Platform · Remote Care
You don't send a truck. You send a packet.
Remote diagnostic. Remote reconfiguration. Signed remote remediation. Wired into every MOS4 device — ready for the moments when one immobilization costs more than the box.
What this replaces
One immobilization costs more than the device.
An ECU failure on an off-highway haul truck means production loss. A technician dispatch to an airport tug means a slot delay. A combine sitting idle in harvest week is a crop-window loss. Remote Care is the OS feature that converts a truck-roll into a packet.
Three tiers
Diagnose. Reconfigure. Remediate.
Tier 1
Diagnose at a distance
Live log retrieval via mos-logs — TAI64 range plus grep filter, streamed compressed. On-demand observability snapshots. No SSH, no SCP, no device-side tooling. For interactive ECU sessions — read, reset, reconfigure, reflash — see Remote Diagnostic.
Tier 2
Reconfigure remotely
Push a new MSP signal graph, a new MEP state-machine, a new geofence map, a new Multi Stacks scenario. Hot-reload without OTA — typically around ten seconds from end-of-edit to first successful service call on the device. Config persists across A/B rotation; rollback to the prior config is one signed call away.
Tier 3
Remediate remotely
A/B OTA with signed delta packages and automatic rollback. Bootcount-based revert on failed boot — no operator intervention required. Remote process restart and remote SoC reboot via the watchdog supervision chain. Remote re-flash with cryptographic attestation. Safety interlocks are not over-ridable from the remediation surface.
Predictive layer
Catch the failure before it stops the machine.
An MSP signal graph runs device telemetry through a fault-detection model on the device. Pre-failure signatures (overtemp drift, gearbox vibration anomaly, CAN bus error rate, OBD DTC bursts) emit alerts before the failure stops the machine. The AI Funnel pipeline retrains the detection model from fleet-aggregated signatures and OTAs the update — no firmware release, no fleet-wide flash window.
Predictive layer — device telemetry flows into an MSP signal graph running a fault-detection model; pre-failure events emit to the event bus and aggregate in the cloud across the fleet; the AI Funnel pipeline retrains, quantises, and OTAs an updated detection model back to every device.
flowchart LR D[Device telemetry] --> MSP[MSP signal graph<br/>fault-detection model] MSP --> EV[Event bus<br/>pre-failure alert] EV --> Cloud[Cloud aggregator<br/>fleet-wide signatures] Cloud --> AIF[AI Funnel<br/>retrain · quantise · OTA] AIF --> NEW[Updated detection model<br/>on every device] NEW --> MSP
Auth and audit
Every remote action is signed. Every action is logged.
Signed-action gate
MD21 uplink carries signed payloads. The on-device gate validates the signature and the operator identity before any remediation runs. Multi-party authorisation is available for sensitive actions. No anonymous super-user path.
Boot attestation
A/B rootfs is verified before any flash write. Bootcount-based revert means a failed remediation reverts automatically without operator action.
Per-action audit log
Every signed action emits a provenance record on the EventBus — actor identity, action type, target, timestamp, result. Suitable as evidence input for CRA-aligned auditing and for operator-side incident review.
Safety boundary
Hardware safety interlocks are not over-ridable from the remediation surface. Remote actions operate within the boundary set by the integrator's safety case. Remote Care is not autopilot.
Reference architecture
The remote-care surface, end to end.
End-to-end remote-care surface — cloud fleet manager or Munic-hosted console connects over MD21 to a signed-action gate; the gate fans out to the OTA agent (A/B partitions, delta packages, rollback), to hot-reload paths for MSP, MEP, Multi Stacks, and geofence maps, and to the logs and observer surfaces. Every path emits a per-action audit log; the audit log flows back to the cloud through the same MD21 uplink.
flowchart LR C[Cloud · fleet manager or<br/>Munic-hosted console] --> Up[MD21 secure uplink<br/>signed · attested] Up --> Gate[Signed-action gate<br/>multi-party where required] Gate --> OTA[OTA agent<br/>A/B · delta · rollback] Gate --> CFG[Hot-reload<br/>MSP · MEP · Multi Stacks · geofence] Gate --> LOG[Logs · Observer<br/>diagnostic surface] OTA --> Audit[Audit log<br/>per-action provenance] CFG --> Audit LOG --> Audit Audit --> Up Up --> C
Worked examples
Three moments where Remote Care pays for itself.
Haul truck · pre-failure
An MSP fault-detection graph flags an oil-temperature drift one hour before the truck would stall. The fleet operator schedules a maintenance window at the next shift change instead of recovering a stalled truck from the haul ramp at 03:00.
Airport tug · remote reboot
A tug stalls at gate 14 in the middle of a turnaround. A signed remote process restart recovers the affected micro service. If the SoC is wedged, a signed remote reboot restores a known-good state — the tug resumes service inside the slot window.
Combine · geofence remap mid-season
A new harvest plot opens late in the season. The operator pushes an updated 1,000-zone geofence map to the combine fleet via a single signed remote reconfigure — no firmware release, no truck roll, no harvester downtime.
Anti-claims
What Remote Care is not.
Not autopilot
Remote Care is operator-mediated and audit-logged. The OS does not take autonomous decisions on remediation. Sensitive remediations can require multi-party authorisation.
Not a separate SaaS
Remote Care is built-in OS capability. A managed fleet console (ekkofleet) exists as a separate Munic product; if you build your own fleet manager, you wire it to the same surface.
Cross-references
Related platform surfaces.
Multi Stacks
The workshop-tool replacement story — small-OEM mechanic console without a 10 k€ Vector tool. Different audience, same vehicle-bus surface.
Operations layer
The day-2 umbrella — observability, safety, OTA, remote control, lifecycle. Remote Care is one cross-cutting capability the operations layer surfaces together.
Compliance · CRA
Signed actions, audit logs, SBOM, and the SDLC pipeline form the evidence chain. The per-action audit log feeds the CRA-aligned posture.
Service tiers
Three plans wrap the surface above.
The OS capability is built in. The packaged service offering is a separate decision — three plan tiers wrap diagnostic, remediation, and predictive into a programme. Pricing and SLA scope are a sales conversation. Plan names below are draft and subject to change.
Tier 1
Munic Diagnostic
One-shot mechanic console — vehicle-bus surface, fault tree, log retrieval. Smallest commitment. Start here when the priority is in-workshop diagnostic work and the fleet uptime story is not yet on the agenda.
Tier 2
Munic Watch
Telemetry plus alerts. MD21 uplink, fleet-wide observability, MSP fault-detection surfaced on the dashboard. No remediation included — Watch sees; you act. For fleets where the observability gap is the binding constraint.
Tier 3
Munic Care
Watch plus signed remediation. The full surface — diagnose, reconfigure, remediate — with operator support and a service-level commitment. For fleets where the cost of one immobilization dwarfs the cost of the plan.
Plan-tier naming and pricing are sales-gated. This page does not commit to retail pricing or SLA scope — that conversation starts with the sales team.
Platform metrics
Key numbers.
FAQ
Frequently asked questions
-
Is Remote Care a separate product or a built-in capability?
Built-in OS capability. Every MOS4 device exposes the remote-care surface — the same signed-action gate, the same MD21 uplink, the same audit log. There is no separate licence, no separate agent, no separate fleet-side install.
-
How is this different from the Multi Stacks page?
Multi Stacks is the mechanic-tool replacement story — a small OEM substituting a 10 k€ Vector tool with a sub-1 k€ Munic device for in-workshop diagnostic work. Remote Care is the fleet-uptime story — preventing the immobilization in the first place, or recovering from it without dispatching a technician. Different audience, same underlying surface.
-
Can any operator trigger a remote action?
No. Every remote action passes through a signed-action gate. Authentication ties to the operator identity; the audit log records what was done, by whom, with what authorisation. Sensitive remediations can require multi-party authorisation. There is no anonymous super-user path.
-
Can Remote Care override safety interlocks?
No. Hardware safety interlocks are not over-ridable from the remediation surface. The OS executes operator-mediated, audit-logged remediations within the boundary set by the integrator. Remote Care is not autopilot, not unattended autonomous remediation.
-
What is the predictive layer based on?
An MSP signal graph runs on the device — telemetry plus fault-detection signal processing. Fleet-aggregated signatures train an updated detection model in the AI Funnel pipeline; the new model OTAs back to every device. Detection is configurable per programme; sensitivity is a tuning decision, not a fixed threshold.
-
How does this relate to ekkofleet?
ekkofleet.com is a turnkey fleet SaaS offered by Munic. It sits on top of MOS4 and uses the same remote-care surface. Remote Care is the built-in OS capability — the platform. If you want a managed fleet console, ekkofleet exists; if you want to wire MOS4 into your own fleet manager, the same remote-care surface is exposed.
-
Does it run on modem-class silicon?
Yes. The diagnostic and remediation tiers are runtime-light — they reuse mos-update, mos-rpc, mos-logs, mos-observer, and the existing micro service supervision chain. The predictive layer adds an MSP graph and an event correlator; this is still within the modem-class envelope.
Wire your fleet into Remote Care.
Fleet topology, vehicle classes, remediation policy, audit obligations — bring the constraints. Engineering will walk through the gate, the OTA chain, and the audit surface during the call.