~ ソフトウエア認証への取り組みと課題 ~

Size: px

Start display at page:

Download "~ ソフトウエア認証への取り組みと課題 ~"

Arron Waters
5 years ago
Views:

1 第 1 回航空機装備品認証技術オープンフォーラム ~ ソフトウエア認証への取り組みと課題 ~ 2019 年 3 月 14 日 The information in this document is the property of Sumitomo Precision Products Co.,LTD.(SPP) and may not be duplicated, or disclosed to any third party, or used, for any purpose other than

2 ソフトウェア認証への取り組み 2

民間機開発への取り組み Landing Gear System 前脚 & ドア構造主脚 & ドア構造

SYSTEM SUPPLIER TIER1 LANDING GEAR SYSTEM SUPPLIER (Japanese

5 LANDING GEAR SUPPLIER All Landing Gear System 設計 / 製造

SUPPLIER/ BUILD-TO- PRINT SUPPLIER Nose Landing Gear(NLG) 製造

3 民間機開発への取り組み Landing Gear System 前脚 & ドア構造主脚 & ドア構造脚揚降制御システムブレーキ制御システムステアリング制御システム STATUS TIER1 LANDING GEAR SYSTEM SUPPLIER TIER1 LANDING GEAR SYSTEM SUPPLIER (Japanese Customer Only) TIER1.5 LANDING GEAR SUPPLIER All Landing Gear System 設計 / 製造 Landing Gear 設計 / 製造 NLG&MLG, NWSS 設計 / 製造 TIER2 COMPONENT SUPPLIER/ BUILD-TO- PRINT SUPPLIER Nose Landing Gear(NLG) 製造 Retract Actuator 製造 Main Side Brace Actuator 製造 Main Landing Gear(MLG) KIT 製造 YEAR

4 民間機システム開発民間機のシステム開発では以下のガイドラインに基づいた開発プロセス ( 組織体制含む ) を厳密に審査されるシステム開発 :ARP4754 による安全性解析 :ARP4761 による電子機器ハードウェア開発 : RTCA DO-254 によるソフトウェア開発 : RTCA DO-178 による ARP:Aerospace Recommended Practice RTCA: Radio Technical Commission for Aeronautics ( 米国航空無線技術委員会 ) Intended Aircraft Function Aircraft System Development Process Hardware Life-Cycle Process Software Life-Cycle Process [ARP 4761] Safety Assessment Process Guidelines & Methods ( 安全評価プロセスガイドライン & 方法 ) Function,Failure &Safety Information [ARP 4754]: Certification Considerations for Highly-Integrated or Complex Aircraft System ( 高度に統合されたまたは複雑な航空機システムの認証に関する考慮事項 ) System Development Process Functions & Requirements [DO-254] ( 搭載用システム及び機器の証明におけるハードウェアに関する考慮事項 ) Hardware Development Life-Cycle [DO-178B] Software Development Life-Cycle ソフトウェアの認証取得への取り組みが重要 System Design Function System Implementation 4

5 SW 認証への取り組み 2005 年 2008 年 2015 年認証準備認証活動認証プロセス改善活動 SW 認証ガイドライン (DO-178B) の調査コンサルタント (DER) による GAP Analysis 実施開発プロセス整備 (5Plan & 3Standard, 開発ツール導入 ) 認証取得体制構築 (Safety, SQA, CM) DER: Designated Engineering Representative SQA: Software Quality Assurance CM: Configuration Management SOI: Stage Of Involvement 約 8 年かけて認証機関による監査 (SOI#1~4) を Pass し認証取得プロジェクトに応じたプロセスの改善 DAL Independency( 独立性 ) 開発ツール PDS EASA memo DO-178C( 付属書含む ) の適用検討 TQ:DO-330 MBD:DO-331 FM:DO-333 DAL: Design Assurance Level PDS: Previously Developed Software TQ: Tool Qualification MBD: Model Based Development FM: Formal Method EASA: European Union Aviation Safety Agency 5

6 取り組み 1:Plan/Standard/Others 5Plan Plan for Software Aspects of Certification (PSAC) :SW 証明計画書 Software Development Plan (SDP) : SW 開発計画書 Software Verification Plan (SVP) : SW 検証計画書 Software Configuration Management Plan (SCMP): SW 構成形態管理計画書 Software Quality Assurance Plan (SQAP) : SW 品質保証計画書 3Standard Software Requirement Standard (SRS): ソフトウェア要求規格書 Software Design Standard (SDS): ソフトウェア設計規格書 Software Coding Standard (SCS): ソフトウェアコード規格書 6

7 Others 取り組み 1:Plan/Standard/Others Software Checklist for General : 各文書に対するチェックリスト設計文書, 試験レポート, 形態管理文書, Milestone Review 等 General Software Artifact Review Procedure :SWレビュー手順 SW Archival, Retrieval, and Duplication Process:SW 文書保管復元規定 DB Backup Procedure :DBのバックアップ規定 Software Change Control Board Process :SW CCB( 変更管理 ) 手順 Software Problem Report Process :SW PR 発行及び運用規定 SW Structural Coverage Analysis Procedure :SWカバレッジ解析手順 Software Complexity Analysis Procedure :SW 複雑度解析手順 Software Unit Test Procedure :SW 単体テスト手順 Software verification code make procedure :SW 検証用コード生成手順 Workflow software verification for test engineer : テスタ用 SW 検証作業手順 Software Installation Procedure :SWインストール手順 7

8 取り組み 2: 認証取得体制ソフトウェア開発に必要な体制 ( 当社例 ) Customer Engineering Org.(GM) PM Certification Regulation Organization (FAA) 成果物安全性解析システム要求 High-Level 要求 Low-Level 要求担当 Safety & Reliability Engineer Design Lead Software Lead Software Designer DL (System) QA Org. (GM) DER コーディング & コンパイル試験手順書 Software Coder Software Tester SW Lead (Requirement) Safety CM CCB 開催メンバー SQA プロセス及び成果物の評価プロセス及び成果物の監視審査及び承認検証試験検証結果報告書ソフトウェア形態ソフトウェアリリース報告書 SQA 報告書 Software Tester Software Tester Software Coder Software Lead SQA Lead SW Developers (Design) SW Developers (Coder) ソフトウェア開発チーム SW Developers (Tester) 形態管理報告書変更要求報告書 CM Manager CM Manager DO-178B 審査対象ソフトウェア環境形態 Software Developer 8

9 取り組み 3: 開発ツール整備民間機用ソフトウェア開発の為に新規購入した主なツール ( 当社例 ) 作業目的購入ツール備考要件 ( 仕様 ) 管理 DOORS 日本 IBM 社製変更管理 Change 日本 IBM 社製形態管理 Synergy 日本 IBM 社製構造解析 LDRA LDRA 社製 MBD ( シミュレーション /ACG) 静的解析 / 設計エラーチェック HILS(Hardware In the loop Simulation) MATLAB/Simulink/ Embedded Coder 等 Polyspace (Bug Finder/Code Prover) SCALEXIO Mathworks 社製 ACG:Auto Code Generation Mathworks 社製 dspace 社製 * 自動化目的 9

10 取り組み 4:MBD プロセス整備 DO-178C 付属書 (*1) で要求される各種 Plan 及び Standard の整備 ( 当社例 ) システム作業ソフトウェア作業従来プロセス Simulation Model 作成及び妥当性確認 (MIL) System 要求作成要求フェーズ HLR 作成及び妥当性確認 MBD プロセス *1:DO-178C 付属書 TQ : DO-330 MBD: DO-331 FM : DO-333 設計フェーズ LLR 作成及び妥当性確認コーディングフェーズ手動コード生成 & Code Review Code 静的解析 Coupling Analysis Unit Test 設計フェーズデザインモデル作成及び妥当性確認 HLR Based Simulation (MIL) コーディングフェーズ自動コード生成 Code 静的解析設計エラーチェック LLR Based Simulation (SIL) HLR :High Level Requirement LLR :Low Level Requirement EOC :Executable Object Code MIL :Model In-the Loop SIL :Software In-the Loop PIL :Processor In-the Loop 結合フェーズ EOC( 実行コード ) 生成テストフェーズ HLR Based Test 10

11 認証機関による監査 (1/2) ソフトウェア開発作業は以下の 4 つのステージ (Stage Of Involvement : SOI) に分け監査員 (FAA では DER) が各ステージに応じた監査を行う FAA : Federal Aviation Administration ( 米国連邦航空局 ) DER : Designated Engineering Representative ( 技術に関する FAA から指名された代理人 ) SOI#1: 開発組織と計画内容 ( 計画フェーズ ) の監査 SOI#2: 設計プロセス ( 設計フェーズ ) の監査 SOI#3: 検証プロセス ( 検証フェーズ ) の監査 SOI#4: 全体を通しての開発プロセスの監査 11

12 認証機関による監査 (2/2) SOI#1: 安全性を考慮した (DAL に基づいた ) ソフトウェアコンセプト及び開発プロセス ( 開発保証レベル ) になっているかを監査上記を証明する Plan が必要 SOI#2~4: 安全性を担保するための各種プロセス ( 要求, 設計, 検証, CM, QA 監査 ) を遵守しているかを監査認証機関で全プログラムを確認する事は多大な工数が必要となり実質的に不可能開発組織や開発プロセス (Software Life Cycle を正しく回しているか ) を監査される 12

13 認証取得するうえで重要 ( 必要 ) なこと (1/3) 計画フェーズ各フェーズにおける作業内容役割を明確に! 誰 ( どんな役割を持った人が? SW Designer, Verifier) いつ ( どの開発フェーズで? Requirement, Design ) 何 ( どんな作業をするのか? 要求作成, Review, 解析 ) 作業完了のCriteriaを明確に! 各種エビデンスはテンプレート化を! 可能な限り自動化を! 但し Tool Qualification は忘れずに安全性 / 信頼性解析によって決定した DAL に基づく開発プロセス ( 開発体制含む ) 及び機能を満たすソフトウェア構成になっていることを示すことが重要! プロセス : 検証レベル独立性等機能 : 冗長構成, Dissimilar, Monitor 機能要否を決定 13

14 認証取得するうえで重要 ( 必要 ) なこと (2/3) 設計 / 検証フェーズプロセス要素計画書で決めたルールを必ず遵守する遵守する為にシステムでプロセスを管理するのがベスト作業の独立性を確保する ( 一人での作業は厳禁 ) Problem Report の活用変更管理 Safety Engineer や SQA との連携技術的要素安全性を考慮した設計 (Monitor 手法 ) 設計の妥当性を示す論理的根拠 ( エビデンス ) 14

15 認証取得するうえで重要 ( 必要 ) なこと (3/3) エビデンスって? 要求 / 設計の妥当性を示すエビデンス Traceability を示すエビデンス Test Case/Procedure の妥当性を示すエビデンス Plan 通りに開発が行われていることを示すエビデンス形態管理, 変更管理を示すエビデンス DER はエビデンスを管理する形態管理者に様々な質問を浴びせエビデンスの残し方をチェックする各エビデンスの残し方を見れば正しいプロセスなのかわかる認証取得できるかはエビデンス次第全ての作業エビデンスを形に残すことが重要 15

16 認証への課題 16

17 認証への課題 (1/5) DO-178 のプロセスを適用すると品質は向上するしかしながら当然コストは増加要因としては開発プロセスの整備 ( 開発環境への投資 ) 作業量増加に伴い開発 LT 増加 LT 短縮の為に開発リソース増加作業者の能力競争力を上げる為にはコストを抑えて品質を確保する必要あり 17

18 認証への課題 (2/5) コストアップの一つの要因としては実はPlanやStandardに規定されない作業の曖昧さがあげられるソフトウェア作業の曖昧さ : 各要求の Tag 付け (Safety, Derived 要求等 ) Design 要求 (Coding 出来るレベルの書き方って?) Data Flow/Function Tree( どうやって Data/Control Coupling Analysis を行うの?) Traceability( どの要求 -Test 間の Trace をとるの?) 上げだすとキリがない曖昧な指示ではなんとなくイメージではわかっていても具体的にどんなアウトプットを出せば良いのかわからない 18

19 認証への課題 (3/5) 単にソフトウェアを作るのは誰でも出来るが論理的に妥当であると証明するエビデンスを誰もが同じレベルで残すことは非常に難しい作業者の裁量に頼ったアウトプットになると作業のやり直しが発生し余分な労力と時間を費やす例え監査で DER に説明出来ても結局エビデンスの作成は要求される曖昧さのない体系立てられたアウトプットが残せるように 5Plan, 3Standard を補足するルール (Procedure 等 ) が必要且つそれを自動化出来るシステムの構築が重要 19

20 認証への課題 (4/5) DO-178 における認証活動を全て自社で実施すると DO-178 の知見を有するエンジニアの確保英語の出来るエンジニアの確保安全性を考慮した設計が出来るエンジニアの確保 DO-178 に対応した自社の開発プロセス教育独立性を考慮したリソースの確保ツールの購入保守費用も自社負担膨大な初期投資が必要開発遅延により更にコストが増加するためリスクシェア ( ツールリソース等 ) することが重要 20

21 ただし認証への課題 (5/5) 海外の機体会社や Tier 1 メーカーにおいてはサプライチェーンを非常に重要視する基本的には実績が重視される ( 使用するツール等も ) 受注前にサプライヤの能力調査も行われる日本全体のソフトウェア認証技術の底上げをし早期のサプライチェーン及びコラボレーションしたプロセスの構築が重要 21

22 最後に開発プロセスは認証機関 (DER) がOKしないといけないしかし必ずこうというものはないため自社の既存プロセスをベースに無理のないプロセスの構築を! 認証取得には組織体制を作ることが重要 SW 開発チームだけでなく QA, Safety Engineer の育成を! 認証プロセスを理解するには実際に経験する事が一番但し何の経験も無しにいきなり受注する事は難しいまずは認証プログラムに参加いただき認証プロセスの経験を積んでいただいた後社内展開していただくのが一番の近道と考えますまた本イニシアティブにて認証経験のある企業のサポートを受けられることも有用だと考えます 22

23 ご清聴ありがとうございました Sumitomo Precision Products Co., Ltd. SPP Home Page 23

携帯電話の吸収率 (SAR) について / Specific Absorption Rate (SAR) of Mobile Phones

携帯電話の吸収率 (SAR) について / Specific Absorption Rate (SAR) of Mobile Phones 携帯電話の吸収率 (SAR) について / Specific Absorption Rate (SAR) of Mobile Phones 1. SC-02L の SAR / About SAR of SC-02L ( 本語 ) この機種 SC-02L の携帯電話機は国が定めた電波の体吸収に関する技術基準および電波防護の国際ガイドラインに適合していますこの携帯電話機は国が定めた電波の体吸収に関する技術基準