EARS Syntax for Signal-Level Requirements

The five patterns, and why signals strain them

EARS — the Easy Approach to Requirements Syntax, introduced by Mavin et al. at Rolls-Royce — constrains requirement text to five templates. The value is not the prose. It is that each template forces you to state a trigger condition explicitly, and an unstated trigger is where signal-level requirements usually fail review.

Pattern	Template	Signal-level failure mode
Ubiquitous	The <system> shall <response>	Overused. Becomes a dumping ground for requirements whose trigger nobody worked out.
Event-driven	WHEN <trigger> the <system> shall <response>	"When the signal is received" hides whether it means a new frame, a changed value, or a rising edge.
State-driven	WHILE <state> the <system> shall <response>	Bus states are rarely enumerated, so WHILE clauses reference states with no definition anywhere in the model.
Unwanted behaviour	IF <condition>, THEN the <system> shall <response>	The one that matters most on a bus, and the one most often missing: timeout, CRC failure, counter stall.
Optional feature	WHERE <feature> the <system> shall <response>	Variant coding is usually in a spreadsheet rather than the model, so the feature name is unresolvable.

A worked example

Take a torque request signal on a powertrain bus. A DBC file gives you the message, the signal, its bit layout, scaling and range — but nothing about timing or failure behaviour. A first-draft requirement usually reads:

The powertrain controller shall read the torque request signal.

That is ubiquitous form. It states no trigger, no timing, and no failure behaviour, and it is untestable as written. What the DBC actually implies is at least three separate requirements, in three different EARS patterns:

WHEN a TorqueRequest frame is received with an incremented rolling counter,
          the powertrain controller shall latch TorqueReq_Nm within 10 ms.
          
          WHILE the vehicle is in Propulsion Enabled state,
          the powertrain controller shall reject TorqueReq_Nm values outside 0..400 Nm.
          
          IF no TorqueRequest frame is received for 100 ms,
          THEN the powertrain controller shall apply zero torque and set TorqueReqTimeout.

The third one is the requirement that keeps a vehicle safe, and it is the one no signal database will ever hand you. The bus definition describes the nominal case. The unwanted-behaviour requirements come from the hazard analysis, and they have to be written deliberately.

Checking conformance

Pattern conformance is checkable with a classifier far simpler than a language model. Each pattern has a distinguishing leading keyword and a required clause structure:

WHEN  <trigger>   ,  the <system> shall <response>   → event-driven
          WHILE <state>     ,  the <system> shall <response>   → state-driven
          IF    <condition> , THEN the <system> shall <response> → unwanted behaviour
          WHERE <feature>   ,  the <system> shall <response>   → optional feature
                               the <system> shall <response>   → ubiquitous

Anything that parses as ubiquitous but describes reactive behaviour is a defect worth flagging, because it means a trigger was dropped. A useful metric on a real programme is the ratio of unwanted-behaviour requirements to event-driven ones. If it is near zero, the failure cases have not been written yet.

Where VectorMBE stands on this

Worth being precise, because it is easy to overclaim. VectorMBE's requirements generator prompts for EARS patterns when drafting from model elements, and the CAN DBC importer gives it the signal structure to draft against — messages, signals and their classification as vmbe:Signal in the ontology.

What it does not currently have is a server-side EARS grammar or validator. Generated requirements are reviewed by an engineer, not machine-checked for pattern conformance, and a generator asked for EARS will still return ubiquitous prose some of the time. Treat pattern conformance as a review step you own, not one the tool closes for you. A classifier of the kind sketched above is on our list precisely because prompting alone does not guarantee the grammar.