A Michael Beine

A Model-Based Reference Workflow for the Development of Safety-Critical Software

Keywords: Model-based development, Reference workflow, Safety-critical systems, Safety standard, ISO 26262, IEC 61508, DO-178B

Model-based software development is increasingly being used to develop software for electronic control units (ECUs). The automatic conversion of models into program code for ECUs plays a major role in this because it ensures efficient implementation, providing considerable savings potential and short development cycles. This paper introduces a model-based reference workflow for the development of safety-critical software conforming to relevant safety-standards such as IEC 61508 and ISO 26262. The reference workflow provides guidance for meeting the safety requirements to develop software up to and including SIL 3 and/or ASIL D. Furthermore the paper shows how such a reference workflow can help address the issue of software tool qualification.

Introduction

Model-based development and automatic code generation have become increasingly established in recent years. The automotive and aerospace industry have widely adopted and successfully deployed these methods in many different series production programs worldwide. This brought various benefits, such as a reduction in development times, improved quality due to more precise specifications, and early verification and validation by means of simulation. Model-based development is a general-purpose development approach which can be applied to a wide variety of applications. Safety-critical systems, which are largely found in aerospace applications, but also increasingly in the automotive industry, impose special additional requirements on this process. This leads to the question of how modelbased design and automatic production code generation can be applied to the development of safety-critical systems. In order to answer this question the relevant safety standards need to be consulted.

Safety Standards

Overview

Standards that apply to automotive software development are IEC 61508 [START_REF]Functional Safety of Electrical / Electronic / Programmable Electronic Safety Related Systems[END_REF] and particularly the new ISO 26262 [START_REF]Road vehicles -Functional Safety, International Organization for Standardization[END_REF]. IEC 61508 is a generic acrossthe-industries standard that encourages the derivation of industry-specific standards. It originated in the process control automation industry, and sector-specific standards were already derived for the process industry (IEC 61511), nuclear power plants (IEC 61513) and machinery (IEC 61513). The new ISO 26262, which reached ISO Draft International Standard (DIS) status in July 2009, is a derivative that is especially tailored to the automotive industry. The US standard for developing airborne software is RTCA DO-178B; the European equivalent is ED-12B. IEC 61508 and DO-178B were published and revised during the 1990s before model-based design and automatic production code generation became common development approaches. They can therefore give little direct guidance on compliance within a model-based development process. The standards have therefore to be interpreted. Aerospace industry and government experts are working on DO-178C, which will specifically address model-based development. The automotive industry now has ISO 26262.

NOTE

In the case of model-based development, the implementation model specifies the software units in conjunction with other techniques (see Table 8). and notes on software unit testing (ISO/DIS 26262-6, 9.4.4)

NOTE 2

In the case of model-based development, software unit testing may be moved to the model level using analogous structural coverage metrics for models.

NOTE 4

For model-based development, software unit testing can be carried out at the model level followed by back-to-back tests between the model and the code. The back-toback tests are used to ensure that the behavior of the models with regard to the test objectives is equivalent to the automatically generated code. Many of the proposed methods are directly recommended by the standards themselves. Figure 2 shows a rough mapping. Additionally, the reference workflow contains detailed reference tables that show how the methods and the overall workflow map to IEC 61508 and ISO 26262. The reference workflow has been approved by TÜV, an independent German certification authority. Users applying model-based development methods can directly relate to the reference workflow and demonstrate how the different aspects and methods are followed in the safety-critical development project. Deviations from the methods described in this reference document are allowed as long as they are justified and documented.

Model-Based Reference Workflow

Requirements Traceability

Before software development itself can start, ISO 26262 requires the planning of the activities, methods and measures used in the individual subphases of software development, always with reference to the ASIL of the system under development. One important aspect to consider already upfront is traceability of requirements.

Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards directions [START_REF] Gotel | An Analysis of the Requirements Traceability Problem[END_REF]. The goal is to track a requirement to its implementation and its tests. Requirements traceability is helpful in determining whether requirements have been fulfilled and tested. The traceability of requirements also helps ensure their completeness, by identifying requirements that are not included in the model and by identifying model parts that cannot be linked to a requirement. The latter helps prevent the modeling and implementation of unintended behavior. It also facilitates the management of requirements changes. Requirements-based development and verification are stipulated by a number of software and safety standards.

A major part of requirements traceability lies in the modeling environment, which provides the bidirectional, navigable links from external requirements management tools to the model. In order to achieve full traceability the code generator must establish the links between the model as input and the code as output. TargetLink as a code generator provides links between the model and code that also support the tracing of requirements, for example by generating C code in HTML format that includes hyperlinks to the model.

The Role of Guidelines

Another aspect to consider before software development itself can start is the selection of modeling and coding guidelines. ISO 26262-6 recommends the use of design and coding guidelines for modeling as well as programming languages. Guidelines describing good programming style and avoiding unsafe language features should be used in general, but particularly for safety-critical applications. Modeling guidelines -Modeling guidelines play an important role in ensuring good design quality as models progress from the initial function design to the implementation model. Moreover, they can help to achieve quality objectives with regard to the functional safety of the generated code. There are several well-established guideline documents for the example tool chain MATLAB, Simulink, Stateflow and TargetLink mentioned above:

The MathWorks Automotive Advisory Board guidelines (MAAB) [START_REF]Control Algorithm Modeling, Guidelines using MATLAB®, Simulink®, and Stateflow®[END_REF], a collection of rules with objectives such as increasing readability, smoothening workflows, and enabling design for verification and validation as well as for code generation TargetLink modeling guidelines [START_REF]Modeling Guidelines for MATLAB / Simulink / Stateflow and TargetLink Version 2.1[END_REF] that cover the whole range from function development to production code generation MISRA TargetLink guidelines for the application of TargetLink in the context of automatic code generation, or MISRA AC TL for short [START_REF] Misra Ac Tl | Modeling style guidelines for the application of TargetLink in the context of automatic code generation[END_REF]. At the beginning of a project the guidelines to be followed have to be defined. Guidelines from the above standard guideline documents should be selected. These can be supplemented by projectspecific guidelines, for example, special naming conventions. A record must be made of which guidelines are to be followed. Committing to guidelines is only the first step. The second is to ensureand documentthat they are being followed. Rule-based guideline checkers help to keep to the formally defined guidelines. Guideline checkers are used to ensure and document that the models used in the project comply with the modeling guidelines. They can be applied early on in projects and also allow large models to be checked efficiently. Coding guidelines -On code level, ISO 26262-6 specifically mentions MISRA C [START_REF] Misra-C | Guidelines for the use of the C Language in critical systems[END_REF] as a suitable standard for C. At the same time ISO 26262 acknowledges that guidelines for automatically generated code and manual code can be different, and MISRA itself specifically permits deviations from the standard as long as they are well justified. A comprehensive compliance document for TargetLink is available as a supplement to the MISRA C guidelines. This document describes in detail whether a rule is always met, whether a rule is met only if certain conditions are observed on model level, whether the code generator can be configured in order to comply with a rule, or whether a rule is only partially fulfilled if it contains multiple code requirements.

To demonstrate compliance on the code level in a similar way to the model level, standard commercial off-the-shelf MISRA C compliance checker tools can be used. Those tools check not only the resulting generated C code itself, but also any legacy or handwritten code that is part of the model. When static checking is performed on the generated code, detected violations have to be compared to the known and accepted violations of the code generator.

Software Architecture Design

The software architecture design needs to consider design principles such as modularity and encapsulation, low complexity and maintainability, and must be suitable for subsequent software unit design and implementation. Modeling environments such as Simulink support the hierarchical, modular partitioning of models. Tools for measuring model complexity on system and subsystem level provide further help in achieving suitable module sizes. Code generators such as TargetLink allow modularization on code level by giving the user various means to configure whether model parts should be realized as separate functions, separate C code files, etc. Incremental code generation allows even smaller parts of the model to be coded separately with the benefit that changes in other parts of the model do not affect incrementally generated code that has already been verified. The elements described in the reference workflow are intended to support modular development and facilitate the verification of model parts and the code generated from them. The basics of model and code verification are not changed by applying these software architecture considerations.

Model-Based Testing

The test process accompanying the model-based development processalso referred to as modelbased testingbenefits from the existence of an executable model and the simulation capabilities of the modeling environment. Systematic use of those simulation capabilities enables developers to perform fast, simple checks on the results obtained and on the modifications and adjustments made during the development process. Viewing the reference workflow from a testing and verification perspective, the first significant activity is to verify the model by demonstrating that it is correct, meets its requirements and does not contain unintended functionality. Model verification is mainly done via simulation by performing functional, requirements-based tests. Test cases that cover all functional requirements have to be derived and executed. Another option would be to apply formal verification techniques. The second significant step following model verification is to verify the generated code by demonstrating that the behavior of the code running on the ECU correctly implements the behavior of the verified model and does not contain any unintended functionality. This step ensures that converting models into program code by means of automatic code generation preserves its behavior and does not introduce any errors. A valid method to demonstrate this is performing back-to-back tests between the simulation model and the generated code. Back-to-back testing means testing the model and then testing the software using the same test cases and scenarios on model and code level, and comparing the results. All tests derived to verify the model, the test cases specified to cover the functional requirements and the test cases to demonstrate structural coverage must be used in back-to-back testing. The test stimuli are first applied to the model (MIL simulation). The results obtained serve as the reference. Then the same test stimuli are used to execute the object code derived from the generated code. The results of this execution are compared to the reference results obtained during model simulation.

Software Tool Qualification

All relevant international functional safety standards, including ISO 26262 and DO-178B, require evidence of software tool suitability and recommend the use of qualified tools. One of the first questions that are often asked when using model-based development and automatic code generation for safety-critical application development is the one about tool qualification: Is it possible to use a non-certified, non-qualified tool for the development of safety-critical software? The answer is: Yes, that is common practice in the industry today for compilers, for linkers, and also for code generators. TargetLink, for example, has been successfully used for years in several safety-critical projects in the automotive as well as in the aerospace industry [START_REF]TargetLink -Driving the Future with Autocode[END_REF].

Tool Qualification and DO-178B

RTCA DO-178B clearly states that a qualified tool is required only if there is no complete verification of the tool's output. More precisely, according to DO-178B (12.2), tool qualification has to be performed only if process steps described in DO-178B are eliminated, reduced or automated. DO-178B distinguishes between "development tools" and "verification tools". The major distinction criterion is a tool's direct impact on the software product. A development tool's output will be part of the airborne software, and therefore errors introduced by that tool introduce errors in the end product. A verification tool's output will not be part of the airborne software; however, an error in a verification tool can lead to non-detection of an error in the airborne software. In a model-based development process the controller code is produced by a code generator which is clearly in the category of "development tools". Qualification of a development tool according to DO-178B is an option that is rarely exercised since it is not practical from a managerial point of view and not easy from a technical point of view as [START_REF] Kornecki | The Qualification of Software Development Tools From the DO-178B Certification Perspective[END_REF] explains. The main advantages of using non-qualified development tools are that it is possible to use patch releases and new functionality without having to wait for the requalification of patch versions, as well as the fact that no additional tool costs (qualified tools can be significantly more expensive) and no extra tool qualification costs are associated with them [START_REF] Kornecki | The Qualification of Software Development Tools From the DO-178B Certification Perspective[END_REF]. Using a non-qualified code generator and applying a standard-compliant software verification process in order to verify the code generator output is an attractive alternative. In this case, a DO-178Bcompliant, model-based reference workflow similar to the one described in this paper is an argument in favor of using a non-qualified code generator for safety-critical software development.

Verification and validation in a model-based development process to a large part rely on automated testing. Since complete verification of the test results is not practical, the use of a qualified verification tool is advisable. In contrast to the qualification of development tools, the qualification of a software verification tool according to DO-178B is almost common practice. Qualification criteria according to DO-178B (12.2.2) are met by "demonstrating that the tool complies with its Tool Operational Requirements under normal operational conditions".

To fulfill this criterion, test suites that cover a tool's operational requirements and can be executed by the user in the context of the development project are available from tool vendors. This approach is similar to but less demanding than the validation suite approach explained below for qualification of a test tool according to ISO 26262, where the reaction of the tool under anomalous operation conditions, for example, also needs to be examined.

Tool Qualification According to ISO 26262

In contrast to IEC 61508 or RTC DO-178B, where tools are categorized by their nature and independently of their use in a concrete project, ISO 26262 introduces a new method of tool classification based on an analysis of a software tool's use case in a concrete project. First, the impact of the tool is determined by evaluating if a malfunctioning software tool and its erroneous output can lead to a violation of a safety requirement and thus to a failure of the system that affects its functional safety. Secondly, the degree of confidence that such a malfunction or erroneous output can be prevented or detected in the project is analyzed. The so-called tool confidence level is determined from the impact of the software tool and the tool error detection probability. Then the necessary tool qualification activities are derived from the tool confidence level with reference to the criticality (ASIL) of the system.

If there is a high degree of confidence that a malfunction or an erroneous output from the software tool will be prevented or detected, i.e., if there is a high tool confidence level, no additional qualification measures are required. In all other cases additional measures are required to demonstrate that the software tool fulfills its use cases with the required level of confidence. ISO 26262 suggests and details four possible methods:

Increased confidence from use

Evaluation of the development process

Validation of the software tool Development in compliance with a safety standard Qualification of a code generation tool -The tool impact of a code generator is TI1, meaning that an error might indeed cause the violation of a safety requirement. This requires the determination of the tool error detection, which depends on the development workflow ("tool use case") that is being used. At this point the model-based reference workflow introduced in this paper is very helpful. According to the TÜV, following the model-based reference workflow and its proposed verification and validation activities provides a high degree of confidence that a malfunction or erroneous output of the code generator can be prevented or detected. In this case the resulting tool confidence level is TCL1, and tool qualification for the code generator can be claimed without further tool qualification measures.

Qualification of a test tool -ISO/DIS 26262 explains that the tool confidence level of a test tool can be the same or even higher than the one of a code generation tool. This is clearly shown by the typical model-based development workflow. Since the workflow heavily relies on model-based testing for the verification of the model as well as the verification of the generated ECU program code, the use of an appropriate testing tool to support these steps is crucial. If the test tool does not work correctly and produces erroneous output, a possible code generation error might not be detected. Since there is typically no systematic verification of the results in subsequent development phases, tool error detection level TD4 has to be assumed. This results in a low level of confidence as defined by ISO 26262, thus requiring additional measures to establish a high degree of confidence in the correct behavior of the test tool.

EmbeddedTester [START_REF]EmbeddedTester[END_REF] is an example of a testing tool that has been qualified for use in safety-critical applications through a combination of validation of the software tool and evaluation of the development process, and thus is suitable up to and including ASIL D. It supports model-based testing, including back-to-back tests between model and code, as well as measuring coverage to evaluate the completeness of the tests used in the tool chain referred to in this paper.

Conclusion

Following a standard-compliant and officially approved reference workflow not only provides guidance and orientation for the user, it also helps demonstrate that the chosen development approach and applied verification and validation measures fulfill the requirements of the safety standards to ensure a sufficient and acceptable level of safety. For DO-178B projects, demonstrating that a software verification process is standard-compliant allows the use of non-qualified development tools such as a code generator. With regard to the automotive industry, the reference workflow supports tool qualification according to ISO 26262. The reference workflow serves as a detailed description of a development workflow as required by ISO 26262. for the analysis of the software tool use case in the project. In fact the TargetLink reference workflow used as an example in this paper was an important factor in the certification of TargetLink for IEC 61508 and ISO/DIS 26262 applications by TÜV SÜD, a German certification authority.

2. 2

 2 ISO 26262 and model-based development ISO 26262 addresses and specifically covers modelbased development aspects, reflecting the importance of this approach in automotive software development today. The ISO 26262 part relevant to model-based development is "Part 6: Product development: software level". It contains a separate chapter in the annex that describes the concept of model-based development of in-vehicle software and outlines its implications for product development at the software level. The annex also details differences between code-based and model-based development. There are also several notes throughout ISO/DIS 26262-6 directly referring to specifics of model-based development. For example, there are notes on software unit design and implementation (ISO/DIS 26262-6, 8.5.1):

  as compared to code-based development, additional requirements and specifics described in the relevant safety-standards have to be met when developing safety-critical software. In this situation a reference workflow can provide guidance for meeting the safety requirements of ISO 26262, IEC 61508 or RTCA DO-178B in developing software up to and including ASIL D, SIL 3 or Level A respectively. Based on best practices and experience from realworld projects, and taking into account the safety requirements from IEC 61508 and ISO 26262including the ISO 26262 notes on model-based development mentioned abovea reference workflow for the model-based development of safetycritical software has been prepared for the established tool chain MATLAB® / Simulink® / Stateflow® and TargetLink [3]. This reference workflow describes model-based development including automatic code generation and modelbased testing methods.

Figure 1 :

 1 Figure 1: Elements of the model-based reference workflow. Back-to-back testing between model and code is the key element in code verification.

Figure 1

 1 Figure1shows the general elements of processes following this reference workflow. The outline addresses design and implementation, as well as appropriate testing and verification. Textual requirements are designed and implemented in an executable model, which then is itself translated into code using code generation. Both steps are covered by guidelines. The step from textual requirements to a model ready for code generation is verified by performing model simulation and requirement-based testing, while the generated code is verified against the model by back-to-back testing, directly comparing the functional behavior of the model and code. The test execution of the model and the code includes structural coverage measurement to assess the completeness of the tests and to avoid unintended functionality. The key element of this workflow is the verification of the automatic conversion of the model into ECU program code. In order to demonstrate that the automatically generated code correctly implements the model, the generated code must be tested against the model by means of back-to-back testing.

Figure 2 :

 2 Figure 2: Elements of the reference workflow mapped to the ISO 26262-6 reference phase model for software development.

Figure 3 :

 3 Figure 3: Principle of back-to-back tests in modelbased development The resulting object code should be executed in an environment that matches as closely as possible the ECU on which the code will be deployed. The actual target compiler used in the project should be used to translate the generated code. The resulting object code should be executed on a platform, e.g., an evaluation board, which contains the processor used in the ECU. Processor-in-the-loop (PIL) simulation offers such an environment. The expressiveness of requirements-based and back-to-back testing depends on the completeness of the test cases. To evaluate the completeness of the test cases, full coverage of the requirements is necessary, and the structural coverage of the model and code needs to be measured. Portions of a model or code not covered by tests help reveal weaknesses in the completeness of the tests and detect unintended functionality in the model or code.

Glossary

MIL: Model-in-the-Loop PIL: Processor-in-the-Loop ASIL: Automotive Safety Integrity Level SIL: Safety Integrity Level ECU: Electronic Control Unit TI:

Tool impact TD:

Tool error detection TCL: Tool confidence level


S Mazzini

E Tronci

C Paccagnini

X Olive

A Model-Based methodology to support the Space System Engineering (MBSSE)

Keywords: model based, system engineering, formal verification, methodology, process

This paper presents a model based methodology that relies on the sound basis of the most recent and widespread applicable system engineering standards and model based practices, The methodology has been defined to support domain specific space system engineering standards and practices and assessed through the application on industrial case studies. A complementary formal verification approach has also been experimented.

Introduction

The use of modeling techniques at different stages of the development process is of crucial importance in order to successfully realize space complex systems.

The System and Software Functional Requirements Techniques (SSFRT) (ESA/ESTEC Contract N. 21188/08/NL/JD) was a study for the application of model based engineering technologies to support the space system-software co-engineering development processes, from mission level requirements to software implementation through model refinements. It aimed at making the software constraints present since the system analysis and avoiding any rupture during the development process.

The SSFRT study objective was to investigate how the system and software requirements processes can be modeled and interrelated with special emphasis during the early phases of a space system project, through the application of SysML and the integration of complementary and domain-specific modeling technologies.

SysML is considered a very promising system modeling language, its usage being currently encouraged both by INCOSE and NASA in their System Engineering Handbooks.

the ASSERT project constitutes a background for the SSFRT study, that intended to complement the ASSERT results at system level.

The study has resulted in the definition of the Model-Based methodology to support the Space System Engineering (MBSSE) [START_REF] Mazzini (ed | Guidelines for Model Based Space System Engineering[END_REF].

MBSSE Overview

The MBSSE methodology addresses the early phases of the system life cycle, in particular the ECSS Phases 0, A, and B, from the early definition of mission needs to the elaboration of a feasible, preliminary system definition. It was conceived with reference to the technical processes and the principles defined in the ISO/IEC 15288, the major system engineering standard providing a common process framework that can be applied as a reference for any domain to cover the life cycle of complex computer based systems. The MBSSE methodology is based upon a modelcentric definition of the system using SysML and adopts, where feasible, the model based engineering approach to integrate complementary and domain specific modeling languages. The MBSSE methodology deals with system requirements as first class citizens; they are captured, visualized and traced along the modeling process. The SysML model is the work product of the methodology, describing and justifying the requirements analysis in relation with the functional analysis and the modeling of the system structure and functional allocation. Other languages and profiles may be integrated for system analysis (Matlab, Petri Nets), to apply discipline specific techniques (e.g. Simulink), or to perform system and software co-engineering (UML, MARTE, AADL, SOC, SCADE/Esterel, HRT-UML/RCM, SDL).

The MBSSE methodology is compliant with the following ECSS standards: the ECSS-E-00 [START_REF]ECSS System, Description, Implementation and General Requirements[END_REF], which sets the basic rules and overall principles to be applied to all space engineering activities during the performance of a space project [ECSS-E-00];

the ECSS-M-10 [START_REF]Space project management, Project planning and implementation[END_REF], which defines the phases and the activities of space projects [ECSS-M-10] the ECSS-E-10 [START_REF]ECSS-E-ST-10C[END_REF], which guides organizations involved in the development of systems for space applications by specifying the system engineering requirements in relation with the system engineering functions (requirement engineering, analysis, design and configuration, verification, integration and control ) and the specific phases of space systems (0, A, B, C, D, E, F);

The ECSS-E40 [START_REF]ECSS-E-ST-40C[END_REF], which defines system and software co-engineering requirements related with software development;

The MBSSE allows you to deliver the required documents (MRD, RB, etc.) associated to the engineering activities, as specified in the ECSS-E-10, during the design process. Each activity and their related models are compliant with the mandatory documents required to support project review objectives as specified in ECSS-M-10 (MDR, PRR, SRR, PDR, etc.).

In addition the MBSSE methodology strongly relies on and integrates from the following bases:

The ISO/IEC 15288:2008 System Engineering -System Life Cycle Processes [START_REF]System engineering, System life cycle processes[END_REF] International Standard;

The ISO/IEC TR 19760 System Engineering -A guide for the application of ISO/IEC 15288 (System life cycle processes) ( [START_REF]System Engineering -A guide for the application of ISO/IEC 15288 (System life cycle processes)[END_REF]).

The INCOSE Systems Engineering Handbook [START_REF]INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities[END_REF], that provides a large guideline for system engineering with the application of the ISO/IEC 15288 standard.

The approach for the definition of the methodology is: to support space system engineering according to the ECSS standards, with emphasis on the application of the E10 for the spacecraft segment on the early phases 0, A and B, aimed at achieving a feasible system specification, to integrate with the ISO/IEC 15288 technical processes as reference processes, to adopt a model-driven solution using the SysML language, from the mission requirement capture to the model of the system feasible specification.

Rationales are the following: SysML was conceived with reference to the overall system engineering processes and principles, as defined in the ISO/IEC 15288

In particular SysML is able to cover the space system engineering processes, from high-level requirements to the architecture definition and verification.

The steps to achieve the definition of this methodology are the following:

The ISO technical processes that are relevant to the context of the methodology were identified A mapping from the ECSS-E-10 functions to the relevant ISO technical processes was identified A correspondence between the ECSS phases 0, A and B to the ISO processes was identified The relevant ISO technical processes were initially tailored/integrated, in order to completely fit in this framework.

The following figure illustrates the overall description of the methodology resulting from the above described theoretical approach. The MBSSE processes support the Phases 0, A and B of the space projects, as defined in the ECSS standards.

They are conceived to be applied iteratively across the project phases in order to reach the specified milestones. At each iteration, outputs are evaluated, refinements are identified and trade-offs between different criteria or between alternatives are analyzed and discussed with the different stakeholders and system discipline specialists; this has the purpose to produce more refined and consolidated outputs that meet stakeholder expectations in a transparent and traceable way.

The activity flow, resulting from the iterative application of the processes, will lead to the preliminary definition and validation of the system model, as well as to the definition and consolidation of the associated requirements, from the identification of mission needs down to the physical description of the system elements.

The figure 2 shows the MBSSE process across the ECSS project phases and reviews and minor and major deliveries for the reviews. As showed in figure 1, each MBSSE process is composed by activities with the following peculiarities:

MDR

Mission Requirements Definition

Each process activity may be iterated several times, in order to achieve a satisfactory outcome at each project phase.

Process activities may be exercised concurrently during each project phase.

Process activities may be exercised, and equally valid and necessary, at all levels of decomposition within the space product.

Process activities address lower levels with greater thoroughness as the project progresses.

The MBSSE processes, activities and related flows, that need to be carried out during each system phase, are defined by a tailoring of the ISO processes, activities, in order to integrate all the ECSS requirements and to be supported by means of SysML models.

The MBSSE methodology is that it extends at the system level the validity of the separation of concerns notion issued from the ASSERT project, by confirming such results at the software level.

Functions, activities and behaviors representing functional parts (function tree), are elaborated by the Analysis Function and modeled at system level separately from the non functional part, represented by the definition of the system structure, interfaces, boundaries and constraints (product tree), elaborated by the Design and Configuration Function. The two models are associated by allocation of functional parts of the function tree to the hardware/software elements of the product tree and the allocation of software components to hardware components. This enables specification of the functional behavior of software components, but also, as a consequence of the allocation to the hardware, the inference of most of the non functional properties of the software components.

Today system engineers are using the function tree implicitly. They have no use to represent it explicitly.

The "function tree" need is coming from the new technologies which can be used on-board like TSP, multi-core, …, and is required to allow a flexible allocation into the hardware.

By instance, let consider a star tracker with a hardware component (CCD sensor) and an associated function (image processing). The function can allocated to the star tracker itself (i.e. we have a smart sensor) or on the central computer (i.e. the star tracker is reduced to a CCD sensor). This tradeoff can be done at system level, only if the function tree is available and contains the "image processing" function.

Finally the function tree representation at system level allows to remove a part of the implicit thing, reducing the design risk.

Figure 3 shows an high-level view of the system engineering model, partitioned into the collection of related sub-models, each representing the outputs of one of the main areas of the space system engineering functions.

Figure 3 Model partitioning

The MBSSE methodology is based on the definition of a SSE Profile of the OMG SysML and UML, that defines a domain specific language for Space System Engineering taking into account modeling practices currently adopted in the space domain, as well as the ECSS standards.

The Case Study

The MBSSE approach has been applied by Thales Alenia Space on a real case study. The case study is related to the ExoMars mission, and covers only partially its perimeter. Both France and Italy were involved in the project. This opportunity has been used to highlight the fact that model can be exchanged. Italy has been in charge of phase 0 and A modeling. The model has then been sent to France, which has modeled the phase B part.

Phase 0 modeling has been focused on the definition of the mission requirements. Textual requirements have been modeled. Mainly table (and not graphical one) representation has been used for visualization (Figur3 4). System context has been defined by the use of SysML Block Definition Diagram (BDD). Data and/or control flows have been preliminary defined by the use flow specification. Finally use case and activity diagrams have been used to model the mission case and scenario.

Figure 4 -Requirement table

Phase A deals with the system requirements refinement. Mission requirements have been refined by using classical SysML requirement management relationship. A functional architecture has been defined based on the system requirements set. A preliminary physical architecture, called system logical architecture, is used as reference to perform some trade-off and verification analysis. This architecture can be inherited from past project, or a new one from scratch. Traceability is ensured between both architectures and requirements set. In addition, they are both compliant with the previously defined flows during phase 0. Functional architecture is refined, by the addition of sub-function. In some particular functional chain, some skeletons for analytical support can be generated. By instance, for AOCS (Attitude and Orbit Control System), each function (AOCS mode, AOCS specific function) can be mapped to a Matlab/Simulink block. It allows you to have the same design in the functional architecture and in the analytical support model. The application of MBSSE approach on a real case can be considered as successful from the methodological point of view. Nevertheless the tools are still not enough mature to edit and handle model. Some transversal functionalities like frozen a part of the model to provide it to a third party, or managing the model in a configuration management system.

System Level Formal Validation

The MBSSE methodology includes the application of model checking techniques for System Level Formal Validation.

System Level Formal Verification (SLFV) has the goal of showing that requirements for the subsystems a given system consists of are correct with respect to the (overall) system requirements. In other words, SLFV has the goal of guaranteeing that if each subsystem satisfies its own requirements then also the system built out of such subsystems will satisfy its requirements. Accordingly, SLFV can be an effective tool to support separation of concerns, since, by using SLFV, we can guarantee that the requirements for the subsystems are correct.

From the above we see that SLFV can be seen as a Validation activity (answering the question: are we building the right system?) for the subsystems and as a Verification activity (answering the question: are we building the system right?) for the overall system.

Accordingly, SLFV, together with testing and simulation, can support System Level Functional Analysis, more specifically, system level V&V. In this respect note that testing and simulation are geared towards showing presence of errors, thus they can only provide evidence for a negative answer to V&V questions. On the other hand, SLFV techniques (e.g. model checking [START_REF] Clarke | Model Checking[END_REF]) are geared towards showing absence of errors, thus SLFV provides evidence for a positive answer to V&V questions. The classes of system models handled by the above mentioned analysis techniques are also different. In fact, testing and simulation can handle quite detailed models as long as all inputs and parameters are defined. On the other hand, formal techniques can handle models with undefined parameters and inputs (e.g., modeling faults or disturbances) as long as such models have a moderate size. Thus, formal techniques can be used for a worst case analysis returning as output a worst case scenario (i.e. inputs and parameters) for the system under analysis.

The above considerations suggests using formal techniques as early as possible in the system design activities, namely: as soon as some system model (even qualitative) is available. In fact, this allows early detection of errors in system or subsystem specifications. For example, as for space software development, the above considerations suggest using formal techniques towards the end of phase A or at the beginning of phase B.

Supporting Proof Continuity with SLFV

In our framework we can use SysML to define the system structure as well as the interfaces between subsystems. This make such information widely available to system engineers. We can then use specialized languages to define subsystems behaviors or requirements. Resting on the SysML system description, SLFV can support proof continuity by using an assumeguarantee verification approach to establish a formal link between system level validation and subsystem verification. To this end we can proceed as follows. First, we assume that subsystems (software or hardware) meet their requirements and verify (using model checking techniques) that the overall system meets its system level requirements. This verification activity indeed validates the subsystems requirements since it shows that subsystem requirements are correct (i.e. we are building the right subsystems). Second, we guarantee that indeed the subsystems (software or hardware) meet their requirements. This is done by showing, for example by using model checking techniques, that the implementation of each subsystem satisfies the given specifications. Of course, depending on how the subsystem is implemented, a suitable model checker will be used. Note that, as for model checking purposes, in the system level validation activity we map requirements into formal specifications and behavioral models into formal models (for a model checker). On the other hand, when using model checking tools to link subsystems formal verification to system level validation, we map model for subsystems into formal specifications and implementations for subsystems to formal models.

Model Checkers for SLFV

When modeling for SLFV we need to model the behavior of all subsystems the system under verification consists of. For example, in a control system this means that the controller as well as the controlled system (plant) will have to be modeled. In our context the controller is often software based whereas the plant is typically a physical system. This yields a dynamical system which state can undertake continuous (e.g. temperature, voltage, current in the controlled system) as well as discrete (e.g. mode of the controller policy) changes. Such systems are known in the literature as Hybrid Systems (HSs), for example see [10]. From the above considerations follows that when choosing a model checker to support SLFV we should consider focusing on model checkers for hybrid systems.

An Example: The Battery Manager System

In the SSFRT project SLFV has been applied to a case study proposed by Thales Alenia Space France: the Battery Manager System (BMS) shown in Figure 4. The CMurphi model checker [START_REF] Alur | Automatic symbolic verification of embedded systems[END_REF][START_REF] Della Penna | Automatic verification of a turbogas control system with the murphi verifier[END_REF][START_REF] Della Penna | Exploiting transition locality in automatic verification of finite-state concurrent systems[END_REF] has been used to model BMS and to verify some given safety properties. Details are in [START_REF] Mazzini (ed | Guidelines for Model Based Space System Engineering[END_REF]. We focus our SLFV analysis on the dependency of the BMS controller (BM in Figure 4) sampling time (T, in seconds, in Table 1) from the maximum voltage available from the solar cells (VS, in Volt, in Table 1).

Figure 7 Battery Manager System (BMS) Intuitively, BM policy should be correct as long as T is not too large with respect to the speed of system dynamics. Of course, the larger T, the larger BM reaction time and the easier the design of BM since it will have more time available for computing the command to be sent to the actuators. Table 1 summarizes our findings. Column "CPU" gives the CPU time (in seconds) to complete the verification task using CMurphi. Column "SLFV Outcome" summarizes CMurphi output. 1 we see that the larger the voltage from the solar cell the smaller should be the controller sampling time. Thus, our SLFV activity effectively shows how software requirements depend on physical parameters, namely, the max solar cell voltage.

Lessons Learned

This section provides a description of the 3 main identified weak points and the 3 main strong points.

First weak point is related to the current Space engineering practice : The physical architecture appears too late. In the MBSSE methodology, the physical architecture is defined in phase B. Current habits are to have a first physical architecture in phase A. This point is not a blocking one but requires to change the way of designing and to make system engineers understand the commonality between a logical system architecture and a Finally the third weak point is about the maturity of (open-source) tools supporting SysML, so that it is still not possible to recommend a tool for specific industrial use. Main issues are about the transversal functionalities (sharing, versioning, splitting, …) and the way to deal with views, to enable the management of big-sized model.

One of the main contribution of the MBSSE methodology is to maintain the separation of concerns from systems engineering to software engineering. It is present during all phases 0, A and B. On one hand, functions, activities and behaviors representing the functional part are designed in an analysis activity; on the other hand, the non functional part is represented by the definition of system interfaces and boundaries, and then the product tree. The association between both is performed during phase B by allocating the functional part (function tree) to the non functional one (product tree).

A second improvement is about the traceability. SysML enables full traceability from phase 0 to phase B. With a restricted number of relations (mainly allocation, refine, derive), all the model elements can be linked altogether. Traceability is expressed from/to the requirements model element and can be extended to the other model elements (like software element / component).

The third main enhancement is to keep the separation between system and software engineering. System -software co-engineering activity is used to go from one world to the other one. For this activity, the system provides as inputs a set of functions/activities to develop (functional part), and a set of non functional elements. Allocation relations can be used to map system block to software components. Mapping can be one-one, none or one-n. The allocation relation introduces flexibility between system and software, and permits to have 2 different but compliant points of view of a software based system.

In complement to this specific advantages, MBSSE offers the classical ones issued from MDE approach: reuse of models, complexity coping, … .

Conclusion

There is a need for a common modeling language to improve communication and cooperation among the different space system domain disciplines, in order that they can work in an integrated way, and to realize seamless integration among the different space development phases.

The SysML language can provide an harmonization and integration models for the involved disciplines across the whole system life cycle, even if there is the need for defining a profile (such as SSE) or DSL to specialize SysML to model the entities that are handled by the Space system engineers.

Properties and behavior of system models shall be verified in the model instead of being just tested after development, in particular they can be formally verified by application of model checking techniques.

The use of models to support the system requirements engineering process was aimed at improving the system requirements allocation process towards the software requirements engineering process.

On the other side, design constraints and system requirements refinement imposed by software on the system functions realization can be easily taken into account if both processes are managed and supported by modeling techniques: System requirements may be fully traced to the software requirements. Mappings from the system modeling language to the software engineering modeling languages may be defined, according to the ASSERT approach of the separation of concerns.

Figure 5

 5 Figure 5 Functional architecture and analytical support Phase B covers the consolidated definition of the system. The requirements are refined and grouped by logical subsystems. Requirements baseline is available for each functional subsystem. The

Figure 6

 6 Figure 6 Separation of concerns

Analysis Verification Requirement Engineering Design and Configuration

	Mission Requirements	System Use Cases and	System Context
	and System Constraints	Scenarios
		Functional Analysis
	System Requirements		System Logical Architecture
		Analytical Support
	Derived System Elements	Function partition and	System Architecture
	Requirements	allocation, Trade offs
	Test Cases	by Analysis Verification	System Sw Co-engineering
	E10 Functions	Mission Requirements Definition Process	Activity/ Information Flow
	Activity/Outcome	System Requirements Analysis Process	Iteration
		Architectural Design and
		Verification Process

Phase 0 Phase A Phase B Analysis Verification Requirement Engineering Design and Configuration

	The Requirements Analysis Process, mainly
	addressing Phase A activities (derived from the
	ISO Requirement Analysis Process),
	The Architectural Design and Verification
	Process, mainly addressing Phase B activities
	(derived from the ISO Architectural Design
	Process).
	Phase	Mission Requirements and System Constraints	System Use Cases and Scenarios	System Context
	0
			Functional Analysis
	Phase	System Requirements		System Logical Architecture
	A		Analytical Support
		Derived System Elements	Function partition and	System Architecture
		Requirements	allocation, Trade offs
	Phase
	B
		Test Cases	by Analysis Verification	System Sw Co-engineering
		E10 Functions	Mission Requirements Definition Process	Activity/ Information Flow
		Activity/Outcome	System Requirements Analysis Process	Iteration
			Architectural Design and
			Verification Process
		Figure 1 The MBSSE Methodology
	Three main System Engineering Processes
	identified for the MBSSE methodology, are derived
	from the ISO processes with the purpose to
	specifically address the E10 functions and the space
	project initial phases:
		The Mission Requirements Definition Process,
		mainly addressing Phase 0 activities (derived
		from the ISO Stakeholder Requirements
		Definition Process),

Table 1 :

 1 Experimental results for BMS formal verification using CMurphi on a 2GHz Dual Core Linux Pentium PC with 2GB of RAM. From Table

Acknowledgement

We are grateful to the ESA ESTEC Project Officer Andreas Jung and Head of the TEC-SWE Division Jean-Loup Terraillon for the very useful discussions we had within the framework of the SSFRT project.


C Aussaguès

D Chabrol

V David

D Roux

N Willey

A Tournadre

M Graniou

PharOS, a multicore OS ready for safety-related automotive systems: results and future prospects

Keywords: dependability and safety, real-time systems, multi-core, automotive embedded software

Automotive electrical/electronic architectures need to perform more and more functions that are mapped onto many different electronic control units (ECU) because of their different safety levels or different application domains (body, powertrain, multimedia, etc.). Freedom of interference is required to comply with the upcoming ISO 26262 standard for mixing different ASIL levels on the same ECU and is also required to cope with the safe integration of software from different suppliers. PharOS provides dedicated software partitioning mechanisms as well as controlled and efficient resource sharing by construction, from the design to the implementation stages. The main features of PharOS, contributing to this property, are presented in this paper as well as the results on its application an industry-driven case study and associated future prospects.

Introduction

Automotive electrical/electronic architectures need to perform more and more functions that are mapped onto many different electronic control units (ECU) because they have different safety levels or different application domains (body, powertrain, multimedia, etc.). Next-generation vehicles need reduced development costs and reduced energy consumption and this can be achieved by reducing the number of embedded ECUs [START_REF] Leteinturier | Multi-Core Processors: Diving the Evolution of Automotive Electronics Architecture[END_REF]. This evolution of automotive architectures requires, firstly, ECUs with more computing power. Today microcontroller suppliers can offer multi-core architectures, where computing power is increased by adding cores rather than by over-clocking the CPU and so for the same CPU capability, this solution increases much less the power consumed. However, carmakers and automotive suppliers lack the appropriate support tools to obtain the full benefit from these new paralleled architectures without compromising safety requirements. Secondly, non-interference among different functions of "merged" ECUs must be ensured. It is required also to comply with the upcoming ISO 26262 standard and to solve the problem of mixing different ASIL levels on the same ECU. Freedom from interference is also a property required to cope with the actual way of integrating software from different suppliers in automotive industry. It calls for dedicated software partitioning mechanisms as well as controlled and efficient resource sharing. Standard approaches in automotive software architectures, like the AUTOSAR-based ones, address some of these requirements partially, such as software modularity and portability, but do not yet provide complete and proved solutions to safety aspects related to non-interference and optimal use of multi-core microcontrollers. To this aim, CEA LIST has developed, in collaboration with Delphi, PharOS, a technology for design and implementation of safe embedded realtime multi-core systems. It shares the same parallel time-triggered and safe-by-construction paradigms of the OASIS technology [START_REF] David | Safety properties ensured by the OASIS model for safety critical real time systems[END_REF] but coping with the specific automotive requirements. Such approaches allow conciliating efficient parallelism management and real-time determinism [START_REF] Halang | Measuring the Performance of Real-Time Systems[END_REF]. PharOS provides safety-assisted real-time design, temporal & spatial partitioning mechanisms and dual-core support, optimized in terms of memory footprint and computing performance required by the highly-constrained automotive environment. The icing on the cake is that PharOS can effectively reduce the development cost by simplifying the validation of components and limiting the need of global system revalidation. This paper will present on one hand the main features of PharOS easing the design and implementation of safe-by-construction and highly available embedded real-time systems and on the other hand the results and future perspectives in the automotive domain.

PharOS execution and protection features

A real-time system coordinates elementary activities (such as data acquisitions/actuations from/to the environment or computations) that are performed by processing units. Each elementary activity has its associated temporal constraints, which can be derived or specified explicitly: an activation rhythm (not necessarily periodic), a time interval when the activity has to be performed (i.e. an earliest start date and a deadline), and dependencies with others activities (communications, atomic requests). The coordination among all activities implies synchronization on the physical (i.e. real) time-to ensure the temporal coherence-and synchronization of the sequential and conditional activities. Thus, temporal distribution of different activities must be controlled and, consequently, defined by the task model. Furthermore, to allow valid offline verification (e.g. proofs, tests, etc.), the system must be deterministic. Indeed, predictability and reproducibility of software behavior in both temporal and logical domains guarantees the coherence between, offline analysis and tests, on one hand, and actual execution, on the other. To ensure such determinism, sources of asynchronism, such as scheduling (e.g. preemption), variation of the execution time, and communication delays must be taken into account at the design level in order to control interactions among tasks. Therefore, all temporal constraints on interactions must be explicitly provided by the tasks model. 2.1. Observability Principles When asynchronism is not accounted for at design level, interactions can result in out-of-date or inconsistent data being manipulated, which can lead to non-reproducible behavior or failures. Indeed, in absence of synchronization mechanisms, it is impossible to know whether production processing is complete or not. Similarly, consulted data must be consistent throughout the associated consumption processing. Furthermore, expiration rules must be provided in order to compute bounds for the size of communication buffers. An observation of a temporal variable is a couple (X,V) where X is the value of the variable and V is the formal visibility instant of this value. Communications are then based on the following principles (see Figure 1):

• A variable X is visible only from its visibility instant V.

∑ = > N i i q Q
1 is controlled at runtime, where i q is the execution time of the executed EA part and N is the total number of executed parts (preemptive system).

In the PharOS approach, the quota has no impact on application design, but is only used for monitoring and, by offline tools, to perform the CPU sizing analysis: to verify whether hardware performance is sufficient for the application requirements or not (and to compute the associated maximum CPU load). Thus, in order to ensure timeliness of elementary activities, quotas represent upper bounds of their WCET. Quota violation is therefore an error and will be managed as described in section 3.3. An execution of an agent is an infinite trace of its defining transition system. An execution defines a sequence of temporal windows (denoted W) derived from the constraints specified at design phase and such that w s T of the current temporal window w ∈ W is equal to

1 w f T - of the previous window denoted 1 w -.
The following temporal constraints can be expressed, monitored, and guaranteed by the system (see Figure 2):

• Activation delay ( A ∆ )-the minimum delay between executions of two consecutive elementary activities: at the latest, the first activity must finish before w D , whereas the second cannot start before

1 w s T + . Hence, { } W w D T A w w s ∈ - = ∆ + | min 1 .
• Jitter ( J ∆ )-the maximum delay between executions of two consecutive elementary activities: at the earliest, the first activity can finish at w s T (zero, i.e. negligible, execution time); similarly, the second must start before

1 + w D . Hence, { } W w T D J w s w ∈ - = ∆ + | max 1 .
The basic temporal constraints, such as the deadlines and sizes of temporal windows (i.e., T t -T s ), are directly incorporated in the task specification allowing to describe behaviors according to external events (e.g. received network frame) or internal (e.g. state of local variable). Therefore, each agent can adopt dynamic behaviors, periodic or not, regular or not for which all possible sequence combinations are known and incorporated in a graph (see section 3.1). Although each TT task must have an associated basic clock, all the clocks are defined globally for the application and can be used by all TT tasks for synchronization. Thus, tasks can be synchronized (see Figure 3):

• At system start (potentially with a bounded phase shift)-first of all, the global reference of the application is specified as a formal instant called inittime; then a start delay S ∆ relative to inittime is associated to each task.

It is important to observe that inittime and S ∆ need not necessarily belong to the same clock. Hence, the starting instant of a task is given by T 0 + S ∆ , where T 0 is the last formal instant on the clock of S ∆ before inittime.

• At a specified instant on any given clock. For example, the synchronization between Agent 1 and Agent 2 in , where e T is the earliest date when the event can occur, whereas f T is the termination instant unknown until the event does occur and defined by Altogether, the above parameters specify the largest acceptable workload.

Temporal communication

All communications/interactions among tasks are explicitly described at design phase and incorporate temporal aspects. The following temporal constraints can be specified and controlled:

• Age delay is the maximum delay from which the consumed or sent value (the earliest value) has been produced. • Delay before injection is the maximum delay between effective event occurrence and its processing by the system. This delay also comprises the injection of data from ET domain to the TT one. • Expedition delay is the maximum delay between data production and its delivery to the external environment. • Expiration delay is the maximum delay from which the data becomes obsolete.

All these constraints (based on the observability principles) associated with temporal behaviors of each task provide means for expression and control of end-to-end temporal constraints, i.e. maximum delay between data acquisition and associated actions.

On the basis of the communication principles presented above, PharOS provides the following communications mechanisms within the TT domain: ET <=> TT (1 agent to 1 handler, and reciprocally) define mechanisms derived from temporal variables and messages to exchange data between the two domains.

Temporal and spatial partitioning

To implement partitioning, the execution is structured in different contexts (called execution context) in PharOS:

• An application layer (compounded of different tasks), that executes the main functions (there is one applicative execution context per task), • A system layer that manages task execution control and inter-task communications (there is one system execution context per task), • A micro-kernel that manages time and task context switching (it is the only atomic execution context).

The kernel is the association of the micro-kernel and the system layer and is designed to be independent of any application. The application layer is compounded of two execution domains:

• Time-triggered (TT) tasks, where processing is activated only by time evolution, • Event-triggered (ET) tasks (also called handlers), where processing is activated on the occurrence of an associated event (Input/Output interrupt). This execution paradigm is typically required when the temporal rhythm of events is too tight to be met by TT tasks (limited hardware performance). The kernel implements generic spatial and temporal partitioning mechanisms [START_REF] Rushby | Partitioning in Avionics Architectures: Requirements[END_REF] to protect each execution context. It uses the protection runtime information (e.g. MPU descriptors, timers, temporal diagram) automatically extracted from functional and sizing constraints provided at software design phase. The protection mechanisms are configured for: earliest/nearest error detection and confinement, non-interference between application and system layers, nor between domains, nor among applications, i.e. TT and ET tasks.

Temporal partitioning

From the design step, offline analysis of the global software sizing can be performed in order to verify whether provided hardware performance is adequate to satisfy application constraints [START_REF] David | Safety properties ensured by the OASIS model for safety critical real time systems[END_REF] [START_REF] Aussaguès | Guaranteeing timeliness in safety critical real-time systems[END_REF]. The guarantee that all the tasks can meet their temporal constraints is provided for both nominal and failure contexts. For this analysis to be relevant the execution of the system must conform to the analyzed design, including the associated temporal constraints. The following errors must be detected: • Local sizing error: task execution consumes more time than expected. This error must have no impact on other tasks. • Global sizing error: a task reaches its deadline. Required CPU load is therefore greater than hardware capabilities. An increase of CPU quartz would suffice in the case of an error in the global CPU load calculation performed during offline analysis. Such operation is performed without changing the design of the application.

• Flow execution error: a task attempts to take an execution path inconsistent with its specification. In PharOS, detection of these errors is performed by monitoring the deadlines, quotas, and execution sequences for each task.

Deadline monitoring

In the TT domain, the system observes its environment and initiates processing operations at recurring, although not necessarily periodic, predetermined instants in time. Therefore, effective execution takes place between two instants-an earliest start date and a latest termination date-split potentially into several execution parts due to preemptive scheduling policy (see Figure 5). Execution support uses therefore a hardware timer to ensure EA termination at the associated deadline, otherwise an error is raised.

Figure 5. Deadline monitoring

The same-hardware timer-mechanism is used to ensure timely termination of handlers in the ET domain. The main difference is that the deadline for a handler is determined at the occurrence of its associated interrupt. 3.1.2. Execution time monitoring CPU is a shared resource for which scheduling policy determines, at every instant, which tasks can use it. Only one task can execute on a given CPU at any given moment; other tasks are waiting. It is therefore important to ensure that CPU is correctly released by the tasks. Tasks execution time is monitored in order to ensure that each task uses no more than the quota it has been assigned at design step. If a task attempts to use more time, an exception is raised by the kernel (see Figure 6). Notice that this implies that the specified execution time of each activity must be strictly positive, whether it belongs to the applicative or the system layer. Each fraction of the execution time consumed by the system layer (communication and monitoring) is attributed to the task for which the processing is performed. Observe, in particular, that a specific time margin, attributed to tasks, is reserved for the monitoring of the quotas by the micro-kernel. Similarly to deadlines, the monitoring of quotas is implemented by a hardware timer which is set when a task is executed.

Execution sequence monitoring

The temporal behavior of tasks and handlers is monitored in order to verify that it conforms to the specified one. To avoid misinterpretation by developers, the temporal model is automatically extracted from the application design and stored in a runtime table; this information supplies online verification mechanisms to check correctness of processing sequence and their associated temporal constraints. The labeled transition system describing a task encompasses its complete temporal behavior and includes all synchronization points that this task can reach. For each task, an extended representation, independent from other tasks, is obtained by unfolding this transition system and computing a temporal congruence on its states. The resulting temporal diagram (illustrated in Figure 7) is an optimized model for behavior used by the system layer to control the execution of a task. This diagram allows one to precisely place each elementary activity in a corresponding temporal window. The temporal diagram in Figure 7 illustrates a cyclic task for which temporal behavior alternates according to a conditional test. This diagram has two types of nodes: adv and upd, corresponding respectively setting and updating the temporal window of the current activity. A system call function sysCall_xxx_n(), generated separately for each transition (cf. the generated code in the right-hand side of Figure 7), passes the index of the target node of the temporal diagram to the system layer. The diagram itself is stored in readonly memory and cannot be modified. The system layer verifies whether the task can move from the current node to the target one while respecting the associated constraints thereby controlling the conformity of the execution to the design specifications.

Figure 7. Temporal behavior monitoring

In the ET domain, all useful interrupt sources are explicitly identified; other unused interrupts are disabled. Therefore, apart from timer interrupts used for time management, each interrupt must start an appropriated processing, encapsulated in a known and controlled temporal window: the interrupt must be expected. For this, minimum time interval (the shortest acceptable in terms of CPU load) between a given number of occurrences of the same interrupt must be specified at the design stage. Then, a system automaton ensures that their executions are performed according to occurrence's order of the respective events. Based on this information, support tools generate appropriate code to perform occurrence monitoring through dedicated hardware timer channel. 3.1.4. Timer implementation Timer implementation in the Time-Triggered domain of PharOS is straightforward. Indeed, one timer is sufficient for monitoring both deadlines and quotas of task activities. Hence, a hardware timer can always be used. This timer is always enabled and reset each time the execution leaves the microkernel. In the Event-Triggered domain, each handler has a specified quota used for monitoring. Hence a separate timer might be necessary for each interrupt type in order to optimize their execution time. However, timer resources may be insufficient or microcontroller performance too tight. Different implementations are possible. In the optimal case, a dedicated or shared timer can be set while ensuring time countdown coherency policy: time must only be deducted when the handler is effectively executed. In some other cases, a software mechanism must be implemented by checking whether, when handler is executed, its previous execution was already terminated or not. This can be ensured by the hardware memory protection, provided clear and explicit segmentation of the executable code: text and data sections of object files must be identified in order to clearly separate variable and constant data, and the application code. In PharOS, data naming rules are used in order to assist this identification. In addition, specific information for the backend compiler can be included in the source code to specify membership of sections. Sections can then be aggregated into uniform ones depending on the execution context:

• produced data and buffers,

• consumed data and buffers,

• functions. These sections are then placed in the memory according to the following criteria:

• Access performance of the memory support (code or data is frequently used). • Shared memory between cores when multi-core architecture is targeted, • Implicit protection provided by the memory support such as flash memory.

(indeed, such memory requires use of specific driver to distort it), • Similarity of the required memory access rights for different elements. All the above operations depend on the memory protection abilities provided by the hardware unit.

Execution support protection

Hardware execution mode mechanism is used to prevent applications from interfering with the system layer. Such mechanism authorizes execution of specific instructions and access to memory regions (through configuration of memory protection unit descriptors) only according to specific microcontroller mode. At least two execution modes must be distinguished by the hardware:

• Supervisor mode-to restrict access to the internal registers (e.g. stack pointer store/load instructions, memory management unit instructions) and peripheral device registers (INT, MPU, timers, etc.) used for the execution.

• User mode-for the application software.

System access is only possible through a unique interface: by the application, based on trap calling (automatically generated at compilation stage), and by the micro-kernel via timer interrupt to manage scheduling as illustrated in Figure 8 (SL means System layer and µN means Micro-Kernel in the following figures).

Memory access protection

A strict memory protection policy must be implemented in order to protect data and code sections against spurious read, write or/and execute attempts. This protection is essential to ensure predictable and reproducible behavior even for the degraded modes. This protection is defined with the memory protection unit (MPU), where rights associated with execution modes provided by the microprocessor are applied dynamically and swapped upon context switch to allow appropriate memory access for the enabled context, as illustrated in Figure 9 (the current task is shown on the left-hand side for each context).

Figure 9. Memory rights

Write access protection

Write access protection is the most important one. Indeed, task or system state alteration can only be confirmed by writing of data in memory or register. Applicative right accesses must therefore restrict at the necessary and sufficient need whatever protection abilities level.

Read and execution access protection

A priori, write access protection is sufficient for some safety-related purposes. However, read and execute accesses should not be restricted to increase the execution determinism, particularly in case of failure. Task should not be able to access unrelated memory area. Hence, for optimal protection, memory area consulted or executed by a context must be clearly identified. However, depending on hardware capacity, degraded protection can be used, where read access rights are extended: first for constant data and code, then for variable data. To be coherent with hardware capabilities, memory protection is highly correlated with the code and data segmentation.

Failure management

Whenever an error is detected and confined, a specific failure management policy must be applied. Based on the presented protection mechanisms, PharOS ensures that errors are detected and confined in their source execution context. The system then remains stable and continues its execution in a degraded mode. Degraded behavior is specified at design stage with the same requirements as in the nominal behavior. PharOS allows performing specific recovery procedures. 3.3.1. Degraded behavior When a faulty task is shut down upon detection and confinement of an error, other tasks can still be affected if their behaviors depend on the data produced by this task. In order to control such error propagation, PharOS provides two kinds of mechanisms to specify degraded behavior:

• Task grouping-confinement area is defined over a set of tasks. Thus, if one task fails, all tasks of the group are shut down. This is necessary when several tasks compose the same application or specification of the degraded behavior for correct tasks is impossible. • Task state broadcasting-for tasks producing real-time data flows, data extrapolation can be realized by the system to ensure data coherency. Consumer tasks are therefore notified of the state of the producer (faulty or correct) and the pertinence of data. To ensure real-time coherence of the data-state pair, the state information is broadcasted to consumers through the real-time data flow mechanisms.

Recovery policy

PharOS provides a recovery mechanism that is performed at the faulty task (or group) level without affecting the functions of the other tasks. Moreover, it is realized with temporal constraints to ensure restarting within a controlled delay. This recovery mechanism is provided by the kernel. The first step consists in reinitializing the context of the task (stacks, registers, etc.) and communication mechanisms without impacting actual consumed values. The second step consists in re-integrating tasks in scheduling lists. For this, a restart instant is computed from a delay specified over a congruent cycle, i.e. in a synchronized way consistent with the offline computed CPU load. When a task is restarted, relevant information are provided to the application level to enable choosing between the nominal behavior (executed at the system initialization and start) or a specific (degraded) one, as all behaviors, including those after a retart, are described in the design. In particular, this allows correct re-initialization of local variables.

Logging mechanisms

Safe and controlled resource sharing allows reporting the error source for later diagnostic operation. 1 For TT tasks failures, the nature of the error as well as the corresponding location in code (given by the temporal execution diagram) can be reported; for ET tasks-information about the interrupt vector. The global determinism ensured by PharOS allows enhanced error identification, and better verification and validation support during software development.

Dual-core support

The dual-core hardware architectures used for microcontrollers dedicated to automotive ECU provides intrinsic execution parallelism.

PharOS execution model

In order to optimize the allocation of the CPU time to application execution, PharOS provides an execution model based on the following two principles:

• Task execution must be interrupted only when necessary. • Ready tasks must be executed whenever possible.

The microkernel is split between cores 2 in order to perform system execution in parallel with application execution:

• The control core manages time evolution and scheduling (lists of ready and pending TT tasks). • The computing core executes TT tasks, with appropriate task context switching management, according to the list of ready tasks.

The control core is also in charge of the execution of handlers, thus avoiding any perturbation of the execution of TT tasks. Therefore, CPU time is preserved for the execution of TT tasks; no time is consumed for task's context switching and system process execution. Figure 10 illustrates the PharOS dual-core execution principle. The computing core runs TT tasks from the list of ready tasks (contexts), which is updated by the control core. Assume that two agents AG1 and AG2 are to be executed in the temporal window [T 0 , T 1 [. When AG1 terminates its elementary action the computing core switches execution to AG2. Apart from changing the task contexts (by the micro-kernel layer), this operation involves operations such as, for example, updating the list of ready tasks. In the 1 The failure reports are stored in an EEPROM. 2 These microkernel features for multi-cores are integrated into a patent. context, all these operations are performed by the same core, which implies, in particular, a number of additional context switches. The separation of control from computing reduces the number of context switches and control computations on the computing core, saving time for execution of application tasks. To summarize, the control core relieves the computing one from managing the time evolution and TT scheduling, as well as processing the interrupts from the I/O operations. Moreover no context switching is required between agents and handlers.

Programming model

The dual-core architecture underlying the system execution is completely transparent for developers, thus simplifying the design phase. In particular, no API is needed for specifying processing on the control core or mapping of tasks. Developers describe only nature of tasks, that is whether a task is Time-Triggered or Event-Triggered, and provide the associated temporal and functional constraints. The mapping is implicit and automatically determined from the design description.

Case study and results

An ECU developed for PSA Peugeot Citroen with an OSEK OS on the S12XS (Freescale microcontroller, single HC12 core) has been redeveloped partially, using PharOS on the S12XE (double core, pin to pin compatible with S12XS). The case study is a subset of an automotive application that includes: some functions for system outputs command, CAN communication bus, sensors signal measurements and voltage control. The whole application is composed of 7 TT tasks (including CAN LS driver) and 2 handlers. TT tasks have different dynamic behaviors and scales from hundreds of microseconds to several seconds, ET ones from a few microseconds to several milliseconds. Handlers indeed measure the duty cycle of a 400 Hz PWM signal and catch the signal state after a precise exclusion time with a filtering policy. CAN driver is totally integrated in the TT domain, even though the CAN frames are received in an event way The sample application that is described below covers some representative functions extracted from this automotive industrial case study. 5.1. Sample application This application includes some functions of system outputs commands, communication through a CAN LS bus and sensors signal measurements.

Figure 11. Sample application

The application consists of 6 TT tasks (including CAN LS driver) and 1 ET handler (see Figure 11 and Figure 15): AgCanRx: Reception management of CAN LowSpeed (125 kbits/s) driver. Its design is implemented to ensure by construction that there is no loss of received messages due to hardware buffer overflows and no work overload due to CAN bursts. AgCanRx has a period of 1 ms followed by a 500 µs deadline in order to ensure a maximum jitter of message extraction processing under 1.5 ms. TT tasks have different dynamic behaviors, according to internal or external state/command, and different time scales from 500 microseconds to several milliseconds.

Error injection results

To stress the error detection mechanisms and the recovery management, 3 kinds of errors were injected at AgWAF level:

• A wrong memory access (see Figure 12), to attempt distortion of a critical function such as light beams command (AgCanRx) by setting the beams to off when they must be set on.

Figure 12. Memory access error injection

• An infinite loop (see Figure 13), for example, to simulate hardware failure which diverts the exit condition of a test.

Figure 13. Quota error injection

• And interferences on interrupt occurrences (see Figure 14), to simulate interrupt burst or bad plug connector.

Figure 3

 3 is obtained by Agent 1 advancing to the fourth and Agent 2 to the second next tick on the clock C 10 .

Figure 3 . Tasks synchronization 2 . 2 . 2 .

 3222 Figure 3. Tasks synchronization 2.2.2. Event-Triggered tasks An ET task-also called a handler-runs one elementary action when an external event is raised and enables a hardware interrupt. The associated computation is executed in a growing temporal window [ [ f e T T ,

  occurrence date and o ∆ the minimum interval with at most N occurrences of the same event. Similarly to TT tasks, a quota Q (an upper bound for the WCET) can be specified for the execution time of a handler.

Figure 4 .

 4 Figure 4. ET tasks model

Figure 6 .

 6 Figure 6. Quota monitoring

3 . 2

 32 Spatial partitioning 3.2.1. Code and data partitioning An error occurring during the execution of a task should impact neither the other tasks, nor the kernel.

Figure 8 .

 8 Figure 8. Execution modes

Figure 10 .

 10 Figure 10. Dual-core execution principles

•

  An observed value of a variable X is not modifiable, neither by its producer nor by consumers.• An observed value of a variable X must remain available until a consumer can use it.Consider two communicating tasks shown in Figure1. Assume that Task 1 produces a new value for the variable X once in the interval [T 0 ,T 2 [ and once in the interval [T 2 ,T 4 [; Task 2 consults the value of X at some current date T c ∈ [T 3 ,T 5 [. As the date T c is a priori unknown, the determinism principle requires that the value of the variable X at the date T c is equal to the value that was the last one observed at the date T 3 . Similarly, this last value is given by the observation (X, T 2 ).

	Figure 2. TT tasks model	In other words, the consulted
	By default the deadline D is equal to T t or computed according to different execution paths. It can also be explicitly specified by the designer for a finer control of jitter and activation delay. The quota Q is the	value of a variable is always a past one and equal to its value at the last formal visibility date less than or equal to the earliest start date of the current time interval of the consulting task.
	maximal authorized execution duration, i.e. the	2.2. Time-and Event-Triggered Model
	inequality	PharOS is based on a Time-Triggered (TT) execution paradigm [2][5]. The system observes the
		environment and initiates its activities at some
		predetermined points of the globally synchronized
		time. For each task, its time-scale, observations, and
		interactions are defined at the design step, allowing
		a precise control at the execution of the system.
		In the automotive domain, many activities (e.g.
		signal capture) have temporal constraints with
		durations smaller than few microseconds. Hardware
		performance may not allow addressing such
		activities with Time-Triggered paradigm. Therefore,
		in addition to Time-Triggered execution, PharOS
		also extends the principles described in the previous
		section to Event-Triggered (ET) activities.
		In PharOS, the decomposition in tasks corresponds
		exactly to the processing that should be executed in
		parallel (i.e. activities that are not directly
		dependent). Moreover, a task can be defined in time-
		triggered domain or in event-triggered one. The
		design in PharOS imposes no constraint on the
		decomposition of an application in tasks, nor
		triggering domains.
		2.2.1. Time-Triggered tasks
		A TT task-also called an agent-is an autonomous
		entity defined by a deterministic labeled transition
		system, where labels represent elementary activities
		(denoted EA) representing sequential computation.
		Each EA has an associated deadline D, i.e. its latest
		end instant and a quota Q, its maximum authorized
		execution duration. An EA is executed within a
		temporal window w defined by an interval [T s ,T t [ (see
		Figure 2), where T s is the earliest start date, and T t is
		the latest termination date of the activity.
		All dates belong to a predetermined subset of ticks
		of real-time clocks defined in the system. Each clock
		is a couple (P, d), where P is the period and the d
		initial phase.
	Figure 1. Observability principles

  • AgPwmOut: Production of the duty cycle according to an external value. This process is performed only if beams command is set to on (15 ms period); otherwise AgPwmOut periodically checks for a presence of a new command (5 ms period for improved reactivity). • AgCmd: Management of the output signals for the light beams and the wiper according to the command received from CAN. • AgCanTx: Transmission management of CAN LowSpeed driver. Its design is implemented to ensure by construction that message transmission is precise and guaranteed. AgCanTx has a period of 5 ms to satisfy transmission constraints of the new values produced by AgPwmIn and AgWAF. • AgWAF: Retrieval of the fix stop position of the wiper and its communication over the CAN network via AgCanTx • itECT: ET task for measurement of a duty cycle of a 400 Hz PWM signal. Time scale (from some microseconds to 2.5 ms) required for this signal processing is too small (compared to the provided frequency range) to be treated in the TT domain. Thus, itECT extracts timers registers value (e.g. instants) noted by hardware on occurrence of rising and falling edges of the measured PWM signal (400 MHz). Then, it communicates these acquisitions to AgPwmIn by blocks of 5. System is then configured to tolerate 2 interrupts by period of 2.5 ms. • AgPwmIn: Computation of the duty cycle based on the instants provided by itECT and communication of the result over the CAN network via AgCanTx.

Figure 14. Interference error injection

In actual automotive controllers, such errors can lead to undesirable failures and, in the worst case, a loss of all functions as a result of restarting the controller. With PharOS, each error was detected and confined at the level of the task responsible for the failure (see Figure 15); the sources and nature of errors were logged in the EEPROM memory for later diagnostics. Subsequently, a recovery procedure was engaged for the faulty task in order to restart it after a specified delay of 2 seconds (see Figure 15). No other functions were disturbed during this recovery process.

Figure 15. Application temporal diagram

The development of the industrial case has established the feasibility of PharOS in an automotive real case. So, ongoing work is now focused on achieving integration between PharOS and AUTOSAR. This paves the way for a modular software architecture where components reuse and modification is easier among vehicles: software component interactions and composition can be controlled to improve cost-efficiency without making any compromise with respect to quality and safety.

Conclusions and prospects

PharOS is a solution for next-generation of automotive controllers that enables implementation of the upcoming automotive safety standard (ISO 26262). It provides a new approach for the design and implementation of embedded real-time systems fulfilling also other important automotive requirements: generic software architecture, adaptability to hardware features such as multi-core one, reuse of safety-based mechanisms, software integration from different suppliers. As it is possible to define and control different temporal behaviors and operational modes of applicative and basic software designed with the PharOS kernel and its associated code generation tool-chain, development times and costs can be improved. Moreover, it enables integration of functions with different ASIL level on a same ECU, as the embedded protection mechanisms ensure freedom from interference between them and so paves the way to future multidomain ECUs.