[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/