ツールアーキテクチャ構想 - TERAS Web Site

TERAS 成果報告会
ツルアキテクチャ構想
ツールアーキテクチャ構想
TERAS理事 CATS取締役副社長
渡辺政彦, Ph.D.
九州工業大学大学院情報工学研究院客員教授
2011/3/19
議題
1.
2.
3.
2
TERASの１年間をメディアとともに振り返る
TERASと機能安全
TEARSとアーキテクチャ
© CATS 2012
メディア
http://techon.nikkeibp.co.jp/article/NEWS/20110808/194952/
http://techon nikkeibp co jp/article/NEWS/20111005/199024/?ref=RL3
http://techon.nikkeibp.co.jp/article/NEWS/20111005/199024/?ref=RL3
3
Copyright © 2011 一般社団法人TERAS All Rights
Reserved.
メディア
合同ワークショップで共同研究分野を決定
独立行政法人情報処理推進機構（IPA）とフランスの原子力・代替エネルギー庁シ
ステム技術統合研究所（CEA LIST）は、2月21日から3日間にわたり沖縄県那覇市で
合同ワークショップを開催した。2011年10月に締結された「研究協力に関する相互
協力協定」に基づくもので、ソフトウェアの信頼性に関する国際的な枠組みでの協力
関係を結ぶにあたり、双方のこれまでの取り組みを理解し、具体的な共同研究分野を
探るのが主な目的だ。
最終日の23日には、その成果として複雑かつ高度な高信頼性システムを主な対象
とした次の3項目についての重要性を共有し継続的な情報交換と人的交流を行うこ
とした次の3項目についての重要性を共有し、継続的な情報交換と人的交流を行うこ
とへの合意が発表された。
1. モデルベースエンジニアリングとトレーサビリティの確保
1
モデルベスエンジニアリングとトレサビリティの確保
2. 高信頼システムの品質評価・監査の仕組みの確立
3. 準形式手法への継続的な取り組み
http://builder.japan.zdnet.com/os-admin/35014581/2/#
4
Copyright © 2011 一般社団法人TERAS All Rights
Reserved.
メディア指摘事項
http://techon.nikkeibp.co.jp/article/NEWS/20111221/202893/?ref=RL3
組み込みソフトウエア分野において、日本でも要件管理の導入が進みつつある。
要件の実現はシステムの開発において必ず求められることなので、これまでもExcelなどを駆使すること
で、要件の管理や実現は何らかの形で実施されてきた。
だが、近年、ソフトウエアを含んだシステムの複雑性が増すにつれ、その安全性に関して説明責任を向
上させようとの意識がさまざまな業界で高まってきた。ハザード解析およびリスク・アセスメントを行い、安
全要件を立てた後それらが後工程の成果物にキッチリと反映されているか膨大な要件に対してそれを
全要件を立てた後、それらが後工程の成果物にキッチリと反映されているか。膨大な要件に対してそれを
体系的に追跡することが求められつつある。いわゆる、要件のトレーサビリティの確保である。
いくら要件管理を徹底し、トレーサビリティを確認しようとも、肝となる上流のリスク・アセスメントが不適切
であれば安全性の向上にはつながらないが、打ち立てた安全要件が膨大なソフトウエアの中のどこに、ど
のように反映されているのかを管理することは、少なくとも安全性の説明の根拠として重要である。また、
将来的に要件が変更された場合、それがどの範囲にまで影響するかというインパクト解析でも、要件のト
レーサビリティは有効だ。
変更管理や構成管理についてはここ10年ほどの開発プロセスの改善活動の積み上げにより日本の
変更管理や構成管理については、ここ10年ほどの開発プロセスの改善活動の積み上げにより、日本の
組み込みソフトウエア開発の現場にも既に浸透しつつある（関連記事01）。また、オープン・ソースのツー
ルも確立しているため、導入の障壁もそれほど高くない。
一方、要件管理となると、体系的に実施している組織は、日本ではまだ少数派のようだ。要件管理ツー
ルについても、オープン・ソースのものはほとんどなく、商用ツールから選ばざるを得ない。
もオプ
も
んどなく商
から選ばざるを得な
5
Copyright © 2011 一般社団法人TERAS All Rights
Reserved.
焦点はメカ系PLMとの連携
自動車業界において要件管理ツールを導入する際、一つのポイントとなるのが、メカ
系や電子系のPLMツルとの連携である。安全設計とはソフトウエアのみで実現す
系や電子系のPLMツールとの連携である。安全設計とはソフトウエアのみで実現す
るものではなく、ハードウエアも含めたシステム全体で対処すべきもの（関連記事
03）。そうなると、要件管理やそのトレーサビリティをソフトウエア系の部署だけで閉じ
て運用していても意味がない。
て運用していても意味がない
メカ系PLMにもトレーサビリティの概念はあるが、「PLMとソフトウエア系の要件管理
ツールとでは、トレーサビリティの粒度が異なる。ソフトウエアの場合、関数単位でト
ルとではトレサビリテの粒度が異なる
トウアの場合関数単位でト
レーサビリティを確認する必要があるが、PLMでは図面単位。このためメカ系PLMの
トレーサビリティをソフトウエア開発に適用するのは無理がある」（サプライヤーの技
術者）。
術者）
PLMベンダーであるPTC社がMKS社を買収したりなど、ツール・ベンダー自体は融
合の方向に向かっている（関連記事04）。今後は実際のツール面でも連携が始まる
だろう。
6
Copyright © 2011 一般社団法人TERAS All Rights
Reserved.
国産の無償ツールも追いかける
「ソフトウエア開発ツールは日本製が少ない」と言われているが、この
要件管理ツールの分野では実は日本勢も正面から戦いを挑もうとして
いる。
経済産業省から約5億円の助成を受け、組み込みソフトウエア開発
ツール・ベンダーのキャッツなどが中心となって、「TERAS」というツー
ル基盤を目下、開発中である（関連記事05、関連記事06）。
ISO 26262対応という観点では、要件管理ツールの導入・整備は自
動車業界では喫緊の課題となっているこのため数年後の完成を目指
動車業界では喫緊の課題となっている。このため数年後の完成を目指
すTERASについては、「少し遅すぎたのでは」「数年前の段階で欲し
かった」という声が多い。ただし、ツールのコア部分についてはTERAS
は無償提供を目指しているため、いざ完成すれば既存ツールに対し一
定の競争力は発揮するかもしれない。今後の仕上がりに期待したいと
ころである
ころである。
7
Copyright © 2011 一般社団法人TERAS All Rights
Reserved.
PLM ‒ ALM連携
PLM
Safety Case
ALM
Variation
Requirements Management
Change Management
Software
Soft
e Configuration
Config
tion
Management
Architecture Management
Quality Management
8
© CATS 2012
Traceability
TERAS コンセプトと仕上がり
ALM ALM(Application Lifecycle Management)
EPM
Plug‐in
Traceability
Plug‐in
61508
Plug‐in
26262
Plug‐in
ETSS
Plug‐in
REST (Representational State Transfer)
OSLC (Open Services for Lifecycle Collaboration)
REST
OSLC
OSLC TRA
OSLC CM
OSLC SCM
OSLC SPM
OSLC AM
Cloud
Traceability
Repository
TERAS-TRA
Empirical Project
Monitor Repository
IPA
TERAS function
Version Control
Repository
Subversion
Open tool
9
Bug Tracking
Repository
Trac
State Transition
Model Repository
ZIPC
Third vendor (Existing)
O‐Data
G‐Data
Microsoft®
Office
Google™
code
MS Office
ff
l
Google
Third vendor (New)
© CATS 2012
TERASのコンセプト
1.
開発の現場にも既に浸透している変更管理や構成
管理に
管理については、そのまま使えるように
ては、そまま使えるように
2
2.
要件管理ツールの導入には、既存資産を活用でき
要件管理ツ
ルの導入には既存資産を活用でき
るように
3.
WEB上のツールチェーンだけではグローバルサプ
ライチェーン構築は困難なので、トレーサビリティを
構築
ビ
HUB、オープンインターフェースをスポークとした
アキテクチ
アーキテクチャ
10
Copyright © 2011 一般社団法人TERAS All Rights
Reserved.
TERASと機能安全
11
Copyright © 2011 一般社団法人TERAS All Rights
Reserved.
Global Supply Chain of Huge and Complex Software
Software Configuration
Type A Type BType B+
V.1
ReqBv1.doc
PreB+.ppt
R01.doc
Feb-12-91
Apr-05-92
RBpV11.tex
R71_r.docx
Requirement
V.3.0
C-dsgn.doc
Dsgn_B.ppt
Apr-15-88
Aug-09-98
R93b.doc
R55.docx
Nov-11-02
ReqBv2.doc
Mar-21-91
D71.ai
Doc_DB.doc
DBpV11.io
Jul-21-99
Oct-12-97
D01.xml
Feb-29-04
Apr-21-02
R89.pptx
R97e1.doc
R01.doc R43.docx
Design Aug-22-88
Requirement
C-mdl.m
MdlB.mdl
Sep-30-98
Nov-29-91
D81_2.txt
Feb-19-96
D03_1e.c
Dec-26-02
g DesBv2.txt
Aug-02-00
Nov-10-03
Nov
10
03Mar
Mar-05-05
05 05
Mar-31-91
MD5_5.stm
Aug-18-99
ZIPC_m.stm
Dec-21-97
D87.eps
Apr-17-04
D02.xml D02_1.xml
D74_1.xml
Jun-15-02
Design
C_0121.c
Code01.c
Code.cppPreB+.ppt
Dec-18-91
Jan-19-03
Sep-02-00
Dec-18-03
Apr-01-96
May-07-05
Source
Code
May-09-92
Feb-02-87
May-09-91
C02.c
Mod_bp1.c
Sep-02-99
Source.fnc
MD05e01.m
MD3e01.stm
M01.mdl MD02_1.vi
Source Code Nov-06-88
Model
PreB+.ppt
T_0121.csv
Test.xlsx
Jan-14-92
Cd0511.c
Oct-11-98
Jan-24-04
Module.jar
Oct-23-00
Jul-08-05
Jul-22-96
Jun-11-92
Jun-01-91
Test_r.hb
T_p151.csv
Tes_DB.csv
Nov-16-99
Jan-13-98
C5221.c
May-02-04
C002.xlsTest02.xls
C005.cpp
Test
Source Code
Man03C pdf
Man_C.pdf
PreB+
J
Jan-24-92
24 92
J
Jan-12-89
12 89
F bppt
Feb-01-03
01
N PreB+.ppt
Nov-05-98
05 98
Nov-13-96
Sep-21-05
Nov-04-01
Jun-15-92
UM_r.docx
Jan-31-00
Test_f.csv
T002.c T009.xlsMan_B.html
Feb-02-92
UM01.pdf
Mar-11-03
Nov-12-05
Dec-02-01
Feb-16-97
Jul-11-04
U01.pdf U02.pdf
ManualMay-06-97Janr-25-02
Test
User’s
Variation
Version
©CATS 2011
12
Function safety needs traceability
y
y
•
•
•
•
•
•
•
•
•
•
Functional Safety (IEC61508)
Automobile (ISO26262)
Automobile (ISO26262)
Robot (ISO10218)
Medical device software (IEC62304)
Railway applications (IEC62278)
Nuclear power plants (IEC61513)
Process industry (IEC61511)
Process industry
Electrical, electronic and programmable electronic control systems (IEC62061)
Adjustable speed electrical power drive systems (IEC61800)
Di i l d
Digital data communications for measurement and control
i i
f
d
l (IEC61784)
QQuality
ISO9000
Safety
IEC61508
Environment
ISO14000
13
© CATS 2012
Annex C
(informative)
Aim of the confirmation measures
C.2.2 Confirmation that the work products referenced in the safety case
‐ are traceable from one to another，
‐ have no contradictions within or between work products
C.2.2 セーフティケースに参照される作業成果物
の確認
‐ 次々と追跡可能であること
‐ 作業成果物間または成果物内で矛盾がないこ
と
8 Functional safety concept
8.4 Requirements and recommendations
For verification, a traceability based argument can be used, i.e. if the item compiles with the functional safety requirements, then the item p
yg
compiles with the safety goals as a result of this requirement.
検証において、トレーサビリティに基づいて議論
ができる。つまり、アイテム†が機能安全性要求
に従うならば、そのアイテムはこの要求の結果
として、セーフティゴールに従う
The traceability between the hardware safety requirements and their implementation shall be maintained down to the lowest level of hardware components.
NOTE: The traceability is not required down to hardware detailed design and no ASILs are assigned to hardware parts.
assigned to hardware parts.
ハードウェアの安全要件とその実装の間のト
レーサビリティは、ハードウェアコンポーネントの
最も低いレベルにまで維持されなければならな
い。
注) トレーサビリティは、ハードウェア詳細設計に
まで要求されず、ASIL‡は、ハードウェア部品に
割り当てられない。
The traceability of safety‐related hardware elements shall be ensured, in accordance with ISO 26262‐7:2011, 5.4.1.2
安全性に関するハードウェア要素のトレーサビ
リティは、ISO 26262‐7:2011の5.4.1.2条への合致
を以って、保証されなければならない。
7 Hardware design
7.4 Requirements and recommendations
7.4.1
7
41
Hardware
architectural design
7.4.5
Production,
operation, service and d
decommissioni
i i i
ng
†アイテム（item）：ISO 26262が適用される車両レベルの機能をインプリメントするシステムあるいはシステム群
© CATS 2012
‡ASIL：Automotive Safety Integrity Level 用語集 ISO 26262‐1:2011, 1.6 より
p9
p
8.4.5
Verification of
Verification of the functional safety concept
p20
‐ 貧弱な安全文化の指標例：
説明責任（アカウンタビリティ）が追跡可能では
ない。
‐ 良好な安全文化の指標例：
機能安全に関わる意思決定の説明責任の追跡
可能を保証するプロセスである。
p
p21
‐ Examples indicative a poor safety culture:
y
Accountability is not traceable
‐ Examples indicative of a good safety culture:
The process assures that accountability for decisions related to functional safety is traceable
p16
Annex B
Examples for evaluating a safety culture
p13
‐5 Product devvelopment at th
he hardwaare level
‐3 Con
ncept phase
‐2 Managem
ment of functional ssafety
ISO 26262 : 2011(E) Functional safety
用語集 ISO 26262‐1:2011, 1.69 より
14
8. Software unit design and implementation
8.4 Requirements
and recommendations
8.4.5 The software unit design and implementation shall be verified in accordance with ISO 26262‐
8:2011 Clause 9, and by applying the verification l
db
l
h
f
methods listed in Table 9, to demonstrate:
b) The fulfillment of the software requirements as allocated to the software units (in accordance with 7.4.9) through traceability;
g
y
8.4.5 ソフトウェアユニットの設計と実装は、
ISO26262‐8:2011‐9条に従い、表9にリストされ
る検証手法を適用
検証されなければ
ている検証手法を適用して検証されなければ
ならない：
b）ソフトウェア要件の履行は、トレーサビリ
ティを介してソフトウェアユニット（7.4.9に準拠）
に割り当てられる。
5 Production
5.4 Requirements and recommendations
5 4 1 Production
5.4.1 Production planning
5.4.1.2 The production plan shall describe the production steps, sequence and methods required to achieve the functional safety of the item, system or element. It shall include:
c) The implementation of the traceability measures
EXAMPLE: Labeling for the element.
5.4.1.2 生産計画はアイテム、システムまたは
要素の機能安全を達成するために必要な、製
造工程、シーケンスおよびメソッドを記述しな
ければならない。それには以下が含まれる。
ビ
C）トレーサビリティ対策の実装
例：要素のラベル
6 Operation, service (maintenance and repair) and
repair), and decommissioning
6.4 Requirements and recommendations
6.4.1 Production,
operation, service (maintenance and repair),and decommissioning
6.4.1.3 The maintenance plan and repair
instructions shall describe the following:
d) The relevant item, systems or elements Th
l
t it
t
l
t
configurations, including traceability measures;
NOTE: This includes maintenance tool feature used to ensure that the correct version of software is loaded into the vehicle, if such an operation is performed during maintenance.
EXAMPLE: Labeling for the element is way of ensuring traceability.
© CATS 2012
6.4.1.3 メンテナンスプランと修理の手順は、
次のことを記述しなければならない。
d）トレーサビリティ対策も含めた関連するア
トレサビリテ対策も含めた関連するア
イテム、システムまたは要素の構成;
注) これは車両にソフトウェアの正しいバー
ジョンがロードされることを確認するために使
用するメンテナンスツール機能が含まれる。
（このような操作がメンテナンス中に実行され
る場合）
例：要素へのラベルは、トレーサビリティを確
保するための方法である。
p10
7.4.2 ソフトウェアアーキテクチャ設計の開発
期間中に以下の点を考慮しなければならない
期間中に以下の点を考慮しなければならない。
ソフトウェアアーキテクチャ設計の検証可能
性;
注) これは、ソフトウェアアーキテクチャ設計と
ソフトウェア安全性要件との間の双方向のト
レーサビリティを意味する。
p
p18
7.4.2 During the development of the software architectural design the following shall be hit t l d i th f ll i
h ll b
considered:
a) The verifiability of the software architecture design;
NOTE: This implies bi‐directional traceability
between the software architectural design and the software safety requirements.
p4
7. Software architectural
architectural design
7.4 Requirements
and recommendations
15
p8
‐
‐7 Production and operation
n
‐6 Product devvelopment at tthe software leevel
ISO 26262 : 2011(E) Functional safety
The management of safety requirements includes managing requirements, obtaining agreement on i
i
t bt i i
t
the requirements, obtaining commitments from those implementing the requirements, and maintaining traceability.
安全要求の管理は、要求を管理し、それら要
求の合意を獲得しそれら要求を実装する
求への合意を獲得し、それら要求を実装する
ものからコミットメントを獲得し、そしてトレーサ
ビリティを維持することを含んでいる。
6 Specification and
6 Specification and management of safety requirements
6.2 General
Figure 3
Figure 3
Specification and management of safety
Specification and management of safety requirements
• Hierarchical structure
• Traceability
• Completeness
• External consistency
l
安全要求の仕様と管理
6 Specification and management of safety requirements
6.4 Requirements and recommendations
6.4.3 Management y
of safety requirements
6.4.3.2 Safety requirements shall be traceable with a reference being made to:
a) each source of a safety requirement at the upper hierarchical level
upper hierarchical level,
b) each derived safety requirement at a lower hierarchical level, or to its realization in the design, and
c) the specification of verification in accordance with 9.4.2.
NOTE Additionally, traceability supports:
‐ an impact analysis if changes are made to particular safety requirements, and
e u ct o a sa ety assess e t
‐ tthe functional safety assessment.
© CATS 2012
• 階層構造
•トレーサビリティ
• 完全性
• 外部整合性
p9
9
p8
6 Specification and management of
management of safety requirements
6.2 General
6.4.3.2 安全要求は、次で形成される参照を
以って、追跡可能でなければならない：
a) 上位階層レベルにある安全要求の各々
のソス
のソース
b) 下位階層レベルにある各々の派生安全
要求、またはそれの設計上でのリアライゼー
ション
c) 9.4.2条に従う検証の仕様
注) 加えて、トレーサビリティは次をサポートす
る：
‐ 特性の安全要求に変更がなされた場合の
インパクト分析
イン
クト分析
‐ 機能安全のアセスメント
p11
1
‐8 Su
upporting processes
ISO 26262 : 2011(E) Functional safety
16
8 Change management
8.4 Requirements and
and recommendations
8.4.1 Planning and initiating change management
8.4 .1.1 The change management process shall be planned and initiated, before changes are made to
work products.
NOTE Configuration management and change f
d h
management are initiated at the same time. Interfaces between the two processes are defined and maintained to enable the traceability of changes.
g
8.4 .1.1 変更管理プロセスは、作業成果物に
変更が施されるよりも前に、計画され、そして
開始されなければならない。
注)構成管理と変更管理は同時に開始される
注)構成管理と変更管理は同時に開始される。
２つのプロセス間のインターフェースは、
変更のトレーサビリティを可能にするべく、定
義され、維持される。
14 Proven in use argument
14.4 Requirements and recommendations
14.4.3 Minimum information on candidate
14.4.3.1 A description of the candidate and its previous use shall be available, that includes:
a) the identification and traceability of the candidate with a catalogue of internal elements or components if any,
14.4.3.1 対象とその以前の使用に関する記
述は利用可能でなければならない:それは
a)内部エレメントまたはコンポーネント（もし
あれば）の一覧を伴った対象の同定およびト
レーサビリティを含んでいる。※
Annex A
(informative)
Overview on and document flow of supporting processes
7 Configuration management
The second objective is to ensure that the relations and differences between earlier and current versions can be traced.
7 構成管理
第二の目的は、以前と現在のバージョン間の
関係性や差分を追跡できることを保証するこ
とである。
p12
2
第一の目的は、作業成果物およびそれらの
作成のための原理および般的な条件が
作成のための原理および一般的な条件が、
一意的に確認され、制御された手段でいつで
も再生産され得ることを保証することである。
第二の目的は、以前と現在のバージョン間の
関係性や差分を追跡できることを保証するこ
とである。
p14
p
The first objective is to ensure that the work products, and the principles and general conditions d t
d th
i i l
d
l
diti
of their creation, can be uniquely identified and reproduced in a controlled manner at any time.
The second objective is to ensure that the relations and differences between earlier and current versions can be traced.
p37
7 Configuration management
7.1 Objectives
p41
‐8 Supporting processess
ISO 26262 : 2011(E) Functional safety
†対象（candidate）：itemまたはelement 用語集 ISO 26262‐1:2011, 1.12 より
© CATS 2012
※使用実績による安全証明（proven‐in‐use)に関する記述
17
Annex C
(informative)
Aim of the confirmation measures
C.2.2 Confirmation that the work products y
referenced in the safety case
‐ are traceable from one to another，
‐ have no contradictions within or between work products
C.2.2 セーフティケースに参照される作業成果物
の確認
確認
‐ 次々と追跡可能であること
‐ 作業成果物間または成果物内で矛盾がないこ
と
p21
‐2 Manageement
of functio
onal safetyy
ISO 26262 : 2011(E) Functional safety
Safety case
Goal:G_1
Response delay failure are supportable
are supportable
応答遅延障害に対応できる
Context:C_1
Limit of response speed is less than 3 seconds
応答速度の許容範囲は3秒以
応答速度の許容範囲は
秒以
下である
Strategy:S_1
Case analysis in y
the monitoring and recovery
モニタリングと復
旧で場合分け
Goal:G_2
Response speed can be monitored
Goal:G_3
Response delay failure can be recovered
応答速度をモニタリングで
きる
応答遅延障害から復旧でき
る
Monitor:M_1
Log
Evidence:E_1
Test result
Test result
ログ
テスト結果
© CATS 2012
Context:C_2
D‐Script
18
http://www.crest‐os.jst.go.jp/topics/file/et2011‐kouen04.pdf
8 Functional safety concept
8.4 Requirements and recommendations
8.4.5
Verification of the functional safety concept
For verification, a traceability based argument can be used,, i.e. if the item compiles with the p
functional safety requirements, then the item
compiles with the safety goals as a result of this requirement.
検証において、トレーサビリティに基づいて議論
ができる。つまり、アイテム†が機能安全性要求
きる。まり、アイテ
機能安性要求
に従うならば、そのアイテムはこの要求の結果
として、セーフティゴールに従う
p16
‐3 Concept p
phase
ISO 26262 : 2011(E) Functional safety
© CATS 2012
19
7. Software architectural design
7.4 Requirements
and recommendat
ions
7.4.2 During the development of the software g
g
architectural design the following shall be considered:
a) The verifiability of the software architecture design;
NOTE: This implies bi‐directional traceability
between the software architectural design and
between the software architectural design and the software safety requirements.
© CATS 2012
7.4.2 ソフトウェアアーキテクチャ設計の開発
期間中以下点を考慮なけれならな。
期間中に以下の点を考慮しなければならない。
ソフトウェアアーキテクチャ設計の検証可能
性;
注) これは、ソフトウェアアーキテクチャ設計と
ソフトウェア安全性要件との間の双方向のト
レーサビリティを意味する
レーサビリティを意味する。
p10
‐6 Product deevelopment at the software level
ISO 26262 : 2011(E) Functional safety
20
8. Software
unit design and implementatio
n
8.4 Requirements
and recommendati
ons
8.4.5 The software unit design and implementation shall be verified in accordance with ISO 26262‐
8:2011 Clause 9, and by applying the verification methods listed in Table 9, to demonstrate:
b) The fulfillment of the software requirements as allocated to the software units (in accordance with 7 4 9) through traceability;
7.4.9) through traceability;
8.4.5 ソフトウェアユニットの設計と実装は、
条従、表リ
され
ISO26262‐8:2011‐9条に従い、表9にリストされ
ている検証手法を適用して検証されなければ
ならない：
b）ソフトウェア要件の履行は、トレーサビリ
ティを介してソフトウェアユニット（7.4.9に準拠）
に割り当てられる
に割り当てられる。
© CATS 2012
TERASとアーキテクチャ
22
Copyright © 2011 一般社団法人TERAS All Rights
Reserved.
p18
‐6 Pro
oduct development at tthe software leevel
ISO 26262 : 2011(E) Functional safety
21
Traceability Management Architecture
Traceability Management Architecture
1. Supply chain architecture
l h
h
– How to change the documents; Office(Word, Excel, PPT), A b t PDF R
Acrobat PDF, Requirement tools(Doors, PTC, Reqtify, …),…
i
t t l (D
PTC R tif
)
– How to get Universally Unique ID
2 Traceability architecture
2.
T
bili
hi
– REST / OSLC
– Non Web Base or Mixed
3. Repository architecture
– Scale Out
– Scale Up
© CATS 2012
23
Traceability Management Architecture
Traceability Management Architecture
1. Supply chain architecture
l h
h
– How to change the documents; Office(Word, Excel, PPT), A b t PDF R
Acrobat PDF, Requirement tools(Doors, PTC, Reqtify, …),…
i
t t l (D
PTC R tif
)
– How to get Universally Unique ID
2 Traceability architecture
2.
T
bili
hi
– REST / OSLC
– Non Web Base or Mixed
3. Repository architecture
– Scale Out
– Scale Up
© CATS 2012
24
Interchange Requirement
Word
Doors
PTC
Integrity
interchange
Excel
© CATS 2012
25
Supply Chain OEM
Supplier_2
A
A
…
Supplier_n
Requirement
q
a
A
b
D
c
B
d
C
B́
B
B
C´
Ć
e
1. Based on various Knowledge（
Work produ
ucts
Needs, Know
wledge
Supplier_1
E
）,
OEM defines Requirements（
）．
At this time, the relations between Knowledge and Requirements are also recorded.
）.
2. OEM give these Requirements to Suppliers （
´
Supplier_1, Supplier_2, …and so on. In that case, confidential or unnecessary information is excepted from the information passed. ,
y
p
p
3. Suppliers perform analysis and design based on requirements. Some Suppliers may add new Requirements（
4. Again, the relations between Work products（（
）,
some may modify Requirements（
）
and Requirements are also recorded.
© CATS 2012
）.
26
ReqIF
OEM
Requirement
q
A
A
…
Supplier_n
matched
A
b
Supplier_2
conflict
D
c
B
d
C
B́
Work prod
ducts
Needs, Know
wledge
a
Supplier_1
B
C´
modified
difi d
e
E
appended
5. Suppliers returns Requirements including modified or additional part to OEM （
）.
In that case, confidential or unnecessary information is excepted from the information passed. 6. OEM merge additional or modified Requirements received from Suppliers into OEM original Requirements.
In that merger, some problems may occur.
(conflict
or modified, appended Requirements)
© CATS 2012
27
Traceability Management Architecture
Traceability Management Architecture
1. Supply chain architecture
l h
h
– How to change the documents; Office(Word, Excel, PPT), A b t PDF R
Acrobat PDF, Requirement tools(Doors, PTC, Reqtify, …),…
i
t t l (D
PTC R tif
)
– How to get Universally Unique ID
2 Traceability architecture
2.
T
bili
hi
– REST / OSLC
– Non Web Base or Mixed
3. Repository architecture
– Scale Out
– Scale Up
© CATS 2012
28
“Hub and spoke” architecture
TERAS is a kind of EAI in software process.
Architecture of TERAS is “Hub and spoke”.
When the applications can be attached into the tip of spokes called “adaptor” or “connector they can
When the applications can be attached into the tip of spokes called “adaptor” or “connector, they can communicate with other applications connected to the hub.
p
g
Therefore, when compared with the integration in which the individuals will be connected to a mesh between applications, it can significantly reduce the effort required to integrate applications.
http://www.keyman.or.jp/at/coresys/eai/30000604/
No integration
Requirem
ents
Model
High cost integration
Configurat
ion
Requirem
ents
Model
Configurat
ion
Low cost integration
Requirem
ents
Model
Configurat
ion
HUB
Version
Bug tracking
Bug tracking
Version
Version
© CATS 2012
Bug tracking
29
Linked Data
Linked Data is about using the Web to connect related data that wasn't previously linked, or using the Web to lower the barriers to linking data currently linked using other methods. More specifically, Wikipedia defines Linked Data as "aa term used to other methods. More specifically, Wikipedia defines Linked Data as term used to
describe a recommended best practice for exposing, sharing, and connecting pieces of data, information, and knowledge on the Semantic Web using URIs and RDF."
http://linkeddata.org/
http://s‐web.sfc.keio.ac.jp/Lod/Talks/20100408‐semweb‐kennyluck/
© CATS 2012
30
Web base architecture
Adaptor(means Spoke) is compliant with OSLC(include REST).
Requirem
ents
Model
Adapt
or
Adaptt
Ad
or
Adapt
or
Version
Adaptt
Ad
or
Adapt
or
WEB
(OSLC/REST)
Adapt
or
Adapt
or
Bug tracking
Configura
tion
Net Business Integrator
ALM
Adapt
or
PLM
© CATS 2012
31
OSLC
OSLC
REST
RDF
Linked Data
XMI
HTTP(XML)
Open Services for Lifecycle Collaboration (OSLC) is an open community creating specifications for integrating tools. These specifications allow conforming independent software and product lifecycle tools integrating tools. These specifications allow conforming independent software and product lifecycle tools
to integrate their data and workflows in support of end‐to‐end lifecycle processes. Examples of lifecycle tools in software development include defect tracking tools, requirements management tools and test management tools. There are many more examples in software and product development and more still in “IT
in IT operations
operations” (sometimes called service management) where deployed applications are managed.
(sometimes called service management) where deployed applications are managed.
The OSLC specifications build on the W3C Resource Description Framework (RDF), Linked Data and REST, enabling integration at data level via links between related resources. OSLC resources are defined in terms of RDF properties. Operations on resources are performed using HTTP. OSLC also specifies user
terms of RDF properties. Operations on resources are performed using HTTP. OSLC also specifies user interface techniques to enable preview, creation and selection of links.
http://open‐services.net/primer/#primer_main
http://en.wikipedia.org/wiki/Open_Services_for_Lifecycle_Collaboration
32
© CATS 2012
External
OEM or
Supplier
REST (Representational State Transfer)
URI(Uniform Resource Identifier)
Meaning of the resource is invariant.
Weather is weather.
State of the resource is variant.
GET,POST,PUT,DELETE GET
POST PUT DELETE
(Verb)
URI(Noun) linked
Representational Stat and
Representational Stat and Transfer
Yesterday was cloudy, today is sunny .
Notation of the resource
the resource has many format. HTML, XML, HTML
XML
PDF・・・
http://yohei‐y.blogspot.com/2005/04/rest‐3.html参考
33
©CATS 2011
RDF
The Resource Description Framework (RDF) is an infrastructure that enables the encoding, exchange and reuse of structured metadata. RDF is an application of XML that imposes needed structural constraints to provide unambiguous methods of expressing semantics. RDF additionally provides a means for publishing both human‐
readable and machine‐processable vocabularies designed to encourage the reuse and extension of metadata semantics among disparate information communities. The structural constraints RDF imposes to support the consistent encoding and exchange of standardized metadata provides for the interchangeability of separate packages of metadata defined by different resource description communities.
http://www.dlib.org/dlib/may98/miller/05miller.html
subject
http://zipc.co
m/documet1
predicate
object
tested‐by
“test‐case1”
subject
http://zipc.co
m/documet1
predicate
tested‐by
unit test
“test‐case U1”
© CATS 2012
object
http://zipc.
com/test
system test
“test‐case S1”
34
Non Web Base or Mixed
subject
predicate
object
subject
tested‐by
documet1
http://zipc.co
m/documet1
“test‐case1”
predicate
object
tested‐by
test
unit test
unit test
system test
system test
“test‐case U1”
“test‐case S1”
Stand alone
MBD, MDD or other Test tool are not Web application.
Web base
Network
No access
By WEB
© CATS 2012
35
Open architecture
Adaptor(means Spoke) is compliant with OSLC(include REST).
Traceability Manager has three
HUB is traceability manager.
Require
features
Model
OSLC
REST
Adap
tor
Adap
tor
Version
Adap
tor
Bug
tracking
36
ments
Adap
tor
(1) UI (as a browser) and CRUD*
operation
(2) Search engine (like a Google)
(3) Repository (big data)
*Create, Read, Update, Delete
Adap
tor
Traceability
Management
Adap
tor
Configu
ration
© CATS 2012
N t
Net
Business
Integrator
Adap
tor
Adap
tor
PLM
ALM
External
E
t
l
OEM or
Supplier
Non Web Base or Mixed
subject
predicate
object
tested‐by
documet1
“test‐case1”
subject
http://zipc.co
m/documet1
predicate
tested‐by
test
unit test
unit test
“test‐case U1”
Adaptor
p
object
system test
system test
“test‐case S1”
Adaptor
p
Traceability
Repository
Adaptor
Adaptor
Traceability
Repository
i
Traceability
Repository
© CATS 2012
37
TERAS
 Tool
Environment for Reliable
and Accountable Software
 Open
Traceability Tool Platform
It was established in April 2011
http://www.teras.or.jp/
38
© CATS 2012
TERAS Scope

The focus of the proposed TERAS project is to
provide;


traceability platform
OSLC compliant adaptor which run under the
WEB , no WEB, and mixed environment
39
© CATS 2012
SCM – CM Traceability
第一の目的は、作業成果物およびそれらの
作成のための原理および般的な条件が
作成のための原理および一般的な条件が、
一意的に確認され、制御された手段でいつで
も再生産され得ることを保証することである。
第二の目的は、以前と現在のバージョン間の
関係性や差分を追跡できることを保証するこ
とある
とである。
8 Change management
8.4 Requirements and
and recommendations
8.4.1 Planning and initiating change management
8.4 .1.1 The change management process shall be planned and initiated, before changes are made to
work products.
NOTE C fi
NOTE Configuration management and change ti
t d h
management are initiated at the same time. Interfaces between the two processes are defined and maintained to enable the traceability of changes.
8.4 .1.1 変更管理プロセスは、作業成果物に
変更が施されるよりも前に、計画され、そして
開始されなければならない。
注)構成管理と変更管理は同時に開始される
注)構成管理と変更管理は同時に開始される。
２つのプロセス間のインターフェースは、
変更のトレーサビリティを可能にするべく、定
義され、維持される。
Annex A
(informative)
Overview on and document flow of supporting
supporting processes
7 Configuration management
The second objective is to ensure that the relations and differences between earlier and current versions can be traced.
7 構成管理
第二の目的は、以前と現在のバージョン間の
関係性や差分を追跡できることを保証するこ
とである。
p12
The first objective is to ensure that the work products and the principles and general conditions
products, and the principles and general conditions of their creation, can be uniquely identified and reproduced in a controlled manner at any time.
The second objective is to ensure that the relations and differences between earlier and current versions can be traced.
p14
7 Configuration management
7.1 Objectives
p41
‐8 Supportin
ng processes
ISO 26262 : 2011(E) Functional safety
© CATS 2012
40
TERAS
Architecture Management
TERAS AM
State Transition
Model Repository
ZIPC
Change Management
OSLC/SOA
Adaptor
Software Configuration Management
TERAS CM
TERAS SCM
Bug Tracking
Repository Trac
Version Control
Version Control
Repository Subversion
Empirical Project Monitor
TERAS EPM
Traceability Management
TERAS TRA
Empirical Project
Monitor Repository
Traceability
Repository TERAS‐TRA
TERAS TRA
© CATS 2012
41
TERAS – SCM – CM (revision)
Software Configuration f
f
Management
OSLC
TERAS SCM
Version Control
Repository Subversion
V1
Requirement rev1, Requirement
rev1, rev2
Design rev1, rev2, rev3
Code rev1, rev2, rev3, rev4, rev5
Change Management
TERAS CM
O
OSLC
Version / revision change
Bug Tracking
Repository Trac
The reason for change
Type: Type: Reporter:
Type: Reporter:
Summary:
Type: Reporter:
Summary:
Description:
p Type: R Type:
Reporter:
t
Summary:
Description:
Reporter:
Summary:
Description:
Summary:
Description:
Description:
Impact analysis
Revision trace repository
Traceability Management
TERAS TRA
TERAS TRA
Document trace repository
Code
Req
Req
Design
Code
1‐>2
1
2
1‐>2
1
2
ID: R1
ID: R1
ID: D1
ID: D1
ID: C1
ID: C1
Design
ID:R2
ID: D2
ID: C2
ID:D3
ID: C3
2‐>3
Traceability
Repository TERAS‐TRA
V2
3‐>4
4 >5
4‐>5
1‐>2
ID: C4
ID: C4
2 >3
2‐>3
© CATS 2012
42
TERAS – SCM – CM (version) Software Configuration f
f
Management
OSLC
TERAS SCM
Version Control
Repository Subversion
V1
Requirement rev1, rev2
Requirement
rev1, rev2
Design rev1, rev2, rev3
Code rev1, rev2, rev3, rev4, rev5
Change Management
TERAS CM
O
OSLC
Version / revision change
Bug Tracking
Repository Trac
V2
The reason for change
Type: Type: Reporter:
Type: Reporter:
Summary:
Type: Reporter:
Summary:
Description:
p Type: R Type:
Reporter:
t
Summary:
Description:
Reporter:
Summary:
Description:
Summary:
Description:
Description:
Impact analysis
Document trace repository
Traceability Management
TERAS TRA
TERAS TRA
Version
Req
Design
Code
ID: R1
ID: R1
ID: D1
ID: D1
ID: C1
ID: C1
ID:R2
ID: D2
ID: C2
ID:D3
ID: C3
1‐>2
Traceability
Repository TERAS‐TRA
p
y
Baseline trace repository
ID: C4
ID: C4
© CATS 2012
43
Integration PLM and Traceability by OSLC/SOA Adaptor
•
Adaptor which convert data and API and add data operation UI can integrate non‐OSLC product and OSLC product.
Non-OSLC Product
OSLC Product
SOA
OSLC/SOA
Adaptor
OSLC
Siemens Teamcenter
Si
T
t
Product Lifecycle
Management (PLM)
D t
Data conversion
i
API conversion
TERAS
Software Traceability
D t
Data selection UI
l ti UI
D t
Data preview UI
i UI
© CATS 2012
44
DOORS‐Teamcenter‐Integrity(OSLC‐RM)
Teamcenter
Adaptor
OSLC
Client
OSLC Server(RM)
Adapter
Adapter Framework
Adaptor
REST I/F
OSLC
Client
(RM)
OSLC Server(RM)
OSLC Server(RM)
(GET, PUT, POST, DELETE)
Adapter
OSLC
Client
(RM)
Adapter Framework
OSLC
Server(RM)
DOORS
(OSLC)
MKS Integrity
© CATS 2012
45
DOORS‐Teamcenter‐Integrity‐TERAS
Teamcenter
Adaptor
Set data in TERAS TRA(repository)
OSLC
Client
OSLC Server(RM)
Adapter
Adapter Framework
REST I/F OSLC
TERAS TRA
Adaptor
OSLC
Client
(RM)
OSLC Server(RM)
OSLC Server(RM)
OSLC
Client
(RM)
Adapter
Adapter Framework
OSLC
Server(RM)
DOORS
(OSLC)
MKS Integrity
© CATS 2012
46
TERAS‐PLM
Architecture Management
Siemens Teamcenter
PLM
TERAS AM
State Transition
Model Repository
ZIPC
OSLC/SOA
Adaptor
Change Management
Software Configuration Management
TERAS CM
TERAS SCM
Bug Tracking
Repository Trac
Version Control
Version Control
Repository Subversion
Empirical Project Monitor
Traceability Management
TERAS EPM
TERAS TRA
Siemens NX
CAD
Traceability
Repository TERAS‐TRA
TERAS TRA
Empirical Project
Monitor Repository
© CATS 2012
47
Traceability Management Architecture
Traceability Management Architecture
1. Supply chain architecture
l h
h
– How to change the documents; Office(Word, Excel, PPT), A b t PDF R
Acrobat PDF, Requirement tools(Doors, PTC, Reqtify, …),…
i
t t l (D
PTC R tif
)
– How to get Universally Unique ID
2 Traceability architecture
2.
T
bili
hi
– REST / OSLC
– Non Web Base or Mixed
3. Repository architecture
– Scale Out
– Scale Up
© CATS 2012
48
Copy & Paste
OEM
Requirement
Supplier
ReqIF
Design
Code
Test
Requirement
Design
Copy
&
Paste
Code
Test
Scale Up : Clock up
© CATS 2012
49
Web Base
OEM
Requirement
Supplier
ReqIF
Design
Code
Test
Requirement
Design
REST
GET
Code
Test
Scale Out : multi core, many core
© CATS 2012
50
NoSQL
Non SQL
Non RDB
Schema less
Key‐Value Store
Column‐Oriented
Document‐Oriented
‐ CouchDB
‐ MongoDB
‐ Riak
‐ Terrastore
T
Scale Out : multi core, many core
Scale Up : Clock up
SQL
RDB
schema
http://www.atmarkit.co.jp/flinux/rensai/noSQL/noSQL_01/01_1.html
© CATS 2012
51
Document Oriented Database
Car catalog
Name: 911
Engine Position : Rear
While Drive : Rear
Nickname : Frog
Anxiety : Traffic jam in summer, Cat on the roof
Name: Jeep
Engine Position : Front
i
ii
While Drive : Four
Color : Navy Blue
U
Usage : Surfing, Ski
S fi Ski
http://www.atmarkit.co.jp/fdb/rensai/09_couchdb/01/couchdb01.html
RDB
Car
Car ID
Name
Position
Drive
Nickname
001
911
Rear
Rear
Frog
002
Jeep
Front
Four
Car_Anxiety
Color
Navy Blue
Car_Usage
Car ID
Anxiety[0]
Anxiety[1]
001
Traffic jam in
Traffic jam in summer
Cat on the roof
Cat on the roof
Car ID
Usag
e[0]
Usag
e[1]
002
Surfin
g
Ski
DODB
ID:001
Name: 911
Engine Position : Rear
While Drive : Rear
While Drive : Rear
Nickname : Frog
Anxiety : Traffic jam in summer, Cat on the roof
© CATS 2012
ID:002
Name: Jeep
Engine Position : Front
While Drive : Four
While Drive : Four
Color : Navy Blue
Usage : Surfing, Ski
52
DODB/REST/JSON
http://server_name/DB_name/documento_name
http://catalog.example.net/catalog_1/911
REST
GET,DEKETE
,POST,PUT
Program
Client
Select document by REST
RESTでドキュメントを指定
JSON
(JavaScript Object Notation)
format data
書式を介してデタの
書式を介してデータの
入出力を行う
DODB will be asked to create applications to user of the document .
In traditional RDB, which provided an application is to provider of the document.
However in the management of documents
However, in the management of documents between OEM and Supplier,
DODB is useful to get a functional safety certification
functional safety certification
Mapping document by URI
URIでドキュメントを
マッピング
DODB Server:”catalog.example.net”
DB:”catalog_1”
“911”
“Jeep”
DB:”catalog
DB:
catalog_2
2”
“CELICA”
“TERRANO”
“S800”
“Savanna”
DODBは、ドキュメントを利用する側に
アプリケーション作成を依頼する。
従来のRDBでは、ドキュメントを提供する側が
アプリケーションを提供していた。
しかし
しかし、OEM‐Supplier間でのドキュメント管理では、
l 間でのドキメント管理では
利用する側に委ねたほうが26262認証では便利である。
© CATS 2012
53
Access Control
Car catalog
Car catalog
Name: 911
Engine Position : Rear
Whil D i
While Drive : Rear
R
Nickname : Frog
Anxiety : Traffic jam in summer, Cat on the roof
Cat on the roof
Permission: cat lover
© CATS 2012
Name: Jeep
Engine Position : Front
While Drive : Four
While Drive : Four
Color : Navy Blue
Usage : Surfing, Ski
Permission: Surfer Skier
Permission: Surfer, Skier 54
まとめ
Process
・MBD
・MDD
・SA/SD
・OOA/D
/
・Code oriented development
・MATLAB/simulink
MATLAB/ i li k
・ZIPC
・SCM
・CM
・Issue Tracking Management
・In‐house tools
Method
・ISO26262
・CMMI
CMMI
・AUTOMOTIVE‐SPICE
・Modular
g
・Integral
・Waterfall (V‐model)
・agile
・Supply chain
Architecture
© CATS 2012
・ I/F
‐REST
‐OSLC
‐ReqIF
・DB
‐RDB
‐DODB
・Scale
‐out
‐up
55

Download Report