Autonomous Standards and Regulatory Issues & Challenges

Transcription

1 Autonomous Standards and Regulatory Issues & Challenges Lessons learned applying different ISO and IEC methods to AHS safety Jonathan Moore Chief Engineer ASI Robots Edmonton October 19, 2017

2 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

3 Who makes the standards International European National ISO International Organization for Standardization IEC International Electrotechnical Commission CEN European committee for standardization CENELEC European committee for electrotechnical standardization IEC does all electrical except anything to do with vehicles which is always ISO CEN/CENELEC may adapt as is or with local adaptation Various bodies e.g. AFNOR*, ANSI, BSI, SABS, Standards Australia, The Instituto Nacional de Normalización (INN), CSA Automotive SAE (Society of automobile manufaturers) Mining GMSG AMIRA EMESRT Earth moving equipment safety round table *Association Française de Normalisation

4 What is functional safety The part of the overall safety of a system that depends on it operating correctly in response to its inputs Methods for hazard identification Hazardous event Pr In many sectors the main emphasis is deploying electronic systems to reduce the risk associated with some hazard. Harm Hazardous situation Fr Presence of persons Hazardous zone Hazard Harm Hazard Hazardous situation Hazardous event Risk injury, damage health of people, property, environment potential source of harm circumstance of exposure to hazard occurrence which results in harm probability (occurrence * severity) IEC 61508

5 Some functional safety standards Generic functional safety IEC (Safety Integrity Levels 1-4) Electric drives IEC Process industry Nuclear Rail Defense IEC IEC EN (IEC / / 62425) UK: Def Stan Sets goals assumed US: MIL-STD-882E generic for system safety Airborne systems DO-178C Testing and documentation, mapping to SIL 1-4 Automotive ISO A-SIL A, B, C, D ISO (2018) Off-road/heavy duty vehicles driver(less) intrinsic safety fail operational Agriculture ISO 25119, Not similar to & Machinery Mining ISO Uses PL not SILs calls up for S/W ISO (earth moving) Calls up 61508, ISO (agricultural vehicles) ISO WD calls up 61508, 13849, 62061, ISO Collision awareness and avoidance Personal Robots (Security, Mowers, Cleaning) ISO Calls up 13849, PLs Machinery directive (CE marking) IEC 62061, IEC /23/EEC LVD, 89/336/EEC EMC ISO 9001 basic QMS in place

6 Functional Safety Systems and safety HT AHS Risk of misdirected energy Typically safety-related systems are defined: System added to another to add safety or protection e.g. to shut something down Control System Protection System 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. 6

7 ISO 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 or IEC

8 Functional Safety Plan Identify Hazards and complete analysis HARA Recommend mitigation(s) Independent review / audit Change Control Assess effectiveness of mitigations FMEA Update H&RA with risk reduction achieved Specify the mitigations Implement the specification FMEDA/FTA Final audit Eng. Sign off Test reports Monitor over time and adjust risk rankings Warranty/Service reports

9 HARA from ISO 17757

10 ISO 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 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.

11 ISO Collisions 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 Inherently safe design physical limitation of the travel speed 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 Verification and validation Appropriate method(s) shall be chosen from the following: C, D, E, F, G

12 Verification ISO 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 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)

13 ISO and EU Machinery Directive

14 EMESRT Earth moving equipment safety round table 9 Layer Defensive Control Model

15 What s the starting point HT AHS Risk of misdirected energy Start with the existing risk management or risk profile for the manual operation to be automated Control System Protection System 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

16 Combinations including S0/E0 or C0 are considered not safety functions (NSF) ISO :2006 Annex A Determination of required performance level (PLr) S F P PLr SIL Severity of injury (S) S1 S1 - slight (normally reversible injury) P1 a None F1 S2 S2 - serious (normally irreversible injury or death) P2 S1 b Frequency and/or exposure times F1 F1 - seldom-to-less-often and/or exposure time is short P1 F2 1 to hazard (F) F2 F2 - frequent-to-continuous and/or exposure time is long P2 c Possibility of avoiding the hazard P1 P1 - possible under specific conditions P1 F1 (P) P2 P2 - scarecely possible P2 S2 d 2 P1 F2 P2 e 3 ISO :2007 Annex A.4 Risk assessment using risk graph S F O A Risk Index Priority Severity of harm (S) 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 S1 F1, F2 example, broken or torn-out or crushed limbs, fractures, O3 A1, A2 serious injuries requiring stiches, major musculoskeletal 3 troubles (MST), fatalities Low 2 Frequency and/or duration of F1 twice or less per work shift or less than 15 min cumulated O1 A1, A2 exposure to hazard (F) exposure per work shift IEC 62061:2005 Date F2 more than twice per work shift or more than 15 min cumulated A1 exposure per work shift System / Hazardous Event F1 O2 Probability of occurrence of the O1 mature technology, proven Operating and recognized in safety A2 Reference hazardous event (O) Subsystem application; or robustness or Harm 3 O2 technical failure observed conditions in the last two years A1 Element / Item Hazardous Situation O3 O3 technical failure regularly observed (every six months or less) S2 A2 4 Possibility of avoidance or A1 possible under some conditions reduction of harm (A) O1 A1 3 A2 impossible F2 O2 Annex A SIL assignment Severity (Se) Frequency and duration of exposure (Fr) Duration > 10 min Probability of occurrence of a hazardous event (Pr) Bystander Employee Operator Risk mitigation achieved S Se S A2Severity Severity4 A1 Rationale A2 Rationale 5 A Severity Rationale Initial Assessment ISO ISO : :2005 Annex A A.2 Determination Risk estimation of required and SIL performance assignment level (PLr) F 2 Medium Probability Frequency of avoiding or limiting Av5 Impossible Frequency Possibility Probability of harm (Av) or exposure Fr exposure PrAv3 avoiding Rarely rationale F P 1 Rationale Rationale Av1 Probably 1-5 High 6 Risk analysis 1-2 and 2-5method description 1-2 Final Assessment Final Assessment ISO : :2011 Annex A 7 Determination Hazard analysis of required and risk performance assessment level (PLr) Frequency Exposure E or exposure Rationale P Rationale Avoidability Av rationale Cl PLr SIL 1,3,5 Controllabil Possibility of avoiding ity C Rationale PLr SIL Mitigation(s) recommended e.g. Pre-release v0.9 Mitigation(s) recommended e.g. Prototype delivery Mitigation(s) recommended e.g. Production delivery Possible avoidance O3 ISO :2010A2 6 Severity Exposure C0 C1 C2 C3 Severity of harm (S) S3 Life-threatening injuries (survival uncertain), severe disability S0, S1{E0,E1}, S2{E0} QM QM QM QM Severe and life-threatening injuries (survival probable), S1 {E2} S3 {E0} QM QM QM a S2 Se4 Irreversible: death, losing an eye or arm Severity Class (Cl) = Fr+Pr+Av permanent partial loss in work capacity S2 {E1} Se3 Irreversible: broken limb(s), losing a finger(s) (Se) Light and moderate injuries, requires medical attention, total S1 E3 QM QM a b Se2 Reversible: requiring attention from a medical practitioner 4 SIL 2 SIL 2 SIL 2 SIL 3 SIL 3 S1 recovery S2 E2 Se1 Reversible: requiring first aid 3 (OM) (OM) SIL 1 SIL 2 SIL 3 S3 E1 Fr5 1 day 2 Final (OM) (OM) (OM) SIL 1 SIL 2 No significant injuries, requires only first aid S1 E4 QM a b c Fr4 > 1 day to 2 weeks 1 (OM) (OM) (OM) FRT (OM) SIL 1Safety Goal S0 S2 E3 Fr3 > 2 weeks to 1 year Safe State S3 E2 Fr2 > 1 year OM Own measures or QM = existing quality measures Exposure to the hazardous event E4 Frequently (almost every operation) > 10 % S2 E4/E3 QM b c d Pr5 Very high What you would normally do as a ISO 9001 company E3 Often (more than once per month) 1 % to 10 % S3 E4 QM c d e No special treatment E2 Sometimes (more than once per year) 0.1 % to 1 % Pr4 Likely E1 Rare events (less than once per year) 0.01 % to 0.,1 % AgPl SRL MTTF Pr3 Possible Improbable (theoretically possible; once during lifetime) < 0.01 E0 Pr2 Rarely Y/N [ms] % Possible avoidance of harm (C) Pr1 Negligible a 1 B B B B Low ISO :2011 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 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 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 Classes of severity S0 No injuries Severity Probability Controllability class S1 Light and moderate injuries class class C1 C2 C3 S2 Severe and life-threatening injuries (survival probable) A-SIL S1 E1 QM QM QM S3 Life-threatening injuries (survival uncertain), fatal injuries E2 QM QM QM Classes of probability of exposure E0 Incredible E3 QM QM A regarding operational situations E1 Very low probability E4 QM A B E2 Low probability S2 E1 QM QM QM E3 Medium probability E2 QM QM A E4 High probability E3 QM A B Classes of controllability C0 Controllable in general E4 A B C C1 Simply controllable S3 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

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

18 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)

19 Terrain to Tires Mistakes here are always blamed on the driver, maintenance staff, mine manager Terrain Driver Sensors Processing Actuation Braking subsystem Tires Electrical/Electronic/Programmable Electronic System (E/E/PES) Robot Driver Electronic Actuation Remote distracted control room operator If braking is necessary for avoiding harm then the complex electronics and software are subject to IEC 61508

20 ISO 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

21 IEC applies is where SIL is defined For example: ISO defers to IEC for complex control systems e.g. software ISO calls up IEC SIL levels directly from the risk graph

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

23 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 1 Functional testing Fault injection testing H Safe detected 3 Electrical testing H Other λ 1a Environmental testing with basic functional verification SD 1b Expanded functional test H o c Statistical test H o o d Worst case test H o o o + 1e Over limit test Safe undetected 1f Mechanical test Annunciated λ undetected SU 1g Accelerated life test H h Mechanical Endurance test H i EMC and ESD test Annunciated H Dangerous ++ Dangerous 1j Chemical test detected detected undetected λ λ DU DD SFF = λ SD + λ SU + λ DD λ SD + λ SU + λ DD + λ DU DC = λ SD + λ DD λ SD + λ SU + λ DD + λ DU IEC

24 IEC :2010 Techniques and Measures Reference # Activities Easy/Hard A A A A , A , A A.7 A A A.10 Software safety requirements specification Software architecture design Support tools and programming language Detailed design Software module testing and integration Programmable electronics integration (hardware and software) Software aspects of system safety validation Modification Software verification Functional safety assessment B.1 -> A.4 Design and coding standards 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 Forward traceability between the system safety requirements and the software safety requirements E R R HR HR C Backward traceability between the safety requirements and the perceived safety needs H R R HR HR B Computer-aided specification tools to support appropriate techniques / measures above E R R HR HR C Fault detection E --- R HR HR C Error detecting codes B.2 -> A.5, A.9 Dynamic analysis and testing 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 g 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 Artificial intelligence - fault correction H --- NR NR NR C Dynamic reconfiguration H --- NR NR NR Table B.9 7 Modular approach E HR HR HR HR C Use of trusted/verified software elements (if available) E R HR HR HR C Forward traceability between the software safety requirements specification and software architecture E R R HR HR C Backward traceability between the software safety requirements B.3 specification -> A.5, and A.6, software A.7architecture Functional and black-box testing H R R HR HR C a Structured diagrammatic methods ** E HR HR HR HR Table B.7 11b Semi-formal methods ** H R R HR HR B.2.2, C c Formal design and refinement methods ** H --- R R HR C d Automatic software generation H R R R R B Computer-aided specification and design tools H R R HR HR C a Cyclic behaviour, with guaranteed maximum cycle time E R HR HR HR C b Time-triggered architecture E R HR HR HR B.4 -> A.10 Failure analysis C c Event-driven, with guaranteed maximum response time E R HR HR - C Static resource allocation E - R HR HR C Static synchronisation of access to shared resources E - - R HR C Suitable programming language E HR HR HR HR C Strongly typed programming language E HR HR HR HR C Language subset B.5 -> A.7 Modelling 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 Computer-aided design tools H R R HR HR C 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 Structured programming E HR HR HR HR C Use of trusted/verified software elements (if available) B.6 -> A.5, A.6 Performance testing H R HR HR HR C Forward traceability between the software safety requirements specification and software design E R R HR HR C Probabilistic testing H --- R R R B.6.5, Table B.2 2 Dynamic analysis and testing H R HR HR HR C Data recording and analysis B.7 -> A.1, A.2, A.4 Semi-formal methods 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 Model based testing H R R HR HR C Interface testing H R R HR HR C Test management and automation tools H R HR HR HR C Forward traceability between the software design specification and the module and integration test specifications E R R HR HR C 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 Forward traceability between the system and software design requirements for hardware/software integration and the hardware/software E R R HR HR C Probabilistic testing H --- R R HR C 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 B.8 -> A.9 Static analysis E HR HR HR HR C Forward traceability between the software safety requirements specification and the software safety validation plan E R R HR HR C Backward traceability between the software safety validation plan and the software safety requirements specification H R R HR HR C Impact analysis E HR HR HR HR C Reverify changed software module H HR HR HR HR C Reverify affected software modules H R HR HR HR Table A.7 4a Revalidate complete system H --- R HR HR C b Regression validation H R HR HR HR C Software configuration management H HR HR HR HR C Data recording and analysis E HR HR HR HR C Forward traceability between the Software safety requirements specification and the software modification plan (including reverification ane R R HR HR C Backward traceability between the software modification plan (including reverification and revalidation)and the software safety requiremenh R R HR HR C Formal proof H --- R R HR C 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 Forward traceability between the software design specification and the software verification (including data verification) plan B.9 -> A.4 Modular approach E R R HR HR C Backward traceability between the software verification (including data verification) plan and the software design specification H R R HR HR C Offline numerical analysis H R R HR HR B Checklists E R R R R C Decision/truth tables E R R R R Table B.4 3 Failure analysis E R R HR HR C Common cause failure analysis of diverse software (if diverse software is actually used) H --- R HR HR C Reliability block diagram H R R R R C Forward traceability between the requirements of Clause 8 and the plan for software functional safety assessment E R R HR HR C Use of coding standard to reduce likelihood of errors E HR HR HR HR C No dynamic objects E R HR HR HR C a No dynamic variables E --- R HR HR C b Online checking of the installation of dynamic variables E --- R HR HR C Limited use of interrupts E R R HR HR C Limited use of pointers E --- R HR HR C Limited use of recursion E --- R HR HR C No unstructured control flow in programs in higher level languages E R HR HR HR C No automatic type conversion E R HR HR HR C Test case execution from boundary value analysis E R HR HR HR C Test case execution from error guessing H R R R R C Test case execution from error seeding H --- R R R C Test case execution from model-based test case generation H R R HR HR C Performance modelling H R R R HR C 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 Test case execution from cause consequence diagrams H R R C Test case execution from model-based test case generation H R R HR HR C Prototyping/animation H R R C.5.7, C Equivalence classes and input partition testing, including boundary value analysis H R HR HR HR C Process simulation H R R R R B a Cause consequence diagrams H R R R R B b Event tree analysis H R R R R B Fault tree analysis H R R R R B Software functional failure analysis H R R R R C Data flow diagrams H R R R R B a Finite state machines H --- R HR HR B.2.2, C.2.4 2b Formal methods H --- R R HR B c Time Petri nets H --- R HR HR C Performance modelling H R HR HR HR C Prototyping/animation H R R R R C Structure diagrams H R R R HR C Avalanche/stress testing H R R HR HR C Response timings and memory constraints H HR HR HR HR C Performance requirements H HR HR HR HR IEC Logic/function block diagrams E R R HR HR IEC Sequence diagrams E R R HR HR C Data flow diagrams H R R R R B a Finite state machines/state transition diagrams H R R HR HR B b Time Petri nets H R R HR HR B Entity-relationship-attribute data models H R R R R C Message sequence charts H R R R R C Decision/truth tables H R R HR HR C UML H R R R R C Boundary value analysis H R R HR HR B Checklists E R R R R C Control flow analysis H R HR HR HR C Data flow analysis H R HR HR HR C Error guessing H R R R R C a Formal inspections, including specific criteria H R R HR HR C b Walk-through (software) H R R R R C Symbolic execution H R R C Design review H HR HR HR HR B.2.2, C Static analysis of run time error behaviour H R R R HR C Worst-case execution time analysis H R R R R C Software module size limit E HR HR HR HR C Software complexity control E R R HR HR C Information hiding/encapsulation E R HR HR HR C Parameter number limit / fixed number of subprogram parameters E R R R R C One entry/one exit point in subroutines and functions E HR HR HR HR C Fully defined interface H HR HR HR HR

25 CSA 336 Low speed battery operated robot Type and purpose of safety-critical function (SCF) Prevent traversing over abrupt surface elevation changes such as unprotected dropoffs Prevent intrusions into the stopping or contact zones to prevent crushing of and collision with parts of the body and objects Prevent exceeding the top speed Provide locked state of drive wheels Provide desired switch-off of the machine, or emergency switch-off Provide desired stop category 0, 1, or 2 Minimum required performance level (PL) as described in ISO PL = d PL = d PL = d PL = b PL = c PL = d

26 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 production AND to check all of that with the right level of independence 3 rd party audit And rely on either external mitigations that maybe ad-hoc now ie drivers mostly follow them

27 Legal instruments, liability Ignorant, 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.

28 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 3 rd party certification demonstrates the highest transparency

29 Brake check example A good practice at a mine I visited included a brake check prior to entering the haul road To Haul Road

30 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

31 Conclusions ISO 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

32 Why is he wearing a hi-vis jacket? Torbjörn Holmström, CTO at Volvo Group

33 Thank you and Questions UofA ALIGHT GMSG Heather and Tim You all for your time and attention Functional safety an IEC Compliant Development Process Medoff/Faller The Laws of Robots Ugo Pagallo Jonathan Moore I d be grateful of a ride to get to my hotel at the airport.