CAHIERS + MCUs

Aujourd'hui 18 58 Sans catégorie

Technologie de chaque module :

Module 8 : Banana Pi BPI-F5
Module 7 : STM32H755ZI-Q
Module 6 : NXP S32K344-WB
Module 5 : Microchip
MPFS250T-FCVG484
Module 4 : NXP FRDM-i.MX93
Module 3 : NXP [Link] 8M Plus
Module 2 : NXP [Link] 8ULP
Module 1 : Verdin iMX95 Quad 2.0GHz
(Toradex)
Cahier de charge des modules :

🧠 1. Module maître : Un mcu orchestreur

pour la gestion des autres mcu.
-La gestion et le contrôle total sur :
Module 8 : Banana Pi BPI-F5,
Module 7 : STM32H755ZI-Q,
Module 6 : NXP S32K344-WB,
Module 5 : Microchip
MPFS250T-FCVG484,
Module 4 : NXP FRDM-i.MX93,
Module 3 : NXP [Link] 8M Plus,
Module 2 : NXP [Link] 8ULP,
Module 1 : Verdin iMX95 Quad 2.0GHz
(Toradex) (secondaire).
-un mcu jumeau ou de redondance.
-orchestreur dois pouvoir accueillir un ou
des mcu supplémentaires sans
interrompre l'entièreté du système.
-Chaque mcu doit être réinitialisable
indépendamment sans interrompre ou
dérangé les autres mcu.
-possibilité de désactiver un mcu
temporairement sans pe urber tout
l'entièreté du système
-mode dégradé : Fonctionnement minimal
en cas de panne.
-journalisation distribué des mcu : chaque
mcu envoi ses log avec horodatage a
l'orchestreur pour analyse.
-implémenter un logiciel d'événement :
chaque mcu réagit à des événements
globaux.
-Pour passer du mode eVTOL au mode
véhicule terrestre, il faut être à une
distance de 10 mètres ou être au sol. Pour
passer du mode véhicule terrestre au
mode eVTOL, pas de restriction de
distance, Les deux modes ne peuvent pas
fonctionner simultanément. Le Lidar
Ouster OS1 Gen2 est utilisé pour mesurer
la hauteur par rappo au sol ou à la mer
et pour détecter les obstacles de manière
omnidirectionnelle..
-Lor du basculement de mode ce ain
fonctionnement reste inchangé.
-Intègrer une con ance
d'utilisateur(double commande ou
verrouillage logiciel, pour éviter les
erreurs d'appuis ou commande
malveillante ou même bug logiciel...)
-Sécurité embarquée niveau militaire :
serrure boot, root of trust, rmware signé
et véri é, isolation des tâches critiques
(utilisé des RTOS avec des séparation
mémoire).
-Détection d'instructions non autorisées.
-Chi rement des communications avec
protocoles adaptés.
-Journalisation distribuée.
-Possibilité d'être réinitialiser
indépendamment sans corrompre ou
dérangé les autres mcu.
-Mode debug distribué.
-capteur de température sur se mcu.
-Condensateur sur les lignes
d'alimentation et de signal (Blindage EMI ;
protection physique des mcu) sur chaque
mcu,
-langage de programmation propre à
chaqu'un.
💾 2. Module de logiciel et mémoire : Un
mcu pour la gestion de tout se qui est :
-un mcu jumeau ou de redondance.
-chi rement de chaque mcu.
-stockage des logiciels et clé de chaque
mcu (de tout les modules).
-Choisir des protocoles d'échanges mcu à
mcu (protocol inter-mcu), mcu à
orchestreur (avec protocole personnalisé
si possible).
-chaque mcu doit avoir son propre
rmware et tout doucementer.
-prévoir une détection d'instruction non
autorisée (interne ou externe, logiciel ou
matériel).
-sécurité embarqué niveau militaire :
accélérateur c ptographiques.
-Crée un protocole de message structuré :
ID, priorité, accusé de réception...
-chi rée les communications inter-mcu et
utilisé des clé unique pour chaque mcu en
cas d'attaque par duplication, (de tout les
modules).
-journalisation distribué des mcu : chaque
mcu envoi ses log avec horodatage a un
orchestreur pour analyse, (de tout les
modules).
-serrure boot.
-root of trusk.
- rmware signé et véri é.
-isolation des tâches critiques (utilisé des
RTOS avec des séparation mémoire).
-gèrer tout ce qui concerne le stockage
des logiciels et sauvegardes les données
( navigation, données moteur, ESC, les
messages d'erreur, les résultats des auto
tests....).
-prévoir un bootloader sécurisée pour
chaque mcu et un rallback automatique
en cas d'échec de la mise à jour ou autre
problème.
-journalisation distribué des mcu : chaque
mcu envoi ses log avec horodatage a un
orchestreur pour analyse.
-Firmware signé et véri é.
-Root of Trust.
-Secure Boot a chaque démarrage.
-Utilise des architectures comme ARM
-TrustZone, Secure Pa ition Manager, ou
TEE (Trusted Execution Environment).
-HSM (Hardware Security Module) pour la
gestion des clés c ptographiques.
-Sauvegarde centralisée.
-Chi rement des communications et
protocoles adaptés.
-Journalisation distribuée.
-Possibilité d'être réinitialiser
indépendamment sans corrompre ou
dérangé les autres mcu.
-Mode debug distribué.
-capteur de température pour chaque
mcu (SHT31 / SHT35).
-Condensateur sur les lignes
d'alimentation et de signal (Blindage EMI ;
protection physique des mcu) sur chaque
mcu.
-langage de programmation propre à
chaqu'un.

🛡 [Link] de supe ision système : Un

mcu pour pour la gestion
-log du séquencage de démarrage des
mcu.
-log des Capteurs de température.
-log de tout le système complet.
-prévoir une détection d'instruction non
autorisée (interne ou externe, logiciel ou
matériel).
-prévoir un mode debug distribué.
-Crée un protocole de message,
structuré : ID, priorité, accusé de
réception...
-la gestion des auto test : sur une période
donné il faire un test ou véri cations de
tout chaque composants, éléments par
éléments même les di érents logiciels des
mcu et faire un compte rendu visuel à
l'écran et aussi une sauvegarde.
-Tests de pe ormance (CPU, mémoire,
réseau et inter-communication )
-Tests de sécurité (intégrité rmware,
véri cation des clés).
-Simulation de pannes pour tester les
modes dégradés.
-Inte ace d'a chage (2 écran tactiles).
-Synchronisation initial au démarrage,
résynchronisation périodique (en fonction
ex: chaque secondes)de chaque mcu.
-correction d'horloge local avec un
algorithme de drift compensé.
-protocole PTP.
-Sécurité embarquée niveau militaire
(serrure boot : serrure de démarrage
root of trust, rmware signé et véri é,
isolation des tâches critiques).
-Chi rement des communications et
protocoles adaptés.
-Journalisation distribuée.
-Possibilité d'être réinitialiser
indépendamment sans corrompre ou
dérangé les autres mcu.
-Mode debug distribué.
-capteur de température pour chaque
mcu (SHT31 / SHT35).
-Condensateur sur les lignes
d'alimentation et de signal (Blindage EMI ;
protection physique des mcu) sur chaque
mcu.
-langage de programmation propre à
chaqu'un.

📡 4. module de communication et
connectivité :
communication : Un mcu pour pour la
gestion de tout se qui est communication
interne - externe .
-Wi-Fi (diagnostic, maintenance
prédictive, pilotage) authentication a
double facteur avant chaque connexion
ou utilisation d'un autre moyen
d'authenti cation similaire via Banana Pi
BPI-F5.
-Bluetooth 5.3 : connexions des appareils
téléphones pour appeler téléphonique,
lecture audio, lecture de messages reçus ;
permet l'a chage uniquement (a che les
mesure, température, le mode,.... ) avec le
même Banana Pi BPI-F5.
-po USB et autres ses po a pour but
unique de lire les chiers vidéos musiques
seulement et radio ; utilisations de
Banana Pi BPI-F5 pour cette tâche.
-prévoir une détection d'instruction non
autorisée (interne ou externe, logiciel ou
matériel).
-chi rée les communications inter-mcu et
utilisé des clé unique pour chaque mcu en
cas d'attaque par duplication.
-autre po de connexion pour interagir
avec le module maître, Module de logiciel
et mémoire, module de supe ision
système.
-Un système de contrôle avancé par
whatsapp (communiqué avec IA par
whatsapp).
-Sécurité embarquée niveau militaire
(serrure boot : serrure de démarrage
root of trust, rmware signé et véri é,
isolation des tâches critiques).
-Détection d'instructions non autorisées.
-Chi rement des communications et
protocoles adaptés.
-Journalisation distribuée.
-Possibilité d'être réinitialiser.
indépendamment sans corrompre ou
dérangé les autres mcu.
-Mode debug distribué.
-capteur de température pour chaque
mcu (SHT31 / SHT35).
-Condensateur sur les lignes
d'alimentation et de signal (Blindage EMI ;
protection physique des mcu) sur chaque
mcu.
-langage de programmation propre à
chaqu'un.

🚀 [Link] de control propulsion : Un

mcu pour la gestion de propulsion
-Moteurs motor CA120-70 (8 moteurs).
-Hélices CF PROP 40X13.1 L+R (2 Hélices
L+R pour chaque moteurs).
-ESC Turnigy 380A 22s ESC (8ESC, 1 pas
moteur).
-joypad (utilisé pour un module arduino
pour les tests).
-potentiomètre de gaz ( utilisé Se o
tester).
batteries 8000mAh Lipo-3S-50C-100C ( 4
batteries en série parallèles pour chaque
moteurs).
-prévoir un mcu jumeau en cas de
défaillance extrême.
-protection contre les inte erences
électromagnétique, champ électrique,
isolation intérieur et extérieur physique et
thermique.
-Des capteurs de siège comme le
CZL301C ou le CZL616C-100, associés à
l’ampli cateur AD7780, permettent de
détecter le poids supérieur à 25 kg et
déclenchent automatiquement la
stabilisation de eVTOL.
-Le mode eVTOL active les lumières qui le
concernent et les désactiver quand il est
désactivé.
-mesure Tours par seconde des moteurs
tr/s de chaque moteurs avec le Capteur
optique TCRT5000.
-Contrôle des axes de rotation :
Roulis via vérins (Idéal pour ajuster des
su aces de contrôle ou des bras
mécaniques stabilisateurs.).
Tangage via se os ( Permet un contrôle
rapide et précis de l’assiette, su out si tu
as des su aces mobiles ou des volets.).
Lacet via moteurs (En modulant la
poussée di érentielle (comme sur un
drone), tu peux faire tourner le véhicule
sur lui-même.).
-Capteurs de température Batteries
( BME280).
-Capteurs de température Moteurs
(SHT31 + thermistance NTC)
-SHT31 pour mesurer l'humidité ambiante
et thermistance NTC collée sur le moteur
pour mesurer la température directe.
-Capteurs de température ESC
(HTU21D-F).
-Sécurité embarquée niveau militaire
(serrure boot : serrure de démarrage
root of trust, rmware signé et véri é,
isolation des tâches critiques).
-Détection d'instructions non autorisées.
-Chi rement des communications et
protocoles adaptés.
-Journalisation distribuée.
-Possibilité d'être réinitialiser
indépendamment sans corrompre ou
dérangé les autres mcu.
-Mode debug distribué.
-capteur de température pour chaque
mcu (SHT31 / SHT35).
-Condensateur sur les lignes
d'alimentation et de signal (Blindage EMI ;
protection physique des mcu) sur chaque
mcu.
-langage de programmation propre à
chaqu'un.

🚙 [Link] véhicule : Un mcu pour la

gestion
-De la motorisation terrestre.
-pédale d'accélération.
-claconne.
-marche arrière.
-caméra de recule.
-Le mode véhicule active les lumières qui
le concernent et les désactiver quand il
est désactivé (clignotant, feu rouge, phare
avant et arrière).
-Sécurité embarquée niveau militaire
(serrure boot : serrure de démarrage
root of trust, rmware signé et véri é,
isolation des tâches critiques).
-Détection d'instructions non autorisées.
-Chi rement des communications et
protocoles adaptés.
-Journalisation distribuée.
-Possibilité d'être réinitialiser
indépendamment sans corrompre ou
dérangé les autres mcu.
-Mode debug distribué.
-capteur de température pour chaque
mcu (SHT31 / SHT35).
-Condensateur sur les lignes
d'alimentation et de signal (Blindage EMI ;
protection physique des mcu) sur chaque
mcu.
-langage de programmation propre à
chaqu'un.

🔋 [Link] d'énergie : Un mcu pour la

gestion de tout se qui concerne les
énergies électrique.
-alimentation de chaque mcu.
-Panneau solaire.
-Conve isseur DC DC.
-onduleur.
-Système de refroidissement (module
Peltier).
-capteur à a et hall LEM HAS 600-S
Pour les mesures énergie, BMS intelligent
Daly Smith BMS 600A-800A pour la
gestion intelligent de la batterie, EMS le
mcu+programmation pour centralisée,
analyser et piloter ces données (mesure
de courant, tension, puissance,
température.....).
-Séquence de démarrage :
1e_Module énergie
-Démarrage initial, véri cation des
tensions, activation du refroidissement.
2e_Module logiciel/mémoire
-Véri e l’intégrité des rmwares,
signatures, clés, et protocoles.
-Peut charger un rmware de secours ou
déclencher un rollback si nécessaire.
-compare les rmwares, signatures, clés,
et protocoles déjà stocker dans la
mémoire.
3e_Module maître
-Orchestration globale, détection des
MCU absents ou corrompus.
-Réinitialisation ciblée des MCU
défaillants ou corrompu.
-Rôle de “gardien”: valide ou bloque
l’activation des modes eVTOL ou
véhicules selon la panne.
-établir une table d’état initiale des
modules avant de poursuivre.
4e_Module communication
-Établit les connexions sécurisées,
chi rement, journalisation.
-établir la connexion logicielle (Wi-Fi,
Bluetooth) et physique (tout les po s).
5e_Module IA (mode passif)
-passe en mode actif qu’après validation
du module supe ision.
6e_Module supe ision
-Lancement des auto-tests, véri cation
de chaque MCU, a chage des résultats.
-Déclenche le démarrage complet du
module IA.
7e_Activation des modes eVTOL /
véhicule.
-Ne s’active que si tous les modules
critiques sont validés.
-basculement automatique en mode qui
est sélectionné au paravent.
-Sécurité embarquée niveau militaire
(serrure boot : serrure de démarrage
root of trust, rmware signé et véri é,
isolation des tâches critiques).
-Détection d'instructions non autorisées.
-Chi rement des communications et
protocoles adaptés.
-Journalisation distribuée.
-Possibilité d'être réinitialiser
indépendamment sans corrompre ou
dérangé les autres mcu.
-Mode debug distribué.
-capteur de température pour chaque
mcu (SHT31 / SHT35).
-Condensateur sur les lignes
d'alimentation et de signal (Blindage EMI ;
protection physique des mcu) sur chaque
mcu.
-langage de programmation propre à
chaqu'un.

🤖 8. module IA : Un mcu pour la gestion

uniquement pour IA.
-installer IA sur Banana Pi BPI-F5.
-Éclairage avec IA.
-En mode cinéma ou lm, musiques,
séries, radio la lumière est ajoutée
automatiquement.
-La commande vocal,
-Capteurs LiDAR, radar, ultrasons, ou
caméras stéréo
-Algorithmes de détection et prédiction
de trajectoire utilisation de Lidar Ouster
OS1 Gen2 + AI.
-Capteurs de température Cockpit
AM2302 (DHT22).
-Capteurs de température Extérieur
(SHT85 / SHT75).
-Réaction automatique (freinage,
stabilisation, évitement),
-Communication avec le module
propulsion et véhicule,
-Système de prévention anti-collisions.
-capteur de température intérieure et
extérieur,
-capteurs de force avec ampli cateurs
intégré :
TE Connectivity eVTOL Sensor Suite :
mesurer les contraintes mécaniques, les
pressions sur les structures, ou même les
interactions physiques (Capteurs de
pression : pour la su eillance des
systèmes hydrauliques, pneumatiques et
de refroidissement;
-Lidar YellowScan Explorer
-Radar omnidirectionnel : Uhnder Digital
Radar S80/S81
-La caméra Airmobi Q10TIRM : caméras
EO/IR pour détection d’obstacles vision
nocturne.
-Un système de contrôle avancé par
whatsapp (communiqué avec IA par
whatsapp),
-Sécurité embarquée niveau militaire
(serrure boot : serrure de démarrage
root of trust, rmware signé et véri é,
isolation des tâches critiques).
-Détection d'instructions non autorisées.
-Chi rement des communications et
protocoles adaptés.
-Journalisation distribuée.
-Possibilité d'être réinitialiser
indépendamment sans corrompre ou
dérangé les autres mcu.
-Mode debug distribué.
-capteur de température pour chaque
mcu (SHT31 / SHT35).
-Condensateur sur les lignes
d'alimentation et de signal (Blindage EMI ;
protection physique des mcu) sur chaque
mcu,
-langage de programmation propre à
chaqu'un.

NB :
Prévoir 2 mcu de rése e (de
redondances) universelle pour prendre le
relais si un des mcu ( modules 3, 4, 6, 7 et
8) n'est plus en état de fonctionner. 2
mcu qui peuvent jouer le rôle du module
3, 4, 6, 7 et 8 à la fois.