E2E hardware-in-the-loop test of an EULYNX TDS

EULYNX test case format/test cases

The structure of the EULYNX test cases is designed in a way that the test cases can be used to perform E2E hardware-in-the-loop tests on the individual subsystems.

The PARAMETER table lists all the parameters that must be defined before the test case is executed. A parameter can be a variable from the subsystem itself, a timer or a value in a message. These are largely defined by the specific system available.

The PRECONDITIONS define the initial state of the subsystem, which must be reproducible by the test laboratory.

The decisive steps for the actual test procedure are the STEPS listed in the table, which describe the exact sequence of the test cases. Each line of the table corresponds to a single action in the test procedure. Unfortunately, these are difficult to translate into instructions that can be executed by our test application.

The SDI sheet contains all messages that may occur during the test.

The POST CONDITIONS show the state of the subsystem after the test case has been executed and are easy to compare. Afterwards, either the state for the next PRECONDITIONS or a neutral initial state should be established.

The large number of test cases made it necessary to limit them to the applicable system/functional package (TDS AC - axle counter) and to filter out test cases that could be easily implemented within the scope of this POC.

Test/simulation circuit – starting point: laboratory environment

The Digital Rail Summer School project in 2024 had already provided a circuit board with a functioning test setup. Source code was also available that allowed an Arduino to stimulate the coils at the correct frequency. This allowed the axle counter to be set to a correct initial state with unoccupied axle counter heads.

In addition, the Platform 21 provided a tool that was able to establish the necessary RaSTA connection and exchange EULYNX telegrams. Alternatively, it would have been possible to build on the results of EULYNX-Live and derive a minimal interlocking system from it (https://github.com/eulynx-live). A future version of the test runner could also communicate with the platform via gRPC to request the status.

Another important component for verifying the successful execution of the test cases is the OPC UA interface to the axle counter, which makes it possible to read and compare system states that are not transmitted as telegrams.

Preparation of the test cases

While pre- and postconditions can be directly adopted as a basis to compare the state, a more comprehensive, partially manual processing is necessary for the steps to make them usable, as can be seen in the following illustration.

"STEPS": [
    {
        "action": "axle_in",
        "confirm": "opcua_axle",
        "expectedValue": 1
    },
    {
        "action":null,
        "confirm": "grpc",
        "expectedValue": {
            "TDS.STATE": "OPERATIONAL",
            "TDS.TVPS_OCCUPANCY_STATUS" : "OCCUPIED",
            "TDS.ABILITY_TO_BE_FORCED_TO_CLEAR" : "UNABLE"
        },
        "wait": 0
    },
    {
        "action":null,
        "confirm": "opcua_timer",
        "expectedValue": 1500
    },
    {
        "action": "axle_in",
        "confirm": "opcua_axle",
        "expectedValue": 2
    },
    {
        "action":null,
        "confirm": "opcua_timer",
        "expectedValue": 1500
    },
    {
        "action": "axle_out",
        "confirm": "opcua_axle",
        "expectedValue": 1
    },
    {
        "action":null,
        "confirm": "opcua_timer",
        "expectedValue": 1500
    },
    {
        "action": "axle_out",
        "confirm": "opcua_axle",
        "expectedValue": 0
    },
    {
        "action":null,
        "confirm": "opcua_timer",
        "expectedValue": 1500
    }
]

Software and platform

A script implemented in Python coordinates all the important steps as a test runner to automatically run the test cases one after the other. The precondition for this is the establishment of a functional connection between the interlocking, which is simulated by Platform 21, and the axle counter. The test case JSON specifies the test runner for the axle sequence, which is transmitted to the Arduino via the serial interface. The Arduino interrupts the stimulation of the two coils one after the other for the duration of a passing axle to simulate its passing and direction of movement. The reactions of the axle counter are received by Platform 21 in the form of EULYNX telegrams and then queried by the test runner. If the test step expects a telegram to be sent, this is compared with the test definition. At the same time, the expected state is compared via OPC UA in the AC. This means that each test step can be checked for correctness independently of communication with the simulated interlocking. The complete correctness of a test case therefore results from the conjunction of the individual steps and the Boolean values can be seen as the basis for a readable test report.