この連載では、2025年内にはリリースされる見込みのシステムモデリング言語SysML v2を取り上げ、業界での利活用に乗り遅れないために基本的な情報や新しい構成要素の紹介、今まで使っていたSysML v1とv2の変換などを紹介していきます。第三回の今回は新しい構成要素のひとつ「Occurrence」を紹介します。

SysML v2の新しい構成要素やその使い道を知る:時により変わるシステムの姿を記述できるOccurrence

システムは、時と場合により異なる姿を取ることがあります。短いスパンでは「使用中にバッテリーが減っていく」、長いスパンでは「開発時にはデバッグ用ポートがあるが、製造時には削除される」などです。こういった概念を記述できる要素がSysML v2のOccurrenceです。 Occurrenceには関連する4種類の要素があり、これらを使い分けてシステムの時間的・空間的な実体表現をします。

• Occurrence：抽象的な「発生」。その概念が存在することを表す。
• Individual：Occurrenceの個体、実体。
• Timeslice：Individualのある時間範囲の姿。
• Snapshot：Individualのある時点での姿。

SysML v1にはBlockのインスタンス的な要素であるPartがありました。PartはBlockに対する個体などを記述でき、v2でいうIndividualに近い概念です。しかしPartは静的な構造を表すにすぎず、時間的な「ある時点の姿」を表現できませんでした。SysML v2のOccurrenceを使えばシステムの「ある時点の姿」を表現できます。

モデル例

この例では、レーシングカーがサーキットを「周回」する概念をモデリングしました。一周中にはセクターという期間(timeslice)があり、また一周中のある瞬間(snapshot)の速度を記録するイメージです。

package MySampleRace{
    part def raceCar{
        attribute speed;
    }
    // 発生定義：Lap（コースの周回）
    occurrence def Lap {
        ref part racecar : raceCar;
        attribute lapTime;
        // 周回の区切り（セクター）
        timeslice sector1;
        timeslice sector2{
            //セクター中のある瞬間
            snapshot turnIn;    //コーナー進入時 
            snapshot apex;      //コーナー頂点時 
            snapshot cornerExit;//コーナー脱出時
        }
        timeslice sector3;
    }
    // 個別の周回の定義
    individual def lap50:> Lap;
    // 個別の周回の実体（その周回の記録のイメージ）
    individual lapRecord_50 : lap50 {       
        timeslice redefines sector2{
            attribute redefines lapTime = "59.870";
            snapshot redefines turnIn{
                attribute speed := 100;
            }
            snapshot redefines apex{
                attribute speed := 50;
            }
            snapshot redefines cornerExit{
                attribute speed := 130;
            }   
        }
    }
}

Occurrenceのうれしさ：状態によるシステムの違いを描き分ける

SysML v1では「動的な振る舞いの違い」はステートマシン等で記述できましたが、静的な構成や属性値が時と場合により異なるさまの記述方法は直接的にはありませんでした。SysML v2のOccurrenceはこの「静的な構成や属性値が時と場合により異なるさま」を記述する文法ととらえることができます。 例えば電気自動車が、充電中、走行後、などのタイミングによってバッテリー残量が異なることを表記できます。

package MySample{
    part def Battery{
        attribute stateOfCharge;
    }
    part def ElectricVehicle{
        part battery : Battery;
    }     

    individual def EV_VIN0001 :> ElectricVehicle{
        snapshot EV_VIN0001_charging;
        snapshot EV_VIN0001_afterDrive;
    }
    individual EV_VIN0001_actual : EV_VIN0001{
        snapshot redefines EV_VIN0001_charging{
            stateOfCharge := 100;
        }//走行後の一時点
        snapshot redefines EV_VIN0001_afterDrive {
            stateOfCharge := 50;
         }
     }
}

またより巨視的には、電気自動車の製造中とユーザーの利用中で検査用ポートの使用可否が変わるような、ライフサイクルステージ毎の違いを表現するようなこともできます。

Occurrenceのうれしさ：個体ごとの違いを記述する

Individualを用いて個体をモデリングすることができます。これを活用すると、例えば市場に出荷された製品個体をモデリングし、各個体のソフトウェアアップデート状況の追跡などに利用可能です。 下記のモデルでは、2台の個車” EV_VIN0011”と” EV_VIN0012”があり、それぞれに搭載された”ECU_SW”の”version”が異なることをモデリングしています。

package MySample2{
    //車載ECUソフトウェアのバージョン情報
    part def ECU_SW{
        attribute version;
        attribute isFSDEnabled;
    }
    //Ver0001のUsage
    part ECU_SW_Ver0001 : ECU_SW{
        attribute redefines version := "0001";
        attribute redefines isFSDEnabled := false;
    }
    //Ver0002のUsage
    part ECU_SW_Ver0002 : ECU_SW{
        attribute redefines version := "0002";
        attribute redefines isFSDEnabled := true;
    }

    part def ElectricVehicle{
        part ecu_sw : ECU_SW;
    }   
    individual def EV_VIN0011 :> ElectricVehicle;
    individual def EV_VIN0012 :> ElectricVehicle;

    //個車VIN0011のバージョン情報
    individual EV_VIN0011_ind : EV_VIN0011{
        part redefines ecu_sw := ECU_SW_Ver0001;
    }
    //個車VIN0012のバージョン情報
    individual EV_VIN0012_ind : EV_VIN0012{
        part redefines ecu_sw := ECU_SW_Ver0002;        
    }
}

SysML v1では、開発ステージ以外のモデル活用はあまりなされなかったと思います。SysML v2のモデルは（開発時に使う）モデリングツールのみならず各種ツールとの連携を企図しているので、こういったモデルが個車のバージョン管理に使われ、開発～製造～市場で情報のトレーサビリティを確保できるようになるかもしれません。

次回予告

次回は要求モデリング、および要求と設計を関連づけるSubject/Satisfyについて解説する予定です。