ソフトウェア FMEA を体系的に実施する出発点としての MISRA-C 株式会社ヴィッツ森川聡久株式会社ヴィッツ中野泰伸名古屋市工業研究所小川清 1

Size: px

Start display at page:

Download "ソフトウェア FMEA を体系的に実施する出発点としての MISRA-C 株式会社ヴィッツ森川聡久株式会社ヴィッツ中野泰伸名古屋市工業研究所小川清 1"

そうあんさい
4 years ago
Views:

1 ソフトウェア FMEA を体系的に実施する出発点としての MISRA-C 株式会社ヴィッツ森川聡久株式会社ヴィッツ中野泰伸名古屋市工業研究所小川清 1

2 背景 1:C 言語のリスク組込みソフトウェア開発で最も使用されている C 言語は記述の自由度が高いためリスクが高い C 言語の主な危険性 1.CPU の違いによって動作が違う ( 環境依存 ) 未規定未定義処理系定義 2. 設計者が誤解をする uint16_t u16a = 40000; /* 0x9C40 */ uint16_t u16b = 30000; /* 0x7530 */ uint32_t u32x; u32x = u16a + u16b; /* (0x11170) or 4464 (0x1170) */ 上記は演算途中で桁溢れするかどうかの例 CPU+ 開発環境依存の C コードは見るだけでは結果を判断できないため非常に気づきにくく ( スキルを要し ) リスクが高い 2014/1/14 2

3 背景 2: ソフトウェアの安全分析自動車航空機鉄道産業機械など安全関連機器の複雑化が進み不具合発生による安全性が懸念されている近年機能安全規格への適合が要求されつつある長年回路図の安全分析 (FMEA) は実施されてきているしかしソフトウェアの安全分析 ( ソフトウェア FMEA) は指針事例が体系化されていない課題 1 ソフトウェア安全分析結果が公開されていない部品製品があり何が不足しておりどう対処すべきか不明ソフトウェアエンジニアは安全分析スキル安全対策スキルが不足している課題 2 3

ハードウェアとソフトウェアの安全分析の違いハードウェアの安全分析回路図部品 DB 故障 DB IEC 62380 ISO

ソフトウェアの安全分析ソフトウェアアーキテクチャ安全分析安全分析 C C プログラム誰でも機械的実施可能ソフトウェア

4 ハードウェアとソフトウェアの安全分析の違いハードウェアの安全分析回路図部品 DB 故障 DB IEC ISO MIL-HDBK-217 etc FMEA 対策 DB 回路図 ( 安全対策済 ) ソフトウェアの安全分析ソフトウェアアーキテクチャ安全分析安全分析 C C プログラム誰でも機械的実施可能ソフトウェア FMEA 安全性向上策何を何処まで実施すれば安全上十分かが不明安全性向上策安全対策故障検出機能 V&V 防御プログラミング MISRA-C : 2014/1/14 4

5 ソフトウェアの誤動作と対策の関係ソフトウェアの誤動作マイコン故障ソフトウェアバグ CPU コア故障 ROM 故障 RAM 故障クロック故障仕様設計実装テストコンハイ SW-C ミスミスミス漏れラハクハク < 対策 > 基本はシステムの安全設計で対策ソフトウェアの安全分析で対策が十分であることを詳細確認 < 対策 > トレーサビリティ V&V コンパイラやSW-Cの信頼性確認で概ね対応可 ( 機能安全規格要求 ) C 言語の特性を正しく理解した上で実装しているかは確認が難しい 2014/1/14 5

6 背景 3:C 言語のリスクへの対応機能安全規格は言語サブセット + コーディング規約 + 静的解析ツールの適用を要求している言語サブセットとして普及している MISRA-C はソフトウェアの品質低下のリスクを検出でき安全上効果的最新の MISRA-C:2012 では静的解析で決定可能か翻訳単位内の課題かの分類で整理されたしかし MISRA-C だけでは全てのリスクを防ぐことはできないリスクについて何を何処まで対策すればよいか体系化されていない課題 3 機能安全規格には具体的なやり方基準の記載は無い 6

7 MISRA-C で防げないリスクの一例例 1) 0 で除算 y = a / x; 変数 x が 0 の場合が該当するがツールで静的に検出することはできない例 2) 演算時にオーバーフロー y = a + x; 変数 a や変数 x の値によっては変数 y の記憶領域を超え桁溢れを起こすがツールで静的に検出することはできない 2014/1/14 7

8 ソフトウェアの品質特性モデル (ISO/IEC 9126) とC 言語のリスクとの関連 C 言語の未規定未定義処理系定義可読性による原因でリスクが生じる対策が比較的難しい未規定未定義処理系定義を今回対象とする品質特性品質副特性概要説明 C 言語の危険性原因影響合目的性ソフトウェアがユーザの目的に合致している機能を提供するか複雑なコード誤解を招くコード正しく実装されているか確認が漏れバグを検出できない可能性あり機能性正確性ソフトウェアが必要な正確さで結果をもたらす能力未規定未定義処理系定義整数の汎整数拡張などで値の正確な継承ができない可能性あり相互運用性ソフトウェアが指定された他のシステムとやりとりをできる能力未規定未定義処理系定義 16ビット 32ビットシステム間で値が異なる可能性あり機密性ソフトウェアが関係のない人に使用されたり機能を実行する権限のない人に実行されたりしない能力複雑なコード誤解を招くコード誤った使い方をされる可能性あり成熟性障害が発生した時にソフトウェアが故障 ( 機能停止 ) しない能力 - - 信頼性障害許容性障害が起きてもソフトウェアが機能を提供し続ける能力未規定未定義処理系定義障害が起きたときの対応が不明回復性障害が発生した後にソフトウェアの機能が正常に復帰する能力未規定未定義処理系定義システムが回復するための機能が不明理解性ソフトウェアの使用法をユーザが理解しやすいか複雑なコード誤解を招くコード誤った使い方をしバグを埋め込む可能性あり習得性ユーザがソフトウェアの使い方を学習しやすいか複雑なコード誤解を招くコード誤った使い方をしバグを埋め込む可能性あり使用性ユーザがソフトウェアを使う時のユーザインターフェイスの使いやす運用性さ複雑なコード誤解を招くコード誤った使い方をしバグを埋め込む可能性あり注目性ソフトウェアがユーザにとって魅力があるか - - 効率性時間効率性ソフトウェアが適切な応答時間処理時間スループットで機能を実行する能力 - - 資源効率性ソフトウェアがメモリやハードディスクなどのコンピュータ資源を適切に利用しているか - - 解析性ソフトウェアに障害が発生した時にその原因を判別し修正の必要複雑なコード誤解を招くコードな箇所を特定しやすいか誤った変更しバグを埋め込む可能性あり保守性変更性稼働後の変更要求などやらなければならない修正をソフトウェアにできるか複雑なコード誤解を招くコード誤った変更しバグを埋め込む可能性あり安定性ソフトウェアを修正した時に影響が予想外の箇所に及ばないこと複雑なコード誤解を招くコード誤った変更しバグを埋め込む可能性あり試験性ソフトウェアを修正した時にテストがしやすいか複雑なコード誤解を招くコードテストがしにくいくテスト漏れが発生しバグを検出しきれない可能性あり環境適応性ソフトウェアを別の環境へ移す時の手間未規定未定義処理系定義移植時にバグを混入する可能性あり設置性ソフトウェアを指定された環境へインストールする時のやりやすさ未規定未定義処理系定義移植時にバグを混入する可能性あり移植性共存性ソフトウェアを同じ環境で他のソフトウェアと共存できること未規定未定義処理系定義移植時にバグを混入する可能性あり置換性同じ環境で同じ目的を持った他のソフトウェアと置き換えられる能力未規定未定義処理系定義移植時にバグを混入する可能性あり参照元 : 2014/1/14 8

9 本研究の概要目標 :C コードへの安全対策を体系化し ( 課題 1 課題 3 対応 ) スキル不足のソフトウェアエンジニアでも十分な安全対策を可能にする ( 課題 2 対応 ) 対象 : 未規定未定義処理系定義に絞る MISRA-C 対応ツールによる自動検出を積極的に採用する世の中で普及している MISRA-C:2004 を主とする新しく策定された MISRA-C:2012 も同時に試用評価する MISRA-C では検出できないリスクへの対策を検討する C C 言語が抱えるリスク未規定未定義処理系定義左記リスクへの対応の完全性を明確化 MISRA-C:2004 MISRA-C:2012 対策 A 対策 B : 2014/1/14 9

10 具体的な実施方法 ( 分析シートの例 ) 未規定未定義処理系定義に関する事項 (JIS X 3010) MISRA-C:2004,2012 検出可能ルール MISRA-C 以外の検出方法を考案 2014/1/14 10

11 実施結果 : 概要危険項目全件数 MISRA-C:2004 検出可能 MISRA-C:2012 検出可能 MISRA-C:2004 &MISRA-C:2012 検出可能 MISRA-C & その他の方策検出可能件数割合 [%] 件数割合 [%] 件数割合 [%] 件数割合 [%] 未規定 % 19 86% 21 95% % 未定義 % 70 72% 87 90% % 処理系定義 % 36 47% 48 63% % 総計 % % % % MISRA-C:2004 だけでは検出できない危険項目が多い MISRA-C:2012 を併用することで 80% まで検出率が向上した MISRA-C では検出できない危険項目も多い (39 件 /195 件 ) 以下の方策を併用することで検出率を 100% まで向上可能コンパイルエラーにて検出コード動的解析ツールにて検出コードレビューにて確認動作検証にて確認 11

12 実施結果 : MISRA-C のバージョンによる違いの例 C90 未規定 21 qsort 関数によって整列された配列内での比較して等しい 2 つの要素の順序 MISRA-C:2004 対応ルール無し MISRA-C:2012 ルール 21.9 <stdlib.h> のライブラリ関数 bsearch および qsort はすべて用いてはならない C90 処理系定義 46 アンダーフロー値域エラーの場合に数学関数がマクロ ERANGE の値を整数式 errno に設定するか否か MISRA-C:2004 ルール 20.5 エラー指示子 errno は用いてはならない MISRA-C:2012 対応ルール無し 2014/1/14 12

13 実施結果 : C コードへの安全対策の体系化の例コンパイルエラー MISRA-C:1998,2004,2012 の静的解析ツールを実行改行文字対にならない文字前処理指令関数変数引数の宣言緩かった int, void ソースファイル検索順序を厳格に指定注 )MISRA-C:2012 対応ツールの登場が必要 C コード動的解析ツールを実行ソースコードレビュー 0 で除算実行時に決まる境界越え値代入等を検出レビュー必要な観点を明確化動作検証 Null ポインタの値の取り出し (dereference) 等未規定未定義処理系定義に完全に対応可能 2014/1/14 13

14 実施結果 : 必要なコードレビューチェック観点の例未規定未定義処理系定義の事項を事前に検査できる事項決定可能翻訳単位で確認可能かを分類しレビュー観点を洗い出した例 ) 構造体または共用体へのポインタが翻訳単位で値を取出 (dereference) さなければ実装が隠蔽できる MISRA-C:2012 Dir 4.8 の例より #include "Opaque.h void f (void) { popaquetype pobject; pobject =GetObject(); UseObject(pObject); } 2014/1/14 14

15 まとめ課題 1: ソフトウェアの安全分析が体系化されていない課題 3:C 言語のリスクへの対策について体系化されていない C 言語が抱えるリスクの内未規定未定義処理系定義について安全対策の体系化を MISRA-C:2012 等を基に行ったソフトウェア FMEA 実施と同等の完全性の実現課題 2: ソフトウェアエンジニアの安全対策スキル不足体系化を行うことでスキル不足のソフトウェアエンジニアでも十分な安全対策を可能にできるようにした 15

16 今後の課題今回体系化したプロセスの実運用における効果の計測評価が必要評価対象 : スキル不足のソフトウェアエンジニアでも十分な安全対策が可能になったか? C 言語が抱えるリスクの内複雑なコード誤解を招くコードへの対応について同等の検討が必要 16

17 ご清聴ありがとうございました < 参考文献 > FMEA 辞書気づき能力の強化による設計不具合未然防止, 本田陽広, 日本品質管理学会, 日本 QC 学会, 2011 設計の故障解析 51 QS9000 対応, 伊予部将三, 日刊工業新聞社,2000 組込み開発者におくる MISRA C 組込みプログラミングの高信頼化ガイド (MISRA-C:1998 対応 ) 日本規格協会,2004 組込み開発者におくる MISRA C:2004 C 言語利用の高信頼化ガイド日本規格協会,2006 ETSS を利用した機能安全対応スキル判定と教育訓練, 小川清, 渡部謹二, 斉藤直希, 堀武司, 奥田篤, 水口大知, 吉岡律夫, 渡辺登, 安全工学シンポジウム,

18 参考 MISRA-C の更新の推移 < 課題 > ルールがわかりづらい ( 目的不明確ルールか説明か不明確 1 ルールに複数要件の記述 ) int 型の環境の違いに非対応 ( ビット幅符号付の扱いなど ) 2 バイト文字非対応ツールによるチェックが困難なルールがあり C99 で bool 型が採用されたため型に関して C90 と C99 両対応が困難自動生成コードについての対応が不明確 C-1998 MISRA-C:1998 MISRA-C:2004 MISRA-C:2012 C-1990 < 主な改善点 > ルールの明確化整理算術演算のルールに新しい概念や用語の導入 (Underlying type ) 3 ルールについて明確化 2 バイト文字対応ツールでチェック可能なルールとチェックできないが実施した方がよいルールを分類 (Rules と Directives) 型チェックを厳しくしコンパイラの型チェックに任せる (Underlying type Essential type) 自動生成コードも対象コードの具体例など解説が充実 2014/1/14 18

Microsoft PowerPoint - A3②　JaSST_MISRA2004ソースコード品質診断.ppt

Microsoft PowerPoint - A3②　JaSST_MISRA2004ソースコード品質診断.ppt ISO/IEC9126 & MISRA-C:2004 ベースソースコード品質診断 ~ MISRA-C:2004 ベース品質診断のご紹介 ~ 株式会社東陽テクニカソフトウェアソリューション MISRA とは Motor Industry Software Reliability Association の略ヨーロッパ自動車技術会 (MIRA) の下部組織 MIRA: Motor Industry

ソフトウェア FMEA を体系的に実施する 出発点としての MISRA-C 株式会社ヴィッツ森川聡久 株式会社ヴィッツ中野泰伸 名古屋市工業研究所小川清 1

ソフトウェア FMEA を体系的に実施する出発点としての MISRA-C 株式会社ヴィッツ森川聡久株式会社ヴィッツ中野泰伸名古屋市工業研究所小川清 1