Autonomous Standards and Regulatory Issues & ChallengesLessons learned applying different ISO and IEC methods to AHS safety

Jonathan Moore

Chief Engineer ASI Robots

Edmonton October 19, 2017

Legislation, standards and guidelines

• Legislation – obvious “must do” requirements but often set a minimum baseline• US: Canada: China: • UK: Australia:

• Standards – help with product development, represent industry consensus• Generally not mandatory unless referred to in legislation• Following standard does not guarantee safe product not does it grant immunity from

marketplace actions• Trade body / industry sponsored to protect reputation and basis for underwriting

• Guidelines – good practice in engineer-accessible format

• Product liability and product safety legislation nevertheless require compliance with “state of the art” and best practice

Who makes the standards

International European National

ISO – International Organization for Standardization

CEN – European committee for standardization

Various bodies e.g. AFNOR*, ANSI, BSI, SABS, Standards Australia, TheInstituto Nacional de Normalización (INN) , CSA

IEC – International ElectrotechnicalCommission

CENELEC – European committee for electrotechnical standardization

IEC does all electrical except anything to do with vehicles which is always ISOCEN/CENELEC may adapt “as is” or with local adaptation

*Association Française de Normalisation

AutomotiveSAE (Society of automobile manufaturers)

MiningGMSGAMIRAEMESRT – Earth moving equipment safety round table

What is functional safety

• The part of the overall safety of a system that

depends on it operating correctly in response to its inputs.

• In many sectors the main emphasis is deploying electronic systems to reduce the risk associated with some hazard.

Harm injury, damage health of people, property , environment

Hazard potential source of harm

Hazardous situation circumstance of exposure to hazard

Hazardous event occurrence which results in harm

Risk probability (occurrence * severity)

IEC 61508

5.3.2 Methods for hazard identification

Harm

Hazardous eventPr

Hazardous situationFr

Presence of persons

Hazardous zone

Hazard

Some functional safety standards• Generic functional safety

• IEC 61508 (Safety Integrity Levels 1-4)

• Electric drives

• IEC 61800-5-2

• Process industry

• IEC 61511

• Nuclear

• IEC 61513

• Rail

• EN 50126 (IEC 62278 / 62279 / 62425)

• Defense

• UK: Def Stan 00-56

• Sets goals – 61508 assumed

• US: MIL-STD-882E generic for system safety

• Airborne systems DO-178C

• Testing and documentation, mapping to SIL 1-4

• Automotive• ISO 26262 A-SIL A, B, C, D

• ISO 26262 (2018)

• Off-road/heavy duty vehicles

• driver(less)

• intrinsic safety

• fail operational

• Agriculture• ISO 25119, 18497

• Not 61508 similar to 13849 & 26262

• Machinery• ISO 13849 Uses PL not SILs calls up 61508 for S/W

• ISO 15998 (earth moving) Calls up 61508, 26262

• ISO 25119 (agricultural vehicles)

• Mining• ISO WD 17757 calls up 61508, 13849, 62061, 19014

• ISO 21815 Collision awareness and avoidance

• Personal Robots (Security, Mowers, Cleaning)• ISO 13482 Calls up 13849, PLs

• Machinery directive (CE marking)• IEC 62061, IEC 61800

• 73/23/EEC LVD, 89/336/EEC EMC

• ISO 9001 – basic QMS in place

6

Functional SafetySystems and safety

Typically safety-related systems are defined:System added to another to add safety or protection

e.g. to shut something down

Where failure to perform the function may have consequences

e.g. intended function not performed or unintended function

This is all in scope of functional safety.

HT

ControlSystem

Protection System

Risk of misdirected energy

AHS

ISO 177574. Safety requirements and/or protective/risk reduction measures

4.1 General• ASAMS shall comply with the safety requirements and/or protective/risk

reduction measures of this clause.

• A risk assessment process for ASAMS shall be completed according to the principles of ISO 12100:2010. All identified risks shall be mitigated to acceptable risk levels as part of the risk assessment process. Annex B gives general information on risk assessment for ASAMS. The results of the risk assessment shall be formally documented.

• Safety-related parts of control systems shall comply with the appropriate functional safety performance level. See, for example, ISO 13849, ISO 19014, IEC 62061 or IEC 61508.

Identify Hazards and complete analysis

Recommend mitigation(s)

Assess effectiveness of mitigations

Specify the mitigations

Independent review / audit

Update H&RA with risk reduction achieved

Final auditEng. Sign off

Functional Safety Plan

Monitor over time and adjust risk rankings

HARA

FMEA

Implement the specification

Test reports

Change Control

FMEDA/FTA

Warranty/Service reports

HARA from ISO 17757

ISO 21815

• There are currently two existing standards in the field:• ISO/DIS 16001:2016 Earth-moving machinery – Object detection systems and

visibility aids – Performance requirements and tests

• ISO/CD 17757 Earth-moving machinery – Autonomous machinery system safety.

• These standards provide guidance for visual aids and for autonomous and semi-autonomous machines, however, there is currently no standard that describes hazard awareness and detection in relation to human response.

ISO 13482Collisions with safety related obstacles

• Robots shall be designed such that the risk of hazardous collisions with safety-related obstacles is as low as reasonably practicable

• 5.10.8.2 Inherently safe design• physical limitation of the travel speed

• 5.10.8.3 Safeguarding and complementary protective measures• calculating a minimum distance between the robot and a safety-related

obstacle• stop the robot if this distance is not maintained

• this can be achieved by position and speed controlling

• 5.10.8.5 Verification and validation• Appropriate method(s) shall be chosen from the following: C, D, E, F, G

Verification

ISO 17757

• Use one or more of the following:• Measurement

• Visual examination

• Testing and analysis or simulation as appropriate, or

• By assessment of the supplier’s documentation of• measurement

• visual examination

• testing

ISO 13842

• Per hazard requirements:• A (inspection)• B (practical tests)• C (measurement)• D (observation during operation)• E (examination of circuit diagrams)• F (examination of software)• G (review of task-based risk

assessment)• H (examination of layout drawings

and relevant documents)

ISO 13482 and EU Machinery Directive

EMESRT Earth moving equipment safety round table9 Layer Defensive Control Model

What’s the starting point

• Start with the existing risk management or risk profile

for the manual operation to be automated

• Determine which risks are now managed by the control system and protection system• Make recommendations on any necessary changes higher up the EMESRT control model• i.e. delete those that were controlled by the driver

• Add to the risk matrix new risk that are a result of adding the control system and protection system• Give you the confidence that additions don’t introduce unreasonable additional risk

• Lock step with the technology this gives us the ‘story’ behind the activities that give all the stakeholders (know and unknown) the confidence to proceed.• There are a tremendous number of people in the mine who are paid to have concerns about

safety and that inertia needs clear and patient explanation

• Functional safety gives us the framework and evidence to ‘prove’ to people that what we are doing is not unreasonable

HT

ControlSystem

Protection System

Risk of misdirected energy

AHS

Date Reference

System /

Subsystem or

Element / Item

Operating

conditions

Hazardous Event

or

Hazardous Situation

Harm

Bystander

Employee

Operator

S

Severity

Rationale

1-2

F

Frequency or

exposure

Rationale

1-2

P

Possibility of

avoiding

1-2

PLr SIL

Initial Assessment

ISO 13849-1-1:2006

Annex A Determination of required performance level (PLr)

Mitigation(s)

recommended

Mitigation(s)

recommended

Mitigation(s)

recommended

e.g. Pre-release

v0.9

e.g. Prototype

delivery

e.g. Production

delivery

Final

Safe StateFRT Safety Goal

Y/N [ms]

Risk mitigation achieved

S

Severity

Rationale

1-2

F

Frequency

or exposure

Rationale

1-2

P

Possibility

of avoiding

1-2

PLr SIL

Final Assessment

ISO 13849-1-1:2006

Annex A Determination of required performance level (PLr)

Se

Severity

Rationale

1-4

Fr

Frequency

or exposure

Rationale

2-5

Pr

Probability

rationale

1-5

Av

Avoidability

rationale

1,3,5

Cl SIL

Initial Assessment

ISO 62061:2005

A.2 Risk estimation and SIL assignment

S

Severity

Rationale

0-3

E

Exposure

Rationale

0-4

C

Controllabil

ity

Rationale

0-3

A-SIL

Final Assessment

ISO 26262-3:2011

7 Hazard analysis and risk assessment

ISO 13849-1:2006 S F P PLr SIL

S1 S1 - slight (normally reversible injury) P1 a None

S2 S2 - serious (normally irreversible injury or death) P2

F1 F1 - seldom-to-less-often and/or exposure time is short P1

F2 F2 - frequent-to-continuous and/or exposure time is long P2

P1 P1 - possible under specific conditions P1

P2 P2 - scarecely possible P2

P1

P2 e 3

ISO 14121-2:2007 S F O A Risk Index Priority

S1 slight injury (usually reversible), for example scratches,

laceration, bruising, light wound, receiving first aid.O1, O2 A1, A2 1

S2 serious injury (usually irreversible, including fatality), for

example, broken or torn-out or crushed limbs, fractures,

serious injuries requiring stiches, major musculoskeletal

troubles (MST), fatalities

O3 A1, A2

F1 twice or less per work shift or less than 15 min cumulated

exposure per work shiftO1 A1, A2

F2 more than twice per work shift or more than 15 min cumulated

exposure per work shiftA1

O1 mature technology, proven and recognized in safety

application; robustnessA2

O2 technical failure observed in the last two years A1

O3 technical failure regularly observed (every six months or less) A2 4

A1 possible under some conditionsA1 3

A2 impossible A2

A1

A2

A1

A2 6

IEC 62061:2005

Se4 Irreversible: death, losing an eye or arm

Se3 Irreversible: broken limb(s), losing a finger(s) 3-4 5-7 8-10 11-13 14-15

Se2 Reversible: requiring attention from a medical practitioner 4 SIL 2 SIL 2 SIL 2 SIL 3 SIL 3

Se1 Reversible: requiring first aid 3 (OM) (OM) SIL 1 SIL 2 SIL 3

Fr5 ≤ 1 day 2 (OM) (OM) (OM) SIL 1 SIL 2

Fr4 > 1 day to ≤ 2 weeks 1 (OM) (OM) (OM) (OM) SIL 1

Fr3 > 2 weeks to ≤ 1 year

Fr2 > 1 year OM Own measures or QM = existing quality measures

Pr5 Very high

Pr4 Likely

Pr3 Possible

Pr2 Rarely

Pr1 Negligible

Frequency and duration of

exposure (Fr)

Duration > 10 min

Probability of occurrence of a

hazardous event (Pr)

What you would normally do as a ISO 9001 company

No special treatment

Annex A SIL assignment

Severity (Se) Severity

(Se)

Class (Cl) = Fr+Pr+Av

F2

O1

4

O2

5

Severity of harm (S)

S1 F1, F2

3

Low2

Frequency and/or duration of

exposure to hazard (F)

S2

F1 O2Probability of occurrence of the

hazardous event (O) 3

2

Medium

O3

Possibility of avoidance or

reduction of harm (A)

1

HighO3

Annex A.4 Risk assessment using risk graph

Annex A Determination of required performance level (PLr)

Severity of injury (S)

S1

F1

S2

F1

F2

b

1Frequency and/or exposure times

to hazard (F)F2

cPossibility of avoiding the hazard

(P)d 2

Av5 Impossible

Av3 Rarely

Av1 Probably

ISO 25119-2:2010 C0 C1 C2 C3

S3 Life-threatening injuries (survival uncertain), severe disability QM QM QM QM

S2Severe and life-threatening injuries (survival probable),

permanent partial loss in work capacity

S1 {E2}

S2 {E1}

S3 {E0} QM QM QM a

S1

Light and moderate injuries, requires medical attention, total

recovery

S1

S2

S3

E3

E2

E1

QM QM a b

S0

No significant injuries, requires only first aid S1

S2

S3

E4

E3

E2

QM a b c

E4 Frequently (almost every operation) > 10 % S2 E4/E3 QM b c d

E3 Often (more than once per month) 1 % to 10 % S3 E4 QM c d e

E2 Sometimes (more than once per year) 0.1 % to 1 %

E1 Rare events (less than once per year) 0.01 % to 0.,1 % AgPl MTTF

E0Improbable (theoretically possible; once during lifetime) < 0.01

% a 1 B B B B Low

C3 None The average operator or bystander cannot generally

avoid the harm. b 2 1 B B B Medium

C2 Mostly controllable More than 90% of people control the

situation. In more than 90% of the occurrences, the situation

does not result in harm. c 2 1 1 1 High

C1 Simply controllable More than 99% of people control the

situation. In more than 99% of the occurrences, the situation

does not result in harm. d 2 2 2

C0 Easily controllable The operator or bystander controls the

situation, and harm is avoided. e 3

C3/C4

CCF >65%

Cat B

DC Low

Cat 1

DC med

Cat 2

DC med

Cat 3

DC med

Cat 4

DC high

ISO 26262-3:2011 S0 No injuries

S1 Light and moderate injuries C1 C2 C3

S2 Severe and life-threatening injuries (survival probable) E1 QM QM QM

S3 Life-threatening injuries (survival uncertain), fatal injuries E2 QM QM QM

E0 Incredible E3 QM QM A

E1 Very low probability E4 QM A B

E2 Low probability E1 QM QM QM

E3 Medium probability E2 QM QM A

E4 High probability E3 QM A B

C0 Controllable in general E4 A B C

C1 Simply controllable E1 QM QM A

C2 Normally controllable E2 QM A B

C3 Difficult to control or uncontrollable E3 A B C

E4 B C D

Combinations including S0/E0 or C0 are considered not safety functions (NSF)

Classes of probability of exposure

regarding operational situations

Classes of severity

Classes of controllability

Controllability classSeverity

class

Probability

class

S1

S2

S3

Exposure to the hazardous event

Possible avoidance of harm (C)

Probability of avoiding or limiting

harm (Av)

6 Risk analysis and method description

Severity of harm (S) S0, S1{E0,E1}, S2{E0}

Possible avoidance

Severity Exposure

SRL

• REDACTED – this was an unreadable view of a real HARA and attendance record

General thinking - Robot safety

• A robot at rest is safe• Stop and remain stopped when commanded

• Don’t start moving unless commanded

• Don’t collide with anything• Physics of momentum and stopping distance

• Forward, reverse

• Sideways (e.g. if you don’t occupy the volume swept during a turn)

Robot Driver

Driver

TiresSensors Processing Actuation Braking subsystemTerrain

ElectronicActuation

Electrical/Electronic/Programmable Electronic System (E/E/PES)

Terrain to TiresMistakes here are always blamed on the driver, maintenance staff, mine manager

If braking is necessary for avoiding harm then the complex electronics and software are subject to IEC 61508

Remote distracted control room operator

ISO 18497

• Ingress and egress are examined in detail in this Highly Automated Agricultural Machinery standard• How to safely exit and move away from a tractor that is armed in autonomous

mode and ready for work

• How to safely approach a tractor to resume manual operations• When the tractor is stopped normally

• If the tractor is in an error state e.g. still in autonomous mode

• Specifies the danger zones and the zones that need to be tested for presence of people before movement in addition to the front and rear

IEC 61508 applies61508 is where SIL is defined

• For example:• ISO 13849 defers to IEC 61508 for complex control systems – e.g. software

• ISO 62061 calls up IEC 61508 SIL levels directly from the risk graph

61508 vs 26262 vs 13489

* Something that can be automated, requires one person or is an event** Something that involves a team, experts, more sustained effort over time

Hardware

• SIL 2/3• 1 dangerous failure in 10 million hours

• Means the component parts of the system likely need to be better than this

Safe detected

Safe undetected

Dangerous detected

Dangerous undetected

Annunciated detected

Annunciated undetected

Other

1 Functional testing ++ ++ ++ ++

2 Fault injection testing H + + ++ ++

3 Electrical testing H ++ ++ ++ ++

1a Environmental testing with basic functional verification ++ ++ ++ ++

1b Expanded functional test H o + + ++

1c Statistical test H o o + ++

1d Worst case test H o o o +

1e Over limit test + + + +

1f Mechanical test ++ ++ ++ ++

1g Accelerated life test H + + ++ ++

1h Mechanical Endurance test H ++ ++ ++ ++

1i EMC and ESD test H ++ ++ ++ ++

1j Chemical test ++ ++ ++ ++

λDDλDU

λSD

λSU

SFF =

DC =

λSD + λSU + λDD

λSD + λSU + λDD + λDU

λSD + λDD

λSD + λSU + λDD + λDU

IEC 61508-1

IEC 61508-3:2010 Techniques and Measures Reference # Activities Easy/Hard 1 2 3 4

Table B.7 1a Semi-formal methods E R R HR HR

B.2.2, C.2.4 1b Formal methods H --- R R HR

C.2.11 2 Forward traceability between the system safety requirements and the software safety requirements E R R HR HR

C.2.11 3 Backward traceability between the safety requirements and the perceived safety needs H R R HR HR

B.2.4 4 Computer-aided specification tools to support appropriate techniques / measures above E R R HR HR

C.3.1 1 Fault detection E --- R HR HR

C.3.2 2 Error detecting codes E R R R HR

C.3.3 3a Failure assertion programming E R R R HR

C.3.4 3b Diverse monitor techniques (with independence between the monitor and the monitored function in the same computer) E --- R R ----

C.3.4 3c Diverse monitor techniques (with separation between the monitor computer and the monitored computer) E --- R R HR

C.3.5 3d Diverse redundancy, implementing the same software safety requirements specification E --- --- --- R

C.3.5 3e Functionally diverse redundancy, implementing different software safety requirements specification H --- --- R HR

C.3.6 3f Backward recovery H R R --- NR

C.2.12 3g Stateless software design (or limited state design) H --- --- R HR

C.3.7 4a Re-try fault recovery mechanisms E R R --- ---

C.3.8 4b Graceful degradation H R R HR HR

C.3.9 5 Artificial intelligence - fault correction H --- NR NR NR

C.3.10 6 Dynamic reconfiguration H --- NR NR NR

Table B.9 7 Modular approach E HR HR HR HR

C.2.10 8 Use of trusted/verified software elements (if available) E R HR HR HR

C.2.11 9 Forward traceability between the software safety requirements specification and software architecture E R R HR HR

C.2.11 10 Backward traceability between the software safety requirements specification and software architecture H R R HR HR

C.2.1 11a Structured diagrammatic methods ** E HR HR HR HR

Table B.7 11b Semi-formal methods ** H R R HR HR

B.2.2, C.2.4 11c Formal design and refinement methods ** H --- R R HR

C.4.6 11d Automatic software generation H R R R R

B.2.4 12 Computer-aided specification and design tools H R R HR HR

C.3.11 13a Cyclic behaviour, with guaranteed maximum cycle time E R HR HR HR

C.3.11 13b Time-triggered architecture E R HR HR HR

C.3.11 13c Event-driven, with guaranteed maximum response time E R HR HR -

C.2.6.3 14 Static resource allocation E - R HR HR

C.2.6.3 15 Static synchronisation of access to shared resources E - - R HR

C.4.5 1 Suitable programming language E HR HR HR HR

C.4.1 2 Strongly typed programming language E HR HR HR HR

C.4.2 3 Language subset E --- --- HR HR

C.4.3 4a Certified tools and certified translators E R HR HR HR

C.4.4 4b Tools and translators: increased confidence from use E HR HR HR HR

C.2.1 1a Structured methods ** E HR HR HR HR

Table B.7 1b Semi-formal methods ** E R HR HR HR

B.2.2, C.2.4 1c Formal design and refinement methods ** E --- R R HR

B.3.5 2 Computer-aided design tools H R R HR HR

C.2.5 3 Defensive programming H --- R HR HR

Table B.9 4 Modular approach E HR HR HR HR

C.2.6, Table B.1 5 Design and coding standards E R HR HR HR

C.2.7 6 Structured programming E HR HR HR HR

C.2.10 7 Use of trusted/verified software elements (if available) H R HR HR HR

C.2.11 8 Forward traceability between the software safety requirements specification and software design E R R HR HR

C.5.1 1 Probabilistic testing H --- R R R

B.6.5, Table B.2 2 Dynamic analysis and testing H R HR HR HR

C.5.2 3 Data recording and analysis E HR HR HR HR

B.5.1, B.5.2, Table B.3 4 Functional and black box testing E HR HR HR HR

Table B.6 5 Performance testing E R R HR HR

C.5.27 6 Model based testing H R R HR HR

C.5.3 7 Interface testing H R R HR HR

C.4.7 8 Test management and automation tools H R HR HR HR

C.2.11 9 Forward traceability between the software design specification and the module and integration test specifications E R R HR HR

C.5.12 10 Formal verification H --- --- R R

B.5.1, B.5.2, Table B.3 1 Functional and black box testing E HR HR HR HR

Table B.6 2 Performance testing H R R HR HR

C.2.11 3 Forward traceability between the system and software design requirements for hardware/software integration and the hardware/software integration test specificationsE R R HR HR

C.5.1 1 Probabilistic testing H --- R R HR

C.5.18 2 Process simulation H R R HR HR

Table B.5 3 Modelling H R R HR HR

B.5.1, B.5.2, Table B.3 4 Functional and black-box testing E HR HR HR HR

C.2.11 5 Forward traceability between the software safety requirements specification and the software safety validation plan E R R HR HR

C.2.11 6 Backward traceability between the software safety validation plan and the software safety requirements specification H R R HR HR

C.5.23 1 Impact analysis E HR HR HR HR

C.5.23 2 Reverify changed software module H HR HR HR HR

C.5.23 3 Reverify affected software modules H R HR HR HR

Table A.7 4a Revalidate complete system H --- R HR HR

C.5.25 4b Regression validation H R HR HR HR

C.5.24 5 Software configuration management H HR HR HR HR

C.5.2 6 Data recording and analysis E HR HR HR HR

C.2.11 7 Forward traceability between the Software safety requirements specification and the software modification plan (including reverification and revalidation)E R R HR HR

C.2.11 8 Backward traceability between the software modification plan (including reverification and revalidation)and the software safety requirements specificationH R R HR HR

C.5.12 1 Formal proof H --- R R HR

C.5.26 2 Animation of specification and design H R R R R

B.6.4, Table B.8 3 Static analysis E R HR HR HR

B.6.5, Table B.2 4 Dynamic analysis and testing E R HR HR HR

C.2.11 5 Forward traceability between the software design specification and the software verification (including data verification) plan E R R HR HR

C.2.11 6 Backward traceability between the software verification (including data verification) plan and the software design specification H R R HR HR

C.2.13 7 Offline numerical analysis H R R HR HR

B.2.5 1 Checklists E R R R R

C.6.1 2 Decision/truth tables E R R R R

Table B.4 3 Failure analysis E R R HR HR

C.6.3 4 Common cause failure analysis of diverse software (if diverse software is actually used) H --- R HR HR

C.6.4 5 Reliability block diagram H R R R R

C.2.11 6 Forward traceability between the requirements of Clause 8 and the plan for software functional safety assessment E R R HR HR

A.6 7.5

A.7

A.8 7.8

A.9 7.9

A.10

A.1 7.2

A.2 7.4.3

A.3 7.4.4

A.4 7.4.5, 7.4.6

A.5 7.4.7, 7.4.8

Programmable electronics integration (hardware

and software)

Software safety requirements specification

Software architecture design

Support tools and programming language

Detailed design

Software module testing and integration

Software aspects of system safety validation

Modification

Software verification

Functional safety assessment

C.2.6.2 1 Use of coding standard to reduce likelihood of errors E HR HR HR HR

C.2.6.3 2 No dynamic objects E R HR HR HR

C.2.6.3 3a No dynamic variables E --- R HR HR

C.2.6.4 3b Online checking of the installation of dynamic variables E --- R HR HR

C.2.6.5 4 Limited use of interrupts E R R HR HR

C.2.6.6 5 Limited use of pointers E --- R HR HR

C.2.6.7 6 Limited use of recursion E --- R HR HR

C.2.6.2 7 No unstructured control flow in programs in higher level languages E R HR HR HR

C.2.6.2 8 No automatic type conversion E R HR HR HR

C.5.4 1 Test case execution from boundary value analysis E R HR HR HR

C.5.5 2 Test case execution from error guessing H R R R R

C.5.6 3 Test case execution from error seeding H --- R R R

C.5.27 4 Test case execution from model-based test case generation H R R HR HR

C.5.20 5 Performance modelling H R R R HR

C.5.7 6 Equivalence classes and input partition testing H R R R HR

C.5.8 7a Structural test coverage (entry points) 100 % E HR HR HR HR

C.5.8 7b Structural test coverage (statements) 100 % E R HR HR HR

C.5.8 7c Structural test coverage (branches) 100 % E R R HR HR

C.5.8 7d Structural test coverage (conditions, MC/DC) 100 % H R R R HR

B.6.6.2 1 Test case execution from cause consequence diagrams H --- --- R R

C.5.27 2 Test case execution from model-based test case generation H R R HR HR

C.5.17 3 Prototyping/animation H --- --- R R

C.5.7, C.5.4 4 Equivalence classes and input partition testing, including boundary value analysis H R HR HR HR

C.5.18 5 Process simulation H R R R R

B.6.6.2 1a Cause consequence diagrams H R R R R

B.6.6.3 1b Event tree analysis H R R R R

B.6.6.5 2 Fault tree analysis H R R R R

B.6.6.4 3 Software functional failure analysis H R R R R

C.2.2 1 Data flow diagrams H R R R R

B.2.3.2 2a Finite state machines H --- R HR HR

B.2.2, C.2.4 2b Formal methods H --- R R HR

B.2.3.3 2c Time Petri nets H --- R HR HR

C.5.20 3 Performance modelling H R HR HR HR

C.5.17 4 Prototyping/animation H R R R R

C.2.3 5 Structure diagrams H R R R HR

C.5.21 1 Avalanche/stress testing H R R HR HR

C.5.22 2 Response timings and memory constraints H HR HR HR HR

C.5.19 3 Performance requirements H HR HR HR HR

IEC 61131-3 1 Logic/function block diagrams E R R HR HR

IEC 61131-3 2 Sequence diagrams E R R HR HR

C.2.2 3 Data flow diagrams H R R R R

B.2.3.2 4a Finite state machines/state transition diagrams H R R HR HR

B.2.3.3 4b Time Petri nets H R R HR HR

B.2.4.4 5 Entity-relationship-attribute data models H R R R R

C.2.14 6 Message sequence charts H R R R R

C.6.1 7 Decision/truth tables H R R HR HR

C.3.12 8 UML H R R R R

C.5.4 1 Boundary value analysis H R R HR HR

B.2.5 2 Checklists E R R R R

C.5.9 3 Control flow analysis H R HR HR HR

C.5.10 4 Data flow analysis H R HR HR HR

C.5.5 5 Error guessing H R R R R

C.5.14 6a Formal inspections, including specific criteria H R R HR HR

C.5.15 6b Walk-through (software) H R R R R

C.5.11 7 Symbolic execution H --- --- R R

C.5.16 8 Design review H HR HR HR HR

B.2.2, C.2.4 9 Static analysis of run time error behaviour H R R R HR

C.5.20 10 Worst-case execution time analysis H R R R R

C.2.9 1 Software module size limit E HR HR HR HR

C.5.13 2 Software complexity control E R R HR HR

C.2.8 3 Information hiding/encapsulation E R HR HR HR

C.2.9 4 Parameter number limit / fixed number of subprogram parameters E R R R R

C.2.9 5 One entry/one exit point in subroutines and functions E HR HR HR HR

C.2.9 6 Fully defined interface H HR HR HR HR

B.6 -> A.5, A.6

B.7 -> A.1, A.2, A.4

B.8 -> A.9

B.9 -> A.4

B.1 -> A.4

B.2 -> A.5, A.9

B.3 -> A.5, A.6, A.7

B.4 -> A.10

B.5 -> A.7

Modular approach

Functional and black-box testing

Failure analysis

Modelling

Performance testing

Semi-formal methods

Static analysis

Design and coding standards

Dynamic analysis and testing

CSA 336 Low speed battery operated robot

Type and purpose of safety-critical

function (SCF)

Minimum required performance level (PL) as described in ISO 13849-1

Prevent traversing over abrupt surface elevation changes such as unprotected drop-offs

PL = d

Prevent intrusions into the stopping or contact zones to prevent crushing of and collision with parts of the body and objects

PL = d

Prevent exceeding the top speed PL = dProvide locked state of drive wheels PL = bProvide desired switch-off of the machine, or emergency switch-off

PL = c

Provide desired stop category 0, 1, or 2 PL = d

Why is someone telling me what I should do?

The vast majority of equipment currently in mining is either

• Not safety related (operator assist)• Even if it has the word ‘safety’ or ‘safe’ in the brand name e.g. SAFEMINE• Even if people perceive it as adding some level of safety

• Not ‘complex’• Relays, switches, contactors, interlocks, simple electronics

• Easily defeated• Tape, disconnection, disabled, re-configured

That changes when you move the driver

The result of the hazard analysis / risk assessment will be a list of mitigations that eventually will identify the primary mitigation as something complex and programmable

• Best practice is to examine those systems and make sure• The right people are specifying, implementing and testing them• The right processes and tools are being used to do that• The right parts are being released into productionAND • to check all of that with the right level of independence – 3rd party audit

• And rely on either external mitigations that maybe ad-hoc now ie drivers mostly follow them

Legal instruments, liabilityIgnorant, incompetent, lazy

• Substantial evidence test• Does the record used contain evidence adequate to support the conclusion?• Consider relevant factors?• Demonstrate the reasonable connection between the facts on record and the resulting choice• Consider that reports with facts contrary to the basis for the conclusion are significant?

• Arbitrary capricious standard• Did the actor fail to consider an important aspect of the problem• Whether actor has offered an explanation that runs counter to the evidence• Whether the developers have the expertise needed

• Expert witness• Whether the opinion was based on sufficient facts or data• Whether the product of reliable methods and principals• Whether these principals and methods have been reliably applied

• All of these standards do not ask whether the conclusion was correct • whether the approach was reasonable• whether the public safety case was reasonable• whether the information provided and used• whether the analysis performed was at its core reasonable.

Why does someone else need to check?

• Independence has been part of functional safety culture since the beginning

• No good having the checkers influenced by the doers

• No good finding out in court that your argument is not robust

• Independence can be achieved internally (different departments)

• Using 3rd party certification demonstrates the highest transparency

Brake check example

• A good practice at a mine I visited included a brake check prior to entering the haul road

To Haul Road

The higher up the model that we can assign the mitigation the easier it is to demonstrate the mitigation is effective and has been implemented

Conclusions

• ISO 17757 is a good start but doesn’t offer much help• It opens a confusing complex world

• Other international standards identify many sources of harm that are• Reasonable• Applicable in mining

• Ignorance, incompetence and laziness are not effective liability limitation strategies

• A different driver in each vehicle is very effective at obstacle avoidance and the common causes of failure are very few

• The same autonomous driver in every vehicle is subject to common cause failure and obstacle avoidance technology is very immature

• Explaining why automated trucks are safe is everyone’s responsibility• Can you explain this to your family, friends, people who work for you, people you work for• Can they explain it too

• Seems sensible to box the systems we rely on for safety to their absolute minimum, smallest and least complex scope – be nice if the standards helped with that

• I’m a robotics engineer – I want adoption of robots• I don't think our children dream of a future doing something mindless over and over again day in and day out

Why is he wearing a hi-vis jacket?

Torbjörn Holmström, CTO at Volvo Grouphttps://www.youtube.com/watch?v=JwhyoUyJNoY&t=51s

Thank you and Questions

• UofA

• ALIGHT

• GMSG

• Heather and Tim

• You all for your time and attention

Jonathan Moore jmoore@exida.com

I’d be grateful of a ride to get to my hotel at the airport.

Functional safety an IEC 61508 Compliant Development Process Medoff/FallerThe Laws of Robots Ugo Pagallo