Context-aware adaptation in IoT-based systems

Analysts predict the emergence of as many as 26 billion connected devices by 2020. The unprecedented scale, mobility and heterogeneity of IoT-based systems is mandating a fundamental change in the way they operate. It is our belief that to be sustainable and cost-effective, these systems must be autonomous and automatically adapt to dynamic changes in context, while ensuring that the IoT-based system delivers on user requirements.

In our ongoing work at Ericsson Research, we have demonstrated context-aware adaptation through a middleware called InteropAdapt. It is designed on the basis that the device capabilities can be exposed as microservices, and configured and composed to deliver different application level functionalities on demand. The dynamic reconfiguration and recomposition are provided by the core engine of InteropAdapt which is built upon the AI (Artificial Intelligence) planning technology.

InteropAdapt: Adaptive middleware

Below you will get a high level overview of the core functionality of InteropAdapt. It needs the application level APIs (commands) and the low-level device actions (capabilities) to be specified formally through pre- and post-conditions over a set of predicates using a common vocabulary (ontology). It then uses AI planning techniques to derive workflows over the capabilities corresponding to the application commands. The generation method considers the contextual constraints and/or policies as additional constraints to be satisfied by the workflows. Whenever there is a change in the context, InteropAdapt transparently generates new workflows to adapt to the new context.

Application commands, device capabilities and capability workflows.

Application commands, device capabilities and capability workflows.

The full architecture of InteropAdapt is based on the MAPE-K (Monitor, Plan, Analyze, Execute with Knowledge) paradigm from autonomic computing. Monitor detects the events of contextual change, such as workflow execution status, mobility related changes, changes in device state and environment, etc. Analysis checks if these events require changes to the existing workflows and/or generation of new workflows. Execution is responsible for orchestrating the new/changed workflow execution. Finally, Knowledge stores both static knowledge about the context and the knowledge acquired during execution and dynamic events.

ImageIntegration of InteropAdapt in an IoT-based system for Building Automation.

ImageIntegration of InteropAdapt in an IoT-based system for Building Automation.

Prototype and results

Our prototype implementation of InteropAdapt is integrated with an IoT-based system for the Building Automation domain. Here, the local management services (LMS) expose the state and capabilities of the IoT devices. InteropAdapt mediates between the commands from the global management service (GMS) and LMS, generating workflows dynamically based on contextual change. The scenarios described in the following illustrate the context-aware adaptability of the IoT system extended with InteropAdapt.

Consider the rooms in the building being equipped with water sprinklers and smoke detectors. The microservices corresponding to the smoke detectors provide a way to check the presence of smoke. The microservices corresponding to the water sprinklers allow one to control the spray of water. At the GMS level, a fire safety application specifies the intention of the manager that the sprinklers should start spraying when smoke is detected in a room. In the simplest scenario, the workflow corresponding to the command douseFire(roomX) is a simple one, namely, [switchOn(sprinkler, roomX)].

Suppose that for additional safety during summer, the manager intends to switch on the sprinklers in adjacent rooms as well. A state-of-the-art system would require programming of this situation into the application. However, with InteropAdapt, this can be stated in a declarative fashion and be construed as either a temporary change in requirements or a general change in the management policy. Taking the new policy as a contextual change, the new workflow generated for douseFire(roomX) is [switchOn(sprinkler, roomX), switchOn(sprinkler, roomY), switchOn(sprinkler, roomZ)] where roomY and roomZ are adjacent to roomX, the information which is extracted from the floor distribution.

Consider another scenario where a server is moved into a room. InteropAdapt detects this change and extracts the policies with the server which would normally be registered with the discovery and registration services. One such policy states that in case of fire the server should be switched off before turning the sprinkler on. Considering all such scenarios and programming them in the application is labor-intensive and highly error-prone. However, manual intervention is completely avoided through InteropAdapt, which produces a new workflow on-the-fly, namely, [switchOff(serverP), switchOn(sprinkler, roomX)] where location(serverP) is roomX, which complies with the policies.

The small but illustrative example scenarios above give an inkling of the intelligence in InteropAdapt, which uses autonomic computing techniques to enable contextual sensing and actuation. While the prototype works in a centralized fashion, we are working on distributed planning algorithms to scale up our prototype to large real-life use cases.

The Ericsson blog

In a world that is increasingly complex, we are on a quest for easy. At the Ericsson blog, we provide insight, news and opinion to help make complex ideas on technology, business and innovation simple. If you want to hear from us directly, please head over to our contact page.

Contact us