Keletron KNX PL110-132 energy manager presales

KNX PL110/132 Energy Manager
KNX powerline PL110/132 transceiver module
www.keletron.com
This document contains information on a new
product. Specification and information herein are
subject to change without notice.
■ Product summary
Keletron KNX Powerline PL110/132 Energy Manager (KEM) - provides energy consumption
measurements, load control, communication to a residential gateway over the powerline and a
serial communication bridge to controlled devices. It can be engineered to be embedded inside
OEM residential appliances.
Our PL110/132 Energy Manager , is based on a KNX powerline transceiver module, controlled by
Keletron Ltd – Tel. +30-2310-947979 Fax +30-2310-947386 Email:info@keletron.com
Page 1

a PIC 18F6722; implementing an OSI7 PL110/132 KNX stack protocol as defined by the KNX
Association (www.knx.org). Supporting powerline modem used is ST7540. Our hardware modules
avail a UART interface for serial communication, configuration and firmware update.
They can be engineered to communicate with a wide variety of sensors and actuators; and have
inbuilt energy metering modules.
KEM meets the KNX PL specification and can be configured to operate in the KNX S, A and E
modes, while adhering to the 110 kHz or 132.5 kHz frequency band. The physical layer complies to
the relevant parts of the CENELEC EN 50090. Also available is Linux based software, which
controls this device, exposing an XML web based interface.
■ Application space
• Home and building control
• HVAC
• Electrical load control
• Energy management
■ Basic Features of KEM
• KNX PL110 or PL132 compliant
• Powerline Carrier Modem 50 Hz/220 V mains
• Carrier Frequency 110 kHz/132.5 kHz
• 1200 or 2400 bps over powerline
• Half duplex
• High sensitivity (0.25 mV RMS)
• CRC and FEC error correction
• PIC 18F6722 core, ST 7540 powerline modem
• 128 kBytes internal flash memory
• Auto boot-loading Program from serial flash
• In-circuit serial flash programming
• UART accessible firmware update
• AD/DAC capability to interface with external devices
• Buffered SPI to external energy metering IC
• Power Supply 5.0 V
• Electrical Load isolation
• Ambient Temperature Range: -40 °C to +85 °C
• Linux compatible residential gateway software
• Bridge connectivity to ZigBee or other supported protocols via gateway
Page 2

■ PIC 18F6722 basics
Page 3

PIC18F6722 functional components
Page 4

■ ST7540 powerline modem basics
• Half-duplex frequency shift keying (FSK)
transceiver
• Integrated powerline driver with programmable
voltage and current control
• Programmable mains access:
– Synchronous
– Asynchronous
• Single supply voltage (from 7.5V up to 13.5V)
• Very low power consumption (Iq = 5mA)
• Integrates 5V voltage regulator (up to 50mA)
with short circuit protection
• Integrated 3.3V voltage regulator (up to 50mA)
with short circuit protection
• 3.3V or 5V digital supply
• 8 Programmable transmission frequencies
• Programmable baud rate up to 4800BPS
• Receiving sensitivity up to 0,25 mV RMS
• Suitable for applications in accordance with EN
50065 Cenelec specification
• Carrier or preamble detection
• Band in use detection
• Programmable control register
• Watchdog timer
• 8 or 16 Bit header recognition
• ST7537 and ST7538 compatible
Page 5

ST7540 Mains interfacing using a coupling transformer
■ The KNX powerline interface
Keletron Energy Manager (KEM) is based on the KNX communication stack technology
(www.knx.org).
Page 6

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 trans-
mission, or powerline communication. Keletron Energy Manager adheres to KNX powerline proto-
cols PL110 and PL132.
KNX PL132 supports communications at rates of up-to 2400 bps between KNX devices sharing a
common powerline, whereas PL110 reaches 1200 bps. PL110 and PL132 are low bandwidth pro-
tocols; noise-resistant and excellent for communicating control signals over the powerlines -- on
quite long distances, which can reach several hundred meters.
Digital signals modulation techniques over powerline signal
■ CDMA access to the KNX powerline bus
The network topology of KEM is based on a common access powerline bus. Only one KEM device
on the net can use the bus at any given moment. All the other connected devices ‘listen’ to the bus
traffic, and wait to find an ‘empty slot’ on the bus to transmit their information. The technology used
is ‘Carrier Detect Multiple Access, Collision Avoidance’ (CDMA-CA). Since PL110 and PL132 are
low bandwidth communication protocols, they were designed to support both a peer-to-peer and
multi-cast communications to conserve precious bandwidth.
Page 7

■ KEM KNX PL110/PL132 network stack
KEM implements a KNX PL110/PL132 network communication stack. The words ‘Network Stack’
indicate an ubiquitous OSI-7 stack. 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. Standardized
PL110/132 KNX routers and bridges are available from several vendors.
The reader should note that the KNX protocol, thus also KEM, 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. A full PL110/PL132 device stack implementation can be expected to be hosted in
70 kbytes of flash space on a 16-bit micro-processor base, including support for network manage-
ment procedures and KNX net topology administration. Our hardware is also equipped with 1Kbyte
of EEPROM which is used to store persistent KNX data (e.g. KNX network address ID, network
groups, KNX Object attributes etc).
■ KEM hardware base
Our KEM is a hardware design, based on the Microchip PIC18F6722 micro-controller and the
ST7540 powerline modem chip. The PIC processor contains the necessary code to implement a
full OSI7 KNX protocol stack; it performs real time operations to control the waveform powerline
signal generation of the ST7540 modem, and handles all communication requests from external
devices. There are two additional hardware components, which are integrated in a KEM: an Allegro
Current metering chip and a TRIAC module for electrical load control, although we can deliver
customized KEMs connected to any type of sensor or actuator our clients demand.
Page 8

KNX specifies three configuration/net setup procedures, actually prescribing the three KNX instal-
lation modes: Easy, System and Auto. Our KEM implementation has been designed to deliver a
virtually automatic install procedure – compliant with the KNX Auto mode.
■ Auto mode – a plug and play experience
When a KEM is connected to the Gateway for the first time, it enters an auto-program mode and is
granted the default Master KNX address (0000). Likewise, when a KNX KEM slave is powered-up
for the first time, it too enters an auto-program mode and on the press of a config button on its
faceplate, sends over the powerlines an auto-trace message to the KNX Master. The Master
receives this message and informs the Gateway that a new KEM slave has been discovered. The
Gateway assigns an unused KNX address to the newly connected KEM, and polls the newly
Page 9

connected device for KNX identity and type attributes.
The KNX KEM is able to parse user data into KNX group object data (KNX standardized com-
mands, aimed at multiple recipients on the KNX net or specific KNX Functional Blocks) – and KNX
interface objects, working as conceptual information conduits/links between KNX devices and sen-
sors. This virtual linking phase is automatically handled during the net setup phase.
■ Communication
KEM is a fully fledged KNX device, which can receive commands not only through the powerline,
but also through a serial interface (RS232). This interface is called PEI (Peripheral External In-
terface), and is the means through which a KEM can be connected to a PC or other type of device.
Our particular implementation uses PEI type 16, according to the KNX specification. KEMs sup-
porting PEI10/FT1.2 can be delivered on request. The PEI is also the path through which we can
submit bridge commands to KEM connected electrical devices that avail a serial port, like latest
generation washing machines/ovens/fridges.
The KEM firmware■
The basic development steps that the KEM KNX firmware encompassed were the following:
Abstracted KNX stack design
We designed our KNX firmware framework, in such a way, as to facilitate future porting to new
processing platforms and microprocessors.
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.
KNX internal message pump in conjunction with a finite state machine
The Transport and Application layers use an event handler on-top of their finite state machines.
Their defined behavior is quite complex and dependent on the device’s functionality state (idle,
working, receiving information, etc).
EMI/IMI parameter parser for each KNX layer
There is a clearly defined interface for communicating information within the KNX stack. When
commands reach the stack via the PEI16 , the commands are coded in EMI (KNX External Mes-
sage Interface) format. These commands are internally translated into IMI (KNX Internal Message
Interface), which actually control the information flow among the KNX stack layers.
PEI16 protocol implementation
The PEI16 protocol is defined both physically (electrical signal-wise) as well as abstractly by the
KNX specs. It is conceptually a set of control codes communicated over RS232 between an exter-
Page 10

nal control terminal (eg Gateway) and the KEM. A KEM with PEI 10 FT1.2 can be delivered on
request.
EEPROM and KNX Virtual RAM interface engineering
Since KNX is an open standard, (thus hardware platform independent), no actual KNX hardware
specs are provided. Instead, on all hardware related functions, the specs define abstracted
functions. These are translated into concrete ones by the specific KNX PL implementation. Thus,
we define virtual access points for the particular micro-processor base we are using. There is an
area in the RAM which is used to store the KNX object RAM data – which means that a Virtual
RAM interface has been incorporated in the stack, to access this area in a uniform and KNX
compliant manner.
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.
KNX Object Attribute Translator
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 is
parsed both at the broadcast (message formulation) and the reception end; which is what the KEM
object attribute translator does.
Implementation of KNX net setup message parser
This is a message conduit, aimed to ‘personalize’ the KNX device, by auto-registering its identity.
The messages that are processed, interact with the KNX Bus Access Unit's EEPROM, by reading/
writing or altering its contents.
Testing and Simulation in vitro
The KNX firmware codebase was unit and simulation tested before being ported into a micro-pro-
cessor. It is immune to buffer overruns, does not use dynamic memory allocation – de-allocation
techniques for speed and stability – it is crash immune under any KNX traffic load, and it is tracked
by a watch dog. Since the KNX stack is a real-time system it was critical to verify that all atomic op-
erations were executing in proper time frames, compatible with the KNX stack communication
speed requests.
Page 11

KNX■ Internal interfaces
Internal interfaces are used when the KEM system is integrated to a another device (e.g KNX
hardware integrated inside a residential appliance, like a washing machine). In simple configura-
tions, the KEM firmware can be hosted inside the residential device’s microprocessor, or may be
hosted on a dual processor architecture, with one microprocessor controlling the residential device
and the other implementing the KEM KNX functions. Either way, there are standard messages
exchanged inside the compound KEM and residential device hardware, which adhere to the KNX
specification IMI1.0 (Internal Message interface) protocol. 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.
■ Serial interface specification
A KEM operates in either Master or Slave configuration. The Master KEM is connected to the
Keletron Residential Gateway using a RS232 (9600N81)serial connection. A KEM Slave
communicates with the Master using KNX powerline communication.
Our implementation of RS232 communication between gateway and KEM master is fully com-
patible to the KNX EMI1 protocol (KNX KNX 03_06_03 EMI_IMI v1.0 AS). Keletron Gateway and
KEM Master communicate using an exchange of data packets in the following format:
KNX EMI1 offers a collection of around 30 KNX command primitives, which can deliver a wide
range of KNX services.
Page 12

Page 13

This RS232 command is used to write persistent data on the KEM’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.
Page 14

This RS232 command is used to read persistent data on the KEM’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 KEM in response to PC_GET_VAL.req and contains the re-
quested data red from the KEM’s RAM or EEPROM memory space.
Page 15

This is the most important KNX command, used to send a data packages (or frames) from the
Master KEM to one or more KEM slaves over the powerlines and vice versa.
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 pow-
erline net). NPDU contains the useful command data, like requesting a slave KEM’s TRIAC on /off,
or an electrical current measurement.
The KEM NPDU field likewise is listed as follows:
02 f7 00 : KEM electrical load switch off
02 f7 01 : KEM electrical load switch on
02 f7 02 : KEM 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
KEMs connected on the system topology.
Example A switch on load command aimed at Slave KEM hosted in address 0100:
0a 11 00 0000 0100 62 02 f7 01
Example B switch off load command aimed at Slave KEM hosted in address 0100:
0a 11 00 00 00 01 00 62 02 f7 00
Example C request electrical current command from Slave KEM 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 cur-
rent) measurement, taken from the controlled device attached to the KEM Slave. This information
is collected by the KEM Master, and is communicated to the Gateway, where it is processed to
complete the energy management loop.
Residential Gateway■
KEM is connected to a Linux residential gateway,
which can host a multitude of residential control protocols, like
ZigBee, Zwave etc.
Thus, the Keletron residential Gateway becomes a control hub
and command translator, that binds diverse smart-home proto-
cols together, exposing control through a unified, secure XML
based web interface.
Page 16

Page 17

Page 18

Keletron KNX PL110-132 energy manager presales

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Keletron KNX PL110-132 energy manager presales

Similar to Keletron KNX PL110-132 energy manager presales (20)

More from Yiannis Hatzopoulos

More from Yiannis Hatzopoulos (20)

Recently uploaded

Recently uploaded (20)

Keletron KNX PL110-132 energy manager presales