Appendix J: Occurrences, Time Slices, and Snapshots

The chapters model a coffee machine: what it is made of, what it does, what it must satisfy. What they do not dwell on is that a machine, a brew, and a fault are all things that happen over time, and that SysML v2 has a specific family of constructs for saying so.

You can build a great deal without them. Reach for them when time itself becomes part of what you are modelling – phases of an operation, the state of something at an instant, or one particular real-world unit as opposed to the kind.

Occurrences

occurrence def <Name>;
occurrence <name> : <OccurrenceDef>;

occurrence def BrewCycle;

An occurrence is something that happens or exists over an interval of time. occurrence is its kind keyword, and it works like every other kind keyword you have met – occurrence def for the definition, occurrence for a usage (SysML §7.9.2).

You have been using occurrences all along without naming them. Actions and states are occurrence usages of more specialized kinds: that is what lets a state have a duration and an action have a start and an end. This appendix is about the layer underneath them.

An occurrence usage may only be typed by an occurrence definition of some kind, or by a KerML class.

Time slices and snapshots

timeslice <name>;          // equivalent to `timeslice occurrence <name>`
snapshot  <name>;          // equivalent to `snapshot occurrence <name>`
timeslice <kind> <name>;   // e.g. `timeslice part activeSection`

occurrence def BrewCycle {
    timeslice grinding;
    timeslice heating;
    timeslice extracting;

    snapshot extractionStart;
}

Read it as: a brew cycle has three phases and one instant worth naming.

A time slice is a portion of an occurrence over an interval – the grinding phase of a brew. A snapshot is a portion at a single instant – the moment extraction begins. Both are written by putting the keyword immediately before the kind keyword of the declaration, and both may stand in place of the kind keyword, in which case they mean timeslice occurrence and snapshot occurrence (SysML §7.9.3).

One rule to remember: a time slice or snapshot must be declared inside the body of an occurrence definition or usage. It is a portion of something, so there has to be a something.

The distinction is worth keeping straight because it is the difference between a duration and an instant. “While heating” is a time slice. “At the moment the pump started” is a snapshot. A constraint on a temperature rise belongs to the former; a constraint on a temperature reading belongs to the latter.

Individuals

individual def <Name> :> <OccurrenceDef>;
individual <kind> def <Name> :> <Def>;

part def Grinder;
individual part def Grinder_SN0417 :> Grinder;

occurrence def BrewCycle;
individual def BrewCycle_20260821_0730 :> BrewCycle;

An individual definition describes exactly one thing in the world, rather than a kind of thing. Grinder is a kind; Grinder_SN0417 is the grinder on the bench with that serial number. BrewCycle is a kind of operation; the second declaration is the brew that ran at half past seven.

Like timeslice and snapshot, the keyword goes immediately before the kind keyword, or in place of it (SysML §7.9.4).

A usage counts as an individual usage when its definition is an individual definition – you do not have to mark the usage. And a usage may not have more than one individual definition, which follows from what an individual is: two “exactly one thing” claims about the same usage would contradict each other.

This is the construct to reach for when the model has to talk about real units – a serial-numbered part, a specific test run, an incident that actually happened – rather than the design.

Event occurrences

occurrence def BrewCycle {
    event occurrence pumpOn;
}

An event occurrence marks a point of interest within an occurrence (SysML §7.9.5). It is what the from and to ends of a message name, which is why Appendix G mentions them under flows: a message runs between two events rather than between two features.

Where this shows up elsewhere

• Successions and the HappensBefore association order occurrences in time. Chapter 7 covers successions.
• States and actions are occurrence usages, which is why they have durations and boundaries. Chapter 8, Chapter 7.
• The standard library’s Occurrences package declares the machinery – including HappensBefore, and the startShot / endShot / snapshots structure that gives every occurrence its boundaries. Chapter 14.