********************************************************************** セッションS4-c チュートリアルテーマ：組込みソフトウェアの機能安全コーディネータ：櫛引豪（ガイアシステムソリューション／日本機能安全）日時：2010年9月3日(金) 13:00〜14:30 参加人数：50名程度 ********************************************************************** ○セッションの概要・チュートリアル・以下の話題・機能安全とは何か？・今後どうなっていくのか？・パネルディスカッション・森川氏と米木氏でディスカッション・まとめと今後の方向性についての議論 ○チュートリアル（大体30分） ☆安全とは何か・安全とは危害から免れていること・危害：人への障害，財産への損害など・リスク：危険事象の起こりやすさと被害の大きさの組合せ・今回のセッションでは悪いほうのリスクについて取り上げる ☆安全関連の企画の指針（ISO guide51）・基本的なポリシー：絶対安全は有り得ない・残存リスクは残る・機械やサービスは相対的な安全にしかなりえない・機械は必ず故障するなどの性悪説を考える・リスクの存在を認識し，その大きさを評価して，許容できる程度まで軽減することが必要・すなわち以下の事を意味する・危険事象の起こりやすさを減らす・起こったときの被害を緩和する ☆機能安全とは何か・対比される言葉：本質安全・もともと危なくないもの・例：鉄道の踏切を立体交差にすると危なさがなくなる・本当は達成したいが現実的に不可能である・安全機能を持つシステムでリスクを抑える・この概念を機能安全と呼ぶ ☆機能安全と安全関連計・電気電子プログラマブル電子技術によって安全を確保すること・安全な状態を維持・安全な状態へ誘導・安全の周りに「安全関連系」が守っている・安全関連系が機能を満たさないと危険にさらされる ☆組込みシステムと安全関連系・安全関連系：コンピュータ技術を使って実現されるシステムで安全機能を果たすもの・例：エアバッグ・エアバッグセンサ→エアバッグECU→エアバッグモジュール ☆機能安全規格の状況・1998年にIEC61508の基本規格が登場・その後に原子力用，鉄道用にIEC61513 IEC62278などが出てきた・主に機械系のものに対してISOが登場・現在では機能安全規格は幅広い分野に広がってきている ☆機能安全の歴史と背景・背景：技術の進歩・技術の進歩から新しいリスク発現メカニズムが発生し，事前安全計画から安全への取り組みが行われた・もしくは，事故の経験から安全への取り組みに力を入れるようになった・そこからさらに技術の進歩が起こり，ループの関係になる・最近ではループの回転が高速化・コンピュータ技術の進歩による ☆機能安全規格制定の歴史・様々な国で機能安全のガイドラインが作られた・1994年に日本も国際委員会に参加するようになった・1998年に各国委員会にCDVを提出→2000年にIEC61508の各パートが順次発行 ☆機能安全規格の概要・どのような安全機能を行うか，その安全機能の確からしさはどれくらいかを規定・構造にとらわれる必要はない・最新の技術が取り入れられる，新しい事故の対策が出来るようにするため ☆安全確認形の装置について・安全確認形とは：安全であることを検出して，安全であることが通報されている間だけ危険を伴う作業を実行する・始動指令と安全状態の検知のANDをとって機械の起動を決定する ☆機能安全におけるソフトウェアの位置づけ・ソフトウェアの位置づけ：汎用コンピュータを一時的に特殊用途の機械にするといえる・コンピュータの振る舞いを司るためにシステムの安全性において重要な役割を果たす・単体では安全を議論することが出来ない・バグが無いから安全，とはいえない・故障の扱い・機器で生じる磨耗故障などは考慮しない・ソフトウェアの設計ミス，製造ミス（＝バグ）を考慮するのが一般的・そもそも仕様が間違ってることが原因ということも有り得る ☆安全関連系における故障の種別・システマティック故障・ある種の原因に決定論的に関連する故障・定量化不可，予測不可・原因は設計変更・運転手順の文章化などにおける誤り・ランダム故障・時間に関して無秩序に発生・確率によって把握が可能 ☆ソフトウェアの安全性確保の考え方・ソフトウェアについては100%の信頼性を期待しない・故障が起こりにくく，起こっても危険な状態に至らないようにする・フォールト・アボイダンス（故障回避性）・フォールト・トレランス（故障許容性） ☆故障の種類と対策技法・ランダムハードウェア故障・アーキテクチャ制約やランダムハードウェア故障確率の評価を行う・システマティック故障・診断，管理，回避など様々なアプローチ ☆ソフトウェアに対する要求事項・リスクの代償に応じて安全度水準を定める・安全度水準に応じて，指定されたソフトウェア技法を使用する ☆ソフトウェアの故障のイメージ・仕様自体が正しくない→仕様に沿えばよいというわけではない・仕様通りに作れなかった・テストでカバーできなかった ☆ECUのSWの故障伝播の例・プログラムエラー→無限ループ→終わらない → コントロールユニットの断続停止→点火の間欠→車がギクシャク動く ☆今後：海外の機能安全対応の前進・EUは企画開発とビジネスが連動しながら世界をリード・韓国中国は近年機能安全の国際委員会にエキスパートとして登録・各国内で議論される仕組みが確立され，意識が高まっている・EU,USAとの結び付けを強めてさらに加速してきている・このままでは日本が取り残されてしまう ☆まとめ（今後どうなっていくのか）・システムの複雑化や新機能の開発→未知領域の拡大・過去資産の再利用の際の安全性確保→実績だけで大丈夫なのか・先人の教えの有効活用・安全に対してはソフトウェアとハードウェアとをセットで考えることが重要 ○パネルディスカッションはじめに ☆テーマ・機能安全への対応が従来のここと同じ／ここと違う・機能安全に期待すること／心配すること・認証のメリットデメリット ☆パネラ・Y氏（ガイアシステムソリューション）・M氏（ヴィッツ） ○パネルディスカッションパネラの方々の講演＜Y氏の講演＞ ☆自己紹介・主にマイコンなどハードウェアについてやっている ☆機能安全はソフトとハードによって実現されるもの・もし不具合が見つかっても機能の実現に影響しない，危険にならないものを機能安全という認識・この観点から見るとマイコンではソフトがどういう影響を受けるのかが問題・実際にはCPUコアの故障のどれくらいが一体どうなるのかなどは全くわからない・機能が実現できているか不明，壊れても危険にならないかが不明・オープンソースのCPUコアの故障が起こったときの影響の伝搬を検討・現状では故障モードと故障率が不明なので，対策と効果が定量的に評価できない・ゲートレベルでのフォールトの影響を机上でトレースするのが不可能・機能ブロックから別の機能ブロック，もしくはソフトへどんなエラーが伝播するかを検討 ☆検討した内容・対象はルネサスのSH2のコアのコンパチ・全体は4つのブロックで構成・主に演算系と制御系のブロック・今回，適当にブロックを選択して実験を行った ☆デコードののブロックが故障した場合・仮に故障しても全く影響がない確率が38% ・半分は1bitエラー・複数bitエラーはそんなに起こらない・他のブロックではまた別の傾向が得られることも ☆CPUコアの出力への影響・サイクル数を増やすと，影響も大きくなる・プログラムカウンタに関する故障が様々あった・命令によって故障率が異なることを定性的に確認 ☆わかったこと・制御系は現行方法でほぼテスト可能・データ系ブロックでは機能テストのみでは不充分 ☆結論・ソフトウェアを用いたコアの故障シミュレーションからコアの故障とソフトウェアの振る舞いの関係性を予測するきっかけを得た・ブロックごとにソフトとマイコンの故障の関係を整理することで，マイコンの故障などがわかるかを定量的に導くことが出来るかもしれない・実アプリを用いた解析をすることで，マイコン故障時のアプリソフトへの影響が評価できるかもしれない＜M氏の講演＞ ☆自己紹介・社内で機能安全グループのリーダを担当・IEC61508ソフト開発のプロセス認証を日本初で取得・この経験を生かして，他社の機能安全開発支援，機能安全対応OSの開発，機能安全開発支援ツールの開発などを行っている ☆機能安全開発の流れ・コンセプトフェーズ（安全設計，安全プロセス）と実現フェーズ（開発）・第1者：安全分析と安全設計→SIL算出評価を行う・第2者：安全プロセスの策定，実施から認証機関によるプロセス認証・この2つから審査を受ける ☆機能安全管理規定の作成・お客様の品質管理規定をベースに機能安全管理規定を作成する・困難な点・全てを規格のまま作成すると使い物にならない・規格の解釈→色々な粒度や深さがある ☆安全設計支援・SIL達成可能なレベルの安全なシステムを設計する・安全分析・安全設計など ☆SIL算出の評価・安全設計したシステムがSILを達成してるかを評価する・コンセプトフェーズにおける評価・開発後の評価・独自対応で困難なところがある・算出評価方法が不明 ☆TUVの機能安全認証の種類・プロセス認証・途中経過として使える位置づけ・製品認証・こちらのほうが重要 ☆プロセス認証有無によるコスト比較・プロセス認証なし・毎回安全プロセスの評価が付き，2回目以降もコストがかかる・SWプロセス認証・第1回目はややコストが増える・2回目以降はコストが大きく減るため，総合的にコストが低く効率が良い・プロセス認証を取得している企業に外部委託した場合，受け売れ検査の工程が大幅にカットできる ○パネルディスカッション討論＜議題：機能安全への対応が従来のここと同じ，ここが違う＞ ☆M氏の見解・きちんとやっている会社にとっては変わらない・やっていない会社にとってはやることがずいぶん増えるかもしれない・従来と同じ：・ベースとなる品質管理・従来と違う：・厳密なトレーサビリティの管理粒度は細かすぎても荒すぎてもダメ →第三者による技術的な検証何年後に見てもわかるようなドキュメントを残せると良い・機能安全によって変わったこと・安全意識の向上 ☆Y氏の見解・大枠自体はあまり変わっていない・違うのは，安全（リスク）の始点が加わったこと・といいつつもこれは従来から考えられていた・リスクに共通指標として等級が付いたこと・機能安全だからといって構える必要はない M氏：安全に関する説明の資料はプラスアルファで作っているわけではない（認証機関のためにやっているものではない）第3者が何年後に見てもわかるようなドキュメントを作らなければならない日ごろから誰がいつ見てもわかるような資料を残して行くことが重要＜議題：機能安全に期待すること／心配すること＞ ☆M氏の見解・期待・安全性のいっそうの向上・日本の製品は元から品質が高いし，安全に対してもしっかり考慮している・しかし，機能安全の規格を使ってさらなる向上が期待できる・機能安全の規格によってビジネス獲得の良い機会になるか・心配・日本のものづくり産業の足かせになるのではないか・コストがものすごくかかるのに安全性はそんなに高くならない …そんなことになってはいけない ☆Y氏の見解・期待・機能安全を機会に過去の設計資産を整理して再評価できるようチャンスになる・機能安全を例として，欧米流の考え方が理解でき，良い部分を取り入れるチャンスも得られる・不安・必要以上に安全に気を使いすぎてコストアップ→品質低下 ☆ディスカッション K氏：期待することは「安全性が上がる」「ビジネスチャンス」「欧米の考えを学べる」などだと思います．やりすぎることが心配な点ということでしょうか．今後これらをどうするかがキーになるとのご意見ですね M氏：システムを考えると，機能安全を高めるために故障判定モジュールを追加するなどして，ソフトウェアやハードウェアでも部品点数が増える可能性がある．小型のシステムでも，サイズが大きくなったりコストが高くなってしまう可能性もあるそして，品質が低下するなどの心配がある． Y氏：今の日本の品質が高いとして，その高い品質を生かしたまま，「この製品は安全である」と言えるような枠組みを日本から発信できるようにしたい．欧米は「壊れたらすぐに取り替えればよい」など，考え方が違うところもある．そうなると，そもそも立ち位置が違うのではないか．国として，そのようなことも考慮して新たな枠組みを作るのもいいのではないか． K氏：私もそのようなことに期待します．心配点は同じですが，心配することに対して「ここまでやればいいよ」という指標がいるかどうか，また，本質的にどこに手当てをすればリスクが減らせるのかなどの過不足無い対応をすることで，部品点数を少なくして，品質も下げないというところがポイントになってくるだろう．そのためには，ソフトとハードも一緒に考える必要がある．＜議題：認証のメリットデメリット＞ ☆M氏の見解・メリット・製品の市場価値を高める→認証機関によるお墨付きは絶大・認証機関も責任を負ってくれる・デメリット・認証費用がかかる・開発サイクルに影響がある（対応が遅いため数ヶ月？） ☆Y氏の見解・メリット・説明責任が容易になる・世界標準レベルで安全対策が出来る・デメリット・コストアップ要因であり，品質低下の要因になる・部品認証の問題・システム全体の問題になるのに，部品認証が先行しており本末転倒 ☆ディスカッション K氏：認証を取ったら本当に安全になるのだろうか？ M氏：製品認証の場合，物の中身まで見る違う視点からしっかり見るということで安全性の保証は高くなると思うし，有意義ただし，100%の安全は間違いなく存在しない． K氏：デメリットとしてお二人ともコストアップを上げていますね Y氏：なくてもよいのかもしれない．認証を取るにあたってドイツ人相手ではなく日本人相手にすべきではある． ○まとめ・機能安全を取り入れることで得られるメリットも多く考えられるが，製品の品質への影響も考えるべきである・機能安全という面で日本が今後どう戦って行くのかも重要である・機能安全についてのビジネスを構築して世界を相手にすることも視野に入れて今後も活動したい以上．