Software Update

SU型式審査マニュアル
2021年1月22日施行版
・UN Regulation No. 156 on uniform provisions concerning theapproval of vehicles with regards to software update and software
updates management system

審査エビデンスおよび審査方法について
CS/OTA国内採用WG
CS/SU規則検討小WG

CS/SU残課題検討小WG

1

Software Update

更新履歴• 2021年1月22日

2021年1月22日施行版として新規作成。

• 2022年4月5日

運用時の課題に対応した結果を反映し更新（本資料中、青文字斜体で反映を実施。）
modified：資料中変更が行われたページを示す。

insertion：資料中追加が行われたページを示す。

2

Software Update

CS/SU規則検討小WG参加団体• 独立行政法人 自動車技術総合機構交通安全環境研究所自動車認証審査部情報セキュリティ審査センター• 一般社団法人

日本自動車工業会

エレクトロニクス部会 電子プラットフォーム分科会、

ソフトウェア・OTA分科会、IＣＴ部会 サイバーセキュリティ分科会、安全環境法規認証部会 国内認証業務分科会• 日本自動車輸入組合• 一般社団法人

日本自動車部品工業会自動運転基準検討部会

3

本マニュアルについて

Software Update

本マニュアルは、 2021年1月22日より国内に直接引用されている“協定規則第156号の技術的な要件”およびその関係告示等の審査に関る提出書面および審査の手順
および手法について明確化を図るものである。

なお、本マニュアル活用に関しては以下を留意のこと。
・本マニュアルに示した方法は、エビデンスの一例であり、その方法を限定するものではない。他の試験方法や詳細な方法については、国交省および審査部と協議の上、決定することができる。
・適用する試験項目及び試験手順については、審査部と十分協議の上、決定することができる。
・本マニュアルで想定しない事例が生じた場合には国交省および審査部と協議の上、試験方法等決定することができる。

4

検討方針

Software Update
modified

１）目的
解釈文書を参照して、審査時に確認するエビデンスおよび審査方法の明確化を目的とする。
（UNでのテストフェーズにならい、法文解釈の一義化ではなくエビデンスの明確化による審査レベルの安定化も考慮する）
２）検討根拠は以下の基準等とする。

・協定規則第156号の技術的な要件
・解釈文書
WP29 GRVA以下のインフォーマルグループ（Task Force on Cyber Security andsoftware updates (CS/OTA)）にて作成され、WP29で承認された解釈文書（ECE-TRANS-WP29-GRVA-2020-29e.docx）

３）解釈文書の扱い
審査マニュアル各項の要件に応じた提出文書が提出されたことを確認したうえで、現地審査（インタビュー等）を含め総合的に基準への適合性を判断する。
5

ＳＵ 同一型式＆同一性能

分類
New Type

Software Update≪本内容は「7.2. 車両型式に関する要件」に係る。 ≫CSに合わせた定義

解釈

参考和訳

例示

Impact on type

Examples

SU機能への影響

変更内容

新たなE/Eアーキ E/Eアーキテクチャの開発に E/Eアーキテクチャの開発には、 新規のSU機能の搭載
・新規のE/Eアーキテクチャの採用
テクチャの開発
は、New Typeが必要
New Typeが必要
・従来のE/Eアーキテクチャに新規のSU経路を追加・SUに係わる新たなアーキテクチャーの採用
・GWを新設し、SU経路を増設
・Ethernet経路を新設しSUに使用
・OTA用通信回線の変更（４G→５G)
・新規のセキュリティ方式の採用
新規
追加

Extension サブシステムを追 既存のサブシステムの置き換 従前から有していた車載通信 従前SU機能の追加・変更
of existing 加、再配置による え、もしくは新たなサブシステ システムによるソフトウエア改変
・既指定と同じ技術を適用
type
SU機能のマイムを追加。これによりE/E
手法を他のECUに適用した・SUプロトコルに変更が無い
ナーな変更
アーキテクチャのSUに若干の変更が加えられるため、Type Extensionが必要

No impact

insertion

SU機能に変化なし

既存のサブシステムを置き換 改変可能なECUの廃止
えてもE/EアーキテクチャのSUが変わらないため、Type
Extensionは不要。これは通常の状況である。

SU機能に影響小・変化なし

・従来SU機能無し車にSU経路追加
・有線SUのE/EアーキテクチャにOTA経路追加
・経路追加と判断される接続ポートの変更･SU経路に新規の通信プロトコルを採用

適用整
理告示

新規
性能が
同一で
ない
追加

・Ethernetを用いた改変機能を他ECUに適用拡大・改変可能なECUの追加（車線維持制御ECU追加）

・通知手段の追加(通知内容:画面表示や文字数、同一手段における様変更
式の変更はNo impact）
・Preconditionの一部条件追加・削除･通信プロトコル規定内の選択仕様を採用

・改変可能なECUの廃止（車線維持制御ECU廃止）
変更
なし ・BCP対応の互換部品への切替え

変更
性能が
同一

廃止
切替

6

Software Update
modified

7.2.1.
Requirements for Software updates
ソフトウェア更新に関する要件
7.2.1.1.
The authenticity and integrity of software updates shall be protected to reasonably prevent theircompromise and reasonably prevent invalid updates.
ソフトウェア更新の危殆化を合理的に防止し、かつ無効な更新を合理的に防止するために、その真正性および完全性を保護するものとする。
解釈（UN解釈文書における要件の説明）

本要件は、有効なソフトウェア更新だけがダウンロードされ実行されることを保証するための、任意の車両型式で実施されているメカニズムに対処するものである。これは、例えばサインすることによって、更新の真正性および完全性を車両が検証することを要求するものである。7.1.3.1項および7.1.3.2項に記載するプロセスとともに、これによって、作成から提供、実行までのソフトウェア更新のエンドツーエンドシステムがセキュアであることが保証されるはずである。

具体的な書面のイメージ・認証され整合性チェックが行われたソフトウェア更新のみが車両で実行されることを保証するために使用されるメカニズムの概要の説明。（認証システム全体が把握できる程度の資料でよい）
・当該メカニズムについて開発時における試験方法の概要および試験結果の概要。
鍵認証され整合性チェックを行う
ロジックを意味する・サイバーセキュリティ（UNR-155）側で説明し、それを引用してもよい。

7

Software Update判断の目安（WP29解釈文書より引用）
7.2.1.1.
Explanation of the requirement
This requirement addresses the mechanisms implemented on a given vehicle
type to ensure that only valid software updates are downloaded and executed.
This requires that updates authenticity and integrity are validated by thevehicle, for example by signing. Together with the processes described inparagraphs 7.1.3.1. and 7.1.3.2. this should ensure that the end to end system
for software updates, from creation through delivery to execution, is secure.

本要件は、有効なソフトウェア更新だけがダウンロードされ実行されることを保証するための、任意の車両型式で実施されているメカニズムに対処するものである。これは、例えばサインすることによって、更新の真正性および完全性を車両が検証することを要求するものである。7.1.3.1項および7.1.3.2項に記載するプロセスとともに、これによって、作成から提供、実行までのソフトウェア更新のエンドツーエンドシステ
ムがセキュアであることが保証されるはずである。

The following clarification should be noted‘Reasonably’ refers to the level of protection being foreseeable and based onstate of the art preventions「合理的に」とは、保護が予見可能で、かつ最先端の防止策に基づいているレベルを指す

Examples of documents/evidence that could be provided
Vehicle manufacturers should provide details of the mechanisms used toensure that only authenticated and integrity checked software updates are
executed on a vehicle. The results of authentication testing may be used as
evidence.
The cyber security regulation may be used as a reference.

車両メーカーは、認証され完全性が確認されたソフトウェア更新だけが、車両で実行されることを保証するために使用されるメカニズムの詳細を提供すべきものとする。
認証テストの結果を証拠として使用してもよい。
サイバーセキュリティ規則を参照として使用してもよい。

8

Software Update

7.2.1.2.
Where a vehicle type uses RXSWIN:
車両型式がRXSWINを使用する場合:
7.2.1.2.1.
Each RXSWIN shall be uniquely identifiable. When type approval relevant software is modified by thevehicle manufacturer, the RXSWIN shall be updated if it leads to a type approval extension or to a new
type approval.
各RXSWINは、固有に識別できるものとする。型式認可関連ソフトウェアが車両メーカにより改変されたとき、それにより型式認可の拡大または新たな型式認可が生じる場合には、RXSWINが更新されるものとする。

RxWIN関係は継続議論とする。

解釈（UN解釈文書における要件の説明）なし

2022/6月を目標とし記載内容を確定し改定する。

具体的な書面のイメージ

・RxSWINの仕様（桁数や各桁の意味合いなど）
・RxSWINが“一意”であることの確認結果。（プロセスと絡めての説明でも良い、重複を防ぐプロセスを用いて確認した結果等の説明）
・認可に影響があった場合に、どのように番号が変更されるかの説明。（プロセスと絡めての説明でも良い、どのプロセスを用いて番号を変更するのか等の説明）
・該当の車両型式のソフトウェアとRxSWINの関係一覧表→申請時点のもので良く当該型式に搭載した装置のExt.等でRxSWINが更新された場合でもSUDの再申請は不要と考えるため、ワイルドカードのような記載でも可？（要検討）※ソフトウェアとRxSWINの関係一覧表について、 RxSWINに紐づくソフトウエアを開示する粒度等も検討が必要。
・RxSWINの管理はOEM毎の解釈でよく、読み出し方を整合させればOKか？
・今後Egdeｺﾝﾋﾟｭｰﾃｨﾝｸﾞ化なども進むと予想され、車載機での厳重な管理ではなくバックエンド側での管理も視野に入れるべきか？
などを継続議論とする。

9

Software Update判断の目安（WP29解釈文書より引用）
7.2.1.2.1.

RxWIN関係は継続議論とする。
Examples of documents/evidence that could be provided
Vehicle manufacturers may provide:
Demonstration of how an RXSWIN is generated for a given vehicle type andmade unique
Demonstration that each RXSWIN has a one on one relation with its
appropriate Regulation and how the regulation can be identified

車両メーカーは、以下を提供してもよい：
任意の車両型式についてRXSWINがどのように生成され、一意的になっているかの証明
各RXSWINが該当する規則と1対1の関係を有しており、当該規則をどのようにして特定することができるかの証明

2022/6月を目標とし記載内容を確定し
改定する

10

Software Update
modified

7.2.1.2.2.
Each RXSWIN shall be easily readable in a standardized way via the use of an electronic communicationinterface, 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 thevehicle or single ECUs with the connection to the relevant type approvals to the Approval Authority. Thisdeclaration shall be updated each time the declared software version(s) is updated. In this case, thesoftware 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).
各RXSWINは電子通信インターフェースの使用による標準化された方法で、少なくとも標準インターフェース（OBDポート）を用いて、容易に読み込むことができるものとする。

RxWIN関係は継続議論とする。

2022/6月を目標とし記載内容を確定し改定する

RXSWINが車両上に保存されていない場合には、メーカーは、該当する型式認可との関連を有する当該車両または個々のECUのソフトウェアバージョンを、認可当局に申告するものとする。申告したソフトウェア
バージョンが更新される都度、この申告を更新するものとする。この場合、ソフトウェアバージョンは、電子通信インターフェースの使用による標準化された方法で、少なくとも標準インターフェース（OBDポート）を用いて、容易に読み込むことができるものとする。
解釈（UN解釈文書における要件の説明）

本要件は、RXSWINを車両から読むことができるように、RXSWINが車両に保管されていること、あるいは車両に保管されていない場合には、RXSWINに関連するソフトウェアバージョンが車両に保管され、RXSWINへのリンクが申告されていることを要求するものである。

11

Software Update
modified

具体的な書面のイメージ
OBD以外を使用の場合は事前に審査部と協議のこと。

RxWIN関係は継続議論とする。

以下の内容を網羅した書面の提出および実車での試験による。
・読み出せるI/Fおよびツールの仕様。（ツールおよび通信の概要）I/Fは原則としてOBDポートとする。
・読み出し手順。（既存のマニュアルでも良い）
・読み出した結果のサンプル（全てのコントローラに対する社内試験結果）
・実車によるデモ（立会い認証試験）
・読み出せるRxSWINもしくはソフトバージョンの仕様。（ Rxswinの場合7.2.1.2.1の説明で代えても良い）・バージョンを使用する場合は当該車料におけるソフトウエアバージョンのリスト。
・読み出せるバージョンはECU単位（ECU全体のソフトを包含したバージョン）でよい。

2022/6月を目標とし記載内容を確定し改定する※RxSWINが車外に保管される形態も想定される。車外保管の例は、次頁参照。

今後、車両のHMI等の他の手段を定義する場合は情報共有していく

12

Software Update

参考）

１．RxSWINの持ち方
UNR156の目的：ソフトウェアアップデート行為における法規適合性の保証(体制認可)及び、確認手法(車両認可)を定めるものであると考えている。

RxWIN関係は継続議論とする。

例１：RxSWINを車両からの情報を元にｻｰﾊﾞ経由で読み出せる方式

例2：RxSWINを車両を介して出力する方式
サーバーから出力されたRxSWINは車両をパススルーしてOBDから出力

2022/6月を目標とし記載内容を確定し改定する
・RxSWIN

・RxSWIN

OEM
・VIN
サーバー ・SW/HW構成情報

OEM
・VIN
サーバー ・SW/HW構成情報

・・・・・・・・・・・・

・Internet
・その他ネットワーク

一致性：OK
VIN：XXXXRxSWIN：XXX
SW：バージョン

４G,５G回線

OBDⅡ

OBDⅡ
VIN：XXXXRxSWIN：XXX

・VIN
・SWバージョン情報

・VIN
・RxSWIN
13

RxSWINフォーマット例

Software Update
insertion

#

分類

１

文字長

可変長とする。
ただし、個社として固定長を採用することを妨げない。
最大文字数は、 “254-Regulation Identification文字数”とする(Regulation IdentificationはISO 14229-1を参照のこと)

２

使用可能文字以下のアスキーコード。
・大文字小文字の英数字及びスペース
・右の記号_<>:+-#$%&()@*/?.
第１フィールド、第２フィールド、第Ｎフィールドでは、フィールド区切り文字は使用しない
第１フィールド、第２フィールド、第Ｎフィールドでは、スタートコード、エンドコードは使用しない

３

フィールドの区切り文字

マイナス記号”-”, 又はアンダーバー記号“_” ,又はスペース。
ただし、スペースをふたつ以上使用しないこと。
区切り文字にスペースを使用する場合には、第２フィールド直後の区切り文字をスペースとすること

４

第１フィールド

OEMを表すコードとする。 可変長。

最初の区切り文字の直前までの文字列。
５

第２フィールド

法規と紐付け可能なコード。可変長。
最初の区切り文字と２番目の区切り文字の間の文字列。

６

第３フィールド以降

個社の定義による

７

スタートコード、
エンドコードスタートコード（１文字）を第１フィールドの前に入れてもよい。
エンドコード（１文字）を最終フィールドの後にいれてもよい。
使用する場合にはスタートコードに左エルボ記号”<“, エンドコードに右エルボ記号”>”-

例

OEM-R079 2021-00001
又は、OEM-R079-2021-00001

注記）RxSWINフォーマットはOEM各社で定義でき、これは提出文書の記載参考例である

14

RxSWINデータイメージ例

insertion

Software Update・フォーマット例（ISO14229-1に則ってRxSWINを車両から出力する場合）の読出しデータイメージ・(a)(b)どちらも仕様に準拠(a) RxSWINにスペースをひとつ含む場合

6216 F1F816 1316 “OEM-R079 2021-00001”1316“OEM-R13H 2021-00012”・・・
ヘッダー
通信データ長RxSWINRxSWIN

通信データ長(b) RxSWINにスペースを含まない場合
6216 F1F816 1816 “R079 OEM-R079-2021-00001”1816“R13H OEM-R13H-2021-00012”・・・
法規関連コード
ヘッダー
通信データ長RxSWIN

法規関連コードRxSWIN

通信データ長注記）RxSWINフォーマットはOEM各社で定義でき、これは提出文書の記載参考例である

15

7.2.1.2.2の「実車によるデモ」の内容補足（立会認証）
具体的な書面のイメージ

Software Update
insertion

以下の内容を網羅した書面の提出および実車での試験による。
・読み出せるI/Fおよびツールの仕様。（ツールおよび通信の概要）I/Fは原則としてOBDポートとする。
OBD以外を使用の場合は事前・読み出し手順。（既存のマニュアルでも良い）に審査部と協議のこと。
・読み出した結果のサンプル（全てのコントローラに対する社内試験結果）
・実車によるデモ（立会い実機試験）
・読み出せるRxSWINもしくはソフトバージョンの仕様。（ Rxswinの場合7.2.1.2.1の説明で代えても良い）・バージョンを使用する場合は当該車両におけるソフトウエアバージョンのリスト。
・読み出せるバージョンはECU単位（ECU全体のソフトを包含したバージョン）でよい。
実機試験

・試験選定
実機試験に先立ち試験対象自動車の選択について、選定案及び事由を読み出しRxSWINの保管場所や読み出しI/Fおよびツールの種類などから技術的に書面で説明し、合意のもと審査を行う。
・実機試験
RxSWINが車両に保存されている場合
・標準インターフェース（OBDポート）を用いて、RXSWINを読み込めることを確認する。
読み込むRXSWINについては試験時に指定する。
RxSWINが車両外に保存されている場合
・標準インターフェース（OBDポート）を用いて、RXSWINに関係する全てのECUのソフトウェアバージョンを読み込める
ことを確認する。
16
対象のRXSWINについては試験時に指定する。

Software Update判断の目安（WP29解釈文書より引用）
7.2.1.2.2.
Explanation of the requirement
This requirement requires that the RXSWINs shall be stored on a vehicle, inorder for them to be read from it or that if it is not stored on the vehicle thatthe versions of software relevant to an RXSWIN should be stored on a vehicle
and the link to a RXSWIN be declared.

本要件は、RXSWINを車両から読むことができるように、RXSWINが車両に保管されていること、あるいは車両に保管されていない場合には、RXSWINに関連するソフト
ウェアバージョンが車両に保管され、RXSWINへのリンクが申告されていることを要求するものである。

Examples of documents/evidence that could be provided
The following standards and regulations may be relevant:(a) ISO14229/1;(b) (OBD port): ISO 14229;(c) UN Regulation No. 83.

以下の基準および規則が関連する場合がある：(a) ISO 14229/1、(b) （OBDポート）：ISO 14229、(c) UN規則No. 83。

17Software Update
modified

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.
車両メーカーは、車両上のRXSWINおよび／またはソフトウェアバージョンを不正な改変から保護するものとする。型式認可時には、車両メーカーによって選択されたRXSWINおよび／またはソフトウェアバージョ
ンを不正な改変から保護するための実施済み手段を機密情報として提供するものとする。

解釈（UN解釈文書における要件の説明）

本要件は、RXSWINのセキュリティに対処するものである。その意図は、公認された当事者だけがRXSWINを変更することができ、関連するソフトウェア更新が車両で実行された場合に限りこれが発生する、ということである。

具体的な書面のイメージ
・CSの範囲として改変保護が含まれているはずなので、CSMS適合証明書およびCS側型式指定審査結果における確認を基本とする。
（当該型式において改変保護が適用されているかを確認する）
・Rxswinおよびソフトウエアバージョンの格納場所の概要説明。
・当該型式において実装された対策についての概要説明。[但し、本説明については資料提示のみで提出は要しない]

コメント
書面の提出要否については機密性に鑑み個社で相談とする

18

（補足）ソフトアップデート システム構成図
Out-Car

Software Update
タイトル修正In-Car

センターインフラ③ECUリセット時
RxSWIN照合

ソフトデータセンター

認証マスター
R13SWIN情報
R79SWIN情報
RxxSWIN情報

情報連携
ECUソフト管理

認証サーバー・認証
・TCU連携

キ
ャ
リ
ア
回
線

ECU-1

TCU

車両製造工場
生産システム車両

sensor

生産設備

ECU-2
actuator

ECUソフト管理

CGW

ソフト書き込み
設備／ツールディーラーシステム

・
・
・

DLC

販売店・ディーラー

ECU-3

社内LAN

②ツールへ
読出し応答

ECU-n

ECUソフト管理
外部接続

サービスツール①ツールから
読出し要求
RxxSWIN

ゲートウェイECU

エンドポイントECU：データの経路（センター、生産、サービスの対象範囲 ⇒ 車両の電子制御システムに直接つながる範囲）

19

Software Update判断の目安（WP29解釈文書より引用）
7.2.1.2.3.
Explanation of the requirement
This requirement addresses the security of the RXSWIN. Its intention is that
only authorised parties may change the RXSWIN and that this only happens
when a relevant software update is executed on the vehicle.

本要件は、RXSWINのセキュリティに対処するものである。その意図は、公認された当事者だけがRXSWINを変更することができ、関連するソフトウェア更新が車両で実行された場合に限りこれが発生する、ということである。

Examples of documents/evidence that could be provided
The manufacturer may describe where/how the RXSWINs are stored andwhat measures have been implemented to protect them against unauthorized
modification.

メーカーは、どこに／どのようにRXSWINが保管され、不正な変更から保護するためにどのような措置が実施されているかを記載してもよい。

20

Software Update
modified

7.2.2.
Additional Requirements for over the air updates
Over the Air更新に関する追加要件
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 afailed or interrupted update.
車両メーカーは、更新が失敗もしくは中断した場合に車両がシステムを以前のバージョンに復元することができること、または、更新の失敗もしくは中断後に車両を安全な状態に置くことができることを確保するも
のとする。

解釈

（UN解釈文書における要件の説明）

本要件の意図は、車両型式が失敗した更新を管理することができることを保証することである。
以前のバージョンに戻ることが不可能である、または好ましくない場合は、安全な状態を実施すべきものとする。これは、車両の能力または機能性の低減を含む場合がある。メーカーは、安全な状態とはどういうものである可能性があるかを決めるべきものとする。

21

Software Update

具体的な書面のイメージ
・OTA手順の概要説明
車両側でOTAを実施する場合の手順説明であり、バックエンド等まで含む必要は無い。
・更新失敗または中断が想定されるケーススタディ
電源断、キャリア圏外、ECU故障など設計的に想定しているケースを説明する。
・フェールリカバリ仕様の概要説明
更新が失敗または中断した場合に、7.2.2.1.1（改変前or安全状態）の状態とするためのロジックの説明。
ECU故障で更新が失敗または中断した場合には、安全状態とするロジックを説明すれば良い。
・実車でのデモ（原則上記で説明された中断が想定される全てのケースについて）
ただし、実際の認証試験でどの項目を立会い試験の対象とするかは申請時の試験選定で決定する。

22

実車デモ 7.2.2.1.1更新の中断、失敗
OTAデータセンタ

・車両状態
・ﾊｰﾄﾞID・ｿﾌﾄID・表示/操作（ソフト配信）・車両状態
・更新ﾊﾟﾀｰﾝ・ｿﾌﾄ管理

①

②

対象
車両
確認

対象
部品
確認

ﾀﾞｳﾝﾛｰﾄﾞ

ｱｯﾌﾟﾛｰﾄﾞ

③

④

更新
要求

更新
承諾

センタからクルマに・対象車両（VIN)
・対象ECU
・対象ソフトなど情報確認実施

停車中にユーザーがナビ画面(例)などで・変更内容
・承諾/拒否など確認実施更新があれば通知

承諾後更新を要求

センタ～クルマ〇△□ECU

センタ～ユーザー⑤
D/L
開始

Software Update

・OTAはコネクテッドサービスが前提。
センタとクルマは常時セキュアな通信環境でつながっています。
・ソフトの改竄、成りすまし検出は
電子証明書などで確実に実施します

⑥

⑦

⑧

ｲﾝｽﾄｰﾙ
開始

更新
ｿﾌﾄの
チェック

停車時
ｱｸﾃｨ
ﾍﾞｰﾄ

走行中のバックグラウンド処理を利用
・更新プログラムをﾀﾞｳﾝﾛｰﾄﾞ(D/L)
・対象ECUへのインストール（上書き更新ではD/Lまで）など、新ソフトの切替え手前まで準備

センタ～クルマ(ECU)

タイトル修正クレジット削除

⑨結果
通知
＋

ﾏﾆｭｱﾙ
更新

E/G OFF→ONで新ソフトに切替える

センタ～ユーザー【デモの手順】
・⑤から⑦のプロセスで、車両の電源をOFFにする
・一定時間経過後、再電源ONで再開(Resume）処理が始まるかを確認

23

Software Update判断の目安（WP29解釈文書より引用）
7.2.2.1.1.
Explanation of the requirement
The intention of this requirement is to ensure that vehicle types can manage
failed updates.
A safe state should be implemented when it is not possible or desirable toroll-back to a previous version. This may include reducing the capability orfunctionality of the vehicle. The manufacturer should determine what a safe
state may be.

本要件の意図は、車両型式が失敗した更新を管理することができることを保証することである。
以前のバージョンに戻ることが不可能である、または好ましくない場合は、安全な状態を実施すべきものとする。これは、車両の能力または機能性の低減を含む場合がある。メーカーは、安全な状態とはどういうものである可能性があるかを決めるべきものとする。

The following clarification should be noted‘Safe state’ may be interpreted as “an operating mode in case of a failure of
an item without an unreasonable level of risk” (using the definition provided
in ISO 26262)「安全な状態」は、「アイテムが失敗した場合に、不合理なリスクレベルを伴わない作動モード」（ISO 26262の定義を使用）と解釈してもよい

Examples of documents/evidence that could be provided
以下の基準および規則が関連する場合がある：
The following standards and regulations may be relevant:(a) 機能的安全性に関してISO 26262を使用してもよい(a) ISO 26262 may be used with regards functional safety
以下は、本要件が満たされているという保証の提供に関連する、あるいはその証拠とThe following may be relevant or evidenced to provide assurance that thisなる場合がある：
requirement is met:(a) 安全な状態の要件、(a) Requirements of the safe state;(b) 安全な状態を達成するために追加した／無効にした機能性。
(b) Functionalities added/ disabled to achieve the safe state.

24

Software Update
modified

7.2.2.1.2.
The vehicle manufacturer shall ensure that software updates can only be executed when the vehicle hasenough power to complete the update process (including that needed for a possible recovery to theprevious version or for the vehicle to be placed into a safe state).
車両メーカーは、更新プロセスを完了させるための十分な電力（生じ得る以前のバージョンへのリカバリに必要な電力、または車両を安全な状態に置くために必要な電力を含む）を車両が有しているときのみソフト
ウェア更新を実行できることを確保するものとする。
解釈（UN解釈文書における要件の説明）なし

具体的な書面のイメージ・プロセスを完了するのに十分な電力があるかどうかの判断方法（ロジック）を記載した書面。
（十分な電源確保については各社が型式認証の時に説明する。リスクがあれば、リスクに対する対策を各社で説明。）
・上記または、複数ケースによるデモ。（電力が十分な場合、不十分な場合、など）

25

実車デモ 7.2.2.1.2 電源管理
OTAデータセンタ

・車両状態
・ﾊｰﾄﾞID・ｿﾌﾄID・表示/操作（ソフト配信）・車両状態
・更新ﾊﾟﾀｰﾝ・ｿﾌﾄ管理

①

②

対象
車両
確認

対象
部品
確認

ﾀﾞｳﾝﾛｰﾄﾞ

ｱｯﾌﾟﾛｰﾄﾞ

③

④

更新
要求

更新
承諾

センタからクルマに・対象車両（VIN)
・対象ECU
・対象ソフトなど情報確認実施

停車中にユーザーがナビ画面(例)などで・変更内容
・承諾/拒否など確認実施更新があれば通知

承諾後更新を要求

センタ～クルマ〇△□ECU

センタ～ユーザー⑤
D/L
開始

Software Update
・OTAはコネクテッドサービスが前提。
センタとクルマは常時セキュアな通信環境でつながっています。
・ソフトの改竄、成りすまし検出は
電子証明書などで確実に実施します

⑥

⑦

⑧

ｲﾝｽﾄｰﾙ
開始

更新
ｿﾌﾄの
チェック

停車時
ｱｸﾃｨ
ﾍﾞｰﾄ

走行中のバックグラウンド処理を利用
・更新プログラムをﾀﾞｳﾝﾛｰﾄﾞ(D/L)
・対象ECUへのインストール（上書き更新ではD/Lまで）など、新ソフトの切替え手前まで準備

センタ～クルマ(ECU)

タイトル修正クレジット削除

⑨結果
通知
＋

ﾏﾆｭｱﾙ
更新

E/G OFF→ONで新ソフトに切替える

センタ～ユーザー【デモの手順】
・①のプロセスで、車両の電源状態をモニタ、判定しているプロセスをデモする
・⑧のプロセスで保証電圧以下でアクティベートさせないガードロジックをデモする

26

Software Update判断の目安（WP29解釈文書より引用）
7.2.2.1.2.

Examples of documents/evidence that could be provided
Examples of documents/evidence that could be provided
The following may be used to provide assurance that this requirement is met:(a) Description of measures taken by the vehicle manufacturer;(b) Demonstration of requirements via documentation/presentation and/or
physical test.

本要件が満たされているという保証を提供するために以下を使用してもよい：(a) 車両メーカーが講じる措置の説明、(b) 文書／プレゼンテーションおよび／または物理テストを介した要件の証明。

27

Software Update
modified

7.2.2.1.3.
When the execution of an update may affect the safety of the vehicle, the vehicle manufacturer shalldemonstrate how the update will be executed safely. This shall be achieved through technical meansthat ensures the vehicle is in a state where the update can be executed safely.
更新の実行が車両の安全性に影響を及ぼす可能性があるとき、車両メーカーは、どのように更新が安全に実行されるかを証明するものとする。これは、車両が更新を安全に実行できる状態にあることが確保される技
術的手段により達成するものとする。
解釈（UN解釈文書における要件の説明）なし

具体的な書面のイメージ
1.改変の実行が車両の安全に影響を与える可能性があるかの検討書。
（可能性のある全てのOTAアップデートについて）
2.上記で安全に影響が有ると判断した場合、更新を安全に実施するためのプロセス（更新中に車両の安全状態を確保するためのロジック）
3. 2.で確認したプロセスに対する実車を使用したデモンストレーション。（立会い試験）

28

7.2.2.1.3 更新の安全性
OTAデータセンタ

・車両状態
・ﾊｰﾄﾞID・ｿﾌﾄID・表示/操作（ソフト配信）・車両状態
・更新ﾊﾟﾀｰﾝ・ｿﾌﾄ管理

①

②

対象
車両
確認

対象
部品
確認

ﾀﾞｳﾝﾛｰﾄﾞ

③

④

更新
要求

更新
承諾

センタからクルマに・対象車両（VIN)
・対象ECU
・対象ソフトなど情報確認実施

停車中にユーザーがナビ画面(例)などで・変更内容
・承諾/拒否など確認実施更新があれば通知

承諾後更新を要求

センタ～クルマ〇△□
ECU

ｱｯﾌﾟﾛｰﾄﾞ

センタ～ユーザー⑤
D/L
開始

Software Update
・OTAはコネクテッドサービスが前提。
センタとクルマは常時セキュアな通信環境でつながっています。
・ソフトの改竄、成りすまし検出は
電子証明書などで確実に実施します

⑥

⑦

⑧

ｲﾝｽﾄｰﾙ
開始

更新
ｿﾌﾄの
チェック

停車時
ｱｸﾃｨ
ﾍﾞｰﾄ

走行中のバックグラウンド処理を利用
・更新プログラムをﾀﾞｳﾝﾛｰﾄﾞ(D/L)
・対象ECUへのインストール（上書き更新ではD/Lまで）など、新ソフトの切替え手前まで準備

センタ～クルマ(ECU)

タイトル修正クレジット削除

⑨結果
通知
＋

ﾏﾆｭｱﾙ
更新

E/G OFF→ONで新ソフトに切替える

センタ～ユーザー【デモの手順】
・③④更新内容が車両の安全性に影響を与える場合の留意事項をユーザーへ通知、承諾を得ているか、確認
・例えば⑧アクティベート時は、車両（制御や機能）がプログラム切替に影響のない状態下であるか、のデモ。

29

Software Update判断の目安（WP29解釈文書より引用）
7.2.2.1.3.

No guidance included in this document with regards this requirement
-

-

30

Software Update
modified

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.
車両メーカーは、更新が実行される前に更新に関する情報を車両ユーザに知らせることができる
ことを証明するものとする。提供情報には、下記を含むものとする：(a) 更新の目的。これには、更新の重要度、ならびに更新がリコール目的、安全目的および／またはセキュリティ目的のためであるかどうかを含めることができる(b) 更新により車両機能に実施される変更(c) 更新の実行完了までの予測時間(d) 更新の実行中に利用できない可能性がある車両機能(e) 車両ユーザーが安全に更新を実行するのに役立つ可能性がある指示
類似のコンテンツを有する更新のグループの場合、1つのグループにつき１つの情報を提供してもよい。
31

Software Update

解釈（UN解釈文書における要件の説明）

本要件は、7.1.1.11項で要求されるプロセスと関連しているが、本要件は、Over the Air更新が提供される車両型式に関連している。その意図は、車両ユーザーが更新実行前に更新について通知を受け、更新を実行するかどうかを判断するために必要な情報を提供されることである（車両ユーザーはその法的権利を有し、かつ通知を受けることを希望しているという前提）。
車両ユーザーが、ソフトウェア更新について1回だけ認証を受ける選択肢が提供され、それを選択した場合に、当該ユーザーは更新の度に通知を受け取る必要はない。ただし、新規ユーザーへの車両の譲渡、または車両ユーザーの希望変更が可能であることを保証するために、これをどう管理するかを証明する必要がある場合がある。

具体的な書面のイメージ
・ユーザへの通知方法の概説。
どの通知手法を使って、更新のどのタイミングでどのような情報が提供されるかについて説明。
通知方法は車載HMIに限定しない。ただし、当該通知方法が確実に通知を出来るものとして型式申請時に引用するSUMSにて説明済であること。この際、当該デバイスは保安基準適合審査の対象外とする。ただし、型式審査にて通知を実証する際には当該デバイスを使用して実施のこと。
なお、使用者の許諾（承認）が前提。結果として、許諾を得たことを記録として残すプロセスが必要。型式ごと（各社ごとや各車両ごと）に許諾を得る方法が異なるため型式要件とする。
・ユーザへの通知のサンプル
実際に通知されるディスプレイ情報など。
・実車を使用したデモンストレーション。（立会い試験）32

実車デモ 7.2.2.２ 更新の通知
OTAデータセンタ

・車両状態
・ﾊｰﾄﾞID・ｿﾌﾄID・表示/操作（ソフト配信）・車両状態
・更新ﾊﾟﾀｰﾝ・ｿﾌﾄ管理

①

②

対象
車両
確認

対象
部品
確認

ﾀﾞｳﾝﾛｰﾄﾞ

ｱｯﾌﾟﾛｰﾄﾞ

③

④

更新
要求

更新
承諾

センタからクルマに・対象車両（VIN)
・対象ECU
・対象ソフトなど情報確認実施

停車中にユーザーがナビ画面(例)などで・変更内容
・承諾/拒否など確認実施更新があれば通知

承諾後更新を要求

センタ～クルマ〇△□ECU

センタ～ユーザー⑤
D/L
開始

Software Update

・OTAはコネクテッドサービスが前提。
センタとクルマは常時セキュアな通信環境でつながっています。
・ソフトの改竄、成りすまし検出は
電子証明書などで確実に実施します

⑥

⑦

⑧

ｲﾝｽﾄｰﾙ
開始

更新
ｿﾌﾄの
チェック

停車時
ｱｸﾃｨ
ﾍﾞｰﾄ

走行中のバックグラウンド処理を利用
・更新プログラムをﾀﾞｳﾝﾛｰﾄﾞ(D/L)
・対象ECUへのインストール（上書き更新ではD/Lまで）など、新ソフトの切替え手前まで準備

センタ～クルマ(ECU)

タイトル修正クレジット削除

⑨結果
通知
＋

ﾏﾆｭｱﾙ
更新

E/G OFF→ONで新ソフトに切替える

センタ～ユーザー【デモの手順】
・③④ユーザーへの更新内容の通知表示をデモし、下記の要件が表示されることを確認（更新目的、車両機能の変更点、予想される更新時間、更新時に制限される機能の有無、ユーザーに役立つ指示、等）33

Software Update判断の目安（WP29解釈文書より引用）
7.2.2.2.
Explanation of the requirement
This requirement is linked to the processes required under paragraph 7.1.1.11
but this requirement is linked to the vehicle type where over the air updates
are provided. The intention is that the vehicle user may be informed about
updates before they are executed and be provided with any information theyneed to decide whether or not to execute the update (assuming they have thelegal right to do so and wish to be informed).
If a vehicle user is provided the option for a onetime authorisation forsoftware updates, and opts for it, he need not be informed about every
update. How this is managed may still need to be demonstrated to ensure it
enables the transfer of a vehicle to a new user or a vehicle user to change
their preference.

本要件は、7.1.1.11項で要求されるプロセスと関連しているが、本要件は、Over the
Air更新が提供される車両型式に関連している。その意図は、車両ユーザーが更新実行
前に更新について通知を受け、更新を実行するかどうかを判断するために必要な情報を提供されることである（車両ユーザーはその法的権利を有し、かつ通知を受けることを希望しているという前提）。
車両ユーザーが、ソフトウェア更新について1回だけ認証を受ける選択肢が提供され、それを選択した場合に、当該ユーザーは更新の度に通知を受け取る必要はない。ただし、新規ユーザーへの車両の譲渡、または車両ユーザーの希望変更が可能であることを保証するために、これをどう管理するかを証明する必要がある場合がある。

Examples of documents/evidence that could be provided
車両メーカーは、各更新について、7.2.2.2項の要件による情報を詳述したリリース
The vehicle manufacturer could have release notes for each of the updates
ノートを有することができる。車両メーカーは、この情報をユーザーに対してどのよ
detailing the information from the requirement in paragraph 7.2.2.2. The
うに利用可能な状態にすることができるかを証明することができる。これは、以下を
vehicle manufacturer could demonstrate how this information may be made
含んでいてもよい：
available to the user. This may include:(a) 車両ユーザーがどのように通知を受けることができるかの説明、(a) Description of how the vehicle user is able to be informed;(b) 文書／プレゼンテーションおよび／または物理テストを介した証明。
(b) Demonstration via documentation/presentation and/or physical test.

34

Software Update
modified

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 safetyof the vehicle or the successful execution of the update.
運転中の更新実行が安全でない可能性がある状況において、車両メーカーは、下記をを示すものとする：(a) 更新の実行中には車両を運転できないことを確保するための方法(b) 車両の安全または更新の実行成功に影響を及ぼすと考えられる車両機能を運転者が使用できないことを確保するための方法。

解釈（UN解釈文書における要件の説明）なし

具体的な書面のイメージ
1.改変の実行が車両の安全に影響を与える可能性があるかの検討書。（可能性のある全てのOTAアップデートについて）
2.上記で安全に影響が有ると判断した場合、車両を運転不可能にする手法および更新に影響を及ぼす機能を停止する手法の説明。
3.実車を使用したデモンストレーション。（立会い試験）35

実車デモ 7.2.2.3 更新中の制約
OTAデータセンタ

・車両状態
・ﾊｰﾄﾞID・ｿﾌﾄID・表示/操作（ソフト配信）・車両状態
・更新ﾊﾟﾀｰﾝ・ｿﾌﾄ管理

①

②

対象
車両
確認

対象
部品
確認

ﾀﾞｳﾝﾛｰﾄﾞ

ｱｯﾌﾟﾛｰﾄﾞ

③

④

更新
要求

更新
承諾

センタからクルマに・対象車両（VIN)
・対象ECU
・対象ソフトなど情報確認実施

停車中にユーザーがナビ画面(例)などで・変更内容
・承諾/拒否など確認実施更新があれば通知

承諾後更新を要求

センタ～クルマ〇△□ECU

センタ～ユーザー⑤
D/L
開始

Software Update

・OTAはコネクテッドサービスが前提。
センタとクルマは常時セキュアな通信環境でつながっています。
・ソフトの改竄、成りすまし検出は
電子証明書などで確実に実施します

⑥

⑦

⑧

ｲﾝｽﾄｰﾙ
開始

更新
ｿﾌﾄの
チェック

停車時
ｱｸﾃｨ
ﾍﾞｰﾄ

走行中のバックグラウンド処理を利用
・更新プログラムをﾀﾞｳﾝﾛｰﾄﾞ(D/L)
・対象ECUへのインストール（上書き更新ではD/Lまで）など、新ソフトの切替え手前まで準備

センタ～クルマ(ECU)

タイトル修正クレジット削除

⑨結果
通知
＋

ﾏﾆｭｱﾙ
更新

E/G OFF→ONで新ソフトに切替える

センタ～ユーザー【デモの手順】
・②③④更新対象機能と影響範囲）から、制約を受ける機能の有無の通知と承諾、対処方法、及び影響する車両状態（駐車中、走行中、アクティベート時、等）が、ユーザーへ適切に通知され、承諾を得ていることを確認。

36

Software Update判断の目安（WP29解釈文書より引用）
7.2.2.3.

Examples of documents/evidence that could be provided
The following may be used to provide assurance that this requirement is met:(a) Demonstration of requirements via documentation/presentation and/or
physical test.

本要件が満たされているという保証を提供するために以下を使用してもよい：(a) 文書／プレゼンテーションおよび／または物理テストを介した要件の証明。

37

Software Update
modified

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 tothe user manual (if applicable).
更新の実行後、車両メーカーは、下記を実施するための方法を示すものとする：(a) 更新の成功（または失敗）について車両ユーザーに知らせることができる(b) 実施された変更およびユーザーマニュアルの関連更新（該当する場合）について車両ユーザーに知らせることができる。
解釈（UN解釈文書における要件の説明）なし

具体的な書面のイメージ

・Demonstrationの内容確認例①コンテンツの画面表示(sample表示)②特定ユースケースの画面遷移（ﾕｰｽｹｰｽは申請時の選定で決定）③規定ユースケースの画面遷移（例：更新通知~更新完了まで）

1.当該型式における改変の成功又は失敗を通知する方法の概説。（通知内容のサンプル提示を含む）
通知方法は車載HMIに限定しない。ただし、当該通知方法が確実に通知を出来るものとして型式申請時に引用するSUMSにて説明済
であること。この際、当該デバイスは保安基準適合審査の対象外とする。ただし、型式審査にて通知を実証する際には当該デバイスを使用して実施のこと。
2.取扱説明書の更新をユーザに伝える方法の概説。（通知内容のサンプル提示を含む）
複数の方式がある場合はその全てにおいて、1.及び2.を説明すること。
現車によるデモンストレーション（公式試験にて実施する）

38

実車デモ 7.2.2.4 更新結果の通知
OTAデータセンタ

・車両状態
・ﾊｰﾄﾞID・ｿﾌﾄID・表示/操作（ソフト配信）・車両状態
・更新ﾊﾟﾀｰﾝ・ｿﾌﾄ管理

①

②

対象
車両
確認

対象
部品
確認

ﾀﾞｳﾝﾛｰﾄﾞ

ｱｯﾌﾟﾛｰﾄﾞ

③

④

更新
要求

更新
承諾

センタからクルマに・対象車両（VIN)
・対象ECU
・対象ソフトなど情報確認実施

停車中にユーザーがナビ画面(例)などで・変更内容
・承諾/拒否など確認実施更新があれば通知

承諾後更新を要求

センタ～クルマ〇△□ECU

センタ～ユーザー⑤
D/L
開始

Software Update

・OTAはコネクテッドサービスが前提。
センタとクルマは常時セキュアな通信環境でつながっています。
・ソフトの改竄、成りすまし検出は
電子証明書などで確実に実施します

⑥

⑦

⑧

ｲﾝｽﾄｰﾙ
開始

更新
ｿﾌﾄの
チェック

停車時
ｱｸﾃｨ
ﾍﾞｰﾄ

走行中のバックグラウンド処理を利用
・更新プログラムをﾀﾞｳﾝﾛｰﾄﾞ(D/L)
・対象ECUへのインストール（上書き更新ではD/Lまで）など、新ソフトの切替え手前まで準備

センタ～クルマ(ECU)

タイトル修正クレジット削除

⑨結果
通知
＋

ﾏﾆｭｱﾙ
更新

E/G OFF→ONで新ソフトに切替える

センタ～ユーザー【デモの手順】
・⑨更新完了時に、更新結果（成功、失敗・・）、更新による変更/追記されるユーザーマニュアルの内容、更新未完了時のユーザーへの対処方法の提示、等が表示されることを確認

39

Software Update判断の目安（WP29解釈文書より引用）
7.2.2.4.

Examples of documents/evidence that could be provided
The following may be used to provide assurance that this requirement is met:(a) Demonstration of requirements via documentation/presentation and/or
physical test.

本要件が満たされているという保証を提供するために以下を使用してもよい：(a) 文書／プレゼンテーションおよび／または物理テストを介した要件の証明。

40

Software Update
modified

7.2.2.5.
The vehicle shall ensure that preconditions have to be met before the software update is executed.
車両は、ソフトウェア更新の実行前に必須条件が満たされなければならないことを確保するものとする。

解釈（UN解釈文書における要件の説明）

メーカーは、満たすべき前提条件を定義し、ソフトウェア更新が開始するときは常にかかる前提条件が満たされていることを確認すべきものとする。

具体的な書面のイメージ
１）アップデートを開始する前に確認する前提条件の概要説明。（少なくとも何をどのレベルで確認するか説明すること）
２）前提条件から外れた場合の対応についての概要説明。（アップデートを開始しない等）
３）２）の対応について実車での同一性確認。（説明の通りの機能となっているか）
補足
・前提条件は各OEMで定義できる。
・前提条件の説明には状態遷移図などでのSU状態遷移の説明を伴っても良い。

41

実車デモ 7.2.2.5 開始条件の確認
OTAデータセンタ

・車両状態
・ﾊｰﾄﾞID・ｿﾌﾄID・表示/操作（ソフト配信）・車両状態
・更新ﾊﾟﾀｰﾝ・ｿﾌﾄ管理

①

②

対象
車両
確認

対象
部品
確認

ﾀﾞｳﾝﾛｰﾄﾞ

ｱｯﾌﾟﾛｰﾄﾞ

③

④

更新
要求

更新
承諾

センタからクルマに・対象車両（VIN)
・対象ECU
・対象ソフトなど情報確認実施

停車中にユーザーがナビ画面(例)などで・変更内容
・承諾/拒否など確認実施更新があれば通知

承諾後更新を要求

センタ～クルマ〇△□ECU

センタ～ユーザー⑤
D/L
開始

Software Update

・OTAはコネクテッドサービスが前提。
センタとクルマは常時セキュアな通信環境でつながっています。
・ソフトの改竄、成りすまし検出は
電子証明書などで確実に実施します

⑥

⑦

⑧

ｲﾝｽﾄｰﾙ
開始

更新
ｿﾌﾄの
チェック

停車時
ｱｸﾃｨ
ﾍﾞｰﾄ

走行中のバックグラウンド処理を利用
・更新プログラムをﾀﾞｳﾝﾛｰﾄﾞ(D/L)
・対象ECUへのインストール（上書き更新ではD/Lまで）など、新ソフトの切替え手前まで準備

センタ～クルマ(ECU)

タイトル修正クレジット削除

⑨結果
通知
＋

ﾏﾆｭｱﾙ
更新

E/G OFF→ONで新ソフトに切替える

センタ～ユーザー【デモの手順】
・更新開始条件は、状態遷移図などを用い、車両の状態と関連する条件が、開始条件として成立するフローを確認
ex.ある条件が未成立時には、既定の開始が得られないことをデモ、等

42Software Update判断の目安（WP29解釈文書より引用）
7.2.2.5.
Explanation of the requirement
The manufacturer should define preconditions to be met and confirm thatthose preconditions are met whenever the software update starts.

メーカーは、満たすべき前提条件を定義し、ソフトウェア更新が開始するときは常にかかる前提条件が満たされていることを確認すべきものとする。

Examples of documents/evidence that could be provided
The following may be used to provide assurance that this requirement is met: 本要件が満たされているという保証を提供するために以下を使用してもよい：(a) 文書／プレゼンテーションおよび／または物理テストを介した要件の証明。
(a) Demonstration of requirements via documentation/presentation and/or
physical test

43