2014ソフトウエアによって実現される車載システムや組込みシステムの規模と複雑さは増大する一方である。それゆえ全ライフサイクルのコストと工数を効率化するためには、それに見合った開発手法やツールの改善が欠かせない。異なるサブシステムの統合や、様々な側面を持つエンジニアリングの連携といった、著しいボトルネックに対処するためには、従来以上にツールの支援が重要視され始めている。ツール間のハイレベルな開発情報の統合は、システム開発と品質管理をモデルベース開発手法で取組むことによってのみ実現され得る。組込みソフトウエアシステムのアーキテクチャには、ソフトウエアの機能性だけでなく、それに関わる要求仕様、リソースの割当て、タイミング、安全性、変動性(プロダクトライン)などもモデル化される。各機能の実装レベルの詳細から、完全なシステム全体のデザインに焦点を上げること。アーキテクチャ上の成果物を形式的に扱うことで、モデルベース手法でシステムの仕様記述が正確で一貫性が取れるようになり、早期段階からシステムの振舞いや特性を予測すること、形式的な設計情報を基にした評価や最適化を実施できるようになる。この資料では、企業がモデルベースのアーキテクチャ設計に移管して成果を上げることが容易であることを、我々の経験から紹介する。ここでは車載システムの電気・電子システムを例にするが、内容の本質とツールの支援機能は、これに制限されるものでは無く、あらゆるドメインに活用できる。implementations既にデザインや実装はあるが、どうやってアーキテクチャを定義するか?相互に補完できる3つの仕掛けで、デザインや実装とアーキテクチャ定義を同調させることができる。最初の仕掛けは既存のデザインや実装を、初期段階のアーキテクチャモデルの生成に利用すること。この資料の例(車載システム)では、Simulinkモデル。アーキテクチャに関連するパーツ(モジュールの階層構造やポートを介した通信)のみを抽出。ジェネレータ機能を用いてSimulinkモデルを構文解析し、当該パーツを抽出し、アーキテクチャモデルを自動生成する。この手のリバースエンジニアリングでは理想的なアーキテクチャデザインには辿り着くことはなく、従来の開発習慣を改革して、労力を軽減する適正なソリューションが必要であることに、多くの組織が直面することになる。2つ目の仕掛けも既存のモデルやレガシーコードを構文解析すること。一貫性のチェックを目的に。アーキテクチャデザインは既存の実装に対して検証され、違いがレポートされる。これによって計画されるアーキテクチャと様々なサプライヤーによって提供される現実的な実装との比較がなされる。ポートやコネクション、インターフェイスなど、個々のモジュールのアーキテクチャレベルのインターフェイスが比較検査される。1にはアーキテクチャビュー(パワーサプライのファンクショナル・コンポーネントとポートを介した接続)における自動チェッキングの結果が表示されている。1の下段に一致性チェックの結果、Simulinkモデルに存在するポート(PowerConversionCtrl)が、アーキテクチャモデル上には無いと表示されている。これにより実装側を修正するべきか、アーキテクチャを更新すべきかを考察できるようになる。このチェックはインターフェイス、クライアント/サーバーベースのコネクション、電源接続、I/O接続など、アーキテクチャの他のエレメントもカバーする。3つめの仕掛けは、モジュール設計やコードなど、より明確なデザインや実装仕様を、アーキテクチャモデルから直接生成させる。この資料の例(車載システム)では、Simulinkモデルをアーキテクチャモデルから自動生成。これにより異なるサプライヤーに割当てられるモジュールが、全体的なアーキテクチャに準拠できるようになる。ツールレベルの実質的な統合は、インターフェイスと、ツールの統合機能によって行われる。このアーキテクチャモデルの例では、MetaEdit+のジェネレータ機能とAPI、そしてSimulinkのファイル形式を利用。ここでツールの選択要件として、効率的な統合を支援する、オープンなデータ交換のインターフェイスと機能が重要な鍵となる。注意したいのは、ツールは偏見なく評価するべきであること。オープンソースのツールが他のツールとのインターフェイスを提供するとは限らないし、市販ツールが様々なインターフェイス機能や既成の統合環境を用意することも多くなっている。基本的にアーキテクチャモデルは、専用の要件管理ツールで管理される要求仕様や、エクセルやワードなど既存の各種データと統合できる。2はスプレッドシート上の要求仕様をアーキテクチャデザインにインポートした例。リンクにより、インポートされた要件とアーキテクチャ上の個々のパーツとの割当て(Allocation)が、明確なトレーサビリティとして表現されている。要件の変更を、アーキテクチャモデリングツール上で自動反映させる機能もある。これにより要件は、アーキテクチャモデルと、専用の要件管理ツールのどちらにおいても、開発プロセス内で柔軟に管理できる。ここではReqIFなど共通の形式を用いて、要件の連携が行われる。use車載ソフトウエアシステムの機能性は一般に、アプリケーションロジックとシステムバウンダリをファンクショナルブロックとコネクタでモデル化する、ファンクショナルビューで仕様化される。ファンクショナルアーキテクチャモデルの例。このようなモデルは、他のモデル(振舞い、追加の機能、技術上の制約など)と連携して、システムの統合や分析の主要な役割を担う。部品とそれらの接続を記述する、ハードウエアアーキテクチャモデルが、これを支援する。3は、ブレーキシステムのハードウエアアーキテクチャ例。センサー、ECUノード、アクチュエータ、各種電子部品、そして部品間の様々なハードウエア接続。modelこのモデルはEAST-ADL(車載システムアーキテクチャ向けのドメインスペシフィック言語)のハードウエアアーキテクチャビューを用いて作られた。この言語では、ECU、バス、ワイヤーといった車載システム開発に通じたコンセプトを直接用い、またルールや制約を持たせることで、モデリングや検証作業が効率化され、可読性も向上している。EAST-ADL言語の全てのコンセプトは、個々にプロパティを持つので、開発担当者がエレメントを作る時に、該当するプロパティのみ問われるようになっている。全エレメントは独自の表記を持つので、グラフ上で他との識別は容易である。この言語の機能により、モデルの正しさや完全性がチェックされるので、モデルはフォーマル(形式的)に記述され、解析ツールやジェネレータ(モデル変換)にも活用される。hardwareアーキテクチャデザインは、システムのファンクショナルなビューとハードウエアのビューの合成を支援する。4のアロケーションのマトリクスは、左列に各ファンクションが、行上部に物理的なハードウエアが表示されている。ハードウエアに対するファンクションの割当てが表現されている。各ハードウエアエレメント内に割当てられているファンクションを表示させながら、割当て・解除を試行錯誤することもできる。platforms.アーキテクチャデザインは協調して行われ(時には同じダイアグラムを同時に)、モデルは様々な用途に使用される。4のようなハードと機能の割当てをベースに、アーキテクチャはソフトウエアコンポーネント構造に変換され、ソフトウエアプラットフォームの基になる。同時に、この割当ては、様々なプラットフォームへの機能のマップにも使用される。パーツによっては内部フレームワークで実行されるし、AUTOSARにマップされるものもある。flowsアーキテクチャモデルは様々な解析にも利用できる。26262のような国際規格は、アーキテクチャモデルによってサポートされる。AUTOSAR向けに.arxmlを生成する代わりに、アーキテクチャモデルはデペンダビリティモデルの基や、エラーモデルの生成に活用できる。アーキテクチャモデリング言語には、正しさや完全性をチェックする機能を有し、フォーマルなモデルをジェネレータ(モデル変換)に提供できるので。アーキテクチャモデルから自動生成されたエラーモデルの例。これにより、安全設計段階において計画されているアーキテクチャの全てのアスペクト(側面)を考察することが支援される。architectureこのエラーモデルは安全分析の基を形成し、エラーの伝搬を分析している。とマーキングされている。このアウトプットポートのエラーの原因と想定されるファンクションやインプットは、青色のアウトラインでハイライトされている。modelingアーキテクチャ設計のフォーカスはシステムのコンフィグレーションではあるものの、有益な副産物として振舞いのプロパティが、要件や、構造化ユニット、その他アーキテクチャの成果物に関連づけられる。振舞いのモデルが、テキストレベルの要求仕様を洗練するために使用される。境界条件、変数のインバリアント、状態や状態遷移など、振舞いの関心事をフォーマルに(形式化)することで。これにより振舞いのモデルと要求仕様とがシームレスに統合される。Constraintsと称されている抽象的な振舞いの仕様は、システムブロックに連携されている。全ての実体は、当該の制約のタイプに属する。デザインでは、このように制約が注釈されることは、様々な理由で必要となる。合成の評価や、合成のチェック、モデル間の一致性の管理など。セマンティクスとともに、アーキテクチャ内の各ファンクショナルブロックは、時間的特性からなる振舞いの制約を持つ。これら時間的特性は算術的に定量化されたもの、あるいはステートマシン、計算の制御フローとして表現される。8は、バッテリー機能のステートマシンモデルに制約を表現した例。ステートのインターバルとガードコンディションが、関連する算術的に定量化されたプロパティを表示。例では、モデルチェックのゲートウエイが制約記述を解析して、外部のモデルを生成できる。ジェネレータ機能に提供されている。これを解析ツールに応じて修正すること、あるいは一から独自のジェネレータを作ることもできる。各種解析ツール用のジェネレータがある。9は、ステートマシンの制約から生成された外部モデルと、そのUPPAALツール上のシステム合成でステートマシンが実行されている例。(L2_AA)エラーモデルでは、コンポーネントの内部故障モードと、他のシステムの故障モードへの伝搬の正確な説明が得られる。11は、デザイン上のコミュニケーションリンク、あるいは割当ての関係に関わるエラーの伝搬を表示。アーキテクチャモデルを基にして、エラーモデルを自動生成することができる。担当者は各エラーモデルブロック内で、宣言されたコンポーネントの出力故障に関係するエラーロジックを、受信したローカルエラーにコンポーネントの出力異常を結びつけて、各エラーモデルブロック内にエラーロジックを指定する。この厳密な形式化はブール代数式やステートマシンにより可能となる。エラーモデルを構文解析し、解析用のモデルを生成する、モデル変換用のゲートウエイが開発されている。11のEAST-ADLのエラーモデルから、HiP-HOPSの解析用のモデルに変換された例。11)から得られて保持されている事が示されている。11の右端にあるアウトプットとして宣言されている。結果のフォルトツリーと合わせて、ファンクショナルとセーフティ要件の導出の確固たる基盤を構成できる。treeConclusionアーキテクチャモデルは、単一機能を実装することにフォーカスした従来式のモデルと比較して、様々な効果をもたらす。わかり易い効果は、大規模システムの全てを一つに統合してデザインできること。ツールのサポートにより、アーキテクチャの開発・編集を、チームメンバー間の共同作業で同時アクセスして行える。アーキテクチャモデルは、多くのサプライヤーが関わる開発作業の管理にも貢献する。個々のパーツが様々なチームに分割され、アーキテクチャのもと実装などの成果物が統合されて、チェックされる。アーキテクチャモデルは、開発するシステムの解析や評価の理想的な基盤であり、早期段階で変更が容易でコスト増を招かない。モデルの解析はチェック、エラー解析、セーフティデザインなど。上述したモデルチェックやフォルトツリー解析など、異なるシステムレベルのデザインの評価、自動解析の実行と結果表示が可能になる。このような解析を早期に実施可能にすることで、開発コストの軽減や品質向上だけでなく、市場投入時期を早めることにも貢献する。要件管理もアーキテクチャモデルと上手く統合される。多くの要件がアーキテクチャ上のハイレベルのエレメント(ファンクションや、それらの接続など)に明確に紐付けされるので。上述したように、既存の要件とアーキテクチャを連携させることがツールによってサポートされている。アーキテクチャモデルの恩恵を受けるために、アーキテクチャを別に作ることや前もって作る必要は無い。ある実装をベースにして初期段階のアーキテクチャを生成するなど、ツールによって多くの作業が自動化される。ツールは結果であるアーキテクチャモデルを既存の実装に対してチェックすることもできるし、これから開発する実装のためにインターフェイスを自動生成することもできる。自動生成をサポートするジェネレータは、AUTOSARやJasPar、あるいは内部プラットフォームなどのターゲットプラットフォームに応じたコンフィグレーションとマッピングを生成することもできる。システムのサイズと複雑さが増大する中で、ツールのサポートは、これまで以上に重要になっている。単一のツールでは全ライフサイクルをカバーできないし、全てのドメインも、システムもカバーできない。アーキテクチャモデルで成果を上げるには、最適なツール選択として、個々にゆるぎない機能を有し、需要に応じて構成可能で、首尾一貫したツールチェインが求められる。