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 Jokernathan . Évalué à 2. Dernière modification le 24 août 2019 à 18:10.
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.
[^] # Re: Conférence sur le même thème aux Embedded Recipes
Posté par Renault (site web personnel) . Évalué à 5.
Ravi que tu aies apprécié. :)
Pour les pressés, il y a les slides ici pour voir rapidement la teneur du propos.
# Pas forcément un casse tête
Posté par Renault (site web personnel) . É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 Da Scritch (site web personnel, Mastodon) . É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 NeoX . Évalué à 4.
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 gUI (Mastodon) . É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 LaBienPensanceMaTuer . É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 Da Scritch (site web personnel, Mastodon) . Évalué à 1.
Oui, c'est expliqué dans l'émission
[^] # Re: Pas forcément un casse tête
Posté par cimcim . Évalué à 1.
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 Renault (site web personnel) . É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 gUI (Mastodon) . Évalué à 4. Dernière modification le 29 novembre 2018 à 18:35.
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 totof2000 . Évalué à 1.
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 totof2000 . É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 Renault (site web personnel) . É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 gUI (Mastodon) . Évalué à 3. Dernière modification le 29 novembre 2018 à 18:28.
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 AnthonyRabine (site web personnel) . É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 devnewton 🍺 (site web personnel) . É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!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Oh Dio !
Posté par gUI (Mastodon) . É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 ted (site web personnel) . Évalué à 2. Dernière modification le 29 novembre 2018 à 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 Da Scritch (site web personnel, Mastodon) . É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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -3. Dernière modification le 01 décembre 2018 à 00:07.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Oh Dio !
Posté par gUI (Mastodon) . Évalué à 3.
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 Da Scritch (site web personnel, Mastodon) . É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 Da Scritch (site web personnel, Mastodon) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.