Journal Mettre à jour l'embarqué

Posté par (page perso) . Licence CC by-sa.
6
29
nov.
2018

Dans la release de l'émission CPU (Carré Petit Utile) de cette semaine : Un appareil bien installé, une connexion réseau, une mise à jour système et un mode recovery bienvenu.

C'est bien beau, l'informatique embarquée connectée (ou IoT pour faire genre), mais dans “informatique”, il y a “mettre à jour”. Et la mettre à jour peut tourner au casse-tête.

Pierre-Jean Texier, ingénieur en systèmes embarqués, en parle à notre micro.

  • # Conférence sur le même thème aux Embedded Recipes

    Posté par . Évalué à 2. Dernière modification le 29/11/18 à 12:48.

    En complément vous pouvez regarder la conférence de Charles-Antoine Couret aux Embedded Recipes de 2018.

    Pour y avoir assisté, je l'avais trouvée très pertinente et claire dans ces explications des différents types de mises à jour avec chacune leurs avantages et inconvénients.

  • # Pas forcément un casse tête

    Posté par (page perso) . Évalué à 10.

    Je travaille également dans le milieu et j'ai aussi fait une conférence à ce sujet, en anglais seulement. En montrant une stratégie qu'on peut mettre en place pour les produits embarqués.

    Pour résumer un peu le topo, car devoir écouter une heure de conf sans savoir en avance ce qu'il y a dedans cela peut être contraignant.

    En fait mettre à jour un système embarqué est relativement simple à mettre en place. Mais disons que tout dépend des contraintes. Car si on peut faire ça simplement, il faudra un matériel un peu plus cher, des développeurs qui bossent bien sur la question (pas de MaJ à l'arrache) et accepter le coût en bande passante associée.

    Mais la question de MaJ des systèmes embarqués n'est pas tellement plus complexe que de mettre à jour un PC. Mettre à jour à chaud son système comme on le fait sur Linux traditionnellement est une aberration car à la moindre coupure de courant au mauvais moment et paf le système peut être cassé (et si on vit dans un pays où l'électricité n'est pas fiable comme en Inde, c'est gênant). Les méthodes de mises à jour hors ligne, à la Windows, macOS ou GNOME Logiciels est plus sûr à cet égard. Même si c'est décrié car le redémarrage prend beaucoup de temps.

    Pour faire une MaJ on va privilégier des méthodes de MaJ qui essayent de concilier prix / temps d'indisponibilité / robustesse selon le cas d'usage que l'on a. Mais ce choix est valide aussi bien pour PC que pour l'embarqué.

    Le vrai problème de l'embarqué à ce sujet est plus culturelle que technique. Maintenir un système à jour dans le temps (disons 20 ans) demande une équipe qui bosse sur le sujet tout le temps. Car il faut corriger les bogues (notamment de sécurité) sur la durée de vie du produit. Cela demande du temps et des compétences pour gérer cet aspect qui est pourtant toujours oublié. D'autant qu'il est rare qu'upstream ou le fournisseur du BSP du SoC (le Yocto ou buildroot) maintiennent aussi longtemps le produit de ce côté là.

    L'autre problème, en embarqué il y a beaucoup d'entreprises qui ont la politique du vendu et oublié. Le produit est développé jusqu'à sa commercialisation, après maintenance minimale voire absente. Car à cause de la contrainte plus haut, la maintenance coûte chère et sur une longue durée. Or le produit n'étant vendu qu'une fois, il faut prévoir correctement le coût de maintenance lors de la vente. Sinon c'est cuit.

    Enfin, le soucis aussi est l'absence de compromis. On veut que la MaJ soit fiable, pas chère, prenne très peu de ressources, etc. Du coup faute de compromis on aboutit souvent à une situation insatisfaisante pour le consommateur. MaJ trop peu fréquentes, plus de problèmes apportés que corrigés faute d'un suivi ou de tests à la hauteur, etc.

    Je trouve que dans l'industrie PC ces biais culturels existent moins. Du coup le problème semble absent. Pourtant je vous assure que mettre à jour un OS comme Windows ou Fedora sur PC a dans l'ensemble beaucoup en commun avec la mise à jour d'un système embarqué. Et il suffit de voir les procédures en place dans ces équipes pour réaliser à quel point le sujet est souvent sous estimé de l'extérieur.

    • [^] # Re: Pas forcément un casse tête

      Posté par (page perso) . Évalué à 1.

      Si vous avez du contenu intéressant, notamment les conférences, n'hésitez pas à les mettre en commentaire du billet de l'émission sur le site !

      Cela servira à d'autres (notamment ceux qui utilisent Windows 10 CE krr krr krr)

    • [^] # Re: Pas forcément un casse tête

      Posté par . Évalué à 4.

      Mettre à jour à chaud son système comme on le fait sur Linux traditionnellement est une aberration car à la moindre coupure de courant au mauvais moment et paf le système peut être cassé (et si on vit dans un pays où l'électricité n'est pas fiable comme en Inde, c'est gênant).

      sans aller si loin (dans mon cas, en France) un constructeur automobile (de renommée international, réputé pour la fiabilité de ces modeles) a fait une mise à jour de son calculateur.

      Le garagiste m'a fait venir au garage, cous en faites pas monsieur, ca prend une heure maxi,
      je suis donc resté sur place… 2h
      pour repartir en tramway car la mise à jour s'etait mal passée et le calculateur n'a pas aimé (brick) necessitant d'en commander un nouveauce qui a pris 10 jours.

      alors coupure de courant, ou simple debranchement du cable qui relie la source à la destination de la mise à jour,
      il faut penser à tout quand on bosse dans l'embarqué

      • [^] # Re: Pas forcément un casse tête

        Posté par . Évalué à 9.

        double banque, bootloader qui vérifie la signature avant de booter, backup de la version précédente… il existe bcp de solutions pas complexes et très fiables.

        là je bosse justement sur la mise à jour à distance des calculateurs automobile, la difficulté est largement plus dans la gestion de la flotte (quel véhicule à été mis à jour ? quel véhicule est resté sur l'ancienne version ? sur quels véhicules la campagne a échoué et pourquoi) que dans la mise à jour elle-même.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Pas forcément un casse tête

          Posté par (page perso) . Évalué à 6.

          Pour expliciter un peu la notion qui peut être inconnue au commun des geeks: double banque == deux jeux de partitions: le système en cours tourne sur le jeu X, le nouveau système est flashé sur le jeu Y.
          Lorsqu'on reboote sur le jeu Y pour appliquer la mise à jour, si ça se vautre, hop, on revient sur le jeu X pour revenir à l'ancien système.
          On conserve ainsi une image "working" sur laquelle on peut revenir en cas d'erreur.

        • [^] # Re: Pas forcément un casse tête

          Posté par . Évalué à 1.

          double banque, bootloader qui vérifie la signature avant de booter, backup de la version >précédente… il existe bcp de solutions pas complexes et très fiables.

          C'est vrai que les solutions existent, généralement à base de double banque pour pouvoir redémarrer sur la version précédente en cas d'échec de la MAJ. Par contre ça signifie 2 fois plus de ROM que "nécessaire", ce qui ne passe pas toujours lors des phases de réduction de cout, sur des très petits systèmes.

          • [^] # Re: Pas forcément un casse tête

            Posté par (page perso) . Évalué à 5.

            Une autre voie est d'avoir un système minimal qui ne s'occupe que de l'étape de la mise à jour. Comme ça en cas d'échec tu as toujours de quoi mettre à jour le produit. Cela prend moins de place.

            Mais bon, dans ce cas l'indisponibilité peut être longue (tant que tu mets à jour, ton produit n'est pas utilisable) et mettre à jour ce système minimal est risqué donc déconseillé ce qui rend la sécurité et l'évolutivité du dispositif plus délicat.

            Ou alors tu as des systèmes à base de snapshot comme os-tree qui semblent prometteurs mais ce n'est pas encore très répandu et le retour d'expérience reste faible sur le sujet.

            Bref, niveau solutions techniques, nous avons des solutions assez éprouvées et connues. Mais comme tout problème d’ingénierie, faut trouver le bon compromis pour son projet. On ne peut pas tout avoir en même temps. :)

            • [^] # Re: Pas forcément un casse tête

              Posté par . Évalué à 4. Dernière modification le 29/11/18 à 18:35.

              On ne peut pas tout avoir en même temps. :)

              Speed, Quality, Price. Pick Two, because you can’t have all three

              En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

            • [^] # Re: Pas forcément un casse tête

              Posté par . Évalué à 1.

              mettre à jour ce système minimal est risqué donc déconseillé ce qui rend la sécurité et l'évolutivité du dispositif plus délicat.

              Un bon compromis pourrait être d'avoir une double banque pour le système minimal, et un système plus conventionnel pour le produit.

              • [^] # Re: Pas forcément un casse tête

                Posté par . Évalué à 1.

                je viens de voir un post plus bas qui parle plus ou moins de ça, et je ne comprends pas que de base, les fabricants de microcontroleurs n'intègrent pas ce genre de fonctionnalité sur des microcontroleurs moins fournis en ressources internes. Mais vu que le monde de l'IOT avec nécessité de mise à jour à distance se développe, on verra peut-être ces fonctionnalités apparaitre de plus en plus à l'avenir.

              • [^] # Re: Pas forcément un casse tête

                Posté par (page perso) . Évalué à 2.

                C'est une possibilité, disons que là on aborde les gros concepts, rien n'empêche de mixer les conceptions suivant les besoins du projet.

                Dans certains cas, pour un objet non connecté à Internet, tu peux te permettre que la mise à jour soit très simpliste et moins fiable par exemple aussi.

          • [^] # Re: Pas forcément un casse tête

            Posté par . Évalué à 3. Dernière modification le 29/11/18 à 18:28.

            ce qui ne passe pas toujours lors des phases de réduction de cout, sur des très petits systèmes.

            Tu as parfaitement raison.

            La double banque impose souvent de prendre le microcontrôleur supérieur, plus cher, et qui embarque en plus des trucs qui servent pas forcément (ram, freq cpu, voire composants en plus carrément). Du coup ce qui se fait c'est une flash externe :
            - microcontroleur au plus petit, il embarque le code actuel
            - flash externe qui possède deux banques
            => une banque pour la mise à jour (nouveau soft)
            => une banque pour le backup (qui doit contenir le dernier code fonctionnant)
            => oui, ça fait 3 banques en tout !

            Lors d'une mise à jour, le bootloader recopie le nouveau soft dans le microcontroleur et boote dessus si tout va bien, ou alors remets le backup si ça va pas.

            Après, tu peux vivre sans la double banque. Il te faut un bootloader qui te permette tout le temps de repartir sur un système de flashing (fastboot sur un téléphone Android, et la "valise" dans les système embarqués automobile). Pour moi le double banque c'est surtout pour des mises à jour à distance, où on ne veut pas d'intervention humaine.

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

            • [^] # Re: Pas forcément un casse tête

              Posté par . Évalué à 0.

              C'est ce qui est fait sur le Linky, seul le nouveau code est présent normalement en mémoire externe. Et il y a 30 millions de compteurs. On envoie le stagiaire lancer l'upgrade et on tremble en regardant les stats de re-connexion monter doucement…

  • # Oh Dio !

    Posté par (page perso) . Évalué à 4.

    J'ai écouté quelques releases de CPU. Le concept est sympa, mais l'émission est pénible à écouter: beaucoup de heuuuuuuuuuuu, des silences, des hésitations, des personnes qui parlent en même temps, un BIIIIIIIIIIIIIIIIIIIIIIIIP qui défonce les oreilles…

    Bonne chance pour la suite!

    Incubez l'excellence sur https://linuxfr.org/board/

    • [^] # Re: Oh Dio !

      Posté par . Évalué à 3.

      Oui, j'ai jamais réussi à écouter une émission en entier, pourtant on voit que c'est très documenté, que les invités sont pertinents.

      A tes remarques, je rajoute les petites phrases (celle qu'on met entre parenthèses) (mais oui, comme ça) (surtout quand elles font des allusions à un truc qu'on connaît pas forcément) (c'est pénible hein ?) qui rajoutent de la confusion et déconcentrent.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Oh Dio !

      Posté par (page perso) . Évalué à 2. Dernière modification le 29/11/18 à 19:57.

      Ce qui m'avais beaucoup gêné lors de ma dernière écoute, c'est la qualité du son, et les différences de volumes. J'ai écouté l'émission en podcast dans la voiture, il y avait des moments inaudibles et d'autres où ça te casse les oreilles. C'est dommage, parce que le contenu de l'émission est pas mal.

      Un LUG en Lorraine : https://enunclic-cappel.fr

      • [^] # Re: Oh Dio !

        Posté par (page perso) . Évalué à 8.

        Je lis l'ensemble de vos remarques et je ne peux qu'abonder en votre sens sur notre amateurisme. Mais bon, nous sommes une émission d'une radio alternative, ce qui veut dire par définition que « des fois ça marche, des fois ça marche pas ».

        Sur les niveaux de son différents, je finalise le PÀD (sonore prêt à diffuser) avec un compresseur qui est très agressif, parfois trop car la radio a son propre traitement de son. Justement, une émission est en préparation sur la production radio pour le web. Les émissions qui ont ces sautes de niveaux sont celles enregistrées dans les conditions du direct, où la réalisation est alors très compliquée. Parce que je réalise en même temps que je gère le plateau et que je lis mes textes.

        Il arrive aussi que durant les interviewes, l'invité n'ose pas parler trop près du micro ou d'une voix posée, et c'est normal car pour certains nous sommes leur première expérience média ou de prise de parole en public. Les situation est alors très stressante pour eux, et c'est justement pour les aider pour leurs fois suivantes que CPU existe.

        Sur le bruit très strident, je suppose que vous faites référence à l'émission sur « créer un jeu 8 bits ». Le "Bip" était exceptionnel. En temps normal, j'évite ce genre d'horreur, mais l'occasion était trop belle de rappeler à la fois le son de ces sauvegardes et la sauvagerie auditive sans vergogne qu'était Radio FMR dans les années 1980s.

        Les hésitations pendant les interviewes…. oui, c'est très pénible. Mais des fois, même en ayant écrit les questions très en avance, on peut se retrouver à vouloir relancer et donc à improviser.

        Enfin, il ne faut pas oublier, nous faisons ça à côté de notre travail, de nos obligations familiales et de nos maintenances de serveur perso. Et des fois les préparations de sujets me semblent trop bâclées, mais j'ai vraiment pas le choix.

        Mais nous espérons progresser.

        • [^] # Re: Oh Dio !

          Posté par . Évalué à -3. Dernière modification le 01/12/18 à 00:07.

          Je vous tire mon chapeau ! Je découvre votre radio et j'apprécie… en relativisant sur la qualité du rendu sonore grâce à vos explications. Puissiez-vous progresser encore !

          [ sur l'usage de termes anglais ]

          Quand j'écoute un peu votre dernière émission, je prends conscience à quel point l'inclusion de termes anglais est passé dans l'usage courant dans le milieu informatique. De l'intérêt de l'approche de Linuxfr.org qui promeut l'usage du français de qualitaÿ (cf. la page traductions classiques).

          Voici d'autres ressources utiles, en dehors des dictionnaires habituels de traduction en ligne et des pages Wikipédia francophones qui présentent très souvent les expressions équivalentes en anglais :

          • Jargonf.org : « Le Jargon Français, dictionnaire d'informatique francophone, version 4.2 » ;
          • Dicofr.com : le « Dictionnaire de l'informatique et d'Internet » ;
          • la page du « Glossaire Celog des termes officiels de l'informatique » (composé notamment des termes retenus par la Commission générale de terminologie et de néologie, il intègre les définitions publiées dans les avis parus dans quelques JO mentionnés, s'étalant de 1997 à 2003). Note : CELOG est un centre d’expertises informatique indépendant spécialisé dans la preuve immatérielle, créé en 1976.

          Un exemple : là ou vous utilisez le mot « release » — que vous mettez en italique, merci pour ça, car c'est conforme à l'usage courant pour présenter un mot de langue étrangère dans une phrase en français — au sein de la phrase « Dans cette _release : Un appareil bien installé, une connexion réseau, une mise à jour système et un mode recovery bienvenu._ », sur la page de la dernière émission, j'apprécierais tout autant de lire « émission », ou encore « publication ». Je comprends l'intérêt d'utiliser un mot anglais qui renvoie aussi au concept de « version » (logiciel, matériel, tout ça…) ainsi que l'intérêt d'accrocher l'attention du public technophile, parce que ça fait plus hype (branché), mais je trouve que la généralisation de l'usage de l'anglais au milieu du français en favorise un usage abusif par mimétisme, participant à diluer notre culture.

          Je vous incite à considérer un exemple (ici puis ) de l'effort qui peut être déployé pour perpétuer un usage adapté du français aux nouvelles technologies.

          [ sur l'aspect visuel du site ]

          Concernant l'aspect visuel du site dédié à l'émission CPU, je trouve dommageable le fait de surcharger visuellement les vignettes avec du texte, même avec un surlignage (le plus souvent) transparent favorisant la lisibilité, car il est difficile de parcourir rapidement les titres et autres mots-clés. Je comprends l'intérêt en terme d'économie d'espace et de maximisation de la surface de la vignette, mais il me semble qu'en voulant optimiser sur ces deux critères, vous perdez beaucoup en lisibilité ainsi qu'en qualité de rendu visuel. Ainsi, j'aurais tendance à prôner un autre mode de présentation, dans lequel le texte soit bien plus lisible, c'est à dire pas sur l'image elle-même, mais à côté ou en-dessous. J'imagine que je ne suis pas le premier à vous le dire… Je serais curieux de lire l'avis de graphistes du Web. Pour ma part, je propose ceci, en première approche : dans l'esprit de conserver une vignette pour illustrer chaque émission, j'imagine un cadre entourant le contenu dédié à la présentation de chaque émission, avec en son sein, sur la gauche, une vignette, sur la droite, le texte. Bon, le texte étant alors confiné sur une zone plus étroite, donc nécessitant une police plus petite, il serait peut-être plus favorable de le disposer sous la vignette, avec la taille de police telle que vous l'avez paramétrée actuellement (dans ces conditions, l'espacement vertical mobilisé par l'ensemble vignette + texte sera accru).

          Par ailleurs, je trouve la page d'accueil impeccablement adaptative à tous les niveaux d'agrandissement (j'ai poussé jusqu'à l'agrandissement maximal avec Firefox). Ca laisse présager une très bonne utilisabilité avec toutes les tailles d'écran et toutes les résolutions, jusqu'aux ordiphones.

        • [^] # Re: Oh Dio !

          Posté par . Évalué à -1.

          [ sur le rythme de l'expression orale au sein des émissions ]

          J'ai pu observer le travail de post-production, sur une émission vocale, effectué par un amateur très éclairé. Pour donner du rythme, il supprime les blancs et les hésitations. Une fois rodé (ce sont les mêmes voix qui reviennent d'émission en émission, ce qui facilite l'optimisation du temps de travail), il met tout de même à la louche 2h pour 1h d'émission, de mémoire. Il est clair qu'avec un tel travail de post-production, la qualité et le plaisir d'écoute sont très largement accrus. L'amateur éclairé que j'évoque fait ça bénévolement, pour le plaisir du partage. Je suppose que vous pouvez trouver un bénévole en soumettant publiquement la requête.

        • [^] # Re: Oh Dio !

          Posté par . Évalué à 3.

          Les hésitations pendant les interviewes…. oui, c'est très pénible. Mais des fois, même en ayant écrit les questions très en avance, on peut se retrouver à vouloir relancer et donc à improviser.

          Est-ce que le montage, la post-prod pourrait un peu aider ? Il ne s'agit pas de "photoshoper" tout et n'importe quoi, mais juste enlever justement les quelques points qui ralentissent fortement le rythme.

          C'est une simple proposition : encore une fois, je trouve que vraiment les émissions sont très préparée (1000x mieux que la plupart des émissions "pro") mais la forme, malheureusement, est un vrai frein pour en profiter pleinement.

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

          • [^] # Re: Oh Dio !

            Posté par (page perso) . Évalué à 3.

            Je le fais parfois, uniquement sur mes chroniques, mais pas sur les émissions enregistrées dans les conditions du direct.

            Du coup, ça rend les voix très artificielles et j'ai autant sinon plus de critiques. J'ai eu droit à des critiques d'avoir remonter des interviewes pour avoir fait dit l'inverse de ce que mon interlocuteur a tenu comme propos. Cela m'a valu une longue, très longue polémique avec ladite personne interviewée.

            Donc maintenant, les interviewes ne sont plus remontées pour couper les silences, mais uniquement si l'interview est trop longue, et la version intégrale est publiée à part sur le site.

        • [^] # Re: Oh Dio !

          Posté par (page perso) . Évalué à 1.

          J'oublie un détail qui n'en n'est pas un : lors des émissions réalisées dans les conditions du direct, nous ne sommes pas dans un studio radio aménagé en tant que tel, mais en extérieurs.

          Ce qui en rajoute à la complexité de la réalisation.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.