Now English isn't great for expressing what comes naturally in their own tongue so it is limiting and sometimes there are even misunderstandings. However, it is the best way for each to understand each other. In simple terms English is the interface that allows these two parties to converse.
In programming languages interfaces are extremely common, especially when it comes to Object Orientated Programming (OOP). They are much more commonly used today in control systems than they were 5-10 years ago.
The basic problem an interface is trying to solve is to separate how we use something from how it is implemented. We do this so that we can work with a variety of different implementations without having to specifically handle each implementation.
Interfaces are trying to solve a very specific problem by allowing us to interact with objects based on what they do, not how they do it.
A clock face is an interface - the mechanism is the implementation
An interface is a contract. They allow us to specify that a particular type of object meets certain expectations that other parts of the system can rely on.
In the application world we see this readily in that various systems have an API and they can all be different in how they are implemented. For example, talking to Xero or MYOB utilises completely different APIs, but they are both accounting systems with some common functionality between them, so we write an interface that takes advantage of this commonality, separating the implementation from how we use them. That is, in the case of Xero and MYOB they both have functions that handle creating invoices, but they are implemented very differently so instead of having to write code to handle a Xero create invoice and different code to handle the MYOB create invoice we create our own custom CreateInvoice method that has a set of defined parameters that translates what is supplied to what either Xero or MYOB needs. In this way our new programmer only needs to know about the custom Createnvoice method. They do not need to also learn about the Xero or MYOB implementations.
This can also be applied to the PLC world, although in a more abstracted way to that of OOP in that we don’t specifically use methods but rather attributes or tags.
In this case, instead of Xero and MYOB we have Allen Bradley and Siemens. Both are PLCs, and both pretty much do the same thing, but what they do is implemented differently. This is where having a defined interface makes communication between these systems easy.
Having a defined interface means that from the SCADA perspective the application developer does not need to know how the PLC code is implemented nor do they need to know what PLC is being used. From the PLC perspective, the coder does not need to know if they are interacting with Wonderware, PanelView, or Citect. Not needing to know is different to they should not know - it is very beneficial for both parties to have an understanding of both systems. The point is, because of the interface they do not need to know. This is a huge benefit when it comes to training new starters. It allows them to focus on what they do know whilst giving them the opportunity to later see what is on the other side of the fence.
In the case of these two PLCs, both support UDTs so our interface is a UDT. It is the contract between two dissimilar systems. For example, communications between System Platform and the PLC. In this regard, from project to project the UDT does not change. However, the implementation may change depending on circumstance. By not changing the UDT (interface) means that we can swap one PLC for another or one SCADA system for another without requiring both systems to change, thus reducing significantly the amount of rework required. By not changing the UDT means that a new starter can go from project to project without needing additional training. By not changing the UDT means that everyone knows what is expected. Again, this is great for new starters who have limited exposure. Once they learn the ins and outs of the UDT they can reapply it on any project they work on without additional training.
That is not to say an interface can never be changed. There are many reasons why an interface should change. But there needs to be an agreement between all parties as to why the interface should change so that everyone involved understands the changes and why they are necessary, what the driver is forcing the change, and what the repercussions will be after that change is made, and it needs to be documented and made aware of to the general public (likely end users who could potentially be impacted by the change).
Lastly, the interface (UDT) needs to be documented. It is not enough to provide an interface and expect from its very existence what it is supposed to do. People, no matter how well named an attribute is, will always interpret its use differently. An interface needs verbose documentation. It needs to spell out the purpose of each attribute, how it is used and examples on how it is used.
By Chris van Duin
