CAN-Protokoll-API — Ihr Protokoll bleibt Ihres

Warum die Protokollfrage Projekte stoppt

Die meisten Telematikprojekte hängen an einem Satz: Wir brauchen Ihr CAN-Protokoll. Für einen OEM bedeutet das, interne Dokumentation an einen Lieferanten zu geben — mit Freigabeprozess. Also wartet das Projekt, nicht wegen der Hardware.

Unsere Antwort: wir fragen nicht danach

Ihr CAN-Protokoll bleibt bei Ihnen. Sie definieren und halten Frames und Signale. Wir fragen nur: welche Datenpunkte, in welcher Einheit, an welches Ziel. Dazu bauen wir und liefern die Werte über eine API.

• Kein Protokolldokument nötig.
• Keine DBC-Übergabe nötig.
• Keine Firmware an uns — wir arbeiten an der Datengrenze.
• Sie bleiben portabel — der API-Vertrag gehört Ihnen.

Was die API tut

• Geplante CAN-Abfragen in wählbarem Intervall.
• Überwachte Übertragung bei Änderung statt Dauerstream.
• Fernparametrierung von Bitrate und Abtastpunkten.
• A/B-FOTA mit Wiederaufnahme und Rollback.
• ECU/VCU-Upgrade per CAN-Passthrough (kundenspezifisch).

Wie lange die Integration dauert

Der erste laufende Datenpunkt ist typischerweise in etwa einem Tag gemeinsamer Arbeit erreichbar, weil die Schnittstelle die API ist und nicht Ihr Protokoll.

Fragen an jeden Lieferanten

• Brauchen Sie mein CAN-Protokoll oder meine DBC?
• Ist die API dokumentiert, gibt es ein Payload-Beispiel vor der Bestellung?
• Wer mappt meine internen Signale?
• Was passiert bei Verbindungsabbruch?

Hardware: CAN-zu-4G-Seite. Schnittstellen: CAN-Bus-Telematik.

FAQ

Brauchen Sie meine DBC-Datei?

Nein. Das Signal-Mapping bleibt bei Ihnen; wir arbeiten mit freigegebenen Datenpunkten.

Ist die API vor der Bestellung dokumentiert?

Ja — wir senden ein Payload-Beispiel und die Feldliste.

Und wenn meine Plattform ein anderes Schema erwartet?

Nennen Sie die Zielfelder; das Mapping wird schriftlich vereinbart.