Senaste nytt

FAA groundar samtliga 787:or

Vill påstå att den där typen av problem med räknare som "slår runt" är betydligt vanligare än man tror och i praktiken ett större problem än vad År 2000-problematiken någonsin var.

Problemet finns i alla möjliga komponenter. Förvisso var det vanligare för några år sedan då det var ont om minne och man var tvungen att hushålla med bitarna, men det förekommer uppenbarligen även idag även i dyra komponenter där minne troligen inte är en riktig bristvara ;)
 
Allmänt trist att just 787:eek:rna dras med så många problem med tanke på vilket fantastiskt flygplan det är. Hoppas Airbus gjort hemläxan med A350.
 
Allmänt trist att just 787:eek:rna dras med så många problem med tanke på vilket fantastiskt flygplan det är. Hoppas Airbus gjort hemläxan med A350.
Ja, det hoppas jag med. Men verkar lovande. Just nu flyger ju bara två flygplan hos Qatar förutom testplanen. Har dock inte läst något om att A350 ska ha några barnsjukdomar likt 787. Båda två är väldigt fina flygplan!
 
Ett slarvfel. En int32-räknare som klockas i 100Hz wrappar runt efter 248 dagar. Men inte ett problem i praktiken, då inga plan är "på" i 248 dagar i sträck iaf.

Fast så där har man sagt förr. Man skapar en parameter i systemet som man "aldrig" kommer att överskrida. Sen ändras mycket av mjukvaran över åren och den där parametern glöms bort. Många år senare sker något som gör att den där parametern som "aldrig" skulle överskridas, överskrids. Vilket leder till problem.

I december 2014 skapades stora förseningar pga en funktion som skapades på 90-talet. Förvisso har mjukvaran ändrats enormt sen dess, men just den där funktionen var uppenbart kvar.
http://www.caa.co.uk/docs/2942/v3 0 Interim Report - NATS System Failure 12 December 2014.pdf


I min mening ska man försöka bygga säkerhetskritiska system (såsom flygplan) på ett sånt sätt att det här aldrig ska kunna hända. Jag vet att det ibland är svårt (och sannolikt omöjligt) men då måste systemet konstrueras "fail-safe". Man måste alltså se till att inte backupen slås ut samtidigt, vilket verkar varit fallet här.
 
Fast så där har man sagt förr. Man skapar en parameter i systemet som man "aldrig" kommer att överskrida. Sen ändras mycket av mjukvaran över åren och den där parametern glöms bort. Många år senare sker något som gör att den där parametern som "aldrig" skulle överskridas, överskrids. Vilket leder till problem.

I december 2014 skapades stora förseningar pga en funktion som skapades på 90-talet. Förvisso har mjukvaran ändrats enormt sen dess, men just den där funktionen var uppenbart kvar.
http://www.caa.co.uk/docs/2942/v3 0 Interim Report - NATS System Failure 12 December 2014.pdf


I min mening ska man försöka bygga säkerhetskritiska system (såsom flygplan) på ett sånt sätt att det här aldrig ska kunna hända. Jag vet att det ibland är svårt (och sannolikt omöjligt) men då måste systemet konstrueras "fail-safe". Man måste alltså se till att inte backupen slås ut samtidigt, vilket verkar varit fallet här.
Mitt inlägg var inte direkt tänkt som ett försvar, utan en teknisk beskrivning av problemet. Du har rätt i det du säger, men jag vågar påstå att det inte är applicerbart i detta fallet. Jag kan inte se att de kommer klocka upp processorer i framtiden för att få ut mer av gamla flygplan. ;) Nu vet inte jag designtanken här, men med tanke på att detta system alltid nollställs var 30e dag om jag förstått det rätt, så är ju 248 dagar en bra failsafe. Men visst, en int64-räknare hade ju klarat sig till efter universum imploderat. :)

Man kommer ju heller aldrig behöva mer än 640KB minne heller... ;)
 
  • Gilla
Reactions: doc
Mitt inlägg var inte direkt tänkt som ett försvar, utan en teknisk beskrivning av problemet. Du har rätt i det du säger, men jag vågar påstå att det inte är applicerbart i detta fallet. Jag kan inte se att de kommer klocka upp processorer i framtiden för att få ut mer av gamla flygplan. ;) Nu vet inte jag designtanken här, men med tanke på att detta system alltid nollställs var 30e dag om jag förstått det rätt, så är ju 248 dagar en bra failsafe. Men visst, en int64-räknare hade ju klarat sig till efter universum imploderat. :)

Inte ett problem som det ser ut idag, men en klar potentiell risk om man till exempel skulle byta ut RAM mot NVRAM som man lagrar räknarna i om ett årtionde, eller liknande designförändringar.

Och nollställningen var 30e dag är ju under förutsättning att ingen "smart" ekonom kommer på att det skulle kosta mindre om man gjorde underhåll med 10 gånger så långt intervall som tillverkaren rekommenderar. Bör inte vara ett problem i länder med fungerande tillsynsmyndigheter, men det finns väl tyvärr motexempel på det också.

Också en liten svaghet i att man har 4-vägs redundans på generatorer, men samma styrsystem till dem så att de har gemensama felfall.
 
Toppen