Software bulletproof krijgen

In dit geval zou ik de programmmeur ontslaan en twee schakelaars aanschaffen.

Dat moet voor elke situatie apart ingeschat worden, maar @Hoeben heeft zeer terecht opgemerkt dat state machines mooie dingen zijn.

Om even bij de hardware te blijven en tegelijk de computernostalgici aan te spreken: de aloude Apple ][ had een (naar de toenmalige normen uitermate primitieve) floppy fisk controller, die encoding/decoding deed met een state machine die als bipolaire PROM was geïmplementeerd. Zo simpel, zo mooi.

Op 18 februari 2017 17:23:02 schreef erik1234:
De vliegtuigindustrie word aangehaald door Sparky, mooi voorbeeld dat software wel (ik denk nagenoeg) foutloos gemaakt kan worden.

if knop a == true then lamp1 = on
if knop a == false then lamp1 = off
if knop b == true then lamp2 = on
if knop b == false then lamp2 = off

Nu blijkt dat na eindeloze tests dat bij het indrukken van a en b tegelijk dat de lampen beginnen te knipperen en alleen een reset dit kan verhelpen.

Hoe hoort programmeur dit soort ongewenste effecten te voorkomen? De software kent geen ongewenste situaties en negeert ze dus gewoon? 

if knop a == true then lamp1 = on
if knop a == false then lamp1 = off
if knop b == true then lamp2 = on
if knop b == false then lamp2 = off

Of elke mogelijke ongewenste situatie staat beschreven in de software? 

if knop a == true && knop b == true then.....

Of elk stukje code heeft een foutafhandeling?

if knop a == true then lamp1 = on
else......

Gr.

Erik

Met booleaanse algebra n.l. exclusief or

XOR a,1 lamp aan
XOR a,1 lamp uit etc.

( als a == 0 dan a wordt 1, als a == 1 dan a wordt 0 )

@ big_fat_mama, Assembly heeft zich in de laatste 30 jaar ook aangepast aan de moderne tijd hoor. Ik programmeer al 35 jaar in assembly ( Windows, ja ook de API's en GUI's en de laatste 15 jaar ook microcontrollers ).
En daarbij vind ik assembly veel overzichtelijker dan b.v. C++.

Ieder zijn ding natuurlijk. Maar assembly zal altijd blijven bestaan.

Op 18 februari 2017 20:18:00 schreef Siekmanski:
[...]

En daarbij vind ik assembly veel overzichtelijker dan b.v. C++.

Eindelijk iemand die snapt wat ik ook al jaren roep. Ik ben van basic rechtstreeks op assembly overgestapt (zelfstudie) en vond dat eigenlijk verbazingwekkend makkelijk en inderdaad overzichtelijk. Onder DOS en wel met een bibliotheek (meegeassembleerd of TSR, het concept van linken, DLL's e.d. was me nog iets te hoog gegrepen) voor ingewikkelder functies, de interface en het grafische werk onder DOS, maar onder Windows heb je dat eigenlijk allemaal al in de diverse API's zitten wat eigenlijk ideaal is voor werken in assembly (nooit geprobeerd, maar in theorie volgens mij wel). Pas later kennisgemaakt met Pascal, C, Modula 2, TCL, Java ugggh.. gggg.. aaaaggg sorry er schiet even wat in m'n keel na dat laatste woord. Ik programmeer de laatste jaren eigenlijk niet meer, volgende project zal wel PHP of Python zijn of iets dergelijks tenzij het zakelijk interessant blijkt om een oud in TCL geschreven project weer uit de kast te trekken.

Op 18 februari 2017 16:18:28 schreef flipflop:
[...]
Famous last Words :-)
Je moet het als programmeur steeds weer beweren, terwijl je maar al te goed weet dat het niet zo is. Jammer dat dat moet.
@

Onzin. Ik heb stapels foutvrije code gebouwd. Als het klein genoeg is zodat het overzichtelijk blijft kan dat zeker. En als het groter is en je de juiste systematiek aanhoudt lukt dat ook wel. Niet op PC's, ik heb het over embedded.

Ok, ik zal het een beetje nuanceren: als de code op 1 A4tje past kun je gelijk hebben. Geen interrupts, weinig i/o, weinig periferals....

Trouwens, hoe weet je dat jouw code foutloos was?

[Bericht gewijzigd door flipflop op (16%)]

Je weet nooit of je code foutloos is. Ik heb code gehad die op heel veel apparaten foutloos liep, en toch kwam er na 12 jaar nog een bug uit... ;)

Op 18 februari 2017 17:23:02 schreef erik1234:

if knop a == true then lamp1 = on
if knop a == false then lamp1 = off
if knop b == true then lamp2 = on
if knop b == false then lamp2 = off

Goede code maak je door het eenvoudig te houden: 

lamp1 == knop1
lamp2 == knop2

Nu blijkt dat na eindeloze tests dat bij het indrukken van a en b tegelijk dat de lampen beginnen te knipperen en alleen een reset dit kan verhelpen. Hoe hoort programmeur dit soort ongewenste effecten te voorkomen? De software kent geen ongewenste situaties en negeert ze dus gewoon? Of elke mogelijke ongewenste situatie staat beschreven in de software?

Nee, in plaats van alle fouten op te sommen moet je alleen de goede mogelijkheden nemen. Veiliger, fouten kun je over het hoofd zien.

De lampen kunnen gewoon met logica, sluit uit dat beide lampen aangezet worden. If statement moeten altijd een else hebben of de else moet ongevaarlijk zijn.

lamp1 == knop1 && not knop2
lamp2 == knop2 && not knop1

En toch is dit NIET veilig! Denk eerst even na voor je verder leest en je het voor jezelf bederft: Wat is er fout?

Hier komt hij dan:

Lamp 1 leest de knoppen en gaat aan omdat alleen knop 1 ingedrukt is en 2 niet. Maar als je net de knoppen in aan het drukken bent schakelt er nogal wat en kan op het moment dat de 2e lamp de knoppen leest de stand van de knoppen anders zijn en de 2e lamp toch aangaan!

Dus wat doe je dan:

lamp1 == knop1 && not knop2 && not lamp2
lamp2 == knop2 && not knop1 && not lamp1

Maar ook dit is niet goed. Want dan ben je de toestand van een lamp van een ander stuk code afhankelijk aan het maken (wat de code van lamp 1 uitvoert hangt af van de code van lamp 2). Hier is het nog supermakkelijk te overzien. Maar als je duizenden regels code hebt raak je de weg kwijt en krijg je een worst van een programma. Dus hoe los je dit op?

stap 1 lees ingangen
stap 2 zet uitgangen


Var Btn1, Btn2 : boolean // jaja, ik kom uit de Delphi/ modula2 wereld
//stap1
btn1 == knop1
btn2 == knop2
//stap2
lamp1 == btn1 && not btn2
lamp2 == btn2 && not btn1

In bouwen met state machines doe je eerst io en je loopt daarna de statemachines af. Foutloos bouwen kan maar kost wel werk en tijd. Naarmate alles groter wordt, wordt het moeilijker, niet "onmogelijker".

Op 18 februari 2017 22:23:58 schreef Arco:
Je weet nooit of je code foutloos is. Ik heb code gehad die op heel veel apparaten foutloos liep, en toch kwam er na 12 jaar nog een bug uit... ;)

Ik kwam na anderhalf jaar nog achter een bug in een 10k regels .NET programma wat al sinds de start foutloos draait. Geen vastloper, maar er ontbrak ergens een sort van een array.

Als ik software schrijf dan neem ik altijd aan dat alles wat fout kan gaan, ooit eens fout zal gaan. Alle user input krijgt ooit iets fouts voor z'n kiezen, alle lees en schrijf functies kunnen ooit falen als er een mapje onbreekt of iets dergelijks, apparaten aan COM poorten kunnen vastlopen of uit staan, van alles en nogwat. In .NET is dat makkelijk, je kan van iedere functie opzoeken in welke gevallen je welke error terugkrijgt. Kwestie van anticiperen en zorgen dat een mogelijke error afgehandeld wordt. Let wel, het zelf gooien van een fatal error waarna je het programma afsluit valt ook onder afhandeling. Het 'laat de fatal error maar gebeuren en het programma vliegt er vanzelf wel uit' niet.

Op 18 februari 2017 17:23:02 schreef erik1234:
Nu blijkt dat na eindeloze tests dat bij het indrukken van a en b tegelijk dat de lampen beginnen te knipperen en alleen een reset dit kan verhelpen.

Dat is typisch een 'we fixen het wel in software' oplossing. Fix eerst de hardware maar eens.

[Bericht gewijzigd door klein is fijn op (13%)]

Op 18 februari 2017 22:33:09 schreef Hoeben:
[...]
Nee, in plaats van alle fouten op te sommen moet je alleen de goede mogelijkheden nemen.

Op 18 februari 2017 22:43:16 schreef klein is fijn:
[...]Kwestie van anticiperen en zorgen dat een mogelijke error afgehandeld wordt.

Altijd fijn die tegenstrijdige adviezen :-) Lijkt me trouwens een vrijwel onmogelijke opgave om alle mogelijke fouten te kunnen voorspellen en dus softwarematig uit te sluiten. Lees hier ook regelmatig over "debugging", zit daar ook een bepaalde systematiek in? Anders gezegd; hoe gaat dat in zijn werk?

Gr.

Erik

Kwestie van anticiperen en zorgen dat een mogelijke error afgehandeld wordt.

20 Jaar geleden bij Esso (raffinaderij software) eens een studietje gedaan en van de totale code was 80% van de code foutafhandeling en 20% "echte" functionaliteit.

Leuk boek hier nog over :
https://www.amazon.com/Art-Programming-Embedded-Systems/dp/0122748808

[Bericht gewijzigd door bprosman op (16%)]

Op 18 februari 2017 23:50:41 schreef bprosman:
[...]
20 Jaar geleden bij Esso (raffinaderij software) eens een studietje gedaan en van de totale code was 80% van de code foutafhandeling en 20% "echte" functionaliteit.

Dat is mijn ervaring ook.

Op 18 februari 2017 23:46:54 schreef erik1234:
Altijd fijn die tegenstrijdige adviezen :-) Lijkt me trouwens een vrijwel onmogelijke opgave om alle mogelijke fouten te kunnen voorspellen en dus softwarematig uit te sluiten. Lees hier ook regelmatig over "debugging", zit daar ook een bepaalde systematiek in? Anders gezegd; hoe gaat dat in zijn werk?

Niet tegenstrijdig: we hebben het niet over fouten in code maar fouten in io. Bijvoorbeeld een seriële verbinding die verbroken is door kabelbreuk. Je mag daar niet vastlopen, maar je gaat die pollen en op een timeout iets doen als een foutmelding.

De beste debugging is geen debugging. Logging vind ik handiger.

Op 18 februari 2017 22:43:16 schreef klein is fijn:
[...]

[...]Dat is typisch een 'we fixen het wel in software' oplossing. Fix eerst de hardware maar eens.

In hardware bouw je veiligheden in. Inputvalidatie werkt het beste als je zowel hardware als software op orde hebt. Het uitlezen van meerdere toetsen tegelijk is opzich wel embedded programming 101, dus ik ben in dit specifieke geval wel benieuwd wat je in hardware wilt fixen.

In dit geval is de oplossing, weten wat er gebeurt in de hardware en hoe dat eenvoudig op te lossen in de software.

Hardware - Wanneer je een knop indrukt krijg je te maken met een korte periode waar "wel/geen/wel/geen/wel/geen/wel" contact bestaat.

Software - Dit moet je opvangen in de software met een "debouncing" routine, waarin je dus deze periode overslaat en zeker weet dat de knop "in wel contact staat" en de software dit afhandelt als 1 druk op de knop.

Als ik het goed begrijp, wil je dus 2 lampen elk afzonderlijk met 1 druk op de knop ( elke lamp zijn eigen knop ) aan of uit kunnen zetten ?

Dit kan je doen door na de "debouncing routine", m.b.v. booleaanse algebra ( je veranderd de bit voor aan/uit met 1 commando -> "exclusive or", 1 wordt 0 of 0 wordt 1 )
Dus je hoeft geen checks uit te voeren of de lamp nu aan of uit is. 1 druk op de knop verandert de status van de lamp van aan naar uit of van uit naar aan.

Hoe je dit programmeerd is afhankelijk van de taal die je gebruikt.
Voor het afhandelen van het debouncing fenomeen, zou je via een timer-interrupt automatisch de status van de invoer van de knoppen kunnen laten afhandelen.

In je programma schrijf je een routine die dan de status van je knop uitleest en de lamp dan aan of uit zet.
Dus geen lampen meer die automatisch aan en uit blijven gaan en je dus moet resetten.

Hier een voorbeeldje van de 2 routines in assembly.

ToetsenInterrupt:
	push	r16		
	in	r16,SREG 
	push	r16
	out 	TCNT0,Interrupt0Teller	; stel interrupt-teller weer in

	push	r1
	push	r2
	mov	r1,ToetsOud
	in	ToetsOud,ToetsenInvoer
	eor	r1,ToetsOud
	com	ToetsOud
	mov	r2,ToetsStatus
	or	ToetsStatus,r1
	and	r1,ToetsOud
	eor	ToetsStatus,r1
	and	r2,r1
	or	ToetsGedrukt,r2
	pop	r2
	pop	r1

	pop	r16
	out	SREG,r16
	pop	r16
	reti

WachtOpToets:
	cli
	mov	r16,ToetsGedrukt
	clr	ToetsGedrukt
	sei
	tst	r16
	breq	WachtOpToets
	ret

; hier de afvraag van de toetsen ergens in je hoofdlus.
BedienLampen:
	rcall	WachtOpToets
	cpi	r16,1	; is toets 1 ingedrukt ?
	breq	Lamp1
	cpi	r16,2	; is toets 2 ingedrukt ?
	breq	Lamp2
; etc
        ret

Lamp1:  eor     LampA,1  ; exclusive or
        ret
Lamp2:  eor     LampB,1  ; exclusive or
        ret

En hoe maak je code foutloos.....

Gewoon een "Sanity Check" uitvoeren.

Je roept elke routine 1 voor 1 aan met alle invoer-waarden die er mogelijk zijn en bekijk dit met een Debugger.
Ja, je hebt hier wel kennis van de Assembly taal voor nodig ongeacht in welke taal het is geschreven.

Wanneer je een Compiler hebt gebruikt om te programmeren kan je gelijk zien wat voor code deze Compiler er van maakt en zal je ontdekken wat voor extra "onnodige shit code" eraan toegevoegd wordt.

En hoe maak je code foutloos.....
Gewoon een "Sanity Check" uitvoeren.

De "gewone" code debuggen lukt ook wel en na een paar jaar heb je ook een bibliotheek opgebouwd met "foutloze" routines.

De echte uitdaging zit echter in situaties waar een knop of ingang (A/D) uitgelezen wordt en iemand op dat zelfde moment een lasapparaat aanpikt. Of een sensor uitlezen en wat gebeurt er als de sensorkabel breekt. Een slagboom (uitrijlus) wat als je ineens TWEE aanhangers hebt (treintje).

Alle situaties waarvan je vantevoren bedenkt "dat gaat nooit voorkomen" komen een keer voor.

Hallo bprosman,

Dat zijn situaties waar je van te voren rekening mee moet houden en eventueel elektronisch kunt opvangen en verwerken in je software.
Daarom is het ook zeer belangrijk om een gedegen stappenplan te maken en ongewenste situaties moet uitsluiten zoals ik eerder al heb omschreven.
In de praktijk is dit natuurlijk niet zo eenvoudig.

Als alle situaties in kaart zijn gebracht kan men hiervoor "bullet-proof" software schrijven.
Inderdaad, als in de praktijk blijkt dat een ongewenste situatie over het hoofd is gezien, heb je pech en moet dit hersteld worden.

Het is veel fijner als eea "vanzelf goed gaat", dus dat je minder code hoeft te schrijven voor "foutafhandeling" (die 80% die hierboven genoemd wordt).

Het probleem met het actief SCHRIJVEN van de foutafhandelende code is dat je gegarandeerd iets vergeet of verkeerd doet. Een probleem met foutafhandelende code is dat het heel lastig is om alle fout-afhandel-trajecten daadwerkelijk te testen onder realistische omstandigheden. Tuurlijk, je kan, als je ambitieus bent om de code te testen zorgen dat bepaalde functies een fout teruggeven en dan kijken wat er gebeurt.

Maar stel je doet een read van een serieele port. Stel je injecteert een fout in die read, en dan gaat je code een "foutafhandeling traject" in. Als je nu diep in een "systeem afsluiten" functie toch weer naar dat device gaat lopen schrijven, gaat dat in de praktijk als de poort fouten geeft ook fout. Maar in de test niet. Als je code dan in de praktijk een tweedekeer de fout-afhandeling ingaat kan er iets onverwachts gebeuren wat je niet getest hebt.

Kortom, ik ben voorstander van een structuur waarbij je zo min mogelijk foutafhandelings-code hoeft te schrijven. Van ongeteste code kan je er op vertrouwen dat het niet werkt. Dus 80% van je code schrijven terwijl je daar niet meer dan de helft adequaat van kan testen... Niet goed.

De beste softwareschrijver is dhr B Gates. Ik krijg regelmatig security updates van hem omdat hij iets over het hoofd heeft gezien. Foutvrije software bestaat dus niet.

Schrijft Bill nog software dan? :7

En was hij ooit de beste? Zijn BASIC is wel redelijk wijd verbreid geraakt, maar toch?

De heer Gates heeft een leuk bedrijfje opgezet, maar is enige tijd geleden uit dat bedrijf gestapt als bestuurder. Mogelijk heeft ie nog wel een paar aandelen.

Ik mis toch een paar belangrijke onderwerpen in deze discussie.

Iedereen die een computer heeft is systeembeheerder en programmeur. Denkt men. In de tijd dat ik op school zat, was programmeren nog een HBO-opleiding. Niet omdat omdat niet zomaar iedereen zomaar een programmeertaal kan leren, maar omdat programmeren MOEILIJK is. Om het GOED te doen. We vinden het heel normaal dat we onze auto naar de garage brengen voor onderhoud en een huis ontwerpen beginnen we al helemaal niet aan. Maar programmeren, dat kan "iedereen".

In de hobbysfeer is dat geen probleem, maar het niveau van bijna alle commerciële software komt hier nauwelijks bovenuit. Waarom zou je iemand in dienst nemen die ervoor geleerd heeft als iemand "hetzelfde" voor de helft van het geld doet.

En DAT is dus het probleem. Knutselaars en beunhazen. Ik voorzie dat dit nog eens een zodanig probleem wordt dat het maatschappelijke impact gaat hebben (dat er doden vallen door de talloze bugs in medische software, dat je privé gegevens op straat liggen door slechte beveiliging enz. enz.)

En overigens, software kán zonder bugs zijn. Er is een methode om dat wiskundig te bewijzen. Zolang je dat niet gedaan hebt, kun je geen enkele uitspraak doen over het aantal bugs in je code.

En overmoed, altijd die overmoed. We vinden allemaal onszelf de beste programmeurs, dus warnings van compilers hoeven we niet op te letten, we hoeven ook geen duidelijke code te maken, want we weten immers zelf wel wat het doet. En vooral altijd moeten we laten zien wat voor "slimme" dingen we kunnen, terwijl de code minder overzichtelijk wordt, dus meer kans op fouten.

Nu is de definitie van 'bug' ook nog wel flexibel... :)
Velen vinden een bug pas en bug als die inderdaad optreedt in software tijdens gebruik.
Ik vind alle afwijkend gedrag van software een bug als er een mogelijkheid is dat het ooit op zou kunnen treden. (hoe sporadisch ook)

Voorbeeld zijn hedendaagse libraries voor I2C communicatie. De meeste zijn 'blocking' als er een ernstige fout optreedt met een slave.
(ze lopen dan vast omdat er in een loop op antwoord wordt gewacht wat nooit komt)
Ik schrijf daarom mijn I2C libraries altijd zelf (met timeouts op dit soort zaken). 't Is tenslotte een voorspelbaar gedrag dat het ooit kan gebeuren.

Uit de eerste versie van Windows NT hebben ze destijds ruim 173.000 bugs gehaald...

Ook de hardware fouten niet vergeten, 'remember Pentium bug', iets met de floating point hardware. Dacht ik. Processors worden alsmaar ingewikkelder, SOC's, GPU's, moderne memory modules...

En het word door mensen gemaakt :-), niet altijd logisch denkende biologische blob's.

Groetjes,
eSe