Enhanced Control Application Development in ...

Enhanced Control Application Development in Building Automation Fritz Praus, Wolfgang Granzer, Wolfgang Kastner Vienna University of Technology, Automation Systems Group Treitlstrasse 1-3, Vienna, Austria Email: {fpraus,w,k}@auto.tuwien.ac.at Abstract— Building Automation Systems (BAS) lack a common application model. Thus, the development of control applications (CAs) is not a very straightforward task and requires profound expertise. When in addition security has to be considered, inexperienced developers are overwhelmed by the manifold demands and constraints. This paper presents an approach to ease the CA development and at the same time to provide security for their execution. The main idea is to base the application model on a generic ontology and to provide a sandbox for the execution environment. The programming concept, configuration and management issues as well as the workflow are described in detail. Finally, a proof of concept for BACnet and KNX is given.

I. I NTRODUCTION Building Automation Systems (BAS) aim at improving control and management of mechanical and electrical systems in buildings – more generally, interaction among all kinds of devices typically found there. Sensor, Actuators and Controllers (SAC) interact with the physical environment. Interconnection Devices (ICD) link different networks and network segments and Configuration and Management Devices (CMD) are used for engineering and management [1]. While the functionality of ICDs and CMDs is usually fixed, SACs are highly customizable and thus in this domain typically the approach exists to customize generic “template” network nodes with application specific hardware. Universally designed base platforms consisting of microcontrollers (MCUs) and network interfaces are used in conjunction with application specific components (e.g., switches, temperature sensors) to form a particular system. Similarly, the software is split into a generic operating system or system software providing basic functionality and a (customizable) control application (CA) dealing with the specific hardware. Traditionally, CA development is quite a complex task which requires profound expertise. The first time creation of CAs is highly technical since often low level constructs and detailed knowledge about the underlying control network stack are required. Besides, implementing CAs is technology specific and therefore CAs are not compatible between the different technologies. Thus even the design of a simple lighting application with configurable lighting duration provides an unnecessary high barrier for developers. With the ongoing integration of formally stand alone systems, security is getting more and more important [2], [3]. However, it has not been covered at all in open BAS standards. Thus dealing with the indispensable security requirements is left open for the security

c 2009 IEEE 978-1-4244-3760-3/09/$25.00 

unexperienced application developer, who often is not able to cope with manifold threats and attack possibilities. To remedy this situation, allow rapid innovation and ease the implementation of secure CAs, we present a two level concept which allows development using the standard Java language and the open development platform Eclipse. Section II discusses the CA concept of the open BAS systems BACnet, KNX, LonWorks and ZigBee. Section III outlines our proposed concept. A deeper look onto the programming architecture, configuration and management issues as well as the workflow is described in Section IV. Section V presents the developed prototype implementation for BACnet and KNX and the description of the test environment. II. C ONTROL APPLICATIONS IN OPEN BAS Interoperability between CAs is achieved by standardizing the application models. Although trying to fulfill the same BAS tasks, the realization of these models within the various technologies is quite different. In the following a short overview of the application models is given as well as an exemplary description of a minimalistic light actuator with delayed on/off behavior being used for stairway lighting. A. BACnet BACnet defines the network visible part called BACnet object of a single data element. The internal data structure is not covered and thus also the CA itself and its development are not specified. Each BACnet object has a dedicated object type and represents a collection of properties. Each property has a data type defining the size and encoding of the data element. Currently 25 different objects and nearly 200 different property types as well as object access services (e.g., ReadProperty, WriteProperty) are defined. The Lighting-Output Object Type has recently been specified in Addendum i [4]: Property Identifier Object-Identifier Object-Name Object-Type Present-Value Progress-Value Lighting-Cmd Blink-Time Off-Delay Blink-Prior.-Threshold Status-Flags Out-Of-Service Priority-Array Relinquish-Default

390

Property Datatype BACnetObjectIdentifier CharacterString BACnetObjectType REAL REAL BACnetLightingCommand Unsigned REAL OPTIONAL Unsigned OPTIONAL BACnetStatusFlags BOOLEAN BACnetPriorityArray REAL

Priority-Array Relinquish-Default Lighting-Cmd-Prior.

BACnetPriorityArray REAL Unsigned

B. KNX KNX defines application models within the different application domains. Their functionality is distributed across functional blocks which are described by a well-known behavior and consist of one or more datapoints. A single datapoint (i.e., input, output, parameter) represents a single data of the application and has a defined datapoint type which states its format, encoding, range and unit. Each datapoint can be accessed using a specific KNX communication service as well as a particular address (e.g., group object datapoints use group addresses and are accessible through group communication services). The KNX function block Light Actuator defines the following datapoints (cf. [5] Part 7/20): Data Point Output: InfoOnOff Input: OnOff Parameter: Timed Duration

Data Point Type DPT Switch DPT Switch DPT TimePeriodSec

Although the tool software ETS allows customization of CAs developed for Bus Coupling Unit (BCU) 1, Bus Interface Module (BIM) M111, BIM M115, BCU 2 and BIM M113 based devices, their first time creation remains quite complex since the hardware does not provide enough memory for advanced CAs. No toolchain is available, that offers high level programming languages (e.g., C, C++) and the developer has to consider microcontroller specific issues (e.g., RAM flags). The new generation of BIMs (NEC 78K0/Kx2 based) overcomes the hardware limitations and allows development in the C programming language and debugging using the IAR Embedded Workbench. For development of CAs on a separate MCU a TP-UART IC can be used, which handles the physical and most of the data link layer. C. LonWorks LonMark International defines so called standard functional profile templates (SFPTs) for interoperability, which may be generic or application-specific. They include standard network variable types (SNVTs), standard configuration property types (SCPTs), defaults and power-up behaviors. SNVTs are shared by the distributed CAs over the network and represent an exactly defined (e.g., encoding, physical unit), calibrated, filtered and linearized engineering value, which can easily be accessed by the CA. SCPTs are defined and used to access configuration functions within a device (e.g., changing parameters). To implement a light with delayed on/off behavior 3 SFPTs are needed [6]. The scene panel selects a defined scene. Network Variable Output: nvoScene

SNVT Type SNVT scene

The scene controller delays the switch off command. Network Variable Input: nviScene Input: nvoSwitch SCPTdelayTime: nciDelayTime

SNVT SNVT SNVT SNVT

Type scene switch time sec

Finally the lamp actuator controls the light.

Network Variable Input: nviLampValue Output: nvoLampValueFb

SNVT Type SNVT switch SNVT switch

LonWorks nodes are usually based on a network controller (e.g., Neuron series, LC3020) which executes the network protocol stack and the CA. The CA may be implemented in ANSI C or Neuron C, which represent SNVTs as standard C variables with the unique property that a data packet is automatically created and transmitted whenever the value of the C variable changes or is automatically updated whenever a data packet has been received from the network. D. ZigBee ZigBee CAs are implemented by application objects that are distributed across the ZigBee devices. Within the application objects, the functionality is represented by so called clusters which represent a collection of attributes (i.e., single data of the process) and commands to manipulate and interact with them. For interoperability the exact structure of the application objects and their logical device descriptions are defined in application profiles (e.g., [7]). The Dimmable Light device can be used to realize a stairway lighting, although devices may disregard the Transmission time field if not being able to move at a variable rate. Cluster Basic Identify On/Off Level Control Scenes Groups

Command

Move to Level (with On/Off) Cmd.

CA security has not been covered by the open BAS, either because they only specify the communication protocol and application model (e.g., BACnet, ZigBee) or insufficient mechanisms are deployed (e.g., ETS with insecure access control mechanism for KNX, LNS based tools with no security measures for LonWorks). Advanced security measures like tests for or prevention of malicious behavior of the uploaded CA are not provided at all. III. T HE CONCEPT OF AN INTEGRATED BAS Today’s BAS are implemented using various technologies (e.g, BACnet, KNX, LonWorks, ZigBee), each with own benefits and features. Thus, SACs have to be implemented very technology specific and as shown in the previous section, even the concept of a simple light application is different. Moreover, even if fulfilling the same tasks, CAs are not compatible and the knowledge of CA developers in one technology cannot be easily applied to another BAS because of the different network protocol stacks and application models. A traditional deep integration is far from being straightforward, requires the use of gateways and maintenance of huge mapping tables and thus demands research. The left side of the dashed line in Figure 1 shows this traditional CA concept while the right side presents the proposed one. To remedy this situation this paper presents a framework for developing CAs for low end ( [...] [...] [...] [...] < !-- Generic on/off light --> [...]

V. P ROTOTYPE IMPLEMENTATION To demonstrate the feasibility of the presented concept and also describe the components in more detail this section presents our efforts to develop a comprehensive development environment for BAS and its applicability to low-end BAS nodes (i.e., SACs). Our proof-of-concept for BACnet and KNX is shown. A. Hardware

D. Management Tool A management tool is used to configure the parameters of the system software and enhanced application layer and deploy the CA into the sandbox. Configuration is based on an ontology (cf. Listing 1, [8], [11]), that hosts the technology specific application models (i.e., BACnet objects, KNX standardized functional blocks, LonWorks SFPTs, ZigBee objects) as well as a definition of generic application objects. Besides, 1 Sandboxes might even be designed to be capable of executing native BAS code and to allow the integration of already existing applications.

The presented concept has been deployed on two different hardware architectures. A low cost hardware platform based on a stripboard has been assembled [9]. It is on the one hand intended to be powerful enough to handle the presented sandbox approach and control a KNX compliant light (on, off), but on the other hand to stay very small scale and represent the lowest end SAC devices. While it appeared reliable during development and testing of the software running on it, it is not intended for real-life use. We chose an Atmel ATMega168 MCU

2009 7th IEEE International Conference on Industrial Informatics (INDIN 2009)

393

KNXcalibur NanoVM Program storage Java interpreter

Visual test shell BACnet/Ethernet

Control Application Enhanced application layer Management API

KNXcalibur KNX

ETS

User API

On/Off Light KNX address BACnet adress

SAC stripboard KNX SAC KNX SAC

KNX plugin

Time System Software BACnet DCF77 plugin

Policy

Output

Hardware Abstraction KNX interface

Fig. 3.

Ethernet interface

Test environment and software implementation structure

clocked at 8 MHz, featuring 16 KBytes flash, 1 KByte SRAM, 512 Bytes EEPROM and an additional 2048 Bytes external EEPROM as starting point. KNX bus access has been realized using a slightly adapted version (additional series resistor, lowered operation voltage of MCU) of the basic circuit of the Freebus project. As second platform we chose KNXcalibur [1], which is based on the Fujitsu 16 bit MB90330 family MCU with 24 MHz, 24 Kilobytes RAM and 384 KB flash. It provides Ethernet connectivity and connection to KNX with the Siemens TP-UART IC. Via the available pin headers an extension daughterboard has been connected. It provides push buttons, LEDs, switches, a relais, a buzzer and a MAX3471 for RS485 connectivity. In addition the following sensors have been integrated: an HSP15 humidity sensor, a MPX4250 pressure sensor, a NSL19M51 light dependend resistor, an LM335Z analog temperatur sensor, a DS1820 digital temperatur sensor and a DCF77 connector for attaching a FSZ01020 antenna. B. Software The software has been implemented in a highly modular way according to the concept presented before in order to allow flexibility and different hardware configurations (c.f. Figure 3). The main basis for hardware indepentent software modules forms the HAL, which has been implemented in an event based way. Using the HAL it is now possible to implement generic modules. The KNX network plugin provides bit stuffing support for controlling the Freebus hardware as well as a TP-UART driver for more simplified KNX network access. Irrelevant to this underlying OSI layer 1/2 the KNX stack offers KNX group communication as well as group object handling (A GroupValue Read, A GroupValue Response) A GroupValue Write, and management communication (A PropertyValue Read, A PropertyValue Write, A PropertyValue Response). In our prototype it has been configured to keep a standard KNX light actuator FB Light Actuator with associated group address synchronized with the generic application object On/Off Light. Likewise the BACnet plugin provides access to BACnet/Ethernet. It maps the On/Off Light to the BACnet Lighting-Output and provides the services

394

ReadProperty and WriteProperty to manipulate its properties (e.g, PresentValue). Besides, drivers for the sensors mentioned before are contained in the system software within further software modules. The system software also manages and stores configuration parameters and data of the enhanced application layer in nonvolatile memory. For sandboxing the CA the NanoVM was chosen, since a port to the AVR MCU already existed and only a port to Fujitsu MCUs had to be done. The NanoVM offers features such as integer arithmetic, floating point operations, garbage collection, simple application upload and about 20k Java opcodes per second on a 8 MHz AVR. It fetches CA Java bytecode instructions from the program storage, which are then interpreted by the Java interpreter. The instructions may be operations on internal Java variables or calls to user API library methods. The library methods read possible configuration values, execute the designated functions on the hardware platform or communicate with peripherals. The user API forms the main component for the CA developer and is the only way to interact with the environment. Native Java classes have been defined which form the interface for the CA. The NanoVM maps these Java methods and variables to their C implementations, which then access the application objects. Listing 2 shows an extract of how CAs can access a generic (networked) application object or a peripheral. Listing 2. Extract of user API class ApplicationObject { public ProcessDataPoint readValue(); // Reads and returns the current value of the application object from the memory. public void WriteValue(ProcessDataPoint value); // Writes the value of the application object. Automatically triggers network plugins to update their values. public static int led(int led, int value); // 1 turns on LED, 0 off public static int initDCF77(void); // initialize DCF77 public static Date getTime(); // returns current date and time [...]

Configuration of a node is XML based (cf. Listing 3). The integrator just needs to instantiate the desired generic application object(s) and process datapoints using their id attributes and to configure their parameters. Then a configuration of the network plugins has to be provided. Basically, this means binding the datapoints to adresses. Besides, relevant parameters for further system components (e.g., mapping an MCU output pin to the corresponding light) can be set. A configuration tool now can process this configuration file and with the use of the ontology calculate the required mappings of the specific addresses to the generic process data points. Finally this representation is transferred into a suitable binary format and stored in the EEPROM of the target node. Listing 3. Device configuration

2009 7th IEEE International Conference on Industrial Informatics (INDIN 2009)

0/0/1 [...] 192.168.0.1 1 < !-- define object identifier --> Lamp [...] 1 [...]

C. Evaluation Using the stripboard with the Freebus circuit a first evaluation has already been performed. For this detailed discussion on the runtime performance and memory footprint as well as the validation of the security measures refer to [9]. This test environment has been refined and extended with KNXcalibur (cf. Figure 3). It consists of a BACnet/Ethernet line with the Visual test shell (VTS) attached for monitoring as well as sending and receiving BACnet service requests and a KNX line with a standard KNX lamp, an actuator and the Engineering Tool Software (ETS). The stripboard has been connected to the KNX line. KNXcalibur has additionally been connected to BACnet/Ethernet. The system software itself has been compiled and downloaded using the MCU specific toolchain (e.g., avr-gcc and AVR Downloader/UploaDEr, avrdude). CAs may be developed and compiled using standard Java toolchains (e.g., Eclipse SDK and the SunJDK) and utilizing the User API. XML device configuration files currently have to be written by hand. The configuration tool (NanoVMTool) is being used to prepare the compiled class files, which includes stripping unnecessary and unsupported instructions from the binary as well as mapping native Java library calls to their corresponding implementations in C. Besides, the NanoVMTool has been extended to provide functionality for parsing the XML based configuration file and changing application parameters. Finally it is used to upload the CA into the sandbox via the serial interface. Listing 4 shows the required CA to control a light (On/Off

Light). A node configuration defining the required application object and parameters is assumed (like in Listing 3). Listing 4. Simple lighting application import nanovm.UserAPI.*; class GroupObjects { ApplicationObject ao1=new ApplicationObject("ao1"); // configuration is automatically read using the id "ao1" public static void main(String[] args) { ProcessDataPoint pdp = new ProcessDataPoint(); // temporary pdp while(true) { if (!pdp.equals(ao1.readValue())) { // if pdp has changed pdp = ao1.readValue(); // read its value io.led(1,pdp.intValue()); // switch lamp [...]

VI. C ONCLUSION AND FUTURE WORK The presented approach simplifies the CA development and allows the secure execution of generic and technology independent BAS CAs. Despite the imposed overhead the concept proofed reasonable and familiarization with BAS CA development is eased due to the help of a clean user API and the use of standard Java language, thus allowing a rapid development, even for inexperienced users. Admittedly the prototype is quite simple. This includes the CA itself as well as the ontology it relies on. More complex CAs will be implemented in future work to demonstrate that the framework is mostly limited by the available memory and processing power. The creation of the required ontologies including possible security policies is a very laborious and error-prone task, which definitively needs further investigation. ACKNOWLEDGMENT The work presented in this paper was funded by FWF (Austrian Science Foundation) under the project P19673.

R EFERENCES [1] W. Granzer, W. Kastner, G. Neugschwandtner, and F. Praus, “A Modular Architecture for Building Automation Systems,” in Proc. 6th IEEE WFCS, Jun. 2006, pp. 99–102. [2] D. Hwang, P. Schaumont, K. Tiri, and I. Verbauwhede, “Securing embedded systems,” IEEE Security & Privacy Magazine, vol. 4, no. 2, pp. 40–49, 2006. [3] S. Ravi, A. Raghunathan, P. Kocher, and S. Hattangady, “Security in embedded systems: Design challenges,” Trans. on Embedded Computing Sys., vol. 3, no. 3, pp. 461–491, 2004. [4] “BSR/ASHRAE Add. i to ANSI/ASHRAE Standard 135-2004,” March 2008, second Public Review Draft. [5] “KNX specification,” Konnex Association, 2004. [6] LonMark Functional Profiles: Lamp Actuator: 3040, Scene Controller: 3251, Scene Panel: 3250, LonMark International, 1997. [7] ZigBee Home Automation Public Application Profile, ZigBee Alliance, 2007. [8] C. Reinisch, W. Granzer, F. Praus, and W. Kastner, “Integration of Heterogeneous Building Automation Systems using Ontologies,” in Proc. 34th IEEE IECON, Nov. 2008, pp. 2736–2741. [9] F. Praus, T. Flanitzer, and W. Kastner, “Secure and customizable software applications in embedded networks,” in Proc. 13th IEEE ETFA, 2008, pp. 1473–1480. [10] S. Soucek and D. Loy, “Vertical Integration in Building Automation Systems,” in Proc. 5th IEEE INDIN, June 2007, pp. 81–86. [11] D. Fensel, H. Lausen, A. Polleres, J. de Bruijn, M. Stollberg, D. Roman, and J. Dominque, Enabling Semantic Web Services, 1st ed. Springer, 2007, ch. 3.

2009 7th IEEE International Conference on Industrial Informatics (INDIN 2009)

395