DroneCANのノードID・終端・実装トポロジ
ノード ID、ステータス証拠、物理トポロジ、終端リファレンス、文書化されたデバイス固有のサポートを通じて、DroneCAN のインストールを調査します。
構成変更前にノード一覧を作る
コントローラーと接続されている各 DroneCAN デバイスを、物理的な ID、ファームウェア、機能、および利用可能なノード情報とともにリストします。見慣れたデバイス名では、どの物理ユニットがメッセージを生成したかがわかりません。アドレスを変更したりコンポーネントを交換したりする前に、検出されたネットワーク状態を保存してください。このインベントリにより、断続的に機器が認識されなくなる報告に具体的な根拠が与えられ、新しく接続されたスペアが交換されたユニットと同一であるとみなされるのを防ぎます。
識別情報と割り当てを理解する
DroneCAN ノードにはネットワークに適した ID が必要であり、サポートされるシステムはさまざまな割り当て配置を使用できます。警告が消えるまで任意の値を割り当てるのではなく、デバイスとネットワークのドキュメントを読んでください。永続的なハードウェア ID とセッションで観察されるノード ID を区別します。再起動後に予想される動作を記録します。受信したデータはメンテナンスや再構成の間も正しいセンサーまたはアクチュエータに関連付けられたままでなければならないため、一意でわかりやすい ID が重要です。
物理的なバスを図示する
実際の設置に従って、ケーブル セグメント、ジャンクション、コネクタ、配電、終端をマッピングします。簡略化されたソフトウェア デバイス リストでは、すべての物理ブランチが明らかになるわけではありません。配置を該当するハードウェア ガイダンスおよび承認された航空機の設計と比較します。通信が不安定に見えるからといってターミネータを追加しないでください。正しく評価するには、既存の要素の場所と目的に加えて、デバイス要件と最近の作業中に行われた変更が必要です。
ノード状態と有効なアプリケーションデータを区別する
認識されているノードは、航空機が期待するすべての機能を提供しなくてもステータスを報告できます。関連するアプリケーション メッセージ、デバイスの正常性情報、実装サポートを調べます。逆に、表示項目の欠落は、バスの破損を証明するのではなく、受信構成に起因する可能性があります。タイムスタンプと影響を受ける機能を保存します。この区別により、すべての症状を同一として扱うのではなく、物理的な接続、ID、ソフトウェアの解釈、またはデバイス固有の動作に向けた次のチェックが行われます。
既知の基準構成で変更を評価する
デバイスまたはケーブルを交換した場合は、変更内容を正確に記録し、結果のトポロジと構成を確認します。承認された診断方法と適切な電気的予防措置を使用してください。起動、ステータス、および必要なアプリケーションの動作を、保持されているベースラインと比較します。機器検出が1回成功しただけでは、完全に受け入れられたわけではありません。証拠は、技術プロセスが実際に評価する条件内で、正しい物理デバイスが意図した情報を確実に提供することを示す必要があります。
整備できるネットワーク資料を残す
バス図、コンポーネント ID、割り当ての仮定、終端基準、ソフトウェア バージョン、および承認されたチェックを一緒に保存します。後の拡張では、検討せず機器を差し込む判断ではなくレビューが行われるようにします。これは、NiVO チームが普遍的な互換性を前提とせずに、サポートされている CAN ペリフェラルを評価するのに役立ちます。また、サービス通信の効率も向上します。技術者は、CAN センサーが時々失われるという単なる報告ではなく、識別可能なネットワークと限定された症状を受け取ります。
