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
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
Ansaldo Segnalamento Ferroviario 1. Ansaldo signalling systems
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
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
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
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)
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
Ansaldo Segnalamento Ferroviario 1. Ansaldo signalling systems – Overview CIU software architecture Hardware Safety Logic Kernel Software System Data
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)
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()
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
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
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 , …
Ansaldo Segnalamento Ferroviario 2. V&V activities
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
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
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
Ansaldo Segnalamento Ferroviario 2. V&V activities – Code inspection Tools for Coverage analysis Safety Logic Entities Commands Statistics code
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
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)
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)
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
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
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
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