MBD 中部コンファレンス PMA2:MATLAB 開発 Simulink モデル開発における 工夫事例 2014 年 12 月 18 日オムロンオートモーティブエレクトロニクス株式会社開発統括室ボディコントロールシステム開発部町井紀善
はじめに Simulink の導入 開発手法 環境をそれぞれの事情 ( 会社 部署 個人 開発アイテム ビジネスモデル 等 ) に合せ込むことで効率化を実現します 設計検証成果物がモデル化されることで品質管理の面では改善が期待されます モデリング等の手間もあり作業は増加? 合せ込みの方法 MATLAB による環境構築 Simulink モデリングの工夫 市販ツールの活用 合せ込み ( 改善 工夫 ) 事例 1 事例 2 事例 3 事例 3 事例 4 1
事例 1: 回帰テスト環境 (1/4) 実現したい事 テスト工数削減のためにシミュレーションを自動実行させたい 1 つのモデルにテスト波形が多数 テスト対象モデルが多数 現在担当しているアイテム ( 多機能 ECU) 独自の事情 数が多いため 自動化による効果が大きい モデルカバレッジの記録 各ログデータの波形生成 各ログデータの過去との比較 期待値と出力値の比較 これら一般的な事柄も合せて実施したい テストテストシナリオテストシナリオデータシナリオデータデータ テスト対象モデル テストログ 2
事例 1: 回帰テスト環境 (2/4) 過去の環境 過去に 1 モデル多テストシナリオ の自動シミュレーション環境を構築済み 過去の環境を拡張して新仕様を実現できないか検討したが 環境構築にまとまった時間を確保できない ( 環境構築の専任者がいない ) Simulink の旧い機能を使っていて ツールで処理する機能範囲が広い 今後を考え 新規に環境を構築 項目 過去の環境 (R14SP3) 新環境 (R2007b+) 目的 1 モデル多テストシナリオ の自動シミュレーション 多モデル多テストシナリオ の自動シミュレーション 仕様 テストシナリオデータ書式 テスト信号生成 ロギング方法 CSV ファイル + 独自規格テキストファイル From Workspace ブロック Scope ブロックの保存機能 : : 3
事例 1: 回帰テスト環境 (3/4) 改善ポイント 段階的な導入や機能拡張が可能 管理が楽 項目 目的 ツール化プロセス ( 考え方 ) 仕様 ツールの構成 テストシナリオデータ書式 テスト信号生成 ロギング方法 : 過去の環境 (R14SP3) 1 モデル多テストシナリオ の自動シミュレーション 実現したい事 ( 要求仕様 ) ツール化 ( ツール仕様 ) 全体で 1 つのツールとして管理 (M ファイルは分割 ) CSV ファイル + 独自規格テキストファイル From Workspace ブロック Scope ブロックの保存機能 : 新環境現在の仕様 (R2007b+) 多モデル多テストシナリオ の自動シミュレーション 実現したい事 手作業手順化 ツール化 手作業に対応した機能毎に機能毎に独立した独立したツールとして管理 エクセルファイル Signal Builder ブロック 信号ロギング機能 : 独自ルールを削減 Simulink の新機能を採用 4
事例 1: 回帰テスト環境 (4/4) 実現方法 ツール G 複数モデル連続テスト エクセルから csv へシナリオをエクスポート (VBA マクロを外部起動 ) ツール B 実行 ツール D 実行 SLVV カバレッジ結果取得 ベースログとの差分比較 ( ツール E 実行 ) 疑似可変ステップ / フルステップ切替 事例 3 ツール Z プロット画面操作機能拡張 事例 2 csv 生成マクロ付属 テストシナリオ (Excel) テストモデル テストログ (logsout) ツール A ツール B csv から SIGB へシナリオ取込 ツール D ログ差分比較 ツール E ログをプロット ツール F ツール C シナリオ編集を支援する VBA マクロ集 ( 機械的作業を自動化 ) ツール W ( 外製 ) MATLAB データを SIGB ブロックへ取込 テストハーネスモデル自動生成 複数テストシナリオ連続実行 (1 シナリオのみのテストも可能 ) 自動ログ保存 SLVV カバレッジ計測 時系列 多 ch 波形プロット ツール X プロット画面ファイル選択 GUI ツール Y 5
事例 2: プロット画面の操作機能拡張 (1/3) 実現したい事 Simulink シミュレーションのロギング波形 波形の拡大縮小 スクロール操作を簡単に行いたい ボタンをクリックする操作が手間 デバッグ作業 ( 不具合要因の検討 ) に意識を集中したい MATLAB の機能 ズーム 移動 6
事例 2: プロット画面の操作機能拡張 (2/3) 実現方法 Figure 画面の操作機能を拡張する汎用ツールを作成 座標軸モード ( 従来の機能 ) ホイール操作でズーム 動作対象 座標軸 ウィンドウ 動作方向 XY 軸 X 軸のみ Y 軸のみ 2 3=6 種類の動作モード 任意の組合せで割り付け可 ドラッグ操作で移動 同時押し操作無し +[Shift] +[Alt] +[Ctrl] ウィンドウモード ( スマホ風の機能 ) オブジェクトの端点を認識して表示範囲を制限 ホイール操作でズーム ドラッグ操作で移動 7
事例 2: プロット画面の操作機能拡張 (3/3) 開発手法 仕様書 M コードのヘルプテキスト領域を仕様書とすることで 仕様書の管理をシンプルにしています コマンド API GUI ツールであってもコマンド API を設けます これにより ツールの用途が広がります テストテスト用スクリプトでツールの各機能を実行し プロファイラでカバレッジを確認します ( マウス等の操作が必要なケースは DOS コマンドで操作できるフリーソフトを使用 ) Figure ウィンドウ Figure 画面操作機能拡張ツール プロファイラカバレッジレポート テスト用スクリプト コマンドウィンドウ 8
事例 3: 広レンジのタイマ制御モデル (1/2) 背景 仕様の数値は架空のケースです 100ms~1 時間程度のタイマ制御を持つアプリケーション機能のモデル開発 タイマ閾値の最小分解能は 50ms ( シミュレーション時に連続系のプラントモデルは用いなくてよい ) 期待値波形 100ms 程度 1 時間程度 改善課題 普通にモデリング ( カウンタで時間を計測 ) すると ソルバの最大ステップを 50ms 以下にする必要があり 1 時間タイマの機能確認に 72000 以上のシミュレーションステップが必要となります シミュレーション実行時間と PC リソース負荷に対する影響が大きい 9
事例 3: 広レンジのタイマ制御モデル (2/2) 実現方法 モデリングの工夫によりシミュレーション負荷を削減 シミュレーションの仕方によって厳密なテスト ( 負荷大 ) も実施可 事例 1 の回帰テスト環境で 2 つのテストモードを選択可能 コントローラモデルのモデリング 時刻情報としてフリーランカウンタ信号を外部から入力 過去のフリーランカウンタ値との比較で経過時間を判定 同一モデル & テストシナリオに対し 両方のテストを実行可能 カウンタ信号 テストモードシミュレーション方法負荷用途 フルステップ 疑似可変ステップ コントローラモデル ソルバを 50ms 周期固定とし カウンタ信号を毎周期 +50ms ソルバは 1s 周期固定 ( ダミー設定 ) とし カウンタ信号を任意に定義 高 低 実機により近い動作実機に近い動作ととしてテストするとき デバッグなど作業時間重視のとき 期待値波形 100ms 程度 1 時間程度 10
事例 4: 要件管理ツール Reqtify との連携 (1/2) 実現したい事 Reqtify はダッソー システムズ製の要件管理ツールで Simulink モデルファイルに対応しています 要件管理ツール Reqtify を使って要求仕様をトレースする ( 諸事情によりツールが先に確定 ) 要求仕様書 Simulink モデル 要求トレースの管理単位は データフローレイヤ ( 処理 ) を有するサブシステム ID タイトル説明 R01 R02 R03 要求仕様 Simulink モデル 要求 ID はモデルレイヤ上に可視化された状態にする Reqtify のデフォルト設定では 説明プロパティや Doc ブロックなど レイヤ上に可視化されない箇所に要求 ID を記述するようになっており そのままではニーズを満たせない 11
事例 4: 要件管理ツール Reqtify との連携 (2/2) 実現方法 市販ツールを利用することで ツールを作成して環境を構築するよりも 簡単にやりたい事を実現 Simulink モデルファイル Reqtify の仕組み タイプ設定に基づき情報抽出 タイプ設定 節節 要件 参照 説明文 モデルの構成要素 ( サブシステム等 ) 節の 要件 (ID) 上位文書の 要件 ( トレース情報 ) 各種分析 レポート生成 データフローレイヤに配置 機能名 : 機能要求 ID:R01,R02 説明 : Model Info ブロック Model Info ブロックのテキストから情報を拾うように設定 要件 参照 説明文 モデルファイルの内部構造を知っていると設定が簡単 環境構築の知識が有効 要求仕様書へリンク ( トレーサビリティ管理 ) Excel 一覧表を生成 ( モデル機能一覧として利用 ) 12
まとめ 改善には様々なパターンがあります それぞれの特徴を考慮して改善を継続する事がポイントと考えています 効果 実現したい事 改善 個別の事情 効果を確認して次を計画 年月とともに状況が変化 継続的な改善活動 一般的 市販ツールの進化に任せたい 重要でなければ優先度を下げて対応 期待効果によっては投資もあり 実現方法 実現したい事 市販ツール運用 ツール開発技術の維持が不要 ニーズに対し小回りがきかない 独自ツール作成 4 個別の事情にマッチした環境が得られる ツール開発工数だけでなく 技術の維持も必要 ( できれば外注化 ) 3 1 発表事例 実現方法 2 13
ご静聴ありがとうございました 14