(57)【要約】【課題】コンパクトであり、電力消費が少なく、かつホスト・システムと通信するための異なるインタフェースを提供することができる装置を提供する。【解決手段】ホスト・システムとネットワーク内のデバイスの間の通信を制御するための装置であって、装置は、これらのデバイスと通信するための診断インタフェースと、ホスト・システムと通信するためのＷＬＡＮインタフェースと、ＷＬＡＮインタフェースを介した装置とホスト・システムの間のデータ通信を制御するためのＷＬＡＮモジュールと、ホスト・システムと通信するためのデータを準備するための診断モジュールと、診断モジュールとデバイスの間の通信を制御するための通信モジュールとを備えており、ＷＬＡＮモジュールおよび診断モジュールは共通のＷＬＡＮプロセッサ内で実施され、通信モジュールは個別の通信プロセッサ内で実施され、プロセッサは実時間オペレーティング・システムを含む。【選択図】図２
2014042232.tif 000002
【特許請求の範囲】
【請求項１】
ホスト・システム（２４）とネットワーク（２６）内のデバイスとの間の通信を制御するための装置であって、前記装置が、
前記デバイスと通信するための診断インタフェースと、
前記ホスト・システム（２４）と通信するためのＷＬＡＮインタフェースと、
前記ＷＬＡＮインタフェースを介した前記装置と前記ホスト・システムとの間のデータ通信を制御するためのＷＬＡＮモジュールと、
前記ホスト・システム（２４）との通信のためのデータを準備するための診断モジュールと、
前記診断モジュールと前記デバイスとの間の通信を制御するための通信モジュールと
を備え、
前記ＷＬＡＮモジュールおよび前記診断モジュールが共通のＷＬＡＮプロセッサの中で実施され、
前記通信モジュールが個別の通信プロセッサの中で実施され、当該プロセッサが実時間オペレーティング・システムを含む
装置。
【請求項２】
前記ＷＬＡＮプロセッサ（２２）が非実時間オペレーティング・システムを含む、請求項１に記載の装置。
【請求項３】
前記ホスト・システム（２４）と通信するためのＵＳＢインタフェースおよびＥｔｈｅｒｎｅｔインタフェースのうちの少なくとも１つをさらに備え、前記ＷＬＡＮモジュールが、前記ＵＳＢインタフェースまたは前記Ｅｔｈｅｒｎｅｔインタフェースを介した前記装置（２０）と前記ホスト・システム（２４）との間のデータ通信も制御する、請求項１または請求項２に記載の装置。
【請求項４】
前記診断モジュールが、前記インタフェースのうちの１つを介して前記ホスト・システム（２４）から受け取られるメッセージを前記デバイスのための制御コマンドに変換し、また、前記デバイスの応答を前記ホスト・システム（２４）に送られるメッセージに変換する、請求項１ないし３の一項に記載の装置。
【請求項５】
前記通信モジュールが、前記診断モジュールの制御コマンドを定義済みの車両通信プロトコルに従って制御信号に変換し、また、前記デバイスの応答信号を前記ＷＬＡＮプロセッサ（２２）の通信プロトコルに従って応答に変換する車両通信モジュールとして機能する、請求項１ないし４の一項に記載の装置。
【請求項６】
前記診断モジュールが前記デバイスの運転データを検出し、かつ、記憶する、請求項１ないし５の一項に記載の装置。
【請求項７】
前記ＷＬＡＮモジュールが接続の品質に関するパラメータを検出し、かつ、記憶する、請求項１ないし６の一項に記載の装置。
【請求項８】
前記ＷＬＡＮプロセッサ（２２）が、前記通信プロセッサ（３０）の前記実時間オペレーティング・システムよりも速いクロック速度および大きいメモリを有する、Ｌｉｎｕｘなどの汎用オペレーティング・システムを備える、請求項１ないし７の一項に記載の装置。
【請求項９】
前記通信プロセッサ（３０）の電力消費が前記ＷＬＡＮプロセッサ（２２）の電力消費より少ない、請求項１ないし８の一項に記載の装置。
【請求項１０】
前記ＷＬＡＮプロセッサ（２２）を電力節約モードに置くように構成される、請求項１ないし９の一項に記載の装置。
【請求項１１】
前記通信プロセッサ（３０）がメッセージを受け取ると前記ＷＬＡＮプロセッサを起動する、請求項１０に記載の装置。
【請求項１２】
前記装置が前記ＷＬＡＮプロセッサ（２２）を起動するために動かされると信号を生成する運動センサをさらに含む、請求項１０または１１に記載の装置。
【請求項１３】
前記ＷＬＡＮモジュールがＷＬＡＮアクセス・ポイントを提供するように構成される、請求項１ないし１２の一項に記載の装置。
【請求項１４】
前記ＷＬＡＮプロセッサ（２２）および前記通信プロセッサ（３０）が回路基板上に搭載され、前記回路基板が、前記ホスト・システム（２４）と通信するための前記インタフェースと、前記ネットワーク（２６）内のデバイスと通信するための前記診断インタフェースとの間の完全なガルヴァニック分離を提供する、請求項１ないし１３の一項に記載の装置。
【請求項１５】
ハウジング（４０）を含み、前記ハウジングの寸法が１２０ｍｍ×５０ｍｍ×２５ｍｍ以下である、請求項１ないし１４の一項に記載の装置。
【請求項１６】
前記ハウジング（４０）が機械的なスイッチを全く有していない、請求項１５に記載の装置。
【請求項１７】
前記ハウジング（４０）が１つまたは２つの射出成形部品で作られており、前記診断インタフェースのプラグ（４２）が前記射出成形部品のうちの一つに統合される、請求項１５または請求項１６に記載の装置。
【請求項１８】
前記装置（２０）を制御するための容量性スイッチをさらに備える、請求項１ないし１７の一項に記載の装置。
【請求項１９】
前記Ｅｔｈｅｒｎｅｔインタフェースが、接触要素（４６）への電気的接続システムおよび少なくとも１つの磁気デバイスを備え、前記磁気デバイスが、アダプタ（５０）の相手側接触要素を前記接触要素（４６）に接触させ、かつ、それらの接触を維持する、請求項３および請求項１ないし１８の一項に記載の装置。
【請求項２０】
前記Ｅｔｈｅｒｎｅｔインタフェースが、前記インタフェースに接続されると、前記アダプタ（５０）を介して起動されることができるリセット入力を備える、請求項１９に記載の装置。
【請求項２１】
前記診断インタフェースが、フィールド・バス・インタフェース、詳細にはオンボード診断（ＯＢＤ）インタフェース、またはＣＡＮあるいはＥｔｈｅｒｎｅｔなどの他のフィールド・バス・インタフェースであり、前記ホスト・システム（２２）と前記診断インタフェースとの間の通信がフィールド・バスを介して提供される、請求項１ないし２０の一項に記載の装置。
【請求項２２】
前記デバイスが、制御デバイス、センサまたは制御ユニットである、請求項１ないし２１の一項に記載の装置。
【請求項２３】
前記デバイスが、車両または産業設備の制御デバイス、センサ・デバイスまたは制御ユニットである、請求項１ないし２２の一項に記載の装置。
【請求項２４】
前記ネットワークが自動車両のオンボード・ネットワークである、請求項１ないし２３の一項に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ホスト・システムと自動車両のオンボード・ネットワーク内の制御デバイスとの間の通信を制御するための装置に関する。このような装置は、従来技術では車両通信インタフェースＶＣＩとして知られている。
【背景技術】
【０００２】
現在の自動車両には極めて多くの制御デバイスおよび制御コンピュータ、ならびにセンサ・デバイスが使用されている。それらは、バス・システムとして実現されることができるオンボード・ネットワークを介して車両内で接続され、互いの間でデータを交換することができる。また、それらは、インタフェースを介してランキングがより高い外部のホスト・システムによってアドレス指定されることができる。制御デバイス、制御コンピュータおよびセンサ・デバイスは、以下では制御デバイスと呼ばれているが、極めて多くの異なる制御機能および監視機能を実行し、また、それらは、電動機および歯車制御、アンチ−ブロッキング・システム、等々などの複雑なシステムの一部である。制御デバイスは、ブレーキ減速などの時間に厳格なプロセスを制御することができなければならないため、これらの制御デバイスは、細かい時間パターン内および／または実時間で動作することができなければならない。したがって、これらの制御デバイス間の通信もこの細かい時間パターン内で、実時間で実現されなければならない。また、車両の制御デバイスからの外部通信／車両の制御デバイスへの外部通信のために、実時間で動作することができるシステムを有している必要があり、このようなシステムは、通常、車両通信インタフェースＶＣＩと呼ばれている。ＶＣＩは、サービス・コンピュータまたは診断コンピュータなどの、実時間で動作することができない、一般的には通例のＰＣであるホスト・システムと車両の実時間通信との間の中間部分、すなわちインタフェースである。車両の制御デバイスと通信するために、Ｋ−Ｌｉｎｅ、Ｌ−ＬｉｎｅまたはＣＡＮ（コントローラエリアネットワーク）バスのための標準化されたプロトコルなどの多くの車両特化プロトコルが存在している。さらに、ＶＣＩは、１２Ｖまたは２４Ｖなどの車両の電圧レベルへのホスト・システムの適合、およびホスト・システムからの車両のオンボード・システムのガルヴァニック分離（ｇａｌｖａｎｉｃ  ｓｅｐａｒａｔｉｏｎ）などのハードウェア・タスクを引き受けることができる。診断バスであるＫ−ＬｉｎｅおよびＣＡＮは、例えばＰＣと比較すると異なる物理的特性を有しており、したがって、ＶＣＩは、物理層通信（例えばＩＳＯ／ＯＳＩモデルによる通信）を引き受けることも可能である。この場合、ＶＣＩは、ＩＳＯ／ＯＳＩモデルによるゲートウェイであり、プロトコルに応じて層１から７のうちの１つまたは複数を実現する。ＶＣＩは、通信に加えて、例えば点火を検出するためのディジタル入力の提供、例えば車両の複数の機能を切り換えるためのディジタル出力の提供、例えば電池電圧を測定するためのアナログ入力の提供、および例えば特定のプロトコルを支援するためのアナログ出力の提供などの他のタスクを引き受けることができる。
【０００３】
ＶＣＩは、通常、少なくとも３つのタスク、つまり車両のオンボード・ネットワーク内の制御デバイスとの実時間通信、ホスト・システムとの通信のためのデータの準備、異なる通信プロトコルの考慮、ホスト・システムへのデータの送信およびホスト・システムからのデータの受信を有している。ホスト・システムと通信するために、ＵＳＢインタフェース、Ｅｔｈｅｒｎｅｔインタフェース（Ｅｔｈｅｒｎｅｔは登録商標）、ＷＬＡＮインタフェースを支援する利用可能な異なるデバイスが存在しており、あるいはＢｌｕｅｔｏｏｔｈまたはＧＳＭ／ＵＭＴＳを介した通信が同じく存在している。したがって、ＶＣＩの主要なタスクは、車両とホスト・システムの間の、詳細には診断を目的とした通信インタフェースの準備であり、ＶＣＩが診断インタフェースとも呼ばれているのはそのためである。さらに、ＶＣＩは、試験走行中における車両の運転データ、走行距離および現在位置の記録（データロギング）、車両のオンボード・ネットワークへの新しいファームウェアのアップロード（フラッシング）、ならびにバス・アクセスおよび接続品質のプロトコル（アナライザ）の提供などの他のタスクを引き受けることができる。
【０００４】
上記複数のタスクのうちの１つまたは複数を実行する通例の診断インタフェースは、例えばドイツのＡａｃｈｅｎにあるＤａｔｅｎ−ｕｎｄ  ｓｙｓｔｅｍｔｅｃｈｎｉｋ  ＧｍｂＨの無線診断インタフェースＷＤＩおよび診断インタフェースＭＤＩ−Ｇ、ドイツのＨａａｒにあるＳｏｆｔｉｎｇ  ＡＧの診断無線デバイス、ＶＡＳ  ５０５４Ａ、およびドイツのＳｉｎｄｅｌｆｉｎｇｅｎにあるＢｅｒｇｅｒ  Ｅｌｅｃｔｒｏｎｉｃの無線ＯＢＤインタフェース、「Ｉｎｔｅｌｌｉｇｅｎｃｅ  Ｓｔａｒ  Ｉｎｔｅｒｆａｃｅ  Ｌｏｇｇｅｒ」である。Ｂａｙｅｒｉｓｃｈｅ  Ｍｏｔｏｒｅｎｗｅｒｋｅ  ＡＧのＤＥ  １０  ２００４  ００５  ６８０  Ａ１およびＡｃｔｉａ  Ａｕｔｏｍｏｔｉｖｅ  ＥｌｅｃｔｒｏｎｉｃｓのＣＮ  １０２１２０４４１Ａにデバイスがさらに記載されている。欧州特許第０３７４９９８（Ｂ１）号明細書、ＥＰ  １  ９９２  ９３２  Ａ２およびＥＰ  ２  ０３７  ４２０  Ａ２に他の診断インタフェースが記載されている。
【０００５】
したがって、要約すると、ＰＣなどのホスト・システムと車両のオンボード・ネットワークとの間の通信を制御することはＶＣＩの重要なタスクである。ＰＣとの通信は、例えばＷＬＡＮ、ＵＳＢターミナルまたはＥｔｈｅｒｎｅｔバスを介してなされてもよく、また、車両のオンボード・ネットワークへの通信は、例えば標準のＣＡＮまたはＫ−ＬｉｎｅによるＯＢＤ（オンボード診断）インタフェースを介してなされてもよい。さらに、ＶＣＩは、データ・ロギングおよびフラッシングなどのタスクを引き受けることができるが、同じくシミュレータまたはプロトコル・アナライザのタスクを引き受けることも可能である。ＯＢＤインタフェースの基本機能は誤りの診断であり、車両を診断するためのデータは、定義されたＯＢＤピン上で読み出されてもよい。ＯＢＤピンの残りの構成は製造者に特化されており、車両内の制御デバイスとの通信を可能にする。通信の基本は、概して標準的な質問／応答シナリオであり、制御デバイスが期待されたように応答しない場合、誤りが検出される。例えばＶＣＩが取り付けられ、かつ、モニタが制御デバイスと通信する車両の製造中に診断が実施される場合、車両を完全に組み立てて試験する必要がなく、誤りは、制御デバイスを使用して機能試験を実施することにより、個々の構成要素の組立て後に直ちに検出されることができるため、製造作業の流れを最適化することができる。
【０００６】
ホスト・システムと車両のオンボード・ネットワークとの間の通信は、共通のシナリオで以下のように実施することができ、つまりホスト・システムが、ＴＣＰ／ＩＰプロトコルに従って、例えばＷＬＡＮを介してＶＣＩへの接続を初期化する。次に、ホスト・システムがＶＣＩに、オンボード・ネットワーク内の制御デバイスがＶＣＩと通信すべきであることを知らせ、ＶＣＩは、ＣＡＮまたはＫ−Ｌｉｎｅなどの車両特化通信プロトコルに従ってこれらの制御デバイスとの通信を開始する。ホスト・システムはＶＣＩに要求を送り、ＶＣＩはこの要求を車両特化通信プロトコルに従った要求に翻訳し、かつ、要求を制御デバイスに送る。それに応じてプロトコルが再翻訳された後、制御デバイスの応答がＶＣＩからホスト・システムに送り返される。実際には、制御デバイスは、製造者特化である時間パターン内で要求を期待する。例えば（仮説の）制御デバイスの場合、２つのＣＡＮフレーム間の時間距離は１００ｍｓでなければならないが、１ｓより長くすることはできない。したがって、ＣＡＮフレームは、最も速い可能伝送速度を達成するためには、１００ｍｓの速度または可能な限り１００ｍｓに近い速度で送られるべきである。
【０００７】
上記タスクを実現するために、市場で入手可能な診断インタフェース（ＶＣＩ）は、ランキングがより高いホスト・システムと車両のオンボード・ネットワークとの間の通信を制御する実時間オペレーティング・システムを始めとする専用マイクロプロセッサを使用している。多くの場合、マイクロコントローラ、すなわちＲＡＭ、ＲＯＭを始めとするマイクロプロセッサおよび通信インタフェースが使用されている。これは、少ないハードウェア資源、少ない電力消費および安価なコストの維持を補助している。埋設されたソフトウェアまたはファームウェアは、複数の車両特化プロトコルの個々の特殊性を知る指定通信プロトコル、ソフトウェアまたはファームウェアに従って、ホスト・システムと車両の制御デバイスとの間で要求および応答を移送し、かつ、翻訳するためにオペレーティング・システム上で動作している。このプロトコル翻訳中、デバイス・データ、例えば制御デバイスから送られる動作パラメータは不変を維持する。
【０００８】
従来技術には、ＷＬＡＮを介した通信を診断インタフェースに許容するための異なる解決法が存在している。１つの手法は、インタフェースを表すＰＣＩまたはＰＣＩを介したＷＬＡＮアクセスを提供することであるが、これには、線とドライバ・デバイスを接続するための比較的広い空間が必要であり、必然的に多くの電力消費を伴っている。ＷＬＡＮアクセスを提供するための他の手法はＵＳＢインタフェースを使用することである。しかしながら、これには必然的に長い待ち時間が伴い、すべてのＷＬＡＮ規格に対して実現されることは不可能であり、例えば複数のチャネルを支援する規格８０２．１１ｎに対しては不可能である。したがって、他の解決法は追加のＷＬＡＮモジュールを使用しているが、より小さい診断デバイス内に収納されることはできず、したがって、ＶＣＩ自身の外部に提供されなければならない。既製のＷＬＡＮモジュールは、大きすぎるか、あるいは誤った形状を有しているかのいずれかであり、したがって、それらは、特定の総体積および／または形状に従わなければならない診断インタフェースに適合されることはできない。また、すべてのＷＬＡＮ要求に従うＷＬＡＮモジュールは、同じくはるかに多くの電力を消費し、および／または大きすぎる。
【０００９】
また、理論的には、ホスト・システム、例えばＰＣは、車両のオンボード・ネットワーク内の制御デバイスと直接通信することが可能である。しかしながら、そのためにはＰＣソフトウェアは、車両特化プロトコルのすべての変形を支援することができなければならないことになる。単純な車両においてさえ、異なるプロトコル、例えばＫ−Ｌｉｎｅを介したプロトコルＫＷＰ  ２０００およびＣＡＮバスを介したプロトコルＵＤＳが使用される可能性は十分にある。したがって、個々のＰＣは、それに応じてプログラムされなければならないことになり、それは大きな投資になる。問題の１つは、車両通信の主要な部分が規格化されておらず、また、公に知られていないため、個々のコンピュータのＰＣソフトウェアは、正確なプロトコルおよびＯＢＤピンを知る必要があることによってもたらされる。しかしながらこれは製造者によって支援されていない。さらに、ＰＣ上では、車両インタフェースの時限要求事項および他の特殊性を実行することは、途方もない高価な代償を払ってのみ可能である。これは、通常のＰＣ応用の計算能力にとっては負担が大きすぎることになる。時限は、例えばプロトコルに応じて個々のビットに到るまで制御されなければならない。さらに、物理的な端末（ＣＡＮ信号の変換）を提供するハードウェアが要求される。このハードウェアは、ＰＣＩまたはＵＳＢのいずれかを介してＰＣに結合されなければならないことになり、そのためにこの場合もマイクロプロセッサが必要になる。したがって、このような解決法は、その実践が追求されていないため、ホスト・システムとオンボード・ネットワークとの間で通信する場合、ＶＣＩの使用が一般的である。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】ＤＥ  １０  ２００４  ００５  ６８０  Ａ１
【特許文献２】ＣＮ  １０２１２０４４１Ａ
【特許文献３】欧州特許第０３７４９９８（Ｂ１）号明細書
【特許文献４】ＥＰ  １  ９９２  ９３２  Ａ２
【特許文献５】ＥＰ  ２  ０３７  ４２０  Ａ２
【特許文献６】ＤＥ  １０  ２０１０  ０２８  ７９１  Ａ１
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明の目的は、ホスト・システムと車両のオンボード・ネットワーク内の制御デバイスとの間の通信を制御するための装置であって、コンパクトであり、電力消費が少なく、かつ、ＷＬＡＮインタフェースを始めとする、ホスト・システムと通信するための異なるインタフェースを提供することができる装置を提供することである。
【課題を解決するための手段】
【００１２】
この目的は請求項１による装置によって解決される。本発明の実施形態は従属請求項の中で定義されている。
【００１３】
本発明は、ホスト・システムと、ネットワーク、詳細には車両のオンボード・ネットワーク内のデバイスとの間の通信を制御するための装置を提供する。デバイスは、例えば車両または産業設備の制御デバイス、センサおよび制御ユニットであってもよい。装置は、制御デバイスと通信するための診断インタフェース、詳細にはＯＢＤインタフェースと、ホスト・システムと通信するためのＷＬＡＮインタフェースとを備えている。ＷＬＡＮインタフェースを介した装置とホスト・システムとの間のデータ伝送を制御するためのＷＬＡＮモジュールが提供され、装置と制御デバイスの間の通信を制御するための通信モジュールが提供される。ホスト・システムとの通信のためのデータを装置内で準備するための診断モジュールが提供される。ＷＬＡＮモジュールおよび診断モジュールは共通のＷＬＡＮプロセッサの中で実施（ｉｍｐｌｅｍｅｎｔ）され、また、通信モジュールは、実時間で動作することができるオペレーティング・システムを含んだ個別の通信プロセッサの中で実施（ｉｍｐｌｅｍｅｎｔ）される。通信モジュールは、一例では車両通信モジュールであり、また、この例では通信プロセッサは車両通信プロセッサである。知られている診断インタフェースと比較すると、本発明の装置の場合、複数のタスクが装置の様々な構成要素間で別様に分散される。本発明とは異なり、従来技術の場合、診断モジュールの機能および車両通信モジュールの機能は、（任意選択で）ＷＬＡＮインタフェースを提供するための個別の無線モジュールを提供している間、実時間オペレーティング・システムを有する共通の専用マイクロプロセッサの中で実現されている。従来技術の場合、ハードウェア計算能力の重点は、車両通信モジュールとの統合のため、実時間オペレーティング・システム上で走ることができたに違いない診断モジュールにあり、実際にはこれには車両診断のための比較的性能が高い高価な専用プロセッサが必要であった。本発明は、通信装置内の複数のタスクの異なる分散を提供するため、診断モジュールの計算集約機能を、実時間で動作しない、さらには実時間で動作することができないオペレーティング・システムを有することができるＷＬＡＮプロセッサに移すことができる。本発明は、大量市場目的のためのＷＬＡＮネットワークの大衆性のため、ＷＬＡＮプロセッサの性能が絶えず改善されていることを利用している。ＷＬＡＮネットワークでは、データの機密保護を改善するためにますます複雑な暗号化技術が使用されるため、通例のＷＬＡＮプロセッサの計算能力も同じく改善される必要があり、したがって、ＷＬＡＮプロセッサの計算能力は、車両診断インタフェースのための利用可能な専用プロセッサの計算能力より優れている。大量市場の大きい商用的圧力のため、ますます多くのＷＬＡＮ機能が既知のＷＬＡＮプロセッサに統合され、これらの機能は、単一チップ解決法の中に提供されている。電力消費および空間要求事項は最適化されているが、自動車市場における知られている制御コンピュータに関しては同様の傾向は存在していない。
【００１４】
したがって、本発明は、ホスト・システムとの通信のためのデータを処理するタスク、つまり診断モジュールのタスクおよびホスト・システムと通信するタスクの一部をこれらの通例のＷＬＡＮプロセッサのうちの１つに移し、一方、車両の制御デバイスと通信する残りのタスク、つまり車両通信モジュールのタスクは、単純な車両通信プロセッサに属している。実時間オペレーティング・システムを有する必要があるのはこの車両通信プロセッサのみであるが、車両通信プロセッサが処理しなければならないタスクはより少ないため、車両通信プロセッサは、より狭い空間要求事項およびより少ない電力消費を使用して構成されてもよい。同じく診断モジュールのタスクを引き受けるＷＬＡＮプロセッサは、実時間で動作することができる必要はなく、したがって、空間要求事項および電力消費に関して同じく最適化されることができる。したがって、本発明は、現在の通例のＷＬＡＮプロセッサは高い計算能力を有しており、また、Ｌｉｎｕｘなどの標準のオペレーティング・システムを使用して動作し、さらに、それらのプロセッサ能力に関して他の計算チップに匹敵し、したがって、それらはＷＬＡＮ通信以外のデータ処理タスクにも適していることを利用している。
【００１５】
通例のＷＬＡＮプロセッサは、入力および出力に関して、ＷＬＡＮおよびＥｔｈｅｒｎｅｔなどのネットワーク機能に限られているため、また、通例のＷＬＡＮプロセッサは、通常、実時間で動作することができないため、車両すなわち車両通信プロセッサと通信するために追加専用ハードウェアが使用される。必要な車両通信インタフェースおよびその中に統合されたＷＬＡＮプロセッサへのインタフェースを有する任意のチップが車両通信プロセッサとして使用されてもよい。車両通信プロセッサは、実時間で動作することができるべきであり、例えば割込み構造を有しているが、この車両通信プロセッサには、特定のプロセッサ能力は一切不要であり、また、複雑なオペレーティング・システムも不要である。したがって、車両通信プロセッサは、比較的小さく、電力消費が少ないプロセッサであってもよい。
【００１６】
ＷＬＡＮプロセッサと車両通信プロセッサとの間の可能インタフェースは、極めて強力で、かつ、小さいターミナルを有し、したがって、必要な空間が狭いＥｔｈｅｒｎｅｔインタフェースである。
【００１７】
また、ホスト・システムと通信するための装置の一例は、ＷＬＡＮインタフェースに加えて、ＵＳＢインタフェースおよびＥｔｈｅｒｎｅｔインタフェースのうちの少なくとも１つを含み、また、それらはいずれもＷＬＡＮモジュールによって起動または制御されてもよい。
【００１８】
また、診断モジュールは、ホスト・システムとの通信のためのデータの準備に加えて、制御デバイスの制御データを検出し、かつ、しまっておくように構成されてもよく、車両の診断は、最終的にはランキングがより高いホスト・システムによって実施されることになる。運転データのこのロギングは、誤りを調査するために使用されても、あるいは単純に、例えば消費および速度などの運転データを検出するために使用されてもよい。一方、診断モジュールは、フラッシングなどによって車両の制御デバイス内のソフトウェアまたはファームウェアを更新するために同じく使用されてもよい。
【００１９】
また、ＷＬＡＮモジュールは、ホスト・システムへの通信の制御に加えて、接続および通信の品質に関するパラメータを決定し、かつ、記憶するように構成されてもよい。さらに、ＷＬＡＮモジュールは、データ・ロギングのための携帯型コンピュータ、データを表示するためのＰＤＡ（Ｐｅｒｓｏｎａｌ  ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）またはＳｍａｒｔ  ＰａｄあるいはｉＰａｄ等々などのＴａｂｌｅｔ  Ｃｏｍｐｕｔｅｒ、およびＧＰＳまたはＵＭＴＳゲートウェイなどの追加デバイスなどの、車両内のＷＬＡＮ能力を有するすべてのデバイスを接続するためのＷＬＡＮアクセス・ポイントを提供するように構成されてもよい。また、ＷＬＡＮモジュールは、例えば試験走行中に主車両のデータを収集し、走行中に予めこのデータが評価され、かつ、比較されてもよいよう、車両間の通信（車対車の通信）を支援することも可能である。
【００２０】
しかしながら、装置の基本機能は制御デバイスの診断であり、車両内の制御デバイスに対する試験を実施すること、および車両を製造している間、または車両を修理している間に車両内のソフトウェアまたはファームウェアを更新することである。異なるインタフェースおよび異なるハウジング形状を提供することにより、車両内のアクセスが困難な場所に取り付けられている場合であっても、例えば邪魔なケーブル布線を提供する必要なく、装置は多目的で使用されることができ、また、外部ホスト・システムと通信することができる。極めて強力なＷＬＡＮモジュールおよび統合されたＷＬＡＮアンテナを提供することにより、デバイスは、ドアが閉まると、車両から同報通信することさえ可能である。
【００２１】
上で説明したように、一例では、ＷＬＡＮプロセッサは、Ｌｉｎｕｘなどの多目的オペレーティング・システムを有することができる。より詳細には、ＷＬＡＮプロセッサは、より速いクロック速度を使用して動作することができ、また、ＷＬＡＮプロセッサは、車両通信プロセッサの実時間オペレーティング・システムより大きいメモリを有することができる。車両通信プロセッサの電力消費は、通常、ＷＬＡＮプロセッサの電力消費より少ないことが期待されてもよいが、両方のプロセッサの電力消費は、これまで通例の診断インタフェースに使用されている専用マイクロプロセッサの電力消費より依然として相当少ない。
【００２２】
一例では、ＷＬＡＮプロセッサは電力節約モードに置かれてもよく、また、車両通信プロセッサは、車両からメッセージを受け取ると、ＷＬＡＮプロセッサを起動する、すなわち動作させるように構成されてもよい。そのために、車両通信プロセッサは車両通信を中断することができる。他の例では、車両通信プロセッサに結合される運動センサが提供されてもよく、この運動センサは、運動が検出されると、車両通信プロセッサを動作させてＷＬＡＮモジュールを起動する。
【００２３】
一例では、ＷＬＡＮプロセッサおよび車両通信プロセッサは、いずれも、ホスト・システムと通信するためのインタフェースと、車両の制御デバイスと通信するための診断インタフェースとの間の完全なガルヴァニック分離を提供する回路基板上に搭載される。ＥｔｈｅｒｎｅｔがＷＬＡＮプロセッサと車両通信プロセッサの間のインタフェースとして選択されると、これは、このインタフェースによってこれらの２つのプロセッサ間の所望のガルヴァニック分離が固有に（ｉｎｈｅｒｅｎｔｌｙ）実現されるというさらなる利点を有する。装置は、いずれにしてもＥｔｈｅｒｎｅｔインタフェースに提供されるガルヴァニック分離を単純に使用する。
【００２４】
一例では、装置は、小さいコンパクトなハウジングに収納され、このハウジングの寸法は約１２０ｍｍ×５０ｍｍ×２５ｍｍ以下であり、したがって、規格ＩＳＯ  １５０３１−３  ２００４  Ｇに従って規格化された体積内を維持している（この規格によって許容される公差を含む）。したがって、初めて、規格化された設計空間に対する前記リミットに合致し、ＵＳＢ、ＥｔｈｅｒｎｅｔおよびＷＬＡＮなどの、それらに基づく暗号化を含む多くの異なる外部インタフェースを支援し、また、電力消費が十分に少なく、したがって、ＵＳＢターミナルを介して装置に供給されてもよい、車両のための診断インタフェースを提供することができる。
【００２５】
一例では、ハウジングは、機械的なスイッチを全く含んでおらず、１つまたは複数の射出成形された部品で作られており、ＯＢＤプラグなどの診断インタフェースのプラグは、射出成形された複数の部品のうちの１つに統合されている。したがって、密閉されたハウジングを有し、また、能動冷却を必要としない、ガレージ環境での使用に絶対的に適した診断インタフェースを提供することができる。
【００２６】
装置を制御するために容量性スイッチが使用されてもよい。
【００２７】
一例では、装置は、Ｅｔｈｅｒｎｅｔインタフェースまたは任意の他の配線式インタフェースを実現するための接触要素および少なくとも１つの磁気デバイスを含んだ接続システムを含むことができ、磁気デバイスは、アダプタの接触要素をＥｔｈｅｒｎｅｔインタフェースの接触要素に接触させ、かつ、それらの接触を維持するように構成されている。このタイプの結合システムは、例えばＤＥ  １０  ２０１０  ０２８  ７９１  Ａ１に記載されている。特定の一例では、スイッチまたは押しボタンがアダプタに提供されてもよく、装置をリセットするためにＥｔｈｅｒｎｅｔインタフェースのリセット入力に接続される。そのため、過失によって容易に起動されることができないよう、あるいは許可なく容易に起動されることができないよう、診断装置上には提供されていないボタンを介して診断装置を単純にリセットすることができる。
【００２８】
この装置の例が車両のための診断インタフェースの文脈で説明され、ホスト・システムは、ＷＬＡＮモジュールおよび車両通信モジュールを介して車両のオンボード・ネットワーク内の制御デバイスと通信する。本発明はこれらの例に限定されず、また、産業設備、等々などの異なるシステム内の他のタイプの装置と通信するために使用されることも可能である。
【００２９】
以下、図面を参照して本発明の例が説明される。
【図面の簡単な説明】
【００３０】
【図１】従来技術による診断インタフェースの略線図である。
【図２】装置の一例の略線図である。
【図３ａ】上から見た装置の例の斜視図である。
【図３ｂ】下から見た装置の例の斜視図である。
【図４ａ】上から見た装置の他の例の斜視図である。
【図４ｂ】下から見た装置の他の例の斜視図である。
【図５ａ】装置のためのアダプタの一例の側面図である。
【図５ｂ】装置のためのアダプタの一例の平面図である。
【発明を実施するための形態】
【００３１】
図１は、従来技術による診断インタフェースすなわち車両通信インタフェースＶＣＩにおける複数のタスクの分散をブロック図の形で概略的に示したものである。診断インタフェース１０の中心は、必要なプロトコル翻訳を始めとする、ランキングがより高いホスト・システム１４と車両１６の制御デバイスとの間の通信を制御する実時間通信プロセッサ１２であり、実時間通信プロセッサ１２は、制御デバイスからのデータを処理する。通信プロセッサ１２は、例えばホスト・システムに対するＥｔｈｅｒｎｅｔインタフェースおよびＵＳＢインタフェースを支援し、また、車両に対するＯＢＤインタフェースを支援する。通常、通信プロセッサは、ホスト・システムへの状態報告、および診断インタフェース自身の状態変化または診断インタフェースに接続されている制御デバイスの状態変化の実時間検出、ならびにこのような状態変化の通信の実施を可能にするファームウェアを含む。通常、通信プロセッサ１２は、さらに、多くの並列チャネルを取り扱うように構成される。通信プロセッサ１２は、例えばＭｉｃｒｏｓｏｆｔ  ＷｉｎｄｏｗｓまたはＬｉｎｕｘなどのオペレーティング・システムのために構成されてもよい。
【００３２】
ホスト・システム１４に無線通信を提供することができるようにするために、従来技術による診断インタフェース１０は無線モジュール１８を使用しており、この無線モジュール１８は、設計に応じて外部で接続されても、あるいは診断インタフェースの共通のハウジングの中に統合されてもよい。この無線モジュール１８は、通信プロセッサ１２からホスト・システム１４へデータを伝送する個別のＷＬＡＮモジュール１８であってもよい。ＷＬＡＮモジュール１８は、例えばＥｔｈｅｒｎｅｔインタフェース、ＵＳＢインタフェースまたはＰＣＩｅインタフェースを介して通信プロセッサ１２に接続されてもよい。さらに、通信プロセッサ１２は、要求に応じて車両１６にＥｔｈｅｒｎｅｔインタフェースを提供することも可能である。
【００３３】
従来技術による解決法は、２つの強力なプロセッサを必要とし、したがって、広い設計空間および多くの電力消費を必要とする基本構造を有している。診断インタフェースの電力消費は約５ワット程度である。従来技術による解決法をより小さいハウジング内に統合するべく試行する場合、相当な熱発生の問題がもたらされる。規格ＩＳＯ  １５０３１−３  ２００４  Ｇに従って規格化された設計空間（約１２０ｍｍ×５０ｍｍ×２５ｍｍ）に従うハウジング内に本発明の装置の機能を統合することは、これまでは不可能であった。また、従来技術による解決法の電流要求事項は明らかに５００ｍＡより大きく、したがって、ＵＳＢターミナルを介した電力供給は不可能である。
【００３４】
従来技術による解決法の他の欠点は、ホスト・システム１４と通信プロセッサ１２を接続し、通信プロセッサ１２と車両インタフェース１６を接続し、また、通信プロセッサ１２と無線モジュール１８を接続するために、個別に調整されなければならない外部追加スイッチ１３が必要であることである。これらのスイッチ１３は、個々のネットワーク・セグメントを結合するためのものであり、それらは、上で言及した構成要素間でデータ・パケットを中継するためのネットワーク・スイッチ・ポイントまたはディストリビュータ・ポイントとして使用される。外部スイッチによって空間が広くなり、電力要求事項が増加し、また、恐らくはコストが高くなる。
【００３５】
図２は、本発明の装置の一例をブロック図で概略的に示したもので、この装置は、以下では、簡潔にするために診断インタフェース２０と呼ばれることもある。診断インタフェース２０は、基本的には従来技術による診断インタフェース１０の機能と少なくとも同じ機能を提供するが、診断インタフェース２０は、異なるタイプのプロセッサおよび複数のタスクの異なる分散を使用しており、したがって、全体として、総空間要求事項および電力消費が実質的に低減され、また、それと同時にプロセッサの性能が改善される。これらの目的は、診断インタフェース２０の複数のタスクのうちの最も大きい部分を、実時間で動作する必要はないが、計算能力が高いＷＬＡＮプロセッサ２２に割り当てることによって達成される。ＷＬＡＮプロセッサ２２は、ホスト・システム２４と通信するためのＷＬＡＮインタフェースを提供し、かつ、このＷＬＡＮインタフェースを介してホスト・システム２４と診断インタフェース２０との間のデータ通信を制御し、また、ホスト・システム２４との通信のために、車両２６の制御デバイスからくるデータを準備するタスクを引き受ける。ＷＬＡＮプロセッサ２２は、ＥｔｈｅｒｎｅｔおよびＵＳＢなどの共通のインタフェースを支援する、計算能力が高い通例のＷＬＡＮチップであってもよい。従来技術による通常の通信プロセッサ１２と比較すると、ＷＬＡＮプロセッサ２２の体積および電力消費は約半分に低減される（大きさが半分になり、かつ、電力消費が半分になる）が、プロセッサの性能は実質的に改善される。これは、一方では、ＷＬＡＮプロセッサ２２を実時間で動作させる必要がないことによって達成され、また、他方では、ＷＬＡＮ技術の利用の速やかな実用化を利用することによって達成される。
【００３６】
共通のＷＬＡＮプロセッサ２２は、実時間で動作することができず、また、車両特化通信プロトコルを支援しないため、診断インタフェース２０は、さらに、従来技術による通信プロセッサ１２およびＷＬＡＮプロセッサ２２と比較すると、計算能力はより低いが実時間で動作することができる小さい車両通信プロセッサ３０を使用している。この車両通信プロセッサ３０は、ＷＬＡＮプロセッサ２２と車両２６の制御デバイスとの間の通信を制御するタスク、および必要なプロトコル翻訳を実施するタスクのみを有している。したがって、車両通信プロセッサ３０に必要なことは、本質的にはプロトコル翻訳を実施することのみである。車両通信プロセッサ３０は、例えばＥｔｈｅｒｎｅｔインタフェースを介してＷＬＡＮプロセッサ２２と通信することができる。
【００３７】
本発明の診断インタフェースは、知られているＶＣＩと比較すると、著しく狭い設計空間および著しく少ない電力消費を使用して実現されることができる。設計空間の広さを約１２０ｍｍ×５０ｍｍ×２５ｍｍの寸法に制限することができ、したがって、インタフェースは、規格化された設計空間の仕様に合致する、元々はアクセス・ケーブルのためにのみ画定されていたハウジング内に収納されることができる。したがって、装置は、その寸法において、個々のＩＳＯ規格の要求事項に合致する。電流消費は、最大で５００ｍＡ、通常はそれ未満であり、また、電力消費は約２．５ワットである。一例では、車両通信プロセッサ３０を介して、ＣＡＮ、Ｋ−ＬｉｎｅおよびＬ−Ｌｉｎｅなどのすべての共通車両特化プロトコルを支援することができる。ＷＬＡＮプロセッサは、ＥｔｈｅｒｎｅｔインタフェースおよびＵＳＢインタフェースを提供する以外に、規格８０２．１１ａ／ｂ／ｇ／ｎによるすべての共通ＷｉＦｉ規格を支援するように許容する。ＵＳＢターミナルは、例えばＰＣから装置を構成するために使用されてもよい。
【００３８】
ＷＬＡＮプロセッサ２２を使用することには、このようなプロセッサが統合スイッチ３２を備え、したがって、システムの複雑性が軽減され、また、空間要求事項がさらに低減される追加利点がある。
【００３９】
この例のＷＬＡＮプロセッサ２２は、図１に示されている実施形態の場合と全く同様に、信号マルチプレクサ２８を介して車両インタフェースに接続されている。ホストＰＣは、信号マルチプレクサを介して（例えばＥｔｈｅｒｎｅｔ  ＤｏＩＰを介して）車両と直接通信することができる。
【００４０】
２つのプロセッサ２２、３０の各々は、そのためにプロセッサが最適化されているタスクのために使用される。ＷＬＡＮプロセッサ２２は、ＷＬＡＮ接続、ファイル・システムの管理、ＵＳＢインタフェースの提供、ならびにＵＤＳおよびＫＷＰ２０００などの診断車両プロトコルの取扱いなどの、高い計算能力を必要とするタスクを担っており、車両通信プロセッサ３０は、車両の制御デバイスへの通信の実時間制御およびプロトコル翻訳を移送する役割を担っている。ＷＬＡＮプロセッサ２２は、一例では、通常はＤＳＬルータに使用されるプロセッサであってもよく、一方、車両通信プロセッサは、一例では、通常は車両内での車両診断に使用されるプロセッサであってもよい。ＷＬＡＮプロセッサは、一例では、高いデータ処理能力および高い計算能力のために最適化される、Ｌｉｎｕｘなどの汎用オペレーティング・システムを有することができるが、車両通信プロセッサは、ＱＮＸなどの実時間オペレーティング・システムを有することになり、また、著しく低い計算能力、著しく少ないメモリおよびフラッシュ・メモリを使用して動作することができる。例えばＷＬＡＮプロセッサのクロックは５００ＭＨｚ以上の程度であるが、車両通信プロセッサは、１２〜８０ＭＨｚ程度のクロックに基づいて動作することができる。これは最小電力消費を保証する。一例では、ＷＬＡＮプロセッサは、車両プロセッサの約１０倍の電力、１０倍のメモリおよび１０倍のクロック周波数を有することができる。より一般的には、プロセッサは、それらの個々のタスクのための最適ＣＰＵを使用して構成されなければならない。例えばＷＬＡＮには暗号化のための高い計算能力が必要であり、車両診断には低い計算能力が必要である。したがって、ＷＬＡＮモジュールのためには要求事項に合致するＣＰＵを選択することになり、また、車両通信プロセッサのためには、要求事項に合致するが、過剰性能である必要はないＣＰＵが選択される。過剰性能が提供される場合、空間および電力消費に関連する問題、ならびに熱散逸に関連する問題が生じることになる。
【００４１】
図３ａおよび３ｂは、一例による、上からおよび下から見たハウジングの斜視図を示したものである。このハウジングの代替例が図４ａおよび４ｂに示されている。いずれのハウジングも、１２０ｍｍ×５０ｍｍ×２５ｍｍ以下の寸法を有している。
【００４２】
図３ａおよび３ｂに示されているハウジングは、例えば２つの射出成形部品から組み立てられることができる本体４０を提供している。車両のＯＢＤインタフェースに接続するためのＯＢＤプラグ４２は、本体４０の軸と同じ軸に沿って提供されている。ＯＢＤプラグ４２は、ハウジング４０の２つの片側半分のうちの一方に統合されている。ハウジング４０の上側の表面には、診断インタフェースを制御し、プログラムし、あるいはリセットするための容量性スイッチ（図示せず）の上に提供されることができる２つのボタン４４が存在している。さらに、装置のＥｔｈｅｒｎｅｔインタフェースまたは他の配線式インタフェースへのアクセスを提供するために、接触ピン４６がハウジングから外側まで延在している。これらの接触ピン４６は、例えば図５ａおよび５ｂに示されているアダプタ５０などのアダプタ５０と接触させることができる。
【００４３】
図４ａおよび４ｂに示されているハウジングは、射出成形プロセスの間に同じくハウジングの２つの片側半分のうちの一方に統合されることができる、角度が付いたＯＢＤプラグ４８が存在している点で、図３ａおよび３ｂに示されているハウジングとは異なっている。この相違以外については、図３ａおよび３ｂの説明が参照される。
【００４４】
図５ａおよび５ｂは、接触ピン４６と接触し、磁石によって所定の位置に保持される、いわゆるＭａｇＣｏｄｅ（商標）アダプタであってもよいアダプタ５０を示したものである。図３ａおよび４ａに示されているボタン４４の代わりに、あるいはこれらのボタンに加えて、１つまたは複数のリセット入力およびプログラミング入力を介して装置を制御し、プログラムし、あるいはリセットするために、他のボタンまたはスイッチがアダプタ５０に提供されることも可能である。これらのリセット入力およびプログラミング入力は、複数の接触ピン４６のうちの１つまたは複数を介して診断インタフェースと結合されてもよい。この例では、所望の制御をアダプタ５０にエクスポートすることにより、スイッチまたはボタン、詳細には独自のリセット・スイッチ／ボタンを全く必要とすることなく診断インタフェースを提供することができる。
【００４５】
当然の問題として、ＭａｇＣｏｄｅアダプタの代わりに、アダプタ５０と接触ピン４６の間の任意の他の接続機構を提供することも可能である。
【符号の説明】
【００４６】
１０、２０  診断インタフェース
１２  通信プロセッサ
１３  外部追加スイッチ
１４、２４  ホスト・システム
１６、２６  車両（車両インタフェース）
１８  無線モジュール（ＷＬＡＮモジュール）
２２  ＷＬＡＮプロセッサ
２８  信号マルチプレクサ
３０  車両通信プロセッサ
３２  統合スイッチ
４０  本体（ハウジング）
４２、４８  ＯＢＤプラグ
４４  ボタン
４６  接触ピン
５０  アダプタ
【図１】
2014042232.tif 000003
【図２】
2014042232.tif 000004
【図３ａ】
2014042232.tif 000005
【図３ｂ】
2014042232.tif 000006
【図４ａ】
2014042232.tif 000007
【図４ｂ】
2014042232.tif 000008
【図５ａ】
2014042232.tif 000009
【図５ｂ】
2014042232.tif 000010
【外国語明細書】
2014042232000001.pdf