Please review the draft of modeling steps

[BaseliyosJacob]

Dear all,

i am really looking forward to have you comments on this modeling draft

[janWelte]

Could you give us a short explanation and how do you want us to comment?

[BaseliyosJacob]

Hello Jan,

as this is just a proposed draft it will be great if you can give me your comments on the issue tracker. The comments will be the input for us to create a document with a common understanding from the partner. This draft should be discussed during the Brunswick meeting and in this case i see the conversation on the issue tracker as a preperation for the meeting in Brunswick. Therefore i will create a document. Do you have another idea? You want me to create a document with the explanations already now?

[janWelte]

No, perfect, I just needed the full picture, where are you coming from, so to target my comments right. This is a very good point for a first start of a document and I'm happy to provide you with comments and my understanding of the needed work.

[MariellePetitDoche]

I have several question to understand your proposal.

Could you give some details on how to proceed for the 2 double arrows from ERA inputs to formal high level model ?

Could you give details on how your process can be integrated in the toolchain ? expecially what are the common elements with the proposal Fig 5 in D7.1 ?

In such a picture what is the added value of SSRS ? What is its aim and contents ?

Why there are no links between inputs and SSRS ?

How to proceed on low level of the formal model with inconsistencies which can come from the both directions : SSRS and high level formal model ?

[BaseliyosJacob]

@janWelte: you will find the picture in the new Draft of the SSRS DoW. I just ask Bernd to put it on Git-hub. As soon it is availabe i will post it. If you need the Visio file i can send it to you!!

[BaseliyosJacob]

@MariellePetitDoche

Thank you very much for your questions and feedback.

I will try my best to answer all the questions.

Could you give some details on how to proceed for the 2 double arrows from ERA inputs to formal high level model ?

The direction of the Arrow from the SRS to the High level model will be directly. We have just to consider that the SRS is not complete and so some informations will lacking. In this case i have to agree on your suggestion that a System Analysis is necessary - and if you see the System Analysis is a part of the SSRS work i will be o.k. with that.

Going to the other direction: The Arrow from the High level model to the SRS will be substituded by the Change Request according to the QA plan.

Could you give details on how your process can be integrated in the toolchain ? expecially what are the common elements with the proposal Fig 5 in D7.1 ?

As a input we have in the Figure 5 the EFS Content, Rail Knowledge, SRS, ..... - here i dont see any issue. This will be not in contradiction to my model.

In Figure 5 we have a SysML Papyrus model - I see this as the system analysis - if the system analysis should be a part of the SSRS i see no contradiction.

In Figure 5 we have a system analysis in prose - from figure 5 i can derive that this will be in parallel to the system model. - there i see a contradiction with my model. But to have a path from the Model to the SSRS will be completly o.k. for me. But i am not happy with double arrow from the system analysis on prose to the SRS. There i think we have to deal with the CR process.

In Figure 5 you will have a semi-formal model. This should not be in contradiction with our model.

In Figure 5 you have a fully formal model and a code generator. This should be not in contradiction with our model.

In such a picture what is the added value of SSRS ? What is its aim and contents ?

The aim of the SSRS is to add the necessary clarifications, documents and decisions to the SRS. But as this will be more putting some delta informations/artifacts as a rewriting of the Requirements i think we can do this in parallel.

Why there are no links between inputs and SSRS ?

If there is a link between the inputs and SSRS we have to solve the traceability issue. But i see there a indirect input for some reasons and a direct input for the system analysis (if you see the system analysis as a part of the SSRS).

How to proceed on low level of the formal model with inconsistencies which can come from the both directions : SSRS and high level formal model ?

Same as the question before. We have to clarify the issue of parallel paths and traceability.

So Marielle, i hope i could give you a little bit a view in the minds behind the model steps. As already mention, this is just a proposed draft and i really appreciate to have feedback from you and the partners.

My aim is to discuss this model in the brunswick meeting. For this case i will try to clarify already some questions to have description that will fit and understand by the partners.

Thank you very much

[BaseliyosJacob]

@janWelte : here you will find the link to the new DoW with the model!! https://github.com/openETCS/SSRS/blob/master/DescriptionOfWork/DoW_SSRS.pdf

[MariellePetitDoche]

IMHO, SSRS is a part of system analysis : SSRS is one of the documents which content the conclusion of the system analysis and which shall be the reference for the following step of design. System analysis shall define:

• organic and functional architecture of the system
• interfaces between system
• a SSRS for each sub-system with allocation of the requirements from the inputs

According Cenelec standard, such results are highly recommended as input of the modelling and design phases in view to obtain a SIL4 software. What is explained on Fig 5 is that a "prose" system analysis phase is necessary before to start formal modelling, and that the inputs of this system analysis are ERA documents (SRS, FIS,...), operator and railway knowledge,...

I understand in your proposal that SSRS is build without any input. How do you proceed ? I think the main traceability step shall be during the system analysis phase when requirement are allocated to the sub-systems and the functions. Once this allocation is settle (by prose, spreadsheet, or any tool dedicated to requirement management) traceability on the formal model can be easy to manage (and automatic step can be covered by tools). Indeed, during the system analysis, all the inputs requirements to take into account are clearly identified (and clarified) and a reference repository of requirements can be defined. Traceability during the modelling phases can take as reference this repository and can be partly automatized (some example have been given with ProR and Event-B).

By building a formal model from the heterogeneous inputs we have, I do not see how we can ensure direct traceability between the inputs and the model and how we can proceed to the verification of this traceability.

[cyrilcornu]

Thank you for providing this scheme Baseliyos. I share Marielle's questions about this scheme regarding the SSRS position in the Formal Design of our system. Indeed, the SRS subset26 is in our understanding an ERTMS tool box that needs to be analyzed in order to have a functional description of our system, a functional and organic architecture, a sub-system interface specification... All these elements can be provided by a system analysis, and are (to me) a necessary step before creating a formal model. This conclusion comes from our early activities (CEA + All4tec) on modeling straight from the subset26, where we faced numerous choices or shortcommings not answered in the Subset26. A SSRS encompassing informations from such a system analysis would be sufficient to model with formal properties (at least an unambiguous behaviour on our SysML model created with Papyrus). So to me, the SSRS is the step between the SRS and the formal model in the scheme (so has the same abstraction level as the formal model).

[BerndHekele]

Dear All, is this issue still open?

[BerndHekele]

I see those topics covered by the documents D2.3 and D2.4 ijn the updated version. Therefore, I close this issue. Please, feel free to re-open if I got this wrong.

Bernd