At the supervisory layer, standard graphical objects are created that allow instances of master templates to be implemented with the concept of “one-change-one-place.” These objects are built to visually represent devices and contain scripting and animations to represent real-world status through the namespace, and provide connections for other graphic controls for configuration and control. Since this layer can be comprised of many computers, a single namespace exists within this layer to allow data to flow without needing to know where the data is located. Within this layer, some systems have or are moving towards having the ability to add/configure alarming, historization, security, scripting, advanced programming (.NET Applications) and I/O interfacing to other systems for each object. Since the graphical objects expose the properties of the control layer objects for configuration, many of the process changes that normally would require a PLC logic change can now occur with a mouse click or touch point. An example of this is enabling a high alarm on an analog transmitter. This can now be done by checking a box and entering a value.
Level III Layer
Within Layer III, data historization and collection, formula management, material tracking, downtime tracking, inventory management and manufacturing execution systems reside. Detailed discussion of this layer is beyond the scope of this article, except to say that building objects within it that maximize the lower-level data structures continues moving the data upward.
Finally, we must answer one other important question: When is a device different enough to warrant a separate standard object? That depends on the plant, personal theory and the complexity or footprint of the differences. For example, a solenoid-operated valve may have one limit switch to detect the open position, or it may have two limit switches to detect both closed and open positions, or it may have no feedback. In these examples, the creation of a separate standard object is not necessary; the best approach would be to have a configuration bit that enabled each limit switch that is used; the reason being is that it takes minimal under-the-hood logic to make that happen.
Let’s look at another example. A conveyor system may have the following devices associated with it:
- Two photo-eye switches
If there were more than three of these conveyor systems, and additional conveyors are expected to be added in the future, then the creation of a standard object for this type of conveyor system may be warranted. If this was a one-off system or rarity, then the proper choice would be to use a SSM standard object and two digital input standard objects.
In conclusion, every device should be either an object or built from objects at every layer. By implementing properly engineered standard objects in your system, you will achieve faster development times with better quality. Furthermore, by creating an object-based toolkit you can achieve the same look and feel for all systems within your organization. Someone trained on the toolkit can have no knowledge of the process, but feel comfortable troubleshooting the control system. Our organization has had many sucesses creating these toolkits and have helped our customers revolutionize their control systems.
Jeff Miller is a group leader with systems integrator, E-Technologies.