A Model That Describes, and a Model That Answers
Most system models describe the system and leave every real question to a reader. Here is what changes when the model can be asked, using one requirement from the Fish On! rod sensor system.
Writing
Articles
Long-form pieces on modeling practice — what SysML v2 and modern tooling make possible, and how to build models that hold up.
Cross-Cutting: When the Answer Isn't a Subtree
Every model has one containment hierarchy, chosen for one purpose. Safety, security, thermal and certification scope all cut across it — and understanding why decides what your model can actually answer.
Four Ways to Constrain an Action in SysML v2
A use case tells you whether a step happened. Constraints are how you say how well it was performed — and there are four places a constraint can read from, only one of which needs an output parameter.
Nominal, Alternate, Exception: Routes a Model Works Out for Itself
A derived state machine arrives already colored by route — green, blue and red. Only one thing in the source model was ever annotated. Here is how the other two colors are computed, and why the stamps that carry them are deliberately not semantic metadata.
Performance, Safety and Security Constraints in SysML v2
How fast, how safe, how protected — none of it comes out of a behavioral model, and it shouldn't. Here is the vocabulary for writing those constraints so they are worth having.
Semantic Metadata: Making a SysML v2 Model Queryable Like an Ontology
A keyword that implies a type relationship turns your architecture model into something you can also reason over — cross-cutting classifications that inherit, and queries you could not otherwise write.
Modeling a Verifiable Use Case
How to write a SysML v2 use case so that requirements and verification cases can be derived from it — and so that what comes out can actually be tested at the boundary.
The Derivation Ladder
Eighteen constructs, added to a use case one at a time, and exactly what each one turns into downstream. The map nobody prints, with the real numbers attached.
From Behavior to Proof
A model can be turned into requirements automatically. Making those requirements testable is a different problem — and the answer starts by asking what you could actually see from outside the box.