Dependable autonomous vehicles

Transcription

1 Dependable autonomous vehicles Paul Pop Technical University of Denmark (DTU), DTU Compute Ph.D. in Computer Systems Linköping University Sweden Assistant professor Linköping University Sweden Associate professor DTU Compute, Technical University of Denmark (DTU) Professor DTU Compute, Technical University of Denmark (DTU) Director 1

2 2 Billion $1.9 Trillion 25% by 2035 annual savings with vehicle-to-vehicle communication economic impact of nearautonomous vehicles by 2025 Market penetration of autonomous vehicles by

3 Safety-assurance is a potential show-stopper 3

4 4

5 Hazard and Risk A hazard is a situation in which there is actual or potential danger to people or to the environment. Example hazard insulin overdose Safety Risk Management Risk Risk is ma atrix combination of the frequency or probability of a specified hazardous event, and its consequence. Example: Negligible Minor Serious Critical Catastrophic Frequent Probable Occasional Remote Improbable Legend: Unacceptable As Low As Reasonably Practicable (ALARP) Insignificant 5

6 Certification For safety-critical systems, decision-makers require pre-release safety assurance evidence that it manages risk acceptably. Safety standard Highly critical systems require certification by a regulatory authority. Company System and Safety Requirements Independent safety assessor Environment System Argumentation Documents Verification Evidence Certificate Source: Hans Hansson 6

7 Certification ISO26262 work products Plans (16) 1. Project management plan 2. Safety plan 3. Safety assessment plan 4. Item integration and test plan 5. Validation plan 6. SW verification plan 7. Design and coding guidelines 8. Production plan 9. Production control plan 10. Maintenance plan 11. Configuration management plan 12. Change management plan 13. Change request plan 14. Documentation management plan 15. HW qualification plan 16. HW component test plan Safety does not happen by accident Artifacts (43) 1. Safety Case 2. Evidence of field monitoring 3. Item definition 4. Impact analysis (modified item) 5. Hazard analysis 6. Safety Goals 7. Functional safety concept 8. Technical safety req. spec. 9. Technical safety concept 10. System design spec. 11. HW/SW interface spec. 12. Production, operation, service, decommissioning. Spec. 13. Integration test spec. 14. HW safety req. spec. 15. HW design spec 16. Analysis of Architecture wrt random failures 17. Analysis of safety goal violation due to random failures 18. Specification of dedicated measures for HW, 19. SW safety req. spec. 20. SW architectural design spec. 21. SW unit design spec 22. SW unit implementation 23. SW unit test spec 24. SW integration test spec 25. Embedded Software (integrated) 26. SW safety req. test spec. 27. SW configuration data spec. 28. SW calibration data spec. 29. Configuration data 30. Calibration data 31. SW configuration & configuration test spec 32. Production requirements (system, HW & SW) 33. Service/maintenance requirements (system, HW & SW) 34. Repair instructions 35. Manual (safety related content) 36. Problem report instructions/process 37. Decommissioning instructions 38. Interfaces within distributed developments (includes 6 artifacts) 39. Change request 40. Change Impact analysis 41. Documentation guideline requirements 42. Software component documentation 43. Proven in use candidate documentation/evidence Verification/reports (57) 1. Safety plan (confirmation) 2. Safety Case (confirmation) 3. Hazard analysis (confirmation) 4. Item integration and test plan (confirmation) 5. Validation Plan (confirmation) 6. Safety Goals 7. Functional safety concept 8. Technical Safety req. spec 9. Technical safety concept 10. System design spec. 11. HW/SW interface spec. 12. Production, operation, service, decommission. Spec. 13. System level safety analysis (confirmation) 14. Integration test spec 15. Integration test records 16. Validation 17. Safety assessment/audti (confirmation) 18. Release for production 19. HW safety req. spec. 20. HW design spec 21. HW safety analysis report 22. Analysis of Architecture for random failures 23. Analysis of safety goal violation due to random failures 24. HW integration test report 25. SW safety req. spec. 26. SW architectural design spec 27. SW Safety analysis report 28. SW Dependent failure analysis report 29. SW unit design spec 30. SW unit implementation 31. SW unit test spec 32. SW unit test records 33. SW unit test report 34. SW integration test spec 35. SW integration test records 36. SW integration test report 37. SW safety req. test spec. 38. SW safety req. test records 39. SW safety req. test report 40. SW configuration data spec. 41. SW calibration data spec. 42. SW configuration & configuration test spec 43. SW configuration & configuration test records 44. SW configuration & configuration test report 45. Production control measures report 46. Production requirements (system, HW & SW) 47. Assessment report for capability of the production process 48. Maintenance plan 49. Interfaces within distributed developments 50. Change management plan 51. Change request plan 52. Change report 53. Software tool evaluation report 54. Software tool qualification report 55. Software component qualification report 56. HW qualification report 57. Proven in use analysis report (confirmation) Source: Hans Hansson 7

8 Deterministic Ethernet 8 History, markets and use cases Example in-vehicle dependable architecture Today s car architectures are highly dependable But! Autonomous functions cannot be safe-assured today When did we gather enough evidence that an autonomous car is safe? After it drove: 100 billion km to collect evidence on the same safety level as the current vehicles 8

9 9

10 10

11 Safety: a huge challenge with autonomous systems How to extend the current safety assurance practice to consider autonomous systems? What safety functions can be automated, and what are the right barriers? Can these systems be self-safe? Is just-in-time certification possible? 11

12 12

13 chitecture ECSEL Call IA ENABLE-S3 EU ECSEL, , 143 M, 74 partners Full Project Proposal European Initiative to ECSEL Enable Call 2015 Validation - IA for Highly Automated Safe and Secure Systems Full Project Proposal Combination of real and virtual components As simulation models in validation scenarios do not implement all features, especially behaviour in case of irregular conditions, not all errors can be detected in simulated, virtual environments. Therefore it is required to combine real and simulated components in the validation platform for a higher test- Figure 3-11: Overtaking chauffeur Objectives Substitute today s cost-intensive validation and verification efforts by virtual and semi-virtual testing and verification, coverage-oriented test selection coverage. methods and standardization for efficient development of highly automated and autonomous systems. In order to connect simulated with real objects, stimuli are required, which convert simulated values into real signals (e.g. for radar, ultrasonic, camera, etc.). It is one goal of the project to develop all required stimuli (at least 3) necessary to connect the simulated with the real world in ACPS validation. Full Project Proposal ECSEL Call IA ECSEL Call IA The figure below shows the countries of the partners in ENABLE-S3. The figures indicat partners per country. Rear SCALA Ultrasounds Frontal Camera Coccon Cameras MB79 Radar Front SCALA Danish focus: automated farming Partners: Figure 1-2: Intended reduction of validation effort compared to conventional tes The ENABLE-S3 project will provide European industry with leading-edge technol development of reliable, safe and secure functions for highly automated and/or a systems by enabling their economically feasible validation and verification (see F Figure 3-12: Proposed vehicle architecture for the development of this use case are: e specifications equipment re development re integration closed environment 5 m 25 m 100 m 150 m Figure 1-8: Stimuli in HiL validation platform DTU Runtime validation, and health industry. analysis and config. of communication NABTO (SME) 1.3 Technical objectives Sky-Watch (SME) ENABLE-S3 will significantly contribute to technological leadership in a market of Technical objective 1 ENABLE-S3 will provide a modular verification and validation framework that pro safety and security of ACPS. Aalborg University Impact: Reduce at least 50% of test execution effort compared to conventional testing. Builds on GUARD EMC2 rs plan to use the methodologies and tools from the ENABLE-S3 project to check the enefits associated to this new V&V development tool chain. e main challenges are: the Traffic Jam situations in the simulation tool, with real-time world ntation and closed loop interactions between the ego-vehicle and the other road the possibility to emulate the sensors of different nature such as cameras, laser EU ECSEL failed proposal 2014, 69 partners, >100 M, WP leader, country coordinator EU ECSEL AIPP project, 99 partners, 100 M, WP leader and country coordinator ENABLE-S3 will develop a modular verification and validation framework t replication of test scenarios for different automated functions for various appl park assistant vs. intersection crossing with automated vehicles which represen contexts). The framework is applicable to 6 different industry domains. Tests different levels of complexity and time frames. ENABLE-S3 provides a library of modular technology bricks used to build tailor individual domains, rather than developing a generic framework that is appl 10 of 444 automated system. Therefore, the main effort addresses the development of re standardized interfaces for easy test platform configuration (in particular 13 for time co-simulation).

14 14

15 15

16 Safe Stop: several redundant sensors System Overview Sensor preprocessing Sensor Fusion Decision System 16

17 SafeCOP ECSEL , 28 partners, 5 countries 11 M EU budget, 1,300 PMs 24 MDH 1 ALT Safe Cooperating Cyber-Physical Systems (CO-CPS) using Wireless Communication Partners 25 QAM COM Objectives Develop a safety-assurance framework for CO-CPS. 20 SINTEF 18 DNVGL 26 KTH 6 FMI Develop a reference platform to support the engineering and certification of CO-CPS. 19 MARO 27 SAFI 7 MOBI SOFT Extend the current wireless protocols for safe & secure cooperation. Contribute to new standards and regulations. Demonstrate the usefulness of SafeCOP concepts in target applications DTU TEC OUH 3 DTI 28 SICS 8 ALTE S1 Com. S2 21 ISEP 9 UNIVAQ 10 CNR 14 THALIT Coopera ve Open Cyber-Physical Systems (CO-CPS) 22 GMV 11 IBTS 15 AIT 23 TEK 12 IMPARA 16 ROT 13 POLIMI 17 INT Builds on EMC2 ECSEL AIPP project, 99 partners, 100 M, WP leader and country coordinator Cou try Coordi ator Cou try OEM Wireless Certifatio SME LE Body W PLeader UC Leader Tech o ogy/ Too Provider Research RECOMP EU ARTEMIS, 41 partners from 9 countries, WP leader and country coordinator 17

18 18

19 19

20 DTU s IoT Center, iotcenter.dk We are open to researchers from other departments at DTU, other Danish universities, and we re welcoming company members. Mission: Performing research on IoT technologies and facilitating collaboration among researchers and practitioners in Denmark. Vision: Dependable and secure IoT enables efficient solutions to societal challenges. Prof. Paul Pop. Industrial IoT Prof. Nicola Dragoni. IoT Security and Privacy Prof. Jens Sparsø and Assoc. Prof. Martin Schoeberl. IoT Platforms Assoc. Prof. Michael S. Berger. IoT Communications Infrastructure Prof. Henrik Madsen. IoT Cyber-Physical Modeling and Smart Energy IoT Prof. Lars Kai Hansen group. IoT Data Analytics Prof. Jan Madsen. Health IoT Assoc. Prof. Sven Karlsson. IoT System Software 20