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