Software bulletproof krijgen

Schijnbaar is het moeilijk. Heb zelf een beetje ervaring met Arduino, een programmaatje werkend krijgen lukt meestal weel, maar om het door-en-door robuust te krijgen is een ander verhaal. Tussen professionele producten zit een wereld van verschil. Een bepaald product van merk A werkt jaren feilloos, terwijl hetzelfde product van merk B na een jaar software gerelateerde kuren gaat vertonen. Recentelijk een Philips smart tv aangeschaft, blijkt het ding bijna wekelijks gereset te moeten worden omdat bepaalde functies "ineens" niet meer werken. Je zou denken dat het niet de allerminsten zijn die het apparaat ontworpen hebben.

Hardwarematig snap ik wel hoe je iets fool- en bulletproof moet ontwerpen. Maar hoe pak je dat aan met de softwarematige kant?

Gr.

Erik

Wie daar het antwoord op weet kan heel rijk worden.

Ook software maken is niet meers dan de PDCA cirkel, m.a.w.: Plan Do Check Act/(re-act).
Ergens in die cirkel wordt op de centjes beknibbelt. Mag je zelf invullen waar......

Overigens geldt er nog een tweede probleem, tijdsdruk i.v.m. concurrentie. Tegen de tijd dat jij jouw software hebt uitontwikkeld heeft de concurrent als 10 nieuwe betere types op de markt gebracht.

[Bericht gewijzigd door Hugo Welther op (37%)]

Philips zegt in de TV wereld helemaal niets, want philips maakt al jaren geen TV's meer.

Wat ik wel hoor van mensen in mijn omgeving die de fout gemaakt hebben een TV aan te schaffen waar 'Philips' op staat is dat deze minder dan stabiel zijn.

Het ontwerpen van goede software is niet fundamenteel anders dan het ontwerpen van goede hardware.

Het begint met het goed specificeren van het systeem, het verdelen van verantwoordelijkheden tussen hardware en software, en specificeren de functies en uitzonderings situaties. Daarna is het belangrijk om het high level ontwerp zo te doen dat je een bewijsbaar correct systeem krijgt.

Ja gaat dan van de high level specificaties naar afgeleide low level specificaties, en vanaf daar naar code. Elke high level specificatie moet terug te leiden zijn naar een systeem specificatie, elke low level specificatie naar een high level. Als dat niet zo is, is ofwel je high level specificatie onvolledig en moet die aangevuld worden, of de low level specificatie is nergens op gebaseerd en moet geschrapt worden. Vervolgens ga je aantonen dat de high level specificaties volledig afgedekt worden door de low specificaties.

Dan pas ga je software schrijven; elke regel code moet daarbij te herleiden zijn naar een specificatie; zo niet, dan is de specificatie onvolledig of de code hoort er niet in.

Ja dit is heel veel werk, maar dit is hoe de luchtvaart werkt voor kritische systemen.

Ik ontwerp elektronica en software voor de kleine luchtvaart.

Het is een kwestie van vooraf alles goed doordenken. Je kunt beter een paar dagen langer erover doen als dat betere software/firmware oplevert.
Bijvoorbeeld met toets routines. Normaal druk je maar 1 toets in, maar wat gebeurt er als je meerdere tegelijk indrukt?
Zelfde voor waitloops voor statusveranderingen. Daar moet altijd een time-out in zitten. Anders blijft het programma daar eeuwig hangen bij problemen...
En zo zijn er zoveel zaken die bekeken moeten worden...

Helaas zijn er ook onbekwame programmeurs werkzaam bij de grote elektronica producenten en wordt vaak de software ook nog eens onvoldoende getest.

Wil je een prima programmeur worden dan moet je al een paar eigenschappen bezitten die echt noodzakelijk zijn.

- analytisch vermogen bezitten.
- wiskundig goed onderlegd zijn.
- uitstekende kennis van Assembly is een must. ( ook al is het alleen om te debuggen )
- creatief zijn.
- logische korte oplossingen kunnen verzinnen. ( vereenvoudigen )
- algoritmen en datastructuren bestuderen en kunnen toepassen.
- lowlevel kennis van de CPU MCU etc.
- begrijpen wat je aan het doen bent.
- ruimdenkend zijn en dus oplossingen willen en kunnen bespreken met collega's

Voordat je gaat programmeren, maak je eerst een robuust stappenplan waarbij je gebruik maakt van de mogelijkheden die voorhanden zijn en dus ook realiseerbaar zijn.
Uitsluiten van ongewenste stappen en mogelijkheden. ( maak een stroom diagram )
Gedegen kennis van de hardware registers ( bestudeer de datasheets dus aandachtig UART, Timers etc.)
Maak als eerste een gedegen framework: initialisatie hardware registers, geheugen management, timers, eventueel visualisatie etc.
Daarna de subroutines/functies een voor een. ( pas hier telkens een sanity-check op toe )
Maak gebruik van error-checking.

Er zijn meerdere wegen die leiden naar een oplossing, doe en denk niet te ingewikkeld, houd het simpel en kies de kortste weg.
- Tip, werk van achter naar voren.
- Maak gebruik van booleaanse algebra o.a. handig voor bit-manipulatie en lussen.

Vaak voorkomend probleem: opeens doet die functie het niet meer....

- Memory overflow, maak een betrouwbaar geheugen management. ( reserveer voldoende ruimte en ruim de boel op alvorens door te gaan )
- Verkeerd gebruik van conditionele jumps ( check de flags !!! )
- Meerdere pointers die verwijzen naar dezelfde data en onderling worden veranderd door meerdere subroutines.
- Het gebruik van libraries waarvan je de werking niet weet of gewoon slecht zijn geschreven.

Dan heb je nog de keuze van welke programmeertaal te gebruiken....

Met een compiler ( C, C++, Basic etc.) ben je afhankelijk wat voor code er wordt gegenereerd en heb je dus niet de volledige controle en wordt er extra onnodige code aan je programma toegevoegd. Meestal is de code ook niet optimaal.

Wil je volledige controle en dus optimaal snelle en korte code dan gebruik je een Assembler.
Een Assembler hoeft niets te compileren dus de code wordt uitgevoerd zoals jij hem hebt geschreven.

Ik denk dat tegenwoordig ook meespeelt dat "men" zoveel van een TV verwacht dat het niet zomaar: "we gaan deze week de software maken voor de nieuwe TV" is, maar dat er ook diverse andere stukken software bij betrokken zijn (denk: android en allerlei bibliotheken). Deels omdat het op een onverwachte manier gebruikt wordt, deels omdat de integratie niet goed gedaan is kan je dat soort instabiliteiten krijgen.

Als ontwerper is trouwens "een week normaal gebruiken" van de TV lastig. Je reboot de boel regelmatig en gebruikt hem niet normaal. Dus die fout die jij ziet, zijn zij niet tegengekomen tijdens de ontwikkeling.

Belangrijk is ook om het complete product te laten testen door een aantal mensen die er verder niets van afweten.
Vaak weten die binnen 30 seconden dingen te doen, die je zelf nooit voor mogelijk had gehouden... :)

Nog een reden om geen slimme TV te willen.

Als het ding smart moet worden doe ik dat zelf wel dmv een losse voorzetdoos die ontworpen is te doen wat ie moet doen, gemakkelijk bijgewerkt kan worden en als het vervelend gaat doen of outdated is de container in kan.

Helaas denkt de gemiddelde eindgebruiker daar anders over en worden die dozen zo vol mogelijk gestampt met software (voller dan die tv van de concurrentie iig) zolang de arme uitgeknepen CPU in het ding het nog net kan bolwerken.

Mijn grootste ergernis met software, je koopt het en gebruikt het, dan kom je erachter dat er een fout in zit, en om die fout opgelost te krijgen hebben ze een update, of je dan even opnieuw wil betalen voor de update :(

Ergerlijk vindt ik ook dat je steeds meer software niet eens meer kunt kopen, maar moet huren... :(   (zoals Microsoft Office 365 e.d.)

Ik heb mijn office toch nog netjes kunnen kopen. Bij Eagle blijkt het niet meer mogelijk. :-(

Gaan we vloeken, Arco? :)

Microsoft kun je niet kopen , is huren, lees de gebruiksovereenkomst maar...
Maar Microsoft moet je niet willen...

[Bericht gewijzigd door mel op (19%)]

Ik verkies MS altijd nog boven Google ;)

Op 18 februari 2017 13:11:23 schreef mel:
Gaan we vloeken, Arco? :)

Ikzelf heb daarom geen MS Office, maar OpenOffice... ;)
Bij veel software ben je genoodzaakt een service abonnement te nemen, anders krijg je geen updates meer.
Zoals mijn boekhoudprogramma. Ieder jaar betalen, en maar eens in de paar jaar een kleine update...   (klachten worden helemaal niet opgelost :( )

Voor sommige zaken moet je betalen zonder duidelijke reden. In het verleden wel eens gevraagd naar beschrijving van OpenTherm. (er is weinig 'open' aan... :) )
Moet je ieder jaar 2750.- euro betalen. Bij de vraag waar dat voor was: "we moeten ons kantoor en personeel toch ook ergens van betalen?...

[Bericht gewijzigd door Arco op (61%)]

Op 18 februari 2017 13:10:15 schreef buckfast_beekeeper:
Ik heb mijn office toch nog netjes kunnen kopen. Bij Eagle blijkt het niet meer mogelijk. :-(

Met Eagle ga je toch niet vrijwillig werken toch? :-)

Er is inderdaad veel software-zooi op de wereld. Ik gebruik zelf zoveel mogelijk open source, da's niet altijd beter, maar je hebt het gevoel dat je niet 'genomen' wordt. Mijn office pakket is Libre Office en zolang er mij niemand een sheet, text document... met ingebouwde VBA functies aangeeft, is het grotendeels compatibel met MS-Office. Schema en print ontwerp doe ik met KiCad, software ontwikkeling met Code::Blocks en GCC. Ik gebruik deze dingen zowel voor mezelf als hobby, maar ook als ik wat ontwerp, maak, schrijf... voor derden.

Mij lijkt software idiot-proof te krijgen een stuk moeilijker dan hardware. Dat laatste is tast-, meet- en reukbaar :-)

Software blijft altijd een beetje mystiek. Zoals hier al een paar keer is aangegeven, een gedegen kennis van de loop van het programma en de controller/computer is een noodzaak. Maar niet alleen dat.Ook en vooral kennis van het ding waarvoor de software moet dienen. Veel programmeurs zijn heel goed in wat ze doen, maar begrijpen niet altijd waarvoor het ding moet dienen, wat het in de echte wereld moet/gaat doen. Als je zelf dingen maakt van de grond af, dan heb je het overzicht van begin tot einde, maar in de grote boze wereld werken we niet alleen. En daar loopt meestal wat mis, de communicatie tussen de verschillende departementen, commerciele overwegingen...enz.

Ik denk dat het nog wat erger gaat worden, als je ziet wat er allemaal gemaakt en geschreven wordt in de 'Maker community'...pfft, da's soms huilen met de pet op. :'(

Groetjes,
eSe

Een van de eerste dingen die ik leerde toen ik begon met programmeren was het begrip KISS.

Keep it simple, stupid
Keep it short and simple
Keep it simple & straightforward
Keep it smart & simple.

Destijds in 1984 was dat nog op een Commodore 64 in basic en assembly.
Ook toen was het met de beperkte hard en software al mogelijk om fouten in je programma te laten sluipen.
Nu is zowel de hard als de software een magnitude uitgebreider en gecompliceerder geworden.
Van simpel kan op dit moment bij een TV weinig sprake meer zijn.
In een eenvoudige TV zitten inmiddels zoveel hard en software features ingebouwd dat er naar mijn idee geen programmeur bestaat die dit in zijn eentje kan overzien en behappen.
Om dit te beperken tot alleen al de hardware,

Digitale tuner:

Analoge tuning
Common Interface
DVB-C
DVB-T
DVB-S
Decoderings software
Landspecifieke beperkingen
Beheer van ontvangstrechten

Interfaces:

HDMI
Merkspecifieke HDMI features
DVI
SPIDIF
Toslink
DisplayPort
USB
LAN
Wireless LAN
Bluetooth
Remote control

Verder:
Screencontroller
Backlight controller
Bedieningstoetsen
Lichtsensoren
IR ontvanger
Microfoons
Ambilight
Etc.

Dit alles is aan elkaar geknoopt via I2C, uart, parallel verbindingen, video bussen etc.
De meeste van deze componenten worden extern ingekocht en hebben hun eigen gebruiksaanwijzing en protocollen.

Mag je dan als programmeur eens een foutje maken?

Software is enorm snel enorm complex geworden. Ergens hierboven wordt assembler aanbevolen, wel, wie dat schrijft die heeft op een manier wel een punt maar is een jaar of dertig achter op de tijd. De opkomst van de GUI was de afgang van assemblerprogrammatie: zo'n complexe toestanden red je niet meer in assembler. Bovendien ben je voor ongeveer alles wat je vandaag nog kunt doen afhankelijk van libraries vanwege derde partijen.

Mijn ideetjes:

* inderdaad open source gebruiken, dan is het tenminste in theorie nog uitvogelbaar

* ieder project opdelen in zoveel mogelijk kleine deelprojectjes, met duidelijke interfaces en logging tussen die modultjes, dan kun je tenminste redelijk vlot uitvlooien waar het precies mis gaat. Daarmee laat je trouwens ook het O/S de ruimte om resources toe te kennen aan al die deelprocessen alnaargelang nodig.

Omdat de software steeds beroerder wordt, worden onze computers ook steeds sneller om dat op te vangen... :)
(in assembly is geen probleem, maar wel tijds intensiever om te schrijven)
Bij vergelijkbare OS zoals Windows NT (in C) en OS/2 (in assembly) was OS/2 ongeveer 5x sneller...

Bugs zullen er altijd zijn; in de eerste versies van Windows NT zaten er meer als 173.000...

Foutvrije code schrijven kan wel. Vooral embedded is dat mogelijk. Op PC's is het moeilijker omdat je een hoop externe code hebt waarvan je eigenlijk maar half weet wat het doet.

Ik heb bij Philips 10 jaren embedded gedaan. Mijn ervaring is dat de betrouwbaarste resultaten worden behaald met de eenvoudigste compilers. Ik heb geschreven in C, maar ook in PLM.

Maak zeer goede specs en vooral op het gebied van interfaces. Wat praat met wat. Wat hadden we ook al weer? User Interface spec, requirements spec, interface spec en ga maar door.

Waar gaat het dan fout tegenwoordig? Zelfs als de code goed lijkt zijn er twee zwakke punten: garbage op stack en heap met C-achtige talen. Maar vooral ook als zaken parallel lopen en de programmeur gewoon rechtstreekse code schrijft (if knop==aan then run motor) in plaats van met state machines te werken.

Op 18 februari 2017 16:09:04 schreef Hoeben:
Foutvrije code schrijven kan wel. Vooral embedded is dat mogelijk.

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.

@Erik hieronder: en nee, ook in het vliegtuig waarmee jij vliegt zitten bugs in de software. Het gaat om kansen. De kans dat jij net getroffen wordt door de zeldzame situatie is erg klein. Maar zeker in dat soort complexe apparatuur zitten enorm veel bugs.

[Bericht gewijzigd door flipflop op (29%)]

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