2024年5月23日

V2X通信を可能にするButterfly Key ExpansionとPKI証明書の種類について

レベル3以上の自動運転を実現するために、自動車業界において自動運転機能の高度化や技術開発などさまざまな取り組みが行われています。テスラではカメラやレーダーなどを使って自動運転機能を実現し、LiDARのようなセンサー技術も年々高度化が進んでいるなか、より高度な自動運転を実現するために欠かせないものとして最近V2X通信が注目されています。V2X通信環境では、車両と車両/インフラ/歩行者間で直接通信が行われるため、車両は周辺環境の情報をリアルタイムで受け取り、潜在的な危険を事前に予防することが可能になります。 V2X通信の安全性を確保するためには暗号技術が必須であり、公開鍵基盤(PKI)を用いてV2Xメッセージの暗号化と証明書管理を行うSCMS(Security Credential Management System)の構築が前提となります。そこで今回は、協調型自動運転の実現に欠かせないV2X PKI証明書および認証の仕組みについて解説します。   V2X PKI証明書の特徴 通信技術は日々進化し、IoTとAIなど様々な分野で様々なデバイスを介して高速で大容量の通信が行われています。また、通信の脆弱性を狙ったサイバー攻撃も増加しており、通信の信頼性を確保することは、業界にとって大きな課題となっています。 安全な通信を実現するためには、以下の3つの条件を満たす必要があります。 通信相手が本人であることを確認・証明すること(Authentication、認証) 他人に盗聴されないこと(Confidentiality、機密性) 通信内容が途中で改ざんされないこと(Integrity、完全性) インターネット通信の場合、認証プロセスは中央集権的で階層的です。ユーザが署名付きのデジタル証明書を使用して、サーバーに対して自分の身元を証明すると、サーバー側は、そのデジタル証明書を通じて信頼できるユーザであることを確認したうえでユーザに対してアクセス権限を付与し、セキュアな通信ができるようにします。 それに比べ、V2X通信の場合、車両は周辺環境の全てのものと直接通信を行う仕組みとなっており、インタネット通信と違って、脱中央集権的であるといえます。インタネット上ではユーザ同士の認証を必要としないですが、V2X環境ではユーザ(車載器)同士の認証は必須です。 さらに、V2X認証の最も大きな特徴として挙げられるのが、車車間通信でお互いの身元(車両情報)を特定されずに認証を行うという点です。車両情報が特定されてしまうと、プライバシーを侵害されたりサイバー攻撃のターゲットになったり、人の命が危険になる可能性もあるため、仮名証明書を使用して条件付きのプライバシー保護が必要になります。 SCMS(Security Credential Management System)では、道路上の全ての車両に対し、認証局(CA)から仮名証明書が発行されます。仮名証明書にはその車両を具体的に特定できる情報は含まれていない、認証局からその車両の情報が正しいことを保証することから、信頼できる車両であることを証明できます。 また、長期にわたって同じ仮名証明書を使用する場合、第三者によってトラッキングされてしまう恐れがあるため、証明書を一定期間ごとに変更することが必要です。一般車両の場合、毎週ごとに最多20個以上の仮名証明書が発行されるといわれます。   Butterfly Key Expansionとは […]
2024年5月20日

車載ソフトウェアの標準仕様AUTOSARとは?基礎説明から導入時のポイントまで

百年に一度の大変革期を迎えている自動車業界において、技術の進歩は目まぐるしい現状となっています。今や自動車は”走るコンピュータ”と言われることもあり、約200個のECU※が搭載されています。そのECUを動かすのに欠かせないものがソフトウェアです。 技術が進歩する一方で、ソフトウェアが複雑化することが大きな課題になっています。この課題を解決すべく、自動車の制御ソフトウェアの標準化活動を実施し、車載電子制御ユニット用の共通標準ソフトウェアアーキテクチャを策定、確立したのがAUTOSARと呼ばれるソフトウェア規格です。今回の記事では、自動車ソフトウェアの標準仕様であるAUTOSARについて説明します。 ※Electronic Control Unitの略称。車載に搭載される電子制御をするユニットを指す。   AUTOSARとは 正式名称AUTomotive Open System ARchitecture (以下、AUTOSAR) は、2003年に発足した自動車業界のグローバル開発パートナーシップです。活動の目的は、インフォテインメントを除く領域で、車載電子制御ユニット用の共通標準ソフトウェアアーキテクチャを策定、確立することになります。さまざまな車種やプラットフォームに対応できる拡張性、ソフトウェアの可搬性、可用性への配慮、安全要求への対応、多種多様なパートナーとの協業、天然資源のサステナブルな利用、車両の「製品ライフサイクル」 全般にわたる保守性などを目標としています。   AUTOSARのソフトウェアアーキテクチャ構造 AUTOSARのアーキテクチャは、次の3つの階層で構成されています。 ①Basic SoftWare (以下、BSW) 上層ソフトウェアの機能を動かすための必須サービスを提供する標準ソフトウェアモジュールです。ほとんどの場合、BSWには以下に述べるアプリケーション層のような機能は存在せず、その名の通り、ソフトウェアの基本となる部分です。 ②Run Time Environment (以下、RTE) アプリケーションソフトウェアのECU内、ECU間通信をネットワークトポロジーに依存せず抽象化するための中間層です。BSWと以下に述べるアプリケーション層を仲介する役割をしています。 […]
2024年4月29日

自工会/部工会サイバーセキュリティガイドラインとは?制定背景から活用まで解説

100年に一度の大変革期を迎えている自動車業界において、技術の進歩は目まぐるしい状況が続いています。 ACC(オート・クルーズ・コントロール)やAHB(オート・ハイビーム・システム)/AHS(アダプティブ・ハイビーム・システム)など、あくまで運転に対する利便性や安全性の向上を目的とした車内クローズドの機能がどの車両にも標準的に搭載されたかと思えば、現在では、スマホを使用した車両の開錠/施錠、それ以外にもリモートコントロールと呼ばれる遠隔で車両を動かす機能まで当たり前になろうとしてきています。 しかし、技術が進歩する一方で、悪い側面も出てきており、それは技術の穴をついたサイバー攻撃です。昨今ニュースなどのメディアで取り上げられている生産停止や顧客情報の流出など、サイバー攻撃によるインシデントが日々発生していることから、サイバー攻撃は車両の影響に留まらず、サプライチェーンを含む自動車業界を巻き込む事態となっていると言えます。これからの自動車業界は、技術の進歩に加え、サイバー攻撃にどう対応し、いかにしてリスクを減らしていくかが求められています。そこで制定されたのが、自工会/部工会・サイバーセキュリティガイドラインです。今回の記事では、自工会/部工会サイバーセキュリティガイドラインに関する制定の背景、ガイドラインの目的、対象になる産業や企業について説明します。   ガイドライン制定の背景と目的 サイバー攻撃のリスクを挙げると ・セキュリティ対策を強化中の関係企業や取引先等のネットワークへの不正侵入 ・企業間ネットワークを経由した攻撃 ・標的企業が利用するソフトウェアや製品への不正なプログラムの埋め込み等のサプライチェーンを狙ったサイバー攻撃 など、数多くあります。自動車メーカーやサプライチェーンを構成する各社に求められる自動車産業固有のサイバーセキュリティリスクを考慮した、向こう3年の対策フレームワークや業界共通の自己評価基準を明示することで、自動車業界全体のサイバーセキュリティ対策のレベルアップや対策レベルの効率的な点検を推進することを目的にガイドラインが制定されました。   ガイドラインの対象 ガイドラインの対象は下記と定義されています。 ・自動車産業に関係する全ての会社(特にセキュリティ業務に関与している) ー CISO (最高情報セキュリティ責任者) ー リスク管理部門 ー 監査部門 ー セキュリティ対応部門 ー 情報システムの開発/運用部門 ー データマネジメント部門 […]
2024年3月26日

自動車の発展、E/Eアーキテクチャの変化について

自動車電装とはE/E(Electrical&Electronic)、自動車の電気及び電子装備のことを示します。各種モーターやセンサー、制御装置、操作スイッチ、ブラックボックス、カメラを含む電気系部品や装備がこれに該当します。SDVの本格化により、自動車電装分野は業界内でもこれから伸びる産業として注目されています。そしてE/Eアーキテクチャとは、自動車内部の様々な装置を管理するために搭載されている各種制御機やケーブルなどの設計構造として定義されています。つまり、車両に搭載されているE/E装置をつなぐシステムのことを意味します。今回は、E/Eアーキテクチャの発展プロセスについて取り上げながら、次世代E/Eアーキテクチャが今後どのように変化していくかについて解説します。   分散型アーキテクチャ(Distributed Architecture)とは 昔の車は、ただ移動するための手段に過ぎませんでした。車両に搭載されるコンピューティング要素と言っても、モーターの制御を含む車両動作関連のECU(Electronic Control Unit)程度であり、この時の自動車は動力機関や安全性などによって車両の性能が決定されました。当時は、車両に搭載されるECUの数が少なかったため、一つの機能を提供する低い性能のECUを複数搭載することで、車両製造のコストを下げるとともに、エンジン制御、ブレーキ制御など、機能ごとに最適化されたECUを配備することができました。 しかし、自動車の電子化に伴い、自動車の快適性や利便性を向上させるための様々な機能が搭載されるようになりました。例えば、運転者に情報や娯楽を提供するインフォテイメント機能や温熱シートなどが開発され、これらの機能を実行するECUが必要となり、自動車メーカーは必要とされるECUを追加し続けることで車両アーキテクチャを構成していきました。 出典:ECUの平均搭載数の増加推移 上のグラフを見ると、自動車の機能が複雑になるにつれて車両に搭載されるECUの数がますます増えているのがわかります。実際、高級車の場合には100個以上のECUが搭載されるともいわれています。このように複数のECUを用途に応じて車内各所に配置したアーキテクチャを「分散型アーキテクチャ(Distributed Architecture)」といいます。 図1.分散型アーキテクチャ 出展:https://www.hyundai-kefico.com/en/future-tech/modular-architecture/content.do 分散型アーキテクチャでは図1のように、車両全体において、複数のECUが配置されている構成となっているのがわかります。 ECUの配置における基準は特になく、機能が追加されるたびにその機能を提供するECUを搭載していくため、このような複雑な構成を見せています。 分散型アーキテクチャの問題点としては、必要に応じてECUを搭載していくため、重複した機能を持つECUも存在すれば、不要な機能がそのまま残っている場合もあるということが挙げられます。こうなると、特定機能をアップデートする際には、当該機能と関連しているECUがどこに配置されているのかを見つけ出し、機能をいちいち比較しなければなりません。このアーキテクチャは車両機能の拡張性に限界があり、用途も限定的ということから、後述するドメイン型やゾーン型アーキテクチャへの移行が求められるようになりました。   ドメイン型アーキテクチャ(Domain Architecture)とは 従来の分散型アーキテクチャの課題を解決するために新しく提示されたのが「ドメイン型アーキテクチャ(Domain Architecture)」です。 図2.ドメイン型アーキテクチャ 出典:https://www.hyundai-kefico.com/en/future-tech/modular-architecture/content.do ドメイン型アーキテクチャでは、自動車の機能に基づいて、複数の関連機能が一つのドメインコントロールに統合されます。一般的にパワートレイン系、ボディ系、シャシ系、インフォテイメント系といった複数の機能単位(ドメイン)で分類されます。これらのドメインの制御を1つのユニットで統合することで、異なるサブシステム間の通信とデータ交換を最適化する、ドメイン制御ユニット(DCU)による集中型アーキテクチャが可能になります。ドメイン型アーキテクチャは、分散型アーキテクチャと比べ機能アップデートが容易になることから、現在多くの車両で採用されています。しかし、自動運転の到来が加速している現在、ドメインにフォーカスした従来のアーキテクチャは限界を迎えつつあります。その理由としては、2つほどが挙げられます。 1つ目に、自動運転技術の発展に伴い、車両に搭載すべき装置が爆発的に増加していることです。自動運転機能を実装するための装置は増える一方で、その装置が機能単位で縛られることによって物理的な限界が生じるようになりました。例えば、特定のドメインを管理するDCUが車両後部に配置されているとしましょう。そして、このドメインに属する装置が車両の前部に搭載されているとしたら、機能単位で分類するドメイン型アーキテクチャでは、どうしても前部の装置と後部のDCUをつなぐためのケーブルが必要になります。このようなケースが多くなると、車両のケーブルの重量と長さが耐えられないほど増えてしまいます。実際、車両ケーブルの重量および長さは車両の単価、燃費、重量に影響を与えるため、自動車設計時に非常に重要な要素となります。 2つ目に、自動運転を可能にするためには、自動車に搭載されている全ての装置間の情報共有が必須であるということです。ドメイン型アーキテクチャでは、車両装置を機能に基づいて分類しているため、機能のアップデートには最適であるものの、他のドメインに属している装置との情報共有に問題が発生する恐れがあります。 […]
2024年3月13日

ECU開発の効率を高める「HILS」とは?

自動運転車、CASEを実現するための技術が高度化するにつれて、車両に搭載されるECUもさらに高度化しています。 それに伴い、ソフトウェアも複雑化しており、ソフトウェアによるエラーやバグも多く発生している状況です。そのため、高度化された技術水準に合わせて徹底した検証が必要になります。 しかし、複雑なソフトウェアが搭載されたECUを実際の駆動環境と同じ環境を構築してテストすることは多くのリソースが必要になるため、簡単にできることではありません。この課題を解決するために、仮想環境でテストを行う「HILS」への関心が高まっています。今回は、HILSとは何か、どのように活用できるのかについて詳しく解説します。   HILSとは? HILS(Hardware in the Loop Simulation)とは、開発された製品の機能を検証するテスト方法であり、製品の駆動環境と同じ条件を仮想環境で構築し、シミュレーションを通じて製品がまともに機能するかどうかを検証する方法です。複雑に構成されたソフトウェアやECUをテストするために、実際の車両レベルのテスト環境を構成しなくても安全性を検証できる効率的な方法です。電気装置・機械装置の代わりに仮想環境にモデル化した制御対象(プラントモデル)とテスト対象(ECU)を連結させ、製品が実際の環境と同じ条件で機能するかどうかをシミュレーションで検証できます。   HILS導入の背景 一つの機能を提供するためには多くのECUが連携して作動する必要があります。例えば、車両の自動温度調節機能を提供するためには、温度・エアコン・窓・ヒーターなどを担当するECUが連携する必要があります。これより複雑な機能を提供するためには、たくさんのECUの連携が必要になります。したがって、車両に何らかの機能を追加する際には、その機能に直接または間接的に関連するECUのソフトウェアテストと検証が必要です。ソフトウェアの欠陥は製品開発段階で検証することが難しく、それで発生する問題も予測できない場合も多いため、徹底的なテストがさらに重要なことになります。また、新たな機能を車両でテストすることはとても危険なことですので、試験用車両や模型車両を製作してテストすることが一般的でした。しかし、組込みソフトウェアの増加や搭載されるECUの数が急激に増加したため、テスト環境の構築に使われるリソースが増えてしまいました。 これらの課題(ソフトウェア検証の難しさ、リソースの最適化、ECU開発の効率化)を解決するためにHILSテストが活用されるようになりました。   HILSのメリット HILSの重要な目的は開発コストを抑え、開発期間を短縮することです。テスト車両を製作しなくても、仮想環境に作成しておいた制御対象を用いてECUのソフトウェアテストができるため、資金と時間を要するテスト車両の製作数を減らし、テストベンチで過ごす時間を大幅に削減できます。これは自動車のテストである断線、センサーの故障、車両衝突などの危険な試験を行う場合にもメリットとなります。また、制御アルゴリズムの開発において、制御対象となる実際の部品が存在しないなどの場合にも効果的です。 時間やスペースの制約がなく、必要なときにいつでもテストを行うことができるのもメリットです。   HILSテストの環境について HILSは、実際のECUを組み合わせてプロトタイプを製作する代わりに、シミュレーションを通じてテストを行います。このため、HILSテスト環境は1)Test Input Generator、2)ターゲットECU、3)HILSで構成されます。Test Input Generatorはテストのための入力値を生成して入力する役割を担い、これにFuzzerなどの入力器が含まれます。ターゲットECUは機能をテストしたい対象ECUを意味します。HILSは実際の車両の環境を数学的にモデル化したもので、実機のアクチュエータを接続してテストすることもできます。 上の図は、AutocryptのHILSテスト環境です。HILSに対象ECUを接続した状態で、Fuzzerを利用してテスト入力値を注入すると、HILSを通じて出力値を受け取ることでターゲットECUのテスト過程を確認できます。このように対象ECUの機能に関連するすべてのECUを実際に構成しなくてもHILS環境でシミュレーションできます。 […]
2024年2月21日

SDV(ソフトウェア定義型自動車)への進化による自動車のリコールの変化

近年、自動車のリコールが世界的規模に拡大されています。2023年12月、アメリカでテスラ(※1)が高度運転支援システムの「オートパイロット」の機能に潜在的リスクが発見されたとして、過去最多の200万台の大規模リコールを発表しました。また2023年2月、トヨタ自動車(※2)は衝突被害軽減ブレーキが作動しない恐れがあるとして、約19万台のリコールを国土交通省に報告しました。これらのリコールの特徴は、ソフトウェアの不具合で発生したリコールという点です。 自動車の機能をソフトウェアが左右するといっても過言ではない時代になっています。自動車が走るコンピュータに変化するにつれて、リコールの傾向も変化しています。ソフトウェア更新で対応可能になり、売店に入庫したりディーラーに連絡することなく、ユーザが自分で対応可能になっていることから、これまでのハードウェアの不具合による自動車のリコールとは明らかに違います。今回は、自動車リコール制度というものを説明しながら、SDV技術の発展で発生するソフトウェアリコールについて詳しく掘り下げていきたいと思います。 ※1出典: https://www3.nhk.or.jp/news/html/20231214/k10014287821000.html ※2出典: https://toyota.jp/recall/2023/0216_2.html   自動車のリコールの変化 自動車のリコール制度は自動車の設計・製作上の不具合による事故や、故障、公害の未然防止を図るため、自動車メーカー等が不具合のあった型式の自動車に対して改善措置を行う制度です。(※3) ※3出典:政府広報オンライン:https://www.gov-online.go.jp/useful/article/201202/1.html 自動車安全基準の不具合が見つかったら自動車メーカが自主的にリコールを行う場合もあれば、国土交通省(アメリカの場合は米道路交通安全局(NHTSA))のような交通安全をつかさどる機関からの命令によるリコールが実施される場合もあります。もともとは、ハードウェアの問題によるリコールが多かったです。矢野経済研究所が調査したレポート(※4)によると、2020年の世界のリコールの比率はハードウェアのリコールが60%で、ソフトウェアのリコールが40%程度でした。それが、ソフトウェア中心のSDVへ進むにつれ、2025年にはソフトウェアのリコールが60~70%まで拡大し、ハードウェアを上回ることが予測されています。 実際、テスラのリコールの90%以上はソフトウェアのアップデートで簡単に処理できるという調査結果もあります。 ※4出典: 「2020年版 車載用ソフトウェア市場分析 VOL.1 分析編 ~CASEで変わるクルマの開発・製造とソフトウェア市場2030年予測~」   ソフトウェアリコールの流れ ソフトウェアのリコールは、OTA(Over the Air)によるソフトウェア更新と同様で、無線ネットワークによるソフトウェアやファームウェアアップデートでリコールを実施できます。OTAによるソフトウェア更新を可能にするためには、自動車に4Gや5G、またはWi-Fiのような通信方式に対応するTCU(テレマティクスコントロールユニット)や、走行データや車両データを保存するメモリーが組み込まなければなりません。ソフトウェアリコールの際、自動車メーカーはクラウド基盤サーバーからソフトウェアパッチを車両に配布し、車両はそのパッチを自動的にダウンロードおよびインストールを行います。そしてパッチが正常にインストールされると、車両はOEMのバックエンドに更新状況を報告し、ソフトウェアリコールの一連の作業は終了になります。   ソフトウェアリコールのメリット OTA技術によるソフトウェア更新は自動車メーカーと車両の所有者の両方に効率性と便利さをもたらしています。ソフトウェア更新で車載システムのエラーが簡単に修正できるため、自動車メーカーはリコール作業を担当していた自動車ディーラーにおけるメンテナンスと人件費の削減ができ、車両の所有者は販売店やディーラーに連絡することなく自らリコール対応できるので費用や時間を軽減できます。   解決すべきソフトウェアリコールの課題 […]
2024年2月8日

「第16回 オートモーティブワールド」出展レポート

これからの自動車はスマートフォンやパソコンと同様に、車両の内部に搭載された通信機器によって車と車、クルマとデバイス、クルマとインフラなどがネットワークを介して連結されると予測されています。外部接続に対応する自動車は完全なる自動運転が可能になり、社会的には交通事故の減少、渋滞の緩和、運転手不足の解消などのメリットがあり、人には運転操作から解放されて自由に過ごすことが可能になるメリットがあります。多くのメリットを持つCASE時代のクルマを開発するために、最も重要だと言われているのがソフトウェアです。世界の自動車産業の潮流と同じく、日本の自動車産業もソフトウェアに対する姿勢が変わりつつあります。その姿勢が確認できたところは、2024年1月24日~26日、東京ビッグサイトで「第16回 オートモーティブワールド」-クルマの先端技術展でした。 日本を代表する産業の1つとして言われている自動車産業に関する先端技術分野の世界最大の展示会であるため、世界中から注目を集めました。また、今回の展示会でソフトウェアデファインドビークル(以下SDV)に焦点を当てたSDV EXPOが初開催されるなど、最新動向も反映した展示会でした。その結果、出展社数は前回より300社が増えた約1,700社が出展、来場者数も約7.8万人に上りました。弊社も世界最大級の展示会に出展し、国際法規を守りながら安全なクルマ作りに必要なサイバーセキュリティ技術やセキュリティテストツールを紹介することができました。 では、これからの自動車産業において最も重要になると予測されているSDVに必要なサイバーセキュリティを紹介した現場をお届けしたいと思います。 高まるサイバーセキュリティの重要性 SDVにとって最も重要なのはソフトウェアですが、それに次いで同様に重要な分野があります。それはサイバーセキュリティです。UNECE WP29で採択された国際法規「UN-R155」により、自動車メーカーは車両のライフサイクル全体をカバーするサイバーセキュリティを構築する(CSMS)必要があり、開発されたソフトウェアが安全であるかを検証することが求められています。そのため、ファジングテストを利用したソフトウェアやECUの脆弱性検知、OSS管理ツールを利用したSBOM作成などが業界で広く使用されています。日本の自動車業界では、このような分析ツールやサービスの導入があまり進んでいないのが現状です。当ブースにご来場いただいた自動車業界に携わっている多くの方々も組み込みソフトウェアの脆弱性検知やサイバー攻撃を防御する対策に関する悩みを抱えていました。 最近のソフトウェア開発にはOSSも多く使われているため、脆弱性だけでなく、ライセンスに違反があるかどうかを確認することも重要になっています。しかし、ソフトウェアに使用されたOSSをライセンス違反まで管理することは難しく、適用されたセキュリティの安全性を検証することも相当な時間が必要な作業です。弊社の「AutoCrypt Security Analyzer」と「AutoCrypt Security Fuzzer」はこのような現場の悩み・課題を解決するために開発されたセキュリティテストツールです。自動化された管理機能を提供していますので、効率的なセキュリティ検証環境の構築をサポートします。 SDVフォーラムに登壇し、サイバーセキュリティと国際法規について解説 今回の展示会では、ただサービスやソリューションを紹介するだけではなく、SDVフォーラムに登壇してSDVに必要なサイバーセキュリティと国際法規に関するセミナーを行いました。主催者側から準備してくれました50席が満席になり、セミナーの後半には通路に立ってセミナーを聞いている方もいましたので、日本もSDVへの関心が高まっている一方で、自動車セキュリティや国際法規に関する多くの懸念を抱えている企業様がまだ多いと実感しました。 上記にも述べましたが、SDVもUN-R155の影響を受けるため、適切なセキュリティ対策を構築する必要があります。弊社は車種に合わせてサイバーセキュリティを企画、構築、テスト及び検証など、国際法規が求めている要件を満たすために必要なサービスを一気通貫で提供しているため、企業様のニーズに応じたサイバーセキュリティを構築することが可能です。車両ライフサイクル全体にわたる必要なサイバーセキュリティ構築ソリューションはこちらをご覧ください。 最後に インタネットを介して繋がっているコネクティッド・カー、いつでも車のソフトウェアをOTA(Over The Air)でアップデートできるSDV、常にあらゆるものと通信を行っているため便利だと言えますが、その分ハッカーから狙われやすくなります。サイバー脅威からクルマを守るために必要なセキュリティ対策は、今まで述べてきた脆弱性の検知・管理するツールだけでなく、持続的に自動車のセキュリティ状況を把握できるシステム(車両SoC)や車両ネットワークへ侵入する不正アクセスを検知・遮断する(IDSとIPS)セキュリティ対策など、考慮すべきポイントがたくさんがあります。セキュリティ対策の構築に慣れていない企業様は「どこからサイバーセキュリティを適用すればいいか、構築したセキュリティが国際法規の基準を満たしているか不安」という不安や悩みを抱えていると思われます。 弊社は2007年から17年間、自動車のサイバーセキュリティを研究・開発してきた弊社はSDVに必要なサービスも提供しています。脆弱性検知・管理するツール以外にも、車載ネットワーク・ECUへの侵入監視・防止システム「AutoCrypt IDS」、 セキュアなV2X通信をサポートするソリューション「AutoCrypt V2X-EE」、PKI基盤のセキュリティ証明書管理システム「AutoCrypt V2X-PKI」など、車両に必要なサイバーセキュリティは全てそろっており、お悩み事や不安なことを解消できるサービスやコンサルティングを提供できる豊富な経験を持っています。 幸いなことに、初めての出展にもかかわらず、多くの方々が弊社のブースに立ち寄り、自動車のサイバーセキュリティに関心を示しました。来場客の中ではOEM、サプライヤー企業様が多かったので、サイバーセキュリティに対する認識が高まっていると実感しました。第16回 […]
2024年1月23日

V2X通信を高度化する異常行動検知(MBD)技術について

自動運転では、運転に必要な「認知」「判断」「操作」のプロセスを、運転者ではなくシステムが全て代替して行います。安全かつ高度な自動運転を実現するために、システムは、1)自動運転車に搭載されたセンサーによるデータ収集、2)通信ネットワークによる周辺のデータ収集3)サーバとの通信によるデータ通信などで、安全に運転するために必要な各種情報を取得(認知)し、その情報をもとに総合的な判断しなければなりません。 カメラやLiDAR、レーダーなどのセンサーのみに頼ってしまうと、センサーに不具合が発生しているのに、システムがそれに気づかずにそのまま運転してしまい、大きな交通事故につながってしまうリスクが高まります。したがって、自動運転の高度化及び普及のためには、V2X(Vehicle to Everything)及びサーバとの通信を活用した情報共有は必須です。 道路を走る自動車は位置、速度などの情報を含むV2Xメッセージを周辺車両及び交通インフラに送信します。受信する側の自動車は、センサーから得られる情報と受信されたV2Xメッセージを組み合わせ、すでに存在する環境のマッピングを充実させたり、追加情報を拡張しながら、周辺の環境を明確に認知することができます。このように、V2X通信に参加しているエンティティの間で共有できる情報を増やすことで、交通事故のリスクを最小限に抑え、自動運転を更に高度化することができるでしょう。これが「協調型自動運転」の真の目的です。 出展:AUTONOMOUS GROUND VEHICLE SECURITY GUIDE: Transportation Systems Sector   誤まった情報拡散のリスク 前述通り、より高度な自動運転を実現させるためには、単一の情報から判断するのではなく、センサーによるデータ情報と周囲の車両やインフラから収集した様々なデータを組み合わせて周辺の状況を判断しなければなりません。 V2X通信では、PKIベースのセキュリティ証明書システム(SCMS:Security Credential Management System)を実装することで、信頼できるシステムから発行された証明書であることを検証し、その証明書を持っている車両の信頼性を保証するという仕組みを取っています。つまり、SCMSを通じてV2Xメッセージの整合性と機密性を保証する仕組みを取っているため、非常に信頼性の高い通信が可能であるといえます。 しかし、そもそもV2Xメッセージに含まれている情報が誤った情報であったらどうなるのでしょうか。システムの信頼性は確保されていても、車両がサイバー攻撃を受けたり、不具合を起こして間違った情報を送信してしまう可能性もあります。 信頼できると判断した車両から受信した情報が誤った情報であった場合、V2X通信に関わる全てのエンティティに大きな混乱を招くことになります。例えば、ある車両に搭載されているGPSセンサーが不具合を起こし、間違った位置情報が周辺の車両に送信されてしまえば、大きな事故につながる可能性も十分あります。 問題は、これだけにとどまりません。C-ITS(協調型高度道路交通システム)では車両における各種情報を個人情報として分類しており、匿名証明書を使って通信することでプライバシー保護を実現する仕組みとなっています。また、同じ証明証を長期にわたって使用することを禁止し、証明書の有効期限を短くすることで、車両の特定及び追跡を防止します。攻撃者が匿名性の高いC-ITSの仕組みを逆手にとって攻撃してくると、追跡が不可能になるため、交通システム全体に深刻な問題を引き起こすことになります。   V2X通信における異常行動の検知プロセス このように、V2X通信において、間違った情報を共有することを「異常行動(Misbehavior)」と言います。異常行動には、大きく2種類に分類できます。 […]
2024年1月8日

車載ソフトウェア開発に用いられるモデルベース開発とテスト、All about 「V字モデル」

V字モデルについてご存知でしょうか。主にソフトウェアの開発やテストにおいて用いられる一般的な手法として知られていますが、近年自動車に搭載されるソフトウェアが増加しており、自動車開発の際ソフトウェアの開発プロセスの一つであるV字モデルの採用が加速しています。今回は、ソフトウェアプロセスの一つである「V字モデル」についてご紹介します。   ソフトウェアプロセスとは? ソフトウェアがますます複雑になり、 開発期間や工数がかかり費用も増加する反面、ソフトウェアの品質における信頼性が低下するという状態を「ソフトウェア危機」と呼びます。「ソフトウェア危機」という言葉は、NATO(北大西洋条約機構)科学委員会主催の「NATOソフトウェアエンジニアリング・カンファレンス」で、ミュンヘン工科大学教授のフリードリッヒ・L・バウアー(Friedrich Ludwig Bauer)によって初めて使われたもので、このソフトウェア危機を克服するために、登場下概念が「ソフトウェアプロセス」です。 ソフトウェアプロセスとは、ソフトウェアの欠陥が原因で発生しうる事故を減らし、ソフトウェアの危機を回避を実現できるソフトウェアエンジニアリング手法の一つです。ソフトウェアシステムの開発に必要な活動や関連情報を段階別に分けて、ソフトウェアの開発、配布、運用のそれぞれのプロセスで実施すべき活動を定義したもので、ソフトウェアプロセスに沿って開発することになれば、修正や再開発の可能性が減ることになることから、ソフトウェアの開発時によく採用されています。 (ソフトウェアプロセス: https://www.itmedia.co.jp/im/articles/1109/09/news135.html)   V字モデルとは? (出典:V字モデル、ウィキペディア) V字モデルとは、システム開発の開始から終了までのプロセスのことで、ウォーターフォールモデル(要求定義‐ソフトウェア設計‐ソフトウェア実装‐テスト‐メンテナンス)の進化版ともいわれ、アルファベットV字のように見えることからV字モデルといわれます。 V字モデルの左側は「開発工程」で、V字の下の方へ工程が進み、ソースコードの作成まで済んだら開発工程は終了になります。その後、V字の右側であるテスト工程に移動していきます。V字モデルでは、ソフトウェア開発の各段階において、その上位の成果物や情報を文書化しながらプロセスを進めていきます。 (出典:ASPICE公式HP) 自動車エンジニアリング分野で広く採用される開発プロセス評価モデルである「A-SPICE」は、 典型的なV字開発モデルに基づいています。要求定義(左側)と受け入れテスト(右側)、基本設計(左側)と結合テスト(右側)、詳細設計(左側)と単体テスト(右側)がそれぞれ対応します。つまり開発工程に対応しテスト工程が決められており、実施するテストの内容が明確になります。要求定義の内容を受け入れテストで、基本設計の内容を結合テストで、詳細設計の内容を単体テストでそれぞれ確認でき、各テストで開発工程で実施した内容が正しく実装できているかを検証することができます。その上、V字モデルは、ソフトウェアの開発初期の段階からテスト計画が同時に作成されるため、迅速にプロセスを経ることができ、順次開発成果物を検証・確認することでエラーを減らし、ソフトウェアの品質向上にもつながります。 (出展: https://www.autocrypt.jp/sdv/) WP29の参照先となるISO/SAE 21434では、OEMやサプライヤー向けに製品開発サイクルでV字モデルを適用させる形で高度のセキュリティを実装し、持続的なサイバーセキュリティを実現することを要求しています。アウトクリプトは、車載ソフトウェアの品質向上を実現するために、このV字モデルに基づいてCSMSコンサルティングを行っております。ソフトウェアプロセスの各段階に必要とされる製品やソリューション、テストなどを提供し、車両型式認証に求められるコンプライアンス遵守をサポートします。 アウトクリプトが提供するCSMSコンサルティングの詳細は、こちらのページからご覧いただけます。 https://www.autocrypt.jp/sdv/   原文: […]
gdpr-image
当ウェブサイトでは、お客様のニーズに合ったより良いサービスを提供するために、クッキーを使用しています。詳細については「個人情報の取り扱い」をご確認ください。