УНИВЕРСИТЕТ ИТМО | ||||
Главная / Беллетристика / Шалыто А.А. Тяжелый коврик и автоматное программирование
(версия для печати)
Шалыто А.А. Тяжелый коврик и автоматное программированиеЯ в разных аудиториях рассказывал, что понимаю под автоматным программированием и его парадигмой. При этом, несмотря на то, что я говорю весьма громко, всегда находится те, кто меня не слышит :). Обычно я говорю, что автоматный подход применим для надежного построения управляющих программ, например, таких, что используются во встроенных системах – в лифте, принтере, фотоаппарате, турникете и т.п. При этом также говорю, что в книге (Ослэндер Д., Риджли Д., Ринггенберг Д. Управляющие программы для механических систем. Объектно-ориентированное проектирование систем реального времени. М.: БИНОМ. Лаборатория знаний. 2004) отмечается, что 99% всех микроконтроллеров и микропроцессоров мира используется в системах этого класса. Подтверждение важности этого класса программ я получил недавно в представительстве корпорации IBM в Цюрихе, когда первое, что они с гордостью показали, были не сложные компьютеры или наносистемы, которыми они занимаются, а кредитные карты с чипом, так как они выпускаются огромными тиражами. Тут и до Java-card и автоматного программирования недалеко. Я обычно рассказываю, что цель моей деятельности состоит в том, чтобы, например, в автомобиле все надежно открывалось и закрывалось, и он корректно разгонялся и тормозил. Чтобы не происходило того, что произошло несколько лет назад в центре Парижа, когда посол Филиппин в Юнеско из ошибок в программном обеспечении чуть было, не задохнулся в новом бронированном автомобиле. Недавно, рассказав эту историю, я вдруг услышал, что для управления автомобилем автоматный подход, может быть, и подходит, а вот для вычислительной геометрии не подходит совсем! На это приходится отвечать, что это, возможно, и так, но …, и дальше все заново, как в сказке про белого бычка. А еще слушатели любят, например, спрашивать, как применять автоматный подход в параллельных асинхронных системах, содержащих 10 со многими нулями состояний. Когда при этом я в ответ уточняю, что они понимают под «состоянием», народ «обычно безмолвствует». После этого я обычно говорю, что цель предлагаемого подхода состоит в создании надежных (за счет кодогенерации и повышения уровня автоматизации верификации на основе метода Model Checking) программ, содержащих от единиц до сотен управляющих состояний, то в ответ часто слышу, что это слишком просто и неинтересно. Это особенно любят говорить программисты, которые никогда не разрабатывали ответственных систем и которые по образованию обычно являются математиками, многих из которых хоть «хлебом не корми», но дай порассуждать о сложных задачах. А то, что люди часто погибают из-за «простых» ошибок в системах, их мало интересует. В подтверждение, расскажу историю про тяжелый коврик! «29.09.2009 г. Американское национальное управление по безопасности дорожного движения обратилось к 3,8 млн. владельцев автомобилей Toyota и Lexus последних моделей с призывом немедленно избавиться от резинового коврика на полу со стороны водителя, который может способствовать залипанию педали газа и неконтролируемому ускорению автомобиля. Вскоре в Интернете появился ролик с записью телефонного звонка в службу 911. Звонивший сообщил, что у него отказали тормоза, и он не может остановить разогнавшийся до 190 км/ч Lexus. В результате погиб звонивший и три его пассажира. По итогам расследования катастрофы ее причиной был назван резиновый коврик! В ноябре 2009 г. корпорация отозвала еще миллионы автомобилей, так как помимо ковриков решила внести изменения в механизм педали газа и конструкцию пола, а также установить систему приоритета тормоза над газом. В январе 2010 стало известно, что с 1999 г. было зафиксировано 2274 случая внезапных ускорений автомобилей Toyota, которые привели к 75 авариям и 18 смертельным исходам. Тем временем сервисная кампания вышла за пределы Америки, и, в частности, было предложено отозвать 1,7 млн. автомобилей в Европе. Общее число затронутых отзывами автомобилей превысило 8.5 млн. штук, что соответствует годовому объему производства корпорации докризисной поры» (Газета «Ведомости». 22.03.2010. http://www.vedomosti.ru/newspaper/article/2010/03/22/228673) Выслушав историю о том, как «простые» ошибки могут приводить к огромным затратам и катастрофам с человеческими жертвами, всегда находится слушатель, который, как глухой, продолжает бубнить: «А для решения такого-то класса задач автоматных подход неэффективен». – Ну, что делать! – обычно отвечаю я. На этом дискуссия обычно завершается, а недовольные автоматным программированием остаются, не понимая, что, пропустив даже одно состояние, последствия могут быть хуже, чем от коврика. И на самом деле, в автомобильной промышленности пошли проблемы не только ковриками, но, и с системами управления, что связано с резким повышением уровня автоматизации автомобилей. Вот что пишет по этому поводу газета «Известия» от 20.05.2010 г.: «Корпорация Toyota отозвала 11,5 тыс. дорогих седанов Lexus по вине системы управления, которая призвана контролировать угол поворота руля при прохождении поворота. Иногда система не до конца «выходит из поворота» – даже при выправленном руле автомобиль продолжает поворачивать, что чревато авариями. После этого Toyota отозвала еще 34 тыс. внедорожников из-за неправильной работы системы курсовой устойчивости, приводящей к заносу автомобиля». Я, естественно, не знаю в чем там проблема, но не исключаю, что эти системы не так программировались. Каждый раз, когда начинается «бодяга» с обсуждением применимости автоматного программирования, так и хочется спросить: «А вы когда-нибудь программировали ответственные системы?» Многие умники сегодня слышали, что в реактивные системах следует использовать автоматы, и поэтому считают, что применение автоматного подхода естественно в системах этого класса, а я знаю многотысячные предприятия, в которых такой подход используют только те специалисты, которых я убедил в этом, а остальные продолжают программировать «как учили». У последних, как говорится, все хорошо, но только им, почему-то, очень не нравится, когда их спрашивают: «А как все-таки верифицировать ваши программы?» | ||||
|