Программирование систем управления машин

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

В начальной стадии проектирования системы электронного управления необходимо решить на каких контроллерах реализовывать проект. Тут есть два варианта:

Контроллеры с языками низкого уровня (типа С и ассемблера).

Плюсы:
+ Самые бюджетные по цене
+ Среда разработки бесплатная

Минусы:
- Нет стандартных плагинов, блоков и драйверов для работы с датчиками, соленоидами и другими устройствами
- Разработка и отладка кода существенно дольше, чем на контроллерах с графическим программированием
- Модификация кода занимает также много времени

Контроллеры с графической интегрированной средой разработки

Плюсы:
+ Можно написать логику программы машины, не разбираясь в программировании глубоко, и не изучая языки программирования, которые чаще всего по возможностям превышают требования, которые нужны для разработки алгоритмов систем управления машин
+ Чаще всего в этих средах есть много готовых библиотек. Это не просто математические или логические операции, и не простые обработчики или фильтры входных и выходных сигналов или драйвера устройств. Это также и целые подсистемы машины, такие как Fan Drive, Dual path, Automotive, Antistall, Antislipping, Constant speed drive и другие, которые требуют только конфигурации со стороны пользователя.
+ Встроенные средства отладки пользовательских алгоритмов и загрузки ПО в контроллер (Service Tool)
+ Встроенные утилиты мониторинга позволяют выполнять диагностику технических систем, разработку и тестирование устройств в полевых условиях
+ Всё вышеперечисленное повышает надежность и сокращает время разработки конечного продукта
+ Модификация кода занимает минимум времени

Минусы:
- Обычно требуется платная лицензия для разработки
- Требуется специфический опыт и дополнительное самостоятельное обучение

Следующий по очереди вопрос - дисплей.

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

Дальше уже переходим к непосредственному решению задачи.

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

Но как показывает практика, на большинстве машин требуются дополнительные системы, которые позволяют этой машине ехать так, как хотелось бы:

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

Как правило у заказчика всё просто: "Мы хотим, чтобы машина ехала на рабочем режиме 25, а на транспортном 40." Можно сказать, что с этого начинается написание технического задания, после чего ты уже садишься с клиентом и вместе с ним пишешь как работает эта машина и в процессе этого анализа вылезает очень много нюансов как одна система влияет на другую, и без знания гидравлики написать техническое задание хорошо очень сложно. Оно будет просто рамочным, а куча проблем будет вылезать уже в процессе работы. Вместе с разработкой алгоритмов подготавливается диагностическая таблица, которая представляет из себя целый лист возможных ошибок. Пропали показания с датчика давления или датчик температуры начал выдавать какие-то неадекватные показания или еще что-то. Этот лист предоставляется заказчику для расстановки уровней ошибок:

• Что для машины является критичным, когда машину нужно срочно остановить
• Что для машины является неприятным, но позволяет работать в аварийном режиме
• Какие ошибки просто выдают информационное сообщение, не приводящее ни к каким ограничениям до определённого момента

И естественно, это все обсуждается в совместном диалоге, потому что с гидравлической точки зрения не всегда заказчик знает, к чему может привести отсутствие показаний например с датчика давления подпитки.