Handling of Device data

The data from the devices/controller need to be validated first in order to make it work. The validation can be part of the device driver itself (best choice) else can be performed by the layer above it. The validation will involve health check diagnostic to check whether the device is alive and communicating, feed back is readable (not any junk characters), etc.,

The validated device data has to be processed by any Logic building application. e.g. :
1. PI-Processbook from OSI soft http://www.osisoft.com/software-support/products/PI_ProcessBook.aspx
2. InTouch from Wonderware/ Invensys http://global.wonderware.com/EN/Pages/WonderwareInTouchHMI.aspx
3. Business Logic Editor in xMII module of SAP http://help.sap.com/saphelp_xmii115/helpdata/en/Introduction/IllumSystemOverview.htm

The above tools are provided user friendly logic building features. These tools are provided with industry standard data connectors or adapters. The following are the industry standard connectors
1. OPC (OLE for Process control) - Connecting to time series data from shop floor control system - http://www.opcfoundation.org/
2. OLEDB (Connect to different type of Relational Database Management System( RDBMS), ISAM (Indexed Sequential Access Method) for accessing flat files

Device drivers for communication between Controllers and PC

Once protocol for the controllers are available, the communication between controller and PC can be enabled using device drivers. Device drivers are the set of instructions developed to communicate with the controllers using assembly level language. Long standing programming tools are C, C++, VC++ and Embedded java. The key parameters required

1. Baudrate of the device ( e.g. 9600)
2. Databits
3. Parity
4. Stopbit
5. Flowcontrol

Once above parameters are available using the programming tool, we can Open the port. Here the port points to COM port (serial port 9-pin) of a PC openning up communication channel with controller. After openning up the port the command or instruction has to be sent based on the protocol document.

More information reference
Sample protocol document for batch controllers : http://info.smithmeter.com/literature/docs/mn06069l.pdf

Controllers in detail

Controllers are the heart of the sensor to boardroom integration scenario. Controllers are basically a microprocessors. The processing capability of these microprocessors vary based on the application. For example, if you take the case of Flow controllers or Batch controllers the microprocessor is capable of process two letter commands and maximum of less than 100 commands. The configuration parameters will be stored in PROM type memory (no hard disk). There will be an Input / Output (I/O) circuit board. Using the I/O board users can connect digital or analog input and output devices. The input devices in this case are solenoid valve, flow measurement devices like Positive Displacement (PD) meter, valve position sensor. The output devices are display units, printers.

The controllers can be communicated through a personal computer connected to it. The communication takes place using serial mode (RS - 232/ 422/ 485). The communication protocol plays a major role in establishing connection. Most of the controllers developed earlier days had a proprietory protocols (e.g. smith protocol in AccuLoad controllers). Recent developments in the industry forced the controller vendors to standardise with MODBUS protocol. This will be the standard for controller communication, in the near future.

Also, recent influence of Information Technology (IT) developments added TCP/IP mode of data transmission in the Industrial Automation network as well. The controllers research and development initiative progressed in the following mode of communication :
1. Modbus protocol support
2. TCP/IP
Today's advaced controllers are provided with Modbus communication port and TCP/IP port apart from traditional RS-232/422/ 485 ports.

Hence, if you are interested in connecting a set of similar devices to Manufacturing Execution System (MES) or directly to ERP and other systems, best bet would be to have Serial to TCP/IP converters. Integrate the sensors to the controllers using serial mode and controllers to the external system using TCP/IP mode. These serial to TCPIP converters are provided with optional output USB Port and Fibre Optic cable port. Fibre Optic cable port can be used if the controller need to be located in a remote place and far from the communicating computer.

Also, the remote controllers can be connected to the TCP/IP converter which in turn can be connected to a wireless LAN device and an in-built GPRS enabled device. This helps in trouble shooting of controllers situated in remote locations e.g. Remote Terminal Units (RTU) in the cross country pipelines of Oil & Gas industries.

More information below,
Controller : Batch controllers http://www.ryanhercoflowsolutions.com/Markets/VendorArticles/Signet/BatchControls.pdf
Modbus protocol : http://www.modbus.org/docs/PI_MBUS_300.pdf
Serial-to-TCPIP converters : http://www.moxa.com/product/NPort_S8000.htm

Let's Begin with Sensors

The sensors are the basic elements in any controller configuration. In a typical process control scenario, it is a device which measures and transmits the process value to the controller (e.g. RTD - temperature, Diaphragm - Pressure, Loadcell-Mass, Orifice - Flow, household security sensors, proximity card readers etc.). The sensors must be connected to a controller. The type of connection and communication methods differ based on the controller. For example in the proximity card reader the sensor need to be connected by a serial cable. This indirectly limits the distance between sensor and respective controller to maximum of 100 to 200 meters.

In the case of hydrocarbon handling area the proximity type sensors need to be intrinsically safe type and only few vendors are available (like Honeywell , HID). For Oil & Gas industry application take extracare while selecting sensors.

The key points while selection of sensors,

1. Type of industry (intrinsic safe or not)

2. Sensor sensitivity

3. method of communication between sensor and the controller

For more information on proximity type sensors/ cards etc ---http://www.hidglobal.com/technology.php?tech_cat=4&subcat_id=9

Webservices for accessing OPC data from ERP sytems

OPC DA XML standards will be the future for accessing data of Shop Floor systems from ERP Systems. The main advantages are,

1. To avoid DCOM related OPC configuration settings while setting up of OPC Client systems

2. No need to install OPC Client on user systems

3. Current ERP systems are updated with very good webservices consumption modules (e.g. SAP PI (XI))

4. Security related services are intact and easy to configure as it is webservice

The sample OPC XML DA Gateway servers and demo servers are available at http://www.advosol.com/pc-6-5-xml-da-server-side-gateway.aspx