DSD2017_Model-driven Development of Safe ...

5 downloads 69367 Views 365KB Size Report
the development tools, developing the software of such systems ... developing safe software systems. ... validate the adaptive behavior of the system [25].
Towards a Safe Software Development Environment Mahmoud Hussein1, Reda Nouacer2, Ansgar Radermacher1 1

CEA, LIST, Laboratory of Model Driven Engineering for Embedded Systems, 2 CEA, LIST, Software Reliability and Security Laboratory P.C. 174, Gif-sur-Yvette, 91191, France {mahmoud.hussein, reda.nouacer, and ansgar.radermacher}@cea.fr

Abstract- It is largely recognized that the architectures of embedded systems are becoming more and more complex both at hardware and software levels. Despite the significant advances in the development tools, developing the software of such systems while ensuring their safety is still a difficult task. In this paper, we propose an engineering methodology to ease the development of safe software systems. It consists of four main phases: system modelling and validation, code generation and integration, static code analysis, and dynamic code analysis. This methodology is realized using CEA LIST 1 open-source development platforms: Papyrus, Frama-C, and UNISIM-VP. These platforms are results of many research and industrial projects such as FP7-SafeAdapt, FUI-EQUITAS, FP7-STANCE, CATRENE-OpenES, and FSNSESAM Grids. Keywords- Embedded Systems; Model-driven Development; Safety Analysis; Simulation.

I.

INTRODUCTION

It is largely recognized that the architectures of embedded systems are becoming more and more complex both at hardware and software levels. Thanks to the constant advances in microelectronic, embedded system engineers are now able to integrate more system functions on a powerful System-on-Chip (SoC) [1]. Due to high integration level, clock frequency, and functioning conditions (e.g. temperature, magnetic fields, etc.), the failure rate of a circuit increases by approximately √2 in an eighteen month period [2]. In addition, the issue of robustness and reliability becomes crucial in the development of complex embedded software systems [3]. Therefore, there is a need for an environment that eases the development of such systems. It also should be kept integrated, and its tools (techniques) evolve hand-on-hand [4]. Recently, a number of research projects has been conducted to assist system engineers in developing complex embedded systems, while ensuring their safety (e.g. MultiPARTES [5], COMPLEX [6], IMPReSS [7], ACTORS [8], DREAMS [9], and SAFURE [10]). The projects have proposed development environments that are built on the partners’ tools. But, keeping these environments fully working on the long term is difficult, where each partner evolves its tools (techniques) separately. CEA LIST has been a partner in a number of research and industrial projects, and has succeed to produce three coherent open-source development platforms: Papyrus [11], Frama-C [12], and UNISIM-VP [13] [14]. In this paper, we propose an engineering methodology that uses these three platforms for 1

http://www-list.cea.fr/en/

developing safe software systems. The main objectives of our methodology are: • Provide an end-to-end software development framework. • Improve the efficiency of software developers. • Increase the system efficiency, while ensuring its safety requirements. The proposed methodology consists of four phases: system modelling and validation, code generation and integration, static code analysis, and dynamic code analysis. First, in the system modelling and validation, the functional and non-functional requirements are taken into account during the specification of an embedded system design in form of a UML model. To create the design model, Papyrus Modeler is used [11]. In addition, to specify details of system behavior that are not possible to be captured by UML fragments (e.g. control algorithms with a continuous behavior), the design model is transformed to a Simulink model. The design model is also turned into an executable model (i.e. fUML [15]), which is used for system validation by simulation using Papyrus Moka [16]. Furthermore, the design model has safety related concepts that are used for early safety analysis by Papyrus Sophia [17]. Second, in the code generation and integration, based on the system design model (validated by simulation and analyzed for safety), a code is generated that is corresponding to the validated model. In addition, to have a fully functioning system, a legacy code is integrated with the generated code by generated wrappers. The code generation and integration step is done automatically by Papyrus Designer [18]. Third, in the static code analysis, integrated code produced by the code generation phase is analyzed statically to verify safety critical properties about the embedded system. The static analysis is performed by the Frama-C platform [19]. The input of this platform is the integrated code annotated with the safety properties as assertions. Fourth, in the dynamic code analysis, in addition to static analysis of the generated code, a non-intrusive dynamic code analysis is performed to detect errors that cannot be detected statically. To do so, the binary code is analyzed dynamically through fault injection and monitoring techniques on the UNISIM virtual platform [20]. The three platforms involved in our methodology (i.e. Papyrus, Frama-C, and UNISIM-VP) have been developed and validated through use-cases of a set of research projects such as in FP7-SafeAdapt [21], FUI-EQUITAS [22], FP7-STANCE [12], FSN-SESAM Grids [23], and CATRENE-OpenES [24].

First, in SafeAdapt, Papyrus Modeler was used to design an automotive system, while Papyrus Designer is used to generate the C Code. This code is then analyzed by the UNISIM-VP to validate the adaptive behavior of the system [25]. Second, in the EQUITAS project, UNISIM-VP has been enhanced with a fault injection capability in hardware components to study the embedded systems reliability [26]. Third, in the STANCE project, the Frama-C platform has been extended for verifying the safety of C/C++ code. Fourth, Papyrus Sophia has been enhanced in the SESAM Grids project to enable risk analysis of a system [23]. Finally, in the OpenES project [24], Papyrus Moka has been improved with a functionality to execute a component-based design, while considering the timing aspects. The remainder of the paper is organized as follows. In Section II, we give a short description of the related work. The platforms used for realizing our methodology are described in Section III. The methodology for developing safe embedded system is presented in Section IV. In Section V, we introduce a number of industrial and research projects use-cases. Finally, work in progress and the paper conclusion are presented in Sections VI and VII respectively. II.

RELATED WORK

Recently, a number of research projects has been conducted to enable the development of safe embedded software systems. In the following, we describe some of them. In the MultiPARTES project, tools and solutions for building trusted embedded systems have been introduced [27]. These systems have mixed criticality components allocated on multicore platforms. The project approach is based on the development of an innovative open-source multicore-platform virtualization layer extending the XtratuM hypervisor [28]. The development methodology proposed in this project supports the development of trusted real-time embedded systems in a costeffective and timely way. A methodology with its associated framework for exploring the design space of embedded systems have been developed in the COMPLEX project (COdesign and power Management in PLatform-based design space Exploration) [5]. The project has five main stages: the system design entry, specification of the executable system, exploration and optimization, estimation and model generation, and overall system simulation [29]. The project uses a UML/MARTE model as input for the automatic generation of an executable SystemC model. In addition, to allow a fast and a unitary simulation of the complete system functional and extra-functional properties, a virtual prototype is generated. The prototype helps the designer in identifying and eliminating power peaks and performance bottlenecks. The main objective of the IMPReSS project is to provide a development platform for mixed-critical internet of things systems [6]. This platform enables the rapid and cost effective development of such systems. It also ease the interactions with the users and external systems. The focus of demonstration and evaluation of the developed platform is on energy efficiency systems (i.e. systems that target the reduction of energy usage and CO2 footprint). The IMPReSS platform aims at solving the complexity of system development through providing a holistic

approach. This approach includes an integrated development environment, middleware components, and a deployment tool. The ACTORS [7] (Adaptivity and Control of Resources in Embedded Systems) project addressed the design of complex embedded systems. This project provided an adaptive resource management during the system execution based on a feedback control loop. However, the adaptation of the entire networked embedded system is not considered in this project. DREAMS (Distributed REal-time Architecture for Mixed criticality Systems) is a project that aims at developing a crossdomain architecture and design tools for complex systems [9]. Such systems include sub-systems with different criticality that executed on networked multi-core chips. During the project, tools, model-driven techniques, architectural concepts, metamodels, virtualization technologies, validation and certification methods are developed. These tools and techniques enable the development of complex embedded systems, and enable the seamless integration of mixed-criticality to establish the system security, safety, and real-time performance [8]. To ensure safety and security of cyber-physical systems, a methodology has been proposed in the SAFURE project [10] [30]. This methodology is supported through a framework that has been developed for extending system capabilities to control concurrent effects of security threats on the system behaviour. The SAFURE project has three main goals: (1) implementing a holistic approach to ensure the safety and security of embedded systems through detecting and preventing potential attacks; (2) supporting designers and developers with analysis techniques, development tools and execution features that consider security and safety; and (3) setting the ground for the development of safe mixed-critical embedded software systems. All of the above projects aimed to support the development of safe embedded systems. However, on the one hand, some of the projects focus only on a phase of the development process (e.g. the system design, its implementation, etc.). On the other hand, the proposed development environments are provided by a set of partners, where these projects are collaborative. Thus, keeping these environments fully functioning on the long term is a difficult task, as each partner evolves its tools (techniques) separately. This raises the need for a development environment that is kept integrated and its tools evolve hand-on-hand [4]. III.

TOOL SUPPORT

In this section, we present the three development platforms that are provided by CEA LIST (i.e. Papyrus [11], Frama-C [12], and UNISIM-VP [13]). These platforms will be used in the next section to support our methodology. A. Papyrus Papyrus is an open source tool that provides an integrated environment to edit the UML and SysML models. Specifically, it provides the glue around UML and SysML diagram editors and other model-driven engineering tools. It also offers support for UML and SysML profiling mechanisms [11]. Papyrus contains several editors that allow simultaneous and consistent viewing of multiple diagrams of a given model. Modifying an element in one diagram is immediately reflected into the other diagrams that display this element. Papyrus is integrated in

Eclipse as a single editor and includes a set of plugins such as Moka, Sophia, and Software Designer. In the following, we describe these plugins. Papyrus Moka: Moka is a Papyrus plugin for executing UML models [16]. It includes an execution engine complying with OMG standards that deal with the execution semantics of UML: foundational UML (fUML [15]), and Precise Semantics of Composite Structures (PSCS [31]). Moka is integrated with the debug framework of Eclipse to provide control, observation and animation facilities on models execution. The key features of Moka are: • Based on Standards: Moka provides the basic execution and debugging facilities for fUML and its extension PSCS which captures an executable subset of UML. This subset is expressive enough for modelling the structure and behavior of embedded systems that have concurrent communicating entities. • Interactive Executions: Debug and animation facilities make it possible to control execution of the models (e.g., suspend/resume executions after reaching breakpoints) as well as observing states of the executed models (e.g., emphasizing the graphical views of model elements on which execution has been suspended). • Extensible Framework: Moka can be easily extended for adding new execution semantics by extension points that enable registration of executable model libraries, or simply through extensions of the execution engine. Papyrus Sophia: For analyzing security and safety of an embedded system, Sophia is introduced as a Papyrus extension. It is based on systems that are designed with Papyrus modeler (e.g. SysML). The use of the same model for design, safety, and security analysis avoids interpretation mistakes [17]. It sets up fault trees (FT) analysis techniques, minimal cut sets, and failure modes identification and their effects on the qualitative aspects. Sophia has the following objectives: • Supporting the specification of the safety properties in the architectural model of the system. • To afford model-based engineering of safety. It enables the automatic calculation of some safety parameters. • Providing an environment for the system development in which all requirements at the same level of abstraction are compatible and parent requirements are decomposed into children requirements correctly. The requirements are then verified using a safety analysis technique. Papyrus Designer: Software designer is an extension of Papyrus [18]. Designer provides code generation for embedded real-time systems from the UML models, reverse and roundtrip code generation, and development and integration of new code generators. The code generation is performed at two different levels of abstraction: • Direct Code Generation: Using designer a system design model is automatically transformed to its corresponding code for a specific programming language (e.g. C, C++, and Java) directly. • Code Generation by Transformation Chains: In this case, the generation starts from a model that includes definition of software functions, hardware nodes, and deployment information. The latter contains a definition of instances of the components and the nodes and allocations between

them. Code generation is then performed by a sequence of transformations steps. The model transformation takes care of the platform specific aspects (e.g. communication mechanisms or thread allocation) based on the system’s non-functional properties. B. Frama-C Frama-C has been proposed as a platform for the industrial analysis of C source code [19]. It contains a kernel, analyzers as collaborating plug-ins, and the ANSI/ISO C Specification Language (ACSL) [32]. The Frama-C plugins are based on abstract interpretation, deductive verification, and concolic testing. In the following, we describe some of the plugins. • Aoraï is a plugin that aims to facilitate the verification of properties over sequences of function calls that can occur during sequential programs execution. More specifically, given an automaton describing sequences of calls that are allowed, Aoraï will generate a set of ACSL annotations that can be verified using the Evolved Value analysis (EVA) plugin to ensure that the program is conforming to the automaton. • For the analysis of multi-threaded programs, the Mthread plugin is introduced. It supports a few popular threading libraries and is based on the EVA plugin with additional built-ins to handle basic threading primitives. Mthread starts an abstract execution of the main thread, and then launches new abstract interpretations each time a thread is forked. Based on these executions, Mthread will discover shared memory locations and check for potential issues (e.g. race conditions or deadlocks). • E-ACSL is a Frama-C plug-in for automatic translation of C programs to other programs to check certain properties at runtime. These properties include absence of certain classes of undefined behaviors such as memory access violations, arithmetic overflows, and specific user-defined properties. C. UNISIM-VP UNISIM-VP provides virtual platforms and a framework to ease the development of new virtual platforms [20]. A virtual platform is a software tool, often called simulator, that mimics the behavior of an electronic system, so that software can run on it before silicon or FPGA implementation of that electronic system is available. The simulated system can include a lot of microprocessors and devices. Depending on the needed representativeness and simulator development budget, the simulator can be an instruction set simulator or a full system simulator. A full system simulator does not only execute a microprocessor instruction set (like an instruction set simulator), but also simulates buses, I/O devices, sensors, actuators. Therefore, the real application workloads and operating systems can run on them. Most of existing UNISIM virtual platforms are full system simulators. They represent the real hardware, whole operating systems (e.g. Linux and VxWorks), and unmodified software stacks (e.g. an AUTOSAR stack) where industrial applications can be executed on them. The UNISIM-VP environment is enhanced with an eclipse-based workbench to simplify the user interactions with the simulator, and to give a snapshot of the embedded system state along simulation.

IV.

PROCESS FOR SAFE SYSTEM DEVELOPMENT

An engineering methodology that system engineers need to follow for developing safe embedded software system is shown in Figure 1. It consists of four main phases: system modelling and validation, code generation and integration, static code analysis, and dynamic code analysis. System Modelling and Validation: In this phase, first, the functional requirements of a system are used for specifying the system design as a UML model [33]. The design model has the structural and behavioral aspects of the embedded system. The structural aspects can be specified using component or class diagrams, while the behavioral aspect can be captured by state machines, activity diagrams, etc. The system design model also contains the non-functional requirements of the system such as safety, timing, etc. The Papyrus modeler is used for creating and editing the system design model [11]. In addition to the UML model, a Simulink model is generated from the UML model. The idea behind this transformation step is to enable the specification of the system behavior details that are not possible to be captured by the UML diagrams such as control algorithms. The details are necessary in modeling the system’s dynamic behavior to avoid ambiguity and for supporting the model analysis. System Modelling and Validation Design Model Simulink Model

Executable Model

Code Generation Code Generation and Integration

Simulink Code

Designer

Legacy Code

Integrated Code

Static Analysis Static Analysis Low level Modules

hierarchically structured safety-critical system) by Sophia [17]. Finally, Sophia uses the ARC tool [35] to compute fault trees (FTs) from the AltaRica model and to run the qualitative FTA. Code Generation: Based on the design model (validated by simulation and analyzed for safety), a code that corresponding to the validated model is generated. In the modelling phase, we have UML and Simulink models. Thus, the code generation is performed from the two models. First, the code corresponding to the Simulink model is generated through Matlab Simulink Coder [36]. Second, the UML model is used for generating the system code together with wrappers for the generated Simulink code using Papyrus Designer [18]. Finally, to make the system fully functioning, an existing (legacy) code is integrated with the generated code through wrappers. This code generation and integration step is performed automatically. Static Code Analysis: In this phase, the integrated code produced by the code generation phase is analyzed statically to verify the system safety properties using the Frama-C platform [19]. The platform input is the generated code annotated with the safety properties. These properties are, first, generated as ACSL assertions. The code is then processed automatically by abstract interpretation of the value analysis plugin in Frama-C. The plugin computes sets of possible values for variables of the code under analysis. Based on these values, it warns the system developer about the possible run-time errors (i.e. violations of safety properties). Dynamic Code Analysis: In addition to the static analysis of the generated code, a dynamic analysis is also performed to verify properties that cannot be proven statically. To do so, the binary code is analyzed dynamically by memory fault injection and monitoring techniques. The faults are defined taking into account the system profile. The embedded code is analyzed by a virtual platform (i.e. UNISIM-VP [20]) as shown in Figure 2. First, the different fault scenarios that can occur during the real system execution are specified. Second, the faults are injected into the simulated system. Finally, the system execution is observed to ensure that it is going to correctly execute in the real situations (i.e. ensuring its reliability [20]). In case that the system does not react correctly to the injected faults (i.e. the system enters a faulty state), the simulated system is updated to cope with this fault as shown in Figure 2.

Analysed Code

Inject Fault

Faults Scenarios

Dynamic Analysis Reference

Dynamic Analysis

Safe(Validated) Code

Figure 1. Process for safe software development

Second, the UML model is turned to an executable version using fUML or PSCS [16]. Then, Papyrus Moka interprets the executable model for validating the system’s high-level model visually [34]. Third, the design model is analyzed by the safety engineers to define safety evaluation metrics that are assessed across fault tree analysis (FTA). The model components are then annotated with the possible failure behaviour specified as a set of failure modes. Later, the design model is converted into AltaRica (a formal data flow language convenient to describe

Test bench

Embedded System Simulator

Monitor and Data Analyzer

Failure?

No

Yes Update Simulated System

Figure 2 – Fault-injection and impact analysis

Silence

V.

CASE STUDIES

The three platforms used in our methodology (i.e. Papyrus, Frama-C, and UNISIM-VP) have been built and validated through use-cases of industrial and research projects such as in FP7-SafeAdapt, FUI-EQUITAS, FP7-STANCE, FSN-SESAM Grids, and CATRENE-OpenES. In the following, we describe briefly these projects and the cases studies conducted by them. A. SafeAdapt The main idea of the SafeAdapt project is to develop novel architecture concepts based on adaptation to address the need for new architecture of fully electric vehicles regarding safety, reliability and cost-efficiency [21] [37]. This architecture aims to reduce system complexity and interactions through generic, system-wide fault and adaptation handling. It also enables the extended reliability despite failures, improvements of active safety, and optimized resources. This is especially important to increase reliability and efficiency regarding design simplicity, cost, and energy consumption. In SafeAdapt, a two-step process for validating the adaptive behavior of an embedded system has been proposed (shown in Figure 3) [38]. In Step 1, a software engineer models a system that has the ability to cope with the anticipated changes (e.g. an application failure). In Step 2, the design model of the system is transformed to a real software system, which is executed on a virtual platform to check the system’s adaptive behavior.

Figure 3. Model-driven simulation of safe adaptive system

To model a safe adaptive system (i.e. Step 1), two aspects need to be captured: the system functionality and its adaptive behavior. First, for specifying the functionality, an architecture description language for the automotive domain (i.e. EASTADL [39]) is used. In EAST-ADL, the architecture is modeled at two levels of abstraction: an abstract functional model and a refinement in form of a design model. Both levels are modelled as a composite structure that contains components that interact with each other through functional ports. Second, to model the

adaptive behavior of the system, the state machine approach is adopted [40]. This technique makes adaptation policies easy to understand and is also useful for validation and verification purposes. In this machine, the states are corresponding to the system configurations, and the transitions represent adaptations between these configurations. To validate the adaptive behavior of a system (i.e. Step 2), the system models are transformed to a software system which is then executed on a virtual platform to observe its behavior. First, the functional model is used as a blueprint for generating the implementation of the system functionality (i.e. an empty skeleton for each function is generated). In addition, to adapt the system in response to runtime changes, the system adaptive behavior model is translated to a code for managing the system while it is in operation (i.e. the system management). Second, to ensure that the system is behaving correctly at runtime, the system adaptive behavior is analyzed using a simulation-based fault injection approach. The embedded code is executed using the UNISIM-VP. The different anticipated adaptation scenarios that can occur while the system in operation are simulated. The system is observed to ensure its correct execution. In addition, faults are injected into the simulated system and their reactions are observed to check the system reliability. B. EQUITAS The EQUITAS (Enhanced Quality Using Intensive Test Analysis on Simulators) project aims for limiting the impact of software verification and validation on the cost and time-tomarket of embedded systems while improving their reliability and functional safety. The project has the following activities: (1) developing a tool-chain for automating the verification and validation process of an embedded software stack in the context of automotive systems; (2) improving the relevance of test campaigns by detecting redundant tests using equivalence classes; (3) providing assistance for the hardware failure effect analysis (FMEA) by introducing a hardware fault model during simulation; (4) assessment of the tool chain by automotive use cases to extract a comprehensive validation methodology using virtual platforms; (5) assessment of the tool-chain under the ISO 26262 requirements. As part of EQUITAS, an approach for fault injection has been introduced (shown in Figure 4) [20]. It takes as inputs: an application, system requirements, and a target hardware. The following services have been also defined and implemented in the simulation environment UNISIM-VP [20]: • Fault Quantification. A physical model of the fault is defined through studying the architectural features of the target hardware and a number of parameters (phenomena) associated with it. This model calculates the probability of the fault occurrence. • Fault Injection. Once the fault model is defined, the test scenarios base is instrumented in order to fix the relevant injection points for the current use case. These injection points serve as triggers during the scenario execution to inject hardware faults. • Traces Analysis. Two timestamped traces are generated as simulation results: instructions trace, and monitored data trace. These traces are compared with the functional

traces (without fault injection). The result is used as data support during reliability quantification. • Reliability Quantifier. The goal is to determine the level of robustness by analyzing the effects of the injected fault and its occurrence probability. This level is used to take corrective decisions or to compute the failure rate (i.e. mean time between failures) when a system failure occurs as a consequence of the injected fault.

timing aspects. The time-related information specified in a model is interpreted in connection with the control entity. D. STANCE To verify complex software systems written in C, C++ and Java, the STANCE project defined, implemented and validated a number of program analysis tools [42]. The project is built on existing assets: formal methods, static and dynamic program analysis tools, and industry-specific knowledge. The tools for programs analysis and the developed methods have increased the trustworthiness and the cost-effectiveness of the existing development processes. In the STANCE project, the Frama-C platform has been extended for verifying the safety and security properties of the medium-critical systems [12]. The extensions are performed in the context of the Evolved Value analysis (EVA) plugin. During the project, the different Frama-C plugins have been also validated through three industrial use cases. E. SESAM Grids The SESAM Grids is a research and development project whose objective is to ensure safe operation of intelligent power grids [23]. Thus, reliability of an electricity grid is guaranteed. It also aimed to develop a safety standard dedicated to smart grids based on IEC 61508. To protect strategic energy sites and infrastructure from cyber-attacks, a design model is created to study data exchange between the grid sub-systems. The attacks are then simulated on this grid model to test system reactions and to propose points of improvement to reinforce the safety and security of the grid.

Figure 4. Hardware fault injection in design and test flow

Unlike existing approaches, a fault is not inject arbitrarily, but the choice of determinism is made through two steps. First, the probability of the hardware fault occurrence is computed depending on the hardware characteristics and aging of the embedded system. Second, the fault injection is driven by a test scenario and hence enables choosing the study scope. C. OpenES For providing missing links at the system level design and for developing common and extensible solutions, the OpenES project has been conducted [24]. It aimed at improving the electronics system design productivity and quality. To provide a co-operation between system blocks providers, and system integrator, an appropriate design framework and interfaces are developed. The project also addressed the system modelling, specification, integration, packaging, code generation from the abstract models, and the validation/verification based on virtual prototyping platforms. In OpenES, Papyrus Moka is used to interpret the system specification designed as an executable UML/SysML model. In this project, Moka has been improved with a functionality to execute component-based design while considering the timing requirements [41]. To consider timing aspects, a control entity (a scheduler-like) is developed. This entity schedules the execution of the various model elements in order to reflect the

In the SESAM Grids project, Papyrus Sophia has been enhanced to enable the risk analysis of a grid system. The risk analysis is performed in six steps [43]. First, an architecture of the system is designed. Second, EBIOS (Expression of Needs and Identification of Security Objectives) analysis is applied [44]. Third, feared events that have residual risk levels higher than a threshold (fixed in the system design) are automatically retrieved. Forth, an attack tree is generated for each event. The feared event is the top OR node of the tree. Threats that lead to the feared event are the OR node’s children. Each threat can exploit one or several vulnerabilities which are the leave nodes related to this threat. Fifth, attack trees are completed either by adding new nodes or specifying parameters for existing nodes. Finally, the indices are computed and the countermeasures are proposed to minimize indices higher than the threshold. VI. WORK IN PROGRESS To realize the methodology introduced in Section IV, in the previous sections, we have discussed the state of our tools and how they are used in a number of research projects. However, there still some missing components that need to be developed to fully realize our proposed methodology. These components include: executable model generation, bridge between UML and Simulink models, and generation of ACSL assertions from the system design model. A. Executable Model Generation To validate an embedded software system using simulation, an executable system model needs to be specified following an action language. But, the creation of the executable model is a

difficult task, because the UML primitives intended for model execution are too low level. To ease this task, Papyrus Moka generates executable models from the high level UML models automatically. Currently, Moka supports the execution of state machines and activity diagrams, and as a work in progress, the execution of sequence diagrams will be supported [41]. B. UML and Simulink Models Bridge To enable the co-modeling between UML and Simulink, we are building a dual-transformation between the two platforms: Papyrus and Matlab/Simulink. This bridge provides round-trip engineering capabilities. In a collaborative workflow between software and control engineers, it enables integration of UML models (that represent the system) with state flow models of Simulink (that specify control functionalities of the software system). As models evolve, the bridge includes incremental ondemand synchronization to maintain the consistency between the two models. C. Generation of ACSL Assertions Currently, to perform the static code analysis using FramaC, an expert should write the safety properties of the system as ACSL assertions. In the future, we plan to provide an easy-touse approach for specifying these assertions (safety properties) at the UML level. In addition, to ease the static analysis task, we will support the generation of the ACSL assertions from the UML model during the code generation and integration step. VII. CONCLUSION AND FUTURE WORK It is largely recognized that the architectures of embedded systems are getting more and more complex both at hardware and software levels. In this paper, we have proposed a modeldriven methodology for developing safe embedded systems by three coherent open-source platforms: Papyrus, Frama-C, and UNISIM-VP. The methodology has four main phases: system modelling and validation, code generation and integration, static code analysis, and dynamic code analysis. First, the requirements of a system are used to specify its design using Papyrus Modeler. In addition, in order to specify the system continues behavior such as its control algorithms, the system design model is transformed to a Simulink model. Furthermore, the system model is transformed to an executable model for the validation by Papyrus Moka, and is analyzed for safety by Papyrus Sophia. Second, based on the system design model, the code corresponding to the system is generated and integrated through Papyrus Designer. Third, using Frama-C, the integrated code is analyzed statically to verify the safety critical properties. Forth, the UNISIM-VP is used for dynamic code analysis to detect errors that cannot be detected statically. To show the applicability of our methodology, a number of industrial and research projects use-cases have been discussed. These uses cases show how each phase of the methodology is realized by the existing platforms. As future work, firstly, we are planning to develop missing components such as an executable model generator, a bridge between UML and Simulink models, and an ACSL assertions generator. Secondly, further evaluations will be carried to assess the applicability of our methodology by fully applying it to a number of industrial case studies.

PROJECTS FUNDING In this paper, we have presented a number of use cases that are done in industrial and research projects. In the following, we present the funding organizations for these projects: • The SafeAdapt project was funded by the European Commission within the 7th Framework Program under the grant number “608945”. • The STANCE project was also funded by the European Commission under the ICT theme of the 7th Framework Program with the grant agreement number “317753”. • The OpenES project was funded under the CATRENE Program with the agreement number “CA703–2013”. • The EQUITAS project was funded by Bpifrance under call FUI-AAP16 with a contract number “F1312031-Q”. • The SESAM Grids is a “Programme d’Investissement d’Avenir” project funded by “FSN-Briques Génériques du Logiciel Embarqué N°3” with contract number “O1483067155”. REFERENCES [1] U. Abelein, H. Lochner, D. Hahn, and S. Straube, "Complexity, quality and robustness - the challenges of tomorrow's automotive electronics," in Design, Automation, Test in Europe (DATE ), Dresden, Germany, 2012, pp. 870-871. [2] A. Hava, J. Qin, J. B. Bernstein, and Y. Bot, "Integrated circuit reliability prediction based on physics-of-failure models in conjunction with field study," in Proceedings of Reliability and Maintainability Symposium (RAMS), Orlando, FL, USA, 2013, pp. 16. [3] P. Queiroz, and R. Braga, "Development of Critical Embedded Systems Using Model-Driven and Product Lines Techniques: A Systematic Review," in Eighth Brazilian Symposium on Software Components, Architectures and Reuse (SBCARS), 2014, pp. 74-83. [4] (2017, April) Horizon 2020: ICT-05-2017: Customised and low energy computing. [Online]. http://ec.europa.eu/research/participants/data/ref/h2020/wp/2016_201 7/main/h2020-wp1617-leit-ict_v1.0_en.pdf [5] K. Grüttner, P. Hartmann, K. Hylla, S. Rosinger, W. Nebel, F. Herrera, E. Villar, C. Brandolese, W. Fornaciari, G. Palermo, C. Ykman-Couvreur, D. Quaglia, F. Ferrero, and F. Valencia., "The COMPLEX reference framework or HW/SW co-design and power management supporting platform-based design-space exploration," Microprocessors and Microsystems, vol. 37, pp. 966-980, 2013. [6] (2017, April) The IMPReSS http://impressproject.eu/news.php

project.

[Online].

[7] ACTORS: Adaptivity and Control of Resources in Embedded Systems. [Online]. http://cordis.europa.eu/project/rcn/85458_en.html [8] G. Durrieu, G. Fohler, G. Gala, S. Girbal, D. Perez, E. Noulard, C. Pagetti, and S. Perez, "DREAMS about reconfiguration and adaptation in avionics," in Proceedings of the 7th Conference on Embedded Real Time Software and Systems (ERTS’16), 2016. [9] (2017, April) The Dreams Project. [Online]. http://www.dreamsproject.eu/ [10] (2017, April) The Safure Project. [Online]. https://safure.eu/ [11] S. Gérard, C. Dumoulin, P. Tessier, and B. Selic, "Papyrus: a UML2 tool for domain-specific language modeling," in International Dagstuhl conference on Model-based engineering of embedded realtime systems (MBEERTS'07), Berlin, Heidelberg, 2007, pp. 361-368. [12] O. Chebaro, P. Cuoq, N. Kosmatov, B. Marre, A. Pacalet, N. Williams, and B. Yakobowski, "Behind the scenes in SANTE: a

combination of static and dynamic analyses," Autom. Softw. Eng., vol. 21, no. 1, pp. 107-143, 2014. [13] D. August, J. Chang, S. Girbal, D. Gracia-Perez, G. Mouchard, D. Penry, O. Temam, and N. Vachharajani, "UNISIM: An Open Simulation Environment and Library for Complex Architecture Design and Collaborative Development," Computer Architecture Letters, vol. 6, no. 2, pp. 45-48, 2007. [14] UNISIM Virtual vp.org/site/index.html

Platforms.

[Online].

http://unisim-

[15] fUML. [Online]. http://www.omg.org/spec/FUML/ [16] J. Tatibouet, A. Cuccuru, S. Gérard, and F. Terrier, "Towards a Systematic, Tool-Independent Methodology for Defining the Execution Semantics of UML Profiles with fUML," in International Conference on Model-Driven Engineering and Software Development (MODELSWARD), 2014, pp. 182-192. [17] N. Yakymets, S. Dhouib, H. Jaber, and A. Lanusse, "Model-Driven Safety Assessment of Robotic Systems," in IEEE/RSJ International Conference on Intelligent Robots and Systems, IROS’2013, Tokyo, Japan, November 3-7, 2013, pp. 1137-1142. [18] W. Chehade, A. Radermacher, F. Terrier, B. Selic, and S. Gerard, "A model-driven framework for the development of portable real-time embedded systems. ," in International Conference on Engineering of Complex Computer Systems, 2011, pp. 45-54. [19] P. Cuoq, F. Kirchner, N. Kosmatov, V. Prevosto, J. Signoles, and B. Yakobowski, "Frama-C - A Software Analysis Perspective," in International Conference on Software Engineering and Formal (SEFM), LNCS 7504, 2012, pp. 233-247. [20] R. Nouacer, M. Djemal, and S. Niar, "Using Virtual Platform for Reliability and Robustness Analysis of HW/SW Embedded Systems," in 1st International ESWEEK Workshop on Resiliency in Embedded Electronic Systems, In conjunction with Esweek 2015, Amsterdam, The Netherlands, 2015. [21] SafeAdapt: Safe Adaptive Software for Fully Electric Vehicles. [Online]. http://www.safeadapt.eu/ [22] R. Nouacer, M. Djemal, S. Niar, G. Mouchard, N. Rapin, J.P. Gallois, P. Fiani, F. Chastrette, T. Adriano, and B. Mac-Eachen, "Enhanced Quality Using Intensive Test and Analysis on Simulators," in 18th Euromicro Conference on Digital System Design (DSD), Funchal, Portugal, 2015, pp. 152 - 157. [23] (2017, April) SESAM Grids: Safety of Smart Grids. [Online]. http://www.sesam-grids.org [24] (2017, April) The Open ES Project. [Online]. https://ecsi.org/openes [25] M. Hussein, R. Nouacer, and A. Radermacher, "A Model-driven Approach for Validating Safe Adaptive Behaviors," in 19th Euromicro Conference on Digital Systems Design (DSD 2016), Limassol, Cyprus, August 31 – September 2, 2016, pp. 75-81. [26] R. Nouacer, M. Djemal, S. Niar, G. Mouchard, N. Rapin, J. Gallois, P. Fiani, F. Chastrette, A. Lapitre, T. Adriano, and B. MacEachen, "EQUITAS: A tool-chain for functional safety and reliability improvement in automotive systems," Microprocessors and Microsystems - Embedded Hardware Design, vol. 47, pp. 252-261, 2016. [27] S. Trujillo, A. Crespo, A. Alonso, and J. Pérez, "MultiPARTES: Multi-core partitioning and virtualization for easing the certification of mixed-criticality systems," Microprocessors and Microsystems, vol. 38, no. 8, pp. 921–932, November 2014. [28] M. Masmano, I. Ripoll, A. Crespo, and J.J. Metge, "XtratuM: a Hypervisor for Safety Critical Embedded Systems," in 11th Real-Time Linux Workshop, Dresden. Germany, 2015.

[29] F. Herrera, H. Posadas, P. Peñil, E. Villar, F. Ferrero, and R. Valencia, "An MDD Methodology for Specification of Embedded Systems and Automatic Generation of Fast Configurable and Executable Performance Models," in International Conference on Hardware/Software Codesign and System Synthesis (CODES+ISSS'2012), Tampere, Finland, October 2012, pp. 529–538. [30] S. Girbal, D. Perez, M. Faugèere, C. Pagetti, and G. Durrieu, "A Complete Toolchain for an Interference-free Deployment of Avionic Applications on Multi-core Systems," in Digital Avionics System Conference (DASC'2015), September 17-20, 2015, pp. 1-14. [31] Precise Semantics of Composite Structures (PSCS). [Online]. http://www.omg.org/spec/PSCS/1.0/ [32] P. Baudin, J.-C. Filliatre, C. Marche, B. Monate, Y. Moy, and V. Prevosto. (2017, April) ACSL: ANSI/ISO C Specification Language, version 1.12. [Online]. http://frama-c.cea.fr/acsl.html [33] M. Fowler, UML Distilled: A Brief Guide to the Standard Object Modeling Language (3 ed.). Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2003. [34] S. Guermazi, J. Tatibouet, A. Cuccuru, S. Dhouib, S. Gérard, and Ed Seidewitz, "Executable Modeling with fUML and Alf in Papyrus: Tooling and Experiments," in 1st International Workshop on Executable Modeling, MODELS, Ottawa, Canada, 2015, pp. 3-8. [35] (2017, April) ARC tool. [Online]. https://altarica.labri.fr/wp/ [36] (2017, April) Simulink Coder. [Online]. https://www.mathworks.com/products/simulink-coder.html [37] P. Schleiss, M. Zeller, G. Weiss, and D. Eilers, "SafeAdapt-Safe Adaptive Software for Fully Electric Vehicles," in 3rd Conference on Future Automotive Technology (CoFAT), Munich, Germany, 2014. [38] M. Hussein, R. Nouacer, and A. Radermacher, "Safe Adaptation of Vehicle Software Systems," Microprocessors and Microsystems, 2017 (to appear). [39] D.J. Chen, S. Gerard, H. Lonn, M.O. Reiser, D. Servat, C.J. Sjostedt, R.T. Kolagari, M. Torngren, and M. Weber P. Cuenot, "Managing Complexity of Automotive Electronics Using the EAST-ADL," in 12th IEEE International Conference on Engineering Complex Computer Systems (ICECCS '07), Washington, DC, USA, 2007, pp. 353-358. [40] B. Morin, O. Barais, J.M. Jezequel, F. Fleurey, and A. Solberg, "Models@ Run.time to Support Dynamic Adaptation," Computer, vol. 42, pp. 44-51, 2009. [41] S. Guermazi, S. Dhouib, A. Cuccuru, C. Letavernier, and S. Gérard, "Integration of UML models in FMI-based co-simulation," in Proceedings of the Symposium on Theory of Modeling & Simulation (TMS-DEVS '16), San Diego, CA, USA, 2016, pp. 1-8. [42] (2017, April) The Stance Project. [Online]. http://www.stanceproject.eu/ [43] R. Abdallah, A. Motii, N. Yakymets, and A. Lanusse, "Using Model Driven Engineering to Support Multi-paradigms Security Analysis. In:," in Model-Driven Engineering and Software Development.: Springer International Publishing, 2015, pp. 278–292. [44] Secretariat General de la Defense Nationale, EBIOS: Expression of Needs and Identification of Security Objectives., 2005.

Suggest Documents