IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日立オートモティブシステムズ株式会社の特許一覧

<>
  • 特開-通信制御システム 図1
  • 特開-通信制御システム 図2
  • 特開-通信制御システム 図3
  • 特開-通信制御システム 図4
  • 特開-通信制御システム 図5
  • 特開-通信制御システム 図6
  • 特開-通信制御システム 図7
  • 特開-通信制御システム 図8
  • 特開-通信制御システム 図9
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024173186
(43)【公開日】2024-12-12
(54)【発明の名称】通信制御システム
(51)【国際特許分類】
   H04L 65/00 20220101AFI20241205BHJP
【FI】
H04L65/00
【審査請求】未請求
【請求項の数】4
【出願形態】OL
(21)【出願番号】P 2023091423
(22)【出願日】2023-06-02
(71)【出願人】
【識別番号】509186579
【氏名又は名称】日立Astemo株式会社
(74)【代理人】
【識別番号】110000350
【氏名又は名称】ポレール弁理士法人
(72)【発明者】
【氏名】折原 伸弥
(57)【要約】
【課題】暗号化/復号化に関わるハードウェアリソースの増大を抑えつつ、アプリケーションに対して通信メッセージの最適な暗号化または復号化の処理タイミングを実現することで、セキュアかつリアルタイムな車両制御を実現する通信制御システムを提供する。
【解決手段】複数のアプリケーションおよび複数プロトコルかつ複数チャネルの通信処理のための複数または単一のCPUコア、および、通信メッセージの暗号化または復号化を処理するための暗号化復号化処理回路を備えた通信制御システムであって、暗号化または復号化が必要な通信メッセージを記憶するバッファと、前記複数のアプリケーションの起動タイミングを管理するアプリ起動管理部と、優先度にしたがって前記バッファに格納された前記通信メッセージの暗号化または復号化の処理順を調停するための調停部と、を備えることを特徴とする通信制御システム。
【選択図】 図1
【特許請求の範囲】
【請求項1】
複数のアプリケーションおよび複数プロトコルかつ複数チャネルの通信処理のための複数または単一のCPUコア、および、通信メッセージの暗号化または復号化を処理するための暗号化復号化処理回路を備えた通信制御システムであって、
暗号化または復号化が必要な通信メッセージを記憶するバッファと、
前記複数のアプリケーションの起動タイミングを管理するアプリ起動管理部と、
優先度にしたがって前記バッファに格納された前記通信メッセージの暗号化または復号化の処理順を調停するための調停部とを備えることを特徴とする通信制御システム。
【請求項2】
前記複数のアプリケーションに予め定めたアプリ重要度、前記通信メッセージに予め定めた重要度、送受信種別、および、前記暗号化復号化処理回路の暗号化または復号化の処理の必要要否を記憶したデータベースを備えることを特徴とする請求項1に記載の通信制御システム。
【請求項3】
同一の前記通信メッセージに対して、前記バッファに記憶されてから現時点までの経過時間を計算し、前記通信メッセージに対する処理待ちの許容時間を算出する許容遅延時間計算部を備えることを特徴とする請求項2に記載の通信制御システム。
【請求項4】
同一の前記通信メッセージに対して、車両状態などに応じて動的に重要度を判定する動的重要度判定部を備えることを特徴とする請求項3に記載の通信制御システム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、通信制御システムに関し、特に、セキュアかつリアルタイムな通信を実現する通信制御システムに関するものである。
【背景技術】
【0002】
特開2022-127418号公報(特許文献1)には、自動運転など複数の車両制御アプリケーションなどを有し、かつセキュアな通信を実現するために通信メッセージに対して暗号化/復号化機能を利用した制御装置が開示されている。また、特許文献1では、暗号化/復号化機能を実現するため、例えば、HSM(Hardware Security Module)などのハードウェアリソースを利用した場合に、通信メッセージの処理時間などに伴う車両制御アプリケーションの性能要件を満足するための通信制御方法が提案されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2022-127418号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、上記の通信制御方法では次のような課題が生じると考えられる。
【0005】
ある時間軸において、通信容量が増大することで重要度の高い通信メッセージがハードウェアリソースを連続して占有する状況では、重要度の低い通信メッセージの暗号化/復号処理が停留した結果、送受信が滞り、対象の通信メッセージを処理するアプリケーションが機能しない恐れがある。
【0006】
本開示は、暗号化/復号化に関わるハードウェアリソースの増大を抑えつつ、アプリケーションに対して通信メッセージの最適な暗号化または復号化の処理タイミングを実現することで、セキュアかつリアルタイムな車両制御を実現する通信制御システムを提供する。
【課題を解決するための手段】
【0007】
一態様に係る通信制御システムは、複数のアプリケーションおよび複数プロトコルかつ複数チャネルの通信処理のための複数または単一のCPUコア、および、通信メッセージの暗号化または復号化を処理するための暗号化復号化処理回路を備えた通信制御システムであって、
暗号化または復号化が必要な通信メッセージを記憶するバッファと、
前記複数のアプリケーションの起動タイミングを管理するアプリ起動管理部と、
優先度にしたがって前記バッファに格納された前記通信メッセージの暗号化または復号化の処理順を調停するための調停部と、を備える。
【発明の効果】
【0008】
本開示によれば、暗号化/復号化に関わるハードウェアリソースの増大を抑えつつ、アプリケーションに対して通信メッセージの最適な暗号化または復号化の処理タイミングを実現することで、セキュアかつリアルタイムな車両制御を実現する通信制御システムを提供することができる。
【0009】
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【0010】
図1】実施例に係る通信制御システムの構成図。
図2】実施例に係る通信制御システムの通信メッセージのシーケンス。
図3】実施例に係る通信制御システムの通信メッセージ送受信時の処理を説明するフローチャート。
図4】実施例に係る通信制御システムのHSM暗復号化完了時の処理を説明するフローチャート。
図5】実施例に係る通信制御システムの通信メッセージのアプリ起動予定時間に関するソート処理を説明する概要図。
図6】実施例に係る通信制御システムの通信メッセージのソート処理全体を説明するフローチャート。
図7】実施例に係る通信制御システムの通信メッセージに対するHSMの処理順の判定フロー例。
図8】実施例に係る通信制御システムの通信メッセージに対するHSMの処理順の判定フロー例。
図9】実施例に係る通信制御システムの通信メッセージに対するHSMの処理順の判定フロー例。
【発明を実施するための形態】
【0011】
以下、実施例を、図面を用いて説明する。
【実施例0012】
本実施例では、暗復号(暗号化処理および復号化処理)に関わるハードウェアリソースの増設を抑えつつ、アプリケーションに対して最適な処理タイミングを実現することで、セキュアかつリアルタイムな通信を実現する通信制御システムの例を説明する。
【0013】
[通信制御システムの構成例]
図1は、実施例に係る通信制御システムの構成図である。通信制御システム1は、SoC(System on Chip)000、CPU(Central Processing Unit)(A)100、CPU(B)200、CPU(C)300、通信ドライバ500、HSM(ハートウエアセキィリティモジュール:Hardware Security Module)400を有する。
【0014】
SoC000は、例えば、シリコン単結晶のような単一の半導体基板に形成され、複数または単一のCPU(中央処理装置)コアおよび周辺装置により構成された半導体装置である。複数または単一のCPUコアは、特に制限されないが、複数のアプリケーションおよび複数プロトコルかつ複数チャネルの通信処理のために設けられている。
【0015】
CPU(A)100は、SoC000上のハードウェア回路として構成され、かつ、CPU(B)200およびCPU(C)300とは独立して構成されている。CPU(A)100は、アプリケーションA101、アプリ起動管理部103、調停部102、バッファ104、データベース105、動的重要度判定部106、許容遅延時間計算部107を有する。
【0016】
アプリケーションA101は、例えば、車両を制御するためのソフトウェアアプリケーションである。
【0017】
アプリ起動管理部103は、アプリケーションA~C(101, 201, 301)の起動および終了を管理する部分である。アプリ起動管理部103は、単に、起動管理部ということもある。
【0018】
調停部102は、バッファ104に格納された通信メッセージに対するHSM400処理の優先度の管理、および、HSM400からの処理完了通知の受信、およびアプリケーションA~C(101, 201, 301)または通信ドライバ500との通信メッセージを入出力する部分である。
【0019】
バッファ104は、アプリケーションA~Cまたは通信ドライバ500から入力された、HSM400の処理が必要な通信メッセージを記憶する部分である。バッファ104は、いわゆる、揮発性メモリの記憶領域としてのRAM(random access memory)領域に定義される。つまり、バッファ104は、RAM領域である揮発性メモリの記憶領域の一部部分に割り当てられている。
【0020】
データベース105は、アプリケーションA~C(101, 201, 301)に予め定めた静的重要度、各通信メッセージに予め定めた静的重要度、送受信種別、および、HSM400の処理の必要要否が記憶された部分である。データベース105は、いわゆる、不揮発性メモリの記憶領域としてのROM(Read only memory)領域に定義される。つまり、データベース105は、ROM領域である不揮発性メモリの記憶領域の一部部分に割り当てられている。この様なデータベール105を有することで、アプリケーションに対して通信メッセージの最適な暗号化または復号化の処理タイミングを実現することが出来る。
【0021】
動的重要度判定部106は、異なるタイミングで受信される同一IDの通信メッセージにおいて、車両状態などに応じて動的に通信メッセージの重要度を判定する部分である。この様な動的重要度判定部106を有することで、車両状態に応じて、通信メッセージの最適な暗号化または復号化の処理タイミングを実現することかできる。これにより、セキュアかつリアルタイムな車両制御を実現することができる。
【0022】
許容遅延時間計算部107は、バッファ104に格納された同一の通信メッセージにおいて、バッファ104に記憶されてから現時点までの経過時間を計算する部分である。この様な許容遅延時間計算部107を有することで、経過時間に応じて、通信メッセージの最適な暗号化または復号化の処理タイミングを実現することが出来る。
【0023】
CPU(B)200は、SoC000上のハードウェア回路として構成され、かつ、CPU(A)100およびCPU(C)300とは独立して構成されている。CPU(B)200は、アプリケーションB201を有する。アプリケーションB201は、例えば、ドライバへ車両状態を通知するためのソフトウェアプリケーションである。
【0024】
CPU(C)300は、SoC000上のハードウェア回路として構成され、かつ、CPU(A)100およびCPU(B)200とは独立して構成されている。CPU(C)300は、アプリケーションC301を有する。アプリケーションC301は、例えば、車両状態を診断するためのソフトウェアアプリケーションである。
【0025】
通信ドライバ500は、SoC000上のハードウェア回路として構成され、かつ、CPU(A)100とは独立して構成されている。通信ドライバ500は、例えば、CAN(Controller Area Network)通信の物理層の処理を担う装置(通信回路とも言う)である。
【0026】
HSM400は、SoC000上のハードウェア回路として構成され、かつ、CPU(A)100とは独立して構成されている。HSM400は、例えば、暗号鍵を用いた暗復号処理(暗号化処理および復号化処理)を担う装置(暗号化復号化処理回路とも言う)である。
【0027】
[通信制御システムの送受信のシーケンス制御例]
図2は、実施例に係る通信制御システムの通信メッセージのシーケンスである。図2には、A:通信メッセージ(受信)のシーケンスと、B:通信メッセージ(送信)のシーケンスとが示されている。
【0028】
本実施例では、図2の通信メッセージのデータシーケンスに示す通り、通信ドライバ500からCPU100内のバッファ104への通信メッセージの入力、または、CPU内のアプリケーションA~C(101, 201, 301)から通信ドライバ500への通信メッセージの入力、これら通信メッセージに対してHSM400による暗復号処理を非周期的に繰り返し処理するものである。
【0029】
A: 通信メッセージ(受信)のシーケンスに示す様に、通信ドライバ500が受信した通信メッセージは、まず、バッファ104へ入力されて、バッファ104に格納される(なお、通信メッセージが暗号化されていないとわかっている場合、受信した通信メッセージを直接アプリケーションA~Cの対応するアプリケーションに入力することも可能である)。この時、CPU100内において、通信メッセージに対するHSM400による暗復号処理(ここでは、復号化の処理に対応する)の要否が判断される。通信メッセージに対するHSM400による暗復号処理が不要な場合(通信メッセージが暗号化されていない場合)、通信メッセージは、HSM400による暗復号処理がされずに、アプリケーションA~C(101, 201, 301)の対応するアプリケーションへ入力される。通信メッセージに対するHSM400による暗復号処理が必要な場合(通信メッセージが暗号化されている場合)、通信メッセージは、バッファ104からHSM400へ入力され、HSM400により暗復号処理される(ここでは、暗号化された通信メッセージに対して、復号化の処理が実行される)。復号化された通信メッセージは、HSM400からアプリケーションA~C(101, 201, 301)の対応するアプリケーションへ入力される。
【0030】
B: 通信メッセージ(送信)のシーケンスに示す様に、アプリケーションA~C(101,201,301)の対応するアプリケーションが送信した通信メッセージは、まず、バッファ104へ入力されて、バッファ104に格納される(なお、通信メッセージの暗号化不要であるとわかっている場合、送信された通信メッセージを直接通信ドライバ500へ入力することも可能である)。この時、CPU100内において、通信メッセージに対するHSM400による暗復号処理(ここでは、暗号化の処理に対応する)の要否が判断される。通信メッセージに対するHSM400による暗復号処理が不要な場合(通信メッセージの暗号化が必要ない場合)、通信メッセージは、HSM400による暗復号処理がされずに、通信ドライバ500へ入力されて、通信ドライバ500から送信される。通信メッセージに対するHSM400による暗復号処理が必要な場合(通信メッセージの暗号化が必要な場合)、通信メッセージは、バッファ104からHSM400へ入力され、HSM400により暗復号処理される(ここでは、通信メッセージに対して、暗号化の処理が実行される)。暗号化された通信メッセージは、HSM400から通信ドライバ500へ入力されて、通信ドライバ500から送信される。
【0031】
また、通信メッセージのシーケンスでは、後述するように、HSM400が暗復号処理すべき通信メッセージの処理順を、各通信メッセージが属するアプリケーションA~C(101, 201, 301)の起動予定時間および静的重要度、および、各通信メッセージの静的重要度、および、各通信メッセージの動的重要度に基づきソートする。
【0032】
[通信制御システムの制御1]
図3は、実施例に係る通信制御システムの通信メッセージ送受信時の処理を説明するフローチャートを示す。図3には、図2において通信ドライバ500からCPU内のバッファ104へ通信メッセージが入力、または、CPU内のアプリケーションA~C(101, 201, 301)から通信ドライバ500へ通信メッセージが入力された時の処理のフローチャートを示す。以下、図3の各ステップS100-S106の動作について説明する。
【0033】
調停部102は、通信ドライバ500またはアプリケーションA~C(101, 201, 301)から入力した通信メッセージに対して、HSM400処理が必要か不要かをデータベース105に予め記憶された情報から判断する(S100)。その結果、HSM400処理が不要な場合(No)は通信メッセージを直接、通信ドライバ500またはアプリケーションA~C(101, 201, 301)に入力する(S101)。
【0034】
HSM400処理が必要な場合(Yes)は、入力された通信メッセージをバッファ104に格納する(S102)。次に、HSM400の処理待ちか否かをHSM400の状態を示すレジスタから判断する(S103)。
【0035】
HSM400の状態が処理待ちではない場合(No)はバッファ104に格納した通信メッセージをHSM400へ送信する(S104)。HSM400は受信した通信メッセージに対して暗復号処理を実施する。
【0036】
HSM400の状態が処理待ちの場合(Yes)は、アプリ起動管理部103からアプリケーションA~C(101, 201, 301)の起動予定時間を取得する(S105)。つぎに、バッファ104内の通信メッセージをソートする(S106)。HSM400は受信した通信メッセージ順に暗復号処理を実施する。なお、ステップS106については、図4で詳細に説明する。
【0037】
[通信制御システムの制御2]
図3のステップS106(バッファ104内の通信メッセージをソート)の処理について図4および図5を用いて説明する。図4は、実施例に係る通信制御システムのHSM暗復号化完了時の処理を説明するフローチャートである。図5は、実施例に係る通信制御システムの通信メッセージのアプリ起動予定時間に関するソート処理を説明する概要図である。
【0038】
図4には、図2のバッファ104に格納されたHSM400にて暗復号処理を必要とする通信メッセージの処理順を、各通信メッセージが属するアプリケーションA~C(101, 201, 301)の起動予定時間および静的重要度および、各通信メッセージの静的重要度および、各通信メッセージの動的重要度に基づいて決定するソート処理のフローチャートの処理)が示されている。
【0039】
起動予定時間に基づくHSM400の処理順設定(優先度の設定)及びアプリの重要度に基づくHSM400の処理順設定(優先度の設定)については、図5に示されているように設定されているものとする。起動予定時間(アプリ予定時間)以外の部分は、データベース105内に格納されている。この例では、アプリの重要度(優先度)は、アプリケーションB201が高、アプリケーションC301が中、アプリケーションA101が低とされている(優先度:アプリケーションB201(高)>アプリケーションC301(中)>アプリケーションA101(低))。起動予定時間は、アプリケーションB201が最も早く(t1)、次に、アプリケーションA,C(101, 301)が同時(t2)とされている。アプリケーションA,C(101, 301)は、起動予定時間が同一程度の複数のアプリケーションとされている。また、HSM400の処理順設定(優先度)は、通信メッセージE, G=>通信メッセージH=>通信メッセージFの順番となっている。共通のアプリケーションに属する通信メッセージとしては、通信メッセージF, Hが共通のアプリケーションA101に属し、通信メッセージE, Gが共通のアプリケーションB201に属し、通信メッセージHがアプリケーションC301に属する。ここで、通信メッセージHは、アプリケーションA101とアプリケーションC301とに共通に利用される。
【0040】
以下、図4の各ステップS200-S207の動作について説明する。
【0041】
最初に、許容遅延時間に基づくHSM400の処理順設定(優先度の設定)について説明する。許容遅延時間計算部107は通信メッセージ毎にバッファ104に格納された時刻を記憶し、現在の時刻と比較し、経過時間を算出する。次に、通信メッセージ種別毎に予めデータベース105に記憶された許容遅延時間(許容時間とも言う)と許容遅延時間計算部107により算出された経過時間を比較し、許容遅延時間を超過している場合は対象の通信メッセージのHSM400の処理順を高く設定する(S200)。また、ここで示す許容遅延時間は通信メッセージがHSM400の処理順の調停処理を待つことができる最大時間とする。
【0042】
次に、送受信種別に基づくHSM400の処理順設定(優先度の設定)について説明する。通信メッセージが送信の場合は受信よりも優先度を高く設定する(S201)。なお、ここで示す送信および受信とは本通信制御装置である通信制御システム1の通信ドライバ500が外部に通信メッセージを出力する場合を送信とし、外部から通信メッセージを入力する場合を受信とする。
【0043】
次に、起動予定時間に基づく優先度の設定する(S202)。
【0044】
通信メッセージが受信の場合は、起動予定時間(起動タイミングとも言う)が最も早いアプリケーションの通信メッセージをHSM400の処理順を高優先とし、起動予定時間が最も遅いアプリケーションの通信メッセージをHSM400の処理順を低優先とする(例えば、図5の例では、アプリケーションB201が高優先とされ、アプリケーションA,C(101, 301)が低優先とされる)。アプリケーションA~C(101, 201, 301)から調停部102へ入力された通信メッセージの場合は、次に起動予定時間が同一程度の複数のアプリケーションがあるか否かを判定する(S203)。起動予定時間が同一程度の複数のアプリケーションがある場合(S203: Yes)には、アプリケーションごとの重要度(アプリ重要度とも言う)に基づき、重要度が高いアプリケーションに属する通信メッセージのHSM400の処理順を高優先とする(S204:図5の例では、アプリケーションA101が低優先とされ、アプリケーションC301が高優先とされる)。起動予定時間が同一程度の複数のアプリケーションがない場合(S203: No)には、S205へ移行する。
【0045】
次に、共通のアプリケーションに属する通信メッセージがバッファ104内に複数あるかないかが判定される(S205:図5の例では、通信メッセージF, HがアプリケーションA101に属し、通信メッセージE, GがアプリケーションB201に属し、通信メッセージHがアプリケーションC301に属する)。共通のアプリケーションに属する通信メッセージがバッファ104内に複数ない場合(S205:No)は、ソート処理のフローチャートを終了する。共通のアプリケーションに属する通信メッセージがバッファ104内に複数ある場合(S205: Yes)は、動的重要度判定部106から取得した通信メッセージの動的重要度に基づき、通信メッセージの優先度を決定する(S206)。ここで示す動的重要度とは、例えばCANなどのように通信メッセージ毎に固有の識別子を有する通信プロトコルでは、通常は周期的に送受信される通信メッセージが、例えばアプリケーションの1つであるAEB(Autonomous Emergency Brake)作動時に非周期的に送受信される場合はメッセージの優先度を上げるといった車両状態などに応じた通信メッセージの優先度を指す。なお通信メッセージ内に予め動的重要度を示す信号を定義しておき、その信号を基に動的重要度を判定し、通信メッセージのHSM400の処理順を決定してもよい。
【0046】
最後に、静的優先度に基づくHSM400の処理順設定(優先度の設定)について説明する。データベース105から取得した通信メッセージの静的重要度に基づき、バッファ104内に記憶された共通のアプリケーションに属する通信メッセージのHSM400の処理順を決定する(S207)。ここで示す静的重要度とは、例えば予め定められた通信メッセージごとの重要度を指し、CAN-IDなどの通信メッセージ毎に一意に定義される識別子を用いても良い。図5の例では、HSM400の処理順(優先度)は、通信メッセージE, G=>通信メッセージH=>通信メッセージFの順番となっている。
【0047】
ここで、[通信制御システムの制御2]のバッファ104における、通信メッセージに対するHSM400の処理順の判定処理例を図7-図9に示す。この例では、8つの通信メッセージA~Hのケースについて、代表例として説明する。
【0048】
図7の1):最初に全ての通信メッセージの処理順は最も遅い8を設定する。
【0049】
図7の2):次に、許容遅延時間に基づく処理順設定を行う。通信メッセージGとHは許容遅延時間が超過となっているため、処理順を8から2にあげる。
【0050】
図7の3):次に送受信種別に基づく処理順設定を行う。通信メッセージDとFとHの送受信種別は送信であるため、DとFは8から3、Hは2から1に処理順をあげる。
【0051】
図8の4):次にアプリケーションの起動予定時間に基づく処理順設定を行う。通信メッセージEはアプリケーションの起動予定時間がA,B,Cよりも早いため、8から5に処理順をあげる。
【0052】
図8の5):次にアプリケーションの重要度に基づく処理順設定を行う。通信メッセージAはアプリの重要度がB,Cよりも高いため、8から6に処理順をあげる。
【0053】
図8の6):次に通信メッセージの動的重要度に基づく処理順設定を行う。通信メッセージCは通信メッセージBよりも動的重要度が高いため、8から7に処理順をあげる。
【0054】
図9の7):最後に通信メッセージの静的重要度に基づく処理順設定を行う。通信メッセージDは通信メッセージFよりも通信メッセージの静的重要度が高いため、通信メッセージFの処理順を3から4に下げる。このようにして、全ての通信メッセージのHSM処理順を最適に並べ替えることができる。
【0055】
[通信制御システムの制御3]
図6図2のHSM400による通信メッセージの暗復号処理完了後の処理のフローチャートを示す。以下、図6の各ステップS300-S305の動作について説明する。
【0056】
HSM400による暗復号処理が完了した通信メッセージを、通信メッセージが属するアプリケーションまたは通信ドライバ500へ入力する(S300)。その後、入力された通信メッセージはバッファ104から削除する(S301)。
【0057】
次に、バッファ104に暗復号処理が未実施の通信メッセージが格納されているか否かを確認し(S302)、格納されていない場合(S302: No)には処理を終了する。
【0058】
バッファ104に暗復号処理が未実施の通信メッセージが格納されている場合(S302: Yes)には、アプリ起動管理部103がアプリケーションA~Cの起動予定時間を取得する(S303)。
【0059】
次に、前記取得した起動予定時間およびデータベース105から取得したアプリケーションの重要度情報および通信メッセージの送受信種別に基づき、バッファ104内に記憶された通信メッセージのアプリケーション単位でのHSM400の処理順をソートする(S304)。S304の動作は、具体的には、[通信制御システムの制御2]のステップS200-S207の動作と同様となるため、重複する説明は省略する。
【0060】
次に、バッファ104内のHSM400の処理順が先頭(最高優先度)の通信メッセージをHSM400へ入力し、HSM400では暗復号処理を実施する(S305)。そして、処理を終了する。
【0061】
[目的・補足]
本実施例は、HSM400を用いたセキュアかつリアルタイム性が要求される通信制御システム、特に自動運転システムや自動運転支援システムなど、特に通信メッセージを多数必要とするシステムまたは装置に適用することを主な目的としている。
【0062】
また、HSM400で暗復号化処理される通信メッセージはシステムまたは装置が送信および受信するもののみに限らず、同一の通信プロトコルにおける複数チャネル間の転送や、異なる通信プロトコル間における転送なども含むものとする。つまり、図1において、2つの通信ドライバ500が設けられている場合において、一方の通信ドライバ500から入力された通信メッセージを他方の通信ドライバ500から送信する場合にも、本実施例を利用できる。
【0063】
また、アプリケーションはA~Cのみならず、各CPUコアに複数存在し、それらが直列また並列で動作することも含むものとする。
【符号の説明】
【0064】
1:通信制御システム、000:SoC、100:CPU(A)、101:アプリケーションA、102:調停部、103:アプリ起動管理部、104:バッファ、105:データベース、106:動的重要度判定部、107:許容遅延時間計算部、200:CPU(B)、201:アプリケーションB、300:CPU(C)、301:アプリケーションC、400:HSM、500:通信ドライバ
図1
図2
図3
図4
図5
図6
図7
図8
図9