システムズエンジニアリング専門家によるSysML v2徹底解説
この連載では、2025年にリリースされたシステムモデリング言語SysML v2を取り上げ、業界での利活用に乗り遅れないために基本的な情報や新しい構成要素の紹介、今まで使っていたSysML v1とv2の変換などを紹介していきます。第六回の今回は「原因と結果」を記述するCause & Effectを紹介します。
SysML V2の新しい構成要素やその使い道を知る: 「原因と結果」を記述するCause & Effect
前回の記事は1月公開で、今が7月。だいぶ間が空いてしまいました。 その間に筆者の実務でもSysML v2に関しての取り組みが幾つかあり、社外のコミュニティ「SysML v2研究会」が立ち上がり、INCOSEの国際会議IS2026が開催され多くのSysML v2事例や研究が発表され…と、SysML v2を取り巻くイベントが（筆者目線で）多くありました。そのあたりのことは次回以降に書きたいと思いますが、 今回は予告通り「原因と結果」を記述するStandard Libraryの要素”Cause & Effect”を紹介します。
Cause & Effectの説明
Cause & Effectは、システム内で発生する事象の原因（Cause）と結果（Effect）の因果関係を分析モデルとして表現するためのライブラリです。Action, Flowなどの振る舞いモデル(Behavior)が「システムがどのような順序・条件で動作するか」という実行可能な振る舞いを記述するのに対し、Cause & Effectは「何が何を引き起こすのか」という因果関係そのものを表現します。そのため時間的な実行順序ではなく、影響の連鎖や依存関係に着目してモデル化する点が特徴です。同じ事象(event occurrence)が、ある関係ではEffect、別の関係では次のCauseとなることで、複雑な因果関係を表現できます。
モデル例
このモデルは、Cause & Effectライブラリを利用して「暑い車内でスマホのバッテリー充電をし、発熱して発火」するさまを記述したものです。「充電」「過熱」などの事象をモデリングするためにevent occurrenceを使用しています。また、#multicausationを使って、「暑い車内」と「充電」という2つの事象が組み合わさることで「過熱」が発生することを表現しています。さらに、#causationにより、「過熱」が原因となって「発火」が発生する流れを記述しています。このように、複数の要因が重なって事象が発生するケースと、単一の要因による因果関係の両方を、分かりやすく表現できることを示したCause & Effectモデリングの基本的なサンプルです。
コードを見る: 暑い車内でスマホのバッテリー充電をし、発熱して発火(Textual Notation)
package SmartphoneBatteryFailure {
private import CauseAndEffect::*;
part def vehicle {
doc /* 自動車(スマホの置かれる環境として) */
event occurrence hotInterior; // 発生事象：暑い車内
}
part smartphone {
doc /* スマートフォン */
part battery {
doc /* バッテリー */
event occurrence charging; // 発生事象：充電
event occurrence overheating; // 発生事象：過熱
}
ref part v : vehicle;
event occurrence fireOccurs; // 発生事象：発火
#multicausation connection {
doc /* 複数要因の因果関係：暑い車内で充電すると過熱を引き起こす */
end #cause ::> battery.charging;
end #cause ::> v.hotInterior;
end #effect ::> battery.overheating;
}
#causation connection {
doc /* 単一要因の因果関係：過熱が発火を引き起こす */
end #cause ::> battery.overheating;
end #effect ::> fireOccurs;
}
}
}
Cause & Effectのうれしさ
安全分析の結果をモデル内で扱うことが可能に
FMEAや機能安全分析では、「アイテム（部品や機能）」にどのような故障（モード）があり、それがどのような危害を起こすかを検討します。また影響が重大である故障に対し、それを検知し危害を回避する安全方策を検討します。
こういった安全分析結果を単なる表形式の成果物として管理するのではなく、設計モデルの一部として扱おうとの試みがあります。故障モード、危険状態、危害、安全方策、安全要求をそれぞれモデル要素として置き、因果関係を明示すると、「どの故障がどの危害につながり、どの安全方策で抑制するのか」をモデル上でたどれるようになります。これは、MBSEで重視される要求・構造・振る舞い・解析結果の一貫性確保に直結します。
SysML v1では、こうしたモデリングは独自拡張仕様によって行われていました。下図はSysML v1の独自拡張仕様SafeMLで記述した「アクセルとブレーキの踏み間違いが起こす危害(Harm)と、それを防止する安全要求・安全機能」のモデルです。
同様のモデルをSysML v2で描くとどうなるでしょうか。以下、SysML v2で、順を追ってモデリングしていきます。
まずは安全分析の対象(Item)となるシステム設計自体をモデリングします。システムの機能をactionで書き、機能間で流れる物事をportでモデリングしています。なおここではまだCause & Effectを使っていません。
コードを見る: 安全分析前のシステム設計モデル(Textual Notation)
package VehicleSystem {
item def AccelerationCommandSignal;
item def ThrustForce;
port def AccelerationCommandPort {
out item accCmd : AccelerationCommandSignal;
}
port def ThrustPort {
out item thrust : ThrustForce;
}
part def vehicle {
doc /* 自動車 */
action sendAccelerateSignal {
doc /* アクセル操作の受付機能 */
port outCmd : AccelerationCommandPort;
}
action generateThrust {
doc /* 動力を出力する機能 */
port inCmd : ~AccelerationCommandPort;
port outThrust : ThrustPort;
}
flow accFlow
from sendAccelerateSignal.outCmd.accCmd
to generateThrust.inCmd.accCmd;
flow thrustFlow
from generateThrust.outThrust.thrust
to thrustOutput.thrust;
port thrustOutput : ThrustPort {
doc /* 車両外部に出る動力 */
}
}
//------------------------------------------
// 物理世界
//------------------------------------------
part physicalWorld {
part v : vehicle;
action applyThrust {
doc /* 動力が車両の加速に変換される */
port inPort : ~ThrustPort;
}
flow thrustTransfer
from v.thrustOutput.thrust
to applyThrust.inPort.thrust;
event occurrence vehicleAccelerates {
doc /* 車両が加速する（物理現象） */
}
}
}
次に、システム設計に対する安全分析を実施し、その結果をモデリングします。下図の例では危険そのものの分析hazardousContextと、その危険に対し安全方策を分析したsafetyContextに分けてモデリングしています。また末尾に、安全方策の分析結果から導出された安全要求をrequirementとして記載しています。
コードを見る: 安全分析(Textual Notation)
package VehicleSafetyAnalysis {
import CauseAndEffect::*;
import VehicleSystem::*;
//------------------------------------------
// 危険要因分析（FMEA相当）
//------------------------------------------
part hazardousContext {
doc /* 危険状況と危害の分析(FMEA的) */
part v : vehicle;
part world : physicalWorld;
//--------------------------------------
// 原因・文脈
//--------------------------------------
event occurrence pedalMisapplication {
doc /* アクセル踏み間違い */
}
event occurrence obstacleAhead {
doc /* 前方に障害物が存在する */
}
//--------------------------------------
// Hazard / Harm
//--------------------------------------
event occurrence collision {
doc /* 衝突（Hazard） */
}
event occurrence personalInjury {
doc /* 人的危害 */
}
//--------------------------------------
// 因果関係
//--------------------------------------
#causation connection {
doc /* 踏み間違いにより加速指示が出る */
end #cause ::> pedalMisapplication;
end #effect ::> v.sendAccelerateSignal.outCmd;
}
#multicausation connection {
doc /* 加速中かつ障害物あり → 衝突 */
end #cause ::> world.vehicleAccelerates;
end #cause ::> obstacleAhead;
end #effect ::> collision;
}
#causation connection {
doc /* 衝突 → 人的被害 */
end #cause ::> collision;
end #effect ::> personalInjury;
}
}
//------------------------------------------
// 安全方策の分析
//------------------------------------------
part safetyContext {
doc /* 危険状況に対する安全方策の分析 */
part hz : hazardousContext;
//--------------------------------------
// 検出・防御
//--------------------------------------
event occurrence obstacleDetected {
doc /* 障害物検知 */
}
event occurrence accelerationCommandCancelled {
doc /* 加速指示がキャンセルされる */
}
event occurrence collisionAvoided {
doc /* 衝突回避 */
}
//--------------------------------------
// 因果関係
//--------------------------------------
#causation connection {
doc /* 障害物は検知される */
end #cause ::> hz.obstacleAhead;
end #effect ::> obstacleDetected;
}
#causation connection {
doc /* 検知により加速指示がキャンセルされる */
end #cause ::> obstacleDetected;
end #effect ::> accelerationCommandCancelled;
}
#causation connection {
doc /* キャンセルにより衝突回避 */
end #cause ::> accelerationCommandCancelled;
end #effect ::> collisionAvoided;
}
}
//--------------------------------------
// 安全方策の分析によって導出された、安全要求
//--------------------------------------
requirement detectObstacleReq {
part sc : safetyContext;
doc /* 前方障害物を検知すること（安全分析から導出） */
// この要求の導出元である安全分析結果のoccurrenceに関連付け
ref derivedFrom :>> sc.obstacleDetected;
// この要求を満たすVehicleのpartに関連付け
part v : VehicleSystem::vehicle;
ref satisfiedBy :>> v.detectObstacle;
}
requirement cancelAccelerationReq {
part sc : safetyContext;
doc /* 障害物検知時に加速指示をキャンセルすること（安全分析から導出） */
// この要求の導出元である安全分析結果のoccurrenceに関連付け
ref derivedFrom :>> sc.accelerationCommandCancelled;
// この要求を満たすVehicleのpartに関連付け
part v : VehicleSystem::vehicle;
ref satisfiedBy :>> v.cancelAcceleration;
}
}
最後に、安全要求を満たす機能をシステム設計に追加し、更新されたシステム設計モデルを作成します。
コードを見る: 安全機能を入れたシステム設計モデル(Textual Notation)
package VehicleSystem {
import VehicleSafetyAnalysis;
item def AccelerationCommandSignal;
item def ThrustForce;
item def ObstacleSignal;
//------------------------------------------
// Port定義
//------------------------------------------
port def AccelerationCommandPort {
out item accCmd : AccelerationCommandSignal;
}
port def ThrustPort {
out item thrust : ThrustForce;
}
port def ObstaclePort {
out item obstacle : ObstacleSignal;
}
//------------------------------------------
// Vehicle
//------------------------------------------
part def vehicle {
doc /* 自動車 */
//--------------------------------------
// 本来機能
//--------------------------------------
action sendAccelerateSignal {
doc /* アクセル操作の受付機能 */
port outCmd : AccelerationCommandPort;
}
action generateThrust {
doc /* 動力を出力する機能 */
port inCmd : ~AccelerationCommandPort;
port outThrust : ThrustPort;
}
//--------------------------------------
// 安全機能（安全分析結果から追加）
//--------------------------------------
action detectObstacle {
doc /* 前方監視機能（障害物検知） */
port outObs : ObstaclePort;
}
action cancelAcceleration {
doc /* 加速指示キャンセル機能 */
port inObs : ~ObstaclePort;
port outCmd : AccelerationCommandPort;
}
//--------------------------------------
// flow（設計）
//--------------------------------------
// 通常のアクセル操作
flow accelFlow
from sendAccelerateSignal.outCmd.accCmd
to generateThrust.inCmd.accCmd;
// 障害物検知 → キャンセル機能
flow obsFlow
from detectObstacle.outObs.obstacle
to cancelAcceleration.inObs.obstacle;
// アクセル操作のキャンセル
flow accelerationCancelFlow
from cancelAcceleration.outCmd.accCmd
to generateThrust.inCmd.accCmd; //動力0を想定
// 動力出力
flow thrustFlow
from generateThrust.outThrust.thrust
to thrustOutput.thrust;
port thrustOutput : ThrustPort {
doc /* 外部に動力を出力 */
doc /* 車両外部に出る動力 */
}
}
part physicalWorld {
doc /* 車両外部の物理現象 */
part v : vehicle;
action applyThrust {
doc /* 動力が車両の加速に変換される */
port inPort : ~ThrustPort;
}
flow thrustTransfer
from v.thrustOutput
to applyThrust.inPort;
event occurrence vehicleAccelerates {
doc /* 車両が加速する（物理現象） */
ref relatedAction :>> applyThrust;
}
}
}
図ではわかりづらいですが、安全分析とシステム設計がモデル上で結び付いています。
従来の安全分析では、FMEA表、要求仕様、設計モデル、テスト仕様が別々の成果物として管理されることが多く、設計変更時にどこまで影響が及ぶかを人手で確認する必要がありました。SysML v2では、テキスト表記と標準ライブラリを使って安全分析結果をモデル要素として記述できるため、変更差分の確認、関連要求の抽出、安全方策の抜け漏れ確認などをツール処理しやすくなります。特にCause & Effectは、正常系の振る舞いとは別に、故障や危険事象の伝播関係をモデル内に重ねて表現できるため、設計モデルと安全分析モデルを分離しすぎず、同じデジタルスレッド上で扱えることが大きな利点です。
FTAをモデル内で扱うことが可能に
FTAのツリーを「システムモデルとは別の図」ではなくモデル内に記述することが可能です。これによりFTAと要求やシステム要素などのシームレスなトレーサビリティが取れます。
FTAは本来、トップ事象から基本事象へと原因を分解していく安全分析手法ですが、設計モデルと切り離された図として作成すると、設計変更に追従しにくくなります。たとえば部品構成、機能分担、振る舞いの順序が変わった場合、FTA側のツリーも更新が必要になりますが、両者が別管理だと更新漏れや不整合が起こりやすくなります。Cause & Effectを用いると、トップ事象と下位事象の関係をモデル要素間の因果関係として表せるため、FTAをシステムモデルと同じ意味空間の中で扱えるようになります。
以下のサンプルモデルは自動車のエンジン始動を題材に、「エンジンが始動しない」トップ事象に対するFTAをモデル化しています。ここではすこし凝ったことを狙っており、システム設計モデルからFTAを機械的に生成できるモデルを作りました。肝心なのは、「(既に作った)FTAのツリーをSysML v2モデルにするのが目的ではない」ということです。
まず前提としてシステム設計をモデル化しますが、このモデルには一工夫がしてあります。次のコードは一部抜粋ですが、部品の機能(action)とその故障(event occurrence)を結び付けてモデリングしています。機能に対し複数の故障（モード）がある場合もあるでしょう。
part battery { //バッテリー
action supplyPower; //「電源供給」機能
event occurrence supplyPowerFails { //「電源供給の故障」
ref failedAction :>> supplyPower; //「電源供給」機能と関連づける
}
}
改めて、システム設計モデル全体が下記のコードです。
コードを見る: システム設計モデル(FTA対象として)(Textual Notation)
package EngineStartSystem {
part def vehicle {
part battery {
action supplyPower;
event occurrence supplyPowerFails {
ref failedAction :>> supplyPower;
}
}
part fuelPump {
action pumpFuel;
event occurrence pumpFuelFails {
ref failedAction :>> pumpFuel;
}
}
part injector {
action injectFuel;
event occurrence injectFuelFails {
ref failedAction :>> injectFuel;
}
}
part starterMotor {
action crankEngine;
event occurrence crankEngineFails {
ref failedAction :>> crankEngine;
}
}
part sparkPlug {
action ignite;
event occurrence igniteFails {
ref failedAction :>> ignite;
}
}
action startEngine {
doc /* エンジン始動機能のフロー */
perform battery.supplyPower;
perform fuelPump.pumpFuel;
perform injector.injectFuel;
perform starterMotor.crankEngine;
perform sparkPlug.ignite;
first supplyPower;
then pumpFuel;
then injectFuel;
then crankEngine;
then ignite;
}
}
}
次にFTAをモデリングします。
上位事象と下位事象の関係がCause & Effectを使ってモデリングされています。（今回は単純なサンプルのため、トップ事象を含め2階層のFTです）
このとき、エンジン始動の振る舞い「action startEngine」を既にシステム設計モデルでモデリングしているため、トップ事象「event occurrence enginFailsToStart」を引き起こす原因は全て機械的に抽出可能です。
コードを見る: FTA結果(Textual Notation)
package EngineStartFailureFTA {
private import CauseAndEffect::*;
private import EngineStartSystem::*;
part v : vehicle {
//--------------------------------------
// トップ事象
//--------------------------------------
event occurrence engineFailsToStart {
doc /* エンジン始動失敗 */
ref failedAction :>> startEngine;
}
//--------------------------------------
// FTA(今回、ゲートはすべてOR)
//--------------------------------------
#causation connection {
end #cause ::> battery.supplyPowerFails;
end #effect ::> engineFailsToStart;
}
#causation connection {
end #cause ::> fuelPump.pumpFuelFails;
end #effect ::> engineFailsToStart;
}
#causation connection {
end #cause ::> injector.injectFuelFails;
end #effect ::> engineFailsToStart;
}
#causation connection {
end #cause ::> starterMotor.crankEngineFails;
end #effect ::> engineFailsToStart;
}
#causation connection {
end #cause ::> sparkPlug.igniteFails;
end #effect ::> engineFailsToStart;
}
}
}
この考え方では、FTAは後から手作業で描く静的な図ではなく、システム設計モデルに含まれる機能、故障事象、因果関係から導出される解析ビューとして位置づけられます。つまり、モデルの主情報は部品、機能、故障、因果関係にあり、FTA図はそれらを安全分析の観点で見せる表現の一つになります。このように整理すると、設計変更時には、変更された機能や部品に紐づく故障事象をたどり、影響を受けるトップ事象や安全要求を機械的に探索できる可能性が高まります。
また、SysML v2のテキスト表記でFTA相当の構造を記述できることは、レビューや自動処理の面でも有効です。モデルを検索・差分比較・生成AIによる確認の対象にしやすくなり、「トップ事象に対する基本事象が網羅されているか」「故障事象が対応する機能に結び付いているか」「安全要求がどの故障伝播を抑えるために導出されたのか」といった確認を、従来より体系的に行えるようになります。これは、FTAを単独の安全成果物として扱うだけでなく、MBSEのモデル群の一部として継続的に更新・活用するための土台になります。
次回予告
次回はSysML v2そのものの説明からいったん離れて、2026年6月に開催された「INCOSE IS2026」で得た情報をもとに、SysML v2への取り組み方や活用のめどを分析していこうと思います。