********************** セッションS1-d 分科会 テーマ:MDD・DSL・DSMの道具たち コーディネーター:佐藤洋介(デンソー)・江口亨 (富士通コンピュータテクノロジーズ)・土樋祐希(富士ゼロックス) 日時:2012/08/30 21:15〜22:45 参加人数:40名(終了時) ********************** ******セッションの雰囲気****** ・3人の講師が順にスライドを用いて発表を行っていた ・セッション会場にはお酒やおつまみが準備され、参加者それぞれがざっくばらんに話し合っていた ・参加者は随時自由に質問し、ほかの参加者や講師とともに白熱した議論を行っていた ・終始雑談や談笑が聞こえ、アットホームな雰囲気での議論となった ****************************** ******コンテンツ****** ライトニングトークス(AUTOSAR開発環境としてもEclipse活用) ・自動車業界でどのようにモデル駆動開発を実現するのか ・MetaEditについて ・自動車業界におけるDSMの活用 ・現場に使いやすいDSM環境 ********************** ******セッション開催の背景****** ・本セッションは、もともと「実践!DSMを用いた組込み開発」を行う予定であったが、 担当である杉本明加さん(富士設備工業株式会社)が参加できなくなってしまったため、その代理として開催された。 ・翌日のセッションで行う「現実的なモデル駆動開発」や「低価格・短納期開発を実現する筋肉質開発体制を考える」 の前置きという名目で行われた。 ******************************** ******セッションの内容****** - 今の車の業界の動向 - ソフトウエアの大規模化 - 現在、ボードに乗っているマイコンの数 - 100個くらい - ネットワークで言うと4種類くらい(CAN・Ethenetなど) - AUTOSARの誕生の背景 - 競争領域ではないところは一緒につくろう!という声がでてくる - 当時(10年ほど前)はマイクロソフトが全盛期 - 車業界も支配されるのでは? - オープンでスタンダードなソフトウエアを作りたい - 今の現状 - OSなどは共通化できてきた - これからのトレンド - 基盤からシステムへ(抽象度の向上) - ATESSTについて - 自動車向けの言語定義 - 多くのベンダが仕様策定段階から参入 - AUTOSARとは違い、タイミング記述について補完するプロジェクトも存在 - DAIMLERの例 - 上をSimulink、下をAUTOSARで書く - AUTOSARというベンダの動向 - 欧州系が牛耳っている - もうけの半分以上を欧州に取られる - 日本としては黙っていられない - JASPA「日本のツールを仕切り直しをしよう!」 - 欧州に対して反撃の狼煙を上げる。。。 - 日本としてやっていかないといけないことはなんなのか? - 今までソフトウエア工学と制御工学が離れすぎていると思う - EUのMARTEUMLなどはよくまとめていると思う - 欧州にちょっと元気がないため、日本で頑張りたい - 欧州でBMWくらいしか元気がない - 今こそ日本が立ち上がる時では? - 日本は今まで「英語ができる一部の人に牛耳られていた」のが現状 - 2005年以前のUMLの仕様で日本は止まっている - 組込みのシステムのドメインに対する仕様は欧州・欧米はそのあいだも進んでいる -北米,フランスとドイツ,スウェーデンの違い - 北米,フランスは飛行機の方が強い(UMLMARTEに強い)。対してドイツ,スウェーデンは車が強い(AUTOSARに強い) - 2001年:UMLのバージョンアップにより、メタランゲージが入る - 2002〜2003年:オメガUMLなど、「なんとかUML」が乱立(各システム開発で使いたいツールチェーンが異なる) - 結局使いたい部分が違って不便 - リアルタイム処理に関する部分をどうやって言語化するか? - MARTEの誕生へ - 時間制約の追加・ソフトウエア,ハードウエア資源の追加が可能になった - 結構地味な変更 - 翻訳しようとした人が意味がわかっていなかったため、日本では発展しなかった。 - 実際にもMARTEについての本はない。欧米ではぼちぼち - 検証ツールとかが盛り上がってくればあるいは。。。 - このため欧米よりも遅れてしまったのは事実 - 日本で仕様を正確に理解できる人がいない - OMGが発行するメタモデルの仕様を読んでる人いないよね? - 現在、着々と統合化を行っているが。。。 - 自由度が高すぎる - 自分の組織に適応したものを作るのが難しい - UMLで指定されていない部分をどうするか? - そこで座礁することが多い - 結局欧米の高いソフトウエアを購入しないといけないことになる - 日本でも昔からMDDに取り組んでいるところはある。 - 富士ゼロックスなど - 近年、発展途上国との価格競争が激しい - 機能が同じなら値段の安い方に傾くのは当たり前 - 作る製品も重要だが、作り方に価値を見出す - その価値を伸ばしていければ、人件費で勝負しなくても良くなるのでは? - ツールの値段がめちゃくちゃ高いのは現在の自動車産業だけ! - 「日本産でもいいから、ちょうどいい頃合のツールってのは、どの程度のことができればいいのかなぁ。。。」というようなものを決めたい - 自動車業界はお金がまだあるし、元気がある - 業界全体として「こういったものが欲しい」というのがあるのでは? - 日本政府はそういったことに対して金を出さない(指導していかない) - 国に対しても何かしらの働きかけがいるかもしれない - 法律がなければ何も縛れない! - 海外は国の資金が結構出る - 本当に力がある人が開発をして、それを業界で共有すればいいのではないか? - 大学をうまく活用するという発想が必要 - 大学の先生は使えないと思っている民間は多いが、ほかの企業との橋渡しの役割をしてくれる可能性はある - MDDについて - 志向型:モデルを書く→思考→コード - 推敲型:モデル化とコード化を繰り返してコードを生成する - 翻訳型のMDDとは? - 同じモデルからモデルコンパイラを通して、いろいろなターゲットに出すことができるMDD - 翻訳型MDDの特徴 - 抽象度の高いMDDを作ることができる - モデルからコードの流れは一方向 - モデルとコードは乖離しない - モデル自体がセマンティックスを持っている - モデルのみで論理的な動作や検証が可能 - モデルコンパイラ - モデルからコードを生成してくれるコンパイラ - 抽象化の向上 - 抽象度を上げるために - 情報を選択し、不要な情報を捨てること - 抽象度を上げることで、複雑に見えていた事柄を単純化することが可能 - (例)航空写真と所謂地図。どちらが目的地につきやすい? - 航空写真では情報が多すぎる - いらない情報を落とすことが大事 - ソフトウエアが大規模化してきた - 抽象度をどこまで上げる? - コードレベルでは太刀打ちできない - それよりも抽象度を上げることで対抗しないといけない - bridgepointによる開発プロセス - ドメインモデルの構築 - 分析モデル作成→モデル動作確認→コード生成→実機での確認 - 動作確認で異常な値が出たら、デバッガで一旦トレスし、あたりをつけて分析モデルまで戻る - アーキテクチャの構築 - 実装プラットフォームを構築→変換方法設計・変換コードの実装→変換ルール・ライブラリコードの確認 - 分析モデルの作成・修正 - クラス図→ステートチャート図→アクション記述という流れ - コード生成といいモデルを作るのは別問題 - インタフェースがどうこうという話ではない。 - 書いたモデルのように動くのが大事。それが外から見ていいかどうかは別問題。 - システムを作るときには、外界とのインターフェースがあるはず。そのインターフェースをどういうふうに切るかということ - 要はモデルを書けばコードが出るんだよっていうのが大事なんです! **************************** ******質問****** Q.MARTEはもともとどこから? A.フランスから来たらしいです Q.ゼロックスの人はモデルコンパイラを通して出てくるコードはかけるの? A.書けない Q.日本人は本質的に抽象化することが苦手な民族ではないのか? A.抽象化することは苦手だと思う。そういうことを考えられる人を育てないといけないと思う。 Q.MDDについて、抽象度の高いところだけを考えるだけではダメなのでは?実装コードをある程度具体的に考えられるひとがいいモデルを組めるのではないのか? A.それは違うと思う。ちゃんと考えられれば問題ないと思う。 Q.抽象度の高い考えを出来る出来ないは民族的な問題ではなく個人差では? A.あくまで比率の問題。人数的には欧米人の方が少ないような、、、 (議論が派生) - 本質的には変わらないと思うが、目的意識が少ない気がする。 - 言語の問題もあるのでは?結論までが長いため、全体が見えない。 - 抽象化能力はメタ言語の能力によることは間違いない。 Q.シミュレーションで確認はしたらOKで、実機において不具合が起きた時に現場は困るのでは? A.基本的にそれはテスト漏れの方が多いので、そちらをしっかりすれば大丈夫。 Q.モデルコンパイラの信頼性は? A.最初はやはり漏れがあったが、今はほとんどない Q.なぜこんなに普及してないの? A.Cコンパイラがあった時に、「それは信頼できない」と思うことがあるのと同じ。 - 最初は不具合が多かったため。その不具合を修正する間、待てない企業があるのでは? Q.モデルのテスト自体はモデルコンパイラに通さないの? A.今はやっていない。もしかしたらできるかもしれない。 Q.うちの会社はC言語でいま書いてるんだけど、ちょっとずつモデルコンパイラにシフトすることはできるの? A.できるための切り口をどのように作るのかが難しいかも。 - 今から新規参入する場合は楽だと思うが、現行のシステムから移行するとなるとちょっと苦労するかもしれない。 Q.クラスは大体ひとりあたり何個くらいまでなら持てるのか? A.一般的な話で言うと、エキスパートで50個くらい ************まとめ************ - 翌日のテーマの前置きという位置づけで行ったセッションであったが、 現在の自動車業界が抱える問題や翻訳型MDDについてとても白熱した議論が展開された。 - 受講者からも積極的に発言があり、有意義な意見交換ができたと考えている。 ******************************