Waarom u op standaarden gebaseerde ontwikkelingspraktijken zou moeten gebruiken (zelfs als dat niet nodig is)

Een hele industrie heeft zich ontwikkeld rond verificatie- en validatiepraktijken die worden ondersteund door functionele veiligheid, beveiliging en coderingsnormen zoals IEC 61508, ISO 26262, IEC 62304, MISRA C en CWE. Natuurlijk is niet iedereen verplicht om de formele processen en methodologieën te volgen die deze normen promoten, vooral als hun software niet aan de strengheid van deze normen hoeft te voldoen. Maar de normen zijn voorstander van best practices, omdat de ervaring leert dat ze de meest effectieve manier zijn om hoogwaardige, betrouwbare en robuuste software te realiseren.

Best-practice ontwikkelingstechnieken die deze standaarden volgen, helpen ervoor te zorgen dat fouten niet in de eerste plaats in de code worden geïntroduceerd, waardoor de noodzaak voor uitgebreide debugging-activiteiten wordt verminderd die de time-to-market kunnen vertragen en kosten kunnen verhogen. Natuurlijk hebben niet alle ontwikkelaars de luxe van de tijd en het budget voor de toepassingen in de lucht- en ruimtevaart-, automobiel- of medische apparatuurindustrie. De technieken die ze gebruiken, vertegenwoordigen echter een gereedschapskist met enorme potentiële voordelen voor elk ontwikkelingsteam, of het nu gaat om kritiek op het gebruik ervan of niet.

Soorten fouten en hulpmiddelen om ze aan te pakken

Twee belangrijke soorten fouten kunnen in software worden gevonden en worden verholpen met hulpmiddelen om te voorkomen dat fouten worden geïntroduceerd:

• Codeerfouten. Een voorbeeld is code die probeert toegang te krijgen buiten de grenzen van een array. Dit soort problemen kunnen worden opgespoord door statische analyse uit te voeren.
• Applicatiefouten. Deze kunnen alleen worden gedetecteerd door precies te weten wat de applicatie moet doen, wat inhoudt dat je moet testen aan de hand van de vereisten.

Codeerfouten en codecontrole

Statische analyse is een effectieve techniek voor het detecteren van codeerfouten, vooral wanneer deze vanaf het begin van een project wordt ingezet. Nadat de code is geanalyseerd, zijn er verschillende soorten resultaten die kunnen worden bekeken. Bij codebeoordeling wordt de code getoetst aan een coderingsstandaard zoals MISRA C:2012, waar we ons in dit artikel op zullen concentreren.

Idealiter zou een veilige taal zoals Ada worden gebruikt voor alle embedded projecten. Ada bevat tal van kenmerken om een ​​denkproces af te dwingen dat op natuurlijke wijze fouten vermindert (zoals strikt typen bijvoorbeeld). Helaas is het moeilijk om programmeurs met Ada kennis en ervaring te vinden, dus de meeste bedrijven gebruiken in plaats daarvan C en/of C++. Deze talen bieden echter ook voor ervaren ontwikkelaars valkuilen. Gelukkig kunnen de meeste van deze potentiële valkuilen worden vermeden door code-review uit te voeren.

De beste manier om fouten in de code te voorkomen, is door ze daar niet te plaatsen. Dit klinkt voor de hand liggend, maar dit is precies wat een coderingsstandaard doet. In de C- en C++-wereld wordt ongeveer 80% van de softwarefouten veroorzaakt door het onjuist gebruik van ongeveer 20% van de taal. Als het gebruik van de taal wordt beperkt om de delen van de taal te vermijden waarvan bekend is dat ze problematisch zijn, worden defecten vermeden en neemt de kwaliteit van de software enorm toe.

De fundamentele taalgerelateerde oorzaken van fouten met de C/C++-programmeertalen zijn ongedefinieerd gedrag, door de implementatie gedefinieerd gedrag en niet-gespecificeerd gedrag. Dit gedrag leidt tot softwarefouten en beveiligingsproblemen.

Overweeg als voorbeeld van door de implementatie gedefinieerd gedrag de verspreiding van de bit van hoge orde wanneer een geheel getal met teken naar rechts wordt verschoven. Is het resultaat 0x40000000 of 0xC0000000?

Figuur 1:Het gedrag van sommige C- en C++-constructies hangt af van de gebruikte compiler. (Bron:LDRA)

Het antwoord hangt af van de compiler die u gebruikt (Figuur 1). Het kan beide zijn. De volgorde waarin de argumenten voor een functie worden geëvalueerd, is niet gespecificeerd in de C-taal. In de code die wordt getoond in Afbeelding 2—waar de rollDice() functie leest eenvoudig de volgende waarde uit een circulaire buffer met de waarden "1, 2, 3 en 4" - de verwachte geretourneerde waarde zou 1234 zijn. Er is echter geen garantie daarvoor en ten minste één compiler zal code genereren die terugkeert de waarde 3412.

Figuur 2:Het gedrag van sommige C- en C++-constructies wordt niet gespecificeerd door de talen. (Bron:LDRA)

De C/C++-talen bieden tal van dergelijke valkuilen, maar met het gebruik van een coderingsstandaard kunnen deze ongedefinieerde, niet-gespecificeerde en door de implementatie gedefinieerde gedragingen worden vermeden. Evenzo is het gebruik van constructies zoals goto of malloc kan leiden tot defecten, dus een coderingsstandaard kan worden gebruikt om te voorkomen dat deze constructies worden gebruikt. Er doen zich veel problemen voor bij het mengen van ondertekende en niet-ondertekende waarden, wat meestal geen probleem oplevert, maar er kan soms een hoekgeval zijn waarbij de ondertekende waarde overloopt en negatief wordt.

Codeerstandaarden kunnen ook controleren of code in een bepaalde stijl is geschreven; bijvoorbeeld controleren of het tabteken niet wordt gebruikt, dat de inspringing een bepaalde grootte heeft of dat haakjes op een specifieke positie staan. Dit is belangrijk omdat enige handmatige codecontrole vereist zal zijn en wanneer de code wordt bekeken in een andere editor waar het tabteken een andere grootte heeft, dan leidt de vreemde lay-out de reviewer af van het concentreren op het beoordelen van de code.

Sommige ontwikkelaars maken zich schuldig aan het schrijven van "slimme" code die zeer efficiënt en compact kan zijn, maar ook cryptisch en complex, waardoor het voor anderen moeilijk te begrijpen is. Het is veel beter om het simpel te houden en de compiler te laten zorgen voor het maken van een efficiënt binair bestand. Nogmaals, het gebruik van een coderingsstandaard kan helpen voorkomen dat ontwikkelaars ongedocumenteerde en te complexe code maken.

De bekendste programmeerstandaarden zijn misschien wel de MISRA-standaarden, die in 1998 voor het eerst werden gepubliceerd voor de auto-industrie. De populariteit van deze standaarden wordt weerspiegeld in het aantal embedded compilers die een zekere mate van MISRA-controle bieden. De nieuwste versie van MISRA is MISRA C:2012, dat bijna het dubbele aantal pagina's heeft van zijn voorganger. De meeste van deze aanvullende documentatie bestaat uit nuttige uitleg over waarom elke regel bestaat, samen met details over de verschillende uitzonderingen op die regel. MISRA heeft verschillende richtlijnen en indien van toepassing bevatten ze verwijzingen naar standaarden of naar het ongedefinieerde, niet gespecificeerde en door de implementatie gedefinieerde gedrag. Een voorbeeld hiervan is te zien in figuur 3.

Figuur 3:MISRA C verwijst naar ongedefinieerd, ongespecificeerd en door de implementatie gedefinieerd gedrag. (Bron:LDRA)

Het merendeel van de MISRA-richtlijnen is 'beslisbaar', wat betekent dat een tool moet kunnen vaststellen of er sprake is van een overtreding of niet. Een paar richtlijnen zijn echter "onbeslisbaar", wat betekent dat het niet altijd mogelijk is voor een tool om af te leiden of er een overtreding is of niet. Een voorbeeld hiervan is wanneer een niet-geïnitialiseerde variabele als uitvoerparameter wordt doorgegeven aan een systeemfunctie die deze moet initialiseren. Tenzij de statische analyse echter toegang heeft tot de broncode voor de systeemfunctie, kan deze niet weten of die functie de variabele gebruikt voordat deze wordt geïnitialiseerd. Als een eenvoudige MISRA-checker wordt gebruikt, wordt deze overtreding mogelijk niet gerapporteerd, wat mogelijk kan leiden tot een fout-negatief. Als alternatief, als een MISRA-checker niet zeker is, kan deze de overtreding melden, wat mogelijk kan leiden tot een fout-positief. Wat is het beste? Niet wetende dat er een probleem zou kunnen zijn? Of precies weten waar je tijd moet besteden om ervoor te zorgen dat er absoluut geen probleem is? Het is toch beter om vals-positieven te hebben in plaats van vals-negatieven.

In april 2016 heeft de MISRA-commissie een amendement op MISRA C:2012 uitgebracht, waarin 14 aanvullende richtlijnen zijn toegevoegd om ervoor te zorgen dat MISRA niet alleen van toepassing was op veiligheidskritieke, maar ook op veiligheidskritieke software. Een van deze richtlijnen was richtlijn 4.14, die, zoals te zien is in figuur 4, helpt valkuilen door ongedefinieerd gedrag te voorkomen.

Figuur 4:MISRA en veiligheidsoverwegingen. (Bron:LDRA)

Toepassingsfouten en testen van vereisten

Applicatiebugs kunnen alleen worden gevonden door te testen of het product doet wat het moet doen, en dat betekent dat er eisen worden gesteld. Het vermijden van applicatiefouten vereist zowel het ontwerpen van het juiste product als het juist ontwerpen van het product.

Het juiste product ontwerpen betekent vooraf eisen stellen en zorgen voor bidirectionele traceerbaarheid tussen de eisen en de broncode, zodat elke vereiste is geïmplementeerd en elke softwarefunctie terug te voeren is op een vereiste. Elke ontbrekende of onnodige functionaliteit (die niet aan een vereiste voldoet) is ook een applicatiefout. Het productrecht ontwerpen is het proces van bevestigen dat de ontwikkelde systeemcode voldoet aan de projectvereisten, wat kan worden bereikt door op vereisten gebaseerde tests uit te voeren.

Figuur 5 toont een voorbeeld van bidirectionele traceerbaarheid. In dit eenvoudige voorbeeld is een enkele functie geselecteerd en wordt de upstream-traceerbaarheid gemarkeerd van de functie naar een vereiste op laag niveau, vervolgens naar een vereiste op hoog niveau en ten slotte naar een vereiste op systeemniveau.

Figuur 5:Bidirectionele traceerbaarheid, met geselecteerde functie. (Bron:LDRA)

In Afbeelding 6 is een vereiste op hoog niveau geselecteerd, en de markering toont zowel de upstream-traceerbaarheid naar een vereiste op systeemniveau als de downstream-traceerbaarheid naar de low-level-vereisten en naar broncodefuncties.

klik voor grotere afbeelding

Figuur 6:Bidirectionele traceerbaarheid, met geselecteerde vereiste. (Bron:LDRA)

Deze mogelijkheid om traceerbaarheid te visualiseren kan leiden tot de detectie van traceerbaarheidsproblemen (toepassingsbugs) vroeg in de levenscyclus.

Het testen van codefunctionaliteit vereist een bewustzijn van wat het zou moeten doen, en dat betekent dat er lage vereisten zijn om aan te geven wat elke functie doet. Afbeelding 7 toont een voorbeeld van een vereiste op laag niveau, die in dit geval een enkele functie volledig beschrijft.

Figuur 7:Voorbeeld lage eis. (Bron:LDRA)

Testgevallen zijn afgeleid van vereisten op een laag niveau, zoals geïllustreerd in tabel 1.

Tabel 1:Testgevallen afgeleid van vereisten op laag niveau. (Bron:LDRA)

Met behulp van een unit-testtool kunnen deze testgevallen vervolgens worden uitgevoerd op de host of het doel om ervoor te zorgen dat de code zich in overeenstemming met de vereisten gedraagt. Afbeelding 8 laat zien dat alle testgevallen zijn teruggelopen en zijn geslaagd.

Figuur 8:Uitvoeren van unit tests. (Bron:LDRA)

Wanneer de testgevallen zijn uitgevoerd, moet de structurele dekking worden gemeten om ervoor te zorgen dat alle code is toegepast. Als de dekking niet 100 procent is, is het mogelijk dat er meer testgevallen nodig zijn of dat er overbodige code is die moet worden verwijderd.

Conclusie

Met toenemende softwarecomplexiteit nemen ook potentiële softwarefouten toe. Best-practice ontwikkelingstechnieken helpen voorkomen dat deze fouten optreden. Best-practice-ontwikkeling bestaat uit het gebruik van een ultramoderne coderingsstandaard zoals MISRA C:2012, het meten van metrieken op de code, het traceren van vereisten en het implementeren van op vereisten gebaseerde tests. De mate waarin deze technieken worden toegepast waar er geen verplichtingen zijn om aan de normen te voldoen, is duidelijk ter beoordeling van het ontwikkelteam. De normen zijn echter voorstander van deze praktijken omdat de ervaring leert dat ze de meest effectieve manier zijn om kwaliteitsvolle, betrouwbare en robuuste software te bereiken. En of een product nu van cruciaal belang is voor de veiligheid of niet, dat is zeker een uitkomst die alleen maar gunstig kan zijn voor het ontwikkelingsteam.