Plug and Play. An Introduction

Transcription

1 Plug and Play in Distributed Home and Building Automation Systems: An Introduction A-Lab, Automation Systems Group, TU Vienna This presentation discusses the goal of reducing the setup time of home and building automation systems. It offers a look into what this task involves, pointing out requirements and challenges. A special focus is placed on how bindings between communication endpoints can be established, including an overview of respective KNX and LON mechanisms. This presentation is intended as a tutorial to provide a better understanding of the goal of Plug and Play independent of particular implementations, outline what is being addressed today and what remains to be done.

2 Plug and play? A home or building automation system consists of various geographically dispersed parts Sensors, actuators, user interfaces; controllers, gateways Goal: Take a hardware component out of the box, add it to the system and make use of it without further configuration More realistically: Reduce setup time as far as possible Reduced setup time reduced overall cost Also reduces risk of configuration errors Page No. 2 Course of talk Functions of home/building automation systems What we want the system to achieve Breakdown of configuration tasks What it takes for these functions to be achieved Key aspect: Bindings between communication endpoints Brief look on different ways to establish them in KNX and LonWorks ISI Some thoughts about describing endpoint semantics Outlook Page No. 3

3 System scope & functions Building automation: functional buildings Energy efficiency, optimised management and detailed accounting (usage reports) Home automation: residential settings Energy efficiency a growing concern, although still largely comfort and peace-of-mind Core domain: HVAC, lighting/shading Measurement and control Monitoring, diagnostics, optimization of the control process Complex targets: Thermal comfort, lighting suited to current mood/task,... Continuous manual intervention part of routine system operation Increasingly also: security, safety, A/V control / consumer electronics, household appliances High-level control information exchange between stand-alone systems vs. deep integration Page No. 4 Implementation dimensions Smart, microcontroller enabled system components allow efficient transfer of complex information Embedded network, distributed system How shall the system function(s) be implemented? Design choices have to be aligned for all devices Application profile Communication stack Dynamic performance parameters (Partial) application functions Data type semantics (Process) data type syntax Communication interface (application layer) Medium Access Control procedures / physical aspects Interchangeable Interoperable Interworkable Interconnectable Coexistent Levels of (runtime) functional compatibility (IEC ) Page No. 5

4 Making choices When setting up an automation system, no one starts from scratch. Use available system technologies Developers have already thought about the same problem and made appropriate choices Medium access algorithms, protocol services, data encodings, standard function blocks But every project is different! Network topology Application parameters (time off delay, PI parameters) How many lights, which switches? Can be determined by smart algorithms Requirements, must be provided by humans Page No. 6 Making (project-specific) choices easier Designing the system towards reducing setup time Statically predefine as much as reasonably possible Allow automatic detection of project specific choices Simplify required manual configuration Decisions concern communication stack as well as application profile/model Support for multiple segments / media, function block design, Simplicity vs. flexibility Fewer choices quicker and easier setup Required flexibility depends on user s demands (and budget) Different systems for different types of projects Smart P&P approaches allow a better trade-off Cleverly manage (hide) the complexity that comes with flexibility System attractive for wider range of project types Page No. 7

5 Hiding complexity Automatic configuration Simplest case: Reasonable defaults (override only when required) Can only choose from possibilities that it was designed to deal with Simplify required manual configuration Support manual choices to only require essential input Needs to take into account the organisation of the setup process, actors competence levels and allowable training effort Includes usability concerns (UI design,...) Both depend on smart system model design Powerful concepts that can nevertheless be grasped quickly and handled efficiently Impact on resource requirements? Page No. 8 Project tasks Specify overall requirements on building services Apply specialised domain knowledge for dimensioning plants and systems (select actuators and sensors, design control loops) Apply high-level domain knowledge to define high-level control integration Break down the functionality and decide on the realisation (devices) Physically install and connect devices Commission programmable devices: program, configure, parameterise Test Page No. 9

6 Task assignment: buildings vs. homes Building automation Tasks tend to be assigned to different persons, strongly based on division of labour Design the software configuration Install the devices Actually configure the devices Continued in operation phase Tenants may only activate scenarios or fine-adjust temperature set points, rather than set up or modify them Automation is a separate trade But HVAC and electrical trades no longer provide stand-alone systems Configuration effort offset by large number of identical sub-applications Useful: simplify download of predefined setup (also with regard to maintenance) Home automation Less specialisation Self-installation (esp. white goods, brown goods) and management by the end-user No separate automation trade Integrated automation solutions partially provided by individual trades and white/brown goods manufacturers Configuration effort has a large share in system cost Application templates required Should still be flexible enough and leave room for custom extensions Page No. 10 Appropriate solutions With this background, the system designer can weigh requirements Which features shall the application have in the end? Where do I need flexibility? Where do I go for simplicity? and decide which particular task to support Cater to competence level, organisational background, For example, No configuration tool should be required for connecting household appliances For deployment in functional buildings, mechanisms need to scale to large numbers of devices Page No. 11

7 Supporting the commissioning step Functions and their realisation have already been decided on Factory-new devices need to be told their purpose Establish bindings between communication endpoints of device applications Ideally, they should be able to find out by themselves Unless they match more than one place in the overall application Manual intervention required to resolve ambiguities Entire application and device mapping predefined with configuration tool? Ambiguities at device level Typically in larger projects Device mapping only defined implicitly? Ambiguities at function block level Typically in smaller projects Page No. 12 Resolving ambiguities At device level, with central configuration manager a) Enter device serial number at manager (stickers) LT-S b) Enter freely assignable device tag at manager (Code wheels, DIP switches) LT-S c) Put device into listening mode, manager broadcasts unique tag S LT-S Cntrl. d) Have device send out a unique tag (serial number or assigned by manager) Cntrl. e) Manager enumerates and sequentially highlights possibilities, user confirms (or disapproves) Cntrl. At function level (set of endpoints), peer to peer As in (b), but setting tags at both partners LT-S LT-R As in (c) or (d) now symmetric PB LTE (a) would be cumbersome; (e) only useful with minimum UI could use manager A Approaches have different strengths Online/offline, device replacement, (deprecated) Page No. 13

8 Determining matches Manager or individual devices need to be able to determine suitable matches No ambiguity no manual intervention should be required Only allow (or offer) potentially useful bindings Discovery and self description Network and device management services Device level: Manufacturer + Application IDs Function level: Channel codes, Connection codes; Object types - Channel: set of Datapoints, Connection: single DP + channel-related semantic Flexibility vs. determining matches easily; combinatorial issues Content addressing Functions and zoning information mapped to group address namespace Use default zone/tag in case of single instance Page No. 14 Everything easy? Or automatic? KNX configuration modes exist in parallel universes (more or less) Different strengths e.g., TX-only device support, downward compatibility Use identifier namespace differently LTE-mode and A-Mode also differ in runtime interworking Interface object properties, group interface objects Lowest common denominator: S-Mode interface And due caution (respect reserved ranges) Page No. 15

9 LonWorks ISI Interoperable Self Installation Freely published company standard, licensed Introduced in 2005 (together with Powerline smart transceivers) Support for one TP and one PL segment < 32 devices or < 200 with domain address server LON communication and interoperability Various channel types, most important TP (FT/LP), PL, EIA-852 Addressing modes: Broadcast (single subnet or all subnets), unicast (subnet/node or Neuron ID), multicast (group) Acknowledged unicast and multicast, repeated and single unacknowledged delivery Network Variables, NV selectors LonMark interoperability: SFPTs, SNVTs, SCPTs Device identification: Service pin, Wink function Page No. 16 LonWorks ISI Invitation (user initiated or periodically) Provisional approvement (if user intervention required) Acceptance Local user interaction or via connection controller (discovery) Matching connections determined via profile number + variant Connection assemblies (or single SNVT) Partial connections possible (local responsibility) Automatic connections announced differently Fixed assignment of group address space to usage categories Sensors, HVAC, Fire and forget Lower-layer network resources (subnet/node addresses, NV selectors) are chosen at random and their use announced; other devices have to give way Unacknowledged multicast (optionally acknowledged unicast) Page No. 17

10 Project specific endpoint semantics Project specific endpoint identifiers (tags) Need to be the same on both sides of the connection to establish a binding But is this everything? Consider adding a visualisation panel Manufacturer-provided self description cannot tell me if a tag belongs to the light in the lobby or the living room Endpoints now require specific local context to be useful Usually, this is recorded in the panel Now, consider adding a gateway for remote access Record everything over again? Suggestion: Localisation database Available for access over the network Implementation e.g. as Interface Object, discovery via NetworkParameter_Read Information only needs to be maintained in a single place Easiest form: Key-value map (group addresses with Connection V attribute description string), advanced: tree structure/s (location of effect, ) Start with push-button binding, add complexity only as required Page No. 18 Outlook Automatic routing Protocol security Resource efficiency Regarding configuration procedures as well as resulting communication relationships Even more important for wireless networking Mesh topology, totally open medium Improvements regarding the design of the distributed application model Simple yet powerful; better integration of configuration modes Page No. 19