56 lines
4.7 KiB
Markdown
56 lines
4.7 KiB
Markdown
# Contrat et déploiement
|
||
|
||
## Services
|
||
|
||
Le navigateur conserve les mêmes URL. Nginx distribue les requêtes aux services internes : télémétrie (`/api/telemetry`), météo (`/api/weather`) et navigation (`/api/search`, `/api/route`, `/api/map-config`). Chaque conteneur possède son processus, son cache et son contrôle de santé. Les rôles sont définis dans `server/server.mjs` et sélectionnés par `SERVICE_ROLE` ; les autres routes sont refusées. Les API ne publient aucun port sur l’hôte.
|
||
|
||
Le module des fournisseurs est partagé entre services pour conserver validation, cache borné et temporisations. Le processus de télémétrie n’appelle aucun fournisseur. L’interface peut démarrer même lorsqu’une API est arrêtée. La réponse d’erreur et les indicateurs de perte de données du client restent ceux du cockpit existant.
|
||
|
||
La commande `npm start` conserve un serveur regroupé pour les tests et le développement. `compose.dev.yaml` ne change que le montage des fichiers UI ; les API restent séparées.
|
||
|
||
## 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](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.
|