introduction to pl右上4つがpleとみなされる。platform は...

© pure-systems GmbH

プロダクトライン開発

持続的な進化と保守を支援するバリアント管理

欧州車載機器メーカなど産業界の実践事例

富士設備工業（株）電子機器事業部浅野義雄

Embedded Technology 2016 設計・検証ツールトラック

11/16（水）15:00〜15:45 アネックスホール2階


プロダクトライン開発にバリアント管理ツール pure::variants を活用

Product Line Engineering (PLE) は、再利用資産を運用する技術的な取り組みであり、継続的に変化する市場要求や技術革新に伴う製品（バリアント）の進化に柔軟に応じることのできる、開発プロセスや手法を伴う全体的なアプローチが求められます


プロダクトラインの例：シンプルで、見た目は右ハンドル車の違いくらいだが中身の違いや、その詳細は簡単にはわからない


プロダクトライン開発の課題として同時に対応すべき２つのバリエーション（変化）があるこの例では、一番上のみ右ハンドルで、下の３つは同様に見えるが違いもあるここでは製品間の違いのみ

Product Line Engineering Variation Dimensions

製品間の違い Technical Dimension


Product Line Engineering Variation Dimensions

製品間の違い Technical Dimension

バージョン Time Dimension

これら製品（バリアント）は、継続的に変化する市場要求や技術革新を受けて進化する

備えはいるが、どうなるか予測はできない

同時進行で発生するバリエーション（製品間の違い）とバージョンの両方の管理が必要


バリアント管理の様々なアプローチ

S

Configurable Product (150%)

Stra

tegi

c A

d-h

oc

S

Platform-based Independent

S

Product Line (90%)

Platform (50%)

Production Line (150%)

S

Clone&Own

Managed Cloning

Reuse Repository


R

R

R R

R

R

P2

P3

P6

P4

P7

P5

Branch Merge ReleaseR Development MaintenancePx Product Integration

RR RP1


バージョン管理とバリエーション管理を混同すると、、

http://www.fuji-setsu.co.jp/files/purevariants.pdf

http://www.fuji-setsu.co.jp/files/purevariants.pdf


課題: 全ての資産にバリアビリティが存在する

ある自動車メーカの事例だが、一般によくある単純な再利用。各成果物で個別にコピペが繰り返され、体系的な再利用には程遠い。こうなると複数バリアント間で同一の問題の修正は困難。またテストは特定の熟練者の経験に頼ることになる



S


Stra

tegi

c A

d-h

oc

S


S

Product Line (90%)

Platform (50%)


S

Clone&Own

Managed Cloning

Reuse Repository


Building From Standard Assets (Building Blocks)

ある目的を持ったブロックをベースに

派生する製品固有の機能を開発する場合


結果、標準化された資産が増えすぎて、こうなると探すのも大変で、無駄も多くあるはずで、拡張性もない。こうならないように、考え方を変える必要がある



S


Stra

tegi

c A

d-h

oc

S


S

Product Line (90%)

Platform (50%)


S

Clone&Own

Managed Cloning

Reuse Repository

右上４つがPLEとみなされる。Platform は共通部分のみ再利用。Product Line は製品ごとで固有の資産がある。Production Line はプロダクトラインの資産から全ての製品が生成される。Configurable Product は単一製品から使用時等の構成によってバリアントが決定される。これらの取組みはpure::variants のバリアント管理ツールによって支援される


R R R R R R R

V1

V2

V1

V3

V2

V3

V1

V4

V2

V3

V1

Branch Merge Release R Development Maintenance Vx Variant Integration

バージョン管理に適正なバリアント管理ツールを統合することで

プロダクトラインの持続的な進化と保守を支援して体系的な再利用を実現できる

© pure-systems GmbH バリアントごとの製品数

バリアントの数

適正な取り組みを選択するときに、考えるべき側面のひとつはバリアント数対バリアントごとの製品数。自動車なら顧客要求を満たすために多くのバリアントが必要で、その分製品数は多くない。電動ドリルの場合は、バリアント数は少ないが沢山出荷される。このようにプロダクトラインに違いがあるので、PLEの取組みも様々

© Danilo Beuche, pure-systems GmbH

解決空間問題空間

バリエーションポイント

問題空間上のバリエーションポイントは、解決空間上のテクニカルなそれと結びつき、バリエーションの複雑さを軽減してバリアントの決定項目を削減できる


Variant Management Solution for

Systems & Software Engineering


アプリケーションエンジニアリング

ドメインエンジニアリング

解決空間問題空間

Feature Models Family Models

Variant Models Variant Assets

フィーチャーとリレーションの集合コード資産など製品ファミリーの部品集合

フィーチャーを選択してバリアントを定義バリアントを自動生成

PLEの戦略＝関心事の分離


問題空間上の各フィーチャに解決空間内のバリエーションポイントを紐付ける


System Requirements

System Design

HW/SW Requirements

HW/SW Design

Implementation Unit Test

System Validation

System Test

HW/SW Test

HW/SW Integration

Test

Feature Model

フィーチャモデルにプロダクトラインの問題空間のバリエーションを表現して、解決空間上のあらゆる資産と紐付けられる


Integrate engineering tools and management systems throughout lifecycle of product line

AUTOSAR

DOORS Next

RTC

Rhapsody Design Manager

C/C++/Java Rational Quality Manager

DOORS 9

Rhapsody

MS Word,Excel EMF

… Reporting Simulink

Enterprise Architect

pure::variants プロダクトラインライフサイクルをサポート

IBM Jazz Global Configurations,

Streams, Change Sets

顧客・市場

からの要求要求仕様書

モデリング・

シミュレーション開発・実装テスト出荷

顧客・市場

からの要求要求仕様書

モデリング・

シミュレーション開発・実装テスト出荷


Feature Model

Legend: = Mandatory （必須） = Optional（選択自由） = Alternative （どれか一つ） = Or（少なくとも一つ）


バリアントごとで搭載する機能を比較

フィルターやソートでバリアント間の違いや同一性を分析できる


Variant Management 事例


When 150% Is Too Much: Supporting Product Centric

Viewpoints In An Industrial Product Line

Authors: Michael Schulze, Maurice Duvigneau, Danilo Beuche

Presenter: Danilo Beuche [email protected]


Some Facts

Embedded Product Line

100+ Developers

10+ Products

C, Java, 2x Assembly Languages

2 Hardware Platforms

3000+ Files 1.25+ Mio Lines of Code

Variant Management by pure::variants

Standard Compliance Certification

Frequent Code Audits by Customer


The Challenge


The 150% Approach

150% Source Code

#ifdef UNITS_METRIC

#else

#endif

Variant A: 100% Binary

Variant B: 100% Binary

Compile #define UNIT_METRICS

Compile #undefine UNIT_METRICS


Use

Au

dit/C

ertificaton

The Required Variant Assets

Variant A: Binary

Variant A: API Docs

Variant A: Source

150% Source Code

#ifdef UNITS_METRIC

#else

#endif

#define UNIT_METRICS


Use

Au

dit/C

ertificaton

Variant Assets: How They Haven Been Made

Variant A: Binary

Variant A: API Docs

Variant A: Source

150% Source Code

#ifdef UNITS_METRIC

#else

#endif

COMPILER

DOXYGEN

150% COPY (OR HUMAN)


Use

Au

dit/C

ertificaton

Variant Assets: Change Impact

Variant A: Binary

Variant A: API Docs

Variant A: Source

150% Source Code

#ifdef UNITS_METRIC

#else

#endif

COMPILER

DOXYGEN

150% COPY (OR HUMAN)


Business Challenges

Change Impact: More Cost

More Assets: More Cost

Complex Assets: More Cost

API != Docs: More Cost


The Solution


Use

Au

dit/C

ertificaton

Basic Idea

Variant A: Binary

Variant A: API Docs

Variant A: Source

150% Source Code

#ifdef UNITS_METRIC

#else

#endif

COMPILER

150% -> 100%

DO

XYG

EN


Blanking vs. Deleting

150% Source Code

#ifdef UNITS_METRIC

#else

#endif

Deleting

Variant A: Deleting

Blanking

/****************/

/****************

****************

****************

****************

****************

****************/

Blanking


Variant

Assets

Feature Model

External

Assets

Evaluation

Family Model

Variant Model

Variant

Result Model

Transformation

External

Variation Points

Variant Generation Dataflow with pure::variants


150% Source to 100% Source data

flow in the pure::variants Source Transformation

Copy only

Variant

Result Model

Analyzer Solver Blanker Source File Resulting File File Selector

pure::variants

Transformation

VEL VEL


VEL = Variability Exchange Language

http://www.variability-exchange-language.org/









The Numbers


The Real Numbers


The Results

● ~10k Variation Points per Variant

● Time to decide about variation point in one variant and remove unused part

– by a human: estimated 55h

– by standard PC: <5min

● Reduced Risk of IP / NDA Violations (still Risk > 0!)

● Better Balance between Evolution Benefits and (Re-)Certification Cost


“アダプティブクルーズコントロール” の影響を受ける “自動ハイビーム機能” は、既存

製品をベースに新機能が追加されて、既存機能は変更されるか削除される。そのような進化の挑戦的課題は、一貫したバリアント管理と再利用であり、これは全ての成果物（要求仕様、モデル、コード、テスト、安全性ケース、各種ドキュメントなど）が正しい順序で、正しい手順で扱われることで一貫性が維持される必要がある。この支援に pure::variants、Doors、Matlab/Simulinkを変更管理ツールと連携した

© pure-systems GmbH 相互に連携する２つのシステムの継続的な進化を支援

Source: SPES_XT Software Platform embedded systems http://spes2020.informatik.tu-muenchen.de/spes_xt-home


(Automotive) OEM Variant Management Challenges

● Each Project may have its own way of writing specifications

● プロジェクトごとに独自のやり方で仕様書が記載される

● Similar behavior / UI makes for strong “brand experience”

● ブランドイメージを強固にする類似した振舞いやUI

● Least Possible Amount of variability gives biggest economies of scale

● バリアビリティを最小限にすることによるスケールメリット

● Continuous Innovation and Variation sells

● 継続的な革新とバリエーションがセールスポイント

● Each Project has its own time line

● プロジェクトごとで納期が定まっている

● Often requirements and V&V tests and calibration are main focus areas

● 要求仕様、V&Vテスト、キャリブレーションが主な関心領域


Benefits of Using pure::variants

● Supports full tool chain (Doors, Simulink, Enterprise Architect, standard calibration data formats via extension, custom transformation generates code)

● 全ての開発ツールをサポートできる

● Uniform Variability Concept over all asset types

● 全ての資産に対して共通したバリアビリティのコンセプト

● Uniform approach across different tools

● 異なるツールに対して共通した扱い

● Migration of home-grown approach to COTS tool based approach

● 自社製の取組みから汎用ツールへの移行をサポート

– DOORS Variant Matrix

– Simulink Variability

– Calibration Tool-independent Calibration Data Reuse controlled via pure::variants Extension


(Automotive) Supplier Variant Management Challenges

● Each Customer in a Customer Project may have its own way of writing specifications

● 顧客のプロジェクトごとに独自のやり方で仕様書が記載される

● Least Possible Amount of variability gives biggest economies of scale

● バリアビリティを最小限にすることによるスケールメリット

● Continuous Innovation and Variation sells

● 継続的な革新とバリエーションがセールスポイント

● Each Customer Project has its own time line

● 顧客のプロジェクトごとで納期が定まっている

● Anything from requirements over code assets to tests and documentation needs to be handled

● 要求仕様からコード、テストやドキュメントなど全てに対処しなければならな

い


Benefits of Using pure::variants

● Supports full tool chain (Doors/Doors NG, Enterprise Architect, Rhapsody, Custom Tools via

API, RQM, RTC, custom transformation generates code)

● 全ての開発ツールをサポートできる

● Uniform Variability Concept over all asset types

● 全ての資産に対して共通したバリアビリティのコンセプト

● Uniform approach across different tools (Easy from Migration from DOORS to DOORS NG)

● 異なるツールに対して共通した扱い（例：DOORS から DOORS NGへの移行も

容易）

● pure::variants Update allows to quickly address project needs

● プロジェクトごとの需要に即座に応じた更新をサポート


動画デモ


動画：Feature Model

http://www.fuji-setsu.co.jp/demo/pvIBM/pv1FeatureModel.wmv


動画：Add Variant‚BaseLight_Sweden‘

http://www.fuji-setsu.co.jp/demo/pvIBM/pv2VariantConfig.wmv


動画：Compare View & Matrix View

http://www.fuji-setsu.co.jp/demo/pvIBM/pv3CompareMatrix.wmv

© pure-systems GmbH http://www.fuji-setsu.co.jp/demo/pvIBM/pv5DNGtransform.wmv

動画：Deriving Variant-Specific Requirements


動画：Restricting UML/SysML Elements

http://www.fuji-setsu.co.jp/demo/pvIBM/pv6RhapsodyRestrict.wmv


動画：Variant Preview

http://www.fuji-setsu.co.jp/demo/pvIBM/pv7RhapsodyPreview.wmv


動画：Stream Transformation

http://www.fuji-setsu.co.jp/demo/pvIBM/pv8RhapsodyTransform.wmv


IBM DOORS NG Jazz と pure::variants連携例

Coevolution of Product Line and Variants

Requirements

Stream (150%)

Requirements

Stream (100%)

Time

Requirements

Stream (100%)

change

Requirements

Stream (150%)

change

Requirements

Stream (100%)

merge

① プロダクトライン全体の資産（150％）から、バリアント固有の要求仕様を生成したものがある ② もしバリアントへの固有の変更と同じタイミングで、 ③ プロダクトライン全体への変更が発生した場合でも、 ④ 双方の変更を3ウェイマージして、処理の自動化を促進できる

① ②

③

④

© pure-systems GmbH http://www.fuji-setsu.co.jp/demo/pvIBM/pv9GC_Coevolution.mp4

動画：Coevolution of Product Line and Variants


Getting Started


Starting and Running Success Product Lines – Real World Data

業界 /製品プロジェクト内容

始める前の取り組み

PLの第一段階で管理できた資産

完全な適応までの期間

バリアント数 Tools

Industry Automation Frequency Converters

既存製品のコピーを修正(Code)

2 ヶ月でソースコードの60%を再利用資産化

4-5 年 (Req, Code, Parameter Database)

~10-20 at any point in time

ClearCase, ClearQuest, Caliber, BuildForge, Inhouse, C++, pure::variants

Transportation Railway Signaling Systems

Requirements (Catalog Approach)

3-6 ヶ月(Requirements)

18 ヶ月 (Req, Code, Tests, other assets)

初期段階は 2つで、後から追加

Doors, Inhouse, C/C++, pure::variants

Automotive Transmission Systems

部品の選択と #ifdef

3 ヶ月 6 ヶ月 50以上 ClearCase, ClearQuest, make, C, pure::variants

Automotive Airbag Systems

既存製品のコピーを修正(Req), #ifdef (Code)

9 ヶ月（まずReqから）

継続中 100以上 Doors, RTC, Inhouse tools, pure::variants

フィーチャ数は40くらいから数千まで様々な事例がある


S Configurable Product (150%)

Summary Variant Management Approaches

Stra

tegi

c A

d-h

oc

S


S

Product Line (90%)

Platform (50%)


S

Clone&Own

Managed Cloning

Reuse Repository

Evolution of reuse approach

Diversification of reuse approach

Lean & agile reuse approach


pure::variants について： http://www.fuji-setsu.co.jp/products/purevariants/index.html

Dr.Daniloの実践的ソフトウエアプロダクトライン開発 http://www.fuji-setsu.co.jp/products/purevariants/Danilo_Blog.html

富士設備ブースに出展

ET2016：小間番号（B-23)

introduction to pl右上4つがpleとみなされる。platform は...

Documents