Murphy existe. Je l’ai rencontré. En particulier lors des deux déploiements de prototypes effectués au Muséum, pour les expositions labelbetes et frontières.
L’épreuve du terrain permet aujourd’hui de tirer quelques leçons des sur les bonnes pratiques à mettre en place pour développer des "prototypes" de production : comment rendre les ensembles informatiques/électroniques développés à ERASME plus robustes et fiables afin de pouvoir les déployer dans la confiance et la sérénité...
L’environnement
Déployer des équipements destinés au public en production c’est faire face à un environnement hostile :
– le public (en particulier les enfants) n’hésite pas à toucher tout ce qui est à sa portée
– le personnel manipule du matériel habituellement robuste, et ne prendra pas forcément de gants pour déplacer les prototypes
– les élements ERASME représentent une partie généralement marginale, en volume, d’une exposition ; les équipes techniques du muséum ne pourront accorder qu’un temps limité à ces équipements,
– les sous-traitants n’ont d’autre intérêt que leur propre installation, ils pourront piétiner votre capteur sans aucun remord
– le personnel d’entretien n’a pas forcément conscience que l’eau et l’électricité ne font pas bon ménage,
– les concepteurs d’expo, qui peuvent au dernier moment modifier la position d’un capteur ou d’un élément.
Les "autres" ne sont pas le seul élément hostile de l’environnement.
Les expositions au public ont des contraintes qui sont antinomiques avec une mise en prodution sereine :
– élements électriques cloisonnés, induisant un problème de refroidissement et d’accès en cas de panne
– moyens limités pour l’extinction et la mise en route (on appuie sur un bouton, pas plus)
– mobilier parfois inamovible, en particulier lorsque l’exposition est en phase publique
Les interventions sur les interactifs lorsque l’exposition passe en phase publique sont donc délicates, et doivent être réduites au strict minimum.
Il faut aussi être prêts à manier perceuse, agrafeuse, pince coupante et tournevis [1], afin d’être autonomes lors du déploiement ou de la maintenance.
Design
– KISS
Sur le "design" des équipements et des ensembles, il est une règle qui ne se dément pas : le principe KISS [2]. "KISS" c’est l’opposé de l’usine à gaz : faire simple, rester simple, afin que le système n’atteigne pas une masse critique impossible à manager et a debugger.
C’est valable aussi bien pour le code que pour le matériel.
– Robustesse des composants
Les circuits gravés maison soufffrent souvent d’un manque de robustesse. Il conviendra de graver des pistes les plus large possible avec des pads les plus gros possibles, ou de privilégier les cartes de prototypage type Olimex.
Ces cartes permettent de s’affranchir d’un certain nombre de détails récurrents liés au hardware : régulation de l’alimentation, prise de programmation in-line, quartz, mise à niveau de la liaison série, ... pour un coût quasi-nul (15€-25€ hors µcontrolleur), en tout cas bien inférieur à ce que serait une création maison.
Par ailleurs, il faut éviter autant que possible les soudures de fil directement sur circuit : les contraintes mécaniques infligées au fil provoqueront forcément un décollement de la piste.
– Tolérance de panne
Dans la mesure du possible, le dysfonctionnement d’un élément de la chaine devra impacter a minima le fonctionnement de l’interactif. Il est évidemment impossible d’avoir une tolérance aux pannes globale ; en revanche, il faudra qu’un fontionnement en mode dégradé soit possible. Dans le pire des cas, il faudra veiller à ce que le dysfonctionnement ne saute pas aux yeux à la place du contenu à produire, type BSOD ("Ecran bleu de la mort, windows") au milieu de la foule..
Pour l’expo labelbêtes, la destruction du capteur entrainait la diffusion en boucle de l’interactif.
Avec les microcontrolleurs, il conviendra d’utiliser le watchdog, qui permet de faire un "self-reset" en cas de blocage.
– Monitoring des dispositifs
Les élements déployés comprennent souvent un PC. Les lieux d’exposition étant en général équipés du réseau, il est souhaitable de pouvoir accéder aux machines à distance, tout en veillant qu’une prise en main à distance n’interfère pas avec la diffusion (ssh est idéal).
– Disponibilité des composants
Les montages & interactifs livrés devront être remplaçables en cas de défaillance. Cela implique d’avoir du "spare", sur le lieu d’exposition si possible.
Avoir du spare implique aussi d’utiliser des composants "du marché", et d’éviter les composants "personnels" récupérés de ci de là.
Cet aspect est contradictoire avec le fonctionnement des achats : acheter des composants est un processus qui prend environ deux mois, et dans les deux expositions cités, les délais de conception/prototypage/déploiement étaient inférieux à ces deux mois.
De l’utilisation des microcontrolleurs
L’utilisation de µcontrolleurs possède d’énormes avantages :
– minimisation du "hard" au profit du "soft", plus facile à gérer (pas de ’Ctrl-Z’ sur le hard)
– paramétrage plus simple
– réutilisation possible
– diagnostics souvent plus aisés
– pilotage facile depuis un PC
– coût négligeable
En revanche, les µcontrolleurs ne suppriment pas les contraintes IHM classiques.
En effet, ces µcontrolleurs contiennent non seulement des programmes, qu’il faut peut être remplacer, mais aussi des "paramètres", qu’il faut ajuster sur le terrain.
Or, déployer une carte de développement STK500 et un PC avec l’environnement de développement entre deux portes ou au milieu d’un escalier est non seulement malaisé, mais en plus dangereux pour le matériel.
Le µcontrolleur possédant une EEPROM, il est possible de conserver des paramètres à chaque redémarrage.
Il faut donc prévoir quelques éléments afin d’éviter d’en arriver là :
– éléments de saisie
Il faut accompagner les développements d’élements de saisie numériques (boutons) ou analogiques (potentiomètres), permettant d’ajuster des paramètres dans le circuit. Par ailleurs, le capteur lui-même peut-être utilisé comme périphérique de saisie.
Par exemple, sur les capteurs de distance Sharp GPD, on pourrait imaginer un bouton permettant de demander un calibrage, suivi d’une détection sur le capteur à la distance à laquelle on veut que le dernier se déclenche.
– élements de sortie
L’élément le plus "pratique" du point de vue interface, c’est l’écran LCD/OLED (type 2 lignes x 20 caractères).
En revanche, ce type d’écran est relativement gros, et nécessite d’être protégé car particulièrement fragile. Par ailleurs, il consomme 7 E/S sur le µcontrolleur.
Une version frustre mais très utile d’affichage alphanumérique est l’afficheur 7-segments.
Bien que mono caractère, il permet d’afficher n’importe quel caractère et consomme entre 4 (chiffres uniquement via un décodeur 4511) et 7 E/S sur le µcontrolleur.
Ces éléments d’IHM pourront par ailleurs servir pour du diagnostic pour le personnel technique sur place.
Enfin, on évitera de déployer des versions hard trop différentes : des prototypes similaires mais avec un brochage différent sont un vrai casse-tête à reprogrammer sur le terrain (Cf. expo frontières).
Code
En ce qui concerne le code (que ce soit sur µcontrolleur ou sur PC), le principe "KISS" s’applique aussi.
Dans le cas de l’assembleur sur µcontrolleur, il est vivement recommandé d’avoir recours à des directives .DEFs et .EQUs afin de pouvoir adapter le code en fonction de la situation. Pour "frontières" par exemple, l’utilisation des pattes du µcontrolleur était différente entre le premier prototype et les deux autres. Les firmware produits n’étaient donc pas compatibles d’un matériel à l’autre.
Equipement
En cas de panne, il est très difficile d’obtenir un diagnostic à distance, en particulier si aucune IHM n’a été prévue en ce sens.
Même si les équipes techniques possèdent un matériel important, celui-ci n’est pas tout le temps disponible ; par ailleurs, il vaut mieux apporter son fer à souder et sa soudure que d’emprunter celui du voisin.
Le minimum à prévoir rentre facilement dans une sacoche de portable :
– Fer, étain, tresse à déssouder
– Multimètre
– Carte de développement STK500 + alimentation
– Téléphone portable
– Composants de rechange (en particlier µcontrolleur)
