JP2020501479A - Ｃａｎベースの充電システムにおけるインテリジェント充電通信切り替え装置 - Google Patents

Abstract

本発明は、使用される充電システムに依存して、第１の通信スタック（２０ａ）又は第２の通信スタック（２０ｂ）が選択される、電動車両の充電管理のための方法に関し、ここでは、同一の物理的インタフェースを介して、第１の通信スタック（２０ａ）は、第１の充電システムに基づくＣＡＮ通信を提供し、第２の通信スタック（２０ｂ）は、第２の充電システムに基づくＣＡＮ通信を提供する。

Description

本発明は、電気自動車用の充電システム及びインタフェースの分野に関する。

世界中においては、相互に互換性のない様々な充電システム及びインタフェースが使用されている。電気自動車を交流で充電するのか又は直流で充電するのかという異なる手段の他に、世界中には、交流用及び交流／直流用のバリエーションにおいて、米国、欧州、日本、及び中国向けの異なるプラグ規格があるほか、ＯＥＭ固有のさらなるプラグ解決手段も存在する。例えば電圧状況、供給電圧不足、プロトコル特性、複雑性又は費用などの異なる技術的条件に起因して、システムの適合化は、容易に実現することができるものではない。また、ソケットシステムのサイズ又は利用可能な構造空間の制約及びコスト状況に基づき、車両において異なる充電システムインタフェースの並列設置は見合わせている。ここでは、解決手段の一部が、顧客にとって実用的ではない外部アダプタ構造に存在する。

特に日本市場で代表されるＣＨＡｄｅＭＯ充電システムは、直流（ＤＣ）電圧をベースとしており、６２．５ｋＷまでの充電電力をサポートしている。ＣＨＡｄｅＭＯ充電通信は、ＣＡＮプロトコルと２本のＣＡＮバス線路を介して行われる。ＣＨＡｄｅＭＯプロトコルにおいては、自動車の充電システムは、マスタースレーブシステムを用いて急速充電ステーションの充電システムと通信する。自動車の充電システム（マスタ）は、駆動用バッテリの現在の充電レベル、並びに、駆動用バッテリの充電に対して許容される直流電圧及び最大電流強度などの充電パラメータを充電ステーション（スレーブ）に通知する。さらに、駆動用バッテリの電圧、温度及び他のパラメータなどのパラメータが伝送される。ＣＨＡｄｅＭＯプロトコルは、ＩＳＯ規格の枠内で直流充電標準として認知されており、規格ＩＳＯ／ＩＥＣ６１８５１−２３及びＩＳＯ／ＩＥＣ６１８５１−２４として採用された。ここでは、ＣＨＡｄｅＭＯ標準に準拠したＣＡＮベースのレイヤ１通信プロトコルが使用される。

中国のＧＢ／Ｔ標準２０２３４も同様に、従来の交流網における充電のためにも、直流による急速充電のためにも適した充電プラグシステムを想定しており、ここでは、充電通信がＣＡＮプロトコルを介して行われている。ＧＢ／Ｔ標準においては、対応する急速充電ステーションでの急速直流充電が可能である。ここでは、ＧＢ／Ｔ標準に準拠したＣＡＮベースのレイヤ１通信プロトコルが使用される。

既存のＣＨＡｄｅＭＯ規格と、新しい中国のＧＢ／Ｔとの間では、物理的なＣＡＮ層（レイヤ１）は、確かに同等ではあるが、標準固有の通信プロトコルやボーレートなどの通信パラメータは一致しない。ＣＨＡｄｅＭＯ（日本）及びＧＢ／Ｔ（中国）の両標準においては、充電スタンドと車両との間のＣＡＮ通信が必要であるが、異なるボーレートと異なる通信フローも必要である。従って、ここでは、それぞれの市場に存在する充電規格に従った車両での使用を可能にする解決手段を実現するための課題が、技術的実現の範囲内で存在する。充電スタンドとの通信においては、自動車業界は、車両外でひいては車両メーカーの手中にない、ＣＡＮ通信への要件が異なる外部通信パートナーと遭遇する。

ＣＨＡｄｅＭＯ及びＧＢ／Ｔ規格に従った２つの充電システムをサポートする場合、特に、異なる要件を通信に適合化させることが有効である。両規格とも、論理メッセージ処理、通信フロー、及び、特にＣＡＮ構成が異なる。自動車業界内部での主に車内通信用に設計されているＣＡＮ通信は、静的に定められており、メーカーによって定められた規則に正確に従う。従って、既存のソフトウェアモジュール及び自動車用制御機器の実装においては、車両内部ＣＡＮ通信のこの特定の種類のみが、定められたボーレートでサポートされている。

このような背景を前提として、特に各充電規格（ＣＨＡｄｅＭＯ又はＧＢ／Ｔ）用に特別に開発された異なる制御機器又はソフトウェア変種を設けることは公知である。このことは、いずれにせよ、そのような代替的制御機器又はソフトウェア変種は、製造において別個に考慮しなければならないという欠点を有する。また、中国（ＧＢ／Ｔ）と日本（ＣＨＡｄｅＭＯ）の異なる市場のための車両において、個別ケーブル配線を有する２つの別個のＣＡＮ通信インタフェースを使用することも公知である。車両内のそのような個別ケーブル配線は、いずれにせよ不経済である。なぜなら、それらは例えば空間においてより多くのコストを必要とし、煩雑であり、制御コストの増大をもたらすからである。

本発明の課題は、上述した欠点を少なくとも部分的に克服する充電システムを提供することである。この課題は、請求項１に記載の本発明に係る方法、対応するオペレーティングソフトウェア、及び、対応する制御機器によって解決される。本発明のさらなる好ましい実施形態は、従属請求項及び以下の本発明の好ましい実施例の説明から明らかになるであろう。

本発明は、電子制御機器内で使用される充電システムに依存して、第１の通信スタック又は第２の通信スタックが選択される、電動車両の充電通信のための方法に関し、ここでは、異なる構成を有する同一の物理的インタフェースを介して、第１の通信スタックは、第１の充電システムに基づくＣＡＮ通信を提供し、第２の通信スタックは、第２の充電システムに基づくＣＡＮ通信を提供する。

この方法は、例えば、アプリケーションが、同一の物理的ＣＡＮインタフェースを介して、第１の通信スタックを用いて通信する又は第２の通信スタックを用いて通信することができるという利点となる。従って、単一かつ同一のソフトウェアで、単一かつ同一の物理的ＣＡＮ通信区間を介して、２つ以上の国又は市場固有の充電規格をカバーすることができる。アプリケーションは、例えば、ＡＵＴＯＳＡＲアーキテクチャにおけるプログラム若しくはプログラムモジュール又はアプリケーション層のソフトウェアコンポーネントであり得る。

通信スタックは、例えば、１つ以上のソフトウェアモジュールを含むことができ、それらはインタフェースを介してアプリケーション層から分離され、それによって、アプリケーション層から論理的及び機能的に分離されているものとしてみなすことができる。アプリケーション層から論理的及び機能的に分離されている通信スタック又はモジュールを設けることは、モジュールの交換性を簡単にできるという利点となる。例えば、アプリケーション層のアプリケーションは、例えばプログラミングインタフェース（ＡＰＩ）を介して通信スタックの機能性にアクセスすることができる。通信スタックのモジュールとは、例えば、ドライバ、インタフェースなどであり得る。

本発明の好ましい実施形態によれば、第１の通信スタックは、ＣＨＡｄｅＭＯプロトコルに基づくＣＡＮ通信を提供し、第２の通信スタックは、ＧＢ／Ｔプロトコルに基づくＣＡＮ通信を提供する。このことは、単一かつ同一のソフトウェアで単一かつ同一の物理的ＣＡＮ通信区間を介してＣＨＡｄｅＭＯプロトコルによるＣＡＮ通信又はＧＢ／ＴプロトコルによるＣＡＮ通信をカバーすることができるという利点となる。

ＣＨＡｄｅＭＯ標準に従った通信に対する特徴は、定められた全てのＣＡＮメッセージが同時に周期的にバス上に置かれ、メッセージのパラメータがフロー中に更新されることである。このことは、５００ｋＢｉｔ／ｓに定められたボーレートを有する車両内部通信の本来の通信フローに関して類似しており、このことは、好ましい実施例によれば、車両内部通信に類似のＣＡＮ構成が標準ソフトウェアモジュールを介して使用されることにつながる。

例えば、充電システム固有の通信を実施するために、ＣＡＮ層のドライバは、国別仕様に応じて構成される。このことは、ＣＡＮ層の単に構成によって充電システム固有の通信に適合化される既存のドライバを使用することができるという利点となる。

ＧＢ／Ｔ（中国）によれば、定められたメッセージは、バス上に周期的にも置かれるが、問合せ応答フローの場合のように、対向箇所からの応答が再び周期的にバス上に置かれる限りはそれぞれ１つのメッセージのみである。セグメント化されたメッセージに対しては、ＧＢ／Ｔ（中国）は、付加的に商用車業界からのＳＡＥＪ１９３９プロトコルに設定する。この通信は、５０ｋＢｉｔ／ｓ、１２５ｋＢｉｔ／ｓ又は２５０ｋＢｉｔ／ｓのボーレートで異なって行われる。

本発明のさらなる好ましい実施形態によれば、本発明に係る方法は、各国別仕様の識別に基づき、各通信スタックを、各充電システム用の対応するＣＡＮドライバ構成を考慮に入れて選択し構成することを含む。このことは、充電管理制御機器の対応するオペレーティングソフトウェアを各国別仕様に合わせて設定することができ、ひいては異なる通信フロー及び異なるＣＡＮ通信のボーレートを有する様々な充電システムと協働することができるという利点となる。

識別又は構成は、製造中のパラメータ化又はコーディングを介して静的に定めることが可能であり、又は、取り付けられた充電ソケット若しくは印加された電気信号（例えばＣＨＡｄｅＭＯ標準におけるスタートストップ（ＣＳＳ１）又はＧＢ／Ｔ標準におけるＣＣ１）に基づく充電システム識別に基づき動的に定めることができる。静的解決手段は、起動時間が迅速になり得るという利点となる。この目的のために、メモリからのソフトウェアフラグが制御機器の初期化中に評価される。動的充電システムの識別は、より複雑な解決手段によって行うこともでき、例えば、制御機器の充電システム固有の信号入力側に印加される電圧値に基づく、又は、制御機器の定められた線路に取り付けられた充電ソケットの抵抗コーディングに基づく、取り付けられた充電ソケットの識別を用いて行うことができる。

識別のさらなる手段は、２つの標準のうちの一方に従った充電スタンドとの通信が可能であるかどうかを検出するための交互のボーレート切り替えにある。交互のボーレート切り替えの場合には、それぞれ必要なボーレートを考慮して、まず一方の充電通信プロトコルに従ったメッセージが送信され、さらに無応答の場合又は当面のバスエラー識別に続いて第２のプロトコルのメッセージが送信される。この方法は、例えばワイヤハーネスの適合化又は各充電スタンドへの接続が、例えばアダプタボックスを用いて行われる場合には特に有利であり、それにより、ＣＨＡｄｅＭＯ固有のプラグも、ＧＢ／Ｔ固有のプラグも、対応する信号と共に車両に接続することができるようになる。この車両には、場合によってはハードウェア変更のさらなる手段が必要である。

本発明のさらなる好ましい実施形態によれば、中国の国別仕様が識別された場合には、ＧＢ／Ｔ充電システム用のＣＡＮドライバ構成を有する通信スタックが選択され及び／又は構成され、日本の国別仕様が識別された場合には、ＣＨＡｄｅＭＯ充電システム用のＣＡＮドライバ構成を有する通信スタックが選択され及び／又は構成される。このことは、例えばＧＢ／Ｔ（中国）によるＤＣ充電も、ＣＨＡｄｅＭＯ（日本）によるＤＣ充電も、単一かつ同一の制御機器又は単一かつ同一の制御機器ソフトウェアによってサポートすることができるという利点がある。

本発明のさらなる好ましい実施形態によれば、国別仕様に応じて、インテリジェントボーレート切り替えが、使用すべき充電システムに依存して行われる。それにより、例えばオペレーティングソフトウェアは、ＣＡＮ通信のボーレートを各充電システムに適合化させることができる。ＣＨＡｄｅＭＯ標準側においては、ここでは、５００ｋＢｉｔ／ｓが特定されており、ＧＢ／Ｔ標準の側においては、５０Ｋｂｉｔ／ｓ、１２５Ｋｂｉｔ／ｓ又は２５０Ｋｂｉｔ／ｓが特定されている。

本明細書に記載の方法は、例えば、充電管理制御機器用のオペレーティングソフトウェアとして実現することができる。好ましい実施形態によれば、この方法又はオペレーティングソフトウェアは、ＡＵＴＯＳＡＲ環境上で実現される。このことは、ＡＵＴＯＳＡＲが、通信スタック及び対応するモジュールの標準化を保証し、それによって、本発明に係るオペレーティングソフトウェアは、異なるメーカーの車両及び様々な供給業者の電子コンポーネントにおいて、ソフトウェアモジュールとして容易に使用することができるという利点となる。特に、ＣＨＡｄｅＭＯ仕様の充電通信は、ＣＡＮ通信用の標準ＡＵＴＯＳＡＲモジュールを使用して実現することができる。

本発明は、この方法又はオペレーティングソフトウェアを、車両の他の既存の制御機器、例えば充電機器又はバッテリ管理部などにおいて使用する手段にも関する。

本発明はさらに、本発明に係るそのような充電管理制御機器を有する電気自動車にも関する。この電気自動車は、任意の種類の電気自動車、例えば、駆動装置用の駆動バッテリを有している電気自動車であり得る。本発明に係る充電管理部又は本発明に係る充電管理用ソフトウェアは、例えばハイブリッド電気自動車においても使用することができる。

以下においては、本発明の実施例を、添付の図面を参照して例示的に説明する。

ＣＨＡｄｅＭＯ充電技術に従ったＣＨＡｄｅＭＯ充電スタンドにおける電気自動車を概略的に示した図。 ＣＨＡｄｅＭＯ充電プラグシステムによる充電プラグのピンレイアウトの一実施例を概略的に示した図。 ＧＢ／Ｔ充電プラグシステムによる充電プラグのピンレイアウトの一実施例を概略的に示した図。 ＡＵＴＯＳＡＲアーキテクチャの層構造の概略図。 ＣＨＡｄｅＭＯ固有の通信スタック及びＧＢ／Ｔ固有の通信スタックを有するソフトウェアアーキテクチャに対する一実施例を示した図。 ＣＨＡｄｅＭＯ固有の通信スタック及びＧＢ／Ｔ固有の通信スタックを有するソフトウェアアーキテクチャに対する代替的実施例を示した図。 ＣＨＡｄｅＭＯ固有の通信スタック及びＧＢ／Ｔ固有の通信スタックを有するソフトウェアアーキテクチャに対するさらなる代替的実施例を示した図。 充電管理部用のオペレーティングソフトウェアとして機能し得る本発明に係る例示的なソフトウェアアプリケーションに関する概略的フローチャート。

以下の実施例は、充電管理部の機能性を提供するアプリケーション、並びに、第１及び第２の通信スタックを含むソフトウェアアーキテクチャに基づく、充電管理部用の本発明に係るオペレーティングソフトウェアを説明している。ここでは、第１の通信スタックは、第１の充電プロトコルに基づくＣＡＮ通信を提供し、第２の通信スタックは、第２の充電プロトコルに基づくＣＡＮ通信を提供する。

図１は、ＣＨＡｄｅＭＯ充電技術に従ったＣＨＡｄｅＭＯ充電スタンド２における電気自動車１を示している。電気自動車１を、ＣＨＡｄｅＭＯ充電スタンド２に接続するために、ＣＨＡｄｅＭＯ充電スタンド２は、電気自動車１のＣＨＡｄｅＭＯソケット４に挿入されるＣＨＡｄｅＭＯプラグ３を有する。この電気自動車１は、さらに当該電気自動車１のエネルギー管理部６と接続を形成する充電管理制御機器５を備える。この充電管理制御機器５は、このケースにおいては、ＣＨＡｄｅＭＯプロトコルに従って動作するように設計されている。充電スタンド２と電気自動車１との間の通信は、状態シグナリングと２線式ＣＡＮ通信との組み合わせによって行われる。

図２は、ＣＨＡｄｅＭＯ充電プラグシステムによる充電プラグのピンレイアウトの一実施例を概略的に示している。ピンＰＥは、基準電位と保護に用いられるアース線路である。ピンＣＳＳ１（Charger Start/Stop 1）及びＣＳＳ２（Charger Start/Stop 1）は、ＥＶリレーの制御に用いられる。ピンＮは、割り当てられていない。ピンＣＥＤ（“Charging Enable/Disable”）は、充電制御の準備ができていること（“Ready to Charge”）を表示するために用いられる。ピンＤＣ−は、エネルギー伝送の−の線路として用いられる。ピンＤＣ＋は、エネルギー伝送の＋の線路として用いられる。ピンＣＯＣ（“Connection Check”）は、近接検出器の信号用に用いられる。ピンＣＡＮ−Ｈは、データ通信用の＋の線路として用いられる。ピンＣＡＮ−Ｌは、データ通信用の−の線路として用いられる。

図３は、ＧＢ／Ｔ充電プラグシステムによる充電プラグのピンレイアウトの一実施例を概略的に示している。ピンＰＥは、基準電位と保護に用いられるアース線路である。ピンＣＣ１及びＣＣ２（“Charging Connection Confirmation”）は、充電過程の制御に用いられる。ピンＤＣ−は、電源の−の線路として用いられる。ピンＤＣ＋は、電源の＋の線路として用いられる。ピンＳ＋（ＣＡＮ−Ｈ）は、データ通信の＋の線路として用いられる。ピンＳ−（ＣＡＮ−Ｌ）は、データ通信の−の線路として用いられる。ピンＡ＋は、低圧充電用の補助電源の＋の線路として用いられ、ピンＡ−は、低圧充電用の補助電源の−の線路として用いられる。

以下においては、本発明を例示的にシステムアーキテクチャＡＵＴＯＳＡＲ（AUTomotive Open System ARchitecture）の枠内で説明する。しかしながら、本発明は、この特定のシステムアーキテクチャに限定されない。この構想は、他のシステムアーキテクチャにも転用可能である。システムアーキテクチャＡＵＴＯＳＡＲの手引きとして、例えばRobert Neue著の文献“AUTOSAR - Eine Einfuehrung”von Robert Neue, TU Dortmund (https://ess.cs.tu-dortmund.de/ Teaching/PGs/autolab/ausarbeitungen/Neue-AUTOSAR-Ausarbeitung.pdf)又はOliver Busch著の公知文献“Die Software-Architektur von AUTOSAR”von, Universitaet Koblenz-Landau (https://www.unikoblenz-landau.de/de/koblenz/fb4/ist/AGZoebel/Lehre/ss2012/seminar/oBusch)が挙げられる。

図４は、ＡＵＴＯＳＡＲアーキテクチャの層構造の概略図を示している。ＡＵＴＯＳＡＲは３層のソフトウェアアーキテクチャである。上位ソフトウェアレベルの機能部分を駆動するためにその存在が必要であるインフラストラクチャを記述するための標準化されたソフトウェアモジュールは基本ソフトウェア１４と称される。ランタイム環境（Run-Time Environment,ＲＴＥ）１２は、アプリケーションソフトウェアコンポーネント間、及びベースソフトウェアとアプリケーションとの間でＥＣＵ間及びＥＣＵ内（Electronic Control Units,電子制御機器）のデータ交換のためのネットワークトポロジによって抽象化されるミドルウェアを表す。ランタイム環境１２と相互作用するアプリケーションソフトウェアのコンポーネントは、アプリケーション層１３と称される。アプリケーションモジュール２１は、アプリケーション層１３のそのようなソフトウェアコンポーネントの一例を表す。それらの物理的及び時間的表現に関してインタフェースを標準化することにより、統合の際の互換性が達成される。ハードウェアアクセスは基本層を介して行われる。従って、ＡＵＴＯＳＡＲは、機器のハードウェアからソフトウェアを分離させる制御機器用のソフトウェアアーキテクチャを定めている。サービス層１１は、例えば診断プロトコル、ＮＶＲＡＭ、フラッシュ及びメモリ管理などのシステムサービスを提供する。マイクロコントローラアブストラクション層（ＭＣＡＬ）８は、例えばＣＡＮ通信用のマイクロコントローラ（ＣＡＮ−ＭＣＵ）１６などの外部周辺ＩＣに直接アクセスする。このマイクロコントローラアブストラクション層８は、例えばＣＡＮドライバ１５などの通信ドライバを含む。マイクロコントローラ層７上のＣＡＮ−ＭＣＵ１６と協働するＣａｎドライバ１５は、ＣＡＮ入出力を生じさせる。ＥＣＵアブストラクション層１０は、マイクロコントローラアブストラクション層８のドライバに対するインタフェース、例えばＣＡＮドライバ１５に対するインタフェースを提供する。

ＡＵＴＯＳＡＲの基本ソフトウェア１４は、垂直領域、いわゆるスタックに分割されている。これらのスタックと層とは相互に重なり合い、いわゆる機能ブロックを形成する。これらの機能ブロック内部においては、ＡＵＴＯＳＡＲ標準、いわゆるモジュールが定められる。ＡＵＴＯＳＡＲ内の一連のモジュール、例えばＣＯＭモジュール（サービス層）、ＰＤＵルータ（サービス層）、ＣＡＮＳＭ（サービス層）、ＣａｎＩｆ，ＬｉｎＩｆ，ＦｒＩｆなどのバス固有のインタフェースモジュール（ＥＣＵアブストラクション層）、ＣＡＮインタフェース（ＥＣＵアブストラクション層）などの外部バスドライバ、及び、ＣＡＮドライバ（ＭＣＡＬ層）などの内部バスドライバは、通信スタックと称される。

図５は、ＣＨＡｄｅＭＯ固有の通信スタック２０ａ及びＧＢ／Ｔ固有の通信スタック２０ｂを有するソフトウェアアーキテクチャの例示的実施形態を示している。第１の通信スタック２０ａは、ＣＨＡｄｅＭＯプロトコルを介したＣＡＮ通信用に設けられている。第２の通信スタック２０ｂは、ＧＢ／Ｔプロトコルを介したＣＡＮ通信用に設けられている。ＣＡＮ／ＣＨＡｄｅＭＯ用の通信スタック２０ａは、４つの基本ソフトウェアモジュール、詳細には、ＭＣＡＬ層８の機能ブロック“Communications Drivers”内のＣＡＮ／ＣＨＡｄｅＭＯドライバ１５ａ、ＥＣＵアブストラクション層１０の機能ブロック“Communications Hardware Abstractions”内のＣＡＮ／ＣＨＡｄｅＭＯインタフェース１７ａ、並びに、サービス層１１の機能ブロック“Communications Services”内のＣＨＡｄｅＭＯ／ＰＤＵルータ１８ａ及びＣＨＡｄｅＭＯ／ＣＯＭモジュール１９ａを含む。ＣＡＮ／ＧＢ／Ｔ用の通信スタック２０ｂは、４つの基本ソフトウェアモジュール、詳細には、ＭＣＡＬ層８の機能ブロック“Communications Drivers”内のＣＡＮ／ＧＢ／Ｔドライバ１５ｂ、ＥＣＵアブストラクション層１０の機能ブロック“Communications Hardware Abstractions”内のＣＡＮ／ＧＢ／Ｔインタフェース１７ａ、及び、サービス層１１の機能ブロック“Communications Services”内のＧＢ／Ｔ／ＰＤＵルータ１８ｂ及びＳＡＥＪ１９３９をサポートしているＧＢ／Ｔ／ＣＯＭモジュール１９ｂを含む。ＣＨＡｄｅＭＯ又はＧＢ／Ｔ固有のＣＯＭモジュール１９ａ及び１９ｂは、特にＣＡＮバスシステムに対するトランスポートプロトコルの提供、メッセージの処理及びタイミングを担っている。インタフェース１７ａ又は１７ｂは、ＣＡＮバスシステムの利用可能なチャネルへのアクセスのための機能を提供する。ドライバ１５ａ又は１５ｂは、伝送又はコールバック機能を開始させかつバス特性を構成するための機能を提供する。これらのモジュールは、当業者に公知の方法でＣＡＮ／ＣＨＡｄｅＭＯ又はＣＡＮ／ＧＢ／Ｔを用いた通信のためにセットアップされる。両通信スタック２０ａ，２０ｂは、マイクロコントローラ層７の同一のＣＡＮ−ＭＣＵを使用する。即ち、それらは、同一の物理的インタフェース上でＣＡＮ通信を提供する。

図５の実施例においては、ＣＡＮドライバ１５ａ，１５ｂ、ＣＡＮインタフェース１７ａ，１７ｂ、ＰＤＵルータ１８ａ，１８ｂ、及びＣＯＭモジュール１９ａ，１９ｂにおいて異なっている、２つの充電システム固有の通信スタック２０ａ，ｂが設けられている。しかしながら、代替的実装変形例においては、通信スタックがこれらのコンポーネントのうちの１つのみにおいて異なる可能性があること、例えばＣＯＭモジュール１９ａ，１９ｂ及びその結果としてのＣＡＮドライバ構成のみにおいて、あるいは代替的に、例えばＣＡＮドライバ１５ａ，１５ｂのみにおいて異なる可能性があることは当業者には明らかである。

図６は、通信スタックが充電システム固有のＣＯＭモジュール１９ａ，１９ｂのみにおいて異なる実施例を示している。通信スタック２０ａは、ＣＨＡｄｅＭＯ規格に従って構成された標準ＣＯＭモジュールによって特徴付けられ、さらに車両内部通信の周期的なＣＡＮメッセージの本来の送受信特性に関して類似する。通信スタック２０ｂ内のＧＢ／Ｔ標準に従った通信の実現のために、この実施形態によれば、ＧＢ／Ｔ固有のＣＯＭ実装がＳＡＥＪ１９３９コンポーネントも含めてＡＵＴＯＳＡＲＣＡＮインタフェースモジュール又はＰＤＵルータの上方に設けられる。標準ＡＵＴＯＳＡＲ−ＣＯＭモジュールは、車両内部ＣＡＮ通信特性から大幅にずれたメッセージのＧＢ／Ｔ固有のＣＡＮ通信特性に基づき、通信スタック２０ｂ内においては使用されない。ＣＯＭモジュールのＧＢ／Ｔ固有の実装は、ＧＢ／Ｔ標準に従った通信スタックからのアプリケーションの最大限の独立性を得るために、インタフェースからより上位の層、即ち、アプリケーションへ、ＡＵＴＯＳＡＲ−ＣＯＭモジュールのインタフェース仕様に従って実装される。この実施形態においては、中国仕様のＧＢ／Ｔ通信スタック２０ｂは、ＧＢ／Ｔ固有のＣＯＭモジュールとして実現される。ＧＢ／Ｔ固有のＣＯＭモジュールは、ＧＢ／Ｔ標準に従った問合せ応答通信フローにおける、周期的メッセージの時間特性及び送信及び処理に関して定められたメッセージ処理の維持を担っている。ＣＡＮドライバ１５は、この実施例においては、実行時又はオペレーティングソフトウェアによる起動時点の初期段階において、充電システム固有に再構成される。それにより、ＣＡＮベースの充電通信プロトコルの並列実装が、単一かつ同一の物理的ＣＡＮインタフェースを介して単一かつ同一の制御機器ソフトウェア内部で可能となる。

図７は、通信スタックが充電システム固有のＣＡＮドライバ１５ａ，１５ｂのみにおいて異なるさらなる代替的実施例を示している。

図８は、充電管理部用のオペレーティングソフトウェアとして機能し得る本発明に係る例示的なソフトウェアアプリケーションに関する概略的フローチャートを示している。このソフトウェアアプリケーションは、例えば、ＡＵＴＯＳＡＲアプリケーションモジュールとして設けることができる（図４のアプリケーション層１３参照）。このソフトウェアアプリケーションは、各国別仕様の識別に基づき、各通信スタックを、各充電システム用の対応するドライバ構成を考慮に入れて選択し構成するように設計されたプログラム命令を有する。ステップ６０１においては、国別仕様ＬＶが問合せされる。ステップ６０２においては、国別仕様ＣＮ＝中国が存在するかどうかが検査される。イエスである場合には、ステップ６０３によって続けられる。ステップ６０３においては、ＧＢ／Ｔ充電システム用のドライバ構成を有する通信スタックが選択され構成される。ステップ６０２において、国別仕様ＣＮ＝中国が識別されない場合には、ステップ６０４に進む。ステップ６０４においては、国別仕様ＪＰ＝日本が存在するかどうかが検査される。イエスである場合には、ステップ６０５によって続けられる。ステップ６０５においては、ＣＨＡｄｅＭＯ充電システム用のドライバ構成を有する通信スタックが選択され構成される。次いで、充電通信は、選択され構成された通信スタックに従って実行することが可能になる。即ち、国別仕様が日本の場合にはＣＨＡｄｅＭＯ／ＣＡＮに従って、あるいは、国別仕様が中国の場合にはＧＢ／Ｔ／ＣＡＮに従って実行することが可能になる。

１ 電気自動車
２ ＣＨＡｄｅＭＯ充電スタンド
３ 充電スタンドのＣＨＡｄｅＭＯプラグ
４ 電気自動車のＣＨＡｄｅＭＯソケット
５ 充電管理制御機器
６ エネルギー管理部
７ マイクロコントローラ（ハードウェア）
８ マイクロコントローラアブストラクション層（ＭＣＡＬ）
９ 複合機器ドライバ（ＣＤＤ＝Complex Device Drivers）
１０ ＥＣＵアブストラクション層
１１ サービス層
１２ ランタイム環境（ＲＴＥ）
１３ アプリケーション層
１４ 基本ソフトウェア
１５ ＣＡＮドライバ
１５ａ ＣＡＮ／ＣＨＡｄｅＭＯドライバ
１５ｂ ＣＡＮ／ＧＢ／Ｔドライバ
１６ ＣＡＮ−ＭＣＵ
１７ ＣＡＮインタフェース
１７ａ ＣＡＮ／ＣＨＡｄｅＭＯインタフェース
１７ｂ ＧＢ／Ｔ／ＣＨＡｄｅＭＯインタフェース
１８ ＰＤＵルータ
１８ａ ＣＨＡｄｅＭＯ／ＰＤＵルータ
１８ｂ ＧＢ／Ｔ／ＰＤＵルータ
１９ ＣＯＭモジュール
１９ａ ＣＨＡｄｅＭＯ／ＣＯＭモジュール
１９ｂ ＧＢ／Ｔ／ＣＯＭモジュール
２０ａ ＣＡＮ／ＣＨＡｄｅＭＯ通信スタック
２０ｂ ＣＡＮ／ＧＢ／Ｔ通信スタック
２１ アプリケーションモジュール
ＤＣ＋ エネルギー伝送＋
ＤＣ− エネルギー伝送−
ＣＡＮ−Ｈ デジタル通信＋
ＣＡＮ−Ｌ デジタル通信−
ＣＳＳ１ Charger Start/Stop 1
ＣＳＳ２ Charger Start/Stop 2
ＣＥＤ Charging Enabled/Disabied
ＰＥ Protective Earth保護アース（「機能的」保護アース）
ＰＰ Proximity Pilot近接パイロット（「プラグ識別」）
ＣＥＤ Charging Enable/Disable
ＬＶ 国別仕様
ＣＮ 国別仕様 中国
ＪＰ 国別仕様 日本

Claims (10)

1. 使用される充電システムに依存して、第１の通信スタック（２０ａ）又は第２の通信スタック（２０ｂ）が選択される、電動車両の充電管理のための方法であって、
   同一の物理的インタフェースを介して、前記第１の通信スタック（２０ａ）は、第１の充電システムに基づくＣＡＮ通信を提供し、前記第２の通信スタック（２０ｂ）は、第２の充電システムに基づくＣＡＮ通信を提供する、方法。
2. 前記第１の通信スタック（２０ａ）は、ＣＨＡｄｅＭＯプロトコルに基づくＣＡＮ通信を提供し、前記第２の通信スタック（２０ｂ）は、ＧＢ／Ｔプロトコルに基づくＣＡＮ通信を提供する、請求項１に記載の方法。
3. 充電システム固有の通信を実施するために、前記第１の通信スタック（２０ａ）のＣＡＮ層のドライバ及び／又は前記第２の通信スタック（２０ｂ）のＣＡＮ層のドライバは、各国別仕様に応じて構成される、請求項１又は２に記載の方法。
4. 各国別仕様の識別に基づき、前記各通信スタック（２０ａ，２０ｂ）を、各充電システム用の対応するドライバ構成を考慮に入れて選択し及び／又は構成する、請求項１乃至３のいずれか一項に記載の方法。
5. 中国の国別仕様が識別された場合には、ＧＢ／Ｔ充電システム用のドライバ構成を有する通信スタックが選択され及び／又は構成され、日本の国別仕様が識別された場合には、ＣＨＡｄｅＭＯ充電システム用のドライバ構成を有する通信スタックが選択され及び／又は構成される、請求項４に記載の方法。
6. 国別仕様に応じて、インテリジェントボーレート切り替えが行われる、請求項１乃至５のいずれか一項に記載の方法。
7. ＣＡＮベースの充電通信プロトコルの並列実装が、単一かつ同一の物理的ＣＡＮインタフェースを介して単一かつ同一の制御機器ソフトウェア内部で実現される、請求項１乃至６のいずれか一項に記載の方法。
8. 請求項１乃至７のいずれか一項に記載の方法を実施するために設計されたオペレーティングソフトウェア。
9. ＡＵＴＯＳＡＲ環境上で実現されている、請求項８に記載のオペレーティングソフトウェア。
10. 請求項１乃至７のいずれか一項に記載の方法を実施するように構成されているプロセッサを有する制御機器。

Images