![](/column/assets/images/banner.jpg)
OEM⇔サプライヤでのECU制御ソフトウェア環境共有による手戻り工数削減方法
目次
1. 不具合修正にかかる工数
2. OEM⇔サプライヤ - 開発における問題点
3. OEM⇔サプライヤ - SILSを使用した要求仕様の不具合の早期発見
4. OEM⇔サプライヤ - 要求仕様の不具合の早期発見における課題と解決
4-1. 秘匿性
4-2. 仮想ECU環境構築工数
4-3. ツールコスト
5. まとめ
1. 不具合修正にかかる工数
ECU制御ソフトウェアの開発では、以下のV字モデルが使用されます。
不具合が後工程で発見されればされるほど、そこまでの各工程をやり直す必要があるので、修正にかかる工数(手戻り工数)は大きくなってしまいます。
各開発フェイズにおける一つの不具合が発生した時に要する修正コスト
![各開発フェイズにおける一つの不具合が発生した時に要する修正コスト](/column/assets/images/gsil20230721_pic2.png)
- コーディング時の修正コストは$977/不具合
- 結合テスト時の修正コストは$7,136/不具合
- 開発の早期段階で不具合修正が必要
これは、開発の各フェーズで1つの不具合を修正する場合のコストを示した、Boehm、BasiliがIEEE Computerに掲載した資料です。修正コストは、実装以前のフェーズではさほど大きくなく、テスト以降になると跳ね上がります。特に、自動車ECUで量産後に不具合が発生、リコールになってしまうと、莫大な対応コストとブランドイメージの低下を引き起こすため、可能な限り早期段階で不具合を発見し修正するということが求められます。この概念は、フロントローディング、シフトレフトなどと呼ばれます。
ユビキタスAIと株式会社 エー・アンド・デイが共同開発・販売している車載ECUソフトウェア開発向けシミュレーションツール「GSIL」は、SILS(Software In the Loop Simulation)です。SILSを使用すれば、フロントローディングを実現することができます。SILSについては、こちらのコラムで説明しているので併せてご覧ください。
2. OEM⇔サプライヤ - 開発における問題点
OEM⇔サプライヤ間でのECU開発は、以下のような流れになります。
![OEM⇔サプライヤ間でのECU開発の流れ](/column/assets/images/gsil20230721_pic3.jpg)
OEMが要求仕様を作成し、サプライヤで設計、実装、検証後にOEMに提供されます。もし要求仕様に間違があったり、サプライヤが要求仕様の解釈を間違えていたりした場合、それは実機試験が完了し、OEMに提供後に発見されることになるので、修正には非常に大きな工数がかかってしまいます。
より詳しい技術や関連製品について知りたい方へ
3. OEM⇔サプライヤ - SILSを使用した要求仕様の不具合の早期発見
SILSを使い、サプライヤがPC上で要求仕様を確認ができるようになった段階で、SILS環境をOEMに提供します。そうすることで、より早期の段階で要求仕様の不具合発見と修正が可能となり、手戻り工数を大幅に削減することができます。
![SILSを使用した要求仕様の不具合の早期発見](/column/assets/images/gsil20230721_pic4.jpg)
4. OEM⇔サプライヤ - 要求仕様の不具合の早期発見における課題と解決
一般的なSILSでは、OEM、サプライヤでSILS環境を共有するに際して「秘匿性」、「仮想ECU環境構築工数」「ツールコスト」という3つの課題があります。
4-1. 秘匿性
GSILの場合、仮想環境、プラントモデルはdll化されるので秘匿性の問題はありません。
4-2. 仮想ECU環境構築工数
仮想ECUの構築とは、アプリケーション部分のソースコードをPC向けのコンパイラでビルド、実行するための作業です。ECUのソースコードは、ターゲットの組込みコンパイラ向けにプラグマ命令などを使用して作成されているため、そのままでは使用できません。また、アプリケーション部分のみをコンパイルすると、ドライバの呼び出し関数が含まれないのでリンクエラーになります。従来型のSILSでは、これらの対処のためにソースコードを変更したり、スタブを作成したりする必要があります。それに対しGSILは、従来のSILSに比べて容易に環境構築を行うことができます。コンパイラに対応済みで、人手での変更はほぼ不要です。リンクエラーも自動的に解消し、スタブを自動で生成します。
実機のビルド
![](/column/assets/images/gsil230718_31.png)
アプリケーション
ソースコード
ミドル層・
ドライバ層
ターゲット
コンパイラ
オブジェクト
![](/column/assets/images/gsil230718_33.png)
フラッシュ
従来型SILSのvECU構築
![](/column/assets/images/gsil230718_31.png)
アプリケーション
ソースコード
ミドル層・
ドライバ層
(スタブ)
手作業で数多くの
個所をコード修正
Windows
コンパイラ
仮想ECU
(vECU)
![](/column/assets/images/gsil230718_34.png)
SILS組込み
GSIL vECU構築
![](/column/assets/images/gsil230718_31.png)
アプリケーション
ソースコード
ミドル層・
ドライバ層
(スタブ)
マイコン依存部分を自動修正
スタブ自動作成
Windows
コンパイラ
仮想ECU
(vECU)
![](/column/assets/images/gsil230718_34.png)
SILS組込み
4-3. ツールコスト
一般的なSILSでOEM⇔サプライヤで環境を共有しようとすると、OEM、サプライヤ両方でSILSツールを購入する必要があります。GSILの場合は、どちらか片方がGSIL を所有していれば、他方は購入の必要がありません。GSILであれば、低コストでOEM⇔サプライヤ間における開発環境の共有が可能なるとともに、手戻り工数を大幅に削減することができます。
5. まとめ
GSILを使用することで、ソフトウェアを実装するサプライヤの開発、検証効率が向上します。その環境をOEMとサプライヤ間で共有すれば、要求仕様の手戻り工数も削減することができます。
このコラムの著者
![株式会社ユビキタスAI エンベッデッド第3事業部 担当部長 植田宏](/column/assets/images/pf_ueda.jpg)
株式会社ユビキタスAI
エンベデッド第3事業部 担当部長
植田 宏​(うえだ ひろし)
大学卒業後Tire1メーカーへ入社、ECUソフトウェア開発を行う。その後海外で組込みソフトウェア開発エンジニアの経験を経て、帰国。1998年より車載系ソフトウェアの技術営業に従事。自身の経験を活かし、課題解決に役立つ海外のソフトウェア商材を取扱い、国内のエンジニアへ届けている。
より詳しい技術や関連製品について知りたい方へ
システムテストのカバレッジ測定
2024.06.13
組込み制御ソフト開発へのシミュレーション応用による開発効率向上
2024.06.04
CANを使用したSILSテスト ―車両全体シミュレーション、テストケース再利用―
2024.05.27
GSILのMILS開発への適用
2023.12.20
GSILのCI(Continuous Integration)適用
2023.09.22
GSILの網羅的自動テストケース生成機能を使ったECUの信頼性向上
2023.09.13
SILSを使用した車載制御ECUソフトウェア開発競争力強化
2023.07.20
車載ECUシミュレーションでテスト資産を活かすための技術とは?
2022.05.16
早期の車載ECUタイミング検証の実現
2021.08.27