重要な生死に関わるシステムでソフトウェアはどのようにテストされますか？

飛行機は、たとえばウェブサイトとは対照的に、特定のシステムの障害が完全に受け入れられないシステムです。飛行監視などのエラーにより、自動操縦装置が誤作動して潜水する可能性があるためです。明らかに、これは、ボーイングとエアバスの優秀なエンジニアがオートパイロットをチェックして、ダイビングが完全に受け入れられ安全な操縦であると突然判断しないことを確認しているために起こりません。または、コンピューターがクラッシュし、新しいフライバイワイヤー航空機のパイロットが飛行機を実際に飛行できなくなった可能性があります。もちろん、（ソフトウェアと航空機の両方の）クラッシュを防ぐために、これらのシステムにはさまざまな安全手順と冗長性が組み込まれています。

ただし、一方で、ソフトウェアが完璧ではないことは明らかです。オープンソースとクローズドソースの両方のソフトウェアは定期的にクラッシュし、最も単純な「Hello World」プログラムだけが失敗しません。航空、医療、その他の生死の業界でソフトウェアシステムを設計するエンジニアは、ソフトウェアが失敗しないようにテストできます（失敗した場合、少なくとも正常に失敗します）。

_{「みんな、ボーイング/エアバス/（他の会社）で働いていますが、そうではありません！次のフライト/病院訪問で楽しんでください。」}

私は工業用制御で多くの仕事をしました。航空宇宙のような輝かしい産業である必要はありません。ほぼすべての産業機械には、重傷または死亡を引き起こすのに十分な潜在的エネルギーがあります。人がけがをしたとき、私は周りにいました。ほとんどの時間をオフィスのデスクで過ごす場合、ほとんどの工場の仕事がどれほど危険であるかに驚くでしょう（そして確かに最近までそうでした）。現在、機械を保護するより良い方法があります。実際の動作は次のとおりです（ただし、管轄区域によって異なります）。

米国にはOSHA規格があり、EUには同様の（通常はより厳しい）ガイドラインがあります。これらは通常、リスクの分析を行うことを要求することから始まります。つまり、すべてのハザードのリストを作成してから、それらのハザードを分類し、人がリスクにさらされる頻度、リスクを回避するのがどれだけ簡単か（速度に依存するなど）、および結果の重大度（カット、切断、死亡など）です。

分析の多くは、ハザードの保護に関係しています。マシンの周りに大きなケージを置いて締め付ける場合、マシンのコンポーネントがガードを破れない場合、マシンは安全であると見なされます。入るためのツールが必要な場合、それはメンテナンス作業と見なされ、メンテナンス担当者はマシンで安全に作業する方法のトレーニングを受けることになっています。しかし、実際には、ほとんどの機械はオペレータと定期的にやり取りする必要があるため、防護ドアやライトカーテンなどにアクセスドアを設置する必要があります。これらのドアとライトカーテンは監視する必要があります。 「制御の信頼できる」方法で遮断する必要があります。

その分析に基づいて、リスクはさまざまなカテゴリに分類されます。一般的な分類尺度は、カテゴリ1からカテゴリ4（EN 954-1標準に基づく）です。これらのカテゴリに基づいて、一定レベルの機械の保護と安全性を法的に提供する必要があります。

たとえば、カテゴリ4では以下が必要です。

これらの各部品に単一の障害が発生しても、安全機能が失われることはありません。

単一の障害は、安全機能への次の要求で、またはその前に検出されます。これが不可能な場合、障害の蓄積によって安全機能が失われることはありません。

これを実際に達成するのは難しい場合がありますが、カテゴリ4に認定された標準コンポーネントが利用できるため、より簡単になります。たとえば、これらのシステムの一般的なコンポーネントの1つはセーフティリレーです。これらは単なる機械式リレーではありません。

• デュアル冗長入力チャンネルを監視するように設計されているため、障害状態（ガードドアが開いているなど）を検出するセンサーがある場合、通常、冗長回路を備えた2つの接点があります。リレーは両方のチャネルを監視し、いずれかが開いた場合、アクチュエータへの電力をドロップアウトしますが、両方が同時にドロップアウトしない場合、障害状態になり、修理されるまでマシンを再起動できません。
• リレーはまた、これらのラインで電気パルスを使用し、これらの信号を使用して、交差または短絡したワイヤを監視するため、配線障害を検出できます。
• 出力側では、出力コイルを駆動するためにデュアル回路のセットを使用するため、一方が「オン」状態にフォールトした場合、もう一方は出力の通電を妨げます。さらに、これらは監視されており、障害が検出された場合、動作を妨げます。コイル自体は、実際にはデュアルフォースガイドリレーであり、出力上の冗長物理リレーを意味します。さらに、各単一リレーの接点が物理的にリンクされていることを保証します。これらも監視されます。
• また、制御している負荷からの通常閉接点を監視するための入力も含まれています。出力をオフにする場合は、通常は閉じた接点がオンになっていることを確認する必要があります。つまり、再びオン状態に動作する前に、モーターコンタクタをオフにしたかどうかを確認する必要があります。

おわかりのように、これらは複雑なデバイスです。一般的なコストは、各安全リレーで200〜600ドルの範囲です。明らかにこれらのデバイスにはソフトウェアがあります。安全リレーの認定を取得するには、通常、次のような設計に従う必要があります。

• 通常、異なる設計に基づいて異なるベンダーから供給される2つの冗長プロセッサ。
• 各プロセッサで実行されるコードは、隔離された条件で作業する2つのチームが開発する必要があります。これにより、単一のソフトウェアバグが単一障害点になるのを防ぎます。
• 両方のプロセッサの出力が一致するか、安全リレーの障害が発生する必要があります。

安全性評価済みのコンポーネントを使用して、マシンの安全システムを設計したら、プロのエンジニアが設計をレビューし、スタンプを押さなければなりません。次に、マシンを構築します。その後、P.Eng。設計どおりに構築されていることを確認しながら、マシンの構造を確認します。彼らはそれを文書化し、それに対していくつかのテストを実行して、期待どおりに機能することを確認します。これは事前開始審査（PSR）と呼ばれ、すべての管轄区域で行われるわけではありません。PSRが合格すると、オペレーターにマシンを実行させることができます。

近年、安全システムにいくつかの革命がありました。しばらくの間、ネットワーク上で安全データを送信することを信頼する人はいなかったため、DeviceNETやEtherCATなどの「分散I / Oシステム」と呼ばれるものは、システムの安全部分で許可されていませんでした。ただし、最近のプロトコルでは、これらの産業用ネットワーク上で安全装置を実行できます。プロトコルは、タイムスタンプ付きメッセージと、接続の両端での二重冗長処理を利用します。

安全リレーはドードー鳥のようにゆっくりと進んでおり、機能ブロック図言語で安全ロジックを構築する方法のような、より複雑な安全PLCに置き換えられています。繰り返しますが、これらの安全PLCは冗長なすべてを使用します。プログラムが承認されると、マシンが稼働する前に、P.Eng。プログラムにスタンプが押され、プログラム/ PLCがパスワードでロックされます。また、プログラムのハッシュを受け取り、そのハッシュはドキュメントに記録されます（P.Eng。が実際に刻印しているものです）。

これで、安全システムを設計したら、マシン自体を制御するために記述するロジックは非常に簡単になります。プログラマは頻繁にマシンをクラッシュさせ、数千ドルの損害を与えますが、少なくとも誰も負傷することはありません。

ランダムな機能テストではなく、正式な検証への重大な動きがあります。

NASAや一部の防衛組織などの政府機関は、これらのテクノロジーにますます投資しています。

彼らはまだ平均的なプログラマーにとってはPITAですが、多くの場合、重要なシステムをテストするのにより効果的です。

また、マルチスレッドコードの検証など、学界からより多くのテクニックを試してみる傾向があります。

それはソフトウェアが何であるかに依存します。たとえば、飛行機では通常、重要なシステムに対して二重冗長処理が行われます。極端な場合、2つの異なるハードウェア設計が使用され、2つの独立して開発されたs / wがあり、それぞれが実行されます。彼らは両方を計算し、相互に確認します。これは絶対確実ではなく、非常に高価です。

航空機システムのテストのようなことになると、一連のテストが行​​われます-飛行関連システムのテストには数か月かかります。変更を行う場合、一連の再テストをすべて実行する必要があります。これは通常、シミュレータで行われます。シミュレータは、実際の航空機の部品（コックピットなど）でいっぱいになっており、シミュレートされたエンジンなどを備えています。ご想像のとおり、これも恐ろしいほど高価です。変更は正式なテストプログラムに対して評価され、テスト飛行中の実際の航空機で実行されます。「妨害された機能」テストのようなものが実行される方法に沿って、これは変更されたアイテムが通常のことをすることを許可され、有害な影響がないことを確認するためにすべてがチェック/テストされる場所です。これには多額の費用がかかり、数週間かかる場合があります。

フライトシステムの非常に簡単な変更が必要な1つの例を知っています。非常に簡単なので、どれほど些細なことにat然とします。ただし、この再テストには3か月以上かかり、100万ドルのような費用がかかります。

医療を始めると、テストだけでなく開発プロセスと文書化に関連する一連の規制上のハードルがあります。

これらのすべてのフィールドは、WebサイトのPHPコードを少し打ち消す場所からの大きな一歩です。時間がかかり、骨が折れ、困難で、退屈で、退屈で、細心の注意を払い、非常に高価です。通常の開発/テストコストに約100を掛けると、目標に近づいています。

NASAスペースシャトルソフトウェアについては、「They Write the Right Stuff」を参照してください。FDA（米国食品医薬品局）については、こちらをお読みください

すでに十分な情報量の多い回答が得られているので、ここに私の見解を示します。

簡単です-最初のテストは常にプログラマー自身で行われます。バグの数を少なく抑える傾向があり、質の高いプログラマーだけが給与に残るようにします。

ライフクリティカルなソフトウェアは、「動作しているように見える」もの以外の標準に対してはテストされていません。

すべての投資は、非プログラマーがより良いソフトウェアを作成できるようにするために、プロジェクトの前またはプロジェクトで機能していると思われるものに費やされます。

ps 最初のコメントはありません-1が、私の意見に-1反する参考文献ごとに喜んで取り上げます。

重要なソフトウェアが適切に設計またはテストされていないことがわかった場合、参照ごとに+1を取得できますか？Simson Garfinkel は、WIREDに関する記事で10件の事例を文書化しています。

すべての場合に1つの答えがあるわけではありません。ソフトウェアの設計およびテスト方法を決定するのは、個々の製造業者次第です。ただし、ソフトウェア開発プロセス全体が正式な仕様に準拠する必要があります。

たとえば、医療機器用のソフトウェアを作成する場合、医療機器用のソフトウェアに関するIEC 62304標準に従う必要があります。（残念ながら、無料ではないのでウィキペディアにしかリンクできません）。世界のほとんどすべての国では、この標準に従うことが求められています。

これらの要件がどの程度厳しいかは、危害のリスクに依存します。たとえば、生命維持装置は最も大きな危険を冒します（システムが故障すると特定の死亡）が、病気の診断で動作するシステムはリスクが低くなります（システムが故障した場合、末期疾患が正しく診断されなかった場合は死亡する可能性があります）。

しかし、これは基本的に、要件からソフトウェアまでのトレーサビリティがなければならないということです。ソフトウェアユニットの検証を実行する必要があります。それは検証が何であるかを指定しません。単体テストでも、コードレビューでもかまいません。よりリスクの高いデバイスの場合、ソフトウェアユニット間のインターフェイスを手動で確認する必要があります（私が理解し、覚えている限り）。そしてもちろん、他にもたくさんのルールがあります。ああ、あなたはあなたの仕事を文書化するために多くの文書を書かなければなりません。

この規格はアジャイル開発を禁止していませんが、読むときはウォーターフォール開発を念頭に置いて書かれているようです。

航空、電車、車など、ソフトウェア開発の他の分野については知りません。しかし、他の同様の正式なガイドラインがあると思います。

以下を含むがこれらに限定されない多くの手法が使用されます。

• 正式な設計および/または検証
• メモリの動的割り当てなどの派手なプログラミングを回避する厳格なコーディング標準
• 非常に厳しい品質エンジニア
• コードレビュー、フォールトツリー、FMECAなどの多くの静的分析手法

しかし、一番のテクニックは：

• 試験

宇宙船のソフトウェアは、そもそも設計とコーディングよりもテストに多くの労力を必要とします。

航空機は、飛行機が極端な状況に置かれる数年間の飛行試験を受けます。これは、物理構造だけでなくソフトウェアもテストします。

2009年3月1日12:00 AM ESTのEETimesに関するJack Ganssleによる記事「Perfect software」があります。そこからいくつかのポイント：

• 「理論的には、ソフトウェアが完璧な唯一のコンポーネントであり、これが常に私たちの出発点であるべきです。」-それはジェシー・プーアによって言われています。彼のWebページに続いて、通常のソフトウェアよりもはるかに高いコストで完璧なソフトウェアを作成できる方法がわかります。
• 信頼性の高いOSの産業プロバイダーがあります。記事では、MircriumとGreen Hillsについて言及しました。MicriumのWebページに続いて、認定基準のリストがあります。それらは、業界が従うプロセスとルールでなければなりません。これは正式な検証に基づいていますが、理論から大きく外れています。

興味深いことに、商用ソフトウェアに関して、Capers Jonesによって収集されたデータは、「ソフトウェアは一般に87％の欠陥除去効率（出荷前に除去されたバグの割合）を持っていることを示唆しています。私にとって、これらはどれも完璧に近いものではありません。以前の回答者が言及した記事は、NASAスペースシャトルチームが99％のバグ除去率を達成したことを示していますが、約40万行のコードで年間3500万のコストです。

2009年11月1日の同じ著者による、より興味深い記事「信頼できるシステムのためのソフトウェア」は、より関連性が高いようです。次のように要約できます。

• 開発プロセスについては、業界はDO-178BまたはIEC61508に準拠しています。最大のカバレッジを持つテストを強調しています。しかし、これの有効性についてはほとんど証拠が見つかりません。
• 証明機関であるCertificably Dependable Software Systemsの委員会は、「Dependable Systemsのソフトウェア-十分な証拠」という本を出版しました。それは良い参考です。
• この本は、基本的に3つのことを求めています。[1]信頼性テストの明示的なルールを作成します。[2]ルールに対するテスト。ただし、テストが開発者が費やす時間よりもはるかに少ない時間で、通常の顧客または規制当局がテストを理解できるようにします。[3]ソフトウェアエンジニアリングと問題領域の専門家が開発とテストを行っていることを確認してください。
• ソフトウェアのサプライヤは、ソフトウェアの障害に対して保証またはその他の救済策を講じる必要があります。
• 特にCではなく、安全な言語を使用してください。SPARKをお勧めします。
• 契約アプローチの設計は、SPARKの強みの1つです。設計のための設計は、すべての関数/メソッド呼び出しにテストを埋め込み、常に実行時に実行するための重要なテクノロジーです。昔の単純なassert（）よりも、契約は構造的な意図に対するテストを埋め込み、元の開発者が主に他のプロジェクトに移行したメンテナンスサイクルの後半に違反が入らないようにすることもできます。契約の設計が非常に信頼性の高いソフトウェア製品を生み出したという証拠があります。SPARKとそのツールを使用して、認証テストケースの生成を支援し、認証プロセスを簡素化できます。

私の記憶によると、HPは約10年前に契約設計を実践していました。小規模なチーム、50万行のコードで、配信後に報告されたバグは2つだけです。非常に印象的。

私の見解では、信頼できるまたは完璧なソフトウェアは、コストが法外に高くない場合にのみ達成できます。フレームワークまたは自動化は必須です。

通常、フェールセーフとして使用されるハードウェアインターロックがあります。

たとえば、キラーロボット用の標準の邪悪なテキストボックスのデザインには、常にキルスイッチが付属しています：P

各業界には、安全関連のハードウェアおよびソフトウェアに関するテストおよびドキュメントの要件がある規制機関の独自のセットがあります。UL 1998標準を紹介するUnderwriters Laboratory（UL）のこのPDFを検討してください：http : //www.ul.com/global/documents/offerings/industries/hightech/software/UL_softwareconformityassessment.pdf

その文書には、UL、CSA、およびIECからの多くの他の関連するものへの参照があります。

通常、安全関連ソフトウェアには冗長ハードウェア回路が含まれているか、安全な動作と安全な故障モードを確保するために他の冗長制御機能が必要です。