Chapter 5: A DevOps Toolchain for Managing Actuation Conflicts in Smart IoT Systems

To assist users in their daily lives, Smart IoT Systems (SIS) have long been limited to the exploitation of environmental information; the use of ‘smart objects’ was mainly motivated by their ability to collect these information from sensors. However, in many areas such as home automation, factory 4.0, Intelligent Transportation Systems (ITS), etc., SIS are no longer limited to collecting sensor data to infer actionable information, they also interact with the physical environment through actuators. This evolution brings new challenges that the scientific community has to meet in collaboration with industrial players, as evidenced by the numerous calls from the European Commission, in which the ENACT project is part of: “Most of the today’s IoT systems are however mainly focused on sensors, whereas in the future actuation and smart behaviour will be the key points. Platforms should provide connectivity and intelligence, actuation and control features” [9], p. 100.

By physically interacting with their environment through actuators, SIS become critical; in the absence of end-to-end human control (utopian in complex operational contexts such as ITS, etc.), they have immediate impacts on the physical environment with all the social and economical risks that this may entail. At designtime, these applications must be conceived to formally prevent any undesirable effect in the physical environment, whether caused by sending contradictory or simultaneous commands to the actuators. At run-time, it is yet necessary to ensure that the effects produced in the physical environment are in line with the expectations. Indeed, the lack of a perfect model of the physical environment (of a complex nature) prevents designers from fully predicting the effects of the commands sent to the actuators; effects that are therefore likely to be hampered by possibly disruptive surrounding physical processes. These challenges bring with them heightened concerns about trustworthiness of SIS which includes, among others, safety and reliability aspects. As defined in [13], safety concerns are related to the ability of SIS to prevent catastrophic consequences for humans and the physical environment; reliability concerns are related to the ability of SIS to deliver predictable performance in expected conditions. While the DevOps methodology is part of the good practices in software development and is applicable to SIS limited to merely collect sensor data, it requires new tools in the realm of trustworthy SIS, both at Dev and Ops Times.

While the DevOps approach is not specific to a particular field of applications, many challenges arise when it comes to applying it to the field of SIS. DevOps practices are therefore still far from being fully adopted in their development, notably due to a lack of key enabling tools [1, 34]. Among these key tools, those capable of taking into account SIS operating in open and complex environments and requiring continuous testing at run-time (i.e., in-situ) beyond the tests traditionally conducted on emulated and simulated infrastructures, are missing [1]. In general, there is a lack of tools that address the trustworthiness of SIS, which, as far as this chapter is concerned, is about safety and reliability aspects, exacerbated by the ability of SIS to act in the physical environment through actuators. A study of the literature around the actuation problem [19] shows that, without even considering the DevOps approach, this problem is still in its infancy in the IoT field and therefore still open. Moreover, the approaches proposed in the literature for managing actuation in SIS are often (1) monolithic, they do not or hardly meet the best practices advocated by the DevOps approach; (2) applied to controlled operational environments; they have a software vision of the problem by focusing on the commands sent to the actuators more than on the effects they produce [29].

The work carried out as part of the ENACT European project and described throughout this chapter aims to fill this gap by proposing a toolchain meant to be integrated into the DevOps framework and meeting end-to-end SIS actuation challenges.

The contribution is built around two complementary toolsets, deployed throughout the DevOps life-cycle phases. This combination of tools aims to improve the trustworthiness of SIS within a framework which, as advocated by the DevOps approach, creates synergies and foster communication between development and operations activities.

At design-time (Dev), a complete toolset is developed for identifying and locally resolving actuation conflicts [12], i.e., (a) preventing contradictory or simultaneous commands to be sent to actuators (direct conflicts), (b) preventing, as much as it can be, antagonistic effects to occur in the physical environment (indirect conflicts). At run-time (Ops), a first tool observes specific environmental features and quantitatively assesses the effectiveness of the SIS, i.e., for the extent to which it produces the expected effects. A second tool is meant to analyse drifts in effectiveness. It makes clear the symptoms of the drifts in effectiveness, providing guidance to designers to help them investigate their possible root causes. Within the framework of the ENACT project, other investigation tools may be used to complement this latter tool, such as, for instance, the Root Cause Analysis (RCA) (Section 8.3) toolset. The analysis resulting from these tools then trigger a new design phase, closing the DevOps life-cycle loop.

The rest of the chapter is organized as follows. Section 5.2 describes the SIS actuation management toolset along with the workflow (Section 5.2.2) involved in the identification and resolution of direct and indirect actuation conflicts. Section 5.3 describes the behavioural drift assessment (Section 5.3.2) and analysis (Section 5.3.3) toolset. Section 5.4 demonstrates, throughout a smart-home use-case described in Section 5.4.1, the complementarity and relevancy of both toolset as part of the DevOps life-cycle. This use-case involves two consecutive DevOps cycles to converge towards a SIS with satisfactory behaviour.

IoT devices, at the edge of SIS infrastructures, have long been leveraged for their capacity at gathering environmental data from sensors, paving the way for decision making support systems covering a broad range of application domains from smart-health, smart-city to smart-grid, Factory 4.0, etc. just to name a few. However, beyond merely gathering data from sensors, new challenges arise as soon as it comes to leverage IoT devices to interact with the physical environment through actuators that turn commands received from SIS into physical effects. One of these challenges concerns the actuation conflict management. Such conflicts are likely to occur when different applications compete for accessing (1) shared actuators at the edge of the IoT infrastructure (direct conflicts), e.g., simultaneously applying ON and OFF to a light bulb, and/or (2) shared physical properties (indirect conflicts), i.e., turning ON both a cooler and a heater in the same room.

The actuation conflict management challenge goes beyond the technological challenge that shared multi-layered IoT infrastructures usually meet by, for instance, providing sensors with access control mechanisms. Indeed, besides this technological challenge, actuation conflict management also poses a semantical challenge; accounting for the locality of the actuators and the physical properties they act on is here essential. In the realm of trustworthy SIS, actuation conflict management is of paramount importance. Designers must prevent SIS from producing any undesirable effects in the physical environment, whether it is caused by sending contradictory or simultaneous commands to the actuators. To this end, designers must be provided with decision support tools that can assist them in identifying and resolving direct and indirect actuation conflicts, and in deploying relevant, yet robust and safe Actuation Conflict Managers (ACM).

In the sequel, a complete toolset for identifying and resolving actuation conflicts is introduced. This toolset consists of three stages throughout the DevOps life-cycle, as described in Fig. 5.1).

Underlying the tools for actuation conflict identification and resolution, a meta-model, denoted Workflow and Interaction Model for Actuation Conflict management (WIMAC), is used to build a structural model of the SIS upon deployment, implementation and physical environment models (phase 1 in Fig. 5.1) [27]. WIMAC provides a modelling language for describing inter-relationships between SIS software components and actuators at the edge of the infrastructure along with their effects on the physical environment.

On the basis of the structural model, potential direct and indirect actuation conflicts are identified (phase 2 in Fig. 5.1). Actuation conflict identification is based on Attributed Graph Grammar (AGG) rules [18] meant to detect conflicting patterns; actuation conflict resolution is based on AGG rewriting rules meant to instantiate local ACMs. DevOps approach aims to provide continuous and rapid software deployment capabilities. In accordance with this approach, a set of pre-configured off-the-shelf and ready-to-use ACMs are offered to designers.

Third, besides off-the-shelf ACMs, a complete formal verification flow is proposed in the Discrete EVent system Specification formalism (DEVS) [39] for designing and verifying reusable custom ACMs, covering different implementation strategies at the edge of the infrastructure (phase 3 in Fig. 5.1).

Finally, the WIMAC-based structural model, with ACMs instantiated, is transformed back to deployment and implementation models (phase 4 in Fig. 5.1).

The problem of identifying and resolving IoT-based systems actuation conflicts is still in its infancy. While most of the existing solutions focus on the identification and the resolution of direct actuation conflicts (a legacy of the technical challenge mentioned above), few focus on identifying and resolving indirect ones [19, 21]. Moreover, the solutions proposed in the literature raise two main problems when it comes to applying them to the DevOps framework; (1) most of them require an a priori knowledge on the system components and the rules governing their evolution [33]; (2) the solutions proposed are thereby monolithic, they implement global identification and resolution mechanisms not easily reusable (e.g., [2, 21, 22]).

In [24], authors recognize that interactions between IoT devices are an increasing cause of safety and security violations whose detection “[…] requires a holistic view of installed apps, component devices, their configurations, and more importantly, how they interact”. This is the approach followed by the SIS actuation conflict management toolset presented in the sequel.

The actuation conflict management workflow is depicted in Fig. 5.2.

DevOps approach provides designers with deployment and implementation models from which it is possible to extract the structural interactions between the SIS software components down to the devices and the actuators they embed. To identify indirect conflicts, however, it is necessary to describe the effects that the actuators produce in the environment in which they operate. Unless each actuator is accompanied by semantic annotations, these descriptions have to be provided by the designers, using a model of the physical environment.

From these models, an holistic description model is generated. This model is built on a metamodel called WIMAC (Workflow and Interaction Model for Actuation Conflict management). This metamodel (Fig. 5.3) provides a language to describe (1) the inter-relationships between software components, down to the actuators at the edge of the infrastructure as well as (2), the effects that the actuators produce in the physical environment in which they operate. The WIMAC metamodel main entities are the following:

1. SoftwareComponents are black-box components. They conceptualize single applications or composite applications described through implementation models (e.g., Node-RED¹ flow). The actuation conflict management solution proposed in the sequel is based solely on the structural links that exist between software components for inferring their interrelationships, identifying and resolving potential conflicts.

2. ActionComponents are SoftwareComponents controlling actuators,

3. PhysicalSystems are spatially delimited physical entities whose properties can be changed by ActionComponents (e.g. the temperature in the kitchen).

Relying on the WIMAC-based model, potential direct and indirect actuation conflict points can be identified and monitoring ACMs instantiated locally. This first step is automatically achieved through a set of predefined Attributed Graph Grammar (AGG) rules [18] in the form of attributed graphs. These rules define (1) conflict patterns to be identified in the WIMAC-based model and (2) associated graph transformations to be applied on the model so as to instantiate monitoring ACMs (Fig. 5.4).

DevOps approach aims to provide continuous and rapid deployment capabilities. To support this objective, a set of off-the-shelf generic ACMs are proposed to designers thereby, replacing dummy ACMs with relevant concrete ones. Although this approach requires designers to take responsibility on the ACMs to be instantiated before applications are deployed, it has several advantages. (1) it helps reinforcing SIS trustworthiness, specifically as actuation conflict management implies some semantic background humans are better able to grasp considering SIS complexity globally; (2) this is all the more important as ACMs are instantiated locally, addressing points of potential conflict in the design. The advantage here is that software components are regarded as black boxes, ACMs do not change their logic.

While off-the-shelfreusable ACMs are relevant for resolving common actuation conflicts, they may not be suitable for some particular cases. To address this concern, state-of-the-art Model Driven Engineering (MDE) tools are leveraged, allowing designers to develop custom, yet robust and safe ACMs, throughout a two-level design workflow (Fig. 5.5).

At the first level, logic of the custom ACMs are defined through Finite State Machines (FSM) built on the basis Event-Condition-Action rules. These conceptual models allow logical properties (e.g. completeness, safety, liveness, etc.) to be formally verified using state-of-the-art methodologies [3].

At the second level, implementation models allow temporal properties to be formally verified by applying different asynchronous timing strategies. Implementation models are proposed to be described through the DEVS formalism (Discrete EVent system Specification)[39]. This formalism brings key advantages in the realm of trustworthy SIS and DevOps.

1. DEVS atomic models allow to encapsulate conceptual models into DEVS Atomic models, coupled with synchronizers that can implement different timing strategies on the inputs of the FSM and targeting different hardware platforms. This approach is particularly relevant considering that SIS software components are likely to be deployed on resource-constrained platforms at the edge of the IoT infrastructure, governed by asynchronous events relative to wireless communication protocols, computational capabilities, etc. [35]. Several modelling and simulation tools are available to facilitate this process [6, 25, 36],

2. It provides a common representation to different discrete event modelling formalisms (including Petri Nets, FSM, etc.) [41]. Designers are therefore not bounded to a particular modelling framework when designing custom ACMs.

3. DEVS Atomic models, once verified for temporal properties, can be translated into any high-level programming language (e.g., C, C++, C#, etc.) and compiled for further deployment. This allows to build a library of reusable off-the-shelf DEVS-based ACM software components (a.k.a., DEVS kernels) targeting different implementation strategies (i.e., hardware platforms).

While, during the development phase, the ACM tool allows for the identification, analysis and resolution of actuation conflicts, it remains, however, based on the global architecture of the SIS and its operational environment, i.e., and is therefore based on a priori acquired knowledge. However, by interacting with the physical environment through actuators, SIS inherits the complex nature of this open environment. Thus, assuming that the knowledge acquired a priori is complete and immutable is illusory, no matter how complicated the associated models may be; an infinite number of unexpected physical processes are likely to disrupt, at any time, operation of the SIS. In the realm of trustworthy SIS, the ACM tool alone thus cannot meet the concerns of reliability and safety. It is therefore necessary to complement this tool with a systemic approach, required to the modelling of complex SIS [30].

Without being able to predict the behaviour of SIS in their design phase, a DevOps tool-set is developed for analysing SIS behavioural drifts at run-time (Fig. 5.6). The aim of the first tool described in the sequel is to quantitatively assess SIS effectiveness at run-time, i.e., the extent to which the effects produced in the physical environment are legitimate (phase 2 in Fig. 5.6). It is no longer a question of describing the global architecture of the SIS, but of describing a model of the effects they have to legitimately produce in the physical environment in different contexts (phase 1 in Fig. 5.6). However, being quantitative in nature, the effectiveness assessment is difficult to interpret by humans and does not allow for creating synergies and fostering communication between development and operations activities, as advocated by the DevOps approach. Indeed, from the designers’ point of view, while the effectiveness assessment allows the detection of unexpected and/or abnormal behaviour at run-time, it does not allow their causes to be identified. Thereby, this hampers a new DevOps cycle from being initiated rapidly so as to implement the corrective actions required. To address this concern, a second tool is presented in the sequel. This tool (phase 3 in Fig. 5.6), produces a model of the behaviour observed in the field and compares this model with the model of the legitimate behaviour produced in phase 1. This results in a dissimilarity graph between both models which, without identifying the causes of the drifts in effectiveness, sheds light on the symptoms likely to explain them [29].

The problem raised in this research, and the solution described in the sequel, concerns the detection, identification and intelligible representation of the symptoms characterizing SIS abnormal behaviours, for the purpose of empirical analysis. A recent systematic literature review carried out on the anomaly detection, analysis and prediction techniques in IoT environments [10], corroborates fairly well the novelty of the approach proposed in this work and the impacts it can have in the SIS community. Indeed, authors found gaps in the visualization of anomalies in IoT-based systems. They conclude that new methods and approaches are needed to represent intuitively IoT-based systems for analytical purposes. This is what the solution described in the sequel is all about.

Current software engineering approaches, which include formal testing and verification methodologies, claim for predictability. However, “in practice, analytical modelling is increasingly proving inadequate, whenever it is agreed that one is not sure that something cannot be forgotten (the hypothesis of closing the model), that objective evidence is only evident in a given ideology (…), in other words, whenever one has to make the assumption that the phenomenon modelled is not complicated but complex” [20] p. 19.

SIS, by their interaction with the open physical environment, are complex systems; At best, can we hope to get as close as possible to the desired behaviour without reaching it exactly: “[…] as soon as a system is open there is no optimum and any equilibrium is in interaction with its environment” [31]. As a result, while the formal testing and verification methods still need to be conducted at design-time, they are not sufficient; the effectiveness of the SIS, i.e., the extent to which SIS behave as expected, must also be continuously evaluated at run-time.

Analytical modelling being inadequate, SIS effectiveness assessment has to rely on a systemic model of the physical effects they are legitimate to produce in the physical environment [30]. In the sequel, it is proposed to build this model in the framework of the Input/Output Hidden Markov Models (IOHMM) [4]. This framework is broadly used in behavioural modelling approaches [14, 40] where it has many advantages [37]; (1) it is an explainable graphical model [15] part of the Dynamic Bayesian Networks (DBN) family; (2) it formalizes conditional dependencies between the effects and their stimuli (i.e., contextual input, events); (3) it handles tolerances on expectations that may reflect randomness of some expected behaviours (through probability theory) or epistemic gaps in SIS knowledge (through the possibility theory and the Transferable Belief Model (TBM), an extension of the Dempster-Shafer evidence theory).

Formally, an IOHMM is defined by the tuple $〈Q,π→,A,B→〉$ where:

• Q = {x₁, x₂,…, x_N}, N ∈ ℕ, is the finite set of hidden states where x_(k) denotes the hidden state at time k ∈ ℕ,

• $π→=(π1,π2,…,πN)T$ is the initial state distribution vector where π_i denotes the likelihood of the state i to be the first state of a state sequence,²

• A is the N × N state transition matrix, where each element a_ij of the matrix is an n-dimensional input distribution (1 ≤ i, j ≤ N). Thus, $aij(u→)=p(x(k+1)=j|x(k)=i,u→(k)=u→)$ denotes the likelihood of transitioning to state x_(k+1) = j at time k + 1, given the current state x_(k) = i and the contextual input vector $u→(k)=u→∈ℝn$ at time k. The function p has here to be understood in the general framework of the uncertainty theory. While most of the hidden Markov-based models are defined in the probabilistic framework (i.e., p is a measure of probability), the model is also compatible with the possibility theory [28], the imprecise probabilities [11], etc.

• $B→=(b1,b2,…,bN)T$ is the state emission vector, where each element b_i (1 ≤ i ≤ N) is an m-dimensional output distribution. $bi(y→)=p(y→(k)=y→|x(k)=i)$ denotes the likelihood of observing the output vector $y→(k)=y→∈ℝm$ at time k, i.e., the physical effects produced, while being in the state x_(k) = i. The output observation $y→(k)$ at time k only depends on the state x_(k) at time k.

This model serves as a basis for efficient solutions to several inference problems [26]. Among these problems, the problem of inferring the likelihood of an observation sequence (i.e., $p((u→(k),y→(k))k=1K)$⁠) to have been generated by the model (filtering), is particularly close to the one of assessing SIS effectiveness whose solution is given by the forward algorithm, here below in its (qualitative) possibilistic form where the function p is a measure of possibility denoted by Π:

1. Initialization – ∀x ∈ Q:

   $α(1)(x)=min(πx,Π(y→(1)|x))$

   5.1
2. Induction – ∀x, x′ ∈ Q, ∀2 ≤ k ≤ K:

   $α(k)(x)=min(maxx′∈Q(min[α(k−1)(x′),Π(x|x′,u→(k−1))]),Π(y→(k)|x))$

   5.2
3. Termination

   $Π((u→(k),y→(k))k=1K)=maxx∈Q(α(K)(x))$

   5.3

An example is depicted in Fig. 5.7. The model describes the legitimate effects that a luminosity control system must produce where tolerances on expectations are described through distributions of possibility as depicted in Fig. 5.8. Here, $u→$ corresponds to the value of a presence sensor, y corresponds to the value of a luminosity sensor.

On the basis of the IOHMM model and field observations, the effectiveness assessment allows the detection of behavioural drifts, consequence of unexpected behaviours, whether legitimate or not. It complements the formal testing and verification approaches carried out at design-time. However, while the model underlying this evaluation is explainable, the same does not apply to the evaluation itself. Indeed, as a quantitative evaluation, it does not provide designers with information that would support them in understanding the reasons for its drifts, limiting de facto their ability to quickly take corrective actions and mitigate risks. The tool described in the sequel is meant to fill this gap.

This tool is mainly based on a generic clustering-based algorithm meant to learn IOHMM structure (states and state transitions) and parameters (distributions) from field observations. This algorithm consists in segmenting u and y observation spaces into a finite number of relevant regions such that each region represents respectively an input context and a discrete state, i.e., it is assumed that there exists a bijection between state and observation spaces [32], thereby taking advantage of understanding the structure of the IOHMM from the observation space [16].

Considering the observation sequence $(u→(k),y→(k))k=1K$⁠, the algorithm works as follows (detailed in [29]):

1. Get the set Y of clusters from $(y→(k))k=1K$ such that each observation $y→(k)$ is associated to a cluster Y_i (i.e., a state), i ∈ |Y|

2. Get the set U of clusters from $(u→(k))k=1K$ such that each observation $u→(k)$ is associated to a cluster U_j (i.e., an input context), j ∈ |U|

3. Get distribution parameters of B_i from ${y→}$ associated to Y_i

4. Get the state-transition matrix A

   • the sequence of clusters $(y(k))k=1K$ obtained from $(y→(k))k=1K$ defines the valid state-transitions A_ii′(h), i, i′ ∈ |Y|, h ∈ U

   • A_ii′ (h) distribution parameters, h ∈ U, are computed from ${u→}∈h$⁠.

On the basis of this algorithm, a framework is proposed for investigating drifts in effectiveness of SIS. This framework conceptually takes place in two steps as depicted in Figure 5.10.

• ❶

  The learning algorithm is fed with observations corresponding to the effects expected to be produced by a SIS in different contexts, leading to the learning of a model of its legitimate behaviour.

• ❷

  This model is complemented with real-world observations, leading to the learning of a model of the observed behaviour. Then, on the basis of these models, an algorithm is developed to build a directed dissimilarity graph that makes clear the differences between both models, thereby helping designers direct their research and identify the possible causes of drifts in effectiveness.

Let us consider an observation sequence corresponding to the legitimate behaviour, defined by $(u→(k)∗,y→(k)*)k=1K$⁠, followed by an observation sequence corresponding to real-world observations, $(u→(k),y→(k))k=K+1G$⁠. The algorithm works as follows (detailed in [29]):

1. Get the set $𝖄$ of clusters from $(y→(k))k=1G$

2. Get the set $𝖀$ of clusters from $(u→(k))k=1G$

3. Get the set $Y⋆⊂𝖄$ of clusters associated to $(y¯⋆(k))k=1K$

4. Get the set $U⋆⊂𝖀$ of clusters associated to $(u→(k)⋆)k=1K$

   • ⊳ $Yi∉Y⋆,i∈|𝖄|$ corresponds to unexpected states.

   • ⊳ $Ui∉U⋆,i∈|𝖀|$ corresponds to unexpected contextual input.

5. The sequence of clusters obtained from $(y→(k))k=1K$ defines legitimate state-transitions $Aii′⋆(h),i,i′∈|Y⋆|,h∈U⋆$⁠. Also, the sequence of clusters obtained from $(y→(k))k=K+1G$ defines observed state-transitions $Aii′(h),i,i′∈|𝖄|,h∈𝖀$⁠.

   • ⊳ State-transitions A_ii′ (.) defined in the state-transition matrix A but not defined in the state-transition matrix A⋆ correspond to unexpected statetransitions.

   • ⊳ State-transitions A_ii′ (h) defined in the state-transition matrix A and in the state-transition matrix A⋆ with h ∉ U⋆ correspond to unexpected statetransitions (i.e., are triggered by unexpected contextual input).

6. Plot the dissimilarity graph where expected states (nodes) and statetransitions (edges) are coloured in green while unexpected ones are coloured in red as depicted in Fig. 5.10.

The dissimilarity graph, without identifying the causes of the drifts in effectiveness, sheds light on the symptoms likely to explain them.

The purpose of this section is to illustrate the toolset presented in this chapter and its benefits throughout DevOps life cycles. The illustration is carried out on a real world smart-home scenario, providing the reader with technical details and key results.

The experimentation is built upon the widely spread three-layer IoT architecture [17]. The first layer (Perception Layer) at the edge of the infrastructure consists of 57 IoT devices providing up to 319 parameters including 249 sensor/actuator whose values/states are updated on a regular basis on a centralized time series database (Synology DS418 Network Attached Storage (NAS) + InfluxDB [23]). IoT devices part of this infrastructure layer are mainly consumer electronics devices (e.g., Netatmo devices, Neato vacuum cleaner, LG TV, etc.), complemented with custom IoT devices based on Arduino Uno/Nano and Raspberry Pi equipped with sensors and actuators targeting specific purposes. The second layer (Network layer) enables data transmission and processing, throughout the different IoT wireless communication protocols (Wifi, ZWave [38], etc.). OpenHab [5] and MQTT middlewares provide this layer with the functionalities required for the illustration. Finally, the third layer (Application layer) consists in several software components controlling actuators and processing sensor data. These software components (along with middlewares) are encapsulated into docker containers hosted on computational resources (Raspberry Pi) at the edge of the infrastructure.

To illustrate SIS actuation conflict management (Paragraph 5.2) and behavioural assessment/drift analysis (Paragraph 5.3) toolsets, the following devices are used; a smart phone, a TV along with its remote control, a light bulb, an Amazon echo smart speaker and an autonomous smart vacuum cleaner. These devices are all located in the living-room and are implemented as part of a scenario focusing on inhabitants well-being. In this scenario, user-comfort is driven by luminosity and sound physical properties.

A first application set (UserComfortApps) is dedicated to give sensor data access to decision making algorithms (App_Lum and App_RC_TV) that respectively control (1) the luminosity level by acting on the roller shutters and the light bulb and (2) the sound by acting on the TV remote controller and the Amazon echo smart speaker. A second application set (i.e. CommunicationCenterApps) is deployed, creating a home-working environment where the focus is put on controlling sound sources so as to prevent home workers to be disturbed during phone calls or video conferences (e.g., App_Phone_TV mutes TV while a phone call is in progress). All applications are implemented through Node-RED flows.

To illustrate the toolsets proposed within the DevOps approach, a scenario with two DevOps cycles has been defined, each cycle covering the development and the operational stages.

At this stage, the aforementioned software components are designed and developed (Fig. 5.12). Before deploying the whole system, the toolset developed for identifying and resolving actuation conflicts (Paragraph 5.2.2) is applied on the WIMAC model built from deployment, implementation and physical environment models. Designers specify the physical environment model by linking ActionComponents to the PhysicalProperty they act on. At this point, a potential direct actuation conflict is identified on App_RC_TV and App_Phone_TV; these applications being meant to control the TV sound source (Fig. 5.13).

The management of this direct actuation conflict is straightforward, applications merely send a Boolean value to a shared actuator (ActionComponent). The developer can then select, among the available off-the-shelf ACMs, the one relevant to resolve this generic conflict type (here, a simple OR logic ACM has to be instantiated between both software components (App_Phone_TV and App_RC_TV) and the actuator they act on (TV)). Once the selected ACM is instantiated into the WIMAC model, a new deployment model is generated from WIMAC and pushed to GeneSIS which concretizes the deployment.

Throughout the execution of the SIS, the effects produced in the physical environment are observed and, thanks to the behavioural drift assessment toolset, the effectiveness of the SIS is measured from a model of the legitimate behaviour it has to comply with (Fig. 5.14).

The model of the legitimate behaviour is built upon a set of sound features computed from a microphone signal. Output observations (expected effects to be produced by the SIS) are then characterized by a Mel-Frequency Cepstral Coefficient³ (MFCCs) and the Zero Crossing Rate⁴ (ZCR) sound features. These sound features lead a good segmentation of the observation space thereby, allow identifying device states on the basis of the sound they emit. Contextual inputs are characterized by the operating status of the TV and the communication status.

As depicted in Fig. 5.15, the ACM instantiated during the design phase fulfils its role and prevents the TV to operate while a communication is in progress. No behavioural drift is therefore reported.

While the SIS operates, free of unexpected effects produced in the physical environment, an autonomous smart vacuum cleaner moving around in the house, bursts into the living-room. By operating in the living-room, this device produces unexpected sounds leading behavioural drifts to occur (Fig. 5.16).

From the designers’ point of view, the quantitative effectiveness assessment is not informative on the reasons for the drifts in effectiveness observed. At that point, the behavioural drift analysis tool (Paragraph 5.3.2 and 5.3.3) is leveraged to guide designers and help them correlate the symptoms of the drifts in effectiveness to various events (Fig. 5.17).

On the basis of the dissimilarity graph depicted in Fig. 5.17, designers can infer that drifts in effectiveness are the result of the smart vacuum cleaner unexpectedly (but legitimately) operating in the living-room and producing conflicting noise. This device was unforeseen by designers in the initial model of the legitimate behaviour. Moreover, this device has to be controlled so as to be integrated into the user-well being control strategy and prevent indirect conflicts to occur on the sound physical property.

The behavioural drift reported at run-time suggests that the model of the physical environment is incomplete. Indeed, the indirect conflict on the sound physical property should have been identified during the first phase of development. A new development cycle is therefore necessary to correct the model of the physical environment. The updated model is depicted in Fig. 5.18; an indirect actuation conflict is now detected between the App_RC_TV, App_Phone_TV and the App_Vaccum_Cleaner applications and a dummy ACM has been instantiated.

The management of this indirect actuation conflict implies semantic concerns that cannot be managed through generic off-the-shelf ACMs. A custom ACM has to be developed. This task relies on “ECA” rules that define the ACM logic, further transformed into an FSM. More specifically, designers have to describe a control strategy that prevent the TV and the smart vacuum cleaner robot to produce sound simultaneously. The custom ACM thus receives commands from App_RC_TV), App_Phone_TV and App_Vaccum_C/eaner. On the basis of these input, the ACM control logic defines a strategy resulting in sending commands to the TV and the vacuum cleaner such that it is stopped while a communication is in progress or while inhabitants watch TV. The ACM control strategy defines some prioritization whose semantic has to be defined by designers.

Along with the logical strategy of the custom ACM, some logical and temporal properties to be formally verified have to be specified. To this end, ECA rules are extended into ECA+ rules (more details about this language are given in [7]) to provide the model with the properties to be verified by state-of-the-art MDE verification tools.

Logical properties are verified through NuSMV [8], a state of the art model checker. Model checkers are meant to ensure that logical properties are always verified, regardless of the state sequence being executed. Two main types of logical properties are formally verified: safety (i.e., something bad will never occur) and Liveness (i.e., something good will eventually happen). In the context of ACM design, safety properties ensure that conflicting states will never occur (e.g., the vacuum cleaner will never operate while a communication is in progress).

Temporal properties are verified through DEVS formalism. FSMs are defined by two functions: (i) the state-transition function computes the new state given the previous state x_(k−1) at time k − 1 and the current input $u→(k)$ at time k, (ii) the output function computes the outputs $y→(k)$ that solely depend on the state x_(k) at time k. DEVS formalism allows an FSM to be encapsulated into DEVS atomic model coupled with a synchronizer managing asynchronous timings on the inputs of the FSM. The ECA+ language provides a syntax to specify asynchronous timings management strategies for the synchronizer. Temporal properties can then be verified for each strategy within a DEVS simulation environment. It is worth noting that asynchronous timing strategies are meant to reproduce the asynchronous timings that govern the different hardware platforms ACMs are supposed to be deployed to, at the edge of the IoT infrastructure.

Once ACMs temporal properties have been verified in DEVS simulated operational contexts, associated DEVS Atomic models (embedding the synchronizer and the logical behaviour) can be directly used for implementation. Indeed, DEVS Atomic models can be translated into high level programming languages (C, C++, C#, Node.js, etc.), embedding a lightweight execution engine (DEVS kernel). This makes ACMs completely portable on the lightweight hardware platforms available at the edge of the IoT infrastructure.

Here again, the WIMAC model modified with the custom ACM is sent to GeneSIS for the deployment on the platforms, thus completing the second development cycle.

Finally, SIS is deployed and the physical effects it produces in the physical environment are observed. The model of the legitimate behaviour is modified to take into account the autonomous vacuum cleaner, as learned during the first cycle. No behavioural drift is reported anymore. However, as the physical environment is complex, there are many reasons why the behaviour of the SIS may drift again and trigger a new development cycle:

• the introduction of a new software component that drives an actuator not correctly defined in the model of the physical environment,

• the introduction of a new device producing physical effects in the environment (as the vacuum cleaner in the use-case),

• unexpected changes in the physical environment in which the SIS operate (e.g., a tree growing in front of a window is likely to have an impact on the luminosity of the room in the long term).

This chapter has introduced two innovative toolsets designed to enrich the DevOps eco-system and meant to address an issue that has been poorly addressed, to date, in the development of trustworthy SIS: the management of applications that can interact with their physical environment through actuators.

The first toolset, called “Actuation Conflict Management” toolset (ACM), is to secure the design of these applications at Devs time. The objective is to identify and resolve, through local structural transformations of the SIS, the actuation conflicts that might arise as a result of the actuation effects produced in the physical environment a priori known and limited to its model. While such precautions at Devs time are necessary, they are not sufficient to guarantee that the SIS will always operate as expected in the physical environment. There is a risk of behavioural drift which is observed and quantified at Ops time, thanks to the second toolset called “Behavioural Drift Assessment & Analysis” toolset (BDA). This toolset makes it possible to assess and analyse the differences between the expected and observed effects of the SIS in real-world environment.

Beyond the interest of these toolsets as part of the DevOps methodology, their complementarity represents a major contribution in the realm of trustworthy SIS. Indeed, it is during consecutive DevOps cycles that the contribution of the couple BDA-ACM can be fully appreciated. The BDA toolset provides DevOps team with information on the observed behavioural drifts, thus motivating new development cycles which then results in changes to the model of the physical environment and/or corrections of the applications carried out in and with the ACM toolset. This complementarity is highlighted in this chapter throughout a smart-home use-case which involves two consecutive DevOps cycles to converge towards a SIS with satisfactory behaviour.

It is within the framework of this complementarity that two possible lines of work are foreseen. The first axis aims to reinforce the added-value of the information obtained from the BDA so as to accelerate the SIS/ACMs re-design cycle. Indeed, while the BDA toolset allows to obtain a model of the effects observed in the field and the symptoms of their dissimilarities with the legitimate ones, it is neither informative on the root-causes underlying these differences nor it provides insights to infer the corrections to be made to the model of the physical environment. The second axis is about leveraging behavioural drift measures as rewards towards self-adaptive ACMs automatically containing/mitigating behavioural drifts at run-time.