車両のソフトウェア デファインド化が進むにつれ、多くの OEM が組み込みソフトウェア スタックにオープンソース ソリューションを使用しています。
オープンソースは、柔軟性、迅速なプロトタイピング、コスト効率を約束します。しかし、常時稼働のセーフティ クリティカルなソフトウェア デファインド ビークル (SDV) プラットフォームのコンテキストでは、これらの利点が認識されているにもかかわらず、多くの場合、重大なリスクが伴います。
彼はタクセラの自動車市場の発展を主導しています。
SDV が本当のトレンドではありますが、特に従来の開発サイクル、階層的な意思決定、迅速な移行よりも間違いの回避を優先する文化を経験している従来の OEM にとって、移行はまだ不完全です。
SDV 時代には、極端な条件下での堅牢かつ決定的なパフォーマンス、10 ～ 15 年の寿命にわたる耐久性、電力損失やハードウェアの変動に対する耐性が必要です。これらはまさに、オープンソース ソフトウェア、特にファイル システムなどの基本的なレイヤーでは不十分な領域です。
オープンソースが常に本番環境であるとは限らない理由
イノベーションとスピードに対するオープンソースの力を否定することはできません。世界中のエンジニアが概念実証を構築し、開発を開始するために使用しています。しかし、試作車から量産車への移行、特に故障の可能性がゼロの車両では、重大な懸念が生じます。
ほとんどのオープン ソースの組み込みファイル システムは、決定論的制約やセキュリティ クリティカルな制約を考慮して設計されていません。
多くのオープンソース ファイル システムは障害の一貫性を提供しますが、通常は、制限された回復時間、繰り返しの突然の電源喪失後の決定的な動作、機能安全要件に合わせた検証テストを保証しません。
これらのシステムは、書き込み負荷が重い場合や停電が繰り返される場合、待ち時間や回復時間が非決定的になる可能性があります。
さらに悪いことに、OEM が ISO 26262 などのセキュリティ標準や ISO/SAE 21434 などのサイバーセキュリティ フレームワークを満たすために必要なドキュメント、サポート、または認証経路が不足していることがよくあります。
オープンソース コミュニティは活発ですが、製品ロードマップやサービス レベル アグリーメント (SLA) に拘束されません。これにより、サポートの不一致、予測できない更新、または長期間未解決のまま残るバグが発生する可能性があります。
セーフティ クリティカルなシステムのコンテキストでは、際限のない遅延や予期しない回復動作がリアルタイムの予算に違反し、システム全体の信頼性に影響を与える可能性があります。
Eclipse SDV や S-Core のようなオープンソースの共同作業には大きな可能性がありますが、これらのスタックが完全に成熟するまで待つと進歩が遅れる可能性があります。現在すでに商用グレードのソフトウェアが入手可能であるため、OEM はすぐに移行を開始できる一方で、後でオープンソースを通じて最適化する余地も残されています。
オープンソースの隠れたコスト
オープンソースは「無料」であるとよく考えられていますが、それを適応させ、認定し、維持するためのエンジニアリングコストは多大です。
この作業は社内で行うか、専門のサービスプロバイダーに委託する必要があります。どちらの場合も、チームは数か月かけて極端なケースを検証し、カスタム パッチを維持し、さまざまなハードウェア間で一貫したパフォーマンスを確保します。
その結果、コストはゼロではなく、ライセンス料から継続的なエンジニアリングまたはコンサルティング費用へと移行し、多くの場合、製品ベンダーではなく特定のインテグレータへの依存が生じます。チームは数か月かけて極端なケースをテストし、カスタム パッチを作成し、さまざまなハードウェア構成でのパフォーマンスを確保する必要があります。
これは、特に組み込みソフトウェアを専門としない企業のプログラマにとって貴重な時間を浪費します。
さらに悪いことに、正式な SLA や製品ロードマップはありません。これは、バグが対処されない可能性があり、オープンソース コミュニティでの変更が非互換性を引き起こしたり、回帰を引き起こしたりする可能性があることを意味します。
SDV のミッション クリティカルなシステムの場合、OTA アップデート中、シャットダウン イベント中、またはレコードが最も必要なときなど、考えられる最悪のタイミングで予期せぬ障害が発生する可能性があります。
たとえば、初期の Tesla Model S ドライブでは、大量のロギングと不十分なフラッシュ抵抗マージンが原因で eMMC の磨耗が発生しました。これは、ストレージ アーキテクチャ、ロギング戦略、およびフラッシュ管理を合わせて考慮する必要があることを思い出させます。
エンジニアリング チームは、オープンソース コンポーネントを実稼働環境に成熟させるために必要なテスト負荷を過小評価することがよくあります。
厳格な認定とライフサイクルテストがなければ、メモリ管理、同期、または I/O 操作における微妙なエラーがすり抜けて、車両の寿命が始まって数か月または数年後にのみ現れる可能性があり、修正にはより多くの費用がかかり、より風評被害が大きくなります。
特に中国の新規市場参入者は、小規模で高度な所有権を持つチームが専門家主導の迅速な意思決定を行う「オオカミ文化」アプローチを採用しています。これに比べ、従来の OEM の多くは、階層化された承認と一元化された意思決定構造によって依然として時間がかかり、「俊敏性のギャップ」が生じています。
サイバーセキュリティには、オープンソースに依存する場合に過小評価されがちな、新たな責任が加わります。オープンソース コミュニティには、脆弱性を監視したり、タイムリーな修正を提供したり、定義されたライフサイクルにわたって製品をサポートしたりする義務はありません。
量産車では、この責任はなくなるわけではなく、OEM またはそのサプライヤーに完全に移転されます。チームは継続的に脆弱性を追跡し、脆弱性を評価し、修正をバックポートし、リスクが ISO/SAE 21434 や UN R155 などの標準に従って管理されていることを示す証拠を提供する必要があります。
この作業が社内で行われるかサードパーティに委託されるかにかかわらず、安全およびセキュリティ システムでオープンソース コンポーネントを使用する場合は、継続的な運用コストと組織的負担を考慮する必要があります。
予測可能性の重要性
安全性が重要な領域では、機能性と同じくらい予測可能性と一貫性が重要です。これらの車両は、変動する環境条件において 10 年以上にわたって確実に動作することが期待されています。
オープンソース ソリューションでこれらの要件を満たすには、通常、大幅な追加の認定、カスタマイズ、および長期的な所有の努力が必要です。
たとえば、ext4 や F2FS などのオープン ソース ファイル システムは、もともとサーバー、デスクトップ、Android 向けに設計されており、車両システムに典型的な限定された決定的な環境向けではありません。
これらのファイル システムでは、予測できないマウント時間、不潔な停止後のデータ破損、または重い書き込み負荷による急速な劣化が発生する可能性があります。
最も先進的な運転支援システムであっても、システムの起動が遅かったり、データが破損したり、衝突時に記録が失われたりすると、効果がなくなる可能性があります。障害は検証中には現れず、何年も現場で使用した後でのみ現れる可能性があるため、OEM は財務上および評判上のリスクに直面します。
OEM は、ソフトウェア スタック全体にわたって、より強力なサイバーセキュリティとセキュリティ テストを提供する必要があります。明確な所有権、ドキュメント、または長期サポートのないコンポーネントでは、このコンプライアンス プロセスがさらに困難になります。
フラッシュ互換ファイルシステムが優れたパフォーマンスを発揮する理由
商用の組み込みファイル システム、特にフラッシュをサポートするファイル システムは、これらの現実を念頭に置いて設計されています。書き込みパターンを最適化し、書き込み増幅を削減し、数千回の突然のシャットダウンの後でもパフォーマンスとマウント時間の一貫性を維持します。
たとえば、自動車環境におけるフラッシュ対応ファイル システムの実際のテストでは、15,000 回を超えるハード シャットダウン サイクル後に 100% のデータ整合性が示されました。このレベルの検証は、汎用のオープン ソース ファイル システムを使用する場合、専用のエンジニアリング作業を行わなければ通常は達成が困難です。
また、フラッシュ互換ファイル システムは断片化と磨耗を最小限に抑え、車載フラッシュ メモリの寿命を延ばします。これにより、OEM は信頼性を犠牲にすることなく、よりコスト効率の高いメモリ テクノロジを使用できるようになります。
さらに、商用グレードのファイル システムには通常、エンジニアリング サポート、長期メンテナンス オプション、業界標準に合わせた検証ロードマップが付属しています。これにより、OEM は、データ レイヤーの基本的な整合性の管理をストレージの専門家に依存しながら、車両の機能に集中できるようになります。
基盤となるハードウェアを深く理解しなければ、どのようなソフトウェア戦略も成功することはできません。フラッシュの動作、ブート要件、または電源障害のシナリオを無視すると、どのスタックが選択されたかに関係なく、システム障害が発生する可能性があります。
コミットメントのないコントロール
OEM はオープンソースを完全に放棄する必要はありません。これは、イノベーションとプラットフォームの柔軟性を実現する上で重要な役割を果たします。ただし、慎重に使用し、必要に応じて増やす必要があります。
これは、データの整合性、セキュリティ、回復力を損なうことができない組み込み層に特に当てはまります。ここで、最も成功している OEM は、アプリケーション層でのオープンソースの柔軟性と、その下にある商用グレードのソフトウェア インフラストラクチャの予測可能性とパフォーマンスを組み合わせています。
OEM は、市販の組み込みファイル システムを必要に応じて使用することで、総所有コストを削減し、検証を簡素化し、市場投入までの時間を短縮できます。
実際、多くの大手 OEM は、専用の認定ファイル システムを使用してストレージ、レジストリ、OTA システムをロックダウンしながら、上位レベルのサービスにオープンソース スタックを使用するハイブリッド アプローチを採用しています。このバランスにより、ミッションクリティカルな信頼性を損なうことなく、より迅速なイノベーションが可能になります。
未来のためのエンジニアリング
SDV は 10 年以上持続し、進化するソフトウェア プラットフォームをサポートし、厳しい条件下でも一貫したパフォーマンスを提供すると予想されます。これらのプラットフォームの中核層でオープンソースのみに依存するのは危険です。
組み込みソフトウェアのライフサイクル全体のコストを理解している OEM は、安全で確実な、将来性のある車両を提供するための備えが強化されます。これは開発者の能力向上にも関係します。
社内チームは、ファイル システムの下位レベルのデバッグやリカバリ ロジックのリバース エンジニアリングの煩わしさから解放され、接続性、UX、航続距離、パフォーマンスなど、車両を真に差別化する機能の構築に集中できます。
SDV 時代では、ソフトウェア スタックが手段であり、これに障害が発生した場合、リセットよりもはるかに大きなコストがかかります。
中小企業向けに最適なソフトウェアをご紹介します。
この記事は以下の一環として作成されました。 TechRadar プロの洞察今日のテクノロジー業界で最も優秀な人材を紹介するチャンネルです。
ここで表明されている見解は著者の見解であり、必ずしも TechRadarPro または Future plc の見解ではありません。コラボレーションに興味がある場合は、こちらで詳細をご覧ください。 https://www.techradar.com/pro/perspectives-how-to-submit
