🎀 😇 💪🏾 フライトシミュレータの構築方法：貴重な体験 📴 🧖 ☮️

みなさんこんにちは！

1年ほど前に、フライトシミュレータとプロのフライトシミュレータの間にあるデバイスを構築するプロセスに参加しました。これは初めての経験ではありませんでした-2009年にすでにこのような問題を解決していたため、非常に野心的な夢を実現し始め、可能なすべての熊手を踏まないようにしました。ここでは、「最初のパンケーキ」の背景と、2番目のパンケーキにどのように影響したかを説明します。興味深い場合は、2番目のシミュレーターについて詳しく説明します。

DIYでの投稿。これまで誰も航空機やプロのシミュレーターを作成した経験がなかったからです。さらに、後で判明したように、低予算のフライトシミュレータの構築へのアプローチは、プロの分野のアプローチとは根本的に異なります。一般に、最初と2番目のシミュレーターは、技術的なバックグラウンドを持つアマチュアによって作成されました。

注意、航空愛好家やエンジニアの間で神経質なチックを引き起こす多くの写真。

だから...

背景

2009年7月、私の知り合いの1人が電話をかけて、モスクワのビジネスマンが彼自身のためにボーイング737-800シミュレーターを作成しており、彼は成功していないと言いました、そして彼らは私がプロジェクトに参加したいと言います。やりたかった、私はこのビジネスマンに来て、st然とし、すぐに仕事に取り掛かりました。

その結果、シミュレータは、おそらく、可能な限り高価で、最大数のレーキで構築されたと言わなければなりません。これは、低コストのフライトシミュレーターとそのコンポーネントの非常に未発達な市場に対する非常に広範な経験がないためであり、最も重要なことは、計画していなかったことです。それは純粋な実験室の科学であり、ひざまずき、即興でした。私たちは非常に限られた時間でした。

その結果、少なくとも、私たちの仕掛けが生き返り、MAXに登場し、誰もがそれに乗り始めました。

ボーイングの完成後すぐに、私は会社を辞め、2012年の夏に会社に戻りました。その素晴らしいビジネスマンが2番目のシミュレータを構築することを決めたので、私はコールバックされました。今回はエアバスA320になりました。

今回は、より積極的にこの問題に取り組むことにしました。計画のために時間とエネルギーを費やすという共同の決定が下されました。さらに、書類と写真が最初に表示され、その後初めて多数のコンポーネントの購入が行われると主張しました。

もちろん、主なタスクの1つは総所有コストを削減することでした。そのために、ボーイングで踏んだレーキを分析して考える必要がありました。

すくい

まず、レーキを分析することにしました。最終的に、設計および建設段階でのこれらの同じレーキは、予期しないシミュレーターのダウンタイムにつながり、その結果、会社にとって非常に顕著な財政的およびイメージの損失をもたらしました。 2回戦でそれらを焼かないことが必要でした。

ITインフラストラクチャの欠如

実際、ボーイングが生まれたとき、「すべてが自然に機能する」と想定されていました。サプライヤーは3社のみでした。すべての電子機器を備えたキャビン、モバイルプラットフォーム、ビデオシステムです。ソフトウェア（誰かがこれに何かを言う場合はProject Magenta）はキャビンのサプライヤーによって提供されたため、インフラストラクチャは「上から私たちに与えられた」。操作が示したように、コンピューター上でコンポーネントを少なくとも正しく分散させる必要がありましたが、これも行われませんでした。

将来的には、絶え間ない変化（これについては別途説明します）により、システムはそれ自体の生活を癒しました。何らかの障害または障害が発生するたびに、ログファイルが特定のサイズに達した場合にそのうちの1つが機能しなくなったことを最終的に確認するために、多くのコンポーネントからノードを解明する必要がありました。

定期的なバックアップ、コンポーネントのバージョン管理に関する話はありませんでした。

パフォーマンスに関しては、新しいシナリオがインストールされると、シミュレーターのパフォーマンスが大幅に低下したため、MSFSをX-Planeに置き換える必要がありました。なぜこのような選挙が行われたのか-私は知りません、私はそれに参加しませんでしたが、事実は残っています。

モノリシックMSFSをスケーラブルなX-Planeに置き換えた後でも、グラフィックパフォーマンスは計算されず、その結果、これらのサーバーのハードウェアは2回アップグレードされました。

この災害から、シミュレーター全体のアーキテクチャを描画し、どのコンポーネントがどのコンピューターで動作するかをペイントし、可能な拡張機能を提供し、ハードウェアパフォーマンスの要件をペイントし、ネットワーク負荷を評価し、さらなる開発のためにわずかなマージンを取るだけでよいと結論付けました。最終的に、シミュレータの目的は、常に新しい技術を開発することではなく、顧客の顔に微笑みかけることです。

継続的な変更とマルチベンダー

ああ、それはただの休日です。

MSFSはシミュレーターとして使用されましたが、すべてが多少安定していました。スクリプトを曲線に入れて、すぐにシミュレーターのダンプを取得してください。シンプルでフリルなし。

X-Planeに切り替えて、4つのコピーをインストールしてシステムをスケーリングすると（1つはダイナミクスを考慮し、それぞれが独自のプロジェクターに独自の画像を描画します）、同じスクリプトを4つのコピーにエラーなしで広げることがはるかに困難であることがわかりました。特に、そのうちの1つがWindowsで動作し、3つがLinuxで動作することを考慮すると。エラーと問題が始まり、プロジェクターの1つでスクリプトがクラッシュしました（最も不快なもの）。ある時点で、スクリプトの制御が完全に失われ、すべてのインストールを任意のインストールと完全に同期させるという強い意思決定が行われました。これにより、ビジュアルの問題をほぼ完全に取り除くことができましたが、問題の根本は残りました。4つの異なるシミュレーターのインストールがあり、そのうち3つが1つの画面に画像を形成します。

時々、アイロン（コントローラー）が故障しました。同じものを調整して購入する代わりに、他のメーカーのコントローラーを購入しました。その結果、3年後、ボーイングは最大5社のベンダーを備え、各ベンダーは独自の特性を持つ独自のインターフェイスソフトウェアを備えています。もちろん、これは一緒に機能しますが、いくつかの未知の問題の場合、診断は生きた地獄に変わります。

繰り返しになりますが、新しいコントローラーはボード上の新しいケーブルであり、ある時点で、どのような種類のワイヤーで、どこに行き、何のために使用されているのかがわからなくなってきました。シミュレータを数日間停止し、ほぼ完全に再配線する必要がありました。

このレーキから、何世紀もの間ではなく、少なくとも数年間はシミュレータを構築する必要があると結論付けました。可能な開発の方向を事前に評価し、修正し、これらの方向に基づいてシステムを構築する必要があります。ある時点で何かを別の方向に改善したい場合は、運用上の信頼性を優先して何かを放棄する必要があります。

運営

シミュレーターの操作はまったく似ていませんでした。

操作手順はなく、変更、バックアップ計画、定期的なメンテナンスに制限はありませんでした。多くのことはありませんでした。

異なる手が同じシミュレーターに登り、設定を変更し、素早く確認して去りました。翌朝、シミュレーターは起動しませんでした。

プロジェクターのランプは最も都合の悪い瞬間に燃え尽き、予備のランプはヴィドノエのどこかの店にあり、金曜日の夜に私たちの宅配便がモスクワを駆け抜けてモスクワで最後のランプを買いました（ジョークを除く）。

移動プラットフォームの駆動装置のシリンダー内のオイルは静かに流出し、床に水たまりが形成されたときにのみ流れることがわかりました。そして、もちろん、このブランドのオイルを購入する方法はありませんでした。

要約：シミュレーターは作動しましたが、作動しませんでした。それは壊れます-私たちはそれを修正します。それは壊れません-私たちは飛ぶ。

新しいプロジェクトでは、運用プロセスを予測して説明することが非常に重要でした：必要なスペアパーツ、診断を行う頻度、これが壊れた場合、インストールする更新、方法、テスト方法、バックアップの頻度など今後、このアプローチが大いに役立ったと言えます。少なくとも定期的なバックアップに同意し、それが恐ろしいときに変更を加えない場合、システムの寿命はずっと長くなります。

電気的問題

このような技術的に複雑なデバイスでは、電気的な問題が多くのスペースを占めることはないようです。

やばい！私が最初にボーイングに参加したとき、コントローラーの自発的なシャットダウンがありましたが、長い間診断できませんでした。ある時点で、USBコントローラーの「グランド」と、このコネクターが差し込まれたコンピューターとの間の電位差を測定しようと思いました。コンピューターのマザーボード上のコントローラーとUSBハブの両方が多すぎます。何らかの未知の方法で、サプライヤーがタクシーとラックの「土地」をコンピューターで解くことができました。彼らは、「アース」とニュートラルの正しい配線で、一点からエネルギーを供給しました-ダンプの数は急激に減少しました。

また、フェーズの1つをノックアウトし、検死により負荷分散が行われていないことが示されました。その後、シミュレータのすべてのコンポーネントの電源回路を分析し、それをやり直しました。問題はなくなりました。

結論は、負荷の計算とバランス、無停電電源装置間の分配、そしてもちろん短絡と感電の両方からの保護を備えた電源回路の必要性でした。まず、紙の上で、「この投稿が外れたらどうなるか」をチェックし、電線の断面積、機械の定格などの電気的なものを計算します。そして、回路が変更されていない場合にのみ-コンポーネントの購入と電気パネルの組み立て。

USB

コックピットにある電球とボタンの数を正確に数えることはありませんでしたが、入出力コントローラーの数は1.5ダースを超えています。そして、それぞれがUSBで終了し、コンピューターでオンになります。

共通の「グラウンド」の欠如に関する問題についてはすでに書きましたが、問題を解決しましたが、ケーブルの3つの束が3つの異なるコンピューターに接続されても問題はありません。

いくつかの異なるUSB延長コードを試し、異なるメーカーのハブをインストールし、すべてのデバイスを1台のコンピューターに集めようとしました。一般に、多くのことを試しましたが、USBデバイスの「脱落」の問題は、まれではありますがこの日。

明らかな結論は、USBの使用の拒否でしたが、私が言ったように、私たちの賢明な時代には、低予算のシミュレーター（つまり、個人で最大5万ドルの費用がかかるシミュレーター）の市場は非常に未発達であり、USBが支配しています。さらに、コンポーネントのサプライヤは、キャビンが移動できることを心に留めていません-そのようなシミュレータのほとんどすべて（ユニットを除く）は動かないのです。可動プラットフォーム上にシミュレータを構築したため、長いケーブルと振動の問題が必要になりました。

そうだとすれば、彼からは何も得られません。つまり、ケーブルをできるだけ短くし、USBを延長ケーブルに10メートルドラッグするのではなく、コンピューターを搭載する必要があります。今後の見通し：これは、ディスクレスコンピューターが搭載されることを意味しました。これは別の優れたタスクであり、次のいずれかの部分で説明します。

機械的な問題

機動性+キャブ内の人々=メカニックのさまざまな問題。

ねじ込み式接続は振動から解き放たれ、セルフタッピングねじが脱落し、時間の経過とともにプラスチックが崩れ始めます。

私たちのクライアントはプロのパイロットではありませんが、普通の人々であり、時には航空にあまり熱心ではありません。彼らは何ができて何ができないかを知りません。

人生の最盛期の普通の普通の人は、知らないうちに、実際の航空機のデバイスからハンドルを引きちぎることができ、それに気付くことさえできません。ただし、「アダルト」トレーニングセンターの仲間のエンジニアの話によると、実際のパイロットは同じことをすることがあります。

新しいシミュレータでは、95％の割合でこのレーキを獲得しました。すべてのケーブルを固定する必要があり、すべてのスレッド接続がロックされています。ネジなし。カプラー、カプラー、カプラー。残りの5パーセントは依然としてお客様です。悲しいかな、ここで-愛情がありますが、永続的な言葉で。これは、組織的な結論に言及しています。

結論

計画、設計、作成、思考、分析。

「シートから」、おそらくあなたは数晩でスクーターを作ることができますが、肉挽き器はなくなっています。フライトシミュレーター-さらには。

過去の失敗の分析は、重要ではないにしても、重要な役割を果たしました。「学習した教訓」の体系化のおかげで、最初に考え、描くこと、次に行うことの必要性が明らかになりました。

もちろん、古いレーキの一部を避けて、新しいレーキを見つけましたが、6か月の経験から、新しいシミュレータの操作上の信頼性がはるかに高いことがわかりました。ダウンタイム、障害、および障害が大幅に減少します。より多くの幸せな顧客、そしてこれがまさに目標です。

次の投稿では、A320を構築するプロセスを詳細に説明します。

更新する

ボーイングの建物から写真を見つけたので、投稿します。

ヘルム付きキャビンのベース。当初、コンピューターの電源が使用されていましたが、これは大きな悪であることが判明しました。今MeanWell

イタリアからモバイルプラットフォームが届きました。ほとんどのモバイルプラットフォームの質量は約800 kgで、制御キャビネットはさらに800 kgです。

ローダーを使用する機会がありました（Airbasでは-もはや場所はありませんでした）。左側には、サーバーラックの最初のバージョンがあります。右側には、投影スクリーンを引く金属構造があります。

コックピットアセンブリ。 MIP（メイン計器盤）はほぼ組み立てられています。

ベースとフレームのコックピット。

窓から開いた天井パネルを眺めます。その後、選択したケーブル配線方法が間違っていることが明らかになりました。

カナダの専門家が、FSUIPCとコントローラーの間のレイヤーであるインターフェイスソフトウェアを構成します。各ボタントグルスイッチランプインジケーターは、FSUIPC変数に「付加」されます。この構成を失った後は楽しかったです。

ギャングウェイが乗るベースのアセンブリの開始。

キャビン、プラットフォーム、プラットフォーム制御キャビネット。制御キャビネットの「心臓部」はシーメンスPLCです。ドライバー-バウムラー。エンジンとドライバーは別の記事に値します。たとえば、内部のドライバーは、モーターの負荷に応じてモーター巻線の温度を考慮します。さらに、巻線にはいくつかの温度センサーがあり、もちろんコントローラーにも接続されています。ただし、計算された温度が許容限度を超えた場合、アラームを発行してすべてのモビリティを停止することはできません。また、計算はエンジン固有のパラメーターに基づいており、工場でのテスト中に削除されます。計算された温度でこの困難に遭遇したとき、私たちは植物と接触しなければなりませんでした。

4年前のプラットフォーム制御キャビネットとサーバーを備えたラック。

そして今-rrraz、そして私たちはローダーでプラットフォームにタクシーを持ち上げました。

OREブロック（エンジンコントロールスティック、英語のスロットルクアドラント）。実際、プロジェクトに登場した理由。それはまったく機能しませんでした。このブロックは、ドイツの職人によるボーイング737-300を搭載した実際のブロックでできています。残念なことに、職人は近藤ボーイングのメカニックのほとんどを捨てて、ばかげた牽引力に置き換え、一部の場所では（ジョークなしで）ライターキャップを付けました。そして、ネジ留め式端子台ははんだを充填することにしました。使用されるコントローラー-フィジェット。このユニットには合計で6個あります。