How Can Usage Monitoring Improve Resilience? - Semantic Scholar

Complex Systems Design & Management November 12-14 2014

How Can Usage Monitoring Improve Resilience?

Jean-René Ruault Frédéric Vanderhaegen Christophe Kolski [email protected]

Summary Running outside the specified domain About systems engineering About resilience Proposition : Design pattern fit to resilient systems Railway case study Conclusion and perspectives

Complex Systems Design & Management - November 12-14 2014

2

Context, train crashes Lac-Mégantic (Canada), 6 July 2013 50 dead

Brétigny sur Orge (France), 12 July 2013 7 dead 9 gravely injured

Santiago de Compostela (Spain), 24 July 2013 80 dead 130 injured

Granges-près-Marnand (Switzerland), 29 July 1 dead 25 injured Complex Systems Design & Management - November 12-14 2014

3

Road map Running outside the specified domain About systems engineering About resilience Proposition : Design pattern fit to resilient systems Railway case study Conclusion and perspectives


4

Running outside the specified domain Dynamic representation of barriers bypassing Time 2

D

C

3 E

Accident

B

A

1


Legend: • Specified path: • Actual path: • Specified local variability: • Actual local variability: • Situation point: X • Safety margin: • Barriers : 1 • Barrier bypassing • Deviation 5

Road map Running outside the specified domain About systems engineering About resilience Proposition : dissonance Management for resilient systems design Railway case study Conclusion and perspectives


6

Systems engineering main issues Definition System: set of complex hardware, software, personnel and operational processes, organized so as to satisfy the needs and fulfil the expected services, in a given environment (prEN 9277: 2012) Systems engineering: interdisciplinary approach governing the total technical and managerial effort required to transform a set of stakeholder needs, expectations, and constraints into a solution and to support that solution throughout its life (ISO/IEC/IEEE 15288, forthcoming) *ities

Holism

Life cycle

Stakeholders

Systems engineering

Interdisciplinary


Evidence

Operational, functional, physical architecture 7

Systems thinking (1/2) Why?

What?

What for?

How long?

In which context?

How much?

How? How efficient?


ROI? …

8

Systems thinking (2/2) A teller Missions Functions

Lifecycle

Environment Components Performances (duration of a transaction)

Acquisition cost Ownership cost ROI ? …


9

Example: the railroad network Trains (high speed, tilting…). Geography, geology, civil engineering, urban impacts, environmental impacts… Connection with other transportation means: end-to-end transportation. Exploitation: exploitation of the network, infrastructure (electrical network, communication network…) Commercialization: billing policy, sales channels). Network, equipment and infrastructure maintenance.


10

Longer cycles USS Enterprise: Keel laid in 1958 Ship launched in Sep. 1960 Commissioned on Nov. 1961 Inactivated Dec. 2012 Decommissioned currently underway (2016?).

Super Frelon: Designed in the 50’s First flight Dec. 1962 In-service Oct. 1965 Retired Apr. 2010 But still in service in China.

B52 Contract bid June 1946 Maiden flight Apr. 1952 Active service since 1955 Upgrades between 2013 and 2015 Expected to serve into the 2040’s.

French Metro car MS61 Ordered in 1963 Delivered Feb. 1967 First commercial trip Jun. 1967 Upgrade in the 80’s and 2000-2010 still in service. Complex Systems Design & Management - November 12-14 2014

11

Systems modelling Systems Modelling Language (SysML) Adaptation from UML to systems Functional modelling Key issue for model-based systems engineering (MBSE)


12



13

Resilience definitions “safety and risks in complex organizations are emergent, not resultant properties: safety and risk cannot be predicted or modeled on the basis of constituent components and their interaction” (1) “we can only measure the potential of resilience, but not resilience itself” (2) resilience as a “management at the border of the domain of application…” (3)

1.

2.

3.

S. Dekker: Resilience engineering: chronicling the emergence of confused consensus ; in E. Hollnagel, D. Woods & N. Levenson (eds), Resilience Engineering. Concepts and precepts, Ashgate, Hampshire, Great Britain, 2006 E. Hollnagel & D. Woods: Epilogue – Resilience engineering precepts; in E. Hollnagel, D. Woods et N. Levenson (eds), Resilience Engineering. Concepts and precepts, Ashgate, Hampshire, Great Britain, 2006 D. Luzeaux: Engineering Large-scale Complex Systems in D. Luzeaux, J.-R. Ruault & J.-L. Wippler, Complex Systems and Systems of Systems Engineering, ISTE Ltd and John Wiley & Sons Inc, 2011

14 Systems Design & Management - November 12-14 2014 Complex

14

About resilience (1/2) Resilience characteristics Reserve (buffering capacity)

Flexibility

Margin

Tolerance

Multilevel interactions

Among factors of context Crew’s training and experiment

Work conditions

Human-system interfaces (HSI) quality

Availability of the resources

Methods and procedures accessibility and availability

Team collaboration quality

Mechanisms dealing with resilience Migration phenomenon (omerta)

Barriers removal (costs; benefits)

Compensation/decompensation mechanism

Dynamic process of “visual piloting”

Threats and appropriate responses Complex Systems Design & Management - November 12-14 2014

15

About resilience (2/2) Positive / negative effects of the observance / nonobservance specified procedures (Hollnagel’s dark matter1) Consequence

Procedure

1.

Positive (no accident)

Negative (accident)

Observance

Sociotechnical system functioning in its specified domain

Actual environment different from the reference situation. Procedure observance generates a failure.

Nonobservance

Sociotechnical system adaptation to the actual environment Compensation mechanism Enhance vigilance because decompensation risks

Unsuited adaptation mechanism Failure of a compensation mechanism Signal indicating the probability of an accident

E. Hollnagel: Resilience – The challenge of the Unstable; in E. Hollnagel, D. Woods et N. Levenson (eds), Resilience Engineering. Concepts and precepts, Ashgate, Hampshire, Great Britain, 2006


16

Issues & aims Resilience: capability of sociotechnical systems To cope with unpredictable, unforeseeable events To adjust faced with disturbing events, To adapt and learn adequate rules of adaptation, Disturbances out of the system’s adaptation mechanisms Impacts of resilience upon sociotechnical systems: Systems engineering processes Systems engineering models Systems architecture issue of this article Systems utilization processes

17 Systems Design & Management - November 12-14 2014 Complex

17

Four main resilience functions (1) 1. 2. 3. 4.

Avoidance (capacity for anticipation) Resistance (capacity for absorption) Adaptation (capacity for reconfiguration) Recovery (capacity for restoration)

This paper deals with: 1. Avoidance

1.

D. Luzeaux: Engineering Large-scale Complex Systems in D. Luzeaux, J.-R. Ruault & J.-L. Wippler, Complex Systems and Systems of Systems Engineering, ISTE Ltd and John Wiley & Sons Inc, 2011


18

Avoidance function decomposition Acquiring information at the operators’ level anticipate and avoid accidents Obtain a representation of the environment Obtain a representation of the system’s dynamics Identify the environment states that were not envisioned Evaluate the instantaneous or trend drifts Evaluate the proximity of the state of the system compared to the zones of danger


19



20

Functional decomposition of the avoidance function (block definition diagram) bdd [Package] Resilience_Functions [Resilience_Functions]

Name: Package: Version: Author:

«Resilience_Functions» Resilience

Resilience_Functions Resilience_Functions 1.0 Ruault

«Resilience_Functions» Av oidance

«Resilience_Functions» Adaption

«Resilience_Functions» Resistance

«Resilience_Functions» Recov ery

«Resilience_Functions» Alert_Opeartors «Resilience_Functions» Obtain_Representation_Env ironment

«Resilience_Functions» Identify_Env ironment_States

«Resilience_Functions» Ev aluate_Proximity_Hazard «Resilience_Functions» Obtain_Representation_System_Dynamic


«Resilience_Functions» Ev aluate_Drifts

21

Allocation of resilience functions on the usage monitoring system components


22

Physical architecture of the usage monitoring system bdd [Package] Usage_Monitoring_System [Usage_Monitoring_System]

Name: Package: Version: Author:

«Usage_Monitoring_Component» Reference_States_Repositoty

«Usage_Monitoring_System» Usage_Monitoring_System

Usage_Monitoring_System Usage_Monitoring_System 1.0 Ruault

+ +

Gather_Usage() Express_Warning() :Warning

«Reference_State» + Numbrer_Authorization :Reference_State 1 + Specified_Variability :Reference_State + Barrier_Characteristics :Reference_State

1..* + «Usage_Monitoring_Component» User_Interface_Proxy + + +

1 «Usage_Monitoring_Component» Current_States_Repository

Show_Warning_Level(Warning_Level) Show_Safety_Margins(Safety_Margins) Show_Drift(Drift)

«Current_State» + Numbrer_Authorization :Current_State* + Current_Variability :Current_State + Barrier_Status :Current_State

1..* «Usage_Monitoring_Component» Usage_Sensor_Proxy

1..*

«Usage» + Gather_Usage() :Usage 1 «Usage_Monitoring_Component» States_Comparison_Engine + + +

Set(Reference_State)

Assess_Drift(Current_States_Repository, Reference_States_Repositoty) :Drift Assess_Warning_Level(Reference_States_Repositoty, Current_States_Repository) :Warning_Level Assess_Safety_Margins(Current_States_Repository, Reference_States_Repositoty) :Safety_Margins


«Usage_Monitoring_Component» Usage_Sensor «Current_State» + Barrier_Status :Current_State + Number_Authorization :Current_State + Current_Variability :Current_State «Usage» + Gather_Usage() :Usage

23

Interfaces and flows between operating system and usage monitoring system ibd [Package] System_Structure [System_Structure] Name: Package: Version: Author:

System_Structure System_Structure 1.0 Ruault

:Operating_System

«Usage» Usage_Information «Current_State» + Barrier_Status :Current_State + Number_Authorization :Current_State + Current_Variability :Current_State

«Operating» ::Operating_System + Exhibit_Usage() :Usage

«Usage» Gather_Usage

«Usage» Exhibit_usage

:Usage_Monitoring_System ::Usage_Monitoring_System + Gather_Usage() + Express_Warning() :Warning

«Usage» «Warning» Express_Warning

«Warning»

«Warning» Express_Warning

«Warning» Warning «Warning» + Warning_Level :Warning + Safety_Margins :Warning + Drift :Warning


24



25

Aldershot accident case study (1/2) Context of the accident: Main-track derailment of a train at Aldershot , Ontario, Canada 3 deaths, 45 wounded

4300 litres of diesel fuel released Summary On 26 February 2012, the train VIA 92 was proceeding eastward from Niagara Falls to Toronto, Ontario, on track 2 of the Canadian National Oakville Subdivision near Burlington, Ontario The track switches were lined to route the train from track 2 to track 3, through crossover No. 5, which had an authorized speed of 15 mph The train VIA 92 entered crossover No. 5 while travelling at about 67 mph. Subsequently, the locomotive and all 5 coaches derailed. The locomotive rolled onto its side and struck the foundation of a building adjacent to the track Complex Systems Design & Management - November 12-14 2014

26

Aldershot accident case study (2/2) Track schematic and site diagram

2 4 1

5 3

6


7

8

27

Simulation of the accident 1

3

2

4


28

Main causes of this accident and synthesis The crew would normally go straight ahead at track speed but the train was diverted to the switch due to the unexpected presence of work crew on the tracks The control opted to route the train from track 2 to track 3 crossover N°5, which was authorized for a speed of 15 mph The control did not communicate this route change to the VIA 92 crew The crew expected to go straight ahead 99% of the time and expectation drive perception and decision processes

Synthesis There was only one way to inform the crew, the signals along the track There was no signal after the Aldershot station in order to remind the crew the speed It’s typically a misperception of the crew due bias and heuristic’s effect Safety and resilience are not guaranteed 29 Complex Systems Design & Management - November 12-14 2014

Relevance of an usage monitoring system An usage monitoring system would have been useful for detecting the major violations of safety Detecting the speed excess by comparing it to the accepted threshold and presenting the evidence of a speed exceeding to the operators. Managing the rail crossing between rail 2 to rail 3 by alerting the operators or presenting a visual device with the maneuver to be accomplished. Time 2

D

C

3

E

Accident

B

A

1

Legend: Specified path: Actual path: Specified local variability: Actual local variability: Situation point: Safety margin: Barriers: Barrier bypassing: Gap: Hazard

X

1

Reporting the railway signals to the operators in real-time in order to keep them informed and secures the situation awareness of the operating crew. Alerting on the specificity of this day, very different from the current 99% “go straight ahead”


30

A whole system containing an operating system part and an usage monitoring system one bdd [Package] System_Structure [System_Structure] Name: Package: Version: Author:


«Operating_System,block» Operating_System

«System» Whole_System + +

«Component» + Security_Device +

«Usage_Monitoring_Syste... Usage_Monitoring_System Gather_Usage() Express_Warning() :Warning

Exhibit_Usage() :Usage

:Rail_Traffic_Management

:Trains

:Railroad_Station

«Operating»

«Operating»

«Operating»

::Rail_Traffic_Management + Manage_T raffic() + Exhibit_Usage() :Usage

::Trains + Transport() + Exhibit_Usage() :Usage

::Railroad_Station + Exhibit_Usage() :Usage

«Usage_Monitoring»


::Rail_Traffic_Management + Gather_Usage() + Express_Warning() :Warning

::Trains + Gather_Usage() + Express_Warning() :Warning

::Railroad_Station + Gather_Usage() + Express_Warning() :Warning



31

Communication of specified states from the rail traffic management and the train ibd [Package] System_Structure [System_Structure] Name: Package: Version: Author:


:Trains

:Rail_Traffic_Management «Reference_State»

«Current_State»

::Rail_Traffic_Management + Specified_Speed + Crossover_Maximum_Speed = 15 mph

::Trains - Current_Speed «information» Specified_State

«Operating» ::Rail_Traffic_Management + Manage_Traffic() + Exhibit_Usage() :Usage

«flow»

::Trains + Transport() Specified_State + Exhibit_Usage() :Usage

Specified_State


«Usage_Monitoring» ::Rail_Traffic_Management + Gather_Usage() + Express_Warning() :Warning

«Operating»

«information» Specified_State

::Trains + Gather_Usage() + Express_Warning() :Warning

«Specified_State» + Specified_Speed + Crossover_Maximum_Speed


32

Road map Running outside the specified domain About systems engineering About resilience Proposition: Design pattern fit to resilient systems Railway case study Conclusion and perspectives


33

Conclusion and perspective Conclusion Proposal : to interconnect the operating system, realizing the operational missions, and the usage monitoring system. To monitor system’s states and usage To estimate the gap between the current state of the system and the safe one, the proximity of hazard, and to inform the operators The goal is that the operators share a clear, reliable, relevant and updated representation of the operational context as well as the usage of the system, so that they can take the appropriate measures

Perspective Widening this architecture to observe the operational context and express it to the operators


34

References Systems engineering: Friedenthal S, Moore A, & Steiner R (2011) A Practical Guide to SysML, Morgan Kaufmann; 2nd edition.

Resilience: D Luzeaux (2011) Engineering Large-scale Complex Systems in D Luzeaux, J-R Ruault & J-L Wippler, Complex Systems and Systems of Systems Engineering, ISTE Ltd and John Wiley & Sons Inc, 2011. Ruault J-R, Vanderhaegen F, Luzeaux D (2012) Sociotechnical systems resilience. 22nd Annual INCOSE International Symposium, 9-12 July, 2012, Rome. Ruault J-R, Vanderhaegen F, Kolski C (2013) Sociotechnical systems resilience: a dissonance engineering point of view. 12th IFAC/IFIP/IFORS/IEA Symposium on Analysis, Design, and Evaluation of Human-Machine Systems (august, 11-15), IFAC, Las Vegas, USA. Zieba S., Polet P., Vanderhaegen F., Debernard S. (2010). Principles of adjustable autonomy: a framework for resilient human machine cooperation. Cognition, Technology and work, 12 (3), pp. 193-203. Ouedraogo K-A., Enjalbert S., Vanderhaegen F. (2013). How to learn from the resilience of Human–Machine Systems?. Engineering Applications of Artificial Intelligence, volume 26, issue 1, pp. 24-34. 35 Complex Systems Design & Management - November 12-14 2014

References Dominique Luzeaux & Jean-René Ruault (Ed.) Systems of Systems, ISTE-Wiley, London, 2011

Dominique Luzeaux, Jean-René Ruault & Jean-Luc Wippler (Ed.) Complex Systems and Systems of Systems Engineering, ISTE-Wiley, London, 2011

Patrick Millot (Ed.), Risk Management in Life critical Systems, ISTE-Wiley, London, 2014


36

THANK YOU VERY MUCH FOR YOUR ATTENTION 37 Systems Design & Management - November 12-14 2014 Complex

37