Testing Railway Interlockings with TTCN-3

1
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
  VPIs software

3
Testing VPIs software with real and scaled time

• Real Time
• Active Time lt Control Cycle
• gtWe 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
• gtdifficult, time
  consuming and error prone
• Even if we have determined the factor, it is
  still not optimal!

4
Testing VPIs software with simulated time

• Simulated time
• Time is modeled by a discrete logical clock
• Actions are instantaneous gt time progression has
  the least priority
• Why simulated time is adequate for testing VPIs
  software
• VPIs environment is continuous
• But VPIs software takes one snapshot of
  environment per cycle gt discrete system
• Length of a control cycle is fixed
• Max computation time lt Min reaction time
• gtTime 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 systems 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 gtThe system is idle
iff all entities are in idle state and there are
no messages/timeouts pending. We extend
Dijkstras 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 VPIs 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