This post is the second post in the series “Journey to the Center of the Plant – from FIELD to SCADA and Back”, if you haven’t read Part 1, I recommend you read it first so you can follow the subject.

Previous – “Journey to the Center of the Plant – from FIELD to SCADA and Back – Part I”

SCADA Systems Information Flow from Field Instruments to Control Room – Part II

As you may remember, in Part 1 we explained the SCADA system big picture at a glance, and then followed one analog signal, the tank temperature signal, from being physical value up to a scaled digital value stored in a known memory address in the PLC CPU.

Let’s continue our journey, starting with the network.

Network Communication

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

You have a PLC with some information located in its memory registers (in our case the tank temperature value), you have a brand new computer and you just installed on it the latest version of XYZ SCADA package, you are so excited about getting this project to run and to have that stylish temperature gauge that you’ve seen in the SCADA vendor’s brochure showing your tank’s temperature on your computer monitor.

Then the question hits you, how would the computer talk to the PLC? Can they actually talk? Don’t panic; let me brief you a little on how to get this done.

For any two devices to exchange data together, four elements must exist:

• Common Communication Interface – or a common network, like both of them has an Ethernet port and they are connected together directly, via a switch, or a network of switches.
• Common Language – in the automation world we call it Communication Protocol.
• Known Network Addresses – obviously, you can’t call someone on his cell phone if you 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, so I am going to write a post about it soon to cover the major aspect of that subject, for now let’s go back to our example and apply the same four points:

• The Communication Interface – In our example, our 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, we plug it into the serial ports in both sides, DONE.
• The Communication Protocol – Our 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. We choose to set the PLC MODBUS Slave Address to 01.
• Data Address – We know from before that the temperature value is waiting for us in MW100, perfect!

Now everything is set, except one thing. Natively, computers and their operating systems don’t speak in MODBUS, it’s the software that runs on them that does this. So you check your XYZ SCADA software manual and BOOM, we didn’t see this one coming, your XYZ SCADA doesn’t speak in MODBUS.

Hey, before the frustration kicks in, don’t worry, we have a plan, it’s called the OPC server!

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.

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), resting assured that it will communicate seamlessly with their hardware as long as there is an OPC server that can talk to it, and vice-versa.

So back to our example, we search online for an OPC server that can talk in MODBUS and play the role of a MODBUS Master, and we find that actually all OPC servers can do that, we pay the money, we get a software named ABC OPC Server and we installed it on the same PC with the SCADA package, and here we go.

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 our example, we have only one PLC and its address is 01.
• Group – An optional item, just a folder to segregate the OPC Items if they are 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, 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 “TankTemperature”.

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

Next post “Journey to the center of the Plant, from FIELD to SCADA and Back – Part III – SCADA Software” we 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.

Next – Part III – SCADA Software