A Model That Describes, and a Model That Answers

Two engineers each make a sensible decision.

The firmware engineer on the Fish On! rod sensor system sets the sensor to wake, send a short status message called a heartbeat, and go back to sleep every five minutes. The sensor runs on a coin cell, and a radio that is almost always off is what lets one cell last a season.

The software engineer sets the phone app to mark a rod weak when it has not heard from that rod in thirty seconds. An angler wants to know quickly if a sensor has gone quiet.

Both decisions are reasonable. Both are written down, one in the firmware and one in the app. Neither engineer made a mistake. Put them side by side and every working rod on the bank shows as weak.

The mistake exists only when the two are put side by side, and nothing in the project ever put them side by side. That is the problem this article is about.

Describing is not the same as answering

Most system models are descriptions. They say what the parts are, how they connect, what the behavior looks like and what the requirements say. A good one is accurate, well organized and pleasant to look at.

And when someone asks it a question, a person still has to go and work out the answer.

The questions people actually bring to a model are not “what does the diagram show?” They are questions like these:

Trace. Which requirement does this behavior exist to satisfy, and who cares about that requirement?
Impact. If the heartbeat interval changes, what else stops being true?
Verification. How would anyone know this requirement is met, and what would the test actually observe?
Classification. Which parts transmit radio energy and so fall under the radio regulators?
Consistency. Do any two things in this model contradict each other?

A model that can only describe leaves every one of those to a reader with time, attention and the whole model in their head. On a small system that is possible on a good day. On an aircraft it is not possible on any day.

A model that answers does that work itself. Ask it which parts are radio transmitters and it tells you, including the ones nobody labeled. Ask whether a design meets a requirement and it checks the numbers instead of repeating the claim. Ask whether the model contradicts itself and it says yes or no, and shows you why.

The same requirement, written to be checked

Here is the heartbeat problem as it appears in the Fish On! model in Models That Answer. Read :> as “is a kind of” and :>> as “in this design, this value is.” A line // ... marks where the excerpt skips part of the model.

part def RodSensor :> LoRaNode, BatteryPowered {
    // ...
    attribute heartbeatInterval : ISQ::DurationValue;
    // ...
}

part def PhoneApp {
    attribute weakAfter : ISQ::DurationValue;
    // ...
}

connection def StatusLink {
    doc /* The phone app showing the connection status of one rod. */
    end part rod : RodSensor;
    end part app : PhoneApp;
}

requirement <'FO-R01'> honestConnectionStatus {
    doc /* A rod that is reporting on schedule is never shown as weak. */
    subject link : StatusLink;
    frame trustTheStatus;
    require constraint {
        link.app.weakAfter > link.rod.heartbeatInterval
    }
}

part def RevBRodSensor :> RodSensor {
    attribute :>> heartbeatInterval = 300 [s];
    // ...
}

part revB : FishOnSystem {
    // ...
    part rod1 : RevBRodSensor :> sensors;
    // ...
    part phone : IosApp :> apps {
        attribute :>> weakAfter = 30 [s];       // the app's threshold
        // ...
    }
    // ...
    connection status1 : StatusLink connect rod1 to phone;
    // ...
}

satisfy honestConnectionStatus by revB.status1;
// ...

Three things make this different from a requirement in a document.

The requirement is a constraint, not a sentence. The doc line is the sentence. The require constraint is the part a program can evaluate: the app’s threshold must be longer than the rod’s heartbeat.

The numbers live in the same model. The heartbeat comes from the Rev B rod sensor design. The threshold comes from the phone in the Rev B kit. Nobody has to copy either value into a spreadsheet to compare them.

The satisfy line is a claim that can be checked. In most toolchains a line like that becomes a row in a traceability matrix, and nobody looks at it again. Here the requirement and the design’s numbers are in one place, so the claim can be tested against them.

Asking it

The examples in the book are answered by the SysML v2 Semantic Reasoner, run over the model file. Here is the question the angler would ask, with the answer exactly as printed in the book:

ssr ask FishOn.sysml -- "does revB.status1 satisfy honestConnectionStatus"

CONTRADICTED — No. revB.status1 is claimed to satisfy honestConnectionStatus and
breaches it.
  revB.status1  [ASSERTED]  claimed to satisfy honestConnectionStatus, and does
                            not

The answer is not “probably not” and it is not a warning. It is a contradiction: the model claims something its own numbers refute. Thirty seconds is not greater than three hundred.

That is the whole difference in one exchange. A model that describes would hold both numbers and the requirement, and the conflict would sit in it unnoticed until someone happened to read the right three places together. A model that answers finds it when asked, before the kit leaves the bench.

“No” is not the only answer

A model that answers also has to be honest about what it does not know. Here are two more questions from the same chapter.

The phone has a radio, of course, but the model has not said anything about it transmitting:

ssr ask FishOn.sysml -- "is revB.phone a RadioTransmitter"

NOT_ENTAILED — phone : RadioTransmitter is not entailed. Under the open-world
assumption that does not make it false — nothing in the model rules it out.

Not “no.” The model is silent, and the answer says so. SysML v2 does not assume a model is complete: anything the model does not say is unknown, not false.

And a requirement whose input nobody has measured yet, the largest jolt that wind, waves or a bumped rod produce:

ssr ask FishOn.sysml -- "does revB.rod1 satisfy wakeThresholdAboveDisturbance"

UNKNOWN — Neither. revB.rod1 is claimed to satisfy wakeThresholdAboveDisturbance
and the claim could not be checked: no value is stated for disturbancePeak. This
is not a pass and it is not a failure.

This is the answer that matters most in practice. A tool that treated “no value” as “no problem” would report that requirement as met. A model that answers says exactly what is missing, so the gap is a task on someone’s list rather than a pass on someone’s report.

What it takes

None of this needs exotic modeling. Everything in the excerpt above is ordinary SysML v2: part definitions, attributes with units, a connection, a requirement with a subject and a constraint, and a satisfy claim. What makes the model answer is a handful of habits:

Write the requirement as a constraint over named values, not only as prose. The doc text is for people; the constraint is for the check.
Put the design values in the model, on the parts that own them, with units. A threshold that exists only in the app’s source code cannot be compared with anything.
Make the claim explicit. A satisfy line says which part of the design is supposed to meet which requirement, and that is what gets checked.
Keep one copy. The moment the numbers live in a second document, the model is describing a system that may no longer exist.

Fixing the contradiction is still an engineering decision, with a battery on one side and an angler’s patience on the other. The model does not make it. It makes sure the decision gets made on purpose, before the boards ship, rather than discovered on a riverbank at two in the morning.

The book

This is the opening idea of Models That Answer: A Practitioner’s Guide to Model-Based Systems Engineering with SysML v2. The book builds the whole Fish On! rod sensor system as one SysML v2 model, from stakeholders and requirements through behavior, verification and analysis, and every chapter ends by asking that model questions and printing its answers.