The LOWIS Software Suite is organized as an n-Tier application consisting of 4 Tiers:
- The User Interface (UI) Layer (LOWIS Client Application and other command line tools such as msql.exe and mcsscrip.exe)
- The Processor Layer that the UI layer interacts with
- The Scan Task Layer that the Processor Layer interacts with
- The Communication Layer accessed by the Scan Task Layer
At each of the layers below the User Interface layer, all interaction is done through a common interface that is only used by that specific layer boundary, enabling each layer above to interact with any layer immediately below it with minimal knowledge of which application in that layer it is communicating with.
The Processor Layer
The Processor Layer is where artificial lift specific functionality is placed. For each artificial lift type there are typically at least one processor application (Beam Processor as an example) and two database server applications (Beam DB Server and Web Beam DB Server) associated with it. There may also be other specialized processors as well at this level (the Analysis processors are an example of these).
It is the responsibility of the applications in this layer to either respond to the request it received directly or to determine what information is needed from a device to answer the request. If information from a device is needed it is requested from the appropriate process in the Scan Task Layer to acquire it.
The Scan Task Layer
The Scan Task Layer is responsible for accepting a list of required information from a device and constructing the necessary requests that will have to be made to the device to get the required information. Each scan task application is written to process a specific protocol (mmdbscan.exe is the Modbus Scan Task for example). As such there is typically a specific instance of each application to handle the requests for a specific controller type (ie: there will be a SAMRPC instance for the earlier Lufkin SAM rod pump controller and a different SAMRP2 instance for the newer versions of that controller, both of which are using the same mmdbscan.exe application).
Any behavior differences needed by different specific controller versions are handled by configuration options specified for that instance in the LOWIS Admin configuration system.
When the scan task generates each request message that will need to be sent to the specific controller, it also calculates the number of bytes that the resulting reply message from the controller should be. This count is sent along with the request message to the appropriate Communications Layer application to actually perform the communications interaction.
The Communications Layer
The Communications Layer applications are responsible for the actual interaction with the device to get the data desired by the Application Layer. As such, each Communications Layer application performs a particular mode of communication interaction. As was the case in the Scan Task layer, specific behavioral requirements for a particular communication channel are specified as configuration options in the LOWIS Admin configuration for that communication channel instance.
In LOWIS, regardless of what type of communication mechanism is used, a COM port is assigned to that communications channel. If the communications is done via RS-232 style communications, this will typically be a real COM port on the machine, otherwise this is a virtual COM port used to group the appropriate configuration information needed for communication with the devices on the communications channel.
LOWIS has the following Communications Layer applications to support the specified types of communications channels:
- Serial Port (mscan.exe) -This application would be used for talking to devices directly accessible via RS-232 from the machine, or device reachable via a radio network whose transmitter is directly connected to via RS-232 to the machine. For more information see Radio Communications (mscan.exe)
- TCP/IP Port (mipscan.exe) - This application would be used for talking to devices that are directly reachable via an TCP/IP address/port combination or for talking to devices reachable via a radio that is accessed via a TCP/IP access device (an ARCOM, IP to Serial, or terminal server type of device). For more information see TCP/IP Communications (mipscan).
- OPC Port (mopccldr.exe) - This application is used for talking to devices which have their communications controlled via an OPC Server. OPC originally was an abbreviation for OLE (Microsoft Object Linking & Embedding) for Process Control, but now has become a non-abbreviation identifier since OPC supports underlying technologies aside from just OLE. OPC consists of specifications that allow any software that follows the specification to be able to get data from any device that has an OPC server that can talk to it. For more information see OPC Communications (mopccldr.exe).