D7.1 Review of appendices B. Papyrus/EFS/Eclipse-Polarsys chain

[MariellePetitDoche]

From https://github.com/openETCS/toolchain/issues/111

@cponsard:

• [ ] use of "Polarsys" should be with caution, see discussion about not confusing industry working group with tool developer (currently tools are not yet available through polarsys)
• [x] B.1 should refer more explicitly to figure B1
• [x] target source code box: have we already identified such Eclipse/Polarsys tools or are we talking about technologies enabling to produce such tools ? make a link to work (secondary tools) that will investigate this
• [x] B.2 the questions raised there are important. How will we answer this is there already some comparative study of the expressiveness of SysML vs EFS ?
• [x] B.3 should state the implementation lgge of EFS in the scade section there is a discussion about the need or not to have graphical editing within Eclipse. The discussion should also take place in both places or not at all.
• [x] B.4 maybe mention how traceability to subset 26/76 is achieved the interface EFS => Scade should probably also recaped in a more general section summarising the possible cross-over scenarios between toolchains
• [x] B.5 section on code generator should mention the need or not to qualify the developed code generator
• [ ] an additional shortcoming about the semantics of EFS was mentionned in the tool review. can this be a risk in a toolchain perspective, mainly for the link with code generation ?
• [x] B.6 redeveloping EFS in Eclipse looks an important task. Is it realistic (knowing the effort for developing the existing version and how faster we can go starting from there and using today's technologies)
• [x] B.7 conclusions: objectively, more arguments are necessary to claim it is realistic given the need to interface both upstream to SysML and downstream to code generation.

[stanpinteTheSignallingCompany]

B.1 fixed in https://github.com/openETCS/toolchain/commit/a73b74f8421346821caf250aad6681b2de172f4a

[stanpinteTheSignallingCompany]

Regarding B.6, I confirm redeveloping ERTMSFormalSpecs workbench in Eclipse is a significant amount of work. @JonasHelming estimated it at more or less 1 Person Year effort.

However, in B.6 we provide two alternatives: "Either implement a full eclipse-based version of the ERTMSFormalSpecs workbench for model development, traceability and testing, or improve the ERTMSFormalSpecs user interface to be fully productive for T3.5 and T3.6 tasks".

Option 2, enhancing ERTMSFormalSpecs, is more limited, as ERTMSFormalSpecs workbench has already been used to model 44% of Subset-026, and has no major drawback identified today preventing reasonably efficient Subset-026 modelling and testing. For that purpose, our ERTMSFormalSpecs toolchain @LaurentFerier is already available during the full duration of the OpenETCS project.

[stanpinteTheSignallingCompany]

target source code: fixed in https://github.com/openETCS/toolchain/commit/7a911f542106877396bbfd427867d814b08a4496, by pointing to shortcomings and ongoing work sections

[stanpinteTheSignallingCompany]

@cponsard: B.5 code generator doesn't need to be qualified for OpenETCS primary objectives. Added note in https://github.com/openETCS/toolchain/commit/2834c95f41b44bcef23f436adf12af6181f4ea15 and https://github.com/openETCS/toolchain/commit/96bfddd37eadd07ce7f22861cef79a8a37334ba0. See minutes of charleroi meeting for justification (https://github.com/openETCS/toolchain/commit/55ff4f79ea06380a03db31bc3b12234e55e9d601)

[stanpinteTheSignallingCompany]

@cponsard : what would you suggest, for the use of Eclipse/Polarsys keywords? That I replace "Eclipse/Polarsys" by "Eclipse" alone?

[stanpinteTheSignallingCompany]

@cponsard: "is there already some comparative study of the expressiveness of SysML vs EFS ?"

As of today, there is no comparative study.

However, inside ERTMS Solutions, we modelled 44% of Subset-026 without the use of SysML. Therefore, for us, SysML is not in the critical path.

We are open to all suggestions from SysML specialists on how it could enhance or accelerate modelling of Subset-026. Especially, as soon as modelling in WP3 officially starts, we would welcome any SysML forces to 1/ study the comparative expressiveness of SysML and ERTMSFormalSpecs and 2/ to develop the ERTMSFormalSpecs <--> SysML model interfaces.

[stanpinteTheSignallingCompany]

B3 addressed in https://github.com/openETCS/toolchain/commit/7d2e63fabe1fb04516f6b5a4dfd1eba369170f72

[stanpinteTheSignallingCompany]

B4 addressed in https://github.com/openETCS/toolchain/commit/e6ed8afb162a6c421cc97e31ae0b8c48bc7da17c

[stanpinteTheSignallingCompany]

@cponsard: could you point me to the exact location of "an additional shortcoming about the semantics of EFS was mentionned in the tool review"? I can't find it back, and as of today, we don't have such issue opened in ERTMSFormalSpecs repository.

I want to make sure that, if there is a semantical shortcoming, it is identified, filed as an issue and fixed.

Thanks in advance for your help!

[stanpinteTheSignallingCompany]

Regarding B7,

1/ creating a non-qualified code generator (T-nothing) is really not an issue. Most of the partners agreed on this, to our understanding.

2/ SysML integration is not upstream, but sidestream (see below figure, included in the D7.1 ERTMSFormalSpecs section) and SysML is not in the critical path (we already modelled 44% without using it).

Therefore, I propose to keep the conclusion as it is. This seems confirmed by other issue https://github.com/openETCS/toolchain/issues/134.

[MatthieuPERIN]

Hello all,

I want to react to the question asked to @cponsard:

"is there already some comparative study of the expressiveness of SysML vs EFS ?"

@stanpinte stated that "As of today, there is no comparative study.

However, inside ERTMS Solutions, we modelled 44% of Subset-026 without the use of SysML. Therefore, for us, SysML is not in the critical path."

The debate is here misplaced I think:

• SysML have been chosen to be the repository model of semi-formal model covering subset 26 and other requirements. If ERTMS solution want to use EFS as the repository for such model it will go against the decision taken and I will not accept that as the reviewer to document D7.1 (Figure B1 of D7.1 has to be change in my point of view to be more clear).
• I have starting to study the ecore model you give me of EFS and I have some doubt that this structure of data may be used to generate C code, as a strong amount of work is to be done to clarify some part of EFS meta-model.
• SysML expressiveness is UML expressiveness so it is basically unlimited (I agree that some specific case may still be hard to model) using profile and other tools. EFS language is domain specific and so it expressiveness is limited to the domain it match by construction. The 44% already modeled in EFS may be integrated into SysML using Model to Model transformation.

[stanpinteTheSignallingCompany]

@MatthieuPERIN

Dear Matthieu,

I think there a first misunderstanding regarding what is called "semi-formal model". My understanding is that the semi-formal model should represent 100% of Subset-026 in an understandable, executable, testeable way, as well as enable the possibility of generating source code. This is what ERTMSFormalSpecs has been designed for.

Also, in my understanding, the decision about SysML was to use it for high-level system design, which is not the same, as far as I am concerned, than semi-formal model. For instance, SystemSCADE (correct me if I'm wrong), enables the SCADE users to design modules and interfaces (= high-level design), and this generates stub for lower-level formal SCADE model. After that, users fill the actual behaviour in SCADE directly.

Therefore, the high-level system design is not executable, and doesn't allow the generation of source code directly. The semi-formal model does.

Very kind regards

Stan

[JonasHelming]

@MatthieuPERIN : What is a "repository model"?

[MatthieuPERIN]

@JonasHelming

To me a "repository model" is a model where to stock and organize data and knowledge from several source in order to be used by several users. The main idea there is to propose a common model to ensure filling/reading capabilities for all partners of the project.

In my opinion SysML is really suitable for this, but another solution me be used.

[MatthieuPERIN]

@stanpinte

Dear Stan,

For me we have to clearly separate the definition and the use of what we call a semi-formal model.

Definition: A semi-formal model is a model with some formal parts (eg in SysML: the block, relation, composition concepts) and some less formally defined parts (eg in SysML: relation between ports and unarity, state machines, textual requirements...).

Use: In OpenETCS, the semi formal model have to hold the SSRS knowledge as stated in introduction of D7.1 § 1.3 "This model shall reflect the architecture defined in SSRS. (...) The semiformal model shall be as consistent as possible with the SSRS level of abstraction, in particular choices concerning software architecture and design have not to be described at this level. In practice, all the requirements of SSRS and of the sub-system Hazard analysis shall be covered by the semi-formal model."

To me, the semi-formal model have to hold both the SSRS using SysML requirements -and some behavior diagram if needed to clarify understanding-, and the functional architecture at high level, with maybe some part of lower-level if needed.

In order to link the SSRS to the SRS, it would be nice and very useful to also integrate the SRS (or ESRS as Klaus proposed) into the SysML in order to maintain traceability and coherence.

But as I asked in #144, the SRS semi-formal model executability is still a -very- open question to me as the subset 26 requierments may be very far from code-level specification.

Executability of SSRS semi-formal model is a true question as we may have some low-level requirements that need to be verify, solutions exist within UML/SysML (using ALF framework) but are not mature enought at this time, but link to other tools of V&V may be provided if semantics of behavior requirements are well defined.

Your understanding of use of SysML is too limited to me, referring to the previously cited §1.3 of D7.1.

Finally, what you wrote considering the semi-formal model and the high level architecture capability to generate code is incorrect if your refers to the semi-formal model of the SRS (the need of architecture design of system and sub-system is mandatory before going to code-level).

The architecture design is the skeleton of the code generation and is mandatory to me, and I do not see a semi-formal model -even of the SSRS- to be sufficient to generate one-click code without defining detailed code-level requirement.

Very kind regards

Matthieu

[stanpinteTheSignallingCompany]

@MatthieuPERIN

Dear Matthieu,

It seems to me the discussion should be held on the phone...I think we don't disagree on everything :)

feel free to suggest any time suitable for you.

Very kind regards

Stan

[MariellePetitDoche]

Review meeting (03/09/2013): Technical points to fix during phone call between reviewers and author of appendix B.

[cponsard]

for the conclusion, it only highlights the strong points but not some uncertainties, e.g. about the part of the toolchain after EFS. The conclusion should be aligned with the summary given in section 2.1 and reformulated in #134

[jastram]

Two issues have not been addressed yet: (1) Polarsys, but this is now explicitly mentioned in the decision chapter (0296440b4c8e61b6c6dcde2777415d34199a94d7). And semantics, for which I opened #149. Therefore, this issue can be closed.