Deterministic Networking Y. Kaneko Internet-Draft Toshiba Intended status: Informational S. Das Expires: April 18, 2016 Applied Communication Sciences October 16, 2015 Building Automation Use Cases and Requirements for Deterministic Networking draft-bas-usecase-detnet-00 Abstract This document describes Building Automation System (BAS) use cases and its requirements for deterministic networking. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 18, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Kaneko & Das Expires April 18, 2016 [Page 1] Internet-Draft bas-usecase-detnet October 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Building Automation Systems . . . . . . . . . . . . . . . . . 3 3.1. BAS Functionality . . . . . . . . . . . . . . . . . . . . 3 3.2. BAS Architecture . . . . . . . . . . . . . . . . . . . . 4 3.3. Deployment Model . . . . . . . . . . . . . . . . . . . . 5 3.4. Use cases and Field Network Requirements . . . . . . . . 7 3.4.1. Environmental Monitoring . . . . . . . . . . . . . . 7 3.4.2. Fire Detection . . . . . . . . . . . . . . . . . . . 8 3.4.3. Feedback Control . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Building Automation System (BAS) is a system that manages various equipment and sensors in buildings (e.g., heating, cooling and ventilating) for improving residents' comfort, reduction of energy consumption and automatic responses in case of failure and emergency. For example, BAS measures temperature of a room by using various sensors and then controls the HVAC (Heating, Ventilating, and air Conditioning) system automatically to maintain the temperature level and minimize the energy consumption. There are typically two layers of network in a BAS. Upper one is called management network and the lower one is called field network. In management networks, an IP-based communication protocol is used while in field network, non-IP based communication protocols (a.k.a., field protocol) are mainly used. There are many field protocols used in today's deployment in which some medium access control and physical layers protocols are standards-based and others are proprietary based. Therefore the BAS needs to have multiple MAC/PHY modules and interfaces to make use of multiple field protocols based devices. This situation not only makes BAS more expensive with large development cycle of multiple devices but also creates the issue of vendor lock-in with multiple types of management applications. The other issue with some of the existing field networks and protocols are security. When these protocols and network were developed, it was assumed that the field networks are isolated Kaneko & Das Expires April 18, 2016 [Page 2] Internet-Draft bas-usecase-detnet October 2015 physically from external networks and therefore the network and protocol security was not a concern. However, in today's world many BASes are managed remotely and is connected to shared IP networks and it is also not uncommon that same IT infrastructure is used be it office, home or in enterprise networks. Adding network and protocol security to existing system is a non-trivial task. This document first describes the BAS functionalities, its architecture and current deployment models. Then we discuss the use cases and field network requirements that need to be satisfied by deterministic networking. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 3. Building Automation Systems 3.1. BAS Functionality Building Automation System (BAS) is a system that manages various devices in buildings automatically. BAS primarily performs the following functions: o Measures states of devices in a regular interval. For example, temperature or humidity or illuminance of rooms, on/off state of room lights, open/close state of doors, FAN speed, valve, running mode of HVAC, and its power consumption. o Stores the measured data into a database (Note: The database keeps the data for several years). o Provides the measured data for BAS operators for visualization. o Generates alarms for abnormal state of devices (e.g., calling operator's cellular phone, sending an e-mail to operators and so on). o Controls devices on demand. o Controls devices with a pre-defined operation schedule (e.g., turn off room lights at 10:00 PM). Kaneko & Das Expires April 18, 2016 [Page 3] Internet-Draft bas-usecase-detnet October 2015 3.2. BAS Architecture A typical BAS architecture is described below in Figure 1. There are several elements in a BAS. +----------------------------+ | | | BMS HMI | | | | | | +----------------------+ | | | Management Network | | | +----------------------+ | | | | | | LC LC | | | | | | +----------------------+ | | | Field Network | | | +----------------------+ | | | | | | | | Dev Dev Dev Dev | | | +----------------------------+ BMS := Building Management Server HMI := Human Machine Interface LC := Local Controller Figure 1: BAS architecture Human Machine Interface (HMI): It is commonly a computing platform (e.g., desktop PC) used by operators. Operators perform the following operations through HMI. o Monitoring devices: HMI displays measured device states. For example, latest device states, a history chart of states, a popup window with an alert message. Typically, the measured device states are stored in BMS (Building Management Server). o Controlling devices: HMI provides ability to control the devices. For example, turn on a room light, set a target temperature to HVAC. Several parameters (a target device, a control value, etc.), can be set by the operators which then HMI sends to a LC (Local Controller) via the management network. o Configuring an operational schedule: HMI provides scheduling capability through which operational schedule is defined. For example, schedule includes 1) a time to control, 2) a target device to control, and 3) a control value. A specific operational Kaneko & Das Expires April 18, 2016 [Page 4] Internet-Draft bas-usecase-detnet October 2015 example could be turn off all room lights in the building at 10:00 PM. This schedule is typically stored in BMS. Building Management Server (BMS) collects device states from LCs (Local Controllers) and stores it into a database. According to its configuration, BMS executes the following operation automatically. o BMS collects device states from LCs in a regular interval and then stores the information into a database. o BMS sends control values to LCs according to a pre-configured schedule. o BMS sends an alarm signal to operators if it detects abnormal devices states. For example, turning on a red lamp, calling operators' cellular phone, sending an e-mail to operators. BMS and HMI communicate with Local Controllers (LCs) via IP-based communication protocol standardized by BACnet/IP [bacnetip], KNX/IP [knx]. These protocols are commonly called as management protocols. LCs measure device states and provide the information to BMS or HMI. These devices may include HVAC, FAN, doors, valves, lights, sensors (e.g., temperature, humidity, and illuminance). LC can also set control values to the devices. LC sometimes has additional functions, for example, sending a device state to BMS or HMI if the device state exceeds a certain threshold value, feedback control to a device to keep the device state at a certain state. Typical example of LC is a PLC (Programmable Logic Controller). Each LC is connected with a different field network and communicates with several tens or hundreds of devices via the field network. Today there are many field protocols used in the field network. Based on the type of field protocol used, LC interfaces and its hardware/software could be different. Field protocols are currently non-IP based in which some of them are standards-based (e.g., LonTalk [lontalk], Modbus [modbus], Profibus [profibus], FL-net [flnet],) and others are proprietary. 3.3. Deployment Model An example BAS system deployment model for medium and large buildings is depicted in Figure 2 below. In this case the physical layout of the entire system spans across multiple floors in which there is normally a monitoring room where the BAS management entities are located. Each floor will have one or more LCs depending upon the number of devices connected to the field network. Kaneko & Das Expires April 18, 2016 [Page 5] Internet-Draft bas-usecase-detnet October 2015 +--------------------------------------------------+ | Floor 3 | | +----LC~~~~+~~~~~+~~~~~+ | | | | | | | | | Dev Dev Dev | | | | |--- | ------------------------------------------| | | Floor 2 | | +----LC~~~~+~~~~~+~~~~~+ Field Network | | | | | | | | | Dev Dev Dev | | | | |--- | ------------------------------------------| | | Floor 1 | | +----LC~~~~+~~~~~+~~~~~+ +-----------------| | | | | | | Monitoring Room | | | Dev Dev Dev | | | | | BMS HMI | | | Management Network | | | | | +--------------------------------+-----+ | | | | +--------------------------------------------------+ Figure 2: Deployment model for Medium/Large Buildings Each LC is then connected to the monitoring room via the management network. In this scenario, the management functions are performed locally and reside within the building. In most cases, fast Ethernet (e.g. 100BASE-TX) is used for the management network. In the field network, variety of physical interfaces such as RS232C, and RS485 are used. Since management network is non-real time, Ethernet without quality of service is sufficient for today's deployment. However, the requirements are different for field networks when they are replaced by either Ethernet or any wireless technologies supporting real time requirements (Section 3.4). Figure 3 depicts a deployment model in which the management can be hosted remotely. This deployment is becoming popular for small office and residential buildings whereby having a standalone monitoring system is not a cost effective solution. In such scenario, multiple buildings are managed by a remote management monitoring system. Kaneko & Das Expires April 18, 2016 [Page 6] Internet-Draft bas-usecase-detnet October 2015 +---------------+ | Remote Center | | | | BMS HMI | +------------------------------------+ | | | | | Floor 2 | | +---+---+ | | +----LC~~~~+~~~~~+ Field Network| | | | | | | | | | Router | | | Dev Dev | +-------|-------+ | | | | |--- | ------------------------------| | | | Floor 1 | | | +----LC~~~~+~~~~~+ | | | | | | | | | | Dev Dev | | | | | | | | Management Network | WAN | | +------------------------Router-------------+ | | +------------------------------------+ Figure 3: Deployment model for Small Buildings In either case, interoperability today is only limited to the management network and its protocols. In existing deployment, there are limited interoperability opportunity in the field network due to its nature of non-IP-based design and requirements. 3.4. Use cases and Field Network Requirements In this section, we describe several use cases and corresponding network requirements. 3.4.1. Environmental Monitoring In this use case, LCs measure environmental data (e.g. temperatures, humidity, illuminance, CO2, etc.) from several sensor devices at each measurement interval. LCs keep latest value of each sensor. BMS sends data requests to LCs to collect the latest values, then stores the collected values into a database. Operators check the latest environmental data that are displayed by the HMI. BMS also checks the collected data automatically to notify the operators if a room condition was going to bad (e.g., too hot or cold). The following table lists the field network requirements in which the number of devices in a typical building will be ~100s per LC. Kaneko & Das Expires April 18, 2016 [Page 7] Internet-Draft bas-usecase-detnet October 2015 +----------------------+-------------+ | Metric | Requirement | +----------------------+-------------+ | Measurement interval | 100 msec | | | | | Availability | 99.999 % | +----------------------+-------------+ Table 1: Field Network Requirements for Environmental Monitoring There is a case that BMS sends data requests at each 1 second in order to draw a historical chart of 1 second granularity. Therefore 100 msec measurement interval is sufficient for this use case, because typically 10 times granularity (compared with the interval of data requests) is considered enough accuracy in this use case. A LC needs to measure values of all sensors connected with itself at each measurement interval. Each communication delay in this scenario is not so critical. The important requirement is completing measurements of all sensor values in the specified measurement interval. The availability in this use case is very high (Three 9s). 3.4.2. Fire Detection In the case of fire detection, HMI needs to show a popup window with an alert message within a few seconds after an abnormal state is detected. BMS needs to do some operations if it detects fire. For example, stopping a HVAC, closing fire shutters, and turning on fire sprinklers. The following table describes requirements in which the number of devices in a typical building will be ~10s per LC. +----------------------+---------------+ | Metric | Requirement | +----------------------+---------------+ | Measurement interval | 10s of msec | | | | | Communication delay | < 10s of msec | | | | | Availability | 99.9999 % | +----------------------+---------------+ Table 2: Field Network Requirements for Fire Detection In order to perform the above operation within a few seconds (1 or 2 seconds) after detecting fire, LCs should measure sensor values at a regular interval of less than 10s of msec. If a LC detects an abnormal sensor value, it sends an alarm information to BMS and HMI immediately. BMS then controls HVAC or fire shutters or fire sprinklers. HMI then displays a pop up window and generates the Kaneko & Das Expires April 18, 2016 [Page 8] Internet-Draft bas-usecase-detnet October 2015 alert message. Since the management network does not operate in real time, and software run on BMS or HMI requires 100s of ms, the communication delay should be less than ~10s of msec. The availability in this use case is very high (Four 9s). 3.4.3. Feedback Control Feedback control is used to keep a device state at a certain value. For example, keeping a room temperature at 27 degree Celsius, keeping a water flow rate at 100 L/m and so on. The target device state is normally pre-defined in LCs or provided from BMS or from HMI. In feedback control procedure, a LC repeats the following actions at a regular interval (feedback interval). 1. The LC measures device states of the target device. 2. The LC calculates a control value by considering the measured device state. 3. The LC sends the control value to the target device. The feedback interval highly depends on the characteristics of the device and a target quality of control value. While several tens of milliseconds feedback interval is sufficient to control a valve that regulates a water flow, controlling DC motors requires several milliseconds interval. The following table describes the field network requirements in which the number of devices in a typical building will be ~10s per LC. +----------------------+---------------+ | Metric | Requirement | +----------------------+---------------+ | Feedback interval | ~10ms - 100ms | | | | | Communication delay | < 10s of msec | | | | | Communication jitter | < 1 msec | | | | | Availability | 99.9999 % | +----------------------+---------------+ Table 3: Field Network Requirements for Feedback Control Small communication delay and jitter are required in this use case in order to provide high quality of feedback control. This is currently offered in production environment with hgh availability (Four 9s). Kaneko & Das Expires April 18, 2016 [Page 9] Internet-Draft bas-usecase-detnet October 2015 4. Security Considerations Both network and physical security of BAS are important. While physical security is present in today's deployment, adequate network security and access control are either not implemented or configured properly. This was sufficient in networks while they are isolated and not connected to the IT or other infrastructure networks but when IT and OT (Operational Technology) are connected in the same infrastructure network, network security is essential. The management network being an IP-based network does have the protocols and knobs to enable the network security but in many cases BAS for example, does not use device authentication or encryption for data in transit. On the contrary, many of today's field networks do not provide any security at all. Following are the high level security requirements that the network should provide: o Authentication between management and field devices (both local and remote) o Integrity and data origin authentication of communication data between field and management devices o Confidentiality of data when communicated to a remote device o Availability of network data for normal and disaster scenario 5. IANA Considerations This memo includes no request to IANA. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 6.2. Informative References [bacnetip] ASHRAE, "Annex J to ANSI/ASHRAE 135-1995 - BACnet/IP", January 1999. [knx] KNX Association, "ISO/IEC 14543-3 - KNX", November 2006. Kaneko & Das Expires April 18, 2016 [Page 10] Internet-Draft bas-usecase-detnet October 2015 [lontalk] ECHELON, "LonTalk(R) Protocol Specification Version 3.0", 1994. [modbus] Modbus Organization, "MODBUS APPLICATION PROTOCOL SPECIFICATION V1.1b", December 2006. [profibus] IEC, "IEC 61158 Type 3 - Profibus DP", January 2001. [flnet] Japan Electrical Manufacturers' Association, "JEMA 1479 - English Edition", September 2012. Authors' Addresses Yu Kaneko Toshiba 1 Komukai-Toshiba-cho, Saiwai-ku, Kasasaki-shi Kanagawa, Japan EMail: yu1.kaneko@toshiba.co.jp Subir Das Applied Communication Sciences 150 Mount Airy Road, Basking Ridge New Jersey, 07920, USA EMail: sdas at appcomsci dot com Kaneko & Das Expires April 18, 2016 [Page 11]