************************************************************************* セッションS2-c チュートリアルテーマ：SysMLを拡張したSafeMLで、システムの安全性をモデル化・設計しよう講師：Geoffrey Biggs 代理　中坊嘉宏(産業技術総合研究所) 日時：2014/8/29 9:00～10:20 参加人数：34名(終了時)　 ************************************************************************* ・自己紹介　知能システム研究部門　　ディペンダブルシステム研究グループ長　Geoffreyさん急な用事で発表することができないので代わりに発表・アジェンダ　SafeML 　安全とはなにか　今日来られている方　研究・開発の対象が自動車の方　介護ロボット・産業ロボット・方法論・開発論　安全性・信頼性を保障するうえでSafeMLを一事例として紹介　SafeMLを用いた安全情報管理方法とコミュニケーションを支援する方法　オープンしているので拡張していただいて結構・概要　安全とはなにか　SafeML 　SafeML適応事例　ツールの説明・製品としてのリスクの違い　自動車はリスクが明らかなことが多い　走れるところは決まっている　衝突・・・リスクの顕在化する危険のモードはすでに分かっている・そもそも安全とは(と語ることは少ない) 　安全とはなにか見つけ出すことが大事　コンポーネントがどうなど　安全性の議論が少ない　想定外のリスクとはなんなのかなど・サービス面を考えたとき　全然違う分野が入ってくるとき,きっとそういうときはある・安全性とは　従来手法との比較　危険：危害の潜在源　Hazard: Potential source of harm 　危害：財産又は環境の損傷の結果、直接的又は間接的に与えられる、人の健康に対する肉体的傷害又は損傷・危害の潜在源　例：自動車の場合は衝突　原因＋状況＝危害　先走ると　危害の原因は二つに分ける　　コンピュータで自動計算もできないので,人間にしかできない（常識が必要）　→危険を見つけるプロセスが必要になる　想定できる危害を全部考える必要があるが,方法論としては人間の能力に依存　システマティックな手法でそれを解決していきぼんやりではいけない　→系統的に取り組む・FTA(Fault Tree Analysis) 　ある原因を分析する手法で原因を深堀する　なにがクリティカルなのか　状況（コンテキスト）が生じないようにする・本質安全(Intrinsic) 　シートベルトなど・機能安全(Functional safety) 　危険源をなくすことはできないが機能的にカバーしていく　人間がつぶれる前に自動車がつぶれることで　エアバッグ：風船がふくらむことで運転者を守る　ABS：ブレーキを踏んだ時にロックされることを防ぐ・情報交換の際の問題点　異分野間のやりとりで安全の専門家とエンジニアの間で安全に関する視点・認識が違う　コミュニケーションのギャップの存在→モデルベースで改善していく・開発プロセス　技術者間でやりとりが異なる　開発が進むほどコスト増加　SafeMLでコンセプトを含めたモデルを早期に作り上げることでそのリスクを抑える・記法に関しては形式的に厳密性がいる　読むのはなんとかなるが、書くのは技術がいる・SafeMLを利用していく上で前提条件が必要　→たとえば人数が2人ならいらない　段階がある　ラピッドプロトタイピングの時にモデリングする必要もない　・SysMLで安全をモデリング→SafeML 　やりたいことはSysMLを使って安全を考えるということ・モデルベースの利点　最初からモデリングしていくと構造化が既にされているので　シミュレーション・分析・コード自動生成など拡張していける　ギャップ分析,認証機関を考慮するとトレーサビリティがあるとよい　→SysML・SafeMLでモデリングするとトレーサビリティのあるドキュメント生成もできる・SafeMLでできること　開発したときに安全性に関する内容を示すのが楽になる　安全の定義　自己流で分析するとあとで治す必要がある・SafeML 　SysMLへ新しい要素と関連（「stereotypes」）の追加・SysMLモデルにこれで　要素で安全情報の表現　関連で安全情報とシステム設計、要求等の関係の表現　リスクアセスメント・SafeML使用箇所　危険を把握＋追跡可能　対処方法・実装が妥当か　→SafeML一つで追っていける・SafeMLの利点　安全のエンジニアからシステムエンジニアにどうしてやるべきか伝えることができる　システムエンジニアは自分のやっていることに興味が向いており、そこばかり取り組んでしまいがち　→SafeMLのモデルを見せることでシステムエンジニアにも意識させることができる・SafeMLの要素と関連　クラスの関係　関連　機能安全の場合はセンサーが必要でそれに関する記述もモデル化されている　ハザード　ハーム　コンテキスト　存在していることを明記　危険源の中身　・ハザード　危害の潜在的原因を突き止める　システム上に存在することを明記　危険源がどういう損傷を及ぼすかも記載する　リスクアセスメントの説明はしないが,基本は網羅的に見つけ出す・ハーム　どれくらいひどいか定義　けがの程度などから起こってはいけないランク付けをする　　一番ひどいときはどうなるか定義する・コンテキスト　引き起こされる状況がなにか　危険が顕在化するプロセスを明確化することが重要　コンテキストに働きかける　コンテキストを無くす方向にもっていく・ハームコンテキスト(harmcontext) 　危険(hazard)と危害(harm)の関連を表す・ハザード要素　ユースケースのどこで？　システム要求でハザードはおこるのか. 　リチウムイオン電池は燃える　危険源→発火の原因,感電の原因・ハーム要素（SafeMLのみの要素）　感電なのか・発火なのか・言語は制約・ルールでできている　コンテキストはシステムの構成によって異なる　リチウム電池の例：電池が座席の下にあるのか後ろにあるのかで影響が違う　→状況によりコンテキストは異なりますよね・危害に対する対策　本質安全はハザードそのものをやめよう(リチウム電池をやめる) 　防御機能＝コンテキストをつぶすこと・SafeMLのコンセプト：Defences 　PassiveDefence 　ActiveDefence 　DefenceResult ・Passive defence→安全を保障するために継続的に働いている機能を提示・Active defence→必要なときだけ安全を確保するような機能を提示・DefenceResult→防衛結果を示す・Defenceにおけるコンセプトを整理していくと要求機能になってくる　要求事項が分かってくると必要なセンサなども明らかになる　パラメータすきなように設定できる・SafeMLのコンセプト：モニタリング　いつ事故が発生するかなどのトリガーが大事→それを見つける・検出する　数も大事(contextdetecterが0のことはないので1..*) 　どういった事象のコンテキストなのか考えることが大事・safeMLの要素と関連　タグによって,パラメータを与えることができる　自動計算するとパラメータを計算してsafety scoreが出るがscoreが高いと安全性が低くなる　SafeMLは上流でも使えるしどのプロセスでも使用可能　テストケースの作成にも活用することができる　IBM・マイクロソフトなどでコードの自動生成も取り組んでいるかもしれない・SafeMLの例　potentialの原因→車が木に衝突,ハザードは衝突,ハームはけが, コンテキストは木がある状況　自動車ではあまり意識されていない・ルンバの安全分析の例　ルンバはアメリカのベンチャー企業が作成　日本でもSharp Panasonicでもリスクアセスメントした結果売ることはしなかった　たとえば、不安定な台の上にろうそくがあり,ルンバがろうそく倒して,火事が起こるかもしれない　しかし,irobot社では、実際このリスクは低いもしくは許容範囲だと考えたので販売されたという例　分析が妥当かどうか考えて、海外の企業はとるに足らないリスクと考察　リスク自体の仕分けが必要だということを意味している. ・新しいものを考える時にリスクを考えるのは大事　しかし,日本はリスクテイクが下手　正しいリスク分析を今後取り組んでいくべき　その分析をしたうえで,そのリスクを扱うかどうか議論していくべき　コンテキストを無くすための分析も必要・インパクト分析　変更がどこに影響を与えるのか　トレースをとって安全を考えるとき　ブレーキがなくなったときにどういった影響を与えるのかなど・Intrisic Safety 　例：キャビンクラッシュ,シートベルト　クラッシャブルゾーンを作っておくことで搭乗者の安全を保障していく →システムから危険を消すシステム・Functional Safety(機能安全) 　例：エアバッグ,アンチロックブレーキシステム→通常作動中の安全性を保障する機能・事故時の安全性を提供する機能　・ツールでできること　正しい書き方をできているか記述を自動化すればエラーなくなるはず　SafeMLメタモデルとの整合性を検証するモデルチェッカ　レポートの自動生成・リスクアセスメント表(ハームに対するハザードやdefence resultの列挙) 　マトリックスビュー：表との違いはsafety scoreを表現していること　危険に対して対処法がどれだけ効果があるか数値的に示すことができる　・SafeMLの利点・まとめ　SysMLだけだと安全情報が分かりづらい　モデル言語として取組みやすい・実際に使ってほしいので,profileのenterprise archtect ver 9,10 and 11と magicdrawを公開している　今,astah*に対応している最中,URL参照を参照してください　必要ならばGeoffreyが講習会もします. 質疑応答 <質問者1> スライドp.33にsafeMLの要素と関連でdefence resultは対象によって変わってしまうのではないか <回答> リスクの前と低減後を記述可関連は二つ以上いくことが可能あるコンテキストに対して一つに防御機能から関連が二つ以上いくこともできる (ほかのハームのコンテキストにもいく) <質問2> 意思決定の自動化はできるのか. 非倫理的な意思決定が出てくるのではないか. <回答> 自動化自体は一番難しいので最後になるこの形で見えるのはシステムの構造と閲覧性. 表によってどういった形でリスクを低減しているのか視覚化できるようにしている. どのくらいお金をかけてどういった効果がでているのかわかるようになっている. 実際にSafeMLのモデリングデータを基に議論をすればよい.→コストの見積もりなど <質問者3> 確率・頻度はコンテキストになると思われるが頻度があきらかに低いものは FMEAなどで点数づけして基準もありますが,SafeMLではそういった対策を打たなくていいような場合の基準はあるのか <回答> SafeMLというよりリスクアセスメントの段階の議論であまりにも頻度が低い・あまりにも危害の程度が小さい場合はやるべきではない変更履歴はとっておくべきでどこまで議論したのかが大事で,どこらへんまでやるか境界線がみえる程度のことをやるべきです. 大事なのは危ないけどこれは大丈夫かなぁっていう部分をアセスメントや履歴として残しておきたいなんのために書くのか考えることが大事以上　