Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Patrick Ruiz

159PARTAGES

23  0 
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.


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.


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.


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 ?

Qu’en pensez-vous ?

Voir aussi :

Raspberry Pi : après 10 millions de dispositifs vendus, la fondation Pi sort un kit officiel Raspberry Pi avec clavier, souris et autres accessoires
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
Le Raspberry Pi enregistre 12,5 millions de ventes en 5 ans, quelle place dans l'écosystème des ordinateurs sur le long terme ?
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
Une nouvelle version de Scratch pour Raspberry Pi, avec la prise en charge du port GPIO

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Vincent PETIT
Modérateur https://www.developpez.com
Le 19/04/2020 à 21:08
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

Ça ne sera pas à la portée de tous.
4  0 
Avatar de Vincent PETIT
Modérateur https://www.developpez.com
Le 20/04/2020 à 11:35
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 :
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
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

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.
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.
4  0 
Avatar de Vincent PETIT
Modérateur https://www.developpez.com
Le 20/04/2020 à 12:47
Citation Envoyé par Jiji66 Voir le message
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 Voir le message
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-ker...l_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.)
4  0 
Avatar de Aiigl59
Membre régulier https://www.developpez.com
Le 25/04/2020 à 0:51
@ 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.
4  0 
Avatar de Jiji66
Membre éprouvé https://www.developpez.com
Le 20/04/2020 à 14:17
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.
3  0 
Avatar de Jiji66
Membre éprouvé https://www.developpez.com
Le 20/04/2020 à 12:18
Citation Envoyé par Vincent PETIT Voir le message
........
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 ?
2  0 
Avatar de Vincent PETIT
Modérateur https://www.developpez.com
Le 20/04/2020 à 15:17
Citation Envoyé par Jiji66 Voir le message
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.
2  0 
Avatar de Fagus
Membre averti https://www.developpez.com
Le 20/04/2020 à 22:42
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.
2  0 
Avatar de Jiji66
Membre éprouvé https://www.developpez.com
Le 20/04/2020 à 10:34
Pourquoi l'Open Source ne serait-il pas adapté ?
1  0 
Avatar de Jiji66
Membre éprouvé https://www.developpez.com
Le 20/04/2020 à 12:15
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 ?
1  0