Review of Scade-2-Open-Migration Document (ends: 12-Nov-2015)

[jastram]

Please review the Scade-2-Open-Migration Document.

Reviewers:

• Silvano Dal Zilio dalzilio@laas.fr
• Peter Mahlmann peter.mahlmann@deutschebahn.com
• Marc Behrens Marc.Behrens@dlr.de
• Xavier ZeitounXavier.ZEITOUN@cea.fr
• Raphaël Faudou raphael.faudou@samares-engineering.com
• David Mentré d.mentre@fr.merce.mee.com

Reference: Review Process

[mahlmann]

@dalzilio @MarcBehrens @raphaelfaudou @MERCEmentre ... just mentioned reviewers by gitname to make them aware that the review started. I am not aware of Xaviers gitname though.

[dalzilio]

Xavier gitname is XavierZeitoun

On 2 November 2015 at 15:18, Peter Mahlmann notifications@github.com wrote:

@dalzilio https://github.com/dalzilio @MarcBehrens https://github.com/MarcBehrens @raphaelfaudou https://github.com/raphaelfaudou @MERCEmentre https://github.com/MERCEmentre ... just mentioned reviewers by gitname to make them aware that the review started. I am not aware of Xaviers gitname though.

— Reply to this email directly or view it on GitHub https://github.com/openETCS/toolchain/issues/505#issuecomment-153028803.

      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

[MERCEmentre]

Hello Silvano,

@dalzilio: I put my answers online.

Here is my review:

• In §1.3 (drawbacks), is a distributed architecture a real issue for SCADE? In case of distributed architecture, I would expect doing a SCADE model par CPU unit so the synchronous hypothesis would be still valid on each CPU. What do you think of it?

@dalzilio: the real problem is with functions that are mapped on different processors but that share a common stream of events (and therefore must be synchronized), hence the "frenzy" about GALS systems. I do not think that Scade provide a solution to this problem.

• In §2 (goals), you should add open-source target software as first explicit goal (it is a strong requirement)

@dalzilio: done

• In §4 (possible scenarios): why don't you consider translation to Scilab/Xcos?

@dalzilio: I haven't found any existing tool for exporting to Simulink or open-source equivalent like Scilab/Xcos; actually I think that, in the long run, this could be the best solution but it is also the one with the more risks associated to it and the one that requires the more efforts. This is why I decided not to include this discussion in the report. I have added a remark on the conclusion about this.

• In §4: why don't you consider translation to AADL model?

@dalzilio: I wanted to limit adding noise to the presentation. Again AADL could have been a good choice at the beginning of the project but: (1) tooling is still quite weak; and (2) the distance is too big from the existing model, which means that the modelling team (if it should still work on subsequent models for the ETCS) would have to start from scratch learning a new language.

• In §4: I think you should tell very briefly why a possible scenario was rejected
• In §4.1: "preludec" is compiler of Prelud language?

@dalzilio: rewrote this part to be clearer

• In §4.1: for "Maintainability", we loose the graphical representation of SCADE and associated semantics information
• In § 4.2: "extension of SysML"
  • For "Certification", why is it "BAD" and not MIXED as for the previous solution?
  • As good point we could keep graphical representation
• In "References", for [2] it is "Deliverable D3.5.3" (and not "Deliverable D.5.3")

@dalzilio: corrected

Typos:

• "close-source" -> "closed-source" (p. 1)
• p. 8, missing word: "but the resulting diagrams only contains information XXXX the functions and their interfaces"

Best regards, david

[raphaelfaudou]

Hello Silvano,

@dalzilio: my comments online, like in the previous case

completing remarks from David, here is my review: in 1.2, I am not sure to understand the sentence "Unfortunately, the SysML (architectural) model obtained from a Scade specification does not preserve all the information. It only keeps states machines and some information at the level of the interfaces; the detailed code related to the functions and the state transitions is left over. Therefore we cannot simply use the output of the Scade system tool for our migration ». Do you mean that Scade System could be used as an intermediate language between Scade language/tool and Papyrus SysML? It would mean that Scade System can import Scade model or that Scade suite can export Scade model to Scade System . Does it exist?

@dalzilio: I cannot answer with certainty to your question (this explain why I do not state it clearly in the text and why I have asked this question to Xavier Zeitoun ;-)). From discussions with "commercials" at Esterel (Francois-Xavier Dormoy) I understood that some support is available, even if not directly ; from discussions with "engineers" at Esterel, I understood that it is not possible (i.e the same answer than Xavier Zeitoun). I will amend the report to state the current situation more clearly.

1.3: perennity of the models: there is a (albeit small) risk that the current Scade toolchain will be discontinued in the future, especially when we take into account the very long service life of railway equipments. What is important to mention here is not « perennity » of model but perennity of model editor, in order to be able to continue editing models even if tooling is discontinued (what can also exist with open source). Close source puts more risk on « long term support » of the tool chain because you cannot subcontract continuation of the tool if sources are not available …

@dalzilio: added the remark

1.3: dificulty to have special needs taken into account by the software editor, or services added to the baseline tools. It should not be very difficult if you pay much for those special needs ;-) I would say it differently: « with close source editor, there is no way to ensure that a special need will be taken into account at some point in time. With open source, you can either contribute the special need (patch addition or commit if authorized) or create a branch in case tool project team does not want to accept your contribution. It seems to be the same idea than « vendor lock-in ».

1.4 => we need to target a language with a rich type system I would rather say « a language with custom data type definition » to avoid « rich » which may be ambiguous and let think of something very elaborated.

@dalzilio: added the remark

1.4: I do not really see the link between « heavy use of state machines » and hierarchical model. we can have a lot of state machines but a very « flat » model, no?

1.4 : The Scade models make use of most of the Scade v6 operators ... It does not mean that we cannot use LUSTRE. In case we want to use LUSTRE, we can define a modelling rule for SCADE use: « do not use SCADE V6 operators any more in order to ensure (improve) backward compatibility to initial LUSTRE language ».

@dalzilio: answered by Marielle

1. Perhaps we can rank those criteria or separate them into « mandatory » and « nice to have » because some of them seem far more important than others (at least for me). I would put « preserve semantics » and « certification » as « Mandatory » because : preserve semantics: we can not afford to check and modify semantics by hand after migration or in a very limited way. certification: Scade choice is often motivated by its ability to generate code with a « qualified » code generator. Without « qualified », source code must be verified and it is very time consuming. with « qualified » you can verify model. So for me this is a key point for the target tool: it should be « qualifiable » (meaning that qualification should not be seen as unfeasible or very long).

3.1 "Diagrams can also be viewed from the Scade System tool, which means that there should be an EMF description (an ecore file) for the Xscade format » From my knowledge and understanding of Scade System tool, I disagree with that conclusion. Scade System tool combines two environments: the workbench is the same than Scade tool (in order to reuse all services/commands offered by the Scade tool suite) and a gateway to Eclipse environment, in order to load and store SysML model in Eclipse Papyrus format. Scade System tool can see XSCADE diagrams because it reuses same parsers and editors than Scade tool (same environment) but gateway with Eclipse EMF world is probably limited to SysML models. So I do not see reason why Esterel would develop also a gateway to EMF for Scade diagrams…

@dalzilio: changed to "..., which means that there should be an EMF description (an ecore file) for at least a subpart of Xscade format (namely the subpart dealing with state machines)"

3.1 "Scade System provides capabilities to develop specific export functions using OCL, the TCL scripting language and a specific Java model API. » Yes, but for SysML models. I’ m not sure at all that such export functions can be used on XScade diagrams even if Scade System can visualize those XScade diagram (this is a different feature).

3.1 "“retro-engineered parsers »

For me it is clear that this solution is very risky if we want to use it concurrently with Scade modeling. Who will engage on maintaining those parsers when Scade suite evolves? Ansys might decide to change their internal format what would make the retro engineering far more complex in the future releases. Such approach can be used if there is « one shot » migration, meaning that Scade tool is not used anymore to update model after first migration. For me that is the key strategy to decide. If yes, then those parsers can be used but are applicable on a limited defined list of Scade tool versions. In « disadvantages », add « no guaranty that those tools can be used on future versions of Scade ».

@dalzilio: we rather target the "one shot" scenario but, of course, a sustainable solution would be better. Added a comment to this end

3.2: do we really need to preserve graphical format? is there any semantics given by Scade graphical format? if not, we can imagine to generate automatic layout from model and this issue can be removed.

3.4: "Therefore it is possible to obtain an architectural description of the OBU models in SysML, but the resulting diagrams only contains information the functions and their interfaces; the detailed code related to the functions and the state transitions are missing and should be added separately. » I think that such formulation is confusing as you might think that SCADE Suite can always export part of SCADE model to SCADE system environment. In fact what exists is a synchronization between models on « shared" blocks and their inputs and outputs. It means that if you start using Scade System to define the different software blocks, then you can refine those blocks with SCADE suite, evolve both models concurrently and ensure synchronization of blocks with their data interfaces. see http://www.esterel-technologies.com/products/scade-suite/ about Scade suite integration. So, it is normal not to find software block content nor state machines because they are not part of the information synchronized between SCADE System blocks and SCADE suite blocks.

@dalzilio: taken care with the update on Sect. 1.2

4.2: what about using « fUML » as a formal specification of behavioral model? fUML is an OMG standard subset of UML Activity diagram concept that can be used in textual form. We can imagine a mapping to HLL or to Lustre for the behavioral part.

@dalzilio: added some comments about fUML

4.2: I would say «MIXED » for certification because with fUML you have find executable models with fUML-based simulation tools… which means that there are good formal foundations and standard for this approach, which are two good steps toward reaching tool qualification.

Best regards Raphaël

[MariellePetitDoche]

Some comments:

• §1 : "The architectural model (written in SysML using the Scade system tool) and the functional model (written in Scade using the Scade suite tool) have been developed from scratch—without the use of prior components—and cover all the aspects defined in chapters 7 and 8 of the ETCS specification": to clarify:
  • what do you mean by " developed from scratch—without the use of prior components" ?

@dalzilio: I mean without reusing prior code (even if partners, such as Systerel, contributed some prior architectural models) and therefore free of prior IP

• is "ETCS specification" the SRS subset 26 specification ? in this case use the correct name.

@dalzilio: corrected

• in this case, chapters 7 and 8 are the only part without functionnal aspects, developped directly in C (bitwalkers) and for which the only part defined in scade is type and data definition.
• The functionnal part of SRS covered by SysML and Scade models are parts of chapters 3, 4 and 5.

@dalzilio: corrected

• §1.4 "There is a heavy use of state machines in the specification" Indeed what is important to precise is that to simplify the complex model, the designers allow them to use advanced operators of Scade v6 as iterators or nested state-machines. The hierarchy is mandatory to deal with the complexity of such a system. Indeed I do not agree Raphael proposition « do not use SCADE V6 operators any more in order to ensure (improve) backward compatibility to initial LUSTRE language », as not using loops or iterators can not be imagine for concrete real size industrial system as EVC kernel.

@dalzilio: I agree with Marielle here.

• §3.1 S3 is not open source
• §4.2: references for use of S3:
  • an invited paper on the use of S3 in OpenETCS:

@inproceedings{DBLP:conf/fmics/Petit-DocheBCFG15, author = {Marielle Petit{-}Doche and Nicolas Breton and Rom{\'{e}}o Courbis and Yoann Fonteneau and Matthias G{\"{u}}demann}, title = {Formal Verification of Industrial Critical Software}, booktitle = {Formal Methods for Industrial Critical Systems - 20th International Workshop, {FMICS} 2015, Oslo, Norway, June 22-23, 2015 Proceedings}, pages = {1--11}, year = {2015}, crossref = {DBLP:conf/fmics/2015}, url = {http://dx.doi.org/10.1007/978-3-319-19458-5_1}, doi = {10.1007/978-3-319-19458-5_1}, timestamp = {Tue, 12 May 2015 15:14:40 +0200}, biburl = {http://dblp.uni-trier.de/rec/bib/conf/fmics/Petit-DocheBCFG15}, bibsource = {dblp computer science bibliography, http://dblp.org} }

@proceedings{DBLP:conf/fmics/2015, editor = {Manuel N{\'{u}}{~{n}}ez and Matthias G{\"{u}}demann}, title = {Formal Methods for Industrial Critical Systems - 20th International Workshop, {FMICS} 2015, Oslo, Norway, June 22-23, 2015 Proceedings}, series = {Lecture Notes in Computer Science}, volume = {9128}, publisher = {Springer}, year = {2015}, url = {http://dx.doi.org/10.1007/978-3-319-19458-5}, doi = {10.1007/978-3-319-19458-5}, isbn = {978-3-319-19457-8}, timestamp = {Tue, 12 May 2015 15:13:12 +0200}, biburl = {http://dblp.uni-trier.de/rec/bib/conf/fmics/2015}, bibsource = {dblp computer science bibliography, http://dblp.org} }

• the entry of the user story: https://github.com/openETCS/validation/blob/master/VnVUserStories/VnVUserStorySysterel/04-Results/e-Scade_S3/Scade_S3_VnV.pdf

[mahlmann]

Some comments:

• In many places it reads "written in SysML" or "written in Scade". I would propose to use "modelled in SysML" or similar as we do not touch the textual languages in WP3 usually.

@dalzilio: corrected

• First sentence of introduction. "model of the ETCS using" should be "model of the ETCS OBU using"

@dalzilio: corrected

• Section 1.4: The SCADE Suite model has about 13 main components.

@dalzilio: corrected

• Section 2 "Traceability": Traceability is not only done via comments. If done properly SCADE's requirements gateway has been used. However, this has only been done for some of the components to the best of my knowledge (e.g. Manage_TracksideInformation_Integration, calculateTrainPosition)

@dalzilio: information added

• Section 2 "Integration": Concerning the gateway to and from SysML it may be worth mentioning that such a gateway does not exist in SCADE either... although it has been requested more than a year ago.
• Chapter 4: Would it be possible to examplarily transform one component to Lustre and provide an exerpt of the code (i.e. to get a better picture of the readability of the generated code)?

@dalzilio: This is a very good idea but I do not have access to Scade suite. I will try to add this info if someone can generate some code for me.

General remark:

• For the next review consider uncommenting the "\linenumbers" command in the main tex file. There were many typos which are hard to reference without linenumbers.

[XavierZeitoun]

Hi Silvano, Please find below remarks that complete a bit what was said before:

&1.1 I would personally remove the "nice" adjective to the "deterministic" property of Scade language. Deterministic indeed imply easier verification, but it limits expressiveness.

@dalziliio: done

§1.2 I endorse the remark from Raphael on this point but in my opinion, it is the process that translates Scade Specification into Sysml that requires a bit more explanation (currently: "the SysML (architectural) model obtained from a Scade specification") . I guess it results from import in Scade System from scade suite outputs. To my knowledge and from a contact in Esterel, there is no existing tool that performs automatic translation for the code associated to function & transition in SysML.

@dalzilio: added a paragraph with the comments of all the reviewers concerning this issue

§4.2 some frameworks exists for the code generation (some are developed as part of the PapyrusRT project). I would still accept the BAD evaluation since they would require more investigation to see if they are fit to the uses in OpenETCS.

Best regards, Xavier

[dalzilio]

Hello,

I have pushed a new revision of the report that takes into account the comments from all the reviewers.

On 10 November 2015 at 14:13, XavierZeitoun notifications@github.com wrote:

Hi Silvano, Please find below remarks that complete a bit what was said before: &1.1 I would personally remove the "nice" adjective to the "deterministic" property of Scade language. Deterministic indeed imply easier verification, but it limits expressiveness. §1.2 I endorse the remark from Raphael on this point but in my opinion, it is the process that translates Scade Specification into Sysml that requires a bit more explanation (currently: "the SysML (architectural) model obtained from a Scade specification") . I guess it results from import in Scade System from scade suite outputs. To my knowledge and from a contact in Esterel, there is no existing tool that performs automatic translation for the code associated to function & transition in SysML. §4.2 some frameworks exists for the code generation (some are developed as part of the PapyrusRT project). I would still accept the BAD evaluation since they would require more investigation to see if they are fit to the uses in OpenETCS.

Best regards, Xavier

— Reply to this email directly or view it on GitHub https://github.com/openETCS/toolchain/issues/505#issuecomment-155415804.

      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

[dalzilio]

document was accepted; pull request was made

[dalzilio]

link to the deliverable:

https://github.com/openETCS/toolchain/tree/Scade2OpenReport/T7.3/MigrationScade2OpenAlternative

At the moment it is in its own branch of the github.

[jastram]

Silvano,

At the moment it is in its own branch of the github.

Can you please merge this in the master branch? Otherwise it may be hard to find later. I reopened this, please close when merged.

[dalzilio]

merge done.

current link for the deliverable is: https://github.com/openETCS/toolchain/tree/master/T7.3/MigrationScade2OpenAlternative