空の移動体の認証技術に関連した各種セミナー・トレーニングを取り揃えております。また、そのレベルもお客様のニーズに合わせて初級者向けから上級者向けまでカスタマイズしてご対応致します。型通りのセミナーではなく、ディスカッション形式で、質疑応答に重点を置いた、お客様の疑問や日頃抱えている課題に応えるような双方向のセミナーの開催も可能です。
RTCA DO-178C 民間航空機向けソフトウェア開発プロセス
RTCA DO-330 民間航空機向けツール認証
RTCA DO-331 民間航空機向けモデルベース開発プロセス
ASTM F3201-16 小型無人航空機向けソフトウェア開発プロセス
Software Considerations in Airborne Systems and Equipment Certification
DO-178Cは、そのタイトルが「Software Considerations in Airborne Systems and Equipment Certification」であり、米国のRTCAが2011年12月13日にC改訂を制定しました。また、民間航空機に搭載されるソフトウェアを開発する際のガイドラインとしてFAAが2017年7月21日にAC20-115Dを発行して、その適用を推奨しています。加えて、欧州、日本を始めとする各国の認証当局も同様にその適用を推奨しています。
ここでは、DO-178Cの特徴を表すいくつかのキーワードについて簡単に紹介したいと思います。
1. ソフトウェアレベル
DO-178Cでは、ソフトウェアの持つ機能の重要度をソフトウェアレベルという指標を用いて表しています。下表に示すように、そのソフトウェアが誤った振る舞い、もしくは機能を停止することにより発生する故障状態が機体の墜落や多くの搭乗者の生命に関わるような結果を引き起こすようなソフトウェアはソフトウェアレベルAと指定され、そのソフトウェア開発は厳密に実施されることが求められます。
2. Software Life Cycle Processes
DO-178Cでは、ソフトウェアの開発プロセス(Software Life Cycle Processes)として以下の3つのプロセスを定義しています。
(1) Software Planning Process
ソフトウェアの開発に先立ち、今後実施するSoftware Development Process及びIntegral Processの活動を計画するプロセスです。
(2) Software Development Process
実際のソフトウェアを作り上げるプロセスであり、以下の4つのサブプロセスから構成されています。一般的に言われているソフトウェア開発のV字プロセスの左側に当たるものとなります。
(a) Software Requirements Process
(b) Software Design Process
(c) Software Coding Process
(d) Integration Process
(3) Integral Process
Software Planning Process及びSoftware Development Processと併行して実施され、各プロセスの成果物が正確であり、管理されており、信頼できることを保証するプロセスです。以下の4つのサブプロセスから構成されています。
(a) Software Verification Process
(b) Software Configuration Management Process
(c) Software Quality Assurance Process
(d) Certification Liaison Process
3. Objectives
ソフトウェアレベルに応じてソフトウェア開発の厳密さが異なると言いましたが、それを具体的に示すもののひとつとしてObjectivesがあります。このObjectivesの考え方はDO-178Cの大きな特徴であり、時にDO-178CはObjective Orientedなガイドラインと言われることがあります。Objectivesとは、簡単に言うとSoftware Life Cycle Processesの各プロセスにおいて達成が求められる目標と言うことができます。
例えば、こんなObjectiveがあります。
High-level requirements comply with system requirements.
これは、Software Requirements ProcessのverificationにおけるObjectivesの中のひとつです。ここでは、「Software Requirements Processの成果物であるHigh-level requirementsが上位プロセスのsystem requirementsと適合していること」をverificationによって示すことが求められています。DO-178Cでは、このobjectiveが記載されているのみであり、どうやってこのobjectiveを達成するのかは記載されていません。それは、そのソフトウェアを開発する側がその達成方法を提案し、認証当局にそれを承認してもらう必要があります。
下表に各プロセスにおいて達成が求められているObjectivesの数を示しました。当然のことですが、ソフトウェアレベルAでは、全てのObjectivesの達成が求められています。それに加えて一部のObjectivesは第三者による達成が求められています(表中のカッコ内の数字)。
Software Tool Qualification Considerations
DO-330は、そのタイトルが「Software Tool Qualification Considerations」であり、米国のRTCAが2011年12月13日にDO-178のC改定を制定した際に、DO-178Cを補足する文書として制定されたガイドラインのひとつです。DO-178BにおいてもTool Qualificationの必要性が記載されていましたが、そのプロセスが曖昧であり、多くの混乱を招いていました。そのため、DO-330において、Tool Qualificationのプロセスを明確にしたものです。DO-178Cと同様に、FAAが2017年7月21日にAC20-115Dを発行して、その適用を推奨しています。加えて、欧州、日本を始めとする各国の認証当局も同様にその適用を推奨しています。
1. どのような時にTool Qualificationが必要となるのか
DO-178C に準拠したソフトウェア開発の際に、使用する全てのツールに対してTool Qualificationが必要となるわけではありません。どのような場合にTool Qualification が必要となるかは、DO-178C に規定されており、以下の2 つの条件を共に満たす場合となっています。
条件1： そのツールを利用することにより、DO-178C で規定されたプロセスが、排除（eliminated）、削減（reduced）、もしくは自動化（automated）される。
条件2： ツールの結果がDO-178C のSoftware Verification Processで検証されない。
例えば、コンパイラはソースコードからオブジェクトコードの生成を自動化していることから、条件1を満たしています。しかしながら、そのコンパイラが生成したオブジェクトコードは、Software Verification Process のtesting process にて検証されますので、条件2 は満たされません。従って、コンパイラにはTool Qualification は必要ありません。一方で、カバレッジ解析ツールは、カバレッジ解析のプロセスを自動化するため、条件1を満たしています。また、一般的にその結果に対して手動で再度検証することはなく、ツールが出力した結果を信用してカバレッジ解析のエビデンスとして使用することになるかと思います。従ってカバレッジ解析ツールのTool Qualification は必要となります。もちろん、カバレッジ解析ツールの結果を手動で再度検証するのであれば、Tool Qualification の必要はありません。
2. ツールの種類
DO-178C では、ツールを以下の3 種類に分類しています。
Criteria 1：ツールの出力が航空機搭載ソフトウェアの一部となり、それ故、エラーを挿入する可能性があるツール
Criteria 2：Software Verification Process を自動化するツールであり、それ故、航空機搭載ソフトウェアに含まれるエラーの検出を誤る可能性があるツールであり、更に、そのツールの出力が、下記の排除や削減に利用されるツール
・自動化される箇所以外のSoftware Verification Process
・航空機搭載ソフトウェアへ影響を持つSoftware Development Process
Criteria 3：Software Verification Process を自動化するツールであり、それ故、航空機搭載ソフトウェアに含まれるエラーの検出を誤る可能性があるツール
この定義を整理すると、Criteria 1は、コンパイラ、リンカー、自動ソースコード生成ツール等のソフトウェア開発ツールであり、Criteria 3は静的解析ツール、テストカバレッジツール等の検証ツールとなります。Criteria 2が少し難しい定義となりますが、検証ツールに分類されますが、直接的に排除（eliminated）、削減（reduced）、もしくは自動化（automated）されるプロセスに加えて、追加他のプロセスも排除、削除することができるツールとなります。
3. TQL (Tool Qualification Level)
DO-178C では、Tool Qualification の厳格さの指標としてTQL（Tool Qualification Level）を定義しています。このTQL は、前述のCriteria と、そのツールを用いて開発する航空機搭載ソフトウェアのソフトウェアレベルの組み合わせで決定されます。下表 にその決定方法を示します。この表から分かるように、TQL には厳格さのレベルに応じて5 段階があり、TQL-1 が最も高く、TQL-5 が最も低いレベルです。ここで注目すべきは、Criteria 3のツール、すなわち検証ツールは、開発対象となる航空機搭載ソフトウェアのソフトウェアレベルに関係なくTQL-5の最も低いレベルが割り当てられていることです。
4. Tool Life Cycle Process
DO-330では、ツールの開発プロセスをTool life Cycle Processとして以下のように定義しています。これを見てわかるようにDO-178CにおけるSoftware Life Cycle Processと非常に似通っています。すなわち、(2)はDO-178CのSoftware Planning Processに、(3)はSoftware Development Processに、(3)はIntegral Processに対応しており、ツールをソフトウェアのひとつと捉えて、ツールを開発するプロセスを規定しています。従って、(2)から(4)のプロセスはツールを開発する側、COTSツールの場合ツールベンダーに対するガイドラインとなります。一方、(1)のTool Operational Processはツールを利用する側に対するガイドラインとなっています。
(1) Tool Operational Process
(a) Tool Operational Requirements Definition Process
(b) Tool Operational Integration Process
(c) Tool Operational Verification and Validation Process
(2) Tool Qualification Planning Process
(3) Tool Development Process
(a) Tool Requirements Process
(b) Tool Design Process
(c) Tool Coding Process
(d) Tool Integration Process
(4) Integral Process
(a) Tool Verification Process
(b) Tool Configuration Management Process
(c) Tool Quality Assurance Process
(d) Tool Qualification Liaison Process
5. Objectives
DO-330 では、DO-178C と同様にObjectivesを設定しており、TQL によって達成すべきObjectives を規定することによりツール開発の厳格さを定めています。下表に各プロセスにおけるObjectives の数をTQL 毎に記載しました。DO-178Cと同様に一部のObjectivesは第三者による達成が求められています(表中のカッコ内の数字)。
この表を見て分かることは、TQL-5 のObjectivesの数が圧倒的に少ないということです。前述したようにCriteria 3 に属している検証ツールは、それを利用する航空機搭載ソフトウェアのソフトウェアレベルに関係なくTQL-5 が割り当てられています。しかも、TQL-5 に求められているObjectives は、No.0 はもちろんですが、No.8、No.9、No.10 に於いても利用者側で達成すべきObjectives となっています。これは、何を意味しているかと言うと、TQL-5 の検証ツールは、たとえそれがCOTS ツールであったとしても、ツールベンダーからのデータ提供はなくてもTool Qualification の取得が可能だということです。
Model-Based Development and Verification Supplement to DO-178C and DO-278A
DO-331は、そのタイトルが「Model-Based Development and Verification Supplement to DO-178C and DO-278A」であり、米国のRTCAが2011年12月13日にDO-178のC改定を制定した際に、DO-178Cを補足する文書として制定されたガイドラインのひとつです。民間航空機に搭載するソフトウェア開発にモデルベース開発(Model Based Development: MBD)を適用した際に、DO-178Cに加えて準拠すべきことが記載されています。DO-178Cと同様に、FAAが2017年7月21日にAC20-115Dを発行して、その適用を推奨しています。加えて、欧州、日本を始めとする各国の認証当局も同様にその適用を推奨しています。
1. DO-331制定の背景
民間航空機に搭載されるソフトウェアには、多くの乗客を乗せて空を飛ぶという特性上、安全性、信頼性の高さが求められています。それを実現する方法として米国RTCAが制定したソフトウェア開発のプロセスであるDO-178に準拠してソフトウェア開発を実施することが各国の認証当局により求められています。
DO-178はB改定が1992年に制定され、ソフトウェア開発プロセスの基本部分は完成しましたが、その後のソフトウェア開発技術の発展に伴い、2012年にC改定が為されました。その際に世間で使われ始めていたMBDを、民間航空機のソフトウェア開発に適用する場合に準拠すべきプロセスとしてDO-178Cを補完する形でDO-331が制定されました。
DO-331では、MBDを適用することにより、DO-178Cで規定されたソフトウェア開発プロセスに加えて実施すべき活動が定義されていると共に、削除することができる活動も併せて定義されています。従って、トータルの開発コストと言う観点から言うと、この追加の活動と削除の活動のトレードオフと言うことになります。
2. MBDの特徴とDO-331での扱い
一般的にMBDとして、最も特徴的なことは、シミュレーションと自動ソースコード生成と言うことができるかと思います。
(1) シミュレーション
MBDは文字通り、ソフトウェアの設計を、モデルを用いて行うものですが、MBDの特徴としてそのモデルレベルでシミュレーションすることにより設計内容の正しさを早期に確認できるという点があります。DO-331においてもこの点に注目し、いくつかの条件はありますが、モデルレベルでのシミュレーションを実施することによりDO-178Cで規定したいくつかの活動を削除することができることを定めています。これは、MBDそのものが持つフロントローディングの優位性に加えて、DO-178Cが求めるソフトウェア開発プロセスへの適合のための労力を軽減すると言う観点からも優位性があるのではないでしょうか。
(2) 自動ソースコード生成
MBDのもう一つの特徴として挙げた自動ソースコード生成ですが、DO-331では、DO-330に基づくTool Qualificationを取得した自動ソースコード生成ツールを用いることにより、DO-178Cで規定されたいくつかの活動を省略することができることを定めています。具体的には設計結果であるモデルに対してソースコードが適合していることを検証する活動となります。この検証活動は一般的にはチェックシート等を用いて人手で行うものですが、認証の取れた自動コード生成ツールであれば、既にツールの振る舞いが保証されているためこれらの検証活動を削減できると言うものです。
他方で、敢えてTool Qualificationを取得しない自動ソースコード生成ツールを選択したツールベンダーもいます。このツールベンダーは、Tool Qualificationを取得した自動ソースコード生成ツールを用いた場合と同じ効果を持つ検証ツールを提供する、と言う戦略を取りました。と言うのも、Tool Qualificationを取得するコストは自動ソースコード生成ツールと比べて検証ツールの方が圧倒的に安いからです。DO-331に準拠したMBDプロセスを構築する場合は、どちらの自動ソースコード生成ツールを選択するかで構築されたMBDプロセスは大きく異なります。両者のメリット、デメリットをよく分析して、自らのやり方に合ったMBDプロセスを構築することが必要だと思います。
(3) DO-331を用いたMBDの勧め
加えて、DO-331の最も特徴的な点は、これらの活動の削減を含めてMBDを適用した際のソフトウェア開発プロセスが合理的に説明されており、それが認証当局により推奨されていると言う点ではないでしょうか。自動車産業においてもMBDは採用されてはいますが、DO-331ほどにその合理性を示したガイドラインはないのではないでしょうか。
このようにDO-331は優れたガイドラインである一方で、欧米に比べて、日本国内ではまだこのガイドラインに基づいた実証例がないのが現状です。今後、航空機の電動化や無人航空機の発展の中で、いかにより早く、信頼性の高いソフトウェアを市場に提供できるかは、これらの新しい分野における優位性を確保するための重要なポイントであり、DO-331に準拠したMBDの適用がキーテクノロジーの一つと言うことができのではないでしょうか。
3. DO-331の開発プロセス
DO-178Cの開発プロセスと比較したDO-331の開発プロセスを下図に示します。DO-331で特徴的なところを赤い字で示しました。まず、青いブロックのSoftware Development Processの中のSoftware Coding Processは自動ソースコード生成ツールにより自動化されます。次に、緑のブロックのSoftware Development Processの成果物としては、Software Design Processの成果物は、Design Modelと呼ばれるモデルで表現されます。加えて、Design Modelのverificationの一環としてSimulationが行われて、モデルの正しさがこの段階で検証されます。
シミュレーションやTool Qualificationを取得した自動ソースコード生成ツールを用いた場合、いくつかの活動を削除することができると書きましたが、それを赤と青の枠で表現してみました。赤枠は、シミュレーションを実施することにより削除することができるverification(testingを含む)を示しています。一方、青枠は、Tool Qualificationを取得した自動ソースコード生成ツールを用いることにより削除することができるverification(testingを含む)を示しています。
4. シミュレーションにより削減できるObjectivesの例
前述のシミュレーションを実施することにより削除できるverificationの例としてSoftware Coding Processのverificationの例を下表に示します。このverificationはDO-178C(及びDO-331)の中ではTable A-4として定義されています。この表中No.1から13まではDO-178Cで定義されたObjectivesとなっており、MB14からMB16までがDO-331で追加されたObjectivesとなっています。MB14からMB16まではシミュレーションを正しく実施することを求めており、これらのObjectivesが達成されたことを前提として◯がつけられたObjectivesがシミュレーションにより達成されたと見做されて削除することができます。
Standard Practice for Ensuring Dependability of Software Used in Unmanned Aircraft Systems(UAS)
F3201は、そのタイトルが「Standard Practice for Ensuring Dependability of Software Used in Unmanned Aircraft Systems(UAS)」であり、無人航空機のソフトウェア開発におけるガイドラインとしてASTMが2016年に制定しました。無人航空機と銘を打っていますが、基本的には、その対象は小型機(最大離陸重量が55lb(25Kg)以下)となっています。また、固定翼機、回転翼機(VTOLを含む)の区別や、エンジン駆動、モーター駆動などの区別はしていません。
ソフトウェアに特化したガイドラインであり、特に、作成されたソフトウェアのレビュー、分析に重点を置き開発途中でのソフトウェアの信頼性を高める活動を要求しています。この考えはDO-178Cを始めとする民間航空機の開発に於ける開発保証(Development Assurance)の考え方に通じるものがあると言えます。これらの活動はF3201の5章Requirementsに個々の要求として規定されています。
また、ソフトウェアの特徴であるサードパーティなどの第三者が作成したソフトウェア(F3201ではEDS(Externally Developed Software)と呼ぶ)の信頼性を担保する要求が多く規定されています。
加えて、飛行の安全に直結する外部とのインターフェースを多く持つ無人航空機の特徴として、サイバーセキュリティに対する要求もいくつか規定されています。
1. Tierについて
Tierとは、無人航空機に搭載されるソフトウェアを、その誤動作、もしくはセキュリティ上の攻撃によって、機体及び地上の人間、建物等に与える損傷、傷害からカテゴリー分けしたものです。TierはTier1(軽度)からTier3(重度)まであり、それぞれに対してソフトウェア開発時に遵守すべき要求がF3201の5章Requirementsに定義されています。
以下に、F3201に於けるTier1～Tier3の定義を示します。
(1) Tier1
ソフトウェアの誤動作、もしくはセキュリティ上の攻撃によって、無人航空機の機能または安全マージンがわずかに低下する結果をもたらすものであり、AC23.1309-1 EにおけるMinor Failure Conditionに相当します。
(2) Tier2
ソフトウェアの誤動作、もしくはセキュリティ上の攻撃によって、潜在的に傷害(injury)の可能性のある無人航空機の機能または安全マージンを著しく低下させる結果をもたらすものであり、AC23.1309-1 EにおけるMajor Failure Conditionに相当します。
(3) Tier3
ソフトウェアの誤動作、もしくはセキュリティ上の攻撃によって、無人航空機の機能または安全マージンの大幅な低下をもたらし、重大な傷害(serious injury)または死亡(fatality)につながる結果をもたらすものであり、AC23.1309-1 EにおけるHazardous / Catastrophic Failure Conditionに相当します。
AC23.1309-1E: FAA Advisory Circular System Safety Analysis and Assessment for Part 23 Airplanes
2. Requirements
前述したようにF3201では、DO-178CのObjectivesに相当するものとして、ソフトウェア開発時に遵守すべき要求が5章Requirementsに記載されています。下表に、5章の構成とそこで定義されているRequirementsの数をTier毎に示しました。
3. ソフトウェア開発プロセス
F3201では、明確にソフトウェアの開発プロセスを定義はしていませんが、F3201の5章 Requirementsを分析することにより、以下に示す開発プロセスを前提としていると推測されます。ここでは、ソフトウェアの開発プロセスとして良く知られたDO-178Cに当てはめる形で整理してみました。
(1) Planning Process
F3201の5. requirementsでは、(2)以降に示す各プロセスの要求の記載の中で、そのプロセスでの計画書(plan)の作成を求めています。これらの活動を実施するプロセスがPlanning Processです。
(2) Development Process
F3201では、明確にDevelopment Processの定義はないが、後述のVerification Processに関連する記載から、verification対象となるDevelopment Processが以下のサブプロセスから構成されていることが見て取れます。
(a) Requirements Design
(b) Architecture Design
(c) Detailed Design
(d) Coding
(e) Integration
(3) Verification Process
F3201では、Development Processの各サブプロセスに対応する形で、分析(Analysis)、及びレビュー(Review)を要求しています。DO-178Cのプロセスに対応付けるとVerification Processとなります。Verification Processを構成するサブプロセスは以下となります。
(a) Requirements Design Analysis
(b) Architecture Design Analysis
(c) Detailed Design Analysis
(d) Code Review
(e) Testing
(4) Quality Assurance Process
ソフトウェア開発時の品質保証の活動がF3201の5.5 Quality Assuranceの項目に記載されています。
(5) Configuration Management Process
F3201には、明確にConfiguration Management Processの定義はありませんが、5章Requirementsで求められている活動の中にDO-178CのSoftware Configuration Management Processに相当する活動が見受けられます。
(6) Security Process
前述したように、F3201ではサイバーセキュリティに関する要求があります。
(7) Maintenance Process
F3201では、ソフトウェア開発後の維持段階における要求も多く記載されています。これは、DO-178Cがソフトウェア開発段階に適用されるガイドラインであるのに対して、F3201はソフトウェア開発後の維持段階もその適用範囲としており、対象とするライフサイクルが長いためです。
4. セキュリティ
ここでは、F3201の特徴として最初に紹介したセキュリティの取り扱いについて簡単に紹介します。
F3201では、セキュリティの観点からソフトウェアのテストの一環としてpenetration testingとred team evaluationの実施を要求しています。さらに、penetration testingの種類として外部からの攻撃に対応するためのexternal penetration testingとソフトウェア内部の脆弱性を見つけるためのinternal subsystem-level penetration testingの2種類の実施を求めています。
また、脅威モデル(threat modeling)によるリスク分析と脅威に対する対応を求めています。これらの活動はDO-326Aに於ける、Security Risk AssessmentとSecurity Requirements(Security Measure)の設定に該当する活動となっています。
4. EDS(Externally Developed Software)
ここでは、F3201の特徴として最初に紹介したEDSの取り扱いについて簡単に紹介します。
F3201では、EDSの取り扱いに対する要求が多く規定されています。F3201の3章Terminologyでは、EDS(Externally Developed Software)を「無人航空機メーカーの外部で開発されたソフトウェアであって、開発プロセスの適切な記録が入手できない場合がある」と定義しています。この定義に従いEDSを「無人航空機メーカーの外部で開発されたソフトウェア」と捉えると該当するものとして以下を挙げることができます。
(1) COTS ソフトウェア : サードパーティが作成したソフトウェアであり、カタログ販売されているもの
(2) ライブラリソフトウェア : コンパイラが提供するものや、フリーソフトなども含まれる
(3) サプライヤ作成ソフトウェア : 無人航空機メーカーが仕様を指定しサプライヤが作成したもの
(1)と(2)は、無人航空機メーカーが仕様を指定することができず、カタログ等から自らの製品に適合するものを選ぶのに対して、(3)は仕様をサプライヤに示して作らせることから、自らのソフトウェア開発の一部をサプライヤに委託していることになります。(3)の場合、そのソフトウェアは自社開発の一部(F3201ではIDS(Internally Developed Software)と呼ぶ)として扱い、サプライヤに対しても自社開発のIDSと同等の開発プロセスを適用し、無人航空機メーカーはサプライヤの管理を実施すべきでしょう。
従って、上記の(1)と(2)をEDSとして取り扱うことになります。ちなみに、DO-178Cに於いては(1)(2)(3)いずれの場合に於いてもDO-178Cに準拠した開発プロセスの適用が求められます。その意味でF3201では、EDSを特別に扱っており、満たさなければならない基準が軽減されている、と言うことができるのではないでしょうか。
F3201に於いて、EDSの取り扱いに関する要求を分類すると、以下のプロセスとなります。これらの要求は全てEDSを統合(Integration)する無人航空機メーカーに課せられたものであり、EDSの開発メーカーに課せられたものではないことに注意する必要があります。詳細の要求はここでは省略しますが、概ね、ソースコードや設計書が入手できない状況で、いかにソフトウェアの安全性、信頼性を担保するかがポイントとなっています。
(1) Planning Process for EDS
(2) Development Process for EDS
(3) Verification Process for EDS
(4) Quality Assurance Process for EDS
(5) Configuration Process for EDS
(6) Safety and Security Process for EDS
(7) Maintenance Process for EDS