自動車業界では、MATLAB/Simulinkをベースとしたモデルベース開発が有望視されています。言うと、適用方法によってはそれなりに工数削減や品質向上が出来ると言う事が実証されてきたからです。一方ではモデルベース開発によって逆に工数が増加してしまうケースもあり、まだまだ課題が山積みです。これは、ユーザー様にとっては課題が山積みと言えますが、私にとっては仕事のネタが山積みとも言えます。このブログでは、そういったモデルベース開発に関わっていく中で思った事について書いていきます。更新日は月曜日+気が向いた日です。Coderとは、MATLABのm-fileからCコードを生成してくれるツールです。なーんだ、それだけかとも思うのですが、意外と大きな変化への第一歩なのかも分かりません。Development)という分野が出来るかも?なんて思ったりしてます。(まぁ、今は単なる言葉遊びですけどね)MBD(モデルベース開発)という言葉には色々含まれますが、やはり制御ロジックをSimulinkモデルで書くのが1つのキーになっている気がします。そのメリットは、ロジックを自然言語で表現するより曖昧さがなく、そしてCで書いたりするよりも簡単に書けるところにある気がします。Cというのは「とりあえず書ける」レベルにはすぐいけますが、「品質の良いコードを書ける」レベルに行くのは結構ホネが折れます。それくらいなら、Simulinkモデルの作り方を習得したほうが遥かに早かったりします。モデルベース開発のメリットこれのアナロジーでいくと、M-fileベース開発だって成り立ちそうです。M-Fileベース開発のメリットもちろん、「モデルベース開発」と「M-Fileベース開発」のどっちを選ぶ?と聞かれたら、まずモデルベース開発を選ぶと思います。「CやSimulinkは分からないけど、m-fileなら分かる」「既に、m-fileで作った資産がいっぱいある」という場合であれば、M-Fileベース開発というのもアリだと思います。Coderの概要についてさっくりまとめてみます。Coderは、m-fileを入力にもち、そこから「mex」「C++ライブラリ」「C++実行形式」のいずれかを生成します。ライブラリ、EXEのいずれかを生成するその出力イメージは、たとえばMEX関数を選択したのであれば、次のようにラッパー部分+アルゴリズム部分に分かれて生成されます。(そもそもMEX関数って何?という方へ。来週か再来週あたりに詳しくご説明します)アルゴリズム+ラッパーC/C++ライブラリとしての出力であれば、基本的にアルゴリズム部分だけの生成となります。.libファイルまで生成してくれます。・MATLABが無くても動く・組み込みシステム上でも動く・M-Fileより高速に動くというメリットがあります。・MATLABの無いシステムでもアルゴリズム検証できるようにする・M-Fileで書いたアルゴリズムをハードウェアに載せて、動かしてみる・M-Fileで書いたアルゴリズムをMEX化して、高速に動作させてみる・M-Fileで書いたアルゴリズムを、S-FunctionとしてSimulinkモデルに埋め込んでみるといった事が出来るようになります。これまで、上記の事を行うにはCコードを書かないといけませんでしたが、これからはM-Fileを書くだけでよくなります。(もしくは、既存のM-Fileをそのまま流用できる。)そのため、「Mなら分かるんだけど、Cとかはちょっと・・・」というエンジニアの方が、手持ちのM-FileをそのままCコードに変換して外注さんに渡し、ハードウェア実装してもらう、という事ができるようになります。すると、アルゴリズムの研究に集中できますので、かなりラクが出来る事でしょう。制限事項さすがに、どんなM-Fileでも全自動でCコードに出来るわけではありません。Coder向けのものには次のようなものがあります。Coder向けエラーメッセージリストセル配列が使えなかったり、Try/Catchが使えなかったり、クラスが使えなかったりと、それなりに厳しい条件が並んでいます。MATLABが用意している各種関数のうち、コード生成しても使えるものとそうでないものがあります。APIが使えるわけではありません。XXX」に載っています。ここに載っていないものは、自力でなんとかするか、諦めるかしないといけません。(ただし、MEX関数を生成するときだけは例外です。来週か再来週にご紹介する予定です)(余談)ISO26262C言語は強い型付けの言語です。値を代入しようとするとコンパイルエラーになります。int型の変数にdoubleの値を入れようとした場合でも、警告を出してくれるコンパイラが殆どです。M-Fileはそうではありません。変数は、代入されるたびに型が変わり得ます。いうのは、弱い型付けといいます。26262を見てみますと、こんな感じの記述があります。A(Dが1番キツく、Aが1番ユルい)にすら適合しません。運用でなんとか強い型付けを実現するか、さもなくばM-Fileの言語規格を変えないといけません。マスワークスさん?コードアナライザーで、型付き宣言でない変数の使用を検出できればカンペキかと!まとめ遊び半分でM-Fileベース開発なんて言葉を作りましたが、今の段階でこれはアリか?と聞かれると・・・ナシかな・・・なんて思います。やるならモデルベース開発でしょう。MATLABという形で実現されて来ました。Coderという独立したプロダクトにもってきたのは、いよいよマスワークスさんも本気を出して来たのかなと思います。この技術がより洗練され進化してくれば、Cで書くより、Simulinkで書くより、M-Fileで書くほうがよっぽど効率が良い!という分野が出てくる可能性があります。(自動車業界でよくあるデータフローであればSimulinkの方が良いでしょう。M-Fileが活躍するのは、もそっと手続き寄り&解析的な分野になるかと思います。CoderおよびM-Fileの今後の進化は、個人的に要チェックだと思っています。17:59型付けの強い弱いは厳密に定義されていない用語ですが、現代的な言語設計の水準ではC言語は弱い型付けだというのが広く認識されるところではないでしょうか。void*型や制限の緩いキャストなどなど型システムからの抜け穴がたくさんありますからね。強い型付けの言語としては、MLやHaskellなどが挙げられることが多いと思います。このあたりの言語からするとC言語は相当危なっかしいのですが、安全規格的にどうなんでしょうかねえ。20:42コメントありがとうございます。ふむふむ、てっきりC言語は強い型付けと思っていましたが、おっしゃるとおり抜け道は沢山ありますね。ISO26262の記述では、言語自体が強い型付けを強制していなくても、何らかの方法で強い型付けが実現できていればいいように見えます。ECUのアプリ部分をC言語以外で書くというのは自動車業界的にありえない話なので、C言語が大前提で何とかしないといけません。今でも、ポインタの使用に強い制限をかけたり、キャスト時に範囲チェックかけたりという事は、たぶんどのメーカーでもやっているように思うのですが、これをたとえば「静的Cコード解析によって強い型付けからの逸脱を許さない、という検査を実施しています。大丈夫ですよね?」というように、プロセスの面から品質保証するしかないと思います。(あくまで個人的な予想です。実際のところ、どうしようとしているのかは知りません)そもそも、何を防ぎたいがために「強い型付け」をISO26262に盛り込んだのかが明記されていないので、どこまでやればいいのかも良くわかりません。規格策定時に参考とした、失敗モード集があると思うんですけどね。いうのをイチイチ明記しちゃったら、欧州のコンサル会社がステキな料金ふっかけられなくなっちゃうんでしょう。(本音:うらやましいなー。コメントを投稿して頂くには、JavascriptとCookieを有効にしていただく必要がございます。