Полное меню
- Актуальное
законодательство - Интернет
и право- - Рассылка ''Закон есть закон''
- - Форум сайта (архив)
- - Законодательство
- - Судебная практика (необычная)
- - Судебная практика (авторская)
- - Процедура UDRP и и решения WIPO
- - Книги серии ''Интернет и Право''
- - Книги в открытом доступе
- - Учебный курс ''Интернет и Право''
- - Учебный курс ''Доменные споры''
- - Литература по ''Интернет и Право''
- - Литература по интел. собственности
- - Научный уголок (работы гостей)
- - Авторские публикации
- Информационные
материалы - ЮРИДИЧЕСКИЕ
УСЛУГИ- - Перечень юридических услуг
- - Карта юридических услуг
- - Юридическая консультация
- - Доменные споры (RU), авторское право
- - Международный суд по доменам (COM)
- - Защита прав на маркетплейсе (WB, Ozon)
- - Защита прав в соцсетях (Vk, Ok, FB)
- - Купля-продажа домена, сайта, ПО
- - Досудебное урегулирование конфликта
- - Защита чести и деловой репутации
- - Отмена блокировки сайта/домена РКН
- - ФАС: товарные знаки, авторское право
- - Регистрация ПО/сайта (Роспатент)
- - Юридическая проверка домена
- - Нотариальное заверение сайтов
- - Способы и формы оплаты услуг
- - Мы в СМИ
- - О компании, клиенты
- - Наши дела и победы
- - Контакты и реквизиты
- Информация
о сайте -
ОписаниеИсточник публикации М.: Стандартинформ, 2016 Примечание к документу Документ введен в действие с 1 августа 2016 года. Название документа "ГОСТ Р ИСО 11898-1-2015. Национальный стандарт Российской Федерации. Транспорт дорожный. Местная контроллерная сеть (CAN). Часть 1. Канальный уровень и передача сигналов" (утв. и введен в действие Приказом Росстандарта от 06.11.2015 N 1711-ст) "ГОСТ Р ИСО 11898-1-2015. Национальный стандарт Российской Федерации. Транспорт дорожный. Местная контроллерная сеть (CAN). Часть 1. Канальный уровень и передача сигналов"
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ACK | - | подтверждение приема; |
BCH | - | код Боуза-Чоудхури-Хоквингема (БЧХ); |
BR | - | скорость передачи данных; |
tB | - | битовый интервал; |
CAN | - | сеть контроллеров; |
CRC | - | циклический контроль избыточности; |
CSMA | - | коллективный доступ с контролем состояния канала; |
DLC | - | код длины данных; |
DLL | - | канальный уровень; |
EOF | - | конец кадра; |
FCE | - | система обработки ошибок; |
IC | - | интегральная схема; |
IDE | - | расширение идентификатора; |
LAN | - | локальная вычислительная сеть; |
LLC | - | управление логической связью; |
LME | - | система управления уровнем; |
LPDU | - | протокольный блок данных LLC; |
LSB | - | младший значащий бит; |
LSDU | - | сервисный блок данных LLC; |
MA | - | доступ к каналу связи; |
MAC | - | управление доступом к каналу связи; |
MAU | - | устройство доступа к каналу связи; |
MDI | - | интерфейс канала связи; |
MPDU | - | протокольный блок данных MAC; |
MSB | - | старший значащий бит; |
MSDU | - | сервисный блок данных MAC; |
NRZ | - | без возврата к нулю; |
OSI | - | взаимосвязь открытых систем (BOC); |
OVLD | - | перегрузка; |
PCI | - | управляющая информация протокола; |
PDU | - | протокольный блок данных; |
PL | - | физический уровень; |
PLS | - | физическая передача сигналов; |
PMA | - | подсоединение к физическому каналу; |
REC | - | счетчик ошибок приема; |
RTR | - | удаленный запрос передачи; |
SAP | - | точка доступа к службе; |
SDU | - | сервисный блок данных; |
SJW | - | ширина перехода синхронизации; |
SOF | - | начало кадра; |
SRR | - | подмена запроса на передачу; |
TEC | - | счетчик ошибок передачи; |
TTC | - | взаимодействие с разделением доступа по времени. |
Шина CAN должна обладать следующими свойствами:
- доступ к шине по принципу мультимастера на основе приоритета;
- недеструктивный арбитраж по содержимому;
- групповая передача кадров с полосовой фильтрацией;
- удаленный запрос данных;
- универсальность конфигурации;
- целостность данных в пределах всей системы;
- обнаружение ошибок и сигнализация об ошибках;
- автоматическая повторная передача кадров, пропущенных при арбитраже или нарушенных ошибками при передаче;
- различение кратковременных ошибок и постоянных отказов узлов, самостоятельное отключение дефективных узлов.
Информация на шине должна пересылаться в виде кадров фиксированного формата различной, но ограниченной длины. Если шина свободна, любой подключенный узел может начать передачу нового кадра.
Если шина свободна, любой узел может начать передачу кадра. Если два или более узла начинают передачу кадров одновременно, конфликт доступа к шине должен разрешаться путем арбитража по содержимому при помощи идентификаторов.
Механизм арбитража должен гарантировать отсутствие каких-либо потерь информации или времени. Преимущество на доступ к шине должен иметь передатчик, пересылающий кадр, который обладает самым высоким приоритетом.
В системах CAN узел не должен пользоваться какой-либо информацией о конфигурации системы (например, адресами узлов). Вместо этого приемники принимают или не принимают информацию на основе процесса, который носит название фильтрация приема кадра. При этом принимается решение о соответствии или несоответствии принятой информации. Для приемников нет необходимости знать, откуда передается информация, и наоборот.
Добавление узлов к сети CAN может производиться без необходимости в каких-либо изменениях в программном или аппаратурном обеспечении любого узла, если добавляемый узел не является передатчиком каких-либо кадров данных и если добавляемый узел не нуждается в каких-либо дополнительно пересылаемых данных.
Кадр в пределах сети CAN должен приниматься одновременно либо всеми узлами, либо ни одним. Таким образом, свойством системы должна являться целостность данных, достигаемая за счет реализации концепций мультикаста и обработки ошибок.
Путем пересылки кадра удаленного запроса данные запроса узла могут требовать от другого узла передачи соответствующего кадра данных. Кадр данных и соответствующий кадр удаленного запроса должны иметь один и тот же идентификатор.
Для обнаружения ошибок должны быть предусмотрены следующие меры:
- мониторинг (передатчики сравнивают уровни битов, которые должны передаваться, с уровнями битов, присутствующими на шине);
- контроль при помощи 5-разрядного циклического избыточного кода;
- переменное заполнение битами с шириной заполнения, равной 5;
- проверка кадра;
- проверка подтверждения приема.
Поврежденные кадры должны сигнализироваться признаками любым передающим узлом и любым работающим в обычном режиме (активным к ошибкам) принимающим узлом. Такие кадры должны отменяться и передаваться повторно в соответствии с реализованной процедурой восстановления (см. 8.3.4). Время восстановления (интервал между обнаружением ошибки и возможностью начала передачи следующего кадра) должно иметь типовое значение от 17 до 23 битовых интервалов [в случае очень сильных помех на шине - до 31-го битового интервала], если не происходит новых ошибок.
Все приемники должны проверять целостность принятых кадров и подтверждать прием целостного кадра, а также выставлять признак приема неправильного кадра. При отсутствии подтверждения приема кадра он считается поврежденным, а передающий узел должен пометить его флагом.
Кадры, пропущенные при арбитраже, и кадры, искаженные ошибками при передаче, должны автоматически пересылаться повторно после восстановления свободного состояния шины. Кадр, подлежащий повторной передаче, должен обрабатываться так же, как и любой другой кадр, т.е. участвовать в процессе арбитража для получения доступа к шине. При использовании разделения доступа по времени автоматическая повторная передача должна быть запрещена (см. 9.2.5).
Узлы шины CAN должны иметь возможность отличать кратковременные сбои от постоянных отказов. Дефективные передающие узлы должны отключаться. "Отключение" означает логическое отсоединение узла от шины таким образом, чтобы он не смог ни передавать, ни принимать никаких кадров (см. 13.1.4.4).
Активный к ошибкам узел должен, как обычно, принимать участие во взаимодействии на шине и пересылать активный флаг ошибки при обнаружении ошибки. Активный флаг ошибки должен состоять из шести (6) последовательных доминантных битов и должен допускать нарушение правила вставки дополняющих битов и любых фиксированных форматов, использующихся в обычных кадрах (см. 13.1.4.2).
Пассивный к ошибкам узел не должен пересылать активный флаг ошибки. Он принимает участие во взаимодействии на шине, однако при обнаружении ошибки должен пересылать пассивный флаг ошибки. Пассивный флаг ошибки должен состоять из шести (6) последовательных рецессивных битов. После их передачи пассивный к ошибкам узел должен ожидать в течение определенного интервала времени, прежде чем приступить к дальнейшей передаче (см. об отложенной передаче в 10.4.6.4 и 13.1.4.2).
Узел должен находиться в состоянии отключения от шины, если он отключается от шины по запросу FCE. В состоянии отключения от шины узел не должен ни передавать, ни принимать никаких кадров. В состоянии отключения от шины узел не должен передавать никаких доминантных битов.
В соответствии с эталонной моделью ВОС архитектура CAN, описанная в настоящем стандарте, должна состоять из двух частей:
- канальный уровень (DLL) и
- физический уровень (PL).
Смотри рисунок 1.
В соответствии с ИСО/МЭК 8802-2 и ИСО/МЭК 8802-3 канальный уровень подразделяется на:
- управление логической связью (LLC) и
- управление доступом к каналу связи (MAC).
Физический уровень подразделяется на:
- физическую передачу сигнала (PLS),
- подсоединение к каналу связи (PMA) и
- интерфейс канала связи (MDI).
Операции на нижнем уровне MAC должны контролироваться подсистемой обработки ошибок (FCE). Система локализации ошибок должна представлять собой механизм самодиагностики, который различает кратковременные сбои и постоянные отказы (о локализации ошибок см. 13.1).
Физический уровень может контролироваться подсистемой, которая обнаруживает и обрабатывает ошибки в физическом канале связи.
При обмене кадрами или протокольными блоками данных (PDU) должно осуществляться взаимодействие друг с другом двух равноправных подсистем протокола.
Блок протокольных данных сетевого уровня (NPDU) должен содержать блок управляющей информации протокола (N-PCI) и (N) блоков пользовательских данных. Блок NPDU должен проходить через (N - 1) подсистем уровня посредством (N - 1) точек доступа к службам (SAP). Блок NPDU должен проходить с помощью (N - 1) сервисных блоков данных (SDU) на уровень (N - 1), службы которого позволяют передать блок NPDU. Блоки SDU должны представлять собой интерфейсные данные, идентичность которых сохраняется между подсистемами (N) уровней, т.е. являться блоками логических данных, пересылаемых службой. Канальный уровень протокола CAN не должен обеспечивать ни средства распределения одного блока SDU в несколько блоков PDU, ни сведения нескольких SDU в один PDU, т.е. NPDU непосредственно формируется из взаимосвязанных блоков NSDU и специфической для уровня управляющей информации N-PCI. На рисунке 2 показано взаимодействие на нижнем канальном уровне.
Рисунок 2 - Взаимодействие уровней протокола
7.3.1 Описание формата служебных примитивов
Служебные примитивы должны описываться как
служба.тип(
[параметр1,...]
),
где "служба" - это имя службы, например, L_Data для службы передачи данных, обеспечиваемой нижним уровнем LLC, "тип" - это тип служебного примитива (см. п. 7.3.2), а [параметр1,...] - это перечень значений, придаваемых служебному примитиву. Квадратные скобки означают, что этот перечень параметров может быть пустым.
7.3.2 Типы служебных параметров
Служебные примитивы должны относиться к одному из трех стандартных типов:
a) Service.Request
Примитив запроса должен поступать от N-го пользователя (пользователя службы) на N-й уровень (провайдер службы) для запроса запуска службы.
b) Service.Indication
Примитив индикации должен поступать от N-го уровня N-му пользователю для указания на внутреннее событие N-го уровня (или нижнего уровня), которое имеет значение для N-го пользователя. Это событие может быть логически связано с дистанционным запросом службы или может быть вызвано событием, внутренним для N-го уровня (или нижнего уровня).
c) Service.Confirm
Примитив подтверждения должен поступать от N-го уровня (или нижнего уровня) N-му пользователю для передачи результатов одного или более взаимосвязанных предыдущих запросов службы. Этот примитив может указывать либо на невыполнение, либо на ту или иную степень выполнения. Индикация какой-либо активности на удаленном равноправном интерфейсе не должна являться необходимой.
Нижний уровень LLC должен обеспечивать для своего пользователя два типа служб передачи данных без установления соединения:
a) службу передачи данных без подтверждения;
b) службу удаленного запроса данных без подтверждения.
Служебные данные интерфейса, пересылаемые от пользователя или к нему, должны соответствовать 8.2.2. Сообщения, пересылаемые между пользователем LLC и нижним уровнем LLC, должны соответствовать a) и b) таблицы 1.
Таблица 1
Сообщения, пересылаемые между пользователем LLC и нижним
уровнем LLC
Сообщение от пользователя к LLC | Значение |
Reset_Request | Запрос на установку узла в исходное состояние |
Сообщение от LLC к пользователю | Значение |
Reset_Response | Ответ на сообщение Reset_Request |
Node_Status | Вывод текущего состояния узла, т.е. информация о том, находится ли узел в состоянии отключения от шины |
Интерфейсные сообщения LLC от супервайзера FCE или к нему, должны соответствовать 13.1.3.
Нижний уровень LLC описывает верхнюю часть канального уровня ВОС. Он относится к тем аспектам протокола, которые не зависят от метода доступа к каналу связи.
8.2.1 Типы служб передачи без установления соединения
Нижний уровень LLC должен обеспечивать два типа служб передачи без установления соединения:
a) Служба передачи данных без подтверждения приема
Эта служба должна обеспечить средство обмена пользователей LLC блоками данных LSDU без установления соединения на канальном уровне. Передача данных может осуществляться методами "точка-точка", мультикаста или широкого вещания.
b) Служба удаленного запроса данных без подтверждения приема
Эта служба должна обеспечить средство запроса пользователем LLC удаленного узла для передачи блоков LSDU без установления соединения на канальном уровне.
Удаленный узел должен в основном обслуживать запрос данных двумя следующими способами:
1) запрошенные данные могут подготавливаться удаленным пользователем для передачи. В этом случае данные должны помещаться в буфер удаленного узла и передаваться подсистемой LLC удаленного пользователя после приема удаленного запроса кадра;
2) запрошенные данные должны передаваться удаленным пользователем после приема удаленного запроса кадра.
Для двух разных служб LLC должны использоваться два типа кадров, пересылаемых от пользователя или к нему:
- кадр данных LLC;
- кадр удаленного запроса LLC.
Кадр данных LLC должен переносить данные от передатчика к приемнику. Кадр удаленного запроса LLC должен передаваться для запроса передачи кадра данных (с тем же идентификатором) от (одного) удаленного узла. В обоих случаях нижний уровень LLC должен регистрировать успешную передачу или прием кадра пользователем.
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).
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
)
Идентификатор должен идентифицировать подлежащий передаче блок 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.1 Общие сведения
Нижний уровень LLC должен обеспечивать следующие функции:
a) фильтрацию доступности кадров;
b) сообщение о перегрузке;
c) управление восстановлением.
8.3.2 Фильтрация доступности кадров
Передача кадра, начатая на нижнем уровне LLC, должна быть отдельной самостоятельной операцией, не зависящей от предыдущих передач кадров. Содержимое кадра должно указываться его идентификатором. Идентификатор не должен указывать назначение кадра, однако описывает значимость данных. Каждый приемник может принять решение относительно фильтрации доступности кадра, является ли кадр соответствующим.
8.3.3 Сообщение о перегрузке
Передача кадра перегрузки MAC должна инициироваться нижним уровнем LLC, если внутренние условия приемника требуют задержки следующего кадра данных LLC или кадра удаленного запроса LLC.
Для задержки следующего кадра данных или кадра удаленного запроса может формироваться не более двух кадров перегрузки MAC.
Нижний уровень LLC должен обеспечивать средства автоматической повторной передачи кадров, пропущенных при арбитраже или искаженных ошибками при передаче (см. 6.11). Служба передачи кадров не должна выдавать подтверждение пользователю до успешного завершения передачи.
8.4.1 Общие сведения
Кадры LLC должны являться блоками данных (LPDU), обмен которыми осуществляется между равноправными компонентами LLC. Структура и формат кадров данных и удаленного запроса LLC должны быть определены ниже.
8.4.2.1 Общие сведения
Кадр данных LLC должен состоять из трех битовых полей (см. рисунок 3):
поле идентификатора | поле кода DLC | поле данных LLC |
Рисунок 3 - Кадр данных LLC
Поле идентификатора должно состоять из трех сегментов: основного идентификатора, флага расширения и расширения идентификатора. Длина основного идентификатора должна составлять одиннадцать (11) бит (от ID-28 до ID-18), длина флага расширения - один бит, а длина расширения идентификатора должна составлять восемнадцать (18) бит (от ID-17 до ID-0). Расширение идентификатора должно игнорироваться, если флаг расширения равен логическому нулю (0).
Количество байтов в поле данных должно быть указано кодом длины данных DLC (см. таблицу 4). Код DLC должен состоять из четырех (4) битов. Допустимое количество байтов данных для кадра данных должно составлять от нуля (0) до восьми (8). Коды DLC в диапазоне от нуля (0) до семи (7) должны сообщать о длине поля данных от нуля (0) до семи (7) байтов. Все прочие коды DLC должны сообщать о длине поля данных в восемь (8) байтов.
Таблица 4
Количество байтов данных | 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).
В реализации полного диапазона возможных значений идентификаторов и кодов DLC нет необходимости.
Если нижний уровень LLC ограничен использованием одного поддиапазона идентификаторов (например, только основных идентификаторов), то кадры данных LLC и кадры удаленного запроса LLC ограничиваются использованием идентификаторов данного поддиапазона (например, идентификаторами с флагом расширения, установленным в значение логического нуля и игнорированием их расширений идентификаторов).
Если нижний уровень LLC ограничен использованием менее чем восьми (8) байтов данных, то кадры данных LLC и кадры удаленного запроса LLC ограничиваются использованием кодов DLC этого ограниченного диапазона.
Нижний уровень MAC должен обеспечивать службы для взаимодействия с LLC для:
- передачи кадров LLC с подтверждением приема (MAC) и
- передачи кадров перегрузки MAC.
Интерфейсные служебные данные, поступающие от нижнего уровня LLC или к нему, должны соответствовать 8.3.
9.2.1 Описание
Опция TTC (взаимодействие с разделением по времени) организует необходимые условия для синхронизации всех узлов сети. При помощи синхронизации узлов любое сообщение от него может быть передано в пределах заданного интервала времени, в течение которого не должна выполняться обработка шиной других сообщений. Таким образом обеспечивается формирование предсказуемых интервалов задержки и избежание пропусков при арбитраже. С целью синхронизации работы всех узлов сети необходима общая точка отсчета. В качестве точки отсчета должны использоваться бит начала кадра (SOF) или выборочная точка последнего бита конца кадра (EOF) любого сообщения. Индивидуальное присутствие только одного сообщения одновременно должно рассматриваться как основа для планирования передачи кадров. Кроме того, на основе синхронизации узлов TTC способствует установлению системы глобального времени для протоколов верхних уровней.
Между LLC и MAC должно присутствовать оборудование, организующее TTC.
9.2.2 Шкала времени
Любой узел, поддерживающий опцию TTC, должен обеспечить формирование шкалы времени. Шкала времени - это накапливающий счетчик как минимум на 16 битов либо с внутренней, либо с внешней синхронизацией.
9.2.3 Начало отсчета времени
Любое принимаемое или передаваемое сообщение должно вызывать захват шкалы времени, предпринимаемый в момент обнаружения бита начала кадра (SOF) соответствующего сообщения или выборочной точки последнего бита конца кадра (EOF). После успешного приема сообщения для CPU должно быть сформировано сообщение о захвате для не менее чем одного сообщения. Оно должно оставаться доступным для считывания до приема следующего сообщения.
9.2.4 Формирование события
Должна обеспечиваться возможность формирования не менее одного программируемого триггера события на основе вышеупомянутой шкалы времени.
Триггер должен свободно программироваться CPU в пределах как минимум от нуля (0) до (216 - 1)x показания счетчика времени.
Должен поддерживаться запрет автоматической повторной передачи кадров (см. 6.11).
Нижний уровень MAC представляет собой нижнюю часть канального уровня ВОС. Он должен обслуживать интерфейс нижнего уровня LLC и физического уровня, а также включать в себя функции и правила, относящиеся к:
- формированию/расформированию передаваемых и принимаемых данных,
- обнаружению ошибок и
- управлению доступом к каналу передачи и приема.
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
Передача данных с подтверждением приема | ||
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
)
Параметр 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.
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).
10.2.2.9.2 Семантика примитива MA_OVLD.Indication
Примитив не должен содержать каких-либо параметров:
MA_OVLD.Indication (
)
10.2.2.9.3 Действие при получении
Действие при получении данного примитива нижним уровнем LLC не определено.
10.2.2.10 MA_OVLD.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.1 Возможности
Функциональные возможности нижнего уровня MAC описываются при помощи функциональной модели, предписанной ИСО/МЭК 8802-3 (см. также рисунок 5). В этой модели нижний уровень MAC подразделяется на две полностью независимо действующих части: передачу и прием. Функции как приемной, так и передающей частей должны соответствовать данным настоящего подраздела с учетом рисунка 5.
Рисунок 5 - Функции MAC
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) представление последовательного битового потока на физический
уровень для передачи.
10.3.3 Прием кадра
Прием кадра должен соответствовать следующим требованиям:
a) управление доступом к каналу приема:
1) прием последовательного битового потока от физического уровня,
2) преобразование из последовательной формы и рекомпиляция структуры
кадра,
3) удаление дополняющих битов (устранение битового заполнения),
4) обнаружение ошибок (CRC, проверка формата, проверка правила
заполнения),
5) передача подтверждения приема,
6) формирование кадра ошибки и начало передачи,
7) определение состояния перегрузки,
8) формирование ответного кадра перегрузки и начало передачи;
b) расформирование принятых данных:
1) удаление специфической для MAC информации из принятого кадра,
2) представление кадра LLC и информации управления интерфейсом на
нижний уровень LLC (для ограниченных нижних уровней LLC
представляется только ограниченная часть кадра LLC, см. п. 8.5).
10.4.1 Описание
Передача и прием данных между узлами в системе CAN должна выполняться и управляться при помощи четырех разных типов кадров:
- кадр данных, который переносит данные от передатчика ко всем приемникам;
- кадр удаленного запроса, который передается узлом для запроса передачи кадра данных с одним идентификатором;
- кадр ошибки, который передается любым узлом (передатчиком или приемником) в случае обнаружения ошибки на шине;
- кадр перегрузки, который используется для введения дополнительной задержки между предшествующим и последующим кадрами данных или кадрами удаленного запроса.
Кадры данных и кадры удаленного запроса должны отделяться от предшествующих кадров междукадровыми промежутками.
10.4.2.1 Описание
Кадры данных MAC должны состоять из семи разных битовых полей (см. также рисунок 6):
- начало кадра (SOF);
- поле арбитража;
- поле управления;
- поле данных;
- поле циклического контроля избыточности (CRC);
- поле подтверждения приема (ACK);
- конец кадра (EOF).
Поле SOF должно обозначать начало кадров данных и удаленного запроса. Оно должно состоять из одного доминантного бита.
Узел должен передавать SOF только при свободном состоянии шины (см. 10.4.6.3). Узел, контролирующий доминантный бит при отложенной передаче или на месте третьего бита промежутка, должен принимать его как SOF.
Если узел в состоянии отложенной передачи контролирует доминантный бит на месте третьего бита промежутка и активен к ошибкам или являлся приемником предыдущего кадра, начиная со следующего бита, он должен начать передачу своего сообщения с первого бита своего идентификатора без предварительной передачи бита SOF, не переходя в режим приемника.
Все узлы должны синхронизироваться по переднему фронту, сформированному SOF того узла, который первым начинает передачу.
Поле арбитража должно состоять из поля идентификатора, поступившего от нижнего уровня LLC, и бита удаленного запроса данных RTR.
Значение бита RTR должно быть доминантным в поле данных кадра MAC. В зависимости от значения флага идентификатора поле арбитража может иметь два формата: базовый формат и расширенный формат.
a) В базовом формате (при доминантном флаге расширения) поле арбитража должно состоять из одиннадцати битов базового идентификатора и бита RTR. Биты идентификатора должны иметь обозначения с ID-28 по ID-18.
b) В расширенном формате (при рецессивном флаге расширения) поле арбитража должно состоять из базового идентификатора (с ID-28 по ID-18), битов SRR и IDE (оба бита - рецессивные), расширения идентификатора (с ID-17 по ID-0) и бита RTR.
1) Бит подмены запроса на передачу SRR (только в расширенном
формате).
Бит SRR должен передаваться в кадрах расширенного формата на позиции
бита RTR в кадрах базового формата, таким образом, заменяя собой бит
RTR кадров базового формата. Передатчики должны передавать только
рецессивные биты SRR. Приемники на шине должны принимать и
рецессивные, и доминантные биты SRR.
2) Бит расширения идентификатора IDE.
Бит IDE должен проводить различие между базовым и расширенным форматами, т.е. должен находиться в поле:
i) арбитража - для расширенного формата либо
ii) управления - для базового формата.
Бит IDE в расширенном формате должен передаваться как рецессивный, в то время как в стандартном формате бит IDE должен быть доминантным. Он должен передаваться после базового идентификатора и бита RTR (базовый формат) или после базового идентификатора и бита SRR (расширенный формат).
Таким образом, столкновения между кадром базового формата и кадром расширенного формата, когда оба кадра имеют одинаковые базовые идентификаторы, должны разрешаться так, чтобы кадр базового формата превалировал над кадром расширенного формата.
10.4.2.4 Поле управления
Поле управления должно состоять из шести битов, последние четыре из которых должны представлять собой код DLC, поступивший от нижнего уровня LLC (см. 8.4.2), а формат первых двух битов должен отличаться для кадров базового и расширенного формата.
a) В кадре базового формата первыми двумя битами должны являться бит IDE, передаваемый как доминантный, и дополнительный резервный бит r0, рассчитанный на использование в будущем. Приемники должны принимать в качестве резервного бита r0 и рецессивные, и доминантные биты. До тех пор, пока назначение резервного бита не определено, передатчики должны пересылать только доминантный бит.
b) В кадре базового формата первыми двумя битами должны являться биты r1 и r0, рассчитанные на использование в будущем. Приемники должны принимать в качестве резервного бита r0 и рецессивные, и доминантные биты. До тех пор, пока назначение резервного бита не определено, передатчики должны пересылать только доминантные биты.
10.4.2.5 Поле данных
Поле данных кадра MAC должно быть тождественным полю данных кадра LLC (см. 8.4.2).
10.4.2.6 Поле CRC
Поле CRC должно состоять из последовательности CRC и последующего разделителя CRC.
a) Последовательность CRC
Контрольная последовательность кадра должна формироваться из кода CRC (кода БЧХ), наилучшим образом соответствующего кадрам с числом битов, не превышающим 127 бит.
Для вычисления последовательности CRC должен быть определен полином для деления - как полином, коэффициенты которого представлены дополняющим битовым потоком, состоящим из SOF, поля арбитража, поля управления, поля данных (при его наличии) и (для 15 младших коэффициентов) нуля. Этот полином должен делиться (коэффициенты вычисляются по модулю 2) на порождающий полином:
X15 + X14 + X10 + X8 + X7 + X4 + X3 + 1.
Остаток после деления полиномов должен представлять собой последовательность CRC, передаваемую по шине.
Для реализации этой функции можно воспользоваться 15-разрядным регистром сдвига CRC_RG(14:0). Если каждый следующий бит потока, представленного последовательностью между SOF и концом поля данных без дополняющих битов, обозначить как NXTBIT, последовательность CRC должна вычисляться следующим образом
CRC_RG(14:0) = (0,...,0); //инициализация регистра сдвига
REPEAT
CRCNXT = NXTBITEXORCRC_RG(14);
CRC_RG(14:1) = CRC_RG(13:0); //сдвиг влево на одну позицию
CRC_RG(0) = 0;
IF CRCNXT THEN
CRC_RG(14:0) = CRC_RG(14:0)EXOR(4599hex);
ENDIF
UNTIL (NXTBIT = [Конец данных] или состояние ошибки).
После передачи/приема последнего бита поля данных регистр CRC_RG должен содержать последовательность CRC.
b) Разделитель CRC
За последовательностью CRC должен следовать разделитель CRC, состоящий из одного рецессивного бита.
10.4.2.7 Поле ACK
Поле подтверждения приема ACK должно иметь длину в два бита и должно состоять из интервала ACK и разделителя ACK. Передающий узел должен пересылать в поле ACK два рецессивных бита.
a) Интервал ACK
Все узлы, которые приняли соответствующую последовательность CRC, должны пересылать ACK в пределах интервала ACK путем перезаписи рецессивного бита передатчика доминантным битом.
b) Разделитель ACK
Разделитель ACK, который является вторым битом поля ACK, должен быть рецессивным битом. Поэтому интервал ACK должен быть окружен двумя рецессивными битами (разделитель CRC, разделитель ACK).
10.4.2.8 EOF
Каждый из кадров данных и кадров удаленного запроса должен ограничиваться разделителем кадров, состоящим из семи рецессивных битов и формирующим поле конца файла EOF.
10.4.3 Параметры кадра удаленного запроса MAC
10.4.3.1 Описание
Узел, работающий как приемник определенных данных, может инициировать передачу соответствующих данных узлом, который является источником этих данных, передав кадр удаленного запроса, соответствующий рисунку 7.
Рисунок 7 - Кадр удаленного запроса MAC
10.4.3.2 Идентичные поля кадра данных MAC и кадра удаленного запроса MAC
Битовые поля SOF, поле CRC, поле ACK и EOF должны быть идентичны соответствующим полям кадра данных MAC (см. 10.4.2). В кадре удаленного запроса должно отсутствовать поле данных.
10.4.3.3 Поле арбитража
Поле арбитража должно состоять из поля идентификатора, поступившего от нижнего уровня LLC, и бита RTR.
В обоих форматах (базовом и расширенном - см. 10.4.2.3) значение бита RTR в кадре удаленного запроса MAC должно быть рецессивным.
10.4.3.4 Поле управления
ИС NORMPROD: примечание. В официальном тексте документа, видимо, допущена опечатка: пункт 10.3.1.3 отсутствует. |
И в базовом, и в расширенном формате поле управления кадра удаленного запроса MAC должно быть идентичным полю управления кадра данных MAC (см. 10.3.1.3). Разрешение столкновений (см. 10.8.8) требует, чтобы значение кода DLC кадра удаленного запроса было равно значению DLC запрашиваемого кадра данных.
10.4.4 Параметры кадра ошибки
10.4.4.1 Описание
Кадр ошибки должен состоять из двух разных полей. Первое поле должно представлять собой результат суперпозиции флагов ошибки, выданных разными узлами. Следующее за ним второе поле должно являться разделителем кадра ошибки.
10.4.4.2 Флаг ошибки
Могут применяться два типа флага ошибки: активный флаг ошибки и пассивный флаг ошибки:
- активный флаг ошибки должен состоять из шести последовательных доминантных битов;
- пассивный флаг ошибки должен состоять из шести последовательных рецессивных битов, если они не перезаписываются доминантными битами от других узлов.
Активный к ошибкам узел должен пересылать активный флаг ошибки при обнаружении ошибки. Формат флага ошибки нарушает правила вставки дополняющих битов или битовые поля, требующие фиксированных форматов. Как следствие, все остальные узлы должны также обнаружить состояние ошибки и должны со своей стороны начать передачу флага ошибки. Таким образом, последовательность доминантных битов, которые могут в действительности контролироваться на шине, является результатом суперпозиции разных флагов ошибки, пересылаемых отдельными узлами. Общая длина этой последовательности может варьироваться от минимум шести (6) до максимум двенадцати (12) битов.
Пассивный к ошибкам узел, пересылающий пассивный флаг ошибки, ожидает шести последовательных битов одинаковой полярности, начиная с момента начала выдачи пассивного флага ошибки. Пассивный флаг ошибки завершается после обнаружения шести одинаковых битов.
Пассивный флаг ошибки, инициированный передатчиком, должен вызывать ошибки (за двумя исключениями) в приемниках, когда они приступают к проверке поля кадра, закодированного с применением дополняющих битов, поскольку при этом происходит ошибка битового заполнения, обнаруживаемая приемниками. Первое исключение - это пассивный флаг ошибки, который начинается во время арбитража, при продолжении передачи другим узлом. Второе исключение - это пассивный флаг ошибки, который начинается менее чем за шесть бит до конца последовательности CRC при случайном рецессивном состоянии всех последних битов CRC.
Пассивные флаги ошибки, инициированные приемниками, не должны быть способны превалировать над любой другой активностью на шине. Таким образом, пассивные к ошибкам приемники всегда должны ожидать шесть (6) последовательных одинаковых битов после обнаружения состояния ошибки - до тех пор, пока не получат свой полный флаг ошибки.
10.4.4.3 Разделитель ошибки
Разделитель ошибки должен состоять из восьми рецессивных битов. После пересылки флага ошибки каждый узел должен переслать рецессивные биты и контролировать шину до тех пор, пока он не обнаружит рецессивные биты. После этого он должен начать пересылку еще семи рецессивных битов.
10.4.5.1 Типы
Перечисленные ниже типы кадра перегрузки должны иметь одинаковый формат.
a) кадр перегрузки, запрошенный LLC: запрашивается нижним уровнем LLC для индикации состояния внутренней перегрузки (см. 10.11).
b) ответный кадр перегрузки: передача ответного кадра перегрузки должна инициироваться нижним уровнем MAC при определенных состояниях ошибки (см. 10.11).
Кадр перегрузки должен содержать два битовых поля: флаг перегрузки и разделитель перегрузки. Флаг перегрузки должен соответствовать активному флагу ошибки. Разделитель перегрузки должен совпадать с разделителем ошибки.
10.4.5.2 Флаг перегрузки
Флаг перегрузки должен состоять из шести доминантных битов. Он нарушает фиксированный формат поля паузы (см. 10.4.6). Как следствие, все остальные узлы, также обнаружившие состояние ошибки, должны со своей стороны начать пересылку флага перегрузки.
10.4.5.3 Разделитель перегрузки
Разделитель перегрузки должен состоять из восьми рецессивных битов. После пересылки флага перегрузки каждый узел должен контролировать шину до тех пор, пока не обнаружит рецессивный бит. В этот момент каждый узел должен завершить пересылку своего флага перегрузки, и все узлы одновременно должны начать пересылку еще семи рецессивных битов, чтобы сформировать восьмибитный разделитель перегрузки.
10.4.6.1 Описание
Кадры данных и кадры удаленного запроса должны отделяться от предыдущих кадров - вне зависимости от типа (кадр данных, кадр удаленного запроса, кадр ошибки, кадр перегрузки) - битовым полем, которое называется междукадровым промежутком. С другой стороны, кадрам перегрузки и кадрам ошибки не должен предшествовать междукадровый промежуток, а несколько кадров перегрузки не должны разделяться междукадровыми промежутками.
Междукадровый промежуток должен состоять из битовых полей паузы и свободного состояния шины, а также поля отложенной передачи для пассивных к ошибке узлов, которые являлись передатчиками предыдущих кадров (см. рисунки 8 и 9).
Рисунок 8 - Междукадровые промежутки для узлов, не пассивных
к ошибкам, или приемников предыдущего кадра
к ошибкам, которые являлись передатчиками предыдущего кадра
10.4.6.2 Пауза
Поле паузы должно состоять из трех рецессивных битов. Во время паузы ни один узел не начинает передачу кадра данных или удаленного запроса. Допускается только сигнализация о состоянии перегрузки.
Обнаружение на шине доминантного бита на месте третьего бита поля паузы должно интерпретироваться как SOF (см. 10.4.2.2).
Длительность свободного состояния шины может быть произвольной. Шина должна распознать свободное состояние, и любой узел может получить доступ к шине для передачи. Кадр, передача которого задержана на время передачи другого кадра, должен начинаться с первого бита следующей паузы.
Обнаружение на шине доминантного бита во время свободного состояния шины должно интерпретироваться как SOF.
Пассивный к ошибкам узел, который являлся передатчиком предыдущего кадра, должен переслать восемь (8) рецессивных битов после паузы, прежде чем начать передачу следующего кадра. Если в это время начинается передача (инициированная другим узлом), узел должен перейти на прием этого кадра.
Кадр, который подразделяется на SOF, поле арбитража, поле управления, поле данных и последовательность CRC, должен быть закодирован путем битового заполнения. Если передатчик обнаруживает в битовом потоке, подлежащем передаче, пять последовательных битов (включая дополняющие биты) одинакового значения, он должен автоматически вставить дополняющий бит в передающийся в данный момент битовый поток (см. таблицу 6).
Таблица 6
Дополняющие биты
Битовый поток без заполнения | 01011111010 | 10100000101 | 01011111000010 | 10100000111101 |
Битовый поток с заполнением | 01011111o010 | 10100000I101 | 01011111o0000I10 | 10100000I1111o01 |
0 - доминантный бит, o - дополняющий доминантный бит, | ||||
1 - рецессивный бит, I - дополняющий рецессивный бит. | ||||
Остальные битовые поля кадра данных или удаленного запроса (разделитель CRC, поле ACK и EOF) должны иметь фиксированный формат и не должны заполняться.
Кадр ошибки и кадр перегрузки также должны иметь фиксированный формат и не должны колироваться путем битового заполнения.
Битовый поток в кадре должен кодироваться методом NRZ. Это означает, что уровень сформированного бита остается постоянным на протяжении всего битового интервала.
Каждое из битовых полей кадра должно передаваться одно за другим, начиная с его поля SOF. Старший значащий бит (MSB) каждого поля должен передаваться первым (см. рисунки 10 и 11).
Рисунок 10 - Порядок передачи битов (базовый формат)
Момент времени, в который кадр признается правильным, должен быть разным для передатчика и приемника кадра.
a) Кадр должен быть правильным для передатчиков, если до конца EOF нет ошибок. Если кадр поврежден, должно выполняться восстановление в соответствии с 8.3.4.
b) Кадр должен быть правильным для передатчиков, если до предпоследнего бита EOF нет ошибок. Значение последнего бита EOF должно обрабатываться как "не имеющее значения", и его доминантное значение не должно приводить к формированию ошибки. Приемник, который обнаруживает доминантный бит на месте последнего бита EOF, должен ответить кадром перегрузки (см. 10.11)
Примечание - Если и приемник, и передатчик обнаруживают доминантный бит на месте последнего бита EOF (глобальная ошибка), то кадр является правильным для приемника, но не для передатчика. Передатчик повторяет пересылку, и кадр принимается дважды.
10.8.1 Общие сведения
В настоящем подразделе описываются функции и параметры, имеющие отношение к методике доступа к каналу связи CAN.
10.8.2 Мультимастер
Каждый узел, передающий кадр данных или кадр удаленного запроса, должен являться контроллером шины на время этой передачи.
10.8.3 Обнаружение свободного состояния шины
Шина должна считаться свободной для любого узла после обнаружения отсутствия прерывания битового поля паузы доминантным битом.
Активный к ошибкам узел может получить доступ к шине, как только шина окажется свободной. Пассивный к ошибкам узел, который является приемником текущего или предыдущего кадра, может получить доступ к шине, как только шина окажется свободной. Пассивный к ошибкам узел, который является передатчиком текущего кадра или являлся передатчиком предыдущего кадра, может получить доступ к шине, как только завершится отложенная передача, - это гарантирует, что ни один другой узел не начнет передачу в это время.
Если по совпадению начнут передачу несколько узлов, контроллером шины становится тот узел, который передает в этот момент кадр с наивысшим приоритетом. Механизм разрешения возникающих конфликтов доступа к шине должен представлять собой арбитраж по содержимому.
10.8.5 Передача кадров MAC
Кадры данных MAC и кадры удаленного запроса MAC могут начинаться, когда узел получает доступ к шине в соответствии с 10.8.4. Кадр ошибки MAC должен передаваться в соответствии с 10.10. Кадр перегрузки MAC должен передаваться в соответствии с 10.11.
10.8.6 Арбитраж по содержимому
Во время арбитража каждый передатчик должен сравнивать уровень пересылаемого бита с уровнем, контролируемым на шине. При совпадении этих уровней узел может продолжить пересылку. При пересылке рецессивного уровня и наблюдении доминантного уровня узел проигрывает арбитраж и должен прекратить пересылку остальных битов.
При пересылке доминантного уровня и наблюдении рецессивного уровня узел должен обнаруживать ошибку символа.
Арбитраж по содержимому выполняется на основе идентификатора и бита RTR, следующего за идентификатором.
10.8.7 Приоритет кадра
Из двух кадров с разными идентификаторами наивысший приоритет должен присваиваться кадру, содержащему идентификатор с наименьшим двоичным значением.
Если в одно и то же время начинаются кадр данных и кадр удаленного запроса с одинаковыми идентификаторами, кадр данных должен иметь более высокий приоритет, чем кадр удаленного запроса. Это должно реализовываться путем присвоения соответствующих значений битам RTR.
Дополнительно к принципу начала передачи только при свободном состоянии шины предусмотрено еще несколько принципов разрешения столкновений.
В пределах одной системы любой информации должен присваиваться уникальный идентификатор.
Кадр данных с определенным идентификатором и ненулевым кодом DLC может передаваться только одним узлом.
Кадры удаленного запроса могут передаваться только с определенным для всей системы кодом DLC, который должен быть кодом DLC соответствующего кадра данных. Одновременная передача кадров удаленного запроса с идентичными идентификаторами и разными кодами DLC должна приводить к неразрешимым столкновениям (ограничение арбитража по содержимому на поле арбитража).
Нижний уровень MAC должен обеспечивать следующие механизмы обнаружения ошибок:
- мониторинг;
- проверка правила заполнения;
- проверка кадра;
- 15-битный код CRC;
- проверка подтверждения приема ACK.
Предусмотрено пять типов ошибок, которые не являются взаимоисключающими:
a) ошибка символа
Узел, пересылающий бит на шину, должен также контролировать шину. Ошибка символа обнаруживается на том битовом интервале, на котором контролируемое значение бита отличается от пересылаемого значения бита.
Исключения:
- доминантный бит не должен вызывать ошибку символа, если во время арбитража пересылается информация рецессивного бита либо если рецессивный бит пересылается на интервале ACK;
- узел, пересылающий пассивный флаг ошибки и обнаруживший доминантный бит, не должен интерпретировать это как ошибку символа;
b) ошибка заполнения
Ошибка заполнения обнаруживается на битовом интервале из шести последовательных битов равного уровня в поле кадра, которое должно быть закодировано методом битового заполнения;
c) ошибка CRC
Последовательность CRC должна состоять из результата вычисления CRC передатчика. Приемники должны вычислить CRC таким же способом, как и передатчик. Ошибка CRC должна обнаруживаться, если рассчитанная последовательность CRC не совпадает с принятой;
d) ошибка формата
Ошибка формата должна обнаруживаться, если битовое поле фиксированного формата содержит один или несколько недопустимых битов.
Исключения:
- если приемник обнаруживает доминантный бит на месте последнего бита EOF или любой узел обнаруживает доминантный бит на месте последнего бита разделителя ошибки либо разделителя перегрузки, он не должен интерпретировать это как ошибку формата;
e) ошибка ACK
Ошибка ACK должна обнаруживаться передатчиком, если он не обнаруживает доминантный бит на интервале ACK.
В случае обнаружения одной из этих ошибок нижний уровень LLC должен получить информацию. Как следствие, нижний уровень MAC должен начать передачу флага ошибки.
В случае обнаружения ошибки символа, ошибки заполнения, ошибки формата или ошибки ACK любым узлом со следующего бита должна начаться передача соответствующим узлом флага ошибки.
В случае обнаружения ошибки CRC, начиная с бита, следующего за разделителем ACK, должна начаться передача кадра ошибки, если уже не контролируется кадр ошибки для другого состояния ошибки.
Перечисленные ниже условия должны вызывать передачу кадра перегрузки:
a) запрошенный LLC кадр перегрузки (по инициативе нижнего уровня LLC): внутреннее состояние приемника, которое требует задержки следующего кадра данных MAC или кадра удаленного запроса MAC;
b) ответный кадр перегрузки (по инициативе нижнего уровня MAC): обнаружение доминантного бита во время первых двух битов паузы, обнаружение доминантного бита на месте последнего бита EOF приемником или обнаружение доминантного бита любым узлом на месте последнего бита разделителя ошибки или разделителя перегрузки.
Запрошенный LLC кадр перегрузки должен начинаться только с первого бита ожидаемой паузы, тогда как ответные кадры перегрузки должны начинаться через один бит после обнаружения доминантного бита при возникновении условия перечисления b). Начало передачи запрошенных LLC кадров перегрузки при возникновении условия перечисления a) должно допускаться, но необязательно для реализации.
Не более двух кадров перегрузки LLC могут формироваться для задержки следующего кадра данных MAC или кадра удаленного запроса MAC.
В опциональном режиме мониторинга шины узел CAN должен иметь возможность приема правильных кадров данных и правильных кадров удаленного запроса, однако пересылает на шину CAN только рецессивные биты и не начинает передачу. Если нижний уровень MAC требует пересылки доминантного бита (бит ACK, флаг перегрузки, активный флаг ошибки), бит должен быть внутренне перенаправлен таким образом, чтобы нижний уровень MAC контролировал этот доминантный бит, хотя шина CAN может оставаться в рецессивном состоянии.
Для реализации в соответствии с техническими требованиями нижние уровни LLC и MAC должны соответствовать всем требованиям и значениям, приведенным в настоящем стандарте.
Физический уровень должен представлять собой электрическую цепь, которая соединяет узел CAN с шиной. Общее количество узлов CAN должно быть ограничено электрической нагрузкой на шине.
Физический уровень должен моделироваться в соответствии с ИСО/МЭК 8802-3 (см. также рисунок 12). Физический уровень должен подразделяться на три части:
a) передача сигналов (PLS) должна выполнять функции, относящиеся к двоичному представлению, распределению по времени и синхронизации;
b) нижний уровень подсоединения к физическому каналу (PMA) должен реализовывать функциональную схемотехнику передачи/приема по проводным линиям шины и может обеспечивать средства обнаружения сбоев на шине;
c) интерфейс канала связи (MDI) должен реализовывать механические и электрические интерфейсы между физическим каналом связи и устройством доступа к каналу связи (MAU).
MAU должно соответствовать функциональной части физического уровня, применяемой для соединения узла со средством передачи. MAU состоит из PMA и MDI.
12.3.1 Описание
Службы физического уровня должны обеспечивать обмен битами данных локального компонента нижнего уровня MAC с равноправными компонентами нижнего уровня MAC.
Физический уровень должен обеспечивать перечисленные ниже служебные примитивы для нижнего уровня MAC:
PLS_Data.request,
PLS_Data.indicate.
12.3.2 PLS_Data.Request
Примитив PLS_Data.Request должен поступать от нижнего уровня MAC на физический уровень для запроса передачи доминантного или рецессивного бита. Параметры примитива должны иметь следующий вид:
PLS_Data.Request (
Output_Unit
)
Параметр Output_Unit может принимать одно из двух значений: доминантное или рецессивное.
12.3.3 PLS_Data.Indicate
Примитив PLS_Data.Indicate должен поступать от физического уровня на нижний уровень MAC для индикации получения доминантного или рецессивного бита. Параметры примитива должны иметь следующий вид:
PLS_Data.Indicate (
Input_Unit
)
Параметр Input_Unit может принимать одно из двух значений, каждое из которых представляет одиночный бит: доминантное или рецессивное.
12.4.1 Кодирование/декодирование бита
12.4.1.1 Битовый интервал
Функции управления шиной реализуются в пределах битового интервала, включая порядок синхронизации узлов CAN, компенсацию времени задержки на передачу в сети и расположения точки отсчета, и должны соответствовать заданной логике временного распределения битов, программируемой в IC протокола CAN.
a) Номинальная скорость передачи данных (BR) определяет количество битов в секунду, передаваемых идеальным передатчиком при отсутствии повторной синхронизации.
b) Номинальный битовый интервал tB:
Номинальный битовый интервал может представляться разделенным на отдельные не перекрывающиеся отрезки времени.
Эти сегменты должны формировать битовый интервал, как это показано на рисунке 13:
- сегмент синхронизации (Sync_Seg),
- сегмент прохождения сигнала (Prop_Seg),
- сегмент фазового буфера 1 (Phase_Seg1),
- сегмент фазового буфера 2 (Phase_Seg2).
Sync_Seg
Эта часть битового интервала должна использоваться для синхронизации различных узлов CAN на шине. В пределах этого сегмента ожидается фронт сигнала.
Prop_Seg
Эта часть битового интервала должна использоваться для компенсации времен физических задержек в сети. Эти времена задержек состоят из времени прохождения сигнала по шине и внутренних времен задержки узлов CAN.
Phase_Seg1, Phase_Seg2
Эти сегменты фазовых буферов предназначены для компенсации ошибок фазы фронта. Эти сегменты могут расширяться или сокращаться при помощи повторной синхронизации.
Точка отсчета
Точка отсчета должна являться моментом времени, в который считывается уровень на шине и интерпретируется как значение соответствующего бита. Ее положение должно совпадать с окончанием сегмента Phase_Seg1.
Время обработки информации
Время обработки информации должно представлять собой отрезок времени, который начинается с точки отсчета и зарезервирован для вычисления уровня следующего бита.
Ширина скачка повторной синхронизации (SJW)
В результате повторной синхронизации возможно расширение сегмента Phase_Seg1 или сокращение сегмента Phase_Seg2. Значение расширения или сокращения сегментов фазовых буферов имеет верхний предел, заданный шириной скачка повторной синхронизации.
Время внутренней задержки
Время внутренней задержки узла CAN, tnode, должно являться суммой всех асинхронных задержек, которые возникают на маршрутах передачи и приема относительно логического блока временного распределения битов при помощи IC протокола отдельных узлов CAN. Подробнее см. рисунок 14.
Пояснения к рисунку 14:
1) сумма задержек на входе (tinput) и выходе (toutput) узла CAN является критичной для логики временного распределения битов и является важным параметром узла CAN, вычисляемым по формуле
tnode = toutput + tinput;
2) для правильности арбитража должно выполняться следующее условие:
tProp_Seg >= Wtnode A + tnode B + 2tbusline,
т.е. управляющая логика временного распределения передающегося бита с учетом синхронизации CAN требует, чтобы узел A был способен определить правильный уровень на шине для бита n в точке отсчета. Допустимые значения tnode зависят от необходимой скорости передачи данных и длины строки шины (от tbusline - максимальной дистанции между любыми двумя узлами), а также от возможного временного распределения битов, соответствующего условию арбитража.
распределениями узлов CAN A и B во время арбитража,
временным распределением двух узлов CAN и временами задержек
12.4.1.2 Программирование битового интервала
Программирование битового интервала должно выполняться при помощи перечисленных ниже интервалов времени (см. также рисунок 14):
a) Квант времени
Квант времени должен являться фиксированной единицей времени, полученной из периода задающего генератора. Должен быть предусмотрен программируемый предварительный делитель частоты на целочисленные значения в диапазоне, как минимум, от единицы (1) до тридцати двух (32). Начиная с минимального значения кванта времени, квант времени должен иметь длительность:
Квант времени = m·минимальный квант времени,
где m - коэффициент деления предварительного делителя.
b) Номинальная длительность временных интервалов (в отсутствие синхронизации).
Сегмент Sync_Seg должен иметь длину в один квант времени.
Время обработки информации должно быть не более двух длительностей кванта.
Сегмент Prop_Seg должен программироваться равным 1, 2, 3, ..., 8 или более квантов. Он должен программироваться в расчете на компенсацию времен задержки реальной сети, округленных до ближайшего целого числа квантов времени.
Сегмент Phase_Seg1 должен программироваться равным 1, 2, 3, ..., 8 или более квантов.
Сегмент Phase_Seg2 должен программироваться равным максимальному значению Phase_Seg1 и времени обработки информации.
Ширина SJW должна программироваться равной значению от 1 до минимального из значений Phase_Seg1 и 4.
В реализации CAN нет необходимости в раздельном программировании сегментов Prop_Seg и Phase_Seg1. Достаточно запрограммировать сумму значений Prop_Seg и Phase_Seg1.
Общее количество квантов времени в битовом интервале должно программироваться равным, как минимум, от 8 до 25.
В случае применения синхронизации сегмент Phase_Seg1 может быть длиннее, а сегмент Phase_Seg2 может быть короче, чем их запрограммированные номинальные значения.
Частоты задающих генераторов разных узлов CAN должны быть согласованы - для обеспечения определенного для всей системы значения кванта времени. Приемлемые допуски частоты задающих генераторов для IC протокола (см. 12.4.2.5) и вероятность неправильной синхронизации определяются значениями Phase_Seg1 и Phase_Seg2.
12.4.2 Синхронизация
12.4.2.1 Описание
Двумя формами синхронизации должны являться жесткая синхронизация и повторная синхронизация. Они должны подчиняться следующим правилам:
a) должен допускаться только один тип синхронизации в одном битовом интервале (между двумя точками отсчета);
b) фронт перехода с рецессивного бита на доминантный должен применяться для синхронизации только при обнаружении состояния шины в предыдущей точке отсчета (предыдущем считывании состояния шины), отличного от состояния шины сразу же после перехода;
c) жесткая синхронизация должна применяться в пределах внутрикадрового интервала (за исключением первого бита паузы) вне зависимости от наличия фронта перехода с рецессивного бита на доминантный;
d) все прочие фронты перехода с рецессивного на доминантный уровень, удовлетворяющие требованиям a) и b), должны использоваться для повторной синхронизации, за исключением узлов, передающих доминантный бит, которые не выполняют повторную синхронизацию при переходе с рецессивного на доминантный уровень при положительном значении фазовой ошибки (см. 12.4.2.2).
Информация тактового сигнала должна быть получена из переходов с одного значения бита на другое. Свойство наличия только фиксированного максимального числа последовательных битов с одним значением, следующее из битового заполнения, обеспечивает возможность повторной синхронизации устройства шины с битовым потоком в пределах кадра.
Фазовая ошибка фронта e определяется положением фронта относительно сегмента Sync_Seg, выраженным в квантах времени. Знак фазовой ошибки определяется:
e = 0, если фронт находится в пределах сегмента Sync_Seg,
e > 0, если фронт находится до точки отсчета и
e < 0, если фронт находится после точки отсчета.
12.4.2.3 Жесткая синхронизация
После применения жесткой синхронизации битовый интервал должен быть заново начат каждым логическим блоком временного распределения битов по сегменту Sync_Seg. Таким образом, жесткая синхронизация должна заставить фронт, который вызвал жесткую синхронизацию, переместиться в пределы сегмента синхронизации перезапущенного битового интервала.
12.4.2.4 Повторная синхронизация бита
Повторная синхронизация должна привести к сокращению или расширению битового интервала таким образом, чтобы положение точки отсчета было правильным, если значение фазовой ошибки фронта, который вызвал повторную синхронизацию, не более запрограммированного значения ширины скачка повторной синхронизации.
Если значение фазовой ошибки превышает ширину скачка повторной синхронизации, то:
- при положительном значении фазовой ошибки e сегмент Phase_Seg1 должен расшириться на значение, равное ширине скачка повторной синхронизации, в то время как
- при отрицательном значении фазовой ошибки e сегмент Phase_Seg2 должен сократиться на значение, равное ширине скачка повторной синхронизации.
Если сегмент Phase_Seg2 сокращается до значения, меньшего, чем время обработки информации, вычисление уровня следующего бита может завершиться после завершения сегмента Phase_Seg2.
Предел допуска отклонения частот задающего генератора fosc относительно номинальной частоты fnom зависит от значений Phase_Seg1, Phase_Seg2, SJW и битового интервала. Максимальное отклонение df частоты fosc при условии
(1 - df)fnom <= fosc <= (1 + df)fnom
должно соответствовать еще двум условиям:
1)
2)
Максимальная разница между двумя задающими генераторами должна составлять 2df·fnom.
12.5.1 Сообщения от PLS к PMA
12.5.1.1 Выходное сообщение
Нижний уровень PLS должен пересылать на нижний уровень PMA выходное сообщение при приеме Output_Unit от нижнего уровня MAC. Выходное сообщение вызывает пересылку PMA доминантного или рецессивного бита.
12.5.1.2 Сообщение Bus_off
Нижний уровень PLS должен пересылать на нижний уровень PMA сообщение bus_off при приеме bus_off_request от супервайзера (см. 13.1).
12.5.1.3 Сообщение Bus_off_release
Нижний уровень PLS должен пересылать на нижний уровень PMA сообщение bus_off_release при приеме bus_off_release_request от супервайзера (см. 13.1).
12.5.2 Сообщения от PMA к PLS
12.5.2.1 Входное сообщение
Нижний уровень PMA должен пересылать на нижний уровень PLS входное сообщение при приеме MAU бита из канала связи. Входной сигнал сообщает PLS о получении доминантного или рецессивного бита.
13.1.1 Технические требования
Требование предотвращения ошибок должно сохранять высокую работоспособность системы передачи данных даже в случае дефекта узла. Таким образом, стратегии предотвращения ошибок должны надежно обеспечивать:
- различие между кратковременными сбоями и постоянными отказами и
- локализацию и отключение отказавших узлов.
13.1.2 Стратегии
Каждый узел должен быть оснащен счетчиком ошибок передачи и счетчиком ошибок приема. Первый из них должен регистрировать количество ошибок при передаче, а второй - количество ошибок при приеме кадров.
Если кадры передаются и принимаются правильно, показания счетчиков должны уменьшаться. При наличии ошибок показания счетчиков должны увеличиваться в большей степени, чем они уменьшались в отсутствие ошибок. Соотношение, с которым увеличиваются или уменьшаются показания счетчиков, зависит от допустимого соотношения правильных и ошибочных кадров на шине. В любой момент показания счетчиков ошибок отражают относительную частоту возникших ранее искажений.
В зависимости от заранее определенных показаний счетчика порядок работы узлов в зависимости от наличия ошибок должен изменяться. Эти изменения должны варьироваться от запрета пересылки флагов ошибок до отмены кадров и до отключения узлов, слишком часто пересылающих неправильные кадры.
13.1.3.1 Описание
Интерфейс предотвращения ошибок должен соответствовать рисунку 15.
13.1.3.2 Интерфейс между нижним уровнем LLC и FCE
Сообщения, которыми обмениваются подсистема предотвращения ошибок (FCE) и нижний уровень LLC, должны соответствовать таблице 7.
Таблица 7
Сообщения между LLC и FCE
a) Сообщения от LLC к FCE | |
Сообщения от LLC к FCE | Значение |
Normal_Mode_Request | Сброс FCE к исходному состоянию <a> |
b) Сообщения от FCE к LLC | |
Сообщения от FCE к LLC | Значение |
Normal_Mode_Response | Ответ на сообщение Normal_Mode_Request |
Bus_Off | Сообщает о состоянии отключения узла от шины |
13.1.3.3 Интерфейс между нижним уровнем MAC и FCE
Сообщения, которыми обмениваются FCE и нижний уровень MAC, должны соответствовать таблице 8.
Таблица 8
Сообщения между MAC и FCE
a) Сообщения от MAC к FCE | |
Сообщения от MAC к FCE | Значение |
Transmit/receive | Сообщает текущий режим передачи узла |
Error | Сообщает об обнаружении ошибки нижним уровнем MAC (ошибка символа, ошибка заполнения, ошибка CRC, ошибка формата, ошибка ACK) |
Primary_error | Сообщает об обнаружении нижним уровнем MAC доминантного бита после пересылки флага ошибки (это говорит о том, что нижний уровень MAC обнаружил первичную ошибку, а не ошибку, которая вызвана флагом ошибки от другого узла) |
Error/overload flag | Сообщает о пересылке нижним уровнем MAC флага ошибки или флага перегрузки |
Counters_unchanged | Сообщает о неизменности показаний счетчиков FCE [в результате особых случаев - см. 13.1.4.2, c)] |
Error_delimiter_too_late | Сообщает о чрезмерно долгом ожидании нижним уровнем MAC разделителя ошибки. Этот сигнал пересылается всякий раз после приема последовательности из восьми следующих друг за другом доминантных битов вслед за пересылкой флага ошибки |
Successful_transfer | Сообщает об успешном завершении передачи и приема |
Error_passive_response | Сообщает об установке узла в состояние пассивности к ошибкам |
Error_active response | Сообщает о повторной установке узла в состояние активности к ошибкам |
b) Сообщения от FCE к MAC | |
Сообщения от FCE к MAC | Значение |
Error_passive_request | Запрос установки узла в состояние пассивности к ошибкам |
Error_active_request | Запрос установки узла в состояние активности к ошибкам |
13.1.3.4 Интерфейс между физическим уровнем и FCE
Сообщения, которыми обмениваются FCE и физический уровень, должны соответствовать таблице 9.
Таблица 9
Сообщения между FCE и физическим уровнем
a) Сообщения от FCE к PL | |
Сообщения от FCE к PL | Значение |
Bus_off_request | Запрос отключения узла от шины |
Bus_off_release_request | Запрос установки узла в обычный режим приема/передачи |
b) Сообщения от PL к FCE | |
Сообщения от PL к FCE | Значение |
Bus_off_response | Ответ на запрос отключения от шины |
Bus_off_release_response | Ответ на запрос прекращения отключения от шины |
13.1.4 Правила предотвращения ошибок
13.1.4.1 Описание
Относительно предотвращения ошибок узел может находиться в одном из трех состояний в зависимости от уровней счетчика ошибок (см. 6.13 - 6.15):
- активность к ошибкам;
- пассивность к ошибкам;
- отключение от шины.
Счетчики ошибок должны быть модифицированы в соответствии со следующими правилами (при передаче данного кадра может применяться более одного правила).
a) Когда приемник обнаруживает ошибку, показания счетчика ошибок приема должны увеличиться на 1, если обнаруженная ошибка явилась ошибкой символа, возникшей при пересылке активного флага ошибки или флага перегрузки.
b) Когда приемник обнаруживает доминантный бит на позиции первого бита после пересылки флага ошибки, показания счетчика ошибок приема должны увеличиться на восемь (8).
c) Когда передатчик пересылает флаг ошибки, показания счетчика ошибок передачи должны увеличиться на восемь (8).
ошибку ACK вследствие отсутствия доминантного ACK и не обнаруживает
доминантного бита при передаче своего пассивного флага ошибки.
2) Исключение 2: если передатчик пересылает флаг ошибки вследствие
ошибки заполнения, возникшей во время арбитража, при этом бит
заполнения должен быть рецессивным и должен пересылаться как
рецессивный, но контролироваться как доминантный.
При обоих исключениях показания счетчика ошибок передачи должны оставаться неизменными.
d) Если передатчик обнаруживает ошибку символа во время пересылки активного флага ошибки или флага перегрузки, показания счетчика ошибок передачи должны увеличиться на восемь (8).
e) Если приемник обнаруживает ошибку символа во время пересылки активного флага ошибки или флага перегрузки, показания счетчика ошибок приема должны увеличиться на восемь (8).
f) Любой узел должен допускать пересылку до семи (7) последовательных доминантных битов после пересылки активного флага ошибки, пассивного флага ошибки или флага перегрузки. После обнаружения четырнадцати (14) последовательных доминантных битов в случае активного флага ошибки или флага перегрузки либо после обнаружения восьми последовательных доминантных битов вслед за пассивным флагом ошибки и после каждой серии из дополнительных последовательных доминантных битов каждый передатчик должен увеличить показания счетчика ошибок передачи на восемь (8), и каждый приемник должен увеличить показания счетчика ошибок приема на восемь (8).
g) После успешной передачи кадра (получения ACK и отсутствия обнаруженных ошибок до завершения EOF) показания счетчика ошибок передачи должны уменьшаться на единицу (1), если уже не равны нулю (0).
h) После успешного приема кадра (прием в отсутствие ошибок на интервале ACK и успешная передача бита ACK) показания счетчика ошибок приема должны уменьшаться на 1, если они равны от единицы (1) до ста двадцати семи (127). Если показания счетчика ошибок равны нулю (0), они остаются нулевыми (0), а если они больше ста двадцати семи (127), то они должны принять значение от ста девятнадцати (119) до ста двадцати семи (127).
13.1.4.3 Переход между состояниями активности к ошибкам и пассивности к ошибкам
Если показания счетчика ошибок передачи или счетчика ошибок приема узла превышают сто двадцать семь (127) (состояние переноса разряда для 7-битного счетчика ошибок приема), то супервайзер должен запросить нижний уровень MAC об установке соответствующего узла в состояние пассивности к ошибкам.
Состояние ошибки, приводящее узел в пассивность к ошибкам, должно вызывать пересылку узлом активного флага ошибки.
Пассивный к ошибкам узел должен вновь стать активным, если и счетчик ошибок передачи, и счетчик ошибок приема имеют показания не более ста двадцати семи (127) (см. рисунок 16).
Если показания счетчика ошибок приема превышают предел пассивности к ошибкам, равный ста двадцати семи (127), дальнейшее увеличение показаний такого счетчика ошибок приема должно ограничиваться разрядностью счетчика. При следующем успешном приеме кадра (переход в активное к ошибкам состояние) счетчик ошибок приема должен установиться в значение, не превышающее предела пассивности к ошибкам [см. перечисление h) 13.1.4.2].
Если показания счетчика ошибок передачи узла превышают двести пятьдесят пять (255) (условие переноса разряда для 8-битного счетчика ошибок передачи), то супервайзер должен запросить физический уровень о переводе узла в состояние отключения от шины.
В состоянии отключения от шины узел не должен оказывать на нее никакого влияния. Он не должен пересылать ни каких-либо кадров, ни подтверждения, ни кадров ошибки или перегрузки. Может ли такой узел принимать кадры от шины, зависит от реализации.
Узел в состоянии отключения от шины может стать активным к ошибкам и больше не являться отключенным от шины, если оба его счетчика ошибок устанавливаются в нуль (0) после контроля ста двадцати восьми (128) появлений на шине одиннадцати (11) последовательных рецессивных битов (см. рисунок 16). Начало последовательности восстановления можно выполнять программно или аппаратно - в зависимости от реализации.
Примечание - Существующие реализации могут быть разными. Например, 6.15 допускает отключение передатчика и приемника; восстановление может начаться только по запросу пользователя. Это не покрывается тестированием на соответствие согласно ИСО 16845.
REC - показания счетчика ошибок приема
TEC - показания счетчика ошибок передачи
13.1.5 Запуск системы
Если при запуске системы на связи только один узел и если этот узел передает какой-либо кадр, он не должен получать подтверждение, обнаруживать ошибки и повторять кадр. В соответствии с перечислениями c), 1) 13.1.4.2 он может стать пассивным к ошибкам, но не может отключаться от шины.
Узел, который был отключен, должен пройти следующую процедуру:
a) синхронизация с уже доступными узлами перед началом передачи - синхронизация достигается, когда одиннадцать (11) рецессивных битов эквивалентны:
- разделителю ACK + EOF + паузе или
- разделителю ошибки/перегрузки + обнаружению паузы и
b) ожидания других узлов без перехода в состояние отключения от шины, если в данный момент другие узлы недоступны.
При обычной работе несколько отказов на шине могут повлиять на работу шины. Эти отказы и итоговое поведение сети должны соответствовать ИСО 11898-2.
[1] | ИСО 7637-3:1995 | Транспорт дорожный. Электрические помехи, вызываемые проводимостью и взаимодействием. Часть 3. Автомобили с номинальным напряжением электропитания 12 или 24 В. Распространение электрических помех, вызываемых переходными процессами |
(справочное)
НАЦИОНАЛЬНОМУ СТАНДАРТУ РОССИЙСКОЙ ФЕДЕРАЦИИ
Таблица ДА.1
Обозначение ссылочного международного стандарта | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
ИСО/МЭК 7498-1 | IDT | ГОСТ Р ИСО/МЭК 7498-1-99 "Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель" |
Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандарта: - IDT - идентичный стандарт. | ||
Вернуться в "Каталог нормативных документов"
Источник информации: https://internet-law.ru/documents/prod/gost-r_gosudarstvennyj-standart/34/gost_76805.html
На правах рекламы:
|
© Антон Серго, 1998-2026.
|
Разработка сайта |
|