GNSS 機器間の RTCM の相互運用性の確認
異なるシステムのベース、キャスター、ローバーを組み合わせる際に、メッセージの内容、信号サポート、および参照情報をテストします。
完全な組み合わせから始めます
RTCM は GNSS 情報を交換するために広く使用されていますが、 2 つの製品の頭字語は、完全な相互運用性テストではありません。 ベースはいくつかのメッセージの組み合わせを出力でき、ローバーはそれらの一部しかサポートできません。 正確な基本構成、トランスポート パス、ローバー モデル、およびファームウェアを文書化します。 この組み合わせは、標準サポートの 2 つの独立した主張ではなく、テストされているユニットです。
先に使用目的を定義します。 従来の RTK の観測値を運ぶストリームは、別の補正方法用に設計されたストリームとは異なります。 ローバーは、配信された情報の形式と意味の両方を理解する必要があります。 ネットワーク接続が成功すると、データ転送が実証されます。 受信機が意図した測位結果に必要なすべてのメッセージを使用できることを示していません。
さらに学ぶ RTCM メッセージ：補正の互換性を確認する
インベントリ サポートされている観測結果
ソースで観測された星座と信号を、ローバーがサポートするものと比較します。 有用な一般的な観察結果は、相対処理にとって重要です。 ローバーがそれらを追跡またはデコードできない場合、ソース信号の長いリストはほとんど役に立ちません。 実際のファームウェア バージョンの製造元のガイダンスを入手し、新しいバージョンの機能がフィールドのユニットに適用されると想定しないでください。
機器がメッセージ ファミリまたはレートの構成を許可する場合、ドキュメント化されたサポートされている組み合わせから始めます。 テスト中に加えられた変更を記録します。 帯域幅が高いように見えるという理由だけで、メッセージを無作為に減らしたり追加したりしないでください。 ストリームは、小規模で不完全な場合もあれば、大きくても互換性がない場合があります。 目標は、受信者に確実に配信される適切で使用可能な情報のセットです。
トランスポートとコンテンツを分けておく
データは、無線、ダイレクト ケーブル、または ntrip サービスで移動できます。 トランスポートの問題により、良好な RTCM コンテンツがローバーに到達するのを防ぐことができますが、接続が復元された後もコンテンツの問題が残ります。 両方のレイヤーを検査します。 バイトまたはメッセージが到着していることを確認してから、受信者の診断を調べて、アプリケーションが単に受信するのではなく、データが測位に受け入れられるかどうかを判断します。
キャスターは、通常、そこに供給されたストリームを配布します。 不足している参照情報を修復したり、すべてのメッセージを Rover 互換のフォームに変換したりすることは想定されるべきではありません。 変換サービスを意図的に使用する場合は、別のコンポーネントとして文書化してください。 関連する構成とバージョンを保持します。 その余分な段階は、リレー接続の動作が異なるときに直接ベース接続が機能する理由を説明するかもしれません。
リファレンス情報の確認
選択した出力でソース座標とアンテナ情報がどのように表されているかを確認します。 正しい観測メッセージを使用してローバーを使用しても、基準座標が間違っているか、または不適切な参照定義の下で解釈されている場合でも、オフセットが生成される可能性があります。 送信ストリームの外に基本設定レコードを保管して、オペレーターがソースが何を表現しようとしているのかをオフィスが確認できるようにします。
ユニット、座標参照フレーム、該当する場合のエポック、およびアンテナの高さの規則をチェックします。 これらのトピックは、多くの場合、接続画面よりも目立たなくなりますが、最終的なデータセットにより大きな影響を与える可能性があります。 混合機器のセットアップが制御に同意しない場合でも、標準の実装をすぐに非難しないでください。 共有座標またはアンテナのセットアップミスは、メッセージ自体が正しくデコードされているときに、相互運用性の失敗を模倣する可能性があります。
管理フィールド トライアルの実行
適切な独立した検証ポイントと同じ通信配置を備えたオープン サイトを使用して、生産のために計画された同じ通信を調整します。 1 回の試行を保証された製品仕様として扱うことなく、使用可能なソリューションまでの時間を運用上の観察結果として記録します。 複数のポイントで座標を比較し、新しい初期化後に重要なチェックを繰り返します。 組み合わせの限界を説明するため、失敗した試行はテスト レコードに残します。
基地からの分離や困難な通信場所など、関連する作業条件をテストします。 ベンチ テストは基本的なデコードを確認できますが、プロジェクト全体のフィールド パフォーマンスを確立することはできません。 テストされていない環境に注意してください。 結果として得られる承認には、構成と作業用封筒が記載されている必要があります。同じ基準を備えたすべての機器が同じように動作するという包括的なステートメントではありません。
さらに学ぶ RTCM メッセージ：補正の互換性を確認する
証拠による非互換性の診断
使用可能なデータが到着しても、ローバーが必要な状態を達成できない場合は、ストリームを受信者のドキュメントと比較します。 承認された監視ツールまたは受信機診断を使用して、メッセージの可用性を調べます。 タイムスタンプと構成とともに、許可されている短いサンプルを保存します。 RTK が機能しないとだけではなく、送信された内容とローバーが報告したことを機器サポートに正確に説明してください。
一度に 1 つの変数を変更します。 既知の作業用ローバーを同じソース、または疑わしいローバーを使用して、既知の作業ソースに対してテストすると、問題を絞り込むことができます。 これらの比較の間、座標系と独立した検証ポイント プロシージャを一貫させます。 そうでなければ、復号を解決するように見える変更が、最初のテストと比較できない別の参照配置を導入しただけかもしれません。
テスト済みのセットアップを承認して維持する
承認された構成レコードのリスト デバイス、ファームウェア、出力メッセージ、トランスポート設定、および結果をチェックします。 アクセス資格情報を非公開で保存する際に、このレコードにアクセスできるようにします。 ファームウェア、ベース出力プロファイル、またはキャスター パスが変更された場合、トライアルのどの部分を繰り返す必要があるかを決定します。 相互運用性の承認は、テスト済みの配置に関連付けられており、テストされていないリビジョンにサイレントに展開してはなりません。
トレーニングに承認された混合機器ワークフローを含めます。 オペレーターは、どのプリセットを使用するか、どのような通常の診断がどのように見えるか、いつ収集を停止するかを把握する必要があります。 標準ベースのワークフローの利点は実用的な柔軟性ですが、信頼性の高い柔軟性は検証に依存します。 意味のあるフィールド チェックに合格する文書化された組み合わせは、任意のベースとローバーが自動的に連携するという文書化されていない約束よりもはるかに便利です。
再現可能な互換性マトリックス
複数の機器の組み合わせを使用するプロジェクトの場合、RTCM が機能する単一のステートメントではなく、小さなマトリックスを維持します。 行は、ソース プロファイルとローバーとファームウェアの組み合わせの列を識別できます。 承認された各セルは、メッセージ構成、通信パス、および座標チェックを含むテスト レコードを指す必要があります。 同様の受信機が別の日に同じソースで動作した場合でも、テストされていないセルは目に見えてテストされていないはずです。
アップデートによってコンポーネントが 1 つ変更されると、マトリックスは繰り返し必要なテストを選択するのに役立ちます。 また、オペレーターが、直接無線の試用版がテストされていない中継ストリームを承認すると仮定するのを防ぎます。 プロジェクトが許可する代表的なテスト ログを保持し、正確な出力プロファイルを復元に使用できるようにします。 このアプローチにより、相互運用性が実用化されます。チームは、観察された互換性と、標準ラベルによってのみ提案される可能性との間の明確な境界を維持しながら、検証済みの配置の中から選択できます。
実践チェックリスト
- 正確なベース、メッセージ、トランスポート、ローバーのバージョンを記録します。
- デコードとは別に、座標情報とアンテナ情報を確認してください。
- ファームウェアまたは出力の変更後に重要な組み合わせを再テストします。
