Для получения триального ключа
заполните форму ниже
Team License (базовая версия)
Enterprise License (расширенная версия)
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
GBP
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
Качество встраиваемого ПО или погром вс…

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

29 Окт 2013

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

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

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

Итак, лет шесть назад две пожилые женщины в штате Оклахома поехали куда-то на своей 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):

a0083_Embedded_Quality_ru/image1.png

Контроллер дроссельной заслонки, по идее, не самое страшное, что можно придумать. По идее. Он считывает положение педали (или принимает его от другого контроллера по какой-то бортовой сети вроде 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) надо бы не забывать. Надеюсь, что индустрия его не проигнорирует. Уже не получится. Потому что шум поднялся на весь мир.

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

Популярные статьи по теме
Зло живёт в функциях сравнения

Дата: 19 Май 2017

Автор: Андрей Карпов

Возможно, читатели помнят мою статью под названием "Эффект последней строки". В ней идёт речь о замеченной мной закономерности: ошибка чаще всего допускается в последней строке однотипных блоков текс…
PVS-Studio для Java

Дата: 17 Янв 2019

Автор: Андрей Карпов

В седьмой версии статического анализатора PVS-Studio мы добавили поддержку языка Java. Пришло время немного рассказать, как мы начинали делать поддержку языка Java, что у нас получилось и какие дальн…
Статический анализ как часть процесса разработки Unreal Engine

Дата: 27 Июн 2017

Автор: Андрей Карпов

Проект Unreal Engine развивается - добавляется новый код и изменятся уже написанный. Неизбежное следствие развития проекта - появление в коде новых ошибок, которые желательно выявлять как можно раньш…
PVS-Studio ROI

Дата: 30 Янв 2019

Автор: Андрей Карпов

Время от времени нам задают вопрос, какую пользу в денежном эквиваленте получит компания от использования анализатора PVS-Studio. Мы решили оформить ответ в виде статьи и привести таблицы, которые по…
Как и почему статические анализаторы борются с ложными срабатываниями

Дата: 20 Мар 2017

Автор: Андрей Карпов

В своей предыдущей статье я писал, что мне не нравится подход, при котором статические анализаторы кода оцениваются с помощью синтетических тестов. В статье приводился пример, воспринимаемый анализат…
Технологии, используемые в анализаторе кода PVS-Studio для поиска ошибок и потенциальных уязвимостей

Дата: 21 Ноя 2018

Автор: Андрей Карпов

Краткое описание технологий, используемых в инструменте PVS-Studio, которые позволяют эффективно обнаруживать большое количество паттернов ошибок и потенциальных уязвимостей. Статья описывает реализа…
Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний

Дата: 31 Июл 2017

Автор: Андрей Карпов

После большой статьи про проверку операционной системы Tizen мне было задано много вопросов о проценте ложных срабатываний и о плотности ошибок (сколько ошибок PVS-Studio выявляет на 1000 строк кода)…
Эффект последней строки

Дата: 31 Май 2014

Автор: Андрей Карпов

Я изучил множество ошибок, возникающих в результате копирования кода. И утверждаю, что чаще всего ошибки допускают в последнем фрагменте однотипного кода. Ранее я не встречал в книгах описания этого …
Любите статический анализ кода!

Дата: 16 Окт 2017

Автор: Андрей Карпов

Я в шоке от возможностей статического анализа кода, хотя сам участвую в разработке инструмента PVS-Studio. На днях я был искренне удивлён тому, что анализатор оказался умнее и внимательнее меня.
Бесплатный PVS-Studio для тех, кто развивает открытые проекты

Дата: 22 Дек 2018

Автор: Андрей Карпов

В канун празднования нового 2019 года команда PVS-Studio решила сделать приятный подарок всем контрибьюторам open-source проектов, хостящихся на GitHub, GitLab или Bitbucket. Им предоставляется возмо…

Комментарии (0)

Следующие комментарии

На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Этот сайт использует куки и другие технологии, чтобы предоставить вам более персонализированный опыт. Продолжая просмотр страниц нашего веб-сайта, вы принимаете условия использования этих файлов. Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте данный сайт. Подробнее →
Принять