MISRA krav

Der stilles allerede krav, et antal steder er fuld compliance med MISRA's krav betingelse for godkendelse.

Jeg er ikke klar over de nærmere omstændigheder eller procedurer, men her er henvisninger til de grundlæggende dokumenter:

Guidelines for the Use of the C Language in Vehicle Based Software (MISRA)
The Motor Industry Research Association, April 1998
Warwickshire, UK, //www.misra.org.uk

The Motor Industry Software Reliability Association
MISRA-C:2004 Guidelines for the use of the C Language in critical systems,
The Motor Industry Research Association,
Warwickshire, UK 2004, ISBN 0952415690

The Motor Industry Software Reliability Association
MISRA-C++: 2008 Guidelines for the use of the C++ Language in critical systems,
The Motor Industry Research Association,
Warwickshire, UK 2008.

Via: FlexeLint/gimpel.com som varmt kan anbefales til alle udviklere hvad enten der er biler involveret eller ej.

Poul-Henning

Re: MISRA krav

Der stilles allerede krav, et antal steder er fuld compliance med MISRA's krav betingelse for godkendelse.

Så vidt jeg er orienteret, definerer MISRA kravene kun hvilket subset af programmeringssproget C, der udgør MISRA-C. Det er muligt jeg ikke er opdateret omkring emnet, men sidst jeg kiggede på MISRA-C var det blot en kodestandard.

Der stilles ikke krav om f.eks. kvalitetsniveau, brugen af statiske analyseværktøjer, bevisførelse eller formelle specifikationer.

Til kritisk software vil jeg anbefale at man kigger på DO-178B eller UK MOD Def Stan 00-55.

Re: Re: MISRA krav

MISRA-C er en god begyndelse til at undgå en del af de "fælder" der ellers tillades i C.

Men MISRA jo hverken en japansk eller en amerikansk opfindelse...
Dog er den oversat til japansk ;-)

Re: MISRA krav

Der stilles allerede krav, et antal steder er fuld compliance med MISRA's krav betingelse for godkendelse.

Jeg kendte ikke MISRA. Tak for henvisningen. Hjemmesiden virker noget uopdateret. Er de gået døde?

Ved genlæsning af mit indlæg har jeg delvist fortrudt formuleringen ...

Lad os få jeres bud på, hvor problemer med pålidelighed af software i biler burde landes.

... for det handler jo ikke kun om software/kodekvalitet, men om softwarens samspil med den fysiske virkelighed i bilen - sensorer osv.

Eller et forsøg på at udtrykke en af vinklerne mere konkret: Hvordan softwaren opdager, at en speeder har sat sig fast i et gulvtæppe og hvilke handlinger den foretager i den forbindelse:

"Du kører i øjeblikket 100 mph på en vej med en hastighedsgrænse på 70 mph. Det kunne være tegn på at din speeder er fastklemt i gulvtæppet. Hvad vil du? (abort, retry, ignore)"

Pudsigt

Jeg er meget enig i, at der burde være et sådant krav, idet flere biler har udviklet sig elektriske på mange traditionelle direkte mekaniske installationer.

Men vedrørende Toyota undrer det med den meget store opmærksom. Det må da primært skyldes de normalt meget høje kvalitetsnormer på dette mærke.

Jeg har haft en del biler også lige nu via konens firma. Når jeg her tænker på antallet af fejl særlig elektroniske på vores Peugeoter virker Toyotas som bagateller.

Men ved en fransk bil er det jo bare acceptabelt med en del fejl.

Definition af en bil

Begrebet "en bil" er gået i opløsning. Man køber reelt ikke længere en årgangsmodel, men en samling af hardware og software med vidt forskellige modenhedsgrader. Historien om lygteproblemer, at kunderne kan udtænke at problemerne skyldes bilens operativsystem, er et godt eksempel. Når en bilproducent dernæst retter på en sådan fejl, kan der tænkes at opstå komplet uventede bivirkninger, fx (et tænkt eksempel) at nedrulning af ruder begynder at svigte hvis lygterne samtidig er tændt.

Alle sådanne sammenhænge i en bils virkemåder, kan ikke reddes med kvalitetskodning af software, fordi sammenhængene er komplekse. Hvis lygterne svigter, skyldes det da lygternes hardware, eller deres software, eller deres dataforbindelse til bilens operativsystem, ellers deres strømforsyning, eller skyldes det en fejl i operativsystemet, eller skyldes det digital støj (eller fx hede) fra en helt anden komponent i bilen, eller skyldes det digital støj (eller fx hede) fra omverdenen? Og, optræder en fejl kun når luften fx har en vis fugtighed eller urenhed, eller når bilen udsættes for en vis grad af rystelser? - Og så videre, som betyder at der er i tusindevis af mulige sammenhænge imellem årsager og virkninger, som betyder at fejlretninger forudsætter en altomfattende analyse, en mængde af viden som intet enkelt menneske i verden kan have. Ganske vist, kan en fabrik udstede en ordre til samtlige underleverandører om at lede efter en fejl, men sådanne ordrer bliver ofte ignoreret eller nedprioriteret på ubestemt tid, fordi alle har travlt. Man kan kun bringe mennesker til at lede efter fejl, hvis de på forhånd får temmelig præcist at vide om hvor fejlen sandsynligvis er.

Virkemidler imod fejl er for det første at undlade at producere for mange varianter af konfigurationer, jo færre, jo mindre kaos at analysere i, når kunder beretter om fejl. For det andet behøver man at udtænke en robust arkitektur som kan indkapsle fejl til specifikke områder, og hvis overhovedet muligt bør en sådan arkitektur være baseret på en fælles standard for alle biler, fordi sådant vil forøge kunders chancer for at kunne forstå hvad der foregår, når en fejl optræder, og dermed vil det forøge chancerne for at kunderne kan give en relevant feedback til et værksted, som vil fokusere mekanikerne bedre, og dermed kan de også mere præcist melde tilbage til en fabrik.

Desuden bør alle biler indeholde en database med historik om bilens adfærd og miljø (en sort boks), fordi værksteders analysesoftware kan anvende sådanne data til at udpege de clustre af situationer der især fremprovokerer fejl, vigtige oplysninger når en fabrik skal forsøge at udregne årsagen bag en fejl, hvis mekanikere ikke evner at finde dem.

Dertil har man behov for at kunne nulstille en bils hardware og software, dvs. have sikkerhed for at man ved at en bil er "uforurenet". For cirka 25 år siden havde jeg en Corolla, der pludselig begyndte at svigte tilfældigt nu og da. Værkstedschefen nægtede at der var et problem, indtil han personligt prøvekørte min bil. Da indså han, på grund af sin erfaring, hvad fejlårsagen var: At en mekaniker havde glemt at fjerne en lille forlængerledning, en ledning som daskede tilfældigt omkring på motoren, en ledning som mekanikeren havde anvendt til at tilkoble bilens elektronik til værkstedets analysesoftware i forbindelse med et almindelige servicebesøg. Sådanne arter af fejl kan gøre det helt umuligt for en fabrik at indse hvor en fejl er, medmindre at bilerne bliver bragt tilbage til fabrikken til en totalanalyse, eller medmindre at biler udstyres med en selvanalyse.

Re: Re: MISRA krav

I mellemtiden stemmer jeg stadig for den røde knap - nu med den tilføjelse, at den skal være uafhængig af resten af bilens elektroniske juletræ.

Hvis din "panik-knap" skal virke som en hovedafbryder (uafhængig af resten af bilens elektroniske juletræ), der svarer til at klippe ledningen til batteri og generator, så vil den jo ikke bare afbryde motoren.

Den vil også afbryde lygterne, inklusive bremselygterne.

Den vil afbryden styringen til ABS-systemet.

Hvis du har en drive-by-wire gaspedal, så har du vel en servomotor i den anden ende af "wiren", til at åbne og lukke gasspjældet. Gasspjældet vil således efterlades åbent, så der ikke er vacuum til bremseservoen.

Med andre ord, du sætter ikke blot drivkraften, men også mange af bilens basale sikkerhedssystemer ud af drift, med den hastighed du nu engang kører med, evt i nattens mulm og mørke.

Det vil jeg ikke anbefale!

Sikkerhedssystemerne skal selvfølgelig virke og være adundante og uafhængige. I det tilfælde at føreren finder bilen ude af kontrol, er det vigtigt at "panik-knappen" har til formål at bringe bilen sikkert til standsning, fremfor at sætte det hele ud af drift.

Den mest naturlige panik-knap er i derfor bremsepedalen, og jeg er 100% sikker på at det første sheriffen i Lexus'en gjorde, da han konstaterede at bilen ikke reagerede som den skulle, da han slap gassen, var at træde på bremsepedalen pr refleks.

Det eneste der skal sættes ud af drift, i den situation, er drivkraften, og den forsvinder omgående når brændstoffet fjernes. Alle andre funktioner skal virke, især i denne situation.

Jeg finder det derfor helt indlysende, at brændstofindsprøjtningen bør afbrydes når bremsepedalen trædes, indtil motoren går under 1.000 rpm, hvilket kan gøres uhyre simpelt og helt uafhængigt.

Jeg er endnu ikke kommet i tanker om en fornuftig grund til, at man i en almindelig bil skal kunne bremse og give gas samtidigt.

Re: Definition af en bil

Morsomt. Den fejl fik mig til at tænke på en lille båndrobot (10-stacker), vi havde på et tidspunkt. Et af drevene fejlede periodisk og selvfølgelig kun, når man ikke målte på det.
For at gøre en lang historie kort, så skyldtes det et problem med elektrisk støj, som kun var der, når frontlågen var lukket.

Re: Re: Re: MISRA krav

Hvis du har en drive-by-wire gaspedal, så har du vel en servomotor i den anden ende af "wiren", til at åbne og lukke gasspjældet. Gasspjældet vil således efterlades åbent, så der ikke er vacuum til bremseservoen.

Elektriske gasspjæld plejer at være fjederbelastede, således at de lukker hvis strømmen går.

Re: Re: MISRA krav

"Du kører i øjeblikket 100 mph på en vej med en hastighedsgrænse på 70 mph. Det kunne være tegn på at din speeder er fastklemt i gulvtæppet. Hvad vil du? (abort, retry, ignore)"

Det er selvfølgelig helt forfejlet!

En advarsel om at chaufføren overtræder loven må da aldrig blandes sammen med en farlig defekt.

Har gasspjældet sat sig fast, så ved chaufføren omgående, når han slipper gaspedalen, at bilen ikke lystrer hans kommando. Ikke først når han kører 30 mph for stærkt.

Så behøver han heller ikke tre valgmuligheder, - han skal bare kunne bremse!

Hvis chaufføren kører for stærkt, skal han kun have en høflig påmindelse, fx som det signal man får, når sikkerhedsselen ikke er spændt, og som ikke forstyrrer ham unødigt, hvis han vælger at ignorere det. Så distraherer det ham heller ikke unødigt, hvis det er gasspjældet der sidder fast.

Det er nemlig chaufførens ansvar, og ikke bilens, og en forstyrrende meddelelse vil kun øge risikoen. Signalet skal højest være en påmindelse, så han sparer bøden.

SW/HW til sikkerhedskritiske funktioner

Der findes en udmærket standard der kan anvendes til at sikre at sikkerhedsfunktioner ikke fejler når der er brug for dem.
Så skal man blot via en risiko analyse fastslå de farer der kan opstå og hvorledes man vil imødegå dem således at restrisikoen kommer under den acceptable risiko. Enkelt, men dog noget mere indviklet i praksis.

Standarden hedder IEC 61508 og omhandler elektiske/elektroniske/programerbare systemer der anvendes til sikkerhedsfunktioner. Slev om mekanikken i princippet ikke er med i scopet så kan den dog behandles på helt ækvivalent måde. Standarden findes bla. i branchespecifikke implementationer til A-kraft, jernbane og procesindustrien.
Standarden er bestemt ikke ukendt stof i Tyskland men jeg ved dog ikke om bilindustrien har set lyset endnu.
Se fx. exida.com

Re: SW/HW til sikkerhedskritiske funktioner

Standarden hedder IEC 61508

...

bestemt ikke ukendt stof i Tyskland men jeg ved dog ikke om bilindustrien har set lyset endnu.
Se fx. exida.com

Tak for et spændende tip. Jeg har googlet lidt og fundet forskellige referencer.

Dette 2005-paper af Ekkehard Pofahl, Ford Research & Advanced Engineering i Tyskland, giver et overblik over implementeringen af IEC 61508 i biler (Bemærk: Henviser til Misra!):

http://www.sipi61508.com/ciks/....pdf

TI har en controller til bilbrug, der er certificeret efter denne standard:

http://www.ti.com/corp/docs/la....htm

Så hvordan skal situationen tolkes?

Noget i retning af: "Nogle i bilindustrien er i gang med at implementere efter 61508, men processen er kun få år gammel og der foreligger ikke en branche-bred implementering?"

Re: Re: SW/HW til sikkerhedskritiske funktioner

Noget i retning af: "Nogle i bilindustrien er i gang med at implementere efter 61508, men processen er kun få år gammel og der foreligger ikke en branche-bred implementering?"

Ja det ser ud som om det er ca. sådan det hænger sammen. Jeg har dog en fornemmelse at lige netop bilbranchen ikke så nemt lader sig inspirere af andre brancher. Det skinner også en smule igennem i Pofahls paper, der jo dog er nogle år gammelt.

IEC 61508 er lidt som ISO 9001, den siger ikke hvilket niveau man skal nå, blot hvorledes et bestemt niveau kan nåes.
Pofahl efterlyser en guide i hvilket sikkerhedsniveau (Safety integrety level, SIL) de enkelte sikkerheds funktioner skal have. Det vil naturligvis være en fordel med sådan en guide som f.eks. kunne være en branche specifik implementering af 61508. Generelt kan man dog sige at intet forhindrer den sikkerheds bevidste bilproducent at lave en risiko analyse og herudfra finde frem til det nødvendige/ønskede SIL niveau for f.eks ABS systemet. Så er der blot risiko for at der bliver forskelle producenterne i mellem.

Pofahl nævner nogle forbehold bilindustrien har i forhold til 61508 og det kan da også være en anden god grund til at lave et afledet standard til bilerne, men igen her vil man åbenbart helst være lidt anderledes og kalde det for ASIL og have andre kriterier for at opnå disse.

Man kan også tage et kig på: http://www.iec.ch/zone/fsafety....htm hvis man vil vide mere om IEC 61508.
p.s. Den findes også som EN standard, dvs. relevant i Europa.

Re: Re: Re: SW/HW til sikkerhedskritiske funktioner

Noget i retning af: "Nogle i bilindustrien er i gang med at implementere efter 61508, men processen er kun få år gammel og der foreligger ikke en branche-bred implementering?"

Ja det ser ud som om det er ca. sådan det hænger sammen. Jeg har dog en fornemmelse at lige netop bilbranchen ikke så nemt lader sig inspirere af andre brancher. Det skinner også en smule igennem i Pofahls paper, der jo dog er nogle år gammelt.

Situationen undrer mig, jeg graver lidt videre og vender tilbage.

Apropos Post-Toyota

Har jeg den sidste tid spekuleret på hvad industrien nu vil gøre med alle de flotte Toyota-inspirerede systemer og arbejdsmetoder, f.eks. LEAN, Kaizen og 5S - det er jo ifølge medierne nu endegyldigt bevist at de fejler stort - kan man tillade sig at producere noget som helst efter et princip som ikke kan lave fejlfri biler alligevel? - det var jo hele grunden til at man overtog ideerne...

Nancy Levenson

arbejder med den slags, link til hendes website (Therac-4 rapporten er en (nu gammel) klassiker).

http://sunnyday.mit.edu/

Som hun påpeger sker uheld (SW/HW/Menneskelige) typisk ved en serie af hver især ukritiske/ufarlige afvigelser fra normen, hvor det så til sidste er en ubetydelighed, der får skidtet til at ramle (Bhopal analysen er værd at læse også). En organisation skal bygges til at lave sikre systemer.

( Problemstillingen er vel iøvrigt den samme, som for fly, medico, våben og atomkraftværker - og meget store volumener af konsumprodukter)

Det er da fint at man kan definere et C++ subset, men oven i det kommer, at de værktøjer (compilere, linkere, biblioteker) man bruger også skal være korrekte. Det er ikke altid tilfældet. ADA var et forsøg på at lave et veldefineret sprog og en valideret værktøjskasse.

Det er ikke så længe siden, at SW i et af Drägers alkometre blev analyseret og det var ikke kønt ( I USA kan man i nogen stater komme i fængsel bare baseret på et pust, uden blodprøve).

Boing 777 f.eks., har den røde knap, som slår al softwaren fra og reducerer styringen til ren elektronisk fly-by-wire.

Venlig hilsen

Claus

Re: Re: Re: Re: SW/HW til sikkerhedskritiske funktioner

Jeg har kigget lidt rundt på nettet og fundet følgende links omkring IEC 61508 og bilbranchen:

http://www.vda-wintermeeting.d....pdf

http://ec.europa.eu/informatio...8406

http://www.iso.org/iso/search....d=on

http://www.linkedin.com/groups...8567

Der er altså faktisk en branche specifik implementering af 61508 på vej til bilbranchen. Den hedder iso 26262 og skulle efter planen blive udgivet sommer 2011. Allerede i dag findes den dog som draft (DIS). Hvorvidt den bliver brugt ved jeg ikke.
mvh. Jørn Tychsen

Alting bliver software

Meget interessant læsning (artiklen og især tråden). Tak for dét.

For nogle år siden fik min nabo en ny bil, som havde den fede feature, at når man hev i dørhåndtaget i passagersiden, så åbnede centrallåsen hele bilen. Han måtte lige indenom værkstedet og blive patchet op :-).

Samme bil købte en af mine medarbejderes kone, og en dag besluttede den sig for at blinke til højre. Hele tiden. Det nyttede ikke engang at slukke og tænke bilen.

Efter lidt kørselsplanlægning (dvs. en serie højresving) fik min medarbejder kørt bilen på værksted. Da han hentede den om aftenen blinkede den ikke mere, men værkstedet måtte indrømme, at de ikke havde kunnet finde fejlen, så de havde bootet den, dvs. frakoblet og tilkoblet batteriet.

Det bekræfter mig i min gamle tese om, at alt konvergerer mod software, og dermod mod fejl. Elevatorer, kaffemaskiner, biler... og såvidt jeg ved findes der faktisk nogle interfaces (måske endda noget open source-halløj ifølge et rygte jeg hørte for et par år siden) så man kan komme ind på egen hånd. Måske nogen kan bekræfte eller afkræfte dette?

Det er da oplagt at man i fremtiden selv kan ændre på blinker-lyden i sin bil. Eller kombinere basale funktioner som at starte bagrudeviskeren når man sætter bilen i bakgear (hvis det ikke allerede er indkodet).

Det bedste bliver jo drive-by-hacking... hvilke muligheder!

Iøvrigt var jeg på et VIP-kørekursus afholdt af Det Nationale Færdselscenter forud for klimatopmødet. Vi kørte i såkaldte limousiner, dvs. Volvo S80, BMW 5 og 7, diverse Mercedeser (inkl. den beslaglagte Stein Bagger-model til 2.8 millioner) og nogle minibus-simulerende vans fra Mercedes.

Én af Mercedeserne havde store problemer med ABS i glat føre, og ifølge instruktørerne havde de over en længere periode været i kontakt med Mercedes' hovedkvarter om problemet, som skyldtes samspillet mellem sensorerne og softwaren.

Vejen frem må være open source, så alle kan kigge med :-).

mvh.

Mogens

Re: Alting bliver software

Begrædeligt at vi er nået et (lav)punkt hvor man kan designe en bil med (bl.a) fundamentalt dårlige køreegenskaber, der så "patches" med husmandsautomatik, udført som en kombination af sensorer og softwarestyret hardware override af (næsten) samtlige førerinput, for at kunne klare en dobbelt undvigemanøvre.

Gad vide om en bil af ældre dato giver en bedre mavefornemmelse.

K

Software i en bil

Faldt lige over dette link:
Skræmmende læsning.

http://spectrum.ieee.org/green...code

Op til 100.000.000 linier kode til at drive en bil. Det er godt nok en hel del.
Så er der ikke noget at sige til at der er noget der fejler.
I en anden tråd (http://ing.dk/artikel/106883-s...vist) nævner PHK lettere ironisk en "acceptabel" fejlrate på 1 fejl per 1000 linier kode. Dette giver jo så ca 100.000 fejl i den dyt!

Måske man skulle overveje en ny cykel?


En enkel metode til at minimere fejlene kunne jo være at udgive koden som open source. Så er jeg sikker på at der i løbet af meget kort tid ville blive fundet mange fejl.

Re: Software i en bil

En endnu enklere måde vil nok være at begrænse elektronikken og vende tilbage til den mekanik som fungerede så udmærket tidligere. :o)

Re: Software i en bil

En enkel metode til at minimere fejlene kunne jo være at udgive koden som open source. Så er jeg sikker på at der i løbet af meget kort tid ville blive fundet mange fejl.

Utvivlsomt, men det er næppe de _rigtige_ fejl der bliver fundet på den måde.

Mantraet om at bare det er open source bliver alle fejl fundet.

Open source er en nødvending betingelse, men ikke en tilstrækkelig betingelse for lav fejl rate i software.

Poul-Henning