********************************************************************** セッションS5-a チュートリアル1 テーマ:ADLシステム設計最新動向 講師:奥村 洋(ガイアシステムソリューション)、佐藤 洋介(デンソー)、 Juha-Pekka Tolvanen(MetaCase) 日時:2010/9/3 14:50〜16:05 参加人数:30名前後 ********************************************************************** ◇アジェンダ 0.はじめに 1.イントロダクション 2.MARTEについて 3.メタエディットツール紹介 ◇内容 0.はじめに なぜいまシステム設計レベルの表現、モデリング表現に取り組まなければならないのか? という背景の説明。 その1つの事例であるMARTE、それを取り巻く欧州の研究動向についての紹介をしていく。 1.イントロダクション(佐藤氏) 特に今回焦点を合わせる領域は車のシャーシ、ボディのような部分である。もちろん、 車のみにあてはまる話ではない。 車の車両開発における課題、特に標準規格であるAUT@SARを中心に、ADLの活動が活発に なっている。 ・ソフトウェアの製品の動向として、大規模・複雑化がある ・搭載マイコンが増えている ・マイコン同士をつなぐネットワークが複雑である ・製品プログラムの規模自体が大きくなっている この4つのポイントが車載開発における大きな動向となっている。 現場の問題をまとめてみた。ここではある会社のテスト工程、デバッグ工程でのバグの 再発防止をどうしたらいいかまとめたものである。 ・最も多かったもの 不具合を出した人の考察を読んでいると、過去の設計レビューのほうで一度検討している が、今回の仕様変更の影響がどのくらいか自信がもてない。 差分開発したが、結合検査項目の網羅度が不安である。 他のコンポーネント(OS、通信ドライバ、IOドライバなど)の変更に気付かなくて誤った 設計をしてしまう。 実績があるソフト、つまり制御対象がかわらないのなら、過去の関数の利用は問題ない はずだが、再利用方法が問題になってしまている(ECU統合)。 →関数呼び出しに順序関係があったが、それが崩れて、共有データの衝突が発生。 設計の誤りに気付かなくて、単一ユーザの開発なら、テスト工程にて防げる。 (←ひとつの組織の中で、設計実装テストをおこなっているから) しかし、設計工程をA社、実装工程をB社と分担することで、設計工程のミスが検出 できるタイミングを逸してしまうという問題が新たに発生。 極論すると、 ・急激にソフトウェアが大規模 ・場当たり的に建て増しにより全体アーキテクチャが崩壊 ・ソースコードを削除するという行為に責任が発生→今の社員にはその責任が持てない →改築が難しくなってしまう、メタボ化 今は新規開発ではなくて変更修正を伴う継続開発が多い →仕様の変更と、設計モデル実装コードの変更が1対1に対応していない →その変更点、変化点をもれなくおさえられているのか?という不安が最も感じている 課題 ○モデルについて 正しく変更修正ができていることを確認できる状態にすればよい そのためのとるべき2つの手段がある ・各ドキュメントを正確に記述する ・それをレビューする 本セッションでは、どういう風に抽象化して仕様記述すればいいか、どういう表現手段 があるのかを伝えていく。 ”正確”とは詳細に全部を記述するのではなく、何を記述したいかという目的と検証する ための手段を記述し、不要なところを削除することである。 →解釈に誤解が発生しない書き方(解決策:数学的な裏付けのある言語などを使う) モデリング言語は様々なものがある。 今回は要求アーキテクチャ記述(いわゆる構造設計といった部分)に焦点を合わせる。 ▽補足:抽象化 AUT@SAR 抽象化をどういったレイヤでやるか→現在は4レイヤくらいで考えている ①ディーラーさんの所に行き、カタログをみながら機能について議論・検証 ②、③機能を実現するための論理的な構造を検証 ④その機能をハード/ソフトで実現するのかを検討・検証 このように、正確に書くということをモデリングのレベルを実装レベルに近づけていく というアプローチを取ろうとしている。 現在のトレンド UML的なアプローチと制御工学的なアプローチがいま融合しようとしている。 →UML MARTE これに伴って、世界の標準化動向にも様々なパワーバランスがある 北米:OMGを中心としたUML陣営。航空機系企業が中心 欧州(ドイツ):TIMMO、AUT@SAR 欧州(フランス):UML MARTE 2.MARTEについて(奥村氏) 6月にMARTEの話を聞く機会があり、それを含めて、MARTEとは?という紹介をする。 −MARTE(UML Profile for Modeling and Analysis of Real-Time and Enbedded systems) 2.1.MARTEとは(www.omgmarte.org/) ちょうどVersion1.0にアップしたばかり。 このURLで示したページへ行けば、スペックもありチュートリアルもプレゼン資料もあり、 情報へのアクセスは可能。しかし内容の把握は困難。←根拠がわからない部分がある。 さまざまなコンテンツがどのように決められているかを紹介してゆく。 2.2.MARTEはOMG的に見たときにどこに位置するか ・リアルタイム組み込みシステム向けUMLの歴史 UML登場初期:リアルタイム組み込みシステム向けではない。特に、非機能要求が書け ない、時間が書けない、といった問題がささやかれていた。 UML1.4:リアルタイム組み込みシステム向けのプロファイルを作ろうという動き→SPT というプロファイルが定義された。 UML2.0:リアルタイム組み込みシステム向けの側面が増えてきた。 SPTにも時間概念などに足らない点が浮上→UML2.0ベースでの新しいスペック策定(MARTE) 2.3.MARTEはどんな図が描けるのか 特徴的な図が書けることはない→見栄えとしては普通のUMLと同じだが、リアルタイム 組み込みシステム向けに記述できる項目内容が補填されている。 MARTEは、図面強化ではなくモデル化要素の強化がポイントといえる。 MARTEは上位のコンポーネントモデルを規定していて、ドメインごとの個別のADLに対応 できるようになっている→極端に詳細を書く必要はない、付加的な要素を記述する。 2.4.MARTEで何を決めているのか ・QoS-awareモデリング:量的資源に関するもの ・アーキテクチャモデリング:コンポーネントのモデリングから実行環境の配置 ・QoS解析モデリング ・資源モデリング RTOS、基本データ構造などの標準で使われるのもの定義がある。さらに、CVSLのように 時間を与えての記述方法、時間に対する制約を記述する方法も定義されている。 しかし、仕様としてみると、モデル化要素が決められているに過ぎず、問題意識がわか らないと何をやろうとしているのかが分からない。 2.5.MARTEはもともと何をしたかったのか 早期のアーキテクチャ推敲がポイント →実機で初めてわかるのではなく、モデルの段階で評価できる項目を増やしたい →そのために、Y字のアプローチを使う ・Y字って? 左側に動作する機能ブロック(アプリ)を置き、右側に実行プラットフォームを置く。 そして実行プラットフォームの上にアプリを乗せる。乗せ方によっては、 遅延が発生したりするが、その結果からアーキテクチャがおおよそ決まり、 見積上はいけそうと決まる。この見積もりに従って進めれば、後半での問題が発見 されることは少なくなるのではないか。ということがMARTEでしたいことである。 ・なぜMARTEの形式を決めたのか? 標準的な非機能プロパティ記述を決めたい →記述言語VSLにより、値を記述できるようにした →NEPにより非機能要求自体を記述できるようにした →アプリケーションと実行プラットフォームの配置 →資源量解析と、そういったツールとの接続 以上がポイントとなる 2.6.解析ツールとの接続 MARTEの中でいろいろな解析ができるわけではない。 MARTEは所詮UMLのプロファイルなので、プロセス、計算手法で確認できる項目などを 決めているわけではない。 UMLのMARTEの形で必要な情報を記述しておいて、その情報をツールに渡せばいい。 というのがMARTEの考え方である。 必要なモデル化要素を使ってモデルを記述し、それを外部ツールにより検証してもらい、 結果を戻してくる。といった使い方を想定。 2.7.Allocation アプリケーション層 実行プラットフォーム層(ソフトウェアリソース) ハードウェア層 ある固定された記述はなく、いろいろ記述できる。 →外部ツールにより評価してもらいたいので、MARTEですべて決めるのではなく、 外部ツールに対して必要なある要素を提供すればいい 実行される機能と、その機能を実行する側のプラットフォームとの間のマッピングと いう形に分けて性能評価する、というのが基本的な考え方。 2.8.NEP:非機能要求 かつてのUMLには非機能要求を記述できなかった→記述できるようにつくりかえた モデル上きちんと記述できる →計算機で処理できるようになっている(外部ツールにより処理) ・UML的に書ける箇所は3か所  −ステレオタイプの値  −スロット値  −制約 ・使い方  −NEPのタイプを決める  −NEPのモデル化要素に宣言  −実際にNEPの記述で埋める 従来では、テキストで記述するだけだったのものが、評価して計算機によって処理でき るというところがポイントである。 2.9.VSL UMLではint,real型の値を記述することができなかった→MARTEでは記述可能 VSLのポイントとしては、 ・こんなモデルで記述可能 ・そのモデルをテキストでも記述可能 といった点が規定してある。 OCLのように時間概念を拡張した言語であり、これを使って記述すると、ただのテキスト ではなく外部ツールで解釈できることがポイントとなっている。 2.10.TIME UML2.0にも時間のモデル化要素は存在するが、いい加減である。 そこを、MARTEではしっかり時間制約に対して記述してある。 時間が経過した時に状態遷移する、といった状態遷移マシンにおいて、どのクロックで 遷移するかを指定できる(何の時間で測るかを指定)。 これらを制約言語の形で記述可能。 2.11.解析スキーム 評価したいターゲットがある。 そして、アプリケーションがある実行プラットフォームに乗っている状態を想定し、 それらをあるシナリオで動作させたときの性能を評価・解析する。アクティビティ図を 使用。 MAST:研究レベルのツール。スペインの大学で開発 スケジューリング解析を行い結果を返す、といった接続テスト済み。 何がうれしいかというと、必要なツールに渡して解析できる。といった当初のスキーム を実現できたこと。データの変換をして、どんな外部ツールにでも対応できる。 2.12.流れの確認 一番上:高級アプリケーションモデル 非機能要求がかける、時間が書ける、値が書ける コンポーネントモデルがあり、それを実行プラットフォームに配置 ソフト・ハード資源モデル(RTOS、タスク・プロセッサ、メモリを想定) 共通部分を出しているが、スケジューラビリティの解析、パフォーマンスの解析 −消費電力の解析モデルなど 2.13.MARTE開発動機 アーキテクチャを早期に推敲 →アプリを実行PFに載せたときの実行モデルを調べたい →さまざまな解析ツールをつないで、資源解析できるようにしたい →非機能要求の非機能プロパティがかけないといけない →値がちゃんと記述できないといけない といった流れに基づいている。 S氏:補足。 標準化動向については、バジェットがどこから流れているかを気にするといい。 ドイツ陣営:ツールベンダに投資するという戦略なので、標準化する必要なし フランス、米国陣営:ツールの標準化という戦略で、相対的な価値をあげようとする ことでドイツに対抗 2.15.関連プロジェクト フランスに偏っていて、さまざまな領域がある。 特定分野を規定せず、分野要求を拾い上げて適応領域を広げている →リアルタイム組み込み向けの汎用DSL 2.16.プロファイルとは MARTEはUMLのプロファイルである←確認済み かつて、言語を使ってソフトウェアのモデルができた。 モデリング言語のためのメタ言語のベース、MOF。 クラスレベルでモデル化するときに、どんな要素使ってよいのかを決めるのがメタモデル。 メタモデルとしてどこまで記述していいのかを決めるがメタメタモデル。 現実世界にあるものをMARTEでモデル化するわけだからメタモデル段階。 UMLはDSL定義のためのメタ言語の位置づけ。 2.17. ドメインに対して、広くカバーするようなドメイン記述言語といえる。 ・ADLとしては基本的にマッピングを定義して、話が通じるようにする なぜマッピングを考えるか→ツールチェーン問題 スペックを決めることの嬉しさ→そのスペックどおりにツールを作ると、ちゃんと呼ぶ ことができ使用可能であること S氏:最近のトレンド やりたいモデリングに対して、やりたいプロファイルを選択する。というのがトレンド。 言語と言語の関係、実際に言語変換をどうするかをこの次のセッションで説明。 ・Eclipseモデリングプロジェクト  −Javaの開発環境プラットフォーム  −さらにその上に、モデリングができるレイアウトを構築 ・Papyrus  −商用レベルではない  −プロファイルを読み込んで、言語のエディタに分けるツール  ※従来のUMLツールはプロファイルのマネージメントが得意でない  −DSLエディタ用プラットフォーム ・TimeSquare  −CCSL:時間を含んだ表現をできる言語  −INRIAにより開発終了 ・EDONAプロジェクト  −自動車向けの開発ツール、プラットフォームを試すプロジェクト  −モデルを変換して、AUT@SARに渡すようなツールチェーンを想定  −Eclipseモデリングプロジェクトの成果を利用 2.18.まとめ ・MARTE リアルタイム組み込みシステム向けDSLを表現するためのUMLプロファイル。 時間・資源・解析の概念といったモデル開発についてと、それらの拡張性をこなす。 ・DSL DSLを簡単に定義する仕組みとしてUMLプロファイルを活用。 UML自体がソフトウェアをモデリングする言語からメタモデリングだけの言語という取扱 に変化してきている。 ・Tools メタモデリング言語のサポートのためのメタモデリング環境によりDSLをサポート。 2.19.最後に ・結論 DSLは計算機により自動化のコア技術の位置づけ  −書きたいことをDSLで書き、自動化すればよい。というのが基本の考え MDAがDSL技術の導入で産業向けに適用可能なフェーズに移行しつつある。 ・今後 欧州は産業、アカデミアの共通言語づくり、非競争領域への基盤構築が進行。 アメリカはツールベンダを活用し進めてくる  −欧州はオープンソースなどの方法で対抗 ・問題提起 日本はIT化により業務効率化をはかるしかない。 Eclipseのフォローアップに期待。 S氏:モデリングが得意な人たちはかついて日本にもいた。しかし、UMLに適応し始めた とき、アジャイルに流れて行く人、教育へ行く人と2つに分かれてしまった。 今、せめて欧州技術のフォローアップくらいはやらなければならないといえる。 ---------------質疑応答-------------------------- [質問]自動車制御ソフトウェアの研究開発をしています。Papyrusなどを自分で使って みたがきつい。何かほかに、スケジューラビリティ解析ツールなどがあったら教えて いただけるでしょうか? [回答]具体的なツールで攻めるという手法もある。(あとで個別に回答) [質問]パピルスをDSLとして用いて、ネクストジェネレーションでといった話の具体的 な目指すところなどを教えていただけますか? [回答]スフィンクスがプラットフォームとなって、その上にPapyrusの拡張部分を乗せる とPapyrusuができる、というイメージ。結局、可変部があって、可変部をプロファイル ないしはプラグインとしてさすことで新しいアプリケーションができるというメタ ツールについて説明をしたかった。 〜デモの準備のため3分ほど休憩〜 3.Juha pekka S氏:Papyrusを紹介するつもりだったが、Eclipseなので見た目が派手でなくわかりづ らいので、そのコンセプトを最も体現しているものとしてMetaCase社のメタエディット ツールのデモをJuhaさんからしていただく。 3.1.Swest panel on architecture description languages 関数的アーキテクチャというものがあり、ハードウェアシステムベースである ・リスク言語アーキテクチャ  −探索手段の種類  −ハードウェア資源配置 どのようにデザインするか。 良い言語とは、設計したどんな構築物(モデル)においても対応可能であること。 ・言語による仕様の相違  −TVのファームウェア ・マルチコア並列コンピューティング  −スーパバイザ ・グラフィカル言語  −メタモデル:モデリング言語(詳細についてはEAST-ADL言語を参考)  数多くのモデリング言語の中から最適なものを検討・適用するには2つのアプローチが ある ・tranceformation:変換 ・separate key:キーによる分割 ハードウェアデザインを関数モデルへと変換する 異なるアーキテクチャでもコンフィギュレーションすることが可能。 3.2.まとめ ツール環境側のいくつかの特権として、自分で言語をカスタマイズする環境が広まりつ つあるという事例の紹介であった。 メタエディットを使いADL(メタモデル)を自分で定義して、それをもとにVHDL、AUT@SAR のコンポーネントを生成するツールを持ってくるなどのように確実に広まっている。 モデル言語を自分でカスタマイズして、他の抽象度の言語を生成する環境が広まってい るのが現状といえるだろう。 以上。