the verification and validation activity for a railway
play

The Verification and Validation activity for a railway control - PowerPoint PPT Presentation

Ansaldo Segnalamento Ferroviario 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


  1. Ansaldo Segnalamento Ferroviario 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

  2. Ansaldo Segnalamento Ferroviario 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

  3. Ansaldo Segnalamento Ferroviario 1. Ansaldo signalling systems

  4. Ansaldo Segnalamento Ferroviario 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

  5. Ansaldo Segnalamento Ferroviario 1. Ansaldo signalling systems – Overview Architecture of Ansaldo ACC interlocking ART2 ART1 server server Peripheral Posts Field Signaller’s desk devices ACC Central Interlocking Unit

  6. Ansaldo Segnalamento Ferroviario 1. Ansaldo signalling systems – Overview Architecture of Ansaldo Radio Block Centre Interlocking ART2 ART1 server server Train Communication Computer Adjacent Operator’s desk RBCs RBC Central Interlocking Unit

  7. Ansaldo Segnalamento Ferroviario 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)

  8. Ansaldo Segnalamento Ferroviario 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

  9. Ansaldo Segnalamento Ferroviario 1. Ansaldo signalling systems – Overview CIU software architecture Hardware Safety Logic Kernel Software System Data

  10. Ansaldo Segnalamento Ferroviario 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)

  11. Ansaldo Segnalamento Ferroviario 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()

  12. Ansaldo Segnalamento Ferroviario 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

  13. Ansaldo Segnalamento Ferroviario 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

  14. Ansaldo Segnalamento Ferroviario 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 , …

  15. Ansaldo Segnalamento Ferroviario 2. V&V activities

  16. Ansaldo Segnalamento Ferroviario 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

  17. Ansaldo Segnalamento Ferroviario 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

  18. Ansaldo Segnalamento Ferroviario 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

  19. Ansaldo Segnalamento Ferroviario 2. V&V activities – Code inspection Tools for Coverage analysis Safety Logic Entities Commands Statistics code

  20. Ansaldo Segnalamento Ferroviario 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

  21. Ansaldo Segnalamento Ferroviario 2. V&V activities – Independent generation of System Data Independent generation of System Data Scheme Scheme Design model of Safety Logic SP CT Configuration System Data Ansaldo Proprietary Rules Query Processor (Development) = Configuration System Data Query Processor Off-the-shelf Rules (V&V) (Microsoft Access)

  22. Ansaldo Segnalamento Ferroviario 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)

  23. Ansaldo Segnalamento Ferroviario 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

  24. Ansaldo Segnalamento Ferroviario 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 black- box 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

  25. Ansaldo Segnalamento Ferroviario 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

  26. Ansaldo Segnalamento Ferroviario 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

Recommend


More recommend