Verification of Module: InformationFilter_Pkg::InformationFilter/

[janWelte]

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. The Information Filter checks whether the incomming message or parts of the content are accepted or rejected due to level, mode and sending RBC. If level or mode transitions are pending it has to store information, which become valid after the transition.

Title	Content
Object	Operator: InformationFilter
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 modelScadeSystemObuFunctionsManageLocationRelatedInformationBaliseGroupInformationFilterInformationFilter.etp)
Link to Documentation	ADD document
Name of Function	InformationFilter_Pkg::InformationFilter/
WP3 Issues	Relates to User Story 4
Related to Specificatoin	SUBSET-026-4.8
Test Specification	tbd
Restult of Tests	tbd
Verification Report

Related to issue #237

assigned to @janWelte

new designer @christianstahl

[janWelte]

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

relating to modeling issue openETCS/modeling#637 and openETCS/modeling#646

relating to chapter:

• 4.1.3.5 Information Filter
  • 4.1.3.5.1 Component Requirements

---

Finding:

• Component name is incorrect in ADD

---

ADD:
The filter receives track information (balise and radio) and filters them depending of the mode, level and source of the message.

The Standard says:
The criteria for acceptance and rejection by the Information Filter in SUBSET-026-4.8.1.1 are

• state of the on-board
  • level,
  • mode
• nature of the received information
  • transmission medium
  • type of information: infill or non-infill

Finding:

• it has to be taken into account whether infill information are present

---

ADD:
Figure 7 shows the highlevel decomposition of the functionality. The filter is consists of four components: FirstFilter, SecondFilter, ThirdFilter and TransitionBuffer.

Finding:

• Figure 7 shows 2 parts TransitionBuffer, which have not connected outputs

---

ADD:
Based on this filter packets of an incoming message is either rejected, accepted or the whole message is put in the TransitionBuffer.

The Standard says:
Those tables (Subset-026 4.8.3.1.1 for Level and 4.8.4.2 for mode) list filter conditions in respect to full radio messages and to single packages and even parts of packages. Specifically for BG messages the header has to be transmitted in every case.

Therefore, the filter has to decide whether:

• full package has to be passed, stored or rejected
• package has to be passed, stored or rejected
• partial information have to be passed, stored or rejected
• stored information have to be passed or rejected due to changed modes or states
• meta information that certain data has been stored has to be transmitted

Finding:

• clear concept needed, how the filter addresses different level of information and how stored information are passed on later

---

Finding:

• SCADE model contains further debug components, which should be replaced or integrated by the main component functionality

---

Finding:

• it should be address whether buffer or track message are processed first if both are valid

---

4.1.3.5.2 Interface

---

Finding:

• inputs inTrainDataValid and inActiveCab are not used an unclear in their purpose
• all messages should be handled by the filter (separate output outputMessageForRadioAck is not needed)