The recent trend from control systems vendors is the use of the term “architecture”. This trend has become so pervasive that one major vendor changed the titles of it’s sales reps to “System Architects”. That shift says a lot about the importance of control system architecture.
Architecture is used when talking about the the design and construction of buildings. The term has been equally appropriated to refer to the internal design of computers and complex semiconductor processors. But just as a processor or a computer has an architecture, a control system has an architecture too.
The control system architecture can be the internal architecture of control product such as a PLC, and it can be a priced bill of materials for a complex list of parts. But how do we go about describing the control system adequately so that everyone understands and agrees that it will do what is expected. A panel layout can be created to put all the control systems in an enclosure. And you can write a functional specification for the control system, although these tend to be very difficult to interpret. And none of these things will provide the needed assurance of specific performance.
A control system architecture is an attempt to graphically represent how a bill of materials goes together to solve a customer’s required functionality. This is a little more subtle and may require some additional information, like a flowchart. But the architecture of a control system is an attempt to translate the functional requirement into hardware. And such a diagram will make more sense in terms of the actual application to anyone who looks at it.
And there are plenty of subtleties here. As vendors continue to integrate more capability into smaller, more integrated packages, it can be a little unclear how new hardware will reflect the application’s requirements. This is a little bit like the question of using a PC versus a PLC, only more complex.
An example might be the many new HMI products that are actually computers with the ability to partition the HMI application and control system application on a single processor platform. Which can be a very cost effective and processor efficient solution.
A system input-output map is only the beginning. Turning devices on and off, picking up analog sensors and controlling analog outputs are all the domain of the PLC. Software glues all of these components together. Based on the leap in processor capability over the last few years, the computing requirements for this type of control are certainly not taxing. And the architecture required is fairly flat, a central processor and an I/O buffer.
When the application requires motion control or the integration of pneumatic or hydraulic systems, there begins to be a system consideration. The pneumatic sub-system could be on a Device Net interface, where there will be a time latency between the central processor and the sub-system. And while this might present no discernable issue for the control system, the latency is very difficult to account for.
When integrating more complex sub-systems like external motion controllers, the time required to update position information can be significant. And as with other sub systems, the time latency cannot be accounted for or circumvented. Which puts a practical limit on the actual application.
This makes careful study of the system architecture an invaluable effort to not only evaluate the cost for a control system, but anticipate performance issues as well. With proper attention to issues like system timing, many pitfalls in implementation can be avoided and the architectural diagram can be an invaluable tool to instill confidence that an application is properly understood and will work as expected.
Tell Us What You Think!