WP.29 の要件と OTA システムに関する考慮事項

UNECE WP.29規制の重要性を説明するシリーズの3番目のブログ投稿へようこそ。追いついたばかりの方のために、規制を理解するための基礎はすでに整っています。 WP.29のブレイキング・ダウン 具体的な内容について議論しました WP.29 レギュレーションストラクチャ。

新しいWP.29自動車規制の2024年のコンプライアンス期限が間近に迫っているため、OEMとOTA（Over-the-Air）ソフトウェアプロバイダーは同様に、コンプライアンスを保証するための変更と新しいプロセスの導入を迫られています。そうしないと、車両承認の遅延、取引制限、法的責任など、莫大な経済的損失が発生する可能性があります。

規制要件を完全に遵守するには、製造業者は規制要件とは何か、その意味を理解し、承認機関に遵守証拠を提供する方法を理解する必要があります。この記事では、ソフトウェア更新管理システム (SUMS) に関する第 2 規制 R156 の WP.29 の主な要件について説明します。システムレベルとソフトウェアレベルの両方で、主要なプロセスと特定の要件について説明します。

情報セキュリティのベストプラクティス

新しいWP.29規制の下では、OEMは情報セキュリティシステムのベストプラクティスを活用する責任があります。言い換えると、自動車メーカーは、すべての関連文書が安全に保管され、その情報を保護するための適切なセキュリティ管理が実施されているという証拠を提供できなければなりません。従業員は、セキュリティ手順、文書化の慣行、および品質保証に関する集中的なトレーニングを受ける必要があります。

データ保護の観点から、すべてのサーバーは安全に保たれ、アクセスを規制および監視する必要があります。また、車両の流通が予定されている国の承認機関にデータをすぐに入手できるようにする必要があります。これに従わないと、生産や流通が遅れる可能性があります。WP.29規制のこの部分は、自動車業界ではまったく新しいものではありません。次のような他のコンプライアンスでも同様の手続きが義務付けられているからです。 ISO 27001 および SOC タイプ 2。

OEM には、OTA プロバイダーがこれらのベストプラクティスに従い、OTA ソフトウェアとデータストレージの慣行が地域の規制に準拠していることを保証および検証する必要があるという点で、OEM にはさらに責任があります。これは、規制や要件が異なる複数の市場に製品を販売するOEMにとって、すぐに問題になる可能性があります。たとえば、ヨーロッパで販売される製品は次の要件にも準拠する必要があります。 ティサックス (信頼できる情報セキュリティ評価交換)。

Sibrosのソリューションは、安全性、セキュリティ、およびデータプライバシーに関する複数の国際コンプライアンス基準に準拠しています。当社の品質管理システムは、すべての情報が、構成制御が施された安全なサーバー上でアクセス制御されるように構築されています。この方法の利点は、ソフトウェアの更新を管理する単一のシステムにアクセスできると同時に、各国の運営に必要なさまざまな安全、セキュリティ、データプライバシーの規制や基準にも対応できることです。

バージョンチェック

この次の要件では、ソフトウェアとシステムのバージョンに固有の識別子が必要です。この一意の識別子は、そのコンポーネントのソフトウェアに変更があった場合にのみ変更する必要があります。さらに、WP.29の論文で述べられているように、この固有の識別子は、電子通信や標準の診断インターフェースを使用しても容易に読み取れる必要があります。Body Control Module (BCM) のような個々のコンポーネントには、ブートローダー、キャリブレーション、アプリケーションなど、複数のファームウェアイメージが含まれている場合がありますが、それぞれのソフトウェアコンポーネントを一意に識別できるよう、すべてのコンポーネントに適切なバージョンが必要です。車両レベルパッケージは、車両ネットワークアーキテクチャの複雑さにもよりますが、20～80個以上のECUを含むすべての車載ECUパッケージをまとめたものです。

更新を実行する前に、ソフトウェアバージョンは、システムレベル、ソフトウェアレベル、およびハードウェアレベルで要件を確認する検証サイクルを受ける必要があります。これは、車両の更新中に発生する可能性のあるセキュリティハッキングを阻止し、特定するうえで非常に重要です。

バージョンチェックを実施することで、リスクが軽減され、ソフトウェア開発ライフサイクル中の進捗状況を追跡できるだけでなく、規制当局はコンポーネントで実行されているソフトウェアバージョンがOEMの定義と一致していることを確認できます。特定のプロセスと検証ツールに関する詳細を提供することで、この要件が満たされていることを証明できます。

SibrosのDeep Connectivity Platformは、コンポーネント上のファームウェアイメージが正しいイメージで更新されていることを確認し、すべてのバージョンIDを受け取るよう車両にリクエストを送信することで、この要件を簡素化します。システムは、最初に車両バージョンマニフェストを作成することですべてのプロセスを実行します。このマニフェストはファームウェアパッケージの一部であり、ECUバージョンとメタデータの集合です。この情報は、車両をECUごとに更新する必要があるかどうかを判断するためにも使用されます。障害が発生した場合、Sibrosは ディープアップデーター エラーを特定し、再試行してバージョンを再確認し、更新が成功したことを確認します。ソフトウェア更新プロセスのいずれかの時点で障害が発生した場合、車載ファームウェアは現在のソフトウェアバージョンに関する情報を含む詳細な導入ログをOEMにアップロードして、問題をさらにトラブルシューティングします。

ターゲット識別プロセス

多くの場合、ソフトウェアアップデートは特定のモデル群の一部の車両にのみ適用されます。フォードの 2020 年を例にとってみましょう。 LED ヘッドライトリコール 照明が明るすぎるF150トラックの217,185台のうち、同モデルイヤーの保有台数の約28％を占めています（フォードは2020年に78万7,000台のF150を販売しました）。WP.29 要件のこの部分では、OEM はソフトウェアアップデートの対象となる車両を特定できるプロセスを整備する必要があると規定されています。

対象を絞ったソフトウェアアップデートを展開できることは、さまざまな車両属性に基づいて特定のターゲットグループを作成できるため、OEMにとって間違いなく最も重要な機能の1つです。これらは、色、メーカー、モデル、トランスミッションタイプなどの静的属性でも、F150ヘッドライトのリコール例のような変数やデータ固有の属性に基づくものでもかまいません。Sibrosは、次のような点で他のOTAプロバイダーとの差別化を図っています。 ディープロガー 受信車両データを動的に分析し、ソフトウェアの更新が必要な場合にOEMに警告する製品。

F150ヘッドライトの例に戻ると、SibrosのDeep Loggerシステムは、すべての車両のデータを記録し、障害が発生した車両のみを特定できます。次に、影響を受けた車両の診断データを使用して、不具合を修正するために適切なソフトウェアパッケージの更新を必要とするターゲットグループを作成します。OEM がソフトウェアの開発、改良、テストを行い、適切な承認を受けると、Deep Updater システムは対象グループの車両のみにソフトウェアアップデートを送信します。

WP.29 SUMS規制のあらゆる側面と同様に、OEMはこの要件を順守していることの証拠を承認機関に提示する必要があります。Sibros OTAソリューションはこれらすべての要件を網羅しているため、OEMは固定的なターゲットグループの枠を超えて、ソフトウェアの問題を発生時に動的に評価して修正することができます。

安全保証メカニズム

いつでもどこでも更新できる携帯電話とは異なり、車両の更新は不適切に行うと大きな安全上のリスクが伴います。車両が道路を走っている間に更新が行われると、運転手、同乗者、その他の無実の傍観者の安全が危険にさらされる可能性があります。これは、自動車業界では時期尚早のケースですでに発生しています。 OTA アップデート 1人の運転手が混雑した高速道路で何時間も立ち往生していました。さらに、WP.29で述べたように、OEMはハザード分析とリスクアセスメント（HARA）に基づいて、失敗した更新を管理するための安全な状態を判断する必要があります（HARAの詳細については、ISO 26262のセクション6、第3章：コンセプトフェーズを参照してください）。安全状態は、たとえ車両の能力や機能が低下したとしても、以前のバージョンへのロールバックが不可能または望ましい場合に実装すべきです。

WP.29 SUMS規制の一部で、車両が危険な状態にあるときにソフトウェアの更新が行われないようにするフェイルセーフが義務付けられているのは当然のことです。これには、車両が使用中であることを認識することから、電力不足を解消すること、車両のテクノロジーが更新を受け入れることができることを確認することまで、あらゆることが含まれます。機能安全要件に関連するものはすべて、ISO 26262のさまざまな章の推奨事項に従い、安全分析を受ける必要があります。ソフトウェア更新管理システム (SUMS) のコンテキストでは、このような機能安全要件の一例として、ソフトウェアの更新が実行される前に車両が静止していなければならないことが挙げられます。

OTA システムは、アップデートを実施する前に特定の条件が満たされていることを確認できなければなりません。また、アップデートが失敗した場合には車両機能を回復させる必要があります。Sibrosのソフトウェアは、以下に概説されているように、すべての技術的安全ニーズを満たしていることを検証するために、故障分析を含む厳格な安全チェックを受けています。 ISO 26262 満たされています。

ソフトウェア更新管理システムへのSibrosソリューション

WP.29ソフトウェア更新管理システムの要件を理解することは、製品発売を成功させるための第一歩です。Sibrosと提携することで、Sibrosのディープ・コネクティビティ・プラットフォームを利用することで、貴社はWP.29のすべての要件をエビデンスに基づいた方法で遵守できるようになります。 

Sibrosのソリューションにより、OEMはコンプライアンス対応のOTAプラットフォームを利用できるだけでなく、安全で確実なロールアウトを実施するためのベストプラクティスに関するトレーニングやガイダンスも受けられます。これには、段階的ロールアウトの実施方法、安全関連条件の試験方法、試験責任の理解、安全前提の確立方法などが含まれます。

もっと詳しく知りたいですか？お問い合わせ ディープ・コネクティビティ・プラットフォームのデモンストレーションを行い、Sibrosがお客様の組織が自動車向けのWP.29システム要件を満たすのにどのように役立つかを理解してください ソフトウェア更新管理システム。