Christophe Debou. Can I still trust my car with so much software in it? May

Transkrypt

1 Can I still trust my car with so much software in it? May Christophe Debou Kugler Maag Cie christophe.debou@kuglermaag.com KUGLER MAAG CIE GmbH Seite 1 Christophe Debou Qualifications SEI-authorized introduction to CMMI Version 1.3 for Development, Supplement CMMI for Services ITIL V3 Foundation Certified Scrum Master Experience Many years of training and presentation experience Project management Process Director Computer Science Engineer Ecole Nationale Supérieure de Sciences, Lannion/France, 1990 Languages French, German, English, Polish CMMI (training over 150 professionals for the SEIaccredited CMMI Introduction) Speaker at numerous international conferences Experience cont. Practical, hands-on experience in advising on and managing process improvement programs (based on CMMI or Automotive SPICE) in different business domains and cultural environments: Automotive, Finance, IT France, Germany, Scandinavia, Central and Eastern Europe Development and Service Management organizations Previous Positions ComArch SA, Cracow, Poland, Member of the Board Q-Labs GmbH, Germany, Operating Manager Alcatel Belgium, France, Austria, Manager of Software Process and Technology Seite 2 Agile and still compliant with Automotive Standards 1

2 O Nas Kilka Faktów Fakty Rok założenia: 2004 Zespół: Ponad 60 ekspertów Specjalizacja: Doskonalenie procesu tworzenia oprogramowania Obszary Wsparcia: CMMI, SCRUM, Automotive SPICE/ ISO 15504, Functional Safety/ IEC 61508, Zarzadzanie Zmianą Branże Przemysł Motoryzacyjny, Medyczny, Kolejowy, Lotniczy Finanse, ICT i Telekomunikacja Klienci Ameryka, Europa, Azja Partnerzy MBtech Page 3 Zakres świadczonych usług Doskonalenie procesów Identyfikacja procesów, wymagających poprawy w Firmie Wdrożenia Definiowania procesów, dopasowanych do indywidualnych potrzeb Klienta (gotowe procesy z półki ) Realizacja procesów na poziomie organizacyjnym Zarządzanie zmianą Zarządzanie Zmianą na poziomie organizacyjnym Definiowania i implementacja Strategii Zarządzania Zmianą Oceny Gap Analysis Appraisal CMMI Assessment ISO/ IEC 15504/ Automotive SPICE Zarządzanie wiedzą Szkolenia praktyków, Grup SEPG, Grup ds. Zarządzania Jakością w Firmie, Assessorów,, Kierowników Projektów, Członków Zarządu Szkolenia na temat obowiązujących standardów zarządzania jakością oraz ich praktycznego użycia Szkolenia Otwarte i Zamknięte ( szyte na miarę potrzeb Klienta) Page 4 2

3 Konkretne Obszary Wsparcia CMMI CMMI for Development CMMI for Acquisition CMMI for Services Oficjalny Partner SEI SPICE Automotive SPICE, ISO Współzałożyciel intacs Functional Safety IEC ISO Zarządzanie projektami PMI, PMBOK Prince 2, OPM3 Zarządzanie jakością Zapewnienie i Kontrola Jakości TS 16949, ISO 9001, VDA 6.3, CMMI/PPQA, SPICE/SUP.1, Inżynieria wymagań Zarządzanie Wymaganiami, Analiza i Przygotowywanie Wymagań Zarządzanie zmianą Koordynowanie Projektów, związanych z Zarządzaniem Zmianą w Organizacji SCRUM / Agile Szkolenia, wdrożenia Coaching zespołów projektowych Skalowanie w dużych organizacjach Page 5 W Centralnej i Wschodniej Europie (CEE) Oddział KMC w Krakowie Realizujemy Projekty w Czechach, Polsce, Rumunii, Ukrainie i na Węgrzech Posiadamy sieć partnerów lokalnych Promujemy zagadnienia doskonalenia procesów wytwórczych: Seminarium CMMI, Warszawa-Wrzesień 2006 Międzynarodowa Konferencja CEE-SPI, Kraków-Wrzesień 2007 Międzynarodowa Konferencja CEE-SPI, Budapeszt-Listopad 2008 Warsztaty CMMI for Services, Warszawa-Maj Międzynarodowa Konferencja CEE-SPI, Bukareszt-Październik 2009 Workshop 6 Sigma w IT, Warszawa-październik 2010 Międzynarodowa Konferencja CEE-SPI, Sofia-Październik, 2010 Międzynarodowa Konferencja CEE-SPI, Warszawa-Październik, 2011 Międzynarodowa Konferencja CEE-SPI/AGILE, Warszawa, 25 Października 2012 Page 6 3

4 CUSTOMERS CEE F22 Raptor, 1.7 MLOC F-35 Joint Strike Fighter 5.7 MLOC Boeing s 787 Dreamliner 6,5 MLOC Modern premium car 100 MLOC ECUs 4

5 Premium Car Radio Navigation System: 20 MLOC Cost of software and electronics up to 40 per cent of the total cost Near Future: 200 million to 300 million lines of software code!! Even low-end cars now have 30 to 50 ECUs embedded 5

6 90% of Innovation is determined by Software Mercedes S-Class Infotainment Subsystem 20 Mio. LOC networked ECUs 6

7 Development of Automobile Software Realization of new features and products without software is not possible Software is a competition and differentiation factor Mechanics and hydraulics is substituted by electronics Replacement of mechanical controlled functions Mechatronic combines mechanics and electronics 80-90% of innovation in cars based on electronic and software 50-70% of ECU Development costs is software Quality Problems in Electronics Cars break down, customers walk away Distribution of the cause of car problems in Germany (%) Electric/Electronic 6 5,7 5 9,5 49,2 Engine Heat sink Wheel/tires 10,5 Fuel system 6,9 7,2 Fuel injection Transmission Source: Der Spiegel (a major German news magazine) in 2003 Others 7

8 Efficient Quality Assurance Typical fault correction during: concept phase 1 keuro A sample 3,5 keuro B sample 4 keuro C sample 6 keuro PV series 65 keuro 0 series 80 keuro series 90 keuro Therefore: Catch defects as early in the process as possible! Data: HIS (Audi, BMW, Daimler, Porsche and Volkswagen); not considering vehicle modifications (like flashing, rework etc.) 8

9 Specifics in Automotive Industry Software as technology has not generally been understood by the vehicle manufacturer, tendency to assume software has no lead time! Embedded, distributed and real-time systems + (Safety) More than 50% of problems from relationships between supplier and customer Poor requirements and lack of controlled process Management and traceability of requirements are major preoccupations due to complexity and diversity of automotive systems Increasing Process Complexity: Single Programmer s ability won t be enough!! Technical complexity (LOC) Organizational complexity 1,000-5,000 Individual programmer 5,000-25,000 Small team 25, ,000 Large subdivided team 100,000-1,000,000 Several teams or divisions 1,000,000-10,000,000 Several companies 10,000, ,000,000 National undertaking 9

10 Process Improvement is an important part of the solution People Mastering Costs and Complexity Decreasing TTM Process Technology HIS - Structure 10

11 The basic idea of Automotive SPICE ISO/IEC allows the creation of domain-specific models consolidated under one common umbrella. The car industry made use of this feature: In 2005, the Automotive Special Interest Group (AUTOSIG) of the Procurement Forum published the Automotive SPICE -Model (AUDI AG, BMW Group, Daimler AG, Fiat Auto S.p.A., Ford Werke GmbH, Jaguar, Land Rover, Dr. Ing. h.c. F. Porsche AG, Volkswagen AG and Volvo Car Corporation) Automotive SPICE contains a methodology and structures to perform assessments of processes It allows organizations to examine and evaluate their own processes use the assessment model as a guideline to improve their processes evaluate other organizations (e.g. their suppliers) Download of the Automotive SPICE -Model at Automotive SPICE Representation Level 5: Optimizing CAPABILITY Dimension Level 4: Predictable Level 3: Established Level 2: Managed Level 1: Performed Level 0: Incomplete ACQ (7) SPL (2) ENG (10) PROCESS Dimension SUP (7) MAN (3) PIM (1) REU (1) 11

12 Processes ISO/IEC , Automotive SPICE & HIS Scope Acquisition Process Group (ACQ) Engineering Process Group (ENG) Supporting Process Group (SUP) ACQ.1 Acquisition preparation A ENG.1 Requirements elicitation A SUP.1 Quality assurance ACQ.2 Supplier selection A ENG.2 System requirements analysis A SUP.2 Verification A ACQ.3 Contract agreement A ENG.3 System architectural design SUP.3 Validation A ACQ.4 Supplier monitoring A ENG.4 Software requirements analysis A SUP.4 Joint review ACQ.5 Customer acceptance A ENG.5 Software design SUP.5 Audit A ACQ.11 Technical requirements A ENG.6 Software construction SUP.6 Product evaluation A ACQ.12 Legal and administrative requirements A ENG.7 Software integration A SUP.7 Documentation A ACQ.13 Project requirements A ENG.8 Software testing A SUP.8 Configuration management A ACQ.14 Request for proposals A ENG.9 System integration A SUP.9 Problem resolution A ACQ.15 Supplier qualification A ENG.10 System testing A SUP.10 Change request management ENG.11 Software installation ENG.12 Software and system maintenance Management Process Group Resource & Infrastructure Process Group (RIN) Operation Process Group (OPE) MAN.1 Organizational alignment assurance RIN.1 Human resource management OPE.1 Operational use MAN.2 Organization management RIN.2 Training OPE.2 Customer support A MAN.3 Project management RIN.3 Knowledge management MAN.4 Quality management RIN.4 Infrastructure A MAN.5 Risk management A MAN.6 Measurement Supply Process Group (SPL) Process Improvement Process Group Reuse Process Group (REU) A SPL.1 Supplier tendering PIM.1 Process establishment REU.1 Asset management A SPL.2 Product release PIM.2 Process assessment A REU.2 Reuse program management SPL.3 Product acceptance support A PIM.3 Process improvement REU.3 Domain engineering A Automotive SPICE Not in ISO/IEC Part-5 HIS Scope The Capability Dimension of Automotive SPICE OPTIMIZING PREDICTABLE ESTABLISHED MANAGED PERFORMED INCOMPLETE

13 Example: Supplier Rating at Volkswagen Group Rating A B C Result of the process assessment according ISO/IEC All ENG processes at least Level 1 (Fully) All Non-ENG processes Level 2 All assessed processes according to standard at least Level 1 At least one assessed process is not rated Level 1 Processes Capable of quality Capable of quality under certain preconditions Not capable of quality Actions Continuous improvement towards higher levels Schedule and implement improvement program Immediate actions Start improvement project No assignment for new development VW Benefits Good Process Capability 13

14 Example: Volkswagen Rating of current suppliers Software Quality is not well-established at Automotive Suppliers for Software centered systems Product maturity: cumulative curve of errors found 14

15 Correlation between process capability and product maturity Data by BMW from 26 ECU projects: What ISO 26262? Functional Safety Definition according to ISO 26262: Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E Systems Electronic can fail: Provide Evidences that risk have been minimized Random Failures: usually a permanent or transient failure due to a system component loss of functionality Hardware Related Systematic Failures: Usually due to a design fault, wrong specification, not fit for purpose, error in software program Seite 30 15

16 ISO Functional Safety Principles ISO/DIS Overview 1. Vocabulary 2. Management of functional safety 2-5 Overall safety management 2-6 Safety management during item development 2-7 Safety management after release for production 3. Concept phase 4. Product development: system level 7. Production and operation 3-5 Item definition 3-6 Initiation of the safety lifecycle 3-7 Hazard analysis and risk assessment 3-8 Functional safety concept 4-5 Initiation of product 4-11 Release for production development at the system level 4-10 Safety assessment 4-6 Specification of the technical safety requirements 4-9 Safety validation 4-7 System design 4-8 Item integration & testing 5. Product development: 6. Product development: hardware level software level 5-5 Initiation of product 6-5 Initiation of product development at the hardware level development at the software level 7-5 Production 7-6 Operation, service (maintenance and repair), and decommissioning 5-6 Specification of hardware safety requirements 5-7 Hardware design 5-8 Hardware arch. metrics 5-9 Evaluation of violation of the safety goals 5-10 HW integration& testing 6-6 Spec. of SW safety requirem. 6-7 Software architectural design 6-8 SW unit design&implementation 6-9 Software unit testing 6-10 Software integration& testing 6-11 Verification of software safety requirements 8. Supporting processes 8-5 Interfaces within distributed development s 8-6 Specification & management of safety requirements 8-7 Configuration management 8-10 Documentation 8-13 Qualific. Of HW components 8-8 Change management 8-11 Qualification of SW tools 8-14 Proven in use argument 8-9 Verification 8-12 Qualific. of SW components 9. ASIL-oriented and safety-oriented analyses 9-5 Requirements decomposition with respect to ASIL tailoring 9-6 Criteria for coexistence of elements 9-7 Analysis of dependent failures 9-8 Safety analyses 10. Guideline (informative) 16

17 Why Autosar? The Challenge: E/E complexity is growing fast Quantity of software is exploding Many different hardware platforms are used Development processes and data formats are not harmonized The main objectives of IMPROVE SOFTWARE QUALITY AND REUSE COSTS BY REUSE Reuse of functions across carlines and across OEM boundaries Reuse of development methods and tools Reuse of basic software 17

18 Conclusion 18

19 19