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

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. 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 Testing VPI`s software with simulated time

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

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.  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 Conclusion