Introducing SCADE Model-Based Development into a Safety-Critical System Environment

With the publishing of ED-12C and ED-218, an opportunity has been created in which Model-Based Development is better defined for a Safety Critical System Environment. This positioning paper describes the approach and methodology applied to move from a conventional development, to a Model-Based Development. The major issue of how to integrate the two development methodologies is discussed.

Introduction

Since the publication of ED-12B, advances and experience have been gained in model-based development and verification, their application, and supporting tools. As the use of this technology for critical software applications in avionics has increased, there are a number of issues that need to be considered to ensure the safety and integrity goals are met. With the ED-12C [1] edition and introduction of ED-218 [START_REF]ED-218[END_REF] these issues are addressed.

For engine control systems the demand placed on the provider is that the software is produced to ED-12C Safety Critical Level A standard [1]. Section 1 of this paper considers the selection of a model-based development tool with a certified code generator which meets the requirements of ED-12C and ED-218. This removes the obligation to perform code reviews and low level testing in the Vmodel process [START_REF]ED-218[END_REF]. Section 2 discusses the integration of the candidate Model-Based Development Tool (MBDT) with the existing technology that had been used over a series of control system developments. Section 3 addresses the tooling that currently supports the existing process. This poses the question of whether to update and integrate, or to generate specific tooling to support the MBDT. Finally Section 4 is concerned with other aspects of the introduction of a Model-Based Development into projects.

Section 1 -Selection and Process for the Model-Based Development Tool

The primary criterion for selecting a Model-Based Development Tool is that there is an ED-12C qualifiable code generator that produces ADA code from a model. A mandated process under ED-12B/C is to demonstrate, using independent review and test, that the code meets the low level design. A significant amount of resource is spent doing this, however very few coding errors are made, typically 2% against 70% in requirements. Under ED-12C if the code has been produced by a qualified code generator then the demonstration is no longer required. Investigating the availability of qualifiable code generators discovered that ANSYS/Esterel Technologies [START_REF]SCADE Suite -Esterel Technologies -A Division of Ansys Corp[END_REF] markets such a product -SCADE Suite, as a member of a four part product set. SCADE Suite uses either KCG C qualifiable code generator, or a currently unqualifiable KCG ADA code generator (KCG ADA is undergoing a process which is expected to complete in 2015 which will result in a qualifiable version). Further investigation showed that there are no qualifiable ADA code generators available. SCADE Suite comes with a large set of utilities; however these are not qualifiable for reasons other than technology. SCADE Suite has a significant user base and, since Esterel Technology became part of ANSYS, the tool is expected to be available to support development over the life time of an engine.

A gated process to introduce a SCADE design process into the company was enacted. This not only examined all aspects of using SCADE for designing and modelling engine behaviour, but the business case as well. Part of the process is to have prototype and pilot projects to demonstrate that the SCADE methodology and tooling is robust and complete. An important part of the process is training, so a SCADE Tutorial was written for use in-house to be led by an internal tutor. The SCADE Tutorial emphasises the particular aspect of designs that are commonly used on projects. The training covered both design and model test coverage features of SCADE and is used in conjunction with the SCADE Suite examples and documentation.

Three 'Golden Examples' or exemplars, were developed by a trained implementation team using a previously implemented set of High Level Requirements (HLRs). They modelled a scheduler, a signal validation scheme and an engine status state machine. They were analysed against the original developments to validate the artefacts produced and compare metrics. The SCADE process identified a problem in a requirement specification which was corrected immediately. In the original implementation the problem had gone through a full development cycle before being identified and corrected. The full SCADE package was then exercised in a pilot project. A team of four engineers from a sister company were trained using our internally developed training material 'The SCADE Tutorial', and then given the same 'Golden Example' requirements to design and verify. This pilot team also discovered the specification problem and completed the task in a slightly longer time than the original team. Full ED-12C Level A processes were used in both cases and, because SCADE KGC ADA is not currently qualified, the code artefacts are subject to review. SCADE is now In-Service within the company and has been successfully used on three engine types for shaft break detection, air flow and lean burn components.

Section 2 -Integration of the Model-Based Development Tool and the Existing Process

The existing process uses Artisan Studio [START_REF]Acronyms SCADE -Safety Critical Application Development Environment[END_REF] for UML Modelling and development and we will always want an Artisan model to place the SCADE components into. This means that all SCADE components have to be integrated into our Fixed Priority Scheduler (FPS) for the Electronic Engine Controller (EEC). The software architecture is modelled in UML and each schedulable component in the model can only have "init" and "run" methods in each software component class. So a way had to be found to access SCADE through a single entry point so as to be able to integrate the SCADE component into the architectural model. A SCADE component stereotype allows the architecture modelling tooling to generate a SCADE/UML interface. A call is generated of the type "componentSCADE_execute" within the "component.run" method, passing a ".ctx" SCADE context object as a parameter. Also the data for the accessor methods to the boundary items between SCADE and the architecture model have to be passed as parameters, these are picked up as sensors within the SCADE package. Any test points are set up as probes and passed back through the ".ctx" SCADE context object. Having a single entry point means that requirement testing has to be behavioural testing in black box mode. Subsequently we discovered, for verification tooling and testing reasons, that multiple entry points might be preferable, if so then a "componentSCADE_execute" operation is needed for each one. However this should be carefully considered, due to the extra work involved.

Section 3 -Tooling for Two Methodologies

In the existing development environment, the processing of hand written ADA is handled by the tool and its code generator. This builds the component source file from all the architectural diagrams and the hand written code. The ADA is checked for SPARK compliance and complied by an in-house complier based on GNAT. At this point the component source files go through an ED-12C mandated review process to check that code meets design. Often the code is subjected to find and fix testing on a rig to expose and capture requirement, design and code problems. On completion of the review, the components are put into a build and undergo a test process. SCADE Suite provides a simulation and model test coverage MTC facility, thus the designer can model and simulate the design. This provides an early opportunity to discover if any problems exist in the component HLRs and, at the end of the design process, there is a high confidence in the validity of the model. After a design review the model code is transferred to the test process for testing against the HLRs.

In order to integrate SCADE Suite with the architecture model, a set of tools were developed. These are based on the work carried out in the 'Golden Examples' and the pilot activities. Previously altering the FPS was not an option, so a convention to name SCADE operations as "componentSCADE_execute" was made. The "component.run" method is designed exactly as before, but now with "componentSCADE_execute" method embedded, which passes, as a minimum, a ".ctx" SCADE context object as a parameter. The SCADE Integrator tool was developed to generate the SCADE component model according to the structure defined in the architecture model. This picks up all the Methods, Interfaces, Development Variables and Test Points in the component class and creates the SCADE Component Model. Any SPARK annotations are also generated. Data Tables are processed by a Graphical Data Loader tool which puts the data into graphical data packages in the architecture model for use by the software components. SCADE Suite operates in its own environment and holds all the type definitions in single file called "KCG_types". This is not an issue when there is a single "componentSCADE_execute" in the "component.run" method. However when there are more than one, then there is a problem with duplicated "KCG_types" files.

Another feature is that SCADE Suite creates its own variable names. For example a record structure "{delta, flt}" is named "daft_1". Understanding this algorithm is easy, however when it comes to Graphical Data with multidimensional arrays, naming proved to be impenetrable. The SCADE Code Processor tool was developed to structure/call KCG using command line arguments and to edit the graphic data files to integrate with KCG generated code files. For example each of the "KCG_types" is forced to generate as "componentSCADE_KCG_types", resolving the name space issue.

The testing tool used for the existing systems is ADATest. Our in-house Component Under Test Explorer tool (CUTE) is used to generate the necessary test cases to demonstrate coverage and robustness. The output ADATest is an ".ath" file which is executed to test the component and gather coverage from an instrumented version. CUTE was modified to access the architecture model "componentSCADE_execute" method and produce "componentSCADE.sth" files for processing by SCADE. There was no change to how CUTE was used. The SCADE Manager was developed to process the CUTE "componentSCADE.sth" files and generate ".sss" files and run SCADE MTC in command line mode. This generates coverage reports for the SCADE components.

Model-Based Systems Engineering (MBSE) is used to produce HLRs. In order to provide traceability the SCADE LifeCycle Requirements Management tool is used. This uses regular expressions to process a range of documents, including ".pdf", ".doc" and ".xls", and also has an interface to DOORS. The requirement tags are extracted from the HLRs and allocated to the SCADE operations. A rich set of views and utilities are available in the tool to make requirement tracing easy. Finally the software design document generator tool was modified to integrate the SCADE design documentation produced by SCADE Suite.

The truncated SCADE V lifecycle under ED-12C and ED-218 is given in Figure 1, the SCADE Context diagram is given in Figure 2 and the conversion of the UML Component into SCADE is given in Figure 3. The major issue was the previous decision to use the KCG ADA code generator. This is currently being "made qualifiable" and will finally eliminate the need for code reviews. Until this happens they still have to be performed to comply with ED-12B/C for certification. Against using the qualified C generator was the necessity of providing ADA/C conversion wrappers for every SCADE call. In an environment where safety is critical and Worst Case Execution Time (WCET) has to be as low as possible, the wrappers were considered to be unnecessary overhead. Another factor was the interfaces between the layers of the architecture models. As SCADE is being used initially on a refresh program, the effort of re-designing the existing systems would have been too great for the benefit obtained. So introducing SCADE and integrating with existing software has to be as robust as possible and this burden falls on the tooling effort.

Critical to the success of the project was the development of SCADE and SCADE MTC Tutorials. These are complementary to those provided by SCADE Suite. The SCADE Tutorials are concerned with generating a set of SCADE projects from nothing and exploring each set of SCADE primitives in depth. This is especially true with maps and folds, which was found to be a difficult concept to grasp.

Also the examples are tailored to meet typical types of project component.

By generating the 'Golden Examples', from a previously implemented HLR set, comparisons were able to be made between the two SCADE teams which found that there were no significant differences between the quality of the teams work or the time spent. This showed that the SCADE Tutorial and training is fit for purpose. The detection of the problem in the original HLRs helped demonstration of the value proposition of introducing the SCADE process.

A set of SCADE Utilities comparable with the existing Utilities were created. By looking across three existing projects only those which were in all three were generated. An exercise was carried to calculate the WCETs and they were compared with the existing times. The auto generated code was within 3% of the hand written code and in the binary search turned out to be faster. SCADE Suite is architected such that SCADE Utilities and project specific versions of Utilities can be deployed simultaneously. The intention is to make the SCADE Utilities product line software components once KCG ADA is qualified.

Due to the IT policy and against advice SCADE Suite was installed on a Citrix network. This proved impossible to run, and so it was installed on the local machine. This again proved to be a problem, due to SCADE Suite requiring to write logging files in its' program directory, which is against our IT policy. The solution turned out to be to run SCADE from a shortcut with the Start In parameter set to a writeable directory.

The look and feel of SCADE Suite was good, and the help system was exceptional. If anything it was over thorough, which is not often stated. The whole SCADE process took about 4 man years to achieve, and was rigorously progressed through a gated improvements process.

By using SCADE the dynamic of planning and project management is changed. The software spend is loaded upfront into the system and software interface and on into the design phase. Of course the cost of code review and low level testing is removed, but is taken up with design activity costs. As part of the ED-12C/ED-218 process there is also a need to re-execute the tests in target to show compatibility with target hardware with attached costs. When comparing SCADE development components against existing development a cost saving of about 18% was seen due to the removal of scrap and rework (S&R), where the components have been right first time. We made the benefit of S&R almost a break even cost because we knew that there were further benefits to be gained, but hard to quantify. As expertise increases other aspects of project spend will be reduced.

Another feature of using SCADE is the effect that it has on the levelling of requirements. There is a tendency to write requirements in a language that resembles pseudo code, and effectively imposes unnecessary constraints on the designers. Using SCADE diagrams to express design helps to encourage a more optimum level of high level requirements. A much greater interaction and discussion between the systems and software engineers was noticed as an evolved behaviour. From our initial experiences it is expected that further changes will occur in the way that projects are managed and resourced, which is a good thing in an environment of continuous improvement.

Conclusion

Ideally anyone wanting to use SCADE Suite should start on a new project that is not dependent on an existing system. ANSYS also provide a SCADE System product which integrates with SCADE Suite, which could have eliminated our architecture tool integration issues. However this should be compared against other vendors or indeed the merits of integrating with existing incumbent systems and processes. Since the code does not need to be inspected the selection of a specific language KCG based on source language preferences should not be an issue but where the code is to be integrated with other code the overheads of mixing languages must be considered. If SCADE Suite is to be used with existing systems then be prepared for lots of challenges. However with a robust plan, analysis, diligence and perseverance it can be achieved.

Figure 1 

 1 Figure 1 -SCADE V Life Cycle

Figure 2 -Figure 3 -

 23 Figure 2 -SCADE Context Diagram

Acknowledgements

All this would not have been possible without the expert help of Edward Anguish, Steven Blyth (Ansys), Andy Burrell, Simon Daniel, Ian Hopkins, Dr Stuart Hutchesson, Yinan Jiang, David Merrifield, Andy Rayner and Tim Roughan.

CUTE -Component Under Test Explorer

SPADE -Southampton Program Analysis Development Environment

SPARK -SPADE ADA Kernel

Authors

Dr Phil Birkin CEng MIET can be contacted at philip.birkin@controlsdata.com Duncan Brown CEng FBCS Roll-Royce Fellow can be contacted at duncan.brown@controlsdata.com


Jean-Louis Dufour

Bertrand Corruble

The Unified Model-Based Design: how not to choose between Scade 1 and Simulink 2

Keywords: Model-Based Software Engineering, Languages and Compilers, Scade, Simulink

software projects using Simulink or Scade use in fact a subset of Simulink or Scade. The 'alignment' of these two subsets gives rise to a new concept, the 'Unified MBD', interesting in two respects: on the academic side, it gives a simple semantics to our subset of Simulink, and on the industrial side, it permits at almost no cost the double-skill Scade/Simulink for software and system engineers. For the data-flow part, the unified subset is simply the 'clockless' part of the Scade/Simulink intersection. For the control-flow part, the unified subset is much more restricted, but the fundamental aspect is that it strictly conforms to a well-known paradigm called 'mode-automatas'.

The 'Unified Model-Based Design' concept

Model-Based Design ('MBD') is today a major paradigm in the engineering of critical embedded software. Here we will focus on implementation models, from which code is automatically generated. The main actor is Simulink, but for certified systems (avionics [our context is DO178 DAL A], railway, nuclear), it has to share the cake with Scade. The simplest (but fuzzy) definition of the subject of this paper, the 'Unified MBD', is the intersection of Scade and Simulink. It is an answer to two problems.

The first and principal problem is an industrial and human one. When the R&D team cannot choose between the two tools, this has unpleasant consequences. Here are the ones we want to address:

• It potentially doubles training costs, and developers have a 'cold start' at each language commutation, • the choice of the 'right' language for in-house libraries can be Cornelian, because it dictates the language for the related products.

The second design driver is simply the main limitation of each tool (in the narrow context of software engineering):

• Simulink's DNA is development, certification was handled only recently: the Simulink subset we use has no formal semantics, contrary to Scade, and the tentative formal semantics are too sophisticated to be of any use in an industrial context ( [HamonRushby2007]), • Scade's DNA is certification, ease of development is perfectible: the Scade simulation environment is suitable for unit debugging, but integration and functional debugging is better done out of the tool, contrary to the seamless environment of Simulink. This very last point is one of the two keys of Unified MBD: our wish list to Scade contains today mainly tooling points, because the Scade language has reached a good expressiveness level, almost sufficient to deal with most critical applications. To be completely clear, when we look at the C source of the application part of our critical avionics software currently under Model-Based development (the other parts are the Operating System and the Boot):

• A few percent come from manual coding, because datatypes are low-level (bitfield manipulations) or algorithms are low-level (sin, sqrt) or sequential (sorting an array, Gram-Schmidt orthogonalization),

• a few percent come from automated coding of state-machines (because our applications contains few moding and are mainly algorithmic; on cockpit or in railway, it could be very different),

• and everything else comes from automated coding of dataflow diagrams.

Independently of this dataflow/state-machine ratio (which is application-dependent), we make a different use of the dataflow features and of the state-machine features:

• almost all dataflow constructions are used: they are very similar in Scade and Simulink, are very intuitive (well readable by system engineers, this is a key point for peer reviews). This will be illustrated in the next section;

• almost none of the state-machine constructions are used: their semantics is often subtle and slightly different between Scade and Simulink, so this is directly conflicting with the first goal of Model-Based Design which is communication between engineers. This will be illustrated in the 3 rd section.

Let Now we can give the definition of the Unified MBD: it is the 'pack' formed of Simple Scade, Simple Simulink and their two syntactic translations. The two translations have been prototyped, to check the robustness of the concept (the translators are not qualified, and we don't plan to reuse certification credits). This concept can be seen as a 'simple industrial version' of the academic works [Caspi&Coll2003] and [Scaife&Coll2004]. The knowledge of what is 'useful' was the key to keep things simple, and on this subset we claim to have the first 'truly operational' semantics of Simulink, usable in an engineering context.

To be completely clear, we must emphasize two points:

• The translators are really just proofs of concepts, and are far from being industrial tools. They have been quickly developed in MATLAB3 to take advantage of its Simulink API for reading / writing / checking models (Scade models are stored in XML, for which MATLAB has also an API). • The Unified MBD is not an Esperanto (i.e. a 3 rd modeling language): it is more like a duo 'British Basic English 4 ' / 'American Basic English', and the translators mentioned above simply change some 's' into 'z' or vice-versa. Projects still use Scade or Simulink, and the Unified MBD only appears as modeling rules. In this, it can be opposed for example to Synoptic [Cortier&Coll2010], which proposes a new modeling language, but it cannot be opposed to the P project [PothonBordin2013], because the Pivot language is not a language for modeling but for communicating models between tools.

The dataflow part

Scade is not a pure data-flow language: it is a 'synchronous' data-flow language. It means that computation is not only driven by the values of the signals, but also (and firstly) by their 'clocks'. It permits compilation (pure data-flow is not really compilable, excepted in asynchronous hardware). In practice, clocks are not used, even for multi-tasking applications, and when you need to suspend an operator, you 'conditionally activate it on a value' and not on a clock: this is illustrated in the next subsection. The reason is that it is conceptually simpler for engineers (the generated code is often the same), this is to be contrasted with the hundreds of academic papers on clock-calculi that have been published in the thirty past years. This is the main characteristic of the unified data-flow: to be clockless (technically speaking, we should say 'single clock', but clockless is more meaningful). This section is structured according to the well-known equation 'Algorithms + Data Structures = Programs'.

Algorithms

The syntactic translations are in general completely obvious (this is the very reason why the Unified concept makes sense). Here is a standard cyclic counter in Scade and its translation in Simulink:

The not-completely-obvious aspects are with what Scade calls 'higher order patterns', typically the conditional activation or the map: in Scade they operate on a sub-block, whereas in Simulink they are in the sub-block (they 'qualify' it). Following the MBD motto (and long before, a famous French statesman), a small drawing is better than a long speech: here is the same counter, but with a conditional addition (to explicitly avoid overflow).

The strange block with a downwards arrow means 'either activate the sub-block '+', or return -36'. The default value -36 is part of the top-level block and not of the sub-block. The sub-block is the standard '+', which doesn't care about conditional activation or default result.

The Simulink translation looks identical, but in fact it is not:

The sub-block '_enabled__builtin_Sum' is not the standard '+': it contains an 'Enable Port' block and the default value -36 as a parameter of the output port 'z':

The translation can be improved by using the 'block parameters' mechanism of Simulink: this way, the '-36' will appear in the top-level block, but there still will be a supplementary hierarchical level compared to Scade. The translation is syntactical (and reversible), but the structure is slightly changed.

Data structures

The only subtlety is the definition of vectors and arrays.

On the one hand, Scade, like C or Ada, is completely rigorous about that:

• a scalar is not a vector of dimension 1, • a matrix is a vector of vectors, • there is a unique 'vector constructor', which construct vector from scalars, matrices from vectors, etc… (same simplicity for 'vector projector'),

• the dimension of a vector is explicitly declared, and to permit generic algorithms (dot product for example, for any dimension), symbolic dimensional parameters 'M', 'N', etc. can be used, with a subset of arithmetic. For example, the concatenation of two vectors of size 'M' and 'N' is a vector of size 'M+N'.

On the other hand, Simulink, like Matlab, tries to be user-friendly, but to make things more 'interesting', it is not user-friendly in exactly the same way that Matlab is:

• a scalar is a vector of dimension 1 (in Matlab, it is a 1*1 matrix because vectors don't exist [row and column matrices do the job]), and is often equivalent to a 1*1 matrix, • a matrix is not a vector of vectors,

• you cannot use exactly the same built-in blocks (or the same configuration of …) to construct/project vectors and matrices,

• the dimension of a vector or a matrix need not to be explicitly declared (even if it has to be statically known for code generation purposes).

The first consequence is that the Scade Simulink translation is sometimes dimensionality-dependent, but hopefully this information is contained in the Scade diagrams: the translation is still syntactic.

The second consequence is more critical: for the moment, generic vector/matrix algorithms cannot be syntactically translated from Simulink to Scade, we can only syntactically translate each instance separately. Type-checking vector/matrix generic algorithms is a complex problem (see [JoishaBanerjee2006] for MATLAB), but hopefully, academic research has always kept this subject on its radar screen. Historically, it had purely academic motivations like APL evolutions or compiler efficiency motivations for FORTRAN, but today there is a new boost driven by parallelism/many-cores, and the concept of 'shape and dimension polymorphism' is increasingly studied. Concerning our Simulink Scade translation problem, the type inference mechanism implemented in the 'Repa' package of Haskell ('Regular Parallel arrays') is not far from our needs [Keller&Coll2010].

The state-machine part

In term of 'Scade-Simulink intersection', state-machines are the exact opposite of the dataflow part: almost nothing can be unified (if you want to ensure the same look-and-feel and simple translations). In fact, as soon as you introduce hierarchy, the semantics differ. To try a simple explanation, in Simulink a sub-automaton is just a drawing artifact, whereas in Scade, a sub-automaton is a true state-machine.

Hopefully, the state-machines we use are ridiculously simple compared to the expressiveness of both state-machine formalisms, and the small intersection (non-hierarchical) makes sense. We have interesting use-cases of (one-level) hierarchy, so the subject is not closed, but for the moment the unified subsets are non-hierarchical.

The SCADE 'Unified Modeling Style'

Scade designers have pushed the dataflow/state-machine integration to the extreme, we will illustrate this on the following operator which generates two integers 'cpt' and 'cpt1' such that:

If cpt1>=0 then cpt = cpt1
The state-machine <SM1> is not an operator (the operator is the whole figure): it is just an equation (i.e. a definition of variables), at the same level than the dataflow definition of 'cpt'. It defines the two variables 'rst_cpt' and 'cpt1', and what is interesting is that 'cpt1' is defined by a dataflow INSIDE 'State2'. In fact, 'State2' is an operator, working 'part time' (in the figure it is at rest, hence the 'n/a's), which could contain itself another state-machine, etc.

The underlying paradigm is extremely clean and elegant: instead of 'state-machine' (a dataflow containing a FBY [i.e. an 1/z] is also a state-machine, after all) we should speak of 'mode-machine' (or 'variant-machine', 'schizophrenic-machine', 'Janus-machine', etc.). The difference is that a state is just a value, whereas a mode is a behavior: a mode is simply an operator implementing one particular personality of many. The first data-flow embodiment of this paradigm were the 'mode-automatas' of [MaraninchiRémond1998].

The Scade implementation of this paradigm (see [Colaço&Coll2005] or the Scade Suite documentation) is rightly called the 'Unified Modeling Style' (not to be confused with our 'Unified Model-Based Design'). And as many implementations, it is (substantially) more complex than its specification: to give an idea, let's just say that none of the three authors has ever reached the end of the Scade Language 'Tutorial' [Esterel2011], which models mainly with state-machines a descendant of Gérard Berry's stopwatch (published in [Berry1991], see also [Halbwachs1993] ; itself a descendant of Harel's wristwatch [Harel84]).

It would be too long to exhaustively enumerate all the limitations we impose on state-machines: weak/synchro/resume transitions, signals, 'last' operator, etc. In fact almost everything has been forbidden, and it is easier to explain what we kept. Let's call a state-machine 'simple' when -the states are independent operators (no 'last': no sharing between states), restarted (and not resumed: inner states are re-initialized) at each entering transition, and contain only (a subset of) built-in operators, -transitions are 'strong', i.e. their conditions are the first thing computed, then the new state is determined and executed, -transitions have no actions, no events and combinatorial conditions (no temporal operator).

So, this is a minimalist interpretation of the paradigm. To transpose the former operator into the unified subset, we have to:

-replace the default value mechanism on 'cpt1' and 'rst_cpt' by an explicit definition in every state,

-replace the two actions on transition by adequate initializations in the modes (transition actions are pushed inside the modes), -replace the 'fby' in the conditions by the elaboration of a new variable 'cpt_m1' (the 'fby' is pushed outside the state-machine).

This last paragraph is a bit technical and can be skipped; it is just an illustration of the countless subtleties that occur with state-machines, which we consider to be inacceptable in a safety-critical design. If you observe only the outputs, the two previous diagrams are indistinguishable. But if you observe also the inner signal 'rst_cpt', there is a difference: it is false in the first diagram and true in the second (look at the upper-left corner of the diagrams). It occurs only during the first cycle (the initial start or 'cold start'), and it is the reason why the first diagram is not accepted by our Scade Simulink translator (the 2 nd diagram is OK). More precisely, <SM1> in the first diagram is a state-machine, but is not a 'mode-machine', because 'State1' is not an operator: it behaves differently in the initial start (rst_cst = false) and in a warm start (a restart in the middle of a run, coming from State2; in this case rst_cst = true). In other words, State1 has an 'extra-sensory' knowledge (not given by its inputs and state) of the fact that a start is an initial one or a warm one. Again in other words, if we had to translate this in the unified subset, we would have to add a supplementary input to State1 to give him this information. We consider that it is no more a syntactical translation, but more fundamentally we consider that such a subtle semantic point is not acceptable in a safety-critical design.

Simulink: classicism

The representation of the intersection

Concerning the dataflow part, the specification of the translations is very simple, from 'drawing' to 'drawing', and the implementation is just as easy, from 'syntax tree' to 'syntax tree'.

Concerning the state-machine part, things are different, and the need for an intermediate language was felt very quickly. The classical approach is to design a third language, and we could have used the 'Pivot' language of the 'P' research project of which we are partner ( [PothonBordin2013]). But the aims of the P-project and of the Unified MBD are not the same, which explains why we have adopted another solution:

• the P-project needs a pivot language for ensuring semantic correctness of transformations of models, nobody will never directly read or write P models, • the Unified MBD needs an operational, but also simple and readable way of specifying (for human end-users) subsets of Scade or Simulink.

Our solution for the specification (and translation) of unified state-machines is a dataflow designpattern, consisting of (see also next So, when we want to incorporate a new feature of, say, Stateflow, into the Unified MBD, we don't have to check the simplicity of translation in Scade: we check the simplicity of translation in this designpattern. This is not a third language; this is a pivot design pattern inside the Unified dataflow: formal semantics of state-machines comes 'for free'.

The Standard Library, and conclusion

A common in-house 'standard' library has been defined, with basic operators like matrix computations and filters. The Scade and Simulink version share their specification and their test-cases. This way, we claim to have unified the look-and-feel of our models and to permit at almost no cost the double-skill Scade/Simulink.

  figure): • a set of states (left-bottom part of the diagram), • a pure (stateless) function 'transitions' computing the next state and the restart order (middle of the diagram), • a pure (stateless) function 'actions' using this next state and restart order to compute the output(s) (right of the diagram).

Simple Scade is syntactically included into Simulink. What

  's call 'Simple Scade' the part of Scade mentioned above (almost complete dataflow + almost nothing of state-machines). The second of the two keys of Unified MBD is that

	does it mean? It means that without any semantic
	analysis, you can structurally translate (almost box to box and wire to wire) a Scade diagram into an
	'equivalent' Simulink diagram. Equivalent is put in quotation marks because without a formal
	semantics for Simulink, it cannot be proved, but it can be verified by test (as in [Caspi&Coll2003]) or by
	expert judgement.
	Let's call 'Simple Simulink' the image of Simple Scade under the syntactic translation. Contrary to
	Simple Scade, which is a syntactic subset of Scade, checking that a Simulink model belongs to the
	Simple subset requires a semantic analysis (simple: the transposition of Scade typechecking into
	Simulink). But once you are in the Simple Simulink subset, you can again syntactically translate
	towards Simple Scade.

  State-machines in Simulink are built with a toolbox called 'Stateflow'. In terms of expression power and complexity, they are comparable to Scade, but they are 'classic' w.r.t. Harel's 'seminal synthesis'[Harel1984]: the behavior of the states is sequential code.

	The search for semantic simplicity and the intersection with Scade have led to a very reduced subset,
	for example from the most general form of transition
	'event_trigger[condition]{condition_action}/transition_action'
	we keep only

'[condition]/transition_action'

with global constraints on the transition actions in order to ensure the 'mode-machine' aspect.

ANSYS, Inc.

The MathWorks, Inc.

The MathWorks, inc.

https://en.wikipedia.org/wiki/Basic_English

The goal of this paper is to show that for critical software, the interesting subset of Scade/Simulink is not so big than that. But of course, the way forward is to continue to extend the two subsets, according to use-cases needed by development projects.


Ralf Bogusch
email: ralf.bogusch@airbus.com

Sabine Ehrich
email: sabine.ehrich@airbus.com

Roland Scherer
email: roland.scherer@airbus.com

Tobias Sorg
email: tobias.sorg@airbus.com

Robert Wöhler
email: robert.woehler@airbus.com

A Lean Systems Engineering Approach for the Development of Safety-critical Avionic Systems

Keywords: Application lifecycle management, domain ontologies, end-to-end traceability, functional analysis, lean systems engineering, model-based systems engineering, model-based testing, product family engineering, requirements patterns, requirements quality analysis, safety analysis, variants

établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

INTRODUCTION

Safety-relevant avionic systems are becoming more and more complex. Additionally, safety standards like SAE ARP4754A and RTCA DO-178C require rigorous development and assurance activities to demonstrate compliance with applicable airworthiness requirements. However, defects introduced in system specifications such as missing or unclear requirements may cause rework in the downstream activities leading to unnecessary costs. In addition, product variants sharing similar features are often developed by different teams hindering the reuse of existing solutions. Due to the strong cost pressure in the aerospace market, industry is forced to optimise their lifecycle processes and tool environments.

In order to address these challenges, we propose a Lean Systems Engineering (LSE) approach. Lean Thinking is a methodology which aims to deliver value to the customer while cutting out waste inadvertently generated by the process, see Figure 1. The lean methodology can be traced back to the success of the Toyota Production System (TPS) and Taiichi Ohno who is considered as the father of the TPS. J.P. Womack and D.T. Jones [START_REF] Womack | Lean Thinking[END_REF] published the basic principles in their book on Lean Thinking:

 Value,  Value streams,  Flow,  Pull,  Perfection.

In order to advance lean thinking in systems engineering, INCOSE has established the LSE Working Group. One significant result of this working group is a list of 194 practices and recommendations of systems engineering based on lean thinking, the so-called lean enablers [START_REF] Oppenheim | Lean for Systems Engineering with Lean Enablers for Systems Engineering[END_REF]. In this paper we refer to the following lean enablers:

Map the value stream:  Map the systems engineering value stream: have cross-functional stakeholders work together to build the agreed value stream.  Plan for frontloading: anticipate and plan to resolve as many downstream issues and risks as early as possible to prevent downstream problems. Plan early for consistent robustness and "first time right".  Plan to develop only what needs developing:

promote reuse and sharing of program assets.  Plan leading indicators and metrics to manage the program: use metrics structured to motivate the right behaviour.

Make value flow continuously along the value stream:  Clarify, derive, prioritize requirements early: use architectural methods and modelling for system representations (prototypes, models, simulations) that allow interactions with customers.  Promote smooth systems engineering flow: minimize handoffs to avoid rework.  Make program progress visible to all: make work progress visible and easy to understand to all, including external customer.  Use lean tools: use lean tools to promote the flow of information and minimize handoffs.

Pursue perfection:  Strive for excellence of systems engineering processes: build in robust quality at each step of the process, and resolve and do not pass along problems. Apply basic PDCA (Plan-Do-Check-Act) method to problem solving.  Develop perfect communication, coordination and collaboration policy across people and processes: ensure timely and efficient access to centralized data.

In the remainder of this chapter we will introduce four aims of the proposed lean systems engineering approach that allow to cover the lean enablers mentioned above.

Our first aim is to significantly improve the quality of system specifications, since reducing defects in requirements is the earliest opportunity in the lifecycle to save money [START_REF] Bogusch | Towards Automatic Quality Evaluation of Natural-Language Requirements[END_REF]. This is accomplished by the following intertwined activities:

 Perform linguistic analysis of requirements supported by domain ontologies to obtain wellformed requirements which fulfil given quality characteristics.  Conduct system modelling guided by model-based systems engineering (MBSE) best practice to ensure consistency and completeness of the requirements.  Define requirements-based test cases to guarantee verifiability of requirements.  Perform simulations of the system model and execute model-based tests to conclude the validation of the system specification.

Our second aim is to standardize the development of variants that share commonalities and promote reuse. In past projects substantial effort was spent for the development of each single variant. Thus, we introduce product family engineering practices leveraging reuse, allowing shorter time-to-market, reducing development cost, while taking into account the variability and diversity of users and customers [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF].

Our third aim is to integrate model-based system engineering with functional safety analysis and foster crossfunctional work. Thus, safety aspects are considered early in the system development process. Furthermore, the approach allows safety and system engineers sharing common artefacts. As a consequence, there is substantial potential for cost savings and quality improvements [START_REF] Binder | Towards seamless integration of functional safety and model-based systems engineering[END_REF].

Our fourth aim is to establish a tightly integrated systems engineering environment (SEE) with interoperable tools providing requirements management, requirements quality analysis, modelling, safety analysis, simulation and test capabilities. This SEE shall support end-to-end traceability across different tools, enable efficient access to lifecycle data, support team collaboration and communication, and provide visual dashboards for process measurements. The tool integration relies on the Linked Data approach [START_REF] Bizer | Linked Data -The Story so Far[END_REF] and leverages interoperability standards such as Open Services for Lifecycle Collaboration (OSLC) [START_REF]Open Services for Lifecycle Collaboration[END_REF].

In this paper, we present a demonstrator based on an open platform for lifecycle tool integration and an experimental case study which was performed by Airbus Defence and Space in the frame of the ARTEMIS Joint Undertaking research project CRYSTAL1 in order to validate the approach from an industrial point of view.

The remainder of the paper is organized as follows. Section 2 introduces the industrial case study and the envisioned SEE. Sections 3 to 9 exemplify the approach. Section 10 concludes the paper and provides an outlook to future work.

INDUSTRIAL CASE STUDY

Airbus Defence and Space develops avionic systems that support helicopter pilots in degraded visual environments (DVE) which can be caused by e.g. rain, fog, sand and snow. Many accidents can directly be attributed to such DVE where pilots often loose spatial and environmental orientation (see Figure 2 on the left side). In this case study we employ the landing symbology function which is part of the "Pilot Assistance Landing" capabilities of the situational awareness suite Sferion™. Other Sferion™ capabilities are "Pilot Assistance In-flight" or "Obstacle Warning".

The landing symbology function supports helicopter pilots during the landing approach. It enables the pilot to mark the intended landing position on ground using a head-tracked HMS/D (Helmet Mounted Sight and Display) and HOCAS (Hands on Collective and Stick). During the final landing approach the landing symbology function enhances the spatial awareness of flying crews by displaying 3D conformal visual cues on the HMS/D (see Figure 2 on the right side). Additionally, obstacles residing in the landing zone can be detected. The situational awareness suite Sferion™ constitutes a product family to be deployed on different helicopter platforms. The reuse of development assets, e.g. requirements, design or test cases, can be significantly improved by the application of product family engineering practices. In this case study we applied the product family engineering practice "Scoping". The practices "Domain Requirements Engineering" and "Domain Design" have been applied on system level to develop system requirements and the system design for the product family [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF].

The The following sections summarize the steps performed in the case study and describe the related tool chain:  Define product family scope.

 Develop system requirements.

 Analyse and improve requirements quality.

 Develop system model.

 Perform safety analysis.

 Develop and perform model-based tests.

 Create product variants.

PRODUCT FAMILY SCOPING

First, the characteristics of potential products (e.g. low-cost or high-end variants) are categorized. In the Sferion™ product family three main configurations have been identified: class 2, 3 and 4.

Then, features of the product family are identified by [START_REF] Lee | Concepts and Guidelines of Feature Modeling for Product Line Software Engineering[END_REF]:  Analysing the capability in terms of end user visible services, internal operations needed to provide the end user visible services and definition of non-functional properties, e.g. performance.

 Analysing the operational environment of the product family to define the context, e.g. external systems and interfaces.

 Analysing domain technology required to implement services or operations, e.g. development approaches or tools.

 Analysing implementation technique to indicate key design and implementation decisions used to implement other features.

Features are refined in terms of commonality and variability rather than describing all details. Common features are described on top level. Feature variations are refined until no variation is exposed among products. An initial classification of each feature is performed (e.g. feature is optional; feature is refined into a range of alternatives), see Important descriptive goals of the feature model are:  Understanding of the variability among products.

 Communication of requirements in terms of features.

 Specification of product variants.

Additionally, prescriptive goals of the feature model are important for this case study:  Guidance for the development or transformation of core assets which are in our case study the product family system requirements and product family architecture.

 Guidance for variant derivation of the system requirements and the system architecture model.

The variability modelling tool pure::variants was selected to support the prescriptive feature modelling goals. Based on the PFM, a variability model has been set up with pure::variants in order to formalize the results of the product family scoping in a feature tree, see Figure 5.

Subsequently, features, commonalities, variabilities and structural relationships have been added to the variability model.

The feature tree was manually optimized to represent variabilities and commonalities rather than functional dependencies like a function call hierarchy.

For example, the mandatory feature "Mark landing position" can be realized in two ways: either the handling pilot only or both pilots are allowed to set the landing position. All product variants provide the safety feature "FrozenImageDetection". However, the frozen image detection on "HMD" is optional. The main advantage of the feature modelling approach is that based on the feature model, validation mechanisms assure that only valid product configurations are defined.

In order to provide guidance for variant derivation it is important to add composition rules to optional and alternative features. Essential composition rules are:

 Mutual dependency relationship: features that shall be selected along with the designated one.

 Mutual exclusion relationship: features that shall not be selected along with the designated one.

For example, if "Check_Obstacles" is selected, an Obstacle Warning System (OWS) is required. In this case, one of the sensor equipments "ELOP" or "SferiSense" has to be selected.

REQUIREMENTS DEVELOPMENT

After the definition of the product family scope, a first set of system requirements covering all features of the product family and derived from stakeholder needs is defined using the requirements management tool DOORS NG. The requirement type is assigned. This enables filtering requirements according to their type, e.g. gathering all functional requirements as input for the subsequent functional analysis.

In order to support the requirement authoring activity, we use two additional tools from the Requirements Quality Suite (RQS) [START_REF]Requirements Quality Suite, The REUSE Company[END_REF]:

 Knowledge Manager (kM), which is used to create and maintain the domain ontology and requirements patterns.

 Requirements Authoring Tool (RAT), which provides on-the-fly guidance for the requirements specification activity [START_REF] Fuentes | Requirements Authoring: Towards the Concept of a Standard Requirement[END_REF].

First, we developed a domain ontology by defining terms, abbreviations, agreed-upon concepts and relations that hold in our application domain. Then, we defined requirements patterns by defining sequences of fixed syntax elements for each type of pattern to cover the relevant requirements statements [START_REF] Fraga | Knowledge-based Requirements Engineering Process: A Guided Example[END_REF]. Requirements patterns can be specified in an elementary way and then concatenated to cover more complex sentence structures, allowing keeping the number of required patterns low while at the same time having a high flexibility. The majority of the functional requirements of our case study could be covered with a few set of patterns.

Figure 6 shows how a Natural Language (NL) requirement is represented by a pattern. The pattern consists of fixed syntactic elements and variable elements. The latter are mapped to semantic concepts in the domain ontology such that the requirement can formalized by a semantic graph.

Using requirement patterns is an effective way to mitigate many types of ambiguity in NL requirements and to enable advanced formal analysis of these requirements, see Section 5. For instance, we can detect requirements formulated in passive voice or any requirement structure that is not wellformed like "It shall be possible..." which lacks an actor. The RAT tool uses the concepts of the domain ontology together with the set of pre-defined requirement patterns managed in the common asset repository to provide a list of suggestions the requirements author can directly build on when defining textual requirements. If done manually, pattern conformance checking can be cumbersome, particularly when requirements change frequently. The tool gives real-time feedback whether a selected pattern is matched or not and also on the quality. Additionally, terms of the controlled vocabulary fitting with the next matched pattern element are suggested, which force the authors to use consistently agreed-upon domain terms.

Having a proactive and interactive guidance that tries to improve requirements quality while actually writing requirements, is a real benefit. It is essential that errors in requirements are found early to avoid cost and error propagation later in the project, as well as reducing rework and modification loops. According to Boehm's law [START_REF] Boehm | Understanding and Controlling Software Costs[END_REF], revealing a defect in the requirements stage is 100 times cheaper than fixing one in coding. Additionally, using a domain ontology allows a better know-how transfer between domain experts and requirements authors in order to achieve a common understanding on the set of requirements between all project stakeholders. Dealing with all these new tools beside DOORS NG as requirements management tool bring new challenges and a systematic process for ontology creation and maintenance is needed as well as a new engineering role: the knowledge manager.

In order to integrate the set of system requirements with the variability model, formal relationships between individual system requirements and features need to be established. The OSLC connector of pure::variants reads all requirements including the allocated features from DOORS NG and initializes the family model defining the reusable artefacts accordingly. In case of changes, the family model can be synchronized again with changes performed in DOORS NG.

REQUIREMENTS QUALITY ANALYSIS

The quality of requirements has a major impact on project success. Badly written requirements are a well-known source of project failure. Moreover, the quality of requirements should be secured before reusing them in different product variants. For this reason, quality metrics are employed to measure the requirements quality and to identify language defects, see Figure 7. Some quality metrics are: readability, use of passive voice, ambiguous terms, negations, abuse of connectors, undefined acronyms, and inconsistent use of measurement units. The INCOSE Requirements Working Group [START_REF]Guide for Writing Requirements[END_REF] and ISO/IEC 29148 [START_REF]International Standard ISO/IEC 29148: Software and systems engineering -Life cycle processes -Requirements engineering[END_REF] provide an exhaustive definition and justification of requirements quality characteristics.

Quality analysis can be done on different levels as depicted in Figure 7:  Textual analysis: e.g. size or readability.

 Lexical and syntactic analysis: e.g. ambiguous terms and passive voice.

 Semantic analysis based on domain ontologies: e.g. overlapping requirements and completeness. We use the Requirements Quality Analyser (RQA) for DOORS NG that provides an automatic quality evaluation of NL requirements by performing lexical and linguistic checks as well as semantic analysis based on the developed domain ontology and requirement patterns, see Section 4.

RQA comprises more than 60 pre-defined metrics, from which a subset may be selected for quality analysis. Every single requirement is analysed one by one and a series of indicators (e.g. readability, ambiguous phrases, and traceability) is determined for every requirement. Every indicator is then transformed into a qualitative value by the associated quality function. During the evaluation, every quality metric rated as medium or low will generate some hints and suggestions for improvement. Figure 8 depicts measurement results for one requirement. Most relevant findings are:  Ambiguous sentences: "be capable of"

 Ambiguous use of connectors: "and/or"  Missing traceability: outlink of type "satisfies" is missing There is also another view for the whole set of requirements in a DOORS NG module, which provides a quick overview of the requirement quality in this module. Moreover, the most frequent quality issues are displayed which allows identifying focused corrective actions.

In addition, there exist several ontology-based metrics which give feedback whether concepts are properly used at the right level of abstraction. For instance we can make use of metrics related to the Product Breakdown Structure (PBS), which is represented within the ontology. In lower level documents, we activate the detection of "compound" terms to force the authors to specify the concrete subelements as defined in PBS. On the other hand for highlevel documents, we can check whether "part" terms have been used to avoid that there exist too specific terms there.

Some additional metrics make use of the categorization of terms within a specific semantic cluster. Terms which represent a system, component or a sub-component of the PBS are assigned to e.g. the semantic cluster "SYSTEM". These clusters are used within the pattern definition to restrict the allowed terms within the defined patterns.

Additionally, we make use of the common asset repository for advanced requirements analysis like consistency and completeness of the whole set of requirements. When dealing with complex systems and a high number of requirements as well as many hierarchal levels, consistency and completeness checks are difficult manual tasks. Here are some examples of automated quality checks:  Identification of inconsistent use of measurements units.

 Identification of redundant requirements by means of their respective formalization as a semantic graph. Overlapping requirements between different hierarchical levels may be an indication for an insufficient refinement.

 Completeness assessment whether any requirements of a specific category (e.g. safety, performance…) are possibly missing based on the matched pattern groups within the ontology.

Finally, analysis results are interpreted; requirements are improved and updated in DOORS NG. In addition, the domain ontology needs to be updated and validated by changing concepts and pattern formalizations to improve guidance and analysis results.

The whole set of RQS tools provides an effective support in defining well-structured requirements and performing automated analysis of requirements. With this approach, the review is more efficient since the amount of manual work is reduced; all trivial checks are performed by the tool and can even be corrected by the author itself. The reviewer can then concentrate on "difficult" points, the assessment results are reproducible and do not depend on individual reviewers' subjective opinion. Quality criteria are clear right from the beginning and hints are provided which motivate authors and drive the quality improvement process of requirements according to the PDCA (Plan-Do-Check-Act) cycle [START_REF] Bogusch | Towards Automatic Quality Evaluation of Natural-Language Requirements[END_REF].

SYSTEM MODEL DEVELOPMENT

In order to support early validation of the system specification and improve communication within the project team and with stakeholders, we adopt a Model-based Systems Engineering approach (MBSE), which constitutes three different viewpoints:

 Functional viewpoint

 Logical viewpoint  Physical viewpoint
The aim of the functional viewpoint is to describe in detail from a technical perspective the functions and behaviour the intended system shall provide, the interaction via identified interfaces with external systems, users and operators, and the interaction and dependencies between the different functions (black box approach). The functional analysis is performed with Rhapsody based on the MBSE methodology Harmony/SE [START_REF] Hoffmann | Deskbook Release 4.1, Model-based Systems Engineering with Rational Rhapsody and Rational Harmony for Systems Engineering[END_REF] and results in use case diagrams, activity diagrams, sequence diagrams, block diagrams and statechart diagrams.

First, the system requirements are accessed from DOORS NG and displayed in Rhapsody. The goal is to prove the complete consideration of all relevant system requirements during the functional analysis process. Then, the system context with interfacing actors is defined with a use case diagram. Other use case diagrams may be created to group the functional scope accordingly. Subsequently, the different functional flows are captured using activity diagrams. In the next step, a set of sequence diagrams consistent with the activity diagram and describing the behaviour of the system in a particular situation, is derived. Operations are derived from actions. Events and related event receptions are defined in relation with external actors. The identified events are linked to data items that are transported across interfaces. With the identified sequence diagrams, the system ports and interfaces including all inand outgoing events can be defined using an internal block diagram. To complete the functional analysis, a statechart is added to the system block to describe its state-based behaviour.

Thanks to the formal semantics of statecharts, code can be generated that implements the state-based behaviour of the system. Although the generation of production code is possible, we only use code generation for the execution of the functional model since we do not intend to qualify the code generator. When executing the model, the system behaviour can visually be inspected with the help of animated statecharts. Model execution is a powerful method to check the correctness and completeness of the functional model and the related system requirements. For this purpose simulations can be setup either by manually stimulating the system with events or by implementing model-based tests. The latter is described in more detail in Section 8.

The aim of the logical viewpoint is to identify an architecture of logical blocks which realises the functions and behaviour identified during the functional analysis (white box approach). In this process also non-functional aspects are considered, e.g. reduction of the number of interfaces, segregation of functions with different criticalities (see Section 7), reuse of available functions (see Section 9), integration of external suppliers, and utilization of COTS elements. The system block representing the complete functional scope is decomposed into logical blocks. Activity diagrams and sequence diagrams are refined considering partitions and lifelines related to logical blocks. System internal ports and interfaces are added for connecting the logical blocks. The state-based behaviour of all logical blocks is defined which allows to validate the logical architecture using model execution.

The aim of the physical viewpoint is to find a suitable system architecture consisting of system elements (e.g. hardware or software items) that allows to implement the logical blocks identified in the logical viewpoint, while considering the business needs and non-functional constraints. In order to derive a candidate system architecture, the logical blocks of the logical architecture are mapped to physical elements of the physical architecture. In the same way, the logical interfaces are mapped to physical interfaces. Both physical elements and physical interfaces need to comply with associated performance requirements.

Additionally, the properties of the selected physical elements (e.g. power consumption, memory size, …) are identified and modelled. Based on a set of prioritized criteria, different candidate solutions can be assessed during a trade-off study. Finally, a solution is jointly selected by all stakeholders.

Moreover, traceability is established between the system requirements in DOORS NG and the model elements in Rhapsody for all viewpoints of the system model to support coverage and impact analysis. For example, when requirements are changed, a suspect indicator is automatically added to the trace which helps maintaining consistency.

SAFETY ANALYSIS

Based on system requirements and the functional analysis of the system, hazards can be identified. Contributing system functions, as they have been identified through the functional analysis in the black box system model, are classified according to their related criticality level. The classification of the system functions as part of the Functional Hazard Assessment (FHA) considers failure modes (e.g. total loss, partial loss, inadvertent provision, and erroneous provision) of functions and the flight phase (e.g. takeoff, approach, and landing) where this failure conditions occur. Further results of the hazard assessment are derived requirements. These new safety requirements are then considered in the white box system model within the logical and physical architecture, where the system architecture has to show compliance not only to the initial functional requirements but also to all safety related requirements.

Figure 9 illustrates the black box approach that comprises the functional analysis and shows how the FHA process is integrated with the functional viewpoint. The white box approach consists of the logical viewpoint, in which an architecture is iteratively developed preventing all failures which have been identified through the FHA. Since also the physical viewpoint, that involves the identification of real interfaces and hardware components, is emerging from the white box approach, fault trees can be elaborated with a failure condition as a starting point and refined up to physical elements, where acceptable probabilities for the occurrence of failure conditions are assigned.

Figure 10 shows the white box approach comprising the logical and the physical viewpoints.

MODEL-BASED TESTING

The notion of Model-based Testing (MBT) refers to the application of models for automation of testing activities as well as modelling of test artefacts. In the following MBT is used to automatically generate test artefacts from the black box system model which represents the system under test (SUT). As discussed in Section 6 this model allows the simulation of the system behaviour. The intention is to verify that this simulation is compliant with the expected behaviour as defined by the system requirements [START_REF] Dias | A survey on model-based testing approaches: A systematic review[END_REF].

The underlying process can be divided into the following phases [START_REF] Utting | Practical Model-Based Testing: A Tools Approach[END_REF]:

1. Modelling of the SUT and/or its environment. Creation of the test architecture.

2. Generation of executable test cases from the black box system model.

3. Test execution on the SUT and assignment of verdicts.

4. Analysis of the test results.

Figure 12 provides a graphical overview of the MBT process. TC is employed for executing the test cases. Test verdicts are provided which for example allow to identify all requirements which are not satisfied by the black box model or state to which extent the system model has been covered by the executed tests.

After completion of the test execution a detailed report summarizing all relevant information including test results and model coverage analysis is generated, see Figure 14.

VARIANT MANAGEMENT

The definition of product variants is supported by an auto resolver based on the feature model (see Section 3). Figure 15 illustrates how the configuration process is performed. Mandatory features like "MarkLandingPosition" are automatically selected. Optional features without a composition rule like "TerrainDataFusion" need to be selected manually. Features affected by composition rules are selected or deselected by the auto resolver, e.g. if "Check_Obstacles" is user-selected, the feature "OWS" is automatically selected by the auto resolver. Inconsistencies in the feature model or missing feature decisions, e.g. in case of alternative feature selections, are highlighted in order to conclude a valid variant description, see missing decision on the alternatives of feature "MarkLandingPosition" in Figure 15.

Product variants are compared and validated using the product variant matrix view, see Figure 16. Each variant configuration is input to the transformation process that creates system requirements, system models, and tests for product variants. Finally, system specifications can be generated automatically capturing the information gathered during the requirements and system model development in a structured way. The generated documents can be used to perform formal reviews, fulfil contractual obligations or show regulatory compliance.

CONCLUSION

We reported on our industrial case study in the aerospace domain which was conducted in the frame of the ARTEMIS Joint Undertaking project CRYSTAL. The case study and the demonstrator cover the identification of variabilities, the construction of a feature model using pure::variants, the development and quality analysis of system requirements using DOORS NG and RQS, the elaboration of a system model using Rhapsody and safety analysis tightly integrated within the MBSE process. Moreover, requirements-based test cases are developed with TestConductor and ATG that allow verifying the system model by simulation runs.

Applying our approach to the industrial case study has produced promising results and addresses the following lean enablers (see Section 1): the basic PDCA method is applied during the requirements quality analysis to resolve problems related with badly written requirements. The use of architectural methods and models in the model-based systems engineering approach allows to clarify requirements early. Through the combination of linguistic analysis, model-based systems engineering, and model-based testing the quality of system specifications can significantly be improved. This contributes to the "first time right" objective. The tightly integrated safety analysis supports cross-functional team work between systems and safety engineers, promotes the flow of information and minimizes handoffs and rework. Additionally, the product family engineering approach allows to derive system specifications for different variants and promotes reuse of shared artefacts. The integrated SEE supports efficient access to systems engineering data. It enables to make the work process visible using metrics and facilitates end-to-end traceability analysis across different tools.

The experience gained from the realisation of the case study can be summarized as follows:  Setting up useful ontologies that effectively support authoring and quality analysis of requirements still requires a lot of experience and specific skills. Therefore, the depth and thoroughness of quality analysis has to be carefully planned depending on the objectives and boundary conditions of each project.

 In the case study a monolithic feature model was chosen. In more complex systems a modular feature model structure might be considered. A modular feature model approach is easier to understand and provides a better separation of concerns but has the burden of maintaining the traceability and dependencies between the feature models.

 The tool integration approach of the SEE allows loosely coupled tools to share and link data based on standardized and open web technologies. It should be noted that an increasing number of tool vendors support the OSLC standard. However, standardisation needs to be extended in order to support domains not covered yet, e.g. variability management and safety analysis.

We are currently working to further develop the integration of safety analysis into the MBSE approach. In addition, we are using formal specifications that can be analysed with model checking techniques. Moreover, we are adopting a more holistic approach of configuration management which provides means to define global system configurations containing all relevant types of artefacts (e.g. requirements, system model and test cases) including the traceability links between them.

Our future work will advance and improve componentbased and model-based systems engineering practices.

Components will comprise executable specifications and ease virtual integration and prototyping. They will provide variation points in order to support product families by derivation of variants. Contractual specification of components enable more efficient system verification and continuous checks of functional safety properties, e.g. by formal checks performed during virtual integration. Components already being qualified provide certification evidence to support incremental qualification and certification approaches. New systems can then be constructed with components according to domain-specific reference architectures. Domain-specific languages will further ease the specification, architectural design and verification of complex systems.

Figure 1 .

 1 Figure 1. Lean thinking [17].

Figure 2 .

 2 Figure 2. Landing aid in degraded visual environments.

Figure 3 .

 3 Figure 3. Envisioned seamlessly integrated SEE.

Figure 4 .

 4 Then, each feature is allocated to the intended product variant.Finally, each feature is assessed by the stakeholders with respect to customer value, development risk and cost yielding a relevance indicator. A threshold for the relevance is defined in order to get the list of features which should be in the scope of the product family. The results of the scoping process are recorded in an Excel sheet -the Product Feature Matrix (PFM).

Figure 4 .

 4 Figure 4. Extract of a Product Feature Matrix (PFM).

Figure 5 .

 5 Figure 5. Feature model describing the variabilities.

Figure 6 .

 6 Figure 6. Semantic analysis.

Figure 7 .

 7 Figure 7. Derivation of requirement quality metrics.

Figure 8 .

 8 Figure 8. RQA quality report.

Figure 9 .

 9 Figure 9. Black box approach.

Figure 10 .

 10 Figure 10. White box approach.System modelling including functional, logical and physical viewpoints is performed with Rhapsody, whereas safety requirements and failure condition lists are kept in DOORS NG. Fault trees as part of the Preliminary System Safety

Figure 11 .

 11 Figure 11. Tooling and exchanged artefacts.

Figure 12 .

 12 Figure 12. MBT process.Modelling of the behaviour of the SUT is already described in detail in Section 6. TestConductor (TC), the test execution and verification engine of Rhapsody is employed for creating the test architecture of the selected SUT. Test architectures comprise all artefacts which are needed for test automation, e.g. test components are created for stubbing of external interfaces.For automatic generation of executable test cases the Rhapsody Automatic Test Generation add-on (ATG) is applied. By analysis of the specified system model ATG automatically generates suites of test cases which are specified by UML sequence diagrams as depicted in Figure13. Test stimuli are generated which allow observing the behaviour of the SUT. In this format the test cases are ready for execution.

Figure 13 .

 13 Figure 13. Test case generated by ATG.

Figure 14 .

 14 Figure 14. Model coverage report generated by TC.

Figure 15 .

 15 Figure 15. Configuration of a product variant.

Figure 16 .

 16 Figure 16. Product matrix view.

  envisaged SEE includes tools and databases to support Application Life Cycle Management (ALM) and Product Lifecycle Management (PLM), see Figure 3. For interoperability, each tool has to provide a connector that is based on open interoperability standards (IOS) such as OSLC 2 . The communication between the tools (e.g. sending of requests to other tools, receiving data from tools) is realised by well-established web protocols.

Critical System Engineering Acceleration, http://www.crystalartemis.eu/

Open Services for Lifecycle Collaboration, http://openservices.net /

ACKNOWLEDGMENTS

The research leading to these results has received funding from the ARTEMIS Joint Undertaking under grant agreement no. 332830 (ARTEMIS project CRYSTAL) and German BMBF.


Pierre Bieber

Frédéric Boniol

Guy Durrieu

Olivier Poitou

Thomas Polacsek

Virginie Wiels

Ghilaine Martinez

MIMOSA: Towards a model driven certification process

Keywords: Certification, Safety, Real-Time, Model-based System Engineering, Argumentation 1 MIMOSA

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The MIMOSA 1 project aims at building a frame of reference for the certification of military embedded architectures. The goal of this frame is not to design and develop architectures, but rather to formalize requirements for this kind of architectures and place in front of them acceptable means of compliance, building a coherent argumentation. This frame of reference may be used by DGA to assess architectures proposed by industrial companies with respect to certification standards [START_REF]Integrated modular avionics (IMA) development guidance and certification considerations[END_REF].

The frame of reference includes models of the fundamental concepts of a modular architecture, models of the requirements attached to these architectures and a model of the argumentation of the compliance of the architecture to the requirements. The frame includes different levels of description from functional to hardware; different facets such as Architecture, Safety and Real-time and different concerns Architecture documentation, requirements and argumentation.

Section 2 presents the modeling approach, language and tool. Section 3 describes the argumentation modeling principles, section 4 gives some examples and section 5 concludes.

Language Overview

The MIMOSA framework is organised as a three dimensional grid having as dimensions:

• the layer -or level of detail -(function, software, topology, hardware),

• the concern (architecture, requirement, argumentation) and • the facet (general, safety, real-time).

Facets are a way to focus on domain specific considerations: properties and associated elements of description. For example, the realtime facet extends the general one by adding:

• specific concepts or attributes to describe an architecture from the realtime aspect such as best and worst-case execution times of each application of the software level, • specific realtime requirements such as "Worst Case Latency of function f should be bounded by time t" at the functional level and • specific argumentation pattern for example to efficiently convince that an application worst case response-time is bounded.

Two specific facets are currently handled by the Mimosa framework: safety and real time.

MIMOSA language internals

The language in which all of those descriptions are expressed should make available to its users concepts such as a function, an application, a binary code and so on. We call this high level language the user language. To be able to fully support the user we need some reasoning capabilities on this user language. Obtaining such capabilities directly on a very rich language as the one we were about to define a very complicated task and leads to hard to maintain result. To obtain such capabilities we then started by defining a simpler language, a formal specification language, called Weird, that offers reasoning capabilities by being translatable to propositional logic. Then, the user language is described using Weird then inheriting its reasoning capabilities. Elements of the Weird language are entity, concept and relation as well as constraint expressions (with quantifiers). Weird offers a typing system that offers to express that an entity e is an instance of a concept c, or that a concept sc is a sub concept of a concept c. Another central notion of Weird is the notion of World that allows modular modeling by constraining visibility and extent to which properties must apply. A World can contain Concepts, Entities, Relations and Constraints/properties to be satisfied. A World can derive from one or several other Worlds; in that case, it has access to all the elements and shall satisfy all the constraints of the World from which it derives.

The notion of World is used to model facets, layers and concerns. In particular one world is associated to each layer (function, software, topology, hardware) as well as to some combination of layers. Those "combination world" mainly contain allocation relations and constraints that take place between elements of different worlds. For example a constraint like "every partition (topological concept) is allocated on a unique CPIOM (hardware concept)" will be expressed in the topological hardware mapping world. This way the final "user language" -the language from which the final user will take elements to describe the system under analyses -is defined. Having this formal WEIRD language offers both the ability to make some reasoning and to ease evolution of the user language.

In our prototype, Weird is translated into propositional logic by applying rewriting rules (translation is rather direct from constraints expressions, user defined relations are kept as relations, all typing information becomes relations, world are used to restrict the domains on which quantifiers are expanded). This way, properties to check are valued by confronting them to knowledge expressed by the user3 .

Description of the system to analyze

When describing an instance to analyze, newly introduced worlds will derive from the layer, facet and concern worlds for which they are relevant. For example a world describing the functional safety requirements of the examined solution will derive at least from the three corresponding worlds Functional, Requirement, and Safety. This way:

• it will gain access to all the concepts, relations and entities they introduce and • it will have to respect constraints introduced by all of them. This derivation may be indirect in some cases: instance functional description world will derive from Functional, then the above described world may derive from the instance functional description world to gain access, at the same time, both to general rules from Functional (indirect derivation) and instance elements and rules from its instantiated version (direct derivation).

These derivations offer to reuse defined concepts and entities in the new worlds as in the example in Figure 2 The same applies to constraints, the following requirement that every application is hosted by a partition is expressed in an intermediate SoftTopoRequirements world as this: This world is then derived by CdTRequirements that will gather all requirements applicable to CdT. There it is evaluated to satisfied by the prototype tool (this is why it is represented in green in the screenshot of Figure 3

Argumentation principles

When inquiring the certification of a system, the inquirer must provide a certification file. According to the Ministry of Defence, this should be "A reasoned, auditable argument created to support the contention that a defined system will satisfy the R&M requirements" [START_REF]Reliability and Maintainability (R&M) Assurance Guidance Part 3 R&M Case[END_REF]. The exact nature of the elements is not detailed but graphical representation or models are more and more part of this certification file. For the safety aspects, the Ministry of Defence even explicitly requires safety cases[4] from which our work is inspired. Anyway the provided elements tend to grow while the structure, in particular the precise intent of an element or another, is sometimes missing. At the same time, IMA (Integrated Modular Avionics) is becoming the standard while its certification offers some additional issues [START_REF] Sicard | Specific Certification Issues Concerning IMA[END_REF].

The goal of the MIMOSA Argumentation facet is to represent graphically the different means of compliance used to justify the satisfaction of the requirements. The Argumentation facet organizes the various elements (formal and informal) that contribute to the justification of requirements.

When coming to represent graphically argumentation, GSN [START_REF] Kelly | The Goal Structuring Notation -A Safety Argument Notation[END_REF] is a reference and MIMOSA argumentation strongly inspires from it. It also inspires from Toulmin works for underlying principles [START_REF] Toulmin | The Uses of Argument[END_REF] and from existing work on assurance cases in the aeronautical domain [START_REF] Holloway | Explicate '78: Uncovering the implicit assurance case in do-178c[END_REF]. In MIMOSA a generic argumentation step relies on the following concepts:

Claim the property to be justified (will often link to a requirement), Evidence the facts that will be used to justify the claim (analysis results, test results, expert knowledge, bibliographical reference. . . ),

Usage Domain domain on which the method is usable

Rationale justifies the use of the method in this particular context Argumentation patterns are then proposed as a partial instance of this generic step, specifying subconcepts, known entities, and their necessity status depending on the strategy or strategy family.

Argumentation patterns can be of different natures: generic (as "Using a software" that will make mandatory to explicit the usage domain and add a corresponding support to show its respect) or domain specific (like "Showing that the Worst Case Response Time of an application is bounded by a value").

When building an argumentation two mechanisms are then used:

• argumentation step chaining -one claim of a level becomes a support for the next one ;

• argumentation pattern composition -a given step inherits from more than one argumentation patterns.

In this last case, it has to exhibit the union of supports, usage domain and rationale of its "parents" (see Figure 5). To make sense strategy and claim of the parents should be compatible, for example "using a software to compute a WCRT bound" would inherit from the patterns "using a software" and "calculating a WCRT bound". See the example just below.

Note that the particular usage that is envisaged here protects us from what could have been an important issue: the supports consistency. In a general case, both mechanisms of combination of argument steps proposed just above would have, as an additional task, to prove that the resulting support set is consistent (in fact, this should also be explored for each elementary step). Each support is here considered valid (and the real situation consistent), that means that:

• an elementary argumentation steps having inconsistent support requirements is unusable (all its supports can not be fulfilled at the same time)

• when combining two steps for which supports have been provided, no inconsistency may appear.

The first item is one reason -the formal one -why argumentation step merging may not make sense4 . For example if two argumentation patterns have been written to deal with two different situations, merging them is useless as no real case would match both situations and then it would be impossible to fulfill all the supports of the resulting pattern.

Eventually, a global constraint should be that every Requirement written -the system must have property P-has a corresponding argumentation claim -The system has the property P-A certification argumentation is complete when every requirement has got a corresponding assert with proper method, supports and some times rationale and usage domain. This can shares validated patterns with industrial entity willing to obtain certification of a product. These patterns will act as guides for building a certification request for the industrial entity while supporting the analysis work of the certification entity, then being profitable for both. Capitalization is also made easier: certification authority builds a new pattern from analyzing a certification request that is not yet formalized this way, and then after an internal validation phase, add this new pattern as a new approved means of compliance. Industrial entity already having strong background in certification may also formalize their way of asserting a given property, and submit it to the certification authority as a new "standard" means of compliance -i.e. a new argumentation pattern-(this formalizes capitalization of the Certification Review Item process often used today when new approaches or technologies are to be evaluated).

Conclusion and perspectives

A Model based framework for certification process has been presented that offers to describe and analyze in a common language the system description, requirements that are put on it, and argumentation that is delivered to show the system conformance to its requirements. Some argumentation patterns have been produced as well as a composition scheme that offers to build an instance of argumentation tree by mainly composing building blocks from rather domain specific ones to very generic ones.

A prototype has been developed to illustrate this approach, it has been tested on a case study containing two functions Fire control and Terrain following (then decomposed in several applications) allocated to a reference architecture with IMA capabilities ; and DGA TA envisages to use the approach on a real case study based on their certification activities. Nevertheless the exact way the methodology presented in this paper should take place is not yet completely defined, a shared tool between certification experts and candidate to certification would clearly be a good support but might not be realistic for tomorrow, an internal tool for the certification team that offers to build the argumentation based on the supports provided and some question/answer with the certification candidate may already help the certification team to organize, keep focused on the objective, and gain confidence in the decision they will eventually make.

Figure 1 :

 1 Figure 1: The architecture layers and mapping worlds 2

  of a Fire Control function (partial) description. The global CdT function, as well as its enabling applications are directly introduced without the need of redefining anything. In the same way 4 partitions are introduced in the TopoRef world by reusing the concept of IMA Partition from the generic Topology one.

Figure 2 :

 2 Figure 2: Worlds describing a product derives from generic ones

  d e r i v e s Requirements , S o f t w a r e T o p o l o g y M a p p i n g { 3 a s s e r t a l l a p p s a l l o c a t e d = 4 f o r a l l e n t i t y a | a : : A p p l i c a t i o n => 5 e x i s t s e n t i t y p | p : : P a r t i t i o n and h o s t i n g P a r t i t i o n [ a]===p 6 }

Figure 3 :

 3 Figure 3: CdT requirements are gathered in the CdTRequirements world

Figure 4 :

 4 Figure 4: The generic argumentation step

Figure 7 :

 7 Figure 7: bounded WCRT argumentation pattern

The content of hardware world have been hidden since it would not have fit in the page width.

Though this is not used in the context described in this article, the low level language is then compatible with SAT solvers tools that can be used to answer different questions.

The other reason why a argumentation step merging may not make sense is that it does not make sense from a business point of view.

Argumentation examples

"Using a software" is a generic pattern that mainly adds the constraint of exhibiting the Usage Domain (that is optional by default). This constraint activates another one that comes from the generic argumentation step telling that if a Usage Domain is attached to the Strategy then at least one support must show conformance to this usage domain.

The second argumentation pattern introduced is domain specific: "assessing an application maximum Worst Case Response Time". Such a claim needs that this WCRT is calculated, and relies necessarily on the computation of the Worst Case Execution Time of each involved applications in the partition hosting the evaluated one, and that the preemption policy and the period are known (links to architecture and realtime facet products will help precisely determine the relevant set of applications, as well as, if filled, automatically check preemption policy and period). A graphical representation of this pattern can be found in Figure 7. A constraint is added to ensure that, at least, WCET, preemption and period supports are provided if this strategy is used.

The third argumentation pattern is the composition of the two previous ones: "Using a software to assess an application maximum Worst Case Response Time" (see Figure 8). It then inherits from all the supports from the two previous ones, as well as the Usage Domain mandatory constraint coming from "Using a software".

Implementation and usage

Today, qualification/certification of new systems becomes more problematic due to several causes, the more invoked being the system complexity increase that is observed and a more practical one being the size of certification teams.

A less trivial reason is the evolution of the way system are developed: the development of a system is no more made from scratch with every subsystem developments made in consis- tency with the unique goal of integrating the system under development. On the opposite, a component based approach is more and more intensively used with a lot of reuse and "generic" components integration. This is strongly involved in the loss of structure of the certification file because part of the argumentation is then made either in another context (reuse case) or still at a general level (generic components case). Documentation provided to certification team is then not so organized, the same information may appear in many documents (strongly redundant documents may be provided to support the same kind of property but for different parts of the system due to the reuse of certification supports in another context and/or the pre-qualification steps). The certification file volume then grows up and, on the opposite of very redundant information, some precise information may become hard to find.

Formalizing the "structure" of the argumentation is the answer we promote in this work, by relying on the introduced argumentation pattern and combination mechanisms.

Apart from the formal principles enunciated in the previous section, the way one may use these argumentation patterns typically varies with the level of abstraction. Technical, low abstraction level patterns may benefit from formal inputs that a tool is able to manage, and provers or solvers can make automatic or semi-automatic reasoning from these argumentation steps. On the other extremity, high abstract level patterns are more likely to require human understanding and supports will often be links to heterogeneous documentation elements. In that last case, argumentation patterns must be seen as "check lists" and tooling will mainly guide the user to missing information, when some supports, rationale or usage domain are linked to no elements.

Classical envisage process of argumentation pattern is that the certification authority