`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Андрей Зубинский

Качество встраиваемого ПО или погром всё-таки случился

+3030
голосов

Сразу предупреждаю - текст будет не для слабонервных. Это почти что Стивен Кинг. Ужасы будут. Ещё и какие.

Поучительная и очень печальная история, длившаяся шесть с лишним лет, подошла к своему логическому завершению. Мы из итогов можем чему-то научиться, а я могу как бы продолжить предыдущую запись в этом блоге, потому что тут есть о чём поговорить.

Итак, лет шесть назад две пожилые женщины в штате Оклахома поехали куда-то на своей Toyota Camry и поездка их закончилась трагически – одна из них погибла (пассажир), вторая получила тяжёлые травмы.

Ситуация была усложнена почтенным возрастом потерпевших, что позволило затянуть судебные процессы на годы и списывать странное поведение машины на водителя (которой просто не повезло, трудно представить себе почтенную пожилую даму, разгоняющую далеко не лёгкую и чтобы очень уж резвую Camry до привычных нашим владельцам этих диванно-мягких колесниц, почему-то считающихся у нас чуть ли не «спортивными», скоростей).

Странность же в поведении заключалась в том, что машина вдруг стала набирать скорость.

Первоначальная реакция официальных представителей Toyota в судебном процессе была очевидной – «иногда люди делают ошибки при управлении своими автомобилями».

Потом случилось ещё более неприятное – Camry начали неоднократно проявлять норов и склонность к неуправляемому разгону. Из-за чего возникли сотни судебных исков. Списать всё на возраст водителя уже не удавалось, и виновный был как будто найден, им оказался… штатный коврик, который якобы поджимал педаль газа из-за неправильных размеров и недостаточной эластичности.

Всего на удовлетворение потока исков Toyota в прошлом (2012) году затратила более миллиарда долларов, некоторые иски в судах отдельных штатов были не удовлетворены, например, суд Калифорнии отклонил 20-миллионный иск родственником водительницы Camry 2006 года выпуска, погибшей в результате неуправляемого внезапного разгона автомобиля.

К расследованию странностей в поведении Camry были подключены специалисты NASA, изучавшие возможность потенциальных проблем в подсистеме управления акселерацией этого автомобиля на протяжении 10 месяцев. Анализ группы специалистов NASA оказался в выводах непростым (по ссылке - немаленький pdf-файл отчёта группы NASA):

Группа [исследователей] NESC идентифицировала два гипотетических сбоя контроллера заслонки ETSC-i (не связанных с неэлектронными причинами…), способных привести к внезапному ускорению автомобиля без генерации кодов диагностики – специфические ошибки в определении положения педали газа и систематические программные ошибки в вычислителе контроллера акселерации, которые не выявляются системой мониторинга автомобиля… Последний сценарий связан с открытием дроссельной заслонки без команды водителя и одновременным сохранением работоспособности систем непосредственного впрыска и зажигания. Непосредственное доказательство того, что эти сбои привели к выявленным авариям, группой не получены, но это не означает, что из-за них подобные аварии невозможны.

И вот, наконец, история пришла к завершению – 24 октября суд штата Оклахома признал Toyota ответственной за инцидент шестилетней давности с присуждением полуторамиллионного штрафа

А специалисты в области embedded-программирования по окончанию судебного процесса получили возможность открыть данные об экспертизе «прошивки» злополучного контроллера дроссельной заслонки.

И данные оказались далёкими от утешительных.

Итак, группа экспертов, информацию о которых можно легко отыскать на сайте «гуру embedded программирования» (EmbeddedGurus), после анализа firmware контроллера дроссельной заслонки пришла к выводу что (даю дословный перевод) «это позорный образец проектирования и разработки ПО».

В выводах – общее низкое качество кода, наличие ошибок в нём, которые могут вызывать случайный разгон автомобиля, общая система контроля и обеспечения безопасности исполнения кода  организована по принципу «карточного домика», и, наконец, вердикт, к которому прислушались судьи – ошибки в firmware стали причиной аварии с тяжёлыми последствиями.

В ходе анализа злополучного контроллера экспертами были проверены и отклонены предположения Toyota, что ошибки являются следствием аппаратных сбоев в микроконтроллере NEC (Renesas) V850, а именно, в его интерфейсе с внешней памятью с контролем чётности. Что неудивительно даже без экспертного анализа, потому как контроллеры Renesas (некогда NEC) – в своём роде эталонные для автомобильной индустрии (и не только), и используются в неисчислимых количествах, о такой злополучной ошибке (явно приводящей к порче памяти) давным-давно знал бы весь мир, она или была бы исправлена в кремнии, или хотя бы внесена производителем в Errata (уточняющую документацию).

Вот, собственно, как выглядит этот самый вычислитель, из-за которого вся история, совершенно обычный встраиваемый компьютерчик, никакой rocket science, просто добротная плата с весьма традиционными для автомобильной индустрии компонентами (самая большая микросхема - тот самый NEC-Renesas V850):

 

Качество встраиваемого ПО или погром всё-таки случился

 

Контроллер дроссельной заслонки, по идее, не самое страшное, что можно придумать. По идее. Он считывает положение педали (или принимает его от другого контроллера по какой-то бортовой сети вроде CAN или более развитой надстройки над CAN, FlexRay). Если он сам считывает информацию, то выдаёт CAN-датаграмму об этом прочим контроллерам, и, само собой, формирует управляющий сигнал шаговому двигателю заслонки. Ещё он очевидно «завязан» в систему поддержания стабильной скорости (круиз-контроля). Собственно, это всё. Что подтверждается здоровенным прошлогодним тематическим документом от самой Toyota (большой pdf-файл, только для любителей hardcore подробностей, он интересен потому что демонстрирует прошлогодние объяснения).

Ну а теперь держимся крепко за что можем держаться – в firmware, решающем эту задачу, надстроенным над операционной системой реального времени, экспертиза выявила… одиннадцать тысяч глобальных переменных. Код реализации firmware назван хорошо знакомым всем программистам словом «spaghetti». Анализ цикломатической сложности программы выдал 67 не пригодных для тестирования функций, а ключевая функция определения угла дроссельной заслонки в ходе этого анализа показала какую-то удивительную оценку, при которой не только тестирование, но и вообще какое-либо сопровождение программы невозможно. Соблюдение отраслевого стандарта кодирования (для автомобильной промышленности такой есть, даже целое семейство, совокупно называемое MISRA) характеризуется выявленным числом его нарушений – их набралось 80 тысяч (в Toyota принят свой внутренний стандарт, который заимствует из MISRA всего 11 правил, при минимально требованных во время написания кода 93-х). По ходу дела было выявлено, что в такой сложной системе полностью отсутствует учёт сбоев и ошибок. При всём этом великолепии все связанные с безопасностью функции контроллера в его «прошивке» оказались реализованными одним единственным процессом. Тема отдельного разговора – watchdog. В «настольном» программировании это нечастое явление, в мире встраиваемых систем – необходимая функция. Watchdog или сторожевой таймер – обычно внешнее по отношению к вычислителю устройство (хоть бы и реализованное на одном с вычислителем кристалле). Принцип его работы предельно прост – если какой-то процесс вовремя не сбросил ранее выставленный на какое-то время страбатывания сторожевой таймер, последний вызовет аппаратное прерывание, оповещающее вычислитель, что с процессом что-то явно не так, или вообще инициирующее быстрый системный сброс. Использование watchdog в «прошивке» вызвало большие сомнения у экспертов – подконтрольным сторожевому таймеру в этой системе оказался по сути только процесс, обслуживающий редкие прерывания системного таймера, что означает – любой сбой в обработчике прочих прерываний мог приводить к исполнению неизвестно чего примерно… полторы секунды до сброса вычислителя от сторожевого таймера. И эксперты не взялись утверждать, что эти полторы секунды до сброса гарантированы, они не исключили возможности, что сброс вообще не наступит. Напоследок не менее прекрасное – коды возврата большинства вызовов RTOS, которые предназначены для сообщений об ошибках, в «прошивке» вообще игнорируются.

Дальше начинается архитектурное. Не менее красивое. Основной вычислитель (неповинно обвинённый в грехах NEC-Renesas V850) мониторится дополнительным микроконтроллером с «прошивкой» от стороннего производителя, которая выходит за границы ответственности Toyota. Да, это хорошо, когда есть независимый мониторинг. Но каким образом единственный аналогово-цифровой преобразователь, который как раз и предназначен для считывания аналогового сигнала положения педали газа оказался мало что не зарезервированным (продублированным), но ещё и интегрированным именно в этот второй микроконтроллер – это даже трудно сказать кто такое придумал. Точности-то от такого преобразователя нужно всего ничего (ну какая может быть прецизионность в нажатии на педаль газа), АЦП такого класса совершенно копеечные и прекрасно отработаны, и вот такая экономия, формирующая потенциально сверхопасную «точку критического сбоя» (single point of failure). Изящное решение оказалось адекватно поддержанным на уровне кода – отказоустойчивый код сопроцессора-монитора оказался зависимым от неназванной из принципов соблюдения промышленных секретов функции, выполняемой основным микроконтроллером, причём на эту одну функцию взвалили кучу всего – от преобразования угла педали в угол дроссельной заслонки до управления в режиме круиз-контроль и даже до диагностики.

Прямо скажу – когда я читал оригинальные статьи и дошёл до одиннадцати тысяч глобальных переменных, используемых в системе реального времени, где любое лишнее находящееся в общем для всех процессов доступе состояние – уже большая проблема, мне стало как-то не по себе. И потому хочу ещё раз напомнить, о чём писал в прошлый раз.

Без сомнения, этот странный код для Toyota писали не школьники и не студенты. И проектировали вычислитель, оказавшийся тоже весьма загадочной архитектуры, вовсе не профаны. Без сомнения и слава богу, что вроде как это не во всех моделях машин такое, что всё это выявлено и локализовано, что в Toyota после такого кошмара (есть такие специально обученные люди, занимающиеся репутационным менеджментом, так вот я им, которые из Toyota, очень не завидую) всерьёз улучшат разработку и тестирование firmware.

Но этот наглядный пример в контексте рвущегося в ширь и ввысь IoT (Internet of Things) надо бы не забывать. Надеюсь, что индустрия его не проигнорирует. Уже не получится. Потому что шум поднялся на весь мир.

Откланиваюсь.

Про DCIM у забезпеченні успішної роботи ІТ-директора

+3030
голосов

Напечатать Отправить другу

Читайте также

да ладно, ничего страшного.

Подумаешь утюг в эфир выходит, ему сеть wifi нужна.
Кофеварка в пузо мужу плюнет кипятком ,
Ребенка испугает унитаз,
А домашний лабрадор погибнет под дверью гаража, потому что утюг был с вирусом.
А тёщу атакует стиральная машинка.

У меня друг разбил Короллу именно по такой причине. К счастью все остались целы и невредимы, но никаких судов не было... Оказывается - напрасно.

это наглядный пример не имеет никакого отношения к IoT, с таким же успехом можно связать с IoT отсутствие регулировки правого подлокотника в Camry

Увы, но автор прав на 1000% и то, о чем идет речь в http://en.wikipedia.org/wiki/Internet_of_Things перекликается с поднятыми проблемами.
Одно дело, когда говнокод - это сломанный сайт, а другое дело, когда рекомый подлокотник в самый ненужный момент примет не то положение. Грубо говоря автор ведет речь о том, что все процессы взаимодействия с внешним миром подчинялись некому минимальному здравому смыслу (с точки зрения технологической и программной реализации) ...

А вот недавно с автомобилями Tesla было похожее.
Вот например
http://itc.ua/news/v-nhtsa-podana-zhaloba-na-neprednamerennoe-uskorenie-...
Наверно те же програмисты

японцы по определению не могут программировать. Знаю из личного опыта. Впрочем китайцы аналогично и по той же причине :)

Восприятие мира и склад ума не тот. Скорее всего сработала типичная японская фишка - каждый скрупулезно выполнял данные ему начальником инструкции, в итоге получилась такая странная конструкция. Я ни коим образом не защищаю Тойоту и в шоке от архитектуры и софта, но почему это не проявилось нигде в Японии? Хотя это самая распространенная марка там и при такой массе авто ни разу не было аналогичных случаев? Почему это проявилось только у американцев и больше нигде?

При всей своей нелюбви (это мягко говоря) к японцам не могу согласится с Вами - при нормальной организации процесса прекрасный код и продукты.
Проблемы лежит в другой плоскости - в обеспечении минимального уровня кач-ва в процессе разработки систем "человек-машина". Что касается проявлений самой проблемы - тут вариантом может быть много. начнем с того, что в США контроль кач-ва поставлен на высокий уровень. Второе - не для кого не секрет, что авто, поставляемые на рынок США отличаются от авто, поставляемых на рынок ЕС (чаще всего в лучшую сторону). В самой Японии ... знаете у них с головой все хорошо - даже если бы были некие подобные случае, то они бы решались в "рабочем" порядке, без лишних истерик и ненужного самобичевания.

Не знаю причин вашей нелюбви, у меня противоположные чувства :) Так сложилось, что я достаточно долго проработал на проектах для одной из крупнейших японских корпораций и знаю их изнутри довольно хорошо, будучи 身内 (Miuchi).
Так вот как раз насчет контроля качества - это уж, простите, явная глупость. И США и остальным с их контролем качества до японцев как до Марса. Нонешние беды японцев связаны как раз с их пресловутым ZD (Zero Defects) подходом. Этот принцип и выбил их из колеи, когда появились китайцы со своими товарами-однодневками, а общество переориентировалось с качественных и долговечных товаров на низкокачественный ширпотреб. Также, слепое следование инструкциям, что тоже часть японского менталитета, зачастую заводит их в технологические тупики, как, видимо получилось в данном случае. И в отношении софта, и в отношении архитектуры сопряжения.

Кто-то не решился нарушить 和 :)

Camry - не самая популярная в Японии машина, насколько я знаю.
очень долго самой популярной была Corolla, потом её сбила с пьедестала Honda Fit.
кроме того, комплектации машин для японского и американского рынков очень разные у всех автопроизводителей.

насчёт японцы не умеюь программировать...
не могу утверждать за всех японцев, но вот традиционно сколько я использовал написанных японцами программ - все были великолепны.

ну а что в Штатах используют весь прискорбный факт с firmware и в целях борьбы за свой авторынок - ну, мы же не дети, чтобы делать такое важное банальное "открытие". и так понятно.

Полностью согласен насчет "грязного использования в целях борьбы" :)

Но вот то, что Камри не показатель - не согласен. У них очень сильна унификация. И я сомневаюсь, что такие элементы, как управление заслонкой, разные для каждой модели Тойоты.

А вот насчет "великолепных программ", позволю себе не согласиться. Создателям иероглифов и комиксов весьма сложно дается абстрактное мышление. Напомню, так же, что в японском языке нет будущего времени. Что тоже в ту же копилку.

Замечательно работающие программы - это результат кошмарных оверхедов на тестирование для достижения ZD. Поэтому внутри эти программы ой как не замечательны и с трудом сопровождаемы. Что, впрочем, и вылезло во время экспертизы.

http://goo.gl/F5Qqt0

Вот вам пример

- иногда люди делают ошибки при написании firmware
- в "большом pdf-файле" на стр. 13, Toyota Corolla выглядит тихой отличницей по сравнению с не чуждой нам Camry, уже не говоря о том, что случаи неконтролируемого разгона фиксировались и до использования ETSC-i
- никто вообщем-то не заметил:
http://www.zr.ru/content/news/588540-avtomobili-yaponskix-marok-nadezhne...

Тут вкратце:

1. Вероятно глобальные переменные и негодные функции являются результатом работы автоматических генераторов программ;
2. Даже Кайзен можно довести до маразма;
3. Экономия посредством аутсорсинга вредит безопасности: вместо своих служащих нужно платить ДВУМ аутсорсинговым компаниям; одна делает оборудование с прошивкой, вторая выполняет аудит сделаного - конечно пытаются экономить на аудите;
4. В потребительской электронике (биосы, прошивки) творится тоже самое, и чем дешевле продукт тем больше ошибок.

80 тысяч нарушений правил -- совершенно ниочем, если нет конкретики. Может, у них 80К строк кода, и в каждой отступ пробелами вместо табов. С глобальными переменными тоже не особо, вроде тот же atmel дает хедеры, в которых обьявлена переменная для каждого управляющего регистра, всего пара сотен запросто наберется.

Вот неумение организовать работу с вотчдогом -- да, типичная проблема.

Skynet уничтожит человечество тоже из-за ошибки программиста :)

Похоже Toyota решает эти проблемы...

http://www.adacore.com/press/toyota-itc-japan-selects-spark-pro-language...

Спасибо. Живо вспоминались http://lib.ru/MEMUARY/ERSHOW_W/zapiski_ezdowogo_psa.txt

--
Миша Шигорин

Афтар передёргивает.

Вывод NASA - ПО скорее всего не является причиной аварий. А не "...идентифицировала два гипотетических сбоя...".

За 500$ в час в течении года, Barr и сотоварищи как ни пытались (с имитацией случайного изменения памяти), не смогли повторить проблему, привёдшую к гибели пенсионерки.

Оно и понятно, в убогом коде тойоты было несколько механизмов
защиты от сбоев.

"Анализ цикломатической сложности программы" и прочее лишь указывают на потенциальные проблемные места. Судить об возможности "сопровождения программы" можно только по коду.

А в целом, ПО тойоты представляет из себя типичное ПО, всё через жопу, как везде, ничего такого особого. На другой модели тойоты, вон, код получше, со слов Barr.

Да ладно вам, глючный софт. Вспомните историю ремня безопасности. Жертвы, суды, время, и законодательством закрепят требования к прошивкам. А может будет как у Теслы, все данные о функционировании кидаются на серверы, до разбирательства.

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT