はじめに

モデルベース開発(Model Based Developmentの頭文字をとって以下、MBDと略)は、航空宇宙分野や自動車業界で近年、急速に普及している製品開発手法です。
その名前の響きと適用産業分野(製品)から、なんだかとっても崇高でムズカシイものだと思ってしまうかも知れませんが、今回はプラレールの魔改造(速度コントロール)にMBDを取り入れてみて、電子工作を通してMBDのうま味について解説していきたいと思います。

実際の成果物

こんなものを作ってみました。

甥のプラレールを奪って魔改造を施す計画。まだまだ詰めの部分はあるけど、なんとかクリスマスに間に合いそう！
いやしかし、ムダにホンモノの電車っぽいコントローラ挙動にしてしまったから、小学生にはちと操作ムズいか・・・？ pic.twitter.com/yN2zZaEtXH

— わたなべ (@mana_544) December 15, 2019

5段階(力行2、力行1、惰行、ブレーキ1、ブレーキ2)の加減速度コントロールにより、速度(モータ印加電圧)を調整しています。
今回は、この速度コントロールプログラムをMBD(コントローラモデル)で作りました。

MBDとは？

MBDとは、マイコンを搭載した製品開発において、 実機で評価をする前に「モデル」を作ってシミュレーションで事前検討をする という、開発手法のことを言います。¹

これだけだとなんのこっちゃ？だと思いますので、もう少し詳しく説明します。
まず、マイコンを搭載した製品を構成する“要素”をブロックで表すと、ふつうはこんな感じになります。

そして、この構成で「モノを作ろう！」となったときに、作り方(開発方法)としては「実機(試作機)にマイコンを載せ、ソフトを書き込んで実際に動かして実験・評価する」というのが一般的ですが、このやり方にはいくつかの問題(宿命)があります。

【問題1】プログラムの動作確認をしたいだけなのに、回路(ハード)を用意しないといけない

これは当然といえば当然なのですが、プログラムのロジックがちゃんと意図した仕様通りになるかどうかを見たいときだけでも、わざわざブレッドボードにマイコンその他の周辺回路をぷすぷす挿さなければなりません(ソフトだけで動かせない)。実機を使ってのフィードバックコントロールだったらなおのことだけれど、そうではないシーケンス的な(オープンループ)プログラムであったとしても、実物にいちいち書き込まないとプログラム検証すらできないというのは地味にメンドい。

【問題2】何かエラーが起きた時の原因特定(デバッグ)がツラい

これはマイコンを使った電子工作をやられた方ならば誰しも経験があるかと思いますが、何かエラーが起きた時にマイコンプログラム(ソフトウェア)が悪いのか、あるは回路や部品(ハードウェア)が悪いのかを切り分けるのだけでも一苦労です。

【問題3】実機の試験はお金と危険が伴う

趣味の電子工作レベルだとあまりピンとこないかもしれませんが、パワーエレクトロニクス(重電)、自動車、飛行機、ロケットなど、ものすごく巨大なエネルギーを扱う製品の開発には、とても危険が伴います。また、試験機自体も大型になったり、使う燃料代もバカにはできなかったり、試験中いつ起こるかわからない危険な状態を回避するための施設(設備)を作ったりで、とにかく実機の試験はお金がめちゃくちゃかかるのです。

こんなかんじでつらつらと問題をあげてみましたが、これらの問題について 実機を動かす(作る)前に、“モデル”でシミュレーションして評価しようぜ！ というのが、基本的なMBDの発想になります。

MBDの「モデル」の種類

ここで、MBDで登場する「モデル」という概念には、大きく分けて以下2種類あります。

1. コントローラモデル
2. プラントモデル

「コントローラモデル」は、対象物を動かすコントローラ(マイコン)に書き込むプログラムそのものをモデルとして作ること。「プラントモデル」は、対象物そのものをモデルとして作ることを言います。

「コントローラモデル」「プラントモデル」両方とも作れば、さきほどの3つの問題にすべてアプローチできますが、実は「コントローラモデル」を作るだけでも問題1と問題2の一部(プログラムのどこが悪いのか)は十分に検証可能です。したがって、電子工作においては「コントローラモデル」だけ作るのでも十分なうま味が得られますので、今回は実際に「コントローラモデル」を作ってMBDのうま味について解説していきたいと思います。

プラントモデル編は・・・なんか良い題材が見つかったらやります。 ²

• 2020/02/03 追記
  プラントモデル編も書きました。併せてご覧下さい。
  電子工作にモデルベース開発(Model Based Development: MBD)を適用してみた【プラントモデル編】

プラレールのスピードコントロールシステム

こんな感じのシステムを考えました。

• マイコンはArduino(厳密にはArduino Pro Mini)
  • Inputはマスコンから送られてた電圧
  • Outputはモータードライバーへの制御電圧
• 無線モジュールはTWELITE をそのまま書き換えずに利用(なんて便利なんだ！)
• マスコンがわりのコントローラ
  • 5段階ロータリーSWで再現(力行2段階、惰行、減速2段階)
  • 分圧回路で電源電圧(3V)を5段階にして、無線モジュール経由でArduino(Analog Input)に投げる

ですので、作りたいプログラム(コントローラモデル)はこんな感じです。

• ロータリーSW電圧から加減速モード(Power2, Power1, Neutral, Brake1, Brake2)の決定
• 加減速モードに応じたモーター印加電圧(加減速度)の決定
• 停車からの加速は、静止摩擦に打ち勝つためにオフセット電圧＋インパルス的な補正電圧を与える

各信号は下記のような感じのイメージを想定しています。

このようにスピード(モーター印加電圧)を調整するようなプログラムをモデルで書いていきます。

モデル構築ツール

さて、コントローラモデルを書くツールですが、MBD業界ではもっぱらMATLAB/Simulinkがデファクトスタンダードです。というか、コントローラモデルにおいては事実上これ一択です。³
Webサイトを見てみても、個人を寄せ付けないビジネス向け商用ツール独特のオーラがみなぎっていて、さぞかし個人で買うには高いんでしょう？・・・とお思いの方、ご安心ください。 個人(趣味)用途のライセンスなら4回ぐらい飲み会をガマンすれば手が届く値段で買えます。⁴
電子工作でArduinoスケッチを書き込んで、実際に動かしてみたらうまく動かなくて、「う～ん、やっぱ●クトロニクスのロジアナがないとなぁ・・・」なんて言ってる人は、まずはMATLAB/Simulinkを買って机上シミュレーションすることを検討してみる価値はあると思います。

プログラムロジックをモデルとして構築していく

さっそく、Simulinkでスピードコントロールプログラム(モデル)を書いていきます。下記はプラレールコントロールモデルの全体図です。

C言語を始めとするテキストベースのプログラミング言語しかやったことのない人にとっては、Simulinkのようなビジュアルプログラミングはとっつきにくいかと思いますが、そこは、、、がんばってください(投げやり)。
ここでは、さらに「モーター印加電圧算出」ブロック内のロジック部分の例を示します。

こんな感じて、「if-else」的なロジカル要素をSimulinkブロックで描いていくのですが、Simulinkはいろいろなブロックがあるので、それこそいろんな書き方でロジックの表現ができてしまいます。
たとえば、“if-elseの条件構文”一つとっても、Simulinkだとこんな感じで複数パターンで表現できてしまいます。
これは表現にとっても柔軟性がある一方で、それが却ってモデル可読性を損なうことがありますので、自分の中で「こう書くんだ」というルール(ガイドライン)を定めるといいです。といっても、やっていかないとわからないと思いますので、やってみてください(投げやり)。⁵

シミュレーションをしてみる

モデル(プログラムロジック)を構築したら、MBD最大のうま味、シミュレーションをしてみましょう。
今回はプラントモデルを構築していないので、インプットとして「ロータリースイッチのポジション(電圧)」をソースブロック(SignalBuilder)で模擬して作り、「モーターへの指示印加電圧(スピード)」をScopeブロックで見てみることにします。⁶

おっけーい、発進補正がうまく動いたぜ！
最初に描いたイメージ図タイミングチャートと同じ挙動になることが確認できましたね！

このように、シミュレーションを回して検証確認して、ロジック(プログラム)のおかしな挙動はすぐさまモデルを修正できる これこそがMBDのうま味で、電子工作にも十分威力を発揮できます！

モデル→Arduinoスケッチ(プログラム)への変換とArduinoへの書き込み

シミュレーションで期待通りのプログラム挙動が確認できたら、このモデルをArduinoへ書き込みたいのですが、Simulink Support Package for Arduinoというアドオン(無料)を追加してインストール&初期設定していれば、ボタン一発で「モデルからArduinoスケッチへの変換 ⁷ 」「コンパイル&ビルド」「Arduinoへの転送」をやってくれます。⁸

モデルでシミュレーションしてプログラムの挙動はバッチリなので ⁹ 、これでマイコンに書き込んで動かなかったらハードが原因の可能性が高いということがすぐにわかって安心ですね！
このプラレールも案の定動かなくて、原因ははんだづけが甘くてGNDが浮いてたというオチもつけときます。

さいごに

MBDのうま味、伝わりましたでしょうか？
今回は “モデルベース開発” というちょっととっつきづらいモノに対して、電子工作に適用することでなんとかうま味を身近に感じて頂けるように記事を書きました。ですので、中身の技術的な部分(プラレール自体の改造内容)については、大幅カットしてしまいました。
プラレールに盛り込んだ機能としては、スピードコントロール以外にも

• モーター印加電圧値を無線で送り返して手元(コントローラ)の速度計に表示
• プラレール側のバッテリー電圧が低下したらLEDでお知らせする
• 特定のコマンド入力をすると、バックモードに入る(ハードを固めた後にバックのことを思いついてしまったので、SWなどのハードを追加せずにプログラムだけでなんとかした)

あたりを盛り込んでいますので、要望があればプラレール魔改造の内容についても書こうと思います。