search

openETCS / validation

WP4: Validation and verification strategy
8 stars 22 forks source link

Verification of Module: CheckBGConsistency_Pkg::CheckBGConsistency/ #301

Open MarcBehrens opened 8 years ago

MarcBehrens commented 8 years ago

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 commented 8 years ago

starting in sprint 36/ 37

MarcBehrens commented 8 years ago

Architecture verification review related to ADD document chapter

relating to modeling issue https://github.com/openETCS/modeling/issues/307

relating to chapter:

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

Finding:

The Standard says:

Finding:

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

Finding:

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:

Findings:

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

The standard says:

Findings:

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:

Finding:

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

@Farhangi could you please clarify the findings and questions.

MarcBehrens commented 8 years ago

relates to https://github.com/openETCS/product-backlog/issues/77

Farhangi commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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"