WuKong Middleware for LCPS and M2M
The Missing Blocks for Large Scale Cyber-Physical and M2M Systems
Many applications in large scale cyber-physical systems (LCPS) and machine-to-machine (M2M) start with single purpose systems designed for homogeneous sensor platforms using specific network protocols. The hardware has a fixed set of sensors, and the applications cannot be easily ported to other platforms. The separation of design abstractions between the low-level hardware and high-level applications has not been as successful in these systems as that for server-based systems, not to mention making them dynamically adaptable and evolvable to new services, and new environments. Except for low level building blocks, there is very little reuse from one project to another.
It is clear that there is a need for better middleware support to ease the deployment of machine-to-machine (M2M) applications (Mottola & Picco, 2011). One missing block is a flexible middleware support so that developers and users of an LCPS/M2M system do not need to be constrained by which and how sensors have been deployed in a target environment. The built-in intelligence from the middleware can dynamically perform sensor detection, device selection, system configuration, software deployment, and system reconfiguration.
Like the transition from low-level coding to high-level programming on top of of a general purpose OS and an optimizing compiler, we would like to make LCPS/M2M programming as platform independent as possible using simple, high-level primitives instead of the node-centric programming. Another missing block is the intelligent mapping from a high-level flow based program (FBP) to self-identified, context-specific sensors in a target environment. The automatic mapping capability in the middleware allows an application developer to specify simply what types of sensors are needed rather than which sensors are used. Such a flexibility is important in order for the same application logic to be adopted by different users at their individual homes or offices with a dynamic, evolving set of heterogeneous sensors.
WuKong – Intelligent Middleware and FBP developing framework for LCPS and M2M
WuKong framework consists of two major components to fill the gap caused by the two aforementioned missing blocks: intelligent middleware and flow-based developing framework. WuKong middleware is regarded as a Virtual Middleware (VMW). The reasons for this are twofold. First, as sensor networks become more wide-spread, it is increasingly likely that applications will want to take advantage of different types of sensors available in a given area. Having a virtual sensor will allow applications to run on heterogeneous networks of sensors. Second, when the system decides to reconfigure the network, the process of reprogramming nodes will be easier using a virtual machine design so that code updates can be smaller since the virtual sensor can offer higher level primitives specific for LCPS/M2M applications. On top of WuKong middleware, WuKong framework can postpone binding logical components with physical devices until an application is deployed, rather than when an application is developed. With the intelligent middleware and FBP, WuKong framework enables intelligent binding for LCPS and M2M systems.
The grand vision for WuKong project is that future LCPS should have “zero-cost” deployment where users of an LCPS application do not need to be concerned on how and where to deploy sensors. The built-in intelligence from the proposed LCPS support can automatically perform the optimal sensor node configuration, bandwidth allocation, fault management, and re-configuration in response to new missions and new device deployment. Much like the past transition from low-level assembly codes to high-level programming using general purpose OS and compiler support, LCPS programming may be as platform-independent as possible while keep only the most essential system primitives to allow automatic performance optimization.
The lifecycle of a LCPS and M2M systems has no ends and is a loop. It starts with the process of device discovery, continues with device identification, user need definition, service composition, service deployment, and service/device update. After a service/device is updated, the process of device discovery repeats. The middleware for LCPS and M2M take into account and support the lifecycle of such application scenario. In WuKong middleware, we develop a three orthogonal middleware frameworks to support this lifescycle:
1. Profile framework: to enable the handling of heterogeneous or new sensor nodes, and for high-level, logical abstraction of low-level, native sensor operations.
2. Policy framework: to allow user-friendly specification of application execution objective, and context-dependent optimization of LCPS/M2M performance.
3. Progression framework: to facilitate in-situ software upgrade for dynamically, progressive reconfiguration.
Roles of WuKong Components:
WuKong acts as a middleware to coordinate the services in system to accomplish the requests from users and applications. To coordinate the services, the services are classified into three roles:
Master: The most important task of WuKong Master is to configure, optimize, and reconfigure sensors. To do this, it communicates with sensors through a layer of abstraction, hiding hardware and network details of the underlying sensor platform. During the discovery and identification phase, Master uses the profile framework to discover the capabilities of connected sensors, and configure sensors’ parameters. WuKong master is also responsible for managing the user-defined services in the system including deploying the service to the devices, making in-situ decision for software upgrade and service remapping. In practice, WuKong master will be deployed on a computational power and robust device which is capable of reliably receiving user requests and managing the services.
Gateway: WuKong gateway has two major responsibilities: communication gateway and backup master. As a communication gateway, it has the capability of discovering devices, forwarding messages, and dispatching messages. In many use scenario, there may be several WuKong gateways, each of which uses different communication protocols to connect to the devices. As a backup master, it has the capability of replicating the state information and services on WuKong Master. When the WuKong Master is down or disconnected, the gateway can replace WuKong Master to manage the devices and services in the system.
WuDevices: WuKong devices, shorted as WuDevices, represent the networked physical devices in the system. One WuDevice can be a combination of sensors, actuators, and computation services. To be part of the WuKong systems, a WuDevice should register itself to WuKong master directly or via WuKong gateway, identify its own capability via its profiles, and join the system. The services including sensing, control, and computation carried out on WuDevices are deployed by WuKong master. WuKong master deploys the service in the form of interpretive commands, native code or Java byte code, depending on the capability of the WuDevices.
M2M applications are by definition distributed, and the difficulty of managing the communication between devices is one of the main obstacles in M2M development. Using FBP as a programming model allows the application programmer to focus on defining the abstract flow of information in the application, while the resulting FBP program will contain all necessary information to let the framework manage the low level details to physically implement this flow.
The developer constructs an application by selecting logical components from a library. Eventually, each component will be realized in practice by a physical sensor or computation services running on WuDeivces. The decision on how to realize the functionality described by the FBP components will be made by Master at the time of deployment, but not during FBP construction. Components in FBP expose their external interface through a set of properties. These can be connected using links to create the dataflow in the application. Only properties with matching data types can be connected in FBP. Below figure shows a simple example of FBP. In this application, it periodically senses the lighting level of a space. It turns on the light if the lighting level is less than a given threshold, represented by the numeric controller on the left. Otherwise, it will turn off the light to reduce energy consumption.
The components an FBP programmer can use to compose the application are defined in a component library in the WuKong framework. Currently, it includes only a basic set of components for commonly-used sensor hardware and functional elements. In addition to these predefined components, a programmer will be able to add custom components containing functions specific to the application if no support is present in the library.
Application similar to the one shown above is general enough to be deployed to billions of home and offices. WuKong framework will map the logic components to physical devices when an application is deployed based on the properties specified in FBP and device profiles collected at device discovery. Below figure shows the profile matching between logical and physical devices. Each application is compiled into app codes that are connecting or running on logical devices. On the other side of the middleware, physical devices with specific capability profiles are discovered and identified. The middleware must then match the capability of each logical device to that of some physical device. If there is a one-to-one match, the decision is easy. If there are more physical devices than logical devices of compatible capabilities, some of the physical devices will not be used. But if there are fewer physical devices than required logical devices, we will need to consider resource sharing. For example, two logical temperature sensors are needed to run the application this figure, yet only one physical temperature sensor is available. The system needs to use the single temperature sensor for feeding data into two logical sensors. Depending on the device usage from the application, we may need to use data sharing, data coercion, or even sensor time multiplexing to share physical sensors.
Development and Deployment Flow
WuKong framework provides an integrated development environment (IDE) for application development, device discovery, device identification, device set up, and service deployment. The IDE is a web-based interface and is executed on WuKong Master.
On WuKong IDE, the developers can use drag-and-drop user interface to compose FBP applications. WuKong has built number of WuClass components to provide arithmetic operations, value assignment, periodic data update, and uni-cast data link between components. After the application is completed, the WuKong IDE starts the process for mapping, and deployment. Below figure shows the workflow for application development and service deployment in WuKong framework.
The following figure first shows the interface for flow-based programming. Built-in components are shown on the left hand side of the programming interface. The developers drag the component of interests from the library to the programming canvas, shown on the right-hand side of the programming interface. To edit the property of the component, the programmer can click the selected component to edit the properties. Shown on the figure, the programmer can edit the location, fault tolerance policy, default properties, and monitors. In this example, there are four default properties: operator, threshold, value, and output.
When the FBP application is exported from WuKong IDE shown in a dashed rectangle on the right part of the above figure, the framework converts the application into a canonical WuKong XML format. The Master accepts the application defined in WuKong XML to deploy it in the network. It will generate a Java file that is compiled into bytecode, possibly including some virtual WuClasses from the library, and then wirelessly upload to the nodes.
The first step in the build process is to assign an ID to each of the components in the FBP. The Master can then generate most of the Java code for the application, except for a table mapping the components to physical nodes. The generated Java code consists of three major parts, two of which are independent of how the application is mapped to physical resources. First, there is a table describing the links between the components in the FBP. Second, some initialization code is generated for each component. This code is responsible for creating the instances of virtual WuClasses and setting parameters, such as the operator of the Threshold component in our example scenario.
The third part in the building process is a table that maps each WuObject to a particular node in the network. To create this table, the Master first starts the discovery phase and asks every node in the network for a list of its WuObject instances and supported WuClasses. The Master will then map each component in the program that represents hardware (the hard WuClasses) to an existing WuObject in the network. For each processing component (the soft WuClasses), the Master will look for nodes containing the corresponding WuClass. If no native WuClass is found, it will try to find the class in the Virtual WuClass library and include it in the application.
While finishing developing the application using FBP, the installer can use the same interface to deploy the designed applications. The following two figures show the the deployment process at WuKong IDE framework. The first one shows the discovery results of the system. This example shows that there is only one device, which has two WuClasses and one WuObjet installed on the device. Icon ‘Classes/Objects list” allows the installer to learn the list of WuClass/WuObject on the devices. The next step on deployment procedure is mapping. The second figure shows the results of mapping FBP application onto the discovered devices. In this example, all four WuObjects are mapping onto the same WuDevice, whose node id is 2. The port number show the port used for communication. In traditional embedded/WSN programming, the node ID and port number are specified either in the application or in a configuration file. This example shows that the node ID and port number are determined by WuKong Master during deployment, rather than development.
The last step of development process is to update the software including application, configuration, and virtual machine on the device. The last step is also conducted on the WuKong IDE framework. The following figure shows the logged results of deploying software component to the selected devices.
The mapping decision can have significant impact on the performance of the application. Developing intelligent mapping protocols will be an important focus in our work. For example, even in our simple light control scenario, it is clear that we would expect significantly more traffic between the light sensor and the threshold component, which will periodically receive an updated current light level, than between the threshold and the light actuator, which will only be triggered if the light level drops below or rises above the set threshold. Thus, the threshold component should be hosted as close to the temperature sensor as possible, preferably on the same node. WuKong has built-in intelligence to conduct the mapping from logical components to physical devices.