質問:
飛行中のソフトウェアの変更にプログラミング言語の変更が含まれたことはありますか?
DrSheldon
2018-10-06 01:47:10 UTC
view on stackexchange narkive permalink

コンピュータソフトウェアは、間違いなく、ミッションがすでに進行中の場合に変更できる無人宇宙船の唯一のコンポーネントです。現在、多くの宇宙船は、無線通信を通じて新しいプログラムを受け入れるように設計されています。ミッション開始後のソフトウェアアップデートの例は数多くあります。

宇宙で最も初期のコンピュータソフトウェアはアセンブリ言語で書かれていましたが、開発者はすぐに次のような高級言語に変更しました。 Fortran、FORTH、およびC。これは、ソフトウェアがリリース前に1つのプログラミング言語で開発されていても、ミッションが開始されると別の言語で再開発される可能性があることを意味します。

そのようなプログラミングがあります。言語の変更が発生しましたか?

  • 宇宙船で実行されているマシンコードではなく、開発者が使用した言語を指します。
  • ミッションは有人または無人の場合があります。
  • あらゆる種類のソフトウェア(フライト制御、データ収集、信号エンコードなど)。
  • この質問で行ったコメントに触発されました。
多くの経験豊富なソフトウェア開発者は、それを避けようとします。使用するコンパイラのバージョンを変更することもできます。
私は、それが良い習慣ではないというUweとDarkdustに完全に同意します。それにもかかわらず、これは例を文書化するための質問になります。
三 答え:
DarkDust
2018-10-06 15:00:11 UTC
view on stackexchange narkive permalink

これが行われたかどうかわからないため、これは回答というよりもコメントですが、ミッション開始後にミッションクリティカルソフトウェアが別のプログラミング言語に切り替わったことは本当に疑わしいです(リフトオフ)。

プログラミング言語の変更は大きなリスクです。すべての言語には、管理する必要のある独自の長所、短所、および癖があります。

たとえば、Cプログラミング言語では、開発者が簡単に足を踏み入れることができるいくつかの構成が可能です(例:overwrite /破損したメモリ)したがって、 NASAにはプロジェクトでCを使用する方法に関するガイドがあります。また、 ESAにもあります実際の ESA C / C ++への代替リンクESAサイトのものがロードされなかったため、コーディング標準)。プロジェクトによっては、さらに厳しいルールが適用される場合があります(動的メモリ割り当てを使用しないなど)。

これらのルールは静的アナライザーやその他のツールによって適用されることが多いため、言語は実際にはエコシステムの一部です。最後になりましたが、ユニットテストと統合テストが必要です。言語を変更する場合は、プログラムのソースファイルだけでなく、エコシステム全体を変更する必要があります。

(もちろん、実際のプロジェクト管理もありますが、これはほぼ同じだと思います。 " 「言語を切り替えるだけです。)

正しいソフトウェアの開発は、非常に面倒で時間のかかる作業になる可能性があります。 ミッションクリティカルなプロジェクトの開発に数か月または数年を費やし、言語を切り替えることにした場合は、基本的に最初から始める必要があります(元の実装の一部を移植/再利用できる場合でも)。プログラミング言語を切り替えるときは、通常、切り替えたいと思います。新しい言語では、問題を解決するコーディングパターンを採用できるためです(たとえば、特定の部分の実装を簡単にしたり、安全に切り替えたりできます)。しかし、これはつまり、元のプロジェクトの設計を少なくとも部分的に変更して、これらの機能を利用することで、さらに多くのリスクをもたらす可能性があることを意味します。

正確性(または「正確に予測できる」ため)動作」)は非常に重要であり、新しい未知の問題を導入するよりも、既知の問題を処理する方が適切です。コンパイラ(または使用するコンパイラのバージョン)を変更するだけでも、変更が必要です。慎重に評価されました。コンパイラにはバグがあるか、コードの動作方法が変更されています。Cを例として再び使用すると、有名な i = i ++ + i ++; 未定義の動作があります。 / code>ここで、式の結果は標準で明示的に定義されておらず、すべてのコンパイラーが必要なことを実行できます(この場合、デーモンを鼻から飛ばすことができるという有名なジョークです)。コンパイラのバージョンを変更すると、そのようなコードは以前の動作を変更する可能性があります。

要点は、プログラミング言語の変更は非常にコストのかかる(時間とお金の)作業であり、多くのリスクをもたらします。そのため、このような切り替えのメリットは、関連するコストとリスクを上回っている必要があります。地上で使用されるソフトウェア(愚かな例:Cで記述された古いX11 UNIXソフトウェアからJavaへの切り替え)の場合を想像できますが、フライトハードウェアで使用されるソフトウェアでこれが発生することを想像するのは困難です。

Bob Werner
2018-10-06 22:04:30 UTC
view on stackexchange narkive permalink

JPLのDeepSpace 1ミッション(1998-2001)の飛行ソフトウェアはCで作成されました。2日間の実験(リモートエージェント実験-RAX)がLispで実装されました。 LispインタープリターとRAXコードは宇宙船にアップリンクされ、Cフライトソフトウェア上で2日間実行され、実験の終了後に破棄されました。 https://www.cliki.net/DeepSpace1および https://ti.arc.nasa.gov/m/pub-archive/176h/0176%20(Havelund)を参照してください。 pdf

これは[Greenspunの10番目のルール](https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule)を証明しています:「十分に複雑なCまたはFortranプログラムには、アドホックで非公式に指定されたバグの多い、遅い実装が含まれていますCommonLispの半分。」
Dennis Ray Wingo
2018-10-07 01:44:53 UTC
view on stackexchange narkive permalink

ここにいる全員に同意する必要があります。ただし、場合によってはこれが不可能です。たとえば、私たちのISEE-3宇宙船にはプロセッサがありませんでした。元の開発環境が何であるかはわかりませんでした。また、宇宙船を開発およびコマンドするための古い地上ソフトウェアはもう存在しませんでした。

私たちが持っていたのは、コマンド文字列とかなりよく文書化されたプロセスだけでした。その情報が消えて、30〜35年後、元の人の誰もそれを覚えていなかったので、宇宙船で飛ばされたような正しいコマンドコードがあるかどうかさえ知りませんでした。

あなたはいくつかに尋ねなければならないでしょう私たちの人のしかし私たちは2つのアプローチを見ました。 1つ目は、labviewのビット操作システムを使用することでした。高度なプログラミング言語を使用して、ビットコードを直接実装し、宇宙船にアップロードしました。したがって、私たちの例では、すべてを最初から再構築する必要があり、元のプログラミング環境を再開発する方法はまったくありませんでした。

OPの定義を厳密に満たしているわけではありませんが、この情報は非常に貴重です。私があなたを正しく理解していれば、ソフトウェアはありませんでした-ハードウェアレベルのロジックのみです。オリジナルが失われたため、地上管制ソフトウェアは完全に再設計されました。 ISEE 3の再起動作業は、明らかにサイトでさらに多くの質問と回答に値します。
Bitchaser、あなたはそこで絶対に正しいです。コマンドコードが記載されたシートを42日で一から作成するだけで、コマンドシステムを完全に再現しました。その後30日以内に、テレメトリ処理システムが稼働しました。プエルトリコの送信機、ドイツの受信機、カリフォルニアの地上ソフトウェア処理を使用して、グローバルな地上システムをすべてリアルタイムで実行することができました。それは私たちのチームによるひどい素晴らしい努力でした。
素晴らしい答えです!未登録のDennisWingo [ここ](https://space.stackexchange.com/a/15337/12102)でもある場合は、IDをマージできます。 [2つのアカウント/ユーザーを1つのリンク/マージ/結合/関連付けるにはどうすればよいですか?]の回答を参照してください。 (匿名/未登録/ Cookie、またはOpenID /登録済み)](https://meta.stackexchange.com/q/18232/303080)または[マージアカウント](https://meta.stackexchange.com)に直接アクセスしてください/ help / mergeing-accounts)宣伝文句。
ISEE-3の経験から私が学んだことの1つは、非常に有能な宇宙船は複雑である必要がないということです。内側の太陽系に宇宙船の星座が欲しかったとしましょう。良好な熱バランスがあれば、50年続く可能性があります。 10年で時代遅れになり、30〜40年で再現するのがほぼ不可能に近いソフトウェアシステムと開発環境を備えた鳥が欲しいのはなぜですか。したがって、長寿命の宇宙船は非常に単純なシステムである必要があります。 JPLは非常に古いため、ボイジャーをプログラムする人を見つけるのに多くの問題を抱えていました。


このQ&Aは英語から自動的に翻訳されました。オリジナルのコンテンツはstackexchangeで入手できます。これは、配布されているcc by-sa 4.0ライセンスに感謝します。
Loading...