For background information see LOWIS Server Architecture Overview
In LOWIS, the mopccldr.exe program (referred to as OPC Manager) is responsible for communications to devices that use an OPC Server to provide the data. OPC Servers are software designed to act as an intermediary between devices and any other software that is interesting in getting information from these devices. Using an OPC Server means that multiple applications can get data from the device (as the OPC Server software is what is communicating with the devices) and since OPC is a specification applications that are written to the specification can get data for any kind of device that has an OPC Server to provide data for it.
LOWIS's OPC support was written against the Data Access 2.05 specification, with some pieces of the Data Access 3.0 specification being used to speed things up when they are available on the OPC Server. LOWIS's OPC support mainly operates in the Asynchronous data mode, where LOWIS tells the OPC Server what data it is interested in and how often it needs it to be updated and LOWIS just waits for the OPC Server to provide it the data when the OPC Server gets it. LOWIS can be forced to operate in Synchronous data mode, where LOWIS will actively ask the OPC Server for the data and wait for the data to be provided by the OPC Server when the LOWIS schedule says that the data should be updated.
OPC is unique in the LOWIS architecture in that exists in two different layers of LOWIS - the communications and scan task layers. This is because while OPC is a communications specification (and thus exists in the communication layer of LOWIS), it is also a specification for which generic device support can be written, and the scan task layer is where device support exists. As such, LOWIS supports OPC communications in two different modes - Native to OPC and Pure OPC communications.
As was mentioned in the LOWIS Server Architecture, each layer of LOWIS uses a generalized interface to communicate with the layer that exists below it in the architecture, meaning that in theory every type of device can be communicated with via any communications channel that LOWIS has available to talk to devices. It is only when we are communicating via OPC that this theory falls apart, mainly because of how data is identified in OPC versus other communication channels. For radio or ip communications, the outgoing request message and returning reply message are identical (except for the slight differences involved in Modbus TCP as mentioned in the TCP/IP Communications article). For OPC the request is completely different.
OPC Servers actually present the data as individual elements instead of returning the data as a stream of bytes that have to be interpreted by the consuming application (this is because the OPC server has already done the consuming and parsed out the data from the replies it receives from the devices). As a result, when talking to an OPC server each item of data to be retrieved is identified by something called an OPC Tag which is just a string identifying the piece of data that is desired. Typically in an OPC server these tags are given readable and meaningful names, so you can ask the OPC Server for the CasingPressure value instead of having to know that it happens to be stored in register 524 on the device. The OPC specifications just say that the OPC server will expose available data via OPC Tags and the OPC client applications will have to know which tags they need to request to get the data desired by the user, there is no specification that specifies how these OPC Tags are structured. Indeed, it might be necessary to configure in the OPC Server each tag that it will need to provide data for.
This means that each OPC Server vendor has the ability to design their own OPC Tag naming conventions meaning that OPC Servers from different vendors that support the same device might have completely different OPC Tags for the same data from a device. For this reason LOWIS has certain identifiers that will need to be specified to tell LOWIS how the OPC Server that it is to communicate with does its tag structuring.
In addition to these explicitly created OPC Tags, many OPC servers also support a pseudo OPC Tag syntax in that the OPC Tag is able to be parsed by the OPC Server such that it can determine from the tag that was passed to it what information needs to be pulled from the device and how to pull it without that tag having been explicitly specified in the OPC Server. This functionality allows for all (or nearly all) registers available in a device to be accessible with minimal configuration in the OPC Server. As an example, lets consider that we configure a device in the OPC Server named Radio5.WellHead9 that the OPC Server knows is accessible on the radio connected to COM Port 2 and is a modbus device with an address of 13. If the OPC Server was then to receive an unexpected OPC Tag request for Radio5.WellHead9.Value.40100S, it could look at this tag and see
- Radio5.WellHead9 - it recognizes this as a configured modbus device on COM Port 2 with an address of 13
- .Value - it sees this and knows that a structured modbus register request will follow
- .40100S - it knows this is a structured modbus request and it parses it as function code 4 (the 40000), register 100 (the 100) and the data to be returned will be a signed 2 byte integer (the S)
All of this allows the OPC Server to generate the correct request to go out to the device and process the reply received from the device. If LOWIS has built in support for Native to OPC for a specific controller type, LOWIS uses this automatic tag generation methodology to translate the request that it normally would have sent out to a device into the appropriate OPC Tags for the OPC Server it going to use to talk to the device instead. This translation to OPC is done in the appropriate controller's scan task layer executable, which also handles repackaging the returned OPC data into a format that the normal processing code can process so that it is unaware of OPC being involved.
For pure OPC communications, the device is configured as an OPC device within LOWIS, either a OPC### (the ### syntax indicates a number that typically starts from 001 - so OPC001 as an example) or xOPC## (where the x is the LOWIS letter code for the artificial lift type employed, SOPC01 as an example of a Submersible OPC device). For these devices every piece of data to be retrieved must be explicitly specified. For the artificial lift specific OPC versions, there are also some analog and discrete point types that must be configured for the built in functionality to operate correctly.