Definitions and terminology
Open systems definitions and terminologies for building automation systems and features.
Definitions and terminology
1. Building automation system (BAS): The facility automated control system comprised of all mechanical system automation, and automatic temperature control, lighting control, and other relevant building controls subsystems as defined. The BAS is responsible for the operational functionality of each system. The BAS may run autonomously from other systems and may not require a central building management system (BMS) to operate. In the event of a loss of communication to a BMS server, the BAS shall continue to operate. The BAS is built upon a single network infrastructure. This infrastructure may include field wiring, control network wiring, routers, bridges, raceways, and interfaces as required connecting all subsystems and devices.
2. Building management system (BMS): The BMS is the central management system responsible for any necessary management, oversight, visualization, configuration, and performance monitoring of the building subsystems. A typical BMS provides ancillary oversight responsibility for a given BAS. However, a BMS does not typically provide operational interaction with a BAS. If a BMS interface becomes offline, the BAS continues to perform its required functionality, reducing the potential for a single point of failure.
3. Communication protocol: The rules and procedures governing transfer of information between devices on a network. The abbreviated term “protocol” is often used. The protocol defines the format of the message being transmitted between devices and defines the actions expected when one device sends a message to another. The protocol normally takes the form of embedded software or firmware code in each device on the network.
4. Compatibility: The ability of a device to operate in the same environment with another device without corruption of, interfering with, or hindering the operation of any other device in the same environment. Example: A light fixture from one vendor is installed into a system with fixtures from a second vendor. Neither fixture is communicating directly with each other, only to third device, and the two fixtures are not functionally identical nor are they interoperable; however, they will not interfere with each other’s functionality or operation in the same system.
5. Energy management system (EMS): The facility EMS is responsible for the required interaction and integration of energy consuming/affecting systems that provide facility level management, visualization, analytics, and reporting. An EMS typical ties into or is an extension of the BMS; however, it may also be a stand-alone, non-integrated supervisory system.
6. Enterprise system, enterprise energy management system (EEMS), enterprise or energy information management system (EIMS) : The term “Enterprise System” typically refers to a system that can access many subsystems, including BMS (HVAC, lighting, fire, security, etc.), EMS (electric metering, water metering, gas metering), and others. The Enterprise or Supervisory system can access many buildings and many subsystems within each building and is connected to a central communication network (LAN—local area network and LON—local operating network). Both the EEMS and EIMS terms are used to define an enterprise-level system that connects many buildings or facilities into one common user interface tool. This central front-end typically has a variety of visualization options, dashboards, and kiosk capability coupled with analysis, reporting, trending, and data archiving. An EEMS or EIMS system has additional functionality that allows for comparison across a portfolio, campus, or collection of non-integrated facilities and typically includes reporting for energy engineers giving guidance on operational improvements relating to energy efficiency. An EEMS differs from an EIMS in that the EEMS may also provide direct control interface into the facility in the case of programs such as load shedding, demand response, or other energy curtailment/conservation activity. An EIMS provides one-way flow of information to an enterprise with no option for direct or indirect control.
7. Enterprise remote monitoring system (ERMS): A system consisting of a central enterprise server(s) that is responsible for visualization, dashboards, and public kiosk display of identified building subsystem information. The ERMS may also perform analytics, trending, and alarming/alerting functionality. The ERMS may also interact with other enterprise applications such as energy load shedding, automated demand response (ADR), and others. Typical guide specifications define the requirements for an ERMS and the interaction with the BMS and BAS system elements. An ERMS system differs from an EEMS/EIMS system in that it does not have a specific energy focus and more typically focuses on operational sequences, system scheduling, alarm reporting, and network management, all performed from a remote interface. Often an ERMS is used by a service technician who can remotely access a client’s facility to diagnose and maintain a system.
8. Facility master system integrator (FMSI): An umbrella position within standard construction divisions to help oversee the specification and implementation of direct digital control (DDC), BMS, and BAS systems. The FMSI is usually accountable for assuring interoperability between subsystems and different buildings, for providing a common graphical user interface, for assuring products from multiple bidders and vendors meet the intent of a specification as well as the letter of a specification, and for acting as a technical go-between for the various involved sub-trades (controls, electrical, mechanical, etc.).
9. Functional profile: A model defining a device, subsystem, or system’s set of specific required and optional functionality, interfaces, and resources such that multiple vendors’ products can be tested and certified for interoperability. A device functional profile typically includes its logical, physical, and algorithmic capability definition such that an external device can properly interface and interact with the device. Similarly, a full subsystem such as a lighting or air conditioning system can interact with other subsystems in a defined, interoperable manner.
10. Interchangeability: The ability of a device to operate in the exact same manner as a like device where each device can be swapped into the system with no configuration, performance, or functional differences. Example: Two light fixtures made by competing manufacturers perform the identical functionality, are installed identically, and require no changes to swap them; however, their look or design might differ. They have the same logical and physical interface; however, their internal algorithms may differ but they produce similar functional results.
11. Interoperability: The ability of a device to operate on a network in a consistent manner with a similar device that shares a common defined set of information but is not exactly identical nor is it plug-and-play interchangeable. Example: Two lighting fixtures made by different manufacturers share a defined set of mandatory data variables with a third device (possibly a gateway) in an identical fashion such that the gateway does not need to change its configuration or management format to be vendor specific. However, each lighting fixture may have its own algorithms, hardware specific functionality, or intellectual property associated with its internal workings, and they cannot be interchanged. They may have different electrical or physical configurations but have consistent logical interfaces.
12. Open system – A generalized term referring to the ability of a solution to meet certain criteria for flexibility, interoperability, inter-communication, and competitive procurement. Open systems differs from “open source”, - a term used in the computer software industry that refers to open availability of a user to see, modify, and expand on the software code. Open systems typically refers to a system consisting of a communications infrastructure (the network), networked devices (hardware controllers), control algorithms (software), and a management system (via computer work station). In an open system each of these components may be sourced from multiple vendors and integrated into an interoperable system without significant engineering effort. Standard rules and procedures are developed to ensure the open requirements are met, typically instituted in a system specification, and often adopt industry best practices such as those from LonMark International. Additionally, an open, interoperable system may employ the common functional profile model enabling equipment to share information with other vendors’ products and a front end computer in a defined, standard way (see functional profile, interoperable). In contrast, a closed system typically is one that affords no or limited interoperability, minimal system flexibility, and little or no vendor choice. In general, the controls market has been adopting open systems standards through better guide specifications, more functional profiles being defined and implemented, and greater ability to deliver compliant, certified interoperable components. System integrators have the trained staff and ability to integrate multiple vendor components into a fully open system. Achieved benefits include greater flexibility, scalability, and procurement options along with reduced lifecycle costs.
Ron Bernstein is president of RBCG LLC, a company providing consulting services for building owners, users, integrators, and engineers. He is also the chief ambassador of LonMark International.
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.