車載LANとしてのCAN・ザックリ話し
このところ、車載用ネットワークシステム(LANと云うもの)に感心を傾け、種々書籍を含めNet探索も繰り返しているところだ。しかし、筆者は元々コンピューター技術者でもないし、いわゆるシステムインテグレーター(システム設計者)でもないし、様々な用語に戸惑いつつ、その仕組みをザックリと大づかみしようと思考しているところなのだ。
そこで、これまでのところ理解できた内容を噛み砕いて、日頃クルマに関わる方々の少しでも役立てばと云う思いで本記述を書き始めたい。なお、冒頭にも記した通り専門家でない者が記す文章だからして、その理解不足だとか、あえて説明を簡略化するためにザックリと切り分ける中で、本来の意味と異なるという部分があることを承知して戴きたい。
1.車載LANが何故求められたのか
LANとはローカルネットワークのことだが、端的に結論付ければ、様々なコンピューターで通信しつつ連携できるというのが根底思想にある。これはコンピューターに限らず、情報共有により複合的なシステムとしての利を追求する思考と考えて良いだろう。
クルマの場合で云えば、そもそも車両のコンピューター化はエンジンコントロールユニット(ECU)から始まり、次いでオートマチックトランスミッションのコントロールユニットが、そしてABSコントロールと次々にコンピューター制御機器が採用されていった。
その後は、このコンピューター制御というものが、従来の機械式の独立制御に比べ、ソフトウェアで制御できるということのメリットに気付くと共に、様々な機器がデバイスが、ECU制御化されて行く時代になった。
ここで、例として各車輪毎に装着される車輪回転センサー、つまり車速信号を考えてみたい。この車速信号は、本来ABSおよびトランスミッション程度に使用するだけだったのだ。しかし、各制御ECUの増加と共に、エンジン、ABSを発展させたESC(スタビリティコントロール)、スピードメーター、最近ではEPS(電動パワステ)、エアバッグ、BCM(ボデーコントロールモジュール)、自動運転を目指し機能を向上しつつあるADAS(先進運転支援システム)など、多くのECUに共有されている。ここで、従来の単独ECU同士が独立している中で、数個のECU同士を連携させようとするだけなら、それぞれのECU同士にスピードセンサーの信号を分岐して配線すれば良い訳なのだが、これが、先に列記した様に多数のECUに配線しなければならなくなってくると、配線は多数複雑化してくる。これは、スピードセンサーだけのことだが、別の信号線だとか、あるECUで処理した結果としての新たな信号を多数のECUと連携処理したいとなると、これら信号線の配線が非常に多くなってしまうことになる。
と云う様な多数のECUを搭載することにより、各ECUの情報共有だとか連携を行う必要上、多数の配線を使うムダを排除しつつ、バスラインで情報通信を行うという思想がLANというもので、その概念を図示したものが別添図(Fig C-1)だ。
つまり、共通バスラインという配線を通して、複数の通信を多重通信できるできるのが、LANもしくはバス通信と云われる概念となる。
ちなみに、単にバス通信というと、係る信号を平行に引き回したパラレルバスと、単線(もしくは複数などの少数配線)で多重通信するシリアル通信の2種があるが、車載LANにしてもインターネットなどの通信回線も何れもシリアルバス通信ということになる。
2.車載用LANの規格CANとは
先に述べた様に車載用LANシステムのバス通信は、シリアルバス通信だ。この概念を一般的に表してみたのが、添付図(Fig C-2)だ。
ここで、車載用各ECUを連携させるために接続しているバスラインは、現在業界スタンダードとなっているのがCAN(Controller Area Network)という、独ボッシュ社が開発し知的財産権を保有している通信プロトコル(通信の約束事)だ。
なお、先の図の中で、LIN(Local Interconnect Network)と記してあるのは、CANバスの下位の規格となる。CANほど通信速度を必用とせず、しかも接続相手に必ずしもCPUを使用する必要ない(ただし送受信する能力のある専用ASIC(特定用途向け専用LSIのこと)は必用となる)通信規格のことだ。
3.CANのデータフォーマット(波形)
ここでは添付図(Fig C-3)がCANの通信データの1フレーム分ということになる。ここで、フレームというワードだが、通信のまとまりとしての1単位となり、多数のECU同士で通信を開始すると、このフレームが連続することになる訳だが、場合によっては同時に複数のECUが送信を始めるとデータの衝突(コンフリクトと称する)や、他のECUの送信中に別のECUが送信し出すと、データがメチャクチャになりまともな通信が成立しない。そんな理由で、フレーム最初にアービトレーションとコントロールというフィールドを持つが、これは調停や制御の意味で、データの衝突が関知されると、そのID固有の優先順位に応じて、該当ECUに優先的に再送信の合図を出す。つまり、これらアービトレーションおよびコントロールは、個別の信号の送受信のIDを示すと共に優先順を判断して通信を制御するためにある。
なお、厳密な意味では異なる解釈となる様だが、この1フレームで送受信されるデータのくくりをパケットという呼び方をする場合がある。つまり、どんなに大きなデータでも、1フレームもしくは1パケットに分割して、送受信することができる訳だが、1つのパケットを受信して、続けて連続するパケットを受信できる保証はない。そこには、そのバス回線に接続された他の通信のパケットが入り込んで来るからだ。
シリアルバス多重通信においては、データ回線の混雑度に応じてこの様な不具合が生じる可能性もあるので、システム設計者は、データ遅延の問題の検討は欠かせないと思える。なお、参照図(Fig C-2)内に示したセントラルゲートウェイは、本来的な意味は異なるプロトコルを変換したりと云うのが主目的だが、場合によりID固有の優先順位に対応してデータを遮断したりする機能(PCでもゲートウェイの機能はソフトウェアとして持つし、別途ルーターという機能を持つデバイスがある)を持つ様だ。つまり、具体的に記すと、CANバス上をすべてのデータが平等にすべて並んで流れている訳ではない様だ。
CANは既にその初版登場から、30年前後を経るのだが、幾つかバーションアップしつつ機能を拡張して来ている。また、当初から、その伝送距離に応じて最大通信速度(bps:bit/sec[秒間何bit通信が上限か])が規定されていたが、スペック上は 1Mbit/s だが、実態上は余裕を見て高速用が 500kbit/s、低速用が 125kbit/s が使用されてきた。ここで、各bitのゼロなり1なりのデータ時間長は、1をそれぞれ除すことで判るが、125bpsで8μs、500kbpsで2μsというbit時間長だと判る。(μ(マイクロ)は100万分の1)
また、当初アービトレーションフィールド長は11ビットだったが、管理下におけるECU(これらをノードと呼ぶ)を増やすため、拡張フォーマットフレームでは、アービトレーションフィールドを29ビットに増やした仕様を追加している。
また、ボッシュ社はCANの最大通信速度を改善するためCAN FD(CAN Flexible Data rate)という規格を2012年に発表している。このCAN FDは、アービトレーションとコントロールというフィールドは従来のCAN2.0と互換を持つが、データの部分を最大64バイトに拡張すると共に、その制御クロックを高速化することで、全体の通信速度を最大5Mbpsに向上させている。また、さらに次世代のCAN XLという規格の開発も進められている様だ。
4.CANの上を行く高速通信への模索
現在、自動運転への方向付けがなされ、カメラ画像、ミリ波レーダー、LiDAR(ライダー)などの新デバイスが既に搭載し始めている。特にカメラ画像とかLiDARのスキャン画像をそのものをバスに乗せると云うことは、そのデータ遅延も生じるので考え難いが、カメラやLidarでスキャンされたものから、至近のプロセッサーで有意なデータのみをバスに乗せ、ADAS・ECU等に転送するということは十分予想できるところだ。そうなると、現状のCAN FDでもデータスループットとして不足すると予想され、より高速なバスが幾つか候補に上がっている。それらが、FilexRayだと云われ欧州車では既に採用車種もある様だが、世界的に見るとあまり追随して行く気配がなく、雲行きが変わって来ていることがNet情報から読み取れる。
つまり、FiexRayでの最大転送速度は10Mbpsだが、それでも不足になるだろうと云うことと、これは私見も入るがCANは独ボッシュ社が開発し知的財産権を保有しており、その利用料を要する中で、コスト的に不利だという思いが内在しているのではないだろうか。この利用料だが、どうやら車両メーカーが負担しているのではなく、CANデータを送受する専用チップ(IC)メーカーが負担しており、そのチップがコスト高の要因の一つになっている様に読み取れる。
その様な中、次世代の車載バスとしてイーサネット(Ethernet)が候補に上がり、既に試行がなされている様だ。イーサネットは、現在のインターネットに接続したり社内LANだとかWifiで使われているプロトコルなのだが、この通信速度は最新最大のものでは1Gbpsに達するものまである。
この将来的にイーサネットが中心になる高速通信への要請として、一つはADAS等の自動運転デバイスでの車載ECUの通信量が格段に増加することも一つあるが、もう一つあるのがOTAを利用したサーバーとの随時通信による高度な自動運転機能の実現がある。例えば、随時更新された最新高精度地図情報だとか、近接する他車との情報との照合とかが想定できるだろう。それと、エンジンとかの走るためのデバイスもそうだが、ADASによる自動運転のソフトウェアの容量はそのレベルが上がる都度増加して行く方向だろう。それに対応したファームウェアのバージョンアップは、もはやディーラーなりに入庫してバーションアップしましょうと云うことでは追い付かなくなる様に想定できる。そうなると、走行中でも、車庫に保管中でも、自動的にOTAでバーションアップがなされ、次回の使用時なのか、信号で一時停止した瞬間なのか、システム次第だろうが、新しいソフトに切り替わり、より自動運転の信頼性を上げていく方向になり得るだろう。
※本項は、まず出始めに記したものであり、今後もう少し深掘りする記述をしてみたい。
このところ、車載用ネットワークシステム(LANと云うもの)に感心を傾け、種々書籍を含めNet探索も繰り返しているところだ。しかし、筆者は元々コンピューター技術者でもないし、いわゆるシステムインテグレーター(システム設計者)でもないし、様々な用語に戸惑いつつ、その仕組みをザックリと大づかみしようと思考しているところなのだ。
そこで、これまでのところ理解できた内容を噛み砕いて、日頃クルマに関わる方々の少しでも役立てばと云う思いで本記述を書き始めたい。なお、冒頭にも記した通り専門家でない者が記す文章だからして、その理解不足だとか、あえて説明を簡略化するためにザックリと切り分ける中で、本来の意味と異なるという部分があることを承知して戴きたい。
1.車載LANが何故求められたのか
LANとはローカルネットワークのことだが、端的に結論付ければ、様々なコンピューターで通信しつつ連携できるというのが根底思想にある。これはコンピューターに限らず、情報共有により複合的なシステムとしての利を追求する思考と考えて良いだろう。
クルマの場合で云えば、そもそも車両のコンピューター化はエンジンコントロールユニット(ECU)から始まり、次いでオートマチックトランスミッションのコントロールユニットが、そしてABSコントロールと次々にコンピューター制御機器が採用されていった。
その後は、このコンピューター制御というものが、従来の機械式の独立制御に比べ、ソフトウェアで制御できるということのメリットに気付くと共に、様々な機器がデバイスが、ECU制御化されて行く時代になった。
ここで、例として各車輪毎に装着される車輪回転センサー、つまり車速信号を考えてみたい。この車速信号は、本来ABSおよびトランスミッション程度に使用するだけだったのだ。しかし、各制御ECUの増加と共に、エンジン、ABSを発展させたESC(スタビリティコントロール)、スピードメーター、最近ではEPS(電動パワステ)、エアバッグ、BCM(ボデーコントロールモジュール)、自動運転を目指し機能を向上しつつあるADAS(先進運転支援システム)など、多くのECUに共有されている。ここで、従来の単独ECU同士が独立している中で、数個のECU同士を連携させようとするだけなら、それぞれのECU同士にスピードセンサーの信号を分岐して配線すれば良い訳なのだが、これが、先に列記した様に多数のECUに配線しなければならなくなってくると、配線は多数複雑化してくる。これは、スピードセンサーだけのことだが、別の信号線だとか、あるECUで処理した結果としての新たな信号を多数のECUと連携処理したいとなると、これら信号線の配線が非常に多くなってしまうことになる。
と云う様な多数のECUを搭載することにより、各ECUの情報共有だとか連携を行う必要上、多数の配線を使うムダを排除しつつ、バスラインで情報通信を行うという思想がLANというもので、その概念を図示したものが別添図(Fig C-1)だ。
つまり、共通バスラインという配線を通して、複数の通信を多重通信できるできるのが、LANもしくはバス通信と云われる概念となる。
ちなみに、単にバス通信というと、係る信号を平行に引き回したパラレルバスと、単線(もしくは複数などの少数配線)で多重通信するシリアル通信の2種があるが、車載LANにしてもインターネットなどの通信回線も何れもシリアルバス通信ということになる。
2.車載用LANの規格CANとは
先に述べた様に車載用LANシステムのバス通信は、シリアルバス通信だ。この概念を一般的に表してみたのが、添付図(Fig C-2)だ。
ここで、車載用各ECUを連携させるために接続しているバスラインは、現在業界スタンダードとなっているのがCAN(Controller Area Network)という、独ボッシュ社が開発し知的財産権を保有している通信プロトコル(通信の約束事)だ。
なお、先の図の中で、LIN(Local Interconnect Network)と記してあるのは、CANバスの下位の規格となる。CANほど通信速度を必用とせず、しかも接続相手に必ずしもCPUを使用する必要ない(ただし送受信する能力のある専用ASIC(特定用途向け専用LSIのこと)は必用となる)通信規格のことだ。
3.CANのデータフォーマット(波形)
ここでは添付図(Fig C-3)がCANの通信データの1フレーム分ということになる。ここで、フレームというワードだが、通信のまとまりとしての1単位となり、多数のECU同士で通信を開始すると、このフレームが連続することになる訳だが、場合によっては同時に複数のECUが送信を始めるとデータの衝突(コンフリクトと称する)や、他のECUの送信中に別のECUが送信し出すと、データがメチャクチャになりまともな通信が成立しない。そんな理由で、フレーム最初にアービトレーションとコントロールというフィールドを持つが、これは調停や制御の意味で、データの衝突が関知されると、そのID固有の優先順位に応じて、該当ECUに優先的に再送信の合図を出す。つまり、これらアービトレーションおよびコントロールは、個別の信号の送受信のIDを示すと共に優先順を判断して通信を制御するためにある。
なお、厳密な意味では異なる解釈となる様だが、この1フレームで送受信されるデータのくくりをパケットという呼び方をする場合がある。つまり、どんなに大きなデータでも、1フレームもしくは1パケットに分割して、送受信することができる訳だが、1つのパケットを受信して、続けて連続するパケットを受信できる保証はない。そこには、そのバス回線に接続された他の通信のパケットが入り込んで来るからだ。
シリアルバス多重通信においては、データ回線の混雑度に応じてこの様な不具合が生じる可能性もあるので、システム設計者は、データ遅延の問題の検討は欠かせないと思える。なお、参照図(Fig C-2)内に示したセントラルゲートウェイは、本来的な意味は異なるプロトコルを変換したりと云うのが主目的だが、場合によりID固有の優先順位に対応してデータを遮断したりする機能(PCでもゲートウェイの機能はソフトウェアとして持つし、別途ルーターという機能を持つデバイスがある)を持つ様だ。つまり、具体的に記すと、CANバス上をすべてのデータが平等にすべて並んで流れている訳ではない様だ。
CANは既にその初版登場から、30年前後を経るのだが、幾つかバーションアップしつつ機能を拡張して来ている。また、当初から、その伝送距離に応じて最大通信速度(bps:bit/sec[秒間何bit通信が上限か])が規定されていたが、スペック上は 1Mbit/s だが、実態上は余裕を見て高速用が 500kbit/s、低速用が 125kbit/s が使用されてきた。ここで、各bitのゼロなり1なりのデータ時間長は、1をそれぞれ除すことで判るが、125bpsで8μs、500kbpsで2μsというbit時間長だと判る。(μ(マイクロ)は100万分の1)
また、当初アービトレーションフィールド長は11ビットだったが、管理下におけるECU(これらをノードと呼ぶ)を増やすため、拡張フォーマットフレームでは、アービトレーションフィールドを29ビットに増やした仕様を追加している。
また、ボッシュ社はCANの最大通信速度を改善するためCAN FD(CAN Flexible Data rate)という規格を2012年に発表している。このCAN FDは、アービトレーションとコントロールというフィールドは従来のCAN2.0と互換を持つが、データの部分を最大64バイトに拡張すると共に、その制御クロックを高速化することで、全体の通信速度を最大5Mbpsに向上させている。また、さらに次世代のCAN XLという規格の開発も進められている様だ。
4.CANの上を行く高速通信への模索
現在、自動運転への方向付けがなされ、カメラ画像、ミリ波レーダー、LiDAR(ライダー)などの新デバイスが既に搭載し始めている。特にカメラ画像とかLiDARのスキャン画像をそのものをバスに乗せると云うことは、そのデータ遅延も生じるので考え難いが、カメラやLidarでスキャンされたものから、至近のプロセッサーで有意なデータのみをバスに乗せ、ADAS・ECU等に転送するということは十分予想できるところだ。そうなると、現状のCAN FDでもデータスループットとして不足すると予想され、より高速なバスが幾つか候補に上がっている。それらが、FilexRayだと云われ欧州車では既に採用車種もある様だが、世界的に見るとあまり追随して行く気配がなく、雲行きが変わって来ていることがNet情報から読み取れる。
つまり、FiexRayでの最大転送速度は10Mbpsだが、それでも不足になるだろうと云うことと、これは私見も入るがCANは独ボッシュ社が開発し知的財産権を保有しており、その利用料を要する中で、コスト的に不利だという思いが内在しているのではないだろうか。この利用料だが、どうやら車両メーカーが負担しているのではなく、CANデータを送受する専用チップ(IC)メーカーが負担しており、そのチップがコスト高の要因の一つになっている様に読み取れる。
その様な中、次世代の車載バスとしてイーサネット(Ethernet)が候補に上がり、既に試行がなされている様だ。イーサネットは、現在のインターネットに接続したり社内LANだとかWifiで使われているプロトコルなのだが、この通信速度は最新最大のものでは1Gbpsに達するものまである。
この将来的にイーサネットが中心になる高速通信への要請として、一つはADAS等の自動運転デバイスでの車載ECUの通信量が格段に増加することも一つあるが、もう一つあるのがOTAを利用したサーバーとの随時通信による高度な自動運転機能の実現がある。例えば、随時更新された最新高精度地図情報だとか、近接する他車との情報との照合とかが想定できるだろう。それと、エンジンとかの走るためのデバイスもそうだが、ADASによる自動運転のソフトウェアの容量はそのレベルが上がる都度増加して行く方向だろう。それに対応したファームウェアのバージョンアップは、もはやディーラーなりに入庫してバーションアップしましょうと云うことでは追い付かなくなる様に想定できる。そうなると、走行中でも、車庫に保管中でも、自動的にOTAでバーションアップがなされ、次回の使用時なのか、信号で一時停止した瞬間なのか、システム次第だろうが、新しいソフトに切り替わり、より自動運転の信頼性を上げていく方向になり得るだろう。
※本項は、まず出始めに記したものであり、今後もう少し深掘りする記述をしてみたい。