ГОСТ Р ИСО 11898-1-2015 Транспорт дорожный. Местная контроллерная сеть (CAN). Часть 1. Канальный уровень и передача сигналов

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

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

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

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

Часть 1

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

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

ОКС 43.040.15

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

Предисловие

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

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 06 ноября 2015 г. N 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, Дорожный транспорт, подкомитет ПК3, электрическое и электронное оборудование (ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical and electronic equipment).

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

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

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

Введение

ИСО (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. Взаимодействие с разделением доступа по времени.

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 битовый интервал: t: Длительность одного бита.

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 передатчик: Узел, формирующий кадр данных, или кадр удаленного запроса, который остается передатчиком до тех пор, пока шина не освободится вновь или пока узел не выберется при арбитраже.

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

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

6.1 Свойства CAN

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

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

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

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

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

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

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

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

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

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

6.2 Кадры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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).

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

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

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

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

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

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

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

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

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

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

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

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

При обмене кадрами или протокольными блоками данных (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 Описание формата служб

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-му пользователю для передачи результатов одного или более взаимосвязанных предыдущих запросов службы. Этот примитив может указывать либо на невыполнение, либо на ту или иную степень выполнения. Индикация какой-либо активности на удаленном равноправном интерфейсе не должна являться необходимой.

7.4 Интерфейс LLC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Функции нижнего уровня 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):

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

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

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

8.4.2.3 Поле кода DLC

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

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

8.4.2.4 Поле данных

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

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

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

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

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

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

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 Опция TTC

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) до (2-1) х показания счетчика времени.

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

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

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

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 Функциональная модель нижнего уровня MAC

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

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

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

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

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

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

Рисунок 5 - Функции MAC

10.3.3 Прием кадра

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

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

b) расформирование принятых данных:

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

10.4.1 Описание

Передача и прием данных между узлами в системе CAN должна выполняться и управляться при помощи четырех разных типов кадров:

- кадр данных, который переносит данные от передатчика ко всем приемникам;

- кадр удаленного запроса, который передается узлом для запроса передачи кадра данных с одним идентификатором;

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

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

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

10.4.2 Параметры кадра данных MAC

10.4.2.1 Описание

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

- начало кадра (SOF);

- поле арбитража;

- поле управления;

- поле данных;

- поле циклического контроля избыточности (CRC);

- поле подтверждения приема (ACK);

- конец кадра (EOF).

Рисунок 6 - Кадр данных MAC

10.4.2.2 SOF

Поле SOF должно обозначать начало кадров данных и удаленного запроса. Оно должно состоять из одного доминантного бита.

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

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

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

10.4.2.3 Поле арбитража

Поле арбитража должно состоять из поля идентификатора, поступившего от нижнего уровня LLC, и бита удаленного запроса данных RTR.

Значение бита RTR должно быть доминантным в поле данных кадра MAC. В зависимости от значения флага идентификатора поле арбитража может иметь два формата: базовый формат и расширенный формат.

a) В базовом формате (при доминантном флаге расширения) поле арбитража должно состоять из одиннадцати битов базового идентификатора и бита RTR. Биты идентификатора должны иметь обозначения с ID-28 по ID-18.

b) В расширенном формате (при рецессивном флаге расширения) поле арбитража должно состоять из базового идентификатора (с ID-28 по ID-18), битов SRR и IDE (оба бита - рецессивные), расширения идентификатора (с ID-17 по ID-0) и бита RTR.

Бит 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) на порождающий полином:

X+X+X+X+X+X+Х+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 два рецессивных бита.

а) Интервал 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 Поле управления

И в базовом, и в расширенном формате поле управления кадра удаленного запроса 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 Параметры кадра перегрузки

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 Параметры межкадрового промежутка

10.4.6.1 Описание

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

Междукадровый промежуток должен состоять из битовых полей паузы и свободного состояния шины, а также поля отложенной передачи для пассивных к ошибке узлов, которые являлись передатчиками предыдущих кадров (см. рисунки 8 и 9).

Рисунок 8 - Междукадровые промежутки для узлов, не пассивных к ошибкам, или приемников предыдущего кадра

Рисунок 9 - Междукадровые промежутки для узлов, пассивных к ошибкам, которые являлись передатчиками предыдущего кадра

10.4.6.2 Пауза

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

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

10.4.6.3 Свободное состояние шины

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

Обнаружение на шине доминантного бита во время свободного состояния шины должно интерпретироваться как SOF.

10.4.6.4 Отложенная передача

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

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

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

Таблица 6 - Дополняющие биты

Остальные битовые поля кадра данных или удаленного запроса (разделитель CRC, поле ACK и EOF) должны иметь фиксированный формат и не должны заполняться.

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

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

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

Каждое из битовых полей кадра должно передаваться одно за другим, начиная с его поля SOF. Старший значащий бит (MSB) каждого поля должен передаваться первым (см. рисунки 10 и 11).

Рисунок 10 - Порядок передачи битов (базовый формат)

Рисунок 11 - Порядок передачи битов (расширенный формат)

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

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

a) Кадр должен быть правильным для передатчиков, если до конца EOF нет ошибок. Если кадр поврежден, должно выполняться восстановление в соответствии с 8.3.4.

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

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

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

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

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

10.8.2 Мультимастер

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

10.8.3 Обнаружение свободного состояния шины

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

10.8.4 Доступ к шине

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

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

10.8.5 Передача кадров MAC

Кадры данных MAC и кадры удаленного запроса MAC могут начинаться, когда узел получает доступ к шине в соответствии с 10.8.4. Кадр ошибки MAC должен передаваться в соответствии с 10.10. Кадр перегрузки MAC должен передаваться в соответствии с 10.11.

10.8.6 Арбитраж по содержимому

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

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

Арбитраж по содержимому выполняется на основе идентификатора и бита RTR, следующего за идентификатором.

10.8.7 Приоритет кадра

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

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

10.8.8 Разрешение столкновений

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

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

Кадр данных с определенным идентификатором и ненулевым кодом DLC может передаваться только одним узлом.

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

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

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

- мониторинг;

- проверка правила заполнения;

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

- 15-битный код CRC;

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

Предусмотрено пять типов ошибок, которые не являются взаимоисключающими:

a) ошибка символа

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

Исключения:

- доминантный бит не должен вызывать ошибку символа, если во время арбитража пересылается информация рецессивного бита либо если рецессивный бит пересылается на интервале ACK;

- узел, пересылающий пассивный флаг ошибки и обнаруживший доминантный бит, не должен интерпретировать это как ошибку символа;

b) ошибка заполнения

Ошибка заполнения обнаруживается на битовом интервале из шести последовательных битов равного уровня в поле кадра, которое должно быть закодировано методом битового заполнения;

c) ошибка CRC

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

d) ошибка формата

Ошибка формата должна обнаруживаться, если битовое поле фиксированного формата содержит один или несколько недопустимых битов.

Исключения:

- если приемник обнаруживает доминантный бит на месте последнего бита EOF или любой узел обнаруживает доминантный бит на месте последнего бита разделителя ошибки либо разделителя перегрузки, он не должен интерпретировать это как ошибку формата;

e) ошибка ACK

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

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

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

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

В случае обнаружения ошибки CRC, начиная с бита, следующего за разделителем ACK, должна начаться передача кадра ошибки, если уже не контролируется кадр ошибки для другого состояния ошибки.

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

Перечисленные ниже условия должны вызывать передачу кадра перегрузки:

a) запрошенный LLC кадр перегрузки (по инициативе нижнего уровня LLC): внутреннее состояние приемника, которое требует задержки следующего кадра данных MAC или кадра удаленного запроса MAC;

b) ответный кадр перегрузки (по инициативе нижнего уровня MAC): обнаружение доминантного бита во время первых двух битов паузы, обнаружение доминантного бита на месте последнего бита EOF приемником или обнаружение доминантного бита любым узлом на месте последнего бита разделителя ошибки или разделителя перегрузки.

Запрошенный LLC кадр перегрузки должен начинаться только с первого бита ожидаемой паузы, тогда как ответные кадры перегрузки должны начинаться через один бит после обнаружения доминантного бита при возникновении условия перечисления b). Начало передачи запрошенных LLC кадров перегрузки при возникновении условия перечисления а) должно допускаться, но необязательно для реализации.

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

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

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

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

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

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

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

Физический уровень должен представлять собой электрическую цепь, которая соединяет узел CAN с шиной. Общее количество узлов CAN должно быть ограничено электрической нагрузкой на шине.

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

Физический уровень должен моделироваться в соответствии с ИСО/МЭК 8802-3 (см. также рисунок 12). Физический уровень должен подразделяться на три части:

a) передача сигналов (PLS) должна выполнять функции, относящиеся к двоичному представлению, распределению по времени и синхронизации;

b) нижний уровень подсоединения к физическому каналу (PMA) должен реализовывать функциональную схемотехнику передачи/приема по проводным линиям шины и может обеспечивать средства обнаружения сбоев на шине;

c) интерфейс канала связи (MDI) должен реализовывать механические и электрические интерфейсы между физическим каналом связи и устройством доступа к каналу связи (MAU).

MAU должно соответствовать функциональной части физического уровня, применяемой для соединения узла со средством передачи. MAU состоит из PMA и MDI.

Рисунок 12 - Модель архитектуры физического уровня

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

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 Параметры нижнего уровня PLS

12.4.1 Кодирование/декодирование бита

12.4.1.1 Битовый интервал

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

a) Номинальная скорость передачи данных (BR) определяет количество битов в секунду, передаваемых идеальным передатчиком при отсутствии повторной синхронизации.

b) Номинальный битовый интервал t:

.

Номинальный битовый интервал может представляться разделенным на отдельные не перекрывающиеся отрезки времени.

Эти сегменты должны формировать битовый интервал, как это показано на рисунке 13:

- сегмент синхронизации (Sync_Seg),

- сегмент прохождения сигнала (Prop_Seg),

- сегмент фазового буфера 1 (Phase_Seg1),

- сегмент фазового буфера 2 (Phase_Seg2).

Рисунок 13 - Разделение битового интервала

Sync_Seg

Эта часть битового интервала должна использоваться для синхронизации различных узлов CAN на шине. В пределах этого сегмента ожидается фронт сигнала.

Prop_Seg

Эта часть битового интервала должна использоваться для компенсации времен физических задержек в сети. Эти времена задержек состоят из времени прохождения сигнала по шине и внутренних времен задержки узлов CAN.

Phase_Seg1, Phase_Seg2

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

Точка отсчета

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

Время обработки информации

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

Ширина скачка повторной синхронизации (SJW)

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

Время внутренней задержки

Время внутренней задержки узла CAN, t должно являться суммой всех асинхронных задержек, которые возникают на маршрутах передачи и приема относительно логического блока временного распределения битов при помощи IC протокола отдельных узлов CAN. Подробнее см. рисунок 14.

Пояснения к рисунку 14:

1) сумма задержек на входе (t) и выходе (t) узла CAN является критичной для логики временного распределения битов и является важным параметром узла CAN, вычисляемым по формуле

t=t+t.

2) для правильности арбитража должно выполняться следующее условие:

,

т.е. управляющая логика временного распределения передающегося бита с учетом синхронизации CAN требует, чтобы узел A был способен определить правильный уровень на шине для бита n в точке отсчета. Допустимые значения t зависят от необходимой скорости передачи данных и длины строки шины (от t - максимальной дистанции между любыми двумя узлами), а также от возможного временного распределения битов, соответствующего условию арбитража.

Рисунок 14 - Временные соотношения между временными распределениями узлов CAN A и В во время арбитража, временным распределением двух узлов CAN и временами задержек

12.4.1.2 Программирование битового интервала

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

а) Квант времени

Квант времени должен являться фиксированной единицей времени, полученной из периода задающего генератора. Должен быть предусмотрен программируемый предварительный делитель частоты на целочисленные значения в диапазоне как минимум от единицы (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) все прочие фронты перехода с рецессивного на доминантный уровень, удовлетворяющие требованиям а) и b), должны использоваться для повторной синхронизации, за исключением узлов, передающих доминантный бит, которые не выполняют повторную синхронизацию при переходе с рецессивного на доминантный уровень при положительном значении фазовой ошибки (см. 12.4.2.2).

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

12.4.2.2 Фазовая ошибка фронта синхронизации

Фазовая ошибка фронта е определяется положением фронта относительно сегмента Sync_Seg, выраженным в квантах времени. Знак фазовой ошибки определяется:

е=0, если фронт находится в пределах сегмента Sync_Seg,

е>0, если фронт находится до точки отсчета и

е<0, если фронт находится после точки отсчета.

12.4.2.3 Жесткая синхронизация

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

12.4.2.4 Повторная синхронизация бита

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

Если значение фазовой ошибки превышает ширину скачка повторной синхронизации, то:

- при положительном значении фазовой ошибки е сегмент Phase_Seg1 должен расшириться на значение, равное ширине скачка повторной синхронизации, в то время как

- при отрицательном значении фазовой ошибки е сегмент Phase_Seg2 должен сократиться на значение, равное ширине скачка повторной синхронизации.

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

12.4.2.5 Предел допуска отклонения частот задающего генератора

Предел допуска отклонения частот задающего генератора f относительно номинальной частоты f зависит от значений Phase_Seg1, Phase_Seg2, SJW и битового интервала. Максимальное отклонение df частоты f при условии

должно соответствовать еще двум условиям:

1)

;

2)

.

Максимальная разница между двумя задающими генераторами должна составлять 2df·f.

12.5 Параметры интерфейса PLS-PMA

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 Описание супервайзера

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

13.1.1 Технические требования

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

- различие между кратковременными сбоями и постоянными отказами и

- локализацию, и отключение отказавших узлов.

13.1.2 Стратегии

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

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

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

13.1.3 Параметры интерфейса предотвращения ошибок

13.1.3.1 Описание

Интерфейс предотвращения ошибок должен соответствовать рисунку 15.

13.1.3.2 Интерфейс между нижним уровнем LLC и FCE

Сообщения, которыми обмениваются подсистема предотвращения ошибок (FCE) и нижний уровень LLC, должны соответствовать таблице 7.

Рисунок 15 - Интерфейс предотвращения ошибок

Таблица 7 - Сообщения между LLC и FCE

13.1.3.3 Интерфейс между нижним уровнем MAC и FCE

Сообщения, которыми обмениваются FCE и нижний уровень MAC, должны соответствовать таблице 8.

Таблица 8 - Сообщения между MAC и FCE

13.1.3.4 Интерфейс между физическим уровнем и FCE

Сообщения, которыми обмениваются FCE и физический уровень, должны соответствовать таблице 9.

Таблица 9 - Сообщения между FCE и физическим уровнем

13.1.4 Правила предотвращения ошибок

13.1.4.1 Описание

Относительно предотвращения ошибок узел может находиться в одном из трех состояний в зависимости от уровней счетчика ошибок (см. 6.13-6.15):

- активность к ошибкам;

- пассивность к ошибкам;

- отключение от шины.

13.1.4.2 Подсчет ошибок

Счетчики ошибок должны быть модифицированы в соответствии со следующими правилами (при передаче данного кадра может применяться более одного правила).

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

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

c) Когда передатчик пересылает флаг ошибки, показания счетчика ошибок передачи должны увеличиться на восемь (8).

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

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].

13.1.4.4 Управление отключением от шины

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

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

Узел в состоянии отключения от шины может стать активным к ошибкам и больше не являться отключенным от шины, если оба его счетчика ошибок устанавливаются в нуль (0) после контроля ста двадцати восьми (128) появлений на шине одиннадцати (11) последовательных рецессивных битов (см. рисунок 16). Начало последовательности восстановления можно выполнять программно или аппаратно - в зависимости от реализации.

Примечание - Существующие реализации могут быть разными. Например, 6.15 допускает отключение передатчика и приемника; восстановление может начаться только по запросу пользователя. Это не покрывается тестированием на соответствие согласно ИСО 16845.

Рисунок 16 - Схема смены состояния узла

13.1.5 Запуск системы

Если при запуске системы на связи только один узел и если этот узел передает какой-либо кадр, он не должен получать подтверждение, обнаруживать ошибки и повторять кадр. В соответствии с перечислениями с), 1) 13.1.4.2 он может стать пассивным к ошибкам, но не может отключаться от шины.

Узел, который был отключен, должен пройти следующую процедуру:

a) синхронизация с уже доступными узлами перед началом передачи - синхронизация достигается, когда одиннадцать (11) рецессивных битов эквивалентны:

- разделителю ACK + EOF + паузе или

- разделителю ошибки/перегрузки + обнаружению паузы и

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

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

При обычной работе несколько отказов на шине могут повлиять на работу шины. Эти отказы и итоговое поведение сети должны соответствовать ИСО 11898-2.

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

Приложение ДА
(справочное)

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

Таблица ДА.1

Электронный текст документа

и сверен по:

, 2016