11ATC-0290 Using SCADE System for the Design and Integration of Critical Systems Copyright 2011 SAE International 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 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 systemlevel 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 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. 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. 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. Block Opaque Behavior i 1 i 1 o 1 o 1 i 2 i 2 o 2 o 2 i 3 i 3 o 3 o 3 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). Block Opaque Behavior P 1 :FS 1 p 1 _i 1 p 2 _o 1 P 2 :FS 2 i 1 o 1 i 2 p 1 _i 2 p 2 _o 2 o 2 i 3 o 3 p 1 _i 3 p 2 _o 3 <<Flow Specification>> FS 1 i 1 :input i 2 :input i 3 :input <<Flow Specification>> FS 2 o 1 :output o 2 :output o 3 :output 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 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.
SysML block i 1 i 2 i 3 CSP o 1 o 2 o 3 exchange, diff, merge, i 1 i 2 i 3 CIP o 1 o 2 o 3 Scade operator System-side Component Specification Proxy (CSP) Figure 4 SysML-Scade synchronization. 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. Page 6 of 11
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 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 ) Page 7 of 11
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 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: Figure 1 Technical architecture of SCADE System. 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 Page 8 of 11
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 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. Experimentation on system modeling for avionics equipment for helicopters is in progress. The objective is to compare the current process based on a custom database system with the SysML capabilities to specify such systems. The advantages of a graphical description that includes all system design details kept in dedicated stereotypes have been demonstrated. The model is now ready for clean report generation, which provides a much better shared understanding by all teams. In this system, the SW part was previously developed with SCADE Suite and certified to DO-178B by EASA at level A. The door is now open for advanced verification that encompasses system and software description with tools that can plug into the SCADE System architecture. This is 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. Page 9 of 11
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, N. Halbwachs, P. Caspi, P. Raymond, D. Pilaud. Proceeding of the IEEE, September 1991. 11. A Conservative Extension of Synchronous Dataflow with State Machines, J.L. Colaço, B. Pagano, M. Pouzet. EMSOFT 05 12. Bridging UML and Safety-Critical Software Development Environments, Alain Le Guennec, Bernard Dion. ERTS 2006 13. SCADE 6: A Model Based Solution For Safety Critical Software Development, François-Xavier Dormoy. ERTS 2008 CONTACT INFORMATION Thierry Le Sergent Esterel Technologies thierry.lesergent@esterel-technologies.com Alain Le Guennec Esterel Technologies alain.leguennec@esterel-technologies.com François Terrier CEA, LIST, Laboratoire d Ingénierie dirigée par les modèles pour les Systèmes Embarqués mailto:francois.terrier@cea.fr 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 Page 10 of 11
ACKNOWLEDGMENTS This work has been partially founded by the FP7 ICT-2007 INTERESTED project and by the FUI 5 th call LAMBDA project. APPENDIX Figure 5 SysML IBD and BDD, and SCADE Suite design in the same framework. Page 11 of 11