マツダ技報2023

117/203

　OEM／サプライヤー間での仕様の曖昧さによる手戻り工数増大に対し，曖昧さの要因となる文書ベースの仕様書をモデルに置き換え，開発工程の各段階で仕様をモデルで詳細化し，検証して後工程に品質の高い仕様を提供することを可能とする，ソフトウェア開発へのモデル適用を行った。　OEM／サプライヤー間で，ツール間でのモデル流通を保証するためモデル交換ガイドラインを定義し，離散事象系（MDD）／連続系（MBD）をつなぐためのI/Fを定義し，OEMとサプライヤーのツール間を連携させたシミュレーション環境を構築し，シミュレーション実行可能なモデルを共有するなど共通基盤を構築した。本手法を用いてCX60以降に搭載されたマツダコネクトのドライブレコーダー連携機能の実装を行った。モデルをシミュレーション実行することでユーザビリティ改善案を仕様に織り込む等，特にSW詳細設計，実装，テストでの工数削減の効果があった。　さらなる効率化のためには，モデル開発環境の整備や，業界内でのモデルの標準化，モデル設計・ソフトウェア設計を推進する人材育成が必要と考えている。　なお，本技術開発は，パナソニックオートモーティブシステムズ（株）と共同で開発したもので，関係諸氏にお―109―5.3　実装コード生成用モデル変換と等価性確認　次に実装コード生成のためのモデル変換について述べる。　これは要求のSysMLモデルを4章で述べたモデル交換ガイドラインに沿ったSysMLモデルに変換する。Fig. 9に変換の一例を示す。これはChange Event（値の変化をトリガとするイベント）をSignal Event（信号の受信をトリガとするイベント）に変換する例である。本変換によるSysMLモデルの検証は5.2節で述べた変換と同様の手順で実施した。具体的にはExcel VBAを用いたテスト結果の比較ツールを構築し変換前後のSysMLモデルの等価性を確認した。このモデル変換と等価性確認により実装コード生成可能なSysMLモデルへの自動変換が可能といえる。Fig. 9　Example of Model Transformation for Implementation Code Generation6.1　MILSSILS統合検証環境の概要　3.1節で述べたとおり，従来の開発では，ソフトウェア詳細設計の結果であるソフトウェアソースコードがECUに実装された後に検証が実施されるため，万が一要求，要件に間違いがあった場合，大きな開発の手戻りを発生させてしまう。　ここでは生成後のコードの検証環境である，MILSとSILS （Software in the Loop Simulation） を統合した検証環境（以下，MILSSILS統合検証環境）について述べる。　ECUへの実装前のソフトウェアソースコードをSILSによるソフトウェアの単体検証の完了後に，MILSSILS統合検証環境を構築し，実装前に要求，要件の検証を行う方法を構築した。Fig. 10にMILSSILS統合検証環境の概要を示す。Fig. 10　MILSSILS Integrated Simulator6.2　MILSSILS統合検証環境の詳細　MILSSILS統合検証環境を構築するに当たり問題になったのが，プラントモデルのMILSと情報制御モデルのSILSの検証環境としての性質の違いである。　MILSは，自動車のエンジン制御の検証にも用いられており，熱や運動に関する連続系モデルを周期的な時間同期でシミュレーションを駆動するという性質をもつ。一方SILSは，情報処理領域を離散事象系としてモデル化しており，非同期でシミュレーションを駆動するという性質をもつ。MILS，SILSを連携するに当たり，同期，非同期で駆動される両検証環境の信号を相互変換するインターフェース（以下MILS I/F）を構築し，このMILS I/Fを介して両検証環境を連携させた。Fig. 11にMILS I/Fの概要を示す。今回，MILS I/FをTCP（Transmission Control Protocol）通信により実現し，MILSとSILSの信号の相互変換と受け渡しを行った。6. MILSSILS統合検証環境Fig. 11　MILS I/F7. おわりに