Module 4: Behaviour Modelling

SysML v2 behaviour modelling is built on KerML’s Occurrence layer — the part of the language that describes things that happen over time, in contrast to the Structure layer which describes things that exist. Every behavioural keyword in this module is a SysML L2 application of a KerML L1 construct from that Occurrence layer.

KerML origin: action def → Behavior (Occurrence layer);  action → Feature typed by Behavior

An action describes something the system does over a time interval. This is the fundamental shift from Module 3: parts exist, actions happen. At the KerML level, Behavior specialises Occurrence which specialises Class — so all the mechanisms you know from structure modelling (specialisation, features, multiplicity, chaining) apply equally to behaviours.

Defining and using actions

The definition/usage split from Module 1 applies here too. action def defines the template; action uses it in a specific context:

1
action def FuelPump {
2
    in  item fuelRequest : FuelRequest;  // input: what is being requested
3
    out item fuelDelivery : Fuel;        // output: fuel delivered
4
}
5
6
action def EngineStart {
7
    // sub-actions: each is a Feature typed by its action def
8
    action primeSystem  : PrimeFuelSystem;
9
    action crankEngine  : CrankEngine;
10
    action fireIgnition : FireIgnition;
11
}

Nesting and decomposition

Actions can be nested to any depth. Each sub-action is a composite Feature whose execution occurs within the lifetime of its parent action — exactly as a composite part is owned by its parent part in the structural domain:

1
action def MissionProfile {
2
    action takeOff   : TakeOff;
3
    action cruise    : CruiseSegment;
4
    action land      : Landing;
5
    // Without explicit succession, execution order is unspecified.
6
    // Use succession / then to impose ordering (see Section 3).
7
}

Performing an existing action definition

Use perform action to invoke a pre-defined action by name, without re-declaring its body. This is a membership reference, not a new definition:

1
action def SystemTest {
2
    perform action runDiagnostics : Diagnostics;  // references Diagnostics by type
3
    perform action logResults     : Logger;
4
}

KerML origin: Parameters → directed Features on a Behavior;  Item flows → ItemFlow

Actions communicate by passing items through parameters. A parameter is a directed Feature on the action definition — the same in / out / inout mechanism as port features in Module 3, but applied to actions. The KerML origin is the same: a directed Feature on a Classifier.

Declaring parameters

1
action def ComputeTrajectory {
2
    in  attribute startPos   : GeoCoordinate;   // input: starting position
3
    in  attribute targetPos  : GeoCoordinate;   // input: target position
4
    in  attribute windSpeed  : ISQ::SpeedValue; // input: environmental data
5
    out attribute trajectory : Trajectory;      // output: computed path
6
    out attribute flightTime : ISQ::TimeValue;  // output: estimated duration
7
}

Item flows between sub-actions

Inside a composite action, item flows connect one sub-action’s output parameter to another’s input parameter. This is the behavioural analogue of the structural flow statement from Module 3, mapping to KerML ItemFlow:

1
action def DriveControl {
2
    action sense  : SenseEnvironment { out item data : SensorData; }
3
    action plan   : PlanRoute        { in  item data : SensorData;
4
                                       out item cmd  : DriveCommand; }
5
    action execute: ExecuteCommand   { in  item cmd  : DriveCommand; }
6
7
    // Item flows: output of one action feeds into input of next
8
    flow sense.data  to plan.data;
9
    flow plan.cmd    to execute.cmd;
10
}

Binding parameters through the hierarchy

Outer action parameters can be bound to inner sub-action parameters using bind. This propagates values across the action boundary without creating a separate item flow object:

1
action def MissionPlan {
2
    in  attribute origin : GeoCoordinate;
3
    out attribute path   : Trajectory;
4
5
    action compute : ComputeTrajectory {
6
        bind compute.startPos  = origin;  // outer in binds to inner in
7
        bind compute.trajectory = path;   // inner out binds to outer out
8
    }
9
}

KerML origin: succession → Succession (a Connector);  if/else → decision / merge ControlNode;  fork/join → fork / join ControlNode

By default, sub-actions within a composite action have no defined execution order. They may run concurrently, in any sequence, or only once their data dependencies are satisfied. To impose explicit ordering, SysML v2 provides succession and higher-level control flow constructs that map to KerML Succession connectors and control node patterns.

Succession: explicit ordering

A succession between two actions means: the first action must finish before the second may start. This is the behavioural analogue of a connector in structure modelling — it is a KerML Succession, itself a specialisation of Connector:

1
action def EngineStart {
2
    action prime  : PrimeFuelSystem;
3
    action crank  : CrankEngine;
4
    action fire   : FireIgnition;
5
6
    succession prime  then crank;   // prime must finish before crank starts
7
    succession crank  then fire;    // crank must finish before fire starts
8
}

The first / then shorthand chains successions compactly:

1
action def EngineStart {
2
    action prime : PrimeFuelSystem;
3
    action crank : CrankEngine;
4
    action fire  : FireIgnition;
5
6
    first prime then crank then fire;  // equivalent to two succession statements
7
}

Conditional branching: if / else

An if block declares a decision node: a guard expression is evaluated, and exactly one branch executes. The KerML model is a DecisionNode control node with guarded outgoing successions:

1
action def HandleRequest {
2
    action validate  : ValidateRequest;
3
    action process   : ProcessRequest;
4
    action reject    : RejectRequest;
5
    action respond   : SendResponse;
6
7
    first validate;
8
    if validate.isValid {
9
        then process;
10
    } else {
11
        then reject;
12
    }
13
    // merge node implicitly recombines the two branches
14
    then respond;
15
}

Parallel execution: fork / join

A fork activates multiple sub-actions simultaneously. A join waits until all forked actions have completed before proceeding. These map to KerML fork/join control node patterns:

1
action def SystemInitialise {
2
    action loadFirmware   : LoadFirmware;
3
    action selfTest       : RunSelfTest;
4
    action calibrateSensors : Calibrate;
5
    action connectNetwork : ConnectNetwork;
6
    action reportReady    : ReportReady;
7
8
    // All four initialisation tasks run in parallel
9
    fork {
10
        then loadFirmware;
11
        then selfTest;
12
        then calibrateSensors;
13
        then connectNetwork;
14
    }
15
    // Wait for all four to complete, then report
16
    join then reportReady;
17
}

Loops

A loop repeats its body while a condition holds. At the KerML level this is a guarded succession cycle — a Succession whose source is the loop body and whose target is a DecisionNode that re-evaluates the condition:

1
action def PollSensor {
2
    action read    : ReadSensorValue;
3
    action process : ProcessReading;
4
5
    loop {
6
        first read then process;
7
    } while process.shouldContinue;
8
}

KerML origin: state def → StateMachine (specialises Behavior);  transition → TransitionUsage (a Succession)

A state machine models a system whose behaviour depends on its current state. In SysML v2, state def maps to a KerML StateMachine, which is itself a specialisation of Behavior. This means state machines are behaviours — they can appear as action usages, accept parameters, and be composed into larger action networks.

Defining states

Each state can have optional entry, do, and exit actions:

1
state def TrafficLightController {
2
    entry;   // initial pseudo-state — execution begins here
3
4
    state RED {
5
        entry action activateRed   : ActivateRedLight;   // runs when entering
6
        do    action holdRed       : HoldRedSignal;      // runs while in state
7
        exit  action deactivateRed : DeactivateLight;    // runs when leaving
8
    }
9
10
    state AMBER {
11
        entry action activateAmber : ActivateAmberLight;
12
    }
13
14
    state GREEN {
15
        entry action activateGreen : ActivateGreenLight;
16
        do    action holdGreen     : HoldGreenSignal;
17
    }
18
}

Transitions

A transition is a TransitionUsage — a KerML Succession that adds a trigger, an optional guard, and an optional effect action:

1
// Syntax: transition <source> accept <trigger> if <guard> do <effect> then <target>
2
3
state def TrafficLightController {
4
    state RED;
5
    state AMBER;
6
    state GREEN;
7
8
    entry; then RED;    // initial transition: start in RED
9
10
    // RED -> GREEN when timer expires
11
    transition RED
12
        accept TimerExpired
13
        then GREEN;
14
15
    // GREEN -> AMBER when timer expires or pedestrian button pressed
16
    transition GREEN
17
        accept TimerExpired | PedestrianRequest
18
        then AMBER;
19
20
    // AMBER -> RED unconditionally after short delay
21
    transition AMBER
22
        accept TimerExpired
23
        then RED;
24
}

Guard conditions and effects

1
state def SafetyController {
2
    state NORMAL;
3
    state DEGRADED;
4
    state SAFE_SHUTDOWN;
5
6
    entry; then NORMAL;
7
8
    transition NORMAL
9
        accept HealthCheck                 // trigger: fired by a HealthCheck event
10
        if systemHealth < 0.5           // guard: only fires when health is low
11
        do  action log : LogDegradation // effect: executed during the transition
12
        then DEGRADED;
13
14
    transition DEGRADED
15
        accept HealthCheck
16
        if systemHealth < 0.1
17
        then SAFE_SHUTDOWN;
18
}

Accept and send inside states

accept waits for an incoming message or signal. send dispatches one. They map to KerML AcceptActionUsage and SendActionUsage respectively:

1
state def CommandProcessor {
2
    state IDLE;
3
    state PROCESSING;
4
5
    entry; then IDLE;
6
7
    transition IDLE
8
        accept CommandReceived  // waits for a CommandReceived event
9
        then PROCESSING;
10
11
    state PROCESSING {
12
        do action work : ProcessCommand;
13
        exit action notify {
14
            send : CompletionSignal;  // sends a CompletionSignal on exit
15
        }
16
    }
17
18
    transition PROCESSING
19
        accept work.done
20
        then IDLE;
21
}

KerML origin: occurrence def → Occurrence (KerML Occurrence layer root);  snapshot → structural projection of an occurrence at a time instant

KerML’s Occurrence layer introduces two fundamental concepts that underpin everything in this module: occurrences (things that happen over a time interval) and snapshots (what an occurrence looks like at a single instant). Every action, state, and message in SysML v2 is ultimately an occurrence.

Occurrence definitions

occurrence def names a reusable type of happening — the most general form before you specialise it into an action or state machine. It is useful when you want to describe events or interactions without immediately committing to whether they are actions, states, or messages:

1
occurrence def SystemEvent;
2
occurrence def FaultEvent specializes SystemEvent {
3
    attribute severity  : Integer;
4
    attribute component : String;
5
}
6
7
occurrence def RecoveryAction specializes SystemEvent {
8
    attribute targetComponent : String;
9
}

Snapshots — structural slices through time

A snapshot captures the state of a part at a specific moment within an occurrence. It is a structural projection — a view of what attribute values and sub-part configurations hold at that instant. Snapshots are used in behavioural models to assert preconditions, postconditions, and invariants:

1
action def ChargeBattery {
2
    in  part battery : Battery;
3
4
    // Precondition: what battery looks like when charging begins
5
    snapshot startState {
6
        assert constraint { battery.stateOfCharge < 0.9 }
7
    }
8
9
    action doCharge : Charge;
10
11
    // Postcondition: what battery looks like when charging ends
12
    snapshot endState {
13
        assert constraint { battery.stateOfCharge >= 0.99 }
14
    }
15
}

Time slices and temporal ordering

Every occurrence has a time slice — its span from start to finish. SysML v2 inherits from KerML the ability to reference startShot and endShot projections of any occurrence, enabling constraints that span multiple actions:

1
requirement def ResponseTime {
2
    subject mission : MissionAction;
3
    require constraint {
4
        // The end of the mission must occur within 60 seconds of its start
5
        mission.endShot.time - mission.startShot.time <= 60[s]
6
    }
7
}

The following model integrates all four sections: a UAV autopilot behaviour combining sequential actions, data flow, a decision, concurrency, and a state machine for flight mode management.

1
package UAVBehaviour {
2
    private import ISQ::*;
3
    private import SI::*;
4
    private import ScalarValues::*;
5
    private import UAVSystem::*;  // parts from Module 3 worked example
6
7
    // ── Occurrences (shared event vocabulary) ───────────────
8
    occurrence def FlightEvent;
9
    occurrence def TakeoffCleared  specializes FlightEvent;
10
    occurrence def LandingCleared  specializes FlightEvent;
11
    occurrence def FaultDetected   specializes FlightEvent {
12
        attribute severity : Integer;
13
    }
14
15
    // ── State machine: flight mode ───────────────────────────
16
    state def FlightModeController {
17
        state GROUND;
18
        state TAKEOFF;
19
        state CRUISE;
20
        state LANDING;
21
        state EMERGENCY;
22
23
        entry; then GROUND;
24
25
        transition GROUND
26
            accept TakeoffCleared
27
            then TAKEOFF;
28
29
        transition TAKEOFF
30
            accept AltitudeReached
31
            if altitude >= 50[m]
32
            then CRUISE;
33
34
        transition CRUISE
35
            accept LandingCleared
36
            then LANDING;
37
38
        transition LANDING
39
            accept TouchdownDetected
40
            then GROUND;
41
42
        // From each state: fault triggers emergency
43
        transition GROUND
44
            accept FaultDetected
45
            if severity >= 2
46
            do  action log : LogEmergency
47
            then EMERGENCY;
48
        transition TAKEOFF
49
            accept FaultDetected
50
            if severity >= 2
51
            then EMERGENCY;
52
        transition CRUISE
53
            accept FaultDetected
54
            if severity >= 2
55
            then EMERGENCY;
56
        transition LANDING
57
            accept FaultDetected
58
            if severity >= 2
59
            then EMERGENCY;
60
    }
61
62
    // ── Action: sensor fusion (produces navigation estimate) ─
63
    action def SensorFusion {
64
        in  item gpsData    : GPSReading;
65
        in  item imuData    : IMUReading;
66
        out attribute navEstimate : NavigationState;
67
    }
68
69
    // ── Action: guidance (consumes nav, produces command) ────
70
    action def GuidanceLaw {
71
        in  attribute navEstimate : NavigationState;
72
        in  attribute targetWP    : Waypoint;
73
        out attribute motorCmds   : MotorCommandSet;
74
    }
75
76
    // ── Top-level autopilot loop ─────────────────────────────
77
    action def AutopilotLoop {
78
        in part uav : UAV;
79
80
        // State machine runs concurrently with the guidance loop
81
        action modeCtrl : FlightModeController;
82
83
        // Sensor fusion and guidance execute in sequence, in a loop
84
        action fuse   : SensorFusion;
85
        action guide  : GuidanceLaw;
86
        action actuate: ActuateMotors;
87
88
        // Data flow: fusion output feeds guidance input
89
        flow fuse.navEstimate to guide.navEstimate;
90
        flow guide.motorCmds  to actuate.motorCmds;
91
92
        // Control flow: sequence within each iteration
93
        loop {
94
            first fuse then guide then actuate;
95
        } while uav.flightMode != FlightMode::GROUND;
96
97
        // Precondition snapshot
98
        snapshot preCheck {
99
            assert constraint { uav.battery.health >= 0.2 }
100
        }
101
    }
102
}

This model demonstrates: occurrence def (shared event vocabulary), state def with triggers and guards, action parameters and item flows (sensor fusion pipeline), succession with first/then, loop with a termination condition, concurrent state machine alongside a sequential loop, and a snapshot precondition.