3.7 KiB
Contrat et déploiement
API de démonstration v1
GET /api/health renvoie {"status":"ok","source":"demo"}.
GET /api/telemetry?profile=route renvoie un instantané JSON. Profils : route, ville, arret. Un profil inconnu renvoie HTTP 400. Les écritures renvoient HTTP 405. L’API n’accepte aucune commande moteur.
| Champ | Type / unité | Usage |
|---|---|---|
| schemaVersion | entier, 1 | Version du contrat |
| source | demo |
Provenance explicite |
| timestamp | millisecondes Unix | Fraîcheur des données |
| profile | texte | Profil simulé |
| speedKph | nombre, km/h | Vitesse |
| rpm | nombre, tr/min | Régime moteur |
| gear | texte | Rapport, N à l’arrêt |
| fuelPercent | nombre, % | Niveau carburant |
| coolantCelsius | nombre, °C | Liquide de refroidissement |
| batteryVolts | nombre, V | Batterie |
| outsideCelsius | nombre, °C | Température extérieure |
| rangeKm | nombre, km | Autonomie |
| tripKm | nombre, km | Trajet fictif constant |
| consumptionL100 | nombre, L/100 km | Consommation fictive |
| weather | objet | Source, description, température fictives |
La vitesse et le régime évoluent ; les autres valeurs sont des exemples fixes, sauf la température moteur à l’arrêt. Il ne s’agit pas d’un modèle physique du véhicule. Le temps du serveur produit une animation cohérente entre clients utilisant le même profil.
Le client refuse les instantanés mal formés ou vieux de plus de 10 secondes, avec une limite de 3 secondes pour chaque requête. En cas de coupure il masque les aiguilles, remplace les mesures par des tirets et retente automatiquement. Les horloges du serveur et des écrans doivent être synchronisées ; un écart de plus de 10 secondes sera traité comme une donnée invalide.
Passage à une source CAN
Prévoir un processus de lecture sur le Raspberry Pi, avec accès au périphérique CAN uniquement sur cette machine. La découverte des identifiants, facteurs, unités et fréquences des trames de la Mégane III reste à réaliser à partir des données du véhicule. Ne pas déduire les identifiants CAN de cette démonstration.
La passerelle produira le contrat normalisé, avec une source can, des valeurs manquantes explicites et un horodatage par signal si nécessaire. La version actuelle du client n’accepte volontairement que demo : adapter la validation, les limites par champ et les indicateurs source/fraîcheur lors de cette étape. Choisir ensuite le transport Raspberry → service (HTTP, MQTT ou WebSocket) selon le réseau et la fréquence nécessaires.
Le simulateur et la future passerelle doivent être sélectionnés explicitement ; ne jamais substituer silencieusement des valeurs fictives à une liaison CAN perdue.
Évolutions indépendantes
- Bibliothèque audio persistante : volume en lecture seule, catalogue et prise en charge des requêtes Range ; la musique serait alors lue depuis le serveur plutôt que choisie dans l’appareil client.
- Météo réelle et cartographie : intégrées en 0.2, voir navigation.md. Restent le hors ligne et le GPS matériel.
- Alertes de zones : moteur local livré en 0.2 ; la source de données réelle et son utilisation par pays restent à définir.
- Affichage : kiosque Linux et configuration des moniteurs au niveau de l’OS ; paramètres propres à chaque écran si nécessaire.
- Distribution : figer les images par version/digest une fois la première construction ARM validée ; ajouter une construction automatisée multiarchitecture au dépôt si son hébergement CI le permet.
Les tags Docker actuels suivent Node 22 Alpine et Nginx stable Alpine. Ils facilitent ce prototype mais ne rendent pas les builds strictement reproductibles.