MES de traçabilité unitaire — provisionnement & rendement, électronique et IoT

Votre ligne ne peut pas fabriquer une révision obsolète. Ni expédier deux fois la même adresse MAC.

Device Fabrik Link est un logiciel MES de traçabilité unitaire, de provisionnement en usine et d'analyse du rendement pour les fabricants d'électronique et d'objets connectés. Vos bancs de test réclament les numéros de série, adresses MAC et firmwares via une API REST, puis rattachent chaque résultat, mesure et journal à l'unité qui les a reçus — y compris sur une ligne que vous ne possédez pas.

  • Sur votre infrastructure ou en cloud privé
  • API REST pour les bancs que vous avez déjà
  • Chaque sous-traitant ne voit que sa production
  • Unité par unitéÉtapes, mesures, reprises, banc et horodatage
  • MAC · DSN · ZigBeeAttribution atomique depuis vos pools d'identifiants
  • ECO + firmwareImpossible de produire une révision non autorisée
  • 4 types d'appelLe temps d'intégrer un banc de test existant
portal.votre-usine.com/analytics
Analytics — Production UBRIDGE-200 14 jours
  • 94,2 %Terminées sans erreur
  • 3,1 %Terminées avec reprise
  • 2,7 %Non terminées
  • 6 min 12Temps d'opération moyen
  • Sans erreur
  • Avec reprise
  • Non terminées
  • Passe unique
ASN UB200-24W31-0428 PROGRAMMING RF_TEST RF_TEST · reprise FINAL_QC DFL-PB-0022

Vue d'illustration — données fictives.

Illustration du tableau de bord Analytics de Device Fabrik Link : indicateurs de rendement, production quotidienne par état d'achèvement et historique des étapes d'une unité.

Le problème

Votre ligne produit des données à chaque seconde. Vous n'en voyez presque rien.

Entre le banc de test et le rapport hebdomadaire, l'essentiel se perd : ce qui a été testé, ce qui a échoué, ce qui a été repris — et avec quel firmware.

  • Un retour client, aucune réponse

    L'appareil revient du terrain. Quel firmware ? Quel banc ? Quelles valeurs mesurées ? Sans historique unitaire, l'analyse s'arrête à la supposition.

  • Des identifiants gérés à la main

    Adresses MAC, numéros de série et certificats vivent dans des tableurs partagés. Un seul doublon suffit à faire revenir un lot entier.

  • Un rendement que personne ne mesure

    Sans rendement au premier passage, ni vue des étapes qui échouent le plus, une dérive de test coûte des semaines de production avant même d'être visible.

  • Des révisions qui dérivent

    Le firmware d'un banc n'est pas celui du banc voisin, et l'usine construit encore l'ancienne révision. On le découvre au contrôle final. Ou chez le client.

DFL ferme la boucle : le banc enregistre, la plateforme conserve, et vous répondez en quelques secondes — pas en quelques semaines.

Fonctionnement

Quatre étapes entre votre banc de test et la preuve

Vos bancs restent les vôtres. DFL ajoute la couche qui enregistre, attribue et prouve.

  1. Déclarez vos bancs

    Chaque poste de test reçoit un nom, un token secret et, si vous le souhaitez, une adresse MAC qui le verrouille à un matériel précis. Un token compromis se révoque sans toucher aux autres postes.

    Portail → Bancs → Nouveau banc
  2. Décrivez le produit

    Un pipeline définit la séquence d'étapes attendue et l'étape qui vaut fin de production. Un ECO fige la révision, l'usine autorisée et le firmware qui va avec.

    Statut ACTIVE = production autorisée
  3. Produisez

    Le banc demande un ASN pour l'unité, télécharge le bon firmware, tire ses identifiants et publie chaque étape avec son résultat et ses mesures. Les reprises sont conservées, pas écrasées.

    GET /v1/uuid → POST /v1/step
  4. Analysez et prouvez

    Rendement au premier passage, Pareto des erreurs par étape, comparaison d'une semaine ou d'un mois à l'autre, et l'historique complet de n'importe quelle unité en une recherche.

    Portail → Analytics · Bibliothèque

La plateforme

Tout ce qu'il faut pour piloter une production électronique

Un portail web pour vos équipes, une API REST pour vos bancs, une base de données par produit.

  • Traçabilité unitaire

    Chaque unité possède son dossier : étapes, résultats, mesures, reprises, banc et horodatage.

    • Recherche par ASN ou par numéro de série usine (FSN)
    • Toutes les tentatives conservées, pas seulement la dernière
    • Colonnes personnalisées selon vos paramètres produit
  • Provisioning d'identifiants

    MAC, DSN, certificats et install codes ZigBee sont attribués depuis vos pools, de façon atomique.

    • Attribution idempotente : une reprise ne consomme pas d'adresse
    • Plusieurs MAC par appareil via un sous-identifiant de port
    • Pool épuisé : un appel renvoie une erreur au lieu d'un doublon
  • Analytics et rendement

    Sans erreur, avec reprise, non terminées : trois états qui totalisent 100 % de vos unités.

    • Taux de réussite au premier passage par produit et par période
    • Classement des étapes qui échouent le plus
    • Comparaison semaine à semaine ou mois à mois
  • Gestion des ECO

    Un ECO fige la configuration de production : révision, usine autorisée, firmware, étiquetage.

    • Cycle CREATED → ACTIVE → CLOSED, fermeture irréversible
    • Seul un ECO ACTIVE autorise un banc à produire
    • Le code usine limite qui est autorisé à fabriquer
  • Parc de bancs

    Chaque poste de test est enregistré, authentifié et suivi, où qu'il se trouve dans le monde.

    • Token secret par banc, adresse MAC optionnelle en verrou
    • Dernier accès et compteur d'appels pour repérer un banc muet
    • Emplacement, modèle, OS et date de maintenance
  • Distribution de firmware

    Le firmware est attaché à l'ECO : le banc télécharge exactement la version prévue pour ce qu'il produit.

    • Version et somme de contrôle livrées avec le binaire
    • Firmware de production immuable une fois publié
    • Remplacement réservé aux ECO de type QA
  • Kits produits

    Regroupez plusieurs produits en un assemblage traçable, avec son propre numéro de série.

    • ASN de kit dérivé du code, de l'année et de la semaine
    • Traçabilité dans les deux sens entre le kit et ses unités
    • Création depuis le portail ou depuis un banc
  • Rôles et cloisonnement

    Un compte par sous-traitant : il ne voit que les produits qui lui sont affectés.

    • Rôles administrateur, fabricant et lecture seule
    • Cloisonnement appliqué aussi sur l'accès direct par URL
    • Une base de données distincte par produit
  • API REST

    Quatorze routes JSON documentées, appelées depuis n'importe quel langage de banc.

    • Authentification par token de banc à chaque appel
    • Client Python de référence fourni comme point de départ
    • Les données restent interrogeables par ASN ou par FSN

Analytics

Le rendement, pas seulement le volume

Compter les unités sorties de la ligne ne dit rien de leur coût. DFL sépare ce qui est passé du premier coup de ce qui a demandé une reprise, et de ce qui n'a jamais été terminé — trois états qui totalisent exactement 100 % des unités de la période.

L'analyse comparative met quatre semaines ou quatre mois côte à côte, avec des taux normalisés par unité produite : un mois deux fois plus chargé ne se déguise pas en dégradation de qualité.

  • Taux de réussite au premier passage, par produit et par période
  • Les unités non terminées jamais retestées, isolées du reste
  • Classement des étapes qui échouent le plus, par unité affectée
  • Tableau de bord multi-produits, une ligne par produit
  • Export PDF depuis le navigateur, sans service externe
portal.votre-usine.com/dashboard
Analyse comparative 4 semaines
Métrique S-3 S-2 S-1 Cette semaine Tendance
Terminées sans erreur 1 2041 3181 402 1 511+1,8 pp
Terminées avec reprise 968871 62−0,9 pp
Non terminées 413744 39−0,3 pp
RF_TEST — erreurs 635871 44−1,6 pp
FINAL_QC — erreurs 12914 22+0,5 pp

À surveiller : FINAL_QC se dégrade de 0,5 pp. En amélioration : RF_TEST, −1,6 pp. Données fictives.

Identité des appareils

Un identifiant unique par appareil. Jamais deux fois le même.

Les adresses MAC, numéros de série et certificats ZigBee vivent dans des pools que vous chargez à l'avance. Chaque attribution est verrouillée : deux bancs qui demandent au même instant obtiennent deux identifiants différents.

L'attribution est idempotente. Si une unité repasse sur le banc après une coupure réseau ou un test raté, elle retrouve son adresse au lieu d'en consommer une nouvelle — et un appareil à plusieurs ports obtient une adresse par port.

  • Pools MAC (EUI-64), DSN, certificats et install codes ZigBee
  • Une reprise ne brûle jamais un identifiant
  • Plusieurs identifiants par unité, un par sous-ensemble déclaré
  • Import et surveillance des pools depuis le portail
  • Pool vide : l'appel renvoie une erreur au lieu d'une adresse — à votre banc de la traiter comme un arrêt
portal.votre-usine.com/mac
Provisioning — Pools Temps réel
MAC (EUI-64)128 400 / 200 000
DSN41 250 / 50 000
Certificats ZigBee3 120 / 20 000

Derniers identifiants attribués

  • MAC70:B3:D5:2A:11:04attribué
  • DSNDSN-24W31-000428attribué
  • ZIGBEEcertificat + install codeattribué

Vue d'illustration — données fictives.

ECO et firmware

L'usine ne peut construire que ce que vous avez autorisé

Un ECO décrit une configuration de production : produit, révision, usine autorisée, firmware, données d'étiquette. Tant qu'il n'est pas ACTIVE, aucun banc ne peut l'utiliser ; une fois fermé, il ne rouvre pas.

Le firmware est attaché à l'ECO, pas au banc. Un poste ne peut donc pas flasher une version qu'il aurait gardée localement, et le firmware de production ne se remplace pas en silence.

  • Cycle de vie CREATED → ACTIVE → CLOSED, fermeture irréversible
  • Un appel de banc avec un ECO non actif est refusé
  • Le firmware est livré avec sa version et sa somme de contrôle
  • Seuls les ECO de type QA acceptent un remplacement de firmware
  • Le code usine restreint qui a le droit de produire
portal.votre-usine.com/eco/ECO-2417
ECO-2417 Configuration de production
CREATED ACTIVE CLOSED
  • ProduitUBRIDGE-200 rev. C
  • Usine autoriséeFCT-02
  • Firmwareub200-1.8.4 · sha256
  • Bancs rattachés6

Un banc ne peut produire qu'avec un ECO au statut ACTIVE.

Vue d'illustration — données fictives.

En vidéo

Voir la plateforme avant d'en parler

Quatre démonstrations courtes : ce que voit un responsable production, ce que voit un ingénieur test, et ce que fait un banc.

  • bientôt

    Découvrir Device Fabrik Link

    Le tour complet en quelques minutes : produits, bibliothèque, bancs, ECO et analytics.

  • bientôt

    Lire son rendement de production

    Premier passage, reprises, unités jamais terminées : interpréter les indicateurs et repérer l'étape qui coûte.

  • bientôt

    Connecter un banc de test

    De l'enregistrement du banc au premier ASN : l'intégration vue côté ingénieur, appel par appel.

  • bientôt

    Attribuer MAC, DSN et certificats

    Charger un pool, l'attribuer en production, surveiller ce qu'il reste et comprendre l'idempotence.

Vous préférez vos propres produits et vos propres chiffres ? Réserver une démo commentée

Pour vos équipes techniques

Un banc de test s'y raccorde en quatre types d'appel

L'API est du JSON sur HTTPS : elle s'appelle depuis Python, C#, LabVIEW ou n'importe quel script déjà en place sur vos postes. Aucun agent à installer, aucun matériel à remplacer.

Chaque requête porte l'identité du banc et l'ECO en cours. Si l'ECO n'est pas actif, l'appel est refusé — la règle de production est appliquée par le serveur, pas par la discipline de l'opérateur.

  • Quatorze routes documentées sous /v1/, réponses JSON
  • Token de banc à chaque appel et vérification MAC optionnelle
  • Client Python de référence livré comme point de départ
  • Historique interrogeable par ASN ou par numéro de série usine

Parler intégration avec un ingénieur

# 1. L'unité entre sur le banc : on obtient son ASN
curl -X GET https://votre-instance/v1/uuid \
  -H "Content-Type: application/json" \
  -d '{
    "bench": { "name": "DFL-PB-0022", "token": "..." },
    "eco":   { "ecoID": "ECO-2417" },
    "asn":   { "fsn": "SN-240731-0428" }
  }'

# -> 200 { "asn": "UB200-24W31-0428", "productRevision": "C" }
import requests

BENCH = {"name": "DFL-PB-0022", "token": TOKEN}
ECO   = {"ecoID": "ECO-2417"}

# 1. Un numéro de série unique pour l'unité qui entre
asn = requests.get(f"{DFL}/v1/uuid", json={
    "bench": BENCH, "eco": ECO, "asn": {"fsn": fsn},
}).json()["asn"]

# 2. Une adresse MAC, allouée de façon atomique et idempotente
mac = requests.get(f"{DFL}/v1/provisioning/mac", json={
    "bench": BENCH, "eco": ECO, "asn": {"asn": asn}, "subId": "eth0",
}).json()["eui64"]

# 3. Chaque étape de test est publiée avec ses mesures
requests.post(f"{DFL}/v1/step", json={
    "bench": BENCH, "eco": ECO,
    "step": {"asn": asn, "stepName": "RF_TEST",
             "stepResult": "PASS",
             "stepData": {"rssi_dbm": -41.2, "channel": 36}},
})

Extrait illustratif — la référence complète est livrée avec la plateforme.

Sécurité et déploiement

Vos données de production restent chez vous

DFL s'installe sur votre infrastructure ou dans un cloud privé. Aucune donnée de production n'a besoin de sortir de votre périmètre.

  • HTTPS de bout en bout

    Le portail comme l'API des bancs ne démarrent qu'en TLS, avec vos propres certificats.

  • Un token par banc

    Chaque poste possède son secret ; il peut être verrouillé à l'adresse MAC de la machine et révoqué seul.

  • Restreint à vos réseaux

    L'API des bancs est un service HTTPS standard : limitez-la aux réseaux de vos usines au niveau de votre pare-feu ou de votre reverse proxy.

  • Verrou par ECO

    Un ECO non actif bloque la production : la règle est appliquée côté serveur, à chaque appel.

  • Isolation par produit

    Chaque produit dispose de sa propre base de données ; l'affectation par fabricant cloisonne les accès.

  • Chez vous, sans dépendance

    Portail, API et base tournent sur vos serveurs ; les secrets de configuration sont chiffrés au repos.

Selon votre rôle

Une plateforme, quatre lectures différentes

Le même enregistrement sert la production, la qualité, l'ingénierie de test et votre sous-traitant.

  • Production

    Voir la ligne sans attendre le rapport

    • Volume produit et rendement du jour
    • Bancs silencieux repérés par leur dernier accès
    • Comparaison directe entre semaines ou entre mois
  • Qualité

    Prouver, pas affirmer

    • Dossier complet de chaque unité en cas de retour
    • Étapes les plus défaillantes, classées par unité affectée
    • Unités de référence exclues des statistiques
  • Ingénierie de test

    Instrumenter une fois, exploiter partout

    • Mesures libres attachées à chaque étape
    • Toutes les tentatives conservées, reprises comprises
    • Une API stable plutôt qu'un export maison
  • Sous-traitant

    Livrer la preuve avec les cartons

    • Un accès limité aux produits qui vous sont confiés
    • Le donneur d'ordre voit les mêmes chiffres que vous
    • Plus de rapport à reconstruire à la main

Démonstration

Voyons ce que ça donnerait sur votre production

Trente minutes, en visioconférence : vous décrivez votre ligne et vos bancs, nous montrons la plateforme sur un produit proche du vôtre et nous répondons franchement sur ce qui demanderait du développement chez vous.

Nous répondons rapidement, en général sous deux jours ouvrés. Pas de séquence commerciale automatique.

Aucun engagement, aucune installation requise pour la démonstration.

Demande envoyée.Merci — nous revenons vers vous rapidement avec une proposition de créneau.

Questions fréquentes

Ce que les fabricants nous demandent

Traçabilité, intégration, déploiement, données : les réponses sans détour.

Qu'est-ce que Device Fabrik Link, exactement ?
DFL est une plateforme MES (Manufacturing Execution System) spécialisée dans la traçabilité unitaire, le contrôle qualité et le provisioning d'appareils électroniques. Elle se compose d'un portail web pour vos équipes et d'une API REST que vos bancs de test appellent pendant la production. Chaque unité fabriquée y possède un dossier complet : étapes réalisées, résultats, mesures, reprises, banc utilisé et identifiants attribués.
En quoi est-ce différent d'un ERP ou d'un tableur partagé ?
Un ERP raisonne en ordres de fabrication et en quantités ; DFL raisonne en unités individuelles et en étapes de test. Un tableur, lui, ne sait ni empêcher un doublon d'adresse MAC, ni refuser une révision obsolète, ni conserver les tentatives ratées. DFL n'est pas un ERP et ne gère ni les stocks, ni l'ordonnancement : il documente et contrôle ce qui se passe sur le banc.
Faut-il remplacer nos bancs de test existants ?
Non. Vos bancs gardent leur logiciel ; ils appellent simplement l'API DFL en HTTPS/JSON aux moments clés — obtention du numéro de série, téléchargement du firmware, attribution des identifiants, publication de chaque étape. L'intégration se fait dans le langage déjà utilisé sur le poste, et un client Python de référence est fourni comme point de départ.
Peut-on l'héberger sur nos propres serveurs ?
Oui. Le portail, l'API et la base de données s'installent sur votre infrastructure ou dans un cloud privé, derrière votre reverse proxy. Les deux services ne démarrent qu'en HTTPS avec vos certificats, et les secrets de configuration sont chiffrés au repos. Vos données de production n'ont pas besoin de sortir de votre périmètre.
Qu'est-ce qu'un ECO et pourquoi conditionne-t-il la production ?
Un ECO (Engineering Change Order) fige une configuration de production : produit, révision, usine autorisée, firmware associé, données d'étiquette. Son cycle de vie est CREATED → ACTIVE → CLOSED, et seul le statut ACTIVE autorise un banc à produire. C'est ce verrou qui empêche une usine de continuer à construire une révision que vous avez arrêtée.
Comment sont gérés les adresses MAC, numéros de série et certificats ?
Vous chargez des pools d'identifiants — MAC (EUI-64), DSN, certificats et install codes ZigBee — et le banc en demande un au moment voulu. L'attribution est atomique : deux bancs simultanés ne peuvent pas recevoir le même identifiant. Elle est aussi idempotente : une unité qui repasse après un échec retrouve son identifiant au lieu d'en consommer un nouveau, et un appareil à plusieurs ports reçoit un identifiant par port.
Notre sous-traitant peut-il accéder à la plateforme sans voir nos autres produits ?
Oui. Un utilisateur rattaché à un fabricant ne voit que les produits qui lui sont affectés, dans les listes comme en accès direct par URL — une tentative d'accès à un autre produit est refusée. Chaque partenaire peut donc consulter sa propre production et ses propres bancs, sans jamais voir ceux des autres.
Que se passe-t-il si le réseau tombe pendant la production ?
Les bancs communiquent avec DFL par appels REST : sans réseau, un appel échoue et votre logiciel de banc doit le gérer. Nous recommandons donc de bufferiser localement les étapes et de les rejouer au retour du lien — l'attribution des identifiants étant idempotente, une reprise ne consomme pas de ressource supplémentaire. Ce comportement se conçoit lors de l'intégration, et nous en parlons pendant la démonstration.
Peut-on exporter ou réinterroger les données ?
Il n'existe pas d'export en masse aujourd'hui. Trois choses le remplacent : un banc peut récupérer tout l'historique d'étapes d'une unité par son numéro de série usine via l'API ; les vues filtrées de la bibliothèque et le tableau de bord multi-produits s'exportent en PDF depuis le navigateur ; et comme chaque produit a sa propre base MongoDB sur vos serveurs, votre historique de production reste directement interrogeable et vous appartient.
Combien ça coûte, et combien de temps pour démarrer ?
Contactez-nous : nous chiffrons chaque déploiement au cas par cas, sans grille automatique ni offre en libre-service. Dites-nous ce que vous fabriquez, combien d'unités par an et comment vous souhaitez l'héberger, et nous établissons une proposition. Le délai de démarrage dépend surtout de vos bancs — déclarer un produit, son pipeline et un ECO prend un après-midi ; instrumenter un banc dépend de son logiciel existant.

Reprenez la main sur ce que votre usine fabrique

Une démonstration de trente minutes suffit pour savoir si DFL correspond à votre production. Nous vous dirons franchement si ce n'est pas le cas.