概要
車載エンターテインメント ソフトウェア、運転支援ソフトウェア、自動運転ソフトウェアのいずれであっても、ソフトウェアのサポートは自動車業界とユーザーに多大なメリットと利便性をもたらしてきました。ただし、機械部品の洗浄、潤滑、交換が必要なように、ソフトウェアにもメンテナンスが必要です。
OEM や Tier 1 サプライヤーは、エンジン オイルやタイミング チェーンの交換などの定期メンテナンスを容易にする自動車部品の選択には優れていますが、自動車用ソフトウェアとなると、どこから始めればよいのかわからない場合があります。ソフトウェアの機能はますます複雑になるため、現在選択されているソフトウェア アーキテクチャが適切でないと、数年後には高額なソフトウェア保守費用が必要になる可能性があります。したがって、OEM と Tier 1 サプライヤーは、車載ソフトウェア システムとソフトウェア アーキテクチャに注意を払い、ソフトウェア セキュリティ脆弱性パッチやソフトウェア アップグレードなど、ソフトウェアに必要な定期的なメンテナンスを考慮する必要があります。
この記事では、ソフトウェア デファインド ビークルに最先端の安全性およびセキュリティ ソリューションが確実に装備されるようにする方法について説明するとともに、OEM が次世代アプリケーションの開発に集中できるようにするだけでなく、オープンソース ソフトウェアを使用することの重要性についても説明します。消費者のニーズを満たすだけでなく、コストを管理することも重要です。
導入
ソフトウェアが自動車産業の U 字型軌道を定義する
ここ数年、車両の電動化と自動運転の分野は急速に進歩し、自動車業界が直面する主な課題は機械部品から電子システムや車載ソフトウェアへと移行しました。
以前は、自動車の設計段階で発生する問題は、多くの場合、機械部品に関連していました。機械部品の適切な供給を確保するために、OEM は多くの場合、自動車の生産終了後、交換部品を少なくとも 10 年間入手可能な状態に保つために、Tier 1 および Tier 2 サプライヤーと長期契約を締結します。自動車のメンテナンスが必要な場合、バリューチェーンの末端にある最終消費者は、自動車の耐用年数が終了するまで、間接的に Tier 1 および Tier 2 サプライヤーに部品代を支払います。
「ソフトウェア デファインド カー」が徐々に自動車業界の主要な開発トレンドになるにつれて、自動車設計プロセスで解決する必要がある問題のほとんどはソフトウェアに関連しており、最終消費者とより密接に関係しています。すべての車の所有者は、自分の車を安全に保ちながら最新の機能を楽しみたいと考えていますが、頻繁な安全機能のアップデートにお金を払う車の所有者はほとんどいません。
刻々と変化する市場の変化により、自動車業界は開発トレンドに追いつき、追いつく必要があります。これは、ルノーやフォルクスワーゲンなどの企業のソフトウェア エンジニアリング部門の驚くべき部門の拡大に見ることができます。
「2011年当時、ルノーとフォルクスワーゲンは社内にソフトウェアエンジニアを見つけることさえできませんでした。」 現在、これら2つの有名な自動車会社はそれぞれ大規模なソフトウェアエンジニアのチームを抱えています。
同時に、ベンダーは独自のソフトウェア エンジニアリング部門の設立に躍起になっています。世界初の自動車用溝付きタイヤを生産したドイツのコンチネンタルグループを例に挙げると、同社は2021年だけで社内開発ソフトウェアに3100万ユーロを投資する予定だ。コンチネンタル オートモーティブ テクノロジーの中核ビジネス ユニット (車両ネットワーキング テクノロジー (VNI)、自動運転および安全技術 (AMS) ビジネス ユニットに分かれる) の従業員数は約 89,000 人ですが、タイヤ ビジネス ユニットの従業員数は現在わずか約 57,000 人です。コンチネンタルも例外ではなく、ワイパー システムや照明システムのサプライヤーとして知られるヴァレオ グループや排気システムのサプライヤーとして知られるマレリも、電子ソリューションやソフトウェアの分野での専門的優位性を拡大するために同様の措置を講じています。
さまざまな企業が相次いで独自のソフトウェア部門を設立しているが、市場の期待と技術的難易度の上昇に伴うコストの高騰との間には大きなギャップがあることは認めざるをえない。
上記の考慮事項に基づくと、OEM にとっての課題は、ますます複雑化するシステムを導入し、システムの維持にかかる年間の経常コストをどのように制御するかということになります。
初期
データ時代における自動車アーキテクチャの再定義
自動車産業の現在の開発状況から、将来、自動車が処理する必要があるデータの量が 1 日あたり 10 メガバイトに達することは明らかです。車内の長距離センサーと近距離センサー (LiDAR やカメラなど) の両方があらゆる種類のデータを収集するようになり、センサーの数は増加します。
データ処理や演算を必要とする自動運転に加え、車載エンターテイメントシステムや拡張車両故障診断システム（車載自動診断システムOBD-IIによる故障診断をさらに強化）を車内に搭載。これら3つの車載システムはいずれも安定したデータ処理が求められます。
では、これらすべてのデータをクラウド サーバーにアップロードできますか? その可能性はほとんどありません。実際には、車載システムは、メイン データまたは集約データをクラウドにアップロードする前に、データの一部をローカルで処理します。
「1 日あたり数十ペタバイトのデータ処理能力を保証するには、自動車システムにコンピューティング エンジンを組み込む必要があります。」
その結果、アップロードする必要のあるデータの量が大幅に増加します。以前は、車両の電子制御ユニット (ECU) は、接続されているセンサーやアクチュエーターの近くに配置されることが多く、したがって、車内全体に広がっていました。現在、相手先ブランド製品製造業者 (OEM) は、電子制御ユニットの統合と統合を可能にし、イーサネットを使用してさまざまな電子制御ユニットを相互接続する「自動車電気電子アーキテクチャ」(EEA) に注目しています。この新しいアーキテクチャには、1 ～ 5 台の高性能コンピューター (HPC) も組み込まれています。
以下では、特にハードウェアとソフトウェアのメンテナンスの観点から、レガシー アーキテクチャから新しい EEA アーキテクチャへの移行による多くの影響について説明します。
出典: ルノー・日産アライアンス
複雑さの増大
ハードウェアの複雑さ
自動車分野では、電子ハードウェアの設計は、コンピューターのようにマザーボードにインストールされた中央処理装置 (CPU) や PCIe 拡張カードではなく、「システム オン チップ」(SoC) に基づいています。システム オン チップは、コンピューティング コンポーネントのすべてまたはほとんどを含む集積回路です。実際、自動車のシステム オン チップには通常、コンピューティング パフォーマンスと運転の安全性を確保するために複数の CPU が含まれています。これらの CPU には、デジタル信号処理 (DSP) ユニット、グラフィックス プロセッシング ユニット (GPU)、ビデオ アクセラレータ、画像処理ユニット (IPU)、および CAN バス インターフェイスが含まれます。言い換えれば、SoC は非常に複雑なシステムです。
出典: テキサス・インスツルメンツ TDA システムオンチップ
「ハードウェアはすでに非常に複雑になっており、ソフトウェアはハードウェアよりも複雑であるため、自動車メーカーは今後の課題を克服するためにより優れたソフトウェア能力を必要としています。」
自動車ハードウェアの開発を見ると、SoC の複雑さは依然として増大しており、まだ開発のピークに達していないことがわかります。実際、車載ハードウェアのパフォーマンスがまだテラフロップの範囲にないとしても、16 個の CPU コアを搭載したチップセットがすでに市場に存在しています。近い将来、自動車に 80 コア CPU、さらにはより優れたコンピューティング パフォーマンスを備えたマルチコア CPU が導入されることが予想されます。
ソフトウェアの複雑さとマイクロサービス
自動車業界は、「機械的に定義された自動車」から「ソフトウェアによって定義された自動車」に徐々に変化しつつあります。この流れに乗って車両開発サイクルも再構築され、車両開発のやり方や求められるスキルも総合的な転換点を迎えています。これらの変化により、業界にさらなる課題が生じています。この課題に対処するために、自動車メーカーは専門チームを拡大し、専門家の雇用と訓練に費用を惜しみませんでした。今のところ、人材のコストは依然として上昇傾向にあります。企業は専門人材を大規模に採用する一方で、会社の強固なソフトウェア戦略基盤を築くことができる有能な人材をどのように引き付けるかという別の課題に直面しています。もう 1 つのアプローチは、OEM とそのサプライヤーの既存の人材をトレーニングし、変化の波に乗るために必要な新しいスキルを教えることです。ただし、スキルを学ぶのは非常に簡単ですが、特にこの分野の発展が高度に成熟している場合、従業員の固有の考え方を再形成することは非常に困難です。
同時に、より複雑な機能に対する最終消費者の要求も徐々に高まっています。マッキンゼーが発表したデータによると、「過去 10 年間で、自動車業界における 1 つのソフトウェア プロジェクトの平均複雑さは 300% 増加しました。」航空機の F-35 やボーイング 787 ドリームライナーには、さらに多くの複雑さが含まれています。2025 年までに、自動車で実行されるコードの行数は 2 億行に達すると推定されており、L5 (完全自動) 自動運転システムの場合、コードの行数は 10 億行に達する可能性もあります。
以下は、自動車技術者協会 (SAE) によって定義された運転自動化レベルです。
自動車技術者協会 (SAE) による運転自動化レベルの分類
これに加えて、人工知能 (AI) または機械学習 (ML) アルゴリズムも、オンボード ソフトウェアの複雑さを大幅に増加させます。
出典: マッキンゼー
サイバーセキュリティの脅威
報告によると、1983 年に、ソフトウェアとインターネットの分野における最初の「ハッカー」であるケビン ポールセンが、インターネットの前身である Arpanet をハッキングしました。当時、車泥棒が車を盗むためには、窓を破り、ハンドルの下にあるワイヤーを接続する必要がありました。現在、車載ソフトウェアの急増により、自動車業界はサイバー犯罪に対してさらに脆弱になっています。
1983 年にドイツの BOSCH 社が CAN バスを発明しました。これは World Wide Web やインターネットよりも早く誕生しました。CAN バスは本質的にハッカーの攻撃に抵抗できないため、CAN バスが現代の自動車に組み込まれている場合、ハッカーにチャンスを与えてしまいます。ケビン・ポールソンのハッキング事件がインターネットの抜け穴を暴露したように、「ハッカーによるジープの遠隔ハイジャック事件」はカーナビゲーションシステムの多くのセキュリティリスクを暴露した。
2021 年に発表された世界の自動車セキュリティに関するレポートでは、「自動車業界にはすでに 110 件の一般的なセキュリティ脆弱性と危険性 (CVE) があり、2019 年には 24 件でしたが、2020 年だけでも 33 件あります。」と述べられています。ただし、すべてのセキュリティ脅威が安全であるわけではありません。 CVE に含まれています。前述のレポートでは、2020年8月に10社が開発した40のECUソフトウェアに300以上の脆弱性が発見されたことも指摘している。当局はセキュリティ侵害による経済的影響を注意深く調査しており、セキュリティの脅威を防ぐための規制を導入しています。
ISO/SAE 21434 規格は、道路車両の電気電子 (E/E) システム (コンポーネントとインターフェイスを含む) のコンセプト、製品開発、生産、運用、保守、廃止のすべての段階におけるサイバーセキュリティ リスク管理のエンジニアリング要件を指定しています。 」。さらに、国連は規則第 155 号「車両のサイバーセキュリティおよびサイバーセキュリティ管理システムの承認に関する統一規則」を採択しました。この規制では、「車両のサイバーセキュリティとサイバーセキュリティ管理システムの承認に関する統一規制」の概要が定められている。
国連規則 155 により、OEM とそのサプライヤーは、車両使用中のサイバー犯罪を防止および制限するために、ソフトウェア セキュリティ パッチまたは修正プログラムの開発に協力する必要があります。すべてのソフトウェア配信は、その目的が機能強化の導入、バグの修正、セキュリティ問題への対処のいずれであっても、車両にプッシュされる前にサイバーセキュリティ評価と正式な承認プロセスを通過する必要があります。
この義務と顧客の期待に応えるために、OEM と Tier 1 サプライヤーは車載ソフトウェアの複雑さを理解する必要があります。ソフトウェアの世界では、機能やサービスを実装する方法が 1 つだけであることは非常にまれです。ソフトウェア管理の複雑さを軽減することが、長期的なソフトウェア保守コストを削減する唯一の方法であるため、ソフトウェア アーキテクトは情報に基づいた意思決定を行う必要があります。
「課題は、ソフトウェア システムを提供することだけではなく、それを長期的に維持する方法です。自動車メーカーはこれに対して十分な準備ができていますか?」
しかし、サイバーセキュリティのリスクはソフトウェアに限定されず、場合によってはハードウェアもセキュリティの脆弱性を露呈する可能性があります。多くの製品で見つかった「メルトダウン」および「スペクター」のセキュリティ脆弱性がその強力な証拠です。ソフトウェアアーキテクトはソフトウェアのリスクを考慮しながら潜在的なハードウェアの脆弱性を予測する必要があるため、このようなセキュリティの脆弱性によりシステム設計がさらに複雑になることは明らかです。
セキュリティに関する考慮事項
自動車業界が直面している課題はシステムの複雑さだけではありません。先ほどサイバーセキュリティについてお話しました。実際、車載システムの安全性は乗客の安全を保証するものではないため、車両のサイバーセキュリティと安全性の保証は 2 つの別個のトピックです。車は、重量が 1 トンを超えることもあるモバイル デバイスです。車は、乗員の安全を保護するだけでなく、走行環境も保護する必要があります。
乗客がシートベルトを着用していない場合、最も高い安全率を備えた自動車であっても、乗客の安全を完全に保証することはできません。2 つの概念はまったく異なりますが、それらの関係は切り離すことができません。
前述の「ハッカーによるジープの遠隔ハイジャック事件」がこの点を証明しており、ハッカーが自動車ネットワークのセキュリティを破壊すると、乗客の個人の安全にも脅威を与えます。プリクラッシュ回避のために車に装備されるアクティブセーフティシステムが増えているため、これは特に考慮することが重要です。アクティブ セキュリティ システムは適切に機能するためにソフトウェアに依存しているため、サイバーセキュリティ攻撃に対して脆弱です。この目的を達成するために、自動車業界は機能安全 (FuSa) の概念を導入しました。これは、OEM とそのサプライヤーにフレームワークを提供することを目的としており、安全の概念がさまざまなプロセスに浸透し、概念、生産、配送、メンテナンスなどのプロセスの重心。
ISO 26262「道路車両の機能安全」は、量産道路車両に搭載される電気および/または電子システムの機能安全を制限および指定する国際安全規格です。ISO 26262 規格では、自動車の「機能安全 (FuSa)」を「電気および電子システムの故障による不当なリスクがないこと」と定義しています。
機能安全は、純粋なハードウェア システムの問題でも、純粋なソフトウェア システムの問題でもありません。それは、ハードウェア システムとソフトウェア システムの両方の特定の操作とプロセスが関与するシステム的な問題です。
ハードウェアセキュリティ
ハードウェアシステムに関しては、厳しい安全要件を満たすシステムオンチップ（SoC）と電子制御ユニット（ECU）を経て初めて車に搭載できます。ISO 26262規格では、自動車安全度水準（ASIL）を定義し、現在開発中のシステムの重要性に応じて各レベルに適用される要件とプロセスを整理しています。
たとえば、ASIL-B レベルを達成するには、自動車システムの単一点故障検出率が 90% 以上に達する必要があるのに対し、 ASIL-D レベルでは、単一点故障検出率がそれ以上に達する必要があります。 99％以上。同時に、ISO 26262規格では「単一点故障」の定義も定められ、「予測故障率」の計算方法も規定されています。この規格では、読者が自動車のシステムの安全性を完全に理解できるように、必要な重要な用語も定義し、対応する評価方法も提供しています。
ハードウェア故障率の予測
ISO 26262 規格には、電気的ストレス、トランジスタ故障、またはパッケージ故障の発生率を評価できる、半導体コンポーネントの故障率を評価するためのいくつかの手法が記載されています。これらの故障の種類とそれぞれの発生率は、主に回路の種類、実装技術、および湿度、温度、圧力、電磁干渉などの環境要因によって異なります。
ISO 26262 標準では、コンポーネントの予想される故障率と予想される信頼性も区別されます。さらに、この規格では、特殊な場合には、単一障害点が複数の個別コンポーネントに安全上のリスクを引き起こす可能性があると規定しています。この規格はさらに、関連する障害分析 (DFA) と関連する障害開始点 (DFI) の特定を通じて、これらのリスク シナリオに対処できることを明確にしています。
データ伝送障害検出
上記のセキュリティ要件を満たすために、半導体企業は多数のハードウェア検出メカニズムとソリューションを提案してきました。最も一般的なものは次のとおりです。
•パリティ コード:データ送信を検出する目的を達成するために、オンチップ通信フローに「パリティ ビット」を追加します。パリティビットは最も単純な誤り検出符号であり、検出方法は単純で、パリティビットが0の場合は送信符号数は偶数、パリティビットが1の場合は送信符号数は奇数となります。個人。受信側が偶数のコードを受信し、パリティ ビットの位置がわかっている場合は、それを削除して送信された番号を見つけることができます。このように、受信機が奇数のエンコーディングを取得した場合、それは送信中にデータ破損が発生したことを意味します。パリティ コードは伝送エラーを検出できますが、正しい情報を取得できないため、情報を再送信する必要があります。
•巡回冗長検査 (CRC) は、データ送信障害を検出するために使用されるもう 1 つのツールです。巡回冗長検査では、除算と剰余の原理を使用してエラーを検出します。指定されたサイズの残りをデータに追加し、受信側でデータが変更されたかどうかを確認します。メッセージを受信した後、受信側は CRC を含む部分に対して多項式除算を実行します。メッセージとともに受信した CRC は、受信したメッセージで計算された CRC と一致する必要があります。そうでない場合は、送信エラーがあることを意味します。
• 誤り訂正符号 (ECC) は、ハードウェアが損傷した場合でも元の情報を取得する方法を備えているため、パリティ チェックの強化されたソリューションです。誤り訂正符号には多くの種類があり、無線 5G 規格にも新しい誤り訂正符号メカニズムが含まれています。
目的は伝送の問題を検出し、伝送された元の情報を取得することですが、これらの検査技術では、情報とともに伝送するために追加のエンコードが必要です。これは実際のネットワーク帯域幅に直接影響し、時間の経過とともに減少します。各バイトの 1 ビットがエラー検出に使用され、7 ビットが実際のデータに使用される場合、帯域幅は 1/8、つまり 12.5% 減少します。
ただし、送信中断が発生する場合があります。転送の中断は、物理的な通信の中断が原因である可能性がありますが、多くの場合、プロセスが長時間ハングしすぎていることが原因で発生します。そこで、通信ロス量を検出するために「通信タイムアウト」を利用します。
ランタイムエラーを検出する
前述したように、ISO 26262 規格はトランジスタ レベルで発生する可能性のある問題をカバーしています。今日の半導体企業は、ハードウェア検査ツールを使用して正しい動作を検証することがよくあります。しかし、半導体企業はまた、安全コントローラを使用してシステム全体の障害情報を収集し、それを分析し、その障害情報をソフトウェア システムの上位レベルのアーキテクチャに渡します。
最近登場した、セキュリティ コンプライアンスを強化するための別の低コストのアプローチは、「組み込み自己テスト」(BIST) です。この方法は、半導体メーカーが製品の製造欠陥を特定し、品質検査プロセスを改善する方法を必要としていたために生まれました。これらの強化されたインシステムテスト機能を最大限に活用し、プロセッサが正常に動作している状態で使用することで、実行時の障害を効果的に特定することができます。
冗長性検出メカニズム
セキュリティ要件を満たすために、メーカーは通常、システムを二重化する方法を採用します。同じセキュリティ要件の下で、2 つのシステムを別々に実装すると、セキュリティはさらに向上します。
デュアル モジュラー冗長性 (DMR) およびトリプル モジュラー冗長性 (TMR) は、システムまたはシステム内の要素を 2 倍または 3 倍にし、これらのシステムまたはモジュールに同じ入力信号を提供し、出力信号を比較する一般的な方法を指します。
トリプルモジュール冗長性の原理は多数決であり、多数決の出力結果が最終出力となります。3 つのシステムのうち 2 つのシステムの出力結果が同じであれば、この結果が正しい出力結果となります。デュアルモジュールの場合、出力結果が矛盾する場合はシステムに異常が考えられます。
デュアル モジュラー冗長性 (DMR) とトリプル モジュラー冗長性 (TMR) は、モジュール レベル、チップ レベル、場合によってはシステム レベルなど、さまざまなハードウェア レベルで使用されます。
一部の SoC はデュアルコア ロックステップ機能をサポートしています。安全なハードウェア メカニズムはデュアル モジュール冗長性 (DMR) によって実装されており、2 つの同一の CPU コアに同一のソフトウェアを提供し、同じクロック サイクルを共有します。各クロック サイクルでは、2 つのコアの出力結果が一致しているかどうかをチェックするロジック コンパレータがあり、一致していない場合はエラーが報告されます。
ただし、高性能 CPU は通常、構造がより複雑で決定性が弱いため、デュアルコア ロックステップ方式の実際の効果は満足のいくものではない可能性があります。その結果、デュアルコア ロックステップに代わるより複雑な代替手段がいくつか登場しました。たとえば、「セーフティ アイランド」を使用して、高い安全性を維持する CPU コアで検査タスクを実行する方法などが挙げられます。また、デュアルコアロックステップ方式のもう一つの最適化方式として「CPUコアロックステップ」があります。
前述の障害検出技術が実際の通信帯域幅を削減するのと同様に、CPU 冗長技術も利用可能な独自の処理能力を消費します。デュアルコア ロックステップ方式またはその拡張方式では、システム オン チップの実効計算能力が 50% 削減されます (スプリット ロック方式を使用した場合、計算能力の削減はわずかに少なくなります)。さらに、このテクノロジは冗長性を追加する必要があるため、開発コストとハードウェア コストの増加にもつながります。
ソフトウェアセキュリティ
半導体企業は多くの場合、ハードウェアのセキュリティ コンプライアンスを確保するために特殊なソフトウェアの使用を必要とします。言い換えれば、一部のクラウドベース システムでは、ハードウェア セキュリティの章で説明した「組み込み自己テスト (BIST)」など、セキュリティの可能性を最大限に実現するために特定の機能をソフトウェアで実装する必要があります。
NXP Semiconductors が発売した S32 車載処理プラットフォームは、最も人気のある車載 SoC シリーズの 1 つです。
同社は、「S32 安全ソフトウェア アーキテクチャは、起動、運用、障害回復時の作業に関与している」と考えています。
出典: NXP S32 セキュア ソフトウェア アーキテクチャ
すべてのソフトウェアがセキュリティに準拠したソフトウェアであるわけではなく、すべてのソフトウェアがセキュリティ要件を満たしているわけでもありません。さらに、ソフトウェアの認定料金も高価です。したがって、電子制御ユニットの段階的な統合に伴い、同じ SoC または電子制御ユニットに異なる安全性重要レベルを組み込むことが徐々に業界のトレンドになってきました。この傾向により、コスト管理とパフォーマンスを最適化できます。車載インフォテインメント システム用の電子制御ユニットは興味深い例です。
現在、業界では、センターコンソール、計器クラスター、ヘッドアップディスプレイ、乗員監視機能を同じ電子制御ユニットに組み込むことが一般的になっています。組み合わせると、一部の表示要素と音声要素には他の要素よりも高いセキュリティ要件が必要になります。以下の図は、ECU 統合を可能にする主なソフトウェアを示しています。
さまざまなオプションの主な違いは、セキュリティ コンプライアンス機能がどこで処理されるかです。
• オプション a では、ハードウェアの分離は ASIL/安全性準拠のハイパーバイザーによって管理されます。
• オプション b では、SoC 内の 2 種類のコアを使用することでハードウェア分離が実現されます。たとえば、車両通信とセキュリティのニーズには 1 つまたはいくつかの ARM Cortex-M コアを使用し、ハイエンド コンピューティング機能には別の汎用コアのセットを使用します。
• オプション c では、ハードウェアの分離は SoC ではなくハードウェア レベルで行われます。2 つの異なる専用 SoC (1 つはセキュリティ用、もう 1 つは汎用) を使用してハードウェアの分離を実現します。
このようなアーキテクチャはソフトウェア開発の難易度を高めるだけでなく、複雑な統合やデバッグの課題も引き起こします。
AUTOSAR 適応プラットフォームをシステムに導入するなど、同様の方法または他の新しい方法を使用できます。これらは通常、特定の SoC に基づく最適化オプションであり、多くの場合、特定の機能には複雑さが伴います。
SoC のコンピューティング能力を拡大するために、ハードウェアの複雑さは今後も増大し続けます。これに加えて、セキュリティ要件によりシステムがさらに複雑になります。コンピューティング能力とセキュリティを単一のシステムオンチップに統合することは、ますます複雑になります。半導体企業は、対応する安全要件を満たすために、SoC のコストを増加させる必要があります。
同様に、システムが複雑になればなるほど、認証は難しくなり、コストも高くなります。価格の成長曲線は直線的になる可能性は低く、指数関数的になる可能性が高くなります。
ただし、セキュリティ コンプライアンスを確保するには、ソフトウェアへの追加投資が必要です。ISO 26262 標準では、システム開発プロセスが V 字型のライフサイクル モデルに従うことが求められています。これは、ソフトウェア開発者がまず顧客のニーズを把握し、次にそれらのニーズに基づいて機能を定義することを意味します。ソフトウェア開発者は、機能をハードウェア システムとソフトウェア システムに分解する必要があり、ソフトウェア システムは機能に細分化されます。さらに、特定のテスト プロセスを定義、作成、または再度有効にしてから、機能レベル、ソフトウェア レベル、ハードウェア レベル、システム レベルでテストを順番に実行する必要があります。このシステム開発アプローチには、コード レビュー、要件からの逸脱の検出、テストの実行、テスト カバレッジの測定など、ソフトウェアを実行するための一連のプロセスが伴います。
「自動車会社は、高額なソフトウェア保守コストが発生することを覚悟しなければなりません。」
ここで、ISO 26262 規格で定義された V 字型のライフサイクル モデルに従って、現在の自動車に埋め込まれている 1 億行のコードがすべて安全に準拠していると仮定します (これは当てはまりません)。 2025 年までに合計 2 億行のコードを作成するには、新たに 1 億行のコードを記述する必要があるでしょうか? 一緒に働くには何人のソフトウェア エンジニアが必要ですか?
現在 1 億行のコードが導入されているため、OEM と Tier 1 サプライヤーは、COCOMO またはその他の方法に基づいて 1 億行のコードを追加するコストを大まかに見積もることができるはずです。ただし、これは単なる推定コストであり、何らかの変更が生じる可能性があります。コストの変化で。
では、レベル 5 の自動運転システムを搭載した自動車の場合、10 億行のコードの推定作業負荷はどのくらいになるでしょうか? 同様に、コンテンツのほとんどが再利用できない場合、この規模のソフトウェアの仕様を作成し、実装し、テストするにはどれくらいの時間がかかるでしょうか?
オープンソースの使用が唯一の持続可能な方法であり、詳細については「推奨事項」セクションで説明します。
干渉を隔離する
前述したように、ハードウェア ECU の統合は大きなトレンドです。ほとんどの場合、これは、安全性が重要なコンポーネントと共通の処理コンポーネントを同じ電子制御ユニットに統合することを意味します。ただし、セキュリティ システムには「気を散らさない」機能が必要です。言い換えれば、システムがセーフティクリティカルなコンポーネントと非セーフティクリティカルなコンポーネントを組み合わせている場合（たとえば、同じECU内）、セーフティクリティカルではない環境がシステムの安全な部分に干渉して安全性を引き起こすことができないことを実証する必要があります。問題。
たとえば、スケジューラが破損しないこと、プロセスがシステムを終了できないこと、メモリ ヒープがバッファ オーバーフローに対して回復力があることを確認します。
CVE インシデントを調査した結果、CVE インシデントのほとんどはバックドア、メモリ オーバーフロー、ソフトウェア (またはハードウェア) コンポーネントの偶発的/意図的ではない動作に基づいていることがわかりました。したがって、CVE の焦点はセキュリティ上の脅威を強調することにあります。私たちは毎日新しい CVE 脆弱性を発見しています。ISO 26262 (「道路車両の機能安全」規格) に従って設計され、Automotive Spice (ソフトウェア プロセス改善および能力測定規格) プロセスに厳密に従っている場合でも、ASIL D レベルのリアルタイム オペレーティング システム (RTOS) にはセキュリティが備わっています。脆弱性。
しかし、いずれにせよ、保護がないということはセキュリティの欠如を意味し、これは誰もが同意する事実です。
ISO 26262 規格だけでは、自動車の安全性を確保するのに十分ではありません。既存の高度な技術要件によれば、ISO/PAS 21448 (「道路車両の期待される機能の安全性」規格) に従って、期待される機能の安全性 (SOTIF) をシステムの分析に組み込む必要があります。これも早急に解決する必要がある難しい問題です。
「システムが複雑になればなるほど、そのセキュリティ コンプライアンスを評価し実証することが難しくなります。」
提案
困難な問題やセキュリティ問題を解決する効果的な方法を見つける
この段階では、次の問題を解決できます。
• より多くの車両データをより速く処理
• ハードウェアの複雑さの増大による課題
• ソフトウェアのスプロール化問題
• サイバー脅威によってもたらされるさらなる課題
• ソフトウェアの長期メンテナンスの必要性
• ハードウェアとソフトウェアに対する個別または共通のセキュリティ要件
次に、航空電子工学、オープンソース ソフトウェア開発、その他の業界におけるこれらの課題に対処するためのベスト プラクティスの事例を検討します。
安全な汚染を制限する
私たちは、オープンソースの使用が持続可能な成長のための唯一の方法であることを証明しました。しかし、それは、自動車のニーズを満たすためにオープンソース ソフトウェアを変更することを期待すべきだという意味ではありません。たとえば、セキュリティ汚染とは、システムのより多くの部分がセキュリティ保護を必要とし始めることです。エンドユーザーのセキュリティを向上させるのではなく、市場投入までの時間を短縮することに重点を置くと、対応するアーキテクチャの研究を無視することになります。セキュリティ汚染により、オープンソース ソフトウェアの使いやすさが大幅に制限されます。
なぜなら、オープンソース ソフトウェアの大部分はセキュリティ要件を満たしておらず、満たすことができないからです。OEM にとって、各コンポーネントが ASIL D であることを要求するなど、システムのさまざまな部分に高い安全性コンプライアンス要件を課すことは、ASIL B システムを ASIL D にアップグレードするよりも簡単であるようです。ただし、これを行うと、複雑さとコストが増大するだけでなく、機能も低下します。たとえば、セキュリティ準拠のオペレーティング システムがサポートする機能は、より汎用的なオペレーティング システムよりも少なくなります。さらに、変更（CVE パッチなど）が行われるたびにセキュリティ評価が必要となるため、セキュリティと保護対策の遵守を同時に行うと、さらなる複雑さの増大につながります。
したがって、このようなシステムが車両に導入されると、運用コストが急速に増加する可能性があります。また、システム アーキテクチャは一度構成すると変更が困難になる場合があります。OEM にとって、コストの爆発を回避する唯一の方法は、システムの安全マージンを合理的に制御することです。
最近、自動運転と電子制御ユニットの統合により、安全要件が車載インフォテインメント システムなどの多くの車両コンポーネントに影響を与えています。
自動車会社は、安全汚染の回避に関して他業界の経験から学ぶことができます。たとえば、アビオニクス システム アーキテクチャでは、システムの安全性コンポーネントと安全性以外のコンポーネントの区別が明確に定義されています。たとえば、機内インフォテインメント システムは航空機の安全コンポーネントに干渉しません。一部の安全コンポーネントは非安全コンポーネントも制御できます。たとえば、船長のアナウンスで車載インフォテインメント システムを制御できます。
将来の電気および電子アーキテクチャに対する当社の提案は、セキュア チャネルと一般チャネルという 2 種類の通信チャネル (ECU ハードウェア レベルで) のサポートを検討することです。システム内の汎用コンポーネントは、セキュリティ準拠のコンポーネント (センサーまたはアクチュエーターにアクセスし、それらからステータスを読み取る) と対話でき、利用可能な場合は、クラウドネイティブ タイプのメッセージング システム (安全なコンポーネント) を使用して応答します。つまり、セキュリティが第一です。汎用コンポーネントがパラメータを設定したり、安全なコンポーネントを制御したりすることは禁止されるべきです。
ECU の安全コンポーネントと非安全コンポーネントを再構築することはお勧めできません。2 つの異なるタイプのシステムオンチップ (SoC)/中央処理装置 (CPU) が、同じ ECU 内の安全性と共通機能を担当することが提案されています (前述のオプション c) ハードウェアの分離に示されているように)。このようにして、すべてのハイ パフォーマンス コンピューティングまたはエッジ コンピューティング SoC/CPU を安全な通信チャネルに接続する必要がなくなるため、ハードウェアおよびソフトウェアの設計の複雑さが軽減されます。
マッキンゼーは、ハードウェアとソフトウェアが別々に調達されることで「調達の競争力が高まり、拡張が容易になり、ハードウェア側での競争を維持しながらアプリケーションソフトウェアのプラットフォームを標準化できる」と予想している。
このため、OEM と Tier 1 サプライヤーの次のステップは、それぞれハードウェアとソフトウェアのセキュリティ コンポーネントと汎用コンポーネントを調達することです。
ハードウェアのセキュリティ要件は、大規模な競争を妨げる参入障壁を生み出します。システム アーキテクチャ内の一部のハードウェア モジュール (HPC など) のセキュリティ要件を削除すると、競争が繰り返され、部品表 (BOM) コストが削減されます。
たとえば、半導体企業はこの機会を利用して、ASIL 認証なしで AEC-Q100 認定の CPU を自動車業界に提供する可能性があります。PC/サーバーと比較して大幅な価格上昇なしで、複数のコアを備えたより強力な CPU が登場することが期待できます。
現在、最終的に「安全なリアルタイム オペレーティング システム」で実行するために、Linux オペレーティング システムで作成されたプロトタイプをどれだけ再設計、移植、調整する必要があるでしょうか? ターゲット ハードウェア上ですぐに実行できる概念実証 (POC) が開発された場合、セキュリティ準拠のコンポーネントを汎用コンポーネントから区別することで、セキュリティ準拠の仮想化ソリューションの必要性が大幅に減り、カスタマイズされたオペレーティング システムの使用が増加することを想像してください ( Linux ベースかどうかに関係なく) セキュリティ標準を満たしていること。その時点で、OEM は Linux オペレーティング システムとオープン ソース ソフトウェアを使用できるようになります。安全なオペレーティング システムの使用と同様に、限られたドメインでセキュリティ要件を取得すると、リソースの使用が改善され、必要なセキュリティに精通したエンジニアの数が減ります。採用のプレッシャーも少なくなります。
オープンソースとLinuxオペレーティングシステムを採用
Facebook/Meta、Airbnb、Netflix (その他多くの企業) が成功したのは、Microsoft の Windows や Linux を独自の OS に置き換えようとしたからでしょうか、それともオープンソースを使用して顧客サービスに重点を置いたからでしょうか? 彼らは確かに自社のソフトウェア スタックに精通していますが、オープンソース コミュニティにすでに存在するものを再発明するためにエネルギーを浪費することはありません。バグを見つけた場合、またはオープンソース モジュールの拡張バージョンを開発した場合は、それをコミュニティにリリースします。これにより、モジュールの機能がアップストリームになり、より多くの人々に利益をもたらし、コミュニティ全体をメンテナンス プロセスに参加させることができます。これがオープンソースが改善され、進化する方法です。
OEM および Tier 1 サプライヤーには、Linux カーネルおよび拡張オープン ソース ソフトウェア パッケージの長期サポートとセキュリティ メンテナンスについて、商用 Linux ベンダーと協力することをお勧めします。これにより、ソフトウェア ソリューションに集中し、顧客のアプリケーション開発とサービスを通じて差別化を推進できるようになります。
同時に、車両はクラウドに接続されているため、OEM は Linux ディストリビュータと協力して、クラウド サーバー、エンジニア デスクトップ、および車載 Linux ソフトウェアのサポートを提供することを検討する必要があります。これにより、OEM は、複数のサプライヤー、複数の契約、複数の開発環境を管理する負担を軽減しながら、より低コストで高レベルのサポートを受けることができます。
次世代自動車アプリケーションの開発
ソフトウェア コード ベースの拡大は自動車業界に限ったものではありません。ソフトウェアの複雑さとますます多様化する機能の間のバランスを維持するために、IT 業界全体が静的でモノリシックなアプローチからマイクロサービスと高可用性ソフトウェア設計の採用に移行しています。
マイクロサービスのケース
マイクロサービスベースのアプリケーション アーキテクチャにより、単一のアプリケーションを、小規模で狭く定義された独立して展開可能なサービスのセットとして開発できます。各マイクロサービスは独自の個別のプロセスで実行され、軽量メカニズム (通常は HTTP アプリケーション プログラミング インターフェイス) と通信します。これらのサービスは特定のビジネス機能に焦点を当てており、完全に自動化されたメカニズムを使用して独立して展開されます。
例えとして、マイクロサービスへの移行を理解するために古い家を使用することができます。この移行は、この家のキッチンとリビングルームの間の壁を取り壊し、手作りのキャビネットを取り除いて大手ブランドのモジュール式システムに置き換え、家庭内 LAN とインターネット経由で通信するキッチン家電とテレビを追加するようなものです。家の外観は何も変わっておらず、内部にはキッチンとリビングルームがまだありますが、これらはよりモダンで、より快適で、さまざまな新しい機能が備わっています。
レガシー アプリケーションをリファクタリングするこのプロセスでは、レガシー コードの一部は他者 (コミュニティなど) によって保守されているため、通常はオープン ソース コードに置き換えられます。これは、コードを使用する人がすべてのメンテナンス コストを負担する必要がないことを意味します。 。さらに、オープン ソース コードは、置き換えられる従来のコードよりもユーザーの使用率が高く、より多くのケースをカバーします。つまり、信頼性も高くなります。
マイクロサービス アーキテクチャ モデルへの移行では、レガシー ソフトウェアの 70% (またはそれ以上) を同等のオープンソース ソフトウェアに置き換えることを目指す必要があります。こうすることで、重要な違いを生み出し、企業に付加価値を生み出す残りの 30% (またはそれ以下) のソフトウェアに取り組みを集中させることができます。
単一障害点に対処する方法
高可用性ソフトウェアは、単一障害点 (SPOF) を特定するように設計されています。SPOF はシステムの一部であり、機能が停止するとシステム全体の動作が停止します。たとえば、単発機はエンジンが故障すると離陸できませんが、双発の民間航空機は離陸中にエンジンの 1 つが故障しても離陸できます。マイクロサービス設計のアプリケーションを使用すると、SPOF を特定して排除することが容易になります。SPOF を排除するには、ミラーリング、負荷分散、レプリケーション、自己修復など、いくつかの方法があります。詳細に触れることはこの記事の目的ではありませんが、重要なのは、IT 業界は高可用性設計を使用してサーバーの耐障害性と 99.9% の稼働時間を確保しているということです。さらに、サーバーのメンテナンス、アップグレード、実験をシャットダウンせずにすぐに実行できます。車両は耐障害性があり、機能し、ほとんどの場合稼働時間が長いことが想定されているのではないでしょうか? 駐車場なしでアップグレードできるようにすべきではないでしょうか? IT業界で働く人たちは、この目標を立てるとき、闘志に満ち溢れています。しかし、これらの目標の実現は非常に有益であり、自動車産業にも適用されるべきです。
インターネットは安定しており、24 時間年中無休で動作していることがわかりました。これを実現するには、可用性の高いソフトウェアとマイクロサービスベースのアプリケーション アーキテクチャが重要な柱となります。データセンターで実行されるソフトウェアは、ハードウェアにほとんど依存しません。世界中の多くの場所に簡単に導入でき、切り替え時にアプリケーション/サービスを書き換えることなく、Amazon Web Services、Google Cloud Platform、Microsoft Azure などのパブリック クラウドでホストしたり、オンプレミスでホストしたりすることもできます。ホスト。これはその強みの 1 つにすぎません。
マイクロサービス アプリケーションはコンテナ化されたソフトウェアです。つまり、実行する必要があるものが含まれる「ボックス」(コンテナ) 内で実行されます。コンテナ化されたソフトウェアにはいくつかの利点があります。
• マイクロサービスに障害が発生した場合、マイクロサービスが実行されている環境またはコンテナの一部のみが影響を受け、システム全体がダウンすることはありません。
• マイクロサービスの実行をサポートするために、仮想ハードウェアおよびオペレーティング システム環境がコンテナ内に構成されます。
これにより、マイクロサービスを実際の物理ハードウェアから独立させるハードウェア抽象化が作成されます。
Web サイト、Web ゲーム、Web アプリはハードウェアに依存せず、画面サイズ、向き、グラフィック プロセッサ、Web カメラなどのハードウェア特性を備えた多くのデバイスで実行できます。
私たちは、組み込みのミッションクリティカルなソフトウェアにおいて、Snap パッケージはシステム全体の安定性を向上させながら (アプリケーションの単一機能の障害がシステム全体を危険にさらすことはない) 同時に、必要なハードウェア抽象化 (アプリケーションをハードウェアに依存しないものにする) を達成できると信じています。 .)。
Snap は、アプリケーションとそのすべての依存関係がバンドルされた統合であり、すべての主要な Linux ディストリビューション、さらには Snap サポートを統合するカスタム ディストリビューション上で変更を加えることなく実行できます。41 の Linux ディストリビューションにわたる数千の Snap が、すでに何百万もの人々によって使用されています。これには、新しいアプリケーションやパッチを作成および展開するためのチュートリアル、サポート資料、ツールが含まれています。OEM や Tier 1 サプライヤーも Snap を作成し、Linux を実行する新旧の ECU に展開する可能性があります。これらのスナップは、料金を支払ったりロックを解除したりすることなく、誰でも自分の Linux コンピューター (および IoT デバイス) で無料で使用できます。
Snap の優れた点の 1 つは、運用とアプリケーション管理にあります。実際、すぐに使えるセキュリティを保証するだけでなく、システムの完全性と信頼性を損なうことなくハードウェアの移植性を最大限に活用します。Snap はどの OEM でも簡単に導入でき、実行するデバイスに移植する必要はありません。
Ubuntu Core、完全なスナップベースのコンテナ化バージョン。Ubuntu Core は安全な設計になっており、AppArmor とセキュア コンピューティング モードを通じてセキュリティの分離が提供されます。また、TPM サポート、セキュア ブート、フルディスク暗号化も提供します。
Snap のセキュリティに対する総合的なアプローチにより、組み込みシステムはセキュリティ、不変性、モジュール性、および構成可能性の利点を提供します。ソフトウェアはデルタ経由で無線で更新でき、何か問題が発生した場合は (Linux オペレーティング システムから任意の単一アプリケーションまで) 自動的にロールバックされます。
自動車業界の CAN バスからイーサネットへの移行には 30 年以上かかりました (部分的にのみ)。自動車業界では耐故障システムの構築が必須であり、これを実現する方法は数多くあります。さらに、システムのサイバーセキュリティ保守は、費用対効果が高くなるよう設計する必要があります。ISO/SAE 21434 (「道路車両サイバーセキュリティ エンジニアリング」) サイバーセキュリティ規制の施行により、セキュリティ、保護対策、拡張性の観点から自動車のハードウェアとソフトウェアのアーキテクチャを再検討する適切な時期が来ています。
顧客中心
携帯電話のデザインや機能と比較すると、車載インフォテインメント システムは 4 年以上時代遅れになっています。
携帯電話と同じ機能を実現することは単なるマイルストーンであり、目標ではありません。自動車は携帯電話をはるかに超える機能（自動運転など）を開発できます。
ファームウェアまたはソフトウェアの無線 (FOTA/SOTA) アップグレードは最初のステップですが、画期的なものではありません。電話やコンピュータの関連分野で検討されてきました。問題は、このアップデートがエンドユーザーにどのようなメリットをもたらすかです。2 年前の機能や外観がそのままでは、お客様の失望を招く可能性があります。
OEM と Tier 1 サプライヤーは、携帯電話など他の業界のイノベーションに遅れを取らないように、ソフトウェアの開発と提供の速度を高める必要があります。さらに、自動車は最先端の消費財です。他の業界と同等であるだけでなく、より高い期待に応える可能性を秘めています。
OEM にとって、ソフトウェア開発コストは低くなり、市場投入までの時間が短縮される必要があります。ソフトウェアの主要な部分 (エンド顧客を満足させる部分とサードパーティのサービスをホストする部分) が安全でない環境でも実行できれば、これはすべて可能になります。同時に、ハードウェアの調達を容易にし（少なくとも安全でない環境で動作するハードウェアの場合）、自動車固有の SoC の使用を減らす必要があります。
このようにして、OEM は顧客とサードパーティのエコシステムに新しいサービスを提供できます。スマートフォンの成功の多くは、プラットフォーム (つまり、スマートフォンとそのアプリ ストア) によって提供されるサードパーティのアプリとサービスのエコシステムによるものです。
統合ソフトウェア会社の考え方
自動車業界はハードウェア デファインド カーからソフトウェア デファインド カーへの移行を模索していますが、両者の違いを理解することが重要です。
• ハードウェア設計は多くの場合コスト効率が高くなります。コストを 1 ドル削減するにはハードウェアを変更するにはどうすればよいでしょうか? デバイスごとに 1 ドル節約すると、100 万台のデバイスで 100 万ドルを節約できます。
• ソフトウェアにはスケーラビリティ要素が含まれることがよくあります。ソフトウェア ソリューションを何百万ものユーザーに対して機能させるにはどうすればよいでしょうか。ユーザーあたり月額 1 ドルを請求すると、100 万ドルの収益が得られます。
両者の間には本質的な違いがあります。
従来の自動車メーカーは、ハードウェア機器の部品表を徹底的に調査してきました。自動車は開発中に明確で詳細な仕様を必要とします。仕様要件を満たすために、メーカーは最もコスト効率の高いハードウェアを選択しました。最終的に、車両はこれらのハードウェアによってある程度制限され、この影響は車両のライフサイクル全体にわたって継続します。
Tesla などの企業は、より強力なハードウェア ソリューションを選択する傾向があります。しかし、それは彼らが BOM コストに注意を払っていないという意味ではありません。彼らは競争上の優位性の要素をより自由に検討できます。テスラは自動車機械システム内にゲームも導入しました。これらのゲームは、機内エンターテインメント デバイスのゲームを指すのではなく、自宅でゲーミング ラップトップを使用してプレイする必要があるゲームを指します。車載ゲームを提供できないでしょうか？そうではないかもしれませんが、それは質問の主旨ではありません。問題は、顧客がこの機能を知ったら満足するかということです。いずれにせよ、機能そのものよりも顧客満足度の方が重要だからです。
このようなハードウェアやシステム オン チップは高価ですが、新機能が毎年展開され、顧客を引き付けるさらなる利点も提供されます。繰り返しになりますが、顧客満足度が重要な推進力です。そして確かに、ほとんどの顧客は常に改良され続ける機能を備えた車を好むでしょう。そうすれば、定期的に新車を購入するような目新しさが得られます。実際、そのような選択をすると、ローエンド SoC ソリューションと比較して部品表コストが増加します。しかし、各 OEM は、複雑なドア形状を湾曲させたり、格納式リア スポイラーを追加したり、特定のホイール リムを使用したりするなど、製品を差別化し、それぞれのブランドの認識を確立するのに役立つ戦略的な選択を行っています。一部の OEM は、車載ハードウェアとソフトウェアのコンピューティング能力によって顧客満足度を効果的に向上できると考えています。
しかし、もう 1 つ興味深い要素があります。30 年前、メーカーは家庭用電子機器、携帯電話、または自動車を生産する際、製品の耐用年数全体にわたって電子ハードウェアを費やすことはありませんでした。しかし、これらのデバイスではソフトウェアが重要な役割を果たしているため、現在では状況が大きく異なります。現在、顧客は新しい製品機能が継続的に導入されることを期待しており、システムのセキュリティを維持する必要があるため、年間のソフトウェア関連費用が発生します。したがって、ハードウェアの部品表コストに加えて、電気および電子アーキテクチャの総所有コスト (TCO) も評価し、最適化する必要があります。システムの複雑さを軽減することが、保守コストを削減する鍵となります。
最後に、最小限の自動車適合性要件（たとえば、AEC-Q100 認定のみと CPU 側の製品可用性の拡大）を備えた既製のコンポーネント アーキテクチャに主に基づいて OEM を選択すると、調達不足にさらに対応しやすくなります。これはチップの点だけではありません。 、エンジニアリングと採用の分野でも。
将来の開発に備える
OEM メーカーは、数十年にわたり、優れた内燃エンジン製品、およびそれぞれのブランドのポジショニングとアイデンティティを作成するために努力してきましたが、最近では、状況が大きく異なっていることに気づきました。新しいブランドが誕生し、より速く、よりダイナミックな車が誕生しています。電気自動車は（テスラの時価総額と利益の点で）莫大な収益をあげています。こうした市場の変化に対応するため、同社はさまざまな取り組みを開始している。しかし、今日の決議を真に果たせるのは、将来、特定の分野に配備された車両を維持する必要がある場合のみです。私たちの推奨事項は、OEM とそのサプライヤーが持続可能な未来に向けて正しい決定を下せるように設計されています。