Verification of Module: Manage_TrackSideInformation_Integration

[janWelte]

Within the design working package (WP3) the Architecture and Design Specifications are defined based mainly based on the Subset-26 and additional Subsets. In addition the User Stories derived for the Amsterdam-Utrecht Track have been used as a guideline. The main function Manage_TrackSideInformation_Integration is responsible to collect and check the data received via BTM or Radio. Those information valid for the current train status are provided to the following kernel functions.

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

Related to issue #237

assigned to @janWelte

[janWelte]

Architecture verification review related to ADD document chapter and SCADE model structure

relating to chapter:

• 4.1 Manage_TrackSideInformation_Integration
  • 4.1.1 Component Requirements

---

Finding:

• Filter in description missing

---

ADD:
In these sections, also a detailed definition of the concepts implemented on those interfaces is documented.

Finding:

• it should be stated, that only one information stream (balise or radio) is handled per cycle.

---

- 4.1.1 Interface

---

ADD:
An overview of the interface of component Manage_TrackSideInformation_Integration is shown in Figure 6.

Finding:

• Figure 6 does not show different input and output streams. It would be helpful to at least represent the information coming from different sources as separate inputs. As information are some subcomponents use information not used by those components before these inputs should directly be connected as input to the subcomponent.
• this SCADE model structure provides a very different impression of the basic data flows as the very clean figure 6. It would be helpful to restructure the SCADE model (specifically those local variables) to at least provide the same principal structure.

---

4.1.2.1 Inputs

---

Finding:

• 4.1.2.1.2 should be API_trackSide_Message

---

ADD:
4.1.2.1.7 tNvContact Description: For monitoring the safe radio connection, this national value is needed as an input. Source: Database

Finding:

• how is managing a safe radio connection related to this function. Please give a clear indication, why this input is needed.
• source database is in current architecture unclear

---

ADD:
`4.1.2.1.8 lastRelevantEventTimestamp

Source: Database `

Finding:

• source database is in current architecture unclear

---

ADD:
`4.1.2.1.10 inSupervisingRbcId

Source: Database
Type: int
Valid range of values [Complete list of valid values]`

Finding:

• type should be a combination of NID_C and NID_RBC
• source database is in current architecture unclear
• if this is an int the range should be defined

---

ADD:
`4.1.2.1.12 q_nvlocacc

Source: Database`

Finding:

• source database is in current architecture unclear

---

Finding:

• further inputs existing in the SCADE model are missing (e.g. inActiveCab, inTrainDataValid, inFilterEvents, transitionPositionPassed)

---

4.1.2.2 Outputs

---

For most outputs

ADD:
Description [Brief description of the output]
And

Destination [Name of the destination component(s)]

Finding:

• it is unclear which information are provided by this output
• it is unclear which components uses this information, therefore no requirements can be verified