ソフトウェアの問題を回避する方法
その他 / / November 29, 2021
このデジタル時代では、FacebookやTwitterなどのソーシャルメディアの巨人や、AlibabaやAmazonなどのeコマースプラットフォームについて聞いたことがあるはずです。 これらのオンラインWebサイトは、さまざまなソフトウェアパッケージに依存して動作しています。 これらのプログラムは、私たちの働き方、考え方、生き方を率直に変えました。
その上、以前は本質的に機械的であった多くのデバイスが、現在はソフトウェアによって制御されています。 たとえば、サーモスタットはかつて電気機械装置でした。 しかし、彼らは現在、操作のためにソフトウェアに大きく依存しています。
しかし、 ソフトウェアのバグ 特に日常の活動でそれらへの依存度が高まっている場合は、非常に問題になる可能性があります。 実際、ソフトウェアが意図した目的を達成できず、不快な結果を招くことがかなりの数あります。
この記事では、ソフトウェアのパフォーマンスが大幅に低下した4つの場合と、そのようなソフトウェアの問題を回避する方法について説明します。
1. 米国のマルチステート911の停止
911は重要なサービスであり、個人が必要なときにいつでも緊急要員に連絡できるようにします。 時には、911を介して緊急ディスパッチャーと連絡を取ることで、文字通り生と死の違いを生むことができます。
したがって、2014年4月9日に、それはかなりの災害でした。 911コールルーティングが失敗しました カリフォルニア、フロリダ、ミネソタ、ノースカロライナ、ペンシルベニア、サウスカロライナ、ワシントンを含む米国の7つの州で。
この停止は、Intradoが所有するコロラド州の緊急通話管理センターで発生した予防可能なコーディングエラーが原因で発生しました。
2. ユナイテッド航空の艦隊の接地
2015年7月、ユナイテッド航空は 艦隊全体を接地する ソフトウェアの不具合による航空機の これは世界中で4,900以上のフライトに影響を及ぼし、多くの乗客が空港で立ち往生し、明らかにイライラしました。
航空会社は多くの乗客に不便を補償しなければならなかったので、おそらく経済的影響もあったでしょう。 おそらく、接地のために失敗したいくつかの重要なビジネス会議がありました。
3. トヨタカムリアクセルペダルの故障
2007年9月、Jean Bookoutは、オクラホマ州の州間高速道路69を、乗客のBarbara Schwarzと一緒に旅行していましたが、彼女は困難に直面しました。 彼女のトヨタカムリを制御する.
彼女はスロットルから足を離そうとしましたが、車は加速し続けました。 ブレーキペダルが車を止めることができず、彼女は緊急ブレーキを使わざるを得なかった。
残念ながら、これは車の世話を堤防に送りました。 その結果、シュワルツは死亡し、ブックアウトは重傷のために5か月間入院しました。
カムリのCPUのタスクのクラッシュにつながったいくつかのコーディングの不備が原因で事故が発生したと推測されました。 このCPUは、イグニッション、スロットルコントロール、クルーズコントロールなど、非常に多くの機能を制御します。
トヨタのコードは、古いコードに数年の新しいコードが積み上げられた後、絡み合った混乱になりました。 これは通常、「スパゲッティコード」と呼ばれます。
しかし、Bookoutの事故はこの問題を浮き彫りにし、ソフトウェアプロセスにおけるトヨタの欠陥を浮き彫りにしました。 1000万以上の方法があることがわかった 発生する可能性のある不要な加速、トヨタのコードが構造化された方法に基づいています。
ネストサーモスタットの故障
ネストは会社です、Alphabetが所有、 それはスマートサーモスタットを作ります。 これらのサーモスタットは非常に気の利いたものであり、ユーザーはスマートフォンから家の温度を制御できます。
昨年の冬、Nestサーモスタット グリッチが発生しました 欠陥のあるソフトウェアアップデートの形で、バッテリーが消耗しました。 残念ながら、このエラーは冬の真っ只中に発生し、一時的に何人かのユーザーが熱を失いました。 これは間違いなく、今年のこの時期に起こりたくないことです。
ソフトウェアの問題の簡単な分析
モデルベースの設計やTLA +などのアプローチにより、開発者はソフトウェアの動作の全体像を把握できます。
著名なコンピューター研究者であるブレット・ビクターは、 切断 プログラマーと彼らがコードで解決しようとしている問題との間。
この切断により、プログラマーはコードに何を入れようとしているのかを想像することが難しくなります。 ビクターは、これがソフトウェアにバグが蔓延している要因の1つであると考えています。
しかし、希望はあります。 などのアプローチ モデルベースのデザインとTLA + 開発者がソフトウェアの動作の全体像を把握できるようにします。
モデルベースの設計は、その名前が示すように、ビジュアルモデルを介したソフトウェアの開発を可能にします。 TLA +は、Temporal Logic of Actionsの略で、コンピュータープログラムの仕様を作成するために設計された言語です。 TLA +の優れている点は、ソフトウェアが公開される前に徹底的なテストと検証ができることです。
モデルベースのデザインとTLA +の両方が、すでにその塩を証明しています。 エステレルテクノロジーソフトウェア開発会社である、はモデルベースの設計を使用してセーフティクリティカルなソフトウェアを構築し、TLA +は マイクロソフトは、Xboxの壊滅的なエラーの可能性を修正し、欧州宇宙機関は、 彗星。
コードを書くプロセスは、プログラマーから高く評価されています。 それらの多くは、コードを書くプロセスに非常に単純に興味をそそられます。 したがって、一部のプログラマーにモデルベースの設計やTLA +などのアプローチを受け入れてもらうことは困難です。 これらのアプローチは、現実世界での実行可能性がなく、厳密に学術的であると認識されることがよくあります。 ただし、見方の変更はできるだけ早く行う必要があります。
最終的な考え
ソフトウェアは、組み込みの安全対策を必要とするアプリケーションでますます使用されています。 そのようなアプリケーションは私たちの生活に不可欠であるため、ソフトウェアを設計するためのより良い方法を全面的に導入する必要があります。
最近の自動化などのプロセスはソフトウェアに大きく依存していますが、上記の例が示すように、コード行に1つのエラーがあると、大きな後退につながる可能性があります。
ここで、人工知能(AI)のようなものがこれらのアプリケーションに組み込まれていると想像してみてください。 AIは それだけで十分怖い ソフトウェアの不具合なし。 バグをミックスに追加すると、何が起こるかわかりません。
ただし、ここにはシルバーの裏地があります。 少しの作業といくつかの新しいツールで、より健全に設計し、スタッドでテストすることで、より優れたソフトウェアとAIを作成できます。
この重大な問題が関係当局によって真剣に受け止められ、ソフトウェアを最大限に活用できるが、より安全でスマートな未来を築くことができるようになることを期待しましょう。