ГОСТ Р ИСО 11783-10-2021 Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 10. Обмен данными между контроллером задач и информационной системой управления

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

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


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


ГОСТР

ИСО 11783-10— 2021


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

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

Часть 10

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

(13011783-10:2015, IDT)

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

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

Предисловие

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

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

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

  • 4 Настоящий стандарт идентичен международному стандарту ИСО 11783-10:2015 «Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 10. Обмен данными между контроллером задач и информационной системой управления» (ISO 11783-10:2015 «Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 10: Task controller and management information system data interchange», IDT).

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

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

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

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

© ISO, 2015

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

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

Содержание

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

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

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

  • 4 Сокращения

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

  • 5.1 Управление задачами

  • 5.2 Управление задачами на компьютере FMIS

  • 5.3 Предварительный выбор и назначение устройств

  • 5.4 Драйвер интерфейса контроллера задач

  • 5.5 Пользовательский интерфейс контроллера задач

  • 5.6 Функция регистратора данных

  • 6 Требования к контроллеру задач

  • 6.1 Выбор и выполнение задачи

  • 6.2 Регистрация времени и положения

  • 6.3 Регистрация параметров из групп параметров

  • 6.4 Регистрация событий задачи

  • 6.5 Выбор языка, форматов и единиц измерения

  • 6.6 Управление подключениями

  • 6.7 Количество контроллеров задач

  • 6.7.1 Инициализация клиента в сетях с несколькими контроллерами задач

  • 6.8 Обмен данными в сети

  • 7 Требования к регистратору данных

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

  • 7.2 Управление соединениями

  • 7.3 Измерения и общие значения

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

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

  • 8.2 Расширяемый язык разметки

  • 8.3 Расширяемое определение схемы

  • 8.4 Определение XML Schema

  • 8.5 XML-файлы передачи данных

  • 8.6 Файлы передачи двоичных данных

  • 8.7 Пул объектов дескриптора устройства

Приложение А (обязательное) Объекты дескриптора устройства

Приложение В (обязательное) Определения сообщений

Приложение С (обязательное) Диаграмма взаимосвязи XML-элементов

Приложение D (обязательное) XML-элементы и атрибуты

Приложение Е (обязательное) Предопределенные привязки ИСО-11783

Приложение F (обязательное) Функционал ТС и определения пула объектов дескриптора устройства

Приложение G (обязательное) Регистрация времени на основе задач

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

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

Введение

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

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

ГОСТ Р ИСО 11783-10—2021

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

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

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

Часть 10

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

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

  • Part 10. Task controller and management information system data interchange

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

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

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

  • 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 11783-11, Tractors and machinery for agriculture and forestry — Serial control and communications data network — Part 11: Mobile data element dictionary (Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 11. Словарь элементов мобильных данных)

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

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

ISO 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling (Дорожные транспортные средства. Контроллерная сеть (CAN). Часть 1. Уровень канала передачи данных и физическая сигнализация)

ISO/IEC 10646, Universal Coded Character Set — UCS (Информационные технологии — Универсальный набор кодированных символов)

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

В настоящем стандарте применены термины и определения по ИСО 11783-1, а также следующие термины с соответствующими определениями:

  • 3.1 клиент (client): Управляющая функция (CF), которая устанавливает соединение с контроллером задач (ТС) или регистратором данных (DL) и предоставляет данные для регистрации данных с помощью DL или ТС и/или принимает команды управления от ТС.

Примечание 1 — Этот термин был введен в версии 4 для замены термина рабочего набора для CF, который подключается к ТС или DL. Концепция многоэлементного рабочего набора не применяется к клиентам ТС или DL. Связь между ТС или DL и их клиентами ограничивается передачей сообщений между ТС или DL и мастером рабочего набора.

  • 3.2 данные кодирования (coding data): Данные, которые изменяются нечасто, такие как данные о машине или химические данные, или данные, на которые ссылается задача, с целью административного распределения задач.

  • 3.3 объект словаря данных (data dictionary entity): Описание идентификатора словаря данных, определение, диапазон значений, разрешение значений и характеристика единиц измерения, используемые переменными данных процесса.

  • 3.4 регистратор данных; DL (data logger): Управляющая функция (CF), определенная специально для выполнения функционала регистрации данных.

  • 3.5 клиент регистратора данных (data logger client): CF, которая устанавливает соединение с регистратором данных (DL) и предоставляет данные DL для регистрации данных.

  • 3.6 набор файлов передачи данных (data transfer file set): Набор файлов в формате расширяемого языка разметки и двоичных форматов, которые используются для передачи данных между информационной системой управления фермой и контроллером задач сети ИСО 11783.

  • 3.7 пул объектов дескриптора устройства; DDOP (device descriptor object pool): Набор связанных с устройством объектов и их взаимосвязей, которые вместе описывают функционал и структуру устройства для целей управления задачами и регистрации данных.

  • 3.8 элемент устройства (device element): Любой адресуемый элемент на устройстве.

Пример — Форсунка на штанге опрыскивателя, где форсунка имеет индивидуально адресуемые переменные данных процесса.

  • 3.9 поле (field): Область земли, находящаяся под управлением фермера, которая представлена либо отдельным участком поля, либо совокупностью нескольких участков.

Примечание 1 — Поле имеет значение только в информационной системе управления фермой для целей управления бизнесом и не обязательно связано с единственной культурой.

  • 3.10 ячейка сетки (grid cell): Прямоугольные области, определяемые сеткой, наложенной на участок поля.

  • 3.11 компьютерный шлюз управления (management computer gateway): CF, которая взаимодействует с компьютерной системой управления и с сетью ИСО 11783.

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

  • 3.12 участок поля (partfield): Область, характеризуемая выращиванием только одной сельскохозяйственной культуры.

Примечание 1 — Участок поля — это XML-элемент, которому назначаются задачи для достижения наибольшей степени детализации.

  • 3.13 полигон (polygon): Плоская поверхность, определяемая одной внешней границей и нулем или более внутренних границ.

Примечание 1 — Каждая внутренняя граница описывает отверстие на поверхности.

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

  • 3.14 переменная данных процесса (process data variable): Элемент информации, имеющий значение, которое описывает состояние процесса.

Примечание 1 — Переменные данных процесса состоят из атрибутов (диапазон, разрешение и единицы измерения), определенных в словаре данных.

  • 3.15 источник заданного значения (setpoint value source): CF, которая может определить заданное значение во время выполнения задачи для использования другой CF и содержит один или несколько объектов данных процесса устройства с атрибутом свойства, установленным в значение «источник управления».

  • 3.16 пользователь заданного значения (setpoint value user): CF, которая принимает значение заданного значения от ТС или другого источника для изменения его производительности в реальном времени, например управления расходом, и содержит один или несколько объектов данных процесса обработки данных устройства с атрибутом свойства, установленным в значение «установлено».

  • 3.17 клиент контроллера задач (task controller client): CF, которая устанавливает соединение с контроллером задач ТС и предоставляет данные для регистрации данных и/или принимает управляющие команды от ТС.

  • 3.18 номер контроллера задач (task controller number): Идентификационный номер, полученный от экземпляра функции контроллера задач (ТС).

  • 3.19 XML-элемент (XML element): Представление данных объекта домена, состоящее из, как минимум, открывающего тега, набора атрибутов и закрывающего тега.

  • 4 Сокращения

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

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

    • 5.1 Управление задачами

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

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

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

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

Управление задачами имеет следующую последовательность действий:

  • а) Планирование полевых задач и ведение данных кодирования с использованием программного обеспечения компьютера FMIS под управлением фермерами или подрядчиками, какописано в пункте 5.2.

  • Ь) Преобразование данных задачи в формат XML.

  • с) Присвоение данных задачи, созданных программным обеспечением для планирования, данным, необходимым орудию или системе датчиков для выполнения запланированных задач. Этот шаг является необязательным.

  • d) Передача данных задачи из системы FMIS в ТС системы MICS, как описано в пункте 5.4.

  • е) ТС использует данные задачи для передачи сообщений данных процесса в электронный блок управления (ECU)орудия.

  • f) ТС собирает данные в соответствии с триггерами регистрации данных DataLogTrigger, указанными в данных задачи.

д) Передача собранных данных в FMIS. Собранные данные могут быть в формате XML или в проприетарном формате. При использовании проприетарного формата этот шаг включает в себя преобразование проприетарного формата в формат XML.

h) Чтение XML-файлов и преобразование в формат FMIS для хранения и оценки данных.

На рисунке 1 показаны интерфейсы между программным обеспечением компьютера FMIS и блоков ECU, смонтированных на орудии с конфигурацией по ИСО 11783.

  • 5.2 Управление задачами на компьютере FMIS

Управление задачами — это часть FMIS, отвечающая за планирование и оценку полевых работ. Задачи указывают, что, где, как, кем и когда планируется выполняться работа.

Объем данных, передаваемых между FMIS и MICS, предписывается административными требованиями фермерского хозяйства. При регистрации только полевых работ управление задачами может быть использовано для записи данных в рабочий журнал. Для этого из FMIS в MICS необходимо передавать только данные кодирования, а задачи создаются в MICS путем выбора задействованных ресурсов. В этом случае задачи содержатся только в наборе файлов передачи данных из MICS в FMIS. На предприятиях, где задачи планируются в FMIS, они будут включены вместе сданными кодирования в набор файлов передачи данных из FMIS в MICS. Эти запланированные задачи могут варьироваться от простого планового распределения ресурсов до географических сведений для привязанных к местоположению полевых операций.

  • 5.3 Предварительный выбор и назначение устройств

Любое клиентское устройство в мобильной системе может быть идентифицировано уникальным образом по NAME (имени) его CF. Для целей FMIS ИМЯ CF клиента должно быть уникальным во всем мире. Это подразумевает, что производитель устройства несет ответственность за то, чтобы идентификационный номер в сочетании с другими полями в ИМЕНИ однозначно идентифицировал устройство.

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

XML атрибут ClientNAMEValue содержит восьмибайтное NAME контрольной функции, как она определена в ИСО 11783-5. Для определения устройства в мобильной сети необходимо указать не все части NAME, а только определенные элементы NAME. Те части ClientNAMEValue, которые содержат информацию, используемую в мобильной системе для выбора подходящего устройства, маскируются битовой структурой, хранящейся в атрибуте XML, ClientNAMEMask. Все различные комбинации элементов структуры NAME могут быть отмечены как действительные для выбора устройства (логическое AND). На FMIS эти маски могут быть закодированы как символы. После того как в задаче на FMIS установлена информация о предварительном выборе, она не перезаписывается на мобильной системе, так как устройство, используемое при обработке задания на мобильной системе, хранится в виде XML-атрибута DeviceldRef.

  • 5.4 Драйвер интерфейса контроллера задач

После генерации файлов интерфейса на компьютере фермы активируется драйвер ТС производителя. Этот драйвер отвечает за передачу данных в ТС, который является частью MICS, используя его собственный формат данных или формат XML ИСО 11783-10 и носитель данных, такой как карта памяти любого типа или радиоканал. Перевод данных из набора файлов передачи данных, установленного в сообщениях в сети ИСО 11783, а также тип передачи между мобильной системой и FMIS не стандартизованы в рамках настоящего международного стандарта. Для создания данных заданного значения для конкретного агрегата этот драйвер может добавлять и использовать данные дескриптора устройства, предоставляемые производителями.

Рисунок 1 — Объекты и интерфейсы управления задачами

  • 5.5 Пользовательский интерфейс контроллера задач

ТС может предоставить пользователю средство взаимодействия с ТС. Взаимодействие с пользователем может осуществляться через виртуальный терминал (VT) или другой интерфейс. Интерфейсы оператора могут варьироваться от очень простых до сложных, в зависимости от целей разработчика. Например, простой ТС, который поддерживает только отдельные задачи, которые запускаются автоматически, может не требовать какого-либо взаимодействия с пользователем. Более продвинутые ТС могут предложить дополнительные возможности интерфейса оператора, такие как:

  • - выбор задач из списка;

  • - запустить/остановить/возобновить/завершить задачу;

  • - изменение задачи;

  • - добавить новые исходные данные.

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

  • 5.6 Функция регистратора данных

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

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

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

Функция регистрации данных представлена в версии 4 стандарта ИСО 11783-10. Версия стандарта ИСО 11783-10 передается по сети в сообщении версии (В.5.3) и в наборе файлов передачи данных, заданном в атрибуте VersionMajor (Основная версия) XML-элемента ISO11783_TaskData (D.32).

  • 6 Требования к контроллеру задач

  • 6.1 Выбор и выполнение задачи

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

На MICS задача может быть выбрана, а может и не быть выбрана. Если задача не была выбрана оператором, то ТС может запросить оператора о выборе задачи или может выбрать задачу автоматически.

Статус задачи определен в таблице 1.

Таблица 1 — Статус задачи

Запланирована

Задача подготовлена в FMIS или MICS, но еще не обработана на MICS

Выполняется

Задача в настоящее время обрабатывается на MICS. Одновременно в ТС может быть активна только одна задача

Приостановлена

Задача ранее выполнялась, в настоящее время не выполняется и еще не завершена. Это состояние может быть конечным состоянием задачи с точки зрения ТС. Задачи с таким состоянием в наборе файлов передачи данных с происхождением MICS должны быть обработаны FMIS

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

Запланирована

Задача подготовлена в FMIS или MICS, но еще не обработана на MICS

Завершена3

Задача закончена. Этот статус может быть установлен только оператором и не может быть установлено MICS автоматически. Задачи с таким состоянием в наборе файлов передачи данных с источником MICS должны обрабатываться системой FMIS

Шаблонь

Задача — это шаблонная задача. Когда запускается шаблон задачи, создается копия шаблона, и копия запускается как новая задача. Шаблонные задачи, которые определены FMIS, не должны изменяться MICS. Шаблонные задачи, созданные в MICS, должны быть определены как новые задачи в наборе файлов передачи данных. Как только шаблонная задача, созданная в MICS, создается в нешаблонной задаче, шаблонная задача не должна изменяться

Отменена13

Цель этого состояния — иметь возможность отозвать задание. FMIS или MICS могут использовать этот статус, чтобы подать сигнал MICS или FMIS об отмене задачи

а Статус выполненной задачи не является обязательным. Некоторые ТС могут не поддерживать этот статус. ь Это определение введено в стандарте ИСО 11783-10 версии 4

  • 6.2 Регистрация времени и положения

Может возникнуть необходимость назначить некоторую необязательную информацию, такую как дата, время и данные о местоположении GPS, событиям, которые происходят во время обработки задачи. Это может быть событие, отражающее взаимосвязь XML-элементов, например назначение комментариев и/или меток, связанных с позицией GPS, или назначение или обмен работника. Другие события основаны на регистрации полученных значений переменных данных процесса от связанных с задачей клиентов, которые должны быть снабжены информацией о дате, времени и позиции.

XML-элементы Allocationstamp и Time позволяют активировать при необходимости присваивание значения времени и даты нескольким XML-элементам. Эти XML-элементы могут быть запланированного или эффективного типа для указания того, было ли событие запланировано или выполнено. Кроме того, на уровне задачи только в XML-элементе Time определяются более подробные типы времени, такие как время подготовки, неэффективное время, время ремонта или время очистки. До версии 4 стандарта ИСО 11783-10 все значения времени и даты должны были указываться в локальных значениях времени и даты внутри этого XML-элемента. В версии 4 и более поздних версиях к значениям времени и данных можно добавлять информацию о часовых поясах.

В XML-элемент задачи можно включить несколько экземпляров XML-элемента Time. Примерами того, когда это происходит, являются запуск задачи с запланированным XML-элементом типа Time и добавление нового эффективного XML-элемента Time, или возобновление задачи и добавление нового эффективного XML-элемента Time. XML-элементы Time должны добавляться в XML-элемент Task (Задача) только при изменении статуса задачи, при изменении назначения ресурса задачам, а также при событиях запуска или выключения ТС. Распределение продуктов также является примером изменения назначения ресурсов. Ранее записанные XML-элементы Time не должны быть изменены.

В качестве опции XML-элементы Allocationstamp и Time могут включать до двух позиционных XML-элементов, которые содержат информацию, поставляемую ГНСС (Глобальная навигационная спутниковая система). Первый позиционный XML-элемент добавляется при создании XML-элемента Allocationstamp или Time, а второй позиционный XML-элемент добавляется при завершении создания XML-элемента Allocationstamp или Time. Если присутствует только один XML-элемент позиции, то он указывает позицию в начале XML-элемента Allocationstamp или Time. Промежуточные позиции вдоль непрерывного CommentAllocation не указываются в самом XML-элементе Allocationstamp, а записываются в двоичные лог-файлы, заданные XML-элементом TimeLog. Определение позиции для записи непрерывных комментариев (см. в приложении D.10).

Чтобы иметь возможность выделять несколько значений данных процесса, XML-элемент Time может включать несколько XML-элементов DataLogValue (Значение журнала данных). Количество этих DataLogValue, хранящихся внутри задачи, должно быть ограничено суммарными значениями или значениями одного экземпляра. Для большого количества элементов DataLogValue определяется использование XML-элемента TimeLog и двоичного лог-файла.

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

Для каждой задачи может существовать больше XML-элементов TimeLog, ссылаясь на внешние файлы с уникальными именами внутри пространства имен набора задач, принадлежащих к набору файлов передачи данных. Уникальность префиксов имен файлов должна быть гарантирована ТС. Каждое определение файла TimeLog приводит к двум отдельным файлам — один содержит двоичные данные, а другой содержит структуру заголовка с закодированным XML-кодом набора двоичных данных. Структура заголовка определяет максимальное количество данных для двоичной записи и позволяет правильно интерпретировать двоичные данные. Расширение имени файла двоичного файла должно быть «.bin»; расширение имени файла структуры заголовка XML должно быть «.xml».

  • 6.3 Регистрация параметров из групп параметров

В дополнение к значениям ProcessDataVariable значения или параметры из других групп параметров могут регистрироваться ТС. XML-элементы DataLogTrigger и DataLogValue содержат атрибуты, чтобы указать, из какой группы параметров следует регистрировать значение. Эти атрибуты являются необязательными. Когда эти атрибуты указаны, атрибут DataLog DDI в DataLogTrigger или DataLogValue должен быть установлен в ParameterGroupNumberValue (DDI = DFFE16). Каждая группа параметров может содержать несколько значений, и поэтому должны указываться как номер группы параметров, так и начальный и конечный бит для получения одного значения из поля данных шины данных CAN (Controller Area Network — сеть контроллеров), когда ТС регистрирует данные из групп параметров, отличных от ProcessDataVariable. Максимальный размер значения составляет 32 бита, и он сохраняется как атрибут DataLogValue в XML-элементе DataLogValue.

Когда ТС регистрирует данные из групп параметров, требуется ссылка на DeviceElement (Элемент устройства). Если эти данные журнала происходят из групп параметров, отличных от ProcessDataVariable, должно быть определено устройство с CF NAME, с заполненным XML-атрибутом ClientNAME (Наименование клиента) и должен быть определен элемент DeviceElement, относящийся к этому устройству. Эти устройства и XML-элементы DeviceElement могут быть сгенерированы ТС или могут быть предоставлены FMIS.

  • 6.4 Регистрация событий задачи

Планируемое или эффективное распределение ресурсов, таких как Worker (Рабочие), Device (Устройства), Products (Продукция), Comment (Комментарии) и Control (Элементы управления), на XML-элемент Task задается с помощью шаблона XML-элементов распределения. Этот шаблон распределения создается в XML-элементах WorkerAllocation, DeviceAllocation, ProductAllocation, CommentAllocation, GuidanceAllocation и ControlAssignment. В пределах одного XML-элемента задачи могут иметь несколько экземпляров распределения этих ресурсов. Примерами того, когда несколько распределений записываются в рамках одной задачи, являются случаи, когда плановое распределение становится эффективным при запуске задачи или когда ресурс отсоединяется и вновь подключается к задаче во время выполнения этой задачи. Ранее записанные распределения ресурсов не могут быть изменены, но могут быть добавлены новые распределения ресурсов для задачи.

  • 6.5 Выбор языка, форматов и единиц измерения

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

Следующие требования применимы к ТС и DL, которые работают в сети ИСО 11783, в которой присутствует VT.

  • а) ТС должен отправлять сообщения стандартного языка, формата и единиц измерения, определенные в ИСО 11783-7, в дальнейшем именуемые «Стандартными установками» (обратите внимание, что этот термин определен в ИСО 11783-6). ТС должен использовать стандартную настройку, определенную и полученную от первичного подключенного VT (VT, который будет отображать значения от клиентов). Если стандартная настройка не была определена соединением с VT (как было бы в случае с новым заводским ТС), ТС должен использовать свою стандартную настройку по умолчанию, определенную изготовителем, до тех пор, пока не будет установлено соединение с VT.

  • Ь) ТС должен сообщать о стандартной настройке во время инициализации клиента и в любое время, когда есть изменение. Изменение может произойти из-за изменения оператором настроек VT, к которому подключен ТС, или ТС, подключенного к другому VT с другой стандартной настройкой. Должны применяться стандартные методы и правила модификации дескриптора устройства, чтобы позволить клиенту модифицировать дескриптор своего устройства на язык, выбранный оператором ТС, VT — путем обновления текстовых полей и значений DeviceValuePresentation (DVP).

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

  • d) ТС должен отвечать на запросы стандарта ИСО 11783-7 «Языковая команда», отправляемые на глобальный адрес (GA). Это требование введено в стандарте ИСО 11783-10 версии 4.

  • е) ТС должен отвечать на запросы стандарта ИСО 11783-7 «Языковая команда», адресованные ТС. Это требование введено в стандарте ИСО 11783-10 версии 4.

Если ТС не использует VT, то ТС должен предоставлять собственные средства для настройки своего языка и единиц измерения.

К клиентам предъявляются следующие требования:

  • а) Клиенты должны сконфигурировать свою стандартную настройку в соответствии с ТС, для которого они публикуют дескриптор устройства. Это требование введено в стандарте ИСО 11783-10 версии 4. Стандарт ИСО 11783-10 версии 3 и предыдущие клиенты следовали настройке VT или T-ECU.

  • Ь) Клиент должен использовать язык по умолчанию, если выбранный язык не поддерживается клиентом.

  • 6.6 Управление подключениями

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

  • 6.6.1 Инициализация контроллера задач

ТС должен завершить следующую инициализацию.

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

  • Ь) После завершения объявления адреса ТС должен подождать 6 секунд.

  • с) ТС должен начать передачу сообщения о состоянии контроллера задач.

  • d) ТС должен позволять клиентам загружать и инициализировать пулы объектов дескриптора устройства.

  • е) ТС должен запросить версию клиента после того, как клиент запросил версию ТС. Это требование введено в версии 4. До версии 4 ТС не требовалось запрашивать версию клиента.

  • 6.6.2 Инициализация клиента контроллером задач

Клиент должен завершить следующую инициализацию.

  • а) Клиент должен завершить процедуру объявления адреса в соответствии с ИСО 11783-5.

  • Ь) Клиент должен подождать 6 секунд после завершения процедуры объявления адреса.

  • с) Клиент должен дождаться, пока выбранный им ТС не начнет передачу сообщения о состоянии контроллера задачи.

  • d) Клиент должен идентифицировать себя как мастера рабочего набора со своими элементами в выбранном им ТС, используя сообщения мастера рабочего набора и элемента рабочего набора, приведенные в стандарте ИСО 11783-7. До версии 3 коммуникация между ТС и рабочим набором не ограничивалась только связью ТС с мастером рабочего набора. В версии 4 и более поздних версиях клиент по-прежнему должен идентифицировать себя через сообщение мастера рабочего набора, но связь с ТС ограничивается мастером рабочего набора в качестве клиента CF.

Клиент может отправлять эти сообщения для других целей (например, инициализация VT).

  • е) Клиент должен начать передачу сообщения задачи клиента.

  • f) Клиент версии 4 и новее должен запросить версию своего выбранного ТС, чтобы определить свои возможности с помощью сообщения запроса версии (В.5.2). До версии 4 этот шаг запроса версии рекомендовался, когда клиент намеревался использовать возможности версии 3 или новее.

Если ТС не поддерживает требуемую или более позднюю версию ИСО 11783-10, то клиент должен ограничить свою версию и возможности теми, которые доступны в ТС.

  • д) Клиент версии 4 и новее должен дождаться и ответить на сообщение Запрос версии, переданное ТС версии 4 и новее. Это позволяет ТС правильно обрабатывать информацию от клиента.

  • h) Клиент может запросить язык и формат сообщений у выбранного им ТС.

  • i) Клиент должен запросить выбранный им ТС, чтобы определить, существует ли уже его пул объектов дескриптора устройства.

  • j) Клиент должен:

  • 1 ) Активировать пул объектов дескриптора устройства в ТС, когда пул объектов дескриптора устройства уже существует в ТС, или

  • 2 ) Начать и завершить передачу пула объектов дескриптора устройства в выбранный ТС и активировать дескриптор устройства в выбранном ТС, используя сообщения, определенные в приложении В, и либо транспортный протокол (см. ИСО 11783-3), либо расширенный транспортный протокол (см. ИСО 11783-3), в зависимости от размера пула объектов дескриптора устройства.

  • 6 .6.3 Техническое обслуживание соединения

ТС должен передавать циклическое сообщение о состоянии контроллера задач с интервалом в 2 секунды. Также ТС должен немедленно отправлять сообщение о состоянии при каждом изменении состояния задачи или изменении значения в любом из других байтов сообщения о состоянии ТС, хотя между сообщениями о состоянии ТС должно быть не менее 200 мс (максимальная скорость передачи сообщения о состоянии контроллера задач составляет 5 Гц). Это сообщение содержит индикацию текущего состояния задачи и отправляется на глобальный адрес назначения (GA). Если клиент не получает это сообщение в течение как минимум 6 секунд, то это означает возможное неконтролируемое отключение ТС и прекращает отправку сообщения Задачи клиента. Клиент может восстановить соединение с ТС, перезапустив процедуру инициализации.

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

Все значения времени, указанные в ИСО 11783-10, например, интервалы 200 мс и 2 секунды, а также время ожидания 6 секунд — это значения времени, которые должны использоваться для реализации этого протокола связи. Точность реализации этих значений времени зависит от требований испытаний, определенных AEF. [2]

Сообщение о статусе ТС и сообщение о задаче клиента определены в приложении В.

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

Процедуры инициализации и завершения соединения с ТС указаны на рисунке 2. Шаг «Запрос обозначения локализации» должен быть пропущен, если ТС указал в ответе «Обозначение структуры», что в ТС отсутствует дескриптор устройства для исходного ECU.

  • 6 .6.4 Завершение соединения с контроллером задач

Выключение системы определяется как период времени, когда состояние Ключа зажигания указывает на то, что ключ трактора выключен, а питание ECU остается включенным. Питание привода может оставаться (или не оставаться) включенным одновременно с питанием ECU (см. ИСО 11783-7).

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

Следующие случаи представлены в версии 4 и являются обязательными для версий CF, совместимых с версией 4. Версия 3 и предыдущие реализации CF могут встречаться в системе, и они определяются и описываются в следующих случаях.

Управляющая функция клиента


Сетевая трансляция


Контроллер задач/ Регистратор данных


Объявление адреса Объявление адреса


Состояние ТС (интервал 2 с)—


Состояние ТС (интервал 2 с)


Мастер рабочего набора -Элемент рабочего набора


-- Мастер рабочего набора -— Элемент рабочего набора


Сообщение задачи клиента запущено (интервал 2 с)


Запрос версии

---Версия---


Запрос версии --Версия —

--------------------Обозначение структуры запроса--------------------

------------------------Обозначение структуры------------------------ Запрос обозначения локализации (только при наличии обозначения структуры) ----------------------Обозначение локализации----------------------


Вариант передачи пула 1


Операция передачи пула объектов (TP / ЕТР)


Включение пула объектов


Состояние ТС [занят] (интервал 2 с}

Состояние ТС [занят] (интервал 2 с)----


TC/DL проверяет пул


Ответ на включение пула объектов


Вариант передачи пула 2 I

-------------------------Включение пула объектов


Состояние ТС [занят] (интервал 2 с]

Состояние ТС [занят] (интервал 2 с)


TC/DL проверяет пул


Ответ на включение пупа объектов

Клиент доступен для выполнения задачи ■

Добавить дескриптор устройства в файл передачи данных Добавить DeviceAllocation и Allocationstamp к задаче (если задача активна)

---Начало измерения(й)^— Значение(я) данных процесса

ТС закрывает DeviceAllocation и Allocationstamp в задаче (если задача активна)


Сбой сообщения задачи клиента в течение 6 с

Прекратить отправку значения(й) данных процесса (если задача активна)


Рисунок 2 — Инициализация и отключение соединений

  • 6.6.4.1 Режим завершения работы контроллера задач

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

  • а) ТС должен отключить свою «логику обнаружения неожиданного отключения клиента», чтобы избежать ненужного уведомления оператора в результате немедленного отключения одного клиента, в то время как другой клиент поддерживает соединительную магистраль ECU за пределами обычного времени ожидания ТС 6 секунд, (см. в пункте 6.6.3),

  • Ь) ТС должен обслуживать службы в течение минимум 2 секунд после последнего запроса «Эксплуатационная мощность» от тех клиентов, у которых в ТС активны пулы объектов дескрипторов устройств. Это гарантирует, что данные, собранные от клиентов, могут быть корректно завершены в течение периода остановки системы.

  • с) ТС должен продолжать следить за замком зажигания и выполнять его повторную инициализацию, если Ключ зажигания в положении «Не выключено» меняется на Ключ зажигания в положении «Выключено». В этом случае ТС должен убедиться, что сообщение о статусе ТС прекращено и что выполняется стандартный процесс инициализации (см. в пункте 6.6.1).

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

  • 6.6.4.2 Режим завершения работы клиента

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

Обязательным поведением клиента является мониторинг состояния замка зажигания и выполнение следующих действий в результате перехода из Ключа зажигания в положении «Не выключено» в Ключ зажигания в положении «Выключено»:

  • а) Клиент должен отправить сообщение «Эксплуатационная мощность» (см. ИСО 11783-7), чтобы проинформировать систему о состоянии клиента, и может использовать это сообщение в качестве средства для запроса на поддержание мощности ECU и/или мощности привода.

  • Ь) Клиент контролирует параметр «Максимальное время работы трактора» (см. сообщение «теоретическая скорость и расстояние» в ИСО 11783-7) и использует эту информацию во время любых процессов управления питанием, которые он выполняет.

  • с) Клиент должен послать команду выключения соединения в ТС, чтобы исключить возможность индикации неожиданного отключения (см. В.6.10).

  • d) Клиент не должен рассматривать отсутствие сообщения о статусе ТС или другого ТС для сообщений клиента как неожиданное отключение ТС, и поэтому не должен пытаться установить соединение с любым другим ТС, который может быть доступен.

  • е) Клиент должен продолжать отслеживать состояние замка зажигания и повторно инициализировать его, если он изменится из положения «Выключено» в положение «Не выключено».

  • 6.6.4.3 Возобновление задачи после цикла питания

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

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

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

  • 6.7 Количество контроллеров задач

Правила управления соединением требуют, чтобы в сети всегда было ТС с экземпляром функции ноль (0), если в этой сети присутствует ТС. Заводские настройки ТС должны быть установлены на 12

нулевой экземпляр функции (0), но должны сохранять экземпляр функции в том виде, в котором она сконфигурирована оператором. Механизм необходим для удобного разрешения конфликтов в случае наличия нескольких ТС с одним экземпляром функции и в случае отсутствия ТС с нулевым экземпляром функции, подключенного к сети. ТС несет ответственность за предоставление собственных средств для установки экземпляра функции из ТС. Это означает, что дублирование экземпляров функций между ТС не будет производиться. Новый экземпляр функции не должен использоваться до тех пор, пока не будет произведено его повторное подключение к сети.

ТС с экземпляром функции ноль (0) определяется как «Основной ТС». Собственные средства для установки экземпляра функции должны представлять оператору номер ТС (см. пункт 3). Это гарантирует, что ТС от всех производителей представят согласованную схему нумерации, чтобы оператор мог выбрать основной (и дополнительный) ТС. Номер ТС должен находиться в диапазоне от 1 до 32, что соответствует экземплярам функций от 0 до 31. Затем на ТС следует ссылаться как на ТС № 1, ТС № 2 и т.д. Номер ТС равен экземпляру функции ТС плюс 1. Смещение 1 предназначено для поддержки операторов, которые могут быть не знакомы с системой нумерации с нуля.

ТС с экземпляром функции, отличным от нуля (> 0), должен следовать той же процедуре подключения, как указано в 6.6.

Примечание — В случае, если ТС является компонентом внутри ECU, который способен выполнять более одной функции управления, рекомендуется, чтобы функция управления ТС могла быть сконфигурирована оператором, чтобы быть активной или неактивной.

  • 6.7.1 Инициализация клиента в сетях с несколькими контроллерами задач

Обычно клиент должен подключиться к ТС с экземпляром функции 0. Если у клиента есть средство для выполнения функции «Переход к другому контроллеру задач» в сетях с несколькими ТС, он может подключиться к ТС с экземпляром функции больше 0 (>0). Эта функция должна позволять перемещение клиента к каждому из доступных ТС последовательно. Например, эта функция может быть выполнена с помощью программной клавиши или кнопки «Следующая задача контроллера» в пользовательском интерфейсе. Функция ведет себя следующим образом:

  • а) «Переход к другому контроллеру задач» активируется, если клиент обнаруживает в сети более одного ТС.

  • Ь) При активации функции «Переход к другому контроллеру задач» клиент должен выполнить следующие действия:

  • 1) Установить безопасное состояние или предотвратить активацию этой функции, если она не находится в безопасном состоянии;

  • 2) Отправить сообщение Деактивации соединения в ТС и дождаться ответа;

  • 3) Прекратить отправку сообщения Задача клиента в ТС;

  • 4) Начать процесс инициализации с другим ТС в сети.

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

Примечание — Клиент должен одновременно подключаться только к одному ТС и к одному DL. Соединения от одного клиента с несколькими ТС или несколькими DL не допускаются в этой редакции данной части ИСО 11783.

  • 6. 8 Обмен данными в сети

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

Весь специфический обмен данными для ТС в сети ИСО 11783 основан на сообщениях данных процесса.

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

  • а) Для каждого клиента в соединение ТС может быть передано не более 10 сообщений данных процесса на одну переменную данных процесса в секунду. Это ограничение касается распределения полосы пропускания сообщений данных процесса по различным переменным данных процесса. Этот максимум является общим требованием. Конкретные сценарии контроля, требующие кратковременного всплеска, например контроль рабочего состояния при въезде или выезде с поворотной полосы, могут временно превышать этот максимум. Эти исключения применимы к определенным DDI, таким как заданное и текущее сокращенное состояние работы, и указаны в DDI-определениях, перечисленных в словаре данных ИСО 11783-11. Исключения должны быть перечислены в этом словаре данных.

  • Ь) На запросы, передаваемые ТС, клиент отвечает до того, как следующий запрос разрешается ТС передать тому же клиенту. Такая синхронизация пар сообщений данных процесса обработки запроса-ответа была введена в стандарте ИСО 11783-10 версии 4. До появления стандарта ИСО 11783-10 версии 4 блок запросов мог передаваться ТС без ожидания отдельных ответов на протяжении всего блока запросов.

  • с) Все команды измерения (значения команд с 4 по 8), передаваемые ТС, должны быть подтверждены клиентом сообщением PDACK. Клиент должен ответить на команду измерения до того, как ТС допустит передачу следующей команды измерения тому же клиенту. Подтверждение команды измерения может быть положительным, если измерение поддерживается и выполняется клиентом, или отрицательным подтверждением, когда команда измерения не принимается клиентом. В случае, если команда измерения принята клиентом и команда начинает измерение, клиент также передает значение, которое переменная данных процесса имела в момент начала измерения для этой переменной данных процесса, в ТС. Это гарантирует, что точное начальное значение измерения переменной технологических данных передается в ТС. Положительное подтверждение и передача значения исходных данных процесса — это требования, которые были введены в ИСО 11783-10 версии 4. До версии 4 требовалось передавать только отрицательное подтверждение в случае, если команда измерения не могла быть принята клиентом.

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

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

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

Клиенты должны передавать в ТС только команды значения данных процесса, которые были запрошены:

  • а) Команда запроса значения.

  • Ь) Метод регистрации данных по умолчанию.

  • с) Отдельные команды измерения.

Взаимодействие между обработкой команд измерения и изменениями состояния бита «общие значения за задачу активные» выглядит следующим образом:

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

  • Ь) Если ТС отправляет конкретные команды Измерения данных процесса, когда значение бита «общие значения за задачу активные» установлено значение 0, то ТС также может остановить измерения путем отправки специальных команд измерений, чтобы остановить измерения.

  • с) Если ТС начал измерения, когда бит «общие значения за задачу активные» равен 0, то ТС не должен останавливать эти измерения непосредственно перед тем, как он изменит бит «общие значения за задачу активные» с 0 на 1.

  • d) Когда бит «общие значения за задачу активные» переходит от 0 к 1 или от 1 к 0, все измерения, которые были определены запрашивающей CF, которая передает это сообщение о статусе контроллера задач, должны быть остановлены клиентом. ТС может повторно запустить измерения, отправив конкретные команды измерения данных процесса или отправив триггер регистрации данных по умолчанию.

В ИСО 11783-10 версии 3 и более поздних указано, что ТС может начать измерение, когда задача не активна. В ИСО 11783-10 версии 2 и более ранних версиях клиенты ТС могут поддерживать или не поддерживать начало измерения, когда задача не активна.

  • 6.8.1 Привязанное к местоположению применение

Привязанное к местоположению применение требует от ТС планирования отправки сообщений с данными процесса в соответствии с фактическим местоположением. Для сопоставления фактического местоположения с определениями XML-элементов в Переменной данных процесса, в данных задачи должна быть указана геометрия для привязанных к местоположению данных процесса. Определение геометрии является либо ячейкой сетки, либо полигоном и должно быть помечено уникальным идентификатором. Ячейки и полигоны сетки относятся к зоне обработки, с которой связаны значения переменных, привязанных к местоположению данных процесса. Когда соответствующий DeviceElement вводит новую Treatmentzone (Зона обработки), новые заданные значения, связанные с этой Treatmentzone, отправляются по сети ИСО 11783 соответствующему клиенту.

Из определений геометрии ячейки сетки имеют постоянные размеры длины и ширины. Расположение ячеек сетки относительно начала сетки, к которой принадлежит ячейка сетки. Структура и идентификация ячеек сетки задаются в XML-элементе Grid. С помощью полигонов можно определить зоны обработки неправильной формы. XML-элементы Polygon, LineString и Point используются для определения данного типа. На рисунке 3 представлено сравнение обоих типов определения Treatmentzone, а на рисунке 4 определение сетки показано более подробно. С правой стороны на рисунке 3 зона обработки 1 представлена двумя полигонами, которые описывают две отдельные области. Первый из этих двух полигонов (Полигон 1) имеет одну линию, ограничивающую его область, тогда как второй из этих двух Полигонов (Полигон 3) определяется двумя линиями, внутренней и внешней границей. Зона обработки 2 также описывается двумя полигонами, 2 и 4, оба полигона имеют только внешние границы.

При использовании наложенных полигонов ТС всегда должен использовать определение внешнего полигона для данного местоположения. Каждая внутренняя граница описывает отверстие во внешнем полигоне.

  • 6.8.1.1 Привязанное к местоположению применение на основе сетки

Внутри определений XML-данных Сетка (Grid) определяется атрибутами GridMaximumColumns и Grid Maxi mum Rows, GridMinimumNorthPosition и GridMinimumEastPosition, а также размером каждой ячейки сетки. Порядок расположения ячеек сетки внутри двоичного файла должен начинаться с GridMinimumNorthPosition/GridMinimumEastPosition в порядке возрастания столбцов (при движении на восток), затем в порядке возрастания (при движении на север) по каждой строке, начиная каждый раз со столбца GridMinimumEastPosition для каждой строки. На рисунке 4 показан пример сетки и ее ячеек.

1 — область участка поля; 2 — участок поля а; 3— участок поля Ь; 4 — ячейка сетки; 5— полигон 1; 6— полигон 2; 7— полигон 3;

8— полигон 4; 9 — полигон 5; 10 — зона обработки 1; 11 — зона обработки 2; 12 — зона обработки 3

Рисунок 3 — Взаимосвязь области участка поля, участка поля, ячейки сетки, полигона, зоны обработки

1 — ячейка сетки; 2 — область участка поля; 3 — начальная точка (GridMinimumNorthPosition, GridMinimumEastPosition); 4 — FrameNorthMax, FrameEastMax; 5 — первая ячейка сетки (ряд 0 и столбец 0); б — последняя ячейка сетки (ряд 7 и столбец 13); 7 — четырнадцатая ячейка сетки (ряд 0 и столбец 13); 8 — зона обработки; а — GridCellNorthSize (размер северной ячейки сетки); b — GridCellEastSize (размер восточной ячейки сетки); с — столбцы сетки (GridColumns); d— ряды сетки (GridRows)

Рисунок 4 — Определение области сетки для участка поля

Данные определений ячеек сетки хранятся в двоичном формате в виде отдельных файлов. Ссылка на отдельный файл указывается в XML-элементе Grid. Для каждой задачи может быть только один XML-элемент Grid, относящийся как к двоичному, так и к XML-файлу с уникальным префиксом имени для всех задач набора файлов передачи данных. Уникальность имен файлов сетки должна быть гарантирована FMIS. Каждое определение файла сетки приводит к двум отдельным файлам — один содержит двоичные данные, а другой — структуру заголовка с кодировкой XML набора двоичных данных. Структура заголовка определяет максимальное количество данных для двоичной записи и позволяет правильно интерпретировать двоичные данные. Суффикс двоичного файла должен быть установлен в «.bin»; суффикс файла структуры XML-заголовка должен быть установлен в «.xml».

См. пункт 8.6.2 для деталей кодирования XML-заголовка и файлов двоичных данных.

  • 6.8.1.2 Привязанное к местоположению применение на основе полигонов

Геометрия различных XML-элементов Treatmentzone также может быть задана полигонами. Для каждой конкретной операции задания должен быть определен отдельный набор полигонов, т.е. каждый отдельный продукт или каждый отдельный тип заданного пространственно-переменного типа имеет свой собственный набор полигонов, которые определяют границы между заданными значениями для разных зон обработки. Примеры однослойных и многослойных, привязанных к местоположению задач, заданных в виде полигонов, см. в пункте D.41. Пример двухслойной специфичной, привязанной к местоположению задачи показан на рисунке 5, а кодирование XML для этого примера представлено в этом разделе.

Чтобы передать заданное значение клиенту, ТС должен определить для каждого элемента устройства, который имеет данные процесса устройства заданного значения, назначенные XML-элементам ProcessDataVariable уровня переменной скорости, находится ли он в одном из XML-элементов Treatmentzone этого уровня.

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

Когда полигоны используются для определения геометрии XML-элемента Treatmentzone, в эту Treatmentzone должен быть включен только один XML-элемент ProcessDataVariable. С этим ограничением указывается не более одной переменной скорости для группы зон обработки и полигонов, которые определяют один слой переменной скорости.

1 — слой 1; 2 — слой 2; 3 — полигон 1; 4 — полигон 2; 5 — полигон 3; 6 — полигон 4; 7 — полигон 5; 8 — зона обработки 1; 9 — зона обработки 2; 70 — зона обработки 3; 77 — полигон 6; 72 — полигон 7; 13 — полигон 8; 74 — полигон 9; 15 — зона обработки 4; 76 — зона обработки 5; 17 — зона обработки 6

Рисунок 5 — Привязанное к местоположению применение на основе двух слоев полигонов

См. пример 2 в D.50 для XML-кодирования этого набора зон обработки на основе полигонов.

  • 6.8.2 Регистрация данных

ТС также может использоваться для регистрации данных для передачи обратно в FMIS. Для этой цели значения переменных данных процесса могут быть запрошены в сети ИСО 11783. Триггеры регистрации данных могут быть указаны FMIS в наборе файлов передачи данных, установленном для ТС. ТС отвечает за преобразование этих триггеров регистрации данных в команды измерения данных процесса и за регистрацию значений переменных, отвечающих за данные процесса. Команды измерения данных процесса для регистрации данных отправляются ТС после запуска и возобновления задачи. Значения для запрашиваемых переменных данных процесса предоставляются подключенными клиентами до тех пор, пока задача активна. Отправка запрашиваемых значений прекращается, а измерения из ТС отменяются, когда задача ставится на паузу. Когда клиент отправляет больше данных, чем запрашивает ТС для регистрации данных, эти дополнительные данные игнорируются ТС. Описание XML-элемента DataLogTrigger в приложении D предоставляет более подробную информацию об использовании триггеров регистрации данных.

Примечание — Команды измерения данных процесса также могут использоваться ТС для запроса данных процесса, когда у бита «общие значения за задачу активные» установлено значение 0. Этот случай описан во введении к пункту 6.8.

  • 6.8.3 Общие значения

Различают два разных типа общих значений: общие значения за задачу и общие значения за срок службы. Общее значение за задачу контролируется ТС, т.е. когда задача запускается, ТС может установить значение этой суммы, чтобы продолжить отсчет. Общее значение за срок службы не контролируется ТС и может быть запрошено и сохранено только в наборе файлов передачи данных. Объекты данных процесса устройства, представляющие общие значения за задачу, должны иметь триггерный метод журнала данных типа «Total» (Общее значение) и бит свойства данных процесса, который указывает на то, что этот объект данных процесса может быть установлен. Объекты данных процесса устройства, которые представляют общие значения за срок службы, должны иметь триггерный метод журнала данных типа «Total», а бит свойства данных процесса «Settable» (Устанавливаемый) должен быть установлен 0.

Триггер журнала данных с методом журнала данных типа «Total» должен использоваться, чтобы запросить ТС о хранении общих значений. Каждое общее значение должно быть сохранено один раз за каждый XML-элемент Time в задаче. Задача может содержать несколько XML-элементов Time, например, в случае, когда задача возобновляется, и каждый XML-элемент Time может содержать набор общих значений. В дополнение к этому общие значения также можно чаще хранить в файлах журналов данных, связанных с TimeLog. Когда задача возобновляется, ТС должен отправить общие значения за задачу клиенту, хранящиеся в самом последнем XML-элементе Time, чтобы продолжить подсчет из этих общих значений задачи. При импорте задач в систему FMIS последний XML-элемент Time должен содержать все общие значения за задачу. ТС может запрашивать общие значения у клиента для получения последних общих значений при остановке задачи. В качестве альтернативы, когда переменные данных процесса, которые представляют общие значения, циклически передаются в ТС как сообщения данных процесса, такой запрос может не потребоваться.

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

  • 6.8.3.1 Обработка общих значений за задачу

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

Для общих значений за задачу ТС обязаны выполнить следующее:

  • а) Настроить внутренний список всех общих значений за задачу от всех подключенных клиентов. Для этого ТС должен проанализировать пулы объектов дескриптора устройства всех подключенных клиентов.

  • Ь) Запросить общие значения за задачу у всех подключенных клиентов, если статус задачи меняется с «выполняется» на «приостановлена» или «завершена», и сохранить их в XML-элементе Time.

  • с) Восстановить общие значения за задачу для всех подключенных клиентов, если задача возобновлена.

  • d) Во избежание потери данных, в случае неожиданного отключения, ТС должен регулярно запрашивать все общие значения за задачу, например, с интервалом в 1 минуту. ТС может использовать 18

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

  • е) Самый последний XML-элемент Time в задаче должен содержать все общие значения за задачу, собранные для этой задачи, даже если некоторые клиенты не присутствовали в течение последнего периода выполнения задачи.

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

Параметры обработки общих значений за задачу относительно событий Запуск/Возобновление/ Приостановка задачи:

  • а) Задача запущена: клиент сбрасывает общие значения за задачу на ноль.

  • Ь) Задача приостановлена: ТС собирает общие значения за задачу от всех клиентов, и все общие значения за задачу сохраняют свои значения.

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

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

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

  • 6.8.3.2 Обработка общих значений за срок службы

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

  • а) Настроить внутренний список всех общих значений за срок службы от всех подключенных клиентов. Для этого ТС или DL должны проанализировать пулы объектов дескриптора устройства всех подключенных клиентов.

  • Ь) Запросить все эти общие значения за срок службы у всех подключенных клиентов, если статус задачи меняется с «выполняется» на «приостановлена» или «завершена», и сохранить их в XML-элементе Time.

  • с) Во избежание потери данных в случае неожиданного отключения, ТС или DL должны регулярно запрашивать все общие значения за срок службы. ТС или DL могут использовать измерения для регулярного запроса этих общих значений за срок службы. Для поддержки измерений общих значений за срок службы рекомендуется поддерживать методы измерения временных интервалов и интервалов между измерениями.

  • d) Самый последний XML-элемент Time в задаче должен содержать все общие значения за срок службы, собранные во время этой задачи, даже если некоторые клиенты не присутствовали в течение последнего периода выполнения задачи.

Общие значения за срок службы не рекомендуется добавлять в набор данных клиента по умолчанию. Это позволяет ТС или DL обрабатывать общие значения за срок службы на основе требований к сбору данных ТС или DL.

На общие значения за срок службы не влияют события Запуск/Возобновление/Приостановка задачи. Обновление общих значений за срок службы полностью контролируется клиентами.

  • 6.8.4 Триггеры регистрации данных

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

В качестве альтернативы для механизма регистрации данных по умолчанию указана переменная данных процесса RequestDefaultProcessData (Запрос данных процесса по умолчанию) (DDI = DFFF16). В рамках механизма регистрации данных по умолчанию клиенты отвечают за отправку данных, которые клиенты хотят регистрировать, с интервалом и с помощью триггеров, указанных клиентом. Примеры случаев, для которых определяется этот механизм протоколирования данных, приведены ниже:

  • а) Клиент имеет большое количество элементов DeviceProcessData (Устройство обработки данных). ТС не знает ни соответствующего выбора, ни хорошего интервала для регистрации. Используя механизм регистрации данных по умолчанию, клиент сам решает, какие данные регистрируются.

  • b) FMIS может указать, что требуется активировать регистрацию данных, добавив запрос RequestDefaultProcessData (DDI = DFFF16) к каждой задаче.

Если в задаче не указаны триггеры регистрации данных для определенных DeviceProcessData, рекомендуется включать XML-элемент DataLogTrigger с указанным DDI RequestDefaultProcessData. Это гарантирует, что по крайней мере набор данных по умолчанию от каждого клиента будет зарегистрирован. В связи с тем, что запись данных по умолчанию может быть остановлена только путем перехода значения бита «общие значения за задачу активные» с 1 на 0, команда запроса данных по умолчанию не должна использоваться ТС, если значение бита «общие значения за задачу активные» равно 0.

Используя идентификатор (ОЭ1)этой переменной данных процесса в XML-элементе DataLogTrigger, ТС получает команду управления запросить у указанных устройств все их значения переменных данных процесса по умолчанию из метода измерения по умолчанию. Запрос DDI данных процесса RequestDefaultProcessData может быть запрошен только из элемента 0 устройства. ТС использует команду запроса значения с DDI = DFFF16, чтобы запросить отправку значений переменных данных процесса по умолчанию. Набор значений переменных данных процесса, которые относятся к набору устройств по умолчанию, указывается в пуле объектов дескриптора устройства. Когда пул объектов дескриптора устройства определяет определенные объекты DeviceProcessData как часть набора по умолчанию, объект DeviceProcessData с RequestDefaultProcessData DDI должен быть включен в пул объектов дескриптора этого устройства. Атрибут ProcessDataTriggerMethod этого объекта DeviceProcessData должен быть установлен в 1F16.

Пример 1. Пул объектов дескриптора устройства, содержащий RequestDefaultProcessData DDI и набор данных по умолчанию:

<DVC A=”DVC1“ В-”Почвообрабатывающая машина” С=”1.02*” D=”A00484000B2CAF13”

F=”32A0FE34A56F00” G=”FF000000006E65”>

<DETA=”DET1” B=”1” C=”1” E=”0” F=”0”>

<DORA="2’7>

<DORA=”3’7>

<DORA=”4’7>

<DOR A=”5’7>

<DORA=”6’7>

</DET>

<DPD A-”2" B=”0074” C=”2” D=”16” Е=”Область” F-”9,’/>

<DPD A=”3” B=”0077” C=”2” D=”16” Е=”Время включения” F=”7’7>

<DPD A=”4” B=”008D” C=”1” D=”3” Е=”Вкл/выкл работы’7>

<DPD A=”5” B=”0043” C=”1” D=”3” Е=”Ширина” F=”8’7>

<DPD A-”6” B=”DFFF” C=”0” D-”31”/>

<DPD A-”7” B=”0” C=”2.777778E-04” D=”2” E=”hr”/>

<DPD A=”8” B-”0” C=”1.000000E-03” D=”1” E-”m”/>

<DPD A=”9” B=”0” C=”1.000000E-04” D=”2” E=”ha’7>

</DVC>

В этом примере DDI данных процесса 8D16 и 4316 являются частью набора данных по умолчанию. Это устройство поддерживает механизм данных процесса запроса по умолчанию, который указывается DPD с идентификатором объекта 6.

Пример 2. RequestDefaultProcessData запускает DataLogTrigger е задаче:

<TSKA-”TSK1" E=”PFD1” G-”3”>

<DLT A=”DFFF” В=”ЗГ7>

</TSK>

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

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

  • а) Данные о времени и местоположении должны регистрироваться не более одного раза в каждом экземпляре TimeLog.

  • b) Каждое значение переменной данных процесса должно регистрироваться не более одного раза для каждого экземпляра TimeLog. Если регистрация данных может быть выполнена только с низкой частотой из-за возможностей ТС, регистрируемое значение зависит от конструкции ТС.

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

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

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

Пример 3. Переменная данных процесса DDI «А» имеет самую высокую частоту обновления; переменные DDI данных процесса «В» и «С» добавляются в текущий журнал данных:

Клиент отправляет значение DDIA^ ТС сохраняет значение А1 в Data Log 1

Клиент отправляет значение DDIТС добавляет значение В1 в Data Log 1

Клиент отправляет значение DDIA2: ТС закрывает DataLog 1; сохраняет значение А2 в Data Log 2

Клиент отправляет значение DDI С7г ТС добавляет значение С1 в DataLog 2

Клиент отправляет значение DDIА3: ТС закрывает DataLog 2; сохраняет значение А3 в DataLog 3 Клиент отправляет значение DDIA4: ТС закрывает DataLog 3; сохраняет значение А4 в DataLog 4 Пример 4. Клиент желает сгруппировать переменные DDI данных процесса: «А», «В», «С» и «О».

Клиент отправляет значение DDI (LogCount) LC^ ТС сохраняет значение DDI LC1 в DataLog 1

Клиент отправляет значение DDI A^ ТС добавляет значение А1 в DataLog 1

Клиент отправляет значение DDIВ^ ТС добавляет значение В1 в DataLog 1

Клиент отправляет значение DDI С7г ТС добавляет значение С1 в DataLog 1

Клиент отправляет значение DDI D1: ТС добавляет значение D1 в DataLog 1

Клиент отправляет значение DDI LC2: ТС сохраняет значение DDI LC2 в DataLog 2

Клиент 1 отправляет значение DDIA2: ТС добавляет значение А2 в DataLog 2

Клиент 1 отправляет значение DDI D2: ТС добавляет значение D2 в DataLog 2

Клиент 1 отправляет значение DDIВ2: ТС добавляет значение В2 в DataLog 2

Клиент 1 отправляет значение DDIС2: ТС добавляет значение С2 в DataLog 2

Клиент отправляет значение DDI LC3: ТС сохраняет значение DDI LC3 в DataLog 3

Клиент 1 отправляет значение DDI D3: ТС добавляет значение D3 в DataLog 3

Клиент 1 отправляет значение DDIВ3: ТС добавляет значение В3 в DataLog 3

Клиент 1 отправляет значение DDIС3: ТС добавляет значение С3 в DataLog 3

Клиент 1 отправляет значение DDIА3: ТС добавляет значение А3 в DataLog 3

FMIS может определить на основе LogCounts (Подсчет журналов), что все DDI А, В, С и D принадлежат к одной группе. Перед передачей группы всегда будет запускаться новый DataLog.

  • 6.8.5 Одноуровневое управление

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

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

Для этого механизма и источник заданного значения, и пользователь заданного значения должны быть CF, которые являются «клиентами» ТС, как определено в этой части ИСО 11783, и которые загружают и активируют пул объектов дескриптора устройства. Подобно запланированным приложениям, специфичным для сайта, пул объектов дескрипторов устройств пользователя с заданным значением должен включать в себя объект(ы) данных процесса обработки данных устройства (DPD), который(ые) имеет(ют) свойство, определенное как «Settable». Пул объектов дескриптора устройства источника заданного значения должен включать аналогичную форму объекта данных процесса устройства со свойством, определенным битовой меткой, установленным как источник заданного значения. Биты для Settable и источника заданного значения являются взаимоисключающими. Источник заданного значения может также включать объекты DPD, определенные как Settable. Устанавливаемый DPD в источнике заданного значения может затем использоваться в функции «Мар Overlay» (Наложение карты), где зависящее от положения полученное значение заданного значения из ТС модифицируется специальным алгоритмом источников заданного значения и используется в качестве значения заданного значения для передачи в конечное заданное значение пользователем. Отношения между источником карты и одноуровневым источником изображены на рисунке 6.

Рисунок 6 — Взаимосвязь между источником заданного значения на основе карты, источником заданного значения одноуровневого управления и пользователем заданного значения

Когда задача инициируется в ТС, используются аналогичные механизмы, доступные в стандарте ИСО 11783-10 версии 3 и более ранних ТС, для автоматического или ручного назначения управляемых объектов данных процесса источникам данных значений. В ИСО 11783-10 версии 3 и более ранних ТС источники данных заданных значений включают в себя слои карты из карт с переменной скоростью, определенных для задачи, или (не обязательно) запрограммированные вручную контрольные значения управления, определенные оператором в пользовательском интерфейсе ТС. В ТС ИСО 11783-10 версии 4 и более поздних источники данных заданных значений включают также элементы из любой CF, которые имеют элемент данных процесса обработки устройства с заданным свойством источника управления в их пуле объектов дескрипторов устройств. Все те же ограничения на назначение DDI и свойства объектов распространяются на все источники данных заданных значений, независимо от того, происходят ли они из источника, запланированного FMIS (Treatmentzone) или из другого внешнего источника (CF с элементом данных процесса устройства с набором свойств управляющего источника). При назначении источников ТС должен инициировать сообщения о назначении как источнику, так и пользователю заданного значения. Каждый клиент должен ответить, чтобы подтвердить или отклонить назначение в течение 250 мс. Для обратной совместимости, если целевой контроллер не отправляет ответ, соединение рассматривается как отклоненное. Назначения позволяют источнику заданного зна-22

чения отправлять информацию заданного значения непосредственно пользователю заданного значения без дополнительной задержки сообщения и затрат на обработку связи через CF. Это назначение использует командное сообщение из сообщения Process Data (PD) (Данные процесса). Сообщение определяет тип соединения Settable или источник управления, DeviceElement, DDI и NAME другой CF. В обязанности назначенной CF входит отслеживание изменений в исходных адресах CF при появлении новых требований к адресам. Процедура назначения визуально представлена на рисунке 7.

Сообщения о назначении должны отправляться после каждого изменения состояния задачи с неактивного на активное. Пока задача активна, информация контрольного заданного значения из источника CF заданного значения должна отправляться с периодической частотой один раз в секунду и при изменении с максимальной частотой 5 Гц. Если сообщения контрольного значения не принимаются в течение 3 секунд, CF, контролирующая цель, должна предпринимать действия таким же образом, как если бы связь с ТС была потеряна. В случае потери связи с ТС (что определяется периодическим сообщением о состоянии контроллера задач) и пользователь заданного значения, и источник заданного значения предпринимают действия на основе потерянных связей ТС и действуют по мере того, как задача становится неактивной. Если задача становится неактивной, то пользователь заданного значения не должен принимать сообщения заданного значения, источник должен прекратить отправку сообщений, и обе CF должны отменить текущие назначения. Новый набор сообщений о назначении должен быть отправлен в случае, когда задача становится активной для каждого элемента устройства, назначенного внешнему источнику. Если сообщение о назначении не получено во время каждого активного сеанса задачи или назначение является недействительным, пользователь заданного значения по умолчанию должен принимать только сообщения заданного значения от ТС, пока состояние задачи активно.

Назначение может быть сделано системой FMIS и сохранено в составе элемента Task (TSK) набора файлов передачи данных. Если назначение, сделанное FMIS, не доступно в начале задачи, ТС может выполнить назначение в соответствии с теми же правилами, которые определены для непосредственного использования ТС для контроллера. Если задание сделано ТС, то задание должно храниться таким же образом, чтобы задание запомнилось для будущих стартовых событий того же самого задания и было доступно для справки в FMIS. Это назначение хранится XML-элементом ControlAssignment (CAT).

CF целевого контроллера


CF источника одноуровневого управления


Сетевая трансляция


ТС


■*1- Состояние ТС (интервал 2 с) —

Состояние ТС (интервал 2 с)—————---

Состояние ТС (интервал 2 с)___

Задача неактивна


Сообщение о задаче рабочего набора (интервал 2 с)

Сообщение о задаче рабочего набора (интервал 2 с)

Инициализация завершена

Состояние ТС (интервал 2 с) Задача активна

Назначение источника

** Тип = Передача. Имя объекта CF, DETx/DETy/DDI1

Задача активирована (оператор или автомат)

Назначение источника

Тип = Полу

чение. Имя CF одноуровневого управления, DETy/DDI1

I

Назначение источника

Ответ на назначение в пределах 250 мс

Тип = Подтверждение Назначение источника ^Тип = Подтверждение получения,

передачи, DETx/DDI1

DETy/DDH

_ Назначение

источника

Назначение завершено раньше, начинается следующее назначение

"" Тип = Передача. Имя объекта CF, DETx/DETy/DDI2

I

1

Назначение источника

Ответ на назначение

Тип = Подтверждение передачи, DETx/DDI2 "

в пределах 250 мс

Назначение источника

Тип = Получе

чие. Имя CF одноуровневого управлен

ля, DETy/DDI2

Назначение источника ^_Тип = Подтверждение получения, j

DETy/DDI2

Данные процесса DETy/DDI1

(периодически и при изменении)

Данные процесса

_____ DETy/DDI2

Данные отправлены, когда задача активна

(периодическое и постоянное изменение)

Данные прерываются, а назначения удаляются,

_ Состояние ТС (интервал 2 с)

когда задана становится неактивной

' Задача неактивна

Примечание - DETx- это элементы описания устройства источника одноуровневого управления; DETy - это элементы описания устройства целевого контроллера; DDI1 и DDI2 - это элементы DETx и DETy.

Рисунок 7 — Процедура назначения одноуровневого управления

  • 7 Требования к регистратору данных

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

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

В DL используется подмножество функций ТС. DL должен удовлетворять требованиям механизма клиентского соединения, обработке пулов объектов дескриптора устройства и регистрации данных из данных процесса, как указано для ТС. Чтобы сохранить четкие обязанности CF в сети, DL не должен использовать все функциональные возможности ТС, которые описаны в пункте 6. Правила сетевого взаимодействия, указанные в пункте 6.8, применяются к взаимодействию между клиентами DL-to-DL

DL не должен:

  • - использовать функции раздела управления;

  • - использовать функцию управления на основе позиции;

  • - устанавливать назначения одноуровневого управления (обратите внимание, что CF одноуровневого управления может подключаться к DL для предоставления значений для целей регистрации данных);

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

DL может:

  • - запрашивать данные процесса у подключенных клиентов DL;

  • - выдавать команды измерения каждому подключенному клиенту DL;

  • - запрашивать регистрацию данных по умолчанию у подключенных клиентов DL;

  • - запрашивать группы параметров для регистрации параметров;

  • - устанавливать и запрашивать итоги задач и управлять накоплением итогов задач с помощью бита «общие значения за задачу активные» в своем сообщении о состоянии ТС (клиент DL должен поддерживать индивидуальный набор итогов задач для DL).

  • 7.2 Управление соединениями

Клиент DL, поддерживающий соединение с DL, должен инициализироваться для DL таким же образом, как описано в 6.6.2. Клиент DL должен предоставить пул объектов дескриптора устройства для DL. Пул объектов дескрипторов устройств клиента, предоставляемый ТС, и пул объектов дескрипторов устройств того же клиента, предоставляемый ТС, могут различаться. Ответственность за указание пулов объектов дескриптора устройства и оптимизацию контента для каждой цели несет разработчик клиента.

В сети может присутствовать несколько DL. Если в сети присутствует несколько DL, каждый DL должен быть идентифицирован уникальным экземпляром функции DL. Конфигурирование экземпляра функции DL аналогично конфигурированию экземпляра функции ТС в случае, если в сети присутствует несколько ТС, выполненных с помощью собственных средств. DL с экземпляром функции 0 не имеет роли, отличной от любого другого экземпляра функции DL в сети. В ИСО 11783-10 версии 4 и более ранних версиях разрешается подключение клиента DL как минимум к одному DL.

Возможны следующие конфигурации сети:

  • а) ТС и ТС клиента(ов).

Каждый клиент ТС, поддерживающий функциональность ТС, устанавливает соединение с ТС. Этот сценарий доступен со стандарта ИСО 11783-10 версии 1 и выше.

  • b) DL и DL клиент(ов).

Каждый клиент DL, поддерживающий функциональность регистратора данных, устанавливает соединение с DL. Этот сценарий в отношении подключения аналогичен сценарию 1 и представлен в стандарте ИСО 11783-10 версии 4.

  • с) ТС и DL и ТС/DL клиента(ов).

Каждая CF, поддерживающая функции ТС и клиента регистратора данных, подключается к ТС и/или DL, CF может поддерживать подключение к серверам ТС и DL одновременно. Этот сценарий представлен в версии 4 стандарта ИСО 11783-10.

  • 7.3 Измерения и общие значения

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

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

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

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

Связь FMIS с MICS и FMIS основана на наборе файлов передачи данных. Каждый файл передачи данных в формате XML отформатирован в соответствии с определениями XML версии 1.0. Файлы XML содержат только текст и кодируются в UTF-8 (см. ИСО/МЭК 10646). В качестве опции файлы данных в двоичном коде для определений ячеек сетки или зарегистрированные данные процесса могут быть частью набора файлов передачи данных. Все файлы должны находиться в одном каталоге.

Как данные кодирования, так и данные задачи сохраняются в одном и том же наборе файлов XML при передаче из FMIS в MICS. Во время обработки задач ТС эти файлы могут быть изменены и, когда задачи завершены, могут быть переданы обратно в FMIS.

  • 8.2 Расширяемый язык разметки

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

XML — это иерархический набор XML-элементов. XML-элементы могут содержать один или несколько XML-атрибутов. Внутри XML-файлов передачи данных текст XML-элементов не допускается.

XML-элемент состоит как минимум из открывающей метки, ряда атрибутов и закрывающей метки. Для требований к низкой пропускной способности памяти и пропускной способности передачи аббревиатуры, указанные в описании XML-элементов, используются в XML Schema и в XML-файлах. Следующая строка является примером определения XML-элемента под названием Worker:

  • < WKR А = “WKR2” В = “Miller” >

  • < /WKR >

Открывающая и закрывающая метки должны быть одинаковые, за исключением того, что закрывающей метке должен предшествовать знак «/». Это важно во всех случаях использования меток XML-элементов, т.е. < worker > не совпадает с < Worker >.

XML-атрибуты содержат информацию, содержащуюся в XML-элементах. Синтаксис XML-атрибута attribute-name = «description».

Обозначение XML-атрибута соответствует тем же правилам, что и обозначение XML-элемента. Регистр имеет значение. Всегда требуется использование знака равенства. Текстовое описание строки должно быть заключено в кавычки.

XML-элементы, которые не содержат дочерних элементов, но содержат атрибуты, могут быть представлены в сокращенной форме:

  • < WKR А = “WKR1 ” В = “Smith” / >

Если XML-файл следует правилам самого синтаксиса XML, он считается синтаксически корректным. XML-элементы документа могут быть формально определены с использованием DTD. Если для документа XML существует DTD, анализаторы XML с соответствующими расширениями могут проверять документ XML на соответствие DTD. Документ, который проходит такой тест на согласованность и валидацию, считается действительным.

Файлы передачи XML-данных всегда являются текстовыми файлами. Благодаря иерархической структуре файлы XML могут содержать только один корневой XML-элемент. Список элементов корневого элемента указывает, какие XML-элементы могут использоваться в качестве основных элементов.

Первичные элементы состоят из элементов данных кодирования и объектов, которые не связаны с одной задачей. Корневой элемент набора файлов для передачи данных называется ISO11783_TaskData. Файлы передачи данных XML всегда должны быть синтаксически корректны и действительны, в противном случае содержимое файла не может быть обработано.

  • 8.3 Расширяемое определение схемы

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

Целью DTD является определение правильности структурных XML-элементов-документа. DTD определяет структуру документа со списком допустимых XML-элементов. DTD может быть, как объявлен встроенным в XML-документе, так и как внешняя ссылка. Подход объектно-ориентированного языкового моделирования заключается в использовании XSD в качестве DTD.

XML Schema:

  • - определяет элементы, которые могут появиться в документе;

  • - определяет атрибуты, которые могут появиться в документе;

  • - определяет, какие элементы являются дочерними элементами;

  • - определяет порядок дочерних элементов;

  • - определяет количество дочерних элементов;

  • - определяет, является ли элемент пустым или может содержать текст;

  • - определяет типы данных для элементов и атрибутов;

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

XML Schemas отформатированы в XML и синтаксически корректны. Синтаксически корректный документ XML — это документ, который соответствует следующим правилам синтаксиса XML:

Документ должен начинаться с декларации XML;

Документ должен иметь один уникальный корневой элемент;

Все стартовые теги должны совпадать с конечными тегами;

XML-теги должны учитывать регистр;

Все элементы должны быть закрытыми;

Все элементы должны быть вложены соответствующим образом;

Все значения атрибутов должны быть заключены в кавычки.

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

  • 8.4 Определение XML Schema

Достоверность файлов передачи XML-данных определяется схемой ISO11783_TaskFile. Схема основана на определениях http://www.w3.org/2001/XMLSchema и типах данных. Схема ISO11783_TaskFile не имеет специфического для ИСО 11783 пространства имен. XML Schemas публикуются по адресу местоположения: http://dictionary.isobus.net/isobus/file/supportingDocuments. Уникальные идентификаторы XML-элементов и ссылки на уникальные идентификаторы по всем XML-элементам определяются как ID типов данных и IDREF соответственно. Для создания индивидуального пространства имен по всему набору файлов передачи данных каждый идентификатор XML-элемента должен быть определен в своем специфическом пространстве имен XML-элемента. Таблица 2 определяет действительные пространства имен идентификаторов XML-элементов.

Определение XML Schema содержит в своем названии информацию о версии стандарта ИСО 11783-10. Для определения XML-схемы используется следующее соглашение об именовании: ISO11783_TaskFile_V[VersionMajor]-[VersionMinor].xml. Например, имя файла определения XML Schema первого опубликованного международного стандарта ISO11783_TaskFile_V2-0.xml; имя файла определения XML Schema первой редакции первого опубликованного международного стандарта ISO11783_ TaskFile_V3-0.xml. Поле VersionMinor (Второстепенная версия) в элементе ISO11783_TaskData XML используется для перечисления ревизий определения XML Schema в том же самом VersionMajor значении. Файлы определения XML Schema публикуются в Интернете по адресу: http://dictionary.isobus.net/isobus/file/ supportingDocuments. Значения атрибутов XML-элемента ISO11783_TaskData VersionMajor и VersionMinor установлены в фиксированное значение в соответствующих файлах определения XML Schema.

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

Определение XML Schema должно применяться ко всем файлам передачи данных XML в обоих направлениях передачи данных. Все XML-элементы рассматриваются как объекты. Каждый объект должен иметь уникальный идентификатор (если существует идентификатор, определенный как XML-атрибут для этого элемента) по всему набору файлов передачи данных. Каждый идентификатор начинается с соответствующих букв пространства имен, за которыми следует максимум 11-значное десятичное число без начальных нулей. Уникальные идентификаторы имеют длину не менее 4 байтов и должны предоставляться в виде и FMIS, и MICS. Значения 0 и 2147483648 для идентификаторов зарезервированы и не должны использоваться внутри XML-элементов. До версии 3 стандарта ИСО 11783-10 значение 0 не резервировалось и предполагалось, что оно будет интерпретироваться как положительное значение, идентифицирующее XML-элементы, генерируемые FMIS. В стандарте ИСО 11783-10 версии 3 значение 0 было введено как зарезервированное и не должно использоваться в качестве идентификатора XML-элемента.

В MICS ни один XML-элемент данных кодирования не может быть изменен или удален. XML-элементы данных без кодирования могут быть отредактированы и изменены. Если оператор ТС создает новые объекты XML-элементов, то ТС отвечает за создание уникальных идентификаторов для всех вновь создаваемых объектов XML-элементов. Для разграничения объектов, предоставляемых FMIS и создаваемых в мобильной системе, каждый вновь созданный идентификатор должен иметь соответствующие буквы пространства имен, за которыми следует отрицательное десятичное число, например «WKR-1».

Таблица 2 — Типы XML-элементов и сокращения

Обозначение XML-элемента

Данные кодирования

Имя XML-элемента

Allocationstamp

ASP

AttachedFilea

X

AFE

BaseStation а

X

BSN

CodedComment

X

CCT

CodedCommentGroup

X

CCG

CodedCommentListValue

X

CCL

ColourLegend

X

CLD

ColourRange

X

CRG

CommentAllocation

CAN

Connection

CNN

ControlAssignmenta

CAT

CropType

X

CTP

CropVariety

X

CVT

CulturalPractice

X

CPC

Customer

X

CTR

DataLogTrigger

DLT

DataLogValue

DLV

Device X

X

DVC

DeviceAllocation

DAN

DeviceElement

X

DET

DeviceObjectReference

X

DOR

DeviceProcessData

X

DPD

DeviceProperty

X

DPT

DeviceValuePresentation

X

DVP

Farm

X

FRM

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

Обозначение XML-элемента

Данные кодирования

Имя XML-элемента

Grid

GRD

GuidanceAllocation а

GAN

GuidanceGroup а

X

GGP

GuidancePattern а

X

GPN

GuidanceShiftа

GST

LineString

LSG

OperationTechnique

X

ОТО

OperationTechniqueReference

X

OTR

OperTechPractice

ОТР

Partfield

X

PFD

Point

PNT

Polygon

PLN

Position

PTN

ProcessDataVariable

PDV

Product

X

PDT

ProductAllocation

PAN

ProductGroup

X

PGP

ProductRelation a

X

PRN

Task

TSK

TaskControllerCapabilities a

ТСС

Time

TIM

TimeLog

TLG

Treatmentzone

TZN

ValuePresentation

X

VPN

Worker

X

WKR

WorkerAllocation

WAN

ExternalFileContents

XFC

ExternalFileReference

XFR

a Этот элемент введен в ИСО 11783-10 версии 4.

Любой XML-атрибут типа IDREF может содержать только одну ссылку на идентификатор.

  • 8.4.1 Собственные расширения XML Schema

Собственные XML-элементы производителя и XML-атрибуты в наборе файлов передачи данных должны начинаться со строки, состоящей из символа «Р», десятичного кода производителя и символа подчеркивания «_». Фирменные имена и теги XML-элементов производителя должны содержать не более 16 символов. Длина данных каждого XML-атрибута производителя не должна превышать 64 символа.

Пример 1. Собственный XML-элемент, обозначенный как «MyElement» в наборе файлов передачи данных производителя с кодом производителя 500, получает имя XML-элемента:

«Р500_МуЕ1етепЬ>.

Пример 2. Собственный XML-атрибут, обозначенный «MyAttribute» от того же производителя, получает имя XML-атрибута:

«Р500_МуА ttribute».

Содержимое фирменных XML-элементов и XML-атрибутов производителя должно игнорироваться, когда набор файлов передачи данных обрабатывается MICS или FMIS другого производителя. В MICS, когда набор файлов передачи данных, исходящий из FMIS, содержит собственные XML-элементы или XML-атрибуты, эти теги XML и их значения могут быть опущены в наборе файлов передачи данных, исходящем из MICS, обратно в FMIS.

XML-элемент AttachedFile (AFE) введен в ИСО 11783-10 версии 4 для обеспечения возможности передачи проприетарных данных производителя в отдельных файлах, которые связаны со стандартным набором файлов передачи данных.

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

  • 8.5 XML-файлы передачи данных

Имя основного файла передачи данных в формате XML, содержащего корневой XML-элемент ISO11783_Task Data, должно быть установлено в «TASKDATA.XML». Когда данные передаются с использованием съемного запоминающего устройства, MICS должен поддерживать доступ к этому файлу в каталоге с именем «TASKDATA», расположенном в корневом каталоге среды передачи. И в этом имени каталога, и в именах файлов среды данных учитываются регистр и все символы в верхнем регистре. Любой другой носитель, используемый для передачи данных между FMIS и MICS, является собственностью (см. рисунок 1).

Основной файл передачи данных содержит данные кодирования и ряд задач. На рисунке 8 показана структура XML-элементов в наборе файлов передачи данных. Там могут быть ссылки на другие XML-файлы, содержащие данные кодирования или задачи внутри основного файла передачи данных. Ссылки на XML-файлы выполняются с использованием XML-элемента XFR. Ссылки на XML-файлы не могут быть вложенными. Это означает, что только основной файл XML может включать XML-элементы XFR. В указанном внешнем XML-файле может быть один XML-элемент. Элементы должны быть встроены в корневой XML-элемент с именем XFC. Ссылочный XML-файл должен содержать только XML-элементы верхнего уровня того же типа; например, он может включать определения потребителей, но не потребителей и участков полей вместе. XML-элементы верхнего уровня могут быть определены как в основном, так и в ссылочных XML-файлах.

Каждый файл передачи данных в формате XML должен начинаться с секции идентификации XML и должен быть синтаксически корректным:

< ?xml version = ”1.0” encoding = ”UTF-8”? >

В корневом файле передачи данных все XML-элементы всегда встроены в глобальную корневую структуру:

< ISO11783_TaskData VersionMajor = ”...” VersionMinor = ”...” TaskControllerManufacturer = ”...” TaskControllerVersion = ”...” ManagementSoftwareManufacturer = ”...” ManagementSoftwareVersion = ”...” xmlns:xsi = ’’http://www.w3.org/2001/XMLSchema-instance” xsknoNamespaceSchemaLocation = ”... ” DataTransferOrigin = ”...” >

</ISO11783_TaskData >

Количество элементов данных кодирования, поддерживаемых получателем набора файлов передачи данных, должно составлять как минимум 2000 на тип элемента, а общее количество элементов данных кодирования, поддерживаемых получателем, должно составлять как минимум 20000. Набор файлов передачи данных, содержащий более 2000 элементов данных кодирования на тип элемента или более 20000 элементов данных кодирования, рискует быть невозможным для обработки получателем. Это поддерживаемое ограничение на элементы данных не распространяется на элементы данных, которые не классифицируются как данные кодирования (см. таблицу 2). Примером элементов данных, не классифицированных как данные кодирования, являются геометрические элементы; например, количество точек на границе не ограничено.

--'.AFE %

’ 0..®

г-^bsn’"^

! 0..®

!• - Гест ' £•]• Рs'£j3- {.CCL ''

: о..® о..® Ох

-%СТР ' й -Г{,’cvirг" jSj “rXj'r •

0..® 0..® 0.®

I ISQ11783 TaskData ф--• -/-Э-

0.®

Рисунок 8 — Схематическая структура набора файлов передачи данных


t -TcCG "У-• 0..®

На рисунке 9 показано использование ссылочных файлов XML.

Рисунок 9 — Ссылки на XFR/XFC XML-файл

Атрибут указания направления в разделе заголовка XML (FMIS—>MICS или MICS—>FMIS) должен обрабатываться и корректно обновляться как FMIS, так и MICS.

Для обновления данных кодирования MICS разрешается добавлять только новые экземпляры XML-элементов. Это означает, что изменение данных кодирования FMIS может быть выполнено только FMIS.

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

  • 8.6 Файлы передачи двоичных данных

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

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

  • 8.6.2 Структура двоичного файла сетки

Ячейки сетки могут быть определены только в двоичном файле. Поддерживаются два типа сетки: первый тип сетки содержит коды Treatmentzone; второй тип сетки содержит значения ProcessDataVariable.

Первый тип используется, когда определено ограниченное количество Treatmentzones и сетка функционирует как таблица поиска для Treatmentzones. В этом случае каждая ячейка сетки в двоичном файле сетки содержит TreatmentZoneCode (Код зоны обработки) для Treatmentzone, к которой принадлежит эта ячейка сетки. Этот тип сетки имеет не более одного значения на ячейку сетки, которое представляет собой беззнаковый 8-битный целочисленный код TreatmentZoneCode.

Пример 1. Сетка, которая содержит TreatmentZoneCodes.

XML-файл данных задачи содержит определение сетки с пустым TreatmentZoneldRef:

  • < GRD А - ”58.096653” В = ”8.54321” С = ’’1.5Е-3” D = ”1.4Е-3” Е = ”200” F = ”300”

G =’’GRD00001” I = ”1’7 >

Двоичный файл содержит: (TreatmentZoneCodes)

(1)(4)(3)(6) ...

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

Файл TASKDATA.XML:

  • <1 SOI1783_TaskData ..... >

<CTR ... />

<TSK ... >

<GRD A= "58.096653" B= "8.54321" C="1.5E-3" D="1.4E-3" E="200” F=’"300 G=’GRD00001" I="l"/>

<TZN A="l" B='MidRate 1" C="'2">

<PDV A=“0006" B=“10000"/>

</TZN>

<TZN A="2"' B="MidRate 2" C="3"> '

<PDV A=”0006" B="I2000"/>

</TZN>

<TZN A=”3" B= HighRate 3" C="4">

<PDV A=”0006"' B="14000"/>

</TZN>

<TZN A='"4" B= HighRate 4" C="5’>

<PDV A="0006" B="15000"/>

</TZN>

<TZN A="5" B="MaxRate 5" C="6">

<PDV A='"0006" B="17000"/>

</TZN>

<TZN A=”6" B="MaxRate 6” C="7">

<PDV A=”0006" B="19000"/>

</TZN>

</TSK>

  • </I SOI 1783 TaskData>

Файл GRD00001.bin:

Содержимое двоично закодированного файла GridCell GRD000Q1.bin: (D(4)(5)(1)......

(Каждая запись представляет собой ссылку на зону обработки для ячеек сетки в порядке первой ячейки сетки. Таким образом, ячейка сетки 1 будет опорной зоной обработки 1, ячейка сетки 2 будет опорной зоной 4, ячейка сетки 3 будет опорной зоной 5 и так далее)

Рисунок 10 — Пример двоичного файла сетки типа 1

Второй тип сетки используется, когда атрибут ProcessDataValue переменной ProcessDataVariable не классифицируется на ограниченное число обрабатываемых зон. В этом случае одна зона обработки, возможно с несколькими переменными ProcessDataVariable, определяется как шаблон для файла двоичной сетки. Нет значений XML-атрибутов «ProcessDataValue» в этом определении шаблона в указанном XML-файле, и вместо этого эти значения кодируются в двоичном файле сетки в виде подписанных 32-битных целых чисел. Для порядка следования байтов 32-битного целочисленного типа данных сформированы те же правила, что и в стандарте ИСО 11783-6.

Пример 2. Сетка, содержащая переменные ProcessDataVariable ProcessDataValues

XML-файл с данными задачи содержит определение сетки с атрибутом TreatmentZoneCode:

  • < GRD А - ”58.096653" В - "8.54321" С = "1.5Е-3" D = "1.4Е-3" Е - "200" F-" 300" G = "GRD00001" I = ”2” J-"6"/>

и прототипа Treatmentzone без атрибутов ProcessDataValue:

  • < TZN А = ”6’’ В = ’’Точное земледелие’’ С = ”2” >

  • < PDV А - "0001" В = "0’7 >

  • < PDVА = "0006" В = ”0’7 >

  • < PDVА = "001А " В - "0’7 >

</TZN>

Двоичный файл содержит: (записи ProcessDataValue [])

[(11100)(15000)(190)]

[(14000)(20000)(200)]

[(19000)(25000)(200)]......

где первая запись представляет собой первую ячейку сетки со следующими значениями ProcessDa ta Values:

  • < PDVA = ”0001” В = "11100’7 >

  • < PDVA = "0006" В = "15000’7 >

  • < PDVA = "001 А" В- ”190’7 >

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

Файл TASKDATA.XML:

<IS011783_TaskData

<CTR ... />

<TSK ... >

<GRD A='58.096653' B="8.54321" C="1.5E-3" D="1.4E-3" E="200" F="300 G="GRD00001" I=*2" J="l’/>


<TZN A= * 1" B= "Точное заземление">

<PDV A="0001* B='0"/>

<PDV А^'ОООб" B="0"/>

<PDV A=’001A" B="0"/>

</TZN>

</TSK>

</IS01L783_TaskData>

Файл GRD00001.bin:

Содержимое двоично закодированного файла GridCell GRD00001.bin:

[(11100)(15000)(190)] [(14000)(20000)(200)] [(19000)(25000)(200)]

(Каждая запись представляет значения ProcessDataVariables в зоне обработки, на которую ссылается сетка. Первая запись содержит первую ячейку сетки в сетке. Таким образом, сетка ссылается на зону обработки 1, ячейка сетки 1 содержит 3 значения для 3 processdatavariables, ячейка сетки 2 содержит 3 значения для ProcessDataVariables и так далее)

Рисунок 11 — Пример двоичного файла сетки типа 2

  • 8.6.3 Структура двоичного файла журнала данных

XML-элемент TimeLog используется в файле данных задачи для ссылки на двоичный файл журнала. В файле данных задачи используется XML-элемент TimeLog без привязки к Time, Position или XML-элементам DataLogValue. Этот XML-элемент TimeLog относится к двум файлам: заголовочному файлу TimeLog XML и двоичному файлу журнала. Внутри заголовочного XML-файла TimeLog XML-элементы должны включать атрибуты без каких-либо значений для определения структуры записи двоичного журнала. Все атрибуты с непустыми определениями значений в XML-заголовочном файле TimeLog содержат фиксированные значения, которые действительны для всех двоичных записей в двоичном файле журнала. В бинарный журнал записываются только значения атрибутов пустого значения заголовочного XML-файла TimeLog. Атрибуты пустых значений XML-элементов Time, Position и DataLogValue могут быть записаны в любом порядке. Порядок указания соответствующих значений в двоичном журнале должен соответствовать порядку, указанному в таблице 3.

Приведен пример XML-кодированного файла TimeLog, который задает структуру двоичного файла TimeLog:

<TIMA = ”” D = ”4”>

  • < !— PositionNorth, PositionEast и Positionstatus — необходимые атрибуты элемента Position. — >

  • < !— В данном примере только эти три атрибута позиции записываются в двоичный файл TimeLog. — >

  • < PTN А = ”” В = ”” D = ”7 >

  • < DLV 0—>

  • < DLV А = ”0815” В = ”” С = ’’DET17 >

  • < !— DLV 1 — >

  • < DLV А = ”4711” В = ”” С = ’’DET27 >

  • < !— DLV 2—>

< DLV А = ”4522” В = ”” С = ’’DET37 >

  • < /Т1М >

Двоичные форматы данных TimeLog приведены в таблице 3. В двоичном файле журнала могут использоваться только атрибуты, перечисленные в таблице 3. Атрибуты из XML-элементов Time, Position и DataLogValue, которые не перечислены в таблице 3, не должны использоваться в двоичном файле журнала. Атрибуты должны быть записаны в порядке, указанном в таблице 3. Обратите внимание, что информация о локальном часовом поясе, введенная в ИСО 11783-10 версии 4 в XML-элементе Time, не изменяет определения использования атрибута TimeStart в двоичном файле журнала. Атрибут TimeStart в двоичном файле журнала должен по-прежнему выражаться в локальном времени.

Таблица 3 — Определения значений записи двоичного файла

Значение

XML-ссылка

Бинарный тип данных

Недоступное значение

Определение

TimeStart: time of day

TIM, A

32-разрядное целое число без знака

FFFFFFFF16

Местный часовой пояс, миллисекунды с полуночи

TimeStart: date

TIM, A

16-разрядное целое число без знака

FFFF16

Дни местного часового пояса с 1980—01—01

PositionNorth

PTN, A

32-разрядное целое число

FFFFFFFF1fi

10’7 градусов WGS-84

PositionEast

PTN, В

32-разрядное целое число

FFFFFFFF16

10-7 градусов WGS-84

PositionUp

PTN, C

32-разрядное целое число

FFFFFFFF16

Миллиметры относительно эллипсоида WGS-84

Positionstatus

PTN, D

Байт

FF16

Статус положения.

Определение ссылается на параметр NMEA2000 MethodGNSS.

0 = Без привязки GPS.

  • 1 = Привязка GNSS.

  • 2 = Привязка DGNSS.

  • 3 = Точная GNSS, без преднамеренного ухудшения (например, избирательной доступности) и код с более высоким разрешением (P-код) и 2 частоты используются для коррекции атмосферной задержки.

  • 4 = фиксированное значение RTK.

  • 5 = Плавающий RTK.

  • 6 = Режим Est(DR)mode.

  • 7 = Ручной ввод.

  • 8 = Режим моделирования.

9—13 = Зарезервировано.

  • 14 = Ошибка.

  • 15 = Значение Positionstatus недоступно

PDOP

PTN, E

16-разрядное целое число без знака

FFFF16

10'1 Информация о качестве PDOP

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

Значение

XML-ссылка

Бинарный тип данных

Недоступное значение

Определение

HDOP

PTN, F

16-разрядное целое число без знака

FFFF16

101 информация о качестве HDOP

NumberOfSatellites

PTN, G

Байт

FF16

Количество использованных спутников

GpsUtcTime

PTN, H

32-разрядное целое число без знака

FFFFFFFF16

UTC миллисекунды с полуночи

GpsUtcDate

PTN, I

16-разрядное целое число без знака

FFFF16

UTC дни с 1980-01-01

#DLV

Байт

Нет данных

Количество PDV для отслеживания

DLVn

Байт

Нет данных

Порядковый номер PDV, начиная с 0 для первого определения DataLogValue

ProcessData Value

DLV, В

32-разрядное целое число

Нет данных

Согласно DDI

Все атрибуты в начальном файле, которые содержат значения, указываются как имеющие эти постоянные значения для всех записей двоичного файла. Все элементы DLV индексируются и ссылаются в двоичных записях в соответствии с порядком их определений. Количество фактически хранимых DataLogValue определяется как #DLV. Пример двоичного файла данных журнала показан на рисунке 12, в котором всего три DLV. Чтобы разрешить динамический набор DLV в двоичной записи, каждый DLV идентифицируется по его порядковому номеру, DLVn, определения в XML-файле. В примере XML-кодированного файла TimeLog, приведенного выше перед таблицей 3, указано, что все последующие записи состоят из следующего набора значений:

(TimeStart,Position North, PositionEast,Positionstatus,#DLV, DLVO, PDVO, DLV1 ,PDV1 ,DLV2,PDV2)

Это означает, что ввод времени может иметь максимум 255 PDV.

Рисунок 12 — Пример двоичного файла журнала данных

  • 8.6.4 Структура двоичного файла точечных данных

Ряд XML-элементов Point может быть передан в двоичном файле в качестве альтернативной кодировки его определению XML. Этот метод передачи данных дает возможность использовать более высокий диапазон точности. В двоичном формате Position North и Position East и указываются как 64-разрядные целые числа. В файле данных задачи XML-элемент Point может ссылаться на двоичный файл. В случае ссылки на двоичный файл XML-элементы Point должны включать атрибуты без каких-либо значений для определения структуры записи двоичного файла. Все атрибуты с непустыми определениями значений в определении XML-элемента Point содержат фиксированные значения, которые действительны для всех записей в двоичном коде в указанном двоичном файле. В двоичный файл записываются только значения атрибутов пустых значений XML-элемента Point. Атрибуты пустого значения могут быть определены в XML-элементе Point в любом порядке. Порядок, в котором значения этих атрибутов записываются или считываются из двоичного файла, должен соответствовать порядку их перечисления в таблице 4. Пример элемента Point в XML-кодировке, который задает структуру двоичного файла Point, приведен в таблице 4.

  • < LSG А = ”6” Е = ”1” В = ”Line1” D = ”2000” С = ”20” >

  • < PNT А = ”2” С = ”” D = Е = ”” F = ”1” J = ’’PNT000017 >

  • < /LSG >

Атрибуты XML-элемента Point, которые могут передаваться через двоичный файл, указаны в таблице 4.

Таблица 4 — Определения значения записи двоичного файла точки

Ценность

XML-ссылка

Бинарный тип данных

Недоступное значение

Определение

PointType

PNT, A

8-разрядное целое число без знака

FF16

Перечисление типа точек

PositionNorth

PNT, C

64-разрядное целое число

FFFFFFFFFFFFFFFF16

10'16 градусов WGS-84

PositionEast

PNT, D

64-разрядное целое число

FFFFFFFFFFFFFFFF1fi

10'16 градусов WGS-84

PositionUp

PNT, E

32-разрядное целое число

FFFFFFFF16

Миллиметры относительно эллипсоида WGS-84

PointColour

PNT, F

8-разрядное целое число без знака

FF16

Цвет точки.

Формат: палитра типа ИСО 11783-6

PointHorizontalAccuracy

PNT, H

16-разрядное целое число без знака

FFFF16

Среднеквадратичная ошибка, в мм

PointVerticalAccuracy

PNT, I

16-разрядное целое число без знака

FFFF16

Среднеквадратичная ошибка, в мм

Примечание — Двоичное представление для передачи данных точек введено в стандрате ИСО 11783-10 версии 4.

  • 8.7 Пул объектов дескриптора устройства

Назначение пула объектов дескриптора устройства состоит в том, чтобы указать связанные с устройством свойства как в MICS, так и в FMIS. Пул объектов дескриптора устройства может быть предоставлен производителем устройства в виде набора XML-определений и может быть интегрирован в FMIS посредством импорта данных. Когда пул объектов дескриптора устройства известен в FMIS, пул объектов дескриптора устройства можно использовать для планирования задач и включить в набор файлов передачи данных из FMIS в MICS.

Если это отдельный файл, то пул объектов дескриптора устройства должен начинаться с раздела идентификации XML. Его содержание должно соответствовать определениям схемы набора файлов передачи данных для устройств. Используемые идентификаторы XML-элементов должны быть уникальными и переноситься FMIS в пространство имен уникальных идентификаторов системы управления фермерским хозяйством. Файл данных дескриптора устройства должен содержать всю информацию об устройстве, необходимую при его использовании для выполнения задачи. Например, дескриптор устройства для распылителя содержит топологию секций или форсунок, количество резервуаров и их объемы, а также поддерживаемые переменные обрабатываемых данных. Эта информация должна быть задана XML-элементами DeviceElement, DeviceProperty и DeviceProcessData в файле.

Первый элемент DeviceElement представляет само устройство и получает ElementNumber = 0. Для этого элемента DeviceElementParentldRef ссылается на XML-элемент устройство. Описание допустимых значений см. в XSD. Для всех других элементов устройства (подустройства) на устройстве, ParentldRef (Ссылка на родительский идентификатор) может ссылаться на DeviceElement для описания иерархической структуры или на устройство для элементов устройства, которые не имеют подпозиций в иерархии, но принадлежат непосредственно к устройству.

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

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

  • а) Клиент должен определить, имеет ли ТС доступную память, передавая запрос на передачу сообщения из пула объектов. ТС подтверждает это сообщение с помощью сообщения ответа на запрос передачи пула объектов. Клиент должен проверить принятый код состояния. При наличии достаточного количества памяти клиент может приступать к работе.

  • Ь) Клиент использует транспортный протокол (см. ИСО 11783-3) или расширенный транспортный протокол (см. ИСО 11783-3) для передачи обновленного или нового объекта (объектов) на ТС. Должно быть осуществлено обычное «рукопожатие», проверка ошибок и ретрансляция в соответствии со стандартом ИСО 11783-3.

  • с) По завершении клиент должен передать ТС сообщение об активации пула объектов, чтобы указать, что обновление завершено и готово к использованию.

  • d) ТС должен ответить ответным сообщением об активации пула объектов.

Клиент может обновить свой пул объектов дескриптора устройства во время выполнения. Обновления дескриптора устройства во время выполнения должны быть ограничены изменениями, связанными с настройками языка и/или единиц измерения. Эти изменения позволяют пользовательскому интерфейсу ТС обновлять информацию, связанную с устройством, для отображения на языке и в формате единиц измерения, выбранных оператором. Нет никаких ограничений на то, когда во время выполнения могут происходить обновления пула объектов дескриптора устройства; однако разработчики клиента должны по возможности избегать выполнения обновлений дескриптора устройства в то время, когда задача активна. Когда клиент обновляет свой пул объектов дескриптора устройства во время выполнения, обновление должно включать объект устройства, где исходное обозначение структуры должно оставаться неизменным, а обозначение локализации должно обновляться до новых параметров локализации. Рядом с объектом устройства находятся только объекты типа DeviceValuePresentation. Передача обновленных объектов осуществляется с использованием тех же сообщений и процедур, которые используются для передачи пула объектов дескриптора устройства при инициализации. Указатели могут быть обновлены с помощью команды изменения указателя.

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

  • а) Клиент передает сообщение об отключении пула объектов.

  • Ь) Клиент передает пул объектов дескрипторов устройств, используя те же сообщения и процедуры, которые использовались для передачи пула при инициализации.

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

Для геометрического описания устройства необходима следующая информация: нумерация и спецификация элементов DeviceElement, поддерживаемые ProcessDataVariables, спецификация DeviceProperties.

Примечание — Для получения общего описания нет разницы между орудием, системой датчиков или трактором. Дескриптор устройства может быть использован как для орудия и системы датчиков с GPS-приемником, так и для трактора с фиксированными элементами DeviceElement.

На рисунке 13 показаны опорные точки в подключенной системе. Все опорные точки описываются элементами DeviceElement, а относительные расстояния могут быть заданы значениями переменных данных процесса, определенными в словаре данных, указанном в ИСО 11783-11.

1 — ось X устройства (положительное направление); 2 — ось Y устройства (положительное направление); 3 — ось Z устройства (положительное направление); 4 — DeviceReferencePoint (DRP); 5 — ConnectorReferencePoint (CRP); 6 — DeviceElementReferencePoint (ERP); 7 — NavigationReferencePoint (NRP); a — NRP_X; b — CRP_X (Tractor); c — CRP_X (Implement); d — NRP_Y; e — ElementWorkingWidth; f— NRP_Z; g — CRP_Z (Tractor); h — CRP_Z (Implement); / — ERP_X; j— ERPZ

Рисунок 13 — Определение геометрии устройства

Каждое устройство имеет систему координат. Центр системы координат устройства определяется как DeviceReferencePoint (Контрольная точка устройства) с координатами (0,0,0). Расположение DeviceElement внутри устройства является относительным к DRP, а система координат является правосторонней со следующими определениями осей:

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

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

  • - ось Z указывается как положительная в направлении вниз по отношению к плоскости земли.

Для трактора DRP является центром задней оси. Для колесного орудия DRP является центром передней оси. В других случаях DRP можно выбирать свободно, например DRP = CRP или DRP = ERP. Если в геометрии устройства имеются углы, функция управления устройством отвечает за пересчет нового DRP/CRP и отправку его в виде динамических данных в ТС.

Точки NavigationReferencePoint (Навигационная точка отсчета) и ConnectorReferencePoint (Контрольные точки коннектора) относятся к местоположению элементов DeviceElementType (Тип элемента устройства) «Навигация» и «Соединение». В случае, если навигационная точка не сообщается трактором, но требуется ТС, ТС может предоставить альтернативные средства для указания смещений опорной точки навигационной системы.

ConnectorReferencePoint определяет положение одного или нескольких монтажных устройств, например заднего и переднего трехточечного навесного устройства или тягово-сцепного устройства. Для трехточечного навесного устройства CRP является центром нижних точек соединения. При наличии динамических изменений (например, со стороны рулевой оси устройства) устройство должно рассчитать новый CRP и отправить его в ТС.

ERP является центром одного (или группы) элемента (ов) устройства, то есть центром распылительной штанги.

Объекты DeviceProperty или DeviceProcessData должны быть определены для устройства и ссылаться на DeviceElementObject (Объект элемента устройства) для предоставления значений смещений DeviceElement, временных задержек, мощностей и т.д. В случае, если эти значения выражены в DeviceProperties, изменения должны применяться только посредством загрузки нового дескриптора устройства. В случае, если эти значения передаются через DeviceProcessData, изменения могут быть внесены во время соединения с ТС и при активной задаче. Каждый из параметров для смещений DeviceElement, временных задержек, емкости и т.д. должен быть включен в элемент устройства либо в качестве DeviceProperty, либо в качестве DeviceProcessData. Включение одного и того же параметра, т.е. одного и того же DDI в элемент устройства через объект DeviceProperty и объект DeviceProcessData, недопустимо.

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

Приложение А (обязательное)

Объекты дескриптора устройства

А.1 Общие положения

Каждое устройство, будь то компьютер или системы датчиков, определяется XML-элементом «Device», по меньшей мере, одним XML-элементом «DeviceElement» и необязательными XML-элементами, относящимися к устройствам «DeviceProcessData», «DeviceProperty» и «ValuePresentation». Определяя эти дескрипторы устройств XML-элементов как объекты, аналогично тому, как объекты используются в определении пула объектов ИСО 11783-6, все данные, относящиеся к устройству, могут быть переданы в ТС с помощью транспортного протокола ИСО 11783 и/или расширенного транспортного протокола. В данном приложении описывается представление XML-элементов дескриптора устройства в виде двоичных объектов. Обратите внимание, что некоторые атрибуты в этом представлении кодируются как строки UTF-8. Эти строки не имеют предшествующей метки порядка байтов. Максимальное количество байтов на символ кодированной строки UTF-8 составляет 4 байта. Следовательно, максимальная длина массивов байтов в четыре раза больше длины строк в кодировке LJTF-8, как указано в соответствующих определениях XML.

Все идентификаторы объекта должны быть уникальными внутри всего пула объектов дескриптора устройства.

Если ни один объект не упоминается, должен использоваться NULL Object ID. NULL ID имеет значение 65535 (FFFF16).

Передача данных объектов дескриптора устройства позволяет ТС получить фактическое описание подключенного устройства. Полученные определения объектов определенного устройства преобразуются в XML-элементы и сохраняются в наборе файлов передачи данных. Если определения объектов не являются частью файла данных текущей задачи (полученного из FMIS), то новое устройство должно быть добавлено в файл данных задачи. Если одно и то же устройство существует в текущем файле данных задачи, то между обоими наборами данных должно быть проверено обозначение структуры программного обеспечения и описания. Мобильная система должна либо обновить определения в файле данных задачи вновь полученными данными дескриптора устройства, либо сохранить полученные объекты описания как XML-элементы нового устройства.

А.2 Определение DeviceObject

DeviceObject — это определение объекта устройства XML-элемента. Каждое устройство должно иметь один единственный объект DeviceObject, который находится в своем пуле объектов дескриптора устройства. В таблице А.1 перечислены значения объекта DeviceObject. Обозначение структуры и атрибуты расширенного обозначения структуры определены для получения определенного пула объектов дескрипторов устройств. В случае, если устройство имеет несколько конфигураций, каждая конфигурация может быть идентифицирована уникальной комбинацией обозначения структуры и расширенной комбинацией атрибутов обозначения структуры. Содержимое обозначения структуры устройства и обозначения расширенной структуры устройства определяется производителем.

Оба атрибута для обозначения расширенной структуры должны использоваться только в том случае, если обе версии, ТС и клиента, указаны как версия 4 или выше. Если либо ТС, либо клиент в соединении имеют версию 3 или более раннюю, то связь должна возвращаться к наименьшей общей версии, и оба атрибута для обозначения расширенной структуры не должны использоваться. Клиент версии 4 или новее, который не использует обозначение расширенной структуры, должен сообщить, что обозначение расширенной структуры имеет длину 0 байтов, установив значение количества байтов обозначения расширенной структуры равным 0 при передаче объекта DeviceObject в ТС версии 4 или новее.

Имя ClientNAME, указанное в объекте DeviceObject, должно совпадать с запросом адреса CF.

Таблица А.1 — Определение DeviceObject

Имя атрибута

Тип

Размер в байтах

Диапазон/ значение

Запись байта

Описание

Table ID

Строка

3

DVC

1—3

Пространство имен XML-элементов для устройства

Object ID

Целое число

2

0

4—5

Уникальный идентификатор объекта внутри этого пула объектов дескриптора устройства. DeviceObject ID = 0

Number of designator bytes (N)a

Байт

1

От 0 до 128

6

Количество байтов следующего обозначения строки UTF-8

Продолжение таблицы А. 1

Имя атрибута

Тип

Размер в байтах

Диапазон/ значение

Запись байта

Описание

Device designator

UTF-8 строка, нет метки порядка байтов

Одо 128

7

Описательный текст для идентификации этого устройства. Этот текст может быть отображен оператору.

Максимальное количество символов обозначения — 32

Number of software version bytes (M)a

Байт

1

От 0 до 128

7+N

Количество байтов строки UTF-8 следующей версии программного обеспечения

Device software version

UTF-8 строка, нет метки порядка байтов

Одо 128

8+N

Версия программного обеспечения с указанием текста. Максимальное количество символов в версии программного обеспечения — 32

ClientNAME

Двойное целое число

8

8+N+M

Название клиентского устройства. Структура NAME определена в ИСО 11783-5

Number of DeviceSerial-Numberbytes (O)a

Байт

1

От 0 до 128

16+N+M

Количество байтов следующей строки DeviceSerialNumber UTF-8

DeviceSerial Number

UTF-8 строка, нет метки порядка байтов

Одо 128

17+N+M

Серийный номер устройства или машины, определенный производителем, предоставленный клиентом, например уникальный идентификационный кодс транспортного средства или продукта. Максимальное количество знаков серийного номера — 32

Device structure label

Массив байт

7

0...254 для каждого байта

17+N+M+O

Обозначение, присваиваемое

устройством для идентификации структуры дескриптора устройства. Это обозначение позволяет устройству идентифицировать текущую версию пула объектов дескрипторов устройств, присутствующих в ТС, и определить необходимость обновления. Обозначение структуры устройства байт 1 передается наиболее близко к параметру DeviceSerialNumber

Device localization label

Массив байт

7

0...254 для каждого из байтов с 1 по 6, 255 за байт 7

24+N+M+O

Обозначение, данное устройством для идентификации локализации дескриптора устройства.

Байты с 1 по 6 определяются командой языка PGN (см. ИСО 11783-7).

Байт 7 зарезервирован и установлен в FF16.

Байт 1 передается наиболее близко к параметру обозначения структуры устройства и является наименее значимым байтом обозначения DeviceLocalizationLabel в устройстве XML-элемента

Number of Extended Structure Label bytesb

Байт

1

От 0 до 32

31+N+M+O

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

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

Имя атрибута

Тип

Размер в байтах

Диапазон/ значение

Запись байта

Описание

Extended Structure Labelb

Массив байт

Одо 32

От 0 до 255 для каждого байта

32+N+M+O

Продолжение обозначения, заданного устройством для идентификации структуры дескриптора устройства. Это обозначение позволяет устройству идентифицировать текущую версию пула объектов дескрипторов устройств, присутствующих в ТС, и определить необходимость обновления. Ближе всего к параметру NumberofExtend-edStructureLabellbytes передается байт 1 ExtendedStructureLabel

а Диапазон значений для этого атрибута был расширен с 32 до 128 в ИСО 11783-10 версии 4.

ь Этот атрибут введен в ИСО 11783-10 версии 4.

с Определено в ИСО 11783-12, 2-е издание, диагностические услуги.

А.З Определение DeviceElementObject

DeviceElementObject—это объектное определение XML-элемента DeviceElement. Атрибут DeviceElementType определяет тип определения данного конкретного элемента. Тип «Устройство» представляет собой завершенное устройство и поэтому может существовать только один раз для каждого пула объектов дескриптора устройств (см. таблицу А.2).

Выборочно дочерние объекты:

  • - DeviceProcessDataObject

  • - DevicePropertyObject

Таблица А.2 — Определение DeviceElementObject

Имя атрибута

Тип

Размер в байтах

Диапазон или значение

Запись байта

Описание

Table ID

Строка

3

DET

1—3

Пространство имен XML-элементов для DeviceElement

Object ID

Целое число

2

От 1 до 65534

4—5

Уникальный идентификатор объекта

DeviceElementType

Байт

1

От 1 до 7

6

  • 1 = Устройство.

  • 2 = Функция.

  • 3 = Бункер.

  • 4 = Секция.

  • 5 = Блок.

  • 6 = Соединитель.

  • 7 = Навигационная метка.

См. подробное описание под этой таблицей

Number of designator bytes (N)a

Байт

1

От 0 до 128

7

Количество байтов следующей строки обозначения UTF-8

DeviceElement

Designator

Метки порядка байтов

Одо 128

8

Описательный текст для идентификации этого элемента устройства. Максимальное количество символов обозначения — 32

DeviceElement

Number

Целое число

2

От 0 до 4095

8+N

Номер элемента для адресации переменных технологических данных в соответствии с определениями, содержащимися в определениях переменных технологических данных в приложении В

Окончание таблицы А. 2

Имя атрибута

Тип

Размер в байтах

Диапазон или значение

Запись байта

Описание

Parent Objectld

Целое число

2

От 0 до 65534

10+N

ID объекта родительского DeviceEle-mentObject или DeviceObject для установления иерархического порядка элементов DeviceElement

Number of objects to follow

Целое число

2

12+N

Количество следующих объектных ссылок

REPEAT: Objectld

Целое число

2

14+N+ объект

Список ссылок на DeviceProcessData-Objects или DevicePropertyObjects

a Диапазон значений для этого атрибута был расширен с 32 до 128 в ИСО 11783-10 версии 4.

А.3.1 Тип элемента устройства — Устройство

Пул объектов дескриптора устройства должен иметь один элемент устройства с номером элемента устройства = 0, который представляет завершенное устройство и делает его адресуемым для ТС.

А.3.2 Тип элемента устройства — Функция

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

А.3.3 Тип элемента устройства — Бункер

Это, например, бак опрыскивателя или бункер сеялки.

А.3.4 Тип элемента устройства — Секция

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

А.3.5 Тип элемента устройства — Блок

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

А.3.6 Тип элемента устройства — Соединитель

Этот тип элемента устройства определяет положение подключения/соединения устройства. Для одного устройства может быть определено более одного соединителя (например, трактор может иметь места соединения спереди и сзади). Элемент соединителя должен предоставлять свои параметры геометрии устройства (х, у, z) относительно базовой точки устройства в качестве значений данных процесса устройства или в качестве значений свойств устройства, даже если базовая точка устройства совпадает с положением соединителя (х = у = z = 0).

А.3.7 Тип элемента устройства — Навигационная метка

Этот тип элемента устройства определяет положение навигационной метки для навигационных устройств, таких как GPS-приемники. Такие элементы должны указывать свою позицию по направлениям х, у и z как значения данных процесса устройства или значения свойств устройства.

А.4 Определение DeviceProcessDataObject

Объект DeviceProcessDataObject — это определение объекта XML-элемента DeviceProcessData. Каждый объект содержит единое определение переменной данных процесса. См. таблицу А.З.

Ссылочный дочерний объект: DeviceValuePresentationObject.

Таблица А.З — Определение DeviceProcessDataObject

Имя атрибута

Тип

Размер в байтах

Диапазон или значение

Запись байта

Описание

Table ID

Строка

3

DPD

1—3

Пространство имен XML-элементов для DeviceProcessData

Object ID

Целое число

2

От 1 до 65534

4—5

Уникальный идентификатор объекта

Окончание таблицы А.З

Имя атрибута

Тип

Размер в байтах

Диапазон или значение

Запись байта

Описание

Process data DDI

Целое число

2

От 0 до 65535

6—7

Идентификатор переменной данных процесса (DDI) в соответствии с определениями в приложении В и ИСО 11783-11

Process data properties

Байт

1

От 0 до 7

8

Набор битов, состоящий из:

Бит 1=1= Элемент набора по умолчанию.

Бит 2 = 1= Устанавливается.

Бит 3 = 1= Источник управления3.

Примечание — Биты 2 и 3 являются взаимоисключающими

Process data available trigger methods

Байт

1

От 0 до 31

9

Набор битов, состоящий из: Бит 1=1= Временной интервал. Бит 2 = 1= Интервал расстояния. Бит 3 = 1= Пороговые значения. Бит 4 = 1= При изменении.

Бит 5 = 1= Общее значение.

См. подробное описание с А.4.1 по А.4.5

Number of designator bytes (N)b

Байт

1

От Одо 128

10

Количество байтов следующей строки обозначения UTF-8

Process data designator

UTF-8 строка, нет метки порядка байтов

Одо 128

11

Описательный текст для этого устройства обрабатывает данные.

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

обозначения — 32

Device value presentation object ID

Целое число

2

От 1 до 65535

11+N

Идентификатор объекта DeviceValuePre-sentation — Объект. Используйте NULL идентификатор объекта, когда нет ссылки на объект Device — ValuePresentationObject

a Бит 3 этого атрибута введен в ИСО 11783-10 версии 4.

ь Диапазон значений для этого атрибута был расширен с 32 до 128 в ИСО 11783-10 версии 4

А.4.1 Метод запуска данных процесса устройства — временной интервал

Устройство может предоставлять эти данные процесса на основе временного интервала.

А.4.2 Метод запуска данных процесса устройства — интервал расстояний

Устройство может предоставить данные процесса, основанные на интервале расстояний.

А.4.3 Метод запуска данных процесса устройства — пороговые значения

Устройство может предоставлять эти данные процесса на основе превышения порогового значения.

АЛЛ Метод запуска данных процесса устройства — при изменении

Устройство может предоставлять эти данные процесса при изменении их значения.

А.4.5 Метод запуска данных процесса устройства — общее значение

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

А.5 Определение DevicePropertyObject

DevicePropertyObject — это объектное определение XML-элемента DeviceProperty.

Каждый объект содержит единственное определение DeviceElementProperty (см. таблицу А.4).

Ссылочный дочерний объект: DeviceValuePresentationObject.

Таблица А.4 — Определение DevicePropertyObject

Имя атрибута

Тип

Размер в байтах

Диапазон или значение

Запись байта

Описание

Table ID

Строка

3

DPT

1—3

Пространство имен XML-элементов для DeviceProperty

Object ID

Целое число

2

От 1 до 65534

4—5

Уникальный идентификатор объекта

Окончание таблицы А.4

Имя атрибута

Тип

Размер в байтах

Диапазон или значение

Запись байта

Описание

Property DDI

Целое число

2

От 0 до 65535

6—7

Идентификатор свойства (DDI) в соответствии с определениями, содержащимися в приложении В и ИСО 11783-11

Property value

Целое число со знаком

4

От -231 до (231-1)

8—11

Значение свойства

Number of designator bytes (N)a

Байт

1

От Одо 128

12

Количество байтов следующей строки обозначения UTF-8

Property designator

UTF-8 строка, нет метки порядка байтов

Одо 128

13

Описательный текст для этого свойства устройства. Максимальное количество символов обозначения — 32

Device value presentation object ID

Целое число

2

От 1 до 65535

13+N

Идентификатор объекта DeviceValuePresentationObject. Используйте NULL идентификатор объекта, когда на объект DeviceValuePresentationObject нет ссылки

a Диапазон значений для этого атрибута был расширен с 32 до 128 в ИСО 11783-10 версии 4.

А.6 Определение DeviceValuePresentationObject

DeviceValuePresentationObject — это объектное определение XML-элемента DeviceValuePresentation. Этот объект содержит информацию о представлении для отображения значения объекта DeviceProcessData или De-viceProperty. Устройство может обновлять эти объекты при изменении оператором языка и/или единиц измерения (см. таблицу А.5).

Ссылочные дочерние объекты: отсутствуют.

Таблица А.5 — Определение DeviceValuePresentationObject

Имя атрибута

Тип

Размер в байтах

Диапазон или значение

Запись байта

Описание

Table ID

Строка

3

DVP

1—3

Пространство имен XML-элементов для DeviceValuePresentation

Object ID

Целое число

2

От 1 до 65534

4—5

Уникальный идентификатор объекта

Offset

Целое число со знаком

4

От -231 до (231-1)

6—9

Смещение, применяемое к значению для представления

Scale

Плавающее положение

4

0,000000001 ...

100000000,0

10—13

Шкала, применяемая к значению для представления

Number of decimals

Байт

1

От 0 до 7

14

Укажите количество десятичных знаков для отображения после запятой

Number of UnitDes-ignator bytes (N)a

Байт

1

От 0 до 128

15

Количество байтов следующей строки обозначения UTF-8

UnitDesignator

UTF-8 строка, нет метки порядка байтов

Одо

128

16

Обозначение устройства для представления этого значения. Максимальное количество символов обозначения — 32

a Диапазон значений для этого атрибута был расширен с 32 до 128 в ИСО 11783-10 версии 4.

А.7 Структура объектов

Рисунок А.1 иллюстрирует иерархию объектов, связанных с устройством. Пул объектов дескрипторов устройств должен содержать только один объект устройств и может иметь несколько объектов DeviceElement, DeviceProcessData, DeviceProperty и DeviceValuePresentation. На объекты DeviceProcessData и DeviceProperty можно ссылаться из нескольких объектов DeviceElement. На объект DeviceValuePresentation можно ссылаться из нескольких объектов DeviceProcessData или DeviceProperty.

Рисунок А. 1 — Объектные отношения дескриптора устройства

Приложение В (обязательное)

Определения сообщений

  • В.1 Общие положения

    • В.1.1 Сообщение данных процесса

Сообщение Process Data используется для передачи данных дескриптора устройства, измеренных данных и/или команд заданных значений одному или нескольким контроллерам. Первый полубайт первого байта сообщения идентифицирует команду или действие, которые требуется выполнить контроллеру (контроллерам). Остальная часть сообщения данных процесса для команд 016 и 116 отличается от остальной части сообщения данных процесса команд от 216 до А16 и от D16 до F16. В таблице В.1 перечислены эти команды и указано определение или местоположение в настоящем приложении.

Сообщения Process Data могут передаваться в сети независимо от того, установлен ли в сообщении о состоянии контроллера задач бит «общие значения за задачу активные» или DL на 1. Сообщения Process Data могут также появляться в сети вне рамок связи между ТС или DL и их подключенными клиентами.

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

На запросы данных процесса и команды измерения необходимо ответить до того, как будет разрешено передать следующий запрос или команду измерения. Эта синхронизация пар сообщений запроса-ответа данных процесса была введена в ИСО 11783-10 версии 4. Дополнительные подробности, касающиеся управления полосой пропускания передачи данных процесса см. в пункте 6.8.

  • В.1.2 Параметр команды

Длина данных: 4 бита

Диапазон данных: от 0 до 15

SPN: 5 199

  • В.2 Группа параметров сообщения данных процесса

Группа параметров сообщения Process Data определяется как:

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

0

Страница расширенных данных:

0

Формат PDU:

203

Специальное поле PDU:

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

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

3 для сообщений со значениями команд 316, А16, Е16 или F16.

4 для сообщений со значением команды D16

5 для сообщений со значениями команд 016, 116, 216 или от 416 до 916.

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

51968 (00СВ0016)

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

Переменная минимум 8 байтов.

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

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

Единичный ТС должен быть представлен единственной функцией управления в сети. Все коммуникации ТС в сети должны происходить между клиентом, идентифицированным как мастер рабочего набора, и сервером ТС. Это требование было введено в ИСО 11783-10. Введение в 4-й версии ИСО 11783-10 метода связи одноуровневого управления устранило необходимость в том, чтобы ТС состоял из нескольких CF, представленных в сети многоэлементным рабочим набором. Обратите внимание, что многоэлементный рабочий набор все еще может быть объявлен в сети для подключения такого многоэлементного рабочего набора к VT. Если из этого многоэлементного рабочего набора один и тот же мастер рабочего набора устанавливает соединение с клиентом как ТС, то только мастер рабочего набора из этого рабочего набора должен связываться с ТС.

Таблица В.1 — Команды данных процесса

Значение команды

Описание

°16

Подкоманда для определения технических возможностей ТС, DL или клиента. Эти сообщения технических данных определены в В.5

116

Подкоманда для передачи и управления дескрипторами устройств. Эти сообщения дескриптора устройства определены в В.6

216

Команда запроса значения. Запрашивается объект данных, определенный идентификатором словаря данных. Макет этого сообщения определен в В.З

316

Команда значения: значением данных процесса является это значение объекта данных, определенное идентификатором словаря данных. Эта команда используется как для ответа на команду запроса значения, так и для установки значения объекта данных процесса. Макет этого сообщения определен в В.З

416

Команда измерения: значением данных процесса является интервал времени для отправки элемента данных, определенного идентификатором словаря данных. Клиент должен отправлять значение этого элемента данных в ТС или DL циклически с этим интервалом времени. Единицей интервала времени является миллисекунда. Макет этого сообщения определен в В.З

516

Команда измерения: значением данных процесса является этот интервал расстояния для отправки элемента данных, определенного идентификатором словаря данных. Клиент должен отправлять значение этого элемента данных в ТС или DL циклически с этим интервалом расстояния. Единицей интервала расстояния является миллиметр. Макет этого сообщения определен в В.З

616

Команда измерения: значением данных процесса является минимум в пределах порога для отправки элемента данных, определенного идентификатором словаря данных. Клиент должен отправлять значение этого элемента данных в ТС или DL, когда значение выше порогового значения. Единица порога указана в определении идентификатора словаря данных. Макет этого сообщения определен в В.З

716

Команда измерения: значением данных процесса является максимум в пределах порога для отправки элемента данных, определенного идентификатором словаря данных. Клиент должен отправлять значение этого элемента данных в ТС или DL, когда значение ниже порогового значения. Единица порога указана в определении идентификатора словаря данных. Макет этого сообщения определен в В.З

816

Команда измерения: значением данных процесса является порог изменения для отправки объекта данных, определенного идентификатором словаря данных. Клиент должен отправлять значение этого элемента данных в ТС или DL, когда изменение значения выше или равно пороговому значению изменения с момента последней передачи. До 3-й версии ИСО 11783-10 клиент должен был отправлять значение, когда изменение значения превышало порог изменения. В 3-й и поздних версиях ИСО 11783-10 разъяснено, что оно должно быть выше или равно порогу изменения, чтобы соответствовать определению DataLogTrigger в D.17. Единица порога указана в определении идентификатора словаря данных. Макет этого сообщения определен в В.З

9i6a

Команда назначения одноуровневого управления. Это сообщение используется для установления соединения между источником заданного значения и пользователем заданного значения. Успешное назначение позволяет источнику заданного значения отправлять команды заданного значения непосредственно пользователю заданного значения. Макет этого сообщения определен в В.4

А а а16

Команда установки значения и подтверждения. Эта команда используется для установки значения объекта данных процесса и запроса подтверждения от получателя. Значение данных процесса команды установки значения является значением объекта данных, определенного идентификатором словаря данных. Макет этого сообщения определен в В.З. Ответом должно быть сообщение подтверждения данных процесса (D16). Это сообщение определено в В.7

В16 И С16

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

D16

Сообщение является подтверждением данных процесса (PDACK). Это сообщение определено в В.7

Е16

Сообщение является сообщением о состоянии ТС. Это сообщение определено в В.8.1

F16

Сообщение задачи клиента, отправленное клиентом, определено в В.8.2

а Это определение значения команды введено в 4-й версии ИСО 11783-10

  • В.З Команды значений и измерений

    В.3.1 Поля параметров

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

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

Байт 1: Биты с 4 по 1

Команда, возможные значения от 216 до А16 (см. таблицу В.1).

Байт 1: Биты с 8 по 5

Номер элемента (LSNibble) (см. В.3.2)

Байт 2:

Номер элемента (MSB) (см. В.3.2)

Байт 3:

Идентификатор DD (LSB) (см. В.3.3)

Байт 4:

Идентификатор DD (MSB) (см. В.3.3)

Байты с 5 по 8:

Значение переменной процесса (см. В.3.4)

  • В.3.2 Номер элемента

Номер элемента представляет собой 12-битное поле, которое содержит байт 1, биты с 5 по 8 и байт 2. Он указывает конкретный управляемый элемент, который должен действовать по команде. Набор номеров определяется в дескрипторе устройства. Синтаксис {номер элемента, родительский номер} используется для описания конфигурации.

Длина данных: 12 бит

Диапазон данных:


от 0 до 4095


SPN:

5200


Пример. Опрыскиватель с 3 секциями штанг с 6 форсунками в первой секции, 8 форсунками во второй секции штанги и 6 форсунками в третьей секции штанги {номер элемента, родительский номер}:

{О, NULL}

{1,0}, {2,0}, {3,0}

{4,1}, {5,1}, {6,1}, {7,1}, {8,1}, {9,1}

{10,2}, {11,2}, {12,2}, {13,2}, {14,2}, {15,2}, {16,2}, {17,2}

{18,3}, {19,3}, {20,3}, {21,3}, {22,3}, {23,3}

Номер элемента 0 обозначает опрыскиватель. Номер элемента 2 обозначает вторую секцию штанги. Для обозначения второй форсунки на третьей секции штанги будет использоваться номер элемента 19.

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

  • В.3.3 Идентификатор словаря данных

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

Длина данных: 2 байта

Диапазон данных: от 0 до 65255

SPN: 5201

  • В.3.4 Значение переменной процесса

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

Длина данных: Разрешение: Диапазон данных: SPN:


4 байта

в соответствии с определением объекта словаря данных в соответствии с определением объекта словаря данных 5202

  • В.4 Сообщения о назначении одноуровневого управления

Сообщение о назначении одноуровневого управления используется для установления соединения между источником заданного значения и пользователем заданного значения. Длина этой команды зависит от направления этого сообщения. При отправке из ТС в другую CF длина сообщения составляет 14 байтов и использует транспортный протокол. При отправке в ТС в ответ на команду назначения длина сообщения составляет 8 байтов. Это сообщение было введено в 4-й версии ИСО 11783-10.

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

По запросу

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

14 байтов (команда назначения), 8 байтов (ответ назначения)

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

Данные процесса с конкретным назначением

Байт1: Биты с 4 по 1 1001

Назначение управления

Байт 1: Биты с 8 по 5

Номер элемента (LSNibble) (см. В.3.2)

Байт 2:

Номер элемента (MSB) (см. В.3.2)

Байт 3:

Идентификатор DD (LSB) (см. В.3.3)

Байт 4:

Идентификатор DD (MSB) (см. В.3.3)

Байт 5: Биты с 4 по 1

Режим назначения управления

Значение = 0: Назначить получателя

Комбинация «Номер элемента/Идентификатор DD (DDI)», указанная в этой команде, начинает получать данные из CF, указанной NAME этой команды. Это значение режима назначения отправляется от ТС к CF пользователя заданного значения.

Значение = 1: Отменить назначение получателя

Комбинация «Номер элемента/DDI», указанная в этой команде, больше не принимает данные из CF, указанной NAME этой команды. Это значение режима присваивания отправляется от ТС к CF пользователя заданного значения.

Значение = 2: Подтверждение получателя

Назначение или отмена назначения для получения данных управления комбинацией «Элемент/DDI», указанной в этой команде, было принято. Это значение режима назначения передается от CF пользователя заданного значения к ТС.

Значение = 3: Назначить отправителя

Комбинация «Номер элемента/DDI», указанная в этой команде, позволяет отправлять команды заданного значения CF пользователя заданного значения, указанной NAME этой команды. Это значение режима назначения передается от ТС к CF источника заданного значения.

Значение = 4: Отменить назначение отправителя

Комбинация «Номер элемента/DDI», указанная в этой команде, больше не отправляет команды заданного значения к CF пользователя заданного значения, указанной NAME этой команды. Это значение режима назначения отправляется от ТС к CF источника заданного значения.

Значение = 5: Подтверждение отправителя

Назначение или отмена назначения для отправки данных заданного значения комбинацией «Элемент/DDI», указанной NAME этой команды, было принято. Это значение режима назначения отправляется от CF источника заданного значения к ТС.

Значение = от 6 до 15:

Зарезервировано для будущего использования

Байт 5: Биты с 8 по 5

Номер элемента назначения (LSNibble) пользователя заданного значения, с которым это назначение выполняется (формат номера элемента: см. В.3.2)

Байт 6:

Номер элемента назначения (MSB) пользователя заданного значения, с которым это назначение выполняется (формат номера элемента: см. В.3.2)

Байты с 7 по 14:

NAME управляющей функции CF, с которой это назначение выполняется.

Примечание — Номер элемента назначения в байтах 5 и 6 используется только в том случае, если типом назначения является «Передача». Номер элемента является номером дескриптора устройства пользователя заданного значения. Это значение должно использоваться источником заданного значения в сообщении данных процесса «Команды значения», отправляемом пользователю заданного значения. Для сообщений назначения получателя установить номеру элемента назначения значение FFF16. Существует только один DDI, потому что он должен быть одним и тем же для дескриптора устройства CF источника заданного значения и дескриптора устройства CF целевого контроллера для возможности назначения посредством ТС.

Ответ о назначении производится путем отправки того же сообщения обратно к ТС с типом назначения (байт 5, биты с 4 по 1), измененным на корректное значение. Битам с 8 по 5 байта 5 установлено значение F16, а байтам с 6 по 8 — значение FF16, и сообщение отправлено как единый пакет. Только одно сообщение, о присвоении или отмене назначения, должно быть отправлено к CF до наступления ответа или времени ожидания.

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

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

  • В.5 Сообщения технических данных

    В.5.1 Общие положения

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

    • В.5.2 Сообщение запроса версии

Сообщение запроса версии позволяет ТС, DL и клиенту определить версию ИСО 11783-10 реализации.

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

По запросу

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

8 байтов

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

Данные процесса с конкретным назначением

Байт 1:

Биты с 4 по 1

0000

Технические данные команды

Биты с 8 по 5

0000

Версия запроса параметра

Байты с 2 по 8:

Зарезервировано, передавать как FF16

В.5.3 Сообщение о версии

Сообщение о версии отправляется в ответ на сообщение запроса версии и содержит информацию о версии ИСО 11783-10 для реализации ТС, DL или клиента.

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

В ответ на сообщение о запросе версии

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

8 байтов

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

Данные процесса с конкретным назначением

Байт 1:

Биты с 4 по 1

0000

Технические данные команды

Биты с 8 по 5

0001

Версия параметра

Байт 2:

Номер версии

Версия этой части стандарта ИСО 11783, которой соответствует эта управляющая функция

0

Версия DIS (проект Международного стандарта).

1

Версия FDIS.1 (окончательный проект Международного стандарта, первое издание)

2

Версия FDIS.2 и первое издание, опубликованное в качестве Международного стандарта

3

Версия второго издания, опубликованная в виде проекта Международного стандарта (E2.DIS)

4

Версия второго издания, опубликованная в качестве окончательного проекта Международного стандарта (E2.FDIS) и в качестве Международного стандарта (E2.IS)

Байт 3:

Время загрузки

Максимальное количество секунд между циклом включения и передачей первого «Сообщения о состоянии контроллера задач» (см. 6.7.1). Передача в виде FF16, если эта информация недоступна. Предоставление информации о времени загрузки должно использоваться только в информационном сообщении о версии, отправленном ТС или DL, клиент должен присвоить этому значению FF16. Определение этого байта введено в 3-й версии стандарта ИСО 11783-10, значением для ИСО 11783-10 версии 2 и более ранних является FF16.

Байт 4:

Предусмотренные опции

Опции, указанные в ИСО 11783-10, которым соответствует этот

Бит 1 = 1 =

ТС, DL или клиент. Определение этого байта введено в версии 3 стандарта ИСО 11783-10, значением для ИСО 11783-10 версии 2 и более ранних является FF16.

Поддерживает документацию.

Бит 2 = 1 =

Примечание — Общие значения за задачу должны обрабатываться на любом уровне. Функциональность ТС-BAS. Подробная информация о функциональных возможностях ТС приведена в приложении F.

Поддерживает ТС-GEO без управления по положению. Это опре

Бит 3 = 1 =

деление указано для регистрации данных по положению.

Поддерживает ТС-GEO с управлением по положению.

Бит 4 = 1 =

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

Бит 5 = 1 =

Поддерживает управление секциями орудия, функциональность

Биты с 6 по 8 = 0 =

TC-SC

Зарезервировано для назначения ISO

Байт 5: Байт 2 предусмотренных опций

Биты с 1 по 8 = 0 = Зарезервировано для назначения ISO. Определение этого байта

введено в стандарте ИСО 11783-10 версии 3, значением для ИСО 11783-10 версии 2 и более ранних является FF16

Байт 6: Количество штанг для управления секциями. Если сообщается ТС, то это максимальное

поддерживаемое количество штанг для управления секциями3. Если сообщается клиентом, то это количество штанг для управления секциями, которым может управлять клиент3. Штанга для управления секциями определяется как элемент устройства, который ссылается на DDI состояния управления секцией в одном из своих объектов данных процесса устройства (см. F.3.5.3). Определение этого байта введено в стандарте ИСО 11783-10 версии 3, значением для ИСО 11783-10 версии 2 и более ранних является FF16.

Байт 7: Количество секций для управления секциями. Это общее количество секций всех штанг. Если

сообщается ТС, то это максимальное количество секций, которое поддерживается3. Если сообщается клиентом, то это количество секций, которым может управлять клиент3. Определение этого байта введено в стандарте ИСО 11783-10 версии 3, значением для ИСО 11783-10 версии 2 и более ранних является FF16.

Байт 8: Количество каналов управления для управления по положению. Если сообщается ТС, то это

максимальное количество отдельных каналов управления, которое поддерживается3. Если сообщается клиентом, то это количество отдельных каналов управления, которым может управлять клиент3. Канал управления по положению определяется как элемент устройства, который ссылается на DDI состояния управления дифференцированным внесением в одном из своих объектов данных процесса устройства (см. F.3.4.4). Определение этого байта введено в стандарте ИСО 11783-10 версии 3, значением для ИСО 11783-10 версии 2 и более ранних является FF16.

3 Клиенту ТС необходимо настроить количество штанг, секций и каналов управления по положению в соответствии с требованиями к функционалу TC-SC и ТС-GEO (см. приложение F). Значения, сообщаемые клиентом ТС в сообщении о версии, при подключении к серверу ТС должны не изменяться по количеству штанг, секций и каналов управления по положению, а описывать возможности клиента ТС.

  • В.5.4 Сообщение запроса идентификации контроллера задач

Сообщение запроса идентификации контроллера задач может быть отправлено как клиентами, так и ТС. После получения этого сообщения ТС должен вывести на экран в течение 3 секунд номер ТС (см. раздел 3). Это сообщение предназначено для отправки с глобальным назначением, однако оно можно быть отправлено с конкретным назначением.

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

Номер ТС должен находиться в диапазоне от 1 до 32 в соответствии с экземплярами функций от 0 до 31. На ТС можно ссылаться, используя ТС № 1, ТС № 2 и т. д.

Номер ТС = Экземпляр функции ТС + 1

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

Примечание 2 — Это сообщение действительно для управляющей функции DL.

Примечание 3 — Это сообщение доступно в стандарте ИСО 11783-10 версии 4 и более поздних.

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

По запросу

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

8 байтов

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

Данные процесса с конкретным назначением

Байт 1: Биты с 4 по 1 0000

Технические данные команды

Биты с 8 по 5 0010

Идентификация контроллера задач

Байты с 2 по 8:

Зарезервировано, передается как FF16

  • В.5.5 Ответное сообщение об идентификации контроллера задач

ТС использует это сообщение для ответа на сообщение об идентификации контроллера задач, если оно было получено с конкретным назначением.

Примечание 1 — ТС без графического интерфейса может существовать, и в этом случае номер экземпляра может не отображаться.

Примечание 2 — Это сообщение действительно для управляющей функции CF.

Примечание 3 — Это сообщение доступно в стандарте ИСО 11783-10 версии 4 и более поздних.

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

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

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

Байт 1: Биты с 4 по 1 0000

Биты с 8 по 5 0010


Байты с 2 по 8:


По запросу

8 байтов

Данные процесса с конкретным назначением

Технические данные команды

Ответ об идентификации контроллера задач

Зарезервировано, передается как FF16


  • В.6 Сообщения дескриптора устройства

    В.6.1 Общие положения

    Сообщения дескриптора устройства используются для передачи дескриптора устройства с клиента на ТС или DL и обслуживания пула объектов дескрипторов устройств.

    • В.6.2 Сообщение запроса обозначения структуры

Сообщение запроса обозначения структуры позволяет клиенту определить доступность запрошенной структуры дескриптора устройства в ТС или DL. Если запрошенное обозначение структуры присутствует, сообщение об обозначении структуры с запрошенным обозначением структуры должно быть передано ТС или DL отправителю сообщения запроса обозначения структуры. В противном случае сообщение об обозначении структуры с 7 байтами обозначения структуры, которым присвоено значение = FF16, должно быть передано ТС или DL отправителю сообщения запроса обозначения структуры.

Если байты с 2 по 8 передаются как FF16, то сообщение запроса обозначения структуры позволяет клиенту определить версию последней структуры дескриптора устройства, присутствующей в ТС или DL. Если обозначение структуры отсутствует, то сообщение об обозначении структуры с 7 байтами обозначения структуры, которым присвоено значение = FF16, должно быть передано ТС или DL отправителю сообщения запроса обозначения структуры. Этот метод является обратно совместимым с ИСО 11783-10 версии 3 и предыдущими версиями.

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

По запросу

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

Переменная (от 8 до 40 байтов)

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

Данные процесса с конкретным назначением

Байт 1: Биты с 4 по 1

0001 Технические данные команды

Биты с 8 по 5

0000 Запрос обозначения структуры

Байты с 2 по п:

Обозначение структуры дескриптора устройства и при необходимости обозначение расширенной структуры. Байт 2 — это байт 1 массива данных обозначения структуры дескриптора устройства, а байт 8 — байт 7 массива данных обозначения структуры дескриптора устройства. Если запрашивается наличие конкретного обозначения расширенной структуры, то байт 9 является байтом 1 обозначения расширенной структуры, а байт п — последним байтом массива данных обозначения расширенной структуры. Это определение введено в ИСО 11783-10 версии 4, предыдущие версии используют ровно 7 байт со значениями, установленными в FF16. Если запрашивается конкретное обозначение расширенной структуры, то используется транспортный протокол.

  • В.6.3 Сообщение обозначения структуры

Сообщение обозначения структуры отправляется ТС или DL для информирования клиента о наличии запрошенной версии структуры дескриптора устройства в ТС или DL.

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

В ответ на сообщение запроса обозначения структуры

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

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

Байт 1: Биты с 4 по 1

0001

Переменная (от 8 до 40 байтов)

Данные процесса с конкретным назначением

Дескриптор устройства

Байты с 2 по п:

Биты с 8 по 5

0001

Обозначение структуры

Обозначение структуры дескриптора устройства и при необходимости обозначение расширенной структуры. Байт 2 — это байт 1 массива данных обозначения структуры дескриптора устройства, а байт 8 — байт 7 массива данных обозначения структуры дескриптора устройства. Если обозначение расширенной структуры доступно, то байт 9 является байтом 1 обозначения расширенной структуры, а байт п — последним байтом массива данных обозначения расширенной структуры. Передавать единичное 8-байтовое CAN сообщение с 7 байтами со значением = FF16, когда запрошенное обозначение структуры отсутствует. Если используется обозначение расширенной структуры, то должен использоваться транспортный протокол.

  • В.6.4 Сообщение запроса обозначения локализации

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

Если байты с 2 по 8 передаются как FF16, то сообщение запроса обозначения локализации позволяет клиенту определить версию локализации последнего дескриптора устройства, присутствующего в ТС или DL. Если обозначение локализации отсутствует, то сообщение обозначения локализации со всеми байтами обозначения локализации, которым присвоено значение FF16, должно быть передано ТС или DL отправителю сообщения за-

проса обозначения локализации.

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

По запросу

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

8 байтов

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

Данные процесса с конкретным назначением

Байт 1: Биты с 4 по 1

0001 Дескриптор устройства

Биты с 8 по 5

0010 Запрос обозначения локализации

Байты с 2 по 8:

7-байтовое обозначение локализации дескриптора устройства. Байт 2 — это байт 1 массива данных, а байт 8 — это байт 7 массива данных. Это определение введено в ИСО 11783-10 версии 4, предыдущие версии используют FF16.

  • В.6.5 Сообщение об обозначении локализации

Сообщение запроса обозначения локализации отправляется ТС или DL для информирования клиента о наличии запрашиваемой версии локализации дескриптора устройства на ТС или DL.

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

В ответ на сообщение запроса обозначения локализации

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

8 байтов

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

Данные процесса с конкретным назначением

Байт 1: Биты с 4 по 1

0001 Дескриптор устройства

Биты с 8 по 5

0010 Обозначение локализации

Байты с 2 по 8:

7-байтовое обозначение локализации дескриптора устройства. Байты с 1 по 6 определяются языковой командой PGN (см. ИСО 11783-7). Байт 7 зарезервирован, и ему присвоено значение FF16. Передавать все байты со значением = FF16, когда запрошенное обозначение локализации отсутствует.

  • В.6.6 Сообщение запроса передачи пула объектов

Сообщение запроса передачи пула объектов позволяет клиенту определить, разрешена ли передача (части) пула объектов дескрипторов устройств в ТС или DL.

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

По запросу

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

8 байтов

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

Данные процесса с конкретным назначением

Байт 1: Биты с 4 по 1

0001 Дескриптор устройства

Биты с 8 по 5

0100 Запрос передачи пула объектов

Байты с 2 по 5:

Запрошенный размер данных передачи в байтах

Байты с 6 по 8:

Зарезервировано, передавать как FF16

В.6.7 Ответное сообщение на запрос передачи пула объектов

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

В ответ на сообщение запроса передачи пула объектов

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

8 байтов

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

Данные процесса с конкретным назначением

Байт 1: Биты с 4 по 1

0001 Дескриптор устройства

Биты с 8 по 5

0101 Ответ на запрос о передаче пула объектов

Байт 2: Состояние

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

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

Байты с 6 по 8:

1 Недостаточно памяти. Не передавать пул объектов дескрип

торов устройств

Байты с 3 по 8:

Зарезервировано, передавать как FF16

  • В.6.8 Сообщение о передаче пула объектов

Сообщение о передаче пула объектов позволяет клиенту передачу (части) пула объектов дескрипторов устройств в ТС или DL. Передача пула объектов дескрипторов устройств может быть разделена на несколько сообщений о передаче пула объектов. В случае разделения передачи пула объектов на несколько сообщений о передаче пула объектов каждая отдельная передача пула объектов должна содержать завершенное описание объекта.

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

По запросу

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

Переменная

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

Данные процесса с конкретным назначением

Байт 1: Биты с 4 по 1

0001 Дескриптор устройства

Биты с 8 по 5

0110 Передача пула объектов

Байты с 2 по п:

Записи пула объектов

В.6.9 Ответное сообщение

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

о передаче пула объектов

В ответ на сообщение о передаче пула объектов

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

8 байтов

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

Данные процесса с конкретным назначением

Байт 1: Биты с 4 по 1

0001 Дескриптор устройства

Биты с 8 по 5

0111 Ответ на передачу пула объектов

Байт 2: Код ошибки

0 Ошибки нет, передача ОК

1 В ТС или DL закончилась память во время передачи

2 Прочая ошибка

Байты с 3 по 6:

Размер полученных данных в байтах

Байты с 7 по 8:

Зарезервировано, передавать как FF16

  • В.6.10 Сообщение о включении/выключении пула объектов

Это сообщение отправляется клиентом для завершения процедуры подключения к ТС или DL или для отключения от ТС или DL.

Для завершения процедуры подключения данное сообщение отправляется клиентом со значением байта атрибута команды, установленным на «Включить». Это указывает, что пул объектов дескриптора устройства полный и готов к использованию. Данная команда отправляется после передачи пула объектов дескриптора устройства, после переопределения или добавления любого объекта в пул объектов дескриптора устройства во время работы либо при сравнении запрашиваемых обозначений указывает на то, что версия пула объектов дескриптора устройства в устройстве совпадает с версией пула объектов дескриптора устройств, доступной в ТС или DL. В случае, если пул объектов дескриптора устройства не был загружен, ТС или DL должны включить пул объектов дескриптора устройства из последнего запроса обозначения структуры, на который был дан успешный ответ.

Для отключения от ТС или DL это сообщение отправляется со значением байта атрибута команды, установленным на «Деактивировать». Это указывает на то, что клиент намеренно отключается от ТС или DL.

Определение значения байта атрибута команды для деактивации подключения к ТС или DL было введено в стандарте ИСО 11783-10 версии 4.

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

По запросу

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

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

Байт1: Биты с 4 по 1 0001

8 байтов

Данные процесса с конкретным назначением

Дескриптор устройства

Биты с 8 по 5 1000

Байт 2:

Байты с 3 по 8:

Включение/выключение пула объектов

Атрибут команды, FF16 = значение команды включения пула объектов, 0 = значение команды выключения пула объектов

Зарезервировано, передавать как FF16

  • В.6.11 Ответное сообщение о включении/выключении пула объектов

Это сообщение отправляется ТС или DL клиенту для подтверждения сообщения о включении/выключении пула объектов дескриптора устройства.

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

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

После успешного выключения пула объектов дескриптора устройства ТС или DL должны ответить байтом 2, установленным для указания отсутствия ошибок. Максимальное время отклика — 2 с.

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

В ответ на сообщение о включении пула объектов

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

8 байтов

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

Данные процесса с конкретным назначением

Байт 1: Биты с 4 по 1 0001

Дескриптор устройства

Биты с 8 по 5 1001

Включение/выключение пула объектов

Байт 2:

Коды ошибок (0 — нет ошибок)

Бит 1=1 =

Существуют ошибки в пуле объектов дескриптора устройства,

обратитесь к байтам 3—7 для получения дополнительной ин

формации об ошибках

Бит 2 = 1 =

Закончилась память ТС во время активации

Бит 3 = 1 =

Любая другая ошибка

Бит 4 = 1 =

Пул объектов не активирован. Другой DDOP с той же меткой

структуры уже существует в ТСа

Биты 5—8 =

Зарезервировано, передавать как 0 (ноль)

Байты 3, 4:

Родительский идентификатор неисправного объекта, передает

как NULL идентификатор объекта, если нет ошибок пула объектов

Байты 5, 6: Идентификатор объекта неисправного объекта, передайте как

нулевой идентификатор объекта, если нет ошибок пула объектов

Байт 7: Коды ошибок пула объектов (0 = нет ошибок)

Бит 1=1= Метод или атрибут не поддерживаются ТС или DL

Бит 2 = 1= Ссылка на неизвестный объект (отсутствующий объект)

Бит 3 = 1= Прочая ошибка

Бит 4 = 1= Пул объектов дескриптора устройства был удален из кратковременной памяти

Биты с 5 по 8 = Зарезервировано, передавать как 0 (ноль)

Байт 8: Зарезервировано, передавать как FF16 а Определение этого бита введено в ИСО 11783-10 версии 4.

  • В.6.12 Сообщение об удалении пула объектов

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

Могут быть удалены только пулы объектов дескриптора устройства, определенные клиентом. Пулы объектов дескриптора устройства, полученные от FMIS, не затрагиваются.

Для ТС или DL версии 3 или более ранних было определено сообщение об удалении пула объектов, чтобы клиент мог иметь возможность для удаления всего пула объектов дескриптора устройства перед отправкой обновленного или измененного пула объектов дескриптора устройства с сообщением о передаче пула объектов. Из-за возможных ссылок протоколированных данных на дескриптор устройства или устройство, уже назначенное на задачу, возникают ситуации, когда сервер ТС не может успешно выполнить это сообщение. В таких ситуациях для ТС версии 3 или более ранних было неясно, должно ли ответное сообщение об удалении пула объектов использоваться для ответа клиенту на ошибку удаления пула объектов или сообщение об удалении пула объектов может быть отклонено сообщением подтверждения данных процесса.

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

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

По запросу

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

8 байтов

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

Данные процесса с конкретным назначением

Байт 1: Биты с 4 по 1

0001 Дескриптор устройства

Биты с 8 по 5

1010 Удаление пула объектов

Байты с 2 по 8:

Зарезервировано, передавать как FF16

В.6.13 Ответное сообщение об удалении пула объектов

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

В ответ на сообщение об удалении пула объектов

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

8 байтов

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

Данные процесса с конкретным назначением

Байт1: Биты с 4 по 1

0001 Дескриптор устройства

Биты с 8 по 5

1011 Ответ на удаление пула объектов

Байты с 2 по 8:

Код ошибки: 0 = нет ошибки; 1 = ошибка

Байт 2:

Подробная информация об ошибке:3

Байт 3:

0 = на пул объектов ссылаются данные задачи

1 = сервер не может проверить ссылки на пул объектов FF16 = сведения об ошибке недоступны

Байты с 4 по 8:

Зарезервировано, передавать как FF16

а Определение этого байта введено в стандарте ИСО 11783-10 версии 4, в стандарте ИСО 11783-10 версии 3 и более ранних версиях; этот байт передавался как FF16.

В.6.14 Сообщение об изменении обозначения

Это сообщение предназначено для обновления обозначения объекта.

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

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

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

Байт 1: Биты с 4 по 1

0001

По запросу

Переменная

Данные процесса с конкретным назначением

Дескриптор устройства

Байты 2, 3:

Байт 4:

Байт 5 — п:

Биты с 8 по 5

1100

Изменить обозначение

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

Длина обозначения, количество байтов, диапазон значений от 0 до 128 для передачи максимум 32 символов UTF-8

Кодированное обозначение UTF-8, нет метки порядка байтов.

В.6.15 Ответное сообщение об изменении обозначения

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

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

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

8 байт

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

Данные процесса с конкретным назначением

Байт 1: Биты с 4 по 1 0001

Дескриптор устройства

Биты с 8 по 5 1101

Ответ на изменение обозначения

Байты 2, 3:

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

Байт 4:

Код ошибки: 0 = нет ошибки; 1 = ошибка

Байт 5 — п:

Зарезервировано, передавать как FF16

  • В.7 Сообщение подтверждения данных процесса (PDACK)

Это сообщение отправляется Мастером клиента или ТС или DL для подтверждения или отклонения команд и данных процесса. Причины приведены в наименее значимом байте значения данных процесса. Когда сообщенный код ошибки данных процесса не связан с конкретным номером элемента или определенным DDI, значения номера элемента или DDI должны быть установлены на «недоступно». Значение «недоступно» для номера элемента равно FFF16, а значение «недоступно» для DDI равно FFFF16.

Чтобы избежать ненужной загрузки шины, сообщение подтверждения данных процесса с кодом ошибки данных процесса = 0 не должно передаваться в ответ на команды данных процесса: 016,116,216, 316,916, D16, Е16 и F16.

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

По запросу

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

8 байтов

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

Данные процесса с конкретным назначением

Байт1: Биты с 4 по 1 1101

Подтверждение данных процесса (PDACK)

Биты с 8 по 5

Номер элемента (наименее значимый полубайт), отправлять как

F16, если он неприменим к коду ошибки

Байты 2:

Номер элемента (наиболее значимый байт, MSB), отправлять как

FF16, если он неприменим к коду ошибки

Байт 3, 4:

DDI, отправлять как FFFF16, когда это неприменимо к коду ошибки

Байт 5:

Коды ошибок данных процесса (0 = нет ошибок)

Бит 1=1 =

Команда данных процесса не поддерживается

Бит 2 = 1 =

Недействительное число элементов

Бит 3 = 1 =

DDI не поддерживается элементом

Бит 4 = 1 =

Метод инициализации не поддерживается

Бит 5 = 1 =

Данные процесса не могут быть установлены

Бит 6 = 1 =

Недействительный или неподдерживаемый интервал или порог

Бит 7 = 1 =

Значение данных процесса не соответствует определению DDIa

Бит 8 = 1 =

Значение данных процесса находится за пределами рабочего диапазона данного устройства1

Байт 6: Биты с 4 по 1

Команда данных процесса, для которой передается это PDACK-сообщение, отправлять как F16, когда она неприменима к коду ошибкиь. До версии 4 эти биты передаются как F16

Биты с 8 по 5

Зарезервировано, передавать как F16

Байты 7,8:

Зарезервировано, передавать как FF16

3 Определение этого бита введено в ИСО 11783-10 версии 4.

ь Определение этих 4 бит введено в стандарт ИСО 11783-10 версии 4.

  • В.8 Сообщения о состоянии

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

  • В.8.1 Сообщение о состоянии ТС

Это сообщение должно быть отправлено ТС, чтобы указать текущее состояние задачи.

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

2 секунды и при изменении любого байта в этом сообщении. Между сообщениями о состоянии должно пройти не менее 200 мс

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

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

8 байт

Данные процесса с конкретным назначением

Байт 1:

Биты с 4 по 1

1110

Состояние ТС

Биты с 8 по 5

1111

Номер элемента, установлен как недоступный1

Байты 2:

FF16

Номер элемента, установлен как недоступный1

Байт 3, 4:

FFFF16

DDI, установлен на недоступный1

Байт 5:

Бит 1 = 1 =

Переход от 0 к 1:

Переход от 1 к 0:

Бит 2 = 1 =

Бит 3 = 1 =

Бит 4 = 1 =

Биты 5—7 = 0 =

Бит 8 = 1 =

Текущее состояние TC/DL

Общие значения за задачу активные, задача запущена или возобновлена, общие значения за задачу могут накапливаться

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

Общие значения за задачу внутренней управляющей функции останавливаются и могут быть запрошены ТС или DL через серию команд запроса значения

ТС или DL заняты сохранением данных в постоянной памяти

ТС или DL заняты чтением данных из постоянной памяти

ТС или DL заняты выполнением команды В.6 (сообщения дескриптора устройства)

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

Недостаточно памяти ТС или DL

Байт 6:

Исходный адрес клиента, для которого выполняется команда В.6 (действительна только в том случае, если установлен Байт 5, Бит 4, или иначе передается значение = 0)

Байт 7:

Команда В.6 (Байт 1), которая выполняется (действительна только в том случае, если установлен Байт 5, Бит 4, или же передается значение = 0)

Байты 7,8:

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

  • В.8.2 Сообщение задачи клиента

Это сообщение должно быть отправлено всеми клиентами в ТС или DL, чтобы указать текущее состояние задачи клиента.

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

2 секунды при каждом изменении состояния задачи. Между сообщениями о состоянии задачи клиента должно пройти не менее 200 мс

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

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

8 байтов

Данные процесса с конкретным назначением

Байт1: Биты с 4 по 1 1111

Задача клиента

Биты с 8 по 5 1111

Номер элемента, установлен как недоступный3

Байты 2: FF16

Номер элемента, установлен как недоступный3

Байт 3,4: FFFF16

DDI, установлен на недоступный3

Байт с 5 по 8: Бит 1

Текущее состояние ТС или DL: общие значения за задачу активные

Бит с 2 по 32 0

(полученные в сообщении состояния контроллера задач, байт 5, бит 1).

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

а Недоступное значение для этого атрибута введено в ИСО 11783-10 версии 2. ТС или DL должны игнорировать этот атрибут при обработке сообщений состояния контроллера задач.

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

Диаграмма взаимосвязи XML-элементов

С.1 Взаимосвязь XML-элементов

На рисунках С.1 и С.2 показана диаграмма взаимосвязи для всех объектов. Содержимое XML-файла должно соответствовать связям, указанным на диаграмме. Объекты, показанные на рисунках С.1 и С.2, не всегда содержат идентификаторы внешних ключей, поскольку это может быть определено последовательностью определений в XML-файле.

Взаимосвязь XML-элементов указывает, например, что объект Task (задача) имеет связь «от одного к нулю или больше» к WorkerAllocation (назначение работников); задача может как не иметь назначенных работников, так и иметь одного или нескольких. Когда назначается один или несколько работников, это означает, что определение WorkerAllocation должно следовать определению TaskHeaderData (данные заголовка задачи), чтобы получить его связь с задачей. Worker также имеет прямую связь «от одного к нулю или больше» к Task. Это означает, что Worker может быть ответственным работником для нуля или более Task.

Завершение строки в каждой связи должно читаться как «Противоположное окончание строки» и определять множественность от исходного объекта по отношению к другому объекту. Например, отношение между Worker и WorkerAllocation читается следующим образом: Worker может возникать в нуле или более WorkerAllocation (0 + crow foot), а объект WorkerAllocation привязан ровно к 1 работнику (single bar).

____2"""'

Customer (CTR) 0 Custom c rid I CustomeitastName ? Custo-metFIrstName 7 CustomerAd dress ? Custom eri*hone_.


OperTechPrartl се (ОТР)


СгорТуре (CTP)

(3'CrO‘pTypeld I CropType Designator 7 ProductGroupEdRcf 7 «CropVariety?


CropVariety (CVT)

CropVarietyJd Г CropVarietyOesignator ? Product! dRef


Farm (FRM)

Ф Farmld Ю-—I FarmDesignator 7 FarmAddress «. TCustomerfdRef


Ограничено - 2 слоями

участков поля


Partfteld(PFD)

@ Partfleldld ? Partite IdCode I PartfteldDesignaror I PartficldArca ? CustomeridRef 7 FarmidRef ? CropTypeldRef ?CropVarfetyidRef TFieidURef 7 «Poiyjpm? ? «LineString?

7 «Point?

7 «GuidanceGroup?


"вие зоны обработки ■


Polygon (PIN)

I PolygonType ? Polygon Designator ? Polygon Area

7 Polygon. Colour 7 Polygon Id

I cLineString?


4-


Grid (GRO)


1 GridMIitirnumNorth Position ! GrtdMtnlmumEastPcsitlon

• GrtdCellNorthSbe I Grid Cd lEastStoc I GridMaxEmumColumn

1 GridMaximirmRow

I Filename

? FUdength

I Grid Type 7 Treatment oncCode


зона обработки


LineS tring (LSG)

I UneStringType 7 UneString Designator 7 Lin eStrir^Width 7 LineS tringtength 7 UneStrtngColouR 7Lkn eStringid Г «Point?


TreatmentZone (TZN)

Qfl TrcotmeniZotteCodc

7 Trcatmt n tZ one De signatOr TTreatmentZ one Colour

7 < Polygon?

7 « Process DM» Vari able?


Point (P NT)


IPotatType ? PointDesignaEor I PositionNorth ! PosltionEast tPoshionUp 7 Pointed our ?Pointid

7 P о tntH orizo itta lAccuracy 7 PointVerticalAccuracy ? Filename ?FUetength


PtncessDataVariable (pov)


I ProccssDataDDl

I ProcessDataValue 7 PraductldRef ? DericeEtementldRef ? va ue Presen tati onl dRef ? ArtualCulEuralPrarticeValuc 7 EtementiypeinstanceValue 7 «ProcessDataVariable?


ю-


Легенда


Кодирование данных


& ::=Id Attribute I: :=Обязатель ный

?: :=Необязягел ь н ый <>::=Встриснный отдельный элемент или синеок элементов


ICulturalPractioeldRcf Х> ? Operation TeehniqueldRef


TadtCrSq

@ Ta skid 7 TadcDesfenator ?CustomcrfdRef 7 FarmldRef ? PartfleEdldRef ? Responsible Workerl dRef 1 TadcStatus ? DefaultTreatmtniZoneCode ? PosttionLostTreMmentZoneCode 7 OutOfH cldTreatmcn tZftneCodc 7 cTreatmeniZoDe?

?<Time> ? «OperTechPractice? 7 «WorkerAllocatiou?

7 «DerkeAUoca tfon?

7 «Conncctioa?

7 «ProductAllocation?

7 «DalaLogT rigger?

7 «CommentAUocation? 7<TizneLog> 7«Grid?

7 «ControlAss^nmcnt?

7 «GuidanceAltocation?


_ ProductAllocation (PAN)


i Pro ductl dRef 7 QuantttyD DI ? Quantity Value ? TransferMode ? D erice ElementldRcf ? Value Presentation!dRef ? «AllocationSUmp?


Product (PDT)

@ Productld I ProductDesigpMor 7 ProduttGroupldRef ? Value Presents ti onl dRef 7 Quantity DD1 7 ProductTypc 7 MbctureRedpeQuantity 7 DmshyMassPerVolume 7 DensityMassPerCount 7 DcnsityVolumePerCount 7 «ProductRelation?


ProductRelation (PRN)


$ProductidRef 1 Quantity Value


ProductGroup (PCS’)


& ProductGroupId


’ -----CH- । pnoductGroupDesignator


? ProductGroupType


x>-


OpcrationTcchnique (OTQ)

& OperatfoaTechnlqueld I OpcratfonTcchniqueDrsIgnator


Worker (WKR)

@ Workerld I WorkerLastName 7 WorkcrFfcrstName 7 WorkerAddress

7 Worke*Phone ? Work erUcense Number


_q^ Worker Allocation (WAN)

<X I WorkerldRef

?<A11ocationStacnp> -f-Q


ControlAssignment (CAT)

1 SouroeClientNAME 1 UscrtlientN АМЁ I Sourcestructure Label I UserStructureLabel I SourceElementNuinber ’UserEternentN Limb er iProoessDauDDi 7 «All ocatiemStamp?


Tim eLog (TLG)


! Fileiame ? Fildength 1 TtmeLogType


Time (TIM)

I Aart

7 (Stop | Duration} 'Type ? «Position?

? cDataLogValue?


Position (PTN)

I PositionNorth I Position East

7 Position Up I PositionStatus 7PDOP 7HDOP

7 NumbcrOfSate-Ultes TCpsLTtcTime

7 GpsUtcDate


DataLogrrigger (DLT)


1 DataLogDD!

I DataLogMethod 7 DataLogDistancefnteival ? DaULogTimclntcrval 7 DafcaLogTh rcsbol dMin im um 7 Data Lo^ThresboldMaxi mum 7 DataLogTh re-shoIdChange-? DeviceElementld Ref ? Vai uePresen tatii onldRef JDataLogPGN

7 DaLiLogPGNSlartBit 7 DaULogPGNStopBit


Value Pres oitation(VHi) @ Value Presen tationid t Offset

I Scale

I NumberOfDectmaLs ? UnitDesigBator

7 ColourUgendldRef


-4'


ColourLegend (CLP)

ColourLcgendld 7 DefaultGolcur 1 «GolourRange?


CotourRaqge (CRG)

I MinimumValue I Maxi mum Value I Colour


Cultural Practice (CPC)

& CuituralPractfceld I QilturaLPracticeDeslgnator 7 « DperationT erhniqueRefe rente*


Ор ига tionTechnlque Reference (OTR)


I OperadonTechniqueidRef


CommcntAllocation (CAN) ------O^------------------------

7 Coded Comm entld Ref « O+ ? CodedCommentLLstValueld Ref | —? FrceCommentText !

J ! 7«AUocationSlamp> !


Coded Coinmen tLlstValue (CCL) @ CodedConuncntListVaiueld I CodedCommentUstValue Designator


I Start

7 (Stop | Duration} I Type

7 «Position?


DataLogValuc (DLV)


! ProcwsDaUDOI I ProccssDataValue 1 DerioeElementldRef YDaULogPGN 7 DataLogPGNStartBit PDatalagPGNStopBit


___±___T ! A___ Devteedement (DET)

@ Device Etemendd I DevkeElemenlObjectld 1 DeviceHementType 7 DevlreEteroentDesigDator I DevfceEle men tN umber I ParentObjectld 7 «DcviceObjectRcferciicc?


Wt


CodedComment (CCT) G? Coded Coinmen Ш I CodedCommcntDesignator I Coded Commentscope


H-


7CodedCommentGroupldRef ^O--? «CodedComm en tLLstVal ue>


Cod cdCommentG roup (CCG)

CodedCommoitGroupld I CodtsdCommcntGroupDcsignator


Allocations tamp (ASP)


Device Allocation (DAN)

1 aientNAMEValue ?OientNAMEMask

7 DevlceldRef

7 «All ocationStamp?


Connection (CNN) I DevkcldReCO ■__CX | DeviceElemcntldRef-O

I Device!dRef_l I DevkeEJemenddRef l


connector


______Dcvkc(DVC)______ @Devfceld

7 Device De signa tor

7 DcviceSoftwarcVerstoQ lOtentNAME

7 DeviceSerialN umber

! DeviceStructureLabel

1 DeviceLocalkationLabd

! «DcvkeHemenC*

7 «DevioeProcessData?

7 < Device Prop erty?

7 «DeviceValuePresen tation?


DevteeProcessData (D₽D)

4® Dev ice Process Da taObj actld I DevkeProcmsDataDDI

I DeviceProcessDataProperty I DeviceProcessDaUTrlggerMethods ? DwteeProcessDaU-DesIgnator ? DeviceValue Presen tationObjectid


•4


______% t DeviceObjectRer^re-nCe (DOR)


DeviceValuePresen ration (DVP)

@ DcviccVaiuePmffltationOtyectid ! Offset

I Scale

1 No mberOfOedmals

? UnttDesignator ;


@ DeviceObjectld


Derice Property (DPT) @D evice Property Object! d I DcvirePrnpertyDDI

I DcvtecPropcrtyValuc 7 DevtcePropertyD esigna tor ? DeviceValue Presen tationObjectid


Рисунок C.1 —Диаграмма взаимосвязи XML-элементов, часть 1


Ограничено 2 слоями ■ участков поля


Partfield (PFD) ® Partfieldld ? PartileldCode 1 PartfleldDesignator I PartfieldArea 7 CurtomCrldRef 7 FartnldRef 7 CropTypefdRef 7 CropVarietyldRef ? FieldldRcf ? «Polygon* ? «LineString* 7 «Point* ? «GuldanceGroup*


40

граница


GuldanceGroup (GGP)

(g GuidanceGroupId

7 GuidanceGroupDesignator ! «Guidance Pattern*

2 «BoundaryPolygon*


■+


Polygon (PLN)

! PoiygouType ? PolygonDesignator 7 PolygonArea

7 Polygon Colon г 7 Polygon Id ! «LineString*


GuidanceAUocation (GAN)

! GuidanceGroupIdRef ! «AllocationStamp* 7 «GuidanceShift*


Task (TSK)

@ Taskld 7 TaskDesignator 7 CustomerldRef ? FarmidRcr 7 PartfieldldRef

7 ResponsibleWorkerldRef ! TaskStatus

7 DefaultTreatmentZoneCode 7 Position IxtstTrealmentZoneCode 7 OutOfFieldTreatmentZoneCode

7 «Treatmentzone* ?<Time>

7 «OperTechPraclice*

7 «WprkerAllocation*

2 «DeviceAllocation*

7 «Connection*

7 «ProductAllocation*

7 «Datat-ogTrigger*

7 «CommentAllocation*

7 «TimeLog*

7 «Grid*

7 «ControlAssignmcnt* 7 «GuidanceAUocation*


граница


LineString (LSG)

! LlncStringType

? LineStringDesignator ? LineStringWidth

7 LineStringLcngth

? LineStringColour

7 LineSt.rin.gId

! «Point*


-04


Point (PAT) iPointType 2 PointDesignator


! PositionNorth ! PosltionEast 7 PotitionVp 7 PointColour 7 Pointld ? PointliorizontalAccuracy 7 PointVcrticalAccuracy ? Filename 7 Filelengtb


-4-

GuidanccPattern (GPN)

@ GuidancePatteruId ? GuidancePatternDesignator I GuidancePatternType ? GuidancePatternOptions 7 GuidancePatternPropagationDirection 7 Guidance Pattern Extension ? GuidanccPatternlleading ? GuidancePatternRadius 7 GuidancePatternGNSSMetbod

? GnidancePatternHorizontalAccurary ? GuidagcePatternVertkalAccuracy 7 BaseStationtdRcf ? OriginalSRID 1 NumberOfSwathsLeflt ? AuniberOfSwathsRight 1 «LineString* 7 «Boundarypolygon*


BaseStation (BSN)


@ BaseStationld

! BaseStationDesignator ! BaseStationNorth ! BaseStationEast ! BascStationUp


40

GuidanceShiTt (GST)


! (GuidauceGroupldRef | Guidance PattcrnidRef} 7 GuidanceEastShift 7 GuidanceNorthShift 7 PropagationOflset 7 «AllocationStamp*



AllocadonStamp (ASP)

1 Start

7 {Stop [ Duration} ’Type

7 «Position*

i


Рисунок C.2 — Диаграмма взаимосвязи XML-элементов, часть 2


Приложение D (обязательное)

XML-элементы и атрибуты

D.1 XML-элементы

XML-атрибуты XML-элемента описаны в настоящем приложении в таблицах с шестью столбцами: - атрибут, имя XML-атрибута.

  • - XML, тег атрибута XML.

  • - использование, «г» обозначает обязательный (required), “о” — необязательный (optional).

  • - тип, спецификация типа XML-атрибута.

  • - длина/диапазон, количество символов или диапазон значений этого атрибута.

  • - комментарий, дополнительное объяснение или ограничения на формат атрибута.

Примечание — В XML-атрибутах также перечислены дочерние XML-элементы.

Таблица D.1 — Пример атрибутов XML-элементов

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Атрибут_1

А

г

xs:datetime

Макс. 29

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

Атрибут _2

В

о

xs:datetime

Макс. 29

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

Элемент_1

о

xs:element

пример дополнительного включения одного XML-элемента Element_1

Тип xsd:dateTime представляет определенную дату и время в формате CCYY-MM-DDThh:mm:ss.sss, представляющий собой конкатенацию форм xsd:date и xsd:time, разделенных буквой «Т». Все те же правила, которые применяются к типам xsd:date и xsd:time, применимы и к xsd:dateTime.

В конце значения может быть добавлено необязательное выражение часового пояса. Буква Z используется для обозначения Всемирного координированного времени (UTC). Все остальные часовые пояса представлены их разницей со Всемирным координированным временем в формате +hh:mm или -hh:mm. Эти значения могут варьироваться от -14:00 до 14:00. Например, восточное время США, которое отстает от UTC на пять часов, представлено как -05:00. Если значение часового пояса отсутствует, оно считается местным временем; оно не считается UTC.

D.2 Allocationstamp — ASP

Тип:

Данные задачи

Описание:

XML-элемент Allocationstamp (отметка распределения) указывает запись события распределения. Дополнительно в спецификации Allocationstamp может быть записана позиция. Все XML-элементы Allocationstamp, которые были предоставлены FMIS, должны иметь тип «запланировано» и все XML-элементы Allocationstamp, которые были предоставлены MICS, должны иметь тип «эффективно».

У всех XML-элементов Allocationstamp должно быть определено значение атрибута Start (запуск). Атрибут Duration (продолжительность) должен всегда иметь положительное значение и быть равен времени, прошедшему между Start и Stop (остановкой). Таким образом, спецификация конечного XML-элемента Allocationstamp может включать либо Start и Stop (Duration может быть рассчитан), либо Start и Duration (время Stop может быть рассчитано). Допускается спецификация бесконечного XML-элемента Allocationstamp, например, если записывается только время Start.

В ИСО 11783-10 версии 4 тип данных datetime был расширен для включения информации о часовом поясе или явной установки значения UTC. Если часовой пояс известен, требуется либо указать время в UTC, добавив индикатор Z, либо включить смещения часовых поясов в атрибуты Start и Stop. Явное использование UTC или использование информации о часовом поясе, когда местное время используется системой FMIS для нормализации данных, поступающих из различных часовых поясов. Если информация о часовом поясе неизвестна, то все времена выражаются в местном времени без информации о часовом поясе.

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

Включен XML-элементом:

— CommentAllocation

— DeviceAllocation

— ProductAllocation

— WorkerAllocation Включает XML-элемент:

— Position

Таблица D.2 — Атрибуты Allocationstamp

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарии

Start

А

г

xs:datetime

Макс. 29

Время запуска. Формат: yyyy-mm-ddThh:mm:ss. sss плюс дополнительная индикация часового поясаа

Stop

В

оь

xs:datetime

Макс. 29

Время окончания. Формат: yyyy-mm-ddThh:mm:ss.sss плюс дополнительная индикация часового поясаа

Duration

С

оь

xs:unsignedLong

От 0 до (232-2)

Время между Start и Stop, в секундах

Type

D

г

xs:NMTOKEN

1,4

Тип Allocationstamp, возможные значения: 1 = Запланировано.

4 = Эффективно (Реализовано)

Position

о

xs:element

Включает до 2 XML-элементов Position, которые представляют собой позицию при значениях атрибутов Start и Stop XML-элемента Allocationstamp

a Информация о часовом поясе представлена в версии 4 стандарта ИСО 11783-10.

ь Либо Stop, либо Duration должны быть указаны дополнительно к Start для создания конечного XML-элемента Allocationstamp.

ПРИМЕР 1. Информация о часовом поясе отсутствует, время записывается по местному времени. <ASPA="2003-08-20T08:10:00” D=”4”>

<PTN А=-”54.588945” В=”9.989209” D=”3”/>

</ASP>

  • <!— устанавливают отметку времени с точностью в секундах — >

<ASP А=”2003-08-20Т08:10:00” С=”3512” D=”4”/>

  • <!— отметка времени с точностью в долях секунды — >

<ASPA=”2003-08-20T08:10:00.245” С=”3512” D=”4’7>

ПРИМЕР 2. Информация о часовом поясе доступна в системе, но время явно записывается только в формате UTC.

<ASPA=”2003-08-20T07:10:00Z” С=”3512” D-”4”/>

ПРИМЕР 3. Информация о часовом поясе доступна, время записывается по местному времени с информацией о часовом поясе; например, для центральноевропейского времени время запуска для того же момента времени, что и в Примере 2, будет

<ASP А=”2003-08-20Т08:10:00+01:00” С=”3512” D-”4”/>

или для местоположения в часовом поясе 0 этот же момент времени равен

<ASP А-”2003-08-20Т07:10:00+00:00” С=”3512” D=”4”/>

D.3 AttachedFile — AFE

Тип:

Внешние данные

Описание:

XML-элемент AttachedFile (прикрепленный файл) указывает проприетарный файл производителя, который должен быть частью набора файлов передачи данных.

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

Если прикрепленный файл происходит от другого производителя (например, производителя FMIS), содержимое может быть проигнорировано ТС, если прикрепленный файл имеет непредопределенный тип. Если XML-атрибут Preserve (Сохранять) имеет значение 1, то ТС может опустить XML-элемент AFE из набора файлов передачи полученных данных и немедленно удалить прикрепленный файл. Значение 2 для XML-атрибута Preserve сигнализирует о том, что ТС должен сохранить этот XML-элемент и файл и включить их в набор файлов передачи данных, отправленный обратно в FMIS.

Чтобы предотвратить ненужную передачу данных, атрибуту В (Preserve) должно быть установлено значение 1, если нет необходимости для ТС передавать прикрепленный файл обратно в FMIS. Примером такого варианта использования может служить обновленный языковой файл контроллера задач.

Включен XML-элементом: — ISO11783_TaskData

Таблица D.3 — АтрибутыAttachedFile

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарии

FilenameWithExtension

A

r

xs:ID

12

Уникальное имя прикрепленного файла. Для предопределенных типов файлов имя файла может быть фиксированным. Формат — это формат имени файла 8.3, состоящего из заглавных символов в диапазоне A-Z и 0—9 (например, «PROPDATA.BIN»)

Preserve

В

r

xs:NMTOKEN

От 1 до 2

  • 1 = Контроллеру задач не нужно сохранять прикрепленный файл.

  • 2 = Сохранить на ТС и отправить обратно в FMIS

ManufacturerGLN

C

r

xs:anyLJRI

Макс. 32

Пусто для привязок, предопределенных стандартом ИСО 11783. Для других привязок он должен содержать номер GS1 GLN (глобальный номер местонахождения) производителя

FileType

D

r

xs:unsignedByte

От 1 до 254

Предопределенные типы (ManufacturerGLN пуст):

1 = LINKLIST (фиксированное имя файла 'LINKLIST.XML', все буквы прописные).

Примечание — Не более одного файла LINKLIST.XML может быть указано в TASKDATA.XML.

Диапазон от 1 до 127 зарезервирован для предопределенных ИСО типов файлов. Диапазон от 128 до 254 предназначен для проприетарных типов файлов производителя.

Для непустого ManufacturerGLN установка соответствующего значения происходит на усмотрение производителя

FileVersion

E

0

xs:string

Макс. 32

Номер версии файла для создания уникальной связи между TASKDATA. XML и прикрепленным файлом

FileLength

F

0

xs:unsignedLong

От 0 до (232-2)

Длина прикрепленного файла в байтах

ПРИМЕР.

<AFE A=”LINKLIST.XML” В=”1” С-"" D=”1” Е=”3.2” F=”6400’7>

<AFE A=”CLAASEXT.DAT” В=”1” C=”urn:epc:id:sgln:4250285.50000.9” D=”1”/>

<AFE A=”PRESERVE.DAT” B=”2” C=”urn:epc:id:sgln:0614141.33254.1” D=”7"/>

D.4 BaseStation — BSN

Тип:

Данные кодирования

Описание:

XML-элемент BaseStation описывает базовую станцию системы позиционирования.

Примечание — Этот XML-элемент представлен в стандарте ИСО 11783-10 версии 4.

Указан XML-элементом:

— GuidancePattern

Включен XML-элементом: — ISO11783_TaskData

Таблица D.4 — Атрибуты BaseStation

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

BaseStationld

A

r

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор

BaseStation. Формат: (BSN|BSN-)([0—9])+ Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

BaseStationDesignator

В

r

xs:string

Макс. 32

Обозначение BaseStation

BaseStationNorth

C

r

xs:decimal

От -90,0 до 90,0

Широта координат положения

BaseStation по WGS-84 (N)

BaseStationEast

D

r

xs:decimal

От-180,Одо 180,0

Долгота координат положения

BaseStation по WGS-84 (Е)

BaseStationUp

E

r

xs:long

От (-231+1)дО (231-1)

Высота положения BaseStation по эллипсоиду WGS-84 в мм

ПРИМЕР.

<BSN A=”BSN4” B=”RTK Reference 1” C=”54.588945” D=”9.989209” E=”523867”/>

D.5 CodedComment — CCT

Тип:

Данные кодирования

Описание:

XML-элемент CodedComment (закодированный комментарий) описывает предопределенные комментарии, которые можно использовать для комментирования задач. Комментарии могут быть сгруппированы в CodedCommentGroup, установив ссылку на эту группу в CodedCommentGroupIdRef. Закодированный комментарий может содержать список возможных значений (например, низкий, средний, высокий). Эти значения описаны в CodedCommentValue. На одно из этих значений может быть указана ссылка при назначении комментария задаче.

Указан XML-элементами:

— CommentAllocation

Включает XML-элемент:

— CodedCommentListValue

Таблица D.5 — Атрибуты CodedComment

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

CodedCommentld

A

r

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор

CodedComment. Формат: (ССТ|ССТ-) ([0—9])+ Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

CodedCommentDesignator

В

r

xs:string

Макс. 32

Обозначение CodedComment

CodedCommentScope

C

r

xs:NMTOKEN

От 1 до 3

Выбор одного атрибута:

  • 1 = точка

  • 2 = глобальный

  • 3 = непрерывный

CodedCommentGroupIdRef

D

0

xsJDREF

От миним. 4 до макс. 14

Ссылка на идентификатор группы CodedCommentGroup.

Формат: (CCG|CCG-) ([0—9]) +

CodedCommentListValue

0

xs:element

BwuoHaeTcnncoKCodedComment-

ListValue XML-элемента

ПРИМЕР 1. Комментарии CodedComment с областью охвата точкой

<ССТА=”ССТ1” В="Дозаправка" С=”1’7>

<ССТА=”ССТ2” В=”Полевая операция прервана” С=”1’7>

ПРИМЕР 2. Комментарии CodedComment с областью охвата глобальной и с CodedCommentListValue

<ССТ А=”ССТЗ” В=”Сорняки” С=”2”>

<CCL A-”CCL12” B=”Hem сорняков’7>

<CCL A=”CCL13” В=”несколько мелких сорняков”/>

<CCL A-”CCL14” В=”несколько крупных сорняков’7>

<CCL A=”CCL15” В-”множество мелких сорнякое’7>

<CCL A=”CCL16” В-”множество крупных сорнякое’7>

</ССТ>

<ССТ А=”ССТ4” В=”Погода” С -”2”>

<CCL A-”CCL17” В-”Мелкий дождь’7>

<CCL A=”CCL18” В=”Влажность’7>

<CCL A=”CCL19” В=”3аморозки, твердая почва’7>

<CCL A=”CCL20” В=”Дождь”/>

<CCL A=”CCL21” B=”Omcymcmeue еетра’7>

<CCL A=”CCL22” В=”Легкий мороз’7>

<CCL A-”CCL23” В=”Слабый eemep’7>

<CCL A=”CCL24” В=”Лиеень’7>

<CCL A-”CCL25” В-”Очень жарко’7>

<CCL A=”CCL26” В=”Очень ветрено”/>

<CCL A~”CCL27” B=”Cyxo’7>

</CCT>

<CCT A=”CCT5” В=”Состояние почвы” С =”2”>

<CCL A=”CCL28” В=”влажно’7>

<CCL A=”CCL29” B=”cyxo на поверхности, влажно внизу ”/>

<CCL A-”CCL30” В=”влажно на поверхности, сухо внизу’7>

<CCL A=”CCL31” В-”посевное место крупнозернистое’7>

<CCL A=”CCL32” В-”посевное место с нормальной зернистостью’7>

<CCL A=”CCL33” В=”посевное место мелкозернистое’7>

<CCL A=”CCL34” В=”очень пористая”/>

<CCL A-”CCL35” В-”очень елажно”/>

<CCL A-”CCL36” В-”сухо”/>

</ССТ>

ПРИМЕРЗ. Комментарии CodedComment с областью охвата непрерывной и с CodedCommentListValue < CCL А-"ССТ7” В-”Чертополох” С =”3”>

<CCL A=”CCL1” В-”10 шт/м2”/>

<CCL A=”CCL2” В-”20 шт/м2”/>

<CCL A-”CCL3” В=”30 шт/м2”/>

</ССТ>

D.6 CodedCommentGroup — CCG

Тип:

Данные кодирования

Описание:

XML-элемент CodedCommentGroup (группа закодированных комментариев) может использоваться, чтобы объединить предопределенные CodedComment в группы с целью получить лучшую навигацию и выбор CodedComment в мобильной системе. Каждый CodedComment может принадлежать только одной CodedCommentGroup. Группой CodedCommentGroup может, например, быть «сорняки», которая содержит CodedComment «ромашка», «пырей» и «чертополох». Чтобы настроить список из CodedComment, которые принадлежат конкретному CodedCommentGroup на MICS, все XML-элементы CodedComment должны быть проверены на соответствие между XML-атрибутами CodedCommentGroupIdRef и идентификатором этой CodedCommentGroup.

Указан XML-элементами:

— CodedComment

Таблица D.6 — Атрибуты CodedCommentGroup

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

CodedCommentGroupId

А

г

xs:ID

От миним. 4

до макс. 14

Уникальный идентификатор CodedCommentGroup.

Формат: (CCG|CCG-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

CodedCommentGroupDesignator

В

г

xs:string

Макс. 32

Обозначение CodedCommentGroup

ПРИМЕР.

<CCG A="CCG1" В=”Сорняки”/>

<ССТ А=”ССТ6” В=”Чертополох” С =” 3” D=”CCG1”>

<CCL A=”CCL37" В=”10 шт/м2”/>

<CCL A=”CCL38” В=”20 шт/м2"1>

<CCL A=”CCL39” В=”30 шт/м2"!>

</ССТ>

D.7 CodedCommentListValue — CCL

Тип:

Данные кодирования

Описание:

XML-элемент CodedCommentListValue (значение списка закодированных комментариев) предоставляет значение для определенного закодированного комментария. Каждое значение CodedCommentListValue всегда принадлежит только одному CodedComment. Одно из значений CodedCommentListValue, принадлежащее CodedComment, может быть указано в CommentAllocation, когда данный CodedComment назначается на задачу. Примерами значений CodedCommentListValue являются наборы типа «низкий», «средний» и «высокий» или определения типа «коды стадий созревания сельскохозяйственных культур».

Указан XML-элементами:

— CommentAllocation

Включен XML-элементом:

— CodedComment

Таблица D.7 — Атрибуты CodedCommentListValue

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

CodedCommentListValueld

А

г

xs:ID

От миним. 4

до макс. 14

Уникальный идентификатор CodedCommentListValue.

Формат: (CCL|CCL-) ([0—9])+

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

CodedCommentListValueDesignator

В

г

xs:string

Макс. 32

Обозначение CodedCommentListValue

ПРИМЕР.

<CCL A=”CCL37” В=”10 шт/м2”/>

<CCL A=”CCL38” В=”20 шт/м2”/>

<CCL A=”CCL39” В=”30 шт/м2’Т>

D.8 ColourLegend — CLD

Тип:

Данные кодирования

Описание:

XML-элемент ColorLegend (цветовое обозначение) описывает цветовое обозначение, которое может использоваться для отображения значений в различных цветах на картах с координатной сеткой. XML-элемент ColorLegend включает в себя XML-элементы ColourRange, которые определяют цвет, используемый при представлении значения. Атрибут Defaultcolour используется для представления значения в случае, если не указан ColourRange, в который попадает значение.

Указан XML-элементами: — ValuePresentation Включает XML-элемент: — ColourRange

Таблица D.8 — Атрибуты ColourLegend

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

ColourLegendld

A

г

xs:ID

От миним.4 до макс. 14

Уникальный идентификатор ColourLegend.

Формат: (CLD|CLD-) ([0—9]) +

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

Defaultcolour

В

о

xs:unsignedByte

От 0 до 254

Цвет по умолчанию ColourLegend.

Формат: палитра в соответствии с ИСО 11783-6

ColourRange

г

xs:element

Включает список ColourRange XML-элемента

ПРИМЕР.

<CLD A=”CLD1” В=”0”>

<CRG А=”0” В=”9999” С=”1”/>

<CRG А=”10000” В=”14999” С="2"/>

<CRG А=”15000” В=”19999” С=”3’7>

<CRG А=”20000” В=”29999” С=”4”/>

<CRG А=”30000" В=”99999” С=”5"/>

</CLD>

D.9 ColourRange — CRG

Тип:

Данные кодирования

Описание:

XML-элемент ColorRange (цветовой диапазон) определяет цвет, используемый для отображения значений в определенном диапазоне значений на картах с координатной сеткой. XML-элемент ColourRange включен в XML-элемент ColourLegend для указания диапазона цветов, которые будут использоваться для представления различных диапазонов значений.

Включен XML-элементом:

— ColourLegend

Таблица D.9 — Атрибут ColourRange

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

MinimumValue

A

г

xs:long

От (-231+1) до (231-1)

Минимальное значение Colour-Range. Значение включено в диапазон

MaximumValue

В

г

xs:long

От (-231+1) до (231-1)

Максимальное значение Colour-Range. Значение включено в диапазон

Colour

С

г

xs:unsignedByte

От 0 до 254

Цвет ColourRange.

Формат: палитра согласно определению цветов ИСО 11783-6

ПРИМЕР.

<CLD A=”CLD1”>

<CRG А=”0" В=”9999” С=”1”/>

<CRG А=”10000” В=”14999” С=”2”/>

<CRG А=”15000” В=”19999” С=”3”/>

<CRG А=”20000” В=”29999” С=”47>

<CRG А=”30000” В=”99999” С="5’7>

</CLD>

D.10 CommentAllocation — CAN

Тип:

Данные задачи

Описание:

XML-элемент CommentAllocation (распределение комментариев) распределяет CodedComment или текст свободного комментария на задачу. Распределение комментариев задается в определенной позиции и в определенное время включением XML-элемента Allocationstamp. Свободный комментарий может быть добавлен в XML-атрибуте FreeCommentText. В случае назначения CodedComment и CodedCommentListValue на задачу CodedCommentListValue должно быть исключено из списка значений назначенного CodedComment. Отдельный CommentAllocation может назначить исключительно либо CodedComment, или FreeCommentText.

Только отдельный CommentAllocation должен быть записан для каждого события распределения CodedComment в задаче. Для CodedComment типа «непрерывный» это означает, что включенный XML-элемент Position должен содержать позицию в момент начала записи непрерывного комментария. При завершении непрерывного CodedComment происходит обновление CommentAllocation для включения атрибутов времени начала и остановки в AllocationTimeStamp.

При активации CodedComments типа «непрерывный» ТС должен проверить, активна ли регистрация данных времени и положения в двоичных файлах журнала. Если регистрация данных времени и положения в двоичных файлах журнала не активна, то ТС должен активировать ее с частотой обновления 1 Гц для сохранения времени и положения в двоичных файлах журнала. Если CodedComment типа «непрерывный» не активны и отсутствуют другие запросы на протоколирование данных, ТС прекращает регистрацию данных времени и положения в двоичных файлах журнала. Это гарантирует, что позиции регистрируются до тех пор, пока активен CodedComment типа «непрерывный».

Включает XML-элемент:

  • — Allocationstamp

Включен XML-элементом:

  • — Task

Ссылается на XML-элементы:

  • — CodedComment

  • — CodedCommentListValue

Таблица D.10 — Атрибуты CommentAllocation

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

CodedCommentldRef

A

0

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент Coded-Comment.

Формат: (ССТ|ССТ-) ([0—9]) +

CodedCommentListValueldRef

В

0

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент CodedCommentListValue.

Формат: (CCL|CCL-) ([0—9]) +

FreeCommentText

C

0

xs:string

Макс. 32

Текст свободного комментария, определяемого оператором

Allocationstamp

0

xs:element

Включает единственный XML-элемент Allocationstamp для указания времени и положения комментария

ПРИМЕР 1. CommentAllocation текста свободного комментария, определяемого оператором

<CAN С =’’плохие условия вождения”>

<ASP А=”2003-08-20Т08:00:20” D=”4”>

<PTN А=”51.23456” В-"13.23456” D-"2”/>

</ASP>

</CAN>

ПРИМЕР 2. Указанный CodedComment типа глобальный и CodedCommentListValue

<CAN А~”ССТЗ” B=”CCL13”>

<ASP А=”2003-08-20Т08:00:20” D=”4”>

<PTNA-”51.23456” B=”13.23456” D=”2”/>

</ASP>

</CAN>

ПРИМЕР 3. Указанный CodedComment непрерывного типа и CodedCommentListValue

Запущен непрерывный CodedComment:

<CAN А=”ССТ6” B=”CCL38”>

<ASP А-"2003-08-20Т08:00:20" D=”4”>

</--А = запуск непрерывного распределения комментариев, комментарий активен —>

<PTN А=”51.23456” В=”13.23456” D=”2”/>

<!--позиция в начале непрерывного распределения комментариев —>

</ASP>

</CAN>

и приблизительно 35 минут спустя тот же непрерывный CodedComment остановлен:

<CAN А=”ССТ6” B-”CCL38”>

<ASP А-"2003-08-20Т08:00:20” В=”2003-08-20Т08:35:45” D=”4”>

  • <! — А =начало непрерывного распределения комментариев, комментарий активен —>

  • <!--В = окончание непрерывного распределения комментариев, комментарий завершен —>

<PTN А=”51.23456” В=”13.23456” D -”2”/>

<!--позиция в начале непрерывного распределения комментариев —>

</ASP>

</CAN>

D.11 Connection — CNN

Тип:

Данные задачи

Описание:

Цель XML-элемента Connection (соединение) — указать, как два устройства соединяются друг с другом в рамках одной задачи. Спецификация соединения состоит из ссылок на два DeviceElement типа «соединитель» двух подключенных устройств. Спецификация соединения позволяет ТС определять положения элементов DeviceElement одного устройства относительно положения, например, NavigationReferencePoint другого устройства. Указанный в DeviceElementldRef_O элемент DeviceElement должен быть частью устройства, указанного в DeviceldRef_0, и должен иметь тип «соединитель». Указанный в DeviceElementldRef_1 элемент DeviceElement должен быть частью устройства, указанного в DeviceldRef_1, и также иметь тип «соединитель».

Включен XML-элементом:

— Task

Ссылается на XML-элементы:

— Device

— DeviceElement

Таблица D.11 — Атрибуты Connection

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

DeviceldRef_0

A

r

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент Device. Формат: (DVC|DVC-) ([0—9]) +

DeviceElementldRef_O

В

r

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент DeviceElement. Формат: (DET|DET-) ([0—9]) +

DeviceldRef_1

C

r

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент Device. Формат: (DVC|DVC-) ([0—9]) +

DeviceElementldRef_1

D

r

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент DeviceElement. Формат: (DET|DET-) ([0—9]) +

ПРИМЕР.

<CNN A=”DVC2” B-”DET2” C=”DVC1” D=”DET1’7>

D.12 ControlAssignment — CAT

Тип:

Данные задачи

Описание:

XML-элемент ControlAssignment (назначение управления) описывает назначение CF источника заданного значения на CF пользователя заданного значения. Примером может служить значение данных процесса элемента системы датчиков и значение данных процесса элемента устройства контроллера приложения. Этот элемент используется для записи назначения, выполненного во время выполнения задачи, и позволяет выполнить то же самое задание без дальнейшего взаимодействия с оператором при перезапуске задачи. Он может использовать FMIS в качестве планового назначения, которое ТС использует после запуска задачи. В задаче может существовать несколько XML-элементов ControlAssignment с одними и теми же CF назначения управления и DDI данных процесса, например, для записи периодов времени назначения управления. В этом случае назначение управления с последней отметкой времени должно использоваться для восстановления назначения при более позднем запуске задачи.

XML-элемент ControlAssignment добавлен в ИСО 11783-10 версии 4.

Включен XML-элементом:

— Task

Включает XML-элемент:

—Allocationstamp

Таблица D.12 — Атрибуты ControlAssignment

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

SourceClientNAME

A

r

xs:hexBinary

От 000000000 000000016 до FFFFFFFFF

FFFFFFF16

NAME управляющей функции источника заданного значения (см. ИСО 11783-5)

UserClientNAME

В

r

xs:hexBinary

От 000000000 000000016 до FFFFFFFFF

FFFFFFF16

NAME управляющей функции пользователя заданного значения (см. ИСО 11783-5)

SourceDeviceStructureLabel

C

r

xs:hexBinary

От 0016 до FE16 на байт для наиболее значимых 7 байтов;

0016 to FF16 на байт для байтов метки расширенной структуры. Максимальное количество байтов расширения метки структуры равно 32

Метка структуры дескриптора устройства источника заданного значения.

Байт 1 массива является наиболее

значимым, а байт п массива — наименее значимым

UserDeviceStructureLabel

D

r

xs:hexBinary

От 0016 до FE16 на байт для наиболее значимых 7 байтов;

0016 to FF16 на байт для байтов метки расширенной структуры. Максимальное количество байтов расширения метки структуры равно 32

Метка структуры дескриптора устройства пользователя заданного значения.

Байт 1 массива является наиболее значимым, а байт п массива — наименее значимым

SourceDeviceElementNumber

E

r

xs:unsignedShort

от 0 до 4095

Уникальный номер элемента устройства источника заданного значения.О нумерации элемента ProcessDataVariable см. приложение В

UserDeviceElementNumber

F

r

xs:unsignedShort

от 0 до 4095

Уникальный номер элемента устройства пользователя заданного значения.О нумерации элемента ProcessDataVariable см. приложение В

Окончание таблицы D.12

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

ProcessDataDDI

G

г

xs:hexBinary

от 000016 до FFFF16

Уникальный номер, который определяет DDI данных процесса (указанный в ИС011783-11) как для источника заданного значения, так и для пользователя заданного значения

Allocationstamp

о

xs:element

Включает единственный Allocationstamp XML-элемента

ПРИМЕР 1. Определение ControlAssignment

<САТ А=”А02282000СЕ03039” В=”А00А84000В8131АЗ” С=”01020304050607” D=”07060504030201 ” Е=”0” F=”0” G=”0006”>

<ASP А-"2003-08-20Т08:00:00” В=”2003-08-20Т17:00:00” D=”4”/>

</САТ>

ПРИМЕР 2. Дескриптор устройства для источника заданного значения

В следующем примере показаны только основные элементы для источника заданного значения. Другие элементы опущены для примера. Показан первичный элемент — это DPD для заданной нормы внесения, атрибут С имеет значение 5, которое представляет собой комбинацию 4 для «источника управления» и 1 для «принадлежит набору по умолчанию».

<DVC A=”DVC1” B-”RT200ISO” С-”0.5.10” D=”A02282000CE03039” Е=”2” F=”01020304050607” G=”FF565A01506E65”>

<DETA=”DET1” B-”65523” C=”1” D=”NDVISensors” E=”0” F=”0”>

<DOR A-”65524” />

</DET>

<DPD A=”65524” B=”0006” C-”5” D=”1” E=”SetPointRate”/>

</DVC>

D.13 CropType — CTP

Тип:

Данные кодирования

Описание:

XML-элемент CropType (тип сельскохозяйственной культуры) описывает сельскохозяйственную культуру, которая может быть выращена на участке поля. XML-элемент CropType может включать несколько XML-элементов CropVariety.

Дополнительный атрибут ProductGroupldRef был введен в версии 4 для включения ссылки на ProductGroup типа «СгорТуре». Эта ссылка включает перекрестные ссылки на использование продукта с атрибутом CropType для Partfield.

Указан XML-элементами:

— Partfield

Включает XML-элемент:

— CropVariety

Таблица D.13 — Атрибуты СгорТуре

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

CropTypeld

А

г

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор СгорТуре.

Формат: (СТР|СТР-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

CropTypeDesignator

В

г

xs:string

макс. 32

Название сельскохозяйственной культуры

ProductGroupldRefа

С

о

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент ProductGroup. Формат: (PGP|PGP-) ([0—9]) +

CropVariety

о

xs:element

Включает список XML-элемента CropVariety

а Этот атрибут представлен в версии 4 стандарта ИСО 11783-10.

ПРИМЕР 1. СгорТуре и определение CropVariety

<СТР А=”СТР1” В=”Пшении,а”>

<CVTA=”CVT1” B=”Ritmo В"/>

<CVTA=”CVT2” B=”Dekan В’7>

<CVTA=”CVT3” B=”Ares C'7>

</CTP>

<CTPA=”CTP2” В=”Ячмень’7>

<CTP A=”CTP3” B=”Oeec”/>

ПРИМЕР 2. Определение СгорТуре связано с определением ProductGroup

<PGPA=”PGP1” В=”картофель” С =”2’7>

<СТР А=”СТР4” В=”картофель” C=”PGP1”/>

D.14 CropVariety — CVT

Тип:

Данные кодирования

Описание:

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

Дополнительное свойство ProductldRef было введено в 4 версии для включения ссылки на продукт Product, сгруппированный в ProductGroup типа «СгорТуре». Эта ссылка включает перекрестные ссылки на использование продукта с атрибутом CropVariety для Partfield.

Включен XML-элементом:

— СгорТуре

Указан XML-элементами:

— Partfield

Таблица D.14 — Атрибуты CropVariety

Атрибут

XML

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

Тип

Длина

Комментарий

CropVarietyld

А

г

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор CropVariety.

Формат: (CVT|CVT-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

CropVarietyDesignator

В

г

xs:string

макс. 32

Название сорта культуры CropVariety

ProductldRef3

С

о

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент Product. Формат: (PDT|PDT-) ([0—9]) +

а Этот атрибут представлен в версии 4 стандарта ИСО 11783-10.

ПРИМЕР 1. Определение CropVariety

<CVTA=”CVT1” B=”Ritmo B’7>

<CVTA=”CVT2” B=”Dekan B’7>

<CVTA=”CVT3” B=”Ares C"/>

ПРИМЕР 2. CropVariety, связанный с определением Product

<PGPA=”PGP1” В=”Пшеница” C=”2"/>

<PDT A=”PDT1" B=”Ritmo B” C=”PGP1’7>

<CTPA=”CTP1” В=”Пшеница” C=”PGP1”/>

<CVTA=”CVT1” B=”Ritmo B” C=”PDT1’7>

</CTP>

D.15 CulturalPractice — CPC

Тип:

Данные кодирования

Описание:

Агротехнический процесс описывают один или несколько видов деятельности, направленных на достижение определенной цели в растениеводстве. XML-элемент CulturalPractice (агротехнический процесс) описывает агротехнические процессы, которые с помощью XML-элемента OperTechPractice могут быть распределены на задачу. Примерами определений CulturalPractice являются «первичная обработка почвы» или «посев». CulturalPractice может относиться к списку ссылок на несколько OperationTechnique (например, агротехнический процесс «внесение удобрений» — > технологии процесса: «внесение жидких удобрений», «внесение органических удобрений», «внесение газообразных удобрений»).

Указан XML-элементами:

— OperTechPractice

Включает XML-элемент:

— OperationTechniqueReference

Таблица D.15 — Атрибуты CulturalPractice

Атрибут

XML

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

Тип

Длина

Комментарий

CulturalPracticeld

A

г

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор

CulturalPractice. Формат: (СРС|СРС-) ([0—9]) +. Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

CulturalPracticeDesignator

В

г

xs:string

Макс. 32

Обозначение CulturalPractice

OperationTechniqueReference

о

xs:element

Включает список XML-элемента OperationTechniqueReference

ПРИМЕР.

<СРС А=”СРС1” В=”внесение удобрений”>

<OTR A=”OTQ1”/>

</СРС>

<СРС А=”СРС2” В=”посев”/>

<СРС А=”СРСЗ” В=”уборка урожая ”/>

D.16 Customer — CTR

Тип:

Данные кодирования

Описание:

XML-элемент Customer (потребитель) описывает потребителя. Потребитель может быть указан в элементах задача, ферма и участок поля. Взаимосвязи между потребителем и фермами и участками поля могут быть множественными. Чтобы определить, какие фермы или участки поля принадлежат конкретному потребителю, значения CustomerldRef всех ферм или участков полей, соответственно, должны быть проверены на соответствие конкретному значению Customerld.

Указан XML-элементами:

  • — Task

  • — Farm

  • — Partfield

Таблица D.16 — Атрибуты Customer

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Customerld

A

r

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор потребителя.

Формат: (CTR|CTR-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

CustomerLastName

В

r

xs:string

Макс. 32

Фамилия потребителя

CustomerFirstName

C

0

xs:string

Макс. 32

Имя потребителя

Customerstreet

D

0

xs:string

Макс. 32

Улица

CustomerPOBox

E

0

xs:string

Макс. 32

Почтовый ящик

CustomerPostalCode

F

0

xs:string

Макс. 10

Индекс

CustomerCity

G

0

xs:string

Макс. 32

Город

Customerstate

H

0

xs:string

Макс. 32

Область или округ

CustomerCountry

I

0

xs:string

Макс. 32

Страна

CustomerPhone

J

0

xs:string

Макс. 20

Номер телефона

Окончание таблицы D.16

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

CustomerMobile

К

о

xs: string

Макс. 20

Номер мобильного телефона

CustomerFax

L

о

xs: string

Макс. 20

Номер факса

CustomerEMail

M

о

xs:string

Макс. 64

Электронная почта

ПРИМЕР.

<CTR A=”CTR1” В=”Смит” С=”Джон” С=”Мюнхен’7>

D.17 DataLogTrigger— DLT

Тип:

Данные задачи

Описание:

XML-элемент DataLogTrigger (триггер регистрации данных) входит в задачу и содержит информацию о том, какие значения ProcessDataVariable должны быть зарегистрированы как DataLogValue во время обработки задачи. Ссылка на DeviceElement может быть добавлена в мобильную систему, как только устройство распределено на выполнение задачи. Когда ссылка на DeviceElement уже дана в FMIS, то для задачи запланировано конкретное устройство. Если ссылка на DeviceElement не указана в DataLogTrigger, то ТС регистрирует запрошенный DDI из всех DeviceElement, которые могут предоставить этот DDL Атрибуты DataLogTrigger определяют поведение ТС относительно того, как собирать и хранить значения ProcessDataVariable.

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

Если DataLogThresholdMinimum меньше, чем DataLogThresholdMaximum, то регистрация данных активна, когда значение находится между DataLogThresholdMinimum и DataLogThresholdMaximum. Если DataLogThresholdMinimum больше DataLogThresholdMaximum, то регистрация данных активна, если значение больше, чем DataLogThresholdMinimum, или меньше, чем DataLogThresholdMaximum.

Метод регистрации данных «общее значение» не зависит от других методов регистрации данных и может использоваться с любой комбинацией, описанной выше. Значения DataLogValue типа «общее значение» должны храниться один раз на XML-элемент Time задачи в наборе файлов передачи данных.

Значения из групп параметра могут регистрироваться путем указания атрибутов DataLogPGN, DataLogPGNStartBit и DataLogPGNStopBit. Когда эти атрибуты будут указаны, значение атрибута DataLogDDI должно быть установлено в DFFE16 (значение журнала PGN).

Включен XML-элементом:

  • — Task

Ссылается на XML-элементы:

  • — DeviceElement

Таблица D.17 — Атрибуты DataLogTrigger

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

DataLogDDI

A

г

xs:hexBinary

От 000016 до FFFF16

Уникальное число,

которое идентифицирует

ProcessDataVariable (как

указано в ИСО 11783-11)

DataLogMethod

В

г

xs:unsignedByte

От 1 до 31

Выбор метода регистрации данных:

  • 1 = интервал времени

  • 2 = интервал расстояния.

  • 4 = пороговые значения.

8 = при изменении.

16 = общее значение

DataLogDistancelnterval

С

о

xs:long

От 0 до 1000000

Интервал расстояния для регистрации данных в мм, 0 останавливает измерения

Окончание таблицы D.17

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

DataLogTimelnterval

D

0

xs:long

От 0 до 60000

Интервал времени для регистрации в мс, 0 останавливает измерение, 100 мс — минимальный интервал времени

DataLogThresholdMinimum

E

0

xs:long

От (-231 + 1) ДО (231-1)

Минимальный порог для активации регистрации данных. Пороговое значение включено в диапазон рачений для регистрации. (2 -1) останавливает измерение

DataLogThresholdMaximum

F

0

xs:long

От (-231 + 1) ДО (231-1)

Максимальный порог для активации регистрации данных. Пороговое значение включено в диапазон значений для регистрации. (-231+1) останавливает измерение

DataLogThresholdChange

G

0

xs:long

От (-231 + 1) ДО (231-1)

Порог изменения для активации регистрации данных, 0 останавливает измерение, 1 регистрирует каждое изменение

DeviceElementldRef

H

0

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент DeviceElement.

Формат (DET|DET-) ([0—9]) +

ValuePresentationldRef

I

0

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент

ValuePresentation.

Формат (VPN|VPN-) ([0—9]) +

DataLogPGN

J

0

xs:unsignedLong

От 0 до (218-1)

Группа параметров, из которой требуется регистрировать значение

DataLogPGNStartBit

К

0

xs:unsignedByte

От 0 до 63

Первый бит значения для регистрации из группы параметров. 0 указывает наименее значимый бит Байта 1 в поле данных кадра данных (битовый индекс, отсчитываемый от нуля). Начальный бит включен в значение и становится наименее значимым битом

DataLogPGNStopBit

L

0

xs:unsignedByte

От 0 до 63

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

ПРИМЕР.

<DLTA=”1122” В="1” D=”1000” H=”DET2’7>

D.18 DataLogValue — DLV

Тип:

Данные задачи

Описание:

DataLogValue (значение регистрации данных) задает единичное значение единичной переменной Рго-cessDataVariable, заданной его DDI и предоставляемой единичным элементом DeviceElement. XML-атрибут DeviceElementldRef ссылается на соответствующий DeviceElement. Положение и время для DataLogValue задаются через XML-элемент Time. Время включено в задачу, и за счет этой связи все значения DataLogValue принадлежат задаче. DataLogValue является частью функциональности регистрации данных ТС.

Когда значения регистрируются из группы параметров, используются атрибуты DataLogPGN, DataLogPGN-StartBit и DataLogPGNStopBit используются, и атрибуту DataLogDDI должно быть установлено значение в DFFE16 (значения журнала PGN).

Включен XML-элементом:

  • — Time

Ссылается на XML-элементы:

  • — DeviceElement

Таблица D.18 — Атрибуты DataLogValue

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

ProcessDataDDI

A

r

xs:hexBinary

От 000016 до FFFF16

Уникальное число, которое определяет ProcessDataVariable (как указано в приложении В и ИСО 11783-11)

ProcessDataValue

В

r

xs:long

От -231 до (231-1)

Значение

DeviceElementldRef

C

r

xs:IDREF

От миним. 4 до макс. 14

Ссылка на DeviceElement.

Формат: (DET|DET-) ([0—9]) +

DataLogPGN

D

0

xs:unsignedLong

От Одо (218-1)

Группа параметров, из которой регистрируются значения

DataLogPGNStartBit

E

0

xs:unsignedByte

От 0 до 63

Первый бит значения для регистрации из группы параметров. 0 указывает наименее значимый бит Байта 1 в поле данных кадра данных (битовый индекс, отсчитываемый от нуля). Начальный бит включен в значение и становится наименее значимым битом

DataLogPGNStopBit

F

0

xs:unsignedByte

От 0 до 63

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

ПРИМЕР.

<DLVA=”0815” В-"10" C=”DET1”/>

<DLVA=”4711” В=”15” C=”DET2’7>

<DLV А=”4522” В=”20” C=”DET3’7>

D.19 Device — DVC

Тип:

Данные кодирования

Описание:

XML-элемент Device (устройство) описывает комплектное устройство, например машину или систему датчиков. Каждое устройство должно иметь по крайней мере один DeviceElement.

Включает XML-элемент:

  • — DeviceElement

  • — DeviceProcessData

  • — DeviceProperty

  • — DeviceValuePresentation

Указан XML-элементами:

  • — Connection

  • — DeviceAllocation

Таблица D.19 — Атрибуты Device

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Deviceld

А

г

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор устройства.

Формат: (DVC|DVC-) ([0—9]) +

DeviceDesignator

В

0

xs: string

Макс. 32

Обозначение устройства

DeviceSoftwareVersion

С

0

xs:string

Макс. 32

Версия программного обеспечения устройства

ClientNAME

D

г

xs:hexBinary

От 0000000000

00000016 до

FFFFFFFFFFFFFFFF16

NAME устройства клиента (см. ИСО 11783-5)

DeviceSerialNumber

Е

0

xs: string

Макс. 32

Серийный номер устройства или машины, представленной клиентом, для конкретного устройства или производителя. Например, уникальный идентификационный номер транспортного средства или продукта3

DeviceStructureLabel

F

г

xs:hexBinary

От 0016 до FE16 на байт для наименее значимых 7 байтов.

От 0016 до FF16 на байт для байтов метки расширенной структуры. Максимальное количество байтов расширения метки структуры равно 32

Метка структуры дескриптора устройства.

Байт 1 массива метки структуры является наименее значимым байтом в значении xs: hexBinary, а байт п массива метки структуры является наиболее значимым байтом в значении xs: hexBinary.

См. пример 1 в этом разделе

DeviceLocalizationLabel

G

г

xs:hexBinary

Байты с 1 по 6:0016 до FE16 на байт. Байт 7 = FF16

Метка локализации дескриптора устройства.

Байты с 1 по 6 определены PGN языковой команды (см. ИСО 11783-7).

Байт 7 зарезервирован, и его значение установлено в FF16. Байт 1 PGN языковой команды является наименее значимым, а байт 7 языковой команды является наиболее значимым

DeviceElement

г

xs:element

Включает список XML-элемента DeviceElement

DeviceProcessData

0

xs:element

Включает список XML-элемента DeviceProcessData

DeviceProperty

0

xs:element

Включает список XML-элемента DeviceProperty

DeviceValuePresentation

0

xs:element

Включает список XML-элемента DeviceValuePresentation

a Определено в ИСО 11783-12; 2-е издание Услуг диагностики.

ПРИМЕР 1. Метка структуры и метка локализации

Байты 1 и 2 языковой команды содержат код языка. Например, код языка ‘еп’ представлен байтами 6516 и 6Е16, наименее значимый байт в обозначении локализации в этом случае имеет значение 6516.

Порядок байтов в DeviceObject в XML-файле:

<DVC A=”DVC1" В=”опрыскиватель 4711” С=”1.0” D=”A00C8400073FFFC7” F=”F9FAFBFCFDFE39” G=”FF000000006E65”>

Байт массива метки структуры [7][6][5][4][3][2][1]: F9 FA FB FC FD FE 39

Байт метки локализации [7][6][5][4][3][2][1]: FF 00 00 00 00 6Е 65

Порядок байтов в DeviceObject, передаваемый по шине CAN:

Порядок байтов массива метки структуры по шине CAN [1][2][3][4][5][6][7]: 39 FE FD FC FB FA F9

Порядок байтов метки локализации по шине CAN [1][2][3][4][5][6][7]: 65 6Е 00 00 00 00 FF

Пример 2. Метка расширенной структуры из 8 байтов добавлена к 7-байтовой метке структуры Порядок байтов в DeviceObject в XML-файле:

<DVC A=”DVC1” В=”опрыскиватель 4711” С=”1.0” D=”A00C8400073FFFC7” F=”E8E7E6E5E4E3E2E1F 9FAFBFCFDFE39 ” G="FF000000006E65 ”>

Байт массива метки структуры [15][14][13][12][11][10][9][8][7][6][5][4][3][2][1]: Е8 Е7 Е6 Е5 Е4 ЕЗ Е2 E1 F9 FA FB FC FD FE 39

Порядок байтов в DeviceObject, передаваемый по шине CAN:

Порядок байтов массива метки структуры по шине CAN [1][2][3][4][5][6][7][8][9][10][11][12][13][14] [15]: 39 FE FD FC FB FA F9..............08 E1 E2 E3 E4 E5 E6 E7 E8

ПРИМЕР 3. Дескриптор устройства

<DVC A=”DVC1” В-”опрыскиватель 4711” C=”1.0” D=”A00C84000B20408B” F=”30353035344042” G=”FF000000006C6E">

<DETA="DET1” B=”1” C=”1” D=”ece элементы” E=”0” F=”0”>

<DORA=”3’7>

<DORA=”4’7>

<DOR A=”8’7>

<DORA=”9’7>

<DORA=”10’7>

<DORA=”11’7>

</DET>

<DET A=”DET2” B=”2” C=”3” О=”главный резервуар” E=”1” F-”1”>

<DORA~”5”/>

<DORA=”6”/>

<DORA=”7’7>

<DORA=”8”/>

<DORA=”9’7>

<DORA=”10’7>

<DORA=”12’7>

</DET>

<DPD A=”3” B=”1234” C=”3” D-”1”/>

<DPD A-”4” B~"8765” C-”1” D-”1’7>

<DPD A-”5” B=”1111” C=”3” D=”1’7>

<DPD A-”6” B=”1112” C=”3” D-”1"/>

<DPD A-”7" B-”1133" C-"1” D=”2”/>

<DPTA-”8” B=”4301” C=”0”/>

<DPTA-”9” B-”4302” C=”0’7>

<DPT A=”10” B-”4303” C=”0”/>

<DPTA=”11” B=”4305” C=”2700”/>

<DPTA-”12” B-”4304” C-”4500”/>

</DVC>

D.20 DeviceAllocation — DAN

Тип:

Данные задачи

Описание:

XML-элемент DeviceAllocation (распределение устройств) содержит информацию о том, для какого устройства (тв) была создана запланированная задача и какие устройства фактически использовались во время обработки задачи. Для запланированной задачи DeviceAllocation описывает ClientNAMEValue и дополнительно маску NAME, чтобы разрешить диапазон значений NAME, которые могут указывать устройства, которые также разрешены для обработки задачи. Во время обработки задачи ТС добавляет новое DeviceAllocation к задаче с информацией о пользователе, которая фактически использовалась для выполнения задачи.

Включает XML-элемент:

—Allocationstamp

Включен XML-элементом:

— Task

Ссылается на XML-элементы:

— Device

Таблица D.20 — Атрибуты DeviceAllocation

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

ClientNAMEValue

A

r

xs:hexBinary

От oooooo16 до FFFFFFFFF FFFFFFF1fi

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

ClientNAMEMask

В

0

xs:hexBinary

От 00000016 до FFFFFFFFF FFFFFFF16

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

Битовое значение = 1 => релевантный бит ClientNAMEValue.

Значение бита = 0 => бит

ClientNAMEValue не релевантный

DeviceldRef

C

0

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент Device. Формат: (DVC|DVC-) ([0—9]) +

Allocationstamp

0

xs:element

Включает единственный XML-элемент Allocationstamp

ПРИМЕР 1. Запланированная DeviceAllocation, маска определяет назначение контроллера опрыскивателя, первого экземпляра функции, найденного в сети. Это запланированное DeviceAllocation не имеет ссылки на конкретное устройство.

<DAN B=”7FFFFFFF00000000” А=”200С840000000000”>

<ASP А=”2003-08-20Т08:00:00” В=”2003-08-20Т17:00:00” D-”1 "/>

</DAN>

ПРИМЕР 2. Запланированное DeviceAllocation для назначения одного определенного экземпляра контроллера опрыскивателя. Это запланированное DeviceAllocation имеет ссылку на конкретное Device.

<DAN B=”FFFFFFFFFFFFFFFF” А=”А00С84000В20408В” C=”DVC1”>

<ASPA=”2003-08-20T08:00:00” B=”2003-08-20T17:00:00” D=”1 "/>

</DAN>

ПРИМЕР 3. Записанное DeviceAllocation контроллера опрыскивателя. Это DeviceAllocation добавляется к задаче для фактического Device, используемого в задаче.

<DAN А=”А00С84000В20408В” C=”DVC1”>

<ASPA=”2003-08-21Т07:34:09” В=”2003-08-21 Т12:40:23” D-”4”/>

</DAN>

D.21 DeviceElement — DET

Тип:

Данные кодирования

Описание:

XML-элемент DeviceElement (элемент устройства) описывает функциональные или физические элементы устройства. Чтобы установить иерархическую структуру групп элементов, DeviceElement должен ссылаться на другой DeviceElement или на само устройство. Атрибут DeviceElementType определен в разделе А.З. Атрибут ParentObjectld используется для ссылки либо на DeviceObject (идентификатор объекта ID = 0), либо на исходный DeviceElementObject для установления иерархического порядка элементов DeviceElement.

Включен XML-элементом:

— Device

Включает XML-элемент:

  • — DeviceObjectReference

Ссылается на XML-элементы:

  • — DeviceElement

  • — Device

Указан XML-элементами:

  • — Connection

  • — DataLogTrigger

  • — Data Log Value

  • — ProcessData Variable

  • — ProductAllocation

Таблица D.21 — Атрибуты DeviceElement

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

DeviceElementld

A

r

xs:ID

От миним. 4

до макс. 14

Уникальный идентификатор

DeviceElement.

Формат: (DET|DET-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

DeviceElementObjectld

В

r

xs:unsignedShort

От 1 до 65534

Уникальный идентификатор объекта в дескрипторе устройства

DeviceElementType

C

r

xs:NMTOKEN

От 1 до 7

Выбор типа:

  • 1 = Устройство.

  • 2 = Функция.

  • 3 = Бункер.

  • 4 = Секция.

  • 5 = Блок.

  • 6 = Соединитель.

  • 7 = Навигация.

DeviceElementDesignator

D

0

xs:string

Макс. 32

Обозначение элемента

DeviceElementNumber

E

r

xs:unsignedShort

От 0 до 4095

Уникальный номер элемента. О нумерации элемента ProcessData-Variable см. приложение В

ParentObjectld

F

r

xs:unsignedShort

От 0 до 65534

Идентификатор объекта родительского DeviceElement или Device

DeviceObjectReference

0

xs:element

Включает список XML-элемента

DeviceObjectReference

ПРИМЕР.

<DETA=”DET1” В="1” С=”1” D=”ece элементы" Е=”0” F-"0">

<DORA=”3’7>

<DORA=”4”/>

<DORA-"8"/>

<DORA=”9’”7>

<DORA=”10’7>

<DORA=”11’7>

</DET>

D.22 DeviceObjectReference — DOR

Тип:

Данные кодирования

Описание:

XML-элемент DeviceObjectReference (ссылка на объект устройства) описывает ссылку на объект DeviceProcessData или объект DeviceProperty.

Этот XML-элемент — часть дескриптора устройства.

Ссылается на XML-элементы:

  • — DeviceProcessData

  • — DeviceProperty

Включен XML-элементом:

  • — DeviceElement

Таблица D.22 — Атрибуты DeviceObjectReference

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

DeviceObjectld

А

г

xs:unsignedShort

От 1 до 65534

Идентификатор объекта DeviceProcessData или DeviceProperty

ПРИМЕР.

<DOR А=”3” />

D.23 DeviceProcessData — DPD

Тип:

Данные кодирования

Описание:

XML-элемент DeviceProcessData (данные процесса устройства) описывает DDI переменных ProcessDataVariable, поддерживаемых DeviceElement, который ссылается на этот XML-элемент. Параметры атрибута DeviceProcessDataProperty «настраиваемый» и «источник управления» являются взаимоисключающими, только один из этих параметров может быть установлен в значении атрибута DeviceProcessDataProperty. Атрибут DeviceProcessDataTriggerMethod указывает доступные методы запуска для ProcessDataVariable DDL

Этот элемент является частью дескриптора устройства.

Ссылается на XML-элементы:

  • — Device ValuePresentation

Указан XML-элементами:

— DeviceObjectReference

Включен XML-элементом:

— Device

Таблица D.23 — Атрибуты DeviceProcessData

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

DeviceProcessData

Objectld

А

г

xs:unsignedShort

От 1 до 65534

Уникальное число внутри одного устройства

DeviceProcessDataDDI

В

г

xs:hexBinary

От 000016 до FFFF16

Уникальное число, которое определено в переменной процесса данных (определено в ИСО 11783-11)

DeviceProcessDataProperty

С

г

xs:NMTOKEN

От 0 до 7

Комбинация битов для указания свойства ProcessDataVariable:

  • 1 = Принадлежит набору по умолчанию.

  • 2 = Настраиваемый.

  • 4 = Источник управления3

DeviceProcessDataTrigger

Methods

D

г

xs:integer

От 0 до 31

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

  • 1 = интервал времени.

  • 2 = интервал расстояния.

  • 4 = пороговые значения.

8 = при изменении.

16 = общее значение

DeviceProcessData

Designator

Е

О

xs:string

Макс. 32

Обозначение DeviceProcess

Data

DeviceValuePresentation

Objectld

F

О

xs:unsignedShort

От 1 до 65534

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

DeviceValuePresentation

a Это битовое значение представлено в версии 4 ИСО 11783-10.

ПРИМЕР.

<DPD А=”1” В=”1234” С=”3” D=”1”/>

D.24 DeviceProperty — DPT

Тип:

Данные кодирования

Описание:

XML-элемент DeviceProperty (свойство устройства) описывает свойство DeviceElement посредством ссылки и значения для DDL Этот элемент является частью дескриптора устройства.

Ссылается на XML-элементы: — DeviceValuePresentation Указан XML-элементами: — DeviceObjectReference Включен XML-элементом: — Device

Таблица D.24 — Атрибуты DeviceProperty

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

DevicePropertyObjectld

A

r

xs:unsignedShort

От 1 до 65534

Уникальное число внутри одного устройства

DevicePropertyDDI

В

r

xs:hexBinary

От 000016 до FFFF16

Уникальное число, которое определяет свойство (указано в ИСО 11783-11)

DevicePropertyValue

C

r

xs:long

От -231 до (231-1)

Значение свойства

DevicePropertyDesignator

D

0

xs:string

Макс. 32

Дополнительное обозначение для свойства

DeviceValuePresentation

Objectld

E

0

xs:unsignedShort

От 1 до 65534

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

DeviceValuePresentation

ПРИМЕР.

<DPT А=”8” В=”1235” С=”-65233”/>

D.25 DeviceValuePresentation — DVP

Тип:

Данные кодирования

Описание:

XML-элемент DeviceValuePresentation (представления значения устройства) используется для указания представления целочисленных значений, определенных объектом словаря данных, которые используются в пределах одного устройства. Представление должно осуществляться по следующей формуле:

Представленные значения = (целое числовое значение + смещение) * масштаб.

Представленное значение всегда округляют к количеству десятичных чисел, указанных в атрибуте NumberOfDecimals.

Указан XML-элементами:

— DeviceProcessData

— DeviceProperty

Включен XML-элементом:

— Device

Таблица D.25 — Атрибуты DeviceValuePresentation

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

DeviceValuePresentation

Objectld

A

r

xs:unsignedShort

От 1 ДО 65534

Уникальное число в одном устройстве

Offset

В

r

xs:long

От -231 до (231-1)

Смещение, которое будет применено к величине для представления

Scale

C

r

xs:decimal

ОтО,000000001 до 100000000,0

Масштаб, который будет применен к величине для представления

NumberOfDecimals

D

r

xs:unsignedByte

От 0 до 7

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

Окончание таблицы D.25

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

UnitDesignator

Е

о

xs:string

Макс. 32

Строка необязательного обозначения единицы измерения

ПРИМЕР.

<DVPA=”1” В=”0” С=”1.0” D=”0” Е=”кг’7>

<DVPA=”2” В=”18” С=”1.8” D=”1” E=”F’7>

D.26 Farm — FRM

Тип:

Данные кодирования

Описание:

XML-элемент Farm (ферма) содержит всю необходимую информацию для описания фермы. В наборе файлов передачи данных ферма может содержать набор полей, управляемых независимо от других ферм. Взаимосвязи между потребителем и фермами и частями поля могут быть множественными. Чтобы определить, какие фермы или части поля принадлежат конкретному потребителю, значения CustomerldRef всех ферм или частей поля, соответственно, должны быть проверены на соответствие определенному значению Customerld.

Ссылается на XML-элементы:

— Customer

Указан XML-элементами:

— Partfield

— Task

Таблица D.26 — Атрибуты Farm

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Farmld

A

r

xs: ID

От миним. 4 до макс. 14

Уникальный идентификатор Farm Формат: (FRM|FRM-) ([0—9]) +. Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

FarmDesignator

В

r

xs:string

Макс. 32

Обозначение/название фермы или хозяйства

FarmStreet

C

0

xs:string

Макс. 32

Улица

FarmPOBox

D

0

xs:string

Макс. 32

Почтовый ящик

FarmPostalCode

E

0

xs:string

Макс. 10

Индекс

FarmCity

F

0

xs:string

Макс. 32

Город

FarmState

G

0

xs:string

Макс. 32

Область или округ

FarmCountry

H

0

xs:string

Макс. 32

Страна

CustomerldRef

I

0

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент Customer. Формат: (CTR|CTR-) ([0—9]) +

ПРИМЕР.

<FRM A=”FRM1” В=”ранчо бонанза’7>

0.27 Grid — GRD

Тип:

Данные задачи

Описание:

XML-элемент Grid (сетка) описывает размер и положение набора ячеек сетки. Должны быть определены минимальное положение на север/восток, размер каждой ячейки сетки и количество ячеек сетки в направлении север/восток. Для каждой задачи может быть указана только одна сетка. Сетка всегда связана с частью поля, но определение сетки всегда зависит от конкретной задачи. Ячейки сетки содержат ссылку на Treatmentzone или значение переменной данных процесса. Сетка должна быть задана как завершенный массив ячейки сетки в порядке возрастания, так как ячйка сетки не содержит никакой информации о порядке упорядочения.

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

Task может иметь максимум один элемент Grid. TaskControllers (с ограниченной производительностью обработки) могут обработать только один Grid на Task. Это означает, что в случае большего количества OperTechPractises FMIS должен сформулировать общий Grid, который указывает Treatmentzones, которые допустимы для всего OperTechPractises. Обратите внимание, что одна Treatmentzone может содержать более одной переменной ProcessDataVariable, управляемой позиционным контроллером. Многопараметрическое управление по положению возможно как с сеткой типа 1, так и с сеткой типа 2.

Ссылается на XML-элементы:

— Treatmentzone

Включен XML-элементом:

— Task

Таблица D.27 — Атрибуты Grid

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

GridMinimumNorthPosition

A

r

xs:decimal

От -90,0 до 90,0

Минимальное северное положение сетки.

Формат: WGS84

GridMinimumEastPosition

В

r

xs:decimal

От -180,0 до 180,0

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

положение сетки. Формат: WGS84

GridCellNorthSize

C

r

xs:double

От 0,0 до 1,0

Размер ячейки сетки в северном направлении. Формат: WGS84

GridCellEastSize

D

r

xs:double

От 0,0 до 1,0

Размер ячейки сетки восточного направления. Формат: WGS84

GridMaximumColumn

E

r

xs:unsignedLong

От Одо (232-1)

Количество ячеек сетки в восточном направлении

GridMaximumRow

F

r

xs:unsignedLong

От Одо (232-1)

Количество ячеек сетки в северном направлении

Filelength

H

0

xs:unsignedLong

От 0 до (232-2)

Длина ячеек сетки файла в байтах

GridType

I

r

xs:NMTOKEN

От 1 до 2

Спецификация типа сетки: 1 = Тип сетки 1.

2 = Тип сетки 2

T reatmentZoneCode

J

0

xs:unsignedByte

От 0 до 254

Тип сетки 2 TreatmentZoneCode

ПРИМЕР.

Спецификация XML-элемента сетки типа 1:

<GRD А=”58.096653” В=”8.54321” С=”0.012” D="0.012” Е=”200” F=”300” G=”GRD00001” l=”1’7>

См. 8.6.2, аде приведены примеры спецификаций типа сетки 1 и типа 2.

D.28 GuidanceAllocation — GAN

Тип:

Данные задачи

Описание:

XML-элемент GuidanceAllocation (распределение указаний направления) описывает распределение GuidanceGroup для решения задачи. Запись Allocationstamp описывает время начала/остановки распределений и обеспечивает возможность отслеживать изменения распределения заданного направления для задачи.

Включенный XML-элемент GuidanceAllocation определяет геопространственные сдвиги, применяемые к GuidancePattern в распределенной группе GuidanceGroup. Каждый XML-элемент GuidanceShift содержит свой необходимый XML-элемент Allocationstamp. Если происходят многократные операции сдвига, то каждая операция сдвига записывается в новый XML-элемент GuidanceShift в XML-элементе GuidanceAllocation.

XML-элемент GuidanceAllocation добавлен в ИСО 11783-10 версии 4.

Ссылается на XML-элементы:

— GuidanceGroup

Включен XML-элементом:

— Task

Включает XML-элемент:

—Allocationstamp

— GuidanceShift

Таблица D.28 — Атрибуты GuidanceAllocation

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

GuidanceGroupIdRef

A

г

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент GuidanceGroup.

Формат: (GGP|GGP-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

Allocationstamp

г

xs:element

Включает один XML-элемент Allocation-Stamp

GuidanceShift

о

xs:element

Включает список XML-элемента GuidanceShift

ПРИМЕР.

<PFD A=”PFD3” С=”холм” D=”32000” G=”CTP3”>

<PLNA=”1” В=”Граница поля" С="32000" D=”1”>

<LSG А=”1” В=”Линия1” С=”20” D=’’280000” Е=”1”>

<PNT А=”2” В=”начало” С=”40.84982” D="-96.596045" Е=”150234” F=”1”/>

<PNT А=”2” В=”середина” С=”40.84982” D-"-96.592655" Е=”148987” F=”1’7>

<PNT А=”2” В=”конец” С="40.846573” D-"-96.592526" Е-"148284" F-"1"/>

</LSG>

</PLN>

<GGP A-"GGP1”>

<GPNA=”GPN1 ” C-”1 " D-"1 ">

<LSG A="5" В="3адание направления 1” C="6000" D-”1500000" E-"1">

<PNTA="6" В=”начало” C=”40.84934” D-"-96.593445" E="148987" F="1" H="0.05"/>

<PNTA-”7" В-"конец" C="40.84683" D-"-96.592225" E="150234” F-"1" H-"0.04"/>

</LSG>

</GPN>

<GPN A=”GPN2” C-"1" D="1">

<LSG A="5" E-"1" В=”3аданное направление 2" D="900000" C="18000" F="LSG2">

<PNTA="2" В=”начало” C="40.84934" D-"-96.122322" E=”123506” F-"1" l=”2.0”/>

<PNTA-"2" В-"конец" C-"40.84911" D="-96.591122" E="122544" F-"1" !="2.0"/>

</LSG>

</GPN>

</GGP>

</PFD>

<TSK A-"TSK1" F=”WKR1” G="1 ">

<GANA-"GGP1">

<ASP A=”2003-08-20T08:00:00” B=”2003-08-20T17:00:00" D-"1"/>

</GAN>

</TSK>

D.29 GuidanceGroup — GGP

Тип:

Данные кодирования

Описание:

XML-элемент GuidanceGroup (группа заданных направлений) группирует вместе один или несколько Guidance Pattern (GPN). Guidance Pattern в группе предназначены для использования одновременно. Как правило, группа заданных направлений будет содержать два шаблона заданного направления на поворотную полосу и один шаблон заданного направления на основное поле, но она может содержать любую комбинацию шаблонов заданного направления на рабочий участок поля и поворотную полосу. Ситуации, когда часть поля ограничена несколькими внешними полигонами, могут потребовать использования нескольких шаблонов задания направления для поворотной полосы/рабочего участка поля. Группа заданнных направлений может содержать один шаблон задания направления, и в этом случае этот шаблон направления должен быть шаблоном заданного направления для рабочего участка поля.

XML-элемент GuidanceGroup добавлен в версии 4 стандарта ИСО 11783-10. Включает XML-элемент:

  • — GuidancePattern

  • — Polygon

Включен XML-элементом:

  • — Partfield

Указан XML-элементами:

  • — GuidanceAllocation

Таблица D.29 — Атрибуты GuidanceGroup

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

GuidanceGroupId

A

г

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор

GuidanceGroup.

Формат: (GGP|GGP-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

GuidanceGroupDesignator

В

о

xs:string

Макс. 32

Обозначение GuidanceGroup

GuidancePattern

г

xs:element

Включает список XML-элемента GuidancePattern

BoundaryPolygon

О

xs:element

Включает списокXML-элемента Polygon для определения границы для этого GuidanceGroup. Граничные полигоны используются, чтобы ограничить геометрию GuidancePattern в этой GuidanceGroup до определенной области внутри границы поля. Следует обратить внимание, что у каждого граничного полигона могут быть внутренние границы в дополнение к внешней границе, определяющие зоны исключения

ПРИМЕР.

<GGPA-”GGP1”>

<GPN A=”GPN1” В=”Адаптивная кривая” С=”2” D=”1”>

<LSG А=”5”>

<PNT А=”6” С=”58.8754321”D-”8.945832”/>

<PNT А=”9” С=”58.8757777” D=”8.94777”/>

<PNT А=”7” С= ”58.8789999” D=”8.99889099”/>

</LSG>

</GPN>

</GGP>

D.30 GuidancePattern — GPN

Тип:

Данные кодирования

Описание:

XML-элемент GuidancePattern (шаблон заданных направлений) описывает свойства, необходимые для передачи данных для выполнения процесса задания направления. XML-элемент GuidancePattern содержит свойства, которые классифицируют шаблон задания направления, в то время как дочерний XML-элемент LineString описывает геопространственную информацию.

Каждый XML-элемент GuidancePattern будет содержать один и только один XML-элемент LineString. Точки в LineString будут определяться классификацией GuidancePattern. Ширина полосы, разделяющая соседние полосы движения в шаблоне задания направления, представлена атрибутом LineStringWidth в XML-элементе LineString. В следующей таблице определены точки, которые должны использоваться для каждого типа GuidancePattern:

Таблица D.30 А — Атрибуты GuidancePattern

Тип линий

Необходимые точки

Дополнительные точки

Примечания

АВ

Начальная точка должна быть А, а; конечная точка — В

Без дополнительных точек

Окончание таблицы D.30 А

Тип линий

Необходимые точки

Дополнительные точки

Примечания

А+

Одна точка

Без дополнительных точек

Должен быть определен заголовок. Строки А+ без заголовка недействительны

Curve

Начальная точка должна быть А, за ней следует любое количество точек задания направления, за которой следует конечная точка В.

Между точками А и В может быть любое количество точек задания направления (тип 9)

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

Pivot

Одноцентровая точка

Одноцентровая точка, сопровождаемая А, сопровождаемым В

Точки А и В используются, чтобы определить угол начальной и конечных точек для неполных окружностей.

Точки поворота считают полными окружностями, если иное не указано в атрибуте опций (options)

Spiral

Одна точка А, за которой следует любое количество точек направления, за которой следует одна точка В

Между точками А и В может быть любое количество точек направления (тип 9)

Примеры этих 5 типов шаблона показаны на рисунке D.1.

Линии АВ, А+, и Кривая будут сгенерированы параллельно предыдущей линии и смещены на расстояние, определяемое шириной полосы.

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

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

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

Горизонтальная и вертикальная точность может быть определена один раз для всей GuidancePattern или может быть определена в каждой отдельной точке. Если эти точности присутствуют в обоих XML-элементах, то точность, определенная в отдельных точках, имеет приоритет.

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

XML-элемент GuidancePattern добавлен в версии 4 стандарта ИСО 11783-10.

Включен в XML-элемент:

  • — GuidanceGroup

Включает XML-элемент:

  • — UneString

  • — Polygon

Ссылается на XML-элемент:

  • — BaseStation



    Кривая


    Точка поворота

    Спираль


    Ширина ряда


Рисунок D.1 — Типы шаблона заданного направления

Таблица D.30 В — Атрибуты GuidancePattern

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

GuidancePatternld

A

г

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор

GuidancePattern.

Формат: (GPN|GPN-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

GuidancePatternDesignator

В

о

xs: string

Макс. 32

Обозначение GuidancePattern

GuidancePatternType

С

г

xs:NMTOKEN

1...5

Выбор типа:

  • 1 =АВ.

  • 2 = А+.

  • 3 = Кривая.

  • 4 = Точка поворота.

  • 5 = Спираль

Продолжение таблицы D.30 В

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

GuidancePatternOptions

D

0

xs:NMTOKEN

1...3

  • 1 = По часовой стрелке — для точки поворота.

  • 2 = Против часовой стрелки — для точки поворота.

  • 3 = Полный круг — для точки поворота

GuidancePatternPropagation Direction

E

0

xs:NMTOKEN

1...4

  • 1 = В обоих направлениях.

  • 2 = Только влево.

  • 3 = Только вправо.

  • 4 = Нет распространения.

Направление работ определяется, стоя на первой точке (А) и глядя на следующую точку.

Если этот атрибут не будет определен в GuidancePattern, распространение должно применяться в обоих направлениях

GuidancePatternExtension

F

0

xs:NMTOKEN

1...4

  • 1 = От первой и последней точки.

  • 2 = Только от первой точки (А).

  • 3 = Только от последней точки (В).

  • 4 = Нет продления.

Если этот атрибут не определен в GuidancePattern, то продление должно применяться как от первой, так и от последней точки.

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

GuidancePatternHeading

G

0

xs:decimal

0,0...360,0

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

GuidancePatternRadius

H

0

xs:unsignedLong

От 0 до (232 - 2)

Информация о радиусе точки поворота в мм

GuidancePatternGNSS Method

I

0

xs:NMTOKEN

0...17

Ссылка на параметр метода NMEA2000 ГНСС 2000:

  • 1 = Поправка ГНСС.

  • 2 = Поправка ДГНСС.

  • 3 = Точная ГНСС.

  • 4 = Целочисленная поправка RTK.

  • 5 = Плавающая RTK.

  • 6 = Расчетный (DR) режим.

  • 7 = Ручной ввод.

  • 8 = Режим моделирования (NMEA 2000 определяет максимально 16 токенов (для метода ГНСС).

Дополнительные методы не NMEA 2000:

  • 16 = Данные, созданные на рабочем столе.

  • 17 = Другое

Продолжение таблицы D.30 В

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

GuidancePatternHorizontal

Accuracy

J

0

xs:decimal

От 0,0 до 65,0

Расчетная точность по горизонтали (ошибка RMS), в м

GuidancePatternVertical

Accuracy

К

0

xs:decimal

От 0,0 до 65,0

Расчетная точность по вертикали (ошибка RMS), в м

BaseStationldRef

L

0

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент BaseStation. Формат: (BSN|BSN-) ([0—9]) +

OriginalSRID

M

0

xs:string

32

Система координат и метод проецирования, используемый системой задания направления во время создания GuidancePattern. Эта информация может помочь в представлении GuidancePattern, когда он представлен на GUI после перезагрузки GuidancePattern. Атрибут OriginalSRID состоит из организационного идентификатора и известного идентификатора (WKID) для метода проекции и/или системы координат. Примером изменения OriginalSRID является «EPSG:4326».

Следует обратитть внимание, что единицы измерения GuidancePattern не изменяются, когда OriginalSRID не является системой координат типа WGS-84 и проекцией. Координаты GuidancePattern передаются в наборе файлов передачи данных как широта, долгота и высота в соответствии с WGS-84

NumberOfSwathsLeft

N

0

xs:unsignedLong

От 0 до (232 - 2)

Количество полос для распространения GuidancePattern влево. Направление определяется при нахождении в первой точке (А) и взглядом по направлению на следующую точку.

Если этот атрибут не определен, распространение влево не ограничивается определенным количеством полос и определяется атрибутом GuidancePatternPropa-gationDirection

NumberOfSwathsRight

0

0

xs:unsignedLong

От 0 до (232 - 2)

Количество полос для распространения GuidancePattern вправо.

Направление определено при нахождении в первой точке (А) и взглядом по направлению на следующую точку.

Если этот атрибут не определен, распространение вправо не связано определенным количеством полос и определяется атрибутом GuidancePatternProp-agationDirection

Окончание таблицы D.30 В

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

LineString

г

xs:element

Включает единственный XML-элемент LineString

BoundaryPolygon

о

xs:element

Включает список XML-элемента Polygon.

Необязательная граница для этой линии. Граница может использоваться для ограничения действия GuidancePattern в определенной области.

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

ПРИМЕР 1. Шаблон заданного направления АВ

<GPN A=”GPN1” В=”АВ” С=”1 ” Е=“3“ F=“3“>

<LSGA=”5”>

<PNT А=”6” С=”58.8754321 ” D=”8.945632”/>

<PNTA=”7” С=”58.8789999” D-”8.99889099”/>

</LSG>

</GPN>

ПРИМЕР 2. Шаблон заданного направления по кривой

<GPNA=”GPN1” В=”Адаптивная кривая” С=”3”>

<LSG А=”5”>

<PNT А=”6” С=”58.8754321” D=”8.945632’7>

<PNT А-”9” С=”58.8757777” D=”8.94777”/>

<PNT А=”7” С=”58.8789999” D=”8.99889099’7>

</LSG>

</GPN>

ПРИМЕР 3. Шаблон заданного направления точки поворота

Полный круг, центр задается как одна точка:

<GPNA=”GPN1” В-”Поворот (полный круг)” С-”4” D=”3” Е-”1” Н=”700000”>

<LSGA=”5”>

<PNT А-”8” С=”58.8789999” D=”8.99889099’7>

</LSG>

</GPN>

Частичный круг, направление по часовой стрелке, центр, начальная и конечная точки, определенные в порядке С А В:

<GPNA=”GPN1” В=”Поворот (по часовой стрелке)” С-”4” D=”1” Е-"1” Н=”700000”>

<LSG А=”5”>

<PNT А=”8” С=”58.8789999” D=”8.99889099’7>

<PNT А-”6” С=”58.8754321” D=”8.945632”/>

<PNT А=”7” С=”58.8757777” D-”8.94777”/>

</LSG>

</GPN>

D.31 GuidanceShift — GST

Тип:

Данные задачи

Описание:

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

На рисунке D.2 показано, как атрибуты EastShift и NorthShift применяются к типам прямолинейных шаблонов, криволинейных шаблонов и шаблонов разворота. Когда атрибуты EastShift (сдвиг на восток) и NorthShift (сдвиг на север) применяются к спиральному типу шаблона, происходит аналогичное смещение как указанного шаблона, так и распространяемых шаблонов. Типичное назначение атрибутов EastShift и NorthShift заключается в корректировке шаблона задания направления для смещения системы позиционирования.

Смещение навигации А-В

Смещение кривой навигации

Точка поворота смещения навигации


Рисунок D.2 — Смещения шаблона заданного направления

Атрибут Propagationoffset смещает распространяемые шаблоны заданного направления перпендикулярно исходному шаблону направления. Как видно из рисунка D.3, влияние смещения на прямую траекторию движения аналогично сочетанию NorthShift и EastShift. Однако для типов кривой, поворота и спирали шаблонов Propagationoffset отличается от комбинации NorthShift и EastShift тем, что распространяемые шаблоны задания направления не перемещаются, а восстанавливаются.


Смещение кривой навигации


Точка поворота


Рисунок D.3 — Смещения шаблона заданного направления

XML-элемент GuidanceShift добавлен в версии 4 стандарта ИСО 11783-10.

Ссылается на XML-элементы:

  • — GuidancePattern

Включен XML-элементом:

  • — GuidanceAllocation

Включает XML-элемент:

  • — Allocationstamp

Таблица D.31 — Атрибуты GuidanceShift

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

GuidanceGroupIdRef

A

r

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент GuidanceGroup.

Формат: (GGP|GGP-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы.

Примечание — Требуется ссылка на GuidanceGroup или на GuidancePattern

GuidancePatternldRef

В

r

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент Guidance-Pattern.

Формат: (GPN|GPN-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы.

Примечание — Требуется ссылка на GuidanceGroup или GuidancePattern

GuidanceEastShift

C

0

xs:signedLong

От -231 до (231-1)

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

GuidanceNorthShift

D

0

xs:signedLong

От -231 до (231-1)

Информация о смещении управления в мм на проектируемой касательной плоскости с точкой А как ориентир

Propagationoffset

E

0

xs:signedLong

От -231 до (231-1)

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

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

Allocationstamp

0

xs:element

Включает единственный XML-элемент Allocationstamp

ПРИМЕР.

<TSK A=”TSK1” D=”FRM1” G=”1” E=”PFD1 ”>

<GAN A=”GGP1”>

<ASP A=”2003-08-20T08:00:00” D-"1 ”/>

<GST B=”GPN2” C=”100” D=”150””>

<ASP A=”2003-08-20T08:10:00” D-"1 ”/>

</GST>

</GAN>

</TSK>

D.32 ISO11783_TaskData

Тип:

Корневой элемент

Описание:

XML-элемент ISO11783_TaskData — является основным XML-элементом, называемым корневым элементом, и содержит определения о конструкции XML-файла (номер версии ...) и использовании основных XML-элементов.

Включает XML-элемент:

  • — Task

  • — CodedComment

  • — CodedCommentGroup

  • — ColourLegend

  • — CropType

  • — CulturalPractice

  • — Customer

  • — Farm

  • — Device

  • — OperationTechnique

  • — Partfield

  • — Product

  • — ProductGroup

  • — ValuePresentation

  • — Worker

  • — ExternalFileReference

  • — TaskControllerCapabilities

Таблица D.32 — Атрибуты ISO11783_TaskData

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

VersionMajor

VersionMajor

r

xs:NMTOKEN

От 0 до 4

Номер выпуска элемента списка (основной), используемый, чтобы указать версию ИСО 11783-10, которой соответствует этот файл данных задачи:

0 = Версия DIS (проект международного стандарта).

  • 1 = Версия FDIS.1 (заключительный проект Международного стандарта, первое издание).

  • 2 = Версия FDIS.2 и первое издание, опубликованное как Международный стандарт.

  • 3 = Версия второго издания, опубликованного как проект Международного стандарта (Е2. DIS).

  • 4 = Версия второго издания, опубликованного как заключительный проект Международного стандарта (Е2. FDIS)

VersionMinor

VersionMinor

r

xs:NMTOKEN

От 0 до 99

Номер версии элемента списка (второстепенный), используемый для обозначения XML schema, которой соответствует этот элемент. См. пункт 8.4 для соглашения о присвоении имен XML schema

Managementsoftware

Manufacturer

Management Software Manufacturer

o/ra

xs:string

32

Название производителя программного обеспечения управления

Managementsoftware

Version

Management Software Version

o/ra

xs:string

32

Версия программного обеспечения управления

TaskController Manufacturer

Task Controller Manufacturer

o/ra

xs:string

32

Название производителя ТС

Продолжение таблицы D.32

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

TaskControllerVersion

Task Controller Version

o/ra

xs:string

32

Версия программного обеспечения ТС

DataTransferOrigin

Data Transfer Origin

r

xs:NMTOKEN

1

Описывает источник XML-файла:

  • 1 = FMIS.

  • 2 = MICS.

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

DataTransfer Language13

lang

0

xs:language

32

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

AttachedFile

AFE

0

xs:element

Включает список XML-элемента

AttachedFile

BaseStation

BSN

0

xs:element

Включает список XML-элемента BaseStation

CodedComment

CCT

0

xs:element

Включает список XML-элемента CodedComment

CodedCommentGroup

CCG

0

xs:element

Включает список XML-элемента CodedCommentGroup

ColourLegend

CLD

0

xs:element

Включает список XML-элемента ColourLegend

CropType

CTP

0

xs:element

Включает список XML-элемента CropType

CulturalPractice

CPC

0

xs:element

Включает список XML-элемента CulturalPractice

Customer

CTR

0

xs:element

Включает список XML-элемента Customer

Device

DVC

0

xs:element

Включает список XML-элемента Device

Farm

FRM

0

xs:element

Включает список XML-элемента Farm

OperationTechnique

OTQ

0

xs:element

Включает список XML-элемента OperationTechnique

Partfield

PFD

0

xs:element

Включает список XML-элемента Partfield

Product

PDT

0

xs:element

Включает список XML-элемента Product

ProductGroup

PGP

0

xs:element

Включает список XML-элемента ProductGroup

Task

TSK

0

xs:element

Включает список XML-элемента Task

TaskController Capabilities0

TCC

o/ra

xs:element

Включает единственный XML-элемент TaskControllerCapabili-ties

ValuePresentation

VPN

0

xs:element

Включает список XML-элемента

ValuePresentation

Окончание таблицы D.32

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Worker

WKR

о

xs:element

Включает список XML-элемента Worker

ExternalFileReference

XFR

о

xs:element

Включает список XML-элемента ExternalFileReference

а Необязательный или обязательный статус этого атрибута зависит от источника передачи данных. Этот атрибут не используется, когда источником передачи данных является FMIS. Требуется информация о ТС, когда источником передачи данных являются MICS.

ь Этот атрибут представлен в версии 4 стандарта ИСО 11783-10.

с Этот элемент представлен в версии 4 стандарта ИСО 11783-10.

ПРИМЕР.

<ISO11783_TaskData VersionMajor=”4” VersionMinor=”0”

TaskControllerManufacturer= ’’FarmCtrl” TaskControllerVersion=”1.0”

ManagementSoftwareManufacturer= ’’FarmSystem ”

Managemen tSoftware Version=”1.0 ” Da ta TransferOrigin=”1 ” lang="en-GB ”>

<TSK A=”TSK1 ” F=”WKR1” G=”1 ”>

</TSK>

</ISO11783_TaskData>

D.33 LineString — LSG

Тип:

Данные задачи

Описание:

XML-элемент LineString описывает положение, длину и внешний вид траектории пути. Признак типа LineStrings можно использовать для назначения комментария ко всем позициям LineString. Это делается для того, чтобы ТС мог отображать сгенерированные на стороне фермы комментарии, хранящиеся в XML-атрибуте LineStringDesignator в определенных позициях, как информационные сообщения оператору.

LineStrings должны быть отображены в виде серии линий, соединяющих точки в том порядке, в котором они перечислены в XML-элементе LineString. LineString должен быть закрыт, если он представляет собой внешнюю или внутреннюю границу полигона (типы 1 и 2). В этом случае первая точка в LineString должна быть повторена как последняя точка в соответствии с тем, как LineString закрывается в соответствующем объекте GML. Обратите внимание, что до версии 4 для LineString типа 1 или 2 первая точка не должна была быть включена в качестве последней точки, чтобы отобразить замкнутую границу, требования в версиях 2 и 3, где также требовалось отобразить линию между последней точкой и первой точкой в списке точки на XML-элементы для LineStrings типа 1 и 2.

Атрибут LineStringID используется только в том случае, если XML-элемент LineString не является дочерним элементом XML-элемента Polygon или XML-элемента GuidancePattern.

Включает XML-элемент:

  • — Point

Включен XML-элементом:

  • — Partfield

  • — Polygon

Таблица D.33 — Атрибуты LineString

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

LineStringType (Тип линейной строки)

А

г

xs:NMTOKEN

От 1 до 9

Тип LineString, возможные величины: 1 = PolygonExterior.

  • 2 = Polygoninterior.

  • 3 = TramLine.

  • 4 = SamplingRoute.

  • 5 = GuidancePattern.

  • 6 = Дренаж.

  • 7 = Забор.

  • 8 = Метка.

  • 9 = Препятствие, любой вид препятствия, например используемый, чтобы генерировать предупреждение, приближаясь к препятствию3

LineStringDesignator

В

о

xs:string

Макс. 32

LineString имя или комментарий

LineStringWidth

С

о

xs:unsignedLong

От 0 до (232-2)

Ширина LineString, в мм.

Это — ширина в реальных единицах измерения, т.е. как измеряется на PartField.

LineStringType 5 (GuidancePattern) для LineStringWidth представляет ширину, которая разделяет смежные пути шаблона заданного направления

LineStringLength (Длина линейной строки)

D

о

xs:unsignedLong

От 0 до (232-2)

Длина LineString, в мм.

Это — длина в реальных единицах измерения, т.е. измеряется как Partfield

LineStringColour (Цвет линейной строки)

Е

о

xs:unsignedByte

От 0 до 254

Цвет LineString.

Формат: палитра как ИСО 11783-6

LineStringlda (Идентификатор линейной строки)

F

о

xs: ID

От миним. 4

до макс. 14

Уникальный идентификатор

LineString.

Формат: (LSG|LSG-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

Point

г

xs:element

Включает список XML-элемента Point

а Это определение представлено в версии 4 станадарта ИСО 11783-10.

ПРИМЕР.

<LSG А=”6” Е=”1” B=”Line1” D="2000” С=”20”>

<PNT А=”2” С=”58.8754321” D=”8.945632” F-”1” B=”start” E=”50"/>

<PNTA=”2” C=”58.8789999” D=”8.99889099” F-”1” B=”end” E=”50’7>

</LSG>

D.34 OperationTechnique — OTQ

Тип:

Данные кодирования

Описание:

XML-элемент OperationTechnique описывает методы работы, такие как: «Посев», «Обработка», «Распыление».

Указан XML-элементами:

  • — OperTechPractice

  • — OperationTechniqueReference

Таблица D.34 — Атрибуты OperationTechnique

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

OperationTechniqueld

А

г

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор

OperationTechnique.

Формат: (OTQIOTQ-) ([0—9]) +.

Записи, сгенерированные на

MICS, имеют отрицательные идентификаторы

OperationTechniqueDesignator

В

г

xs:string

Макс. 32

Обозначение OperationTechnique

ПРИМЕР.

<OTQ A=”OTQ1” В=”Посев’7>

<OTQ A=”OTQ2” В=”Обработка”/>

<OTQ A=”OTQ3” В=”Распыление’7>

D.35 OperationTechniqueReference — OTR

Тип:

Данные кодирования

Описание:

XML-элемент OperationTechniqueReference содержит ссылку на единственный OperationTechnique.

Включен XML-элементом:

  • — CulturalPractice

Ссылается на XML-элементы:

  • — OperationTechnique

Таблица D.35 — атрибуты OperationTechniqueReference

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

OperationTechniqueldRef

А

г

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент OperationTechnique.

Формат: (OTQ|OTQ-)([0—9])+

ПРИМЕР.

<OTR A=”OTQ1” />

D.36 OperTechPractice — OTP

Тип:

Данные задачи

Описание:

XML-элемент OperTechPractice, связанный с задачей, обеспечивает назначение комбинации конкретной техники и операции с одной агротхнической культурой.

Включен XML-элементом:

  • — Task

Ссылается на XML-элементы:

  • — OperationTechnique

  • — CulturalPractice

Таблица D.36 — Атрибуты OperTechPractice

Атрибут

XML

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

Тип

Длина

Комментарий

CulturalPracticeldRef

А

г

xs:IDREF

От миним. 4

до макс. 14

Ссылка на XML-элемент CulturalPractice. Формат: (СРС|СРС-) ([0—9]) +

OperationTechniqueldRef

В

о

xsJDREF

От миним. 4

до макс. 14

Ссылка на XML-элемент OperationTechnique.

Формат: (OTQIOTQ-) ([0—9]) +

ПРИМЕР.

<ОТРА~”СРС1” B=”OTQ1’7>

D.37 Partfield — PFD

Тип:

Данные кодирования

Описание:

XML-элемент Partfield описывает участки земли, которым может быть присвоена Task. Partfield — это динамический объект, который создается в тот момент, когда известно, что он будет обрабатываться как единое целое. Partfield может быть пустым или засеянным одним типом культуры СгорТуре. В случае неполного посева указывается только основной тип СгорТуре. Partfield заканчивается, когда запускается новая единица растениеводства или когда она объединяется с соседним Partfield. Partfield может быть целым полем или частью поля. Когда Partfield состоит из нескольких участков земли, все участки должны располагаться рядом друг с другом, например только разделенные относительно узкими полосами земли. Каждый участок земли, относящийся к одному Partfield, ограничен одним Polygon. До версии 4 в поле детали можно было включить только один Polygon, представляющий границу. В версии 4 и более поздних версиях — несколько Polygon, каждый из которых представляет ограниченную область поля, могут быть включены в одно поле.

Partfield с 1 границей Polygon, содержащей 1 внешнюю и 3 внутренние LineStrings


Partfield с 3 границами Polygon, каждый Polygon содержит 1 внешнюю LineString


Partfield с 2 границами Polygon, каждый Polygon содержит 1 внешнюю






Рисунок D.4 — Примеры полигона границы Partfield и LineString

Partfield могут относиться только к Polygon LineString и Point, которые не связаны с Treatmentzones.

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

Указан XML-элементами:

— Task

Ссылается на XML-элементы:

— СгорТуре

— CropVariety

— Customer

— Farm

Включает XML-элемент:

— Polygon

— LineString

— Point

— GuidanceGroup

Таблица D.37 — Атрибуты Partfield

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Partfield Id

A

r

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор partfield.

Формат: (PFD|PFD-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

PartfieldCode

В

0

xs:string

Макс. 32

Номер поля от FMIS

PartfieldDesignator

C

r

xs: string

Макс. 32

Обозначение/название поля

PartfieldArea

D

r

xs:unsignedLong

От 0 до (232-2)

Размер поля, в м2

CustomerldRef

E

0

xsJDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент Customer. Формат: (CTR|CTR-) ([0—9]) +

FarmldRef

F

0

xsJDREF

От миним. 4 до макс. 14

Ссылка на XML-элемента Farm. Формат: (FRM|FRM-) ([0—9]) +

CropTypeldRef

G

0

xsJDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент СгорТуре. Формат: (СТР|СТР-) ([0—9]) +

CropVarietyldRef

H

0

xsJDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент CropVariety. Формат: (CVT|CVT-) ([0—9]) +

FieldldRef

I

0

xsJDREF

От миним. 4 до макс. 14

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

Формат: (PFD|PFD-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

Polygon

0

xs:element

Включает список XML-элемента

Polygon

LineString

0

xs:element

Включает список XML-элемента Line-String

Point

0

xs:element

Включает список XML-элемента Point

GuidanceGroup

0

xs:element

Включает список XML-элемента GuidanceGroup

ПРИМЕР.

<PFD A=”PFD3” С=”холм” D=”32000” G=”CTP3”/>

D.38 Point — PNT

Тип:

Данные задачи

Описание:

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

Атрибут Point ID используется только в том случае, если XML-элемент Point не является дочерним XML-элементом элемента LineString.

Включен XML-элементом: — LineString

  • — Partfield

  • — LineString

  • — Partfield

Таблица D.38 — Атрибуты Point

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

PointType

А

г

xs:NMTOKEN

От 1 до 11

Определяет описание этой точки: 1 = Метка.

2 = Другой.

Окончание таблицы D.38

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

  • 3 = Доступ к полю, точка въезда на поле3.

  • 4 = Склад, место хранения продукции на поле3.

  • 5 = Препятствие, любой вид препятствия, например, используемый, чтобы генерировать предупреждения, приближаясь к препятствию3.

  • 6 = Guidance Reference А, начальная точка направления линии, например точка А на линии А-В3.

  • 7 = Guidance Reference В, конечная точка направления линии, например точка В на линии А-В3.

  • 8 = Guidance Reference Center, центральная точка шаблона поворота системы направления.

  • 9 = Guidance Point, относится к заданному направлению точки, которая не является ни А, ни В, ни центральной контрольной точкой3.

  • 10 = Partfield Reference Point, местоположение, например, в Partfield, определяющее поле для административных целей3.

  • 11 = База3

PointDesignator

в

о

xs:string

Макс. 32

Название точки, описания или комментария

PointNorth

С

г

xs:decimal

От -90,0 до 90,0

Положение GPS на север. Формат: WGS84

PointEast

D

г

xs:decimal

От -180,0 до 180,0

Положение GPS на восток. Формат: WGS84

PointUp

Е

О

xs:long

От (-231+1) до (231-1)

Высота. Положение GPS, в мм. Формат: эллипсоид WGS84

PointColour

F

О

xs:unsignedByte

От 0 до 254

Цвет точки.

Формат: палитра как ИСО 11783-6

Pointlda

G

О

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор точки.

Формат: (PNT|PNT-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

PointHorizontal

Accuracy3

Н

О

xs:decimal

От 0,0 до 65,0

Расчетная точность по горизонтали точки (ошибка RMS), в м

Pointvertical

Accuracy3

I

О

xs:decimal

От 0,0 до 65,0

Расчетная точность точки по вертикали (ошибка RMS), в м

Filename3

J

О

xs:ID

8

Уникальное имя двоичного файла точки. Формат: PNT [0—9] [0—9] [0—9] [0—9] [0-9]

Filelength3

К

О

xs:unsignedLong

ОтО до(232-2)

Длина двоичного файла точки в байтах

3 Это определение представлено в версии 4 стандарта ИСО 11783-10.

ПРИМЕР 1. LineString с Points в формате XML

<LSG А=”6” Е-”1” B=”Line1" D=”2000” С="20”>

<PNT А=”2” С=”58.8754321” D=”8.945632” Р=”Г’ В=”Начало” Е="50’7>

<PNT А=”2” С-"58.8789999" D=”8.99889099” F="1" В="Конец" Е="50’7>

</LSG>

ПРИМЕР 2. LineString с Points в двоичном формате

<LSG А=”6” Е=”1” B=”Line1” D=”2000” С=”20”>

<PNT А=”2” С=”” D=”” Е=”” F=”1” J=”PNT00001” К=”40”/>

</LSG>

D.39 Polygon — PLN

Тип:

Данные задачи

Описание:

XML-элемент Polygon описывает область путем включения LineStrings. Polygon может использоваться для указания границы поля или области Treatmentzone.

До версии 4 в один Polygon можно было включить несколько строк внешних границ LineStrings. В версии 4 и более поздних версиях Polygon должен описывать только одну поверхность, которая соответствует определению полигона в GML.

Polygons с типовой меткой можно использовать для назначения комментария ко всем позициям внутри Polygon. Это необходимо для того, чтобы ТС мог отображать сгенерированный на стороне фермы комментарий, хранящийся в XML-атрибуте PolygonDesignator в определенных позициях в виде информационных сообщений оператору.

Включен XML-элементом:

  • — Partfield

  • — Treatmentzone

Включает XML-элемент:

  • — LineString

Таблица D.39 — Атрибуты Polygon

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

PolygonType

A

r

xs:NMTOKEN

От 1 до 12

Типы полигона, возможные величины:

  • 1 = Граница Partfield.

  • 2 = Treatmentzone.

  • 3 = WaterSurface.

  • 4 = Здание.

  • 5 = Дорога.

  • 6 = Препятствие.

  • 7 = Метка.

  • 8 = Другой.

  • 9 = Основное поле, основная область поля используется для выращивания3.

  • 10 = Поворотная полоса. Площадь поля, используемая для поворота, обычно засеянная в другом направлении, чем основная площадь поля. Определение и пример основной области поля: граница поля за вычетом препятствий, водной поверхности, не-запаханной поворотной полосы поля.

  • 11 = BufferZone, область поля, которую нужно обрабатывать по-другому, в соответствии с экологическими нормами3.

  • 12 = Ветрозащитная полоса, окружающая поле с целью уменьшения ветра на поле3

PolygonDesignator

В

0

xs:string

Макс. 32

Обозначение/название полигона

PolygonArea

C

0

xs:unsignedLong

От Одо (232 - 2)

Площадь полигона, в м2

PolygonColour

D

0

xs:unsignedByte

От 0 до 254

Цвет полигона.

Формат: палитра как в ИСО 11783-6

Окончание таблицы D.39

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Polygonlda

Е

о

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор полигона.

Формат: (PLN|PLN-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

LineString

г

xs:element

Включает список XML-элемента Line-String. Может быть включено не более одного LineString типа внешней границы. Может быть включено несколько LineStrings типа внутренней границы, где каждая внутренняя граница не должна пересекать внешнюю границу или другую внутреннюю границу. Внутренние границы могут касаться внешней или внутренней границы

а Это определение представлено в версии 4 стандарта ИСО 11783-10.

ПРИМЕР.

<PLNA=”1” В="Граница поля" С=”32000” D=”1 ”>

<LSG А="1" B-"Line1" С="20" D-"280000" Е-"1">

<PNTA-"2" В=”Начало” С="40.84982" D="-96.596045" Е-"150234" F=”1’7>

<PNTА="2” В="Середина" С="40.84982" D="-96.592655" Е="148987” F="1"/>

<PNT А-"2" В-"Конец" С-"40.846573" D="-96.592526" Е="148284" F-"1"/>

<PNT А=”2" В-"Начало" С-"40.84982" D=”-96.596045” Е="150234" F="1"/>

</LSG>

</PLN>

D.40 Position — PTN

Тип:

Данные задачи

Описание:

XML-элемент Position описывает отслеживаемое положение. Позиция является частью спецификации Allocationstamp или Time. С помощью последнего он может быть использован, например, для регистрации DataLogValue вместе с положением позиции.

Включен XML-элементом:

  • —Allocationstamp

  • — Time

Таблица D.40 — Атрибуты Position

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

PositionNorth

A

r

xs:decimal

От -90,0 до 90,0

Положение GPS на север WGS84

PositionEast

В

r

xs:decimal

От -180,0 до 180,0

Положение GPS на востоке WGS84

PositionUp

C

0

xs:long

От -231 до (231-1)

Эллипсоид высоты WGS84 по GPS, в мм

Positionstatus

D

r

xs:NMTOKEN

От 0 до 15

Статус положения.

Определение ссылается на параметр NMEA2000 MethodGNSS.

0 = Без привязки GPS.

  • 1 = Привязка GNSS.

  • 2 = Привязка DGNSS.

Окончание таблицы D.40

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

3 = Точная GNSS, без преднамеренного ухудшения (например, избирательной доступности) и код с более высоким разрешением (P-код) и 2 частоты используются для коррекции атмосферной задержки.

  • 4 = фиксированное значение RTK.

  • 5 = Плавающий RTK.

  • 6 = Режим Est(DR)mode.

  • 7 = Ручной ввод.

  • 8 = Режим моделирования.

9—13 = Зарезервировано.

  • 14 = Ошибка.

  • 15 = Значение Positionstatus недоступно

PDOP

E

0

xs:decimal

От 0,0 до 99,9

Информация о качестве PDOP

HDOP

F

0

xs:decimal

От 0,0 до 99,9

Информация о качестве HDOP

NumberOfSatellites

G

0

xs:unsignedByte

От 0 до 254

Количество используемых спутников

GpslItcTime

H

0

xs:unsignedLong

От 0 до (232-2)

Время UTC, в миллисекундах с полуночи

GpsUtcDate

I

0

xs:unsignedShort

ОтО до (216-2)

Дата в формате UTC в днях относительно 1980—01—01

ПРИМЕР.

<PTN А~”54.588945” В=”9.989209” D=”3”/>

D.41 ProcessDataVariable — PDV

Тип:

Данные задачи

Описание:

XML-элемент ProcessDataVariable включен в Treatmentzone. Он содержит ProcessDataDDI, сопровождаемые значением для этого ProcessDataDDI и дополнительной информацией о продукте и элементах устройства, которые будут использоваться в этой Treatmentzone. ProcessDataVariable может содержать другие переменные данных процесса ProcessDataVariable для описания запланированного распределения нескольких продуктов на один элемент DeviceElement. В этом случае «исходный» ProcessDataVariable указывает ProcessDataDDI, который должен быть отправлен контроллером задач в DeviceElement, в то время как «дочерние» ProcessDataVariable содержат спецификации продукта. «Дочерние» ProcessDataVariable не должны содержать другие ProcessDataVariable и не должны указывать атрибут DeviceElementldRef.

Дополнительные атрибуты ActualCulturalPracticeValue и ElementTypelnstanceValue были введены для активации планирования и отслеживания присвоения значений данных процесса конкретным операциям или экземплярам элементов данного типа. Это активирует возможность различать наборы ProcessDataVariables, когда в одной задаче присутствуют несколько операций или несколько экземпляров одного и того же типа элемента устройства в одной Task. Примером является одновременное управление нормами внесения операции посева и операции внесения удобрений в рамках одной задачи. В этом случае, чтобы отделить данные процесса нормы расхода при посеве от данных процесса нормы расхода удобрений, каждый набор заданных значений данных процесса нормы внесения содержит свое ActualCulturalPractice. Примером использования атрибута ElementTypelnstanceValue является разделение наборов переменных данных процесса, предназначенных для нормы внесения с помощью одних и тех же DDI, но переходящих к отдельным элементам устройства управления скоростью. Использование атрибутов ElementTypelnstanceValue позволяет группировать эти данные процесса по экземпляру контроллера скорости без необходимости их предварительного назначения фактическому элементу устройства. До версии 4 стандарта ИСО 11783-10 такая группировка технологических данных могла быть достигнута только путем запланированного распределения для фактического элемента устройства. Сводная информация для группировки технологических данных в различных версиях стандарта ИСО 11783-10 выглядит следующим образом:

Версия 3 стандарта ИСО 11783-10 и пред- 1) Используйте атрибут ProductldRef, чтобы сгруппировать шествующий: нормы прописывания по продуктам. Для этого в наборе фай

лов передачи данных должен присутствовать фактический продукт.

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

ИСО 11783-10 версия 4 и более поздние версии:


  • 1) Используйте ссылку ProductID для группировки задание для дифференцированного внесения доли по продуктам, если продукт известен и присутствует в наборе файлов для передачи данных.

  • 2) Используйте атрибут ActualCulturalPracticeValue, чтобы сгруппировать задание для дифференцированного внесения значения для технологического процесса, для которого определена задача. Элементы устройства могут содержать значение DDI ActualCulturalPractice, которое позволяет сопоставить операцию с правильным элементом устройства в случае, если задачи или устройства способны выполнять несколько операций.

  • 3) Используйте атрибут ElementTypelnstanceValue для группировки значений задания для дифференцированного внесения с одним и тем же DDI и ActualCulturalPracticeValue по их запланированным устройствам экземпляра элемента управления на устройстве. Элементы устройства могут содержать значение DDI ElementTypelnstance, которое обеспечивает автоматическое сопоставление каждой группы переменных данных процесса устройства с правильным элементом на устройстве.

  • 4) Во время выполнения Task, как только выбрана фактическая машина, атрибут DeviceElementldRef переменных данных процесса может быть обновлен, чтобы сохранить распределение данных процесса по элементам устройства.

Атрибут DeviceElementldRef в XML-элементе ProcessDataVariable является необязательным атрибутом. Применение контроллера задач необходимо для того, чтобы иметь возможность назначить ProcessDataVariable подключенному пользователю, который имеет дескриптор устройства с соответствующим ProcessDataDDI, способным принять этот ProcessDataVariable в качестве заданного значения. Группировка ProcessDataVariables по ProductldRef, ActualCulturalPracticeValue и ElementTypelnstanceld помогает этому процессу быть изменяемым для управляемого процесса назначения DeviceElement.

Включен XML-элементом:

— Treatmentzone

Ссылается на XML-элементы:

— Product

— DeviceElement

— ValuePresentation

Включает XML-элемент:

— ProcessDataVariable

Таблица D.41 — Атрибуты ProcessDataVariable

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

ProcessDataDDI

A

r

xs:hexBinary

От oooo16 до FFFF16

Уникальное число, которое определяет данные процесса DDI (указано в ИСО 11783-11)

ProcessDataValue

В

r

xs:long

От -2J1 до (23,-1)

Содержит величину данных процесса DDI

ProductldRef

C

0

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент Product. Формат: (PDT|PDT-) ([0—9])

Окончание таблицы D.41

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

DeviceElementldRef

D

0

xsJDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент DeviceElement.

Формат: (DET|DET-) ([0—9])

ValuePresentationldRef

Е

0

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент ValuePre-sentation.

Формат: (VPN|VPN-) ([0—9])

ActualCulturalPracticeValue3

F

0

xs:long

От -231 до (231-1)

Содержит величину ActualCulturalPractice DDI, для которого запланированы или назначены данные этого процесса

ElementTypelnstanceValue3

G

0

xs:long

От -231 до (231-1)

Содержит величину ElementTypeln-stance DDI, для которого запланированы или назначены данные процесса

ProcessDataVariable

0

xs:element

Включает список XML-элемента ProcessDataVariable

a Этот атрибут представлен в версии 4 стандарта ИСО 11783-10.

ПРИМЕР 1. ProcessDataVariable, ссылающийся на продукт и DeviceElement.

Для элемента устройства, идентифицированного DET2, задается заданная масса на единицу площади внесения (DDI6) со значением 15000 мг/м2 (150 кг/га) продукта, идентифицированного PDT1:

<PDTA=”PDT1” В=”Гранулированное удобрение”/>

<VPN A-’’VPN1” В=”0” С=”0.01” D=”0” Е=”кг/час’7>

<TSKA=”TSK1” G=”1” Н=”0”>

<TZN А=”0” В-"Зона обратки по умолчанию”>

<PDVА=”0006” В=”15000” C=”PDT1" D=”DET2” E=”VPN1’7>

</TZN>

</TSK>

Пример 2. ProcessDataVariables c ActualCulturalPracticeValue, заданными для отличия между двумя операциями, управление по положению задано конфигурацией полигонов.

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

<PDT A=”PDT1” В=”Гранулированное удобрение”/>

<PDTA=”PDT2” В=”Подсолнух7>

<VPN A=”VPN1” В-"0" С-"0.01" D=”0” Е=”кг/час7>

<TSKA-”TSK1” G=”1” Н=”0”>

<TZNA=”1” B=”Layer 1, Rate 1" C=”2”>

<!— низкая скорость внесения удобрения —>

<PDVА=”0006” В=”5000” C=”PDT1” E=”VPN1” F=”17>

... список полигонов для указания областей этой зоны обработки ...

</TZN>

<TZNA=”2" B=”Layer 1, Rate 2" C=”3”>

</— высокая скорость внесения удобрения —>

<PDVA=”0006” В=”6500” C=”PDT1” E=”VPN1” F=”17>

... список полигонов для указания областей этой зоны обработки ...

</TZN>

<TZN А=”3” B=”Layer 2, Rate Г’ С=”9”>

<!— низкая скорость посадки —>

<PDVA=”0006” В=”800” C=”PDT2” E=”VPN1” F=”2”/>

... список полигонов для указания областей этой зоны обработки ...

</TZN>

<TZN А=”4” В=”Layer 2, Rate 2" С=”10”>

<!— высокая скорость посадки —>

<PDVА=’’0006” В=”1000” C=”PDT2” E=”VPN1” F-n2n/>

... список полигонов для указания областей этой зоны обработки ...

</TZN>

</TSK>

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

Зоны обработки с геометрией полигона, несколькими переменными данных процесса, позволяют группировать ActualCulturalPractice и по значениям ElementTypelnstance:

<PDTA=”PDT1” В=”Гранулированное удобрение N’7>

<PDT A=”PDT2” В=”Гранулированное удобрение Р”/>

<PDTA=”PDT3” В=”Подсолнух’7>

<VPN A=”VPN1» В=”0” С=”0.01” D=”0” Е=”кг/Га”/>

<TSKA~”TSK1" G=”1” Н=”0”>

<TZN А=”1 ” B=”Layer 1, Rate 1” C=”2”>

<!— Низкая норма внесения удобрения N —>

<PDVА=”0006” В=”5000" C=”PDT1” E=”VPN1” F="1” G=”0”/>

... список полигонов для указания областей этой зоны обработки ...

</TZN>

<TZNA=”2” B=”Layer 1, Rate 2" C=”3”>

</— высокая норма внесения удобрений N —>

<PDVА=”0006” В=”6500” C=”PDT1” E=”VPN1" F=”1” G=”0”/>

... список полигонов для указания областей этой зоны обработки ...

</TZN>

<TZN А=”3” B=”Layer 2, Rate 1" C=”12”>

<!— Низкая норма внесения удобрения Р —>

<PDV А=”0006” В=”450” C=”PDT2” E=”VPN1 ” F=”1” G=”1’7>

... список полигонов для указания областей этой зоны обработки ...

</TZN>

<TZN А-”4” B=”Layer 2, Rate 2” C=”13”>

<!— высокая норма внесения удобрений Р —>

<PDVA=”0006” В=”550” C=”PDT2” E=”VPN1” F=”1” G=”1”/>

... список полигонов для указания областей этой зоны обработки ...

</TZN>

<TZN А=”5” B=”Layer 3, Rate 1” С=”9”>

<!— низкая скорость посадки —>

<PDVА-’’0006" В=”800” C=”PDT3” E=”VPN1” F=”2’7>

... список полигонов для указания областей этой зоны обработки ...

</TZN>

<TZN А=”6” B=”Layer 3, Rate 2" C=”10”>

<!— высокая скорость посадки —>

<PDVА=”0006" В=”1000" C=”PDT3” E=”VPN1" F="2”/>

... список полигонов для указания областей этой зоны обработки ...

</TZN>

</TSK>

Пример 4. Переменные технологических данных ProcessDataVariables для устройства сеялки, оснащенного двумя бункерами удобрений и одним бункером семян, различают заданные переменные технологических данных для 3 норм внесения массы/площади. Переменные ProcessDataVariables имеют фактическое значение ActualCulturalPracticeValue и атрибуты значения ElementTypelnstanceValue, заданные для различных двух операций и двух ячеек продукта для одной из операций. Управление по положению задано геометрией сетки типа 2.

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

<PDT A=”PDT1” В=”Гранулированное удобрение N”/>

<PDT A=”PDT2” В=”Гранулированное удобрение Р’7>

<PDTA=”PDT3” В=”Подсолнух’7>

<VPNA=”VPN1 ” В="0” С=”0.01” D=”0” Е-"кг/Га"/>

<TSKA=”TSK1” G=”1" Н=”0”>

<TZNA=”1” B=”Layer 1, Rate 1” C=”2”>

<!— низкая норма внесения удобрения N —>

<PDVA=”0006” В=”” C=”PDT1” E=”VPN1” F=”1” G=”0’7>

<!— низкая норма внесения удобрения Р —>

<PDVА=”0006" В-”" C=”PDT2” E=”VPN1” F=”1” G=”1’7>

</— низкая скорость посадки —>

<PDV А=”0006” В=”” C=”PDT3” E=”VPN1” F=”2"/>

</TZN>

<GRD A=”51.812025” B=”4.284920” C=”1.5E-3” D="1.4E-3" E=”200” F=”300” G=”GRD00001” l=”2” J=”1 ”/> </TSK>

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

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

<PGPA=”PGP1” В=”Соевые бобы" С="2’7>

<PDTA=”PDT1” В=’Тлен’7>

<PDT A=”PDT2" В="Стотард’7>

<VPN A=”VPN1” В-"0" С=”0.01” D="0" Е-"семена/Га"/>

<TSKA-"TSK1" G=”1” Н=”0”>

<TZNA=”1” B="Layer 1, Rate 1" C-"2">

<!— сорт 1 низкий уровень —>

<PDVA="000B" B=”25000” C=”PDT1” E="VPN1" G-"0"/>

... список полигонов для указания областей этой зоны обработки ...

</TZN>

<TZNA-"2" B-"Layer 1, Rate 2" C="3">

  • < !— сорт 1 высокий уровень —>

<PDVA-"000B" В="29000" C="PDT1" E="VPN1" G="0’7>

...список полигонов для указания областей этой зоны обработки...

</TZN>

<TZN А=”3” B=”Layer 2, Rate 1" С="12">

  • < !— сорт 2 низкий уровень —>

<PDVA=”000B” В=”23000" C-"PDT2" E="VPN1" G-"1"/>

...список полигонов для указания областей этой зоны обработки...

</TZN>

<TZNA="4" B=”Layer 2, Rate 2" C="13">

  • < !— сорт 2 высокий уровень —>

<PDVA="000B" В="27000" C="PDT2” E="VPN1" G-"1"/>

  • . .. список полигонов для указания областей этой зоны обработки ...

</TZN>

</TSK>

D.42 Product — PDT

Тип:

Данные кодирования

Описание:

XML-элемент Product описывает единичный продукт, смесь продуктов, продукцию различных сортов сельскохозяйственных культур или посадочный материал различных сортов сельскохозяйственных культур. Продукт может быть связан с ProductGroup. XML-элементы Product, определяющие продукцию или посадочный материал различных сортов сельскохозяйственных культур, группируются в XML-элементы ProductGroup типа «СгорТуре».

Чтобы определить, какие продукты принадлежат к конкретной группе ProductGroup, значения Product-GroupIdRef всех продуктов должны быть проверены на соответствие определенному значению ProductGroupId. Продукты относятся как к продуктам, используемым в задаче (например, химикаты для защиты растений), так и к продуктам, производимым в результате выполнения задачи (сельскохозяйственные продукты).

ValuePresentationldRef и QuantityDDI могут быть использованы для указания представления и определения количества продукта. Следующие DDI должны использоваться для QuantityDDI:

  • 72 Фактическое объемное содержание (мл)

  • 75 Фактическое массовое содержание (г)

  • 78 Фактическое содержание подсчета (количество)

Эти единицы QuantityDDI также могут быть использованы для выбора единицы измерения DDI заданной нормы внесения, необходимой для управления внесением продукта.

ProductType используется для задания типа продукта, единичного или смеси продуктов. В случае смеси продуктов MixtureRecipeQuantity используется для определения всего количества рецептуры смеси. Если ProductType не определен, то используется единичный тип по умолчанию.

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

Встроенные ProductRelation используются для определения компонентов смеси продукта. Для продукта типа «единичный» ProductRelation не должны использоваться. ProductRelation не должны содержать ссылок на продукты типа «смесь».

Если на продукт тип «единичный» сошлются в XML-элементе ProductRelation, то в этом продукте должно быть указано значение QuantityDDI. Если указанный продукт относится к типу «смесь», то этот продукт должен содержать значения для QuantityDDI и MixtureRecipeQuantity.

Смесь продуктов, которая предназначена для повторного использования и может быть выбрана в списке продукции либо в FMIS, либо в MICS, будет иметь ProductType типа «смесь». В некоторых случаях смесь продуктов создается в полевых условиях без намерения повторного использования смеси в дальнейшем. Этот тип смеси должен быть задокументирован, но не может быть выбран из списка продуктов в FMIS или MICS. В этом случае смесь будет иметь тип «Временная смесь».

Ссылается на XML-элементы:

— ProductGroup

— ValuePresentation

Указан XML-элементами:

— ProductAllocation

— ProcessData Variable

— ProductRelation

Включает XML-элемент:

— ProductRelation

Таблица D.42 — Атрибуты Product

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Productld

A

r

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор продукта.

Формат: (PDT|PDT-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

ProductDesignator

В

r

xs:string

Макс. 32

Обозначение продукта/название

ProductGroupIdRef

C

0

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент ProductGroup.

Формат: (PGP|PGP-) ([0—9]) +

ValuePresentationldRef

D

0

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент

ValuePresentation.

Формат: (VPN|VPN-) ([0—9]) +

QuantityDDI

E

0

xs:hexBinary

от 000016

до FFFF16

Уникальное число, которое определяет DDI (указано в ИСО 11783-11) из количества

ProductTypea

F

0

xs:NMTOKEN

От 1 до 3

Тип определения продукта

  • 1 = Единичный (значение по умолчанию).

  • 2 = Смесь.

  • 3 = Временная смесь

MixtureRecipeQuantity3

G

0

xs: long

ОтО до(231 -1)

Содержит полученное количество компонентов рецепта смесей

DensityMassPerVolume3

H

0

xs:long

ОтО до(231 -1)

Плотность продукта, в мг/л, соответствует DDI 121

DensityMassPerCount3

I

0

xs:long

ОтО до(231 -1)

Плотность продукта, в мг/1000, соответствует DDI 122

DensityVolumePerCount3

J

0

xs:long

ОтО до(231 -1)

Плотность продукта, в мл/1000, соответствует DDI 123

Окончание таблицы D.42

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

ProductRelationa

0

xs:element

Включает список XML-элементов ProductRelation в случае, если ProductType имеет установленное значение 2 или 3

а Этот атрибут представлен в версии 4 стандарта ИСО 11783-10.

ПРИМЕР 1. Определение продукции без типа продукции или информации о количестве.

<PDT A=”PDT1” В=”agent V7>

<PDTA=”PDT2” В="agent 2’7>

Пример 2. Определение продукции, предоставление информации о типе продукции и отслеживании его количества.

<PDT A=”PDT3” В=”agent 3” D=”VPN100” E=”0048” F=”1’7>

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

  • < !— Определение продукта жидкой смеси —>

<VPN A=”VPN1” В=”0” С=”0.00Г D=”3” Е=”Г7>

<VPN A=”VPN2” В=”0” С=”0.00Г D=”3” Е=”кг”/>

  • < !— Определение жидкого продукта 10, QuantityDDI 004816 (72) = Фактический объем —>

<PDT A=”PDT10” Byproduct 10” D=”VPN1” E=”0048’7>

  • < !— Определение жидкого продукта 20, QuantityDDI 004816 (72) = Фактический объем —> <PDT A=”PDT20” Byproduct 20” D=”VPN1” E=”0048” F=”1’7>

  • < 1— Определение твердого продукта 24, QuantityDDI 004B16 (75) = Фактическая масса —> <PDT A=”PDT24” Byproduct 24” D=”VPN2” E=”004B” F=”1’7>

  • < !— Определите жидкую смесь 12, QuantityDDI 004816 (72) = Фактический объем —> <PDT A=”PDT250” B=”mixture 12” D=”VPN1” E=”0048” F=”2” G=”100000”>

  • < 1— Чтобы получить 100 л смеси 12, нужно: —>

  • < !— 80 л продукта 10 —>

<PRN A=”PDT10” В=”80000”/>

  • < !— 20 л продукта 20 —>

<PRN A=”PDT20” В=”20000”/>

  • < !— 0,5 кг продукта 24, который распадается полностью е 100 л смеси —> <PRN A=”PDT24” В=”500’7>

</PDT>

Если е ходе выполнения задания было применено в общей сложности 7600 л смеси 12 и FMIS нуждается в количествах ингредиентов смеси продуктов 10, 20 и 24, то FMIS вычисляет их следующим образом:

f = 7600 л /100 л = 76 И Общее количество нанесенного соответствует 76-кратному рецепту.

Общий объем, примененный продукта 10, является f * PRN.B = 76* 80 000 мл = 6 080 000 мл = 6 080 л Общий объем, примененный продукта 20, является f * PRN.B = 76* 20 000 мл = 1 520 000 мл = 1 520 л Общая масса, примененная продукта 24, является f * PRN.B = 76 * 500 мг = 38 000 мг = 38 кг Пример 4. Определение состава смеси продуктов с двумя компонентами: одним жидким (количество измеряется как объем) и одним твердым (количество измеряется как масса). В этом случае сухой химикат слегка прибавляет к объему получившейся жидкости.

  • <! — Жидкое определение продукта смеси —>

<VPN A=”VPN1” В =”0” С =”0.001” D =”3” Е =”!”/>

<VPN A=”VPN2” В =”0” С =”0.001” D =”3” Е =”кг”/>

  • <! — Определяют воду (жидкость), QuantityDDI 004816 (72) = Фактический VolumeContent —> <PDT A=”PDT60” В =”eoda”D =”VPN1” E =”0048” F =”1’7>

<! — Определяют твердый продукт 70, QuantityDDI 004B16 (75) = Фактическое массовое содержание —> <PDTA=” PDT70” В =” продукт 70” D =” VPN2” Е =” 004В” F =" 1”/>

<! — Определяют жидкую смесь, QuantityDDI 004816 (72) = Фактическое содержание объема —> <PDTA=”PDT251” В =”смесь 13” D =” VPN1” Е =”0048” F =”2” G =”500000”>

  • < ! — Чтобы получить 500 л смеси 13, каждому нужно: —>

  • < ! — 498 л воды —>

<PRN A=”PDT60” В =” 498000’7>

  • < ! — 22,5 кг продукта 70, который увеличивает объем на 2 л —>

<PRN A=”PDT70” В =”22500”/>

</PDT>

Если во время выполнения задания было применено в общей сложности 18200 л смеси 13 и FMIS нуждается в количествах ингредиентов смеси воды (PDT60) и сухого химического продукта 70 (PDT70), FMIS вычисляет их следующим образом:

f= 18 200 л / 500 л = 36,4 // Общее количество применяемого препарата соответствует 36,4-кратному рецепту.

Общий объем, примененный PDT60 (вода), является f * PRN.B = 36,4 * 498 000 мл = 18 127 200 мл = 18 127 л Общая масса, примененная PDT70 (продукт 70), является f * PRN.B = 36,4 * 22 500 мг = 819 ООО мг = 819 кг Пример 5. Определение смеси продуктов с тремя компонентами, одним жидким (количество измеряется как объем) и двумя твердыми (количество измеряется как масса), результирующая плотность смеси продуктов указывается в качестве необязательного атрибута.

  • <! — Основательное определение продукта смеси —>

<VPN A=”VPN1" В=”0” С=”0.001” D =”0” Е=’Т7>

<VPNA=”VPN2” В=”0” С=”0.001” D =”0” Е=”кг”/>

  • <1— Определяют жидкий продукт 10, QuantityDDI 004816 (72) = Фактический VolumeContent—> <PDTA=”PDT10” В =” продукт 10” D =”VPN1” Е =”0048” F =” 1” Н =”910000’7>

<! — Определяют твердый продукт 23, QuantityDDI 004В16 (75) = Фактическое массовое содержание —> <PDT =”PDT23” В=" продукт 23” D =”VPN2” Е =”004В” F=”1”/>

<! — Определяют твердый продукт 24, QuantityDDI 004В16 (75) = Фактическое массовое содержание —> <PDTA=”PDT24” В=”продукт 24” D =”VPN2” Е =”004В” F=”1’7>

<1 — Определяют твердую смесь 7, QuantityDDI 004В16 (75) = Фактическое массовое содержание —>

<PDTA=”PDT275” В=”смесь 7” D =”VPN2” Е =”004В” F=”2” G=”375000” Н=”990000”>

<! — Чтобы получить 375 кг смеси 7, каждому нужно: —>

<! — 250 кг продукта 23 —>

<PRN A=”PDT23” В=”250000’7>

<! — 120 кг продукта 24 —>

<PRN A=”PDT24” В=”120000’7>

<! — 5,5 л продукта 10 —>

<PRN A=”PDT10” В=”5500”/>

<! — 5,5 л продукта 10 добавляют 5 кг массы к смеси. —>

<! — Плотность жидкого продукта 10 составляет 0,91 кг/л. Так как информация —>

<! — о плотности не требуется, оператор или FMIS должны —>

<!— правильно рассчитать MixtureQuantity и MixtureDensity—> </PDT>

Если в ходе выполнения задания было применено в общей сложности 12 562,5 кг смеси 7 и FMIS нуждается в количествах ингредиентов смеси продуктов 23, 24 и 10, FMIS вычисляет их следующим образом:

f = 12 562,5 кг / 375 кг = 33.5 // Общее количество применяемого препарата соответствует 33,5-кратному рецепту.

Общая масса, примененная продукта 23, является f * PRN.B = 33.5* 250 000 мг = 8 375 000 мг = 8 375 кг

Общая масса, примененная продукта 24, является f * PRN.B = 33.5 *120 000 мг= 4 020 000 мг= 4 020 кг Общий объем, примененный продукта 10, является f * PRN.B = 33.5 * 5 500 мл = 184 250 мл = 184,25 л Пример 6. Атрибут плотности продукта используется для преобразования между заданной единицей задания и измерительной единицей устройства (например, заданное значение массы/площади в объемную измерительную единицу или объем/площадь в измерительную единицу на основе давления).

<VPNA=”VPN1” В=”0” С=”0.001” D=”0” Е=”1’7>

<1— Определяют жидкий продукт 10, QuantityDDI 004816 (72) = Фактический VolumeContent—>

  • <! — Плотность продукта составляет 0,91 кг/л —>

<PDTA=”PDT10” В=” продукт 10” D =”VPN1” Е=”0048” F=”1” Н=”910000”/>

  • <1 — Устройство принимает основанный на объеме уровень заданного значения и команду комплекта плотности —>

<DVC A=”DVC1” В =”Распылитель” С=”1.0” D=”A00C84000B20408B” F=”30353035344042” G =”FF000000006C6E”>

<DETA=”DET1”B =”1” C =”1” D=”ece элементы” E=”0” F =”0”>

<DOR =”3”/>

</DET>

<DET A=”DET2” В =” 2” C =” 3” D=” основной корпус” E =” 1” F=”1”>

<DORA=”3”/>

<DORA=”4”/>

<DORA=”5”/>

<DORA=”6’7>

<DORA=”7’7>

<DORA=”8’7>

</DET>

<DPD А=”3” B="008D" С ="1" D =”9” Е=”Переключатель работы”/>

<DPD А=”4” В=”009Е” С ="2" D =”8" Е=”Состояние управления дифференцированным внесением’7>

<DPD А=”5” В="0043" С ="1" D =”9” Е=”Текущая ширина рабочей зоны’7>

<DPD А~"6” В="0001" С =”2” D =”8” Е=”3аданный расход’7>

<DPD А-"7" В=’’0002" С =”1” D ="Г’ Е=”Текущий расход’7>

<DPD А=”8” В=”0079” С -"2" D =”8" Е=”Плотность продукт а ”/>

</DVC>

  • <! — Задача с продуктом с определением плотности продукта —>

<TSKA=”TSK1” G=”1” Н="1”>

<TZNA=”1" В=”Уровень по умолчанию" С-"2">

<PDVA="0001" В="15000" C-"PDT10" D=”DET2”/>

</TZN>

</TSK>

D.43 ProductAllocation — PAN

Тип:

Данные задачи

Описание:

XML-элемент ProductAllocation определяет распределение отдельного продукта для задачи. ProductAllocation не обязательно связано с DeviceElement. Это необходимо для того, чтобы иметь возможность отслеживать назначение одного продукта или нескольких различных продуктов в бункере или к другому типу DeviceElement. Передаваемое количество может быть дополнительно задано комбинацией атрибутов QuantityDDI и QuantityValue. Следующие DDI должны использоваться для QuantityDDI:

72 Фактическое объемное содержание (мл)

75 Фактическое массовое содержание (г)

78 Фактическое содержание подсчета (количество)

Если для определения распределения продукта используются итоговые значения, то ТС должен рассчитать правильные значения для фактического количества заполнения, разгрузки и остатков. Типы ProductAllocation «за-поление» и «разгрузка» используют перенесенные количества (количество, поступающее в бункер или выходящее из него), тип ProductAllocation «остаток» использует абсолютное количество (количество в бункере).

Включает XML-элемент:

—Allocationstamp

Включен XML-элементом:

— Task

Ссылается на XML-элементы:

— DeviceElement

— ValuePresentation

— Product

Таблица D.43 — Атрибуты ProductAllocation

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

ProductldRef

A

r

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент Product. Формат: (PDT|PDT-) ([0—9]) +

QuantityDDI

В

0

xs:hexBinary

От 000016 до FFFF16

Уникальное число, определяющее количество (указано в ИСО 11783-11)

QuantityValue

C

0

xs:long

От Одо (2J1-1)

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

TransferMode

D

0

xs:NMTOKEN

От 1 до 3

Тип передачи: 1 = Заполнение.

  • 2 = Разгрузка.

  • 3 = Остаток3

Окончание таблицы D.43

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

DeviceElementldRef

Е

0

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент DeviceElement.

Формат: (DET|DET-) ([0—9]) +

ValuePresentationldRef

F

о

xs:IDREF

От миним. 4 до макс. 14

Ссылка на ValuePresentation.

Формат: (VPN|VPN-) ([0—9]) +

Allocationstamp

о

xs:element

Включает один XML-элемент Allocationstamp

а Этот токен представлен в версии 4 стандарта ИСО 11783-10.

Пример 1. Основанное на массе распределения продукта.

<PANA=”PDT2” В="004В" С="20000" D=”1” E=”DET3” F=”VPN1”>

<ASP А=”2003-11-12Т08:00:00” D=”4’7>

</PAN>

<PDT A=”PDT2” В=”Агент”/>

<VPN A=”VPN1” B="0.001" C="1.0” D="0” Е="кг’7>

Пример 2. Смесь продуктов на жидкой основе.

<PDT A=”PDT250” B="liquid_mix_12" D="VPN1" E=”0048” F=”2” G="505">

<PRN A="PDT1" B="400’7>

<PRN A=”PDT2" B="100"/>

<PRN A=”PDT24” B=”5’7>

</PDT>

Пример 3. Полный цикл задач.

<TSKA-"TSK11" В=”пример заполнения" D="FRM1" E=”PFD1” G="1" H-"1" F=”WKR1”>

<!— Планирование —>

<PAN A=”PDT250” B="0048" C-"50000" D="1" E=”DET3” F=”VPN1”>

<ASP A="2010-02-05T13:00:00" D="1"/>

</PAN>

<!— На старте задания бак не пуст —>

<PAN A=”PDT250” В="0048" С-"2000" D=”3” E=”DET3” F="VPN1 ">

<ASP A=”2010-02-05T13:38:00” D=”4’7>

</PAN>

<!— Заполнение —>

<PAN A=”PDT250” B="0048" C-"50000" D-"1" E="DET3" F="VPN1">

<ASP A-"2010-02-05T13:40:00" D="4"/>

</PAN>

<!— Остаток в баке —>

<PAN A=”PDT250” B=”0048" C="10000" D-"3" E="DET3" F="VPN1">

<ASP A="2010-02-05T18:50:00" D="4’7>

</PAN>

<!— Пополнение —>

<PAN A=”PDT250” B="0048" C-"50000" D-"1" E="DET3" F="VPN1">

<ASP A="2010-02-05T19:00:00" D="4’7>

</PAN>

<!— Оставшаяся часть бака для смены продукта —>

<PAN A=”PDT250” В=”0048" С-"0" D-"3" E="DET3" F="VPN1">

<ASP B="2010-02-05T20:40:00" D-"1"/>

</PAN>

<!— Наполнение нового продукта —>

<PAN A=”PDT258” B="0048" C-"30000" D-"1" E=”DET3” F="VPN1">

<ASPA="2010-02-05T21:00:00"D="4’7>

</PAN>

</TSK>

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

Если при запуске задачи нет PAN типа 3 (остаток), то FMIS принимает остаток 0. Это также относится к концу задачи. Без финишного PAN-элемента типа 3 (остаток) бак считается пустым.

Расчет количества продукта в приведенном выше примере:

13:00 Задача запланирована с общим объемом 50 л PDT250, который будет заполнен в DET3.

13:38 При запуске задания в баке остается 2 л PDT250.

13:40 Бак заполнен. Теперь в баке находится 50 л PDT250 (—>водитель залил 48 л).

18:50 Остаток 10 л находится в баке (до сих пор применялось—» 50 л - 10 л = 40 л)

19:00 Заправьте в общей сложности 50 л PDT 250 (= водитель заправил 40 л).

20:40 Бак пуст (остаток от 0). Всего к настоящему времени было применено 40 л + 50 л = 90 л ФДТ250.

21:00 Бак заполнен 30 л PDT258.

??.?? Задача завершена (время должно быть взято из отношения времени задачи). Поскольку не существует конечного PAN элемента типа 3 (остаток), FMIS предполагает, что резервуар пуст. Поэтому в задании было применено 30 л PDT258.

Так в задаче DET3 применено 90 л PDT250 и 30 л PDT258. Итого в элементе TIM будет указано 120 I: < TIM ... > < DLV А = “0080” В = “120” С = “DET3” / > < / TIM >

D.44 ProductGroup — PGP

Тип:

Данные кодирования

Описание:

XML-элемент ProductGroup используется для группировки продуктов или продукции и посадочного материала различных сортов сельскохозяйственных культур. Продукты могут быть назначены Task во время выполнения Task путем добавления элемента ProductAllocation к Task. С помощью этого метода все изменения в распределении продуктов или в спецификации сортов сельскохозяйственных культур, которые обрабатываются, могут быть записаны во время выполнения Task.

Чтобы определить, какие продукты, продукция или посадочный материал сортов сельскохозяйственных культур относятся к ProductGroupIdRef (определенной группе продуктов или типу культур), значения всех продуктов должны быть проверены на соответствие определенному значению ProductGroupId. Аналогично, чтобы определить, какие сорта культур принадлежат к определенному типу культур, значения ProductGroupIdRef всех продуктов, соответствующих группе продуктов типа СгорТуре, определяют набор сортов культур, принадлежащих к определенному типу культур. В XML-элементах СгорТуре и CropVariety ссылки могут быть включены в ProductGroup и Product для перекрестной ссылки на СгорТуре и CropVariety, указанные для Partfield, с товаром, указанным в Product и ProductGroup.

Атрибут ProductGroupType используется для различения продуктов (например, химических средств защиты растений) и сельскохозяйственных культур (например, сортов сельскохозяйственных культур, выращиваемых на части поля). Если атрибут ProductGroupType не задан, то типом по умолчанию будет ProductGroup.

Указан XML-элементами:

—Product

Таблица D.44 — Атрибуты ProductGroup

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

ProductGroupId

А

г

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор ProductGroup.

Формат: (PGPIPGP-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

ProductGroupDesignator

В

г

xs:string

Макс. 32

ProductGroup обозначение/имя

ProductGroupType3

С

о

xs:NMTOKEN

От 1 до 2

Тип ProductGroup:

  • 1 = ProductGroup (значение по умолчанию) содержит продукты.

  • 2 = СгорТуре содержит варианты сорта сельскохозяйственных культур

а Этот атрибут представлен в версии 4 стандарта ИСО 11783-10.

ПРИМЕР.

<PGPA=”PGP1” В=’Тербициды”/>

<PDTA=”PDT1” В="Агент 1” C="PGPV’/>

<PGPA=”PGP2” В=”Картофель” С=”2”/>

<PDTA=”PDT1” В=”Астерикс (Звездочка)” C-”PGP2”/>

D.45 ProductRelation — PRN

Тип:

Данные кодирования

Описание:

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

Продукты, указанные элементом PRN, должны содержать величины для атрибутов QuantityDDI и MixtureQuantity, чтобы обеспечить вычисление и обработку частей продуктовой смеси всех компонентов.

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

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

Комбинированное внесение удобрений, которые объединяют N-P-K-S и любые другие минеральные вещества в гранулах, рассматриваются как единый продукт. Собранный на ферме из однокомпонентных удобрений продукт рассматривается как смесь по сравнению с отдельными продуктами.

XML-элемент ProductRelation добавлен в версии 4 стандарта ИСО 11783-10.

Ссылается на XML-элементы:

— Product

Включен XML-элементом:

— Product

Таблица D.45 — Атрибуты ProductRelation

Атрибут

XML

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

Тип

Длина/диапазон

Комментарий

ProductldRef

А

г

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент Product. Формат: (PDT|PDT-) ([0—9]) +

QuantityValue

В

г

xs:long

От 0 до (231 - 1)

Содержит часть смеси

ПРИМЕР.

<PDT A=”PDT250” B=”liquid_mixJ2” D=”VPN1” E=”0048” F=”2” G -”505">

<PRN A=”PDT1” B=”400'7>

<PRN A=”PDT2” B=’’100’7>

<PRN A-”PDT24” B=”5’7>

</PDT>

D.46 Task — TSK

Тип:

Данные задачи

Описание:

XML-элемент Task описывает задачу ИСО 11783. Задача центрального XML-элемента в наборе файлов передачи данных. Задача содержит ссылки на различные другие XML-элементы, чтобы указать и записать распределенные ресурсы и операции.

Указывая XML-атрибуты CustomerldRef, FarmldRef и PartfieldldRef в задаче, можно создать дублирующие связи между задачей, потребителем, фермой и деталями поля. Это дублирование разрешено и не должно приводить к конфликтам в отношениях между этими XML-элементами.

XML-атрибут ResponsibleWorkerldRef является ссылкой на единственного рабочего, ответственного за эту задачу. Это может, например, быть рабочий, который указал эту задачу или рабочего, с которым можно связаться, чтобы обеспечить дополнительные сведения об этой задаче. Запись, например, времени начала и продолжительности одного или нескольких рабочих, способствующих выполнению задачи, должна быть сделана при помощи XML-элемента WorkerAIlocation в задаче. Несколько XML-элементов WorkerAllocation могут быть указаны в единственной задаче.

У XML-атрибута TaskStatus есть величины 1—4 и 6 для определения жизненного цикла Task. В дополнение к этим 5 состояниям TaskStatus может быть указан как «шаблон» (значение 5). При запуске Task со статусом «шаблон» должна быть создана и запущена новая Task, которая является копией шаблонаТаэк.

По крайней мере один элемент Time должен быть добавлен к Task после того, как он был запущен MICS, и информация времени присутствует в сети ИСО 11783.

Ссылается на XML-элементы:

  • — Customer

  • — Farm

  • — Partfield

  • — (Responsible) Worker

  • — (Default and PositionLost) Treatmentzones

Включает XML-элемент:

  • — Treatmentzone

  • — Time

  • — OperTechPractice

  • — WorkerAllocation

  • — DeviceAllocation

  • — Connection

  • — ProductAllocation

  • — DataLogTrigger

  • — CommentAllocation

  • — Grid

  • — TimeLog

  • — ControlAssignment

  • — GuidanceAllocation

Таблица D.46 — Атрибуты задачи

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Taskld

A

r

xs:ID

От миним. 4 до макс. 14

Уникальный идентификатор задачи.

Формат: (TSK|TSK-) ([0—9]) +.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

TaskDesignator

В

0

xs:string

Макс. 32

Обозначение/имя задачи

CustomerldRef

C

0

xs:IDREF

От миним. 4

до макс. 14

Ссылка на XML-элемент Customer.

Формат: (CTR|CTR-) ([0—9]) +

FarmldRef

D

0

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент Farm.

Формат: (FRM|FRM-) ([0—9]) +

PartfieldldRef

E

0

xs:IDREF

минута 4 / максимум 14

Ссылка на XML-элемент Partfield.

Формат: (PFD|PFD-) ([0—9]) +

ResponsibleWorkerldRef

F

0

xs:IDREF

От миним. 4 до макс. 14

Ссылка на XML-элемент

Worker.

Формат: (WKR|WKR-) ([0—9]) +

TaskStatus

G

r

xs:NMTOKEN

1—6

Состояние задачи, возможные значения:

  • 1 = Запланирована.

  • 2 = Выполняется.

  • 3 = Приостановлена.

  • 4 = Завершена.

  • 5 = Шаблон3.

  • 6 = Отменена3

DefaultTreatmentZoneCode

H

0

xs:unsignedByte

от 0 до 254

Ссылка на XML-элемент Treatmentzone

PositionLostTreatmentZone Code

I

0

xs:unsignedByte

от 0 до 254

Ссылка на XML-элемент Treatmentzone

OutOfFieldTreatmentZone Code

J

0

xs:unsignedByte

от 0 до 254

Ссылка на XML-элемент Treatmentzone

Окончание таблицы D.46

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Treatmentzone

о

xs:element

Включает список XML-элемента Treatmentzone

Time

о

xs:element

Включает список XML-

элемента Time

OperTechPractice

о

xs:element

Включает один XML-элемент OperTechPractice

WorkerAllocation

о

xs:element

Включает список XML-элемента WorkerAllocation

DeviceAllocation

о

xs:element

Включает список XML-элемента DeviceAllocation

Connection

о

xs:element

Включает список XML-элемента Connection

ProductAllocation

о

xs:element

Включает список XML-элемента ProductAllocation

DataLogTrigger

о

xs:element

Включает список XML-элемента DataLogTrigger

CommentAllocation

о

xs:element

Включает список XML-элемента CommentAllocation

TimeLog

о

xs:element

Включает список XML-элемента TimeLog

Grid

о

xs:element

Включает один XML-элемент Grid

ControlAssignmenta

О

xs:element

Включает список XML-элемента ControlAssignment

GuidanceAllocationa

О

xs:element

Включает список XML-элемента GuidanceAllocation

a Это определение представлено в версии 4 стандарта ИСО 11783-10.

ПРИМЕР.

<TSK A=”TSK1 ” F=” WKR1” G=”1 ”>

<OTPA~" CPC1” B=”OTQ1’7>

<WAN A=”WKR1 ”>

<ASP A=”2003-08-20T08:00:00” B=”2003-08-20T17:00:00” D=”1 ”/>

</WAN>

< DAN B=”7FFFFFFF00000000”=”200C840000000000”>

<ASP A=”2003-08-20T08:00:00” B=”2003-08-20T17:00:00” D=”1 ”/>

</DAN>

<CNNA-”DVC2” B=”DET2” C =”DVC1” D =”DET2’7>

<DLTA-”1122” B-” 1" H=”DET2”/>

<CAN A=”CCT5”>

<ASP A=”2003-08-20T08:00:20” D-”4”/>

</CAN>

<TZN A=”1” B=” 200” C=”140”/>

<TIM A=”2003-08-20T08:00:00” B=”2003-08-20T17:00:00” D-”1”/>

</TSK>

D.47 TaskControllerCapabilities — TCC

XML-элемент TaskControllerCapabilities содержит версию применения и возможности контроллера задач, который генерировал набор файла передачи данных. Этот XML-элемент должен быть включен только в набор файлов передачи данных, только в том случае, если источником передачи данных является MICS, и в этом случае в набор файлов передачи данных должен быть включен как минимум один XML-элемент TaskControllerCapabilities.

XML-элемент TaskControllerCapabilities добавлен в версии 4 стандарта ИСО 11783-10.

Включен XML-элементом:

— ISO11783_TaskData

Таблица D.47 — Атрибуты TaskControllerCapabilities

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

NAME

TaskControllerControl

Function

A

r

xs:hexBinary

От 000000000 000000016 до FFFFFFFFF FFFFFFF1fi 1 о

NAME диспетчера задачи (см. ИСО 117835)

TaskControllerDesignator

В

r

xs:string

He более 153 символов

Название продукта, указанное производителем. Содержит название продукта, указанное в группе параметра Идентификационной информации продукта и определенное в ИСО 11783-12

VersionNumber

C

r

xs:NMTOKEN

От 0 до 4

Версия ИСО 11783-10, которой соответствует данный контроллер задачи:

0 = Версия DIS (проект Международного стандарта).

  • 1 = Версия FDIS.1 (заключительный проект Международного стандарта, первое издание).

  • 2 = Версия FDIS.2 и первое издание, опубликованное как Международный стандарт.

  • 3 = Версия второго издания, опубликованного как проект Международного стандарта (Е2. DIS).

  • 4 = Версия второго издания, опубликованного как заключительный проект Международного стандарта (Е2. FDIS)

ProvidedCapabilities

D

r

xs:unsignedByte

От 0 до 63

Поддерживаемые возможности: 1 = Поддерживает документацию. 2 = Поддерживает ТС-GEO без управления по положению.

4 = Поддерживает ТС-GEO с управлением по положению.

8 = Поддерживает назначение одноуровневого управления.

16 = Поддерживает управление секциями агрегата.

32 = Поддерживает полигон карт дифференцированного внесения

NumberOfBoomsSection

Control

E

r

xs:unsignedByte

От 0 до 254

Задает максимальное количество штанг, поддерживаемое контроллером задач для управления секциями, или 0, если управление секциями не поддерживается

NumberOfSectionsSection

Control

F

r

xs:unsignedByte

От 0 до 254

Задает максимальное количество секций, поддерживаемых контроллером задач для управления секциями, или 0, если управление секциями не поддерживается

NumberOfControlChannels

G

r

xs:unsignedByte

От 0 до 254

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

D.48 Time —TIM

Тип:

Данные задачи

Описание:

XML-элемент Time (время) указывает запись события времени. Дополнительно позиция может быть зарегистрирована с указанием времени. Атрибут типа используется, чтобы указать, какое Time указано или зарегистрировано. Все XML-элементы Time, которые обеспечены FMIS, должны иметь запланированный тип. Если MICS не обеспечат подробное различие записи времени при помощи всех типов 2 (Предварительно) перед типами 8 (Выключено), то далее все XML-элементы Time, которые обеспечены MICS, должны относиться к типу 4 (Эффективно). В этом случае сумма этого зарегистрированного эффективного времени составляет общее рабочее время и не может быть разбита на более подробные типы времени. См. приложение G для описания более подробных типов времени.

XML-элемент Time с Типом 1 (Запланированный) используется, чтобы указать запланированный запуск и остановку или продолжительность Task, в которую на этот раз включен XML-элемент. Использование данного значения типа (Туре) предназначено только для планирования Task и составления расписаний. В каждую задачу может быть включен максимум один XML-элемент Time запланированной задачи.

XML-элемент Time с Туре 8 (Выключено) используется, чтобы записать время выключения машины, частью которой является ТС.

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

В версии 4 стандарта ИСО 11783-10 тип данных дата и время был расширен, чтобы включать информацию о часовом поясе или быть явно установленным значением в UTC. Когда часовой пояс известен, необходимо либо указать время в формате UTC, добавив индикатор «Z», либо включить смещение часового пояса в атрибуты Запуск и Остановка. Явное использование UTC или информации о часовом поясе, когда FMIS использует местное время для нормализации данных, поступающих из нескольких часовых поясов. Если информация о часовом поясе неизвестна, все время выражается в местном времени без информации о часовом поясе.

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

Включен XML-элементом:

— Task

— TimeLog

Включает XML-элемент:

— Position

— DataLogValue

Таблица D.48 — Атрибуты Time

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Start

A

r

xs:datetime

Макс. 29

Время начала. Формат: yyyy-mm-ddThh:mm:ss. sss плюс дополнительная индикация часового поясаа

Stop

В

0

xs:datetime

Макс. 29

Время конца. Формат: yyyy-mm-ddThh:mm:ss. sss плюс дополнительная индикация часового пояса3

Duration

C

0

xs:unsignedLong

От 0 до (232-2)

Время между началом и концом в секундах

Type

D

r

xs:NMTOKEN

От 1 до 2, от

4 до 8

Тип указанного времени или тип зарегистрированного времени, возможные значения:

  • 1 = Запланировано.

  • 2 = Предварительно.

  • 4 = Эффективно.

  • 5 = Неэффективно.

  • 6 = Ремонт.

  • 7 = Очистка.

  • 8 = Выключено01

Окончание таблицы D.48

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Position

о

xs:element

Включает до 2 XML-элементов Position, которые представляют позицию при значениях атрибутов начала и конца элемента Time

DataLogValue

о

xs:element

Включает список XML-элемента DataLogValue

а Информация о часовом поясе введена в 4 версии ИСО 11783-10.

ь Для создания конечного XML-элемента Time в дополнение к Start должен быть указан либо Stop, либо Duration.

с Значение 3 (Подготовка) было исключено в 4 версии ИСО 11783-10. Это значение не давало данных в дополнение к значению 2 (Предварительно) времени.

d Этот параметр введен в 4 версии ИСО 11783-10.

ПРИМЕР 1 Информация о часовом поясе не доступна, время регистрируется местное

<Т1М А=”2003-08-20Т08:10:00” В=”2003-08-20Т12:04:23” D=”4”>

<PTN А=”54.588945” В=”9.989209” D=”3’7>

<DLVA=”0815” В=”10” C=”DET1”/>

<DLVA=”4711” В=”15” C=”DET2”/>

</TIM>

<TIM A=”2003-08-20T08:10:00” C="3612” D=”6”/>

ПРИМЕР 2 Информация о часовом поясе доступна в системе, но время явно регистрируется только в UTC

<TIM A=”2003-08-20T07:10:00Z” С=”3612” D=”6”/>

ПРИМЕР 3 Информация о часовом поясе доступна, время регистрируется местное с информацией о часовом поясе; например, для центральноевропейского времени время начала для того же момента времени, как в примере 2, будет

<Т1М А=”2003-08-20Т08:10:00+01:00” С=”3612” D=”6’7>

или для местоположения в часовом поясе 0 этот же момент времени будет

<Т1М А=”2003-08-20Т07:10:00+00:00” С-”3812" D=”6”/>

D.49 TimeLog — TLG

Тип:

Данные задачи

Описание:

XML-элементы Time используются в качестве встроенных списков внутри набора файлов для передачи XML-данных или в качестве спецификации шаблона времени в XML-элементе TimeLog. TimeLog активирует сбор всех значений DataLogValue в файле журнала двоично-кодированных данных. В XML-элементе TimeLog значение атрибута TimeType XML-элемента Time должно быть установлено равным 4 (Эффективно). Атрибут TimeLogType установлен для обеспечения будущего расширения метода регистрации данных. Значение атрибута TimeLogType должно быть установлено равным «1» для текущего метода регистрации данных, указанного в пунктах 6.8.2 и 6.8.4.

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

Включен XML-элементом:

— Task

Таблица D.49 — Атрибуты TimeLog

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Filename

A

г

xs:ID

8

Уникальное имя файла TimeLog Формат: TLG [0—9] [0—9] [0—9] [0—9] [0-9]

Filelength

В

о

xs:unsignedLong

От 0 до (232-2)

Длина файла TimeLog в байтах

TimeLogType

С

г

xs:NMTOKEN

1

1 = Двоичный файл журнала времени типа 1

ПРИМЕР. TimeLog в наборе файлов передачи данных <TLG A=”TLG00001” С-”1”/>

XML-файл TimeLog TL.G00001.xml выглядит следующим образом:

<TIM A-"" D=”4”>

<PTN А-”" В=”” D=”’7>

<DLVА=”0002” В=”” C=”DET1”/>

<DLVA=”0007” В=”” C=”DET2”/>

</TIM>

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

(TimeStart, PositionNorth, PositionEast, Positionstatus, #DLV, DLVO, PDVO, DLV1, PDV1)

Что будут представлять следующие значения в двоичном формате:

(2005—05—02Т16:32:00, 51.00678, 6.03489, 1, 2, 0, 10, 1, 15)

D.50 Treatmentzone — TZN

Тип:

Данные задачи

Описание:

Treatmentzone (Зона обработки) описывает область, которая должна быть обработана теми же DDI данных процесса и теми же значениями.

Внутри задачи можно ссылаться на зоны обработки. Элемент DefaultTreatmentZone (зона обработки по умолчанию) имеет особое значение относительно включенных переменных ProcessDataVariable. Значения тех ProcessDataVariable должны быть применены глобально к целой задаче. Все значения переменных ProcessDataVariable в элементе DefaultTreatmentZone отправляются контроллером задач ТС всем соответствующим клиентам при запуске и возобновлении задачи. DefaultTreatmentZone может существовать для не привязанных к месту задач. Не привязанные к месту задачи — это задачи без каких-либо привязанных полигонов или сетки. Элемент PositionLostTreatmentZone (зона обработки при потерянной позиции) содержит переменные ProcessDataVariable, которые должны быть отправлены клиентам, когда позиционирование становится недоступным. Элемент OutOfFieldTreatmentZone (зона обработки вне поля) содержит переменные ProcessDataVariable, которые должны быть отправлены соответствующим элементам устройств клиентов, когда клиенты или их часть покидают область, ограниченную полигоном границы поля. Спецификация элементов PositionLostTreatmentZone и OutOfFieldTreatmentZone предназначена для привязанных к месту задач.

До 4 версии ИСО стандарта 11783-10 в элемент Treatmentzone мог быть включен лишь один Полигон для определения ее геометрии. Начиная с 4 версии в Treatmentzone может быть включен список Полигонов, и каждый Полигон ограничен для описания одной-единственной поверхности.

Если геометрия Treatmentzone определена одним или более полигонами, то должна быть включена лишь единственная переменная ProcessDataVariable XML-элемента. Это изменение для зон обработки, ограниченных полигонами, со списка на единственную переменную ProcessDataVariable XML-элемента было введено в 4 версии стандарта ИСО 11783-10. Зоны обработки Treatmentzone без определения геометрии, например, как указано в атрибутах Grid или Task, могут включать список переменных ProcessDataVariable XML-элемента.

Указан XML-элементами:

— Grid

Включен XML-элементами:

— Task

Включает XML-элементы:

— ProcessData Variable

— Polygon (только для типа Treatmentzone)

Таблица D.50 — Атрибуты Treatmentzone

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Т reatmentZoneCode

A

r

xs:unsignedByte

От 0 до 254

Уникальный код TreatmentZone-Code внутри задачи

TreatmentZoneDesignator

В

0

xs:string

макс. 32

Название Treatmentzone

TreatmentZoneColour

C

0

xs:unsignedByte

От 0 до 254

Цвет зоны обработки Treatment-Zone.

Формат: палитра ИСО 11783-6

Polygon

0

xs:element

Включает список3 Полигонов XML-элемента

Окончание таблицы D.50

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

ProcessDataVariable

0

xs:element

Включает единственную или список переменных ProcessDataVariable XML-элемента

a Кратность включения этого атрибута была изменена в 4 версии ИСО 11783-10.

Пример 1 Treatmentzone с несколькими переменными ProcessDataVariable

<TZN А=”6” B=”MidRate 1” С-”2”>

<PDVA=”0001” В=”100’7>

<PDVА=”0006” В=”1200”/>

</TZN>

Пример 2 XML-кодироеание привязанного к месту внесения на основе полигона (см. рисунок 5)

<PDT A=”PDT1” В=”Гранулированное удобрен и е”/>

<PDT A=”PDT2” В=”Подсолнечник’7>

<VPN A~”VPN1” В="0” С=”0.01 ” D=”0” Е=”кг/га7>

<TSK A~”TSK1" G-”1” H=”0”>

<TZN A="1 ” B=”Layer 1, Treatmentzone Г’С=’Ч02”>

<PDVA=”0006” B=”5800” C=”PDTT E=”VPN1” F=”1”/>

<PLN A=”2” B=”Polygon 1”>

<LSG A-”1” В=”внешняя граница”>

<PNT A=”2” C=”38.13336” D=”-97.41707’7>

<PNT A=”2” C=”38.13322" D=”-97.41675”/>

<PNT A-”2” C=”38.13319" D=”-97.41675’7>

<PNT A=”2” C=”38.13318" D=”-97.41683’7>

<PNT A=”2” C=”38.13318" D=”-97.41890”/>

<PNT A=”2” C=”38.1332”

<PNT A-”2” C=”38.13323" D=”-97.41707’7>

<PNT A=”2” C=”38.13336" D=”-97.41707’7>

</LSG>

</PLN>

<PLN A=”2” B=”Polygon 3”>

<LSG A=”1” В=”внешняя граница”>

<PNT A=”2” C=”38.1331” D-"-97.41707"/>

<PNTA=”2” C=”38.13312" D-"-97.41704"/>

<PNTA=”2” C=”38.13312" D=”-97.41702”/>

<PNTA=”2” C=”38.1331” D=”-97.41699’7>

<PNTA=”2” C=”38.13309" D=”-97.41696’7>

<PNTA=”2” C=”38.13309" D=”-97.41694”/>

<PNT A-”2" C=”38.133105” D=”-97.41689’7>

<PNT A=”2” C=”38.13311” D=”-97.41683”/>

<PNTA=”2” C=”38.1331” D=”-97.41675’7>

<PNTA=”2” C=”38.132955” D=”-97.41675’7>

<PNTA-”2” C=”38.13296" D=”-97.41679”/>

<PNTA=”2” C=”38.132955” D=”-97.41683’7>

<PNTA=”2” C=”38.13294" D=”-97.41689”/>

<PNT A-”2” C=”38.132945” D=”-97.41694”/>

<PNTA-”2” C=”38.13295" D=”-97.41696’7>

<PNTA=”2” C=”38.13297” D=”-97.417’7>

<PNTA=”2” C=”38.13297" D=”-97.41703’7>

<PNT A-”2” C=”38.13295" D=”-97.41707’7>

<PNTA-”2” C=”38.1331” D-”-97.41707”/>

</LSG>

<LSG A-”2” В=”внутренняя граница”>

<PNTA=”2” C=”38.133055” D=”-97.41690’7>

<PNTA-”2” C=”38.13306” D=”-97.41688”/>

<PNTA-”2” C=”38.13306” D=”-97.41684’7>

<PNTA=”2” C=”38.13305" D=”-97.41681’7>

<PNT A-”2” C=”38.13304" D=”-97.41680’7>

<PNT А=”2” С=”38.13302” D=”-97.41680”/>

<PNT А=”2” С=”38.13301” D=”-97.41581’7>

<PNT А=”2” С=”38.133” D=”-97.41684’7>

<PNT А=”2” С=”38.132995” D=”-97.41689’7>

<PNT А=”2” C="38.133” D=”-97.41691’7>

<PNT A=”2” C=”38.13301” D=”-97.41692’7>

<PNT A-”2” C=”38.13303” D=”-97.41692’7>

<PNT A=”2” C~”38.13305” D=”-97.41691’7>

<PNT A-"2” C=”38.133055” D=”-97.41690’7>

</LSG>

</PLN>

</TZN>

<TZN A-”2” B=”Layer 1, Treatmentzone 2” C=”1”>

<PDVA-”0006” B-"6500” C=”PDT1” E=”VPN1” F=”1’7>

<PLN A-”2” B=”Polygon 2”>

<LSG A=”1” В=”внешняя граница”>

<PNTA-”2” C=”38.13323” D=”-97.41707’7>

<PNT A=”2” C=”38.1332” D=”-97.417’7>

<PNTA-”2” C=”38.13318” D=”-97.4169’7>

<PNTA-”2” C=”38.13318” D=”-97.41683’7>

<PNTA-”2” C-”38.13319” D=”-97.41675’7>

<PNTA-”2” C=”38.1331” D=”-97.41675”/>

<PNT A~"2” C=”38.13311” D=”-97.41683’7>

<PNT A=”2” C-”38.133105” D=”-97.41689’7>

<PNT A-”2” C=”38.13309” D=”-97.41694’7>

<PNTA-”2” C=”38.13309” D=”-97.41696’7>

<PNTA=”2” C=”38.1331” D=”-97.41699’7>

<PNTA=”2” C=”38.13312” D=”-97.41702’7>

<PNT A-”2” C=”38.13312” D=”-97.41704’7>

<PNTA-”2” C=”38.1331” D-”-97.41707”l>

<PNTA-”2” C=”38.13323” D=”-97.41707’7>

</LSG>

</PLN>

<PLN A-”2” B=”Polygon 4”>

<LSG A=”1” В=”внешняя граница”>

<PNTA-”2” C-”38.133055” D=”-97.41690’7>

<PNTA-”2” C=”38.13306” D=”-97.41688’7>

<PNTA-"2” C=”38.13306” D=”-97.41684”/>

<PNTA-”2” C=”38.13305” D=”-97.41681”/>

<PNT A=”2” C-”38.13304” D-”-97.41580”/>

<PNTA-”2” C-”38.13302” D=”-97.41680”/>

<PNTA-”2” C=”38.13301” D-”-97.41681”/>

<PNTA-”2” C=”38.133” D=”-97.41684’7>

<PNT A=”2” C-”38.132995” D=”-97.41689”/>

<PNT A-”2” C=”38.133” D=”-97.41691”/>

<PNTA-”2” C=”38.13301” D=”-97.41692’7>

<PNTA-”2” C=”38.13303” D=”-97.41692’7>

<PNTA=”2” C-”38.13305” D=”-97.41691’7>

<PNTA=”2” C=”38.133055” D=”-97.41690’7>

</LSG>

</PLN>

</TZN>

<TZN A=”3” B=”Layer 1, Treatmentzone 3” C-”7”>

<PDVA-”0006” B-”5000” C=”PDT1” E=”VPN1” F-”1”/>

<PLN A=”2” B=”Polygon 5”>

<LSG A=”1” В=”енешняя граница”>

<PNT A-”2” C-”38.13295” D="-97.41707’7>

<PNTA-”2” C=”38.13297” D-”-97.41703”/>

<PNT A-"2” C=”38.13297” D=”-97.417”/>

<PNTA-”2” C=”38.13295” D=”-97.41696’7>

<PNT A-”2” C-”38.132945” D=”-97.41694’7>

<PNTA=”2” C=”38.13294” D=”-97.41689’7>

<PNTA-"2" С=”38.132955” D=”-97.41683’7>

<PNT А=”2” С=”38.13296" D="-97.41679"/>

<PNT А=”2" С=”38.132955" D="-97.41675"/>

<PNT А=”2” С=”38.13286” D="-97.41675"/>

<PNT А="2" C="38.13286" D="-97.41707’7>

<PNT A=”2” C="38.13295" D="-97.41707’7>

</LSG>

</PLN>

</TZN>

<TZN A="4" B-"Layer 2, Treatmentzone 4" C-"7"> <PDVA=”0006” B=”800” C=”PDT2” E-"VPN1" F="2"/> <PLN A=”2” B=”Polygon 6">

<LSG A-”1" В=”внешняя граница">

<PNT A=”2” C="38.13336" D="-97.41707’7>

<PNT A~"2" C="38.13325" D="-97.41682’7>

<PNT A=”2” C-”38.13324" D="-97.4169"/>

<PNT A=”2” C="38.13323" D-"-97.41694"/>

<PNT A=”2” C=”38.1332” D-"-97.41697"/>

<PNT A-"2" C="38.13317" D=”-97.416982’7>

<PNT A=”2” C-"38.13312" D="-97.41698"/>

<PNT A-"2" C-"38.133108" D="-97.416985’7>

<PNT A=”2” C="38.1331" D-"-97.417"/>

<PNT A-"2" C="38.13309" D="-97.41707’7>

<PNTA-"2" C="38.13336" D="-97.41707"/>

</LSG>

</PLN>

</TZN>

<TZN A-"5" B=”Layer 2, Treatmentzone 5" C="102"> <PDVA="0006" B-"900" C="PDT2" E="VPN1" F-"2"/> <PLN A="2" B=”Polygon 7">

<LSG A="1" В="енешняя граница">

<PNTA-"2" C="38.13309" D-"-97.41707"/>

<PNTA="2" C="38.1331" D="-97.417"/>

<PNTA=”2” C=”38.133108" D="-97.416985’7>

<PNTA="2" C="38.13312" D="-97.41698’7>

<PNTA="2” C="38.13317" D="-97.416982’7>

<PNT A="2" C="38.1332" D="-97.41697"/>

<PNTA=”2” C-"38.13323" D="-97.41694’7>

<PNTA="2" C="38.13324" D="-97.4169’7>

<PNTA-"2" C-"38.13325" D="-97.41682"/>

<PNT A="2" C-"38.13322" D="-97.41675’7>

<PNT A-"2" C="38.13319" D="-97.41675’7>

<PNTA="2" C="38.13318" D="-97.41679"/>

<PNTA-"2" C="38.13315" D="-97.41685"/>

<PNT A="2" C="38.133095" D="-97.4169"/>

<PNTA=”2” C="38.133055" D="-97.41695’7>

<PNT A-"2" C="38.133025" D="-97.417’7>

<PNTA-"2" C="38.133005" D-"-97.41707"/>

<PNTA="2" C="38.13309" D="-97.41707’7>

</LSG>

</PLN>

<PLN A-"2" B=”Polygon 9">

<LSG A-"1” В="енешняя граница">

<PNTA=”2” C-"38.1329" D-"-97.41707"/>

<PNT A-"2" C-"38.132905" D-"-97.41703"/>

<PNT A-"2” C=”38.13291" D="-97.417"/>

<PNTA=”2” C="38.132925" D="-97.41698’7>

<PNTA=”2” C-"38.13298" D=”-97.41695’7>

<PNT A-"2" C="38.132995" D="-97.41689"/>

<PNTA="2” C="38.133005" D=”-97.41683’7>

<PNTA-"2" C="38.132995" D="-97.41679"/>

<PNTA=”2” C-"38.13297" D="-97.41675’7>

<PNT А=”2” С=”38.13286” D=”-97.41675”/>

<PNT А=”2” С=”38.13286” D-”-97.41707”/>

<PNT А=”2” С=”38.1329” D-”-97.41707”/>

</LSG>

</PLN>

</TZN>

<TZN A-”6” B=”Layer 2, Treatmentzone 6” C=”1”>

<PDVA=”0006” B=”1000” C=”PDT2" E=”VPN1” F=”2’7>

<PLN A=”2” B=”Polygon 8”>

<LSG A=”1” В=”внешняя граница”>

<PNT A=”2” C=”38.133005” D=”-97.41707”/>

<PNT A=”2” C-”38.133025” D=”-97.417’7>

<PNT A-”2” C-"38.133055” D=”-97.41695”/>

<PNTA-”2” C=”38.133095” D=”-97.4169’7>

<PNT A-”2” C=”38.13315” D=”-97.41685”/>

<PNT A~”2” C~”38.13318” D=”-97.41679”/>

<PNTA-”2” C~”38.13319” D-”-97.41675”/>

<PNT A=”2” C=”38.13297” D=”-97.41675’7>

<PNTA-”2” C=”38.132995” D=”-97.41679’7>

<PNTA-”2” C-”38.133005” D=”-97.41683’7>

<PNTA-”2” C-”38.132995” D=”-97.41689’7>

<PNTA-”2” C=”38.13296” D=”-97.41695’7>

<PNTA-”2” C=”38.132925” D=”-97.41698”/>

<PNT A=”2” C=”38.13291” D=”-97.417”/>

<PNT A-”2” C=”38.132905” D-”-97.41703”/>

<PNTA-”2” C=”38.1329” D-”-97.41707”l>

<PNTA=”2” C=”38.133005” D=”-97.41707’7>

</LSG>

</PLN>

</TZN>

</TSK>

D.51 ValuePresentation — VPN

Тип:

Данные кодирования

Описание:

XML-элемент ValuePresentation (Представление значения) используется для задания способа представления целочисленных значений, определенных объектом словаря данных. Представление должно соответствовать следующей формуле:

Представленное значение = (целочисленное значение + Offset) * Scale

Представленные значения всегда округляются до числа десятичных знаков, указанных в атрибуте NumberOfDecimals.

Ссылается на XML-элементы:

  • — ColourLegend

Указан XML-элементами:

  • — DataLogTrigger

  • — ProcessData Variable

  • — Product

  • — ProductAllocation

Таблица D.51 — Атрибуты ValuePresentation

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

ValuePresentationld

A

r

xs:ID

От мин. 4 до макс. 14

Уникальный идентификатор ValuePresentation.

Формат: (VPN|VPN-) ([0—9]) +

Offset

В

r

xs:long

От -231 до (231-1)

Смещение, которое применено к значению для представления

Scale

C

r

xs:decimal

От 0.000000001

до 100000000.0

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

Окончание таблицы D.51

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

NumberOfDecimals

D

r

xs:unsignedByte

От 0 до 7

Число десятичных знаков после десятичного разделителя

UnitDesignator

E

0

xs:string

От мин. 4 до макс. 14

Дополнительная строка обозначения устройства

ColourLegendldRef

F

0

xs:IDREF

От мин. 4 до макс. 14

Ссылка на ColourLegend XML-элемента.

Формат: (CLD|CLD-) ([0—9]) +

Пример.

<VPN A=”VPN1” В=”0” С=”1.0” D=”0” Е=”кг”/>

<VPN A=”VPN2” В=”18” С=”1.8” D=”1” E=”°F’7>

D.52 Worker — WKR

Тип:

Данные кодирования

Описание:

XML-элемент Worker (Работник) описывает работника, с которым может быть связана задача. Распределение всех работников занесено с информацией о времени в набор файлов передачи данных. Атрибут ResponsibleWorkerldRef имеет особое значение для задачи. Этот работник непосредственно связан с задачей без каких-либо дополнительных регистрируемых данных.

Указан XML-элементами:

— Task

— WorkerAllocation

Таблица D.52 — Атрибуты Worker

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Workerld

A

r

xs:ID

От миним. 4

до макс. 14

Уникальный идентификатор работника Формат: (WKR|WKR-)([0—9])+.

Записи, сгенерированные на MICS, имеют отрицательные идентификаторы

WorkerLastName

В

r

xs:string

Макс. 32

Фамилия

WorkerFirstName

C

0

xs:string

Макс. 32

Имя

Workerstreet

D

0

xs: string

Макс. 32

Улица

WorkerPOBox

E

0

xs:string

Макс. 32

Почтовый ящик

WorkerPostalCode

F

0

xs:string

Макс. 10

Индекс

WorkerCity

G

0

xs:string

Макс. 32

Город

WorkerState

H

0

xs:string

Макс. 32

Штат, область

WorkerCountry

I

0

xs:string

Макс. 32

Страна

WorkerPhone

J

0

xs:string

Макс. 20

Номер телефона

WorkerMobile

К

0

xs:string

Макс. 20

Номер мобильного телефона

WorkerLicenseNumber

L

0

xs:string

Макс. 32

Номер лицензии работника

WorkerEmail

M

0

xs:string

Макс. 64

Электронная почта

Пример.

<WKR A=”WKR1” В=”Смит” С=”Джон”/>

<WKR A=”WKR2” В=”Миллер” С=”Карл’7>

D.53 WorkerAllocation — WAN

Тип:

Данные задачи

Описание:

XML-элемент WorkerAllocation (Распределение работников) описывает распределение работников на задачу. Запись Allocationstamp описывает время начала/окончания распределения работников и изменения в распределении работников на задачу.

Ссылается на XML-элементы:

— Worker

Включен XML-элементом:

— Task

Включает XML-элемент:

—Allocationstamp

Таблица D.53 — Атрибуты WorkerAllocation

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

WorkerldRef

А

г

xs:IDREF

От мин. 4 до макс. 14

Ссылка на XML-элемент Worker. Формат: (WKR|WKR-)([0—9])+

Allocationstamp

о

xs:element

Включает единственный XML-элемент Allocationstamp

Пример.

<WAN A-”WKR1’’>

<ASP А- ”2003-08-20Т08:00:00” D=”4 ” />

</WAN>

<WAN A=”WKR2”>

<ASPA="2003-08-20T08:05:00” D-"4 ” />

</WAN>

D.54 ExternalFileContents — XFC

Тип:

Данные задачи

Описание:

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

Включает XML-элементы:

  • — CodedCommentGroup

  • — CodedComment

  • — ColourLegend

  • — CulturalPractice

  • — CropType

  • — Customer

  • — Device

  • — Farm

  • — OperationTechnique

  • — Product

  • — Partfield

  • — ProductGroup

  • — Task

  • — ValuePresentation

  • — Worker

D.55 ExternalFileReference — XFR

Тип:

Данные задачи

Описание:

XML-элемент ExternalFileReference (Ссылка на внешний файл) используется для указания ссылки на XML-файл, внешний к основному XML-файлу. Внешний файл может включать только XML-элементы верхнего уровня. XML-элементы верхнего уровня — это элементы, которые могут быть включены в XML-элемент ISO11783_TaskData. Во внешнем XML-файле может быть указан только единственный тип XML-элемента на файл. Не допускается рекурсивное использование XFR- и XFC-элементов.

Включен XML-элементами:

  • — ISO11783_TaskData

Включает XML-элементы: — Нет

Таблица D.54 — Атрибуты ExternalFileReference

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

Filename

A

г

xs:ID

8

Указание имени файла.

Формат: CCG|CCT|CLD|CPC|CTP|CTR| DVC| FRM|OTQ|PDT|PFD|PGP|

TSK| VPN|WKR)[0—9][0—9][0—9] [0-9][0-9]

Filetype

В

г

xs:NMTOKEN

1

1 =XML

ПРИМЕР.

<XFR А-’’FRMOOOOO" В=”1’7>

<XFR А=”СТР00000" В=”1 "/>

<XFR A=”PFD00000" В=”1 "/>

<XFR A=”WKR00000” В=”1 ”/>

<XFR А=”ССТ00000” В=”1 ”!>

<XFR A=”PGP00000” В=”1’7>

<XFR A=”PDT00000" B=”1 "/>

<XFR A=”DVC00000” B=”1’7>

<XFR A=”TSK00000” B="1 "/>

<XFR A-”TSK00001 ” B-"1 "/>

<XFR A=”TSK00002” B=”1 "/>

<XFR A-”VPN00000" B=”1’7>

<XFR А-’’CTROOOOO" B=”1 ”/>

Приложение Е (обязательное)

Предопределенные привязки ИСО-11783

  • Е.1 Link List

Встречаются ситуации, когда FMIS и MICS необходимо обмениваться дополнительной ключевой информацией об объектах набора данных XML. Предопределенная привязка Link List (Список ссылок) предоставляет стандартизованный способ, чтобы связать XML-элемент набора файлов передачи данных с одним или несколькими дополнительными ключевыми значениями. Существование идентификатора объекта является предварительным условием для этой связи. Ассоциации (далее также названные «сопоставлениями») между идентификаторами объектов XML-элемента и дополнительными ключевыми значениями хранятся в отдельном файле — файле списка ссылок — с именем ‘LINKLIST.XML’ (все буквы заглавные).

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

<?xml version=”1.0" encoding=”UTF-8”?>

Файл списка ссылок должен содержать один корневой XML-элемент, содержащий все определения ссылок.

Файл списка ссылок и XML-элементы, содержащиеся в этом файле, введены в 4-й версии ИСО 11783-10.

  • Е.2 ИСО 11783LinkList

Тип:

Корневой элемент

Описание:

XML-элемент ИСО 11783LinkList является корневым XML-элементом файла списка ссылок и содержит определения о конструкции XML-файла и включении основных XML-элементов.

Чтобы определить уникальное отношение между файлами LINKLIST.XML и TASKDATA.XML, должен использоваться атрибут FileVersion.

Файл TASKDATA.XML должен содержать элемент AttachedFile (AFE), < AFE = ’’LINKLIST.XML” В =”1” С =”” D =”1” F =”12988’7 >, чтобы указать передачу приложенного файла LINKLIST.XML.

В файле TASKDATA.XML может быть указана ссылка на не более чем один файл LINKLIST.XML.

Включает XML-элементы:

— LinkGroup

Таблица Е.1 — Атрибуты ИСО 11783LinkList

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

VersionMajor

VersionMajor

r

xs:NMTOKEN

От 4 до

99

Номер версии (главной) элемента списка, используемый для указания версии ИСО 11783-10, которой соответствует этот файл списка ссылок:

4 = Версия второго издания, опубликованного как заключительный проект Международного стандарта (E2.FDIS).

Примечание — ИСО 11783 LinkList введен в 4-й версии

VersionMinor

VersionMinor

r

xs:NMTOKEN

От 0 до

99

Номер версии (второстепенной) элемента списка, используемый для указания редакции XML schema, которой соответствует этот элемент. См. пункт 8.4 о соглашении об именовании XML schema

Managementsoftware

Manufacturer

Management Software Manufacturer

r

xs:string

32

Название производителя программного обеспечения управления

Managementsoftware

Version

Management

Software Version

r

xs:string

32

Версия программного обеспечения управления

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

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

TaskController Manufacturer

TaskController Manufacturer

0

xs:string

32

Название производителя ТС

TaskControllerVersion

TaskController

Version

0

xs:string

32

Версия программного обеспечения ТС

FileVersion

FileVersion

0

xs:string

32

Версия файла linklist

DataTransferOrigin

DataTransfer

Origin

r

xs:NMTOKEN

От 1 до 2

Описывает источник происхождения XML-файла:

  • 1 = FMIS.

  • 2 = MICS

LinkGroup

LGP

r

xs:element

Включает список LinkGroup XML-элемента

Пример.

<ISO11783LinkList VersionMajor=”4” VersionMinor="0"

TaskControllerManufacturer="FarmCtrl" TaskControllerVersion="1.0"

ManagementSoftwareManufacturer= "FarmSystem "

ManagementSoftwareVersion=”1.0” FileVersion=”3.2” DataTransferOrigin=”2”>

<LGP A=”LGP10” B="1” Е=”Образец ссылок UUID”>

<LNK A=”FRM1" B=”{1059B 14E-929F-4C4C-BCD4-C4F52A6A076A}"/>

<LNK A=”PFD3” B="{92043685-072D-4CAA-B3A8-C1E9D23BDB31}" С=”Межа’7>

<LNKA="PDT19" B=”{C89AA8C5-A9B3-4CA4-BE47-4449B9CD336E}’7>

<LNK A=”TSK-21” B=”{EB689DCE-A287-400C-9F0A-E8777716DDE6 }"/>

</LGP>

<LGP A=”LGP31 ” B=”3” D=”urn:epc:id:sgtin:” Е=”Образец ссылок GS1 GTIN”>

<LNKA=”PDT19” B=”0764011.9854564”/>

<LNK A=”PDT20" B="0764012.9852311’7>

</LGP>

</ISO11783LinkLlst>

E.3 Link —LNK

Тип:

Данные кодирования

Описание:

XML-элемент Link (Ссылка) связывает/сопоставляет/ассоциирует XML-элемент (объект) в наборе файлов передачи данных ИСО 11783 и значение ключа, соответствующее объекту вне области применения ИСО 11783. Формат и значение значения ключа зависят от LinkGroupType (тип группы ссылок), определенного в родительском элементе LinkGroup (группа ссылок). Также может быть указан дополнительный указатель для ссылки.

Включен XML-элементом:

— LinkGroup

Таблица Е.2 — Атрибуты Link

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

ObjectldRef

A

г

xs: ID

От миним. 4 до макс. 14

Идентификатор объекта, область уникальности этого идентификатора — набор файлов передачи данных ИСО 11783

LinkValue

В

г

xs:token

Макс. 255

Значение ссылки для объекта

LinkDesignator

С

о

xs:string

Макс. 32

Указатель ссылки

Пример.

<ISO11783LinkList VersionMajor=”4” VersionMinor=”0”

TaskControllerManufacturer= "FarmCtrl" TaskControllerVersion=”1.0"

ManagementSoftwareManufacturer= "FarmSystem "

Managementsoftware Version=”1.0 " File Version="3.2 " Data TransferOrigin="2 ”>

<LGPA=”LGP10” В="1” E=”UUIDs”>

<LNKA=”FRM1” B=”{1059B14E-929F-4C4C-BCD4-C4F52A6A076A}”/>

<LNKA=”PFD3” B=”{92043685-072D-4CAA-B3A8-C1 E9D23BDB31}” C=” Поворотная полоса’7>

<LNK A=”PDT19” B=”{C89AA8C5-A9B3-4CA4-BE47-4449B9CD336E}”/>

<LNK A=”TSK-21 ” B=”{EB689DCE-A287-400C-9F0A-E8777716DDE6 }”/>

<LNK A=”PFD-3” B=”{8D96B98A-62C2-44D0-9709-29467A4169F3}’7>

</LGP>

<LGPA=”LGP20” B=”3" D=”urn:epc:id:sgtin:” Е=”Ссылки GS1 GTIN”>

<LNK A=”PDT19” B=”0764011.9854564’7>

<LNК A=”PDT20” B=”0764012.9852311 "/>

</LGP>

</ISO11783LinkList>

E.4 LinkGroup — LGP

Тип:

Данные кодирования

Описание:

XML-элементы Link (LNK) могут быть созданы в различных целях и могут включать различные типы внешних объектов (ключей). XML-элемент LinkGroup (Группа ссылок) объединяет элементы Link одного общего типа ключа, а также содержит данные, общие для всех элементов Link группы. Атрибут типа LinkGroup (LGP.B) описывает тип ключа, содержащегося в LinkGroup.

Включает XML-элемент:

— Link

Таблица Е.З — Атрибуты LinkGroup

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

LinkGroupId

А

г

xs:ID

От мин. 4

до макс. 14

Уникальный идентификатор (в области файла списка ссылок) группы ссылок LinkGroup.

Формат: (LGP|LGP-)([0—9])+.

Записи, сгенерированные MICS, имеют отрицательные идентификаторы

LinkGroupType

В

г

xs:NMTOKEN

От 1 до 4

Выбор одного атрибута, который представляет тип внешнего объекта (ключа), участвующего в ссылке:

  • 1 — UUID.

Стандартизированные UUID. Все дочерние элементы группы Link содержат действительный UUID в атрибуте LinkValue (LNK.В). Для недавно созданных элементов MICS и FMIS необходимо создать UUID, используя ИСО/МЭК 98348 (технически совместимый с RFC 4122). В рамках стандарта должен использоваться алгоритм версии 4 (Случайный).

  • 2 — Собственность производителя

Если атрибут В имеет значение 2, действующий GLN обязателен в атрибуте ManufacturerGLN.

  • 3 — Уникальные разрешимые URI.

Этот тип может использоваться, чтобы связать элементы передачи данных с кодами GS1; например, полное значение ссылки представляет собой конкатенацию LinkGroupNamespace и LinkValue (LGP.D и LNK.B).

  • 4 — Информационные разрешимые URI Тип для (несвязного) набора информационных ссылок. Полное значение ссылки представляет собой конкатенацию LinkGroupNamespace и LinkValue (LGP.D и LNK.B)

Окончание таблицы Е.З

Атрибут

XML

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

Тип

Длина/ диапазон

Комментарий

ManufacturerGLN

C

0

xs:anyURI

Макс. 64

Номер глобального местоположения (Global Location Number, GLN) GS1 производителя. О существующих GLN или для запроса новых см. http://www.gs1 .ого

LinkGroupNamespace

D

0

xs:token

Макс. 255

Для разрешимых типов URI (3 и 4) этот атрибут содержит значение префикса, который применен ко всем значениям LinkValue содержащихся элементов Link. В LinkGroup типа 3 он должен содержать URI до последнего двоеточия включительно

LinkGroupDesignator

E

0

xs:string

Макс. 32

Указатель LinkGroup

Link

0

xs:element

Включает список Link элемента

Пример.

<LGPA=”LGP10” В=”1” E=”UUIDs”>

<LNKA=”FRM1” B=”{1059B14E-929F-4C4C-BCD4-C4F52A6A076A}’7>

<LNKA=”PFD3” B=”{92043685-072D-4CAA-B3A8-C1E9D23BDB31}” С=”Поворотная полоса”/>

<LNK A=”PDT19" B=”{C89AA8C5-A9B3-4CA4-BE47-4449B9CD336E}’7>

<LNKA=”TSK-21” B=”{EB689DCE-A287-400C-9F0A-E8777716DDE6}"/>

<LNK A=”PFD-3” B=”{8D96B98A-62C2-44D0-9709-29467A4169F3}”/>

</LGP>

<LGP A=”LGP31” B=”3” D=”urn:epc:id:sgtin:” E=”GS1 GTIN/EAN”>

<LNK A=”PDT19” B=”0764011.9854564’7>

<LNKA=”PDT20” B=”0764012.9852311 ”/>

</LGP>

<LGP A=”LGP32”B=”4” D=”https://Dortal.bvl.bund.de/psm/isp/DatenBlatt.isp?kennr=”Е=”Ссылки BVL”>

<LNKA-"PDT103" B=”024658-00’7>

<LNK A=”PDT104” B=”024145-00’7>

<LNK A=”PDT105” B-"004960-00"/>

<LNK A=”PDT106” B=”024309-00’7>

</LGP>

E.4.1 LinkGroupType 1: Универсальные уникальные идентификаторы

Уникальность идентификаторов объектов в наборе файлов передачи данных ИСО 11783 ограничена областью самого набора файлов передачи. Чтобы обеспечить активацию FMIS и MICS синхронизировать объекты в более широкой системной области, с каждым XML-элементом, у которого присутствует атрибут идентификатора объекта, может быть связан универсальный уникальный идентификатор (UUID).

Если у MICS есть возможность создать UUID, то ТС может добавлять новые записи в файл LINKLIST.XML. Идентификатор каждого недавно созданного объекта должен иметь соответствующие буквы пространства имен с последующим отрицательным десятичным числом.

UUID должны быть созданы согласно ИСО/МЭК 98348 (технически совместимым с RFC 4122). В рамках этого стандарта должен использоваться случайный алгоритм (версия 4).

UUID элементов, недавно созданных MICS, должны всегда добавляться к элементу LinkGroup типа 1 с пустым ManufacturerGLN. Из элементов LinkGroup с пустым ManufacturerGLN у любого XML-элемента набора файлов передачи данных должно быть не более одного элемента Link.

Пример.

<LGPA=”LGP10” В=”1” Е=”Пример UUID, Группа 1”>

<LNK А="FRM1 ” В=’’{1059B14E-929F-4C4C-BCD4-C4F52A6А076А}”/>

<LNKA=”PFD3” B=”{92043685-072D-4CAA-B3A8-C1E9D23BDB31}” С=”Поворотная полоса’7>

<LNKA=”PDT19” B=”{C89AA8C5-A9B3-4CA4-BE47-4449B9CD336E}”/>

<LNK A=”TSK-21 ” B=”{EB689DCE-A287-400C-9F0A-E8777716DDE6} ”/>

<LNK A=”PFD-3” B=”{8D96B98A-62C2-44D0-9709-29467A4169F3}”/>

</LGP>

<LGP A=”LGP20” B=”3” D=”urn:epc:id:sgtin:” E-"GS1 GTIN Links”>

<LNKA=”PD T19” B=”0764011.9854564”/>

  • < !— На тот же объект (PDT19) можно сослаться е нескольких LinkGroup. —>

  • < !— Исключением из этого правила являются LinkGroup типа 1 с пустым ManufacturerGLN. —>

<LNK A=”PDT20” В=”0764012.9852311’’/>

</LGP>

<LGPA=”LGP11” В=”1” Е=”Пример UUID, Группа 2”>

<LNKA=”FRM2” B=”{84A46623-2D31-4427-BB4E-288FAC4A48AB} "/>

<LNK A=”PFD5” B=”{F9B87F36-7F4A-445C-9083-C23D0F2492A8} ”/>

</LGP>

<LGP A=”LGP12” B=”1”>

<!— <LNK A=”FRM2” B=”{446278DF-4035-4101-92FD-47525D1AF077}’7> —>

  • < !— He разрешено! Должно быть не более одной ссылки на один и тот же XML —>

  • < !— элемент из LinkGroup типа 1 с пустым ManufacturerGLN! —>

</LGP>

  • Е .4.2 LinkGroupType 2: Собственные значения ссылок производителя

Группы ссылок типа 2 подходят для обмена собственными ключами производителя. Приведенные ниже примеры показывают сопоставление Customer и Product с собственными значениями ID. Обратите внимание, что допускается несколько ссылок на один и тот же элемент. В рамках собственной группы LinkGroup производителю необходимо знать (и сообщать партнерам), как использовать элементы Link, при условии, что они пройдут валидацию по схеме. Значение ключа элемента LNK может быть значением UUID.

Пример.

<LGPA=”LGP29” В=”2” C=”urn:ерс:id:sgln:0614141.33254.1 ” D=”” Е=”Собстеенные коды клиентов”>

<LNK A=”CTR103” В=”1909-19’7>

<LNKA="CTR104” В-"1909-20"/>

<LNKA=”CTR105" В=”1909-21 "/>

<!— CTR105 — клиент ‘Waldo & Beer’—>

<!— Так как произошло слияние (потребителя Waldo и потребителя Beer), —>

<!— существует также бывший id потребителя Beer (1909-34). Поэтому—>

<!— существует второй элемент LNK для CTR105. —>

<LNKA="CTR105" В=’’1909-34’7>

<LNKA=”CTR106” В-"1909-22"/>

</LGP>

<LGPA="LGP29” В=”2” C=”urn:epc:id:sgln:0614141.33254.1 ” D=”” Е=”Собстеенные коды продуктов”>

<LNK A-”PDT943" B="{3950035A-FE41-4A5B-89BB-D9AAF1F5FB99}" С="Продукт Х’7>

<LNK A=”PDT944” B="{DC759896-9026-4800-A548-657001A1FCF9}" С-"Продукт Y"/>

<LNK A=”PDT945” B=”{D8159354-BCC6-48A6-B566-23193AB95841}” С="Продукт Z"/>

</LGP>

<LGP A=”LGP30” B=”2” C="urn:epc:id:sgln:0123456.78901.2” D-"" Е-"Коды продуктов из FMIS">

<LNK A=”PDT943” B="{2AF969DA-E47A-4F18-B34F-99BD00C70A2D}’’ С="Консультационная система (агробизнес)’7>

<LNKA-"PDT943" B=”{F95829FD-7AFB-46A2-B213-9A7F00D8EDB1}” С=”Консультационная система (мастер)’7>

<!— В этом случае приобретение двух производителей химических веществ одной материнской —>

<!— компанией привело к тому, что один и тот же продукт (т.е. даже имеющий один и тот же —> <!— регистрационный номер) продавался от двух разных производителей, но с одним и тем же —> <!— названием. Контролируемый компанией FMIS-словарь, состоящий примерно из 20 000 —> <!— наименований продукции, включал 92 набора из 2 и более наименований: итого 198 записей, примерно 1% от общего числа. —>

</LGP>

<!— Следующая группа ссылок типа 1 (UUID) не имеет ничего общего с примером, но иллюстрирует, —> <!— что в одном файле LINKLIST.XML может быть несколько групп ссылок. —>

<LGP A=”LGP30” В-"1">

<LNKA-"PDT103" B="{84A46623-2D31-4427-BB4E-288FAC4A48AB}’7>

<LNK A="PDT104” B=”{F9B87F36-7F4A-445C-9083-C23D0F2492A8}’7>

</LGP>

E.4.3 LinkGroupType 3: Уникальные разрешимые URI

Группа ссылок типа 3 связывает XML-элемент набора файлов передачи данных с универсальным идентификатором ресурса URI, который должен однозначно идентифицировать элемент и быть неизменным с течением времени. Примерами URI являются:

de.wikipedia.orq

user@example.com:8080

192.0.2.16:80

[2001 :db8:: 7]

Конкатенация LGP.D и LNK.B должна быть разрешима для URI. Это необходимо для того, чтобы исключить избыточные данные, а также для того, чтобы сделать содержимое LinkGroup программно распознаваемым.

В особом случае, когда рассматриваемый URI является универсальным именем ресурса (URN), URN должен быть разделен последним двоеточием, используемым для указания пространства имен. Первая часть (пространство имен, включая двоеточие в конце строки) входит в атрибут D элемента LinkGroup (LinkGroupNamespace). Вторая часть — это LinkValue (LNK.B). Обратите внимание, что допускается использование нескольких ссылок на один тот же элемент.

Пример.

<LGP A=”LGP31” В=”3” D=’’urn:epc:id:sgtin:” E=”GS1 GTIN/EAN”>

<LNK A=”PDT19” B=”0764011.9854564’7>

<!— Становится urn:epc:id:sgtin:0764011.9854564 —>

<LNK A=”PDT20” B=”0764012.9852311 ”/>

</LGP>

<LGP A=”LGP32” B=”3” D=”urn:epc:id:sgln:” E=”GS1 GLN”>

<LNKA="C TR9 ”B=”4260159.94000.8”/>

<LNK A=”CTR10” B=”4014689.00000.4’7>

<LNK A=”CTR11” B=”4399901.95917.0’7>

<LNKA=”CTR11” B=” 4399902.09257.9”/>

  • <!— Обратите внимание, как можно иметь более одной ссылки на «CTR11» в одной и той же LinkGroup типа 3 —>

</LGP>

<LGPA=”LGP33” В=”3” D=”” Е=”1Р-адреса Базовой станции”>

<LNKA=”BSN1 ” В-"192.0.2.16"/>

<LNK A=”BSN2” В=”192.0.2.22’7>

</LGP>

  • Е.4.4 LinkGroupType 4: Информационные разрешимые URI

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

Тип 4 подходит для непостоянных интернет-страниц. Ссылки типа 4 не могут использоваться для идентификации или сопоставления. Конкатенированное значение из LGP.D и LNK.B должно быть разрешимым URL

Внутри Групп ссылок типа 4 может быть более одного элемента Link, относящегося к одному и тому же XML-элементу из набора файлов передачи данных.

Группа ссылоктипа 4 может использовать пространство имен LinkGroupNamespace. Если LinkGroupNamespace не пустое, то значение URI представляет собой конкатенцию LGP.D и LNK.B. Нет никаких правил относительно того, где должен быть разделен URI.

Пример.

<LGPA=”LGP29” В=”4”>

<LNK A=”PDT9” B=”http://www.baver.de/products?234234”/>

<LNK A=”PDT19” B=”htto://www.monsanto.com/7832637abc’7>

<LNK A=”PDT27” B=”http://www.kemira. com/service/products/info#6733a93 ”/>

<LNK A=”PDT27” B=” https://oortal.bvl.bund.de/Dsm/iso/DatenBlatt.isD?kennr=024658-00 “/>

<LNK A=”CTR22” B=”htto://www. aut-schrockwede. de/start.iso ”/>

<LNK A=”WKR7” B=”httn://www.facebook.com/max.muster?fref=ts” C=”facebook”/>

<LNK A=”WKR7” B=”http://www.max-muster.de” С=”персональная домашняя страница’7>

</LGP>

<LGP A=”LPG30” B=”4” D=” http://en.wikiDedia.org/wiki/”>

<LNK A=”CTP209” В=”Соя’7>

<LNK A=”CTP210” В=”Кукуруза’7 >

<LNK A=”CTP211” В=”Пшеница’7 >

<LNK A=”CTP212” B=”Oeec’7 >

</LGP>

<LGPA=”LGP31” B=”4” D=”httos://oortal.bvl.bund.de/nsm/isn/DatenBlatt.isn?kennr= ” Е=”Ссылки BVL”>

<LNK A=”PDT103” B=”024658-00’7>

<!— Полная ссылка: https://portal.bvl.bund.de/psm/isp/DatenBlatt.isp?kennr=024658-00 —>

<LNK A=”PDT104” B=”024145-00’7>

<LNK A=”PDT105” B=”004960-00’7>

<LNK A=”PDT106” B=”024309-00”/>

</LGP>

  • <!— LGP31 — это LinkGroupType 4, потому что LGP.D ссылается на существующий веб-сайт. —>

<!— Так что это URL в зависимости от существования https://portal.bvl.bund.de.—>

Приложение F (обязательное)

Функционал ТС и определения пула объектов дескриптора устройства

F.1 Общие положения

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

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

Эти рекомендации и примеры были разработаны в сотрудничестве с AEF [2], который способствует использованию стандартов ИСО 11783 в продуктах путем проведения испытаний на соответствие и мероприятий по поддержке внедрения.

F.2 Функционал ТС

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

Определен следующий функционал ТС:

  • а) ТС-BAS (контроллер задач — базовый) 1-го поколения.

  • Ь) ТС-GEO (контроллер задач — геопозиционирование) 1-го поколения.

  • с) TC-SC (контроллер задач — управление секциями) 1-го поколения.

  • d) LOG (регистратор данных) 1-го поколения.

Указанный функционал ТС, его требования и функциональные опции объясняются в следующих разделах.

F.2.1 Функционал ТС-BAS 1-го поколения

Функционал ТС-BAS определяется как сборник основанных на задаче общих значений, т.е. чтение и запись общих значений по задаче для одного или нескольких элементов устройства клиента ТС. Общие значения — это накопленные значения для входящих или исходящих ресурсов, расстояния, времени или нормы этих значений (например, общая площадь, общая масса урожая и т.д.); общие значения не обязательно привязаны к местоположению и, следовательно, не требуют данных о времени или положении.

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

Соответствующий ТС-BAS клиент ТС может предоставить часть набора общих значений. Для соответствия ТС-BAS клиент ТС должен предоставить как минимум DDI 119 (общее время). В случае, если DDI расхода также определяется в рамках DDOP, должно быть предоставлено соответствующее общее значение. Список дополнительных рекомендуемых общих значений по типам устройств представлен в таблице F.1.

Таблица F.1 — Рекомендуемые DDI общих значений по классам устройств

Класс устройства

DDI (определены в ИСО 11783-11)

1

Трактор

117, 118, 119, 120, 148

2

Первичная обработка почвы

116, 117, 119

3

Вторичная обработка почвы

116, 117, 119

4

Сеялки/посевные машины

81 или 82, 116, 117, 119

5

Внесение удобрений

81, 116, 117, 119

6

Опрыскиватели

80, 116, 117, 119

7

Зерноуборочные комбайны

89 или 90 или 91, 116, 117, 119

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

Класс устройства

DDI (определены в ИСО 11783-11)

8

Комбайны для уборки корнеплодов

116, 117, 119

9

Кормоуборочные комбайны

116, 117, 119

10

Орошение

80, 119

11

Транспорт/Прицепы

117, 119

12

Операции на ферме

119, 120

13

Вспомогательные устройства с питанием

116, 117, 119

14

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

116, 117, 119

15

Земляные работы

119

16

Трелевочные тракторы

119, 148

17

Системы датчиков

119

25

Аппликаторы органических удобрений

80, 116, 117, 119

Реализации FMIS, ТС и клиентов ТС в соответствии с ТС-BAS 1-го поколения должны публиковать версию 3 контроллера задач в наборе файлов передачи данных (например, ISO11783_TaskData) и сообщение о версии.

Изделия FMIS должны учитывать ограничения встроенных реализаций ТС, и, наоборот, реализации ТС должны избегать генерации большого набора файлов передачи данных задачи. Реализации FMIS и ТС должны поддерживать набор файлов передачи данных задачи, содержащий в общей сложности не менее 20 000 XML-элементов и не менее 2 000 XML-элементов на каждый тип элемента.

Реализации серверов FMIS или ТС в соответствии с ТС-BAS 1-го поколения не требуются для обработки следующих XML-элементов:

  • a) OperationTechnique.

  • b) OperationTechniqueReference.

  • с) CodedCommentGroup.

  • d) Connection.

  • е) Все геометрически или географически привязанные элементы.

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

Список пулов объектов дескрипторов устройств, соответствующих функционалу ТС-BAS 1-го поколения, представлен в F.3.

F.2.2 Функционал ТС-GEO 1-го поколения

Функционал ТС-GEO определяет обработку привязанных к местоположению значений для задачи, выполняемой элементами устройств клиента ТС, исходя из их географических положений. ТС-GEO требует наличия источника позиционирования, например приемника ГНСС, подключенного к ТС. Несмотря на то, что функционал ТС-GEO относится к регулированию норм внесения, данный функционал не ограничивается устройствами с управляемыми элементами данных процесса. ТС-GEO также применим, например, к клиентам ТС, не имеющим управляемых элементов, которые предоставляют данные процесса фактического внесения для целей сопоставления (например, данные датчиков урожайности комбайнов или данные о плотности посадки сеялки).

Все DDI, определенные в стандарте ИСО 11783-11 и перечисленные в словаре данных ISOBUS, должны поддерживаться типом службы ТС в целях соответствия сервера ТС функциональности TC-GEO.

Соответствующий ТС-GEO клиент ТС может предоставить часть набора DDI, относящихся к процессам, которыми он управляет или для которых предоставляет данные для регистрации в журнал. Список рекомендованных DDI по типу устройства приведен в таблице F.2. В случае, если в устройстве выполняются процессы управления расходом, рекомендуется поддерживать как минимум одну пару DDI заданного и фактического значений расхода. Наряду с контролем нормы внесения можно управлять и другими DDI заданных значений, например рабочей глубиной для обработки почвы.

Таблица F.2 — Рекомендуемые DDI расхода по классам устройств

Класс устройства

DDI (определены в ИСО 11783-11)

4

Сеялки/посевные машины

6, 7, 11, 12, 16, 17

5

Внесение удобрений

1,2, 6, 7

6

Опрыскиватели

1,2, 6, 7

Окончание таблицы F.2

Класс устройства

DDI (определены в ИСО 11783-11)

7

Зерноуборочные комбайны

7, 84, 181

8

Комбайны для уборки корнеплодов

7, 84

9

Кормоуборочные комбайны

7, 84, 181

10

Орошение

1, 2

25

Аппликаторы органических удобрений

1, 2, 6, 7

В случае, если поддерживается функционал ТС-GEO, то должен поддерживаться и функционал TC-BAS.

Реализации FMIS, ТС и клиента ТС в соответствии с ТС-GEO 1-го поколения должны публиковать версию 3 контроллера задач в наборе файлов передачи данных (например, ISO11783_TaskData) и сообщение о версии.

Требуется обработка сеток типов 1 и 2. Минимальное поддерживаемое количество рядов и столбцов в сетке — 350 рядов и 350 столбцов.

Обработка карт заданий дифференцированного внесения на основе полигонов не является обязательной. Если ТС поддерживает задания дифференцированного внесения на основе полигонов, то это должно быть указано в сообщении о функционале функции управления. Сообщение о функционале функции управления определено в стандарте ИСО 11783-12.

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

Список пулов объектов дескрипторов устройств, которые соответствуют функционалу ТС-GEO 1-го поколения, представлен в F.3.

F.2.3 Функционал TC-SC 1-го поколения

Функционал TC-SC определяет управление включением/выключением элементов устройства клиента ТС в зависимости от их географического положения. Функционал TC-SC включает возможность определения, встречали ли эти элементы устройства ранее обработанные или другие особые области (например, поворотную полосу или участок вне поля), чтобы свести к минимуму дублирование и пропуски внесения. Функционал TC-SC требует наличия такого источника позиционирования, как приемник ГНСС, подключенный к ТС.

Сервер TC-SC должен поддерживать как минимум 1 штангу и 3 секции, в то время как клиент ТС поддерживает минимум 1 штангу и 1 секцию. Если сервер TC-SC может управлять меньшим количеством штанг или секций, чем может передаваться и управляться физически клиентом ТС, то клиенту ТС необходимо настроить количество штанг и секций в дескрипторе своего устройства в соответствии с количеством штанг и секций, которыми может управлять сервер ТС. В этом случае клиент ТС должен объединить свои физически управляемые элементы устройства таким образом, чтобы меньшее количество штанг или секций передавалось на сервер ТС. Количество штанг и секций, которые либо поддерживаются сервером ТС, либо могут управляться клиентом ТС, должно быть указано в сообщении о функционале функции управления и в сообщении о версии. Клиент ТС должен использовать информацию, указанную в сообщении о версии, для настройки пула объектов дескрипторов устройств на сервере ТС в случае, если количество штанг или секций, которыми может управлять клиент ТС, превышает возможности функционала TC-SC сервера ТС.

Функционал TC-SC не зависит от функционала ТС-BAS или ТС-GEO, он не требует поддержки одного из них в сочетании с функциональностью TC-SC. Для обеспечения только функционала TC-SC нет требования поддерживать обработку набора файлов передачи данных или соединения между FMIS и ТС.

Реализации ТС и клиентов ТС в соответствии с TC-SC 1-го поколения должны публиковать версию 3 контроллера задач в сообщении о версии.

DDI, которые должны поддерживаться сервером TC-SC и клиентом ТС для обеспечения функционала TC-SC, перечислены в таблице F.3.

Таблица F.3 — DDI, которые должны поддерживаться для обеспечения функционала TC-SC

DDI (определены в ИСО 11783-11)

67, 70, 134, 135, 141,142, 143, 160, 161... 176, 205, 206, 290... 305

Список пулов объектов дескрипторов устройств, которые соответствуют функционалу TC-SC 1-го поколения, представлен в F.3.

F.2.4 Функционал LOG 1-го поколения

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

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

Соответствующий функционалу LOG клиент LOG может предоставить часть набора общих за весь срок службы значений. Для обеспечения соответствия функционалу LOG клиент LOG должен предоставить как минимум DDI 274 (общее время за весь срок службы). В случае если DDI расход также определяется в рамках DDOP, должно быть предоставлено соответствующее общее значение за весь срок службы. Перечень рекомендуемых дополнительных общих значений за срок службы по типам устройств представлен в таблице F.4.

Таблица F.4 — Рекомендуемые DDI общих значений по классам устройств

Класс устройства

DDI (определены в ИСО 11783-11)

1

Трактор

272, 273, 274, 275, 276

2

Первичная обработка почвы

271, 272, 274

3

Вторичная обработка почвы

271, 272, 274

4

Сеялки/посевные машины

271,272,274, 266 или 267

5

Внесение удобрений

271, 272, 274, 266

6

Опрыскиватели

271,272, 274, 325

7

Зерноуборочные комбайны

271, 272, 274 и 268 или 269 или 270

8

Комбайны для уборки корнеплодов

271, 272, 274

9

Кормоуборочные комбайны

271, 272, 274

10

Орошение

274, 325

11

Транспорт/Прицепы

272, 274

12

Операции на ферме

274, 275

13

Вспомогательные устройства с питанием

271, 272, 274

14

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

271, 272, 274

15

Земляные работы

274

16

Трелевочные тракторы

274, 276

17

Системы датчиков

274

25

Аппликаторы органических удобрений

325, 271,272, 274

Реализации FMIS, сервера LOG и клиента LOG в соответствии с функционалом LOG 1-го поколения должны публиковать версию 4 контроллера задач в файле передачи данных и сообщение о версии.

Изделия FMIS должны учитывать ограничения встроенных реализаций LOG, и, наоборот, реализации LOG должны избегать генерации больших файлов передачи данных задачи. Реализации FMIS и LOG должны поддерживать файлы передачи данных задачи, содержащие не менее 20 000 XML-элементов в общей сложности и не менее 2 000 XML-элементов на каждый тип элемента.

Список пулов объектов дескрипторов устройств, которые соответствуют функциональности LOG 1-го поколения, представлен в F.3.

F.3 Пулы объектов дескрипторов устройств

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

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

F.3.1 Определение элемента устройства штанги

Во многих пулах объектов дескрипторов устройств упоминается понятие «штанга». Штанга является либо элементом устройства типа «Функция», либо элементом устройства типа «Устройство». В случае, если штанга является элементом устройства типа «Устройство», то это корневой элемент устройства. Концепция штанги используется для обозначения индивидуальной операции устройства, которая приводит к нанесению одного слоя покрытия (обработанной площади) для этого устройства. В случае если устройство имеет несколько штанг, то одновременно можно отслеживать и управлять несколькими операциями или слоями покрытия для этого устройства. Элемент устройства, который представляет штангу, может иметь набор элементов устройств типа «Секция» или «Бункер» в качестве дочерних элементов устройства для более подробного описания уровня управления покрытием и для поддержки устройств, которые позволяют вносить несколько материалов через одну штангу. Примерами штанг являются жатка на комбайне, штанга опрыскивателя с форсунками на аппликаторе для внесения жидкостей или ряд высевающих аппаратов на сеялке.

F.3.2 Условные обозначения диаграмм дескриптора устройства

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




Элемент устройства типа «device» (устройство)

Элемент устройства типа «function» (функция)

Элемент устройства типа «bin» (бункер)

Элемент устройства типа «section» (секция)

Элемент устройства типа «unit» (блок)

Элемент устройства типа «navigation reference» (навигационная метка)

Элемент устройства типа «connector» (соединитель)

Рисунок F.1 — Обозначение типов элементов устройств

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

DDI

Свойство

DDI

Данные процесса (только чтение)

DDI

Данные процесса, общее значение за срок службы

DDI

&

Данные процесса, общее значение

DDI

Данные процесса, заданное значение

DDI

•»

Данные процесса, источник управления

DDI

©

Измерение в интервал времени

DDI

JT-

Измерение при изменении

DDI

Измерение в интервал расстояния

Рисунок F.2 — Обозначение атрибутов элементов устройств

F.3.3 Пулы объектов дескрипторов устройств ТС-BAS поколения 1

Самая простая версия из ТС-BAS поколения 1 соответствует пулу объектов дескрипторов устройств, показанному на рисунке F.3. Этот дескриптор устройства содержит только один атрибут — общее время, обозначенное карандашом как заданное общее время. Символ измерения временного интервала указывает на то, что этот общий DDI может быть запрошен для передачи через определенный интервал времени.


Рисунок F.3 — Устройство с одной операцией без элемента устройства «Функция» и без информации о геометрии

Устройства, включающие DDI расхода, должны обеспечивать соответствующий общий DDI для этого расхода (рисунок F.4).



119

^0

Общее время

X

Г-0

Текущий расход

Y

^0

Значение общего расхода

Рисунок F.4 — Устройство с одной операцией с текущим DDI расхода без элемента устройства «Функция» и без информации о геометрии

Пример, приведенный на рисунке F.5, добавляет дополнительный элемент «соединитель» устройства в пул объектов дескриптора устройства и задает ширину рабочей зоны устройства в корневом элементе устройства. Показаны два варианта обеспечения ширины рабочей зоны и смещений соединения в качестве свойств или данных процесса. Если значение этих атрибутов является константой для устройства, то рекомендуется использовать 144

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





DET-0

119

(ft©

Общее время

X

-Р-0

Текущий расход

Y

Значение общего расхода

67

-Р-0

Текущая ширина рабочей зоны


DET-D

119

а®

Общее время

X

-п-ф

Текущий расход

Y

Значение общего расхода

67

-Р-0

Текущая ширина рабочей зоны




134

©

Смещение X

135

Смещение Y

157

Тип соединения


134

_Р-

Смещение X

135

_Р-

Смещение Y

157

[ml

Тип соединения



Рисунок F.5 — Устройство с одной операцией с текущим DDI расхода и информацией о типе соединения и ширине рабочей зоны

Описанные ранее пулы объектов дескриптора устройства не имели элементы функционирования устройства, отдельного от корневого элемента устройства. Это разделение показано на рисунке F.6 для самого базового дескриптора устройства слева и с дополнительным соединительным элементом устройства справа.


Рисунок F.6 — Устройство с одной операцией с отдельным элементом устройства «Функция» — с элементом устройства «тип соединения» и без него

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

Итоговые данные могут быть представлены в нескольких элементах устройства. На рисунке F.8 приведен пример общего времени, доступного для устройства, указанного в корневом элементе устройства, а также общего времени, записанного для конкретного элемента устройства «Функция». Каждое общее время обновляется на основе логики элемента устройства, в котором оно указано. Все итоговые значения элемента устройства «Функция» не обязательно должны совпадать с итоговыми значениями на уровне устройства. Для функциональности ТС-BASE поколения 1 общее время DDI на уровне устройства является обязательным, любое общее время DDI внутри других элементов устройства не является обязательным.

DET-0



Рисунок F.7 — Устройство с одной операцией с текущим расходом и шириной рабочей зоны DDI и отдельным элементом устройства «Функция» с элементом устройства «тип соединения» и без него


Рисунок F.8 — Общее время, имеющееся на уровне устройства и уровне Функции

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

Вместо общего элемента устройства «Функция» в качестве атрибутов элемента устройства «Бункер» также могут быть указаны DDI расхода и связанные с ними итоговые значения. Два примера этих пулов объектов дескрипторов устройств приведены на рисунке F.9. В этом примере рекомендуется указать расход, ширину рабочей зоны и информацию о соединении. Корневой элемент устройства представляет собой штангу устройства. Расположение элементов устройства «Бункер» в качестве дочернего элемента штанги указывает на то, что продукт из этого бункера распределяется через эту штангу. Не допускается иметь одинаковый DDI расхода, прикрепленный как к корневому элементу устройства, так и к элементу «Бункер». Общее время в корневом элементе устройства является обязательным, и общий расход DDI должен быть расположен в том же элементе устройства, который имеет текущий расход DDL

DET-0

116

1^0

Общая площадь

117

^0

Общее расстояние

119

Общее время

67

_р-ф

Текущая ширина рабочей зоны


CNN]


BIN 1

X

-ф-

Заданный расход

Y

-Р-0

Текущий расход

Z

fi) 0

Общий расход

178

_п-

Экземпляр элемента данного типа (0)

179

_р-

Текущий технологический процесс (1)


134

fi)

Смещение X

135

Смещение Y

157

в

Тил соединения



Рисунок F.9 — Устройство с одной операцией с элементом устройства «Бункер»

Рисунок F.10 расширяет рисунок F.9, добавляя дополнительную операцию к устройству и отдельные элементы устройства «Функция», которые представляют собой два независимых способа применения штанги. В этом примере каждый элемент устройства «Функция» представляет собой штангу. Расположение элементов устройства «Бункер» в качестве дочерних элементов штанг указывает на то, что продукты из этих бункеров распределяются через эти штанги. Одинаковый расход DDI не должен возникать как в элементах устройства «Функция», так и в элементах устройства «Бункер» и не должен быть присоединен одновременно к элементу корневого устройства и элементу устройства «Функция» штанги.

Первая функция слева на рисунке F.10 представляет собой операцию внесения удобрений (текущий технологический процесс DDI имеет значение 1), вторая функция представляет собой операцию посева или посадки (текущий технологический процесс DDI имеет значение 2). Общие значения внутри корневого элемента устройства представляют собой общие значения устройства. Общие значения элементов устройства «Функция» представляют собой только общие значения для каждой операции. Сумма общих значений уровня функции не обязательно совпадает с общими значениями устройства. Общее время в корневом элементе устройства является обязательным, общее время DDI в элементе устройства «Функция» является необязательным.

В случае наличия нескольких штанг вид текущей операции DDI (179) должен быть размещен либо в элементе устройства «Функция» штанги, либо в базовом элементе устройства «Бункер».

Элемент типа образец (Instance) DDI (178) должен использоваться для идентификации бункера для оператора, чтобы позволить выбрать, из какого бункера брать продукт. Это означает, что экземпляр элемента данного типа DDI должен быть помещен внутри элемента устройства «Бункер».

Использование текущего технологического процесса DDI дополнительно показано на рисунке F.11. В этом примере пула объектов дескриптора устройства пресс-подборщика, значение 5 DDI текущего технологического процесса идентифицирует это устройство как пресс-подборщик, а не, например, как косилку. Без использования текущего технологического процесса DDI эти устройства были бы неразличимы, так как класс устройств для пресс-подборщиков и косилок — это кормоуборочные машины.

DET-0


116

^0

Общая площадь

117

^0

Общее расстояние

119

^0

Общее время



FUN 2



BIN 1


X

-ф-

Заданный расход

Y

-Р-0

Текущий расход

Z

^>0

Общий расход

178

Экземпляр элемента данного типа (0)

179

_р-

Текущий технологический процесс(1)



116

^0

Общая площадь

117

i^0

Общее расстояние

119

Общее время

67

-Р-0

Текущая ширина рабочей зоны


BIN 2



134

Ш

Смещение X

135

|Й)

Смещение ¥

157

Тип соединения



Y

-Р-0

Текущий расход

Z

^0

Общий расход

178

_р-

Экземпляр элемента данного типа (1)

179

JP-

Текущий технологический процесс(2)


Рисунок F.10 — Многооперационная сеялка с двумя Функциями и двумя бункерами



Рисунок F.11 —Дескриптор устройства пресс-подборщика, класс устройства для уборки кормов


На рисунке F.12 показан пример дескриптора устройства пресс-подборщика, включающего два уровня подсчета тюков. В этом примере общее количество измельченных и неизмельченных тюков должно равняться значению общего счета DDL

DET-0

119

0G

Общее время

91

Общее количество урожая

283

Общее количество измельченного

284

Общее количество неизмельченного

179

_г-

Текущий технологический процесс (5)

Рисунок F.12 — Дескриптор устройства пресс-подборщика с несколькими общими значениями

Другой пример для конкретного класса устройств приведен на рисунке F.13. В этом примере задается набор общих значений для трактора, которые могут быть записаны. Элементы устройства соединитель (Connector) и элемент устройства навигация (Navigation) являются дополнительными для функциональности TC-BAS.

DET-0

117

^■0

Эффективное общее расстояние

118

t?0

Неэффективное общее расстояние

119

30

Эффективное общее время

120

^■0

Неэффективное общее время

148

<^0

Общий расход топлива



(CNN3

Заднее трехточечное навесное устройство

134 Смещение X

135 Смещение Y

157 Тип соединения


Рисунок РИЗ — Дескриптор устройства трактора с несколькими общими значениями

Если исходное заданное значение и значение, заданное пользователем, одинаковые для устройства с возможностью одноуровневого управления (например, онлайн-датчик) и совпадают с заданным значением DDI, то эти объекты данного процесса устройства не должны упоминаться в одном элементе устройства. Рисунок F.14 иллюстрирует этот случай: два отдельных элемента устройства требуются, когда один и тот же DDI присутствует как в качестве источника заданного значения, так и в качестве значения, заданного пользователем.

DET-0

Рисунок F.14 — Описание сенсорного устройства, заданное значение исходное/пользователь с одним и тем же DDI

F.3.4 Пулы объектов дескрипторов устройства ТС-GEO поколения 1

Минимальная структура пула объекта дескрипторов устройства, которая соответствует функциональности ТС-GEO, показана на рисунке F.15. Это устройство включает единственную штангу. Минимальное количество штанг, которое должно присутствовать в ТС-GEO, соответствует одной штуке. Минимальная функциональность штанги состоит из обеспечения фактических значений, которые могут быть привязаны в пространстве. Как минимум, для этих атрибутов фактических значений технологических данных должен поддерживаться триггер измерения «Временной интервал».

F.3.4.1 Рабочее состояние

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

F.3.4.2 Геометрия

Каждая штанга должна обеспечивать свое полное геометрическое определение, чтобы позволить ТС и FIMS получить рабочую зону. Как минимум, геометрия определяется свойствами или данными процесса для смещения X, смещения Y и максимальной ширины рабочей зоны DDL Смещение X и смещение Y DDI необходимы для каждой штанги. Геометрия штанги не должна выходить из дочерних секций элементов устройства.

В пуле объектов дескриптора устройства допускается смешивание данных процесса и атрибутов свойств. На рисунке F.17 атрибут типа соединитель (Connector) — это свойство, которое не будет изменяться в течение срока работы структуры пула объектов дескриптора устройства, в то время как остальные атрибуты геометрии могут изменяться, например, при изменении конфигурации устройства.

Для данных геометрического процесса рекомендуется использовать триггер измерения «On Change». При запуске системы ТС, поддерживающий функциональность ТС-GEO, должен запросить у устройства его геометрические значения DDI, чтобы убедиться, что правильная геометрия используется для определения команд покрытия и определения местоположения.

Функциональность ТС-GEO требует наличия соединителя, который определяет точку подключения к трактору для навесного или прицепного орудия. Определение нескольких соединителей разрешено в пуле объектов дескрипторов устройств. Элементы устройства типа соединитель (Connector) и навигация (Navigation) должны располагаться только непосредственно под корневым элементом устройства. Элементы устройства соединитель (Connector) и навигация (Navigation) должны включать свойства смещения X и Y или данные процесса, а также определение типа соединителя.

F.3.4.3 Ширина рабочей зоны

Максимальная ширина рабочей зоны DDI, указанная в соответствии с требованиями геометрии, представляет собой ширину, к которой может быть применено заданное значение предписания. Эта максимальная ширина может изменяться динамически на некоторых типах орудий или может быть статическим свойством, когда заданное значение предписания применяется через штангу фиксированной ширины. Опционально штанга может обеспечивать фактическую рабочую ширину. Текущая ширина рабочей зоны на уровне устройства или функции должна зависеть от текущего рабочего состояния его основных секций. Это позволяет устройству или функции сообщать текущую рабочую ширину как сумму ширины рабочих зон секций, которые «включены», в то время как ТС или FMIS используют ширину рабочих зон секций для определения геометрии секций и отображения того, где секции были «включены» или «выключены».

Рисунок F.15 — Текущая скорость и геометрия представлены в дескрипторе устройства

F.3.4.4 Состояние управления дифференцированным внесением

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

  • а) При остановке работы клиент ТС должен внутренне установить ее состояние управления дифференцированным внесением в деактивировано/выключено.

  • Ь) ТС должен установить состояние управления дифференцированным внесением в активировано/включено перед отправкой команд величины расхода клиенту ТС.

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

  • d) ТС должен использовать команду определения по изменению для получения изменений состояния управления дифференцированным внесением от клиента ТС.

Штанга, включающая атрибут данных заданного значения процесса, должна также включать соответствующий атрибут данных текущего значения процесса. Этот вариант рисунка F.15 представлен на рисунке F.16.

F.3.4.5 Секции штанги

На рисунке F.17 показано добавление к штанге элементов устройства, состоящего из секций. В этом примере штанга, соответствующая ТС-GEO, содержит требования для функциональности TC-SC. Атрибуты TC-GEO (состояние управления дифференцированным внесением) и TC-SC (состояние управления секцией) присутствуют в элементе устройства штанга.

DET-0 (действует как штанга)

141

.Р-0

Текущее состояние работы

Y

0

Текущий расход

X

-А-г-

Заданный расход

158

-ф_п-

Состояние управления дифференцированным внесением

134

Смещение X

135

Смещение Y

67

_Р-0

Текущая ширина рабочей зоны

70

_Р-0

Максимальная ширина рабочей зоны



134

Смещение X

135

©

Смещение Y

157

Тип соединения


Рисунок F.16 — Заданная скорость, добавленная к дескриптору устройства



DET-0 (действует как штанга)

141

-П-0

Текущее состояние работы

Y

0

Текущий расход

X

ф-г-

Заданный расход

158

ф-г-

Состояние управления дифференцированным внесением

67

_П-0

Текущая ширина рабочей зоны

70

-П-0

Максимальная ширина рабочей зоны

160

■ф-л-

Состояние управления секцией

161

-Р-0

Текущее сокращенное состояние работы

290

ф-г-

Заданное сокращенное состояние работы

134

_р-

Смещение X

135

_г-

Смещение Y



SCT 1..П


67

_п-

Текущая ширина рабочей зоны

134

_Р-

Смещение X

135

_Р-

Смещение Y


134

_Р-

Смещение X

135

_г-

Смещение Y

157

Тип соединения


Рисунок F.17 — Штанга с секциями, выполняющая одну операцию

Рисунок F.18 показывает пример пула объектов дескриптора устройства с элементом устройства «Функция», определяемого как штанга. Если штанга определяется элементом устройства «Функция», то текущее и заданное значения, смещение X и Y, максимальная ширина рабочей зоны и состояние управления дифференцированным внесением должны все быть помещены в этот элемент устройства. В этом случае корневой элемент устройства (DET-0) не должен содержать фактического или заданного значения, кроме атрибута текущего состояния работы.

DET-0

141


Г-0


Текущее состояние работы


FUN (действует как штанга)

141

.Р-0

Текущее состояние работы

Y

Текущий расход

X

-ф-Т1-

Заданный расход

158

-ф-т-

Состояние управления дифференцированным внесением

67

Текущая ширина рабочей зоны

70

Г-0

Максимальная ширина рабочей зоны

160

-ф-J1-

Состояние управления секцией

161

Текущее сокращенное состояние работы

290

-ф'.П-

Заданное сокращенное состояние работы

134

_П-

Смещение X

135

_г-

Смещение Y



134

_Р-

Смещение X

135

_Р-

Смещение Y

157

fil

Тип соединения


SCT

1. п

67

_Р-

Текущая ширина рабочей зоны

134

_Р-

Смещение X

135

_Р-

Смещение Y

Рисунок F.18 — Устройство, выполняющее одну операцию с функцией, действующей как штанга

В качестве альтернативы рисунку F.18 можно добавить элемент устройства «Бункер» ниже элемента устройства, представляющего штангу, когда продукт подается через эту штангу. В случае если устройство имеет только одну операцию, использование DDI экземпляра элемента данного типа внутри элемента устройства «Бункер» не является обязательным. Этот пул объектов дескрипторов устройств показан на рисунке F.19.

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

DET-0

141

Г-0

Текущее состояние работы


FUN 1 (представляет штангу 1)

141

Г-0

Текущее состояние работы

67

Г-0

Текущая ширина рабочей зоны

70

Г-0

Максимальная ширина рабочей зоны

160

Состояние управления секцией

161

Г-0

Текущее сокращенное состояние работы

290

-ф-Т-

Заданное сокращенное состояние работы

134

_п-

Смещение X

135

Т1-

Смещение Y

205

Время включения SC

206

ч

Время выключения SC



134

г-

Смещение X

135

_р-

Смещение Y

157

Тип соединения


SCT


158

142

178



BIN 1



Заданный расход



0г-


Текущий расход

Состояние управления дифференцированным внесением Физическая задержка заданной величины


Экземпляр элемента данного типа (0)


179


Текущий технологический процесс (1)

Рисунок F.19 — Однооперационное устройство с отдельным элементом устройства «Бункер», штанга представлена элементом устройства «Функция»

F.3.4.6 Задержка управления

На рисунке F.20 показаны значения данных процесса от эффекта физической задержки заданной величины. Если в элементе устройства присутствует атрибут физической задержки времени заданной точки, то его значение должно использоваться ТС для регулировки отправки заданных команд для задержки срабатывания в клиенте ТС. Рисунок F.20 показывает поток сообщений между ТС, подключенным клиентом ТС и внутренней связью устройства с модулем управления расходом. Клиент ТС в этом примере передает текущее обновление расхода на основе временного интервала по времени Т1, ТЗ и Т4. ТС получает обновление позиции и передает команду изменения расхода, которая приводит к тому, что расход начинает изменяться в момент времени Т2. Между отметками времени Т2 и Т4 расход обновляется контроллером расхода, и время, необходимое для реализации устройством обновления расхода, составляет Т4 — Т2, в мс. Это время сообщается клиентом ТС как значение DDI физической задержки заданной величины. ТС, компенсирующий физическую заданную задержку времени, должен спроецировать положение, полученное в точке Т2, на расчетное положение элемента устройства в точке Т4 и передать клиенту ТС заданное значение расхода для расчетного положения в точке Т4. Обратите внимание, что обновления текущего расхода на основе временных интервалов могут передаваться во время изменения расхода.


Клиент ТС


Контроллер расхода

Получение расхода


Обновление текущего расхода


Обновление расхода


Т1 - интервал времени, — основанный на обновлении

текущего расхода


Обновление положения


Команда заданного расхода


Обновление заданного . расхода


Обновление текущего расхода


Обновление текущего расхода


Изменение расхода


Получение расхода


Обновление расхода


Получение расхода


Обновление расхода


Т2 - начало — изменения расхода


ТЗ - интервал

_ времени, основанный на текущем расходе


Т4 - завершение изменения расхода


Т5 - интервал времени, — основанный на текущем обновлении расхода


см


<х>


«3


Рисунок F.20 — Схема последовательности физической задержки заданной величины и обновления расхода

Если присутствует атрибут физической текущей задержки времени (DDI 143), то его значение должно использоваться ТС и FMIS для корректировки значений, например, на карте до правильного местоположения. Обратите внимание, что физическое текущее значение задержки времени может быть, как положительное, так и отрицательное. Примеры этих случаев определены в значении DDI в стандарте ИСО 11783-11. Физическая задержка заданной величины может иметь только положительное значение.

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

F.3.4.7 Несколько каналов управления

Более сложное устройство, имеющее две независимые операции управления работой, изображено на рисунке F.22. Первая функция в этом примере представляет собой операцию внесения удобрений с атрибутом текущего технологического процесса, имеющим значение 1. Вторая функция представляет собой операцию посева или посадки с текущим технологическим процессом, имеющим значение 2. В случае нескольких штанг атрибут текущего технологического процесса (DDI 179) должен располагаться в штанге или в нижележащем элементе устройства «Бункер». ТС может дифференцировать определения штанги на основе значения атрибута текущего технологического процесса.

Атрибут «экземпляр элемента данного типа» (DDI 178) должен использоваться для идентификации каждого бункера для оператора. Это позволяет оператору выбрать, из какого бункера будет взят продукт. Следовательно, атрибут «экземпляр элемента данного типа» должен быть помещен внутри элемента устройства «Бункер».

Как и в предыдущих примерах, не допускается одновременное размещение одного и того же атрибута расхода в элементе корневого устройства и штанге или в элементе устройства «Функция», выполняющем функции штанги, и элементе устройства «Бункер».

DET-0 (действует как штанга)

141

Л-0

Текущее состояние работы

67

Л0

Текущая ширина рабочей зоны

70

Л-0

Максимальная ширина рабочей зоны

160

фЛ

Состояние управления секцией

161

Л-0

Текущее сокращенное состояние работы

290

ф-л-

Заданное сокращенное состояние работы

134

л-

Смещение X

135

Смещение Y

205

ф-л-

Время включения SC

206

ф-л-

Время выключения SC

Рисунок F.21 — Устройство с одной операцией с отдельными элементами устройства типа «Бункер», штанга представлена корневым элементом устройства

Атрибут текущего технологического процесса и атрибут «экземпляр элемента данного типа» также помогают в процессе переноса выполнения задачи ТС-GEO с одного устройства на другое. Когда устройство с другой структурой используется в полевых условиях или когда существует несоответствие между запланированным и фактическим пулом объектов дескрипторов устройств, то «группы» PDV должны быть переназначены на доступное устройство. ТС должны быть способны обрабатывать переназначения устройств и сопоставлять группы значений заданных технологических данных элементам устройства, имеющим соответствующие атрибуты технологических данных устройства для обработки заданных значений.

Вариантом многооперационного устройства является аппликатор (подкормщик) с несколькими бункерами и единственной штангой. Этот пример приведен на рисунке F.23. С одной штангой может находиться более одного элемента устройства «Бункер», что указывает на то, что все продукты из этих бункеров подаются через эту единственную штангу.

Устройства, которые могут изменять интенсивность расхода на уровне субштанги или секции, должны моделировать эту возможность посредством определения элементов устройства субштанга (sub-boom) или элементов устройства Секция с атрибутами расхода. Заданный и текущий атрибуты расхода, которые в этом случае могут встречаться на двух различных уровнях элементов устройства, указывают на то, что это устройство с одной операцией с двумя управляемыми расходами субштанг. Команды управления расходом, полученные на самом верхнем уровне штанги, должны автоматически передаваться устройством его дочерним функциям. Команды управления расходом, полученные на самом детальном уровне, применяются только к адресуемой функции. Текущий расход на самом верхнем уровне штанги — это среднее значение текущих расходов ее дочерних функций. Пул объектов дескрипторов устройств должен иметь не более одного уровня субштанг, как показано на рисунках F.24 и F.25. Субштанги должны включать в себя полное определение геометрии, включая атрибуты для смещений X и Y и для максимальной ширины рабочей зоны.

На рисунке F.24 показан пример устройства с субштангами с несколькими секциями в субштанге. Рисунок F.25 имеет альтернативную компоновку, где каждая секция имеет контролируемый расход.

SCT

1..П



67

л

Текущая ширина рабочей эоны

135

л

Смещение Y


BIN 1

X

ф-л

Заданный расход

Y

0

Текущий расход

158

фл

Состояние управления д иффере нцированным внесением

142

л

Физическая задержка заданной величины



DET-0


141 Р-® Текущее состояние работы


FUN 1 (представляет штангу 1)


FUN 2 (представляет штангу 2)


141


67


70


Р®

Р®

Р®


Текущее состояние работы


141


160


Текущая ширина рабочей зоны Максимальная ширина рабочей зоны


ф р- Состояние управления секцией


161


Г-®


290 фр-


134


Текущее сокращенное состояние работы

Заданное сокращенное ______состояние работы______

Смещение X


67


70


р® р® р®


Текущее состояние работы


Текущая ширина рабочей зоны Максимальная ширина рабочей зоны


160


। ф р- Состояние управления секцией


161


'290


134


135


Смещение Y


135


205


фР


Время включения SC


205


Г-0


Текущее сокращенное состояние работы заданное сокращенное ______состояние работы______

Смещение X


Смещение Y


206 фР


Время выключения SC


206


фг-фр


Время включения SC

Время выключения SC


158


BIN 1


142


178


179


фР-


Ф-Р


Заданный расход


SCT Т.п



67

Р-

Текущая ширина рабочей эоны

135

Р

Смещение Y


Текущий расход

Состояние управления дифференцированным внесением Физическая задержка заданной ______величины__________ Экземпляр элемента данного ______________типа (0)_______________


Текущий технологический

_______процесс (1)_______


SCT Т.п


67


135





Смещение X

134

Смещение Y

135

157 |^я! Тип соединения


BIN 2


X

фР

Заданный расход

Y

Текущий расход

158

фР

, , Состояние управления дифференцированным внесением

142

Физическая задержка заданной величины

178

Экземпляр элемента данного типа (1)

179

Текущий технологический процесс (2)


Текущая ширина рабочей зоны


Смещение Y


Рисунок F.22 — Устройство с двумя операциями с отдельными элементами устройства «Бункер», штанги представлены элементами устройства «Функция»


DET-0


141

Г-0

Текущее состояние работы



FUN 1 (представляет штангу)


141

Г-0

Текущее состояние работы

67

.Г-0

Текущая ширина рабочей зоны

70

Г-0

Максимальная ширина рабочей зоны

160

Ф-г-

Состояние управления секцией

161

Г-0

Текущее сокращенное состояние работы

290

фг-

Заданное сокращенное состояние работы

134

г-

Смещение X

135

Г-

Смещение Y

205

фг-

Время включения SC

206

Ф-Т-

Время выключения SC





BIN

1..П



141

Г-0

Текущее состояние работы

X

фг-

Заданный расход

Y

0

Текущий расход

142

г-

Физическая задержка заданной величины

178

г-

Экземпляр элемента данного типа (0...П-1))

179

г-

Текущий технологический процесс (...1...)

158

фг-

Состояние управления дифференцированным внесением


Рисунок F.23 — Устройство с несколькими операциями с одной штангой и несколькими элементами устройства «Бункер»


DET-0



FUN

141

Г-0

Текущее состояние работы

67

.П-0

Текущая ширина рабочей зоны

70

-Г-0

Максимальная ширина рабочей зоны

160

Ф-Л-

Состояние управления секцией

161

.Г-0

(екущее сокращенное состояние работы

290

ф^Г"

Заданное сокращенное состояние работы

134

г-

Смещение X

135

_р-

Смещение Y

205

фГ-

Время включения SC

206

Фг-

Время выключения SC

158

фр-

Состояние управления дифференцированным внесением

X

ФГ*

Заданный расход

Y

0

Текущий расход


Смещение X

134

Смещение Y

135

157 l^l Тип соединения


FUN (показывает левую половину штанги)


141

Г-0

Текущее состояние работы

67

Г-0

Текущая ширина рабочей зоны

70

Г-0

Максимальная ширина рабочей зоны

134

Г-

Смещение X

135

г-

Смещение Y

X

фг-

Заданный расход

Y

0

Текущий расход


FUN (показывает правую половину штанги)

141

Г-0

Текущее состояние работы

67

Г-0

Текущая ширина рабочей зоны

70

-П-0

Максимальная ширина рабочей зоны

134

_П-

Смещение X

135

J1-

Смещение Y

X

фГ-

Заданный расход

Y

0

Текущий расход


SCT 1..П


SCT п+1..т


67

г-

Текущая ширина рабочей зоны

135

г-

Смещение Y


67

г-

Текущая ширина рабочей зоны

135

г-

Смещение Y


141

г-0

Текущее состояние работы

Рисунок F.24 — Устройство с одной операцией с несколькими регуляторами расхода в качестве субштанг

DET-0 (действует как штанга)

141

_Л-0

Текущее состояние работы

158

ф_Л-

Состояние управления дифференцированным внесением

X

фг-

Заданный расход

Y

©

Текущий расход

67

_Л-0

Текущая ширина рабочей зоны

70

-F0

Максимальная ширина рабочей зоны

160

ф_Л-

Состояние управления секцией

161

_Р-0

Текущее сокращенное состояние работы

290

ф_Л-

Заданное сокращенное состояние работы

134

_Р-

Смещение X

135

_Р-

Смещение Y


SCT

1..П


67

_л-

Текущая ширина рабочей зоны

134

_Р-

Смещение X

135

_Р-

Смещение Y

X

Ф-Л-

Заданный расход

Y

0

Текущий расход


134

_л-

Смещение X

135

_р-

Смещение Y

157

в)

Тип соединения


Рисунок F.25 — Устройство с одной операцией с несколькими регуляторами расхода в качестве элементов устройства Секция

F.3.5 Пулы объектов дескрипторов устройств TC-SC поколения 1

Первый пример пула объектов дескрипторов устройств, отвечающий требованиям для TC-SC поколения 1, представлен на рисунке F.26. В этом примере корневой элемент устройства действует как штанга и присутствуют необходимые элементы устройства типа Секция и соединитель (Connector) плюс атрибуты геометрии в качестве свойств устройства. Благодаря тому, что геометрия в этом примере присутствует как набор свойств устройства, контроллеру TC-SC не нужно запрашивать их при подключении или отслеживать их изменения во время работы.

F.3.5.1 Рабочее состояние

Текущие и заданные сокращенные состояния работы являются единственными состояниями работы, которые разрешены в DDOP для отчета и управления состояниями работы секции. Отдельные текущие состояния работы (DDI 141) или отдельные заданные состояния работы (DDI 289) не допускаются в элементах устройства секция. Индивидуальный атрибут текущего состояния работы в элементе устройства штанга представляет собой главный рабочий выключатель для этой операции, и он может быть передан «по изменению» и по основному интервалу времени.

Тип измерения «On Change» рекомендуется поддерживать с помощью атрибута заданное сокращенное состояние работы. Это позволяет контроллеру TC-SC настроить измерение для получения подтверждения каждой передаваемой команды сокращенного состояния работы заданной точки.

Типы измерений «Об изменении» и «Интервал времени» должны поддерживаться атрибутами текущего состояния (состояний) работы и текущего сокращенного состояния (состояний) работы.

Текущие значения состояния работы вдоль иерархии элементов устройства должны быть объединены для определения состояния работы каждой секции. В приведенном выше примере если текущее состояние работы в корневом элементе устройства имеет значение «Выключено (OFF)», то даже когда текущее состояние работы секций имеет значение «Включено (ON)», результирующее состояние работы для этих секций обрабатывается контроллером TC-SC как «Выключено (OFF)».

DET-Э (действует как штанга)

141

Г-0

Текущее состояние работы

X

Г-0

Текущий расход

67

Г-0

Текущая ширина рабочей зоны

160

Ф-Г-

Состояние управления секцией

161

_Р-0

Текущее сокращенное состояние работы

290

ф-_Р-

Заданное сокращенное состояние работы

134

©

Смещение X

Рисунок F.26 — Устройство с одной операцией, геометрия в свойствах

F.3.5.2 Ширина рабочей зоны

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

  • а) Текущая ширина рабочей зоны (Actual Working Width) (DDI 67).

  • b) Максимальная ширина рабочей зоны (Maximum Working Width) (DDI 70).

  • с) Ширина рабочей зоны по умолчанию (Default Working Width) (DDI 68).

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

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

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

F.3.5.3 Состояние управления секцией

Для функциональности TC-SC штанга должна включать атрибут данных состояния управления секцией на том же уровне, что и заданные сокращенные состояния работы. Этот атрибут данных состояния управления секцией должен быть настраиваемым и должен поддерживать триггер распознавания при изменении. Штанга, которая не поддерживает TC-SC, не должна содержать атрибут данных состояния управления секцией. В дополнение к спецификации в словаре данных ISOBUS (ISOBUS Data Dictionary) для состояния управления секцией DDI (160) применяются следующие правила:

  • а) При остановке задания клиент ТС должен внутренне установить свое состояние управления секцией в деактивировано/выключено.

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

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

  • г) ТС должен использовать команду измерения «на изменение» для получения изменений состояния управления секцией от клиента ТС.

F.3.5.4 Геометрия устройства

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




67

Текущая ширина рабочей зоны

134

Смещение X

135

Смещение Y

[


134

(Ш)

Смещение X

135

Смещение Y

157

(fi

Тип соединения


DET-0 (действует как штанга)

141

_Р-0

Текущее состояние работы

X

-Р-®

Текущий расход

67

-Р-®

Текущая ширина рабочей зоны

160

Ф-Р-

Состояние управления секцией

161

-Р-®

Текущее сокращенное состояние работы

290

Ф-Р-

Заданное сокращенное состояние работы

134

_р-

Смещение X

Рисунок F.27 — Устройство с одной операцией, геометрия в данных процесса

Для данных геометрического процесса рекомендуется поддерживать измерения типа «On Change». При запуске системы TC-SC должен запросить у устройства его начальные значения геометрии DDI, чтобы убедиться, что для определения команд управления секциями и охватом используется правильная геометрия.

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

TC-SC требует наличия соединения, указывающего точку подключения к трактору. Допускается наличие нескольких соединений. Элементы устройства соединитель (Connector) и навигация (Navigation) должны располагаться только непосредственно под корневым элементом устройства (DET-0). Элементы устройства соединитель (Connector) и навигация (Navigation) должны содержать свойства устройства или данные процесса устройства для смещений X и Y, а также определение типа соединителя.

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

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

F.3.5.5 Задержка управления

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

На рисунке F.29 слева показан пример дескриптора устройства с отдельными атрибутами времени включения управления секцией и времени выключения управления секцией, указанными на уровне штанги. Это рекомендуемый метод указания секций управления включением и выключением задержек в новых конструкциях клиентов TC-SC. Для обеспечения обратной совместимости TC-SC сервер должен быть в состоянии использовать физическую заданную задержку DDI, как показано на правой стороне на рисунке F.2.

DET-D

141

_Р-0

Текущее состояние работа!

Рисунок F.28 — Устройство с одной операцией, варианты атрибутов смещения X

Значения времени включения и выключения SC рекомендуется использовать в дескрипторе устройства, и они должны обрабатываться контроллером TC-SC. Контроллер TC-SC должен вычислить места включенных/вы-ключенных секций на основе полученных значений времени включения и выключения от клиента ТС. Клиент ТС не должен изменять время включения/выключения секции от заявленного времени включения или выключения. Время включения и выключения зависит от физической производительности секций.

DET-0

141

.T-G)

Текущее состояние работы

Рисунок F.29 — Определения задержки управления секцией на уровне штанги (рекомендация по новым конструкциям) и физической заданной задержки времени на уровне секции (требование обратной совместимости)

Последовательная схема цикла включения и выключения секции приведена на рисунке F.30. На этой диаграмме присутствуют как обновления состояния работы секции, передаваемые за временной интервал (при отметках времени Т1, ТЗ, Т5 и Т8), так и за счет изменения состояния (при отметках времени Т2 и Тб). Обратите внимание, что время включения и выключения для секции может быть разным. В этом примере время, необходимое для включения секции (Т4-Т2), больше времени, необходимого для выключения секции (Т7-Т6). Также на этой диаграмме видно подтверждение команды заданного значения сокращенного состояния (Setpoint CWS) обратным сообщением, «обновление». Это ответное сообщение и обновление до текущего состояния, которое будет отправлено клиентом TC-SC немедленно при запуске изменения состояния секции, являются обязательными. Сервер TC-SC несет ответственность за использование времени включения или выключения SC для корректировки сообщаемых изменений состояния работы, например, для обновления видимой зоны на дисплее карты. Последовательность включения первой секции на этой диаграмме запускается обновлением положения 1. Следующее обновление позиции 2 не привело к необходимости изменения состояния секции с положения включено (on) на положение выключено (off) и, таким образом, не привело к передаче команды Setpoint CWS. Обновление третьей позиции запускает последовательность выключения секции.

щего CWS


Обновление положения 1


Команда заданного CWS


Обновление заданного CWS

<£----------------

Включено: обновление текущего CWS_____


Включение состояния работы


___Т2 - запуск изменения состояния работы


j Получение состояния работы


Обновление состояния работы


ТЗ - интервал времени

__на основе текущего обновления состояния работы


DD) 205

Время включения SC


Обновление положения 2


Включено: обновление текущего CWS


___Т4 - полное изменение состояния работы


] Получение состояния работы |


Обновление положения 3


Включено: обновление текущего CWS


Обновление состояния pa6oTbi]j


Тб — интервал времени на основе текущего обновления состояния работы


Команда заданного CWS


Обновление заданного CWS


Выключение состояния работы


Тб - запуск изменения состояния работы


Выключено: обновление


Выключено: обновление текущего CWS

I


текущего CWS


1 L—I

j Получение состояния работы |

Обновление состояния pa6oTbi]j


DDI 206

Время включения SC


Т7 - полное изменение состояния работы Т8 - интервал времени на основе текущего обновления состояния работы


Рисунок F.30 — Схема последовательности включения и выключения секции TC-SC

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

Сервер TC-SC должен использовать время включения SC для опережения своей управляющей команды включения своей секции на величину времени, указанную в этом значении данных процесса. Положительное значение заставляет сервер TC-SC посылать свою команду включения секции раньше к клиенту ТС, чтобы компенсировать задержку включения клиента ТС.

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

Для клиентов ТС, которые предоставляют средства настройки времени включения/выключения SC на своем собственном интерфейсе оператора, рекомендуется поддерживать тип измерения «On Change» для этих значений и передавать обновления на сервер TC-SC, когда оператор корректирует эти значения. Сервер TC-SC должен использовать команды измерения «по изменению» (on-change) для получения обновлений значений от клиентов TC-SC, способных работать с ТС, которые позволяют оператору изменять значения включения и выключения SC в своем интерфейсе оператора.

Для обеспечения обратной совместимости если элементы устройства секции также содержат физическую заданную задержку времени (DDI 142), то значения времени включения и выключения ТС имеют более высокий приоритет, и значение физической заданной задержки времени должно игнорироваться для команд управления секцией. Если в элементе устройства секции задана только физическая задержка заданной величины, то она должна использоваться сервером TC-SC для опережения команд управления включением и выключением секции на заданную задержку. Этот альтернативный сценарий обработки задержки управления изображен на рисунке F.31. В этом случае управляющие задержки включения или выключения секции равны и не могут быть дифференцированы.




134

©

Смещение X

135

©

Смещение Y

157

©

Тип соединения


67


160


161


290


134


135


FUN (действует как штанга)


П-0


Г-0


П-0


-ф-г-

Р-0

-ф-г-

Текущее состояние работы


Текущий расход


Текущая ширина рабочей зоны


Состояние управления секцией


Текущее сокращенное состояние работы


Смещение X

134

Смещение Y

135

157 |^т| Тип соединения



Заданное сокращенное состояние работы


Смещение X


Смещение Y


SCT

1..П


67



Текущая ширина рабочей зоны



134



Смещение X


135



Смещение Y


FUN (действует как штанга)

141

_Р-0

Текущее состояние работы

X

Г-0

Текущий расход

67

_Р-0

Текущая ширина рабочей зоны

160

-ф-т-

Состояние управления секцией

161

_Р-0

Текущее сокращенное состояние работы

290

-ф-г-

Заданное сокращенное состояние работы

134

_п-

Смещение X

135

_п-

Смещение Y



67

_Р-

Текущая ширина рабочей зоны

135

_Р-

Смещение Y


141


FUN {действует как штанга)


_п-0


Текущее состояние работы


Г-0


Текущий расход


67


-П-0


Текущая ширина рабочей зоны


160


ф_Г-


Состояние управления секцией


161


П-0


Текущее сокращенное состояние работы


Смещение X

134

Смещение Y

135

157 [mil Тип соединения


290


ф_г-


Заданное сокращенное состояние работы


134


135



Смещение X


Смещение Y


205


ф-Р-


Время включения SC


206


ф Р-


Время выключения SC




FUN (действует как штанга)

141

_Р-0

Текущее состояние работы

X

-Г-®

Текущий расход

67

-Г-0

Текущая ширина рабочей зоны

160

фг-

Состояние управления секцией

161

-П-0

Текущее сокращенное состояние работы

290

фг-

Заданное сокращенное состояние работы

134

_р-

Смещение X

135

_р-

Смещение Y


Текущая ширина рабочей зоны

134

Смещение Y


142


Физическая задержка заданной величины


Обновление положения

Команда заданного CWS


Обновление заданного CWS


Включение состояния работы


___Т2 - запуск изменения состояния работы


Включено: обновление текущего CWS


{ Получение состояния работы


Обновление состояния работы


Т3 - интервал времени на основе обновления текущего состояния работы


DD1142 Физическая задержка заданной величины



Включено: обновление текущего CWS

___Т4 - завершение изменения состояния работы


Рисунок F.31 —Альтернатива обработки задержки управления физической задержкой заданной величины

F.3.5.6 Несколько штанг и несколько продуктов

Примером TC-SC совместимого устройства с несколькими штангами является дескриптор, представленный на рисунке F.32. Первая функция в этом примере представляет собой операцию разбрасывания удобрений, значение атрибута текущего технологического процесса равно 1. Вторая функция представляет собой операцию посева или посадки со значением, равным 2 для атрибута текущего технологического процесса. В случае нескольких штанг атрибут текущего технологического процесса (DDI 179) должен быть помещен в штангу или в базовый элемент устройства «Бункер», чтобы ТС мог идентифицировать различные определения штанги.

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

Пример дескриптора устройства, моделирующего устройство, способное применять несколько продуктов через одну стрелу, представлен на рисунке F.33. С точки зрения TC-SC этот пример имеет одну штангу, которая должна содержать все атрибуты, необходимые для того, чтобы одна штанга была совместимым устройством с TC-SC.

DET-0


141

Г-0

Текущее состояние работы


FUN 1 (представляет штангу 1)

141

Г-0

Текущее состояние работы

67

Г-0

Текущая ширина рабочей зоны

160

ф_Р~

Состояние управления секцией

161

Г-0

Текущее сокращенное состояние работы

290

фг-

Заданное сокращенное состояние работы

134

_р-

Смещение X

135

_р-

Смещение Y

205

фг-

Время включения SC

206

ф_р-

Время выключения SC


к


FUN 2 (представляет штангу 2)


141

_П-0

Текущее состояние работы

67

Г-0

Текущая ширина рабочей зоны

160

ф-Р-

Состояние управления секцией

161

Г-0

Текущее сокращенное состояние работы

290

фг-

Заданное сокращенное состояние работы

134

_р-

Смещение X

135

JT-

Смещение Y

205

ф_Р-

Время включения SC

206

ф_Р-

Время выключения SC



134

_п-

Смещение X

135

_Р-

Смещение Y

157

©

Тип соединения



BIN 2


X

ф_п-

Заданный расход

Y

Г-0

Текущий расход

158

фг-

Состояние управления дифференцированным внесением

142

_Р-

Физическая задержка заданной величины

178

_р-

Экземпляр элемента данного типа (0) (0)

179

-Р-

Текущий технологический процесс Л)



X

ф_Р~

Заданный расход

Y

_F0

Текущий расход

158

фг-

Достояние управления дифференцированным внесением^

142

Г-

Физическая задержка заданной величины

178

JP-

Экземпляр элемента данного типа (1) (0)

179

JP-

Текущий технологический процесс (2)




67

_Р-

Текущая ширина рабочей зоны

135

_Р-

Смещение Y


Рисунок F.32 — Дескриптор устройства управления секциями с несколькими штангами и несколькими продуктами


DET-0

141

Г-0

Текущее состояние работы

Рисунок F.33 — Дескриптор устройства управления многопродуктовой секцией одиночной стрелы

Переход от многоштангового устройства к конфигурации TC-SC с одной штангой представлен на рисунке F.34. Этот пример имеет аналогичную структуру, как пример, приведенный на рисунке F.32, с той разницей, что вторая штанга на рисунке F.34 не является штангой TC-SC. Регулировка уменьшения количества штанг TC-SC требуется для того, чтобы не превышать количество штанг TC-SC, которые поддерживает сервер TC-SC. Общее количество секций, определенных в штангах TC-SC, не должно превышать количество секций, поддерживаемых сервером TC-SC. Разница между штангой, управляемой TC-SC, и штангой, не управляемой TC-SC, заключается в том, что штанга, управляемая TC-SC, должна включать в себя атрибут состояния управления секцией в штанге как настраиваемый и поддерживающий, по крайней мере, измерения при изменении. Штанги, не управляемые TC-SC, не должны включать атрибут состояния управления секцией.

FUN (представляет штангу 1)

141

_п-®

Текущее состояние работы

67

-Г-0

Текущая ширина рабочей эоны

160

Ф-Т-

Состояние управления секцией

161

_п-®

Текущее сокращенное состояние работы

290

фт-

Заданное сокращенное состояние работы

134

_р-

Смещение X

135

_р-

Смещение Y

205

фГ-

Время включения SC

206

фр-

Время выключения SC



134

_п-

Смещение X

135

_п-

Смещение Y

157

Тип соединения



SCT 1..П


I__________________________

BIN

2.п


67

_Р-

Текущая ширина рабочей зоны

135

_Р-

Смещение Y

I'


141

г-©

Текущее состояние работы

X

ф_р-

Заданный расход

Y

г-0

Текущий расход

142

_р-

Физическая задержка заданной величины

178

_р-

Экземпляр элемента данного типа (0...Л-1)

179

_р-

Текущий технологический процесс (...1...)

158

Ф-Р-

Состояние управления дифференцированным внесением


DET-0

141

Л-0

Текущее состояние работы

FUN 1 (представляет штангу 1)

141

_Г-0

Текущее состояние работы

67

Г-0

Текущая ширина рабочей зоны

160

ф-Т-

Состояние управления секцией

161

Г-0

Текущее сокращенное состояние работы

290

ф_П-

Заданное сокращенное состояние работы

134

_р-

Смещение X

135

_р-

Смещение У

205

Ф-Р-

Время включения SC

206

ф_р-

Время выключения SC


FUN 2 (представляет штангу 2)

141

_П-0

Текущее состояние работы

67

Л-0

Текущая ширина рабочей зоны

161

Л-0

Текущее сокращенное состояние работы

134

_р-

Смещение X

135

_р-

Смещение У

205

фг-

Время включения SC

206

ф_р-

Время выключения SC



134

_п-

Смещение X

135

_п-

Смещение У

157

Тип соединения


Текущий расход


Состояние управления дифференцированным внесен ием Физическая задержка заданной величины



X

ф_Р-

Заданный расход

У

_F0

Текущий расход

158

фг-

Состояние управления дифференцированным внесением

142

Физическая задержка заданной величины

178

JP-

Экземпляр элемента данного типа (1)

179

JP-

Текущий технологический процесс (2)




Рисунок F.34 — Несколько штанг, настроенных на один дескриптор устройства управления секцией штанги

Другой вариант применения продукта, в котором продукт может быть применен с различными расходами через одну штангу TC-SC, изображен на рисунке F.35. В этом примере требуется промежуточная функция уровня элемента устройства для представления различных расходов каждой части стрелы. Для использования сокращенных состояний работы эффективно по всей штанге определение штанги TC-SC должно располагаться в родительском элементе регулирования расхода частей штанги. Состояние управления секцией, текущее сокращенное состояние работы и заданное сокращенное состояние работы должны быть указаны в самом верхнем уровне штанги. В этом примере допускается максимум 1 уровень субштанги.

DET-0

141

Г-0

Текущее состояние работы

FUN

141

_Р0

Текущее состояние работы

67

Текущая ширина рабочей зоны

160

ф_р

Состояние управления секцией

161

Текущее сокращенное состояние работы

290

фР-

Заданное сокращенное состояние работы

134

Смещение X

135

р-

Смещение Y

205

Ф_р

Время включения SC

206

ф_р

Время выключения SC

158

фт1-

Состояние управления дифференцированным внесением

142

Физическая задержка заданной величины

X

Ф-Р

Заданный расход

Y

_рф

Текущий расход



134

Смещение X

135

Смещение Y

157

&

Тип соединения


FUN 2 (представляет левую половину штанги)

141

_Р®

Текущее состояние работы

67

_Р0

Текущая ширина рабочей зоны

134

Смещение X

135

Смещение Y

X

фр-

Заданный расход

У

_Р0

Текущий расход


FUN 2 (представляет правую половину штанги)

141

_Р0

Текущее состояние работы

67

Текущая ширина рабочей зоны

134

Смещение X

135

Смещение Y

X

ф.Р

Заданный расход

У

_Р0

Текущий расход




SCT

1,.п


SCT п+1..т


67

Текущая ширина рабочей зоны

135

Смещение Y


Текущая ширина рабочей зоны


135


Смещение Y


Рисунок F.35 — Дескриптор устройства управления многопродуктовой секцией одиночной штанги

F.3.5.7 Изменяемая геометрия

Атрибут смещения Y штанги TC-SC с несколькими секциями не должен изменяться, если нижележащие секции включены или выключены. Пример, изображенный на рисунке F.29, содержит атрибуты смещения Y как на уровне штанги TC-SC, так и в элементах устройства раздела. Значение атрибута смещения Y в этом случае должно быть центром штанги и не должно изменяться, например, при выключении левой части секций.

Примером, требующим динамического обновления значения атрибута смещения Y для корректного представления зоны охвата, является дескриптор устройства, представленный на рисунке F.36. К примеру, для устройства, которое срезает растительную массу с помощью режущего механизма, который может быть использован частично и может срезать урожай либо с левой стороны, либо с правой стороны спереди. В этом случае, если ре-

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


67

1^0

Текущая ширина рабочей зоны

134

г-

Смещение X

135

_р-

Смещение Y


134

Г-

Смещение X

135

_п-

Смещение Y

157

fil

Тип соединения


Рисунок F.36 — Односекционный, динамический атрибут смещения Y, дескриптор устройства

F.3.5.8 Фактическая рабочая длина

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

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

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

DET-0

141 Г-0 Текущее состояние работы у

FUN (действует как штанга)

141

-Г-0

Текущее состояние работы

X

Г-0

Заданный расход

67

Г-0

Текущая ширина рабочей зоны

160

ф_п-

Состояние управления секцией

161

Текущее сокращенное состояние работы

290

-ф-т-

Заданное сокращенное состояние работы

226

Г-0

Текущая длина рабочей зоны

134

_р-

Смещение X

135

-Р-

Смещение Y


141



67


160


161


290


226


134


135


FUN (действует как штанга)


Г-0 Г-0

■Г-0 ф-Г Г-0 фг Тчз


Текущее состояние работы


Заданный расход


Текущая ширина рабочей зоны


Состояние управления секцией

Текущее сокращенное состояние работы

Заданное сокращенное состояние работы

Текущая длина рабочей зоны



Смещение X


Смещение Y



134

_П-

Смещение х

135

_р-

Смещение Y

157

®|

Тип соединения




Рисунок F.37 — Пример добавления атрибута текущей длины рабочей зоны

F.3.6 Пулы объектов дескриптора устройства LOG поколения 1

Самая простая версия LOG поколения 1 соответствует пулу объектов дескриптора устройства, показанного на рисунке F.38. Этот дескриптор устройства содержит только один атрибут, который представляет собой общее эффективное время за срок службы. Обратите внимание, что общий срок службы DDI не может быть установлен сервером ТС или DL, и, следовательно, с ним не связан настраиваемый фон. Символ измерения временного интервала указывает, что этот общий DDI может быть запрошен для передачи через определенный интервал времени.

DET-0

274

^0

Общее эффективное время за срок службы

Рисунок F.38 — Устройство с одной операцией без элемента устройства «Функция» и без информации о геометрии

Устройства, которые включают расход DDI, должны предоставлять соответствующий жизненный цикл общего DDI для расхода (рисунок F.39).

Пулы объектов дескриптора устройства, изображенные до этого, не имели элемента функционирования устройства, отдельного от корневого элемента устройства. Это разделение показано на рисунке F.40 для самого базового дескриптора устройства с отдельным элементом функционирования устройства.

DET-0

274

Общее эффективное время за срок службы

X

фГ-

Текущий расход

Y

Общий расход за срок службы

Рисунок F.39 — Устройство с одной операцией с фактическим DDI расхода без элемента устройства «Функция» и без информации о геометрии


274

Общее эффективное время за срок службы

Рисунок F.40 — Устройство с одной операцией с отдельным элементом устройства «Функция»

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



Рисунок F.41 — Однооперационное устройство с фактической скоростью и рабочей шириной DDI и отдельным элементом устройства «Функция»

Общие значения могут быть представлены в нескольких элементах устройства. На рисунке F.42 приведен пример жизненного цикла общего времени, доступного для устройства, указанного в корневом элементе устройства, а также жизненного цикла общего времени, записанного для конкретного элемента устройства «Функция». Каждый жизненный цикл общего времени обновляется на основе логики элемента устройства, в котором он указан. Все общие жизненные циклы на уровне функции не обязательно должны совпадать с общим жизненным циклом уровня устройства. Для функциональности LOG 1-го поколения жизненный цикл общего времени DDI на уровне устройства является обязательным, любые жизненные циклы общего времени внутри других элементов устройства являются необязательными.

Рисунок F.42 — Общее время присутствует на уровне Устройства и уровне Функция

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

Вместо общего элемента устройства «Функция», в качестве атрибутов элемента устройства «Бункер» также могут быть заданы значения DDI расхода и связанные с ними итоговые значения за срок службы. Два примера этих пулов объектов дескрипторов устройств приведены на рисунке F.43. В этом примере рекомендуется использовать информацию о расходе и ширине рабочей зоны. Корневой элемент устройства представляет собой штангу устройства. Расположение элементов устройства «Бункер» в качестве дочернего элемента штанги указывает на то, что продукт из этого бункера распределяется через эту штангу. Не допускается иметь одинаковый DDI расхода, прикрепленный как к корневому элементу устройства, так и к элементу «Бункер». Жизненный цикл общего времени в корневом элементе устройства является обязательным, и жизненный цикл общего DDI расхода должен располагаться в том же элементе устройства, который имеет фактический DDI расхода.

Рисунок F.43 — Устройство с одной операцией с элементом устройства «Бункер»

Рисунок F.44 расширяет рисунок F.43, добавляя вторичную операцию к устройству и отдельным элементам устройства «Функция», которые представляют собой две независимые штанги для применения продукта. В этом примере каждый элемент устройства «Функция» представляет собой штангу. Расположение элементов устройства «Бункер» в качестве дочерних элементов штанги указывает на то, что продукты из этих бункеров распределяются через эти штанги. Один и тот же расход DDI не должен возникать как в элементах устройства «Функция», так и в элементах устройства «Бункер» и не должен быть присоединен одновременно к элементу корневого устройства и элементу устройства «Функция» штанги.

Первая функция слева на рисунке F.44 представляет собой операцию внесения удобрений (текущий технологический процесс DDI имеет значение 1) — вторая функция представляет собой операцию посева или посадки (текущий технологический процесс DDI имеет значение 2). Итоговые значения за срок службы внутри корневого элемента устройства представляют собой общие итоговые значения за срок службы устройства. Общие значения за срок службы в элементах устройства «Функция» представляют собой только общие значения для каждой операции. Сумма общих значений уровня функционирования не обязательно совпадает с общими значениями устройства. Общее время за срок службы в корневом элементе устройства является обязательным. Общее время за срок службы DDI в элементах устройства «Функция» является необязательным.

В случае нескольких штанг текущая технологическая операция DDI (179) должна быть размещена либо в элементе устройства «Функция» штанги, либо в базовом элементе устройства «Бункер».

Экземпляр элемента данного типа DDI (178) должен использоваться для идентификации бункера оператором, чтобы позволить выбрать, из какого бункера применяется продукт. Это означает, что экземпляр элемента данного типа образец DDI должен быть помещен внутри элемента устройства «Бункер».

Рисунок F.44 — Сеялка с несколькими операциями с двумя функциями и двумя бункерами

Использование текущего технологического процесса DDI дополнительно иллюстрируется на рисунке F.45. В этом примере пула объектов дескриптора устройства пресс-подборщика текущий технологический процесс DDI имеет значение 5 и идентифицирует это устройство как пресс-подборщик, а, например, не косилку. Без использования текущего технологического процесса DDI эти устройства были бы неразличимы, поскольку класс устройств для пресс-подборщиков и косилок — это кормоуборочные машины.

На рисунке F.46 показан пример дескриптора устройства пресс-подборщика, включающего два уровня подсчета тюков. В этом примере суммарные значения предварительно измельченных и неизмельченных тюков должны равняться значению DDI общего счета тюков.

DET-0

274

^>0

Общее эффективное время за срок службы

179

_р-

Текущий технологический процесс (5)

Рисунок F.45 — Дескриптор устройства пресс-подборщика, класс устройства для уборки кормов

DET-0

270

0-0

Общее количество урожая за срок службы

274

^>0

Общее эффективное время за срок службы

285

^0

Общее количество измельченного за срок службы

286

^0

Общее количество неизмельменного за срок службы

179

_р-

Текущий технологический процесс (5)

Рисунок F.46 — Дескриптор устройства пресс-подборщика, множественные итоговые значения

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

DET-0

272

^>0

Общее эффективное расстояние за срок службы

273

^>0

Общее неэффективное расстояние за срок службы

274

^0

Общее эффективное время за срок службы

275

Общее неэффективное время за срок службы

276

^>0

Общий расход топлива за срок службы

Рисунок F.47 — Дескриптор устройства трактор, множественные итоговые значения

Приложение G (обязательное)

Регистрация времени на основе задач

G.1 Уровни регистрации времени

В соответствии со стандартом ИСО 11783-10 можно использовать два уровня регистрации времени. Первый уровень находится на уровне задачи и может использоваться для регистрации возникновения различных типов времени, через которые может пройти задача. Второй уровень находится на уровне регистрации данных устройства. Каждое устройство может сообщать о таких состояниях, как работа или транспортировка, в ТС или DL, и изменения состояния могут быть зарегистрированы в журнале времени.

G.2 Регистрация времени уровня задачи

В рамках каждой задачи могут быть добавлены временные XML-элементы для регистрации начала, продолжительности и/или остановки различных типов времени. В зависимости от уровня детализации реализации регистрации времени в ТС могут использоваться различные наборы типов времени. В таблице G.1 перечислены определения типов времени, которые могут быть записаны. Таблица G.2 определяет уровни детализации, которые могут быть уточнены при выполнении регистрации времени в настоящем стандарте. На рисунке G.1 приведен пример набора записанных типов времени для минимальных и промежуточных уровней регистрации времени.

Таблица G.1 — Определения типов времени

Тип времени

Определение

2. Предварительный

Время, потраченное на подготовку на ферме, перегон до поля и подготовку на поле. «Предварительное» время начинается, как только задача активирована, и останавливается, когда запускается задача либо с типом времени «Эффективная работа», либо с другим типом времени. Если запись этого конкретного типа времени недоступна, это время будет подпадать под «Неэффективный» тип времени

4. Эффективный

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

«Эффективное» время задачи начинается с момента начала задачи основной работы и содержит время, затраченное на основную работу. Этот тип времени является минимальным требованием для обеспечения MICS

5. Неэффективный

Это время, когда задача основная/эффективная работа не активна. «Неэффективное» время можно использовать между периодами «Эффективного» времени

6. Ремонт

Это время, выделенное на ремонтные работы во время выполнения задачи. Если запись этого конкретного типа расписания недоступна, это время будет подпадать под «Неэффективный» тип времени

7. Очистка

Запускается, как только «Эффективная работа» останавливается в последний раз во время выполнения задачи, и останавливается, когда задача остановлена. Если запись этого конкретного типа времени недоступна, это время будет подпадать под «Неэффективный» тип времени

8. Отключено питание

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

Таблица G.2 — Уровни регистрации времени

Уровень

Типы времени, поддерживаемые MICS

Описание

1. Минимальный

4. Эффективный

Минимальное требование — обеспечить запись времени только с этим типом времени для задачи. Сумма всех эффективных временных XML-элементов в задаче — это общее рабочее время этой задачи

2. Промежуточный

2. Предварительный.

  • 4. Эффективный.

  • 5. Неэффективный.

  • 6. Ремонт.

  • 7. Очистка.

  • 8. Питание отключено

Обнаружение основной работы позволяет автоматически регистрировать время типов 2,4,5 и 7. Обнаружение основной работы может использовать информацию о состоянии работы от устройств, выделенных для задачи. Тип времени 6 может потребовать от оператора ввода, а тип времени 8 может быть записан автоматически на основе информации, транслируемой по шине инструмента

Старт задачи


Остановка задачи


1 Минимальный 2 Промежуточный

Эффективный (общее рабочее время)

Предварительный

Эффективный

Неэффективный

Эффективный

Неэффективный

Эффективный

Очистка


Рисунок G.1 — Пример регистрации времени на двух уровнях детализации

G.3 Регистрация времени на уровне устройства

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

Таблица G.3 — Объекты времени словаря данных

DDI

Объект

Определение

Единица измерения

119

Эффективное общее время

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

с

120

Неэффективное общее время

Накопленное время вне рабочего положения или в состоянии покоя

с

Примечание — Плуг может находиться в рабочем положении, когда трактор не движется. Когда трактор не движется, это не «Эффективное» время, а «Неэффективное».

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

Стандарты ИСО 11783-7 и SAE-J1939 также перечисляют группы параметров, из которых можно получить информацию, относящуюся к записи времени. Примерами таких групп параметров являются «Теоретическая скорость и расстояние» и «Реализовать команду рабочего состояния».

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

Сведения о соответствии ссылочных международных стандартов национальным стандартам

Таблица ДА.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 11783-11

IDT

ГОСТ Р ИСО 11783-11—2021 «Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 11. Словарь элементов мобильных данных»

ISO 11783-12

IDT

ГОСТ Р ИСО 11783-12—2021 «Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 12. Диагностические службы»

ISO 11898-1

IDT

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

ISO/IEC 10646

*

  • * Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Перевод данного международного стандарта находится в Федеральном информационном фонде стандартов.

Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов:

  • - IDT — идентичные стандарты.

Библиография
  • [1] SAE Л 939, Recommended Practice for a Serial Control and Communications Vehicle Network

  • [2] AEF (Ag Industry Electronics Foundation, http://www.aef-online.org), guidelines on the definition of ISOBUS functionalities

  • [3] ISO 19136:2007, Geographic information — Geography Markup Language (GML)

УДК 631.3:006.354

ОКС 65.060.01


Ключевые слова: тракторы и машины сельскохозяйственные; последовательная сеть управления и передачи данных; контроллер задачи и обмен данными информационной системы управления

Редактор В.Н. Шмельков Технический редактор И.Е. Черепкова Корректор Л. С. Лысенко Компьютерная верстка Е.О. Асташина

Сдано в набор 12.11.2021. Подписано в печать 13.12.2021. Формат 60x84%. Гарнитура Ариал. Усл. печ. л. 21,39. Уч.-изд. л. 19,25.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано в единичном исполнении в ФГБУ «РСТ» , 117418 Москва, Нахимовский пр-т, д. 31, к. 2.

1

Недоступное значение для этого атрибута введено в ИСО 11783-10 версии 2. Клиенты должны игнорировать этот атрибут при обработке сообщений о состоянии ТС.