何やら「モデルベース開発」がいいらしい、という話はあちこちで耳にします。これは、UMLによるモデルでも、Simulinkモデルでも同じです。

UMLモデルが嬉しいのは、システムの中身を理解しやすくなるからです。システムの「構造」をモデルで表す事で、システムの中身を理解しやすくします。UMLモデルを見る事で、このシステムって要するに何なの？という事が分かります。

一方、Simulinkモデルによる嬉しさは全然別の所にあります。一言でいうと、それは「動く」から嬉しいのです。

オーケー。「モデルベース開発」というものはいいらしい。特に制御系なら、Simulinkモデルを使うのがいいらしい。じゃあ早速、ツールベンダーのいいなりになってツールを買いあさり、モデルベース開発を導入したらいいのか？というと、必ずしもそれが正しいとは限りません。

そこで今回は、Simulinkによるモデルベース開発の何が嬉しいのか？何が嬉しくないのか？をご説明します。

嬉しい点、嬉しくない点を理解することで、「モデルベース開発を導入するべきなのか？」あるいは「モデルベース開発を導入する際に、何から手を付けたらいいだろう？」といったことを考えるときに、多少なりとも判断材料になるのではないかと思います。

静的側面、動的側面

まずは、開発において行われている事を、ものすごく抽象化してとらえてみます。そうすることで、モデルベース開発における「モデル」の役割が見えてきます。

開発というのは、「何を作るのか？」をどんどん明確化していくプロセス、とも言えます。「○○がしたいなぁ（要求）」→「○○という機能を作ろう（仕様）」→「○○モジュールを作ろう（設計）」→「○○関数を実装しよう（実装）」という段階で、徐々に明確化を行います。ここにでている「→」の部分が、「What？ → How？」の変換に当たります。○○がしたい。そのためには○○を作る。そのためには・・・という形で、どんどんと具体的なレベルに落とし込んでいきます。

この明確化のプロセスの中でいくつもの「ドキュメント」を作る事になります。そうすることで、「何を作るのか？」を表します。この「何を作るのか？」には、動的な側面と、静的な側面とがあります。

従来のプロセスでは、動的な側面も、静的な側面も、すべてドキュメントで記述します。日本語で書けばいいので、比較的楽に書けます。ただし、日本語で説明されると、いろいろな捉え方が出来てしまいます。そのせいで、誤解なく理解するのが難しくなってしまいます。

たとえば、「ボタンが押されたら、０．５秒ごとに設定値を１ずつ増やす」という仕様を書いたとします。

ところでこの仕様は、「０．５秒おきに、設定値がポンと上昇するのでしょうか？（赤線）」それとも、「もっと細かくじわじわと上昇し、そのペースが０．５秒に設定値１、という意味なのでしょうか？（緑線）」。日本語だけでは読み取れませんので、上図のような補助資料が必要です。補助資料さえあれば誤解の余地は少なくなります。しかし、日本語による記述しかなければ、どういう意味なのか？考えてしまいます。

「こんな風に動いてほしい」という事を示すためには「動かないもの」である「ドキュメント」だけでは限界があります。「動くもの」である「プロトタイプ」を作れば、こういった曖昧さは随分と減ります。プロトタイプがあれば、誤解なく理解するのは比較的容易です。その代わり、要するにプログラミングをしないといけないわけですから、書くのは大変です。要するにプロトタイプとは、「動かしてみないと良く分からないから、ちょっとだけ動かしてみよう」というものです。

「ボタンが押されたら、０．５秒ごとに設定値を１ずつ増やす」ようなプロトタイプがあれば、、「０．５秒おきに、設定値がポンと上昇する」のか「もっと細かくじわじわと上昇し、そのペースが０．５秒に設定値１という意味なのか」が、プロトタイプを動かすだけで分かります。誤解の余地はありません。この時、Simulinkモデルを使うと簡単にプロトタイプが出来る上に、色々と便利ですよ、というのがモデルベース開発です。

こんな感じで、プロトタイプがあると、かなり曖昧性が減ります。しかし、いちいちこんなプロトタイプを作るのも手間がかかります。ですから従来プロセスでは、「動くもの」はつくらずに「動かないもの」であるドキュメントだけを書いて済ませています。

余談ですが、「動かないもの」の曖昧性を徹底的に排除したものを作ろう、という動きもあります。これは仕様記述言語と呼ばれるもので、仕様を論理式であらわそうという物です。仕様を論理式であらわすと、コンピュータが仕様を理解できます。すると、コンピュータお得意の「力技による総当たり検証」によって、作ったソフトウェアが仕様に合致しているかどうかを確かめる事ができます。

（モデルベースの世界でも、こういったことをしてくれるツールがあります。これはこれで有効だと思うのですが、モデルベースというのは時間要素が入ってくるものですから、「総当たり」のためのパターンが爆発してしまいます。それってツールとして、どうなのかなぁ？というのが個人的な感想です。地球シミュレータみたいなスパコンを自由に使わせてもらえるのであれば、アリだと思うんですけどね。）

プロトタイプとモデルベース

これまで「プロトタイプ」と呼んでいたものを、もうすこし具体的に見てみます。そうすることで、上記の説明と「モデルベース開発」に何の関係があるのかが、もうすこし見えてきます。

システム設計であれば、ラピッドプロトタイピングを行います。たとえば、エンジンの制御方法を検討する場合について考えてみます。頭の中だけで考えていても仕方ありません。そこで、リアルタイム動作するハードウェア（ECUなど）を用意して、実際に動かしてみます。

実機につなぐ事で、考えている制御アルゴリズムが有効である事がわかります。前章では「あいまいさの排除」をメインとして「動くもの」をご紹介しました。しかしこの場合では、「仕様の妥当性を検討」するためのツールとして「動くもの」を使用します。

機能設計であれば、純粋にPC上だけで動くソフトウェアを使います。「こんなものを作りたい」というイメージをつかむために、実際にPC上で動作するものを作ります。そうすることで、「あいまいさの排除」が出来ます。また、本当にいい感じ（？）に動くかどうかを確かめるという「仕様の妥当性の検討」にも使えます。

＜宣伝／＞OpenPLATEのユーザー様は、上記のような使い方で、機能モデルの検討をされています。＜／宣伝＞

さて、上の例２つ、どちらの場合にも、とにかく「動くもの」が必要です。選択肢としては、C言語で書くか、Simulinkで書くか、といったところです。

C言語で書いた場合とSimulinkで書いた場合、どちらが嬉しいのでしょうか？

• Simulinkモデルで書く場合
  • ブロック線図というグラフィカルなものでアルゴリズムを書けます。そのため、データフローがとても分かりやすいものになります。
  • ブロック線図に微分方程式を書くと、数値的に解いてくれます。微分方程式が書けると、「制御アルゴリズム」だけでなく、「制御対象の挙動（プラントモデル）」も記述できます。
• C言語で書く場合
  • C言語が分かるエンジニアの数が多いです。
  • コンパイル時のメモリ効率等が、Simulinkから自動コード生成した場合とくらべ、２～３割有利です。

こんな感じで、演算リソースがふんだんにあるのであれば、Simulinkモデルで書いた方が断然有利です。ですから、もしも工程のなかで「動くもの」を作ると決めたのであれば、モデルベース開発するのがお勧めです。どうせ「動くもの」を作るのであれば、C言語で書くよりもSimulinkモデルで書いた方が素早く分かりやすいものが出来るからです。

モデルベースの使いどころ

これまで「動くもの」を作ると、いろいろと嬉しいという話をしました。では、モデルベース開発を始めようと思った時に、どの工程に適用したらいいのでしょうか。全部でしょうか？それとも一部の工程でしょうか？

システム設計であれば、エンジンなどの物理現象が相手です。ですから、頭の中だけで考えていると失敗します。かならず「動くもの」が必要です。どうせ「動くもの」を作るのであれば、ラピッドプロトタイピング用のシステムを導入して、モデルベース開発を行うのが良いと思います。（なお、システム設計といえども「動くもの」を作らずにこれまでやってきたのであれば、この限りではありません）

ECUの実装完了後に「試験」をするのであれば、ECUが相手です。このECUが思い通りに動くのか？を確かめるわけですから、やっぱり「動くもの」が必須です。HILS用のシステムを導入して、モデルベース開発を行うのも手です。

（ただし最近は、HILS導入はオーバースペックじゃないのか？もうちょっと単純なデバッガでもいいんじゃないか？という話もあります。以前の記事でご紹介した「低価格HILSへの流れ」というのは、こういう「もっと単純なものでも良くないか？」というところが原因です。）

一方、機能設計や詳細設計では、これまでドキュメントだけでやってきました。「動くもの」を作らなくても、なんとかなっています。従来プロセスでは、机上の検証しかしないで後工程に流します。その結果、実装段階や試験段階など、後工程で設計不具合が発覚して手戻りが起きたりしています。しかし、それで開発が破綻しているわけではなく、なんとか頑張ってECUを仕上げています。

（なにより、日本には良いサプライヤーが多数あります。良いサプライヤーは、いいかげんに仕様を書いて渡しても、不具合の起きない良い部品を納入してくれます。「車ってだいたいこんな物だから」という所で空気を読んでくれるわけです。だったら、それでいいじゃないか？という気になってくるのもうなづけます。どうせ「細かい詰め」というのはどこかで行わなくてはいけません。じゃあそれを、OEM側でやるのと、サプライヤー側でやるのと、どっちが安く済むのか？という話になるわけです。どこまで技術をコントロールしたいのか？という部分と、どこまで安さを追求したいのか？という部分の綱引きで、どこまで真面目に仕様書を書くのかが決まってくるのではないでしょうか。）

この分野では、少なくとも日本では、モデルベース開発はあまり進んでいません。（欧州では、このレベルの設計にもモデルベース開発が盛んにおこなわれています。それが良いことなのかと聞かれると、個人的には「そうでもないかも？」と思っています。いずれその理由をお話しする機会があるかも分かりません）

機能設計や詳細設計、実装などの工程にモデルベース開発を導入した場合、従来プロセスでは行われなかった「動くもの」づくりの工数が余計にかかってしまいます。「動くもの」づくりによって設計品質が向上し、結果として手戻りが減る事が期待されていますが、「余計な工数」と「減少できる手戻り」を比べてどっちが重いか？と聞かれると結構疑問です。

やはり「いままではやって来なかった、まったく新しい作業が必要」というところが大変なネックになってしまいます。トータルで見ると、設計段階の余計な手間が、後工程の作業を軽減してくれて、全体では楽になる、という可能性もありますが、そうではない可能性もあります。

いずれにせよ、まったく新しい作業が必要なものを、むりやり現場に導入しようとしても反発を受けるだけです。もっとスムーズな導入を考える必要があるでしょう。（実は、そのためのツールを現在開発中です。いきなり新しい作業をさせるのではなく、まずは既存の作業を楽にするようなツールにするつもりです。そこからなし崩し的に、「動くもの」づくりをしてもらうようなトリックを考えています。来年の頭くらいには公表できるかと思います。）

そもそも、どうしても「動くもの」づくりをしないといけないわけではありません。私は、仕様書を書く時に「ここは誤解がありそうだな」と思った場所には、かならず１つ２つ具体例を書くようにしています。「ボタンが押されたら、０．５秒ごとに設定値を１ずつ増やす」というような仕様でも、ついでに上図のようなちょっとしたグラフを書いておくだけで、誤解の余地は随分と減ります。

このように、既存のドキュメントの品質を上げて行くような工夫をするだけでも、随分と品質に寄与するはずです。「動くもの」づくりに走るのは、そういった工夫をやりつくしてしまった後でも良いのではないかと思っています。設計品質をある程度以上のところまで上げようとすると、図や表や波形などの補助資料が、たくさんたくさん必要になってきます。補助資料がどんどんと増えて行くと、ある時点で「これ、プロトタイプ作った方が速くないか？」という話になるはずです。そのあたりがモデルベース開発の導入ポイントでしょうか。

まとめ

• 従来プロセスにおいても「動くもの」を扱っている工程では、モデルベース開発の導入による恩恵が受けられることが期待されます
• 「動くもの」を作らなくても済んでいる工程では、モデルベース開発を導入しても、余計なオーバーヘッドがかかるだけ、という可能性も十分にあります。他に出来る事があれば、それを先にやった方が良いでしょう。

次回は

次回から、HILSのスピードに関するお話をします。HILSにはやはりスピードが重要です。ですから、スピードアップのために色々な工夫がなされています。次回から何度かに分けて、HILSで行われているスピードアップ手法についてご説明します。