MOGWAI en production : quand un langage de script donne vie à un banc de test industriel

Cas d’usage n°1 — Banc de test pour cartes électroniques

Le problème, posé simplement

Imaginez une société qui fabrique des produits électroniques. Deux gammes, deux architectures (LoRaWAN + BLE, 4G + BLE), deux types de cartes — une carte power et une carte processing — à tester séparément puis assemblées. En tout, cinq scénarios de test distincts, chacun composé de plusieurs dizaines de vérifications : tensions, niveaux logiques, couleurs de voyants LED, programmation du microcontrôleur, configuration LoRaWAN, communication avec un serveur…

Et le cahier des charges, redoutable dans sa simplicité apparente :

Le programme PC doit être le même pour tous les tests, présents et futurs. Il ne doit jamais être modifié ni recompilé pour ajouter un nouveau test. Les tests doivent pouvoir être mis à jour à distance, chez les sous-traitants, sans intervention sur le logiciel.

En d’autres termes : un programme figé, des tests vivants.

La solution : embarquer un runtime de script

La réponse à ce problème, c’est d’embarquer le runtime MOGWAI dans l’application WinForm .NET du banc de test.

Au lieu de coder chaque séquence de test en C#, on l’écrit en MOGWAI. Le programme PC devient un hôte : il gère la communication USB avec l’outillage de test, expose des fonctions étendues au runtime (affichage, sons, interaction utilisateur), et se contente de jouer les scripts. Les scripts, eux, contiennent toute la logique.

Ajouter un nouveau test revient à déposer un nouveau dossier contenant ses fichiers MOGWAI. Pas une ligne de C# à toucher.

Architecture du banc de test

Programme PC (WinForm .NET)
│
├── Runtime MOGWAI (embarqué)
│   ├── banc.mog          ← bibliothèque partagée par tous les tests
│   │
│   ├── Test carte power/
│   │   ├── main.mog      ← séquence de test
│   │   └── config.mog    ← paramètres de l'outillage
│   │
│   ├── Test processing LoRaWAN/
│   │   ├── main.mog
│   │   └── config.mog
│   │
│   └── ... (3 autres tests)
│
└── Fonctions hôte exposées au runtime
    (COM USB, UI, logs, sons...)

Le fichier banc.mog est le cœur de l’affaire. Il contient toutes les fonctions communes à l’ensemble des tests : dialogue avec l’outillage, programmation JLink, gestion du serveur, vérifications de conformité. Chaque test main.mog s’appuie sur cette bibliothèque partagée.

Ce que MOGWAI orchestre concrètement

1. Attente de mise sous tension de l’outillage

Avant de lancer un test, il faut s’assurer que le coffret est alimenté. Plutôt qu’un simple délai, MOGWAI effectue une mesure réelle et attend une réponse valide :

to 'WAIT_FOR_POWER_ON' params [signal: .string] do
{
    false -> 'showWaitForPower'
    forever do
    {
        "AT+MEASURE:{! signal}" eval COM.cwrite
        [COM.mread timeout: 1000 expected: ("*")] -> 'r'
        if (r->state "Success" !=) then
        {
            [UI.showModal icon: "error"
                message: "Il y a un problème de communication avec le coffret !"
                buttons: ("ARRETER")] drop
            mogwai.exit
        }
        else
        {
            if (r->answers "Command fail" contains) then
            {
                if (showWaitForPower not) then
                {
                    true -> 'showWaitForPower'
                    [UI.show icon: "Warning"
                        message: "Veuillez alimenter le coffret..."]
                }
                1000 wait
            }
            else
            {
                if (showWaitForPower) then { UI.hide }
                break
            }
        }
    }
}

La boucle interroge l’outillage, affiche un message d’invite si nécessaire, et sort proprement dès que la tension est détectée. Aucun timeout arbitraire — on attend l’état réel.

2. Programmation du firmware via sonde JLink

MOGWAI pilote directement la sonde JLink pour programmer le microcontrôleur STM32WB55. Le script génère dynamiquement le fichier de commandes JLink, lance le processus externe et attend son retour :

to 'JLINK_FW_PROGRAMMING' do
{
    (! "HOME" $JLINK_FOLDER) dir.enter
    (
        !
        "Erase 0x08000000 0x080B9FFF"
        "LoadFile {! $JLINK_FW_MASTER_FILE}"
        "Exit"
    ) "\r\n" eval join ->ascii
    $JLINK_SCRIPT_FILE file.write
    [
        !
        PROCESS.start
        filename: $JLINK_PROGRAM
        arguments: "-AutoConnect 1 -ExitOnError 1 -device STM32WB55RG
                    -if swd -speed 2000 -CommandFile {! $JLINK_SCRIPT_FILE}"
        workingDirectory: $JLINK_FOLDER
        wait: true
    ]
    trap { $JLINK_SCRIPT_FILE file.purge }
}

La même mécanique est utilisée pour programmer la stack BLE et les option bytes — trois fonctions indépendantes, chacune générant son propre script JLink à la volée.

3. Vérification de voyants LED par analyse colorimétrique

Le banc vérifie que les voyants de la carte émettent bien les bonnes couleurs. MOGWAI effectue une calibration initiale (10 mesures moyennées), puis compare chaque lecture aux plages RVB attendues :

to 'GET_LED' params [name: .string timeout: .number save: .boolean
                     rMin: .number rMax: .number
                     gMin: .number gMax: .number
                     bMin: .number bMax: .number] do
{
    [COM.mwrite command: "AT+LED:?" timeout: 5000
        expected: ("*,*,*,*")] -> 'result'
    result (answers: 0) get "," split -> 'result'
    result 0 get hex-> $LED_INIT_R - -> 'r'
    result 1 get hex-> $LED_INIT_G - -> 'g'
    result 2 get hex-> $LED_INIT_B - -> 'b'
    r rMin >= r rMax <= and -> 'rTest'
    g gMin >= g gMax <= and -> 'gTest'
    b bMin >= b bMax <= and -> 'bTest'
    if (rTest gTest bTest and and not) then
    {
        "Non conforme !" LOG.write
        EXECUTE_ON_ERROR_FUNCTION
    }
    else
    {
        "Conforme." LOG.write
    }
}

4. Résilience serveur avec file d’attente locale

Quand la connexion au serveur est indisponible, les données ne sont pas perdues. MOGWAI les sérialise dans un fichier horodaté et les renvoie automatiquement dès que le serveur répond à nouveau — sans intervention humaine :

# Serveur inaccessible → on sauvegarde localement
content "LB-{! year}{! month}{! day}-{! hour}{! minute}{! second}.mog"
    eval file.pack
false -> '$SERVER_LAST_KNOWN_STATE'
'EVENT_SERVER_ERROR' null event.host.fire

Un processus de synchronisation tourne en arrière-plan et traite la file dès que la connexion revient.

Ce que ça change en pratique

• Zéro recompilation pour ajouter ou modifier un test. Le sous-traitant reçoit un nouveau dossier, le dépose dans l’application, c’est prêt.
• Mise au point rapide grâce à MOGWAI STUDIO et son débogueur intégré — les séquences de plusieurs minutes se mettent au point pas à pas.
• Évolutivité totale : si demain l’outillage change de protocole de communication, on modifie banc.mog. Le programme PC, lui, ne bouge pas.
• Traçabilité complète : chaque test génère un fichier de log horodaté, et les données sont transmises au serveur (ou mises en attente) automatiquement.

L’application banc de test avec ses 5 séquences est en production depuis octobre 2025, déployée chez les sous-traitants qui fabriquent les cartes électroniques. Elle est prévue pour tester plusieurs milliers de cartes chaque année.

Bilan

MOGWAI y tourne quotidiennement, du démarrage à l’arrêt, sans accroc. Il programme les microcontrôleurs, vérifie les tensions, lit les couleurs, dialogue avec le serveur, et génère les logs de traçabilité — tout cela en scripts interchangeables, sans toucher une seule ligne de l’application hôte.

C’est exactement le problème que MOGWAI était destiné à résoudre.

→ Découvrir MOGWAI sur GitHub
→ Essayer le Playground en ligne