Onderwerp: Betrouwbaarheid open bron software + Raspberry Pi

Een geweldige opsteker voor het gebruik van openbron software en een Raspberry Pi in mission critical zetting. Nu denk ik dat het gebruik als boordcomputer aan boord van onze bootjes lang niet zo mission critical is dan een beademingsapparaat op een IC maar het is toch prettig om te weten dan onze framboosjes gansrijk strenge keuringen met betrekking tot betrouwbaarheid binnen medische toepassing kan doorstaan. Het hart van deze machine is een Rpi met touchscreen.

link

Ontwikkel club

Dát is mooi nieuws!

Ik hoop alleen wel dat ze een SSD gebruiken ipv SD of USB qua betrouwbaarheid?

Of een schrijfbeveiligde SD-card á la Rooiedirk.

Ik heb ook nog nooit een bericht of een vraag gezien dat er RPI's defect zijn geraakt. De kwaliteits controle bij de Sony fabriek in Wales, waar de computerboards gemaakt worden, is erg hoog.

Als de RPI's gebruikt worden voor allerlei medische en industrieele toepassingen, dan zijn die zeker geschikt voor onze bootjes.

En wil je net als bij de profesionele zeevaart waar een back-up systeem verplicht is, dan neem je een extra reserve setje mee aan boord. De kosten ? Net zoveel als een paar NMEA2K kabeltjes.

Ook al heb je al een merk kaartplotter aan boord, dan is een extra navigatie systeem een goede zaak.

Zeker als in de toekomst van kaartgebruik uitsluitend digitaal gaat plaats vinden.

Bram

Ik heb geen wantrouwen ten aanzien van de kwaliteit en stabiliteit van de Raspberry.

Mijn bedenkingen liggen meer bij de vaardigheden en het kennisniveau van de meeste gebruikers bij gebruik van de Raspberry als een personal computer.

Als procescontroller zoals deze beademingsmachine is de Raspberry perfect toepasbaar.

WADnWIND schreef :
Wat als je SSD het dan niet meer doet ?

Met een SD kaartje, die overigens steeds beter worden, stop je er direct een back-up kaartje in.

Je kunt een SD kaartje eenvoudig kopieeren met een kaartlezer van een paar €'s.

Overigens kost zo'n SSD PCIe ook niet zoveel meer. Hier een in gebruik met 128 GB.

Zie afbeelding.

Eén van de vereisten van deze beademingsmachine is dat hij minimaal 2 weken onafgebroken moet kunnen werken. Een SD kaartje verwisselen en opnieuw opstarten is dan niet aan de orde. Het sterkt mij in mijn vertrouwen dat mits goed gebruikt en de juiste software er geen problemen te verwachten zijn. Iets wat ik ook op kleine schaal zelf ook ervaren heb. Ik heb een 7 tal Rpi's in 24/7 gebruik waarvan er 2 nu onafgebroken drie jaar functioneren. Mijn boord Rpi staat altijd 3 maanden onafgebroken per jaar aan zonder gedoe. Maar goed in mijn geval niet zo mission critical als in aangehaalde toepassing. Hier zullen ze niet over 1 nacht ijs gaan.

De betrouwbaarheid van de hardware of de software staat ook niet ter discussie.
De betrouwbaarheid van de het data medium wel.

Door ervaring wijsgeworden is een SD-card niet het ultieme betrouwbaarste medium. USB sticks al helemaal niet.
Ik heb hier een bakje liggen met gecrashte zooi.
Alleen de write protected media of SSD overleven hier tot nu toe. Het staat al ruim een jaar proef te draaien.

Dit is een apparaat met een duidelijk omschreven functie. Wat ingangen (sensoren etc) , wat uitgangen (pompjes / motortjes) en wat instellingen. ( lcd + touch)
Voor de rest moet dat ding gewoon 24/7 een programma draaien. Aanzetten en werken.
Stekker eruit en er weer in: gewoon werken, meteen.

Met een raspberry oplossing moeten er dan input en output borden en een goede voeding bijgezocht worden. En wordt het weer een samenraapsel van hardware. En software en drivers.

Dan kun je dus beter embedded gaan. geen ssd en geen usb sticks. En vooral niet linux erop zetten.
(Dan krijg je echt tientallen misschien nog wel meer MegaBytes aan software gratis erbij. Met de nodige bugs.)


Ik had een custom made print ontwerp gedaan. De ingangen zijn dan goed beschermd en ontworpen voor de toepassing. Ditto voor de uitgangen. Met custom made software en geen onnodig operating system.
Hou het simpel dan werkt het veel beter, en kunnen wij als simpele zielen het overzien, en de risico's afdekken en oplossen. 1000 regels broncode is veel eenvoudiger te managen dan 1 miljoen. Het gaat hier om mensenlevens.
Print kan binnen 3 dagen op hier mijn buro liggen. En een uur later geassembleerd zijn. Ondertussen wordt de software ontworpen. De tweede versie met alle fouten eruit kan dan een week later gereed zijn. De meeste tijd zal de applicatie software kosten,die je in ook het geval van de raspberry zal moeten inkloppen.

nb: Overigens zijn er natuurlijk voldoende toepassingen waar de raspberry prima tot zijn recht komt. Vooral wanneer een operating system nut heeft. Zoals bij voorbeeld bij een desktop toepassing. Ik ga geen tekstverwerker embedded ontwerpen natuurlijk!

Het is alleen jammer dat er tegenwoordig steeds meer kant en klare bordjes gekozen worden. Vaak is het gebrek aan kennis, en kan zo toch een redelijk project gerealiseerd worden, het blijft altijd een compromis. En dat is niet altijd fijn.

Dit is mijn bescheiding mening, hè. Ik weet dat velen hier de raspberry ophemelen als de heilige graal. Ik respecteer die mening. Maar het zijn meestal geen elektronici.

No worries , ik zal verder een discussie aangaan.
Ik wilde het gezegd hebben, omdat het volgens mij inhoudelijk wat toevoegt.

Mooi initiatief!

WADnWIND schreef :
Waar lees je dat dit ter discussie staat; het gehele appaarat gaat in produktie toch?

Alles wat je aan boord haalt met een framboos is een testopstelling welke door jouw getest moet worden. Bij iedere update of hardware verandering begint dit proces opnieuw. Je moet dus ZELF testen met de door jouwzelf verzonnen acceptatiecreteria. Bij commerciële navigatieproducten wordt dit voor je gedaan.

Bovenstaand beademingsapparaat is zeker getest en even een update doen daarna terwijl er een patiënt aan de beademing ligt is natuurlijk uit den boze.

roozeboos schreef :
Zelden zulke onzin gelezen.

roozeboos schreef :
Linux als operating system is uitgekristalliseerd waar het bugs betreft. Niet helemaal, en zeker niet de testversies, maar grotendeels wel. Daarbij wordt altijd de broncode meegeleverd. En zeker met zo'n groep studenten zitten er altijd wel een paar bij die uit die broncode alle niet noodzakelijke dingen eruit slopen, voordat het ingezet gaat worden. Roozeboos weet dit uiteraard ook, dit is meer voor degenen die niet goed thuis zijn in besturingssystemen, daarom is het ook versimpeld gesteld.

Een custom print ontwerp kost tijd, om te ontwerpen, te testen en te fabriceren. Daarnaast weet je nooit zeker of er niet toch ergens een fout gaat opduiken. Een Raspberry is ook uitgekristalliseerd qua ontwerp en uitvoering. Daarvan is vrijwel zeker dat er geen fouten meer naar boven zullen komen. Zeker als je de Rpi 3 neemt.

Deze groep studenten wilde IN KORTE TIJD een oplossing bieden. Dan is het verkeerd om van nul af te gaan ontwerpen, dan kun je beter een al bestaand betrouwbaar stuk hardware nemen en de software die daarop gaat zo simpel mogelijk houden. En dat is precies wat ze gedaan hebben.

brambo schreef :
Bram, Roos is weer aan het stangen, hij bedoelde Micorshit en niet Linux.

Roos, je kunt met Linux, tenminste met bepaalde linux distributies of met een zelf ontworpen versie, al wat overbodig is eruit laten. ( vermoedelijk weet je dat ook wel, en dan is het jammer dat je dat er niet gewoon bijschrijft ).
Er zijn tutorials genoeg voor een minimalistische linux versie die alleen dat doet wat voor jou toepassing noodzakelijk is.
Dergelijke linux versie's zitten bvb in routers, modem's, etc etc etc.
Allemaal toestellen die 24/7/12 ( 24h/7d/12m, xxy ) moeten blijven werken zonder storingen.
En de processor die in de Pi zit wordt heel dikwijls ook daarvoor gebruikt, (snel, laag vermogen.)
Ik weet wel dat je daarvan op de hoogte bent, maar schijf het hier maar omdat anderen niet in de waan zouden komen dat de Pi rommel zou zijn.

Wat het mooie is van dit project is dat het een open bron team prestatie is. Voortbouwend op geteste en bewezen modules. Bovendien we hoeven de vraag niet meer te beantwoorden of het voldoet. Dat hebben anderen die veel meer verstand er van hebben al beantwoord.
Hier een discussie starten over vermeende onbetrouwbaarheid lijkt een beetje op iemand die hijgend het perron op komt stuiven en zijn trein in de verte ziet wegrijden en begint te klagen dat de trein altijd te laat vertrekt.
Je kunt met een vrij grote zekerheid stellen dat als je zo'n Rpi niet goed aan het werk krijgt en houdt dat het voor 99% aan je eigen onkunde ligt.

Er zijn hier minimaal 2 experts die zelf een raspberry niet betrouwbaar aan de praat krijgen of kunnen houden, dat kan natuurlijk nooit aan hun eigen beperkingen liggen, als zij dat niet kunnen dan is het product inferieur. Einde discussie...
Of de personen die deze longmachine hebben ontwerpen dat wel kunnen is natuurlijk ook niet zeker, misschien valt hij over 2 weken wel uit, een echte duurtest hebben ze nog niet kunnen doen.
Geen idee hoe snel je een longmachine kan of zou moeten kunnen swappen, maar ze kunnen nu een aantal fulltime laten draaien natuurlijk, zodat mogelijke problemen eerst in de testopstelling zullen ontstaan.

Mijn langste testopstelling heeft ongeveer 3 jaar online gedraaid zonder zelfs maar een reset of reboot, hij is werkend uitgeschakeld voor redesign van het systeem. Het modem waarmee hij verbonden was moest wel een aantal keren gereboot worden.

Ik denk trouwens dat Chris heel goed in staat is om ook een longmachine te ontwerpen. En die zou zomaar nog eens beter kunnen zijn dan dit ontwerp.
Ik ken wel tientallen bedrijven om mij heen dat het ook zouden kunnen en zouden willen!
Het ontbreekt ons gewoon aan de capaciteit om daarvoor snel de subsidie naar binnen te harken.
Ondertussen heb je al zoveel kapers op de kust dat het al geen zin meer heeft.

Zeilprutser schreef :
Wat een zelfoverschatting en arrogantie van deze prutsers. Even geen tijd en capaciteit om de subsidies binnen te harken.

Laat staan het belang om de IC's van goed werkende apparatuur te voorzien, om daarmee levens te redden.

tsja Bram,

als ik hoor dat ze het daar met een team van 30 man in 2 weken realiseren, dan zie ik duo Rooz en Pruts het nog niet voor elkaar krijgen in alle realiteit

hoe mooi dat ook geweest zou zijn..

Knappe enthousiaste koppen bovendien in knappe opleiding zonder beperkende dogma’s.

Ongelofelijk wat je dan kunt bereiken!

sy helios schreef :
Als team zie ik het hem ook niet worden

Op de universiteiten staan machine parken voor miljoenen, alle software is gratis beschikbaar, en alle benodigde ervaring aan instrumenten makers en leraren staan voor ze klaar. Daarnaast hebben ze netwerken met vele technische bedrijven die de subsidiepotjes heel goed weten te gebruiken voor het "onderzoek".

Nachtvlinder schreef :
Dat was meer bedoeld als voorschot voor sommige lieden die beweren daar nooit last van te hebben en altijd een backup kaartje op zak hebben.

Een voorschot nemen op iets wat nooit gaat komen is behoorlijk zinloos.

In detail; het herhaald schrijven van de zelfde cel van een SD kaart of een multi layer ssd is nooit een slimme zet. Een willekeurige multi layer ssd kan ik ook wel in 24 uur naar zijn grootje helpen.
Kortom verzin een beter argument.

3Noreen schreef :
De dingen van het voorschot zijn reeds geweest in oudere draadjes van sommige lieden.
Ik schrijf uit een multi ervaring met crashen van SD kaartjes en USB sticks.
De read only optie is prima. Een SSD is kennelijk aanzienlijk beter voor ingericht en houdt het hier nu ruim een jaar vol.

We hebben in het verleden de pi elke 10 minuten random laten af en inschakelen om de betrouwbaarheid te testen tijdens schrijfacties. Binnen een week waren de SD elke keer stuk.
De USB stick nog sneller. Behalve de SSD die werkt nog steeds.

Een UPS voor een safe shutdown lost alles op.

Ik kom alleen met praktijk geteste feiten, geen theoretische argumenten.
Nogmaals; het zegt niets over de PI of de software. maar wel over de3 data drager.
Wij moesten een bomvrij product maken voor op zee, waar we nooit meer bij komen.

Uit eindelijk hebben we gekozen voor iets betrouwbaarders (ook daar weer voor- en tegenstanders).

Het zoeken naar een veilige en betrouwbaar werkende PI in een onstabiele omgeving heeft ons nog de meeste tijd gekost.