Шины для бортовых автомобильных систем

CAN протоколы высокого уровня
Введение
CAN протокол получил всемирное признание как очень универсальная, эффективная, надежная
и экономически приемлемая платформа для почти любого типа связи данных в передвижных
системах, машинах, техническом оборудовании и индустриальной автоматизации. Основанная на
базе протоколов высокого уровня CAN-технология успешно конкурирует на рынке распределенных
систем автоматизации. Под терминами "CAN стандарт" или "CAN протокол" понимаются
функциональные возможности, которые стандартизированы в ISO 11898. Этот стандарт
объединяет физический уровень (Physical Layer) и уровень канала данных (Data Link Layer) в
соответствии с 7-ми уровневой OSI моделью. Таким образом, "CAN стандарт" соответствует
уровню сетевого интерфейса в 4-х уровневой модели TCP/IP. Однако, практическая реализация
даже очень простых распределенных систем на базе CAN показывает, что помимо
предоставляемых сервисов уровня канала данных требуются более широкие функциональные
возможности : передача блоков данных длинной более чем 8 байтов, подтверждение пересылки
данных, распределение идентификаторов, запуск сети и функции супервизора узлов. Так как эти
дополнительные функциональные возможности непосредственно используются прикладным
процессом, вводится понятие уровня приложений (Application Layer) и протоколов высокого уровня.
Обычно их и называют термином "CAN протоколы".
OSI модель протоколов высокого уровня на базе CAN,протоколов
TCP/IP
Для систем реального времени на базе CAN нет необходимости в реализации полной 7-ми
уровневой модели OSI(рис. 1). Это связано с тем, что типичная CAN система имеет в своей основе
единственный канал данных для обмена сообщениями между устройствами, все устройства
ориентированы на конкретный способ передачи данных по каналу, а приложения пишутся именно
под данную архитектуру сети и данный протокол. Поэтому нет необходимости в реализации
уровня представлений, уровня сеанса и сетевого уровня из 7-ми уровневой модели OSI и были
оставлены только 3 уровня этой модели : физический уровень, уровень канала данных и уровень
приложений(рис. 2). Причем последний реализует некоторые функции транспортного уровня.
Рис. 1
Рис. 2
Из-за широко использования CAN сетей с различными целями и требованиями существуют
несколько главных стандартов CAN-протоколов высокого уровня : CAL (CAN Application Layer),
OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS (Smart Distribution Systems),CAN-Kingdom. Далее
более подробно будет рассмотрен стандарт DeviceNet для сравнения с TCP/IP.
Основные возможности протоколов высокого уровня на базе CAN
Рассмотрим основные возможности, которые предоставляют протоколы высокого уровня:
система назначения идентификатора для сообщения
метод обмена данных процесса
прямая(peer-to-peer) связь
метод установления связей для обмена данных процесса
сетевое управление
модели и профайлы устройств
Идентификаторы сообщений
Метод назначения идентификатора сообщения является главным архитектурным элементом
CAN систем, так как идентификатор CAN-сообщения определяет относительный приоритет
сообщения и следовательно время обработки сообщения (latency time). Это также влияет на
возможность применимости фильтрования сообщения,на использование возможных
коммуникационных структур и эффективность использования идентификатора. Что касается
назначения идентификаторов сообщений, существуют различные подходы для систем на базе
CAN. Некоторые (CANopen) не применяют предопределение идентификаторов для общих структур
системы, DeviceNet и SDS делают это.
Устройства (nodes) в DeviceNet получают постоянный идентификатор. Максимальное
количество узлов составляет 64. Каждый узел имеет некоторое множество идентификаторов в
одной из 3-х групп в зависимости от приоритета сообщения (рис. 3).
Рис. 3
Группа 1 сообщений обеспечивает до 16 высоко приоритетных сообщений на устройство, группа
3 сообщений - до 7 низко приоритетных сообщений на устройство. Группа 2 сообщений
предназначена для поддержки устройств с ограниченными способностями фильтрования
сообщений. Поэтому для данной группы идентификаторов было выбрано фильтрование согласно
номеру узла (MAC-ID). Это означает, что приоритет сообщений этой группы прямо определяется
номером узла. MAC-ID группы 2 может быть адресом источника или адресом назначения.
DeviceNet использует также предопределенное Master/Slave множество связей для облегчения
взаимодействия в Master/Slave системной конфигурации (рис. 4):
Рис. 4
Поддерживаются следующие функции канала обмена I/O сообщениями и явными (Explicit)
сообщениями между Master и Slave устройствами из предопределенного множества связей:
явный канал сообщений
изменение Master статуса канала (Master Poll Change of State/Cyclic channel)
изменение Slave статуса канала (Slave I/O Change of State/Cyclic channel )
Bit Strobe канал
Явный канал сообщений главным образом служит для конфигурации устройства. С изменением
Master статуса канала Master может запрашивать данные ввода - вывода от устройства и
посылать данные на Slave устройство. C изменением Slave статуса канала Slave устройство может
передать данные Master-устройству. При помощи Bit Strobe команды Master-устройство может
запросить данные у любого из 64 Slave устройств посредством одного сообщения.
Oбмен данных процесса
Передача данных процесса между устройствами распределенной системы - цель системы на
основе CAN протокола. Поэтому передача прикладных данных (данные процесса, данные ввода вывода) системы должна быть выполнена наиболее эффективным путем. CANopen и DeviceNet
обеспечивают весьма схожие механизмы связи для передачи данных обслуживания /
конфигурации процесса. У CANopen передача данных процесса происходит посредством так
называемых "Объектов Данных Процесса (PDOs)", у DeviceNet посредством " I/O-сообщений ".
В таблице 1 приведены основные характеристики для протоколов CANopen, DeviceNet and SDS.
Одним из главных различий является обеспечение протоколами DeviceNet and SDS фрагментации
пакетов без подтверждения, что делает возможным передачу данных длиной более 8 байт. Также
поддерживаются 3 различных протокола (рис. 4) по отношению к подтверждению приема данных
("Transport Classes") . Например, классы 2 и 3 могут быть использованы для эффективного
опроса(polling) устройств. Для той цели master устройство имеет коммуникационные объекты
(connection objects), связанные с каждой командой опроса как клиентский транспортный класс 2
или 3. Каждое slave устройство имеет коммуникационные объекты серверного транспортного
класса 2 или 3 для получения команд опроса и передачи соответствующих ответных данных.
Таблица 1. Exchange of Process Data in CANopen, DeviceNet and SDS
(Multicasting)
CANopen
DeviceNet
SDS (V2.0)
Name of
Communication Process Data Object
Object
I/O-Message
Multicast Channel
APDU
Maximal
Number of
512 Transmit PDOs 512
Communication
Receive PDOs
Objects per
Device
27 I/O- Transmit Messages 1701
I/O Receive Messages per device 32 Embedded
32 Multicast Channels for each of Objects per device
up to
Maximal length
of Data Field
8 bytes fragmented: Arbitrary
length
8 bytes
6 bytes fragmented:
64 * 4 bytes
Unfragmented: No overhead,
three "Transport Classes"
supported:
Unfragmented: No overhead,
Notify/Read "Stored-Event"protocol (CAL/CMS)
Unacknowledged
Unfragmented: 2
Unacknowledged,
byte protocol
Acknowledged by Server overhead,
Connection Object,
Unacknowledged
Acknowledged by
Application
Protocol
Fragmented: Unacknowledged
fragmented protocol 1 byte
protocol overhead per frame
Message
Production
Triggering
Modes
Mapping of
Application
Objects
On Request of local or
remote application
Cyclic/acyclic
synchron
Maximum number of
mappable application
objects/PDO dependent on
data size of objects (1-bit
objects: 64 application objects
mappable) Definition of
Application objects by means
of "Mapping Parameter
Record" (configurable)
Dynamic mapping supported
Cyclic
Change-of-State
Application specific
Arbitrary number of Application
objects mappable with
fragmented protocol. Definition of
Application objects by means of
Assembly Object (several
Assembly Objects possible)
Dynamic mapping supported
Fragmented:
Acknowledged
fragmented
protocol with
Acknowledge after
reception of
complete block 4
bytes protocol
overhead per
fragment
Specified by object
model
Network Data
Descriptor defines
size, granularity
and data type of I/O
data of Embedded
Object (V1.8)
Рис. 5. Device Net Transport Classes
Вызов (triggering) сообщений
Все рассматриваемые протоколы поддерживают различные способы вызова сообщений.
DeviceNet поддерживает циклический (Cyclic), по состоянию (Change-of-State) и программный
(Application) способы вызова. Циклический вызов осуществляется по истечению времени таймера
и начинается передача сообщения. Передача по состоянию начинается, когда статус
определенного объекта изменяется. В этом случае сообщение также передается, когда истекает
определенный интервал времени, в котором не осуществлялась передача сообщения.
Программным способом сам объект решает, когда начать передачу сообщения. В этом случае
сообщение также передается, когда истекает определенный интервал времени без передачи
сообщения.
Установление соответствий (mapping) для программных
объектов
Сетевые устройства обычно содержат более одного программного объекта и передача I/O
сообщения более чем одному программному объекту внутри одного PDO является необходимым
требованием. В DeviceNet объединение прикладных данных осуществляется посредством
трансляционных (assembly) объектов, которые определяют формат передаваемых данных.
Устройство может содержать более одного I/O трансляционного объекта и выбор подходящего
(consumed/ produced_connection_path) может быть настраиваемой опцией устройства.
Прямые (peer-to-peer) коммуникационные каналы
Для конфигурации устройств посредством конфигурационных средств требуются специальные
функции у устройств или программы, обеспечивающие многоцелевые каналы связи. Это не
критичные по времени каналы связи. Передача данных в них осуществляется посредством
протокола с подтверждениями и фрагментацией. Любой из протоколов высокого уровня, которые
поддерживают некоторую конфигурацию устройств, должны обеспечивать этот вид связи.
DeviceNet обеспечивает многоцелевые устройство ориентированные каналы и сервисы. Запись
и чтение атрибутов объектов, контролирование объектов (reset, start, stop etc.),
сохранение/восстановление атрибутов объектов осуществляется посредством явных (Explicit)
сообщений. Намерение использовать данное сообщение определяется в поле данных CANа. На
рис. 7 показан формат поля данных фрагментированного Explicit сообщения. В запросе сервиса
указывается номер класса, номер экземпляра(instance), номер атрибута (в поле Service specific
arguments).
Рис. 6. DeviceNet Fragemented Explicit Message Data Field Format
(Request/Response)
Explicit(прямая) связь устанавливается посредством менеджера сообщений (Unconnected
Message Manager (UCMM)). UCMM предоставляет два сервиса для открывания и закрывания
подобных соединений. Каждое устройство, поддерживающее UCMM, резервирует у себя
идентификаторы сообщений для запросов и ответов для UCMM. Для устройств 2-й группы,
которые не поддерживают UCMM порт, master устройство сперва должно разместить Explicit
соединение в предопределенном множестве соединений. Запрос к устройству группы 2
передается как Explicit запрос без предварительного установления соединения (Unconnected
Explicit Request ) с зарезервированным идентификатором сообщения.
Сравнительные характеристики протоколов CANopen, DeviceNet и SDS в отношении прямых
(peer-to-peer) коммуникационных каналов представлены в таблице 2.
Таблица 2. Main Characteristics of Peer-to-Peer Communication Channels
CANopen
DeviceNet
SDS (V2.0)
Name
Service Data Channel
Explicit Message
Maximum
number of
channels
128 Client SDOs, 128
Server SDOs per device
27 Explicit Transmit Messages 4 channels per Embedded
1701 Explicit Receive
Object. 32 Embedded
messages per device
Objects per Logical Device
Protocol
< 5 byte: Acknowledged
< 7 byte: Acknowledged
Peer-to-peer Channel
< 6 bytes Acknowledged
unfragmented 4 byte:
Fragmented transmission (7
bytes per fragment) Each
frame acknowledged Any
length (CAL Multiplexed
Domain protocol)
Establishing
of
Connections
Dynamic
establishment by
means of
Unconnected
Message Manager
Group 2 Only
devices: Allocation
of Explicit Message
from Predefined
Connection Set
Initiate, Abort
Upload/Download
Segment/Domain
Connection
Services and
Arguments
Index and Subindex of
addressed
unfragmented 6 byte:
Fragmented transmission. (6
bytes per fragment) Each
frame acknowledged Any
length
Dynamic establishing
by means of
Connection Manager
Master/Slave Set of
Connections Set
unfragmented 5 byte
Fragmented transmission (3
bytes per fragment)
Acknowledgement of
complete data block. Max.
255 byte
Dynamic
establishment by
means of SDO
Manager
Default predefined
connections
Open/Close Creation,
Configuration, Start, Stop,
Reset etc. of Objects
Open/Close Read, Write,
Event, Action
Object Directory Entry Object
attribute access path, Service
arguments
Channel Number,
Attribute/Action/Event
Identifier
Установление связей для обмена данных процесса
Распределение идентификаторов для передаваемых сообщений и , соответственно,
получаемых сообщений устанавливает коммуникационные пути в CAN сети. Установление
взаимодействия возможно через использование предопределенного множества сообщений с уже
размещенными идентификаторами сообщений или через переменное распределение
идентификаторов для сообщений.
В системе с предопределенным множеством сообщений "функции" и идентификаторы
сообщений уже определены. DeviceNet также использует предопределенное множество
сообщений для системы со структурой 1:n. Master устройство, предварительно разместив у себя
множество связей со Slave устройствами, "знает" ID сообщений для передачи запроса и ID
сообщений для получения ответа, который включает Slave MAC-ID в соответствии с
предопределенным множеством связей. Также возможно не предопределять идентификаторы
сообщений.
Сетевое управление
Так как в CAN-сети мы имеем дело с распределенными приложениями, должны отслеживаться
определенные события(отказы различных частей приложения или отказ устройств). Поэтому
главными задачами сетевого управления становятся обнаружение и вывод ошибок в сети и
предоставление сервисов, позволяющих контролировать статусы устройств и вести координацию
устройств. В зависимости от системных решений сетевое управление может вестись явным или
косвенным путем.
В DeviceNet каждое соединение контролируется. Поэтому каждая ожидающая сообщение
конечная точка имеет "Inactivity/Watchdog" таймер, чтобы контролировать прибытие сообщения
согласно предопределенному времени ожидания. Если время истекает, соединение выполняет
действие "Timeout". На рис. 7 показана диаграмма изменения состояний у объекта I/O.
Рис. 7. Device Net I/O Connection Object State Transition Diagram
После получения вызова CREAT ( Explicit сообщение) соединение настраивается при помощи
подходящей последовательности вызовов явных сообщений и после этого устанавливается.
Перед получением доступа к сети каждое устройство должно совершить проверку на дубликат
своего MAC-ID. Определенные алгоритмы выбора гарантируют уникальность MAC-ID.
Контроль может осуществляться также посредством Heartbeat сообщения, которое может
посылаться устройствам посредством UCMM в форме сообщения. В поле данных этого сообщения
передается состояние устройства. Heartbeat сообщение вызывается объектом Idendity.
Профайлы устройств
Для открытых автоматических систем помимо обеспечения связи от входящих в их состав
устройств требуется также обеспечение возможности взаимодействия и взаимозаменяемости.
Поэтому протоколы высокого уровня (такие как DeviceNet) описывают функциональные
возможности устройств в виде модели устройства ("Device Model").
Помимо описания функциональности устройств модель устройства должна также содержать ряд
важных параметров (статус, диагностическую информацию, коммуникационные возможности,
конфигурационные параметры и т.д.). На рис. 8 показана модель устройства DeviceNet.
Рис. 8. DeviceNet Object Model
DeviceNet профайл должен содержать следующую информацию:
модель объекта для устройства
формат данных I/O для устройства
конфигурационные данные и внешние интерфейсы для этих данных
В таблице 3 показаны главные функции объектов в DeviceNet.
Таблица 3. Objects of a DeviceNet node
Object
Function
Connection
Instantiates connections (I/O or Explicit Messaging)
DeviceNet
Maintains configuration and status of physical attachments to DeviceNet.
Message
Router
Routes received Explicit Messages to appropriate target objects
Assembly
Groups attributes of multiple objects into a single block of data, which can be sent and
received over a single connection
Parameter
Provides a standard means for device configuration and attribute access
Identity
Provides general information about the identity of a device
Application
Supplies application-specific behaviour and data
Заключение
Протокол CAN применяется в real-time системах для решения различных задач. В настоящий
момент развиваются несколько видов CAN протоколов высокого уровня, таких как CAL ,OSEK/VDX,
SAE J1939, CANopen, DeviceNet, SDS ,CAN-Kingdom , в основе которых лежит канальный протокол
CAN2.0 (Bosch) , и на основе этих протоколов можно решать проблемы, возникающие в real-time
системах, которые невозможно разрешить при помощи других известных протоколов, скажем,
TCP/IP.
Шины для бортовых автомобильных систем
Эдуард Пройдаков
Читатели нашего еженедельника в большинстве своем хорошо знакомы с локальными сетями
(ЛС, ЛВС). Однако внедрение микропроцессоров и микропроцессорных контроллеров в самое
различное оборудование
потребовало наличия сетей, объединяющих
многообразные электронные управляющие устройства
(ECU).
Рассмотрим в качестве примера такой сети шину (и
соответствующий ей протокол) CAN (Controller Area
Network). Она была предложена Робертом Бошем
(Robert Bosch) в 80-х годах для автомобильной
промышленности, затем стандартизована ISO (ISO
11898) и SAE (Society of Automotive Engineers).
(Описание стандартов и большой объем документации
Рис. 1. Топология шины CAN
по CAN можно найти на сайте http://www.can-cia.de/)
Сегодня большинство европейских автомобильных гигантов (например, Audi, BMW, Renault, Saab,
Volvo, Volkswagen) используют CAN в системах управления двигателем, безопасности и
обеспечения комфорта. В Европе в ближайшие годы будет введен единый интерфейс для систем
компьютерной диагностики автомобиля. Это решение также разрабатывается на базе CAN, так что
со временем в каждом автомобиле будет по крайней мере один узел этой сети.
Однако сети CAN используются и в таких сложных установках, как современные оптические
телескопы с большим диаметром зеркала. Так как такие зеркала невозможно сделать
монолитными, их сейчас делают составными, а управление отдельными зеркальцами (их может
быть больше сотни) осуществляется сетью микроконтроллеров. Другие сферы применения —
корабельные бортовые сети, управление системами кондиционирования воздуха, лифтами,
медицинскими и промышленными установками. В мире уже установлено более 100 млн. узлов
сетей CAN, ежегодный прирост составляет более 50%.
CAN представляет собой асинхронную последовательную шину, использующую в качестве
среды передачи витую пару проводов (см. рисунок 1). При скорости передачи 1 Мбит/с длина
шины может достигать 30 м. При меньших скоростях ее можно увеличить до километра. Если
требуется большая длина, то ставятся мосты или повторители. Теоретически число
подсоединяемых к шине устройств не ограничено, практически — до 64-х. Шина мультимастерная,
т. е. сразу несколько устройств могут управлять ею.
Если базироваться на семиуровневой модели OSI, то CAN описывает передачу данных между
узлами на двух нижних уровнях — физическом и канальном. Физический уровень разбит на три
подуровня: физических сигналов (PLS), соединения с физической средой (PMA) и физического
соединения (MDI). Битовый поток кодируется по методу NRZ (без возвращения к нулю), что
позволяет работать на меньших частотах, чем, например, при других видах кодирования. Над CAN
надстроена реализация протоколов более высоких уровней. Здесь нет жесткой стандартизации и
имеется много протоколов или решений компаний. Примером одного из них является
разработанный компанией Allen Bradley протокол DeviceNet.
На рынке CAN присутствует в двух версиях: версия А задает 11-битную идентификацию
сообщений (т. е. в системе может быть 2048 сообщений), версия B — 29-битную (536 млн.
сообщений). Отметим, что версия В, часто именуемая FullCAN, все больше вытесняет версию А,
которую называют также BasicCAN.
Сеть CAN состоит из узлов с собственными тактовыми
генераторами. Любой узел сети CAN
посылает сообщение всем системам, подсоединенным к
шине, таким, как приборная доска или подсистема
определения температуры бензина в автомобиле, а уж
получатели решают, относится ли данное сообщение к
ним. Для этого в CAN имеется аппаратная реализация
фильтрации сообщений.
В мире производится множество типов контроллеров
CAN. Их объединяет общая структура — каждый
контроллер имеет обработчик протокола (CAN protocol
handler), память для сообщений, интерфейс с ЦП. Во
многих популярных однокристальных микропроцессорах
есть встроенный контроллер шины CAN.
Характеристики шины Controller
Area Network (CAN)
Топология: последовательная
шина, с обоих концов линии
стоят заглушки (120 Ом)
Обнаружение ошибок: 15битовый CRC-код
Локализация ошибок:
различают ситуации с
постоянной ошибкой и
временной; устройства с
постоянной ошибкой
отключаются
Текущая версия: CAN 2.0B
Скорость передачи: 1 Мбит/с
Длина шины: до 30 м
Количество устройств на
шине: ~ 64 (теоретически
неограничено)
Поддержкой технологии CAN занимается
некоммерческая международная группа CiA (CAN in
Automation, http://www.can-cia.de/), образованная в 1992 г.
и объединяющая пользователей и производителей
технологии CAN. Группа предоставляет техническую,
маркетинговую и продуктовую информацию. Осенью 1999
г. в CiA было около 340 членов. Она также занимается
разработкой и поддержкой различных базирующихся на CAN протоколов высокого уровня, таких,
как CAL (CAN Application Layer), CAN Kingdom, CANopen и DeviceNet. Кроме того, члены группы
дают рекомендации, касающиеся дополнительных свойств физического уровня, например
скорости передачи и назначения штырьков в разъемах.
Замечу, что эта шина развивается в нескольких направлениях. В новом проекте стандарта будет
увеличена скорость передачи данных, так как в автомобиле появилось много компьютерных
подсистем, связанных с передачей аудио- и видеоинформации. Повышение надежности требует
введения так называемой двойной (дублированной) шины CAN. Другие изменения достаточно
кардинальны и вызваны появлением нового протокола, рассмотренного ниже.
Протокол TTP
В системах реального времени существует два основных способа управления — по событиям
(например, по прерываниям) и по временным меткам. Если первый подход широко распространен,
то для второго требуются специальные средства. Одно из них — TTP, Time Triggered Protocol,
коммуникационный протокол для высоконадежных приложений. Первоначально он
разрабатывался в рамках исследовательской программы, финансируемой Евросоюзом. В этой 15летней программе принимало участие множество фирм, таких, как DaimlerChrysler, British
Aerospace, Alcatel, Temic, Fiat, Ford, Marelli, Bosh, Volvo, и Венский технический университет.
Разработкой занято около 100 человек, в нее вложено примерно 25 млн. долл. Созданная в ходе
выполнения программы архитектура TTA (Time-Triggered Architecture) признана эффективной для
критичных по безопасности систем (автомобильных, железнодорожных, авиационных). TTP
является центральной частью проектов SETTA (System Engineering for TTA) и FIT (Fault Injection for
TTA), разрабатываемых ЕС в рамках программы ESPRIT.
В настоящее время поддержка протокола TTP осуществляется специально созданной для этого
компанией TTTech (http://www.ttttech.com/), которая выпускает интегрированные средства
разработки (пакет TTPtools) и занимается обучением пользователей протокола. Сотрудничество
этой фирмы с Венским техническим университетом привело к появлению протокола TTP/C. Буква
C в его названии говорит о том, что протокол удовлетворяет требованиям класса C Ассоциации
инженеров автомобилестроения (SAE) на отказоустойчивые протоколы передачи данных для
жесткого реального времени.
В современном автомобиле используется больше сотни
микропроцессоров
В отличие от большинства стандартов на мультиплексированные шины для встраиваемых
систем, TTP с самого начала разрабатывалась для высоконадежных приложений. В системах
управления автомобиля очень важны устойчивость к ошибкам и временные характеристики,
связанные, например, с заменой обычных гидравлических тормозов на электромеханические
(brake-by-wire), управляемые по сети. Поэтому сети CAN при большом потоке сообщений будут
заменяться на TTP/C. Замена гидравлических и механических компонентов в автомобиле
обозначается общим термином by-wire applications. При этом образуется жесткая связь между
электроникой и исполнительными механизмами, когда требуются надежность, простота сборки и
обслуживания.
Другой член семейства протоколов TTP — протокол TTP/A — дешевый протокол для сети
датчиков и приводов. Он бесшовно интегрируется с TTP/C. Получающаяся в результате
архитектура TTA гарантирует, что каждое чтение с датчика и команда на привод будут полностью
предсказуемы в соответствии с их временными свойствами.
Система управления на базе протокола TTP/C состоит по крайней мере из одного
вычислительного кластера, содержащего набор узлов. Узлы общаются по широковещательной
шине. Общее время устанавливается с помощью синхронизации таймеров каждого из узлов. На
уровне кластера ошибки узла или коммуникаций могут быть замаскированы за счет дублирования
узлов и объединения их в группы, устойчивые к сбоям. Такие группы называются FPU (Fault
Tolerant Units).
Доступ к среде передачи осуществляется по схеме статического TDMA, определенной перед
запуском системы. Каждому узлу разрешается посылать до 16 байт данных с 4-байтовым
заголовком и 16-битовым контрольным кодом (CRC). Эта посылка осуществляется в
предопределенный интервал времени, называемый TDMA-слотом.
Технология TTP/C уже начала воплощаться в микросхемах: несколько европейских
производителей либо выпустили первые кристаллы (AMS), либо объявили о намерении это
сделать (ARM, Motorola, Philips). Motorola собирается предлагать не только аппаратные решения,
но и программные — их реализацией уже заняты ее подразделения в Шотландии. Законченные
решения появятся к концу года (www.mot-sps.com/automotive/TTPC.html).
Дважды в год проводятся форумы (см. http://www.ttpforum.org/), посвященные TTP. Четвертый
TTPforum прошел 8 марта в Детройте в рамках выставки и конференции по автомобильной
электронике SAE 2000. В нем приняло участие около 200 человек. Если самая крупная из
известных мне компьютерных конференций (Oracle) собирала 30 тыс. участников, то в SAE
приняли участие 50 тыс. человек и 1200 экспонентов.
Безусловно, этот текст, написанный под впечатлением увиденного на Нюрнбергской выставке
“Embedded Systems’2000”, лишь введение в интереснейшую тему шин для бортовых систем.
Редакция приглашает специалистов осветить эту тему, как и в целом тему автомобильной
электроники.С автором можно связаться по адресу: chief@pcweek.ru.