System Architecture and Requirements Documents
Entry posted by Bryon Sol
852 views
Following on the heels of my blog about Ethernet Protocols, I think it’s worth discussing System Architecture and Equipment Requirements. Over the past several years I’ve been on what I consider the wrong end of system architecture gone wrong and had to help people work their way out of a tough spot on a more than one occasion. And the reason that the architecture has gone wrong is usually the same: either lack of equipment requirements or poorly written equipment requirements.
So what do I mean when I talk about System Architecture? Simply put System Architecture is defined by the major components chosen, and their capabilities. This ties into Ethernet protocols quite frequently because people don’t consider the protocols or how difficult they may or may not be to implement.
Let’s look at an example below. This set of components and the architecture looks like a reasonable solution at first glance. Each component will communicate and work together, and everything is using common off-the-shelf protocols and should be relatively easy to program and get to a functional state.
In this solution we have three separate networks, Ethernet for SLMP to the HMI, Ethernet/IP for communications with a pneumatic manifold which also has remote inputs and outputs, CC-Link to talk to a Robot, and an analog to monitor/control a temperature controller. However, with a small component adjustment we can get to the following layout instead.
In this solution we have reduced our networks to just two, Ethernet for SLMP to the HMI which is built into our PLC, and one common CC-Link network to talk to both the Robot and the pneumatic manifold. And we also have reduced our component count by switching to a temperature control module on our PLC and bringing our thermocouple directly to the PLC.
This new architecture benefits us in several ways:
- Component count reduction
- Fewer networks to maintain
- Reduced program/configuration maintenance
The reduced component count is obvious, and sometimes this can actually increase cost, sometimes certain components cost more than others. For example switching everything to Ethernet/IP instead of CC-Link could be more expensive, but both our robot and pneumatic manifold could have been on Ethernet/IP instead if that was our preference. As for reduced program/configuration, now instead of needing to program and configure both a temperature controller and the PLC to monitor and control temperature based on analog conversion, it’s all native to the PLC. This both reduces component count and we no longer have to know multiple platforms (PLC and temp controller), nor do we need to keep multiple configuration files etc.
In the end though, a lot of the component choice mistakes can either be caused by a poorly written or non-existent System Specification or Equipment Specification document. Before sitting down to pick hardware, some sort of minimal system specification document should be created. This document is a living document and can change, but it needs to exist. This document should inform the engineers who are designing and building the equipment what is required in terms of components and functionality, what is optional and potential future expansion plans.
A well written requirements document should include only the truly mandated requirements. For instance, maybe a facility has standardized on Mitsubishi PLCs and ASCO/Numatics pneumatic manifolds. This requirement of manufacturers should be included, but unless there is a real benefit to specifying the protocol and specific model numbers to be used, this does not need to be part of the specification document and it should be left to the discretion of the design engineer. The other information that needs to be in the requirements document is the purpose of the equipment, expected modes of operation and how the equipment must interact with other equipment in the facility. Simple things like power requirements (110VAC vs 230VAC for example), safety requirements, data storage requirements, and networking requirements are simple enough to determine and should also be included. Just make sure your requirements don’t paint the design engineer into a corner where it becomes unreasonably complex or simply impossible to achieve.
And wherever possible keep an eye on the future. For instance if you expect you may want multiple copies of the machine and they must all communicate with each other, it is much easier to design for this up front rather than completing and validating the first machine, and then having to go back and reprogram and revalidate the system later.
So just a friendly word of advice from me to you, write a specification – it really will help, and thoughtfully consider your component choices. In the end this will save you time, money and a lot of frustration.
------------------------------
For more on the benefits of a good specification document, there’s a good article over on automationworld.com:
https://www.automationworld.com/products/control/blog/13300793/do-we-really-need-a-urs
1 Comment
Recommended Comments