Date of entry into force as an annex to the
1958 Agreement: 22 January 2021
1958년 협정의 부속서로 2021년 1월 22일
시행
Addendum 155 – UN Regulation No.
156
Uniform provisions concerning the
approval of vehicles with regards to
software update and software updates
management system
1. Scope
1.1. This Regulation applies to vehicles of
CategoriesM, N, O, R, S and T that permit
software updates.
2. Definitions
2.1. “Vehicle type” means vehicles which do
not differ in at least the following:
(a) The manufacturer’s designation of the
vehicle type;
(b) Essential aspects of the design of the
vehicle type with respect to software
update processes.
2.2. “RX Software Identification Number
(RXSWIN)” means a dedicated identifier,
defined by the vehicle manufacturer,
representing information about the type
approval relevant software of the Electronic
Control System contributing to the
Regulation N° X type approval relevant
characteristics of the vehicle.
2.3. “Software update” means a package
used to upgrade software to a new version
including a change of the configuration
parameters.
2.4. “Execution” means the process of
installing and activating an update that has
been downloaded.
2.5. “Software Update Management System
(SUMS)” means a systematic approach
defining organizational processes and
procedures to comply with the requirements
for delivery of software updates according
to this Regulation.
2.6. “Vehicle user” means a person
operating or driving the vehicle, a vehicle
owner, an authorised representative or
employee of a fleet manager, an authorised
representative or employee of the vehicle
manufacturer, or an authorized technician.
2.7. “Safe state” means an operating mode
in case of a failure of an item without an
unreasonable level of risk.
2.8. “Software” means the part of an
Electronic Control System that consists of
digital data and instruction.
2.9. “Over-the-Air (OTA) update” means
any method of making data transfers
wirelessly instead of using a cable or other
local connection.
2.10. “System” means a set of components
and/or sub-systems that implement a
function of functions.
2.11. “Integrity validation data” means a
representation of digital data, against which
comparisons can be made to detect errors
or changes in the data. This may include
checksums and hash values.
3. Application for approval
3.1. The application for approval of a
vehicle type with regard to software update
processes shall be submitted by the vehicle
manufacturer or by their duly accredited
representative.
3.2. It shall be accompanied by the
undermentioned documents in triplicate, and
by the following particulars:
3.3. A description of the vehicle type with
regard to the items specified in Annex 1 to
this Regulation.
3.4. In cases where information is shown to
be covered by intellectual property rights or
to constitute specific know-how of the
manufacturer or of their suppliers, the
manufacturer or their suppliers shall make
available sufficient information to enable
the checks referred to in this Regulation to
be made properly. Such information shall be
treated on a confidential basis.
3.5. The Certificate of Compliance for
Software Update Management System
according to paragraph 6. of this Regulation.
3.6. A vehicle representative of the vehicle
type to be approved shall be submitted to
the Technical Service responsible for
conducting approval tests.
3.7. Documentation shall be made available
in two parts:
(a) The formal documentation package for
the approval, containing the material
specified in Annex 1 which shall be supplied
to the Approval Authority or its Technical
Service at the time of submission of the
type approval application. This
documentation package shall be used by the
Approval Authority or its Technical Service
as the basic reference for the approval
process. The Approval Authority or its
Technical Service shall ensure that this
documentation package remains available
for at least 10 years counted from the time
when production of the vehicle type is
definitely discontinued.
(b) Additional material relevant to the
requirements of this regulation may be
retained by the manufacturer but made open
for inspection at the time of type approval.
The manufacturer shall ensure that any
material made open for inspection at the
time of type approval remains available for
at least a period of 10 years counted from
the time when production of the vehicle
type is definitely discontinued.
4. Marking
4.1. There shall be affixed, conspicuously
and in a readily accessible place specified
on the approval form, to every vehicle
conforming to a vehicle type approved
under this Regulation an international
approval mark consisting of:
4.1.1. A circle surrounding the Letter “E”
followed by the distinguishing number of
the country which has granted approval.
The number of this Regulation, followed by
the letter “R”, a dash and the approval
number to the right of the circle described
in paragraph 4.1.1. above.
4.2. If the vehicle conforms to a vehicle
type approved under one or more other
Regulations annexed to the Agreement in
the country which has granted approval
under this Regulation, the symbol
prescribed in paragraph 4.1.1. above need
not be repeated; in this case the Regulation
and approval numbers and the additional
symbols of all the Regulations under which
approval has been granted in the country
which has granted approval under this
Regulation shall be placed in vertical
columns to the right of the symbol
prescribed in paragraph 4.1.1. above.
4.3. The approval mark shall be clearly
legible and shall be indelible.
4.4. The approval mark shall be placed on
or close to the vehicle data plate affixed by
the Manufacturer.
4.5. Annex 3 to this Regulation gives
examples of the arrangements of the
approval mark.
5. Approval
5.1. Approval Authorities shall grant, as
appropriate, type approval with regard to
software update procedures and processes,
only to such vehicle types that satisfy the
requirements of this Regulation.
5.1.1. The Approval Authority or the
Technical Service shall verify by testing a
vehicle of the vehicle type that the vehicle
manufacturer has implemented the
measures they have documented. Tests
shall be performed by approval authority or
the technical service itself or in
collaboration with the vehicle manufacturer
by sampling.
5.2. Notice of approval or of extension or
refusal of approval of a vehicle type
pursuant to this Regulation shall be
communicated to the Parties to the 1958
Agreement which apply this Regulation, by
means of a form conforming to the model in
Annex 2 to this Regulation.
5.3. Approval Authorities shall not grant
any type approval without ensuring that the
manufacturer has put in place satisfactory
arrangements and procedures to manage
properly the software update processes
aspects as covered by this regulation.
6. Certificate of Compliance for Software
Update Management System
6.1. Contracting Parties shall appoint an
Approval Authority to carry out the
assessment of the manufacturer and to
issue a Certificate of Compliance for
Software Update Management System.
6.2. An application for a Certificate of
Compliance for Software Update
Management System shall be submitted by
the vehicle manufacturer or by their duly
accredited representative.
6.3. It shall be accompanied by the
undermentioned documents in triplicate, and
by the following particular:
6.3.1. Documents describing the Software
Update Management System.
6.3.2. A signed declaration using the model
as defined in Appendix 1 to Annex 1.
6.4. In the context of the assessment, the
manufacturer shall declare using the model
as defined in Appendix 1 to Annex 1 and
demonstrate to the satisfaction of the
Approval Authority or its Technical Service
that they have the necessary processes to
comply with all the requirements for
software updates according to this
Regulation.
6.5. When this assessment has been
satisfactorily completed and in receipt of a
signed declaration from the manufacturer
according to the model as defined in
Appendix 1 to Annex 1, a certificate named
Certificate of Compliance for SUMS as
described in Annex 4 to this Regulation
(hereinafter the Certificate of Compliance
for SUMS) shall be granted to the
manufacturer.
6.6. The Certificate of Compliance for
SUMS shall remain valid for a maximum of
three years from the date of deliverance of
the certificate unless it is withdrawn.
6.7. The Approval Authority which has
granted the Certificate of Compliance for
Software Update Management System may
at any time verify its continued compliance.
The Certificate of Compliance for Software
Update Management System may be
withdrawn if the requirements laid down in
this Regulation are no longer met.
6.8. The manufacturer shall inform the
Approval Authority or its Technical Service
of any change that will affect the relevance
of the Certificate of Compliance for
Software Update Management System.
After consultation with the manufacturer,
the Approval Authority or its Technical
Service shall decide whether new checks
are necessary.
6.9. At the end of the period of validity of
the Certificate of Compliance for Software
Update Management System, the Approval
Authority shall, after a positive assessment,
issue a new Certificate of Compliance for
Software Update Management System or
extends its validity for a further period of
three years. The Approval Authority shall
issue a new certificate in cases where
changes have been brought to the attention
of the Approval Authority or its Technical
Service and the changes have been
positively re-assessed.
6.10. Existing vehicle type approvals shall
not lose their validity due to the expiration
of the manufacturer’s Certificate of
Compliance for Software Update
Management System.
7. General specifications
7.1. Requirements for the Software Update
Management System of the vehicle
manufacturer
7.1.1. Processes to be verified at initial
assessment
7.1.1.1. A process whereby information
relevant to this Regulation is documented
and securely held at the vehicle
manufacturer and can be made available to
an Approval Authority or its Technical
Service upon request;
7.1.1.2. A process whereby information
regarding all initial and updated software
versions, including integrity validation data,
and relevant hardware components of a type
approved system can be uniquely identified;
7.1.1.3. A process whereby, for a vehicle
type that has an RXSWIN, information
regarding the RXSWIN of the vehicle type
before and after an update can be accessed
and updated. This shall include the ability to
update information regarding the software
versions and their integrity validation data
of all relevant software for each RXSWIN;
7.1.1.4. A process whereby, for a vehicle
type that has an RXSWIN, the vehicle
manufacturer can verify that the software
version(s) present on a component of a
type approved system are consistent with
those defined by the relevant RXSWIN;
7.1.1.5. A process whereby any
interdependencies of the updated system
with other systems can be identified;
7.1.1.6. A process whereby the vehicle
manufacturer is able to identify target
vehicles for a software update;
7.1.1.7. A process to confirm the
compatibility of a software update with the
target vehicle(s) configuration before it is
issued. This shall include an assessment of
the last known software/hardware
configuration of the target vehicle(s) for
compatibility with the update before it is
issued;
7.1.1.8. A process to assess, identify and
record whether a software update will
affect any type approved systems. This
shall consider whether the update will
impact or alter any of the parameters used
to define the systems the update may affect
or whether it may change any of the
parameters used to type approve those
system (as defined in the relevant
legislation);
7.1.1.9. A process to assess, identify and
record whether a software update will add,
alter or enable any functions that were not
present, or enabled, when the vehicle was
type approved or alter or disable any other
parameters or functions that are defined
within legislation. The assessment shall
include consideration of whether:
(a) Entries in the information package will
need to be modified;
(b) Test results no longer cover the vehicle
after modification;
(c) Any modification to functions on the
vehicle will affect the vehicle’s type
approval.
7.1.1.10. A process to assess, identify and
record if a software update will affect any
other system required for the safe and
continued operation of the vehicle or if the
update will add or alter functionality of the
vehicle compared to when it was registered;
7.1.1.11. A process whereby the vehicle
user is able to be informed about updates;
7.1.1.12. A process whereby the vehicle
manufacturer shall be able to make the
information according to paragraph 7.1.2.3.
and 7.1.2.4. available to responsible
Authorities or the Technical Services. This
may be for the purpose of type approval,
conformity of production, market
surveillance, recalls and Periodic Technical
Inspection (PTI).
7.1.2. The vehicle manufacturer shall
record, and store, the following information
for each update applied to a given vehicle
type:
7.1.2.1. Documentation describing the
processes used by the vehicle manufacturer
for software updates and any relevant
standards used to demonstrate their
compliance;
7.1.2.2. Documentation describing the
configuration of any relevant type approved
systems before and after an update, this
shall include unique identification for the
type approved system’s hardware and
software (including software versions) and
any relevant vehicle or system parameters;
7.1.2.3. For every RXSWIN, there shall be
an auditable register describing all the
software relevant to the RXSWIN of the
vehicle type before and after an update.
This shall include information of the
software versions and their integrity
validation data for all relevant software for
each RXSWIN.
7.1.2.4. Documentation listing target
vehicles for the update and confirmation of
the compatibility of the last known
configuration of those vehicles with the
update.
7.1.2.5. Documentation for all software
updates for that vehicle type describing:
(a) The purpose of the update;
(b) What systems or functions of the
vehicle the update may affect;
(c) Which of these are type approved (if
any);
(d) If applicable, whether the software
update affects the fulfilment of any of the
relevant requirements of those type
approved system;
(e) Whether the software update affects
any system type approval parameter;
(f) Whether an approval for the update was
sought from an approval body;
(g) How the update may be executed and
under what conditions;
(h) Confirmation that the software update
will be conducted safely and securely;
(i) Confirmation that the software update
has undergone and successfully passed
verification and validation procedures.
7.1.3. Security - the vehicle manufacturer
shall demonstrate:
7.1.3.1. The process they will use to ensure
that software updates will be protected to
reasonably prevent manipulation before the
update process is initiated.;
7.1.3.2. The update processes used are
protected to reasonably prevent them being
compromised, including development of the
update delivery system;
7.1.3.3. The processes used to verify and
validate software functionality and code for
the software used in the vehicle are
appropriate.
7.1.4. Additional requirements for software
updates over the air
7.1.4.1. The vehicle manufacturer shall
demonstrate the processes and procedures
they will use to assess that over the air
updates will not impact safety, if conducted
during driving.
7.1.4.2. The vehicle manufacturer shall
demonstrate the processes and procedures
they will use to ensure that, when an over
the air update requires a specific skilled or
complex action, for example recalibrate a
sensor post-programming, in order to
complete the update process, the update
can only proceed when a person skilled to
do that action is present or is in control of
the process.
7.2. Requirements for the Vehicle Type
7.2.1. Requirements for Software updates
7.2.1.1. The authenticity and integrity of
software updates shall be protected to
reasonably prevent their compromise and
reasonably prevent invalid updates.
7.2.1.2. Where a vehicle type uses
RXSWIN:
7.2.1.2.1. Each RXSWIN shall be uniquely
identifiable. When type approval relevant
software is modified by the vehicle
manufacturer, the RXSWIN shall be updated
if it leads to a type approval extension or to
a new type approval.
7.2.1.2.2. Each RXSWIN shall be easily
readable in a standardized way via the use
of an electronic communication interface, at
least by the standard interface (OBD port).
If RXSWINs are not held on the vehicle, the
manufacturer shall declare the software
version(s) of the vehicle or single ECUs
with the connection to the relevant type
approvals to the Approval Authority. This
declaration shall be updated each time the
declared software version(s) is updated. In
this case, the software version(s) shall be
easily readable in a standardized way via
the use of an electronic communication
interface, at least by the standard interface
(OBD port).
7.2.1.2.3. The vehicle manufacturer shall
protect the RXSWINs and/or software
version(s) on a vehicle against unauthorised
modification. At the time of Type Approval,
the means implemented to protect against
unauthorized modification of the RXSWIN
and/or software version(s) chosen by the
vehicle manufacturer shall be confidentially
provided.
7.2.2. Additional Requirements for over the
air updates
7.2.2.1. The vehicle shall have the following
functionality with regards to software
updates:
7.2.2.1.1. The vehicle manufacturer shall
ensure that the vehicle is able to restore
systems to their previous version in case of
a failed or interrupted update or that the
vehicle can be placed into a safe state after
a failed or interrupted update.
7.2.2.1.2. The vehicle manufacturer shall
ensure that software updates can only be
executed when the vehicle has enough
power to complete the update process
(including that needed for a possible
recovery to the previous version or for the
vehicle to be placed into a safe state).
7.2.2.1.3. When the execution of an update
may affect the safety of the vehicle, the
vehicle manufacturer shall demonstrate how
the update will be executed safely. This
shall be achieved through technical means
that ensures the vehicle is in a state where
the update can be executed safely.
7.2.2.2. The vehicle manufacturer shall
demonstrate that the vehicle user is able to
be informed about an update before the
update is executed. The information made
available shall contain:
(a) The purpose of the update. This could
include the criticality of the update and if
the update is for recall, safety and/or
security purposes;
(b) Any changes implemented by the
update on vehicle functions;
(c) The expected time to complete
execution of the update;
(d) Any vehicle functionalities which may
not be available during the execution of the
update;
(e) Any instructions that may help the
vehicle user safely execute the update;
In case of groups of updates with a similar
content one information may cover a group.
7.2.2.3. In the situation where the
execution of an update whilst driving may
not be safe, the vehicle manufacturer shall
demonstrate how they will:
(a) Ensure the vehicle cannot be driven
during the execution of the update;
(b) Ensure that the driver is not able to use
any functionality of the vehicle that would
affect the safety of the vehicle or the
successful execution of the update.
7.2.2.4. After the execution of an update
the vehicle manufacturer shall demonstrate
how the following will be implemented:
(a) The vehicle user is able to be informed
of the success (or failure) of the update;
(b) The vehicle user is able to be informed
about the changes implemented and any
related updates to the user manual (if
applicable).
7.2.2.5. The vehicle shall ensure that
preconditions have to be met before the
software update is executed.
8. Modification and extension of the vehicle
type
8.1. Every modification of the vehicle type
which affects its technical performance
and/or documentation required in this
Regulation shall be notified to the approval
authority which granted the approval. The
approval authority may then either:
8.1.1. Consider that the modifications made
still comply with the requirements and
documentation of prior type approval; or
8.1.2. Require a further test report from the
Technical Service responsible for
conducting the tests.
8.1.3. Confirmation or extension or refusal
of approval, specifying the alterations, shall
be communicated by means of a
communication form conforming to the
model in Annex 2 to this Regulation. The
approval authority issuing the extension of
approval shall assign a series number for
such an extension and inform there of the
other Parties to the 1958 Agreement
applying this Regulation by means of a
communication form conforming to the
model in Annex 2 to this Regulation.
9. Conformity of production
9.1. The Conformity of Production
Procedures shall comply with those set out
in the 1958 Agreement, Schedule 1
(E/ECE/TRANS/505/Rev.3) with the
following requirements:
9.1.1. The holder of the approval shall
ensure that results of the conformity of
production tests are recorded and that the
annexed documents remain available for a
period determined in agreement with the
Approval Authority or its Technical
Service. This period shall not exceed 10
years counted from the time when
production is definitively discontinued;
9.1.2. The Approval Authority which has
granted type approval may at any time
verify the conformity control methods
applied in each production facility. The
normal frequency of these verifications
shall be once every three years.
9.1.3. The Approval Authority or its
Technical Service shall periodically validate
that the processes used and decisions made
by the vehicle manufacturer are compliant,
particularly for instances where the vehicle
manufacturer chose not to notify the
Approval Authority or its Technical Service
about an update. This may be achieved on a
sampling basis.
10. Penalties for non-conformity of
production
10.1. The approval granted in respect of a
vehicle type pursuant to this Regulation
may be withdrawn if the requirement laid
down in this Regulation are not complied
with or if sample vehicles fail to comply
with the requirements of this Regulation.
10.2. If an Approval Authority withdraws an
approval it has previously granted, it shall
forthwith so notify the Contracting Parties
applying this Regulation, by means of a
communication form conforming to the
model in Annex 2 to this Regulation.
11. Production definitively discontinued
11.1. If the holder of the approval
completely ceases to manufacture a type of
vehicle approved in accordance with this
Regulation, he shall so inform the authority
which granted the approval. Upon receiving
the relevant communication that authority
shall inform thereof the other Contracting
Parties to the Agreement applying this
Regulation by means of a copy of the
approval form bearing at the end, in large
letters, the signed and dated annotation
“PRODUCTION DISCONTINUED”.
12. Names and addresses of Technical
Services responsible for conducting approval
test, and of Type Approval Authorities
12.1. The Contracting Parties to the
Agreement which apply this Regulation
shall communicate to the United Nations
Secretariat the names and addresses of the
Technical Services responsible for
conducting approval tests and of the Type
Approval Authorities which grant approval
and to which forms certifying approval or
extension or refusal or withdrawal of
approval, issued in other countries, are to
be sent.
Annex 1 Information document
The following information, if applicable,
shall be supplied in triplicate and include a
list of contents. Any drawings shall be
supplied in appropriate scale and in
sufficient detail on size A4 or on a folder of
A4 format. Photographs, if any, shall show
sufficient detail.
1. Make (trade name of manufacturer): .
2. Type and general commercial
description(s): (Type is the type to be
approved, commercial description refers to
the product in which the approved type is
used)
3. Means of identification of type, if marked
on the vehicle:
4. Location of that marking:
5. Category(ies) of vehicle:
6. Name and address of manufacturer/
manufacturer's representative:
7. Name(s) and Address(es) of assembly
plant(s):
8. Photograph(s) and/or drawing(s) of a
representative vehicle:
9. Software Updates
9.1. General construction characteristics of
the vehicle type:
9.2. The number of the Certificate of
Compliance for Software Update
Management System: .
9.3. Security measures.
9.3.1. Documents for the vehicle type to be
approved describing that the update process
will be performed securely
9.3.2. Documents for the vehicle type to be
approved describing that the RXSWINs on a
vehicle are protected against unauthorized
manipulation.
9.4. Software updates over the air
9.4.1. Documents for the vehicle type to be
approved describing that the update process
will be performed safely
9.4.2. How a vehicle user is able to be
informed about an update before and after
its execution.
Annex 1 - Appendix 1 Model of
declaration of compliance for
Software Update Management
System
Manufacturer’s declaration of
compliance with the requirements for
Software Update Management
System
Manufacturer Name:
Manufacturer Address: .
(Manufacturer Name) attests that the
necessary processes to comply with the
requirements for the Software Update
Management System laid down in paragraph
7.1 of UN Regulation No. 156 are installed
and will be maintained.
Done at: (place)
Date: .
Name of the signatory:
Function of the signatory:
(Stamp and signature of the manufacturer’s
representative)
Annex 2 Communication
(Maximum format: A4 (210 x 297 mm))
issued by: Name of administration:
그림1 (원문)
Concerning:Approval granted
Approval extended
Approval withdrawn with effect from
dd/mm/yyyy Approval refused
Production definitively discontinued
of a vehicle type, pursuant to UN
Regulation No. 156
Approval No.:
Extension No.: .
Reason for extension:
Reason for extension:
1. Make (trade name of manufacturer):
2. Type and general commercial
description(s) .
3. Means of identification of type, if marked
on the vehicle:
3.1. Location of that marking: .
4. Category(ies) of vehicle:
5. Name and address of manufacturer /
manufacturer’s representative:
6. Name(s) and Address(es) of the
production plant(s)
7. Number of the certificate of compliance
for software update management system: .
8. Software updates over the air included
(Yes/no):
9. Technical Service responsible for
carrying out the tests: .
10. Date of test report: .
11. Number of test report:
12. Remarks: (if any). .
13. Place:
14. Date:
15. Signature: .
16. The index to the information package
lodged with the Approval Authority, which
may be obtained on request is attached.
Annex 3 Arrangement of approval
mark
Model A
(See paragraph 4.2 of this Regulation)
그림2 (원문)
a = 8 mm min.
The above approval mark affixed to a
vehicle shows that the road vehicle type
concerned has been approved in the
Netherlands (E 4), pursuant to Regulation
No. 156, and under the approval number
001234. The first two digits of the approval
number indicate that the approval was
granted in accordance with the
requirements of this Regulation in its
original form (00).
Annex 4 Model of Certificate of
Compliance for Software Update
Management System
CERTIFICATE OF COMPLIANCE
FOR SOFTWARE UPDATE
MANAGEMENT SYSTEM
With UN Regulation No. 156
Certificate Number [Reference number]
[Approval Authority]
Certifies that
Manufacturer:
Address of the manufacturer:
Complies with the provisions of Regulation
No. [this Regulation]
Verifications have been performed on: .
by (name and address of the Approval
Authority):
Number of report:.
The certificate is valid until: [Date]
Done at: [Place]
On: [ Date]
[Signature]
Date of entry into force as an annex to the
1958 Agreement: 22 January 2021
1958년 협정의 부속서로 2021년 1월 22일
시행
부록 155. 국제연합 규정 제156호
소프트웨어 업데이트 및 소프트웨어
업데이트 관리시스템과 관련하여 차량
승인에 관한 통일 조항
제1조(범위)
1.1. 이 규정은 소프트웨어 업데이트를 허용
하는 카테고리 M, N, O, R, S 및 T의 차량에
적용된다.
제2조(정의)
2.1. “차량형식”이란 최소한 다음과 같은 차
이가 없는 차량을 말한다.
(a) 제조사의 차량형식 지정
(b) 소프트웨어 업데이트 절차와 관련된 차
량형식 설계의 필수적인 측면
2.2. “RX 소프트웨어 식별번호”란 차량의 규
정 N° X 형식승인 관련 특성에 기여하는 전
자제어장치의 형식승인 관련 소프트웨어에
대한 정보를 나타내는 차량 제조사가 정의하
는 전용 식별자를 말한다.
2.3. “소프트웨어 업데이트”란 구성 매개변수
의 변경을 포함하여 소프트웨어를 신규 버전
으로 성능 향상하는 데 사용되는 패키지를
말한다.
2.4. “실행”이란 다운로드된 업데이트를 설치
하고 활성화하는 절차를 말한다.
2.5. “소프트웨어 업데이트 관리시스템”이란
이 규정에 따라 소프트웨어 업데이트 제공
요건을 준수하기 위한 조직적 처리 및 절차
를 정의하는 체계적인 접근방식을 말한다.
2.6. “차량사용자”란 차량을 운행하거나 운전
하는 자, 차량 소유자, 차량군 관리자의 공
인 대리인이나 직원, 차량 제조사의 공인 대
리인이나 직원 또는 공인 기술자를 말한다.
2.7. “안전상태”란 불합리한 수준의 위험 없
이 어느 품목이 고장난 경우의 작동 모드를
말한다.
2.8. “소프트웨어”란 디지털 데이터와 명령으
로 구성된 전자제어장치의 일부를 말한다.
2.9. “무선 업데이트”란 케이블이나 그 밖의
로컬 연결을 사용하는 대신 무선으로 데이터
를 전송하는 방식을 말한다.
2.10. “시스템”이란 기능들 중 어느 한 기능
을 구현하는 구성요소 및 하위시스템의 집합
을 말한다.
2.11. “무결성 검증 데이터”란 데이터상 오
류 또는 변경을 감지하기 위하여 비교할 수
있는 디지털 데이터의 표현을 말한다. 이에
는 체크섬과 해시값이 포함될 수 있다.
제3조(승인 신청서)
3.1. 소프트웨어 업데이트 절차와 관련된 차
량형식의 승인 신청서는 차량 제조사 또는
적법하게 공인된 대리인이 제출한다.
3.2. 아래에 언급된 문서 3부와 다음의 세부
사항을 첨부한다.
3.3. 이 규정의 부속서 1에 명시된 항목에
대한 차량형식에 관한 설명
3.4. 정보가 지식재산권의 적용을 받거나 제
조사나 공급업체의 특정 노하우를 구성하는
것으로 표시되는 경우 제조사나 공급업체는
이 규정에 언급된 점검이 적절하게 이루어질
수 있도록 충분한 정보를 제공한다. 그러한
정보는 기밀로 취급된다.
3.5. 이 규정 제6조에 따른 소프트웨어 업데
이트 관리시스템 준수증명서
3.6. 승인될 차량형식의 차량 대리인은 승인
시험 수행을 담당하는 기술서비스기관에 제
출한다.
3.7. 문서는 두 부분으로 제공된다.
(a) 형식승인 신청서 제출 시 승인당국 또는
기술서비스기관에 제공되는 부속서 1에 명
시된 자료를 포함하는 승인을 위한 공식 문
서패키지. 이 문서패키지는 승인당국 또는
기술서비스기관에서 승인절차의 기본 참조로
사용된다. 승인당국 또는 그 기술서비스기관
은 차량형식의 생산이 완전히 중단된 시점부
터 계산하여 최소 10년 동안 이 문서패키지
가 사용 가능하도록 한다.
(b) 이 규정의 요건과 관련된 추가 자료는
제조사가 보관할 수 있으나 형식승인 시 검
사를 위하여 공개된다. 제조사는 형식승인
시 검사를 위하여 공개된 자료가 차량형식의
생산이 완전히 중단된 시점부터 계산하여 최
소 10년의 기간 동안 사용 가능하도록 보장
한다.
제4조(표시)
4.1. 이 규정에 따라 승인된 차량형식에 부
합하는 모든 차량에는 승인 양식에 명시된
눈에 잘 띄고 쉽게 접근할 수 있는 위치에
다음으로 구성된 국제 승인표시를 부착한다.
4.1.1. 문자 “E”를 둘러싼 원 뒤에 승인을
부여한 국가의 식별번호. 이 규정의 번호 뒤
에 제4.1.1항에 설명된 원의 오른쪽에 있는
줄표 및 승인 번호인 문자 “R”.
4.2. 차량이 이 규정에 따라 승인을 부여한
국가에서 협정에 부속된 하나 이상의 다른
규정에 따라 승인된 차량형식에 적합한 경우
제4.1.1항에 규정된 기호는 반복될 필요가
없다. 이 경우, 이 규정에 따라 승인을 부여
한 국가에서 승인이 부여된 모든 규정상 규
정, 승인 번호 및 추가 기호는 제4.1.1항에
규정된 기호의 오른쪽에 있는 세로 열에 배
치된다.
4.3. 승인표시는 명확하게 읽을 수 있고 지
워지지 아니하여야 한다.
4.4. 승인표시는 제조사가 부착한 차량 정보
기록판 위에 또는 그 가까이에 배치된다.
4.5. 이 규정의 부속서 3은 승인표시를 준비
하는 법에 관한 예시를 제공한다.
제5조(승인)
5.1. 승인당국은 이 규정의 요건을 충족하는
그러한 차량형식에만 소프트웨어 업데이트
절차 및 처리와 관련한 형식승인을 적절한
경우에 부여한다.
5.1.1. 승인당국 또는 기술서비스기관은 차
량 제조사가 문서화한 조치를 구현했는지 차
량형식의 차량을 시험하여 확인한다. 시험은
승인당국 또는 기술서비스기관이 자체적으로
또는 샘플링을 통하여 차량 제조사와 협력하
여 수행한다.
5.2. 이 규정에 따른 차량형식의 승인, 연장
또는 승인 거부 통지는 이 규정의 부속서 2
의 모델에 부합하는 양식을 통하여 이 규정
을 적용하는 1958년 협정 당사자에게 전달
한다.
5.3. 승인당국은 제조사가 이 규정의 적용을
받는 소프트웨어 업데이트 처리 측면을 적절
하게 관리하기 위한 만족스러운 준비 및 절
차를 마련했는지에 관한 보장 없이 형식승인
을 부여해서는 아니 된다.
제6조(소프트웨어 업데이트 관리시스템 준수
증명서)
6.1. 체약 당사자들은 제조사의 평가를 수행
하고 소프트웨어 업데이트 관리시스템에 준
수증명서를 발급할 승인당국을 지정한다.
6.2. 소프트웨어 업데이트 관리시스템 준수
증명서 신청서는 차량 제조사 또는 적법하게
공인된 대리인이 제출한다.
6.3. 이 신청서에 아래에 언급된 문서 3부와
다음 사항을 첨부한다.
6.3.1. 소프트웨어 업데이트 관리시스템을
설명하는 문서
6.3.2. 부속서 1의 부록 1에 정의된 모델을
활용하여 서명된 선언서
6.4. 평가의 맥락에서 제조사는 부속서 1의
부록 1에 정의된 모델을 활용하여 선언하고
이 규정에 따라 소프트웨어 업데이트에 관한
모든 요건을 준수하는 데 필요한 절차가 있
음을 승인당국 또는 기술서비스기관이 만족
할 정도로 입증한다.
6.5. 이 평가가 만족스럽게 완료되고 부속서
1의 부록 1에 정의된 모델에 따라 제조사로
부터 서명된 선언서를 수령하면 이 규정의
부속서 4에 설명된 소프트웨어 업데이트 관
리시스템 준수증명서라는 증명서가 제조사에
부여된다.
6.6. 소프트웨어 업데이트 관리시스템 준수
증명서는 철회되지 아니하는 한 증명서의 전
달일부터 최대 3년 동안 유효하다.
6.7. 소프트웨어 업데이트 관리시스템 준수
증명서를 부여한 승인당국은 언제든지 지속
적인 준수 여부를 확인할 수 있다. 소프트웨
어 업데이트 관리시스템 준수증명서는 이 규
정에 명시된 요건이 더 이상 충족되지 아니
하는 경우 철회될 수 있다.
6.8. 제조사는 소프트웨어 업데이트 관리시
스템 준수증명서의 관련성에 영향을 미칠 모
든 변경을 승인당국 또는 기술서비스기관에
알린다. 승인당국 또는 그 기술서비스기관은
제조사와 협의한 후 새로운 점검이 필요한지
여부를 결정한다.
6.9. 소프트웨어 업데이트 관리시스템 준수
증명서의 유효기간이 종료되면 승인당국은
긍정적인 평가 후 신규 소프트웨어 업데이트
관리시스템 준수증명서를 발급하거나 그 유
효기간을 추가로 3년 연장한다. 승인당국은
승인당국 또는 그 기술서비스기관에 변경이
알려지고 그 변경이 긍정적으로 재평가된 경
우 신규 증명서를 발급한다.
6.10. 기존 차량형식승인은 제조사의 소프트
웨어 업데이트 관리시스템 준수증명서의 만
료로 인하여 효력을 잃지 아니한다.
제7조(일반 설명서)
7.1. 차량 제조사의 소프트웨어 업데이트 관
리시스템 요건
7.1.1. 초기 평가에서 검증해야 할 절차
7.1.1.1. 이 규정과 관련된 정보가 문서화되
고 차량 제조사에서 안전하게 보관되며 요청
시 승인당국 또는 그 기술서비스기관에 제공
될 수 있는 절차
7.1.1.2. 무결성 검증 데이터 및 형식승인 시
스템의 관련 하드웨어 구성요소를 포함하여
모든 초기 및 업데이트된 소프트웨어 버전에
관한 정보를 고유하게 식별할 수 있는 절차
7.1.1.3. RX 소프트웨어 식별번호가 있는 차
량형식에 대하여 업데이트 전후 차량형식의
RX 소프트웨어 식별번호에 관한 정보에 접
근하고 업데이트할 수 있는 절차. 이에는 각
RX 소프트웨어 식별번호에 관한 모든 관련
소프트웨어의 소프트웨어 버전 및 무결성 검
증 데이터에 관한 정보를 업데이트하는 기능
이 포함된다.
7.1.1.4. RX 소프트웨어 식별번호가 있는 차
량형식에 대하여 차량 제조사가 형식승인 시
스템의 구성요소에 있는 소프트웨어 버전이
관련 RX 소프트웨어 식별번호에 정의된 버
전과 부합하는지 확인할 수 있는 절차
7.1.1.5. 업데이트된 시스템과 다른 시스템의
상호의존성을 식별할 수 있는 절차
7.1.1.6. 차량 제조사가 소프트웨어 업데이트
를 위한 목표 차량을 식별할 수 있는 절차
7.1.1.7. 발행되기 전에 목표 차량 구성과 소
프트웨어 업데이트의 호환성을 확인하는 절
차. 이 절차에는 발행되기 전에 업데이트와
의 호환성을 위하여 목표 차량의 가장 최근
에 알려진 소프트웨어 및 하드웨어 구성에
관한 평가가 포함된다.
7.1.1.8. 소프트웨어 업데이트가 형식승인 시
스템에 영향을 미치는지 여부를 평가, 식별
및 기록하는 절차. 이는 업데이트가 영향을
미칠 수 있는 시스템을 정의하는 데 사용되
는 매개변수에 영향을 미치거나 변경하는지
여부 또는 해당 시스템을 형식승인하는 데
사용되는 매개변수를 변경할 수 있는지 여부
를 고려한다(관련 법률에 정의된 바와 같
다).
7.1.1.9. 차량이 형식승인되었을 때 소프트웨
어 업데이트가 존재하지 아니하였거나 활성
화되지 아니한 기능을 추가, 변경 또는 활성
화하는지 여부를 평가, 식별 및 기록하거나
법률 내에 정의된 다른 매개변수 또는 기능
을 변경 또는 비활성화하는 절차. 평가에는
다음에 대한 고려가 포함된다.
(a) 정보패키지의 항목이 수정되어야 할 것
이다.
(b) 시험 결과가 수정 후 더 이상 차량을
적용 대상으로 하지 아니한다.
(c) 차량의 기능에 대한 수정은 차량의 형식
승인에 영향을 미칠 것이다.
7.1.1.10. 소프트웨어 업데이트가 차량의 안
전하고 지속적인 운행에 필요한 다른 시스템
에 영향을 미치는지 또는 업데이트가 등록되
었을 때와 비교하여 차량의 기능을 추가하거
나 변경하는지를 평가, 식별 및 기록하는 절
차
7.1.1.11. 차량사용자가 업데이트에 관하여
알 수 있는 절차
7.1.1.12. 책임당국 또는 기술서비스기관이
이용 가능한 제7.1.2.3.항 및 제7.1.2.4.항에
따라 차량 제조사가 정보를 작성할 수 있는
절차. 이는 형식승인, 생산 적합성, 시장 감
시, 리콜 및 정기검사를 위한 것일 수 있다.
7.1.2. 차량 제조사는 주어진 차량형식에 적
용되는 각 업데이트에 대하여 다음의 정보를
기록하고 저장한다.
7.1.2.1. 소프트웨어 업데이트를 위하여 차량
제조사가 사용하는 절차 및 준수를 입증하는
데 사용되는 관련 표준을 설명하는 문서
7.1.2.2. 업데이트 전후의 관련 형식승인 시
스템의 구성을 설명하는 문서. 이에는 형식
승인 시스템의 하드웨어 및 소프트웨어(소프
트웨어 버전을 포함한다) 및 관련 차량이나
시스템 매개변수에 대한 고유 식별이 포함된
다.
7.1.2.3. 모든 RX 소프트웨어 식별번호에 대
하여 업데이트 전후 차량형식의 RX 소프트
웨어 식별번호와 관련된 모든 소프트웨어를
설명하는 감사 가능한 기록부가 있다. 이 기
록부는 각 RX 소프트웨어 식별번호의 모든
관련 소프트웨어에 대한 소프트웨어 버전 및
무결성 검증 데이터에 관한 정보를 포함한
다.
7.1.2.4. 업데이트를 위한 목표 차량을 열거
하고 업데이트와 해당 차량의 가장 최근에
알려진 구성 간의 호환성을 확인하는 문서
7.1.2.5. 해당 차량형식에 대한 모든 소프트
웨어 업데이트 문서
(a) 업데이트의 목적
(b) 업데이트가 영향을 미칠 수 있는 차량
의 시스템 또는 기능
(c) 형식승인을 받은 것(존재하는 경우)
(d) 적용 가능한 경우, 소프트웨어 업데이트
가 해당 형식승인 시스템의 관련 요건의 이
행에 영향을 미치는지 여부
(e) 소프트웨어 업데이트가 시스템 형식승
인 매개변수에 영향을 미치는지 여부
(f) 업데이트에 대한 승인이 승인기관으로부
터 요청되었는지 여부
(g) 업데이트 실행 방법 및 조건
(h) 소프트웨어 업데이트가 안전하고 빈틈
없이 수행될 것이라는 확인
(i) 소프트웨어 업데이트가 확인 및 검증절
차를 거치고 성공적으로 통과했다는 확인
7.1.3. 보안. 차량 제조사는 다음을 입증한
다.
7.1.3.1. 업데이트 절차가 개시되기 전에 조
작을 합리적으로 방지하기 위하여 소프트웨
어 업데이트 보호 목적상 사용할 절차
7.1.3.2. 사용된 업데이트 절차는 업데이트
전달 시스템의 개발을 포함하여 손상을 합리
적으로 방지하기 위하여 보호된다.
7.1.3.3. 차량에 사용되는 소프트웨어의 소프
트웨어 기능과 코드를 확인하고 검증하는 데
사용되는 절차가 적절하다.
7.1.4. 무선 소프트웨어 업데이트에 대한 추
가 요건
7.1.4.1. 차량 제조사는 무선 업데이트가 운
전 중에 수행되는 경우 안전에 영향을 미치
지 아니하는지 평가하는 데 사용할 처리 및
절차를 입증한다.
7.1.4.2. 차량 제조사는 무선 업데이트가 업
데이트 절차를 완료하기 위하여 특정한 숙련
되거나 복잡한 작업을 필요로 하는 경우(예:
프로그래밍 후 감지기 재보정), 해당 작업을
수행할 수 있는 숙련된 자가 있거나 해당 절
차를 제어하는 경우에만 업데이트를 진행될
수 있도록 보장하기 위하여 사용할 처리 및
절차를 입증한다.
7.2. 차량형식에 대한 요건
7.2.1. 소프트웨어 업데이트 요건
7.2.1.1. 소프트웨어 업데이트의 진정성과 무
결성은 손상을 합리적으로 방지하고 유효하
지 아니한 업데이트를 합리적으로 방지하기
위하여 보호된다.
7.2.1.2. 차량형식이 RX 소프트웨어 식별번
호를 사용하는 경우
7.2.1.2.1. 각 RX 소프트웨어 식별번호는 고
유하게 식별할 수 있다. 차량 제조사가 형식
승인 관련 소프트웨어를 수정했을 때 형식승
인 연장 또는 신규 형식승인으로 이어지는
경우 RX 소프트웨어 식별번호를 업데이트한
다.
7.2.1.2.2. 각 RX 소프트웨어 식별번호는 최
소한 표준 인터페이스(OBD 포트)에 의하여
전기통신인터페이스의 사용을 통한 표준화된
방식으로 쉽게 읽을 수 있다.
차량에 RX 소프트웨어 식별번호가 없는 경
우 제조사는 관련 형식승인과 연결된 차량
또는 단일 ECU의 소프트웨어 버전을 승인
당국에 선언한다. 이 선언은 선언된 소프트
웨어 버전이 업데이트될 때마다 갱신된다.
이러한 경우, 소프트웨어 버전은 최소한 표
준 인터페이스(OBD 포트)에 의하여 전기통
신인터페이스의 사용을 통한 표준화된 방식
으로 쉽게 읽을 수 있어야 한다.
7.2.1.2.3. 차량 제조사는 무단 수정으로부터
차량의 RX 소프트웨어 식별번호 및 소프트
웨어 버전을 보호한다. 형식승인 시 차량 제
조사가 선택한 RX 소프트웨어 식별번호 및
소프트웨어 버전의 무단 수정을 방지하기 위
하여 구현된 수단이 기밀로 제공된다.
7.2.2. 무선 업데이트에 대한 추가 요건
7.2.2.1. 차량에는 소프트웨어 업데이트와 관
련하여 다음의 기능이 있다.
7.2.2.1.1. 차량 제조사는 업데이트가 실패하
거나 중단된 경우 차량이 구버전으로 시스템
을 복원할 수 있는지 또는 업데이트가 실패
하거나 중단된 후 차량을 안전한 상태로 전
환할 수 있도록 보장한다.
7.2.2.1.2. 차량 제조사는 차량에 업데이트
절차를 완료할 수 있는 충분한 동력이 있는
경우에만 소프트웨어 업데이트가 실행될 수
있도록 보장한다(구버전으로의 가능한 복구
또는 차량을 안전한 상태로 전환하는 데 필
요한 것을 포함한다).
7.2.2.1.3. 업데이트 실행이 차량의 안전에
영향을 미칠 수 있는 경우, 차량 제조사는
업데이트가 안전하게 실행될 수 있는 방법을
입증한다. 이는 차량이 업데이트를 안전하게
실행할 수 있는 상태에 있음을 보장하는 기
술적 수단을 통하여 달성된다.
7.2.2.2. 차량 제조사는 업데이트가 실행되기
전에 차량사용자가 업데이트에 대해 알 수
있음을 입증한다. 이용 가능한 정보에는 다
음이 포함된다.
(a) 업데이트의 목적. 이에는 업데이트의 중
요도와 업데이트가 리콜을 목적으로 하는 경
우, 안전 및 보안 목적이 포함될 수 있다.
(b) 차량 기능에 대한 업데이트로 구현된
모든 변경
(c) 업데이트 실행 완료 예상 시간
(d) 업데이트 실행 중에 이용할 수 없는 모
든 차량 기능
(e) 차량사용자가 업데이트를 안전하게 실
행하는 데 도움이 될 수 있는 모든 지침
유사한 내용을 가진 업데이트 그룹의 경우
단일 정보가 그룹에 적용될 수 있다.
7.2.2.3. 운전 중 업데이트 실행이 안전하지
아니할 수 있는 상황에서 차량 제조사는 다
음을 보장할 방법을 입증한다.
(a) 업데이트 실행 중에는 차량을 운전할 수
없다.
(b) 운전자는 차량의 안전이나 성공적인 업
데이트 실행에 영향을 미칠 수 있는 차량의
기능을 사용할 수 없다.
7.2.2.4. 업데이트를 실행한 후 차량 제조사
는 다음을 구현하는 방법을 입증한다.
(a) 차량사용자는 업데이트의 성공(또는 실
패)을 알 수 있다.
(b) 차량사용자는 구현된 변경 및 사용 설
명서에 관한 관련 업데이트(적용 가능한 경
우)에 대해 알 수 있다.
7.2.2.5. 차량은 소프트웨어 업데이트가 실행
되기 전에 전제조건이 충족되도록 보장한다.
제8조(차량형식의 수정 및 연장)
8.1. 기술적 성능 및 이 규정에서 요구하는
문서에 영향을 미치는 차량형식의 모든 수정
은 승인을 부여한 승인당국에 통보된다. 그
러면 승인당국은 다음 중 어느 하나를 수행
할 수 있다.
8.1.1. 수정이 이전 형식승인의 요건 및 문
서를 여전히 준수하는지 고려한다.
8.1.2. 시험 수행을 담당하는 기술서비스기
관에 추가 시험 보고서를 요구한다.
8.1.3. 변경을 명시한 승인의 확인, 연장 또
는 거부는 이 규정의 부속서 2의 모델에 부
합하는 통신 양식을 통하여 전달된다. 승인
의 연장을 발행하는 승인당국은 그러한 연장
에 일련번호를 배정하고 이 규정의 부속서
2의 모델에 부합하는 통신 형식을 통하여
이 규정을 적용하는 1958년 협정의 다른 당
사자에게 알린다.
제9조(생산 적합성)
9.1. 생산 절차의 적합성은 다음의 요건과
함께 1958년 협정, 표
1(E/ECE/TRANS/505/개정 3)에 명시된 것
을 준수한다.
9.1.1. 승인 보유자는 생산 시험의 적합성
결과를 기록하고 승인당국 또는 그 기술서비
스기관과 합의하여 결정한 기간 동안 부속
문서를 이용할 수 있도록 보장한다. 이 기간
은 생산이 완전히 중단된 날부터 계산하여
10년을 초과할 수 없다.
9.1.2. 형식승인을 받은 승인당국은 언제든
지 각 생산시설에 적용되는 적합성 관리방법
을 확인할 수 있다. 이러한 검증의 일반적인
빈도는 3년에 1회이다.
9.1.3. 승인당국 또는 그 기술서비스기관은
특히 차량 제조사가 업데이트에 대하여 승인
당국 또는 그 기술서비스기관에 알리지 아니
하기로 선택한 경우, 차량 제조사가 사용하
는 절차 및 내리는 결정이 규정을 준수하는
지 정기적으로 검증한다. 이는 샘플링 기준
으로 달성될 수 있다.
제10조(생산 부적합에 대한 처벌)
10.1. 이 규정에 따라 차량형식에 대하여 부
여된 승인은 이 규정에 명시된 요건이 준수
되지 아니하거나 샘플용 차량이 이 규정의
요건을 준수하지 아니하는 경우 철회될 수
있다.
10.2. 승인당국이 이전에 부여한 승인을 철
회하는 경우, 이 규정의 부속서 2의 모델에
부합하는 통신 양식을 통하여 이 규정을 적
용하는 체약 당사자에게 이를 즉시 통보한
다.
제11조(완전히 중단된 생산)
11.1. 승인 보유자가 이 규정에 따라 승인된
차량형식의 제조를 완전히 중단하는 경우 승
인을 부여한 당국에 이를 알린다. 해당 당국
은 관련 통신의 수령 시, “생산 중단”이라고
마지막에 큰 글자로 서명되고 날짜가 표시된
주석이 기재된 승인 양식의 사본을 통하여
이 규정을 적용하는 협정의 다른 체약 당사
자에게 알린다.
제12조(승인시험을 수행할 책임이 있는 기술
서비스기관 및 형식승인당국의 명칭과 주소)
12.1. 이 규정을 적용하는 협정의 체약 당사
자들은 승인시험을 수행할 책임이 있는 기술
서비스기관 및 승인을 부여하고 다른 국가에
서 발행된 승인, 연장, 승인 거부나 철회를
증명하는 양식을 발송하는 형식승인당국의
명칭과 주소를 국제연합 사무국에 전달한다.
부속서 1 정보 문서
다음의 정보는 적용 가능한 경우, 3부를 제
공하고 이에는 내용 목록을 포함시킨다. 모
든 도면은 A4 크기 또는 A4 형식의 폴더에
적절한 크기로 충분히 상세하게 제공한다.
사진이 존재하는 경우, 충분한 세부정보를
표시한다.
1. 제조(제조사의 상호):
2. 형식 및 일반적인 상업적 설명(형식은 승
인을 받아야 하는 형식, 상업적 설명은 승인
된 형식이 사용되는 제품을 말한다):
3. 차량에 표시된 경우, 형식 식별 수단:
4. 표시의 위치:
5. 차량의 카테고리:
6. 제조사/제조사 대리인의 이름 및 주소:
7. 조립공장의 이름 및 주소:
8. 대표 차량의 사진 및 도면:
9. 소프트웨어 업데이트
9.1. 차량형식의 일반적인 구성 특징:
9.2. 소프트웨어 업데이트 관리시스템 준수
증명서 번호:
9.3. 보안조치
9.3.1. 업데이트 절차가 안전하게 수행될 것
임을 설명하는 승인될 차량형식에 관한 문서
9.3.2. 차량의 RX 소프트웨어 식별번호가 무
단 조작으로부터 보호된다는 것을 설명하는
승인될 차량형식에 관한 문서
9.4. 무선 소프트웨어 업데이트
9.4.1. 업데이트 절차가 안전하게 수행될 것
임을 설명하는 승인될 차량형식에 관한 문서
9.4.2. 차량사용자가 실행 전후에 업데이트
에 관하여 알 수 있는 방법
부속서 1. 부록 1 소프트웨어 업데이
트 관리시스템 준수 선언 모델
소프트웨어 업데이트 관리시스템 요건
에 대한 제조사의 준수 선언
제조사명:
제조사 주소:
(제조사명)은 국제연합 규정 제156호 7.1에
규정된 소프트웨어 업데이트 관리시스템의
요건을 준수하는 데 필요한 절차가 설치되고
유지될 것임을 증명한다.
작성 장소: (장소)
날짜:
서명자 이름:
서명자의 기능:
(제조사 대리인의 날인 및 서명)
부속서 2 통신
(최대 형식: A4(210 x 297mm))
발급기관: 관리기관 이름:
그림1 (번역문)
관련: 국제연합 규정 제156호에 따른 차량
형식의 부여된 승인,
연장된 승인,
연도/월/일부터 효력이 있는 철회된 승인, 거
부된 승인,
완전히 중단된 생산
승인 번호:
연장 번호:
연장 사유:
1. 제조(제조사의 상호):
2. 형식 및 일반적인 상업적 설명
3. 차량에 표시된 경우, 형식 식별 수단:
3.1. 표시의 위치:
4. 차량의 카테고리:
5. 제조사/제조사 대리인의 이름 및 주소:
6. 생산공장의 명칭 및 주소
7. 소프트웨어 업데이트 관리시스템 준수증
명서 번호:
8. 포함된 무선 소프트웨어 업데이트(예/아
니오):
9. 시험 수행을 담당하는 기술서비스기관:
10. 시험 보고서의 날짜:
11. 시험 보고서의 번호:
12. 비고(존재하는 경우):
13. 장소:
14. 날짜:
15. 서명:
16. 요청 시 획득할 수 있는 승인당국에 제
출된 정보패키지에 대한 색인이 첨부되어 있
다.
부속서 3 승인표시의 준비
모델 A
(이 규정의 제4.2항을 참조한다).
그림2 (번역문)
a = 최소 8mm
차량에 부착된 위의 승인표시는 관련 도로
차량형식이 규정 제156호에 따라 그리고 승
인 번호 001234에 따라 네덜란드(E 4)에서
승인되었다는 것을 나타낸다. 승인 번호의
처음 두 자리는 승인이 이 규정의 요건에 따
라 원래의 형식(00)으로 부여되었다는 것을
나타낸다.
부속서 4 소프트웨어 업데이트 관리시
스템 준수증명서 견본
소프트웨어 업데이트 관리시스템 준수
증명서
국제연합 규정 제156호 관련
증명서 번호 [참조번호]
[승인당국]은
다음을 증명한다.
제조사:
제조사의 주소:
규정 번호 [이 규정]의 조항을 준수한다.
검증 수행 대상:
검증 수행 주체(승인당국의 이름과 주소):
보고서 번호:
이 증명서는 다음의 날짜까지 유효하다: [날
짜]
작성 장소: [장소]
작성 날짜: [날짜]
[서명]