Safety/Securityへのアジャイル開発とモデルベース …•°学のソフトウェアへの導入の心は日本的開発手法そのものである…” キーワード:

Safety/Securityへのアジャイル開発とモデルベース開発

アプローチ

株式会社チェンジビジョン

平鍋健児

1

2

≪講演概要≫

昨今、システム開発でますます使われるようになってきたモデルベース開発手法とアジャイル開発手法。

これらは、複雑化するシステム開発を一方は抽象化、可視化によって、もう一方はエンピリカルで人間中心な活動として解決しようとしている。一方、高信頼化が求められるシステム開発においても、これらのアプローチが影響をおよぼしはじめている。

本セッションでは、「アジャイル開発手法」と「モデルベース開発手法」を外観した後、それぞれの手法がセイフティやセキュリティのエリアでどのように使われるようになってきているか、ご紹介する。

3

自己紹介㈱永和システムマネジメント

– 福井市（本社）、上野東京（支社）

– Ruby と Agileを使ったシステム開発

株式会社チェンジビジョン – 福井市（開発部）、上野東京（本社）

– astah* (旧：JUDE) の開発

平鍋健児 – UML+マインドマップエディタ astah*の開発

– 要求開発アライアンス、理事

– 翻訳、XP関連書籍、『リーン開発の本質』『IMPACT MAPPING』等多数。

– 著書『アジャイル開発とスクラム』、『要求開発』『ソフトウェア開発に役立つマインドマップ』

http://www.amazon.co.jp/UML%E3%83%AF%E3%83%BC%E3%82%AF%E3%83%96%E3%83%83%E3%82%AF-%E5%B1%B1%E7%94%B0-%E5%81%A5%E5%BF%97/dp/4798101931/sr=8-1/qid=1169464250/ref=sr_1_1/249-9729823-0184359?ie=UTF8&s=books

http://www.amazon.co.jp/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%86%E3%82%AF%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC%E3%83%AF%E3%83%BC%E3%82%AF%E3%83%96%E3%83%83%E3%82%AF-VOL-3%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3%E3%83%AF%E3%83%BC%E3%82%AF%E3%83%96%E3%83%83%E3%82%AF-%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E5%80%B6%E6%A5%BD%E9%83%A8-%E5%B2%A1%E6%9D%91-%E6%95%8F%E5%BC%98/dp/479810194X/sr=8-1/qid=1169464278/ref=sr_1_1/249-9729823-0184359?ie=UTF8&s=books

http://astah.change-vision.com/

4

• 顧客・技術・経営の３者をつなぐために、アジャイルと日本経営の接合点を探る

• 海兵隊の組織とアジャイル • 知識創造プロセスとアジャイル • 実践知リーダーとアジャイル • 富士通・楽天・リクルートの事例 • Jeff Sutherlandインタビュー

『アジャイル開発とスクラム』

平鍋健児＋野中郁次郎著

アジャイル開発の背景 (情報系から組込み系へ)

5

6

市場ビジネス IT

市場分析発注

納品リリース

半年から３年

ミッション・リスク分割型ビジネスとウォーターフォール型開発（従来型）

従来型の問題＝要求の劣化

• Standish group study report in 2000 chaos report

7

システムの機能の利用度

全く使われない45%ほとんど使われな

い19%

たまに使う16%

いつも使う7%

よく使う13%

8

市場

IT

ミッション・リスク共有型ビジネスとAgile型開発

ビジネス

市場

ビジネスとITが一体になった「OneTeam」を作り、ミッションとリスクを共有する。やってみて、結果から戦略を作りながら進む。

スクラムのフレームワーク

9

製品

バックログ

スプリント

バックログ

1-4 週

24 時間

出荷可能

ソフトウェア

朝会

10

IDEAS

CODE DATA

BUILD LEARN

MEASURE

素早くコード

単体テストユーザビリティテスト

継続的結合漸進開発

オープンソース利用クラウド

クラスタ免疫システム JITスケーラビリティリファクタリング

デベロパーサンドボックス

素早く測定

AB テスト明確なプロダクトオーナ継続的開発ユーザビリティテストリアルタイムモニタ顧客代表

素早く学習

AB テスト顧客インタビュー顧客開発なぜなぜ5回、真因分析顧客アドバイザリボード仮説検証プロダクト・オーナーの責任顧客タイプ分析機能横断チーム半自立チームスモークテスト

漏斗分析コホート分析

ネットプロモータスコア検索エンジンマーケティング

リアルタイムアラート予測的モニタリング

LeanStartup

組込みシステムでも(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

組込みシステムでも(2)… DEOS： The Open Groupで標準化

12 出典: DEOS協会 http://deos.or.jp/technology/process-j.html

13

アジャイル開発

• (1) 市場（何を作るか）が不安定

• (2) 技術（どうやって作るか）が不安定

ともに、予見できない

• 「作って試す」繰り返しが必要

• エンピリカルで人間活動を考慮した手法

• SoS(System of Systems) やセキュリティでは「相手」を知りきれない。

14 Copyright (C) 2014 Change Vision Corporation. All Rights Reserved.

本質的な不確実さ

モデリング技術

15

16

情報システム組込みシステム

物

メカCAD ECAD

制御

ソフトウェア

UML （離散系/

情報系） Simulink(連続系/制御系)

UML,ER, DFD,BPMN..(データ,プロセス,..）

システムのモデルリング言語

SysML(要求、構造、振舞、制約) SysML(統合系)

システム/SoS

SysML(要求、構造、振舞、制約)

アシュランス

GSN(D-Case) 保証議論

SafeML(安全+設計情報)

SCDL (ISO26262の

安全コンセプト)

2

4

3

1

SysML (Systems Modeling Language

MBSEの言語)

17

SysMLを使ったRTCベースのロボットアプリケーション開発 : 事例ケースタディとデモ

平鍋健児(Change Vision, Inc) 安藤慶昭(産総研)

一昨年OMGで発表された事例。 http://www.slideshare.net/hiranabe/using-sysml-in-a-rtcbased-robotics-application-a-case-study-with-a-demo

プロジェクトメンバー

Honda R&D Team

安藤慶昭

平鍋健児

岩永寿来

岡村敏弘

関谷眞

原功

鳥井豊隆

SysML to RTC 1 2 OpenRTM to Honda RTM

Geoffrey Biggs

自律ロボットを遠隔操作し、２つの動き (Spiral と Back-and-

Forth) をさせる。Operatorは自律

モードとデモモード切り替えることができる。

ハードウェアアーキテクチャはあらかじめ決まっている。PCを乗せたRoombaを、Wi-Fi通信で、Kinectを使ってモードスイッチする。

問題記述

kinect

Operator Controller PC

Receiver PC

Roomba

Wi-Fi

req [コア要求(問題文)]

req [Robotへの要求]

uc [デモユースケース]

bdd [コンテキスト図]

bdd [システム概要]

ibd [デモシステム]

ibd [controller物理構造]

SysMLとSoS

• 慶応大学大学院ＳＤＭ西村秀和先生の事例

• IPA(RISE) ソフトウェア工学分野の先導的研究支援事業(2014年実施中)

• 自動運転車を例題に、SoSアーキテクチャの参照モデルを構築

28

研究概要次世代自動運転車の導入に向け、それを取り巻く交通インフラ、各種情報システムを含む周辺環境、ドライバなどをSystem of Systems（SoS）として捉えた上で、安全性を考慮したアーキテクチャを構築する。

自動運転技術の研究のみでは、システムレベルでの安全性の確保は難しいため、安全なSoSアーキテクチャを構築することが課題と考える。

29

2014年度ソフトウェア工学分野の先導的研究支援事業

システムモデルと繰り返し型モデル検査による次世代自動運転車を取り巻くSoSのアーキテクチャ設計

Copyright©2014 Hidekazu Nishimura.

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 StateObstacle State

Pedestrian StatePedestrian State

Natural Environment StateNatural Environment State

Surrounding Mobility StateSurrounding 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 forceNavigation information

システムモデルの記述コンテキストレベルのSoSの記述

ドライバ

自車

交通インフラ

周辺モビリティ

自然環境

歩行者

物理環境

自動運転システム

ICT システム


システムモデルと繰り返し型モデル検査による次世代自動運転車を取り巻くSoSのアーキテクチャ設計 30


モデル検査による安全性の検証

SoS全体が本プロジェクトで定義する安全性を満たすかどうかを検証するためにモデル検査を用いる。

安全性要求

の明確化

SoS

アーキテクチャ

状態機械図

（ステートマシーン図）

モデル検査式モデル検査用

モデル

SysMLモデル SoSを並行システムと考え、CSP（Communicating Sequential Processes）モデルを作成

CSPモデル：並行システムの

「構造」や入出力の「動作」を表すことができるモデル

アシュランスケース

31


システムモデルと繰り返し型モデル検査による次世代自動運転車を取り巻くSoSのアーキテクチャ設計


SERA

• システムズエンジニアリング研究会

• 発起人：内田功志（システムビューロ）、井上樹（豆蔵）。

• 日本で事例収集がし難いので、事例開発（植物工場）。


Assurance Case GSN/D-Case

(Goal Structuring Notation ゴール指向で議論を記述)

33

GSNの記法と例

GSN(D-Case)

• ある「主張」を行うための議論構造をグラフィカルに表現した図(Goal Structuring Notation)

• ヨーク大学 Tim Kelly の研究。

• セーフティケースを記述する手法として利用される。

• ノードとして、「ゴール」（主張）、「戦略」、「コンテキスト」、「ソリューション」（証拠）、などがある。

• ゴールをサブゴールに分割し、ソリューション（証拠）と結んで立証する。

• Safety 以外にも Dependability やSecurity を Assure する用途に使えるので、「Assurance Case」と総称する。

• D-Case: GSNを拡張し、デペンダビリティケースを表現する、DEOSで開発された記法

セキュリティにGSNを利用する例


• DHS(米国国土安全保障省)のリソース

GSNによるセキュリティ(1)

37

GSNによるセキュリティ(2)

38

SafeML (設計情報と安全情報をつなぐ)

39

SafeML

• 産総研 Geoffrey Biggs 氏が SysML の拡張Profileとして開発

• 「設計情報」と「安全情報」のトレーサビリティを目的とする。

• Hazard, Harm, Context を組として、設計情報上に危険情報対応する安全情報を追加する。

• GSNとの接続事例も。


SafeMLのコンセプト

Hazard（危険）:

• 「危害」の潜在源

• システムは関連する危害を引き起こす可能性が常に有る。

• システムのコンポーネント、設計、使われ方（要求とユースケース）に関連。

Harm（危害)：

• 直接または間接的に与えられる、人の健康に対する肉体的障害または損傷

• 特定の「状況」で特定の「危険」により及ぼされる。

Context(状況)：

• 「危険」が「危害」を引き起こせる危険状況（コンテキスト）

• コンテキストが出ると「危険事象」(hazardous event)

• 「危害」が起きたら「危害事象」(harmful event)


42

43

Safety Model and Systems Model - GSN/MARTE/SysML/SafeML integration in Robotics

Geoffrey Biggs (AIST) Toshihiro Okamura(Change Vision, Inc.)

12月にOMGで発表された事例。 http://www.slideshare.net/hiranabe/omg-safety-modelsystemsmodel20141210final

http://www.slideshare.net/hiranabe/omg-safety-modelsystemsmodel20141210final

SysML・UML/M

ARTE 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

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 attain traceability between safety analysis and system features (safety requirements)

SysML • Revise system design to implement required safety features

MARTE • Add implementation 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 solutions

Language Objectives

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 ofJIS 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


C10

Product brief

C1

Discuss separately with deriving safety requirements and implementing safety requirements

S1


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


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)

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


G3


C4


G2

ISO13482:2014(Standard related to the safety of the personal care robots)

C3

GSN model (2)

All hazards have been identified sufficiently

G4


Sn1

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


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

Figuring out hazards and activities to identify risks that inhibit the safety

S2

Kinds of improper use have been identified

G11


C10


G2

GSN model (3)

* Hazard analysis statement* Risk assessment statement

C6

Risks have been analyzed and evaluated properly. And the ways of eliminating the risks are analyzed properly.

G5

Risk assessment statement (each phase)

Sn2 Phase：Specification, transport, installation, setting, maintenance, emergency response, removal


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


Sn3

All risks have been estimated by following the estimation rules

G15

Acceptable range of risk has been decided properly

G16

The way of estimating risks has been defined concretely

G14


G2

Break down by activities

S3

GSN model (4)

Safety requirement verification result

Sn6


G3


C4

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

[ package] Safet y d iagram s [ 36a. Rid ing user t ouches a wheel during m ot ion and get s t heir hand or fingers caught ]bdd

< < Hazard> >< < block> >

M oving m echan ical com ponent s

< < Harm > >< < block> >

Dislocat ed join t s, b roken bones or choking

< < block> >Wheel cover

< < DefenceResult > >< < block> >

Wheel covers resu lt

< < block> >Elect r ic m ot or

< < block> >Wheel

< < Harm Context> >< < block> >

36a. Rid ing user t ouches a wheel during m ot ion and get s t heir hand or fingers caught

< < deriveHzd> >< < deriveHzd> > < < block> >Wheel

< < deriveHC> >

< < PassiveDefence> >< < block> >

Wheel covers

< < requirem ent> >

text = The wheels shall be covered such t hat t he user and object s

cannot t ouch t hem during m ot ion.

Id = 140

Wheel covers

< < reqDefence> >

< < sat isfy> >

SafeML

System components, activities, etc. Sources

of hazard

Hazard

Potential

harm

Hazardous

situation/event

Result of

safety measure

Safety

measure

Safety

requirement

SafeML

[ package] Wheelchair robot [Wheelchair robot ]b d d


< < block> >Wheel

< < block> >Drive t rain

< < block> >Drive u n it

< < system > >< < block> >

Wh eelchair robot

Right drive un it


2

[ package] Safet y d iagram s [ 36a. Rid ing user t ouches a wheel during m ot ion and get s t heir hand or fingers caught ]bdd

< < Hazard> >< < block> >

M oving m echan ical com ponent s

< < Harm > >< < block> >

Dislocat ed join t s, b roken bones or choking


< < DefenceResult > >< < block> >

Wheel covers resu lt


< < block> >Wheel

< < Harm Context> >< < block> >

36a. Rid ing user t ouches a wheel during m ot ion and get s t heir hand or fingers caught

< < deriveHzd> >< < deriveHzd> > < < block> >Wheel

< < deriveHC> >

< < PassiveDefence> >< < block> >

Wheel covers

< < requirem ent> >

text = The wheels shall be covered such t hat t he user and object s

cannot t ouch t hem during m ot ion.

Id = 140

Wheel covers

< < reqDefence> >

< < sat isfy> >

SCDL (Safety Concept Description Language: ISO26262安全コンセプトの説明性を向上)

54

SCDL

• DNV 山下修平氏が、ISO26262の重要成果物のレビュー過程から発案。

• 「安全要求」の構造、「エレメント」の構造、ASILの付与規則、を記法とルールとして「言語化」

• 安全コンセプト記法研究会で仕様化中。


56 http://scn-sg.com/

安全コンセプト図


エレメントツリー要求ツリーエレメント構造図

エレメント

安全要求構造図

安全要求

安全コンセプト図

基本構成要素(1/2)

• 「エレメント」


Sub-sys01

SYSXX

Sub-sys02

ECU01 SENS01

mC01

eSW01

基本構成要素(2/2)

• 「要求」と「インタラクション」


ダイアグラムー安全コンセプト図

• 安全コンセプトを分かりやすく設計できる図

– 要求のインタラクション

– エレメントの配置構成

– 要求とエレメントのアロケーション

– ASILアサインメント


認証工学WG (SafetyとSecurityの二重認証コストをモジュール化で低減)

62

認証工学

• 産総研田口研治氏が、規格の共通点に注目し、複数の規格の認証コストを下げるための工学的手法を提唱。

• 計測自動制御学会のWGとして設置。

• 規格のメタモデル化を通して、共通部と差違部を認識し、認証を構造化、モジュール化。


64

• 安全性・信頼性・セキュリティの認証適合作業・取得のコストによる開発の圧迫。

• 認証取得で要求される成果物のレベル・質の第三者認証機関ごとの違い。 • 認証機関とのコミュニケーションギャップ、共通理解の欠如による認証取得期間の延長と市場へ

の製品出荷の遅延。 • 規格・ガイドラインの効率的な策定、合意形成のためのプロセスなどに対する方法論の欠如によ

る発行時の時代背景との乖離。

• 規格・ガイドラインの解釈が多義的であり、学習コストが高い。

• 複数の規格の認証(安全性とセキュリティなど)を取得するための効率的な方法論の確立。

• 規格に適合していても、必ずしもシステムの品質が向上しない。

以上のような課題の解決のために、工学的、科学的アプローチを行うことを目的とするのが、認証工学（Certification Engineering）になります。

http://www.sice.or.jp/org/ce-wg/

Are You Modeling?

(現代モデリング技術の情報源)

65

66 http://areyoumodeling.com

67 http://ja.areyoumodeling.com

まとめ

• 情報系システム開発、スタートアップWebビジネスで主流になりつつあるアジャイル開発の考え方が、組込み系にも影響を与えている。本質的な不確実性を扱う際に必須の考え方。

• 同様に、モデリング技術もさまざまな記法が提案され、実用に入っている。情報をモデル化することで、ステークホルダー合意の構築、分析容易性向上、認証、さらに計算機利用の可能性が広がる。


Documents

Safety/Securityへの アジャイル開発と モデルベース …•°学のソフトウェ アへの導入の心は 日本的開発手法そ のものである…” キーワード:

Safety/Securityへのアジャイル開発とモデルベース …•°学のソフトウェアへの導入の心は日本的開発手法そのものである…” キーワード: