ГОСТ Р ИСО 11783-3-2021. Национальный стандарт Российской Федерации. Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 3. Уровень канала передачи данных
Актуально на 08.11.2026.
Как цитировать: "ГОСТ Р ИСО 11783-3-2021. Национальный стандарт Российской Федерации. Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 3. Уровень канала передачи данных". ГОСТ Р ИСО 11783-3-2021. https://bukva.ai/docs/standart-gost-r-iso-11783-3-2021
(утв. и введен в действие Приказом Росстандарта от 21.10.2021 № 1241-ст)
Примечание
Документ введен в действие с 01.01.2022.
Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 21 октября 2021 г. № 1241-ст
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ТРАКТОРЫ И МАШИНЫ ДЛЯ СЕЛЬСКОГО И ЛЕСНОГО ХОЗЯЙСТВА
ПОСЛЕДОВАТЕЛЬНАЯ СЕТЬ УПРАВЛЕНИЯ И ПЕРЕДАЧИ ДАННЫХ
УРОВЕНЬ КАНАЛА ПЕРЕДАЧИ ДАННЫХ
Tractors and machinery for agriculture and forestry. Serial control and communications data network. Part 3. Data link layer
Дата введения 1 января 2022 года
Предисловие
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).
Международный стандарт разработан Техническим комитетом ИСО/TC 23 «Тракторы и машины для сельского и лесного хозяйства», Подкомитетом SC 19 «Сельскохозяйственная электроника» Международной организации по стандартизации (ИСО).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)
Введение
Части с 1 по 14 серии стандартов ИСО 11783 устанавливают систему коммуникаций сельскохозяйственного оборудования, основанную на ИСО 11898-2. Документы SAE J 1939 [1], на части которых основан стандарт ИСО 11783, были разработаны для совместного использования на грузовых автомобилях и автобусах, а также для применения в строительстве и сельском хозяйстве. Были разработаны общие документы, позволяющие использовать после минимальных изменений в сельскохозяйственном и лесохозяйственном оборудовании электронные блоки, соответствующие техническим условиям SAE J 1939 для грузовых автомобилей и автобусов. Общая информация по всем частям серии стандартов ИСО 11783 приведена в ИСО 11783-1.
Цель стандартов серии ИСО 11783 состоит в предоставлении открытой взаимосвязанной системы для бортовых электронных систем. Стандарт предназначен для обеспечения связи электронных блоков управления (ECU) со всеми другими блоками в целях создания стандартной системы.
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)
б) Расширенный классический формат кадра (CEFF)
Рисунок 1 — Кадры данных классического CAN
Затем поля упаковываются в один кадр данных классического CAN и отправляются через физический носитель другим сетевым контроллерам. Уровни модели OSI, которые поддерживает ИСО 11783, показаны на рисунке 2. Возможно, что для некоторых определений группы параметров требуется более одного классического кадра данных CAN для отправки их информации.
Рисунок 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).
Назначение ИСО 11783 в поля арбитража и контроля CAN
| Номер бита | 29-битный идентификатор | 11-битный идентификатор | |||||
| CAN | ИСО 11783 | CAN | ИСО 11783 b | ||||
| 1 | SOF | SOF a | SOF | SOF a | |||
| 2 | ID28 | P3 | ID28 | P3 | |||
| 3 | ID27 | P2 | ID27 | P2 | |||
| 4 | ID26 | P1 | ID26 | P1 | |||
| 5 | ID25 | EDP | ID25 | ID8 a | |||
| 6 | ID24 | DP | ID24 | ID7 a | |||
| 7 | ID23 | PF8 | ID23 | ID6 a | |||
| 8 | ID22 | PF7 | ID22 | ID5 a | |||
| 0 | ID21 | PF6 | ID21 | ID4 a | |||
| 10 | ID20 | PF5 | ID20 | ID3 a | |||
| 11 | ID19 | PF4 | ID19 | ID2 a | |||
| 12 | ID18 | PF3 | ID18 | ID1 a | |||
| 13 | SRR (r) | SRR a | RTR (x) | RTR a (d) | |||
| 14 | IDE (r) | IDE a | IDE (d) | IDE a | |||
| 15 | ID17 | PF2 | FDF (d) | FDF a | |||
| 16 | ID16 | PF1 | DLC4 | DLC4 | |||
| 17 | ID15 | PS8 | DLC3 | DLC3 | |||
| 18 | ID14 | 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 (x) | RTR a (d) | |||||
| 34 | FDF (x) | FDF a (d) | |||||
| 35 | r0 (d) | r0 a | |||||
| 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 | ||||
| FDF | Индикатор формата FD | (d) | доминантный бит | ||||
| r# | Зарезервированный номер бита CAN (#) | (r) | рецессивный бит | ||||
| DLC# | Номер бита кода длины данных (#) | (x) | состояние бита зависит от сообщения | ||||
| P# | Номер приоритетного бита (#) в соответствии с ИСО 11783 | ||||||
| a Определенный CAN бит, без изменений в ИСО 11783. b Требуемый формат проприетарных 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 страницы x [240 + (16 x 256)] = 8 672}, используя соглашения, указанные в настоящем стандарте. См. ИСО 11783-1 для последних назначений PGN.
Примеры номера группы параметров (PGN)
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, ACK и EOF, а также части поля управления. Они определены протоколом CAN и не изменяются положениями ИСО 11783.
Поля PDU (см. рисунок 4) указаны в 5.2.2 - 5.2.8.
| Приоритет | EDP, | DP, | PF, | PS, | SA, | Данные | |
|---|---|---|---|---|---|---|---|
| Номер бита | ...3..., | ...1..., | ...1..., | ...8..., | ...8..., | ...8..., | ...64... |
5.2.2 Приоритет (P)
Приоритетные биты используются только для оптимизации задержки сообщения для передачи на шину. Они должны быть глобально замаскированы принимающим контроллером (игнорируются). Приоритет любого сообщения может быть установлен от самого высокого 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.
Определение использования расширенной страницы данных (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.
Определение специального поля 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 бит. В сети должна быть только одна управляющая функция с конкретным адресом источника.
Примечание - Управление адресами и их распределение, а также процедуры по предотвращению дублирования SA см. ИСО 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, определены как PDU1 (PS = DA) и PDU2 (PS = GE). PDU1 позволяет направлять кадр данных классической CAN на конкретный адрес назначения (управляющей функции); PDU2 передает только кадры данных классической CAN, которые не зависят от места назначения. Два отдельных формата PDU создаются для обеспечения различных возможных комбинаций номеров групп параметров, в то же время обеспечивая связь для конкретного адреса назначения. Собственные определения группы параметров назначаются таким образом, чтобы оба формата PDU могли использоваться для проприетарной связи. Стандартизированный метод для проприетарной связи определен, чтобы предотвратить возможные конфликты в использовании идентификатора.
Было установлено определение собственных номеров групп параметров, позволяющее использовать форматы PDU1 и PDU2. Интерпретация служебной информации зависит от производителя.
| Приоритет | EDP, | DP, | PF, | PS(DA), | SA, | Данные | |
|---|---|---|---|---|---|---|---|
| Номер бита | ...3..., | ...1..., | ...1..., | ...8..., | ...8..., | ...8..., | ...64..., |
| Приоритет | EDP, | DP, | PF | PS(GE), | SA, | Данные | |
|---|---|---|---|---|---|---|---|
| Номер бита | ...3..., | ...1..., | ...1..., | ...8..., | ...8..., | ...8..., | ...64..., |
Рисунок 5 — Доступные форматы PDU
5.3.2 Формат PDU1
Формат PDU1 предусматривает отправку применимых групп параметров либо в конкретный, либо в глобальный адрес назначения. Поле PS содержит DA.
Сообщения формата PDU1 могут быть запрошены или отправлены как нежелательные сообщения.
Сообщения формата PDU1 определяются полем PF. Когда значение этого поля составляет от 0 до 239, сообщение имеет формат PDU1. Формат сообщения PDU1 показан на рисунке 5. Также см. рисунок 6.
a В настоящее время 2 x 240 = 480.
Группы параметров, требующие назначения (PDU1) и минимальной задержки, начинаются с PF = 0 и увеличиваются в направлении x (или x1).
См. таблицу 7.
PF, равный 239 (бит расширенной страницы данных = 0 и бит страницы данных = 0), назначается для проприетарного использования. В этом случае поле PS является адресом назначения (см. 5.4.6). PGN для проприетарного A составляет 61 184.
5.3.3 Формат PDU2
Формат PDU2 может использоваться только для передачи групп параметров в виде глобальных сообщений. Сообщения формата PDU2 могут быть запрошены или отправлены как нежелательные сообщения. Выбор формата PDU2 во время назначения PGN предотвращает возможность направления PGN в конкретный адрес назначения. Поле PS содержит GE.
Сообщения формата PDU2 определяются как сообщения, в которых значение PF равняется от 240 до 255. Формат сообщения PDU2 показан на рисунке 5. Также см. рисунок 7.
a В настоящее время 2 x 16 x 256 = 8192.
PGN сообщений, которые отправляются с высокой скоростью обновления (обычно менее 100 мс), начинается с PF = 240 и увеличивается в направлении y (или y1).
PGN сообщений, которые запрашиваются, отправляются только при изменении или отправляются с низкой частотой обновления (обычно более 100 мс), начинаются с PF = 254 и уменьшаются в направлении y (или y1).
См. таблицу 7.
PF, равный 255 (бит расширенной страницы данных = 0 и бит страницы данных = 0), назначается для проприетарного использования. Поле PS оставлено для определения и использования каждым производителем (см. 5.4.6). PGN для проприетарного B охватывает диапазон от 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, а MSB — в байт 8.
5.4.2 Команда
Тип командного сообщения классифицирует те группы параметров, которые задают конкретный или глобальный адрес назначения из источника. Затем предполагается, что адрес назначения должен предпринять определенные действия на основе приема этого типа командного сообщения. Как команды PDU1 (PS = DA), так и сообщения формата PDU2 (PS = GE) могут использоваться для команд. Примеры командных режимов включают управление передачей, запрос адреса и управление крутящим моментом/скоростью.
5.4.3 Запрос
Тип сообщения запроса, идентифицируемый PGN, предоставляет возможность запрашивать информацию глобально или из определенного места назначения. Запросы, специфичные для одного адреса назначения, называются запросами, специфичными для адреса назначения. Приведенная ниже информация назначает PGN группе параметров запроса PGN. Эта информация представлена в том же формате, что и определения групп параметров в стандарте ИСО 11783.
| Имя группы параметров: | ЗАПРОС |
|---|---|
| Определение: | используется для запроса группы параметров из управляющей сетью функции или управляющей функции |
| Частота повторения передач: | в соответствии с требованиями пользователя обычно рекомендуется, чтобы запросы выполнялись не более двух-трех раз в секунду |
| Длина данных: | 3 байта (Классический кадр CAN для этого PG должен установить DLC на 3) |
| Страница данных: | 0 |
| PF: | 234 |
| PS: | DA (глобальный или конкретный) |
| Приоритет по умолчанию: | 6 |
| Номер группы параметров: | 59 904 (00EA0016) |
| Байты: 1, 2, 3 | Запрашивается PGN (см. 5.1.3 для определения поля и порядка байтов) |
В таблице 5 перечислены возможности запроса/ответа для PDU1 и PDU2 формата PGN. В нем поясняется, что отправляющая управляющая функция сообщением определяет, является ли адрес назначения конкретным или глобальным, в зависимости от того, был ли запрос к конкретному или глобальному DA. Таблица 5 также иллюстрирует, что для незапрошенных сообщений отправляющая управляющая функция может передавать на конкретный или глобальный DA для PDU1 и PDU2 PGN с более чем 8 байтами. Для PDU2 PGN с 8 байтами или меньше отправляющая управляющая функция может отправлять данные только глобально.
PDU1 и PDU2 требования к передаче, запросу и ответу
Ниже приведены общие правила работы для определения, следует ли отправлять PGN на глобальный или конкретный адрес назначения. См. таблицу 5.
a) Если запрос отправляется на глобальный адрес, то ответ также отправляется на глобальный адрес.
NACK (см. 5.4.5) не разрешен в качестве ответа на глобальный запрос.
b) Если запрос отправляется на конкретный адрес, то ответ отправляется на конкретный адрес.
NACK требуется, если PGN не поддерживается.
Если длина данных составляет 8 байт или более, транспортный протокол RTS/CTS должен использоваться для ответа на конкретный адрес.
- PDU2 формат PGN с 8 байтами или менее может быть отправлен только на глобальный адрес назначения, потому что в формате PDU2 нет поля адреса назначения.
- Объявление адреса PGN отправляется на глобальный адрес назначения, даже если запрос был адресован конкретному адресу назначения (см. ИСО 11783-5).
c) Для периодических транслируемых или незапрошенных сообщений PGN формата PDU1 или PDU2 может отправляться на глобальный или конкретный адрес назначения.
- PDU2 формата PGN с 8 байтами или меньше может быть отправлен только на глобальный адрес назначения, потому что в формате PDU2 нет поля адреса назначения.
d) Исключения из этих правил существуют, как видно из вышесказанного. Исключения отмечены в соответствующем документе в разделе, в котором определен PGN.
В таблице 6 приведены два примера использования запроса PGN.
Использование указанных полей в формате ИСО 11783 PDU1
| Тип сообщения | PGN | PS (DA) | SA | Данные 1 | Данные 2 | Данные 3 |
| Глобальный запрос | 59 904 | 255 (Отвечающий) | SA1 (Запрашивающий) | PGN LSB a | PGN | PGN MSB a |
| Конкретный запрос | 59 904 | SA2 (отвечающий) | SA1 (Запрашивающий) | PGN LSB a | PGN | PGN MSB a |
| a Номер группы параметров (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. Их отсутствие подтверждает, что все остальные контроллеры с питанием и подключением получили сообщение правильно.
Вторая форма подтверждения является ответом «нормальной трансляции», «ACK» или «NACK» на конкретную команду или запрос, как предусмотрено прикладным уровнем. Определение группы параметров подтверждения показано ниже. Тип подтверждения, требуемый для некоторых групп параметров, определяется на уровне приложений.
Для групп параметров групповой функции (см. 5.4.6) параметр «Значение групповой функции» позволяет управляющей функции идентифицировать конкретную групповую функцию, которая подтверждается. Значение групповой функции уникально для каждой групповой функции PG. Желательно, чтобы значения групповой функции использовали только диапазон от 0 до 250.
Каждая форма Подтверждения включает в себя байт подтверждения адреса, содержащий адрес источника отправителя запроса, на который направлено подтверждение. Для максимальной совместимости с SAE J1939 поле подтверждения адреса является дубликатом поля PS. Параметры в байте 5: подтверждение адреса, отрицательное подтверждение адреса, отказ в доступе к адресу и занятый адрес.
Диапазоны данных для параметров, используемых этим типом сообщения:
Положительное подтверждение: контрольный байт = 0
| Байт: | 1 | Контрольный байт = 0, Положительное подтверждение (ACK) |
|---|---|---|
| Байт: | 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 и Тип расширенного идентификатора «Однобайтовый расширенный идентификатор»
Отрицательное подтверждение: контрольный байт = 129 и Тип расширенного идентификатора «Однобайтовый расширенный идентификатор»
Доступ запрещен: контрольный байт = 130 и Тип расширенного идентификатора «Однобайтовый расширенный идентификатор»
Не может ответить: контрольный байт = 131 и Расширенный типа идентификатора «Однобайтовый расширенный идентификатор»
Положительное подтверждение: контрольный байт = 144 и Расширенный тип идентификатора «Двубайтовый расширенный идентификатор»
Отрицательное подтверждение: контрольный байт = 145 и Расширенный тип идентификатора «Двухбайтовый Расширенный Идентификатор»
Доступ запрещен: контрольный байт = 146 и Расширенный тип идентификатора «Двухбайтовый расширенный идентификатор»
Не может ответить: контрольный байт = 147 Расширенный тип идентификатора «Двухбайтовый расширенный идентификатор»
Положительное подтверждение: контрольный байт = 160 и Расширенный тип идентификатора «Трехбайтовый расширенный идентификатор»
Отрицательное подтверждение: контрольный байт = 161 и Расширенный тип идентификатора «Трехбайтовый расширенный идентификатор»
Доступ запрещен: контрольный байт = 162 и Расширенный тип идентификатора «Трехбайтовый расширенный идентификатор»
Не может ответить: контрольный байт = 163 и Расширенный тип идентификатора «Трехбайтовый расширенный идентификатор»
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 между различными производителями. Он также предоставляет средства для получения и различения проприетарных сообщений для использования, когда это необходимо. Групповые функции могут предоставлять свои собственные механизмы запроса, ACK и/или NACK, если сообщений, определенных в этом документе, недостаточно.
Запрос с использованием PGN 59 904 (см. 5.4.3) может быть использован для определения того, поддерживается ли определенная группа параметров типа сообщения групповой функции. Если поддерживается, то принимающая управляющая функция отправляет подтверждение PGN с управляющим байтом, равным нулю, для положительного подтверждения, или равным двум для отказа в доступе, или равным 3 для «не может ответить». Если он не поддерживается, то принимающая управляющая функция отправляет подтверждение PGN с управляющим байтом, установленным на единицу, для отрицательного подтверждения. Остальные части указанной в стандарте ИСО 11783 группы PF и параметров должны быть заполнены надлежащим образом (см. пункт 5.4.5).
В соответствии с определениями, содержащимися в этом пункте, фраза «не поддерживается» означает, что PG не передается. С помощью этого метода невозможно определить, действует ли управляющая функция на полученный PG.
Длина данных проприетарных сообщений A, A2 и B может быть установлена каждым производителем. Поэтому два производителя могут использовать одно и то же значение GE, и оно может иметь разный код длины данных. Для получения контрольных функций этой информации необходимо различать двух производителей. То, как используется поле данных этого сообщения, находится на усмотрении производителя, как и использование проприетарных сообщений. Использование проприетарных сообщений во время нормальной работы должно быть сведено к минимуму, где сумма проприетарных A, A2 и B на CF не должна превышать 2% емкости сети (см. приложение D).
5.4.6.2 Проприетарный A
| Имя группы параметров: | ПРОПРИЕТАРНЫЙ A | |
| Определение: | Проприетарный PG, который использует специфичный для назначения формат PDU, чтобы позволить производителям направлять свои проприетарные коммуникации к определенной управляющей функции назначением. | |
| Частота повторений передач: | согласно требованиям пользователя | |
| Длина данных: | от 0 до 1 785 байт (поддерживаются несколько пакетов) | |
| Страница данных: | 0 | |
| PF: | 239 | |
| PS: | DA | |
| Приоритет по умолчанию: | 6 | |
| Номер группы параметров: | 61 184 (00EF0016) | |
| Байты: | от 1 до 8 | конкретное для производителя использование (см. 5.1.3) |
Диапазоны данных для параметров, используемых этой групповой функцией: не определены ИСО.
5.4.6.3 Проприетарный A2
| Имя группы параметров: | ПРОПРИЕТАРНЫЙ A2 | |
| Определение: | Проприетарный PG, который использует формат PDU, специфичный для адреса назначения, чтобы производители могли направлять свои проприетарные коммуникации на конкретный адрес управляющей функции. | |
| Частота повторений передач: | согласно требованиям пользователей | |
| Длина данных: | от 0 до 1 785 byte (поддерживаются несколько пакетов) | |
| Страница данных: | 1 | |
| PF: | 239 | |
| PS: | DA | |
| Приоритет по умолчанию: | 6 | |
| Номер группы параметров: | 126 720 (01EF0016) | |
| Байты: | от 1 до 8 | конкретное для производителей использование (см. 5.1.3) |
Диапазоны данных для параметров, используемых этой групповой функцией: не определены ИСО.
5.4.6.4 Проприетарный B
| Имя группы параметров: | ПРОПРИЕТАРНЫЙ B | |
| Определение: | Проприетарный PG, который использует сообщение формата PDU2, чтобы позволить производителям определять содержимое поля PS (GE) по своему усмотрению. | |
| Частота повторений передач: | согласно требованиям пользователей | |
| Длина данных: | от 0 до 1 785 байт (поддерживается несколько пакетов) | |
| Страница данных: | 0 | |
| PF: | 255 | |
| PS: | GE (назначенный производителем) | |
| Приоритет по умолчанию: | 6 | |
| Номер группы параметров: | 65 280 до 65 535 (от 00FF0016 до 00FFFF16) | |
| Байты: | от 1 до 8 | использование определено производителем (см. 5.1.3) |
Диапазоны данных для параметров, используемых этой групповой функцией: Результаты использования, определенные производителем, с кодом длины данных, уникальным для каждого поставщика компонента и адреса источника. Следует соблюдать осторожность при использовании группы параметров проприетарный B (PGN = 65 280), поскольку несколько адресов источников могут использовать одно и то же значение PGN проприетарный B для разных целей.
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 не является обязательной.
Диапазоны данных для параметров, используемых этим типом сообщения:
Элемент управления, указывающий тип расширенного идентификатора:
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 байт (поддерживается несколько пакетов) | |
| Страница данных: | 0 | |
| PF: | 202 | |
| PS: | DA (конкретный или глобальный) | |
| Приоритет по умолчанию: | 6 | |
| Номер группы параметров: | 51 712 (00CA0016) | |
| Байты от 1 до 3: | a) PGN, запрошенный Request2 (см. таблицу 2 для заказа PGN) | |
| Байт 4: | b) Длина данных для сообщенного PGN, связанного с идентифицированной управляющей функцией (например, управляющая функция в байтах с 5 по 8). Значение длины представляет собой сумму этого байта, длины байтов идентификатора (то есть байтов с 5 по 8) и связанных данных PGN. Таким образом, длина составляет b + c + d. | |
| Байты от 5 до 8: | c) Идентичность функции управления, связанной с 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 до x: | d) Повторяющаяся информация для 2-го и последующих пунктов должна содержать: «Идентификатор функции управления», «Длина» и «PGN, запрошенный данными Request2» (см. Определения формата ниже.) | |
Формат a, b, c, d, b, c, d, b, c, d ...:
Пример - Для данного транспортного средства управляющая функция двигателем знает номера VIN для трактора и прицепа. Другая управляющая функция отправляет Request2, направленный в глобальный адрес назначения, запрашивая VIN с «Использовать Transfer PGN», установленным в 012. Ответ от двигателя может быть следующим:
- BAM передача Transfer PGN, сообщающего VIN трактора и VIN прицепа, или
- если запрос имел значение «Использовать Transfer PGN», равное 002, то ответом была передача BAM 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 и PDU2. Группы параметров назначаются специально для использования в формате PDU1 или PDU2. Как только формат назначен, другой формат недоступен для этой группы параметров. Формат 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 существуют три основных метода связи, надлежащее использование каждого из которых позволяет эффективно использовать доступные группы параметров:
- Формат PDU1 (PS = DA, разрешение связи с конкретным адресом назначения);
- Формат PDU2 (PS = GE);
- проприетарная коммуникация, использующая два стандартных проприетарных PGN.
Каждый из этих методов имеет соответствующее применение. Группы параметров, с конкретным адресом назначения, необходимы там, где одно и то же сообщение может быть направлено в тот или иной адрес назначения. В стандарте ИСО 11783 определено сообщение управления крутящим моментом, которое может быть отправлено двигателю. В случае более чем одного двигателя это сообщение должно быть отправлено только нужному двигателю, а конкретная группа параметров назначения требуется и назначается.
Сообщения формата PDU2 применяются в нескольких ситуациях, включая сообщения, отправленные из одного или нескольких источников в один адрес назначения, а также сообщения, отправленные из одного или нескольких источников в несколько адресов назначения. Связь PDU2 не может использоваться там, где сообщение должно быть отправлено в один или другой адрес назначения, а не в оба.
Проприетарные коммуникации обеспечиваются использованием проприетарного PGN. Различные PGN были назначены для проприетарных сообщений, не относящихся к конкретному назначению, и для проприетарных сообщений, относящихся к конкретному назначению. Это позволяет использовать две альтернативные функции:
a) конкретный источник может отправить свое проприетарное сообщение в формате PDU2 (не зависящем от назначения) с полем PS, идентифицированным по желанию пользователя;
b) использование формата PDU1 (с конкретным адресом назначения) позволяет учитывать ситуации, когда диагностический инструмент направляет свои запросы к определенному месту назначения из возможной группы контроллеров.
Пример - Двигатель использует более чем один контроллер, но должен иметь возможность выполнять диагностику, когда все его контроллеры подключены к одной сети. В этом случае проприетарный протокол должен соответствовать конкретному месту назначения.
Проприетарные сообщения полезны в двух ситуациях:
- когда это не нужно для стандартизированных коммуникаций;
- когда важно передавать конфиденциальную информацию.
Большая часть связи между контроллерами, созданными одним производителем, не требует стандартизации. Передаваемая информация, как правило, бесполезна для других контроллеров в сети. В этой ситуации можно использовать проприетарную группу параметров.
Когда предполагается назначение группы параметров, следует рассмотреть проприетарные и PDU2-форматные методы связи. Если передается несвободная информация или если информация, подлежащая передаче, не представляет общего интереса, следует использовать несвободный метод. Если информация представляет общий интерес и не требует направления сообщения на конкретную управляющую функцию, следует искать назначение формата PDU2. Наконец, если информация представляет общий интерес, но требует направления на ту или иную управляющую функцию, то необходима адресация для конкретного назначения и следует искать назначение группы параметров формата PDU1 назначения.
5.9.4 Определение поля данных
Минимизация накладных расходов на сообщения в системах на базе CAN требует полного использования поля данных (все 8 байт). За исключением очень важных по времени сообщений, соответствующие параметры должны быть сгруппированы для заполнения восьмибайтового поля данных. После этого Принципал сохраняет PGN для будущего назначения. Строгое обоснование необходимо для того, чтобы можно было определить группы параметров, которые приводят к редко используемым полям данных.
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 пакетов x 7 байт/пакет = 1 785 байт при использовании транспортного протокола.
5.10.2.3 Порядковый номер
Порядковые номера присваиваются пакетам для передачи по сети во время «пакетирования» сообщений, а затем используются при приеме пакетов для их повторной сборки в сообщение.
Порядковые номера присваиваются отдельным пакетам, начинающимся с единицы и продолжающимся последовательно до тех пор, пока все сообщение не будет «пакетировано» и передано. Пакеты должны быть отправлены последовательно в порядке возрастания, начиная с пакета 1.
Многопакетное сообщение определяется как сообщение, данные которого не помещаются в поле данных одного кадра данных 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 (см. рисунки B.1 и B.2). В случаях, когда соединение между одним и несколькими, управление потоком или замыкание не предусмотрено (см. рисунок B.3).
5.10.3.2 Многопакетная трансляция
Многопакетные сообщения могут быть не специфичными для адреса назначения, то есть они могут быть транслируемыми сообщениями. Для трансляции многопакетного сообщения управляющая функция сначала передает сообщение транслируемого оповещения (BAM). Это сообщение, которое должно быть передано по глобальному адресу назначения, представляет собой большое сообщение с предупреждением для управляющих функций в сети. Сообщение BAM содержит 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 Общие положения
Передача данных начинается после того, как отправляющая управляющая соединением функция получает сообщение о разрешении отправки. Исключением является случай, когда передача данных была результатом BAM — в этом случае сообщение о разрешении отправки не используется. Пакет передачи данных использует PGN передачи данных (см. 5.10.5), но байты данных, содержащиеся в этом пакете, применяются к PGN, объявленному в байтах с 6 по 8 сообщения запроса на передачу или сообщения транслируемой передачи. Первый байт поля данных содержит порядковый номер пакета.
5.10.3.4.2 Управление потоком соединения
В случае сообщений о назначении принимающая управляющая функция отвечает за координацию управления потоком между управляющими функциями. Если принимающая управляющая функция хочет на мгновение остановить поток данных при открытом соединении, она должна использовать сообщение о разрешении отправки, установив число отправляемых пакетов равным нулю. В случае, когда поток должен быть остановлен на некоторое количество секунд, управляющая функция приемом должна повторять передачу сообщения о разрешении отправки один раз в Th с (0,5 с), чтобы обеспечить отправляющую управляющую функцию. Связь не разорвана. Все оставшиеся битовые поля установлены в одно («Не имеет значения»).
5.10.3.5 Закрытие соединения
При отсутствии ошибок существуют два случая закрытия соединения: первый для глобального назначения и второй для конкретного назначения. В случае глобального адреса назначения никакая операция закрытия соединения не выполняется после приема самих данных (см. 5.10.4.1 и 5.10.4.5). В случае передачи по конкретному назначению и после получения последнего пакета в потоке сообщений управляющая функция приемом передает подтверждение окончания сообщения отправляющей управляющей функции сообщения. Это сигнал отправляющей управляющей функции о том, что соединение считается закрытым с помощью принимающей управляющей функции. Закрытие ACK в конце сообщения требуется для освобождения соединения для последующего использования другими управляющими функциями.
Сообщение о разрыве соединения не может быть использовано принимающими управляющими функциями в случае сообщения глобального назначения (5.10.4 и 5.10.4.5). В случае передачи по конкретному назначению либо отправляющая, либо принимающая управляющая функция могут в любой момент использовать прерывание соединения, чтобы разорвать соединение. (См. 5.10.3.3 для объяснения того, когда считается, что соединение установлено для управляющей функции отправкой и приемом.) Если, например, управляющая приемом функция определяет, что нет ресурсов, доступных для обработки сообщения, она может прервать соединение с помощью сообщения о прерывании соединения с причиной прерывания 2 (см. таблицу 8). После получения этого сообщения любой пакет сообщений, который уже был передан, отменяется.
Отказ любой из управляющих функций также может привести к закрытию соединения.
Пример 1 — Задержка получения последнего пакета более чем на T1 с, когда ожидалось больше (CTS разрешил больше).
Пример 2 — Задержка более чем T2 с после передачи CTS (сбой отправляющей управляющей функции).
Пример 3 — Отсутствие CTS или ACK в течение более чем T3 с после передачи последнего пакета (сбой принимающей управляющей функции).
Пример 4 — Отсутствие CTS в течение более T4 с после сообщения CTS (0) о том, что необходимо «держать соединение открытым».
Любой из этих примеров приводит к закрытию соединения.
Значения времени ожидания: Tr = 200 мс, Th = 500 мс, T1 = 750 мс, T2 = 1 250 мс, T3 = 1 250 мс и T4 = 1 050 мс (см. также 5.13.3 и рисунок B.1 относительно времени ожидания). Когда либо отправляющая управляющая функция, либо принимающая управляющая функция решает закрыть соединение по любой причине, включая время ожидания, она должна отправить сообщение о прерывании соединения с причиной прерывания 3 из таблицы 8.
С определениями в этом подпункте и определениями, приведенными в 5.10, можно сделать следующие наблюдения.
a) Закрытие соединения для сообщения транслируемого объявления включает в себя следующее. Соединение считается закрытым,
i) получает последний пакет передачи данных или
ii) истекло время ожидания соединения T1.
b) Закрытие соединения для сообщений «Запрос на отправку „/“Разрешение отправки» включает следующее. Соединение считается закрытым,
i) получает TP.CM_EndOfMsgACK по завершении передачи данных для всего PGN;
ii) отправляет прерывание соединения по любой причине (например, из-за превышения времени ожидания T3 или T4) или
iii) получает разрыв соединения;
i) отправляет TP.CM_EndOfMsgACK по завершении передачи данных для всего PGN;
ii) получает разрыв соединения или
iii) отправляет прерывание соединения по любой причине (включая раннюю остановку сеанса, если это необходимо, для времени ожидания соединения T1 или T2 и т.д.).
5.10.4 Транспортный протокол — Сообщения управления соединением (TP.CM)
5.10.4.1 Определение сообщения управления соединением транспортного протокола
Этот тип сообщения используется для инициирования и закрытия соединений, а также для управления потоком. Транспортный протокол предоставляет следующие пять сообщений управления соединением транспортного протокола: запрос режима соединения для отправки, сброс режима соединения для отправки, подтверждение окончания сообщения, прерывание соединения и сообщение о транслируемой рассылке. Формат этого сообщения показан ниже в определении группы параметров для транспортного протокола — Управление соединениями.
Диапазон данных, пользующихся этой групповой функцией:
Примечание — ноль в графе «количество пакетов, которые могут быть отправлены» означает приостановку соединения (см. 5.10.3.4.1).
Запрос на отправку режима соединения (TP.CM_RTS): конкретный адрес назначения
Режим соединения разрешения отправки (TP.CM_CTS): конкретный адрес назначения
Подтверждение конца сообщения (TP.CM_EndofMsgACK): конкретный адрес назначения
Разрыв соединения (TP.Conn_Abort): конкретный адрес назначения
Трансляция сообщения (TP.CM_BAM): глобальный адрес назначения
5.10.4.2 Транспортный протокол Режим Соединения Запрос На Отправку (TP.CM_RTS)
Сообщение TP.CM_RTS сообщает управляющей функции, что другая управляющая функция в сети желает открыть с ней виртуальное соединение. TP.CM_RTS — это сообщение с полем SA, установленным для отправляющей управляющей функции, DA, установленным для предполагаемой управляющей функции получением большого сообщения, и остальными полями, установленными соответствующим образом для отправляемого PGN. Байт 5 этого сообщения позволяет отправляющей управляющей функции ограничить количество пакетов, указанных в сообщении о разрешении отправки (см. рисунки B.4 и B.5) принимающей управляющей функции. Когда принимающая управляющая функция соответствует этому пределу, она гарантирует, что отправляющая управляющая функция всегда может ретранслировать пакеты, которые по какой-либо причине принимающая управляющая функция не получила. Если несколько PTC получены от одного и того же SA для одного и того же PGN, то следует действовать по самому последнему PTC и отказаться от предыдущего PTC. В этом конкретном случае сообщение об отмене не должно быть отправлено для оставленного 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, запрашивающую повторную передачу, начиная с отсутствующего пакета.
- Пропущенный пакет(ы), включая последний пакет, приводит к превышению времени ожидания T1. В этом случае принимающая управляющая функция принимает решение либо отправить CTS, либо прервать соединение по причине 4 из таблицы 8. См. рисунок B.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 мс. После отправки или получения сообщения о разрыве соединения все полученные связанные пакеты данных должны игнорироваться. TP.Conn_Abort передается отправляющей управляющей функцией или принимающей управляющей функцией.
5.10.4.6 Предупреждение о трансляции (TP.CM_BAM)
TP.CM_BAM используется для информирования всех управляющих функций сети о том, что должно быть передано большое сообщение. Он определяет группу параметров и количество байтов для отправки. После передачи сообщения TP.CM_BAM отправляются сообщения транспортного протокола, содержащие «пакетированные» транслируемые данные.
TP.CM_BAM передается только отправляющей управляющей функцией.
5.10.5 Транспортный протокол — сообщения передачи данных (TP.DT)
Сообщение TP.DT используется для передачи данных, связанных с группой параметров. Сообщение TP.DT является отдельным пакетом передачи нескольких пакетов сообщений. Например, если большое сообщение должно было быть разделено на пять пакетов для передачи, тогда было бы пять сообщений TP.DT. (Примеры использования сообщений TP.DT см. в Приложении B). Формат этого сообщения показан в следующем определении группы параметров.
TP.DT передается только отправляющей управляющей функцией.
Диапазон данных, использующийся этим типом сообщений:
| Порядковый номер: | от 1 до 255 (1 байт) | |
| Байт: | 1 | Порядковый номер |
| Байты: | от 2 до 8 | «Пакетированные» данные (7 байт) |
Последний пакет из группы параметров из нескольких пакетов может потребовать менее 8 байтов. Дополнительные байты должны быть заполнены FF16.
5.10.6 Ограничения соединений транспортного протокола
5.10.6.1 Общие положения
Если управляющая функция не может обработать другой сеанс, то она должна отклонить инициации соединения, которые выполняются другими управляющими функциями. RTS для другого PGN из того же SA в тот же адрес назначения, что и существующий сеанс, также должен быть отклонен. В любом случае новый запрошенный сеанс следует отклонить, отправив прерывание соединения с причиной прерывания 1 из таблицы 8. Это позволяет устройству, желающему установить соединение, перейти к новому соединению, не дожидаясь истечения времени ожидания.
5.10.6.2 Количество и тип соединений, которые должна поддерживать управляющая функция
Каждая управляющая функция в сети может одновременно инициировать одну передачу соединения транспортного протокола для конкретного адреса назначения с данным адресом назначения. Это связано с тем, что TP.DT содержит только SA и DA, а не PGN передаваемых данных. Сеанс расширенного транспортного протокола может быть открыт параллельно с соединением транспортного протокола.
Только один многопакетный BAM (т.е. глобальный адрес назначения) может быть отправлен от отправляющей управляющей функции в данный момент времени. Это связано с тем, что TP.DT не содержит фактического PGN или идентификатора соединения. Однако принимающие управляющей функции должны признавать, что несколько многопакетных сообщений могут быть получены, перемежаясь друг с другом, от различных отправляющих управляющих функций (т.е. адресов источников).
Управляющая функция также должна быть способна поддерживать одну сессию RTS/CTS и одну сессию BAM одновременно от одного и того же SA. Поэтому принимающая управляющая функция должна использовать адрес назначения двух сообщений транспортного протокола, чтобы обеспечить их надлежащее разделение. Одно из сообщений транспортного протокола имеет глобальный, а другое — конкретный DA. DA должен использоваться для различения различий между ними, поскольку TP.DT не содержит ни фактического PGN, ни идентификатора соединения.
Независимо от того, может ли управляющая функция поддерживать несколько одновременных сеансов транспортного протокола (RTS/CTS и/или BAM), она должна гарантировать, что сообщения TP.DT/ETP.DT из одной и той же SA, но имеющие разные DA, могут различаться. Принимающие управляющие функции должны использовать DA и SA для обеспечения правильности данных для сообщений. Передатчик параллельных сеансов TP/ETP должен знать, что получатель может поставить один или оба сеанса на удержание в течение любого периода времени (см. 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 определяет требование, которое реализуется с помощью сообщения ETP.CM_CTS).
5.11.2 Общие положения
Сообщения, длина которых превышает 1785 байт, слишком велики, чтобы поместиться в сеанс транспортного протокола. Следовательно, они разбиваются на несколько меньших пакетов, и эти пакеты передаются в отдельных классических кадрах данных CAN с управлением соединениями этих кадров, что позволяет принимающей управляющей функции повторно собирать сообщение в порядке порядкового номера.
5.11.3 Пакеты сообщений
Максимальное количество пакетов, которые могут быть отправлены в одном соединении с расширенным транспортным протоколом, ограничено смещением расширенного пакета данных (3 байта). Это дает максимальный размер сообщения 224 — 1 пакет x 7 байт/пакет = 117 440 505 байт для расширенного транспортного протокола.
5.11.4 Расширенный транспортный протокол — Управление соединением
5.11.4.1 Общие положения
Расширенные функции транспортного протокола требуются, когда управляющая функция требует передачи сообщений длиннее, чем длина транспортного протокола 1785 байт.
Расширенный транспортный протокол использует пять управляющих байтов для расширенных запросов на соединение и ответов на сообщения. Эти управляющие байты и сообщения следующие.
Максимальное количество байтов, которое может быть отправлено в одном соединении с расширенным транспортным протоколом сообщений, составляет 117 440 505 байт.
Последовательность сообщений показана на рисунке 8. Отправляющая управляющая функция отправляет расширенный запрос сообщения для отправки (ETP.CM_RTS) в принимающую управляющую функцию. Принимающая управляющая функция отправляет ETP.CM_CTS обратно отправляющей управляющую функцию с количеством пакетов, которые может отправлять отправляющая управляющая функция, которые могут быть между 0 и 255, и номером пакета исходного пакета, который нужно отправить для первого сеанса передачи данных транспортного протокола. Установка количества пакетов для отправки на ноль удерживает соединение открытым между принимающей и отправляющей управляющей функцией. См. 5.10.4.3.
Затем отправляющая управляющая функция отправляет расширенное смещение пакета данных (ETP.CM_DPO), за которым следуют сообщения передачи данных расширенного транспортного протокола с необходимым количеством пакетов данных. Затем она ожидает следующего сообщения ETP.CM_CTS от принимающей управляющей функции, а затем повторяет со следующим сообщением расширенного смещения пакета данных и требуемым количеством сообщений передачи данных расширенного транспортного протокола. Фактическая последовательность каждого пакета в расширенном сообщении равна последнему принятому смещению расширенного пакета данных, добавленному к порядковому номеру в сообщении передачи данных расширенного транспортного протокола.
Рисунок 8 — Последовательность расширенного транспортного сообщения
Для расширенного транспортного протокола используются такие же интервалы времени, как для транспортного протокола.
5.11.5 Расширенный транспортный протокол — Сообщения управления соединением (ETP.CM)
5.11.5.1 Общие положения
В сообщениях управления соединением расширенного транспортного протокола используется PGN, отличный от используемого для транспортного протокола (см. 5.10.4).
5.11.5.2 Определение сообщения управления соединением
Диапазоны данных для параметров, используемых этой групповой функцией:
Расширенный режим подключения RTS (ETP.CM_RTS): конкретный адрес назначения
Расширенный режим подключения CTS (ETP.CM_CTS): конкретный адрес назначения
Примечание 1 — Количество отправляемых пакетов + Следующий пакет для отправки — 1 не может превышать 16 777 215.
Примечание 2 — Ноль в байте 2 означает режим удержания соединения (см. 5.11.3.1).
Расширенный режим подключения Смещение пакета данных (ETP.CM_DPO): конкретный адрес назначения
Примечание 3 — n + порядковый номер любого пакета не может превышать 16 777 215.
Байт 2 ETP.CM_DPO должен быть меньше или равен байту 2 ETP.CM_CTS. Если байт 2 меньше байта 2 сообщения ETP.CM_CTS, то получатель должен внести необходимые корректировки в свой сеанс, чтобы принять определенный блок данных сообщением ETP.CM_DPO и последующими пакетами ETP.DT.
Расширенное Подтверждение окончания сообщения (ETP.CM_EOMA): конкретный адрес назначения
Расширенный Разрыв соединения (ETP.Conn_Abort): конкретный адрес назначения
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 Расширенное Подтверждение окончания сообщения (ETP.CM_EOMA)
Сообщение ETP.CM_EOMA передается от принимающей управляющей функции большого сообщения к его отправляющей управляющей функции, что указывает на то, что все расширенное сообщение было получено и правильно собрано.
5.11.5.7 Расширенный Разрыв соединения (ETP.Conn_Abort)
Сообщение ETP.Conn_Abort используется любой из управляющих функций, участвующих в виртуальном соединении, для закрытия соединения без завершения передачи сообщения.
После получения сообщения с запросом на отправку расширенного режима соединения управляющая функция должна определить, достаточно ли ресурсов для обработки сообщения, для которого требуется это соединение — например, если управляющая функция должна получить память из системы, но ее может быть недостаточно, чтобы принять все сообщения, или управляющая функция просто слишком занята, выполняя другие задачи, чтобы тратить циклы процессора на обработку большого сообщения. Управляющая функция может либо ответить количеством отправляемых пакетов, равным 0, что удерживает соединение открытым между отправляющей управляющей функцией и принимающей управляющей функцией, либо отправить сообщение о разрыве расширенного соединения, чтобы закрыть соединение.
Если по какой-либо причине отправляющая или принимающая управляющая функция принимает решение закрыть соединение до завершения передачи данных, включая время ожидания, она должна отправить расширенное сообщение о разрыве соединения с указанием соответствующей причины разрыва соединения. См. таблицу 9. Если определена причина разрыва соединения, которая не указана в таблице 9, используется код 254.
Причины разрыва соединения расширенного транспортного протокола
5.11.6 Расширенный транспортный протокол — Сообщения Передачи данных (ETP.DT)
Сообщение ETP.DT используется для передачи данных, связанных с группой параметров. Сообщение ETP.DT является отдельным пакетом передачи нескольких пакетов сообщений. Например, если большое сообщение должно было быть разделено на 300 пакетов для передачи, тогда было бы 300 сообщений ETP.DT. В сообщениях передачи данных расширенного транспортного протокола используется PGN, отличный от используемого для транспортного протокола (см. 5.10.5).
Диапазоны данных для параметров, используемых этим типом сообщения:
Последний пакет из группы параметров многопакетного сообщения может содержать менее 8 байт. В таком случае остальные байты следует передавать как FF16.
5.11.7 Ограничения соединений Расширенного транспортного протокола
Как определено в 5.10.6.2, передатчик параллельных сеансов TP/ETP должен знать, что приемник может приостановить один или оба сеанса в течение любого периода времени (см. 5.11.5.3), и поэтому невозможно предсказать, какая из сессий будет первой, чтобы завершить.
5.12 Требования к обработке PDU
Обработка PDU требует следующих специфических процедур. Предлагаемая последовательность для интерпретации PDU описана в Приложении A. В Приложении C приведены примеры типов сообщений ИСО 11783 и используемых форматов PDU.
Контроллеры должны иметь возможность обрабатывать сообщения канала передачи данных достаточно быстро, чтобы предотвратить потерю сообщений, когда канал передачи данных используется на 100%. Это также означает, что в ситуациях с низким уровнем использования, когда имеются идущие друг за другом сообщения, каждый контроллер должен иметь возможность обрабатывать сообщения достаточно быстро, чтобы не потерять сообщения из-за их последовательно идущего положения. Достаточно быстрая обработка сообщений не означает, что сообщение должно быть немедленно сгенерировано, но новое сообщение не должно выходить за пределы предыдущих сообщений.
5.13 Замечания по применению
5.13.1 Высокая скорость передачи данных
Данные, которые должны обновляться с высокой скоростью и которые имеют жесткие требования к задержке, должны, по возможности, позволять использовать аппаратную фильтрацию сообщений.
5.13.2 Планирование запроса
Планирование запроса должно быть отменено, если информация, которая готовится к запросу, получена до отправки запроса. То есть если информация получена за 50 мс до планирования запроса, запрос не должен выдаваться. Группы параметров не должны запрашиваться, если их рекомендуется транслировать в сеть. Исключения могут возникнуть, когда рекомендуемое время трансляции превышает особый случай.
5.13.3 Время отклика контроллера и время ожидания по умолчанию
Все контроллеры, когда требуется предоставить ответ, должны сделать это в течение 0,20 с (Tr). Все контроллеры, ожидающие ответа, должны подождать не менее 1,25 с (T3), прежде чем сдаться или повторить попытку. Эти времена гарантируют, что любые задержки из-за доступа к шине или пересылки сообщений через мосты не приводят к нежелательным превышениям времени ожидания. Различные значения времени могут быть использованы для конкретных приложений, когда это необходимо. Например, ответ 20 мс можно ожидать для высокоскоростных управляющих сообщений. Переупорядочение любых буферизованных сообщений может быть необходимо для достижения более быстрого ответа. Нет ограничений на минимальное время ответа.
Время между пакетами многопакетного сообщения, направленного в конкретный адрес назначения, составляет от 0 мс до 200 мс. Это означает, что могут возникать взаимные сообщения и они могут содержать один и тот же идентификатор. Механизм CTS может использоваться для обеспечения заданного промежутка времени между пакетами (управление потоком). Требуемый интервал времени между пакетами многопакетного широковещательного сообщения составляет от 10 мс до 200 мс. Минимальное время 10 мс гарантирует, что принимающая управляющая функция успеет получить сообщение от оборудования CAN. Принимающая управляющая функция должна использовать время ожидания (то есть T1), равное 750 мс. Это обеспечивает время ожидания, превышающее максимальный интервал передачи в 200 мс.
Пример - Использование синхронизации 1,25 с (T3).
a) Максимальное время прямой пересылки в пределах моста составляет 50 мс. Общее количество мостов равно 10 (то есть один трактор + пять прицепов + четыре тележки = 10 мостов). Следовательно, общая задержка в сети составляет 500 мс в одном направлении.
b) Количество повторных запросов равно двум (всего — три запроса), это относится к ситуации, когда CTS используется для запроса повторной передачи пакета(ов) данных. Если достигнут предел запроса на повторную передачу, то разрыв соединения должен быть отправлен с причиной разрыва 5 из таблицы 8.
c) Запас для времени ожидания составляет 50 мс.
На рисунках B.1 и B.3 показаны определенные временные требования. На рисунке B.1 временные числа рассчитаны исходя из наименьшего количества мостов, то есть 10 мостов. Значения времени ожидания для принимающих управляющих функций определяются как значение времени, в то время как исходные требования к управляющим функциям указываются как меньшее или равное значению времени.
Примечание - Отправляющая и принимающая управляющие функции имеют свои требования к передатчику и приемнику.
5.13.4 Требуемые ответы
Ответ на глобальный запрос требуется от всех управляющих функций, которые используют запрошенную группу параметров, даже от запрашивающего. Подтверждения не допускаются для глобальных запросов.
Управляющая функция, которая использует глобальный DA (255) для запроса (например, «запрос адреса»), сама должна отправить ответ, если она запросила данные. Это требование установлено, поскольку все управляющие функции должны реагировать. Если управляющая функция, выдающая запрос, не отвечает, то другие управляющие сетью функции могут определить неверный вывод о запрашиваемой информации.
5.13.5 Передача PGN в конкретные или глобальные адреса назначения
Большую часть времени желательно отправлять периодически транслируемую PGN в глобальный адрес назначения.
5.13.6 Рекомендуемое количество пакетов CTS
Во время нормальной работы орудия рекомендуется, чтобы максимальное количество пакетов, которое может быть отправлено CTS, было установлено равным 16.
ОБРАБОТКА PDU ПО ИСО 11783 — ТИПИЧНАЯ ПРОЦЕДУРА ПРИЕМА
Примечание 1 — Когда микропроцессор получает сообщение через CAN IC, выполняется несколько тестов, чтобы проанализировать его и определить, где и когда оно должно храниться. Три приоритетных бита используются только для арбитража шины и поэтому не нужны (не используются) принимающей управляющей функцией.
Примечание 2 — Данный контроллер может иметь более одного адреса, если он выполняет несколько функций.
ПОСЛЕДОВАТЕЛЬНОСТИ ПЕРЕДАЧИ ТРАНСПОРТНОГО ПРОТОКОЛА — ПРИМЕРЫ ПОДКЛЮЧЕНИЯ РЕЖИМА ПЕРЕДАЧИ ДАННЫХ
При нормальных условиях поток передачи данных соответствует рисунку B.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 байтов.
Передача сообщений в случае ошибки соединения показана на рисунке B.2. Сообщение TP.CM_RTS передается и получает требуемый ответ, затем данные теряются на этапе передачи данных.
В этой ситуации запрос на отправку отправляется так же, как и в предыдущем примере. Первые два пакета передаются, но пакет номер два не прошел контрольную сумму или был ошибочно распознан принимающей управляющей функцией. Принимающая управляющая функция затем передает TP.CM_CTS, указывая, что требуется передать один пакет, и что требуемым пакетом является пакет номер 2. Отправляющая управляющая функция выполняет передачу пакета номер 2. Затем принимающая управляющая функция передает CTS, указывая, что требуется передать один пакет, и что требуемые пакеты начинаются с пакета номер 3. Это сообщение TP.CM_CTS является подтверждением того, что пакеты 1 и 2 были приняты правильно. Как только последний пакет принят правильно, принимающая управляющая функция передает сообщение TP.EndOfMsgACK, сигнализируя, что все сообщение было принято правильно.
В ситуации, показанной на рисунке B.3, управляющая функция указывает сети, что она собирается передать многопакетное сообщение, используя службы транспортного протокола. В этом примере PGN 65 260, идентификация трактора транслируется в сеть. Отправляющая управляющая функция сначала передает сообщение TP.CM_BAM, а затем пакеты данных. Подтверждение не выполняется ни одной из принимающих управляющих функций.
На рисунке B.4 отправляющая управляющая функция использует параметр Максимальное количество пакетов, чтобы ограничить количество пакетов, которые получает принимающая функция и которые должны быть переданы. В этом примере обе управляющие функции поддерживают параметр «Максимальное количество пакетов».
На рисунке B.5 показана ситуация, когда отправляющая управляющая функция поддерживает параметр RTS «Максимальное количество пакетов», а принимающая функция не поддерживает. В этой ситуации отправляющая управляющая функция должна соответствовать ограничениям CTS принимающей управляющей функции. В этом примере отправляющая управляющая функция должна будет отправлять семь пакетов передачи данных, несмотря на то, что предпочтительно отправлять не более пяти.
ВНИМАНИЕ — В этом примере, если принимающая управляющая функция должна была отправить CTS для пакета 1 после передачи данных пакета 7, возможно, что отправляющая управляющая функция должна была бы повторно вычислить информацию, и, следовательно, вторая передача пакета 1 могла бы содержать разные данные из исходного пакета 1, в зависимости от типа данных, содержащихся в PGN. Например, PGN 65 227 имеет динамические данные и может привести к тому, что пакет 1 будет отличаться, в то время как PGN, такой как 65 242, имеет статические данные и не приведет к тому, что пакет 1 будет отличаться при его второй передаче данных.
На рисунке B.6 показан случай, когда отсутствует последний пакет в группе CTS. Принимающая управляющая функция отправляет CTS в попытке избежать прерывания сеанса.
Рисунок B.7 является примером случая CTS после истечения времени ожидания. В примере управляющей функции с медленной инициацией (левая сторона) отправляющая управляющая функция отправляет «пакет CTS» из 12 пакетов, но CTS повторной передачи принимающей функции приходит до того, как отправляющая управляющая функция отправляет последний пакет данных. Отправляющая управляющая функция прерывает сеанс с причиной отмены 4. Это возможный пример, когда повторная передача CTS не позволяет избежать прерывания сеанса. В примере функции с быстрой инициацией (правая сторона) повторная передача CTS принимающей управляющей функцией поступает после того, как отправляющая управляющая функция отправляет последний пакет данных и до истечения времени ожидания T3. Это пример, в котором отправляющая управляющая функция может принимать CTS и не прерывать сеанс.
Рисунок B.1 — Передача данных без ошибок
Рисунок B.2 — Передача данных с ошибкой
Рисунок B.3 — Трансляция данных
Рисунок B.4 — Передача данных с использованием максимального количества пакетов RTS
Рисунок B.5 — Передача данных не в состоянии использовать максимальное количество пакетов RTS
Рисунок B.6 — Отправка CTS получающей управляющей функцией по истечении времени ожидания для предотвращения прерывания сеанса
Рисунок B.7 — Примеры реакции отправляющей управляющей функции реакции на ретрансляцию CTS
В данном примере показано, как двигатель обычно выполняет следующие действия.
1 ТРАНСЛЯЦИЯ/ОТВЕТ/ПОДТВЕРЖДЕНИЕ ПОЛУЧЕНИЯ
Отправка серийного номера двигателя [PGN ID компонента = 65 259 (00FEEB16)].
2 ЗАПРОС НА КОНКРЕТНЫЙ АДРЕС (PGN 59 904)
Получение запроса серийного номера двигателя. Отправленное сообщение является либо ОТВЕТОМ с данными, либо ОТРИЦАТЕЛЬНЫМ ПОДТВЕРЖДЕНИЕМ ПОЛУЧЕНИЯ. См. пример для пункта 4 ниже.
Получение глобального запроса на серийный номер двигателя. Сообщение, отправленное обратно, является ОТВЕТОМ от определенной управляющей функции, которая имеет данные. Подтверждения ответа не используются в глобальных запросах.
Для некоторых команд является желательным получить конкретное подтверждение того, что задача была выполнена. В этом случае сообщение может быть отправлено обратно либо как ACK = КОМАНДА ЗАВЕРШЕНА, либо как NACK = КОМАНДА НЕ МОЖЕТ БЫТЬ ЗАВЕРШЕНА. В приведенном ниже примере «CF» используется в качестве команды, подтвержденной ACK или NACK.
Отправка сообщения 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 |
| 2A | ГЛОБАЛЬНЫЙ ЗАПРОС | 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 |
| или | ДРУГОЕ (См. примечание) |
Примечание - Команды всегда имеют механизм подтверждения того, было ли действие успешным или нет. Сообщение подтверждения не требуется, если доступно другое средство. Это помогает минимизировать загруженность шины. Например, команда изменения крутящего момента двигателя может быть подтверждена путем просмотра битов режима крутящего момента, а также значения крутящего момента, поступающего от двигателя.
ИСПОЛЬЗОВАНИЕ ПОЛОСЫ ПРОПУСКАНИЯ СЕТИ
В открытой системе, такой как ИСО 11783, использование полосы пропускания данной сети CAN очень важно. Требования к обмену сообщениями могут превышать пропускную способность сети, если не будут тщательно продуманы. Для оптимизации использования полосы пропускания следует:
a) ограничить использования проприетарных PG и сообщений CBFF;
b) ограничить частоту периодических сообщений настолько, насколько это практически возможно;
c) использовать приоритет PG по умолчанию.
Следующие меры настоятельно рекомендуются.
- Использование проприетарных сообщений во время нормальной работы должно быть сведено к минимуму; сумма проприетарных A, A2 и B не должна превышать 2% пропускной способности сети.
- Сообщения CBFF могут сосуществовать с сообщениями CEFF, но рекомендуется изолировать трафик CBFF в подсети, чтобы сохранить пропускную способность сети CEFF ИСО 11783.
- Приоритет по умолчанию следует классифицировать и применять в соответствии с таблицей D.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 — идентичные стандарты. | ||
БИБЛИОГРАФИЯ
| УДК 631.3:006.354 | ОКС 65.060.01 |
| Ключевые слова: Тракторы и машины сельскохозяйственные; последовательная сеть управления и передачи данных; уровень канала передачи данных | |