Функций ЦБУЭ. 
Разработка мультиплексной системы управления электрооборудованием автомобиля КАМАЗ-5490 с использованием контроллера

Программные языки создания ПО блока удовлетворяют требованиям стандарта IEC 61 131−3, базируясь на методах усовершенствования техники программирования, повышающих качество ПО, снижающий затраты на обслуживание и ускоряющих процесс разработки.

Внедрение международного стандарта IEC 61 131−3 создало базу для стандартизированного подхода к созданию ПО с использованием современных концепций программирования. Стандарт подразумевает структурированность, возможность повторного использования и простоту обслуживания ПО в течение его жизненного цикла.

Главной задачей ПО — собрать данные с входных каналов, обработать их по заданному алгоритму и задать значения выходным каналом.

Среда разработки ПО После генерирования и тестирования ПО конвертируется и компилируется в машинный код. Затем это ПО загружается из ПК в блок по К-линии или CAN. Это обеспечивает быстрое и легкое прикладное конечное программирование.

Максимальная скорость загрузки в блок 115 кБод по К-линии или 250/500 кБод через CAN.

Базовая программная система.

Базовая система состоит из нескольких модулей, некоторые из них:

• · Операционная система (Совместима с OSEK/VDX Ver 2.2).
• · Система диагностики (поддерживает стандартные диагностические сообщения протокола KWP 2000, передаваемые по К-линии или CAN).
• · Программное ядро (выполняет алгоритмы, созданные потребителем).
• · Интерфейсы с другими устройствами (позволяет блоку управлять другими устройствами).

Прикладные алгоритмы.

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

Системное поведение Блок имеет 3 системных состояния: рабочее, неактивное, базовое.

В рабочем состоянии все программы полностью выполняются. Низкоуровневые драйверы активны, и прикладное ПО периодически запускается (рисунок 2.6). Оно же отвечает за управлением этим состоянием. Это выполняется с помощью сигнала PlcHold. Пока этот сигнал активен, система остается в рабочем состоянии.

Если сигнал PlcHold деактивируется, то блок переходит внеактивное состояние. В неактивном состояние вычисления останавливаются, чтобы уменьшить энергопотребление. Поэтому в этом состоянии все выходы отключаются. Неактивное состояние продолжается до тех пор, пока не возникает событие пробуждения. Блок переходит в рабочее состояние. Этот переход называется включением.

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

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

Время запуска.

Время запуска вклюяает время перехода из неактивного режима в рабочий плюс первый проход прикладного ПО.

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

Максимальное время запуска составляет 1000 мс.

Время пробуждения.

Время пробуждения — промежуток, потребный для перехода из неактивного состояния в рабочее плюс первый проход прикладного ПО.

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

CAN общего назначения Чтобы дать потребителю возможность задавать сообщения CAN без изменения типа ресурса, реализован не специализированный объект CAN общего назначения «Generic CAN Objects». Это позволяет пользователю создать свои сообщения CAN с помощью среды разработки.

Для сообщения CAN можно задать:

• · Идентификатор CAN
• · Код длины данных
• · Время цикла
• · Данные сообщения

В прикладном ПО доступ к данным сообщениям выполняется точно так же, как и для фиксированных сообщений CAN. Сообщения появляются в списке сигналов ПО.

В ПО блока имеется возможность программно запускать и останавливать передачу каждого сообщения. Также возможно запускать и останавливать прием сообщений. Отслеживание таймаута при приеме сообщений начинается с момента запуска приема.

Прием пользовательских сообщений не должен генерировать более 10% трафика по шине CAN (чтобы избежать влияние на цикловое время ПО блока).

Передача пользовательских сообщений не должен генерировать более 5% трафика по шине CAN (чтобы избежать влияние на цикловое время ПО блока).

Пользовательские сообщения поддерживаются интерфейсы I-CAN и P-CAN.

CAN транслятор Транслятор CAN поддерживает ретрансляцию сообщений от одного интерфейса CAN другому. Транслятор прозрачен, что означает, что адрес источника и другие данные сообщения остаются не измены. Транслятор работает подобно мосту, определенному в J1939.81.

Сообщения определяются своим задаваемым 29 битным идентификатором. Все определенные сообщения транслируются независимо от их приоритета.

Трансляторы управляются ПО блока. ПО должно включить трансляцию сообщений CAN. Когда блок не функционирует (неактивное состояние), трансляторы также не функционируют.

Транслирование выполняется базовым системным ПО, которое поддерживает потребительские ресурсы и не входит в прикладное ПО. Принимаемые узлом приема сообщений ставится в очередь на отсылку на узле передачи. Никакой сортировки (например, по приоритету) не производится.

Диагностика.

— Диагностическая информация, ассоциированная с входами и выходами.

На каждый сигнал в прикладном ПО предусмотрен соответствующий диагностический сигнал.

Тип данных для диагностического сигнала WORD.

Для диагностических сигналов предусмотрено единое битовое кодировка. В зависимости от входа диагностического сигнала некоторые биты не используются. Это означает, что они некогда не выставляются.

Если ошибка не может быть охарактеризовано однозначно, несколько битов выставляются однозначно.

Если выявлена ошибка, состояние сигнала остается неизменным, и выставляются соответствующие биты его диагностического сигнала. Последнее корректное значение сигнала доступно для прикладного ПО.

— Стендовая диагностика.

Диагностика на стационарном стенде выполняется по протоколу «KWP2000» по К-линии или по интерфейсу PCAN. Поддерживается механизм, определенный в стандарте ASAM. Возможна только одна сессия между диагностическим инструментом и ЭБУ. Все ЭБУ, подключаются к интерфейсу CAN, по которому выполняется программирование, должно поддерживать режим DM13 (уменьшение загрузки шины при программирование).

Диагностический инструмент посылает сообщение о начале и завершение диагностической сессии однократно. Прикладное ПО может быть остановлено во время программирования.

Одновременно блок поддерживает одну диагностическую сеть.

— Диагностический доступ к сигналам ПО.

Существуют 2 метода для диагностического доступа к сигналам ПО. Оба могут быть использованы для доступа к сигналам ввода — вывода, а также к диагностическим сигналам.

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

Второй метод предлагает использование диагностического сервиса Read/WriteDataByIdentifier.

Этот метод имеет то преимущество, что доступ к сигналам осуществляется по фиксированным идентификаторам. Это полезно, когда тестер не может интерпретировать информацию ASAM и должен изменить физический адрес, когда поступает новая версия ПО.

Если тестер хочет проконтролировать выходные сигналы, то перед этим выполнением прикладного ПО должно быть остановлено (диагностическим сервисом).

Сохранение ошибок Каждая запись об ошибке содержит диагностический код и дополнительный набор данных.

В памяти может быть сохранено 15 записей.

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

Для доступа к памяти ошибок существует набор стендовых диагностических сервисов.

Это диагностический интерфейс предусматривает:

• · Получение количества сохраненных ошибок.
• · Получение полного списка сохраненных ошибок.
• · Чтение дополнительной информации по каждой ошибке.
• · Удаление всех сохраненных ошибок сразу.
• · Диагностический код ошибки

Каждая ячейка в памяти называется диагностическим кодом ошибки (`Diagnostic Trouble Code' (DTC)) и включает дополнительную информацию (Freeze Frame Data).

Каждый код состоит из следующих полей предусмотренных прикладным ПО:

• · Номер подозреваемого параметра, 19 бит (Suspect Parameter number (SPN)).
• · Идентификатор режима неисправности, 5 бит (Failure Mode Identification (FMI)).
• · Приоритет, 8 бит.

Системой предусмотрено добавочная информация:

• · Счетчик возникновения, 7 бит (Occurrence Counter (OC)).
• · Статус кода, 1 бит (активен/ был активен).
• — Механизм записи

При первом возникновении ошибки код и дополнительная информация записываются в память, а счетчику присваивается значение 1. Если та же ошибка возникает снова, увеличивается только счетчик.

Ошибки с одинаковыми номерами параметра и идентификаторами режима считаются одинаковыми, даже если обладают разными приоритетами. В этом случае увеличивается только счетчик.

Статус кода устанавливается в «активный» с возрастающим фронтом сигнала на соответствующим входе блока. Статус устанавливается «был активен» с падающим фронтом сигнала на входе.

При включение все статусы устанавливаются «был активен». Если ошибка была активна при выключении и активна также и при включении, то она обрабатывается как новая. Т. е.увеличивается значение счетчика.

Максимальное значение счетчика равно 126. Если количество ошибок превышает эту границу, то значение остается равным максимальному.

Каждый код ошибок защищается контрольной суммой.

Рабочая копия памяти, содержит ошибки, располагающиеся в ОЗУ.

При включение содержимое EEPROM копируется в ОЗУ.

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

При выключения режима изменившийся код записываются обратно в EEPROM.

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

Центральное хранилище ошибок Активные ошибки из списка ЭБУ, подключенные к блоку PCAN, записываются в центральное хранилище неисправностей (Vehicle Error Memory, VEM). Хранилище располагается в ОЗУ и удаляется в момент запуска системы.

Могут быть заданы до 5 внешних ЭБУ:

• · Коды до 5 внешних ЭБУ могут быть сохранены.
• · Для каждой системы (ЭБУ) до 15 кодов может быть сохранено.
• · Номер параметра и идентификатор режима вместе взятые являются идентификатором кода.
• · Как только блок посылает сигнал, флаг ожидания («Pending») этого блока становится активным.
• · Каждая новая комбинация номера параметра и идентификатора режима записывается в свою ячейку. Ячейки не перезаписываются, поэтому, когда хранилище заполнено, все ячейки остаются неизменными.
• · Флаг ожидания («SPN/FMI Pending») устанавливается, как только код передается внутри сообщения.

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

• · Чтение ожидающейся информации об ошибке для каждой системы.
• · Чтение всех записанных кодов ошибок для каждой системы.
• · Обнуление всех записанных кодов ошибок для каждой системы.
• · Чтение ожидающейся информации об ошибке для всех систем в целом.
• · Чтение всех записанных кодов ошибок для всех систем в целом.
• · Обнуление всех записанных кодов ошибок для всех систем в целом.

Конфигурация хранилища задается с помощью среды разработки.

Кроме того, в прикладном ПО можно сохранить информацию со следующими полями: адрес источника, номер параметра и идентификатор режима.

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

Передача сообщений DM1.

Сообщение DM1 передается согласно 4му методу преобразований SPN, описанного в SAEJ1939/73.

Количество кодов ошибок, которое передается в сообщение DM1, ограничено 10. Если кодов больше, то пересылаются те, у которых выше приоритет.

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

Если код, передаваемый в сообщение DM1, помещается в хранилище, то значение счетчика берется оттуда. В противном случае счетчик равен 1.

Код статуса и мигание ламп устанавливается также на внешнем модуле. Информация о лампах, посылаемая в сообщении DM1, отражает логически сложное (OR) значения величин, принадлежащих каждому из кодов ошибки, содержащихся в сообщении DM1.

Пока имеются активные ошибки, сообщение DM1 посылается ежесекундно.

Как только появляется новая ошибка, сообщение DM1 посылается исходя из того, что её приоритет достаточен для того, чтобы поместить её в сообщение DM1. Если ошибка активна 1 с и больше, а затем становиться не активной, то сообщение DM1 посылается.

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

Когда последняя ошибка становится неактивной, посылается сообщение DM1, оповещение о том, что активных ошибок больше нет.

Передача сообщений DM1 выполняется через ICAN.

Самодиагностика Чтобы поддержать аппаратную функциональность ограниченного режима (limp home), реализовано несколько программных функций внутреннего слежения (мониторинга).

— Безопасное состояние.

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

— Сторож (Watchdog).

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

— Супервизор часов.

В микроконтроллерных системах, работа которых отслеживается внутренними супервизорами, есть риск не исправности часов. в таком случае микроконтроллер останавливает любую активность, в том числе работу супервизоров (фактически повисает).

Поэтому микроконтроллер снабжен супервизором часов.

Он используется, чтобы отслеживать работу внешнего часового (главного) генератора импульсов. В случае, если внешний генератор не исправен, он подменяется внутренним (RC-oscillator) с меньшей частотой для ограниченного режима и запускается перезагрузка.

Если запускающийся код определяет, что перезагрузка была вызвана неисправностью часов, то блок переводит в безопасное состояние.

— Обработчик исключений.

Обработчик исключений — это центральная функция для обработки отказов и неисправностей программной части или ОС (например, несуществующая команда или неправильный код) и сохранение их для анализа. Кроме того в обработчике предусматривается необходимая реакция (например, программная перезагрузка).

Если запускающийся код определяется, что перезагрузка была вызвано программно, то блок переводит в безопасное состояние.

— Целостность системы.

После включения питания контрольные числа целостности ПЗУ проверяются относительно друг друга. ПО блок запускается, только если все области ПЗУ исправны.

В противном случае система остается в режиме программирования ПЗУ.

— Отслеживания предельного времени (deadline).

Для повышения надежности существует функция отслеживания предельного времени. Она состоит из двух частей: обратной связи при инициализации/завершение и отслеживание запросов на ресурсы.

— Обратная связь при инициализации/завершение.

Обработчик центрального состояния запускает обратный отсчет при каждом запросе инициализации или завершение. Если инициализации/завершение не закончились до окончания обратного отсчета, генерируется исключение.

— Отслеживание запроса на ресурсы.

Если ресурс был затребован, но не освобожден, то система не сможет нормально завершить работу.

— Самоконтроль внутренних областей ПЗУ.

Самоконтроль ПЗУ различает 2 типа памяти: где записан исполняемый код (например, прикладное и системное ПО) и где записаны данные, не являющиеся исполняемым кодом (например, ASAM).

Контролируются только области, защищенные собственной циклической контрольной суммой.

— Самоконтроль исполняемого кода.

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

Если не возможно полностью выполнить проверку хотя бы один раз, пока система находится в рабочем состоянии, то проверка продолжается при следующем старте системы.

— Самоконтроль данных.

Если тестером затребована выгрузка данных, то проверяется их циклическая контрольная сумма. Если контрольная сумма не верна, то выгрузка завершается с отрицательным кодом ошибки.

Производительность системы Базовое ПО блока CBCU3 работает в цикле 20 мс. В конце этого цикла драйверы оборудования поставляют заданные сигналы на выходах. Цикл базового ПО и старт прикладного ПО синхронизированы. Поэтому, если прикладное ПО отрабатывает менее, чем за 15 мс, значение выходных сигналов записывается оборудованием в том же базовом цикле.

Прикладное ПО блока CBCU3 может быть реализована как единая задача.

Относительно работы прикладного ПО приняты следующие допущения:

• · Длительность цикла (период работы прикладной задачи) равно 20 мс.
• · Время работы менее, чем 15 мс.

С учетом этих допущений время отклика CBCU3-Е приведена в таблице 2.2.

Таблица 2.2. Время отклика CBCU3-Е.