Intervention express

Ingénierie de systèmes embarqués et IoT, du firmware à la supervision.

Imaginez un appareil fixé au fond d'une armoire électrique, que personne ne reverra avant des années et qui doit faire son travail chaque jour sans qu'on lui demande rien. Le logiciel qui vit à l'intérieur et qui le relie au reste de votre activité, c'est ce que nous écrivons et ce que nous vous remettons, testé sur votre matériel, avec son code source et sa documentation.

Parler de votre équipement

Un ordinateur que personne ne regarde

Un système embarqué est un petit ordinateur enfermé dans un équipement pour y tenir un seul rôle : un compteur qui mesure, un automate qui pilote une ligne, un boîtier qui surveille une cuve. Il n'a ni clavier ni personne devant lui. Il démarre seul et doit tenir des années, souvent avec moins de mémoire qu'une seule photo sur votre téléphone.

Le firmware, c'est le logiciel logé là-dedans. Il lit les capteurs, commande les moteurs et les relais, surveille ses propres erreurs. Écrire pour une telle puce ne ressemble pas à écrire une application, parce que chaque octet est une décision et qu'une fonction de plus peut prendre la place d'une mesure à conserver. Et quand le programme se bloque, personne n'est là pour redémarrer la machine : il faut avoir prévu dans le code comment elle se relève. Nous aimons ce travail pour cette exigence. L'IoT, ou Internet des objets, ajoute un réseau par-dessus, pour suivre, configurer et mettre à jour ces équipements à distance.

Pour ce firmware, nous proposons d'abord le C++ embarqué, et c'est un choix raisonné. Il laisse décider précisément de ce qui occupe la mémoire et du moment où le code s'exécute, il existe pour la plupart des microcontrôleurs, et il permet de faire évoluer le code déjà en place au lieu de repartir de zéro. Rust le complète quand il apporte quelque chose, par exemple pour un composant neuf exposé au réseau, si la puce retenue s'y prête.

Une limite, dite franchement. Codetics écrit le logiciel. Le dessin des cartes électroniques, l'électronique de puissance, les fonctions de sécurité des machines et la certification sont d'autres métiers, avec d'autres responsabilités : ils demandent un périmètre distinct et des partenaires spécialisés. Nous préférons vous le dire au premier échange plutôt que de le découvrir ensemble au milieu du projet.

Fig. 02Contrôleur connecté
Contrôleur connectéCTRL / REV. AMCUCTRL / 24 V DC
Assemblé

Le boîtier et ses entretoises maintiennent et protègent le circuit. Le modèle exclut l'électronique de puissance.

Contrôleur basse tension pédagogique : boîtier aluminium, carte fixée sur entretoises, microcontrôleur, alimentation, bornier et interface réseau. Ce modèle n'est pas un schéma de fabrication.

Du premier démarrage de la carte au parc en service

Un projet embarqué se joue à plusieurs étages, et vous n'avez pas forcément besoin de tous. Vous pouvez nous en confier un seul, par exemple le firmware d'un produit dont votre équipe garde le reste, ou l'ensemble.

Firmware et C++ embarqué

Nous pouvons écrire le firmware en C++, avec du C quand un pilote ou le kit du fabricant de la puce l'impose, et du Rust là où il aide. Une habitude à laquelle nous tenons : le code qui touche au matériel reste à part, loin de la logique de l'appareil. Le jour où un composant devient introuvable et qu'il faut le remplacer, la reprise porte surtout sur cette partie-là.

  • Développement d'un firmware neuf
  • Reprise et stabilisation d'un firmware existant
  • Firmware en C++ embarqué
  • Rust embarqué, quand la cible s'y prête
  • Pilotes : le code qui dialogue avec chaque composant

Microcontrôleurs et ressources matérielles

Un microcontrôleur réunit sur une seule puce un petit processeur, sa mémoire et ses entrées-sorties, ces broches par lesquelles il touche le monde réel. Tout y est compté. Une fuite de mémoire qui passerait inaperçue sur un ordinateur finit ici par bloquer l'appareil, parfois au bout de plusieurs semaines, et c'est pour cela qu'elle est si difficile à attraper. Nous concevons donc le logiciel autour de ces limites, et nous mesurons sur la cible ce qu'il consomme vraiment.

  • Conception logicielle pour microcontrôleur
  • Gestion des ressources matérielles et des périphériques
  • Optimisation de la mémoire et des performances
  • Maîtrise de la consommation d'énergie
  • Intégration du logiciel et du matériel, à partir de vos schémas et fiches techniques

IoT et connectivité

Le réseau finira par tomber, et un équipement bien écrit s'y attend. Il continue son travail, garde ses mesures de côté et les renvoie quand la connexion revient, sans que personne ait à intervenir. Nous écrivons ce comportement, et aussi la passerelle qui relie vos machines à votre réseau et à vos logiciels.

  • Communication entre équipements
  • Passerelles entre machines et logiciels
  • Fonctionnement défini en cas de coupure réseau
  • Collecte des mesures envoyées par les équipements

Protocoles industriels

Un protocole, c'est la langue que deux équipements parlent pour se comprendre, et les machines d'un même atelier en parlent rarement une seule. Notre réflexe est de partir de celle qu'elles utilisent déjà. Changer de protocole parce qu'un autre paraît plus moderne coûte cher, et n'apporte souvent rien à celui qui regarde ses machines.

  • MQTT : envoyer des messages légers d'un appareil vers un serveur, même sur un réseau instable
  • Modbus : lire et écrire les valeurs d'automates, de compteurs et de capteurs, un standard ancien et très répandu
  • OPC UA : échanger des données structurées entre machines et logiciels de fabricants différents
  • CAN : faire dialoguer les modules électroniques d'une machine ou d'un véhicule sur un câble commun

Sécurité et mises à jour à distance

Envoyer une mise à jour à un appareil posé au milieu d'un champ fait peur, et c'est une peur saine. Si elle échoue à mi-chemin, l'appareil peut ne plus démarrer, et il faut alors envoyer quelqu'un sur place, parfois pour chaque appareil. Une mise à jour à distance bien conçue, dite OTA (over the air), garde donc l'ancienne version à côté de la nouvelle : si la nouvelle échoue, l'appareil revient à la précédente. Avec ce chemin de retour, on ose enfin corriger. La sécurité se pense au même endroit, avec deux questions : qui a le droit de parler à l'appareil, et quel logiciel il accepte d'exécuter.

  • Mises à jour à distance avec retour en arrière
  • Vérification de l'origine des mises à jour
  • Identification des équipements et chiffrement des échanges
  • Réduction des accès ouverts sur l'appareil

Diagnostic et supervision

Quand un équipement se comporte mal à l'autre bout du pays et qu'il n'a rien enregistré, il ne reste que le récit de la personne sur place et un déplacement. Nous prévoyons donc des journaux lisibles et un logiciel de supervision attentif à une différence trop souvent oubliée. Avoir envoyé l'ordre d'ouvrir une vanne ne dit pas que la vanne est ouverte : la mesure, la commande demandée et l'état confirmé par l'équipement sont trois choses distinctes.

  • Journaux et codes d'erreur exploitables
  • Outils de configuration et de maintenance
  • Supervision d'un parc d'équipements, avec alertes
  • Comportement défini à la reconnexion

Un firmware qui se comporte bizarrement ?

Un appareil qui redémarre sans raison apparente, un bug qui ne se montre qu'une fois par semaine. Nous pouvons déboguer ce genre de problème à distance, selon l'accès possible et le matériel disponible. Le périmètre est validé avant de commencer, et si le vôtre demande le matériel sur place, nous vous le disons. Prix fixe, dès 149 € pour un diagnostic. TVA non applicable, art. 293 B du CGI.

Obtenir une intervention express

Des machines d'atelier aux instruments de mesure

Ce sont des exemples de ce qui peut se construire dans chaque secteur, et non une liste de clients. Votre équipement ressemble peut-être à l'un d'eux, ou à aucun, et la discussion part de lui.

  • Industrie

    Il arrive que quelqu'un relève encore à la main des valeurs que les machines savent pourtant donner. Une passerelle peut les lire en Modbus ou en OPC UA et les envoyer à vos logiciels, sans remplacer ces machines.

  • Automatisation

    Le logiciel d'un boîtier de commande ou d'une séquence de pilotage, où chaque état, chaque erreur et chaque reprise est écrit avant de devenir une surprise. Les fonctions de sécurité machine restent hors de ce périmètre.

  • Équipements professionnels connectés

    Vous vendez ou louez un appareil, et le premier signe de panne, c'est l'appel du client. Avec le bon firmware et une liaison réseau, vous suivez votre parc à distance, vous envoyez une mise à jour, et vous pouvez repérer le problème sans attendre ce coup de fil.

  • Électronique et objets intelligents

    Votre équipe ou votre bureau d'études dessine la carte, nous écrivons ce qui la fait vivre, du prototype qui démarre pour la première fois jusqu'à une version que l'on peut maintenir. Une application de configuration peut s'y ajouter si besoin.

  • Systèmes de mesure

    Une mesure manquante se rattrape rarement. Un instrument ou un enregistreur peut relever ses capteurs à intervalle régulier, garder ses données pendant une coupure et les transmettre ensuite, avec une logique prévue pour éviter les doublons et les trous dans la série.

  • Véhicules et mobilité électrique

    Un secteur parmi les autres, avec ses propres langues : firmware et communication CAN dans un véhicule, supervision de bornes de recharge en OCPP, le protocole standard entre une borne et son serveur.

C++ d'abord, et les bonnes raisons de s'en écarter

Le bon langage dépend de votre puce et du code que vous avez déjà. Nous ne toucherons pas à un firmware qui marche pour le plaisir d'un langage plus récent.

  • C++

    Le langage que nous proposons d'abord pour le firmware. Il vous laisse décider de ce qui occupe la mémoire et du moment où le code s'exécute, et il est disponible sur la plupart des microcontrôleurs.

  • C

    Il reste partout : dans les pilotes, dans les kits des fabricants de puces, dans le code existant qu'il faut reprendre.

  • Rust

    Une erreur de mémoire peut dormir des mois avant de bloquer un appareil. Pour un composant neuf où elle coûterait cher, si la puce s'y prête, Rust a un grand mérite : l'outil qui transforme le code en programme refuse une grande partie de ces erreurs dès l'écriture.

  • MQTT, Modbus, OPC UA, CAN

    Les langues de vos équipements, retenues d'après ce que vos machines utilisent déjà.

  • Rust, Java ou C# côté serveur

    Là où les données des équipements arrivent et deviennent lisibles pour vos équipes, dans le logiciel de supervision.

De vos schémas au firmware qu'on vous remet

  1. 01

    Comprendre la cible

    Nous commençons par lire vos schémas, vos fiches techniques et le code existant. Puis nous fixons avec vous l'accès au matériel, les limites de ressources, et surtout ce que l'appareil doit faire quand quelque chose va mal, une question qu'on repousse trop souvent.

  2. 02

    Séparer le matériel de la logique

    L'architecture isole les accès au matériel. Une partie du code peut alors être testée sans la carte, ce qui évite bien des allers-retours quand celle-ci est rare ou pas encore fabriquée.

  3. 03

    Valider sur le vrai matériel

    Un firmware qui marche quand tout va bien n'a encore rien prouvé. Nous le poussons sur le matériel retenu là où il peut casser : erreurs, limites de mémoire, réseau coupé, mises à jour, selon des scénarios convenus avec vous.

  4. 04

    Vous remettre le tout

    Selon le devis, vous recevez le code source, la procédure pour reconstruire le firmware, les scénarios de validation, les outils de diagnostic et la documentation. Un firmware que seul son auteur sait reconstruire est une dette, et nous ne voulons pas vous la laisser.

Quand l'équipement roule ou se recharge

Un serveur bien réel, un contrôleur pédagogique

Autant être franc sur ce que vous voyez. Ce contrôleur est un modèle pédagogique basse tension : il sert à montrer comment un équipement est organisé, et ce n'est ni un schéma de fabrication ni un équipement client. Le reste se consulte.

Trois façons de commencer sur votre firmware

Projet firmware

5 000 à 30 000 €, à titre indicatif

Écrire ou reprendre le firmware d'un équipement, avec le code source, les scénarios de test et la documentation. Le prix exact suit un devis écrit, selon le matériel et le périmètre. TVA non applicable, art. 293 B du CGI.

Envoyer un brief

Intervention express

Dès 149 €

Un diagnostic ou un débogage à distance sur un problème précis, à prix fixe, selon l'accès et le matériel disponibles. TVA non applicable, art. 293 B du CGI.

Voir l'intervention express

Journée de conseil senior

900 €

Une journée pour trancher un choix d'architecture, de protocole ou de langage, ou pour faire relire un firmware. TVA non applicable, art. 293 B du CGI.

Voir la journée de conseil

Questions fréquentes

Oui, selon ce que le projet demande. L'accès au matériel se convient projet par projet, par exemple une carte de développement envoyée ou un accès à distance à votre banc de test, si l'une de ces options vous convient. Une partie du code peut être testée sans la carte. La validation finale, elle, doit se faire sur le vrai matériel, parce qu'une puce réelle a des comportements qu'aucune simulation ne montre. Nous convenons avec vous, avant de commencer, de qui la réalise et comment.

Non, et nous préférons le dire tout de suite. Codetics écrit le logiciel. Le dessin de la carte, l'électronique de puissance et la fabrication relèvent de votre équipe, de votre bureau d'études ou de partenaires spécialisés. Nous travaillons à partir de leurs schémas et fiches techniques. Parler tôt avec eux de la mémoire, des entrées-sorties et de l'accès pour le débogage peut éviter de refaire une carte pour un détail oublié.

Nous ne tenons pas de liste fermée. Ce qui compte vraiment, c'est que la puce ait une documentation disponible, des outils de compilation et un moyen de déboguer. Si vous avez déjà choisi la vôtre, indiquez-la dans votre brief : nous vous dirons avant tout devis si nous pouvons travailler dessus. Si le choix reste ouvert, une journée de conseil est un bon moment pour y réfléchir ensemble.

Codetics ne certifie pas de produit et ne détient pas de certification de ce type. Les fonctions de sécurité des machines et les essais de qualification demandent un périmètre distinct et des partenaires spécialisés. Notre part, c'est le logiciel, les tests et la documentation dont ce travail aura besoin. Parlez-nous-en dès le départ : nous devons connaître ces exigences avant d'écrire la première ligne, car les découvrir à la fin peut obliger à beaucoup reprendre.

Oui, et cette peur est plus saine qu'elle n'en a l'air. Elle dit souvent que le firmware marche et que plus personne ne sait pourquoi. Nous ne commencerons pas par tout réécrire, car ce vieux code contient peut-être des années de corrections dont personne ne se souvient. Nous le lisons, nous repérons ce qui le rend fragile, puis nous ajoutons des tests et des outils de diagnostic pour pouvoir le modifier sans casser le reste. Pour une première réponse sur un problème précis, l'intervention express commence à 149 €, TVA non applicable, art. 293 B du CGI.
Projet logiciel

Racontez-nous ce que fait votre appareil.

Ce qu'il fait, la puce qu'il utilise si vous la connaissez, ce qui vous inquiète. Nul besoin d'un cahier des charges. Nous vous répondons avec ce que nous pouvons faire, ce qui relève d'un autre métier, et un prix.

  1. 01Vous décrivez le besoin
  2. 02Nous clarifions le périmètre
  3. 03Vous recevez un devis détaillé
Discuter d'un projet

Que voulez-vous réaliser ?

Choisissez ce qui s'en rapproche le plus : le brief s'ouvrira sur ce sujet, et nous préciserons ensemble.

  • Un périmètre clarifié
  • Un devis détaillé
  • Un échange direct avec l'ingénieur