KNX Scientific Conference

Transcription

1 KNX Scientific Conference Environment control platform based on KNX and NFC technologies to support independent daily life Pamplona 4 th 5 th November

2 Table of Contents Introduction Who are we? Objectives Why? Platform architecture What? Development tools How? Use cases When? Evaluation Closure Conclusion Ending

3 > Who are we? Introduction

4 > Why? Objectives Problem Life expectancy and ageing population Direct relationship between ageing population and some disabilities New interaction mechanisms with home automation standards are necessary Scientific basis Ambient Intelligence (AmI) Ambient Assisted Living (AAL) Goal Design a platform to allow elderly people and persons with certain disabilities enjoy a new experience when interacting with ordinary devices and home appliances Basic requirements Easy to use: learning cost must be inexistent or very low Accessible: devices should be usable by the target users Useful: services must provide an improvement in the quality of life of the users Attractive: users should find only benefits in the use of the tools Technologically feasible and scalable: the result system must be ready to be installed avoiding deep changes

5 > What? Platform architecture Near Field Communication (NFC) Short-range wireless connectivity technology Based on RFID kbps Distance from 0 to 20 cm Helps people receiving and sharing information Bluetooth Wireless technology Mbps Distance from 10 to 100 meters The Bluetooth signal is able to penetrate solid objects Doesn t require line of sight between devices KNX Worldwide standard Home and building automation Several transmission mediums: twisted pair, radio frequency, power line and ethernet Guarantees interoperability and interworking between different devices Independent from any hardware and software technology

6 > How? Development tools Software tools Eclipse IDE for Java developers Java TM 2 platform Standard Edition development kit (J2SE) Java TM platform Micro Edition (J2ME) Java TM APIs 1.1 for Bluetooth ProSyst mbs Smart Home ETS-3 Nokia Connectivity Framework 1.2 Hardware tools MIFARE 1k and MIFARE 4k (NFC smart tags) Mobile phone Nokia 6131 Bluetooth dongle with JSR 82 stack Smart card reader ACR122 Tira 2.1 (bidirectional USB/IR adapter) KNX home automation network (sensors and actuators)

7 > When? Use cases Aim Success Scenario 1: IR appliances control Solve the inaccessibility and the absence of real switches at some home locations Installing NFC smart tags we can reduce risk, hazards or uncomfortable situations

8 > When? Use cases Aim Success Scenario 2: Scene management (1/5) Eliminate repetitive tasks on user s daily life Objects in the real world could be associated with actions in home automation networks ( the homeautomation of things )

9 > When? Use cases Aim Success Scenario 2: Scene management (2/5) Eliminate repetitive tasks on user s daily life Objects in the real world could be associated with actions in home automation networks ( the homeautomation of things )

10 > When? Use cases Aim Success Scenario 2: Scene management (3/5) Eliminate repetitive tasks on user s daily life Objects in the real world could be associated with actions in home automation networks ( the homeautomation of things )

11 > When? Use cases Aim Success Scenario 2: Scene management (4/5) Eliminate repetitive tasks on user s daily life Objects in the real world could be associated with actions in home automation networks ( the homeautomation of things )

12 > When? Use cases Aim Success Scenario 2: Scene management (5/5) Eliminate repetitive tasks on user s daily life Objects in the real world could be associated with actions in home automation networks ( the homeautomation of things ) Scene name At home Traditional scene trigger A presence or movement sensor detects the user/the user presses a button Advanced scene trigger The keys are placed into the key basket Ready to read The user presses a button The user picks up a book from the bookcase Goodbye The user presses a button A smart tag is touched by a mobile phone Go to sleep The user presses a button A mobile phone is placed into the night table

13 > When? Use cases Aim Success Scenario 3: Contextual lighting Users with severe disabilities couldn t access easily to home automation systems Universal switches (on/off/dim) could be developed combining SpheraOne TM indoor location system and NFC tags

14 > Closure Evaluation Users review Nursing home in Alicante May people between 60 at 74 years old Interaction paradigm with NFC technology Questionnaire based on Likert scale (efficiency, easiness of use, easiness to learn, benefits and emotional response) Users were really impressed: able to use and understand it without any learning process Technical review Done by qualified persons in the CIAmI Living Lab Adaptable and accessible infrastructure Intelligent space for testing technological prototypes with real users All proposed scenarios are permanently available

15 > Ending Conclusion Advantages System based on mature and robustness technologies Final solution could be used by non technical persons with a low learning curve Objects in the real world could be associated with actions in home automation networks The development tools (hardware and software) are available in the market at low cost Users were really impressed: able to use it and understand it without any learning process Disadvantages NFC is not a widely adopted technology in the market A computer with a logical algorithm is required Elderly people don t like carry on electronic devices A technical person is needed for burning the instructions commands into each one NFC tag

16 > Ending Conclusion At the present, the interaction way with home automation systems is poor, non natural and is an important handicap to many people (elderly users and persons with several disabilities)

17 > Thank you! Juan-Pablo Lázaro-Ramos Miguel-Ángel Llorente-Carmona Ángel Martínez-Cavero Chief Scientific Officer R&D Department s.es Researcher R&D Department as.es Researcher R&D Department gias.es Tecnologías para la Salud y el Bienestar Instituto ITACA Universidad Politécnica de Valencia Edificio 8G Camino de Vera s/n (Valencia, Spain) Telephone number: Fax number: Soluciones Tecnológicas para la Salud y el Bienestar S.A Ronda Auguste & Louis Lumiere 23, Nave 13 Parque Tecnológico de Valencia Paterna Valencia Spain Telephone number: Fax number:

18 Environment control platform based on KNX and NFC technologies to support independent daily life Miguel-Ángel Llorente-Carmona 1, Ángel Martínez-Cavero 1, Juan-Pablo Lázaro-Ramos 1 (1) TSB Tecnologías para la Salud y el Bienestar S.A. Ronda Auguste y Louis Lumiere 23, Nave Parque Tecnológico de Valencia , Paterna. Valencia (Spain) {mllorente, amartinez, jplazaro}@tsbtecnologias.es Keywords Ambient Assisted Living, Human Computer interface, Independent living, Ambient Intelligence Abstract The use of Information and Communication Technologies (ICT) in the social services as in Ambient Assisted Living (AAL) applications is a new step in the improvement of the quality of life and the independent living of elderly people. A rich application is presented to support the environment control in smart homes using an easy human-computer interface based on Near Field Communication (NFC) technology combined with the KNX worldwide standard for home automation. The easy interaction mechanisms that NFC technology provides combined with a reliable communication infrastructure distributed at home, creates a new bunch of innovative applications that will help to facilitate daily life to elderly people as well as facilitate the use of technology to achieve their objectives. 1. Introduction This paper describes a platform that is designed to allow that elderly people and people with certain disabilities enjoy of a new experience when interacting with ordinary devices and appliances at home. First, it is presented the list of basic requirements that have guided the work. In the next chapter it is described the architecture of the platform and how the workflows between the different technologies are coordinated to improve users experiences. After that, three scenarios have been implemented in order to demonstrate the capacity of the platform thanks to the combination of NFC, KNX and Bluetooth. Finally, the different scenarios have been tested and evaluated with real elderly users who have been participating in different evaluation activities providing feedback and opportunities for improvement according to their requirements and critical point of view. 2. Objectives The main purpose of this work is the creation of a platform in order to build different services oriented to support activities of daily living (ADL) of elderly people or impaired users at home by making more accessible the conventional KNX home automation systems. The list of basic requirements of the platform is:

19 Easy-to-use: the learning costs must be very low or inexistent to enable all kind of users the use of the KNX system at home. Accessible: devices should be usable by the target users (icons or messages must be readable, feedback sounds must be played loudly enough, etc). Useful: services must provide an improvement in the quality of life of the users extending the range of ADL they are able to do and decreasing the dependence with other people. Attractive: users should find only benefits in the use of the tools. Any inconvenient or difficulty could decrease the interest of them in its use. Technologically feasible and scalable: the new systems must be also ready to be installed in the houses with a previous KNX network avoiding deep changes on it. 3. Platform architecture The platform architecture defines the required technological hardware components and the internal information flow exchange that will allow the successful implementation of the overall AAL proposed platforms and applications or services. The right-hand side figure shows that there are several standard technologies that work together with KNX systems in order to ensure the right performance of the system: systems or energy management, for instance. The KNX standard recognizes twisted pair, radio frequency, power line or Ethernet like transmission medium to communicate with all installed devices. One of the most important things about this system is that the human-computer interface is greatly simplified. A number of smart tags are distributed over the user s home and each one is assigned with a certain desired functionality. For instance, one tag can be used to switch on/off or dimming lamps; another one to up and down blinds or another one to run full scenes that involve different devices from several KNX lines. The system could be formed by a lot of tags but it is necessary that each one has its own functionality (it isn t possible to use the same tag for more than one functionality). When users want to interact with the system they just have to touch a tag with a NFC-enabled mobile phone. Then a J2ME application running in background mode in the terminal pops up and reads automatically the command or commands previously burned in the tag. At this point it is important to note that the application runs automatically without users intervention (they don t need to start anything by accessing through the complex mobile phone menu). After this, data are sent to a computer (located anywhere at users home) via the Bluetooth channel. Finally, the required action is transmitted to the KNX network from the computer using any USB/KNX interface available nowadays in the market. Near Field Communication (NFC) [1] is a short range wireless connectivity technology based on RFID (Radio Frequency Identification) that operates at MHz and it is able to transfer data at up 424 kbits/s over a distance from 0 to 20 centimeters. NFC simplifies the way consumer devices interact with one other and helps people receiving and sharing information. Bluetooth [2] is a wireless technology that operates at 2.4 GHz over a distance of 10 or 100 meters with a peak data rate nearly 3 Mbps depending on the device class employed. The Bluetooth signal is able to penetrate solid objects and doesn t require line of sight positioning between the transmitter and receiver devices. KNX [3] is a worldwide standard for home and building automation able to offer comfort and versatility in the management of air-conditioning, lighting, access control, monitoring and security Figure 1 Real system architecture

20 4.2. Hardware tools 4. Development tools Develop and install any ICT system in general and AAL system in particular requires a series of complex tools and our proposal is not an exception. For this reason, we describe all the tools (software and hardware) employed by us to make possible the service described in the paper Software tools The software tools required to develop the full application are listed below: Eclipse IDE for Java developers [4] is an open source integrated development environment comprised of frameworks and tools for building, deploying and managing software. Java TM 2 platform Standard Edition development kit (J2SE 1.5.0) [5] to develop the Java application running in the computer side (between the mobile phone and the KNX network). Java TM platform Micro Edition (J2ME) [5] provides a robust and flexible environment for applications running on embedded devices like mobile phones. Java APIs 1.1 for Bluetooth [5] (optional library of the above package) involves the Bluetooth and OBEX (Object Exchange Protocol) code required by JSR 82. ProSyst s mbs Smart Home [6] provides a full catalogue of Java TM APIs to interact with the most important home automation standards currently available (Zigbee, KNX or X10, for instance). ETS [3] is the software to design, configure and maintain smart homes and building control installations made with the KNX system. The ETS 3 Professional version was employed by us to identify the physical and group addresses of all sensors and actuators available in the KNX network. Nokia Connectivity Framework 1.2 [7] is a tool to visualize, construct and test environments that utilize Nokia SDK emulators. This tool is used to test and emulate in a computer platform the application that runs inside the mobile phone. The hardware tools required to develop the full application are listed below: MIFARE 1k and MIFARE 4k [8] are the two kinds of NFC smart tags used in our AAL development provided by MIFARE Company. Nokia 6131 is the mobile phone chosen by us with NFC and Bluetooth capabilities. This terminal uses the JSR 257 (set of APIs for proximity and contactless based communication). A Bluetooth dongle to receive and send information between the mobile phone and the KNX network if our computer hasn t Bluetooth features. There are a lot of available alternatives on the market at low cost nowadays (the only requirement is that this additional dongle must implement the JSR 82 stack). A full network of KNX sensors and actuators installed at the users home (the higher number of devices available the better the services work). ACR122 [9] is a standard NFC smart card reader that supports the most important NFC tags available in the market. This device has been used to build rich scenarios that involve daily objects to launch the scenes. Tira 2.1 [10] is a bidirectional USB/IR adapter that can send and receive signals to/from remote controls. This device could control a lot of home appliances sending IR signals. 5. Use cases In this section we will analyze different use cases that make sense to the AAL services proposed in this technical paper. As we can see, the same service will be exploited in several scenarios for users with different degrees of needs Scenario 1: IR appliances control This first scenario is intended to solve the inaccessibility and the absence of real switches or push-buttons at some home locations. With a low number of smart tags installed near the user location, we can reduce risk, hazards or uncomfortable situations. The figure below shows how adding a NFC smart tag into the sofa s arm a conventional television can be controlled. If the user wants to turn on the television,

21 touches the corresponding tag with his/her mobile phone. Then, a loop appears at the phone s display asking what action he/she wants to do: on or off. When the display shows the user desired action, he/she distances the terminal from the tag and a phone s buzzing means that an IR signal will be send to the television. wants to leave home touches this tag with his/her mobile phone and all lights and non critical home appliances (the television or the radio if applicable, for instance) will be turned off and a SMS will be sent to a familiar caregiver to inform that the elderly user is now away home. Go to sleep scene. A smart tag with a size easily visible for elderly people is stuck into the bedside table. When the user goes to the bed, he/she puts his/her mobile phone on top of the NFC tag and automatically all lights and the television will be turned off. Figure 2 - Turning OF/OFF a TV with NFC tags 5.2. Scenario 2: Scene management A scene in the home automation world is defined as an iterative function sequence that helps the user to eliminate routine and repetitive tasks on his/her daily life pressing a simple button. Using NFC tags in real environments adds more capabilities to enrich the traditional scenes available nowadays in the market and opens a new range of possibilities for interacting with the system thanks to enhanced interaction devices. The most important thing about these interaction devices is that is not necessary to employ an expensive touch panel or a new generation of KNX switches to launch the scene, the user only has to concentrate on what he/she really wants to do in a natural way: I m at home scene. The elderly user arrives at home and put his keys into a key basket located in the hall. Thanks to a NFC reader hidden under the key basket when the user places his/her keys on it the scene is automatically launched: the hall lights will be turned on, on the radio will sound a welcome nice song and a SMS will be sent to a familiar caregiver to inform that the elderly user is now at home. Ready to read scene. A smart tag is stuck on the back cover of a book. When the user wants to read a book, picks up one of them from his/her bookcase and sits on his/her sofa. After this, the living room lights dim its brightness until a favorable value appropriate for reading the book. Goodbye scene. A NFC tag is located near the door at a suitable height. When the elderly user Scene name At home Ready to read Goodbye Go to sleep Traditional scene trigger A presence or movement sensor detects the user/the user presses a button The user presses a button The user presses a button The user presses a button Advanced scene trigger The keys are placed into the key basket The user picks up a book from the bookcase A smart tag is touched by a mobile phone A mobile phone is placed into the night table Table 1 - Traditional scene trigger vs advanced scene trigger 5.3. Scenario 3: Contextual lightning At the present, there is an innovative technology with a huge potential at home environments based on indoor location systems that will design and develop a new group of emerging applications. This new kind of services will improve the existing home automation installations because the users will be identified and located by the intelligence of the system all the time. Although this feature will be a non ethical policy (direct attack on his/her privacy) for some users for others like elderly people o persons with several or moderate disabilities could be the only way to access to these smart systems. The brand product available nowadays in the market chosen by us to develop this scenario is the SpheraOne TM system owned by TSB Tecnologías para la Salud y el Bienestar S.A [11]. SpheraOne TM is a technology that enables creating localization, identification and tracking applications that can be used to monitor people at indoors spaces in a safety, precise and efficient way. The SpheraOne TM system works automatically through the installation of location system beacons in any given area. Meanwhile, each person to be monitored wears a

22 bracelet which serves to identify, locate and trace them at all times. Combining this indoor location system with a smart tag carried on a wheelchair we could develop universal on, off or dim switches in an easy way. The system knows the user location and touching the NFC tag (stuck in the arm s wheelchair, for instance) he/she could interact with the right lamp. the realization of the activities, identifying the most important users impressions in order to look for potential improvements of the service. Most users were really impressed about the unexpected good performance of the technology so that they are able to use it, understand it and benefit for it, without any learning process with the exception of some words to explain them the basic principles of work. Figure 4 - NFC user s evaluation Figure 3 - Indoor location system with NFC tags 5. Evaluation To demonstrate the real effectiveness and efficiency of all AAL scenarios previously defined by us is needed to do an evaluation from two complementary points of view: users and a technical review. In the first of them the full system is built, installed in an environment similar to its final location and tested with target users. At the end, an important feedback is obtained by developers to improve the final design. Although all the AAL scenarios suggested in this paper couldn t been tested by real users the interaction paradigm with NFC technology has been validated by real elderly users in a Spanish nursing home. During the last week of May 2009 the usability of a NFC technology was tested by a group of users in Old People s Care Centre of San Vicente del Raspeig municipality (Alicante, Spain). Up to 14 people between 60 at 74 years old participated in this experiment. The test consisted in the realization of a number of tasks using one test application provided running in the NFC mobile phone. In order to classify the results of the experiment, a questionnaire was defined based on Likert scale. It consists on a 5 points assessment scale where 5 means totally in agreement and 1 means totally in disagreement. Each question is connected to one of the main classifiers that define the user experience: efficiency, easiness of use, easiness to learn, benefits and emotional response. Calculating the average of the obtained answers, it is possible to obtain the rate that the service has got in each of the basic usability aspects. Apart from the objective results, several interviews took place during On the other hand, the technical review has been done by qualified persons in the CIAmI Living Lab. The CIAmI Living Lab [12] is an adaptable and accessible infrastructure that combines on one hand the simulation of a living space where anyone could live in total comfort and safety and on the other hand, integrated technologies hidden into the physical environment. Its purpose is to provide an intelligent space for testing technological prototypes with their potential users in real conditions. All proposed scenarios are permanently available in this living laboratory. 6. Conclusion In this technical paper we have reviewed a new way to interact with the KNX home and building automation installations specially oriented to elderly people and persons with some disabilities. Despite of there are a lot of devices (sensors, actuators and gateways between different technologies) available to home automation installers in the manufacturers catalogs the list of them related with the interaction part are limited, unattractive and inaccessible for those users who really could be benefit for the use of smart systems at home. Little displays with low resolution, technologically obsolete and fixed wall touch panels and small portable computers with high capabilities but too expensive are all the possibilities we can find in the market nowadays. For this reason, is very important for all population guarantees that the next generations of home automation devices ensure an easy interaction between all equipment present in an installation in a natural and intuitive way.

23 As we can see in the figure labeled as Real system architecture (figure 1) we propose an innovative system to solve this problem providing a reasonable alternative. The more important advantages of this proposal architecture are: Elderly people don t like carry on electronic devices like mobile phones at home. A simple solution could be replacing this interaction device by a smart bracelet or something similar with NFC and KNX capabilities. The system is based on three mature and robustness technologies with low cost. The final solution could be used by non technical persons with a low learning curve. Using high technological devices for interaction and computing allows to define more complex scenarios with full standards compatibility (additional sensors, communications networks and gadgets could be integrated). The full architecture has a high degree of innovation because we could associate objects in the real world with actions in the home automation network ( the home-automation of things ). The software and hardware tools required to build this kind of AAL scenarios are available in the market at low cost. A person with a technical profile is needed for burning the instructions command into each one NFC tag and doing the computer s maintenance. For all these reasons we can conclude that this is a service platform really useful for elderly people and persons with several disabilities. At the present, there are home automation installations with a huge quantity of sensors to measure an enormous variety of parameters and actuators to control any home equipment but the interaction way with these systems is poor, non natural and is an important handicap to many people. However, the creation of a short-term brand product would be very difficult because there are a lot of different technologies involved in the AAL services and the real needs of each user are completely different of the rest of other users. 7. References For launching scenes it is not necessary additional tasks by the user (he/she only needs to do that he/she wants to do: nothing else). There are many technologies and electronic gadgets appropriate to work in home environments that can allow the development of rich scenarios (the only limit is our imagination). On the other hand, the more important disadvantages are: NFC is not a widely adopted technology in the market. This is the most important problem because this implies that there are few mobile phones (or other devices with similar features ready to interact with the system) with the NFC profile enabled. Although this is a huge disadvantage we must consider the Nokia s announce [13] that said all its mobile phones will be NFC compatibles in the next year (2011). [1] NFC Forum (accessed in October, 2010) [2] Official Bluetooth info site (accessed in October, 2010) [3] KNX Association (accessed in October, 2010) [4] Eclipse (accessed in October, 2010) [5] Oracle (accessed in October, 2010) [6] Prosyst (accessed in October, 2010) [7] Forum Nokia (accessed in October, 2010) A computer with a logical algorithm is required to interact with the home automation network (sends/receive KNX frames thanks to an USB/KNX adapter). This component could work without a display and doesn t requires a high performance. [8] Mifare (accessed in October, 2010) [9] ACR card reader (accessed in October, 2010)

24 [10] HOME electronics (accessed in October, 2010) [11] TSB Tecnologías para la Salud y el Bienestar S.A (accessed in October, 2010) [12] CIAmI Living Lab (accessed in October, 2010) [13] Nokia s announce (accessed in October, 2010) Acknowledgement The AAL service presented here has been tested in the CIAmI Living Lab which has been developed under the Plan Avanza framework (2007) of the Ministry of Industry, Tourism and Commerce (Spain). The authors wish to acknowledge the Spanish Ministry for their support.

25 LIGHTING MANAGEMENT SYSTEM USING KNX IN THE REMOTE LABORATORY OF AUTOMATIC CONTROL AT THE UNIVERSITY OF LEÓN Manuel Domínguez, Juan José Fuertes, Perfecto Reguera, Serafín Alonso, Antonio Morán. Instituto de Automática y Fabricación. Aŕea de Automática y Control (AAC-IAF). Universidad de León. KNX Conference, 05 September 2010 A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

26 Outline 1 Introduction 2 LRA-ULE 3 Lighting System 4 Operation Modes 5 Study of Energy Saving 6 Conclusions A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

27 Introduction Energy efficiency is a priority in modern societies where available resources are limited and demanded comfort increases exponentially A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

28 Introduction Energy efficiency is a priority in modern societies where available resources are limited and demanded comfort increases exponentially One of the main factors for better energy efficiency in a building, is the effective management of lighting system. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

29 Introduction Energy efficiency is a priority in modern societies where available resources are limited and demanded comfort increases exponentially One of the main factors for better energy efficiency in a building, is the effective management of lighting system. To reduce the energy consumption in the laboratory an autonomous lighting system has been implemented. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

30 Introduction Energy efficiency is a priority in modern societies where available resources are limited and demanded comfort increases exponentially One of the main factors for better energy efficiency in a building, is the effective management of lighting system. To reduce the energy consumption in the laboratory an autonomous lighting system has been implemented. The new system has to be compatible with the structure of the remote laboratory of the University of León. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

31 Introduction Energy efficiency is a priority in modern societies where available resources are limited and demanded comfort increases exponentially One of the main factors for better energy efficiency in a building, is the effective management of lighting system. To reduce the energy consumption in the laboratory an autonomous lighting system has been implemented. The new system has to be compatible with the structure of the remote laboratory of the University of León. The use of KNX and DALI protocols has produced a system which is efficient, simple, open and easy to integrate into the laboratory architecture. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

32 Remote Laboratory of Automatic Control The Remote Laboratory of Automatic Control (LRA-ULE) is a Remote Laboratory for teaching and training through the Internet using different industrial equipment ( The architecture is based on a 3-layer structure: A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

33 Remote Laboratory of Automatic Control The Remote Laboratory of Automatic Control (LRA-ULE) is a Remote Laboratory for teaching and training through the Internet using different industrial equipment ( The architecture is based on a 3-layer structure: Physical Layer Three industrial scale models. A 4-tank scale model. An industrial pilot plant. An ABB robot. A electro-pneumatic cell. An AC motor-drive group. A Feedback DC motor. A KNX-EIB domotic panel. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

34 Remote Laboratory of Automatic Control The Remote Laboratory of Automatic Control (LRA-ULE) is a Remote Laboratory for teaching and training through the Internet using different industrial equipment ( The architecture is based on a 3-layer structure: Physical Layer Three industrial scale models. A 4-tank scale model. An industrial pilot plant. An ABB robot. A electro-pneumatic cell. An AC motor-drive group. A Feedback DC motor. A KNX-EIB domotic panel. Server Layer Four servers to Internet access: Web Server. Proxy Server. Controller Server. Database Server. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

35 Remote Laboratory of Automatic Control The Remote Laboratory of Automatic Control (LRA-ULE) is a Remote Laboratory for teaching and training through the Internet using different industrial equipment ( The architecture is based on a 3-layer structure: Physical Layer Three industrial scale models. A 4-tank scale model. An industrial pilot plant. An ABB robot. A electro-pneumatic cell. An AC motor-drive group. A Feedback DC motor. A KNX-EIB domotic panel. Server Layer Four servers to Internet access: Web Server. Proxy Server. Controller Server. Database Server. Client Layer Remote users access to the LRA using a common web browser. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

36 LRA-ULE Architecture A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

37 Lighting System Architecture Tow communication buses are used: KNX (Konnex) was chosen due to its popularity in Europe. DALI (Digital Addressable Lighting Ingerface) because of its use in lighting system and its minimal wiring. DALI controls the lamps and KNX is in charge of the management, control monitoring and maintenance of the complete system. A KNX-DALI gateway and a IP-KNX gateway are needed to connect the buses and networks. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

38 Lighting System Architecture DALI interconnects all electronic ballasts and KNX the rest of the domotic equipment. A.Mora n (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

39 Lighting System Integration Several possibilities for the integration were studied. OPC OPC Server based on the Falcon libaries. A well known structure in our laboratory. Non-free. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

40 Lighting System Integration Several possibilities for the integration were studied. OPC OPC Server based on the Falcon libaries. A well known structure in our laboratory. Non-free. Calimero A library developed in Java. The libraries are free. Require a great code development in order to be used in a web browser. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

41 Lighting System Integration Several possibilities for the integration were studied. OPC OPC Server based on the Falcon libaries. A well known structure in our laboratory. Non-free. Calimero A library developed in Java. The libraries are free. Require a great code development in order to be used in a web browser. EIBnetmux A free software for Linux. Multiple simultaneous connections to the IP-KNX. A high-level programming interface based on PHP language. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

42 EIBnetmux Client applications can communicate using a protocol based on TCP/IP sockets. Also supports KNXnet/IP protocol based on UDP used by ETS Remote programming. PHP libraries have been used in order to link to the CMS. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

43 Operation Modes Local Mode Lamps are controlled by means of push-buttons or by a control loop, similar to the traditional way. Two types: Manual: Lamps are controlled directly from the switch. Automatic: Ballasts receive a control action calculated according to a setpoint and the lighting level measured. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

44 Operation Modes Local Mode Lamps are controlled by means of push-buttons or by a control loop, similar to the traditional way. Two types: Manual: Lamps are controlled directly from the switch. Automatic: Ballasts receive a control action calculated according to a setpoint and the lighting level measured. Remote Mode Lamps are controlled and monitorized through the Internet. Two ways were implemented: Via Web: Access through the content management system (Drupal) of the laboratory. Via iphone: Access through an application for iphone called Open Remote iknx. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

45 Local Mode Manual Mode A 8-key push-button controls the light of the laboratory. Each button has a function needed in classroom practices. In order to avoid conflicts the automatic mode has to be turned off. Key Key 1 Key 2 Key 3 Key 4 Key 5 Key 6 Key 7 Key 8 Function local or automatic mode Switching on/off and dimming G7 Switching on/off and dimming G8 Maximum lighting Medium lighting Minimum lighting Projection Switching off all A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

46 Local Mode Automatic Mode Default operation mode of the lighting system. A PI regulates the ballast according to the setpoint and the light level measured. Also, the sensor takes into account the people presence in the room. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

47 Remote Mode Via Web Access to the lighting system via web page based on Drupal. A set of rules switch on the corresponding lamps depending on the system accessed. After logging out the initial state is restored. A.Mora n (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

48 Remote Mode Via iphone Due to the use of the iphone, it has been decided to integrate the Open Remote iknx The free version allows one tho create quickly a control and monitoring system for a KNX installation. Only requires the configuration of a database and a user interface. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

49 Study of Energy Saving Evolution of the lighting and dimming level in a laboratory. The average dimming level is around 75 %. The energy saving is 15 %. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

50 Conclusions Conclusions The system guarantees a correct lighting of the laboratory during remote practices. The control loop adjust continuously the lighting level during classroom practices. The users can also control and monitor the system via web or iphone. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

51 Conclusions Conclusions The system guarantees a correct lighting of the laboratory during remote practices. The control loop adjust continuously the lighting level during classroom practices. The users can also control and monitor the system via web or iphone. Future Work A friendlier and easier graphical interface will be developed. Verify the real energy saving and compare it with the theoretical one. Use this system with modern control techniques to reduce the energy consumption in a public building. A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

52 THANKS FOR YOUR ATTENTION A.Morán (AAC-IAF) Lighting management in LRA-ULE KNX Conference / 17

53 LIGHTING MANAGEMENT SYSTEM USING KNX IN THE REMOTE LABORATORY OF AUTOMATIC CONTROL AT THE UNIVERSITY OF LEON Manuel Domínguez, Juan José Fuertes, Perfecto Reguera, Serafín Alonso, Antonio Morán. Instituto de Automática y Fabricación. Aŕea de Automática y Control (AAC-IAF). Universidad de León. Edificio Tecnológico de Ingenierías. Campus de Vegazana LEON. [email protected], Abstract This paper presents a system for managing lighting in the Remote Laboratory of Automatic Control at the University Leon (LRA-ULE). The architecture of this system is based on two open, simple and flexible protocols, such as KNX and DALI. Their advanced features allow us an easy and fast integration into the technological platform of the laboratory. It provides a local operation mode with a lighting control (manual or automatic) in each room of the laboratory. It also can be operated remotely by a web interface developed inside a Content Management System based on Drupal software package or iphone application. In addition, the system guarantees correct lighting in all physical equipment in the laboratory during the time which a remote user is connected. Finally, a study of energy saving checks the improvement of energy efficiency in the laboratory. Key words: Lighting management, energy efficiency, electronic ballast, home & building automation, KNX protocol, DALI protocol, remote control and monitoring. 1 INTRODUCTION Energy efficiency is a priority in modern societies where available resources are limited and demanded comfort increases exponentially. A efficient system requires the implementation of several high technologies and therefore, investments. So nowadays, the way to reach energy efficiency goes through introducing appropriate technological strategies in control and automation engineering area [5]. One of the main factors for better energy efficiency in a building, is the effective management of lighting system. The traditional manual switch on/off of the lamps causes situations in which there is too much lighting and therefore, a waste of energy, or poor lighting what involves low comfort. That obsolete technique to manage the lighting should be replaced by technological solutions which allow to control the lighting level and so, the power of lamps according to the sunlight, establishing a control closed loop. It should allow to define lighting scenes in order to ensure comfort and good lighting and also, to monitor the status of the lamps and electronic ballasts to detect possible faults immediately. The field of home/building automation is emphasizing the lighting optimization and new technologies which pursue energy efficiency management are emerging [8]. Standard protocols, such as Lon- Works, BACnet, KNX, A-10, etc, are well known around the world. These protocols have been created not only to manage the lighting system, but also the building integral management [1]. From the point of view of lighting control, it can be analog (1-10V protocol) or digital (DALI protocol). The last type of control is more efficient because it does not need intermediate steps for converting signals [6]. The research group SUPPRESS at the University of Leon has proposed in this work to improve the energy efficiency in the Remote Laboratory of Automatic Control LRA-ULE. For this purpose, a modern and autonomous lighting management system has been designed and implemented. The LRA- ULE offers to remote users (students, teachers and professionals) industrial equipment which is accessible through the Internet to perform automation and control experiences. The lighting system of Remote Laboratory was initially composed of fluorescent lamps with white screens. Electromagnetic ballasts were used to switch on/off the lamps. The problem was that they generated much heat causing a deterioration of insulation and therefore, continuous electrical faults. This lighting system had a low energy efficiency, required frequent maintenance (starters, isolation) and needed a capacitor to rise the low power factor. Due to all the things above, the increasing number of users and availability of laboratory at night, it was considered replacing the lighting system. This paper presents the lighting management system in the Remote Laboratory of Automatic Control at the University of León. The use of KNX and

54 DALI protocols has produced a system which is efficient, simple, open and easy to integrate into the laboratory architecture. The paper structure is as follows: in section 2 LRA- ULE features are summarized and the motivations which led us to establish a lighting management system are mentioned, in section 3 the lighting system architecture is described in detail, in section 4 integration of the lighting system into LRA-ULE is explained, in section 5 system operation modes are presented emphasizing remote mode via the Internet, in section 6 the achieved energy saving is presented as a result and finally, in section 7, conclusions and future work are listed. 2 LRA-ULE REMOTE LABORATORY The LRA-ULE ( is a Remote Laboratory for teaching and training where automation and control practices can be performed through the Internet using different industrial equipment [4]. It consists of a complex network structure which enables a secure and reliable remote access to industrial equipment, taking into account all the conditions imposed by the University of León network. The architecture of Remote Laboratory is based on a 3-layer structure (see figure 1): the first layer is comprised of industrial equipment offered, the middle layer consists of 4 servers to Internet access and in the third layer remote clients are located. Currently, the laboratory has the following equipment in physical systems layer: Three industrial scale models for the control of four variables (pressure, flow, level and temperature) [3]. This scale model consists of two auxiliary fluid circuits (cold, heat) and a process fluid circuit which is used to implement 4 possible control loops. A 4-tank scale model which is used in the study of MIMO (Multiple Input-Multiple Output) systems. An industrial pilot plant with two reactors, one of them high efficiency and three associated utility circuits (cold, heat and steam). This plant is used in the development of advanced control and monitoring strategies. A ABB IRB 1400 S4 robot with 6 degrees of freedom. A electro-pneumatic cell which simulates an assembly line. It comprises a conveyor belt, pneumatic cylinders and displacement table in two axes. The robot can be part of this cell. A motor-drive group to work with variable speed drives and AC induction motors. A group with DC motor, angular sensors and controllers made by Feedback. A home/building automation panel with several KNX / EIB sensors and actuators. The middle layer consists of four servers: Web server contains all web interfaces (operation environments and learning additional contents) which have been developed in PHP and HTML with a Manager Content System based on Drupal. Controller server executes an OPC client(object Linking and Embedding for Process Control) which is used to connect to the selected equipment and to read, modify or store its physical variables. Database server stores historical data from systems and allows remote users to download data for further analysis. Proxy server handles network filtering, connection tracking and network address translations. Finally, in the client layer, remote users access to the Remote Laboratory via the Internet using a common web browser. Due to lighting is a resource shared by several physical systems in the laboratory, it was integrated as a utility which provides support to physical systems. Thus, when a user accesses to the remote laboratory, lighting must be available to display the system via webcam correctly. On the other hand, lighting system can be also considered as an independent system to perform experiences in the same way that other equipment. 3 LIGHTING SYSTEM ARCHITECTURE Before defining the system architecture, a study of the different technologies to lighting management in buildings was carried out. Finally, it was decided to use two communication buses [7]: KNX and DALI. KNX protocol was chosen due to its popularity in Europe, many equipment manufacturers, it is reliable, safe and easy to wire. DALI protocol was chosen because of its minimal wiring, it is very simple and has excellent possibilities in the future. KNX (Konnex) [1] is an European open protocol for building integral management (including lighting, air conditioning, ventilation, energy manage-

55 Figure 1: LRA-ULE technological platform. ment, access control, security, audio/video, household electrical appliances control, etc). DALI (Digital Addressable Lighting Interface) [6] is a lighting management protocol designed to control electronic ballasts and lamps digitally. As it can be seen in figure 2, lighting system has been designed following an architecture with two buses, one of them based on KNX protocol for management, control, monitoring and maintenance of the complete system and the other based on DALI protocol for control of the lamps digitally. To achieve communication between TCP/IP network of the laboratory and KNX bus, it is used a gateway which is the interface between the two networks and establishes appropriate filters to prevent the transmission of unnecessary information. Likewise, KNX-DALI gateway is an interface between the two buses, incorporates the power supply for DALI bus and is the actuator for electronic ballasts. The devices which are connected to KNX bus are multifunction push-buttons, lighting and presence sensors, digital actuator and the corresponding gateways between different networks (IP-KNX, KNX-DALI and programming). Each room in the laboratory has a push-button and one or more lighting and presence sensors depending on its size and geometry. All KNX devices have a unique physical address which identifies them in the bus. Moreover, it is essential to connect a power supply which provides the voltage required for proper operation. The type of control used by KNX devices is distributed, that is to say, there is no central controller and so, each device can incorporate a part of control depending on their configuration and group addresses created between devices. DALI bus interconnects all electronic ballasts which are DALI slaves and are controlled by the gateway KNX-DALI (DALI master). Initially, unique physical address is assigned to each ballast. Different groups of lamps were made to optimize their control and maximize the energy saving. It means that, the same dimming level is applied to every ballast within the same group. For instance, in each room there are several lamp groups according to their geometry, layout of internal components (physical systems), sunlight areas, etc. Altogether, there are 11 lamp groups which are controlled by the same device, the gateway KNX-DALI. In addition, there are 8 spotlights to light 4 industrial scale models in the laboratory. They do not have DALI interface, so they are controlled by a KNX binary actuator. A set of lighting scenes have been defined, that is to say, different dimming levels preprogrammed in the DALI actuator. It provides rooms with different lighting environments. For example, the projection scene is activated when the use of the projector is necessary for a theoretical explanation in the room. In the table 1 the lighting scenes defined for the A3 room are shown. To remark that user can update

56 Figure 2: Lighting system architecture. Table 1: Set of the scenes for A3 room. Scene Group Dimming level Definition 4 G7, G8 80%, 80% Maximum lighting scene in the room 5 G7, G8 50%, 50% Medium lighting scene in the room 6 G7, G8 20%, 20% Minimum lighting scene in the room 7 G7, G8 0%, 35% Projection scene in the room Several possibilities for the integration of the lighting system into the LRA-ULE and its management from Drupal were studied. The first idea, using a well known structure in our laboratory, was to use an OPC Server for KNX based on the Falcon libraries. This option was rejected because this software is non-free. The second option studied was the use of Calimero libraries developed in Java. Although these libraries are free, they require a great code development in order to be used from a higher level such as a web browser. So it was also rejected. Finally, the possibility of using a free software for Linux was assessed and adopted. This software, called EIBnetmux [10], allows us multiple simultaneous connections to KNX bus by means of a single IP-KNX gateway. Furthermore, it includes a high-level programming interface based on PHP language which permits us to use it directly from web browser, in particular from the Drupal Content Management System. the scenes at any time and he can save the current dimming level as a new scene, although this option is disabled for the time being. For the rest of the rooms there is a set of scenes similar to those indicated for A3 room. 4 INTEGRATION OF LIGHTING SYSTEM IN THE LRA-ULE Figure 3: EIBnetmux architecture. The greatest advantage of EIBnetmux software is that it permits us multiple simultaneous connections to the IP-KNX gateway from different client applications. Requests are queued and only one application communicates with the KNX bus at every moment. It is very usual the use of the unique gateway for different purposes such as programming KNX devices, an application for controlling or monitoring the system, application for data acquisition from KNX bus, etc. Thus, this software not only provides this property but also includes different security levels to control the access of remote users to the system. Client applications can communicate with KNX bus simultaneously using a protocol based on TCP/IP sockets as well as KNXnet/IP

57 protocol based on UDP commonly used by programming software (ETS3) [9]. It includes C and PHP libraries with very simple and intuitive functions which do not require an advanced knowledge of KNX protocol. In this case, PHP libraries have been used in order to reach the link to the CMS. For this purpose, it was necessary to develop a new database module in Drupal which contains all group addresses to be modified remotely (luminosity setpoints, lighting level signals, manual/automatic selection, switch on/off signals, dimming level signals, operating binary status, dimming status, error status and scene numbers). There are more group addresses, but they are not added to the database because they are not necessary for the remote control and monitoring, although they are necessary for correct operation of the system. 5 OPERATION MODES The lighting system has two operation modes in each room: local mode and logically, remote mode. Modifying some of the many parameters which KNX and DALI devices have and carrying out a new programming, it is possible to change operation modes quickly and easily. 5.1 LOCAL MODE In local mode, the lamps are controlled by the user from the room by means of push-buttons, similar to the traditional way in which switches are used to change the lamps state. In local mode, it also is possible to establish a control loop to maintain constant the lighting. Thus, we can distinguish the manual local mode and the automatic local mode. The mode change can be done from the push-button of each room or remotely. In the manual operation mode, the lamps are controlled from the push-buttons. The difference between 8-key push-buttons and previous switches stems from the push-buttons are multifunction allowing us several options. In addition, large electrical currents do not flow through them. Each key of the push-buttons has a different function or even two if we discriminate between long and short keypress. For example, a single key can switch on/off the lamps and adjust brighter/darker the light. The table 2 contains all the available functions to the A3 room. When we want to use the pre-programmed scenes, it is necessary to enable the manual mode in order to avoid that new dimming values modify the scene settings. The scenes are very useful, if their values are properly adjusted, because they permit us to establish a specific and known dimming value quickly. Table 2: room. Key Key 1 Push-button functionalities of the A3 Function Selector between local mode and automatic mode Key 2 Switching on/off and lighting dimming brighter/darker in G7 group lamps Key 3 Switching on/off and lighting dimming brighter/darker in G8 group lamps Key 4 Key 5 Key 6 Key 7 Key 8 Enabling scene number 4 (Maximum lighting) Enabling scene number 5 (Medium lighting) Enabling scene number 6 (Minimum lighting) Enabling scene number 7 (Projection) Switching off all lamps in the room The automatic operation mode is the default mode, so that the system is in this state most of the time. In this mode, electronic ballasts receive a control action which is calculated according to the setpoint and the lighting level measured in the room. It is applied a proportional-integral (PI) algorithm with a dead zone to avoid sending information through the KNX bus continuously. As you can see in figure 4, the lighting and presence sensor performs controller functions and carries out the calculation of the action control, based on the measurement of the lighting level, the setpoint and the other internal device parameters. It should be noted that the sensor takes into account the people presence in the room to perform lighting control. The calculated dimming level is sent to the actuators which consist of electronic ballasts and the lamps. For this task, it is used a KNX-DALI gateway which interconnects both buses. When there are no users, the lamps are turned off after the pre-programmed switch off delay time (10 minutes). The sampling period (10 seconds) is sufficient to control lighting changes in indoor rooms since these ones are normally slow. 5.2 REMOTE MODE Like the rest of the physical systems of Remote Laboratory, it is possible to access to the lighting system remotely through the Internet in order to control and monitor it. When a remote user accesses to the system, the automatic local mode is disabled and immediately manual local mode is enabled to avoid overwriting the values sent by the user. Therefore, in remote mode, the automatic control loop is always disabled, and subsequently it is enabled when the user logs out. For monitoring and control environment, it has been designed a Java-based graphical user interface to be integrated into a website managed by Drupal. Like other physical systems in the laboratory, users should register, log in and access to the graphical interface where

58 Figure 4: Control loop implemented for the automatic local mode. they can send on/off signals and dimming values, change setpoints, display states, lighting levels, etc. All these operations are possible for each room of Remote Laboratory. Besides a remote environment to manage the lighting system, a set of fixed rules has been established in Drupal to manage the use of lighting system by different physical systems. It means that, if a user accesses, for instance to a 4-variables industrial scale model, the corresponding lamps will be turned on immediately as well as spotlights in order to allow him a correct image of the real system through the webcam. When a user logging out is detected, initial state of lamps will be restored. The set of rules is large and so, conflicts arise because of the interrelations between physical systems in the laboratory, multipurpose rooms, etc. It has been tried to solve these problems by giving priority to local use of the room. Lite version and allows us to create quickly a control and monitoring system for KNX installation. It only requires the configuration of database and user interface, without the necessity of code development. It comprises 4 tabs: control, monitoring, database configuration and information about the application. A screenshot of control user interface of the A3 room is shown in figure 5. 6 STUDY OF ENERGY SAVING Nowadays, lighting control systems are focused on achieving energy saving mainly, but without forgetting the visual comfort and aesthetics. Thus, it is important in a first approximation, to perform the theoretical estimation of energy saving which the lighting control system provides us. Figure 6: Lighting level in the A3 room for 3m height mounting sensor. Figure 5: Graphical user interface of Open Remote iknx application for iphone. Recently, a new tool for remote control and monitoring through the Internet has been integrated into Remote Laboratory. It is based on an application for iphone. Nowadays the number of applications for this mobile phone has increased considerably and the possibilities which this phone offers us are very interesting in the future. For this reason, it has been decided to integrate the application known as Open Remote iknx [2] which provides a configurable graphical user interface, a database for KNX group addresses and devices, bus monitor, etc. This application is available for free on the Data have been taken from different rooms of the Remote Laboratory in order to perform the mentioned estimation. As a example, data obtained from A3 room are showed bellow. In figure 6, you can see the temporal evolution of the lighting level (lux) during a full day. When there are users in the room, and so the lamps are on, the lighting value measured by the sensor fluctuates around the 160 lux. It is worth pointing out, the lighting sensor is mounted 3 m height approximately. The appropriate lighting level on work height (0.8 m height) is much higher (closer to 400 lux). The operation mode is usually the automatic one, so the lighting level remains constant around the setpoint (small changes of 10 %) and the dimming level applied

59 to electronic ballasts of lamps in the A3 room (G7 and G8 control groups) varies from 30% to 100% depending on the sunlight input (see figure 7). which students spend in their experience. In addition, electronic ballasts have less heat loss than magnetic ones and permit to establish limit values for dimming. 7 CONCLUSIONS AND FUTURE WORK Figure 7: Dimming level applied to ballasts into G7 and G8 groups. Although the dimming level reaches low values when the sunlight affects strongly (exceptional events), it often remains above 50% (initial value when lamps switch on). Taking into account the typical curve of the electronic ballasts given by the manufacturer, which is shown in figure 8, and knowing the limit values of the dimming level applied to the ballasts (50% and 100%), we can assert that the range of energy saving is between 0% and 30% of the total electrical power of lamps. We will take the average energy saving as a reference, that is to say 15%. Figure 8: Typical curve of the used electronic ballast. The other rooms which make up the Remote Laboratory have a performance similar to the previous one because there are not great differences in their physical construction. For this reason, results obtained in the A3 room can be extrapolated to the other rooms and so it can be asserted that the energy saving is 15% in all rooms. The electrical power demanded by the lamps in all rooms reaches kw and the power of spotlights is 2.4 kw which must be added to obtain global power of lighting system. Applying a energy saving rate of 15%, the power demanded by all the lamps will be kw for the same operation time. In case of spotlights, energy saving is even greater since now they do not work during all night, otherwise they only shine the time In this paper, a new lighting system in the Remote Laboratory of Automatic Control at the University Leon has been explained. The system is based on two open, simple, flexible and well known protocols in the field of home/building automation. The lighting system has been incorporated into the laboratory from two points of view. On one hand, the system guarantees to user transparently a correct lighting of the physical resource during his remote connection time. In addition, a control loop adjusts continuously the lighting level in order to remain around the setpoint. On the other hand, a environment has been developed for remote operation via the Internet of lighting system so that users can control and monitor it in a similar way to the local operation mode. The use of open home/building automation protocols in the system design, has facilitated its integration into the Remote Laboratory. Moreover, it is been shown that these technologies bring great benefits in energy saving. This work has been a first step in optimizing the lighting system in the laboratory. Currently, further experiences are being carried out about lighting control loop in different rooms of the laboratory. As examples, it can be mentioned the study of the sunlight influence, the measuring the energy consumption to verify the real energy saving and compare it with the theoretical one. It also is being developed a graphical user interface friendlier and more intuitive. Acknowledgement This work has been funded by ULE project at the University of León. References [1] Konnex Association., (2010) KNX Protocol, [2] Open Remote Association., (2010) Open Remote iknx Application, [3] M. Domínguez, J. J. Fuertes, P. Reguera, J. J. González, and J. M. Ramón, (2004) Maqueta Industrial para Docencia e Investigación, Revista Iberoamericana de Automática

60 e Informática Industrial, vol. 1, no. 2, pp [4] M. Domínguez, P. Reguera, and J. J. Fuertes, (2005) Laboratorio Remoto para la Enseñanza de la Automática en la Universidad de León (España), Revista Iberoamericana de Automática e Informática Industrial, vol. 2, no. 2, pp [5] S. Erice-Oronoz, (2010) Saving Energy in Offices Through a Good Lighting Solution, DYNA Ingeniería e Industria, vol. 85, no. 3, pp [6] AG-DALI Working Group., (2010) DALI Protocol, [7] K. Kastner, G. Neugschwandtner, S. Soucek, H. M. Newman, (2005) Communications Systems for Building Automation and Control, Proceedings of the IEEE, vol. 93, no. 6, pp [8] X. Pi, (2005) Estándares Domóticos: el Panorama se Clarifica, Revista Automática e Instrumentación, no. 360, pp [9] F. Praus, K. Kastner, O. Alt, (2004) Yet Another All-Purpose EIBNet/IP Gateway, In Proc. Konnex Scientific Conference. [10] U. Zurbuchen., (2010) EIBnetmux Software,

61 TangiLight: a tangible interface for complex dynamic lighting control Mathieu Gallissot Daniel Arfib Valentin Valls Laboratoire LIG, Equipe MultiCom, Bâtiment C, BP 53, Grenoble Cedex 9, France {Name}.{Surname}@imag.fr ABSTRACT. Seeking to help inhabitant to be more comfortable in their intelligent houses, this paper will present how, with the KNX protocol, a tangible interface can be used to control several parameters for lighting control with a cyclic timeline. KEY WORDS: tangible interface, smart homes, KNX, RFID, lighting control

62 2 KNX Scientific Conference Introduction Interacting with innovative products always raise the question of user interaction. In this domain, Home Automation systems didn t suffer much, using traditional interfaces such as push buttons, light switches and thermostat. Only difference is these objects communicate with an overall system to impact indirectly the user s environment, while traditional interfaces did it directly. But when it comes to more complex functions, these interfaces are not suitable anymore. Artifacts such as supervision software with touch panels are often used as a solution. They provide a disruptive way to interact with its house, with techniques explored in human/computer interaction fields [1] [2]. With the emerging of intelligent building and smart homes visions, most proposals would suffer problems with human interaction. For example, sensory marketing suggests the adaptation of many parameters to influence customer buying s [3]. Such a number of parameters require a new kind of interface where the user would not necessarily need expert s knowledge to use the system. With these visions, and as part of our current research in both intelligent buildings and human interaction, we were interested in dynamic lighting. This kind of lighting has many parameters, fixed such as color and light intensity, and dynamic such as a color cycle and its speed. 2. User Interface 2.1. Tangible user interfaces versus graphical interfaces. The goal is to provide the user with a way to change the colors projected on walls in a dynamic manner. This is properly done by sequencing a series of color values, which means by having a time line where color breakpoints are given. While this can be done using a virtual graphic interface on a computer, our thinking is that using a circle as a time base where objects indicate the color breakpoints is a natural way to introduce a time sequence in a cyclic manner. As it will be seen in chapter 3, it is possible to detect objects equipped with RFID tags in such a manner that we can specify properties or actions to these objects, and this constitutes the basis of the TangiLight physical implementation. With this in mind, we need two other features to build a time sequence of colors: the color of each breakpoint, and the time speed of the entire cycle. To specify a color, one needs to select (the term used for this is to afford) a color in a palette. The display of this palette is related to the choice of a color bucket (a small blue box in

63 TangiLight: a tangible interface for complex dynamic lighting control 3 Fig 1) which is afforded to a specific palette. And in order to be able to change the cycle period (or speed), we will use a specific rotary knob on the Tangisense table. The user interface designed in this scope relies on two principles: selection and activation. The selection (of a color) is made with a physical object (glass cube). It uses the concept of affordance. The activation is made with the reactive table, by affording objects and positioning them on a particular space of the color cycle. It uses tangibility and affordance concepts Tangibility Figure 1: TangiLight user interface Our research is in the general frame of tangible user interfaces (TUI) where the interfaces quit the virtual domain for using everyday life objects the people can manipulate. Interaction with objects is very different from computer graphical interfaces in the sense that the action-perception loop is going through gestures and physical actions and that the immersion may be more natural and intuitive. Nevertheless objects are usually only tracked and some kind of feedback is essential to get the feeling that objects have inherent functions or possible actions. In our implementation, the use of a color bucket immediately displays the palette that is contained in it. The posing of a cube in a palette immediately makes a link (and displays a color line) to a specific color (Fig 1 left). And the position of such a cube on a circle modifies the time sequence of relative colors (Fig 1 right) Affordance concept The term affordance has been introduced by Gibson [4] in its ecological view of perception and action, and originally meant the way a user perceives an object

64 4 KNX Scientific Conference 2010 and the possible actions with it. Norman [5] was more concerned with the information concept, hence the way indices can be taken from objects such as propositions of interaction. In a simple way, we can say that a tangible experience is carefully designed when with a few explanations (or no explanations at all) a naïve user can guess the way to play with it, and experts can ultimately find their way to produce creative results. This is achieved when objects are clearly identified and when actions are clearly reported in terms of gestural feedback or final result. 3. Hardware The hardware used in this scope was specified and implemented during an ANR 1 project called TTT, in which the research group participated. This hardware function is to detect tangible objects (that is to say physically manipulated) on a surface. It has been called TangiSense in reference with tangibility and human senses. This surface is composed of tiles, each tile being equipped with a matrix of 8 by 8 RFID antennas (compliant to the ISO specifications) and 16 by 16 LED to ensure visual feedback. Tiles are given communication capabilities, using the IP transport protocol over Ethernet. Many configurations can be used, such as a table made of 25 tiles (5 * 5), or as a smaller device (2 tiles aside). This last configuration is used in our project. Figure 2: TangiSense tile view Other technologies also allow the detection of tangible objects, such as Reactable 2 which is using optical sensors. In our approach, the RFID technology allows more flexibility in the arrangement and the size of the active surface by arranging tiles together. Moreover, it does not suffer from problems about lighting pollution and thus allows outdoor use or in dynamic lighting conditions (such as at concerts or in the present case). 1 Agence Nationale de la Recherche, National Research Agency. 2

65 TangiLight: a tangible interface for complex dynamic lighting control 5 The implementation of such a device raises a major challenge, concerning electromagnetic compatibility. Due to the close proximity of each antenna, the activation of all of them at the same time would be parasitic, the emitted electromagnetic field covering each antenna's neighbors. The design in operation to respond to this challenge activates a given number of antennas at a given time. Optimization can be made with parameterization, in order to tune object detection latency and stability, both being linked. An interactive table must respond appropriately to user input, time and accuracy. Given the chosen parameters, the faster mode can detect a quarter of the antennas simultaneously. A more stable set of parameters performs a complete detection with a latency of 500 milliseconds. On the control part, the detection, recognition and tracking of objects is divided in three main layers: Capture interface layer, which works at the RFID level to drive RFID tiles and to detect tags dispatched on the surface. Traceability layer, use to interpret RFID tags at an object level. Fed with object s topology (shape and tags position), it can provide position and orientation of the object on the surface. Application layer, which depends of the usage of the device. 4. Software 4.1 Specifications In order to integrate this work in our KNX system, we designed an application compliant to the Easy Mode configuration profile specified by the KNX standard. This choice was driven by interoperability reasons, moreover for tangible objects behavior association. Using an Easy-Mode model (at least specifying a channel) allows us to extend future work to other intelligent building applications. The important aspects of this application are: The cycle, represented by an array of colors. The speed of the cycle, which should be customizable by the user The ability to store and recall cycles, associated to its speed The ability to turn on and off the controlled device (RGB lighting). 4.2 KNX Channel CH_RGB_Sequencer The goal of this channel is to represent our application as seen from the KNX system. Role of this application is to sequence over time RGB values to an RGB

66 6 KNX Scientific Conference 2010 actuator. It uses the main base of a light actuator with scene (0103h) [6], but as an intermediate channel (controlled by sensors, driving actuators), it was adapted. We considered using the recently standardized RBG datapoint to send values to an RGB actuator. Thus, as prior to the standardization of this datapoint, alternate implementation may use three dimming type functional blocks, one for each color. This alternate implementation induces the use of subunits. Inputs CH_RGB_Sequencer Outputs OnOff OO RGB RGB SceneNumber SN IOO Info OnOff Figure 3: representation of CH_RGB_Sequencer Inde x Name Sub - unit Main CC Additional CCs Fla gs (i/o,x, v..) O/M DPT 1 RGB 1 CC_RGB (private) O Status OnOff 1 CC_Switch_Status_OnOff OV OnOff 1 CC_Switch_OnOff CC_Logical IL Scene Number 1 CC_Scene I Table 1: list of datapoints for channel CH_RGB_Sequencer 4.3 Implementation Figure 3 shows the implementation diagram which was used for this study, where: TangiLight HMI constitutes the RFID device, in a two tiles aside configuration. TangiLight Application contains the necessary software to drive the tiles and to push objects positions to the CH_RGB_Sequencer implementation

67 TangiLight: a tangible interface for complex dynamic lighting control 7 KNX Middleware is a virtualized KNX network (from SIRLAN Technologies) in which our channel is implemented and instantiated. It provides a direct access to the bus and configuration capabilities. KNX System composed of two (virtualized) RGB actuators and one push buttons. KNX RGB Actuator CH_RGB_Sequencer TangiLight HMI IP/OSC TangiLight Application IP/OSC KNX Middleware KNX Push Button CH_RGB_Sequencer KNX RGB Actuator Figure 4: integration diagram The communication between TangiLight s components uses the OSC 3 protocol, as the device was initially intended for music interaction. Thus, even if this protocol is suitable for this function, it can be further replaced depending of deployment cases. The communication between the TangiLight HMI and the TangiLight Application concerns in one way the object s position and movements, and in the other way drives the LEDs in order to feedback the user with the cycle in operation. The communication between the TangiLight application and one or more CH_RGB_Sequencer is event driven. When an object appears, is moved or is removed, impacting the cycle, its position and representing color is sent with its action to the channel, which will compute the cycle to render. Other messages concerning the speed of the cycle may be received too. In order to reduce the network load, a choice was made to compute rendered cycle on both devices. This choice was also impacted by the fact colors may not be rendered the same on each device (both HMI and RGB actuators), so adjustments can be parameterized on each device. 5. Conclusion and Future work We have presented in this paper a new vision of inhabitant/building interaction, using a tangible interface in order to provide a friendly user interface for a domain specific intelligent building application. In this case, the application was about dynamic lighting, for conceiving and customizing light color sequences. If this primarily design was concluded as a challenge for our research group (cross competences), its implementation seems promising to explore new horizons 3 Open Sound Control (

68 8 KNX Scientific Conference 2010 in building / user interaction. With the promising future of intelligent buildings, and human interfaces, future work will be carried out in order to combine these two concepts. The future work will extend the application from dynamic lighting to other intelligent building applications, which has the same level of complexity. Reviewing the state of art in the intelligent building and smart home fields, we discovered that applications such as scene management are often misunderstood by users. As a matter of fact, these scenes are more likely programmed by the integrator, and rarely by the user itself. We also would like to use a bigger device based on the same technology to extend possibilities on the existing application. Due to the relatively small size of the reactive surface, color choice and cycle resolution are limited. Using a bigger device (1 square meter) would bring more possibilities, using the same interaction or extending it such as in past work [7]. 6. References [1] Taylor, A. S., Swan, L. (2005). Artful systems in the home. Conference on Human Factors and Computing systems, CHI '05, Portland, OR, ACM Press, pp [2] Edwards K. W., Grinter R. (2001). At Home with Ubiquitous Computing: Seven Challenges. Proceedings of the Conference on Ubiquitous Computing (Ubicomp 2001). Atlanta, GA. September 30-October 2, [3] Kotler P. (1973). Atmospherics as a marketing tool. Journal of retailing. [4] Gibson, J.J. (Eds). (1979). The ecological approach to visual perception. New York: Lawrence Arlbaum Associate. [5] Norman, D. A. (1999). Affordances, conventions and design, Interactions. ACM, [6] KNX Association, The KNX Standard. [7] Arfib D., Filatriau J.J., Kessou L. (2009), Prototyping Musical Experiments For Tangisense, A Tangible And Traceable Table. Proceedings of the SMC th Sound and Music Computing Conference, July 2009, Porto Portugal

69 Integrating surveillance systems into KNX Felix Schuster, Lukas Krammer, Wolfgang Kastner, Wolfgang Granzer Vienna University of Technology Institute of Computer-Aided Automation, Automation Systems Group Treitlstr. 1-3, A-1040 Vienna {felix.schuster, lkrammer, k, auto.tuwien.ac.at Surveillance systems are of increasing importance for modern buildings. Still, most of the existing video surveillance systems are based on analog technologies and human operators. This paper proposes a concept to integrate smart cameras into KNX based building automation systems. Once integrated, such cameras will be able to autonomously detect different kinds of events and perform appropriate actions. At first, typical application scenarios of surveillance systems are presented. Based on these scenarios, basic communication models for this purpose are discussed. Finally, necessary Functional Blocks and appropriate Datapoint Types are introduced. The resulting interworking is demonstrated by a proof-of-concept implementation. 1 Introduction State-of-the-art video surveillance systems are based on analog technologies. Recently, a trend towards IP based monitoring and recording systems can be identified. These systems allow archiving and later analysis of video material where the problem of huge amounts of data arises. Therefore, it is desirable that big command and control centers only get notified in case of a security event in order to derive further actions by the human operators. An additional trend is to add computational power and image processing functions on-thespot of smart cameras. Low cost cameras are well suited for such purposes. Nowadays, such cameras are produced in very large quantities for the automotive industry and are thus readily available at the viable prices. The paper focuses on the integration of surveillance systems into a KNX network infrastructure. First, potential use cases are discussed, particularly, when building automation and surveillance systems are tightly integrated. As a first example, consider a motion detection device opening a KNX based access door or a window contact requesting a video camera to take a snap-shot. Next, two paradigms will be introduced and compared. While in a gateway-driven approach high engineering effort is necessary, a decentralized solution based on tunnelling multimedia data over KNX is taken into account. Following the latter approach, corresponding Functional Blocks and necessary Datapoint Types are proposed. For a proof-of-concept implementation, a popular software based monitor is used. This monitor is able to detect changes 1

70 of significant parts of the image. Only in such a case, the picture is transferred. Finally, mechanisms for multimedia data transfer via TP1 are evaluated and an outlook on possible future work is given. 2 Use cases Integration is an everyday reality (and necessity) even for BAS that once solely aimed at the HVAC or lighting/shading domain [2]. In the following, selective use cases where future surveillance systems may play an important role are presented targeting building performance, security and life safety. 2.1 Surveillance for comfort and energy efficiency In the near future, people and their activities can be expected to be detected (even identified) by cameras. This offers an enormous potential for building performance (yet leaves ample room for privacy issues). Consider for example advanced room controllers that act dependent on the number of people inside an office. Even individual control can be imagined, if once a person is identified and thus his/her personal desires can be taken into account. Furthermore, it is possible to identify typical activities in a room (e.g., conferences, meetings) and the number of people in the room. Based on these data, it is possible to compute the thermal emissions of the people and control the HVAC system in the room accordingly. Additionally, smart cameras can be used to control lights and blinds. Dependant on the brightness in the room and the brightness outside, lighting and shading actuators can be controlled to provide optimal ambient light conditions. If face recognition is also used, the ambient light can be controlled as desired by an individual person. It is also possible that smart cameras take the position of people in a room into account. For example, consider a person sitting in front of her/his office desk. In this case the ambient light can be dimmed and the desk lamp is turned on. These functionalities not only increase the usability and comfort of people in an office, it improves the energy efficiency of a building enormously, too. A quite different application area where smart cameras can be used are restaurants or hotels. In addition to the intelligent light control, smart cameras can be used to detect fumes. Depending on the intensity of fumes, the ventilation system is controlled accordingly. Such a system offers a fine grained ventilation system and reduces the demand of energy. Obviously, such a system can also be used in concert halls and other rooms where smoking is permitted. 2.2 Surveillance for security In the area of security, surveillance is emphasized on criminals. Consider, a public garage, where long stops in front of cars as well as breaking of glass of car windows indicate a possible crime. In combination with voice sensors, screaming shouts can be a reason to notify the system about a violent crime. In this case, the cameras are used to display and save the incident for investigation. Other possible actions are closing the gates or turning on klaxons. Currently, breaking of glass is detected by vibration sensors. If image processing is used, these sensors can be replaced or extended by smart cameras. In contrast to isolated vibration sensors, broken pieces of glass can be recognized, too. This results in a more reliable detection 2

71 of a cullet. As a reaction, the doors can be locked and warning-lights start blinking in the concerned area. Another area of interest could be surveillance of transportation systems. The main focus of an elevator monitoring system is vandalism prophylaxis and detection of vandalism. An in-house alarm should occur, if someone taggers some graffiti or spoils emergency buttons Surveillance for safety Currently, fire is spotted with smoke alarms and flame detectors. These sensors could be extended or even replaced, if cameras with fire detection are used. In case of a fire alarm, an HVAC system could enter a special mode for smoke extraction, elevators could automatically stop loaded cabins at the next floor level and shut down and the flextime system could print out a list of all people having checked in. After confirmation of a fire alarm the sprinkler and water spray fire-extinguishing installation should be turned on. Finally, the fire brigade gets informed automatically. Also surveillance systems can be tightly coupled to guidance systems. For example, consider the movement of a mass of people, e.g. at a stadium during inflow and outflow of a concert. Routes can be automatically proposed through lighting a pathway dependent on the current rush. Cameras can even be used for the detection of water ingress. This is a critical event, if there is an installation energized. Therefore, actions must be performed immediately. A first reaction is the disconnection of the electrical power supply. Furthermore, the electrical installation will be grounded to avoid danger for people through electrical discharges. 3 Communication models Before a communication model for a surveillance application can be specified, possible communication approaches have to be discussed. On one hand, a communication can be done by using a centralized approach. On the other hand, the complete distributed approach without any central entity can be used. 3.1 Centralized approach The main characteristic of the centralized approach is that it is based on a strictly hierarchical communication concept. An overview about this communication model is given in Figure 1. End-devices are located at small local field networks which are interconnected by gateways. The gateways are in turn connected with a centralized instance (e.g., operator workstation). If a device behind one gateway wants to communicate with another device located within a different field network, the centralized instance has to receive the corresponding network messages. Afterwards, it has to process the messages and forward it to the desired destination. Since each data exchange between two devices has to be passed through the centralized instance, it is obvious that the traffic is concentrated at this instance. The result is a bottleneck. 1 A pilot scheme in council housings in Vienna resulted in up to 65 percent less costs due to vandalism acts. The bulk of savings were indicated through existence of the cameras only. 3

72 Operator Workstation Gateway Gateway Gateway HVAC/Lighting Access Control Motion Detection Devices Communication Channel Figure 1: Communication scheme of a centralized communication approach In general, the communication media at the field level have other requirements than the communication media at the upper levels. The challenge when using gateways is to connect these two levels with each other since a forwarding and translation of exchanged data is necessary. Since there is never a one-to-one mapping between two communication protocols, protocol translation always results in a loss of information. This fact is one of the main disadvantages of the centralized approach. Another major disadvantage is that if this central instance fails, the complete communication breaks down. Thus, such a central instance represents a single point of failure. Another drawback of the centralized approach comes up, when the engineering and maintenance effort is considered. Due to the required protocol translation, the gateways have to be aware of the communication structure and so, they have to be configured accordingly. This results in an additional engineering effort which can not be neglected for large networks. 3.2 Distributed approach The distributed approach is also based on a two-level communication concept. Figure 2 gives an overview about this approach. Using a decentralized scheme, there is no need to forward messages between gateways and the central instance. Instead, the end-devices are communicating directly with each other. The upper-level communication medium is used to tunnel messages between two end-devices if they are located in different network segments. To interconnect the different network segments, routers are used. However, compared to gateways, routers do not need to translate the adjacent network protocols. Instead, a tunnelling concept is used where the untouched network messages are encapsulated into packets of the upper-level 4

73 protocol. These tunnelling packets are transmitted to the destination routers which decapsulate the received tunnelling packets and finally forward the original message to its destination. This tunnelling concept is independent from a central instance. However, it is still possible that a centralized instance captures or visualizes all messages, but this does not influence the communication between two end-devices. In contrast to the previously described centralized approach, no single point of failure exists anymore. Since all messages of the end-devices are only tunnelled through the upper-level medium, it is not necessary to perform a mapping between two different protocols. However, it is necessary that all different end-devices use the same protocol. This fact is a drawback of this approach. Another disadvantage is that an enormous amount of bandwidth is required, since the communication is still concentrated at the upper-level network. Operator Workstation Operator Workstation Backbone Router Router Router HVAC/Lighting Access Control Motion Detection Devices Communication Channel Figure 2: Communication scheme of a decentralized communication approach 4 Application specification The overall surveillance application consists of at least two Functional Blocks (FBs). One FB represents the camera in combination with a motion detection and image processing software. In the following, it will be entitled Camera Functional Block (CFB). Additionally, one or more FBs are necessary for further image analysis. They are called Surveillance Functional Blocks (SFBs). Moreover, other building service FBs can be appended to the application to perform immediate actions (e.g., to switch on a light or lock a security door). Since it is not possible to transmit a whole image (with a size of about 20kB) inside one message, it is necessary to split the image into different data frames. The size of one data frame depends on the allowed or desired size of the datagram. If large data frames are desired, the 5

74 time for transmitting the image reduces due to the reduced communication overhead. However, large data frames occupy the medium and increase the response time of other devices. To ensure that the image is correctly reassembled at the receiver, it is necessary to uniquely identify a single data frame. This implies that a sequence number is necessary which identifies a data frame within an image. Moreover, another label is necessary to distinguish between two different images. This label is called event number in the following sections. 4.1 Datapoint types To offer a flexible yet robust communication model, a bidirectional communication between an CFB and its corresponding SFBs is necessary. Since the number of SFBs belonging to a CFB shall not be limited, Group Objects (GOs) are used for the communication. In the following, new Data Point Types (DPTs) are introduced and specified for image transmission using a KNX based communication DPT_ImageIndication DPT_ImageIndication is used by the CFB to indicate a detected event. A formal description of this DPT is given in Figure 3. Format: octet nr 6 octets: U 16 U 8 U 8 U 8 U 8 6 MSB 5 LSB field names Remainder NumberOfFrames FrameSize ImagePriority Size EventNumber encoding UUUUUUUU UUUUUUUU UUUUUUUU UUUUUUUU UUUUUUUU UUUUUUUU Datapoint Types ID: Name: Use: DPT_ImageIndication Data fields Description Unit/Range EventNumber Subsequent event number U ImagePriority Priority value of an event U 8 0=lowest 255=highest FrameSize Payload of an image frame U RemainderSize Remainder octets of the image size U (FrameSize - 1) NumberOfFrames Number of frames of the according image U Figure 3: Compound structure of DPT_ImageIndication 6

75 One part of the DPT is the event number that uniquely identifies subsequent events. One octet is used as event number allowing a range of After each detected event, the value is monotonically increased and finally, wraps around at the end. Furthermore, the DPT contains the priority of the detected event. The priority is represented by an unsigned variable with a size of one octet. Thus, the priority value can be chosen between 0 and 255 where the lowest priority is corresponding with 0. Depending on the priority, one event can displace another one. The priority of an event with the according image is determined by the image processing software (e.g., safety events may overrule security events). A detailed description about the priority mechanism is presented in the following section. Additionally, the DPT contains the number of data frames of the detected image. For this purpose an unsigned integer with a size of 2 octets is used. Thus, the maximum number of data frames is limited to approx which should be sufficient for transmission of images with medium quality. To later reassemble the image, the size of an image frame has to be defined in advance. This value belongs to the current image and can not be changed once the image is in transmission. Since normally the size of the original image is no multiple of the data frame size, the image size is also transmitted within this DPT to guarantee a correct reassembly. However, it is not necessary to transmit the number of bytes of the file. It is sufficient to transmit the remainder between the size of the image and the smallest multiple of the data frame size greater than the image size. The resulting size can be determined by image size := (frame size (number of frames 1)) + remainder size. Thus, the range of the remainder size can be defined as 0 remainder size < frame size. Since the data frame size is limited to one octet, the remainder size is also limited to one octet DPT_ImageTransmission DPT_ImageTransmission is used to transmit a single data frame of an image. This DPT can have a variable length depending on the data frame size field of the according DPT_Image Indication. Figure 4 shows a detailed description of the DPT. The first octet represents the event number also included in the DPT_ImageIndication. This number uniquely identifies an image where values between 0 and 255 are allowed. To identify the position of the frame within the image, every data frame has a unique and increasing number. The range of the sequence number depends on the number of data frames and is defined between 0 and number of frames 1. Similarly to the number of data frames in DPT_ImageIndication, the sequence number has also a size of two octets. The "payload" DPT_ImageTransmission represents a part of the image file and starts with the 4th octet. The length of the payload is variable and specified by the according DPT_ ImageIndication. The payload size for an Application Protocol Data Unit (ADPU) datagram is normally limited to 14 octets (+6 bits) but can be extended to 252 octets (+6 bits) by using extended frames. 2 Due to the "header" of the DPT_ImageTransmission (i.e., 3 octets), the value has a range of 0 to 249 This value specifies the size of the payload (without the overhead of three octets). 2 Note that such large messages dramatically reduce the response time of other devices on the medium (e.g., approx. 250 milliseconds for TP1). 7

76 Format: n octets: U 8... U 8 U 16 U 8 octet nr n MSB 2 LSB 1 field names ImagePayload n-3... ImagePayload 0 SequenceNumber EventNumber encoding UUUUUUUU UUUUUUUU UUUUUUUU UUUUUUUU UUUUUUUU Datapoint Types ID: Name: Use: DPT_ImageTransmission Data fields Description Encoding Unit/Range EventNumber Subsequent event number U SequenceNumber Identifier for a frame within an image U (NumberOfFrames - 1) ImagePayload Payload of an image frame (U 8 ) FrameSize binary octets Figure 4: Compound structure of DPT_ImageTransmission DPT_ImageRequest A further DPT called DPT_ImageRequest has to be defined which represents a request. This DPT is used by SFBs to request images from the CFB. A detailed description of its content is given in Figure 5. DPT_ImageRequest contains the event number of the requested image. Equally to the DPT_ImageIndication, this variable has a size of one octet. Additionally, the DPT includes the priority value of the requested image frame. This value is used to inform other SFBs about the priority of the request. 4.2 Functional blocks Camera Functional Block As mentioned before, the overall application contains at least two different FBs. The CFB represents one or possibly more cameras in combination with an image processing unit. Depending on the underlying application, the image processing unit is able to detect different kinds of events as mentioned in Section 2 (e.g., fire, water ingress). Based on these events, the CFB is able to perform immediate actions by communicating with standard KNX devices. Furthermore, it indicates interested SFBs the detected event and is able to transmit the according image on request of a specific SFB. 8

77 Format: 2 octets: U 8 U 8 octet nr 2 1 field names ImagePriority EventNumber encoding UUUUUUUU UUUUUUUU Datapoint Types ID: Name: Use: DPT_ImageRequest Data fields Description Encoding Unit/Range EventNumber Subsequent event number U ImagePriority Priority value of an event U 8 0=lowest 255=highest Figure 5: Compound structure of DPT_ImageRequest As shown in Figure 6, a CFB uses three different group objects (GOs) for communication with SFBs. It is possible that the FB optionally contains further GOs to perform immediate actions (e.g., for light switching). SFBs get indicated on reception of a DPT_ImageIndication value transmitted via a specific group address. This message informs the corresponding service user or possibly an operator about the occurence of the event and the recorded image. Depending on the priority, a SFB is able to request the recorded image from the CFB. This request can be performed by any SFB and is handled via a DPT_ImageRequest. To ensure that urgent images are transmitted immediately, a priority mechanism is introduced. This mechanism basically prefers all requests with higher priority and interrupts transmissions with less priority. As mentioned before, the priority value has a range between 0 and 255 where 0 represents events with the lowest priority. The following set of rules specifies the priority mechanism of the CFB: If an image is requested by an SFB and no other image is in transit by the CFB, the message is transmitted immediately by successively sending all image frames to a group address using DPT_ImageTransmission. If the priority of the requested image is lower than the priority of the image in transit, the request is ignored. The SFB will not be informed about this decision. However, the SFB is allowed to send a new request after a while. 3 If the priority of the requested image is higher than the priority of the image in transit, the actual transmission is interrupted and the transmission of the requested image is started. The two different frames can be identified by the event number which is a part of the DPT_ImageTransmission. Note that the transmission of the interrupted image is not 3 Note that normally an SFB will send such requests only during its start-up phase or due to race conditions. 9

78 continued when the transmission of the new image is finished. If an SFB still requires this image, it can request the image once again. If the priority of both images is equal, the request is queued. In this case the queued image is transmitted immediately after the previous image was transmitted successfully. If more images are in the request queue, they are transmitted in the order of their requests. If two equal requests are received, the last request will be dropped. Since group addresses are used to transmit the images all SFBs can receive all transmitted images. Hence, an image has to be transmitted only once independent from the number of requests. Beside this mechanism, the CFB is able to store a predefined number of events with the according images in a buffer. The buffer is organized in a first-in-first-out manner. Thus, the oldest event is dropped if a new one is received and the buffer is full. If a requested image has already been moved out of the buffer, the request is ignored Surveillance Functional Block An SFB is able to receive detected events and can request the according images from the CFB. It is possible that more than one SFB is bounded to one CFB. Such a functional block can, for instance, represent an operator panel or an image archiving unit. Thus, the FB offers a local interface where the indication of an event is forwarded to. Based on this event, an operator (or an advanced surveillance software) may request a transmission of the according image by using services of the mentioned interface. If an image was received successfully, the reception is indicated to an operator and the reassembled image is delivered. If the CFB detects an event, it transmits a DPT_ImageIndication messages via a specific group address. If an SFB receives such a message, it stores the information and informs the service user that in turn may request the image via DPT_ImageRequest and the corresponding group address. Since requests for images which are currently in transit are ignored by the CFB, all SFBs have to receive and buffer all transmitted images. This mechanism ensures that two subsequent requests of different SFBs for the same image can be satisfied without retransmission. However, the service user is only informed, if it has requested the according image previously. If a message containing DPT_ImageTransmission is received, it is buffered. If all frames of an image were received and buffered, the image is reassembled. If the image was requested previously, it is delivered by the local interface. If the image is not completely received and a frame of another image is received, it is assumed that the actual image is displaced by another image with higher priority. The service user gets an indication in case the transmission failed. All buffered frames of the image which were already received are dropped. Nevertheless, an SFB is allowed to request the interrupted image once again. Due to the different priorities, it is possible that requested images are not transmitted. If the function block behaves correctly, it will not request a frame with lower priority than the current one. During start-up of new surveillance applications and a concurrent image transmission, the new application has no knowledge about the current priority. Thus, requests to the CFB of this service user will be ignored. In this case, an underlying SFB has to wait for a given time and may then request the image frame once again. In case of race conditions (i.e. two SFBs 10

79 concurrently transmit events with different priority), the one request with the lower priority will also be ignored by the CFB. 4.3 Interworking In the previous part, the functional behavior of each FB was described. Now, the interaction between all FBs is introduced. Figure 6 shows a functional block diagram of a typical application. In this application scenario one CFB exists which observes an object (e.g., entrance area of a building). Furthermore, two SFBs are considered which are able to request and receive images. Optionally, other FBs can be used to perform immediate KNX actions. In this example, a simple light switch actuator could be activated. CFB SFB Inputs (mandatory) I_IR Outputs (mandatory) O_II DPT_ImageIndication Inputs (mandatory) I_II Outputs (mandatory) O_IR DPT_ImageRequest O_IT DPT_ImageTransmission I_IT Inputs (optional) Outputs (optional) Inputs (optional) Outputs (optional) DPT_Switch O_S O_S Inputs (local) Outputs (local) Inputs (local) Outputs (local) CAM O_Op SFB Inputs (mandatory) IDP Outputs (mandatory) O_IR TDP Inputs (optional) Outputs (optional) O_S Inputs (local) Outputs (local) O_Op LSAB DPT_Switch I_S O_L Figure 6: Block diagram of a typical surveillance application The CFB and the SFBs are connected by using three different group objects transferring three different DPTs as described before. Since group objects offer multicast communication, 11

80 all messages have to be sent only once. For instance, consider the case that only a point-topoint communication is used. If two SFBs request the same image, it would be transmitted twice. If the CFB detects an event, it sends an indication to a group address. All SFBs receive the indication by listening to this group address. Also, other SFBs may request the according image via a dedicated group address. Since every FB can receive this message (including all other SFBs), other FBs which want to request another image with lower priority can postpone their request. If one SFB requests an image, it is transmitted if no other image frame is currently in transit or the requested image frame has a higher priority than the message in transit. If an SFB requests an image with a lower priority than the currently transmitted image, the request is ignored. The transmission of an image is also done by sending messages to a group address. Thus, every SFB is able to receive all transmitted images. However, only if an image is requested by the corresponding service user, it is provided by its local service interface. To visualize the communication between the CFB and an SFB, Figure 7 shows a time-line diagram of a typical application. The left side of the diagram represents the CFB. This FB is separated into two different instances. The left instance represents the camera in combination with an image processing unit, whereas the right one represents the communication instance which is responsible for KNX communication. The two instances on the right side represent the SFB. The left one represents the communication instance and the right one represents the described service interface. These services can, for instance, be used for communication with system operators. 5 Proof of concept To evaluate the proposed concept, a PC based proof of concept to detect and transmit images via KNX TP1 was implemented. Though a PC-based solution will not be feasible for real applications, it allows to demonstrate the underlying interworking concept. For real installations, embedded devices will be necessary to integrate the previously described FBs. This issue is left open for future work. 5.1 Hardware The hardware environment consists of a TP-UART in combination with a standard PC. The TP- UART interface as introduced in [3] only provides the physical layer and a part of the data link layer. The interface board is powered by the KNX TP1 medium. It is optically coupled with a USB interface chip. Both, the optical coupler and the USB interface chip are powered by USB. The driver for the TP-UART board emulates a standard serial port on the PC, where necessary parts of the KNX stack reside. 5.2 Motion detection software Two different detection libraries were evaluated for image processing purposes. Some positive and negative aspects as well as their features are discussed in the following. 12

81 Camera & image processing CFB KNX Interface KNX Interface SFB Surveillance interface services Event X0 detected Priority: 0 Indication of Event X0 transmission requested Request of X0 received transmission of X0 started Event X1 detected Priority: 0 Event X2 detected Priority: 1 Indication of Event X1 no transmission requested Request of X2 received transmission of X0 interrupted transmission of X2 started Event X3 detected Priority: 0 Indication of Event X2 transmission requested Indication of failed reception of Event X0 Request received Priority (X3) < Priority (X2) request of X3 ignored Request received Priority (X4) = Priority (X2) request of X4 queued Event X4 detected Priority: 1 Indication of Event X3 transmission requested Indication of Event X4 transmission requested Transmission of X2 done queued transmission of X4 started Event X2 completely received Figure 7: Time-line diagram of a typical transmission 13

82 5.2.1 Motion Motion [4] is an open source motion detector software hosted by sourceforge and can be used under the terms of the GNU General Public License. It acts as a daemon and uses text files for configuration. There is one main file (which includes configuration of the first input stream) and one more for each further input stream. Motion is capable of detecting movements. Therefore, it scans an image and indicates if significant parts of the picture have changed. There are several features making Motion a useful tool. For instance, it is possible to take snapshots after a defined period of time. Next, it provides a feature to select either the first or the best picture. Considering a person walking through an observed area, the first picture could hold the information that someone entered the area, whereas the best picture could be one where the person is right in the middle of the picture. Motion allows recording such events and even adds some pictures before and after. Moreover, it supports the execution of commands if some kind of motion is detected. Pictures taken by Motion are configurable in quality. Choosing between ppm and jpeg images is possible. One more option is to get a "Motion-image". This is an image with a solid background where changed pixels are printed colored. They have approximately one third of the image size of an ordinary jpeg image and are intended mainly for debugging purposes especially for tuning the eroding and dilating options. Motion is even capable of tracking events, if the camera supports moving the head (like PTZ cameras typically do). In the presented approach the feature Area_detect is used. It enables detection in different regions which is particularly useful for prioritizing events. As described in Section 4, events with higher priority interrupt and abort transmission of lower prioritized events. Area_detect intersects the picture in 9 (3 x 3) areas which in turn were configured to trigger prioritized events AXIS event detection Meantime, low cost AXIS cameras[5] are capable of detecting events. For each event type a name, a status, a priority, a triggered-by event and an action may be specified. While the name can be chosen arbitraryly, the status just differentiates between enabled or disabled. There are three priorities available (low, normal and high) which influence the job importance on the camera s operating system. For instance, a high prioritized event gets a higher priority than the web server running on the camera. An event does not necessarily need to get triggered by motion detection. Furthermore, triggers are defined by input ports, manual triggers or on start-up. Possible actions support the upload of image (send as , upload to http or ftp), the activation of an output port or notifications sent via . Axis event detection is less powerful than independent libraries. For easy installation and low requirements it is still good enough, at least as on-board solution. 5.3 Functional block implementation The application software is based on eibd and its client-server application programming interface (API) as introduced in [6]. The server application implements the whole KNX stack up to the application layer. Due to the server s socket interface, easy to handle client libraries for 14

83 different programming languages exist (e.g., C, Java). The prototype contains two FBs which are implemented in C CFB implementation The application which represents the CFB has to implement an image processing module and a camera interface on one hand and a module which is responsible for KNX communication on the other hand. Motion is used as interface to the camera and for image processing purposes. To visualize the structure and the communication interfaces, Figure 8 shows a block diagram of the application. The used camera is connected with the image processing software via Ethernet. The image processing software is a command line tool able to detect movement in different areas of the observed area. If an event is detected, the application executes a user defined script. For simplicity, it was assumed that different areas of the image have different priorities. For example, consider that a movement in an upper area of the image would indicate a fire and a movement in the bottom of the image indicates water ingress. Depending on the area in which motion was detected, a different script is executed. The script sends the according images to a named pipe. Each pipe represents a priority level. The main application implements the KNX communication using application layer services via eibd. PC Camera Module Ethernet TCP/IP Image Processing Software (e.g., Motion) Named Pipe Camera Functional Block Application Unix Socket EIBD Server USB TP-UART Board Figure 8: Block diagram of a typical surveillance application The main application is set up as a State Machine (SM). It synchronously polls all input channels for new events, changes its state and performs necessary actions. It is assumed that all message services are blocking. Thus, the corresponding service terminates only if the message is physically transmitted or an error occurred. This function block is implemented as SM. The functional behavior of this SM is determined by a block diagram as shown in Figure 9. If a new image is detected in one pipe, the message is buffered, an indication message is sent and the internal state remains unchanged. This action is performed independently from the current state. If a request of another FB is received and the SM is in idle-state, the state changes to transmit-state and the transmission of the first data frame of the requested image is 15

84 if: -ev_pending do: -send DPT_ImageIndication -clear (ev_pending) if: -rq_pending (R_ev,x) & buffer_empty do: -send DPT_ImageTransmission: (R_ev,0) -T_ev :=R_ev -T_sq:= 1 -clear (rq_pending) if: - rq_pending & buffer_empty do: -send DPT_ImageTransmission: (FIFO_getFirst,0) -T_ev :=FIFO_getFirst -T_sq:= 1 -FIFO_removeFirst if: -rq_pending (R_ev,x) & buffer_empty & -pr(buffer(0))>pr(r_ev) do: -send DPT_ImageTransmission: (FIFO_getFirst,0) -T_ev := FIFO_getFirst -T_sq:= 1 -clear (rq_pending) -FIFO_removeFirst IDLE if: - ev_pending & t_done & rq_pending (R_ev) & -pr (R_ev)=pr(T_ev) & T_sq >= max_sq(t_ev) do: -FIFO_add(R_ev) -clear (rq_pending) -clear (t_done) if: - ev_pending & t_done & rq_pending (R_ev) & -pr (R_ev)<pr(T_ev) & T_sq >= max_sq(t_ev) do: -clear (rq_pending) -clear (t_done) if: - ev_pending & t_done & rq_pending & -T_sq >= max_sq (T_ev) do: -send DPT_ImageTransmission: (T_ev,T_sq) -T_ev :=T_ev+1 -T_sq:= T_sq+1 -clear (t_done) if: -rq_pending (R_ev,x) & buffer_empty & -pr(fifo_getfirst)=pr(r_ev) do: -FIFO_add (R_ev) -send DPT_ImageTransmission: (FIFO_getFirst,0) -T_ev := FIFO_getFirst -T_sq:= 1 -clear (rq_pending) -FIFO_removeFirst TRANSMIT EventNumber: T_ev SequenceNumber: T_sq if: - ev_pending do: -send DPT_ImageIndication -clear (ev_pending) if: -rq_pending (R_ev,x) & buffer_empty & -pr(buffer(0))<pr(r_ev) do: -send DPT_ImageTransmission: (R_ev,0) -T_ev := R_ev -T_sq:= 1 -FIFO_clear -clear (rq_pending) if: - ev_pending & t_done & -rq_pending (R_ev) & -pr (R_ev)>pr(T_ev) do: -send DPT_ImageTransmission: (R_ev,0) -T_ev :=R_ev -T_sq:= 1 -clear (rq_pending) -clear (t_done) if: - ev_pending & t_done & rq_pending (R_ev) & -pr (R_ev)<pr(T_ev) & T_sq < max_sq(t_ev) do: -send DPT_ImageTransmission: (T_ev,T_sq) -T_sq:= T_sq+1 -clear (rq_pending) if: - ev_pending & t_done & rq_pending (R_ev) & -pr (R_ev)=pr(T_ev) & T_sq < max_sq(t_ev) do: -FIFO_add (R_ev) -send DPT_ImageTransmission: (T_ev,T_sq) -T_sq:= T_sq+1 -clear (rq_pending) -clear (t_done) if: - ev_pending & t_done & - rq_pending & -T_sq < max_sq(t_ev) do: -send DPT_ImageTransmission: (T_ev,T_sq) -T_ev :=T_ev+1 -T_sq:= T_sq+1 -clear (t_done) Figure 9: SM of the CFB implementation 16

85 started. Note that the transmit-state is not a single state. It is more a collection of states. A single state can be determined by the sequence number of the frame and its event number. If a request is received and the SM is in a transmit-state, the performed action depends on the priority of the request. If the priority of the request is higher than the priority of the current state, the first frame of the requested frame is transmitted and the state is changed accordingly. Furthermore, the request queue is cleared because there are only events with lower priority in it. If the priority of the request is equal to the priority of the current state, the request is added to the request queue (if it contains no equal entry from another FB). If the requested frame is not in the buffer or the requested frame has a lower priority than the current state, no state change happens. The request is also ignored, if an equal state is in the request queue or if the frame is in transit. If the last frame of an image was transmitted and the request queue is empty the SM returns to the idle-state. If the request buffer is not empty the first frame of the first request in the queue is transmitted and the state is changed accordingly (i.e., transmit-state) SFB implementation The implementation of the SFB is quite easier than the CFB, since no special hardware is required. The implementation of this FB strongly depends on the purpose (e.g., operator panel, image archiving unit, advanced image processing). However, the main part of the FB which is responsible for the KNX communication is equal in each case. In the context of this FB, a simple interface was defined to separate the main part of the FB from the application dependent part. In the current implementation, a simple operator panel is simulated. This panel informs the user about an event by writing a text message to the command window. If an image shall be requested, the event number has to be typed in. If an image was received successfully, the default viewer of the operating system displays the image. Similarly to the CFB, the SFB is realized as SM. Figure 10 shows the functional behavior of this SM. An overview about the behavior is provided as follows: If an indication message is received, it is decoded and written to the command window. A user can request an image by typing the event number. If the SM recognizes such an event, it checks if an indication for the desired event was previously received. In this case, it sends a request to the CFB, if the priority of the request is higher than the internal priority. The internal priority value is a variable which holds the highest priority. This value can be changed by receiving requests of other SFBs or a transmission message of the CFB. If a request from another SFB is received and its priority value is higher than the value of the internal priority variable, the internal priority variable is updated. If the SM is in idle-state and a message frame is received, it is checked if the sequence number is equal to zero. In this case, the frame is buffered and the state changes to 4 Note that all events in the event queue have equal priority. 17

86 if: -ind_pending (I_ev, I_pr) do: -pr(i_ev):=i_pr -IF_Indicate -clear(ind_pending) if: if: -fr_pending(f_ev,f_sq) & - rq_pending -F_ev=T_ev & T_sq=F_sq & -T_sq = max_sz (T_ev) do: -add_buffer(f_ev,f_sq) -IF_image (T_ev) -clear(fr_pending) IDLE -fr_pending(f_ev,f_sq) & - rq_pending -F_ev=T_ev & T_sq=F_sq & -T_sq = max_sz (T_ev) do: -add_buffer(f_ev,f_sq) -clear(fr_pending) if: if: -IF_rq_pending (I_ev) & - fr_pending do: -send_request(i_ev) -pr(i_ev):=i_pr -T_pr:=I_pr -T_sq:=0 -T_ev:=I_ev -clear(if_rq_pending) if: -IF_rq_pending (I_ev) & -fr_pending(f_ev,f_sq) & -F_ev = I_ev do: -pr(i_ev):=i_pr -T_pr:=I_pr -T_sq:=1 -T_ev:=I_ev -clear(if_rq_pending) -clear(fr_pending) if: -fr_pending(f_ev,f_sq) & -rq_pending(r_ev,r_pr) -F_ev=T_ev & T_sq=F_sq & -T_sq = max_sz (T_ev) do: -T_pr:=R_pr -add_buffer(f_ev,f_sq) -IF_image (T_ev) -clear(fr_pending) -clear(rq_pending) -ind_pending (I_ev, I_pr) do: -pr(i_ev):=i_pr -IF_Indicate -clear(ind_pending) if: - fr_pending & -rq_pending(r_ev,r_pr) do: -T_pr:=R_pr -clear(rq_pending) IDLE_RQ Priority: T_pr if: -IF_rq_pending (I_ev) & pr(i_ev)>=t_pr & - fr_pending do: -T_pr:=pr(I_ev) -T_ev:=I_ev -T_sq:=0 -clear(if_rq_pending) if: -IF_rq_pending (I_ev) & pr(i_ev)>=t_pr & -fr_pending(f_ev,f_sq) & -F_sq=0 do: -add_buffer(f_ev,f_sq) -T_pr:=pr(F_ev) -T_ev:=F_ev -T_sq:=1 -clear(fr_pending) -clear(if_rq_pending) if: -IF_rq_pending (I_ev) & -I_ev = T_ev do: -clear(if_rq_pending) if: - fr_pending & -rq_pending(r_ev,r_pr) do: -T_pr:=R_pr -clear(rq_pending) if: - IF_rq_pending -fr_pending(f_ev,f_sq) & -F_sq=0 do: -add_buffer(f_ev,f_sq) -T_pr:=pr(F_ev) -T_ev:=F_ev -T_sq:=1 -clear(fr_pending) if: -fr_pending(f_ev,f_sq) & -rq_pending(r_ev,r_pr) -F_ev=T_ev & T_sq=F_sq & -T_sq = max_sz (T_ev) do: -T_pr:=R_pr -add_buffer(f_ev,f_sq) -clear(fr_pending) -clear(rq_pending) if: -fr_pending(f_ev,f_sq) & -F_sq=0 do: -add_buffer(f_ev,f_sq) -T_ev:=F_ev -T_sq:=1 -clear(fr_pending) TRANSMIT_RQ EventNumber: T_ev SequenceNumber: T_sq Priority: T_pr TRANSMIT_N_RQ EventNumber: T_ev SequenceNumber: T_sq Priority: T_pr if: -fr_pending(f_ev,f_sq) & -F_ev<>T_ev & F_sq=0 if: -ind_pending (I_ev, I_pr) do: -pr(i_ev):=i_pr -IF_Indicate -clear(ind_pending) if: -fr_pending(f_ev,f_sq) & -F_ev=T_ev & T_sq=F_sq & -T_sq < max_sz (T_ev) do: -add_buffer(f_ev,f_sq) -T_sq:=T_sq +1 -clear(fr_pending) do: -add_buffer(f_ev,f_sq) -IF_failure (T_ev) -T_ev:=F_ev -T_sq:=1 -clear(fr_pending) if: -ind_pending (I_ev, I_pr) do: -pr(i_ev):=i_pr -IF_Indicate -clear(ind_pending) if: -fr_pending(f_ev,f_sq) & -F_ev=T_ev & T_sq=F_sq do: -add_buffer(f_ev,f_sq) -T_sq:=T_sq +1 -clear(fr_pending) Figure 10: SM of the SFB implementation 18

87 transmit-state with the according event and sequence number. Furthermore, the internal priority variable is updated with the priority of the received frame. If the sequence number is different to zero, only the internal priority variable is updated and the frame is ignored. If the SM is in transmit-state and a data frame is received, the event number and the sequence number of the received frame are compared with the current state. If the event numbers are equal and the sequence number of the received frame is expected, the image frame is buffered. Additionally, if the last frame of an image was received, the image is reassembled and written to a file on the local file system. Furthermore, the image is displayed using the default image viewer. If the event number of the transmitted frame differs from the event number of the local state and the sequence number is zero, then a new image was received. In this case, the frame is buffered. In all other cases only the internal priority variable is updated. 6 Conclusion This paper presented an approach to integrate a multimedia surveillance system into conventional KNX installations. The KNX standard is primarily designed for data communication in the home and building automation domain. However, surveillance applications using multimedia systems become more and more important. Since the bandwidth of the classical KNX medium (i.e., TP1) is limited, only small amounts of data can be transmitted within reasonable time. Thus, the presented concept uses image processing software to identify different safety and security relevant events. Based on these events, the software performs different actions autonomously. However, in some cases it is necessary to transmit the whole image. In general, images with at least 15 kb are necessary to identify safety and security events. If an image transmission is requested by a client (e.g., an operator panel) it takes more than one minute until the whole image is transmitted. Table 1 shows some measured response times for images with different sizes. This calculation assumes that nothing else is transmitted on the medium. To ensure that only important images are transmitted and no important image is stalled, a priority mechanism was introduced. Image size (bytes) Frame size (bytes) Number of Frames Transmission speed (seconds) Table 1: Main results of the proof of concept implementation To conclude, the proposed solution is suitable for applications where events can be detected and processed autonomously. Thus, state-of-the-art image processing technologies are necessary to detect events dependably. For applications where many images have to be transmitted or a real-time surveillance is desired KNX TP1 is infeasible. KNX IP [7] will provide a communication medium with high bandwidth. This technology can be used for those purposes where classical KNX reaches its limits. Based on the previously 19

88 described FBs and the KNX IP communication medium, a system can be developed which provides a decentralized autonomous automation approach in combination with a fast or even real-time transmission of multimedia data. Acknowledgment This work was funded by FFG (Austrian Research Promotion Agency) under the Kiras project Networked minispot" P References [1] KNX Specification Version 2.0. Konnex Association, [2] W. Kastner, G. Neugschwandtner, S. Soucek, and H. M. Newman, Communication systems for building automation and control, Proceedings of the IEEE, vol. 93, no. 6, pp , [3] F. Praus, C. Reinisch, P. Leitner, and W. Kastner, Open Source Approaches to integrate KNOX into Media Centers, in KNX Scientific Conference, [4] Motion a software motion detector. [5] Axis Communications network cameras. [6] M. Kögler, Free development environment for bus coupling units of the european installation bus, Master s thesis, Vienna University of Technology, [7] KNX IP - a new class of KNX devices, KNX Journal, vol. 01, pp , (available from 20