Товары в корзине: 0 шт Оформить заказ
Стр. 1 

42 страницы

Определяет канальный уровень (DLL) и уровень физической передачи сигналов сети контроллеров (CAN).

 Скачать PDF

Идентичен ISO 11898-1:2003/Cor.1:2006

Оглавление

1 Обзор

2 Соответствие требованиям

3 Нормативные ссылки

4 Термины и определения

5 Сокращения

6 Основные понятия CAN

     6.1 Свойства CAN

     6.2 Кадры

     6.3 Метод доступа к шине

     6.4 Передача информации

     6.5 Универсальность системы.

     6.6 Целостность данных

     6.7 Удаленный запрос данных..

     6.8 Обнаружение ошибок

     6.9 Сигнализация об ошибках и время восстановления

     6.10 Подтверждение приема (АСК)

     6.11 Автоматический повтор передачи

     6.12 Локализация ошибок

     6.13 Активность при ошибках

     6.14 Пассивность при ошибках

     6.15 Отключение от шины

7 Иерархическая архитектура CAN

     7.1 Соответствие модели взаимосвязи открытых систем (ВОС)

     7.2 Технические характеристики протокола

     7.3 Описание формата служб

     7.4 Интерфейс LLC

8 Описание нижнего уровня LLC

     8.1 Общие сведения

     8.2 Службы нижнего уровня LLC

     8.3 Функции нижнего уровня LLC

     8.4 Структура кадров LLC

     8.5 Ограниченные кадры LLC

9 Интерфейс LLC - MAC

     9.1 Службы

     9.2 Опция ТТС

10 Описание нижнего уровня МАС

     10.1 Общие сведения

     10.2 Службы нижнего уровня МАС

     10.3 Функциональная модель нижнего уровня МАС

     10.4 Структура кадров МАС

     10.5 Кодирование кадра

     10.6 Порядок передачи битов

     10.7 Подтверждение кадра

     10.8 доступ к каналу связи

     10.9 Обнаружение ошибок

     10.10 Сигнализация об ошибках

     10.11 Сигнализация о перегрузке

     10.12 Мониторинг шины

11 Технические требования к нижним уровням LLC и МАС

12 Физический уровень

     12.1 Общие сведения

     12.2 Функциональная модель

     12.3 Службы физического уровня

     12.4 Параметры нижнего уровня РLS

     12.5 Параметры интерфейса РLS—РМА

13 Описание супервайзера

     13.1 Предотвращение ошибок

     13.2 Управление отказами на шине

Библиография

Приложение ДА (справочное) Сведение о соответствии ссылочного международного стандарта национальному стандарту Российской Федерации

 

42 страницы

Дата введения01.08.2016
Добавлен в базу01.02.2017
Актуализация01.01.2019

Этот ГОСТ находится в:

Организации:

06.11.2015УтвержденФедеральное агентство по техническому регулированию и метрологии1711-ст
ИзданСтандартинформ2016 г.
РазработанМАДИ

Road vehicles. Controller area network (CAN). Part 1. Data link layer and physical signalling

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

ГОСТ Р исо

11898-1-

2015

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

Транспорт дорожный МЕСТНАЯ КОНТРОЛЛЕРНАЯ СЕТЬ (CAN)

Часть 1

Канальный уровень и передача сигналов

(ISO 11898-1:2003, ЮТ)

Издание официальное

Москва

Стандартинформ

2016

Предисловие

1    ПОДГОТОВЛЕН Федеральным государственным бюджетным образовательным учреждением высшего профессионального образования «Московский автомобильно-дорожный государственный технический университет» (МАДИ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4.

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 57 «Интеллектуальные транспортные системы»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 06 ноября 2015 г. № 1711-ст

4    Настоящий стандарт идентичен международному стандарту ИСО 11898-1:2003 «Транспорт дорожный. Местная контроллерная сеть (CAN). Часть 1. Канальный уровень и передача сигналов» («Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling», IDT), включая поправку 1:2006 (Cor. 1:2006).

Международный стандарт ИСО 11898-1 разработан техническим комитетом ИСО/ТК 22, Дорожный транспорт, подкомитет ПКЗ, электрическое и электронное оборудование (ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical and electronic equipment).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие национальные стандарты, сведения о которых приведены в дополнительном приложении ДА.

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а текст изменений и поправок— в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2016

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

ГОСТ Р ИСО 11898-1-2015

(Л/ - 1) подсистем уровня посредством (Л/ - 1) точек доступа к службам (SAP). Блок NPDU должен проходить с помощью (Л/ - 1) сервисных блоков данных (SDU) на уровень (Л/- 1), службы которого позволяют передать блок NPDU. Блоки SDU должны представлять собой интерфейсные данные, идентичность которых сохраняется между подсистемами (Л/) уровней, т.е. являться блоками логических данных, пересылаемых службой. Канальный уровень протокола CAN не должен обеспечивать ни средства распределения одного блока SDU в несколько блоков PDU, ни сведения нескольких SDU в один PDU, т.е. NPDU непосредственно формируется из взаимосвязанных блоков NSDU и специфической для уровня управляющей информации N-PCI. На рисунке 2 показано взаимодействие на нижнем канальном уровне.

Интерфейс физического уровня Рисунок 2 — Взаимодействие уровней протокола

7.3 Описание формата служб

7.3.1    Описание формата служебных примитивов

Служебные примитивы должны описываться как служба.тип (

[параметр^...]

),

где «служба» — это имя службы, например, L_Data для службы передачи данных, обеспечиваемой нижним уровнем LLC, «тип» — это тип служебного примитива (см. п. 7.3.2), а [параметр1,...] — это перечень значений, придаваемых служебному примитиву. Квадратные скобки означают, что этот перечень параметров может быть пустым.

7.3.2    Типы служебных параметров

Служебные примитивы должны относиться к одному из трех стандартных типов:

a)    Service.Request

Примитив запроса должен поступать от N-ro пользователя (пользователя службы) на N-й уровень (провайдер службы) для запроса запуска службы.

b)    Service.Indication

Примитив индикации должен поступать от N-ro уровня N-му пользователю для указания на внутреннее событие N-ro уровня (или нижнего уровня), которое имеет значение для N-ro пользователя. Это событие может быть логически связано с дистанционным запросом службы или может быть вызвано событием, внутренним для N-ro уровня (или нижнего уровня).

c)    Service.Confirm

Примитив подтверждения должен поступать от N-ro уровня (или нижнего уровня) N-му пользователю для передачи результатов одного или более взаимосвязанных предыдущих запросов службы.

7

Этот примитив может указывать либо на невыполнение, либо на ту или иную степень выполнения. Индикация какой-либо активности на удаленном равноправном интерфейсе не должна являться необходимой.

7.4 Интерфейс LLC

Нижний уровень LLC должен обеспечивать для своего пользователя два типа служб передачи данных без установления соединения:

a)    службу передачи данных без подтверждения;

b)    службу удаленного запроса данных без подтверждения.

Служебные данные интерфейса, пересылаемые от пользователя или к нему, должны соответствовать 8.2.2. Сообщения, пересылаемые между пользователем LLC и нижним уровнем LLC, должны соответствовать а) и Ь) таблицы 1.

Интерфейсные сообщения LLC от супервайзера FCE или к нему, должны соответствовать 13.1.3.

Таблица 1 — Сообщения, пересылаемые между пользователем LLC и нижним уровнем LLC

а) Сообщения, пересылаемые от пользователя LLC нижнему уровню LLC

Сообщение от пользователя к LLC

Значение

Reset_Request

Запрос на установку узла в исходное состояние

b) Сообщения, пересылаемые от нижнего уровня LLC пользователю LLC

Сообщение от LLC к пользователю

Значение

Reset_Response

Ответ на сообщение Reset_Request

Node_Status

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

8 Описание нижнего уровня LLC

8.1    Общие сведения

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

8.2    Службы нижнего уровня LLC

8.2.1 Типы служб передачи без установления соединения

Нижний уровень LLC должен обеспечивать два типа служб передачи без установления соединения:

a)    Служба передачи данных без подтверждения приема

Эта служба должна обеспечить средство обмена пользователей LLC блоками данных LSDU без установления соединения на канальном уровне. Передача данных может осуществляться методами «точка — точка», мультикаста или широкого вещания.

b)    Служба удаленного запроса данных без подтверждения приема

Эта служба должна обеспечить средство запроса пользователем LLC удаленного узла для передачи блоков LSDU без установления соединения на канальном уровне.

Удаленный узел должен в основном обслуживать запрос данных двумя следующими способами:

1)    запрошенные данные могут подготавливаться удаленным пользователем для передачи. В этом случае данные должны помещаться в буфер удаленного узла и передаваться подсистемой LLC удаленного пользователя после приема удаленного запроса кадра;

2)    запрошенные данные должны передаваться удаленным пользователем после приема удаленного запроса кадра.

Для двух разных служб LLC должны использоваться два типа кадров, пересылаемых от пользователя или к нему:

-    кадр данных LLC;

-    кадр удаленного запроса LLC.

ГОСТ Р ИСО 11898-1-2015

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

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

8.2.2.1 Общие сведения

Параметры служебных примитивов службы, приведенные в настоящем подразделе, подробно описывают примитивы служб LLC и связанные с ними параметры. Полный перечень примитивов служб LLC должен соответствовать приведенному в таблице 2.

Таблица 2 — Обзор примитивов служб LLC

Служба передачи данных без подтверждения приема

L_Data. Request

Запрос передачи данных

L_Data.Indication

Индикация передачи данных

L_Data.Confirm

Подтверждение передачи данных

Служба удаленного запроса данных без подтверждения приема

L_Remote. Request

Запрос удаленного запроса передачи данных

L_Remote. Indication

Индикация удаленного запроса передачи данных

L_Remote. Confirm

Подтверждение удаленного запроса передачи данных

Параметры, связанные с различными примитивами служб LLC, должны соответствовать приведенным в таблице 3.

Таблица 3 — Перечень параметров примитивов служб LLC

Параметры примитивов служб LLC

Identifier

Идентификатор данных и их приоритета

DLC

Код длины данных

Data

Данные, которые желает передать пользователь

Transfer_Status

Параметр подтверждения

8.2.2.2 L_Data.Request

8.2.2.2.1    Назначение

Примитив L_Data.Request должен поступить от пользователя LLC на нижний уровень LLC для запроса, по которому блок LSDU будет передан одной или нескольким компонентам LLC.

8.2.2.2.2    Семантика примитива L_Data.Request

Параметры примитива должны иметь следующий вид:

L_Data.Request (

Identifier

DLC

Data

)

Параметр Data не должен быть значащим, если соответствующий кадр данных LLC имеет нулевую длину данных.

8.2.2.2.3    Действие при получении

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

9

8.2.2.3 L_Data.Indication

8.2.2.3.1    Назначение

Примитив L_Data.Indication должен поступить от нижнего уровня LLC пользователю LLC для индикации поступления LSDU.

8.2.2.3.2    Семантика примитива L_Data.Indication Параметры примитива должны иметь следующий вид:

L_Data.Indication (

Identifier

DLC

Data

)

Параметр Data не должен быть значащим, если соответствующий кадр данных LLC имеет нулевую длину данных.

8.2.2.3.3    Действие при получении

Действие при получении данного примитива пользователем LLC не определено.

8.2.2.4    L_Data.Confirm

8.2.2.4.1    Назначение

Примитив L_Data.Confirm должен поступить от локального нижнего уровня LLC пользователю LLC для передачи результатов предыдущего примитива L_Data.Request. Данный примитив должен являться локальным подтверждением, т. е. не должен означать, что удаленная(ые) подсистема(ы) LLC передала(и) взаимосвязанный примитив индикации соответствующим пользователям LLC.

8.2.2.4.2    Семантика примитива L_Data.Confirm Параметры примитива должны иметь следующий вид:

L_Data.Confirm (

Identifier

Transfer_Status

)

Параметр Transfer_Status должен использоваться для индикации выполнения транзакции, начатой предыдущим примитивом L_Data.Request.

Transfer_Status:[Complete (выполнено), Not_Complete (невыполнено)]

8.2.2.4.3    Действие при получении

Действие при получении данного примитива пользователем LLC не определено.

8.2.2.5    L_Remote.Request

8.2.2.5.1    Назначение

Примитив L_Remote.Request должен поступить от пользователя LLC на нижний уровень LLC для запроса одной подсистемы LLC на передачу блока LSDU.

8.2.2.5.2    Семантика примитива L_Remote.Request Параметры примитива должны иметь следующий вид:

L_Remote.Request (

Identifier

DLC

)

Значение DLC равно длине поля данных запрошенного кадра данных.

8.2.2.5.3    Действие при получении

Прием данного примитива должен вызывать начало передачи нижним уровнем LLC блока LSDU путем использования службы передачи данных с удаленных узлов, предоставляемой нижним уровнем MAC (см. таблицу 5).

8.2.2.6    L_Remote.Indication

8.2.2.6.1    Назначение

Примитив L_Remote.Indication должен поступить от нижнего уровня LLC пользователю LLC для индикации поступления запроса на передачу блока LSDU.

8.2.2.6.2    Семантика примитива L_Remote.Indication Параметры примитива должны иметь следующий вид:

L_Remote.Indication (

Identifier

DLC

)

ГОСТ Р ИСО 11898-1-2015

Идентификатор должен идентифицировать подлежащий передаче блок LSDU. Значение DLC равно длине поля данных запрошенного кадра данных.

8.2.2.6.3 Действие при получении

Действие при получении данного примитива пользователем LLC не определено.

8.2.2.7 L_Remote.Confirm

8.2.2.7.1    Назначение

Примитив L_Remote.Confirm должен поступить от локального нижнего уровня LLC пользователю LLC для передачи результатов предыдущего примитива L_Remote.Request. Данный примитив должен являться локальным подтверждением, т. е. не должен означать, что удаленная подсистема LLC передала взаимосвязанный примитив индикации соответствующему пользователю LLC.

8.2.2.7.2    Семантика примитива L_Remote.Confirm

Параметры примитива должны иметь следующий вид:

L_Remote. Confirm    (

Identifier

Transfer_Status

)

Параметр Transfer_Status должен использоваться для индикации выполнения транзакции, начатой предыдущим примитивом L_Remote.Request.

Transfer_Status:[Complete (выполнено), Not_Complete (невыполнено)]

8.2.2.7.3    Действие при получении

Действие при получении данного примитива пользователем LLC не определено.

8.3    Функции нижнего уровня LLC

8.3.1    Общие сведения

Нижний уровень LLC должен обеспечивать следующие функции:

a)    фильтрацию доступности кадров;

b)    сообщение о перегрузке;

c)    управление восстановлением.

8.3.2    Фильтрация доступности кадров

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

8.3.3    Сообщение о перегрузке

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

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

8.3.4    Управление восстановлением

Нижний уровень LLC должен обеспечивать средства автоматической повторной передачи кадров, пропущенных при арбитраже или искаженных ошибками при передаче (см. 6.11). Служба передачи кадров не должна выдавать подтверждение пользователю до успешного завершения передачи.

8.4    Структура кадров LLC

8.4.1    Общие сведения

Кадры LLC должны являться блоками данных (LPDU), обмен которыми осуществляется между равноправными компонентами LLC. Структура и формат кадров данных и удаленного запроса LLC должны быть определены ниже.

8.4.2    Параметры кадра данных LLC

8.4.2.1 Общие сведения

Кадр данных LLC должен состоять из трех битовых полей (см. рисунок 3):

11

поле

поле

поле

идентификатора

кода

данных

DLC

LLC

Рисунок 3 — Кадр данных LLC

8.4.2.2    Поле идентификатора

Поле идентификатора должно состоять из трех сегментов: основного идентификатора, флага расширения и расширения идентификатора. Длина основного идентификатора должна составлять одиннадцать (11) бит (от ID-28 до ID-18), длина флага расширения — один бит, а длина расширения идентификатора должна составлять восемнадцать (18) бит (от ID-17 до ID-О). Расширение идентификатора должно игнорироваться, если флаг расширения равен логическому нулю (0).

8.4.2.3    Поле кода DLC

Количество байтов в поле данных должно быть указано кодом длины данных DLC (см. таблицу 4). Код DLC должен состоять из четырех (4) битов. Допустимое количество байтов данных для кадра данных должно составлять от нуля (0) до восьми (8). Коды DLC в диапазоне от нуля (0) до семи (7) должны сообщать о длине поля данных от нуля (0) до семи (7) байтов. Все прочие коды DLC должны сообщать о длине поля данных в восемь (8) байтов.

Таблица 4 — Кодирование количества байтов данных с помощью DLC

Количество байтов данных

DLC

DLC3

DLC2

DLC1

DLC0

0

0

0

0

0

1

0

0

0

1

2

0

0

1

0

3

0

0

1

1

4

0

1

0

0

5

0

1

0

1

6

0

1

1

0

7

0

1

1

1

8

1

0 или 1

0 или 1

0 или 1

8.4.2.4 Поле данных

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

8.4.3 Параметры кадра удаленного запроса LLC

Кадр удаленного запроса LLC должен состоять из двух битовых полей (см. рисунок 4):

поле

поле кода

идентификатора

DLC

Рисунок 4 — Кадр удаленного запроса LLC

Формат обоих полей кадра удаленного запроса LLC (поля идентификатора и поля DLC) должен быть идентичен форматам поля идентификатора LLC (см. 8.4.2.2) и поля DLC кадра данных LLC (см. 8.4.2.3). Поле данных присутствовать не должно вне зависимости от значения кода DLC.

Кадры удаленного запроса могут передаваться только с определенным в масштабе всей системы значением DLC, которое является кодом DLC соответствующего кадра данных (см. 10.8.8).

12

ГОСТ Р ИСО 11898-1-2015

8.5 Ограниченные кадры LLC

В реализации полного диапазона возможных значений идентификаторов и кодов DLC нет необходимости.

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

Если нижний уровень LLC ограничен использованием менее чем восьми (8) байтов данных, то кадры данных LLC и кадры удаленного запроса LLC ограничиваются использованием кодов DLC этого ограниченного диапазона.

9 Интерфейс LLC-MAC

9.1    Службы

Нижний уровень MAC должен обеспечивать службы для взаимодействия с LLC для:

-    передачи кадров LLC с подтверждением приема (MAC) и

-    передачи кадров перегрузки MAC.

Интерфейсные служебные данные, поступающие от нижнего уровня LLC или к нему, должны соответствовать 8.3.

9.2    Опция ТТС

9.2.1    Описание

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

Между LLC и MAC должно присутствовать оборудование, организующее ТТС.

9.2.2    Шкала времени

Любой узел, поддерживающий опцию ТТС, должен обеспечить формирование шкалы времени. Шкала времени — это накапливающий счетчик как минимум на 16 битов либо с внутренней, либо с внешней синхронизацией.

9.2.3    Начало отсчета времени

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

9.2.4    Формирование события

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

Триггер должен свободно программироваться CPU в пределах как минимум от нуля (0) до (216 - 1)х показания счетчика времени.

9.2.5    Повторная передача кадров

Должен поддерживаться запрет автоматической повторной передачи кадров (см. 6.11).

13

10 Описание нижнего уровня MAC

10.1    Общие сведения

Нижний уровень MAC представляет собой нижнюю часть канального уровня ВОС. Он должен обслуживать интерфейс нижнего уровня LLC и физического уровня, а также включать в себя функции и правила, относящиеся к:

-    формированию/расформированию передаваемых и принимаемых данных,

-    обнаружению ошибок и

-    управлению доступом к каналу передачи и приема.

10.2    Службы нижнего уровня MAC

10.2.1    Описание служб

Службы, управляемые нижним уровнем MAC, должны допускать информационный обмен блоками данных MSDU локального компонента нижнего уровня LLC с равноправными компонентами нижнего уровня LLC. В состав служб нижнего уровня MAC должны входить:

a)    Передача данных с подтверждением приема

Эта служба должна обеспечивать средства обмена компонентов LLC блоками MSDU без установления соединения на канальном уровне. Передача данных может осуществляться методами «точка — точка», мультикаста или широкого вещания.

b)    Удаленный запрос данных с подтверждением приема

Эта служба должна обеспечивать средства, дающие возможность запроса компонентом LLC на передачу блока LSDU другим удаленным узлом без установления соединения на канальном уровне. Удаленный компонент LLC должен использовать службу MAC «передача данных с подтверждением приема» для передачи запрошенных данных. Подтверждение приема службой должно формироваться нижними уровнями MAC удаленных узлов. Подтверждение приема не должно содержать каких-либо сведений о пользователе удаленного узла.

c)    Передача кадра перегрузки

Эта служба должна обеспечивать средства, с помощью которых компонент LLC начинает передачу кадра перегрузки, блока LPDU особого фиксированного формата, который вызывает задержку передачи следующего кадра данных или кадра удаленного запроса.

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

10.2.2.1 Общие сведения

Служебные примитивы нижнего уровня MAC, предусмотренные для нижнего уровня LLC, должны соответствовать перечисленным в таблице 5.

Таблица 5 — Служебные примитивы нижнего уровня MAC

Передача данных с подтверждением приема

MA_Data. request

MA_Data. indication

MA_Data.confirm

Удаленный запрос данных с подтверждением приема

MA_Remote. request

MA_Remote. indication

MA_Remote. confirm

Передача кадра перегрузки

MA_OVLD. request

MA_OVLD. indication

MA_OVLD. confirm

10.2.2.2 MA_Data.Request

10.2.2.2.1    Назначение

Примитив MA_Data.Request должен поступить от нижнего уровня LLC на нижний уровень MAC для запроса на передачу MSDU одному или нескольким удаленным компонентам MAC.

10.2.2.2.2    Семантика примитива MA_Data.Request Параметры примитива должны иметь следующий вид:

MA_Data. Request (

Identifier

DLC

Data

)

ГОСТ Р ИСО 11898-1-2015

Параметр Data не является значащим для данных нулевой длины.

10.2.2.2.3    Действие при получении

Прием данного примитива должен вызывать подготовку нижним уровнем MAC блока данных PDU путем добавления всей специфичной для уровня MAC информации управления (SOF, бита SRR, бита IDE, бита RTR, резервных битов, CRC, рецессивного бита во время интервала подтверждения приема, EOF) в блок MSDU, поступающий от нижнего уровня LLC. Блок PDU уровня MAC должен быть приведен в последовательную форму и передан бит за битом как блок SDU на физический уровень для передачи равноправному компоненту или компонентам нижнего уровня MAC.

10.2.2.3    MA_Data.Indication

10.2.2.3.1    Назначение

Примитив MA_Data.Indication должен поступить от нижнего уровня MAC на нижний уровень LLC для сообщения о поступлении блока MSDU.

10.2.2.3.2    Семантика примитива MA_Data.Indication

Параметры примитива должны иметь следующий вид:

MA_Data. Indication    (

Identifier

DLC

Data

)

Параметр Data не является значащим, если соответствующий кадр данных MAC имеет нулевую длину данных. Нижнему уровню LLC о получении MSDU должно сообщаться только при правильности приема.

10.2.2.3.3    Действие при получении

Действие при получении данного примитива нижним уровнем LLC не определено.

10.2.2.4    MA_Data.Confirm

10.2.2.4.1    Назначение

Примитив MA_Data.Confirm должен поступить от локального нижнего уровня MAC на нижний уровень LLC для передачи результатов предыдущего примитива MA_Data.Request. Данный примитив должен являться удаленным подтверждением, т. е. должен означать, что удаленный(ые) компонент (компоненты) MAC передал (передали) соответствующий примитив индикации соответствующим пользователям.

10.2.2.4.2    Семантика примитива MA_Data.Confirm

Параметры примитива должны иметь следующий вид:

MA_Data. Confirm (

Identifier

Transmission_Status

)

Параметр Transmission_Status должен использоваться для индикации успешности или неуспеш-ности передачи предыдущего примитива A_Data.Request.

Transmission_Status:[Success (успешно), No_Success (неуспешно)]

Сбои являются либо ошибками, возникшими при передаче, либо пропусками при арбитраже.

10.2.2.4.3    Действие при получении

Действие при получении данного примитива нижним уровнем LLC не определено.

10.2.2.5    MA_Remote.Request

10.2.2.5.1    Назначение

Примитив MA_Remote.Request должен поступить от нижнего уровня LLC на нижний уровень MAC для запроса одного удаленного компонента MAC на передачу MSDU.

10.2.2.5.2    Семантика примитива MA_Remote.Request

Параметры примитива должны иметь следующий вид:

MA_Remote.Request (

Identifier

DLC

)

Идентификатор должен идентифицировать блок MSDU, подлежащий передаче. Значение DLC должно равняться длине запрошенных данных MSDU.

15

10.2.2.5.3 Действие при получении

Прием данного примитива должен вызывать подготовку нижним уровнем MAC блока данных PDU путем добавления всей специфичной для уровня MAC информации управления (SOF, бита SRR, бита IDE, бита RTR, резервных битов, CRC, рецессивного бита во время интервала подтверждения приема, EOF) в блок MSDU, поступающий от нижнего уровня LLC. Блок PDU уровня MAC должен быть приведен в последовательную форму и передан бит за битом как блок SDU на физический уровень для передачи равноправному компоненту или компонентам нижнего уровня MAC.

10.2.2.6    MA_Remote.Indication

10.2.2.6.1    Назначение

Примитив MA_Remote.Indication должен поступить от нижнего уровня MAC на нижний уровень LLC для индикации получения запроса на передачу MSDU.

10.2.2.6.2    Семантика примитива MA_Remote.Indication

Параметры примитива должны иметь следующий вид:

MA_Remote.Indication (

Identifier

DLC

)

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

10.2.2.6.3    Действие при получении

Действие при получении данного примитива нижним уровнем LLC не определено.

10.2.2.7    MA_Remote.Confirm

10.2.2.7.1    Назначение

Примитив MA_Remote.Confirm должен поступить от локального нижнего уровня MAC на нижний уровень LLC для передачи результатов предыдущего примитива MA_Remote.Request. Этот примитив является удаленным подтверждением, т. е. он должен сообщить о том, что удаленный компонент или компонент MAC передали взаимосвязанный примитив индикации соответствующим пользователям.

10.2.2.7.2    Семантика примитива MA_Remote.Confirm

Параметры примитива должны иметь следующий вид:

MA_Remote. Confirm    (

Identifier

Transmission_Status

)

Параметр Transmission_Status должен использоваться для индикации успешности или неуспеш-ности передачи предыдущего примитива MA_Remote.Request.

Transmission_Status:[Success (успешно), No_Success (неуспешно)]

Сбои являются либо ошибками, возникшими при передаче, либо пропусками при арбитраже.

10.2.2.7.3    Действие при получении

Действие при получении данного примитива нижним уровнем LLC не определено.

10.2.2.8    MA_OVLD.Request

10.2.2.8.1    Назначение

Примитив MA_OVLD.Request должен поступить от нижнего уровня LLC на нижний уровень MAC для запроса передачи кадра перегрузки MAC OVLD (см. 10.4.5). Кадр OVLD должен являться кадром фиксированного формата и полностью формироваться нижним уровнем MAC.

10.2.2.8.2    Семантика примитива MA_OVLD.Request

Примитив не должен содержать каких-либо параметров:

MA_OVLD.request (

)

10.2.2.8.3    Действие при получении

Прием этого примитива должен вызывать формирование нижним уровнем MAC кадра перегрузки. Кадр перегрузки должен поступить в протоколы нижнего уровня для передачи в равноправные компоненты нижнего уровня MAC.

10.2.2.9    MA_OVLD.Indication

10.2.2.9.1 Назначение

Примитив MA_OVLD.Indication должен поступить от нижнего уровня MAC на нижний уровень LLC для индикации приема кадра перегрузки (см. 10.4.5).

16

ГОСТ Р ИСО 11898-1-2015

Содержание

1    Обзор..................................................................................1

2    Соответствие требованиям.................................................................1

3    Нормативные ссылки......................................................................1

4    Термины и определения...................................................................2

5    Сокращения.............................................................................3

6    Основные понятия CAN....................................................................3

6.1    Свойства CAN........................................................................3

6.2    Кадры...............................................................................4

6.3    Метод доступа к шине.................................................................4

6.4    Передача информации.................................................................4

6.5    Универсальность системы..............................................................4

6.6    Целостность данных...................................................................4

6.7    Удаленный запрос данных..............................................................4

6.8    Обнаружение ошибок..................................................................4

6.9    Сигнализация об ошибках и время восстановления.........................................5

6.10    Подтверждение приема (АСК)..........................................................5

6.11    Автоматический повтор передачи.......................................................5

6.12    Локализация ошибок.................................................................5

6.13    Активность при ошибках..............................................................5

6.14    Пассивность при ошибках.............................................................5

6.15    Отключение от шины.................................................................5

7    Иерархическая архитектура CAN............................................................5

7.1    Соответствие модели взаимосвязи открытых систем (ВОС)..................................5

7.2    Технические характеристики протокола...................................................6

7.3    Описание формата служб..............................................................7

7.4    Интерфейс LLC.......................................................................8

8    Описание нижнего уровня LLC..............................................................8

8.1    Общие сведения......................................................................8

8.2    Службы нижнего уровня LLC............................................................8

8.3    Функции нижнего уровня LLC..........................................................11

8.4    Структура кадров LLC................................................................11

8.5    Ограниченные кадры LLC.............................................................13

9    Интерфейс LLC — MAC...................................................................13

9.1    Службы............................................................................13

9.2    Опция ТТС..........................................................................13

10    Описание нижнего уровня MAC...........................................................14

10.1    Общие сведения...................................................................14

10.2    Службы нижнего уровня MAC........................................................14

10.3    Функциональная модель нижнего уровня MAC...........................................17

10.4    Структура кадров MAC..............................................................18

10.5    Кодирование кадра.................................................................23

10.6    Порядок передачи битов.............................................................24

10.7    Подтверждение кадра...............................................................24

10.8    Доступ к каналу связи...............................................................24

10.9    Обнаружение ошибок...............................................................25

10.10    Сигнализация об ошибках..........................................................26

10.11    Сигнализация о перегрузке..........................................................26

10.12    Мониторинг шины.................................................................26

11    Технические требования к нижним уровням LLC и MAC.......................................26

12    Физический уровень.....................................................................26

12.1    Общие сведения...................................................................26

12.2    Функциональная модель.............................................................27

12.3    Службы физического уровня.........................................................27

12.4    Параметры нижнего уровня PLS......................................................28

12.5    Параметры интерфейса PLS—РМА....................................................31

13    Описание супервайзера.................................................................31

13.1    Предотвращение ошибок............................................................31

13.2    Управление отказами на шине........................................................36

Библиография............................................................................37

Приложение ДА (справочное) Сведение о соответствии ссылочного международного стандарта

национальному стандарту Российской Федерации................................38

III

ГОСТ Р ИСО 11898-1-2015

10.2.2.9.2    Семантика примитива MA_OVLD.Indication Примитив не должен содержать каких-либо параметров:

MA_OVLD. Indication    (

)

10.2.2.9.3    Действие при получении

Действие при получении данного примитива нижним уровнем LLC не определено.

10.2.2.10 MAJDVLD.Confirm

10.2.2.10.1    Назначение

Примитив MA_OVLD.Confirm должен поступить от нижнего уровня MAC на нижний уровень LLC для индикации пересылки кадра перегрузки. Это подтверждение должно быть локальным, т. е. оно не должно означать, что компонент удаленного равноправного протокола правильно принял кадр перегрузки.

10.2.2.10.2    Семантика примитива MA_OVLD.Confirm Параметры примитива должны иметь следующий вид.

MA_OVLD.Confirm (

Transmission_Status

)

Параметр Transmission_Status должен использоваться для индикации успешности или неуспеш-ности передачи предыдущего примитива MA_OVLD.request.

Transmission_Status:[Success (успешно), No_Success (неуспешно)]

10.2.2.10.3    Действие при получении

Действие при получении данного примитива нижним уровнем LLC не определено.

10.3    Функциональная модель нижнего уровня MAC

10.3.1    Возможности

Функциональные возможности нижнего уровня MAC описываются при помощи функциональной модели, предписанной ИСО/МЭК 8802-3 (см. также рисунок 5). В этой модели нижний уровень MAC подразделяется на две полностью независимо действующих части: передачу и прием. Функции как приемной, так и передающей частей должны соответствовать данным настоящего подраздела с учетом рисунка 5.

10.3.2    Передача кадра

Передача кадра должна соответствовать следующим требованиям:

a)    формирование передаваемых данных:

1)    прием кадров LLC и информации управления интерфейсом,

2)    вычисление последовательности CRC,

3)    формирование кадра MAC путем добавления всей специфичной для уровня MAC информации управления (SOF, бита SRR, бита IDE, бита RTR, резервных битов, CRC, рецессивного бита во время интервала подтверждения приема, EOF) в кадр LLC. Ограниченные подуровни LLC могут не требовать передачи кадров MAC с идентификаторами или полями данных, не соответствующих их ограничениям, см. 8.5;

b)    управление доступом к каналу передачи:

1)    начало процесса передачи после распознавания свободного состояния шины (в соответствии с междукадровым промежутком),

2)    преобразованием кадра MAC в последовательную форму,

3)    вставка дополняющих битов (заполнение битами),

4)    арбитраж и переход в режим приема в случае пропуска при арбитраже,

5)    обнаружение ошибок (мониторинг, проверка формата),

6)    проверка подтверждения приема,

7)    определение состояния перегрузки,

8)    формирование кадра перегрузки и начало передачи,

9)    формирование кадра ошибки и начало передачи,

10)    представление последовательного битового потока на физический уровень для передачи.

17

Введение

ИСО (International Organization for Standardization — международная организация по стандартизации) — это всемирная федерация национальных органов по стандартизации (членов ИСО). Работа по подготовке международных стандартов обычно выполняется техническими комитетами ИСО. Каждая организация — член ИСО, заинтересованная в предмете, для которого создается технический комитет, имеет право на представительство в этом комитете. В сотрудничестве с ИСО в этой работе также принимают участие международные организации, правительственные и неправительственные. ИСО тесно сотрудничает с Международной электротехнической комиссией (International Electrotechnical Commission — IEC — МЭК) по всем вопросам стандартизации электротехнического оборудования.

Международные стандарты составляются в соответствии с правилами, предписанными частью 2 директив ИСО/МЭК.

Главная задача технических комитетов — подготовка международных стандартов. Проекты международных стандартов, принятых техническими комитетами, рассылаются членам ИСО для голосования. Для публикации в качестве международного стандарта необходимо одобрение не менее чем 75 % участников голосования.

Особое внимание уделяется возможности того, что какие-либо составные части данного документа могут оказаться предметом патентного законодательства. ИСО не может нести ответственности за идентификацию всех или каких-либо патентных прав.

Первая редакция стандарта ИСО 11898-1 совместно с ИСО 11898-2 заменяет ИСО 11898:1993, который был технически пересмотрен. Поскольку замененный международный стандарт покрывал как уровень передачи данных CAN (DLL — Data Link Layer — канальный уровень), так и высокоскоростной физический уровень (PL— Physical Layer— физический уровень), ИСО 11898-1 определяет уровень передачи данных, включая нижние уровни LLC (Logical Link Control — управление логической связью) и MAC (Medium Access Control — управление доступом к каналу связи), а также нижний уровень PLS (Physical Signalling — физическая передача сигналов), тогда как ИСО 11898-2 определяет уровень высокоскоростного доступа к среде передачи данных MAU (Medium Access Unit — устройство доступа к каналу связи).

ИСО 11898 под общим названием «Транспорт дорожный. Местная контроллерная сеть (CAN)» состоит из следующих частей:

-    часть 1. Канальный уровень и передача сигналов;

-    часть 2. Устройство высокоскоростного доступа к каналу связи;

-    часть 3. Низкоскоростной устойчивый к ошибкам интерфейс, зависящий от канала;

-    часть 4. Взаимодействие с разделением доступа по времени.

IV

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Транспорт дорожный

МЕСТНАЯ КОНТРОЛЛЕРНАЯ СЕТЬ (CAN)

Часть 1

Канальный уровень и передача сигналов

Road vehicles. Controller area network (CAN). Part 1. Data link layer and physical signalling

Дата введения — 2016—08—01

1    Обзор

Настоящий стандарт определяет канальный уровень (DLL) и уровень физической передачи сигналов сети контроллеров (CAN). Это протокол последовательной передачи данных, который поддерживает распределенное управление в реальном времени и мультиплексирование данных для использования в дорожных транспортных средствах. Протокол описывает общую архитектуру шины CAN в виде иерархии уровней в соответствии с эталонной моделью ИСО для ВОС — взаимосвязи открытых систем (OSI), установленной ИСО/МЭК 7498-1, и представляет технические характеристики для построения системы информационного обмена цифровой информацией между модулями, формирующими канальный уровень CAN. Этот уровень сам по себе оговаривается в соответствии с ИСО/МЭК 8802-2 и ИСО/МЭК 8802-3 — с подробным описанием характеристик нижнего уровня управления логической связью (LLC) и нижнего уровня управления доступа к среде передачи данных (MAC).

2    Соответствие требованиям

Соответствие канального уровня требованиям должно проверяться в соответствии с ИСО 16845.

3    Нормативные ссылки

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

ИСО/МЭК 7498-1, Информационные технологии. Взаимосвязь открытых систем. Базовая эталонная модель: Базовая модель (ISO/IEC 7498-1 Information technology — Open Systems Interconnection — Basic reference model — Part 1: The basic model)

ИСО/МЭК 8802-2, Информационные технологии. Телекоммуникации и обмен информацией между системами. Локальные общегородские сети. Специальные требования. Часть 2. Управление логическим звеном (ISO/IEC 8802-2 Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 2: Logical link control)

ИСО/МЭК 8802-3, Информационные технологии. Телекоммуникации и обмен информацией между системами. Локальные общегородские сети. Специальные требования. Часть 3. Метод доступа (CSMA/CD) с обнаружением столкновений и спецификации физического уровня (ISO/IEC 8802-3 Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications)

ИСО 16845, Транспорт дорожный. Сеть области контроллера. План проверки соответствия (ISO 16845 Road vehicles — Controller area network (CAN) — Conformance test plan)

Издание официальное

4 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями.

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

4.2    заполнение битами: Метод кодирования кадров, обеспечивающий изменение состояния шины, необходимое для ее периодической реорганизации при использовании двоичного представления NRZ (без возврата к нулевому уровню).

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

4.3    битовый интервал: fB: Длительность одного бита.

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

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

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

4.7    состояние шины: Одно из двух взаимно дополняющих состояний: доминантное и рецессивное.

Примечание — Доминантное состояние представляется логическим нулем, а рецессивное состояние представляется логической единицей. При одновременной передаче доминантных и рецессивных битов итоговое состояние шины —доминантное. Если передачи не происходит, шина свободна. В это время она находится в рецессивном состоянии.

4.8    арбитраж по содержимому: Процедура арбитража при коллективном доступе с контролем состояния канала (CSMA) разрешает возникающие на шине конфликты при одновременном доступе к шине нескольких узлов.

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

4.10    многоадресная передача: Способ адресации, при которой один кадр адресуется целой группе узлов одновременно.

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

4.11    мультимастер: Система, разделенная на несколько узлов, в которой каждый узел может временно управлять работой других узлов.

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

Примечание — Узел CAN — это узел, осуществляющий взаимодействие по сети CAN.

4.13    без возврата к нулевому уровню: Метод представления двоичных сигналов, при котором в пределах одного и того же битового интервала уровень сигнала не изменяется и поток битов имеет один и тот же логический уровень, не имея фронтов.

4.14    приоритет: Атрибут кадра, регулирующий его положение в иерархии при арбитраже, при этом более высокий приоритет повышает вероятность выбора кадра в процессе арбитража.

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

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

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

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

2

ГОСТ Р ИСО 11898-1-2015

5 Сокращения

АСК

ВСН

BR

подтверждение приема; код Боуза-Чоудхури-Хоквингема (БЧХ); скорость передачи данных; битовый интервал;


CAN — сеть контроллеров;

CRC — циклический контроль избыточности;

CSMA — коллективный доступ с контролем состояния канала; DLC — код длины данных;

DLL — канальный уровень;

EOF — конец кадра;

FCE — система обработки ошибок;

1C — интегральная схема;

IDE — расширение идентификатора;

LAN — локальная вычислительная сеть;

LLC — управление логической связью;

LME — система управления уровнем;

LPDU — протокольный блок данных LLC;

LSB — младший значащий бит;

LSDU — сервисный блок данных LLC;

МА — доступ к каналу связи;

MAC — управление доступом к каналу связи;

MALI — устройство доступа к каналу связи;

MDI —интерфейс канала связи;

MPDU — протокольный блок данных MAC;

MSB — старший значащий бит;

MSDU —сервисный блок данных MAC;

NRZ — без возврата к нулю;

OSI — взаимосвязь открытых систем (БОС);

OVLD — перегрузка;

PCI — управляющая информация протокола;

PDU —протокольный блок данных;

PL — физический уровень;

PLS — физическая передача сигналов;

РМА — подсоединение к физическому каналу;

REC — счетчик ошибок приема;

RTR — удаленный запрос передачи;

SAP — точка доступа к службе;

SDU —сервисный блок данных;

SJW — ширина перехода синхронизации;

SOF — начало кадра;

SRR — подмена запроса на передачу;

ТЕС — счетчик ошибок передачи;

ТТС — взаимодействие с разделением доступа по времени.

6 Основные понятия CAN

6.1 Свойства CAN

Шина CAN должна обладать следующими свойствами:

-    доступ к шине по принципу мультимастера на основе приоритета;

-    недеструктивный арбитраж по содержимому;


3


-    групповая передача кадров с полосовой фильтрацией;

-    удаленный запрос данных;

-    универсальность конфигурации;

-    целостность данных в пределах всей системы;

-    обнаружение ошибок и сигнализация об ошибках;

-    автоматическая повторная передача кадров, пропущенных при арбитраже или нарушенных ошибками при передаче;

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

6.2    Кадры

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

6.3    Метод доступа к шине

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

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

6.4    Передача информации

В системах CAN узел не должен пользоваться какой-либо информацией о конфигурации системы (например, адресами узлов). Вместо этого приемники принимают или не принимают информацию на основе процесса, который носит название фильтрация приема кадра. При этом принимается решение о соответствии или несоответствии принятой информации. Для приемников нет необходимости знать, откуда передается информация, и наоборот.

6.5    Универсальность системы

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

6.6    Целостность данных

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

6.7    Удаленный запрос данных

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

6.8    Обнаружение ошибок

Для обнаружения ошибок должны быть предусмотрены следующие меры:

-    мониторинг (передатчики сравнивают уровни битов, которые должны передаваться, с уровнями битов, присутствующими на шине);

-    контроль при помощи 5-разрядного циклического избыточного кода;

-    переменное заполнение битами с шириной заполнения, равной 5;

-    проверка кадра;

-    проверка подтверждения приема.

ГОСТ Р ИСО 11898-1-2015

6.9    Сигнализация об ошибках и время восстановления

Поврежденные кадры должны сигнализироваться признаками любым передающим узлом и любым работающим в обычном режиме (активным к ошибкам) принимающим узлом. Такие кадры должны отменяться и передаваться повторно в соответствии с реализованной процедурой восстановления (см. 8.3.4). Время восстановления (интервал между обнаружением ошибки и возможностью начала передачи следующего кадра) должно иметь типовое значение от 17 до 23 битовых интервалов [в случае очень сильных помех на шине — до 31-го битового интервала], если не происходит новых ошибок.

6.10    Подтверждение приема (АСК)

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

6.11    Автоматический повтор передачи

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

6.12    Локализация ошибок

Узлы шины CAN должны иметь возможность отличать кратковременные сбои от постоянных отказов. Дефективные передающие узлы должны отключаться. «Отключение» означает логическое отсоединение узла от шины таким образом, чтобы он не смог ни передавать, ни принимать никаких кадров (см. 13.1.4.4).

6.13    Активность при ошибках

Активный к ошибкам узел должен, как обычно, принимать участие во взаимодействии на шине и пересылать активный флаг ошибки при обнаружении ошибки. Активный флаг ошибки должен состоять из шести (6) последовательных доминантных битов и должен допускать нарушение правила вставки дополняющих битов и любых фиксированных форматов, использующихся в обычных кадрах (см. 13.1.4.2).

6.14    Пассивность при ошибках

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

6.15    Отключение от шины

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

7 Иерархическая архитектура CAN

7.1 Соответствие модели взаимосвязи открытых систем (ВОС)

В соответствии с эталонной моделью ВОС архитектура CAN, описанная в настоящем стандарте, должна состоять из двух частей:

-    канальный уровень (DLL) и

-    физический уровень (PL).

5

Смотри рисунок 1.

Канальный уровень(DLL)

Управление логической связью (LLC)

Полосовая фильтрация Сообщение о перегрузке Управление восстановлением

Г

\

\

Управление доступом к каналу связи (MAC)

Упаковка/извлечение данных. Кодирование кадра (формирование/

\

\ 1 \ 1

\| i ■ )|

/расформирование). Управление доступом к каналу. Обнаружение ошибок. Сигнализация об ошибках. Подтверждение приема. Последовательное и параллельное преобразование.

U

/1

л

/1 /1 / 1 / 1

/

Физический уровень(PL)

/

/

/

/

Физическая передача сигналов (PLS)

/ 1

/

*

11

Кодирование/декодирование битов. Интервал передачи бита. Синхронизация.

11

11

|

Подсоединение к физическому каналу (РМА)

Параметры передатчика/приемника.

1

1

Интерфейс канала связи (MDI)

Соединители.

1

i_

Локализация

ошибок

(MAC-LME)

Устранение ошибок на шине (PLS-LME)

Рисунок 1 — Иерархическая архитектура CAN


Супервайзер


В соответствии с ИСО/МЭК 8802-2 и ИСО/МЭК 8802-3 канальный уровень подразделяется на:

-    управление логической связью (LLC) и

-    управление доступом к каналу связи (MAC).

Физический уровень подразделяется на:

-    физическую передачу сигнала (PLS),

-    подсоединение к каналу связи (РМА) и

-    интерфейс канала связи (MDI).

Операции на нижнем уровне MAC должны контролироваться подсистемой обработки ошибок (FCE). Система локализации ошибок должна представлять собой механизм самодиагностики, который различает кратковременные сбои и постоянные отказы (о локализации ошибок см. 13.1).

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

7.2 Технические характеристики протокола

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

Блок протокольных данных сетевого уровня (NPDU) должен содержать блок управляющей информации протокола (N-PCI) и (N) блоков пользовательских данных. Блок NPDU должен проходить через

6