ГОСТ Р ИСО 11783-3-2021

ОбозначениеГОСТ Р ИСО 11783-3-2021
НаименованиеТракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 3. Уровень канала передачи данных
СтатусДействует
Дата введения01.01.2022
Дата отмены-
Заменен на-
Код ОКС65.060.01
Текст ГОСТа

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

НАЦИОНАЛЬНЫЙ ГОСТ Р



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

ИСО 11783-3— 2021


Тракторы и машины для сельского и лесного хозяйства

ПОСЛЕДОВАТЕЛЬНАЯ СЕТЬ УПРАВЛЕНИЯ И ПЕРЕДАЧИ ДАННЫХ

Часть 3

Уровень канала передачи данных

(ISO11783-3:2018, IDT)

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

Москва Российский институт стандартизации 2021

Предисловие

  • 1 ПОДГОТОВЛЕН Российской ассоциацией производителей специализированной техники и оборудования (Ассоциация «Росспецмаш») на основе собственного перевода на русский язык англоязычной версии указанного в пункте 4 стандарта

  • 2 ВНЕСЕН Техническим комитетом по стандартизации ТК 284 «Тракторы и машины сельскохозяйственные»

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

  • 4 Настоящий стандарт идентичен международному стандарту ИСО 11783-3:2018 «Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 3. Уровень канала передачи данных» (ISO 11783-3:2018 Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 3: Data link layer, IDT).

Международный стандарт разработан Техническим комитетом ИСО/ТС 23 «Тракторы и машины для сельского и лесного хозяйства», Подкомитетом SC 19 «Сельскохозяйственная электроника» Международной организации по стандартизации (ИСО).

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

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

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

© ISO, 2018

© Оформление. ФГБУ «РСТ», 2021

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

Содержание

  • 1 Область применения

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

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

  • 4 Общее описание

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

  • 5.1 Формат кадра сообщения

  • 5.2 Протокольный блок данных (PDU)

  • 5.3 Форматы протокольного блока данных (PDU)

  • 5.4 Типы сообщения

  • 5.5 Приоритет сообщения

  • 5.6 Доступ к шине

  • 5.7 Арбитраж на основе разногласий

  • 5.8 Выявление ошибок

  • 5.9 Процесс назначения для SA и PGN

  • 5.10 Функции транспортного протокола

  • 5.11 Функции расширенного транспортного протокола

  • 5.12 Требования к обработке PDU

  • 5.13 Замечания по применению

Приложение А (обязательное) Обработка PDU по ИСО 11783 — типичная процедура приема

Приложение В (обязательное) Последовательности передачи транспортного протокола — примеры подключения режима передачи данных

Приложение С (обязательное) Примеры режима связи

Приложение D (обязательное) Использование полосы пропускания сети

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

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

Введение

Части с 1 по 14 серии стандартов ИСО 11783 устанавливают систему коммуникаций сельскохозяйственного оборудования, основанную на ИСО 11898-2. Документы SAE J 1939 [1], на части которых основан стандарт ИСО 11783, были разработаны для совместного использования на грузовых автомобилях и автобусах, а также для применения в строительстве и сельском хозяйстве. Были разработаны общие документы, позволяющие использовать после минимальных изменений в сельскохозяйственном и лесохозяйственном оборудовании электронные блоки, соответствующие техническим условиям SAE J 1939 для грузовых автомобилей и автобусов. Общая информация по всем частям серии стандартов ИСО 11783 приведена в ИСО 11783-1.

Цель стандартов серии ИСО 11783 состоит в предоставлении открытой взаимосвязанной системы для бортовых электронных систем. Стандарт предназначен для обеспечения связи электронных блоков управления (ECU) со всеми другими блоками в целях создания стандартной системы.

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

Тракторы и машины для сельского и лесного хозяйства ПОСЛЕДОВАТЕЛЬНАЯ СЕТЬ УПРАВЛЕНИЯ И ПЕРЕДАЧИ ДАННЫХ Часть 3 Уровень канала передачи данных

Tractors and machinery for agriculture and forestry. Serial control and communications data network.

  • Part 3. Data link layer

Дата введения — 2022—01—01

  • 1 Область применения

Настоящий стандарт определяет приложение, протоколы сетевого уровня и сопоставление с протоколом уровня передачи данных местной контроллерной сети (CAN), как указано в ИСО 11898-1. Уровень приложений определяет протокольные блоки данных (PDU), которые могут быть сопоставлены с кадрами данных Классической CAN с использованием Классического Расширенного Формата Кадра (CEFF). Для PDU, превышающих длину кадров данных в формате CEFF, настоящий стандарт определяет протоколы транспортного уровня и сопоставление с кадрами данных в формате CEFF.

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

В настоящем стандарте использованы нормативные ссылки на следующие стандарты [для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных — последнее издание (включая все изменения)].

ISO 11783-1, Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 1: General standard for mobile data communication (Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 1. Общий стандарт на мобильную передачу данных)

ISO 11783-3, Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 3: Data link layer (Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 3. Уровень канала передачи данных)

ISO 11783-5, Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 5: Network management (Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 5. Управление сетью)

ISO 11783-6, Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 6: Virtual terminal (Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 6. Виртуальный терминал)

ISO 11783-7, Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 7: Implement messages application layer (Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 7.Прикладной уровень сообщений для управления орудием)

ISO 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signaling [Транспорт дорожный. Местная контроллерная сеть (CAN). Часть 1. Канальный уровень и передача сигналов]

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

ISO 15765-2, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 2: Transport protocol and network layer services [Транспорт дорожный. Диагностическая связь по местной контроллерной сети (DoCAN). Часть 2. Транспортный протокол и услуги сетевого уровня]

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

В настоящем стандарте применены термины по ИСО 11783-1 и ИСО 11898-1.

ИСО и МЭК поддерживают терминологические базы данных для использования в стандартизации по следующим адресам:

  • - IEC Electropedia, которая доступна по адресу: http://www.electropedia.org/

  • - платформа ИСО для просмотра в режиме онлайн, которая доступна по адресу: https://www.iso. org/obp

  • 4 Общее описание

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

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

    • 5.1 Формат кадра сообщения

      5.1.1 Общие положения

      Формат кадра сообщения должен соответствовать требованиям CAN. Спецификация CAN, упомянутая в настоящем стандарте, приведена в ИСО 11898-1. При наличии различий между спецификацией CAN и настоящим стандартом следует использовать положения настоящего стандарта.

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

ИСО 11898-1 определяет два классических формата кадра: Классический базовый формат кадра (CBFF) и классический расширенный формат кадра (CEFF). Совместимость с ИСО 11898-1 подразумевает, что сообщения обоих форматов потенциально могут присутствовать в одной сети с использованием определенного битового кодирования, которое позволяет распознавать различные форматы. До этого момента ИСО 11783 также поддерживает оба формата кадров сообщений. Тем не менее, ИСО 11783 определяет только полную стратегию стандартизированной связи с использованием CEFF. Все сообщения CBFF предназначены для проприетарного использования в соответствии с правилами, определенными в настоящем стандарте. Кадры формата FD не должны быть использованы в сети ИСО 11783.

Поэтому контроллеры ИСО 11783 должны использовать CEFF. Сообщения CBFF могут находиться в сети, но только в соответствии с настоящим стандартом.

Кадр данных классического CAN разбирается на разные битовые поля, как показано на рисунке 1. Количество и разделение битов в поле арбитража и управления различаются в сообщениях CBFF и CEFF. Сообщения CBFF, как показано на рисунке 1 а), содержат 11 битов идентификатора в поле арбитража, тогда как поле арбитража сообщений CEFF, как показано на рисунке 1 б), содержит 29 битов идентификатора. ИСО 11783 дополнительно определил биты идентификатора в поле арбитража форматов кадра сообщения CAN. Эти определения приведены в таблице 1.

  • 5.1.2 Формат кадра сообщения по ИСО 11783 (ИСО 11898-1 CEFF)

Сообщение CEFF, показанное на рисунке 1, охватывает единичный протокольный блок данных (PDU). PDU состоит из семи определенных полей, полученных из информации, предоставляемой уровнем приложения:

  • - Приоритет;

  • - Расширенная страница данных (EDP);

  • - Страница данных (DP);

  • - PDU формат (PF),

  • - PDU спецификация (PS), которая может быть адресом назначения (DA), расширением группы (GE) или проприетарной информацией;

  • - Адрес источника (SA);

  • - Данные.

См. 5.2 для подробного описания каждого поля и 5.3 для форматов PDU.

Кадр данных классического базового формата кадра (CBFF) Максимальная длина кадра с заполнением битами = 127 бит

Поле арбитража Контрольное поле

Поле данных


12 бит 6 бит

S R

~ Идентификатор т и 11 бит 1

F R


DLC

4 бита


Поле данных от 0 до 8 байтов


CRC

15 бит


Попе АСК 2 бига


EOF

7 бит


Заполнение битами


Нет заполнения битами

  • а) Базовый классический формат кадра (CBFF)

Кадр данных классического расширенного формата кадра (CEFF) Максимальная длина кадра с заполнением битами = 150 бит

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

Контрольное поле 6 бит

Поле данных

S О F

Идентификатор 11 бит

S R R

I D Е

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

18 бит

R Т R

F D

F

г

0

DLC

4 бита

Поле данных от 0 до 8 байтов

CRC

15 бит

Поле АСК 2 бита

EOF

7 бит

Заполнение битами

Нет заполнения битами

  • б) Расширенный классический формат кадра (CEFF)

Рисунок 1 — Кадры данных классического CAN

Затем поля упаковываются в один кадр данных классического CAN и отправляются через физический носитель другим сетевым контроллерам. Уровни модели OSI, которые поддерживает ИСО 11783, показаны на рисунке 2. Возможно, что для некоторых определений группы параметров требуется более одного классического кадра данных CAN для отправки их информации.

Уровень


Запрашивающая управляющая функция


Получающая управляющая функция

Уровень данных


Priority, PGs, SPs


Priority, PGs, SPs


Протокол уровня приложений


PDU (Priority, EDP, DP PF, PS, DA, SA, Data)


PDU (Priority, EDP, DP PF, PS, DA, SA, Data)


Протокол уровня отображения

Протокол уровня сеанса


Протокол транспортного уровня

Кадры данных CEFF


Кадры данных CEFF


Протокол сетевого уровня


Протокол уровня канала данных

Сигналы и компоненты сети по ISO 11783-2

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

Рисунок 2 — Применение модели OSI в соответствии с ИСО 11783

В таблице 1 показаны поля арбитража и управления для 29-битного идентификатора CAN, 29-бит-ного идентификатора ИСО 11783 и 11-битного идентификатора CAN, а также использование 11-битного идентификатора в сети ИСО 11783. Полное определение для каждого из назначений битовых полей в соответствии с ИСО 11783 приведено в 5.3. В ИСО 11783 поле данных кадра данных CAN описывается как байты с 1 по 8. Бит 1 в байте 8 (наиболее значимый бит) является первым битом, посланным ближе всего к коду длины данных (DLC). Бит 1 (наименее значимый бит) в байте 8, является последним из битов данных, которые должны быть отправлены, и наиболее близок к полю проверки циклическим избыточным кодом (CRC). См. рисунок 3.

Когда расширенная страница данных (EDP) равна 1 и страница данных (DP) равна 1, кадр CAN идентифицируется как кадр с форматом по ИСО 15765-2. ИСО 15765-2 определяет диагностическую связь по CAN (DoCAN). Следовательно, обработка этого конкретного формата кадра CAN не соответствует определениям, указанным в ИСО 11783, и должна соответствовать ИСО 15765-2 (см. 5.2.4).

Таблица 1 — Назначение ИСО 11783 в поля арбитража и контроля CAN

Номер бита

29-битный идентификатор

11-битный идентификатор

CAN

ИСО 11783

CAN

ИСО 11783b

1

SOF

SOFa

SOF

SOFa

2

1D28

РЗ

ID28

P3

3

ID27

Р2

ID27

P2

4

ID26

Р1

ID26

P1

5

ID25

EDP

ID25

ID8a

6

ID24

DP

ID24

ID7a

7

1D23

PF8

ID23

ID6a

8

ID22

PF7

ID22

ID5a

0

ID21

PF6

ID21

ID4a

10

ID20

PF5

ID20

ID3a

11

ID19

PF4

ID19

ID2a

12

ID18

PF3

ID18

ID1a

13

SRR (г)

SRRa

RTR (x)

RTRa (d)

14

IDE (г)

IDEa

IDE (d)

IDEa

15

JD17

PF2

FDF (d)

FDFa

16

ID16

PF1

DLC4

DLC4

17

ID15

PS8

DLC3

DLC3

18

1D14

PS7

DLC2

DLC2

19

ID13

PS6

DLC1

DLC1

20

ID12

PS5

21

ID11

PS4

22

ID10

PS3

23

ID9

PS2

24

ID8

PS1

25

ID7

SA8

26

ID6

SA7

27

ID5

SA6

28

ID4

SA5

29

ID3

SA4

30

ID2

SA3

31

ID1

SA2

32

ID0

SA1

33

RTR (х)

RTRa (d)

Окончание таблицы 1

Номер бита

29-битный идентификатор

11-битный идентификатор

CAN

ИСО 11783

CAN

ИСО 11783ь

34

FDF (х)

FDFa (d)

35

г0 (d)

r0a

36

DLC4

DLC4

37

DLC3

DLC3

38

DLC2

DLC2

39

DLC1

DLC1

SOF

Начало бита кадра

EDP

Расширенная страница данных в соответствии с ИСО 11783

ID##

Номер бита идентификатора (#)

SA#

Номер бита Адреса источника (#) в соответствии с ИСО 11783

SRR

Заменить удаленный запрос

DP

Страница данных в соответствии с ИСО 11783

RTR

Бит запроса удаленной передачи

PF#

Номер бита формата PDU (#) в соответствии с ИСО 11783

IDE

Бит расширения идентификатора

PS#

Конкретный номер бита PDU (#) в соответствии с ИСО 11783

PDF

Индикатор формата FD

(d)

доминантный бит

r#

Зарезервированный номер бита CAN (#)

(r)

рецессивный бит

DLC#

Номер бита кода длины данных (#)

(x)

состояние бита зависит от сообщения

P#

Номер приоритетного бита (#) в соответствии с ИСО 11783

a Определенный CAN бит, без изменений в ИСО 11783.

ь Требуемый формат проприетарных 11-битных идентификаторов.

Рисунок 3 — Поле данных классического CAN

  • 5.1.3 Номера групп параметров (PGN)

Идентификатор группы параметров в поле данных классического кадра данных CAN, расположен в бите 24. Значение бита 24 отправляется первым в наименее значимом байте (LSB) (см. таблицу 2), в соответствии с которой наиболее значимый байт (MSB) отправляется третьим, средний байт — вторым, наименее значимый — первым. Бит 24 PGN состоит из следующих компонентов: 6 битов, установленных на ноль, бит расширенной страницы данных, бит страницы данных, поле формата PDU (8 бит) и специальное поле PDU (8 бит).

Процедура преобразования битовых полей в PGN заключается в следующем. Шесть MSB PGN установлены на ноль. Затем бит расширенной страницы данных, бит страницы данных и поле формата PDU копируются в следующие 10 бит. Если значение PF меньше 240 (F016), то наименее значимый бит PGN устанавливается на ноль. В другом случае он устанавливается на значение поля PS. См. таблицу 2 для иллюстрации PGN, их соответствующих битов и их преобразования в десятичные числа.

Примечание — Не все 131 072 комбинации (217) доступны для назначения в качестве PGN. Для назначения доступно всего 8 672 комбинации {рассчитанных следующим образом: 2 страницы * [240 + (16 х 256)] = 8 672}, используя соглашения, указанные в настоящем стандарте. См. ИСО 11783-1 для последних назначений PGN.

Таблица 2 — Примеры номера группы параметров (PGN)

Составляющие компоненты PGN

PGN

Число назначаемых PG

Суммарное число PG

Назначено по ИСО или изготовителем

PGN (MSB) Байт 1 Пересылается третьим в кадре данных CAN

PGN Байт 2 Пересылается вторым в кадре данных CAN

PGN (LSB) Байт 3 Пересылается первым в кадре данных CAN

Dec10

Нех^

Бит 8—3

EDP

DP

PF

PS

Бит 2

Бит 1

Бит 8—1

Бит 8—1

0

0

0

0

0

0

00000016

ИСО

239

239

0

0

0

238

0

60 928

00EE0016

0

0

0

239

0

61 184

00EF0016

1

240

Изготовитель

0

0

0

240

0

61 440

00F00016

ИСО

3 840

0

0

0

254

255

65 279

00FEFF16

4 080

0

0

0

255

0

65 280

00FF0016

256

Изготовитель

0

0

0

255

255

65 535

00FFFF16

4 336

0

0

1

0

0

65 536

01000016

0

0

1

238

0

126 464

01EE0016

239

ИСО

0

0

1

239

0

126 720

01EF0016

240

4576

Изготовитель

0

0

1

240

0

126 976

01F00016

4 096

ИСО

0

0

1

255

255

131 071

01FFFF16

8 672

  • 5.1.4 Поддержка ИСО 11783 сообщений CBFF по ИСО 11898-1

Контроллеры в сети ИСО 11783 могут поддерживать формат сообщения CBFF (11-битный идентификатор). Хотя они несовместимы со структурой сообщений ИСО 11783, для обеспечения сосуществования двух форматов дан минимальный уровень определения. Это минимальное определение позволяет контроллерам, которые используют этот формат, не мешать другим контроллерам. Сообщения CBFF определяются как проприетарные. Согласно таблице 1, поле 11-битного идентификатора анализируется следующим образом: три наиболее значимых бита используются в качестве битов приоритета; восемь наименее значимых битов идентифицируют SA PDU. Приоритетные биты описаны в 5.2.2. SA описан в 5.2.7.

Неправильный арбитраж шины может произойти, когда два сообщения, один базовый кадр и один расширенный кадр получают доступ к шине одновременно. Адрес источника (SA) имеет более высокий относительный приоритет в сообщениях базового кадра, чем в сообщениях расширенного кадра. Сообщение с 11-битным идентификатором (базовый кадр) может иметь SA, указывающий более высокий приоритет, чем у бита расширенной страницы данных, бита страницы данных и формата PDU 29-битно-го сообщения идентификатора (расширенного кадра). Три приоритетных бита должны использоваться для достижения правильного арбитража шины.

Важно — ИСО 11783 определяет полную стратегию стандартизированной связи с использованием CEFF. Аппаратное обеспечение, которое не соответствует ИСО 11898-1, не должно использоваться в сети, поскольку эти версии аппаратного обеспечения не позволяют передавать сообщения CEFF.

  • 5.2 Протокольный блок данных (PDU)

    5.2.1 Общие положения

    Приложения и (или) сетевой уровень предоставляют строку информации, которая ассимилируется в протокольный блок данных. Протокольный блок данных обеспечивает основу для организации информации, которая необходима для каждого отправляемого классического кадра данных CAN. Протокольный блок данных (PDU) сети ИСО 11783 должен состоять из семи полей, перечисленных в 5.1.2 и указанных ниже. Затем эти поля должны быть упакованы в один или несколько классических кадров данных CAN и отправлены через физический носитель другим сетевым контроллерам. В каждом классическом кадре данных CAN имеется только один PDU.

Примечание — Некоторые определения PGN требуют более одного классического кадра данных CAN для отправки соответствующих данных.

Некоторые биты полей классических кадров данных CAN остаются вне определения PDU, поскольку они полностью контролируются спецификацией CAN и невидимы для всех уровней OSI выше уровня канала передачи данных. К ним относятся поля SOF, SRR, IDE, RTR, FDF, CRC, АСК и EOF, а также части поля управления. Они определены протоколом CAN и не изменяются положениями ИСО 11783.

Поля PDU (см. рисунок 4) указаны в 5.2.2—5.2.8.

Приоритет

EDR

DR

РЕ

PS,

SA,

Данные

Номер бита

...3...,

...1...,

...1...,

...8...,

...8...,

...8...,

...64...

Рисунок 4 — поля PDU

  • 5.2.2 Приоритет (Р)

Приоритетные биты используются только для оптимизации задержки сообщения для передачи на шину. Они должны быть глобально замаскированы принимающим контроллером (игнорируются). Приоритет любого сообщения может быть установлен от самого высокого 0 (0002) до самого низкого 7 (1112). По умолчанию для всех сообщений, ориентированных на управление, 3 (0112). По умолчанию для всех других информационных, проприетарных запросов и сообщений NACK установлено значение 6 (1102). Это позволяет в будущем повышать или понижать приоритет по мере назначения новых значений PGN и изменения трафика шины. Рекомендуемый приоритет назначается каждому PGN, когда он добавляется к стандартам уровня приложений. Однако поле приоритета должно быть перепрограммируемым, чтобы производители могли настраивать сеть в случае необходимости.

  • 5.2.3 Расширенная страница данных (EDP)

Бит расширенной страницы данных (EDP) используется вместе с битом страницы данных для определения структуры идентификатора CAN классического кадра данных CAN. Все сообщения ИСО 11783 должны устанавливать бит расширенной страницы данных в ноль при передаче. (См. таблицу 3 для определенного использования полей EDP и DP.) Возможно, что будущие определения будут расширять поле Формат PDU, определяя новые форматы PDU, расширяя поле приоритета или увеличивая адресное пространство.

  • 5.2.4 Страница данных (DP)

Бит страницы данных (DP) используется вместе с битом EDP для определения структуры идентификатора CAN классического кадра данных CAN. Если для параметра EDP установлено значение 0, бит DP выбирается между страницей 0 и страницей 1 описания PGN. См. таблицу 3.

Таблица 3 — Определение использования расширенной страницы данных (EDP) и страницы данных (DP)

EDP бит 25

DP бит 24

Описание

CAN ID бит 25

CAN ID бит 24

0

0

ИСО 11783 страница 0 PGN

0

1

ИСО 11783 страница 1 PGN

1

0

ИСО 11783 зарезервировано

1

1

PGN по ИСО 15765-2

Примечание — EDP и DP 29-битного идентификатора CAN, установленного на «112», идентифицируют его как сообщение ИСО 15765-2. Это означает, что оставшиеся биты идентификатора CAN не установлены в соответствии со стандартом ИСО 11783; Кадры CAN, следующие этому формату, не описаны в ИСО 11783.

  • 5.2.5 Формат PDU (PF)

Формат PDU (PF) — это 8-битовое поле, которое определяет формат PDU и является одним из полей, используемых для определения PGN, назначенного классическому полю данных CAN. PGN используются для идентификации или маркировки команд, данных, некоторых запросов, подтверждений и отрицательных подтверждений, а также для идентификации или маркировки информации, для которой требуется один или несколько классических кадров данных CAN для передачи информации. Если имеется больше информации, чем может поместиться в восьми байтах данных, необходимо отправить многопакетное сообщение. Если имеется восемь или менее байтов данных, то используется один классический кадр данных CAN. PGN может представлять один или несколько параметров, где параметр представляет собой фрагмент данных, например обороты двигателя в минуту. Даже если метка PGN может использоваться для одного параметра, рекомендуется сгруппировать несколько параметров, чтобы использовать все 8 байтов поля данных.

Определение двух проприетарных PGN позволяет использовать оба формата: PDU1 и PDU2. Интерпретация конфиденциальной информации варьируется между производителями.

Пример — Даже если два разных двигателя могут использовать общий набор стандартных PGN, вполне вероятно, что проприетарные сообщения одного производителя будут отличаться от сообщений другого.

  • 5.2.6 Специальное поле PDU (PS)

Специальное поле PDU (PS) является 8-битовым полем, определение которого зависит от формата PDU, которое определяет, будет ли оно полем DA или GE. См. таблицу 4.

Таблица 4 — Определение специального поля PDU (PS)

Формат PDU

PF

PS

PDU1

0—239

Адрес назначения (DA)

PDU2

240—255

Расширение группы (GE)

Поле DA определяет конкретный адрес, на который отправляется сообщение. Любой другой контроллер должен игнорировать это сообщение. Глобальный адрес назначения (255) требует, чтобы все контроллеры слушали и отвечали соответственно, как получатели сообщений.

Поле GE в сочетании с четырьмя наименее значимыми битами поля PF обеспечивает 4 096 групп параметров на страницу данных. Они доступны только с использованием PDU формата GE (PDU2).

Примечание — Когда четыре наиболее значимых бита поля формата PDU установлены, это указывает, что поле PS является полем GE.

Кроме того, 240 групп параметров предоставляются на каждой странице данных для использования только в PDU-формате, определяемом адресатом (формат PDU1). Всего доступно 8 672 группы параметров, которые можно определить, используя две доступные страницы данных.

Эта сумма рассчитывается по формуле (1):

[240 + (16 • 256)] -2 = 8 672,

(1)


где 240 — количество значений поля формата PDU, доступных для каждой страницы данных (то есть формат PDU1, поле PS = DA);

16 — число значений формата PDU на значение GE (т. е. только формат PDU2);

256 — количество возможных значений GE (то есть только формат PDU2);

  • 2 — количество состояний страницы данных (оба формата PDU).

См. также 5.3.

  • 5.2.7 Адрес источника (SA)

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

Примечание — Управление адресами и их распределение, а также процедуры по предотвращению дублирования SAcm. ИСО 11783-5.

  • 5.2.8 Поле данных

    • 5.2.8.1 Данные от 0 до 8 байт

Если для описания заданной группы параметров требуется восемь или менее байтов данных, то могут использоваться все восемь байтов данных классического кадра данных CAN. Рекомендуется выделять или резервировать 8 байтов для всех PGN, которые могут расширяться в будущем. Это позволяет легко добавлять параметры и избегать несовместимости с предыдущими версиями, которые определяют только часть поля данных. Как только количество байтов данных, связанных с PGN, указано, оно не может быть изменено (и также не может стать многопакетным, если оно изначально не определено как таковое). Код длины данных CAN (DLC) устанавливается равным значению «длина данных» определенной группы параметров, когда оно составляет 8 байт или меньше; в противном случае, когда длина данных PG составляет 9 байт или более, CAN DLC устанавливается на 8. Например, REQUEST PGN 59 904 имеет длину данных PG в 3 байта, поэтому CAN DLC устанавливается на 3. Функция отдельной группы (см. 5.4.6) должна использовать одинаковую длину поля данных, поскольку идентификатор CAN всегда идентичен; в то время как классическое поле данных CAN используется для передачи определенных групповых подфункций. Эти групповые функции требуют много разных интерпретаций, основанных на классическом поле данных CAN.

  • 5.2.8.2 Данные свыше 8 байт

Когда для выражения заданной группы параметров требуется более 8 байтов данных, передача этих данных осуществляется в нескольких классических кадрах данных CAN. Термин «многопакетный» используется для описания этого типа группы параметров. Группа параметров, определенная как способная к работе с несколькими пакетами и имеющая менее девяти байтов данных для передачи в конкретном случае, должна отправляться в одном классическом кадре данных CAN с DLC, установленным на 8. Когда конкретная группа параметров имеет девять или более байтов данных для передачи, затем используется одна из функций транспортного протокола. Возможность управления соединением с транспортной функцией используется для настройки и закрытия связи многопакетных групп параметров. Возможность передачи данных транспортного протокола используется для передачи самих данных в серии классических кадров данных CAN (пакетов), содержащих «пакетированные» данные. Кроме того, функция транспортного протокола обеспечивает возможности управления потоком и установления связи для передачи по месту назначения (см. 5.10).

Все классические кадры данных CAN, связанные с конкретным многопакетным ответом, должны иметь DLC, равный 8. Все неиспользуемые байты данных имеют значение «Недоступно». Количество байтов в пакете является фиксированным; тем не менее, ИСО 11783 определяет многопакетные сообщения, которые имеют переменное и/или фиксированное количество пакетов. PGN для активных диагностических кодов является примером многопакетного сообщения, которое имеет переменное количество пакетов. Группы параметров, которые определены как многопакетные, используют транспортный протокол, только когда количество отправляемых байтов данных превышает восемь.

  • 5.3 Форматы протокольного блока данных (PDU)

    5.3.1 Общие положения

    Доступные форматы PDU, показанные на рисунке 5, определены как PDLI1 (PS = DA) и PDU2 (PS = GE). PDLI1 позволяет направлять кадр данных классической CAN на конкретный адрес назначения (управляющей функции); PDU2 передает только кадры данных классической CAN, которые не зависят от места назначения. Два отдельных формата PDU создаются для обеспечения различных возможных комбинаций номеров групп параметров, в то же время обеспечивая связь для конкретного адреса назначения. Собственные определения группы параметров назначаются таким образом, чтобы оба формата PDU могли использоваться для проприетарной связи. Стандартизированный метод для проприетарной связи определен, чтобы предотвратить возможные конфликты в использовании идентификатора.

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

Приоритет

EDR

DR

PR

PS(DA),

SA,

Данные

Номер бита

...3...,

...1...,

...1...,

...8...,

...8...,

...8...,

...64...,

a) PDU1

Приоритет

EDR

DR

PR

PS(GE),

SA,

Данные

Номер бита

...3...,

...1...,

...1...,

...8...,

...8...,

...8...,

...64...,

b) PDU2

Рисунок 5 — Доступные форматы PDU

  • 5.3.2 Формат PDU1

Формат PDU1 предусматривает отправку применимых групп параметров либо в конкретный, либо в глобальный адрес назначения. Поле PS содержит DA.

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

Сообщения формата PDU1 определяются полем PF. Когда значение этого поля составляет от 0 до 239, сообщение имеет формат PDLI1. Формат сообщения PDLI1 показан на рисунке 5. Также см. рисунок 6.

PGN

Доступно для формата PDU1a

а В настоящее время 2 х 240 = 480.

Рисунок 6 — формат PDU1

Группы параметров, требующие назначения (PDU1) и минимальной задержки, начинаются с PF = 0 и увеличиваются в направлении х (или х1).

См. таблицу 7.

PF, равный 239 (бит расширенной страницы данных = 0 и бит страницы данных = 0), назначается для проприетарного использования. В этом случае поле PS является адресом назначения (см. 5.4.6). PGN для проприетарного А составляет 61 184.

  • 5.3.3 Формат PDU2

Формат PDLI2 может использоваться только для передачи групп параметров в виде глобальных сообщений. Сообщения формата PDU2 могут быть запрошены или отправлены как нежелательные сообщения. Выбор формата PDU2 во время назначения PGN предотвращает возможность направления PGN в конкретный адрес назначения. Поле PS содержит GE.

Сообщения формата PDU2 определяются как сообщения, в которых значение PF равняется от 240 до 255. Формат сообщения PDLI2 показан на рисунке 5. Также см. рисунок 7.

PGN

Доступно для формата PDU2a

а В настоящее время 2 х 16 х 256 = 8192.

Рисунок 7 — Формат PDU2

PGN сообщений, которые отправляются с высокой скоростью обновления (обычно менее 100 мс), начинается с PF = 240 и увеличивается в направлении у (или у1).

PGN сообщений, которые запрашиваются, отправляются только при изменении или отправляются с низкой частотой обновления (обычно более 100 мс), начинаются с PF = 254 и уменьшаются в направлении у (или у1).

См. таблицу 7.

PF, равный 255 (бит расширенной страницы данных = 0 и бит страницы данных = 0), назначается для проприетарного использования. Поле PS оставлено для определения и использования каждым производителем (см. 5.4.6). PGN для проприетарного В охватывает диапазон от 65 280 до 65 535.

  • 5.4 Типы сообщения

    5.4.1 Общие положения

    В настоящее время поддерживается пять видов сообщений:

  • - Команды;

  • - Запросы;

  • - Трансляции/Ответы;

  • - Подтверждения;

  • - Групповые функции.

Конкретный тип сообщения распознается по назначенному ему PGN. Бит RTR (определенный в протоколе CAN для удаленных кадров) не должен использоваться в рецессивном состоянии (логическая 1). Поэтому запрос удаленной передачи (RTR = 1) недоступен для использования в сети ИСО 11783.

RTR предназначался для «запроса» определенного объекта CAN путем простого объявления его идентификатора CAN в сети без каких-либо байтов данных. Поскольку ИСО 11783 использует часть идентификатора CAN для приоритета сообщения и часть для адреса источника, этот механизм вызовет конфликты. Устройство не может отправлять сообщения с SA другого устройства. В ИСО 11783 существует отдельный механизм запроса. См. 5.4.3.

Многобайтовые параметры, которые появляются в поле данных классического кадра данных CAN, должны быть помещены в наименее значимый бит. Исключения отмечены, где это применимо (то есть данные ASCII). Если 2-байтовый параметр должен быть размещен в байтах 7 и 8 классического кадра данных CAN, наименее значимый бит будет помещен в байт 7, a MSB — в байт 8.

  • 5.4.2 Команда

Тип командного сообщения классифицирует те группы параметров, которые задают конкретный или глобальный адрес назначения из источника. Затем предполагается, что адрес назначения должен предпринять определенные действия на основе приема этого типа командного сообщения. Как команды PDU1 (PS = DA), так и сообщения формата PDLI2 (PS = GE) могут использоваться для команд. Примеры командных режимов включают управление передачей, запрос адреса и управление крутящим моментом/скоростью.

  • 5.4.3 Запрос

Тип сообщения запроса, идентифицируемый PGN, предоставляет возможность запрашивать информацию глобально или из определенного места назначения. Запросы, специфичные для одного адреса назначения, называются запросами, специфичными для адреса назначения. Приведенная ниже информация назначает PGN группе параметров запроса PGN. Эта информация представлена в том же формате, что и определения групп параметров в стандарте ИСО 11783.

Имя группы параметров:

ЗАПРОС

Определение:

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

Частота повторения передач:

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

Длина данных:

3 байта (Классический кадр CAN для этого PG должен установить DLC на 3)

Страница данных:

0

PF:

234

PS:

DA (глобальный или конкретный)

Приоритет по умолчанию:

6

Номер группы параметров:

59 904 (00ЕА0016)

Байты:1,2, 3

Запрашивается PGN (см. 5.1.3 для определения поля и порядка байтов)

В таблице 5 перечислены возможности запроса/ответа для PDII1 и PDU2 формата PGN. В нем поясняется, что отправляющая управляющая функция сообщением определяет, является ли адрес назначения конкретным или глобальным, в зависимости от того, был ли запрос к конкретному или глобальному DA. Таблица 5 также иллюстрирует, что для незапрошенных сообщений отправляющая управляющая функция может передавать на конкретный или глобальный ОАдля PDU1 и PDLI2 PGN с более чем 8 байтами. Для PDU2 PGN с 8 байтами или меньше отправляющая управляющая функция может отправлять данные только глобально.

Таблица 5 — PDU1 и PDU2 требования к передаче, запросу и ответу

Формат PDU

Длина данных, байт

Запрос PGN 59 904

Ответ

Использование ТР

1

<8

DA конкретный

DA конкретный

Не допускается

1

<8

DA глобальный

DA глобальный

Не допускается

1

<8

нет

DA глобальный

Не допускается

DA конкретный

Не допускается

1

>8

DA конкретный

DA конкретный

RTS/CTS

1

>8

DA глобальный

DA глобальный

ВАМ

1

>8

нет

DA глобальный

ВАМ

DA конкретный

RTS/CTS

Окончание таблицы 5

Формат PDU

Длина данных, байт

Запрос PGN 59 904

Ответ

Использование TP

2

<8

DA конкретный

DA глобальный

Не допускается

2

<8

DA глобальный

DA глобальный

Не допускается

2

<8

нет

DA глобальный

Не допускается

2

>8

DA конкретный

DA конкретный

RTS/CTS

2

>8

DA глобальный

DA глобальный

ВАМ

2

>8

нет

DA глобальный

ВАМ

DA конкретный

RTS/CTS

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

  • а) Если запрос отправляется на глобальный адрес, то ответ также отправляется на глобальный адрес.

NACK (см. 5.4.5) не разрешен в качестве ответа на глобальный запрос.

  • Ь) Если запрос отправляется на конкретный адрес, то ответ отправляется на конкретный адрес.

NACK требуется, если PGN не поддерживается.

Если длина данных составляет 8 байт или более, транспортный протокол RTS/CTS должен использоваться для ответа на конкретный адрес.

Исключения:

  • - PDLI2 формат PGN с 8 байтами или менее может быть отправлен только на глобальный адрес назначения, потому что в формате PDU2 нет поля адреса назначения.

  • - Объявление адреса PGN отправляется на глобальный адрес назначения, даже если запрос был адресован конкретному адресу назначения (см. ИСО 11783-5).

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

Исключения:

  • - PDLI2 формата PGN с 8 байтами или меньше может быть отправлен только на глобальный адрес назначения, потому что в формате PDLI2 нет поля адреса назначения.

  • d) Исключения из этих правил существуют, как видно из вышесказанного. Исключения отмечены в соответствующем документе в разделе, в котором определен PGN.

В таблице 6 приведены два примера использования запроса PGN.

Таблица 6 — Использование указанных полей в формате ИСО 11783 PDU1

Тип сообщения

PGN

PS (DA)

SA

Данные 1

Данные 2

Данные 3

Глобальный запрос

59 904

255 (Отвечающий)

SA1 (Запрашивающий)

PGN LSBa

PGN

PGN MSBa

Конкретный запрос

59 904

SA2 (отвечающий)

SA1 (Запрашивающий)

PGN LSBa

PGN

PGN MSBa

а Номер группы параметров (PGN) в поле данных используется для идентификации запрашиваемой информации.

Ответ всегда требуется от конкретного адреса назначения (не глобального), даже если это NACK, указывающий, что конкретное значение PGN не поддерживается. На глобальный запрос нельзя отвечать NACK, когда конкретный PGN не поддерживается управляющей функцией.

Примечание 1 — Некоторые PGN являются многопакетными, поэтому для одного запроса могут возникать несколько кадров данных классического CAN.

Запрос PGN может быть направлен на конкретный адрес назначения, чтобы определить, поддерживается ли конкретная группа параметров (т. е. «передает ли запрошенный адрес назначения конкретную группу?»). Ответ на запрос определяет, поддерживается ли PGN. Если поддерживается, то получающая управляющая функция должна отправлять запрошенную информацию. Если PGN подтверждения является подходящим, то контрольный байт должен быть установлен в 0, 2 или 3. Если это не поддерживается, управляющая функция приемом должна отправить PGN подтверждения с байтом управления, установленным в 1, для отрицательного подтверждения. Остальные части формата и группы параметров PDU ИСО 11783 должны быть заполнены соответствующим образом (см. 5.4.5). С помощью этого метода невозможно определить, действует ли управляющая функция на PG (при получении).

Примечание 2 — «Не поддерживается» выше означает, что PG не передается.

Если управляющей функции не удается получить ответ (либо PG, либо ПОДТВЕРЖДЕНИЕ) на запрос в течение времени ожидания ответа, то управляющая функция может повторно отправить или повторить тот же запрос. Количество повторных попыток для конкретного запроса должно быть ограничено двумя (2) повторными попытками, то есть запрос выдается в общей сложности три (3) раза. Если управляющей функции не удается получить ответ (либо PG, либо ПОДТВЕРЖДЕНИЕ) на запрос после второй попытки, то управляющая функция должна отказаться от дальнейших попыток запроса той же информации или управляющая функция может ожидать в течение продолжительного периода времени (минут, а не секунд), прежде чем пытаться запросить ту же информацию.

  • 5.4.4 Трансляция/ответ

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

  • 5.4.5 Подтверждение

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

Вторая форма подтверждения является ответом «нормальной трансляции», «АСК» или «NACK» на конкретную команду или запрос, как предусмотрено прикладным уровнем. Определение группы параметров подтверждения показано ниже. Тип подтверждения, требуемый для некоторых групп параметров, определяется на уровне приложений.

Для групп параметров групповой функции (см. 5.4.6) параметр «Значение групповой функции» позволяет управляющей функции идентифицировать конкретную групповую функцию, которая подтверждается. Значение групповой функции уникально для каждой групповой функции PG. Желательно, чтобы значения групповой функции использовали только диапазон от 0 до 250.

Каждая форма Подтверждения включает в себя байт подтверждения адреса, содержащий адрес источника отправителя запроса, на который направлено подтверждение. Для максимальной совместимости с SAE Л 939 поле подтверждения адреса является дубликатом поля PS. Параметры в байте 5: подтверждение адреса, отрицательное подтверждение адреса, отказ в доступе к адресу и занятый адрес.

Имя группы параметров:

ПОДТВЕРЖДЕНИЕ

Определение:

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

Частота повторения передач:

при получении PGN, который требует эту форму подтверждения

Длина данных:

8 байт

Страница данных:

0

PF:

232

PS:

DA

Приоритет по умолчанию:

6

Номер группы параметров:

59 392 (00Е80016)

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

Контрольный байт:

от 0 до 3

См. определения ниже

4 до 127

Зарезервировано для назначения в будущем стандарте

128 до 131

См. определения ниже

132 до 143

Зарезервировано для назначения в будущем стандарте

144 до 147

См. определения ниже

148 до 159

Зарезервировано для назначения в будущем стандарте

160 до 163

См. определения ниже

164 до 255

Зарезервировано для назначения в будущем стандарте

Значение групповой функции

0 до 250

Определение является специфическим для отдельного PGN, когда это применимо. Чаще всего он располагается в качестве первого байта в поле данных соответствующей группы параметров групповой функции.

251 до 255

Следует конвенциям, определенным в ИСО 11783-7.

Положительное подтверждение: контрольный байт = 0

Байт:

1

Контрольный байт = 0, Положительное подтверждение (АСК)

Байт:

2

Значение групповой функции (если применимо) (см. 5.4.6) в противном случае FF16

Байт:

от 3 до 4

Зарезервировано для назначения в будущем стандарте; отправить каждый из этих байтов как FF16

Байт:

5

Подтверждение адреса

Байт:

6

PGN запрашиваемой информации (8 LSB номера группы параметров, бит 8 MSB)

Байт:

7

PGN запрашиваемой информации (второй байт номера группы параметров, бит 8 MSB)

Байт:

8

PGN запрашиваемой информации (8 MSB номера группы параметров, бит 8 MSB)

Отрицательное подтверждение: контрольный байт = 1

Байт:

1

Контрольный байт = 1, Отрицательное подтверждение (NACK)

Байт:

2

Значение групповой функции (если применимо) (см. 5.4.6) в противном случае FF16

Байт:

от 3 до 4

Зарезервировано для назначения в будущем стандарте; отправить каждый из этих байтов как FF16

Байт:

5

Отрицательное подтверждение адреса

Байт:

от 6 до 8

PGN запрашиваемой информации (см. выше)

Доступ запрещен: контрольный байт = 2

Байт:

1

Контрольный байт = 2, Доступ запрещен (PGN поддерживается, но доступ к безопасному режиму запрещен)

Байт:

2

Значение групповой функции (если применимо) (см. 5.4.6) в противном случае использовать FF16

Байт:

от 3 до 4

Зарезервировано для назначения в будущем стандарте; отправить каждый из этих байтов как FF16

Байт:

5

Доступ к адресу защищен

Байт:

от 6 до 8

PGN запрашиваемой информации (см. выше)

Не может ответить: контрольный байт = 3

Байт:

1

контрольный байт = 3; Не может ответить (PGN поддерживается, но ECU занят и не может ответить сейчас, запросите данные позже)

Байт:

2

Значение групповой функции (если применимо) (см. 5.4.6) в противном случае использовать FF16

Байт:

от 3 до 4

Зарезервировано для назначения в будущем стандарте; отправить каждый из этих байтов как FF16

Байт:

5

Адрес занят

Байт:

от 6 до 8

PGN запрашиваемой информации (см. выше)

Особые

случаи ПОДТВЕРЖДЕНИЯ возможны только для ситуаций, когда Request2 использует

расширенный тип идентификатора (см. 5.4.7).

Положительное подтверждение: контрольный байт = 128 и Тип расширенного идентификатора «Однобайтовый расширенный идентификатор»

Байт:

1

Контрольный байт = 128, Положительное подтверждение (АСК)

Байт:

2

Значение групповой функции = Расширенному идентификатору

Байт

от 3 до 4

Зарезервировано для назначения в будущем стандарте; отправить каждый из этих байтов как FF16

Байт:

5

Подтверждение адреса

Байт:

от 6 до 8

PGN запрашиваемой информации (см. выше)

Отрицательное подтверждение: контрольный байт = 129 и Тип расширенного идентификатора «Однобайтовый расширенный идентификатор»

Байт

1

Контрольный байт = 129, Отрицательное подтверждение (NACK)

Байт:

2

Значение групповой функции = Расширенному идентификатору

Байт:

от 3 до 4

Зарезервировано для назначения в будущем стандарте; отправить каждый из этих байтов как FF16

Байт

5

Отрицательное подтверждение адреса

Байт:

от 6 до 8

PGN запрашиваемой информации (см. выше)

Доступ запрещен: контрольный байт = 130 и Тип расширенного идентификатора «Однобайтовый расширенный идентификатор»

Байт:

1

Контрольный байт = 130, Доступ запрещен (PGN поддерживается, но доступ к безопасному режиму запрещен)

Байт:

2

Значение групповой функции = Расширенному идентификатору

Байт:

от 3 до 4

Зарезервировано для назначения в будущем стандарте; отправить каждый из этих байтов как FF16

Байт:

5

Доступ к адресу запрещен

Байт:

от 6 до 8

PGN запрашиваемой информации (см. выше)

Не может ответить: контрольный байт = 131 и Расширенный типа идентификатора «Однобайтовый расширенный идентификатор»

Байт:

1

Контрольный байт = 131, Не может ответить (PGN поддерживается, но СА занят и не может ответить сейчас. Повторный запрос данных позднее)

Байт:

2

Значение групповой функции = Расширенному идентификатору

Байт:

от 3 до 4

Зарезервировано для назначения в будущем стандарте; отправить каждый из этих байтов как FF16

Байт:

5

Адрес занят

Байт:

от 6 до 8

PGN запрашиваемой информации (см. выше)

Положительное подтверждение: контрольный байт = 144 и Расширенный тип идентификатора «Двубайтовый расширенный идентификатор»

Байт:

1

Контрольный байт = 144, Положительное подтверждение (АСК)

Байт:

2

Значение групповой функции = Расширенному идентификатору (8 LSB расширенного идентификатора, бит 8 MSB)

Байт:

3

Значение групповой функции = Расширенному идентификатору (8 MSB расширенного идентификатора, бит 8 MSB)

Байт:

4

Зарезервировано для назначения в будущем стандарте; отправить каждый из этих байтов как FF16

Байт:

5

Адрес подтвержден

Байт:

от 6 до 8

PGN запрашиваемой информации (см. выше)

Отрицательное подтверждение: контрольный байт = 145 и Расширенный тип идентификатора Двухбайтовый Расширенный Идентификатор»

Байт:

1

Контрольный байт = 145, Отрицательное подтверждение (NACK)

Байт:

2

Значение групповой функции = Расширенному идентификатору (8 LSB расширенного идентификатора, бит 8 MSB)

Байт

3

Значение групповой функции = Расширенному идентификатору (8 MSB расширенного идентификатора, бит 8 MSB)

Байт:

4

Зарезервировано для назначения в будущем стандарте; отправить каждый из этих байтов как FF16

Байт:

5

Адрес отрицательно подтвержден

Байт:

от 6 до 8

PGN запрашиваемой информации (см. выше)

Доступ запрещен: контрольный байт = 146 и Расширенный тип идентификатора «Двухбайтовый расширенный идентификатор»

Байт:

1

Контрольный байт = 146, Доступ запрещен (PGN поддерживается, но доступ к безопасному режиму запрещен)

Байт:

2

Значение групповой функции = Расширенному идентификатору (8 LSB расширенного идентификатора, бит 8 MSB)

Байт:

3

Значение групповой функции = Расширенному идентификатору (8 MSB расширенного идентификатора, бит 8 MSB)

Байт:

4

Зарезервировано для назначения в будущем стандарте; отправить каждый из этих байтов как FF16

Байт:

5

Доступ к адресу запрещен

Байт:

от 6 до 8

PGN запрашиваемой информации (см. выше)

Не может ответить: контрольный байт = 147 Расширенный тип идентификатора «Двухбайтовый расширенный идентификатор»

Байт:

1

Контрольный байт = 147, Не может ответить (PGN поддерживается, но СА занят и не может ответить сейчас. Повторный запрос данных в более позднее время)

Байт:

2

Значение групповой функции = Расширенному идентификатору (8 LSB расширенного идентификатора, бит 8 MSB)

Байт:

3

Значение групповой функции = Расширенному идентификатору (8 MSB расширенного идентификатора, бит 8 MSB)

Байт:

4

Зарезервировано для назначения в будущем стандарте; отправить каждый из этих байтов как FF16

Байт:

5

Адрес занят

Байт:

от 6 до 8

PGN запрашиваемой информации (см. выше)

Положительное подтверждение: контрольный байт = 160 и Расширенный тип идентификатора

«Трехбайтовый расширенный идентификатор»

Байт:

1

Контрольный байт = 160, Положительное подтверждение (АСК)

Байт:

2

Значение групповой функции = Расширенный идентификатор (8 LSB расширенного идентификатора, бит 8 MSB)

Байт:

3

Значение групповой функции = Расширенному идентификатору (второй байт расширенного идентификатора, бит 8 MSB)

Байт:

4

Значение групповой функции = Расширенному идентификатору (8 MSB расширенного идентификатора, бит 8 MSB)

Байт:

5

Адрес подтвержден

Байт:

от 6 до 8

PGN запрашиваемой информации (см. выше)

Отрицательное подтверждение: контрольный байт = 161 и Расширенный тип идентификатора

«Трехбайтовый расширенный идентификатор»

Байт:

1

Контрольный байт =161, Отрицательное подтверждение (NACK)

Байт:

2

Значение групповой функции = Расширенному идентификатору (8 LSB расширенного идентификатора, бит 8 MSB)

Байт:

3

Значение групповой функции = Расширенному идентификатору (второй байт расширенного идентификатора, бит 8 MSB)

Байт:

4

Значение групповой функции = Расширенному идентификатору (8 MSB расширенного идентификатора, бит 8 MSB)

Байт:

5

Адрес отрицательно подтвержден

Байт:

от 6 до 8

PGN запрашиваемой информации (см. выше)

Доступ запрещен: контрольный байт = 162 и Расширенный тип идентификатора «Трехбайтовый

расширенный идентификатор»

Байт:

1

Контрольный байт = 162, Доступ запрещен (PGN поддерживается, но доступ к безопасному режиму запрещен)

Байт:

2

Значение групповой функции = Расширенному идентификатору (8 LSB расширенного идентификатора, бит 8 MSB)

Байт:

3

Значение групповой функции = Расширенному идентификатору (второй байт расширенного идентификатора, бит 8 MSB)

Байт:

4

Значение групповой функции = Расширенному идентификатору (8 MSB расширенного идентификатора, бит 8 MSB)

Байт:

5

Доступ к адресу запрещен

Байт:

от 6 до 8

PGN запрашиваемой информации (см. выше)

Не может ответить: контрольный байт = 163 и Расширенный тип идентификатора «Трехбайтовый расширенный идентификатор»

Байт:

1

Контрольный байт = 163, Не может ответить (PGN поддерживается, но СА занят и не может ответить сейчас. Повторный запрос данных в более позднее время)

Байт:

2

Значение групповой функции = Расширенному идентификатору (8 LSB расширенного идентификатора, бит 8 MSB)

Байт:

3

Значение групповой функции = Расширенному идентификатору (второй байт расширенного идентификатора, бит 8 MSB)

Байт:

4

Значение групповой функции = Расширенному идентификатору (8 MSB расширенного идентификатора, бит 8 MSB)

Байт:

5

Адрес занят

Байт:

от 6 до 8

PGN запрашиваемой информации (см. выше)

  • 5.4.6 Групповая функция

    • 5.4.6.1 Общие положения

Тип сообщения групповой функции используется для групп функций. Собственные функции, многопакетные транспортные функции и функции сетевого управления (ИСО 11783-5) Виртуальные терминалы (ИСО 11783-6), контроллеры задач (ИСО 11783-10), файловые серверы (ИСО 11783-13) и контроллеры последовательности (ИСО 11783-14) используют сообщения групповой функции.

Каждая группа функций распознается по присвоенному ей PGN. Сама функция определяется в структуре данных (обычно первый байт поля данных). Более подробное объяснение проприетарного и транспортного протокола групповой функции приведено в 5.4.6.2—5.4.6.4. Функция проприетарной группы предоставляет средство передачи проприетарных сообщений таким образом, чтобы исключить конфликты использования идентификаторов CAN между различными производителями. Он также предоставляет средства для получения и различения проприетарных сообщений для использования, когда это необходимо. Групповые функции могут предоставлять свои собственные механизмы запроса, АСК и/или NACK, если сообщений, определенных в этом документе, недостаточно.

Запрос с использованием PGN 59 904 (см. 5.4.3) может быть использован для определения того, поддерживается ли определенная группа параметров типа сообщения групповой функции. Если поддерживается, то принимающая управляющая функция отправляет подтверждение PGN с управляющим байтом, равным нулю, для положительного подтверждения, или равным двум для отказа в доступе, или равным 3 для «не может ответить». Если он не поддерживается, то принимающая управляющая функция отправляет подтверждение PGN с управляющим байтом, установленным на единицу, для отрицательного подтверждения. Остальные части указанной в стандарте ИСО 11783 группы PF и параметров должны быть заполнены надлежащим образом (см. пункт 5.4.5).

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

Длина данных проприетарных сообщений А, А2 и В может быть установлена каждым производителем. Поэтому два производителя могут использовать одно и то же значение GE, и оно может иметь разный код длины данных. Для получения контрольных функций этой информации необходимо различать двух производителей. То, как используется поле данных этого сообщения, находится на усмотрении производителя, как и использование проприетарных сообщений. Использование проприетарных сообщений во время нормальной работы должно быть сведено к минимуму, где сумма проприетарных А, А2 и В на CF не должна превышать 2 % емкости сети (см. приложение D).

5.4.6.2 Проприетарный А

Имя группы параметров:

ПРОПРИЕТАРНЫЙ А

Определение:

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

Частота повторений передач:

согласно требованиям пользователя

Длина данных:

от 0 до 1 785 байт (поддерживаются несколько пакетов)

Страница данных:

0

PF:

239

PS:

DA

Приоритет по умолчанию:

6

Номер группы параметров:

61 184 (00EF0016)

Байты: от 1 до 8

конкретное для производителя использование (см. 5.1.3)

Диапазоны данных для параметров, используемых этой групповой функцией: не определены ИСО.

  • 5.4.6.3 Проприетарный А2

    Имя группы параметров:

    ПРОПРИЕТАРНЫЙ А2

    Определение:

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

    Частота повторений передач:

    согласно требованиям пользователей

    Длина данных:

    от 0 до 1 785 byte (поддерживаются несколько пакетов)

    Страница данных:

    1

    PF:

    239

    PS:

    DA

    Приоритет по умолчанию:

    6

    Номер группы параметров:

    126 720 (01EF0016)

    Байты: от 1 до 8

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

Диапазоны данных для параметров, используемых этой групповой функцией: не определены ИСО.

  • 5.4.6.4 Проприетарный В

    Имя группы параметров:

    ПРОПРИЕТАРНЫЙ В

    Определение:

    Проприетарный PG, который использует сообщение формата PDU2, чтобы позволить производителям определять содержимое поля PS (GE) по своему усмотрению.

    Частота повторений передач:

    согласно требованиям пользователей

    Длина данных:

    от 0 до 1 785 байт (поддерживается несколько пакетов)

    Страница данных:

    0

    PF:

    255

    PS:

    GE (назначенный производителем)

    Приоритет по умолчанию:

    6

    Номер группы параметров:

    65 280 до 65 535 (от 00FF0016 до 00FFFF16)

    Байты: от 1 до 8

    22

    использование определено производителем (см. 5.1.3)

Диапазоны данных для параметров, используемых этой групповой функцией: Результаты использования, определенные производителем, с кодом длины данных, уникальным для каждого поставщика компонента и адреса источника. Следует соблюдать осторожность при использовании группы параметров проприетарный В (PGN = 65 280), поскольку несколько адресов источников могут использовать одно и то же значение PGN проприетарный В для разных целей.

  • 5.4.7 Request2

Request2 PG имеет дополнительную возможность указать, использует ли принимающая управляющая функция передачу PGN 51 712. Указывая, что принимающая управляющая функция использует передаточный PGN, она обеспечивает возможность для принимающей управляющей функции сообщать набор данных для всех управляющих функций, которые ей поручено сообщать (см. 5.4.8), включая тот, который принимающая управляющая функция обычно сообщала бы при получении того же PGN, запрошенного в PGN 59 904 (правильно отформатированном для передачи PGN), и набор данных для каждой управляющей функции, которую ей поручено сообщать. Например, если параметр Использовать передачу PGN равен yes (012), то ответ должен включать все известные данные относительно запрошенного PGN. Когда Использовать передачу PGN равен 002, эффект Request2 PGN такой же, как если бы был использован запрос PGN (59 904). Ответ на Request2, когда Use Transfer PGN равен 002, не отправляется с помощью передачи PGN, а отправляется точно так же, как если бы запрос был сделан с помощью запроса PGN (т. е. PGN 59 904). Приведенная ниже информация присваивает PGN группе параметров Request2.

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

Пример — Идентификационная информация ECU, идентификатор компонента и идентификация программного обеспечения PGN. См. также пример 5.4.8. Если управляющей функции не удается получить ответ (либо PGN, либо ACKNOWLEDGMENT) на запрос в течение времени ожидания ответа, то управляющая функция может повторно отправить или повторить тот же запрос. Количество повторных попыток для конкретного запроса должно быть ограничено двумя (2) повторными попытками, то есть запрос выдается в общей сложности три (3) раза. Если управляющей функции не удается получить ответ (либо PGN, либо ACKNOWLEDGMENT) на запрос после второй попытки, то управляющая функция должна отказаться от дальнейших попыток запроса той же информации или управляющая функция может ожидать в течение продолжительного периода времени (минут, а не секунд), прежде чем пытаться запросить туже информацию.

Поддержка REQUEST2 не является обязательной.

Имя группы параметров:

REQUEST2

Определение:

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

Частота повторений передач:

В соответствии с требованиями пользователя, как правило, рекомендуется, чтобы запросы возникали не более 2 или 3 раз в секунду. Когда управляющая функция поддерживает Request2, NACK требуется, если не запрашивается PG с запрашиваемым адресом, см. PGN 59 392.

Длина данных:

8 байт (поддерживается несколько пакетов)

Страница данных:

0

PF:

201

PS:

конкретный адрес назначения (глобальный или конкретный)

Приоритет по умолчанию:

6

Номер группы параметров:

51 456 (00С90016)

Байты от 1 до 3:

Запрашиваемый PGN

Байт 4:

Специальные инструкции

Биты от 6 до 8:

Зарезервировано для назначения в будущем стандарте

Биты от 3 до 5:

Элемент управления, указывающий тип расширенного идентификатора (расширенный идентификатор, передаваемый в байтах данных с 5 по 7)

Биты от 1 до 2:

Используйте Transfer PGN для ответа (002 = нет, 012 = да, 102 = не определено, 112 = не разрешено)

Байт 5:

Байт расширенного идентификатора 1 (наименее значимый байт)

Байт 6:

Байт расширенного идентификатора 2

Байт 7:

Байт расширенного идентификатора 3 (наиболее значимый байт)

Байт 8:

Зарезервировано для назначения в будущем стандарте

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

0002 — Нет расширенного идентификатора. Ни один из байтов данных не используется для

значений идентификатора/управления. Используется при запросе PGN, который не имеет байтов групповой функции/расширенного идентификатора. Индикатор того, что устройство поддерживает новую специальную инструкцию Request2. Байты данных с 5 по 7 PGN запроса 2 установлены на 255 (FF16).

0012 — Однобайтовый расширенный идентификатор. Байт 5 данных PGN Request2 содер

жит однобайтовый идентификатор/управляющее значение, которое соответствует байту данных запрошенного PGN 1. Байты данных 6-7 PGN Request2 установлены на 255 (FF16).

0102 — Двухбайтовый расширенный идентификатор. Байт данных 5 PGN-запроса Request2

содержит идентификатор байта/контрольное значение, которое будет соответствовать байту 1 данных запрашиваемого PGN, а байт 6 данных PGN Request2 содержит идентификатор/контрольное значение, которое соответствует байту данных запрашиваемого PGN 2. Байт данных 7 Запроса 2 PGN установлен на 255 (FF16).

0112 — Трехбайтовый расширенный идентификатор. Сведения байт 5 из Request2 PGN со

держит идентификатор байта/контрольное значение, которое будет соответствовать запрошенному PGN байта 1, байт 6 из Request2 PGN содержит идентификатор/контрольное значение, которое соответствует запрашиваемому PGN данных байта 2, и байт данных 7 Request2 PGN содержит идентификатор/управляющее значение, которое соответствует запрошенному PGN байту данных 3.

от 1002 до 1102 — Зарезервировано для назначения в будущем стандарте 1112 — Не выполняются никакие действия. Не применяется.

  • 5.4.8 Передача

Передача PGN предоставляет механизм для сообщения множества наборов данных для данного PGN в ответ на Request2 (см. 5.4.7). Эти множественные наборы данных для данного PGN требуют, чтобы каждый набор данных имел длину и был помечен четырьмя байтами из ИМЕНИ ИСО 11783-5. Четыре байта ИМЕНИ определяют каждую PGN запрашиваемой информации (второй байт номера группы параметров, бит 8 MSB). Управляющая функция, отвечающая на запрос, должна сообщать ту же информацию, что и с PGN 59 904, как первый набор данных в этом ответе. Если управляющая функция имеет только один набор данных, то она должна ответить одним набором данных, использующим передачу PG.

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

Имя группы параметров:

Определение:


Transfer

Используется для передачи данных в ответ на Request2, когда для параметра «Использовать передачу PGN для ответа» установлено значение «Да».

Частота повторяющихся передач: в ответ на Request2 PGN с «Использовать передачу PGN» = 01 Длина данных: от 9 до 1 785 байт (поддерживается несколько пакетов)

Страница данных:

PF:

PS: DA (конкретный или глобальный)

Приоритет по умолчанию:

Номер группы параметров: 51 712 (00СА0016)

Байты от 1 до 3: a) PGN, запрошенный Request2 (см. таблицу 2 для заказа PGN)

Байт 4: Ь) Длина данных для сообщенного PGN, связанного с идентифи

цированной управляющей функцией (например, управляющая функция в байтах с 5 по 8). Значение длины представляет собой сумму этого байта, длины байтов идентификатора (то есть байтов с 5 по 8) и связанных данных PGN. Таким образом, длина составляет b + с + d.

Байты от 5 до 8:

с) Идентичность функции управления, связанной с PGN и данны ми (то есть идентичность функции управления)

Байт 5: Биты от 4 до 8

Экземпляр функции (наиболее значимый бит 8)

Биты от 1 до 3

Экземпляр ECU (наиболее значимый бит 3)

Байт 6: Биты от 1 до 8

Функция (наиболее значимый бит 8)

Байт 7: Биты от 2 до 8

Класс устройства (наиболее значимый бит 8)

Бит 1

Зарезервировано

Байт 8: Бит 8

Самостоятельно настраиваемый

Биты от 5 до 7

Промышленная группа (наиболее значимый бит 7)

Биты от 1 до 4

Экземпляр класса устройства (MSB Бит 4)

Байты от 9 до х: d) Повторяющаяся информация для 2-го и последующих пунктов

должна содержать: «Идентификатор функции управления», «Длина» и «PGN, запрошенный данными Request2» (см. Определения формата ниже.)

Формат a, b, с, d, b, с, d, b, с, d ...:

a PGN, запрошенный Запросом2, когда режим передачи установлен в положение «Да»;

b первый набор данных — длина идентификатора каскадной управляющей функции и связанных данных PGN (длина = b + с + d);

с идентичность управляющей функции, с которой связано поле d;

d запрошенные данные PGN для конкретной управляющей функции;

b второй набор данных — длина идентификатора каскадной управляющей функции и связанных данных PGN;

с идентичность управляющей функции, с которой связано поле d;

d запрошенные данные PGN для второй конкретной управляющей функции.

Пример — Для данного транспортного средства управляющая функция двигателем знает номера VIN для трактора и прицепа. Другая управляющая функция отправляет Request2, направленный в глобальный адрес назначения, запрашивая VIN с «Использовать Transfer PGN», установленным в 012. Ответ от двигателя может быть следующим:

  • - ВАМ передача Transfer PGN, сообщающего VIN трактора и VIN прицепа, или

  • - если запрос имел значение «Использовать Transfer PGN», равное 002, то ответом была передача ВАМ VIN трактора, но не использование передачи PGN.

  • 5.5 Приоритет сообщения

Приоритет кадра данных CAN должен соответствовать ИСО 11898-1. Значение в поле идентификатора CAN определяет приоритет сообщения. Низкое значение (29-битный идентификатор, установленный на все нули) является наивысшим приоритетом, а наибольший идентификатор CAN — наименьшим приоритетом (29-битный идентификатор, установленный на все единицы). Назначения идентифицируются на прикладном уровне в соответствии с рекомендациями, приведенными в 5.9.

  • 5.6 Доступ к шине

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

  • 5.7 Арбитраж на основе разногласий

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

  • 5.8 Выявление ошибок

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

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

  • - разрядный циклический контроль избыточности (CRC);

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

  • - проверка формата кадра.

Примечание — Для более подробного объяснения этих методов обнаружения ошибок см. ИСО 11898-1.

  • 5.9 Процесс назначения для SA и PGN

    5.9.1 Общие положения

    Доступные протокольные блоки данных обеспечивают два формата: PDU1 и PDLI2. Группы параметров назначаются специально для использования в формате PDU1 или PDLI2. Как только формат назначен, другой формат недоступен для этой группы параметров. Формат PDU1 должен использоваться всякий раз, когда необходимо направить группу параметров в конкретное место назначения. Назначение группы параметров должно выполняться с использованием следующих характеристик:

  • - приоритет;

  • - частота обновления;

  • - важность данных в пакете для других управляющих функций в сети;

  • - длина данных, связанных с группой параметров.

Чтобы помочь с этим процессом назначения, форма запроса доступна для использования при запросе новых назначений SA или PGN.

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

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

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

PGN линейно распределяются по различным разделам таблицы 7 на основе критериев, приведенных в форме запроса PGN и SA. Обратите внимание, что многопакетные сообщения не допускаются, если частота повторения превышает или равна 10 Гц.

  • 5.9.2 Критерии назначения адреса

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

Контроллеры ИСО 11783 должны поддерживать самонастраивающийся адрес в соответствии с ИСО 11783-5.

  • 5.9.3 Критерии назначения группы параметров

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

  • - Формат PDLI1 (PS = DA, разрешение связи с конкретным адресом назначения);

  • - Формат PDU2 (PS = GE);

  • - проприетарная коммуникация, использующая два стандартных проприетарных PGN.

Каждый из этих методов имеет соответствующее применение. Группы параметров, с конкретным адресом назначения, необходимы там, где одно и то же сообщение может быть направлено в тот или иной адрес назначения. В стандарте ИСО 11783 определено сообщение управления крутящим моментом, которое может быть отправлено двигателю. В случае более чем одного двигателя это сообщение должно быть отправлено только нужному двигателю, а конкретная группа параметров назначения требуется и назначается.

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

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

  • а) конкретный источник может отправить свое проприетарное сообщение в формате PDU2 (не зависящем от назначения) с полем PS, идентифицированным по желанию пользователя;

  • Ь) использование формата PDU1 (с конкретным адресом назначения) позволяет учитывать ситуации, когда диагностический инструмент направляет свои запросы к определенному месту назначения из возможной группы контроллеров.

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

Проприетарные сообщения полезны в двух ситуациях:

  • - когда это не нужно для стандартизированных коммуникаций;

  • - когда важно передавать конфиденциальную информацию.

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

Когда предполагается назначение группы параметров, следует рассмотреть проприетарные и РО112-форматные методы связи. Если передается несвободная информация или если информация, подлежащая передаче, не представляет общего интереса, следует использовать несвободный метод. Если информация представляет общий интерес и не требует направления сообщения на конкретную управляющую функцию, следует искать назначение формата PDU2. Наконец, если информация представляет общий интерес, но требует направления на ту или иную управляющую функцию, то необходима адресация для конкретного назначения и следует искать назначение группы параметров формата PDU1 назначения.

  • 5.9.4 Определение поля данных

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

Таблица 7 — шаблон PGN ИСО 11783

Определения

EDP = Расширенная страница данных

(1 бит)

DP = Страница данных

(1 бит)

GE = Расширение группы

(8 битов)

PF = Формат PDU

(8 битов)

Р = Приоритет

(1 бит)

PS = Специальное поле PDU

(8 битов)

NA = Не допускается

DA = Адрес назначения

(8 битов)

un = Не определено

PGN = Номер группы параметров

(3 байта)

EDP DP PF PS Определение группы параметров Многопакетное PGN

0 0 0 DA Формат PDU1 -100 мс или менее NA ООО

0 0 1 DA . 256

I раница х 1

0 0 238 DA Формат PDU1 - свыше 100 мс Допускается 60928

0 0 239 DA Формат PDU1 - Проприетарный А Допускается 61184

0 0 240 0 Формат PDU2 -100 мс или менее NA 61440

0 0 240 1 I 61441

Iраница у I

0 0 254 254 J 65278

0 0 254 255 Формат PDU2 - свыше 100 мс Допускается 65279

0 0 255 un Формат PDU2 - Проприетарный В Допускается 65280-65535

0 1 0 DA Формат PDU1 -100 мс или менее NA 65536

0 1 1 DA | 65792

1 раница х1 |

0 1 238 DA Формат PDU1 - свыше 100 мс Допускается 126464

0 1 239 DA Формат PDLI1 - Проприетарный А2 Допускается 126720

0 1 240 0 Формат PDU2 -100 мс или менее NA 126976

0 1 240 1

126977

Граница у1 ‘

0 1 254 254

0 1 254 255 Формат PDU2

0 1 255 un Формат PDU2 -

130814

-свыше 100 мс Допускается 130815

Проприетарный В Допускается 130816-

131071

  • 5.10 Функции транспортного протокола

    5.10.1 Общие положения

    Функции транспортного протокола описываются как часть уровня канала передачи данных с признанием того, что функциональность транспортного протокола подразделяется на две основные функции: «пакетирование» сообщений и повторная сборка, а также управление соединениями. Они описаны в пунктах 5.10.2—5.11.6, в которых термин отправляющая управляющая функция соответствует управляющей функции, передающей запрос на отправку сообщения, а принимающая управляющая функция соответствует управляющей функции, передающей сообщение о разрешении отправки.

Существует два вида функций транспортного протокола. Для сообщений длиной более 8 байт и длиной до 1 785 байт используются функции транспортного протокола. Если длина сообщения превышает 1785 байт, тогда необходимы расширенные функции транспортного протокола. Функции транспортного протокола гармонизированы с SAE, а расширенные функции транспортного протокола — нет (см. 5.11).

  • 5.10.2 «Пакетирование» и повторная сборка

    • 5.10.2.1 Общие положения

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

  • 5.10.2.2 Пакеты сообщений

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

Отдельным пакетам сообщений присваивается порядковый номер от 1 до 255. Это дает максимальный размер сообщения 255 пакетов х 7 байт / пакет = 1 785 байт при использовании транспортного протокола.

  • 5.10.2.3 Порядковый номер

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

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

  • 5.10.2.4 «Пакетирование»

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

Для целей этого протокола большое сообщение считается группой параметров со строкой из девяти или более байтов. Первый пакет передачи данных содержит порядковый номер один и первые семь байтов строки. Вторые семь байтов помещаются в другой кадр данных вместе с порядковым номером 2, третий — с порядковым номером 3 и т. д. до тех пор, пока все байты отправляемого сообщения не будут помещены в указанные классические кадры данных CAN, определенные в стандарте ИСО 11783, и переданы.

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

Время между пакетами для транслируемых многопакетных сообщений должно составлять от 10 мс до 200 мс (см. 5.13.3). Для многопакетных сообщений, направленных в конкретный адрес назначения, управляющая функция передачей поддерживает максимальное время между пакетами (где CTS допускает более одного) 200 мс без минимальных временных требований. В принимающей управляющей функции должны знать, что все пакеты, содержащие данные, имеют одинаковый идентификатор.

  • 5.10.2.5 Повторная сборка

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

  • 5.10.3 Транспортный протокол — Управление соединением

    • 5.10.3.1 Общие положения

Управление соединениями связано с открытием, использованием и закрытием виртуальных соединений между управляющими функциями для передачи по назначению. Виртуальное соединение в среде, определенной в стандарте ИСО 11783, считается временной ассоциацией двух управляющих функций с целью передачи одного большого сообщения, которое описывается одним PGN (см. рисунки В.1 и В.2). В случаях, когда соединение между одним и несколькими, управление потоком или замыкание не предусмотрено (см. рисунок В.З).

  • 5.10.3.2 Многопакетная трансляция

Многопакетные сообщения могут быть не специфичными для адреса назначения, то есть они могут быть транслируемыми сообщениями. Для трансляции многопакетного сообщения управляющая функция сначала передает сообщение транслируемого оповещения (ВАМ). Это сообщение, которое должно быть передано по глобальному адресу назначения, представляет собой большое сообщение с предупреждением для управляющих функций в сети. Сообщение ВАМ содержит PGN большого сообщения, подлежащего транслируемой передаче, его размер и количество пакетов, в которые оно было упаковано. Управляющие функции, заинтересованные в транслируемых данных, затем должны распределять ресурсы, необходимые для приема и повторной сборки сообщения. PGN передачи данных (PGN = 60 160) затем используется для отправки связанных данных.

  • 5.10.3.3 Инициирование соединения

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

После получения сообщения «Запрос на отправку» контрольная функция может принять или отклонить соединение. Для подтверждения соединения функция контроля приема передает сообщение о разрешении отправки. Сообщение о разрешении отправки содержит количество пакетов сообщений, которые оно может принять, и порядковый номер первого ожидаемого пакета. Функция контроля приема должна гарантировать, что у нее достаточно ресурсов для обработки количества пакетов, которые она принимает к доставке. Порядковый номер пакета, в случае только что открытого соединения, равен 1.

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

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

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

  • 5.10.3.4 Передача данных

    • 5.10.3.4.1 Общие положения

Передача данных начинается после того, как отправляющая управляющая соединением функция получает сообщение о разрешении отправки. Исключением является случай, когда передача данных была результатом ВАМ — в этом случае сообщение о разрешении отправки не используется. Пакет передачи данных использует PGN передачи данных (см. 5.10.5), но байты данных, содержащиеся в этом пакете, применяются к PGN, объявленному в байтах с 6 по 8 сообщения запроса на передачу или сообщения транслируемой передачи. Первый байт поля данных содержит порядковый номер пакета.

  • 5.10.3.4.2 Управление потоком соединения

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

сообщение о разрешении отправки, установив число отправляемых пакетов равным нулю. В случае, когда поток должен быть остановлен на некоторое количество секунд, управляющая функция приемом должна повторять передачу сообщения о разрешении отправки один раз в Th с (0,5 с), чтобы обеспечить отправляющую управляющую функцию. Связь не разорвана. Все оставшиеся битовые поля установлены в одно («Не имеет значения»).

  • 5.10.3.5 Закрытие соединения

При отсутствии ошибок существуют два случая закрытия соединения: первый для глобального назначения и второй для конкретного назначения. В случае глобального адреса назначения никакая операция закрытия соединения не выполняется после приема самих данных (см. 5.10.4.1 и 5.10.4.5). В случае передачи по конкретному назначению и после получения последнего пакета в потоке сообщений управляющая функция приемом передает подтверждение окончания сообщения отправляющей управляющей функции сообщения. Это сигнал отправляющей управляющей функции о том, что соединение считается закрытым с помощью принимающей управляющей функции. Закрытие АСК в конце сообщения требуется для освобождения соединения для последующего использования другими управляющими функциями.

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

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

Пример 1 — Задержка получения последнего пакета более чем на Т1 с, когда ожидалось больше (CTS разрешил больше).

Пример 2 — Задержка более чем Т2 с после передачи CTS (сбой отправляющей управляющей функции).

ПримерЗ— Отсутствие CTS или АСК в течение более чем ТЗ с после передачи последнего пакета (сбой принимающей управляющей функции).

Пример 4 — Отсутствие CTS в течение более Т4 с после сообщения CTS (0) о том, что необходимо «держать соединение открытым».

Любой из этих примеров приводит к закрытию соединения.

Значения времени ожидания: Тг = 200 мс, Th = 500 мс, Т1 = 750 мс, Т2 = 1 250 мс, Т3 = 1 250 мс и Т4 = 1 050 мс (см. также 5.13.3 и рисунок В.1 относительно времени ожидания). Когда либо отправляющая управляющая функция, либо принимающая управляющая функция решает закрыть соединение по любой причине, включая время ожидания, она должна отправить сообщение о прерывании соединения с причиной прерывания 3 из таблицы 8.

С определениями в этом подпункте и определениями, приведенными в 5.10, можно сделать следующие наблюдения.

  • а) Закрытие соединения для сообщения транслируемого объявления включает в себя следующее. Соединение считается закрытым,

  • 1) когда отправляющая управляющая функция отправляет последний пакет передачи данных;

  • 2) при получении управляющей функции:

  • i) получает последний пакет передачи данных или

  • ii) истекло время ожидания соединения Т1.

  • Ь) Закрытие соединения для сообщений «Запрос на отправку»/«Разрешение отправки» включает следующее. Соединение считается закрытым,

  • 1) когда отправляющая управляющая функция:

  • i) получает TP.CM_EndOfMsgACK по завершении передачи данных для всего PGN;

  • ii) отправляет прерывание соединения по любой причине (например, из-за превышения времени ожидания ТЗ или Т4) или

  • iii) получает разрыв соединения;

  • 2) при получении управляющей функции:

  • i) отправляет TP.CM_EndOfMsgACK по завершении передачи данных для всего PGN;

  • ii) получает разрыв соединения или

  • iii) отправляет прерывание соединения по любой причине (включая раннюю остановку сеанса, если это необходимо, для времени ожидания соединения Т1 или Т2 и т. д.).

  • 5.10.4 Транспортный протокол — Сообщения управления соединением (ТР.СМ)

    • 5.10.4.1 Определение сообщения управления соединением транспортного протокола

Этот тип сообщения используется для инициирования и закрытия соединений, а также для управления потоком. Транспортный протокол предоставляет следующие пять сообщений управления соединением транспортного протокола: запрос режима соединения для отправки, сброс режима соединения для отправки, подтверждение окончания сообщения, прерывание соединения и сообщение о транслируемой рассылке. Формат этого сообщения показан ниже в определении группы параметров для транспортного протокола — Управление соединениями.

Имя группы параметров:

ТРАНСПОРТНЫЙ ПРОТОКОЛ — УПРАВЛЕНИЕ СОЕДИНЕНИЕМ (ТР.СМ)

Определение:

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

Частота повторяющихся передач:

в соответствии с PGN, подлежащим передаче

Длина данных:

8 байт

Страница данных:

0

PF:

236

PS:

DA

Приоритет по умолчанию:

7

Номер группы параметров:

60 416 (00ЕС0016)

Диапазон данных, пользующихся этой групповой функцией:

Контрольный байт:

от 0 до 15, 18, от 20 до 31, от 33 до 254 зарезервировано для присвоения в будущем стандарте

Общий размер сообщения, байт:

от 9 до 1 785 (2 байта), от 0 до 8 и от 1 786 до 65 535 не допускаются

Общее количество пакетов:

от 2 до 255 (1 байт), ноль и 1 не допускаются

Максимальное количество пакетов:

от 2 до 255 (1 байт), ноль и 1 не допускаются

Число пакетов, которые могут быть отправлены:

от 0 или 1 до 255 (1 байт)

Следующий номер пакета, который будет отправлен:

от 1 до 255 (1 байт), ноль не допускается

Порядковый номер:

от 1 до 255 (1 байт), ноль не допускается

Примечание — ноль в графе «количество пакетов, которые могут быть отправлены» означает приостановку соединения (см. 5.10.3.4.1).

Запрос на отправку режима соединения (TP. CM_RTS): конкретный адрес назначения

Байт:

1 Контрольный байт =16, специфичный для назначения Request То Send

(RTS)

Байты:

от 2 до 3 Общий размер сообщения, количество байт

Байт:

4 Общее число пакетов

Байт:

5

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

Байт:

6

PGN запрашиваемой информации (8 наименее значимый байт параметра номер группы, Бит 8 бит)

Байт:

7

PGN запрашиваемой информации (второй байт номера группы параметров, бит 8 MSB)

Байт:

8

PGN запрашиваемой информации (8 MSB номера группы параметров, Бит 8 MSB)

Режим соединения разрешения отправки (TP. CM_CTS): конкретный адрес назначения

Байт:

1

Контрольный байт =17, разрешение отправки для конкретного адреса назначения (CTS)

Байт:

2

Количество пакетов, которые могут быть отправлены. Это значение не должно превышать меньшее из двух значений в Байте 4 и Байте 5 сообщения RTS

Байт:

3

Следующий номер пакета для отправки

Байты:

от 4 до 5

Зарезервированные для присвоения в будущем стандарте, эти байты должны быть отправлены как FF16

Байты:

от 6 до 8

PGN пакетного сообщения

Подтверждение конца сообщения (TP.CM_EndofMsgACK): конкретный адрес назначения

Байт:

1

Контрольный байт = 19, подтверждение конца сообщения

Байты:

от 2 до 3

Общий размер сообщения, число байтов

Байт:

4

Общее число пакетов

Байт:

5

Зарезервированные для присвоения в будущем стандарте, эти байты должны быть отправлены как FF16

Байты:

от 6 до 8

PGN пакетного сообщения

Разрыв соединения

(TP.Conn_Abort): конкретный адрес назначения

Байт:

1

Контрольный байт = 255, Разрыв соединения

Байт:

2

Причина разрыва соединения

Байты:

от 3 до 5

Зарезервированные для присвоения в будущем стандарте, эти байты должны быть отправлены как FF16

Байты:

от 6 до 8

PGN пакетного сообщения

Трансляция сообщения (TPCMJBAM): глобальный адрес назначения

Байт:

1

Контрольный байт = 32, Трансляция сообщения

Байты:

от 2 до 3

Общий размер сообщения, число байтов

Байт:

4

Общее число пакетов

Байт:

5

Зарезервированные для присвоения в будущем стандарте, эти байты должны быть отправлены как FF16

Байты:

от 6 до 8

PGN пакетного сообщения

  • 5.10.4.2 Транспортный протокол Режим Соединения Запрос На Отправку (TP. CM_RTS)

Сообщение TP.CM_RTS сообщает управляющей функции, что другая управляющая функция в сети желает открыть с ней виртуальное соединение. TP.CM_RTS — это сообщение с полем SA, установленным для отправляющей управляющей функции, DA, установленным для предполагаемой управляющей функции получением большого сообщения, и остальными полями, установленными соответствующим образом для отправляемого PGN. Байт 5 этого сообщения позволяет отправляющей управляющей функции ограничить количество пакетов, указанных в сообщении о разрешении отправки (см. рисунки В. 4 и В. 5) принимающей управляющей функции. Когда принимающая управляющая функция соответствует этому пределу, она гарантирует, что отправляющая управляющая функция всегда может ретранслировать пакеты, которые по какой-либо причине принимающая управляющая функция не получила. Если несколько РТС получены от одного и того же ВАдля одного и того же PGN, то следует действовать по самому последнему РТС и отказаться от предыдущего РТС. В этом конкретном случае сообщение об отмене не должно быть отправлено для оставленного RTS. TP.CM_RTS передается только отправляющей управляющей функцией.

  • 5.10.4.3 Транспортный протокол Режим Соединения Разрешение Отправки (TP.CM_CTS)

Сообщение TP.CM_CTS используется для ответа на сообщение о запросе на отправку. Он сообщает функции однорангового управления, что она готова для определенного количества больших данных сообщения. Объем данных большого сообщения, очищенных для отправки, должен быть не больше меньшего из двух значений в байте 4 и байте 5 отправляющей управляющей функции сообщением TP.CM_RTS. Если после установления соединения получено несколько CTS, то соединение должно быть прервано. Когда отправляющая управляющая функция прерывает соединение, она должна отправить сообщение о прерывании соединения с причиной прерывания 4 из таблицы 8. Принимающая управляющая функция не должна посылать следующий CTS до тех пор, пока она не получит последний пакет данных от предыдущего CTS или не истечет время ожидания. В случае времени ожидания управляющая функция приемом имеет выбор, отправлять ли прерывание соединения или отправлять CTS. Существуют следующие случаи, когда передача данных происходит с ошибками:

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

  • - Пропущенный пакет(ы), включая последний пакет, приводит к превышению времени ожидания Т1. В этом случае принимающая управляющая функция принимает решение либо отправить CTS, либо прервать соединение по причине 4 из таблицы 8. См. рисунок В. 7.

Когда CTS используется для запроса повторной передачи пакетов данных, рекомендуется не использовать более 2 запросов на повторную передачу. Когда этот предел будет достигнут, будет отправлено сообщение о прерывании соединения с причиной прерывания 5 из таблицы 8. Если CTS принимается, пока соединение не установлено, оно должно быть проигнорировано. CTS не только контролирует поток, но и подтверждает правильное получение любого пакета данных до номера этого пакета CTS. Поэтому, если информация для предыдущего CTS была повреждена, то действия для поврежденной информации должны быть отправлены перед продолжением к следующим последовательным пакетам, которые будут отправлены. Из-за этого требования отправляющая управляющая функция передачей большого сообщения может использовать байт 5 сообщения TP.CM_RTS как способ обеспечить возможность повторной передачи пакета в пределах последнего набора пакетов, очищенных для отправки. TP. CM_CTS передается только принимающей управляющей функцией.

  • 5.10.4.4 Транспортный протокол Конец Сообщения Подтверждение (TP.CM_EndofMsgACK)

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

  • 5.10.4.5 Транспортный протокол Разрыв Соединения (TP.Conn_Abort)

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

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

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

Отправляющая управляющая функция (т. е. управляющая функция RTS) должна немедленно прекратить передачу после получения сообщения о разрыве соединения управляющей функцией протокола CAN. Если это невозможно, процесс прекращения передачи пакетов данных должен занимать не более 32 пакетов данных и не должен превышать 50 мс. После отправки или получения сообщения о разрыве соединения все полученные связанные пакеты данных должны игнорироваться. ТР.Сопп_ Abort передается отправляющей управляющей функцией или принимающей управляющей функцией.

Таблица 8 — Причины разрыва соединения

Значение

Определение

0

Зарезервировано для назначения в будущих стандартах

1

Уже находятся в одном или нескольких сеансах, управляемых подключением, и не может поддерживать другой сеанс

2

Системные ресурсы были необходимы для другой задачи, поэтому этот сеанс управления подключением был прекращен

3

Закончилось время ожидания, и это прерывание соединения для закрытия сеанса

4

CTS-сообщения, полученные во время передачи данных

5

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

6

Неожиданный пакет передачи данных

7

Плохой порядковый номер (и программное обеспечение не в состоянии восстановить)

8

Дубликат порядкового номера (и программное обеспечение не в состоянии восстановить)

9

«Общий размер сообщения» превышает 1 785 байт

от 10 до 249

Зарезервировано для назначения в будущем стандарте

250

Если выявлена причина разрыва соединения, которая не указана в таблице, используйте код 250

от 251 до 255

Согласно определениям ИСО 11783-7

  • 5.10.4.6 Предупреждение о трансляции (ТР.СМ_ВАМ)

ТР.СМ_ВАМ используется для информирования всех управляющих функций сети о том, что должно быть передано большое сообщение. Он определяет группу параметров и количество байтов для отправки. После передачи сообщения TP.CMJBAM отправляются сообщения транспортного протокола, содержащие «пакетированные» транслируемые данные.

TP.CMJBAM передается только отправляющей управляющей функцией.

  • 5.10.5 Транспортный протокол — сообщения передачи данных (TP.DT)

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

TP.DT передается только отправляющей управляющей функцией.

Имя группы параметров:

ТРАНСПОРТНЫЙ ПРОТОКОЛ — ПЕРЕДАЧА ДАННЫХ (TP.DT)

Определение:

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

Частота повторяющихся передач:

в соответствии с PGN, подлежащим передаче

Длина данных:

8 байт

Страница данных:

0

PF:

235

PS:

DA [глобальный (DA = 255) для передачи данных ТР.СМ.ВАМ; глобальный не разрешен для передачи данных RTS / CTS]

Приоритет по умолчанию:

7 (Приоритет, используемый независимо от транспортируемого PGN)

Номер группы параметров:

60 160 (00ЕВ0016)

Диапазон данных, использующийся этим типом сообщений:

Порядковый номер:

Байт: 1

Байты: от 2 до 8


от 1 до 255 (1 байт)

Порядковый номер

«Пакетированные» данные (7 байт)

Последний пакет из группы параметров из нескольких пакетов может потребовать менее 8 байтов. Дополнительные байты должны быть заполнены FF16.

  • 5.10.6 Ограничения соединений транспортного протокола

    • 5.10.6.1 Общие положения

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

  • 5.10.6.2 Количество и тип соединений, которые должна поддерживать управляющая функция

Каждая управляющая функция в сети может одновременно инициировать одну передачу соединения транспортного протокола для конкретного адреса назначения с данным адресом назначения. Это связано с тем, что TP.DT содержит только SA и DA, а не PGN передаваемых данных. Сеанс расширенного транспортного протокола может быть открыт параллельно с соединением транспортного протокола.

Только один многопакетный ВАМ (т. е. глобальный адрес назначения) может быть отправлен от отправляющей управляющей функции в данный момент времени. Это связано с тем, что TP.DT не содержит фактического PGN или идентификатора соединения. Однако принимающие управляющей функции должны признавать, что несколько многопакетных сообщений могут быть получены, перемежаясь друг с другом, от различных отправляющих управляющих функций (т. е. адресов источников).

Управляющая функция также должна быть способна поддерживать одну сессию RTS/CTS и одну сессию ВАМ одновременно от одного и того же SA. Поэтому принимающая управляющая функция должна использовать адрес назначения двух сообщений транспортного протокола, чтобы обеспечить их надлежащее разделение. Одно из сообщений транспортного протокола имеет глобальный, а дру-36

гое — конкретный DA. DA должен использоваться для различения различий между ними, поскольку TP.DT не содержит ни фактического PGN, ни идентификатора соединения.

Независимо от того, может ли управляющая функция поддерживать несколько одновременных сеансов транспортного протокола (RTS/CTS и/или ВАМ), она должна гарантировать, что сообщения TP.DT/ETP.DT из одной и той же SA, но имеющие разные DA, могут различаться. Принимающие управляющие функции должны использовать DA и SA для обеспечения правильности данных для сообщений. Передатчик параллельных сеансов ТР/ЕТР должен знать, что получатель может поставить один или оба сеанса на удержание в течение любого периода времени (см. 5.10.3.4.1), и поэтому невозможно предсказать, какой из сеансов будет закончен первым.

  • 5.10.6.3 Предполагаемое использование транспортного протокола

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

  • 5.10.6.4 Одновременный прием PGN

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

Примечание — Форма нетранспортного протокола PGN не считается сеансом, поэтому его отправка не закрывает форму транспортного протокола того же PGN.

  • 5.11 Функции расширенного транспортного протокола

    5.11.1 Описание

    Функции расширенного транспортного протокола описываются как часть уровня канала передачи данных аналогично функциям транспортного протокола. Из-за сходства понятно, что 5.10 является основой для требований, и настоящий пункт сосредоточен на уникальных характеристиках расширенного транспортного протокола. Хотя ссылки на 5.10 определяют общее поведение и требования, методы в этом подпункте реализуются с помощью сообщений расширенного транспортного протокола (например, ссылка на TP.CM_CTS определяет требование, которое реализуется с помощью сообщения ЕТР. CM_CTS).

    • 5.11.2 Общие положения

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

  • 5.11.3 Пакеты сообщений

Максимальное количество пакетов, которые могут быть отправлены в одном соединении с расширенным транспортным протоколом, ограничено смещением расширенного пакета данных (3 байта). Это дает максимальный размер сообщения 224 — 1 пакет х 7 байт / пакет = 117 440 505 байт для расширенного транспортного протокола.

  • 5.11.4 Расширенный транспортный протокол — Управление соединением

    • 5.11.4.1 Общие положения

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

Расширенный транспортный протокол использует пять управляющих байтов для расширенных запросов на соединение и ответов на сообщения. Эти управляющие байты и сообщения следующие.

  • - Контрольный байт 20

  • - Контрольный байт 21

  • - Контрольный байт 22

  • - Контрольный байт 23

  • - Контрольный байт 255


Расширенное сообщение Запрос на отправку

Расширенное сообщение Разрешение отправки

Расширенное сообщение Смещение пакетов данных

Расширенное сообщение Подтверждение окончания сообщения

Расширенное сообщение Разрыв соединения

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

Последовательность сообщений показана на рисунке 8. Отправляющая управляющая функция отправляет расширенный запрос сообщения для отправки (ETP.CM_RTS) в принимающую управляющую функцию. Принимающая управляющая функция отправляет ETP.CM_CTS обратно отправляющей управляющую функцию с количеством пакетов, которые может отправлять отправляющая управляющая функция, которые могут быть между 0 и 255, и номером пакета исходного пакета, который нужно отправить для первого сеанса передачи данных транспортного протокола. Установка количества пакетов для отправки на ноль удерживает соединение открытым между принимающей и отправляющей управляющей функцией. См. 5.10.4.3.

Затем отправляющая управляющая функция отправляет расширенное смещение пакета данных (ETP.CM_DPO), за которым следуют сообщения передачи данных расширенного транспортного протокола с необходимым количеством пакетов данных. Затем она ожидает следующего сообщения ЕТР. CM_CTS от принимающей управляющей функции, а затем повторяет со следующим сообщением расширенного смещения пакета данных и требуемым количеством сообщений передачи данных расширенного транспортного протокола. Фактическая последовательность каждого пакета в расширенном сообщении равна последнему принятому смещению расширенного пакета данных, добавленному к порядковому номеру в сообщении передачи данных расширенного транспортного протокола.

Рисунок 8 — Последовательность расширенного транспортного сообщения


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


  • 5.11.5 Расширенный транспортный протокол — Сообщения управления соединением (ЕТР.СМ)

    • 5.11.5.1 Общие положения

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

  • 5.11.5.2 Определение сообщения управления соединением

Имя группы параметров:

РАСШИРЕННЫЙ ТРАНСПОРТНЫЙ ПРОТОКОЛ — УПРАВЛЕНИЕ СОЕДИНЕНИЕМ (ЕТР.СМ)

Определение:

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

Частота повторения передач: по мере передачи PGN

Длина данных:

8 байт

Страница данных:

0

PF:

200

PS:

DA

Приоритет по умолчанию:

7

Номер группы параметров:

51 200 (00С80016)

Диапазоны данных для параметров, используемых этой групповой функцией:

Контрольный байт:

20, 21,22, 23, 255 для расширенных сообщений управления соединением;

0—19, 24—254 зарезервировано для назначения в будущих стандартах

Общий размер сообщения, байт: от 1 786 до 117 440 505 (4 байт) ((224 - 1) * 7)

Общее количество пакетов: от 256 до 16 777 215 (3 байт), от 0 до 255 не допускается

Количество пакетов, которые можно от 256 до 16 777 215 (3 байт), от 0 до 255 не допускается

отправить:

Следующий номер пакета для отправки: от 1 до 16 777 215 (3 байт)

Номер смещения пакета данных: от 0 до 16 777 214 (3 байт)

Порядковый номер:

от 1 до 255 (1 байт), 0 не допускается

Расширенный режим подключения RTS (ETP.CM_RTS): конкретный адрес назначения

Байт: 1

Контрольный байт = 20, Расширенный запрос на отправку

Байты: от 2 до 5

Количество байт для передачи (от 1 786 байт до 117 440 505 байт максимальное.)

Байты: от 6 до 8

PGN расширенного пакетного сообщения

Расширенный режим подключения CTS (ETP.CM_CTS): конкретный адрес назначения

Байт: 1

Контрольный байт = 21, Расширенное разрешение отправки

Байт: 2

Количество пакетов, которые можно отправить (0 или от 1 до 255)

Байты: от 3 до 5

Байты: от 6 до 8

Следующий номер пакета для отправки (от 1 до 16 777 215) PGN расширенного пакетного сообщения

Примечание 1 — Количество отправляемых пакетов + Следующий пакет для отправки - 1 не может превышать 16 777 215.

Примечание 2 — Ноль в байте 2 означает режим удержания соединения (см. 5.11.3.1).

Расширенный режим подключения Смещение пакета данных (ETP.CM_DPO): конкретный адрес назначения

Байт: 1 Контрольный байт = 22, Расширенное смещение пакета данных

Байт: 2 Количество пакетов, к которым применяется смещение (от 1 до 255)

Байты: от 3 до 5 Смещение пакета данных (от 0 до п) (Всегда на 1 меньше байтов с 3 по 5 из

ETP.CM_.CTS)

Байты: от 6 до 8 PGN расширенного пакетного сообщения

Примечание 3 — п + порядковый номер любого пакета не может превышать 16 777 215.

Байт 2 ETP.CM_DPO должен быть меньше или равен байту 2 ETPCM_CTS. Если байт 2 меньше байта 2 сообщения ETP.CM_CTS, то получатель должен внести необходимые корректировки в свой сеанс, чтобы принять определенный блок данных сообщением ETP.CM_DPO и последующими пакетами ETPDT.

Расширенное Подтверждение окончания сообщения (ЕТР.СМ_ЕОМА): конкретный адрес назначения

Байт: 1 Контрольный байт = 23, Расширенное Подтверждение окончания сообще

ния

Байты: от 2 до 5 Количество байтов для передачи (от 1 786 байт до 117 440 505 байт)

Байты: от 6 до 8 PGN расширенного пакетного сообщения

Расширенный Разрыв соединения (ETP.Conn_Abort): конкретный адрес назначения

Байт: 1 Контрольный байт = 255, Разрыв соединения

Байт: 2 Причина разрыва соединения

Байты: от 3 до 5 Зарезервированные для присвоения ИСО, эти байты должны быть установлены в FF16

Байты: от 6 до 8 PGN расширенного пакетного сообщения

  • 5.11.5. 3 Расширенный режим подключения Запрос на отправку (ETP.CM_RTS)

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

  • 5.11.5. 4 Расширенный режим подключения Разрешение на отправку (ETP.CM_CTS)

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

  • 5.11.5. 5 Расширенный режим подключения Смещение пакета данных (ETP.CM_DPO)

ETP.CM-DPO устанавливает смещение, из которого переданные пакеты нумеруются в пределах одной группы данных CTS. Фактический расширенный порядковый номер сообщения = (порядковый номер ETP.DT + ETP.CM_DPO смещение пакета данных).

  • 5.11.5. 6 Расширенное Подтверждение окончания сообщения (ЕТР.СМ_ЕОМА)

Сообщение ЕТР.СМ_ЕОМА передается от принимающей управляющей функции большого сообщения к его отправляющей управляющей функции, что указывает на то, что все расширенное сообщение было получено и правильно собрано.

  • 5.11.5. 7 Расширенный Разрыв соединения (ETP.Conn_Abort)

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

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

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

Таблица 9 — Причины разрыва соединения расширенного транспортного протокола

Значение

Описание

0

Зарезервировано для назначения в будущем стандарте

1

Уже находится в одном или нескольких сеансах, управляемых подключением, и не может поддерживать другой

2

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

3

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

4

Получение Сообщения CTS во время передачи данных

5

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

6

Неожиданный пакет передачи данных

7

Неверный порядковый номер (и программное обеспечение не может восстановить)

8

Дубликат порядкового номера (и программное обеспечение не может восстановить)

9

Неожиданный пакет EDPO

10

Неожиданный EDPO PGN (PGN в EDPO плохой)

11

Количество пакетов EDPO больше, чем CTS

12

Плохое смещение EDPO

13

Устаревшее. Используйте вместо него 250 (любая другая причина)

14

Неожиданный PGTS ECTS (PGN в ECTS плохой)

15

ECTS запрошенных пакетов превышает размер сообщения

16 до 249

Зарезервировано для назначения в будущем стандарте

250

Любая другая причина (если указана причина прерывания соединения, которая не указана в таблице, используйте код 250)

251 до 255

Согласно определениям ИСО 11783-7

  • 5.11. 6 Расширенный транспортный протокол — Сообщения Передачи данных (ETP.DT)

Сообщение ETP.DT используется для передачи данных, связанных с группой параметров. Сообщение ETP.DT является отдельным пакетом передачи нескольких пакетов сообщений. Например, если большое сообщение должно было быть разделено на 300 пакетов для передачи, тогда было бы 300 сообщений ETP.DT. В сообщениях передачи данных расширенного транспортного протокола используется PGN, отличный от используемого для транспортного протокола (см. 5.10.5).

Имя группы параметров:

РАСШИРЕННЫЙ ТРАНСПОРТНЫЙ ПРОТОКОЛ — ПЕРЕДАЧА

ДАННЫХ (ETP.DT)

Определение:

Используется для передачи данных, связанных с группами параметров, которые имеют более 1 785 байт данных.

Частота повторения передачи:

По мере передачи PGN

Длина данных:

8 байт

Страница данных:

0

PF:

199

PS:

DA

Приоритет по умолчанию:

7

Номер группы параметров:

50 944 (00С70016)

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

Порядковый номер: от 1 до 255 (1 байт)

Байт: 1 Последовательность чисел. Первый пакет ETP.DT, следующий за сообще

нием ETP.CM_DPO, всегда должен иметь порядковый номер 1.

Байты: от 2 до 8 «Пакетированные» данные (7 байт).

Последний пакет из группы параметров многопакетного сообщения может содержать менее 8 байт. В таком случае остальные байты следует передавать как FF16.

  • 5.11. 7 Ограничения соединений Расширенного транспортного протокола

Как определено в 5.10.6.2, передатчик параллельных сеансов ТР/ЕТР должен знать, что приемник может приостановить один или оба сеанса в течение любого периода времени (см. 5.11.5.3), и поэтому невозможно предсказать, какая из сессий будет первой, чтобы завершить.

  • 5.12 Требования к обработке PDU

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

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

  • 5.13 Замечания по применению

    5.13.1 Высокая скорость передачи данных

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

    • 5.13.2 Планирование запроса

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

  • 5.13.3 Время отклика контроллера и время ожидания по умолчанию

Все контроллеры, когда требуется предоставить ответ, должны сделать это в течение 0,20 с (Тг). Все контроллеры, ожидающие ответа, должны подождать не менее 1,25 с (ТЗ), прежде чем сдаться или повторить попытку. Эти времена гарантируют, что любые задержки из-за доступа к шине или пересылки сообщений через мосты не приводят к нежелательным превышениям времени ожидания. Различные значения времени могут быть использованы для конкретных приложений, когда это необходимо. Например, ответ 20 мс можно ожидать для высокоскоростных управляющих сообщений. Переупорядочение любых буферизованных сообщений может быть необходимо для достижения более быстрого ответа. Нет ограничений на минимальное время ответа.

Время между пакетами многопакетного сообщения, направленного в конкретный адрес назначения, составляет от 0 мс до 200 мс. Это означает, что могут возникать взаимные сообщения и они могут содержать один и тот же идентификатор. Механизм CTS может использоваться для обеспечения заданного промежутка времени между пакетами (управление потоком). Требуемый интервал времени между пакетами многопакетного широковещательного сообщения составляет от 10 мс до 200 мс. Минимальное время 10 мс гарантирует, что принимающая управляющая функция успеет получить сообщение от оборудования CAN. Принимающая управляющая функция должна использовать время ожидания (то есть Т1), равное 750 мс. Это обеспечивает время ожидания, превышающее максимальный интервал передачи в 200 мс.

Пример — Использование синхронизации 1,25 с (ТЗ).

  • а) Максимальное время прямой пересылки в пределах моста составляет 50 мс. Общее количество мостов равно 10 (то есть один трактор + пять прицепов + четыре тележки - 10 мостов). Следовательно, общая задержка в сети составляет 500 мс в одном направлении.

  • Ь) Количество повторных запросов равно двум (всего — три запроса), это относится к ситуации, когда CTS используется для запроса повторной передачи пакета(ов) данных. Если достигнут предел запроса на повторную передачу, то разрыв соединения должен быть отправлен с причиной разрыва 5 из таблицы 8.

  • с) Запас для времени ожидания составляет 50 мс.

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

Примечание — Отправляющая и принимающая управляющие функции имеют свои требования к передатчику и приемнику.

  • 5.13.4 Требуемые ответы

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

Управляющая функция, которая использует глобальный DA (255) для запроса (например, «запрос адреса»), сама должна отправить ответ, если она запросила данные. Это требование установлено, поскольку все управляющие функции должны реагировать. Если управляющая функция, выдающая запрос, не отвечает, то другие управляющие сетью функции могут определить неверный вывод о запрашиваемой информации.

  • 5.13.5 Передача PGN в конкретные или глобальные адреса назначения

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

  • 5.13.6 Рекомендуемое количество пакетов CTS

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

Приложение А (обязательное)

Обработка PDU по ИСО 11783 — типичная процедура приема

ПОЛУЧЕНИЕ ПРЕРЫВАНИЯ:

Примечание 1 — Когда микропроцессор получает сообщение через CAN IC, выполняется несколько тестов, чтобы проанализировать его и определить, где и когда оно должно храниться. Три приоритетных бита используются только для арбитража шины и поэтому не нужны (не используются) принимающей управляющей функцией.

Примечание 2 — Данный контроллер может иметь более одного адреса, если он выполняет несколько функций.

Если PGN = Запрос PGN и адрес назначения конкретный ; конкретный запрос То

Если DA= Назначенный адрес (адрес назначения) То

Сохранить 4 байта ID и 3 байта данных в очереди запросов Если PGN = Запрос PGN и адрес назначения глобальный ; глобальный запрос То Сохранить 4 байта ID и 3 байта данных в очереди запросов Если PF < 240 То

Если DA= Глобальный ; Формат PDU1 (DA= глобальный)

То

Использовать таблицу смещения для значений запрашиваемого PGN и Если SA= ID запрашиваемых значений То

Сохранить 8 байтов данных в назначенном буфере Иначе

Сохранить 12 байтов сообщения (ID и DATA) в очереди рассылки

Иначе DA = Конкретный ; Формат PDU1 Format (DA = Конкретный)

Использовать таблицу смещения для значений запрашиваемого PGN и Если SA = ID запрашиваемых значений То Сохранить 8 байтов данных в назначенном буфере Иначе

Сохранить 12 байтов сообщения (ID и DATA) в очереди рассылки

Если PF > или = 240 ; Формат PDU2

То

Использовать таблицу смещения для значений запрашиваемого PGN и Если SA= ID запрашиваемых значений То

Сохранить 8 байтов данных в назначенном буфере Иначе

Сохранить 12 байтов сообщения (ID и DATA) в очереди рассылки

Приложение В (обязательное)

Последовательности передачи транспортного протокола — примеры подключения режима передачи данных

При нормальных условиях поток передачи данных соответствует рисунку В.1. Отправляющая управляющая функция отправляет TP.CM_RTS, указывая, что в пакетном сообщении содержится 23 байта, которые будут переданы в четырех пакетах. PGN передаваемых данных — 65 259, идентификация компонента.

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

Отправляющая управляющая функция передает первые два пакета по сети, используя TP.DT. Затем принимающая управляющая функция передает сообщение TP.CM_CTS, указывающее, что соединение следует удерживать открытым, но принимающая управляющая функция не может принимать какие-либо пакеты в этот момент. Спустя максимум 500 мс необходимо отправить еще одно сообщение TP.CM_CTS для удержания соединения открытым. В этом примере принимающая управляющая функция отправляет сообщение TP.CM_CTS, указывающее, что могут быть приняты еще два пакета, начиная с пакета 3. Как только пакеты 3 и 4 были переданы, принимающая управляющая функция передает сообщение TP.EndOfMsgACK, указывающее, что все ожидаемые пакеты были получены и что соединение считается закрытым. Обратите внимание, что пакет 4 содержит 2 байта действительных данных, байты 22 и 23, остальные символы данных в этом пакете передаются как 255 (FF16), «данные недоступны», так что сообщение имеет общую длину 8 байтов.

Передача сообщений в случае ошибки соединения показана на рисунке В.2. Сообщение TP.CM_RTS передается и получает требуемый ответ, затем данные теряются на этапе передачи данных.

В этой ситуации запрос на отправку отправляется так же, как и в предыдущем примере. Первые два пакета передаются, но пакет номер два не прошел контрольную сумму или был ошибочно распознан принимающей управляющей функцией. Принимающая управляющая функция затем передает TP.CM_CTS, указывая, что требуется передать один пакет, и что требуемым пакетом является пакет номер 2. Отправляющая управляющая функция выполняет передачу пакета номер 2. Затем принимающая управляющая функция передает CTS, указывая, что требуется передать один пакет, и что требуемые пакеты начинаются с пакета номер 3. Это сообщение TP.CM_CTS является подтверждением того, что пакеты 1 и 2 были приняты правильно. Как только последний пакет принят правильно, принимающая управляющая функция передает сообщение TP.EndOfMsgACK, сигнализируя, что все сообщение было принято правильно.

В ситуации, показанной на рисунке В.З, управляющая функция указывает сети, что она собирается передать многопакетное сообщение, используя службы транспортного протокола. В этом примере PGN 65 260, идентификация трактора транслируется в сеть. Отправляющая управляющая функция сначала передает сообщение ТР.СМ_ ВАМ, а затем пакеты данных. Подтверждение не выполняется ни одной из принимающих управляющих функций.

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

На рисунке В.5 показана ситуация, когда отправляющая управляющая функция поддерживает параметр RTS «Максимальное количество пакетов», а принимающая функция не поддерживает. В этой ситуации отправляющая управляющая функция должна соответствовать ограничениям CTS принимающей управляющей функции. В этом примере отправляющая управляющая функция должна будет отправлять семь пакетов передачи данных, несмотря на то, что предпочтительно отправлять не более пяти.

ВНИМАНИЕ — В этом примере, если принимающая управляющая функция должна была отправить CTS для пакета 1 после передачи данных пакета 7, возможно, что отправляющая управляющая функция должна была бы повторно вычислить информацию, и, следовательно, вторая передача пакета 1 могла бы содержать разные данные из исходного пакета 1, в зависимости от типа данных, содержащихся в PGN. Например, PGN 65 227 имеет динамические данные и может привести к тому, что пакет 1 будет отличаться, в то время как PGN, такой как 65 242, имеет статические данные и не приведет к тому, что пакет 1 будет отличаться при его второй передаче данных.

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

Рисунок В.7 является примером случая CTS после истечения времени ожидания. В примере управляющей функции с медленной инициацией (левая сторона) отправляющая управляющая функция отправляет «пакет CTS» из 12 пакетов, но CTS повторной передачи принимающей функции приходит до того, как отправляющая управляющая функция отправляет последний пакет данных. Отправляющая управляющая функция прерывает сеанс с причиной отмены 4. Это возможный пример, когда повторная передача CTS не позволяет избежать прерывания сеанса. В примере функции с быстрой инициацией (правая сторона) повторная передача CTS принимающей управляющей функцией поступает после того, как отправляющая управляющая функция отправляет последний пакет данных и до истечения времени ожидания ТЗ. Это пример, в котором отправляющая управляющая функция может принимать CTS и не прерывать сеанс.

Отправляющая управляющая функция

Принимающая управляющая функция


ТЗ 1250 мс н

Тг< 200 мс —►

Тг< 200 мс —► м

ТЗ 1250 мс н

Т4 < 1050 мс —►

Тг < 200 мс —►

Тг < 200 мс —► м

ТЗ 1250 мс


— Т1 < 750 мс



Рисунок В.1 — Передача данных без ошибок

гост ? и00

АА783-3^02А

чество


пакетов RTS


РИСО ^83-3-^ ГОСТ P ис°


TP.CM_RTS 100,15, 5 X

TP.DT 1

TP.DT 10

TP.DT 3

TP.DT 4

TP.DT 5

TP.DT 6

TP.DT 7

TP.DT 8

TP.DT 9

TP.DT 10


TP.DT 2


n0 истечении e^'


ПоП'Л'® a


TP.DT 11


TP.DT 12


TP.DT 13


TP.DT 14


TP.DT 15


Приложение С (обязательное)

Примеры режима связи

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

  • 1 ТРАНСЛЯЦИЯ/ОТВЕТ/ПОДТВЕРЖДЕНИЕ ПОЛУЧЕНИЯ

Отправка серийного номера двигателя [PGN ID компонента = 65 259 (00FEEB16)].

  • 2 ЗАПРОС НА КОНКРЕТНЫЙ АДРЕС (PGN 59 904)

Получение запроса серийного номера двигателя. Отправленное сообщение является либо ОТВЕТОМ с данными, либо ОТРИЦАТЕЛЬНЫМ ПОДТВЕРЖДЕНИЕМ ПОЛУЧЕНИЯ. См. пример для пункта 4 ниже.

2А ГЛОБАЛЬНЫЙ ЗАПРОС

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

  • 3 КОМАНДА

Для некоторых команд является желательным получить конкретное подтверждение того, что задача была выполнена. В этом случае сообщение может быть отправлено обратно либо как АСК = КОМАНДА ЗАВЕРШЕНА, либо как NACK = КОМАНДА НЕ МОЖЕТ БЫТЬ ЗАВЕРШЕНА. В приведенном ниже примере «CF» используется в качестве команды, подтвержденной АСК или NACK.

  • 4 ПОДТВЕРЖДЕНИЕ ПОЛУЧЕНИЯ

Отправка сообщения NACK, если команда или запрос не могут быть обработаны (недопустимый запрос). Сообщение NACK содержит номер группы параметров (PGN) в поле данных. Если номер группы параметров в поле КОМАНДА или ЗАПРОС не распознается адресатом (получающей управляющей функцией), также должно быть отправлено NACK. Если номер группы параметров распознан, но параметры недоступны, возвращается нормальный ответ, но со значением данных равным 255.

Примеры:

PF

PS(DA)

SA

ДАННЫЕ

1

ТРАНСЛЯЦИЯ

254

235(GE)

000

236 912

2

КОНКРЕТНЫЙ ЗАПРОС

234

000(DA)

003

PGN 65 259

1

ОТВЕТ

254

235(GE)

000

236 912

or

4

ОТРИЦАТЕЛЬНОЕ ПОДТВЕРЖДЕНИЕ

232

3(DA)

000

01,255,255,255,3,PGN 65 259

ГЛОБАЛЬНЫЙ ЗАПРОС

234

255(DA)

003

PGN 65 259

1

ЗАПРОС

254

235(GE)

000

236 912

3

КОМАНДА

CF

000(DA)

240

1

КОМАНДА ЗАВЕРШЕНА

232

240 (DA)

000

00,255,255,255,240,PGN for CF

или

4

КОМАНДА НЕ МОЖЕТ БЫТЬ ЗАВЕРШЕНА

232

240 (DA)

00

01,255,255,255,240,PGN for CF

или ДРУГОЕ (См. примечание)

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

Приложение D (обязательное)

Использование полосы пропускания сети

В открытой системе, такой как ИСО 11783, использование полосы пропускания данной сети CAN очень важно. Требования к обмену сообщениями могут превышать пропускную способность сети, если не будут тщательно продуманы. Для оптимизации использования полосы пропускания следует:

  • а) ограничить использования проприетарных PG и сообщений CBFF;

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

  • с) использовать приоритет PG по умолчанию.

Следующие меры настоятельно рекомендуются.

  • - Использование проприетарных сообщений во время нормальной работы должно быть сведено к минимуму; сумма проприетарных А, А2 и В не должна превышать 2 % пропускной способности сети.

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

  • - Приоритет по умолчанию следует классифицировать и применять в соответствии с таблицей D.1.

Таблица D.1 — Рекомендованные уровни приоритета

Приоритет

SAE J 1939

Рекомендации для ИСО 11783

Определение

Период

Определение

0

Зарезервировано

1

от 10 мс до 20 мс

Управление машины другой машиной

2

от 20 мс до 50 мс

Защита системы

3

Управление

от 50 мс до 100 мс

Управление оператора

4

от 100 мс до 200 мс

Высокий статус системы

5

от 200 мс до 400 мс

Средний статус системы

6

Статус

от 400 мс до °° мс

Низкий статус системы, UI, Е/ТР.СМ

7

Передача данных

ЕТР и ТР Данные

Передача больших объемов данных

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

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

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

Сведения о соответствии ссылочных международных стандартов национальным стандартам

Таблица ДА.1

Обозначение ссылочного международного стандарта

Степень соответствия

Обозначение и наименование соответствующего национального стандарта

ISO 11783-1

IDT

ГОСТ Р ИСО 11783-1—2021 «Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 1. Общий стандарт на мобильную передачу данных»

ISO 11783-3

IDT

ГОСТ Р ИСО 11783-3—2021 «Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 3. Уровень канала передачи данных»

ISO 11783-5

IDT

ГОСТ Р ИСО 11783-5—2021 «Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 5. Управление сетью»

ISO 11783-6

IDT

ГОСТ Р ИСО 11783-6—2021 «Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 6. Виртуальный терминал»

ISO 11783-7

IDT

ГОСТ Р ИСО 11783-7—2021 «Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 7. Прикладной уровень сообщений для управления орудием»

ISO 11898-1

IDT

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

ISO 15765-2

*

  • * Соответствующий национальный стандарт отсутствует. До его принятия рекомендуется использовать перевод на русский язык данного международного стандарта.

Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов:

  • - IDT — идентичные стандарты.

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

[1 ] ISO 11783 (all parts), Tractors and machinery for agriculture and forestry — Serial control and communications data network

  • [2] SAE J 1939-21, Recommended practice for serial control and communications vehicle network — Part 21: Data link layer

  • [3] IEC 80000-13:2008, Quantities and units — Part 13: Information science and technology

УДК 631.3:006.354

ОКС 65.060.01


Ключевые слова: Тракторы и машины сельскохозяйственные; последовательная сеть управления и передачи данных; уровень канала передачи данных

Редактор В.Н. Шмельков Технический редактор В.Н. Прусакова Корректор О.В. Лазарева Компьютерная верстка Е.А. Кондрашовой

Сдано в набор 01.11.2021. Подписано в печать 03.12.2021. Формат 60x84%. Гарнитура Ариал. Усл. печ. л. 6,97. Уч.-изд. л. 6,32.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано в единичном исполнении в ФГБУ «РСТ» , 117418 Москва, Нахимовский пр-т, д. 31, к. 2.

Другие госты в подкатегории

    ГОСТ 10000-2017

    ГОСТ 10677-82

    ГОСТ 1114-84

    ГОСТ 12.2.111-2020

    ГОСТ 11674-75

    ГОСТ 12.2.122-2013

    ГОСТ 12588-81

    ГОСТ 12.2.139-97

    ГОСТ 12.2.122-88

    ГОСТ 12.2.121-2013

    ГОСТ 10677-2001

    ГОСТ 15594-80

    ГОСТ 12.2.121-88

    ГОСТ 17034-82

    ГОСТ 12935-76

    ГОСТ 16526-70

    ГОСТ 17800-72

    ГОСТ 18524-85

    ГОСТ 13398-82

    ГОСТ 19677-87

    ГОСТ 12.2.140-97

    ГОСТ 19722-82

    ГОСТ 19777-74

    ГОСТ 20760-75

    ГОСТ 20793-2009

    ГОСТ 17595-88

    ГОСТ 158-74

    ГОСТ 20062-96

    ГОСТ 22587-91

    ГОСТ 19597-94

    ГОСТ 22999-88

    ГОСТ 23074-85

    ГОСТ 23173-78

    ГОСТ 21909-83

    ГОСТ 23173-96

    ГОСТ 20915-75

    ГОСТ 23982-85

    ГОСТ 23707-95

    ГОСТ 19598-95

    ГОСТ 23734-79

    ГОСТ 2472-80

    ГОСТ 24665-81

    ГОСТ 25327-82

    ГОСТ 25483-95

    ГОСТ 25518-93

    ГОСТ 17.2.2.02-98

    ГОСТ 25353-82

    ГОСТ 25836-83

    ГОСТ 25791-90

    ГОСТ 25942-90

    ГОСТ 26285-84

    ГОСТ 26711-89

    ГОСТ 26738-91

    ГОСТ 26879-88

    ГОСТ 24059-2017

    ГОСТ 26954-2019

    ГОСТ 27310-87

    ГОСТ 26025-83

    ГОСТ 27388-87

    ГОСТ 27434-87

    ГОСТ 27857-88

    ГОСТ 13758-89

    ГОСТ 27021-86

    ГОСТ 26026-83

    ГОСТ 27378-87

    ГОСТ 28099-89

    ГОСТ 28174-89

    ГОСТ 27999-88

    ГОСТ 27994-88

    ГОСТ 20915-2011

    ГОСТ 28305-89

    ГОСТ 28286-89

    ГОСТ 28306-2018

    ГОСТ 28307-2013

    ГОСТ 28287-89

    ГОСТ 28516-90

    ГОСТ 28523-90

    ГОСТ 28307-89

    ГОСТ 28524-90

    ГОСТ 28708-90

    ГОСТ 28713-2018

    ГОСТ 28306-89

    ГОСТ 28708-2001

    ГОСТ 28714-90

    ГОСТ 28713-90

    ГОСТ 28301-89

    ГОСТ 23730-88

    ГОСТ 28722-2018

    ГОСТ 28722-90

    ГОСТ 28957-91

    ГОСТ 28958-91

    ГОСТ 28718-90

    ГОСТ 30411-2001

    ГОСТ 30411-95

    ГОСТ 30506-97

    ГОСТ 28745-90

    ГОСТ 30725-2001

    ГОСТ 28301-2015

    ГОСТ 24055-2016

    ГОСТ 30723-2001

    ГОСТ 28301-2007

    ГОСТ 30748-2001

    ГОСТ 30749-2001

    ГОСТ 30752-2001

    ГОСТ 30747-2001

    ГОСТ 28717-90

    ГОСТ 31593-2012

    ГОСТ 30746-2001

    ГОСТ 17460-72

    ГОСТ 28714-2007

    ГОСТ 28718-2016

    ГОСТ 32485-2013

    ГОСТ 30750-2001

    ГОСТ 33037-2014

    ГОСТ 32617-2014

    ГОСТ 30745-2001

    ГОСТ 33678-2015

    ГОСТ 33679-2015

    ГОСТ 31742-2012

    ГОСТ 31595-2012

    ГОСТ 31345-2017

    ГОСТ 33691-2015

    ГОСТ 31348-2007

    ГОСТ 33687-2015

    ГОСТ 33677-2015

    ГОСТ 33736-2016

    ГОСТ 34280-2017

    ГОСТ 34363-2017

    ГОСТ 33734-2016

    ГОСТ 31345-2007

    ГОСТ 34389-2018

    ГОСТ 33032-2014

    ГОСТ 34431-2018

    ГОСТ 32431-2013

    ГОСТ 33686-2015

    ГОСТ 34491-2018

    ГОСТ 34492-2018

    ГОСТ 34493-2018

    ГОСТ 34494-2018

    ГОСТ 34490-2018

    ГОСТ 34393-2018

    ГОСТ 34495-2018

    ГОСТ 34501-2018

    ГОСТ 34605-2019

    ГОСТ 34629-2019

    ГОСТ 34391-2018

    ГОСТ 34392-2018

    ГОСТ 34746-2021

    ГОСТ 34747-2021

    ГОСТ 3481-79

    ГОСТ 3496-74

    ГОСТ 3497-74

    ГОСТ 34265-2017

    ГОСТ 4154-93

    ГОСТ 4156-93

    ГОСТ 4153-93

    ГОСТ 4230-93

    ГОСТ 5.1650-72

    ГОСТ 4229-94

    ГОСТ 6939-85

    ГОСТ 7057-81

    ГОСТ 7496-84

    ГОСТ 34631-2019

    ГОСТ 33735-2016

    ГОСТ 9024-70

    ГОСТ 7751-2009

    ГОСТ 33737-2016

    ГОСТ EN 12525-2012

    ГОСТ 7751-85

    ГОСТ EN 13118-2012

    ГОСТ 34496-2018

    ГОСТ EN 12965-2012

    ГОСТ 34498-2018

    ГОСТ 34390-2018

    ГОСТ EN 13448-2012

    ГОСТ ЕН 632-2003

    ГОСТ EN 13140-2012

    ГОСТ EN 1853-2012

    ГОСТ 7057-2001

    ГОСТ IEC 60335-2-70-2015

    ГОСТ IEC 60335-2-87-2019

    ГОСТ IEC 60335-2-70-2011

    ГОСТ IEC 60335-2-87-2015

    ГОСТ IEC 60335-2-94-2021

    ГОСТ 34630-2019

    ГОСТ ISO 11001-2-2019

    ГОСТ EN 609-1-2012

    ГОСТ EN 609-2-2012

    ГОСТ ISO 11169-2011

    ГОСТ ISO 11512-2011

    ГОСТ ISO 11850-2011

    ГОСТ ISO 11839-2016

    ГОСТ ISO 11001-1-2019

    ГОСТ EN 703-2012

    ГОСТ ИСО 14269-3-2003

    ГОСТ IEC 60335-2-77-2011

    ГОСТ ИСО 14269-5-2003

    ГОСТ ISO 16231-1-2016

    ГОСТ ISO 15886-3-2017

    ГОСТ ИСО 14269-2-2003

    ГОСТ 34499-2018

    ГОСТ EN 13525-2012

    ГОСТ ISO 11837-2016

    ГОСТ ISO 3776-1-2012

    ГОСТ ИСО 14269-4-2003

    ГОСТ ISO 3776-2-2012

    ГОСТ ISO 26322-1-2012

    ГОСТ ISO 26322-2-2012

    ГОСТ ISO 3776-3-2013

    ГОСТ ISO 3776-2-2018

    ГОСТ ИСО 4253-2005

    ГОСТ ISO 2332-2013

    ГОСТ ISO 4254-13-2013

    ГОСТ ИСО 4252-2005

    ГОСТ IEC 62841-4-3-2020

    ГОСТ ISO 4254-11-2013

    ГОСТ ИСО 11545-2004

    ГОСТ ISO 4254-6-2012

    ГОСТ ИСО 4254-6-2005

    ГОСТ ИСО 4254-7-2005

    ГОСТ ISO 4254-9-2021

    ГОСТ ISO 5395-2-2016

    ГОСТ ISO 5395-1-2016

    ГОСТ ISO 5395-3-2016

    ГОСТ ISO 5675-2019

    ГОСТ ISO 5681-2012

    ГОСТ ИСО 5682-2-2004

    ГОСТ ISO 4254-10-2013

    ГОСТ ИСО 4254-3-2005

    ГОСТ ISO 4254-9-2012

    ГОСТ ISO 5721-2-2016

    ГОСТ ISO 5721-1-2016

    ГОСТ ISO 16231-2-2019

    ГОСТ ISO 12003-2-2016

    ГОСТ ISO 4254-8-2013

    ГОСТ ISO 7914-2012

    ГОСТ ISO 5674-2012

    ГОСТ ИСО 5682-1-2004

    ГОСТ ISO 8084-2011

    ГОСТ ИСО 7714-2004

    ГОСТ ИСО 5682-3-2004

    ГОСТ ISO 8083-2011

    ГОСТ ИСО 8224-2-2004

    ГОСТ ИСО 7749-2-2004

    ГОСТ ISO 8082-2-2014

    ГОСТ ISO 8082-1-2017

    ГОСТ ИСО 8909-2-2003

    ГОСТ МЭК 60335-2-94-2004

    ГОСТ МЭК 60335-2-92-2004

    ГОСТ ИСО 7749-1-2004

    ГОСТ ISO 22867-2014

    ГОСТ Р 50022-92

    ГОСТ Р 50060-92

    ГОСТ Р 41.71-99

    ГОСТ ISO 730-2019

    ГОСТ Р 50163-92

    ГОСТ Р 50060-98

    ГОСТ Р 50164-92

    ГОСТ ИСО 9261-2004

    ГОСТ Р 50634-93

    ГОСТ Р 50162-92

    ГОСТ ИСО 9260-2004

    ГОСТ Р 50192-92

    ГОСТ Р 50911-96

    ГОСТ Р 50717-94

    ГОСТ Р 50191-92

    ГОСТ Р 50908-96

    ГОСТ Р 51207-98

    ГОСТ Р 51390-99

    ГОСТ Р 51389-99

    ГОСТ Р 51208-98

    ГОСТ Р 51657.1-2000

    ГОСТ Р 51961-2002

    ГОСТ Р 51754-2001

    ГОСТ Р 51960-2002

    ГОСТ Р 41.86-99

    ГОСТ Р 52504-2005

    ГОСТ Р 51629-2000

    ГОСТ Р 52648-2006

    ГОСТ Р 51614-2000

    ГОСТ Р 52746-2007

    ГОСТ Р 52291-2004

    ГОСТ Р 52026-2003

    ГОСТ Р 52053-2003

    ГОСТ ИСО 8224-1-2004

    ГОСТ Р 52649-2006

    ГОСТ Р 52777-2007

    ГОСТ Р 53051-2008

    ГОСТ Р 52759-2007

    ГОСТ Р 52758-2007

    ГОСТ Р 53054-2008

    ГОСТ Р 53391-2009

    ГОСТ Р 53489-2009

    ГОСТ Р 52757-2007

    ГОСТ Р 54454-2011

    ГОСТ Р 53057-2008

    ГОСТ Р 53052-2008

    ГОСТ Р 54778-2011

    ГОСТ Р 52778-2007

    ГОСТ Р 54781-2011

    ГОСТ Р 54784-2011

    ГОСТ Р 54785-2011

    ГОСТ Р 54780-2011

    ГОСТ Р 41.96-2005

    ГОСТ Р 53053-2008

    ГОСТ Р 58249-2018

    ГОСТ Р 58330.1-2018

    ГОСТ Р 58330.2-2018

    ГОСТ Р 58330.3-2021

    ГОСТ Р 55261-2012

    ГОСТ Р 57192-2016

    ГОСТ Р 54783-2011

    ГОСТ Р 41.96-99

    ГОСТ Р 58657-2019

    ГОСТ Р 58331.1-2018

    ГОСТ Р 58331.2-2019

    ГОСТ Р ИСО 10884-99

    ГОСТ Р 58655-2019

    ГОСТ Р 58801-2020

    ГОСТ Р 54779-2011

    ГОСТ Р ИСО 11783-1-2021

    ГОСТ Р ИСО 11783-11-2021

    ГОСТ Р 53056-2008

    ГОСТ Р ИСО 11783-13-2021

    ГОСТ Р ИСО 11783-12-2021

    ГОСТ Р ИСО 11169-2000

    ГОСТ Р ИСО 11783-14-2021

    ГОСТ Р ИСО 11512-2000

    ГОСТ Р ИСО 11783-4-2021

    ГОСТ Р ИСО 11783-8-2021

    ГОСТ Р ИСО 11783-7-2021

    ГОСТ Р 60.6.2.1-2019

    ГОСТ Р ИСО 11783-5-2021

    ГОСТ Р ИСО 11850-2005

    ГОСТ Р ИСО 11783-9-2021

    ГОСТ Р ИСО 11783-2-2021

    ГОСТ Р ИСО 15078-2002

    ГОСТ Р ИСО 11783-10-2021

    ГОСТ Р 54782-2011

    ГОСТ Р 58656-2019

    ГОСТ Р ИСО 13862-2003

    ГОСТ Р ИСО 4254-7-2011

    ГОСТ Р ИСО 13860-2003

    ГОСТ Р ИСО 7914-99

    ГОСТ Р ИСО 13861-2003

    ГОСТ Р ИСО 4254-1-2011

    ГОСТ Р ИСО 7917-99

    ГОСТ Р ИСО 7918-99

    ГОСТ Р ИСО 6815-2004

    ГОСТ Р ИСО 7916-99

    ГОСТ Р ИСО 8083-2008

    ГОСТ Р ИСО 8084-2005

    ГОСТ Р ИСО 8084-99

    ГОСТ Р ИСО 8380-99

    ГОСТ Р ИСО 8082-2005

    ГОСТ Р ИСО 3463-2008

    ГОСТ Р ИСО 12003-1-2011

    ГОСТ Р ИСО 8082-99

    ГОСТ Р ИСО 8082-1-2012

    ГОСТ Р 41.96-2011

    ГОСТ Р МЭК 60335-2-77-99

    ГОСТ Р ИСО 5700-2008

    ГОСТ Р ИСО 5696-2002

    ГОСТ Р 55262-2012