Les ventes de Raspberry Pi à la hausse : voici pourquoi l'ordinateur monocarte est très demandé

Les ventes de Raspberry Pi à la hausse : voici pourquoi l'ordinateur monocarte est très demandé
En cette période de pandémie de coronavirus

Les ventes de Raspberry Pi ont atteint 640 000 unités en mars. C’est ce qui ressort d’une annonce (du dirigeant de la fondation du même nom) de laquelle on tire en sus que c’est le deuxième record de ventes le plus important de l’entreprise. D’après Eben Upton, cette hausse résulte du fait que beaucoup plus de gens utilisent la plateforme pour travailler et étudier à domicile à peu de frais alors que le confinement reste en vigueur dans bon nombre de pays.

Du travail, ce n’est pas ce qui manque pour les personnes désireuses d’apporter des solutions à la lutte contre le coronavirus. Avec avril 2020 qui tire à petits pas à son terme, cela va faire à minima quatre mois que la (désormais) pandémie de coronavirus s’est déclenchée. De par le monde la pénurie de respirateurs artificiels reste l’un des problèmes les plus importants en raison de l’afflux de patients atteints. Les hôpitaux sont débordés et parfois obligés de procéder au tri des personnes à connecter aux dispositifs d’aide à la respiration. Face au manque de respirateurs à utiliser contre le coronavirus, les solutions envisagées tournent entre autres autour de l’open source, du Do It Yourself. C’est ce qui justifie la hausse des ventes de la plateforme. Eben Upton le confirme en soulignant que la fondation Raspberry Pi a enregistré de nombreuses requêtes de tiers désireux de faire usage de Raspberry Pi dans le cadre du pilotage de respirateurs pour personnes atteintes du nouveau coronavirus.

Pièce jointe 557602

Marco Mascorro, un ingénieur en robotique, fait partie de ces personnes qui se sont lancées dans ces projets de respirateurs architecturés autour de plateformes comme le Raspberry Pi. L’objectif : répondre au besoin urgent formulé par de nombreuses institutions hospitalières. Le dispositif s’appuie sur d’autres pièces qu’on peut se procurer dans les magasins de fourniture automobile et de plomberie. Une vidéo en ligne permet de voir à quoi ressemble le respirateur de sa conception.

https://www.youtube.com/watch?v=ZqtTlJ4bQYw

Le dispositif n’a pas été approuvé par l’Agence américaine des produits médicamenteux (FDA). Toutefois, une équipe en Colombie a manifesté un intérêt pour ce dernier. Cette dernière a souligné que le design est important pour leur pays d'Amérique du Sud car les pièces pour les modèles traditionnels pouvaient être difficiles à obtenir. Le système doit faire l’objet de tests l'hôpital universitaire de l'Université pontificale Xavierienne et à l'Université de Los Andes, à Bogota. Les premiers tests verront l'unité fonctionner pendant cinq jours en continu sur un ensemble de poumons artificiels. Si elle réussit, elle passera ensuite aux essais sur les animaux. Les chercheurs espèrent commencer à utiliser des modèles produits en masse sur des patients hospitalisés d'ici le milieu de l'année.

« J’aurais préféré ne pas vendre d’unités plutôt que ce soit le cas en pareilles circonstances. Mais je suis heureux que nous puissions être d’une certaine utilité », a déclaré Eben Upton.

Pièce jointe 557603

La fondation Raspberry Pi a produit 192 000 unités au premier trimestre de l’année en cours. Elle entend faire passer la production à 250 000 unités au cours de celui qui a débuté avec le mois d’avril. La manœuvre est destinée à anticiper sur l’importante demande.

Source : Twitter

Et vous ?

:fleche: Qu’en pensez-vous ?

Voir aussi :

:fleche: Raspberry Pi : après 10 millions de dispositifs vendus, la fondation Pi sort un kit officiel Raspberry Pi avec clavier, souris et autres accessoires
:fleche: Quatrième anniversaire de Raspberry Pi avec la sortie officielle de Raspberry Pi 3 modèle B pour le même prix que le Raspberry Pi 2
:fleche: Le Raspberry Pi enregistre 12,5 millions de ventes en 5 ans, quelle place dans l'écosystème des ordinateurs sur le long terme ?
:fleche: Bientôt un support Android pour le Raspberry Pi 3*? Le matériel apparaît dans la liste des dispositifs officiellement supportés par Android
:fleche: Une nouvelle version de Scratch pour Raspberry Pi, avec la prise en charge du port GPIO

C'est une superbe initiative !

En effet le gouvernement anglais a bien assoupli les spécifications de ses futurs respirateurs afin d'en avoir plus et plus rapidement mais vu ce que demande l'agence de régulation des appareils médicaux Rapidly Manufactured Ventilator System ça m'étonnerait qu'avec du DIY + Open Source on y arrive :aie:

Ça ne sera pas à la portée de tous.

Pourquoi l'Open Source ne serait-il pas adapté ?

Salut,
J'ai écrit "Ça m'étonnerait" car pour avoir déjà fait des projets qui entre dans le cadre de la sûreté de fonctionnement, je sais qu'on demande des choses comme : être ISO 9001 (assurance qualité), arbres des défaillances du produit, planning de développement, cycle de développement, tests dynamique et statiques, calculs statistique de fiabilité, les solutions de repli (pour que quand ça plante, le comportement doit être déterministe) etc... et pour le hardware c'est pareil.

Avec la récupération d'un programme open source tu n'aura que le code (sauf erreur de ma part) ?

Alors ici ils ont largement assouplie les règles mais il reste des choses qui ne sont pas à la portée du DIY. Je prends quelques exemple du document https://assets.publishing.service.go...RMVS001_v4.pdf

Au début il est écrit :

Citation:

---

Note on vocabulary

Must: Defines the minimum viable product clinically acceptable by clinicians

Should: Highly desirable features of considerable benefit for therapeutic use. As time is of the essence if omitting one of these features significantly accelerates development and production
it should be considered

Could: Features or options often found in respirators, but are of significantly lower priority in terms of the current need and should not be considered if they delay production and development or the provision of more important features

---

Citation:

---

Note sur le vocabulaire

Il faut : Définit le produit viable et le minimum cliniquement acceptable par les cliniciens

Devrait : Caractéristiques hautement souhaitables et d'un bénéfice considérable pour un usage thérapeutique. Comme le temps est pressant si l'omission d'une de ces caractéristiques accélère considérablement le développement et la production il est possible de s'en passer.

Pourrait : Les caractéristiques ou options que l'on trouve souvent dans les respirateurs, mais qui sont nettement moins prioritaires dans les termes du besoin actuel et ne devraient pas être pris en compte s'ils retardent la production et le développement ou la fourniture de fonctionnalités plus importantes

---

En se concentrant sur tout ce qui est MUST on se rend compte que les spécs de la ventilation ne permettent pas de faire du DiY, il faut acheter des choses très précises. Dans la partie 2 Gas et Electricity et surtout electricity on demande a ce que l'alimentation soit conforme aux normes lEN 62353 et 60601-1 et en gros ça veut dire qu'il faut acheter une alimentation certifiée (ça existe tout fait, j'en ai souvent vu). Du côté Software Safety la difficulté est au point 7

Citation:

---

Must have transparent design, supply chain, manufacture, quality assurance and testing processes that are of sufficient quality to enable MHRA officials to deem appropriate for usage in exceptional circumstances.

---

Citation:

---

Doit avoir des processus transparents de conception, de chaîne d'approvisionnement, de fabrication, d'assurance qualité et d'essai qui sont d'une qualité suffisante pour permettre aux responsables de la MHRA de les juger appropriés pour une utilisation dans des circonstances exceptionnelles.

---

Voilà, ici on demande une assurance qualité (ISO9001 par exemple), des essais minimales sur le logiciel etc. Dans Testing, le point 1 précise bien que tu ne dois pas répondre à la norme (heureusement) mais on doit démonter la sécurité minimal du soft.

Il y a quand même des choses qui me font dire que le DIY n'est pas vraiment envisageable et que l'Open Source ne serait peut être pas une bonne idée. Le soft n'est pas complexe mais il doit être bien testé et démontrer sa fiabilité, pour ces raisons je crois qu'il vaut mieux le faire soit même plutôt que de récupérer du code qu'on ne maîtrisera pas forcément.

ps : je ne pense pas dire de bêtise en disant que dans l'Open Source, il est quand même très rare que la personne l'utilisant maîtrise tout le code. Souvent on ne fait que l'utiliser.

Je ne vois toujours pas en quoi un Open Source ne pourrait-il pas être ISO9001 ?

Cacher le code source permettrait-il d'augmenter la qualité d'un produit ?

Citation:

---

Envoyé par Vincent PETIT

........
ps : je ne pense pas dire de bêtise en disant que dans l'Open Source, il est quand même très rare que la personne l'utilisant maîtrise tout le code. Souvent on ne fait que l'utiliser.

---

J'utilise Word ou Exel sans complètement les maîtriser, est-ce un problème ?

Citation:

---

Envoyé par Jiji66

J'utilise Word ou Exel sans complètement les maîtriser, est-ce un problème ?

---

Ça le deviendra quand je te demanderai de me prouver la fiabilité du code source de Word ou Excel. (Oui je sais on a pas les sources mais c'est pour l'exemple)

J'ai cité ISO9001 car il est quasi l'inverse du DIY. ISO9001, si je fais un gros résumé, c'est quand tu es capable de faire des produits identiques selon un référentiel (tu écris ce que tu fais et tu fais ce que tu as écrit) dans le DIY c'est quand même plus dur de se mettre à produire à la chaîne

Citation:

---

Envoyé par Jiji66

Cacher le code source permettrait-il d'augmenter la qualité d'un produit ?

---

Cette remarque est très intéressante.

En temps normal lorsque tu développes du Software Safety, qui va de paire avec le Hardware Safety, on appelle ça SIL (Safety Integrity Level), c'est une norme mère EN61508 qui se décline dans le médicale IEC 62304, l'automobile ISO 26262, le ferroviaire EN50128, les machines .... il faut que quelqu'un s'engage en faisant un produit (le fabricant) ensuite il faut que quelqu'un atteste (un labo certificateur) et pour tout ça tu es obligé de montrer que tu maîtrises tout le code dans les moindre détails (tests + cycle de développement, statistiques, arbres de défaillances, stratégie de tests, ....) car toutes ces normes au final protège l'utilisateur, et dans le médicale c'est la personne qui y est raccordée.

Je ne vois pas bien la place de l'Open Source là dedans, je veux dire l'Open Source au sens ou tout le monde l'entend. Qui va s'engager ?

Quelques exemple d'OS temps réel pré-certifié :
- https://www.highintegritysystems.com/safertos/ (basé sur FreeRTOS, il est pré-certifiable pour le Nucléaire, pétrochimie et les voitures. De mémoire ~$60 000 mais l'équipe derrière s'engage.)
- https://www.esol.com/embedded/et-kernel_compact.html (idem que SafeRTOS)

Un truc que je regarde de très près depuis une certain temps, un OS temps réel pré-certifié Open Source (mais j'ai un gros doute sur la notion d'Open source, j'ai l'impression que ça va finir comme SafeRTOS, payant, mais basé sur FreeRTOS, gratuit)
- https://www.zephyrproject.org/zephyr...rating-system/ (Quid de l'engagement ? Comme souvent c'est le labo TÜV qui certifie et lui il demandera tout ce que j'ai cité plus haut.)

En fait le problème n'est pas au niveau de la qualité ou du ISO 9001 car ils est parfaitement possible de faire quelque chose qui respecte des norme très sévères avec de l'open source. Décrire précisément le mode de production pour remplir un dossier pour accréditation ISO 9001 n'est pas incompatible avec de l'Open Source.

Le problème, car il y en a un, c'est que les licences de type GPL empêchent de transférer la cascade des responsabilités, ce qui n'est donc pas assurable.
Ça n'a aucun lien avec le fait que ce soit ou pas Open Source.
C'est juste une question de licences et de gens qui refusent d'assumer leurs responsabilités !

C'est par ailleurs une des raisons qui freinent la diffusion de Linux.

Quelle est par exemple la différence entre un Oracle Linux et un RedHat ?
Et bien il n'y en a pas. Et c'est la raison pour laquelle nombreux sont ceux qui installent leurs bases de données sur du RedHat, ça permet de diminuer les coûts des licences.

Citation:

---

Envoyé par Jiji66

Le problème, car il y en a un, c'est que les licences de type GPL empêchent de transférer la cascade des responsabilités, ce qui n'est donc pas assurable.

---

+1

Tu as parfaitement raison je me suis trompé en faisant le raccourci ci dessous car c'est vrai qu'il y a plusieurs licences

Citation:

---

Envoyé par Vincent PETIT

Je ne vois pas bien la place de l'Open Source là dedans, je veux dire l'Open Source au sens ou tout le monde l'entend. Qui va s'engager ?

---

C'est bien Licence vs Engagement de la responsabilité le problème. Open source ou pas.

C'est très bien la certification.
Ensuite, quand on n'a pas assez de matériel certifié, refuser du matériel non certifié car non assuré, mais testé selon un un cahier des charges : je vous laisse choisir ce que vous voudriez...

La communication officielle (état) est qu'il n'y a pas eu de tri sur l'âge. Oui, pas de tri quand on peut... Si ± toutes les places sont prises en réa, qu'il faut ventiler mais qu'il n'y a plus de respirateur. Si des patients de >70 ans arrivent ? Que fait-on ? on leur explique qu'ils peuvent céder leur place à quelqu'un de plus jeune car le matériel alternatif est non certifié ?

La moyenne d'âge des décès est vers 80 ans et j'ai lu quelque part que 92% des décès avaient plus de 62 ou 65 ans.
La moyenne d'âge en réanimation est tombée jusqu'à 56 ans dans les mauvais moments. Je vous laisse deviner ce qui est arrivé aux plus de 70 ans.

@ Vincent: "on appelle ça SIL (Safety Integrity Level), c'est une norme mère EN61508 qui se décline dans le médicale IEC 62304, l'automobile ISO 26262, le ferroviaire EN50128, les machines .... il faut que quelqu'un s'engage en faisant un produit (le fabricant) ensuite il faut que quelqu'un atteste (un labo certificateur) et pour tout ça tu es obligé de montrer que tu maîtrises tout le code dans les moindre détails (tests + cycle de développement, statistiques, arbres de défaillances, stratégie de tests, ....) "

Toutes ces normes sont des "verrues" ne servant qu'a payer un circuit de "technocrate" (Techno-burocrates). Je viens de l'industrie médicale, ces certifications que tu énumèrent sont bien souvent obtenues si tu es d'accord d'en payer le prix (très élevé) de tous les intervenant. (auditeurs, organismes, etc...), ET que ton entreprise paye suffisamment pour qu'au deuxième (parfois troisième tour si ton entreprise est vraiment mauvaise) audit, elle l'obtienne de toute façon. Les vrais problèmes et les vrais questions ne sont jamais abordées. (car trop couteuses et demandant de vraiment "mouiller" le maillot pour les résoudre). J'ai vécu toute la chaîne depuis ISO9000 (la première supercherie). Lorsque tout le monde a été certifié une autre norme est apparue, etc...
Le problème est que certaines personnes se permettent de prendre des décisions pour d'autres, pour se rendre "rénumérables" et ce, "avec des oeuillères", je m'explique: si je suis malade, en train de mourir ou avec une probabilité très élevée d'y passer, que le remède est connu, et qu'on me demande si je veux tester un matériel qui n'a pas été "certifié" au risque d'être probablement sauvé, bien sur que je donnerai mon accord. Si je meurs parce que le système avait un défaut non testé (car on est dans l'urgence, ne l'oublions pas) ça change quoi ? De toute façon vu qu'il n'y avait pas le matériel nécessaire au départ j'étais forcément condamné...
Le seul test utile et nécessaire avant de passer à l'utilisation en "réel" est de s'assurer, comme il a été mentionné dans l'article, que le matériel (piloté par de l'électronique) ne "plante" pas en utilisation intensive. (5 à 6 jours d'utilisation non stop sur des poumons artificiels par exemple), il y a suffisamment d'analyseurs de microparticules (éventuellement émise par un ou des composants de la machine) "low cost" pour s'assurer rapidement que le dispositif envisagé n'est pas une "machine à tuer"
Donc ces discussions de certifications sont stériles et dangereuses pour la société lorsque l'on est, comme maintenant, dans un cas de pandémie.
On agit, on sauve avec tous les moyens possibles, et on laisse la bureaucratie pour plus tard.
Salutations à tous.

Aiigl59

Citation:

---

On agit, on sauve avec tous les moyens possibles, et on laisse la bureaucratie pour plus tard.
Salutations à tous.

---

A propos du respect des normes (tourné hardware mais le firmware n'est pas loin): le "scandale" des respirateurs qu'Air liquid s'est engagé en partenariat avec PSA et Schneider Electric à fournie à la france... du bricolage médiatique.
Ces normes semblent drasiques surtout du fait de l'évolution des connaissances liées à la maladie... selon l'adage qui peut le plus peu le moins (non pas le contraire qui reviendrait à dire que l'on peut bouler une norme tant qu'elle est respectée)

investigation france inter.

"Dans un premier temps, l’État souhaite que soient produit 5 000 respirateurs "T60" et autant d’un modèle plus basique, utilisé depuis 1998, qu’on appelle "l’Osiris 3". Mais le "T60" est complexe à assembler. Air Liquide propose donc de produire plus de modèles de type "Osiris" qui, eux, ne nécessitent que 300 composants. Résultat : 8 500 "Osiris 3", contre 1 600 "T60", seront fabriqués dans un délai record de 50 jours. Le projet est sur les rails. L’alliance fait appel à 240 volontaires. La production démarre le 6 avril."

Le mode opératoire est complexe et les préconisations d'usage d'un matériel inadapté le sont davantage...

"Dans le cadre de la crise sanitaire Covid 19, les respirateurs de transport « MONO-BRANCHE » typeOsiris ou Oxylog ne doivent être utilisés qu’en dernier recours après les respirateurs « Bi-BRANCHE » (circuit inspiratoire et circuit expiratoire) de réanimation ou d’anesthésie.
Les risques de l’utilisation d’un respirateur mono-branche (turbine ou piston) pour une ventilation de longue durée chez un patient intubé doivent être connus et prévenus par les utilisateurs :
1. HUMIDIFICATION ET RECHAUFFEMENT DES GAZ INSPIRES NON OPTIMAUX
. Assurer une bonne hygrométrie du gaz insufflé. Des bouchons muqueux dans les bronches des patients décédés ont été décrit, témoignant d’une humidification et réchauffement des gaz inspirés non optimaux. Le système d’hygrométrie à savoir un échangeur de chaleur et d’humidité (HME)doit avoir des bonnes performances en limitant au mieux l’espace mort additionnel.
2. Risque d’HYPERCAPNIE.
Il ne faut pas boucher la valve expiratoire. Les gaz expirés doivent être évacuer en dehors du patient. Ceci arrive souvent et doit être prévenu par la formation du personnel utilisant ce matériel.
3. Risque d’AEROSOLOTHERAPIE DU VIRUS.
L’utilisation du filtre combiné dans l’échangeur de chaleur et d’humidité (HME) qui devient HME-F (HME-Filtre) doit être expliqué aux utilisateurs pour éviter de confondre les 2 fonctions. Bien que la majorité des industriels commercialisant les HME-F annoncent une performance d’efficacité antibactérienne et antiviral de plus de 99,9% ; ceci ne permet pas d’éliminer le risque d’aérosolthérapie dans la chambre du patient de virus d’autant que la ventilation est prolongée. Le personnel soignant doit être protégé car le risque d’accumulation du virus dans l’air est réel en l’absence de chambre à pression négative ou de Plasmair filtrant.
Il faut recommander en cas d’utilisation de ce type de ventilateur monobranche chaque fois que possible, que ce soit fait dans des chambres à pression négative ou en mettant un Plasmair filtrant.
Comme les filtres-HME vont être changés souvent selon instruction du constructeur ou des recommandations ; il faut prévoir une procédure de prudente lors du débranchement et prévoir un circuit d’évacuation de ces déchets remplis de virus possiblement."

(...)

Il était un petit homme Pirouette, cacahuète Il était un petit homme Qui avait une drôle de maison...

"On a transformé ces appareils simples en appareil un peu plus complexes. Mais cela n’en fait pas pour autant un outil de thérapie adapté à des patients en situation de détresse respiratoire. Ce dispositif devra faire l’objet de nouveaux essais cliniques, puis d’une homologation, avant d’être commercialisé. "

@Aiigl59

Dans mon labo de R&D nous étions 10 et je voyais bien comment se passait toutes ces histoires de normalisation et de certification, d'audite et de restaurant :lol: Oui quand tu vas dans un labo de certification tu y vas avec un gros chèque et là le labo certificateur sait que :
- si il te refuse trop de fois la certification parce qu'il y a des défauts, tu vas aller voir ailleurs pour trouver un labo un peu plus sympa.
- si il veut vivre il a tout intérêt à te certifier pour que tu reviennes avec un nouveau produit à certifier.

Donc oui je suis d'accord qu'il y a un petit jeu de dupe là dedans car chacun à besoin de l'autre, le fabricant pour vendre et le certificateur pour faire tourner sa boîte.



Mais les normes en elles mêmes ont quand même du sens. Ci dessous un appareil de détection de gaz portable (concurrent de mon ancienne boîte), ce truc est sensé sauver la vie des gens. Imagine que tu l'as en main dans cet état.

Pièce jointe 560432

- Qui me dit qu'il n'est pas planté et que l'écran est figé ?
- Il indique 0.00ppm de Monoxyde de Carbone (CO), c'est normal ou alors est ce que la cellule électrochimique dedans est morte ?

:arrow: Les normes demandent des choses du genre "il faut un clignotement pour différentier un appareil planté, d'un appareil qui ne détecte rien"
:arrow: Les normes demandent dans certain cas d'avoir "de la redondance hardware donc deux cellules électrochimiques" et que tu apportes la preuve statistique d'un taux de défaillance moyen par heure d''un appareil ayant deux cellules (les fabricants de composant électronique donnent les taux de défaillance moyen par heure)
:arrow: Et oui je suis d'accord pour dire que les normes demandent plein de choses même parfois très bizarre.


Sans normes tu peux être sur que certain fabricant vont te réinventer la lampe à grisous ! Avec une fiabilité très relative et qui créait des explosions dans les mines !
Pièce jointe 560438

Citation:

---

Envoyé par Aiigl59

On agit, on sauve avec tous les moyens possibles, et on laisse la bureaucratie pour plus tard.

---

Par contre là je te rejoints car je ne comprends pas pourquoi on ne demande pas simplement aux fabricants habituels de respirateur d'en produire en masse. La certification c'est qu'une fois pour le premier respirateur de la série, ensuite tous les suivant ce n'est que de la production à la chaîne.

c'est évidement tentant d'utiliser un raspberry comme pc, système complexe, d'ailleurs je pense en utiliser un pour faire tourner mon juke box à l'arrêt depuis 35 ans, mais la on envisage de piloter un respirateur, ben non avec des fonctions répétitives demandant une grande fiabilité un automate est plus rustique et plus apte à être géré par un simple technicien avec un bac pro, par contre pour la supervision et éventuellement le pilotage à distance le Raspberry c'est idéal, peu coûteux, modulable, facile à faire acheter par son service car ça n'entre pas les catégories investissement,