CANバス搭載の車載コンピュータは、単に一対のCAN端子を提供するだけではありません。適切なメッセージを適切なタイミングで受信し、選択されたデータをアプリケーションに渡し、シリアルデバイスや無線リンクと共存し、車両の電気的および環境的条件に関わらず信頼性を維持する必要があります。
OEMにとって、ディスプレイサイズを選定した後が難関です。統合チームは、バスアーキテクチャ、メッセージ定義、オペレーティングシステムインターフェース、サービス動作、および受け入れテストについて合意する必要があります。このガイドでは、CANバス端末を再現可能な量産サブシステムに変換するための実践的なチェックリストを提供します。
PDS統合の図解。配線、プロトコル、およびソフトウェアの動作は、対象車両上で検証する必要があります。
ハードウェアを選択する前に、CANバス車両コンピュータのアーキテクチャを定義する。
CANネットワークは、共有差動バスです。複数の電子制御ユニットがフレームを交換し、各受信ノードがフレームが関連性があるかどうかを判断します。物理層、ビットレート、終端、コネクタポリシー、およびメッセージプロトコルは、車両設計に適合している必要があります。CSS Electronicsは、共通の用語を必要とするチーム向けに、 CANバスに関する有用な入門書を提供しています。
OEMが最初に決定すべき事項は、CANバス車両コンピュータにどのような動作を許可するかです。データ監視のみ、限定された一連のアクションの要求、ゲートウェイとしての動作、プライベートネットワークへの参加など、様々な動作が考えられます。この役割をインターフェース制御文書に明記してください。監視端末とコマンド実行機能を持つコントローラでは、テストとサイバーセキュリティ対策が異なります。
また、端末に接続されているすべてのバスを特定してください。商用車の場合、パワートレイン、ボディ、機器、診断、およびプライベートCANネットワークは分離されていることがよくあります。これらを分離またはゲートウェイ戦略なしで混在させると、不要なトラフィック、ウェイクアップ動作、または障害の伝播が発生する可能性があります。
| 統合レイヤー | デザイン上の決定 | 証拠が必要 |
|---|---|---|
| 物理的な | ビットレート、トポロジー、終端、ケーブル、コネクタ、絶縁 | ハーネス図、オシロスコープまたはアナライザによるデータ取得、およびEMC計画 |
| プロトコル | 生のCAN、J1939、CANopen、ISO-TP、UDS、または独自のフォーマット | メッセージデータベース、識別子、タイミング図、状態図 |
| オペレーティング·システム | ドライバー、API、権限、プロセスの優先度、およびリカバリ | SDKドキュメント、サンプルコード、および障害注入結果 |
| 応用 | デコード、フィルタリング、ログ記録、表示、およびビジネスロジック | 記録された車両データを含むエンドツーエンドのテストケース |
| ライフサイクル | バージョン管理、アップデート、診断、フィールドサービス | 構成ベースライン、リリースプロセス、および復旧手順 |
CANバスRS232 RS485車両コンピュータチェックリストを完了してください
OEMプロジェクトでは、CANと従来のシリアル機器を組み合わせることがよくあります。CANバスRS232 RS485車載コンピュータのチェックリストでは、各インターフェースを個別に文書化し、データパス全体をテストする必要があります。
CANバス
独立チャネル数、CAN FDサポート、ビットレート、終端方式、絶縁性、ウェイク動作、コネクタのピン配置を確認します。端末が特定のフレームのみを受信する必要があるか、メッセージも送信する必要があるかを確認します。車両ハーネス全体を使用して、バス負荷と最悪ケースの遅延を測定します。
RS232とRS485
RS232を搭載した車載コンピュータの場合、電圧レベル、ボーレート、フロー制御、コネクタ、ケーブル長、およびプロトコルを指定する必要があります。RS232は一般的にポイントツーポイント接続です。RS485は複数のノードで半二重または全二重動作を行う場合があるため、終端およびバイアス要件を定義する必要があります。ボーレート設定が同じであればプロトコルの互換性が保証されるとは限りません。
車両への取り付け前に、ループバックテストまたはデバイスレベルのテストを依頼してください。その後、CAN、両方のシリアルチャネル、USB、および無線接続における同時トラフィックをテストしてください。プロセッサの負荷共有と割り込み処理によって、単一インターフェースのデモでは明らかにならない問題が明らかになる場合があります。
PDS OEM統合の図解。インターフェースの動作は、提示された製品構成と照合して確認する必要があります。
メッセージデータベースとデータモデルを制御する
アプリケーションは、コードベース全体で生の16進数フレームをデコードしてはなりません。メッセージデータベース（DBC）を定義し、物理値と単位をマッピングし、テスト済みのデコードレイヤーを生成してください。更新レート、タイムアウト動作、無効値処理、バイト順序、スケーリング、および信号範囲を含めてください。
データベースのバージョン管理は、端末アプリケーションだけでなく、車両ソフトウェアとも連携させてください。ECUがメッセージを追加したり信号を変更したりした場合、統合チームはどの端末、クラウドモデル、テストケースが影響を受けるかを把握する必要があります。車両がなくても変更内容をデコードして再現できるよう、代表的なCANログを保存してください。
プロジェクトでSAE J1939を使用する場合は、ソースアドレス、パラメータグループ、要求動作、および診断処理について文書化してください。CANopenまたは独自のプロトコルを使用する場合は、同等のステートマシンとエラー定義を提供してください。
オペレーティングシステムとCAN APIを選択してください
Linux上で動作するCANバス搭載車両コンピュータは、カーネルのSocketCANサブシステムを介してインターフェースを公開できます。ソフトウェア開発チームは、標準的なソケット操作、フィルタ、およびネットワークツールを使用できます。カーネルバージョン、CANドライバ、受信バッファ構成、および権限は、開発ボードだけでなく、出荷イメージでも確認してください。
Androidの場合、サプライヤーはJava、Kotlin、ネイティブ、またはJNI APIを提供する可能性があります。アプリケーションがどのようにフレームを受信するのか、送信アクセスがどのように制御されるのか、サービスが再起動したときに何が起こるのかを確認してください。統合計画には、停止したプロセス、切断されたインターフェース、またはエラーパッシブバス状態から回復できるウォッチドッグまたはヘルスチェックを含める必要があります。
OpenHarmonyプロジェクトには、同様に具体的なインターフェース定義が必要です。CANがサポートされているという一般的な記述は避けてください。OEMには、実際のAPIインターフェース、サンプルプロジェクト、権限、ライフサイクル動作、デバッグ機能が必要です。
車両インターフェースを弱めることなく、GNSSと4G LTEを追加する
CANバスを備えたGNSS車載端末は、位置、動き、および車両状態データを統合できます。必要な精度、更新レート、座標フォーマット、時刻ソース、および補正サービスを定義します。実際の屋根、キャブ、貨物、および近くの無線機器を使用してアンテナの配置をテストします。GNSSの損失とCANタイムアウトを独立した状態として保持し、一方のソースが利用できない場合でも他方が無効にならないようにします。
4G LTE対応の車載コンピュータは、これらのデータストリームを車両群プラットフォームに拡張しますが、アップリンクは常に利用可能であるとは限らないため、サポートするバンド、キャリアプロファイル、ローミング動作、アンテナ分離、データ制限、再接続時間などを指定する必要があります。重要なレコードにはローカルバッファリングを使用し、どのフィールドを即時、定期的に、またはイベント発生後にのみ送信するかを定義してください。
データの所有権とアクセス権限を明確に定める。車両所有者は、位置情報、診断データ、運転者データ、および運用データに対する制御権を必要とする場合がある。端末およびクラウドプラットフォームには、明確な認証、認可、データ保持、およびリモートコマンドに関するポリシーが必要である。
電力、信号、およびソフトウェア境界を保護する
車両の電源には、始動時の電圧低下、負荷遮断、ジャンプスタート、およびアクセサリーのスイッチングが含まれます。CANバス車両コンピュータは、実際の車両クラスに応じて、入力範囲、過渡現象の標準、ヒューズ、接地、および点火動作を規定する必要があります。CANポートおよびシリアルポートは、外部機器に接続する際に、ガルバニック絶縁または保護が必要になる場合もあります。
OEMが信頼性を定義した後のみ、CANを信頼できるインターフェースとして扱います。送信識別子を制限し、受信長さと範囲を検証し、コマンドのレートを制限し、アプリケーションが無関係なバスチャネルにアクセスできないようにします。セキュリティ関連の構成変更をログに記録し、署名または検証済みのソフトウェアアップデートをサポートします。
ケーブルハーネスは保守性を考慮して設計する必要があります。コネクタにはラベルを貼り、ピン配置を文書化し、未使用ポートを保護し、必要に応じてトルク値を指定してください。ベンチテストで合格した端子でも、重いハーネスがコネクタを引っ張ったり、バスを乱すような突起部ができたりすると、故障する可能性があります。
生産リリースには受入マトリックスを使用する
| テストエリア | 受入基準の例 |
|---|---|
| バスの状態 | 通常動作、起動、ウェイクアップ、シャットダウンの各シーケンス中に、意図しないエラーフレームは発生しませんでした。 |
| データ精度 | 復号された信号は、動作範囲全体にわたって基準測定値と一致します。 |
| 遅延 | 重要なデータは、プロジェクトの納期内にアプリケーションに届く。 |
| 回復 | ケーブル、電源、ネットワーク障害発生後、CAN、シリアル通信、GNSS、セルラー通信サービスが復旧する。 |
| パワーサイクル | 設定データとバッファリングされたデータは、必要な点火およびバッテリーの状態でも保持されます。 |
| 更新とロールバック | アップデートが失敗した場合、ユニットを既知の正常なバージョンに戻すことができます。 |
CANバス搭載車両コンピュータは、生産前に、バス、レイテンシ、リカバリ、およびアップデートに関する承認済みのテストマトリックスに合格する必要があります。PDSは、堅牢な車両端末向けにOEM/ODM統合サポートを提供し、プロジェクトのソフトウェア計画に合わせてインターフェースを調整できます。車両レベルのインターフェース仕様は引き続きOEMが所有し、最終的な検証計画を承認する必要があります。
PDS検証図。製品出荷前に、受入基準と試験装置について合意しておく必要があります。
よくある質問
CANバス搭載の車載コンピュータが車両データを受信するために必要なものは何ですか？
互換性のある物理CANインターフェース、適切なビットレートと終端、関連バスへのアクセス、メッセージデータベース、および必要な信号をデコードするソフトウェアが必要です。端末はタイムアウト、無効な値、およびバス障害も処理する必要があります。
1台の車両用コンピュータでCAN、RS232、RS485を同時に使用できますか？
多くの堅牢な車載コンピュータはこれらのインターフェースを同時にサポートできますが、正確なチャネル数と分離レベルは機種によって異なります。必要なすべてのトラフィックを同時にテストし、オペレーティングシステムが各インターフェースを確実に公開していることを確認してください。
J1939はCANバスと同じですか？
J1939はCANネットワークで使用される上位層プロトコルであり、主に大型車両で用いられます。端末はCANを物理的にサポートすることはできますが、プロジェクトで要求される特定のJ1939メッセージや診断動作をサポートする必要はありません。
CANデータは端末上で処理すべきか、それともクラウド上で処理すべきか？
時間制約のあるフィルタリング、表示、アラート、バッファリングには端末を使用してください。ネットワークの可用性とデータポリシーが許す場合は、要約されたレコードまたはイベント駆動型のレコードをクラウドに送信してください。データの分割は、レイテンシ、プライバシー、コスト、オフライン要件に従って行う必要があります。
お問い合わせ
📧メールアドレス：[email protected]
📞電話番号：+86 13421822024
🌐ウェブサイト： www.szpds.com
免責事項
本記事の情報は参考情報としてのみ提供されています。PDS Technology Co., Ltd.は、内容の誤り、脱落、または特定の用途への適合性について一切責任を負いません。製品仕様は予告なく変更される場合があります。ご購入前に、技術的な詳細事項はすべて弊社チームにご確認ください。
PDSテクノロジーについて
PDS Technologyは、高精度RTK GNSS端末および車載コンピュータの大手OEM/ODMメーカーであり、2011年以来、農業、建設、鉱業、タクシー、物流業界にサービスを提供しています。
15年以上にわたる車載グレードの研究開発経験に基づき、当社は堅牢なマルチOS（Android/Linux/OpenHarmony）対応デバイスを提供しています。これらのデバイスは、RTKによるセンチメートルレベルの測位精度、IP66の保護等級、そしてAI対応性能を備えています。IATF16949認証を取得した当社の工場では、世界中で10万台以上の製品を生産し、中国の農業用自動操舵端末市場で30%以上のシェアを占めています。日本、米国、英国、トルコ、ロシアをはじめとする世界各国に製品を輸出しています。
