Saving time and money are two key benefits of an open, interoperable control system. Specifying an open system with good planning and coordination up front saves time and money later during system design and commissioning. Good consulting engineers consider the entire system, not just an individual subsystem, when writing specifications.
Defining a common system architecture using standard, open methods is more appropriate than specifying the “buffet” style that allows anything to be used. When defining an open specification, we need to remember that it is more than just the protocol that needs to be specified. There are five elements that need to be defined:
- The network infrastructure
- The system’s control devices
- The network management tools
- The user interface, and
- The enterprise/I- level interface
The network infrastructure includes the protocol, routers, media type, IT connectivity, etc.
The control devices are the workhorses that consume or manipulate data, and control/monitor the system.
The network management tools configure, commission, and maintain the system.
User interfaces (human-to-machine interfaces, or HMIs) are typically the visualization tools that the user or controls manager uses to obtain a view into the system, including both PC software and instrumentation panels.
The enterprise/IT-level interface is the method for connecting the control network into the data network. We call it the LON-LAN-WAN architecture and it is defined in the specifications using standard Open Systems methodologies. No gateways but using standard routers instead.
Along with these elements, system specifiers must design each subsystem and define the system functionality and requirements for how each subsystem will share information with another.
For example: consider an occupancy sensor, which determines if someone is in a particular space, such as a building, train, or parking lot. The sensor does not determine what happens when presence is detected; it merely provides the “occupancy detected” data. Traditional systems may connect the occupancy sensor to the lighting system: Someone enters the space, and the lights turn on. But that information is vitally useful to many other systems. For example, a heating, ventilating, and air-conditioning (HVAC) system can use the information to provide more conditioned air into an occupied space rather than an unoccupied space. A security system can use the “occupancy detected” information to determine if there is presence in a secured area. An elevator system can use it to determine if a car needs to be sent to a floor as a person enters a defined space - even before the person pushes the elevator-call button. In a parking lot, occupancy sensor information can be used to brighten lights but it can also alert security personnel that someone is in an area after hours.
These are just a few examples where one piece of information can be useful to different subsystems. But far too often, these simple, cross-system data are overlooked when the system is designed. Why? Until recently, specifiers have tended to focus on subsystem design only, not considering the value of integration. Open, interoperable systems now enable more complete system integration with very little extra design effort. The process is relatively straightforward: Start by designing each subsystem, then design the cross-system functionality, and then design the user interface for alarming, scheduling, and data logging.