5.用語集
民間航空機の開発で適用される安全認証や関連するガイドラインで使用される用語を解説します。
| 用語 | 解説 |
| ARINC 653 | ARINC 653は、セーフティクリティカルリアルタイムOSにおける空間とメモリパーティションを規定したソフトウェア仕様書である。 IMA構成においては、同一のハードウェア上で、異なるレベルの複数のソフトウェアアプリケーションを実装することができる。 パーティショニングの適用は、自動車機能安全規格において、ソフトウェアコンポーネント間の干渉からの独立を実現するアーキテクチャ設計の１つとして考えられている。 |
| ARINC 429 | ARINC 429は、航空機や輸送機で標準的に採用されているアビオニクス間ローカルネットワークのインターフェースとデータプロトコールを 定義した仕様書である。 |
| ARP 4754A | ARP 4754A(Guidelines For Development of Civil Aircraft and Systems)は、機体の機能を実現する航空機やシステムの開発サイクルを規定したガイドラインである。開発計画、航空機やシステムの開発プロセス、インテグラルプロセスを定義している。システム開発プロセスでは、航空機の機能開発、機能のシステムの割当て、システムアーキテクチャの設計、システム要件の各構成要素への割当てが行い、その後、ハードウェア(DO-254)、ソフトウェア(DO-178C)それぞれの開発プロセスに入っていく。インテグラルプロセスは、システム開発プロセスに対する検証活動、安全性アセスメント、形態管理プロセスを定義している。 |
| ARP 4761 | ARP 4761(Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment)は、ARP 4754Aに沿って、航空機やシステムの開発時に、安全性評価を実施するための手法やガイドラインを記述している。 |
| DAL | DAL(Development Assurance Level)は、航空機やシステムレベルでの潜在的な機能故障とその故障が航空機へ及ぼす影響度合に応じて、安全性評価プロセス(ARP4761)で決定される開発保証レベル(A～E)である。レベルは、破壊的から危険なしまでの5レベルで定義されている。DO-178Cのソフトウェア開発は、上位で決定された開発保証レベルを継承する。 |
| DO-178C | DO-178Cは、2011年12月に航空無線技術委員会（RTCA)によってC改定された、米国における航空用ソフトウェアの開発用ガイドラインである。DO-178Cは、ソフトウェアライフサイクルに関する規格であり、DO-178Cの認証取得には、ライフサイクルデータがプロセスに沿って作成され、目的を達成していることを示す必要である。認証レベルは、A～Eまであり、上位の安全性評価プロセスで決定された開発保証レベル(DAL)を継承している。ソフトウェアの不具合によって起こる結果をそれぞれ壊滅的(A)、非常に危険(B)、メジャー(C)、マイナー(D)、危険なし(E) と分類している。 |
| DO-330 | DO-330は、DO-178Cの補足ガイドラインの一つで、ソフトウェア開発に使用するツールクォリフィケーションに関する規定である。ツールは、設計、検証、管理などの面で活用されるが、ツールの不具合が、アビオニクスソフトウェアに大きく影響を与えてはならないので、ツール提供者とツール利用者に向けて用意されたガイドラインである。 |
| DO-331 | DO-331は、モデルベース開発手法(設計と検証)が、航空機搭載システムのソフトウェアライフサイクルの一部として使用された時に、DO-178CとDO-278Aに対する追加差分と修正を含む補足的な規定である。単独で適用することはない。 自動コード生成を含むモデルベースと従来のハンドコーディングを統合したプロセス構築が一般的である。モデリング言語の性質、モデル化の適用範囲、モデリングツール機能によって、標準プロセスとそのテーラリング方法に差異が出る。Biz3では、自動車分野の知見を活かして、モデルベースツールの特徴を考慮したテーラリングの仕方を支援することができる |
| FADEC | FADEC(Full Authority Digital Engine Control)は、防衛・民間航空機のエンジンを制御する電子制御装置である。燃料噴射量だけでなく、故障診断を含むデジタルコンピュータ制御によって、エンジンを最適な状態に保ち、燃費性能、高応答性、保守性を向上している。フライバイワイヤーとも呼ばれ、油圧機械式のような直接的な制御でなく、センサ、アクチュエータを通して、コンピュータによって、油圧や機械機構を間接的に制御する方式である。自動車のエンジン制御、ステアリング制御、ブレーキ制御、自動運転にも同様のメカニズムが採用されている。 |
| IMA | IMA(Integrated Modular Avionics)は、統合化アビオニクスと呼ばれ、従来のサブシステムをバスで結合した連携型システム構成を、１つのCPU上に複数の機能を実装する設計コンセプトである。ARINC 653に準拠して、複数の機能をレベル別の異なるパーティションに配置することで、安全性を確保しつつ、重量、空間、消費電力、コストを低減する効果がある。統合化アビオニクスをSysMLなどのモデリング言語を使用して設計することで、ソフトウェア設計との一貫性がより確保し易くなる。 |
| Masking MC/DC | Masking MC/DC(Masking Modified Condition/Decision Coverage)は、DO-178BのCertification Authorities Software Team（CAST)が、2001年に発行したポジションペーパーCAST-6で提案されたテストのカバレッジである。”or”演算子の1入力が、真の場合、もう一方が真、偽を取っても、結果に影響しないような状況をマスクと呼ぶ。Z = (A and B) or C という判断文(デシジョン)を例に解説する。Aの独立したZへの影響を示すために、MC/DCではCを偽で固定する。Masking MC/DCでは、Cが偽で、Aとの組で変更することが許される。 |
| MC/DC | MC/DC(Modified Condition/Decision Coverage)は、ソフトウェアテストの網羅性を計るための基準である。DO-178Bの中で、航空機搭載ソフトウェアのテストで適用する網羅度として開発された。レベルAアプリケーションでは、ソースコードのテスト網羅度で、MC/DCを適用する。MC/DCを100%満たすための条件は、各判断文(デシジョン)が、少なくとも1回は、すべての可能な結果を得る、各判断文に含まれる各条件(コンディション)が、少なくとも1回は、すべての可能な結果を得る、１つの判断文に含まれる各条件が、単独でその判断文の結果に影響することである。 |
| PSAC | PSAC(Plan for Software Aspects of Certification)は、ソフトウェア認証計画と呼ばれ、ソフトウェア開発が、DALから継承したソフトウェアレベルの要求を満たすプロセスで実施されることを認証機関が判断するために必要なプロジェクト全体を説明する計画書である。計画書には、システム概要、ソフトウェア概要、認証時の考慮点、ソフトウェアライフサイクルとライフサイクルデータの定義、スケジュール、サプライヤ監視を記載する。 |
| SDP | SDP(Software Development Plan)は、ソフトウェア開発計画と呼ばれ、ソフトウェア開発プロセスの目的を満たすために使用するソフトウェアライフサイクルとソフトウェア開発手順をまとめた計画書である。ソフトウェア開発計画書には、各種標準書(ソフトウェア要求標準書、ソフトウェア設計標準書、コーディング標準書)、詳細なソフトウェアライフサイクル(プロセスの移行基準を含む)、ソフトウェア開発環境として選択したハードウェア、ソフトウェア環境(ツールなど)を記述する。 |
| SVP | SVP(Software Verification Plan)は、ソフトウェア検証計画と呼ばれ、ソフトウェア検証プロセスの目的を満たすために使用する検証手順をまとめた計画書である。計画書には、検証プロセス内の組織的な責任と他のプロセスとのインターフェース、検証の独立性を確立するための手段、検証手法、検証環境(テスト装置、テスト/解析ツール、ツール適用ガイドライン、ハードウェアテスト装置)、検証プロセスに入るための判断基準、コンパイラー/リンカー/ローダーの正しさについて設定した仮定、パーティショニングを使用する場合はパーティショニングの完全性を検証する手法、ソフトウェア変更に関する再検証手法などを記述する。 |
| SCMP | SCMP(Software Configuration Management Plan)は、ソフトウェア形態管理計画と呼ばれ、ソフトウェアライフサイクルを通して、形態管理プロセスの目的を達成するために使用する手法をまとめた計画書である。計画書には、環境(手順、ツール、手法、標準書、組織的な責任とインターフェース)、ソフトウェアライフサイクルにおける形態管理活動(構成の識別、ベースライン化、トレーサビリティ構築、問題報告、変更管理、形態ステータス報告、リリース、権限、ソフトウェアライフサイクルデータの管理、ツールの管理)、ソフトウェア形態管理プロセスに移行する基準、形態管理プロセス要求をサプライヤに適用する方法などを記述する。 |
| SQAP | SQAP(Software Quality Assurance Plan)は、ソフトウェア品質保証計画と呼ばれ、ソフトウェア品質保証プロセスの目的を達成するために使用する手法をまとめた計画書で、プロセス改善、メトリクス、進捗管理方法も含む。計画書には、環境(範囲、組織的な責任とインターフェース、手順、ツール、手法)、権限(責任、独立性、ソフトウェア製品のSQA認証)、活動(レビュー、監査、報告、インスペクション、ライフサイクルプロセスの監視、問題の報告/追跡/是正アクション、ソフトウェア適合性レビュー)、SQAプロセスに移行するための基準、SQA活動のタイミング(他のライフサイクルプロセスとの関連)、SQA活動の記録、サプライヤーのプロセスや成果物が計画や標準に準拠していることを保証する手段を記載する。 |
| 形式手法(Formal Method) | 形式手法は、数学的に厳密に定義された言語を使用して、要求、仕様、ソフトウェア詳細設計を記述し、検証する手法である。記述内容が厳密に定義されることによって、記述の曖昧さが排除され、また厳密に定義されているため、記述の検証を数学的な手段で行うことができる。記述が検証できることによって、テストとレビューを中心とした検証活動の多くを置き換えることが可能になる。その結果、検証工数の削減に大きく貢献する。 |
| 形態管理 | DO-178Cでは、Configruation Managementのことを、形態管理と呼ぶ。形態管理は、認証データ(システム、構成品、工具など)を対象とし、データや記録を過去に遡って取り出すことができるように管理することである。適切な形態管理は、対象のベースライン化、対象の変更を管理、発生した問題を管理することである。データや記録を適切に管理するためのプロセスを形態管理計画書に記述する。 DO-178Cでは、形態管理は構成管理だけでなく、変更管理、問題解決管理をセットにしたプロセスとして扱われている。また、安全レベル、成果物によって、管理の要求レベルが異なる。これらの個別管理は、自動車版安全規格ISO-26262でもあまり深く言及されておらず、規格目的に沿った実装がツール依存になりがちで、過渡な管理または不十分な管理になることが多々ある。Automotive SPICEでは、構成管理、変更管理、問題解決管理プロセス単位で、能力を評定する指標が定義されている。この指標は、DO-178Cに準拠目的にも適用可能である。Biz3は、過去に実施した豊富なAutomotive SPICEアセスメント経験を活用して、DO-178Cの目的を達成するための最適な形態管理プロセス構築を支援できる。 |
| トレーサビリティ | トレーサビリティは、ユーザー要求、システム要件、システム構成、アーキテクチャ設計、詳細設計、実装、検証結果を紐付けし、ある工程で発生した変更や修正、不具合が、上流または下流方向の成果物に対して、どのように影響しているかを追跡できる仕組みである。各プロセスで作成される成果物をデータベース化し、データベース内でトレーサビリティ関係を構築する方法と、各成果物に対して外部からアクセスし、トレースに必要な情報だけを抽出し、それらのトレーサビリティ関係を構築する方法が、ツールとして実現されている。 |
| モデルベース開発 | ソフトウェアウェア開発で一般的に適用されている開発手法で、特徴は、設計と検証を同時に行いながら開発を進めることで、手戻りを少なく、設計の早い段階での不具合排除を可能にしている点である。ソフトウェア要求からアーキテクチャ、仕様、詳細設計をモデルで表現することで、各段階で記述したモデルをシミュレーションによって検証、テストを行い、設計の修正と検証を繰返し実施する手法である。モデルベース開発の利点は、モデル自体が、仕様や設計を共通に認識するコミュニケーション手段になり、仕様や設計の容易な再利用、テストの自動化、モデルの修正が仕様の修正、自動コード生成による人的コーディングエラー排除、コード品質の担保などがあげられる。 |
| モデルベース・システムズエンジニアリング | システムズエンジニアリングは、INCOSEでは、”システムの実現を成功させることができる複数の専門分野にまたがるアプローチおよび手段”と定義されている。システムズエンジニアリングは、システム設計、インテグレーション、評価・解析、システムズエンジニアリング管理の活動で構成され、この活動の中で、モデルを用いるアプローチを、モデルベースシステムズエンジニアリングと呼ばれている。モデル記述の言語は、SysMLを使用する場合が多いので、一般的に、モデルベースシステムズエンジニアリング(MBSE)＝SysMLによるモデリングと解釈されることが多いが、システムズエンジニアリング活動の一部を支援するに過ぎない。 |
| リアルタイムOS | リアルタイム(実時間以内)で実行されるシステムは、ソフトウェア実行だけでなく、ハードウェアやデバイスなどの管理も含む。それらを可能にするOSがリアルタイムOSで、一般的には組込みシステムに採用されている。実時間という制約の中で、複数タスクの並列実行処理、最悪実行時間の保証、タスク間の安全な通信を与えることができるOSである。 |
| ワーストケース実行時間 | ワーストケース実行時間(最悪実行時間)は、組込みシステムにおいて、ある処理の実行に関して、その処理が必要とする最も長い時間のことを指す。組込みシステムでは、リアルタイム性の保証が必要で、ハードウェア上で、処理が常にリアルタイムで実行されなければならない。この要求を検証するための１つの指標が、最悪実行時間である。 |