Skip to content

D7.1 review

Jump to bottom Edit New page
stanpinte edited this page Sep 10, 2013 · 30 revisions

This week (as of 4-Sep-2013), the D7.1 is in a crucial phase. In particular, it seems difficult to agree on a conclusion and recommendation. While a lot of documentation exists in the issue tracker, the information there is hard to understand.

First, all issues regarding conclusion and recommendation have been tagged with D7.1-Recommendation. There are currently six issues, feel free to tag more if you think an issue should be included in this group.

Second, the following is a list of core ideas, implied by those issues. I would like you to:

  • Look through the list to see whether important core ideas are missing. (This is only meant with respect to conclusion and recommendation.)

  • Look at each core idea and see whether your name is listed underneath, either with a + (you agree) or a - (you disagree). If your name is missing, please:

  • Add your name

  • If you would like to provide a justification, comment an appropriate issue, and provide a link to that issue.

Scade Core Ideas

S-1: Scade cannot become part of the openETCS toolchain in the long run.

S-2: Scade cannot do formal Verification well.

    • Pierre Francois: Internal experience hints to that this is not the case.
  • o Matthieu Perin: Maybe Good at verification of structure and bad at behavior
  • o All4tec (Frédérique + Cyril): Depends on what we are talking about. Scade Suite, based on lustre, allows formal Verification. Scade System, based on papyrus, doesn't allow such formal verification.

S-3: If we work with SCADE, we need to find a way to make it affordable.

S-4: Scade is the only viable option to get started NOW

EFS Ideas

E-1: EFS is ready to be used for WP3 modeling now, what's missing can be produced within the openETCS timeframe.

E-2: EFS does not do formal Verification and therefore at the least needs to be complemented, e.g. by SCADE.

E-3: EFS is better suited to support V&V activities

B Ideas

B-1 A B-based solution cannot be used any time soon

Other Ideas

O-1: EFS and B may be pursued in parallel, but a single tool must be picked by 1/2014 the latest.

O-2: We need a Scade and an EFS team, working in parallel, synchronizing their work.

  • Marielle, not feasible as part of WP-3
    • Matthieu: minus, if redundant for the same purpose.
    • Matthieu: plus, if traceability and reuse can be achieved.

O-4: By standardizing input and output of a tool, the transition between tools can be managed.

O-5: There should be a collaboration with Polarsys

  • o Marielle: Fundamentally fine, but who should do it?
  • o Matthieu: Great opportunity, but many questions open
  • o David: Like Marielle and Matthieu.
  • o Stefan: Lots of details missing.
  • o Frank: same
  • o All4tec: same: what would it be for?

O-6: We don't have to decide on what comes after SysML right away

    • Marielle
    • David
    • Alexander
    • Matthieu
    • All4tec

O-7: The model to start with is the SysML model

This implies that the SysML model ist not a derived model

Proposed Conclusions/Recommendations

Very briefly summarized, I believe we have the following conclusions/recommendations. Please add one if one is missing. This is about describing the possible solutions on a high level, please don't add a solution if you have a minor squabble:

C-1: Two model teams, one for EFS and one for SCADE.

This is what's currently in the Latex.

Supported by: S-1, E-1, E-2, O-1, O-2, O-4,

C-2 SCADE for modeling, EFS for V&V

With the understanding that all closed tools shall be replaced in the long run.

Supported by: S-1, S-2, S-3, S-4, E-3, O-3, O-4

Core Ideas not mentioned.

In the above conclusions, not mentioned are: B-1, O-5

Add a custom footer
Add a custom sidebar
Clone this wiki locally