既知のワークフローを失うことなく、GNSS ファームウェアの更新を管理します
新しいレシーバーまたはコントローラーのバージョンを本番環境に導入する前に、設定を保持し、重要な土地調査タスクをテストしてください。
更新を構成変更として扱います
ファームウェアとソフトウェアの更新により、機器が改善されますが、設定、サポートされるワークフロー、またはインターフェイスの動作も変更できます。 Land Survey 組織は、承認された構成をサポートするバージョンを認識しておく必要があります。 更新を、重要なキャンペーンに出る直前に、定期的なボタンを押すのではなく、制御された変更として扱います。 問題は、改訂されたシステムが引き続きタスクを実行し、プロジェクトに必要な証拠を保持するかどうかです。
使用中のレシーバー、コントローラ、アプリケーションの正確なバージョンを特定することから始めます。 フィールド テストとセットアップ テンプレートでその記録を保持します。 モデル名だけでは、すべてのユニットの処理および通信動作を経時的に説明するものではありません。 更新後に問題が発生した場合、バージョン レコードは、先週機器が異なっているように見えた不確かなメモリではなく、比較のための具体的な出発点を提供します。
該当するリリース情報をお読みください
正確な製品については、公式の製造元の指示とリリース ノートを使用してください。 前提条件、互換性、および設定またはデータ形式の変更内容を確認してください。 同様のモデルの更新がケースの機器に適用されると推測しないでください。 指示が不明な場合は、作業予定の作業のために乗組員が依存する生産ユニットを変更する前に、サポート ルートを通じて問題を解決してください。
実際に提供された情報を使用して、推奨される改善と緊急の運用要件を分離します。 プロジェクトの状況は重要です。オフィスの準備中にテストできる変更は、キャンペーンの途中で混乱を招く可能性があります。 更新プログラムが何を修正するかについて、サポートされていない主張をしないでください。 変更の理由と、組織が後で検証しようとしている特定の動作を記録します。
さらに学ぶ 橋の接近と接続道路の GNSS 制御
既知の構成を保持します
サポートされているメソッドで設定をバックアップし、重要な値を読み取り可能な形式で記録します。 修正プロファイル、アンテナ情報、ロギング設定、関連するジョブ テンプレートを含めます。 バックアップ ファイルは、その範囲と復元方法が理解されている場合にのみ役立ちます。 一部の設定は、コントローラーにあるものもあれば、レシーバーまたは別のアプリケーションにあるものもあります。 これらの境界を特定して、1 つのエクスポートでシステム全体をキャプチャすることがチームに想定されないようにします。
既知の作業構成から代表的なテスト データと成功したチェック レコードを保持します。 これらは、改訂されたシステムの比較を提供します。 接続設定を記録するときは、資格情報を非公開にしてください。 一般的な変更メモは、パスワードを公開せずにテクニカル プロファイルを特定する必要があります。 変更しようとしているデバイスだけではなく、承認済みのバックアップとバージョン情報をプロジェクトまたは機器のアーカイブに保存します。
実用的なテスト ウィンドウを選択
問題の検査、テスト、解決にかかる時間があれば、アップデートをスケジュールします。 チームが明確な比較を求めている場合は、無関係なハードウェアやテンプレートの変更をいくつか組み合わせて使用しないでください。 可能な場合は、すべての機器を交換する前に、非臨界ユニットまたは制御パイロットを使用してください。 目的は、すべての改善を遅らせることではなく、改訂された配置が評価される間、実際の参照を維持することです。
製造元の手順に従って、電源、接続、および完了のチェックを行います。 サポートされていない場合は、リカバリまたはダウングレードの方法を即興で実行しないでください。 中断または予期しないメッセージを記録し、適切なサポートを求めます。 更新が完了したら、報告されたバージョンと重要な設定を調べます。 インストーラーからの成功のメッセージは、プロセスの 1 つの段階であり、最終的な土地調査の準備状況の決定ではありません。
さらに学ぶ 土地調査員全体で一意なポイント名を作成
重要なフィールド関数をテストする
意図した修正ソースに再接続し、ローバーで使用可能なデータを検証します。 メッセージの互換性、修正年齢、必要なソリューションの状態、および制御された中断後の動作を確認してください。 特殊な観察モードが承認されたワークフローの一部である場合は、適切な条件下で初期化と出力をテストします。 まったく異なる試行に起因するのではなく、変更された結果を解釈できるようにするため、同じ文書化されたテスト手順を使用してください。
適切な既知のポイントを占有し、プロジェクト基準を使用して水平コンポーネントと垂直コンポーネントを比較します。 観察と構成を保持します。 受信機が固定されているか、インターフェイスが使い慣れているように見えるという理由だけで、更新を受け入れないでください。 意味のある問題は、完全に改訂されたワークフローが、組織にとって重要な条件下で依然として許容できる結果をもたらすかどうか、およびその診断が乗組員に理解できるかどうかです。
記録とエクスポートの確認
代表的なポイント、属性、および生のログを作成し、それらを意図した Office ルートに転送します。 宛先ソフトウェアで識別子、単位、高さの定義、および形式の解釈を調べます。 更新は、位置決めが変更されていない場合でも、データの取り扱いに影響を与える可能性があります。 生産記録が蓄積される前に、チームが不足しているフィールドまたは変更されたエクスポート規則を認識できるように、予期された結果の小さな既知のテスト データセットを保持します。
ジョブのインポートとテンプレートの動作もチェックします。 古い構成では、デフォルトで読み込まれるか、以前に保存されていた設定が省略される場合があります。 インポートされたファイル名が同等であると仮定するのではなく、アクティブな値を確認してください。 変換ツールが同時に更新される場合は、そのバージョンを記録して出力をテストします。 最終アーカイブは、各派生ファイルを作成したソフトウェアを明らかにする必要があります。
さらに学ぶ 橋の接近と接続道路の GNSS 制御
変更を承認または含む
テスト、結果、および制限を記録します。 改訂されたシステムが必要なチェックに合格した場合は、それを承認されたバージョンとして識別し、乗組員の指示を更新します。 問題が解決しない場合は、ユニットを影響を受ける本番ワークフローから除外するか、承認済みの代替手段を使用してください。 修復については、製造元のガイダンスに従ってください。 設定を静かに元に戻し、テストされた内容や変更が拒否された理由の証拠を消去しないでください。
一部の機器が更新され、一部の機器が以前のバージョンに残っている場合は、区別を表示します。 混合フリートは、その構成がわかっている場合は管理できますが、1 つの統一設定と混同すると、不必要な不確実性が生じます。 デバイスとバージョン別のラベル テスト ステータス。 これにより、フィールド スーパーバイザーが機器を適切に割り当てることができ、問題がフリートの一部のみに影響を与える場合にサポートが正確に説明されます。
結果を操作に移す
プロジェクトの結果の乗務員配達時に、変更された画面、設定、またはフィールド アクションについて説明します。 必要に応じて、プリフライトとリカバリの手順を更新します。 組織の保持ポリシーに従って、以前に承認された構成と変更履歴を保持します。 今後の調査では、現在のバージョンだけでなく、どのバージョンが特定のキャンペーンをサポートし、いつ移行が行われたかを知る必要があるかもしれません。
たとえば、すべての乗組員が採用する前に、パイロット テストと改訂されたテンプレートを使用して、エクスポート フィールドを変更するコントローラの更新プログラムを含めることができます。 このテストがないと、ファイルがクライアントに届いた後にのみ問題が発生する可能性があります。 更新の制御により、ソフトウェアの変更が確認可能な運用上の決定に変わります。 土地調査のワークフローを維持しながら、改善の利点を維持し、証拠と責任を明確にします。
テスト中にデフォルトに戻った設定の簡単な記録を残してください。 その情報は、残りのユニットのロールアウト命令に属します。 そうしないと、パイロット オペレーターが問題を黙って修正する可能性がありますが、後で乗組員が予期せず遭遇し、同じ公称バージョンの下で一貫性のない構成のジョブを生成します。
さらに学ぶ 土地調査員全体で一意なポイント名を作成
実践チェックリスト
- バージョンを記録し、サポートされている構成バックアップを保持します。
- 修正、既知のポイント、ログとエクスポートをテストします。
- デバイスとバージョンごとに改訂されたワークフローを本番前に承認します。
