API protocole CAN — votre protocole reste le vôtre

Pourquoi la question du protocole bloque les projets

La plupart des projets télématiques s'arrêtent sur une phrase : il nous faut votre protocole CAN. Pour un OEM, cela signifie livrer une documentation interne à un fournisseur — avec un processus de validation. Le projet attend, et ce n'est pas la matériel qui bloque.

Notre réponse : nous ne le demandons pas

Votre protocole CAN reste chez vous. Vous définissez et détenez trames et signaux. Nous demandons seulement : quels points de données, quelle unité, quelle destination. Nous livrons les valeurs via une API.

• Aucun document de protocole requis.
• Aucune remise de DBC requise.
• Aucun firmware à nous confier — nous travaillons à la frontière des données.
• Vous restez portable — le contrat d'API vous appartient.

Ce que fait l'API

• Requêtes CAN planifiées à intervalle choisi.
• Envoi surveillé au changement plutôt qu'un flux permanent.
• Réglage à distance du débit et des points d'échantillonnage.
• FOTA A/B avec reprise et retour arrière.
• Mise à jour ECU/VCU par passthrough CAN (sur mesure).

Durée de l'intégration

Le premier point de données fonctionnel est généralement atteignable en environ un jour de travail commun, car l'interface est l'API et non votre protocole.

Questions à poser à tout fournisseur

• Avez-vous besoin de mon protocole CAN ou de mon DBC ?
• L'API est-elle documentée, avec un exemple de payload avant commande ?
• Qui mappe mes signaux internes ?
• Que se passe-t-il en cas de perte de connexion ?

Matériel : page CAN-vers-4G. Interfaces : télématique bus CAN.

FAQ

Avez-vous besoin de mon fichier DBC ?

Non. Le mapping des signaux reste chez vous ; nous utilisons les points exposés.

L'API est-elle documentée avant commande ?

Oui — nous envoyons un exemple de payload et la liste des champs.

Et si ma plateforme attend un autre schéma ?

Indiquez les champs cibles ; le mapping est convenu par écrit.