vector india conference 2019€¦ · it provides asil-dependent requirements for the whole...
Post on 19-Oct-2020
0 Views
Preview:
TRANSCRIPT
-
V0.1 | 2019-05-10
Conforming to Safety Standard
Vector India Conference 2019
https://www.vector.com/in/en-in/events/vh-vector-india/2019/vh-vtts19/
-
2
▪ Introduction to ISO 26262
▪ Parts of ISO 26262
▪ ASIL Levels
▪ Part 4 : Product Development – System Level
▪ Part 6 : Product Development – Software Level
▪ Fitting software tools into ISO 26262 process
▪ Demo
▪ Q&A
Agenda
-
3
Introduction of ISO26262
-
4
Present cars and Electronics:
Background
Introduction of ISO 26262
• Increasing Functional complexity and Software based cars
• Increasing risk from systematic faults and random hardware Failures
-
5
How safety is important ?
Introduction of ISO 26262
▪ Safety is most important of course
▪ Due to technology, environment, cost etc 100% safety is not possible
▪ There is always remains a risk about danger!
▪ So we have to think about acceptable Risk
-
6
What is Functional Safety?
Introduction of ISO 26262
Assessment of safety measures ( Safety Functions) and its numerous evaluation is the basis of Functional Safety
-
7
What is ISO26262?
Introduction of ISO 26262
▪ ISO 26262 is IEC 61508 adapted to the needs of the Automotive Industry
▪ Adopts a similar approach to software testing and code coverage requirements to other, longer-lived standards (such as DO-178B)
-
8
What is ISO26262?
Introduction of ISO 26262
▪ It applies to safety-related road vehicle E/E systems, and addresses hazards due to malfunctions, excluding nominal performances of active and passive safety systems.
▪ Risk is determined based on customer risk by identifying the so-called Automotive Safety Integrity Level (ASIL) associated with each undesired effects.
▪ It provides ASIL-dependent requirements for the whole lifecycle of the E/E system (including Hardware and Software components)
- Series production passenger cars
Maximum gross weight up to 3500 kg
- Does not apply to E/E systems in special purpose vehicles
e.g., vehicles designed for drivers with disabilities
-
9
Origins of ISO26262 (Automotive IEC 61508)
Introduction of ISO 26262
IEC 61508
Initial work of individual companies
Initiative within national
standardization bodies
First draft of requirement specification
ISO
TC22
SC3
WG16
MISRA
BNA
FAKRAOEM suppliers
Technical services
20029.20052003 1.2004
11.2005
-
10
ISO 26262 Parts
-
11
ISO 26262 Parts
▪ Part 1 : Vocabulary
▪ Part 2 : Management of Functional Safety
▪ Part 3 : Concept phase
▪ Part 4 : Product Development: System Level
▪ Part 5 : Product Development: Hardware Level
▪ Part 6 : Product Development: Software Level
▪ Part 7 : Production and Operation
▪ Part 8 : Supporting Processes
▪ Part 9 : ASIL-oriented and Safety-oriented Analyses
▪ Part 10 : Guidelines on ISO 26262
▪ Part 11 : Guidelines on application of ISO 26262 to semiconductors
▪ Part 12 : Adaption of ISO26262 for motorcycles
-
12
ISO26262 Process
ISO26262 Parts
-
13
ASIL
ISO26262 Parts
▪ ISO/DIS 26262 replaces SILs with ASILs (Automotive Safety Integrity Levels)
▪ ASILs designed to specify the measures required to avoid unreasonable residual risk
▪ ASIL levels A-D, with D being the most demanding
▪ Risk of each hazardous event is evaluated on the basis of:
– Frequency of the situation (or “exposure”)
– Impact of possible damage (or “severity”)
– Controllability
-
14
ASIL Ranking Table
ASIL
-
15
Part 4 : Product Development – System Level
-
16
Overview
Part 4 : Product Development – System Level
▪ Identify and plan the functional safety activities for each sub-phase of system development
- Includes supporting processes activities
- Includes methods to be used Tailoring of the
lifecycle
▪ Applies to both systems and subsystems
Safety plan
-
17
Example Product Development at the System Level
Part 4 : Product Development – System Level
After the initiation of the product
development of the technical safety
requirements, the system design is
performed
Depending on the complexity of the architecture, the
requirements can be derived iteratively, and
integrated after the Hardware &Software
implementation.
Integrate software & hardware, validation is performed to comply
with each safety requirement in
accordance with its specification and ASIL
classification
-
18
4.6 - Specification of the Technical Safety Requirements
Part 4 : Product Development – System Level
▪ Develop the technical safety requirements
▪ Refinement of the functional safety requirements
considering the preliminary architectural assumptions
▪ Verify the technical safety requirements comply with the
functional safety requirements
Describe how to implement the Functional Safety Concept
-
19
4.6 - Specification of the Technical Safety Requirements
Part 4 : Product Development – System Level
Requirements Engineering of this nature requires additional initial effort but benefits will be obtained whenever changes are required.
Cost of a project WITHOUTRequirements Engineering
Cost of a project WITHRequirements Engineering
Deliver
Deliver (less delay)Project Start
-
20
4.7 - System Design
Part 4 : Product Development – System Level
▪ To develop the system design and the technical safety concept that comply with the functional requirements and the technical safety requirements specification.
▪ Verify the System design and technical safety concept comply with Technical safety requirements specification.
▪ Need to have bidirectional traceability between System design and Technical safety requirements specification.
-
21
4.8 - Item integration and testing
Part 4 : Product Development – System Level
▪ Integrate the elements of an item
- If applicable, systems or elements of other
technologies and external measures or systems
- Test the integrated item for compliance with each
safety requirement
▪ Verify that the system design is correctly implemented by the entire item
-
22
4.8 - Item integration and testing
Part 4 : Product Development – System Level
Each functional and technical safety requirements shall be tested at least once in the complete integration phase.
-
23
4.8 - Item integration and testing
Part 4 : Product Development – System Level
-
24
4.9 - Safety Validation
Part 4 : Product Development – System Level
▪ To provide evidence of due compliance with the functional safety goals and that the safety concepts are appropriate for the functional safety of the item.
▪ To provide evidence that the safety goals are correct, complete and fully achieved at vehicle level.
▪ The validation plan shall include:
1. The configuration of the item
2. The specification of test cases and acceptance criteria
3. The required environmental conditions
-
25
4.10 - Functional safety assessment
Part 4 : Product Development – System Level
▪ Assess the functional safety achieved by the item
▪ Initiated by the entity with responsibility for functional safety e.g., the vehicle manufacturer
-
26
4.11 – Release for Production
Part 4 : Product Development – System Level
▪ To specify the criteria for the release for production at the completion of the item development.
▪ The release for production confirms that the item complies with the requirements for functional safety at vehicle level.
▪ The documentation shall include
a) the name and signature of the person in charge of release
b) the version/s of the released item
c) the configuration of the released item
d) references to associated documents
e) the release date
-
27
Part 6 : Product Development – Software Level
-
28
Software Level
Part 6 : Product Development – Software Level
ISO 26262 (Part 6) refers more specifically to the development of software, particularly:
– Initiation of product development at the software level
– Derivation of software safety requirements from the system level
(following from part 4) and their subsequent verification
– Software architectural design
– Software unit design and implementation
– Software unit testing, and
– Software integration and testing
-
29
6.5 Initiation of Product Development at Software Level
Part 6 : Product Development – Software Level
To plan and initiate the functional safety activities for the sub phases of the software development
Evaluate work products to ensure they meet previously established requirements
Ensure that the item developed, or parts of it,
comply with the requirements
-
30
6.5 Modeling and Coding Guidelines
Part 6 : Product Development – Software Level
To support the correctness of the design and implementation, the design and coding guidelines for the modeling, or programming languages, shall address following topics:
-
31
6.6 Specification of Software Safety Requirements
Part 6 : Product Development – Software Level
▪ Specify the SW safety requirements from the technical
safety requirements (including their ASIL) and the
system design specification
▪ Detail the hardware-software interface requirements
▪ Verify that the SW safety requirements are consistent
with the technical safety requirements and the system
design specification
Compliant with technical safety requirements and system design, and consistent with relevant hardware safety requirements
-
32
6.6 Verification of Software Safety Requirements
Part 6 : Product Development – Software Level
A verification activity shall be performed to demonstrate that the software safety requirements are traceable with he technical safety requirements, the system design and consistent with the relevant parts of the hardware safety requirements achieving complete traceability.
-
33
6.7 Software Design (1\2)
Part 6 : Product Development – Software Level
▪ To develop a software architectural design that realizes the software safety
requirements and verify the software architectural design achieving bi-directional
traceability.
▪ The software architectural design represents all software components and their
interactions with one another in a hierarchical structure.
-
34
6.7 Software Design (2\2)
Part 6 : Product Development – Software Level
The software architectural design shall exhibit
– Modularity
– Encapsulation
– Minimum complexity
-
35
6.8 Software Unit design & implementation
Part 6 : Product Development – Software Level
▪ To specify the software units in accordance with the SW architectural design and the associated SW safety requirements, to implement the software units as specified and to verify the design of the SW units and implementation.
▪ The specification of the software units shall describe the functional behavior and the internal design.
▪ The design and implementation of software unit shall achieve
– Avoidance of unnecessary complexity
– Testability
– Maintainability
-
36
6.8 Verification of software unit design and implementation
Part 6 : Product Development – Software Level
The software unit design and implementation shall be verified to demonstrate
▪ Compliance with the hardware-software interface
▪ Completeness regarding the software safety requirements and the software architecture through traceability
▪ Compliance of the source code with its specification
▪ Compliance of the source code with the coding guidelines
▪ Compatibility of the software unit implementations with target hardware.
-
37
6.8 Verification of software unit design and implementation
Part 6 : Product Development – Software Level
-
38
6.9 Software Unit Testing
Part 6 : Product Development – Software Level
▪ Demonstrate that the software units satisfy their specification and do not contain undesired functionality.
▪ The following testing methods can be used for proving compliance with specification and Hardware Software interface, correct implementation, absence of unintended functionality, robustness, and sufficiency of the resources.
-
39
6.9 Test case specification and structural coverage metrics
Part 6 : Product Development – Software Level
To evaluate:
▪ The completeness of test cases
▪ To demonstrate that there is no unintended functionality
▪ The coverage of requirements at the software unit level shall be determined and
▪ The structural coverage shall be measured in accordance with the metrics listed.
-
40
6.10 SW integration & Testing
Part 6 : Product Development – Software Level
▪ To integrate the software components and demonstrate that the software architectural design is correctly realized by the embedded software.
▪ Integrated software tested against architectural design and interfaces between the software units and the software component.
▪ Software integration test shall demonstrate
– Compliance with the software architectural design
– Compliance with the specification of the hardware-software interface
– Correct implementation of the functionality
– Robustness
– Sufficiency of the resources to support the functionality.
-
41
6.11 Verification of SW safety requirements
Part 6 : Product Development – Software Level
▪ To demonstrate that the embedded software fulfils the software safety requirements and embedded software satisfies its requirements in the target environment.
▪ The results of the verification of the software safety requirements shall be evaluated in accordance with:
– Compliance with the expected results
– Coverage of the software safety requirements
– A pass or fail criteria
-
42
Fitting software tools into ISO 26262 process
-
43
VectorCAST Compliance with ISO 26262
Fitting software tools into ISO 26262 process
▪ ISO/DIS 26262 is a new standard for the Automotive sector
- But it is based on principles which have been long established elsewhere
▪ The concept of adopting Aerospace development principles sounds expensive.
But tools to handle these issues are:
• Designed to apply these principles cost effectively, and
• Sophisticated and proven
▪ Similarly, the VectorCAST have long been established to provide the support for IEC 61508 based principles
-
44
V Model Process
Fitting software tools into ISO 26262 process
-
45
Coding Standard Enforcement
Fitting software tools into ISO 26262 process
MISRA C/C++
-
46
Software Unit Testing
Fitting software tools into ISO 26262 process
-
47
Unit Test Case Execution
Fitting software tools into ISO 26262 process
-
48
Coverage Analysis
Fitting software tools into ISO 26262 process
ISO 26262-8:2018 Table 12: Structural coverage at the software architectural level
Methods VectorCAST Support ASIL
A B C D
1a Function coverage ✓ + + ++ ++
1b Call coverage ✓ + + ++ ++
ISO 26262-8:2018 Table 9: Structural coverage metrics at the software unit level
Methods VectorCAST Support ASIL
A B C D1a Statement coverage ✓ ++ ++ + +
1b Branch coverage ✓ + ++ ++ ++
1c MC/DC (Modified Condition/Decision Coverage) ✓ + + + ++
-
49
Coverage Analysis
Fitting software tools into ISO 26262 process
-
50
Traceability Matrix
Fitting software tools into ISO 26262 process
-
51
Demo
-
52
Conclusion
▪ IEC 26262 ensures the safety of the electrical / electronic / programmable electronic devices in Road vehicles.
▪ Using tools with a proven track record and pedigree to automate the software development process:
– Will help in producing safe product
– Provides confidence to the manufacturers
– Save time and money
-
53
Q&A
-
54
Author:
Yadav, Sunil
Vector India
top related