HOME | products | MetaEdit+ | MetaEdit+ software and hardware co-design

SWとHWのコデザインに DSM言語を統合

組込みシステム開発では、ソフトウエアとハードウエア両方の異なるアーキテクチャ間の代替案を分析・管理する必要があり、様々なアーキテクチャ記述言語が必要になる。 それら多くはインハウスで各企業あるいは特定製品用に開発されている(Philips社のKoala などのように)。 また自動車ドメインのアーキテクチャ記述言語である AADLEAST-ADLAUTOSAR など一定規模のコンソーシアムとして開発される DSL も多く存在する。それぞれ異なった目的を持ったドメイン・スペシフィック・モデリング言語として。
 
組込みSWアーキテクチャのセミナー(seminar)に備えて、共通メタモデル上に統合される 2つの言語を実装した。ネットワークアーキテクチャの機能アーキテクチャと、HWアーキテクチャ。これら言語により個々のアーキテクチャは別々にデザインできる。そして何よりも重要なのは、SWで提供される機能を、異なったHWアーキテクチャに割当てるというコデザイン。下の動画( 9 minute video)では、システムのデザイン視点から、一つの言語で統合されるモデル上の変更が他のモデル上でどう現れるかをデモすることで、複数の言語がどのように統合されるかを紹介する。
 

ボート(船舶)の機能と HW のコデザイン(英語音声)


 

動画デモのシナリオ

 
*HWアーキテクチャ図:
 
 ボート(船舶)の自動運転処理コンピュータには専用のフィールドバス(SeaTalk)を介して、表示パネルやセンサーの情報(コンパス、ラダー(舵)、速度、ログ情報、温度、風力など)が、それぞれのケーブルで接続される。 現在 HWアーキテクチャには2種のモデルがある(フィールドバスのみ、フィールドバスとケーブル接続の両方)
 
*機能アーキテクチャ図:
 
 例えばコンパスやラダーなどのセンサー情報を受けて、自動操縦装置(Autopilot)はボードの進行方向やモータを制御する。また風向と風速センサーで得られる情報と、ボードの速度を処理して、実際の風向と風速を得る機能もある。
 
 この機能デザインモデルにGPSセンサー、ナビゲータ を追加モデリングして自動操縦装置に接続。
 
 このモデル左上にある2つの長方形(緑色)は、2種のHWアーキテクチャモデル(Single Fieldbus と、Cable & Single Fieldbus )のいずれかと連携できることを示している。
 
 -Single Fieldbus フィールドバスのみ
 -Cable & Single Fieldbus フィールドバスとケーブル接続の両方
 
 次に PC接続用のバスを追加した、新しいHWアーキテクチャモデルを定義してみる
 
*新しいHWアーキテクチャモデルの実装
 
 既存のHWデザイン(Cable & Single Fieldbus)をコピーして、追加のネットワークとしてNMEAを追加モデリング。そしてゲートウエイを追加して、専用フィールドバスと接続させる。そこにPCをUSBで接続することで、PC上のナビゲーションソフトを自動操縦装置や各種センサーと連携させられる。
 
 HWアーキテクチャ図内の白色オブジェクト内 イタリック (斜字)表示に注目。
これらは機能アーキテクチャで定義されている各種機能が、そのHWアーキテクチャ上で採用されていることを視覚化している。

  (NMEA:National Marine Electronics Associationの略でデータ転送の標準フォーマット。GPS受信機の出力するメッセージを定義するもの)

 
*機能アーキテクチャ図にHWアーキテクチャ図を連携させる(赤色チェックで)
 
 機能アーキテクチャモデル図内の黄色オブジェクト内にも、 HWアーキテクチャ上の各接続が イタリック 表示で視覚化されることがわかる。
ここで GPSなどの接続を定義していないHWアーキテクチャ図を選択すると、”not assigned ” と即座に不整合を指摘する。
 
そこでCable & Single FieldbusにもGPSセンサー、ChartPlotter(Navigatorソフトを介して) を追加してみる。そうすることで、その結果が機能アーキテクチャ図にも自動反映される。
 

MetaEdit+ ならこの例のように1つのメタモデルに複数アーキテクチャモデルを統合させることが出来る。 あるいはモデルからのコード生成機能を用いてモデルから他のモデルへ変換させることで統合させることもできる。これら手法の+/-は以下の通り。
 
<一つのメタモデルで統合>
+あるモデル側の変更が他のモデル側でわかりやすくなる
+同じツール上で両モデルを扱えるので作業を単純化できる
-メタモデル内のルールを当初から想定する必要がある(MetaEdit+ ならメタモデル・ジェネレータなどの変更・修正が柔軟にサポートされるので問題にはならない)
 
<モデルから他のモデルへ変換することで統合(コード生成機能を活用)>
+モデルごとに異なるモデリングツールで分離できる
+統合のルールの変更は容易、あるいは後からでも追加できる
-あるモデル側の変更を他のモデル側に反映させるのは容易でない(モデルからコードのように一方向なら問題にはならないが)

 
 
ADL に関して興味があれば、 FESA workshop in Stockholm は参考になるでしょう。
 
この記事のオリジナル LinkIconIntegrating Domain-Specific Languages: an example of embedded software and hardware co-design