1. はじめに
組込ソフト開発では、最終段階のシステムテスト実行時、ソフトを実機上で動かしてテストします。その時に、オシロスコープ、パルスジェネレータ、通信モニタなど、複数の機器を接続して、設計通りに動作するかを確認します。ただし、これらの機器は高価なものが多く、数が少ないことで、占有出来ないことが多いです。そのため、実機との接続を毎回行うことが必要になり、工数ロスが非常に大きいものとなっていました。また、この工数増大を抑えようとすることが原因で、気軽に動作確認が出来ないことから、システムテストで見つかる不具合が発生しやすくなります。そして、この段階で見つかる不具合というのは、後戻りが大きいことが大半であり、不具合修正も、本来修正したい内容とは違う小手先の修正をすることが多く、次代への負の遺産となり、品質ロスも大きいものとなっていきます。これは、設計段階で機能分割して、機能ごとに仮想環境を作成して検証するのも一つの解ですが、今回はシステムテストの自動化ということで、この辺りの話はパスします。
ところで、実機の接続先は、マイコン搭載の実機であることが多くないでしょうか。あるいは、実機の外部入力信号をマイコンで作成し、実機の外部出力信号をマイコンで取り込めることが多くないでしょうか。これは、つまり、オシロスコープ、パルスジェネレータ、通信モニタの代わりに、マイコンでテストベンチを作成出来るということです。そして、最近のマイコンボードは、USBやLANでPCと通信出来ることが多く、実機の外部入力信号をPCから制御することでマイコンボード上で作成したり、実機の外部出力信号をマイコンボードで取り込み、それをPCへ送信することも出来ます。さらに、うまくハード構成を考慮すれば、リモート操作の可能性も秘めています。ただし、リモート操作となると、火災などのリスク対策が必要となり、反対にコストが掛かることが予想されますが。。。
この記事に興味ある人は、組込開発者だと考えられるため、テストベンチの役割を果たすマイコンボードのソフトは自力で開発出来ること前提とします。そして、以降は、自動化の考え方と、主にPC側のソフト開発について説明します。
ちなみに、テストベンチの一部であるマイコンボード部分は、LabView、dSpaceなどでも作成可能です。ただ、非常に高額であることから、個人では手が出ませんので、今回は、マイコンボードを使用します。
2. 概略
テストベンチの全体像は、以下の通りです。
2-1. マイコンボード
使用するマイコンボード
http://akizukidenshi.com/catalog/g/gM-10094/
マイコンボードは、上記を使用しました。性能が高く、何より日本語の仕様書なのがポイントとなりました。
使用するマイコン機能
この記事では、以下のマイコンインターフェイスを使用しています。
- CAN（自分が車載開発者なので。。。）
- SPIマスター（拡張用に使用）
- LAN（PCとの通信用）
- AD変換（６チャネル、オシロの代わり）
- PWM（６チャネル、ファンクションジェネレータの代わり）
マイコンソフトの機能ブロック
全体像に記載の通り、マイコン側のソフトは、ドライバ（AD、PWM等）とユーザープログラムの構成となっています。システム検証環境に依存して、フレキシブルに変更したいこともあると考え、PC側でユーザープログラムを開発し、PCからマイコンボードへプログラムをアップロードする形としています。
2-2. マイコンボードとPCの接続
以降に、作成したサンプルを格納しましたが、試しに動かす場合の注意点としては、PCとGR Peachの接続はクロスケーブルを使用し、PCと直接LAN接続してください。これは、MACアドレスが適当な値のためです。また、マイコンボード側のIPアドレスは、192.168.0.100固定としています。PC側のIPアドレスは、192.168.0.*の固定としておいてください。
2-3. PC
使用する開発環境
VisualStudioをインストールしてください。自分は最新の2019を使用しました。
3. 自動化環境の作成方法
3-1. スクリプトを定義して、自動化する
自分は、組込開発のシステム検証環境をいくつか見てきました。
かなり悲惨な現場は、オシロスコープや、ファンクションジェネレータのパラメータを手動で設定し、システム検証を実行する手法を取っています。これの何が問題かというと、手動が入っているということです。例えば、不具合が発生したとしても、手動であれば再現が非常に困難となります。これが、もし、タイミングに依存した不具合であれば、不具合再現させるために試行回数が必要になることがあります。手動であれば、解析が進みづらく、最悪な場合、再現すら出来ないこともあり、手順ミスだとして不具合が無かったものとされてしまいます。それが本当の不具合であれば、そのまま商品が市場に出ると、後々大きな損害として返ることとなるでしょう。
先ほどより、だいぶマシな開発現場では、PCでツールを作成し、めんどくさい設定手順をPCで自動化していることが多いと感じます。しかし、それでも、GUI上のボタンを、順番に押すようになっていることが多く、タイミングが人依存となります。ここまでくれば、自動化はもう目前ですが、なぜか、そこで満足している現場が多いように見えます。
この記事で提案する案は、例えば、GUIのボタンを押す行為自体を、スクリプトで表現することです。そして、それらを組み合わせて、検証パタンとすることで、実行の自動化が可能となるのです。スクリプトを１から定義するのは、非常に困難ですが、C#のRoslynなるものがあり、それを使うと、簡単にスクリプトを定義することが可能となります。
https://qiita.com/siy1121/items/aee3ce1fff6e83e33b22
上記記事を参照しました。
ちなみに、１０年近く前から、このような思想を持っており、実際に検証環境を作成したことがありましたが、このときは、エクセルで管理しているスクリプトをVBAで加工し、さらにそれをPerlプログラムに掛けてc++言語を生成し、それをコンパイルしてからPCで実行する、という非常に厄介な検証環境を作成しました。複数言語の組み合わせで作ったことで、検証環境自体のデバッグも大変となり、たぶん、現在の自分も含め、誰も検証環境をケア出来ないでしょう。C#とRoslynを使えば、VisualStudioで開発できるため、検証環境作成が楽となり、さらに、デバッグもしやすいと思われます。
3-2. スクリプトのコマンド定義について
どのようにスクリプトのコマンドを定義すれば良いでしょうか。それは、イベントドリブン型のコマンド仕様にすれば、解決できます。
http://e-words.jp/w/%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%83%89%E3%83%AA%E3%83%96%E3%83%B3.html
イベントドリブンについては、上記を参照してください。
例えば、実機に入力するサイン波を、時間ごとに周波数を変更して入力する検証項目を仮定します。これをどのように表現すれば良いでしょうか。
// Boot状態をトリガーにして、周波数２０ヘルツを出力。
Set( Trig: "Boot", SineWave: new SineWave() { Freq = "20.0", Gain = "0.5" } );
// Boot状態をトリガーにして、２秒後にA1状態に遷移。
Wait( Trig: "Boot", Next: "A1", Time: 2.0 );
// A1状態をトリガーにして、周波数６０ヘルツを出力。
Set( Trig: "A1", SineWave: new SineWave() { Freq = "60.0", Gain = "0.5" } );
// A1状態をトリガーにして、２秒後にA2状態に遷移。
Wait( Trig: "A1", Next: "A2", Time: 2.0 );
// A2状態をトリガーにして、周波数４０ヘルツを出力。
Set( Trig: "A2", SineWave: new SineWave() { Freq = "40.0", Gain = "0.5" } );
// A2状態をトリガーにして、４秒後にEnd状態に遷移。
Wait( Trig: "A2", Next: "End", Time: 4.0 );
// Boot から End まで波形取得
GetWave( Trig: "Boot", Stop: "End", FileName: "test.wav", InId: "0, 1, 2, 3, 4, 5", OutId: "0");
このように表現すれば、うまく動作するように見えないでしょうか。あとは、これを解釈して実行するプログラムをPC上で作成すれば良いだけです。そして、Roslynを使用すれば、上記スクリプトはRoslynが実行してくれるので、以前より楽に検証環境を作成することが可能となりました。
3-3. サンプルソフトの実行
スクリプト実行がどれだけ便利か、そして、その先に、リモートで作業出来る可能性を秘めていることが、実際に動かしてみたら分かると思い、サンプルを用意しました。
https://github.com/EmVerif/EmVerifPC
https://github.com/EmVerif/EmVerifCtrl
上記に、Roslynを利用したプログラムを格納しました。Roslynを利用するにはWPFが必須です。しかし、自分がWPF初心者であるため、フォームで開発している部分もあります。不細工な構造となっていますが、ご了承ください。
コンパイルが成功し、実行すると、上記のようなウィンドウが立ち上がると思います。
そして、開始を押すと、上記のようなGUIが起動し、約８秒後に終了すると思います。
サンプルプログラムの説明は、長くなると思われるため、別の記事にします。
4. まとめ
- システム検証に必要な入出力信号や通信の大半は、マイコンボードで作成可能。
- スクリプトを導入すれば、マイコンボード、dSpace、LabViewと連携し、自動化が可能。
- Roslynを利用すれば、スクリプトの実装が簡単。
もちろん、自分も、全てのケースで自動化が出来るとは思っていません。しかし、上記環境を使用すれば、大半の項目が自動化可能だと考えており、どうしても無理な場合のみ、既存のオシロ、ファンクションジェネレータなどを利用すれば良いと思っています。こうすることで、工数削減や、将来は、組込開発でも、リモートワークが出来るようになれば、と考えています。