IST Aim Energy management device d3-1-1-1v1-0

AIMDeliverable 3.1.1.1

Title: EMD Design and specification report

Editor: Spyridon Tompros

Deliverable nature: Report (R)

Dissemination level:(Confidentiality)

Public (PU)

Contractual delivery date:

31 May 2009

Actual delivery date: 28 May 2009

Suggested readers: AIM consortium

Version: 1.0

Total number of pages: 79

Keywords: Energy Monitoring Device, Interfaces, Network, Power metering

Abstract

This deliverables summarizes the technical work that the consortium has carried out towards the definition, design and implementation of the first version of the Energy Management Device (EMD).

The EMD has the role of communicating with the connected appliances for the purpose of polling and controlling their status, enabling in that way realisation of energy monitoring and saving applications.

Although the architecture of the EMD specified in this document is the final one, the physical implementation of the EMD will have a second phase in which the device will be optimised in terms of physical size and internal software interfaces to user services.

In this document the EMD specification is given in terms of architecture and internal building elements description, and use-cases and realistic user scenarios analysis. In the annexes the reader can find installation, configuration and maintenance information.

AIM Deliverable D3.1.1.1

Page 2 of (79) © AIM consortium 2009

Disclaimer

This document contains material, which is the copyright of certain AIM consortium parties, and may not be reproduced or copied without permission.

All AIM consortium parties have agreed to make this document available on request to other framework programme participants.

The commercial use of any information contained in this document may require a license from the proprietor of that information.

Neither the AIM consortium as a whole, nor a certain party of the AIM consortium warrant that the information contained in this document is capable of use, or that use of the information is free from risk, and accept no liability for loss or damage suffered by any person using this information.

Impressum

WP3: Design of the power management architecture

Document title: EMD Design and specification report

Editor: Giannis Chatzopoulos, Keletron LTD

Work-package 3 leader: Spyridon Tompros, Keletron LTD

Estimation of PM spent on the Deliverable: 97

Copyright notice

2009 Participants in project AIM


© AIM consortium 2009 Page 3 of (79)

Executive summary In contrast to the most predominant ICT-based solution for implementing energy control, which are based on the use of smart metering device, the AIM project follows a different approach in the implementation of energy management in households, with the main goal of being a low cost and user friendly solution without the need of extra components. This approach is based on the observation that today appliances are becoming increasing ICT-enabled and therefore can be controlled remotely over the network.

The AIM solution is based on the establishment of generic logic for energy management, called theAIM core logic, which can be mapped on any communication component of the home environment, a modem, a residential gateway or a user personal computer. The AIM core logic hosts user services that operate performing three functions:

Energy monitoring (metering function);

Energy control (maintenance of energy levels within user programmable limits);

Standby devices management (self-explanatory).

The AIM services are accessible by users through any kind of Internet-based terminal and can be configured by the user themselves or the operators who provide access to AIM service.

To avoid the use of smart metering devices and to extend the management logic with energy control functionality, AIM has developed its own cognitive approach in measuring and controlling appliances energy consumption, based on the concept of user programmes. Each appliance type has a number of user programmes that can be operated. For example a washing machine has economical user programmes, more intensive energy consuming programmes for woollen clothes, coloured clothes,etc, while a refrigerator has also different cooling programmes.

AIM energy control logic is based on the management of the appliance user programmes via the network. Being able to poll the appliance status in terms of current user programmes, the AIM logic hosted on a home gateway can retrieve the profile of each appliance from the local profiles database and find out instantly the energy each appliance consumes.

With regard to the AIM core logic, the Energy Monitoring Device of which architecture and specification is summarised in the deliverable, represents ways of implementing physical communication and low level control logic for the user programmes of the appliances.

This deliverable summarizes the technical work that the consortium has carried out towards the definition, design and implementation of the first version of the Energy Management Device (EMD).




List of authors

Company Author

Keletron Nikolaos Mouratidis

Keletron Spyridon Tompros

Infineon Sandor Plosz

Infineon Andreas Foglar

PPC Markus Ridchen

DOE Wolfgang Doebeldt

BCT George Karidis

Eurescom Maria Barros



Table of Contents

Executive summary ................................................................................................................................. 3

List of authors.......................................................................................................................................... 4

List of figures and/or list of tables........................................................................................................... 6

Abbreviations .......................................................................................................................................... 8

1 Introduction ..................................................................................................................................... 8

2 Energy Management Device (EMD) – Overview......................................................................... 11

2.1 Internal components and functions........................................................................................ 14

2.1.1 EMD generic architecture.............................................................................................. 15

2.1.2 Standby mode implementation using an EMD.............................................................. 16

2.1.3 Energy Management in active mode using an AIM EMD ............................................ 18

2.1.4 EMD Appliance function types ..................................................................................... 19

2.1.5 EMD physical communication interfaces...................................................................... 19

2.1.6 The EMD hardware implementation ............................................................................. 33

2.1.7 The EMD firmware roadmap ........................................................................................ 36

2.2 Internal interfaces.................................................................................................................. 37

2.3 External interfaces................................................................................................................. 37

2.3.1 EMD integrated to the controlled appliance.................................................................. 38

2.3.2 EMD integrated to the AIM logic ................................................................................. 38

2.3.3 EMD as an independent control box between Gateway and appliance......................... 38

2.3.4 Interfaces toward the appliances ................................................................................... 38

2.3.5 Interfaces towards the network...................................................................................... 44

3 EMD Architecture ......................................................................................................................... 46

3.1 Overview ............................................................................................................................... 46

3.2 Internal components and functions........................................................................................ 46

3.2.1 Integration with the network ......................................................................................... 48

3.2.2 Protocol stacks............................................................................................................... 49

4 User-related operations.................................................................................................................. 65

4.1 Example usage scenarios....................................................................................................... 65

5 Use-cases....................................................................................................................................... 67

5.1 Installation possibilities......................................................................................................... 67

5.2 Supported appliances............................................................................................................. 68

5.3 Use-cases for network operators ........................................................................................... 68

5.4 Use-cases for residential users .............................................................................................. 68

5.5 Use-cases for energy generation utilities............................................................................... 69

6 Conclusions ................................................................................................................................... 70

References ............................................................................................................................................. 71

Annex A ................................................................................................................................................ 72

A.1 Installation & Configuration Guide....................................................................................... 72

A.2 Serial interface specification ................................................................................................. 75



List of figures and/or list of tables Figure 1: Residential appliances and EMD........................................................................................... 12

Figure 2 : A/V appliances and EMD..................................................................................................... 13

Figure 3: Communication appliances and EMD ................................................................................... 14

Figure 4: Internal architecture of the Energy Management Device (EMD).......................................... 15

Figure 5: Standby reference communication scenario .......................................................................... 16

Figure 6: Energy consumption polling procedures ............................................................................... 17

Figure 7: Message flows for standby implementation .......................................................................... 17

Figure 8: Active appliances management reference communication scenario...................................... 18

Figure 9: Message flows for active appliances management ................................................................ 18

Figure 10: Modulation of digital data on power line signal .................................................................. 20

Figure 11: Digital signals modulation techniques over power line signal............................................. 21

Figure 12: Internal architecture of power line communication interfaces............................................. 22

Figure 13: Device addressing................................................................................................................ 23

Figure 14: Reference communication over power line ......................................................................... 24

Figure 15: Signal modulation phases .................................................................................................... 25

Figure 16: Data format .......................................................................................................................... 25

Figure 17: Data layout........................................................................................................................... 26

Figure 18: Data link layer architecture.................................................................................................. 26

Figure 19: Network layer architecture................................................................................................... 27

Figure 20: Transport layer architecture ................................................................................................. 28

Figure 21: KNX Protocol states and state machines ............................................................................. 29

Figure 22: Application layer architecture.............................................................................................. 30

Figure 23: Mapping of data structures................................................................................................... 31

Figure 24: Internal KNX primitives overview ..................................................................................... 32

Figure 25: EMD Hardware implementation diagram............................................................................ 33

Figure 26: AIM EMD............................................................................................................................ 35

Figure 27: The DECT frequency/time spectrum................................................................................... 40

Figure 28: DECT Basic STAR topology............................................................................................... 41

Figure 29: Used frequencies of DECT and CAT-iq.............................................................................. 42

Figure 30: CAT-iq Application examples ............................................................................................. 43

Figure 31: CWMP End-to-End architecture.......................................................................................... 44

Figure 32: Functional components of the EMD.................................................................................... 46

Figure 33: Distributed EMD architecture.............................................................................................. 47

Figure 34: Architecture of the EMD Power Plug Array........................................................................ 48

Figure 35 : Indoor and outdoor communication scenario ..................................................................... 49

Figure 36: Reference communication scenario for energy saving services implementation ................ 50

Figure 37: Protocols stacks for the implementation of energy saving services..................................... 51

Figure 38: Message format of the Universal Energy Management protocol......................................... 52

Figure 39: Payload field layout ............................................................................................................. 53

Figure 40: State machine for the implementation of the switch off command ..................................... 56

Figure 41: State machine for the implementation of the switch on command ...................................... 57

Figure 42: State machine for the implementation of the switch over command................................... 58



Figure 43: State machine for the implementation of the error command.............................................. 59

Figure 44: State machine for the implementation of the acknowledge command ................................ 60

Figure 45: State machine for the implementation of the status command ............................................ 61

Figure 46: Internal data structure of the energy profile database .......................................................... 62

Figure 47: Internal data structure of the status database ....................................................................... 62

Figure 48: EMD hardware configurations............................................................................................. 67

Figure 49: The EMD Slave ................................................................................................................... 72

Figure 50: The EMD Electrical Current measurement unit detached ................................................... 73

Figure 51: Close up of the electrical current measurement unit............................................................ 74

Figure 52: The EMD Slave assembled with add-on board.................................................................... 74



Abbreviations

AC Area Coupler

ACS Auto-Configuration Server

ADPCM Adaptive Differential Pulse Code Modulation

ADSL Asymmetric Digital Subscriber Line

AIM FP7 Project number ICT- 224621 acronym

API Application Programming Interface

A/V Audio/Video

CAT-iq Cordless Advanced Technology - Internet and Quality

CDMA Carrier Detect Multiple Access

CDMA /CA Carrier Detect Multiple Access/Collision Avoidance

CECED European Committee of Domestic Equipment Manufacturers

CPE Customer Premises Equipment

CWMP CPE WAN Management Protocol

DECT Digital Enhanced Cordless Technology

DPRS DECT Packet Radio Service

DQPSK Differential Quadrature Phase Shift Keying

EEPROM Electronically Erasable Programmable Read Only Memory

EMD Energy Management Device

EMI External Message Interface

EMU Energy Metering Unit

ESTIA FP6 Project number IST- 27191 acronym

ETSI European Telecommunications Standards Institute

FEC Forward Error Correction

FP Fixed Part

FSK Frequency Shift Keying

GAP General Access Profile

GFSK Gaussian Frequency-Shift Keying

GPIO General Purpose Input/Output

GPRS General Packet Radio Service

HDTV High Definition TV

HGI Home Gateway Initiative

HTTP Hyper-Text Transfer Protocol

IC Integrated Circuit

ICT Information and Communication Technology

IMI Internal Message Interface

IMS IP Multimedia Subsystem

IP Internet Protocol

ISDN Integrated Services Digital Network

KNX Network communications protocol for intelligent buildings

LAN Local Area Network

LC Line Coupler



M2M Machine-To-Machine

MAU Mount Access Unit

MISO Master In Slave Out

MOSI Master Out Slave In

OSGi Open Service Gateway Initiative

OSI Open Systems Interconnection

PABX Private Automatic Branch Exchange

PC Personal Computer

PDA Portable Digital Assistant

PEI Peripheral External Interface

PIC Programmable Integrated Circuit

PL Power Line Communications

PLC Power Line Communications

POTS Plain Old Telephone Service

PP Portable Part

PSTN Public Switched Telecommunications Network

QAM Quadrature Amplitude Modulation

QoS Quality of Service

SOA Service Oriented Architecture

SOAP Simple Object Access Protocol

SPI Serial Peripheral Interface

RAM Random access memory

RG Residential Gateway

RF Radio Frequency

RPC Remote Procedure Calls

RS232 Recommended Standard 232 - computer serial interface

RSSI Received Signal Strength Indication

TCP Transmission Control Protocol

TCP/IP Transmission Control Protocol / Internet Protocol

TDD Time Division Duplexing

TDMA Time Division Multiple Access

TPDU Transport Protocol Data Unit

TRIAC TRIode for Alternating Current

UDP Undefined Datagram Protocol

UMP Universal Management Protocol

UMTS Universal Mobile Telecommunications System

USART Universal Synchronous/Asynchronous Receiver/Transmitter

USB Universal Serial Bus

WAN Wide Area Network

Wi-Fi Wireless Fidelity – wireless networking

WLAN Wireless Local Area Network

VoIP Voice over Internet Protocol

XML Extensive Mark-Up Language



1 Introduction

The most predominant ICT-based solution proposed for implementing energy control is the use of smart metering devices. Smart metering devices are able to measure in real time energy consumption of households and communicate these figures to energy generation utilities, but they are add-on boxes that add up to energy consumption, are costly and therefore may minimise user acceptance.

The AIM project [1] follows a different approach in the implementation of energy management in households, which is based on the observation that today appliances are becoming increasing ICT-enabled and therefore can be controlled remotely over the network.

The AIM approach has as main goal to remove the need of introducing extra components in the implementation of wide scale energy management that add up to energy consumption, are costly and therefore may minimise user acceptance. The objective behind this goal is to render the AIM solution open, low cost and friendly to the user so that it becomes rapidly available on the market.

This document describes the internal architecture of the AIM Energy Management Device (EMD).

In the following sections the EMD architecture and building blocks functional decomposition is presented along with use-cases indicating the use of the device in the frame of realistic applications.

In chapter 2 it is given an overview on ways of implementing communication between the gateway and the appliances via the EMD. In chapter 3, the EMD architecture protocols and services is presented. In chapter 4 there are some realistic scenarios of using AIM’s energy management functions, along with realistic use-cases in chapter 5, provided by the user groups of the project.



2 Energy Management Device (EMD) – Overview

In the AIM architecture, the energy consumers are controlled by an Energy Management Device (EMD), which works as the local hub of the AIM energy control. The EMD communicates through proper communication channels called "Interfaces" with all the energy consumption actors, using one (or more) physical communication media and associated protocols. The implicated communication technologies are based on wireless, power-line or Ethernet connectivity. The interfaces are specified for communications channels among appliances (white goods, audiovisual and communications equipment) on one side, and users (home users, utilities and network operators) on the other side.

The EMD is controlled by an AIM Gateway through a bus interface, ensuring access to multiple EMDs from a single access-point, either locally ('domestic' users); or offers a single access-point for controlling the full system remotely. The EMD functional entity is linked with the AIM gateway via an IP or PL connectivity component. It can also be controlled directly via external networks using IP.

The AIM EMD is the functional entity in charge of implementing energy management functions towards the household appliances. As such, it employs two types of communication interfaces: a low-level power line interface, which allows physical communication to some appliance types and also facilitates real time measurement of energy consumption for the appliances that are connected to the same power line on the mains; and a high-level interface that is employed solely for exchanging control and status information with household appliances, implementing custom-made communication protocols. The latter interface may not necessarily be of power line type but is subject to the choice of the appliance manufacturer.

In addition to the two core functional entities, the architecture provides a group of household appliance encompassing functions, which must be managed in terms of energy consumption, and a number of user’s applications grouped in compatible use-cases. The two peripheral entities and the core functional entities are altogether connected via the IP protocol. Moreover, further enhancement of platform automated operations beyond the usual user configurable scenarios is achieved through the inclusion of a sensor network in the home network, which allows detection of human presence and movement in the home. With this addition the platform becomes capable of accommodating logic for more intelligent energy saving scenarios, such as automated switching off of communication equipment, when there is no user at home.

There is a multitude of associated control scenarios and technologies that can lead to reduced energy expenditure in a residential setting. Bellow we shall examine the main ones.



Figure 1: Residential appliances and EMD

The AIM EMD is a multiprotocol and quite flexible control device. Its communications hub is based on power line communications, though it can be connected to the rest of the AIM actors using a wide variety of additional protocols, like Ethernet, ZigBee, Wi-Fi etc. The connection to port to these protocols is executed via an intermediate parallel interface, which is used to link the EMD to additional electronic boards that deliver the complementary protocol services. This port is also used to link the EMD to an energy metering apparatus. The control connection to residential appliances is executed using power line communications and an on/off TRIAC control is also available, as can be seen in the associated diagram from figure 1. Control information stemming from the Gateway can reach the EMD using a wide assortment of wired, wireless or power line protocol bases.



Figure 2 : A/V appliances and EMD

The same is the case with Audio/Video appliances controlled by an EMD. An additional controloption offered for this set of devices is an On/Off switch, figure 2, which uses Infrared RF technology similar to the one employed by the actual remote controls of the associated A/V devices. This means that an A/V device can be shut off remotely by a command that reaches the EMD through the power line and transferred to the actual A/V device using infrared signalling. An electronic switch (TRIAC) control is also available in this configuration.



Figure 3: Communication appliances and EMD

Communications residential equipment generally employs low energy consumption modes, but is not able to receive input from a residential sensor network. This is where the AIM EMD acts, being able to set controlled communications equipment in low energy , stand-by mode, or even shut them down completely using standardized power shut off controls (TRIAC) or wireless signals received and executed by the associated communication devices, based on the AIM sensor network.

2.1 Internal components and functionsNetworked electrical devices are being slowly introduced to the market. Even if every new sold electrical appliance was networked and manageable, it would take many years till all devices in households would get replaced. Hence, to speed up the process, some intermediate solution must be introduced and provided. This solution is called Energy Monitoring Device (EMD). Thus in the scope of our project, the EMD will provide an energy control interface to existing household appliances.

An important aspect of the AIM system is management and control. After an energy control point has retrieved a description of the device, the EMD will send action commands to a device's service layer.To achieve this, an EMD sends a suitable control message. Control messages can also be expressed in XML using the Simple Object Access Protocol (SOAP). Like function calls, in response to the control message, this service returns action-specific values. The effects of the actions, if any, are modelled by changes in the variables that describe the run-time state of the power management service.

An important factor in energy expenditure is the Standby mode, also known as phantom power load, which is responsible for an incredibly high amount of electricity consumption. Practically every electronic device that is plugged into a socket continues to consume electricity after it is switched off. Examples include phone chargers, notebook power adaptors, microwave ovens, game consoles, CD, video and DVD players. Worldwide surveys indicate that energy consumed by appliances in standby mode amount to 10% of the total energy consumed in households.



EMD and White goods: White-goods belong to a category of easily managed appliances regarding their instantaneous energy consumption, however only washing machines can benefit from standby energy management. Most white good appliance types can therefore be controlled via the home network either over the power line network or over short range (mesh) and home wireless networks.

EMD and A/V: All A/V appliances have standby modes so they can be switched on and off using a remote control. Switching between standby and OFF states will be performed by the EMD, taking into account usability factors, such as:

Presence of users at home; Time zone & movement of users between rooms; On permanent or long term leave.

EMD and Communication equipment: Communication equipment usually does not offer a standby mode. Instead, manufacturers encourage users to unplug the devices each time they do not use them. For many devices the active mode is also the standby mode. For example a DECT station in the absence of people at home could be safely switched off without any impact on user communication. Other, more energy consuming communication devices, such as wireless access points or GPRS/ADSL gateways, recently introduced as a method for integrating mobile communications over fixed operator networks, are said to be in standby mode although they remain active, during nights or user absence periods.

2.1.1 EMD generic architecture

The EMD shall have a unified architecture, which will feature generic interfaces towards the household appliances, the power network and the home network. Due to its generic architecture, the system can be realized in differing forms, i.e. standalone external box or internal module. Concerning its buildings blocks, the system offers three generic-purpose interfaces; one towards home communications networks, one towards the mains power network and one for connecting to internal digital control buses of household appliances.

Figure 4: Internal architecture of the Energy Management Device (EMD)

With these three general-purpose interfaces, the system will be able to integrate with virtually any network environment or household appliance and will provide two types of power management logic:



Energy monitoring: power metering functions that are applied to power electronics of the household appliances, an encoding logic that turns measurement results into digital values and a monitoring logic that buffers the obtained measurements following user configuration commands.

Energy control: control logic, taking into account the user commands as they have been decoded and submitted by the enforcement logic of a given appliance. Based on this information, the system performs selection of one of the several external interfaces to the household appliance.

EMDs shall be accessible either locally, through the AIM gateway or via external IP operator networks.

2.1.2 Standby mode implementation using an EMD

In AIM, stand-by control is performed by switching off the power outlet to which an appliance is connected. The EMD will be pre-programmed so that it ‘knows’ which appliance it is connected with. At any given time, the AIM gateway may choose to switch off the appliance by sending an execution command to the EMD. The AIM gateway would only be allowed to execute this task for specific sets of appliances (e.g. not for refrigerators) and under specific events; e.g. following a user command or time schedule (e.g. past midnight) or even automatically, by using the AIM sensor network.

Figure 5: Standby reference communication scenario

To implement an energy standby mode, an EMD should be aware whether the connected appliance is about to enter a standby mode. This information can be provided by the appliance itself (by sending a command to the Gateway via the Power-line network or I/F2, e.g. Wi-Fi, ZigBee, IEEE 801.11, etc) -or by an EMD implementation of real time energy consumption monitoring. It is worth noting that the energy consumption of a KNX [2] EMD control box is very low in sleep mode (~100 mWatts).



Figure 6: Energy consumption polling procedures

To support this cause, as can be seen in figure 6, AIM provides a series of energy polling functions, which are controlled by the AIM gateway, reaching the controlled appliance. An embedded database in the AIM Gateway is used to log the responses and provide value threshold checks.

Figure 7: Message flows for standby implementation

A similar case is evident in AIM Switch-off commanding, which involves the AIM actors and the AIM database. An AIM appliance notifies the AIM gateway on its standby state. The AIM gateway registers this event in the database and finally sends a switch off command to the appliance. A similar procedure switches on the appliance and registers the event in the database.



2.1.3 Energy Management in active mode using an AIM EMD

Active mode energy management constitutes the core of the AIM architecture and consequently of the EMD functionality. We should note that either Power-line or pure COM interfaces may be used in this case.

Figure 8: Active appliances management reference communication scenario

As we have mentioned, the EMD logic consists of: (a) energy monitoring, (b) energy management, (c)standby management. All other necessary EMD functions can be implemented either inside the AIM gateway, in the controlled appliance or as an individual external electronic box component.

In energy management the user sets a maximum energy consumption limit for the AIM topology, and the AIM network makes the appliance operations to conform to that limit through the EMD.

Figure 9: Message flows for active appliances management



2.1.4 EMD Appliance function types

The main functions managed by the appliance digital control systems, according to external data coming from the network, are the following five:

1. Power levelling

The control system of each connected appliance continuously compares the value of the current total power consumption with the current power threshold value and activates the “power levelling function” when it overcomes such threshold.

During the execution of power levelling function, each appliance reduces its power consumption according to its priority level, being such priority level dependent on appliance type and working status (or program phase). For instance, the oven’s priority is higher than the washing machine’s one because eating is more important than washing; similarly, washing machine’s priority during the heating phase is higher when the water temperature is cold and decreases when such temperature increases. Each appliance manages its power levelling function using two delay timers.

2. Load shifting

Load shifting function is driven by daily energy cost profile and based on real time clock. If the user enables the load shifting function on the washing machine, it starts working when the lower energy tariff takes place. In other words, the appliance activates automatically a delay timer for reaching the first low energy rate period. Load shifting function is applicable only to the washing machine.

3. Energy monitoring

The appliance control system allows the execution of this function by continuously sending its working status to the gateway. The gateway executes energy monitoring function by using the appliance energy profiles stored in its database. When a proprietary Power Metering Adapter is connected on the power line plug of the appliance, energy monitoring function can be directly based on the measured values of the energy actually consumed by the appliance.

4. Efficiency estimation

This function takes place when a proprietary Power Metering Adapter is connected on the power line plug of the appliance. Efficiency estimation is performed by comparing the measured energy consumption of the appliance with the expected one according to specific working phases.

5. Performance monitoring & alarm

This function takes place when the appliance control system detects a low efficiency working condition: for instance, when an open door condition lasts for too much time, depending on the appliance type. In such a case, the appliance control system sends an alarm message to the gateway in order to properly inform the user.

2.1.5 EMD physical communication interfaces

As it is depicted in Figure 4, the EMD exhibits communication interfaces towards the appliances that must control and towards the gateway with which it must be physically connected to exchange energy management control primitives.

Concerning the interfaces towards the household appliances, these are mainly specified by theEuropean Committee of Domestic Equipment Manufacturers (CECED) and are of the following types:

ZigBee short range wireless communication interface;

Bluetooth wireless communication interface;

Power line fixed network interface;

Serial interface;

Wi-Fi wireless communication interface.



The reason for adopting several wireless interfaces in the implementation of the EMD is to allowrealisation of different communication possibilities depending on user application. For example, in large houses the use of short range interfaces is not recommended and in that case can be replaced by fixed network or normal range wireless communication interfaces. On the other hand, when it comes to energy reservation, the low power network interfaces such as ZigBee and power line are recommended.

In the following sections we give a description of the European low bit rate power line communication protocol, called KNX [2], as we think it is the most important protocol for the implementation of the AIM architecture.

The other protocol definitions can be found in world wide standards and therefore their description falls outside the scope of this document.

The EMD version providing power line communication is connected to the gateway via a serial port of which protocol and supported primitives are defined in Annex A.

2.1.5.1 The KNX Power Line interface

The AIM EMD will make heavy use of the KNX power line communication stack technology. KNXconstitutes the core of the EMD interface to the power line net. The same communications media will be used to link AIM EMDs to either controlled residential devices or the AIM Gateway.

Figure 10: Modulation of digital data on power line signal

KNX is an open European standardized protocol, used by manufacturers of electronic automation devices to communicate information among their devices either using twisted pair wires, RF transmission, or power-line communication. The AIM EMD uses KNX power line protocols PL110 and PL132 (www.knx.org). The naming conventions used: PL denotes Power-line communications, 132 means 132Khz, 110 means 110Khz, which either-way are the central frequencies on which information is ‘loaded’ on the power line bus. KNX PL132 supports communications at rates of up-to 2400 bps between KNX devices, whereas PL110 reaches 1200 bps. PL110 and PL132 are low bandwidth protocols, nevertheless quite noise-resistant and excellent for communicating control signals over the power lines, on quite long distances, which can reach several hundred meters. . A wireless technology with similar features is DECT. Using a reserved frequency band (1880-1900MHz) it is less distorted than today’s popular wireless power switches using ISM band devices. Range is several hundred meters depending on building type.



Figure 11: Digital signals modulation techniques over power line signal

The above depiction demonstrates how a power-line base frequency of 50Hz can be ‘loaded’ with information, according to FSK (Frequency Shift Keying) technology. PL110 and PL132 are half-duplex protocols. This means that one KNX node is transmitting and one receiving intermittently – but and not concurrently.

2.1.5.1.1 CDMA access to the KNX Power-line bus

The network topology of the PL AIM EMD is based on a common access power line bus. Only one EMD device can use the bus at any given moment. All the other connected devices ‘listen’ to the bus traffic, and wait to find an ‘empty’ time-space on the bus to transmit their information. The technology used is ‘Carrier Detect Multiple Access’ or CDMA. If a device needs to broadcast a piece of information on the PL bus, it initially ‘listens’ to the bus, to determine if somebody else is broadcasting. If the channel is found to be occupied the device postpones the transmission for a later time, otherwise it transmits its information packet. Since PL110 and PL132 are low bandwidth communication protocols, they were designed to support both a peer-to-peer and multicast communications to conserve precious bandwidth.



Figure 12: Internal architecture of power line communication interfaces

2.1.5.1.2 EMD KNX PL110/PL132 network stack

The AIM EMD implements a KNX PL110/PL132 network communication stack. The words ‘Network Stack’ indicate the ubiquitous OSI-7 network layer. Indeed, KNX PL110/132 specifies 5 out of the 7 OSI network layers, namely Physical, Data link, Network, Transport and Application. Session and Presentation layers are not defined, and are thus considered transparent to their adjacent layers.

KNX defines 2 additional stack sub-categories, the router stack and the bridge stack. Routers are used to guide information through disparate KNX net topologies (think the equivalent of a network multiplexer). Bridges function as re-transmitters, to connect distant net topologies (e.g. as links between different power phases in 3phase systems ), or to amplify a weakened KNX signal source –since the maximum length in a KNX copper power-line is around 400-600m. The router stack and the bridge stack present differences in the network, transport and the application layers compared to the EMD device KNX stack. Since one can buy standardized PL110/132 KNX routers and bridges from a number of vendors, we do not need to address this issue.

The reader should note that the KNX protocol is layer flexible. It allows the KNX developer to turn stack layers on or off (starting from the top and moving downwards) up-to the data link layer. Certain applications are expected to run in very simple KNX network topology configurations, thus they need the first 2 layers to function properly. By disabling the overlaying stack segments, the stack implementation can be hosted in very minute and cheap microprocessors (typically in just 8 Kbytes of memory). When more complex topologies are necessary, the application designer must deploy additional layers, which support more complex net configurations, but need stronger micro-processors, both in terms of processing power and memory. A full PL110/PL132 device stack implementation can be expected to be hosted in 70Kbytes of code on an 16-bit micro-processor base, including support for network management procedures and net topology administration. This feature allows us to be equally flexible in engineering our EMD design – since KNX is foremost hardware base agnostic.



2.1.5.1.3 KNX Network topology and node addressing

Every EMD device on a power line net needs to be net-configured and obtain an individual and domain address, according to the KNX protocol. A fully extended KNX PL network has a 3-level structure. This is similar to an inverted tree. It consists of:

• Area line _ Area 0 (backbone line);

• Main lines _ Areas 1 .15;

• Lines _ Lines 1.1 .15.15.

Figure 13: Device addressing

The area line forms the network’s backbone. It has the physical address "0". 15 area couplers (AC) can be connected to the area line, and also bus devices, whereby the number of bus devices results from the difference [64 - number of AC].

From area line "0", the area coupler can branch off 15 main lines (main lines). The area couplers with which the main lines are created have the physical addresses 1.0.0 - 15.0.0. 15 line couplers (LC) can be connected to each main line, and also bus devices, whereby the number of bus devices results from the difference [64 - the number of LC].

From each main line, 15 lines can branch off via line couplers. The line couplers with which the lines from main line 1 are created have the physical addresses 1.1.0 - 1.15.0. (Line couplers from main line 15 have the physical addresses 15.1.0 - 15.15.0).

The KNX network is structured in domains and sub-networks. Information is passed from one place to the other using bridges and routers. In total, 64K devices can be co-hosted in the net and up to 255 devices can be linked per common bus.



Figure 14: Reference communication over power line

Each connected device (apart from routers and bridges) must have an individual address and possibly multiple group address assignments. This information in our application is stored inside an EEPROM table on the EMD a processor and is automatically registered during the configuration of the network setup, as we will explain in greater detail later on. Group addressing is a subscriber based model, used to broadcast information to multiple net recipients with a single data communication burst. Every node that belongs to the same group will receive it simultaneously, which saves communication capacity on the common PL bus.

2.1.5.1.4 The EMD hardware base

Our EMD is a hardware design based on the Microchip PIC18F6720 micro-controller and the ST7540power-line modem chip. Detailed specs on these ICs are available at the respective manufacturers’ web sites. The PIC processor should envelop all the reasoning to implement a full KNX protocol stack, it will perform all the real time operations necessary to control the waveform power line signal generation by the ST7540 modem, and will handle all communication requests to external devices (wireless / IP communications). There are two basic AIM hardware components which are connected to the EMD: an EMD energy metering unit and a TRIAC / dimmer module.

The energy metering unit (EMU) supplies the EMD with readings on the energy consumption of the EMD controlled device. The EMD TRIAC is an electronic switch, which will allow the EMD to cut-off or limit the power supply to the EMD controlled device.

The reader should note that the ST7540 modem does not offer any kind of firmware functionality. It is simply capable of informing the PIC micro-controller on signal carrier detection over the common PL bus, it introduces power line harmonics necessary to broadcast a high/low bit value on the PL bus, and will inform the micro-controller on bit values trafficked on the bus. The necessary digital signal processing, which will allow us to broadcast data on the power line and filter-out incoming noise will be delivered by the power line modem chip.



Figure 15: Signal modulation phases

The EEPROM hosted inside the EMD will offer the necessary persistency to register information like the network address of the EMD device, the group addresses this device subscribes to etc.

KNX specifies three configuration procedures, actually prescribing the three KNX installation modes, namely Easy, System and Auto. Our EMD implementation has been designed to deliver a virtually an automatic install procedure – compliant with the KNX Auto mode. When an EMD is connected to the power net for the first time, it will broadcast a message which the AIM Gateway will pick up via the power line. The EMD will be automatically placed in Program Mode, and will wait for the Gateway to set the EMDs individual address and domain address according to the KNX standard. Having set this information, the EMD will establish its post inside the KNX PL net, without any other user intervention. It is a real plug and play user experience.

The EMD will be a full fledged KNX device, which could receive commands not only through the power line, but also through a serial interface (RS232). This interface is called PEI (Peripheral External Interface), and is the means through which an EMD could be connected to a PC, or a Wi-Fi/ IP module. Our particular implementation uses PEI type 16, according to the KNX specification, which is based on RS232 communications.

Further on we will briefly describe the 5 stack layers that constitute the EMD power line functionality.

2.1.5.1.5 KNX Layer 1 – The physical Layer

This layer takes care of the communicating bit sequences from one KNX net node to other, transforming the bits into power-line waveforms. The diagram listed bellow describes the layer 1 packet format (KNX terminology lingo for it is frame) for the PL132 and PL110.

Figure 16: Data format

The KNX frame format is somewhat different in PL110, nevertheless similarities are evident.



Figure 17: Data layout

Either way, first a preamble, or undulating bit pattern, is broadcast on the bus. The PL modem can pick this up and identify the beginning of a KNX frame. Next follows a header, which signifies the identity of the protocol. Several different protocols can co-exist on the same power-line, thus a protocol ID is necessary. All subsequent information is safeguarded by a FEC (Forward error correction) pattern on every byte and a checksum at the end of the frame. FEC and checksum are using CRC calculation.

The power-line is a noisy domain, which can introduce several types of communication errors. Some can be corrected at the reception spot by the FEC information, and for those that can’t (caught by the checksum), a rebroadcast is mandated by the receptor. This layer implements the CDMA/CA (Carrier detect multiple access/collision avoidance) on the common bus.

2.1.5.1.6 KNX Layer 2 – The Data Link Layer

This layer is closely bound to the physical layer; it provides the minimum functionality that would allow a client device using a PEI to communicate data over the KNX net (on the same sub-network only). This layer takes care of communication attributes and problems, like corrupted data re-broadcasting, matching domain addresses, source addresses with destination addresses and group addresses, or setting broadcast priorities on the net.

Figure 18: Data link layer architecture

In the above diagram, we can see which messages are exchanged in this layer from one network node to the next. Without being overly detailed, there are a couple of points that are worth mentioning, which are also shared by all the overlaying layers in KNX.

All KNX internal messages are standardized, responding to prescribed functions. The ‘useful’ information is packed in a byte buffer which is called L_PDU (for this layer). This packs all the information coming from the overlaying layer. In other words, as the flow of command moves downwards, Application->Transport->Network->Data Link layer, this buffer is appended with more data. When the physical layer is reached, we must communicate the concatenated information from all

Network layer



the above layers. When moving up the communication chain (physical->application), information is thinned-out from layer to layer.

The standardized commands are attached with suffixes “.ind” (=indication), “.req” (=request), “.con”(=confirmation). These primitives control the information flow, responding to sequences of requests for information, which are sent from one net node to the next (either at a specific, or group address, or even to the whole network). Upon reception comes an indication from the remote node (meaning that an answer is broadcast) and finally a confirmation that the data has been received is sent back.

This pattern is typical for all intra-layer communication, which is an internal type of communication inside the PIC KNX stack implementation. Another point specific to this layer is the existence of busmonitor and polling messages, which are especially useful for designing thin implementations of KNX, giving direct access to the bus (in layer 1-2 only) functioning as KNX packet sniffers.

The KNX stack must implement a parser for the series of message exchanges, which correspond tocommand byte tags, forming discrete finite state machines; working inside the PIC micro-processor. Each layer must implement its own state machine, which becomes more complex as we move to the higher layers.

2.1.5.1.7 KNX Layer 3 – The Network Layer

This layer stands on-top of the EMD data link layer. It is responsible for controlling the communication pipelining from one network node to the next. The information buffer is N_PDU. A series of messages are exchanged between overlaying and under-laying layers of the respective net correspondents.

Figure 19: Network layer architecture

We also get the “.req”, “.con” and “.ind” communication primitives. Communication is either individually aimed (peer to peer), group oriented (peer to group) multicast or peer to network (broadcast). A respective collection of byte tags represents each function. We are also expected to implement a finite state machine for this layer, conforming to its message transaction reasoning.

The KNX spec refers to the communication modes provided by layer 3 using the following terminology:

1. Point to multipoint, connectionless (multicast);

2. Point to all points, connectionless (broadcast);

3. Point to point, connectionless;

4. Point to point, connection oriented.

2.1.5.1.8 KNX Layer 4 – The Transport Layer

The transport layer coordinates the communication flow, mediating between the application layer and the KNX network layer.

Transport layer



Figure 20: Transport layer architecture

Its interaction graph is quite complex and it is differentiated according to the communication mode requested from the network layer (unicast, multicast, broadcast, etc.). The communication functional unit in this layer is the TPDU. The communication flow is described in great detail in the KNX spec using a transition table representation of a finite state machine. In this description it is more elegant to depict its graph-node equivalent.

Application layer



Figure 21: KNX Protocol states and state machines

We can easily distinguish that the behaviour of the Transport layer depends on the KNX bus activityand it is thus action defined and event driven. For detailed explanation on each message’s meaning the reader should refer to the KNX transport layer specs.

2.1.5.1.9 KNX Layer 7 – The Application Layer

This is by far the most complex layer of the EMD KNX specification. It is responsible for supporting aset of 4 different functions, namely installer procedures, configuration procedures, network management procedures and application layer services. Communication and coordination in a KNX network are essential to the accomplishment of such a task. A device or control action is considered by KNX as a ‘functional block’, which is linked to sensors and human controls by ‘channels’. Sensors and controls use the described channels to convey variable data, which are called ‘datapoints’ in KNX terminology.



Figure 22: Application layer architecture

More than 200 standardized commands are defined for the KNX application layer. Every of them come with “.con”, “.ind’, “.req” suffixes, to control the data flow. It is outside the scope of this document to provide more than a cursory briefing on their functions. For a detailed explanation, the reader should refer to the KNX application layer specs.

Some of the basic commands listed there are:

Installation-wise

A_GroupValue_Read/Write, for reading/writing group values on a KNX node;

A_IndividualAddress_Read/Write , for reading/writing an address value on a KNX node;

A_DomainAdd_Address_Read/Write, for reading/writing a domain address value on a KNX node;

A_Propery_Value_Read/Write, for reading/writing data such as max transmission retries, max frame length etc on a KNX node;

A_Description_Read/Write, for reading and writing description commands on KNX nodes.

Communication-wise

A_Memory_Read/Write, used to alter the EEPROM memory contents on a KNX node;

A_Restart, for resetting a KNX node remotely;

A_Authorize_Request, to request a password from a KNX node;

A_Key_Read/Write, to read/write a password on a KNX node etc.

Another layer of commands (NM_* listed) deals with network management procedures; DM_* listed deals with datapoint broadcasting etc.

Every piece of information in the KNX stack is clearly pre-defined, be it data-point variable, functional block type, predefined channelling, etc.

The standard application messages and network management messages, as well as the complex flow of control interaction they generated must be inscribed in the PIC micro-processor logic. Extensive use of finite state machines must be made on each message category, to describe the rule engine invoked in each particular case.

On the following chart, we can visualize the interaction of message flow among the different layers of the EMD KNX protocol stack. Normal mode applies to a functional device versus a programmingmode which places the device in an identity inception role. The latter is used when the EMD is plugged in for the first time.



APDU

TPDU

NPDU

LPDU

SPDU

Figure 23: Mapping of data structures



Figure 24: Internal KNX primitives overview



2.1.5.2 EMD with wireless interface

A wireless version of the EMD is implemented as well. As mentioned earlier DECT technology offers similar features as PLC concerning reach, stability and bi-directional communication. In addition encryption is built in and low cost chips for DECT technology are available.

The DECT EMD re-uses large parts of the KNX EMD:

Mains control and power measurement;

Protocol stack above layer 2.

The DECT EMD is complementary to the PLC EMD in applications where PLC technology is not usable for any technical or non-technical reason. It contributes to the AIM goal of providing energy saving means as fast as possible to the consumer.

Integration of the DECT EMD to the home network according to Figure 36 is facilitated by the fact that many home gateways include a DECT base station.

2.1.6 The EMD hardware implementation

The architecture of AIM EMD is depicted bellow.

Figure 25: EMD Hardware implementation diagram



* MAU (Mount Access Unit) in this case is the ST power line modem.

The EMD will possess two basic communication ports: one will be a USART channel (RS232) and the other will be constituted through a power-net link. The USART will allow us to bind an EMD toexternal hardware modules, which provide services such as wireless communication services or deliver IP connectivity (External User Application). A similar option will be available with a USB interface to IP and wireless modules.

Inside the EMD, External Message interface commands will be mapped into an internal format which is called ‘Internal Message Interface’. This is the command message language that the KNX layers use with each other. Moving commands up and down the stack layers and on the KNX bus would be useless unless we could add persistence and reasoning to them.

The AIM EMD will be equipped with 1Kbyte of EEPROM which is used to store persistent KNX data (e.g. KNX network address ID, network groups etc – Bus Access Unit’s non volatile memory). The KNX EMD must be able to process the user data (coming from the client device) into Group object data (in other words, standardized commands, aimed at possibly many recipients on the KNX net of specific Functional Blocks) and interface objects, working as conceptual information conduits between KNX devices and sensors, linked to one another. This virtual linking phase will be automatically handled at the net setup phase; a process which must be also supported by the command parser of the AIM EMD.

The API (Application programmers interface) refers to a KNX specified set of code functions, whichthe EMD micro-processor must support into order to be able to process commands coming from the client device. Most of the API calls work quite similar to the ANSI C standard library.



Figure 26: AIM EMD

The EMD receives an energy reading on its controlled device through an EMD energy meter circuit based on the STPM01 chip. It is also able to control the energy power that reaches the controlled electric load by using a TRIAC circuit. There is a hardware extension interface on the EMD, which



makes it possible to connect this device to other electronic boards, delivering complementary communication protocol functionality(e.g. TCP/IP) or enhanced control interfaces (e.g. infrared).

2.1.7 The EMD firmware roadmap

The AIM EMD will be a hardware device constituting a composition of a power line modem and an embedded micro-processor, exporting a serial interface and possessing 1Kbyte EEPROM with 3Kbytes of RAM. The process of hardware integration will not be addressed in this short description. Nevertheless, we can focus on the firmware design challenges that this project presented.

The basic development steps that the AIM EMD encompassed are the following:

1. Abstracted KNX stack design (layer by layer)

The definition on each layer’s functionality is available in detail in the KNX spec documents.

2. Generic finite state machine for KNX stack layers design

Each KNX stack layer is a layered finite state machine/parser. We use 4 of these structures, for the Data link, Network, Transport and Application layer, respectively.

3. KNX internal message pump in conjunction with a finite state machine

The Transport and Application layer need an event handler on-top of their Finite State Machine. Their defined behaviour is quite complex and dependent on the client device’s functionality state (idle, working, receiving information, etc). This means that their state machines must be aware of the external functional environment, which is guaranteed by the implementation of an event handler – this event handler is executed in the transport layer of KNX.

4. EMI/IMI parameter parser for each KNX layer

There is a clearly defined interface for communicating with the KNX stack. When commands reach the stack from the outside by a PEI16 (application-wise it is a RS232 serial port), the commands must be coded in EMI (KNX External Message Interface) format. These commands are translated into IMI (KNX Internal Message Interface), which actually controls the information flow among the KNX stack layers.

5. PEI16 protocol implementation

The PEI16 protocol is defined both physically (electrical signals) as well as abstractly by the KNX specs. For further information, the reader should refer to the KNX.org KNX PEI specification. It is conceptually a set of control codes communicated over RS232 between the client device and the AIM EMD.

6. EEPROM and KNX Virtual RAM interface engineering

Since the KNX is an open standard, (hardware platform independent), no hardware specs are provided. Instead, for all hardware related functions, such as the ones that deal with the persistency of a KNX device, the specs define abstract functions. These must be translated into concrete ones by our KNX PL implementation. Thus we need to define EEPROM virtual access points for the particular micro-processor base we are using. There is an area in the RAM which is used to store KNX object RAM data – thus a Virtual RAM interface has been incorporated in the stack to access this area in a uniform and KNX standard compliantmanner.

7. KNX API implementation

The KNX API is a set of functions that the KNX micro-processor must implement in order to be able to process KNX messages. It is the standard function library of the KNX micro-processor world, irrespective of hardware base chosen.

8. KNX object attribute translator

The object constituents of KNX device data are not just arbitrary framed byte collections. In KNX topologies, the KNX net is used to communicate information between logical entities, called functional blocks, which are atomic operators in a KNX system (like an actuator, a push button or a sensor). All these come in predefined types, with standardized inputs and outputs.



This format must be parsed both as the broadcast (message formulation) and the reception end; which is what the object attribute translator does.

9. Implementation of KNX net setup message parser

This is a message conduit, aimed mainly to ‘personalize’ the KNX device, by registering its identity. The messages that are processed interact with the BAU’s EEPROM, by reading/ writing or altering its contents. This functionality is used mainly during the setup phase of the network and has to do with placing a device in programmable mode, one at a time, making it perceptible to receiving personalization commands like receiving its KNX individual and domain address. In AIM we had to develop a setup procedure that could be automatically completed – similar to plug and play.

10. Low level engineering to interface and host the AIM EMD BAU on a PIC18F6720

This process involved all the low-level implementation details that had to go into engineering the KNX EMD system; selecting portions of the code to go into specific memory areas, and developing the ST7540 driver over the PIC18F6720. The ST7540 is not equipped with firmware; it must be controlled by the PIC186720 using real time gate-logic. (FSK keying modulation of data, error correction, frame check sequencing, etc.).

11. Testing and Simulation in vitro

The firmware codebase is unit and simulation tested before being ported into a micro-processor. It has to be immune to buffer overruns, not use dynamic memory allocation – de-allocation techniques, and it has to be crash immune under any circumstance and KNX traffic load. Since the KNX stack is a real-time system, without the benefit of being hosted on a Real Time Operating System, it is critical to verify that all atomic operations are executing in proper time frames, compatible with the KNX stack communication speed requests.

12. Integration with Energy Meter and TRIAC

The completion of the EMD development coincides with porting the firmware code into a PIC186720, and interfacing it to an energy metering and TRIAC soft-switch module. This compound module should be connected to a PL KNX net topology and be operated remotely by the AIM Gateway. Operationally-wise, the EMD’s auto setup mode should be verified. The KNX defines a set of test-cases to which our KNX implementation should rigorously comply.Add -on boards like Zigbee, IP or 802.11 will be tested additionally to the power line net.

2.2 Internal interfacesInternal interfaces are only used when the EMD is integrated with the controlled device. In simple configurations, the EMD firmware can be hosted inside the residential device’s microprocessor, or there may by a dual processor architecture, with one microprocessor controlling the residential device and the other implementing the EMD functions. Either way, there are standard messages exchanged inside the compound EMD and residential device hardware, which adhere to the KNX specification IMI1.0 (Internal Message interface) protocol. Information on IMI can be tracked in the KNX specification available from knx.org. Moreover there are numerous service primitives that are communicated inside the KNX stack, when information flows from the physical to the application layer and vice versa.

2.3 External interfacesAn AIM EMD can be integrated to the controlled appliance, be integrated in the AIM Gateway, or be installed as a standalone control-box between the controlled residential appliance and the AIM Gateway. Each scenario is examined case-by-case.



2.3.1 EMD integrated to the controlled appliance

This EMD option is found in appliances already implementing a generic communication way, e.g. an internally integrated power line communication interface. In this case there is no need of connecting externally an EMD and the AIM logic can communicate directly with the appliance.

2.3.2 EMD integrated to the AIM logic

The same external protocols mediate the connection between EMD and appliance. This EMD option is available for appliances that implement communication interfaces other than power line, such as ZigBee, IEEE 802.11, Wi-Fi, etc. In that case, the energy management logic contained in the AIM logic communicates directly with the appliance without the need of introducing external communication equipment.

2.3.3 EMD as an independent control box between Gateway and appliance

In this case, the connection between Gateway and EMD is achieved using power line communications protocols like KNX PL110/132 or any other communication interface. The connection between EMD and controlled appliance can be constituted using either wireless (802.11/Zigbee) or power linecommunication media.

2.3.4 Interfaces toward the appliances

There are many energy consumption appliances from different companies in a household. All these appliances don’t have the same interface and same functionality. Even appliances from the same manufacturer may have different interfaces and functions. Functions are depending on the complexity and the construction model of the appliances. Simple appliances like coffee machines do have less functionality than high sophisticated appliances like washing machines. Even the interface is depending on the state of the art and the complexity of the appliance. The replacement interval of many household appliances is long so the standardisation in this application field takes place very slowly. For the faster accomplishing of energy saving functions with household appliances the EMD is invented.

The advantages of the AIM architecture will be shown with three different categories of household appliances. These are A/V equipments, COM home equipments and white goods.

For the AIM project there will be the following appliances with an internal or external EMD interface:

White goods- Washing machine

- Oven

- Fridge

A/V Equipment

- TV Set

COM Equipment

- ADSL2 Router

The following appliances and interfaces will be a part of the AIM project:

Interface/appliance Washing machine Fridge Oven TV ADSL2 RouterManufactory Indesit Indesit Indesit Philips InfineonType 32PFL96130/10 EASY 50812Hardware Interface RS232 RS232 RS232 LAN/IR LANTransport Protocol TCP/IP TCP/IPApplication Protocol CECED CECED CECED RC5/RC6 AIMEMD functionality no no no no yes



In this table the communication interface and the communication protocol of each appliance is shown. There will be an ADSL2 Router with an integrated EMD functionality which supports the AIM protocol. All other appliances use different protocols and need an EMD to fulfil the AIM specification.

To get the power consumption information and to control the appliance, different commands and functionalities are offered. Each appliance has it specific command set.

The following table shows the supported functions by the appliances:

Functions/Applaince Washing machine Fridge Oven TV RouterType 32PFL96130/10 ADSL2Interface RS232 RS232 RS232 LAN LANAIM-Functionality no no no no yesStatus yes yes yes no yesactual power consumption yes yes yes no yesfault notification yes yes yes no nodelay before run program yes yes no no noSwitch on/off no no no no yes

Many appliances have basic functions for power measurement and status information. Functions to control the power consumption of the appliance via the interface connection differ from one application to the other and are seldom. There is one appliance with an integrated EMD functionality and the AIM protocol. To communicate with appliances without AIM Protocol an EMD is needed.

The main function of the EMD is to exchange information from and to the appliance and transfer it with the standard AIM Protocol to and from the AIM gateway. Additional functions for power control and power saving which are not implemented in the appliance can be added through the EMD.

The EMD will be designed by the appliance-manufacturer itself or by a company which participates in the AIM project, so different EMDs will be build. Other project partners are non appliances manufacturers, but services or communication companies. These companies will contribute with equipment for internal and external communication with the appliances. In the future an optimized EMD integrated in the appliance or also external will be the best way to support the AIM functionality. The following table shows different EMD instantiations and functions:

EMD-Type KEL-EMD DOE-EMD IFX-EMD PHI-EMD PHI-GatewayHome-Gateway-Interface Powerline LAN DECT LAN/WIFIshort-range Interface Zigbee ZigbeeAppliance-Interface Powerplug RS232/Powerplug Powerplug powerplug LANAppliance-Protocol CECED CECED no no RC5/RC6Additional Functionson/off yes yes yes yes nopower-saving-options yes yes yes no noEMDs for appliances with different interfaces and protocols adapted to each appliance will be developed. Furthermore the EMD will implement additional functions for power measuring and control.

2.3.4.1 The DECT Interface and Technology

The DECT [3], Digital Enhanced Cordless Technology (previously Digital European Cordless Technology), went through a remarkable evolution in the past decade due to its rapid growth on the market. The technology that allowed the wireless voice transfer was developed and standardised by the European Telecommunications Standards Institute (ETSI) [4]. The first standard was released in 1992. The work was concentrated to define an interworking profile for public telephony (PSTN), and business environments (PABX), released as the General Access Profile (GAP), followed later by additional profiles like DECT/GSM, and DECT/ISDN defining GSM and ISDN operation over DECT



[5]. These profiles are defined to provide the base functionality required to assure compatibility between devices from different manufacturers.

The DECT forum [3] is made up from representatives from different manufacturers and service providers. This organization is working closely with ETSI to assure, that solutions are elaborated in accord with market needs. The role of the DECT forum is to set requirement specifications before ETSI, which will provide the experts for realization [6]. This cooperation assures that solutions are made for present needs.

Figure 27: The DECT frequency/time spectrum

DECT technology uses Multi Carrier, Time Division Multiple Access (TDMA) and Time Division Duplexing (TDD) techniques in the physical layer. Multi Carrier has the used frequency spectrum, between 1880 and 1980 MHz, divided into 10 carriers1. Time divided, because the time spectrum is divided into 10 ms long timeframes. A timeframe is further divided into 24 timeslots, presented on Figure 27. In theory, the DECT standard could support 24 devices on each of the 10 frequencies, altogether 240.

1 The frequency range varies depending on location. In Europe 1880-1900 MHz is used, but outside Europe 2010-2025 MHz may be used, while in the US 902-928 MHz and 2400-2483,5 MHz have been defined. 0



Figure 28: DECT Basic STAR topology

To provide full duplex mode, which is required for telephonic function, half of the timeslots are used for downlink, and the other half for uplink. Thus, the usable devices in full-duplex mode are reduced to 120. This means that in theory 120 phones, called Portable Parts (PP) can be used with one Base Station, called Fixed Part (FP) which is attached to the PSTN (Public Switched Telephone Network) in the GAP scenario. The typical STAR topology for that scenario is presented on Figure 28. Accordingto the standard, the base station scans the 10 frequencies at once. The high capacity and the usage of protected frequency band made it possible to widen the scope of the usage of this technology.

The PP runs an algorithm called Dynamic Channel Selection and Allocation when needed to establish a connection to the base station. Even on incoming calls, the PP establishes the connection. The PP periodically scans the frequency band, and calculates an RSSI (Received Signal Strength Indication) list based on the determined occupancy of the frequencies. Frequencies having lower RSSI number are less occupied. The base station also monitors the occupancy and transmits its bearing signal in one, or more of these frequencies. This signal carries information about the base station, e.g. for synchronisation for a PP to know when to connect to the FP. It is important to note that PP only connect to the FP when establishes a call, or special cases for other type of information exchange. The PP is therefore not connected to the base station most of the time. Upon call initiation, the Fixed Part transmits its signal on the channel with the lowest RSSI number in time of the transmitted synchronisation information. During the call, the PP and the FP send uplink and downlink data accordingly in their allotted timeslot. The uplink timeslot is always followed by a 12 timeslots delay from the downlink, as can be seen on Figure 27, where ‘a’ and ‘b’ represents two separate connections.

The original DECT standard has defined possibilities for creating DECT cellular networks. Distribution of base stations in an area increases the coverage of DECT and also the number of usable devices. This is very useful in smaller home environment and also in enterprise premises, like in case of PABX (Private Automatic Branch Exchange). For PPs moving outside the coverage of the FP seamless handover technique was defined. The PP detects the weakening of the signal of the connected base and a stronger signal initiates connection with the other base. When one of the signals gets significantly intense than the other one, then the weaker connection gets dropped by the PP. During the procedure uninterrupted service is guaranteed so QoS is maintained.

DECT proved to be outstanding in terms of standard voice transfer, however spreading of Internet formed new demands on the market. The Internet Protocol (IP) became the de facto standard used for



packet delivery on the Internet. ETSI standardized DECT Packet Radio Service (DPRS) profile defining ways to implement packet-data services over DECT [7]. Using this profile makes it possible to extend IP networks to Portable parts un-terminated, and transparently. This means, that IP protocol above DECT can be implemented, allowing IP packets to traverse to the PP. The main application scenario for DPRS is VoIP, thus allowing VoIP phones as portable parts. DPRS remained to be used in the upcoming next generation DECT standard, the CAT-iq (Cordless Advanced Technology—internet and quality).

2.3.4.1.1 Next generation DECT: the CAT-iq standard

The standards defining this new technology are under standardisation since 2006, the process expected to be ended by 2010 according to information presented by the DECT Forum [8] [9]. CAT-iq (Cordless Advanced Technology—internet and quality) offers a great deal of new features and enhancements from DECT, while still relying on the lover layer DECT protocol stack. The name suggests that this technology is related to internet. The fact is that it prefers the DPRS (DECT Packet Radio Service) profile in most scenarios. From CAT-iq 3.0 every device will communicate via IP. In CAT-iq 4.0 smart home integration is targeted [10]. CAT-iq will completely replace the old DECT standard.

Figure 29: Used frequencies of DECT and CAT-iq

The most significant feature of CAT-iq is the enhanced voice quality, which comes from the increased data-rate. Standard PSTN technology as well as DECT is designed to transport voice between 300Hz and 3,4kHz frequencies. Most of the human speech is in that frequency range. Nonetheless above and below this range there is voice recognizable to human ear, which can be experienced by talking with someone in person (Figure 29). In the CAT-iq standard therefore the recommended frequency range expands between 150Hz and 7 kHz, with a 16 kHz sampling in-between [11]. To transport the increased amount of data at the same speed a higher bit rate should be achieved. The original 32kbit/s bit rate has been doubled to 64kbit/s, to comply with this purpose defined in CAT-iq. Achieving this brings up technological challenges; more complex modulation techniques are required. With the spreading of Broadband internet these goals are no longer constrained. DECT uses ADPCM (Adaptive Differential Pulse Code Modulation) for voice sampling.

The original DECT standard used GFSK (Gaussian frequency-shift keying) modulation to convert digital signals to analogue form. This very simple modulation has been used by early modems as well. The frequency of a simple carrier (sinusoid) signal is altered depending of the transported bit. The information is decoded bit by bit on the other side. A Gaussian filter is used to shape the wave, so to



reduce the effective bandwidth making it more resistant to changes in a noisy environment. The new standard [12] allows additional DQPSK (Differential Quadrature Phase Shift Keying) or QAM (Quadrature amplitude modulation) modulations to be supported by devices, but only while maintaining backward compatibility with the default GFSK modulation.

Figure 30: CAT-iq Application examples

Besides advanced voice quality support, CAT-iq offers numerous application scenarios mostly for the home environment (Figure 30). It has a generic goal to offer internet connectivity to home appliances, for example, audio and video streaming among devices, internet radio, or internet TV, which requires low data-rate, but quality of service. On the other hand, other application areas, such as High Definition TV (HDTV) streaming, and high speed internet download capability are not designated applications for CAT-iq. For this, LAN or WLAN techniques are recommended [13]. Other application profiles, like sensor network integration and home control, are under definition. These aim complete integration in the home environment to contribute achieving intelligent decision making and control.

2.3.4.1.2 Home Integration

The integration of different technologies in the Home is pursued by three players: the DECT Forum, the European Telecommunications Standards Institute (ETSI), and the Home Gateway Initiative (HGI). The last one is to define requirements, and use cases for the Home Gateway, which is to be the central service provider in the home. The term gateway in telecommunications refers to a network device, which supports passage of data between different technologies. HGI has released a document describing the requirements of the Home Gateway based on present demands and predicted trends[14]. According to this document the so-called Home Gateway should support broadband internet connection, VoIP, POTS (Plain Old Telephone Service), and integration to IMS (IP Multimedia Subsystem) in one box. IMS is a multi-layered network architecture to integrate different technologies, like GSM/UMTS and IP networks, and to offer compatibility and multimedia services sharable between them. The application layer is common providing transparent cooperation of technologies while maintaining QoS [15]. To provide individual and easily obtained services, IMS builds upon the Service Oriented Architecture (SOA). SOA defines individual services with common interfaces for



easy deployment, upgradability, and integration. This technique is commonly used in software development nowadays.

Figure 31: CWMP End-to-End architecture

With the usage of the Home Gateway concept and technologies now being developed for cooperation and SOA based services, a higher level of interoperation can be achieved in the Home Environment. Requirements specify the Home Gateway to be plug-and-play as much as possible. SOA provides easy manageability that can be achieved remotely, even without user interaction. Broadband Forum’s technical report TR-69 defines the CPE (Customer Premises Equipment) WAN (Wide Area Network) Management Protocol (CWMP) [16] to manage Home Network devices from a remote server. The application scenario is presented on Figure 31. The features of this protocol are auto-configuration of managed devices and dynamic service provisioning, software/firmware management, status and performance monitoring, diagnostics, and identity management to allow web-sites to customize their content based on the devices. The main target of this protocol is the Home Gateway on the user side, but can be implemented in other network devices managed by the Home Gateway. The devices are managed by the Auto-Configuration Server (ACS) on the provider side. The protocol builds upon TCP, uses SSL for security, and HTTP to transport SOAP (Simple Object Access Protocol). The CWMP application layer protocol uses Remote Procedure Calls (RPC) sent in SOAP messages. This protocol opens new possibilities for the future Internet, where intelligent Home Gateways are completely plug-and-play. Maintenance will be done by the provider itself, without the involvement of the user. It is nevertheless an issue how much interaction should be allowed by the provider in the homes of individual users. It should be decided by the user how much of the provider offered features are in his or her need.

2.3.5 Interfaces towards the network

The AIM EMD will be able to access both external and internal networks. External networks will be mainly accessible using IP technologies. This will be mainly used to allow utilities and ISP to dispatch commands and receive readings from EMDs without necessarily going through the AIM gateway.

The EMD will rely heavily on power line communications as well as wireless and IP protocols to control connected residential devices. The physical integration with the AIM communication network dictates the adoption of a generic interface, such as the Universal Serial Bus (USB) or even RS232, which will grant connectivity of an EMD to any physical medium, wireless (Zigbee, Bluetooth, Wi-Fi, GPRS, etc), fixed (802.11, PoE, etc) or Power-line (KNX, LonWorks, etc).

Concerning the physical integration with household appliances, the project will use information from appliance manufacturers in order to build a generic bus through which the various commands will be



enforced. Interworking of the AIM power management architecture with communication networks shall be made on the basis of exploiting the capabilities of the IP protocol of the EMD.

An Interface which has been specified as D in D2.1 is the interface between the AIM EMDs and their controlling Gateway. Since the AIM domestic network is essentially hierarchical, typically the flow control will be governed by an AIM Gateway. This is the device that accepts commands from external actors and channels them to specific or grouped EMDs in the system, to make the controlled devices comply with the energy consumption pattern requested. Interface D will support multiple wired, wireless or power-line communication technologies,, like power-line , ZigBee, Wi-Fi etc.



3 EMD Architecture

3.1 OverviewThe Energy Management device (EMD) is a piece of hardware that resides between the household appliances and the Home Gateway. Functionally it hosts the logic for energy management and control of household appliances and act as a middleware towards the home gateway.

Nowadays very little percent of appliances are capable of measuring the power consumption of their own. Even if this technology were commonly used, it would not be a crucial information source for most of the users. The collection of such information is nevertheless the first step towards creating an information system, which can involve users in conscious decision-making. The EMD that collects data from the appliances and transmits control hosts its services for the Home Gateway.

The EMD will be constructed as a logic, which can be integrated into any households. To achieve this, it will be connected to power plugs making it able to monitor and control multiple appliances. The different components of the EMD can be distributed in the house, connected by existing wired or wireless solutions making it transparent and unnoticeable by the users.

3.2 Internal components and functions

Figure 32: Functional components of the EMD

The main controlling unit of the EMD is the microprocessor. The microprocessor is to address the individual appliances and transmit control messages in a standard interface to the addressed appliance or appliances. It has an operating system, which runs the drivers for communication to both sides. The messages sent from the Home Gateway are processed by the microprocessor and translated to serial format control messages for the microprocessor. For incoming measurement data the microprocessor will provide clock and be the master in the communication. The master/slave model induces polling of the slaves by the master, hence not permitting slave initiated communication. This technique is simplerthan allowing the microcontroller to take the role of the master unless functions generating interrupts are defined on the appliance side.

The microprocessor is connected to one or more microcontrollers on SPI (Serial Peripheral Interface) bus as can be seen on Figure 32. The microprocessor has to support SPI communication through hardware or simulate the operation in software on standard GPIO (General Purpose Input/Output) outputs.

The SPI is a very simple communication standard consisting of at least 4 wires: the Clock output (master to slave), the Master Out Slave In (MOSI), the Master In Slave Out (MISO) and at least one Slave Select wires. In one clock cycle the master and the slave exchange one bit information in full duplex mode. The master uses the Slave Select line to enable a particular device; therefore enabling multiple slaves requires a Slave Select line to each device.



The microcontroller is a simple computer consisting of counters, Analogue/Digital converters, a Flash memory, comparators, multiplexers, etc. These individual units can be programmed to achieve the desired function. This solution is more reliable and cheaper than a complex processor for such low-level functions.

The microcontroller operates one or more switches, which are used to switch on and off the power current. By using a relay in the power switch we can control high power current with low power signals. The relay has an electromagnet, which acts as a switch by applied power.

Measuring the power consumption of the appliance is done by the Power metering logic. It consists of a separate voltage and current meters. Since it does not have an internal clock by default, it cannot calculate performance. Performance is calculated on the microprocessor instead.

Figure 33: Distributed EMD architecture

The switch circuit is connected between the AC source and the output power plug, while the Power metering logic is connected between the output plug and the microcontroller. These can be integrated along with the microcontroller in the power plug, or a different power plug module, which is plugged in the power plug. The architecture of this type of integration can be seen on Figure 33. The EMD is separated into the core consisting of the microprocessor, and a wireless transmitter, and the appliance side consisting of the microcontroller, the switch circuit, the power metering logic, and the wireless transmitter. This way, there can be any number of EMD power plugs controlled by the EMD core without the need to define the exact number on realizing the device. The microprocessor can address the end device in the beginning of the transmittable data. On the other side, the microcontroller can generate the Slave Select signal by decoding the address bits.



Figure 34: Architecture of the EMD Power Plug Array

A proper microcontroller is able to control and monitor several appliances. An array of EMD power plugs can be created with one microcontroller and wireless transmitter. The architecture of this array is represented on Figure 34. Using this power plug array any number of appliances can be connected to the AIM network.

3.2.1 Integration with the network

3.2.1.1 Integration with the home network

In the indoor communication scenario, EMD will offer power management services to applications hosted on the AIM gateway (flow 1) or on PC terminals through the AIM gateway (flow 2) or directly (flow 3) via short range wireless interfaces or the GPRS network.



Figure 35 : Indoor and outdoor communication scenario

In the outdoor communication scenario, an EMD will offer its services to users residing in public networks, through operator services running either in cooperation with the AIM gateway (flow 1) or in standalone (flow 2).

Privacy and confidentiality of user data circulated in the outdoor networks will be ensured by the application of proper encryption of messages exchanged between the EMDs and the AIM network.

Encryption will maintain user anonymity in the processing of energy consumption data by third parties, by suppressing user identity. The interfaces that the EMD will exhibit to external communication networks will be of generic type, so as to allow connectivity with any type of wired/wireless communication networks, like Zigbee, Bluetooth, power-line , Ethernet, etc.

3.2.2 Protocol stacks

The role of the EMD, depicted in Figure 36, is to facilitate logical communication of the residential gateway with the domestic appliances so that appliance programmes control and status retrieval is realised in a generic way independently of the individual communication requirements of the appliances.

In that sense, there is always a universal protocol that conveys communication between the energy management logic of the AIM Logic and the EMD device, whereas, on the other side, this protocol is translated by the EMD according to the requirements of the proprietary APIs of the connected domestic appliances.



Home Network

Home or OutdoorNetwork

AIM Logic

ResidentialGateway

EMDSlave

DomesticAppliances

KNX Power LineNetwork

Appliance API

IEEE 802.11, ZigBee, etc

User Applications

User Terminal

EMDMaster

EMDIEEE 802.3 and/orEMD

Alternative locations of the EMD

Alternative physical network interfaces

Appliance Profiles & Status Database

Figure 36: Reference communication scenario for energy saving services implementation

Thus, an EMD can be implemented in various forms depending on the available home network type and the physical communication APIs supported by the connected domestic appliances. Two possible communication scenarios involving different EMD implementation are depicted in Figure 36.

If white goods are to be controlled, communication of the AIM Logic with the appliance must be implemented over the KNX power line interface, which is the interface of choice for white goods manufacturers. In that case, the EMD is implemented in two parts. According to the KNX protocol standards, an EMD KNX master communicates simultaneously with many EMD KNX slaves, implementing appliance control and status retrieval. Today, most white goods manufacturers have KNX enabled power line interfaces already integrated in their appliances and therefore the use of an external EMD KNX slave is not required.

For other domestic appliance types, such as audiovisual (TVs, Set-top-boxes) or communication equipment (DECT terminals, wireless hot spots, routers, etc), communication with the AIM Logic can be implemented using wireless or fixed network interfaces, such as ZigBee, Wi-Fi and IEEE 802.11. In that case, the EMD can be located either on the appliance or the AIM Logic (as is depicted in Figure 36). In the latter case an interworking function on the AIM Logic is needed for the translation of the messages of the universal protocol into primitives compatible with communication requirements of the domestic appliances.

Under the given communication scenario, estimation of the energy consumption figure of the household is accomplished by reading the status of all connected appliances and using it as index in the appliance profiles database to retrieve their real consumption figures.

3.2.2.1 Protocol Stacks

The communication between the energy saving services of the AIM Logic, the user applications and the domestic appliances is based on the adoption of the Internet Protocol (IP) that ensures interoperability across home and wide area networks.



Figure 37: Protocols stacks for the implementation of energy saving services

On the user-AIM Logic communication side, user applications are realised using web service calls over the HTTP protocol. In this way, access to the services of the AIM Logic takes the form of browsing the web pages contained in the web services server hosted on the AIM Logic.

Design and implementation of the web service calls between the user application and the AIM Logic is a work item of the WP4. The web service platform fulfils the purpose of allowing residential users to realise different applications like energy and media control, supervision and remote service.

The type of messages that this web service interface will convey will be defined and implemented in WP4 as part of the design of the logical interface A [17].

On the AIM Logic-appliance communication side, two new protocols are introduced.

The machine-to-machine (M2M) protocol has the role of harmonising communications between the energy saving services contained in the AIM Logic and the connected appliances by providing a single API that can be employed by the AIM Logic services for the implementation of appliance programmescontrol and status monitoring functions. AIM has decided to adopt the M2M protocol developed in the frame of the ESTIA project [18] on the ground that the ESTIA M2M protocol is already providing an API suited for controlling household appliance functions and because from architectural point of view ESTIA M2M is IP based and its binaries are compatible with the OSGi software environment.

Apart from the M2M protocol AIM has introduced the Universal Energy Management protocol that offers a unified way of implementing communication between the AIM Logic and the connected appliances by offering a generic message format for the realisation of control and status commands as well as a method for processing incoming status messages and generating outgoing requests.

3.2.2.1.1 Specification of the Universal Energy Management

The messages of the Universal Energy management protocol are exchanged between the AIM Logicand the appliances encapsulated through the EMD in IP packets, using the Undefined Datagram Protocol (UDP).



In the direction from the AIM Logic to the appliance, commands of the Universal Energy management protocol are captured by the EMD and translated into messages compatible with the protocol requirements of the appliance that the AIM Logic message is addressed to, while in the opposite direction, messages issued by the appliances as responses to the AIM Logic commands, are assembled by the EMD into relevant Universal Energy management messages, using the message format outlined in Figure 38.

3.2.2.1.1.1 Message format

Messages exchanged between this protocol and the EMD that connects the appliances has the format shown in Figure 38. The first field has a fixed length of two octets and indicates the total length of the message in octets. The second field has one octet length and is a sequence number which is always incremented by one and is used by the recipients of the message to detect lost messages.

The command ID indicates the type of the conveyed command. For expandability reasons, this field has a variable length defined in the first octet. The last bit of the last octet of this field indicates command’s direction that is, a Request issued by the AIM Logic toward the appliance or a Responseissued by an appliance in response to a AIM Logic command. The remaining part of the command ID field is used for the encoding of the energy management commands.

Figure 38: Message format of the Universal Energy Management protocol

The following commands types are supported:

User programme swap request: A request sent by the AIM Logic to instruct an appliance to swap the programme currently operated with another less energy consuming;

Switch off command: a request sent by the AIM Logic towards an appliance that must be switched off;

Switch on command: a request sent by the AIM Logic to an appliance that is switched off and now can be switched on again;

Command acknowledge: a message that can be issued by the AIM Logic or the appliances as a response to a previously submitted command;

User status request/response: Instructs the appliance to send back its status;

Error: a message used for reporting errors, such as command execution failures.

Command ID Command value (in Hex)

Direction

User programme swap request 0x10 Request

Appliance switch off command 0x20 Request

Appliance switch on command 0x30 Request

Command Acknowledgment 0x40 Response

User status 0x50 Request/Response

Error 0x60 Response

Table 1: Command ID, values and message direction specification



The appliance ID has a fixed length of two octets with the first octet indicating the appliance category (e.g. white goods, audiovisual equipment, brown goods, etc), and an incremental number that allows appliance identification in cases where more than one appliances of the same type exist in the household, e.g. two refrigerators, three DECT phones, and the second octet indicating the exact appliance type, for example washing machine, kitchen, etc.

The payload field has also variable length and contains information pertinent to the command type.For example, if the message is a user status response the payload field contains the state of the appliance such as power state (active or standby) and user programme. The format of the payload field is depicted in Figure 39.

Figure 39: Payload field layout

The content of the payload field is defined per management procedure in ANSI C format:

{

unsigned integer current_user_programme;

unsigned integer new_user_programme;

}payload_field:user_programme_swap_req;

payload_field:switch_off_command=0;

{

unsigned integer user_programme; // indicate the user programme the appliance should be set in

}payload_field:switch_on_command;

{

unsigned integer result; // indicate whether the command has implemented (result=0) or not //(result=1)

}payload_field:acknowledge_command;

payload_field:status_command_req=0;

{

short integer state; // state=0 switched off, state=1 powered on, state=2 standby

unsigned integer current_user_programme; //indicates current user programmes if the appliance is set //in active state

}payload_field:status_command_resp;

{




unsigned integer current_user_programme; //indicates current user programmes if the appliance is set //in active state

short integer error_code; // 1 command not implemented, 2 EMD internal error, 3 //EMD-appliance communication error

}payload_field:error;

{


unsigned integer no_of_fields; //indicates the number of payload fields

unsigned integer payload_fields[no_of_fields];

}payload_field:for_new_commands;

Message field Size in octets Comments

Length 2

Seq. No. 1

Command ID Variable The first octet contains field’s length, the last bit of the last octet indicates command direction; 0 for requests, 1 for responses

Appliance ID 2 The first octet contains appliance category and appliance incremental number starting from 0, the second octet contains appliance type.

Payload Variable The first octet contains field’s length. Content depends on message type.

Table 2: Message fields size

Appliance ID –first octet Value (values in Hex)

White goods 0x0

Audiovisual equipment 0x1

Communication equipment 0x2

Control equipment 0x3

Lighting equipment 0x4

Heating/air-conditioning 0x5

Table 3: Values of the first octet of the appliance ID field



Appliance ID –second octet Value (values in Hex)

White goods

Washing machine 0x1

Oven 0x2

Hob (cooktop) 0x3

Kitchen 0x4

Refrigerator 0x5

Freezer 0x6

Dishwasher 0x7

Dryer 0x8

Audiovisual equipment

TV (HDTV) 0x1

Set-top-Box 0x2

DVD player 0x3

PC 0x4

Hi-Fi system 0x5

Home Cinema 0x6

Communication equipment

Router 0x1

WiFi hot spot 0x2

DSL modem 0x3

Residential gateway 0x4

Cordless phone 0x5

Satellite modem 0x6

Control equipment

Door control system 0x1

Window shutter control system 0x2

Sensor network 0x3

Electronically controlled valves (for water pumps, etc) 0x4

Lighting equipment

Inner space lighting equipment 0x1

External space lighting equipment 0x2

Dimmer-controlled light 0x3

Heating/air-conditioning

Solar panel 0x1

Water heater 0x2



Boiler 0x3

Electrical air-conditioner 0x4

Fuel consuming heating system 0x5

Electrical cooling system 0x6

Table 4: Values of the second octet of the appliance ID field

3.2.2.1.1.2 State machines

Figure 40: State machine for the implementation of the switch off command



Appliance switch onprocedure

Which appliance to be switched

on

M2M protocol

Define appliance IDCommand ID

Energy profiles Database

Appliance IdCommand Id

Formulate control message

send the message to the EMD via the corresponding

OSGi bundle

End

Status DatabaseAppliance ID

Wait for successful status report from the

appliance

Update the status of the appliance in the database

Yes

Wait

Report command unsuccessful implementation

to the service via the M2M protocol

Timerexpired

M2M protocol

Set wait timer

Figure 41: State machine for the implementation of the switch on command



Appliance switch overprocedure

Request supported power

modes of an appliance x

M2M protocol

Get power modes


Appliance IdSupported Power modes (power mode ID)Consumption values per power mode


OSGi bundle

Send to the M2M protocol supported power modes/

energy consumption values for the appliance

in question

Get Appliance idCommand Id

New power mode ID


Appliance IdCommand Id

Power mode ID

New power mode

Formulate control message

End

Status DatabaseAppliance ID


appliance

Update the status of the appliance in the database

Yes

Wait



Timerexpired

M2M protocol

Set wait timer

Figure 42: State machine for the implementation of the switch over command



Figure 43: State machine for the implementation of the error command



Figure 44: State machine for the implementation of the acknowledge command



Status implementationprocedure

Request status for appliance X

M2M protocol

Find ID for appliance X

End

Energy profiles database

Appliance Id

Formulate status request message


OSGi bundle


appliance

Yes

Wait



Timerexpired

M2M protocol

Set wait timer

Figure 45: State machine for the implementation of the status command

3.2.2.1.1.3 Databases structure

As is indicated in the deliverable D2.2 and the state machines depicted in the previous section, the universal energy saving protocol implements messages translation with the help of two databases that are integrated within the RG architecture.

The energy profiles database is used for maintaining the appliance types found in household, the supported user programmes and the energy they consume in each user programmes.

The status database is used for maintaining the real time status of all connected appliances so that it can be exploited in the implementation of energy saving services.

For both databases indexing of information is implemented using as main index the appliance id and as a secondary index the consecutive appliance number. The secondary index is mainly used in cases where more than one appliances of the same type exist in the household.

The data structure of the energy profiles and the status databases is shown in the following figures.



Figure 46: Internal data structure of the energy profile database

The third field is used for indicating which commands are supported by the appliance and has the following ANSI C format:

{

unsigned integer Overall_length;

unsigned integer Number_of_supported commands;

unsigned integer Array_of_supported_commands[Number_of_supported_commands];

} supported_commands_data_structure;

As is depicted to the Figure 46, the fourth field is used for maintaining the supported user programmes and the corresponding energy consumption values. This field has a data structure of variable length with the layout shown below defined in ANSI C format:

{

unsigned integer Overall_length;

unsigned integer Number_of_supported programmes;

unsigned integer Array_of_programmes_energy_values[Number_of_supported programmes];

} supported_user_programmes_data_structure;

Each appliance has a number of supported programmes of which encoding within the given data structure is a matter of agreement with the appliance manufacturers and corresponding values will defined in WP4.

The standby capability field has one octet length and indicates the capability of the appliance “t” be set in standby mode (value=1) or not (value=0).

Figure 47: Internal data structure of the status database

The status field has two bytes, the second of which indicates whether the appliance is powered on (bit8-15=1) or is switched off (bit8-15=0) or is in standby (bit8-15=2).

The first byte indicates the user programme of the appliance when it is powered on.

3.2.2.2 Protocol and operations extensibility functions

Protocol extensibility is defined at three levels; network, appliance and service.

Extensibility at network level is ensured by the OSGi architecture, which offers a network independent software execution environment, whereby underlying network interfaces are addressed by the high level OSGi applications as software bundles that are automatically recognised in terms of communication features. Thus, a new communication interface that may be needed for the



implementation of communication with new appliance types can be seamlessly added on the AIM Logic without inducing any impact on the functionality of the supported services.

Extensibility at appliance level is ensured by the adoption of the two databases (energy profiles and status databases) specified in previous sections. Both databases are thin data structures embedded in the OSGi software environment that offer the range of the appliances that the service architecture should manage.

Extensibility at service level is ensured by the OSGi environment, the M2M protocol and the Universal Management Protocol in various ways.

The OSGi environment ensures that new services can be added on the AIM Logic without affecting the operation of existing ones, while existing services can be withdrawn, modified or amended.

The M2M protocol ensures independency of the Universal Management Protocol from the functionality of the user services and allows addition of new management features without the need of enhancing the Universal Management Protocol.

Finally, the Universal Management Protocol supports variable length command and status messages so that new messages can be implemented without the need of producing new protocol binaries. In addition, in the profiles database along with their energy profile, each appliance, whether it is or not addressed in the project, should define the commands that supports, including new ones.

The management interface, which can be used for configuring the protocols and services of the AIM Logic, is also implemented using the HTTP protocol and is subject to design and implementation in WP4.

3.2.2.3 Integration with operator networks

The following section presents in detail several use cases that are important for the telecom operators. They are mainly focusing on the energy management related services. The operator networks can interact with the EMD either directly using internet technologies, or by submitting requests through an AIM residential Gateway.

The utility wants to introduce an incentive based business model which means that the customer can directly participate in savings; this benefits the utility which can generate additional cash-flow through a flexible cost model. To realize such a business model a communication path between the utility and the customers, which provides the required information (tariff/pricing information), has to be established and the customer needs to have a device which is at least capable of displaying the actual tariff-information. This functionality should be provided by the AIM-gateway and the EMD.

One possible way for introducing flexible tariffs is that the utility sends a pricing profile for the next day which includes the tariffs for every hour. This would be just a finer differentiation of “time-slices”. In peak times the energy would be more expensive than in off-peak times. Now the customer knows when the more energy intensive services should be used.

Another way for flexible tariffs would be the possibility for customers to buy a certain amount of kilowatt-hours for consumption. This would require more communication between the utility and the customer, since a buy order must be carried out and the crosscheck whether the bought amount of energy is already consumed needs more communication between customer and utility. Nevertheless the AIM Gateway can be used as central device to organize the communication and information exchange between utility and customer. The associated energy management is executed by the EMD.

In the time of frequently changing prices and changing availability of additional power generation capacities the requirements for remote load control becomes a challenging aspect in power grid operation. When a utility knows that in its network unused load which can be controlled remotely is available, it could plan with that buffer to be able to buy cheaper energy. It is the EMD that provides this information, either directly or through the AIM core logic.

3.2.2.4 Integration with user services

The AIM scenario supports a wide variety of services. According to the general use cases, local users can interact with the system to perform a set of basic set of operations that include the monitoring of



energy use, the personalization of energy use and gateway maintenance (for expert users only). In every case the EMD is pivotal to the requested actions.

In the following we specify in more detail these use cases for local users and include also the interaction of the sensor network with the system through the EMD.

Home users can access to the energy use monitoring service of the AIM system through a local interfaces to the service using a terminal (PC, PDA, etc.) that is connected to the home gateway via the home networks. Data provided by the service are obtained in general aggregating and elaborating rawdata provided by the EMDs. The specific data provided and the way in which they are presented to the user depends on the monitoring energy use application that is installed in the home gateway.



4 User-related operationsIn this section we give three realistic examples showing some usability aspects of the AIM system. Because the document is public and therefore can be read by users not experienced in ICT technology, this description is not exhaustive nor highlights the functions of particular building blocks of the architecture, but gives to the reader a flavour of the benefits that the AIM system bears in his daily life.

4.1 Example usage scenariosIn all the scenarios listed bellow the EMD is used to communicate information to the AIM Gateway and enforce any energy management action dictated by the Gateway or the external actors of the system.

Example N°1 – Usage scenario during workdays (from Monday to Friday)

The user is a typical worker who is found at home either very early of the day or late, afternoon time.The objective of the user using the AIM system is to minimize energy consumption costs and to this purpose he sets the system for the time his absent to have standby devices switched off and have the programs of appliances that cannot be switched off replaced by economical user programs.

While being through the winter time the user wakes up at 7:00AM. He desires a pleasant temperature in the rooms that he visits in the morning for preparing breakfast and dressing himself before going out for work. He sets a temperature of 22°C in the bedroom, bathroom and in the kitchen. He doesn’t want to warm up the living room because he doesn’t use this room in the morning. While the user is not in the house, it is not necessary warming up any room over a specified threshold of temperature so, at 8:00AM when the user gets out, the system is free to manage home temperature just considering the cost minimization objective and minimum temperature constraints. Obviously, user desires that at 7:00PM, when he is back home, the temperature in the house is again around 22°C like in the morning, but this time in all the rooms.

The user settings can be provided to the system through a local interface or it can be estimated by the sensor network based on the analysis of the time series of user presence at home and in the room of the house. The user also desires that when he comes back home in the evening the clothes that he puts in the washing machine in the morning are washed and dried. Accordingly with the general settings of the system, the goal is to reduce energy cost for washing the clothes. The system can select an available program to reduce energy consumption considering the type of clothes to be washed. The system is also capable of managing the schedule of the washing program considering its duration, the constraints set by the users and the information of energy cost during the day.

Example N°2 – From Monday to Friday with discrete power levels in devices.

Like in previous example, the user is a typical worker that lives in household only in the early hours of the day and come back in the house in late evening for dinner and the night.

The general objective of the user is to minimize incurred costs and avoiding exceeding a defined threshold of 2kW/h. The selected general function for the system is:

Allocate energy consumption in a period of time (i.e. 24 h) avoiding exceeding a defined threshold (i.e. 2kW/h) Objective: energy consumptions are allocated in 24h/day to avoid peaks of energy requests to the provider. The energy provider informs that energy is cheaper than usual if the user doesn’t exceed a threshold of 2kW/h when the maximum power allowed is 3,3 kW/h.

The system operates to have an instantaneous total consumption of energy always below 2kW/h.

The system has also the ability to operate at single connected device level and to manage for each one various power levels diversified for every function that the devices accomplish in every single moment of time. With this kind of logic the system can power-off single components of the device or power-on the devices for a longer period of time but with smaller costs.



The user wants to cook a meal in the microwave oven and doesn’t want to exceed a defined threshold of 2kW/h. The system knows the energy being used by the other appliances and the threshold of 2kW/h, and it calculates the residual energy to reach the threshold. Based on the available programs for cooking the meal and the residual energy, the system chooses the best one.

The user also asks the system to manage displays of all the devices based on the presence of the user detected by the sensor network. Each device is described in the ontology by his components and the system knows if a display is available on them or not. The system can simply power-on the display when the use is in the room and power it off if when user leaves the room, or it can performs more complex control functions considering for its decisions also the time of the day and the estimated probability that the user will use a specific device. Similarly, the system can manage available discrete energy consumption levels associated to appliances internal functions or components based on the needs of the user, its presence in the room and the probability of using a specific device based on user profile.

The user sets the system to manage automatically the lights in the rooms. He decides to activate the functions that manage the light bulbs so that to compensate smoothly the growing darkness of natural light. The light level in the room is detected by the sensor network.

Example N°3 – On vacation

The user leaves the house to go on vacation and his objective is the minimization of incurred costs to manage the house when he is away. The objective function that is selected by the user is:

Minimize cost for energy during a period of time (i.e. 6 hours, 24 hours, week and month)

Objective: minimization of total consumption in a period of time without considering incurred costs. It is necessary to define if the minimization is operated for a day, week, month or year.

The user can turn off some kind of services available in the house while they’re not going to be used without him but he needs that some other services are also guaranteed during his holiday.

The system knows the devices that are available to be turned off completely or not.

The user doesn’t need to manage temperature so its control system is turned off.

Devices that usually are in stand-by mode like modem, TV, microwave oven and washing machine are also turned off.

Refrigerator and freezer stay in power-on state in order to maintain food in good conditions.

A date/time for the return of the user has been provided to the system by the user so it can restore the normal functioning of the devices before the user is in the house.



5 Use-casesAs in the case of chapter 4, also here the following sections provide simple information about how the EMD can be installed and be exploited in the frame of energy saving applications for the three user groups targeted by the project.

5.1 Installation possibilitiesThe EMD has the role of interfacing the energy control logic of the AIM architecture, consisting of energy monitoring and management functions, with the appliances that are controlled, both of which are integral parts of the AIM core logic.

Energy monitoring consists of monitoring the energy consumed by the each appliance and reporting the value to the system logic via the AIM gateway. Energy management consists of maintaining specific energy consumption thresholds set by home users by applying on household appliances various control models such as state alteration, switching off and standby management.

EMDPL/802.11/Zigbee/…..

RG

Appliance

EMD802.11/Zigbee/PL/..

RGAppliance

EMDPL

802.11/Zigbee/PL/..

RG

Appliances

Stand-alone

on RG

on the applianceAIM Core Logic

AIM Core Logic

AIM Core Logic

Figure 48: EMD hardware configurations

The EMD can either be hosted inside the controlled appliance, be integrated inside the residential gateway, or be an independent device, mediating the communication between RG and controlled appliance. In either cases part of the logic, the entire logic can be implemented by the EMD component, whereas in some cases the EMD can simply implement the communication interface.



All these communication possibilities have been deemed as necessary in order to enable flexible system implementation.

5.2 Supported appliancesThe EMD concept should be able to support every electrical device, including devices which do not exist today. Therefore the KNX protocol has been specified extensible.

Within AIM, three appliance types will be supported:

Audiovisual equipment: TV, Home Cinemas, etc

White goods: Refrigerators, Kitchens, washing machines, etc

Communication equipment: Home gateways, wireless hot spots, etc

The selection criteria for these appliances were the following:

The appliances must be widely deployed;

Control of the device should lead to significant energy savings;

A demo of the device control shall be possible.

For the organisation of the trial phase AIM will use appliances that will be provided by the appliance manufacturers that participate in the project (Infineon, Indesit and Philips).

5.3 Use-cases for network operatorsThe energy consumers in the AIM architecture are controlled by Energy Management Devices (EMDs), which create the local hub of the AIM energy control. EMD communicates, through proper communication channels called "Interfaces" with all the AIM energy consumption actors, using one (or more) physical communication media and associated protocols. The implicated communication technologies are based on wireless, power-line or Ethernet connectivity. The interfaces are specified for communications channels among appliances (white goods, audiovisual and communications equipment) on one side and users (home users, utilities and network operators) on the other side.

Network operators have a vital role to play, since they collude with the utilities in communicating energy consumption data to utility data centres for processing and network fine-tuning.

5.4 Use-cases for residential usersThe AIM architecture permits to obtain three main functions as remote control, energy monitoring and energy management. The residential user could perform those operations interacting with AIM system. To allow this, it is necessary that each appliance is equipped with a power meter.

The residential user by the “Interface” could be aware of measuring, for each appliance, its Energy Consumption. This information, for example, can also be a prediction, before starting the cycle. Other opportunity is to assist the user to optimize his power Consumption, visualizing that energyinformation.

By the same “Interface” the user could monitor and control the energy consumption of all appliances collected to AIM system in a networked manner, or he could choose the cycle starting time depending on energy time tariffs that the power generation utilities supply to the system. The AIM system allows improvement of home energy performance.

All of those features are possible by the remote control that enables the user to show information as the functional status or perform actions. Another service for User disposal is the appliance monitoring outside the house in order to check its functional status. The AIM system allows the User to be more aware of his usage of the appliance or about its power consumption and his habits.

By the merge of the remote control and energy management functionalities the User could choose, on AIM system request, the optimal running time to obtain energy and cost efficiency (i.e. for washing machine).



5.5 Use-cases for energy generation utilitiesAIM provides a technology which allows the measurement of the power consumption of single appliances and their remote control by the AIM service logic. This functionality satisfies the requirement for direct feedback about the energy usage towards the owner of the household. On the other hand the potential usage can be extended by adding further information which is delivered by the utilities. The idea is that by using incentive based tariffs in combination with the possibility to control power consumption inside the households it is possible to flatten the energy usage curve and lower peak loads in the power distribution network. To understand this use case it is important to know that the peak load is the most expensive part of the power, the idea behind time variable tariffs (e.g. changing price for every hour) is that those users that shift their power consumption away from peak times get an incentive (lower price for the kWh).

To realise such functionality, a data exchange between the AIM service logic and the power grid operator in a defined format is required. The data exchange could be realised in two different ways:

1. The AIM service logic knows the location of the data file and retrieves it automatically from the utility's server;

2. The utility takes care of the transmission of the tariff data and “pushes” the information to the AIM service logic.

This data is containing the hourly tariffs, e.g. for the next 24 hours, which gives the AIM service logic the possibility to plan power consumption depending from different requirements. The idea behind this data exchange is to incorporate external information to the decision process of the AIM system.



6 ConclusionsIn this document it has been described a detailed system architecture that targets reduced energy consumption in residential appliances based on the EMD concept. This concept represents a different approach in the implementation of energy management in household from the most predominant ones that are based in smart metering devices, removing the need of extra components in the energy management system. It is a low cost and friendly solution.

Several functional components needed in order to realize the EMD architecture, such as the EMD metering and soft switching module, were described. It was presented a potential realization of the proposed architecture that consists of hardware and firmware.


The final EMD system will be ready on month 16 and will be documented in deliverable 3.1.2.2.



References[1] http://www.ict-aim.eu

[2] http://www.knx.org

[3] http://www.dect.org

[4] http://www.etsi.org

[5] DECT, The Standard Explained, DECT Forum, February 1997.

[6] DECT Next Generation: New services and standardization, DECT Forum presentation,

PresseForum München 19. Jan 2006

[7] Draft ETSI EN 301 649 V1.4.2, DECT Packet Radio Service (DPRS), 2007-05

[8] DECT World 2008 Conference Presentation, DECT Forum

[9] 2007 Wireless Symposium London, DECT Forum presentation, June 19 2007

[10] CAT-iq at a Glance, Global Technology for Broadband Home Connectivity, DECT Forum 2009

[11] ETSI TS 102 527-1 V1.2.1, DECT, New Generation DECT; Part 1: Wideband speech, 2008-06

[12] ETSI EN 300 175-2 V2.2.1, DECT, Common Interface, Physical Layer

[13] CAT-iq,- New Global Broadband Technology for Wireless Home Connectivity, DECT Forum,

January 2007

[14] Home Gateway Technical Requirements: Residential Profile, Version 1.0, Home Gateway

Initiative, 29.04.2008

[15] Introduction to IMS, White Paper, ERICSSON, March 2007

[16] TR-69, CPE WAN Management Protocol, v1.1, Issue 1 Amendment 2, Broadband Forum

Technical Report, December 2007

[17] AIM deliverable 2.1.

[18] M2M protocol specification, ESTIA- FP6-IST-27191 STREP consortium, 2007.



Annex A

A.1 Installation & Configuration GuideThe Configuration of an EMD is fully automatic. The AIM EMD operates in either Master or Slave configuration – each of these is launched automatically by the hardware. In terms of connectivity, the Master EMD is connected to the AIM Gateway using a RS232 serial connection. The EMD Slave communicates with the EMD Master using powerline communications or additional wired/wireless protocols.

The configuration of the EMD offers a Plug & Play experience, since the user needs to tend to some very simple actions.

1. The user initially connects an EMD to the Gateway using an RS232 cable;

2. Then powers-up both the Gateway and EMD; the latter being automatically configured to a Master mode by the Gateway;

3. The user, at his own pace, connects one-by one every EMD controlled device to a respective EMD TRIAC controlled power outlet (see figure bellow) and hooks-up the EMD mains plug to the mains. The sequence of events that automatically takes place is following one: the EMD is autoconfigured to Slave mode, contacts the EMD Master and Gateway through powerline messaging, automatically obtains an individual net address, and reports back its controlled device type information to the Gateway.

Figure 49: The EMD Slave

An EMD is an expandable control device, through a parallel extension interface, which can be used to connect additional boards on it, implementing complementary communication protocols, like TCP/IP, ZigBee, WiFi etc.



Figure 50: The EMD Electrical Current measurement unit detached

The AIM Slave EMD is hosting an Allegro ACS712 chip, which is a Fully Integrated, Hall Effect-Based Linear Current Sensor with 2.1 kVRMS Voltage Isolation and a Low-Resistance Current Conductor. This is the device that measures the electrical current that is used by the device under control at any given time. This add-on board is hooked over the EMD main board using special connection pin holders.

In terms of hardware, the EMD Master is exactly the same as the EMD Slave, and in-fact running an identical firmware image. The function differentiation between Master and Slave is automatically assumed during run-time, offering a plug & play experience to the end-user.



Figure 51: Close up of the electrical current measurement unit

Figure 52: The EMD Slave assembled with add-on board



A.2 Serial interface specificationThe AIM EMD operates in either Master or Slave configuration. The Master EMD is connected to the AIM Gateway using a RS232 serial connection. We are using a 9600 bps connection to communicate with the EMD Master. The EMD Slave communicates with the Master using powerline communications.

Our implementation of RS232 communication between AIM gateway and EMD master is fully compatible to the KNX EMI1 protocol (KNX KNX 03_06_03 EMI_IMI v1.0 AS). AIM gateway and EMD Master communicate using an exchange of data packets in the following format:

The length octet contains the full RS232 message length. The available message codes and their functions are listed in KNX 03_06_03 EMI_IMI v1.0 AS document; the user data responds to specific command attributes appropriate to each message code.

The installation of an EMD, either Master or Slave is Plug & Play. When the EMD Master is connected to the Gateway for the first time, it enters an auto-program mode and is granted a default Master KNX address by the Gateway.

Likewise, when a KNX EMD slave is powered-up for the first time, it too enters an autoprogram modeand sends over the powerlines an autotrace message to the KNX master. The Master receives this message and informs the Gateway that a new EMD has been discovered.

The Gateway assigns an unused KNX address to the newly connected EMD, and polls the newly connected device for KNX identity and type attributes. User intervention is limited to plugging the EMDs along their controlled devices and powering them up. The EMD network configuration is automatically completed under the transparent control of the EMD Master and AIM Gateway.

The AIM Gateway forces the EMD Master to poll the connected EMD Slaves at regular intervals, and thus obtain information on their connectivity Status.

KNX EMI1 offers a collection of around 30 KNX command primitives, which can deliver a wide range of KNX services as listed bellow.





The AIM Gateway mostly uses the following configuration RS232 KNX EMI1 commands. Note that the whole process is completely transparent to the AIM user.

This RS232 command is used to write persistent data on the EMD’s EEPROM or alter the contents of its RAM in specific address spaces. m_code is 46h, length is the number of bytes to read at a specific address and subsequently follow the actual data.

Example (hex values):

05 46 01 00 60 12

meaning: this is a 5 byte command ; the command type is PC_Set_Val_req, requesting a writing

of 01 byte starting at address 0060; the value to be written is 12h.



This RS232 command is used to read persistent data on the EMD’s EEPROM or contents on its RAM. m_code is 4Ch, length is the number of bytes to read at a specific address.

Example (hex values):

04 4C 01 00 60

meaning: a 4 byte command length, command type is PC_Get_Val_req, requesting a reading of 01 byte starting at memory address 0060.

This RS232 command is sent by an EMD in response to PC_GET_VAL.req and contains the requested data red from the EMD’s RAM or EEPROM memory space.

This is the most important KNX command, used to send a data packages (or frames) from the Master EMD to one or more EMD slaves over the powerlines.



The m_code is 11h. The control field dictates the broadcast priority and the recipient acknowledgement request, the frame’s destination address; the frame type (group or individual) and the hop count,(or number of KNX routers the frame can hop-over when travelling on the powerline net). NPDU contains the useful command data, like requesting a slave EMD’s TRIAC on /off, or an electrical current measurement.

The EMD NPDU field likewise is listed as follows:

02 f7 00 EMD electrical load switch off

02 f7 01 EMD electrical load switch on

02 f7 02 EMD request electrical current measurement (Irms in Amps).

The NPDU format is fully compliant to the KNX application command tags, which are also hosted inside this field. Using a destination address of 0000 makes the frame global-cast to all Slave EMDs connected on the AIM topology.

Example A switch on load command aimed at Slave EMD hosted in address 0100:

0a 11 00 0000 0100 62 02 f7 01

Example B switch off load command aimed at Slave EMD hosted in address 0100:

0a 11 00 00 00 01 00 62 02 f7 00

Example C request electrical current command from Slave EMD hosted at address 0100:

0a 11 00 00 00 01 00 62 02 f7 02

A response reaching the Master from the powerline KNX bus contains a 16bit Irms (Electrical current) measurement, taken from the controlled device attached to the EMD Slave. This information is collected by the EMD Master, and is communicated to the AIM Gateway, where it is processed to complete the AIM energy management loop.

Education

IST Aim Energy management device d3-1-1-1v1-0