Modularer Protokollanalysator

Protokolle sehen,
verstehen, dekodieren.

Trace erfasst serielle Byte-Streams in Echtzeit und macht sie als strukturierte Telegramme sichtbar — RS232, USB-Serial, CAN, SPI. Eigene Protokolle beschreibst du rein deklarativ in TrIML, ganz ohne eine Zeile Code.

Echtzeit-Capture < 1 ms Hot-Path 32 Protokolle out of the box Cross-Platform · C99 + .NET 10
32+
Fertige Protokoll-Interpreter
<1ms
Match-Latenz im Hot-Path
0×
Zeilen Code für neue Protokolle
Lock-free SPSC-Capture-Pipeline
Vom Rohbyte zum Telegramm

Rohdaten rein. Struktur raus.

Trace nimmt den nackten Byte-Strom von der Leitung und liefert vollständig interpretierte Telegramme — mit Feldern, Enums, Prüfsummen und hierarchischen Beschreibungen. Live, persistiert und durchsuchbar.

// Eingang · Byte-Stream
02 01 05 48 45 4C 4C 4F 03  02 02 03 9A 1B 04 03
02 01 03 4F 4B 21 03  02 01 05 57 4F 52 4C 44 03
A4 C1 02 01 … // fortlaufend, mehrere Ports
// Ausgang · Strukturierter Frame
▾ Status-Telegramm ✓ CRC ok
STX 0x02
Type Status (0x01)
Length 5
Payload "HELLO"
ETX 0x03
Funktionen

Ein Werkzeug für die ganze Leitung.

Erfassen, dekodieren, durchsuchen, triggern, aufzeichnen — und über den Hub aus der Ferne. Alles in einer Oberfläche.

Deklarativ · TrIML

Interpreter ohne Code

Felder, Verzweigungen, Prüfsummen und Enums in XML — die Engine wertet sie zur Laufzeit aus und tauscht laufende Ports per Hot-Swap.

Echtzeit-Capture

Lock-free SPSC-Ring-Buffer im Hot Path. Jedes Byte bekommt einen atomaren Millisekunden-Zeitstempel — exakte Delta- und Dauerberechnung ohne Sekundengrenzen-Fehler.

Suche & Filter

Volltextsuche über alle Telegramme mit O(log n)-Navigation, kombinierbaren Port-Filtern und Live-Treffern — direkt im laufenden Stream.

Trigger & Lua

Deklarative Predicates oder NLua-Skripte werten jeden Frame aus — mit eigener Hit-Liste pro Trigger.

Self-Contained Sessions

Jede Aufnahme liegt komplett in einer .msf-Datei — inklusive fertiger Interpretation. Kein Interpreter nötig zum Öffnen.

Remote über den Hub

Sicherer Zugriff auf Probes und Nodes hinter NAT/Firewall — Ed25519-signiert, ohne eingehende Portfreigabe, mit Live-Dashboard.

TrIML · Trace Interpreter Markup Language

Schreib das Protokoll. Nicht den Parser.

Eine vollständige TrIML-Definition — und der Frame, den die Engine daraus zur Laufzeit erzeugt. Risikofrei testbar über POST /api/interpreters/dryrun.

my-interpreter.triml.xml
<?xml version="1.0" encoding="utf-8"?>
<Trace-Interpreter-Definition>

  <interpreter name="My-Interpreter" type="FrameOriented" />

  <definition>
    <!-- Wertetabelle (Enum) -->
    <valuedescriptor type="byte" name="type-desc">
      <descriptor value="0x01" label="Status" />
      <descriptor value="0x02" label="Command" />
    </valuedescriptor>

    <!-- Das Telegramm -->
    <message>
      <const type="byte" value="0x02" name="STX" />
      <byte  name="Type" valuedescriptor="type-desc" />
      <byte  name="Length" />
      <array sizeRef="Length" name="Payload" />
      <const type="byte" value="0x03" name="ETX" />
      <match label="Frame" />
    </message>
  </definition>
</Trace-Interpreter-Definition>
▸ dryrun · 02 01 05 48 45 4C 4C 4F 03
Frame matched
STX 0x02
Type Status (0x01)
Length 5
Payload48 45 4C 4C 4F"HELLO"
ETX 0x03
Dieselbe Definition läuft live: PUT auf einen aktiven Port und die Ports werden im Betrieb umgeschaltet — keine Neustart-Pause.
Architektur

Eine Pipeline von der Leitung zum Browser.

Native C99-Capture-Engine, .NET-10-Server mit Interpretern, Echtzeit-Push per SignalR — bis in die WASM-Oberfläche.

01 · HARDWARE

Serial · USB · CAN · SPI

Physische Interfaces liefern den rohen Byte-Strom.

02 · BYTECAT (C99)

Capture-Engine

Plugins, SPSC-Pipes, Zeitstempel, FileWriter → .bin.

03 · TSERVER (.NET 10)

Interpreter & REST

32 Interpreter, 6 Controller, SignalR-Hub, Sessions.

04 · CLIENTS

TraceUI · CLI

WASM-Oberfläche auf Canvas, CLI und Desktop-App.

Topologie

Viele Messorte, mehrere Knoten — ein Hub in der Mitte.

Gemessen wird dort, wo die Leitung liegt. Gerechnet wird dort, wo die Maschine steht. Verwaltet wird alles an einer Stelle: Probes an den Messorten liefern Bytes, Nodes betreiben die Worker, und der Hub hält als übergeordnete Ebene beide Seiten zusammen.

Topologie von Trace: entfernte Probes, entfernte Nodes und der zentrale Hub Links stehen drei Probes an verschiedenen Messorten — zwei TraceProbes und eine Mini-Probe. Jede baut eine ausgehende Verbindung zum Hub in der Bildmitte auf und liefert Bytes. Rechts stehen drei Rechenknoten: ein Cloud-Node beim Betreiber und zwei Bring-Your-Own-Nodes beim Kunden. Der Hub erreicht sie über den vom Node aufgebauten Tunnel und startet dort je Session einen Worker. Unterhalb des Hubs hängt die TraceUI im Browser, die ausschließlich über die Proxy-Pfade des Hubs auf ihren Worker zugreift. MESSORT · KUNDENNETZ ZENTRAL · ÜBERGEORDNET NODES · RECHENKNOTEN HTTPS · nur über Hub-Pfade TraceProbe Werk Nord · Halle 3 RS232 · USB-Serial TraceProbe Prüfstand 2 · mobil CAN · SPI Mini-Probe Embedded-Firmware TCP · ohne SignalR bis zu 16 Probes je Session nur ausgehende Verbindungen Cloud-Node Betreiber · Container Quota · Auto-Stop BYO-Node Kundenhardware Worker + MSF lokal BYO-Node Werk Süd · Dienst kein offener Port ein Worker-Prozess je Session die .msf bleibt auf dem Node TRACE HUB CONTROL PLANE Sessions, Mandanten, Tarife Pairing und Vertrauen (Ed25519) Routing in die laufende Session Der einzige Zeitgeber im System verarbeitet selbst keine Trace-Daten Bytes · ausgehend Node-Tunnel TraceUI im Browser Blazor WASM · auf Canvas
PROBE → HUB

Die Probe wählt den Hub an, nie umgekehrt. Bytes und Steuerung laufen über dieselbe ausgehende Verbindung — hinter NAT und Firewall bleibt damit jeder Port zu.

HUB → NODE

Auch der Node baut den Tunnel nach außen auf. Der Hub nutzt ihn in Gegenrichtung: er startet dort je Session einen Worker und reicht die Bytes durch.

HUB → BROWSER

Die Oberfläche spricht nie direkt mit einem Worker. Jeder Aufruf geht über die Proxy-Pfade des Hubs, der Besitz und Session-Token prüft.

Entfernt · am Messort

Probes

Ein eigenständiger Prozess direkt an der Hardware. Er hält die native Capture-Engine am Leben, gibt jedem Byte lückenlos Index und Zeitstempel und schiebt den Strom nach außen. Mehrere Probes an verschiedenen Orten können gleichzeitig in eine Session liefern — die Zeitbasis dafür kommt vom Hub.

  • Ed25519
  • Gerätecode-Pairing
  • RS232 · USB · CAN
  • 16 je Session
Entfernt · wo gerechnet wird

Nodes

Ein Node ist die Maschine, auf der die Worker laufen — je Session ein eigener Prozess, der Frames erkennt, sie in die Session-Datei schreibt und ausliefert. Bei Bring Your Own Node gehört diese Maschine dem Kunden: Rechenlast und Aufnahme bleiben im Haus, und geöffnet wird dafür kein einziger eingehender Port.

  • 1 Worker je Session
  • Cloud oder BYO
  • kein Inbound-Port
  • .msf bleibt lokal
Zentral · übergeordnet

Der Hub

Die Ebene über allem: Konten und Mandanten, das Pairing von Probes und Nodes, Start und Ende jeder Session, das Routing vom Browser in genau den richtigen Worker. Trace-Daten verarbeitet er dabei selbst nicht — er vermittelt sie nur. Und er ist der einzige Zeitgeber, damit Zeitstempel über alle Messorte hinweg vergleichbar bleiben.

  • Sessions & Quoten
  • Reverse-Proxy
  • Zeitgeber
  • Browser-UI

Beschreib dein erstes Protokoll.

Die TrIML-Referenz führt vom ersten Telegramm bis zur vollständigen Element-Referenz — mit Mustern, Beispielen und Live-Test.