Internet DRAFT - draft-bas-usecase-detnet
draft-bas-usecase-detnet
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,
<http://www.rfc-editor.org/info/rfc2119>.
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]
