Home / Intégrer une application BLE TPMS dans son propre produit

Quand un OEM évalue un capteur BLE TPMS, la discussion commence par la précision de pression et finit par la spécification radio. Ce qui échoue vraiment se situe entre les deux : à l'interface entre le capteur et ce que l'utilisateur regarde.

Vous n'achetez pas un capteur, vous achetez un chemin de données

• Sur un système à écran, cette interface est un câble et un écran que le fournisseur vend avec. En BLE, c'est un protocole radio et une application.
• Les deux se négocient, et les deux devraient être réglés avant l'outillage, pas après.

Trois voies d'intégration

• Voie un : l'application du fournisseur. Le capteur arrive avec une application qui fonctionne. Vous mettez votre marque sur l'emballage et le client télécharge une application généraliste. Le plus rapide pour le marché, le plus faible en appropriation de marque : la relation du client au logiciel appartient à quelqu'un d'autre.
• Voie deux : une version marquée de l'application du fournisseur. Fonctionnellement celle du fournisseur, mais avec votre nom, vos couleurs et vos seuils. Le compromis habituel pour un distributeur avec un catalogue et sans équipe logicielle.
• Voie trois : votre application, le capteur comme composant. Le capteur devient un périphérique de votre produit ; votre application lui parle via le service BLE et tout ce que voit l'utilisateur est à vous. C'est la bonne voie pour un OEM qui a déjà une application, ou pour qui vend l'application plutôt que le matériel.
• La voie choisie détermine ce qu'il faut cadrer : la trois exige une documentation de protocole, du code d'exemple et une politique de versions de firmware.

Ce qui peut être adapté

• Pour les programmes OEM, nous pouvons adapter le service BLE et le format de données. Concrètement :
• Service et caractéristiques — définitions, valeurs lues, valeurs notifiées, selon l'architecture de votre application.
• Format de données — disposition des octets, mise à l'échelle, unités, drapeaux, horodatages, selon votre parseur et votre schéma cloud.
• Advertising et identité — ce que le capteur annonce, comment les appareils sont nommés et filtrés ; important avec plusieurs capteurs par véhicule et en flotte.
• Comportement d'alarme — seuils, hystérésis, conditions déclenchantes, selon marché et classe de véhicule. Image de l'application — nom, icône, couleurs, mise en page, langues. Marquage du capteur — laser, y compris vos références et la position de roue.
• Ce qui n'est pas négociable, c'est la mesure physique : l'élément sensible, la chaîne de mesure et le calibrage de pression sont le produit. L'adaptation se fait au-dessus de cette ligne.

L'état de l'application, dit clairement

• Android est disponible. L'APK se télécharge aujourd'hui : une intégration Android peut être évaluée immédiatement sur du matériel réel.
• iOS n'est pas encore publié. À la date de rédaction, il n'y a pas de version iOS à remettre. Si votre plan produit suppose une application iPhone à court terme, cette hypothèse doit être testée avec nous, pas reprise d'une brochure.
• Nous préférons l'écrire plutôt que de laisser un programme le découvrir trois mois plus tard. Si iOS est sur votre chemin critique, dites-le dès le premier échange — y compris l'option voie trois, où votre équipe construit le client iOS sur le protocole du capteur au lieu d'attendre le nôtre. C'est l'argument général de la voie trois : si le protocole est documenté et stable, l'application au-dessus est votre calendrier, pas celui d'un autre.

Ce qu'intégrer veut vraiment dire

• Découverte et identification. Un véhicule peut avoir deux, trois ou quatre capteurs à portée. Votre application doit trouver les bons, les distinguer de ceux du véhicule voisin et les rattacher aux positions de roue.
• Gestion des connexions. Les connexions BLE ne sont pas gratuites. Garder quatre capteurs ouverts en permanence vide la batterie du téléphone ; interroger trop lentement manque une fuite rapide. Le bon schéma dépend de si le produit est un tableau de bord en direct ou une surveillance en arrière-plan.
• Données manquantes. La radio perd des paquets. Votre application a besoin d'un comportement défini sur une notification manquée : afficher la dernière valeur avec son âge, ou ne rien afficher. Les deux se défendent ; présenter silencieusement une valeur ancienne comme actuelle, non.
• Logique d'alarme. Seuils, compensation de température, différence entre fuite lente et matin froid, et ce que fait l'alarme quand le téléphone dort. Où vit cette logique — capteur ou application — se décide une fois et s'écrit.

Ce qu'il faut cadrer avant de commencer

• Recevrons-nous la documentation du service BLE et du format de données ? Sans elle, la voie trois est impossible et la deux dépend du calendrier d'un autre.
• Le format de données peut-il être modifié pour nous, ou faut-il accepter le défaut ? Les changements de disposition d'octets semblent petits et ne le sont pas, car ils touchent tous les consommateurs de la donnée.
• Quelle est la politique de version et de publication du firmware ? Que se passe-t-il au changement, et reste-t-il compatible avec votre application ?
• Quelle est la situation iOS, par écrit ? Une date, ou l'énoncé clair qu'il n'y en a pas. Les deux sont utilisables ; une réponse vague non.
• Recevons-nous des unités d'évaluation avant de nous engager ? Les problèmes d'intégration se trouvent sur le matériel, pas dans les documents.
• À qui appartiennent l'application et les données client ? Si la relation client est votre actif, c'est la question qui compte le plus.

Où nous en sommes

• Nous fabriquons le capteur : mesure, logique d'alarme, service BLE et format de données sont les nôtres. C'est ce qui rend l'adaptation possible au lieu de demander au client de contourner une référence figée de catalogue.
• Volume actuel : plus de 10 000 jeux par mois vers le marché secondaire chinois du deux-roues, capacité de 30 000 capteurs par mois. Chaque capteur est calibré en pression sur notre propre logiciel de test avant expédition ; immersion, portée RF et vérification de protocole sont faites en interne. La certification est traitée par marché et par projet.
• Si vous intégrez un capteur BLE dans un produit existant et voulez savoir ce qu'il faudrait changer de chaque côté, envoyez la forme du projet : véhicule, nombre de roues, plateforme d'application et marché.

← Tous les articles

Produits · Application · Contact