ライフクリティカルシステムによるイノベーション

公開: 2022-03-11

すべての企業には「重要な」インフラストラクチャがあります。一般に、これは、システムがオフラインになった場合、技術者がシステムを再び実行できるようになるまで、ビジネスの一部（またはすべて）が完全に停止することを意味します。これは、大規模なソフトウェア、ハードウェア、またはネットワークのアップグレードが必要な場合によく発生します。新しく展開されたシステムに、システム障害の原因となる予期しないバグが含まれている場合や、ユーザーが新しいシステムに慣れていないためにミスを犯した場合、技術者ができるようになるまで生産性が停止します。展開のバグを処理するか、ユーザーをトレーニングします。ほとんどの場合、ダウンタイムや生産性の低下は、新しいテクノロジーのパフォーマンスと効率の向上を約束することと引き換えに許容できるリスクですが、それは普遍的ではありません。ほとんどの企業は、多くの収益を危険にさらしたり、クライアントに敵対したりすることなく、ある程度のダウンタイムを許容できます。

しかし、変更する必要のあるシステムが生命にかかわるシステムであり、生命の安全がシステムを確実に使用できるかどうかに依存している場合はどうなるでしょうか。

この記事は、私たちがほとんどの時間を費やしている従来のソフトウェア開発から離れて、代わりに、ライフクリティカルシステムの人間的要素を見ていきます。このトピックに関する私の考えは、911救急車サービスの情報技術部長、国際的な人道的災害対応組織の技術スペシャリスト、および博士号を取得した経験に基づいています。マサチューセッツ工科大学でヒューマンシステムインテグレーションの修了。

始める前に、なぜこれがあなたに関係があるのかを説明したいと思います。あなたのプロジェクトが実際に生命にかかわるシステムを含んでいることは明らかではないかもしれませんが、それはあなたが思っているよりはるかに可能性が高いです。以下のすべてが適格であり、さらに数え切れないほどのトピックがあります。

自動車。 自動車メーカーまたはそのサプライヤーとのプロジェクトに取り組んでいますか？自動運転車のスタートアップによって大学を卒業しましたか？自動ブレーキ、クルーズコントロール、レーンコントロール、コンピュータービジョン、障害物認識、電子エンジン制御モジュールなど。これらはすべて生命にかかわるシステムであり、障害が致命的になる可能性があります。
航空。 空中で30,000フィートの場合、ほとんどすべてのシステム障害が生命にかかわる可能性があります。ボーイング737MAXの最近の出来事を考えると、オートパイロットとコンピューター化された飛行制御の明らかな生命にかかわるシステムがありますが、あなたが考えていないかもしれないこともたくさんあります。自宅では、HVACシステムのファンが故障して少し煙が出た場合は、窓を開けるか、外に出て新鮮な空気を吸います。大西洋横断飛行中に窓を開けて外に出ようとしたことはありますか？ギャレーの電源コンセントからドリンクカートのホイールのブレーキまで、最も基本的なシステムでさえ、航空機では生命にかかわる可能性があります。
コミュニケーション。 ほとんどの開発者またはエンジニアは、キャリアのある時点で、何らかの形で通信システムプロジェクトに取り組みます。多くの人にとって、電気通信は最初は生命にかかわるようには見えません。結局のところ、文明は電話やインターネットの前にうまくやっていた。電気通信インフラが破壊された災害地帯に配備した人として、実際に何が起こっているのかをお話ししましょう。人々は非常に病気になったり怪我をしたりして、911に電話をかけることができなくなります。高齢者は子供に電話して薬局から処方箋を受け取るように頼むことはできません。緊急時対応要員は、コーディネーターまたは相互に通信できません。そして、家族と連絡が取れない人は心配になり、非常に危険な状況に身を置いて彼らを見つけようとします。通信システムは絶対に生命にかかわるものです。

テクノロジーに大きく依存している今日の世界では、半重要であるとさえ考えたことのないプロジェクトが、生命にかかわるシステムの重要なコンポーネントになる可能性があります。

しかし、それが壊れていない場合は、それを修正しないでください

技術システムに関連して「遺産」という言葉を聞いたり使用したりしたことがありますか？それは強い言葉であり、長年の伝統、血統、そして昔の困難な時代の考えを呼び起こします。エンジニアリングの世界では、これは長い間使用されており、確実に機能することが証明されている設計を表すために使用され、リスクを軽減するための望ましい特性と見なされることがよくあります。実際には、リスク回避のために更新されなかった古語法の婉曲表現であり、システム障害が悲惨な結果につながる可能性のある業界に蔓延しています。

遺産のソフトウェアとハードウェアに対するこの親和性の背後には、正当な理由があります。動作することが知られており、未知のバグが発生する可能性は低く、そのコストは安定していて予測可能です。優れた例は宇宙飛行産業です。ロシアのソユーズ宇宙船は50年以上にわたって宇宙飛行士を宇宙に打ち上げてきましたが、その間わずかな修正が加えられました。信頼性が高く安全であるため、引き続き使用されています。残念ながら、これは現代の設計と比較して非常に非効率的であることを意味します。ソユーズは、NASAの遺産ハードウェアを使用して宇宙飛行士を宇宙ステーションに飛ばすのに1席あたり8,100万ドルの費用がかかりますが、SpaceXとボーイングはそれぞれ5,800万ドルの座席を提供すると予想されます彼らの現代のロケット設計を使用します。

まだ機能している古いシステムをアップグレードしたい人はほとんどいないことは理解できます。経営幹部はリスクを望んでおらず、技術者は12年の稼働時間でクローゼット内の不思議なサーバーに対処することを望んでおらず、クライアントは新しい設計を学ぶ必要はありません。残念ながら、リスクの最小化とコスト削減の間には転換点があります。リスクの高い環境であっても、遺産の設計を最終的にアップグレードする必要があります。

この記事の残りの部分では、ファーストレスポンダー、軍隊、または航空機で使用されるシステムなど、システムが生命にかかわる場合にそうするプロセスのいくつかのより重要なステップについて説明します。

真鍮を説得する

私の経験では、おそらくプロセスの最も難しいステップは、アップグレードが必要であることを意思決定者と利害関係者に納得させることです。ライフクリティカルな環境で動作するシステムは、多くの場合、広範な法規制と組織ポリシーに準拠しています。つまり、リスクを冒してお金を使うだけでなく、簡単にいくつかの可能性があることに従事する必要があることを納得させる必要があります。官僚的なテープカットの年。あなたが直面するであろう最も強い反対は、おそらく法務チームからのものであり、法務チームは、新しいテクノロジーを導入することによって組織を開放する潜在的な責任を非常に詳細に説明します。彼らは正しいです。責任は大きな問題であり、何かが壊れて誰かが怪我をしたり死んだりした場合、それは倫理的、評判的、そして経済的な大きな負担になる可能性があります。

フォーチュン500企業と協力しているのか、地元のボランティア消防署と協力しているのかに関係なく、それは常に同じこと、つまりお金に帰着します。企業はそれを失いたくないし、非営利団体はそもそも協力することがあまりない。ライフクリティカルなシステムを変更するリスクを冒すように組織のリーダーシップを説得するために私が見つけた唯一の信頼できる方法は、確率論的に、彼らがそれを失うよりもお金を稼ぐ/節約する可能性が高いこと、または彼らができることを実証することです彼らの技術を近代化し、安全性を向上させることにより、彼らの責任を減らします。

それが意味するのは、あなたが数学をする必要があるということです。バグ（組織内の以前の展開、または他の組織からのデータに基づく）が原因で、ダウンタイムが延長されたり、将来的にクラッシュしたりする可能性はどのくらいありますか？それが失敗した場合に予想される影響は何ですか、そしてその費用はどのくらいですか？逆に、期待されるパフォーマンスまたは信頼性の向上は何であり、それらは何の価値がありますか？先に出る可能性が高いことを示すことができれば、青信号が出る可能性が高くなります。

それはあなたのことではありません

「エンジニアによって、エンジニアのために」というフレーズは、エンジニアが自分と同じような資格を持つ人々が使用するものを作成したことを示唆するイディオムです。これは非常に一般的な出来事であり、1990年代初頭のコンピュータユーザビリティ研究の台頭の主な要因の1つでした。エンジニアとして、私たちは技術システムがどのように機能するかについて平均的なエンドユーザーとは異なるメンタルモデルを持っていることが多く、エンドユーザーがその機能をすでに知っているという前提でシステムを設計する傾向があります。従来のシステムでは、これはエラーと不幸なクライアントにつながります。生命にかかわるシステムでは、死に至る可能性があります。

エールフランス447便の場合を考えてみましょう。2009年6月1日、エアバスA330は、リオデジャネイロからパリに向かう途中で大西洋を越えていました。氷の結晶がピトー管をふさいで、対気速度の測定に不一致を引き起こしました。フライトコンピューターは、不正確な対気速度データで飛行機自体を確実に飛行させることができなかったことを認識して、オートパイロットを解除しました。次に、それ自体を「拡張飛行エンベロープ」モードにしました。これにより、パイロットは、コンピューターでは通常許可されない操作を実行できました。システムを構築したエンジニアは、「自動操縦装置が自動的に解除された場合、それはおそらくパイロットが追加の制御を必要とする状況があるためだと考えていることを想像できます。」

これは、どのようなことがオートパイロットの離脱を引き起こす可能性があるかを理解しているエンジニアにとって自然な考え方です。パイロットにとってはそうではありませんでした。彼らは、対気速度をすべて失い、海に急降下するまで、「失速」警告を無視して、航空機を急な上昇に追いやった。 228人の乗客と乗組員全員が殺されました。彼らの行動の正確な動機については複数の考えがありますが、一般的な理論は、パイロットはフライトコンピューターが航空機を失速させる制御入力を防ぐと想定し（通常の飛行エンベロープに当てはまります）、それを認識していなかったというものです。コンピューターの決定を推進するロジックのエンジニアの精神モデルを共有していなかったため、拡張エンベロープモードに切り替わりました。

少し遠回りですが、これが私の要点につながります。特定の条件下でユーザーに実行してほしいアクションは、ユーザーにとって自然に感じられるアクションでなければなりません。

ユーザーは特定の手順に従うように指示できますが、ストレスの多い状況で何が起こっているのかを理解したり、正しいことを常に覚えているとは限りません。ソフトウェア、コントロール、およびインターフェイスを直感的な方法で設計して、ユーザーが本来あるべきことをやりたくなるようにするのは、ユーザーの責任です。

これが意味することは、エンドユーザーが設計および開発プロセスのすべての段階に関与することが絶対に重要であることです。ユーザーがおそらく何をするかについての仮定はあり得ません。それはすべて証拠に基づいている必要があります。インターフェイスを設計するときは、ユーザーに誘発する思考パターンを特定し、必要に応じて調整するための調査を実施する必要があります。新しいシステムをテストするときは、現実的な条件下で実際の環境で実際のユーザーとテストする必要があります。残念ながら、デザインを変更するときは、これらの手順を最初からやり直す必要があります。

複雑なシステムはどれも独自のものですが、特に、普遍的に適用する必要がある3つの設計上の考慮事項について説明します。

コントロールは、それらが呼び出すアクションを表す必要があります。 幸いなことに、これはかなり一般的であり、一般的にGUIボタンに関連するアイコンまたは物理的なコントロールに関連する形状を選択する形で見られます。「新しいファイル」ボタンは白紙のアイコンを使用し、航空機の着陸装置レバーにはホイールの形をしたノブがあります。しかし、自己満足するのは簡単です。「保存」ボタンに3.5インチフロッピーディスクのアイコンが表示されるのはなぜですか？ 25歳未満の人はフロッピーディスクが何であるかさえ知っていますか？代表的なものだと思って使い続けていますが、実際にはもうありません。コントロールの表現がユーザーにとって意味のあるものになるようにするには、絶え間ない努力が必要ですが、それと継続性のバランスを取ることも必要であり、困難です。
警告システムが壊れた場合、それは検出可能でなければなりません。 赤色のインジケーターが点滅するなど、問題が発生したときに作動する警告灯をよく使用します。ユーザーの注意を引くのに最適ですが、光が切れるとどうなりますか？アポロの月面ミッションで使用された宇宙船には、あらゆる種類のシステム用に数十個の警告灯がありましたが、それらは従来の方法では機能しませんでした。問題が発生したときに点灯するのではなく、すべてが正常なときに点灯したままで、問題が発生したときに消灯しました。これにより、警告灯が切れても、宇宙飛行士が致命的なシステムエラーを見逃すことはありません。電球は1960年代から信頼性が大幅に向上しているため、この設計を使用する必要があると言っているわけではありませんが、計画の一部をどの程度詳細にする必要があるかがわかります。ロギングまたは通知が正しく機能していなかったために、システムがクラッシュしたが、それについて知らなかったことが何回ありますか？
モード遷移は、ユーザーにとって明白でなければなりません。 エアバスA330がユーザーに気付かれずに通常の制御モードから高度な制御モードに移行し、突然航空機がユーザーが考えていなかったことを実行した場合はどうなりますか？自動運転車が自動操縦を解除し、ユーザーが予期せず完全に制御できるようになった場合はどうなりますか？ユーザーのアクションを即座に変更する必要があるモードまたは機能に大きな移行があるが、ユーザーが何が起こったのかを理解するのに1〜2分かかる場合はどうなりますか？複雑なシステムではさまざまな動作モードが必要になる場合がありますが、適切な通知、説明、およびユーザーとの対話なしにモードを移行することはできません。

ライフクリティカルシステムを店外に転がす

業界のベストプラクティスに沿って、新しいライフクリティカルシステムの展開にはベータフェーズが不可欠です。新しいテクノロジーのテストは、バグや使いやすさの問題の大部分を修正するのに役立つかもしれませんが、実際の環境で他のシステムと一緒に使用する必要がある場合、隠れた危険が表面化する可能性があります。システム工学の分野では、これは「創発」として知られています。創発的プロパティは、「アプリケーションのコンポーネントとその環境との間の相互作用に起因する予期しない動作」であり、その性質上、ラボ環境で検出することは本質的に不可能です。エンドユーザーの代表的なグループを慎重な監督の下で新しいシステムの試用に招待することにより、これらのプロパティの多くを検出し、本格的な展開で発生する可能性のある悪影響を評価できます。

クライアントとのアーキテクチャに関する話し合いでよく発生するもう1つのトピックは、段階的な展開です。これは、既存のシステムの要素を新しいシステムの要素に徐々に置き換えるか、最終的にすべてが置き換えられるか、すべてを一度に変更するかの選択です。それぞれに長所と短所があります。段階的な展開により、ユーザーを新しい設計に段階的に順応させることができ、変更が管理可能な量で行われ、ユーザーが圧倒されないようになります。一方、プロセスを長期間にわたって引きずり出し、一定の遷移状態をもたらす可能性があります。即時展開は、「バンドエイドを取り除いて」物事をスピードアップするという点で有益ですが、突然の大幅な変更はユーザーを圧倒する可能性があります。

ライフクリティカルなシステムの場合、段階的なロールアウトの方が一般的に安全であることがわかりました。これにより、実稼働環境で個々のコンポーネントを段階的に評価でき、ロールバックが必要な場合に小さな復帰が可能になります。ただし、これはケースバイケースで評価する必要があるものです。

逸脱の正規化

OK、ユーザーテストは直感的なシステムの設計に役立ち、ベータフェーズでは緊急の問題が特定され、段階的なロールアウトによりユーザーは設計に慣れることができ、すべてがスムーズに実行されています。終わりましたよね？残念ながら違います。

システムの問題は必然的に発生し、それを回避することはできません。ユーザーがこれらの問題に遭遇すると、技術チームに問題を報告する代わりに、多くの場合、回避策を開発します。回避策は、ベテランからルーキーへの「ヒント」として共有される標準的な方法になります。社会学者のダイアン・ヴォーンは、この現象を説明するために「逸脱の正常化」というフレーズを作り出しました。ユーザーは逸脱した行動に非常に慣れているため、実際には逸脱していることを思い出せません。

古典的な例はスペースシャトルチャレンジャーです。固体ロケットブースターのコンポーネントは打ち上げ中に定期的に侵食されることが観察されました。ロケットコンポーネントの侵食は悪いことであることは誰もが知っていましたが、頻繁に発生したため、定期的に免除が発行され、検討されました。正常。 1986年1月28日、誰もが最初に知っていた問題は許されるべきではありませんでしたが、彼らは正常化したため、チャレンジャーが爆発し、7人の宇宙飛行士が死亡しました。

ライフクリティカルシステムの管理者は、このような事態が発生しないようにするのはあなた次第です。ユーザーがシステムとどのように対話するかを調べます。それらを数日間シャドウイングし、予期しない回避策を使用しているかどうかを確認します。定期的にアンケートを送信して、提案された変更や改善を依頼してください。ユーザーがあなたなしで問題を回避する方法を見つける前に、システムを改善するために時間と労力を費やしてください。

プレッシャー下でのパフォーマンスのためのトレーニング

ユーザーがストレス、アドレナリンサージ、およびトンネル視力に苦しんでいる場合、ライフクリティカルシステムの障害が発生することがよくあります。エールフランス447のパイロット、最初の心停止患者の心臓モニターの操作方法を思い出せない救急医療員、および火災時にラジオを適切に操作できない兵士が発生しました。

このリスクの一部は、前述のように直感的な設計を使用することで改善されますが、それだけでは不十分です。特に、ストレスの高いシナリオが発生するが発生頻度が低い環境では、システムの操作方法だけでなく、そのような状況で明確に考える方法をユーザーにトレーニングすることが不可欠です。ユーザーが機器の操作に関連するアクションを記憶している場合、学習したアクションが適切でなくなる可能性があるため、予期しない障害に対処できません。彼らがストレスの下で論理的かつ明確に考えるように訓練すれば、彼らは変化する状況に対応し、何かが壊れたときにあなたのシステムが生き続けるのを助けることができます。

結論

明らかに、ライフクリティカルなソフトウェアの開発、展開、および保守は、単一の記事で詳しく説明するよりもはるかに複雑です。ただし、これらの考慮事項は、そのようなプロジェクトに取り組むことを考えているときに何を期待するかについてのより良いアイデアを与えるのに役立つ場合があります。要約すれば：

すべてが順調に進んでいる場合でも、イノベーションが必要です
リスクに見合う価値があることを経営幹部に納得させるのは難しいですが、数字は嘘ではありません
エンドユーザーは、プロセスのすべてのステップに関与する必要があります
現実的な条件下で、実際の環境で実際のユーザーを使用してテストおよび再テストします
初めて正しく理解したと思い込まないでください。それが機能しているとしても、ユーザーがあなたに話していない検出されていない問題があるかもしれません。
システムの使い方だけでなく、ストレス下で明確に考え、適応する方法についてユーザーをトレーニングします。

最後に、複雑なセーフティクリティカルシステムでは、計画、テスト、およびメンテナンスをいくら行っても、ある時点で問題が発生することに注意してください。これらのシステムが生命にかかわる場合、障害が人命や手足の喪失につながる可能性があります。

そのような悲劇があなたの責任で起こった場合、それはあなたの良心に圧倒的な重荷となるでしょう、そしてあなたがもっと注意を払うかもっと一生懸命働いたならあなたはそれを防ぐことができたと思うでしょう。たぶんそれは本当かもしれないし、そうではないかもしれないが、起こりうるすべての出来事を予見することは不可能である。

細心の注意を払って作業し、生意気にならないでください。そうすれば、世界をより良い場所にすることができます。