民間航空機の安全・開発保証プロセスについて · mitsubishi aircraft corp....

- 1 - NAM06739NC MITSUBISHI AIRCRAFT CORP. PROPRIETARY

民間航空機の安全・開発保証プロセスについて

第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とのハーモナイゼーションが進行中


耐空性基準の背景 – 故障発生確率の定義

（注）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

Engine Rotor Burst



機体レベル

機能・性能要求

システムレベル


機器レベル


機器

詳細仕様

機器ﾚﾍﾞﾙ

検証試験

ｿﾌﾄｳｪｱ／

ﾊｰﾄﾞｳｪｱ

単体検証

システムレベル

検証試験

機体レベル

検証試験 Verification

Verification

Verification

Validation

Validation

機体システムのレベルにおいて機能・性能の検証を実施


Top Down

Safety

Requirements

Development

&

Validation

Bottom Up

Safety

Requirement

s

Verification

AR

P 4

75

4

DO

-178B

ARP4754 ：機体システム全般の開発保証

DO-178B/DO-254 ：ｿﾌﾄｳｪｱ / AEH (Airborne Electronic Hardware）の開発保証


出典；SAE ARP4754 REV.A


航空機という巨大システムにおける、全ての装備品の設計要求を管理する。特に、機体メーカ／サプライヤ間などの「会社間」の要求が正しくトレースされていることに注意を払う必要あり。

設計要求は全てトレース（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 品質管理活動記録の作成と提出 ◎ ◎ ○ ○

*PSAC :Plan for Software Aspects of Certification


AR

P 4

75

4

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（品質保証）

民間航空機の安全・開発保証プロセスについて · mitsubishi aircraft corp....

Documents

Transcript of 民間航空機の安全・開発保証プロセスについて · mitsubishi aircraft corp....