По этим причинам разработка и стандартизация протоколов высоких уровней важна для будущего автомобильной промышленности.
Протоколы высоких уровней должны обеспечивать:
- надежные и эффективные процедуры обмена длинными последовательностями данных;
- независимость программного обеспечения приложений от конфигурации сети и оборудования;
- удобство интерфейса для программиста.
Семиуровневая модель ВОС хорошо подходит для больших компьютеров и сетей, где нет необходимости для коммуникаций в реальном времени. Для автомобилей эта модель упрощается до двух верхних уровней — прикладного и транспортного, как показано на рис. 6.17. Прикладной уровень обеспечивает интерфейс для программиста, решает задачу по получению и посылке данных, необходимых при управлении различными системами автомобиля. На транспортном уровне осуществляется разборка и сборка пакетов. Блок управления сетью и узлами производит контроль сети и узлов, обнаруживает неисправности, активизирует сеть или переводит се в неактивный режим. Этот блок взаимодействует непосредственно со всеми уровнями сетевой модели и с приложением.
Рис. 6.17. Упрощенная модель ВОС
Транспортный уровень
Транспортный уровень должен обеспечивать передачу произвольно длинных сообщений между объектами прикладных уровней.
Если длина сообщения превышает размер кадра, передаваемого по коммуникационной шине, сообщение разделяется на несколько пакетов. Сообщение передается с прикладного уровня на транспортный, где разделяется на сегменты, соответствующие размеру одного кадра. К каждому кадру транспортный уровень добавляет свою управляющую информацию протокола (PCI — protocol control information). Управляющая информация используется транспортным уровнем на принимающей стороне для восстановления исходного сообщения и передачи его принимающему прикладному уровню.
Управляющая информация протокола содержит сведения о числе кадров в исходном сообщении, номере текущего кадра в сообщении, она необходима для обнаружения и исправления ошибок типа пропуска или дублирования кадра.
Управляющая информация протоколов высокого уровня обычно размещается в поле данных кадра низкого уровня (рис. 6.18, а). В автомобильных мультиплексных системах иногда управляющая информация протокола размещается в управляющем (арбитражном) поле кадра низкого уровня (рис. 6.18, б). Эта технология делает мультиплексную систему более быстродействующей, но увеличивает зависимость от протоколов низкого уровня и применяемой аппаратуры.
Рис. 6.18. Размещение PCI в кадре
Механизм управления потоком сообщений (трафиком) включает использование двух видов подтверждений:
- положительное подтверждение АСК (сокращение от acknowledge);
- отрицательное подтверждение NACK (сокращение от negative acknowledge).
Положительное подтверждение сигнализирует передатчику, что сообщение или кадр были приняты правильно и приемник готов принять следующий кадр. Положительное подтверждение необходимо, когда передатчику не известна скорость приема сообщений приемником. Положительное подтверждение может быть, например, использовано для синхронизации передачи данных между быстродействующей и медленной шиной без буферирования. В этом случае скорость обмена определяется возможностями медленной шины.
В сети могут быть реализованы режимы, когда приемник квитирует (подтверждает) каждый принятый кадр (рис. 6.19) или блок кадров (рис. 6.20), что более эффективно в смысле быстродействия мультиплексной системы.
Рис. 6.19. Квитирование каждого кадра
Рис. 6.20. Квитирование блока кадров
Отрицательное подтверждение выдается приемником в сеть, когда что-то происходит неправильно. Режим работы с отрицательным подтверждением может увеличить быстродействие сети, так как при отсутствии ошибок число кадров, передаваемых от передатчика к приемнику, а следовательно, и время их передачи уменьшается (рис. 6.21).
Рис. 6.21. Передача сигнала NACK
На практике могут использоваться различные комбинации механизмов управления передачей данных в сети.
И приемник, и передатчик могут иметь средства для обнаружения и исправления ошибок. Примеры ошибок, которые могут быть выявлены:
- приемник не получил кадр в установленное время;
- приемник получил некорректный кадр, например, не с тем номером;
- приемник не закончил обработку полученного кадра, но готов получить следующий кадр;
- передатчик не получил положительное подтверждение в установленное время.
Когда передающий объект на транспортном уровне обнаруживает ошибку, он может поступить следующим образом:
- повторить передачу кадра;
- повторить передачу всего сообщения;
- прекратить передачу и предоставить дальнейшие действия приложению.
При проектировании транспортного уровня возникает проблема буферизации сообщений. Для получения сколь угодно больших сообщений от прикладного уровня следует иметь сколь угодно большой буфер (оперативную память) на транспортном уровне, что невозможно. На практике размер сообщений разумно ограничивается буферированием, что увеличивает возможности мультиплексной системы работать в реальном времени.
Прикладной уровень
Прикладной уровень является необходимой платформой для создания приложений. Он скрывает детали аппаратуры и сетевой конфигурации. На прикладном уровне создание приложений для мультиплексных и централизованных систем мало чем отличается. Приложение использует данные в пределах прикладного уровня и для него безразлично, локальные это данные или получены по коммуникационной шине.
На прикладном уровне форматируется кадр со следующими данными из приложения:
- имя кадра и его идентификатор;
- место размещения переменных (параметров) в кадре;
- формат представления параметров;
- единица измерения параметра;
- допустимый диапазон значений;
- разрешающая способность;
- формула, преобразующая числовое значение в кадре (N) в значение, имеющее физический смысл (Е).
В табл. 6.1 приведен пример кадра:
Таблица 6.1
| Имя кадра | Температура |
| Идентификатор | 40hex |
| Название переменной | Забортная температура |
| Размещение | Байты 0 и 1 |
| Формат | 16-битовый |
| Единица измерения | °C |
| Диапазон | -40...+50 |
| Разрешение | 0,1 |
| Формула | N = (Е + 40) · 10 |
При декодировании кадра данных требуется определить, допустимо ли полученное значение параметра или нет (например, при неисправности датчика). Это делается или путем добавления в кадр специального поля, фиксирующего досто-верность/недостоверность значений параметров, или непосредственным анализом текущих значений параметров на принимающей стороне.
На прикладном уровне определяется, когда сообщение должно быть отправлено или принято. Отправка производится по времени или в результате обработки события. Событием может быть: изменение состояния датчика, значение, вышедшее за заданный предел; запрос от другого узла и т.д. Передача по времени ведется для параметров, которые должны быть доступны всей мультиплексной системе. Такие переменные делят на группы с различной требуемой скоростью обновления и передачи значений.
При приеме сообщений на прикладном уровне сообщение распаковывается в соответствии с принятым форматом кадра, и данные передаются активному приложению.
На прикладном уровне могут быть реализованы несколько моделей взаимодействия между узлами. В модели с общей памятью обмен информацией производится за счет операций записи и чтения. Данные сразу же становятся доступными для всех участвующих процессов. В мультиплексной системе никакой общей памяти физически не существует, она создается программным обеспечением прикладного уровня.
В модели «клиент — сервер» взаимодействие между процессами осуществляется способом, когда какой-либо процесс (сервер) способен выполнять операции но запросу другого процесса (клиента), размещенного в другом узле. Например, при диагностике сканер посылает по сети запрос ЭБУ и получает в ответ значения параметров или коды ошибок.
Управление сетью (диспетчеризация)
Назначение управления (диспетчеризации) сети — поддерживать се корректную (штатную) работу. При этом должны производиться обработка ошибок, контроль конфигурации сети и правильности ее работы, ограничение доступа и обеспечение сохранности информации в сети. Для автомобильных систем наиболее важными являются обработка ошибок и контроль конфигурации.
От правильности реализации диспетчерских функций зависит способность сети противостоять отказам. Диспетчеризация осуществляется на локальном и сетевом уровнях.
Локальная диспетчеризация осуществляется на уровне узлов. Производится конфигурирование и инициализация узлов, управление уровнями на уровне узла, обнаружение неисправностей и ошибок. Для локального диспетчера нет необходимости посылать какие-либо сообщения по сети. При включении узла локальный диспетчер конфигурирует канальный уровень, например, в микросхеме CAN. После обнаружения неисправности диспетчер пытается перезапустить и реконфигурировать канальный уровень. Перезапуск производится по различным алгоритмам, как показано на рис. 6.22.
Рис. 6.22. Алгоритмы перезапуска шины CAN
Диспетчеризация на сетевом уровне обеспечивает:
- определение и контроль конфигурации сети;
- включение сети;
- переход от неактивного к активному режиму и обратно.
Диспетчеризация производится централизованно или децентрализованно. При централизованном подходе один узел выполняет функции диспетчера сети. Для повышения надежности системы должен быть предусмотрен механизм передачи диспетчерских функций другому узлу при отказе первого. При централизованном подходе требуется меньше ресурсов, чем при децентрализованном.
При децентрализованном подходе каждый узел снабжен набором диспетчерских функций. Узлы постоянно обмениваются специализированной диспетчерской информацией. Сеть оказывается способной продолжать работу, с меньшими возможностями, даже при отказе нескольких узлов.
Конфигурация сети может изменяться в зависимости от нужд конкретного приложения. В этом случае узлы выполняют разные задачи в зависимости от конфигурации сети. Имеются концепции, когда программное обеспечение для элементов мультиплексной системы с указанием конфигурации загружается с одного из узлов при инициализации сети. Полагают, что это путь к сокращению числа типов ЭБУ.
При выходе из строя одного из узлов теряется информация, поступающая с него. Приложение должно сгенерировать утраченные данные самостоятельно, используя аварийные значения.