LoginSignup
2
2

CAN Bus:機能、利点と課題、高速ローカル処理チュートリアル

Posted at

image.png

CAN Busとは?

CAN(Control Area Network)バスは、機器が信頼性の高い効率的な方法でデータを交換することを可能にするシリアル通信プロトコルです。自動車に広く使われており、車両内のECUをつなぐ神経系のような働きをしています。

CAN Busは、1980年代にBosch社によって自動車用に設計されたものです。マルチマスター、マルチスレーブ、半二重、フォールトトレラントのプロトコルであり、車載アプリケーションの要件によく適合している。シンプルで低コスト、かつ信頼性が高く、過酷な環境でも使用することができます。CAN Busは、車両内のすべてのECUに1つのポイントを提供するため、接続や診断が容易になります。

CAN Busデータは、接続されたデバイスのパフォーマンスとステータスに関する貴重な洞察を提供することができます。しかし、CAN Busデータの収集と処理は、高いデータレート、低い帯域幅、および変化するネットワーク条件のために困難である可能性があります。

これらの課題を克服するための一つの解決策として、MQTTを使用することが考えられ、弱いネットワーク条件でも自動車からクラウドへのタイムリーなデータ伝送を可能にします。EMQXはオープンソースのMQTTブローカーで、CAN Busデータを収集するための信頼性と拡張性の高いMQTTインフラストラクチャを構築するのに役立ちます。

image.png

CAN Busの歴史

CAN(Controller Area Network)バスは、ドイツの多国籍エンジニアリング・テクノロジー企業であるボッシュが1980年代前半に開発したものである。その主な目的は、自動車用の効果的な通信システムを確立することであり、特に自動車のワイヤーハーネスの複雑さを軽減することであった。

1986年、ボッシュは最初のCANプロトコルを発表し、その信頼性と堅牢性から自動車メーカーの間で急速に普及が進みました。1993年には、ISO-11898の国際規格になりました。プロトコルの進化をまとめると

  • 1991:メルセデス・ベンツ、W140型Sクラスにいち早くCAN Busを搭載。
  • 2004:CAN FD(Flexible Data Rate)が導入され、従来のCANネットワークよりも高いデータレートと大きなペイロードを提供する。
  • 2015:クラシックCANとCAN FDの両プロトコルを実装した機器のコンフォーマンステストプランとして、ISO-16845:2015が採用されました。

自動車用以外にも、この汎用性の高いネットワークプロトコルを採用する産業が増えました。現在では、産業用オートメーションシステム(CANopen)や船舶用電子機器(NMEA 2000)などで使用されています。その理由は、過酷な環境下でも確実に動作し、かつ低コストで実装できることにあります。

CAN Busの仕組みは?

CAN Busは、分散型の通信プロトコルです。その分散型アプローチにより、信頼性とリアルタイム性が不可欠な自動車や産業用システムのアプリケーションに最適です。

CANネットワークでは、すべてのノードがツイストペア配線または光ファイバーケーブルで接続されています。各ノードは、受信メッセージの処理と送信メッセージの送信を担当する独自のマイクロコントローラーを持っています。データはノードから共有バス上にブロードキャストされ、他のすべてのノードがそれを受信できるようになります。通信プロセスの主なステージは以下の通りです:

  1. アービトレーション(優先度制御):複数のノードが同時に送信しようとしたときの衝突を防ぐため、CANではメッセージの優先順位に基づく調停プロセスを採用しています。メッセージの識別子の値が低いほど、その優先順位は高くなります。
  2. エラー検出:内蔵されたエラー検出メカニズムにより、CANネットワーク内のデータの完全性が保証されます。これには、巡回冗長検査(CRC)、フレームチェックシーケンス(FCS)、受信ノードからの確認ビットが含まれます。
  3. フォールトコンファインド(Fault confinement):送信中にエラーや故障を検出したノードは、正常な動作が再開されるまで「エラーパッシブ」状態になります。これにより、欠陥のある伝送がシステム全体の機能に影響を与えることを防ぎます。

このような特徴の組み合わせにより、CAN Busは、自動車やFA機器などの複雑なシステムにおいて、異なるコンポーネント間の信頼性の高い通信を確保しながら、高い効率性を維持することができます。

CANプロトコルのメッセージ構造

CAN Busシステムにおけるメッセージ構造は、機器間の効率的な通信を行う上で非常に重要である。プロトコルは、識別子、制御フィールド、データフィールド、エラー検出メカニズムなど、いくつかのフィールドから構成されるデータフレーム形式を使用しています。

  • Identifier(識別子):このユニークな値によって、ネットワーク上の各メッセージの優先順位が決定されます。標準の11ビット識別子(CAN 2.0A)では、最大2048種類の優先順位が利用可能です。29ビットの拡張識別子(CAN 2.0B)では、5億以上の異なる値でさらに多くのオプションを提供します。
  • データ長コード(DLC):制御フィールド内にあり、データフィールドに何バイト存在するかを指定します。
  • データフィールド:データフィールド:ノード間で伝送される実際の情報がバイトサイズのセグメントで格納されている。
  • CRC(Cyclic Redundancy Check):巡回冗長検査:送信エラーを検出し、必要に応じて再送信を要求することで、信頼性の高い通信を実現する内蔵のエラー検出機構です。
  • Acknowledgment Slot(確認応答スロット):受信ノードがメッセージの正常な受信を確認するため、または再送を必要とするエラーを示すために使用される1ビット。
  • エラーフレーム:CANメッセージングのオプションで、ノードが自身の送信やネットワーク上の他のデバイスからの受信メッセージに問題を検出した場合に信号を送ることができます。

CANの種類

ここでは、CANの主な3つのタイプを紹介します:

低速度CAN

低速CANは、フォールトトレラントまたはISO 11898-3としても知られ、最大125kbpsの速度で動作する。ボディコントロールモジュール、ドアロック、ウィンドウコントロールなど、データ伝送速度が重要でないシステム向けに設計されています。その主な特徴は、バス内の1本のワイヤーが故障しても機能を継続することができることです。

高速CAN

高速CAN(ISO 11898-2)は、最大で1Mbpsの速度に達することができます。このタイプのネットワークは、低速のものと比べてデータ転送速度が速いため、エンジン管理システムや電子ブレーキシステムなど、より時間的制約のあるアプリケーションに適しています。しかし、低速ネットワークに見られるようなフォールトトレランス機能はありません。

CAN FD(フレキシブル・データ・レート)

ボッシュが2012年に発表したCAN FDは、既存の高速機器との後方互換性を保ちながら、データレートを5Mbpsまで向上させた高速ネットワークの拡張技術である。この技術の主な利点は、従来のCANよりも大きなペイロードをより効率的に伝送できることにあり、複雑化する電子システムを持つ現代の自動車に最適な技術です。

CAN Bus:利点と課題

CAN Busの主なメリットは何ですか?

CAN Busデータは車両の性能、状態、動作に関する貴重な情報を提供できる。クラウドにCAN Busデータを収集することは、ビッグデータ分析を通じて車両データの潜在能力を活用する強力な方法である。大量の車両から収集したデータに機械学習、人工知能、その他の分析ツールを適用することで、車両メーカーは貴重な洞察を得て、車両の性能を最適化するために活用できる。

  • 障害の検出、トラブルシューティング、予測:CAN Busデータを分析することで、デバイスやセンサーからの異常や誤った信号を特定できる。これにより、問題の根本原因を診断し、より大きな損傷や安全上の問題につながる前に修正できる。メーカーは収集したデータをモデルに入力することで、機械学習モデルを訓練して障害を予測することもできる。
  • 車両データの可視化:収集したデータを使用して、ユーザーはさまざまな車両とメトリクスをフィルタリング、ソート、比較できるダッシュボードに集約データを表示するシステムを開発できる。ダッシュボードはデータ分析に基づいてアラートと推奨事項も提供する。このシステムにより、ユーザーはパフォーマンスに関する洞察を得ることができる。
  • 車路協調システム:収集したデータは、道路インフラストラクチャデータとともに算出され、車路協調システムを構築するために使用できる。AI時代には、データが最も価値のある財産となります。自動車からクラウドにデータを集め、データベースやデータレイクなどあらゆるデータインフラにデータを分散させることで、ユーザーはほぼすべての種類のアプリケーションにデータを活用することができます。

リアルタイムでのデータ収集の課題とは?

車両上でローカルにCAN Busデータを収集することはかなり成熟しています。しかし、データレートが高く、帯域幅が狭く、ネットワークの状態が変化しやすいため、CAN Busデータを収集して処理し、その結果をリアルタイムでクラウドに転送することは困難な場合があります。したがって、すべてのCAN Busデータをクラウドに転送して処理することは現実的ではありません。そこで、エッジ側でCAN Busデータをローカルに収集・処理することでデータ量を削減し、その知見をリアルタイムでクラウドに転送することができます。

このようなソリューションを構築するためには、少なくとも2つのコンポーネントが必要です:

  1. エッジコンピューティングエンジン:エッジコンピューティングエンジンは、必要なCAN Bus信号のみを収集し、柔軟に処理し、リアルタイムでMQTT転送アクションをトリガーすることができます。LF Edge eKuiperは、オープンソースのエッジコンピューティングエンジンで、CAN Busデータをリアルタイムで処理・解析することができます。
  2. MQTTブローカーをクラウドに:MQTTブローカーは、処理されたCAN Busデータをリアルタイムでクラウドに転送するのに役立ちます。EMQXはオープンソースのMQTTブローカーで、CAN Busデータを収集するための信頼性と拡張性の高いMQTTインフラストラクチャの構築を支援することができます。

詳しくはこちらをご覧ください:
https://ekuiper.org/
https://www.emqx.com/ja/products/emqx-ecp

次に、EMQXとeKuiperを組み合わせたソリューションのを全面的に説明します。

eKuiperでCAN Busローカル処理の課題に取り組む

eKuiperはオープンソースのエッジコンピューティングエンジンで、CAN Busデータをリアルタイムで処理・解析することができます。eKuiperはエッジでのストリーム処理用に設計されており、CAN Busが生成する典型的なストリーミングデータのリアルタイム処理に適しています。eKuiperはこれらの課題に対処できます:

  • CAN Busから発生する大量のデータをリアルタイムで処理するのに十分な性能。データ転送のための帯域幅を削減するために、興味のある信号だけを柔軟にフィルタリング、処理、ピックすることができます。
  • バイナリCANフレームを意味のある信号に解析し、ルール処理とトリガーアクションを可能にすることができる。動的なDBCファイルの読み込みをサポートしており、エンジンを再起動することなく、ユーザー自身で柔軟にDBCファイルを変更し、異なるCAN Busデバイスに適応することができます。また、DBCファイルを開発チームと共有する必要がなく、プライベートかつセキュアに使用することができます。
  • 異なるCANフレームからの信号を柔軟に組み合わせ、ルールによってアプリケーションのための完全なメッセージを構築することができます。ユーザーは、ホットリロードにより、異なるユーザーシナリオや要件変更に適応するために、ルールを俊敏に変更することができます。

チュートリアルeKuiperによるCAN BUSデータのローカル処理

ステップ1:CAN Busへの接続

eKuiperは、CANソースプラグインを使用してCAN Busに接続し、CANフレームを受信します。下図に示すように、CAN Busに接続するための2つのモードをサポートしています。

image.png

  1. SocketCanでCAN Busに直接接続します。SocketCANは、BerkeleyソケットAPI、Linuxネットワークスタックを使用し、CANデバイスドライバをネットワークインターフェースとして実装しています。CAN BusがLinuxシステムに接続されると、ユーザーはCANネットワークインターフェイスを取得することができます。eKuiperでは、CANネットワークインターフェイスとDBCファイルパスを指定して、CANストリームを作成することができます。その後、任意のルールをCANストリームに適用して、CAN Busデータを処理することができます。
  2. TCP/UDPでゲートウェイを経由してCAN Busに接続します。ゲートウェイは、複数のCANフレームを1つのパケットにまとめ、TCPまたはUDPで一括送信するCANアダプターを使用することができます。ゲートウェイが送信するパケットフォーマットは標準化されていないことに注意してください。そのため、それに適応するようにプラグインを修正する必要があるかもしれません。eKuiperでは、TCP/UDPアドレスとDBCファイルパスを指定することで、CANストリームを作成することができます。その後、任意のルールをCANストリームに適用して、CAN Busデータを処理することができます。

ステップ2:CAN Busデータのデコード

CAN Busのデータはバイナリ形式で、フレームとして構成されています。CANフレームは、いくつかのフィールドで構成されています。CANのプロトコルには、CAN2.0A、CAN2.0B、CANFDなどさまざまなものがあります。CANフレームのフォーマットは、プロトコルによって微妙に異なっています。CAN2.0AのCANフレーム形式を下図に示します。

image.png

その中でも、CAN Busのデータをデコードするために重要なフィールドが2つあります:

  1. IDフィールドです:IDフィールドは、CANフレームを識別するために使用されます。CAN 2.0Aプロトコルの場合は11ビット、CAN 2.0BとCANFDの場合は29ビットです。
  2. Dataフィールド:データフィールド:データフィールドは、実際のデータを運ぶために使用されるペイロードです。CAN 2.0A と CAN 2.0B では 0-8 バイト、CANFD では 0-64 バイトです。

ペイロードでは、データは一連の信号として整理される。信号は、特定の長さとペイロード内の特定の位置を持つ名前付きデータ項目です。DBCファイルは、生のCAN Busデータを「物理的な値」にデコードするための情報を含むテキストファイルである。信号名、長さ、位置、および生データを物理値に変換するための変換式が定義されています。

eKuiperでは、ユーザーはCAN Busデータを解析する際に使用するDBCパスを指定することができます。eKuiperでDBCを設定するのは、かなり柔軟で安全です。

  • 複数のDBCファイル:ユーザーは、DBCのパスとしてディレクトリを指定することができます。そのディレクトリ内では、複数のDBCファイルがアルファベット順に読み込まれ、すべてが有効になります。これは、ユーザーが別々のDBCファイルを使用して、インクリメンタルに信号を追加したり戻したりするのに役立ちます。
  • 動的なDBCファイルの読み込み:DBCファイルは、開発時にデプロイすることなく、実行時にロードされます。これにより、ユーザーはDBCファイルを非公開にし、安全性を保つことができます。
  • ホットリロードを実現:エンジンを再起動することなく、ユーザー自身でDBCファイルを変更し、異なるCAN Busデバイスに適応させることができます。

eKuiper CANソースを設定した後、ユーザーは、物理的かつ意味のある信号でCAN Busデータを受信するストリームを作成することができます。例えば、CANペイロード 0x0000000000000000
は、以下の信号に解析することができます:

{
"signal1": 0,
"signal2": 0,
"signal3": 0,
"signal4": 0,
"signal5": 0,
"signal6": 0,
"signal7": 0,
"signal8": 0
}

次に、eKuiperの強力なストリーム処理機能を活用し、MQTTからの受信と同様に、解析されたデータを柔軟に処理することができます。

ステップ3:CAN Busデータの処理

解析されたデータを取得した後、我々はeKuiperによってそれを使用して多くのことを行うことができます。データ転送のための帯域幅を減らすために、興味のある信号だけをピックアップすることができます。例えば、 signal1 と signal2 の信号のみを選択することができます。

{ "signal1": 0, "signal2": 0 }

これを実現するeKuiperのSQLはシンプルです:

SELECT signal1, signal2 FROM canStream

CANフレームのサイズは限られているため、必要な信号が複数のCANフレームに分散している可能性が高いです。このような場合、異なるCANフレームの信号を柔軟に合成することで、様々なアルゴリズムを持つアプリケーションに対して、ニーズに合わせて完全なメッセージを構築することができます。詳しくは、データ合成の例をご覧ください。ここでは、signal1をメインプロパティとして、データをピックアップしています。

SELECT signal1, latest(signal2) as signal2 FROM canStream WHERE isNull(signal1) = false

また、何らかのイベントが発生したときだけデータを収集するという処理もあります。これも帯域幅を大幅に削減することができます。例えば、signal1が100より大きいときだけデータを収集することができます。

SELECT signal1, signal2 FROM canStream WHERE signal1 > 100

しかも、この処理ルールは、その場で柔軟に変更することが可能です。最初から必要なシグナルを特定できなくても心配はありません。ホットリロードで要件変更に適応したルールに変更することができます。

最も成熟した使い方は、柔軟なデータ収集を実現することです。それ以外にも、eKuiperは次のようなシナリオで使用することができます:

  1. 車両側のリアルタイムで柔軟なルールエンジンで、特定の条件に基づいてアクションを引き起こすことができます。例えば、車速が70mphを超えると自動的に窓を閉めるなど。
  2. コーディングやクラウド接続なしでデータとAIモデル(現在はTF Lite)の配線が可能なアジャイル・スマート・アナリティクス。この機能により、速度やタイヤ空気圧などのデータから走行モードを予測・提案するなど、リアルタイムのデータ分析が可能になります(ネットワーク接続なしでも可)。
  3. エッジコンピューティングで転送帯域を削減し、クラウド側のコンピューティングプレッシャーを軽減する。保存するタイムウィンドウの平均速度を計算するなど、データの解析、再フォーマット、変換を行う。
  4. 異種データのアグリゲーション様々なプロトコル(TCP、UDP、HTTP、MQTT)、様々なフォーマット(CAN、JSON、CSVなど)からデータを解析し、柔軟なルールでマージします。
  5. メッセージルーティング。どのデータをクラウドに送り、どのデータをローカルに保存して他の車両側アプリで活用するかを決定する。例えば、GDPRや何らかのホワイトリストに基づいて、ルーティングを決定する。

MQTTを使ったCAN Busのデータ収集

CAN Busのデータ収集にEMQXのようなMQTTブローカーを使用すると、以下のようなメリットがあります:

  • ネットワークのオーバーヘッドを削減:MQTTは、バイナリフォーマットと最小限のヘッダーを使用してメッセージをエンコードするため、ネットワーク帯域幅の消費を抑え、データ伝送効率を向上させることができます。
  • スケーラビリティの向上:MQTTは、1つのブローカーで数千の同時接続と数百万メッセージ/秒をサポートすることができます。これにより、性能や信頼性を損なうことなく、複数のCAN Busデバイスから大規模なデータ収集を行うことができます。
  • セキュリティが強化されています:MQTTは、TLS/SSL暗号化、ユーザー名/パスワード認証、アクセスコントロールリスト(ACL)などの様々なセキュリティ機構をサポートし、不正なアクセスや改ざんからデータを保護します。
  • 相互運用性の向上:MQTTはオープンスタンダードに基づき、様々なプラットフォームや言語で広くサポートされています。これにより、CAN Busデータを他のシステムやアプリケーションと統合することを容易にすることができます。

これらの利点に加え、EMQXはより多くの機能を提供し、eKuiperと一緒に、ユーザーがCAN Busデータを転送する際に、帯域幅の節約、待ち時間の短縮、信頼性の向上に貢献することができます。

帯域幅の節約

MQTTでCAN Busのデータを転送するには、通常、帯域幅が限られた弱いネットワーク条件で転送する必要があります。この場合、データサイズをできる限り小さくする必要があります。

eKuiperシンクでは、 format
オプションでデータ形式を指定することができます。デフォルトのフォーマットは JSON
です。これを protobuf
に変更すると、データをバイナリ形式に直列化し、データサイズを大幅に縮小することができます。さらに、 compress
オプションで gzip
などの圧縮方式でデータを圧縮することができます。こうすることで、元のJSONデータと比較して、データサイズを大幅に削減することができます。特にバッチで送信する場合、あるテストケースでは、データサイズを90%以上削減することができました。

リアルタイムデータ

クラウドアプリケーションには、時間的な制約があるデータもあります。例えば、車両事故を診断するためのデータは重要です。この場合、レイテンシをできるだけ減らす必要があります。eKuiper ruleでは、MQTTシンクを使ってEMQXにデータを送ることができます。

リアルタイムシナリオで帯域を節約するために、eKuiper MQTTシンクでは、上記のようにシリアライズ形式と圧縮方法を設定することができます。EMQX側では、データの解凍とデシリアライズをサポートするルールエンジンが提供されています。また、EMQX側にはルールエンジンが用意されており、データの解凍やデシリアライズをサポートしています。

ファイルでのバッチデータ

時間依存性のないデータの場合、データをファイルまたはローカルDBに保存し、バッチでクラウドに送信できる。これにより、さらに帯域幅を節約するための高い圧縮率を達成できる。eKuiperルールでは、ファイルシンクを使用してデータをローカルに保存および圧縮できる。ファイルローリングポリシーの構成をサポートしている。たとえば、ファイルローリングポリシーを10分ごとにファイルをロールするように構成できる。このようにして、バッチでデータをファイルに保存できる。EMQXはファイル転送をサポートする新機能を開発している。完了すると、保存されたファイルをMQTTを介して転送できる。現在、ユーザーはファイルをクラウドに転送するために他のツールを使用できる。

まとめ

今回のブログでは、eKuiperとEMQXを使って、車両からCAN Busデータを収集、処理、クラウドに転送する方法を紹介しました。次回のブログ記事では、各ステップについてより詳しく解説していきます。

元々は www.emqx.com で公開されました

2
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
2