The common starting point for parallel application development and hardware tasks remains the list of necessary input and output points that emerges from a preliminary process design. In ABB’s xStream Engineering methodology
, for example, each of these points will have been given a unique “Signal” identifier, or field device tag. Functioning as both instrument Signal and application Signal, the consistent and coordinated use of these field device tags throughout hardware and software project execution processes contributes to the smooth and speedy start-up of a fully functioning system.
Engineers responsible for the hardware side of the control system equation can then order standard cabinets with the adequate number of generic I/O channels (plus spare capacity) based on the list of Signals. Because the project is based on pre-designed and tested I/O cabinets that require no custom engineering, there’s no need for a factory acceptance test (FAT) when the cabinets arrive. Instead, they can proceed to install the cabinets, wire the field devices to the I/O, configure each I/O channel with the appropriate plug-in signal conditioning module and field device tag, and finally check that each loop functions as expected.
Meanwhile, those responsible for the software side of the equation will have developed the necessary application logic, allocated the applications to specific controllers, and—in a virtual FAT—tested the software against emulated hardware and a simulated process to ensure that the code will perform as anticipated.
Finally, the tested application and hardware meet up on site. I/O points are digitally marshalled and bound to their designated controllers and applications, independent of physical I/O channel location. This ability to preserve automation system flexibility while performing hardware and software engineering tasks in parallel is a critical step toward moving automation off the critical path of the overall project schedule.