航空用の空間測位システム(FPGAを使用)

プロローグ



FPGAに関するどの記事でも、コメントは遅かれ早かれ、「彼らはクールなもので、簡単なプロジェクトをまとめて、LEDで点滅しているので、この便利な機能をどうすればよいかわからない」という考えを思い付きます。 誰かがFPGAでゲームを作成し、誰かが昔の標準プロセッサを移植しますが、これはすべてエンターテイメントと技術開発として主に位置付けられています。 実際、「家庭用、家族用」アプリケーションのFPGAテクノロジーは高価すぎて、明らかに冗長です。 今日は、FPGAが平和的で社会的に有用な目的のためだけにその調和のとれた使用を見つけるシステムについて話そうとします(株式投機、覗き見、または独自の種類の殺害のメカニズムはありません)。 ただし、後続のストーリーからわかるように、物語の大部分は、主題領域とシステム設計のレベルに当てられます。



簡単な背景は次のとおりです。1つの国内の大企業が、国内の1つの空港のナビゲーションシステムを作成するための命令を受け取りました(注文であるかどうかはわかりません。 原則として、彼らはそのようなシステムを作成した経験がありましたが、多くの技術に関する特別な知識が必要であったため、FPGAに基づいたデバイス開発の専門家が関与しました。 実際には、物語はそのような専門家の観点から行われ、他の多くの質問は無知のために失われる可能性があります...



問題の声明



このシステムの主な目的は、空港を通過するすべての地上物体を「監視」し、情報をまとめ、オペレーターの職場に表示し、場合によっては移動の安全性の制御を自動化する他のサービスです。 システムのさらなる開発には、空港の近くで[合法的に]飛行する物体への使用が含まれます。 この問題の標準的な解決策はADS-Bテクノロジーです。これは、各航空機が、振幅変調を使用する特別な形式で1090 MHzの周波数でさまざまなデータを空中に送信する特別なトランシーバー(トランスポンダー)を備えていることを前提としています。 航空機の座標もそのようなデータとして機能します。 最近、このようなトランスポンダーを空港サービスの地上車両に設置する傾向があります。 このようなシステムの欠点は、座標がオブジェクト自体(GPS / GLONASS /ガリレオまたはより古い技術に基づいて)によって決定され、ナビゲーションシステムのみが信頼できることです。 意図的なデータ破損の可能性を破棄したとしても、その精度はそれほど高くなく、地上車両にとって非常に重要です。 別の一般的に使用されるオプションは、すぐ近くのすべてのオブジェクトを照らすアクティブレーダーです。 この技術の欠点は、オブジェクトを識別できないことと、オブジェクトのサイズとレーダー上のマークのサイズ/輝度との関係です。





最近、いわゆるマルチラテレーション(MLAT)に基づいて、これら2つのアプローチの利点を組み合わせたハイブリッドテクノロジーが普及しています。 より詳細な説明については、すべての人を優れたアマチュアリソースに送り、一般的なアイデアを簡単に説明します。 現代の民間航空機はどれも(大型旅客機に当てはまり、小型航空機ではますます複雑になっています)、ADS-B Mode-S規格でオンエア(実際には要求に応じて、現在は重要ではありません)メッセージを送信しています。 これらのメッセージは単一の受信者が受信でき、その後は内部コンテンツに満足することができます。 MLATテクノロジーは、既知の座標を持つ複数の受信機を使用します。 この場合、各受信者からメッセージが受信された時刻の形式で追加情報があります。 飛行機でメッセージを送信する絶対時間は私たちにはわかりませんが、ベースが選択した受信機に対するメッセージの到着時間の差はわかっています。 空気上の電波が均一かつ直線的に伝播すると仮定すると(タスクの想定はほぼ間違いありません)、飛行機からベースまでの受信機までの距離の差が得られます。 一対のコンパスと定規(さらに良いことに、3Dアクセラレーターを備えたコンピューター)を装備したこれらのデータに基づいて、受信機に対する航空機の座標を確立し、標準座標に再計算するのは簡単です。



当初、MLATテクノロジーは、ADS-B Mode-Sモードをサポートしない古いタイプのトランスポンダーに使用されていました(Mode-Aの実装は著しく単純です)。 現在、これらはすべてADS-X(Extended ADS)と呼ばれる一般的なシステムに統合されています。 使用のために選ばれたのはこの種のシステムでした。 もちろん、世界(およびロシア)には、西側メーカーの同様の悪用されたシステムがありますが、この種の国内システムを作成したい(政治的駆動を含む)要望がありました。



3種類のシステムアーキテクチャを区別できます。

  1. 独自のクロックソースを持つ独立したレシーバー。
  2. 共通のクロックを持つレシーバー。
  3. アンテナからアナログ信号を受信する一般的な受信機。


最初のタイプのアーキテクチャは、地上の位置の観点から普遍的ですが、受信機のクロックを同期させるという深刻な問題があります。 最新のGPSモジュールは、100〜200 nsのタイムスタンプを形成する精度を備えています。 ご存知のように、電波は光の速度(300,000 km / s)で伝播します。 したがって、100 nsの時間測定誤差により、30 mの測位誤差の推定値が得られます。航空交通管制には十分ですが、地上車両には適していません。ここでは、少なくとも3〜5 mの精度が必要です。より高度な技術を使用して、受信機のクロックを同期します。

2番目と3番目のタイプのアーキテクチャはこの問題を解消しましたが、受信機(アンテナ)を情報処理センターに直接接続する必要があり、システムがカバーするエリアが制限されます。 さらに、ワイヤによる信号の配信に「追加」遅延の問題がありますが、既知の座標を持つトランスミッタに関してシステムをキャリブレーションすることで解決できます。 私たちの仕事は空港用のローカルシステムを構築することであり、インフラストラクチャが存在するため、顧客はシステムアーキテクチャの3番目のバージョンを選択しました。



レシーバー構造の設計



作成されたデバイスの直接のタスクは、受信アンテナからアナログ信号を取得し、その中のADS-Bフレームを検出し、異なるアンテナによる同じフレームの受信間の遅延を計算することです。 その後、各受信フレームについて収集された情報は、上位システムに送信されます。



ADS-B Mode-S形式のフレーム(英語のsquitterからはsquitterとも呼ばれます)は、前のプリアンブルを持つ56または112ビットのデータで構成されます。 持続時間8μsのプリアンブルには、互いにある程度の距離を移動する2組のパルスが含まれ、その後に各データビットが0 => 1または1 => 0の遷移によってエンコードされる情報部分が続きます。



この図を初めて見ると、コンパレータを設定し、可能な限り高い周波数(必要に応じて少なくとも1〜2 GHz)で結果をサンプリングし、フレームが開始する正確な瞬間を記録することができます。 残念ながら、このソリューションは[通常]動作しません。これには多くの理由があります。

  1. 信号がRF周波数(1090 MHz)に転送されるとき、またはその逆の場合、波形が大幅に歪むため、パルスは矩形から遠くなります。
  2. 異なるソースからの信号は異なるパワーを持ちます。つまり、コンパレータが動作するレベルを選択する際に問題が発生します。
  3. 近くで多数のトランスポンダーが動作している状況では、2つ(またはそれ以上)のスキッターが互いに重なり合う可能性が非常に高くなります。これは完全に正常な状況であり、受信者はそのような信号を受信できる場合があります。
  4. 空気への干渉と再反射、受信信号の形状の歪み。
  5. そして最後に、そのような解決策は、このスキッターがどのオブジェクトから送信されたかを識別するために、メッセージを直接受信およびデコードするタスクの括弧を省きます。


これに関連して、別のアプローチが使用されました。これにより、受信信号の形式による受信時間の差をより正確に確立することができます。 数学モデリングにより、この場合のサンプリング周波数は比較的低くなる可能性があることが示されました。この場合、12 MHzに選択されました。つまり、送信データ1ビットあたり12サンプルです(1ビットの持続時間は1μsです)。



昔、私は機器の開発に対する一般的なアプローチについての記事を書きまし 。 原則として、それ以降根本的に何も変わっていません。 最初に、前述のように、遅延を計算するというアイデアは数学モデルで実行され、肯定的な結果を受け取った後、デバイスの機能図が開発されました。





システムの要件の1つはスケーラビリティです。これは、デバイスのアーキテクチャを大幅に変更せずに受信チャネルの数を増やすことができることです。 1つのデバイスが最大32の受信チャネル(冗長性を備えた16)に対応できるように計画されました。

アンテナから受信した信号は、AM復調ユニットで低周波数に転送されます。この数は、受信チャネルの数に等しくなります。 次に、データは、比較的低いサンプリング周波数(数十MHz)のマルチチャネルADCを使用してデジタル化されます。 このようなADCには、多くのアナログデータ入力と高速シリアルまたはシリアルパラレルデジタルインターフェイスがあり、すべてのチャネルからの情報がフレームにパックされて送信されます。 これにより、PCBトレースと、ADCとのインターフェースを実装するマイクロ回路の入力/出力要素のリソースを大幅に節約できます。



情報処理装置として、FPGAを使用するのが最も便利です(この場合)。これにより、ADCとのインターフェース、高速内部メモリのデータバッファリング、DSP処理、組み込みプロセッサに実装された複雑な制御アルゴリズムといった一連の問題を即座に解決できます。 実際、ハードウェアプラットフォームの選択の問題は簡単ではありません。 一般的な見積もりによると、良いDSPですべての処理を行う時間がある可能性がありますが、リスクを冒したくはありませんでした。 さらに、いずれにしても、ADCとのインターフェースをサポートする必要があります。つまり、FPGAをインストールすることを意味します。



受信した信号はバッファリングされ、ADS-Bフレーム受信ユニットに送信されます。 ブロックの数は、受信チャネルの数に対応しています。 それらでは、プリアンブルが検出され、データが抽出され、それらのチェックサムがチェックされます。 重ね合わせたフレームの1つが著しく大きい場合には、フレームを受信するための多くの手段も講じられています。 タイムスタンプ付きの受信フレームは、さらに処理するために送信されます。



同時に、別の手順が実行されます-受信信号の形式に応じた正確な遅延(1サンプリング間隔未満の精度)の計算。 すべての受信フレームについて、バッファ内での位置が設定され、その後、1つのサンプリング間隔内で結合された処理のために(プレゼンターによって選択されたチャネルに対して)ペアで送信されます。 時間領域とスペクトル領域の両方で集中的なデジタル処理を行った後、出力はサンプリング周波数の数分の一の数、つまりフレームが互いに時間的にどれだけ離れているかを示します。 たとえば、次の図は、サンプリング間隔の半分の間隔で配置された信号の2つの実装を示しています(便宜上、時間的に組み合わされ、マークはサンプリングされた瞬間を示します)。 そのような信号を入力に適用するときに正確な遅延を計算するための単位は、0.5(または、どちらの信号が先に来たかに応じて-0.5)の値を与えます。 サンプリング間隔の半分。





この手順の最後で、各フレームの最終情報、フレームに含まれるデータと各チャネルの受信遅延を準備できます。 フレーム処理を管理するための一般的な手順の複雑さは、異なる(異なる)チャネルが同時に(近い)異なるオブジェクトからフレームを受信できるという事実にあります-トランスミッターがより強力で、アンテナに対して誰が配置されるかによって異なります。 最終的に、収集された情報は、オブジェクトの空間位置のさらなる処理と計算のために、優れたシステムに送信されます。



ご覧のとおり、結果のテキストには1行のコードは含まれていません。 実装の微妙な違いを理解することは、長く困難な問題です。 私の意見では、コードを提供することは完全に無意味な運動です。なぜなら、どの作品も見栄えが悪く、とにかく大量のボリュームを読むことはないからです。 したがって、この記事では、主要なアイデアと一般的な構造の説明に焦点を当てました。 将来、もう1つのパートが作成され、個々の要素の実装の詳細が明らかになるかもしれません。 さて、今は終了する時間です...



エピローグとして



最初の開発段階の一部として、4つのチャネルのみを含む上記のシステムのプロトタイプが、ビンにある無線コンポーネントから作成されました 。 「テーブル上」でテストする場合、強い信号レベルでの遅延測定の誤差は2 ns未満で、S / N比の低下とともに徐々に減少しました。 実際の条件でテストを実施した場合、エラーは約10 nsであり、同僚によると、これは購入した同様のシステムのエラーの約2〜3倍です。 開発者がパンと水の兵舎に住んでいたという事実によるゼロから開発された製品の推定コストは、競合他社の連続サンプルの領域にあったことを考えると、これはすべてプロジェクトの成功のための明るい見通しを刺激しました。



残念なことに、昨年秋に悲しい出来事が発生しました-民間旅客機ヴヌーコボ空港でand落しました。 発生した要因の1つは、上記のような最新のナビゲーションシステムが空港にないことでした。 このイベントはプロジェクトに逆説的な結果をもたらしました-上記のどこかで、独自のシステムの作成が長すぎて不当であると判断されたため、既製のレシーバー(およびシステムの他のコンポーネントを購入することにしました-私は質問を所有していません)西洋のパートナー、および現在の開発は終了しました。



All Articles