Timeline and Deliverables for Migration from Scade to an open alternative

[jastram]

The following represents a mini project-plan for this important backlog issue (US-Scade-to-Open). @dalzilio - please adapt as you see fit.

Deliverable

The output of this task will be a document that contains:

• A high-level description of the Scade Artifacts from WP3 and WP4, both content and format
• A high-level description of the open alternatives
• Selection of the most promising alternative(s)
• Detailed migration path to the most promising alternative

  Timeline

• Week 40: Outline complete
• Week 42: First draft
• Week 44: Document complete
• Week 46: Review complete

[dalzilio]

Hello Michael,

Sorry for answering you so late.

I will propose an outline for the report at the next WP7 Friday meeting. I have already received the documentation on Scade from Uwe Steinke at the end of August but I have not been able to look in depth at the OpenETCS Scade model since we do not have a Scade licence locally. (I have followed the discussion on the evolution of the model but I am not sure to have the last, up-to-date info on the models that is on github).

We have already scheduled a meeting next week in Toulouse, with Marc Pantel and others local researchers, in order to converge quickly on a good proposal. I will keep you posted.

Sincerely,

Silvano

On 25 September 2015 at 08:39, Michael Jastram notifications@github.com wrote:

The following represents a mini project-plan for this important backlog issue (US-Scade-to-Open). @dalzilio https://github.com/dalzilio - please adapt as you see fit. Deliverable

The output of this task will be a document that contains:

• A high-level description of the Scade Artifacts from WP3 and WP4, both content and format
• A high-level description of the open alternatives
• Selection of the most promising alternative(s)
• Detailed migration path to the most promising alternative

Timeline

• Week 40: Outline complete
• Week 42: First draft
• Week 44: Document complete
• Week 46: Review complete

— Reply to this email directly or view it on GitHub https://github.com/openETCS/toolchain/issues/500.

      Silvano DAL ZILIO           CNRS / LAAS - Vertics Group
 http://www.laas.fr/~dalzilio  Tel: +33 561 33 78 20 Fax: - 64 11

7 avenue du Colonel Roche, BP 54200, F-31031 Toulouse Cedex 4

[jastram]

Hi Silvano,

Thank you for the update. I'll put you on Friday's agenda.

Best,

• Michael

[dalzilio]

Description of the existing solution

• a brief explanation of the choices that leads to the selection of Scade and a posteriori evaluation of the strength and drawbacks of the Scade suite for the OpenETCS project
• high-level description of the current Scade model

What were the decision on modeling; what are the choices in modeling that are directly influenced by the choice of Scade ; what was very useful to the modeler in the tooling ; influence of the modeling choices on the execution platform (does the modeling precludes some implementation choices)

Existing open-source solution around (or similar to) Scade

• link with the Lustre language and existing open-source tooling for Lustre, e.g. lus2lic or prelude, open-source lustre/Scade compiler ; readability of a pure Lustre model when compared to Scade ; licensing issue
• possibility to choose another language that can embed Scade (not necessarily synchronous), e.g. a subset of Simulink, for which there is equivalent tooling available and better open-source support^
• issues concerning the certification of the tools (project requires EN50128)

Choice of a Domain Specific Modeling Language (DSML)

• a posteriori evaluation of the use of SysML ; possibility to "reverse engineer" a DSML from the existing Scade code

Possible migration path to one or several possible alternatives

[dalzilio]

Goal of this Project (what do we want)

We can try to establish a wish list:

• loose as few information as possible (close to round-trip conversion)
• solution is already existing or at least partially completed
• available tooling for the format (editor, simulator, formal verification, ...)
• integration in the OpenETCS toolsuite
• SysML integration
• is the translation semantics-preserving ? (use of a discrete time semantics)
• traceability
• certification (look at the output of WP2; any reference to a particular deliverable !?)

We do not expect to have a working implementation for the end of the project but we can define a roadmap of the possible scenarios for a following project.

Supported Output Formats from Scade Suite

• XSCADE

XML format keeping all editor-specific information (see Sect. 2 of TechnicalManual_SC-TM-R16). Advantage: no information loss Disadvantage: format not very well-documented (related XML Schema not provided !?)

"parsers" are available from OSATE plugin and the S3 tool by Systerel (see below).

• SCADE

SCADE Suite KCG can generate a kcg_xml_filter_out.scade file which contains the translation of the graphical SCADE format into a textual format Advantage: no information loss; except for the placement of graphical elements if we want to target a graphical format ; easier to parse Disadvantage: format not very well-documented

"parser" available in the Scade2B project (https://github.com/cercles/scade2b)

• KCG

textual format close to Lustre Advantage: Many open-source Lustre implementation are available Disadvantage: we loose the state machines and many information on the underlying "architecture" of the model (hierarchical components are flattened) ; name of variables and ports are quite obfuscated ; KCG is an extension of Lustre

Lustre is not a normalized language and the existing implementations have slightly different syntax. There are some works that have addressed the problem of converting "Scade's version" of Lustre to, for example, VERIMAG Lustre. Nonetheless none of these tools are mature.

Possible Scenarios

• Conversion to the AADL
  • See http://www.aadl.info/aadl/currentsite/
  • The OSATE 2 Eclipse plugin provides an importer from XSCADE to AADL
  • Each component in the diagram is mapped into an AADL system component
  • SCADE component connections is mapped using AADL event data port connections
  • SCADE state machines are translated into AADL behavior state machine
  • we need to test the transformation on the current Scade model
• Conversion to HLL, Intermediate format of Systerel S3 tool
  • the tool is based on a XSCADE parser ; need to extend HLL or adapt the transformation to better take into account (nested) state machines
  • HLL has already been used succesfully on the OpenETCS Scade model (https://raw.githubusercontent.com/openETCS/validation/master/VnVUserStories/VnVUserStorySysterel/05-Work/S3/Proof_SoM/Modes.hll)
• Conversion to SysML with added behavioral information in Lustre
  • Scade Suite provides an extension mechanism based on the use of TCL scripts.
• Conversion to Simulink (!?)

Particularity of the OpenETCS model

• use of a large number of (complicated) types
• heavy use of state machines, se for example the ManageLevelsAndModes (https://github.com/openETCS/modeling/tree/master/model/Scade/System/ObuFunctions/ManageLevelsAndModes/Modes)
• use of iterators, that are not supported in other flavors of Lustre and other comparable languages, e.g. Simulink

[jastram]

This can be closed now, as the resulting document is tracked via #505 .