Factsheet: Brief Overview of Main Changes

Be ready for Automotive SPICE® v3.0 (HIS Scope)Changes and improvements in version 3.0 of Automotive SPICE® concern the structure, process names, concepts and definitions. Also the measurement framework was adapted to the changes in ISO 33020.

In the following we describe the major changes:

Structure: Changed Structure of Engineering Processes

Further they are grouped by the type of activity they address and organized in a way that each process on the left side of the V-model is corresponding to exactly one process on the right side.

SYS.2 System Requirements Analysis System Qualification Testing SYS.5

SYS.3 System Architectural Design System Integration and Integration Test SYS.4

SWE.1 Software Requirements Analysis Software Qualification Test SWE.6

SWE.2 Software Architectural Design Software Integration and Integration Test SWE.5

SWE.3 Software Detailed Design and Unit Construction

Software Unit Verification SWE.4

Concept: Plug-In Concept for other Engineering DomainsManagement processes and supporting processes are designed in a way that they can be applied to both the system level (above the line) and the domain level (below the line).

oben

4Automotive SPICE® at a glanceAutomotive SPICE® is a standard used as a framework for improving and evaluating processes. It applies to the development of mechatronic systems focusing on the software and system parts of the product. However, as of version 3.0 of the standard it is possible to add further engineering disciplines (e.g. hardware engineering, mechanical engineering etc.) and the corresponding domain-specific processes to the scope of Automotive SPICE®, depending on the product to be developed.

SYS.4

SYS.5

SWE.1

SWE.4

SWE.2 SWE.5

SWE.3

SWE.6

System EngineeringSoftware EngineeringHardware Engineering*Mechanical Engineering*

* not developed by VDA; Not included in Automotive SPICE® v3.0

ACQ

.4

MA

N.3

Syst

em le

vel

Dom

ain

leve

l

SUP.

1

SUP.

8

SUP.

9

SUP.

10

HWE.1-n

SYSSWEHWEMEE

MEE.1-n

SYS.1

SYS.2

SYS.3

kuma-pocket_guide-v02-05.indd 4 30.09.15 10:19

System level: The top-level of the V comprises of all System Engineering Processes (SYS).

Domain level: In addition to Software Engineering Processes (SWE), other domains can be added to the assessment scope, e.g. Hardware Engineering (HWE) and Mechanical Engineering (MEE) processes which are not part of Automotive SPICE®.

Engineering Processes (ENG) are divided into two new process categories: • System Engineering (SYS)• Software Engineering (SWE)

Concept: Traceability and ConsistencyTraceability and Consistency are divided in two base practices in the v3.0 of Automotive SPICE®.

• Traceability addresses the existence of references or links between work products. • Consistency: The traceability is used to review whether the downstream process is consistent with the

upstream process in terms of full and correct coverage. • Bidirectional traceability is by now explicitly defined between:

test cases/specifications and test results.change requests and work products affected by change requests.

Concept: Evaluation, Verification Criteria and Ensuring Compliance • Evaluation of alternative solutions is required for system and software architectures. The

evaluation has to be done according to defined criteria. Such evaluation criteria may include quality characteristics like modularity, reliability, security, and usability, or results of make-or-buy or reuse analysis. The evaluation result including a rationale for the architecture/design decision has to be recorded.

• Verification Criteria are used as input for the development of the test cases or other verification measures that ensures compliance with the requirements. Verification criteria are only used in the context of System Requirements Analysis (SYS.2) and Software Requirements Analysis (SWE.1) processes. Verification aspects which cannot be covered by testing are covered by the Verification Process (SUP.2).

Criteria for Unit Verification ensure compliance of the source code with the software detailed design and the non-functional requirements. Unit test criteria shall be defined in a unit test specification.

• Compliance with an architectural design (SWE.5.BP3) means that the specified integration tests are capable of proving that interfaces and relevant interactions like e.g. dynamic behavior between: the software units, the software items and the system items fulfill the specification given by the architectural design.

Concept: Communicate Agreed, Summarize and Communicate ResultsBase practices Communicate Agreed (left side of the V-model) and Summarize and Communicate Results (right side of the V-Model) are clearly defined:

• Work products on the right side are made available and communicated to all relevant stakeholders. • Information resulting from test executions is made available to all relevant parties.

AUTOMOTIVE SPICE® v3.0 HIS-SCOPE*

Syst

em le

vel

Dom

ain

leve

l

BP1 Define the scope of work.BP2 Define project life cycle.BP3 Evaluate feasibility of the project.BP4 Define, monitor and adjust project activities.BP5 Determine, monitor und adjust project estimates and resources.

BP1 Develop a project quality assurance strategy.BP2 Assure quality of work products.BP3 Assure quality of process activities.BP4 Summarize and communicate quality assurance activities and results.BP5 Ensure resolution of non-conformances.BP6 Implement an escalation mechanism.

BP1 Develop a configuration management strategy.BP2 Identify configuration items.BP3 Establish a configuration management system.BP4 Establish branch management strategy.BP5 Control modifications and releases.BP6 Establish baselines.BP7 Report configuration status.BP8 Verify the information about configured items.BP9 Manage the storage of configuration items and baselines.

BP1 Develop a problem resolution management strategy.BP2 Identify and record the problem.BP3 Record the status of problems.BP4 Diagnose the cause and determine the impact of the problem.BP5 Authorize urgent resolution action.BP6 Raise alert notifications.BP7 Initiate problem resolution.BP8 Track problems to closure.BP9 Analyze problem trends.

BP1 Develop a change request management strategy.BP2 Identify and record the change requests.BP3 Record the status of change requests.BP4 Analyze and assess change requests.BP5 Approve change requests before implementation.BP6 Review the implementation of change requests.BP7 Track change requests to closure.BP8 Establish bidirectional traceability.

BP6 Ensure required skills, knowledge, and experience.BP7 Identify, monitor and adjust project interfaces and agreed commitments.BP8 Define, monitor and adjust project schedule.BP9 Ensure consistency.BP10 Review and report progress of the project.

Management Process Group

Supporting Process Group

System Engineering Process Group

Software Engineering Process Group

Aquisition Process GroupMAN.3 – Project Management

Generic practices

PA 1.1 Process performance process attribute The process performance attribute is a measure of the extent to which the process purpose is achieved.GP 1.1.1 Achieve the process outcomes

LEVEL 1 – Performed process

PA 2.1 Performance management process attribute The performance management process attribute is a measure of the extent to which the performance of the process is managed.GP 2.1.1 Identify the objectives for the performance of the process.GP 2.1.2 Plan the performance of the process to fulfill the identified objectives.GP 2.1.3 Monitor the performance of the process against the plans.GP 2.1.4 Adjust the performance of the process.GP 2.1.5 Define responsibilities and authorities for performing the process.GP 2.1.6 Identify, prepare, and make available resources to perform the process according to plan.GP 2.1.7 Manage the interfaces between involved parties.

PA 2.2 Work product management process attribute The work product management process attribute is a measure of the extent to which the work products produced by the process are appropriately managed.GP 2.2.1 Define the requirements for the work products.GP 2.2.2 Define the requirements for documentation and control of the work products.GP 2.2.3 Identify, document and control the work products.GP 2.2.4 Review and adjust work products to meet the defined requirements.

LEVEL 2 – Managed process

PA 3.1 Process definition process attribute The process definition process attribute is a measure of the extent to which a standard process is maintained to support the deployment of the defined process.GP 3.1.1 Define and maintain the standard process that will support the deployment of the defined process.GP 3.1.2 Determine the sequence and interaction between processes so that they work as an integrated system of processes.GP 3.1.3 Identify the roles and competencies, responsibilities, and authorities for performing the standard process.GP 3.1.4 Identify the required infrastructure and work environment for performing the standard processGP 3.1.5 Determine suitable methods and measures to monitor the effectiveness and suitability of the standard process.

PA 3.2 Process deployment attribute The process deployment process attribute is a measure of the extent to which the standard process is deployed as a defined process to achieve its process outcomes.GP 3.2.1 Deploy a defined process that satisfies the context specific requirements of the use of the standard process.GP 3.2.2 Assign and communicate roles, responsibilities and authorities for performing the defined process.GP 3.2.3 Ensure necessary competencies for performing the defined process.GP 3.2.4 Provide resources and information to support the performance of the defined process.GP 3.2.5 Provide adequate process infrastructure to support the performance of the defined process.GP 3.2.6 Collect and analyze data about performance of the process to demonstrate its suitability and effectiveness.

LEVEL 3 – Established process

LEVEL 5 – Innovating process

LEVEL 4 – Predictable process

SUP.1 – Quality Assurance SUP.8 – Configuration Management SUP.9 – Problem Resolution Management SUP.10 – Change Request Management

BP1 Agree on and maintain joint processes, joint interfaces, and information to be exchanged.BP2 Exchange all agreed information.

BP3 Review technical development with the supplier.BP4 Review progress of the supplier.BP5 Act to correct deviations.

ACQ.4 – Supplier Monitoring

SYS.2 – System Requirements Analysis

BP1 Specify system requirements.BP2 Structure system requirements.BP3 Analyze system requirements.BP4 Analyze the impact on the operating environment.BP5 Develop verification criteria.BP6 Establish bidirectional traceability.BP7 Ensure consistency.BP8 Communicate agreed system requirements.

SWE.1 – Software Requirements Analysis

BP1 Specify software requirements.BP2 Structure software requirements.BP3 Analyze software requirements.BP4 Analyze the impact on the operating environment.BP5 Develop verification criteria.BP6 Establish bidirectional traceability.BP7 Ensure consistency.BP8 Communicate agreed software requirements.

SYS.5 – System Qualification Test

BP1 Develop system qualification test strategy including regression test strategy.BP2 Develop specification for system qualification test.BP3 Select test cases.BP4 Test integrated system.BP5 Establish bidirectional traceability.BP6 Ensure consistency.BP7 Summarize and communicate results.

SYS.3 – System Architectural Design

BP1 Develop system architectural design.BP2 Allocate System Requirements.BP3 Define interfaces of system elements.BP4 Describe dynamic behavior.BP5 Evaluate alternative system architectures.BP6 Establish bidirectional traceability.BP7 Ensure consistency.BP8 Communicate agreed system architectural design.

SYS.4 – System Integration and Integration Test

BP1 Develop system integration strategy.BP2 Develop system integration test strategy including regression test strategy.BP3 Develop specification for system integration test.BP4 Integrate system items.BP5 Select test cases.BP6 Perform system integration test.BP7 Establish bidirectional traceability.BP8 Ensure consistency.BP9 Summarize and communicate results.

HardwareEngineering

MechanicalEngineering

SWE.6 – Software Qualification Test

BP1 Develop software qualification test strategy including regression test strategy.BP2 Develop specification for software qualification test.BP3 Select test cases.BP4 Test integrated software.BP5 Establish bidirectional traceability.BP6 Ensure consistency.BP7 Summarize and communicate results.

SWE.5 – Software Integration and Integration Test

BP1 Develop software integration strategy.BP2 Develop software integration test strategy including regression test strategy.BP3 Develop specification for software integration test.BP4 Integrate software units and software items.BP5 Select test cases.BP6 Perform software integration test.BP7 Establish bidirectional traceability.BP8 Ensure consistency.BP9 Summarize and communicate results.

SWE.4 – Software Unit Verification

BP1 Develop software unit verification strategy including regression strategy.BP2 Develop criteria for unit verification.BP3 Perform static verification of software units.BP4 Test software units.BP5 Establish bidirectional traceability.BP6 Ensure consistency.BP7 Summarize and communicate results.

Automotive SPICE® as a basis for functional safety

SYS.1 Requirements Elicitation Item definition (detailed level)

SYS.2 System Requirements Analysis Functional safety concept

Specification of the technical safety requirements

Specification and management of safety requirements

SYS.3 System Architectural Design System design

SWE.1 Software Requirements Analysis Specification of software safety requirements

SWE.2 Software Architectural Design Software architectural design

SWE.3 Software Detailed Design and Unit Construction Software unit design & implementation

SWE.4 Software Unit Verification Software unit testing

SWE.5 Software Integration and Integration Test Software integration & testing

SWE.6 Software Qualification Test Verification of software safety requirements

SYS.4 System Integration and Integration Test Item integration and testing

SYS.5 System Qualification Testing –

ACQ.4 Supplier Monitoring Interfaces within distributed developments

SPL.2 Product Release Release for production

strong support medium support weak support

MAN.3 Project Management Safety management during the concept phase and

the product development

Item definition (top level)

Initiation of the safety lifecycle

Initiation of product development at the system level

Initiation of product development at the hardware level

Initiation of product development at the software level

MAN.5 Risk Management –

SUP.1 Quality Assurance Safety management during the concept phase

and the product development

Functional safety assessment

SUP.2 Verification Verification

SUP.4 Joint Review –

SUP.7 Documentation Documentation

SUP.8 Configuration Management Configuration management

SUP.9 Problem Resolution Management –

SUP.10 Change Management Change management

REU.2 Reuse Program Management –

ISO

262

62

Aut

omot

ive

SPIC

E® e

xten

ded

HIS

-Sco

pe

Bidirectional traceability and consistency

SYS.2 BP6

SYS.3 BP6

SWE.1 BP6

SWE.2 BP7

SWE.3 BP5

SWE.3 BP5SWE.3 BP6

SWE.3 BP5SWE.3 BP6

SWE.1 BP6SWE.1 BP7

SYS.3 BP7

SYS.3 BP7

SWE.1 BP7

SWE.2 BP8

SWE.3 BP6

Softwarerequirements

Software detailed design

Softwareunits

Static verification results

System qualification test results

System integrationtest results

Software qualification test results

Software integrationtest results

Unit testresults

Unit test specification

Software integration test specification

Software qualification test specification

System qualification test specification

System integration test specification

Systemarchitecture

Softwarearchitecture

Stakeholderrequirements System

requirementstest cases

test cases

test cases

test cases

SWE.4 BP5 SWE.4 BP6

SWE.5 BP7SWE.5 BP8

SWE.6 BP5SWE.6 BP6

SYS.4 BP7SYS.4 BP8

SYS.5 BP5SYS.5 BP6

SWE.4 BP5

SWE.4 BP5

SWE.5 BP7

SWE.6 BP5

SYS.4 BP7

SYS.5 BP5

To affected work products ABC.n BPn bidirectional traceabilityABC.n BPn consistencySUP.10 BP8

Changerequests

Process attributes and capability Levels

LEVEL PROCESS ATTRIBUTES PERFORMANCE DESCRIPTION

5 Innovating PA 5.1 Process InnovationPA 5.2 Process Optimization

The previously described pre dictable process is now continually improved to respond to organizational change.

4 PA 4.1 Quantitative AnalysisPA 4.2 Quantitative Control

The previously described established process now operates predictively within defined limits to achieve its process outcomes. Quantitative management needs are identified, measurement data are collected and analyzed to identify assignable causes of variation. Corrective action is taken to address assignable causes of variation.

Predictable

3 PA 3.1 Process DefinitionPA 3.2 Process Deployment

The previously described managed process is now implemented using a defined process that is capable of achieving its process outcomes.

Established

2

1

0

PA 2.1 Performance ManagementPa 2.2 Work Product Management

PA 1.1 Process Performance

The previously described performed process is now implemented in a managed fashion (planned, monitored and adjusted) and its work products are appropriately established, controlled and maintained.

The implemented process achieves its process purpose.

The process is not implemented, or fails to achieve its process purpose

Managed

Performed

Incomplete

SWE.3 – Software Detailed Design and Unit Construction

BP1 Develop software detailed design.BP2 Define interfaces of software units.BP3 Describe dynamic behavior.BP4 Evaluate software detailed design.BP5 Establish bidirectional traceability.BP6 Ensure consistency.BP7 Communicate agreed software detailed design.BP8 Develop software units.

SWE.2 – Software Architectural Design

BP1 Develop software architectural design.BP2 Allocate software requirements.BP3 Define interfaces of software elements.BP4 Describe dynamic behavior.BP5 Define resource consumption objectives.BP6 Evaluate alternative software architectures.BP7 Establish bidirectional traceability.BP8 Ensure consistency.BP9 Communicate agreed software architectural design.

training partnerAUTOMOTIVE SPICE®

KUGlER MAAG CIE GmbH leibnizstraße 1170806 KornwestheimGermany+49 7154 1796 100

information@kuglermaag.com www.kuglermaag.com

KUGlER MAAG CIE North America Inc. Columbia Center No 387, Suite 1447101 West Big Beaver, Troy, MI 48084 USA+1 248 687 1210

usa@kuglermaag.com www.kuglermaag.com

ISBN-13 978-3-945547-17-5

* under discussion (as of October 2015)

item

item

item

item

itemunit

element

element

element

componentelement

componentelement

unit

By implementing Automotive SPICE®, a large part of the ISO 26262 requirements can also be fulfilled. The tables below display the Automotive SPICE® support for an ISO 26262 implementation.

Defined: Element, Item, Component, Unit • Architecture consists of architectural elements (or further decomposed

architectural sub-elements) • Components are the lowest level elements of software architecture for which

the detailed design is defined. • A software component consists of one or more software units. • Items on the right side of the V-model correspond to one or more elements

on the left side (e.g. object file, library, executable)

Added: ObjectivityObjectivity has been added to independence (SUP.1) referring to an independent financial and/or organizational structure.

RevisedProcess outcomes, base practices, and output work products regarding consistency, comprehensibility, state-of-the-art, and usability.

Need more information about Automotive SPICE® v3.0?

• With our presentation Automotive SPICE® 3.0 – What is new and what has changed? you will know about the changes been implemented in the new version 3.0 of Automotive SPICE®. www.kuglermaag.com/aspice3

• Update training courses and introductions www.kuglermaag.com/aspice-intro

• The original Automotive SPICE® Pocket Guide and an overview poster is available here: www.kuglermaag.com/shop

Elements

Components

Units

Items

SYS.1

SYS.2

SYS.3 SYS.4

SYS.5