対象システムの SysML モデリングガイドの詳細化の過程でSysML モデルに必要な情報をD-Case に記述する。SysML モデルとの連携に適したノードの記述スタイルのガイドを別紙「対象システムの

対象システムの SysML モデリングガイド

1/41

目次

1 本ガイドの主旨 .............................................................................................................4

2 D-CaseとSysMLモデリングガイドの概要 ....................................................................4

2.1 背景と目的 .............................................................................................................4

2.2 モデリングガイドの対象システム..........................................................................6

2.3 モデリングガイドの構成 ........................................................................................6

3 開発プロセス .................................................................................................................9

4 要件定義 ...................................................................................................................... 11

4.1 ユースケース図 .................................................................................................... 11

4.2 要求図...................................................................................................................16

5 システム設計 ...............................................................................................................21

5.1 ブロック定義図 ....................................................................................................21

5.2 パラメトリック図.................................................................................................25

5.3 内部ブロック図 ....................................................................................................29

5.4 ステートマシン図.................................................................................................33

6 システム検証 ...............................................................................................................37

6.1 検証シナリオ ........................................................................................................37

参考文献 .............................................................................................................................41

2/41

変更履歴

変更日変更内容

2014/01/10 作成

3/41

1 本ガイドの主旨

本ガイドでは、D-Case と SysML との連携において必要となる SysML の記述スタイルに

ついて記載する。

2 D-CaseとSysMLモデリングガイドの概要

2.1 背景と目的

近年、組込みシステムはユーザーの生活に密着した多くの領域で活用されている。一方で、

組込みシステムはユーザーの多様な要求を満たすために複雑化が進んでいる。要求には、

ユーザーからの機能要求だけでなく、ディペンダビリティに関する非機能要求も含まれる。

ディペンダビリティの属性には、安全性、信頼性、可用性、一貫性、保守性がある。ユー

ザーが安心してシステムを利用するためには、ディペンダブルなシステムを開発すること

が求められる。

本ガイドでは、開発対象システムのディペンダビリティを開発の上流工程から下流工程ま

で一貫して実現するためのD-Caseによるアプローチを紹介する。ディペンダブルなシステ

ムの開発に必要な特性を表 2-1に示す。

表 2-1 ディペンダブルなシステムの開発に必要な特性

開発フェーズ必要な特性

要件定義システム要求がディペンダビリティを満足している

システム設計設計仕様が要求を正確に反映している

システム検証検証結果がディペンダビリティを満足することを説明可能である

要件定義において、システム要求がディペンダビリティを満足するためには、ディペンダ

ビリティを阻害するすべての要因を除去するシステム要求を導出する必要がある。システ

ム要求を過不足なく導出する手段として D-Case を利用する。D-Case の議論分解により、

ディペンダビリティへの脅威を明確化し、続いて脅威の発生シーン、原因、対策の順に明

確化する。この議論分解によりディペンダビリティを阻害するすべての要因を抽出し、対

策をシステム要求として整理することが可能である。

システム設計において、設計仕様を要求から正確に反映するためには、ディペンダビリテ

ィから導出した要求に含まれる設計情報を活用してシステム設計を行う必要がある。また、

導出した設計仕様を、ディペンダビリティに基づく要求と照合し、設計仕様が過不足なき

ことを確認する必要がある。これを実現するため、D-Case の議論分解によって得られた要

求の記述から、機能・非機能要求、システム構成要求、システムの制約、検証の条件など

の設計情報を抽出し、システム設計に活用する。次に、システム設計により導出した設計

仕様を D-Case に反映し、ディペンダビリティに基づく要求と設計仕様とを照合することで、

設計仕様が過不足なきことを確認する。

4/41

システム検証において、検証結果がディペンダビリティを満足することを説明するために

は、検証結果を要求や設計仕様と関連付けて位置付けを明確化する必要がある。このため

には、D-Case のエビデンスとして検証結果をゴールに関連付けることで、要求や設計仕様

との整合性を確認する。

この手法のフローを図 2-1に示す。

D-Case SysML

要望獲得・商品企画

要件定義

S/W, H/W 開発

システム検証

要件の実現の可否

システム設計

ユースケース図ユースケース図

パラメトリック図パラメトリック図

ブロック定義図ブロック定義図

要求図要求図

内部ブロック図内部ブロック図

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

機能概要と前提要求機能概要と前提要求

システムの環境

システムの操作ユースケース

機能・非機能要求

機能・非機能要件

システムの構成要素

構成要素に課した制約検証結果

検証条件

モデル・シミュレーション


システムの機能構成要素

構成要素

制約

2. 設計仕様を正確に導出2. 設計仕様を正確に導出

3. 検証結果と要求や設計仕様との関連性を明確化3. 検証結果と要求や設計仕様との関連性を明確化

システム要求を過不足なく導出


1.



1.

検証結果による保証検証結果による保証

対策の明確化対策の明確化

原因の明確化原因の明確化

脅威の発生シーンの明確化脅威の発生シーンの明確化

ディペンダビリティへの脅威の明確化ディペンダビリティへの脅威の明確化

トップゴールの設定トップゴールの設定

図 2-1 D-Case と SysML との連携によるディペンダブルなシステムの開発手法

本手法では、D-Case の議論分解により、開発の上流工程から下流工程まで開発の意図を明

確化し、設計に反映することにより、開発するシステムの品質の向上することが可能であ

る。D-Case の分解により得られるシステムの情報を SysML モデルに反映し、モデルを作

成することが可能である。また、D-Case の分解の過程で導出されたサブゴールには、開発

に必要なアクティビティが含まれており、ゴールからアクティビティを抽出し開発計画に

反映することで、開発計画の精度を向上することが可能である。

下記に本手法をガイドする文書を挙げる。

対象システムの D-Case モデリングガイド

対象システムの SysML モデリングガイド

D-Case テンプレート

SysML テンプレート

5/41

2.2 モデリングガイドの対象システム

本ガイドが開発対象とするシステムは、自動車の機能安全に関する国際規格 ISO26262 に

準拠した車載システムである。既に開発が完了したシステムを機能安全に適合させるため、

安全性要求や信頼性要求の意図を反映し差分開発することを想定する。

2.3 モデリングガイドの構成

本手法によるモデリングフローとISO26262 が定義する安全ライフサイクルの対応関係を

図 2-2に示す。D-Caseの分解構造をISO26262 第 3 章のアイテム定義から第 4 章のシステ

ム設計に対応付けている。

安全性の観点からトップゴールと前提を設定

安全性を阻害する脅威を大別

安全性を阻害するすべてのシーンを明確化

システムの利用者と操作の関係の明確化

検証条件の明確化

対策を立てられる粒度まで原因を深堀り

対策ごとにシステム要求を詳細化

システムの機能・非機能要件を明確化

システムのアーキテクチャを明確化

システムの前提と制約を明確化













システム要求を満足することを明示


要求図要求図



モデル・シミュレーションモデル・シミュレーション


要求図要求図



モデル・シミュレーションモデル・シミュレーション

実行可能なモデルによるシステム検証

D-Case

3.5 アイテム定義アイテムの定義

3.5 アイテム定義アイテムの定義

3.7 ハザード分析とリスク評価ハザードの識別

3.7 ハザード分析とリスク評価ハザードの識別

3.8 機能安全コンセプト機能安全要求に基づく分解

3.8 機能安全コンセプト機能安全要求に基づく分解

4.6 技術安全要求の仕様技術安全要求に基づく分解

4.6 技術安全要求の仕様技術安全要求に基づく分解

4.7 システム設計検証結果による保証

4.7 システム設計検証結果による保証

ISO26262 SysML

図 2-2 モデリングフローと ISO26262 の対応

6/41

D-CaseとSysMLのモデリングガイドの構成を表 2-2に示す。

表 2-2 モデリングガイドの構成

対象 D-Case SysML

カテゴリ D-Case の

構造

ノードの

記述スタイル

D-Case からの

情報抽出

D-Case への

関連付け

アイテムの定義達成すべきゴールと

前提の記述

- -

ハザードの識別システムの操作と環

境の記述

システムの操作と

環境

ユースケース

検証の条件

機能安全要求に

基づく分解

対策を立てられるま

で原因を明確化

- -

技術安全要求に

基づく分解

システム要求の

記述

機能・非機能要求

構成要素と制約

ユースケース、要件

構成要素、制約

ガイド

項目

検証結果による

保証

検証に必要な情報

の記述

制御の条件と処理検証結果

本ガイドでは、主に以下の 3 点についてガイドする。

1. ISO26262 の安全ライフサイクルに基づいた D-Case の構造

トップゴールに対象のシステムが達成すべき性質を命題の形式で記述する。

トップゴールを分解し D-Case を完成させるための全体的な構造を検討する。本ガイド

は ISO26262 に着目し、トップゴールを ISO26262 関連部分とそれ以外に分解する。

安全ライフサイクルによる活動で作成される成果物を活用して ISO26262 関連部分の

D-Case を分解する。分解のフローを別紙「対象システムの SysML モデリングガイド」

にて解説する。

2. SysML モデルに必要な情報を提供する D-Case のノードの記述スタイル

D-Case の詳細化の過程で SysML モデルに必要な情報を D-Case に記述する。SysML

モデルとの連携に適したノードの記述スタイルのガイドを別紙「対象システムの

SysML モデリングガイド」にて解説する。

3. D-Caseの情報を基にしたSysMLモデルの作成方法

作成したD-CaseからSysMLモデルに必要な情報を抽出し、SysMLモデルを作成または

更新する。この方法を4章、5章、6章にて解説する。

7/41

以上の点を加味したD-Case と SysML モデルの作成フローを図 2-3に示す。

SysMLD-Case SysMLD-Case

要件定義要件定義

システム設計システム設計

S/W開発S/W開発

システム検証システム検証

アイテムの定義

ハザードの識別

機能安全要求に基づく分解

技術安全要求に基づく分解





検証結果による保証



図 2-3 D-Case と SysML モデルの作成フロー

8/41

3 開発プロセス

要望獲得・商品企画

図 3-1 SysML を活用した開発プロセス

本ガイドでは、図 3-1に示す開発プロセスに従って、自動車に搭載されるシステムを開発す

ることを前提とする。過去に開発した前機種の資産（仕様書やモデル）を活用して次機種

を開発する派生開発（差分開発）を行うことを前提とする。

（要件定義フェーズ）

要件定義フェーズでは、ユースケース図と要求図を更新する。ユースケース図では、シス

テムのユーザーとオペレーションの関係や、外部システムとの境界を定義する。要求図で

は、システムの詳細な機能要件と非機能要件を定義する。ユースケース図と要求図を定義

する方法と例を4章に記述する。

（システム設計フェーズ）

システム設計フェーズでは、ブロック定義図とパラメトリック図、内部ブロック図とステ

ートマシン図を更新する。ブロック定義図では、システムのアーキテクチャを定義する。

パラメトリック図では、システムの制約、関連する値と数式を定義する。内部ブロック図

では、ブロック定義図で定義したブロックの内部構造を定義する。ステートマシン図では、

安全要求の確認

要件の実現の可否

信頼性要求の確認

要件定義安全要求信頼性要求

要求の実現方法検証仕様

システム検証

機能検証

検証シナリオ（テストケース）

ステートマシン図

内部ブロック図


ブロック定義図

パラメトリック図

ユースケース図

要求図

システム設計

S/W開発・ H/W開発

9/41

システムの動的な振舞を定義する。ブロック定義図とパラメトリック図、内部ブロック図

とステートマシン図を定義する方法と例を5章に示す。

（システム検証フェーズ）

システム検証フェーズでは、ステートマシン図で記述した検証シナリオと、ステートマシ

ン図から自動生成したソースコードを基に、モデル・シミュレーションを実施する。検証

シナリオを定義する方法と例を6章に示す。

10/41

4 要件定義

4.1 ユースケース図

ユースケース図は、システムのユーザーとオペレーションの関係や、外部システムとの境

界を定義する図である。ユースケース図はアクター、ユースケース、関連、サブジェクト

から構成される。構成要素を定義する方法と例を以下に記載する。

図 4-1 ユースケース図の例

（アクター）

アクターとは、システムのユーザーや外部システムである。アクターを定義する方法を以

下に示す。

前機種の仕様書やモデルを基に、システムのユーザーや外部システムをアクターとし

て定義する。

D-Case の中に、ディペンダビリティを阻害する脅威の発生シーンを明確化するための

ストラテジ「脅威のシーンごとに●システムの安全性を検討する」と、それにより分

解されるサブゴール「▼の時、●システムはハザード X に対して安全である」がある

場合、「▼の時」に該当する部分からシステムのユーザーや外部システムを抽出し、ア


uc [パッケージ] Design [UC_CC]

サブジェクト

CC

CC停止

目標車速の設定

目標車速の減速

目標車速の加速

CC再開

車速制御<<include>>

<<include>>

<<include>>

<<include>>

CC一時休止

CC起動

車速の監視

<<include>>

<<include>>

<<include>>

CC動作状況の監視

<<include>>

<<include>>

<<include>>

<<include>>CC緊急停止

<<include>>

ドライバ

アクター

ユースケース

ドライバ

スロットルスロットル

PCSPCS関連

11/41

クターとして定義する。

（ユースケース）

ユースケースとは、システムに対する具体的な機能である。ユースケースを定義する方法

を以下に示す。

前機種の仕様書やモデルを基に、システムの機能を抽出し、ユースケースとして定義

する。




場合、「▼の時」に該当する部分からシステムの機能を抽出し、ユースケースとして定

義する。

D-Case の中に、ディペンダビリティを阻害する脅威を引き起こす原因への対策を明確

化するためのストラテジ「対策別に分解する」と、それにより分解されるサブゴール

「■ブロックにより、▼の時、▲ブロックで故障が発生しても●を許容範囲内に抑え

られる」がある場合、「■ブロックにより」に該当する部分からシステムの機能を抽出

し、必要に応じてユースケースとして定義する。

D-Case を機能分解パターンに従って機能構成別に議論分解している場合は、その中か

らシステムの機能を抽出し、ユースケースとして定義する。

※システムの視点でユースケースを記述するのではなく、アクターの視点でユースケース

を記述する。

※アクター名とユースケース名を使用して、「アクター名」＋「は」＋「ユースケース名」、

という文章を作ると意味が通じるように、ユースケース名を記述する。

※必要に応じて、ユースケース記述を追加する。

（関連）

アクターと、アクターにより利用されるユースケースの関係を関連として定義する。

※必要に応じて、汎化、包含、拡張などの他の関係も明記する。

（サブジェクト）

一つの機能を構成する複数のユースケースをまとめたサブシステムをサブジェクトとして

定義する。

12/41

（D-Case への関連付け）

ユースケース図で定義したユースケースに関連するD-Caseゴールノードが存在する場合、

D-Caseのコンテキストノードを使用して、その該当するゴールにユースケースを関連付け

ることにより、トレーサビリティの確保を実現する。関連付けの際には、ユースケースのID

をコンテキストノードのDesc欄やAttachment欄などに記載する。SW開発環境のD-Caseデ

ータ連携機能[1]が利用可能である。

（D-Case と要件の対応確認）

D-Case のゴールノードに記述された要求の内容と、ユースケース図の内容が矛盾していな

いことを確認することにより、要件定義の過不足や誤りを防止する。

13/41

（適用例）

D-Case

図 4-2 ユースケース図の更新例

uc [パッケージ] Design [UC_CC]

CC

CC停止

目標車速の設定

目標車速の減速

目標車速の加速

CC再開

車速制御<<include>>

<<include>>

<<include>>

<<include>>

CC一時休止

CC起動

車速の監視

<<include>>

<<include>>

<<include>>

CC動作状況の監視

<<include>>

<<include>>

<<include>>

<<include>>CC緊急停止

<<include>>

ドライバドライバ

スロットルスロットル

PCSPCS


技技術術安安全全要要求求（（機機能能））

をを参参照照ししてて

ユユーーススケケーースス図図をを更更新新

D-Case

技術安全要求（機能）

ISO 26262 関連部分を更新

関関連連付付けけ

ユユーーススケケーーススををゴゴーールルやや

ココンンテテキキスストトとと照照合合しし、、

過過不不足足ななききここととをを確確認認

14/41

ユースケース図の更新例を図 4-2に示す。この例では、機能安全に関する記述として、

FMEAの結果から導出される技術安全要求（TSR）「CCの緊急停止により、CCの故障が発

生してもCC動作中にブレーキを踏むとCCを緊急停止できる」がD-Caseのゴールに記述さ

れている。このTSRを基に、機能安全の観点で必要となる機能「CC緊急停止」を抽出し、

ユースケースとして定義している。そしてこのユースケースをD-Caseのコンテキストとし

て関連付けている。

このユースケースは関連する D-Case のゴール「CC の緊急停止により、CC の故障が発生

しても CC 動作中にブレーキを踏むと CC を緊急停止できる」の内容と整合性があり、要件

定義が過不足なく正確に行われていることを確認できる。

15/41

4.2 要求図

要求図は、システムの詳細な機能要件と非機能要件を定義する図である。要求図は機能要

件や非機能要件を記載する要求クラスと関係から構成される。構成要素を定義する方法と

例を以下に記載する。

図 4-3 要求図の例

（機能要件）

機能要件とは、システムに対する要件のうち機能面に関するものである。機能要件を定義

する方法を以下に示す。

前機種の仕様書やモデルを基に、機能要件を抽出し、要求クラスとして定義する。




られる」がある場合、「■ブロックにより」に該当する部分からシステムの機能要件を

抽出し、要求クラスとして定義する。

D-Case を機能分解パターンに従って機能構成別に議論分解している場合は、その中か

らシステムの機能要件を抽出し、要求クラスとして定義する。

※機能要件の名称は、具体的であり、一意であり、かつ、統一感のあるものにする。

（非機能要件）

非機能要件とは、システムに対する要件のうち機能面以外に関するものである。非機能要

件を定義する方法を以下に示す。

要求図 req [パッケージ] Design [REQ_CC]

CC<<Requirement>>

ID = REQ_01

車両は運転者を支援する走行制御機能を搭載する

CC起動（Cruise）<<Requirement>>

ID = REQ_02

CC停止中に運転者が「Cruise」ボタンを押すと、CCが起動する

<<derive>>

CC停止（Cruise）<<Requirement>>

ID = REQ_08

CC起動中に運転者が「Cruise」ボタンを押すと、CCを停止する

<<derive>>

目標車速の設定（Set）<<Requirement>>

ID = REQ_03

CC起動中に運転者が「Set」ボタンを押すと、現在の速度を設定値として保持する

機能要件

<<derive>>

目標車速の減速（Decel）<<Requirement>>

ID = REQ_04

CC起動中に運転者が「Decel」ボタンを押すと、設定値の速度が下がる

<<derive>>

目標車速の加速（Accel）<<Requirement>>

ID = REQ_05

CC起動中に運転者が「Accel」ボタンを押すと、設定値の速度が上がる

<<derive>>

CC一時休止<<Requirement>>

ID = REQ_06

CC起動中に運転者がブレーキを踏むと、CCを一時休止する

<<derive>>

CC復帰<<Requirement>>

ID = REQ_07

CC一時休止中に運転者が「Resume」ボタンを押すと、一時休止前の設定でCCを再開する

<<derive>>

操作の即応性<<Requirement>>

ID = REQ_12

ドライバが設定すると、CCが1ms以内に応答する

<<derive>><<derive>> <<derive>><<derive>> <<derive>>

操作の容易性<<Requirement>>

ID = REQ_11

ワンタッチでCCを操作できる

<<derive>> <<derive>><<derive>>

車速制限<<Requirement>>

ID = REQ_18

CCの設定車速を50～100km/hに制限する

<<derive>><<derive>> <<derive>>

加速の加速度制限<<Requirement>>

ID = REQ_13

加速は0.35G未満とする

<<derive>> <<derive>>

連続稼働<<Requirement>>

ID = REQ_15

100時間以上、連続稼働する

<<derive>>

ドライバによる運転操作の尊重<<Requirement>>

ID = REQ_16

ドライバによるアクセル操作、ブレーキ操作、ステアリング操作を最優先とする

<<derive>><<derive>>

設定情報の保持<<Requirement>>

ID = REQ_17

設定情報を不正に変更しない

<<derive>>

加減速性能<<Requirement>>

ID = REQ_14

目標速度と20km/h以上の差があるときは、0.080G以上の加速度で加減速する


CC停止（PCS）<<Requirement>>

ID = REQ_09

CC起動中にPCSから停止要求があると、CC停止する

<<derive>>

加速度の抑制制御<<Requirement>>

ID = REQ_21

加速度が閾値を超えない制御を行う

<<derive>>

<<derive>>

車速の監視<<Requirement>>

ID = REQ_22

車速を監視する

<<derive>>

<<derive>>

CCの緊急停止<<Requirement>>

ID = REQ_23

異常を検知するとCCを緊急停止する

<<derive>>

CC動作状況の監視<<Requirement>>

ID = REQ_24

CCの動作状況を監視する

<<derive>>

関係

非機能要件

16/41

前機種の仕様書やモデルを基に、ディペンダビリティ属性（安全性、信頼性、可用性、

一貫性、保守性）に関する記述、および表 3に示す機能性、使用性、効率性、移植性、

秘匿性などに関する記述を抽出し、要求クラスとして定義する。




られる」がある場合、「●を許容範囲内に抑えられる」に該当する部分からシステムの

非機能要件を抽出し、要求クラスとして定義する。

表 3 非機能要件の特性

特性説明

安全性利用者と環境へ破壊的影響をもたらさないこと

利用者に危害を加えないこと

信頼性正しいサービスの継続性

壊れにくいこと

可用性正しいサービスの即応性

利用者のサービス要求に即座に対応できること

一貫性不適切なシステム変更がないこと

保守性変更と修理を受け入れられること

機能性明示的及び暗示的必要性に合致する機能を提供すること

使用性理解、習得、利用ができ、利用者にとって魅力的であること

効率性使用する資源の量に対比して適切な性能を提供すること

移植性ある環境から他の環境に移すための特性

別環境へ移した際、そのまま動作すること

秘匿性正当な権限を持つ者のみが情報に触れられること

（関係）

要求クラス間の関係や他の SysML モデル要素との関係を、階層関係、複製関係、派生関係、

満足関係、検証関係、洗練関係、追跡関係などとして定義する。


要求図で定義した機能要件、非機能要件に関連するD-Caseゴールノードが存在する場合、

D-Caseのコンテキストノードを使用して、その該当するゴールに機能要件や非機能要件を

関連付けることにより、トレーサビリティの確保を実現する。関連付けの際には、機能要

件や非機能要件のIDをコンテキストノードのDesc欄やAttachment欄などに記載する。SW

開発環境のD-Caseデータ連携機能[1]が利用可能である。

17/41

（D-Case と要件の対応確認）

D-Case のゴールノードに記述された要求の内容と、要求図の内容が矛盾していないことを

確認することにより、要件定義の過不足や誤りを防止する。

D-Caseで分解されたゴールが一つ以上の機能要件や非機能要件と関連付けられていること

を確認することにより、要件定義の過不足を防止する。

18/41

（適用例）

図 4-4 要求図の更新例

要求図の更新例を図 4-4に示す。この例では、機能安全に関する記述として、FMEAの結

果から導出される技術安全要求（TSR）「CCの緊急停止により、CCの故障が発生してもCC

動作中にブレーキを踏むとCCを緊急停止できる」がD-Caseのゴールに記述されている。こ

D-Case

req [パッケージ] Design [REQ_CC]

CC<<Requirement>>

ID = REQ_01

車両は運転者を支援する走行制御機能を搭載する

CC起動（Cruise）<<Requirement>>

ID = REQ_02

CC停止中に運転者が「Cruise」ボタンを押すと、CCが起動する

<<derive>>

CC停止（Cruise）<<Requirement>>

ID = REQ_08

CC起動中に運転者が「Cruise」ボタンを押すと、CCを停止する

<<derive>>

目標車速の設定（Set）<<Requirement>>

ID = REQ_03

CC起動中に運転者が「Set」ボタンを押すと、現在の速度を設定値として保持する

<<derive>>

目標車速の減速（Decel）<<Requirement>>

ID = REQ_04

CC起動中に運転者が「Decel」ボタンを押すと、設定値の速度が下がる

<<derive>>

目標車速の加速（Accel）<<Requirement>>

ID = REQ_05

CC起動中に運転者が「Accel」ボタンを押すと、設定値の速度が上がる

<<derive>>

CC一時休止<<Requirement>>

ID = REQ_06

CC起動中に運転者がブレーキを踏むと、CCを一時休止する

<<derive>>

CC復帰<<Requirement>>

ID = REQ_07

CC一時休止中に運転者が「Resume」ボタンを押すと、一時休止前の設定でCCを再開する

<<derive>>

操作の即応性<<Requirement>>

ID = REQ_12

ドライバが設定すると、CCが1ms以内に応答する

<<derive>><<derive>> <<derive>><<derive>> <<derive>>

操作の容易性<<Requirement>>

ID = REQ_11

ワンタッチでCCを操作できる

<<derive>> <<derive>><<derive>>

車速制限<<Requirement>>

ID = REQ_18

CCの設定車速を50～100km/hに制限する

<<derive>><<derive>> <<derive>>

加速の加速度制限<<Requirement>>

ID = REQ_13

加速は0.35G未満とする

<<derive>> <<derive>>

連続稼働<<Requirement>>

ID = REQ_15

100時間以上、連続稼働する

<<derive>>

ドライバによる運転操作の尊重<<Requirement>>

ID = REQ_16

ドライバによるアクセル操作、ブレーキ操作、ステアリング操作を最優先とする


設定情報の保持<<Requirement>>

ID = REQ_17

設定情報を不正に変更しない

<<derive>>

加減速性能<<Requirement>>

ID = REQ_14

目標速度と20km/h以上の差があるときは、0.080G以上の加速度で加減速する


CC停止（PCS）<<Requirement>>

ID = REQ_09

CC起動中にPCSから停止要求があると、CC停止する

<<derive>>

加速度の抑制制御<<Requirement>>

ID = REQ_21

加速度が閾値を超えない制御を行う

<<derive>>

<<derive>>

車速の監視<<Requirement>>

ID = REQ_22

車速を監視する

<<derive>>

<<derive>>

CCの緊急停止<<Requirement>>

ID = REQ_23

異常を検知するとCCを緊急停止する

<<derive>>

CC動作状況の監視<<Requirement>>

ID = REQ_24

CCの動作状況を監視する

<<derive>>


要求図

技技術術安安全全要要求求（（機機能能））

を技術安全要求（機能）を参参照照ししてて

要要求求図図をを更更新新

D-Case


ブブロロッッククををゴゴーールルやや



19/41

のTSRを基に、機能安全の観点で必要となる機能「CC緊急停止」を抽出し、機能要件とし

て定義している。そしてこの機能要件をD-Caseのコンテキストとして関連付けている。

この機能要件は関連する D-Case のゴール「CC の緊急停止により、CC の故障が発生して

も CC 動作中にブレーキを踏むと CC を緊急停止できる」の内容と整合性があり、要件定義

が過不足なく正確に行われていることを確認できる。

20/41

5 システム設計

5.1 ブロック定義図

ブロック定義図は、システムのアーキテクチャを定義する図である。ブロック定義図はブ

ロックと関連から構成される。構成要素を定義する方法と例を以下に記載する。


bdd [パッケージ] Design [BDD_car]

車両<<Block>>

Values

Operations

図 5-1 ブロック定義図の例

（ブロック）

ブロックとは、システムの構成要素である。ブロックを定義する方法を以下に示す。

前機種の仕様書やモデルを基に、システムの構成要素を抽出し、ブロックとして定義

する。




られる」がある場合、「■ブロックにより」に該当する部分からシステムの構成要素を

抽出し、ブロックとして定義する。

D-Caseをアーキテクチャ分解パターンに従ってシステム構成別に議論分解している場

CCコントローラ<<Block>>

Values

Operations

1

ブレーキ<<Block>>

Values

Operations

1

CC操作UI<<Block>>

Values

Operations

1

車速センサー<<Block>>

Values

Operations

1

車両力学制御<<Block>>

Values

Operation

電子制御スロットル<<Block>>

Values

Operations

1

スロットルアクチュエータ<<Block>>

Values

Operations

1

PCSコントローラ<<Block>>

Values

Operations

1

前方障害物検知センサー<<Block>>

Values

Operations

1

統合制御<<Block>>

Values

Operations

1

1

CC動作状況のモニター回路<<Block>>

Values

Operations

1

1

アクセル<<Block>>

Values

Operations

1

電子制御ブレーキ<<Block>>

Values

Operations

1

ブレーキアクチュエータ<<Block>>

Values

Operations

1

車速のモニター回路<<Block>>

Values

Operations

1

1

関連

ブロック

21/41

合は、その中からシステムの構成要素を抽出し、ブロックとして定義する。

※必要に応じて、区画やプロパティを記述する。

（関連）

複数のブロック間の意味的な関係を、依存関係、パート関連（コンポジション）、共有関連

（集約）、誘導可能性、汎化などとして定義する。

※必要に応じて、関連端や多重度などを記述する。


ブロック定義図で定義したブロックに関連するD-Caseゴールノードが存在する場合、

D-Caseのコンテキストノードを使用して、その該当するゴールにブロックを関連付けるこ

とにより、トレーサビリティの確保を実現する。関連付けの際には、ブロックのIDをコン

テキストノードのDesc欄やAttachment欄などに記載する。SW開発環境のD-Caseデータ連

携機能[1]が利用可能である。

（D-Case と設計仕様の対応確認）

D-Case のゴールノードに記述された要求の内容と、ブロック定義図の内容が矛盾していな

いことを確認することにより、システム設計の過不足や誤りを防止する。

D-Caseで分解されたゴールが一つ以上のブロックと関連付けられていることを確認するこ

とにより、システム設計の過不足を防止する。

22/41

（適用例）

D-Case

図 5-2 ブロック定義図の更新例

bdd [パッケージ] Design [BDD_car]

車両<<Block>>

Values

Operations


Values

Operations

1


Values

Operations

1

CC操作UI<<Block>>

Values

Operations

1


Values

Operations

1


Values

Operation


Values

Operations

1


Values

Operations

1

PCSコントローラ<<Block>>

Values

Operations

1

前方障害物検知センサー<<Block>>

Values

Operations

1


Values

Operations

1

1

CC動作状況のモニター回路<<Block>>

Values

Operations

1

1


Values

Operations

1


Values

Operations

1


Values

Operations

1


Values

Operations

1

1



シシスステテムム構構成成要要求求

を技術安全要求

（システム構成要求）を参参照照ししてて

ブブロロッックク定定義義図図をを更更新新

D-Case


設設計計仕仕様様ををゴゴーールルやや



23/41

ブロック定義図の更新例を図 5-2に示す。この例では、機能安全に関する記述として、

FMEAの結果から導出される技術安全要求（TSR）「車速のモニター回路により、CC起動

後にCCコントローラで演算不具合が発生しても加速度を許容範囲内に抑える制御ができ

る」がD-Caseのゴールに記述されている。このTSRはシステム構成要求の例である。この

TSRを基に、機能安全の観点で必要となるブロック「車速のモニター回路」を抽出し、ブ

ロックとして定義している。そしてこのブロックをD-Caseのコンテキストとして関連付け

ている。

このブロックは関連する D-Case のゴール「車速のモニター回路により、CC 起動後に CC

コントローラで演算不具合が発生しても加速度を許容範囲内に抑える制御ができる」やコ

ンテキスト「要求一覧：車速の監視、車速を監視する」などの内容と整合性があり、シス

テム設計が過不足なく正確に行われていることを確認できる。

24/41

5.2 パラメトリック図

パラメトリック図は、システムの制約、関連する値と数式を定義する図である。パラメト

リック図は制約ブロックとコネクタから構成される。構成要素を定義する方法と例を以下

に記載する。


図 5-3 パラメトリック図の例

（制約ブロック）

制約ブロックとは、システムの制約、関連する値や数式を記述したブロックである。制約

ブロックを定義する方法を以下に示す。

前機種の仕様書やモデルを基に、システムの制約、関連する値や数式に関する記述を

抽出し、制約ブロックとして定義する。




par [パッケージ] Design [PAR_車両ブロック]


Values

Operations

breakPowerTargetbreakPower


Values

Operations

powerOFF ccBtnccPower

speed


Values

Operations

speed


Values

Operations

accelPowerTargetaccelPower


Values

Operations

pwrthrottleTorque


Values

Operations

pwr

CC操作UI<<Block>>

Values

Operations

ccBtn

加速の加速度制限：a < 0.35G

加減速性能：a > 0.080G

設定車速の制限：

50km/h ≦ vt ≦ 100km/h

<<allocate>>


Values

Operations

breakPowerTarget

accelPowerTarget

breakTorque

throttleTorque

ccPower

breakPower

accelPower

<<allocate>><<allocate>>


Values

Operations

pwrbreakTorque


Values

Operations

pwr


Values

Operations

pwrspeed


Values

Operations

powerOFF speed

<<allocate>>CC動作状況のモニター回路<<Block>>

Values

Operations

ccBtn

speedpowerOFF

pwr =Kp ( Vp - Vt )+ Ki ∫(Vp - Vt ) dt

<<allocate>>

a = (thrust + drag) / mass

<<allocate>>

thrust = pwr / actualSpeed

<<allocate>>

actualSpeed =

∫ a dt + v0

コネクタ

<<allocate>>

drag =

-1/2 * Cd * A

* densityOfAir

* actualSpeed^2

<<allocate>>

セダンの場合mass = 1700 kgワゴンの場合mass = 2500 kg

<<allocate>>

セダンの場合Cd = 0.44ワゴンの場合Cd = 0.50

<<allocate>>

セダンの場合A = 1.8 m 2̂ワゴンの場合A = 2.0 m 2̂

<<allocate>> <<allocate>>

densityOfAir = 1.2 kg/m^3

制約ブロック

25/41

られる」がある場合、「●を許容範囲内に抑えられる」に該当する部分からシステムの

制約、関連する値や数式を抽出し、制約ブロックとして定義する。

D-Case のゴールノードを基に、システムの制約、関連する値や数式を検討し、制約ブ

ロックとして定義する。

（コネクタ）

ブロック定義図で作成したブロックの構造を基に、関連する制約ブロックをコネクタで連

結する。


パラメトリック図で定義した制約ブロックに関連するD-Caseゴールノードが存在する場合、

D-Caseのコンテキストノードを使用して該当するゴールに関連付けることにより、トレー

サビリティの確保を実現する。関連付けの際には、制約ブロックのIDをコンテキストノー

ドのDesc欄やAttachment欄などに記載する。SW開発環境のD-Caseデータ連携機能[1]が利

用可能である。


D-Case のゴールノードに記述された要求の内容と、パラメトリック図の内容が矛盾してい

ないことを確認することにより、システム設計の過不足や誤りを防止する。

26/41

（適用例） D-Case

機能安全要求

図 5-4 パラメトリック図の更新例

par [パッケージ] Design [PAR_車両ブロック]


Values

Operations

breakPowerTargetbreakPower


Values

Operations

powerOFF ccBtnccPower

speed


Values

Operations

speed


Values

Operations

accelPowerTargetaccelPower


Values

Operations

pwrthrottleTorque


Values

Operations

pwr

CC操作UI<<Block>>

Values

Operations

ccBtn

加速の加速度制限：a < 0.35G

加減速性能：a > 0.080G

設定車速の制限：

50km/h ≦ vt ≦ 100km/h

<<allocate>>


Values

Operations

breakPowerTarget

accelPowerTarget

breakTorque

throttleTorque

ccPower

breakPower

accelPower

<<allocate>><<allocate>>


Values

Operations

pwrbreakTorque


Values

Operations

pwr


Values

Operations

pwrspeed


Values

Operations

powerOFF speed

<<allocate>>CC動作状況のモニター回路<<Block>>

Values

Operations

ccBtn

speedpowerOFF

pwr =Kp ( Vp - Vt )+ Ki ∫(Vp - Vt ) dt

<<allocate>>

a = (thrust + drag) / mass

<<allocate>>

thrust = pwr / actualSpeed

<<allocate>>

actualSpeed =

∫ a dt + v0

<<allocate>>

drag =

-1/2 * Cd * A

* densityOfAir

* actualSpeed^2

<<allocate>>

セダンの場合mass = 1700 kgワゴンの場合mass = 2500 kg

<<allocate>>

セダCd

ンの場合 = 0

ワゴ

.44ンの場合

Cd = 0.50

<<allocate>>

セダンの場合A = 1.8 m 2̂ワゴンの場合A = 2.0 m 2̂

<<allocate>>

densityOfAir = 1.2 kg/m^3

<<allocate>>


機機能能安安全全要要求求をを参参照照ししてて

パパララメメトトリリッックク図図をを更更新新


D-Case 関関連連付付けけ




27/41

パラメトリック図の更新例を図 5-4に示す。この例では、機能安全に関する記述として、ハ

ザード分析の結果から導出される機能安全要求（FSR）「加速度の抑制制御により、CC起動

後にCCコントローラで演算不具合が発生しても加速度を許容範囲内に抑える制御ができ

る」がD-Caseのゴールに記述されている。このFSRを基に、システムの制約を詳細化して

「加速の加速度制限： a < 0.35G」とし、制約ブロックとして定義している。そしてこの制

約ブロックをD-Caseのコンテキストとして関連付けている。

この制約ブロックは関連する D-Case のゴール「加速度の抑制制御により、CC 起動後に

CC コントローラで演算不具合が発生しても加速度を許容範囲内に抑える制御ができる」や

コンテキスト「要求一覧：加速度の抑制制御、加速度が閾値を超えない制御を行う」など

の内容と整合性があり、システム設計が過不足なく正確に行われていることを確認できる。

28/41

5.3 内部ブロック図

内部ブロック図は、ブロック定義図で定義したブロックの内部構造を定義する図である。

内部ブロック図はブロックとコネクタから構成される。構成要素を定義する方法と例を以

下に記載する。

図 5-5 内部ブロック図の例

（ブロック）

ブロックとは、システムの内部構造を示す構成要素である。ブロックを定義する方法を以

下に示す。

前機種の仕様書やモデルを基に、ブロック定義図で定義したブロックやパラメトリッ

ク図で定義した制約ブロックに対して、内部構造を詳細化し、ブロックとして定義す

る。

5.1節のブロック定義図と同様に、D-Caseの中からシステムの構成要素を抽出し、ブロ

ックとして定義する。


ibd [Block] 車速のモニター回路 [IBD_車速のモニター回路]

powerOFFspeed powerOFF

<<flow>>

speed

<<flow>>

車速読み取り異常判定1

Attributes

Operations

speed 車速

1

Attributes

Operations

判定結果車速

異常通知1

Attributes

Operations

判定結果 powerOFF

ブブロロッックク

ココネネククタタ

29/41

（コネクタ）

ブロック定義図で作成したブロックやパラメトリック図で定義した制約ブロックの構造を

基に、関連するブロックをコネクタで連結する。

※ブロック定義図で定義した関連やパラメトリック図で定義したコネクタと、内部ブロッ

ク図で定義するコネクタが整合するようにする。


必要に応じて、内部ブロック図で定義したブロックをD-Caseのコンテキストノードを使用

して該当するゴールに関連付けることにより、トレーサビリティの確保を実現する。関連

付けの際には、ブロックのIDをコンテキストノードのDesc欄やAttachment欄などに記載す

る。SW開発環境のD-Caseデータ連携機能[1]が利用可能である。


D-Case のゴールノードに記述された要求の内容と、内部ブロック図の内容が矛盾していな

いことを確認することにより、システム設計の過不足や誤りを防止する。

30/41

（適用例）

D-Case

図 5-6 内部ブロック図の更新例

内部ブロック図の更新例を図 5-6に示す。この例では、ブロックに関する記述として、「ブ

ロック：車速のモニター回路」がD-Caseのコンテキストに記述されている。このブロック

の内部構造を詳細化し、内部ブロック図を更新している。

この内部ブロック図は関連する D-Case のゴール「車速のモニター回路により、CC 起動後

に CC コントローラで演算不具合が発生しても加速度を許容範囲内に抑える制御ができる」

ibd [Block] 車速のモニター回路 [IBD_車速のモニター回路]

powerOFFspeed powerOFF

<<flow>>

speed

<<flow>>

車速読み取り1

Attributes

Operations

speed 車速

異常判定1

Attributes

Operations

判定結果車速

異常通知1

Attributes

Operations

powerOFF判定結果


ブブロロッッククにに関関すするる記記述述をを参参照照ししてて

内内部部ブブロロッックク図図をを更更新新





31/41

やコンテキスト「要求一覧：車速の監視、車速を監視する」などの内容と整合性があり、

システム設計が過不足なく正確に行われていることを確認できる。

32/41

5.4 ステートマシン図

ステートマシン図は、システムの動的な振舞を定義する図である。ステートマシン図は状

態と遷移から構成される。構成要素を定義する方法と例を以下に記載する。

stm [Block] AccController [statechart_0]

図 5-7 ステートマシン図の例

（状態）

状態とは、ある一定の時間とどまっている状況である。状態を定義する方法を以下に示す。

ブロック定義図で定義したブロックに対して、ある一定の時間とどまっている状況が

あれば状態として定義する。

前機種の仕様書やモデルの中に、状態に関する記述があれば、それを再利用する。

※必要に応じて、開始状態、終了状態なども追加する。

（遷移）

各状態に対して、別の状態への状態遷移を起こす契機となるトリガー、状態遷移を有効と

すべきかを判断するガード条件、状態遷移が生じたときに実行するアクション、状態に入

init

runningステートマシン図

cycle1ms tm(1)/if (this->isWorking) {

double diffVelocity = (this->targetVelocity - this->velocity) / 3.6; // [m/s]this->sumDVelocity += diffVelocity;this->power += Kp * diffVelocity + Ki * this->sumDVelocity;if(this->power > this->maxPower) this->power = this->maxPower;if(this->power < -this->maxPower) this->power = -this->maxPower;

}else {

this->power = 0.0;}

evAccPowerRequest(this->power) to itsArbitrationController

Off

On

Working

evAccSetBtn/set(this->velocity);

evAccAccelBtn/accel();

evAccDecelBtn/decel();

Unset

evAccSetBtn[valid(this->velocity)]/set(this->velocity);

SleepingevAccBreakPedal

evAccResumeBtn




evAccCruiseBtn

evAccCruiseBtn

evAccOFF

sensoring

状態

evPowerOFF

遷移

evSpeedChanged/this->velocity = params->velocity;

33/41

ってから出るまでの間に継続して行うアクティビティを定義する。

前機種の仕様書やモデルの中に、状態遷移に関する記述があれば、それを再利用する。

※必要に応じて、状態遷移表を使用して状態遷移を整理する。


必要に応じて、ステートマシン図で定義した状態や遷移をD-Caseのコンテキストノードを

使用して該当するゴールに関連付けることにより、トレーサビリティの確保を実現する。

関連付けの際には、状態や遷移のIDをコンテキストノードのDesc欄やAttachment欄などに

記載する。SW開発環境のD-Caseデータ連携機能[1]が利用可能である。


D-Case のゴールノードに記述された要求の内容と、ステートマシン図の内容が矛盾してい

ないことを確認することにより、システム設計の過不足や誤りを防止する。

34/41

（適用例）

D-Case

図 5-8 ステートマシン図の更新例

ステートマシン図の更新例を図 5-8に示す。この例では、ブロックに関する記述として、「ブ

ロック：CCコントローラ」がD-Caseのコンテキストに記述されている。このブロックの動

的な振舞を詳細化し、ステートマシン図を更新している。

このステートマシン図は関連する D-Case のゴール「CC の緊急停止により、CC 起動後に

stm [Block] CcController [statechart_0]

init

running

cycle1ms

evAccPowerRequest(this->power) to itsArbitrationController

tm(1)/if (this->isWorking) {

double diffVelocity = (this->targetVelocity - this->velocity) / 3.6; // [m/s]this->sumDVelocity += diffVelocity;this->power += Kp * diffVelocity + Ki * this->sumDVelocity;if(this->power > this->maxPower) this->power = this->maxPower;if(this->power < -this->maxPower) this->power = -this->maxPower;

}else {

this->power = 0.0;}

Off

On

Working




Unset

evAccSetBtn[valid(this->velocity)]/set(this->velocity);

SleepingevAccBreakPedal

evAccResumeBtn




evAccCruiseBtn

evAccCruiseBtn

evAccOFF

sensoring

evSpeedChanged/this->velocity = params->velocity;

evPowerOFF

ステートマシン図

ブブロロッッククのの状状態態にに関関すするる

記記述述をを参参照照ししてて

スステテーートトママシシンン図図をを更更新新

ISO 26262関連部分を更新




35/41

車速センサーの伝送経路に故障が発生してもドライバーの意図と異なる加速をしない」や

コンテキスト「要求一覧：CC の緊急停止、異常を検知すると CC を緊急停止する」などの

内容と整合性があり、システム設計が過不足なく正確に行われていることを確認できる。

36/41

6 システム検証

6.1 検証シナリオ

検証シナリオは、テストケースの検証手順を定義する図である。本ガイドではステートマ

シン図により検証シナリオを記述する。検証シナリオを定義する方法と例を以下に記載す

る。

検証シナリオ

stm [Block] Driver [statechart_1]

init

図 6-1 検証シナリオの例

（検証シナリオ）

検証シナリオとは、システム検証における検証手順であり、ステートマシン図などで記述

される。検証シナリオを定義する方法を以下に示す。

前機種の仕様書やモデルの中に、システム検証に関する検証シナリオがあれば、それ

を再利用する。




場合、「▼の時」の部分から検証条件を抽出し、ステートマシン図などで表現する。

evAccelPedalPressDown(1.0) to itsAccelPedal

evCarPowerON to itsCar

tm(10)

evCarPowerOFF to itsCarevSimulationStart to itsDynamics

evSimulationEnd to itsDynamics

evAccelPedalTakeOff to itsAccelPedal

tm(5100)

evAccSetBtn to itsAccPanel

evAccCruiseBtn to itsAccPanel

tm(1000)

tm(10)

tm(10)/for (int idx = 0; idx < 50/3; ++idx) {

itsAccPanel->GEN(evAccAccelBtn);}

tm(10000)

evAccAccelBtn to itsAccPanel

37/41

（システム検証）

ステートマシン図などからソースコードを生成し、システム検証のためのモデル・シミュ

レーションを実施する。


システム検証の結果をD-Caseのコンテキストノードやエビデンスノードを使用して該当す

るゴールに関連付けることにより、トレーサビリティの確保を実現する。関連付けの際に

は、検証シナリオなどのIDをコンテキストノードのDesc欄やAttachment欄などに記載する。

D-Case OSLCアドオン[2]が利用可能である。


D-Case のゴールノードに記述された要求の内容と、システム検証の内容が矛盾していない

ことを確認することにより、システム検証の過不足や誤りを防止する。

D-Caseで分解されたゴールが一つ以上のシステム検証の結果と関連付けられていることを

確認することにより、システム検証の過不足を防止する。

38/41

（適用例）

D-Case

図 6-2 検証シナリオによる更新例

検証シナリオによる更新例を図 6-2に示す。この例では、検証シナリオに関する記述として、

stm [Block] Driver [statechart_1]

init

evAccelPedalPressDown(1.0) to itsAccelPedal

evCarPowerON to itsCar

tm(10)

evCarPowerOFF to itsCarevSimulationStart to itsDynamics

evSimulationEnd to itsDynamics

evAccelPedalTakeOff to itsAccelPedal

tm(5100)

evAccCruiseBtn to itsAccPanel

tm(1000)

evAccSetBtn to itsAccPanel

tm(10) evAccAccelBtn to itsAccPanel

tm(10000)

tm(10)/for (int idx = 0; idx < 50/3; ++idx) {

itsAccPanel->GEN(evAccAccelBtn);}

検証シナリオ

検検証証シシナナリリオオをを作作成成

検検証証シシナナリリオオををゴゴーールルやや


過過不不足足ななくく正正確確にに論論証証でで

ききるるここととをを確確認認

39/41

ハザード分析の結果から導出される機能安全要求（FSR）「加速度の抑制制御により、CC

起動後にCCコントローラで演算不具合が発生しても加速度を許容範囲内に抑える制御がで

きる」がD-Caseのゴールに記述されている。このFSRを基に、「テストケース：加速性能テ

スト、CC故障発生時でも加速度は 0.35G未満となる」を定義し、D-Caseのコンテキストと

して関連付けている。この検証シナリオを基に、モデル・シミュレーションを行うのに必

要なステートマシン図を記述し、検証を行っている。

この検証結果は D-Case のエビデンス「CC の加速性能テスト結果（CC 故障発生時）」とし

て記録される。このエビデンスは関連する D-Case のコンテキスト「要求一覧：加速度の抑

制制御、加速度が閾値を超えない制御を行う」などの内容と整合性があり、システム検証

が過不足なく正確に行われていることを確認できる。

40/41

41/41

参考文献

[1] SW開発環境のD-Caseデータ連携機能,

http://www.dependable-os.net/tech/D-Case-OSLC/index.html

[2] D-Case OSLCアドオン,




Documents

対象システムの SysML モデリングガイド の詳細化の過程でSysML モデルに必要な情報をD-Case に記述する。SysML モデルとの連携に適したノードの記述スタイルのガイドを別紙「対象システムの

対象システムの SysML モデリングガイドの詳細化の過程でSysML モデルに必要な情報をD-Case に記述する。SysML モデルとの連携に適したノードの記述スタイルのガイドを別紙「対象システムの