I/O Devices

The Plant SCADA computer that directly connects to an I/O device is an I/O server. I/O servers are responsible for servicing the read, write and subscription requests from clients. A project can have many I/O servers, with each cluster able to include multiple I/O servers.

An I/O server keeps up-to-date information on its connected I/O devices by regularly retrieving data from each and storing it in a cache (I/O device data cache). Whenever a Plant SCADA client requires data from an I/O device, it will use the information stored in the I/O server cache. Clients will not retrieve data directly from an I/O device.

An I/O server will read the necessary data from the I/O device to execute a requested Cicode task or process. For example, when you schedule a report, Plant SCADA reads the I/O device data that the report might need before the first line of the report starts running.

Plant SCADA performs writes to the I/O device asynchronously, allowing other operations to continue while a write is taking place.

Plant SCADA is predominantly a supervisory system. It is the I/O devices that directly monitor and control automation equipment. In most I/O devices (such as PLCs) a program stored in the I/O device controls the outputs. The logic (control strategy) of this stored program and the status of the inputs determine the value of each output.

The value of each input and output is stored in a separate memory register in the I/O device. Each memory register is referenced by its address. You usually don't need to read (or write) to every register in the I/O device: Plant SCADA lets you specify which inputs and outputs you want to monitor or control.

By reading and writing to memory registers in I/O devices, Plant SCADA collects data from your plant or factory for monitoring and analysis, and provides high-level (supervisory) control of your equipment and processes.

Note: I/O devices such as programmable logic controllers (PLCs) usually have an internal program that controls the low-level processes within your plant. A PLC program continually scans the input registers of the PLC, and sets the output registers to values determined by the PLC program logic. While Plant SCADA can replace any PLC program, this is not recommended. PLCs are designed for high-speed response (typically 1 to 100 ms) and replacing this functionality with Plant SCADA could negatively affect your control system’s performance. Only use Plant SCADA to complement your PLC program (that is, for high level control and system monitoring).

The term ‘transport’ refers to both the physical communications medium and the low-level logic necessary to drive it. As far as Plant SCADA is concerned, it simply defines how to package a message, how to send it, and where to send it.

The available transport options are usually governed by the kind of ports available on the target I/O device. However, they are also influenced by the geography of the automation system, specific domain requirements (such as performance and redundancy), and the amount of money the owners are willing to invest.

The three main categories of available transport are:

• Simple serial – such as RS-232, RS-422, RS-485

• Ethernet – the dominant frame-based inter-network protocol

• Proprietary – using intermediary PC-communications hardware or software (such as OPC servers).

Of these, Ethernet is by far the transport technology of choice.

Fortunately, by using the concepts of packet encapsulation and intelligent gateway/routing devices, you are able to mix different transport layers and mediums, including high-speed wireless links or an FDDI network. For example, you could use a serial cable from Plant SCADA to a modem, a PSTN line from the modem to another modem, then a serial cable to an Ethernet gateway, and Ethernet to the I/O device.

Note: Modems are treated as a special case in Plant SCADA since they are recognized as logical devices by Windows. Refer to the specific online help on setting up modems.

Plant SCADA uses the ‘COMx’ driver to implement simple serial transports. Similarly, the ‘TCPIP’ driver implements the Ethernet transport. These are commonly used transport drivers, and both have a range of options and settings that can be tuned. Each proprietary board has its own specific transport driver – which is typically integrated with the protocol driver.

Similarly, the protocol-specific message could be a simple ASCII message or a complex object-based message such as DNP3. Engineers are free to assemble different combinations of I/O devices, transports, and protocols.

Protocol refers to the type of messages exchanged between the I/O server and I/O device.

I/O devices support at least one protocol – which governs the kind of commands and data you can exchange with the device. They vary significantly in functionality and in complexity. However, because Plant SCADA supplies the protocol drivers, the engineer does not need to know the details of the protocol.

Most modern devices support two or more protocols. This gives engineers flexibility in designing appropriate communications architectures. Occasionally the protocol is closely linked to the transport layer used – particularly in the case of proprietary protocols and communications hardware. In many cases, a specific card or module is necessary in the I/O device to support additional protocols.

Industry Standard Protocols

The automation and associated industries have developed a number of standardized protocols for communicating with I/O devices:

• ASCII – for simple serial communications

• Modbus – a widely used simple serial protocol for automation

• DNP 3.0 – a protocol for distributed networks such as RTUs

• BACNet – specifically for the building automation control industry

• OPC – a technology for sharing automation data at the PC level

• IEC870-5 – communication profile for sending basic telecontrol messages

• EIB – European installation bus

• Profibus – field bus communications protocols for automation

• SNMP – widely used protocol for network devices.

As Plant SCADA allows you to choose whatever protocol you need for the situation, you can choose to use these protocols where supported by your I/O device. This is particularly useful when you have a mix of I/O device brands but you want to simplify and use one common protocol.