HOME | products | MetaEdit+ | ArchitecturalModeling_EAST-ADL

アーキテクチャモデリングで成果を上げる

embedded 掲載記事


Volvo、Fiat、Continental、KTH のシステムモデリング/アーキテクチャモデリング言語

Reaping the benefits of architectural modeling in embedded design

 

Juha-Pekka Tolvanen and Janne Luoma, Metacase and De-Jiu Chen, KTH November 09, 2014
 

 ソフトウエアによって実現される車載システムや組込みシステムの規模と複雑さは増大する一方である。それゆえ全ライフサイクルのコストと工数を効率化するためには、それに見合った開発手法やツールの改善が欠かせない。異なるサブシステムの統合や、様々な側面を持つエンジニアリングの連携といった、著しいボトルネックに対処するためには、従来以上にツールの支援が重要視され始めている。
 
ツール間のハイレベルな開発情報の統合は、システム開発と品質管理をモデルベース開発手法で取組むことによってのみ実現され得る。そして組込みソフトウエアシステムのアーキテクチャには、ソフトウエアの機能性だけでなく、それに関わる要求仕様、リソースの割当て、タイミング、安全性、変動性(プロダクトライン)などもモデル化される。
 
各機能の実装レベルの詳細から、完全なシステム全体のデザインに焦点を上げること。アーキテクチャ上の成果物を形式的に扱うことで、モデルベース手法でシステムの仕様記述が正確で一貫性が取れるようになり、早期段階からシステムの振舞いや特性を予測すること、形式的な設計情報を基にした評価や最適化を実施できるようになる。
 
この資料では、企業がモデルベースのアーキテクチャ設計に移管して成果を上げることが容易であることを、我々の経験から紹介する。ここでは車載システムの電気・電子システムを例にするが、内容の本質とツールの支援機能は、これに制限されるものでは無く、あらゆるドメインに活用できる。
 

Integrating with current processes and implementations

 
既にデザインや実装はあるが、どうやってアーキテクチャを定義するか?相互に補完できる3つの仕掛けで、デザインや実装とアーキテクチャ定義を同調させることができる。
 
最初の仕掛けは既存のデザインや実装を、初期段階のアーキテクチャモデルの生成に利用すること。この資料の例(車載システム)では、Simulinkモデル。
 
アーキテクチャに関連するパーツ(モジュールの階層構造やポートを介した通信)のみを抽出。この処理はMetaEdit+ のジェネレータ機能を用いてSimulinkモデルを構文解析し、当該パーツを抽出し、アーキテクチャモデルを自動生成する。ただこの手のリバースエンジニアリングでは理想的なアーキテクチャデザインには辿り着くことはなく、従来の開発習慣を改革して、労力を軽減する適正なソリューションが必要であることに、多くの組織が直面することになる。
 
2つ目の仕掛けも既存のモデルやレガシーコードを構文解析すること。ただし一貫性のチェックを目的に。アーキテクチャデザインは既存の実装に対して検証され、違いがレポートされる。これによって計画されるアーキテクチャと様々なサプライヤーによって提供される現実的な実装との比較がなされる。ポートやコネクション、インターフェイスなど、個々のモジュールのアーキテクチャレベルのインターフェイスが比較検査される。Figure 1にはアーキテクチャビュー(パワーサプライのファンクショナル・コンポーネントとポートを介した接続)における自動チェッキングの結果が表示されている。
 


Figure 1: Checking the consistency of designs and reporting them with architecture model
 
Figure 1の下段に一致性チェックの結果、Simulinkモデルに存在するポート(PowerConversionCtrl)が、アーキテクチャモデル上には無いと表示されている。 これにより実装側を修正するべきか、アーキテクチャを更新すべきかを考察できるようになる。このチェックはインターフェイス、クライアント/サーバーベースのコネクション、電源接続、I/O接続など、アーキテクチャの他のエレメントもカバーする。
 
そして3つめの仕掛けは、モジュール設計やコードなど、より明確なデザインや実装仕様を、アーキテクチャモデルから直接生成させる。この資料の例(車載システム)では、Simulinkモデルをアーキテクチャモデルから自動生成。これにより異なるサプライヤーに割当てられるモジュールが、全体的なアーキテクチャに準拠できるようになる。
 
ツールレベルの実質的な統合は、インターフェイスと、ツールの統合機能によって行われる。このアーキテクチャモデルの例では、MetaEdit+のジェネレータ機能とAPI、そしてSimulinkのファイル形式を利用。ここでツールの選択要件として、効率的な統合を支援する、オープンなデータ交換のインターフェイスと機能が重要な鍵となる。
 
注意したいのは、ツールは偏見なく評価するべきであること。オープンソースのツールが他のツールとのインターフェイスを提供するとは限らないし、市販ツールが様々なインターフェイス機能や既成の統合環境を用意することも多くなっている。
 
基本的にアーキテクチャモデルは、専用の要件管理ツールで管理される要求仕様や、エクセルやワードなど既存の各種データと統合できる。Figure 2はスプレッドシート上の要求仕様をアーキテクチャデザインにインポートした例。マトリクス内の ‘satisfy’ のリンクにより、インポートされた要件とアーキテクチャ上の個々のパーツとの割当て(Allocation)が、明確なトレーサビリティとして表現されている。
 
更に要件の変更を、アーキテクチャモデリングツール上で自動反映させる機能もある。これにより要件は、アーキテクチャモデルと、専用の要件管理ツールのどちらにおいても、開発プロセス内で柔軟に管理できる。ここではReqIFなど共通の形式を用いて、要件の連携が行われる。
 

Figure 2: Importing requirements and aligning them with architecture designs
 

Architecture models and their use

 
車載ソフトウエアシステムの機能性は一般に、アプリケーションロジックとシステムバウンダリをファンクショナルブロックとコネクタでモデル化する、ファンクショナルビューで仕様化される。Figure1 は、ファンクショナルアーキテクチャモデルの例。このようなモデルは、他のモデル(振舞い、追加の機能、技術上の制約など)と連携して、システムの統合や分析の主要な役割を担う。
 
組込みシステムの、設計上の重要な決定事項は、演算処理と通信のリソースの配置・展開。物理的な部品とそれらの接続を記述する、ハードウエアアーキテクチャモデルが、これを支援する。
 
Figure 3は、ブレーキシステムのハードウエアアーキテクチャ例。センサー、ECUノード、アクチュエータ、各種電子部品、そして部品間の様々なハードウエア接続。
 


Figure 3: Part of a hardware architecture model
 
このモデルはEAST-ADL(車載システムアーキテクチャ向けのドメイン固有言語)のハードウエアアーキテクチャビューを用いて作られた。この言語では、ECU、バス、ワイヤーといった車載システム開発に通じたコンセプトを直接用い、またルールや制約を持たせることで、モデリングや検証作業が効率化され、可読性も向上している。
 
例えばEAST-ADL言語の全てのコンセプトは、個々にプロパティを持つので、開発担当者がエレメントを作る時に、該当するプロパティのみ問われるようになっている。また全エレメントは独自の表記を持つので、グラフ上で他との識別は容易である。またこの言語の機能により、モデルの正しさや完全性がチェックされるので、モデルはフォーマル(形式的)に記述され、解析ツールやジェネレータ(モデル変換)にも活用される。
 

Allocating functions to hardware

 
アーキテクチャデザインは、システムのファンクショナルなビューとハードウエアのビューの合成を支援する。Figure 4のアロケーションのマトリクスは、左列に各ファンクションが、行上部に物理的なハードウエアが表示されている。そしてセル上の ‘FunctionAllocation’ でハードウエアに対するファンクションの割当てが表現されている。
 


Figure 4: Allocating functions to hardware
 
またハードウエアアーキテクチャモデル上に、ファンクションのアロケーションを直接視覚化する機能もある(Figure 5)。各ハードウエアエレメント内に割当てられているファンクションを表示させながら、割当て・解除を試行錯誤することもできる。
 

Figure 5: Hardware architecture visualizing allocations made
 

Targeting software platforms.

 
アーキテクチャデザインは協調して行われ(時には同じダイアグラムを同時に)、モデルは様々な用途に使用される。例えばFigure 4のようなハードと機能の割当てをベースに、アーキテクチャはソフトウエアコンポーネント構造に変換され、ソフトウエアプラットフォームの基になる。また同時に、この割当ては、様々なプラットフォームへの機能のマップにも使用される。例えば、パーツによっては内部フレームワークで実行されるし、AUTOSARにマップされるものもある。
 

Automating safety design flows

 
アーキテクチャモデルは様々な解析にも利用できる。例えば、安全設計フローやISO 26262のような国際規格は、アーキテクチャモデルによってサポートされる。AUTOSAR向けに.arxmlを生成する代わりに、アーキテクチャモデルはデペンダビリティモデルの基や、エラーモデルの生成に活用できる。
 
なぜならアーキテクチャモデリング言語には、正しさや完全性をチェックする機能を有し、フォーマルなモデルをジェネレータ(モデル変換)に提供できるので。Figure 6 はアーキテクチャモデルから自動生成されたエラーモデルの例。これにより、安全設計段階において計画されているアーキテクチャの全てのアスペクト(側面)を考察することが支援される。
 


Figure 6: Initial error model generated from nominal architecture
 
 
このエラーモデルは安全分析の基を形成し、エラーの伝搬を分析している。Figure 6 の右端・上から3つ目のアウトプットポートが、青色テキストで‘error’ とマーキングされている。そして、このアウトプットポートのエラーの原因と想定されるファンクションやインプットは、青色のアウトラインでハイライトされている。
 

Behavior modeling

 
アーキテクチャ設計のフォーカスはシステムのコンフィグレーションではあるものの、有益な副産物として振舞いのプロパティが、要件や、構造化ユニット、その他アーキテクチャの成果物に関連づけられる。
 
例えばEAST-ADL では振舞いのモデルが、テキストレベルの要求仕様を洗練するために使用される。境界条件、変数のインバリアント、状態や状態遷移など、振舞いの関心事をフォーマルに(形式化)することで。そして、これにより振舞いのモデルと要求仕様とがシームレスに統合される。
 
Figure 7に紹介するEAST-ADLの別の例では、Behavior Constraintsと称されている抽象的な振舞いの仕様は、システムブロックに連携されている。そして全ての実体は、当該の制約のタイプに属する。デザインでは、このように制約が注釈されることは、様々な理由で必要となる。合成の評価や、合成のチェック、モデル間の一致性の管理など。
 


Figure 7: Sample of behavior constraint annotations for three architecture block types.
 
実行に関するRun-to-completion セマンティクスとともに、アーキテクチャ内の各ファンクショナルブロックは、時間的特性からなる振舞いの制約を持つ。これら時間的特性は算術的に定量化されたもの、あるいはステートマシン、計算の制御フローとして表現される。Figure 8は、バッテリー機能のステートマシンモデルに制約を表現した例。ステートのインターバルとガードコンディションが、関連する算術的に定量化されたプロパティを表示。 
 

Figure 8: Screenshot of a temporal constraint declaration with state machines
 
このMetaEdit+ の例では、モデルチェックのゲートウエイが制約記述を解析して、外部のモデルを生成できる。そのためのマッピングルールのアルゴリズムはMetaEdit+ のジェネレータ機能に提供されている。これを解析ツールに応じて修正すること、あるいは一から独自のジェネレータを作ることもできる。
 
例えば顧客の要求に応じて開発されたSPIN,、UPPAAL,、HiP-HOPS、Modelica など、各種解析ツール用のジェネレータがある。Figure 9は、ステートマシンの制約から生成された外部モデルと、そのUPPAALツール上のシステム合成でステートマシンが実行されている例。
 

Figure 9: Screenshot of the generated UPPAAL file and model for model-checking
 
安全工学を支援するEAST-ADLのアーキテクチャモデリングでは、システムファンクションの振舞いのエラーと怪しまれる部分を、エラーモデリング機能によって、正確に注釈できる(Figure 10)。
 

Figure 10: Sample of error behavior annotations for a system architecture (L2_AA)
 
エラーモデルでは、コンポーネントの内部故障モードと、他のシステムの故障モードへの伝搬の正確な説明が得られる。Figure 11は、デザイン上のコミュニケーションリンク、あるいは割当ての関係に関わるエラーの伝搬を表示。
 
安全工学の支援機能として、MetaEdit+ にはアーキテクチャモデルを基にして、エラーモデルを自動生成することができる。そして担当者は各エラーモデルブロック内で、宣言されたコンポーネントの出力故障に関係するエラーロジックを、受信したローカルエラーにコンポーネントの出力異常を結びつけて、各エラーモデルブロック内にエラーロジックを指定する。この厳密な形式化はブール代数式やステートマシンにより可能となる。
 

Figure 11: Error model defining the plausible error behavior of target system architecture
 
 
MetaEdit+ では、エラーモデルを構文解析し、解析用のモデルを生成する、モデル変換用のゲートウエイが開発されている。Figure 12は、Figure 11のEAST-ADLのエラーモデルから、HiP-HOPSの解析用のモデルに変換された例。
 
またFigure 12のフォルトツリーには、故障モードがEAST-ADLのエラーモデル(Figure 11)から得られて保持されている事が示されている。ルートイベントであるbraking_failure_ALは、Figure 11の右端にあるアウトプットとして宣言されている。結果のフォルトツリーと合わせて、ファンクショナルとセーフティ要件の導出の確固たる基盤を構成できる。
 

Figure 12: The exported HiP-HOPS file and the analysis result fault tree
 

Conclusion

 
アーキテクチャモデルは、単一機能を実装することにフォーカスした従来式のモデルと比較して、様々な効果をもたらす。最もわかり易い効果は、大規模システムの全てを一つに統合してデザインできること。そしてツールのサポートにより、アーキテクチャの開発・編集を、チームメンバー間の共同作業で同時アクセスして行える。アーキテクチャモデルは、多くのサプライヤーが関わる開発作業の管理にも貢献する。個々のパーツが様々なチームに分割され、アーキテクチャのもと実装などの成果物が統合されて、チェックされる。
 
アーキテクチャモデルは、開発するシステムの解析や評価の理想的な基盤であり、早期段階で変更が容易でコスト増を招かない。モデルの解析はチェック、エラー解析、セーフティデザインなど。上述したモデルチェックやフォルトツリー解析など、異なるシステムレベルのデザインの評価、自動解析の実行と結果表示が可能になる。このような解析を早期に実施可能にすることで、開発コストの軽減や品質向上だけでなく、市場投入時期を早めることにも貢献する。
要件管理もアーキテクチャモデルと上手く統合される。多くの要件がアーキテクチャ上のハイレベルのエレメント(ファンクションや、それらの接続など)に明確に紐付けされるので。上述したように、既存の要件とアーキテクチャを連携させることがツールによってサポートされている。
 
アーキテクチャモデルの恩恵を受けるために、アーキテクチャを別に作ることや前もって作る必要は無い。既にある実装をベースにして初期段階のアーキテクチャを生成するなど、ツールによって多くの作業が自動化される。ツールは結果であるアーキテクチャモデルを既存の実装に対してチェックすることもできるし、これから開発する実装のためにインターフェイスを自動生成することもできる。自動生成をサポートするジェネレータは、AUTOSARやJasPar、あるいは内部プラットフォームなどのターゲットプラットフォームに応じたコンフィグレーションとマッピングを生成することもできる。
 
システムのサイズと複雑さが増大する中で、ツールのサポートは、これまで以上に重要になっている。単一のツールでは全ライフサイクルをカバーできないし、全てのドメインも、システムもカバーできない。アーキテクチャモデルで成果を上げるには、最適なツール選択として、個々にゆるぎない機能を有し、需要に応じて構成可能で、首尾一貫したツールチェインが求められる。
 
Dr. Juha-Pekka Tolvanen is CEO of MetaCase. He has been involved in domain-specific languages and tools since 1991 and acted as a consultant world-wide on their use. Juha-Pekka has co-authored a book (Domain-Specific Modeling, Wiley 2008) and over 80 articles in software development magazines and conferences. He can be reached at jpt@metacase.com.
 
De-Jiu Chen received his PhD degree in Mechanical Engineering from Swedish Royal Institute of Technology (KTH) in 2004 for his research on embedded computer control systems. His research interests include systems and software architecture, model-based engineering, dependability, and self-adaptive embedded systems. He is currently an associate professor at KTH.
 
Janne Luoma (M.Sc.) works as senior consultant at MetaCase Consulting. His area of expertise is in the engineering of software development methods for company-specific needs. Janne has over 15 years of experience as a consultant world-wide for method development and code generators. He can be reached at janne@metacase.com.