Vol.54　No.2（2015）

115

1.　は じ め に

民間航空機において「安全な機体を開発する」為に必要とされるプロセスは，米国／欧州を中心に国際的な規定やガイドラインに詳細かつシステマティックに定義されている．開発時に考慮すべき重要事項を分類すると①運航中の偶発故障に代表される確率論的な事象に対する安全性確保，②ソフトウェアバグに代表される決定論的な機能不全に対する品質確保，③運航全般に関わるヒューマンエラーに対する耐性確保，④過去の運行実績で生じた異常事象に対する被害最小化方策が挙げられる．これらは全て欠かすことの出来ない重要な指標であるが，本稿では特に①確率論的な偶発故障と②決定論的な機能不全に焦点を当てMRJ操縦システムを例に挙げつつ概説する．また，主要な略語を表 1に示す．

2.　偶発故障と機能不全

民間航空機を設計／開発する上で，確率論的な偶発故障や決定論的な機能不全を効率的／網羅的に抑制するには，双方の活動を有機的に連携させつつ開発プロセスを推進する必要がある．偶発故障／機能不全の発生が問題となりうる装備品の開発は，SAEが発行するガイドラインである ARP4754 2）に基づき遂行される．

ARP4754は機体及びシステムの開発プロセスに関するガイドラインである．航空機の安全性に影響を与える設計要求（Requirement）を網羅的に管理し，飛

行安全への影響度に応じて装備品を分類し影響度に応じた解析／管理を求め，第 3者に対してエビデンスを明示できる開発プロセスの構築が求められる．民間航空機の場合，機体メーカの職掌にある要求だけでも数万件に及び，装備品メーカや下位サプライヤの扱う要求まで含めると膨大な件数を扱う事となる．それら全ての要求に高度な開発保証活動を求めることは現実的では無い為，安全性解析に基づく DALを設定し必要な活動の深度を区別する．さらに複雑な機能を実現す

総　　　説

MRJ 開発における安全性

山やま

　　口ぐち

　　恭やす

　　弘ひろ†

　民間航空機における「安全性」とは，妥協の許されない必達の要求である．いかに優れた性能／収益性を有する機体であっても，乗客の安全性を確保出来なくてはエアラインとして運航することは出来ない．民間航空機の開発においては，年々厳格化が求められる安全性要求をクリアした上で，どこまで快適性／収益性／運航性等の商品性向上を図れるかの競争となる．本稿では，YS-11以来の国産民間旅客機開発となるMRJ（Mitsubishi Regional Jet）1）を題材として取り上げつつ，民間航空機を開発する際に考慮すべき安全性について概説する．　キーワード：偶発故障，開発保証，民間航空機，ソフトウェア品質保証，操縦システム

† 三菱航空機（株）開発保証部 安全・開発保証グループ：〒 480-0287 愛知県西春日井郡豊山町 名古屋空港内E-mail：yasuhiro_yamaguti@mitsubishiaircraft.com

ACE Actuator Control ElectronicsARP Aerospace Recommended PracticeASA Aircraft Safety AssessmentCCA Common Cause AnalysisCMA Common Mode AnalysisDAL Development Assurance LevelFAR Federal Aviation RegulationFBW Fly-By-WireFHA Functional Hazard AssessmentFPGA Field Programmable Gate ArrayMC/DC Modified Condition / Decision CoverageMRJ Mitsubishi Regional JetMTBF Mean Time Between FailurePASA Preliminary Aircraft Safety AssessmentPFCC Primary Flight Control ComputerPSAC Plan for Software Aspects of CertificationPSSA Preliminary System Safety AssessmentRTCA Radio Technical Commission for AeronauticsSAE Society of Automotive EngineersSREU Spoiler Remote Electronics UnitSSA System Safety Assessment

表 1　主要な略語

安 全 工 学

116 MRJ開発における安全性

るソフトウェアや FPGAなどの Complex Hardwareには，設計不良による致命的なバグ発生を抑制する為のプロセスが求められる．図 1にこれら活動のガイドライン体系図を示す．

ARP4754を中心として，安全性解析に関するガイドラインは ARP4761 3）に，ソフトウェア／ Complex

Hardwareにおける開発保証ガイドラインはそれぞれRTCA DO-178B 4）/DO-254に示されている．

3.　機能不全の抑制と開発保証活動

決定論的な機能不全であれ確率論的な偶発故障であれ，民間航空機の安全性を議論するにはまずシステマティックな開発保証活動に関する議論が必要である．図 2にいわゆる V字開発プロセスの概要を示す．

ARP4754で推奨される開発プロセスでは，開発初期では航空機レベルから部品レベルまでトップダウン方式での設計要求管理とその「検証（Validation）」が求められる．開発後期では，逆に部品レベルから機体レベルまでボトムアップ方式で設計要求に関する「実装の検証（Implementation Verification）」が求められる．さらにそれら過程では並行して偶発故障に対する安全性評価を繰り返し行い，製品の安全性を高めていく．本項ではまず V字開発プロセスによる開発保証の詳細と，仕様設定ミスの撲滅活動に関して紹介する．3.1　トップダウン・フェーズ開発初期の「Vの左側（トップダウン・フェーズ）」では，航空機レベルでの設計要求の設定に始まり，システムレベル／部品レベルへと「要求のフローダウン」を行い，各階層の詳細要求を順に整備する．例えば航空機レベルで実現したい性能として以下を考える．着陸後の停止までの滑走距離が X［m］以下航空機の地上での減速は主として 3種のシステム・レベル機能で実現されており，それぞれに対して「性能配分」を実施する．

図 1　開発保証／安全性解析ガイドライン体系２）

図 2　V字開発プロセス２）

Vol.54　No.2（2015）

MRJ開発における安全性 117

操　　縦：Spoiler舵面による減速能力エンジン：逆推力による減速能力脚　　　：車輪ブレーキによる減速能力各システムに配分された「性能要求」は，さらに詳

細要求へとフローダウンされる．操縦システムであれば Spoiler舵面の面積，最大展開角度，舵面アクチュエータ作動速度などへと分解され，詳細仕様が設定される．その後，設定した要求を Validateする事で要求の妥当性を確認する．上記の例では設定した Spoiler

舵面の性能により，最終的に機体の滑走距離要求を満足できる見通しであることを解析する作業となる．これら Validation活動の特徴及び主な留意点を挙げ

ると以下となる．（ 1）要求は，基本的に上位要求及び下位要求と紐づいている（リンクしている）必要がある．リンクしていない場合は「派生要求（Derived Requirement）」と識別され，その存在の妥当性を明示する必要がある．（ 2）上位リンクの妥当性を示す Validationエビデンスを準備する必要がある．各要求が安全性に与える影響度合いを後述する DALとして識別し，DALに応じた詳細度のエビデンスが求められる．例えば機能不全時に致命的な影響を与えかねない要求の場合，上位リンクの妥当性を Test /Analysis/ Modeling等で明示する必要がある．（ 3）Validationチェックは，要求設定者とは異なる独立した人物の遂行が求められる．さらに Validationチェックは正確性チェックと網羅

性チェックに細分化される．【正確性チェック】要求毎の「正確さ」を確認する．具体例は以下．・1文に 1要求が述べられているか？・曖昧さが無く明確な要求か？（複数の解釈が出来る内容ではダメ）

・検証（Verification）可能な要求か？・安全性解析の結果を安全派生要求（Derived

Safety Requirement）として正しく反映しているか？【網羅性チェック】必要な要求が網羅されている事の確認であるが，網

羅性を完全に証明する事は難しい．その為，下記に例を示すチェック項目を用いた有識者によるレビューを通じて実施されるのが一般的である．・本要求の実現により上位要求を達成できるか？・規定／ガイドライン／スタンダード等の一般的に必要とされる内容をカバーしているか？

・実現すべき機能をハードウェア／ソフトウェア等に明確に割り付けているか？

・必要な全てのインターフェース要求は定義されて

いるか？何万もの要求を扱う航空機開発において，上述の

Validation活動を行いかつエビデンスを準備するには多大な労力を要する．しかしながら，開発初期に要求を十分吟味／確認しておく事は結果的に航空機の安全性を担保するだけでなく，作業の出戻りを抑制し巨大システム開発の費用と期間の低減につながる．3.2　ボトムアップ・フェーズさて次に「Vの右側（ボトムアップ・フェーズ）」

における要求の「実装の検証（Implementation

Verification）」について紹介する．本過程では，各レベル（機器レベル／システムレベル／機体レベル）において要求が正しく機器に実装されている事を確認していく．特に DALが高く機能不全時に安全性に及ぼす影響の大きい要求においては，最初の段階でVerification Planを設定し各要求に対する Verification

Methodを下記例から選択する．・Inspection or Review

・Analysis

・Modeling

・Test or Demonstration

ここでも DALが高い要求に対しては Testと，さらに も う 一 つ の Verification 実 施 が 推 奨 さ れ る．Verification結果は Verification Matrix及び Verification

Summaryとして文書化され，開発保証活動におけるエビデンスとなる．

4.　確率論的　偶発故障への対処

本項では偶発的事象と分類される確率論的故障に関して説明する．確率論的故障に対しては，規定

（Regulation）5）により定義された定量的な信頼性要求が存在する．米国で用いられている FARによると，装備品，特に操縦システムに課される代表的な安全性に関する規定の例は以下となる．

FAR Sec. 25.671（抜粋）（c） The airplane must be shown by analysis, tests, or

both, to be capable of continued safe flight and landing

after any of the following failures or jamming in the

flight control system and surfaces, within the normal

flight envelope, without requiring exceptional piloting

skill or strength.

（1）Any single failure.　（以下，省略）FAR Sec. 25.1309（抜粋）（b）T h e a i r p l a n e s y s t e m s a n d a s s o c i a t e d

components, considered separately and in relation to

other systems, must be designed so that--

（1）The occurrence of any failure condition which

安 全 工 学

118 MRJ開発における安全性

would prevent the continued safe flight and landing of

the airplane is extremely improbable, and

（2）The occurrence of any other failure condition

which would reduce the capability of the airplane or the

ability of the crew to cope with adverse operating

conditions is improbable．FARに対する適合手法例を示す Advisory Circular 6）

の内容も勘案しつつ上記規定を解釈すると，以下のように記述する事が出来る．（1） 以下の故障が発生しても，“exceptional piloting

skill or strength” な し に “continued safe flight

and landing” が可能であること．（a）全ての単一故障（b） “extremely improbable” （発生確率が 10-9／時

より小さい）と証明できない全ての故障状態の組合せ

（2） 航空機の性能や，不利な運用条件に対し乗組員が対処する能力を低下させるような故障状態の発生は “improbable” （発生確率が 10-5／時より小さい）であること．

上記の通り，民間航空機の操縦システム等の装備品において，多数の死傷者を出すような Catastrophic

Eventを引き起こす恐れのある場合は冗長設計が求められるだけでなく，その故障の発生確率が 10-9／時より小さいことが求められる．さらに，航空機の性能や乗務員の対処能力の低下を伴う故障状態の発生確率も，10-5／時より小さくなければならない．民間航空機が型式証明を取得するには，これら規定

に対する適合性を網羅的に解析し規定適合性をエビデンスとして提示する必要がある．航空機という巨大システムにおける解析作業は膨大であるが，その標準的な作業プロセスは ARP4754/4761に示されている．図 2に示す通り，機体レベルであれシステムレベル

であれ，まずは実現する機能（Function）に対するFHA（Functional Hazard Assessment）と呼ばれる分析を実施する．FHAでは割り当てられた機能の全ての異常／停止状態を想定し，発生しうる Hazard事象を網羅的に洗い出す．抽出された故障事象（Failure

Condition）に対し，飛行安全に及ぼす影響を分析しSeverityと呼ばれる 5段階の影響度を設定する．・Catastrophic：複数の死傷者を生じ，多くの場合機体の喪失につながる故障事象

・Hazardous：少数ではあるが致命的な負傷者が生じるか，航空機の性能や不利な運用条件に対する乗組員の対処能力が著しく低下する故障事象

・Major：負傷者が発生じるか，航空機の性能や不利な運用条件に対する乗組員の対処能力が低下す

る故障事象・Minor：航空機の性能や不利な運用条件に対する乗組員の対処能力がわずかに失われる故障事象・No Safety Effect：安全性に対する影響がほとんどない故障事象それぞれの故障事象は，分類された Severityに応じて飛行時間 1時間当たりの定量的な故障発生確率が

表 2の通り要求される．

上記の故障発生確率要求は，Fault Tree Analysis

（FTA）を活用した Aircraft/System Safety Assessment

（ASA/SSA）において達成度合いを評価する．特に開発初期における本活動の成果は，Preliminaryな ASA/

SSA と し て，PASA/PSSA に 記 述 さ れ る． ま た，Catastrophic事象が単独故障により発生しない事の確認も FTAに基づき実施される．FTA解析は基本的にMajor以上の全ての故障事象に対して実施し，かつ部品レベルまでのブレイクダウンが必要となる為，解析書は膨大なページ数に及ぶ文書となる．（P）ASA/（P）SSAが果たす別の重要な役割の一つに，DALアサインがある．DALアサイン作業では，FHA にて設定した Severity に応じて各機能にFunctional DALを表 2の通り割り振る．次に，FTA

結果を活用し，各機器／部品に対して Item DALを設定する．これらの活動により各機器／部品の開発時に考慮すべき DALが最終的に設定される．3項でも述べた通り，開発保証活動に求められる詳細さ／厳密性はDALに大きく依存し結果的に作業量が異なることとなる．またソフトウェア／ Complex Hardwareを開発する際にも求められる作業内容が大きく異なってくる．ソフトウェア／ Complex Hardware品質保証の詳細については 5項にて解説する．次に安全性解析の一環として実施する CCAのうち，

CMAの概要を紹介する．CMAとはその名が示す通り，「共通要因により重大故障が起きない事の検証作業」である．例えば Catastrophic事象の発生確率が10-9／時未満であったとしても，Fault Treeを構成する故障要因が真に独立でなければ要求を満たすとは言

Severity 故障発生確率要求 DALCatastrophic 10-9 ／時　未満 AHazardous 10-7 ／時　未満 BMajor 10-5 ／時　未満 CMinor 10-3 ／時　未満 D

No Safety effect 要求無し E

表 2　Severity と故障発生確率要求

Vol.54　No.2（2015）

MRJ開発における安全性 119

えない．FTA 解析では「単一故障要因によりCatastrophic事象が発生しないか」を確認するが，CMAではさらに深く，ソフトウェアバグ／製造工程不 良 な ど の 共 通 要 因 が 無 い か，Catastrophic /

Hazardous事象の FTAに基づくチェックを行う．結果的に，例えば安全性上の重要な機能を果たす冗長コンピュータを異なる CPUにて構成する事が求められたり，同一機能を実現する冗長機器を敢えて別部品で構成する事が求められる．さらに飛行安全に直結する機能を果たすソフトウェアの場合，設計不良によるバグの混入を避ける為の一つの方策として Dissimilar

Software開発と呼ばれる手法を用いる事がある．本開発手法は同一の機能を果たすソフトウェアを複数のチームが独立した状態で開発し，冗長構成を成す機器に別々にインストールすることで単一要因（共通バグ）による致命的機能異常を防ぐ手法である．本手法は現在の航空宇宙機における代表的な開発手法であるが，開発期間とコストの増大を招く傾向がある．

5.　ソフトウェア品質保証と DO-178B

ソフトウェアのバグに代表される決定論的故障に対しては，その発生要因を徹底的に排除すべく，品質保証プロセスに関するガイドラインが設定されている．これはソフトウェア等で実現されるブラックボックス的なデジタル機器は，検証試験による完全な動作保証が不可能であり，工程管理による品質保証の考えを導入して不良を防止する必要があると考えられている為である．特にささいなミスが致命的な事故となる航空宇宙機においてバグの内在は許容できない．にもかかわらず，1996年のアリアン 5ロケットに代表されるような重大事故が引き続き発生しており 7），ソフトウェア品質の向上が求められている．以下，民間航空機におけるソフトウェア品質保証の公的なガイドラインである RTCA DO-178B 4）について概説する．

DO-178Bに従うとソフトウェア開発の初期において，PSACと呼ばれる文書の作成とレビューが求められる．本文書ではソフトウェア開発に用いる工程／ツール／手順を明確にすると共に，当該ソフトウェアに求められる DALが 4項に述べた手順に従い宣言される．DO-178Bではこれらレベルに応じて認証取得に必要な管理度合いを区別して要求する．表 3にソフトウェア開発時に整備が求められる Life Cycle Data

と DALの関係を示す．操縦システムとして一般的なLevel Aソフトウェアでは，上述の PSACにて当該ソフトウェアの果たす機能及び搭載 CPUなどのハードウェア構成が明記され，Level Aであると宣言された後，開発／検証／形態管理／品質管理に関する計画を

策定する．さらに，要求設定／ソフトウェア設計／コーディングに関する標準設定が求められ，ソフトウェア品質を確保する為の手順整備が必要となる．実際の開発過程においても，要求文書，設計書，検証結果，形態管理記録，発生した問題点の記録などを文書化する．検証プロセスでも厳密な品質管理が求められ，例えば以下に対して 100 ％カバレッジが要求される．・要求のトレーサビリティ・カバレッジ・コード・カバレッジ・MC/DC

実際に搭載用ソフトウェアの開発に携わっていると，バグの要因はソフトウェア開発プロセスより，要求設定の段階で混入することが多く，ソフトウェア自体の狭義の検証作業だけではバグ撲滅が困難と感じることがある．これに対して上位要求では ARP4754に従った要求管理の徹底と，ソフトウェアレベルではDO-178Bに従った初期段階からの要求の厳正なトレーサビリティ管理で対応する．また，ソフトウェア検証の後半プロセスでは機体レベルの機能／性能要求に対応した検証シナリオを設定し，ソフトウェアが設計意図通り出来上がっていることを確認する．

これら多大な作業が求められる DO-178B 適合ソフトウェアの効率的な開発には，ツールの活用が欠かせない．低位レベルではMC/DCカバレッジの自動検証ツール，上位レベルでは要求管理ツールや，Autocode機能を活用したトレーサビリティ管理の容易化が行われている．とはいえ，Autocode機能にて自動生成されたコードをそのまま DO-178Bに適合させるには Autocodeツールとしての品質保証が求められ，現状，Autocodedソフトウェアを直接製品に使用できるとは限らない．Model Based Developmentに代表される Autocode機能よる省力化のメリットを享受するには，各種ツールの Qualification活動が進み，出

表 3　DO-178B ソフトウェア開発活動

Software 開発時に要求される主な活動SoftwareDAL

A B C DPlanning 計画書の作成 ◎ ◎ ◎ ○

Standards / Rules 仕様設定／Coding 方法等に関する規定設定 ○ ○ ○

Verification 検証方法／結果の記録 ◎ ○ ○ ○Records in Entire Life Cycle 不適合記録等の作成 ○ ○ ○ ○

Configuration Management 形態管理の記録 ○ ○ ○ ○

Quality Assurance 品質管理活動の記録 ◎ ◎ ○ ○　◎：厳密／詳細な活動が求められる　○：活動が求められる

安 全 工 学

120 MRJ開発における安全性

来るだけ人的作業を低減したシームレスな開発手法の構築と品質保証体制の確立が期待される．

6.　操縦システムの安全性

操縦システムの安全性について議論する際，機体運動としての特性と故障時の Pilot操縦性を併せて考慮する必要がある．図 3にMRJ舵面構成図を示す．航空機の運動方向である Pitch / Roll / Yawを制御する舵面は以下の通り，Yawを除いて複数準備されており，1舵面の故障による完全機能喪失を防ぐ設計となっている．また Yaw運動に関しては，左右エンジンの推力調整などにより，舵面の機能を補完できる仕組みとなっている．・Pitch運動：2 Elevators

・Roll運動：2 Ailerons，3 Pairs of Multi- Function

Spoiler

・Yaw運動：Rudder

ここでは例題として，操縦系統故障の一つであるRudder Hardover（意図せぬ Rudder舵面の暴走）発生時における分析例について紹介する．4項にて述べた通り，まず開発初期段階で FHAにより「機体のYaw運動を制御する」機能の喪失及び異常挙動の影響度を分析し，Severityをアサインする．ここでは仮に，SeverityをMajorと設定したとする．その結果，本事象の発生確率要求は 10-5／時未満となるが，この時点では本当に SeverityがMajor程度なのか，或いはMRJ操縦システムの構成が発生確率要求を満足するか否か，不明の状態である．

設計作業が進むにつれ，システム・アーキテクチャ，機能の冗長構成，部品の信頼度情報などが明らかとな

図 3　MRJ 舵面構成図

り，Rudder Hardover事象の発生確率がより正確に予想できるようになる．ここでは仮に発生確率が 10-7

／時としよう．本システム構成であれば，Major事象に対する発生確率要求は満足している．一方，Major

という Severityが妥当か否かの検討も並行して行われる．航空機の機体挙動は最終的に「飛んでみないと分からない」代物である．とはいえ開発リスクを考慮すると出来るだけ早く故障時の影響を見積もる必要があり，初飛行前の段階から機体運動プログラムやシミュレータを用いた操縦性／制御性の評価を積み重ねて行く．図 4にMRJシミュレータの例を示す．具体的には Rudder Hardover事象を機体運動模擬プログラムにて模擬し，Pilotによるリカバリ操作を経て安全に空港に着陸できるか等の操縦性評価を実施し Severity

検証を進める．シミュレータを用いた Pilot評価試験では，飛行速度，高度，現実的な確率で遭遇しうる風条件などの組み合わせを考慮し，安全性を総合的に評価する．ここでは仮に，Rudder Hardover発生時に機体姿勢をリカバリすることが困難であり，Severityが Catastrophic

であったとする．その結果，発生確率は 10-9／時未満でなければならず，本操縦システムは安全性要求を満たさない事となる．

実際にこのような分析結果が得られた場合，操縦システム設計を改善して故障発生確率を減らすか，機体特性を見直して Rudder Hardover時の Severityを改善するかの選択を迫られる．いずれの選択も開発後期になるほどコスト増大／スケジュール遅延を招く為，出来るだけ早い段階で確度の高い分析をする事が肝要である．特に操縦システム開発においては，模擬度の高い機体運動プログラムと Pilot操縦が可能なシミュレータの準備が必要となる．

図 4　MRJ シミュレータ

Vol.54　No.2（2015）

MRJ開発における安全性 121

7.　MRJ操縦システム構成

近年の各種システムの高度化は，部品点数の増大を引き起こしシステムの信頼性を悪化させる事態に繋がりかねない．前述の通り一般に安全性に直接影響を与える重要なシステムは，冗長設計によりシステムの信頼性向上を図る必要がある．操縦システムの主流である FBWシステムでは，中核をなすセンサやコントローラも冗長設計の思想が適用される．一般的に電子機器の信頼性として，コントローラなど 1機器あたりのMTBFはせいぜい 10 000時間程度と言われ，故障発生確率は 10-4／時程度となる．このことは，多大な死傷者を伴う致命的な故障発生確率として 10-9／時未満が求められる民間航空機のフライト・クリティカルなシステムは，3重以上の冗長構成となることを示唆している．図 5にMRJ操縦システム・アーキテクチャを示す．中核をなす PFCC は 3重機器構成を成し，いくつかの偶発故障が発生した場合でも操縦性に対する影響を抑えるシステムとなっている．さらに，1つの PFCC内部は互いに出力を監視し合う 2

レーンから構成され，何らかの故障が発生しても自機器内で故障を検出し，外部への間違った情報送出を防ぐ機能を有する．これにより，単一故障による舵面の異常挙動を防止する設計となっている．最終的に舵面を制御する ACEは，独立した複数

チャンネルが異なる舵面を制御する事で機体全体の姿勢制御機能としての冗長性を確保している．ACEは計 4チャンネル構成から成り，各チャンネル内部は 2

レーンから構成され，PFCCと同様に単一故障による舵面の異常挙動を防止する設計となっている．また，Roll制御にも用いられる 3 PairsのMulti- Function

Spoilerのうち，1 Pairは ACEと異なる筐体であるSREUにより制御する方式とすることで操縦システムの独立性を高めている．

図 5　MRJ 操縦システム・アーキテクチャ

ただし，単にシステムを冗長化するだけでは構成機器が増加してシステム全体としての信頼性を悪化させる恐れがある．冗長システムの利点を活かしシステムとしての信頼性を向上するには，故障の検出／同定／分離を確実に実現する事が肝要であり，Votingロジック（多数決論理）を活用する事が多い．Votingロジックはその名の通り 3重冗長以上の信号であれば，多数決により正しいデータを選別して使用する方法である．2重冗長信号の場合は，双方の内容が一致した場合のみ信用できるデータとしてはじめて使用が許可される．実際の Voting処理ロジックには，異常信号を分離する際のトランジェント挙動を抑制する為の中間値選択処理や各種フィルタの装備が必要となり，各メーカのノウハウに基づいて設計されるのが一般的である．故障検出ロジックにも，短時間で大きなトランジェント挙動を示す異常信号と，長時間かけて少しずつ誤差を積み重ねる異常信号を区別して検出するなど，メーカのノウハウが必要となる．このような航空機の実設計に活用可能な，体系的な設計手法の構築が望まれるところである．

8.　お わ り に

MRJ操縦システムの例を挙げつつ，民間航空機に求められる安全性設計と開発保証活動について概説した．これら以外にも，安全で継続的な運用に必要な整備要求，ヒューマンエラーへの耐性確保，過去事例に対する改善設計など，航空機の安全性を確保する上で考慮すべき事項は多岐に及ぶ．MRJ開発を通じて総合的な技術力を高め，お客様の信頼を高めていくことがプロジェクト成功の為に必要不可欠な要素だと考えている．

参　考　文　献

1） 　 山口恭弘，佐藤昌之：民間航空機における制御技術，計測と制御，第 51巻 2012年 12月号，p.1174-1180

2） 　 ARP4754 A, Guidelines for Development of Civil Aircraft and Systems

3） 　 ARP4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment

4） 　 RTCA/DO-178B, Software Considerations in Airborne Systems and Equipment Certification

5） 　 Federal Aviation Regulation, Par t 25 Air wor thiness （Transport Category Airplane）

6） 　 Advisor y Circular 25-1309-1A, System Design and Analysis

7） 　 Nuseibeh, Bashar : Arian 5, Who Dunnit ?, IEEE Software, May-June 1997, Volume: 14, Issue: 3