詳細設計工程
次に詳細設計工程を進めます。
詳細設計工程では、基本設計工程で検討した各サブシステムの作り込みと検証を行います。
① 各サブシステムの中身の作成
② 制御モデルの検証(モデリングガイドラインチェック、設計エラー検証、動的解析)
③ MILSによるシステム検証
※具体的なタスクは各社様々だと思いますのでご参考まで。
① 各サブシステムの中身の作成
各サブシステムの中身を作り込んでいきます。
①-1 状態管理機能(サブシステム名:StateManagement)
ChatteringProcessサブシステムではチャタリングの処理を行っています。
OnEdgeサブシステムではオンエッジ検出を行っています。
①-2 LED制御機能(サブシステム名:LED)
①-3 異常検知機能(サブシステム名:ErrDetection)
①-4 モーター制御機能(サブシステム名:MotorControl)
②制御モデルの検証(モデリングガイドラインチェック、設計エラー検証、動的解析)
次に作成したモデルの検証を行います。
②-1 モデリングガイドラインチェック
概要: 作成した制御モデルがモデリングガイドラインに準拠しているかどうかを検証します。モデリングガイドラインとはモデルを作成する際に守るべきルール一覧のことで、ルールを守ってモデルを作成することで可読性の向上やコード生成効率の向上などの効果があります。チームで分担して制御モデルを作成する場合でも、全員のモデル品質を合わせることができます。
採用するルールに正解はなく、各社独自のルールや各団体(例 JMAAB)が提唱するルールなどから必要なものを取捨選択します。
モデリングガイドラインチェック方法
デフォルトで用意されているチェッカー、または自作のスクリプト、またはSimulink Checkツールボックスを用意することによりモデリングガイドラインに準拠しているかどうかを自動判定することができます。目視による確認もできますが、工数がかかる割にミスや漏れの温床なので、なるべく自動チェック可能な環境を整えるべきだと思います。今回はデフォルトで使用可能なチェックのみを実施します。
手順1 チェッカー(モデルアドバイザー)の起動
モデル化タブを開き、左上のモデルアドバイザーをクリックしてモデルアドバイザーを起動します。
手順2 モデリングガイドラインチェック対象の選択
モデリングガイドラインチェックを行う階層(どのサブシステムをチェックするかどうか)を選択します。モデルの規模が大きい場合は一度にチェックを行うと時間がかかったり、Simulinkがクラッシュしてしまったりするのである程度の規模で分割してチェックを行います。今回は規模が小さいモデルなので、モデル全体をチェックします。
手順3 対象ルールの選択
どのルールを採用するかどうか選択します。今回はデフォルトで入っているSimulink機能に関するルールをチェックします。チェックしたい項目のチェックボックスにチェック入れた後、選択したチェックを実行ボタンを押すと自動チェックが始まります。チェックが完了するとチェック結果が格納されたレポートが生成されます。すべてパスするようにモデルの修正を繰り返します。最終的なレポートはエビデンス(証拠)として保存しておきましょう。
②-2 設計エラー検証
次に設計エラー検証を行います(Simulink Design Verifierツールボックスが必要)。設計エラー検証とは、制御モデルに構造的な問題が無いかどうかを確認する工程です。仕様通り(例: スイッチを押すと動き出す)に動くかどうかといった観点の検証ではないことがポイントです。具体的にはオーバーフローがないか。デッドロジックがないか。配列アクセスに違反がないか。ゼロ除算がないかを検証します。
設計エラー検証の手順を記載していきます。(バージョンによってインターフェースが変わります)
手順1 SimulinkのアプリタブからDesign Verifierを選択する
手順2 モードを設計エラー検出モードに設定
画面左上のモードから設計エラー検出を選択します。(Simulink Design Verifierは設計エラー検出だけでなく、自動でテストケースを作ったりプロパティ証明する機能も持っています。それらはまた別の機会に解説します。)
手順3 設計エラー検出内容の設定
エラー検出の設定をクリックし、設計エラー検出内容を選択します。今回はデッドロジック、範囲外配列アクセス、ゼロ除算、整数オーバーフローの4項目を選択します。選択内容はプロジェクト全体で統一するようにしましょう。
手順4 設計エラー検出の実行
設計エラーの検出ボタンをクリックして検出を実行します。検出が完了するとレポートが生成されるので、エビデンスとして保存しておきましょう。
②-3 動的解析
次に動的解析を行います。動的解析とは解析対処のサブシステムの入力信号と出力信号(期待値)の時系列情報(テストパターン)を用意し、実際にモデルをシミュレーションして期待通り(仕様通り)の動きをするかどうかを確認する工程です。シミュレーション時にはカバレッジ(モデル全体のうち何%の確認ができたのかどうか)を計測(Simulink Coverageツールボックスが必要)することにより解析の抜け漏れを防止します。Simulink Testツールボックスがあれば、解析を自動化することができます。
例としてStateManagement内のChatteringProcessサブシステムの動的解析例を記載します。
手順① テストパターンの作成
解析対象のテストパターンを用意します。テストパターンは下図のようにエクセルで作成します。
手順② 解析の実行
Simulink Testツールボックスの機能であるTestManager(テストを一元管理、自動実行できるツール)の設定を行い、解析を実行します(詳細手順は別ページで解析予定)。解析が完了すると下図のように解析結果やカバレッジの結果を確認することができます。今回の場合、作成したモデルが期待値通りの動きをしており、条件カバレッジと実行カバレッジが両方とも100%達成できていることがわかります。エビデンスとしてレポートを出力し、保存します。
以上で制御モデルの検証が完了です。
③MILSによるシステム検証
次にMILS(Model In the Simulation)を利用してシステム検証を行います。MILSの詳細はリンク先をご覧ください。MILSを一言でいうと制御モデルとプラント(実機)モデルを接続しての動作シミュレーションです。実機の代わりにモデルを使うので実機レスで試験可能です。
ライントレースロボットの場合、タイムを縮めるために走行→ログ取り出し→ログ解析→パラメータチューニングを何度も繰りかえす必要があり時間を要します。MILSであればそれらの工程をPC上で済ますことができます。制御ロジックの確認やパラメーターの当たりづけをMILSで行い、最後の調整を実機を用いて行うことにより大幅に工数を削減することができます。
また、大会に使われるコースはかなり大きく、そもそも試験スペースを確保することが困難な場合も多くぶっつけ本番になってしまうこともあると思います。MILSであれば試験スペースは自由に作成できるので、色々なコースパターンで制御ロジックが正しく動作するかどうか検証することができます。
手順① プラント(実機)モデルの作成
制御対象をモデル化します。いくつかのプラントモデリングツールを使ってきましたが、個人的にはSimscape推しです。(使いやすい、制御モデルと接続しやすい)。Simscape Multibodyツールボックスを使うと下図のように物理モデリングをすることができます。具体的な使用方法について後日まとめたいと思います。
手順② 動作確認
制御モデルとプランとモデルを接続し、動作確認を行います。要件定義で定義した仕様をすべて満たしていることを確認できたら詳細設計工程完了です。もし仕様と異なった動作をした場合はモデルを修正します。
MILSをしていると、「このパターンの検討が漏れていた！」、「なんか動作おかしくない？」などいろいろな発見があります。これこそがMILSの効果です。従来開発の場合、実機とECUを接続しての確認は最終工程である実機評価工程で行っていました。最終工程で不具合が出てしまった場合は大きな手戻り(※1)に繋がってしまい、プロジェクト日程に致命的な影響を与えてしまいます。MILSを活用することにより早期に動作確認を行えるので、大きな手戻りを防止して開発効率向上に繋がります。
※1 大きな手戻りの例
例① そもそもの要件を修正必要がある
→要件を修正するということは制御モデルの修正～検証をすべてやり直す必要があり工数がかかります。エンジニアの士気もかなり低下します。(せっかくここまで来たのにやり直しか。。。という心境)
例② 機械・機構を変更する必要がある
→実現したかった機能が現状の機械・機構では実現できないことが実機試験ではじめてわかる場合があります。機械設計をやり直す場合、数ヶ月単位で日程遅延が発生することがあります。(もっと長い場合も。。。)
以上で詳細設計工程は完了です。
コーディング工程に移ります。