DO-178C

航空システムおよび機器認証におけるソフトウェアの考慮事項
略語
  • DO-178C
  • ED-12C
最新バージョン2012年1月5日 （2012年1月5日）
組織
前任者DO-178B
ドメイン航空

DO-178C（航空システムおよび機器認証におけるソフトウェアに関する考慮事項）は、 FAA、EASA、カナダ運輸省などの認証機関が、すべての商用ソフトウェアベースの航空宇宙システムを認証する際に用いる主要な文書です。この文書は、RTCA, IncorporatedがEUROCAEとの共同作業により発行し、DO-178Bに代わるものです。新しい文書はDO-178C/ED-12Cと呼ばれ、2011年11月に完成し、2011年12月にRTCAの承認を受けました。2012年1月から販売および使用可能となりました。[ 1 ] [ 2 ] [ 3 ]

FAR 33 / JAR Eを除き、連邦航空規則はソフトウェアの耐空性について直接言及していない。[ 4 ] 2013年7月19日、FAAはAC 20-115Cを承認し、DO-178Cを「航空機システムおよび機器認証のソフトウェア面に関する適用されるFAR耐空性規則への準拠を示すための許容可能な手段であるが、唯一の手段ではない」と認定した。[ 5 ]

背景

DO-178Bの発表以来、FAA指定技術担当者（DER）からは、DO-178Bの主要概念である高レベル要件、低レベル要件、派生要件の定義と境界の明確化／改良、そしてシステム要件とシステム設計（ARP4754参照）とソフトウェア要件とソフトウェア設計（DO-178Bの領域）の間の開始／終了基準のより明確な定義を求める強い要望がありました。その他の懸念事項としては、モデルベース開発パラダイムにおける検証の意味、およびソフトウェアテスト活動の一部またはすべてをモデルシミュレーションまたは形式手法に置き換えることの検討などが挙げられました。 DO-178Cと、関連文書であるDO-278A（地上システム）、DO-248C（DO-178Cの各目標に関する根拠を付した追加情報）、DO-330（ツール認定）、DO-331（モデリング）、DO-332（オブジェクト指向）、DO-333（形式手法）は、指摘された問題に対処するために作成されました。SC-205のメンバーは、SAE S-18委員会と協力し、ARP4754Aと上記のDO-xxx文書が、相互に補完的な基準を備えた統一された連携プロセスを提供できるよう努めました。

全体的にDO-178CはDO-178Bのテキストの大部分を維持しており、低レベル要件の概念に関する曖昧さなど、DO-178Bのいくつかの問題が完全に解決されていない可能性があるという懸念が生じている。[ 6 ]

委員会の組織

RTCA/EUROCAE 合同委員会の作業は 7 つのサブグループに分かれています。

  • SG1: SCWGドキュメント統合
  • SG2: 問題点と根拠
  • SG3: ツール認定
  • SG4: モデルベース開発と検証
  • SG5: オブジェクト指向技術
  • SG6: 形式手法
  • SG7: 安全に関する考慮事項

モデルベース開発・検証サブグループ（SG4）は、ワーキンググループの中で最大の規模を誇っていました。すべての作業は、共同作業管理メカニズムであるウェブサイトを通じて収集・調整されていました。[ 7 ]作業成果物と草案文書は、グループメンバーのみがアクセスできる限定エリアに保管されていました。

この作業は、現在のソフトウェア開発の実践、ツール、技術に合わせてDO-178B/ED-12Bを最新のものにすることに重点を置いていました。[ 8 ] [ 9 ]

ソフトウェアレベル

ソフトウェアレベルは、ARP4754 （DO-178CではIDALをソフトウェアレベルと同義としてのみ言及している[ 10 ] ）で定義されている開発保証レベル（DAL）またはアイテム開発保証レベル（IDAL）とも呼ばれ、システムの故障状態の影響を検証することにより、安全性評価プロセスとハザード分析から決定されます。故障状態は、航空機、乗組員、および乗客への影響によって分類されます。

  • 壊滅的- 故障により死亡事故が発生する可能性があり、通常は航空機の損失を伴います。
  • 危険- 故障により安全性や性能に大きな悪影響が生じたり、乗務員の身体的苦痛や作業負荷の増加により航空機の操縦能力が低下したり、乗客に重傷や致命傷を引き起こしたりします。
  • 重大- 故障により安全マージンが著しく減少するか、乗務員の作業負荷が著しく増加します。乗客に不快感（または軽傷）をもたらす可能性があります。
  • 軽微- 不具合により安全マージンがわずかに減少するか、乗務員の作業負荷がわずかに増加します。例えば、乗客に不便が生じたり、飛行計画が予定通り変更されたりすることが挙げられます。
  • 影響なし- 障害は安全性、航空機の運航、乗務員の作業負荷に影響を与えません。

DO-178Cだけでは、ソフトウェアの安全性を保証するものではありません。設計段階および機能として実装された安全属性は、明示的な安全要件を満たしていることを客観的に証明するために、追加の必須システム安全性タスクを実行する必要があります。認証機関は、これらの包括的な分析手法を用いてソフトウェアレベルAEを確立するための適切なDALを確立することを要求しており、DO-178Cもこれを規定しています。「ソフトウェアレベルは、DO-178Cへの準拠を証明するために必要な厳密さを確立する」[ 10 ]。安全性が極めて重要な機能を指示、制御、監視するソフトウェアはすべて、最高のDALであるレベルAを取得する必要があります。

達成すべき目標の数（独立性を伴うものも含む）は、ソフトウェアレベルAEによって決定されます。「独立性を伴う」とは、検証および妥当性確認プロセスの客観性がソフトウェア開発チームからの「独立性」によって確保される責任の分離を指します。独立性を伴う達成が求められる目標については、項目（要件やソースコードなど）を検証する担当者は、必ずしもその項目を作成した担当者とは限りません。この分離は明確に文書化されていなければなりません。[ 11 ]

レベル 故障状態 目的[ 12 ]独立して
あ 壊滅的な 71 30
B 危険物 69 18
C 選考科目 62 5
D マイナー 26 2
E 安全効果なし 0 0

プロセスと文書

プロセスは、ソフトウェアレベル（AからDまで。レベルEはDO-178Cの対象外です）に応じて、目標をサポートすることを目的としています。DO-178Cでは、プロセスは抽象的な作業領域として記述されており、プロセスの実行方法を具体的に定義し、文書化するのは、実際のプロジェクトの計画担当者の責任です。実際のプロジェクトでは、プロセスのコンテキストで実行される実際のアクティビティが目標をサポートすることを示す必要があります。これらのアクティビティは、計画プロセスの一環としてプロジェクト計画担当者によって定義されます。

DO-178Cのこの目的ベースの性質は、様々なスタイルのソフトウェアライフサイクルに従う上で大きな柔軟性をもたらします。プロセス内のアクティビティが定義されると、プロジェクトは一般的に、そのプロセス内で文書化されたアクティビティを尊重することが期待されます。さらに、DO-178Cによれば、プロセス（およびその具体的なアクティビティ）には明確に定義された開始基準と終了基準が設けられていなければならず、プロジェクトはプロセス内のアクティビティを実行する際に、これらの基準を遵守していることを示す必要があります。

DO-178Cのプロセスと開始・終了基準は柔軟性が高いため、これらの側面は抽象的であり、作業の「基本セット」がないため、初回導入は困難です。DO-178Cの意図は規範的なものではありません。実際のプロジェクトでは、これらの側面を定義する方法は数多くあり、受け入れ可能です。企業がこの規格に基づいて民間航空電子システムの開発を初めて試みる場合、これは困難な場合があり、DO-178Cのトレーニングとコンサルティングというニッチな市場が形成されています。

一般的な DO-178C ベースのプロセスでは、関与の段階 (SOI) は、EASA の認証覚書SWCEH – 002: SW 承認ガイドラインおよび FAAの命令 8110.49: SW 承認ガイドラインで定義されているように、認証機関がシステムまたはサブシステムのレビューに関与する最低限のゲートです。

トレーサビリティ

RTCA DO-178C規格で要求されている、認証アーティファクト間の双方向トレースを示す図。細い青色のトレースと青色で塗りつぶされたボックスはレベルAのみで必要です。紫色のトレースと紫色の塗りつぶされたボックスはレベルA、B、Cで必要です。太い緑色のトレースと緑色で塗りつぶされたボックスはレベルA、B、C、Dで必要です。レベルEではトレースは不要です。各トレース矢印上の参照は、それぞれ目標、アクティビティ、レビュー/検証の規格への参照を表しています。

DO-178では、認証成果物間の双方向の接続（トレースと呼ばれる）を文書化することが求められています。例えば、低レベル要件（LLR）は、それが満たすべき高レベル要件（HLR）までトレースされるだけでなく、それを実装するためのソースコード行、要件に対するソースコードの正確性を検証するためのテストケース、それらのテスト結果などにもトレースされます。トレーサビリティ分析は、各要件がソースコードによって満たされていること、各機能要件がテストによって検証されていること、ソースコードの各行に目的があること（要件と関連していること）などを確認するために使用されます。トレーサビリティ分析は、システムの完全性にアクセスします。認証成果物の厳密さと詳細は、ソフトウェアレベルに関連しています。

DO-178Bとの違い

SC-205/WG-12は、DO-178B/ED-12Bを最新のソフトウェア開発および検証技術に合わせて改訂する役割を担いました。文書の構造はBからCまでほぼ変わっていません。変更点の例としては、以下のものがあります。[ 13 ]

  • より明確な言語と用語を提供し、一貫性を高める
  • より多くの目標（レベルA、B、C）
  • レベルAに適用される「隠れた目標」を明確にしました。これはDO-178Bのセクション6.4.4.2bで暗示されていたものの、附属書Aの表には記載されていませんでした。この目標は、DO-178Cの附属書Aの表A-7、目標9「ソースコードまで遡ることができない追加コードの検証が達成される」に明示的に記載されています。[ 14 ]
  • パラメータデータ項目ファイル - 実行可能オブジェクトコードの動作に影響を与える（ただし、動作自体は変更しない）個別の情報を提供します。例えば、パーティション分割されたオペレーティングシステムのスケジュールと主要なタイムフレームを設定する設定ファイルなどが挙げられます。パラメータデータ項目ファイルは、実行可能オブジェクトコードと共に検証するか、パラメータデータ項目のあらゆる範囲についてテストする必要があります。
  • DO-330「ソフトウェアツールの適格性に関する考慮事項」は、新しい「ドメインに依存しない外部文書」であり、許容可能なツール適格性評価プロセスのガイダンスを提供するために開発されました。この新しい文書の開発にはDO-178Bがベースとして使用されましたが、テキストはツール開発に直接かつ個別に適用できるように改訂され、ツールのあらゆる側面に対応できるように拡張されました。ドメインに依存しないスタンドアロン文書であるDO-330は、DO-178C/ED-12Cのサポートだけでなく、DO-278 /ED-109、DO-254/ED-80、DO-200のサポートにも使用されることを目的としており、 ISO 26262やECSSなどの航空以外のアプリケーションにも使用できます。[ 15 ] その結果、DO-178Cではツール適格性評価ガイダンスが削除され、DO-178Cのコンテキストで使用されるツールにDO-330ツール適格性評価ガイダンスを適用するタイミングを決定するためのガイダンスに置き換えられました。[ 16 ]
  • DO-178C文書のガイダンスを特定の技術に拡張するために、技術補足資料が追加されました。既存の文書を拡張して現在および将来のすべてのソフトウェア開発技術を網羅するのではなく、補足資料は、特定の技術またはテクノロジーに適用するために、コア規格のガイダンスを明示的に追加、削除、または変更するために提供されています。これらの補足資料のすべてのガイダンスは、DO-178Cの関連するガイダンス要素の文脈で記述されているため、コア文書と同等の権限を持つものとみなされるべきです。[ 17 ]
    • DO-331「DO-178CおよびDO-278Aのモデルベース開発および検証補足」 - モデルベース開発（MBD）と検証、およびモデリング手法に固有の落とし穴を回避しながら開発と検証を改善するためのモデリング技術の使用能力について説明しています。
    • DO-332「DO-178CおよびDO-278Aのオブジェクト指向技術および関連技術補足」 -オブジェクト指向ソフトウェアとその使用条件について規定
    • DO-333「DO-178CおよびDO-278Aの形式手法補足」 -テストを補完する（ただし代替ではない）形式手法について言及

ガイドラインとガイダンス

DO-178Bでは、本文中の「ガイドライン」と「ガイダンス」という用語の使用において、完全に一貫性がありませんでした。「ガイダンス」は「ガイドライン」よりもやや強い義務感を帯びます。そのため、SCWGはDO-178Cにおいて、「推奨事項」とみなされるすべての記述に「ガイダンス」を使用し、残りの「ガイドライン」を「補足情報」に置き換え、本文が「推奨事項」よりも「情報」に重点を置いている場合は必ず「補足情報」を使用することにしました。

DO-248C /ED-94C文書全体、 DO-178CおよびDO-278Aのサポート情報は、ガイダンスではなく「サポート情報」カテゴリに分類されます。[ 18 ]

DO-178BとDO-178Cのサンプルテキストの違い

第6.1章では、ソフトウェア検証プロセスの目的が定義されています。DO-178Cでは、実行可能オブジェクトコードについて以下の記述が追加されています。

  • 「実行可能オブジェクト コードはソフトウェア要件 (つまり、意図された機能) を満たし、意図しない機能が存在しないという信頼性を提供します。」
  • 「実行可能オブジェクト コードは、異常な入力や条件に正しく応答できるというソフトウェア要件に関して堅牢です。」

比較すると、DO-178B では実行可能オブジェクト コードに関して次のように規定されています。

  • 「実行可能オブジェクト コードはソフトウェア要件を満たしています。」

追加のリビジョンCの明確化は、ソフトウェア開発者がリビジョンBの文書を解釈する際に遭遇した可能性のあるギャップを埋めました。[ 19 ]

参照

参考文献

  1. ^ Timberlake Membership Software、 703-591-4232。「Rtca, Inc」。Rtca.org 。 2016年8月7日閲覧。{{cite web}}: CS1 maint: 数値名: 著者リスト (リンク)
  2. ^ Charlotte Adams (2010年9月1日). 「DO-178C、近代的なツールと技術の功績により、完成間近」 . Avionics Intelligence . 2011年7月14日時点のオリジナルよりアーカイブ。 2010年10月23日閲覧。業界では、最終版となるDO-178Cが2011年第1四半期に発表され、批准後6～9ヶ月で施行されると予想されている。
  3. ^ 「DO-178BとDO-178Cの相違点の概要」 FAA Consultants.com Qualtech Consulting, Inc. 2010年8月27日時点のオリジナルよりアーカイブ。2010年10月23日閲覧。待望されていたこれらの規格は2011年半ばにリリースされ、2012年に認証機関によって承認される予定です。
  4. ^ Leslie A. (Schad) Johnson. DO-178B, 航空機システムおよび機器認証におけるソフトウェアの考慮事項（軍用機のソフトウェア開発の文脈において、 RTCA/DO-178Bの現在の実践と適用の進化に関する実務家による議論）。ボーイング民間航空機グループ。p. 11。2022年3月3日閲覧。
  5. ^ 「アーカイブコピー」（PDF） 。 2014年9月3日時点のオリジナル（PDF）からアーカイブ。2013年8月8日閲覧。{{cite web}}: CS1 maint: アーカイブされたコピーをタイトルとして (リンク)
  6. ^ Dale, Chris; Anderson, Tom, 編 (2010).システム安全性の進歩：第19回セーフティ・クリティカル・システム・シンポジウム議事録、英国サウサンプトン、2011年2月8日～10日ロンドン：Springer. pp.  298– 299. ISBN 9780857291325。
  7. ^ 「SC-205/WG-71 全体会合」 。 2011年7月19日時点のオリジナルよりアーカイブ。2010年9月18日閲覧。
  8. ^ Bill StClair & Tim King (2012年3月7日). 「DO-178Cは安全性が重要なソフトウェア開発に最新技術をもたらす」 . Military Embedded Systems . 2012年4月17日閲覧。
  9. ^ 「DO-178Cは安全性が重要な航空電子機器ソフトウェア開発を強化」 Electronic Design誌、 2012年4月17日閲覧。
  10. ^ a b RTCA/DO-178C「航空機システムおよび機器認証におけるソフトウェアの考慮事項」、116ページ。「一例として、「アイテム開発保証レベル」（IDAL）という用語がありますが、これはソフトウェアの場合、「ソフトウェアレベル」という用語と同義です。」
  11. ^ RTCA/DO-178C「航空システムおよび機器認証におけるソフトウェアの考慮事項」、41ページ
  12. ^ RTCA/DO-178C「航空システムおよび機器認証におけるソフトウェアの考慮事項」、付録A
  13. ^ 「HighRelyによるFAAソフトウェア・ハードウェア会議の全国概要にDO-178Cのステータスが含まれる」 2006年。2009年9月30日閲覧。DO -178Cでは、ソフトウェアモデリングに関するより詳細な情報と、モデリングを用いてDO-178Bで通常求められる検証手法の一部を代替する可能性のある可能性について規定されます。また、DO-178Cでは、オブジェクト指向（OO）ソフトウェアとその使用条件、そしてDO-178CにおけるOOの認証への影響についても、より詳細に規定されます。
  14. ^ RTCA/DO-178C 航空機搭載システムおよび機器認証におけるソフトウェアの考慮事項RTCA, Inc. 2011.
  15. ^ Pothon, Frédéric. 「DO-330/ED-215の使用原則と利点」（PDF） . validas . 2019年10月3日閲覧。
  16. ^ポソン、フレデリック;他。 （2012年）。DO-178C/ED-12C と DO-178B/ED-12B の変更点と改善点(PDF)。 p. ４９．2015 年1 月 5 日に取得。
  17. ^ポソン、43-46ページ
  18. ^ポソン、14ページ
  19. ^ 「Parasoft Development TestingによるDO-178C準拠の達成」。2014年9月11日時点のオリジナルよりアーカイブ。2013年3月7日閲覧。
「 https://en.wikipedia.org/w/index.php?title=DO-178C&oldid=1319062224」から取得