Component-based specification, design and verification of adaptive systems

Control systems are typically tightly embedded into their environment to enable adaptation to environmental effects. As the complexity of such adaptive systems is rapidly increasing, there is a strong need for coherent tool-centric approaches to aid their systematic development. This paper proposes an end-to-end component-based specification, design and verification approach for adaptive systems based on the integration of a high-level scenario language (sequence chart variant) and an adaptation definition language (statechart extension) in the open source Gamma tool. The scenario language supports high-level constructs for specifying contracts and the adaptation definition language supports the flexible activation and deactivation of static contracts and managed elements (state-based components) based on internal changes (e.g., faults), environmental changes (e.g., varying context) or interactions. The approach supports linking managed elements to static contracts to formally verify their adherence to the specified behavior at design time using integrated model checkers. Implementation can be derived from the adaptation model automatically, which can be tested using automated test generation and verified at runtime by contract-based monitors.

propose the specification of functional system requirements using an informal language, whose automated utilization in later development phases, for example, V&V, is not feasible.
In order to tackle these issues, model-based systems engineering (MBSE) and component-based systems engineering (CBSE) 5-10 put the focus on the application of models and components, considering them the main artifacts that provide the primary means of information exchange during system development. These artifacts can be utilized to support platform-independent, high-level design, the automated derivation of implementations to multiple platforms and automatic V&V both at design time and runtime with the potential utilization of formal methods. 11 However, there is a lack of cohesive tools as well as methodologies for building adaptive applications 12 and the employment of formal methods for V&V, for example, model checking, remains low. 11 Thus, engineers generally struggle with incompatible techniques and tools to specify requirements, design and implement the adaptation logic and managed elements (e.g., adaptable components) and verify and validate the resulting application using integrated tools.
Consequently, there is a need for coherent tool-centric MBSE and CBSE approaches to aid the systematic development of adaptive systems along the entire development process, including (i) requirement specification, (ii) the design of adaptation logic and elements managed by it, (iii) formal verification and testing of the resulting behavior and (iv) automated derivation of implementation with monitoring support. As a solution, we propose an approach in the context of our open source Gamma Statechart Composition Framework 1,13 which is an integrated modeling toolset for the semantically well-founded modeling and analysis of state-based reactive systems. 14 Our approach offers a scenario language to specify contracts for adaptive behavior in terms of interactions (input and output events) and sequence chart 15 constructs, for example, alternative, parallel and loop fragments. It also offers a design language, called adaptation definition language, based on the well-known statechart formalism 16 to design the adaptation logic. The language supports the definition of adaptive application behavior based on configurations of activated and deactivated state-based components (managed elements). Moreover, the activation and deactivation of scenario contracts can also be defined by linking them to component configurations that shall satisfy these contracts. The created adaptation model can be formally verified against contract specifications in our integrated design environment by mapping these models into the inputs of model checker tools. We also provide methods for deriving implementation (source code) for the designed system, as well as generating test cases that can check the conformance of the implementation on a specific platform to the contracts. This work builds on and extends our contract-based specification and black-box test generation approach for adaptive systems, presented in its initial version in literature. 17 Nevertheless, this approach did not support adaptation logic design (the definition of applica- 1 More information about the framework and the source code can be found at http://gamma. inf.mit.bme.hu/and https://github.com/ftsrg/gamma/. tion behavior in system states) and thus, either formal verification of adaptive behavior against contract specifications or implementation derivation supporting monitoring. In this work, we extend the original approach and provide solutions to these missing features.
Accordingly, this paper presents an end-to-end CBSE approach for adaptive systems development seamlessly integrated in our modeling tool, Gamma, based on the following main features.  In the development standards of safety-critical systems, for example in IEC 61508:2010, 18 dynamic reconfiguration in the software architecture is not recommended as it may complicate the achievement of predictability, verifiability and testability. Adopting a state-based approach to design the adaptation logic and managed components opens a way to design predictable adaptation. The use of precise modeling languages (including scenario-based representation of requirements) allows for complete formal verification and test generation with respect to well-defined test coverage criteria.
The rest of the paper is structured as follows. Section 2 presents the motivation and basic concepts of our work in the context of an example smart house themed adaptive system, and positions our approach among existing solutions (related work). Section 3 overviews our proposed CBSE approach for adaptive systems in our Gamma tool. Section 4 describes how adaptive behavior can be modeled in our approach based on the example system presented in Section 2.
Section 5 presents the model transformations enabling the formal verification, test generation and code generation supporting monitoring for adaptive models in Gamma. Section 6 presents experiments with the smart house themed example model. Finally, Section 7 concludes the paper and outlines plans for future work.

MOTIVATION AND BACKGROUND
This section presents the motivation and background of our work. Section 2.1 introduces a motivating example, namely an adaptive smart house system, as well as basic concepts of adaptivity, in the context of which later sections present our CBSE approach. Section 2.2 covers related work and positions our solution in the state of the art based on the identified gaps in terms of adaptive systems development.

Motivating example and basic concepts of adaptivity
The motivating example builds on an adaptive smart house system 2 presented in literature 19,20 and extends it with additional components and adaptation behaviors. With this example, in addition to presenting our approach, we also aim to enrich the set of models available for evaluating solutions focusing on the development of adaptive systems.
The adaptive smart house system, whose thorough functional breakdown can be found in the Appendix, controls the ventilation in a room based on the number of present people. The system, as illustrated in Figure 1, comprises two sensors, a camera and a simple motion sensor (see Figures 3 and 4), responsible for detecting people, as well as two actuators (see Figures 5 and 6), a smart ventilator and a switch, for controlling the ventilation level in the room based on presence datathese are the components (managed elements) managed by the adaptation logic realized by a central controller (adaptation model -we will present it later in Figures 7 and 10 after introducing our adaptation definition language to make its adaptation-related features understandable). The adaptive nature of the system stems from the fact that these components can become unavailable (e.g., due to internal faults) or must be deactivated (e.g., due to external commands) to which the adaptation logic must react by component adaptation (reconfiguration), for example, activating the motion sensor after the failure of the camera (see an illustration in Figure 2), or the adaptation of parameters, for example, adjusting the frequency of communication between components based on presence data or energy consumption. Upon changing between component configurations, the requirements that the system must satisfy can also change, that is, the newly activated components may offer an extended functionality or can provide only a degraded system service, for example, in the case of the more complex camera and the simpler motion sensor components. History between the deand reactivation of components may also have to be saved to support continuity after handling a certain external or internal event, for example, keeping the ventilation level in the room the same after handling a fault.
Regarding the detailed functionalities of the sensors, the motion sensor can detect only the moving of people in the room, whereas the camera can also identify the number of present people with image processing techniques, which can be used to adjust the ventilation level accordingly. The system wants to minimize internal event transmission between components to minimize power consumption by frequent communication and changes of ventilation level. Thus, the camera has an adjustable granularity parameter (variable) that sets the difference in the number of detected people that, compared to the last update, results in an update towards the actuators. The camera also has a battery that is drained when people are detected and can be recharged in an idle state. As a special feature, the motion sensor can count incoming motion events in a specified time interval and detect unexpected situations (i.e., too many events in a time interval), such as failures in the underlying hardware components or potentially malicious behaviors. Regarding actuators, the switch can only turn off and on the ventilation at a predefined (default) level, whereas the ventilator can also adaptively set the ventilation level based on the number of present people (data received from the camera) and the time elapsed since the last received data (data becomes obsolete after a while).
As demonstrated in the description of the example system, there are special concepts for adaptation, which must be addressed during the functional breakdown of the system (requirement specification), as well as system design to ensure its correct functioning in case of different events. Accordingly, we explain the following concepts in detail, which are prevalent in the design of adaptive systems both in our approach and in the state of the art 21  reconfiguration in the rest of the paper (see the activation of the motion sensor after the failure of the camera in our example, illustrated in Figure 2). Our approach supports components with an event-driven behavior modeled using statecharts.

Parametric adaptation
Parametric adaptation allows for the fine tuning of system behav-

Related work and gaps in the development of adaptive system
Many different aspects of adaptive systems development have been researched in the past 22,23 due to the wide spectrum of applica-tion types. Accordingly, many design solutions, for example, goalbased, [24][25][26] rule-based, 27 actor-based, 28 service-based 29 and modelbased, 30 as well as V&V solutions, for example, (runtime and probabilistic) formal verification, 31-34 theorem proving 27 and monitor-based runtime verification, 35 have been presented. This section overviews adaptive systems development solutions related to ours that support behavior. In addition, adaptive CSP models can be exhaustively verified using process-algebraic mechanisms, as well as LTL model checking.
The authors also present how adaptive CSP models can be used to derive implementations realizing the specified behavior; however, the derivation process is not fully automated. The main limiting factor in their methodology is that they do not support the description of adaptive behavior based on high-level requirement specification and state-based models, greatly hindering its application by systems engi-

COMPONENT-BASED DEVELOPMENT OF ADAPTIVE SYSTEMS
This section presents our CBSE approach for adaptive systems. First, Section 3.1 overviews how our solution addresses the general concepts of adaptivity presented in Section 2. Next, Section 3.2 introduces the modeling languages supporting the approach, which is followed by the description of the design and internal transformation steps necessary from the designer (user) and the Gamma tool in the development workflow (see Section 3.3).

Proposed modeling strategy
In Section 2.1, we argued that the presented concepts of adaptivity must be addressed in a solution that aims to support the flexible and V&V-oriented design of adaptive systems. Accordingly, we describe how our approach addresses the above concepts with different modeling facilities. The relations and linking of these modeling facilities are demonstrated in a conceptual diagram in Figure 7 (explained in the sequel).

Adaptation logic
In our approach, the adaptation logic is captured in a statechart model,

History
In addition to historyless reconfiguration, our approach supports both shallow history, that is, history only for the topmost regions in statechart components, and deep history, that is, history for all nested regions, during component and contract reconfiguration. In both cases, history considers internal variables. Shallow or deep history are not distinguished in the case of contracts as each contract represents scenarios of events without multiple levels of refinement.

Supporting modeling languages
The concepts of adaptivity presented in Section 3.1, as well as the services provided by our CBSE approach presented in Section 3.3 are supported by the following modeling languages:

The Gamma Scenario Language (GSCL) is a configurable variation
of the LSC 15 (Live Sequence Chart) formalism supporting the highlevel description of system behavior in terms of input and output events (interactions).

The Gamma Statechart Language (GSL) is a configurable
UML/SysML-inspired formal statechart 16

Supporting development workflow
Our CBSE workflow (depicted in Figure 8) comprises two parts. The

MODELING OF ADAPTIVE BEHAVIOR
This section presents the modeling languages of our approach for modeling functional behaviors of adaptive systems in the context of the example smart house system presented in Section 2.

Specifying scenario contracts
Scenarios can be defined in GSCL, which is a Live Sequence Chart (LSC) 15 Figure 9 with scenario examples that specify interaction sequences for the camera component and the whole adaptive smart house system.
For a more thorough description of the language, we direct the reader to literature. 52,53 1. DelayThenMotion specifies that after a certain time (specified by the TIMEOUT_TIME constant) if the camera receives a motion event via its Camera port, it has to transmit it via its Motion port (towards the actuators).
2. MotionThenMotion specifies that after the camera receives a motion event via its Camera port, and then receives another one in a specified time interval (timeoutTime parameter), it must not transmit it via its Motion port (to save battery).
3. MotionThenDelayThenMotion specifies that after the system (spec- interactions that need to occur at the same time/cycle (Lines 28-32).
In an interaction set, the direction and modality of the contained inter- GSCL supports test generation with configuration options for (1) specifying constraints for system response and (2) categorizing unspecified system behavior.
Option 1 handles the issue of not knowing the exact latency between inputs and reactions in an implementation. For example, Lines 11 and 12 specify that the system must respond to an incoming motion event with a motion event on the respective output port.
Depending on the implementation, this may take several execution cycles. Therefore, GSCL introduces an annotation (Line 8) that specifies the accepted range of latency in terms of execution cycles. If the response does not arrive within the specified interval, a violation occurs. Note that this kind of uncertainty does not apply to events received by the system, because they do not depend on the system implementation.
Option 2 allows the different interpretation of unspecified events sent by the system during test execution. As explained above, after receiving a motion event (Line 11) the system may have "time" to respond, during which it may send unspecified events, too. GSCL offers annotations (Line 7) to decide whether this behavior is permitted (permissive mode) by ignoring that event or treated as a violation of the interaction expecting the response (strict mode).

Designing the adaptation model linked with changing scenario contracts
As detailed in Section 2.1 (see changing of requirements), the functional requirements that adaptive systems must satisfy may change depending on external or internal events, for example, the failure of a component or an external command prescribing the reconfiguration of components to better handle a certain need. Therefore, a modeling language is required to support the description of adaptivity with respect to scenario contracts.
GASL is a statechart language 16 extension to support the definition of adaptive contracts, that is, the activation and deactivation of static scenario contracts upon specific events. It builds on GSL, the built-in formal statechart language of Gamma, 48

VERIFICATION AND MONITORING OF ADAPTIVE BEHAVIOR
This section presents the internal model transformations in Gamma that facilitate the formal verification (see Section 5.3.1), implementation derivation supporting monitoring (see Section 5.3.2) and test generation (see Section 5.3.3) for the adaptive system based on derived composite models that integrate scenario contracts, the adaptation model and state-based components (see Section 5.2). In order to support these functionalities, as a first step, observer automaton models are derived from scenarios (Section 5.1).

5.1
Mapping scenarios into observer automata In the case of monitoring, the above construction is used both for event reception and transmission. In turn, for test generation, event reception is modeled using a single transition targeting the source state of the next interaction while event transmission is modeled as above.
Note that this construction introduces determinism to event reception In the case of monitoring, the resultant automaton is determinized using the powerset construction method, 55

Creating models for formal verification and monitoring
With the scenario models mapped into observer automata according to the selected functionality (monitoring or test generation, see

Contract-based black box test generation for adaptive behavior
The approach supports black box test generation based on the original (unprocessed) adaptation and contract models using the model checking functionalities of the Gamma framework. Currently, only historyless contract links are supported. As a general idea, in a testing context, an execution trace derived during model checking as a witness for satisfying a property can be considered as an abstract test case for the property based on which it is generated, representing a test target. 57 Thus, with the goal of generating tests, we control model checkers in a way that they generate execution traces (abstract test cases) to cover test targets specified as formal properties, for example, in the case of state coverage as a test target, state reachability properties. Such abstract test cases then can be customized to concrete test environments according to various aspects. 58 Test generation comprises two steps: generating paths in the adaptation model to activate contract models and traversing the activated contract models. The traversal of the adaptation model can be configured using various coverage criteria, including state, transition, out-event or interaction coverage. Based on the configured criteria, reachability properties are generated automatically and then passed to the selected model checkers along with the adaptation model, which return execution traces (paths) represented in GTL to state configurations with linked contracts. The observer automaton models derived from these contracts are then traversed to derive positive or negative tests using Theta as it is the only integrated back-end supporting the retrieval of all paths from the initial state to a certain state in acyclic models. Abstract test cases are created as the sequential combination of paths activating particular contracts in the adaptation model and paths in the contract models. In addition, test configuration options present in the contract models, that is, allowed latency and permissive/strict mode, are saved to support test concretization in the next step.
As a last step, abstract test cases are customized to execution environments, that is, they are mapped into sequences of concrete calls to provide test inputs and time delays as well as schedule system execution, and then retrieve and evaluate outputs. The test configuration options in the concretized tests are handled with a simple auxiliary method used in conjunction with output evaluations as depicted in

EXPERIMENTS WITH THE EXAMPLE MODEL
This section presents experiments with the adaptive smart house system

Scenario contracts for the adaptive smart house system
We defined 11 scenario contracts 5 based on the functional requirements of the system presented in the Appendix, which specify system and component behavior from different aspects. Two scenarios (S1 and S2) describe behaviors of the entire system whereas the remaining ones capture the behaviors of managed components (S3 to S11). S1 and S2 specify how the system must control the ventilation level in the case of motion sensing and timeouts when the ventilator component is active. S3, S4 and S5 capture the common behavior of the camera and motion sensor components focusing on motion sensing and internal event transmission (see DelayThenMotion and MotionThenMotion scenarios in Figure 9). S6 specifies person detection based on the granularity parameter and timeouts for the camera component (an extension of the MotionThenDelayThenMotion scenario in Figure 9), whereas S7 specifies how too many events in a certain time interval must be handled by the motion sensor. S8 describes how ventilation must be turned on and off by the ventilator and switch components based on received motion sensing events. Finally, S9, S10 and S11  Table 1 Table 1). Typically, having unconstrained combinations and sequences of input events is not a practical goal for verification; realistic behavior can be restricted with user-defined environment models.

Formal verification based on the derived composite models
Therefore, we experimented with environment models that restricted error and recovery events. In particular, we specified in an environ- After eliminating such problematic cases, the correctness of a coherent parameterization was proven by formal verification for scenarios S3-S11 and the respective component models based on the derived T-3 models.

Semantic variations
Gamma offers multiple semantic variation options for statechart com- In the second phase, in order to generate positive and negative tests, the algorithm traversed the observer automata that were linked to states in which the generated execution traces ended. Table 3 summarizes the number of generated execution traces and the median and maximum number of steps in these traces considering every linked observer automaton for positive and negative tests for the motion sensor, ventilator and switch components. The generation of such traces was carried out under ten seconds for each automaton.
The number of generated traces in an automaton depends on the number of distinct paths between the initial and the accept states for positive tests, determined by the optional and alternative fragments (branchings) of the scenario. For negative tests, in addition to the number of distinct paths between the initial and the hot violation states, the number of hot modality interactions is also a determining factor.
As Table 3 shows, there were no branchings and there was a single hot TA B L E 3 Results of the observer automaton traversal phase of test generation in the adaptive smart house system.

CONCLUSION AND FUTURE WORK
In this paper, we introduced an end-to-end component-based speci- Our experiments show that the approach is applicable in an extended adaptive house automation system, first presented in literature. 19,20 Adaptive behavior can be adequately modeled using the proposed modeling languages, and the satisfaction of functional requirements specified as scenarios can be formally verified based on component-contract links and the employment of optimization techniques that reduce irrelevant context details. Nevertheless, adaptive models with many adaptation options, as expectable, can pose a great challenge to model checkers if optimization is not employed. In general, this problem could be addressed by extending the formal verification capabilities of Gamma by integrating additional model checkers more tailored to these models along with abstraction and reduction techniques. Also, implementation with monitoring support can be automatically derived and then tested using the generated test sets.
Subject to future work, we plan to extend our approach to allow the management of composite components in order to support a system modeling approach based on compositional variation points and application variants. 36 We intend to realize the extension based on the generalization of the integration and (de)activation facilities for observer automata presented in Section 5.2. Moreover, we aim to extend our scenario language to support inter-component communication (multiple lifelines). We also plan to extend our approach by introducing the modeling and verification of extra-functional properties based on literature 60 and support the automatic deployment of adaptive functionality to computation nodes.

ACKNOWLEDGMENTS
We would like to express our gratitude to Benedek Horváth for his initial contributions to the GSCL metamodel and Dénes Lendvai