Konkurs: Færgebrand kostede elbilfirma forretningen

Fra et lille Dansk niche firma til verdensfirma, og så annonceret sammen med meddelelsen om konkurs, kan man det?

Produktet ville under alle omstændigheder være dødt, når vi i løbet af i år kan få serieproducerede biler til væsentlig lavere pris, så mon ikke det er den egentlige årsag til de lidt tilbageholdende investorer?

Hvem overtager service forpligtelserne på de biler A future trods alt nåede at bygge?

Bliver der etableret et nyt selskab med den eksisterende know how, en Better Place samarbejdspartner eller lignende?

Hvem har lyst til at købe en elektrisk bil, designet af en mand, som ikke evner at administrere en forlængerledning?

Med venlig hilsen

Ole Jensen

Det kan jo være, at man har stået ombord og ikke haft en forlængerledning med den rigtige kapslingsklasse, men det er altså en ufattelig dårlig idé at tage den chance. Nu vides det jo så ikke, om det var sådan det gik til, men hvis det var, så er det vel egentlig fair nok at hans firma går konkurs på det.

Er der udarbejdet nogen rapport om årsagen? Det undre mig at det er fugt på en forlængerledning der får skylden, er det isoleret net på færgen?

jeg synes det er ærgerligt at en af personerne i Danmark, som har gjort meget for at skabe klare og tydelige regler for godkendelse af elbiler får en mavepuster af denne slags.

Jeg takker for såvel støtte som kritik; er det konstruktivt er begge dele altid velkommen.

Som der skrives i artiklen har bestyrelsen måtte erklære A FUTURE EV konkurs; der ses ikke længere muligheder for at fortsætte driften, da investorerne til testproduktionen trak sig grundet risikoen for sagsanlæg og lign. på baggrund af færgebranden. De statslige støttemidler til firmaet beløb sig til trods for 2 års søgen og samarbejde til blot 300.000 kr. i lån, der for størstedelen allerede var afviklet, hvorfor der heller ikke her sås mulighed for en redning.

Selskabet søges lukket pænest muligt for alle parter og de eksisterende elbiler, derunder Moto Mundo Electric World Tour ekspeditionen, støtter vi op om via serviceordninger og en fortsat privat indsats. Medarbejderne finder arbejde andetsteds, muligvis også på baggrund af nationale og internationale muligheder der er opstået i kølvandet på projektet og ekspeditionen. En rekonstruktion forventes ikke da dette netop faldt med manglen på investorer. Det er i øvrigt en udbredt misforståelse at A FUTURE EV var eller skulle være et produktionsselskab; fokus har været på konsulentstøtte til OEMer, med produktionen af Qashqai Electric som demonstrator og udviklingsfinansiering.

Mht. færgebranden var stikket den første konklusion der opstod på åstedet i selskab med de brandtekniske eksperter; efterfølgende konklusioner ved yderligere undersøgelser formoder at stikket blev beskadiget af branden i bilen. Branden er muligvis opstået i en fejlproduceret komponent fra en underleverandør, men det kan være umuligt at afgøre pga. skaderne fra branden – underleverandøren er dog gjort opmærksom på risikoen der derved gerne skulle være elimineret for fremtiden.

Den brandtekniske rapport er endnu ikke færdig, men vi støtter op om arbejdet med den og håber den i det mindste kan være til gavn for branchen efterfølgende. Vi havde ikke umiddelbart kunne forudse eller teste os til fejlen hvis de nuværende konklusioner er korrekte, men derfor så vi naturligvis under alle omstændigheder helst at uheldet ikke var sket og glæder os over at der trods alt ikke skete legemlig skade, ligesom vi håber erfaringerne kan være til gavn for eftertiden.

Jeg skal bemærke at ovenstående er min personlige kommentar, og ikke nødvendigvis repræsenterer hverken A FUTURE EVs eller bestyrelsens holdning. Jeg beklager i øvrigt min begrænsede tilstedeværelse på debatten her, men jeg har meget at se til og kan derfor ikke prioriterer dette medie særlig højt for tiden.

Mvh Søren O. Ekelund, Grundlægger af A FUTURE EV Kontakt: soe@afuture.dk

Jeg kan kun tilslutte mig gruppen der synes det er ærgeligt at der i dag er så lidt plads til "human error" ( hvis der da viser sig at være en menneskelig fejl til branden ). Det er i forvejen ikke let at være iværksætter, med alle de regler om miljø, afgifter, overenskomster o.s.v. -synd for et firma med nogle folk der har drevet det så langt, og ofret så meget for at putte Danmark på verdenskortet for fremtidens transport.

Mange store bilfabrikanter blev spurgt, men kun AFutureEV turde stille op til Hjalte & Nina´s world tour i el-bil ( http://moto-mundo.com/da ). Bilen ( og dermed Danmark ) er blevet vist på flere store "motorshows", og har skabt en del interesse rundt omkring. Nu ved flere at Danmark gerne vil, og godt kan lege med på den front.

Jeg håber, at de der siger "selv-mål" rundt omkring kender følgende ; "Hvor der arbejdes meget laves også mange fejl. De der ikke laver fejl, laver ikke noget." Det gør sig især gældende når der er tale om nytænkning og demo af prototype-grej.

Held og lykke fremover herfra til Søren og I andre elbil-folk. Bare klø på ! -det er vigtigt arbejde det I laver.

/Allan Korup allankorup@gmail.com

Sådan en dum hændelse giver skrammer på hele branchen, når det ikke kan bevises at det var en enkeltstående hændelse, hvilket færgeselskab tør så genindføre opladning under overfarten?

Det vil nok også lægge en dæmper på viljen til kræse for el-bil ejeren ved butik centre og hoteller, men måske der stadig er point at hente på reklameværdi/imagepleje.

Det bliver sikkert også sværere at få tilladelse til at få en lader op i boligforeningen, dvs det bliver en langsom start, først når der uden fejl lades hundredvis af biler dagligt og uden fejl, vil tilliden komme tilbage.

Dette ikke for at negligere færgebrandens betydning, men for at sætte perspektiv på:

Der selvantænder hundredvis af biler hvert år, både under kørsel og ved stilstand, og at det her sker på en færge er absolut uheldigt, men det har ikke noget specielt at gøre med at det er en elbil – men det øger desværre ’katastrofe-stemningen’ i medierne, da en elbil-brand er en mere interessant historie end ’endnu en normal bil har brændt endnu en færge…’.

Så vidt det er mig bekendt er dette den eneste færgebrand startet af en elbil, mens mange færgebrande tidligere er startet af almindelige biler og lastvogne – givet; der er også væsentlig flere ikke-elbiler endnu, men derfra og til at konkludere at elbiler er farlige pga. én færgebrand bør der være ret langt. Potentielt er det faktisk nemmere at brandsikre elbiler, da de generelt indeholder færre bevægelige dele, har lavere arbejdstemperatur og færre brandbare væsker end biler med forbrændingsmotor – men som altid er risikoen naturligvis størst ved modeller med få år i test.

At biler lader op på færger med relativ høj effekt er i øvrigt ikke nyt, idet køle/fryse trailere kobles til under længere overfarter. At det kan være svært at slukke en elbilbrand pga. batteriets kemiske energi der ikke behøver ilt er et problem, men til gengæld eksploderer de nye sikkerhedsbatterier ikke, hvilket brændstof derimod kan gøre, og risikoen for brænd under kørsel bør pga. opbygningen af en elbil uden flydende brændstof, varme og sod være mindre end for en bil med forbrændingsmotor. Alligevel er almindelige biler og lastbiler dog ganske velkomne på færger, på trods af de brande der opstår hvert år – så lad os få lidt perspektiv på:

Selvantænding under kørsel: http://www.112alarm.dk/2008/ribelandevej36... Selvantænding under stilstand: http://www.citronik.dk/jforum/posts/list/2... Selvantænding EFTER kontrol: http://politiken.dk/tjek/bilerogmc/ECE1281... Selvantænding for modelserie: http://www.fri.dk/bil/c3-til-service-mod-b...

Og lad os så undgå at afspore debatten her mere end højst nødvendigt med brandteknik; det hører vist til i anden debat.

Hvad jeg finder mere interessant er den måde mediernes dækning og perspektiv kan have indflydelse på virksomheder, brancher og ikke mindst ny teknologi. Den stemning medierne skaber, og ikke den konkrete sag, kan være skillelinjen mellem succes og konkurs, som i ovenstående tilfælde.

Mvh Søren O. Ekelund, Grundlægger af A FUTURE EV Kontakt: soe@afuture.dk

Der selvantænder hundredvis af biler hvert år, både under kørsel og ved stilstand, og at det her sker på en færge er absolut uheldigt, men det har ikke noget specielt at gøre med at det er en elbil – men det øger desværre ’katastrofe-stemningen’ i medierne, da en elbil-brand er en mere interessant historie end ’endnu en normal bil har brændt endnu en færge…’.

Nu kører der jo langt flere benzinbiler end elbiler rundt, så det er vel ikke overraskende at der er flere benzinbiler, der selvantænder.

Har du nogen statistik over selvantændelser per benzinbil vs. per elbil?

Jeg har en kollega hvis elbil antændte en garage og han er den eneste jeg kender, der har en elbil!

Måske det var en opgave for redaktionen at ringe rundt og høre rederiernes nuværende indstilling til fragt og opladning af el-biler på deres færger og opmarchbåse på land.

Jeg har en kollega hvis elbil antændte en garage og han er den eneste jeg kender, der har en elbil!

Måske skyldes det samme OEM komponent, som den der antændte omtalte elbil. Her har brænden fået konsekvensen, at producenten er blevet gjort opmærksom på problemet, og fejlen derfor er rettet. El-biler, skulle derfor være sikre i fremtiden.

Det er trist, når at en fejl får så fatale konsekvenser, som en brænd på en færge, og at en uskyldig virksomhed går konkurs. Men nogle gange, er det jo det som skal til, for at sikre at denne type fejl ikke sker igen, og at fejlen opdages.

Jeg tror også, at der mangler noget lovgivning på området, der skal sikre at el-bilerne kan synes, og er el-sikkerhedsmæssigt forsvarligt bygget.

Vi kan forestille os mange krav, man kan sætte til el-bilens elektronik og overvågningssytem, der kan være med til at dels undgå el-uheld, og slå strømmen fra i tide, samt systemer der kan overvåge, og sikre at man kan undersøge enhver fejl, og hvor den er opstået, i forbindelse med brænd, eller andre uheld.

Som eksempel, kan man måske sætte krav til en overvågning, af el-bilens elektriske system, der sikrer at der ikke kan opstå brænd ved nogen fejl på kabelnet, og elektronikstyring. Der kan sættes krav, til en brændsikret "sort boks", der som eksempel kan vise, hvor fejlen er opstået i systemet, så man ved om det er ved/i batteriet, og om strømmene til batteriet har været korrekte mv. De pågældende strømme, kan måles ved, eller i batteriet, og afbryder til strøm, kan også placeres ved/i batteriet, således at bilen er uden højspænding, når den er slukket, og står stille. Det vil være muligt, at overvåge ethvert spændingsfald over ledningerne, og dermed undersøge, hvor fejl opstår. Der kan opskrives metoder, således man er i stand til at undersøge om sikkerheden er i orden ved godkendelsen og syn, herunder om overvågningssystemet logger data korrekt ved batteri, motorstyring osv. Der kan sættes krav til, at systemet automatisk kobler ud, hvis det målte er forkert, og det kan også testes ved godkendelse.

Min erfaring er, at erhvervslivet skal holdes i ganske kort snor, når det drejer sig om sikkerhed. For ellers, vil de gøre alt, for at spare den bort. Hvis der ikke er love, så vil alt for mange virksomheder, ikke leve op til ganske elementære krav for sikkerhed. Det er uanset, om det er mad-branchen, eller om det er el-branchen. Det er nødvendigt med love, og der kræves en stor ekspertise, for at kunne lave lovene. Vi mangler også love, indenfor områder som datalogi, og specielt operativsystemer. Her, har man spurgt erhvervslivet, hvad deres holdning er, fordi man har ment de har ekspertisen, og lovene på området er begrænset til, at "kunden må ikke kopiere", og "kunden skal betale". Intet, der sikrer kunden, og sikrer at produkterne fungerer. Så det dur hellerikke, at lade virksomhederne styre. Det bliver der ikke nogen god lovgivning ud af.

Selvfølgeligt, er det forkert at sige at alle virksomheder er ligeglade med sikkerheden - mange er naturligvis ikke, og for nogle er det en levevej. Men, hvis der ikke er love, og krav, så vil det som regel gå sådan, at det er dem der har dårligst sikkerhed, dårligst tager vare på miljøet, og på alle måder er mest ligeglade der overlever. Mens de gode går konkurs...!

I moderne biler er der efterhånden så mange variabler at det er umuligt at teste dem alle til bunds, hvis en bil skal på markedet indenfor et par år.

Et nyligt eksempel på at det går galt, selv hos store OEMer der tester deres biler millioner af kilometer, er Peugeot 206s nøgleproblem: http://www.dr.dk/Nyheder/Indland/2011/02/0... Dette skal absolut ikke være en undskyldning for ikke at sikre og teste designs ordentligt, men det viser hvor ufatteligt svært, for ikke at sige praktisk umuligt, det kan være at få det hele med.

Vedr. færgebranden var den komponent der muligvis har været årsag til branden systematisk testet og kørte i 6 måneder i forskellige versioner i flere køretøjer, men da der er tale om en avanceret chip med tusindvis af komponenter og funktioner er det i praksis umuligt for såvel underleverandør som udvikler og producent at teste samtlige mulige scenarier med samtlige benyttede komponenter.

Bilen der brændte var udstyret med en 'sort-boks' funktion der gemmer fejlmeldinger og sender dem via SMS til producenten, men da bilen ikke havde GSM/GPRS dækning på færgen og 'sort-boks' enheden ikke overlevede branden bliver vi ikke meget klogere af dette. Der havde ikke været fejlmeldinger fra systemet i et par måneder, men statusmeldinger uden fejl blev afsendt før elbilen kørte ombord på Oslobåden.

Den ’sorte boks’ (der i vores tilfælde er gul) i Electric World Tour bilen (www.moto-mundo.com) har undervejs givet data om et par fejl på den bemeldte chip, hvoraf nogle er rettet på ekspeditionsbilen via fjernsupport og andre blot rettet i senere modeller, men fælles for alle de observerede fejl er at de ikke har været sikkerhedsmæssigt kritiske (dvs. f.eks. ikke har kunnet føre til brand).

Som det ses kan jeg trods alt ikke lade være med at engagere mig i debatten her da den forhåbentligt kan skabe bevidsthed om de mulige problemer og løsninger, men jeg vil opfordre til en konstruktivt (men gerne kritisk) indgang til debatten, så vi ikke spilder tiden.

Mvh

Søren Ekelund Grundlægger af A FUTURE EV Mobil 20730028 soedtu@hotmail.com

Da den tidsbegrænsede redigeringsfeature på Ing.dk ikke ville lege pænt med mig, får I lige et tillæg her (Til Ing.dk redaktionen: Stol nu på vi er voksne ansvarlige mennesker og lad os redigere i de indlæg på ubegrænset tid - vil man sikre sig mod en debatørs ændring af indholdet i et indlæg i debatten kan man jo citere de(t) bemeldte indlæg):

Vedr. love var elbilen typegodkendt på europæiske nummerplader et par måneder før branden (faktisk var netop det stelnummer der brændte benyttet som testbil ved godkendelsen), og ingen af de godkendelsesprocedurer der bruges i hverken EU, Norge eller Danmark kan dæmme op for sådan en fejl - og skal heller ikke kunne, idet dette vil medføre et uhåndterligt system der søger at teste underkomponenter og halvfabrikata som leverandørerne bør stå inde for hvis det ikke skal tage årtier at godkende en bilmodel.

Godkendelsessystemet i EU, og ikke mindst i Danmark der har sine egne specialregler, er i forvejen ganske komplekst og indeholder undertiden temmelig mærkelige og ligefrem potentielt skadelige bestemmelser: F.eks. kan en elbil hvis lovens ordlyd følges slavisk ikke have håndfri nøgle, hvilket gav os en del problemer med Nissan Qashqai der er født OG godkendt med denne meget hjælpsomme feature som forbrændingsmotorbil. Et andet interessant eksempel er EMC emission der ud fra standarden kun testes fra siderne, hvilket betyder at elbilen kan støje med elektromagnetiske felter så meget det skal være ud af front og bagende, men i praksis skal støje mindre end en mobiltelefons strømforsyning ud fra siderne... her er absolut tale om standarder der nærmest helt har mistet deres mening, men det er vist en helt anden, dog ikke irrelevant, diskussion.

Mvh

Søren Ekelund Grundlægger af A FUTURE EV Mobil 20730028 soedtu@hotmail.com

Test og test og test - det virker ikke et hak. Derfor, skal love hellerikke dreje sig om testing.

Jeg har selv sidet som tester - og ikke en eneste gang skrev jeg under på, at noget virkede. Det nægtede jeg - for som jeg sagde, at det var umuligt at teste. Det skal konstrueres til at fungere. Og ikke testes til at fungere. I kan teste det så meget i vil, og det vil sku ikke få lortet til at du. Så til sidst, sagde jeg op, da de ønskede jeg skulle teste dobbelt så meget, på den halve tid, og troede at det så vil hjælpe på test resultatet.

Det som det drejer sig om, er at designe tingene så de ikke fejler. I nogle tilfælde kan du som et del af designet, lave fejlsikker design, overvågning, have metoder under selve designet som gør, at tingene fungerer. Det er forskel på, hvilket programmeringssprog du bruger. Du skal ikke have mange variable der skal testes - formålet er, at du skal designe det, så at der er så få variable som muligt! Netop OOP software, havde langt flere variable, end den gamle ikke OOP opbygning, fordi at det bestod af selvstændige objekter, med masser af variable, der blev husket konstant, og defor "levede videre". Dette øger kompleksiteten, fordi et objekt virker som tilstandsmaskine. Den kan gå ind i en fejlende tilstand, og er ikke bare en simpel funktion mellem inputs og outputs. Dertil, havde de brugt parallelisme - men i stedet for, at designe det ud fra regler der fungerer, så systemet var deterministisk, så var det designet i sprog som C, og med masser af parallele tasks, hvor hastigheden og rækkefølgen de udførtes i, havde betydning for resultatet. Igen, et godt eksempel på, at man designer noget til at ikke fungere. De skulle have opskrevet programmet i et sprog så parallelismen var deterministisk, f.eks. brugt erlang. I Erlang, har du ikke mulighed for at indtaste et program, der ikke opfører sig deterministisk, for det dækker sprogets syntaks ikke.

Du kan naturligvis ikke helt undgå tests, og du skal ikke undgå enhver form for test. Men ofte, er det bedre, at have indbygget overvågning, der standser maskinen på en sikker måde, når noget går galt. Og ikke mindst, er det vigtigt, at anvende nogle strategier, således det advancerede, tjekkes af noget mindre advanceret, så at sikkerheden i sidste ende, er simpel og overskuelig.

Det som loven skal indholde, er naturligvis ikke at sætte krav til testing. Tingene skal selvfølgeligt testes, og overholde deres specifikationer. Men, det vigtige er, at loven sætter krav til overvågning. Overvågning, kan f.eks. måle modstand i ledninger, fejl som følge af spændingsfald over ledninger, og der kan måles strømforbrug. Disse kan tjekkes, er indenfor nogle fastsatte rammer, og dette tjek behøver ikke at være nær så advanceret, som bilens "advancerede" styresystem. Det er bare nogle simple regler, der i sidste ende skal overholdes, og så er sikkerheden intakt.

Det samme gælder operativsystemer. Når der er så store problemer, skyldes det operativsystemets design: Det er udviklet, til at aldrigt vil fungere. Og det gælder såmænd også Linux. Mange sprog, såsom C er designet i højere grad, til at være en praktisk lærerigt eksempel på, hvordan man ikke skal udvikle et sprog, og en "samling" af de største brølere der kan begås, og som så er integreret i et sprog. Herefter, har man gjort sproget populært, vel mest for at sikre sig, at man så ved, at dem der falder for sproget, hverken kan datalogi, eller er egnet som programmør.

Jeg mener godt, at man kan lave sikker elektronik - men det koster naturligvis ekstra, fordi at det både koster komponenter til overvågning, og det koster udvikling af dem. Samtidigt, skal ofte sættes krav til fremgangsmetoden - og måske programmeringssprog - som der gøres til andet kritisk elektronik, f.eks. indenfor tog transport. Havde man brugt sådanne sprog hos os, så tror jeg godt jeg kan forsikre, at vi ikke havde haft så mange fejl. Fejlen var C, og Java. Java går ikke igennem "mit" nåleøje. Og i særdeleshed ikke Sun's.

Skal du lave noget som fungerer, så er det udviklingen og vejen fra Idé, til produkt, som er væsentligt. Test, skal bare vise, at du ikke har begået nogen brølere, og at tingene fungerer. Hvis, at der er produktionsskavanker, så skal de også opdages. Men test, skal ikke "reparere" fejl i designet, sådan som det så ofte ses forsøgt. Er der designfejl, som medfører et upålideligt design, fordi at selve processen fra idé til produkt, har været gjort helt forkert, så vil du næppe nogensinde opdage alle brølere. Brølerne, skal opdages under processen, og test skal gøres systematisk, for hver eneste lille ting du foretager dig, under hele processen. Dertil, skal så vidt muligt bruges metoder, der automatisk fanger fejl. I den sidste ende, kan man også bruge overvågningssystemer, der dels har som opgave at logge fejl, således man kan analysere dem, og bruge dem til at undersøge hvor fejlen er opstået (f.eks. toyota's sorte boks - hvis vi så kan stole på indholdet...), og dertil skal overvågningen også stoppe en maskine, eller en bil, før der sker uheld, og at det koster mange penge.

Jeg udelukker ikke, at det stadigt kan ske fejl. Men idag, er der ikke mange biler, og hellerikke elbiler, der overvåger deres ledningsnet, så de opdager, hvis du ødelægger en ledning. Og når Falck er bange for el-biler, fordi der er højspænding på, trods bilen er slukket, og hjulene ikke drejer rundt, så viser det også, at bilen er designet forkert. Her må batteriet ikke kunne levere strøm, og strømmen skal helst afbrydes ved batteriet. Typisk, vil det ske ved der bruges AC til relæet, for at få den til at levere spænding, eller sendes nogle "koder" af sted. Det må ikke være DC, eller andet, som kan "hænge", f.eks. fordi at elektronikken ikke fungerer.

En lovgivning, vil kunne specificere reglerne som skal følges. Så vil der ikke kunne opstå brænde, andet end hvis det skyldes fejl i produktionen af batteriet. Alt andet, vil blive overvåget elektronisk, og hvis det ikke opfylder reglerne, så leverer batteriet ingen strøm, for den får ingen koder, eller AC, som gør at den kan levere energi.

Normalt, har man et system, der består af enheder der overvåger hinanden, og de sender så koder, eller i de simplere tilfælde AC til hinanden. Som eksempel, overvåges en processor ofte af en watch-dog. Dette svarer lidt til relæet, der automatisk kobler ud, når den ikke får AC. Ved watch-dog'en, laver procesoren AC ved at skifte et signal, der instruerer watch-dog'en om, at CPU'en har gennemløbet sit måleprogram og godkendt at alt fungerer som det skal, og ellers vil watch-dog'en genstarte CPU'en med henblik på, at den så retter eventuelle fejl. Hvis dette mislykkedes, så kan CPU'en ikke levere data videre til næste kredsløb i systemet, hvorfor energien forsvinder, f.eks. kobles strømmen fra, eller sikringen springer. Man har normalt et netværk af enheder, der overvåger hinanden, således de hele tiden sender koder til hinanden: Mangler koderne, så har man fejlretningsprocedurer, hvor man undersøger muligheden for at rette fejlen, med så mindst skade som mulig. I sidste ende, har man den hårde vej, hvor sikringer springer, eller relæer kobler fra. Problemet opstår først, når en virksomhed for at spare, vælger at "kortslutte" sikringen.

Jeg udtrykte mig måske en smule for hårdt overfor tests. Naturligvis, skal udføres tests, og det vigtigste er at de udføres under selve udviklingsforløbet. Laver du en komponent, så skal ikke kun komponenten testes, men også dens bestanddele. I virkeligheden, får man derved et hiraki af tests, således at enhver lille del, er testet adskillige gange: Dels af selve producenten af komponenten - for software kan det være programmøren - og herefter af brugeren. For software, kan brugeren være andre programmører. Så enhver komponent, er derfor testet af mindst to uafhængige personer. Dertil, dokumenterer man testen, hvordan den er gjort, og man har test programmer, som andre skal kunne udføre, og se giver samme resultat. Test programmer, kan også have til hensigt, at samtidigt illustrere en komponents funktion, og vise hvad den kan opnå. Ved software, vil man lade brugeren (de andre programmører) få disse tests og beskrivelser, så de starter med at sætte sig ind i komponenten ved at bruge dem. Derefter, så laver de deres egne test programmer, så de også selv kan stå inde for, at det de bruger fungerer. Opdages fejl, så sendes fejlen tilbage til producenten, der herefter retter fejlen. Som regel, er bedst at i første omgang have producenten til at se på det, da han kender årsagen og baggrunden bag, og måske også er bedst til at se, om noget er forkert, eller om det er forkert brug. Hvis man som bruger ikke vil acceptere komponentens funktion, kan man vælge en anden komponent, eller eventuelt få en lavet. Derved består alt, af mange "komponenter" der individuelt er testet, og garanteres fungerer, af såvel konstruktør som bruger.

I sidste ende, så har producenten lavet et produkt - og det er så testet af produktets konstruktører. Imidlertid, er produktet dermed ikke nødvendigvis testet af to uafhængige, og derfor er bedst man har en uafhængig test gruppe i virksomheden. Dennes opgave, er fortrinsvis at tjekke, at alt fungerer, set fra et kunde synspunkt. Typisk vil produktet blive tjekket ud til sine specifikationer, såvel de maximale, som de minimale, så det sikres at de også opfyldes. Og, det vil blive testet i praktiske omgivelser, der måske ikke har været gjort under selve udviklingen. Slut testen, er ofte dyr, men det er dårligt at spare den bort. Men, skal den føre til success, er vigtigt, at alle komponenter og dele, der har ført til resultatet, også er testet, så det er testet op igennem hele hirakiet.

Indenfor software, kan man desuden have programmer, der analyserer om dele af programmerne er blevet påvirket ved en test, og der kan sættes krav til, at alle dele af softwaren, og alle branches og switches i alle retninger, har været gennemgået af test softwaren. Ellers, er det ikke testet godt nok. I nogle tilfælde, kan måske være "sikkerheder" der er lagt ind, og som ikke kan aktiveres, men dette problem kan løses ved, at anvende specielle indstruktioner for disse "fejltjeks", og sikre sig, at disse fungerer, og ikke kan skade - så kan man måske undlade at kræve de udføres. Alle dele, som derfor ikke udføres under testen, skal være specielt godkendt, til at ikke blive udført. En tilfældig programmør, kan derfor ikke nemt lægge en bagdør ind, fordi at testen vil opdage, at de pågældende linier ikke er kørt. Og, så bliver koden analyseret, og programmøren skal måske angive eventuelle "passwords" til sin bagdør, og de indstruktioner der kan udføres, således at enhver linie og indstruktion er udført, når at test er overstået.

Test er derfor ikke noget, man bare skal sløjfe, som jeg måske kunne få det til at se ud som om først. Det jeg mente var, at man ikke med en slut-test kan få tingene til at fungere. Du kan ikke sælge muggent smørrebrød, og få det til at være godt, ved at lade det gå igennem en test, hvor du smider de mugne brød ud. Og oftest, er det den type problematik at test kan dække over. Man tester og tester, på et produkt der ikke er udviklet til at fungere, og så forsøger man, at "fikse" problemet, der skyldes en totalt misforstået udviklingsmetode og process. Det retter kun sjældent problemet, fordi at fejlene bygger på fejl, der bygger på fejl, og det hele er et stort hiraki, der aldrigt er lavet til at vil kunne fungere. Og selvom man så tester nogle systemer til at fungere, så vil de samme systemer måske ikke fungere næste gang de testes. Derfor, forsøgte man i den virksomhed som jeg var ansat, i første omgang at løse problemet, ved at instruere mig i, at jeg KUN måtte teste systemet éen gang: Der var ikke grund til mer. Jeg testede det altid flere gange, indtil det fejlede. Og det skete hver gang. For fejlene, i form af ustabilitet, var et grundlæggende problem, i hele operativsystemet. Formålet med tests, er at sikre der ikke sker fejl under selve udviklingen, og naturligvis skal tests kunne gentages, uden at fejle næste gang. Uanset hvor ofte at de gentages.

Tests, løser dog ikke sikkerhedsproblemet. Her er overvågning og automatisk fejlanalyse og retning, nogle af de effektive metoder. Dog skal man være opmærksom på at automatisk fejlretning, er set udviklet så det har fungeret som nødvendighed, for at produktet fungerer. Så er det ikke mere en sikkerhed, men faktisk et fatalt problem, der kan gøre det hele mere ustabilt. Fejlretning, kan måske dække over underliggende problemer. Formålet ved fejlretning, er ligesom når strømmen afbrydes, at begrænse omfanget af en skade når den er sket, og at gøre det bedst muligt og automatisk. Men, for at undgå, at der sker fejl hele tiden - og måske er fejl i softwaren eller hardwaren - så er vigtigt, at man logger det, så man sikrer at det er i orden, eller analyserer problemet, og viser at fejlretning er den sikre måde at løse et problem, og viser at det er i orden, at løse det på den pågældende måde. Men generalt, må fejlretning aldrigt træde i kraft. Derfor er nogle som mener, at det sikreste altid er, at springe sikringen. Dog er det langtfra altid tilfældet, da det måske ikke er det, som er mest sikkert, i det pågældende tilfælde. Det er også en stor ulempe for kunden. Derimod er vigtigt, at springe sikringen, når det faktisk er god grund til det - altså hvis fejlretningen mislykkedes, og noget kan gå galt. Fejlretning og redundans, er ofte det samme, og vil betyde at man kan ødelægge en del af et system, samtidigt med det fungerer. Det er en stor fordel, og øger sikkerheden, langt bedre end at "springe" en sikring. Men selvom et system retter sine egne fejl, bør det overvåges af et mere simpelt, men sikkert system, der når det går galt, så "springer sikringen". Og fejlretningen, bør ofte noteres i en "black box", så man har kontrol over den, og ved når det sker, og hvad det skyldes. Sker en fejlretning, så skyldes det måske skader på systemet, og så er god grund til, at få løst problemet. Her er så nogle, der vælger at "spamme" den sorte bog, eller loggen i black-boxen, så den smaskfyldes med fejl, der i sidste ende ingen mening giver - og som måske intet betyder, i forhold til de fejl, den får overskrevet.

Naturligvis er ikke billigt at udvikle og producere elektronik, eller andet som fungerer, og er sikkert. Og det er naturligt, at producenterne vil undgå det, hvis de ikke påbydes at opfylde en lovgivning. Her er også vigtigt, at det er muligt at teste at loven opfyldes, og her er det også ofte nemmere at teste et overvågningssystem fungerer, end at mange millioner liniers kode fungerer. Sikkerhedssystemet er designet til, at være simpelt, og slå fra, når det er nødvendigt. Det er sidste sikkerhed - og den bør være muligt at teste og designe til at fungere sikkert.

Hvis der ikke er en lovgivning, så vil vi sandsynligvis også se, at en sådan test ikke gøres ordentligt, men bare påstås at være gjort efter alle kunstens regler af producenten. De er dygtige til at prale, men gør alt for at spare. Ofte ser man, at sikkerheden gøres forkert, og der bruges relæer der kan hænge, er placeret på et uheldigt sted, eller der bruges et DC signaleringssystem, der relativt nemt kan snydes ved en kortslutning, eller en defekt transistor der leder strøm uafbrudt. Også her, vil en lovgivning, som regel kunne henvise til standarder der skal følges, og som specificerer hvordan det gøres på den mest sikre måde, således at defekte transistorer, defekte relæer, eller kortsluttede ledninger, ikke kan sætte et systems sikkerhed ud af drift.

Tusind tak for et meget dybdegående og konstruktivt indlæg, Jens Madsen – jeg er lidt bekymret for at vi her er på vej ud af en tangent i forhold til artiklens primære indhold; nemlig konsekvenserne af en mediestorm, men dit indlæg er absolut relevant så lad os alligevel gå ind i teknikken:

Jeg har selv, i tilgift til uddannelse som maskiningeniør og el-tekniker, baggrund som autodidakt udvikler og programmør af logistiksystemer, og har derfor haft meget at gøre med fejlsikret (eller rettere ”fejlmindskende”) design: At eliminere enhver fejl i komplekse systemer er sjældent muligt da det kræver at vi kender hver eneste variabel i systemet og er 100% sikre på variablernes indbyrdes samspil, og det viser sig hurtigt at være umuligt at regne på med en overskuelig responstid når dynamiske fysiske systemer indblandes i designet. Min bedste løsning hidtil (kombineret med konventionelle sikkerhedsløsninger som tjeksumme og statistisk selvtest) er dynamiske algoritmer (grænsende til selvlærende AI), der konstant sammenligner målinger, beregninger og valg fra hele systemet og sammenligner det med forventede resultater baseret på historik og estimeringer, i en systematisk men selvjusterende (læs: delvist erfaringsbaseret og konstant lærende) stikprøvemetode. Sammen med en relativ lav tærskel for de acceptable afvigelser er det min erfaring at dette giver en lidt højere risiko for småfejl (sammenlignet med hvis al regnekraften til sikkerhed benyttedes til konventionelle løsninger) men klart den laveste risiko for kritiske fejl og systemnedbrud. Denne løsning kræver naturligvis et relativt stort budget og tidsramme til sikkerhedsprogrammellet.

Problemet som jeg ser det er, at når vi træder ud af den rene data verden og over i målinger på den fysiske verden øges kompleksiteten af systemet til et punkt hvor streng systematisk test bliver umulig og hvor fail-safe løsningerne skal være så talrige at det på forhånd ligner et Sisyfos-arbejde: I det konkrete tilfælde her (med udgangspunkt i hypotesen om at overvågningschippen er årsag til færgebranden; dette ved vi ikke med sikkerhed og kommer næppe til at få 100% sikkerhed for) er der tale om en hardware fejl i form af overophedning af en komponent på en overvågningschip, sandsynligvis som følge af en atypisk produktionsfejl, der derefter har antændt omgivelserne; her lithium batterier.

Skulle vi også have haft en komponent til at overvåge overvågningschippen? Og hvad skulle have overvåget overvågningschippens overvågningschip for fejl? Selv hvis vi laver en treenighed der overvåger hinanden (som det faktisk er tilfældet for en lang række systemer i bilen, hvor f.eks. batteristyringssystemet (BMS), køretøjsstyringssystemet (VCU) og motorstyringssystemet (MCU) indbyrdes overvåger hinanden, ledningsnettet og underkomponenter, hver med sin egen watch-dog, mens en ’black-box’ med separat batteri overvåger dem alle, gemmer data og sender dem til en ekstern server når der er GSM/GPRS forbindelse) kan vi i praksis ikke gøre dette for hver enkelt elektronikkomponent uden at systemets kompleksitet, og dermed risikoen for fejl ved f.eks. produktion (der kan være selve grunden til branden her), stiger voldsomt. Samtidig skal det her tages i betragtning at ikke alle komponenter fremstilles internt og at underleverandører sjældent er særlig glade for at man beder om en totalforklaring på deres licenserede hardware og kode for at kunne lave et integreret sikkerhedssystem – nervøsiteten for illegal kopiering, omprogrammering og videreudvikling er temmelig stor, og ikke uberettiget da vi bl.a. har set multinationale batterileverandører skamløst kopierer BMS-leverandørers systemer.

Der er her ikke tale om en systematisk fejl som kunne være testet i designfasen, men en produktionsfejl som måske burde være fanget af underleverandørens producent – da denne komponent muligvis er blevet benyttet for første gang i den 6 måneder lange levetid ville en test der fangede dette at hver eneste producerede chip blev testet under alle maksimalforhold før den blev afsendt – dette er næppe et normalt krav og en nærmest umulig logistisk opgave når antallet af komponenter tages i betragtning, og som alle involverede skal teste hvis vi ikke stoler på hinanden. Vi har for praktiske formål og efter inspektion valgt at stole på at vores underleverandør testede ordentligt i designfasen, der på sin side har stolet på at producenten lavede en ordentligt sluttest, og det skulle forhåbentligt også være sket i langt de fleste henseender – men tydeligvis ikke i alle. Alligevel mener jeg ikke det er muligt at teste sig ud af denne situation, da det ville kræve at vi internt testede hver eneste underleverandørs produkt til bunds, hvilket vi hverken kan få udleveret data til eller har ressourcer til hvis bilerne skal leveres til en nogenlunde overkommelig pris. At dette ikke kun gælder ”amatør projekter”, som visse morsomme folk har kaldt A FUTURE EV, vises jo bl.a. af Peugeots ”lille” låseproblem: http://www.dr.dk/Nyheder/Indland/2011/02/0... Det bør ikke kunne ske at sådanne fejl slipper gennem test, men det gør de nu altså alligevel undertiden pga. af de mange, også menneskelige, faktorer i hele systemet – især når det gælder udvikling af ny teknologi. Som en så smukt skrev andetsteds; ”de som intet gør laver ingen fejl…” Men derfor skal vi naturligvis minimere risikoen indenfor al rimelighed.

Det er dog sjældent nok at konstaterer fejlen; i vores konkrete eksempel er der stadig for høj varme selvom vi konstatere fejlen og stopper systemet, så vi skal også have en mulighed for at gribe ind. Helst skal vi naturligvis gribe ind før fejlen bliver kritisk (ved f.eks. at slukke en komponent der bliver usædvanligt varm, før den bliver kritisk varm), men da komponenten her stort set i det øjeblik den blev tilsluttet har opnået de kritiske 150 deg C i en lysbue i en dårlig lodning kan vi næppe reagere hurtigt nok. Da måleudstyret sidder direkte på battericellerne (som det måler små marginaler på og derfor ikke godt kan sidde andet sted, ligesom de sidder under den brandhæmmende beklædning af samme årsag, mens alt andet end sensorelektronikken er holdt langt væk fra batterierne) er branden her stort set allerede overbragt til battericellerne (vis interne struktur reagerer med kortslutning ved over 150 deg celsius) så snart overophedningen sker, hvorfor vi ikke har de store muligheder for at modgå fejlen ved at slukke for systemet. Selv med et lynhurtigt system der kunne køle komponenten (f.eks. skumslukker) ville branden allerede være startet i batterierne, og de kan ikke slukkes (kræver ikke ilt da varmeenergien kommer fra en ren intern kortslutningsproces) men kun nedkøles, hvilket vil kræve langt højere køleeffekt end batterisystemet er i besiddelse af for ethvert normalt formål. Et brandslukningssystem med den rette kapacitet kan stort set ikke være i en bil og ville her tilføre mange yderligere komponenter og vægt, hvilket vil mindske køretøjets effektivitet og medføre yderligere mulige fejlkilder.

Man kunne naturligvis argumenterer for at vi ikke bør have sensorer så tæt på batterierne, men dette er omvendt en nødvendig sikkerhedsfaktor for at detektere fejl der opstår i selve cellerne og stoppe disse før de overopheder sig selv under op- eller afladning. Så kan man naturligvis argumenterer med at der ikke bør benyttes så brandfarlige batterier, men indtil videre er højkapacitets lithium batterier nu den bedste mulighed vi har for langtrækkende elbiler (med undtagelse af nyere eksperimentalbatterier) og så må det skiftes ud efterhånden som bedre muligheder viser sig. I forvejen benyttes sikkerhedsbatterier der ikke kan eksploderer (de brænder blot kraftigt) og kræver temmelig høj varme for at reagerer (tidl. batterier f.eks. krævede blot 100 deg celsius), og alternativet i dag er f.eks. saltbatterier, der er stort set umulige at få til at brænde men til gengæld er relativt tunge og aflader op til 14% i døgnet. Vi accepterer jo også at køre med eksplosionsfarlig benzin, selvom der er mindre farlige, men også mindre praktiske, alternativer.

Løsningen mener jeg således i sidste ende er den samme som nævnt for logistiksystemerne; at acceptere muligheden for mindre fejl og i stedet reducere risikoen for kritiske fejl mest muligt (med tidsplan, budget og ikke mindst konsekvenserne ved fejl taget i betragtning – ofte et temmelig subjektivt skøn desværre da de fleste variabler her er ukendte i designfasen) og så i øvrigt være opmærksom på at INTET HØJTYDENDE OG KOMPLEKST SYSTEM ER 100% FEJLSIKRET og tage hensyn til dette i alle henseender, samt FORBEDRE SIKKERHEDEN LØBENDE og RET FEJL SÅ SNART DE OPDAGES.

Opfordres der samtidig til en kritisk holdning overfor systemet har man således sikret sig bedst muligt inden for rammerne – om det er ’godt nok’ bliver så nærmere en diskussion om meninger vedr. risikovillighed og lovgivning end om teknik. Men lad os meget gerne høre forslagene til forbedringer på alle områderne, såvel teknisk som lovgivnings- og risikomæssigt.

NB: Rent faktisk blev det efter branden konstateret at et hovedrelæ måske svejsede under batteriernes kortslutning, eller muligvis var svejset før dette, på trods af belastning på max. 75% af den specificerede brydestrøm selv ved batteriernes kortslutning. Relæet har dog redundans i form af et reserverelæ, således at sikkerhedssystemet virkede trods fejlen og hovedlederne blev afbrudt i fejløjeblikket. Denne fejl er, selvom den ikke var kritisk, overgivet til producenten af relæerne via de brandtekniske myndigheder, og vi undersøger den nærmere sammen med producenten – relæerne skal jo virke og i teorien kunne begge relæer have svejset samtidigt; det havde så bare resulteret i en sprængt hovedsikring, men bør under alle omstændigheder ikke ske uanset om det er kritisk eller ej. Igen gør det komplekse system det svært at vurdere hvori fejlen ligger, da vi kun måler om relæerne samlet afbryder, ikke om ét ud af to redundante relæer er svejset – dette vil blive rettet i et senere system, hvis det vurderes at være kritisk nok til at være ressourcerne værd; sådan må man jo desværre altid vurdere i en verden hvor varer skal sælges for maksimal profit. Også non-kommercielle projekter som f.eks. Copenhagen Suborbitals ligger dog under for ressourcebegrænsninger og må foretage lignende valg, så vi kommer næppe uden om at skulle acceptere en eller anden form for risiko – det gør vi jo også hver dag vi går ned på gaden eller blot tager det næste åndedrag, så det er jo ikke så mærkeligt endda; derfor bør dette handle om fornuftig risikostyring og ikke den praktisk umulige risikoeliminering.

Mvh

Søren Ekelund Grundlægger af A FUTURE EV Mobil 20730028 soedtu@hotmail.com

Var der ikke et fransk bilmærke Peugot, som blevet meget varme, pg lidt vand i elnettet, der gik faktisk ild i dem.

Nu kender jeg ikke ovenstående fabrikat, men hvis det er Peugeot du tænker på, så jo - der brændt et par stykker for nogle år siden. De var dog med forbrændingsmotorer og ikke elbiler, som artiklen handler om.

Årsagen var et plastikstykke med stikforbindelser

Ja, det gik ud over flere fabrikater, min Citroen blev også kaldt ind, det gik ud over biler der havde fået kontroleren til ESP men solgt som ABS, når der kom fugt i det ubenyttede stik så selvantændte bilerne, altid under parkering, og aldrig i drift, ret praktisk, for når folk ikke tør holde ved siden af, så er der jo ekstra god plads ved dørene.

Det blev så vidt jeg husker fikset tidligt 2003.

Ja, det gik ud over flere fabrikater, min Citroen blev også kaldt ind...

...og Citroen-forhandleren i Otterup brændte ned til grunden, på den konto.