(57)【要約】  車両に搭載されたＥＣＵの診断やリプログラミングの効率性の確保と、セキュリティリスクを低減する。制御装置は、制御エントリを参照して、車両に搭載されたＥＣＵに入出力されるパケットを中継する複数のスイッチに前記制御エントリを設定することにより、前記車両内の通信を制御する制御部と、前記複数のスイッチのいずれかを経由して前記ＥＣＵとの通信を試みる機器の認証処理を行う認証実施部と、を備える。前記制御部は、前記機器の認証に成功した場合、前記スイッチに、前記機器と前記ＥＣＵとの通信を実現する臨時の制御エントリを設定する。
2019187204.tif 000002
【特許請求の範囲】
【請求項１】
制御エントリを参照して、車両に搭載されたＥＣＵに入出力されるパケットを中継する複数のスイッチに前記制御エントリを設定することにより、前記車両内の通信を制御する制御部と、
前記複数のスイッチのいずれかを経由して前記ＥＣＵとの通信を試みる機器の認証処理を行う認証実施部と、を備え、
前記制御部は、
前記機器の認証に成功した場合、前記スイッチに、前記機器と前記ＥＣＵとの通信を実現する臨時の制御エントリを設定する
制御装置。
【請求項２】
前記機器は、テスター又はＴｅｌｅｍａｔｉｃｓ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｕｎｉｔである請求項１の制御装置。
【請求項３】
前記認証実施部は、所定の認証装置に、前記機器の情報を送信し、所定の認証装置から認証結果を受け取ることにより、認証を実施する請求項１又は２の制御装置。
【請求項４】
前記制御部は、
前記機器と前記ＥＣＵ間の通信同士が競合しない範囲で、機器とＥＣＵの複数の組に対して通信を許可する請求項１から３いずれか一の制御装置。
【請求項５】
前記制御部は、
前記スイッチに対し、前記機器と前記ＥＣＵ間のプロトコルの変換を実施させる制御エントリを設定する請求項１から４いずれか一の制御装置。
【請求項６】
前記機器は、前記ＥＣＵのプログラムを更新する更新用データを用いたリプログラミング処理を行う機器である請求項１から５いずれか一の制御装置。
【請求項７】
制御エントリを参照して、車両に搭載されたＥＣＵに入出力されるパケットを中継する複数のスイッチと、
前記スイッチに前記制御エントリを設定することにより、前記車両内の通信を制御する制御装置と、を含み、
前記制御装置は、
前記複数のスイッチのいずれかに接続された機器の認証処理を行う認証実施部と、
前記機器の認証に成功した場合、前記スイッチに、前記機器と前記ＥＣＵとの通信を実現する前記制御エントリを設定するスイッチ制御部と、
を備える車両内通信システム。
【請求項８】
制御エントリを参照して、車両に搭載されたＥＣＵに入出力されるパケットを中継する複数のスイッチに、前記制御エントリを設定することにより、前記車両内の通信を制御する制御部を備えた制御装置が、
前記複数のスイッチのいずれかを経由して前記ＥＣＵとの通信を試みる機器の認証処理を行うステップと、
前記機器の認証に成功した場合、前記スイッチに、前記機器と前記ＥＣＵとの通信を実現する臨時の制御エントリを設定するステップと、
を含む通信制御方法。
【請求項９】
制御エントリを参照して、車両に搭載されたＥＣＵに入出力されるパケットを中継する複数のスイッチに、前記制御エントリを設定することにより、前記車両内の通信を制御する制御部を備えた制御装置に搭載されたコンピュータに、
前記複数のスイッチのいずれかを経由して前記ＥＣＵとの通信を試みる機器の認証処理と、
前記機器の認証に成功した場合、前記スイッチに、前記機器と前記ＥＣＵとの通信を実現する臨時の制御エントリを設定する処理と、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願についての記載］
本発明は、日本国特許出願：特願２０１８−０６１３５８号（２０１８年３月２８日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、制御装置、車両内通信システム、通信制御方法及びプログラムに関する。
【背景技術】
【０００２】
特許文献１に、ＣＡＮ対応のＥＣＵと、ＣＡＮ以外の通信プロトコルに対応したＥＣＵ間のプロトコル変換を行う車載ゲートウェイ（ＧＷＥＣＵと呼んでいる）が開示されている。また、同文献では、ＣＡＮ対応ＥＣＵからその他プロトコル対応ＥＣＵに不正なメッセージが中継されてしまうことを防ぐため、ゲートウェイが、ＣＡＮ対応ＥＣＵとゲートウェイ間の電圧やＣＡＮ対応ＥＣＵからの通信周期を監視することが記載されている。ここで、ＣＡＮは、Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋの略であり、ＥＣＵは、Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔの略である。【０００３】
特許文献２には、イーサネット（以下、「イーサネット」は登録商標）バスを介して、２つの車載ゲートウェイを２本の通信路で接続し、一方の通信路の障害時に、他方の通信路を用いて通信を継続する構成が開示されている。【０００４】
また、近年、ソフトウェアを用いてネットワークの仮想化を実現するＳＤＮ（Ｓｏｆｔｗａｒｅ  Ｄｅｆｉｎｅｄ  Ｎｅｔｗｏｒｋ）という技術が知られている。非特許文献１は、ＳＤＮを構築するにあたり用いられるオープンフロースイッチの仕様書である。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１６−１１１４７７号公報
【特許文献２】特開２０１７−５６１７号公報
【非特許文献】
【０００６】
【非特許文献１】ＯｐｅｎＦｌｏｗ  Ｓｗｉｔｃｈ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｖｅｒｓｉｏｎ  １．５．１  （Ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ  ０ｘ０６）、ＯＮＦ、［ｏｎｌｉｎｅ］、［平成３０（２０１８）年３月１６日検索］、インターネット〈URL: https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-content/uploads/2014/10/openflow-switch-v1.5.1.pdf〉
【発明の概要】
【発明が解決しようとする課題】
【０００７】
以下の分析は、本発明によって与えられたものである。特許文献１の背景技術欄に記載されているように、車載ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）を実現する各種の規格が提案されている。しかしながら、特許文献１のようなゲートウェイを配置する方式では、対応する通信プロトコルが増えるほど、ＥＣＵとゲートウェイ間の通信線が必要となり全体のハーネス長が長くなってしまうという問題点がある。【０００８】
特許文献２の方式では、２つのＧＷ−ＥＣＵにプロトコル変換機能を持たせるとともに、ＧＷ−ＥＣＵ間をイーサネットバスで接続しているため、ハーネス長を短くできる余地がある。しかしながら、特許文献２の方式では、特許文献１で採用されているようなセキュリティ対策を採ることができないという問題点がある。【０００９】
加えて、次世代型車両では、多数のＥＣＵが搭載され、それらが互いに連携して自動運転に代表されるクリティカルな役割を担うことが想定される。このため、これら多数のＥＣＵの診断やプログラム更新（リプログラミングとも呼ばれる）を効率よく、かつ、適切に行う必要が生じる。一方で、診断の名を借りて、不適切な機器や悪意を持った機器が接続されることを防ぐ必要もある。【００１０】
本発明は、車両に搭載されたＥＣＵの診断やリプログラミングの効率性を確保しつつ、セキュリティリスクの低減に貢献できる制御装置、車両内通信システム、通信制御方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
第１の視点によれば、制御エントリを参照して、車両に搭載されたＥＣＵに入出力されるパケットを中継する複数のスイッチに前記制御エントリを設定することにより、前記車両内の通信を制御する制御部と、前記複数のスイッチのいずれかを経由して前記ＥＣＵとの通信を試みる機器の認証処理を行う認証実施部と、を備え、前記制御部は、前記機器の認証に成功した場合、前記スイッチに、前記機器と前記ＥＣＵとの通信を実現する臨時の制御エントリを設定する制御装置が提供される。【００１２】
第２の視点によれば、制御エントリを参照して、車両に搭載されたＥＣＵに入出力されるパケットを中継する複数のスイッチと、上記した制御装置と、を含む車両内通信システムが提供される。【００１３】
第３の視点によれば、制御エントリを参照して、車両に搭載されたＥＣＵに入出力されるパケットを中継する複数のスイッチに、前記制御エントリを設定することにより、前記車両内の通信を制御する制御部を備えた制御装置が、前記複数のスイッチのいずれかを経由して前記ＥＣＵとの通信を試みる機器の認証処理を行うステップと、前記機器の認証に成功した場合、前記スイッチに、前記機器と前記ＥＣＵとの通信を実現する臨時の制御エントリを設定するステップと、を含む通信制御方法が提供される。本方法は、スイッチに、制御エントリを設定することにより車両内の通信を実現する制御装置という、特定の機械に結びつけられている。【００１４】
第４の視点によれば、上記した制御装置の機能を実現するためのコンピュータプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な（非トランジトリーな）記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。
【発明の効果】
【００１５】
本発明によれば、車両に搭載されたＥＣＵの診断やリプログラミングの効率性を確保しつつ、セキュリティリスクの低減に貢献することが可能となる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態の構成を示す図である。
【図２】本発明の一実施形態の制御装置の構成を示す図である。
【図３】本発明の一実施形態の制御装置の動作を説明するための図である。
【図４】本発明の第１の実施形態の車両内通信システムの構成を示す図である。
【図５】本発明の第１の実施形態の車両内通信システムの模式的構成を示す図である。
【図６】本発明の第１の実施形態の動作を説明するための図である。
【図７】本発明の第１の実施形態の動作を説明するための図である。
【図８】本発明の第１の実施形態の動作を説明するための図である。
【図９】本発明の第１の実施形態の動作を説明するための図である。
【図１０】本発明の第２の実施形態の車両内通信システムの構成を示す図である。
【図１１】本発明の第２の実施形態の車両内通信システムの模式的構成を示す図である。
【図１２】本発明の第２の実施形態の動作を説明するための図である。
【図１３】本発明の第２の実施形態の動作を説明するための図である。
【図１４】本発明の制御装置を構成するコンピュータの構成を示す図である。
【発明を実施するための形態】
【００１７】
はじめに本発明の一実施形態の概要について図面を参照して説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、本発明を図示の態様に限定することを意図するものではない。また、以降の説明で参照する図面等のブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。また、図中の各ブロックの入出力の接続点には、ポート乃至インタフェースがあるが図示省略する。
【００１８】
本発明は、その一実施形態において、図１に示すように、制御エントリを参照して、車両に搭載された複数のスイッチ２０Ａ〜２０Ｃ（以下、スイッチ２０Ａ〜２０Ｃを特に区別しない場合スイッチ２０と記す。）を制御する制御装置１０Ａにて実現できる。
【００１９】
より具体的には、前記複数のスイッチ２０は、制御エントリを参照して、車両に搭載されたＥＣＵ３０Ａ〜３０Ｄ（以下、ＥＣＵ３０Ａ〜３０Ｄを特に区別しない場合ＥＣＵ３０と記す。）に入出力されるパケットを中継する。これらのパケットはＥＣＵ間の通信パケットやＥＣＵとセンサ間のパケットなどが含まれる。なお、図１の例では、ＥＣＵ３０の数は４つであるものとして説明するが、ＥＣＵの数はこれに限定されない。
【００２０】
そして、図２に示すように、制御装置１０Ａは、制御部１１Ａと、認証実施部１２Ａと、を備える。そして、制御部１１Ａは、前記スイッチ２０に制御エントリを設定することにより、前記車両内の通信を制御する。なお、ＥＣＵ３０が他のすべてのＥＣＵと通信する必要はなく、自身の機能に関連する他のＥＣＵやセンサと通信ができればよい。その観点では、制御部１１Ａが、スイッチ２０によって構成されるネットワークを複数のドメインに分割してもよい。
【００２１】
一方、認証実施部１２Ａは、前記複数のスイッチ２０のいずれかを経由してＥＣＵ３０との通信を試みる機器の認証処理を行う。なお、認証処理の方法としては、ＰＩＮコードの入力を求める簡易な方法でもよいし、予め正当なユーザに配布したシリアル番号やパスワードの入力を求めるものであってもよい。また、この認証の際に、認証実施部１２Ａが外部の認証サーバと連携して認証処理を行ってもよい。この場合、認証実施部１２Ａは、外部の認証サーバ（所定の認証装置）に、機器の情報を送信し、この認証サーバから認証結果を受け取ることにより、認証を実施することになる。
【００２２】
例えば、図３に示すように、スイッチ２０Ｂを介して機器４０が接続されたとすると、制御装置１０Ａの認証実施部１２Ａが、機器４０の認証処理を実施する。ここで認証に失敗した場合、制御装置１０Ａの制御部１１Ａは、機器４０とＥＣＵ３０との通信を実現する臨時の制御エントリを設定しない。これにより、不正な機器が車両内のネットワークにパケット等を送出することを防止することができる。
【００２３】
一方、機器４０の認証に成功した場合、制御装置１０Ａは、制御部１１Ａに対し、機器４０とＥＣＵ３０との通信を実現する臨時の制御エントリを設定する。これにより、正当な機器がＥＣＵと通信し、所定の検査やデータ読み出しを行うことが可能となる。また、機器によっては、ＥＣＵ３０側に更新用データを送信し、ＥＣＵ３０内のプログラムの更新（リプログラミング）を行うこともできる。なお、臨時の制御エントリは、非恒久的という意味であり、必要な通信が終わったら、制御装置１０Ａが削除してもよいし、その他、制御エントリにハードタイムアウト値を設定し、一定期間経過後に、自動的に制御エントリを削除させるようにしてもよい。
【００２４】
［第１の実施形態］
続いて、本発明の第１の実施形態について図面を参照して詳細に説明する。図４は、本発明の第１の実施形態の車両内通信システムの構成を示す図である。図４を参照すると、車両内にオープンフローコントローラ（ＯＦＣ）１００と、複数のオープンフロースイッチ（ＯＦＳ）２００Ａ〜２００Ｃとが配置された構成が示されている。なお、以下、オープンフロースイッチ２００Ａ〜２００Ｃを特に区別しない場合、ＯＦＳ２００と記す。
【００２５】
ＯＦＣ１００は、非特許文献１に記載されているオープンフローコントローラ相当の機器であり、上述した制御装置１０Ａに対応する。
【００２６】
ＯＦＳ２００は、ＯＦＣ１００から設定されたフローエントリに従って、通信経路を選択してＥＣＵ３０間の通信やＥＣＵ３０とセンサ間の通信を実現する。図４の例では、ＯＦＳ２００は、リング状に接続されている。なお、このように、ＯＦＳ２００をリング状に接続することで、フロー種別に応じて経路を切り替えたり、いずれかのスイッチ間のリンクに障害が発生した際に、そのリンクを経由しない迂回路をバックアップ経路として利用することが可能となっている。
【００２７】
ＯＦＣ１００とＯＦＳ２００は、図４の破線で示す制御チャネルを介して接続されている。
【００２８】
ＥＣＵ３０は、例えば、エンジン、電動機、バッテリー、変速機など車両の各部を制御する機器である。ＥＣＵ３０は、その種別に応じた送信先に、そのデータ種別に応じた頻度で情報を送信する動作を行う。また、本実施形態では、ＥＣＵ３０は、ＣＡＮ又はイーサネットのいずれかに対応しているものとする。
【００２９】
続いて、上記ＥＣＵ３０間の通信を実現するＯＦＣ１００の構成について図面を参照して詳細に説明する。図５は、本発明の第１の実施形態の車両内通信システムの模式的構成を示す図である。図５のＯＦＣ１００は、ＯＦＳ制御部１０１と、認証実施部１０２と、ネットワーク構成記憶部（ＮＷ構成記憶部）１０３とを備えている。
【００３０】
ＮＷ構成記憶部１０３は、複数のＯＦＳ２００の接続関係と各ＯＦＳに接続されているＥＣＵやセンサ等の情報を記憶する。ＯＦＳ２００間のリンクの通信帯域（データ転送速度）に違いがある場合、これらの情報をＮＷ構成記憶部１０３に保持させておいてもよい。このようにすることで、ＯＦＣ１００に、ＥＣＵ３０と機器４０の通信に必要な通信帯域（データ転送速度）を確保できる経路を計算させることが可能となる。
【００３１】
ＯＦＳ制御部１０１は、ＮＷ構成記憶部１０３を参照して、ＥＣＵ３０間の通信を実現するフローエントリを作成し、ＯＦＳ２００に設定する。なお、ＯＦＣ１００がその都度フローエントリを作成する必要はなく、例えば、一部のフローエントリは車両出荷時に設定されていてもよい。一方、機器やＯＦＳの故障が発生した場合、ＯＦＣ１００が、ＯＦＳ制御部１０１の代替経路や所定のバックアップ用のＥＣＵとの経路を動的に設定してもよい。これらのＯＦＣ１００及びＯＦＳ２００の基本動作は、非特許文献１に記載されているので、説明を省略する。
【００３２】
認証実施部１０２は、所定の機器４０と通信し、その機器４０が正当な機器であるか否かを確認する認証処理を実施する。なお、認証実施部１０２による認証処理の方法は、認証実施部１２Ａと同様、ＰＩＮコードの入力、シリアル番号やパスワードの組の入力のほか、その他生体情報や別の端末の端末固有情報を用いる方式など種々の方法を用いることができる。
【００３３】
続いて、本実施形態の動作について図面を参照して詳細に説明する。以下の説明では、ＯＦＳ２００Ｂに、車両の診断用のコネクタが接続されており、このコネクタに各種のテスターや診断ツールを接続して、目的とするＥＣＵとの通信を試みるものとして説明する。なお、前記車両の診断用のコネクタとしては、ＯＢＤ（Ｏｎ  Ｂｏａｒｄ  Ｄｉａｇｎｏｓｉｓ）や、ＯＢＤ２（ＯＢＤ  ｓｅｃｏｎｄ  ｇｅｎｅｒａｔｉｏｎ）などの規格が知られているがこれに限られるものではない。
【００３４】
例えば、図５の下段に示すように、機器４０がＯＦＳ２００Ｂに接続し、ＥＣＵ３０Ｂに対し、診断通信のリクエストを送信し、通信を試みたものとする。ＯＦＳ２００Ｂは、前記機器４０から受信したパケットにマッチするフローエントリを保持していないため、ＯＦＣ１００に対して、新規通信発生を報告する。
【００３５】
前記報告を受けたＯＦＣ１００は、図６に示すように、機器４０と認証実施部１０２間の通信経路を設定し、認証実施部１０２に機器４０との認証処理を実施させる。先の制御装置１０Ａと同様に、ここで、認証に失敗した場合、ＯＦＣ１００は、機器４０とＥＣＵ３０Ｂとの通信を実現するフローエントリを設定しない。これにより、不正な機器が車両内のネットワークにパケット等を送出することを防止することができる。
【００３６】
前記認証の結果、機器４０の認証に成功した場合、ＯＦＣ１００は、ＮＷ構成記憶部１０３の情報を参照して、機器４０とＥＣＵ３０Ｂ間の経路を計算する。ここでは、ＯＦＳ２００Ａ、２００Ｂを経由する経路が計算されたものとする。次に、ＯＦＣ１００は、該経路上のＯＦＳ２００Ａ、２００Ｂに、機器４０とＥＣＵ３０Ｂとの通信を転送させるフローエントリを設定する。このフローエントリのマッチ条件には、機器４０とＥＣＵ３０Ｂ間の診断用の通信を特定するための情報が設定されていることが好ましい。このような情報としては、機器４０とＥＣＵ３０Ｂのそれぞれの通信アドレスやＵＤＳフレーム内の特定の情報が挙げられる。
【００３７】
以上の結果、図７に示すように、機器４０は、ＥＣＵ３０Ｂと通信し、診断を実施することが可能となる。ここでの診断のプロトコルとしては、ＵＤＳ（Ｕｎｉｆｉｅｄ  Ｄｉａｇｎｏｓｉｓ  Ｓｅｒｖｉｃｅｓ、ＩＳＯ１４２２９）およびＤｉａｇｎｏｓｔｉｃｓ  ｏｎ  ＣＡＮ（ＩＳＯ１５７６５）等が挙げられる。また、通信先のＥＣＵによっては、プロトコル変換が必要となる。その場合は、非特許文献１に例示されているＣＡＮフレームとイーサネットフレームの変換を行うフローエントリをＯＦＳ２００に設定すればよい。
【００３８】
なお、上記の過程で設定するフローエントリは、機器４０による診断用の通信を実現するものであるので、恒久的なものである必要はない。例えば、これらのフローエントリに適切なタイムアウト値を設定してもよいし、あるいは、所定時間の経過後に、ＯＦＣ１００がＯＦＳ２００に明示的にフローエントリを削除する操作を行えばよい。従って、これらのフローエントリは、そのタイムアウトが設定されているか否かに拘わりなく、臨時の制御エントリに相当することになる。
【００３９】
さらに、本実施形態では、オープンフローの仕組みを用いているため、通信の競合、即ち、フローエントリのマッチ条件の競合が発生しない限り、複数の機器による診断を並行して実施することが可能である。例えば、機器４０によるＥＣＵ３０Ｂの診断中に、ＥＣＵ３０Ｃの診断を行うため別の機器４０ＢがＯＦＳ２００Ｂに接続されたものとする。この場合も同様に、ＯＦＳ２００Ｂは、前記機器４０Ｂから受信したパケットにマッチするフローエントリを保持していないため、ＯＦＣ１００に対して、新規通信発生を報告する。
【００４０】
前記報告を受けたＯＦＣ１００は、図８に示すように、機器４０Ｂと認証実施部１０２間の通信経路を設定し、認証実施部１０２に機器４０Ｂとの認証処理を実施させる。
【００４１】
前記認証の結果、機器４０Ｂの認証に成功した場合、ＯＦＣ１００は、ＮＷ構成記憶部１０３の情報を参照して、機器４０ＢとＥＣＵ３０Ｃ間の経路を計算する。ここでは、ＯＦＳ２００Ｂ、２００Ｃを経由する経路が計算されたものとする。次に、ＯＦＣ１００は、該経路上のＯＦＳ２００Ｂ、２００Ｃに、機器４０ＢとＥＣＵ３０Ｃとの通信を転送させるフローエントリを設定する。このように、既存のフローエントリと異なるマッチ条件を持つフローエントリを設定することで、少なくともＥＣＵ３０が異なるＵＤＳ通信を論理的に分離して取り扱うことが可能となる。
【００４２】
以上の結果、図９に示すように、機器４０Ｂは、ＥＣＵ３０Ｃと通信し、診断を実施することが可能となる。ＯＦＳ２００Ｂにおいては、ＯＦＳの一般的な動作と同様に、フローエントリを参照して機器４０とＥＣＵ３０Ｂ間の診断パケットと、機器４０ＢとＥＣＵ３０Ｃ間の診断パケットと、を同時に処理することが可能となる。従って、本実施形態によれば、診断に要する期間を大幅に短縮することが可能となる。その理由は、複数ＥＣＵ３０の診断を並行して実施可能な構成を採用したことにある。
【００４３】
なお、図８、図９の例では、説明の便宜上、機器４０、４０Ｂの２台の機器を示しているが、本実施形態によれば、１台の機器で、同時に複数のＥＣＵの診断を実施することも可能である。この意味でも、本実施形態は、診断に要する期間を大幅に短縮することが可能となる。
【００４４】
［第２の実施形態］
続いて、クラウド側に配置された認証機能と連携して認証処理を実施するようにした第２の実施形態について図面を参照して詳細に説明する。図１０は、本発明の第２の実施形態の車両内通信システムの構成を示す図である。図４に示した第１の実施形態との相違点は、ＯＦＳ２００ＢにＴＣＵ（Ｔｅｌｅ−Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｕｎｉｔ）５００が接続され、ＴＣＵ５００経由でクラウド側の認証機能６００と接続可能となっている点である。その他の構成は第１の実施形態と同様であるので説明を省略する。
【００４５】
図１１は、本発明の第２の実施形態の車両内通信システムの模式的構成を示す図である。図５に示した構成との相違点は、ＯＦＣ１００Ａに認証実施部が省略されている点である。その他の構成は第１の実施形態と同様であるので、以下、第１の実施形態との動作上の相違点を中心に説明する。  
【００４６】
例えば、図１１の下段に示すように、機器４０がＯＦＳ２００Ｂに接続し、ＥＣＵ３０Ｂとの通信を試みたものとする。ＯＦＳ２００Ｂは、前記機器４０から受信したパケットにマッチするフローエントリを保持していないため、ＯＦＣ１００Ａに対して、新規通信発生を報告する。
【００４７】
前記報告を受けたＯＦＣ１００Ａは、図１２に示すように、機器４０とクラウド側の認証機能６００間の通信経路を設定し、クラウド側の認証機能６００に機器４０との認証処理を実施させる。ここで、クラウド側の認証機能６００が、所定の認証装置として機能し、機器４０からの要求に応じて、機器の情報を受信し、認証結果を送信する。先の制御装置１０と同様に、認証に失敗した場合、ＯＦＣ１００Ａは、機器４０とクラウド側のＥＣＵ３０Ｂとの通信を実現するフローエントリを設定しない。これにより、不正な機器が車両内のネットワークにパケット等を送出することを防止することができる。
【００４８】
一方、前記認証の結果、機器４０の認証に成功した場合、ＯＦＣ１００Ａは、第１の実施形態と同様に、ＮＷ構成記憶部１０３の情報を参照して、機器４０とＥＣＵ３０Ｂ間の経路を計算する。次に、ＯＦＣ１００Ａは、該経路上のＯＦＳ２００Ａ、２００Ｂに、機器４０とＥＣＵ３０Ｂとの通信を転送させるフローエントリを設定する。なお、認証結果は、クラウド側の認証機能６００から直接ＯＦＣ１００Ａに送信してもよい。また別の形態として、クラウド側の認証機能６００が、一旦、機器４０に認証結果を送り、機器がＯＦＣ１００Ａに認証結果を提示する形態を採ってもよい。
【００４９】
以上の結果、図１３に示すように、機器４０は、ＥＣＵ３０Ｂと通信し、診断を実施することが可能となる。また、本実施形態においても第１の実施形態と同様に、機器４０はＥＣＵ３０Ｂと通信している間に、別の機器の認証を実施し、当該別の機器とＥＣＵ間の通信を許容することも可能である。
【００５０】
以上説明したように、本実施形態によっても、ＥＣＵの診断やリプログラミングの効率性と、セキュリティリスクの低減とを両立することが可能となる。
【００５１】
また、上記第２の実施形態の説明では省略したが、ＴＣＵ５００が新規に接続された場合も認証処理を行ってもよい。この場合は、ＯＦＣ１００Ａに、第１の実施形態のＯＦＣ１００の認証実施部１０２を追加することが考えられる。
【００５２】
以上、本発明の各実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。例えば、各図面に示したネットワーク構成、各要素の構成、メッセージの表現形態は、本発明の理解を助けるための一例であり、これらの図面に示した構成に限定されるものではない。また、以下の説明において、「Ａ及び／又はＢ」は、Ａ及びＢの少なくともいずれかという意味で用いる。
【００５３】
また、上記した実施形態では、認証実施部１２Ａ、１０２が機器４０と認証処理を行う者として説明したが、ＥＣＵ３０側に認証機能がある場合、その認証機能を用いる構成も採用可能である。例えば、機器４０から、セキュリティ認証のＳＥＥＤ要求を送信すると、制御装置ないしＯＦＣがＥＣＵ３０にＳＥＥＤ要求を転送する。そして、ＥＣＵ３０から、ＳＥＥＤ要求に対する応答がなされると、制御装置ないしＯＦＣは機器４０に返送する。そして、機器４０が、前記ＳＥＥＤを用いたＫＥＹを計算し、ＥＣＵ３０に送信すると、制御装置ないしＯＦＣがＥＣＵ３０にＫＥＹを転送する。その結果により、制御装置ないしＯＦＣが認証に成功したか否かを判定してもよい。この場合、認証実施部１２Ａ、１０２は、機器４０とＥＣＵ３０間の認証処理を仲介することになる。
【００５４】
例えば、上記した実施形態では、オープンフローを用いて車両内のスイッチを制御するものとして説明したが、オープンフロー以外の方式を用いて本発明を実現することも可能である。
【００５５】
また、上記した第１、第２の実施形態に示した手順は、制御装置又はＯＦＣとして機能するコンピュータ（図１４の９０００）に、これらの装置としての機能を実現させるプログラムにより実現可能である。このようなコンピュータは、図１４のＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）９０１０、通信インタフェース９０２０、メモリ９０３０、補助記憶装置９０４０を備える構成に例示される。すなわち、図１４のＣＰＵ９０１０にて、スイッチ制御プログラムや認証処理プログラムを実行し、その補助記憶装置９０４０等に保持された各計算パラメーターの更新処理を実施させればよい。
【００５６】
即ち、上記した第１、第２の実施形態に示した制御装置又はＯＦＣの各部（処理手段、機能）は、制御装置又はＯＦＣに搭載されたプロセッサに、そのハードウェアを用いて、上記した各処理を実行させるコンピュータプログラムにより実現することができる。
【００５７】
最後に、本発明の好ましい形態を要約する。
［第１の形態］
（上記第１の視点による制御装置参照）
［第２の形態］
上記した制御装置が臨時の制御エントリを設定する機器は、テスター又はＴｅｌｅｍａｔｉｃｓ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｕｎｉｔであることが好ましい。
［第３の形態］
上記した制御装置の前記認証実施部は、所定の認証装置に、前記機器の情報を送信し、所定の認証装置から認証結果を受け取ることにより、認証を実施する形態を採ることができる。
［第４の形態］
上記した制御装置の前記制御部は、
前記機器と前記ＥＣＵ間の通信同士が競合しない範囲で、機器とＥＣＵの複数の組に対して通信を許可する構成を採ることができる。
［第５の形態］
上記した制御装置の前記制御部は、
前記スイッチに対し、前記機器と前記ＥＣＵ間のプロトコルの変換を実施させる制御エントリを設定することもできる。
［第６の形態］
上記した制御装置が臨時の制御エントリを設定する機器は、前記ＥＣＵのプログラムを更新する更新用データを用いたリプログラミング処理を行う機器であってもよい。
［第７の形態］
（上記第２の視点による車両内通信システム参照）
［第８の形態］
（上記第３の視点による通信制御方法参照）
［第９の形態］
（上記第４の視点によるプログラム参照）
なお、上記第７〜第９の形態は、第１の形態と同様に、第２〜第６の形態に展開することが可能である。
【００５８】
なお、上記の特許文献および非特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし選択（部分的削除を含む）が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。
【符号の説明】
【００５９】
１０Ａ  制御装置
１１Ａ  制御部
１２Ａ  認証実施部
２０、２０Ａ〜２０Ｃ  スイッチ
３０、３０Ａ〜３０Ｄ  ＥＣＵ
４０、４０Ｂ  機器
１００、１００Ａ  オープンフローコントローラ（ＯＦＣ）
２００、２００Ａ〜２００Ｃ  オープンフロースイッチ（ＯＦＳ）  
１０１  ＯＦＳ制御部
１０２  認証実施部
１０３  ネットワーク構成記憶部（ＮＷ構成記憶部）
５００  ＴＣＵ
６００  認証機能
９０００  コンピュータ
９０１０  ＣＰＵ
９０２０  通信インタフェース
９０３０  メモリ
９０４０  補助記憶装置
【図１】
2019187204.tif 000003
【図２】
2019187204.tif 000004
【図３】
2019187204.tif 000005
【図４】
2019187204.tif 000006
【図５】
2019187204.tif 000007
【図６】
2019187204.tif 000008
【図７】
2019187204.tif 000009
【図８】
2019187204.tif 000010
【図９】
2019187204.tif 000011
【図１０】
2019187204.tif 000012
【図１１】
2019187204.tif 000013
【図１２】
2019187204.tif 000014
【図１３】
2019187204.tif 000015
【図１４】
2019187204.tif 000016
【国際調査報告】
2019187204.tif 000017
2019187204.tif 000018