Integration engineers
Which component started the failure?
PULSAR names the origin and shows the evidence for it, so nobody has to assemble that by hand out of separate supplier deliveries.
Root-Cause Analysis
What happened in run 4711 — and what started it?
Ask in your own words. PULSAR reads the behavioral model, rebuilds what “normal” looks like from your own runs, and names the component the deviation started in.
run 4711 Ask
Symptom
Display frozen
HMI Cluster · 14:32
Origin
searching
Charge Controller
published charge_state late
System model
- Traces, logs and metricsrun 4711
- System model4 units · 41 signals
- Reference runssoftware 7.4 · 96 runs
- Learned rangesper signal · 11,412 intervals
Measured against learned normal
charge_state publish interval
41.0 ms
learned 9.6–12.4 ms
cause · Charge ControllerCPU load · Charge Controller
91 %
learned 38–52 %
cause · Charge ControllerSOME/IP 0x8021 rate
9.4 /s
learned 8.0–11.2 /s
CAN 0x2A1 cycle time
20.1 ms
learned 19.8–20.3 ms
Ready
Ask
Describe what you saw. Not what you think caused it.
"My display got frozen around 14:32 in run 4711." That is a complete question
An engineer writes what they observed, in their own words, and picks the run. PULSAR resolves that to a moment and to the components involved, based on the system model it has already built, and returns what it found. No query language to learn, and no need to know where to look before you can start looking.
Every engineer asks directly
Detect
The run passed. Something still changed.
Normal is learned from your system's own history — not set as a threshold somebody had to guess in advance
PULSAR builds its reference from the runs a program already produces, then compares against it: one run against a software version, one version against the one before it, or two setups that were supposed to be identical and are not. That is what makes behaviour visible when it fails in only a minority of runs, or drifts without ever crossing a limit — the cases no single passing run reveals and no threshold catches.
Defects found in days, not weeks
Explain
A display is where a fault is noticed. It is almost never where one starts.
The analysis starts at the symptom and runs backwards in time
The signal travelled forwards: published, forwarded, displayed. The investigation travels the other way. PULSAR begins at the one thing somebody actually observed — the frozen display at 14:32 — and steps back along the propagation it recorded, unit by unit and across domain and supplier boundaries, ranking the origins that remain possible at each step. It stops at the unit whose behaviour is not explained by anything upstream of it. Each finding arrives as a plain-language claim with what it rests on: the events involved, the timing between them, the components affected. Every answer comes from runs that actually happened, and any value in it can be followed down to the log line it was read from — so an engineer checks the answer instead of trusting it, and marks what turns out to be expected, which sharpens what PULSAR raises next time.
An answer, where there used to be a search
Report view
Also available as a classic report on the health of your runs
Like a blood panel: each value, what it measured, and the range this system is normally in. You name the baseline, normal is learned from the runs you put in it, and any line opens down to the log line it was read from.
Detected anomalies
2 outside the baseline · 5 values measured
Timing
Charge status update interval
High41.0 ms
normal 9.6–12.4 ms
Measurements
Processor load · Charge Controller
High91 %
normal 38–52 %
No test in this build failed
Who benefits
Testers
The test passed. Did anything change?
Timing, load and messages nobody expected turn up in the comparison, before they become somebody else's integration problem.
Release leads
Can we ship this build?
Decide the gate on how the system behaved in its runs, not on what was reported upward.
Architects
Is the system still built the way we designed it?
See the architecture as built, and where it drifted from the last version and from the intended design.
Supplier managers
Whose problem is this?
PULSAR points at the supplier whose component is actually in the path, so the work lands with the team that owns it.
FAQ
A material difference from the learned reference — in timing, in the set or order of events, in communication behaviour, in a measured value, or in the structure itself. It is a signal to look, not a verdict: it can also reflect a deliberate change, or a reference that does not yet hold enough runs to be trusted.
An engineer marks them, and that judgement carries forward. Accepted differences stop competing for attention with new ones.
No. PULSAR identifies where a problem originates and shows the evidence for it. The fix stays an engineering decision.
No. A test checks a condition somebody wrote in advance. PULSAR has none: you choose the set of runs that defines normal, it derives the reference from what those runs actually did — timing, order, communication, measured values — and flags what falls outside it. That is how it catches what nobody wrote an assertion for: a step that got slower without ever crossing a limit, an order that changed, a value that drifted across releases. In builds where every test passed.
Yes, and that is the point. Every finding names what it rests on, and each value in it reaches the specific log line it was read from. There is no tier where the explanation stops and you have to take PULSAR's word for it.