Downloaded from SAE International by University of Wisconsin - Madison , Monday, September 10, 2018
Using SCADE System for the Design and Integration
of Critical Systems
Thierry Le Sergent and Alain Le Guennec
Esterel Technologies
Sebastien Gerard, Yann Tanguy and Francois Terrier
CEA, LIST
ABSTRACT
This paper presents the SCADE System™ product line for
systems modeling and generation based on the SysML
standard [2] and the Eclipse Papyrus open source technology.
SCADE System has been developed in the framework of
Listerel [7], a joint laboratory of Esterel Technologies,
provider of the SCADE® tools [8], and CEA LIST, project
leader of the Eclipse component, Papyrus [4].
From an architecture point of view, the Esterel SCADE tools
are built on top of the SCADE platform which includes both
SCADE Suite®, a model-based development environment
dedicated to critical software, and SCADE System enabling
model-based system engineering. SCADE System includes
Papyrus, an open source component (under EPL license),
integrated in the modeling platform of Eclipse. Using this
integrated modeling platform, both system and software
teams share the same environment for system development.
Furthermore, other model-based tools can be added to the
environment, due to the use of Eclipse.
SCADE System avoids duplication of efforts and
inconsistencies between system structural descriptions made
of SysML Block Definition Diagram (BDD) and Internal
Block Diagram (IBD), and the full software behavioral
description designed through SCADE Suite models. Once the
system description is completed and checked, the individual
software blocks in the system can be refined in the form of
models in SCADE Suite or in the form of manually
developed source code. Automatic and DO-178B Level A-
qualified code generation can then be applied to the SCADE
Suite models. Moreover, the SCADE System description can
2011-01-2577
Published
10/18/2011
Copyright © 2011 SAE International
doi:10.4271/2011-01-2577
be used as the basis to develop scripts that will automatically
integrate the complete application software.
INTRODUCTION
The International Council on Systems Engineering (INCOSE)
[1] defines system engineering as an interdisciplinary
approach and means to enable the realization of successful
systems. It focuses on defining customer needs and required
functionality early in the development cycle, documenting
requirements, and then proceeding with design synthesis and
system validation.
The main challenges of System Engineering are related to
providing non-ambiguous and coherent specifications,
making all relevant information readily available to all
stakeholders involved in the development process,
establishing traceability between all activities, and providing
the appropriate level of verification and validation. Model-
based approaches can play a central role in System
Engineering. Among the benefits, Model-based System
Engineering (MBSE) avoids duplication and parallel
evolution of data between system teams and software teams,
hence reducing the nightmare of information
resynchronization.
SysML is specifically targeting system-level specifications.
We currently observe a trend toward more formalization of
the system-level artifacts through the use of modeling
languages like SysML.
Esterel SCADE is a proven solution for developing safety-
critical and mission-critical software. Although SCADE Suite
is already connected to various tools that together form the
 Downloaded from SAE International by University of Wisconsin - Madison , Monday, September 10, 2018
overall development environment, its scope does not directly
encompass system-level artifacts themselves. There is an
identified need to smoothen the integration between system-
level artifacts and SCADE Suite designs, making the
transition process from system to software more reliable and
efficient. A good process, in which the right formalism is
used for the right artifact, is an important aspect. Good tool
support is also essential for automating as many tasks as
possible while preserving overall consistency of the system to
software flow.
Esterel Technologies is working on a combined modeling
solution that brings together the respective strengths of
SysML and SCADE Suite. The combined process facilitates
the work of both system designers and software designers
with respect to the overall design. Therefore, the
requirements are captured from both the system designer's
point of view and from the software designer's point of view.
The requirements also consider the interactions between them
and how they can synchronize their respective points of view.
The paper presents the results of combining a selected subset
of SysML with SCADE Suite and how the modeling
constructs used at the boundary between the two formalisms
can be synchronized to support the resulting “mixed
language” modeling experience. The resulting tool is branded
SCADE System.
PAPYRUS - SYSML
Papyrus is the UML editor of the Eclipse open-source
platform and is the result of a joint effort from different
initiatives launched by CEA and TOPCASED [5] some years
ago. Papyrus is aiming to provide full support to UML and a
very advanced support to UML profiles. This latter concept is
the lightweight extension mechanism of UML that enables
one to customize it later to fit to different specific domains
and concerns.
In order to enable systems architects to model their systems,
the OMG (http://www.omgsysml.org/) has standardized the
UML Profile for Systems Engineering (in short SysML).
SysML has been defined as a general-purpose modeling
language for systems engineering and was designed as a
UML profile. In addition to its UML support, Papyrus also
provides complete support to SysML enabling one to edit
BDD, IDD, as well as the other SysML diagrams. Papyrus
also enables validation of the models with respect to its
underlying language (SysML in this case) and comparison
and merge of SysML models.
SCADE SUITE
SCADE (Safety Critical Application Development
Environment) is both a notation and a toolset that was
specifically designed for the development of critical systems
in aeronautics, railway, and industry that must comply with
certification standards. In the rest of the paper, “Scade” is
used to refer to the modeling notation and “SCADE Suite”
refers to the toolset that supports the Scade notation.
The Scade notation includes both block diagrams and state
machines that can be nested at any levels. This powerful
notation has been formally defined [9] to provide a rigorous
description of the SW behavior, leaving no room for
uncertainty. Characteristics are:
• Strong typing
• Explicit initialization of data flows
• Explicit management of time with clocks [9, 11]
• Concurrency based on data dependencies
• Deterministic execution.
The SCADE Suite toolset supports a model-driven paradigm
in which the Scade model is the software specification.
The SCADE Suite KCG C code generator is qualified for
avionic systems with respect to DO-178B at the highest level
of safety (Level A) and for industrial and railways domains
with respect to IEC 61508 up to SIL 3 and EN 50128 up to
SIL 3/4. This, in addition to several verification tools such as
SCADE Suite Model Test Coverage™, provides evidence
that the code that will be embedded fulfills the high-level SW
requirements.
WORKFLOW
INCOSE provides guidelines; in practice, each organization
defines its own workflow depending on internal constraints.
The better the Commercial Off-The-Shelf (COTS) tool
supports the different workflow steps, the more efficient it is.
This paper is not a methodological paper but a technical
paper focusing on the way that the required features can be
implemented in a COTS tool to support individual MBSE
activities.
So an ideal toolset shall support MBSE activities, automating
the tasks, still be customizable and ensuring information
consistency between the teams. To that end, in addition to
being a SysML modeler, SCADE System supports
requirements traceability, model diff, and automatic
production of system design documents.
Project specificities also require additional verification or
development tools, so the COTS tool should allow
development of such complementary tools. SCADE System
Model APIs provide an adequate means for such
developments. This is presented in the last section of this
paper together with the architecture of the SCADE System
modeler tool itself.
 Downloaded from SAE International by University of Wisconsin - Madison , Monday, September 10, 2018
Among the activities that must rely on safe foundations, the
System-Software synchronization is a key feature. The
mechanism implemented in SCADE System provides the
basic bricks that allow system teams and SW team to work
efficiently on the same project. The foundation of this feature
is detailed in the next section of paper.
SYSTEM-SOFTWARE
SYNCHRONIZATION
BOUNDARY BETWEEN SYSML AND
SCADE SUITE
The proposed approach assumes that SCADE Suite will be
used for application-level behavioral specification, at
minimum for selected software components deemed critical.
Scade is a structured behavioral modeling language. Unlike
SysML, it does not enforce a strong separation between
structural interface and behavioral interface. In Scade, the
unit of modeling is called the “operator”, which can be
considered as a type of “functional block”, performing a
computation using a set of inputs and providing a set of
outputs, as a result. On the other hand, SysML separates
structural descriptions on one side (blocks and their
interfaces) and behavioral descriptions (behaviors, such as
activities or state machines) on the other side. Therefore, the
most straightforward representation of a Scade operator in the
SysML world would be as a so-called “opaque behavior” (a
behavior of which only the input and output parameters are
known, but which implementation is considered hidden or
external to SysML).
Once promoted as opaque behaviors in a SysML application
model, Scade nodes can be used like any other behaviors in
the SysML model.
• They can be used in architecture models represented as
block diagrams: Some of the blocks will use Scade operators
as their “main behavior” (a block can have any behavior as its
“main behavior”).
• They can be used in architecture models represented as
activity diagrams: Some of the sub-behaviors called within
the activity will be the Scade operators directly.
In a more “service oriented” context, they could also be used
as implementation “methods” for some SysML operations (an
operation can have any behavior as its implementation
“method”). Previous work on the UML/SysML gateway [12]
for SCADE Suite focused solely on the first use case (block
diagrams). Moreover, a Scade operator was always directly
derived from a SysML block, without having to use an
opaque behavior as an intermediate “proxy” between the
SysML world and the Scade world. We now consider making
the “opaque behavior” always explicit because this has
several advantages over the previous approach.
• The “opaque behavior” can be attached not only to mere
SysML blocks, but to any entity to which an “opaque
behavior” can legally be attached.
• The connection between a behaviored classifier and the
opaque behavior providing its main behavior need to no
longer be implicit and direct (implicitly matching behavioral
flow ports of the behaviored classifier with the inputs/outputs
of the Scade node). Instead, the connection between the
structural interface and the behavioral interface can be made
explicit. (Some suggest using delegation connectors in the
SysML model itself; some suggest using an explicit
behavioral description that realizes the transmission.)
This explicit separation also shields the behavioral interface,
made of the parameters of the opaque behavior, from the
more complex features available to describe the structural
interface of the behaviored classifier (non-atomic flow ports,
etc.). As a consequence, the mapping between the opaque
behavior and the corresponding Scade node can be kept more
direct and simple, and therefore, easier to maintain in an
automated way (the mapping is kind of “canonical”, whereas
the connection between structure and behavior in SysML
might not be canonical).
The following sections describe the boundary between
SysML and Scade. We follow a two-stage approach.
• The first (optional) step is to make the SysML opaque
behavior that acts as the Scade operator surrogate explicit, in
cases where it was left implicit; it is a simplification step in
preparation for the actual mapping to Scade.
• The second step describes the actual mapping between the
SysML opaque behavior and the corresponding Scade
operator interface in details.
DETAILED SPECIFICATION OF
SYSTEM/SOFTWARE BOUNDARY
Canonical SysML Opaque Behavior of a Block
In the top-down scenario described previously, it is assumed
that the SysML block (or the behavioral feature) to be
implemented in Scade already has an attached opaque
behavior. In cases where there is initially no such opaque
behavior, the tool supporting the approach provides a means
to automatically derive a “canonical” opaque behavior for the
block or behavioral feature. The next subsection describes
how such a “canonical” opaque behavior can be derived from
the interface of a given SysML block, to act as its main
behavior. For the sake of simplicity, we assume in subsequent
sub-sections that leaf SysML blocks to be implemented in
Scade already have an opaque behavior, be it explicit or
automatically derived.
 Downloaded from SAE International by University of Wisconsin - Madison , Monday, September 10, 2018
Automatic Derivation of an Opaque Behavior for a
Given SysML Block
In cases where a SysML block only has atomic flow ports
typed by a value-type (not by a signal), deriving the
corresponding “canonical” opaque behavior is
straightforward: the opaque behavior will simply have one
parameter for each flow port, keeping the same name, type,
and direction. We consider that the values carried by the
atomic flow ports are bound to the corresponding parameters
of the behavior as if the ports were somehow connected to the
corresponding parameters of the behavior using delegation
connectors.
Figure 2. Opaque behavior for block with only atomic
ports.
However, as already mentioned, the structural interface of a
block can make use of more complex features that require
some “massaging” to be mapped to parameters of an opaque
behavior.
Non-atomic flow ports are typed by a flow specification,
which is a special kind of interface made of individual flow
properties that are grouped together. Moreover, such a flow
port can be marked as “conjugated”, which implicitly
reverses the direction of all its flow properties. This allows
the same flow specification to be reused for two conjugated
ports on both sides of an assembly connector. In this case, we
consider all flow properties of the port as if they were
individual atomic flow ports with same type and direction (or
opposite direction if the port is conjugated). In order to avoid
name conflicts if several ports happen to carry homonymous
unrelated flow properties, we additionally prefix the name of
the derived atomic flow port with the name of the port
carrying the flow property to ensure parameter name
uniqueness. Again, we consider that the individual values
carried by the non-atomic flow ports are bound to the
corresponding parameters of the behavior as if the ports were
somehow connected to the corresponding parameters of the
behavior using delegation connectors with “nested connector
ends” on the flow ports' side to pick the right individual flow
property (“nested connector ends” were introduced by
SysML to overcome the limitation of “shallow/flat”
connections).
Figure 3. Opaque behavior for block with non atomic
ports.
In addition to data types, signals can also be used to type an
atomic flow port or a flow property of a non-atomic flow
port. Normally, a signal is handled by a special kind of
behavioral feature called a “reception”. Here, the chosen
solution is having a Boolean property for each signal to hold
its presence status and linking the presence status to a
corresponding Boolean parameter of the opaque behavior.
Note that at this stage, we do not consider automatic
derivation of opaque behavior for a block having so-called
“service ports”, since each service would better be handled by
its own implementation behavior. In that case, the designer
might want to attach a Scade opaque behavior to the
appropriate individual service behavioral feature instead.
Automatic Derivation of an Opaque Behavior for a
Given Behavioral Feature
Creating an opaque behavior that implements a given
behavioral feature (typically an operation) is much more
straight forward; it simply amounts to creating an opaque
behavior with parameters equivalent to those of the
behavioral feature it is meant to implement. The association
between the parameters of the behavioral feature and the
corresponding parameters of its opaque behavior is implicit
and automatic.
Mapping between a SysML Opaque Behavior and
a Scade Operator Interface
Because an actual Scade operator is conceptually very close
to its SysML opaque behavior surrogate, the mapping is again
fairly straight forward. The main difference, however, is that
 Downloaded from SAE International by University of Wisconsin - Madison , Monday, September 10, 2018
Scade does not support bidirectional parameters contrary to
SysML behavior parameters. A Scade operator always has a
disjointed set of inputs and outputs. Nonetheless, the
following mapping can still be defined.
• Parameters having direction “in” are each mapped to a
corresponding input of the Scade operator interface.
• Parameters having direction “out” or “return” are each
mapped to a corresponding output of the Scade operator
interface.
• Parameters having direction “inout” must each be mapped
to a couple {input, output }. To avoid name conflicts, the
input's name will be prefixed by “input_” and the output
name will be prefixed by “output_”. Appropriate traceability
information is retained to re-synthesize a bidirectional
parameter in the reverse mapping.
The types of the parameters are mapped as follows:
• predefined types of SysML are mapped to corresponding
Scade predefined types, if a match exists;
• enumeration types of SysML are mapped to corresponding
Scade enumeration types; and
• value types (with unit and dimension) are mapped to a
corresponding homonymous alias of the Scade predefined
type “real” (the unit and dimension are however currently
ignored).
When no Scade type can be inferred from the SysML model,
specific translation directives can be added in the tool
configuration to force a user-defined type mapping.
TOOL WORKFLOW
Based on this mapping, the workflow in SysML-Scade
synchronization can now be detailed. It is summarized Figure
4.
Figure 4. SysML-Scade synchronization.
System-Side “Component Specification Proxy”
(CSP)
Once a SysML application component has been allocated to
SCADE, the appropriate opaque behavior, which will serve
as the boundary between the two modeling realms, must be
prepared.
• First, it can be derived automatically as explained
previously, if it does not exist because the system designer
stopped at the level of “functional blocks”.
• Second, the system designer must anticipate that this
opaque behavior might later be updated as a result of a
bottom-up propagation of changes that happened
concurrently in the Scade model. To make sure these
modifications can be applied without disruption and can be
tracked judiciously, the opaque behavior should be
considered as an independent “unit” from a storage/
configuration management point of view. We will call this
unit the “Component Specification Proxy” or CSP. Bottom-
up modifications can then be incorporated carefully using
diff/merge facilities in the SysML modeling tool.
Note that if the opaque behavior changes as a result of a
bottom-up modification, this might imply structural changes
to the SysML block to which it is attached (or to the
behavioral feature). Notably, ports may have to be added/
removed/modified along with delegation connectors between
the ports of the block and the parameters of the opaque
behavior. A specific “wizard” in the SysML tool could be
developed to ease the “reconciliation” process between the
structure and the external behavior. At this stage, such a
“reconciliation wizard” is out of scope, and the structural
reconciliation must be achieved manually by the system
designer.
Software-Side “Component Implementation
Proxy” (CIP)
Any Scade operator that implements the behavior of a
component of the SysML application model is associated
with a corresponding SysML opaque behavior. This SysML
opaque behavior can be derived automatically from the Scade
operator interface, and we call it the “Component
Implementation Proxy”, or CIP, on the SCADE side. This
derived SysML opaque behavior should normally not be
modified directly by the component designer using SCADE
Suite.
There are, however, a few circumstances in which the
SCADE Suite user should be aware of it. These are listed
below.
• When the initial version of a Scade node is “bootstrapped”
from an existing SysML opaque behavior coming from the
system application model, the component designer using
SCADE will select the right CSP to be used to produce the
 Downloaded from SAE International by University of Wisconsin - Madison , Monday, September 10, 2018
initial version of the Scade node, and the tool guarantees that
the reverse mapping (i.e. producing the CIP) is idempotent
(the CIP after bootstrapping is equivalent to the CSP used for
the bootstrap step, but both can evolve concurrently from
then on).
• After the Scade node has been completed, it may actually
appear that the interface of the Scade node has to be modified
because of important design choices that have to be
propagated bottom-up to the system application model. To
that end, the component designer can decide to publish a new
version (through the configuration management tools for
instance). Each time a new version of the Scade node is
published, the corresponding CIP should also be made
explicit and published alongside the Scade model, so that the
system designer can pick it and use it to produce the next
version of the CSP on the other side if he agrees with the
changes.
• The component designer can also be informed that the CSP
corresponding to the Scade node has changed and that
changes need to be propagated top-down. In this case, the
new version of the CSP is compared with the current version
of the derived CIP, and the change-set describing the SysML
modifications is then translated into a corresponding change-
set to be applied to the Scade model itself. Diff/merge
facilities in SCADE can then be used to analyze the impact of
the changes on the Scade model and to incorporate them
(implicitly creating a new version of the CIP).
In some settings, it might be possible to share the
configuration management unit representing the opaque
behavior for both the CSP and the CIP, hence forcing any
side to take action any time the view of the interface changes
on the other side. However, one might prefer a setting in
which the system design team and the software design team
are loosely coupled and can work concurrently using explicit
synchronization milestones (through exchanges of CSP and
CIP) when they see fit.
SCADE SYSTEM DESIGNER
This section describes how the SCADE System modeler is
built from the pre-existing Papyrus and SCADE Suite tool set
with a short focus on the model API provided by the
underlying architecture.
TECHNICAL ARCHITECTURE
Papyrus and SCADE Suite were developed independently.
For user adoption this may have several drawbacks:
• two different tools to install, two different windows on the
screen, two different look and feel; and
• no sharing of existing or yet-to-be-developed add-ons.
However, despite their different technical origins, both
Papyrus and SCADE Suite were developed with the same
principles in mind: a generic platform that supports graphical
editors. For Papyrus, the generic platform is Eclipse. For
SCADE Suite, it is an internal platform called SCADE Studio
that is based on the Microsoft MFC framework, which was
developed in the 90s. It provides services very similar to the
Eclipse subset used by Papyrus.
A first possible solution for integrating Papyrus and SCADE
Suite IDE would “simply” be to port SCADE Suite to the
Eclipse platform. Though technically possible, this solution is
not the ideal solution for two reasons:
• the number of Esterel Technologies' tools (SCADE
LifeCycle Reporter™, SCADE Suite Model Test
Coverage™, SCADE Suite Design Verifier, SCADE Suite
Timing and Stack Verifier, etc) already relying on SCADE
Studio would make the porting effort very significant; and
• the look and feel of the SCADE Suite interface would
change for current users.
Likewise, it does not make sense to update the Papyrus
Eclipse project to make it run outside Eclipse.
Instead, a hybrid platform has been built that blends the
Eclipse and the SCADE Studio platforms. The later remains
the main “host” platform, but most Eclipse platform User
Interface (UI) elements involved in the Eclipse plugins
making up Papyrus are transparently intercepted and
“reframed” to fit in the SCADE Studio platform at the
appropriate place. Therefore, the integration is fine-grained.
From the Eclipse-side, this special reconfiguration is
recognized as another UI “perspective”. The following UI
element categories are supported:
• Navigator/explorer views (as SCADE Studio “browser
tabs”)
• Ordinary views (as SCADE Studio “output tabs”)
• Property pages and tabbed property pages (as SCADE
Studio property pages)
• Editor parts of the editor area (as SCADE Studio editors)
• Menu contributions and key shortcuts
Moreover, the integration is not just “cosmetic”; indeed, both
platforms are model-based platforms and each provides its
own framework to support model entities:
• The Eclipse Modeling Framework (EMF)
• The SCADE Studio Modeling Framework
Both frameworks offer generic model-oriented services based
on model meta-data. These modeling frameworks are also
combined. The hybrid platform supports EMF-based models
as if they were SCADE Studio-based models. That is, EMF
meta-data are translated at run-time into the corresponding
 Downloaded from SAE International by University of Wisconsin - Madison , Monday, September 10, 2018
Figure 1. Technical architecture of SCADE System.
SCADE Studio meta-data, and proper API bridges have been
set-up to call back into EMF code where appropriate. So,
existing SCADE Studio plugins that work at the generic
meta-data level can also work with EMF-based models
unchanged.
Finally, the concepts of “workspaces”, “projects” and “files”
are also unified and synchronized between the two platforms,
allowing the system projects and software projects to be
managed uniformly with configuration management tools. It
is even possible for a single project to have both a “system”
nature (supported by Eclipse/Papyrus plugins) and a “Scade”
nature (supported by native SCADE Suite plugins). Both
sides always have the exact same view of the project's
resources.
The solution developed is pictured in Figure 1 and a screen
shot of the resulting IDE is shown in Figure 5.
This tool architecture provides several benefits:
• the development of the Papyrus tool can be pursued as part
of the Eclipse consortium without constraints;
• there is full compatibility ensured between SCADE System
and Papyrus, as they rely on the same code;
• SCADE System is open to other Eclipse tool extensions,
provided that they comply to the supported Eclipse subset, in
addition to the openness brought by Papyrus for modeling
extensions; and
• there is one window and look and feel for SW design with
SCADE Suite and system architecture design in SysML with
SCADE System.
MODELS API
Based on the Eclipse Modeling Framework (EMF), Papyrus
provides a Java API on the profiled SysML UML model.
SCADE Suite has its own meta-model; in addition to the
classical EMF Java API, the tool provides a tcl API, directly
accessible from the SCADE Suite IDE that allows traversal
of the model. An html wizard derived from the meta-model
guides tcl script developers in the traversal of the models.
The tcl script not only interacts with the model but also with
the IDE allowing, for example, locate feature on graphical
views of the model.
Due to the SCADE System architecture presented in the
previous section, the existing SCADE Suite technology has
been extended to the SysML models. This makes the
development of easy to build tools that require both System-
level and SW-level information possible
Three actual examples of the API usage are provided below:
The first example is model documentation generation.
SCADE Suite and SCADE System reporters are simply
realized with tcl scripts that traverse the respective models
and share the same RTF and html drivers. It is then easy to
produce documentation that mixes system and SW
information when required.
A second usage is for code and configuration file generation
from system models specifying, for example, multi-tasks
systems. Each task represented by a SysML block is
implemented via a SCADE Suite design with code generated
by the SCADE Suite code generator. The task's connection,
periods, etc. are specified as a SysML model with a specific
Real-Time profile such as MARTE [5]. The APIs are used to
generate the wrapping code and RTOS configuration files
allowing for the complete generation of the multitasks
system.
A third usage of the API is to import into SCADE System a
legacy model developed previously with a technology that is
becoming obsolete. In this case, the API is used to construct a
SCADE System model. One of the nice features of SysML
implementation in a tool like Papyrus, and likewise SCADE
System, is the capability to set-up a model independently
 Downloaded from SAE International by University of Wisconsin - Madison , Monday, September 10, 2018

from any graphical diagrams, allowing the user to draw
diagrams in a second step for documentation purposes. The
core of the model is typically built from a database of
“signals” like information-giving datatypes, endpoint blocks,
periods, etc. Such techniques are still heavily used but suffer
from being misaligned with existing standards, without
COTS tool support, etc. Moving to the SysML standard
which is supported by open tools is a natural trend.
Of course, the model API allows automatic verification of
design rules. Integration of SW and System designs within
the same toolset facilitates the development of complex
design rules that encompasses System and SW descriptions.
SUMMARY/CONCLUSIONS
Esterel Technologies provides a seamless flow from the
initial requirement analysis phase in SysML down to the SW
code that benefit from certification evidences provided by
SCADE Suite.
The SCADE System preliminary version has already been
used successfully. As part of the INTERESTED ICT FP7
project, Siemens is using the synchronization between
SysML blocks and SCADE Suite. The architecture of the
ZLB (simplified traffic management on secondary lines) in
the context of German railway systems has been modeled in
SysML and SW developed with SCADE Suite. Siemens
reported that, in comparison with their previous process
based on standard C++ development, this methodology
supported by tools allowed for the:
• increase in the precision of the architecture description and
components reuse;
• increase in overall maintainability of the product due to a
better level of abstraction;
• the time required for the integration phase was significantly
reduced; and
• the tool provides increased flexibility allowing for quicker
completion of changes.
facilitated through both the model's detailed access through
APIs and the openness of the platform. Such verification
tools, including those for simulation of both discrete and
continuous systems, will be developed in future cooperative
projects driven by the joint Esterel Technologies and CEA
Listerel laboratory.
REFERENCES
1. “Systems Engineering Handbook, a Guide for System Life
Cycle Processes and Activities”, SE Handbook Working
Group, INCOSE, January 2010.
2. “OMG Systems Modeling Language (OMG SysML)”,
OMG, Version 1.2, June 2010
3. “DO-178B Software Considerations in Airborne Systems
and Equipment Certification”, RTCA/EUROCAE, 1992
4. Papyrus, http://www.eclipse.org/papyrus
5. MARTE, //http://www.omg.org/omgmarte
6. TOPCASED, http://www.topcased.org
7. Listerel Critical Software Lab, http://www.listerel.org
8. Esterel technologies SCADE products, http://www.esterel-
technologies.com
9. SCADE Language Reference Manual, http://www.esterel-
technologies.com
10. “The Synchronous Dataflow Programming Language
LUSTRE”, Halbwachs, N., Caspi, P., Raymond, P., Pilaud,
D.. Proceeding of the IEEE, September 1991.
11. “A Conservative Extension of Synchronous Dataflow
with State Machines”, Colaço, J.L., Pagano, B., Pouzet, M..
EMSOFT'05
12. “Bridging UML and Safety-Critical Software
Development Environments”, Le Guennec, Alain, Dion,
Bernard. ERTS 2006
13. “SCADE 6: A Model Based Solution For Safety Critical
Software Development”, Dormoy, François-Xavier. ERTS
2008

Experimentation on system modeling for avionics equipment

for helicopters is in progress. The objective is to compare the CONTACT INFORMATION
current process based on a custom database system with the Thierry Le Sergent
SysML capabilities to specify such systems. The advantages Esterel Technologies
of a graphical description that includes all system design thierry.lesergent@esterel-technologies.com
details kept in dedicated stereotypes have been demonstrated.
The model is now ready for clean report generation, which Alain Le Guennec
provides a much better shared understanding by all teams. In Esterel Technologies
this system, the SW part was previously developed with alain.leguennec@esterel-technologies.com
SCADE Suite and certified to DO-178B by EASA at level A.
François Terrier
The door is now open for advanced verification that CEA, LIST, Laboratoire d'Ingénierie dirigée par les modèles
encompasses system and software description with tools that pour les Systèmes Embarqués
can plug into the SCADE System architecture. This is francois.terrier@cea.fr
 Downloaded from SAE International by University of Wisconsin - Madison , Monday, September 10, 2018

Sébastien Gérard
CEA, LIST, Laboratoire d'Ingénierie dirigée par les modèles
pour les Systèmes Embarqués
sebastien.gerard@cea.fr

Yann Tanguy
CEA, LIST, Laboratoire d'Ingénierie dirigée par les modèles
pour les Systèmes Embarqués
yann.tanguy@cea.fr

ACKNOWLEDGMENTS
This work has been partially founded by the FP7 ICT-2007
INTERESTED project and by the FUI 5th call LAMBDA
project.
 Downloaded from SAE International by University of Wisconsin - Madison , Monday, September 10, 2018

APPENDIX

Figure 5. SysML IBD and BDD, and SCADE Suite design in the same framework.

The Engineering Meetings Board has approved this paper for publication. It has Positions and opinions advanced in this paper are those of the author(s) and not
successfully completed SAE's peer review process under the supervision of the session necessarily those of SAE. The author is solely responsible for the content of the paper.
organizer. This process requires a minimum of three (3) reviews by industry experts. SAE Customer Service:
Tel: 877-606-7323 (inside USA and Canada)
All rights reserved. No part of this publication may be reproduced, stored in a
Tel: 724-776-4970 (outside USA)
retrieval system, or transmitted, in any form or by any means, electronic, mechanical, Fax: 724-776-0790
photocopying, recording, or otherwise, without the prior written permission of SAE. Email: CustomerService@sae.org
ISSN 0148-7191 SAE Web Address: http://www.sae.org
Printed in USA