Embedded codevalidatie is lastig, vooral als het gaat om onderdelen met beperkte bronnen, zoals PIC's. Je hebt vaak niet de luxe van coderen in testgevallen vanwege de geheugenbeperkingen van het onderdeel en de vaak "realtime" programmering op dit soort apparaten.

Hier zijn enkele van mijn richtlijnen :

1. Schrijf een specificatie als die er niet is: Als u niet codeert tegen een specificatie, documenteer dan wat uw code zou moeten doen, wat zijn geldige inputs, wat zijn verwachte outputs, hoe lang zou elke routine moeten duren, wat kan en kan niet in de war raken, enz. - een theorie van de werking, stroomdiagrammen, alles is beter dan niets.

2. Geef commentaar op uw code: het feit dat iets voor u duidelijk is, betekent niet dat het voor iemand anders duidelijk (of correct) is. Commentaar in gewone taal is nodig voor zowel controle als voor onderhoud van de code.

3. Code defensief: Voeg niet alleen code toe voor normale invoer. Omgaan met ontbrekende invoer, invoer die buiten bereik is, wiskundige overlopen, enz. - hoe meer hoeken u afdekt met uw codeontwerp, hoe minder vrijheidsgraden de code zal hebben wanneer deze wordt geïmplementeerd.

4. Gebruik statische analyse-instrumenten: het kan vernederend zijn hoeveel bug-tools zoals PC-lint in uw code kunnen vinden. Beschouw een zuivere statische analyse als een goed startpunt voor serieuze tests.

5. Peerrecensies zijn essentieel: uw code moet schoon en goed gedocumenteerd zijn voldoende dat het efficiënt kan worden beoordeeld door een onafhankelijke partij. Controleer je ego bij de deur en overweeg serieus eventuele kritiek of suggesties.

6. Testen is essentieel: u dient uw eigen validatie uit te voeren, evenals een onafhankelijke validatie van de code. Anderen kunnen uw code breken op manieren die u zich onmogelijk kunt voorstellen. Test elke geldige voorwaarde en elke ongeldige voorwaarde die u maar kunt bedenken. Gebruik PRNG's en voer afvalgegevens in. Doe wat je kunt om dingen kapot te maken, repareer ze en probeer het opnieuw. Als je geluk hebt, kun je je code in de foutopsporingsmodus uitvoeren en naar registers en variabelen kijken - zo niet, dan moet je slim zijn en LED's / digitale signalen omschakelen om een ​​idee te krijgen van de staat van je apparaat. Doe wat nodig is om de feedback te krijgen die u nodig heeft.

7. Kijk onder de motorkap: wees niet bang om naar de machinecode te kijken die wordt gegenereerd door uw C-compiler. U kunt (zult?) Plaatsen vinden waar uw prachtige C-code is opgeblazen in tientallen, zo niet honderden bewerkingen, waar iets dat veilig zou moeten zijn (aangezien het maar één regel code is, toch?) Zo lang duurt om uit te voeren dat meerdere interrupts hebben ontslagen en de voorwaarden ongeldig gemaakt. Als iets vreselijk inefficiënt wordt, refactuur het dan en probeer het opnieuw.

De meeste van dezelfde technieken voor het maken van betrouwbare software op een pc zijn ook van toepassing op embedded ontwikkeling. Het is handig om uw algoritmen te scheiden van de hardwarespecifieke code en deze afzonderlijk te testen met unit-tests, simulaties, statische analyse en tools zoals Valgrind. Op die manier is er veel minder code die alleen op de hardware wordt getest.

Ik zou C niet verlaten. Hoewel talen zoals Ada enkele kleine garanties kunnen bieden, is het gemakkelijk om in de val te trappen door de taal belooft meer dan het in werkelijkheid doet.

MISRA-C is inderdaad erg handig om de algemene codekwaliteit te verbeteren en bugs te minimaliseren. Zorg ervoor dat u elke regel leest en begrijpt, de meeste zijn goed, maar een paar kloppen niet.

Een waarschuwing hier. Het MISRA-document gaat ervan uit dat de lezer iemand is met uitgebreide kennis van de C-taal. Als je niet zo'n doorgewinterde C-veteraan in je team hebt, maar besluit om een ​​statische analysator aan te schaffen en dan blindelings elke gegeven waarschuwing te volgen, zal dit hoogstwaarschijnlijk resulteren in code van mindere kwaliteit , aangezien je de leesbaarheid mogelijk vermindert en per ongeluk bugs introduceren. Ik heb dit vaak zien gebeuren, het omzetten van code naar MISRA-conformiteit is geen triviale taak.

Er zijn twee versies van het MISRA-C-document die van toepassing kunnen zijn. Ofwel MISRA-C: 2004, dat nog steeds de huidige de facto standaard voor de embedded industrie is. Of de nieuwe MISRA-C: 2012 die de C99-standaard ondersteunt. Als je nog nooit MISRA-C hebt gebruikt, raad ik je aan om het laatste te implementeren.

Houd er echter rekening mee dat leveranciers van tools meestal naar MISRA-C: 2004 verwijzen als ze zeggen dat ze MISRA-controle hebben (soms verwijzen ze zelfs naar de verouderde MISRA-C: 1998-versie). Voor zover ik weet, is de toolondersteuning voor MISRA-C: 2012 nog steeds beperkt. Ik denk dat tot nu toe slechts enkele statische analysers het hebben geïmplementeerd: Klocwork, LDRA, PRQA en Polyspace. Misschien meer, maar u moet zeker controleren welke versie van MISRA het ondersteunt.

Voordat u besluit, kunt u natuurlijk beginnen met het lezen van het MISRA-document en kijken wat het inhoudt. Het kan voor £ 10 worden gekocht bij misra.org, redelijk betaalbaar vergeleken met de prijzen voor ISO-normen.

Mathworks (de MATLAB-mensen) hebben een statische code-analysetool genaamd Polyspace.

Naast statische code-analyse, lint en dergelijke, zou ik een zorgvuldige definitie en ontwerp van interfaces (met een formeel beoordelingsproces) en codedekkinganalyse willen voorstellen.

Misschien wilt u ook kijken naar richtlijnen voor het ontwerpen van veiligheidskritische codes, inclusief MISRA, maar ook de UL1998- en IEC 61508-normen.

Voor een volledig antwoord op deze vraag zou ik de gedachte aan "codebetrouwbaarheid" onderdrukken en in plaats daarvan denken aan "ontwerpbetrouwbaarheid", omdat de code slechts de laatste uitdrukking van het ontwerp is.

Begin dus met de vereisten en schrijf en inspecteer deze. Als je geen requirementsdocument hebt, wijs dan naar een willekeurige regel code en vraag jezelf af "waarom is die regel nodig?" De behoefte aan een regel code moet uiteindelijk herleidbaar zijn tot een vereiste, zelfs als het zo simpel / voor de hand liggend is als "de voeding zal 5 VDC leveren als de invoer tussen 12-36 VDC ligt". Een manier om hierover na te denken is dat als die regel code niet kan worden herleid tot een vereiste, hoe weet u dan dat het de juiste code is of dat deze überhaupt nodig is?

Verifieer vervolgens uw ontwerp. Het is oké als het volledig in de code staat (bijvoorbeeld in opmerkingen), maar dat maakt het moeilijker om te weten of de code doet wat echt bedoeld is. De code kan bijvoorbeeld een regel hebben die luidt: output = 3 * setpoint / (4 - (current * 5)); Is current == 4/5 een geldige invoer die een crash kan veroorzaken? Wat moet er in dit geval worden gedaan om de deling door nul te voorkomen? Vermijdt u de operatie helemaal of vermindert u in plaats daarvan de output? Als u een algemene opmerking in uw ontwerpdocument heeft over hoe u met dergelijke randgevallen moet omgaan, wordt het veel gemakkelijker om het ontwerp op een hoger niveau te verifiëren. Code-inspectie is nu dus gemakkelijker omdat het een kwestie is van controleren of de code dat ontwerp correct implementeert.

Daarnaast moet code-inspectie controleren op veelvoorkomende fouten die uw IDE niet opvangt (u gebruikt een IDE, toch?) zoals '=' toen je '==' bedoelde, ontbrekende accolades die de betekenis van 'als'-uitspraken veranderen, puntkomma's waar ze niet zouden moeten zijn, enz.

Zoals ik Als ik dit schrijf, bedenk ik me dat het erg moeilijk is om jarenlange training / ervaring op het gebied van softwarekwaliteit in één bericht samen te vatten. Ik schrijf code voor medische hulpmiddelen en het bovenstaande is een extreem vereenvoudigde samenvatting van hoe we het benaderen.