Road vehicles -- End-of-life activation of on-board pyrotechnic devices

ISO 26021-2:2008 defines the deployment process, the system architecture, CAN-based communication methods and system preconditions which have to be implemented to fulfil the use cases defined in ISO 26021‑1. Additionally, the relationship to and use with other existing standards are defined. It also describes the technical details of the on-board deployment method. The way in which the pyrotechnic devices contained in the vehicle function in conjunction with the PDT is the primary focus of the document. Under the provisions of the document, the design of the PDT or PCU can be implemented in accordance with specific functionality and hardware requirements. This part of ISO 26021 specifies the access to the PCU. This includes communication as well as the logic sequences which are involved during the activation process.

Véhicules routiers -- Activation de fin de vie des dispositifs pyrotechniques embarqués

General Information

Status
Published
Publication Date
09-Jul-2008
Current Stage
6060 - International Standard published
Start Date
23-Jun-2008
Completion Date
10-Jul-2008
Ref Project

Buy Standard

Standard
ISO 26021-2:2008 - Road vehicles -- End-of-life activation of on-board pyrotechnic devices
English language
49 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (sample)

INTERNATIONAL ISO
STANDARD 26021-2
First edition
2008-07-15
Road vehicles — End-of-life activation of
on-board pyrotechnic devices —
Part 2:
Communication requirements
Véhicules routiers — Activation de fin de vie des dispositifs
pyrotechniques embarqués —
Partie 2: Exigences de communication
Reference number
ISO 26021-2:2008(E)
ISO 2008
---------------------- Page: 1 ----------------------
ISO 26021-2:2008(E)
PDF disclaimer

This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but

shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In

downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat

accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.

Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation

parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In

the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

COPYRIGHT PROTECTED DOCUMENT
© ISO 2008

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,

electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or

ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2008 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 26021-2:2008(E)
Contents Page

Foreword............................................................................................................................................................ iv

Introduction ........................................................................................................................................................ v

1 Scope ..................................................................................................................................................... 1

2 Normative references ........................................................................................................................... 1

3 Terms and definitions........................................................................................................................... 2

4 Symbols and abbreviated terms ......................................................................................................... 2

5 Conventions .......................................................................................................................................... 3

6 Pyrotechnic device deployment via on-board diagnostic architecture .......................................... 3

6.1 Vehicle system description ................................................................................................................. 3

6.2 Example of in-vehicle hardware and software required ................................................................... 4

6.3 Additional communication line (optional).......................................................................................... 5

6.4 Requirements for the PDT ................................................................................................................... 5

7 Relationship to existing standards..................................................................................................... 6

7.1 General................................................................................................................................................... 6

7.2 Application layer................................................................................................................................... 6

7.3 Session layer......................................................................................................................................... 6

7.4 Application layer and diagnostic session management timing....................................................... 6

7.5 Network layer ........................................................................................................................................ 7

7.6 Data link layer........................................................................................................................................ 7

7.7 Data link layer........................................................................................................................................ 9

7.8 Physical layer........................................................................................................................................ 9

8 Deployment process............................................................................................................................. 9

8.1 General information.............................................................................................................................. 9

8.2 System preconditions .......................................................................................................................... 9

8.3 Initiation of the communication between PDT and PCU................................................................. 10

8.4 Deployment process description ...................................................................................................... 11

8.5 Software provisions............................................................................................................................ 19

8.6 Error handling and reaction............................................................................................................... 20

9 Communication with diagnostic services........................................................................................ 21

9.1 Unified diagnostic services overview............................................................................................... 21

9.2 Diagnostic session control (10 hex) service.................................................................................... 21

9.3 EcuReset (11 hex) service ................................................................................................................. 22

9.4 Read data by identifier (22 hex) service ........................................................................................... 22

9.5 Write data by identifier (2E hex) service .......................................................................................... 29

9.6 Security access (27 hex) service....................................................................................................... 30

9.7 RoutineControl (31 hex) service........................................................................................................ 31

9.8 TesterPresent (3E hex) service ......................................................................................................... 35

Annex A (normative) Specification of the data identifier used.................................................................... 36

Annex B (normative) Deployment loop parameter definitions.................................................................... 41

Annex C (normative) Routine control parameter definitions....................................................................... 47

Bibliography ..................................................................................................................................................... 49

© ISO 2008 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 26021-2:2008(E)
Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies

(ISO member bodies). The work of preparing International Standards is normally carried out through ISO

technical committees. Each member body interested in a subject for which a technical committee has been

established has the right to be represented on that committee. International organizations, governmental and

non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the

International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.

The main task of technical committees is to prepare International Standards. Draft International Standards

adopted by the technical committees are circulated to the member bodies for voting. Publication as an

International Standard requires approval by at least 75 % of the member bodies casting a vote.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent

rights. ISO shall not be held responsible for identifying any or all such patent rights.

ISO 26021-2 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,

Electrical and electronic equipment.

ISO 26021 consists of the following parts, under the general title Road vehicles — End-of-life activation of

on-board pyrotechnic devices:
⎯ Part 1: General information and use case definitions
⎯ Part 2: Communication requirements
⎯ Part 3: Tool requirements
⎯ Part 4: Additional communication line with bidirectional communication
⎯ Part 5: Additional communication line with pulse width modulated signal

NOTE Additional parts will be introduced as necessary to take into account requirements not yet covered by the

standard.
iv © ISO 2008 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 26021-2:2008(E)
Introduction

ISO 26021 describes a method for the in-vehicle deployment of pyrotechnically activated components (also

referred to as pyrotechnic components or pyrotechnic devices) in cars.

Worldwide, nearly all new vehicles are equipped with one or more safety systems. Advanced protection

systems using pyrotechnic actuators are becoming more common. All components which contain pyrotechnic

substances should be handled in the same way.

Recycling of these vehicles requires a new process which ensures that the deactivation of airbags will be safe

and cost-efficient. Based on the harmonization of the on-board diagnostics (OBD) interface, there is an

opportunity to use this interface for on-board deployment, utilizing the same tools and processes.

The representatives of the global automobile industry have decided the following:

⎯ automobile manufacturers do not support reuse as an appropriate treatment method for pyrotechnic

devices;

⎯ automobile manufacturers believe treatment of pyrotechnic devices is required before shredding;

⎯ automobile manufacturers support in-vehicle deployment as the preferred method.

Based on this decision, the four major automobile manufacturer associations (ACEA, Alliance, JAMA and

KAMA) started to develop a method for the in-vehicle deployment of pyrotechnic components in cars with the

pyrotechnic device deployment tool (PDT). The vision is that, one day, a dismantler will need only one tool

without any accessories in order to deploy all the pyrotechnic devices inside an end-of-life vehicle (ELV). The

target is to use an existing interface to the car.

This part of ISO 26021 is applicable to the in-vehicle deployment of pyrotechnic devices in vehicles. It defines

communication methods to be implemented by a pyrotechnic control unit (PCU) to allow the PDT to

successfully establish and maintain communication with the PCUs in the vehicle to deploy all of the

pyrotechnic devices sequentially.
© ISO 2008 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 26021-2:2008(E)
Road vehicles — End-of-life activation of on-board pyrotechnic
devices —
Part 2:
Communication requirements
1 Scope

This part of ISO 26021 defines the deployment process, the system architecture, CAN-based communication

methods and system preconditions which have to be implemented to fulfil the use cases defined in

ISO 26021-1. Additionally, the relationship to and use with other existing standards are defined.

This part of ISO 26021 also describes the technical details of the on-board deployment method. The way in

which the pyrotechnic devices contained in the vehicle function in conjunction with the PDT is the primary

focus of this document. Under the provisions of this document, the design of the PDT or PCU can be

implemented in accordance with specific functionality and hardware requirements.

This part of ISO 26021 specifies the access to the PCU. This includes communication as well as the logic

sequences which are involved during the activation process.
2 Normative references

The following referenced documents are indispensable for the application of this document. For dated

references, only the edition cited applies. For undated references, the latest edition of the referenced

document (including any amendments) applies.

ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference Model —

Conventions for the definition of OSI services

ISO 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical

signalling

ISO 14229-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements

ISO 15031-3, Road vehicles — Communication between vehicle and external equipment for emissions-related

diagnostics — Part 3: Diagnostic connector and related electrical circuits, specification and use

ISO 15765-2:2004, Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part 2: Network layer

services

ISO 15765-3:2004, Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part 3:

Implementation of unified diagnostic services (UDS on CAN)

ISO 15765-4, Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part 4: Requirements for

emissions-related systems

ISO 26021-1, Road vehicles — End-of-life activation of on-board pyrotechnic devices — Part 1: General

information and use case definitions

ISO 26021-4, Road vehicles — End-of-life activation of on-board pyrotechnic devices — Part 4: Additional

communication line with bidirectional communication
© ISO 2008 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO 26021-2:2008(E)

ISO 26021-5, Road vehicles — End-of-life activation of on-board pyrotechnic devices — Part 5: Additional

communication line with pulse width modulated signal
3 Terms and definitions

For the purposes of this document, the terms and definitions given in ISO 14229-1 and the following apply.

3.1
key

data value sent from the external test equipment to the on-board controller in response to the seed in order to

gain access to the locked services
3.2
pyrotechnic device deployment tool

tool designed to be plugged into the OBD interface in order to communicate via the internal computer network

in an end-of-life vehicle with all control units which are able to activate pyrotechnic devices

NOTE This tool will comprise e.g. a computer, a connection between the computer and the diagnostic connector, and

some software.
3.3
pyrotechnic control unit
PCU

electronic control unit in the vehicle network which controls the activation of pyrotechnic devices

3.4
safing

mechanism whose primary purpose is to prevent an unintended functioning of the PCU processor prior to

detection of a crash situation
3.5
safing unit

part of the PCU (e.g. an electromechanically operated switch or a separate processor) that allows the

pyrotechnic component deployment microprocessor (µP) to deploy the pyrotechnic devices via the driver

stage
3.6
scrapping program module
module responsible for firing the selected pyrotechnic device loops one by one
3.7
scrapping program module loader

module responsible for converting the scrapping program module to an executable format

3.8
seed

pseudo-random data value sent from the on-board controller to the external test equipment, which is

processed by the security algorithm to produce the key
4 Symbols and abbreviated terms
ACL additional communication line
CAN controller area network
ELV end-of-life vehicle
OBD on-board diagnostics
2 © ISO 2008 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 26021-2:2008(E)
PCU pyrotechnic control unit
PDT pyrotechnic device deployment tool
RAM random access memory
SPL scrapping program module loader
SPM scrapping program module
SRS supplementary restraint system
µC microcontroller
5 Conventions

ISO 26021 is based on the conventions for the definition of OSI services (see ISO/IEC 10731) as they apply to

diagnostic services.
6 Pyrotechnic device deployment via on-board diagnostic architecture
6.1 Vehicle system description

ISO 26021 is based on a vision of the diagnostic network architecture in combination with the PCU

deployment architecture that is described below.

The PCU is connected to the vehicle diagnostic connector in accordance with ISO 15031-3. The PDT

communicates with the PCU on CAN_H and CAN_L, which are the mandatory vehicle interfaces.

Depending upon the specific architecture of the vehicle, the mandatory link of the PCU may be connected via

a gateway to the diagnostic connector; thus a CAN interface in the PCU for the mandatory link may not be

required.

During the deployment procedure, the vehicle PCUs shall be powered by the vehicle battery or, if the battery

is flat, by connecting an external power source to the battery terminals.
This requires an undamaged electrical architecture for the devices involved.
Figure 1 — Access to the vehicle via diagnostic connector
© ISO 2008 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO 26021-2:2008(E)

To interface the PCU with the vehicle, a PDT to diagnostic connector interface shall be used. The purpose of

this interface is to
⎯ provide the CAN bus interface and optional ACL interface with the vehicle;

⎯ provide widely known standard wire interfaces like UART (RS232) or USB, or wireless interfaces like

BLUETOOTH and WLAN.

The PDT could be based on a PC architecture running the operation system and application software from a

bootable compact disc (CD) to avoid independence from software of any operating system, or the PDT could

consist of a separate operating console.
6.2 Example of in-vehicle hardware and software required

To execute the on-board deployment via the communication link, the software inside the PCU shall have full

access to the output driver stage, which controls the deployment loops.

In the solution without an ACL, a mechanical acceleration switch in the deployment loop circuit would not be

able to carry out the redundant safing function.

To achieve a reasonable functionality without the classical safing design, an independent electronic safing unit

is recommended due to the different safing philosophies of the various vehicle manufacturers. This unit could

receive the required safing acceleration data from a second acceleration sensor inside the PCU or from an

external frontal sensor.

Thus the deployment loop output stage is controlled by two independent branches. Depending on the safing

philosophy of the vehicle manufacturer, the safing path could be controlled via the optional ACL or the main

deployment processor.
Figure 2 — Overview of hardware and software required
4 © ISO 2008 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 26021-2:2008(E)
6.3 Additional communication line (optional)

For special safety requirements, an additional signal can be applied. General requirements for the interface

between the deployment sequence and the ACL sequence are as shown in Figure 3.
Figure 3 — Integration of ACL communication into deployment process

The standardized steps specify the diagnostic sequence. This type of step is mandatory. The PDT and the

PCU shall behave as specified. The optional steps are necessary if the original equipment manufacturer

(OEM) chooses the additional communication line. Optional ACL steps will depend on the use of the ACL

option. Only while communicating with a PCU having an ACL is the PDT allowed to connect with the ACL line.

These steps are mandatory only for the optional ACL. These optional steps are detailed in ISO 26021-4 and

ISO 26021-5.
6.4 Requirements for the PDT
6.4.1 Power supply

This subclause defines the requirements for the PDT to be able to establish communication with the PCUs

and successfully activate the pyrotechnic devices installed in the vehicle.

The PCUs shall be powered internally so that they are independent of the power supply of the vehicle even if

pins 4 and 16 on the diagnostic connector provide a permanent power supply when the vehicle is powered.

This is to achieve robustness against a damaged power supply in the diagnostic connector. However, the tool

may provide the capability to recharge its internal batteries using pins 4 and 16 of the diagnostic connector if

the power supply on these pins has not been damaged.
6.4.2 Initial condition of vehicle

The operation can only start if full access to the vehicle is granted via a suitable identification method (e.g.

ignition key or keyless entry unit).

It is necessary to ensure that the vehicle's electronic system is active for communication via the diagnostic

connector.
6.4.3 Safety requirements

To execute the on-board deployment function via the diagnostic connection, a software module inside the

PCU is required which performs the necessary steps to control the output stages, overrides the safing unit

(alternative use of ACL) and carries out the communication to the PDT. To avoid any inadvertent deployment

© ISO 2008 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO 26021-2:2008(E)

caused by the deployment software module in the PCU, it shall be stored in a non-executable format in the

program memory of the PCU and shall only be activated by an SPL which is an executable program code.

A key code from the PDT is required to enable the SPL to load the SPM into the RAM and convert the SPM to

an executable format.

After a further communication sequence of the PDT with the PCU, the SPM will communicate to the

independent electronic safing unit (if no ACL is available), activate the output stages and record this event

individually for each deployment loop.

When an ACL is present, the unlock signal on this line has to be present during the deployment event and

evaluated by the independent safing unit to release the output.

After the deployment sequence of this particular PCU is completed, the PDT may request a reset of the PCU

and the PCU exits the scrapping mode.
6.4.4 Suitability of vehicle

Vehicles that can be scrapped via the diagnostic connector will respond to the PDT. All others will not.

7 Relationship to existing standards
7.1 General

All clauses of ISO 11898-1, ISO 14229-1 and the relevant part of ISO 15765 are applicable for the PCU

deployment process, with the restrictions/additions defined below.
7.2 Application layer

This part of ISO 26021 uses the application layer services and protocol as defined in ISO 14229-1 for client-

server-based systems to perform functions such as initialization, monitoring or start of functions of on-board

vehicle servers like the PCU.
7.3 Session layer

For security reasons, the scrapping sequence shall take place in the deployment session.

7.4 Application layer and diagnostic session management timing

This part of ISO 26021 uses the application layer and session layer timing parameters as defined in

ISO 14229-1 and ISO 15765-3. The detailed timing parameter descriptions for physical communication and

functional communication shall be in accordance with ISO 15765-3. Although functional communication is not

necessary for this part of ISO 26021, ∆P2CAN shall be between 0 ms and 500 ms. The PDT needs to detect

P2CAN_Client timeout and this part of ISO 26021 specifies the ∆P2CAN value for gateway design.

In the case of a communication error, it is assumed that the client and the server implement the application

and session layer timing as defined in ISO 15765-3. The client (i.e. the PDT) shall repeat the last request a

maximum of two (2) times, which means that the greatest number of service request transmissions is three (3).

In the case of the worst-case communication error, the PDT shall stop the execution of the deployment

process.
6 © ISO 2008 – All rights reserved
---------------------- Page: 11 ----------------------
ISO 26021-2:2008(E)
7.5 Network layer

The network layer of the external equipment (i.e. the PDT) and the vehicle, which may have one or more

PCUs, shall be compliant with the standard diagnostic specification in ISO 15765-4, with the restrictions

defined below:

⎯ the PDT shall not transmit the FC.WAIT frame in the segmented response message;

⎯ the PDT shall not transmit the FC frame with the non-zero block size (BS) parameter in the segmented

response message;

⎯ the PDT shall not transmit the FC frame with the non-zero separation time (STmin) parameter in the

segmented response message;

⎯ the maximum number of FC.Wait frame transmission (N_WFTmax) parameters shall be zero.

For the parameters used above, see ISO 15765-2:2004, Subclause 6.5.5, “FlowControl N_PCI parameter

definition”.

From the external test equipment (PDT) point of view, each PCU in a compliant vehicle must have an

addressed CAN identifier.

For the initialization sequence only, the normal addressing format and normal fixed addressing format as

defined in ISO 15765-2 shall be used.
⎯ 11 bit CAN identifiers: normal addressing;
⎯ 29 bit CAN identifiers: normal fixed addressing.

After the initialization sequence, the OEM-specific combinations can be used as defined in Table 3 to Table 5.

7.6 Data link layer
7.6.1 11 bit CAN identifiers

Table 1 specifies the 11 bit CAN identifiers for safety-relevant initialization aspects, based on the defined

mapping of the diagnostic addresses.
Table 1 — 11 bit safety-relevant identifiers
CAN identifier Description
(hex)
7F1 Physical request CAN identifier from the external test equipment to PCU #1

7F9 Physical response CAN identifier from PCU #1 to the external test equipment PDT

© ISO 2008 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO 26021-2:2008(E)
7.6.2 29 bit CAN identifiers

Table 2 specifies the 29 bit CAN identifiers for safety-relevant initialization aspects, based on the defined

mapping of the diagnostic addresses.
Table 2 — 29 bit PCU deployment CAN identifiers
CAN identifier Description
(hex)

18 DA 53 F1 Physical request CAN identifier from the external test equipment to PCU 0x53 (hex)

18 DA F1 53 Physical response CAN identifier from PCU 0x53 (hex) to the external test equipment

The maximum number of safety-relevant ECUs in a PCU deployment compliant vehicle is not limited. The

physical PCU diagnostic address of the fixed-address PCU is “0x53” hex. This address, embedded in the

physical CAN identifiers, shall be unique to any one vehicle.

7.6.3 Mapping of network layer protocol data units to PCU address information of in-vehicle PCUs

The PCUAddressFormat byte defines the mapping of the request and response addresses into a 32 bit field

as defined in Tables 3 to 5.
Table 3 — Reserved PCU Address Format
8 bit field 32 bit field request/response address
PCUAddress
Format
Byte 1 (MSB) Byte 2 Byte 3 Byte 4 (LSB)
31 24 23 19 18 16 15 8 7 0
Reserved 0x00 0x00, 0x00, 0x00, 0x00
Reserved 0x07 … 0xFF ISO/SAE reserved for future use

Table 4 — Mapping of 11 bit N_PDU parameters into the 32 bit request/response address

11 bit mapping 8 bit field 32 bit field request/response address
(e.g. CAN) PCUAddress
See ISO 15765-2:2004, Subclause 7.3, Mapping of the N_PDU fields.
Format
Byte 1 (MSB) Byte 2 Byte 3 Byte 4 (LSB)
31 24 23 19 18 16 15 8 7 0
11 bit — normal 0x01 0x00 0b0000 0 N_AI 0xFF (default)
addressing
11 bit — extended 0x02 0x00 0b0000 0 N_AI, except N_TA N_TA
addressing
11 bit — mixed 0x03 0x00 0b0000 0 N_AI N_AE
addressing
8 © ISO 2008 – All rights reserved
---------------------- Page: 13 ----------------------
ISO 26021-2:2008(E)

Table 5 — Mapping of 29 bit N_PDU parameters into the 32 bit request/response address

29 bit mapping 8 bit field 32 bit field request/response address
(e.g. CAN) PCUAddress
See ISO 15765-2:2004, Subclause 7.3, Mapping of the N_PDU fields, and
Format
ISO 15765-3:2004, Subclause 8.3, Enhanced diagnostics 29 bit CAN identifiers.
Byte 1 (MSB) Byte 2 Byte 3 Byte 4 (LSB)
29 bit — normal 0x04 0x00 N_TA N_SA 0xFF
fixed addressing
29 bit — mixed 0x05 0x00 N_TA N_SA N_AE
addressing
ISO 15765-3 31 22 21 11 10 0
mapping
Unique addressing 0x06 0b00 0110 1111 Unique source address Unique destination
address
7.7 Data link layer
There is no addition or restriction to the data link layer.
7.8 Physical layer

The PDT shall support all legislated OBD baud rates. If this is not possible, the PDT shall support at least the

baud rates of 250 kbit/s and 500 kbit/s.
8 Deployment process
8.1 General information
This clause defines the general steps in the deployme
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.