********************************************************************** セッションS2-b　ワークテーマ：実践！　機能安全〜Safety Conceptを作ろう！(ソフトウェア編)〜コーディネータ: 武井　千春(名古屋大学) 森川　聡久(ヴィッツ) 水口　大知(アトリエ) 松原　豊(名古屋大学) 日時：8/23 09:00-10:20 参加人数：19人 ********************************************************************** ※講義パート開始前にグループ分け　一班3〜4人(グループ分けは同じ会社の人が同じ班にならないようだけ配慮) ++++++++++++++講義パート++++++++++++++++++++++++++++++++++++++++++++++ (09:02〜) 講師：森川聡久 ■セッションの目的・概要・機能安全において、すべての前提となる最も重要な活動は「Safety Concept作り」　その中で「安全分析」が最も重要な作業である・目的：Safety Concept構築のためのエッセンスを修得する　　　　(今回はソフトウェアにフォーカス) ・概要： -例題システムのソフトウェアについて、故障モードを分析、安全対策の検討　　　　-数人のグループでブレーンストーミング＆発表 ■本セッションの狙い・ソフトウェアエンジニアへの期待 -ソフトウェア安全分析手法を体験する -ソフトウェアによる安全対策の実例を学ぶ ■タイムテーブル 09:00〜09:10：イントロダクション、グループ分け 09:10〜09:20：「例題システムの説明」 09:20〜10:00：グループワーク「ソフトウェアの安全分析」 10:00〜10:20：成果発表、まとめ ■機能安全の大枠 ○IEC 61508 ＜SIL(Safety Integrity Level、安全度水準)：１〜４＞・低頻度作動モード　作動失敗確立(１／回) -SIL４数万回に１度 -SIL３数千回に１度 -SIL２数百回に１度 -SIL１数十回に１度・高頻度作動モード、連続モード　故障率(１／時間) -SIL４数万年に１度 -SIL３数千年に１度 -SIL２数百年に１度 -SIL１数十年に１度 ■従来開発と機能安全開発 ○従来開発・信頼性(壊れないこと)重視・事故努力によってバグゼロが目標・担当者間のすり合わせ開発・開発文書の出来栄えは不十分・効率的だが説明力が乏しい ○機能安全開発・故障を前提とした安全担保・高品質の証拠を積み重ねた開発によってバグゼロが目標・構成部品が故障しても危険にならない仕組みが必要・安全を客観的に説明できる開発文書の作成が必要もし緊急スイッチが(マイコンが・・・)壊れたら → ”危険” → アクチュエータを停止し、故障したことがわかるようにする＜対策＞・バグが潜在していないことを客観的に説明可→安全プロセスの強化・故障を発見する → 故障検出機能・故障しにくくする → システムの多重化、低故障率の部品を使用 →安全設計 ■IEC61508の派生規格 ○IEC 61508：一般安全装置 ↓ ・ISO26262：自動車・IEC61513：原子力・IEC61511：化学プラント・IEC62061：産業機械・ISO13482：サービスロボット・IEC62304：医療機器・BS EN 50128、BS EN 50129：鉄道・DO-178B：航空機 ■安全コンセプトの構築の流れ ◎いかなる故障が発生しても、必要なレベルの安全を達成できることを証明すること　一番の肝は「安全分析」＜安全コンセプト４文書＞・安全分析結果故障を網羅的に洗い出すことと、安全対策が重要・SRS：Safety Requirement Specification：安全要求仕様書安全関連機能について記載した仕様書・SC：Safety Concept：安全コンセプトコンセプトレベルで安全を証明（説明）できる資料・SM：Safety Manual：安全マニュアルユーザやハードへの制約条件 ■SILと安全策の関係・IEC61508ではSFFの達成が必要！・SILとN重化によって、要求SFFが決まる "SFF＝安全側故障率／全故障率" ⇒ 故障検出率（DC）を上げることで、安全側故障率を上げる必要あり ⇒ 最悪ケースを想定すると、SFF相当のDCを目指すことを推奨する＜DCの決定方法＞ IEC61508:2010-2 Table.A に記載あり。検出可能な故障によって、DC=High（99%）／Medium（90%）／Low（60%）を判定それを達成するための具体的な方策についても、記載あり ■安全分析にて考慮すべき故障のパターン・系統的原因故障（バグ）とランダムHW故障・単一故障と多重故障 -IEC61508では、単一故障のみ考慮 -ISO26262（自動車）では、２重故障まで考慮必要 -BS EN 50129（鉄道）では、３重故障まで考慮必要・恒久故障と一時故障 -一時故障の例）ノイズによるメモリ化け・従属故障 -ある故障が原因で、その影響を受け、別の箇所が故障する・共通原因故障 -１つの原因により、複数箇所への同時故障が生じること -例１）電源異常により、２マイコン共誤動作 -例２）ノイズの影響（環境）により、２マイコン共誤動作 -例３）安全系のある変数が化け、各出力系全てが誤動作 -例４）同一設計のソフトのため、同じ箇所にバグが存在 ■潜在故障・安全策（Safety Mechanism；SM）の潜在故障 a) 安全なケース ①安全機能が故障→②安全策１が異常を検出→フェールセーフ処理 b) 危険なケース ①安全策１が先に故障→②安全機能が後に故障→危険＜対策例＞安全策２を設ける安全策１は安全機能と安全策２が故障していないことを監視し、安全策２は安全策１が故障していないことを監視する ■例題システムの説明(例題システム：IHクッキングヒーター) ○例題システムについての解説 1.直流電力を供給する 2.設定周波数で電流方向を入れ替える 3.電磁誘導(IH)で電流を発生させる 4.鍋のジュール熱で具があたたまる・トップハザード 1)システム内部の火災 2)具(油等を含む)の異常加熱による火災 ○基本的なこと＜ハードウェア部＞・スイッチS1、S2のON/OFFによってコイルに流れる電流の方向が決定する　→S1とS2の出力時間の割合によってヒーターの温度が変化する・S1、S2はMCUから1がくるとONし、0がくるとOFFする・S1=ON、S2=OFFでは、電流はコイルを左→右に流れる・S1=ON、S2=OFFの間にコンデンサに電荷が溜まる・S1=OFF、S2=ONにするとコンデンサを電池として電流が右→左に流れる＜ソフトウェア部(制御ソフトウェア)＞・S3、S4(押しボタン)からの入力とS1、S2への出力、SW実行の3機能のみを有する・S3、S4の値を定期的に見に行く(ボタンの状態をMCUで読み取る) ・S3、S4の値に基いてS1、S2への出力の時間の割合を変化させる・時間の測定はソフトウェア部でループを回し、レジスタをインクリメントして　測定している・S3とS4は割込みで実装されている ○例題システムのハザード＜IHクッキングヒーター内部の火災についての前提＞・電気的に火災の条件が揃えば発生するとする　(一例：S1とS2が同時にON(通電)した場合) ・リスク評価危険度：大、曝され度：大、回避困難度：中　(SIL2相当) ・安全状態：システム停止(自然冷却が可能な状態) ・安全状態への以降限界時間(PST)：1秒(と仮定) ＜加熱対象(具、油等)の火災についての前提＞・加熱の送料が限界を超えると火災が発生するとする・リスク評価：危険度：大、曝され度：大、回避困難度：中・安全状態：システム停止(自然冷却が可能な状態) ・PST：Q1未満の場合：5分、Q1以上：1秒(と仮定) 　※Q1：異常加熱境界。これを超える熱量はごく短時間でも、加熱対象の火災を招くものと仮定する＜制御ソフトウェアについての前提＞・マイコン以外のハードウェアの故障は考えない　(マイコンの故障、ソフトウェアのバグだけを考える) ＜ソフトウェア安全要求仕様＞・S1とS2が同時に1になる状態が(0.1*t)以上継続しないこと・tの値がT1以下(Q1以上に相当)の状態が1秒以上継続しないこと＜ソフトウェア制御の安全状態＞・S1とS2の出力がともに0 ※今回は時間の都合で＜加熱対象の火災＞については考えない　→今回の検討事項は＜IHクッキングヒーター内部の火災＞のみ ■グループワークの概要について解説 ○入力情報・例題システムの仕様：ソフトウェア処理(フローチャート) ・安全／危険の定義・目標SIL ○グループワーク＜安全分析の進め方＞・Step1.異常動作(故障モード)の検討・Step2.影響の検討(安全／危険) ・Step3.故障原因の検討・Step4.対策の検討 →模造紙に異常動作・故障原因・影響・対策を色分けして記入する →最後に各グループで発表を行う(各グループ3分) ■ソフトウェアの誤動作に影響する故障原因の代表例 -バス：固着、タイムアウト -汎用レジスタ：固着、データ化け -プログラムカウンタ：固着、データ化け -スタックポインタ：固着、データ化け -命令デコーダ：誤った命令の実行、命令が実行されない -ROM：データの固着、アドレスの固着、データ化け、アドレス化け -RAM：データの固着、アドレスの固着、データ化け、アドレス化け -クロック：周期の誤り -ソフトウェア：ソフトウェアのバグ ■異常動作と故障原因の一例 -例1)異常動作：処理のスキップ→原因：ROMの故障 -例2)異常動作：処理の繰り返し→原因：CPUコアの故障 -例3)異常動作：待ち時間が期待値より長い・短い→原因：クロックの故障 -例4)異常動作：割込みが不要に入る、割込みが入らない　　　　　　　 →原因：割込みコントローラ故障 -例5)異常動作：変数が異なる値になる→原因：RAM故障、ノイズによるRAM化け ■各処理の異常動作(故障モード)の検討の導入についての補足危険状態：S1とS2が同時に1(High)となる→システム内部の火災前提条件：設定値通り、時間t,dが保たれていれば、温度は一定になる　　　：異常加熱のケースは今回のワークでは考えない →危険状態が発生する可能性があるかどうか検討する +++++++++グループワークパート++++++++++++++++++++++++++++++++++++++++++++++ (09:33〜) 講師：森川聡久、水口　大知、松原　豊、武井　千春 ■グループワーク開始 10:00まで(⇒10:10に変更) ・一班3〜4人(グループ分けは適当、同じ会社の人が同じ班にならないようだけ配慮) ・付箋紙、ペン、制御フローの図を配布・故障原因の代表例や異常動作と故障原因の一例を参考に　制御フロー図をベースにしてグループで検討　⇒検討後発表 ■第２班で議論した内容＜考えられる異常動作及び故障＞・PCカウンタの数値が変わってフローが飛ぶ・変換テーブルの内容書き換え・補正後やテーブルから値の取得中に、割込みなどによってv_req_heat(ヒーター強度を　格納した変数)の値が変更され、変換テーブルから想定外のインデックスを引く・メモリの固着により出力値が固定になる＜その他挙がった疑問点等＞・ハードウェアの故障が発生した際にソフトウェアはどのように動作するのか・同時に割込み(S3、S4)が入ったらどうなるか　→割込みに優先順位が設定されていれば大丈夫、そうでない場合は危険・割込みを禁止にする時間を設けるとその間はスイッチの入力を受け付けなくなり　ユーザはスイッチが故障していると勘違いする可能性がある　→基本的には割込みを禁止してはいけない(割り込み中は例外) ・タイマ割込みについては遅延が起きても危険状態には結びつかないので問題なし＜まとめと対策＞問題：PCカウンタの異常でS1の書き込みからS2の書き込みに一気に遷移する　　　→S1,S2が同時に1になってしまう対策：S1とS2を同時に管理する　　　→S1に1を書き込むときはS2を0に、S2に1を書き込むときはS1を0にする問題：v_t(待ち時間tを格納した変数)が異常値　　　→周期がおかしくなる対策：v_tに補正をかけて、異常値の場合は許容値内に収まるようにする問題：タイマが壊れて割込みが入りっぱなしになる　　　→S1,S2が0⇒1⇒0・・・と短い間隔で変化し続ける　　　→ハード的には曖昧な状態(HIGHかLOWか)で危険対策：具体的な対策でず ■グループ発表」(10:12〜) ※時間が押しているため1グループ1分程で発表 ○1班発表者：Ｓ氏・今回はv_t(待ち時間)については検討範囲外とする・Waitを細かい時間のループにして、その中でS1とS2の値が正常かチェックする・S1のポートに1を出力する時は、S2が0であることをチェックする　同様にS2のポートに1を出力する時は、S1が0であることをチェックする・何らかの原因でWaitの命令が実行されていない、あるいは正しい時間で　実行されていない可能性があるので、Wait終了後に正常な時間が経過している　ことをチェックする・S1とS2が同時に1になった時に割込みを入れることができればさらに簡単に　対策できる ○2班発表者：Ｋ氏・基本的には1班と同じ事を考えた・S1S2を制御する時は必ず同時に制御を行うようにする　S1に1を出力する時は必ずS2に0を出力する、S2に1を出力する時は必ずS1に0を　出力するようにする ○3班発表者：Ｓ氏・1班と同様にS1S2が両方1になることに関与しない箇所は検討外とした・(問題)スタックの破壊やROMの故障で正しい遷移先の状態に遷移しない　(対策)各状態において実行順序のチェックを行う　→実行順序が不正だった場合はリカバリ処理を行う・(問題)ソフトウェア上ではS1に0を出力しているつもりでも、メモリ化けで実際は　1が出力されている　(対策)出力後にポートを確認して本当に正しい値が出力されているかをチェックする・(問題)クロックに異常が発生してWaitが規定より短くなってしまう　(対策)Wait後に正しい時間が経過したかをチェックする　→Wait時間が不正だった場合はリカバリ処理を行う ○4班発表者：Ｈ氏・S1S2の値とは関係ないv_req_heatを扱う部分は検討外とした・(問題)待ち時間を格納した変数が化けると非常に短い時間で出力が切り替わってしまう　(対策)最低限の待ち時間を保証するようにする　→変数が下限値を下回っていた場合は下限値に補正する・S1S2のどちらかを1にするときはアトミックトランザクションのように　片方を強制的に0にしてからもう片方を1を出力するようにする ○5班発表者：Ｎ氏・v_req_heatや割込みの処理はS1,S2の出力には直接関わってこないので検討外とした・waitについては中身の処理が不明であるので、waitには手を触れないという前提　のもと検討を行った・waitの処理の後に1を出力するポートとは逆のポートに0が出力されていることを　確認する +++++++++クロージングパート++++++++++++++++++*+++++++++++++++++++++++++++++++++ (10:20〜) 講師：森川聡久 ■セッションのまとめと発表に対するコメント ○セッションのまとめ・本セッションでは安全分析を体験してもらうために、IHクッキングヒーターを例に挙げ、　内部発火を起こさないためにはどうするべきか、問題点とその対策をグループで討論し、　発表を行った ○発表に対するコメント・v_req_heat等を内部発火の原因とは関係ないものとして検討から外すという判断は正しい　しかし、製品として販売する際には直感的ではなく、網羅的に全ての箇所について　分析をする方が良い・第2班で挙がっていたプログラムカウンタが飛んでしまう問題に対してはシーケンスモニタ　を入れることで解決できる　ただし、シーケンスモニタをどれぐらい細かく入れるかは問題　→細かく入れ過ぎるとオーバーヘッドが大きくなる ○最後に・今回行った様な細かい粒度での検討によって発見された問題は、上流の粗いレベル　での検討ではなかなか発見できない・対策にしても、その対策で本当に安全かどうかを確かめるためにはもっと細かい粒度　で検討してみる必要がある・ハードウェアよりもソフトウェアでの対策を重視することで、安価なマイコンでも　システムを実現可能になるが、その分対策が大変になり、ソフトウェア規模も膨大になる以上