Skip to content
RigLink Remote
Demo mode, simulated J1939 data

Architecture

Two endpoints talk over one encrypted session: the vehicle side, which reads the truck's J1939 network, and the technician side, which shows it. In this demo both run in your browser, in separate Web Workers that share no memory and no keys.

RigLink Remote data pathsBrowser-only demo: a vehicle worker runs the simulator, produces J1939 frames and encrypts them; the link in the page carries ciphertext only; a technician worker decrypts, decodes and builds the view model for the console. Windows agent path: the agent reads an RP1210 adapter (an untested skeleton) or a simulated adapter and encrypts; a WebSocket relay carries ciphertext only; the browser technician decrypts and decodes. The encryption boundary surrounds the link and the relay.Encryption boundary: ciphertext onlyBrowser-only demo (this site)Vehicle workerSimulatorJ1939 framesEncrypt (AES-256-GCM)Link in the pageCarries ciphertext onlyOptional simulated delayDrop, tamper, replay testsTechnician workerDecrypt and verifyDecode J1939Build the view modelConsoleReact screensRead the view modelNo telemetry of its ownWindows agent and relayWindows agent (WPF)RP1210 adapter orsimulated adapterEncrypt (AES-256-GCM)RP1210 path is an untested skeletonWebSocket relayCarries ciphertext onlyHolds no session keysForwards between peersTechnician workerDecrypt and verifyDecode J1939Build the view modelConsoleSame screensSame view modelSame checks
Both paths use the same session protocol and the same technician code. Only the transport between the two sides changes.

Data path

The simulator produces a truck's engine values. The vehicle side encodes them as standard J1939 frames (EEC1, CCVS, ET1, EFL/P1, LFE, VEP1 and DM1), packs the frames and encrypts them. The link passes the encrypted bytes across.

The technician side decrypts, decodes the frames with its own J1939 decoder and builds the view model. The console screens only render that view model. Nothing on screen is generated by the interface itself.

Session security in plain language

The vehicle side creates an invitation: a link with a secret, plus a six-digit pairing code shown separately. The technician needs both. The two sides then run a key exchange (ECDH on P-256) and each proves it knows the invitation secret before either is trusted.

Every message after that is encrypted and authenticated with AES-256-GCM and carries a sequence number. A changed, replayed or misdirected message is rejected and never reaches the application. After a dropped link the session resumes with fresh keys. The link and the relay only ever see ciphertext.

What is simulated

The truck, its engine controller and the adapter are simulated. The engine model follows plausible physics at reduced demo rates. The engine controller is a virtual ECM that stores synthetic calibration images, checks every transferred block against its SHA-256 hash and keeps a journal so a flash can resume.

Fault thresholds, such as the coolant warning at 104 °C, are simulator settings. The round trip time shown in the console is measured through the in-page link, which adds a simulated delay.

What real hardware work remains

The Windows agent has an RP1210 adapter path that has not been tested with a physical adapter or truck. Connecting real hardware needs testing with specific adapters and vehicles, timing and bus load checks, and OEM-specific diagnostic and programming procedures, which differ by engine make.

Programming a real ECM also needs the manufacturer's security access and approved calibration files. The flash workflow here shows the checks and recovery behaviour a real tool needs; it does not program real controllers.

Launch live demoVehicle agent view