Agile and Modeling Approach Used in Embedded systems safety and security.

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
までどうぞ。