Ahorrar tiempo y dinero son dos ventajas clave de un sistema de control abierto e interoperable. Especificar un sistema abierto con una buena planificación y coordinación a priori ahorra tiempo y dinero más tarde durante el diseño del sistema y la puesta en marcha. Los buenos ingenieros consultores consideran todo el sistema, no sólo un subsistema individual, al escribir las especificaciones.
Definir una arquitectura de sistema común utilizando métodos estándar y abiertos es más apropiado que especificar el estilo «buffet» que permite que cualquier cosa sea utilizada. Al definir una especificación abierta, necesitamos recordar que es más que sólo el protocolo que necesita ser especificado. Hay cinco elementos que deben definirse:
La infraestructura de red
Los dispositivos de control del sistema
Las herramientas de gestión de red
La interfaz de usuario, y
La interfaz de nivel de empresa / I
La infraestructura de red incluye el protocolo, enrutadores, tipo de medio, conectividad de TI, etc. Los dispositivos de control son los caballos de carga que consumen o manipulan datos y controlan / monitorean el sistema. Las herramientas de administración de red configuran, comisionan y mantienen el sistema.
Las interfaces de usuario (interfaces hombre-máquina o HMI) son típicamente las herramientas de visualización que el usuario o el administrador de controles utiliza para obtener una vista en el sistema, incluyendo el software de PC y los paneles de instrumentación.
La interfaz de nivel de empresa / TI es el método para conectar la red de control a la red de datos. Lo llamamos la arquitectura LON-LAN-WAN y se define en las especificaciones usando metodologías estándar de sistemas abiertos. No hay gateways sino usar enrutadores estándar.
Junto con estos elementos, los especificadores del sistema deben diseñar cada subsistema y definir la funcionalidad del sistema y los requisitos de cómo cada subsistema compartirá información con otro.
Por ejemplo: considere un sensor de ocupación, que determina si alguien está en un espacio particular, como un edificio, tren o estacionamiento. El sensor no determina qué sucede cuando se detecta presencia; Simplemente proporciona los datos de «ocupación detectada». Los sistemas tradicionales pueden conectar el sensor de ocupación al sistema de iluminación: Alguien entra en el espacio y las luces se encienden. Pero esa información es de vital utilidad para muchos otros sistemas. Por ejemplo, un sistema de calefacción, ventilación y aire acondicionado (HVAC) puede utilizar la información para proporcionar más aire acondicionado en un espacio ocupado en lugar de un espacio desocupado. Un sistema de seguridad puede usar la información de «ocupación detectada» para determinar si hay presencia en un área segura. Un sistema de ascensor puede usarlo para determinar si un automóvil necesita ser enviado a un piso cuando una persona entra en un espacio definido – incluso antes de que la persona empuje el botón de llamada al ascensor. En un estacionamiento, la información del sensor de ocupación se puede utilizar para iluminar las luces, pero también puede alertar al personal de seguridad de que alguien está en un área después de horas.
Estos son sólo algunos ejemplos donde una pieza de información puede ser útil a diferentes subsistemas. Pero con demasiada frecuencia, estos simples datos cruzados del sistema se pasan por alto cuando se diseña el sistema. ¿Por qué? Hasta hace poco, los especificadores tendían a centrarse únicamente en el diseño del subsistema, sin considerar el valor de la integración. Los sistemas abiertos e interoperables ahora permiten una integración de sistemas más completa con muy poco esfuerzo de diseño adicional. El proceso es relativamente sencillo: Comience diseñando cada subsistema, luego diseñe la funcionalidad de sistema cruzado y luego diseñe la interfaz de usuario para alarmar, programar y registrar datos.
[:en]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.[:pb]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.