民間航空機の安全性 民間航空機は 開発時の型式証明に始まり 運航フェース での耐空性を維持するためのマニアル類の評価など 航空機ライフサイクに渡る活動を通して安全性を担保 更に近年では 各社に航空安全管理体制の構築を要求 型式証明取得 ;1 機毎の耐空証明取得検査にて 設計 製造過程検査を省略できる

Transcription

1 公開用抜粋版 民間航空機の安全 開発保証プロセスについて - MRJ 開発における取組み - 第 11 回クリティカルソフトウェアワークショップ January 16, 2014 三菱航空機株式会社技術本部開発保証部 篠田和英 - 1 -

2 民間航空機の安全性 民間航空機は 開発時の型式証明に始まり 運航フェース での耐空性を維持するためのマニアル類の評価など 航空機ライフサイクに渡る活動を通して安全性を担保 更に近年では 各社に航空安全管理体制の構築を要求 型式証明取得 ;1 機毎の耐空証明取得検査にて 設計 製造過程検査を省略できる 型式証明 ( 航空機の型式毎に実施 ) 耐空証明 (1 機毎に実施 ) 耐空性基準 ( 以下参照 ) への適合性検査を行い 国交省大臣が認可 証明 航空機が安全に飛行できること 音がうるさくないこと エンジンから環境に悪いものが出ないこと 耐空性維持 設計の検査 技術基準 ( 安全性 環境適性 ) に適合する設計か 製造過程の検査 設計通りに製造されているか 初回耐空証明 (1 機毎 ) 設計通りの性能が発揮され 最終的に技術基準に適合しているか 運航 ( 使用開始 ) 定期的整備 / 改造 2 回目以降の耐空証明 AEG(Aircraft Evaluation Groups) 活動により運航を評価改善 運航 ( 使用 ) 航空安全管理体制 SMS:Safety Management System - 2 -

3 型式証明と耐空証明耐空証明 = 型式証明 ( 共通の検査 )+ 機体毎の検査共通の検査機体毎の検査 設計検査 製造過程検査 耐空証明書 耐空証明書 機体メーカが証明書を取得 型式証明書 機体所有者が証明書を取得 耐空証明書 - 3 -

4 設計検査と耐空性基準 航空法により耐空性基準を満たすことが求められる MRJ を世界で販売 運航するためには 日本 / 米国 / 欧州の型式証明取得が必要 法 Law Law 耐空性審査要領 14CFR PART25 CS PART25-4 -

5 型式証明取得プロセス 全開発過程及びカスタマーサポートを含む安全性の証明 市場要求 カスタマー サポート 風洞試験 クーポン試験 部分構造試験 構想設計 基本設計 解析ツール 細部設計 全機とりまとめ 規定 標準 スペック デジタルエンジニアリング 試作 生産 納入 全機試験 ( 飛行試験等 ) 飛行試験シミュレータ試験全機静強度試験全機疲労 損傷許容性試験 試作 工作試験 システムリグ試験 - 5 -

6 システムの安全性と耐空性基準 航空当局が定めた耐空性基準の中で 想定される故障状態 (Failure Condition) の影響度 (Severity: リスクの大きさ ) に応じた許容発生確率を規定 搭載システムの複雑化 デジタル制御化に伴い 近年では従来の確率論的な安全性評価 (Safety Assessment) に加え 開発保証 (Development Assurance) の考え方が重要となってきている 故障状態 (Failure Conditions) 故障 (Failure) 想定され得る物理的な故障 = 発生確率が算出できるもの 安全性解析 評価により 安全性を担保 エラー (Error) 開発段階で発生し得るエラー = 発生確率が算出できないもの 開発保証 ( プロセス ) により 安全性を担保 - 6 -

7 耐空性基準 - システム安全性 開発保証 民間航空機装備品の安全性に関する規定の例 FAR (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 (b) 航空機の continued safe flight and landing を妨げるような故障状態の発生は extremely improbable ( 発生確率が1x 10-9 /hr 以下 ) であること 航空機の性能や, 不利な運用条件に対し乗組員が対処する能力を低下させるような故障状態の発生は improbable ( 発生確率が1x 10-5 /hr 以下 ) であること 民間航空機装備品の開発保証に関する規定の例 FAR (a) 各装備品は所要の機能 (Intended Function) を発揮する種類及び設計でなければならない FAR (a) 装備品 系統及び装備は 予想されるすべての運用条件下において 所要の機能 (Intended Function) を発揮するように設計し かつ 装備しなければならない - 7 -

8 耐空性基準の背景 影響度の定義 用語 FAA EASA AC A AMC 用語の定義 N/A No Safety Effect 安全性に何ら影響を与えない故障状態 機体の運行性能に影響なし 乗員のワークロードの増加なし Minor Major Severe Major Catastrophic Minor Major Hazardous Catastrophic 機体の安全性を大きく低減せず 乗員の能力の範囲内で容易に対処できる故障状態 わずかな安全余裕または機能の低減 わずかな乗員のワークロード増加 乗客の不便 (FAA) 乗客又は乗員の身体的不快感 (EASA) 機体の性能や 不利な運用条件に対し乗員が対処する能力を低下させる故障状態 重大な安全余裕または機能の低減 重大な乗員のワークロード増加 乗客の不快感 (FAA) パイロットの不快感又は乗客, 乗員の身体的な苦痛 ( けがを含む )(EASA) 機体の性能や 不利な運用条件に対し乗員が対処する能力を低下させる故障状態 著しい安全余裕または機能の低減 乗員の正確で完全な作業遂行を妨げるような高いワークロードまたは肉体的苦痛 乗客への有害な影響 (FAA) パイロットを除く, 少数の乗客又は乗員の重傷又は致命傷 (EASA) 安全な飛行及び着陸を妨げる故障状態 (FAA) 機体損失を伴い, 多数の死者が出るであろう故障状態 (EASA) ( 注 )FAA Draft AC (Arsenal Version) により EASA とのハーモナイゼーションが進行中 - 8 -

9 耐空性基準の背景 故障発生確率の定義 用語 用語の定性的 / 定量的定義 FAR Part25 (AC A) EASA CS-25 (AMC ) Probable Failure Improbable Failure Remote Failure Extremely Remote Failure Extremely Improbable Failure 個々の機体の運用寿命の間に 1 回以上発生が予想さ れる故障 1.0E-5 < 発生確率任意に選んだ1 機の機体の運用寿命の間には発生しないと予想されるが 特定機種の全生産機の運用寿命の間には時々発生すると予想される故障 1.0E-9 < 発生確率 1.0E-5 N/A N/A 特定機種の全生産機の運用寿命の間に発生することが予想できない故障 発生確率 < 1.0E-9 同左 N/A 個々の機体の運用寿命の間には発生しないと予想されるが 特定機種の多くの機体の運用寿命の間には数回発生し得る故障 1.0E-7 < 発生確率 1.0E-5 個々の機体の運用寿命の間には発生しないと予想されるが 特定機種の全生産機の運用寿命の間には数回発生し得る故障 1.0E-9 < 発生確率 1.0E-7 同左 ( 注 )FAA Draft AC (Arsenal Version) により EASA とのハーモナイゼーションが進行中 - 9 -

10 エラーへの対処 - DAL (Development Assurance Level) 発生確率が定義できない要因への対処 ( 例 ) ソフトウェア開発中のエラー ( バグ等 ) DAL (Development Assurance Level) 開発プロセスに要求される厳格さの指標 DALに応じ 必要な開発保証活動の内容を設定 大 開発プロセスに要求される厳格さ 出典 ;SAE ARP4754 REV.A 小

11 システムの安全性 開発保証に対する耐空性基準 Probability (Quantitative) Probability (Descriptive) Failure Condition Severity Classification FAA EASA FAA EASA Per flight hour e-3 1.0e-5 1.0e-7 1.0e-9 Probable Frequent Minor Minor Reasonably Probable Improbable Remote Major Major Extremely Remote Severe Major Hazardous Extremely Improbable Extremely Improbable Catastrophic Catastrophic Failure Condition Effect FAA & EASA - slight reduction in safety margins - slight Increase in crew workload - some inconvenience to occupants 異常時の影響度 ( Severity) に応じて Development Assurance Level (DAL) が決まり 必要なソフトウェア品質保証活動の内容が決まる 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 Level C Level B Level A

12 安全 開発保証プロセスのガイドライン Intended Aircraft Function Aircraft System Development Process Hardware Lifecycle Process Software Lifecycle Process 安全 開発保証に関する Guideline Document Function, Failure, and Safety Information 安全性評価プロセス (SAE ARP 4761) Functions & Requirements System Design システム開発保証プロセス (SAE ARP 4754) Implementation ハードウェア (AEH) 開発保証プロセス (RTCA/DO-254) ソフトウェア開発保証プロセス (RTCA/DO-178B) Functional System 安全性評価プロセス 各機器 / 搭載 Software の安全性への影響を評価 影響度 (Severity) に応じて Complex Hardware / Software に対する開発品質要求レヘ ルが設定される システム開発保証プロセス 機体レヘ ル システム レヘ ル 機器レヘ ル Software レヘ ルへと 機能 / 性能要求をフ レイクタ ウン設定 全ての要求に関して Completeness( 抜けが無いこと ) Correctness( 妥当であること ) が求められる ソフトウェア開発保証プロセス 所望の Software 開発品質要求を満たすことを示す為のカ イト ライン Software 開発計画 開発フ ロセス 形態管理 品質管理 検証フ ロセス等に関する具体的な活動内容が定義されている 民間航空機搭載ソフトウェアの品質を担保する為の 事実上唯一のカ イト ライン

13 安全性評価プロセス DONE Minor DONE Major Proposed System Design FHA FMEA FTA ZA Cat. Haz. Verify Redunda ncy Claims Final System Design 出典 :Page, Gillette, Hodgkinson, Preston, "Quantifying the Pilot's Contribution to Flight Safety", 1992 Redesign (Typically Add Redundancy) P(Hazard) 10-9 Redesign (Typically Relocate to Restore Redundancy) Unacceptable Common-mode Failures 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 の一部 1 つの要因により複数の機能が同時に喪失しないことを確認

14 安全性評価プロセス - ZA(Zonal Analysis) の例 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 Fan Blade Release Envelope Typical Blade Swath Failure: Uncontained fan blade release Engine Rotor Burst Worst Case Result: Loss of 1 elevator & possible damage to opposite engine. Conclusion: Adequate cable separation exists. 出典 :Page, Gillette, Hodgkinson, Preston, "Quantifying the Pilot's Contribution to Flight Safety",

15 システム開発保証プロセス 機体レベル機能 性能要求 Verification 機体レベル検証試験 Validation システムレベル機能 性能要求 Verification システムレベル検証試験 Validation 機器レベル機能 性能要求 Verification 機器レヘ ル検証試験 機器詳細仕様 ソフトウェア / ハート ウェア単体検証 機体システムのレベルにおいて機能 性能の検証を実施

16 システム開発保証プロセス ARP4754 : 機体システム全般の開発保証 DO-178B/DO-254 : ソフトウェア / AEH (Airborne Electronic Hardware) の開発保証 Top Down Safety Requirements Development & Validation 出典 ;SAE ARP4754 REV.A Bottom Up Safety Requirement s Verification ARP 4754 DO-178B

17 航空機という巨大システムにおける 全ての装備品の設計要求を管理する 特に 機体メーカ / サプライヤ間などの 会社間 の要求が正しくトレースされていることに注意を払う必要あり 設計要求は全てトレース (Requirements Capture) され 抜け / 漏れなく かつ 正しい内容であることを証明する必要あり (Completeness & Correctness) 航空機業界では 要件管理ツールとして DOORS の使用が標準的 全ての設計要求におけるトレース妥当性を 以下のうちいずれかの手法により検証 (Validation) しなければならない Test Analysis Engineering Review 等 ソフトウェア不適合の原因は 上位文書のエラーにあることが多い 製品を検証 (Verification) する際には 機器レベルの試験 システム開発保証プロセス 機器を組み合わせたシステム レベルの試験 (Iron Bird など ) 機体として飛行試験 の順に 積み上げ式の検証を行うのが一般的

18 MRJ における具体例 (Fly-By-Wire システム ) (A-1) 全ての飛行条件において 60[deg] ハ ンク変化を X1 [sec] 以内に達成できること (A-2) 全ての飛行条件において 最大ロールレートが X2 [deg/s] 以下であること (A-3) 操縦システムが機能喪失する確率は 10^(-9) / FLT Hr より小さいこと 飛行試験 & 安全性解析 Verification (Aircraft Level) FBW 操縦システムを採用 (S-1) Pilot 入力に応じて駆動される舵面の角度を自動調整する機能を有すること (S-2) 対気情報に応じて舵角を自動変動させること (S-3) Pilot 入力から舵面が動き出すまでの時間遅れは Y1 [sec] 以下であること (S-4) 対気センサが故障した場合でも 安全に飛行を継続する能力が確保できること 等々 コントローラ冗長度 / テ ータ通信方式等を設定 操縦 RIG 装置 Verification (System Level) (E-1) 対気センサ情報を遅れ時間 Z1 [sec] 以下で取り込むこと (E-2) Pilot 入力 Aileron 舵面の比率は 対気情報に応じて指定の図に示す特性であること等々 FBW コントローラに対する要求トレースの例 コントローラ詳細仕様を設定 コントローラ担当サプライヤによるソフトウェア / ハードウェア開発 コントローラ単体 Verification (Equipment Level)

19 Planning Standards / Rules ソフトウェア開発保証プロセス Software 開発時に要求される主な活動 開発 / 検証 / 形態管理等に関する計画書 (PSAC*) の作成と提出 要求仕様 /Coding 方法等に関する規定の設定と提出 Software DAL A B C D Verification 検証方法 / 検証結果記録の提出 Records in Entire Life Cycle Configuration Management 開発期間中に発生した不適合記録等の作成と提出 形態管理記録所の作成と提出 Quality Assurance 品質管理活動記録の作成と提出 : 厳密 / 詳細な活動が求められる : 活動が求められる例 :Level Aの場合 以下の全てに対して100% Coverageの検証が求められる 要求のトレーサビリティ カバレッジ コード カバレッジ MC/DC(Modified Condition / Decision Coverage) *PSAC :Plan for Software Aspects of Certification

20 ソフトウェア開発保証プロセス 民間機開発における DO-178 カ イト ラインに従ったソフトウェア開発は サフ ライヤの責任範囲 型式証明 (Type Certification) 取得には 機体メーカが審査当局 (Authority) に対して DO- 178 カ イト ラインに従ってソフトウェア開発が行われていることを説明する必要有 機体メーカのソフトウェア エンシ ニアは サフ ライヤが DO-178 カ イト ラインに従って開発していることを Audit にて 監査 し 要すれば是正させる必要有 開発フェース に応じた 複数回の Audit を実施 SOI #1 Planning Audit 機器レベル要求仕様 ソフトウェア要求仕様 ソフトウェア設計 ソフトウェア単体検証試験 ソフトウェア結合検証試験 ソフトウェア / ハードウェア結合検証試験 SOI #3 Test Audit ARP 4754 DO-178B SOI #2 Requirement / Design / Codig Audit コーディング SOI : Stage Of Involvement( 次頁参照 )

21 SOI (Stage Of Involvement) (1/2) DO178B に従い 開発のプロセス ライフサイクル過程 を忠実に実施する サプライヤの活動状況を Life Cycle Data の Review と Audit で確認する SOI(Stage Of Involvement)Audit #1~#4: 各開発段階での実施内容検証 ソフトウェアのエラー存在率は バスタブ型を示すハードウェアとは 全く異なった第一象限双曲線型であり 原理的には次のような性質のものである ソフトウェア全体を覆い尽くして あらゆるケースを動作経験してエラーを発見し正していけば エラーは排除される エラーは原型作成過程において発生し内蔵されており 確率的に発生するものではない 量産において エラーが入り込む機会はない ( インストールの手順も規定され確立されている場合 ) System Development Planning Process Requirement Process Design Process Coding Process Integration Process Planning Docs. & Design Standards Verification High Level Requirement Verification Low Level Requirement Verification of Source Code Testing Conformity Planning 2 Requirement Design Coding Test Audit Audit Audit Audit Audit SOI #1 SOI #2 SOI #3 SOI #4-21 -

22 SOI (Stage Of Involvement) (2/2) 1 SOI レヒ ューのホ イント サフ ライヤの定めた開発計画や設計標準を忠実に実行していることを確認する Planning Audit サフ ライヤの QA 部門が承認し 形態管理されていること 計画に従い開発を実施するためのフ ロセスとシステムが明確であること 2 Requirement Audit Design Audit Coding Audit ソフトウェア要求仕様のカハ レッシ 100% が確認されていること 標準に従い 要求の評価が実施され レヒ ューされていること アーキテクチャが定義され 妥当性の検討結果を標準に従いレヒ ューしていること 上位要求と下位要求のトレースを標準に従いレヒ ューしていること インタフェースやタイミンク の検討とそのレヒ ューが 標準に従い実施されていること Coding 標準に従った開発をしていることを レヒ ューで確認していること 問題が発生した時の処置が標準に従い管理されていること 3 Test 標準に従った検証をしていることをレヒ ューで確認していること Audit 問題が発生した時の処置が標準に従い管理されていること ( 特に Safety に関する影響範囲の検討が抜けなく実施されていること )

23 価値の創造 乗客 快適な客室 環境 少ない排出物と低騒音 エアライン 優れた経済性 MRJ を世界の空へ 安全 開発保証プロセスに沿った品質の創り込み 航空機の安全性 Safety Assurance ( 安全性解析 ) Validation & Verification ( 検証と妥当性確認 ) Configuration Management ( 形態管理 ) 型式証明の取得 Process Assurance ( プロセス保証 ) Quality Assurance ( 品質保証 )