Testing Railway Interlockings with TTCN3 Stefan Blom Stefan

Testing Railway Interlockings with TTCN-3 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

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!

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

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

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

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 §