Testing Railway Interlockings with TTCN-3

1. Stefan Blom Stefan.Blom@uibk.ac.at University of Innsbruck Natalia Ioustinova, Jaco van de Pol ustin@cwi.nl, Jaco.van.de.Pol@cwi.nl Centrum voor Wiskunde en Informatica, Amsterdam Testing Railway Interlockings with TTCN-3

2. Vital Processor Interlocking (VPI) • Control cycle: • input of new values • computations • idle waiting • output of results • VPI is timed, delays are used to ensure safety • Goal: find time semantics suitable for testing VPI`s software

3. Testing VPI`s software with real and scaled time Real Time: Active Time < Control Cycle =>We wait a lot of time for an idle SUT Scaled Time: • Activities (inputs, computations, outputs) can not be scaled • Finding a time factor such that activities of an SUT and a test system still fit into a scaled control cycle =>difficult, time consuming and error prone • Even if we have determined the factor, it is still not optimal!

4. Testing VPI`s software with simulated time Simulated time: • Time is modeled by a discrete logical clock • Actions are instantaneous => time progression has the least priority Why simulated time is adequate for testing VPI`s software: • VPI`s environment is continuous But VPI`s software takes one snapshot of environment per cycle => discrete system • Length of a control cycle is fixed • Max computation time < Min reaction time =>Time spent on the computations is negligible compared to durations of normal events

5. A TTCN-3 test system • All entities of a TTCN-3 test system should agree on simulated time • Time may progress only if the system is idle • We need a mechanism that • detects system`s idleness and • progresses time if idleness is detected

6. Idleness detection Global idleness: A TTCN-3 system is idle if all the entities of the system are idle Local idleness: An entity of the system is idle if it can not proceed by performing computations, or by receiving/sending messages or by producing/consuming timeouts =>The system is idle iff all entities are in idle state and there are no messages/timeouts pending. We extend Dijkstra’s distributed termination algorithm to detect idleness

7. Simulated time in TTCN-3 • Idleness Handler detects idleness of an entity (local idleness) • Time Manager • initiates idleness detection, • detects idleness of the system (global idleness), • triggers time progression if global idleness is detected

8. Time Manager • Initiates idleness detection by sending a token consisting of a global message counter and a global flag along the ring. • Initially, global message counter is 0 and the global flag has value IDLE_TAG. • If time manager receives the token back with the global message counter equal to 0 and the global flag equal to IDLE_TAG, it detects global idleness. • Otherwise, time manager repeats idleness detection. • If global idleness is detected, time manager progresses time by sending the token with flag TICK_TAG and restarts idleness detection in the next time slice

9. Idleness Hanlder

10. Idleness Hanlder

11. Transformation of TTCN-3 test components • Each test component gets a port for communication with its idleness handler. • Every TTCN-3 blocking operation is preceded by sending ``IDLE`` to an idleness handler (IH). • A receive statement is followed by sending ``RECV`` to an IH. • A send statement is followed by sending ``SEND`` to an IH. • A timeout statement is followed by sending ``ACTIVATE`` to IH. • Sending ``RECV``, ``IDLE``, ``SEND``, ``ACTIVATE`` are followed by receiving of an acknowledgement from an IH. • Receiving an acknowledgement for ``ACTIVATE`` is followed by • stopping the timer which timeout has caused ``ACTIVATE``.

12. Conclusion • We have provided a solution for simulated time in TTCN-3. • The solution can be used for other systems similar to VPIs. • The solution has been used to test VPI`s software for Betuwelijn station Future work • Optimization of the current solution • Extension for dynamic reconfiguration and distributed testing • Proposals for introducing simulated time into the TTCN-3 standard