Verification of Module: CheckBGConsistency_Pkg::CheckBGConsistency/

[MarcBehrens]

Within the design working package (WP3) the Funcitonal Requirement Specificaiton is defined by User Stories. These User Stories are based on the application at the Amsterdam - Utrecht ETCS L2 track. To provide the track data for the ETCS OBU model a dynamic track model has been build, which in cooperation with a train movement model allows to simulate a run on the track. The issue documentes the verification for this dynamic track model.

Title	Content
Object	Operator: CheckBGConsistency
Definition	Verify correct and consitent implementation of the module
Link to DAS2V	ADD document with the [SCADE model](https://github.com/openETCS/modeling/raw/mastermodel modelScadeSystemObuFunctionsManageLocationRelatedInformationBaliseGroupCheckBGConsistencyCheckBGConsistency.etp)
Link to Documentation	ADD document
Name of Function	CheckBGConsistency_Pkg::CheckBGConsistency/
WP3 Issues	Relates to User Story 4
Related to Specificatoin	SUBSET-026-3.16
Test Specification	tbd
Restult of Tests	tbd
Verification Report

Please use inside a commit message when your contribution is related to this user story.

Related to issue #237

assigned to @AbdelnasirMohamed

[MarcBehrens]

starting in sprint 36/ 37

[MarcBehrens]

Architecture verification review related to ADD document chapter

relating to modeling issue openETCS/modeling#307

relating to chapter:

• 4.1.3.2 CheckBGConsistency
• 4.1.3.2.1 Component Requirements

of this document: openETCS Architecture and Design Specification

---

ADD:
This function verifies the completeness and correctness of the received messages from balise groups.

The Standard says:
The criteria for data consistency of track messages is defined in SUBSET-026-3.16.1.1

• whole message shall be complete in respect to the ETCS language
• variables shall not have invalid values
• message shall be received in due time
• the message shall be received at the right expected location

Finding:

• Of the claimed 4 aspects only parts of the first aspect have been covered in the detailed description below.
• Detailed aspects to which parts of the ETCS language completeness check is covered is needed here.

The Standard says:

• The criteria for correctness of the received track messages is defined in SUBSET-026-3.16.1.1 a)
  • whole message shall be complete in respect to the ETCS language
  • variables shall not have invalid values

Finding:

• Of the claimed 2 aspects only parts of the first aspect have been covered in the detailed description below.
  Detailed aspects to which parts of the ETCS language completeness check is covered is needed here.

---

ADD:
A message consists of at least a telegram and a maximum of 8 telegrams.
The standard says:

• A balise group message contains at least one balise telegram. SUBSET-026-3.4.1
• A balise group message can be assembled from up to eight different telegrams and its duplicates.

Finding:

• The term message is used in an ambiguous way. Clarification is needed.
• A balise group consists of up to eight balises, this does not always have to correlate to eight telegrams.
• A distinction between the physical balises and a telegram received needs to be represented inside the architecture.

---

ADD:
A message is still complete and correct, if a telegram is missing or not decoded or incomplete decoded ), and this telegram is duplicated within the balise group and the duplicating one is correctly read.

The standard says:

• This paragraph relates to SUBSET-026-3.16.2.4.4.1 and the variable M_DUP of SUBSET-026-7.5.1.63.
  This only is an exception of 3.16.2.4.4 a) 'balise missed inside the group' and b) 'balise is detected but no telegram is decoded'

Findings:

• This exception does not touch the two criteria for correctness:
  • message shall be received in due time
  • the message shall be received at the right expected location thus correctness shall not be used or shall be used in a reduced range when referring to duplicated balises.
• The term complete message is not defined. Is the completeness in respect to the ETCS language meant here?

---

ADD:
By more than one telegram, the order of the telegrams must be either ascending (nominal) or descending(reverse).

The standard says:

• Nothing about the ascending or descending order of the telegrams.

Findings:

• This is a design restriction which should be mentioned inside the chapter of the input and output variables (Balise input related to N_PIG) of the ADD document, part "Valid range of values" and "Behaviour for values out
  of valid range" and "Behaviour when value is erroneous, absent or unwanted (i.e. spurious)"
• Additional explanation: Valid for the datastructure inside the model: a previous filter should care for the correct line-up of the balises. Architecture question: Which functional part of the model cares to correctly line up balise messages read as N_PIG in the order of 0 1 2 3 4 3 4 3 4 5 6 7 to 0 1 2 3 4 5 6 7 ?

---

ADD: A message is correct, if all message counters (**M MCOUNT**) do not equal 254 (that means: The telegram never fits any message of the group). A message counter can be equal 255 (that means: The telegram fits with all telegrams of the same balise group) and all other values must be the same.

The standard says:

• Describes M_MCOUNT as part of the Balise message header 'Message counter (M_MCOUNT).[...]To enable detection of a change of balise group message during passage of the balise group.'
• Relates to SUBSET-026-5.7.1.71.

Finding:

• The special value for 'The telegram fits with all telegrams of the same balise group' is M_MCOUNT = 255. This only says something about the telegram carrying M_MCOUNT = 255. The check concerning the other telegrams should still be the same.
• The telegram carrying M_MCOUNT = 254 only says something about this telegram. The absence of MMCOUNT = 254 does not in all cases lead to a correct message.

---

ADD: The orientation of the BG will also be calculated in this block.

• Relates to the standard: N_PIG SUBSET-026-7.5.1.81; SUBSET-026-3.4.2.2; SUBSET-026-3.4.2.3.2

@Farhangi could you please clarify the findings and questions.

[MarcBehrens]

relates to openETCS/product-backlog#77

[Farhangi]

I have revised the section CheckedBGConsistency.
I hope that now some ambiguities and uncertainties are resolved.
The function "Receive_TrackSide_Msg" collects the telegrams in an
array. If one or more telegrams are received more than one time, either the
whole array or single telegram should be deleted.(depending on the situation)
The function "Receive_TrackSide_Msg" cares e.g. to correctly line up balise messages read as N_PIG in the order of 0 1 2 3 4 3 4 3 4 5 6 7 to 0 1 2 3 4 5 6 7 .
The balises in a group are to be expected in a certain
distance from each other. The function "Receive_TrackSide_Msg"
checks if the telegrams has been received in due time and at the right
expected location.
When linking information is used on-board,
the check, if the message of linked balise group has been received
in due time and at the right expected location, will be performed in
"Calculate Train Position".
"CheckBGConsistency" checks all variables of valid values in the headers of telegrams.
The packet variables are not checked here.

[AbdelnasirMohamed]

@Farhangi :
The revised description of the CheckBGConsistency have covered some of the findings stated above. However it has now no contradictions with SRS-Clauses (here referred as the "standard") nor it has vague wording, which it may lead to misunderstanding.

still the following findings should be adapted to the ADD-Document:

• A distinction between the physical balises and a telegram received needs to be represented inside the architecture.
• This is a design restriction which should be mentioned inside the chapter of the input and output variables (Balise input related to N_PIG) of the ADD document, part "Valid range of values" and "Behaviour for values out of valid range" and "Behaviour when value is erroneous, absent or unwanted (i.e. spurious)"

There are also some minor quality issues, which need to be corrected:

If one or more telegrams are received more then than one time, either
whole the the whole array or single telegram should be deleted.

The packte packet variables are not checked here.

[MarcBehrens]

Concerning the finding: "This is a design restriction which should be mentioned inside the chapter of the input and output variables (Balise input related to N_PIG) of the ADD document, part "Valid range of values" and "Behaviour for values out of valid range" and "Behaviour when value is erroneous, absent or unwanted (i.e. spurious)" it is expected to be handled inside the chapter "5.2.3.2.2 Interface"

• Please add to the identified chapter the restrictions on input consistency mentioned above with the input it applies to. @Farhangi