Agility and safety Agile development & ISO26262 State-of-Practice in Automotive Stockholm, 25-March-215 Horst Hientz, Dr. Erwin Petry www.kuglermaag.com KUGLER MAAG CIE GmbH Page 1
Agenda Brief introduction Agile Automotive Framework / Survey ISO 26262 development principles Agile & ISO 26262 Page 2
Kugler Maag Cie We are an independent consulting company supporting our customers world-wide particularly in the field of lasting performance improvements. Customers expectations Market expectations Management Products & Services Life Cycle Support Customers satisfaction Market position Our customer Our Focus Analyze, assess, and improve our customers' products and services value creation processes. We take operative responsibility and provide systematic and sustainable know-how transfer. Our Mission Support our customers in mastering risks associated with developing, acquiring or delivering software, systems, and services while maintaining the speed of innovation. besser mit uns Page 3 DAIMLER Automotive extract
Agile Automotive Framework based on input from [1] KUGLER MAAG MAAG CIE GmbH CIE GmbH [1] Agile in Automotive State-of-Practice 214, Kugler Maag Cie, 3/214: www.kuglermaag.de/agile214 Page 4
Automotive goes Agile The Survey is initiated and conducted by Kugler Maag Cie. The study is performed in the context of the major European research project SCALARE. This ITEA project supports the automotive industry in developing and expanding their ability to scale. SCALARE assumes that software will continue to be the key to bring about innovations and be able to provide holistic services. http://scalare.org/about-scalare/ Page 5
Rapid survey among participants Institutionalization of Agile in Automotive Agile methods Safety-related projects Application types Process areas supported by agile elements Tools used Page 6
Which phase of the Agile implementation is your organization currently in? Please indicate which phase the most mature agile project of your organization is in. A pilot is a small-scale attempt in order to evaluate the applicability of Agile; roll-out means an official launch of Agile (on a bigger scale). Stabilization is achieved when agile roles, ceremonies and artefacts are in place and Agile has become part of the culture. 4 11 3 3 No agile projects Piloting agile Roll-out Stabilization Page 7
Which Agile methods and practices do you use in your organization? In Scrumban, Scrum and Kanban are used in parallel. Here, Scrum is used for plannable development, while Kanban is covering the event-driven topics. Extreme Programming is an agile method that emphasizes business results first and takes an incremental, get-something-started approach to building the product. Feature Driven Development is a short-iteration development process that delivers features in logical incremental intervals. Test Driven Development is an agile practice in which a test is written before writing the code. Continuous Integration is the process of building your application on every new source code check-in. 17 4 1 2 1 1 Scrum Kanban Scrumban Extreme Programming (XP) Feature Driven Development (FDD) Test Driven Development (TDD) Continuous Integration (CI) Others Page 8
Do you apply agile methods and practices in safety-related projects? Multiple answers possible if projects with agile methods and practices have different ASILs. If you do apply another safety standard try to vote for the most appropriate ASIL. 4 6 6 3 Agile methods and practices only (!) in non safety-related projects ASIL A ASIL B ASIL C ASIL D Page 9
Which ECU/Application Types are covered in your Agile projects? Please indicate all ECU/Application Types that are covered in your agile projects. If several teams or projects cover different ECU/Application Types, please check every type that is covered. 3 Multimedia Applications Location-based Services Applications, Telematics, Radio Navigation 2 Body Electronics Body Controller, Sensors (Light, Battery, ), Instrument Cluster 4 Powertrain and Chassis Control Braking Systems, Engine Management 3 Integrated Systems/Services Intelligent Mirror, Active Safety, Driving Assistance/Automatic Driving Page 1
Which processes are covered within one sprint/cadence? Please indicate all the processes that are covered within one sprint/cadence. 8 11 19 1 1 System Requirements Analysis System Design Software Requirements Analysis Software Design Software Implementation Software Integration and Integration Test Software Test System Integration and Integration Test System Test Hardware Development Mechanical Engineering Page 11
Which tools do you use in your agile projects? (1) Please indicate tools you use in your organization. If you use other tools than those listed below, please leave a comment with the tool group and tool name. Project/CR/PR/Task Management 6 IBM Tool Suite (RTC) Jira Agile (former Greenhopper) MS Project PTC Integrity 1 Redmine 1 Serena Dimensions VersionOne 1 Others TFS Page 12
Which tools do you use in your agile projects? (2) Configuration Management 2 1 Clear Case Git IBM Synergy Mercurial PTC Integrity Serena Dimensions 5 Subversion 1 Others TFS Page 13
Which tools do you use in your agile projects? (3) Build Ant 1 Bitbake (Montavista, Mentor Graphics) 2 Cmake 1 Gmake 3 Jenkins Maven 4 Visual Studio Others Continuous Integration Bamboo Hudson 3 Jenkins Others Page 14
Which tools do you use in your agile projects? (4) Test/Test automation 2 Google Test Framework Jenkins PTC Integrity TM Quality Center Xunit 3 Others TFS Page 15
Agile Automotive Framework Kugler Maag Cie 215-2 Product R&D Organization Agile Engineering Adaptive Planning Agile Benefits Agile Evolution Agile Transformation Product Development Process Development Tool Chain Page 16
Agile Evolution is a team-centric choreography Level 4 Agile Enterprise Level 3 Agile R&D Level 2 Agile Project Level 1 Agile Team What Agile Methods (Test first/tdd, Continuous integration, Continuous delivery, Architecture refactoring) Bootstrap Initial Core Agile Roles (Feature Owner*, Scrum Master, Kanban Coach, Agile T-Shape Team) Agile Ceremony (Daily stand-ups, Retrospectives, Sprint/Cadence ) Agile Artifacts (Task-Boards, Feature/ Team-Backlog, Definition-of-Done/ Definition-of-Ready) Where Any Engineering Discipline! (SW, HW, EM, Mech., ) Benefits Quality artifacts (code, ) No technical debt build-up Self-organizing teams Work-in-Progress/ Bottleneck transparency Fast-feedback loops Where Whole Sub-Project / Project What Agile Roles (Product Owner, Quality PO, Safety PO, + FO*, SE Team) Agile Ceremony (Release Planning & Review, Release Retrospectives) Agile Artifacts (Project Backlog) Benefits Responsiveness to customer Continuous delivery Better integrated & tested products Higher First-Pass-Yield Where Whole R&D Organization What Agile Roles (Servant Leader) Agile Methods (Theory of Constraints, High Resolution Management, ) Benefits Shorter time to market More innovations Where Whole Enterprise What Agile Roles (Enterprise Transition Community, HR, Sales, Marketing, Infrastructure) Benefits Change Responsiveness (Adaptiveness) Learning Organization Antifragility Page 18
Product R&D Organization, e.g. Tier-1 Customer (OEM) new Customer / Application Projects EU CEE APAC NAFTA Roles CR Project Management Systems Engineering Software Hardware Mechanics Product Owner, Feature Owner, SE Team, Sys Architect/Int/Test, Quality Product Owner, Safety Product Owner Platform Projects CR Project Management Systems Engineering Software Hardware Mechanics Product Owner, Feature Owner, SE Team, Sys Architect/Int/Test Technology Domains CR OS NAND HMI ECU Display Housing Feature Owner, Scrum Master, Kanban Coach, Agile T-Shape Team Software Hardware ME Page 21
Product Development Process, e.g. Tier-1 Platform/ Application System 1. - RA & AD 2. - RA & AD 3. - RA & AD Continuous Integration / Continuous Delivery 1. Sample 2. Sample SW 1.1- RA & AD 1.2 - RA & AD 1.3 - RA & AD 2.1 - RA & AD 2.2 - RA & AD 2.3 - RA & AD 3.1 - RA & AD HMI 1.1 - IT & ST 1.2 - IT & ST 1.3 - IT & ST 2.1 - IT & ST 2.2 - IT & ST 1.1 - Sprint 1.2 - Sprint 1.3 - Sprint 2.1 - Sprint 2.2 - Sprint 2.3 - Sprint Common Common Common Common Common Common Repository Repository Repository Repository Repository Repository Team OS NAND Techn. Domain 1.1 - Sprint 1.1 - Sprint 1.2 - Sprint 1.3 - Sprint 2.1 - Sprint 2.2 - Sprint 2.3 - Sprint 1.2 - Sprint 1.3 - Sprint 2.1 - Sprint 2.2 - Sprint 2.3 - Sprint 1.1 - Cadence 1.2 - Cadence 2.1 - Cadence 2.2 - Cadence HW ECU Display 1.1 - Cadence 1.2 - Cadence 2.1 - Cadence 2.2 - Cadence 1.1 - Cadence 1.2 - Cadence 2.1 - Cadence 2.2 - Cadence ME Housing Techn. Domain 1.1 - Cadence 1.2 - Cadence 2.1 - Cadence 2.2 - Cadence 1.1 - Cadence 1.2 - Cadence 2.1 - Cadence 2.2 - Cadence Page 22
Agile Engineering, e.g. SW Development Process Requirement Requirement analysis verifies criteria Req. test development Architecture development Design development Common Repository Continuous Deployment Implementation verifies Unit test development criteria Integration test development Page 26
ISO 26262 development principles KUGLER MAAG MAAG CIE GmbH CIE GmbH Page 28
Work Products, specific for Functional Safety Functional Safety Concept 2-5 Overall safety management 2. Management of functional safety 2-6 Safety management during the concept phase and the product development 3. Concept phase 4. Product development at the system level 7. Production and operation 4-5 Initiation of product 4-11 Release for production Functional 3-5 Item definition development Technical at the system level 7-5 Production Technical Safety 4-1 Functional safety assessment Safety 3-6 4-6 Specification of the Hazard Initiation of the safety Safety Assessmen technical safety requirements 4-9 Safety validation 7-6 Operation, service lifecycle Requireme Validation Analysis Concept t Report (maintenance and repair), and nts Report 4-7 System design 4-8 Item integration and testing decommissioning 3-7 and Hazard Risk analysis and risk assessment 5. Product development at the 6. Product development at the t Hardware hardware level software level Software 3-8 Functional safety concept 5-5 Initiation Safety of product 6-5 Initiation of product Safety development at the hardware level development at the software level Assessmen Functional Safety Manageme nt Procedure Functional Software Safety Tool Engineering Support Procedure Procedure Requireme nts 5-6 Specification of hardware safety requirements 5-7 Hardware design 5-8 Evaluation of the hardware architectural metrics 1. Vocabulary Confirmatio n Reports FMEDAs 5-9 Evaluation of safety goal violations due to random HW failures 5-1 Hardware integration & testing 8. Supporting processes Safety Plan Safety Case 6-6 Spec. of SW safety requirem. 6-7 Software architectural design 6-8 SW unit design & implementation 6-9 Software unit testing 6-1 Software integration & testing 6-11 Verification of software safety requirements 2-7 Safety management after the item s release for production Requireme nts List of Work Products not complete 8-5 Interfaces within distributed developments 8-6 Specification and management of safety requirements 9-5 Requirements decomposition with respect to ASIL tailoring 8-7 Configuration management 8-1 Documentation 8-8 Change management 8-9 Verification 8-11 Confidence in the use of software tools 9. ASIL-oriented and safety-oriented analyses 9-6 Criteria for coexistence of elements Software Tool Qualificatio n Report FTA, FMEA, 8-12 Qualification of SW components 8-13 Qualification of HW components 8-14 Proven in use argument 9-7 Analysis of dependent failures 9-8 Safety analyses 1. Guideline on ISO 26262 (informative) Page 29
Some other important Work Products Item Definition DIAs 2-5 Overall safety management 5. Product development at the hardware level 5-5 Initiation of product development at the hardware level 5-6 Specification of hardware safety nts requirements 2. Management of functional safety 3. Concept phase 4. Product development at the system level 7. Production and operation 4-5 Initiation of product 4-11 Release for production 3-5 Item definition development System at the system level Hardware- 7-5 Production Requireme Software- 4-1 Functional safety assessment 4-6 Specification System 3-6 Initiation of the safety nts of the Interface technical safety requirements 4-9 Safety validation 7-6 Operation, service lifecycle Design Specificatio Specificatio (maintenance and repair), and 4-7 System design 4-8 Item integration and testing decommissioning 3-7 Hazard analysis and risk assessment 3-8 Functional safety concept Verification Reports for many documents 8-5 Interfaces within distributed developments 8-6 Specification and management of safety requirements Developme nt Process n Hardware Requireme 1. Vocabulary Project Plan 2-6 Safety management during the concept phase and the product development Hardware Designs 5-7 Hardware design 5-8 Evaluation of the hardware architectural metrics 5-9 Evaluation of safety goal violations due to random HW failures ns 5-1 Hardware integration & testing Configurati on Manageme nt Plan 8. Supporting processes 6. Product development at the software level 6-5 Initiation of product development at the software level Software Requireme nts Audit Reports 6-6 Spec. of SW safety requirem. 6-7 Software architectural design 2-7 Safety management after the item s release for production Software Designs 6-8 SW unit design & implementation 6-9 Software unit testing 6-1 Software integration & testing 6-11 Verification of software safety requirements 8-7 Configuration management 8-1 Documentation 8-8 Change management 8-9 Verification Change Requests 8-11 Confidence in the use of software tools Test Specificatio ns Production 8-12 Qualification of SW components 8-13 Qualification of HW components 8-14 Proven in use argument Test Reports Operation, service, decommissi oning 9-5 Requirements decomposition with respect to ASIL tailoring 9. ASIL-oriented and safety-oriented analyses 9-6 Criteria for coexistence of elements 9-7 Analysis of dependent failures 9-8 Safety analyses 1. Guideline on ISO 26262 (informative) Page 3
Agile & ISO 26262 KUGLER MAAG MAAG CIE GmbH CIE GmbH Page 32
Product Owner Safety The Safety Product Owner focuses on functional safety and supports the Product Owner (functional and business aspects) and Quality Product Owner (product and process quality) with functional safety aspects Supports the interpretation, detailing and prioritisation of the requirements for functional safety in the Product Backlog Responsible for safety planning and monitoring Expert, Coach and Monitor for the implementation of the requirements, processes and methods needed for functional safety Defines and schedules the activities necessary for functional safety (e.g. reviews, audits, safety assessments) Checks the Definition-of-Done (DoD) and if necessary extends it to include full implementation of the (standard) requirements for functional safety (e.g. application of methodology) Checks that activities related to functional safety and the extended DoD are being implemented Supports the team when presenting and carrying out safety analyses Creates and maintains the safety case Participates in the Sprint Review to accept the deliverables. May participate in the Retrospective in order to provide an external perspective on where there is room for improvement Represents a key contextual bridge between the team s local focus and the company s global view of functional safety Page 33
Typical State Machine for Functional Safety Work Products To be implemented through Definition-of-Done mechanism draft informal verification under revision informal verification formal verification next cycle (SPRINT, cadence, sample, ) informally released for limited usage formal verification next cycle (SPRINT, cadence, sample, ) confirmation review formally released confirmed evidence in final safety case Page 34
Example: Quality Attributes of the Technical Safety Concept (TSC) TSC table of contents scope collection of key concepts informal verification When: A-Sample phase Informally verified (team: Definition-of-Done) TSC safety goals stable ASILs known functional safety requirements stable key technical safety requirements stable key safety mechanisms defined Informally verified informal verification When: B-Sample phase (team: Definition-of-Done) Formally verified (ISO 26262-8, clause 9) TSC complies with ISO 26262-4, clause 6.4.6, requirements for the work product technical safety requirements specification complies with ISO 26262-4, clauses 6.5.1 and 7.5.1 formal verification When: C-Sample phase Page 35
Key Work Products Quality Attributes built-up over development cycles (1) Preparation & planning Item definition Hazard analysis and risk assessment FSC including FSR Safety plan of the 1 st tier TSC including TSR (1) (1) (1) 2) Implementation Safety analyses Concept FMEA System FMEA System FTA FMEDA SW-FMEA Design & implementation System level Hardware level Software level incl. unit test development and unit testing Test specification System level Hardware level Software level Test execution System level Hardware level Software level (2) (2) (2) (2) (2) (2) (2) (3) Confirmation Safety audit Safety case Safety assessment Safety validation (3) (3) (3) Page 36
Some Conclusions Agile in Automotive is applying customized methods and practices. No verbatim interpretation of the Agile Manifesto. Compliance with ISO 26262 is achievable. Complex Automotive projects in a dynamic environment can hardly be implemented with the traditional approach. Manage safety requirements in the backlog with high priority Beginning to apply Agile in safety-related projects does not yet need organizational changes. Add a few roles: Product Owner, Scrum Master, Safety Product Owner Work on the Definition-of- Done for safety work products. Define iterations for completeness, quality and ISO 26262 compliance The use of appropriate tools is key for Agile and important for the safety case, e.g. Jira Agile, Jenkins, PTC Integrity Page 37
Thank you! Questions? KUGLER MAAG CIE GmbH Leibnizstr. 11, 786 Kornwestheim, Germany Phone +49 7154 1796 1 information@kuglermaag.com www.kuglermaag.com KUGLER MAAG CIE GmbH Page 38