Modular process engineering implications for automation
The demand for shorter development manufacturing plant construction cycles is changing how process engineering plants are designed. Pre-planned and pre-built vendor packages or modules are being used more and more in place of ‘stick built’ bespoke processing engineering plant that is built in situ at the target factory. This modular approach to plant building also requires a modular approach to automation and automation integration. How do we manage to keep control systems from different vendors aligned with a centralised standard such that they may be integrated?
Harmonising automation systems throughout different pre-built process modules or ‘skids’ is difficult. It requires common look and feel SCADA, common software modules usage and agreement on common batch or report data semantics, among other requirements. A number of Namur working groups were developed to address this issue.
A model is worth a 1000 meetings..
NE148 identifies that the risk of misunderstanding is high during the planning process between module vendor and system integrator, and it is helpful if a common language (for e.g. a model or system blueprint) can be found. In addition, as the vendor is now going to have to change how they program their system, guidance is required to make this move smoother. Skid documentation should be in a common format (if all the vendors use the same modelling system, it will be in the exact same format). Likewise for testing documentation. Even the approach to simulation during testing should be identical.
Dividing out the factory floor namespace
One of the other challenges facing automation integration of different skids vendors is enforcing unique namespace nomenclature. Distributing a preconfigured virtual development machine is one way to help safeguard the development. Again, a model can help here, by providing both samples but also pre-allocated namespaces. If every process module has its own OPCUA server, then it is a straightforward effort to mimic the model namespace. Finally, if the project type library is rolled into the model, then modules will be uniform across all suppliers.
Communicating design patterns to suppliers
Sometimes a system integrator is tasked with coordinating the control of a number of vendor packages that are being delivered to a site. In the case where the SI has to coordinate numerous other equipment vendors writing software, provision of a model is a good way to do this, especially for interfaces. If both systems support OPCUA, the actual interface can be tested.
In the case where the SI is actually writing the control code for a different equipment vendor, the equipment vendor can help wireframe out how they want the SI software to work. This helps alleviate the problems associated with language barriers, different programming platform experience, different internal standards and different pseudo code used in FDS documents.
Design patterns – Batch philosophy
Just because both vendors are familiar with ISA-S88 does not mean that everything is agreed regarding batch implementation. Some implementations may consider the unit operation layer as redundant and don’t program it. Others don’t use equipment modules. Some sites may differentiate between recipe parameters and ‘engineering parameters’, and others may not! An abstracted model can help align different vendors.
Design patterns – User and equipment safety
While there are Atex standards for hardware, and SIL standards for SIS systems, there is plenty of other operational safety ‘lessons learned’ from the site history Codex that could reasonably be called ‘design patterns’. If they are captured in a model, they are easier to convey to vendors. For example, ‘on this site, we always interlock the pump against the valve on its outlet (to prevent dead heading the pump or damaging the valve seats)’
Summary
Modular automation has been brought about by a move towards modular process engineering. A model is a great way to outline how your plant works to an equipment vendor so that they can do all the testing on their own time against it. Your commissioning project runs smoother as a result.
See Spike in action or try it yourself, no sign up or login required.
