Review relating to #47 - Githubissues

Part 1: This issue relates to #47.

Chapter 1:

Since the document is not related to a openETCS deliverable or the relation is not stated inside the document, it is not clear where in the development process the document resides.

Chapter 2:

Block Diagram Definition: looks like DMI is composed of EVC. for my understanding the OBU includes the interfaces whereas the EVC + interfaces assemple to the OBU.
Please detail on 'triple bus'. How is it defined.

Capter 2.3:

Block "Actigram": Please detail the concept of "Virtual Machine (Excel)"
How is the "Hardware + basic soft + simulator" defined?
How is ADA C++ generated. For my information SCADE produces C- code.

Chapter 2.3.4

Please define the rationale of using EXCEL. Currently EXCEL does not comply to project goal of OPEN PROOFS.

Chapter 2.3.5

Please detail on the rationale of using ADA or C++ or B
Where should which language be applied?
Is C considered?

Chapter 3.2.1

The linking qualifier (Q_LINK) in general indicating that the balise is known to trackside enables linking data to be used with this balise relating to "linking usable with this balise". The terms "Linking used" or "linking not used" would more probably be applied in case of a packet 5 is valid for this track section and decoded on-board. On this topic an ambiguity within the SRS, so a glossary is of vital importance here.
Unlinked BG: Please detail in which case the unlinked BG can be announced in the current LRBG - contradicts to "can not be announced ..."
"Linked / Unlinked is defined by one header qualifier." - Is Q_LINK meant here? - in this case the possibility to have Q_LINK = 1 and no linking packet 5 is a contradiciton to the statement.
"Linking is defined by packet 5 for all level" - linking is not valid in all ERTC level
"1 level." what is meant by this, please detail.

De : Marc Behrens [mailto:notifications@github.com] Envoyé : jeudi 23 octobre 2014 16:19 À : openETCS/SRS-Analysis Objet : [SRS-Analysis] Review relating to #47 (#48)

Part 1: This issue relates to #47https://github.com/openETCS/SRS-Analysis/issues/47.

Chapter 1:

Since the document is not related to a openETCS deliverable or the relation is not stated inside the document, it is not clear where in the development process the document resides. Response : the document is a SRS Analysis preliminary to any formal specification and modelling.

Chapter 2:

Block Diagram Definition: looks like DMI is composed of EVC. for my understanding the OBU includes the interfaces whereas the EVC + interfaces assemple to the OBU. Response : DMI is seen as one module like BTM (balise), Odometer, TIU, Core, Radio (RBC).
Please detail on 'triple bus'. How is it defined. Response : Triple Bus is a manner to satisfy Requirement in terms of “Safety” and “Reliability”.

Capter 2.3:

Block "Actigram": Please detail the concept of "Virtual Machine (Excel)" Response : « Virtual Machine » is a pure software which starting from “Signalling Implementation Specification” is able to compute braking curve related to every possible signal at stop.
How is the "Hrdware + basic soft + simulator" defined? Response : this is all software or hardware out of OpenETCS scope.
How is ADA C++ generated. For my information SCADE produces C- code. Response : it is not evident that terminal box of scade will not need some software development (or algorithm).

Chapter 2.3.4

Please define the rationale of using EXCEL. Currently EXCEL does not comply to project goal of OPEN PROOFS. Response : EXCEL can be used for proofs through « virtual machine » by computing curves for validation.

Chapter 2.3.5

Please detail on the rationale of using ADA or C++ or B
Where should which language be applied?
Is C considered? Response : is scade able to support all part of OpenETCS ?

Chapter 3.2.1

The linking qualifier (Q_LINK) in general indicating that the balise is known to trackside enables linking data to be used with this balise relating to "linking usable with this balise". The terms "Linking used" or "linking not used" would more probably be applied in case of a packet 5 is valid for this track section and decoded on-board. On this topic an ambiguity within the SRS, so a glossary is of vital importance here.
Unlinked BG: Please detail in which case the unlinked BG can be announced in the current LRBG - contradicts to "can not be announced ..."
"Linked / Unlinked is defined by one header qualifier." - Is Q_LINK meant here? - in this case the possibility to have Q_LINK = 1 and no linking packet 5 is a contradiciton to the statement.
"Linking is defined by packet 5 for all level" - linking is not valid in all ERTC level
"1 level." what is meant by this, please detail. Response : qualifier Q_LINK defines if BG can become LRBG : it is yes if BG is within linking list. If not within list, BG is ignored. If no list, the trend is to ignore too. ….

— Reply to this email directly or view it on GitHubhttps://github.com/openETCS/SRS-Analysis/issues/48.

CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.

Chapter 3.2.2

"Linking exists in message" and "Unlinked BG": Please explain what "Window is computed" means in this context.
"Linking exists in message" and "Unlinked BG": Please explain what "Train Position is checked" means in this context.
"Linking exists in message" and "Unlinked BG": Please explain what happens if a balise with Q_LINK=0 contains a linking packet 5.
What does "Linking is not used" together with "Linking exists" mean?
Should "Linkin exists in message" mean that the balise is linked inside the packed 5?

Chapter 3.3

Since "Linked / Unlinked is defined by one header qualifier." (Q_LINK) and a Balise can only be LRBG with Q_LINK=1 an "Un-Linked BG" can never be the reference for a MA, thus never contain a MA. This contradicts to "These data are provided by ... “Un-Linked BG” ..."
Relates to "Section : the MA is composed of several section with optional timer to enter" according to SUBSET-026-7.4.2.3 a MA can have zero or more sections.
Relates to "LOA : is the length of MA starting from LRBG, and is terminated by EOA" - according to SUBSET-023 "LOA" is defined to be "Limit of Movement Authority", according to SUBSET-026-3.8.1.1 it is a special case that EOA relates to LOA when the target speed is set to zero.
Relates to "must be covered by SSP and Gradient Profile" - the case that the complete MA is not covered by SSP and gradient profiles exists in SUBSET-026-3.7.2.3. In this case the OBU has to reject the MA. That the SSP and gradient profile is complete is a mandatory requirement for the trackside, not for the OBU.

Chapter 3.3.2

"Standard Speed Profile", according to Subset-023 SSP is defined to be the "Static Speed Profile"
"Value negative for down-hill." according to SUBSET-026-7.5.1.110 the coding for Q_GDIR as used inside packet 21 for downhill is described with "0". In case a separate coding is used, please define in detail.

Chapter 3.4

What about: Override function related Speed Restriction
What about: Signalling related speed restriction (only level 1)

End of review at chapter 3.4

The copyright is not stated inside the document. Which copyright is applicable to the document?

Hi, See response in the text, Cdt, CG

De : Marc Behrens [mailto:notifications@github.com] Envoyé : jeudi 23 octobre 2014 18:01 À : openETCS/SRS-Analysis Cc : GIRAUD Christian Objet : Re: [SRS-Analysis] Review relating to #47 (#48)

Chapter 3.2.2

"Linking exists in message" and "Unlinked BG": Please explain what "Window is computed" means in this context.
"Linking exists in message" and "Unlinked BG": Please explain what "Train Position is checked" means in this context.
"Linking exists in message" and "Unlinked BG": Please explain what happens if a balise with Q_LINK=0 contains a linking packet 5. Response : keep in mind :

   ”LINKING USE” = option of on-board, when train position is considered as enough safe and can be used to position BG. This point of view is still on discussion. But notice that Un-linked BG are commonly used for TSR.

   “LINKING EXITS”  = there is a packet n°5 recorded in data base, therefore a D_LINK related to BG and previous BG is available.

```
   “LINKED BG” = BG can become LRBG. But in any case, BG can provide packet n° 5 that is recorded in data base for future BG.
```
- What does "Linking is not used" together with "Linking exists" mean? Response : linking is not used on board but trackside provides D_LINK without impact.
- Should "Linkin exists in message" mean that the balise is linked inside the packed 5? Response : yes.

Chapter 3.3

Since "Linked / Unlinked is defined by one header qualifier." (Q_LINK) and a Balise can only be LRBG with Q_LINK=1 an "Un-Linked BG" can never be the reference for a MA, thus never contain a MA. This contradicts to "These data are provided by ... “Un-Linked BG” ..." Response : the position of Un-linked BG is given by train position, so the current LRBG can be used as reference…
Relates to "Section : the MA is composed of several section with optional timer to enter" according to SUBSET-026-7.4.2.3 a MA can have zero or more sections. Response : At least, MA is composed of one section whose length can be 0.
Relates to "LOA : is the length of MA starting from LRBG, and is terminated by EOA" - according tu SUBSET-023 "LOA" is defined to be "Limit of Movement Authority", according to SUBSET-026-3.8.1.1 it is a special case that EOA relates to LOA when the target speed is set to zero. Response : EOA is still « End Of Autorisation », and LOA is the associated length. But EOA may be overpassed up to DP (Danger Point) or OL (Overlap).
Relates to "must be covered by SSP and Gradient Profile" - the case that the complete MA is not covered by SSP and gradient profiles exists in SUBSET-026-3.7.2.3. In this case the OBU has to reject the MA. That the SSP and gradient profile is complete is a mandatory requirement for the trackside, not for the OBU. Response : yes, but OBU need to detects abnormal situation and reacts.

Chapter 3.3.2

"Standard Speed Profile", according to Subset-023 SSP is defined to be the "Static Speed Profile"
"Value negative for down-hill." according to SUBSET-026-7.5.1.110 the coding for Q_GDIR as used inside packet 21 for downhill is described with "0". In case a separate coding is used, please define in detail. Yes.

Chapter 3.4

What about: Override function related Speed Restriction
What about: Signalling related speed restriction (only level 1) Yes, additional definition is needed.

End of review at chapter 3.4

— Reply to this email directly or view it on GitHubhttps://github.com/openETCS/SRS-Analysis/issues/48#issuecomment-60262520.

Some remarks in the text:

On Oct 23, 2014, at 4:45 PM, christiangiraud notifications@github.com wrote:

De : Marc Behrens [mailto:notifications@github.com] Envoyé : jeudi 23 octobre 2014 16:19 À : openETCS/SRS-Analysis Objet : [SRS-Analysis] Review relating to #47 (#48)

Part 1: This issue relates to #47https://github.com/openETCS/SRS-Analysis/issues/47.

Chapter 1:

Since the document is not related to a openETCS deliverable or the relation is not stated inside the document, it is not clear where in the development process the document resides. Response : the document is a SRS Analysis preliminary to any formal specification and modelling.

Chapter 2:

Block Diagram Definition: looks like DMI is composed of EVC. for my understanding the OBU includes the interfaces whereas the EVC + interfaces assemple to the OBU. Response : DMI is seen as one module like BTM (balise), Odometer, TIU, Core, Radio (RBC).

Please detail on 'triple bus'. How is it defined. Response : Triple Bus is a manner to satisfy Requirement in terms of “Safety” and “Reliability”.

Capter 2.3:

Block "Actigram": Please detail the concept of "Virtual Machine (Excel)" Response : « Virtual Machine » is a pure software which starting from “Signalling Implementation Specification” is able to compute braking curve related to every possible signal at stop. It seems that Excel takes the role that NS is giving to Labview: Independent validation of algorithms

How is the "Hrdware + basic soft + simulator" defined? Response : this is all software or hardware out of OpenETCS scope.

How is ADA C++ generated. For my information SCADE produces C- code. Response : it is not evident that terminal box of scade will not need some software development (or algorithm).

SCADE can typically model and implement all necessary behaviour in an OBU. If small portions of the software are more efficiently implemented using hand written code (which is for example possible for bitwalker or CRC checks etc.), external code can be integrated into the model.

There is also a backend for SCADE KCG generation Ada Code (Ada95 or SPARK), but in openETCS SCADE KCG C- code generator has been selected.

In an open proof setting, C is the more open choice. Ada skills and tools are not generally adopted.

Chapter 2.3.4

Please define the rationale of using EXCEL. Currently EXCEL does not comply to project goal of OPEN PROOFS. Response : EXCEL can be used for proofs through « virtual machine » by computing curves for validation. Repeat: Alstom is using Excel the same way NS is using LabView. Independent Verification.

Chapter 2.3.5

Please detail on the rationale of using ADA or C++ or B

Where should which language be applied?

Is C considered? Response : is scade able to support all part of OpenETCS ?

As said, typically the full application can be represented using SCADE.

SysML/ SCADE toolchain is already defined for openETCS. The idea is that a functional specification in SCADE is understandable in itself while fully defining the behaviour.

Chapter 3.2.1

The linking qualifier (Q_LINK) in general indicating that the balise is known to trackside enables linking data to be used with this balise relating to "linking usable with this balise". The terms "Linking used" or "linking not used" would more probably be applied in case of a packet 5 is valid for this track section and decoded on-board. On this topic an ambiguity within the SRS, so a glossary is of vital importance here.

Unlinked BG: Please detail in which case the unlinked BG can be announced in the current LRBG - contradicts to "can not be announced ..."

"Linked / Unlinked is defined by one header qualifier." - Is Q_LINK meant here? - in this case the possibility to have Q_LINK = 1 and no linking packet 5 is a contradiciton to the statement.

"Linking is defined by packet 5 for all level" - linking is not valid in all ERTC level

"1 level." what is meant by this, please detail. Response : qualifier Q_LINK defines if BG can become LRBG : it is yes if BG is within linking list. If not within list, BG is ignored. If no list, the trend is to ignore too. ….

— Reply to this email directly or view it on GitHubhttps://github.com/openETCS/SRS-Analysis/issues/48.

CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium. — Reply to this email directly or view it on GitHub.

openETCS / SRS-Analysis

Review relating to #47 #48