The runtime, on the record.

Works today with the debug probe already on your desk.

The trace is the test.

A capture is a record, so every number in it is something a build can be measured against. Give a metric a baseline and a tolerance and it becomes a gate: the run that drifts past it fails, and the trace that proves it is attached to the failure. No screenshot, no one remembering what last month looked like.

Everything the panels show is reachable headless, so this runs on real hardware in CI the same way it runs on your desk: boards, transports and probe combinations as a matrix, one row per case, with stable output lines and exit codes to assert on.

• Timing, footprint, event counts and pipeline cost, tracked per run
• Baseline, tolerance band and a gate line on every metric
• Hardware in the loop, one case per board and transport

Freeze the run you trust.

A fingerprint is a known-good capture boiled down to a small file you commit next to the code: CPU share per task, timing stats per trace, stack high water marks, heap peak, event rates and per-function ETM timing, each carrying its own tolerance. It stores expectations, not just values.

Load a baseline during a live session and every capture is judged the moment it lands: each metric gets a pass, warn or fail verdict against its own thresholds, and pinned runs let you compare candidates mid-session. The exact same compare runs headless and exits nonzero on a fail, so the gate in CI and the verdict on your desk can never disagree.

• Learns tolerances from several good runs instead of guessing them
• Gate on exactly the metrics you choose, with advisories on ones that gate poorly
• Counts compare as per-second rates, so captures of different lengths compare fairly

Follow the message, not just the task.

RTOS bugs love the space between tasks: a queue that backs up once an hour, a notification that lands late, a mutex held a little too long. The Comms panel pairs every send with the receive that consumed it, queue messages in FIFO order, notifications by peer, semaphore gives with takes, mutex acquires with releases, and groups them into paths: this producer, through this object, to this consumer.

Each path is a row you can sort by rate, median and p99 latency, worst case, blocking or failures. Open one and you get the full-capture latency scatter with backlog peaks marked, then click a single exchange and see its anatomy: time in the queue, time in the consumer, end to end, with one click jumping the timeline to that exact moment.

• Failures are first class: full-queue sends, wait timeouts and dropped events are counted per path
• Unmatched events are classified, never hidden: a poll timeout looks different from a message still in flight
• The same per-path stats print from the headless CLI, so a latency budget can gate CI

Make ViewAlyzer understand your technology.

Your product is more than an RTOS and a stream of generic user events. If your silicon, SDK, middleware or internal platform has behavior worth understanding, an OEM Trace Domain can make those concepts native to ViewAlyzer.

A wireless vendor can expose connection state, radio activity and protocol transactions. A motor-control team can surface control-loop phases and fault recovery. A proprietary runtime can get its own objects, relationships and timing rules. Engineers see the language of the product instead of event IDs and printf strings.

• Dedicated event schemas, decoders and protocol-aware timelines
• Domain-specific statistics, filters, relations and visualizations
• Private enterprise extensions or vendor-distributed integrations
• Optional recorder-side instrumentation and long-term compatibility support