The Verification and Validation activity for a railway control system Davide Alagna, Alessandro Romei [alagna.davide@asf.ansaldo.it, romei.alessandro@asf.ansaldo.it] RAMS Department Geneva, 19 th September 2008
Summary 1. Ansaldo signalling systems Overview Safety Logic System Data 2. V&V activities Overview Code inspection Independent generation of System Data Typologies of tests 3. Conclusions Software Problem Report
1. Ansaldo signalling systems
1. Ansaldo signalling systems Overview Purpose of a signalling system Safe railway traffic requires a signalling system to assign and control the route support the driver s behaviour avoid collisions
1. Ansaldo signalling systems Overview Architecture of Ansaldo ACC interlocking ART1 server ART2 server Field devices Peripheral Posts ACC Central Interlocking Unit Signaller s desk
1. Ansaldo signalling systems Overview Architecture of Ansaldo Radio Block Centre Interlocking ART1 server ART2 server Train Communication Computer Adjacent RBCs RBC Central Interlocking Unit Operator s desk
1. Ansaldo signalling systems Overview Products and applications Generic Product: Hardware and Kernel Software (e.g. ACC, RBC) Generic Application: Signalling Safety Logic (e.g. Italy, UK, ERTMS) Specific Applications: Systems (e.g. NVC Milano-Bologna, ACC Roma Termini, RBC Torino-Novara)
1. Ansaldo signalling systems Overview CIU design guidelines Same product for different applications Strict separation between invariant and variant parts of the product Invariant: Hardware, Kernel Software Variant: Safety Logic, System Data Variant parts managed through databases, handled by a common software engine
1. Ansaldo signalling systems Overview CIU software architecture Safety Logic Hardware Kernel Software System Data
1. Ansaldo signalling systems Overview Safety Logic design Object-Oriented modelling of Safety Logic starting from safety requirements (principle schemes): Entities (classes) Attributes (classes specification) Linked Entities (relationships among classes) Entities state (classes members) Commands (classes methods)
1. Ansaldo signalling systems Overview Design example Requirement: a point machine shall not move if it is engaged by a train. Entities (classes): Point, Track_circuit Attributes (classes specification): - Linked entities (relationships among classes): Dead_track_circuit Entities state (classes members): Point.position, Track_circuit.state Commands (classes methods): Point.move()
1. Ansaldo signalling systems Overview Safety Logic implementation Safety Logic developed in a high-level proprietary language Conditional statements Assignments Exceptions No pointers No dynamic memory allocation Restricted use of error-prone statements Safety Logic compiled in a symbolic language ready to be interpreted by the Logic Handler Process Reflects the strict separation between invariant and variant parts of the product All objects and their relationships are statically instantiated, therefore they can be analyzed offline
1. Ansaldo signalling systems Overview From Safety Logic to System Data Requirements, design and implementation of Safety Logic are abstract (generic application) Systems are configured (specific applications) Databases to be instantiated for: entities attributes linked entities
1. Ansaldo signalling systems Overview Configuration example Entities: PT.01, PT.03, TC.110, TC.111, Attributes: PT.01 is Oleodynamic, PT.07 is Electromechanic Linked entities: PT.01 TC.161,
2. V&V activities
2. V&V activities Overview V&V activities Generic Product: Hardware testing Kernel Software testing Generic and Specific Application: Code inspection of Safety Logic code Coverage analysis Independent generation of System Data Automatic and manual testing in simulated environment Field testing on target system
2. V&V activities Code inspection Code inspection Automatic analysis provides: Context diagrams Used vs not used variables Used vs not used attributes and linked entities Manual analysis focuses on: UML modelling of safety logic code Check lists for good programming style Functional analysis, search for critical complex scenarios Tools under development for: Automatic UML modelling of safety logic code through its translation in C++ or Java, thus allowing off-the-shelf environments to be positively used
2. V&V activities Code inspection Coverage analysis Performed after the completion of automatic and manual test sets Focuses on either Code or Data Automatic analysis provides: Coverage statistics Reports and databases Manual analysis focuses on: Non covered branches, attributes and linked entities Feedback to test specifications
2. V&V activities Code inspection Tools for Coverage analysis Entities Commands Safety Logic code Statistics
2. V&V activities Independent generation of System Data Independent generation of System Data Aims at verifying the correctness and completeness of System Data Independent generation of: entities attributes linked entities according to the design model of Safety Logic Comparison with System Data produced by the Development Team Evaluation of differences
2. V&V activities Independent generation of System Data Independent generation of System Data Design model of Safety Logic Scheme Scheme CT SP Configuration Rules (Development) Ansaldo Proprietary Query Processor System Data = Configuration Rules (V&V) Query Processor Off-the-shelf (Microsoft Access) System Data
2. V&V activities Typologies of tests Typologies of tests Functional tests: all functional requirements are correctly implemented by Safety Logic code Scope: generic application Configuration tests: all System Data required by the Safety Logic are correctly configured, and no spurious data are present Scope: specific application Stress tests: critical functions of the system are stressed introducing a set of random inputs Scope: both generic and specific application (in particular RBC)
2. V&V activities Typologies of tests Functional tests A Test Case is specified for each Safety Logic requirement, according to a black-box approach Abstract Test Scripts are implemented Level of abstraction classes of equivalence Test Scripts are executed in a fully or partially simulated environment Both positive and negative results are analysed, leading to Code Coverage Analysis
2. V&V activities Typologies of tests Configuration tests A Test Case can be defined: for each attribute and for each linked entity, according to a white-box approach based on the Safety Logic design model for each relationship among data, according to a blackbox approach based on System Data requirements Abstract Test Scripts are implemented Level of abstraction entity Test Scripts are executed in a fully or partially simulated environment Both positive and negative results are analysed, leading to Data Coverage Analysis
2. V&V activities Typologies of tests Stress tests Identification of a set of critical functions with references both to safety and complexity issues System stressed with a set of random inputs System behaviour analysed searching for: compliance with pre-defined properties of state variables unforeseen evolutions of state variables based on Chronological Events Recording (RCE) Suitable for reactive systems such as RBC
2. V&V activities Typologies of tests Testing approach and development The white-box approach requires a detailed knowledge of the Safety Logic Applied to Italian ACC interlocking The black-box approach is independent from the system implementation Applied to projects developed incrementally, such as UK ACC interlocking and RBC Tools under development for: Specifying black-box test cases with UML class and sequence diagrams Automatic generations of test scripts from UML model
2. V&V activities Typologies of tests Simulated Testing Environment (ACC) ART1 ART2 Station Simulator Peripheral Posts Posts Simulator CIU Simulator CIU Signaller Tester
2. V&V activities Typologies of tests Simulated Testing Environment (RBC) Interlocking IXL Simulator ART1 ART2 Train Train Simulator Communication Protocol stack computer Adjacent RBCs RBC Simulator CIU CIU Simulator Operator Tester
2. V&V activities Typologies of tests Field testing on target system Functional tests which cannot be completed in a simulated environment, e.g. Integration with adjacent systems Interfacing with target field devices Diagnostic issues and fault tolerance Tests on the correct set-up of field devices (track circuits, point machines, signal heads) and peripheral posts Tests with real trains
3. Conclusions
3. Conclusions Software Problem Report Management of non-compliances Production of Software Problem Reports (SPR) Causes Safety issues Impacts Problem Resolution by the Development Team New V&V cycle Evaluation of the impact of changes Regression tests SPR closure (if possible) New SPR production (if any)
Thank you for your kind attention