DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Gisteren een interessante talk gekeken van iemand die de meeste software ontwikkelaars waarschijnlijk wel kennen, uncle Bob, en hieruit kwamen voor mij twee interessante keypoints.
• Sinds 1946 is het aantal programmeurs wereldwijd op enig gegeven moment minimaal iedere vijf jaar verdubbeld. Hiermee is het een bijzonder werkveld waarin gedurende deze periode(eigenlijk altijd dus
) op ieder moment minimaal de helft van alle programmeurs minder van vijf jaar werkervaring heeft.• Er is inmiddels zoveel software om ons heen (hij gaf o.a. als voorbeeld dat een auto met bouwjaar 2018 100 miljoen regels code huisvest) dat het wachten is op een groot ongeval met meer dan duizend dodelijke slachtoffers met als oorzaak een bug. Er zijn al verschillende kleinere incidenten geweest waarbij een bug doden tot gevolg heeft gehad, zoals bijvoorbeeld recent een bug in een Toyota auto met minimaal 89 doden als resultaat.
Hij verwacht dat als gevolg hiervan dat politici naar de software industrie gaat wijzen en dat er regelgeving komt omtrent hoe er software gemaakt moet worden, zoals er nu bijvoorbeeld regelgeving is binnen de accountancy. Hierbij was zijn gedachte dat de wetgeving geschreven gaat worden door mensen die er geen verstand van hebben en welke verdere ontwikkeling mogelijk in de weg gaat staan. Hieropvolgend sprak die de gedachte uit dat we dit voorval beter voor kunnen zijn door als industrie zelf governing bodies op te stellen, hierbij opperde die kort TDD, maar verder ging die hier omwille van de tijd niet dieper op in.
Zelf zie ik wetgeving omtrent de wijze waarop software ontwikkelt wordt in de toekomst niet als een compleet onwerkelijk scenario; ik heb alleen nog geen concreet beeld bij hoe de software industrie dit voor kan zijn door zelf regulering op te tuigen. De reden voor dit topic is ik wel benieuwd hoe anderen hierover denken.
Sowieso is de talk ook wel een aanrader om te kijken, duurt ongeveer anderhalf uur.
[ Bericht 0% gewijzigd door FlippingCoin op 23-10-2021 15:34:34 ]
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
For all who deny the struggle, the triumphant overcome
Maar ik neem aan dat voor bepaalde industrieën zoals automotive en luchtvaart als regels zijn m.b.t. software en hoe deze getest wordt.
Bij het lezen van de TT dacht ik trouwens dat het zou gaan om A.I. systemen.
Bij het lezen van de TT dacht ik trouwens dat het zou gaan om A.I. systemen.
Volgens mij is er geen standaardmethode voor het ontwikkelen van software opgesteld voor gehele sectoren of breder.quote:Op donderdag 28 oktober 2021 19:25 schreef TargaFlorio het volgende:
Maar ik neem aan dat voor bepaalde industrieën zoals automotive en luchtvaart als regels zijn m.b.t. software en hoe deze getest wordt.
Bij het lezen van de TT dacht ik trouwens dat het zou gaan om A.I. systemen.
Nee niet specifiek AI, maar dit zal allicht een nieuw struikelblok vormen in de toekomst daar er met AI naar een uitkomst een algoritme wordt opfesteld wat nog complexer is om te doorgronden en daarmee testen, denk ik.
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
For all who deny the struggle, the triumphant overcome
In bepaalde industrieën is het al zo dat er regels zijn voor de software (denk alles vervoer en nuts bedrijven).
NASA heeft bijvoorbeeld strakke richtlijnen hoe de software voor sondes en satalieten wordt geschreven. https://yurichev.com/mirrors/C/JPL_Coding_Standard_C.pdf
In het geval van nucleaire kerncentrales is er zulke strikte controle dat het gewoon niet leuk meer is, maar bugs bijtijds gevonden worden (en dat is het belangrijke).
In elk geval is er ontwikkeling op het gebied van programmeertalen die het makkelijker maken om bugs te vinden (rust, nim?), en dat is al een hele hulp. Ik zie het al voor me dat ze op gevoelige plaatsen (kernreaktoren, besturing van auto's, etc.) C en C++ van lieverlee uit gaan rangeren, ten goede van talen als rust en nim, simpelweg omdat die in de taal zelf enige mate aan veiligheid ingebouwd hebben en hele klassen aan bugs voorkomen.
Die veiligere talen zullen nog niet beteken dat alle bugs automatisch uitgesloten zijn, maar het helpt zeker een hoop. Het zal mij niks verbazen als rust en nim door ontwikkelaars van software voor op gevoelige plaatsen goed in de gaten wordt gehouden.
NASA heeft bijvoorbeeld strakke richtlijnen hoe de software voor sondes en satalieten wordt geschreven. https://yurichev.com/mirrors/C/JPL_Coding_Standard_C.pdf
In het geval van nucleaire kerncentrales is er zulke strikte controle dat het gewoon niet leuk meer is, maar bugs bijtijds gevonden worden (en dat is het belangrijke).
In elk geval is er ontwikkeling op het gebied van programmeertalen die het makkelijker maken om bugs te vinden (rust, nim?), en dat is al een hele hulp. Ik zie het al voor me dat ze op gevoelige plaatsen (kernreaktoren, besturing van auto's, etc.) C en C++ van lieverlee uit gaan rangeren, ten goede van talen als rust en nim, simpelweg omdat die in de taal zelf enige mate aan veiligheid ingebouwd hebben en hele klassen aan bugs voorkomen.
Die veiligere talen zullen nog niet beteken dat alle bugs automatisch uitgesloten zijn, maar het helpt zeker een hoop. Het zal mij niks verbazen als rust en nim door ontwikkelaars van software voor op gevoelige plaatsen goed in de gaten wordt gehouden.
Ze zouden het gebruik van bepaalde controletools verplicht kunnen stellen, iedere release build bewijzen dat je je best gedaan hebt.
Herinner me uit de Java docs dat er iets in staat van: “Niet geschikt voor kernonderzeeërs”
Herinner me uit de Java docs dat er iets in staat van: “Niet geschikt voor kernonderzeeërs”
"We aren't people, we are text." - Japanman Sakyusan -
Oh nice dat is wel cool om te lezen die richtlijnen van de NASA die kende ik nog niet, en ik ken er wel meer o.a. van de grote partijen, alleen is het allemaal wel erg gefragmenteerd momenteel. Maar heb je ook voorbeelden van zulke standaarden die een bedrijf overstijgen?quote:
In bepaalde industrieën is het al zo dat er regels zijn voor de software (denk alles vervoer en nuts bedrijven).
NASA heeft bijvoorbeeld strakke richtlijnen hoe de software voor sondes en satalieten wordt geschreven. https://yurichev.com/mirrors/C/JPL_Coding_Standard_C.pdf
In het geval van nucleaire kerncentrales is er zulke strikte controle dat het gewoon niet leuk meer is, maar bugs bijtijds gevonden worden (en dat is het belangrijke).
In elk geval is er ontwikkeling op het gebied van programmeertalen die het makkelijker maken om bugs te vinden (rust, nim?), en dat is al een hele hulp. Ik zie het al voor me dat ze op gevoelige plaatsen (kernreaktoren, besturing van auto's, etc.) C en C++ van lieverlee uit gaan rangeren, ten goede van talen als rust en nim, simpelweg omdat die in de taal zelf enige mate aan veiligheid ingebouwd hebben en hele klassen aan bugs voorkomen.
Die veiligere talen zullen nog niet beteken dat alle bugs automatisch uitgesloten zijn, maar het helpt zeker een hoop. Het zal mij niks verbazen als rust en nim door ontwikkelaars van software voor op gevoelige plaatsen goed in de gaten wordt gehouden.
Rust is met zijn memory safety zeker een goede stap voorwaarts, alleen heeft Rust weer als keerzijde een hoge leercurve en relatief trage ontwikkelsnelheid; zoals altijd wel voor en nadelen.
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
For all who deny the struggle, the triumphant overcome
Oh dat is wel vrij standaard tegenwoordig denk ik, een CI/CD flow die alleen slaagt zodra alle unit en e2e tests slagen, alleen als je dan een slechte test coverage of gewoon slechte tests schrijft helpt dat ook niet zo veel meer.quote:Op donderdag 28 oktober 2021 23:46 schreef Tyr80 het volgende:
Ze zouden het gebruik van bepaalde controletools verplicht kunnen stellen, iedere release build bewijzen dat je je best gedaan hebt.
Herinner me uit de Java docs dat er iets in staat van: “Niet geschikt voor kernonderzeeërs”
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
For all who deny the struggle, the triumphant overcome
De rust taal zelf is relatief gemakkelijk (toegegeven, het omvat wel een hoop). Het is echter het geval dat, als je van een andere taal, een hele andere manier van denken aan moet leren, en dat kan moeilijk zijn. Zo kan je niet even snel iets in elkaar rammelen en er later wel de bugs uit halen. De dingen die andere compilers slikken, slikt de rust compiler dus echt niet en hij geeft dan gewoon doodleuk een foutmelding en legt gelijk uit waar je de fout in gegaan bent.
Ik dacht juist dat de grotere leercurve van Rust voortkwam uit de substantiële grammar en niet vanuit de omvattende paradigma? Of doel je dan op de borrowing methodiek die gebruikt wordt in Rust? De meldingen die de Rust compiler geeft zijn wel echt een voorbeeld voor vele anderen ja.quote:
De rust taal zelf is relatief gemakkelijk (toegegeven, het omvat wel een hoop). Het is echter het geval dat, als je van een andere taal, een hele andere manier van denken aan moet leren, en dat kan moeilijk zijn. Zo kan je niet even snel iets in elkaar rammelen en er later wel de bugs uit halen. De dingen die andere compilers slikken, slikt de rust compiler dus echt niet en hij geeft dan gewoon doodleuk een foutmelding en legt gelijk uit waar je de fout in gegaan bent.
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
For all who deny the struggle, the triumphant overcome
In bepaalde sectoren gebeurt dat in ieder geval al. Bij CBTC-systemen, is de software in twee delen opgeknipt.
Het ATP-deel (Automatic train protection, de primaire beveiliging tegen onsporing en botsiingen) met een heel beperkte hoeveelheid code waar een independent safety assessor een verklaring voor moet afgeven.
En het ATS-deel (Automatic Train Supervision, dat er voor zorgt dat treinen naar de juiste eindbestemming rijden, waarmee de verkeersleider routes kan invoeren en dat met reisinformatie-systemen gegevens uitwisselt etc) dat uit veel meer code bestaat en relatief minder kwaliteitscontroles heeft.
Het ATP-deel (Automatic train protection, de primaire beveiliging tegen onsporing en botsiingen) met een heel beperkte hoeveelheid code waar een independent safety assessor een verklaring voor moet afgeven.
En het ATS-deel (Automatic Train Supervision, dat er voor zorgt dat treinen naar de juiste eindbestemming rijden, waarmee de verkeersleider routes kan invoeren en dat met reisinformatie-systemen gegevens uitwisselt etc) dat uit veel meer code bestaat en relatief minder kwaliteitscontroles heeft.
Representant van het failliet van de westerse liberale maatschappij
En op welke schaal is dit dan? Nationaal, Europees of zelfs groter? Leuk om te lezen iig.quote:
In bepaalde sectoren gebeurt dat in ieder geval al. Bij CBTC-systemen, is de software in twee delen opgeknipt.
Het ATP-deel (Automatic train protection, de primaire beveiliging tegen onsporing en botsiingen) met een heel beperkte hoeveelheid code waar een independent safety assessor een verklaring voor moet afgeven.
En het ATS-deel (Automatic Train Supervision, dat er voor zorgt dat treinen naar de juiste eindbestemming rijden, waarmee de verkeersleider routes kan invoeren en dat met reisinformatie-systemen gegevens uitwisselt etc) dat uit veel meer code bestaat en relatief minder kwaliteitscontroles heeft.
Ah dat staat in het artikel, dus in Nederland voor de Noord-zuid lijn en de Amsterdamse metro.
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
For all who deny the struggle, the triumphant overcome
O.a. de Amsterdamse Metro inderdaad. Maar in essentie is ERTMS op de HSL-zuid niet anders, behalve dat daar de wal-voertuig-communicatie Europees gestandaardiseerd zijn zodat (in theorie) een Roemeense trein met de Nederlandse infrastructuur kan communiceren.quote:Op dinsdag 2 november 2021 15:04 schreef FlippingCoin het volgende:
[..]
En op welke schaal is dit dan? Nationaal, Europees of zelfs groter? Leuk om te lezen iig.
Dat onderscheid tussen heel beperkt gehouden veiligheidskritische software en 'normaal' geprogrammeerde functionele software zie je wel meer in de industrie. Bijvoorbeeld waar de software die brandmeldingen of oververhitting afhandelt heel klein gehouden is en op een separate, redundant uitgevoerde PLC draait, terwijl de hele bedrijfsvoering en functionaliteiten voor operators parallel draait. De veiligheidskritische PLC wordt dan zo ingericht dat die bij uitval van het netwerk zijn kritische functies autonoom kan uitvoeren. Sturingen door het niet-veiligheidskritische deel gaan dan altijd eerst naar de veiligheidskritische PLC die toestemming moet geven voordat er iets uitgevoerd kan worden. O.a. IC61508 zegt iets over hoe software aan een bepaald SIL-niveau kan voldoen.
Bij auto's zal dat niet anders zijn, je gaat niet de software die de aansturing van de remmen regelt vermengen met software die MP3'tjes afspeelt. Een rem in een personenauto zal iets van (gok ik) SIL3 moeten hebben, terwijl een mentaal gezond persoon geen SIL-niveau gaat eisen voor een MP3'tje of een Tomtom (nog even afgezien van dat je per SIL-level grofweg een 0 achter de ontwikkelkosten mag zetten).
Representant van het failliet van de westerse liberale maatschappij
De taal helpt zeker om bepaalde problemen uit te sluiten of te verminderen maar ook met Rust zal je waarschijnlijk nog steeds bagger programma's kunnen schrijven.quote:
De rust taal zelf is relatief gemakkelijk (toegegeven, het omvat wel een hoop). Het is echter het geval dat, als je van een andere taal, een hele andere manier van denken aan moet leren, en dat kan moeilijk zijn. Zo kan je niet even snel iets in elkaar rammelen en er later wel de bugs uit halen. De dingen die andere compilers slikken, slikt de rust compiler dus echt niet en hij geeft dan gewoon doodleuk een foutmelding en legt gelijk uit waar je de fout in gegaan bent.
Klopt. In de automotive branche wordt al vele tientallen jaren gewerkt met de Misra standaard voor C en C++.quote:
Maar ik neem aan dat voor bepaalde industrieën zoals automotive en luchtvaart als regels zijn m.b.t. software en hoe deze getest wordt.
Voor bepaalde groepen van electronica (hoogste veiligheids klasse) is C en C++ al tientallen jaren niet meer toegestaan door de automobiel fabrikanten
Daarnaast is er ook nog Autosar (ook een automotive standaard) en Cert C.
Voor medische apparatuur weet ik niet de naam van de standaard, maar die is nog vele malen strenger dan in de automotive sector. Alles moet exact gedocumenteerd worden. Ook al verander je maar 1 letter aan de code, dan moet er een rapport komen wat de klacht was, wat de oplossing is, wanneer die is gevonden, wanneer de gewijzigde software is uitgeleverd. etc., etc.
|
|
