beeplane - User contributions [en]

STM32 premier pas et prise en main logiciel

2026-05-22T15:47:52Z

Wiki.admin: /* Montage maquette */

STM32 premier pas et prise en main logiciel

2026-05-22T15:46:34Z

Wiki.admin: /* Montage maquette */

File:STM32 wiki 07 Maquette et code fin image12 rotated left.jpeg

2026-05-22T15:44:43Z

Wiki.admin:

STM32 premier pas et prise en main logiciel

2026-05-22T15:40:25Z

Wiki.admin: /* Architecture de commande */

STM32 premier pas et prise en main logiciel

2026-05-22T15:37:45Z

Wiki.admin: /* Montage maquette */

STM32 premier pas et prise en main logiciel

2026-05-22T15:36:05Z

Wiki.admin: /* Architecture de commande */

File:STM32 wiki 08 Maquette et code fin image14.png

2026-05-22T15:34:19Z

Wiki.admin:

STM32 premier pas et prise en main logiciel

2026-05-22T15:32:06Z

Wiki.admin: /* Bus CAN */

File:STM32 wiki 13 20260511 FCU MINIBEE image60.png

2026-05-22T15:29:42Z

Wiki.admin:

STM32 premier pas et prise en main logiciel

2026-05-22T15:28:23Z

Wiki.admin: /* Pilotage moteur avec L298N */

File:STM32 wiki 14 20260511 FCU MINIBEE image61.png

2026-05-22T15:27:15Z

Wiki.admin:

STM32 premier pas et prise en main logiciel

2026-05-22T15:25:19Z

Wiki.admin: /* Lecture d’un joystick */

File:STM32 wiki 03 Maquette et code fin image6.png

2026-05-22T15:24:13Z

Wiki.admin:

STM32 premier pas et prise en main logiciel

2026-05-22T15:22:59Z

Wiki.admin: /* Installation logicielle */

STM32 premier pas et prise en main logiciel

2026-05-22T15:22:36Z

Wiki.admin: /* Premier test : clignotement LED */

File:STM32 wiki 02 Maquette et code fin image3.png

2026-05-22T15:21:28Z

Wiki.admin:

STM32 premier pas et prise en main logiciel

2026-05-22T15:20:37Z

Wiki.admin: /* Matériel utilisé */

STM32 premier pas et prise en main logiciel

2026-05-22T15:19:10Z

Wiki.admin: /* Matériel utilisé */

File:STM32 wiki 11 20260511 FCU MINIBEE image50.png

2026-05-22T15:16:24Z

Wiki.admin:

STM32 premier pas et prise en main logiciel

2026-05-22T15:15:36Z

Wiki.admin: /* Contexte Mini-Bee */

File:ChatGPT Image 22 mai 2026, 10 58 59.png

2026-05-22T15:12:57Z

Wiki.admin:

STM32 premier pas et prise en main logiciel

2026-05-22T15:09:24Z

Wiki.admin:

STM32 premier pas et prise en main logiciel

2026-05-22T15:04:28Z

Wiki.admin:

STM32 premier pas et prise en main logiciel

2026-05-22T14:55:34Z

Wiki.admin:

STM32 premier pas et prise en main logiciel

2026-05-22T14:48:06Z

Wiki.admin: Created page with "{{DISPLAYTITLE:STM32 — Premiers pas et prise en main logicielle}} <div style="background:#f5f9fb; border-left:6px solid #0b4f6c; padding:18px 22px; margin-bottom:24px;"> <h..."

{{DISPLAYTITLE:STM32 — Premiers pas et prise en main logicielle}}

<div style="background:#f5f9fb; border-left:6px solid #0b4f6c; padding:18px 22px; margin-bottom:24px;">
<h1 style="margin-top:0;">STM32 — Premiers pas et prise en main logicielle</h1>
<p style="font-size:1.08em;">
Cette page présente une prise en main progressive de l’environnement STM32 utilisé pour le projet Mini-Bee.
Elle explique comment installer l’environnement logiciel, réaliser les premiers exercices Arduino/STM32,
puis comprendre le rôle de la carte Nucleo, des BluePills, du bus CAN et des modules de puissance L298N dans l’architecture FCU.
</p>
<p>
L’objectif n’est pas de tout documenter, mais de donner une base claire, lisible et directement réutilisable par les futurs contributeurs du projet.
</p>
</div>

__TOC__

== 1. Objectif de la page ==

Cette page sert de point d’entrée pour les étudiants, ingénieurs ou contributeurs qui découvrent la partie logicielle STM32 du projet Mini-Bee.

Elle permet de comprendre :

* comment préparer l’environnement de développement ;
* comment programmer une carte STM32 Nucleo avec l’IDE Arduino ;
* comment tester les entrées/sorties de base ;
* comment lire un joystick analogique ou numérique ;
* comment piloter un moteur à courant continu via un pont en H ;
* comment utiliser un bus CAN pour connecter la carte principale aux modules moteurs ;
* comment cette prise en main s’intègre dans le Flight Control Unit du Mini-Bee.

<div style="background:#eef6f9; border:1px solid #c8dde6; border-radius:10px; padding:16px; margin:20px 0;">
'''Idée clé :''' la STM32 Nucleo joue le rôle de contrôleur principal.
Elle lit les consignes pilote, traite les informations capteurs et envoie des ordres aux modules moteurs.
</div>

== 2. Contexte Mini-Bee et Flight Control Unit ==

Le Mini-Bee est un multicoptère hybride VTOL développé comme plateforme collaborative de recherche et de prototypage.

Dans l’architecture FCU étudiée, la carte STM32 Nucleo agit comme le cerveau de commande.
Elle reçoit les consignes de pilotage, prépare les ordres moteurs et coordonne les modules déportés.

Le projet vise à rendre le Mini-Bee contrôlable et stabilisable sur les trois axes principaux :

* '''Roll''' : roulis ;
* '''Pitch''' : tangage ;
* '''Yaw''' : lacet.

La soutenance ESTACA rappelle que l’objectif final du FCU Mini-Bee est de rendre le prototype contrôlable et stabilisable en trois axes grâce à une nouvelle architecture de contrôle distribuée.

[[Fichier:STM32_FCU_MiniBee_architecture_generale.png|center|900px|thumb|Architecture générale du Flight Control Unit Mini-Bee : une carte maître STM32 coordonne les modules moteurs.]]

== 3. Matériel principal utilisé ==

{| class="wikitable" style="width:100%;"
! Élément
! Rôle dans la maquette
! Point important
|-
| '''STM32 Nucleo F446RE'''
| Carte maître du système
| Lit les consignes, prépare les ordres et pilote la communication
|-
| '''BluePill STM32F103C8T6'''
| Carte esclave locale
| Reçoit les ordres et génère les signaux moteur localement
|-
| '''SN65HVD230'''
| Transceiver CAN
| Permet la communication différentielle CAN en 3,3 V
|-
| '''L298N'''
| Pont en H de puissance
| Alimente et contrôle le sens de rotation des moteurs DC
|-
| '''Moteurs DC'''
| Actionneurs de la maquette
| Permettent de visualiser les commandes moteurs
|-
| '''Joystick / potentiomètre'''
| Interface de commande
| Sert à générer des consignes pilote simples
|}

[[Fichier:STM32_Nucleo_F446RE_MiniBee.jpg|center|650px|thumb|Carte STM32 Nucleo F446RE utilisée comme contrôleur principal de la maquette.]]

== 4. Installation de l’environnement logiciel ==

La première étape consiste à préparer l’IDE Arduino pour programmer la carte STM32.

=== 4.1 Installer les bibliothèques STM32 ===

La carte d’extension X-NUCLEO-IKS01A2 est compatible avec l’écosystème Arduino.
Une bibliothèque dédiée permet d’utiliser les capteurs et les fonctions associées dans l’IDE.

Étapes recommandées :

# Télécharger la bibliothèque STM32duino X-NUCLEO-IKS01A2 au format ZIP.
# Ouvrir l’IDE Arduino.
# Aller dans '''Croquis > Inclure une bibliothèque > Ajouter la bibliothèque .ZIP'''.
# Sélectionner directement le fichier ZIP sans le décompresser.
# Vérifier que la bibliothèque apparaît bien dans la liste des bibliothèques disponibles.

<div style="background:#fff8e5; border:1px solid #e4c46a; border-radius:10px; padding:14px; margin:18px 0;">
'''Attention :''' ne pas décompresser le fichier ZIP avant import dans Arduino IDE.
L’IDE attend l’archive complète.
</div>

[[Fichier:STM32duino_X_NUCLEO_IKS01A2_installation.png|center|850px|thumb|Installation de la bibliothèque STM32duino X-NUCLEO-IKS01A2 dans l’IDE Arduino.]]

=== 4.2 Ajouter le gestionnaire de cartes STM32 ===

Dans les préférences Arduino, ajouter l’URL du gestionnaire de cartes STM32duino.
Puis ouvrir le gestionnaire de cartes et installer les paquets STM32.

Ensuite, configurer la carte :

{| class="wikitable" style="width:100%;"
! Paramètre Arduino IDE
! Valeur à sélectionner
|-
| Board
| Nucleo-64
|-
| Board part number
| Nucleo F446RE
|-
| Port
| Port série correspondant à la carte branchée
|-
| Upload method
| Valeur par défaut adaptée à la Nucleo
|}

[[Fichier:Arduino_IDE_Nucleo64_F446RE_configuration.png|center|750px|thumb|Configuration de la carte Nucleo-64 / Nucleo F446RE dans l’IDE Arduino.]]

== 5. Premier exercice : clignotement d’une LED ==

Le clignotement d’une LED est l’exercice de base pour valider :

* le branchement ;
* le téléversement du code ;
* la configuration d’une sortie numérique ;
* le retour d’information dans le moniteur série.

=== 5.1 Câblage ===

Connecter une LED sur la broche '''D13 / PA5''' de la Nucleo.

Prévoir :

* une LED ;
* une résistance de 220 Ω ;
* une connexion vers GND ;
* un fil entre D13 / PA5 et l’anode de la LED.

[[Fichier:STM32_LED_breadboard_Nucleo.png|center|700px|thumb|Premier montage LED sur breadboard avec la carte STM32 Nucleo.]]

=== 5.2 Code de test ===

<syntaxhighlight lang="cpp">
#define LED_PIN PA5
#define BLINK_DELAY 500

void setup() {
Serial.begin(115200);
pinMode(LED_PIN, OUTPUT);
Serial.println("LED blink test started");
}

void loop() {
digitalWrite(LED_PIN, HIGH);
Serial.println("LED: ON");
delay(BLINK_DELAY);

digitalWrite(LED_PIN, LOW);
Serial.println("LED: OFF");
delay(BLINK_DELAY);
}
</syntaxhighlight>

=== 5.3 Résultat attendu ===

La LED doit s’allumer et s’éteindre toutes les 500 ms.
Le moniteur série doit afficher alternativement :

<syntaxhighlight lang="text">
LED: ON
LED: OFF
</syntaxhighlight>

Ce test valide que la carte est reconnue, que le programme est chargé correctement et que la sortie numérique fonctionne.

== 6. Lecture d’un joystick numérique ==

Le joystick numérique est utilisé comme une série d’interrupteurs logiques.

Il permet de détecter des états simples :

* direction activée ;
* bouton pressé ;
* position de repos.

=== 6.1 Broches utilisées ===

{| class="wikitable" style="width:100%;"
! Fonction
! Broche STM32
! Remarque
|-
| Axe X
| PA0
| Entrée numérique
|-
| Axe Y
| PA1
| Entrée numérique
|-
| Bouton
| PB2
| Entrée numérique avec pull-up
|-
| VCC
| 3.3 V
| Alimentation logique
|-
| GND
| GND
| Masse commune
|}

<syntaxhighlight lang="cpp">
#define PIN_X PA0
#define PIN_Y PA1
#define PIN_BTN PB2

void setup() {
Serial.begin(115200);
pinMode(PIN_X, INPUT_PULLUP);
pinMode(PIN_Y, INPUT_PULLUP);
pinMode(PIN_BTN, INPUT_PULLUP);
Serial.println("Digital joystick test ready");
}

void loop() {
int stateX = digitalRead(PIN_X);
int stateY = digitalRead(PIN_Y);
int stateBtn = digitalRead(PIN_BTN);

if (stateX == LOW && stateY == HIGH) {
Serial.println("Position detected: upper right");
}

if (stateBtn == LOW) {
Serial.println("Button pressed");
}

delay(200);
}
</syntaxhighlight>

[[Fichier:STM32_joystick_numerique_montage.png|center|650px|thumb|Montage d’un joystick sur la carte Nucleo pour lire des états numériques.]]

== 7. Lecture d’un joystick analogique ==

Le joystick analogique est plus adapté au pilotage progressif du Mini-Bee.

Contrairement au joystick numérique, il ne donne pas seulement un état ON/OFF.
Il fournit une valeur proportionnelle à l’inclinaison.

=== 7.1 Principe ===

Les axes X et Y sont lus par les entrées analogiques de la STM32.

Sur STM32, la lecture analogique peut être effectuée sur une résolution élevée.
Dans les exercices, les valeurs sont exploitées pour détecter des zones :

* centre ;
* gauche / droite ;
* haut / bas.

=== 7.2 Exemple de code ===

<syntaxhighlight lang="cpp">
#define JOYSTICK_X_PIN PA0
#define JOYSTICK_Y_PIN PA1

void setup() {
Serial.begin(115200);
pinMode(JOYSTICK_X_PIN, INPUT);
pinMode(JOYSTICK_Y_PIN, INPUT);
Serial.println("Analog joystick ready");
}

void loop() {
int x = analogRead(JOYSTICK_X_PIN);
int y = analogRead(JOYSTICK_Y_PIN);

Serial.print("X: ");
Serial.print(x);
Serial.print(" | Y: ");
Serial.println(y);

if (x > 600) {
Serial.println("Action: right");
} else if (x < 400) {
Serial.println("Action: left");
}

if (y > 600) {
Serial.println("Action: up");
} else if (y < 400) {
Serial.println("Action: down");
}

delay(200);
}
</syntaxhighlight>

<div style="background:#eef6f9; border:1px solid #c8dde6; border-radius:10px; padding:14px; margin:18px 0;">
'''Lien avec le Mini-Bee :''' le joystick analogique est indispensable pour générer une consigne proportionnelle.
Il permet de piloter progressivement la poussée, l’orientation ou la vitesse angulaire.
</div>

== 8. Pilotage de moteurs avec un pont en H ==

La carte STM32 ne peut pas alimenter directement les moteurs.
Il faut utiliser un composant de puissance.

Dans les exercices, deux approches apparaissent :

* L293D pour les premiers tests pédagogiques ;
* L298N pour la maquette Mini-Bee.

Le principe reste le même : le pont en H permet d’inverser la polarité appliquée au moteur, donc de changer son sens de rotation.

=== 8.1 Logique de commande ===

{| class="wikitable" style="width:100%;"
! IN1
! IN2
! Résultat moteur
|-
| HIGH
| LOW
| Rotation sens A
|-
| LOW
| HIGH
| Rotation sens B
|-
| LOW
| LOW
| Arrêt
|-
| HIGH
| HIGH
| Arrêt / freinage selon montage
|}

=== 8.2 Exemple simple ===

<syntaxhighlight lang="cpp">
const int motorPin1 = 5;
const int motorPin2 = 6;
const int motorPin3 = 10;
const int motorPin4 = 9;

void setup() {
pinMode(motorPin1, OUTPUT);
pinMode(motorPin2, OUTPUT);
pinMode(motorPin3, OUTPUT);
pinMode(motorPin4, OUTPUT);
}

void loop() {
digitalWrite(motorPin1, HIGH);
digitalWrite(motorPin2, LOW);
digitalWrite(motorPin3, LOW);
digitalWrite(motorPin4, LOW);
delay(2000);

digitalWrite(motorPin1, LOW);
digitalWrite(motorPin2, HIGH);
delay(2000);

digitalWrite(motorPin1, LOW);
digitalWrite(motorPin2, LOW);
digitalWrite(motorPin3, HIGH);
digitalWrite(motorPin4, LOW);
delay(2000);

digitalWrite(motorPin3, LOW);
digitalWrite(motorPin4, HIGH);
delay(2000);

digitalWrite(motorPin1, LOW);
digitalWrite(motorPin2, LOW);
digitalWrite(motorPin3, LOW);
digitalWrite(motorPin4, LOW);
}
</syntaxhighlight>

[[Fichier:STM32_L298N_moteur_DC_montage.png|center|700px|thumb|Montage de test moteur avec module de puissance et carte STM32.]]

== 9. Potentiomètre et jauge de poussée ==

Le potentiomètre permet de simuler une commande de puissance.

Dans le rapport d’exercices, il est utilisé pour allumer progressivement une, deux puis trois LED.
Ce montage représente une jauge simplifiée de régime moteur.

=== 9.1 Principe ===

* Potentiomètre faible : aucune LED allumée.
* Potentiomètre moyen : une ou deux LED allumées.
* Potentiomètre maximum : trois LED allumées.

=== 9.2 Exemple de code ===

<syntaxhighlight lang="cpp">
#define POT_PIN A0
#define LED1 D2
#define LED2 D3
#define LED3 D4

void setup() {
Serial.begin(115200);
pinMode(LED1, OUTPUT);
pinMode(LED2, OUTPUT);
pinMode(LED3, OUTPUT);
Serial.println("Throttle gauge ready");
}

void loop() {
int value = analogRead(POT_PIN);

if (value < 50) {
digitalWrite(LED1, LOW);
digitalWrite(LED2, LOW);
digitalWrite(LED3, LOW);
} else if (value < 2000) {
digitalWrite(LED1, HIGH);
digitalWrite(LED2, LOW);
digitalWrite(LED3, LOW);
} else if (value < 4000) {
digitalWrite(LED1, HIGH);
digitalWrite(LED2, HIGH);
digitalWrite(LED3, LOW);
} else {
digitalWrite(LED1, HIGH);
digitalWrite(LED2, HIGH);
digitalWrite(LED3, HIGH);
}

Serial.print("Potentiometer value: ");
Serial.println(value);
delay(100);
}
</syntaxhighlight>

== 10. Bus CAN : pourquoi l’utiliser ? ==

Le bus CAN est utilisé pour faire communiquer la carte principale STM32 Nucleo avec les modules moteurs.

Il présente plusieurs avantages pour la maquette :

* réduction du câblage ;
* meilleure robustesse face aux parasites ;
* communication différentielle sur CAN_H et CAN_L ;
* architecture multipoint ;
* possibilité d’ajouter des modules sans refaire toute l’architecture ;
* priorité des messages grâce aux identifiants CAN.

<div style="background:#f5f9fb; border-left:6px solid #0b4f6c; padding:16px; margin:20px 0;">
'''Pourquoi le CAN est important :''' les moteurs et les modules de puissance génèrent des perturbations électriques.
Le bus CAN est mieux adapté qu’une liaison simple ou qu’un câblage en étoile pour une maquette distribuée.
</div>

[[Fichier:SN65HVD230_CAN_transceiver.png|center|500px|thumb|Transceiver CAN SN65HVD230 utilisé pour la communication entre STM32 et modules déportés.]]

== 11. Test CAN en mode loopback ==

Le mode loopback permet de vérifier que le contrôleur CAN fonctionne sans dépendre immédiatement d’un autre module.

Le test consiste à :

# configurer les broches D14 / D15 ;
# initialiser le CAN à 500 kbps ;
# envoyer une trame ;
# recevoir la même trame en retour ;
# afficher le résultat dans le moniteur série.

=== 11.1 Paramètres principaux ===

{| class="wikitable" style="width:100%;"
! Paramètre
! Valeur utilisée
|-
| TX
| D14 / PB9
|-
| RX
| D15 / PB8
|-
| Débit
| 500 kbps
|-
| Mode
| Loopback
|-
| Identifiant de test
| 0x123
|}

=== 11.2 Résultat attendu ===

Le moniteur série doit afficher une réception de données.

Exemple :

<syntaxhighlight lang="text">
SUCCESS: CAN uses D14/D15
Sending...
RECEIVED! Data: 1 2 3 4
</syntaxhighlight>

== 12. Architecture distribuée de la maquette ==

L’architecture retenue sépare la commande et la puissance.

La STM32 Nucleo ne pilote pas directement tous les moteurs.
Elle envoie des ordres à des BluePills, qui pilotent localement les modules L298N.

=== 12.1 Chaîne fonctionnelle ===

<div style="text-align:center; margin:24px 0;">
<pre style="display:inline-block; text-align:left; background:#f5f9fb; border:1px solid #c8dde6; border-radius:10px; padding:16px;">
Joystick / capteurs
↓
STM32 Nucleo F446RE
↓ Bus CAN
SN65HVD230
↓
BluePill STM32F103
↓ PWM + direction
L298N
↓
Moteurs DC
</pre>
</div>

=== 12.2 Rôle de chaque niveau ===

{| class="wikitable" style="width:100%;"
! Niveau
! Fonction
|-
| STM32 Nucleo
| Décision, consigne, stratégie de vol, coordination
|-
| Bus CAN
| Transport fiable des messages vers les modules
|-
| BluePill
| Exécution locale, génération PWM, pilotage moteur
|-
| L298N
| Amplification de puissance et inversion de sens
|-
| Moteurs
| Action physique observable sur la maquette
|}

[[Fichier:MiniBee_schema_branchement_STM32_CAN_Bluepill_L298N.png|center|900px|thumb|Schéma de principe de l’architecture STM32, CAN, BluePill et L298N.]]

== 13. Exemple de branchements maquette ==

Les documents de référence indiquent une organisation répétable par branche moteur.

=== 13.1 STM32 vers CAN principal ===

* TX / D1 de la STM32 vers TX du CAN principal.
* RX / D0 de la STM32 vers RX du CAN principal.
* GND de la STM32 vers GND du CAN principal.
* 3.3 V de la STM32 vers 3.3 V du CAN principal.

=== 13.2 CAN principal vers modules CAN ===

Pour chaque branche :

* CANH vers CANH ;
* CANL vers CANL.

=== 13.3 CAN vers BluePill ===

* CANTX vers A7 de la BluePill.
* CANRX vers B1 de la BluePill.

=== 13.4 BluePill vers L298N ===

* B8 vers ENA.
* B7 vers IN1.
* B6 vers IN2.
* B5 vers IN3.
* B4 vers IN4.
* B3 vers ENB.

=== 13.5 L298N vers moteurs ===

* OUT1 / OUT2 vers le premier moteur DC.
* OUT3 / OUT4 vers le second moteur DC.

[[Fichier:MiniBee_montage_maquette_STM32_CAN_L298N.jpg|center|750px|thumb|Montage physique de la maquette avec STM32, CAN, BluePill, L298N et moteurs DC.]]

== 14. Exemple de code maître STM32 ==

Ce code illustre le principe : la STM32 envoie une consigne de vitesse à plusieurs BluePills via le bus CAN.

<syntaxhighlight lang="cpp">
#define HAL_CAN_MODULE_ENABLED
#include <STM32_CAN.h>

STM32_CAN Can1(CAN1, ALT);

void setup() {
Serial.begin(115200);
Can1.begin();
Can1.setBaudRate(500000);
Serial.println("Mini-Bee master ready");
}

void loop() {
static uint8_t speed = 0;
static bool increasing = true;

for (int id = 0x101; id <= 0x104; id++) {
CAN_message_t msg;
msg.id = id;
msg.len = 2;
msg.buf[0] = speed;
msg.buf[1] = speed;
Can1.write(msg);
}

if (increasing) {
speed += 5;
} else {
speed -= 5;
}

if (speed >= 250 || speed <= 0) {
increasing = !increasing;
}

delay(50);
}
</syntaxhighlight>

== 15. Exemple de code BluePill esclave ==

Chaque BluePill possède un identifiant unique.
Elle ne traite que les messages CAN qui lui sont destinés.

<syntaxhighlight lang="cpp">
#include <STM32_CAN.h>

#define NODE_ID 0x101

#define ENA_PIN PB8
#define IN1_PIN PB7
#define IN2_PIN PB6
#define IN3_PIN PB5
#define IN4_PIN PB4
#define ENB_PIN PB3

STM32_CAN Can1(CAN1, DEF);

void setup() {
pinMode(ENA_PIN, OUTPUT);
pinMode(IN1_PIN, OUTPUT);
pinMode(IN2_PIN, OUTPUT);
pinMode(ENB_PIN, OUTPUT);
pinMode(IN3_PIN, OUTPUT);
pinMode(IN4_PIN, OUTPUT);

Can1.begin();
Can1.setBaudRate(500000);
Can1.setFilter(0, NODE_ID, 0x7FF);
}

void driveMotors(uint8_t spd1, uint8_t spd2) {
analogWrite(ENA_PIN, spd1);
digitalWrite(IN1_PIN, HIGH);
digitalWrite(IN2_PIN, LOW);

analogWrite(ENB_PIN, spd2);
digitalWrite(IN3_PIN, HIGH);
digitalWrite(IN4_PIN, LOW);
}

void loop() {
CAN_message_t msg_rx;

if (Can1.read(msg_rx)) {
if (msg_rx.id == NODE_ID) {
driveMotors(msg_rx.buf[0], msg_rx.buf[1]);
}
}
}
</syntaxhighlight>

== 16. Lien avec les futures lois de commande ==

Ces exercices ne sont pas seulement pédagogiques.
Ils préparent directement la logique du Flight Control Unit.

{| class="wikitable" style="width:100%;"
! Exercice
! Compétence acquise
! Application FCU
|-
| LED
| Sortie numérique
| Signal d’état, diagnostic, alerte
|-
| Joystick numérique
| Lecture d’ordre simple
| Boutons, modes, commandes discrètes
|-
| Joystick analogique
| Lecture proportionnelle
| Consigne pilote progressive
|-
| Potentiomètre
| Lecture ADC
| Simulation de throttle ou jauge de poussée
|-
| Pont en H
| Commande moteur
| Sens, vitesse, arrêt moteur
|-
| CAN loopback
| Communication robuste
| Validation du bus de commande
|-
| CAN + L298N
| Ordre numérique vers action moteur
| Architecture distribuée Mini-Bee
|}

== 17. Bonnes pratiques de démarrage ==

Avant de lancer un test moteur :

* vérifier le câblage GND commun ;
* vérifier les alimentations 3.3 V, 5 V et puissance moteur ;
* tester d’abord sans hélice ;
* limiter la vitesse au début ;
* utiliser le moniteur série ;
* documenter chaque branche moteur ;
* numéroter les BluePills ;
* noter les identifiants CAN ;
* conserver une version du code stable avant modification.

<div style="background:#fff1f1; border:1px solid #d99; border-radius:10px; padding:16px; margin:20px 0;">
'''Sécurité :''' les tests moteurs doivent être réalisés sans hélices lors des premières validations.
Une erreur de code, de sens moteur ou de câblage peut déclencher un mouvement imprévu.
</div>

== 18. Perspectives pour la suite ==

La prise en main logicielle STM32 ouvre la voie aux travaux suivants :

* intégration complète du bus CAN sur toutes les branches ;
* validation de la commande moteur distribuée ;
* synchronisation des moteurs ;
* lecture des capteurs inertiels ;
* intégration d’un correcteur PID ;
* stabilisation roll / pitch / yaw ;
* test des cas de vol : décollage, stationnaire, montée, descente, virage et arrêt d’urgence.

Le travail réalisé constitue donc une base de reprise pour les futurs groupes.
Il permet de passer d’exercices simples à une architecture de contrôle réellement exploitable sur la maquette Mini-Bee.

== 19. Visuels recommandés pour cette page ==

{| class="wikitable" style="width:100%;"
! Visuel
! Source recommandée
! Utilisation dans la page
|-
| Capture installation bibliothèque STM32duino
| Rapport codes et exercices, page installation
| Section 4
|-
| Configuration Nucleo-64 / F446RE dans Arduino IDE
| Rapport codes et exercices, page configuration
| Section 4.2
|-
| Montage LED + breadboard
| Rapport codes et exercices, exercice LED
| Section 5
|-
| Montage joystick
| Rapport codes et exercices, exercice joystick
| Section 6
|-
| Transceiver CAN SN65HVD230
| Rapport codes et exercices, section bus CAN
| Section 10
|-
| BluePill
| Rapport codes et exercices, section BluePill
| Section 12
|-
| L298N
| Rapport codes et exercices, section L298N
| Section 8 ou 12
|-
| Schéma de branchement maquette
| Rapport codes et exercices, montage maquette
| Section 13
|-
| Architecture FCU
| Soutenance FCU Mini-Bee
| Section 2 ou 12
|}

== 20. Conclusion ==

La STM32 est le point d’entrée logiciel du Flight Control Unit Mini-Bee.

En partant d’exercices simples — LED, joystick, potentiomètre, moteur — on construit progressivement les briques nécessaires à une architecture de vol distribuée :

* acquisition des consignes ;
* traitement logiciel ;
* communication CAN ;
* délégation locale aux BluePills ;
* pilotage de puissance par L298N ;
* commande synchronisée des moteurs.

Cette progression rend le système compréhensible, testable et améliorable.
Elle facilite la reprise du projet par de nouveaux contributeurs et prépare les prochaines étapes de stabilisation du Mini-Bee.

FCU multicopter hybrid

2026-05-22T09:24:44Z

Wiki.admin:

A '''Flight Control Unit''', or '''FCU''', is the flight control computer of a [[hybrid multicopter]]. In this type of aircraft, energy comes from a piston engine feeding a distributed propulsion architecture with fixed-pitch vertical-thrust propellers. The FCU translates pilot commands into safe, stable, and efficient flight behavior. It distributes power between the rotors, keeps the aircraft balanced, continuously monitors onboard sensors, corrects deviations caused by wind or system anomalies, and manages warnings as well as emergency procedures.
Unlike a conventional helicopter, where the pilot directly manages much of the aircraft response, or a fully electric VTOL focused mainly on battery management, the FCU of a hybrid multicopter must simultaneously stabilize flight and coordinate a more complex propulsion system.
{{Infobox
| title = FCU — Hybrid Multicopter
| Source = Cahier des charges — Flight Control Unit of a Hybrid Multicopter
| Author = Chérif Hidoussi
| Reviewer = Xavier Dutertre
| Date = 2024-11-08
}}
[[File:20241108 Cahier de charge FCU VTOL V2.pdf]]
TOC
== Overview ==
This specification defines the functional and technical requirements for a Flight Control Unit (FCU) that controls a '''hybrid multicopter''' — an aircraft powered by a single piston engine driving electric generation, with fixed-pitch vertical-thrust propellers (no tilt rotor). The reference design uses around 60 rotors.
The goal is a flight control system that is '''safe, reliable, and efficient''', suitable for the multicopter's operational needs across takeoff, stable flight, maneuvers, and emergency procedures.
=== Target applications ===

'''Light air ambulance''' — transport of a stabilized patient (no winching). The pilot may be the doctor or stretcher-bearer, seated on the left; the patient is a passenger and does not fly the aircraft.
'''Tourism''' — one pilot (left seat); the second person is a passenger with controls disabled.
'''Pilot training''' — both left and right control sets are active.

=== Certification target ===
CS 27 (small helicopter) or EASA VTOL (a relatively new certification path as of 2024).
== What makes this FCU different ==
Unlike a traditional helicopter (single variable-pitch rotor, often pilot-controlled directly or via fly-by-wire) or a fully electric VTOL (Volocopter, Lilium, Joby — where battery management is central), this aircraft relies on '''a single, less powerful piston engine'''.
Because there is no redundant second engine, the aircraft carries a '''whole-aircraft rescue parachute''' to handle total engine loss, allowing it to land without any flight control. Stabilization and control methods must therefore be adapted to this single-engine hybrid configuration.
=== Pilot controls and flight axes ===
The pilot uses a '''right-hand joystick'''. The three flight axes are:

'''Pitch''' (''tangage'')
'''Roll''' (''roulis'')
'''Yaw''' (''lacet'')

== The 10 operating cases ==
The specification breaks FCU behavior down into distinct flight scenarios, each with defined inputs, outputs, and rules. For clarity, vertical climb and vertical descent are presented here as two separate cases, even though they are grouped together in the original requirements document.
=== Case 1 — Progressive takeoff ===
As the pilot raises the throttle, engine speed and available electrical power increase, spinning the rotors faster until the aircraft lifts off. The FCU distributes power evenly across all rotors to keep the aircraft level and lifting vertically. It manages progressive power increase, automatic tilt correction (e.g. wind gusts or a failed rotor), continuous sensor monitoring, climb-rate limiting, motor-saturation prevention, altitude and vertical-speed control, and alarm generation for abnormal conditions.
=== Case 2 — Stabilized hover ===
Pressing the red push/pull stop button on the joystick holds the aircraft stationary in the air with a fixed heading. The FCU uses positioning and altitude sensors to maintain position and altitude, correcting for wind drift. It handles fallback cases such as GPS dropout (switching to inertial mode), rotor performance loss (redistributing power), logs the stop event, manages subsequent pilot commands (restart/resume), and can disable automatic functions (e.g. auto-follow, return-to-home) temporarily or permanently.
=== Case 3 — Vertical climb ===
With the stop button engaged and joystick centered, the pilot presses climb. The FCU increases motor power proportionally so the aircraft climbs along its vertical axis while preserving trajectory control, stability, and motor availability. It maintains stability against wind, monitors altitude, and handles emergencies such as a motor jam during climb or an obstacle triggering an emergency climb.
=== Case 4 — Vertical descent ===
The same principle applies during descent. The FCU reduces motor power proportionally to keep the aircraft stable and on a controlled vertical path down to the target altitude, compensating for wind. It manages emergencies such as motor overheat (progressive power reduction) or power loss (emergency descent protocols).
=== Case 5 — Yaw rotation on the spot ===
With the stop button pressed, turning the joystick left or right rotates the aircraft about its vertical axis. The FCU modulates individual rotor speeds to produce accurate yaw motion — keeping pitch = 0, roll = 0, and altitude constant — without excessive drift or loss of control. It respects the aircraft's operational limits and handles faults such as gyro failure or loss of yaw authority. Returning the joystick to center reverts to the Case 2 hover.
=== Case 6 — Straight forward flight ===
Pressing the forward button with the joystick centered, the pilot adjusts throttle to hold altitude. The FCU generates a pitch command to tilt the aircraft forward for horizontal thrust, controls attitude in real time, compensates for disturbances (gusts, front-rotor loss, speed-sensor failure), manages propulsion and thrust distribution to hold the target speed, and respects pitch-angle limits to prevent stall or instability.
=== Case 7 — Turning while moving forward ===
With forward already engaged, turning the joystick makes the FCU coordinate roll, yaw, and power management to perform a balanced right or left turn at constant speed and altitude. It differentiates motor power side-to-side to bank the aircraft, caps the maximum bank angle (with pilot alerts and automatic intervention if exceeded), compensates altitude loss from banking, and returns the aircraft smoothly to stable flight after the turn.
=== Case 8 — Turning while climbing or descending ===
In a more complex maneuver, combining throttle (climb/descent) with a joystick turn, the FCU analyzes the trajectory, calculates the required bank angle while accounting for changing gravitational load, redistributes motor power, manages attitude and vertical speed, compensates for wind, and maintains reinforced sensor and safety-system monitoring throughout.
=== Case 9 — In-flight emergency stop with parachute deployment ===
For critical failures (piston engine, generator/Emrax, flight computers, or many rotors), the pilot presses the red emergency button. The FCU's logic: if the emergency button is pressed and the parachute is not yet deployed, it triggers the parachute. Once deployed, it stops all rotors and shuts down systems — though it may keep a few rotors running at adjusted power to keep the aircraft level during the parachute descent. It continues monitoring critical systems (sensors, batteries, controls) and transmits the emergency situation, location, and flight conditions to ground operators to aid recovery.
=== Case 10 — Final shutdown on the ground ===
After landing, pressing the "shut down" button makes the FCU confirm the order, progressively deactivate onboard systems (non-essential first, then flight-critical), cut electrical power to the motors and components, and confirm safe shutdown to the pilot interface. Backup procedures cover faults such as a motor not responding to shutdown, overheating during shutdown, or a non-functional shutdown button.
== Cross-cutting concerns ==
=== Sensor and system monitoring ===
The FCU continuously collects and validates data from gyroscopes, accelerometers, and barometers (plus GPS) to compute motor commands, orientation adjustments, and telemetry. It detects sensor anomalies, falls back to redundant or backup data, and logs critical flight data for post-flight analysis.
=== Power management and safety ===
Dynamic power balancing prevents motor overload, especially during power transitions in climb and descent. Maximum power limits protect against overheating and damage, climb-rate limits prevent excessive reactions, and saturation prevention preserves control margin.
=== Alarms and warnings ===
Abnormal conditions trigger graded visual or audible alerts on the radio-control display, designed with ergonomics and pilot workload in mind, and built with redundancy for reliability.
== Why it matters ==
The FCU is a core technology for the missions targeted by a hybrid multicopter, including light air ambulance operations, tourism, and pilot training. Without it, distributed propulsion would be difficult to operate safely and reliably. With it, the aircraft can take off, hover, move forward, turn, handle emergencies, and shut down in a controlled way while maintaining a high level of operational safety.
== Sections not yet detailed ==
The specification reserves (but does not yet fully populate) sections on:

'''Testing and validation''' — test methodology and scenarios covering standard flight and emergencies.
'''Maintenance and support''' — preventive/corrective maintenance, spare parts, manuals, and manufacturer technical support.
'''Schedule and budget''' — development/delivery timeline and cost estimates for design, manufacturing, and certification.

== Reference projects ==

'''Mini-Bee''' ([https://www.mini-bee.com mini-bee.com]) — Rotax 915is/916is piston engine (~140 hp).
'''Workhorse SureFly''' — Honda engine (~200 hp).
'''Zephyr helicopter''' — cited as the first helicopter with a parachute rescue system.

{{Note|The original document states it was partially drafted with the help of ChatGPT.}}
[[Category:Flight Control]]
[[Category:Hybrid Multicopter]]
[[Category:Avionics]]

File:20241108 Cahier de charge FCU VTOL V2.pdf

2026-05-22T09:20:20Z

Wiki.admin:

This specification defines the Flight Control Unit (FCU) for a hybrid multicopter, powered by a single piston engine driving electric generation, with around 60 fixed-pitch rotors. Target applications are light air ambulance, tourism, and pilot training, with CS 27 or EASA VTOL certification. Lacking a second engine, the aircraft carries a rescue parachute for total engine failure. The pilot commands via a right-hand joystick (pitch, roll, yaw). The core of the document covers nine flight cases: manual takeoff, hover (stop button), vertical climb/descent, yaw rotation, straight-line forward flight, turns, climbing/descending turns, emergency stop with parachute, and final ground shutdown. Each case defines inputs, outputs, and rules. The FCU continuously monitors gyroscopes, accelerometers, and barometers to distribute power, stabilize the aircraft, and generate alerts. Dynamic power management prevents motor overload during transitions. The testing, maintenance, and budget sections remain to be completed. Reference projects: Mini-Bee

FCU multicopter hybrid

2026-05-22T09:19:19Z

Wiki.admin:

A Flight Control Unit, or FCU, is the flight control computer of a hybrid multicopter. In this type of aircraft, energy comes from a piston engine feeding a distributed propulsion architecture with fixed-pitch vertical-thrust propellers. The FCU translates pilot commands into safe, stable, and efficient flight behavior. It distributes power between the rotors, keeps the aircraft balanced, continuously monitors onboard sensors, corrects deviations caused by wind or system anomalies, and manages warnings as well as emergency procedures. Unlike a conventional helicopter, where the pilot directly manages much of the aircraft response, or a fully electric VTOL focused mainly on battery management, the FCU of a hybrid multicopter must simultaneously stabilize flight and coordinate a more complex propulsion system.

10 Operating Cases, from the Simplest to the Most Complex

For clarity, vertical climb and vertical descent are presented here as two separate cases, even though they are grouped together in the original FCU requirements document.

1. Progressive takeoff
When the pilot increases throttle, the FCU distributes power across the rotors so the aircraft lifts vertically while remaining level, limiting climb rate and preventing motor saturation.

2. Stabilized hover
When hover mode is requested, the FCU uses sensor data to maintain position and altitude, even in the presence of wind or drift.

3. Vertical climb
The FCU adjusts thrust so the aircraft climbs along its vertical axis while preserving trajectory control, stability, and motor availability.

4. Vertical descent
The same principle applies during descent: the FCU regulates power to keep the aircraft stable and on a controlled vertical path down to the target altitude.

5. Yaw rotation on the spot
When the pilot commands rotation about the vertical axis, the FCU modulates rotor power to produce accurate yaw motion without excessive drift or loss of control.

6. Straight forward flight
When a forward command is given, the FCU generates a pitch command and adapts rotor power so the aircraft moves ahead in a stable, controlled way.

7. Turning while moving forward
The FCU combines roll, yaw, and power management to perform a coordinated right or left turn during forward flight.

8. Turning while climbing
In a more complex maneuver, the FCU must manage the turn, altitude increase, and reinforced sensor monitoring at the same time to maintain safety and stability.

9. In-flight emergency stop with parachute deployment
In a critical failure, the FCU detects the emergency, confirms parachute deployment logic, stops or manages the rotors as required, continues monitoring critical systems, and issues the alerts needed to secure descent.

10. Final shutdown on the ground
After landing, when the pilot commands shutdown, the FCU confirms the instruction, prepares the aircraft for a safe stop, and cuts the motors according to a controlled sequence.

Why it Matters

The FCU is a core technology for the missions targeted by a hybrid multicopter, including light air ambulance operations, tourism, and pilot training. Without it, distributed propulsion would be difficult to operate safely and reliably. With it, the aircraft can take off, hover, move forward, turn, handle emergencies, and shut down in a controlled way while maintaining a high level of operational safety.

<br>
[[File:20241108 Cahier de charge FCU VTOL V2.pdf]]<br>
<br>

# Flight Control Unit (FCU) for a Hybrid Multicopter — Specification Summary

*Source: Cahier des charges — Flight Control Unit of a Hybrid Multicopter (Author: Chérif Hidoussi, Reviewer: Xavier Dutertre, 2024-11-08)*

## Overview

This document specifies the functional and technical requirements for a **Flight Control Unit (FCU)** that controls a **hybrid multicopter** — an aircraft powered by a single piston engine driving electric generation, with fixed-pitch vertical-thrust propellers (no tilt rotor). The reference design uses around 60 rotors.

The goal is a flight control system that is **safe, reliable, and efficient**, suitable for the multicopter's operational needs across takeoff, stable flight, maneuvers, and emergency procedures.

### Target applications
- **Light air ambulance** — transport of a stabilized patient (no winching). The pilot may be the doctor/stretcher-bearer, seated on the left; the patient is a passenger and does not fly the aircraft.
- **Tourism** — one pilot (left seat); the second person is a passenger with controls disabled.
- **Pilot training** — both left and right control sets are active.

### Certification target
CS 27 (small helicopter) or EASA VTOL (a relatively new certification path as of 2024).

## What makes this FCU different

Unlike a traditional helicopter (single variable-pitch rotor, often pilot-controlled directly or via fly-by-wire) or a fully electric VTOL (Volocopter, Lilium, Joby — where battery management is central), this aircraft relies on **a single, less powerful piston engine**. Because there is no redundant second engine, the aircraft carries a **whole-aircraft rescue parachute** to handle total engine loss, allowing it to land without any flight control. Stabilization and control methods must therefore be adapted to this single-engine hybrid configuration.

### Pilot controls and flight axes
The pilot uses a **right-hand joystick**. The three flight axes are pitch (tangage), roll (roulis), and yaw (lacet).

## Functional requirements by use case

The specification breaks FCU behavior down into distinct flight scenarios, each with defined inputs, outputs, and rules.

**Case 1 — Takeoff (throttle increased by hand):** As the pilot raises the throttle, engine speed and available electrical power increase, spinning the rotors faster until the aircraft lifts off. The FCU distributes power evenly across all rotors to keep the aircraft level and lifting vertically. It manages progressive power increase, automatic tilt correction (e.g. wind gusts or a failed rotor), continuous sensor monitoring, climb-rate limiting, motor-saturation prevention, altitude and vertical-speed control, and alarm generation for abnormal conditions.

**Case 2 — Hover via the stop button:** Pressing the red push/pull stop button on the joystick holds the aircraft stationary in the air with a fixed heading. The FCU uses positioning and altitude sensors to maintain position and altitude, correcting for wind drift. It handles fallback cases such as GPS dropout (switching to inertial mode), rotor performance loss (redistributing power), logs the stop event, manages subsequent pilot commands (restart/resume), and can disable automatic functions (e.g. auto-follow, return-to-home) temporarily or permanently.

**Case 3 — Climb and descent around a vertical axis:** With the stop button engaged and joystick centered, the pilot presses climb or descent. The FCU detects the command, adjusts motor power proportionally (reducing for descent, increasing for climb), maintains stability against wind, monitors altitude, and handles emergencies (e.g. obstacle detection triggering emergency climb, motor overheat triggering controlled descent, motor jam during climb).

**Case 4 — Hovering yaw rotation:** With the stop button pressed, turning the joystick left or right rotates the aircraft about its vertical axis. The FCU modulates individual rotor speeds to produce the required yaw torque while keeping pitch = 0, roll = 0, and altitude constant. It maintains stability against wind, respects the aircraft's operational limits, and handles faults (gyro failure, loss of yaw authority). Returning the joystick to center reverts to the Case 2 hover.

**Case 5 — Straight-line forward flight:** Pressing the forward button with the joystick centered, the pilot adjusts throttle to hold altitude. The FCU generates pitch setpoints to tilt the aircraft forward for horizontal thrust, controls attitude in real time, compensates for disturbances (gusts, front-rotor loss, speed-sensor failure), manages propulsion and thrust distribution to hold the target speed, and respects pitch-angle limits to prevent stall or instability.

**Case 6 — Turning while moving forward (left/right):** With forward already engaged, turning the joystick makes the FCU coordinate pitch and roll for a balanced turn at constant speed and altitude. It differentiates motor power side-to-side to bank the aircraft, caps the maximum bank angle (with pilot alerts and automatic intervention if exceeded), compensates altitude loss from banking, and returns the aircraft smoothly to stable flight after the turn.

**Case 7 — Turning while climbing or descending:** Combining throttle (climb/descent) with a joystick turn, the FCU analyzes the trajectory, calculates the required bank angle while accounting for changing gravitational load, redistributes motor power, manages attitude and vertical speed, compensates for wind, and continuously monitors sensors and safety systems.

**Case 8 — In-flight emergency stop and parachute deployment:** For critical failures (piston engine, generator/Emrax, flight computers, or many rotors), the pilot presses the red emergency button. The FCU's logic: if the emergency button is pressed and the parachute is not yet deployed, it triggers the parachute. Once deployed, it stops all rotors and shuts down systems — though it may keep a few rotors running at adjusted power to keep the aircraft level during the parachute descent. It continues monitoring critical systems (sensors, batteries, controls) and transmits the emergency situation, location, and flight conditions to ground operators to aid recovery.

**Case 10 — Final shutdown (power-off button):** On the ground after landing, pressing the "shut down" button makes the FCU confirm the order, progressively deactivate onboard systems (non-essential first, then flight-critical), cut electrical power to the motors and components, and confirm safe shutdown to the pilot interface. Backup procedures cover faults such as a motor not responding to shutdown, overheating during shutdown, or a non-functional shutdown button.

## Cross-cutting concerns

**Sensor and system monitoring:** The FCU continuously collects and validates data from gyroscopes, accelerometers, and barometers (plus GPS) to compute motor commands, orientation adjustments, and telemetry. It detects sensor anomalies, falls back to redundant or backup data, and logs critical flight data for post-flight analysis.

**Power management and safety:** Dynamic power balancing prevents motor overload, especially during power transitions in climb and descent. Maximum power limits protect against overheating and damage, climb-rate limits prevent excessive reactions, and saturation prevention preserves control margin.

**Alarms and warnings:** Abnormal conditions trigger graded visual or audible alerts on the radio-control display, designed with ergonomics and pilot workload in mind, and built with redundancy for reliability.

## Document sections not yet detailed

The specification reserves (but does not yet fully populate) sections on:
- **Testing and validation** — test methodology and scenarios covering standard flight and emergencies.
- **Maintenance and support** — preventive/corrective maintenance, spare parts, manuals, and manufacturer technical support.
- **Schedule and budget** — development/delivery timeline and cost estimates for design, manufacturing, and certification.

## Reference projects
- **Mini-Bee** (mini-bee.com) — Rotax 915is/916is piston engine (~140 hp).
- **Workhorse SureFly** — Honda engine (~200 hp).
- **Zephyr helicopter** — cited as the first helicopter with a parachute rescue system.

*Note: the original document states it was partially drafted with the help of ChatGPT.*

FCU multicopter hybrid

2026-05-22T09:18:40Z

Wiki.admin:

A Flight Control Unit, or FCU, is the flight control computer of a hybrid multicopter. In this type of aircraft, energy comes from a piston engine feeding a distributed propulsion architecture with fixed-pitch vertical-thrust propellers. The FCU translates pilot commands into safe, stable, and efficient flight behavior. It distributes power between the rotors, keeps the aircraft balanced, continuously monitors onboard sensors, corrects deviations caused by wind or system anomalies, and manages warnings as well as emergency procedures. Unlike a conventional helicopter, where the pilot directly manages much of the aircraft response, or a fully electric VTOL focused mainly on battery management, the FCU of a hybrid multicopter must simultaneously stabilize flight and coordinate a more complex propulsion system.

10 Operating Cases, from the Simplest to the Most Complex

For clarity, vertical climb and vertical descent are presented here as two separate cases, even though they are grouped together in the original FCU requirements document.

1. Progressive takeoff
When the pilot increases throttle, the FCU distributes power across the rotors so the aircraft lifts vertically while remaining level, limiting climb rate and preventing motor saturation.

2. Stabilized hover
When hover mode is requested, the FCU uses sensor data to maintain position and altitude, even in the presence of wind or drift.

3. Vertical climb
The FCU adjusts thrust so the aircraft climbs along its vertical axis while preserving trajectory control, stability, and motor availability.

4. Vertical descent
The same principle applies during descent: the FCU regulates power to keep the aircraft stable and on a controlled vertical path down to the target altitude.

5. Yaw rotation on the spot
When the pilot commands rotation about the vertical axis, the FCU modulates rotor power to produce accurate yaw motion without excessive drift or loss of control.

6. Straight forward flight
When a forward command is given, the FCU generates a pitch command and adapts rotor power so the aircraft moves ahead in a stable, controlled way.

7. Turning while moving forward
The FCU combines roll, yaw, and power management to perform a coordinated right or left turn during forward flight.

8. Turning while climbing
In a more complex maneuver, the FCU must manage the turn, altitude increase, and reinforced sensor monitoring at the same time to maintain safety and stability.

9. In-flight emergency stop with parachute deployment
In a critical failure, the FCU detects the emergency, confirms parachute deployment logic, stops or manages the rotors as required, continues monitoring critical systems, and issues the alerts needed to secure descent.

10. Final shutdown on the ground
After landing, when the pilot commands shutdown, the FCU confirms the instruction, prepares the aircraft for a safe stop, and cuts the motors according to a controlled sequence.

Why it Matters

The FCU is a core technology for the missions targeted by a hybrid multicopter, including light air ambulance operations, tourism, and pilot training. Without it, distributed propulsion would be difficult to operate safely and reliably. With it, the aircraft can take off, hover, move forward, turn, handle emergencies, and shut down in a controlled way while maintaining a high level of operational safety.

# Flight Control Unit (FCU) for a Hybrid Multicopter — Specification Summary

*Source: Cahier des charges — Flight Control Unit of a Hybrid Multicopter (Author: Chérif Hidoussi, Reviewer: Xavier Dutertre, 2024-11-08)*

## Overview

This document specifies the functional and technical requirements for a **Flight Control Unit (FCU)** that controls a **hybrid multicopter** — an aircraft powered by a single piston engine driving electric generation, with fixed-pitch vertical-thrust propellers (no tilt rotor). The reference design uses around 60 rotors.

The goal is a flight control system that is **safe, reliable, and efficient**, suitable for the multicopter's operational needs across takeoff, stable flight, maneuvers, and emergency procedures.

### Target applications
- **Light air ambulance** — transport of a stabilized patient (no winching). The pilot may be the doctor/stretcher-bearer, seated on the left; the patient is a passenger and does not fly the aircraft.
- **Tourism** — one pilot (left seat); the second person is a passenger with controls disabled.
- **Pilot training** — both left and right control sets are active.

### Certification target
CS 27 (small helicopter) or EASA VTOL (a relatively new certification path as of 2024).

## What makes this FCU different

Unlike a traditional helicopter (single variable-pitch rotor, often pilot-controlled directly or via fly-by-wire) or a fully electric VTOL (Volocopter, Lilium, Joby — where battery management is central), this aircraft relies on **a single, less powerful piston engine**. Because there is no redundant second engine, the aircraft carries a **whole-aircraft rescue parachute** to handle total engine loss, allowing it to land without any flight control. Stabilization and control methods must therefore be adapted to this single-engine hybrid configuration.

### Pilot controls and flight axes
The pilot uses a **right-hand joystick**. The three flight axes are pitch (tangage), roll (roulis), and yaw (lacet).

## Functional requirements by use case

The specification breaks FCU behavior down into distinct flight scenarios, each with defined inputs, outputs, and rules.

**Case 1 — Takeoff (throttle increased by hand):** As the pilot raises the throttle, engine speed and available electrical power increase, spinning the rotors faster until the aircraft lifts off. The FCU distributes power evenly across all rotors to keep the aircraft level and lifting vertically. It manages progressive power increase, automatic tilt correction (e.g. wind gusts or a failed rotor), continuous sensor monitoring, climb-rate limiting, motor-saturation prevention, altitude and vertical-speed control, and alarm generation for abnormal conditions.

**Case 2 — Hover via the stop button:** Pressing the red push/pull stop button on the joystick holds the aircraft stationary in the air with a fixed heading. The FCU uses positioning and altitude sensors to maintain position and altitude, correcting for wind drift. It handles fallback cases such as GPS dropout (switching to inertial mode), rotor performance loss (redistributing power), logs the stop event, manages subsequent pilot commands (restart/resume), and can disable automatic functions (e.g. auto-follow, return-to-home) temporarily or permanently.

**Case 3 — Climb and descent around a vertical axis:** With the stop button engaged and joystick centered, the pilot presses climb or descent. The FCU detects the command, adjusts motor power proportionally (reducing for descent, increasing for climb), maintains stability against wind, monitors altitude, and handles emergencies (e.g. obstacle detection triggering emergency climb, motor overheat triggering controlled descent, motor jam during climb).

**Case 4 — Hovering yaw rotation:** With the stop button pressed, turning the joystick left or right rotates the aircraft about its vertical axis. The FCU modulates individual rotor speeds to produce the required yaw torque while keeping pitch = 0, roll = 0, and altitude constant. It maintains stability against wind, respects the aircraft's operational limits, and handles faults (gyro failure, loss of yaw authority). Returning the joystick to center reverts to the Case 2 hover.

**Case 5 — Straight-line forward flight:** Pressing the forward button with the joystick centered, the pilot adjusts throttle to hold altitude. The FCU generates pitch setpoints to tilt the aircraft forward for horizontal thrust, controls attitude in real time, compensates for disturbances (gusts, front-rotor loss, speed-sensor failure), manages propulsion and thrust distribution to hold the target speed, and respects pitch-angle limits to prevent stall or instability.

**Case 6 — Turning while moving forward (left/right):** With forward already engaged, turning the joystick makes the FCU coordinate pitch and roll for a balanced turn at constant speed and altitude. It differentiates motor power side-to-side to bank the aircraft, caps the maximum bank angle (with pilot alerts and automatic intervention if exceeded), compensates altitude loss from banking, and returns the aircraft smoothly to stable flight after the turn.

**Case 7 — Turning while climbing or descending:** Combining throttle (climb/descent) with a joystick turn, the FCU analyzes the trajectory, calculates the required bank angle while accounting for changing gravitational load, redistributes motor power, manages attitude and vertical speed, compensates for wind, and continuously monitors sensors and safety systems.

**Case 8 — In-flight emergency stop and parachute deployment:** For critical failures (piston engine, generator/Emrax, flight computers, or many rotors), the pilot presses the red emergency button. The FCU's logic: if the emergency button is pressed and the parachute is not yet deployed, it triggers the parachute. Once deployed, it stops all rotors and shuts down systems — though it may keep a few rotors running at adjusted power to keep the aircraft level during the parachute descent. It continues monitoring critical systems (sensors, batteries, controls) and transmits the emergency situation, location, and flight conditions to ground operators to aid recovery.

**Case 10 — Final shutdown (power-off button):** On the ground after landing, pressing the "shut down" button makes the FCU confirm the order, progressively deactivate onboard systems (non-essential first, then flight-critical), cut electrical power to the motors and components, and confirm safe shutdown to the pilot interface. Backup procedures cover faults such as a motor not responding to shutdown, overheating during shutdown, or a non-functional shutdown button.

## Cross-cutting concerns

**Sensor and system monitoring:** The FCU continuously collects and validates data from gyroscopes, accelerometers, and barometers (plus GPS) to compute motor commands, orientation adjustments, and telemetry. It detects sensor anomalies, falls back to redundant or backup data, and logs critical flight data for post-flight analysis.

**Power management and safety:** Dynamic power balancing prevents motor overload, especially during power transitions in climb and descent. Maximum power limits protect against overheating and damage, climb-rate limits prevent excessive reactions, and saturation prevention preserves control margin.

**Alarms and warnings:** Abnormal conditions trigger graded visual or audible alerts on the radio-control display, designed with ergonomics and pilot workload in mind, and built with redundancy for reliability.

## Document sections not yet detailed

The specification reserves (but does not yet fully populate) sections on:
- **Testing and validation** — test methodology and scenarios covering standard flight and emergencies.
- **Maintenance and support** — preventive/corrective maintenance, spare parts, manuals, and manufacturer technical support.
- **Schedule and budget** — development/delivery timeline and cost estimates for design, manufacturing, and certification.

## Reference projects
- **Mini-Bee** (mini-bee.com) — Rotax 915is/916is piston engine (~140 hp).
- **Workhorse SureFly** — Honda engine (~200 hp).
- **Zephyr helicopter** — cited as the first helicopter with a parachute rescue system.

*Note: the original document states it was partially drafted with the help of ChatGPT.*

File:20241108 Cahier de charge FCU VTOL V2.pdf

2026-05-22T09:16:56Z

Wiki.admin:

File:Minibee official 1.png

2026-05-20T07:55:52Z

Wiki.admin: Wiki.admin uploaded a new version of File:Minibee official 1.png

File:Minibee official 1.png

2026-05-19T15:30:16Z

Wiki.admin: Wiki.admin uploaded a new version of File:Minibee official 1.png

Certification FrameWork VTOL

2026-05-19T10:49:51Z

Wiki.admin: /* Useful links */

= VTOL Certification Framework =

'''Mini-Bee / RED VTOL — EASA Certification Framework'''

<div style="border:1px solid #d0d7de; border-radius:14px; padding:22px; background:#f8fafc; margin-bottom:25px;">

<div style="font-size:150%; font-weight:bold; color:#1f4e79; margin-bottom:8px;">
Mini-Bee / RED VTOL — Certification Pathway
</div>

<div style="font-size:105%; line-height:1.6;">
This page presents the high-level EASA certification framework studied for the Mini-Bee / RED VTOL concept.
The objective is to understand how a 2PAX hybrid VTOL multicopter, designed as an ultra-light air ambulance concept, can be positioned inside the European aviation certification environment.
</div>

<br />

[[File:MiniBee_VTOL_Certification_Framework_Hero.png|center|900px|Mini-Bee / RED VTOL certification framework hero visual]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Figure 1.''' Mini-Bee / RED VTOL certification framework overview.
</div>

</div>

__TOC__

== Main presentation ==

<div style="border:2px solid #1f4e79; border-radius:12px; padding:18px; background:#eef6ff; margin-bottom:25px;">

<div style="font-size:125%; font-weight:bold; color:#1f4e79;">
Download the full PowerPoint presentation
</div>

<br />

'''Red VTOL TRL4 — 2PAX VTOL hybrid multicopter — Ultra light air ambulance — EASA Certification Framework'''

<br /><br />

[[File:20260422_RedVTOL_EASA_Certification_01_High_Level_Framework_v2_en.pptx|'''Download the PowerPoint presentation''']]

<br /><br />

This presentation was prepared in the context of the '''Mini-Bee / RED VTOL''' work, with contributions from '''RED VTOL''', '''TechnoPlane''' as coordinator of the Mini-Bee project, and '''ALTEN Sud-Ouest''' through the '''ALTEN Solidaire''' initiative.

</div>

== Project context ==

{| class="wikitable" style="width:100%;"
! Item
! Description
|-
| '''Project'''
| Mini-Bee / RED VTOL
|-
| '''Aircraft concept'''
| 2PAX hybrid VTOL multicopter
|-
| '''Mission orientation'''
| Ultra-light air ambulance / VEMS concept
|-
| '''Main certification authority'''
| EASA — European Union Aviation Safety Agency
|-
| '''Main aircraft basis'''
| CS-27 Small Rotorcraft
|-
| '''VTOL-specific basis'''
| SC-VTOL-02 Small-Category VTOL-Capable Aircraft
|-
| '''Project logic'''
| Build a credible path from innovative VTOL concept to certifiable aircraft architecture
|}

The Mini-Bee / RED VTOL concept is not only a flying vehicle study. It is also a certification-oriented design exercise.

The central question is simple:

: '''How can an innovative hybrid VTOL aircraft be designed from the beginning with certification, safety and operational approval in mind?'''

This question is essential because a VTOL aircraft cannot be evaluated only through performance. It must also be understandable by the authority, technically justified, testable, and traceable.

== RED VTOL and ALTEN Solidaire ==

'''RED VTOL''' is associated with the humanitarian and emergency medical orientation of the project.

The RED VTOL vision gives the Mini-Bee concept a concrete use case: a compact VTOL aircraft able to support medical aid, rapid response, local mobility, and potentially emergency transport missions.

The name RED VTOL is linked to the idea of a '''VTOL vehicle for emergency medical service''', or '''VEMS'''. This mission orientation creates strong design and certification implications:

* the aircraft must be safe in degraded modes;
* the lift and thrust system must be robust;
* the operational use must be clearly defined;
* the pilot and crew logic must be considered;
* medical or public-service missions may bring additional constraints;
* the aircraft must be credible not only as a prototype, but as a future operational system.

'''ALTEN Solidaire''' appears in the presentation as a collaborative support framework.

It refers to the involvement of ALTEN through a solidarity or skills-based contribution logic, with '''Christophe Marionneau, ALTEN Sud-Ouest for ALTEN Solidaire''', mentioned in the presentation credits.

In this context, ALTEN Solidaire contributes to the technical structuring of the certification analysis. The value is not only to produce a document, but to help transform the project into a more rigorous engineering framework.

This type of collaboration is important for Mini-Bee because certification requires several levels of expertise:

* aircraft architecture;
* systems engineering;
* safety analysis;
* regulatory interpretation;
* electric and hybrid propulsion;
* rotorcraft certification logic;
* documentation and traceability.

TechnoPlane is identified as the coordinator of the Mini-Bee project, while RED VTOL and ALTEN Solidaire contribute to the broader collaborative R&D and certification preparation effort.

== Objective of the certification framework ==

The purpose of the certification framework is to define the regulatory environment in which Mini-Bee / RED VTOL could be positioned.

The presentation has four main objectives:

{| class="wikitable" style="width:100%;"
! Objective
! Meaning for the project
|-
| '''Classify the aircraft'''
| Understand whether the aircraft is treated as a rotorcraft, a VTOL-capable aircraft, or both.
|-
| '''Identify applicable texts'''
| List the EASA certification specifications and special conditions that influence design choices.
|-
| '''Assess rule maturity'''
| Understand where VTOL-capable aircraft regulation is mature, evolving, or still uncertain.
|-
| '''Prepare future evidence'''
| Anticipate the analyses, tests and demonstrations needed to support certification.
|}

== Certification snapshot ==

[[File:MiniBee_Certification_Three_Level_Logic.png|center|900px|Mini-Bee certification three-level logic]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Figure 2.''' Three-level certification logic: aircraft framework, system architecture, and compliance evidence.
</div>

<br />

{| class="wikitable" style="width:100%; text-align:center;"
! Level
! Main question
! Main output
|-
| '''High Level'''
| Where does Mini-Bee fit in the EASA framework?
| Aircraft category and certification basis
|-
| '''Medium Level'''
| Which rules apply to each system?
| System and sub-system certification map
|-
| '''Low Level'''
| Which evidence proves compliance?
| Analyses, tests, inspections, simulations and reports
|}

== High Level — aircraft positioning ==

The high-level framework defines the regulatory positioning of Mini-Bee / RED VTOL.

The current logic is to consider the aircraft as:

* a '''small rotorcraft''' under '''CS-27''';
* with '''VTOL-capable characteristics''' under '''SC-VTOL-02'''.

This is the main certification idea of the presentation.

CS-27 provides the small rotorcraft basis.
SC-VTOL-02 covers the specific aspects of VTOL-capable aircraft.

[[File:MiniBee_CS27_SCVTOL_Positioning.png|center|900px|Mini-Bee CS-27 and SC-VTOL-02 positioning]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Figure 3.''' Mini-Bee positioned between CS-27 small rotorcraft logic and SC-VTOL-02 VTOL-capable aircraft logic.
</div>

== Main EASA references ==

EASA is the official European authority for aviation certification.

For the Mini-Bee / RED VTOL project, all certification assumptions must be traced back to official EASA documents, with the correct issue date, amendment level and applicability.

{| class="wikitable" style="width:100%;"
! Reference
! Role in the framework
|-
| '''CS-27'''
| Main basis for small rotorcraft certification.
|-
| '''SC-VTOL-02'''
| Special condition for small-category VTOL-capable aircraft.
|-
| '''CS-VLR'''
| Possible reference for very light rotorcraft, only if the design fits its restrictions.
|-
| '''CS-29'''
| Reference for complex rotorcraft aspects or if the aircraft exits CS-27 boundaries.
|-
| '''CS-E'''
| Certification specifications for engines.
|-
| '''SC E-19'''
| Special condition for electric and hybrid propulsion systems.
|-
| '''CS-P'''
| Certification specifications for propellers.
|-
| '''CS-26'''
| Additional airworthiness specifications for operations.
|-
| '''AMC-20'''
| Acceptable means of compliance for products, parts and appliances.
|-
| '''CS-34'''
| Aircraft engine emissions and fuel venting.
|}

[[File:MiniBee_EASA_Reference_Map.png|center|900px|Mini-Bee EASA reference map]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Figure 4.''' EASA reference map for the Mini-Bee / RED VTOL certification framework.
</div>

== System and sub-system logic ==

The medium-level framework translates the aircraft-level certification basis into system and sub-system references.

For Mini-Bee / RED VTOL, the main technical domains are:

* engine;
* electric and hybrid propulsion system;
* propellers and rotors;
* high-power electrical architecture;
* lift / thrust system;
* operational airworthiness;
* emissions and fuel venting;
* environmental constraints.

The important point is that Mini-Bee cannot be certified only as a list of independent components.

The aircraft must be understood as an integrated system.

In particular, the complete '''lift / thrust system''' must be considered as a chain from energy source to thrust production.

== Lift / thrust system chain ==

The lift / thrust system is the core technical object of the Mini-Bee / RED VTOL certification study.

It includes:

{| class="wikitable" style="width:100%;"
! Chain element
! Certification attention point
|-
| '''Fuel / battery'''
| Energy availability, storage, safety and endurance.
|-
| '''Engine'''
| Certified status, installation, operating limits and failure modes.
|-
| '''Generator'''
| Electrical generation, reliability and integration with the hybrid chain.
|-
| '''Power electronics'''
| High-voltage distribution, thermal control, EMC and safety.
|-
| '''Motors'''
| Redundancy, monitoring, degraded modes and thrust command.
|-
| '''Rotors / propellers'''
| Loads, vibration, thrust generation, noise and failure behaviour.
|-
| '''Lift'''
| Aircraft controllability, stability and safety in normal and degraded conditions.
|}

[[File:MiniBee_Lift_Thrust_System_Chain.png|center|900px|Mini-Bee lift thrust system chain]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Figure 5.''' Lift / thrust system chain from energy source to distributed lift.
</div>

== Certification risks ==

The presentation highlights several certification risks that must be controlled early.

{| class="wikitable" style="width:100%;"
! Risk
! Why it matters
|-
| '''CS-27 / SC-VTOL boundary'''
| Mini-Bee combines rotorcraft behaviour and VTOL-capable characteristics.
|-
| '''Possible CS-29 drift'''
| Mass, occupants, system complexity or operations may increase certification expectations.
|-
| '''Hybrid propulsion'''
| The complete energy and propulsion chain may become a safety-critical integrated system.
|-
| '''High electrical power'''
| EWIS, EMC, power electronics and electrical safety must be justified.
|-
| '''Distributed lift'''
| Failure cases and degraded modes must be clearly demonstrated.
|-
| '''VEMS mission'''
| Medical or public-service missions may create additional operational constraints.
|}

== Low Level — evidence and demonstration ==

The low level is the level of concrete proof.

Certification is not based only on design intention.
It is based on evidence.

Typical evidence includes:

* requirement allocation;
* safety analyses;
* calculations;
* system schematics;
* bench tests;
* HIL / SIL simulations;
* inspection reports;
* environmental qualification;
* flight test preparation;
* flight test reports;
* compliance documentation.

The purpose of this work is to connect each certification requirement to a verifiable means of compliance.

This can include:

{| class="wikitable" style="width:100%; text-align:center;"
! Analysis
! Test
! Simulation
! Inspection
! Demonstration
|-
| Safety studies
| Bench tests
| HIL / SIL
| Installation checks
| Flight evidence
|}

== Certification pathway logic ==

The certification pathway should be progressive.

It should move from regulatory positioning to detailed evidence:

{| class="wikitable" style="width:100%; text-align:center;"
! Step 1
! Step 2
! Step 3
! Step 4
! Step 5
|-
| Aircraft classification
| Applicable rules
| System allocation
| Evidence production
| Testing and approval
|}

The presentation therefore supports a structured development logic:

* first define the aircraft category;
* then identify the applicable EASA texts;
* then allocate requirements to systems and sub-systems;
* then prepare the evidence matrix;
* then organize tests, analyses and demonstrations.

== What this work brings to the project ==

The RED VTOL / ALTEN Solidaire certification work brings structure to the Mini-Bee project.

It helps the project move from a conceptual aircraft architecture to a more credible engineering path.

The main benefits are:

* better understanding of EASA certification logic;
* clearer positioning between CS-27 and SC-VTOL-02;
* identification of system-level certification references;
* early detection of regulatory risks;
* preparation of future compliance evidence;
* improved design discipline;
* stronger credibility for partners, authorities and future operators.

== Conclusion ==

Mini-Bee / RED VTOL should currently be considered as a '''small rotorcraft with VTOL-capable characteristics'''.

The most credible certification logic is based on:

* '''CS-27''' as the small rotorcraft basis;
* '''SC-VTOL-02''' for VTOL-capable aspects;
* '''SC E-19''' for electric and hybrid propulsion;
* '''CS-E''' for engines;
* '''CS-P''' for propellers;
* additional references such as CS-26, AMC-20, CS-34, CS-VLR and CS-29 when relevant.

The certification framework is not only a regulatory checklist.
It is a design management tool.

For Mini-Bee / RED VTOL, it helps transform an innovative hybrid VTOL concept into a structured, traceable and progressively certifiable aircraft project.

== Useful links ==

* [[File:20260422_RedVTOL_EASA_Certification_01_High_Level_Framework_v2_en.pptx|Download the PowerPoint presentation]]
* [[Mini-Bee]]
* [[Minibee_TRL3]]
* [[RED VTOL ONG]]

File:MiniBee VTOL Certification Framework Hero.png

2026-05-19T10:41:41Z

Wiki.admin:

Certification FrameWork VTOL

2026-05-19T10:35:26Z

Wiki.admin:

Certification FrameWork VTOL

2026-05-19T10:29:04Z

Wiki.admin:

= VTOL Certification Framework =

'''Mini-Bee / RED VTOL — EASA Certification Framework'''

<div style="border:1px solid #d0d7de; border-radius:14px; padding:22px; background:#f8fafc; margin-bottom:25px;">

<div style="font-size:150%; font-weight:bold; color:#1f4e79; margin-bottom:8px;">
Mini-Bee / RED VTOL — Certification Pathway
</div>

<div style="font-size:105%; line-height:1.6;">
This page presents the high-level EASA certification framework studied for the Mini-Bee / RED VTOL concept.
The objective is to understand how a 2PAX hybrid VTOL multicopter, designed as an ultra-light air ambulance concept, can be positioned inside the European aviation certification environment.
</div>

<br />

[[File:MiniBee_VTOL_Certification_Framework_Hero.png|center|900px|Mini-Bee / RED VTOL certification framework hero visual]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Figure 1.''' Mini-Bee / RED VTOL certification framework overview.
</div>

</div>

__TOC__

== Main presentation ==

<div style="border:2px solid #1f4e79; border-radius:12px; padding:18px; background:#eef6ff; margin-bottom:25px;">

<div style="font-size:125%; font-weight:bold; color:#1f4e79;">
Download the full PowerPoint presentation
</div>

<br />

'''Red VTOL TRL4 — 2PAX VTOL hybrid multicopter — Ultra light air ambulance — EASA Certification Framework'''

<br /><br />

[[File:20260422_RedVTOL_EASA_Certification_01_High_Level_Framework_v2_en.pptx|'''Download the PowerPoint presentation''']]

<br /><br />

This presentation was prepared in the context of the '''Mini-Bee / RED VTOL''' work, with contributions from '''RED VTOL''', '''TechnoPlane''' as coordinator of the Mini-Bee project, and '''ALTEN Sud-Ouest''' through the '''ALTEN Solidaire''' initiative.

</div>

== Project context ==

{| class="wikitable" style="width:100%;"
! Item
! Description
|-
| '''Project'''
| Mini-Bee / RED VTOL
|-
| '''Aircraft concept'''
| 2PAX hybrid VTOL multicopter
|-
| '''Mission orientation'''
| Ultra-light air ambulance / VEMS concept
|-
| '''Main certification authority'''
| EASA — European Union Aviation Safety Agency
|-
| '''Main aircraft basis'''
| CS-27 Small Rotorcraft
|-
| '''VTOL-specific basis'''
| SC-VTOL-02 Small-Category VTOL-Capable Aircraft
|-
| '''Project logic'''
| Build a credible path from innovative VTOL concept to certifiable aircraft architecture
|}

The Mini-Bee / RED VTOL concept is not only a flying vehicle study. It is also a certification-oriented design exercise.

The central question is simple:

: '''How can an innovative hybrid VTOL aircraft be designed from the beginning with certification, safety and operational approval in mind?'''

This question is essential because a VTOL aircraft cannot be evaluated only through performance. It must also be understandable by the authority, technically justified, testable, and traceable.

== RED VTOL and ALTEN Solidaire ==

'''RED VTOL''' is associated with the humanitarian and emergency medical orientation of the project.
The RED VTOL vision gives the Mini-Bee concept a concrete use case: a compact VTOL aircraft able to support medical aid, rapid response, local mobility, and potentially emergency transport missions.

The name RED VTOL is linked to the idea of a '''VTOL vehicle for emergency medical service''', or '''VEMS'''. This mission orientation creates strong design and certification implications:

* the aircraft must be safe in degraded modes;
* the lift and thrust system must be robust;
* the operational use must be clearly defined;
* the pilot and crew logic must be considered;
* medical or public-service missions may bring additional constraints;
* the aircraft must be credible not only as a prototype, but as a future operational system.

'''ALTEN Solidaire''' appears in the presentation as a collaborative support framework.
It refers to the involvement of ALTEN through a solidarity or skills-based contribution logic, with '''Christophe Marionneau, ALTEN Sud-Ouest for ALTEN Solidaire''', mentioned in the presentation credits.

In this context, ALTEN Solidaire contributes to the technical structuring of the certification analysis. The value is not only to produce a document, but to help transform the project into a more rigorous engineering framework.

This type of collaboration is important for Mini-Bee because certification requires several levels of expertise:

* aircraft architecture;
* systems engineering;
* safety analysis;
* regulatory interpretation;
* electric and hybrid propulsion;
* rotorcraft certification logic;
* documentation and traceability.

TechnoPlane is identified as the coordinator of the Mini-Bee project, while RED VTOL and ALTEN Solidaire contribute to the broader collaborative R&D and certification preparation effort.

== Objective of the certification framework ==

The purpose of the certification framework is to define the regulatory environment in which Mini-Bee / RED VTOL could be positioned.

The presentation has four main objectives:

{| class="wikitable" style="width:100%;"
! Objective
! Meaning for the project
|-
| '''Classify the aircraft'''
| Understand whether the aircraft is treated as a rotorcraft, a VTOL-capable aircraft, or both.
|-
| '''Identify applicable texts'''
| List the EASA certification specifications and special conditions that influence design choices.
|-
| '''Assess rule maturity'''
| Understand where VTOL-capable aircraft regulation is mature, evolving, or still uncertain.
|-
| '''Prepare future evidence'''
| Anticipate the analyses, tests and demonstrations needed to support certification.
|}

== Certification snapshot ==

[[File:MiniBee_Certification_Three_Level_Logic.png|center|900px|Mini-Bee certification three-level logic]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Figure 2.''' Three-level certification logic: aircraft framework, system architecture, and compliance evidence.
</div>

<br />

{| class="wikitable" style="width:100%; text-align:center;"
! Level
! Main question
! Main output
|-
| '''High Level'''
| Where does Mini-Bee fit in the EASA framework?
| Aircraft category and certification basis
|-
| '''Medium Level'''
| Which rules apply to each system?
| System and sub-system certification map
|-
| '''Low Level'''
| Which evidence proves compliance?
| Analyses, tests, inspections, simulations and reports
|}

== High Level — aircraft positioning ==

The high-level framework defines the regulatory positioning of Mini-Bee / RED VTOL.

The current logic is to consider the aircraft as:

* a '''small rotorcraft''' under '''CS-27''';
* with '''VTOL-capable characteristics''' under '''SC-VTOL-02'''.

This is the main certification idea of the presentation.

CS-27 provides the small rotorcraft basis.
SC-VTOL-02 covers the specific aspects of VTOL-capable aircraft.

[[File:MiniBee_CS27_SCVTOL_Positioning.png|center|900px|Mini-Bee CS-27 and SC-VTOL-02 positioning]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Figure 3.''' Mini-Bee positioned between CS-27 small rotorcraft logic and SC-VTOL-02 VTOL-capable aircraft logic.
</div>

== Main EASA references ==

EASA is the official European authority for aviation certification.

For the Mini-Bee / RED VTOL project, all certification assumptions must be traced back to official EASA documents, with the correct issue date, amendment level and applicability.

{| class="wikitable" style="width:100%;"
! Reference
! Role in the framework
|-
| '''CS-27'''
| Main basis for small rotorcraft certification.
|-
| '''SC-VTOL-02'''
| Special condition for small-category VTOL-capable aircraft.
|-
| '''CS-VLR'''
| Possible reference for very light rotorcraft, only if the design fits its restrictions.
|-
| '''CS-29'''
| Reference for complex rotorcraft aspects or if the aircraft exits CS-27 boundaries.
|-
| '''CS-E'''
| Certification specifications for engines.
|-
| '''SC E-19'''
| Special condition for electric and hybrid propulsion systems.
|-
| '''CS-P'''
| Certification specifications for propellers.
|-
| '''CS-26'''
| Additional airworthiness specifications for operations.
|-
| '''AMC-20'''
| Acceptable means of compliance for products, parts and appliances.
|-
| '''CS-34'''
| Aircraft engine emissions and fuel venting.
|}

[[File:MiniBee_EASA_Reference_Map.png|center|900px|Mini-Bee EASA reference map]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Figure 4.''' EASA reference map for the Mini-Bee / RED VTOL certification framework.
</div>

== System and sub-system logic ==

The medium-level framework translates the aircraft-level certification basis into system and sub-system references.

For Mini-Bee / RED VTOL, the main technical domains are:

* engine;
* electric and hybrid propulsion system;
* propellers and rotors;
* high-power electrical architecture;
* lift / thrust system;
* operational airworthiness;
* emissions and fuel venting;
* environmental constraints.

The important point is that Mini-Bee cannot be certified only as a list of independent components.

The aircraft must be understood as an integrated system.

In particular, the complete '''lift / thrust system''' must be considered as a chain from energy source to thrust production.

== Lift / thrust system chain ==

The lift / thrust system is the core technical object of the Mini-Bee / RED VTOL certification study.

It includes:

{| class="wikitable" style="width:100%;"
! Chain element
! Certification attention point
|-
| '''Fuel / battery'''
| Energy availability, storage, safety and endurance.
|-
| '''Engine'''
| Certified status, installation, operating limits and failure modes.
|-
| '''Generator'''
| Electrical generation, reliability and integration with the hybrid chain.
|-
| '''Power electronics'''
| High-voltage distribution, thermal control, EMC and safety.
|-
| '''Motors'''
| Redundancy, monitoring, degraded modes and thrust command.
|-
| '''Rotors / propellers'''
| Loads, vibration, thrust generation, noise and failure behaviour.
|-
| '''Lift'''
| Aircraft controllability, stability and safety in normal and degraded conditions.
|}

[[File:MiniBee_Lift_Thrust_System_Chain.png|center|900px|Mini-Bee lift thrust system chain]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Figure 5.''' Lift / thrust system chain from energy source to distributed lift.
</div>

== Certification risks ==

The presentation highlights several certification risks that must be controlled early.

{| class="wikitable" style="width:100%;"
! Risk
! Why it matters
|-
| '''CS-27 / SC-VTOL boundary'''
| Mini-Bee combines rotorcraft behaviour and VTOL-capable characteristics.
|-
| '''Possible CS-29 drift'''
| Mass, occupants, system complexity or operations may increase certification expectations.
|-
| '''Hybrid propulsion'''
| The complete energy and propulsion chain may become a safety-critical integrated system.
|-
| '''High electrical power'''
| EWIS, EMC, power electronics and electrical safety must be justified.
|-
| '''Distributed lift'''
| Failure cases and degraded modes must be clearly demonstrated.
|-
| '''VEMS mission'''
| Medical or public-service missions may create additional operational constraints.
|}

== Low Level — evidence and demonstration ==

The low level is the level of concrete proof.

Certification is not based only on design intention.
It is based on evidence.

Typical evidence includes:

* requirement allocation;
* safety analyses;
* calculations;
* system schematics;
* bench tests;
* HIL / SIL simulations;
* inspection reports;
* environmental qualification;
* flight test preparation;
* flight test reports;
* compliance documentation.

[[File:MiniBee_Low_Level_Evidence_Matrix.png|center|900px|Mini-Bee low level evidence matrix]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Figure 6.''' Low-level evidence matrix linking requirements to analyses, tests, inspections and demonstrations.
</div>

== Certification pathway ==

The certification pathway should be progressive.

It should move from regulatory positioning to detailed evidence:

{| class="wikitable" style="width:100%; text-align:center;"
! Step 1
! Step 2
! Step 3
! Step 4
! Step 5
|-
| Aircraft classification
| Applicable rules
| System allocation
| Evidence production
| Testing and approval
|}

[[File:MiniBee_Certification_Pathway.png|center|900px|Mini-Bee certification pathway]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Figure 7.''' Certification pathway from concept definition to compliance demonstration.
</div>

== What this work brings to the project ==

The RED VTOL / ALTEN Solidaire certification work brings structure to the Mini-Bee project.

It helps the project move from a conceptual aircraft architecture to a more credible engineering path.

The main benefits are:

* better understanding of EASA certification logic;
* clearer positioning between CS-27 and SC-VTOL-02;
* identification of system-level certification references;
* early detection of regulatory risks;
* preparation of future compliance evidence;
* improved design discipline;
* stronger credibility for partners, authorities and future operators.

== Conclusion ==

Mini-Bee / RED VTOL should currently be considered as a '''small rotorcraft with VTOL-capable characteristics'''.

The most credible certification logic is based on:

* '''CS-27''' as the small rotorcraft basis;
* '''SC-VTOL-02''' for VTOL-capable aspects;
* '''SC E-19''' for electric and hybrid propulsion;
* '''CS-E''' for engines;
* '''CS-P''' for propellers;
* additional references such as CS-26, AMC-20, CS-34, CS-VLR and CS-29 when relevant.

The certification framework is not only a regulatory checklist.
It is a design management tool.

For Mini-Bee / RED VTOL, it helps transform an innovative hybrid VTOL concept into a structured, traceable and progressively certifiable aircraft project.

== Useful links ==

* [[File:20260422_RedVTOL_EASA_Certification_01_High_Level_Framework_v2_en.pptx|Download the PowerPoint presentation]]
* [[Mini-Bee]]
* [[Minibee_TRL3]]
* [[RED VTOL]]
* [[CS-27]]
* [[SC-VTOL-02]]
* [[Hybrid Propulsion]]
* [[TRL]]

File:MiniBee Lift Thrust System Chain.png

2026-05-19T10:23:54Z

Wiki.admin:

File:MiniBee Medium Level System Certification Map.png

2026-05-19T10:04:03Z

Wiki.admin:

File:MiniBee EASA Reference Map.png

2026-05-19T09:21:21Z

Wiki.admin:

File:MiniBee CS27 SCVTOL Positioning.png

2026-05-19T09:06:34Z

Wiki.admin:

File:MiniBee Certification Three Level Logic.png

2026-05-19T08:48:10Z

Wiki.admin:

Certification FrameWork VTOL

2026-05-19T08:25:09Z

Wiki.admin: /* VTOL Certification Framework */

= VTOL Certification Framework =

<div style="border:1px solid #d0d7de; border-radius:14px; padding:22px; background:#f8fafc; margin-bottom:25px;">

<div style="font-size:150%; font-weight:bold; margin-bottom:8px;">
Mini-Bee / Red VTOL — EASA Certification Framework
</div>

<div style="font-size:105%; line-height:1.6;">
A high-level certification map for a 2PAX hybrid VTOL multicopter designed as an ultra-light air ambulance concept.
</div>

<br />

[[File:20260422 RedVTOL EASA Certification 01 High Level Framework v2 en.pptx|center|900px|Mini-Bee / Red VTOL EASA Certification Framework]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Hero visual placeholder''' — Mini-Bee aircraft, EASA certification path, CS-27, SC-VTOL-02 and system demonstration.
</div>

</div>

__TOC__

== Main document ==

<div style="border:2px solid #1f4e79; border-radius:12px; padding:18px; background:#eef6ff; margin-bottom:25px;">

<div style="font-size:125%; font-weight:bold; color:#1f4e79;">
Download the full PowerPoint presentation
</div>

<br />

'''Red VTOL TRL4 — 2PAX VTOL hybrid multicopter — Ultra light air ambulance — EASA Certification Framework'''

<br /><br />

[[File:20260422_RedVTOL_EASA_Certification_01_High_Level_Framework_v2_en.pptx|'''Download the PowerPoint presentation''']]

<br /><br />

This presentation defines the high-level EASA certification logic for Mini-Bee / Red VTOL.
It identifies the main aircraft classification, the applicable certification texts, the system references, and the next certification risks to analyse.

</div>

== Certification snapshot ==

{| class="wikitable" style="width:100%; text-align:center;"
! Project
! Aircraft logic
! Main basis
! VTOL complement
! Key issue
|-
| '''Mini-Bee / Red VTOL'''
| 2PAX hybrid VTOL multicopter
| '''CS-27'''
| '''SC-VTOL-02'''
| Certifiable lift/thrust system
|}

<gallery mode="packed" heights="210px">
File:MiniBee_High_Level_Certification_Map.png|'''High Level'''<br />Aircraft classification and regulatory basis.
File:MiniBee_System_Certification_Map.png|'''Medium Level'''<br />System and sub-system certification references.
File:MiniBee_Evidence_Demonstration_Map.png|'''Low Level'''<br />Evidence, tests and means of compliance.
</gallery>

== Page objective ==

The objective of this page is to summarize the certification logic of Mini-Bee / Red VTOL.

It answers three practical questions:

{| class="wikitable" style="width:100%;"
! Question
! Certification answer
|-
| '''What is the aircraft category?'''
| Small rotorcraft with VTOL-capable characteristics.
|-
| '''Which rules apply?'''
| CS-27, SC-VTOL-02 and associated system references.
|-
| '''What must be demonstrated?'''
| Safety, compliance, lift/thrust system robustness and technical evidence.
|}

== Visual certification logic ==

[[File:MiniBee_Certification_Three_Level_Logic.png|center|900px|Mini-Bee certification three-level logic]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Figure placeholder''' — Three-level certification logic: High Level, Medium Level, Low Level.
</div>

<br />

{| class="wikitable" style="width:100%;"
! Level
! Meaning
! Main output
|-
| '''High Level'''
| Aircraft classification and certification basis.
| CS-27 + SC-VTOL-02 positioning.
|-
| '''Medium Level'''
| System and sub-system rules.
| CS-E, SC E-19, CS-P, CS-26, AMC-20, CS-34.
|-
| '''Low Level'''
| Compliance demonstration.
| Analyses, tests, simulations, inspections and reports.
|}

== High Level — aircraft positioning ==

<div style="display:flex; gap:22px; align-items:flex-start; flex-wrap:wrap;">

<div style="flex:1; min-width:320px;">

The current certification logic is to position Mini-Bee / Red VTOL as:

* a '''small rotorcraft''' under '''CS-27''';
* with '''VTOL-capable characteristics''' under '''SC-VTOL-02'''.

This is the central regulatory positioning of the project.

CS-27 gives the rotorcraft basis.
SC-VTOL-02 covers the specific VTOL-capable aspects.

</div>

<div style="flex:1; min-width:320px;">

[[File:MiniBee_CS27_SCVTOL_Positioning.png|center|430px|Mini-Bee CS-27 and SC-VTOL-02 positioning]]

<div style="text-align:center; font-size:90%; color:#555;">
'''Visual placeholder''' — Mini-Bee positioned between CS-27 and SC-VTOL-02.
</div>

</div>

</div>

== Main EASA references ==

{| class="wikitable" style="width:100%;"
! Reference
! Role in the framework
|-
| '''EASA'''
| Official European authority for aviation certification.
|-
| '''CS-27'''
| Main basis for small rotorcraft.
|-
| '''SC-VTOL-02'''
| Special condition for small-category VTOL-capable aircraft.
|-
| '''CS-VLR'''
| Possible reference for very light rotorcraft, if the design fits.
|-
| '''CS-29'''
| Reference for more complex rotorcraft aspects.
|}

[[File:MiniBee_EASA_Reference_Map.png|center|900px|Mini-Bee EASA reference map]]

<div style="text-align:center; font-size:90%; color:#555;">
'''Visual placeholder''' — EASA reference map: CS-27, SC-VTOL-02, CS-VLR and CS-29.
</div>

== Medium Level — system certification map ==

The aircraft-level certification basis must be translated into system and sub-system references.

{| class="wikitable" style="width:100%;"
! Aircraft domain
! Main certification reference
|-
| Engine
| '''CS-E'''
|-
| Electric / hybrid propulsion
| '''SC E-19'''
|-
| Propellers
| '''CS-P'''
|-
| Operational airworthiness
| '''CS-26'''
|-
| Products, parts and appliances
| '''AMC-20'''
|-
| Emissions and fuel venting
| '''CS-34'''
|}

[[File:MiniBee_Medium_Level_System_Certification_Map.png|center|900px|Mini-Bee medium level certification map]]

<div style="text-align:center; font-size:90%; color:#555;">
'''Visual placeholder''' — System map linking each aircraft domain to its certification reference.
</div>

== Lift / thrust system ==

For Mini-Bee / Red VTOL, the key technical object is the complete '''lift / thrust system'''.

It must be considered as an integrated chain.

[[File:MiniBee_Lift_Thrust_System_Chain.png|center|900px|Mini-Bee lift thrust system chain]]

<div style="text-align:center; font-size:90%; color:#555;">
'''Visual placeholder''' — Fuel source → engine → generator → power electronics → motors → propellers → thrust.
</div>

<br />

{| class="wikitable" style="width:100%;"
! Chain element
! Certification attention
|-
| Energy source
| Safety, endurance, fuel venting.
|-
| Thermal engine
| CS-E and installation.
|-
| Electrical generation
| Reliability and degraded modes.
|-
| Power electronics
| Electrical safety and EMC.
|-
| Electric motors
| Redundancy and failure cases.
|-
| Propellers / rotors
| Loads, vibration, noise and safety.
|-
| Control logic
| Monitoring, command and degraded operation.
|}

== Low Level — evidence and demonstration ==

Certification is not based on intention.
It is based on documented evidence.

[[File:MiniBee_Low_Level_Evidence_Matrix.png|center|900px|Mini-Bee evidence matrix]]

<div style="text-align:center; font-size:90%; color:#555;">
'''Visual placeholder''' — Requirements linked to analyses, tests, inspections, simulations and demonstrations.
</div>

<br />

{| class="wikitable" style="width:100%; text-align:center;"
! Analysis
! Test
! Simulation
! Inspection
! Demonstration
|-
| Safety studies
| Bench tests
| HIL / SIL
| Installation checks
| Flight evidence
|}

== Certification risks ==

{| class="wikitable" style="width:100%;"
! Risk
! Design impact
|-
| '''CS-27 / SC-VTOL boundary'''
| The aircraft must remain clearly classifiable.
|-
| '''CS-29 drift'''
| Complexity may increase certification burden.
|-
| '''Hybrid propulsion'''
| The full chain may be safety-critical.
|-
| '''High electrical power'''
| EWIS, EMC and power distribution must be justified.
|-
| '''Distributed lift'''
| Failure cases and degraded modes must be demonstrated.
|-
| '''VEMS mission'''
| Medical or public service use may add operational constraints.
|}

== Certification pathway ==

[[File:MiniBee_Certification_Pathway.png|center|900px|Mini-Bee certification pathway]]

<div style="text-align:center; font-size:90%; color:#555;">
'''Visual placeholder''' — Concept → classification → system map → evidence → tests → operational approval.
</div>

== Key conclusions from the presentation ==

<div style="border-left:5px solid #1f4e79; padding:14px 18px; background:#f6f8fa; margin:18px 0;">

Mini-Bee / Red VTOL should currently be considered as a '''small rotorcraft with VTOL-capable characteristics'''.

The most credible certification logic is:

* '''CS-27''' as the small rotorcraft basis;
* '''SC-VTOL-02''' for VTOL-capable aspects;
* '''SC E-19''' for hybrid propulsion;
* '''CS-E''' and '''CS-P''' for engine and propulsive elements;
* additional references when operations, complexity or environmental aspects require them.

</div>

== Visuals to create ==

{| class="wikitable" style="width:100%;"
! File name
! Role
|-
| '''MiniBee_VTOL_Certification_Framework_Hero.png'''
| Hero image for the top of the page.
|-
| '''MiniBee_Certification_Three_Level_Logic.png'''
| Explain High / Medium / Low certification levels.
|-
| '''MiniBee_CS27_SCVTOL_Positioning.png'''
| Show the dual positioning of Mini-Bee.
|-
| '''MiniBee_EASA_Reference_Map.png'''
| Show the main EASA references.
|-
| '''MiniBee_Medium_Level_System_Certification_Map.png'''
| Link systems to certification references.
|-
| '''MiniBee_Lift_Thrust_System_Chain.png'''
| Show the full lift/thrust chain.
|-
| '''MiniBee_Low_Level_Evidence_Matrix.png'''
| Show compliance evidence.
|-
| '''MiniBee_Certification_Pathway.png'''
| Final certification roadmap visual.
|}

== Useful links ==

* [[File:20260422_RedVTOL_EASA_Certification_01_High_Level_Framework_v2_en.pptx|Download the PowerPoint presentation]]
* [[Mini-Bee]]
* [[Minibee_TRL3]]
* [[RED VTOL]]
* [[CS-27]]
* [[SC-VTOL-02]]
* [[Hybrid Propulsion]]

== See also ==

* [[Mini-Bee]]
* [[Bee-Plane]]
* [[Iso-Plane]]
* [[RED VTOL ONG]]

File:20260422 RedVTOL EASA Certification 01 High Level Framework v2 en.pptx

2026-05-19T08:24:05Z

Wiki.admin:

Certification FrameWork VTOL

2026-05-19T08:18:25Z

Wiki.admin:

= VTOL Certification Framework =

<div style="border:1px solid #d0d7de; border-radius:14px; padding:22px; background:#f8fafc; margin-bottom:25px;">

<div style="font-size:150%; font-weight:bold; margin-bottom:8px;">
Mini-Bee / Red VTOL — EASA Certification Framework
</div>

<div style="font-size:105%; line-height:1.6;">
A high-level certification map for a 2PAX hybrid VTOL multicopter designed as an ultra-light air ambulance concept.
</div>

<br />

[[File:MiniBee_VTOL_Certification_Framework_Hero.png|center|900px|Mini-Bee / Red VTOL EASA Certification Framework]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Hero visual placeholder''' — Mini-Bee aircraft, EASA certification path, CS-27, SC-VTOL-02 and system demonstration.
</div>

</div>

__TOC__

== Main document ==

<div style="border:2px solid #1f4e79; border-radius:12px; padding:18px; background:#eef6ff; margin-bottom:25px;">

<div style="font-size:125%; font-weight:bold; color:#1f4e79;">
Download the full PowerPoint presentation
</div>

<br />

'''Red VTOL TRL4 — 2PAX VTOL hybrid multicopter — Ultra light air ambulance — EASA Certification Framework'''

<br /><br />

[[File:20260422_RedVTOL_EASA_Certification_01_High_Level_Framework_v2_en.pptx|'''Download the PowerPoint presentation''']]

<br /><br />

This presentation defines the high-level EASA certification logic for Mini-Bee / Red VTOL.
It identifies the main aircraft classification, the applicable certification texts, the system references, and the next certification risks to analyse.

</div>

== Certification snapshot ==

{| class="wikitable" style="width:100%; text-align:center;"
! Project
! Aircraft logic
! Main basis
! VTOL complement
! Key issue
|-
| '''Mini-Bee / Red VTOL'''
| 2PAX hybrid VTOL multicopter
| '''CS-27'''
| '''SC-VTOL-02'''
| Certifiable lift/thrust system
|}

<gallery mode="packed" heights="210px">
File:MiniBee_High_Level_Certification_Map.png|'''High Level'''<br />Aircraft classification and regulatory basis.
File:MiniBee_System_Certification_Map.png|'''Medium Level'''<br />System and sub-system certification references.
File:MiniBee_Evidence_Demonstration_Map.png|'''Low Level'''<br />Evidence, tests and means of compliance.
</gallery>

== Page objective ==

The objective of this page is to summarize the certification logic of Mini-Bee / Red VTOL.

It answers three practical questions:

{| class="wikitable" style="width:100%;"
! Question
! Certification answer
|-
| '''What is the aircraft category?'''
| Small rotorcraft with VTOL-capable characteristics.
|-
| '''Which rules apply?'''
| CS-27, SC-VTOL-02 and associated system references.
|-
| '''What must be demonstrated?'''
| Safety, compliance, lift/thrust system robustness and technical evidence.
|}

== Visual certification logic ==

[[File:MiniBee_Certification_Three_Level_Logic.png|center|900px|Mini-Bee certification three-level logic]]

<div style="text-align:center; font-size:90%; color:#555; margin-top:8px;">
'''Figure placeholder''' — Three-level certification logic: High Level, Medium Level, Low Level.
</div>

<br />

{| class="wikitable" style="width:100%;"
! Level
! Meaning
! Main output
|-
| '''High Level'''
| Aircraft classification and certification basis.
| CS-27 + SC-VTOL-02 positioning.
|-
| '''Medium Level'''
| System and sub-system rules.
| CS-E, SC E-19, CS-P, CS-26, AMC-20, CS-34.
|-
| '''Low Level'''
| Compliance demonstration.
| Analyses, tests, simulations, inspections and reports.
|}

== High Level — aircraft positioning ==

<div style="display:flex; gap:22px; align-items:flex-start; flex-wrap:wrap;">

<div style="flex:1; min-width:320px;">

The current certification logic is to position Mini-Bee / Red VTOL as:

* a '''small rotorcraft''' under '''CS-27''';
* with '''VTOL-capable characteristics''' under '''SC-VTOL-02'''.

This is the central regulatory positioning of the project.

CS-27 gives the rotorcraft basis.
SC-VTOL-02 covers the specific VTOL-capable aspects.

</div>

<div style="flex:1; min-width:320px;">

[[File:MiniBee_CS27_SCVTOL_Positioning.png|center|430px|Mini-Bee CS-27 and SC-VTOL-02 positioning]]

<div style="text-align:center; font-size:90%; color:#555;">
'''Visual placeholder''' — Mini-Bee positioned between CS-27 and SC-VTOL-02.
</div>

</div>

</div>

== Main EASA references ==

{| class="wikitable" style="width:100%;"
! Reference
! Role in the framework
|-
| '''EASA'''
| Official European authority for aviation certification.
|-
| '''CS-27'''
| Main basis for small rotorcraft.
|-
| '''SC-VTOL-02'''
| Special condition for small-category VTOL-capable aircraft.
|-
| '''CS-VLR'''
| Possible reference for very light rotorcraft, if the design fits.
|-
| '''CS-29'''
| Reference for more complex rotorcraft aspects.
|}

[[File:MiniBee_EASA_Reference_Map.png|center|900px|Mini-Bee EASA reference map]]

<div style="text-align:center; font-size:90%; color:#555;">
'''Visual placeholder''' — EASA reference map: CS-27, SC-VTOL-02, CS-VLR and CS-29.
</div>

== Medium Level — system certification map ==

The aircraft-level certification basis must be translated into system and sub-system references.

{| class="wikitable" style="width:100%;"
! Aircraft domain
! Main certification reference
|-
| Engine
| '''CS-E'''
|-
| Electric / hybrid propulsion
| '''SC E-19'''
|-
| Propellers
| '''CS-P'''
|-
| Operational airworthiness
| '''CS-26'''
|-
| Products, parts and appliances
| '''AMC-20'''
|-
| Emissions and fuel venting
| '''CS-34'''
|}

[[File:MiniBee_Medium_Level_System_Certification_Map.png|center|900px|Mini-Bee medium level certification map]]

<div style="text-align:center; font-size:90%; color:#555;">
'''Visual placeholder''' — System map linking each aircraft domain to its certification reference.
</div>

== Lift / thrust system ==

For Mini-Bee / Red VTOL, the key technical object is the complete '''lift / thrust system'''.

It must be considered as an integrated chain.

[[File:MiniBee_Lift_Thrust_System_Chain.png|center|900px|Mini-Bee lift thrust system chain]]

<div style="text-align:center; font-size:90%; color:#555;">
'''Visual placeholder''' — Fuel source → engine → generator → power electronics → motors → propellers → thrust.
</div>

<br />

{| class="wikitable" style="width:100%;"
! Chain element
! Certification attention
|-
| Energy source
| Safety, endurance, fuel venting.
|-
| Thermal engine
| CS-E and installation.
|-
| Electrical generation
| Reliability and degraded modes.
|-
| Power electronics
| Electrical safety and EMC.
|-
| Electric motors
| Redundancy and failure cases.
|-
| Propellers / rotors
| Loads, vibration, noise and safety.
|-
| Control logic
| Monitoring, command and degraded operation.
|}

== Low Level — evidence and demonstration ==

Certification is not based on intention.
It is based on documented evidence.

[[File:MiniBee_Low_Level_Evidence_Matrix.png|center|900px|Mini-Bee evidence matrix]]

<div style="text-align:center; font-size:90%; color:#555;">
'''Visual placeholder''' — Requirements linked to analyses, tests, inspections, simulations and demonstrations.
</div>

<br />

{| class="wikitable" style="width:100%; text-align:center;"
! Analysis
! Test
! Simulation
! Inspection
! Demonstration
|-
| Safety studies
| Bench tests
| HIL / SIL
| Installation checks
| Flight evidence
|}

== Certification risks ==

{| class="wikitable" style="width:100%;"
! Risk
! Design impact
|-
| '''CS-27 / SC-VTOL boundary'''
| The aircraft must remain clearly classifiable.
|-
| '''CS-29 drift'''
| Complexity may increase certification burden.
|-
| '''Hybrid propulsion'''
| The full chain may be safety-critical.
|-
| '''High electrical power'''
| EWIS, EMC and power distribution must be justified.
|-
| '''Distributed lift'''
| Failure cases and degraded modes must be demonstrated.
|-
| '''VEMS mission'''
| Medical or public service use may add operational constraints.
|}

== Certification pathway ==

[[File:MiniBee_Certification_Pathway.png|center|900px|Mini-Bee certification pathway]]

<div style="text-align:center; font-size:90%; color:#555;">
'''Visual placeholder''' — Concept → classification → system map → evidence → tests → operational approval.
</div>

== Key conclusions from the presentation ==

<div style="border-left:5px solid #1f4e79; padding:14px 18px; background:#f6f8fa; margin:18px 0;">

Mini-Bee / Red VTOL should currently be considered as a '''small rotorcraft with VTOL-capable characteristics'''.

The most credible certification logic is:

* '''CS-27''' as the small rotorcraft basis;
* '''SC-VTOL-02''' for VTOL-capable aspects;
* '''SC E-19''' for hybrid propulsion;
* '''CS-E''' and '''CS-P''' for engine and propulsive elements;
* additional references when operations, complexity or environmental aspects require them.

</div>

== Visuals to create ==

{| class="wikitable" style="width:100%;"
! File name
! Role
|-
| '''MiniBee_VTOL_Certification_Framework_Hero.png'''
| Hero image for the top of the page.
|-
| '''MiniBee_Certification_Three_Level_Logic.png'''
| Explain High / Medium / Low certification levels.
|-
| '''MiniBee_CS27_SCVTOL_Positioning.png'''
| Show the dual positioning of Mini-Bee.
|-
| '''MiniBee_EASA_Reference_Map.png'''
| Show the main EASA references.
|-
| '''MiniBee_Medium_Level_System_Certification_Map.png'''
| Link systems to certification references.
|-
| '''MiniBee_Lift_Thrust_System_Chain.png'''
| Show the full lift/thrust chain.
|-
| '''MiniBee_Low_Level_Evidence_Matrix.png'''
| Show compliance evidence.
|-
| '''MiniBee_Certification_Pathway.png'''
| Final certification roadmap visual.
|}

== Useful links ==

* [[File:20260422_RedVTOL_EASA_Certification_01_High_Level_Framework_v2_en.pptx|Download the PowerPoint presentation]]
* [[Mini-Bee]]
* [[Minibee_TRL3]]
* [[RED VTOL]]
* [[CS-27]]
* [[SC-VTOL-02]]
* [[Hybrid Propulsion]]

== See also ==

* [[Mini-Bee]]
* [[Bee-Plane]]
* [[Iso-Plane]]
* [[RED VTOL ONG]]

Certification FrameWork VTOL

2026-05-19T08:14:49Z

Wiki.admin:

= VTOL Certification Framework =

'''Mini-Bee / Red VTOL — EASA Certification Framework'''

The '''VTOL Certification Framework''' defines how a vertical take-off and landing aircraft can be designed, justified, tested and progressively accepted by the aviation authority.

For '''Mini-Bee / Red VTOL''', certification is not only a regulatory constraint.
It is a design driver.

The objective is to position the aircraft inside the EASA certification environment and to identify the main rules that will guide the future technical demonstration.

[[File:MiniBee_VTOL_Certification_Framework_Overview.png|thumb|center|900px|'''Mini-Bee / Red VTOL certification framework overview'''<br />Placeholder visual showing the aircraft, EASA, CS-27, SC-VTOL-02 and the certification pathway.]]

== Quick project summary ==

{| class="wikitable"
! Item
! Description
|-
| '''Project'''
| Mini-Bee / Red VTOL
|-
| '''Aircraft type'''
| 2PAX hybrid VTOL multicopter
|-
| '''Mission orientation'''
| Ultra-light air ambulance / VEMS concept
|-
| '''Certification topic'''
| EASA VTOL Certification Framework
|-
| '''Main aircraft basis'''
| CS-27 Small Rotorcraft
|-
| '''VTOL-specific basis'''
| SC-VTOL-02 Small-Category VTOL-Capable Aircraft
|-
| '''Key challenge'''
| Demonstrate that the aircraft can follow a credible path toward certification, safety and operational approval
|}

== Main presentation ==

The main document supporting this page is the PowerPoint presentation:

: '''Red VTOL TRL4 — 2PAX VTOL hybrid multicopter — Ultra light air ambulance — EASA Certification Framework'''

{| class="wikitable"
! Document
! Description
|-
| [[File:20260422_RedVTOL_EASA_Certification_01_High_Level_Framework_v2_en.pptx|Download the PowerPoint presentation]]
| High level certification framework for Mini-Bee / Red VTOL, including EASA references, CS-27, SC-VTOL-02, CS-VLR, CS-29, system and sub-system certification references, environmental topics, official links and glossary.
|}

[[File:MiniBee_EASA_Presentation_Extract.png|thumb|center|900px|'''Presentation overview'''<br />Placeholder visual to be created from the first slide or from a graphical synthesis of the PowerPoint.]]

== Visual introduction ==

<gallery mode="packed" heights="220px">
File:MiniBee_High_Level_Certification_Map.png|'''High level framework'''<br />CS-27, SC-VTOL-02, CS-29 and CS-VLR positioning.
File:MiniBee_Lift_Thrust_System_Chain.png|'''Lift / thrust system'''<br />Hybrid chain from energy source to distributed propellers.
File:MiniBee_Low_Level_Evidence_Matrix.png|'''Compliance evidence'''<br />Requirements, analyses, tests, inspections and demonstrations.
</gallery>

== Project overview ==

The Mini-Bee / Red VTOL concept is a hybrid VTOL aircraft project based on a distributed lift architecture.

From a certification point of view, the aircraft must be treated carefully because it is not a conventional helicopter and not a conventional aeroplane. It combines rotorcraft behaviour with VTOL-capable characteristics.

The current certification logic is therefore based on two main references:

* '''CS-27 Small Rotorcraft''' for the rotorcraft basis;
* '''SC-VTOL-02''' for VTOL-capable specific aspects.

This dual approach helps structure the project without ignoring the innovative features of the aircraft.

== High Level Certification Framework ==

The high level framework answers one main question:

: '''Where does Mini-Bee / Red VTOL fit inside the EASA certification environment?'''

The current positioning is:

{| class="wikitable"
! Reference
! Role
|-
| '''CS-27'''
| Main basis for small rotorcraft certification.
|-
| '''SC-VTOL-02'''
| Complementary framework for VTOL-capable characteristics.
|-
| '''CS-VLR'''
| Possible reference only if the aircraft fits very light rotorcraft restrictions.
|-
| '''CS-29'''
| Reference for complex rotorcraft aspects or if the design exits CS-27 boundaries.
|}

[[File:MiniBee_CS27_SCVTOL_Positioning.png|thumb|right|420px|'''Certification positioning'''<br />Mini-Bee between small rotorcraft logic and VTOL-capable aircraft logic.]]

At this level, the key point is to avoid a late reclassification risk.

A design initially considered under CS-27 may be pushed toward more demanding expectations if it exceeds boundaries related to mass, occupants, complexity, power architecture, operating mode or public transport use.

== EASA as official source ==

EASA is the official European authority for aviation safety and certification.

For Mini-Bee / Red VTOL, every certification reference must be checked from official EASA sources:

* certification specifications;
* special conditions;
* acceptable means of compliance;
* guidance material;
* rulemaking tasks;
* consultation documents;
* easy access rules;
* official FAQs and product lists.

This is important because certification work must rely on validated texts, with clear issue dates and amendment levels.

== Main EASA references ==

{| class="wikitable"
! Reference
! Main use for Mini-Bee / Red VTOL
|-
| '''CS-27'''
| Small rotorcraft certification basis.
|-
| '''SC-VTOL-02'''
| VTOL-capable aircraft specific requirements.
|-
| '''CS-VLR'''
| Very light rotorcraft reference, under strict limitations.
|-
| '''CS-29'''
| Large rotorcraft reference for complex or higher-category aspects.
|-
| '''CS-E'''
| Engine certification.
|-
| '''SC E-19'''
| Electric and hybrid propulsion system certification.
|-
| '''CS-P'''
| Propeller certification.
|-
| '''CS-26'''
| Additional airworthiness specifications for operations.
|-
| '''AMC-20'''
| Products, parts and appliances.
|-
| '''CS-34'''
| Aircraft engine emissions and fuel venting.
|}

== System and sub-system framework ==

The medium level framework links the aircraft-level certification basis to each major technical domain.

For Mini-Bee / Red VTOL, the most important domains are:

* thermal engine;
* electric and hybrid propulsion system;
* propellers or rotors;
* high-power electrical architecture;
* distributed lift system;
* operational airworthiness;
* emissions and fuel venting;
* noise and environmental constraints.

[[File:MiniBee_Medium_Level_System_Map.png|thumb|center|900px|'''System and sub-system certification map'''<br />Placeholder visual showing CS-E, SC E-19, CS-P, CS-26, AMC-20 and CS-34 around the Mini-Bee architecture.]]

The main technical point is the definition of the complete '''lift / thrust system'''.

For Mini-Bee, this system should include the complete chain:

{| class="wikitable"
! Chain element
! Certification attention point
|-
| Fuel / energy source
| Safety, storage, venting, endurance and environmental constraints.
|-
| Thermal engine
| CS-E, installation, operating limits and integration.
|-
| Electrical generation
| Power conversion, reliability and degraded modes.
|-
| Power electronics
| Thermal control, electrical safety and EMC.
|-
| Electric motors
| Redundancy, failure cases and thrust control.
|-
| Propellers / rotors
| CS-P, loads, vibration, safety and noise.
|-
| Flight control logic
| Command, monitoring, degraded modes and safety analysis.
|}

== Low Level demonstration ==

The low level framework is the level of evidence.

At this stage, the project must demonstrate that each requirement is satisfied through traceable proof.

Typical evidence includes:

* analyses;
* calculations;
* simulations;
* safety assessments;
* system schematics;
* bench tests;
* HIL / SIL tests;
* inspections;
* qualification reports;
* flight test preparation;
* flight test reports.

[[File:MiniBee_Low_Level_Evidence_Matrix.png|thumb|center|900px|'''Low level evidence matrix'''<br />Placeholder visual showing the link between requirements, means of compliance and project deliverables.]]

This level is essential because certification is not based on intention.
It is based on documented, verifiable and reviewable evidence.

== Main certification risks ==

{| class="wikitable"
! Risk
! Why it matters
|-
| '''Boundary between CS-27 and SC-VTOL'''
| Mini-Bee combines rotorcraft behaviour and VTOL-capable characteristics.
|-
| '''Possible move toward CS-29 expectations'''
| Complexity, mass, occupants or operations may increase the certification burden.
|-
| '''Hybrid propulsion'''
| The propulsion chain may need to be treated as an integrated safety-critical system.
|-
| '''High electrical power'''
| Electrical architecture, EWIS and EMC require specific attention.
|-
| '''Distributed lift'''
| Failure modes and degraded operation must be clearly demonstrated.
|-
| '''VEMS / medical mission'''
| Emergency medical use may introduce additional operational constraints.
|}

== Certification maturity logic ==

The certification framework for VTOL-capable aircraft is still evolving.

Mini-Bee / Red VTOL should therefore keep a living certification watch on:

* SC-VTOL updates;
* new means of compliance;
* EASA Rotorcraft and VTOL Safety Symposium outputs;
* electric and hybrid propulsion guidance;
* environmental rules;
* operational rules for VTOL-capable aircraft;
* pilot training and licensing evolutions.

This point is important for the transition toward a stronger demonstrator phase.

== What the presentation clarified ==

The PowerPoint presentation clarified several key points:

{| class="wikitable"
! Topic
! Clarification
|-
| '''Aircraft classification'''
| Mini-Bee can be considered as a small rotorcraft with VTOL-capable characteristics.
|-
| '''Main certification basis'''
| CS-27 should be used as the main rotorcraft basis.
|-
| '''VTOL complement'''
| SC-VTOL-02 is needed for specific VTOL-capable features.
|-
| '''System certification'''
| Engine, hybrid propulsion, propellers and electrical systems require dedicated references.
|-
| '''Design risk'''
| The project must avoid unintentionally exiting the CS-27 frame.
|-
| '''Future work'''
| Each certification text must be analysed in detail to deduce constraints and design options.
|}

== Questions to solve before a future certification phase ==

Before moving toward a more advanced certification phase, several questions must be clarified:

* What is the final certified mass target?
* What is the final occupant configuration?
* Which parts of the hybrid propulsion chain can rely on certified components?
* How should the integrated lift / thrust system be demonstrated?
* Which degraded modes must be demonstrated?
* What operational category should be targeted?
* How far should the VEMS mission be included in the first certification logic?
* Which EASA discussions or consultations should the project enter?

== Suggested visuals to create ==

{| class="wikitable"
! Visual
! Purpose
|-
| '''MiniBee_VTOL_Certification_Framework_Overview.png'''
| Global cover visual for the page.
|-
| '''MiniBee_High_Level_Certification_Map.png'''
| Show CS-27, SC-VTOL-02, CS-29 and CS-VLR around Mini-Bee.
|-
| '''MiniBee_CS27_SCVTOL_Positioning.png'''
| Explain the dual positioning: rotorcraft basis + VTOL-capable complement.
|-
| '''MiniBee_Lift_Thrust_System_Chain.png'''
| Show the complete hybrid chain from fuel to propellers.
|-
| '''MiniBee_Medium_Level_System_Map.png'''
| Map systems and sub-systems to certification references.
|-
| '''MiniBee_Low_Level_Evidence_Matrix.png'''
| Show requirements linked to evidence and means of compliance.
|-
| '''MiniBee_Certification_Pathway.png'''
| Final synthesis visual: concept → framework → compliance → tests → approval.
|}

== Useful links ==

* [[File:20260422_RedVTOL_EASA_Certification_01_High_Level_Framework_v2_en.pptx|Download the PowerPoint presentation]]
* [[Mini-Bee]]
* [[Minibee_TRL3]]
* [[RED VTOL]]
* [[CS-27]]
* [[SC-VTOL-02]]
* [[Hybrid Propulsion]]

== Why this framework matters ==

The VTOL Certification Framework is essential because Mini-Bee / Red VTOL cannot be assessed only through performance or innovation.

The aircraft must also be understandable, justifiable and demonstrable from a certification point of view.

This framework helps the project move from an innovative VTOL concept toward a structured, traceable and credible aircraft development path.

[[File:MiniBee_Certification_Pathway.png|thumb|center|900px|'''Mini-Bee certification pathway'''<br />Placeholder visual showing the progression from concept definition to certification evidence and operational approval.]]

Certification FrameWork VTOL

2026-05-19T08:12:29Z

Wiki.admin:

= VTOL Certification Framework =

[[File:20260422_RedVTOL_EASA_Certification_01_High_Level_Framework_v2_en.pptx|thumb|center|900px|'''Download the full presentation''' — Red VTOL / Mini-Bee EASA Certification Framework]]

The '''VTOL Certification Framework''' defines how a vertical take-off and landing aircraft can be designed, justified, tested, and accepted by the aviation authority.

For a project such as '''Mini-Bee / Red VTOL''', certification is not only a regulatory topic. It is a design driver. The aircraft must not only fly. It must also follow a credible path toward safety demonstration, technical compliance, and operational approval.

In Europe, this framework is based on '''EASA''' — the European Union Aviation Safety Agency. EASA provides the official certification specifications, special conditions, acceptable means of compliance, guidance material, and rulemaking documents used for aircraft certification.

[[File:MiniBee_VTOL_Certification_Framework_Overview.png|thumb|center|900px|'''Figure 1.''' Overview of the Mini-Bee / Red VTOL certification framework.]]

== Objective ==

The objective of this page is to summarize the certification logic presented in the document:

'''Red VTOL TRL4 — 2PAX VTOL hybrid multicopter — Ultra light air ambulance — EASA Certification Framework'''

The presentation identifies the main regulatory references that may apply to Mini-Bee / Red VTOL and explains how the project can be positioned inside the EASA certification environment.

The main objectives are:

* define the certification framework of the concept;
* identify the main texts that orient the design;
* anticipate the certification process;
* analyse the maturity of the VTOL-capable aircraft regulation;
* prepare future technical demonstration and compliance activities.

== High Level Certification Framework ==

At high level, the main question is:

: '''Where does Mini-Bee / Red VTOL fit inside the EASA certification framework?'''

The current logic is to consider Mini-Bee as:

* a '''small rotorcraft''' under '''CS-27''';
* with '''VTOL-capable characteristics''' under '''SC-VTOL-02'''.

This means that the design should be oriented around both references:

* '''CS-27 Small Rotorcraft''';
* '''SC-VTOL-02 Small-Category VTOL-Capable Aircraft'''.

CS-27 provides the rotorcraft basis.
SC-VTOL-02 adds the specific requirements linked to VTOL-capable aircraft, distributed lift, hybrid propulsion, high electrical power, and lift/thrust system safety.

[[File:MiniBee_High_Level_Certification_Map.png|thumb|center|900px|'''Figure 2.''' High level certification positioning: CS-27, SC-VTOL-02, CS-29 and CS-VLR.]]

== Main EASA references ==

The presentation identifies several EASA references that structure the certification approach.

{| class="wikitable"
! Reference
! Role for Mini-Bee / Red VTOL
|-
| '''CS-27'''
| Main basis for small rotorcraft certification.
|-
| '''SC-VTOL-02'''
| Special condition for small VTOL-capable aircraft.
|-
| '''CS-VLR'''
| Possible reference for very light rotorcraft, only if the design fits its restrictions.
|-
| '''CS-29'''
| Reference for large rotorcraft and complex design aspects.
|-
| '''CS-E'''
| Certification specifications for engines.
|-
| '''SC E-19'''
| Special condition for electric and hybrid propulsion systems.
|-
| '''CS-P'''
| Certification specifications for propellers.
|-
| '''CS-26'''
| Additional airworthiness specifications for operations.
|-
| '''AMC-20'''
| Acceptable means of compliance for products, parts and appliances.
|-
| '''CS-34'''
| Aircraft engine emissions and fuel venting.
|}

== System and Sub-System Certification Framework ==

The medium level of the framework concerns the main systems and sub-systems of the aircraft.

For Mini-Bee / Red VTOL, this includes:

* the engine;
* the electric or hybrid propulsion system;
* the propellers or rotors;
* the high-power electrical architecture;
* the lift/thrust chain;
* operational airworthiness topics;
* emissions and environmental constraints.

The key point is that Mini-Bee cannot be certified only as a set of separate components.
The complete '''lift/thrust system''' must be considered as an integrated chain.

This chain includes:

* energy source;
* thermal engine;
* electrical generation;
* power electronics;
* electric motors;
* distributed propellers or rotors;
* control logic;
* failure modes and degraded operation.

[[File:MiniBee_Lift_Thrust_System_Chain.png|thumb|center|900px|'''Figure 3.''' Placeholder visual: complete Mini-Bee lift/thrust chain.]]

== Low Level Demonstration ==

The low level corresponds to the concrete demonstration of compliance.

At this stage, the project must produce technical evidence. Each requirement must be linked to a means of compliance.

Typical evidence may include:

* analyses;
* calculations;
* safety studies;
* system schematics;
* simulations;
* bench tests;
* HIL / SIL tests;
* inspection procedures;
* flight test preparation;
* test reports.

This level is essential because certification is not based only on a concept. It is based on traceable proof.

[[File:MiniBee_Low_Level_Evidence_Matrix.png|thumb|center|900px|'''Figure 4.''' Placeholder visual: requirements linked to analyses, tests, inspections and demonstrations.]]

== Key certification risks ==

The main risks identified for Mini-Bee / Red VTOL are:

* unclear boundary between rotorcraft and VTOL-capable aircraft;
* possible movement from CS-27 toward CS-29 if the design becomes too complex;
* certification of the hybrid propulsion system;
* high electrical power requirements;
* distributed lift safety demonstration;
* lack of mature means of compliance for some VTOL technologies;
* operational requirements linked to air ambulance or public service missions.

These risks do not block the project. They define the topics that must be treated early in the design process.

== Conclusion ==

Mini-Bee / Red VTOL should currently be considered as a '''small rotorcraft with VTOL-capable characteristics'''.

The most credible certification logic is therefore based on:

* '''CS-27''' as the small rotorcraft basis;
* '''SC-VTOL-02''' for the VTOL-capable specific aspects;
* '''SC E-19''' for hybrid propulsion;
* additional references such as CS-E, CS-P, CS-26, AMC-20, CS-34, CS-VLR and CS-29 when relevant.

The certification framework is not only a compliance checklist.
It is a design management tool.

It helps structure the project, identify design constraints, prepare evidence, and build a credible path toward future certification.

[[File:MiniBee_Certification_Pathway.png|thumb|center|900px|'''Figure 5.''' Placeholder visual: Mini-Bee certification pathway from concept to compliance demonstration.]]

== Download ==

* [[File:20260422_RedVTOL_EASA_Certification_01_High_Level_Framework_v2_en.pptx|Download the full PowerPoint presentation]]

== See also ==

* [[Mini-Bee]]
* [[Minibee_TRL3]]
* [[RED VTOL ONG]]

Certification FrameWork VTOL

2026-05-19T07:36:41Z

Wiki.admin:

= VTOL Certification Framework for Mini-Bee / Red VTOL =

[[File:MiniBee_VTOL_Certification_Framework_Cover.png|thumb|center|900px|'''Figure 1.''' Mini-Bee / Red VTOL certification framework overview. Placeholder for a visual showing the aircraft, the EASA framework, and the High / Medium / Low certification logic.]]

The '''VTOL Certification Framework''' is the regulatory and technical structure that defines how a vertical take-off and landing aircraft can be designed, justified, tested, and accepted by the aviation authority.

For a project such as '''Mini-Bee / Red VTOL''', certification is not a secondary topic. It is a central part of the design logic. The objective is not only to build an innovative hybrid VTOL aircraft, but also to demonstrate that the concept can follow a credible path toward certification, safety, and operational approval.

In Europe, this framework is based on '''EASA''' — the European Union Aviation Safety Agency. EASA publishes the official certification specifications, special conditions, acceptable means of compliance, guidance material, and rulemaking documents used as the basis for certification demonstration.

The Mini-Bee / Red VTOL concept is currently positioned as a '''small rotorcraft''' under '''CS-27''', complemented by '''SC-VTOL-02''' for its VTOL-capable characteristics. This combination is essential because the aircraft behaves partly like a rotorcraft, while also introducing specific VTOL features such as distributed lift, hybrid propulsion, high-power electrical architecture, and a complex lift/thrust chain.

== Objective of the certification framework ==

The objective of this certification framework is to:

* define the regulatory environment in which the Mini-Bee / Red VTOL concept is included;
* identify the main certification texts that orient the aircraft design;
* anticipate the future certification process;
* analyse the maturity of the regulation, especially for VTOL-capable aircraft;
* identify potential gaps, uncertainties, and areas requiring further authority interaction;
* transform the aircraft concept into a certifiable engineering project.

This framework is also a design enabler. It helps discover associated technologies, technical constraints, and certification orientations that can make the Mini-Bee / Red VTOL concept more coherent with market expectations and aviation safety requirements.

[[File:MiniBee_Certification_Objectives.png|thumb|center|900px|'''Figure 2.''' Certification framework objectives: classification, applicable rules, maturity analysis, and evidence preparation.]]

== High Level Certification Framework ==

The '''High Level Certification Framework''' corresponds to the strategic level of the certification approach.

At this level, the question is:

: '''Where should Mini-Bee / Red VTOL be classified within the EASA certification framework?'''

The answer defines the aircraft category, the main certification basis, the complementary certification references, and the regulatory philosophy that will guide the design.

For Mini-Bee / Red VTOL, the current logic is:

* '''CS-27 Small Rotorcraft''' as the main certification basis;
* '''SC-VTOL-02 Small-Category VTOL-Capable Aircraft''' as a complementary framework for VTOL-specific features;
* '''CS-29 Large Rotorcraft''' as a possible reference for design drivers, especially where system complexity or operational use goes beyond CS-27;
* '''CS-VLR Very Light Rotorcraft''' as a possible reference only if the aircraft design fits its restrictive conditions;
* selected '''AMC''', '''GM''', '''RMT''', '''NPA''', and consultation documents as supporting material.

[[File:MiniBee_High_Level_Certification_Map.png|thumb|center|900px|'''Figure 3.''' High Level certification map showing CS-27, SC-VTOL-02, CS-29, and CS-VLR around the Mini-Bee concept.]]

=== EASA as the official reference ===

EASA is the official European authority for aviation safety and certification. Any certification basis used for Mini-Bee / Red VTOL must be traced to an official EASA source.

This point is important because certification cannot be built on informal interpretations or outdated documents. Each text used as a reference should be checked for:

* official EASA origin;
* issue number;
* amendment number;
* publication date;
* current validity;
* associated AMC or GM;
* relationship with other certification specifications.

For Mini-Bee / Red VTOL, the EASA Pro environment is the main access point for official certification material, including certification specifications, special conditions, rulemaking tasks, easy access rules, and consultation documents.

== Main certification positioning of Mini-Bee ==

Mini-Bee / Red VTOL is currently considered as:

: '''a small rotorcraft under CS-27, with VTOL-capable characteristics under SC-VTOL-02.'''

This means that the design should comply with both:

* '''CS-27 Small Rotorcraft''';
* '''SC-VTOL-02 Small-Category VTOL-Capable Aircraft'''.

This dual positioning is one of the key points of the certification strategy.

CS-27 provides the rotorcraft basis.
SC-VTOL-02 provides the additional logic for the VTOL-capable aspects that are not fully covered by conventional rotorcraft rules.

[[File:MiniBee_CS27_SCVTOL_Positioning.png|thumb|right|450px|'''Figure 4.''' Proposed visual: Mini-Bee positioned between small rotorcraft logic and VTOL-capable aircraft logic.]]

== SC-VTOL-02 Small-Category VTOL-Capable Aircraft ==

'''SC-VTOL-02''' is a special condition for small-category VTOL-capable aircraft.

It addresses aircraft that are able to take off and land vertically but differ from conventional rotorcraft or fixed-wing aircraft. This point is central for Mini-Bee / Red VTOL because the aircraft uses a non-conventional architecture, with distributed propulsion and a hybrid lift/thrust chain.

The main SC-VTOL-02 topics relevant to Mini-Bee include:

* VTOL-capable aircraft classification;
* safety analysis;
* single failure prevention;
* weight and occupant limits;
* lift/thrust system definition;
* flight and safety recorders;
* high electrical power;
* EWIS considerations;
* interaction between propulsion, lift, thrust, and control systems.

For Mini-Bee, the complete hybrid chain must be considered as part of the '''lift/thrust system'''. This means that the certification logic must not only cover the propellers or rotors, but the full chain from energy storage and generation to the final thrust-producing elements.

This includes, for example:

* fuel reservoir;
* thermal engine;
* generator or alternator;
* power electronics;
* electrical distribution;
* electric motors;
* rotors or propellers;
* control logic;
* degraded modes;
* safety monitoring.

[[File:MiniBee_Lift_Thrust_System_Chain.png|thumb|center|900px|'''Figure 5.''' Placeholder for a visual showing the complete Mini-Bee lift/thrust chain from energy source to distributed propellers.]]

== CS-27 Small Rotorcraft ==

'''CS-27''' is the Certification Specification for Small Rotorcraft.

For Mini-Bee / Red VTOL, CS-27 is used because the aircraft behaves, from a certification standpoint, like a small rotorcraft. The presence of multiple propellers or rotors does not automatically remove the aircraft from rotorcraft logic. Instead, the general behaviour, flight control logic, lift generation, and operational philosophy remain close to rotorcraft certification principles.

CS-27 provides requirements and acceptable means of compliance for small rotorcraft, including topics such as:

* structural design;
* flight characteristics;
* controllability;
* performance;
* powerplant installation;
* equipment;
* operating limitations;
* safety and airworthiness.

For Mini-Bee, CS-27 is therefore the baseline certification frame. However, because Mini-Bee includes VTOL-capable and hybrid propulsion features, CS-27 must be complemented by additional references.

== CS-VLR Very Light Rotorcraft ==

'''CS-VLR''' applies to very light rotorcraft.

It may be useful as a reference only if the design enters its restrictive frame. Typical CS-VLR logic is associated with simple rotorcraft, very limited occupancy, and restricted operations.

For Mini-Bee / Red VTOL, CS-VLR may provide useful insights, but it should not be assumed as the main basis unless the aircraft fully matches its constraints.

CS-VLR is relevant mainly as a comparison tool for:

* simplicity of design;
* very light rotorcraft logic;
* low occupant count;
* restricted operations;
* possible design simplification.

== CS-29 Large Rotorcraft ==

'''CS-29''' applies to large rotorcraft.

Mini-Bee is not primarily positioned as a CS-29 aircraft. However, CS-29 remains important as a reference because some design characteristics can push a project toward higher certification expectations.

This may happen if the aircraft design includes:

* higher weight;
* higher occupant capacity;
* complex systems;
* multi-engine or complex power architecture;
* public transport operations;
* night operations;
* operations over water;
* advanced equipment;
* human factors requirements;
* safety requirements beyond the CS-27 baseline.

A candidate design under CS-27 may be required to comply with selected CS-29 specifications if some features exceed the boundaries of CS-27.

This is a major risk to be considered early in the design.

[[File:MiniBee_CS27_CS29_Boundary_Risk.png|thumb|center|900px|'''Figure 6.''' Placeholder for a visual showing the risk of moving from CS-27 logic toward CS-29 expectations when design complexity increases.]]

== Conclusion of the High Level framework ==

At High Level, Mini-Bee / Red VTOL should be treated as:

* a '''small rotorcraft''' under CS-27;
* a '''VTOL-capable aircraft''' under SC-VTOL-02;
* a concept that may need selected CS-29 considerations if complexity, operations, or configuration exceed CS-27 expectations;
* a design that should only rely on CS-VLR if it fully fits the very light rotorcraft frame.

The main conclusion is that Mini-Bee must be designed with certification boundaries in mind from the beginning.

Only one non-compliant characteristic may be enough to move the aircraft into a higher or more demanding category. This may relate to mass, number of occupants, propulsion complexity, electrical architecture, operational use, or safety assumptions.

== Medium Level Certification Framework ==

The '''Medium Level Certification Framework''' corresponds to the system and sub-system certification architecture.

At this level, the question changes:

: '''Which certification texts apply to each technical domain of the aircraft?'''

The aircraft-level framework must be translated into system-level references. This is where the broad certification strategy becomes a practical engineering map.

For Mini-Bee / Red VTOL, the main system and sub-system references include:

* '''CS-E''' for engines;
* '''SC E-19''' for electric and hybrid propulsion systems;
* '''CS-P''' for propellers;
* '''CS-26''' for additional airworthiness specifications for operations;
* '''AMC-20''' for products, parts, and appliances;
* '''CS-34''' for aircraft engine emissions and fuel venting;
* '''CS-36''' for aircraft noise where applicable;
* '''CS-CO2''' for CO2 aspects where applicable;
* selected EASA Certification Memoranda and consultation material.

[[File:MiniBee_Medium_Level_System_Map.png|thumb|center|900px|'''Figure 7.''' Medium Level certification map: engine, hybrid propulsion, propellers, electrical system, operations, emissions, and environmental references.]]

== CS-E Engines ==

'''CS-E''' defines certification specifications and acceptable means of compliance for engines.

For Mini-Bee / Red VTOL, the thermal engine is part of the complete lift/thrust chain. It is therefore not only an isolated component. Its certification status, integration, operating limitations, failure modes, and interaction with the hybrid electrical system must be considered.

A certified aeronautical engine may reduce certification effort, provided that:

* the engine is used within its certified operating envelope;
* installation effects are properly justified;
* cooling, fuel, vibration, and control interfaces are demonstrated;
* the integration with the hybrid chain does not create unaddressed risks.

If a non-certified or significantly modified engine is used, the certification burden becomes much higher.

For Mini-Bee, the engine must be analysed in relation with:

* CS-E;
* SC E-19;
* SC-VTOL-02;
* CS-34;
* the full lift/thrust system logic.

== SC E-19 Electric / Hybrid Propulsion System ==

'''SC E-19''' is the special condition addressing electric and hybrid propulsion systems.

It is highly relevant for Mini-Bee / Red VTOL because the aircraft concept includes a hybrid propulsion architecture. SC E-19 provides a structured certification reference for systems that combine energy conversion, electrical power, control, and propulsion functions.

The key point is that the certification approach may consider the hybrid propulsion either as:

* an aircraft-level integrated system;
* an engine-like certification object;
* a set of interacting certified and non-certified components;
* or a dedicated system requiring its own means of compliance.

For Mini-Bee, this creates a major design question:

: '''Should the hybrid propulsion system be treated as a set of components, or as one integrated lift/thrust system?'''

From a safety perspective, the integrated-system approach appears more coherent because failures may propagate through electrical, mechanical, thermal, and control interfaces.

[[File:MiniBee_Electric_Hybrid_Propulsion_Certification.png|thumb|center|900px|'''Figure 8.''' Placeholder for a visual showing SC E-19 applied to the Mini-Bee hybrid propulsion architecture.]]

== CS-P Propellers ==

'''CS-P''' defines certification specifications and acceptable means of compliance for propellers.

For Mini-Bee / Red VTOL, propellers or rotors are part of the lift/thrust system. Their certification cannot be isolated from the aircraft architecture because they interact with:

* distributed lift;
* propulsion control;
* structural loads;
* vibration;
* redundancy;
* failure modes;
* noise;
* safety around rotating elements;
* energy management.

If certified propellers are available and compatible with the Mini-Bee design, their use may reduce certification uncertainty. If custom propellers are required, additional design justification and testing will be necessary.

== CS-26 Additional airworthiness specifications for operations ==

'''CS-26''' provides additional airworthiness specifications linked to certain operational conditions.

For Mini-Bee / Red VTOL, CS-26 may become relevant depending on the intended operational use, especially for:

* public transport;
* emergency medical service;
* water impact and ditching considerations;
* emergency equipment;
* fire extinguishers;
* operational safety requirements.

This is important because Mini-Bee / Red VTOL is associated with an ultra-light air ambulance concept. If the aircraft is intended for medical aid or public service missions, the operational certification expectations may become more demanding than a basic demonstrator configuration.

== AMC-20 Products, Parts and Appliances ==

'''AMC-20''' provides general acceptable means of compliance for airworthiness of products, parts, and appliances.

For Mini-Bee, AMC-20 is useful because it creates bridges between certification references. It helps connect product-level airworthiness with system-level and equipment-level certification expectations.

AMC-20 should be used as a supporting reference, especially for:

* equipment qualification;
* system installation;
* environmental qualification;
* electrical and electronic equipment;
* interfaces between certification domains;
* means of compliance selection.

== CS-34, CS-36 and CS-CO2 environmental references ==

'''CS-34''' relates to aircraft engine emissions and fuel venting.
'''CS-36''' relates to aircraft noise.
'''CS-CO2''' relates to aircraft CO2 emissions where applicable.

For Mini-Bee / Red VTOL, environmental certification cannot be ignored. Even if the aircraft is small and hybrid, the use of a thermal engine, fuel system, and propulsive elements creates environmental compliance questions.

The key topics include:

* fuel venting;
* engine emissions;
* noise;
* environmental protection;
* possible future evolution of CO2-related requirements;
* alignment with ICAO Annex 16 principles.

Mini-Bee should therefore monitor future evolutions of these requirements, especially because hybrid aircraft and new air mobility vehicles may be subject to evolving environmental expectations.

[[File:MiniBee_Environmental_Certification_Map.png|thumb|right|450px|'''Figure 9.''' Placeholder for a visual showing environmental certification links: CS-34, CS-36, CS-CO2, fuel, emissions, and noise.]]

== Low Level Certification Framework ==

The '''Low Level Certification Framework''' is the level of concrete demonstration.

At this level, the question becomes:

: '''Which evidence proves that each requirement is satisfied?'''

This is where the project moves from regulatory interpretation to engineering proof.

For Mini-Bee / Red VTOL, Low Level certification work should include:

* requirement allocation;
* requirement traceability;
* design assumptions;
* safety analyses;
* functional hazard assessment;
* system safety assessment;
* architecture justification;
* schematics;
* material files;
* control logic description;
* bench tests;
* simulation reports;
* HIL and SIL validation;
* electrical safety evidence;
* EWIS analysis;
* electromagnetic compatibility assessment;
* mechanical tests;
* environmental tests;
* inspection procedures;
* flight test preparation;
* flight test reports;
* degraded mode demonstrations.

[[File:MiniBee_Low_Level_Evidence_Matrix.png|thumb|center|900px|'''Figure 10.''' Placeholder for a Low Level evidence matrix linking requirements to analysis, test, inspection, simulation, and demonstration.]]

The Low Level is essential because certification is not granted on the basis of concept quality alone. It requires traceable and verifiable evidence.

Each requirement must be connected to a means of compliance, such as:

* analysis;
* calculation;
* test;
* inspection;
* demonstration;
* similarity;
* simulation;
* qualification;
* operational limitation.

== Flight test and DOARI considerations ==

The presentation refers to '''DOARI 2021-01 Consultation''' regarding the competence of flight test crew involved in VTOL flight test activities.

This document is no longer valid and should only be considered for its principles. However, it remains useful to understand the type of questions raised by VTOL flight testing.

The main principles retained for Mini-Bee / Red VTOL are:

* flight test operations must be prepared early;
* the aircraft should be designed to fit the certification frame as much as possible;
* VTOL-capable aircraft may be assimilated to CS-27 rotorcraft for technical specifications;
* handling qualities, controls, and performances should remain coherent with rotorcraft expectations;
* pilot licensing and training considerations must influence design philosophy;
* the project should avoid creating unnecessary gaps with existing flight crew categories.

This means that certification thinking must influence not only the aircraft hardware, but also the way the aircraft is controlled, tested, trained, and operated.

== Parachute and recovery systems ==

The presentation also highlights the question of parachutes and recovery systems.

EASA FAQ material indicates that personnel parachutes within the scope of EASA are mainly emergency parachutes for glider and aerobatic pilots, while other parachute types may fall under Member State responsibility.

For Mini-Bee / Red VTOL, this means that a parachute or ballistic recovery system should not automatically be assumed as an accepted means of compliance for a lift/thrust failure.

This point requires further analysis.

A recovery system may be useful from a safety perspective, but it must be demonstrated within the applicable certification framework. It cannot replace the need to show robustness of the lift/thrust system, degraded modes, redundancy, and controllability.

[[File:MiniBee_Recovery_System_Certification_Question.png|thumb|center|900px|'''Figure 11.''' Placeholder for a visual showing the certification question around parachute or recovery systems for VTOL aircraft.]]

== Rulemaking maturity and VTOL evolution ==

The certification framework for VTOL-capable aircraft is still evolving.

EASA symposiums, rulemaking tasks, notices of proposed amendment, and consultation documents show that the authority is progressively building the certification approach for new air mobility and VTOL-capable aircraft.

Important evolution topics include:

* VTOL means of compliance;
* human factors;
* flight envelopes;
* energy reserve;
* ditching and emergency flotation;
* doors and landing gear;
* design loads;
* structural durability;
* fire protection;
* U-space;
* artificial intelligence;
* pilot training;
* licensing;
* integration into air transport operations.

For Mini-Bee / Red VTOL, this means that the certification framework should be treated as a living reference. The design should remain adaptable to future updates of SC-VTOL, AMC, GM, and related EASA material.

== Air transport and VEMS use case ==

Mini-Bee / Red VTOL is linked to the concept of an ultra-light air ambulance.

The EASA material on air transport by VTOL-capable aircraft identifies several possible use cases, including:

* urban passenger services;
* regional passenger services;
* VEMS services;
* sightseeing flights.

For Mini-Bee, the VEMS angle is particularly relevant. However, medical aid missions can introduce additional constraints because they may involve:

* public service operations;
* patient transport;
* specific equipment;
* reliability requirements;
* mission availability;
* emergency landing considerations;
* operational approval;
* crew training;
* safety procedures.

The certification framework must therefore remain connected to the intended mission of the aircraft.

[[File:MiniBee_VEMS_Mission_Certification.png|thumb|center|900px|'''Figure 12.''' Placeholder for a visual showing Mini-Bee as a VTOL emergency medical service concept within certification constraints.]]

== Summary table ==

{| class="wikitable"
! Level
! Purpose
! Main question
! Main references
! Output
|-
| '''High Level'''
| Define the certification positioning
| Which aircraft category and framework apply?
| CS-27, SC-VTOL-02, CS-29, CS-VLR
| Certification basis and philosophy
|-
| '''Medium Level'''
| Map system and sub-system requirements
| Which rules apply to each technical domain?
| CS-E, SC E-19, CS-P, CS-26, AMC-20, CS-34
| System certification architecture
|-
| '''Low Level'''
| Produce compliance evidence
| Which proof demonstrates compliance?
| AMC, GM, tests, analysis, simulations, inspections
| Traceable evidence files
|}

== Main certification risks ==

The main certification risks for Mini-Bee / Red VTOL are:

* unclear boundary between rotorcraft and VTOL-capable aircraft;
* design moving outside CS-27 assumptions;
* hybrid propulsion treated as an integrated safety-critical system;
* high-power electrical architecture requiring specific evidence;
* distributed lift creating complex failure cases;
* lack of accepted means of compliance for some innovative features;
* operational use leading to additional requirements;
* environmental and noise requirements evolving before certification;
* flight test and licensing assumptions not aligned with existing categories.

These risks do not block the project. They define the areas where early engineering discipline is required.

== Conclusion ==

Mini-Bee / Red VTOL should currently be considered as a '''small rotorcraft with VTOL-capable characteristics'''.

Its design should therefore comply with '''CS-27''' as the main rotorcraft basis and '''SC-VTOL-02''' for the specific VTOL-capable aspects. Additional references such as CS-29, CS-VLR, CS-E, SC E-19, CS-P, CS-26, AMC-20, and CS-34 must be used to structure the system-level and sub-system-level certification approach.

The most important point is that certification must be integrated into the design process from the beginning.

For Mini-Bee / Red VTOL, the certification framework is not only a regulatory checklist. It is a design management tool. It helps define the aircraft category, orient technical decisions, identify missing evidence, manage risks, prepare authority discussions, and progressively transform an innovative VTOL concept into a certifiable aircraft project.

[[File:MiniBee_Certification_Pathway.png|thumb|center|900px|'''Figure 13.''' Placeholder for a final pathway visual: from concept to certification basis, system compliance map, evidence matrix, testing, and operational approval.]]

== Glossary ==

{| class="wikitable"
! Acronym
! Meaning
|-
| AC
| Advisory Circular
|-
| AMC
| Acceptable Means of Compliance
|-
| ATS
| Air Traffic Service
|-
| CAEP
| Committee on Aviation Environmental Protection
|-
| CM
| Certification Memorandum
|-
| CS
| Certification Specifications
|-
| DOA
| Design Organisation Approval
|-
| DOARI
| DOA Review Item
|-
| EASA
| European Union Aviation Safety Agency
|-
| ED
| EASA Decision
|-
| EHPS
| Electric / Hybrid Propulsion System
|-
| ETSO
| European Technical Standard Order
|-
| EWIS
| Electrical Wiring Interconnection System
|-
| FAA
| Federal Aviation Administration
|-
| GM
| Guidance Material
|-
| ICAO
| International Civil Aviation Organization
|-
| MoC
| Means of Compliance
|-
| NAM
| New Air Mobility
|-
| NPA
| Notice of Proposed Amendment
|-
| PAX
| Passenger
|-
| RMT
| Rulemaking Task
|-
| SARP
| Standards and Recommended Practices
|-
| SC
| Special Condition
|-
| TCDS
| Type Certificate Data Sheet
|-
| TLD
| Time Limited Dispatch
|-
| ToR
| Terms of Reference
|-
| TRL
| Technology Readiness Level
|-
| VEMS
| VTOL Emergency Medical Service
|-
| VLR
| Very Light Rotorcraft
|-
| VTOL
| Vertical Take-Off and Landing
|-
| WG
| Working Group
|}

== Suggested visuals to create ==

The following visuals can be created later and inserted into the page:

{| class="wikitable"
! File name
! Purpose
! Suggested content
|-
| MiniBee_VTOL_Certification_Framework_Cover.png
| Cover visual
| Mini-Bee aircraft, EASA framework, certification pathway
|-
| MiniBee_Certification_Objectives.png
| Explain the page objective
| Classification, rules, maturity, evidence
|-
| MiniBee_High_Level_Certification_Map.png
| High Level view
| CS-27, SC-VTOL-02, CS-29, CS-VLR around Mini-Bee
|-
| MiniBee_CS27_SCVTOL_Positioning.png
| Aircraft positioning
| Mini-Bee between rotorcraft and VTOL-capable categories
|-
| MiniBee_Lift_Thrust_System_Chain.png
| Technical chain
| Fuel, engine, generator, power electronics, motors, propellers
|-
| MiniBee_CS27_CS29_Boundary_Risk.png
| Certification risk
| Design features that may push toward CS-29
|-
| MiniBee_Medium_Level_System_Map.png
| Medium Level view
| System/sub-system certification map
|-
| MiniBee_Electric_Hybrid_Propulsion_Certification.png
| Hybrid propulsion
| SC E-19 applied to Mini-Bee
|-
| MiniBee_Environmental_Certification_Map.png
| Environmental references
| CS-34, CS-36, CS-CO2
|-
| MiniBee_Low_Level_Evidence_Matrix.png
| Low Level view
| Requirements linked to tests, analysis, inspection, simulation
|-
| MiniBee_Recovery_System_Certification_Question.png
| Safety recovery question
| Parachute / recovery system versus certification evidence
|-
| MiniBee_VEMS_Mission_Certification.png
| Mission use case
| Mini-Bee as VTOL emergency medical service aircraft
|-
| MiniBee_Certification_Pathway.png
| Final synthesis
| Concept → certification basis → compliance map → evidence → testing
|}

== See also ==

* [[Mini-Bee]]
* [[Minibee_TRL3]]
* [[RED VTOL]]
* [[EASA]]
* [[CS-27]]
* [[SC-VTOL-02]]
* [[Hybrid Propulsion]]
* [[VTOL Emergency Medical Service]]

Certification FrameWork VTOL

2026-05-19T07:29:38Z

Wiki.admin:

= VTOL Certification Framework =

The '''VTOL Certification Framework''' is the regulatory and technical structure that defines how a vertical take-off and landing aircraft can be designed, justified, tested, and accepted by the aviation authority.

For a project such as '''Mini-Bee''', certification is not a secondary topic. It is a central part of the design logic. The challenge is not only to build an innovative VTOL aircraft, but also to demonstrate that the concept can follow a credible path toward certification, safety, and operational approval.

In Europe, this framework is built around '''EASA''' (European Union Aviation Safety Agency), which publishes the official certification rules, certification specifications, acceptable means of compliance, and guidance material used as the basis for demonstration.

[[File:VTOL_Certification_Framework_Overview.png|thumb|center|900px|'''Figure 1.''' Global overview of the VTOL Certification Framework for Mini-Bee, from regulatory classification to technical demonstration.]]

In practical terms, a VTOL Certification Framework answers three essential questions:

* '''Which category does the aircraft belong to?'''
* '''Which rules apply to its systems and sub-systems?'''
* '''Which evidence must be produced to demonstrate compliance?'''

For '''Mini-Bee''', the selected logic is based on '''CS-27''' for the small rotorcraft framework, complemented by '''SC-VTOL-02''' to address the specific features of a VTOL-capable aircraft, especially distributed lift, the hybrid thrust chain, the high-power electrical architecture, and the associated safety constraints.

== High Level ==

The '''High Level''' corresponds to the strategic level of the certification framework.

At this stage, the objective is to determine how the aircraft is positioned within the EASA regulatory environment, which main texts apply, and what the overall certification philosophy will be. For a VTOL aircraft, this means identifying the main certification basis and then selecting the complementary texts required to cover the specific characteristics of the concept.

For '''Mini-Bee''', this level leads to a primary positioning under '''CS-27''' because of its rotorcraft logic. This basis is then complemented by '''SC-VTOL-02''' to account for the vertical capability, distributed propulsion architecture, lift/thrust chain, and the special safety considerations linked to VTOL operations.

At the High Level, it is also necessary to assess the maturity of the applicable rules and identify any gaps between the aircraft concept and the existing certification framework. This work may also require considering connections with other regulatory references such as '''CS-29''', '''CS-VLR''', or selected '''AMC/GM''' approaches depending on the detailed configuration and intended use of the aircraft.

[[File:VTOL_High_Level_Framework.png|thumb|right|450px|'''Figure 2.''' High Level view: regulatory positioning of Mini-Bee within the EASA certification environment.]]

In other words, the High Level defines the '''strategic certification map'''. It answers the question: ''under which main regulatory logic will the aircraft be certified?''

=== Key objectives of the High Level ===

* Identify the main aircraft category
* Define the principal certification basis
* Select the complementary special conditions
* Detect regulatory gaps or grey zones
* Establish the global certification philosophy

== Medium Level ==

The '''Medium Level''' corresponds to the compliance architecture of the systems and sub-systems.

Once the aircraft category and overall basis have been defined, it becomes necessary to specify which certification references apply to each major technical function. This is the level where the process moves from the question ''“what is the overall framework?”'' to the question ''“which certification reference applies to each building block?”''

For a hybrid VTOL aircraft such as '''Mini-Bee''', this means linking the aircraft-level basis with the relevant references for each domain:

* '''CS-E''' for the engine logic
* '''SC E-19''' for electric or hybrid propulsion systems
* '''CS-P''' for propulsive elements such as propellers or rotors
* '''CS-26''' for certain operational airworthiness topics
* '''AMC-20''' for general compliance approaches
* '''CS-34''' for emissions and environmental aspects

This level therefore transforms a broad regulatory vision into a more structured map of the technical requirements applicable to each major domain of the aircraft: propulsion, electrical installation, rotors, control interfaces, equipment, safety interactions, and environmental performance.

[[File:VTOL_Medium_Level_Compliance_Map.png|thumb|center|900px|'''Figure 3.''' Medium Level view: mapping the main certification references to each aircraft domain and subsystem.]]

The Medium Level is particularly important for '''Mini-Bee''' because the aircraft combines several technological layers that interact strongly with each other: hybrid propulsion, distributed lift, electrical power architecture, flight control logic, and safety management between conventional and non-conventional functions.

In practice, this level builds the '''compliance architecture''' of the project.

=== Key objectives of the Medium Level ===

* Allocate the relevant certification texts to each subsystem
* Build a technical compliance map
* Clarify interfaces between propulsion, electrical, and flight systems
* Identify the means of compliance expected for each domain
* Prepare the transition toward detailed demonstration

== Low Level ==

The '''Low Level''' is the level of concrete demonstration.

At this stage, the focus is no longer only on regulations or on the global compliance architecture. The work moves toward technical evidence. This is where every requirement must be translated into identifiable, traceable, and verifiable deliverables.

The Low Level includes, for example:

* Detailed requirement allocation
* Safety analyses
* Design assumptions
* System schematics
* Material files
* Control logic descriptions
* Bench tests
* HIL/SIL simulations
* Robustness checks
* Electromagnetic compatibility activities
* Inspection procedures
* Test reports
* Representative-environment evidence
* Flight evidence when applicable

In other words, the Low Level is where each requirement is linked to an explicit '''means of compliance''': analysis, calculation, test, inspection, demonstration, or a justified combination of these approaches.

[[File:VTOL_Low_Level_Demonstration.png|thumb|right|450px|'''Figure 4.''' Low Level view: technical evidence and means of compliance used to support certification.]]

This level gives an industrial project its real credibility because it connects the certification intent to a body of technical proof. Without this step, a certification framework remains theoretical. With it, the project becomes demonstrable, reviewable, and progressively acceptable from an authority perspective.

For '''Mini-Bee''', the Low Level is especially critical because innovative VTOL architectures require a clear demonstration of safety in normal, degraded, and transitional operating conditions. The project must therefore show not only the expected performance of the aircraft, but also the robustness of the design choices and the traceability of all supporting evidence.

=== Key objectives of the Low Level ===

* Translate requirements into verifiable evidence
* Define the means of compliance for each requirement
* Produce safety and technical demonstration files
* Organize testing, simulation, and verification activities
* Build traceability between design choices and certification evidence

== Summary View ==

The VTOL Certification Framework can therefore be understood through three complementary levels:

{| class="wikitable"
! Level
! Main purpose
! Main question
! Typical output
|-
| '''High Level'''
| Strategic positioning
| Which regulatory framework applies?
| Certification basis and global philosophy
|-
| '''Medium Level'''
| Compliance architecture
| Which text applies to each subsystem?
| Map of applicable rules by technical domain
|-
| '''Low Level'''
| Technical demonstration
| Which evidence proves compliance?
| Analyses, tests, reports, simulations, and demonstrations
|}

[[File:VTOL_Certification_Three_Levels.png|thumb|center|900px|'''Figure 5.''' The three levels of the VTOL Certification Framework: High Level, Medium Level, and Low Level.]]

== Why this framework is essential for a VTOL aircraft ==

A VTOL aircraft cannot be treated like a conventional aircraft based only on performance. Its real value depends on its ability to be '''certifiable'''. This means being able to demonstrate the safety of its design choices, the consistency of its propulsion architecture, the control of degraded modes, the robustness of its flight control system, and the traceability of its compliance evidence.

The '''VTOL Certification Framework''' is precisely what structures this process, from the high-level regulatory vision down to the detailed technical demonstrations. It is therefore not only a compliance framework, but also a '''design management tool'''. It helps organize engineering decisions, identify missing evidence, structure technical development, and build credibility toward authorities, partners, and future operators.

For '''Mini-Bee''', this framework is essential because it transforms an innovative VTOL concept into a project that can be progressively justified, tested, and matured toward a realistic certification pathway.

[[File:MiniBee_Certification_Pathway.png|thumb|center|900px|'''Figure 6.''' Certification pathway vision for Mini-Bee, from concept definition to demonstrable compliance.]]

== See also ==

* [[Mini-Bee]]
* [[Minibee TRL3]]
* [[EASA]]
* [[SC-VTOL-02]]
* [[CS-27]]
* [[Hybrid Propulsion]]

Alten Solidaire

2026-05-18T09:48:28Z

Wiki.admin: /* Alten Solidaire */

= Alten Solidaire =

<div style="border-left:5px solid #1f4e79; padding:18px 24px; margin:20px 0 30px 0; background:#f7f9fc; font-size:16px; line-height:1.65;">

'''Alten Solidaire''' is positioned in the Bee ecosystem as an engineering support contributor serving a project with a humanitarian purpose.
Coming from the ALTEN group, Alten Solidaire is linked to a skills-based sponsorship approach, where engineering knowledge, technical method and human commitment can support projects of general interest.

In the context of the Bee ecosystem, this role becomes especially meaningful through the link between '''Alten Solidaire''', '''RED VTOL ONG''' and the '''Mini-Bee Hybrid''' project. The objective is not only to explore an innovative aircraft architecture, but also to support a possible operational use case: vertical flight technologies serving emergency response, medical support and humanitarian missions.

</div>

* [https://www.alten.fr/alten-solidaire/ ALTEN Solidaire – ALTEN France]

[[File:Logo Alten Solidaire.png|thumb|center|700px]]
== Alten Solidaire and RED VTOL ONG ==

<div style="display:flex; gap:28px; align-items:stretch; margin:25px 0; flex-wrap:wrap;">

<div style="flex:1; min-width:280px; border:1px solid #ddd; border-radius:14px; padding:22px; background:#ffffff; box-shadow:0 2px 8px rgba(0,0,0,0.06); font-size:16px; line-height:1.65;">

'''RED VTOL ONG''' represents the humanitarian application side of the VTOL vision. Its purpose is to promote and explore vertical take-off and landing technologies that could be useful for rescue operations, emergency access, medical evacuation, light logistics and intervention in degraded environments.

In this framework, '''Alten Solidaire''' can be understood as an engineering support actor. Its contribution is not presented as the ownership of an aircraft programme, but as a technical and methodological support helping a humanitarian-oriented project become more structured, credible and readable.

</div>

<div style="flex:1; min-width:280px; border:1px solid #ddd; border-radius:14px; padding:22px; background:#ffffff; box-shadow:0 2px 8px rgba(0,0,0,0.06); font-size:16px; line-height:1.65;">

The connection between Alten Solidaire and RED VTOL ONG gives a practical meaning to the Mini-Bee Hybrid project. The aircraft is not only considered as a technology demonstrator. It is also studied as a possible tool for missions where rapid access, reduced infrastructure and operational flexibility are essential.

This creates a clear positioning: '''engineering serving humanitarian mobility'''.

</div>

</div>

== Humanitarian use of VTOL technologies ==

Vertical take-off and landing aircraft are relevant for humanitarian missions because they can operate with limited ground infrastructure. Unlike conventional aircraft, they do not necessarily require a runway. Compared with traditional helicopters, new VTOL concepts may explore different compromises between cost, noise, energy source, maintenance, modularity and operational accessibility.

For humanitarian use, the main value is not technological novelty by itself. The value comes from the mission: reaching isolated areas, supporting emergency teams, transporting light medical equipment, evacuating a patient, or connecting a temporary base with a damaged or remote location.

Typical humanitarian VTOL use cases include:

* '''Emergency medical access''' in isolated or poorly connected territories.
* '''Light medical evacuation''' when ground transport is too slow or impossible.
* '''Rapid response after natural disasters''' when roads, bridges or airports are unavailable.
* '''Transport of small critical payloads''' such as medicine, blood bags, diagnostic equipment or communication devices.
* '''Support to field teams''' operating in remote, mountainous, flooded or degraded environments.
* '''Reconnaissance and coordination''' before sending heavier rescue assets.

== Current aircraft families used for emergency missions ==

Before considering innovative VTOL architectures, it is useful to understand the aircraft families already used today for emergency, rescue and humanitarian missions.

<div style="border:1px solid #ddd; border-radius:14px; overflow:hidden; margin:25px 0;">

{| class="wikitable" style="width:100%; margin:0; font-size:15px; line-height:1.55;"
! style="width:25%; background:#1f4e79; color:white;" | Aircraft family
! style="width:35%; background:#1f4e79; color:white;" | Typical strengths
! style="width:40%; background:#1f4e79; color:white;" | Operational limits
|-
| '''Twin-engine helicopters'''
| High safety margin, strong operational capability, medical evacuation compatibility, professional emergency use.
| High acquisition cost, high operating cost, demanding maintenance, need for trained crews and support infrastructure.
|-
| '''Single-turbine helicopters'''
| Good balance between performance and cost, widely used for utility missions, rescue support and regional operations.
| Still expensive to operate, noisy, fuel-dependent and maintenance-intensive.
|-
| '''Light helicopters'''
| More accessible, useful for observation, light transport and short-range missions.
| Limited payload, limited medical configuration, weather sensitivity and reduced redundancy.
|}

</div>

These aircraft remain essential today. However, they also show why new VTOL concepts are being explored: lower infrastructure needs, potentially lower operating cost, modular deployment and better adaptation to targeted missions.

== Innovative VTOL project landscape ==

The VTOL innovation landscape is broad. It includes electric air taxis, autonomous passenger aircraft, personal VTOL machines, multicopter platforms and hybrid-electric concepts. For a humanitarian project such as RED VTOL ONG, these examples are useful as references, but they must be evaluated with caution. Certification, payload, endurance, safety, maintainability and cost remain decisive.

<div style="display:grid; grid-template-columns:repeat(auto-fit, minmax(260px, 1fr)); gap:20px; margin:25px 0;">

<div style="border:1px solid #ddd; border-radius:14px; padding:20px; background:#fdfdfd; box-shadow:0 2px 8px rgba(0,0,0,0.05);">
'''Joby Aviation'''<br>
All-electric piloted eVTOL concept focused on air taxi operations. It is one of the most visible advanced air mobility projects and is often used as a reference for electric VTOL development.
</div>

<div style="border:1px solid #ddd; border-radius:14px; padding:20px; background:#fdfdfd; box-shadow:0 2px 8px rgba(0,0,0,0.05);">
'''EHang EH216-S'''<br>
Autonomous passenger-carrying eVTOL platform. It is an important reference because of its certification progress in China for pilotless passenger operations.
</div>

<div style="border:1px solid #ddd; border-radius:14px; padding:20px; background:#fdfdfd; box-shadow:0 2px 8px rgba(0,0,0,0.05);">
'''Volocopter'''<br>
Electric multicopter VTOL concept historically focused on urban air mobility. It remains a useful technical reference, although its industrial and financial situation requires caution.
</div>

<div style="border:1px solid #ddd; border-radius:14px; padding:20px; background:#fdfdfd; box-shadow:0 2px 8px rgba(0,0,0,0.05);">
'''Lilium'''<br>
Former electric jet-based eVTOL project. It should now be treated mainly as a historical reference showing both the ambition and the financial difficulty of the eVTOL sector.
</div>

<div style="border:1px solid #ddd; border-radius:14px; padding:20px; background:#fdfdfd; box-shadow:0 2px 8px rgba(0,0,0,0.05);">
'''Zapata AirScooter'''<br>
Personal hybrid-electric VTOL machine. It illustrates a different approach, closer to individual vertical mobility than to collective air transport.
</div>

<div style="border:1px solid #ddd; border-radius:14px; padding:20px; background:#fdfdfd; box-shadow:0 2px 8px rgba(0,0,0,0.05);">
'''Mini-Bee Hybrid'''<br>
Hybrid VTOL concept developed in the Bee ecosystem, with a humanitarian orientation through RED VTOL ONG and a focus on useful missions, emergency access and modular deployment.
</div>

</div>

== Electric, hybrid and piston-based VTOL approaches ==

Different VTOL architectures answer different operational needs.

'''All-electric VTOL''' aircraft are attractive because of their low local emissions, reduced acoustic signature and simplified propulsion architecture. However, endurance, charging infrastructure, payload and battery mass remain important constraints, especially for humanitarian missions far from prepared bases.

'''Hybrid-electric VTOL''' aircraft combine electric propulsion with an onboard energy source, often a combustion engine used as a generator. This approach can improve range, endurance and operational flexibility. For humanitarian use, hybridization may be relevant when missions require longer distances, uncertain infrastructure or rapid redeployment.

'''Piston-engine and turbine-based systems''' remain important because they are already proven in aviation. Engines such as Rotax aircraft engines are widely used in light aviation and can support hybrid architectures where a combustion engine feeds an electric propulsion system.

== Mini-Bee Hybrid as a humanitarian VTOL concept ==

Within the Bee ecosystem, '''Mini-Bee Hybrid''' is positioned as a light hybrid VTOL concept designed around useful missions rather than luxury mobility. Its purpose is connected to emergency response, medical support, humanitarian logistics and rapid intervention.

The project explores an aircraft architecture that could support:

* vertical take-off and landing without a conventional runway;
* modular deployment in difficult environments;
* light medical or emergency missions;
* operation in areas with reduced infrastructure;
* a balance between electric propulsion benefits and hybrid endurance;
* a possible link with humanitarian field operations through RED VTOL ONG.

This is where the support of Alten Solidaire becomes valuable. The challenge is not only to imagine an aircraft, but to structure a credible engineering approach around the mission.

== Role of Alten Solidaire in the project ==

Alten Solidaire can contribute by bringing engineering culture, technical discipline and project structuring to a humanitarian-oriented innovation effort.

Its role may include:

* helping clarify operational needs;
* supporting the definition of technical requirements;
* contributing to architecture studies;
* improving the readability of engineering choices;
* supporting the link between mission needs and aircraft design;
* helping transform a concept into a more structured development path;
* bringing method, technical review and engineering perspective.

In this position, Alten Solidaire supports RED VTOL ONG by helping the humanitarian application become technically clearer. The objective is to make the project easier to understand, easier to discuss with partners and more coherent from an engineering perspective.

== A shared ambition: engineering for humanitarian action ==

The link between Alten Solidaire, RED VTOL ONG and Mini-Bee Hybrid gives the project a strong identity. It combines three complementary dimensions:

<div style="display:grid; grid-template-columns:repeat(auto-fit, minmax(240px, 1fr)); gap:20px; margin:25px 0;">

<div style="border-left:5px solid #1f4e79; padding:18px; background:#f7f9fc; border-radius:10px;">
'''Engineering method'''<br>
A structured approach to requirements, architecture, feasibility and technical credibility.
</div>

<div style="border-left:5px solid #1f4e79; padding:18px; background:#f7f9fc; border-radius:10px;">
'''Humanitarian purpose'''<br>
A focus on emergency access, medical support, rescue missions and operations in difficult environments.
</div>

<div style="border-left:5px solid #1f4e79; padding:18px; background:#f7f9fc; border-radius:10px;">
'''VTOL innovation'''<br>
A search for new aerial mobility solutions that can operate with reduced ground infrastructure.
</div>

</div>

Alten Solidaire therefore appears as an engineering support actor serving a wider humanitarian ambition. Through its connection with RED VTOL ONG, it helps position Mini-Bee Hybrid not only as an aeronautical innovation, but as a possible tool for useful missions.

== Summary ==

Alten Solidaire is part of the Bee ecosystem as a technical and human support contributor. Its position is especially relevant in relation to RED VTOL ONG, because the project aims to connect VTOL innovation with humanitarian use cases.

The Mini-Bee Hybrid project gives this relationship a concrete direction: a light hybrid VTOL concept studied for emergency, medical and humanitarian missions. In this framework, Alten Solidaire helps reinforce the engineering credibility of a project whose purpose is not only to fly, but to serve.

== References ==

Alten Solidaire

2026-05-18T09:44:36Z

Wiki.admin: /* Alten Solidaire and RED VTOL ONG */

= Alten Solidaire =

<div style="border-left:5px solid #1f4e79; padding:18px 24px; margin:20px 0 30px 0; background:#f7f9fc; font-size:16px; line-height:1.65;">

'''Alten Solidaire''' is positioned in the Bee ecosystem as an engineering support contributor serving a project with a humanitarian purpose.
Coming from the ALTEN group, Alten Solidaire is linked to a skills-based sponsorship approach, where engineering knowledge, technical method and human commitment can support projects of general interest.

In the context of the Bee ecosystem, this role becomes especially meaningful through the link between '''Alten Solidaire''', '''RED VTOL ONG''' and the '''Mini-Bee Hybrid''' project. The objective is not only to explore an innovative aircraft architecture, but also to support a possible operational use case: vertical flight technologies serving emergency response, medical support and humanitarian missions.

</div>

* [https://www.alten.fr/alten-solidaire/ ALTEN Solidaire – ALTEN France]

[[File:Logo Alten Solidaire.png]]
== Alten Solidaire and RED VTOL ONG ==

<div style="display:flex; gap:28px; align-items:stretch; margin:25px 0; flex-wrap:wrap;">

<div style="flex:1; min-width:280px; border:1px solid #ddd; border-radius:14px; padding:22px; background:#ffffff; box-shadow:0 2px 8px rgba(0,0,0,0.06); font-size:16px; line-height:1.65;">

'''RED VTOL ONG''' represents the humanitarian application side of the VTOL vision. Its purpose is to promote and explore vertical take-off and landing technologies that could be useful for rescue operations, emergency access, medical evacuation, light logistics and intervention in degraded environments.

In this framework, '''Alten Solidaire''' can be understood as an engineering support actor. Its contribution is not presented as the ownership of an aircraft programme, but as a technical and methodological support helping a humanitarian-oriented project become more structured, credible and readable.

</div>

<div style="flex:1; min-width:280px; border:1px solid #ddd; border-radius:14px; padding:22px; background:#ffffff; box-shadow:0 2px 8px rgba(0,0,0,0.06); font-size:16px; line-height:1.65;">

The connection between Alten Solidaire and RED VTOL ONG gives a practical meaning to the Mini-Bee Hybrid project. The aircraft is not only considered as a technology demonstrator. It is also studied as a possible tool for missions where rapid access, reduced infrastructure and operational flexibility are essential.

This creates a clear positioning: '''engineering serving humanitarian mobility'''.

</div>

</div>

== Humanitarian use of VTOL technologies ==

Vertical take-off and landing aircraft are relevant for humanitarian missions because they can operate with limited ground infrastructure. Unlike conventional aircraft, they do not necessarily require a runway. Compared with traditional helicopters, new VTOL concepts may explore different compromises between cost, noise, energy source, maintenance, modularity and operational accessibility.

For humanitarian use, the main value is not technological novelty by itself. The value comes from the mission: reaching isolated areas, supporting emergency teams, transporting light medical equipment, evacuating a patient, or connecting a temporary base with a damaged or remote location.

Typical humanitarian VTOL use cases include:

* '''Emergency medical access''' in isolated or poorly connected territories.
* '''Light medical evacuation''' when ground transport is too slow or impossible.
* '''Rapid response after natural disasters''' when roads, bridges or airports are unavailable.
* '''Transport of small critical payloads''' such as medicine, blood bags, diagnostic equipment or communication devices.
* '''Support to field teams''' operating in remote, mountainous, flooded or degraded environments.
* '''Reconnaissance and coordination''' before sending heavier rescue assets.

== Current aircraft families used for emergency missions ==

Before considering innovative VTOL architectures, it is useful to understand the aircraft families already used today for emergency, rescue and humanitarian missions.

<div style="border:1px solid #ddd; border-radius:14px; overflow:hidden; margin:25px 0;">

{| class="wikitable" style="width:100%; margin:0; font-size:15px; line-height:1.55;"
! style="width:25%; background:#1f4e79; color:white;" | Aircraft family
! style="width:35%; background:#1f4e79; color:white;" | Typical strengths
! style="width:40%; background:#1f4e79; color:white;" | Operational limits
|-
| '''Twin-engine helicopters'''
| High safety margin, strong operational capability, medical evacuation compatibility, professional emergency use.
| High acquisition cost, high operating cost, demanding maintenance, need for trained crews and support infrastructure.
|-
| '''Single-turbine helicopters'''
| Good balance between performance and cost, widely used for utility missions, rescue support and regional operations.
| Still expensive to operate, noisy, fuel-dependent and maintenance-intensive.
|-
| '''Light helicopters'''
| More accessible, useful for observation, light transport and short-range missions.
| Limited payload, limited medical configuration, weather sensitivity and reduced redundancy.
|}

</div>

These aircraft remain essential today. However, they also show why new VTOL concepts are being explored: lower infrastructure needs, potentially lower operating cost, modular deployment and better adaptation to targeted missions.

== Innovative VTOL project landscape ==

The VTOL innovation landscape is broad. It includes electric air taxis, autonomous passenger aircraft, personal VTOL machines, multicopter platforms and hybrid-electric concepts. For a humanitarian project such as RED VTOL ONG, these examples are useful as references, but they must be evaluated with caution. Certification, payload, endurance, safety, maintainability and cost remain decisive.

<div style="display:grid; grid-template-columns:repeat(auto-fit, minmax(260px, 1fr)); gap:20px; margin:25px 0;">

<div style="border:1px solid #ddd; border-radius:14px; padding:20px; background:#fdfdfd; box-shadow:0 2px 8px rgba(0,0,0,0.05);">
'''Joby Aviation'''<br>
All-electric piloted eVTOL concept focused on air taxi operations. It is one of the most visible advanced air mobility projects and is often used as a reference for electric VTOL development.
</div>

<div style="border:1px solid #ddd; border-radius:14px; padding:20px; background:#fdfdfd; box-shadow:0 2px 8px rgba(0,0,0,0.05);">
'''EHang EH216-S'''<br>
Autonomous passenger-carrying eVTOL platform. It is an important reference because of its certification progress in China for pilotless passenger operations.
</div>

<div style="border:1px solid #ddd; border-radius:14px; padding:20px; background:#fdfdfd; box-shadow:0 2px 8px rgba(0,0,0,0.05);">
'''Volocopter'''<br>
Electric multicopter VTOL concept historically focused on urban air mobility. It remains a useful technical reference, although its industrial and financial situation requires caution.
</div>

<div style="border:1px solid #ddd; border-radius:14px; padding:20px; background:#fdfdfd; box-shadow:0 2px 8px rgba(0,0,0,0.05);">
'''Lilium'''<br>
Former electric jet-based eVTOL project. It should now be treated mainly as a historical reference showing both the ambition and the financial difficulty of the eVTOL sector.
</div>

<div style="border:1px solid #ddd; border-radius:14px; padding:20px; background:#fdfdfd; box-shadow:0 2px 8px rgba(0,0,0,0.05);">
'''Zapata AirScooter'''<br>
Personal hybrid-electric VTOL machine. It illustrates a different approach, closer to individual vertical mobility than to collective air transport.
</div>

<div style="border:1px solid #ddd; border-radius:14px; padding:20px; background:#fdfdfd; box-shadow:0 2px 8px rgba(0,0,0,0.05);">
'''Mini-Bee Hybrid'''<br>
Hybrid VTOL concept developed in the Bee ecosystem, with a humanitarian orientation through RED VTOL ONG and a focus on useful missions, emergency access and modular deployment.
</div>

</div>

== Electric, hybrid and piston-based VTOL approaches ==

Different VTOL architectures answer different operational needs.

'''All-electric VTOL''' aircraft are attractive because of their low local emissions, reduced acoustic signature and simplified propulsion architecture. However, endurance, charging infrastructure, payload and battery mass remain important constraints, especially for humanitarian missions far from prepared bases.

'''Hybrid-electric VTOL''' aircraft combine electric propulsion with an onboard energy source, often a combustion engine used as a generator. This approach can improve range, endurance and operational flexibility. For humanitarian use, hybridization may be relevant when missions require longer distances, uncertain infrastructure or rapid redeployment.

'''Piston-engine and turbine-based systems''' remain important because they are already proven in aviation. Engines such as Rotax aircraft engines are widely used in light aviation and can support hybrid architectures where a combustion engine feeds an electric propulsion system.

== Mini-Bee Hybrid as a humanitarian VTOL concept ==

Within the Bee ecosystem, '''Mini-Bee Hybrid''' is positioned as a light hybrid VTOL concept designed around useful missions rather than luxury mobility. Its purpose is connected to emergency response, medical support, humanitarian logistics and rapid intervention.

The project explores an aircraft architecture that could support:

* vertical take-off and landing without a conventional runway;
* modular deployment in difficult environments;
* light medical or emergency missions;
* operation in areas with reduced infrastructure;
* a balance between electric propulsion benefits and hybrid endurance;
* a possible link with humanitarian field operations through RED VTOL ONG.

This is where the support of Alten Solidaire becomes valuable. The challenge is not only to imagine an aircraft, but to structure a credible engineering approach around the mission.

== Role of Alten Solidaire in the project ==

Alten Solidaire can contribute by bringing engineering culture, technical discipline and project structuring to a humanitarian-oriented innovation effort.

Its role may include:

* helping clarify operational needs;
* supporting the definition of technical requirements;
* contributing to architecture studies;
* improving the readability of engineering choices;
* supporting the link between mission needs and aircraft design;
* helping transform a concept into a more structured development path;
* bringing method, technical review and engineering perspective.

In this position, Alten Solidaire supports RED VTOL ONG by helping the humanitarian application become technically clearer. The objective is to make the project easier to understand, easier to discuss with partners and more coherent from an engineering perspective.

== A shared ambition: engineering for humanitarian action ==

The link between Alten Solidaire, RED VTOL ONG and Mini-Bee Hybrid gives the project a strong identity. It combines three complementary dimensions:

<div style="display:grid; grid-template-columns:repeat(auto-fit, minmax(240px, 1fr)); gap:20px; margin:25px 0;">

<div style="border-left:5px solid #1f4e79; padding:18px; background:#f7f9fc; border-radius:10px;">
'''Engineering method'''<br>
A structured approach to requirements, architecture, feasibility and technical credibility.
</div>

<div style="border-left:5px solid #1f4e79; padding:18px; background:#f7f9fc; border-radius:10px;">
'''Humanitarian purpose'''<br>
A focus on emergency access, medical support, rescue missions and operations in difficult environments.
</div>

<div style="border-left:5px solid #1f4e79; padding:18px; background:#f7f9fc; border-radius:10px;">
'''VTOL innovation'''<br>
A search for new aerial mobility solutions that can operate with reduced ground infrastructure.
</div>

</div>

Alten Solidaire therefore appears as an engineering support actor serving a wider humanitarian ambition. Through its connection with RED VTOL ONG, it helps position Mini-Bee Hybrid not only as an aeronautical innovation, but as a possible tool for useful missions.

== Summary ==

Alten Solidaire is part of the Bee ecosystem as a technical and human support contributor. Its position is especially relevant in relation to RED VTOL ONG, because the project aims to connect VTOL innovation with humanitarian use cases.

The Mini-Bee Hybrid project gives this relationship a concrete direction: a light hybrid VTOL concept studied for emergency, medical and humanitarian missions. In this framework, Alten Solidaire helps reinforce the engineering credibility of a project whose purpose is not only to fly, but to serve.

== References ==