やっとかめIT風雲録

最近、ヨーロッパの研究開発に関する施策を少々、調べてみました。誤解があるかもしれませんが、以下のような感じでしょうか.

公的投資の主体はやはり欧州委員会(The Europe Commission)。もちろん、委員会やその執行組織的な性格を持つ総局(Directrorerate General)が直接、議論する訳ではなく、学者(多分碩学と呼ばれる人たちだと思う)により組織されるEARMAという組織が、Europe Research Area(ERA)とよばれる重点研究対象領域を設定する。ERAの企画実施の実体とも言えるのがEuropean Technology Platformと呼ばれる協議体で、企業, 学者,EC総局、場合によっては消費者から構成されるとされています。そこで、何を行うのべきか? という議論を行い、出資対象プロジェクトの募集要項を決めるという手順をとっているようです。これにより審査採用されるR&Dファンドともプロジェクト群ともいうべきものがFramework Programme(通称FP) と呼ばれるもの。実際、FPのプロジェクトのカタログを見ると、出資者(?)であるEC,ETP, FP-7や6のロゴマークが並んでいます。
上の話は、欧州単位の話、それと連携をとっているのが、ナショナル・プロジェクト。フラウンフォーファーや、CEAのプロジェクトがこれに相当するものと思われます。更に、地域毎のプロジェクトとの連携もあるとのこと。

ここまでは、道具だての話。「欧州の競争力を高め、雇用を産み出すため」というのがまず宣言されています。なぜ、こんなことをやるのか? 税金を使うので域内のために使う。当然ですね。でも、一方で、持続可能な社会を(地球規模で)実現する、ということも謳っています。実際、純粋な欧州企業だけがFP-7のプロジェクトに顔を出しているかというと、NECやRenesasといった名前も顔を出していたりしますので、予算獲得の美辞麗句といった範囲を越えているように思えます(自動車関係のプロジェクでは、欧州系テレコムやIBMの名前がないのが不思議な気がしますが・・・・)。

ECUというと、Engine Control Unitと思う人とElectric Control Unitと思う人がいる。
それはなぜか? というのは、次の文を読むと分かるかもしれません。
もとは、別の文章用に準備したものですので、論文調はご容赦ください。
では、

自動車にコンピュータが搭載された嚆矢は、フォルクスワーゲンタイプ3の燃料噴射装置であり、1969年のことであった。また、1975年には日産フェアレディZが採用するなど徐々に市販車クラスにおいても燃料噴射制御用途として普及し始めた。この動きの背景として、1960年代から1970年代にかけて行なわれたアメリカ合衆国政府内での自動車廃棄物規制への対応や、1973年から1974年にかけて起こったオイル・ショックの影響で市場から大排気量や大馬力自動車に対する疑問が突きつけたことなどが挙げられる。

この動きの中で、1970年代後半から1980年代中頃にかけて、ほとんどの自動車メーカーはキャブレタ(気化器)を廃止し、電子回路で制御を行なうインジェクタ(燃料噴射機)を採用するようになった。電子回路あるいはマイクロ・コンピュータの技術が進化し、インジェクタに必要な能力や形状（大きさ）を提供できるようになったことが大きな要因となっている。

行政的な側面では、1988年からカルフォルニアで適用された自動車へのOBD-I搭載の義務付けの影響は大きい。OBDは、カルフォルニア大気資源保護局が研究していた概念であり、車両から排出される汚染物質を抑制するための電子システムとその故障を診断するためのシステムである。その後、1996年以降に全米でOBD-Iの欠点を改善したOBD-IIが適用され自動車へOBD-II搭載が義務付けられた。このことにより環境対策としてのオンボード・コンピュータはその存在を確立したと言える。OBD-IIは、ODB-Iを拡大したもので自動車の排気ガス制御状況を車載コンピュータ(on board computer)でモニターすることを義務付け、そのコネクタ形状などを規定している。 1990年代からは、車載コンピュータは、燃料系の制御に加え、走行支援システム、ブレーキ・システム、走行計などの制御なども担当するようになり、ECU(電子制御ユニット)へと進化していった。

ECUの用語の変化という視点では、On-board computerの主な用途が、排出物規制を実現するための燃料噴射制御とそのモニターであった時期が長く、本来ならECUであるエンジン・コントロール・ユニットが実態に即した呼称であったが、1990年代以降、車載コンピュータの用途が拡大するにつれ、ECU（電子制御ユニット）とするのが相応しくなり、今日ではECU Electric Control Unit（電子制御ユニット）と認識されるようになったとするのが最も実態に近い説明であろう。また、今日ではOBD-IIを通じてiPhoneをオンボード・コンピュータとして使用するなど、新たな展開が始まっているように見える。

参考資料:

http://en.wikipedia.org/wiki/On-board_diagnostics#History

自動車用語中辞典

AUTOSAR の第二回オープン・カンファレンスが3月3日に東京で開催されます。
日本語フライヤーです。もちろん、英文フライヤーもあります。
詳細は後日発表とのこと。

ちなみに第一回は、2008年10月にデトロイトで開催されました。

少し間があいてしまいましたが、MARTEのPart IIを眺めてみましょう。

やはり、「A UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded systems, Beta 2 」が対象です。

 

Part II MARTE Design Modelの章立ては次の通りです。

12 Generic Component Model (GCM)

13 High-Level Application Modeling (HLAM)

14 Detailed Resource Modeling (DRM)

 「A UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded systems, Beta 2 」から引用)

 

12章で議論されるGeneral Component Model (GCM)は、リアルタイム組込みシステム開発における成果物のモデルを議論する必要から定義された追加的なコンセプトで、リアルタイム組込みシステムをコンポーネントベースで開発するときや、モデルを簡素化するのに便利だと説明されています。SysMLや、EAST-ADL2との関係もここで説明されています。

.

13章では、 リアルタイム性と組込みシステムの特性を取り扱うための抽象度の高いモデリング・コンセプトを取り扱うために用意されたHigh-Level Application Modeling (HLAM)について、リアルタイム・システムがどのようなものとして見えるかなどの例を示しながら説明しています。

 

14章は、 Detailed Resource Modeling (DRM)についてです。ここのDetailedというのは、ソフトウェアとハードウェアを意味しています。いよいよ、ソフトウェアとハードウェアが明示的に分離されます。Software resource modeling(SRM)とHardware resource modeling(HRM)について、文法と記法の説明が展開されます。

 

以上、詳しく見たい方、疑問を持たれた方、仕様書等にあたってみてください。 

ここまでで、258ページ。残りは約400ページ。

 

参考URL

OMG MARTE http://www.omgmarte.org/

ITEA MARTE http://www.martes-itea.org/public/news.php

Object Research http://www.object-report.jp/2009/03/05/omgmarte_tutorial_translation/

MARTEのPart II を眺めるつもりでしたが、少し脱線。

MARTE, EAST-ADL2などは欧州生まれ。これらの動きの源は、EUREKA- ITEA(2)にあります。

EUREKAは1985年設立ですから、第五世代コンピュータで、ブイブイ言わせてた頃の日本に対抗するための産学官連携組織と言っても大きな間違いはないでしょう(Σはどうでしょう?)。その後、2000年にミッションの再確認文書が出ています。これによると、インダストリー主導、非官僚主義。柔軟性を持って領域横断的で高度な研究と開発を行なうとあります。

ITEA-2は、EUREKAを構成するクラスタの一つで、ソフトウェア・エンジニアリングに焦点を当てたものです。やはり、マーケット主導で、研究と企業を結びつけることをうたっていますが、加えて、競合/競争段階に入る前のテーマを選択すると同時に中小企業の輩出も狙う、といったこともうたわれています。

あれから20年余。

 今のEUREKAやITEA-2の人たちは、「生産手段の迅速な展開能力を前提に、(ソフトウェアを含むシステムの)デザイン能力を産業ドメインをまたがってアジャイルに展開する。」みたいなことを考えているように見えます。 

 

 今回は、MARTEのPart I を眺めてみましょう。

やはり、「A UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded systems, Beta 2 」が対象です。

Part I MARTE Foundationsの章立ては次の通りです。

 

Part I MARTE Foundations

7 Core Elements (CoreElements) ......................................................... 21

8 Non-functional Properties Modeling (NFPs) ....................................... 31

9 Time Modeling (Time) ...................................................................... 51

10 Generic Resource Modeling (GRM) ................................................. 85

11 Allocation Modeling (Alloc) ............................................................. 115

 

Part Iは、MARETで使われる道具立ての定義と説明が行われます。

第7章 Core Elementsでは、モデル駆動アプローチに必要な要素、特に、リアルタイム組込みの領域に固有な要素の定義が行われます。ここでFoundationとCausality(因果関係)の二つのパッケージが登場します。Causalityパッケージはリアルタイム組込みシステムの表現を行なう為に導入されたもので、第9章と関係しています。

第8章はNon-Functional Properties Modelong(NFPs)。非機能要件を、定性的あるいは定量的に記述するためのフレームワークを定義しています。MARTEで想定している非機能要件は、スループット、遅延、オーバーへッド、スケジューリング方針、デッドライン、メモリ使用などの特性などです。また、Value Specification Language(Appendix B)で定数、変数、組や式の値などを記述するための道具立てを用意しています。何が非機能要件に該当するかは一概には言えないと言われていますが、エンタープライズ系の場合には、参考URLに示すものなどで詳しい議論が見られます。

第9章 Time Modeling。MARTEで使用する時間と時間に関係するコンセプトを定義しリアルタイム組込みシステムのモデリングの記述に適したメカニズムを導入しています。ここではリアルタイムシステム組み込みシステムでは必須と考えられる、遅延、期間、クロック時間などの時間濃度(cardinality of time )など実測値で示される時間と、論理的な時間モデルの双方が扱われます。

第10章　Generic Resource Modelingは、システム・レベルのリソース・モデル、つまりリアルタイム組込みアプリケーションの実行のためのプラットフォームを記述するための枠組みを与えます。ここで言うプラットフォームは、ハードウェア・プラットフォームと、リアルタイムOSなどのソフトウェア・プラットフォームを意味しています。

第11章は、実行プラットフォームへの機能アプリケーション要素の配置(Allocation)について議論しています。ある時点から別々に設計されてきた実行ハードウェアとアプリケーションを相互にマッピングし、物理的資源とスケジューリング可能性を評価するための基本的な記法が示されています。この章はSysMLと強い関係にあることが言及されてもいます。

詳しくは、その道の専門家に訊くか、仕様書をご覧下さい。

 

ここまでで150ページ少々。まだまだ山のように残っています。

 

参考URL

OMG MARTE http://www.omgmarte.org/

ITEA MARTE http://www.martes-itea.org/public/news.php

Object Research http://www.object-report.jp/2009/03/05/omgmarte_tutorial_translation/

OMG SysML  http://www.otij.org/omginfo/technology/primer/sysml.html

 

　　情報システムの信頼性向上に関するガイドライン

http://www.meti.go.jp/press/20060615002/20060615002.html

 

 

 

MARTEは、Modeling and Analysis of Real-time and Embedded systemsの略です。

文字通り、組み込みリアルタイム・システムをモデル化するためのUMLプロファイルです。時間モデルに限って見ても、Basic Time Models、Multiple Time Models、Time Event Modelsなど、この世界で使われそうなものはおよそ全て定義されており、更にCCSL(Crock Constraint Specific Language)という記述言語まで付いている巨大なものです。興味のある方は文末の参考URLを覗いて見て下さい。

で、内容については参考URLその他にお任せし、これをどんな人たちが作ったかを見てみましょう。

 

A UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded systems, Beta 2 (convenience document without change bars)によると、基本的な権利を持っているは次の各社です。

 

© 2001-2007, Alcatel-Lucent (仏) 

© 2003-2007, ARTISAN Software Tools (英米) 

© 2001-2007, International Business Machines Corporation(米)

© 2003-2007, Telelogic AB(スェーデン) 

© 2003-2007, Lockheed Martin Corporation(米) 

© 1997-2007, Object Management Group(米)

© 2001-2007, SOFTEAM (仏) 

© 2003-2007, THALES(仏)

欧州企業が目立ちます。MARTEはEUREKA-ITEAの成果ですので当然と言えば当然の話です。ちなみにMARTEプロジェクトは2005年から2007年末、パートナーは次の通りでした。

 

Barco, CoFluent Design, GMV, INRIA, Katholieke Universiteit Leuven, Lund University, Nokia, Philips, Softeam, Tampere University of Technology, Telefónica I+D, Telelogic, Thales Communications, Thales Research & Technology, Universidad Carlos III de Madrid, University of Cantabria, VTT Electronics(MARTE Project profileから)

聞いたことのない大学/研究所の名前が結構入っていますね。きっと裾野が広いのでしょう。

それにしてもEUREKA計画。昔々AIをやっていた人などは懐かしい名前かもしれません。存続し今も続々とアウトプットを出している。たいしたものです。

 

参考URL

OMG MARTE 　http://www.omgmarte.org/

ITEA MARTE 　http://www.martes-itea.org/public/news.php

　　　Object Research http://www.object-report.jp/2009/03/05/omgmarte_tutorial_translation/

EUREKA   　　　　http://www.eureka.be/home.do

 

平鍋さんからコメントを頂いた。メカ/エレ/ソフト/ツールという身分制ができているとのこと。平鍋さんをして嘆かせるような状況は、よろしくないような気がする。

 

ツールを作ることとはどういうことだろう。

問題の領域を定義し、構造を解明し、解くための方法を探究し、それを例えばソフトウェア・システムとして実現すること　だろう。

それぞれの過程で出来合いの答えがあることの方が珍しく、何人もの人間の思索や努力を経て見出されるものであることが多いだろう。ツールそれ自体が、先行する人たちも含めた英知の結実だと思うべきだ。

さらに、ツールは、うまく設計されていれば、それを使う現場の人たちの経験やそこでの新しい発見を乗せて、その先に向かって成長できるものだ。

 

使い易いハンマーを求めることも必要だが、もぐら叩きというゲームを解析し攻略のため様々な解を探求し、ゲームそのものの進化を実現することが必要なのだと思う。

 

私は、平鍋さんとは少し分野が違っているが、問題の定義から行なおうとしている。一緒に動いてくれそうな方々は実はIT業界の外の人たちだ。

エンタープライズ系IT系から組込み系ITの世界に移住してから5年ほど。間違ったことは(あまり)言わなくなったと思えるようになるまで、3年以上はやっぱりかかるんだと思っていたりする今日この頃です。

 以下、長い間の無沙汰のお詫び代わりのメモです。

 

MDD

最近、身の回りで話題になっている単語はMDD。Model Driven DesignとかDevelopment(モデル駆動型設計/開発)の略です。エンタープライズ系の方々には既にお馴染みのものでしょう。組込み系、特に車載システム系(ソフトウェアを含む電気/電子システム)でも、ここ2～3年急速にバズワードになってきています。もっとも、この世界ではMATLAB/Simulinkがデファクト的存在ですので、エンタープライズ系とはいささか様相を異にしています。ソフトウェア側から見た時のキーワードの一つがOMGが作業をしているMARTE(Modeling and Analysis of Real-Time & Embedded Systems)です。会社の勉強会で仕様を読みましたが、思考過程がこぼれ落ちてくるというか、なかなか「生」な感じの内容です。時間の扱いの部分などは、学部一年の教科書に出てくる微分の定義を思い出させます・・・・。

 

AUTOSARとEAST-ADL2

MDDでは、様々なレベルの抽象度の「モデル」を記述し、それらが「正しく記述されているか?」、「記述されたものは妥当か?」を検証しながら実装に落とし込ます。MATLAB/Simulinkもこの目的を満たすものですが、ソフトウェア側からのアプローチとして、実装部分ではAUTOSAR、それより上位レベルでEAST-ADL2が提唱されています。有志で、EAST-ADL2の仕様を眺めている最中ですが、Feature-Oriented Design Analysis(FODA)を基礎とするソフトウェア・プロダクトライン管理などについてある程度見てからの方が分かりやすそうです。基礎的な概念の定義部(EAST-ADL2仕様書の元になっているような論文に載ってます)は論理記号の嵐だったりするので結構骨が折れます。個人的にはContext-Oriented Design Analysis(CODA)を補完的にでも使えないものかなどと考えています(詳しい人にお伺いできれば)。

 

成果物管理

モデルを記述した成果物の管理も設計を支えるインフラとして整備する必要があります。当然先行する動きも多いわけですが、この成果物管理、BigTableやAzureとの相性ってどうなんでしょうか? これも詳しい人にお伺いしてみたいものです。

 

以上、オルタナティブ・ブログ復帰の御挨拶に代えて、最近の課題に関するメモでした。

「新ネットワーク思考(アルバート=ラズロ・バラバシ著 NHK出版2002年)」では、スケールフリー・ネットワークは、ベキ法則に従うネットワークと説明されています。これに対比されるネットワークが、ランダム・ネットワーク。
スケールフリー・ネットワークでは、ロングテール・モデルでよく使われている滑らかに移行するグラフをイメージしてOKのはず。これに対して、ランダム・ネットワークのものは、釣鐘状の形状をしている(らしい)。
さて、SNSのミクシィから約500例を引っ張り出して、とりあえずプロットしたものが下図。
Fig060911_mixi.pptをダウンロード

なんとなく、それっぽい感じになっています。
データの処理とか、サンプル数とか、グラフそのものの作り方などの点で、本格的な議論に耐えるものではありませんが。ベキ法則の影が見え隠れしているように見えます。
もしそうだとして、このことから何が言えるのか? 　それは、これから手をつけたいと思っています。