PROL’s test interfaces

1. PROL’s test interfaces

2. Contents • Application environment • Example specification

3. Electronic contol desk

4. Application environment Behaviour Model of Railway Objects (UML statechart) conversion, extension extension simulator application model Objs application model code generation, interfaceimplementation test case generation test case generation generated simulator code existing Objs code test case by running the simulator

5. Example: railway object - points start to right set to right moving to right (WLR=1, WUW=0, Left position WLL=0) Right position (WUW=1, (WUW=1. WLR=0, WLR=1, WLL=1) moving to left WLL=0) (WLL=1, WUW=0, WLR=0) set to left start to left occupied free (WFM=1) (WFM=0) locked unlocked (WV=1) (WV=0)

6. Extension for simulator • Classes – state charts of object types (~30) • Factory – instance of classes • Input of simulator – script language • Input list for factory • Timed events (transaction) for each instance • Interpreting scripts • Output – IEC 60870-5-104 telegrams – changes of signals belong to states

7. Test vector for simulator • Factory: • Type (class), object_id • Input: • Time_stamp, station_code, object_id, transition_id • Output: • Series of IEC 60870-5-104 telegram • Time_stamp, object_id, signal_value, status • One telegram can consist more signals

8. Extension for object state decoder • The Objs is a state converter • Extending state charts of railway objects: • Second status word for each state • Existing specification – conversion tables:

9. Test vector for Objs • Input: • Series of IEC 60870-5-104 telegrams • Output: • Second status word:

10. Planned tests • Testing railway object simulator • with generated test from application model of simulator • comparing output of simulator to real-world interlocking within a given scenario • Testing railway object state decoder • with generated test cases from model • with simulator

11. Coverage • Comparing above described tests together and to manual tests: • coverage using requirement traceability • coverage using source level coverage tools • the number of incorrect test cases • This measurement can be repeated after increasing test cases with combined tests (e.g.. mixing test cases of different objects.)

12. Error handling • Unplanned transitions • Completting states with every transitions • Leading to error state • Leaving in the previous state • Inconsistent signals • Detection by Objs module • Leading to error state

13. Fault injection • Using fault injection to exercise error handling mechanisms in the Objs module • Inconsistent signals • focus on communication errors between the Objs application and the interlocking system • the result and the coverage of this test can be compared to software-implemented fault injection into communication of Objs ablication

14. Interfaces of modules • IEC 60870-5-104 protocol • Both module objs and simulator use IEC 60870-5-104 based communication. A C library will be used to create, to decode, to send and to receive IEC 870 based telegrams. This library can handle the following C structure: • typedef struct _PROC_DATA { • _PROC_HEADER header; • _SIG_TA_RC data[]; • } • typedef struct _PROC_HEADER { • unsigned char type_id; /* TYP_M_DP_TA */ • unsigned char num_blocks; /* 0-255 , 0:only header */ • unsigned char cause_transmit; /* */ • unsigned char group; /* station code */ • unsigned int data_len; /* data length in bytes */ • } PROC_HEADER;

15. Interfaces of modules • Output of Objs module • The output of objs module is a C structure: • typedef struct _OBJS_STATE { • int type; /* type of the railway object */ • int group; /* station code */ • int record; /* id of object */ • unsigned short state1 /* status word */ • int time; /* time stamp of status change */ • }

16. Interface descriptions • Elpult SW Construction: Conversion Tables • Elpult KSW System Level Interface Specification: Interface Tables • OBJS Module Functional Requirements: Object Tables

17. Thank you for yourattention!