The exPL project extends xPL technology to embedded platforms without an IP stack. The xPL automation protocol is "... 'glue' to tie together home automation technologies." One of the underlying assumptions of xPL is that the protocol operates over an Ethernet network and relies on the broadcast behaviors specific to the IP and Ethernet stacks. The exPL project adds specifications to the xPL specification for resource constrained embedded systems that do not have an IP and Ethernet stack. The network layer specification defines a network independent message router which does not rely on an IP stack. In addition exPL will, over time, define various exPL MAC and Physical Layers needed to interwork the low speed networks common to resource constrained embedded systems.

IMPORTANT: This specification is not intended for IP network based equipment, except as a low speed gateway. If an embedded platform has enough resources to contain an IP stack then there is no reason to use the exPL architecture.

exPL Specification Page Links

• exPL Network Stack - Network stack concept and organization
• Application Layer - Application layer definition
  • LSG - Low Speed Gateway
• Network Layer - Network layer definition
• MAC Layer
• Physical Layer

• exPL Examples - Example message exchanges to illustrate the stack's function
• exPL Notes

Challenges for Low Speed Networks

There are a number of challenges that must be overcome to bring xPL to low speed networks that are not IP based. This section will cover these challenges while subsequent sections define an architecture that addresses each challenge.

Network Layer

The xPL specification assumes that devices communicate on an IP/Ethernet network. As such the xPL specification does not define the MAC/Data Link or Physical layer behaviors; IP/Ethernet is assumed. The gateway for low speed networks will need to define how exPL interworks with existing MAC and Phy layers of various low speed networks that replace the IP/Ethernet stacks. In addition some low speed networks do not fully specify a MAC layer (e.g. RS232) and/or Phy layer (RS485). For these networks the exPL specification should define these layers.

IP/Ethernet Broadcast

The existing xPL Hub and xPL application specifications rely on the broadcast functionality of an IP/Ethernet stack even for communication between applications on the same device. If more than one application runs on an embedded device without an IP stack, a message router, similar to an xPL Hub but different, is required to route xPL messages to each application.

xPL Gateway Definition

The xPL specification does not define the functionality of a gateway. There are existing gateway implementations for connecting separate IP broadcast domains, however the low speed nature of exPL will likely have filtering requirements not desired when connecting relatively high speed IP networks.

Network Bandwidth

xPL is a broadcast, ASCII encoded protocol that will tax a low speed network and resource constrained devices that are the target of exPL. Some method will be needed to filter the messages from the xPL domain in the gateway. It may also be necessary to compress the ASCII encoding by either truncating or out right converting to integer enumerations. Care must be taken when defining any type of filtering since the xPL specification assumes all nodes hear every message. Compression should only be considered after determining that the target low speed networks and resource constrained devices can not support the xPL defined messages. Compression would be a major departure from all existing xPL implementations and should only be used as a last resort.

Architectural Departures

exPL has a number of architectural differences from the architecture specified by xPL. The primary goal is to change as little as possible while accommodating the non-IP, low speed networks, and resource constrained devices which are the target of exPL. If the changes can be be successfully isolated to the network layer then the xPL application layer will function without modifications or constraints as xPL messages traverse both IP/Ethernet and other low speed networks.

Filtering

exPL encourages xPL message filtering for messages sent toward a low speed network. By default the Low Speed Gateway will filer all messages toward the low speed network unless the message target is used by a device on the low speed network. The Low Speed Gateway can be configured with permit rules that over ride the default behavior. For instance xPL broadcasts for certain schemas can be permitted through if desired. Filtering broadcasts has implications that limit the uses for a low speed network. Care should be exercised when deciding what type of xPL functionality is deployed on a low speed network. The intent of this specification is that low speed networks will support sensors and actuators; however simple, embedded controllers (e.g. thermostat or sprinkler) are also a reasonable target. The primary result of filtering is that devices on the exPL network do not hear xPL broadcasts from other exPL devices or from xPL devices.

Role of the hub

The exPL hub specification requires that exPL clients transmit "through" the hub. The hub is involved in both reception and transmission of xPL messages.

Network Layer

The exPL network layer is the most dramatic departure from the xPL specification. This is required because most low speed network layers do not have a notion of broadcast. Even where broadcasts can be simulated or are directly supported, the network layer behaviors are radically different from each other and from those of IP/Ethernet. One approach could have been to force each low speed layer to simulate the behavior of IP/Ethernet; however this would lead to resource wasting, unnatural behaviors for some types of low speed networks.

xPL intertwines the IP/Ethernet network transport in the specification while exPL does not assume any particular network transport. In xPL the network layer specification is split between the applications, which transmit directly to the xPL UDP port, and the Hub which listens on the xPL UDP port rebroadcasting to the applications. The exPL network layer specification explicitly replaces this behavior and eliminates the use of broadcast transmissions.

The exPL architecture defines the device level message routing in the network layer and redefines the IP/Ethernet based broadcast behavior so that all exPL networks are accessed through an exPL low speed gateway (eLSG) on each device.

Reference Diagram

Generic xPL / exPL Process Types

Workstation Based Process Types

• Hub (xPL Hub): xPL hub process as defined in xPL
• xApp (xPL Application): xPL application process as defined in xPL
• xDO (xPL Device Object): Process that manages configuration and status objects for the device. This application behaves like any standard xPL application but provides a well defined interface to the workstation or server system. The xDO does not manage configuration or status for any xPL applications or Hub; these instances continue to manage their own configuration and status as defined in the xPL specification. There is no current definition for this application. It is a mirror to exDO which has a more easily defined purpose. This process type is left as a placeholder should it be needed in support of the exPL architecture.
• LSG (xPL Low Speed Gateway): The LSG process is responsible for interworking between the xPL high speed IP network domain and the exPL low speed network domain. This application is responsible for solving most of the problems when interworking xPL to a low speed network with resource constrained devices. The LSG is the ideal place to perform complex, CPU intensive, and memory intensive functions like filtering and device learning since the LSG runs on a workstation, server, or relatively high end embedded device. The LSG behaves like a standard application layer process in both the xPL and exPL specification.

Embedded Process Types

• eApp (exPL Application): The eApp process is analogous to a standard xPL application. The only major difference in behavior is that eApps do not directly access the network layer as is the case for xPL applications. Rather the eApp will use the local xPL Network Layer implementation for both sending and receiving xPL messages. Otherwise the same schema definitions, heartbeat behavior, and configuration behavior apply to the eApp.
• exDO (exPL Device Object): The exDO is a standard eApp which specifically maintains configuration and status objects for the device. These include power status, device name, device location, device capabilities, remote code update capabilities, etc. The exDO does not manage configuration or status for any exPL applications, exPL Hub, or eLSG instances. Those instances manage their own configuration and status just like other xPL applications.
• eLSG (exPL Low Speed Gateway): The eLSG process forms the network layer of an exPL device. The eLSG is a logical grouping of a specific combination of exPL MAC Layer, Physical Layer, with the exPL Network Layer. Each eLSG instance is responsible for managing all aspects of the network, MAC, and physical layers. Some examples of exPL low speed networks are serial (SPI, TTL, RS232, or USB/serial emulation), multi-drop RS485, and Zigbee.
• eHub (exPL Hub): The eHub process is an xPL message router which receives and retransmits xPL messages to all applications on the same device. The eHub "is" the exPL Network Layer and is defined in that section. This hub is different from a standard xPL Hub because it replaces the broadcast behavior of the IP/Ethernet network stack that is assumed in the xPL specification. One major difference is that the eHub is involved in both reception and transmission of the xPL messages where an xPL hub is only involved in reception. The other major departure is that the exPL architecture does not assume any type of communications network. As such every exPL network interface is, by design, a gateway. With this assumption the eHub is not tied to the network layer as is the case with the xPL Hub specification.