Requirement Refinement to Test Case Generation for Embedded Railway Control Systems

Requirement Refinement to Test Case Generation for Embedded Railway Control Systems by : Ying YANG 09/06/2011 Ph.D Student French institute of science and technology for transport, development and networks (IFSTTAR) Lille, France

Content • Introduction and background • Formal specification • Requirement refinement method • A case study • Formal verification • Method of conformance testing - a framework

FERROCOTS project Cabling technology using relay panels Railway command-control systems Cabling technology Use of electronic cards with simple logic gates, transistors, diodes and analog circuits to perform logic functions. • Disadvantages • Difficult to update the functions • Weight • Cost 1

FERROCOTS project Cabling technology using relay panels Railway command-control systems COTS-based technology FPGA • COTS-based technology • Use of Commercial-Off-The-Shelf (COTS) components • a COTS is a programmable piece of hardware called High Speed Field-Programmable Gate Array (FPGA). • Space-, Weight-, Cost-saving, • Flexible • Easily maintained • Reuse of components 2

Transformation from informal to formal requirement What we want: Formal specification • Describe what the system should do • By building a rigorous mathematical model How to get formal models: Transformation from informal to formal requirement Rn: R2: Requirement list R1: fonction requirement Formal models Transformation ? ? Traceability 3

Requirement refinement methodObjective and introduction Requirement document • Requirement refinement method: • A progressive transformation • Assure the requirement traceability Analyze Raw requirements Refinement Verification Refined requirements Properties • Formal verification : • model-checking • test/simulation Formalization 4

Process1: requirement refinement processThree refinement patterns • Refinement patterns: • «Clarify» • «Split» AND/OR/XOR • «Modify» «Add» «Remove» «Change» Activity diagram of requirement refinement process 5

Process 1: requirement refinement processIntro SysML • SysML • Modeling for system engineering • Inspirited by UML 2 • Requirement diagram 6

Process1: requirement refinement processNew stereotypes defined SysML profile diagram with new stereotypes and their attributes defined 7

Process 2: requirement formalization processFormal framework-CTL* • Formal framework: a temporal logic CTL* • Classical logic + operators with time • A superset of CTL (Computation Tree Logic) et LTL (Linear Time Logic) • Why? • For formal verification • Model checking / test • “Intuitive” logic Logic operators directly mapped to natural language words, like “Globally”, “Finally” 8

Path operators X (next), F (future), U (until), G (globally)… |= Gp State operators A (always) Aφ: the formula φ must hold on every path. R: the train doors can be opened only when the train speed ≤ 2km/h AG(dooropen → trainspeed ≤ 2km/h). Process 2: requirement formalization processFormal framework-CTL* 9

central console COTS (FPGA) Case studyTrain Door Control system Inputs General command series of subsystems Sensors Alarms Fire detection Door (un)locking … General command Local command when a passenger push the button to open one of the doors in the right side of train, the COTS receives a local command, then it verify whether authorization of right-hand doors is true… 10

Case studyTrain Door Control system • The requirement of generating the authorization of door opening is described as follows: • 1) some buttons can allow the driver to generate the authorization for door opening. a) A push button for cancelling the signal of closing the right-hand doors, which is located on the console. b) A push button for cancelling the signal of closing the left-hand doors, which is located on the console. c) A push button for cancelling the signal of closing the right-hand doors, which is located near the right side of the window in the driving cabin. d) A push button for cancelling the signal of closing the left-hand doors, which is located near the left side of the window in the driving cabin. • 2) When the train speed is ≤ 2km/h, if the doors are closed and locked, the doors can be authorized to be opened. 11

some buttons can allow the driver to generate the authorization for door opening. a) A push button for cancelling the signal of closing the right-hand doors, which is located on the console. b) A push button for cancelling the signal of closing the left-hand doors, which is located on the console. c) A push button for cancelling the signal of closing the right-hand doors, which is located near the right side of the window in the driving cabin. d) A push button for cancelling the signal of closing the left-hand doors, which is located near the left side of the window in the driving cabin. • 2) When the train speed is ≤ 2km/h, if the doors are closed and locked, the doors can be authorized to be opened. 12

Case studyTrain Door Control system R1.1.3 is formalized by P1.1.3 its variables: • PB(C-CD-R)_1: push button 1 for cancelling the signal of closing the right-hand doors • PB(C-CD-R)_2 : push button 2 for cancelling the signal of closing the right-hand doors • AU-OD-R : authorization for opening right-hand doors P1.1.3 : 13

Case studyTrain Door Control system P1.1.4similar to P1.1.3 14

Case studyTrain Door Control system R1.3.1 is formalized byP1.3.1 its variables : • TS: the train speed is ≤ 2km/h • door_R: the set of all the right-hand doors • close_Rand lock_R: the state of right-hand doors • AU-OD-R: authorization for opening right-hand doors P1.3.1 : P1.3.2 : 15

Case studyTrain Door Control system 16

Conformance testing - a framework Testing process Specification Phase Verification Phase Refined requirements Formalization Testing Properties Model-checking 17

Thank you! JING YANG IFSTTAR, ESTAS, F-59650 Villeneuve d’Ascq, France Email: jing.yang@ifsttar.fr

Requirement Refinement to Test Case Generation for Embedded Railway Control Systems