ソフトウェアfmeaを体系的に実施する 出発点として · pdf...
TRANSCRIPT
ソフトウェアFMEAを体系的に実施する出発点としてのMISRA-C
株式会社ヴィッツ 森川聡久
株式会社ヴィッツ 中野泰伸
名古屋市工業研究所 小川清
1
背景1：C言語のリスク
上記は、演算途中で桁溢れするかどうかの例。
CPU+開発環境依存のCコードは、見るだけでは結果を判断できないため、非常に気づきにくく（スキルを要し）、リスクが高い。
2014/1/14 2
uint16_t u16a = 40000; /* 0x9C40 */uint16_t u16b = 30000; /* 0x7530 */uint32_t u32x;u32x = u16a + u16b; /* 70000 (0x11170) or 4464 (0x1170) */
C言語の主な危険性１．CPUの違いによって動作が違う（環境依存）
– 未規定、未定義、処理系定義２．設計者が誤解をする
組込みソフトウェア開発で最も使用されているC言語は、記述の自由度が高いためリスクが高い。
背景2：ソフトウェアの安全分析
• 自動車、航空機、鉄道、産業機械など安全関連機器の複雑化が進み、不具合発生による安全性が懸念されている。近年、機能安全規格への適合が要求されつつある。
• 長年、回路図の安全分析（FMEA）は実施されてきている。しかし、ソフトウェアの安全分析（ソフトウェアFMEA）は、指針・事例が体系化されていない。【課題①】
• ソフトウェア安全分析結果が公開されていない部品・製品があり、何が不足しており、どう対処すべきか不明。
• ソフトウェアエンジニアは、安全分析スキル、安全対策スキルが不足している。 【課題②】
3
ハードウェアとソフトウェアの安全分析の違い
2014/1/14 4
安全分析
部品DB故障DB
IEC 62380ISO 13849MIL-HDBK-217 etc
FMEA
誰でも機械的実施可能
■ハードウェアの安全分析
■ソフトウェアの安全分析
ソフトウェアアーキテクチャ
安全性向上策
回路図回路図
（安全対策済）
・故障検出機能・V&V・防御プログラミング・MISRA-C
：
ソフトウェアFMEA
対策DB
安全性向上策
何を何処まで実施すれば安全上十分かが不明
安全分析
安全対策
CCプログラム
ソフトウェアの誤動作と対策の関係
2014/1/14 5
ソフトウェアの誤動作
マイコン故障 ソフトウェアバグ
CPUｺｱ故障
ROM故障
RAM故障
ｸﾛｯｸ故障
設計ミス
実装ミス
仕様ミス
テスト漏れ
・・・ ・・・
・基本はシステムの安全設計で対策。
・ソフトウェアの安全分析で、対策が十分であることを詳細確認。
・トレーサビリティ、V&V、コンパイラやSW-Cの信頼性確認で概ね対応可。（機能安全規格要求）
・C言語の特性を正しく理解した上で実装しているかは、確認が難しい。
＜対策＞ ＜対策＞
ｺﾝﾊﾟｲﾗﾊﾞｸﾞ
SW-Cﾊﾞｸﾞ
背景3：C言語のリスクへの対応
• 機能安全規格は、『言語サブセット＋コーディング規約＋静的解析ツール』の適用を要求している。
• 言語サブセットとして普及しているMISRA-Cは、ソフトウェアの品質低下のリスクを検出でき、安全上効果的。
• 最新のMISRA-C:2012では、静的解析で決定可能か、翻訳単位内の課題かの分類で整理された。
• しかし、MISRA-Cだけでは全てのリスクを防ぐことはで
きない。リスクについて何を何処まで対策すればよいか、体系化されていない。【課題③】
– 機能安全規格には具体的なやり方・基準の記載は無い。
6
MISRA-Cで防げないリスクの一例
2014/1/14 7
例１） 0で除算y = a / x;変数x が 0の場合が該当するが、ツールで静的に検出することはできない。
例２） 演算時にオーバーフローy = a + x;変数aや変数xの値によっては、変数yの記憶領域を超え、桁溢れを起こすが、ツールで静的に検出することはできない。
ソフトウェアの品質特性モデル（ISO/IEC 9126）
とC言語のリスクとの関連
2014/1/14 8
原因 影響
合目的性 ソフトウェアがユーザの目的に合致している機能を提供するか 複雑なコード、誤解を招くコード正しく実装されているか確認が漏れ、バグを検出できない可能性あり。
正確性 ソフトウェアが必要な正確さで結果をもたらす能力 未規定、未定義、処理系定義整数の汎整数拡張などで値の正確な継承ができない可能性あり。
相互運用性 ソフトウェアが指定された他のシステムとやりとりをできる能力 未規定、未定義、処理系定義 １６ビット、３２ビットシステム間で、値が異なる可能性あり。
機密性ソフトウェアが関係のない人に使用されたり、機能を実行する権限のない人に実行されたりしない能力
複雑なコード、誤解を招くコード 誤った使い方をされる可能性あり。
成熟性 障害が発生した時にソフトウェアが故障 (機能停止) しない能力 － －障害許容性 障害が起きてもソフトウェアが機能を提供し続ける能力 未規定、未定義、処理系定義 障害が起きたときの対応が不明。
回復性 障害が発生した後にソフトウェアの機能が正常に復帰する能力 未規定、未定義、処理系定義 システムが回復するための機能が不明。理解性 ソフトウェアの使用法をユーザが理解しやすいか 複雑なコード、誤解を招くコード 誤った使い方をし、バグを埋め込む可能性あり。習得性 ユーザがソフトウェアの使い方を学習しやすいか 複雑なコード、誤解を招くコード 誤った使い方をし、バグを埋め込む可能性あり。
運用性ユーザがソフトウェアを使う時のユーザインターフェイスの使いやすさ
複雑なコード、誤解を招くコード 誤った使い方をし、バグを埋め込む可能性あり。
注目性 ソフトウェアがユーザにとって魅力があるか － －
時間効率性ソフトウェアが適切な応答時間、処理時間、スループットで機能を実行する能力
－ －
資源効率性ソフトウェアがメモリやハードディスクなどのコンピュータ資源を適切に利用しているか
－ －
解析性ソフトウェアに障害が発生した時に、その原因を判別し、修正の必要な箇所を特定しやすいか
複雑なコード、誤解を招くコード 誤った変更し、バグを埋め込む可能性あり。
変更性稼働後の変更要求など、やらなければならない修正をソフトウェアにできるか
複雑なコード、誤解を招くコード 誤った変更し、バグを埋め込む可能性あり。
安定性 ソフトウェアを修正した時に、影響が予想外の箇所に及ばないこと 複雑なコード、誤解を招くコード 誤った変更し、バグを埋め込む可能性あり。
試験性 ソフトウェアを修正した時にテストがしやすいか 複雑なコード、誤解を招くコードテストがしにくいく、テスト漏れが発生し、バグを検出しきれない可能性あり。
環境適応性 ソフトウェアを別の環境へ移す時の手間 未規定、未定義、処理系定義 移植時にバグを混入する可能性あり。設置性 ソフトウェアを指定された環境へインストールする時のやりやすさ 未規定、未定義、処理系定義 移植時にバグを混入する可能性あり。共存性 ソフトウェアを同じ環境で他のソフトウェアと共存できること 未規定、未定義、処理系定義 移植時にバグを混入する可能性あり。
置換性同じ環境で、同じ目的を持った他のソフトウェアと置き換えられる能力
未規定、未定義、処理系定義 移植時にバグを混入する可能性あり。
※参照元：http://www.ogis-ri.co.jp/otc/hiroba/technical/JavaPress_ISO9126/index.html
移植性
効率性
保守性
C言語の危険性品質特性 品質副特性 概要説明
使用性
信頼性
機能性
C言語の「未規定」「未定義」「処理系定義」「可読性」による原因でリスクが生じる。⇒対策が比較的難しい「未規定」「未定義」「処理系定義」を、今回対象とする。
本研究の概要
2014/1/14 9
• 目標：Cコードへの安全対策を体系化し（課題①・課題③対応）、
スキル不足のソフトウェアエンジニアでも十分な安全対策を可能にする（課題②対応） 。
• 対象：「未規定」「未定義」「処理系定義」に絞る。• MISRA-C対応ツールによる自動検出を、積極的に採用する。
世の中で普及しているMISRA-C:2004 を主とする。 新しく策定されたMISRA-C:2012 も同時に試用・評価する。
• MISRA-Cでは検出できないリスクへの対策を検討する。
「未規定」「未定義」「処理系定義」
左記リスクへの対応の完全性を明確化・MISRA-C:2004・MISRA-C:2012・対策A・対策B
：
C
C言語が抱えるリスク
具体的な実施方法（分析シートの例）
2014/1/14 10
「未規定」「未定義」「処理系定義」に関する事項 （JIS X 3010）
MISRA-C:2004,2012検出可能ルール
MISRA-C以外の検出方法を考案
実施結果：概要
11
件数 割合[%] 件数 割合[%] 件数 割合[%] 件数 割合[%]
未規定 22 18 82% 19 86% 21 95% 22 100%未定義 97 75 77% 70 72% 87 90% 97 100%
処理系定義 76 47 62% 36 47% 48 63% 76 100%総計 195 140 72% 125 64% 156 80% 195 100%
危険項目 全件数
MISRA-C:2004検出可能
MISRA-C:2012検出可能
MISRA-C＆その他の方策
検出可能
MISRA-C:2004＆MISRA-C:2012
検出可能
• MISRA-C:2004 だけでは、検出できない危険項目が多い。⇒MISRA-C:2012 を併用することで、80%まで検出率が向上した。
• MISRA-Cでは検出できない危険項目も多い。（39件/195件）• 以下の方策を併用することで、検出率を100%まで向上可能。
コンパイルエラーにて検出 コード動的解析ツールにて検出 コードレビューにて確認 動作検証にて確認
実施結果：MISRA-Cのバージョンによる違いの例
2014/1/14 12
C90 未規定21「qsort関数によって整列された配列内での比較して等しい２つの要素の順序」
■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対応ルール無し
実施結果：Cコードへの安全対策の体系化の例
2014/1/14 13
MISRA-C:1998,2004,2012の静的解析ツールを実行
※注）MISRA-C:2012対応ツールの登場が必要
ソースコードレビュー レビュー必要な観点を明確化
未規定、未定義、処理系定義に完全に対応可能
Cコード動的解析ツールを実行
コンパイルエラー
0で除算実行時に決まる境界越え値・代入等を検出
動作検証
改行文字、対にならない文字、前処理指令、関数・変数・引数の宣言、緩かったint, voidソースファイル検索順序を厳格に指定
Nullポインタの値の取り出し(dereference)等
実施結果：必要なコードレビューチェック観点の例
• 未規定、未定義、処理系定義の事項を、事前に検査できる事項、決定可能、翻訳単位で確認可能かを分類し、レビュー観点を洗い出した。
• 例）構造体または共用体へのポインタが翻訳単位で値を取出(dereference)さなければ、実装が隠蔽できる。
2014/1/14 14
MISRA-C:2012 Dir 4.8 の例より#include "Opaque.h”void f (void) {
pOpaqueType pObject;pObject =GetObject();UseObject(pObject);
}
まとめ
・課題①：ソフトウェアの安全分析が体系化されていない。・課題③：C言語のリスクへの対策について体系化されていない。⇒ C言語が抱えるリスクの内、 「未規定」「未定義」「処理系定義」について安全対策の体系化をMISRA-C:2012等を基に行った。
ソフトウェアFMEA実施と同等の“完全性”の実現
・課題②：ソフトウェアエンジニアの安全対策スキル不足⇒体系化を行うことで、スキル不足のソフトウェアエンジニアでも十分な安全対策を可能にできるようにした。
15
今後の課題
• 今回体系化したプロセスの実運用における、効果の計測・評価が必要。
– 評価対象：スキル不足のソフトウェアエンジニアでも十分な安全対策が可能になったか？
• C言語が抱えるリスクの内、「複雑なコード、誤解を招くコード」への対応について、同等の検討が必要。
16
ご清聴ありがとうございました
＜参考文献＞
• FMEA辞書―気づき能力の強化による設計不具合未然防止,本田 陽広, 日本品質管理学会, 日本QC学会, 2011
• 設計の故障解析51―QS9000対応, 伊予部将三,日刊工業新聞社,2000
• 組込み開発者におくるMISRA‐C―組込みプログラミングの高信頼化ガイド(MISRA-C:1998対応）日本規格協会,2004
• 組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド日本規格協会,2006
• ETSSを利用した機能安全対応スキル判定と教育訓練,小川清,渡部謹二,斉藤直希,堀武司,奥田篤,水口大知,吉岡律夫,渡辺登,安全工学シンポジウム, 2008
17
【参考】MISRA-Cの更新の推移
2014/1/14 18
MISRA-C:1998
MISRA-C:2004
MISRA-C:2012
＜課題＞
・ツールによるチェックが困難なルールがあり。・C99でbool型が採用されたため、型に関してC90とC99両対応が困難。
・自動生成コードについての対応が不明確。
・ルールがわかりづらい（目的不明確、ルールか説明か不明確、1ルールに複数要件の記述）・int型の環境の違いに非対応（ビット幅、符号付の扱いなど）・2バイト文字非対応
C-1990
C-1998
・ルールの明確化整理
・算術演算のルールに新しい概念や用語の導入（Underlying type ）⇒ 3ルールについて明確化・2バイト文字対応
・ツールでチェック可能なルールと、チェックできないが実施した方がよいルールを分類。 （RulesとDirectives）
・型チェックを厳しくし、コンパイラの型チェックに任せる。（Underlying type⇒Essential type）・自動生成コードも対象・コードの具体例など、解説が充実
＜主な改善点＞