DO-178C/ED-12Cの正式名称は「Software Considerations in Airborne Systems and Equipment Certification」で、民間航空機に搭載されるソフトウェアの妥当性を規定する認証規格です。section1.1には次のように記載されています：
「この文書の目的は、耐空性要求に準拠し、確実な安全性で、その機能を達成する航空機システムおよび搭載機器用のソフトウェアを開発するためのガイダンスを提供します。」

このガイダンスは、次の内容で構成されています：ソフトウェアライフサイクルプロセス（software life cycle processes）に関連するobjective

• 計画プロセス（Planning process）
• 開発プロセス（要求、設計、コーディング、統合）　Development processes (requirements, design, coding, integration)
• インテグラルプロセス（検証、構成管理、品質保証、認証調整）Integral processes (verification, configuration management, QA, certification liaison)
• objective達成のための推奨アクティビティ（DO-178Cは、 software life cycle objectives に準拠するためのガイダンスと手法を示し、その手法を活用事例に当てはめることも推奨しています。）
• ソフトウェアライフサイクルデータ（Software life cycle data）：アクティビティ/objectivesが達成されたことを検証するエビデンス（「成果物」）。

ソフトウェア・レベルは、どのガイダンスが、どの程度厳密に適用されるかを定めています。また、ソフトウェア異常が耐空性／パイロットの業務負荷に与える影響に基づいており、安全性評価（system life cycle process）の中で決定されます。DO-178C/ED-12C規格でのソフトウェア・レベルは、D (軽微な障害状態につながる可能性) から A (壊滅的な障害につながる可能性） までの範囲です。その主な目的は検証プロセスで、検証はソフトウェアライフサイクルプロセス（software life cycle process）の成果物を技術的に評価することです。レビュー、解析、テストを通じてソフトウェア開発中に発生したエラーを検出し、報告します。

section6.3には以下のように記載されています：

• 「レビューは、妥当性を定性的に評価し 、チェックリストまたは類似した方法で、成果物を検証します。」レビューとは、DO-178C/ED-12C のobjectivesに準拠したソフトウェア開発によって作成された、ソフトウェア要求、ソフトウェア・アーキテクチャ、ソースコード、オブジェクトコード、テストなどのソフトウェアライフサイクルデータの評価を指します。
• 5.0 Software Development Processes
• 6.4 Software Testing

レビューは認証で必要なエビデンスの必須項目です。具体的に、レビューはDO-178C/ED-12Cの以下のsectionに準拠しています

• 6.3 “Software Reviews and Analyses” and
• 6.4.5 “Reviews and Analyses of Test Cases, Procedures, and Results”).

以下のDO-178C/ED-12C sectionは、追加の「レビュー」アクティビティを定義していますが、ソフトウェア検証プロセスとは異なるため本稿の対象外です。

• 4.6 “Review of the Software Planning Process”
• 7.2.5 “Change Review”
• 8.3 “Software Conformity Review”

本稿は、DO-178C/ED-12Cの観点から効果的なレビューを行うためのフレームワークを定義し、活用する方法を紹介するブログの第1回目です。ツールのレビュー・フレームワークを実現する前に必要なステップは以下の通りです。

1. DO-178C/ED-12Cに規定または暗黙の内に示されているレビュー関連の制約を説明します。
2. DO-178C/ED-12Cに準拠したチェックリスト、レビュー権限、レビューアーの役割等で構成され、レビューに最低限必要なフレームワークを定義します。
3. GitLabなどの構成管理リポジトリを設定し、開発アクティビティを分析してライフサイクルデータを抽出します（プロジェクト、リポジトリ、継続的インテグレーションの自動化など）。GitLab CI（Continuous Integration）は、ソフトウェア開発プロジェクトのビルド、テスト、デプロイプロセスを自動化するためにGitLabに統合されたDevOpsツールです。

本稿では、DO-178C/ED-12Cのレビューobjectiveを効率良く達成するための制約（独立したエビデンスの記録、レビューする構成項目など）を特定します。続いて、2つの項目について説明します。

レビューについて

レビューの主な目的は、DO-178C/ED-12Cでは必須で、開発プロセスの初期段階で潜在的なソフトウェアの欠陥、エラー、不整合を特定し、修正することです。特に、アクティビティが自動化（認定された）ツールで実行されない場合に重要です。

DO-178C/ED-12Cのソフトウェアレビューアクティビティには、重要な要素が含まれています。

1. 3で説明されているように、技術データならびにライフサイクルデータを確認するためのチェックリストまたは類似の補助手段の使用。
2. ソフトウェア検証結果の作成（14に従ってレビューされたソフトウェアのレビュー記録と構成管理情報を含む）。
3. 0(b)に示されるレビューされたライフサイクルデータを効率的に保存および取得するためのメカニズムの導入。
4. 6ならびに6.2にあるように、独立した検証を実施すること。レビューは開発者以外の担当が行い、エビデンスは、出力からアクティビティと入力をトレースできる必要があります
5. section6.3.1から6.4.5で概説されているobjectiveに準拠するために、上位要求（high-level requirements）、下位要求（low-level requirements）、アーキテクチャ（architecture）、ソースコード(source code)、統合プロセス（integration process）の出力、およびソフトウェアテストアクティビティ（software testing activities）のレビュー。
6. section 11.14 に定める、不具合報告によるレビュープロセス中に発見された問題の記録。

DO-178C/ED-12Cのレビューの最初のタスクは、ソフトウェアライフサイクルデータ（software life cycle data）の8つのカテゴリーに分類されたレビューと解析のobjectivesに注目することです。

下図は、ソフトウェア検証プロセスにおいてレビューのために提出されるソフトウェアライフサイクルデータ（software life cycle data）の概要を示しています：

DO-178C/ED-12Cのsection6.3「Software Reviews and Analyses」とsection6.4.5「Reviews and Analyses of Test Cases, Procedures, and Results」には、31のレビューと解析objectivesが明示されています。そのため、レビューの目的は、Objectivesが達成されたことを明確にすることです。そして、適切な検証方法を選択し、検証対象に焦点を当てる必要があります。

検証手法について

レビュー vs 解析

先に示した方法論を適用するために、レビューまたは解析を通じて、すべてのsoftware life cycle data（上位要求(high level requirements)、下位要求(low level requirements)、ソフトウェア・アーキテクチャ、ソースコード、実行可能オブジェクトコード、テストケース、テスト手順、およびテスト結果など）が、Objectivesを達成していることを確認する必要があります。

解析は再現可能なエビデンスとして妥当性を示し、レビューは定性的に妥当性を評価します（DO-178C/ED-12C 6.3項）。レビューの工数を削減する一つの解決策は、DO-333/ED-216 「Formal Methods Supplement to DO-178C/ED-12C and DO-278A 」を用いて、レビューを形式手法で解析することで 補完または置き換えることができます。「形式手法はライフサイクルの初期段階でエラーを特定できるため、プロジェクト全体の工数を削減することができます。(DO-333/ED-216 Section FM.B.1.4.4 Reduce Effort)

例えば、「上位要求(high level requirements)が正確で、曖昧さがなく、詳細な」objectiveであれば、要求が形式記述されていれば、形式解析で処理することができます。また、「上位要求(high level requirements)が形式記述されていれば、正確で曖昧さはなくなります。さらに、上位要求(high level requirements)の形式モデルは、一貫性（矛盾のなさ）を確認することが可能で、形式解析を用いて正確性を検証することができます。」(DO-333/ED-216section6.3.1 b)。

実際に、従来のソフトウェア開発では、次のようになります：

• 上位要求(high level requirements)と下位要求(low level requirements)は自然言語で書かれています。
• ソフトウェア・アーキテクチャは、形式的または準形式的記述を用いないで設計されています。
• コードチェッカーツールを使用して、コーディングルールを検証します。（3.4-c Conformance to standard）
• 静的コード解析ツールを使用して、ソースコードの正確性と一貫性を確認します。（3.4-e Accuracy and consistency）

31個のDO-178objectiveのうち、29個以上のobjectiveがレビューによって検証されます。

形式記述では、次のようになります：

• 上位要求(high level requirements)は、制約のある自然言語（EARSなど）で記述されます。
• 下位要求(low level requirements)は、形式記述（例：SPARK、SPARKはAdaを基にした言語で、コントラクト（contract）や拡張アノテーションを通常のAdaコードのサブセットとして追加されています）で記述されます。
• 「要求を形式記述すると効率が良くなります。」（(DO-333/ED-216 Section FM.B.1.4.1 Improve Requirements)。
• ソフトウェア・アーキテクチャは、UMLのような準形式記述で設計されます。
• 設計検証ツールは、ソフトウェア・アーキテクチャの検証に使用されます（Simulink Design Verifier、GNATprove（データフローの正確性を検証するため）など）。
• 自動化されたドキュメンテーション生成ツールを使用して、トレーサビリティマトリクスを生成します。

準形式記述を用いると、検証するレビューobjectivesを減らしたり、工数を軽減したりすることが可能になります。さらに、規定や規則に従うことで、その柔軟性や解釈の幅が拡がります。この記述法は、必ずしも絶対的な正確さが要求されない場合や、形式記述と可読性を両立させる必要がある場合に用いられます。以下は、EARS構文を使用した例です（EARSはEasy Approach to Requirements Syntaxの略で、テキスト形式の要求を適切に制約するメカニズムです）。EARS 形式の構文は、体系化されたガイダンスを提供するため、品質の高いテキスト要求を記述できるようになります：

When the input A is below 20 [amperes] for more than 10 [milliseconds], the function B shall set the output C to ACTIVE

（入力Aが20 [アンペア]を下回る時間が10 [ミリ秒]を超える場合、関数Bは出力CをACTIVEに設定します。）

要約すると、評価を自動化（レビューを解析に切り替える）、または、形式あるいは準形式記述を用いることで、レビュープロセスを簡素化できます。

レビュー方法

DO-178C/ED-12Cでは、準拠すべき特定のレビュー方法を定めていません。ただ、「レビューは、チェックリストまたは類似した方法で示されたプロセスの成果物で検証を行います。」(6.3 Software Reviews and Analyses)。

代わりに、正確性、精度、完全性、検証可能性など、達成すべきobjectivesと基準（criteria）を規定しています。その結果、文書に定められた基準（criteria）を満たす限り、レビュー方法を選択することが可能になります。

一般的には、ウォークスルー（walk-through）とインスペクション（inspection ）という2つのレビュー方法を用います。２番目の方法は、問題点をより明確にしますが形式化が求められます。

ウォークスルー方式は一種の査読であり、成果物を複数の担当で確認します。ロジック、構造、機能を理解することに重点が置かれ、形式にとらわれず内容を理解することを目的としています。

インスペクション（inspection method）は、1970年代にマイケル・フェイガン氏（Michael Fagan）によって提唱された検査法で、より形式的なプロセスで、管理者（moderator）が複数のレビューアーとともに成果物をレビューします。あらかじめ定義された基準（criteria）または規格（standard）に従って、成果物を検証します。

課題

以下の点に注意することで、効率の低下や工数の増加を防止できます。最初の3つの制約は、構成の明確化、独立性、可用性です。

最後の3つは、工数を削減し、管理を容易するための手段となります。

構成の明確化

DO-178C/ED-12Cでは、レビューした構成項目を明確化することが重要です。

• 開発プロセス全体を通してトレーサビリティを確保するために、要求、テスト、レビュー、欠陥、コードの全内容を含む必要があります。
• 構成項目の正確なバージョンを記録する必要があります。
• 不具合の発生した状況を再現し、解決策を示す必要があります。
• ある時点での、ソフトウェアの状態を文書に記録して、認証監査時に準拠状況を証明します。

独立性

DO-178C/ED-12Cは、レベルAまたはBのソフトウェアのレビュー・アクティビティにおいて、独立性を重要視しています。独立性とは、ソフトウェア開発と検証アクティビティの客観性、正確性、徹底的な精査を明確にすることが基本原則です。さらに、レビュー対象となるソフトウェアライフサイクルデータ（software life cycle data）の開発者以外の担当者がレビューすることが独立性となります。ツールを使用することで、人による検証アクティビティと同等のレベルを達成することが可能です（DO-178C section6.2-e）。ソフトウェア・レベルAでは31項目中16項目（レベルBでは31項目中7項目、レベルC、Dでは該当なし）レビューobjectivesは、独立性を満たす必要があります。

レビューの独立性は、レビューのobjectivesを達成するために不可欠ですが、同時に、必要とされる工数に影響を及ぼす可能性があります：

– 人員の追加

– 必要な人員や専門知識を有する人員のスケジュール調整

– 文書化及びトレーサビリティの記録などの管理により全体的な経費の増加

レビュー・レコードの可用性

レビュー・レコードはコンプライアンスのエビデンスで、認証機関から要求されることがあります。したがって、データとデータベースが監査に使用できる場合、データベースからレビュー・レコードをエクスポートして成果物文書を作成する義務はありません。

文書の書式

文書の書式は、DO-178C/ED-12Cに準拠したレビューおよび解析の効率に影響を及ぼすことがあります。構造化された文書では、レビューは効率化され、レビューアーが要求事項への準拠を適正に審査できます。「文書が念入りに作成されていれば、長期間にわたって有用なものとなります。 反対に、広範にわたって活用されるのであれば、きちんと作成される価値があります。」A Rational Design Process: How and Why to Fake It、Parnas、Clements、1986

DO-178C/ED-12Cは、レイアウトや見栄えではなく、内容に重きが置かれています。そのため、文書は自由な書式や構成（例えば、データベース）をとることが可能です。レビューの工数を削減するために、「少ないほど良い（less-is-more）」ルールを適用し、詳細を必要なものだけに限定し、レビューアーが、全体像を把握できるようにして、適切に詳細を管理することが重要です。

最後に、ソフトウェア要求のレビューを自動化するために、自然言語処理（NLP）ツールで処理できる形式で表現可能な要求の記述ルールを定義する必要があります。

ソフトウェア・コンポーネントの定義

ソフトウェア・アーキテクチャとそのソースコードへの実装に関するDO-178C/ED-12Cレビューおよび解析のobjectivesは次の通りです：

• 6.3.3 b) このレビューobjectivesは、データフローおよび制御フローを介して、ソフトウェア・アーキテクチャのコンポーネント間の関係を検証することです。
• 6.3.4 b) このobjectivesは、ソースコードがソフトウェア・アーキテクチャで定義されたデータフローおよび制御フローと一致することを確認することです。

工数は、コンポーネントの定義、データフロー、コントロールフローの定義ならびに検証にツールを利用するかで大幅に異なります。DO-178C/ED-12Cでは、構成要素の規模や複雑さは、独立したソフトウェア・ モジュールまたは関数に始まり、サブシステム またはアプリ全体といった大規模なソフトウェア・ ユニットに至るまで、多岐にわたります。ここでは、DO-178C/ED-12CとDO-248C/ED-94Cに準拠したプロパティを紹介します：

• ソフトウェア・コンポーネントには、ソフトウェア・レベルが割り当てられます（DO-178C/ED-12C section2.3）。これは、ソフトウェア・コンポーネントがシステムの観点から可視化できることを意味しています。
• ソフトウェア製品（航空機搭載アプリケーションで使用されることを目的としたソフトウェア）は、複数のコンポーネントで構成されます（DO-178C/ED-12C section3.2）。
• ソフトウェア・コンポーネント間のインターフェイス（データフローおよび制御フローの形式）は、コンポーネント間で一貫性を保持するように定義する必要があります（DO-178C/ED-12C section5.2.2 d）。
• インターフェイスが下位のソフトウェア・レベルのコンポーネントに関連している場合、上位のソフトウェア・レベルのコンポーネントには、下位のソフトウェア・レベル・コンポーネントでの誤入力から保護するために、適切な保護メカニズムが備わっていることを確認する必要があります（DO-178C/ED-12C section6.3.3 b）。
• ソフトウェア・コンポーネントはサブプログラムとして定義することもできます（DO-248/ED-94C FAQ #67）。

したがって、ソフトウェア開発戦略に最も適したソフトウェア・コンポーネントの範囲を選択することが求められます。

リソースと時間の制約

プロジェクト管理に関する考慮事項はDO-178C/ED-12Cの範囲外ですが、時間や人員などのリソースが限られているため、レビューの範囲と深さが制限される可能性があります。重要なレビュー・アクティビティに優先順位を付け、品質を損なうことなくレビューがタイムリーに行われるよう、リソースを効果的に割り当てる必要があります。

この制約は、査読コメントが 「Status」、「Category 」または 「Severity 」のプロパティを含みます。

査読コメントを分類することが重要であるもう一つの理由は、EASAとFAAと連携して開発されたアドバイザリーサーキュラーadvisory circular（AC）であるAC 20-189 “Open Problem Reports (OPRs)” による未解決の問題報告書を管理することです。

次回

本稿では、DO-178C/ED-12Cのレビューおよび解析objectiveから得られる制約事項に焦点をあて、DO-178C/ED-12Cに準拠するために最低限のレビュー・フレームワークを記述する仕様書を書くための基礎を解説しました。次回は、DO-178C に準拠し、可能な限り効率的で最小限の実行可能なレビュー・フレームワークを定義する方法を解説します。

著者

———————————————————————————————————————————————————————————————————————–

• Olivier Appéré（オリヴィエ・アペレ）について

オリヴィエは認証エンジニアで、2022年にAdaCoreに入社しました。航空機ソフトウェアの認証分野で20年以上の経験を持ち、DO-178ソフトウェア安全認証規格に精通しています。AdaCoreでは、認証可能なアプリケーションに適したGNATランタイム・ライブラリを担当しています。

————————————————————————————————————————————————————————————————————————-

• Josue Bello（ジョスエ・ベロ）について

ジョスエは2022年よりAdaCoreの認証チームに所属しています。航空業界におけるソフトウェア、ハードウェア、飛行管理・誘導機能の認証に携わった経験を持っています。AdaCoreでは現在、ツール認定に従事し、ランタイム認証活動（ activities.）をサポートしています。

*本資料は、AdaCoreのブログを意訳したものです。正確な内容については、原文こちらをご参照下さい。