Where Are the Standards Going?

Where are the standards going?

Even-André Karlsson Agenda

. Introduction . Maturity standards . Safety standards . Current connections . Discussion - Merging - Goal based or prescriptive - Safety case or process compliance - Safety levels - Staged or continuous - Next step: Security

. Unifying different maturity approaches: CMM, BOOTSTRAP, Trillium, ... . Published as ISO-standard - 1998 as TR (Technical Report) ISO/IEC 15504:1998 - 2003-2005 revision of TR in Form as International Standard - 2015: 15504 was replaced by ISO 33001 . Adaptation to several industry branches: Aerospace (SPiCE4Space), Medicine (MediSPiCE), Automotive: HIS-Subset TR 99, Automotive SPICE 2004 . Automotive SIG (Special Interest Group) - SPiCE User Group: [email protected] - Procurement Forum: www.procurementforum.org/ - Automotive SPICE: www.automotivespice.com - Gate4Spice: www.gate4spice.net . OEMs:

SPICE provides a generic framework to incorporate Process Reference and Adoption to several industrial sectors: Assessment Models Automotive SW related (in general) - Subset of SPICE Processes - New automotive genuine ISO 15504 Processes Detailed automotive specific SPICE4Space - Base Practices - Work Products

SW related (in general): - Base Practices Version 3.0 released MediSPICE - Work Products July 2015

PRIMARY Life Cycle Processes PRIMARY Life Cycle Processes ORGANIZATIONAL Life Cycle (cont.) Processes Acquisition Process Group (ACQ) Management Process Group (MAN) ACQ.1 Acquisition preparation Operation Process Group (OPE) MAN.1 Organizational alignment ACQ.2 Supplier selection OPE.1 Operational use MAN.2 Organizational management A ACQ.3 Contract agreement OPE.2 Customer support A MAN.3 Project management A ACQ.4 Supplier monitoring MAN.4 Quality management ACQ.5 Customer acceptance A MAN.5 Risk management A ACQ.11 Technical requirements SUPPORTING Life Cycle A MAN.6 Measurement A ACQ.12 Legal and administrative requirements Processes Resource & Infrastructure Process A ACQ.13 Project requirements Support Process Group (SUP) A ACQ.14 Request for proposal Group (RIN) A ACQ.15 Supplier qualification A SUP.1 Quality assurance RIN.1 Human resource management A SUP.2 Verification RIN.2 Training Supply Process Group (SPL) SUP.3 Validation RIN.3 Knowledge management A SPL.1 Supplier tendering A SUP.4 Joint Review RIN.4 Infrastructure A SPL.2 Product release SUP.5 Audit SPL.3 Product acceptance support SUP.6 Product evaluation Reuse Process Group (REU) A SUP.7 Documentation REU.1 Asset management Engineering Process Group (ENG) A SUP.8 Configuration management A REU.2 Reuse program management A ENG.1 Requirements elicitation A SUP.9 Problem resolution management REU.3 Domain engineering A ENG.2 System requirements analysis A SUP.10 Change request management A ENG.3 System architectural design Process Improvement Process Group (PIM) A ENG.4 Software requirements analysis PIM.1 Process establishment A ENG.5 Software design PIM.2 Process assessment A ENG.6 Software construction A PIM.3 Process improvement A ENG.7 Software integration ISO/IEC 15504-5 process A ENG.8 Software testing A Automotive SPICE process A ENG 9 System integration A ENG.10 System testing HIS-Scope ENG.11 Software installation ENG.12 Software and system maintenance not included in ISO/IEC 15504-5

Automotive SPICE (Version 3.0) Extended HIS Scope

Previously Eng 1-10 Changes in Test structure

. The principles underpinning Functional Safety were developed in the military, nuclear and aerospace industries during the 1960-1970 ties . 1995 IEC 1508 - New approach to functional safety – Risk based - Define safety requirements to reduce risk . 1998-2000 IEC 61508

- Build on IEC 1508 ISO 26262 Automotive

. IEC 61508 detailed in IEC 61511 IEC 62061 Process Machinery - Medical IEC 62304 industry IEC - Machinery IEC 62061 61508 - Railway EN 5012X Generic

IEC 62304 - Nuclear Process IEC 61513 … IEC 61513 Medical IEC 60880 - Automotive IEC 26262 EN 50126 IEC 62138 EN 50128 Nuclear EN 50129 Railway

Process industry, Medical industry

Planes, Busses, Ships, Trains

Cars, MC, Robots, Medical equipment

Smaller equipment

Safe state? Human control?

. Is there really a conflict? . Each prescriptive practice should have a goal/objective – any alternative should fulfill the same goal/objective . A prescriptive standard provides guidance . A safety case summarize and argues that the system developed according to the standard is safe – should summarize and reference the work done, not duplicate it.

. IMO = International Maritime Organization

The standard will be independent of changes in technology – methods and techniques => . We can chose whatever approach we want as long as we reach the defined goals. . We can start using new methods as soon as - they become available - we have done the necessary testing and evaluation . Can not just do tick box of practices

Against: . More complex for the organization and accessor Can be supported by tailor of prescriptive standards

High level objective for each “process”: 7 Software architectural design 7.1 Objectives The first objective of this sub-phase is to develop a software architectural design that realizes the software safety requirements. The second objective of this sub-phase is to verify the software architectural design.

But none of the requirements are motivated: 7.4.4 The software architectural design shall be developed down to the level where all software units are identified.

Process reference model (Purpose, outcomes)

Process assessment model (BPs, WPs)

Management

Capability A-SPICE ASIL ISO 26262

Technical

Diciplines

. The SS 7740 development was performed by the Swedish working group “SIS/TK 240 AG16 Functional Safety in Electronic Systems”. . The first draft was developed within the research program DFEA2020 (Dependable and Flexible Electrical Architecture 2020) which was founded by the FFI program where a part of the research result was handed over to AG 16 in 2011. . The first revision of SS 7740:2012 was released in 2012 . The second revision was planned to be release in the end of 2014 – Not done

. Cybersecurity Standard – SAE J3061: Cybersecurity Guidebook for Cyber- Physical Vehicle Systems

. Merging: Why have several partly overlapping standards? We can only have one development process for a project. . Goal based or prescriptive: Goal based gives more freedom, but put higher demands on the competence. In any case the goals have to be broken down into a process for the development project . Safety case or process compliance: Similar to goal based, the safety case should be “automatic” from the process? . Safety levels: Must be possible to harmonize? . Staged or continuous: I liked the original staged CMM model, the continuous model seems a bit strange for the higher levels. It is the whole process that is measured and improved, not small parts. . Next step: Security: Yet another additional complementary and overlapping standard

In Search of Excellence - Tom Peters

[email protected] +46 706 800 533