В статье я расскажу историю одной разработки, выполненной небольшим коллективом.
Сначала немного теории о том, что же такое локомотивная система управления и какие функции она выполняет.
Последние несколько лет я занимаюсь проектированием тепловозов, поэтому чаще буду употреблять именно слово «тепловоз», а не «локомотив», мне так привычнее, хотя все сказанное в равной степени относится и к электровозам, и даже к путевой технике с небольшими оговорками. Речь не будет идти о поездах без машиниста, по умолчанию предполагается, что в кабине есть кто-то кто нажимает на кнопки.
Современный тепловоз оснащен целой кучей электронных систем. Но самые главные из них это система управления и система безопасности. Общие требования к ним приведены в ГОСТ 33435-2015. «Устройства управления, контроля и безопасности железнодорожного подвижного состава». Для того чтобы установить систему на тепловоз, а потом еще и продать его на территории Таможенного Союза нужно доказать, что все требования этого ГОСТа выполнены.
Основная задача систем безопасности состоит в том, чтобы не дать технике двигаться, когда не следует. Система управления же определяет как двигаться, т.е. управляет тяговой передачей и частично торможением, а также вспомогательным оборудованием, которого тоже довольно много: компрессорный агрегат, охлаждение, подогрев силовой установки и т.д.
Применяемые в РФ системы управления можно разделить на 2 группы: централизованные и распределенные. Централизованные системы как правило сделаны на основе крейтов, распределенные состоят из отдельных блоков, соединенных цифровым интерфейсом. Оба вида конструктивного исполнения имеют свои плюсы и минусы. В централизованных системах проще обеспечить конструктивные требования для отдельных модулей, распределенные системы упрощают кабельное хозяйство.
По большому счету локомотивная система управления состоит из набора портов ввода-вывода (аналоговых и дискретных), набора преобразователей интерфейсов и HMI-устройств. Порты ввода-вывода используются для управления электрическими аппаратами, получения информации о состоянии контакторов и концевых выключателей, получения данных от различных датчиков. HMI нужен чтобы показать машинисту что происходит с техникой, вывести результаты диагностики. Можно сказать, что это аналог приборной панели в автомобиле, но с заметно большим количеством функций.
Аппаратная часть нашей системы
Изначально решение разрабатывать полностью свою систему было принято не от хорошей жизни. Сразу оговорюсь, что применить какой-нибудь промышленный ПЛК нельзя. Во-первых, это не получится по чисто механическим причинам: вибрации на железнодорожной технике достаточно серьезные, во-вторых у нас присутствует специфический набор датчиков и подыскать под них решение нужно постараться.
Исторически мы натренировались с внедрением покупных систем. С этим связана отдельная категория фейлов. Например, был случай, когда после сборки в тепловоз заливается ПО, согласованной с поставщиком версии до этого нормально работавшее на полусотне машин и один из блоков системы управления внезапно превращается в кирпич. Звоним поставщику и оказывается, что они внесли изменения в аппаратную часть и новый внешне такой же блок со старой программой не совместим. Нам об этом сказать конечно же забыли. Что там поменялось и зачем тайна за семью печатями.
На просьбу внести определенные изменения наоборот легко получить ответ в стиле «Мы сейчас не можем поправить, все инженеры заняты, приходите через полгода-год, ну и заказчиков своих попросите потерпеть».
Так что первая идея была в том, чтобы купить готовую систему управления и зашить туда собственноручно разработанное ПО. На одном объекте так и сделали. Но здесь тоже не обошлось без проблем. Полноценную документацию нам никто не передал, поэтому для реализации обновления прошивки блоков через цифровой интерфейс, пришлось пару недель посидеть с дизассемблером, мучая штатный загрузчик.
Вторая засада состояла в возможностях покупной системы. Для стыковки с новым оборудованием производительности явно не хватало, а нужный нам интерфейс CAN просто отсутствовал. Попытались договориться с поставщиком, но после нескольких совещаний стало понятно, что это бесперспективно. Пришлось сесть за разработку.
Изготовление железа для установки на тепловоз в итоге делал тот же завод что и покупную часть системы управления, они же упаковали наши платы в свой стандартный корпус. Мы сделали стенд для полуавтоматической проверки прибора и проблем с производством не испытывали. Разводку USB естественно поправили, корпус сделали стальным. В корпусе 2 идентичных платы, работает горячее резервирование. Да, USB тут используется только для первоначальной заливки программы.
Опыт был признан удачным, немногим менее 30 устройств работают несколько лет и ни одно не вышло из строя.
Было очевидно, что для нашего следующего (то есть уже текущего) проекта готового решения нам подобрать не удастся и мы начали разработку полностью своей системы управления.
Основной наш заказчик компания государственная и первоначально была идея заложить отечественные «гражданские» компоненты там, где это возможно, хотя формального требования такого и нет. После некоторой проработки стало понятно, что наших потребностей это в любом случае не покрывает, а в себестоимости и надежности мы можем потерять. Сроки также никто не отменял и не сдвигал, так что было решено оставить один из основных компонентов отечественным, а конкретно микроконтроллер К1986ВЕ1QI.
Его возможностей по большому счету хватает, мы используем 2xCAN, Ethernet, 2xSPI, UART, внешнее ОЗУ, часы реального времени. Здорово было бы иметь QSPI и квадратурные энкодеры, но чего нет - того нет. При отладке оказалось, что К1986ВЕ1QI хорошо так греется, особенно при работе Ethernet-PHY контроллера, так что пришлось снизить частоту работы ядра. Температура конечно за допустимые пределы не выходила, но лишний нагрев на работе электроники хорошо не сказывается.
Сейчас уже к сожалению, нельзя сказать, что отечественный микроконтроллер дает преимущества при выборе системы управления заказчиком. Да и в целом технические характеристики в этом процессе не особо рассматриваются.
Для первого внедрения системы были выбраны две новые серии тепловозов. Их разработка шла параллельно разработке системы, так что сроки были вполне ясны и задержать выпуск системы и тем самым сорвать выпуск тепловоза мягко говоря вариантов не было. Был сформирован необходимый минимальный функционал блоков системы, параллельно мы выполняли поиск наиболее оптимальных конструктивных решений, подбирались габариты устройств.
В итоге решили разработать блоки пяти типов, которые закрывали наши потребности на проекте. Все блоки имеют схожий обвес микроконтроллера, схемотехнику главных источников питания и интерфейса CAN. Исходя из выбранных габаритов родилось следующее техническое решение: реализация портов ввода-вывода выносится на отдельные модули, которые шлейфами соединяются с платой, на которой расположен источник питания и микроконтроллер. Это дало возможность сэкономить занимаемый объем, а в дальнейшем расширять функционал системы без необходимости полноценной разработки новых устройств.
Блоки системы объединены единой дублированной сетью CAN. Узлы поддерживают ретрансляцию сообщений в случае повреждения любого участка. Таким образом система остается работоспособной даже если каждая из линий CAN по отдельности неисправна. На одном из локомотивов сеть CAN состоит из 35 узлов, работают на скорости 250 кбит/с, при текущей загрузке ~50% потерь пакетов мы не наблюдали.
На макетках мы проверили схемотехнику, провели значительную часть отладки программ. Но глобальных изменений при переходе к серийным образцам у нас не было. Случилась некоторая оптимизация перечня элементов, немного изменились разъемы.
Дальше нужно было запускать заводское производство. Изготовителя нашли у себя в городе, тогда это было самым простым решением, потому как контроль перед покрытием плат лаком мы делали сами, все-таки партия не сказать, чтоб большая, пара сотен плат.
Первую партию плат мы вручную покрыли дополнительным слоем лака. Для этого мы вдвоем с коллегой в пустующем на выходных офисе оккупировали свободный кабинет.
Мы заранее не обговаривали цвет маски текстолита, синие платы были небольшим приятным сюрпризом, смотрятся неплохо. А новая партия системы изготовлена с платами черного цвета.
Программная часть системы
Для программирования контроллеров К1986ВЕ1QI мы использовали связку GCC и CMake. Среди прочих плюсов это давало возможность каждому разработчику самостоятельно выбирать среду разработки и отладки. Но на практике использовался Qt Creator.
Надо сказать, что официальной поддержки GCC для выбранного микроконтроллера не заявлено и мы взяли стандартную библиотеку из неофициального репозитория на GitHub, ссылка на который была на сайте Миландра. На начальном этапе полезным было чтение миландровского форума, ну и естественно перечитывание спецификации и errata, благо их не забывают обновлять.
Во всех разработанных блоках системы применен порт FreeRTOS со статическим распределением памяти. Там, где это возможно соблюдаются правила MISRA C. Пожалуй наиболее трудоемким было написание собственного стека CANOpen с реализацией дополнительного функционала, требуемого для максимально быстрой реакции системы при возникновении нештатных ситуаций.
HMI
Для вывода машинисту информации о работе оборудования тепловоза как правило используется полноценный панельный ПК железнодорожного исполнения. Есть несколько известных европейских производителей, поставляющих устройства на рынок РФ, есть производство и внутри России, а зачастую разработчик системы управления сам проектирует необходимое устройство под свои потребности. На момент начала разработки мы не могли договориться о поставках. Или цена была заоблачной или характеристики нас не устраивали. Выручил один тайваньский производитель электроники. После рядового разговора на Экспо 1520 со мной связались и оказалось, что они готовят серию устройств для применения на ЖД, мы стали одними из первых покупателей и на отладочный стенд получили предсерийный образец.
HMI у нас реализован на базе Qt: интерфейс написан на QML, обработка данных С++. Мы опасались, что управление интерфейсом через тачскрин будет воспринято в штыки. Есть такой стереотип, что у машиниста тепловоза вечно руки в масле, работать будет плохо. Поэтому основные функции продублированы физическими кнопками по периметру монитора. В реальности управление через свайпы оказалось настолько удачным, что о кнопках вспоминают редко.
Интерфейс выполнен конфигурируемым: важные для него параметры машинист может вывести в виде стрелочных индикаторов, но можно и посмотреть все данные в числовом виде.
Что дальше
Недавно мы получили декларации соответствия на наше программное обеспечение и систему управления. В ближайшие несколько месяцев мы должны будем внедрить систему управления на еще одну серию тепловозов, разрабатываются 4 новых типа блоков, с ними в обозримом будущем аппаратные потребности будут закрыты. Параллельно идет запуск системы в серийное производство, т.к. после получения сертификатов на тепловозы требуемый объем поставок существенно вырастет.
Автор: kasba
