Testing Railway Interlockings with TTCN-3 Stefan Blom University of Innsbruck Natalia Ioustinova,Jaco van de Pol Centrum voor Wiskunde en Informatica, Amsterdam

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

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!

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

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

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

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

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

Idleness Hanlder

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``.

 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