Протокол от съдебния разпит относно проблем с неконтролирано ускоряване на Тойоти - дълго, но доста интересно четиво ... и ако всички нови коли се правят с подобен софтуер отивам да си купя една стара трошка без грам процесор в нея ...
https://www.dropbox.com/s/wnzqidngrtj8y ... DACTED.pdf
Не знам дали тук е най подходящото място за този пост.

Eeeee до 59 стигнах ама то много бре ... дай интересната част ако си я намерил.

За мен интересното беше описанието на грешките които е намерил Барр - наивна работа - препълване на стека, което омазва разни системни променливи в резултат на което една нишка гръмва - точно нишката която се грижи за сигурноста на системата. И от там като няма кой да провери, че нещата са асе сгомнясали става забавно - ако има включен круиз контрол, започва ускоряване за да се стигне зададената скорост, но проверката, че е стигната и тя е в умрялата нишка, съответно колата продължава да ускорява докато на шофьора не му направи впечатление, че нещо не е както трябва и набие спирачки при което сработва най после друга защита при която нещата пак влизат в релси. В началото верно са общи приказки, ама около 80 страница вече е интересно. Освен това са хванали - препълване на буфери, използване на неинициализирани указатели, рекурсия и още доста подобни грехове. Въпреки, че са участвали в правенето на стандарти за безопаснот отностно как се пише софтуер за автомобили, те самите въобще не са ги спазвали. Не се поддържа дори списък с бъговете, кой и кога ги е оправил и т.н. Абе явно всичко е правено джаста праста ...

Софта на тойотите индийци ли го пишат!?

Тц. Японци
Всъщност втората защита просто спира мотора ... сещайте се един типичен американец с какъв ентусиазъм води дело срещу Тойота след като докато си е карал кротко по магистралата колата му е тръгнала да ускорява, изпадайки в паника по някое време се усеща, че нито педала за газ нито круиз контрола повече работят, удря една спирачка и мотора му спира. Или е ударил колата пред него - т.е виновен отвсякъде, движил се е несъобразена скорост, или колата зад него го удря защото е набил рязко спирачки.
Пък ако имал късмета да е натиснал спирачката докато проблема се случва май е ставало още по интересно - според инжинерите на Тойота нещата продължавали зле според количеството гориво в автомобила ...
Ъъъъ ... може леко да бъркам превода, че го четох снощи полузаспал, който му е интересно да чете - 280 страници е ... и това е само протокола от разпита на колегата, анализа му не е публикуван - 800 страници.

http://embeddedgurus.com/barr-code/2013 ... eleration/
Това е блога от който е линка към съдебния протокол, има кратко резюме ... и

Т.е. 500+ дела, ако всяко се размине с по $1.5 милиона ... вървим към милиард долара щети ... май ще грабнат купата за най скъп софтуерен бъг

Само не си мислете, че Тойота са изключение. По-скоро ако има някой, който да не е като тях, ще е изключение.

Всички така работИМ. Проблема не е в това дали са го писали индийци, пакистанци или японци. Проблема е, че се стигна до някаква бясна надпревара с времето. Доктрината е нов модел всяка година. И най-бесния гуру на програмирането да хванеш, като го притиснеш зверски с времето - почват компромисите. От там до въпросния турлюгювеч стъпката е ужасно малка.

Цецо, в случая май ситуацията е друга. Тойота не е случайна компания, имат си самочувствие (то се вижда по цените им), имат имидж да защитават и т.н. Открито си признават, че доста време не са имали капацитет (разбирай хора) които да са нясно как се прави failsafe firmware, съответно много неща са правени от подизпълнители и никой в Тойота не е проверил кода който вграждат после в автомобилите. Имат нелоши кодинг рулес които не се спазват, и това на никой не му прави впечатление.
Цинизма е, че са сложили външен watchdog и нишката която си комуникира с него работи, въпреки че нишката която върши основната работа и се грижи за целоста на системата е умряла. Т.е. този watchdog не им решава никакъв проблем, единственото което прави е ако се натовари много процесора да го ресетне, не и ако процесора се омота щото тогава от нищоправене не е и натоварен. Абе ... жална им майка ... гледай сеир сега как ще се раздуха това по медиите ...
(Между другото във фирмата в която работя нещата не се правят през пръсти, всичко си е точно, съответно цените не са особенно конкурентни и фирмата не е цъфнала и вързала, но ми е кеф да работя както трябва да се работи, вечер лягам и заспивам спокойно, компромис с качеството не се прави)

Преди малко обсъдихме с един приятел случая. Той (железар) каза ,че с неговото карбураторно ауди'88 такова нещо не може да се случи. Мене обаче друго ме впечатли-
сорса май отива към милион линии на С, и се споменават 10'000 глобални променливи.

Всичко това е странно на фона на защитите реализирани в хардуера против разни глупави издънки.
Например, на доста от автомобилите педалът за "газ" е с два датчика. При някои са свързани насрещно - когато напрежението от единия датчик се увеличава, на другия намалява. Следят се данните и от двата и ако има разлика над определен процент - дефектен датчик и в авариен режим.
Същото е и с датчиците на дроселите с електрическо задвижване.
Подобно е и с бутоните за запалване - с два контакта. Пак се следят и двата.
При някои при които стартерът се управлява от екуто, комутацията е през две релета - едно с нормално отворен контакт, и втори с нормално затворен.

Казано в резюме, подсигуряват се повече от добре, и такива тъпи издънки...

Ами точно конкретно не съм го чел. Ама знам, че като дойде заповед отгоре, да сме готови с три тона сорс и хардуер за вчера... Не такива, ами дваж по-големи лайна бъркаме. Щото стандартите са много хубаво разписани, ама струват ВРЕМЕ, къде за учене, къде за имплементиране, къде за тестване (това най-вече). А ВРЕМЕТО е пари. Просто няма как в това зверско бягане и зверско поевтиняване да се ражда нещо читаво.

Без да претендирам да съм печен програмист, знам, че качеството на писане е правопропорционално на времето за писане.

Абе прав си, спор да няма, хората които го правят това нещо бързо без грешки, са обикновенно с много години опит - т.е. иска си време да натрупат опит, че да правят всичко бързо и качествено (и съответно скъпо). В случая обаче грешките са направо лапешки ... срамна работа.

Едит: Спестили са един десетки милиони в разработката, сега ще платят стотици милиони, може би и милиарди за неустойки. Един екип от 10-на човека с опит няма да им излезе повече от 4-5 милиона годишно, 10 да са - пак не излиза математиката да си е струвал компромиса.

Ицо, точно тук е веселото, задачата която следи тези неща е забила по някаква си причина, и всичко спира да работи ... демонстрирали са как със смяна на 1 бит се получава този (д)ефект. Преди 15 години ръчках покер машини, е как в тях имаше 2 копия на данните (все пак говорим за пари там ) а за кола с която можеш да се претрепеш няма да го направят, т.е. направено ама половинчато, защитили си техната програма, а ОС-а отдолу останал по бели гащи - с 4к стек + рекурсия.

Това с висването на някой таск го схванах, но на фона на подсигуряването откъм железа е направо безумно... Все пак, разработката на софтуер се плаща и приключва. Скъпите железа се плащат на всяко вградено такова...

Тук ме загуби като аудитория. Говориш ми на китайски. Аз на тема програмиране съм блондинка...

Важни променливи на ОС-а са останали незащитени по никакъв начин. Стека на една от нишките е 4к, от Тойота са сметнали, че ползват в най лошия случай 1.5к, колегата който е правил анализа е сметнал, че ползват 3.9к което е много близо до препълване, и това без да се взима в предвид рекурсията която са допуснали, т.е. с тази рекурсия стека не стига и препълва, от там точно под стека където е препълването се намират тези незащитени данни на ОС-а които като се омажат task scheduler-а почва да прави бели и на практика спира task-а който има грижата за прави failsafe т.е. яхнал си едно торпедо ...