Enhanced Control Application Development in Building Automation

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 (s) 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 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 and is given. I. INTRODUCTION 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 () dealing with the specific hardware. Traditionally, development is quite a complex task which requires profound expertise. The first time creation of s is highly technical since often low level constructs and detailed knowledge about the underlying control network stack are required. Besides, implementing s is technology specific and therefore s 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 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 s, we present a two level concept which allows development using the standard Java language and the open development platform Eclipse. Section II discusses the concept of the open BAS systems,, 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 and and the description of the test environment. II. CONTROL APPLITIONS IN OPEN BAS Interoperability between s 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. defines the network visible part called object of a single data element. The internal data structure is not covered and thus also the itself and its development are not specified. Each 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 Property Datatype Object-Identifier ObjectIdentifier Object-Name CharacterString Object-Type ObjectType Present-Value REAL Progress-Value REAL Lighting-Cmd LightingCommand Blink-Time Unsigned Off-Delay REAL OPTIONAL Blink-Prior.-Threshold Unsigned OPTIONAL Status-Flags StatusFlags Out-Of-Service BOOLEAN Priority-Array PriorityArray Relinquish-Default REAL 978-1-4244-3760-3/09/$25.00 c 2009 IEEE 390

Priority-Array PriorityArray Relinquish-Default REAL Lighting-Cmd-Prior. Unsigned B. 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 communication service as well as a particular address (e.g., group object datapoints use group addresses and are accessible through group communication services). The function block Light Actuator defines the following datapoints (cf. [5] Part 7/20): Data Point Data Point Type Output: InfoOnOff DPT Switch Input: OnOff DPT Switch Parameter: Timed Duration DPT TimePeriodSec Although the tool software ETS allows customization of s 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 s. 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 s 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 s 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. 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 SNVT Type Output: nvoscene SNVT scene The scene controller delays the switch off command. Network Variable Input: nviscene Input: nvoswitch SCPTdelayTime: ncidelaytime SNVT Type SNVT scene SNVT switch SNVT 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. The 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 s 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 Command Basic Identify On/Off Level Control Move to Level (with On/Off) Cmd. Scenes Groups security has not been covered by the open BAS, either because they only specify the communication protocol and application model (e.g.,, ZigBee) or insufficient mechanisms are deployed (e.g., ETS with insecure access control mechanism for, LNS based tools with no security measures for LonWorks). Advanced security measures like tests for or prevention of malicious behavior of the uploaded are not provided at all. III. THE CONCEPT OF AN INTEGRATED BAS Today s BAS are implemented using various technologies (e.g,,, 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, s are not compatible and the knowledge of 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 concept while the right side presents the proposed one. To remedy this situation this paper presents a framework for developing s for low end (<100 KBytes memory, <25 MHz CPU speed) BAS devices. Application designers 2009 7th IEEE International Conference on Industrial Informatics (INDIN 2009) 391

CMD CMD LonWorks CMD ZigBee CMD IP Backbone CMD Ontology Ontology SAC Sandbox Control Application Enhanced application layer Management API User API Securitymeasures Sandboxing SAC SAC ICD SAC SAC ICD LonWorks ICD ZigBee ICD LonWorks LonWorks SAC LonWorks LonWorks SAC Technology specific Fig. 1. LonWorks ZigBee ZigBee SAC ZigBee ZigBee SAC //LonWorks/ZigBee Control applications in BAS Secure generic with network plugin(s) ICD Generic Multi-protocol SAC Generic // LonWorks/ZigBee SAC shall be supported to allow rapid innovation and implementation, configuration, deployment and execution of arbitrary (uncertified) software. Besides, this possibly erroneous or malicious software shall not compromise the overall system security. Not only security attacks evolving from accidental software faults are to be prevented but also attacks resulting from intentional malicious software. The solution shall be low cost and not require any special hardware modification, thus allowing easy and compatible integration. The idea is to separate the system software (including network stacks) running on the device from the as well as the node configuration. This model encapsulates the system software entities in a way which is inspired by the object-oriented paradigm. It also makes use of a generic ontology, which describes the application behavior and provides relevant configuration parameters [8]. The following list describes the intended advantages the proposed framework provides: The framework supports the use of high-level languages, in particular Java. Thus the desired behavior can be obtained more easily. development is simplified, since the application programmer does not have to cope with details concerning the network protocol or the system software. It can be ensured that all (bus-)communication is standard compliant, even if the developer does not know a particular technology. Since the is separated from the system software, the latter has to be certified only once. Portability of s can be achieved due to their separation from the system software and the network stack. s can only issue a defined set of operations and may not interfere with the system software. Besides, limitations to operations a issues can be enforced by the system software. This eases a possible certification process and also allows to deploy advanced security concepts [9]. Home and building automation (HBA) control tasks can be carried out very flexible and with an adaptable configuration. Information invisible and unaccessible to the can be stored and used on the system (e.g., configuration parameters). Management Data point Application Device Policy Anomally based mapping objects intrusion detection System Software Binary Network Network plugins plugins System System Components Static code analysis Configuration Hardware Abstraction Network interface Process interface Control network Fig. 2. Architecture s being easier to understand are also less error prone. IV. APPROACH To achieve the goal of allowing the easy development of secure s we propose a framework that consists of four main parts (cf. Figure 2): A. System software A simple, tight and secure system software provides controlled access to system resources. It consists of various layers and intends to provide building blocks which can be mixed and matched to support different hardware configurations. Besides, it is designed to maximize code reuse. A change in the combination of the software modules or a change in the hardware design should only require a minimum of modification to the software. It takes care of initialization tasks and manages the available resources of the system. To provide security, the system software is analyzed using human being based inspection, code reviews as well as static code analysis using automated tools. To access the hardware in an independent and modular way at the lowest level, a Hardware Abstraction Layer (HAL) hides the peculiarities of basic I/O handling and on-chip peripherals. It allows to easily deploy the developed software to other MCU architectures allowing flexibility in design and to fulfill the differing resource requirements. Network protocol stacks can be integrated according to the requirements of a particular application. The network plugins handle the mapping of technology specific application models to the generic application objects. Basically they keep the application objects up to date when corresponding network messages are received and trigger network messages when the application object is changed by the. Further system components (e.g., for controlling peripherals) are also located on top of the HAL. B. Enhanced application layer The enhanced application layer stores the application objects, their data point mappings as well as the security policy for the. Any network plugin or system component exclusively interacts with the via these shared objects. Note, that multiple network plugins may be deployed, allowing the design of multi-protocol devices [10]. The security policy defines the normal behavior of the. Any abnormal behavior 392 2009 7th IEEE International Conference on Industrial Informatics (INDIN 2009)

can be detected using anomaly based intrusion detection. Thus, limits to e.g., network or processing resources may be defined, which are enforced at runtime. The user API provides various services to access the application objects (e.g., network access, access to on-chip peripherals such as timers, process interaction). Besides allowing to control the possibilities of a such a generic API also increases portability and compatibility of applications on different platforms and technologies. This way, the s can be kept simple and at the same time can concentrate to perform intended actions, only. The management API interfaces with a management tool, which pre-processes the binary of a as well as its corresponding configuration and allows access to the system software to support the total replacement and download of s. Moreover, this tool allows customization of an application by adapting runtime parameters for the sandbox defined its configuration. C. Sandbox A sandbox executes the in a controlled way and is often used for untrusted programs or untested code with the essential benefit that the system outside the sandbox is protected from (malicious) actions by the. Additionally, the behavior of the program in the sandbox can be monitored and controlled (e.g., via a watchdog). Besides, it is also designed to support the rapid development of s. It interfaces the enhanced application layer and provides a clear abstraction of the underlying hard- and software by providing an object-oriented access to the application objects using the Java programming language. The application designer can thus focus on the application development. This also allows portability of s between devices offering the same sandbox. It is obvious that such a sandbox has to be designed for little memory usage and low overhead. While this approach may at first seem inappropriate for a low-end SAC due to the relatively high resource requirements of such techniques, it offers outstanding possibilities. 1 Besides, the resource requirements can be lowered to a significant extent with the acceptance of certain limitations. The sandbox does not need to support fully fledged programming models, since the desired operations, especially in control tasks, are often quite simple. For such purposes, s more or less consisting of a sequence of simple operations may be sufficient which can be supported by a resource-saving sandboxing implementation. D. Management Tool A management tool is used to configure the parameters of the system software and enhanced application layer and deploy the into the sandbox. Configuration is based on an ontology (cf. Listing 1, [8], [11]), that hosts the technology specific application models (i.e., objects, 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. it provides a mapping of the technology datapoints to the generic datapoints. This way a device specific configuration can reference this knowledge base and provide the necessary additional information such as network address(es) for actually implementing a SAC. Listing 1. Extract of ontology <?xml version="1.0" encoding="utf-8"?> <Ontology xmlns:xsi="http://"> <> <!-- application model --> <Object Name="Lighting-Output" Object_Type=" LIGHTING_OUTPUT"> <Property id="bacnetdp_1" Name="Object_Identifier " Datatype="ObjectIdentifier" /> <Property id="bacnetdp_2" Name="Object_Name" Datatype="CharacterString" /> <Property id="bacnetdp_3" Name="Present_Value" Datatype="REAL" /> </> <> <!-- application model --> <FunctionalBlock ObjectType="417" Name=" FB_Light_Actuator" Title="Light Actuator"> <DataPoints> <Input> <DP id="knxdp_1" Name="OnOff" Abbr="OO" Mandatory="true" Description="To switch the light On/Off" DatapointTypeRef="1.001"/> </> <LonWorks></LonWorks> <!-- LonWorks application model --> <ZigBee></ZigBee> <!-- ZigBee application model --> <Generic> <!-- Generic model --> <ApplicationObject Name="On/Off Light" id="ao1"> <!-- Generic on/off light --> <ProcessDataPoint id="pdp_1" Name="Value"> <!-- Associate technology specific datapoints with generic datapoint --> <DataPoint id="bacnetdp_3" /> <DataPoint id="knxdp_1" /> <LONDataPoint id="londp_1" /> <ZigBeeDataPoint id="zigbeedp_1" /> V. PROTOTYPE 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 and is shown. A. Hardware 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 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

Visual test shell /Ethernet ETS calibur SAC stripboard SAC SAC calibur NanoVM Program storage Java interpreter Control Application Enhanced application layer Management API address adress plugin interface On/Off Light Time System Software DCF77 plugin User API Hardware Abstraction Ethernet interface Policy Output Fig. 3. 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. 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 calibur [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 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 network plugin provides bit stuffing support for controlling the Freebus hardware as well as a TP-UART driver for more simplified network access. Irrelevant to this underlying OSI layer 1/2 the stack offers group communication as well as group object handling (A GroupValue Read, A GroupValue Write, A GroupValue Response) and management communication (A PropertyValue Read, A PropertyValue Write, A PropertyValue Response). In our prototype it has been configured to keep a standard light actuator FB Light Actuator with associated group address synchronized with the generic application object On/Off Light. Likewise the plugin provides access to /Ethernet. It maps the On/Off Light to the Lighting-Output and provides the services 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 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 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 developer and is the only way to interact with the environment. Native Java classes have been defined which form the interface for the. 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 s 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 <?xml version="1.0" encoding="utf-8"?> <DeviceConfig xmlns:devconf="http://"> 394 2009 7th IEEE International Conference on Industrial Informatics (INDIN 2009)

<> <!-- configuration for plugin --> <GroupAddress id="knx_ga1">0/0/1</groupaddress> <! -- define group address --> <FunctionBlock id="417"> <!-- instantiate function block --> <GroupObject id="knx_go1"> <!-- instantiate group object --> <DataPoint dpref="knxdp_1" garef="knx_ga1"/> <!-- bind group address to datapoint --> </GroupObject> <Parameter></Parameter> </FunctionBlock> </> <> <!-- configuration for plugin --> <DeviceAddress id="bada1">192.168.0.1</ DeviceAddress> <!-- define device address --> <Object Name="Lighting-Output" deviceaddress=" bada1"> <!-- instantiate object and bind device address--> <Property Name="Object_Identifier">1</Property> <!-- define object identifier --> <Property Name="Object_Name">Lamp</Property> <!-- define object name --> </Object> </> <Generic> <ApplicationObject id="ao1"> <!-- instantiate generic application object --> <ProcessDataPoint id="pdp_1">1</processdatapoint> <!-- set pdp to on --> 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 calibur (cf. Figure 3). It consists of a /Ethernet line with the Visual test shell (VTS) attached for monitoring as well as sending and receiving service requests and a line with a standard lamp, an actuator and the Engineering Tool Software (ETS). The stripboard has been connected to the line. calibur has additionally been connected to /Ethernet. The system software itself has been compiled and downloaded using the MCU specific toolchain (e.g., avr-gcc and AVR Downloader/UploaDEr, avrdude). s 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 into the sandbox via the serial interface. Listing 4 shows the required 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. CONCLUSION AND FUTURE WORK The presented approach simplifies the development and allows the secure execution of generic and technology independent BAS s. Despite the imposed overhead the concept proofed reasonable and familiarization with BAS 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 itself as well as the ontology it relies on. More complex s 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. REFERENCES [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] 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