isit 第10回カーエレクトロニクス研究会『グローバル化とmbd...

1 Copyright © 2012 GAIO TECHNOLOGY CO., LTD. ALL RIGHTS RESERVED.

【開示及び用途制限資料ガイオ・テクノロジー株式会社】

2012.1.30

ガイオ・テクノロジー（株）

橋本一也

ISIT 第10回カーエレクトロニクス研究会

『グローバル化とMBD化が進む

組込み開発で選ぶ「ツール」とは？』

※本内容は、予告無く変更する場合がありますので、予めご了承下さい。



ガイオ・テクノロジーとは？

・組込み系開発ツールのメーカー（コンパイラ/検証・テスト・解析ツール/プロトタイピングツール等）・MBDやMDDなどのモデル開発事業とテスト・検証に関するサービスやコンサルテーションを展開

・30年のツール開発や販売のノウハウを活かしツール開発・供給を拡大・加速させてゆく

ガイオ・テクノロジー株式会社 GAIO TECHNOLOGY CO., LTD.

■ 設立 1980年 ■ 資本金 2億9800万円 ■ 従業員 80名

（営業10名技術者60名支援要員 10名） ■ 本社：横浜 ■ 事業所：東京、松山 ■ 子会社： GAIO INC（USA）

GAIO：ポルトガル語で快活な、楽しそうな、抜け目のないの意

カバレッジテストツール

仮想検証ツール/MBD向けテストツール

自動テストツール

ツール関連事業の1例

GAIO：ポルトガル語で快活な、楽しそうな、抜け目のないの意

ツール事業モデル中核開発事業

お客様の「エンジニアリング能力（競争力）」向上を支援



ガイオのツールチェーンコンセプト「GIS」

・業界、とくにカーメーカー、ECUサプライヤーの期待に応えるものとして・検証と実装を生業にしてきたガイオも設計やライフサイクルマネージメントの提案を必要と決断

・Global tool Interlink Solution (略称GIS)をツールチェーンコンセプトとして前面に打ち出してゆく

Integrity連携 ■ Team Center連携 ■ Team Concert連携 ■ Inter Stage ADM連携 ■ Quality Center連携 ■ EA連携 ■ astah連携 ■ プロトビルダー ■ GUIビルダー/A2RU ■

■

Reactis連携 ■ EmbeddedTester連携 ■ Matlab/Simulink連携 ■ SLDV連携 ■

■ ■

G-VPM ■ プロジェクトコンポーザー ■

■ ■

リバースモデリング代行 ■ ■

レガシーリファクタリング ■ ソフトウェア見える化 ■ 単体品質ギャップ診断 ■

■ XCCV/XCC++ ■

■ ■ ■ ■ RtFT ■ ADAMS連携 ■ SCS ■ VECU-G/VMPF-G ■ VESS-G ■ MFSS-G ■ ASLS-G ■ ■ FIシミュレータ ■ ■ winEVT ■ ■ ■ カバレッジマスター ■ ユニットマスター ■ ユニットテストオンザトラック

■ ■ MC-Checker ■ TargetLink連携 ■ 単体テスト代行 ■ ■ CasePlayer2 ■ ■ WXG 機能安全solution ■



モデル（MBD/MDD）中核開発事業（MCD事業）展開

・従前のハード、ソフト受託開発能力をMBD/MDDに対応・ツール事業で経験を積んだソリューションやコンサルをサービス事業に

・中期的にはモデル販売とカスタマイゼーションおよびプロセス導入支援を中核に事業を拡大

開発

企画

仕

様検

討システム設計

ソフト設計

ハード設計ソフト実装/検証

ハード実装/検証

モデルリファクタリングモデルリダクション

モデルチューニング

システム検証

MBDを基軸に

MDDを基軸に

MBD/MDD 開発受託

ソリューション

リバースモデリング

コンサルティング MBDのプロセスとツール導入および定着の支援

MDDのプロセスとツール導入および定着の支援

モデル/ライブラリ開発および販売とカスタマイズモデル/ライブラリ

開発&販売

モデル（MBD/MDD）中核開発事業



ガイオは何が得意？

リバースエンジニアリング

CASE連携

リバース CASE

MISRA 構文チェック

協調検証協調検証

MBD対応

I/O検証単体テストコードカバレッジ

測定

RTOS M/W

試作レス実機レス

静的解析

テストデータ生成

テスト設計

BtoBテスト

・クロスコンパイラ/マイコンシミュレータ系デバッガでツールメーカーとしての地場を固める・各種ツールをリリースし多様性をアピール現在は検証ツール、テストツールを中心に事業展開

・コンパイラ開発で得たコード解析技術・経験とマイコンシミュレータの開発資産・経験が基礎技術

コード解析・加工

システムシミュレーション

クロスアセンブラ

クロスコンパイラ

デバッガシミュレータ

HMI仕様作成

近年の傾向・自動化/機械化による省力・品質改善・安全規格への対応



海外展開

・欧州、中国、インド、北米にセールス拠点を展開（インドはパートナー選定中）・欧州にはサポート拠点も設置

・ガイオのビジネスフォーカスはワールドワイド

GAIO Technology Tokyo,Japan

Sales&Support R&D VRAIC

China Sales

Undecided India Sales

Sumitomo Deutschland GmbH EU/Germany

General Agent GAIO Inc USA/North America

Sales

Undecided EU

Sales&Support

スペシャリストによる顧客訪問顧客先でのセールスパッケージ展開戦略的活動

VRAICサイトでのサイクリックなセールスプログラム実施

Webベース営業トライアルパッケージ中核

顧客訪問を中心とした直販セミナーとDMを多用した販促展示会は年間に大小4つ程度製品開発と製品企画



目次

1. ソフトウェア開発の動向

2. MBDと開発ツール

3. 機能安全と開発ツール

4. 今時の開発ツール

5. まとめ



１．ソフトウェア開発の動向（グローバル化が進む環境）



車載ソフト開発の現状と課題

設計品質の向上

開発期間の短縮

開発コストの削減

■ 技術テーマが、快適・安全・環境へ移行

■ 機能安全への対応が必要に

■ 国際規格の制定で、開発がグローバル化

部品管理

品質問題

会社間コミュニケーション円滑化業界規格対応

スキル不足

グローバル化性能向上機能間の相互接続

インテリジェント化（高機能化）

大規模化

標準プロセス適用

作業の可視化

エビデンス作り



開発ツールの動向欧/米/中/日

・欧米や中国ではツールを多用する文化が日本に先行特に欧州は国策－産学連携が上手く機能・日本は優秀な技術者があらゆる問題を解決してきたので汎用ツールの活用余地が少なかった

・日本も今後はツール活用を増やしてゆき真の国際競争力を得る段階に来たと考える

北米や欧州、中国に比べ日本はツール使用度合いが低いといわれる経済産業省のデータを見ても「品質確保のため」がツールの購入理由の大半であっても設計ツールや管理ツールの利用割合はけっして高くない



参考：UML/ADL動向

・自動車業界から見たUML動向 UMLからADLへ自動車業界が規格作成に大きく関与・日本の積極的関与はほとんど無し当面は、規格を上手にキャッチアップするベンダーの見極め

UML2

SDL MSC

Synchronous Language

AML

ADL

UML3,MARTE,SysML2,EAST-ADL

ITU OMG

BWM BOSCH

INRIA CEA/LIST

SAE SEI IEEE EAST

ERICSSON

UML1.4 ADL:Architecture Description Language AML:Automotive Modeling Language SDL:Specification Description Language MSC:Message Sequence Chart

アーキテクチャ記述言語ADLに関するとりくみ

欧州 HOO 1990～

Koala 1996～

AIL-Transport 1999～ EEA

EAST-ADL 2001～ EAST-EEA

AUTOSAR 2003～ AUTOSAR,EASIS

UML2.0 2003～ OMG提案は2002

EAST-ADLⅡ 2006～ ATESST

SysML,MARTE 2005～ 2008 OMG

EAST-ADLⅢ 2008～ ATESSTⅡ

米国 AADL SAE,SEI,IEEE CMM/SEIはアーキテクチャ手法中心 ASAM,ATAM

日本なし



どんな影響が発生するのか？

・品質規格に制約をうけ日本の技術力が平凡化・グローバル化、開発手法の変化、に立ち遅れることで日本の技術競争力低下の懸念

・放置が続けば日本製または日本である必然性が低下してゆく



国際規格制定による影響が大きい

■国際規格の制定により

グローバル化が進展 • AUTOSAR規格 • 機能安全規格ISO26262 • 他

コンソーシアム策定規格

MSR 仕様書交換フォーマット

HIS OSEK拡張

C言語コーディングガイド

メトリクスガイド

Automotive-SPICE

テストプロセスTPI-Automotive

OSEK リアルタイムOS

ASAM 適合データツール、フォーマット

MOST マルチメディア通信

FlexRay 高速通信

CAN 通信

LIN ボディ通信

AUTOSAR 基本ソフトPF

UML/SPEM ソフトプロセス

UML/BPM ビジネスプロセス

●AUTOSAR関連の主要民間コンソーシアム

（海外が中心）



２．MBDと開発ツール



各自動車関連メーカー様の取り組み

①標準開発プロセスの適用推進 • AutomotiveSPICE、CMMI、など

②モデルベース開発の推進 • 業界標準ツール、AUTOSAR、ADL、など

③開発プラットフォームの整備 • AUTOSARなど

④機能安全への対応 • ISO26262など

※どれもグローバルな対応が求められる



仕様書（文書）

設計書（文書）

分析モデル

機能モデル

実装モデル

フローチャート

t

残存バグ数

残存バグ数

要件定義 DR DR 機能設計詳細設計プログラミング

テストデバッグ

DR

要件定義機能設計テストデバッグ

MR SIM

DR: デザイン・レビュー MR: モデル・レビュー SIM: シミュレーション

0

従来

開発

プロ

セス

モ

デル

ベー

ス開

発プ

ロセ

ス

期間短縮

品質向上

MR SIM

MR SIM

詳細設計

モデルベース開発の推進

■ モデルベース開発プロセスの効用

• 分析、機能、実装モデル毎の検証による品質向上と期間短縮



・パラメチューニング

・単体／合体検証・ターゲット化の影響（機能実行速度やスタック使用量など）を検証・異常系の確認・オートコードの動作確認・物理的ﾌﾟﾛﾄﾀｲﾌﾟを削減

・ハードウェア化の影響(動作タイミングなど）を検証する・コントローラ不具合の検出・実験で生じた不具合の再現

・HILSでは困難なデバッグ

MILS環境（Model In the Loop Simulation）

SILS環境（Software In the Loop Simulation） HILS環境

（Hardware In the Loop Simulation）

実機検証環境

PILS環境（Processor In the Loop Simulation）

プロトタイプ（Prototyping）

実行環境・シミュレータ（SPILS）・エミュレータ・ボード

・S-Functionアルゴリズムで検証する・C言語化の影響(量子化誤差など）を検証する・高速シミュレーションする

・制御装置の試作期間短縮・検討用コードの自動生成・効率的なモニタ・データ解析環境・コントローラ要求仕様検討

V字開発プロセスとMBD検証環境

検証設計

コントローラ (モデル)

Plant (モデル) +

コントローラ (PC)

Plant (モデル) +

コントローラ (実機)

Plant (モデル) +

コントローラ (実機)

Plant (実機) +

コントローラ (マイコン)

Plant (モデル) +

コントローラ (ﾌﾟﾛﾄﾀｲﾌﾟ)

Plant (実機) +

・コントローラ設計・離散化検証・パラメチューニング

ＥＣＵ単体実機（HILS）検証

実車テスト車両仕様設計

ＥＣＵ単体詳細設計

コード生成

ＥＣＵ実装

車載ソフト単体検証

車載ソフト合体検証

※各用語の定義は各社で異なりますので、ご注意ください。



モデル関連ツール必要技術

・モデルベースの場合、必要技術が成熟途上にあるものがまだ多い

分類技術コードベース開発時代の必要技術モデルベース開発時代の必要技術

実装記述ルールコーディングルールモデリングルール

リファクタリングコードレベルモデルレベル

実装品質の確認デバッグコードデバッグモデルデバッグ

テストパターン作成コードレベルモデルレベル

テスト自動化コード駆動モデル駆動

シミュレーションコードシミュレーションモデル連携シミュレーション(MIL/SIL/PIL/HIL)

性能測定コード実行性能（実行・スタック使用量）コード実行性能

モデルシミュレーションによる測定

実装品質の基準メトリクスコードメトリクスモデルメトリクス

カバレッジコードカバレッジコードカバレッジ（ACGの品質が満足できない場合）

モデルカバレッジ

（システムカバレッジ）（システムカバレッジ）

仕様・設計工程に関わる技術

ソースコード自動生成オートコーダー

コード作成コンパイラコンパイラ

リバース（資産移行）クロスリファレンスリバースモデリング（資産移行作業）

設計書作成

一致性確認ウォークスルー/レビュー BTBテスト（Back-To-Backテスト）

※赤字は、特徴的な技術



機能モデルベース開発時代の必要技術ツール・サービス

記述ルールモデリングルールガイドライン MISRA AC （機能安全にフォーカス）、JMAAB Control Algorithm Modeling Guidelines （コントローラのモデルレイアウト＆ネーミングコンベンション）、dSPACE TargetLink Modeling Gudeline

チェッカー Model Examinar （MXAM： Simulink, Stateflow, MISRA ACのチェック）、StyleChecker (AFT)

リファクタリングモデルレベルリファクタリングサービス

デバッグモデルデバッグ Simulink, Simulink Design Verifier

テストパターン作成モデルレベル SystemTest, Reactis, EmbeddedTester, TVEC, カバレッジマスター+CasePlayer2

テスト自動化モデル駆動 SystemTest, Reactis, EmbeddedTester, TVEC, MC-Checker

シミュレーションモデル連携シミュレーション各社HILS, 各社PILS, VECU-G/VMPF-G/VSFS-G/ASLS-G

性能測定コード実行性能 MC-Checker

モデルシミュレーションによる測定 Simulink

メトリクスモデルメトリクス eXquote

カバレッジコードカバレッジ Reactis, EmbeddedTester, TVEC, カバレッジマスターほか

モデルカバレッジ Simulink Verification and Validation、Reactis, EmbeddedTester, TVEC

システムカバレッジ

ソースコード生成オートコーダー Real-Time Workshop Embedded Coder、 TargetLink

リバースリバースモデリングリバースモデリング代行サービス（一部ツール化予定）

一致性確認 BTBテスト MC-Checker、EmbeddedTesterほか

参考）現状のモデル関連ツール



MBDの適用状況

■ アプリの部分での適用

■ 量産適用が始まっている

プロジェクト

項目先行開発量産開発

制御仕様開発

要求検討 ○ ○

ラピッドプロトタイピング ○ (フルパス・バイパス)

○ (バイパス)

Simulink仕様書 ○ (アプリ)

○ (アプリ)

実装 ACG

(自動コード生成)

○ ○

確認・検証 HILS/SILS/PILS ○ ○

JMAABより



MILS/SILS SPILS

MBDの構成要素

コントローラ（制御器） + プラント

（制御対象）

同定モデル

データフローモデル状態遷移モデル

VinDC = 130

TX1

L1_VALUE = 10mHL2_VALUE = 0.166mH

C20.5n

R2100

0

00

C30.1u

R1130

1 2L1

20uH

C1200u

OUT

0

D1

D1N4933

D2D1N4933

Rf100Meg

D3D1N4933

1

2

3

4

5 -Reference

+X1

ZX

Rref1

0

VloadDC = 1

0 0

Vsw

TRAN = pulse(0 1 5u 0.05u 0.05u 12.5u 25u)0

2N6547/TO

Q1

0

Load

ターゲットコード

オートコード生成

専用OS

コントローラモデルプラントモデル

コードダウンロード

専用ライブラリ

モデル関連ツール

Real World

Virtual World

ターゲットボード

プロトタイプボード HILSボード／FPGAボード

ダウンロード

HILS

実機

測定データ



モデル関連ツール（MBD/MDD開発対応ツール）

・下表のように、要望はつきない →まだまだ十分ではない・これから徐々に整備

ツール名ツールのやくわり

1 テストパターンジェネレーションモデルからテストパターンを生成

2 モデリングルールチェック（独自/MAAB/JMAAB/TargetLink/…）

大量のルールを自動チェックで効率化

3 Simulinkビューア Simulinkライセンスなしでも使える

4 Simulinkモデルメトリクスモデルの出来栄えを一定の物差しで評価

5 Simulink整形可視化＋ルールに準拠した整形

6 ブロック検索複数のブロックの組合せを検出

7 レポーターブロック＆プロパティ表示（レビュー用図面）

8 専用データディクショナリパラメータ一括設定・閲覧・変更用

9 タグ＆ジャンプエディタ操作性向上

10 静的解析 Simulinkの解釈難のエラーメッセージの補助

11 Simulinkブロックロガーブロックがどう実行されるかトレース

12 リバースモデリングツール（C→Simulink）資産移行の効率化

13 Simulinkブロックとコード関数の連携オートコード評価環境

※お客様の必要度に応じ開発優先順位を変更



a.c a.c

組込みソフトウェア(obj-E)

モデルベース開発(MDD)のプロセスとツール

a.c

obj-D

m.c

obj-M

TP-D

AMS/CP2

100%

テストデータカバレッジ情報

オートコーダー（RTW-EC）

スタブ関数

TP-M

AMS/CP2

100%

テストデータカバレッジ情報

s.c

obj-E

MATLAB/Simulink （実装モデル）

リンク

コントローラ (マイコン)

Plant (モデル) +

MC-Checker 一致性

MATLAB/Simulink (全体モデル)

MATLAB/Simulink （機能モデル）

・離散化・固定小数点化・機能モデルとの一致性確認

結合テスト (全体動作確認＋故障注入テスト)

単体テスト（モデルとコードの動作確認）

SysML(Enterprise Architect / astah?)

コンポーネント図

シーケンス図

クラス図

ステートマシン図ユースケース図

要件定義設計実装

コード生成

単体テスト (カバレッジ確認)

シナリオ入力

ダウンロード

d.c

ドライバ等

ソフトウェアPF

マイコン・シミュレータ

Plant (モデル)

同じもの

※ 現時点で一番近い現実解の例

課題

課題



UML(SysML) とSimulinkとの連携（現時点の連携方法）

■ UMLシミュレーション（全体実行）

■ Simulink実行

MATLAB/Simulink

リンクコード生成


シーケンス図

クラス図



Plant (モデル)

MATLAB/Simulink

S-function生成

Plant (モデル)

dll

RTW

dllリンク

dll S-function


シーケンス図

クラス図



Obj

RTW-EC


【開示及び用途制限資料ガイオ・テクノロジー株式会社】 ※ ：ガイオソリューションで対応

開発プラットフォームの整備

●実装モデル

機能2 プラント1

A C

BSW1

HW1

機能１

E C

B

D A


コンポーネントベース開発モデルベース開発プラットフォームベース開発

BSW2

HW2

B A C

BSW3

HW3

B

機能2

機能１

参照

プラントモデル1

MILS/SILS

MILS/SILS

ECU3 ECU2 ECU1

●機能モデル

プラント1

機能2

機能１

プラントモデル1

MILS/SILS

MILS/SILS

コードベース SWコンポーネント

A C

BSW3

HW3

B

ECU3

RTE

BSW2

HW2

B

ECU2

RTE

A C

BSW1

HW1

ECU1

RTE

A C

ECU1

プラント1 プラントモデル1

MILS/SILS

MILS/SILS

オートコード生成／コンパイル／リンク

VFB VFB

ECU2

B A C

ECU3

VFB

B

E C

B

D A HW毎

リンク

E G

BSW3

HW3

F

ECU3

BSW2

HW2

B

ECU2

A C

BSW1

HW1

ECU1

A C

ECU1

コンパイル／リンク

ECU2

B E G

ECU3

F

ECU毎オートコード生成

HILS

SS

SILS/PILS SILS/PILS

PILS /HILS

PILS /HILS

モデルベース SW-C

ECU再構築可能

BSWにより HWの抽象化

再利用性向上流動化

VFB: Virtual Functional Bus RTE: Run-time Environment

AUTOSAR / JasPar



AUTOSAR プロジェクト・プラン

■ 開発 • ３つのフェーズで進行しており、現在はフェーズ３に

■ 適用状況 • 欧州のOEM

― → • 北米のOEMは・・・

― GMなどはAUTOSAR 4.Xを使用予定としている • 日本のOEMは・・・

― 機能安全のメリットがAUTOSARによってどこまで見出せるのか？ ― JasParの検討結果待ち状態？

フェーズ活動内容

フェーズ１・ AUTOSAR Release2.Xで2006年まで

フェーズ2 ・ AUTOSAR Release3.Xをメインにこれまでのアップデートや改善・ AUTOSAR Release4.0のスタート

フェーズ3 ・ AUTOSAR Release4.Xの最終版として2012年目標でBSWのエンハンスメントや機能安全、パワーセーブなどを盛り込む予定 => 4.X を使用した量産ECUの開発が加速する模様



AUTOSAR ソフトウェア・アーキテクチャ

出所）AUTOSAR, “AUTOSAR_LayeredSoftwareArchitecture”より転載



.XML

ECU Extract of System Configuration Configure

ECU Extract ECU-Specific Information

System Configuration Description

Configure System

System Configuration Input

.XML .XML

.XML

ECU Configuration Description

Implement Component

Implemented Component

Generate Executable

.exe

ECU Executable

Component related templates

●ECUの設計とコンフィギュレーション

●コンポーネント実装

●システム・コンフィギュレーション

AUTOSAR Methodology （概要）



.XML

.XML

.XML .XML Vendor Specific ECU Configuration Parameter Definition : Module Def BSW Module Description

: BSW Module Description

Collection of Available SWC Implementations

ECU Extract of System Configuration : System

Configure ECU

Extract ECU-Specific Information

ECU Configuration Extractor

System Configuration Description : System

System CommunicationMatrix : CommunicationMatrix Type

System Configuration Generator

Configure System

System Mapping : SystemMapping

Available SWC Implementation : Implementation

Collection of Available SWC Implementations

Top-Level Composition : CompositionType

Mapping Constraints : SystemMapping

CommunicationMatrix as Constraint : CommunicationMatrixType

ECU Resource Description : ECU

System Configuration Input : System

Topology : SystemTopologyType

.XML

.XML .XML .XML

.XML

.XML

.XML

.XML

.XML

.XML

.XML

.h

.XML


Generate COM

RTE Generator

COM Generator

Generate RTE

Generate OS

OS Generator

OS Configuration Header

COM Configuration Header

RTE Header

RTE Code

COM Configuration Code

OS Configuration Code

MCAL Code

MCAL Header

Generate MCAL

MCAL Generator

Edit ECU Configuration

ECU Configuration Editors

.h

.h

.h

.c

.c

.c

.c

Compile Mudules

.obj

Compiled Objects

Link Mudules

.XML

Component Internal Behavior Description [API Generation] : InternalBehavior

Generate Component API

Component API Generator

Component API

Additional Headers

Implement Component

Component Internal Behavior Description [Post Implementaion] : InternalBehavior

Component Implementaion Description [for SourceCode] : Implementaion

Component Implementation

Compile Component

Component Implementaion Description [for ObjectCode] : Implementaion

Compiled Component

.XML .c

.XML

.XML

.h

.obj

.XML

.exe

Executable

.obj .obj

.obj .obj

RTE COM

OS MCAL

Compiler






■システムデザインツール・SystemDesk (dSPACE) ・DaVinci Developer (Vector) ・VSA (Mentor) ・ZIPC Autosar (CATS) ・Rhapsody (IBM)

■BSWコンフィグレーションツール・EB tresos Studio (Elektrobit) ・DaVinci Configurator Pro (Vector) ・ECU SPECTRUM (KPIT)

■マイコンとMCAL ・Renesas Electronics ・Fujitsu ・Freescale ・Infineon ・ST micro ・Texas Instruments

AUTOSARツール

■デバッグテストツール・モデルカバレッジ機能・コードカバレッジ機能・通信可視化機能・テストデータ生成機能・スタック使用量測定・VFB環境

■デバッグテストツール・コードカバレッジ機能・テストデータ生成機能・割込みテスト機能・エミュレータ・通信データ測定器・評価ボード



AUTOSAR Methodologyとマイコンシミュレータの連携（例）

.XML

ECU Extract of System Configuration

Configure ECU

Extract ECU-Specific Information

System Configuration Description

Configure System System Configuration Input

.XML .XML

.XML


Implement Component

Implemented Component

Generate Executable

.exe

ECU Executable

Component related templates




SW-C

（サーバ）

SW-C

（クライアント）

SW-C

（クライアント）

SW-C

（レシーバ）

SW-C

（センダー）

SW-C

（レシーバ）

通信状況をタイミングチャートでビジュアル化



・ODEモデル→Simulink記述・DAEモデル→ODEモデルへ変換→Simulink記述 or ・DAEモデル→Modelica記述

プラントの表現

コントローラ（制御器） + プラント

（制御対象）

常微分方程式 (ODE: Ordinary Differential Equation) で表現

作用・反作用、キルヒホッフの法則、質量保存則といった代数式を含む微分代数方程式 (DAE: Differential Algebraic Equation) で表現

■ODE変換の問題点・非常に多くの労力必要・結果は作業者に依存



プラント・モデリングに関する動向： modelicaが注目されている

■ modelicaとは、オブジェクト指向のマルチドメイン･モデリング言語

• オブジェクト指向 • 方程式でのモデル表現 • 物理量の国際単位の適用 • 微分、代数、離散方程式への対応

■ 物理システムのモデリング国際標準を目指す

■ 制御も記述できるが、プラント記述に利用。特に物理現象を表現するモデルの構築で使われている。コントローラ（制御ロジック）はSimulinkで記述。

■ 特徴（典型的記述）

• 代入文） x := 2+y; • 方程式） f = m * a; (左辺と右辺の式が等しいことを表現する)



Modelicaのツール

ツール名メーカ特徴

（MSL） Modelica協会 MSL=Modelica Standard Library （Molelica標準ライブラリ）

CATIA ダッソー・システムズ

Dymola ダッソー・システムズ Dymola=ダイナミック・モデリング・ラボラトリ

AMESim LMS

JModelica JModelica.org

MapleSim Maplesoft

MathModelica MathCore

OpenModelica OSMC

SCICOS Modlica SCICOS includes a compiler for a subset of Modelica language

SimulationX ITI



３．機能安全と開発ツール



各産業分野に対する機能安全規格

引用文献：“Functional Safety in the Automotive Industry, Process and methods” BMW AG, RELNETyX AGに加筆

安全規格 Safety Standards - IEC 61508 (Meta-Standard) - ISO TR 15497: MISRA Guidelines - ECSS-E-40A (EU, Space) - RTCA DO-178B (Aerospace SW, V&V) - SAE APR 7451 (Aerospace, HW) - NASA-GB-1740,13-96 (SW-Guidebook) - Def Stan 00-55 (Military) - IEC 60880 (SW in Nuclear Power Plants) - AUTOSAR Safety Function - ISO13482 (サービスロボット)

IEC 61508 Derivates - IEC62278, EN 5012x (鉄道) - IEC62304 (医療機器ソフトウェア)、 IEC60601 1-4 (Medical) - ISO10218 (産業用ロボット) - IEC61311-6 (PLC) - IEC62061 (産業機械) - IEC61800 (電子制御モータ) - IEC61784-3 (フィールドバス) - EN81-1 (エレベータ) - IEC61511 (プロセス産業) - IEC61513 (原子力) - ISO EN 12100 (Machinery) - ISO26262 (Automotive)

Specific Design Instructions - Standardised E-Gas-Safety Concept - Type Approval Regulations: ECE R13(H) Annex 18(8), ECE R79 Annex 6

Assessment Models - IEC 15504 (SPICE) - CMM(I)

品質規格 Quality Standards - ISO 16949 (automotive) - VDA Band 3.1 und 4.ff - DIN EN 60300-2(Reliability Management) - VDI 4001-10: Technical Reliability

Engineering Standards - ISO/IEC 12207 (SW-Process) - V-Model

Automotive SPICE

派生

派生

ISO26262 (Automotive)



機能安全対応ツールのポイント

3-1 各工程支援（各手法の支援）

3-2 作業成果物・検証エビデンスの作成

3-3 使用する開発ツールの認定

3-4 安全機構の確認支援



6-8

ソフトウェア単体設計と実装

6-9

ソフトウェア単体テスト

6-7

ソフトウェアアーキテクチャ設計

6-6

ソフトウェア安全要求仕様

6-10

ソフトウェア結合テスト

6-11

ソフトウェア安全要求の検証

CM/winAMS

MC-Checker

CasePlayer2

ASLS-G

VECU-G

VMPF-G

VSFS-G

クロスコンパイラ

システムシミュレータ

CM/winAMS

UnitMaster

VECU-G

MC-Checker

システムシミュレータ

ASLS-G

VECU-G

VMPF-G

VSFS-G

3-1 各工程支援（各手法の支援）

■ソフトウェア開発におけるＩＳＯ２６２６２－６参照開発フェーズモデルとガイオが提供するツール



参考：マイコンコアシミュレータ－機能安全とのかかわり

・ISO/DIS 26262のpart-6に記載される推奨・代表的ツールにもマイコンシミュレータが活用できるものが少なくない

分類表題代表的ツール（ガイオの理解）

6-5 製品開発の開始表１モデリングおよびコーディングの指針でカバーされる原則構造解析ツール、構文解析ツール、モデリングツール

6-6 ソフトウェア安全要求仕様

6-7 ソフトウェアアーキテクチャ設計

表２ソフトウェアアーキテクチャ設計のノーテーション構文解析ツール

表３ソフトウェアアーキテクチャ設計の原則モデリングツール、構造解析ツール

表４ソフトウェアアーキテクチャレベルにおけるエラー検出メカニズム構造解析ツール、動的解析ツール

表５ソフトウェアアーキテクチャレベルにおけるエラーハンドリングメカニズム

構造解析ツール、動的解析ツール

表６ソフトウェアアーキテクチャ設計のベリフィケーション手法レビュープロセス支援ツール、構造解析ツール

6-8 ソフトウェア単体の設計と実装

表７ソフトウェアユニット設計のノーテーション文書校正支援ツール、文書管理ツール

表８ソフトウェアユニット設計および実装のための設計原則構文解析ツール、構造解析ツール、動的解析ツール

表９ソフトウェアユニット設計および実装のベリフィケーション手法レビュープロセス支援ツール、構造解析ツール、構文解析ツール

6-9 ソフトウェア単体テスト

表１０ソフトウェアユニットテスト手法テスト設計ツール、ユニットテストフレームワーク、モニタリングツール、動的解析ツール、テスト比較ツール、故障／障害模擬ツール

表１１ソフトウェアユニットテストのテストケース導出手法テスト設計ツール、構文解析ツール、構造解析ツール

表１２ソフトウェアユニットレベル構造カバレッジメトリックスカバレッジ計測ツール、テストデータ準備ツール、テスト実行ツール

6-10 ソフトウェア結合テスト

表１３ソフトウェア結合テスト手法テスト設計ツール、ユニットテストフレームワーク、モニタリングツール、動的解析ツール、テスト比較ツール、故障／障害模擬ツール

表１４ソフトウェア結合テストのテストケース導出手法テスト設計ツール、構文解析ツール、構造解析ツール

表１５ソフトウェアアーキテクチャレベル構造カバレッジメトリックスカバレッジ計測ツール、テストデータ準備ツール、テスト実行ツール

6-11 ソフトウェア安全要求の検証

表１６ソフトウェア安全要件ベリフィケーション実行環境 HILS、SILS、PILS



分類表表題ガイオ・ソリューション(部分的に適用)

モデリング、コーディング

表１モデリングおよびコーディングのガイドラインでカバーされる原則 CasePlayer2

アーキテクチャ

表２ソフトウェアアーキテクチャ設計のノーテーション

表３ソフトウェアアーキテクチャ設計の原則

表４ソフトウェアアーキテクチャレベルにおけるエラー検出メカニズム

表５ソフトウェアアーキテクチャレベルにおけるエラーハンドリングメカニズム

表６ソフトウェアアーキテクチャ設計のベリフィケーション手法

ユニット表７ソフトウェアユニット設計のノーテーション

表８ソフトウェアユニット設計および実装のための設計原則 CasePlayer2

表９ソフトウェアユニット設計および実装のベリフィケーション手法 CasePlayer2＋WinAMS

表１０ソフトウェアユニットテスト手法 WinAMS / UnitMaster / VECU-G / ｼｽﾃﾑｼﾐｭﾚｰﾀ / MC-Checker

表１１ソフトウェアユニットテストのテストケース導出手法 WinAMS / UnitMaster

表１２ソフトウェアユニットレベル構造カバレッジメトリックス WinAMS / UnitMaster

結合表１３ソフトウェア結合テスト手法 VECU-G / VMPF-G / VSFS-G / ASLS-G /ｼｽﾃﾑｼﾐｭﾚｰﾀ / MC-Checker

表１４ソフトウェア結合テストのテストケース導出手法

表１５ソフトウェアアーキテクチャレベル構造カバレッジメトリックス

実行環境表１６ソフトウェア安全要件ベリフィケーション実行環境 VECU-G / VMPF-G / VSFS-G / ASLS-G

ISO26262-6の手法に対応するガイオ・ソリューション一覧

■ ソフトウェア単体テスト関連が中心の製品群



ISO26262-6手法に対応するツール（詳細例１）

■ 表１２ ― ソフトウェアユニットレベル構造カバレッジメトリックス

手法 ASIL ガイオから提供できるソ

リューション A B C D

1a ステートメントカバレッジ ++ ++ + +

WinAMS / UnitMasterにより計測、エビデンス作成（効率化）

1b 分岐カバレッジ + ++ ++ ++


1c MC/DC （Modified Condition/Decision Coverage) + + + ++




ISO26262-6手法に対応するツール（詳細例２）

■ 表１０－ソフトウェアユニットテスト手法

手法 ASIL ガイオから提供できるソリ

ューション A B C D

1a 要件ベーステスト ++ ++ ++ ++

1b インタフェーステスト ++ ++ ++ ++

1c 故障注入テスト

+ + + ++

WinAMS / UnitMaster / VECU-G / システムシミュレータ / FIシミュレータで欠陥データ作成・シミュレーション実行（効率化）

1d リソース使用測定 + + + ++

1e 該当する場合には、モデルとコードとのBack-to-backテスト

+ + ++ ++ MC-Checkerで一致性自動確認（効率化）



規格におけるユニットテストの手法

機能の含まれ具合規格適合度合

確認手段・対策

仕様書＝＝コード（一致）

○

仕様書＞コード（仕様に記述されている機能が、コード内に実装されている機能より多い）

× 要件ベーステスト要件カバレッジ

仕様書＜コード（仕様に記述されている機能が、コード内に実装されている機能より少ない）

× コードカバレッジ

■ 単体テストの目的は、ユニットソフトウェア仕様書通りであること、余分な機能がふくまれないこと、を確認すること。



ユニットテストに関するポイント（ISO 26262規格要約＋コメント）

■ ユニットテスト環境 • ユニットテストの環境は、できるだけターゲット環境に近い環境にすること。

― ユニットテストがターゲット環境で実行できない場合は、ターゲット環境下でテスト（単体テストでない）を規定するために、「ソースコードおよびオブジェクトコードの差異」、「単体テスト環境とターゲット環境」の差異を分析すること。

例）単体テスト環境とターゲット環境の差異が、データ語長、アドレス長が異なるソース／オブジェクトコードに表れる可能性がある

■ カバレッジについて

• 計測用コードを用いる場合は、その計測機能がテスト結果に影響を及ぼさないことを示す必要がある。

• 達成したカバレッジ率に対して論理的根拠を示すこと。

■ BTBテストについて • モデルベース開発の場合は、BTBテスト（Back-to-backテスト）が実施される場合があ

る。 ― BTBテストとは、「二通り以上の実現方法で開発されたソフトウェアを同じ入力でテストを行い、

その結果を比較することでテストを行う手法」を言う。期待値を作成する工程が削減できる利点がある（テストケース（入力）さえ作れば短期間に大量のテスト実行が可能）。

―現行のオートコーダの技術水準は「成熟度が低い」ので、出力コードの正しさをチェックしなければならない、との意見もある



適用事例）パワートレーンECUメーカでのBTBテストツール利用例

■ 走行データをテストに活用し、モデル一致性テストと単体テストを実現 • 実車走行のデータをMC-CheckerとカバレッジマスターwinAMSで実行 • 実車走行データでの動作確認をすることでOEM（完成社メーカ）とのコミュニケーションが円滑になる • 今後はCarSim（㈱バーチャルメカニクス製）やCANalyzer（Vector 製）などからテストデータの作成を

検討中

u実車走行データ

uCarSimデータ

uCANalyzerデータ MC-Checker

winAMS

テストデータテストデータテストデータ

lモデル動作の確認

lモデルとコードの一致性の確認

lカバレッジ取得



3-2 作業成果物・検証エビデンスの作成

安全計画（修正版）

ソフトウェア検証計画

モデル＆プログラム言語用設計・コーディングガイドライン

ツール適用ガイドライン

ソフトウェア安全要件仕様

ハードウェア-ソフトウェア・インタフェース仕様（修正版）

ソフトウェア検証計画（修正版）

ソフトウェア検証報告

ソフトウェアアーキテクチャ設計仕様


ソフトウェア安全要件仕様（修正版）

安全分析報告

ソフトウェアユニット設計仕様

ソフトウェアユニット実装

ソフトウェア検証報告（修正版）


ソフトウェア検証仕様



ソフトウェア検証仕様（修正版）

組込みソフトウェア



ソフトウェア検証仕様（修正版）


従属故障分析報告


コンフィギュレーションデータ仕様

キャリブレーションデータ仕様


コンフィギュレーションデータ

キャリブレーションデータ


検証仕様

検証報告

6-5 ソフトウェ

アレベル製品開発

6-6ソフトウェア

安全要件の仕様

6-7 ソフトウェ

アアーキテクチャー設計

6-8 ソフトウェ

アユニットの設計と実装

6-9 ソフトウェ

アユニットテスト

6-10 ソフトウェア統合とテスト

6-11 ソフトウェ

ア安全要件の検証

6-AnnexC ｿﾌﾄ

ｳｪｱｺﾝﾌｨｷﾞｭﾚｰｼｮﾝ

■ 作業成果物は、全体で１００以上。これらのトレーサビリティを保証する必要がある • トレーサビリティの保証 →ALM等のツールを利用 • 各作業成果物の作成 →各種ツールを利用

●表１：モデリングおよびコーディングのガイドラインでカバーされる原則 ●表2：ソフトウェアアーキテクチャ設計のノーテーション

●表3：ソフトウェアアーキテクチャ設計の原則 ●表4：ソフトウェアアーキテクチャレベルにおけるエラー検出メカニズム ●表5：ソフトウェアアーキテクチャレベルにおけるエラーハンドリングメカニズム ●表6：ソフトウェアアーキテクチャ設計のベリフィケーション手法

●表7：ソフトウェアユニット設計のノーテーション ●表8：ソフトウェアユニット設計および実装のための設計原則 ●表9：ソフトウェアユニット設計および実装のベリフィケーション手法

●表10：ソフトウェアユニットテスト手法 ●表11：ソフトウェアユニットテストのテストケース導出手法 ●表12：ソフトウェアユニットレベル構造カバレッジメトリックス

●表13：ソフトウェア結合テスト手法 ●表14：ソフトウェア結合テストのテストケース導出手法 ●表15：ソフトウェアアーキテクチャレベル構造カバレッジメトリックス

●表16：ソフトウェア安全要件ベリフィケーション実行環境

※参照ポインタは一部



3-3 ソフトウェアツールの認定

■TI (Tool Impact)

・ツールの不具合が安全要求を満足でき

ないような影響を与える可能性

TI1 可能性がないという論拠がある

TI2 上記以外

■TD (Tool error Detection)

・ツールの不具合、誤出力を検出できる確率

TD1 その確率が高い

TD2 その確率が中程度

TD3 上記以外

■TCL (Tool Confidence Level)

・要求される信頼度水準

TD1 TD2 TD3

TI1 TCL1 TCL1 TCL1

TI2 TCL1 TCL2 TCL3

Method ASIL

A B C D

TCL1 1a 使用実績から得られる信頼度

1b 開発プロセスの評価

1c ソフトウェアツールの妥当性検証

1d 安全標準に適合する開発

TCL2 1a 使用実績から得られる信頼度 ++ ++ ++ +

1b 開発プロセスの評価 ++ ++ ++ +

1c ソフトウェアツールの妥当性検証 + + + ++

1d 安全標準に適合する開発 + + + ++

TCL3 1a 使用実績から得られる信頼度 ++ ++ + +

1b 開発プロセスの評価 ++ ++ + +

1c ソフトウェアツールの妥当性検証 + + ++ ++

1d 安全標準に適合する開発 + + ++ ++

■ 課題 • たくさんある自社製ツールをどう認定するか



3-4 安全機構の確認支援

四輪操舵システム

21% 3

32

17

12 6

10

AFS

28% 12

30

13

11 2

4 OS

チューニング制御フェールセーフ／診断

信号処理・システムマネージメント

ドライバ

CAN

ET2008基調講演より

■ 比較的割合が大きい「フェールセーフ／診断」部の検証も重要

■ ECU機能が統合されてくると、アプリ間の保護が必要になってくる



安全機構検証に関わる検討事項

■ フェールセーフ＆フールプルーフの安全機構は • ハードウェアのみで実装 (ハードウェア的診断)

― ウォッチドッグタイマ ― クロック停止 ― etc

• ソフトウェアのみで実装 (ソフトウェア的診断) ― メモリパリティチェック ― 演算チェック ― ＣＲＣチェック ― 伝送路渋滞検出 ― etc

• ハードウェアとソフトウェアの組み合わせで実装

■ では、その安全機構をどのように確認するか？

■ 安全機構が確認できる状況を作って、その状況化で確認する必要ある • その確認には故障系動作を模擬できる仮想環境が必須と言われている

―（仮想環境だと）故障状態になっても壊れない ―（仮想環境だと）故障状態のままデバッグもできる



４．今時の開発ツール（期待されるツールの機能・要件の具体的事例）



今後期待されるツール機能（例）

① テストデータ自動生成

② バリデーション（仕様記述と形式手法）

③ ｖECU-MBD （仮想ECU）

④ フォールトインジェクション（故障注入テスト）

⑤ 割込みカバレッジ

vECU-MBD （仮想ECU）

テストデータ自動生成

バリデーション

フォールトインジェクション

割込みカバレッジ



①－１ UMLからテストデータ自動生成（EnterpriseArchitect）



テストベクタ生成

①-2 Simulinkモデルからテストデータ自動生成＆自動テスト

Simulink モデル

Tester

Reactis （動作はMスクリプトで記述可能）

csv Export

テストベクタ

SPILS実行（MC-Checker）

MILS 実行結果

OK/NG

BTB結果

Validator

カバレッジレポート違反検出特定のテストケースの検出

モデル実行

Simulator

テストベクタ＋実行結果

カバレッジ計測モデル上に通過パスを可視化

Back step

要求

要求の確認

テストベクタ

Simulink モデル


SPILS 実行結果




①-3 TargetLinkモデルからテストデータ自動生成＆自動テスト

Simulink モデル

Mスクリプト

TargetLink モデル

Cソース

ATG

CV

実行・期待値作成

SL-MIL

TL-MIL

TL-SIL

TL-PIL

BTBテスト

SL-MIL

TL-MIL

TL-SIL

TL-PIL

MC/DC

モンテカルロ法

形式検証テクノロジーを利用テストベクタ

(MC/DC用)

実行結果

EmbeddedTester （動作はMスクリプトで記述可能）

csv Convert/export （プラグイン）

MCC用テストベクタ


csv

SPILS実行結果

OK/NG

BTB結果

OK/NG

BTB結果

プロファイル作成

カバレッジ測定



モデルで実施する検証

●機能モデル（浮動小数点モデル）

車両機能車両機能車両要件

●要求分析モデル（SysML等）

●集中実装モデル（固定小数点モデル）

●分散実装モデル

Task１ Task2

タスク間通信（遅延）

機能間通信（遅延）

Task３

機能１機能2

(VFB)

(RTE) (RTE)

●実装コード

Task１ Task2 Task３

OS NW

OS NW

NW通信

ECU１ ECU2

●NW設計モデル

ECU

CAN ノード LIN

GW

ECU

ECU

t

task1 task2

task3

●タスク設計モデル

FlexRay

メッセージマッピング

タスクマッピングコンフィギュレーション情報

■誤差検証・シミュレーション

■リアルタイム性保証 / リソース要求検証・BCET/WCET （静的・動的）・シミュレーション

■実行時エラー検証・Cソース静的解析（モデル検査）

OEMメーカ

ECUメーカ

■到達可能性・矛盾性検証・形式検証（モデル検査）

■スケジューリング検証・形式検証（モデル検査）

■モデルとコードの一致性検証・時間的誤差

■モデルとコードの一致性検証・データ誤差・時間的誤差

■機能検証・シミュレーション・モデル・カバレッジ

■形式検証

■形式検証

■形式検証

■単体テスト・形式検証（モデル検査） ■形式検証

（SLP）



形式手法の利用が注目されてきている（ISO26262-6規格中の形式手法）

表手法 ASIL

A B C D 表手法

ASIL

A B C D

ユニット設計＆実装

アーキテクチャ設計

７ 1a 自然言語 ++ ++ ++ ++

1b インフォーマル・ノーテーション ++ ++ + +

1c セミフォーマル・ノーテーション + ++ ++ ++

1d フォーマル・ノーテーション + + + +

２ 1a インフォーマル・ノーテーション ++ ++ + +

1b セミフォーマル・ノーテーション + ++ ++ ++

1c フォーマル・ノーテーション + + + +

６ 1a 設計のウォークスルー ++ + o o

1b 設計のインスペクション + ++ ++ ++

1c 設計の動的部分のシミュレーション + + + ++

1d プロトタイプ生成 o o + ++

1e フォーマル・ベリフィケーション o o + +

1f 制御フロー分析 + + ++ ++

1g データフロー分析 + + ++ ++

９ 1a ウォークスルー ++ + o o

1b インスペｸション + ++ ++ ++

1c セミフォーマル・ベリフィケーション + + ++ ++

1d フォーマル・ベリフィケーション o o + +

1e 制御フロー分析 + + ++ ++

1f データフロー分析 + + ++ ++

1g 静的コード分析 + ++ ++ ++

1h セマンティックコード分析 + + + +

【ベリフィケーション】【ノーテーション】



形式検証ツールの適用フロー（EmbeddedValidator/SCADEの場合）

Simulink/Stateflow モデル

TargetLinkモデル

SCADEモデル

true Sig

import

変換

TargetLink

検証 Property

sig1

sig2 sig3

sig1

sig2

Implies (AならばB)

sig3

Property

Property

安全要件の記述 ※SCADEモデルで記述

検証エンジン

反例（含むベクター）

Assumption

検証エンジン


$走行中

$ロックしない

P

Q

※日本語のマクロで記述（中身は信号名を使ったロジック）

安全要件の記述

PならばＱ

デバッグ用モデル（反例を入力できるモデル）

生成

絞込み

Embedded Validator

SCADE 検証モデル

BTBテストが必要

Assume 制約条件



要件／仕様の形式化がポイント

■ 現状の問題：要求仕様書完成度の影響

• 開発のライフサイクルの中で、要求仕様書に起因する問題が40%を占める。（日本科学技術

連盟ソフトウェア品質管理研究会）

• 受発注間（社内も含む）での仕様の共有が困難となっている。 • 手戻り多発、品質低下、納期延長などで、テストの工数が設計・実装の2倍に達してい

る。（Jean-Raymond Abrial, Modeling in Event-B）

• 要求仕様書の欠陥が設計と実装に影響し、さらには市場に出た製品で問題が発生する。

■ ツール例： SPEC L-PERFECT（“SLP” と略）

• 要求仕様書を簡単な文法で正確に書くツール • 要求仕様書の論理整合性と一意性を支援 • 「主語述語論理モデル」による要求仕様記述ツールであり、大規模組込み系要求仕様

書の品質および品質説明力を向上させることを目的とした支援ツールである

※JFP様SLP資料より引用



応用１）仕様形式記述から形式検証

Simulink/Stateflow モデル

TargetLinkモデル

変換

TargetLink

Assumption

検証エンジン


$走行中

$ロックしない

P

Q

※日本語のマクロで記述（中身は信号名を使ったロジック）

要件の記述

PならばＱ

デバッグ用モデル（反例を入力できるモデル）

生成

絞込み

SLP

変換（自動）

BTC様仕様記述ツール（Embedded Specifier －開発中）

eXmotion様仕様記述ツール USDM 仕様

（日本語）

EmbeddedValidator

変換（自動）

現行仕様（半形式化されたもの）

要件（日本語）

SLP

変換（手作業）

モデル作成（手作業）







応用２）仕様形式記述から要件テストベクタを生成

Simulink モデル

Mスクリプト

TargetLink モデル

Cソース

ATG

CV

実行・期待値作成

SL-MIL

TL-MIL

TL-SIL

TL-PIL

BTBテスト

SL-MIL

TL-MIL

TL-SIL

TL-PIL

MC/DC

モンテカルロ法

形式検証テクノロジーを利用テストベクタ

(MC/DC用)

実行結果

EmbeddedTester （動作はMスクリプトで記述可能）

csv Convert/export （プラグイン）

MCC用テストベクタ


csv

SPILS実行結果

OK/NG

BTB結果

OK/NG

BTB結果

プロファイル作成

カバレッジ測定

ECUソフトウェア

$走行中

$ロックしない

P

Q

PならばQ

要件モデル（Cソース）

SLP

BTC様 EmbeddedTester C-Observer

要件記述

要件記述から要件モデルを自動生成

現時点の最適解か。。。



vECU-MBD WG

■ ISIT・STARC中心

■ 仮想ECUモデル有効活用に向けた有志活動



バーチャルECU（マイコンシミュレータ）による動作確認

赤：HILS

外部入力信号の丸め処理の調整だけで、合わせ込みが可能

青：シミュレーション出力 ■HILSと同じ動きをするバーチャルECU （ガイオ事例）



モデル流通TFについて

■ 仮想ECUモデル流通のためのガイドラインを作成



ISO26262-6で推奨される故障注入テスト

■ 表１０－ソフトウェアユニットテスト手法

手法 ASIL

A B C D

1a 要件ベーステスト ++ ++ ++ ++


1c 故障注入テスト + + + ++

1d リソース使用テスト + + + ++

1e 該当する場合には、モデルとコードとのBTBテスト + + ++ ++

■ 表１３ ― ソフトウェア結合テスト手法

手法 ASIL

A B C D

1a 要件ベーステスト ++ ++ ++ ++


1c 故障注入テスト + + ++ ++

1d リソース使用テスト + + + ++

1e 該当する場合には、モデルとコードとのBTBテスト + + ++ ++



関連用語

開発時稼動時

欠陥

故障モード

欠陥（Defect）

故障モード（Failure Mode）

フォールト（fault）

異常（Error）

（残存欠陥）

部品レベルの故障

部品レベルの故障

故障（Failure）

システムレベルの故障

システムレベルの故障

潜在的潜在的顕在的

デュアルポイント故障

シングルポイント故障

部品レベルの故障システムレベルの故障

マルチポイント故障

フォールト

マルチポイントフォールト

デュアルポイントフォールト

潜在的フォールト（latent fault）

※青字の用語はISO/DIS 26262で定義 ※本書ではFault=「故障／障害」としている

「故障モード、欠陥、フォールト、そして故障」の定義各規格で定義が異なるので注意必要。

異常状態

経年・経時変化（断線,固着,…）

顕在化



INT

故障モードが発生する場所

ECU

LAN

ROM RAM CPU

周辺機能 A/D WDT

ECU回路マイコン故障診断

入出力ポート

電源IC

サブマイコン

ロジックIC メモリ通信

ﾄﾗﾝｼｰﾊﾞ

fault 検出機構

reset

DF

DF

FMC1

FMC２ FMC0

FME2

FME3

FME0

FME1

fault 検出機構

FMC3

※DF: detected fault

FME4

+

フェールセーフ処理

故障注入テストの目的故障注入対象テスト指標

アプリケーションソフト（フェールセーフ機能）の検証

・周辺デバイス・コード/関数/コールカバレッジ

故障診断プログラムの評価・プロセッサ回路・ECU回路

・HW故障検出率



FIシミュレータの操作対象（3種類）

(故障モード・欠陥) (検出結果)

FMC0 FMC1 FMC2 FMC3 FMCn FME0 FME1 FME2 FME3 FMEn

DF0 DF1 DF2 DF3 DF4 DFm

回路断線・メモリ固着など

故障モード・欠陥を HW/SWで検出

(検出機構）

操作１

操作２

操作３操作

検出の結果が、割込み・SFR・メモリなどに反映される

操作操作

（マイコン外の故障モード）

（マイコン内の故障モード）

マイコンメーカが仕様決定

＜故障処理の流れ＞ (フェールセーフ処理)

対象操作機能（例一部）

メモリ値、レジスター値、ポート

指定されたタイミングで、指定されたレジスタ、指定されたアドレス範囲のメモリの値、または、指定されたポートを固着する/変更値を設定する。

実行指定されたタイミングにおいて指定されたアドレスで実行を抑制する

指定されたアドレス範囲と回数の間、指定されたオペコードは、NOPとみなす。

割込み指定されたタイミングにおいてエラー/例外割り込みを生成する.

指定されたタイミングで指定された割り込みを抑制する、あるいは、継続させる。

通信指定されたタイミングにおいて応答を抑制／遅延させる。

指定されたタイミングにおいて各フラグをセット／クリアする

指定されたタイミングにおいて指定された（イリーガルな）メッセージによって応答する。

メッセージの伝達順序を変更する



FIシミュレータを使った故障注入テスト

■ SRS故障注入検証に利用 ■ 他、ボデー電装系や音振制御、CAN通信検証、割込

み負荷テストなどの例も

専用ビューアーにより、・エアバッグの爆発順序・タイミング・アラーム点燈を確認

リファレンスデータ

シミュレーション結果ロギンｸﾞ

自動比較

故障設定GUI

決定

Cancel

初期化

点火デバイス１入力名設定

システムシミュレータ GUI エディタ

操作記述



割込みカバレッジとは？

■「割込みテスト基準」とは、割込みがどの程度テストできているかを表す指標

■どのような割込みテストをしていますか？ • 「割込み単体テスト→割込み処理部時間実測→机上で論理検証(WCET)→実機

使って確認」といった手順？ ―品質確認として十分ですか？

• 耐久テストだけで済ませていませんか？

■再現可能なイベント網羅検証器・割込み対する制御ソフトの堅牢性の検証を可能にします・シミュレータ使用により、確実に現象を再現し、問題特定を素早くできます

コンセプト ★機能・割込み条件（割込む箇所等）を詳細に設定可能・割込み自動生成可能・耐久テスト可能・割込みカバレッジ測定可能

※マイコンシミュレータを利用して実現



割込みテストの実施例

■特定箇所での割込み動作の確認 • 過去事例の確認 • 割込優先順位の妥当性の確認 • 未使用割込みの発生時の動作 • スリープ/ウェイクアップ（繰り返し）動作の確認 • 割込みによるスタック破壊の確認 • DI/EI処理漏れの確認

■不特定箇所で発生する割込み動作の確認

• 思わぬ箇所での割込み発生時の動作確認 ―割込みタイミング

» １日１回発生する ←耐久テスト • 通信系割り込みは、通信タイミングを変更して確認

■コードカバレッジ結果により割込み検査レベルの確認



国際学会で割込カバレッジを発表（名古屋大学＆GAIO）



「割り込まれる側」リソースに着目した割込みポイント

(1) 全共有リソース網羅

(2) 全割込みポイント網羅

ＡＡＢ

A, B：共有リソースアクセスタイミング：割込みテストポイント

グラフの縦線が命令。

実行系列１

実行系列２

ＡＡ

ＡＡＢ実行系列１

実行系列２

ＡＡ



■ 各処理毎の実行系列の選び方として、以下が挙げられる

• (a) 各共有リソースをアクセスする実行系列（パス）を１個網羅する ―例えば、ある割込み処理が２つの共有リソースA、Bにアクセスするならば、いず

れに関しても１回は通る（A11かA12どちらか + B1） • (b) 各共有リソースにアクセスする実行パスを全て網羅する

―共有リソースアクセスする実行パス全て（→ A11 ＋ A12 ＋ B1） • (c) （全ての組み合わせ、多重まで網羅する）

―詳細は議論中 » 要因、回数、順序など

「割り込む側」実行系列の選び方

■多重割込みは必要か？多重割込みはシステムの割込み優先順位の問題とすれば、ソフトウェア観点の割込みカバレッジとしては不要?

A12

A11

B1

要因１の割込みハンドラ



割込みテスト基準

78

（割り込む側）

実行系列

（割り込まれる側）

割込みポイント

(b) 各共有リソースにアクセスする実行パスを全て網羅

(c) （多重網羅、詳細は検討中）

(1) 全共有リソース網羅 I0 I2 (検討中)

(2) 全割込みポイント網羅

I1 I3 (検討中)

%100´=総数カバレッジアイテムの

イテムの数実行したカバレッジアカバレッジ



Save/load

Cause interrupt

Information on behavior of interrupt Show

Setting

Tool chain of interrupt testing

Log Infomations

Test events manager

Interrupt condition

Log viewer

Configuration on interrupt condition

(executes interrupt scenario)

Save/load

Calculate and view coverage

Interrupt testing

coverage

●class of interrupt ●Timing of interrupt ●interrupt testing point

●Event log ●Coverage information

Application code

② ③

⑤

⑥

⑦

⑧

・・・

Register Memory SFR

Interrupt handling module

Module (OS independent

Task1

OS

Taskn

Shared resources

Software

●Test case for interupt handling module

Input test case for interrupt handling modules

④

SystemSimulator

Handler code

Interrupting test point will be identified automatically

①

（例） I0: 100% I1: 90%

※シミュレータだから実現可能！



協賛会社募集中

■ 「割込みカバレッジ」は、難しい課題であり、まだ検討が必要

■ 日本発の規格をつくりませんか？

■ 参加者募集

• アドバイザ • ツール評価



５．まとめ



まとめ

■ グローバル化、MBD化が進む開発で使用するツールの状況

• コードベース開発の時代より、高度化されたツール • 多種多様なツールを使いこなさないとならない時代 • 機能安全用大量のエビデンスを作成・管理するためにもツールを使わなければ

対応できない • ツール自体の信頼性も求められる • ツールは単独で動作するのではなく、ツール間の連携が必要となる

―個別ツールより、ツールチェーンとして整備

■ 進化途上で、これからも期待される機能がある

■ 海外ツールメーカに負けないよう、日本ツールメーカも頑張りたい

• グローバルな活動 • 日本から国際的規格を発信



ご清聴有難うございました

※会社名・商品名は各社の商標または登録商標です。 ※本テキストの内容は、予告無く変更される場合があります。 ※本書記載の誤りにより生じる問題や損失に対して弊社は

責任を負いません。 ※本資料の無断転載、複写はお断りします。

ガイオ・テクノロジー株式会社日本橋事業所営業部〒103-0013 東京都中央区日本橋人形町3-12-8

TEL.（03）3662-3041 FAX.（03）3662-3043 Email info＠gaio.co.jp ・・ご質問はこちらにお願いします。

isit 第10回 カーエレクトロニクス研究会 『グローバル化とmbd...

Documents

isit 第10回カーエレクトロニクス研究会『グローバル化とmbd...