民間航空機の安全・開発保証プロセスについて
第11回クリティカルソフトウェアワークショップ January 16 , 2014 三菱航空機株式会社 技術本部 開発保証部 篠田 和英 NAM06739NC- MRJ
開発における取組み
-
公開用抜粋版
民間航空機の安全性
設計の 検査 製造過程 の検査 初回 耐空証明 （1機毎） 運航 （使用開始） 運航 （使用） 定期的整備 /改造 2回目 以降の 耐空証明耐空性維持
耐空証明
（1機毎に実施）型式証明
（航空機の型式毎に実施） 技術基準（安全性・ 環境適性）に適合す る設計か 設計通りに製造さ れているか 設計通りの性能が発 揮され、最終的に技術 基準に適合しているか 耐空性基準（以下参照）への適合性検査を 行い、国交省大臣が認可・証明 ・航空機が安全に飛行できること ・音がうるさくないこと ・エンジンから環境に悪いものが出ないこと 型式証明取得；1機毎の耐空証明 取得検査にて、設計、製造過程 検査を省略できる。AEG(Aircraft Evaluation Groups)活動に より運航を評価改善
航空安全管理体制
SMS:Safety Management System
民間航空機は、開発時の型式証明に始まり、運航ﾌｪｰｽﾞでの耐空性を維持するための
ﾏﾆｱﾙ類の評価など、航空機ﾗｲﾌｻｲｸに渡る活動を通して安全性を担保。
型式証明と耐空証明
機体毎の検査
共通の検査
設計検査
製造過程検査
型式証明書 耐空証明書 耐空証明書 耐空証明書機体メーカが
証明書を取得
機体所有者が
証明書を取得
耐空証明＝型式証明（共通の検査）＋機体毎の検査
設計検査と耐空性基準
航空法により耐空性基準を 満たすことが求められる 耐空性審査要領≒
14CFR PART25 法 Law CS PART25 Law≒
MRJを世界で販売・運航するためには、日本/米国/欧州 の型式証明取得が必要型式証明取得プロセス
風洞試験 基 本 設 計 細 部 設 計 試作・生産 納入 構 想 設 計 サポート 市場 要 求 全 機 試 験 （ 飛 行 試 験 等 ） 部分構造試験カスタマー
全 機 と り ま と め 飛行試験 シミュレータ試験 全機静強度試験 全機疲労・損傷許容性試験 解析ツール デジタル エンジニアリング 規定・標準・スペック システムリグ試験 クーポン試験 試作・工作試験 全開発過程及びカスタマーサポートを含む安全性の証明
システムの安全性と耐空性基準
航空当局が定めた耐空性基準の中で、想定される故障状態（Failure
Condition）の影響度（Severity：リスクの大きさ）に応じた許容発生確率を
規定。
搭載システムの複雑化・デジタル制御化に伴い、近年では従来の確率論
的な安全性評価（Safety Assessment）に加え、開発保証（Development
Assurance）の考え方が重要となってきている。
故障状態 （Failure Conditions）
故障 （Failure）
想定され得る物理的な故障 ＝ 発生確率が算出できるもの
⇒
安全性解析・評価により、安全性を担保
エラー （Error）
開発段階で発生し得るエラー ＝ 発生確率が算出できないもの
⇒
開発保証（プロセス）により、安全性を担保
耐空性基準
- システム安全性・開発保証
【民間航空機 装備品の安全性に関する規定 の例】 FAR 25.671 (c)
以下の故障が発生しても、“exceptional piloting skill or strength”なしに“continued safe
flight and landing”が可能であること。 全ての単一故障
“extremely improbable” (発生確率が1x 10-9/hr以下）であると証明できない全ての故
障状態の組合せ
操縦系統のジャミング
“probable” (発生確率が1x 10-5/hr以上）な故障は“only minor effect”しか与えぬこと。
FAR 25.1309 (b)
航空機の“continued safe flight and landing”を妨げるような故障状態の発生は“extremely
improbable” (発生確率が1x 10-9/hr以下）であること。 航空機の性能や，不利な運用条件に対し乗組員が対処する能力を低下させるような故障 状態の発生は“improbable” (発生確率が1x 10-5/hr以下）であること。 【民間航空機 装備品の開発保証に関する規定 の例】 FAR 25.1301 (a) 各装備品は所要の機能 (Intended Function)を発揮する種類及び設計でなければならない。 FAR 25.1309 (a) 装備品、系統及び装備は、予想されるすべての運用条件下において、所要の機能 (Intended Function) を発揮するように設計し、かつ、装備しなければならない。 機種全体の全運用時間を想定しても、ほとんど発生しない
耐空性基準の背景
– 影響度の定義
FAA EASA
AC 25.1309-1A AMC 25.1309
N/A No Safety Effect
安全性に何ら影響を与えない故障状態。 ・機体の運行性能に影響なし ・乗員のワークロードの増加なし Minor Minor 機体の安全性を大きく低減せず、乗員の能力の範囲内で容易に対処できる故障状態。 ・わずかな安全余裕または機能の低減 ・わずかな乗員のワークロード増加 ・乗客の不便（FAA） ・乗客又は乗員の身体的不快感（EASA） Major Major 機体の性能や、不利な運用条件に対し乗員が対処する能力を低下させる故障状態。 ・重大な安全余裕または機能の低減 ・重大な乗員のワークロード増加 ・乗客の不快感（FAA） ・パイロットの不快感又は乗客，乗員の身体的な苦痛（けがを含む）（EASA）
Severe Major Hazardous
機体の性能や、不利な運用条件に対し乗員が対処する能力を低下させる故障状態。 ・著しい安全余裕または機能の低減
・乗員の正確で完全な作業遂行を妨げるような高いワークロードまたは 肉体的苦痛 ・乗客への有害な影響（FAA）
・パイロットを除く，少数の乗客又は乗員の重傷又は致命傷（EASA）
Catastrophic Catastrophic 安全な飛行及び着陸を妨げる故障状態。(FAA)
機体損失を伴い，多数の死者が出るであろう故障状態。(EASA) 用語
用語の定義
耐空性基準の背景
– 故障発生確率の定義
（注）FAA Draft AC 25.1309（Arsenal Version）により、EASAとのハーモナイゼーションが進行中 FAR Part25 （AC 25.1309-1A） EASA CS-25 （AMC 25.1309） Probable Failure 個々の機体の運用寿命の間に１回以上発生が予想さ れる故障。 同 左 Improbable Failure 任意に選んだ１機の機体の運用寿命の間には発生し ないと予想されるが、特定機種の全生産機の運用寿 命の間には時々発生すると予想される故障。 N/A Remote Failure N/A 個々の機体の運用寿命の間には発生しないと予想さ れるが、特定機種の多くの機体の運用寿命の間には 数回発生し得る故障。 Extremely Remote Failure N/A Extremely Improbable Failure 特定機種の全生産機の運用寿命の間に発生すること が予想できない故障。 同 左 用語 用語の 定性的/定量的 定義 個々の機体の運用寿命の間には発生しないと予想さ れるが、特定機種の全生産機の運用寿命の間には 数回発生し得る故障。 1.0E-5 ＜ 発生確率 1.0E-9 ＜ 発生確率 ≦ 1.0E-5 1.0E-7 ＜ 発生確率 ≦ 1.0E-5 1.0E-9 ＜ 発生確率 ≦ 1.0E-7 発生確率 ＜ 1.0E-9
エラーへの対処
- DAL (Development Assurance Level)
発生確率が定義できない要因への対処
（例）ソフトウェア開発中のエラー （バグ等）
DAL (Development Assurance Level)
開発プロセスに要求される厳格さの指標
DALに応じ、必要な開発保証活動の内容を設定
開発プロセス に要求される 厳格さ 大 小 出典；SAE ARP4754 REV.Aシステムの安全性・開発保証に対する耐空性基準
Probability(Quantitative)
Per flight hour FAA EASA Reasonably Probable FAA EASA Failure Condition Effect FAA & EASA - - - - - - significant reduction in safety margins or functional capabilities significant Increase in crew workload or in conditions Impairing crew efficiency some discomfort to occupants - - - large reduction in safety margins or functional capabilities higher workload or physical distress such that the crew could not be relied upon to perform tasks accurately or completely adverse effects upon occupants - all failure conditions which prevent continued safe flight and landing Development Assurance Level ARP 4754 DO-178B DO-254 Level D
slight reduction in safety margins slight Increase in crew workload
some inconvenience to occupants
Level A Level B Level C Extremely Improbable Frequent Minor Minor Extremely Remote Severe Major Hazardous Extremely Improbable Catastrophic Catastrophic Major Major Remote Failure Condition Severity Classification Probability (Descriptive) Improbable Probable
1.0 1.0e-3 1.0e-5 1.0e-7 1.0e-9
異常時の影響度 ( Severity)に応じて、
Development Assurance Level (DAL)が決まり、必要なｿﾌﾄｳｪｱ品質保
Function, Failure, and Safety Information Intended Aircraft Function System Design Functions & Requirements
安全・開発保証に関する
Guideline Document
安全性評価プロセス （SAE ARP 4761） システム開発保証プロセス （SAE ARP 4754） ソフトウェア 開発保証プロセス （RTCA/DO-178B） ハードウェア（AEH） 開発保証プロセス （RTCA/DO-254） Implementation Aircraft System Development Process Hardware Lifecycle Process Software Lifecycle Process Functional System 【安全性評価プロセス】 各機器／搭載Softwareの安全性への影響を 評価。 影響度（Severitｙ）に応じて、Complex Hardware / Softwareに対する開発品質要求 ﾚﾍﾞﾙが設定される。 【システム開発保証プロセス】 機体ﾚﾍﾞﾙ → ｼｽﾃﾑ・ﾚﾍﾞﾙ → 機器ﾚﾍﾞﾙ → Softwareﾚﾍﾞﾙへと、機能／性能要求をﾌﾞﾚｲｸ ﾀﾞｳﾝ設定 全ての要求に関して、 Completeness（抜けが無いこと） Correctness（妥当であること） が求められる。 【ソフトウェア開発保証プロセス】 所望のSoftware開発品質要求を満たすことを 示す為のｶﾞｲﾄﾞﾗｲﾝ。 Software開発計画、開発ﾌﾟﾛｾｽ、形態管理、 品質管理、検証ﾌﾟﾛｾｽ等に関する具体的な活 動内容が定義されている。 民間航空機 搭載ｿﾌﾄｳｪｱの品質を担保する為 の、事実上唯一のｶﾞｲﾄﾞﾗｲﾝ。安全・開発保証プロセスのガイドライン
出典：Page, Gillette, Hodgkinson, Preston, "Quantifying the Pilot's Contribution to Flight Safety", 1992 Proposed System Design Redesign (Typically Add Redundancy) Redesign (Typically Relocate to Restore Redundancy) Final System Design Verify Redunda ncy Claims DONE DONE “Minor ” “Major”
FHA FMEA FTA ZA
Unacceptable Common-mode Failures P(Hazard)≧10-9 “Haz. ” “Cat.”
FHA : Functional Hazard Analysis
機能上の異常事象を抽出して、機体に及ぼす影響と致命度を評価し、信頼度要求を設定 FMEA : Failure Mode and Effect Analysis
構成要素の故障モードを洗い出し、機体への影響を評価（ボトムアップ手法） FTA : Fault Tree Analysis
FHA/FMEAで抽出された異常事象のうち、影響度が“Hazardous”以上のアイテムに対し Fault Treeを作成し、発生確率を算出（トップダウン手法）
ZA : Zonal Analysis 【CCA : Common Cause Analysisの一部】 １つの要因により複数の機能が同時に喪失しないことを確認
安全性評価プロセス
- ZA（Zonal Analysis）の例
出典：Page, Gillette, Hodgkinson, Preston,
"Quantifying the Pilot's Contribution to Flight Safety", 1992
A: Primary Rudder Cables B: Left Elevator Cables
C: Redundant Rudder Cables D: Primary Stabilizer Trim Cables E: Redundant Stabilizer Trim Cables
F: Right Elevator Cables
Typical Blade Swath
Fan Blade Release Envelope
Worst Case Result: Loss of 1 elevator & possible damage to opposite engine. Conclusion: Adequate cable
separation exists.
Failure: Uncontained fan blade release
システム開発保証プロセス
機体レベル 機能・性能要求 システムレベル 機能・性能要求 機器レベル 機能・性能要求 機器 詳細仕様 機器ﾚﾍﾞﾙ 検証試験 ｿﾌﾄｳｪｱ／ ﾊｰﾄﾞｳｪｱ 単体検証 システムレベル 検証試験 機体レベル 検証試験Verification
Verification
Verification
Validation
Validation
機体システムのレベルにおいて機能・性能の検証を実施
Top Down Safety Requirements Development & Validation Bottom Up Safety Requirement s Verification A R P 4754 DO -178B
ARP4754 ：機体システム全般の開発保証
DO-178B/DO-254 ：ｿﾌﾄｳｪｱ / AEH (Airborne Electronic Hardware）の開発保証
システム開発保証プロセス
航空機という巨大システムにおける、全ての装備品の設計要求を管理する。特に、
機体メーカ／サプライヤ間などの「会社間」の要求が正しくトレースされていることに
注意を払う必要あり。
設計要求は全てトレース（Requirements Capture
）され、抜け／漏れなく、かつ、正
しい内容であることを証明する必要あり（
Completeness & Correctness
）。航空機
業界では、要件管理ツールとして”DOORS”の使用が標準的。
全ての設計要求におけるトレース妥当性を、以下のうちいずれかの手法により検証
（
Validation）しなければならない。
Test
Analysis
Engineering Review 等
ソフトウェア不適合の原因は、上位文書のエラーにあることが多い。
製品を検証（Verification）する際には、
機器レベルの試験
機器を組み合わせたシステム・レベルの試験（Iron Birdなど）
機体として飛行試験
の順に、積み上げ式の検証を行うのが一般的。
システム開発保証プロセス
MRJにおける具体例 (Fly-By-Wireシステム）
(E-1) 対気ｾﾝｻ情報を遅れ時間Z1 [sec]以下で取り 込むこと。
(E-2) Pilot入力 – Aileron舵面の比率は、対気情報 に応じて指定の図に示す特性であること等々 コントローラ担当サプライヤによる ソフトウェア／ハードウェア開発 コントローラ単体Verification (Equipment Level) (A-1) 全ての飛行条件において、60[deg]ﾊﾞﾝｸ変化を X1 [sec]以内に達成できること。 (A-2) 全ての飛行条件において、最大ﾛｰﾙﾚｰﾄがX2 [deg/s]以下であること。 (A-3) 操縦ｼｽﾃﾑが機能喪失する確率は10^(-9) / FLT Hrより小さいこと。 (S-1) Pilot入力に応じて駆動される舵面の角度を自動 調整する機能を有すること。 (S-2) 対気情報に応じて舵角を自動変動させること。 (S-3) Pilot入力から舵面が動き出すまでの時間遅れは Y1 [sec]以下であること。 (S-4) 対気ｾﾝｻが故障した場合でも、安全に飛行を継 続する能力が確保できること。 等々 飛行試験＆安全性解析 Verification (Aircraft Level) 操縦RIG装置Verification (System Level) FBW操縦 ｼｽﾃﾑを採用 ｺﾝﾄﾛｰﾗ冗長度／ ﾃﾞｰﾀ通信方式等を 設定 ｺﾝﾄﾛｰﾗ 詳細仕様を設定 FBWｺﾝﾄﾛｰﾗに対する 要求ﾄﾚｰｽの例
ソフトウェア開発保証プロセス
◎：厳密／詳細な活動が求められる ○：活動が求められる
例：Level Aの場合、以下の全てに対して100% Coverageの検証が求められる。 要求のトレーサビリティ・カバレッジ
コード・カバレッジ
MC/DC（Modified Condition / Decision Coverage)
Software開発時に要求される主な活動
Software DAL
A
B
C
D
Planning
開発／検証／形態管理等に関す
る計画書(PSAC*)の作成と提出
◎
◎
◎
○
Standards / Rules
要求仕様／Coding方法等に関す
る規定の設定と提出
○
○
○
Verification
検証方法／検証結果記録の提出 ◎
○
○
○
Records in Entire Life
Cycle
開発期間中に発生した不適合記
録等の作成と提出
○
○
○
○
Configuration
Management
形態管理記録所の作成と提出
○
○
○
○
Quality Assurance
品質管理活動記録の作成と提出
◎
◎
○
○
A R P 4754 DO -178B ｿﾌﾄｳｪｱ 要求仕様 ソフトウェア／ ハードウェア 結合検証試験 ｿﾌﾄｳｪｱ 設計 コーディング ソフトウェア 単体検証試験 機器レベル 要求仕様 ソフトウェア結合 検証試験 【SOI #1】 Planning Audit 【SOI #2】 Requirement /
Design / Codig Audit
【SOI #3】
Test Audit
民間機開発におけるDO-178ｶﾞｲﾄﾞﾗｲﾝに従ったｿﾌﾄｳｪｱ開発は、ｻﾌﾟﾗｲﾔの責任範囲。 型式証明 (Type Certification)取得には、機体ﾒｰｶが審査当局
(Authority)に対してDO-178ｶﾞｲﾄﾞﾗｲﾝに従ってｿﾌﾄｳｪｱ開発が行われていることを説明する必要有。
機体ﾒｰｶのｿﾌﾄｳｪｱ・ｴﾝｼﾞﾆｱは、ｻﾌﾟﾗｲﾔがDO-178ｶﾞｲﾄﾞﾗｲﾝに従って開発していることを、
Auditにて“監査“し、要すれば是正させる必要有。
開発ﾌｪｰｽﾞに応じた、複数回のAuditを実施。
SOI : Stage Of Involvement（次頁参照）
SOI (Stage Of Involvement) (1/2)
System Development Requirement Process Design Process Coding Process Integration Process Verification High Level Requirement Verification Low Level Requirement Verification of Source Code Testing Requirement Audit Design Audit Coding Audit Test Audit Planning Docs. & Design Standards Planning Audit Planning Process Conformity 2【SOI #1】 【SOI #2】 【SOI #3】 【SOI #4】
DO178Bに従い、開発のプロセス“ライフサイクル過程”を忠実に実施する。 サプライヤの活動状況を、Life Cycle DataのReviewとAuditで確認する。
SOI（Stage Of Involvement）Audit #1~#4：各開発段階での実施内容検証 ソフトウェアのエラー存在率は、バスタブ型を示すハードウェアとは、全く異なった第一象限双曲線 型であり、原理的には次のような性質のものである。 ソフトウェア全体を覆い尽くして、あらゆるケースを動作経験してエラーを発見し正していけば、 エラーは排除される。 エラーは原型作成過程において発生し内蔵されており、確率的に発生するものではない。 量産において、エラーが入り込む機会はない。（インストールの手順も規定され確立されてい る場合）
SOI (Stage Of Involvement) (2/2)
Requirement Audit Design Audit Coding Audit Test Audit Planning Audit 1 2 3 ｻﾌﾟﾗｲﾔのQA部門が承認し、形態管理されていること。 計画に従い開発を実施するためのﾌﾟﾛｾｽとｼｽﾃﾑが明確であること。 ｿﾌﾄｳｪｱ要求仕様のｶﾊﾞﾚｯｼﾞ１００％が確認されていること。 標準に従い、要求の評価が実施され、ﾚﾋﾞｭｰされていること。 ｱｰｷﾃｸﾁｬが定義され、妥当性の検討結果を標準に従いﾚﾋﾞｭｰしていること。 上位要求と下位要求のﾄﾚｰｽを標準に従いﾚﾋﾞｭｰしていること。 ｲﾝﾀﾌｪｰｽやﾀｲﾐﾝｸﾞの検討とそのﾚﾋﾞｭｰが、標準に従い実施されていること。 Coding標準に従った開発をしていることを、ﾚﾋﾞｭｰで確認していること。 問題が発生した時の処置が標準に従い管理されていること。 標準に従った検証をしていることをﾚﾋﾞｭｰで確認していること。 問題が発生した時の処置が標準に従い管理されていること。 （特に、Ｓａｆｅｔｙに関する影響範囲の検討が抜けなく実施されていること。）【SOIﾚﾋﾞｭｰのﾎﾟｲﾝﾄ】
ｻﾌﾟﾗｲﾔの定めた開発計画や設計標準を忠実に実行していることを確認する。
環境 少ない排出物 と低騒音 乗客 快適な客室 エアライン 優れた経済性
MRJを世界の空へ
安全・開発保証
プロセスに沿った
品質の創り込み
価値の創造
型式証明の
取得
航空機の 安全性 Process Assurance （プロセス保証） Validation & Verification（検証と妥当性確認） Configuration Management （形態管理） Safety Assurance （安全性解析） Quality Assurance （品質保証）
