Transcript

• 1. Safety/Securityへの アジャイル開発と モデルベース開発 アプローチ 株式会社チェンジビジョン 平鍋健児 1
• 2. 2 ≪講演概要≫ 昨今、システム開発でますます使われるようになってきた モデルベース開発⼿手法とアジャイル開発⼿手法。 これらは、複雑化するシステム開発を⼀一⽅方は抽象化、可視 化によって、もう⼀一⽅方はエンピリカルで⼈人間中⼼心な活動と して解決しようとしている。⼀一⽅方、⾼高信頼化が求められる システム開発においても、これらのアプローチが影響をお よぼしはじめている。 本セッションでは、「アジャイル開発⼿手法」と「モデル ベース開発⼿手法」を外観した後、それぞれの⼿手法がセイフ ティやセキュリティのエリアでどのように使われるように なってきているか、ご紹介する。
• 3. 3 自己紹介 l  ㈱永和システムマネジメント – 福井市（本社）、上野東京（⽀支社） – Ruby  と  Agileを使ったシステム開発 l  株式会社チェンジビジョン – 福井市（開発部）、上野東京（本社） – astah*  (旧：JUDE)  の開発 l  平鍋健児 – UML+マインドマップエディタ  astah*の開発 – 要求開発アライアンス、理理事 – 翻訳、XP関連書籍、『リーン開発の本質』 『IMPACT  MAPPING』等多数。 – 著書『アジャイル開発とスクラム』、『要求開発』 『ソフトウェア開発に役⽴立立つマインドマップ』
• 4. 4 •  顧客・技術・経営の３者をつなぐ ために、アジャイルと⽇日本経営の 接合点を探る •  海兵隊の組織とアジャイル •  知識識創造プロセスとアジャイル •  実践知リーダーとアジャイル •  富⼠士通・楽天・リクルートの事例例 •  Jeff  Sutherlandインタビュー 『アジャイル開発とスクラム』 平鍋健児＋野中郁次郎著
• 5. アジャイル開発の背景 (情報系から組込み系へ) 5
• 6. 6 市場 ビジネス IT 市場分析 発注 納品リリース 半年年から３年年 ミッション・リスク分割型ビジネスと ウォーターフォール型開発（従来型）
• 7. 従来型の問題＝要求の劣劣化 •  Standish  group  study  report  in  2000  chaos  report 7 システムの機能の利用度 全く使われない 45%ほとんど使われな い 19% たまに使う 16% いつも使う 7% よく使う 13%
• 8. 8 市場 IT ミッション・リスク共有型ビジネス とAgile型開発 ビジネス 市場 ビジネスとITが⼀一体になった 「OneTeam」を作り、ミッション とリスクを共有する。 やってみて、結果から戦略略を 作りながら進む。
• 9. スクラムのフレームワーク 9 製品 バックログ スプリント バックログ 1-4 週 24 時間 出荷可能 ソフトウェア 朝会
• 10. 10 IDEAS   CODE  DATA   BUILD  LEARN   MEASURE   素早くコード 単体テスト   ユーザビリティテスト   継続的結合   漸進開発   オープンソース利用   クラウド   クラスタ免疫システム   JITスケーラビリティ   リファクタリング   デベロパーサンドボックス 素早く測定 AB  テスト   明確なプロダクトオーナ   継続的開発   ユーザビリティテスト   リアルタイムモニタ   顧客代表 素早く学習 AB  テスト   顧客インタビュー   顧客開発   なぜなぜ5回、真因分析   顧客アドバイザリボード   仮説検証   プロダクト・オーナーの責任   顧客タイプ分析   機能横断チーム   半自立チーム   スモークテスト 漏斗分析   コホート分析   ネットプロモータスコア   検索エンジンマーケティング   リアルタイムアラート   予測的モニタリング LeanStartup
• 11. 組込みシステムでも(1)… 消費者機械安全性：  IPA/SEC  →  OMGで提案 11 出典： SEC journal http://www.ipa.go.jp/files/000024514.pdf “ここで提案してい る素早い繰り返し、 動的振る舞いモデ ルの導⼊入、物理理と 数学のソフトウェ アへの導⼊入の⼼心は ⽇日本的開発⼿手法そ のものである…” キーワード: D-Case, GSN, SoS, Model-based, Safety Case Certification Engineering, Dependability, ISO26262
• 12. 組込みシステムでも(2)… DEOS：  The  Open  Groupで標準化 12 出典: DEOS協会 http://deos.or.jp/technology/process-j.html
• 13. 13
• 14. アジャイル開発 •  (1)  市場（何を作るか）が不不安定 •  (2)  技術（どうやって作るか）が不不安定 ともに、予⾒見見できない •  「作って試す」繰り返しが必要 •  エンピリカルで⼈人間活動を考慮した⼿手法 •  SoS(System  of  Systems)  やセキュリ ティでは「相⼿手」を知りきれない。 14   Copyright  (C)  2014  Change  Vision  CorporaEon.  All  Rights  Reserved.   本質的な不確実さ
• 15. モデリング技術 15
• 16. 16   情報システム組込みシステム 物 メカCAD ECAD 制御 ソフトウェア UML （離離散系/ 情報系） Simulink(連続系/制御系) UML,ER, DFD,BPMN.. (データ,プロセス,..） システムのモデルリング⾔言語 SysML(要求、構造、振舞、制約)SysML(統合系) システム/SoS SysML(要求、構造、振舞、制約) アシュランス GSN(D-Case) 保証議論論 SafeML(安全+設計情報) SCDL (ISO26262の 安全コンセプト) 2 4 3 1
• 17. SysML (Systems  Modeling  Language MBSEの⾔言語) 17   1
• 18. SysMLを使ったRTCベースの
 ロボットアプリケーション開発  :   事例ケースタディとデモ       平鍋健児(Change  Vision,  Inc)   安藤慶昭(産総研)   一昨年OMGで発表された事例。 hQp://www.slideshare.net/hiranabe/using-­‐sysml-­‐in-­‐an-­‐roboE-­‐applicaEon 1
• 19. プロジェクトメンバー Honda R&D Team 安藤慶昭 平鍋健児 岩永寿来 岡村敏弘 関谷 眞 原 功 鳥井 豊隆 SysML to RTC1 2 OpenRTM to Honda RTM Geoffrey Biggs
• 20. l 自律ロボットを遠隔操作し、２つ の動き (Spiral と Back-and- Forth) をさせる。Operatorは自律 モードとデモモード切り替えること ができる。 l ハードウェアアーキテクチャはあ らかじめ決まっている。PCを乗せ たRoombaを、Wi-Fi通信で、 Kinectを使ってモードスイッチする。 問題記述 kinect Operator Controller PC Receiver PC Roomba Wi-Fi
• 21. req  [コア要求(問題文)]
• 22. req  [Robotへの要求]
• 23. uc  [デモユースケース]
• 24. bdd  [コンテキスト図]
• 25. bdd  [システム概要]
• 26. ibd  [デモシステム]
• 27. ibd  [controller物理構造]
• 28. SysMLとSoS •  慶応⼤大学⼤大学院ＳＤＭ 　⻄西村秀和先⽣生の 事例例 •  IPA(RISE)  ソフトウェア⼯工学分野の先導 的研究⽀支援事業(2014年年  実施中) •  ⾃自動運転⾞車車を例例題に、SoSアーキテクチャ の参照モデルを構築 28   1
• 29. 研究概要 　次世代自動運転車の導入に向け、それを取り巻く交通インフラ、各種情報 システムを含む周辺環境、ドライバなどをSystem  of  Systems（SoS）として捉え た上で、安全性を考慮したアーキテクチャを構築する。   　自動運転技術の研究のみでは、システムレベルでの安全性の確保は難し いため、安全なSoSアーキテクチャを構築することが課題と考える。   29 2014年度ソフトウェア工学分野の先導的研究支援事業   システムモデルと繰り返し型モデル検査による次世代自動運転車を取り巻くSoSのアーキテクチャ設計 Copyright©2014 Hidekazu Nishimura.
• 30. Context between Automated Driving System and System of Systems[Block]ibd [ ] transport Infrastructure System a u t o m a t e d D r i v i n g S y s t e me g o V e h i c l e D r i v e r p e d e s t r i a n p h y s i c a l E n v i r o n m e n t s n a t u r a l E n v i r o n m e n t s u r r o u n d i n g M o b i l i t y e g o V e h i c l e I C T S y s t e m Driver automated driving commandAutomated driving information Direct driver monitoring data Obstacle State Obstacle State Pedestrian StatePedestrian State Natural Environment StateNatural Environment State Surrounding Mobility State Surrounding Mobility State Ego vehicle driving state Automated driving control command Indirect driver monitoring dataDriver on-board system use Driver manuever command Navigation information Driver navigation system use Transport Infrastrucure State Transport Infrastrucure State Navigation information Ego vehicle navigation related data Surrounding vehicle navigation related data Transport infrastrucure information Traction Force Driving force Navigation information システムモデルの記述 コンテキストレベルのSoSの記述   ドライバ 自車 交通インフラ 周辺モビリティ 自然環境 歩行者 物理環境 自動運転   システム ICT   システム 2014年度ソフトウェア工学分野の先導的研究支援事業   システムモデルと繰り返し型モデル検査による次世代自動運転車を取り巻くSoSのアーキテクチャ設計 30 Copyright©2014 Hidekazu Nishimura.
• 31. モデル検査による安全性の検証 }  SoS全体が本プロジェクトで定義する安全性を満たすかどうか を検証するためにモデル検査を用いる。   安全性要求 の明確化 SoS アーキテクチャ 状態機械図 （ステートマシーン図） モデル検査式 モデル検査用 モデル SysMLモデル SoSを並行システムと考 え、CSP（Communica2ng   Sequen2al   Processes）モ デルを作成 CSPモデル：並行システムの 「構造」や入出力の「動作」 を表すことができるモデル アシュランスケース 31 2014年度ソフトウェア工学分野の先導的研究支援事業   システムモデルと繰り返し型モデル検査による次世代自動運転車を取り巻くSoSのアーキテクチャ設計 Copyright©2014 Hidekazu Nishimura.
• 32. SERA •  システムズエンジニアリング研究会 •  発起⼈人：内⽥田功志（システムビューロ）、井上樹（⾖豆蔵）。 •  ⽇日本で事例例収集がし難いので、事例例開発（植物⼯工場）。 32   Copyright  (C)  2014  Change  Vision  CorporaEon.  All  Rights  Reserved.   1
• 33. Assurance  Case GSN/D-‐‑‒Case (Goal  Structuring  Notation ゴール指向で議論論を記述) 33   2
• 34. GSNの記法と例例
• 35. GSN(D-‐‑‒Case) •  ある「主張」を行うための議論構造をグラフィカルに表現し た図(Goal Structuring Notation) •  ヨーク大学 Tim Kelly の研究。 •  セーフティケースを記述する手法として利用される。 •  ノードとして、「ゴール」（主張）、「戦略」、「コンテキスト」、 「ソリューション」（証拠）、などがある。 •  ゴールをサブゴールに分割し、ソリューション（証拠）と結 んで立証する。 •  Safety 以外にも Dependability やSecurity を Assure す る用途に使えるので、 「Assurance Case」と総称する。 •  D-Case: GSNを拡張し、デペンダビリティケースを表現す る、DEOSで開発された記法
• 36. セキュリティにGSNを利利⽤用する例例 36   Copyright  (C)  2014  Change  Vision  CorporaEon.  All  Rights  Reserved.   •  DHS(⽶米国国⼟土安全保障省省)のリソース
• 37. GSNによるセキュリティ(1) 37  
• 38. GSNによるセキュリティ(2) 38  
• 39. SafeML (設計情報と安全情報をつなぐ) 39   3
• 40. SafeML •  産総研  Geoffrey  Biggs  ⽒氏が  SysML  の拡 張Profileとして開発 •  「設計情報」と「安全情報」のトレーサ ビリティを⽬目的とする。 •  Hazard,  Harm,  Context  を組として、設 計情報上に危険情報対応する安全情報を 追加する。 •  GSNとの接続事例例も。 40   Copyright  (C)  2014  Change  Vision  CorporaEon.  All  Rights  Reserved.  
• 41. SafeMLのコンセプト Hazard（危険）: •  「危害」の潜在源 •  システムは関連する危害を引き起こす可能性が常に有る。 •  システムのコンポーネント、設計、使われ⽅方（要求とユース ケース）に関連。 Harm（危害)： •  直接または間接的に与えられる、⼈人の健康に対する⾁肉体的障害 または損傷 •  特定の「状況」で特定の「危険」により及ぼされる。 Context(状況)： •  「危険」が「危害」を引き起こせる危険状況（コンテキスト） •  コンテキストが出ると「危険事象」(hazardous  event) •  「危害」が起きたら「危害事象」(harmful  event) 41   Copyright  (C)  2014  Change  Vision  CorporaEon.  All  Rights  Reserved.  
• 42. 42  
• 43. 43  
• 44. Safety  Model  and  Systems  Model    -­‐  GSN/MARTE/SysML/SafeML     integraEon  in  RoboEcs   Geoffrey  Biggs  (AIST)   Toshihiro  Okamura(Change  Vision,  Inc.)   12月にOMGで発表された事例。 hQp://www.slideshare.net/hiranabe/omg-­‐safety-­‐modelsystemsmodel20141210final http://www.slideshare.net/hiranabe/omg-safety-modelsystemsmodel20141210final 3
• 45. SysML・ UML/ MARTE   GSN Describes system safety cases. Describes system and software models SafeML Example robot (from AIST) (Extension to SysML) Describes hazards and harms related to the system Goal: •  Demonstrate the effectiveness of using GSN/SafeML/SysML/MARTE together. Overview  
• 46. Modelling  process GSN • Design  argument  for  how  system  will  be  developed  to  be  safe  (safety  analyses  to  be   performed,  design  methods,  etc.) SysML • Model  a  system  that  meets  the  requirements SafeML • Add  safety  analysis  results  to  system  model  to  aQain  traceability  between  safety   analysis  and  system  features  (safety  requirements) SysML • Revise  system  design  to  implement  required  safety  features MARTE • Add  implementaEon  details  and  analyse  model  for  feasibility  of  design GSN • Revise  argument  based  on  actual  steps  performed  and  work  products • Link  GSN  argument  to  system  model  to  provide  context  and  soluEons Language Objectives
• 47. GSN  model Safety requirement verification result Sn6 * Hazard analysis statement * Risk assessment statement C6 DRC is acceptably safe G1 All hazards have been identified sufficiently G4 Basic Requirement for Safety: (1) DRC should be safe for using in the second office in the main building of AIST (2) DRC should be safe for users who are not familiar with electric wheelchair C2 Hazard analysis statement Sn1 Risks have been analyzed and evaluated properly. And the ways of eliminating the risks are analyzed properly. G5 Risk assessment statement (each phase) Sn2 Activities in each phases of the lifecycle of DRC have been figured out G10 Primitive hazards have been figured out comprehensively by using the hazard identification checklist of JIS B 9700 and ISO13482 G12 Product brief C7 Hazard identification checklist of JIS B 9700:2013 (Table B.1) C9 Hazard identification checklist of ISO13482 (Annex A) C11 The lists of hazards for each phases of the lifecycle have been created by matching the activities and the hazards figured out by checklists G13 Table B.3: 'List of risky activities' of JIS B 9700 (Standard for safety of machinery) C8 Phase： Specification, transport, installation, setting, maintenance, emergency response, removal Figuring out hazards and activities to identify risks that inhibit the safety S2 Kinds of improper use have been identified G11 Hazard identification checklist of JIS B 9700:2013 (Table B.3) C10 Product brief C1 Discuss separately with deriving safety requirements and implementing safety requirements S1 Hazard analysis statement C5 Required risk reduction measures have been defined properly G17 Risks have been reduced to less than the allowable level by risk reduction measures G18 Safety requirements have been derived properly from the risk reduction measures G6 All safety requirements have been implemented G3 Safety requirement definition document Sn3 All risks have been estimated by following the estimation rules G15 Acceptable range of risk has been decided properly G16 Safety requirement definition document C4 The way of estimating risks has been defined concretely G14 Safety requirements have been led to properly G2 Break down by activities S3 The completed product has satisfied all safety requirements G9 The way of testing the completed product has been defined property depending on the safety requirements G8 Validation plan document Sn5 Safety requirements have been adapted to the design G7 System design model (SysML, SafeML) Sn4 ISO13482:2014 (Standard related to the safety of the personal care robots) C3 (1) (2) (3) (4)
• 48. GSN  model  (1) DRC is acceptably safe G1 Basic Requirement for Safety: (1) DRC should be safe for using in the second office in the main building of AIST (2) DRC should be safe for users who are not familiar with electric wheelchair C2 Product brief C1 Discuss separately with deriving safety requirements and implementing safety requirements S1 All safety requirements have been implemented G3 Safety requirement definition document C4 Safety requirements have been led to properly G2 ISO13482:2014 (Standard related to the safety of the personal care robots) C3
• 49. [package] Safety diagrams [36a. Riding user touches a wheel during motion and gets their hand or fingers caught]bdd < < Hazard> > < < block> > Moving m echanical com ponents < < Harm> > < < block> > Dislocated joints, broken bones or choking < < block> > Wheel cover < < DefenceResult> > < < block> > Wheel covers result < < block> > Electric m otor < < block> > Wheel < < HarmContext> > < < block> > 36a. Riding user touches a wheel during m otion and gets their hand or fingers caught < < deriveHzd> >< < deriveHzd> > < < block> > Wheel < < deriveHC> > < < PassiveDefence> > < < block> > Wheel covers < < requirement> > text = The wheels shall be covered such that the user and objects cannot touch them during motion. Id = 140 Wheel covers < < reqDefence> > < < satisfy> > SafeML   System components, activities, etc. Sources of hazard Hazard Potential harm Hazardous situation/event Result of safety measure Safety measure Safety requirement
• 50. SafeML   [package] Wheelchair robot [Wheelchair robot]bdd < < block> > Elect ric m ot or < < block> > Wheel < < block> > Drive t rain < < block> > Drive unit < < system > > < < block> > Wheelchair robot Right drive unit < < block> > Wheel cover 2 [package] Safety diagrams [36a. Riding user touches a wheel during motion and gets their hand or fingers caught]bdd < < Hazard> > < < block> > Moving mechanical components < < Harm> > < < block> > Dislocated joints, broken bones or choking < < block> > Wheel cover < < DefenceResult> > < < block> > Wheel covers result < < block> > Electric motor < < block> > Wheel < < HarmContext> > < < block> > 36a. Riding user touches a wheel during motion and gets their hand or fingers caught < < deriveHzd> >< < deriveHzd> > < < block> > Wheel < < deriveHC> > < < PassiveDefence> > < < block> > Wheel covers < < requirement> > text = The wheels shall be covered such that the user and objects cannot touch them during motion. Id = 140 Wheel covers < < reqDefence> > < < satisfy> >
• 51. SCDL (Safety  Concept  Description  Language: ISO26262安全コンセプトの説明性を向上) 51   4
• 52. SCDL •  DNV  ⼭山下修平⽒氏が、ISO26262の重要成 果物のレビュー過程から発案。 •  「安全要求」の構造、「エレメント」の 構造、ASILの付与規則、を記法とルール として「⾔言語化」 •  安全コンセプト記法研究会で仕様化中。 52   Copyright  (C)  2014  Change  Vision  CorporaEon.  All  Rights  Reserved.  
• 53. 53   http://scn-sg.com/
• 54. 安全コンセプト図 54   Copyright  (C)  2014  Change  Vision  CorporaEon.  All  Rights  Reserved.  
• 55. エレメントツリー 要求ツリー エレメント構造図 エレメント 安全要求構造図 安全要求 安全コンセプト図
• 56. 基本構成要素(1/2) •  「エレメント」 56   Copyright  (C)  2014  Change  Vision  CorporaEon.  All  Rights  Reserved.   Sub-‐‑‒sys01 SYSXX Sub-‐‑‒sys02 ECU01 SENS01 mC01 eSW01
• 57. 基本構成要素(2/2) •  「要求」と「インタラクション」 57   Copyright  (C)  2014  Change  Vision  CorporaEon.  All  Rights  Reserved.  
• 58. ダイアグラム 　ー 　安全コンセプト図 •  安全コンセプトを分かりやすく設計できる図 –  要求のインタラクション –  エレメントの配置構成 –  要求とエレメントのアロケーション –  ASILアサインメント 58   Copyright  (C)  2014  Change  Vision  CorporaEon.  All  Rights  Reserved.  
• 59. 認証⼯工学WG (SafetyとSecurityの⼆二重認証 コストをモジュール化で低減) 59  
• 60. 認証⼯工学 •  産総研  ⽥田⼝口研治⽒氏が、規格の共通点に注 ⽬目し、複数の規格の認証コストを下げる ための⼯工学的⼿手法を提唱。 •  計測⾃自動制御学会のWGとして設置。 •  規格のメタモデル化を通して、共通部と 差違部を認識識し、認証を構造化、モ ジュール化。 60   Copyright  (C)  2014  Change  Vision  CorporaEon.  All  Rights  Reserved.  
• 61. 61   •  安全性・信頼性・セキュリティの認証適合作業・取得のコストによる開発の圧迫。 •  認証取得で要求される成果物のレベル・質の第三者認証機関ごとの違い。 •  認証機関とのコミュニケーションギャップ、共通理理解の⽋欠如による認証取得期間の延⻑⾧長と市場へ の製品出荷の遅延。 •  規格・ガイドラインの効率率率的な策定、合意形成のためのプロセスなどに対する⽅方法論論の⽋欠如によ る発⾏行行時の時代背景との乖離離。 •  規格・ガイドラインの解釈が多義的であり、学習コストが⾼高い。 •  複数の規格の認証(安全性とセキュリティなど)を取得するための効率率率的な⽅方法論論の確⽴立立。 •  規格に適合していても、必ずしもシステムの品質が向上しない。 以上のような課題の解決のために、⼯工学的、科学的アプローチを⾏行行うことを⽬目的とするのが、認証⼯工 学（Certification Engineering）になります。 http://www.sice.or.jp/org/ce-wg/
• 62. Are  You   Modeling? (現代モデリング技術の情報源) 62  
• 63. 63   http://areyoumodeling.com
• 64. 64   http://ja.areyoumodeling.com
• 65. まとめ •  情報系システム開発、スタートアップWebビジ ネスで主流流になりつつあるアジャイル開発の考 え⽅方が、組込み系にも影響を与えている。本質 的な不不確実性を扱う際に必須の考え⽅方。 •  同様に、モデリング技術もさまざまな記法が提 案され、実⽤用に⼊入っている。情報をモデル化す ることで、ステークホルダー合意の構築、分析 容易易性向上、認証、さらに計算機利利⽤用の可能性 が広がる。 65   Copyright  (C)  2014  Change  Vision  CorporaEon.  All  Rights  Reserved.   ツール等の情報必要な方は、 kenji.hiranabe  at  change-­‐vision.com  までどうぞ。