Keywords

1 Introduction

A Cyber-Physical System (CPS) integrates a physical mechanism with a computer-based control and monitoring system. Usually, it contains feedback loops in which the physical processes affect embedded computer systems and vice versa [11]. Being tightly integrated with physical processes, a CPS is not always predictable and does not necessarily operate in a controlled environment [25]. Therefore, it needs to respond and adapt quickly to changes during operation, such as hardware and software defects, changes in resource use efficiency and surrounding environments, unexpected conditions, and non-continual feature usage.

This concern is particularly important for mobile Cyber-Physical Systems (mCPS), in which a unit moves freely in its environment and may cooperate with other units, e.g., in mobile robotics and smart vehicles [37]. The mCPS essentially run in highly dynamic environments (e.g., coordination of autonomous vehicles). In consequence, they need to adapt their behavior in a collaborative manner at runtime. The kind of adaption that mCPS software systems may perform can be the dynamic allocation of resources [22], content adaptation [26] (e.g., multimedia content), or the adaptation of the structure and functionality of software, to name the most significant ones. Among these, dynamic and autonomous adaptation of mCPS software is considered the most difficult aspect to implement. It involves the deployment of software modules and reconfiguration of networks and software architectures at runtime, as well as the adaptation of mCPS control software parameters (e.g., the speed of a unit) [14].

To coordinate a bunch of mCPS units and adapt them to a varying environment in a timely manner, we need efficient context reasoning solutions that guide the reconfigurations carried out in the various devices. The control systems of the involved mCPS have to consider numerous spatial and temporal contextual conditions (e.g., humans in the vicinity). This and the potentially large number of cooperating units makes context processing and self-adaptation of mCPS software a non-trivial design problem for which traditional device-centric adaptation approaches are hardly suited [36].

The challenge to create adaptable mCPS software systems has received growing attention by the research community. Existing work addressed this challenge within specific application domains, e.g., robotics and smart automotive systems [14]. Most proposed solutions are either devoted to low-level reconfiguration issues for adaptation (e.g., component-based frameworks [12]) or focus on specifying the CPS adaptable behavior through high-level language abstractions, such as Domain-Specific Languages (DSL) [33, 34]. However, the state-of-the-art has not sufficiently addressed the aforementioned complexity issues in modeling and developing adaptive mCPS.

We propose a self-adaptation service framework for mCPS addressing the complexity in modeling and adapting to highly dynamic location and time aspects of cooperative mCPS, called Virtual Adaptation Services Framework (VASF). In contrast to device-oriented approaches, it allows us to define adaptation requirements for a whole system of cooperating mCPS units, while adhering to the principles of the MAPE-K adaptation loop [9]. In particular, we can model spatiotemporal system properties using a set of rules that relate contextual aspects to reconfiguration and other change tasks. VASF uses the tool-set BeSpaceD [4] to reason about which rules to apply in a certain context. The result of this analysis is a number of adaptation actions that are automatically executed at the involved mCPS units. The provision of a rule-based reference context model eases the modeling of simultaneous and complicated contextual conditions, while the automatic runtime operation of VASF facilitates software reconfigurations on cooperating mCPS devices. We demonstrate the framework implementation on DiddyBorg robots [30] operated by Raspberry Pi boards.

The rest of this paper is organized as follows: In Sect. 2, we introduce a motivating scenario followed by the proposed adaptation framework in Sect. 3. We present related work in Sect. 4 and conclude in Sect. 5.

2 Motivating Scenario

Autonomous mobile robots are getting popular in various application domains ranging from healthcare to warehousing and transport (e.g., autonomously operating cars and stellar rovers). Like mCPS in general, the robots operate collaboratively in varying physical environments that may have different contextual properties. For instance, transport robots can face changing indoor and outdoor environments ranging from sterile “highways” in which they are protected from conflicting obstacles to areas crowded by humans, stationary barriers, and other robots which may be on conflicting courses. The differing environments aggravate the construction of a correct and timely working control software since, for example, the sensors to be used need to change constantly. In the following, we list some typical contextual environment properties:

  • Surface: The state of the surface, a mobile robot operates on, may effect relevant control parameters (e.g., braking distances are larger on wet surfaces than on dry ones). Further, the surface may influence the sensors to be used since, for instance, some sensors tend to provide wrong readings when the robot movement is bumpy.

  • Network access: Larger distances and obstacles may impede the communication between robots operating in the same area which, e.g., may lead to a delayed reaction when two robots are on a conflicting course (see [18]).

  • Self-localization: For many tasks, it is important for a robot to know where it is (see, e.g., [24]). The way to find the current position, however, depends on various aspects (for example, GPS can only be used outdoors; for triangulation, a number of beacons have to be located at the right spots).

  • Coordination and collision prevention: For the control, it is relevant whether a robot operates alone in a sterile environment or if it has to coordinate with other robots. A relevant use case is, of course, the protection of humans that may be severely hurt when colliding with a robot.

  • Energy consumption: Many robots are run by batteries, and for a sustainable operation it is often relevant to keep energy consumption as low as possible. For instance, it may be useful to switch off sensors at the side and the back of a robot if it operates straight ahead for a while.

When a robot moves between locations for which the above mentioned contextual properties differ, it has to adapt its control software. If, moreover, several robots collaborate, the adaptations may embrace the control systems of all of them.

Fig. 1.
figure 1

(a) A DiddyBorg robot and (b) its testing environment

Full size image

Our testbed consists of DiddyBorg robots [30], see Fig. 1. That are affordable and easily manageable demonstrators, each consisting of six motors that are controlled by a Raspberry Pi. To use DiddyBorg robots in practice, we provided them with sensors in order to enable self-localization and to avoid collisions with fixed and moving obstacles. In our current arrangement, we test the use of infrared and ultrasound sensors combined with an accelerometer and a magnetic sensor determining the direction of the robot. Moreover, the robots are provided with sensors for temperature and air pressure which enables us to adapt their behavior in, e.g., icy conditions. Infrared sensors are suitable for very close distances until 80  cm. They fit nicely to the ultrasound sensors which cannot render precise measures to obstacles closer than 60 cm but provide good distance sensing of more distant objects of up to about 5 m. Using all these sensors, we have to prevent straining the batteries of a DiddyBorg robot. Its motors are operated by 10 AA cells connected in series while we use a rechargeable 5V battery to drive the Raspberry Pi and the sensors. We consider the following dynamic adaptations beneficial:

  • To save energy, it seems sensible not to use all sensors at once but to start and stop them according to the environment, the robot operates in, and to adapt the control software accordingly.

  • Typical controller parameters like maximum speed and protective braking distances shall be adjusted depending on the physical location and other properties of the environment. For instance, when the robot operates in a long and empty corridor, and the ultrasound sensor detects no obstacle within three meters, the robot can operate with full speed. When enclosing an obstacle, the speed may be reduced depending on the distance to the obstacle.

  • We also consider special constructional features which might affect the quality of the sensor readings (e.g., we found out that the heating pipes in one of our labs falsify the readings of the ultrasound sensors which render wildly shaking values when the pipes are approached).

  • Temporary conditions in an environment can occur, e.g., due to spills or accidents, that afford extra caution or to avoid an area entirely.

Our VASF-based solution introduced below, shall address these adaptation types.

3 Adaptation Framework

The main goal of VASF is to provide a unified abstraction for adaptation in mCPS in order to reduce the complexity of modeling spatiotemporal-related contextual changes of the control software of mCPS. In particular, it allows us to express the contextual aspects of a mCPS that may consist of various cooperating units, with a set of easily understandable rules. Each rule allows the user to relate contextual information to context change tasks. Based on sensor inputs and other existing context data, a context reasoning system driven by BeSpaceD [4] analyzes the rules and sorts out potential conflicts between them. The result of the analysis is a set of reconfigurations that VASF automatically forwards to the involved units. They may vary from basic parameter-based software reconfiguration (e.g., switching from one localization sensor type to another type) to software service-level changes (e.g., replacement of a energy-draining localization software service with a less powerful but more energy-efficient one).

Figure 2 illustrates the main design elements of VASF. That includes: (i) the context modeling space which represents the mCPS operation environment; (ii) the software framework which resides on the software system of mCPS devices and offers the context monitoring and processing, and reconfiguration functionality. Reconfiguration is performed through services relying on the Java-based OSGi framework [28]. From the developer’s viewpoint, VASF provides a unified virtualized view to the mCPS-level adaptation needs which will be further detailed for each mCPS device. The different design aspects of VASF are introduced below.

Fig. 2.
figure 2

Overview of our virtualization-based approach for self-adaptation in mCPS

Full size image

3.1 Spatiotemporal Context Modeling and Reasoning

For context modeling and reasoning, we propose the use of our BeSpaceD language and tool [4] for spatiotemporal modeling and reasoning. Spatiotemporal models provide a formal view of the context modeling space that robots are operating in. Such models can include geometric information like obstacles, regions with specific operating conditions as well as topological information such as interconnection information between different regions that do not depend on a specific geometry. Temporal aspects are used to describe the change of geometry and topology over time, and the appearance and disappearance of structures and other robots. Furthermore, BeSpaceD formalizes conditions under which a change may occur.

BeSpaceD is implemented in Scala and its core functionality runs in a Java environment. It has been successfully applied in different contexts such as decision support for factory automation [3] and for verification of spatiotemporal properties of industrial robots [19]. Besides of basic logical operators (e.g., AND), BeSpaceD offers special constructs for space, time, and topology. For instance, OccupyBox refers to a rectangular two-dimensional space parameterized by its left lower and its right upper corner points while constructs like TimeInterval make the modeling of temporal aspects possible. For example, the following formula expresses that the rectangular space with the corner points (1050, 2056) and (1502, 2603) will be temporary closed between the time points 200 and 600:

figure a

BeSpaceD formulas can be efficiently analyzed for spatiotemporal and other properties. For instance, we can specify a point of time and a predicate and derive the spatial implications from these definitions. Likewise, logical quantifiers can be applied to specify and check the existence of a spatiotemporal condition in a specification, or to prove that a certain property holds for a distinct time and space area. In addition, algorithms and tools such as external SMT solvers (e.g., we have a connection to z3 [8]) can help to resolve geometric constraints such as the overlapping of different areas in time and space. A variety of different operators (for instance, breaking geometric constraints on areas down to geometric constraints on points) exist which facilitates the reasoning about geometric and topological constraints.

We decided to utilize BeSpaceD for reasoning about the context rules since it addresses their spatiotemporal nature well. The BeSpaceD language is used to specify the rules while the efficient automatic analysis of BeSpaceD makes it suitable to find out which rules have to be triggered in a certain context. Moreover, the expressibility of BeSpaceD allows us to define prioritization schemes in order to find out which of two or more contradicting rules to prefer.

3.2 Software Reconfiguration

The control software of an mCPS unit shall support runtime changes in the configuration parameters as well as in the software structure, e.g., through software component replacement. In addition, the mCPS software has to support plugability of context data provider components. Such general-purpose components are dynamically loaded and unloaded from the mCPS device, providing contextual information such as sensor data.

The software reconfiguration mechanism is built on the Java-based OSGi (formerly known as Open Service Gateway initiative) platform [28]. We chose this framework as resource-efficiency has been one of the core design goals of OSGi and therefore it does not impose high resource overhead on mCPS devices. Some existing implementations, such as Concierge [32], exhibit a reasonable memory footprint for resource-constraint devices (80 kB). Our testbed, the Raspberry Pi node used to control a DiddyBorg, can host the Eclipse OSGi framework, called Equinox [10]. OSGi offers a class-loading mechanism to dynamically load and unload Java packages, so-called business bundles that, in our context, may implement a service like listening to a sensor or controlling an activator. For that, OSGi offers functions to activate, deactivate, and replace a business bundle. In particular, it preserves automatically the dependencies of a system when some of its bundles are installed, uninstalled or reconfigured.

Fig. 3.
figure 3

Architecture of virtualization-based adaptation using the OSGi framework

Full size image

Figure 3 shows the architecture of VASF. The core idea of the proposed architecture is to provide a virtualization layer supporting access to the collaborating units. Thus, it allows abstract services like Context Monitoring to interact with one or more actual services on selected devices in order to perform part of an adaptation process, e.g., loading a bundle on devices.

Service properties are the main source of information for determining the filtering, i.e., which data to consider. They enable the association of additional metadata with services, in addition to the service name. We propose two types of properties for services in order to achieve adaptation: (i) generic properties that describe the functionally of a service, e.g., localization.ultrasound; (ii) properties describing the non-functional aspects of services, e.g., accuracy.distance.high or energy.low. For example, if the functional property for filtering is decided to be localization.shortrange, another level of filtering can be performed by including the non-functional property energy.low in order to select a short range localization service that demands less energy. If there is more than one bundle implementing a service, the service.ranking property, a standard OSGi property, is defined for such services in order to select a single service with the highest ranking.

VASF can either be implemented and deployed on a network node (e.g., a gateway) or reside on an mCPS unit that is powerful enough to perform the context processing and communicate with other devices for performing the adaptation actions. In the latter case, we need a leader selection protocol (see, e.g., [29]) to compensate for the failure of the leading unit. The key component of VASF, Virtualization Support, handles the communications between VASF and the mCPS units, in our case, the Raspberry Pi devices. The WiFi capability of devices along with the socket-based data transmission between the VASF device and robots will be used, e.g., to perform service tracking and load remote bundles.

Adaptation Manager receives the current system context retrieved by the Context Monitoring service from the corresponding actual services on the units. Adaptation Manager forwards the context space information to Spatiotemporal Analyzer, running the BeSpaced-based analysis. Based on its results, Spatiotemporal Analyzer selects the OSGi mechanism to execute, as well as the new property settings and notifies Service Tracker. This service is used to detect services of a specific type, e.g., sending notifications when a service is started or stopped. Its instance at the VASF level is in charge of communicating with the equivalent services on selected mCPS devices to perform service tracking. Thanks to OSGi, we can build our own Service Tracker based on OSGi’s service tracking component. Specifically, when Spatiotemporal Analyzer suggests a new service for update, Service Tracker will perform investigations regarding the current status of the old service and ensure that other bundles using this service can continue their execution safely during reconfiguration.

After the new service is located by Spatiotemporal Analyzer and Service Tracker, Adaptation Manager will initiate the service reconfiguration phase using the dynamic service reconfiguration feature of OSGi. If no service with the specified filtering criteria is found, Adaptation Manager invokes RemoteBundle Loader to download the bundle that implements the requested service and load it to the OSGi runtime system. This service is also used to load Context Bundles (see Fig. 2) that are dynamically added to the system in order to collect new context information based on the available sensors of the robot. Like Service Tracker, Service Reconfiguration on VASF communicates with the actual equivalent services on selected mCPS devices to perform the configuration process.

3.3 Combining Context Reasoning and Software Reconfiguration

The business bundles in our DiddyBorg testbed comprise functionality like path planning, the control of the six engines, reading the various sensors, and special tasks necessary in a certain environment (e.g., a detector for unstable sensor readings close to heating pipes). Depending on the reconfigurations selected in the current context, bundles may change in one or more robots. For example, in the case of an area temporarily closed for an mCPS, a new path planning algorithm may be loaded and replace the previous one. Furthermore, once BeSpaceD identifies the approach of an uncritical area, we may temporarily unload bundles that control some sensing devices if these are not needed for the uncritical area. This can result in energy savings.

Table 1. Context change rules for the test bed
Full size table

To clarify our approach, we list in Table 1 a set of rulesFootnote 1 guiding context reasoning and software reconfiguration for our DiddyBorg robot testbed. The rules depend on the current robot location and other contextual aspects like sensor readings, input from collaborating units, time properties, or reports about other robots being in the same room. They are described as BeSpaceD formulas and guide the context reasoning. The results of a rule may be software reconfigurations and other changes, e.g., the adjustment of control parameters. For instance, rule 5 defines that if the robot is in room B216 and the magnetic sensor detects that it heads towards the heating pipes which may effect the reading of the ultrasound sensor, an OSGi-bundle containing a detector function is added which constantly checks the readings of the ultrasound sensor. If the detector finds out that the readings get unstable, i.e., start to jump ferociously, this is an indication that the robot approaches the heating pipes. In this case, following rule 6, the control parameter determining the robot speed is changed such that the speed is reduced to 25% preventing the robot crashing against the pipes.

As discussed above, rules may be contradictory. For instance, rule 1 demands to switch off the infrared sensor saving energy when the robot is operated in one of the hallways and the ultrasound sensor does not detect any obstacles within 3 m. In contrast, according to rule 8 the infrared sensor has to be kept operating between 00 and 15 of the hour since then there is a break between lectures and many people are expected in the hallways. Thus, the likelihood of somebody encountering the robot from the side leaving a room is significantly higher and the infrared sensor may provide a better reading of the exact distance. The context reasoning shall, of course, guarantee the safest possible solution which, in our case, means prioritizing rule 8 keeping the infrared sensor on. Using its prioritization scheme which, for instance, may determine that a sensor has to be active if desired by one of the contradicting rules, BeSpaceD decides that rule 8 will be applied and not rule 1.

The Diddyborg demonstrator is currently under development, thereby we cannot provide reliable measures on the time needed for the various adaptations of the control systems of the robots. First tests of OSGi on a Raspberry Pi, however, give the impression that the typical OSGi reconfiguration functions like starting or changing business bundles are quite resource-efficient, expecting no major performance penalties of our approach. Of course, that has to be analyzed more in-depth when the full demonstrator is running. Likewise, we have to determine the impact of the BeSpaceD-based analysis on the overall performance. As discussed in [21], BeSpaceD proved to run efficiently for similar approaches such that we do not expect a serious penalty here either.

4 Related Work

Self-adaptation of CPS software systems has received great attention because of their inherent unpredictability and high dynamicity. In the following, we discuss the related work with respect to context modeling techniques for mCPS and the solutions for enabling self-adaptation of mCPS software system.

Spatiotemporal specifications and means to reason about them, are an important part of our work. A variety of different specification mechanisms such as a process algebra-like formalism and a related type system for concurrency and resource control exists [6]. In the SPEEDS project [2, 17], contracts between components are used to model behavior in the form of transition systems. Means to reason about spatial and geometric constraints are described in, e.g., [1, 20]. Additional logic approaches for hybrid systems (e.g., [13, 31]) provide comprehensive languages and tools for describing CPS including time and space. In contrast to these works, our system combines the Java basis of the OSGi context with spatiotemporal reasoning at runtime that can take place on the robot controller to support runtime adaptivity of CPS.

Other work addresses the large amount of information available for context processing [7, 23]. This also includes the diversity of application variants for software reconfiguration [5, 27]. However, the view to diversity in these types of approaches is different from what we envisage for mCPS applications, i.e., growing and diverse spatiotemporal contextual changes. Another aspect of context processing is to address uncertainty in adaptation. In [15, 16], meta-adaptation strategies are proposed that extend the adaptability of a system by constructing new tactics at runtime reflecting the changes in the environment.

With respect to dynamic software adaptation models for CPS, a framework for mapping the large component model Kevoree into micro controller-based architectures is discussed in [12]. The main goal of this work is to push dynamics and elasticity concerns directly into resource-constrained devices, based on the notion of models@runtime. The proposed dynamic component model is benchmarked against certain key criteria such as memory usage and reliability, on an Arduino board with an ATMEL AVR 328P microcontroller. The main focus of this work is on efficient development of dynamic components for resource-constrained CPS, which is different from the goal of this paper, i.e., modeling contextual aspects in a scalable manner and adopting a service-based view to adaptation instead of the device-level view. In [33], an approach is proposed for the development of adaptable software applications for embedded systems based on a Domain-Specific Language (DSL). The authors chose DSL-based adaptation to specify adaptation policies and strategies at a high-level, using rules that produce the necessary runtime reconfigurations independent from the application logic. In particular, they develop the adaptation framework of a Lego NXT Mindstorms robot exploring the environment. Similarly, PLASMA [35] and Sykes [34] utilize ADL and planning-as-model-checking technologies to enable dynamic replanning in the architectural domain in robots. The focus of these works is on specifying the adaptable behavior through DSL, while our work is characterized by a high-level service-oriented abstraction model, which is domain-independent and simplifies adaptation modeling and implementation in typical mCPS.

5 Conclusions and Future Work

Enabling efficient dynamic software adaptation is a key requirement of mCPS with respect to their high dynamicity and spatiotemporal contextual changes. The main goal of the framework, presented in this paper, is to facilitate the adaptation of mCPS software, referring to the support of complicated contextual changes in the spatiotemporal aspects of mCPS. Further, our approach supports the collaborative nature of mCPS for which we need an application- and high-level view to adapting the whole mCPS, rather than individual devices. We achieve this by introducing a new software architectural model, which is based on the idea of virtualizing the adaptation services at the application level through a Virtulization Services Adaptation Framework (VASF) and then interpreting the process to actual low-level adaptation actions performed on selected devices. We use BeSpaceD for modeling and reasoning, while the framework components and the self-configuration model are demonstrated for the DiddyBorg robots with Raspberry Pi boards using OSGi. As our future plan, we will develop a generic version of VASF and use it in a variety of mCPS environments. As an demonstrator, we will apply the adaptation framework to a bottling plant deployed in the RMIT’s advanced manufacturing precinct. In addition, as an adaptation solution for CPS, we plan to study the reliability of VASF when faults occur during the service reconfiguration.