Вы находитесь на странице: 1из 66

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ

ФЕДЕРАЦИИ
САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ, МЕХАНИКИ И ОПТИКИ

Факультет___Информационных технологий и программирования________________


Направление Прикладная математика и информатика_____
Специализация Математические модели и алгоритмы в разработке программного
обеспечения
Академическая степень ___бакалавр прикладной математики и информатики___

Кафедра__Компьютерных технологий_________Группа_____4538_________________

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
К ВЫПУСКНОЙ КВАЛИФИКАЦИОННОЙ РАБОТЕ

Применение автоматного подхода для разработки программного


обеспечения автомобилей

Автор квалификационной работы _________Фирун К.Б.__________________(подпись)


( Фамилия, И., О. )

Научный руководитель______________Шалыто А.А.____________________(подпись)


( Фамилия, И., О. )

Консультанты:

а) По экономике и орга-
низации производства ______________________________________________(подпись)
( Фамилия, И., О. )

б) По безопасности жизне-
деятельности и экологии __________________________________________ (подпись)
( Фамилия, И., О. )

К защите допустить
Зав. кафедрой ____ВАСИЛЬЕВ В.Н. ___________________________(подпись)
( Фамилия, И., О. )
 
 
“____”____________________20 ____г.
 
Санкт-Петербург, 2009 г.
2
 

Квалификационная работа выполнена с оценкой _______________________________

Дата защиты “____”________________________20____г.

Секретарь ГАК ____________________________________

Листов хранения ___________________________________

Чертежей хранения _________________________________

 
 
 
 
3
 
ОГЛАВЛЕНИЕ 

ВВЕДЕНИE …………………………………………………………………….. 5
ГЛАВА 1. ИССЛЕДОВАНИЕ ЗАДАЧИ ........................................................... 7

1.1. Цели работы ..................................................................................................... 7

1.2. Обзор методик разработки программного обеспечения автомобилей ...... 7

1.2.1. История разработки и использования программного обеспечения в


автомобилях ......................................................................................................... 9

1.2.2. Электронные системы в автомобилях сегодня .................................... 10

1.2.3. Современные требования к электронным системам ........................... 12

1.2.4. Современные направления разработки программно-аппаратных


систем ................................................................................................................. 15

1.2.5. Процесс разработки программного обеспечения автомобилей ......... 18

1.2.6. Недостатки современного процесса разработки программного


обеспечения автомобилей ................................................................................ 19

1.2.7. Экономические основания проблем разработки программного


обеспечения автомобилей ................................................................................ 22

1.2.8. Области исследований разработки программного обеспечения


автомобилей ....................................................................................................... 23

ГЛАВА 2. ПРЕДСТАВЛЕНИЕ АВТОМОБИЛЬНЫХ СИСТЕМ ПРИ


ПОМОЩИ АВТОМАТНОГО ПОДХОДА ..................................................... 30

2.1. Постановка задачи ........................................................................................ 30

2.2. Описание работы составляющих модели автомобиля ........................... 31

2.2.1. Двигатель ................................................................................................. 31

2.2.2. Коробка передач ...................................................................................... 31

2.2.3. Ходовая часть (колеса) ........................................................................... 32

2.3.Система управления автомобилем ................................................................ 33


4
 
2.4. Диаграмма классов и события ...................................................................... 33

2.4.1. Диаграмма классов.................................................................................. 33

2.4.2. Взаимодействие автоматов .................................................................... 34

2.5. Класс «Двигатель» (car.Engine) .................................................................... 35

2.5.1. Входные переменные (x) ........................................................................ 35

2.5.2. Выходные воздействия (z) ..................................................................... 35

2.5.3. Схема связей автомата “Управление двигателем” (A1) ..................... 35

2.5.4. Граф переходов автомата “Управление двигателем” ......................... 36

2.6. Класс «Коробка передач» (car.Gears) ......................................................... 36

2.6.1. Входные переменные (x) ........................................................................ 36

2.6.2. Схема связей автомата “Управление коробкой передач” (A2) .......... 37

2.6.3. Граф переходов автомата “Управление коробкой передач” .............. 37

2.7. Класс «Колеса» (car.Wheels) ........................................................................ 37

2.7.1. Входные переменные (x) ........................................................................ 38

2.7.2. Выходные воздействия (z) ..................................................................... 38

2.7.3. Схема связей автомата “Управление вращением колес” (A3) ........... 39

2.7.4. Граф переходов автомата “Управление вращением колес” ............... 39

2.7.5. Схема связей автомата “Управление поворотом колес” (A4) ............ 40

2.7.6. Граф переходов автомата “Управление поворотом колес” ................ 40

2.8. Визуализация управления автомобилем..................................................... 41

2.9. Программный код ......................................................................................... 43

2.10. Пример протокола моделирования управления автомобилем ................ 59

ЗАКЛЮЧЕНИЕ ................................................................................................... 64
 
5
 
ВВЕДЕНИЕ
В настоящее время разработка программного обеспечения для применения
в продукции автомобильной промышленности стала ведущим направлением
при решении проблем, связанных с обеспечением безопасности автомобильных
пользователей, а также для создания им должного комфорта. Девяносто
процентов всех инноваций в области создания автомобильных систем прямо
или косвенно связаны со встраиваемым программным обеспечением.
Например, в последние годы число серьезных автомобильных аварий в Европе
уменьшилось, несмотря на увеличение автомобильного парка. Во многом это
является заслугой недавних нововведений в обеспечении безопасности,
основанных на программно-аппаратных решениях, помогающих водителю
автомобиля избежать аварийных ситуаций. Одной из таких программно-
аппаратных систем является электронная система стабилизации автомобиля,
которую можно найти в любом новом автомобиле, продающемся в Европе.

Рис.1. Вклад электронных систем в конечную стоимость автомобиля на


примере Mercedes-Benz W220

Программное обеспечение имеет большое влияние на формирование


конечной стоимости автомобиля. При этом к 2010 году примерная стоимость
разработки программного обеспечения составит около 40 и более процентов от
цены автомобиля (см. рис.1). В то же время, специалисты компании Daimler
AG, выпускающей автомобили под марки Mercedes-Benz, считают, что в
6
 
автомобилях, которые будут выпускаться в ближайшие 5–7 лет, до 80%
функций будут основаны на электронной составляющей, причем 90% функций
этих электронных систем будут возможны при применении соответствующего
программного обеспечения. Следовательно, автопроизводителям необходимо
сосредоточить свое внимание на создании программного обеспечения, без
которого невозможны последующие нововведения и улучшения автомобилей.
Из-за важности программного обеспечения в системах автомобиля и
сложности тех функций, которые реализуются программно, возникает ряд
проблем, как при разработке, так и при исполнении программного кода.
Центральной задачей при разработке электронных систем автомобиля является
управление различными несвязанными подсистемами, выполняющими
множество функциональных задач. В качестве примера, рассмотрим систему
центрального замка, чья функциональность в некоторых автомобилях премиум-
класса распределена между 19 различными подсистемами. В функции системы
центрального замка входит запоминание настроек сидений, радио,
климатической установки и, конечно, закрытие замков и активация
сигнализации при входе и выходе водителя.
В данной работе предлагается использовать автоматный подход для
решения описанных выше проблем качества и безошибочности программного
обеспечения.
7
 
ГЛАВА 1. ИССЛЕДОВАНИЕ ЗАДАЧИ

1.1. Цели работы


Цель настоящей работы – показать удобство и перспективность
автоматного подхода программирования при разработке программного
обеспечения автомобилей. Для этого требуется выполнить анализ и провести
сравнение существующих подходов разработки программного обеспечения
автомобилей, выделить их сильные и слабые стороны. По результатам анализа
существующих методик будут сформулированы требования, предъявляемые к
разработке программного обеспечения автомобилей, и способы их достижения
при использовании указанного подхода.

1.2. Обзор методик разработки программного обеспечения


автомобилей
Объем программного обеспечения в автомобилях в последние годы растет
экспоненциально. Это связано с падением цен на электронные комплектующие,
а также с требованиями применения инновационных подходов из-за
появляющихся новых функциональных требований, предъявляемых
потребителями и контролирующими качество продукции автопроизводителей
государственными органами. Быстрый рост использования программного
обеспечения и основанных на нем функциональных решений преподносит
автомобильной индустрии разнообразные задачи, начиная от организации
труда и заканчивая стратегическими разработками. С точки зрения разработки
программного обеспечения и прикладной математики, автомобильная
промышленность – идеальное место для применения новых технологических
методик и приемов. Несмотря на то, что автомобильная промышленность
использует основные результаты и решения из других областей науки и
техники, из-за особенных требований при разработке автомобилей, требуются
индивидуальные для этой области решения, которые создают многие проблемы
для разработчиков программного обеспечения. Другими словами, в
8
 
автомобилях можно обнаружить множество задач, интересных для
разработчиков программного обеспечения и ученых прикладной математики.
В недавнем прошлом программное обеспечение стало одним из главнейших
факторов в развитии автомобилестроения, привнеся различные задачи, решение
которых стало основным моментом в конкурентном споре автопроизводителей.
Если провести анализ использования программного обеспечения в
автомобилях в прошедшие годы, то можно сделать вывод о том, что за
последние 35 лет роль программного обеспечения в этой области стала
доминирующей. При продолжающемся росте использования программного
обеспечения ожидается, что в ближайшие 20 лет значимость задачи разработки
надежных и отказоустойчивых электронных систем будет повышаться.
Впервые программное обеспечение в автомобилях появилось около 35 лет
назад, и с тех пор сменилось четыре поколения систем различной сложности.
От поколения к поколению объем программного обеспечения рос в системах
автомобиля на порядок. На сегодняшний день в автомобилях премиум-класса
(Mercedes-Benz S-Class, BMW 7-Series, Lexus LS460) насчитывается более 70
контроллеров, шесть шин обмена данными, а число строк кода превышает 12
миллионов (см. рис.2) [2]. В следующем поколении этих моделей автомобилей
также ожидается рост числа строк кода на порядок.

 
Рис.2. Современный автомобиль премиум-класса на
примере Mercedes-Benz W220
9
 

Многие новые функции в автомобилях управляются программным


обеспечением (например, экономичное регулирование использования топлива и
использование нескольких источников энергии для движения автомобиля – то
есть, гибридных технологий, включающих в себя двигатели внутреннего
сгорания и электрические двигатели). Решение всех этих задач напрямую
зависит от программного обеспечения и его грамотного использования.
Ниже будет описана история развития программного обеспечения в
автомобильной промышленности, так как это необходимо для точного
понимания современных задач в этой области. Кратко описав историю, будут
даны прогнозы будущего развития программного обеспечения в автомобильной
области. На этом шаге будет описано применение автоматного подхода
программирования для разработки программного обеспечения автомобилей.

1.2.1. История разработки и использования программного


обеспечения в автомобилях
 
35 лет назад программное обеспечение было впервые использовано в
автомобиле для управления двигателем, в частности, зажиганием. Первые
программные решения были локальны, изолированы друг от друга и
ненадежны. Программно-аппаратные системы в автомобилестроении
развивались от простого к сложному. Это развитие послужило основой
применения в автомобилях узкоспециализированных контроллеров
(электронное управляющее устройство или ECU – Electronic Control Unit) для
различных задач, впрочем, как и сенсоров, и разнообразных приводов. Со
временем, ставшая громоздкой система связей была заменена на систему шин
обмена данных, которые позволили соединить контроллеры и сенсоры с
большей скоростью и удобством расположения в автомобиле. При появлении
подобной структуры, контроллеры также объединились в единую сеть и смогли
обмениваться информацией. В результате в автомобильной промышленности
электронные системы стали распределенными и соединенными множеством
10
 

 
Рис.3. Схема электронных систем современного автомобиля

шин обмена данных (см. рис.3). Систематизированное конструирование сверху


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

1.2.2. Электронные системы в автомобилях сегодня


На сегодняшний день в автомобилях премиум-класса насчитывается не
менее 70 контроллеров соединенных более чем пятью разными системами шин
обмена данных [ГРИММ]. Около 50% стоимости производства автомобиля
приходятся на электронику и программное обеспечение [].
За последние 35 лет в автомобилях число строк кода выросло до 12
миллионов. Более 2000 различных функций в автомобилях премиум-класса
реализовано или управляется программным обеспечением [ГРИММ]. От 50%
11
 
до 70% стоимости разработки программно-аппаратных систем – стоимость
разработки программного обеспечения.
Программное обеспечение, как и аппаратные системы, позволяет
реализовать инновационные технологии в автомобилях. При этом аппаратные
системы становятся для автопроизводителя все более доступными из-за
падения цен на контроллеры и прочие электронные компоненты, а программное
обеспечение определяет функциональность этих аппаратных систем и тем
самым становится основным фактором при реализации тех или иных
нововведений.
Как отмечено выше, программное обеспечение является основой инноваций
в технологических системах. При помощи программного обеспечения
реализуется новые функции, находятся пути оптимизации известных
технических решений, экономится топливо, улучшается качество, и важнее
всего – происходит объединение всех этих решений в многофункциональные
системы. Таким образом, программное обеспечение позволяет находить
абсолютно новые решения для известных задач.
Несмотря на все преимущества, которые позволяет получить программное
обеспечение, в настоящее время разработка программного обеспечения для
автомобилей до сих пор находится на начальной стадии своего становления.
Быстрое увеличение объема использования программного обеспечения и
традиционный подход к разработке автомобилей создают сложности для этой
области экономики при адаптации к новым требованиям.
Следуя традиции создания своих собственных решений существующих
задач, автомобильная промышленность создала большое число несовместимых
между собой программных и аппаратных решений. Подобную ситуацию можно
было бы избежать, используя наработки и опыт из других областей
промышленности и науки, таких как телекоммуникация и авионика.
Управление жизненным циклом программного обеспечения также
находится на ранней стадии своего развития. Многие поставщики и даже
производители комплексного оборудования (OEM-производители) находятся
12
 
ниже второго уровня модели технологической зрелости организации (CMM –
Capability Maturity Model [for Software]). В общем и целом, это большая
проблема для распределенной параллельной разработки, в итоге которой
создается сложное, многофункциональное, распределенное, работающее в
режиме реального времени программное обеспечение.
Повторное использование решений для одной модели автомобиля в другой
является недостаточным и используется лишь в некоторых узких областях. Во
многих областях функциональность одного поколения автомобилей
переносится в следующее поколение лишь на 10%, в то время как 90%
программного обеспечения переписывается с нуля [2]. Причиной этому служит
низкоуровневая реализация программного обеспечения, привязанность к
определенному оборудованию – все это усложняет и часто делает
невозможным переносимость существующего кода.
Кроме того отметим, что степень автоматизации при создании
программного обеспечения на сегодняшнем уровне крайне низка.

1.2.3. Современные требования к электронным системам

Традиционно, автомобильная промышленность очень вертикально


организованна. Инженеры механических систем работали на протяжении 100
лет над различными подсистемами в автомобилях и сделали возможным
разработку и производство этих систем довольно независимым друг от друга.
Это облегчает разработку и производство автомобильных компонентов и
позволяет достичь разделения труда за счет использования поставщиков
первого уровня.
В результате поставщики могут взять на себя значительную часть
разработки и конструирования, а также производства некоторых компонентов.
В идеале, автомобильные компоненты производятся поставщиками и
собираются в единое целое лишь на сборочных производствах
автопроизводителя (таким образом, автопроизводитель становится
13
 
производителем комплексного оборудования). При этом огромная часть
разработки и производства отдается на сторону, а затраты и риски могут быть
оптимизированы.
С появлением программного обеспечения, которое становится главной
движущей силой инноваций в области автомобилестроения, ситуация в корне
изменилась.
 Традиционно довольно несвязанные и независимые между собой
функции (такие как, тормозная система, рулевое управление, управление
двигателем), выполнение которых, управлялось водителем, становятся все
сложнее и начинают взаимодействовать между собой. Автомобиль превратился
из цельного механического устройства в распределенную электронную
систему.
 Сборка автомобильных компонентов становится частью системной
интеграции.
 Поведение автомобилей становится все более программируемым и более
не зависит лишь от механики, но зависит в большей степени от настроек
программного обеспечения.
 Стоимость автомобилей становится все более зависимой от стоимости
разработки программного обеспечения, для которой не действуют
традиционные модели оценки затрат, используемые в производстве
автокомпонентов.
Размер и значимость программно-аппаратных средств в автомобилях имеют
огромное значение. Большая часть программного обеспечения работает на базе
операционных систем реального времени, а также высокоскоростных шин
обмена данных систем автомобиля. Кроме того, большая часть программного
обеспечения требует систем жесткого реального времени, или, по крайней
мере, систем мягкого реального времени.
Вместе с тем, требования к программным системам в автомобилях довольно
специфичны.
14
 
 Большое число различных пользователей (от водителей и пассажиров до
работников сервисных служб автопроизводителя).
 Возможность поддержания работоспособности в сложных ситуациях.
 Большая требовательность к безопасности.
 Гетерогенность функциональных решений (от систем развлечения до
систем обеспечения безопасности).
В результате, сложность и диапазон требований к программному
обеспечению автомобилей крайне велики.
Оценивая вышеперечисленные требования и уже существующее
использование программного обеспечения в автомобилях, можно с
уверенностью спрогнозировать увеличение использования данных технологий
в автоиндустрии. Существенный рост приложения программного обеспечения
ожидается в основном по следующим причинам:
 Большой спрос на инновационные технологии и улучшенную
функциональность.
 Быстро изменяющиеся платформы разработки автомобилей и системной
инфраструктуры.
 Требования лучшей надежности и качества.
 Более быстрый вывод решений на рынок.
 Увеличение возможности индивидуализации автомобилей для
пользователей.
В результате, уже сейчас есть большой и продолжающий расти спрос на
исследования, посвященные программному обеспечению в автомобильной
промышленности. Уже сегодня наблюдается быстрый рост стоимости
разработки программного обеспечения, даже, несмотря на сильное урезание
средств на разработку новых моделей автомобилей.
В связи с быстрым ростом числа случаев приложения программного
обеспечения в автомобилях возникают, вопросы связанные с его разработкой,
внедрением и поддержкой, которые ощутимо ударяют по автомобильной
15
 
промышленности – так за прошедшие 35 лет количество разработок связанных
с программным обеспечением выросло с 0 до 40-45%. Если предположить, что
в автомобильной области инженер работает на протяжении 35-40 лет, то
становится очевидно, что автомобильные производители не могли обладать
требуемой компетентностью в области программного обеспечения в нужное
время. Другой проблемой является нехватка специалистов, подготавливаемых
университетами. Этим специалистам не хватает знаний и умений требуемых
при создании встроенных систем, и особенно в области автомобильной
промышленности.

1.2.4. Современные направления разработки программно-


аппаратных систем
Основные направления, в которых будет развиваться разработка
программного обеспечения в автомобильной отрасли в ближайшие 20 лет – это
пассивная и активная безопасность, улучшенное управление работой
двигателя и навесного оборудования, улучшенная помощь водителю при
вождении, адаптивный интерфейс управления функциями автомобиля
пользователями, «программируемый» автомобиль, персонализация и
индивидуализация автомобильных систем под запросы пользователей, сетевые
соединения внутри и снаружи автомобилей. Кроме того, перед автомобильной
индустрией стоит задача уменьшения затрат на разработку программно-
аппаратных систем, в первую очередь не из-за урезания средств на разработку,
а на оптимизацию средств, затрачиваемых на поддержку и гарантийного
обслуживания программно-аппаратных систем в автомобилях.
Далее дано подробное описание вышеназванных направлений:
 Пассивная и активная безопасность
Уже сейчас стандарты безопасности в автомобилях довольно высоки.
Так в прошедшие годы количество погибших или получивших
ранения людей в автомобильных катастрофах уменьшилось, несмотря
на значительное увеличение автопарка. По статистике программное
16
 
обеспечение в автомобилях помогло значительно уменьшить
количество жертв в этих авариях. Однако, несмотря на уже
имеющиеся успехи, системы безопасности далеки от совершенства и в
ближайшие годы нас ждет прорыв в технологиях, обеспечивающих
безопасность движения.
 Улучшенное управление работой двигателя и навесного
оборудования
Гибридные автомобили появились лишь примерно 10 лет назад, но в
будущем ожидается рост количества подобных моделей. Для
успешной разработки подобных автомобилей требуется улучшение
технологий по управлению энергопотреблением, настроек автомобиля
и его систем.
 Улучшенная помощь водителю при вождении
Сложность программного обеспечения в автомобилях слишком
велика не только для водителей, пассажиров, но и для сервисного
обслуживания. В этом вопросе могут помочь разнообразные системы
на всех уровнях взаимодействия с автомобилем, которые мгновенно
реагируют и помогают водителям, к примеру, система распознавания
непреднамеренного перестроения из полос движения или система
автоматической парковки, которые уже встречаются на серийных
автомобилях, во многом помогают неопытным пользователям.
 Адаптивный интерфейс управления функций автомобиля
пользователями
Интерфейс между пользователем и автомобилем – очень важная цель
в разработке программного обеспечения, так как сложность
автомобилей, во многом из-за программного обеспечения, влияет на
безопасность дорожного движения. В последние годы интерфейсы
управления сильно продвинулись вперед, но все еще далеки от
совершенства.
 «Программируемый» автомобиль
17
 
Автомобили премиум-класса, оснащенные огромным количеством
сенсоров и приводов, уже сегодня позволяют вводить новые
функциональные возможности, используя лишь программное
обеспечение. Автоиндустрия уже в ближайшие годы достигнет уровня
необходимого для разработки и производства полностью
«программируемых» автомобилей.
 Персонализация и индивидуализация автомобильных систем под
запросы пользователей
Довольно интересной задачей является персонализация и
индивидуализация автомобилей, так как существуют разные типы
водителей, требующие разного к себе подхода. При тенденции
усложнения управления автомобилем для пользователя, важным
является адаптация автомобилей к индивидуальным водительским
привычкам.
 Сетевые соединения внутри и снаружи автомобилей
Другой не менее важной задачей является обеспечение сетевых
соединений между системами автомобиля, а также между
автомобилем и внешними системами. Используя беспроводные
технологии, возможно соединять автомобили, что может повысить
безопасность, уменьшить вероятность возникновения пробок.
Например, в долгосрочной перспективе можно представить, что все
дорожные знаки смогут обмениваться электронными сигналами с
автомобилями, тогда можно ожидать совершенно другого уровня
координации дорожного движения.
Использование программного обеспечения в автомобилях на нынешнем
уровне ставит автомобильную индустрию в сложное положение. В будущем
ситуация может измениться в куда худшую сторону из-за описанных выше
требований к программному обеспечению в автомобилях следующего
поколения.
18
 
Программное обеспечение серьезно изменило подход к разработке и
созданию автомобилей. На протяжении почти ста лет инженеры
автомобилестроители создавали системы, которые можно было использовать
независимо друг от друга – как в модульной системе. Теперь же из-за
огромного количества программного обеспечения и его крайней сложности,
автомобиль приходится понимать как изощренную распределенную систему,
где все составляющие функции связаны между собой.  

1.2.5. Процесс разработки программного обеспечения


автомобилей
Для лучшего понимания проблем связанных с программным обеспечением
в автомобилях, необходимо хорошо знать процесс разработки этих
электронных систем. Так из-за роста числа применений программного
обеспечения в автомобилях, индустрии требуется новый и улучшенный подход
к разработке программного обеспечения. Вместе с тем, автоиндустрии
требуется новый подход к разработке самой продукции из-за растущей
важности программного обеспечения в работоспособности автомобилей.
Во многом из-за особенностей разработки программного обеспечения,
разработка и производство автомобилей в корне изменились. Таким образом,
автопроизводители создали тенденцию по передаче разработки многих систем
сторонним поставщикам. В индустрии разработки программного обеспечения
данная ситуация называется термином «аутсорсинг». При этом
автопроизводители должны понимать и уметь модифицировать продукты
сторонних компаний для лучшей интеграции в свою продукцию. Вместе с тем,
в разработке программного обеспечения в автоиндустрии практически не
используется теория управления. На сегодняшний день большая часть
программного обеспечения в автомобиле создана без проработанной
математической модели, а базируется лишь на событийно-ориентированном
подходе программирования.
19
 
Подытоживая выше написанное, можно сделать вывод, что разработка
программного обеспечения для автомобилей несет за собой большие риски, но
еще и большие возможности для улучшения технологий и достижения цели
экономического благополучия в условиях современной экономики.
Для достижения цели снижения расходов на разработку, и вместе с тем
повышения качества программного обеспечения, требуются изменения в
архитектуре разработки программных средств. Во-первых, во многих
современных автомобилях мы можем найти до 2000 и более функций,
отвечающих как за осуществления движения (работа двигателя, коробки
передач, подвески) так и отвечающие за комфорт и развлечение пассажиров
автомобиля [2]. Главной и самой значимой проблемой в этом множестве
функций является их тесное переплетение и взаимосвязь. Решение этой задачи
является крайне важным, так как в большой распределенной системе
вычислений, которую представляет автомобиль, возможны случаи, когда одно
электронно-управляющее устройство может считать, основываясь на показания
подключенных датчиков, что автомобиль стоит на месте, в то время как другое
электронно-управляющее устройство, подключенное в другую
вычислительную сеть, может считать, что автомобиль движется. На данный
момент, является необходимым разработка грамотного подхода к построению
архитектуры электронных систем автомобиля, в которой будет взаимосвязь
всех функций, датчиков и устройств в понятной и удобной для использования
форме. В данной работе дается решение описанной проблемы.

1.2.6. Недостатки современного процесса разработки


программного обеспечения автомобилей
Очевидно, что с ростом количества электронных технологий, применяемых
при создании автомобилей, разработка программного обеспечения становится
все более сложной задачей. Требования, предъявляемые к разработке
программного обеспечения автомобилей, должны освещать следующие
вопросы: упрощение процесса разработки программного обеспечения, простая
20
 
интеграция инновационных технологий, экономия денежных средств,
затрачиваемых на разработку. Кроме того, важна большая интеграция
«аутсорсинга» в разработку программного обеспечения автомобилей.
Одним из решений поставленных задач, является более полный анализ
требований программного обеспечения, чем тот что происходит в
автоиндустрии сейчас. В области промышленности с большим числом
инновационных функций, актуально грамотное описание требований к
разработке программного обеспечения, которое будет понятно и легко
усваиваемо не только разработчиками программного обеспечения, но и
сторонним разработчикам систем, напрямую не связанных с разработкой
программного обеспечения. С ростом количества информации, возникающим
при разработке программного обеспечения автомобилей, становится
необходимым грамотное описание математических моделей, показывающих
обмен информацией между различными системами автомобиля.
Стоит упомянуть и о необходимости более глубокого подхода к
конструированию и проработке аппаратных систем автомобиля. Вопросы
переносимости кода и его повторного использования напрямую зависят от
аппаратных платформ и их совместимости. На данный момент, как
описывалось выше, совместимость аппаратных платформ в автоиндустрии
крайне низка.
Переходя к вопросу самого написания кода, стоит отметить крайне малую
степень использования средств по генерированию кода – большая часть
программного обеспечения создается программистами вручную, в то время как
с этой задачей могли справиться и автоматические генераторы исходных кодов.
Слабым местом современной автомобильной индустрии также является
интеграция программного обеспечения и аппаратной части. Во многом, это
происходит из-за описанных выше проблем, но также и из-за недостатка
взаимосвязи между поставщиками систем, которые не имеют единых
стандартов.
21
 
Обеспечение качества продукции для автопроизводителей не менее важно,
чем описанные выше пункты к решению проблем автопроизводства. Зачастую
качество автомобилей и стоимость их гарантийного обслуживания напрямую
зависит от программного обеспечения. Стоит помнить, что автомобиль
является продуктом длительного использования, так как в развитых странах
автомобиль в среднем используется на протяжении 20-30 лет [2], что требует от
производителя также и грамотного подхода к осуществлению поддержки
продукции на таком длительном этапе. В обеспечении данных требований,
требуется достигнуть более высокого уровня совместимости оборудования и
программного обеспечения, так как множество проблем связанных с
программным обеспечением в автомобилях напрямую зависит от
совместимости разных версий оборудования с разными версиями
программного обеспечения даже для одной и той же модели автомобиля.
Подобные ситуации происходят во время жизненного цикла использования
автомобиля, так как продолжительность выпуска многих электронных
компонентов в разы меньше длительности выпуска модели автомобиля. Из этой
проблемы сразу же вытекает и проблема замены оборудования в автомобиле
при выходе его из строя, так как версия модели автомобиля первых серий
значительно отличается от модели автомобиля, выпущенного в последних
сериях, но программное обеспечения должно одинаково безошибочно работать
с оборудованием, разных лет выпуска, отличающихся друг от друга в том числе
и конструктивно. Аппаратная составляющая значительно различается из-за
описанного выше процесса производства электронных компонентов. Здесь
стоит отметить тот факт, что до 50 процентов электронных блоков, заменяемых
при сервисных работах аппаратно полностью исправны [2], но сложность и
практическая невозможность отладки программного обеспечения, а также
работоспособность электронных блоков вкупе с остальными электронными
блоками заставляют сервисных работников прибегнуть к замене оборудования
из-за невозможности нахождения ошибок в программном обеспечении,
повлекших за собой сбои при использовании автомобиля. При этом по данным
22
 
специалистов Daimler AG, до 40% ошибок в программном обеспечении
автомобиля вызваны неграмотными и непроработанными требованиями,
образовавшимися в результате недоразвитой системы создания спецификаций в
автомобильной промышленности.
По достижению решений описанных проблем, возможна интеграция
технологий электронного управления автомобилем (X-by-wire), которые пока
далеки от практического применения в современных моделях автомобилей.

1.2.7. Экономические основания проблем разработки


программного обеспечения автомобилей
Традиционно автомобильная отрасль очень зависима от количества
инвестиций, выделяемых на разработку модели автомобиля. Самым важным
является тот факт, что главными факторами в продвижении модели автомобиля
являются ее конечная цена для покупателя и ее потребительские свойства –
дизайн, качество, комфорт и инновации. Все четыре фактора напрямую зависят
от программного обеспечения и стоимости его разработки. На данный момент
из-за высокой степени реакционности автомобильной индустрии, программное
обеспечение оценивается, как и остальные автомобильные комплектующие, что
в корне неверно из-за разности подходов в экономической модели разработки и
производства программного обеспечения и остальных комплектующих. Но все
же, в последнее время можно видеть положительные изменения в вопросе
оценки программного обеспечения автопроизводителями, в ходе которого
количество средств затрачиваемых на разработку программно-аппаратных
систем сильно возросли. Во многом рост затрат связан с необходимостью
переписывания программного кода под конкретную модель автомобиля. Это
происходит из-за желания автопроизводителей сэкономить на аппаратных
средствах, вследствие чего зачастую используются дешевые процессоры и
комплектующие, которые работают на грани своих вычислительных
возможностей, но при этом требуют создания новых программных решений для
обеспечения требуемых функциональных требований.
23
 
Также на затраты автопроизводителей на разработку программных средств,
радикально повлияет изменение структуры производства и архитектуры
программно-аппаратных систем. В ближайшем будущем на смену электронно-
управляющим устройствам, выполняющим лишь узко-очерченные функции,
придут процессоры, выполняющие и отвечающие за намного большее число
функций. При этом программное обеспечение для подобных систем будут
создавать не производители аппаратной части, а независимые разработчики
программного обеспечения, которые возникнут на рынке в ближайшее время и
произведут революцию в автомобильной индустрии. Обоснованно,
автомобильная индустрия находится на том же этапе, что и производители
персональных компьютеров 30-35 лет тому назад, когда они сами производили
большую часть программного обеспечения для своей продукции [2].

1.2.8. Области исследований разработки программного


обеспечения автомобилей
Автомобильная отрасль столкнулась с множеством задач в области
программного обеспечения в автомобилях. Далее в этой главе дается описание
основных областей исследований в данном вопросе.
Из-за многофункциональности программно-аппаратного комплекса, которая
возникла в недавнем прошлом, необходимо более глубокое понимание
архитектуры автомобиля.
Во-первых, рассмотрим функциональный уровень – точку зрения
пользователей. Этот уровень представляет из себя функциональность
предлагаемую пользователям автомобиля – не только водителю и пассажирам,
но и сервисному персоналу.
Во-вторых, это уровень конструирования – логика архитектуры. На данном
уровне система автомобиля представляется как распределенная программно-
аппаратная сеть. На уровне конструирования архитектура автомобильных
систем может быть представлена в виде конечных автоматов, которые
принимают входные и выходные данные в зависимости от требований
24
 
функционального уровня. Все эти взаимоотношения описываются на уровне
абстракций и описания алгоритмов для внедрения функционала.
Далее идет уровень разбиения на группы в котором идет подготовка в виде
распределения логики и абстракций для реализации на уровне архитектуры
программного обеспечения. Уровень архитектуры программного обеспечения
состоит из классического разделения на часть операционной системы,
драйверов аппаратной части и приложений, с другой.
После уровня архитектуры программного обеспечения идет уровень
аппаратных систем, который включает в себя все устройства, сетевые
соединения, интерфейсы пользователя и многое другое.
В конце идет уровень совмещения программного и аппаратного обеспечения
на котором происходит реализация функционала всех систем автомобиля.
Все упомянутые уровни разработки автомобиля не могут полноценно
работать без проработанной стратегии моделирования и описания
поставленных задач.
Однако, на всех уровнях разработки возникает множество трудностей
связанных с ошеломляющей сложностью систем, составляющих автомобиль.
Есть следующие методы борьбы с все возрастающей сложностью. Например,
разработчики могут использовать технологии и методики, пришедшие из
разработки программного обеспечении – такие как структурирование данных,
разделение задач и абстракция. В итоге разработчики могут получить хорошо
проработанную структуру, если будут пользоваться методами описанными
выше. В тоже время, абстракция – это то, что получают разработчики, если
используют модели. По заявлениям ученых, занимающихся данной тематикой,
разработка методик для работы с моделями остается важной и
многообещающей задачей для улучшения ситуации в разработке продукции
индустрии автомобилестроения [3].
Во многом проблемы, возникающие при разработке программного
обеспечения для автомобильной индустрии можно избежать, переориентировав
бизнес-процессы этой отрасли в сторону высокотехнологичных и
25
 
инновационных разработок, которые требуют намного более быстрого
принятия решений. Например, начало использования стандарта ISO/IEC 15504,
так же известного как SPICE (Software Process Improvement and Capability
Determination), а также методик Capability Maturity Model Integration (CMMI) во
многом помогло бы решить возникающие проблемы при разработке
программного обеспечения в автомобильной отрасли. Тема обеспечения
процессов разработки программного обеспечения в автомобильной отрасли в
целом заслуживает отдельной научной работы.
Одной из надежд в данной области является «плавная» разработка,
использующая модели. Это значит, что разработчики работают с цепочкой
моделей для классических задач: моделирование требований, моделирование
проектируемой системы, моделирование внедрения системы и моделирование
тестов. В будущем, возможно, будет интегрированная система моделирования,
в которой отношения между всеми моделями взаимосвязаны, и модели
создаются из предыдущих моделей.
Напомним важность моделей при разработке и конструировании систем –
начиная с документации, формализации и перевода описания системы с
естественного языка на математический язык, поддающийся анализу,
повторному использованию, трансформации, автоматическому генерированию
кода, который в конечном итоге и предстает в конечной продукции. В общем,
модели являются ключом для удобного инструментария и автоматизации
процесса разработки программного обеспечения в автомобильной отрасли.
Нельзя не отметить и тот факт, что модели помогают запомнить и использовать
вновь знания, приложенные к производству, а также помогают оптимизировать
процесс разработки.
Несмотря на свои преимущества, использование моделей в автомобильной
индустрии находится на крайне низком уровне. Модели используются лишь в
частных случаях процесса разработки программного обеспечения автомобиля.
Таким образом, и такое их редкое использование теряет смысл без
интегрированной в процесс разработки цепочки моделирования.
26
 
Так как модели являются полуформальными, и языки для создания моделей
не формализованы, то польза от их использования не достигается. Типичными
примерами на сегодняшний день являются проверка не непротиворечивость и
генерирование тестовых случаев из моделей. С другой стороны, модели могли
бы значительно улучшить взаимоотношения между автопроизводителями и
поставщиками, которые без использования формальных моделей не являются
оптимальными.
Нынешнее использование языка UML и других подходов моделирования,
используемых в автомобильной отрасли не достаточно отвечают требованиям
для разработки программного обеспечения автомобилей. Стоит отметить, что
эти подходы не основываются на должной теоретической базе и не обладают
необходимым уровнем формализации. В результате, инструментарий для
работы с подобными моделями довольно слаб, возможность анализа моделей
низка, и точность моделирования недостаточна.
Не стоит забывать, что моделировании не тоже самое, что и документация.
Как пишет в своей работе Манфред Брой, вплотную занимающийся проблемой,
язык UML следовало бы назвать UDL от Unified Documentation Language [2],
так как этот язык не предоставляет возможности удобной работы по
автоматизации и детализации.
Следует понимать, что моделирование способно улучшить качество
автомобильных программных систем. Однако, на сегодняшний момент
моделирование не может улучшить качество разработки программных систем,
потому что оно не дает точную и унифицированную оценку для подобных
систем, созданных применяя теоретические основы.
Потенциал интегрированного моделирования в автомобильной отрасли
можно описать следующим образом – сперва, требования производителя
разделяются на функциональную и нефункциональную части; функциональные
требования формализуются при помощи функциональной иерархии, в которой
все атомные свойства описаны взаимосвязанными конечными автоматами, либо
диаграммами последовательностей различных функций. Также в
27
 
функциональной иерархии вводятся отношения зависимостей.
Нефункциональные требования являются требованиями к процессу разработки
программных систем и к обеспечению качества продукта. Таким образом,
разработчики формируют архитектуру, основанную на обеспечении качества,
для которой они обеспечивают функциональные требования.
На этом этапе возникает декомпозиция системы – необходимо описать
логическую архитектуру и интерфейсы компонентов логики. На данном шаге
возможна верификация логической архитектуру, используя формальные
модели компонентов логики, а также доказательство работоспособности
концепта. После этого шага необходимо провести декомпозицию самих
компонентов логики, и провести конструирование аппаратной части и
внедрения всей системы.
К сожалению, на данный момент не существует качественного
инструментария для вышеописанной работы с моделями. Инструментарий, что
используется сейчас, не является частью интегрированной системы, в которой
возможен обмен моделями данных. Те инструментальные средства, что есть
сейчас, не обладают полной и достаточной совместимостью между собой и
вызывают дорогостоящие ошибки еще на этапе разработки модели автомобиля.
Описанный процесс интеграции моделей позволит улучшить качество
программного обеспечения в автомобилях, которое на данный момент является
недостаточным. К примеру, в авионике надежность компонентов оценивается
временем 109 часов, чего более чем достаточно для данной области. В
автомобильных системах даже не известны оценки надежности программного
обеспечения [2].
Одним из решений является автоматическая генерация тестов для
программного обеспечения автомобиля. На данный момент отрасль полагается
на аппаратную и программную часть с точки зрения технологий system in the
loop (hardware-in-the-loop/software-in-the-loop). В данной технике подсистемы
работают в симулированных окружениях в режиме реального времени. Однако,
данный подход приближается к своим технологическим пределам, так как
28
 
комбинаторная сложность всех возможных условий и состояний программно-
аппаратного комплекса в автомобилях быстро увеличивается. Решением
данного вопроса как раз и может выступить технология, где тесты
генерируются, основываясь на моделях.
Однако, моделирование упирается в проработку архитектуры и
спецификацию интерфейсов программно-аппаратной системы. В значительной
мере из-за высокой степени распределенности процесса разработки
комплектующих автомобиля, разработка архитектуры систем оставляет желать
лучшего. Так при разработке комплектующих автопроизводитель описывает
поставщикам архитектуру логики программно-аппаратных средств, но так как
это не формализованный метод описания, поставщики при создании,
заказанных у них систем, используют разные методы, которые при внедрении в
модель автомобиля могут конфликтовать друг с другом, делая процесс отладки
систем кошмаром.
Даже грамотное моделирование и проработка на этапе создания не спасают
от появления ошибок в период использования автомобиля. Но в автомобильной
отрасли, в отличии от авиационной, диагностика и исправление ошибок в
программной части электронных систем не находит широкого применения из-
за сложности нахождения и отслеживания причин проявления ошибок. В
результате, как было описано выше, большая часть электронного оборудования
в автомобиле заменяется, при том, что аппаратно оно было исправно.
От количества ошибок в программном обеспечении, напрямую зависит
надежность автомобиля, которая, в отличии от той же авиационной отрасли, не
может быть предсказана. Авиационная отрасль может служить примером для
автомобильной промышленности из-за методик и качества работы над
программным обеспечением. Так моделирование ошибок FMEA (Failure Mode
and Effects Analysis) значительно повысило качество программного обеспечения
в авиационной отрасли. К сожалению, на данном этапе развития технологий в
автомобильной отрасли моделирование ошибок введено не в полном объеме.
Сейчас автомобильной отрасли необходимы полные модели ошибок в
29
 
автомобилях, а также программное обеспечение для нахождения этих ошибок и
их регистрации, для последующего анализа. Очевидно, что количество ошибок,
и ситуаций, в которых они возникают, в автомобилях больше чем в самолетах –
во многом именно поэтому автомобильная отрасль отстает от авиационной в
решении этой проблемы. Также следует отметить и важность вопроса
безопасности авиационного транспорта, которая была важна еще 80 лет назад, и
тот факт, что в автомобильной отрасли задумались о безопасности пассажиров
гораздо позже.
30
 

ГЛАВА 2. ПРЕДСТАВЛЕНИЕ АВТОМОБИЛЬНЫХ СИСТЕМ ПРИ


ПОМОЩИ АВТОМАТНОГО ПОДХОДА

2.1. Постановка задачи


Цель данной главы – создать модель управления автомобилем. Эта модель
должна обеспечить корректное «поведение» автомобиля в зависимости от
действий «водителя»:
 включение и выключение двигателя;
 нажатие тормоза;
 нажатие акселератора;
 поворот руля;
 переключение передачи.
Так как реальный автомобиль, как было описано в главе 1 – сложная
система, поведение которой зависит от многих внутренних и внешних
факторов, в настоящей работе были выбраны только те из них, которые
являются достаточными для моделирования управления автомобилем в
«первом приближении».
При этом была выбрана модель автомобиля, содержащая три основные
части:
 двигатель;
 коробка передач;
 ходовая часть (колеса).
Этот выбор объясняется тем, что движение автомобиля возможно лишь в
случае вращения колес, которое, в свою очередь, зависит от включенной
передачи и числа оборотов двигателя.
Такие параметры как сила трения колес о поверхность, масса автомобиля,
радиус колес и другие параметры были выбраны при написании программы и
ее отладке.
31
 
Таким образом, ограничившись рассмотрением трех основных
составляющих автомобиля, необходимо промоделировать его поведение в
зависимости от перечисленных выше действий.
 
 

2.2. Описание работы составляющих модели автомобиля

2.2.1. Двигатель
Скорость автомобиля зависит от частоты вращения карданного вала
двигателя и включенной передачи. При этом будем предполагать, что двигатель
работает следующим образом.
1. Включить двигатель можно только при включенной нейтральной
передаче.
2. При включении двигателя устанавливается минимальное число
оборотов, которое в дальнейшем (при переключении передачи)
передается колесам, и автомобиль начинает движение.
3. При разгоне (нажатии акселератора) число оборотов увеличивается до
тех пор, пока не будет достигнут максимум.
4. При отпускании акселератора число оборотов уменьшается до
минимального уровня.
5. Если включить двигатель можно только при включенной нейтральной
передаче, то выключить его можно всегда. При выключении двигателя
число оборотов уменьшится до нуля, и автомобиль остановится.
6. Нажатие акселератора фиксируется и может быть в дальнейшем
отменено.

2.2.2. Коробка передач


Коробка передач для простоты имеет всего четыре передачи (состояния):
 вторая;
 первая;
32
 
 нейтральная;
 задняя.
При визуализации водителю доступны для переключения только три
передачи: первая (D – drive), нейтральная (N – neutral) и задняя (R – reverse).
Их переключение возможно в порядке D N R или R N D, причем смена
направления движения осуществляется только при полной остановке вращения
колес.
Переключение на вторую передачу происходит автоматически, когда число
оборотов двигателя превышает заданное значение (lim).

2.2.3. Ходовая часть (колеса)


За счет вращения колес автомобиль движется в заданном направлении.
При включенном двигателе и выбранной передаче на колеса передается
крутящий момент, который зависит от передаточного числа, определяемого
выбранной передачей.
Для нейтральной передачи это число ноль. В этом случае автомобиль
катится по инерции, и в зависимости от силы трения рано или поздно
остановится.
При первой, второй и задней передачах число оборотов колес зависит от
оборотов двигателя.
Для останова в модели предусмотрен тормоз. При нажатии тормоза
автомобиль останавливается при любой включенной передаче и продолжает
движение при его отпускании.
Управление поворотом передних колес осуществляется рулевым
механизмом. При этом предполагается, что максимальный угол поворота руля,
равный , соответствует максимальному углу поворота колес на угол /6.
Если автомобиль поворачивает (угол поворота руля отличен от нуля), то
при отпускании руля автомобиль за счет вращения задних колес выравнивается.
33
 
Визуализация акселератора, тормоза и руля осуществляется с помощью
соответствующих кнопок, причем для руля используются две кнопки – влево и
вправо. Более подробно визуализация описана в разд.8.

2.3. Система управления автомобилем


Исходя из выбранной модели автомобиля, систему управления также
построим из трех составляющих:
 подсистема управления двигателем (автомат A1);
 подсистема управления коробкой передач (автомат A2);
 подсистема управления колесами (автомат A3 – управление
вращением колес и автомат A4 – управление поворотом колес).

2.4. Диаграмма классов и события

2.4.1. Диаграмма классов


Модель состоит из трех классов:
 класс «Двигатель» (car.Engine);
 класс «Коробка передач» (car.Gears);
 класс «Колеса» (car.Wheels).
Подсистемы управления представляют собой «автоматные» методы
классов.
Основной класс программы (Main) кроме методов, обеспечивающих ее
визуализацию, содержит также обработчик событий.
Упрощенная диаграмма классов приведена на рис.4. В класс frame.Main
является контейнером для классов car.Engine, car.Gears и car.Wheels.
 
34
 
Основной класс
(frame.Main)

Двигатель Коробка передач Колеса


(car.Engine) (car.Gears) (car.Wheels)
A1 A2 A3, A4
 
Рис. 4. Диаграмма классов
 

2.4.2. Взаимодействие автоматов


Автоматы A1, A2, A3 и A4 не являются вложенными. Автомат A2
вызывается при переходах автомата A1, а автомат A3 вызвывется при
переходах автомата A2.
Действия пользователя преобразуются в определенные события в системе.
Обработчики событий помещают события в очередь, которая затем
последовательно обрабатывается в менеджере событий. Очередь событий
общая для всех автоматов. Менеджер событий извлекает из очереди событие и
в зависимости от типа вызывает соответствующий автомат.
Работа системы осуществляется циклически по тактам. На каждой
итерации в каждом из объектов “Engine”, “Gears” и “Wheels” вызывается
метод turn(). В этом методе происходит анализ входных переменных и
осуществляется один переход соответствующего автомата. При этом
осуществляется необходимые выходные воздействия и вызов автоматов.
Также на каждой итерации происходит вызов менеджера событий и при
наличии события происходит вызов соответствующего автомата.
Таким образом, на одной итерации автомат может выполнить несколько
переходов, один из которых определяется цикличностью работы программы, а
остальные – событиями очереди.
В основном цикле принят следующий порядок вызова автоматов:
 A1 (Двигатель);
 A2 (Коробка передач);
 A3, A4 (Ходовая часть – колеса).
35
 
2.5. Класс «Двигатель» (car.Engine)
Основу класса составляет подсистема управления двигателем – автомат
A1. Его входные переменные и выходные воздействия перечислены ниже, а
события, воздействующие на него – на схеме связей (рис.5). Граф переходов
автомата A1 приведен на рис.6.

2.5.1. Входные переменные (x)


1 – Число оборотов двигателя > 0.
2 – Число оборотов двигателя > min.
3 – Число оборотов двигателя < max.
4 – Нажата кнопка акселератора.

2.5.2. Выходные воздействия (z)


0 – Установить минимальное число оборотов.
1 – Увеличить число оборотов двигателя.
2 – Уменьшить число оборотов двигателя.
3 – Зафиксировать нажатие акселератора.
4 – Отменить фиксацию акселератора.
 

2.5.3. Схема связей автомата “Управление двигателем” (A1)


Обработчики A1 Установить мин. число оборотов
Включить двигатель z0
событий e1
Выключить двигатель Увеличить число оборотов
e2 z1
Нажатие акселератора
e33 Уменьшить число оборотов
Отпускание акселератора z2 Двигатель
e34

Включена нейтральная передача


A2 y2=0

e5 Увеличение числа оборотов

e6 Уменьшение числа оборотов A2


x1
x2
x3

Число оборотов двигателя < max

Число оборотов двигателя > min

Число оборотов двигателя > 0


 
Рис. 5. Схема связей автомата “Управление двигателем”
36
 
2.5.4. Граф переходов автомата “Управление двигателем”
 

 
Рис. 6. Граф переходов автомата “Управление двигателем”

2.6. Класс «Коробка передач» (car.Gears)


Основу класса составляет подсистема управления коробкой передач –
автомат A2. Входная переменная автомата указана ниже, а события,
воздействующие на него – на схеме связей (рис.4). Граф переходов автомата A2
приведен на рис.5.

2.6.1. Входные переменные (x)


10 – Количество оборотов двигателя > lim.
37
 
2.6.2. Схема связей автомата “Управление коробкой передач”
(A2)

Рис. 7. Схема связей автомата “Управление коробкой передач”


 

2.6.3. Граф переходов автомата “Управление коробкой


передач”
e5 · !x10 e6 · !x10 e5 e6
A3(15) A3(14) A3(15) A3(14)

e41·!(y3=4)·!(y3=5) e45·!(y3=2)·!(y3=3)
A3(11) A3(13)
1. Первая 0. Нейтральная 3. Задняя

e43 v e100 e43 v e100


A3(10) A3(10)
x10 e43 v e100
A3(12) A3(10)
!x10
A3(11)
2. Вторая

e5 · x10 e6 · x10
A3(15) A3(14)
 
Рис. 8. Граф переходов автомата “Управление коробкой передач”

2.7. Класс «Колеса» (car.Wheels)


Основу класса составляет подсистема управления колесами – автоматы A3,
A4. Входные переменные и выходные воздействия автоматов перечислены
38
 
ниже, а воздействующие события – на схеме связей (рис. 9,11). Графы
переходов автоматов A3 и A4 приведены на рис. 10 и 12, соответственно.

2.7.1. Входные переменные (x)


33 – Двигатель включен.
36 – Нажат тормоз.
40 – Угол поворота колес ~ 0.
43 – Угол поворота колес < max.
44 – Угол поворота колес > -max.
45 – Нажата кнопка поворота вправо.
46 – Нажата кнопка поворота влево.

2.7.2. Выходные воздействия (z)


30 – Установить передаточное число в соответствии с текущей передачей.
31 – Установить необходимое число оборотов колес.
32 – Уменьшить число оборотов колес.
33 – Увеличить число оборотов колес.
34 – Аварийная остановка колес.
42 – Поворот вправо.
41 – Поворот влево.
51 – Зафиксировать нажатие кнопки поворота влево.
52 – Зафиксировать нажатие кнопки поворота вправо.
53 – Зафиксировать нажатие кнопки тормоза.
61 – Отпустить кнопку поворота влево.
62 – Отпустить кнопку поворота вправо.
63 – Отпустить кнопку тормоза.
39
 
2.7.3. Схема связей автомата “Управление вращением колес”
(A3)

A3 z30 Установить передаточное число


Коробка передач Включить нейтральную пердачу
e10 Установить обороты
Включить 1-ю передачу z31
e11 Уменьшить число оборотов Число оборотов
Включить 2-ю передачу z32
e12 Увеличить число оборотов колес,
Включить заднюю передачу z33
e13 передаточное
Уменьшить число обор. колес Аварийный останов колес
e14 z34 число
Увеличить число обор. колес
Обработчики e15
сообщений
Нажатие кнопки тормоза e31
Отпускание кнопки тормоза e32
Аварийная остановка
e100
Выбрана нейтральная передача
y2=0
Выбрана первая передача
A2 y2=1
Выбрана задняя передача
y2=3

x30

Число оборотов колес > 0

Рис. 9. Схема связей автомата “Управление вращением колес”

2.7.4. Граф переходов автомата “Управление вращением


колес”

Рис. 10. Граф переходов автомата “Управление вращением колес”


40
 
2.7.5. Схема связей автомата “Управление поворотом колес” (A4)

Обработчики A4
Нажатие кнопки поворота руля влево e35 Поворота вправо
сообщений z42
Отпускание кнопки поворота руля влево e36 Поворота влево
Нажатие кнопки поворота руля вправо
z41
e37
Отпускание кнопки поворота вправо
e38 Угол поворота
колес
Калеса вращаются
A3 y3 > 1

x40
x43
x44

Угол поворота колес > - max

Угол поворота колес < max


Угол поворота колес = 0
 
Рис. 11. Схема связей автомата “Управление поворотом колес”

2.7.6. Граф переходов автомата “Управление поворотом колес”

Рис. 12. Граф переходов автомата “Управление поворотом колес”


41
 
2.8. Визуализация управления автомобилем
Визуализация управления автомобилем выполнена в виде Java-
приложения (Application). Для построения интерфейса пользователя
использовался Jbuilder7.0.
Основными классами, осуществляющими визуализацию, являются:
 frame.CarApp (содержит метод main()) – создает в конструкторе
объект класса frame.Main;
 frame.Main – главный класс, который
o инициализирует объекты классов car.Engine, car.Gears и
car.Wheels;
o инициализирует вспомогательные объекты классов
frame.EnginePanel, frame.GearsPanel, frame.WheelsPanel,
frame.RoadPanel;
o обрабатывает очередь событий;
o включает обработчики нажатия клавиш клавиатуры и мыши;
 frame.EnginePanel, frame.GearsPanel, frame.WheelsPanel –
вспомогательные классы для визуализации.

Визуализатор (рис.10) выполнен в виде окна, содержащего:


 панель коробки передач;
 панель акселератора;
 панель рулевого механизма;
 панель визуализации движения.

Панели отражают текущее значения параметров взаимодействующих


подсистем. Например, панель акселератора показывает число оборотов
двигателя, а панель рулевого механизма – угол поворота руля.
Автомобиль визуализирован в виде треугольника, в котором центральная
линия, показывает направление движения. Препятствия выполнены в виде
42
 
прямоугольников. Начальное расположение автомобиля, количество и размеры
препятствий задается текстовым файлом («data.dat»).
Для увеличения числа оборотов, поворота руля или торможения
предусмотрены кнопки («Акс.», «<-», «->», «тормоз»). Также можно
воспользоваться и клавишами клавиатуры «вверх», «вправо», «влево», «вниз»
соответственно.
Автомобиль не будет двигаться пока выключен двигатель. Для его
включения необходимо воспользоваться меню «Двигатель -> Старт». При этом
должна также быть включена нейтральная передача (N). Движение вперед
осуществляется при включенной первой (D), а назад – задней (R) передаче.
 

 
Рис. 13. Пример визуализации системы

Визуализатор ведет в виде отдельного файла протокол работы, в котором


фиксируются:
 все нажатия кнопок и пунктов меню;
 работа автоматов (по наступлению события);
 результирующие значения (число оборотов двигателя и колес,
поворот руля и перемещение автомобиля).
43
 
В этом протоколе для «привлечения взгляда» введены дополнительные
символы: i – для входных переменных, * – для выходных воздействий, [] – для
названий состояний автоматов, {} – для отображения вложенности автоматов.

2.9. Программный код


Программный код из-за большого объема приведен фрагментарно.
В классе Main:
 в методе initCar() происходит начальная инициализация объектов
Engine, Gears и Wheels;
 в методе checkEvents() – в менеджере событий – происходит проверка
очереди событий и передача сообщений об их наступлении
соответствующим автоматам;
 в методе initTimer() сосредоточен основной цикл работы программы
(while(true)).
Остальные методы несущественны для целей данной работы. Классы Engine,
Gears и Wheels приведены полностью.
Остальные вспомогательные классы здесь также не приводятся.
 
Начальная инициализация(Main.java):
/**
* Car objects initialization.
*/
private void initCar() {
logfile.setPrefix("car_");
logfile.log("--- Старт ---");

logfile1.setPrefix("frame_");
logfile1.log("--- Инициализация ---");

wheels = new Wheels(WheelsPanel.MAX_ANGLE_STEPS);


engine = new Engine();
gears = new Gears();

engine.init(gears);
gears.init(engine, wheels);
wheels.init(engine, gears);

engine.setLogger(logfile);
gears.setLogger(logfile);
wheels.setLogger(logfile);

gearsPanel.setEvents(events);
roadPanel.setEvents(events);
44
 
enginePanel.setLogger(logfile1);
gearsPanel.setLogger(logfile1);
roadPanel.setLogger(logfile1);
wheelsPanel.setLogger(logfile1);

Основной цикл (Main.java):


/**
* Timer initialization.
*/
private void initTimer() {
timer = new Timer();
timer.schedule(new TimerTask() {
public void run() {
while (true) {
try {
Thread.currentThread().sleep(100);
} catch (InterruptedException e) {
}

if (engine.getY() == 1) {
//if engine started
menuRunStart.setEnabled(false);
menuRunStop.setEnabled(true);
} else {
menuRunStart.setEnabled(true);
menuRunStop.setEnabled(false);
}
checkEvents();

engine.turn();
gears.turn();
wheels.turn3();
wheels.turn4();

enginePanel.setState(engine.getCycles());
gearsPanel.setState(gears.getY());
wheelsPanel.setState(wheels.getAngle());
roadPanel.drawState(wheels.getAngle(), wheels.getCycles(),
wheels.getY3());
}
}

}, 100, 100);
}

Менеджер событий (Main.class):


/**
* Main cycle for checking car events.
*/
private void checkEvents() {
Iterator iter = (new Vector(events)).iterator();
events.clear();

while (iter.hasNext()) {
car.events.CarEvent event = (car.events.CarEvent) iter.next();

if (event instanceof car.events.EngineEvent) {


engine.A1(event.getValue());
}

if (event instanceof car.events.GearsEvent) {


45
 
gears.A2(event.getValue());
}

if (event instanceof car.events.WheelsEvent3) {


wheels.A3(event.getValue());
}
if (event instanceof car.events.WheelsEvent4) {
wheels.A4(event.getValue());
}
if (event instanceof car.events.RunIntoTheWallEvent) {
//run into the wall
gears.A2(100);
wheels.A3(100);
}
}

}
/*--------------------- Engine.java ------------------*/
package car;

public class Engine extends LogObject {

private String autName = "A1";


private boolean LOGX = true;
private boolean START_LOGGING = false;

//Engine parameters
public static int min_cycles = 100;
public static int max_cycles = 1300;
public static int dcycles = 50;

//Engine cycles
private int cycles = 0;

//State value
private int y1 = 0;
private Gears gears;

/**
* Constructor.
*/
public Engine() {
setObjectName("Двигатель");
}

/**
* Turn.
*/
public void turn() {
switch (y1) {
case 0: // stopped
if (x_1()) {
z_2();
//less engine cycles
gears.A2(6);
}
break;
case 1: // started && acc released
if (x_2()) { // cycles > min
z_2(); //less engine cycles
gears.A2(6);
}
break;
46
 
case 2: // started && acc pressed
if (x_3()) { // cycles < max
z_1(); //more engine cycles
gears.A2(5);
}
break;
}
}

/**
* Engine initialization.
* @param g Gears object.
*/
public void init(Gears g) {
this.gears = g;
cycles = 0;
y1 = 0;
}

/**
* Automate A1.
* @param e Event value.
*/
public void A1(int e) {

beginLogging(y1, e, autName);
START_LOGGING = true;

switch (y1) {

case 0: // stopped
if (e == 1 && (gears.getY() == 0)) {
// start engine
z_0();
y1 = 1;
}
break;

case 1: // started && acc released


if (e == 33) { // accelerator pressed
y1 = 2;
} else if (e == 2) { // stop engine
y1 = 0;
}
break;

case 2: // started && acc pressed


if (e == 34) { // accelerator released
y1 = 1;
} else if (e == 2) { // stop engine
y1 = 0;
}
break;

default:
this.logErrorState(y1, autName);
break;
}

endLogging(y1, autName);
START_LOGGING = false;
}

private boolean x_1() {


47
 
boolean result = cycles > 0;
if (LOGX && START_LOGGING) {
logAutX("x1", "Количество оборотов двигателя > 0 ?", result);
}
return result;
}

private boolean x_2() {


boolean result = cycles > min_cycles;
if (LOGX && START_LOGGING) {
logAutX("x2", "Количество оборотов двигателя > min ?", result);
}
return result;
}

private boolean x_3() {


boolean result = cycles < max_cycles;
if (LOGX && START_LOGGING) {
logAutX("x3", "Количество оборотов двигателя < max ?", result);
}

return result;
}

private void z_0() {


cycles = min_cycles;
if (START_LOGGING) logAutZ("z0", "Установить минимальное число
оборотов");
}

private void z_1() {


cycles += dcycles;
if (cycles > max_cycles) cycles = max_cycles;
if (START_LOGGING) logAutZ("z1", "Увеличить число оборотов двигателя ("
+ cycles + ")");

private void z_2() {


cycles -= dcycles;
if (cycles < 0) cycles = 0;
if (START_LOGGING) logAutZ("z2", "Уменьшить число оборотов двигателя ("
+ cycles + ")");

/**
* Gets automat state.
* @return Automat state.
*/
public int getY() {
return y1;
}

/**
* Gets number of engine cycles.
* @return Current cycles.
*/
public int getCycles() {
return cycles;
}

/**
* Gets name of the automat state.
48
 
* @param state Automate state.
* @param aut Aut name.
* @return String name of the state.
*/
public String getStateName(int state, String aut) {
String name = "не определено";
switch (state) {
case 0:
name = "Двигатель выключен";
break;
case 1:
name = "Двигатель включен и акселератор отпущен";
break;
case 2:
name = "Двигатель включен и акселератор нажат";
break;
}
return name;

}
}
/*--------------------- Gears.java ------------------*/:
package car;

public class Gears extends LogObject {

private String autName = "A2";


private boolean LOGX = true;
private boolean START_LOGGING = false;

private int limit;

//Gears state value


private int y2 = 0;

//Engine
private Engine engine;

//Wheels
private Wheels wheels;

public Gears() {
limit = Engine.min_cycles + (Engine.max_cycles – Engine.min_cycles) * 1
/ 2;
setObjectName("Коробка передач");
}

public void init(Engine e, Wheels w) {


this.engine = e;
this.wheels = w;
y2 = 0;
}

/**
* Turn.
*/
public void turn() {
switch (y2) {
case 0: //neutral gear
break;

case 1: //first gear


if (x_10()) {
y2 = 2;
49
 
//to the second gear
wheels.A3(12);
}
break;

case 2: //second gear


if (!x_10()) {
y2 = 1;
//to the first gear
wheels.A3(11);
}
break;

case 3: //reverse gear


break;
}

/**
* Automat A2.
* @param e Event value.
*/
public void A2(int e) {

beginLogging(y2, e, autName);
START_LOGGING = true;

switch (y2) {
case 0: //neutral gear
if (e == 41 && !(wheels.getY3() == 2)) {
//if choose D
y2 = 1;
//to the first gear
wheels.A3(11);
} else if (e == 45 && !(wheels.getY3() == 1)) {
//if choose R
y2 = 3;
//to the reverse gear
wheels.A3(13);
}
break;

case 1: //first gear


if (e == 43 || e == 100) {
//if choose neutral gear or run into the wall
y2 = 0;
//to the neutral gear
wheels.A3(10);
} else if (e == 5 && !x_10()) {
//if more engine cycles
//more wheels cycles
wheels.A3(15);
} else if (e == 6 && !x_10()) {
//if less engine cycles
//less wheels cycles
wheels.A3(14);
}
break;

case 2://second gear


if (e == 43 || e == 100) {
//if choose neutral gear or run into the wall
50
 
y2 = 0;
//to the neutral gear
wheels.A3(10);
} else if (e == 5 && x_10()) {
//if more engine cycles
//more wheels cycles
wheels.A3(15);
} else if (e == 6 && x_10()) {
//if less engine cycles
//less wheels cycles
wheels.A3(14);
}
break;

case 3://reverse gear


if (e == 43 || e == 100) {
//if choose neutral or run into the wall
y2 = 0;
//to the neutral gear
wheels.A3(10);
} else if (e == 5) {
//if more engine cycles
//more wheels cycles
wheels.A3(15);
} else if (e == 6) {
//if less engine cycles
//less wheels cycles
wheels.A3(14);
}
break;
default:
logErrorState(y2, autName);
break;
}

endLogging(y2, autName);
START_LOGGING = false;
}

private boolean x_10() {


boolean result = engine.getCycles() > limit;
if (LOGX && START_LOGGING) {
logAutX("x10", "Число оборотов двигателя > lim ?", result);
}
return result;
}

public int getY() {


return y2;
}

public String getStateName(int state, String aut) {


String name = "не определено";

switch (state) {
case 0:
name = "Включена нейтральная передача";
break;
case 1:
name = "Включена первая передача";
break;
case 2:
name = "Включена вторая передача";
51
 
break;
case 3:
name = "Включена задняя передача";
break;
}
return name;
}
}
/*--------------------- Wheels.java ------------------*/
package car;

public class Wheels extends LogObject {

private String autName1 = "A3";


private String autName2 = "A4";

private boolean LOGX = true;


private boolean START_LOGGING = false;

private static final double pi = Math.PI;

//Gears numbers
static final double gear1_num = 4;
static final double gear2_num = 3;
static final double gear3_num = 4;

public static double maxangle = pi / 6;


public static double default_dcycles = 5;
public static double brake_dcycles = 10;
public static double dangle = 0;

//Wheels rotation state value


private int y3 = 0;

//Wheels angle state value


private int y4 = 0;

private double cycles = 0;


private double angle = 0;
public static double dcycles = default_dcycles;

//Current gears number


private double num = 0;

//Engine
private Engine engine;

//Gear
private Gears gears;

/**
* Constructor.
* @param max_count_of_angle_steps Max count of steps for the car wheel (Rudder).
*/
public Wheels(int max_count_of_angle_steps) {
dangle = maxangle / max_count_of_angle_steps;
setObjectName("Ходовая часть");
}

/**
* Wheels Initialization.
* @param e Engine object.
* @param g Gears object.
*/
52
 
public void init(Engine e, Gears g) {
this.engine = e;
this.gears = g;

y3 = 0;
y4 = 0;
num = 0;
cycles = 0;
dcycles = default_dcycles;
}

/**
* Turn A3.
*/
public void turn3() {
switch (y3) {
case 0:// wheels stopped && break released
break;
case 1:// wheels stpped && break pressed
break;
case 2:// wheels forward && break released
if (gears.getY() == 0) { // neutral gear
z_32(); // less wheel's cycles
}
if (!x_30()) y3 = 0; // if cycles == 0 set y3 = 1;
break;
case 3:// wheels forward && break pressed
z_32(); // less wheel's cycles
if (!x_30()) y3 = 1; // if cycles == 0 set y3 = 1;
break;
case 4:// wheels backward && break released
if (gears.getY() == 0) { // neutral gear
z_32(); // less wheel's cycles
}
if (!x_30()) y3 = 0; // if cycles == 0 set y3 = 1;
break;
case 5:// wheels backward && break pressed
z_32(); // less wheel's cycles
if (!x_30()) y3 = 1; // if cycles == 0 set y3 = 1;
break;
}
}

/**
* Turn A4.
*/
public void turn4() {
switch (y4) {
case 0: //wheels in line && nothing pressed
break;
case 1: //wheels in line && left pressed
z_41(); // left turn
y4 = 9;
break;
case 2: //wheels in line && right pressed
z_42(); // right turn
y4 = 6;
break;
case 4: // wheels turned right && nothing pressed
if (y3 > 1) { // wheel cycles != 0
z_43(); // set to line
y4 = 0;
//z_41();
}
53
 
break;
case 5: // wheels turned right && left pressed
z_41(); // set to left
if (x_40()) y4 = 1;
break;
case 6: // wheels turned right && right pressed
if (x_43()) { // angle < max
z_42(); // set to right
}
break;
case 8: // wheels turned left && nothing pressed
if (y3 > 1) { // wheel cycles != 0
z_43(); // set to line
y4 = 0;
//z_41();
}
break;
case 9: // wheels turned left && left pressed
if (x_44()) {
z_41(); // set to left
}
break;
case 10: // wheels turned left && right pressed
z_42(); // set to right
if (x_40()) y4 = 2;
break;
}
}

/**
* Automat A3.
* @param e Event value.
*/
public void A3(int e) {

beginLogging(y3, e, autName1);
START_LOGGING = true;

switch (y3) {
case 0://wheels stopped && break released
if (e == 31) { // press break
y3 = 1;
} else if (e == 11 && engine.getY() > 0) {// to the first gear
z_30();
z_31();
y3 = 2;
} else if (e == 13 && engine.getY() > 0) { // to the reverce gear
z_30();
z_31();
y3 = 4;
}
break;
case 1: //wheels stopped && break pressed
if (e == 32 && (gears.getY() == 1)) { // release break && first
gear
z_30();
z_31();
y3 = 2;
} else if (e == 32 && (gears.getY() == 3)) { //release break &&
reverse gear
z_30();
z_31();
y3 = 4;
} else if (e == 32) { // release break
54
 
y3 = 0;
}
break;

case 2://wheels forward && break released


if (e == 31) {
y3 = 3;
z_32(); // less cycles
} else if (e == 14) { // less wheels cycles
z_32();
} else if (e == 15) { // more wheels cycles
z_33();
} else if (e == 10 || e == 11 || e == 12) { // to neutral or first
or second
z_30();
z_31();
} else if (e == 100) { // run into the wall
z_34();
y3 = 0;
}
break;

case 3://wheels forward && break pressed


if (e == 32) {
z_30();
z_31();
y3 = 2;
} else if (e == 10 || e == 11 || e == 12) { // to neutral or first
or second
z_30();
z_31();
} else if (e == 100) { // run into the wall
z_34();
y3 = 1;
}
break;

case 4:// wheels backward && break rteleased


if (e == 31) {
y3 = 5;
z_32(); // less cycles
} else if (e == 14) { // less wheels cycles
z_32();
} else if (e == 15) { // more wheels cycles
z_33();
} else if (e == 10 || e == 13) { // to the neutral or reverce
z_30();
z_31();
} else if (e == 100) {
//if run into the wall
z_34();
y3 = 0;
}

break;

case 5:// wheels backward && break pressed

if (e == 32) {
y3 = 4;
z_30();
z_31();
} else if (e == 10 || e == 13) { // to the neutral or reverce
55
 
z_30();
z_31();
} else if (e == 100) { //if run into the wall
z_34();
y3 = 1;
}

break;

default:
logErrorState(y3, autName1);
break;
}

endLogging(y3, autName1);
START_LOGGING = false;
}

/**
* Automat A4.
* @param e Event value.
*/
public void A4(int e) {
beginLogging(y4, e, autName2);
START_LOGGING = true;

switch (y4) {
case 0: //wheels in line && nothing pressed
if (e == 37) { // right press
y4 = 6;
z_42(); // to right
} else if (e == 35) { // left press
y4 = 9;
z_41(); // to left
}
break;
case 1: //wheels in line && left pressed
if (e == 36) { // left button release
y4 = 0;
}
break;
case 2: //wheels in line && right pressed
if (e == 38) { // right button release
y4 = 0;
}
break;
case 4: // wheels turned right && nothing pressed
if (e == 37 && x_43()) { //right button press && angle < max
y4 = 6;
z_42();
} else if (e == 35) { // left button press
y4 = 5;
z_41();
}
break;
case 5: // wheels turned right && left pressed
if (e == 36) { // left button release
y4 = 4;
}
break;
case 6: // wheels turned right && right pressed
if (e == 38) { // right button release
y4 = 4;
56
 
}
break;
case 8: // wheels turned left && nothing pressed
if (e == 37) { // right button press
y4 = 10;
z_42();
} else if (e == 35 && x_44()) { //left button pressed && angle > -
max
y4 = 9;
z_41();
}
break;
case 9: // wheels turned left && left pressed
if (e == 36) { //left button release
y4 = 8;
}
break;
case 10: // wheels turned left && right pressed
if (e == 38) { //right button release
y4 = 8;
}
break;
default:
logErrorState(y4, autName2);
break;
}

endLogging(y4, autName2);
START_LOGGING = false;
}

private boolean x_30() {


boolean result = cycles > 0;
if (LOGX && START_LOGGING) {
logAutX("x30", "Число оборотов колес> 0 ?", result);
}
return result;
}

private boolean x_40() {


boolean result = angle > -dangle && angle < dangle;
if (result) angle = 0;

if (LOGX && START_LOGGING) {


logAutX("x40", "Угол поворота колес ~ 0 ?", result);
}
return result;
}

private boolean x_43() {


boolean result = angle < maxangle;
if (LOGX && START_LOGGING) {
logAutX("x43", "Угол поворота колес < max ?", result);
}
return result;
}

private boolean x_44() {


boolean result = angle > -maxangle;
if (LOGX && START_LOGGING) {
logAutX("x44", "Угол поворота колес > -max ?", result);
}
return result;
57
 
}

private void z_30() {


switch (gears.getY()) {
case 0:
num = 0;
break;
case 1:
num = gear1_num;
break;
case 2:
num = gear2_num;
break;
case 3:
num = gear3_num;
break;
}

if (START_LOGGING) logAutZ("z30", "Установить передаточное число в


соответствии с текущей передачей");
}

private void z_31() {


if (num != 0) {
cycles = engine.getCycles() / num;
dcycles = Engine.dcycles / num;
} else {
dcycles = default_dcycles;
}

if (START_LOGGING) logAutZ("z31", "Установить необходимое число оборотов


колес");
}

private void z_32() {


cycles -= dcycles;
if (cycles < 0) cycles = 0;
if (START_LOGGING) logAutZ("z32", "Уменьшить число оборотов колес");
}

private void z_33() {


cycles += dcycles;
if (START_LOGGING) logAutZ("z33", "Увеличить число оборотов колес");
}

private void z_34() {


cycles = 0;
if (START_LOGGING) logAutZ("z34", "Аварийная остановка колес");
}

private void z_42() {


angle += dangle;
if (angle > maxangle) angle = maxangle;
if (START_LOGGING) logAutZ("z42", "Поворот вправо ");
}

private void z_41() {


angle -= dangle;
if (angle < -maxangle) angle = -maxangle;
if (START_LOGGING) logAutZ("z41", "Поворот влево");
}
58
 
private void z_43() {
angle = 0;
if (START_LOGGING) logAutZ("z43", "Установить угол поворота колес в 0");
}

/**
* Gets wheels cycles.
* @return Current cycles.
*/
public double getCycles() {
return cycles;
}

/**
* Gets wheels angle.
* @return Current wheels angle.
*/
public double getAngle() {
return angle;
}

/**
* Get automat A3 current state.
* @return Automat A3 current state.
*/
public int getY3() {
return y3;
}

/**
* Get automat A4 current state.
* @return Automat A4 current state.
*/
public int getY4() {
return y4;
}

/**
* Gets automat state name.
* @param state State value.
* @param aut Automat name.
* @return Name of outomat state.
*/
public String getStateName(int state, String aut) {
String name = "не определено";

if (autName1.equals(aut)) {
switch (state) {
case 0:
name = "Колеса не вращаются и тормоз отпущен";
break;
case 1:
name = "Колеса не вращаются и тормоз нажат";
break;
case 2:
name = "Колеса вращаются вперед и тормоз отпущен";
break;
case 3:
name = "Колеса вращаются вперед и тормоз нажат";
break;
case 4:
name = "Колеса вращаются назад и тормоз отпущен";
break;
case 5:
59
 
name = "Колеса вращаются назад и тормоз нажат";
break;

}
}
if (autName2.equals(aut)) {
switch (state) {
case 0:
name = "Поворота колес нет и кнопки поворота отпущены";
break;
case 1:
name = "Поворота колес нет и нажата кнопка поворота влево";
break;
case 2:
name = "Поворота колес нет и нажата кнопка поворота вправо";
break;
case 4:
name = "Колеса повернуты вправо и кнопки поворота отпущены";
break;
case 5:
name = "Колеса повернуты вправо и кнопка поворота влево
нажата";
break;
case 6:
name = "Колеса повернуты вправо и кнопка поворота вправо
нажата";
break;
case 8:
name = "Колеса повернуты влево и кнопки поворота отпущены";
break;
case 9:
name = "Колеса повернуты влево и кнопка поворота влево
нажата";
break;
case 10:
name = "Колеса повернуты влево и кнопка поворрота вправо
нажата";
break;

}
}

return name;
}

 

2.10. Пример протокола моделирования управления автомобилем


 
Старт двигателя и начало движения вперед
--- Старт ---
--- Инициализация ---
> акс.: [ число оборотов двигателя -- 0 ]
> к.п.: [ включена передача -- 0 ]
> руль: [ поворот -- 0.0 ]
> итог: [ перемещение -- 0.0 ] [ поворот руля -- 0.0 ] [ поворот объекта -- 0.0
]
< @МЕНЮ >: включить двигатель
Для объекта Двигатель:
{ A1: Автомат A1 запущен в состоянии 0 [Двигатель выключен]
60
 
с событием e1 (Включить двигатель)
* z0: Установить минимальное число оборотов
} A1: Автомат A1 завершил свою работу в состоянии 1 [Двигатель включен и
акселератор отпущен]
> акс.: [ число оборотов двигателя -- 100 ]
< @КНОПКА = ВЫБОР >: передача D
Для объекта Коробка передач:
{ A2: Автомат A2 запущен в состоянии 0 [Включена нейтральная передача]
с событием e41 (Выбор передачи D)
Для объекта Ходовая часть:
{ A3: Автомат A3 запущен в состоянии 0 [Колеса не вращаются и тормоз отпущен]
с событием e11 (Включить первую передачу)
* z30: Установить передаточное число в соответствии с текущей передачей
* z31: Установить необходимое число оборотов колес
} A3: Автомат A3 завершил свою работу в состоянии 2 [Колеса вращаются вперед и
тормоз отпущен]
} A2: Автомат A2 завершил свою работу в состоянии 1 [Включена первая передача]
> к.п.: [ включена передача -- 1 ]
> итог: [ перемещение -- 2.5 ] [ поворот руля -- 0.0 ] [ поворот объекта -- 0.0
]

Поворот влево при движении вперед

< @КНОПКА = НАЖАТА >: поворот влево


Для объекта Ходовая часть:
{ A4: Автомат A4 запущен в состоянии 0 [Поворота колес нет и кнопки поворота
отпущены]
с событием e35 (Нажатие кнопки поворота руля влево)
* z41: Поворот влево
} A4: Автомат A4 завершил свою работу в состоянии 9 [Колеса повернуты влево и
кнопка поворота влево нажата]
> руль: [ поворот -- -0.31 ]
> итог: [ перемещение -- 2.5 ] [ поворот руля -- 0.0 ] [ поворот объекта -- -
0.05 ]
> руль: [ поворот -- -0.47 ]
> итог: [ перемещение -- 2.5 ] [ поворот руля -- 0.0 ] [ поворот объекта -- -
0.13 ]
> руль: [ поворот -- -0.62 ]
> итог: [ перемещение -- 2.5 ] [ поворот руля -- 0.0 ] [ поворот объекта -- -
0.23 ]
> руль: [ поворот -- -0.78 ]
> итог: [ перемещение -- 2.5 ] [ поворот руля -- 0.0 ] [ поворот объекта -- -
0.36 ]
> руль: [ поворот -- -0.94 ]
> итог: [ перемещение -- 2.5 ] [ поворот руля -- 0.0 ] [ поворот объекта -- -
0.52 ]
> руль: [ поворот -- -1.09 ]
> итог: [ перемещение -- 2.5 ] [ поворот руля -- 0.0 ] [ поворот объекта -- -
0.70 ]
< @КНОПКА = ОТПУЩЕНА >: поворот влево
Для объекта Ходовая часть:
{ A4: Автомат A4 запущен в состоянии 9 [Колеса повернуты влево и кнопка поворота
влево нажата]
с событием e36 (Отпускание кнопки поворота руля влево)
} A4: Автомат A4 завершил свою работу в состоянии 8 [Колеса повернуты влево и
кнопки поворота отпущены]
> руль: [ поворот -- 0.0 ]
> итог: [ перемещение -- 2.5 ] [ поворот руля -- 0.0 ] [ поворот объекта -- -
0.70 ]
 
61
 
Торможение при движении вперед
 
> акс.: [ число оборотов двигателя -- 350 ]
> итог: [ перемещение -- 8.75 ] [ поворот руля -- 0.0 ] [ поворот объекта -- 0.0
]
< @КНОПКА = НАЖАТА >: тормоз
Для объекта Ходовая часть:
{ A3: Автомат A3 запущен в состоянии 2 [Колеса вращаются вперед и тормоз
отпущен]
с событием e31 (Нажатие тормоза)
* z32: Уменьшить число оборотов колес
} A3: Автомат A3 завершил свою работу в состоянии 3 [Колеса вращаются вперед и
тормоз нажат]
Для объекта Коробка передач:
{ A2: Автомат A2 запущен в состоянии 1 [Включена первая передача]
с событием e6 (Уменьшить число оборотов двигателя)
Для объекта Ходовая часть:
{ A3: Автомат A3 запущен в состоянии 3 [Колеса вращаются вперед и тормоз нажат]
с событием e14 (Уменьшить число оборотов колес)
} A3: Автомат A3 завершил свою работу в состоянии 3 [Колеса вращаются вперед и
тормоз нажат]
} A2: Автомат A2 завершил свою работу в состоянии 1 [Включена первая передача]
> акс.: [ число оборотов двигателя -- 300 ]
> итог: [ перемещение -- 6.25 ] [ поворот руля -- 0.0 ] [ поворот объекта -- 0.0
]
Для объекта Коробка передач:
{ A2: Автомат A2 запущен в состоянии 1 [Включена первая передача]
с событием e6 (Уменьшить число оборотов двигателя)
Для объекта Ходовая часть:
{ A3: Автомат A3 запущен в состоянии 3 [Колеса вращаются вперед и тормоз нажат]
с событием e14 (Уменьшить число оборотов колес)
} A3: Автомат A3 завершил свою работу в состоянии 3 [Колеса вращаются вперед и
тормоз нажат]
} A2: Автомат A2 завершил свою работу в состоянии 1 [Включена первая передача]
> акс.: [ число оборотов двигателя -- 250 ]
> итог: [ перемещение -- 5.0 ] [ поворот руля -- 0.0 ] [ поворот объекта -- 0.0
]

< @КНОПКА = ОТПУЩЕНА >: тормоз
Для объекта Ходовая часть:
{ A3: Автомат A3 запущен в состоянии 1 [Колеса не вращаются и тормоз нажат]
с событием e32 (Отпускание тормоза)
* z30: Установить передаточное число в соответствии с текущей передачей
* z31: Установить необходимое число оборотов колес
} A3: Автомат A3 завершил свою работу в состоянии 2 [Колеса вращаются вперед и
тормоз отпущен]
> итог: [ перемещение -- 2.5 ] [ поворот руля -- 0.0 ] [ поворот объекта -- 0.0
]

Авария (столкнулись с препятствием)

Для объекта Коробка передач:


{ A2: Автомат A2 запущен в состоянии 2 [Включена вторая передача]
с событием e100 (Столкновение с препятствием)
Для объекта Ходовая часть:
{ A3: Автомат A3 запущен в состоянии 2 [Колеса вращаются вперед и тормоз
отпущен]
с событием e10 (Включить нейтральную передачу)
* z30: Установить передаточное число в соответствии с текущей передачей
* z31: Установить необходимое число оборотов колес
} A3: Автомат A3 завершил свою работу в состоянии 2 [Колеса вращаются вперед и
тормоз отпущен]
62
 
} A2: Автомат A2 завершил свою работу в состоянии 0 [Включена нейтральная
передача]
Для объекта Ходовая часть:
{ A3: Автомат A3 запущен в состоянии 2 [Колеса вращаются вперед и тормоз
отпущен]
с событием e100 (Столкновение с препятствием)
* z34: Аварийная остановка колес
} A3: Автомат A3 завершил свою работу в состоянии 0 [Колеса не вращаются и
тормоз отпущен]
Для объекта Двигатель:
{ A1: Автомат A1 запущен в состоянии 2 [Двигатель включен и акселератор нажат]
с событием e34 (Отпускание акселератора)
} A1: Автомат A1 завершил свою работу в состоянии 1 [Двигатель включен и
акселератор отпущен]
Для объекта Коробка передач:
{ A2: Автомат A2 запущен в состоянии 0 [Включена нейтральная передача]
с событием e6 (Уменьшить число оборотов двигателя)
} A2: Автомат A2 завершил свою работу в состоянии 0 [Включена нейтральная
передача]
> акс.: [ число оборотов двигателя -- 750 ]
> к.п.: [ включена передача -- 0 ]
> итог: [ перемещение -- 0.0 ] [ поворот руля -- 0.0 ] [ поворот объекта -- 0.0
]
Для объекта Коробка передач:
{ A2: Автомат A2 запущен в состоянии 0 [Включена нейтральная передача]
с событием e6 (Уменьшить число оборотов двигателя)
} A2: Автомат A2 завершил свою работу в состоянии 0 [Включена нейтральная
передача]
> акс.: [ число оборотов двигателя -- 700 ]

Начало движения назад


--- Старт ---
--- Инициализация ---
> акс.: [ число оборотов двигателя -- 0 ]
> к.п.: [ включена передача -- 0 ]
> руль: [ поворот -- 0.0 ]
> итог: [ перемещение -- 0.0 ] [ поворот руля -- 0.0 ] [ поворот объекта -- 0.0
]
< @МЕНЮ >: включить двигатель
Для объекта Двигатель:
{ A1: Автомат A1 запущен в состоянии 0 [Двигатель выключен]
с событием e1 (Включить двигатель)
* z0: Установить минимальное число оборотов
} A1: Автомат A1 завершил свою работу в состоянии 1 [Двигатель включен и
акселератор отпущен]
> акс.: [ число оборотов двигателя -- 100 ]
< @КНОПКА = ВЫБОР >: передача R
Для объекта Коробка передач:
{ A2: Автомат A2 запущен в состоянии 0 [Включена нейтральная передача]
с событием e45 (Выбор передачи R)
Для объекта Ходовая часть:
{ A3: Автомат A3 запущен в состоянии 0 [Колеса не вращаются и тормоз отпущен]
с событием e13 (Включить заднюю передачу)
* z30: Установить передаточное число в соответствии с текущей передачей
* z31: Установить необходимое число оборотов колес
} A3: Автомат A3 завершил свою работу в состоянии 4 [Колеса вращаются назад и
тормоз отпущен]
} A2: Автомат A2 завершил свою работу в состоянии 3 [Включена задняя передача]
> к.п.: [ включена передача -- 3 ]
> итог: [ перемещение -- -2.5 ] [ поворот руля -- 0.0 ] [ поворот объекта -- 0.0
]
Для объекта Коробка передач:
63
 
{ A2: Автомат A2 запущен в состоянии 3 [Включена задняя передача]
с событием e100 (Столкновение с препятствием)
Для объекта Ходовая часть:
{ A3: Автомат A3 запущен в состоянии 4 [Колеса вращаются назад и тормоз отпущен]
с событием e10 (Включить нейтральную передачу)
* z30: Установить передаточное число в соответствии с текущей передачей
* z31: Установить необходимое число оборотов колес
} A3: Автомат A3 завершил свою работу в состоянии 4 [Колеса вращаются назад и
тормоз отпущен]
} A2: Автомат A2 завершил свою работу в состоянии 0 [Включена нейтральная
передача]
Для объекта Ходовая часть:
{ A3: Автомат A3 запущен в состоянии 4 [Колеса вращаются назад и тормоз отпущен]
с событием e100 (Столкновение с препятствием)
* z34: Аварийная остановка колес
} A3: Автомат A3 завершил свою работу в состоянии 0 [Колеса не вращаются и
тормоз отпущен]
> к.п.: [ включена передача -- 0 ]
> итог: [ перемещение -- 0.0 ] [ поворот руля -- 0.0 ] [ поворот объекта -- 0.0
]   
64
 
ЗАКЛЮЧЕНИЕ
Итак, в ходе работы выполнен обзор существующих подходов к созданию
встроенного программного обеспечения для автомобилей. В результате были
сформулированы требования к разработке программного обеспечения, для этой
узкоспециализированной области. В итоге, для реализации поставленной
задачи выбран автоматный подход. Разобранный пример показывает, как,
применяя автоматный подход к проектированию программ, можно красиво
добиться желаемого результата в поведении системы. Конечно, можно было
пойти и другим путем, например, расписать алгоритм в виде стандартных блок-
схем. Но, было ли возможно в этом случае так же подробно и ясно увидеть
картину взаимодействия подсистем? Или также легко добавить необходимую
функциональность и получить протокол работы? Либо же приблизить
движение автомобиля к реальному, например, когда глохнет двигатель и колеса
под действием силы трения снижают обороты и останавливаются? На первый
взгляд, можно обойтись добавлением пары флагов и циклов и все заработает.
Но, что будет, если потребуется еще больше усложнить поведение системы?
Возможно ли, так же легко разобраться в написанном вами коде и алгоритме?
Еще одним плюсом автоматного проектирования, на мой взгляд, является
независимость в разработке взаимодействующих подсистем – четко
определяются возможные состояния, действия, входные и выходные
переменные.
Такой способ проектирования позволяет легко наращивать
функциональность системы и усложнять ее поведение, путем
усовершенствования каждой из подсистем.
Большой объем работы по построению графов и схем не является
недостатком, скорее плюсом для разработчика, так как потом потребуется
меньше времени на отладку программы и внесения в нее изменений.
Подводя итог, можно отметить, что автоматный подход при создании
программного обеспечения реальных систем и их моделей помогает
существенно облегчить процесс проектирования, отладки и модификации
65
 
программного кода. Явное выделение состояний делает логику программы
более простой и прозрачной для понимания, что вместе с протоколированием
работы автоматов позволяет разработчикам успешно следить за поведением
программы, как в период разработки, так и во время сопровождения
программного продукта.
В ходе данной работы произведено исследование применения автоматного
подхода для разработки встроенного программного обеспечения автомобиля,
которое заинтересовало автопроизводителей и поставщиков первого уровня,
разрабатывающих комплексные электронные системы, встраиваемые в модели
автомобилей. В ближайшем будущем, будет продолжена работа по
исследованию и интеграции автоматного подхода в автомобильную
промышленность при содействии Правительства Петербурга и
автопроизводителей, участвующих в создании петербургского автомобильного
экономического кластера.
66
 

СПИСОК ЛИТЕРАТУРЫ
1. Н. Поликарпова, А. Шалыто. Автоматное программирование. СПб.:
Питер, 2009
2. Manfred Broy. Challenges in Automotive Software Engineering, 2006
3. Dr. Klaus Grimm. Software Technology in an Automotive Company –
Major Challenges, 2003
4. Kiencke, Nielsen. Automotive Control Systems. Berlin: Springer, 2005.
5. Tom Denton. Automobile Electrical and Electronic Systems. London:
Elsevier Butterworth-Heinemann, 2005
6. Manfred Broy. Model-Driven Development of Reliable Automotive
Services. Berlin: Springer, 2008
7. Martin Rohdin, Lars Ljungberg. A Method for Model Based Automotive
Software Development, 2003
8. Gabriel Leen, Donal Heffernan. Expanding Automotive Electronic Systems,
2002
9. Oleg Gusikhin, Dimitar Filev, Nestor Rychtyckyj. Intelligent Vehicle Systems
Applications and New Trends, 2005
10. Jewgenij Botaschanjan, Manfred Broy, Alexander Gruler. On the correctness
of upper layers of automotive systems, 2008
11. Ken Tindell, Hermann Kopetz, Fabian Wolf, Safe Automotive Software
Development, 2003
12. Alexander Pretschner, Manfred Broy, Ingolf H. Krüger, Thomas Stauner,
Software Engineering for Automotive Systems: A Roadmap, 2007
13. Сайт The Daimler Center for Automotive Information Technology
Innovations (DCAITI), http://www.dcaiti.tu-berlin.de/