j-maab 制御仕様検証ガイドライン version 1jmaab.mathworks.jp/guidelines_v1_0.pdf · 1.2...

CONFIDENTIAL

J-MAAB

制御仕様検証ガイドライン

Version 1.0

2009 年 6 月 2 日

J-MAAB 制御仕様検証 WG


CONFIDENTIAL

変更履歴

Revision 日付内容作成者

1.0 09/6/2 ガイドライン正式リリースホンダ

制御仕様検証ガイドライン 3


CONFIDENTIAL

目次

1 はじめに ............................................................................ 5

1.1 背景 ............................................................................. 5

1.2 制御仕様検証ガイドライン策定目的 ................................................. 5

1.3 制御仕様検証ガイドラインの取り扱いについて ....................................... 6

1.3.1 ガイドラインの公開 ........................................................... 6

1.3.2 ガイドラインのメンテナンス ................................................... 6

2 概要 ................................................................................ 7

2.1 J-MAAB 制御仕様検証ガイドラインとは .............................................. 7

2.2 要求仕様と Simulink モデル仕様の一致性確認の考え方 ................................ 8

3 ガイドライン構成 .................................................................... 9

3.1 制御仕様検証プロセス定義 ......................................................... 9

3.2 検証ドキュメントガイドライン定義 ................................................. 9

4 制御仕様検証プロセス定義の詳細 ...................................................... 11

4.1 制御仕様検証プロセス図 .......................................................... 11

4.2 各プロセスの説明 ................................................................ 12

4.2.1 要求分析プロセス ............................................................ 12

4.2.2 構造設計プロセス ............................................................ 15

4.2.3 制御設計プロセス ............................................................ 18

4.2.4 検証設計プロセス ............................................................ 19

4.2.5 テストベクタ作成 ............................................................ 24

4.2.6 シミュレーション検証モデル作成 .............................................. 25

4.2.7 シミュレーション検証プロセス ................................................ 29

4.2.8 命題モデル作成 .............................................................. 30

4.2.9 プロパティ検証モデル作成 .................................................... 31

4.2.10 プロパティ検証 .............................................................. 33

4.2.11 検証レポート作成 ............................................................ 34

5 検証ドキュメントの詳細 ............................................................. 35

5.1 要求仕様書 ...................................................................... 35

5.1.1 システム要求仕様書 .......................................................... 35

5.1.2 制御モデル要求仕様書 ........................................................ 35

5.1.3 システム構成図 .............................................................. 35

5.1.4 ユースケース図 .............................................................. 35

5.1.5 タイミングチャート .......................................................... 35



CONFIDENTIAL

5.1.6 制御構成図 .................................................................. 36

5.1.7 状態遷移図 .................................................................. 36

5.1.8 状態遷移表 .................................................................. 36

5.1.9 制御フロー図 ................................................................ 36

5.1.10 構造設計書 .................................................................. 36

5.2 制御モデル ...................................................................... 37

5.2.1 制御仕様 Simulink モデル ..................................................... 37

5.3 検証仕様書 ...................................................................... 37

5.3.1 検証構想書 .................................................................. 37

5.3.2 検証仕様書（S） ............................................................. 37

5.3.3 検証仕様書（P） ............................................................. 37

5.3.4 検証項目管理表（S） ......................................................... 37

5.3.5 検証項目管理表（P） ......................................................... 38

5.4 検証モデル ...................................................................... 38

5.4.1 テストベクタ ................................................................ 38

5.4.2 命題モデル .................................................................. 38

5.4.3 シミュレーション検証モデル .................................................. 38

5.4.4 プロパティ検証モデル ........................................................ 38

5.5 検証結果 ........................................................................ 38

5.5.1 検証結果表（S） ............................................................. 38

5.5.2 検証結果表（P） ............................................................. 39

5.5.3 検証レポート ................................................................ 39



CONFIDENTIAL

1 はじめに

1.1 背景

自動車業界において制御仕様開発を効率的に行うために MATLAB/Simulink が広く使われるよう

になってきている。しかし MATLAB/Simulink の機能が十分ではなく、効率化できていない制御仕様

開発プロセスが存在していることも事実である。

J-MAAB では MATLAB/Simulink を使った実行可能制御仕様書を用いた制御仕様開発手法を用いれ

ば、品質が高くなる可能性があると考えた。この内容が実践できれば Cコードを直接得ることがで

きるので、制御仕様から Cコードへの設計工程での誤解によるミスが少なくなり品質が向上すると

考えられていた。しかし、抜本的に「要求仕様どおりの制御仕様が実現できているのか？」と言う

問題については改善されておらず、現状のモデルベース開発を実践してもミスが０になっているわ

けでは無かった。

2007 年 R2007a のリリース時に Simulink Design Verifier（以降 SLDV）が登場した事により、

この問題解決の糸口がつかめた。そこで、J-MAAB では SLDV を用いた制御仕様書の検証手法検討に

着手し本ガイドラインをまとめるまでに至った。

J-MAAB 制御仕様検証 WG メンバー：

アイシンＡＷ、アイシン精機、アドヴィックス、いすゞ、ジヤトコ、スズキ、デンソー、トヨタ、

日立製作所、富士重工、本田技術研究所、マツダ、ミツバ、三菱自動車（50 音順）

WG 事務局：サイバネットシステム株式会社

1.2 制御仕様検証ガイドライン策定目的

本ガイドラインは、Simulink モデル仕様書が要求と一致するかを検証するための手法を示すこ

とを目的とし、SLDV を用いたプロパティ検証、及びシミュレーションによる制御仕様の検証手法

を提案する。

要求書から作った制御仕様モデルと、要求書から作った検証観点を盛り込んだ要求仕様検査モデ

ルを合体させ、制御仕様書が要求書と一致していることを証明する。ただし、どの様にして制御仕

様モデルを作成し、どの様にして要求仕様検証モデルを作成するのかは、ケースバイケースとなり、

正しい手法を一概に決めることができない。そこで本ガイドラインでは、数例の参考例を提示する

にとどめる。

本ガイドラインは制御仕様検証業務の基本形を示すもので制御仕様検証業務そのものを保証す

るものではない。従って、実際の業務を進めていく為には各ビジネスモデルに合わせた最適化が必

要である。



CONFIDENTIAL

1.3 制御仕様検証ガイドラインの取り扱いについて

1.3.1 ガイドラインの公開

‘09/6 version 1.0 初版公開

1.3.2 ガイドラインのメンテナンス

改訂の時期----- 必要に応じて見直しを実施（1回／年）

改訂の方法----- メンバーからのフィードバックを株式会社本田技術研究所で取りまと

め The MathWorks Japan に送付

メンテナンス担当者----- The MathWorks Japan

メンバーからのフィードバック窓口-----株式会社本田技術研究所



CONFIDENTIAL

2 概要

2.1 J-MAAB 制御仕様検証ガイドラインとは

本ガイドラインは、図 1に示す制御開発のＶプロセスにおいて、左上の制御仕様検討領域にフォ

ーカスし、要求仕様書を入力とし、要求仕様書との一致性が検証された Simulink モデル仕様書（制

御モデル）を出力として想定した制御仕様検討プロセスとドキュメントの関連をガイドラインとし

て定義したものである。

以下に本ガイドライン作成の目的項目を示す。

要求仕様書と Simulink モデル仕様書の一致性を検証するための基本プロセスの明確化

上記一致性検証のためのテスト仕様書記述ガイドラインの明確化

検証作業を進める為に必要となる情報やドキュメントの明確化

上記ドキュメントの記述内容の明確化

図 1 本ガイドランの適用対象となる制御開発 Vプロセスの上層部分

要求分析

要求仕様書

検証モデルの記述方法ガイド

ドキュメントの記述内容の明確化

テスト仕様書

検証仕様書制御モデル

検証

制御モデル

設計

制御仕様検証プロセスの明確化

検証に必要となるドキュメントの明確化

検証結果報告書

制御モデル

現物テスト



CONFIDENTIAL

2.2 要求仕様と Simulink モデル仕様の一致性確認の考え方

大半の要求仕様書は自然言語（文字ベース）で記載されている。自然言語で記載された要求仕様

書には、抜け漏れや矛盾が含まれていたとしても、作成された時点で全てを完全な形に修正するこ

とは難しい。要求仕様書に抜け漏れや矛盾が含まれていても、制御設計を行う際にはそれに気付か

ず、制御仕様（Simulink モデル仕様書）が作成されることもある。本ガイドラインでは、真の要

求を基に要求分析を行い要求仕様書を作成し、これをもとに Simulink モデル仕様書（制御モデル）

と検証仕様書を並行して作成するプロセスを提案している。

制御設計を行う中では見落としてしまうような要求仕様書の抜け漏れや矛盾も、検証設計を行う

ことで気が付くことが多いと考える。抜け漏れや矛盾を排除した要求仕様書を基に本ガイドライン

に示すような検証を実施することで、要求仕様と Simulink モデルの一致性が確認でき、これらを

並行して実施することで、制御設計のやり直しが少なくなるものと考える。

本ガイドラインでは、プロセス上での必要となる補助的ドキュメントについても概要を記載して

いる。これらの最適な活用は各ビジネスモデルに合わせた最適化が必要であることをご注意頂きた

い。

また、制御仕様検証の領域としては、図 2に示すようなシステムレベルやモジュールレベルとい

った階層の違いで要求仕様書が存在する場合も考えられるが、本ガイドラインではこの様な階層に

依存しない共通的な制御仕様検証プロセスとドキュメントの関連を対象としている。

図 2 要求仕様書及び Simulink モデル仕様書の階層

要求分析

システム

テスト仕様書

システムテスト

モジュール

テスト仕様書

モジュールテスト

システム

要求仕様書

モジュールレベル

Simulinkモデル仕様書

システム制御設計

システムレベル

Simulinkモデル仕様書

モジュール

要求仕様書

モジュール制御設計



CONFIDENTIAL

3 ガイドライン構成

3.1 制御仕様検証プロセス定義

本ガイドラインでは、制御仕様検証作業に至るまでを、大きく以下の５つのプロセスとして分類

した。

① 要求分析プロセス

② 制御モデル設計プロセス

③ 制御モデル検証設計プロセス

④ 検証モデル設計プロセス

⑤ 制御モデル検証プロセス

また、各プロセスの関連を検証プロセス図として定義した。（図 3参照）

3.2 検証ドキュメントガイドライン定義

検証作業を進める上で必要となる資料や検証作業の結果として作成されるドキュメントの記述

についての定義で、以下に示すものが含まれる。

①要求仕様書

システム要求仕様書

制御モデル要求仕様書

システム構成図

ユースケース図

タイミングチャート

制御構成図

状態遷移図

状態遷移表

制御フロー図

構造設計書

②制御モデル

制御仕様 Simulink モデル

③検証仕様書

検証構想書

シミュレーションによる検証仕様書（以降、検証仕様書（S））

SLDV（プロパティ検証）による検証仕様書（以降、検証仕様書（P））

シミュレーションによる検証項目管理表（以降、検証項目管理表（S））

SLDV（プロパティ検証）による検証項目管理表（以降、検証項目管理表（P））

④検証モデル

テストベクタ



CONFIDENTIAL

命題モデル

シミュレーション検証モデル

プロパティ検証モデル

⑤検証結果

検証結果表（S）

検証結果表（P）

検証レポート



CONFIDENTIAL

4 制御仕様検証プロセス定義の詳細

4.1 制御仕様検証プロセス図

制御仕様検証プロセスを図式化したものを以下に示す。

図 3 制御仕様検証プロセス図



CONFIDENTIAL

4.2 各プロセスの説明

以下に各プロセスでの作業概要を記述する。

4.2.1 要求分析プロセス

要求をもとに、システムとして実現が求められる項目を明確にし、要求仕様書としてまとめる為

のプロセス。

当該製品を実現するために、システムとして実現が必要となる要求を明確にし、システム要求仕

様書を作成する。このシステム要求仕様書に基づき、制御モデルに求められる要求を明確にし、制

御モデル要求仕様書を作成する。

【実施内容】

① 要件抽出

製品の要求仕様を把握し、システムにおける機能面・非機能面の要求、動作条件、制約条

件を分析して明確にする。要件抽出では、ユースケース図などを用いて要求を整理するとよ

い。またシステム要求分析、制御モデル要求分析を行う過程で要求の抜け漏れが見つかった

場合や、顧客要望（ニーズ）に変更があった場合にも要件抽出に戻り、あらためて他の要求

への影響も含めて再抽出を行う。

【入力】

顧客ニーズ

開発課題

技術資料

製品企画書

製品仕様書等

【概要】

【出力】

システム要求仕様書

システム構成図

ユースケース図

制御構成図

状態遷移図

制御フロー図等

① 要件抽出

② システム要求分析

③ 制御モデル要求分析

参考情報：SEC ESPR v2.0、 SWP2 SWP3

Automotive SPICE Automotive SIG PAM v22_J.pdf ENG.5

SESSAME、要求を仕様化する技術



CONFIDENTIAL

図 4 ユースケース図の例

② システム要求分析

システムの要求事項を整理し、システム要求仕様書を作成する。システム要求仕様書には、

システム外部との関連性（インターフェース）、ハード・ソフト（制御モデル）で実現する

要求を明確に記載する必要がある。このため要求仕様書を書き出す前に、システム全体の構

成を図解して詳細を定義するとよい。システム全体の構成を図解・定義するとき、FMEA

などの検討も実施し、結果をシステムの要求仕様に反映する。

図 5 システム構成図の例



CONFIDENTIAL

システム要求仕様書、制御モデル要求仕様書は、SESSAME「話題沸騰ポット GOMA-1015 型

要求仕様書」の例のように、可能な限り曖昧さを含まないように記述すること。また、シス

テム要求仕様書では、ハードウェアに対する要求とソフトウェア（制御モデル）に対する

要求について、どちらでどこまで実現するのか分担を明確にすること。また外部とのインタ

ーフェースを明確にすること。

（補足）SESSAME「話題沸騰ポット GOMA-1015 型要求仕様書」とは？

特定非営利活動法人組込みソフトウェア管理者･技術者育成研究会（SESSAME）による、

組込みシステム教育教材。この要求仕様書をもとに電子ポットシステムを分析・設計して、

組込みソフトウェア技術者の実践的教育に活用している。

③ 制御モデル要求分析

システム要求仕様書をもとに、ソフトウェア（制御モデル）で実現が必要となる要求を明

確にして、制御モデル要求仕様書を作成する。

図 6 要求仕様書の記載例

【注意点】

要求仕様書では、要求範囲や動きを明確にし、要求と仕様の関連付けがはっきりわかるよ

うに記載する。（SESSAME 例題を参考）

また自然言語での記載が推奨されているが、間違いのない明確な記載を追求すると作成に

時間がかかるため、「仕様」については各社で推奨するソフト仕様書の記載方法や、

Simulink/Stateflow モデル画像の貼り付けなど、作成期間を短縮できるように工夫すると

よい。

要求仕様書を作成するときに、状態遷移図や制御フロー図を作成して整理しておくとわか

りやすい要求仕様書になりやすく、また、これらの資料は後の検証設計でも活用することが



CONFIDENTIAL

できる。

4.2.2 構造設計プロセス

要求仕様書をもとに、制御システムの構造、構成要素の抽出・整理、構成要素間のインターフェ

ース設計を実施するプロセス。

【実施内容】

要求仕様書を元に、実現すべき機能、非機能要求を確認し、それを実現する為の振る舞い

とシステム全体構成を検討する。また、制御モデル構成として、最上位構造、及び再利用可

能な制御モデル構成要素を含む、構成として整理する。

- 共通する処理などを局所化、共通化を図りながら、制御システム構成要素を抽出す

る。

- 制御システム全体としての振る舞いを考え、構造を設計する。

- 個別の制御モデル構成要素が実現する内容を明確にする。

- 個別の制御モデル構成要素間とのインターフェースを設計する。

構造設計した時点で、構造設計書を、共同レビューし、実現方法・構造設計の妥当性を確

認することが望ましい。

【注意点】

制御モデル設計時は、以下に注意する。

- 保守性、開発効率、テスト効率性、信頼性、拡張性、安全性を考慮して設計

- 制御モデル検証を考慮した構成設計、機能分割になっていること

【入力】

要求仕様書

【参考】

-システム要求仕様書

-システム構成図

-ユースケース図

-制御構成図

-状態遷移図

-制御フロー図

-ハードウェア仕様書

等

【概要】

【出力】

構造設計書

・構造設計



CONFIDENTIAL

- 共通する処理など、局所化／共通化を図り、制御モデル構成要素を設計

【参考】

構造設計書（ドキュメント例：パワーウィンドウシステムの場合）

制御モデル全体構造

システム全体構造モデル



CONFIDENTIAL

制御モデル構成要素が実現する内容及びインターフェース（入出力）

制御モデル構成要素



CONFIDENTIAL

4.2.3 制御設計プロセス

構造設計書をもとに、制御モデルを詳細設計するプロセス。

【実施内容】

・制御モデル詳細設計

構造設計で定義された、個別の制御モデル構成要素で実現すべき機能を、詳細設計する。

個別の制御モデル構成要素を設計した時点で、処理内容の正しさ、構成要素間のインター

フェースの整合性含め、共同レビューするのが望ましい。

（本ガイドラインでは作成された制御モデルの一致性検証手法について記述するため、制

御モデル自身の作成プロセス詳細については言及しないこととする。）

【概要】

【入力】

構造設計書

【参考】

-システム要求仕様書

-システム構成図

-ユースケース図

-制御構成図

-状態遷移図

-制御フロー図

-ハードウェア仕様書

等

【出力】

制御モデル

・制御モデル詳細設計



CONFIDENTIAL

【概要】

4.2.4 検証設計プロセス

要求分析/構造設計プロセスで得られた要求仕様書/構造設計書をもとに、制御モデルとして実現

が求められる事項が正しく実装されているか検証するための仕様書を作成するプロセス。検証方法

の選定（シミュレーション検証/プロパティ検証）は本プロセスで行う。

（１）検証方法の選定

【解説】

① 検証方法は下記 2点に大別される。

・シミュレーション検証

Signal Builder ブロック等を使用してテストベクタを作成する検証方法。テストハーネス

モデルは、SLDV の自動テスト生成機能で作成するモデルと Signal Builder ブロックから

直接作成するモデルの 2種類がある。

・プロパティ検証

Verification Subsystem ブロックを使用して検証命題を記述する検証方法。形式検証技術

により、要求仕様書／構造設計書と制御モデルの一致性を検証する。

② 検証内容は下記の観点で分析する。

・一致性検証（Verification、仕様=検証）

正しく制御モデルが作成されているか検証する。すなわち、要求仕様通りに制御モデルが

【入力】

要求仕様書

構造設計書

【出力】

検証構想書

【概要】

要求仕様書/構造設計書を分析し、

検証の観点や起こりうる事象をま

とめ、シミュレーション検証とプロ

パティ検証の構想をまとめる。

(1) 検証方法の選定

【入力】

要求仕様書

構造設計書

【出力】

検証仕様書（S）

検証仕様書（P）

(2) 検証仕様書(S)の作成

(3) 検証仕様書(P)の作成



CONFIDENTIAL

作成されているか開発者の見地から検証する。

・妥当性検証（Validation、仕様⊆検証）

正しい制御モデルが作成されているか検証する。すなわち、要求仕様を満足する制御モデ

ルになっているかユーザーの見地から検証する。

・瞬間の検証（論理）／時間軸の検証（様相）

【実施内容】

分析した検証内容に対し、より適した検証方法を選定する。

選定の基準については特に規定しないが、参考として下記に目安を記す。

・一致性検証は、いずれの検証方法も有効。

・妥当性検証は、仕様を抱合する形で検証用命題を設定できるプロパティ検証が有効だが、

抜け漏れなく合否判定基準が設定できればシミュレーション検証も有効。

・瞬間の検証は、計算負荷が小さいプロパティ検証が有効。

・時間軸の検証は、計算負荷が指数的に増加するため、プロパティ検証よりもシミュレーシ

ョン検証が有効。

【注意点】

プロパティ検証で一致性検証する場合、制御モデルと検証モデルとがほとんど同じ形になることが

ある。できれば、制御モデルと検証モデルとで表現の手段を変えると良い。

（例）制御モデル：Simulink、検証モデル：TruthTable

参考に、検証の種類ごとの特徴と難易度を、下記の表にまとめる。

②

妥当性の検証

（仕様⊆検証）

・・・出力がある範囲内（外）かどうか

①

一致性の検証

（仕様＝検証）

・・・計算式・論理式どおりの出力となっているかどうか

B

瞬間の検証（論理）

A

時間軸の検証（様相）

②

妥当性の検証



①

一致性の検証



B


A


SLDVでカウンタ使用

SLDVでカウンタ未使用

※カウンタの検証を除外

仕様と検証が同じ表現

仕様と検証が異なる表現

シミュレーション検証

（テストハーネス）

図 7 検証の種類と特徴



CONFIDENTIAL

②

妥当性の検証



①

一致性の検証



B


A


②

妥当性の検証



①

一致性の検証



B


A


・要求から作成する検証命題・仕様が包含されるような検証命題

・計算時間大

・表現を工夫

難

易

やや難

ツールの問題

人間の頭の問題

やや難

図 8 検証の種類と難易度

（２）検証仕様書（S）の作成

起こりうる事象の中で検証する事象を決定し、検証項目を「入力が Xのときの出力は Y」の形で文

章やタイミングチャートでまとめ、検証仕様書（S）を作成する。

【実施内容】

① 要求仕様書／構造設計書をもとにシミュレーション検証として選定した検証項目を作成する。

検証項目の内容としては以下のようなものを考えるとよい。

- ブラックボックステスト

- 正常動作、非正常動作に関するシステム全体の検証（エラー検証）

- 正常値入力、異常値入力に関するシステム全体の検証（フェールセーフ処理）

- 過去不具合

- 制御モデル不具合修正後のリグレッションテスト

② 個々の検証項目に関する合否判定の基準を明確にしておく。

③ 検証環境を整える。

- 使用するツール（MATLAB／Simulink／Stateflow／SLDV）のバージョン管理を整理する。

- 要求仕様書／構造設計書／制御モデル、それぞれのバージョン管理を整理する。

【入力】

検証構想書

要求仕様書

構造設計書

【出力】

検証仕様書（S）

検証項目管理表（S）

【概要】

シミュレーション検証を実施する

ために必要な検証項目や環境を検

証仕様書（S）としてまとめる。



CONFIDENTIAL

- 各タスクの責任所在を明確にしておく。

- プラントモデルを接続する場合は、予め準備しておく。

④ 上記を検証仕様書（S）としてまとめる。

【注意点】

・状態遷移表・マトリックス網羅法等を用い、漏れのない検証項目を作成する。

・検出された不具合は、各社の不具合管理の手順・ルールに従い、適切に管理すること。制

御モデル作成者が検証項目を検討している場合は、特に検証項目の抽出や合否判定基準が

甘くないか注意する。

（３）検証仕様書（P）の作成

起こりうる事象の中で検証する事象を決定し、検証項目として「Aならば B」の文章でまとめ、検

証仕様書（P）を作成する。

【実施内容】

① 要求仕様書／構造設計書をもとにプロパティ検証として選定した検証項目を作成する。検証項

目の内容としては以下のようなものを考えるとよい。

- 要求仕様書に記載されている機能の網羅的な検証

- 正常動作、非正常動作に関する検証（エラー検証）

- 正常値入力、異常値入力に関する検証（フェールセーフ処理）

- 過去不具合

- 制御モデル不具合修正後のリグレッションテスト

② 個々の検証項目に関する合否判定の基準を明確にしておく。

③ 検証環境を整える。

- 使用するツール（MATLAB／Simulink／Stateflow／SLDV）のバージョン管理を整理する。

- 要求仕様書／構造設計書／制御モデル、それぞれのバージョン管理を整理する。

- 各タスクの責任所在を明確にしておく。

④ 上記を検証仕様書（P）としてまとめる。

【入力】

検証構想書

要求仕様書

構造設計書

【出力】

検証仕様書（P）

検証項目管理表（P）

【概要】

プロパティ検証を実施するために

必要な検証項目や環境を検証仕様

書（P）としてまとめる。



CONFIDENTIAL

【注意点】

・状態遷移表・マトリックス網羅法等を用い、漏れのない検証項目を作成する。

・検出された不具合は、各社の不具合管理の手順・ルールに従い、適切に管理すること。制

御モデル作成者が検証項目を検討している場合は、特に検証項目の抽出や合否判定基準が

甘くないか注意する。



CONFIDENTIAL

4.2.5 テストベクタ作成

テストベクタ作成とは、シミュレーション検証モデル作成の準備で、制御モデル作成と並行して

実施可能な事を想定している

【実施内容】

・テストベクタの作成

検証仕様書の入力信号と期待する出力信号を発生するブロックを Signal Builder、From

workspace、または SLDV の自動テスト生成機能等を使って作成する。

・判定サブシステムの作成

シミュレーション検証モデル上で、制御モデル出力の確認（一致性／妥当性）を行う場合、

制御モデル出力と、期待する出力信号を比較し、要求を満たすか判定する判定サブシステ

ムを作成する。Simulink/Model Verification ブロックを活用できる。

【注意点】

・テストベクタと制御モデルの結合が円滑に進むように、テストベクタ、判定サブシステム、

プラントモデルの制御モデルとの接続部分の信号名、ポート名、型を制御モデルと合わせ

る。

【入力】

検証仕様書(Ｓ)

【概要】

検証仕様書(Ｓ)に従い、テストベクタ

を作成する。

【出力】

テストベクタ



CONFIDENTIAL

4.2.6 シミュレーション検証モデル作成

【実施内容】

・ Signal Builder などを使用して作成したテストベクタと検証対象の制御モデルを結線する。

・テストベクタの期待値と制御モデルの出力の一致性を判断するロジックを Relational

Operator ブロックなどを用いて作成する．

・一致性の判断結果を Assertion ブロックに結線する。

【入力】

検証仕様書(Ｓ)

テストベクタ

制御モデル

【概要】

テストベクタと制御モデルを結合し、

シミュレーション検証モデルを作成

する。

【出力】

シミュレーション検証モ

デル



CONFIDENTIAL

【シミュレーション検証モデルの構成】

シミュレーション検証モデルは、色々なパターンがあるが、

テスト対象部分

テスト対象への入力信号と期待する出力信号を発生する信号発生部分

テスト対象の出力信号を、期待する出力と比較し要求仕様を満足するか確認する判定部分

の３つ部分に分ける事ができる。

シミュレーション検証モデルのテスト対象部分、信号発生部分、判定部分の機能とモデル化につい

て以下に解説する。

【テスト対象部分】

・制御モデル

・制御モデル＋プラントモデル

制御モデルの振る舞いを、制御モデルとプラントモデルを結合したシステムで検証する場合、

プラントモデルが必要になる。プラントモデルの妥当性は確認済みである事が必要

【信号発生部分】

テスト対象への入力信号と期待する出力信号を発生する。

テスト対象への入力信号の種類

・手動編集データ

・自動生成データ検証ツールで生成

・過去のデータ過去の実験／シミュレーションのデータ

・プラントモデル出力

・上記信号の組み合わせ

入力信号に使用するブロックの種類

・Signal Builder

・From Workspace

・プラントモデル

・上記ブロックの組み合わせ

Input 1

Input 2

Expect

Signal Builder

==

RelationalOperator

Input 1

Input 2

Output

Controler Assertion

信号発生部分テスト対象部分判定部分



CONFIDENTIAL

期待する出力信号の種類

・手動編集データ

・過去のデータ過去の実験／シミュレーションのデータ

・基準モデル出力検証する要求の機能をモデルで表したもの

期待する出力信号に使用するブロックの種類

・Signal Builder

・From Workspace

・基準モデル

【判定部分】

テスト対象の出力と、期待する出力信号を比較し、要求を満たすか判定する。

判定する信号

・コントローラ出力

・プラント出力

判定方法の種類

・期待する出力に対して値が一致または、値が範囲内

・出力信号の変化時期

・上記の組み合わせ

判定に使用するブロック

・Simulink/Model Verification ブロック

・その他

判定期間シミュレーション実行中、設定期間で判定を実行するようにモデル化する。

【参考】

制御モデルのシミュレーション検証モデルは、下図のように色々なパターンがある。

1.制御モデル単体でのモデル妥当性/一致性確認制御モデル出力で判定

Verification of Controller

Verify Subsystem

y

Yexpected

Signal Builder

In1

In2

Yexpected

DoVerifyController

In1

In2yIn1

In2

Yexpected

DoVerify

Verify Subsystem

Scope

RelationalOperator

<=

Assertion

Enable

Yexpected

2

y

1

<y , Yexpected >

<y >

<Yexpected >

信号発生部分

判定部分




CONFIDENTIAL

2.システムにおける制御モデル妥当性/一致性確認制御モデル出力で判定

3.システムにおける制御モデル妥当性確認プラントモデル出力で判定

Validation of Pid Controller

Verify Subsystem

x

UpperLimit

LowerLimit

Trig 10ms

Signal Builder

Ref

UpperLimit

LowerLimit

DoVerifyPlant

u x

Controller

Ref

xuRef

UpperLimitUpperLimit

LowerLimitLowerLimit

DoVerify

Verify Subsystem

Scope

Check Dynamic Range

max

min

sig

Enable

LowerLimit

3

UpperLimit

2

x

1

<x, UpperLimit, LowerLimit>

<UpperLimit>

<LowerLimit>

<x>

制御モデル

信号発生部分

判定部分

プラントモデル

Verification of Feedback Controller

u_expected generator

In1

x

DoVerify

u_expected

Verify Subsystem

u

u_expected

Signal Builder

In1

Plant

u x

Controller

In1

xu

In1

信号発生部分

プラントモデル制御モデル

判定部分





CONFIDENTIAL

4.2.7 シミュレーション検証プロセス

要求事項が正しく実現されているか、テストベクタを使用して検証する為のプロセス。

検証仕様書に従い、シミュレーション検証を実施する。

【実施内容】

① 検証を実施する。

検証仕様書をもとにシミュレーション検証モデルを実行し、出力結果を得る。

② シミュレーション不具合がありテストベクタを修正した場合、以下の確認を行う。

・テストベクタが正しく修正されたか確認するため、再度シミュレーション検証を実施す

る。

・テストベクタの修正により、別の不具合が発生していないか確認を実施する。

③ 検証結果を検証レポートにまとめる。

・シミュレーション検証を実行した際に出力されるカバレッジレポート、および、

検証項目毎の OK/NG 結果の記録を含める。

【注意点】

・検証結果は個別のレポートとしてまとめても良いが、検証項目管理表への結果記入をも

ってレポートとしても良い。

【入力】

検証仕様書

検証項目管理表

シミュレーション検

証モデル

【概要】

【出力】

シミュレーション検証結

果（検証項目管理表）

① シミュレーション検証実施

② テストベクタ修正確認

③ 検証レポート作成



CONFIDENTIAL

4.2.8 命題モデル作成

【実施内容】

・ Simulink ブロック、或いは Stateflow のフローチャートや Truth Table などを使用し、検

証命題（ＡならばＢ）をモデルで表現する。

・検証仕様書の検証命題（ＡならばＢ）毎に、Ａ、Ｂ各々に対する表現の出力を implies ブ

ロックのＡ、Ｂ入力に結線し、implies ブロックの出力を Proof Objective ブロックまたは

Assertion ブロックに結線する。

・各検証命題（ＡならばＢ）の表現に前提条件がある場合は、Assumption ブロックを用いて

その条件（表現の入出力や中間値について取り得る値や値の範囲）を設定する。

【注意点】

・検証仕様書（P）に記されている全ての命題が間違いなくモデルで表現されていることを確

認することはもちろん、命題が前提条件の範囲内で起こりうる全ての事象（検証仕様書（P）

に“検証対象外の事象”が記されている場合は、その事象以外）を網羅していることを確

認することも必要。

・起こりうる全ての事象を網羅していない場合には検証設計に戻り、漏れている事象につい

ての命題を作成し、検証仕様書（P）を修正する。

En信号が立上った直後は、Flg信号は偽、かつ、Cnt信号はCV-1になる

A

B

A ==> B

impl i esz

1

X0 = 1

==

==

==

==AND

AND

0

CV-1

0

1

Assertion

3Cnt

2Flg

1En

図 9 命題モデルの例

【入力】

検証仕様書(P)

【概要】

検証仕様書に従い、命題モデルを作成

する。

【出力】

命題モデル



CONFIDENTIAL

4.2.9 プロパティ検証モデル作成

【実施内容】

・検証に必要な Assumption（前提条件）を設定する。

・制御モデルより、プロパティ検証に必要な線を確認する。

・ Assertion ブロック、または Proof Objective ブロックを接続する。

・検証に必要な箇所をすべて含む形で、制御モデルから該当箇所を抜き出す。

・制御モデルと命題モデルを合体させ、プロパティ検証実行用のモデルとして保存する。

（図 10 プロパティ検証モデル構成例参照）

【入力】

検証仕様書(P)、

制御モデル、

命題モデル

【概要】

検証対象の制御モデルと検証目的

を記述した命題モデルを結合し、プ

ロパティ検証モデルを作成する。

【出力】

プロパティ検証モデル



CONFIDENTIAL

図 10 プロパティ検証モデル構成例

（参考例 R2008b/sldvdemo_debounce_validprop.mdl）

制御モデル

検証モデル



CONFIDENTIAL

4.2.10 プロパティ検証

要求事項が正しく実現されているか検証する為のプロセス。

検証仕様書に従い、プロパティ検証を実施する

【実施内容】

① 検証を実施する。

検証仕様書をもとに検証を実施し、出力結果を得る。

- プロパティ検証モデルを実行する。

② 修正確認を実施する。

・不具合が発生し、それを修正した場合の確認として、不具合が解消されたか検証を実施

する。

・不具合の修正により、別の不具合が発生していないか検証を実施する。

③検証結果を検証レポートにまとめる。

・プロパティ検証を実行した結果の合否を判定し、その結果をレポートに記録する。

【注意点】



【入力】

検証仕様書


プロパティ検証モデ

ル

【概要】

【出力】

プロパティ検証結果（検証

項目管理表）

① 検証実施

・プロパティ検証実施



CONFIDENTIAL

4.2.11 検証レポート作成

検証結果をレポートにまとめる為のプロセス。

シミュレーション検証結果／プロパティ検証結果を確認し、それらを統合して検証レポートとし

てまとめる。

【実施内容】

① 検証結果確認・統合

シミュレーション検証結果／プロパティ検証結果を確認し、結果を統合する。

- 個々の検証についての合否判定結果を統合する。

- 検証設計プロセスにて振り分けられたそれぞれの検証結果を足し合わせると、すべ

ての検証項目が漏れなく実施されていることを確認する。

- 未実施となっている検証項目がある場合には、未実施となった理由を確認し、対応

を検討する。

② 検証レポート作成

結果をレポートにまとめる。

- 個々の検証についての合否判定結果を記述する。

- 検証不合格の項目について、問題点と対策を明記し、上流プロセス（構造設計、制

御モデル作成、検証設計）へ差し戻す。

- 修正確認を実施した場合、その結果も記述する。

【注意点】



【入力】

シミュレーション検

証結果

プロパティ検証結果

検証仕様書


【概要】

【出力】

検証レポート（検証項目管

理表）

① 検証結果確認・統合

② 検証レポート作成



CONFIDENTIAL

5 検証ドキュメントの詳細

5.1 要求仕様書

図 3 制御仕様検証プロセス図の「①要求分析」に含まれるドキュメント。

5.1.1 システム要求仕様書

システムとして実現が求められる、機能要求（システムの機能やシステムがなすべきこと）、非

機能要求（システムの備えるべき属性・・例えば、効率性、保守性、信頼性など）、制約条件など

を明確にし、記述したもの。

システム要求仕様書は、可能な限り曖昧さを含まないように記述すること。また、ハードウェア

に対する要求とソフトウェア（制御モデル）に対する要求について、どちらでどこまで実現する

のか分担を明確にすること。また外部とのインターフェースを明確にすること。

5.1.2 制御モデル要求仕様書

システム要求仕様書に基づき、制御モデルに求められる要求を明確に記述した仕様書。要求仕様

書では、要求範囲や動きを明確にし、要求と仕様の関連付けがはっきりわかるように記載する。自

然言語での記載の他に、ユースケース図、タイミングチャート、制御構成図、状態遷移図、制御フ

ロー図等を適時活用すると解りやすい要求仕様書になりやすく、検証設計でも活用することができ

る。

5.1.3 システム構成図

システム全体の構成（システムに包含される部品、接続、インターフェースなど）を図解したも

の。システム構成を詳細に図解・定義することで、システム要求仕様書の記載をより明確にでき、

またシステム要求仕様書を読む人の理解の助けとなる。

5.1.4 ユースケース図

UML（Unified Modeling Language：統一モデリング言語）で定義されている図のうちの 1 つで、

ユーザーのシステムに対する要求を表現する図。システムの振る舞いを表すユースケース（楕円）､

システムの外側にあってシステムと直接関係するアクター（人型）、ユースケースとアクターとの

つながりを示す関連（実線）、システムの範囲を示す境界（四角枠）で構成される。

ユースケース図を使うと、システムの外部と内部との境界をはっきりさせることができ、また、

ユーザーの視点からシステムについて見ることができるため、コミュニケーションが円滑になり、

要求に対する相互の理解の補助となる。

5.1.5 タイミングチャート

制御の各入出力や内部フラグなどの実行状態を、時間の経過とともに表したグラフ。制御を時系

列で定義したり、把握するのに有効なドキュメント。



CONFIDENTIAL

5.1.6 制御構成図

要求を満たす、制御の目的や、観点と、制御範囲、応答性、メモリー制限、計算速度などを考慮

し、最適などの様な制御方式を用いるか検討したドキュメント。

このドキュメントを見れば、制御の大枠が理解できる。

構想図には、制御方式、入出力の信号、時間的な流れ、全体の仕組み（モデル構造）等が含まれ

る。

制御方式とは、例えば、PID 制御を用いるのか、現代制御理論を用いるのか、

マップによって条件分けで実現するのか？

全体の仕組み（モデル構造）とは、どのモデルにどの様な機能を持たせるかを検討した構成図で

ある。

5.1.7 状態遷移図

有限な内部状態が入力に応じて動的に遷移するような事象のモデルである有限状態機械（有限オ

ートマトン）をグラフで表現したもの。ノードとエッジからなる有向グラフとして表現され、ノー

ドは状態を、エッジは状態間の遷移を意味する。入出力の扱いが異なる複数の形式が存在し、その

ひとつが UML ダイアグラムのひとつとして採用され、プログラムやプロセスなど様々な対象をモデ

リングに利用されている。

5.1.8 状態遷移表

状態遷移表（State Transition Table）は、有限状態機械（有限オートマトン）の遷移関数を記

述した表である。この関数は有限の状態から状態への遷移を制御するものである。状態遷移図から

状態遷移表を作成することが可能であり、その逆も可能である。

状態遷移表は、一般に二次元で、現在の状態とイベントにより次に遷移すべき状態を示すものと、

現在と次の状態からその遷移を発生させるイベントを示すものがある。

状態数が多い場合や、出力記述が多い場合に有効で、特定のイベントが発生した場合の状態遷移

について一覧できるようになる。

5.1.9 制御フロー図

制御フロー図とは、制御の流れを図で表したものである。処理順序を規定することに重要な意味

がある場合や、条件分岐等により処理の流れを変えることに重要な意味がある制御において必要と

なる。

5.1.10 構造設計書

構造設計プロセスのアウトプットとして作成された Simulink モデル。

構造設計書は、定義された機能の階層をサブシステムで記述したものであり、当該機能の入出力

と各機能（サブシステム）間のデータの流れは Inport ブロック、Outport ブロック、及び信号線

で記述されている。（16 ページ参照）



CONFIDENTIAL

JMAAB Simulink スタイルガイド jc_0301:コントローラモデルの構造レイヤまで書いたモデ

ルになる。（データフローレイヤ内の記述は、制御設計プロセスで行う。）

5.2 制御モデル

図 3 制御仕様検証プロセス図の「②制御モデル設計」に含まれるドキュメント。

5.2.1 制御仕様 Simulink モデル

制御仕様 Simulink モデルは、要求仕様に沿って自動車用制御装置の制御機能をブロック図形式

で記述したもので、検証対象となる。

制御仕様 Simulink モデルの記述については、J-MAAB Simulink 仕様書ガイドラインに準ずる。

5.3 検証仕様書

図 3 制御仕様検証プロセス図の「③制御モデル検証設計」に含まれるドキュメント。

5.3.1 検証構想書

検証の目的や観点、検証対象範囲等から要求仕様書/構造設計書を分析し、以下に示すような項

目についてまとめたドキュメント。

・検証対象と検証範囲の定義

・検証完了基準とその設定経緯

・使用する検証方法（シミュレーション検証/プロパティ検証）とその選定経緯

・検証の計画

5.3.2 検証仕様書（S）

要求仕様書/構造設計書をもとに、制御モデルとして実現が求められる事項が正しく実装されて

いるかシミュレーション検証するための仕様書。起こりうる事象の中で検証する事象を決定し、検

証項目を「入力が Xのときの出力は Y」の形で文章やタイミングチャートでまとめる。

5.3.3 検証仕様書（P）

要求仕様書/構造設計書をもとに、制御モデルとして実現が求められる事項が正しく実装されて

いるかプロパティ検証するための仕様書。起こりうる事象の中で検証する事象を決定し、検証項目

として「Aならば B」の文章でまとめる。

5.3.4 検証項目管理表（S）

シミュレーション検証を実施するために必要な検証項目や環境の詳細を管理表としてまとめた

もの。検証項目に対応する要求仕様、検証内容、シミュレーション検証モデル名等を記述した一覧

表を作成し、進捗状況および検証結果を随時記入していく。



CONFIDENTIAL

5.3.5 検証項目管理表（P）

プロパティ検証すべき項目の詳細を管理票としてまとめたもの。検証項目に対応する要求仕様、

検証内容、プロパティ検証モデル名等を記述した一覧表を作成し、進捗状況および検証結果を随時

記入していく。

5.4 検証モデル

図 3 制御仕様検証プロセス図の「④検証モデル設計」に含まれるドキュメント。

5.4.1 テストベクタ

設計したモデルが要求を満足するか検証するために使用するテストデータ。

検証時に、検証モデルへ入力するデータパターンを意味しており、テストパターンとも呼ばれる。

5.4.2 命題モデル

命題モデルとは、プロパティ検証で使用する検証すべきルールが設計されたモデルである。

モデルは、検証仕様書（P）を元に設計する。

検証命題となるモデルは、検証仕様書（P）に記載されている「Aならば B」の文書を元にモデル

化を行う。

命題は、状態の変化を示す場合や、複雑な論理条件の組み合わせの場合がある。

モデル作成の詳細については、[4.2.8 命題モデル作成]を参照の事

5.4.3 シミュレーション検証モデル

シミュレーション検証プロセスで用いられるモデルで、検証対象となる制御モデル、信号発生部

と判定部から構成される。信号発生部で生成されたテストパターンに対する制御モデルの振る舞い

と期待される出力との比較を判定部にて行う。

5.4.4 プロパティ検証モデル

検証対象の制御モデルと検証目的を記述した命題モデルを結合したモデル（図 10 プロパティ

検証モデル構成例参照）。制御モデルが与えられた仕様（プロパティ）を満たしているかを制御モ

デルと命題モデルの一致性を証明することによって検証する。

5.5 検証結果

図 3 制御仕様検証プロセス図の「⑤制御モデル検証」に含まれるドキュメント。

5.5.1 検証結果表（S）

シミュレーション検証のアウトプットであり、シミュレーション検証を実行した結果の合否が記

されている。

検証結果は個別のレポートとしてまとめても良いが、検証項目管理表への結果記入をもってレポ



CONFIDENTIAL

ートとしても良い。

5.5.2 検証結果表（P）

プロパティ検証のアウトプットであり、プロパティ検証を実行した結果の合否が記されている。

検証結果は個別のレポートとしてまとめても良いが、検証項目管理表への結果記入をもってレポ

ートとしても良い。

5.5.3 検証レポート

検証仕様書に基づく検証実施結果の総括をするレポートで、検証がすべて終わった段階で作成さ

れるもの。

各検証の詳細な結果は、5.5.1、5.5.2 でまとめられているため、検証レポートでは１ページ程

度で全体の検証結果が把握できる様にまとめるのが望ましい。

検証レポートでは、合否判定結果を報告するだけでなく、特に完全一致が得られない結果につい

ては必要に応じて要因を分析して報告する。

j-maab 制御仕様検証ガイドライン version 1jmaab.mathworks.jp/guidelines_v1_0.pdf · 1.2...

Documents