Codeofchina.com is in charge of this English translation. In case of any doubt about the English translation, the Chinese original shall be considered authoritative.
GB/T 34590 consists of the following parts under the general title Road Vehicles - Functional Safety:
——Part 1: Vocabulary;
——Part 2: Management of Functional Safety;
——Part 3: Concept Phase;
——Part 4: Product Development at the System Level;
——Part 5: Product Development at the Hardware Level;
——Part 6: Product Development at the Software Level;
——Part 7: Production and Operation;
——Part 8: Supporting Processes;
——Part 9: Automotive Safety Integrity Level (ASIL)-oriented and Safety-oriented Analyses;
——Part 10: Guideline.
This part is Part 1 of GB/T 34590.
This part is developed in accordance with the rules given in GB/T 1.1-2009.
This part has been redrafted and modified in relation to ISO 26262-1: 2011 Road Vehicles - Functional Safety - Part 1: Vocabulary.
There are technical deviations between this part and ISO 26262-1:2011. The technical deviations, together with their justifications, are as follows:
——the application scope of this part is modified from "ISO 26262 is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars with a maximum gross vehicle mass up to 3 500kg" to "This standard is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars.";
——for architecture (2.3), the functions in original text are modified to requirements, since the term "allocation" refers to allocating requirements to architecture elements other than functions;
——for element (2.32), the definition in original text is modified, defining the scope of elements;
——for hardware part (2.55), the definition in original text is modified and example is added;
——for initial ASIL (2.66), the definition in original text is modified, and ASIL is resulted from hazard analysis and risk assessment;
——for item (2.69), the definition in original text is modified to complete it;
——for multiple-point failure (2.76), the note in original text, which results in over definition and duplicate definition, is deleted;
——for passenger car (2.86), the definition in original text is modified to be consistent with that in GB 7258-2012 Safety Specifications for Power-driven Vehicles Operating on Roads;
——for safety measure (2.110), Note 1 in original text is modified to example;
——for semi-formal notation (2.117), the example in original text is modified, SADT is short for Structured Analysis and Design Techniques instead of System Analysis and Design Techniques;
——special-purpose vehicle (2.126), the note in original text is deleted;
——for verification review (2.138), Note 2 in original text is modified to define its purpose.
The following editorial changes present in this part:
——the introduction and its expression as well as Figure 1 of international standard are modified.
This part was proposed by and is under the jurisdiction of National Technical Committee on Automobiles of Standardization Administration of China (SAC/TC 114).
Introduction
ISO 26262 is prepared based on IEC 61508 to comply with needs specific to the application sector of electrical and/or electronic (E/E) systems within road vehicles.
GB/T 34590 is the adaptation of ISO 26262 and applies to all activities during the safety lifecycle of safety-related systems comprised of electrical, electronic and software components.
Safety is one of the key issues of future automobile development. New functionalities not only in areas such as driver assistance, propulsion, in vehicle dynamics control and active and passive safety systems increasingly touch the domain of system safety engineering. Development and integration of these functionalities will strengthen the need for safe system development processes and the need to provide evidence that all reasonable system safety objectives are satisfied.
With the trend of increasing technological complexity, software content and mechatronic implementation, there are increasing risks from systematic failures and random hardware failures. GB/T 34590 includes guidance to avoid these risks by providing appropriate requirements and processes.
System safety is achieved through a number of safety measures, which are implemented in a variety of technologies (e.g. mechanical, hydraulic, pneumatic, electrical, electronic, programmable electronic) and applied at the various levels of the development process. Although GB/T 34590 is concerned with functional safety of E/E systems, it provides a framework within which safety-related systems based on other technologies may be considered. GB/T 34590:
a) provides an automotive safety lifecycle (management, development, production, operation, service, decommissioning) and supports tailoring the necessary activities during these lifecycle phases;
b) provides an automotive-specific risk-based approach to determine integrity levels [Automotive Safety Integrity Levels (ASIL)];
c) uses ASILs to specify applicable requirements of GB/T 34590 so as to avoid unreasonable residual risk;
d) provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety being achieved;
e) provides requirements for relations with suppliers.
Functional safety is influenced by the development process (including such activities as requirements specification, design, implementation, integration, verification, validation and configuration), the production and service processes and by the management processes.
Safety issues are intertwined with common function-oriented and quality-oriented development activities and work products. GB/T 34590 addresses the safety-related aspects of development activities and work products.
Figure 1 shows the overall structure of GB/T 34590. GB/T 34590 is based upon a V-model as a reference process model for the different phases of product development. Within the figure:
——the shaded “V”s represent the interconnection between GB/T 34590.3-2017, GB/T 34590.4-2017, GB/T 34590.5-2017, GB/T 34590.6-2017 and GB/T 34590.7-2017;
——the specific clauses are indicated in the following manner: “m-n”, where “m” represents the number of the particular part and “n” indicates the number of the clause within that part.
Example: “2-6” represents Chapter 6 of GB/T 34590.2-2017.
Figure 1 Overview of GB/T 34590-2017
Road Vehicles - Functional Safety -
Part 1: Vocabulary
1 Scope
This part of GB/T 34590 specifies the terms, definitions and abbreviated terms for application in all parts of GB/T 34590.
This standard is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars.
This standard does not address unique E/E systems in special purpose vehicles such as vehicles designed for drivers with disabilities.
Systems and their components released for production, or systems and their components already under development prior to the publication date of this standard, are exempted from the scope. For further development or alterations based on systems and their components released for production prior to the publication of this standard, only the modifications will be developed in accordance with this standard.
This standard addresses possible hazards caused by malfunctioning behaviour of E/E safety-related systems, including interaction of these systems. It does not address hazards related to electric shock, fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion, release of energy and similar hazards, unless directly caused by malfunctioning behaviour of E/E safety-related systems.
This standard does not address the nominal performance of E/E systems, even if dedicated functional performance standards exist for these systems (e.g. active and passive safety systems, brake systems, Adaptive Cruise Control)
2 Terms and Definitions
2.1
allocation
assignment of a requirement to an architectural element (2.32)
Note: intent is not to divide an atomic requirement into multiple requirements. Tracing of an atomic system (2.129) level requirement to multiple lower level atomic requirements is allowed.
2.2
anomaly
condition that deviates from expectations, based, for example, on requirements, specifications, design documents, user documents, standards, or on experience
Note: anomalies may be discovered, among other times, during the review (2.98), testing (2.134), analysis, compilation, or use of components (2.15) or applicable documentation.
2.3
architecture
representation of the structure of the item (2.69) or functions or systems (2.129) or elements (2.32) that allows identification of building blocks, their boundaries and interfaces, and includes the allocation (2.1) of functions to hardware and software elements
2.4
assessment
examination of a characteristic of an item (2.69) or element (2.32)
Note: a level of independence (2.61) of the party or parties performing the assessment is associated with each assessment.
2.5
audit
examination of an implemented process
2.6
automotive safety integrity level; ASIL
one of four levels to specify the item's (2.69) or element's (2.32) necessary requirements of GB/T 34590 and safety measures (2.110) to apply for avoiding an unreasonable residual risk (2.97), with D representing the most stringent and A the least stringent level
2.7
ASIL decomposition
apportioning of safety requirements redundantly to sufficiently independent elements (2.32), with the objective of reducing the ASIL (2.6) of the redundant safety requirements that are allocated to the corresponding elements
2.8
availability
capability of a product to be in a state to execute the function required under given conditions, at a certain time or in a given period, supposing the required external resources are available
2.9
baseline
version of a set of one or more work products, items (2.69) or elements (2.32) that is under configuration management and used as a basis for further development through the change management process
Note: see GB/T 34590.8-2011, Chapter 8.
2.10
branch coverage
percentage of branches of the control flow that have been executed
Note 1: 100% branch coverage implies 100% statement coverage (2.127).
Note 2: an if-statement always has two branches - condition true and condition false - independent of the existence of an else-clause.
2.11
calibration data
data that will be applied after the software build in the development process
Example: parameters (e.g. value for low idle speed, engine characteristic diagrams); vehicle specific parameters (adaptation values) (e.g. limit stop for throttle valve); variant coding (e.g. country code, left-hand/right-hand steering).
Note: calibration data cannot contain executable or interpretable code.
2.12
candidate
item (2.69) or element (2.32) whose definition and conditions of use are identical to, or have a very high degree of commonality with, an item or element that is already released and in operation
Note: this definition applies where candidate is used in the context of a proven in use argument (2.90).
2.13
cascading failure
failure (2.39) of an element (2.32) of an item (2.69) causing another element or elements of the same item to fail
Note: cascading failures are dependent failures (2.22) that are not common cause failures (2.14). See Figure 2, Failure A.
Figure 2 Cascading Failure
2.14
common cause failure; CCF
failure (2.39) of two or more elements (2.32) of an item (2.69) resulting from a single specific event or root cause
Note: common cause failures are dependent failures (2.22) that are not cascading failures (2.13). See Figure 3.
Figure 3 Common Cause Failure
2.15
component
non-system (2.129) level element (2.32) that is logically and technically separable and is comprised of more than one hardware part (2.55) or of one or more software units (2.125)
Note: a component is a part of a system.
2.16
configuration data
data that is assigned during software build and that controls the software build process
Example: pre-processor instructions; software build scripts (e.g. XML configuration files).
Note 1: configuration data may not contain executable or interpretable code.
Note: 2: configuration data controls the software build. Only code, or data selected by configuration data may be included in the executable code.
2.17
confirmation measure
confirmation review (2.18), audit (2.5) or assessment (2.4) concerning functional safety (2.51)
2.18
confirmation review
confirmation that a work product meets the requirements of GB/T 34590 with the required level of independence (2.61) of the reviewer
Note 1: a complete list of confirmation reviews is given in GB/T 34590.2-2017.
Note 2: the goal of confirmation reviews is to ensure compliance with GB/T 34590.
2.19
controllability
ability to avoid a specified harm (2.56) or damage through the timely reactions of the persons involved, possibly with support from external measures (2.38)
Note 1: persons involved may include the driver, passengers or persons in the vicinity of the vehicle's exterior.
Note 2: the parameter C in hazard analysis and risk assessment (2.58) represents the potential for controllability.
2.20
dedicated measure
measure to ensure the failure rate (2.41) claimed in the evaluation of the probability of violation of safety goals (2.108)
Example: design feature [such as hardware part (2.55) over-design (e.g. electrical or thermal stress rating) or physical separation (e.g. spacing of contacts on a printed circuit board)]; special sample test of incoming material to reduce the risk (2.99) of occurrence of failure modes (2.40) which contribute to the violation of safety goals; burn-in test; dedicated control plan.
2.21
degradation
strategy for providing safety (2.103) by design after the occurrence of failures (2.39)
Note: degradation may include reduced functionality, reduced performance, or both reduced functionality and performance.
Foreword i
Introduction iii
1 Scope
2 Terms and Definitions
3 Abbreviated Terms
Bibliography
Index
