Примеры автомобильных мультиплексных систем



Класс А

Системы класса А применяются в основном для упрощения и удешевления электрических соединений между устройствами корпусной электроники. Рассмот­рим для примера противоугонную систему со структурой, показанной на рис. 4.12.

Противоугонная система приводится в дежурный режим контактом 11, а вы­ключается — контактами замков дверей пассажира или водителя или багажника. В рабочем состоянии система включает клаксон 10 при срабатывании одного из контактов: 1, 3, 4, 5, 7, 8. Датчики и исполнительные механизмы в этом варианте подключены непосредственно к блоку управления через мультиплексоры одним проводом. Улучшены диагностические возможности системы.

Рисунок 4.12 – Блок-схема противоугонной системы

1 — контакт двери водителя, 2 — контакт замка двери водителя, 3 — контакт левой задней двери, 4 — контакт на капоте, 5 — контакт двери пассажира, 6 —  контакт замка двери пассажира, 7 — контакт правой задней двери, 8 — контакт на крышке багажника, 9 — контакт замка багажника, 10 — клаксон, 11 — контакт на приборной панели

Рисунок 4.13 – Блок-схема мультиплексной противоугонной системы

 

Легче изменять конфигурацию противоугонной системы, подключая к одной и той же шине через мультиплексоры дополнительные датчики и исполнительные механизмы. Мульти­плексоры — это относительно несложные микроэлектронные устройства, которые содержат до 300 полупроводниковых вентилей. Их интегрируют с датчиками и ис­полнительными механизмами.

То же устройство может быть реализовано в мультиплексном варианте (рис. 4.13).

 

Класс В

 

На рис. 6.14 показана часть типичной информационной системы водителя (ИСВ). Здесь сигналы с датчиков поступают на бортовой компьютер, к шине дан­ных которого подключена комбинация приборов.

Рисунок 4.14 – Блок-схема информационной системы водителя

 

В упрощенном варианте ИСВ число проводов в жгуте не слишком велико, что оправдывает данную схему соединений. Однако, по мере усложнения электронно­го оборудования автомобиля и увеличения числа функций информационной сис­темы, количество соединительных проводов резко возрастает, усложняется диа­гностика неисправностей. Возможным решением в таком случае является введе­ние нескольких узлов, соединенных с шиной класса В, к которым подключаются соответствующие датчики. При этом стараются уменьшить размеры жгутов, про­ходящих через узкие места типа «дверца — корпус». К стоимости проводки добав­ляется стоимость узлов.

На рис. 4.15 приведена блок-схема ИВС с шиной класса В, на котором цифра­ми обозначены сигналы датчиков.

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

Рисунок 4.15 – Блок-схема информационной системы водителя с шиной класса В

1 — уровень охладителя, 2 — давление тормозной жидкости, 3 — уровень масла, 4 — масло в коробке передач, 5 — омывающая жидкость, 6 — капот не закрыт, 7 — фары включены, 8 — мало топлива в баке, 9 — стеклоочистители включены, 10 — ключ в замке зажигания, 11 — привязные ремни, 12 — ручка двери, 13 — замок, 14 — дверь закрыта, 15 — дверь не заперта

 

Узел двери лучше располагать в двери, тогда жгут через промежуток упрощает­ся, желательна также интеграция электронных и механических устройств в двери. Структурная схема электронной части устройств двери показана на рис. 4.16.

Общие замечания по применению узлов.

1.Для снижения стоимости узлы выполняются на базе специализированных микросхем.

2.Единая конструкция возможна при использовании микропроцессоров в уз­лах.

3. Комбинация «обычный датчик — мультиплексный узел» не облегчает диа­гностику датчиков. Нельзя определить, что именно неисправно — датчик или проводка.

Рисунок 4.16 – Подключение устройств двери

 

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

Такая конфигурация системы позволяет вводить дополнительные датчики и исполнительные устройства. Теперь к бортовому компьютеру на один исполните­льный механизм можно подключать 7—14 датчиков.

 

Класс С

 

Все большую популярность завоевывает протокол CAN, с применением которо­го мультиплексные системы класса С могут реализовываться в следующих формах:

1. Через одну и ту же сеть класса С производится обмен данными как для при­ложений, работающих в реальном времени (управление двигателем, подвеской, передачами), так и для приложений, обслуживающих бортовой компьютер, контроль климата салона, приборную панель. Скорость обмена до 1 Мбит/сек, линия связи — коаксиальный или оптический кабель.

2. Гибридная сеть класса В и С. Производится обмен данными между узлами скоростной сети класса С и относительно медленной сети класса В. Шлюзом обычно бывает контроллер двигателя.

3. Интеграция функций управления в реальном времени в наименьшее число модулей. Например, ЭБУ двигателя может управлять еще и трансмиссией. При такой архитектуре необходимость в дорогостоящих сетях класса С сводится к ми­нимуму.

 

Протоколы высоких уровней

Термин «протоколы высоких уровней» обычно относят к уровням 3—7 модели ВОС. На этих уровнях решаются вопросы представления данных, упаковки длин­ных сообщений, стандартизации приложений и т. д. Когда функции приложения распределены между несколькими электронными блоками управления, необходи­ма максимальная независимость программного обеспечения приложения от лока­лизации функций. Уже сегодня автомобильные средства связи с внешним миром, устройства для развлечения, мультимедиа средства производят обмен пакетами данных между собой (радиоприемник, CD-проигрыватель, сетевой телефон, бор­товой компьютер, навигационная система). Эти пакеты значительно превышают размеры кадров данных, которые можно передавать по автомобильной коммуни­кационной шине. Разборка и сборка пакетов этих данных производится под управлением протоколов высоких уровней.

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

Протоколы высоких уровней должны обеспечивать:

•надежные и эффективные процедуры обмена длинными последовательно­стями данных;

Рисунок 4.17 – Упрощенная модель ВОС

 

•независимость программного обеспечения приложений от конфигурации сети и оборудования;

•удобство интерфейса для программиста.

Семиуровневая модель ВОС хорошо подходит для больших компьютеров и се­тей, где нет необходимости для коммуникаций в реальном времени. Для автомо­билей эта модель упрощается до двух верхних уровней — прикладного и транс­портного, как показано на рис. 4.17. Прикладной уровень обеспечивает интерфейс для программиста, решает задачу по получению и посылке данных, необходимых при управлении различными системами автомобиля. На транспортном уровне осуществляется разборка и сборка пакетов. Блок управления сетью и узлами про­изводит контроль сети и узлов, обнаруживает неисправности, активизирует сеть или переводит ее в неактивный режим. Этот блок взаимодействует непосредствен­но со всеми уровнями сетевой модели и с приложением.

 

Транспортный уровень

 

Транспортный уровень должен обеспечивать передачу произвольно длинных сообщений между объектами прикладных уровней.

► Если длина сообщения превышает размер кадра, передаваемого по коммуни­кационной шине, сообщение разделяется на несколько пакетов. Сообщение пере­дается с прикладного уровня на транспортный, где разделяется на сегменты, соот­ветствующие размеру одного кадра. К каждому кадру транспортный уровень добавляет свою управляющую информацию протокола (PCI — protocol control information). Управляющая информация используется транспортным уровнем на принимающей стороне для восстановления исходного сообщения и передачи его принимающему прикладному уровню.

Управляющая информация протокола содержит сведения о числе кадров в ис­ходном сообщении, номере текущего кадра в сообщении, она необходима для об­наружения и исправления ошибок типа пропуска или дублирования кадра.

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

                                           а)

Арбитражное поле

Поле данных

 

PCI Данные

                                           б)

Арбитражное поле

Поле данных

  PCI PCI Данные
       

 

Рисунок 4.18 – Размещение PCI в кадре

 

Рисунок 4.19 – Квитирование каждого кадра

 

 

Рисунок 4.20 – Квитирование блока кадров

 

Рисунок 4.21 – Передача сигнала NACK

 

►                Механизм управления потоком сообщений (трафиком) включает использова­ние двух видов подтверждений:

•положительное подтверждение АСК. (сокращение от acknowledge);

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

В сети могут быть реачизованы режимы, когда приемник квитирует (подтверж­дает) каждый принятый кадр (рис. 4.19) или блок кадров (рис. 4.20), что более эф­фективно в смысле быстродействия мультиплексной системы.

Отрицательное подтверждение выдается приемником в сеть, когда что-то про­исходит неправильно. Режим работы с отрицательным подтверждением может увеличить быстродействие сети, так как при отсутствии ошибок число кадров, пе­редаваемых от передатчика к приемнику, а следовательно, и время их передачи уменьшается (рис. 4.21).

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

► И приемник, и передатчик могут иметь средства для обнаружения и исправ­ления ошибок. Примеры ошибок, которые могут быть выявлены:

• приемник не получил кадр в установленное время;

• приемник получил некорректный кадр, например, не с тем номером;

• приемник не закончил обработку полученного кадра, но готов получить следующий кадр;

•передатчик не получил положительное подтверждение в установленное время.

Когда передающий объект па транспортном уровне обнаруживает ошибку, он может поступить следующим образом:

• повторить передачу кадра;

• повторить передачу всего сообщения;

• прекратить передачу и предоставить дальнейшие действия приложению.

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

 

Прикладной уровень

 

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

► На прикладном уровне форматируется кадр со следующими данными из приложения:

•имя кадра и его идентификатор;

•место размещения переменных (параметров) в кадре;

•формат представления параметров;

•единица измерения параметра;

•допустимый диапазон значений;

• разрешающая способность;

•формула, преобразующая числовое значение в кадре (N) в значение, имею­щее физический смысл (Е).

В табл. 4.1 приведен пример кадра:

 

Таблица 4.1

Имя кадра    Температура
Идентификатор 40hex
Название переменной Забортная температура
 Размещение Байты 0 и 1
Формат 16-битовый
Единица измерения ºС
Диапазон -40...+50
Разрешение 0,1
Формула N = (E + 40)·10

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

► На прикладном уровне определяется, когда сообщение должно быть отправ­лено или принято. Отправка производится по времени или в результате обработки события. Событием может быть: изменение состояния датчика, значение, вышед­шее за заданный предел; запрос от другого узла и т. д. Передача по времени ведет­ся для параметров, которые должны быть доступны всей мультиплексной системе. Такие переменные делят на группы с различной требуемой скоростью обновления и передачи значений.

При приеме сообщений на прикладном уровне сообщение распаковывается в соответствии с принятым форматом кадра, и данные передаются активному при­ложению.

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

В модели «клиент — сервер» взаимодействие между процессами осуществляет­ся способом, когда какой-либо процесс (сервер) способен выполнять операции по запросу другого процесса (клиента), размещенного в другом узле. Например, при диагностике сканер посылает по сети запрос ЭБУ и получает в ответ знамения па­раметров пли коды ошибок.

 


Дата добавления: 2018-11-24; просмотров: 658; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!