Journey to the center of the plant: SCADA systems information flow

Part 2: Understanding the network communication process between a PLC and the SCADA computer is important because there are a number of elements that need to be addressed, such as the language a computer speaks and the tools needed to streamline the process.

By Shady Yehia January 13, 2016

Part 1 explained the supervisory control and data acquisition (SCADA) system big picture at a glance and then followed one analog signal, the tank temperature signal, from being a physical value up to a scaled digital value stored in a known memory address in the programmable logic controller (PLC) central processing unit (CPU). Let’s continue our journey, starting with the network communication between the PLC and the SCADA computer.

Network communication

Network communication has always been the most confusing topic for instrumentation engineers when discussing SCADA.

In this example, we have a PLC with some information located in its memory registers (the tank temperature value) and a brand new computer with the latest version of XYZ SCADA package installed on it. A question presents itself: How would the computer talk to the PLC? Can they actually talk? The answer is they can, but for any two devices to exchange data together, four elements must exist:

  • Common communication interface—or a common network, both of them have an Ethernet port, and they are connected together directly, via a switch, or a network of switches.
  • Common language—it’s called a communication protocol in automation.
  • Known network addresses—obviously, we can’t call someone on his cell phone if we don’t have his number, and the same goes here.
  • Memory addresses—addresses for the data to be communicated in the slave "or server" device memory.

The discussion on the industrial network communications can go endlessly here, but for now let’s go back to our example and apply the same four points:

  • The communication interface—In our example, the PLC has only an RS232 serial port; we have no choice but to use it and make sure the PC we buy has a similar port too. If not, we can always buy a PCI serial card and plug it into the mother board of the PC. We bought the serial cable and made sure it has the correct pin-assignment and plug it into the serial ports in both sides.
  • The communication protocol—This PLC talks one of the most common communication protocols in the world, the modbus.
  • Known addresses—As the modbus serial protocol allows only one master on the network, and only the master can initiate communication requests, the master needs no address. The PLC modbus slave address is set to 01.
  • Data address—The temperature value is MW100, which is explained in part 1 of this article.

Natively, computers and their operating systems don’t speak modbus; it’s the software that runs on the computer that provides this. If the SCADA does not speak modbus, then an OPC server in the middle that can talk with the SCADA and the modbus is needed.

OPC server, the middle man!

OPC is a software interface standard that allows Windows programs to communicate with industrial hardware devices:

  • OPC—OLE for process control
  • OLE—Object linking and embedding

The OPC server is a software program that converts the hardware communication protocol used by a PLC into the OPC protocol. The OPC client software is any program that needs to connect to the hardware, such as SCADA. The OPC client uses the OPC server to get data from or send commands to the hardware (see Figure 2).

The value of OPC is that it is an open standard. Users can choose any OPC client software they need (i.e. any SCADA software), and it can communicate seamlessly with their hardware as long as there is an OPC server that can talk to it (see Figure 3).

OPC servers usually are very user friendly, for a small application like the one we have, setting up the OPC server to do the needed job shall take no more than minutes. The user is usually asked to configure four elements:

  • Channel—The user defines the communication interface, communication protocol, and the port used in the PC. In our example it is a serial interface, the protocol is modbus serial, and we will utilize the serial port COM1.
  • Device—The user mainly defines the node address of the PLC. In the example shown below, there is one PLC and its address is 01.
  • Group—An optional item, just a folder to segregate the OPC items if there are too many. In our example we will create a group and call it "Tank."
  • Item—This is the actual place that holds the information in the OPC server. Each item is corresponding to a memory address in the PLC memory, and each item can have a read/write capability or a read only capability (like our tank temperature, we certainly don’t want to write anything on it, we just want to read it). In our example we have one OPC item and it’s named "Tank Temperature" (see Figure 4). 

These four elements actually represent the address of the OPC item; this address can be called by OPC clients (i.e. the XYZ SCADA Software).

The next post in this series will discuss the SCADA software and how its tags are defined, how information is visualized, stored and reported, and the concept of client/server in SCADA applications.

– Shady Yehia is the founder and author of The Control Blog. He is the Instrumentation, Control, and Automation Proposals & Engineering manager in a process technology integration company based in Qatar and operates in the EMEA region. This article originally appeared on The Control Blog. Edited by Chris Vavra, production editor, CFE Media, Control Engineering, cvavra@cfemedia.com.

ONLINE extra

See additional stories about SCADA systems linked below and see Part 1 of this series.