DO-178B and DO-178C

提供: T-VEC Wiki
移動: 案内検索

T-VECによる、DO-178B対応に関して、またDO-178C案に対する関わりについて、多くの質問が寄せられています。このページでは、これらのトピックに関するいくつかの情報を提供し、認証プロセスに欠かせない、ツールのクォリフィケイション(証明)といった、重要なトピックも紹介します。

Who Does it Effect

全ての、グローバル航空輸送管理(GATM)、商業輸送システム、空軍や宇宙システム(U.S. Air Force 2001)は、DO-178Bの認証といった、FAAの航空電子機器に対する取決めに準拠しなければなりません。これは宇宙飛行にも影響を与えています。

ツールの証明

認証対象となるソフトウェアの、開発あるいは検証の自動化に用いられるツール、それらツールからの成果物が手動で厳密に評価・査察されないのであれば、ツールのクォリフィケイション(証明)が必要です。 ツールの証明作業は、簡単ではなく、それゆえツール選択において障害にもなります。 一方、ツールのクォリフィケイションを含む、広範にわたる調査が、民間航空電子機器システム開発コミュニティに対して、FAAに独立して委任され、実施されました(Streamlining Software Aspects of Certification (SSAC) program)。 その結果、60%の回答者は、ツールのクォリフィケイションに掛かるコストは小さい、または、僅かであるとし、36%は、相当量であると考え、4%のみが、法外な費用が掛かると考えていました。 幸いに、T-VECツールセットのコンポーネントには、ツールのクォリフィケイション・パッケージが提供されるので、ユーザにとって、クォリフィケイションに掛かるコストは、僅かで済みます。

DO-178 and Tool Qualification History

マシンコードの開発支援に、初めてアセンブラプログラムが記述されてから、アプリケーションソフトウェアの開発を支援するソフトウェアツールの採用は、常識となっています(Salmon 1993)。 ツールの使用者にとって、ソフトウェアツールの正しい動作は、常に関心事であり、アプリケーションのユーザの関心事では有りません。 アプリケーションの機能性に対する責務は、一般に開発者側に任せられ、顧客はアプリケーションが、どのように開発されたかの興味は持ちません。

しかしながら、健康、安全性への影響が懸念されるシステムや、高い保証が求められるセキュリティ関連などでは、正しい機能性に対する関心は、大きくなっています。 そのような分野では、取り得る全ての動作状態において、正しく機能するかの検証は、顧客のみならず、FAAやFDAのような管理機関の関心事でもあります。 これらは、FAAのDO-178B (U.S. DOT 1999)ガイドラインとして、正式に発行されました。 このガイドラインは、ソフトウェアベースの航空電子システムアプリケーションに対する、FAAの認可を基礎としています。ソフトウェア開発プロセスの完全さと、機能の検証に対する、基準を設け、商用飛行に用いられるアプリケーションは、これらに対するFAAの認証が必要となります。 ガイドラインの中でも、特にDO-178Bは、アプリケーション開発プロセスにおいてのソフトウェア使用に関しての項があり、またツール・クォリフィケイションの考えも展開しています。 そのようなわけで、ツール・クォリフィケイションの意味と、T-VECを使用することへのインパクトを理解する上で、T-VECの起源についての簡単な紹介が役に立つでしょう。

History of DO-178B (Paraphrased From Johnson [1998])

アビオニクス産業では、当初ソフトウェアは、安価で、機械の機能とアナログ電気システムを拡張するためのより柔軟な方法として見られていました。 しかし、安全性と信頼性を評価するために、従来からの統計的アプローチでは、航空機のクリティカルなソフトウェアでは役に立たないことが、すぐに認識されました。 代わりの手段として、コンポーネントの故障率ではなく、デザインエラーの解決を目指した評価が、必要となりました。これにより、DO-178の最初のバージョンが作られました。

DO-178

DO-178は、ソフトウェア開発の“ベストプラクティス”を特定し、文書化することによって、ソフトウェア認証の基礎を提供するために作られましたが、それは主に概念上のレベルで書かれました。 準拠するために、認証の申込は、DO-178の“意図”を満たすよう義務付けられましたが、これを行う実際の方法に関して、ほとんど詳細がありませんでした。 使用のルールは、時間をかけて試行錯誤で開発されました。 DO-178は、ソフトウェア認証の要求は、安全性の度合いに依存するという概念を、最初に紹介しました。 そして、ソフトウェア・アプリケーションを3つのカテゴリーに分けました。(critical, essential, and nonessential)

DO-178は、ソフトウェア検証工程と、他の関連する連邦航空規則(FARs)(例えば、Type Certification Approval、Technical Standard Order (TSO) Authorization、Supplemental Type Certification)の関係を確立しました。

DO-178A

DO-178の最初のバージョンが、ソフトウェア検証の概念を導入したのに対し、適用を試みて、改訂が必要であることが、すぐに教訓として指摘されました。 RTCA特別委員会152は、この改訂(1985年に発表されたDO-178A)を作成するために結成されました。DO-178Aは、DO-178と大きく異なることがわかりました。

DO-178Aでは、DO-178で欠落されていると判断された、ソフトウェア開発や検証プロセスを、体系的かつ構造の詳細に、記述されました。 ソフトウェア・アプリケーションの安全性カテゴリーを、critical, essential, and nonessentialとし、またさらに、これら安全性のカテゴリーに相当する、ソフトウェアの認証レベル1,2,3を導入しました。 これは、アプリケーションの安全性の度合いと、ソフトウェアの認証レベル間における違いを容認していました。 それは、全アプリケーションがcritical(臨海レベル)とされても、そのアプリを実現するソフトウェアの認証レベルは、システムデザイン、実装テクニックによって下げられるといったものでした。 例えば、適切に分割されたデザインであれば、クリティカルなアプリケーションの一部は、認証レベル2,3程度で、レベル1で有る必要はありません。(全機能のなかで、重要性が低い部分に対して) DO-178同様、DO-178A適用への試みは、結果として多くの問題を導きました。認証に求められる要求の解釈が、FAAの地域によって食い違っていました。 認証の提出物は、出願者と認証機関の間で、頻繁に論争されました。また、DO-178Aの誤った解釈により、従来式のウォータフォール的なプロセスに従っていないというようなことで、開発サイクル全体が否認されることもありました。 そして産業界は、認証の要求に対する目的を、総合的に理解、認識することができませんでした。

DO-178B

DO-178A の時代、航空電子システム業界は、アナログからデジタルシステムへのシフトを経験し、かつてないほどに、ソフトウェアが応用され、アプリケーションは、より複雑になりました。そして、多くの新しい航空電子システム開発ベンダーが参入し、ソフトウェア認証の制限を、始めて受けることになりました。 DO-178Aドキュメント、トレーニング資料、開発標準、経験者などに不足が有ることが明らかになり、これの対処と、DO-178A適用により新しく得られた教訓を盛り込む、新しいバージョンのDO-178が必要であると、業界は結論付けました。

これらに対処するために、DO-178Bは、以下3つの主要目的を満たすように、仕組まれました。

  • 開発ライフサイクル・プロセスの目標を作成
  • 開発ライフサイクル・プロセスの目標を達成する為の、活動内容、設計検討の詳細を提出
  • 目標が満たされたことを示す証拠の提出

狙いは、重荷を減らし、ソフトウェア認証の経験者不足に対する需要に応えるために、十分な情報、詳細をできるだけ提供することでした。

DO-178Bは、2つの変更内容をもたらしました:安全性の度合いについて説明するための名称集は、“critical, essential, and nonessential”から、“catastrophic, hazardous/severe-major, major, minor, and no effect”へ変更されました。;ソフトウェアレベル1,2,3は、AからEに変更されました。

DO-178Bでは、ソフトウェアの検証に対する要求が変更されたことが、特筆すべき点です。 更に重要なのは、要求仕様ベースのテストが、以前のバージョンに対して盛り込まれたことです。 これは、要件を十分にテスト・評価することなく、テストと構造化カバレッジ解析を行うこと(結果、追試が必要になるような)、を削減あるいは除外させるためです。 要求仕様ベースのテスト、その機能テストに対する構造化カバレッジ解析の重要視は、検証のためのテストを実施する上で、有意義でコスト効率の良い方法であると、みなされました。

要求仕様ベースのテストに重点を置くことで、DO-178Bでは新たに、コードが要件を満たしているかの検証に、要件、コード、テスト間のトレーサビリティを確証する、という重要な目標が得られました。 トレーサビリティには、要件が満たされているかをコード、テストと確認、テストはどの要件から生成されているかを、コード、要件へと確認、といった綿密で、双方向の証拠が必要となります。 DO-178Bの最も高い安全性レベルでは、トレーサビリティの証拠として、100%の構造化カバレッジ解析結果を要求しています。

DO-178Bは、FAA、あるいはDERが、完全性と正確さを監査、解析できる、検証とトレーサビリティの証拠を必要とします。以前のバージョンでもそうでしたが、DO-178Bで求められる、より厳密で完全な検証の証拠は、航空電子システム開発業界にとって、重荷となりました。 認証のためのプロセスには、効果が有るかないかも判らないような一部の作業に、途方も無い時間と費用を費やす、と言った業界関係者からの批判も有りました。 とりわけFAAには、一部の認証プロセスに関して、多くの苦情が寄せられました。(Hayhurst et al. 1998)

DO-178Bで求められる、一定の、体系的で、厳密、完全な、検証とトレーサビリティの証拠を、人的に作ることは、計り知れない尽力となります。 加えて、複雑さは増大し、そのアプリケーションサイズと合わせて、検証作業は急激に増加しました。 DO-178のx3つのバージョンに対して、開発、検証、トレーサビリティを支援するツールが使用され、評価を受けてきたことで、DO-178Bの要求に対応するように特別設計されたツールが、既存のものに対してはるかに自動化を支援すると、期待されるようになりました。 そのようなわけで、そうしたツールに対する依存は、その結果や成果物に独立したレビューも無しに、ますます高まりました。 そして、ツールのクォリフィケイション(証明)がDO-178Bの中で、追加の課題となりました。

Common Questions

DO-178C について

SC-205は、DO-178B - SOFTWARE CONSIDERATIONS IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICATION の更新を行う為の、米国RTCA小委員会内の公式委員会です。 このDO-178Bのドキュメントは、FAAによる、全ての民間航空機のソフトウェア認証を基本としています。 この、1992年にリリースされたDO-178Bは、ED-12Bと同じですが、こちらは欧州で制定されました。 SC-205は、DO-178B/ED-12Bを、現状のソフトウェア開発と検証に用いられる技術に則して、改訂をすることを担っています。新しいドキュメントは、DO-178C/ED-12Cと呼ばれる予定で、2008年完成の予定です。

委員会の作業は、7つのサブグループに分けられています。

  • SG1: SCWG Document Integration
  • SG2: Issues and Rationale
  • SG3: Tool Qualification
  • SG4: Model Based Design and Verification
  • SG5: Object-Oriented Technology
  • SG6: Formal Methods
  • SG7: Safety Related Considerations

モデルベースの設計と検証のグループ(SG4)は、(2007年1月現在)約45名の、最も大きな作業部会です。全ての作業報告は、Embry Riddle大学のDr. Matte Jaffeによって管理されています。

http://forum.pr.erau.edu/SCAS/

このサイトは、一般に公開され、誰もが作業の成果物を参照できますが、それにアクセスするには登録してアカウントを設定する必要があります。現在、このウェブサイトには約700名のユーザがおり、現在委員会には、約130~140名が参加しています。

この作業は、DO-178B/ED-12B(1991年)を、現状のソフトウェア開発、ツール、テクノロジーに則して、改訂をすることです。(このドキュメントの簡単な説明と、現在の作業状況は、以下で確認できます)http://www.aviationtoday.com/cgi/av/show_mag.cgi?pub=av&mon=0705&file=perspectives.htm

SSCIのメンバーや、TAFのような技術、従来からのソフトウェア開発手法などが、直接影響を受けるような多くのトピックが議論されています。なかでもDO-178Bのキーコンセプトである、ハイレベルの要件(High Level Requirements)、ローレベルの要件(Low Level Requirements)、派生要件(Derived Requirements)の定義、関係(境界)の意味を明確にすることや改善、システム要件とシステムデザイン境界に対する基準の、より良い定義について(ARP4754 -http://www.answers.com/topic/arp4754 )、ソフトウェア要件とソフトウェアデザイン間の、より良い定義について(which is the domain of DO-178B - http://www.answers.com/DO-178B )、などが強く求められています。 その他のトピックは、“モデルベース開発における検証とは?”や、“モデルシミュレーションやフォーマルメソッドは、一部の、あるいは全てのソフトウェアテストの実施に取って代われるか?”など。

Model Based Design and Verification について

サブグループ4による議論と決定を求めて、多くの議案が提出されています。 これら議案は、モデルベース開発、及びそれのDO-178Bガイドラインや、ソフトウェアベースの航空機器システムの認証にまつわる手引、などへのインパクト、に対する懸念に取組み、勧告するために書かれました。カバーされているトピックは、

  • 自動コード生成ツールに於いて、ソースコードとは何か?
  • モデリング環境でモデルをシミュレーションした時に、モデルの論理パスのカバレッジは、証明された(完全な)コード生成ツールの、MCDC構造化カバレッジとして認められるか?
  • 上位(high level)、下位(low level)、派生要件(derived requirements)は、何であるか?Simulink/MatrixX/SCADEのようなデザインモデルが、下位要件とすることが順当か?

RTOS の認証について

ここにあるのは、航空システムで使用するRTOSを開発し、DO-178Bの認証を必要とするユーザによって、よく尋ねられる質問例です。

DO-178Bは、単なる認証ではありません。開発計画と同時に開始する工程です。 FAAまたはヨーロッパの同等のガイドラインに則して開発されなかった、既存のアプリケーションを、DO-178Bのいかなるレベルで認証することは不可能に近く、また明らかにレベルAアプリケーションを得ることは不可能です。 DO-178B開発計画の真っ先に、“Plans for Software Aspects of Certification”と呼ばれる文書を作成し、承認のために認証機関に提出することになっています。 この計画書には、開発者がアビオニクスソフトウェア・アプリケーションの開発や検証に用いる、工程やツールや手順を記載します。 この計画はまた、航空機の安全性へのインパクトに関して、アプリケーションと、その使用について記載します。 そして開発者と認証機関は、アプリケーションが、どのレベルの安全性の度合いで、開発されなければならないか、また保証されなければならないかについて判断します。 これにより、目標が決定され、プロジェクトの開発と検証フェーズで生成されるべき、提出物の内容が定まります。

顧客のRTOSなど、既存のアプリケーションを用いて、DO-178Bの認証を受けるためには、実コードを生成するのではなく、元に返って認証をサポートする為の、追加の全書類の作成が必要です。そして完全な開発努力が必要となるでしょう。 例えば、DO-178BレベルAの検証のためには、MCDCオブジェクトコードカバレッジが100%となる十分なテストと、その全てのテスト対象コードが、要求仕様へトレースバックできる必要があります。 認証機関が利用できるように作成されなければならない多くの提出物、満足しないといけない多くの目標が、有ります。