Как это — быть разработчиком ПО для автомобилей. Часть 2/2

Автор оригинала: Viktor Schepik
  • Перевод
В первой части серии мы приступили к разработке системы с сервоприводом, по крайней мере, мысленно. Я показал модель системы, на которой прекрасно видны все элементы и связи между ними.

image

Так как же соединяются части нашей системы? Благодаря протоколу FlexRay с электронным блоком управления (ECU) руль связан с датчиком положения. В отличие от обычного датчика, который регулирует напряжение в зависимости от температуры, умный датчик прекрасно взаимодействует напрямую с FlexRay.

В современных автомобилях, как правило, применяют два вида сетевых технологий: CAN и FlexRay. FlexRay — преемник CAN. Главное преимущество FlexRay в том, что можно точно определить момент передачи определенного сигнала, то есть протокол детерминирован. С помощью данной сети отдельные системы автомобиля, будь то тормозная, рулевая или другие блоки умных датчиков, непрерывно обмениваются необходимой информацией, что гарантирует бесперебойную работу авто.

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

image

Итак, датчик поворота руля должен отправить текущие показатели, когда на очереди соответствующий слот, ни секундой раньше или позже. Поскольку стандартное время отправки данных — 10 миллисекунд, на диаграмме выше пришлось сильно преувеличить возможное изменение положение руля. Да и водитель не сможет так быстро повернуть руль на 5°. Но для наглядности будем придерживаться этого примера.

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

image
Датчик положения – FlexRay — контроллер FlexRay – Процессор – ШИМ – Передача -Рулевая рейка

Вы, возможно, обратили внимание на незнакомый блок ШИМ. Это широтно-импульсная модуляция (ШИМ), позволяющая регулировать подачу тока на усилитель мощности – он же отвечает за питание двигателя. Но что такое ШИМ?

ШИМ — широтно-импульсная модуляция, отличный способ контроля за питанием различных электрических устройств. Другими словами, вы регулируете соотношение электричества и максимальной мощности, где 0% — отсутствие мощности и 100% — полная мощность, которую усилитель мощности обеспечивает двигателю. И, как всегда, более подробную информацию вы можете найти в Википедии:

image

Широтно-импульсная модуляция (ШИМ, англ. pulse-width modulation (PWM)) — процесс управления мощностью, подводимой к нагрузке, путём изменения скважности импульсов, при постоянной частоте. Различают аналоговую ШИМ и цифровую ШИМ, двоичную (двухуровневую) ШИМ и троичную (трёхуровневую) ШИМ.

Что происходит, когда водитель поворачивает руль? В определенный момент программное обеспечение, работающее на процессоре, получает информацию о новом положении руля и генерирует значение ШИМ, которое необходимо для запуска двигателя. Он, в свою очередь, перемещает рулевую рейку. В приведенном ниже примере водитель поворачивает руль на 5° (1). Датчик анализирует положение и посылает соответствующее значение по каналу FlexRay (2). Наш контроллер FlexRay получает данные (3), на их основе программа вычисляет подходящие показатели ШИМ (4) и задает их модулю ШИМ микроконтроллера (5). Модуль ШИМ регулирует поток электричества, который, в свою очередь задает мощность двигателя, определяемую усилителем мощности (6). Ток приводит в движение двигатель (7), а он перемещает рулевую рейку (8).

image
Датчик положения-FlexRay- контроллер FlexRay-Процессор-ШИМ-Передача-Рулевая рейка

Теперь вы знаете, что в предыдущем примере задействовано множество различных физических расчетов и элементов. Например, каким-то образом нужно вывести % ШИМ из градуса поворота руля. При этом важно учитывать текущее положение двигателя, потому что только так ясно, в каком направлении и с которой скоростью придется запустить двигатель. Но, к сожалению, это уже тема техники контроля, которую я не планировал освещать в рамках данной статьи.

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

Таким образом, среда программного обеспечения требует ритмичной обработки сигналов. Ритмичность предполагает наличие определенных циклов в работе программы. Вы когда-нибудь рассматривали архитектуру встроенного приложения? Если нет, не пугайтесь. Мы начинаем погружение.

Давайте проанализируем, как можно разделить нашу работающую на процессоре программу с картинки выше (см. иллюстрацию поворота руля). Если вы задумаетесь о задачах компонентов приложения, вы, очевидно, заметите, что мы имеем дело с 3 блоками: один для приема сигнала FlexRay, один для определения значения ШИМ на основе данных FlexRay и один для регулирования итоговой мощности ШИМ. На следующей схеме эти компоненты накладываются на микроконтроллер и вуа-ля, многоуровневая архитектура программного обеспечения готова.

image

«Com» используется для обозначения линий коммуникаций: этот элемент считывает сигнал контроллера FlexRay, входящего в состав микроконтроллера. Он также проверяет корректность передачи сигнала (например, посредством автосуммирования данных) и передает его остальным компонентам программы в виде показателей положения руля. Благодаря умному алгоритму, над созданием которого пришлось потрудиться не один год, элемент «Рулевое управление» принимает это значение и рассчитывает необходимые параметры ШИМ. Я не шучу, на разработку такого алгоритма может уйти море времени, потому что на карту поставлено управление автомобилем. А, значит, нужно учесть массу переменных, актуальных для тех или иных условий вождения. Но вернемся к многоуровневой архитектуре – остался ШИМ. Данный компонент ШИМ считывает полученную информацию о задает итоговую мощность ШИМ микроконтроллера.

И еще пару слов о концепции синхронизации. Новые данные поступают каждый раз, когда FlexRay получает соответствующий сигнал и если это раз в 10 миллисекунд, картина выглядит следующим образом:

image

Получение сигнала FlexRay приводит к запуску 3 взаимозависимых функций или компонентов. Затем определяется итоговая мощность ШИМ. Причем все это повторяется каждые 10 миллисекунд. Вот вам и ритм программного обеспечения.

Получив от программы итоговые значения, рассчитанные на основе исходных данных, получается такая диаграмма:

image

ШИМ рассчитывается и регулируется каждые 10 миллисекунд, а, значит, мы справились с первым этапом. Теперь можно разворачивать машину!

Как вы уже догадались, при таких результатах двигатель явно не будет работать плавно. Так ведь лучше:

image

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


От переводчика:

Пока это второй и последний пост об автомобильном ПО от автора оригинального текста, но я буду внимательно следить за обновлениями в его блоге на Medium.

Спасибо за внимание.
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 15

    +2
    Хотя по профессии я архитектор, разработка программного обеспечения доставляет мне огромное удовольствие

    Через примерно 500 часов эксплуатации (через 15000 пробега) появится люфт в приводе, еще через 500 часов шестерни развалятся.
    Но гораздо раньше водитель уедет в кювет или в бетон, поскольку не почует привычной ему обратной связи между колёсами и рулём.
    Ересь это.
      +1
      Отдельный моторчик прикрутят, для force feedback, как в рулях для автосимуляторов делают. Его кстати можно использовать для автоматического вождения: ткнул на навигаторе в точку, машина сама поехала и рулём крутит, благодать!
        +5
        Теперь у меня вопрос: если есть система, которая без кардинальных изменений работает 100+ лет, почему нельзя прикрутить моторчик к рулю? Отказ моторчика? Не проблема, рулим как 100 лет назад.
        Может это во мне говорит старпёрский инженерный консерватизм, но вообще вся эта концепция (именно та, которая тут описана) вызывает животный страх. Особенно когда я читаю про архитектора.
        Не говоря уже о том, что человек разрабатывает следящий регулятор без всякого упоминания о ТАУ.
          0
          Ну электронная педаль газа довольно давно применяется ведь. Видимо, преимущества перевешивают возможные риски.
          (хотя пример не самый удачный, наверное, если вспомнить недавний случай с Тойотой, убивший то ли 20, то ли 80 человек, да).
            +1
            Да, иногда добавив скорости можно избежать ДТП. И отказ электронной педали газа может привести к аварии. Но такие аварии реже и менее опасны чем те, которые возникнут из-за отказа педали тормоза или руля. Потому и применяются усилители поверх старого доброго прямого управления. Тут и в случае отказа усилителя шансов выкрутиться больше, и обратная связь остаётся, её не надо эмулировать.
            +1
            Более-менее тяжёлые самолеты уже с полвека рулятся только дистанционно (прямой связи ручки с рулевыми элементами оперения нет совсем).
            Дублирование (методологический приём, если так можно выразится), более глубокие тесты при разработке (меньшее копроэкономическое давление, т.к. самолет ещё более "долгоживущий" предмет, чем авто), более широкое тестирование и анализ данных перед выпуском в производство.
            КМК.
              +1
              Более-менее тяжёлые самолеты уже с полвека рулятся только дистанционно (прямой связи ручки с рулевыми элементами оперения нет совсем).
              Вопрос, конечно, что называть «более-менее тяжелыми».

              Те же Boeing 737 (включая NG, которые производятся с 1997 года) — прямое управление + гидравлика (с дублированием).

              Airbus A320 (производится с 1984) был первым fly-by-wire пассажирским самолётом.

              В военном применении оно появилось с 70х, и связано это, в частности, с использованием нестабильных аэродинамических схем, повышением нагрузок и неудовлетворительными характеристиками механических систем управления.
          +2
          Всё в порядке, колёса всегда механически связаны с рулём.
            +5
            Собственно, оба раздела этой статьи о другом подходе.
              +2
              Steer-by-wire системы тоже имеют жёсткую связь с колёсами через нормально замкнутое сцепление.
              +1
              Уже не всегда. Infiniti Q50
                +1
                Там тоже есть механическая связь с колёсами, вот на схеме видно сцепление.

                https://www.infiniti-cdn.net/content/dam/Infiniti/2014/Q50/Performance/EMEA%20Master/36156_INF_Helios_Images_1200x675_EMEA_Q50_02.jpg.ximg.l_6_h.smart.jpg
            +2
            Насчёт "преемника CAN", возможно, преждевременно. Это совсем другая шина и такого массового выпуска устройств, как под CAN, под неё нет. Не факт, что получит такую же популярность, как CAN. Передавать сигналы быстрого регулирования для критических с точки зрения безопасности узлов по общей шине, на которой черт знает что творится, не лучшая идея. Даже со всей помехоустойчивостью технологии. Команды для контроллеров сравнительно медленного управления устройствами передавать, ещё куда ни шло, но с этим и CAN пока справляется. Попытки применить быстрые шины в автомобильных системах управления были и ранее, но пока о широком распространении таких систем ничего не слышно. Да и эта технология разрабатывается уже 16 лет, с 2000 года, и пока что-то никак.
              +1
              И не получит уже, скорее всего. Консорциум распущен в 2009, на смену пытаются прикрутить RT Ethernet, т.к. вышло очень дорого, а некоторые устройства, прекрасно смотревшиеся на бумаге и имевшие прототипы в авиации (Bus Guardian, например), так и не были реализованы, т.к. это оказалось слишком дорого.
                0
                Да, для массового автомобильного рынка стоимость технологии это важно. Военные деньги не так считают, но там другая проблема, всё чересчур зарегулировано и потому запредельно консервативно.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое