fr=en Introduction au protocole xAAL ****************************** Version 0.2 *********** Jérôme Kerdreux Corinne Le Moan Christophe Lohr ===================================================== Abstract: This paper gives a description of Xaal protocol as defined by IHSEV team Télécom Bretagne and its status in 2014. 1 General architecture *=*=*=*=*=*=*=*=*=*=*=*=*= Xaal The system revolves around a bus multicast IP (IPv4 or IPv6). It is basically a distributed architecture: the functions described below may be present several times, be implemented and grouped in several different ways hardware and dialogue all through this bus Xaal. There are several advantages to a communication bus: - Do not handle a set of point-to - points which saves the resources of automation equipment. - A bus allows the discovery when a new component appears in the installation, it looks; All other entities are then taken into account. Similarly, when you add a component, it can query the bus to discover the elements already present. This greatly facilitates the configuration and allows dynamicity and scalability. 1.1 Functional Architecture =============================== Figure 1 shows the general functional architecture of the system Xaal. ---- bus-xaal_devices bus-xaal_databases bus-xaal_activators Figure 1: Functional Architecture Xaal. ---- Native facilities. Home automation devices (sensors, actuators) can communicate natively in Xaal protocol. Gateways. More likely, the automation equipment of each manufacturer only support communication protocol of the manufacturer. Therefore, take care of gateways translate messages between the manufacturer and the protocols Xaal protocol. At this level it is assumed that there are as many as gateway manufacturer protocols to support the building. Following the manufacturer's protocols and technologies, each gateway will handle issues of pairing between the gateway and home automation equipment it manages problems addressing and configuration of automation equipment, and manage the persistence of the configuration information. Note that it may be interesting to examine a gateway on the mapping it makes between Xaal addresses and physical addresses of the manufacturers equipment. Even if it interacts with the devices via Xaal Xaal their address, the mapping information managed by the gateway may be advantageous for the configuration of the database ( described below). Indeed, during installation, the installer usually notes the manufacturer of the equipment with its physical address location in the house. To facilitate the configuration of this database ( the location information associated with the address Xaal the device), it may be interesting to the beginning by the identifier or the manufacturer of the device address. Registres schemas ( Schemas repository ). Generally, the home automation equipment to be described by a schema ( the nature of the equipment, the interaction ). These different patterns are listed in one or more registers diagrams. These registers patterns are present on the bus Xaal. Other entities interrogate, via this bus, to get the description schema other equipment ( such equipment are active or not on the bus). - It queries the registry on a type identifier, it sends us his scheme, if known. More specifically, it retroune us a URL where we can download the schema. - Associated with a schema, in addition to the description of the device itself, there may be metadata: the language are written descriptions, dates or version number, the url for documentation, for the url the HMI ( points to html fragments, possibly hosted on the internet), etc.., a url for update, etc.. - Note that the registry is also described himself in a diagram ( to be drafted). This scheme must be able to describe how to advertise schemes ( so it is a little meta ) In a given installation, there may be zero or more registers patterns on Xaal bus. The schema definition of a device must be especially careful. A number of these schemes general purpose must be written by our international office Xaal standardization. More specific patterns may be written by the manufacturers themselves. Consequently, there can be conflicts: a schema name given several registers on the bus could return schemes with differing descriptions. Then there should be a mechanism for conflict resolution: either statically where a director comes invalidate / delete schemas problem in a register or dynamically where records broadcast priority information in addition to the schema itself ( then load the receiver to sort ). This point has not yet been resolved in the current specification. In addition, we can consider several ways to update these records: via Xaal bus itself, or via the Internet ( the register will download schema files to addresses that have shown him), or by a other means ( installation CD, etc.. ). Again, this point will be clarified later. Metadata Database. Each automation equipment within a facility, should be involved a number of information: at least location information (eg, declare that the equipment lamp type and address X is located in the. kitchen), and possibly a symbolic name (eg. equipment that address X is called "lamp - 1"). All this information is grouped into a metadata database. Concretely, for openness and extensibility (as flexibility and not in the sense scalability ) worry, this information is materialized by tags. This database contains somehow configure the automation system. The metadata database is present on the bus Xaal. Other entities in question via this bus for the tags associated to the identifier of a device, or conversely a list of devices associated with one or more tags. - It accrues with the device ID, type, a series of keyword (tags) to locate the house - You can update the information on a device - It asks to see the tags associated with a given ID - It asks to see the ID tag associated with such or such type - We know the questions to existing tags - You can delete a record - Note: A device can be said in this database without being present on the bus It should have at least a base metadata on the bus, but there may be several. Again, the creation of this database must be established with the greatest care. Therefore need to implement the traditional mechanisms for organizing tags: check inconsistencies, synonyms, ambiguities, provide facilities renaming tags, etc.. The classic trap being would specify location information in two places, for example indicate a friendly name tag "living room lamp ", then add location: "living room"(and even in this case the information is redundant but convergent... ) Note: this notion of friendly name can be found in UPnP... In fact this mechanism is a source of problems: either it is diverted from its role in addressing return location information as in the previous example, or it is left to the manufacturer value (how DLNA TV or android smartphone to have friendly name: Media Server... ) Cache. It is common to have unidirectional sensors, we can not ask, and send their information sporadically. (eg. sends a thermometer so that the temperature has changed.) He should have at least a cache that stores this information and other entities can query whenever necessary. Such a cache should store at least the notifications issued by the devices. One can question the relevance of trade also store type command / response. As with any caching mechanism, you must associate a timestamp to cached information. When another entity on the bus Xaal request information in the cache, it specifies the maximum length. This is not the cache itself manages the relevance of data according to their age, but the client makes the request. Again one can imagine that inconsistencies occur if two caches on the bus returning differing information but with the same timestamp. It is estimated that this is a priori rare, and therefore it does not intend to define a specific mechanism in the specification to disambiguate. We leave it to the customer to sort the information received according to its own criteria. Automaton of scenarios. Among the advanced home automation services, is the notion of scenarios: for example run a full sequence of actions from a user click, or scheduled hours or monitor sequences of events and react etc.. To do this, Xaal provides that this is supported by one or more entities PLC type scenarios. These controllers scenarios are also the favorite place to implement virtual devices: for example, a scenario could aggregate and correlate a variety of events real devices to synthesize information such as "presence"and generate such a notification on the bus which could then be re- operated by other entities. By proceeding in this way, this scenario should appear as itself a device on the bus, with its address and its schema. As always, there may be inconsistencies or conflicts between scenarios ( one lights the lamp, the other off), or interbloquent, etc.. This is not the Xaal specification itself that will prevent it. Conflicts are supposed to be treated as far as possible off-line when editing scenarios. The specification does not require the use of a model-checker based on colored Petri network delayed or anything like that... This is still a research topic, although very interesting, but outside the framework specification Xaal. ( If anyone wants it, it can introduce a monitoring device, which is itself a kind of engine a few specific scenarios. ) User interfaces. One, or, user interfaces are provided by specific entities connected to Xaal bus. This can be a real hardware device with a screen and buttons; or a software component that generates eg usable Web interfaces in a browser on a PC, TV or other connected; or software that provides a REST API for mobile applications ( tablets, smartphones ) or to an external server with a service. Again, it seems natural to have several user interfaces ( smartphone, tablet, remote control, etc.. ) In a home automation system. synthesis Such a functional architecture to manage dynamic aspects of infrastructure ( modularity, scalability, adaptation, etc.. ). Thus, advances such as HMI or engines scenarios functions, can automatically adapt to the infrastructure and its modifications (if equipment entering / leaving, if one fails or is replaced, etc.. ). The typical operation of an HMI could be this: . 1 query the bus to identify equipment present; . 2 query the registry schema for the type of the equipment, the type of data from the sensors / actuators, the possible commands, URLs to retrieve icons; . 3 query the metadata of sensors to discover the configuration of the installation ( see the symbolic name, location and other tags associated with each piece of equipment ); . 4 query cache for the latest known states such equipment; 5. Dynamically build display screens and control interfaces for equipment. 1.2 Hardware Architecture ============================= The interest of such a functional distributed architecture is to allow greater freedom regarding the placement and grouping functions on hardware. For example: - A manufacturer of automation equipment could sell a box that would include: the gateway to its own home automation protocol, the directory schema for equipment of its brand, the cache of equipment managed by the gateway, some automated scripts to manage devices virtual, and a small metadata database for its own sensors to note their location. - An operator of automation services could sell a box ( different from and complementary to the first one) that would include: the database location, automated scripts, web interfaces and REST to communicate with servers in the cloud and provide services fortified, etc.. - A provider of virtual services (ie A.D. selling only service and no equipment ) could provide a mobile application for smartphone or tablet embark: a user interface, a controller scenario, an interface to its external servers for advanced services, etc.. - A service provider (. Eg personal assistance, tele-medicine, etc.). Could add its box ( yet another ) that would include: a gateway for specific equipment (medical, remote alarm, etc.)., unattended monitoring cases, an interface to its external servers, etc.. - A manufacturer of innovative connected objects could sell these connected objects embark: the automation component itself speaking natively in Xaal the registry schema describing the object itself, ATM scenario, an interface to its external servers, etc.. - Services or scenarios a bit muscular (. Eg based on actigraphy, or composition of adaptive services,... ) could be composed of a scenario engine coupled to the cache, coupled to a base metadata. The reliance on IP as a means of interconnection and lightweight protocol that allows Xaal hopefully, flexibility and better interoperability between these different actors who have nothing else to prove to competition Xaal of messages. The real sticking point is the definition of patterns and the rigor with which one would flounder in implementations... The transport layer 2 *=*=*=*=*=*=*=*=*=*=*=*=* It uses IP multicast (IPv4 and / or IPv6), UDP so. - The IP multicast address is defined. - The port number is also set. May reserve a range of ports. - If there are several "home networks "in the home, they use different ports. - Messages will be limited by the size max UDP size (eg 65507 bytes in IPv4. ). IP fragmentation is allowed to operate normally. ( As opposed to approaches such xPL that terminal 1500 and implements continuous. IP fragmentation already handles this very well. ) Remains the problem that some PICs do not necessarily manage well the IP fragmentation (eg. The stack basic Arduino ). We only recommend trying to be limited to 1500 bytes. If services need to exchange larger amounts of data between devices, they are asked to identify the automation bus (which is not made for it ) in favor of another transmission channel ( eg. A TCP connection ) they can advertise against by the Xaal bus. - The IP Configuration is the senior executive Xaal system. Equipment can use the static IP configuration, DHCP, the IPv6 Router Advertisement of Zeroconf, a Link- Local address ( 169.254.0.0/16, fe80:: / 64 ), etc.. Note however that because of the use of a multicast bus, the source address of the transmitters is relatively small ( and not used in this case). Some equipment might as well use IP addresses can hardcodée... - Attention is drawn to future developers of the horrors that have been seen in implementations of xPL or XAP bus (often in Java or Net. ) Potential: the use of a "hub", a software component that repeats posts bus for applications on the same machine. This is useless on almost all current operating systems: applications on the same machine may well each have their own socket on the multicast bus, as long as the socket options dedicated to used it (typically SO_REUSEADDR and IP_MULTICAST_LOOP )... - The choice of IP multicast requires almost UDP. UDP does not manage to detect packet loss and retransmissions, there could have been more comfortable to choose TCP. Here are some arguments that can reassure people cautious towards UDP: In the context of a network at home, it can be assumed that packet loss, though still possible, is a priori rather ESPP. By construction Xaal is quite undemanding towards processing error ( see 7.3); From this point of view we Xaal parrait rather robust. Use TCP to manage packet loss only shifts the problem in the protocol stack ( and heavy way: it is systematic, and the TCP controller is resource intensive ). In Xaal if we need to handle this (which finialement is not necessarily a systematic necessary), this will be at the application services ( located on equipment entitées which generally has the comfortable resources). 3 The presentation layer data *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= It is to decide whether the data manipulated by the Xaal buses are rather text-based or binary in nature. This point has been discussed within the team, where two schools of thoughts wonder. 3.1 The binary protocol approach =================================== The main motivation is to stay low: a protocol that can be encoded in a PIC (eg C base. ), Rather than a sophisticated middleware from the PC world and web applications. This does not mean that it is compact / compressed messages, but simple messages to manufacture and parser ( without structure to cast C ), self-sufficient, in a constrained format, with a variability constraint a predictable size, etc.. More concretely we decide to essentially manipulate 32-bit words, aligned on 32-bit (ie, with the jam if necessary ). The disadvantage is that the phase of debugging messages is more complicated than a textual approach, because then you have a validated tool for analyzing the frames exchanged. The other drawback and that it is too far techno trendy (around the web), and it will be a priori more difficult to join a community. Finally, this is not the approach that was chosen by the team for the implementation of Xaal. However, a draft specification has been defined and is available on request, this is version 0.1 -bin In the future it might be interesting to look at the Mihini/M3DA protocol to do this just... 3.2 The text-based protocol approach =================================== The advantage of a text-based protocol is that it is easier to debug, just by looking at the frames exchanged. The disadvantage is that the messages are more complex to build, and even more complicated to parse. The compromise adopted was to choose as Json data exchange format. Many libraries are available in many development environments. In addition, it is close enough to the Web world, as the latest generation of computer scientists were overwhelmingly and primarily trained in web technologies, we can expect a better adhesion to the public, as well as with some public policy-makers... It is this approach that has been experienced in previous implémenations of Xaal made ​​in the team: it was version 0.1- json Version. The specifications in the following document for version 0.1 are based on this text protocol approach and extend it to describe the current version... An interesting alternative might be to use some aspects of CoAP (1 ) (or a subset )... To consider for the future... even if proximity to the web world seems nevertheless to limited technical interest... 4 Definition of a device *=*=*=*=*=*=*=*=*=*=*=*=*=*= A device has: - A DEVTYPE: this reference name scheme, that is to say the type of device. It is hard-coded into the device. - This identifier scheme is a string consisting of a pair of words separated by a dot. - The first word refers to a class of device type (eg lighting, heating, multimedia, etc.. ).. - The second word refers to a type in a given class (eg in lighting class was a one -off lamp, a lamp with dimmer, a mirror ball, etc.. ).. The second word may reference the schema extensions manufacturers ( cf. 5.1). - The identifier. "Any any "type is reserved and refers to all types of all classes. - And for example the couple "lamp any. "Means all types of class "lamp". - We reserve a special name: "experimental "( ie when someone of an implementation but has not got a name for our international standardization Xaal office. ). And this for the class, as well as the type. - An address: a device ID, a unique number on the bus. - The device identifier is a 32-bit integer. - Address 0 is reserved. This is the broadcast address and refers to all devices. - How is assigned an address? - Is hard-coded in the factory (the first 2 bytes are a manufacturer number assigned by our office numbers are assigned, the rest is at the discretion of the manufacturer (serial or otherwise), so YES Ethernet) - Auto- generated (random ) if YES ( ie of the first 2 bytes. ) Is 0xFFFF? - But verified by a kind of "free arp "by isAlive queries to check that someone else has not already - But certainly not assigned by a supervisor or another bus thingy gender! - A device may consist of several devices. This is typically the case of a gateway (eg. Equipment that will make the bridge between our bus and X10 home automation, or Zigbee, X2D, Somfy, etc.. ). But it may also be the case of a small weather station that measures indoor / outdoor temperature / humidity / etc. - Such equipment is then called composite device, - And each of its components is an embedded device. - The composite device is announced (possibly ) itself on the bus with its own address and its own schema name. Can specifically interact with (e. g to its config, consult your battery level, etc.).. He also announced the list of its embedded ( their address) - Each embedded is also announced on the bus like an ordinary device, bus - native, with its own address and its own schema name. Everyone is announced by specifying its parent, ie d. the composite to which it is hung. (Note: the real bus - native devices have to parent = 0) - A composite device can also choose to be invisible, do not announce himself, or report that has embedded, or that its embedded have to parent. 5 Defining a schema (or type of a device) *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Each device is typed, ie d. described by a schema. The scheme is heavily inspired UPnP ( 2). We have not yet defined dialect to write these patterns. Presumably it will be XML ( still writing the DTD). - The diagram gives a bit of a semantic device and describes its capabilities: a list of possible methods on this device ( mechanism of request-response ), a list of notifications that spontaneously emits, and a list of variables state of the device ( the device on the bus ad spontaneously change any value). - A list of methods. Each method is described by: - A unique name that identifies the schema. - A textual description (see later how to handle the language and issues of internationalization) - A list of arguments, each argument is defined by: - A name - A direction ( in / out) - The unit ( meaning the International Bureau of Weights and Measures... ) - A description - A list of notifications. Notifications are messages that the device emits spontaneously on the bus. These notifications are defined by: - un nom, - A description - A list of variables (name, unit ) - A list of state variables. If the value changes, it generates a default notice on the bus. ( Note that a device may well be composed of a number of additional internal variables that are not monitored and are not subject to notification... ) Each state variable is defined by: - A name - A description - The unit - A default value (? ) 5.1 Inheritance patterns. =========================== There is a notion of inheritance between schemas, schema can extend an existing schema. We define the first 3 levels of this genealogy: 1. A common generic scheme for all devices of the bus, everyone must implement. 2. A specific pattern to each class, which inherits the general scheme (lamp, thermometer, switch, thermostat, etc.). 3. A specific pattern for each type that inherits from a class diagram, which indicates the level of functionality (eg. Lamp type can be on / off, some are of the trigger, and others with dimmer... ) 4. Thereafter, manufacturers of home automation equipment will naturally define their own schemas and the decline of their product range. By cons, it is forbidden for these schemes to be builders schemes Level 1 ( generic schema is single ) or level 2 diagrams ( class diagram ). Patterns manufacturers are necessarily extensions schemes level 2 or higher. In terms of naming schemes (pair pointing described in 4), the second word is at the discretion of the manufacturer. ( Manufacturers frustrated this situation are cordially invited to discuss with our office standards if they wish to introducing new schema level 2 or 3. ) Note: imagine, listing the APIs of devices described by these diagrams, some devices will not be able to listen to the bus and will not be that issuing it, only notices of state variables. 5.2 Naming patterns ========================= It will give greater rigor in naming patterns in order to maintain maximum consistency in the minds of all... In too many systems ( XAP xPL not name them), naming devices and their typing is regularly misused to encourage the return of concepts who do not have their place. What a schema. Two things: It is hoped that the schema name refers above all to the functionality of the device, means to interact with it. This name must also discuss the nature of the sensor. That is not a schema. - The name is not meant to refer to a technology manufacturer (and even less to a specific model). - The schema name must not refer to use: a switch ( that transmits "open / closed"notifications) can be used both for safety ( on windows or door ) that actimetry ( on ​​kitchen drawers ); remains the same thermometer thermometer ( that sends notifications of temperature ), it is dedicated to a weather station or the management of heating. So there is no need to have categories like security or HVAC (Heating, Ventilation and Air -Conditioning )! These are chapters in a sales catalog builder, not categories of functions of home automation equipment. At most, the role associated with a sensor ( security, heating, etc.. ) Is storing a tag in the metadata database installation. - Must be carefully avoided tote categories such soft (it has already been!). Obviously that was a number of software components... Also, some equipment will be purely software (eg application of web- radio in a PC). The fact that the component is in soft rather than hard has no interest point of view Xaal. 6 generic diagram *=*=*=*=*=*=*=*=*=*=*= This is the database schema. All other regimens should inherit one way or another. - Internal parameters: - Devtype: the name of the schema to which the device obeys - Address: 32-bit integer ( the address of the device) - Parent: a 32-bit integer ( The address of the parent in the case of a composite, or 0 if not ) - State variable: - No imposed in the generic scheme - Notification: - Alive: issued when starting the device and then periodically at a rate left to the discretion of the device. The notification message contains no parameters, no body. - StateChange: issued at each change of state variables. The message body contains only state variables that have changed. - Error: issued when the device detects an error. - Description: The text description of the error - Code: a code (numeric) error. This is intended to be overridden in the definitions of specific patterns. - Methods: - IsAlive: no attributes and no return value. However (or ) receiver must respond as much as possible by a notification alive at all (ie A.D. not reply with a message to the author of the application). - getDescription - VendorID (out): string or number assigned by the office? - ProductId (out): string - Version (out): string - Parent ( out): address of the parent if there is one, or 0. - getState - \u003cvariables \u003cstatus: A priori this method will be overridden in the definition of specific patterns of each device to return all state specific parameters added by each type of device. - Attention: we do not return the internal parameters devtype, address that are anyway in the header or the parent is given in getDescription. - setBusConfig - BusAddr (in / out): a string giving the IPv4 or IPv6 address of the bus on which Xaal switch. If the returned address is not the one we were sent is that the device could not be set above (in short, there is an error). - Busport (in / out): an unsigned integer (well, limited to 65535), indicating the port on which switch Xaal bus. Similarly, if the value returned is not the one that had been sent, is that there was an error. - TTL (in / out): an 8-bit unsigned integer indicating the TTL used for sending multicast packets. A priori we put 1 by default, but after all it might also want to change... 7 Defining a message *=*=*=*=*=*=*=*=*=*=*=*=*=*=* A message consists of a header portion and a body portion. The header is mandatory, while the presence of the body is optional. Figure 2 gives an example of exchange Xaal messages. ---- \u003c\u003c{ "header": \u003c\u003c{ { "header": "version": "0.2", { "source": 16778244, "version": "0.2", "target": 39595606, "source": 39595606, "msgType ": "reply ", "target ": 16778244 "devType ": "thermometer. queryable " "devType": "thermometer. queryable", "action": "getState", "msgType": "request", "cipher": "none", "action": "getState", "signature": "" "cipher": "none", }, "signature": """body": } { } "temperature": 9.3000000000000007 \u003e\u003e } } \u003e\u003e Figure 2: Example of messages Xaal ---- 7.1 Header =========== The header of a message comprises: - Version: The version of the protocol. This document describes version 0.2. - Source target: is source and destination addresses of the message. Note that the destination address can be 0, in which case the message is broadcast category. Receptors (ie everyone ) are invited to filter the relevance of message types ( schema name ) of the device. Notification messages are often broadcast type, but not necessarily. In contrast, the response messages are returned to an application specifically address of the applicant. - Devtype: the schema name (torque type class. ) To which this message. So typically if it is a message of request type is the schema name of the recipient device, and if a response message or notification type, the diagram of the transmitter. Note that in the case of a request (broadcast or not ), the applicant may use the keyword any to the class as for the type. By cons, in their reply (if any), the devices concerned explicitly specify their DEVTYPE. ( I actually can not have ANY in the responses and notifications. ) - Msgtype: message type from request notify reply. Thus, typically, a message request is followed by a reply if necessary to return values ​​to the requester. Note that we do not require sequence number or id request-response... We can have some inconsistencies: we discuss below. - Action: The name of the action brought by the message from the list of methods and notifications described in the schema whose name is indicated in the message. - Cipher: the safety mechanism used in the message. So far none has been defined mechanism... In the future we may consider the mechanism SHA ( SHA1 SHA256 SHA512? ) Shared across the bus key. One can also consider a type mechanism PGP asymmetric encryption, the private key of each device being hardcodée, and public key written on the label and shared ( and witnessed ) in the bus... See below for a discussion on the subject. - Signature: the signature of the message by the selected cipher... 7.2 Body ========= The message body is optional: it all depends on what has been defined in the schema in question, depending on the activity and the type of message. Therefore, where appropriate, the body of the message contains a list of key - value. 7.3 Error Case =================== The spirit of Xaal specification is primarily to focus on interoperability. It is guided by the desire to offer, but not to force... Consequently, the Xaal protocol has very few safeguards against the failure. It is the responsibility of the component implementations Xaal to do the best. The specification says nothing about the lack of response. On the one hand, since it is UDP, the query as the answer may be lost. On the other hand, there are who know that issuing device and not listen on the bus. The specification does not impose any timeout mechanism: some device does not necessarily have clock at hand and can manage responses to requests in a circular buffer (and if a reply arrives so late that we forgot question, too bad ) Another argument concerning the non -response to a request: in the case of a non- unicast (ie actually broadcast or a class type ) query, it seems natural that the equipment can not honor the request may choose to remain silent rather than pollute the bus with error messages. In some cases we may want to ensure that messages are not lost (eg. Central alarm). Since the loss is not supported by the protocol layer Xaal itself, this can be supported by the application above. We can consider several strategies: - After an action request to a device, the device asks the transmitter to see if there has been a change in its state variables; - Api action may introduce an ad- hoc parameter (eg requestId. ) The device must repeat his answer; - Etc. The case of error or inconsistency are possibly many. The specification does not impose a specific behavior. So, faced with an inconsistent message duplicates, answers or contradictory statements, the behavior is unspecified. One might want to declare nevertheless that, faced with a poison message, we have the obligation to reject, ignore. Unfortunately, for some equipment, it is not possible to undo what we started to do ( not enough memory or partial action). In short, the specification imposes nothing. Load implementations to be careful, and do the best. For example, in some cases it is relatively easy to decide: - A device receives a request to address to him, with a specific type of device, but that is not his. It can easily identify the problem and ignore the request. - A device receives a request but the name of the method does not exist in the schema. It can easily identify the problem and ignore the request. - A device receives a request but some parameters are of the wrong type, or missing parameters, or there are too many. Thence cases, it may have started to partially fulfill a number of tasks for the requested method and may end up in trouble. There may not undo what he has begun, and therefore can not impose will reject the message. If he does, that's fine. If not, too bad. At most, it sets an error code that goes. - Conversely, if a certain response variables do not have the right type, if missing or if there is too much, the device may have started to partially process the response... is asked to at best. - If the schemas are written carefully, we can also provide a number of notification messages error. But this is the responsibility of the scheme, not Xaal bus. 8 Security *=*=*=*=*=*=* In preliminary work, we have not proposed a model of security mechanism. However, this need seems inescapable today. This section provides some food for thought. We can consider that the underlying link provides some level of security. Consider an infrared remote control RC5 link ( or RC6 ) is not encrypted, and hack the transmission between the remote and the TV, it is necessary that the neighbor can aim with the remote control through the window. These are the walls of the rooms that ensure the security of the transmission, not the protocol itself. It is the same for IP protocol should already be on the network to attack. Must be physically present to wire Ethernet, WiFi connections have wpa keys (usually ) remains in CPL existing encryption is enabled but rarely... And finally, remember to contrast the firewall configuration of the home network can be bad, or PC on the network can be compromised by virus... 8.1 Need for security ========================= When we talk about security, we must first define all - against what we want to protect. It is not a question of dealing with cases of failure, but rather cases of malice. Among the classical precepts of security (integrity, confidentiality, availability, non-repudiation, authentication), what is does one need? At a minimum, we need to ensure the authentication of the sender of the messages, the messages are not corrupted, and there is no replay. Remains the issue of confidentiality: a priori it is not necessarily matter much if the neighbor just listen ( as it can not inject false messages). However, in some cases to use it can be annoying: just knowing that the control panel is removed or the door is unlocked can be problematic... On the other hand, keep in mind that it was very light equipment and the encryption mechanisms are resource intensive. In addition, to implement them must go through a phase configuration ( keys ), and that this can be problematic. (You can draw inspiration from several auto configuration mechanisms key as WPS WiFi. ) 8.2 Proposals for safety =============================== - "Cipher ": "none": you have to keep the ability to communicate without encryption, just for all those equipment that are too light to embed encryption mechanisms and configuration keys. - "Signature": xxx: nothing but a signature mechanism with a conventional hash function (MD5 SHA1 SHA-256 SHA-512 Blowfish... ) with a shared key ensures authentication and integrity. Against by this means to manage the configuration of device to give them the key. Another approach is to use asymmetric key mechanisms: the private key being hardcodée in the device, its public key is written on the label, with a mechanism for dissemination, sharing and against signature of these keys ( to PGP ). Nevertheless, to avoid replay must be added in the signed message a little something that makes it unique... For this, you can add a timestamp (and avoid replay frame captured there too long ). Or, in the scheme of the device can provide a mechanism for challenge: first ask the device a cookie, then return it in the message by signing it. Such a mechanism is expected in the diagram of the device, not in the Xaal protocol. - Confidentiality: this involves encrypting the information themselves carried in the message. There are two possible approaches: - This can be specified not in the Xaal protocol but in the scheme of the device that needs it: we exchange a public data parameter, but the value is encrypted. - Another approach would be to redefine the message format in a new body but fully encrypted block. At present, all this is still embryonic. However the general idea is that security must be possible but optional. 9 Best Practices *=*=*=*=*=*=*=*=*=* Xaal the specification itself allows many things, good and bad... Over the preceding pages some suggestions of good practice were discussed. We combine them here. 9.1 Device composite ===================== In the world of automation it is common to find facilities that include several functions in one unit: eg thermometer, door switch, pilot wire. In Xaal This is organized around the notion of composite device. ( This is our way to make multiple inheritance... ) This device will then expose as many devices as Xaal elementary functions. In the example here: a device with the thermometer scheme, a device with the door switch diagram, a device with a wire diagram driver. In addition, the device will expose himself with the composite diagram, whose sole function is to list its embedded devices ( give address and diagram). The fact of exposing themselves as composite is not mandatory, it is recommended only: it does not provide additional automation functionality, but it can express the hardware architecture, which can aid in the diagnosis and maintenance. 9.2 Gateway ============ Summarize the role of a gateway: - Xaal transform messages into messages of a home automation protocol manufacturer; - Manage the pairing between itself and manufacturer devices; - Manage the configuration of these devices (eg Z -Wave is bidirectional, it is based Z -Wave which causes some settings to devices: the gateway is then the base Z -Wave, it manages the Z-Wave parameters but does not expose the Xaal bus); - Expose the manufacturer Xaal bus devices with their address and Xaal Xaal scheme; - Do the mapping between the address and the manufacturer Xaal addresses; Note that this mapping can be useful to help database configuration metadata ( for example, when the power is reconnected after installing several automation equipment: all will appear in a mess on the bus... so we need to identify which is which ). We can therefore ask the gateway on this mapping. For each device, the mapping is typically a pair: address Xaal Constructor address. On one manufacturer to another, the notion of address may have a very variable form (eg sometimes the notion of group). However, Json allowing dynamic typing, the address format for each manufacturer will be defined later. ( At the very least it is a dictionary that contains the variable ProtocolName. ) - Do the translation between the functions of manufacturer devices and methods described in Schemes Xaal; This translation is fairly straightforward principle, the gateway is transparent quasiement this point of view. By building a gateway appears as a composite device. This is a somewhat more sophisticated than the simple composite device previously described composite device, but it is a device that exposes itself as such on Xaal bus. There is the case of the gateway that will handle equipment manufacturers who themselves are of a composite nature. Take the case of "opening 3 in 1 FIB- FGK -101 Sensor."(3) This equipment is Z -Wave: door switch, thermometer, relay digital data ( for connecting an extension). The Z-Wave gateway will therefore exhibit on the bus Xaal: - A door switch device (with a schema "door switch "and its own Xaal address); This device has relative to the composite device described hereinafter. - A thermometer device (with the scheme "thermometer "and his own Xaal address); This device has relative to the composite device described hereinafter. - A device "digital data "(with a schema "digital data"and its own Xaal address); This device has relative to the composite device described hereinafter. - A composite device (with the scheme "composite "and his own Xaal address); This composite device has embedded the previous three devices. Moreover, it has the relative gateway described below. - A gateway device (with the scheme "gateway"and its own address). This composite device has embedded the previous four devices. It has no parent. 9.3 Virtual Device =================== In the functional architecture Xaal, PLCs scenarios are an ideal place to implement automation services "intelligent". For example: - On receipt of an order, trigger a whole series of action ( eg "evening tv". ) - Or conversely, by correlating a variety of events, synthesize information (eg "presence."). In so doing, the PLC itself appears on the bus as a Xaal device as such. It is a virtual device, but a device with its own methods, notifications, state variables: short, it is defined by a schema and other entities can interact with it via the Xaal bus. 9.4 Device overloading another ================================= In a home automation system may be used to MFPs. Consider for example the "Z -Wave Micro -module on / off switch FGS -211."(4) This equipment has a size studied to slip into a wall outlet and control any electrical device ( lamp, fan, shutters, etc.. ). This type of micro -module, more current, provides complex functionality. Here is what the catalog about this: - Functions on / off ( relay ) controlled by Z -Wave or connected buttons. - Can use 1 or 2 buttons (the second option button can control one or more other modules associated with Z -Wave ). - The buttons can be bistable (on / off) or monostable ( pulse pushbutton ). - Back to Zwave state. Therefore, the Z- Wave gateway that supports will exhibit on the bus Xaal the following devices: - A device type relays with state feedback (with the scheme "relay", and its own address ) corresponding to the device connected to it and thus controlled by the micro-module ( but at this level it does not say if c is more than a lamp or fan shutter ); - A button device type (ie with the "flip "scheme, or the "shot "following diagram the configuration), and corresponding to the second button, the first button possible being used for manual control of the relay; - And incidentally a composite device incorporates the two previous ones. By cons, we lack the configuration information as what behind this module it is a lamp that is controlled and not a fan or shutter. To do this, we'll use a Xaal entity, a new device that will expose the "tube"type and do the translation between actions on this device and actions on the device "relay status feedback "described above. This new device is a little virtual, but mostly it just overload the generic device. Then it can be described as device overload. (And a view Xaal, it will as a parent generic device. ) Note that since it is the gateway that exposes this new device overload, this gateway is not completely transparent in our architecture: it must declare how to configure specialized generic devices. We believe that there should be setting at the gateway and not in (for example) the metadata database. Indeed, it is the setting of inner workings of device, not an attribute which we have just the rich. Strictly speaking, a gateway that will handle a generic micro-module will therefore exhibit on the bus Xaal two devices: one generic, the other overload. However, for reasons of simplicity of implementation ( and also because we know how are the developers ), it is quite acceptable that the gateway makes the economy of the generic device and exposes on the bus Xaal the overload device. 9.5 Device caché ================== Some devices are not intended to be presented in user interfaces. This is the case of gateways, composites, engines scenarios metadatabases, caches themselves interfaces, generic devices are masked by an overload device, etc.. Do not make a priori on the hidden or not the devices, it must remain an explicit tag in the metadata database (possibly with a default value according to the class diagram, but can be changed later ). User interfaces know all devices ( hidden or not), but choose to display only those that are not hidden unless the user explicitly requests (like in its file manager on your PC you can choose "show hidden "files). This information (specify a device is hidden or not) could be a purely local property HMI and be managed locally via the HMI. However, we think this is specific to the automation system characteristic and must be stored in the metadata database and available to all. A Draft patterns *=*=*=*=*=*=*=*=*=*=*=*=* At present, the formalization of patterns has not yet been decided. Nevertheless, some general ideas about what could contain these patterns. \u003c\u003cNotes: - P: internal parameters - V: state variables - m:méthodes - n:notifications generic ======= p:devType p:address p:parent n:alive() n:stateChange(out v: ) n:error(out description, out code) m:isAlive() m:getDescription(out vendorId, out productId, out version, out parent) m:getState(out v:*) m:getBusConfig(in/out busAddr, in/out busPort, in/out TTL) lamp. basic (extends generic) ========== m:powerSwitch(in/out bool target) lamp. queryable ( extends lamp. basic) ============== v:enlighten (bool) lamp. dimmer ( extends lamp. queryable ) =========== v: level ( float, precent ) m:dimmer(in/out float level) lamp. rgb ( extends lamp. queryable ) ======== v:level{red, green, blue} (float, precent)x3