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

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

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

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

Часть 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 — Статус задачи

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

• 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 = DFFE₁₆). Каждая группа параметров может содержать несколько значений, и поэтому должны указываться как номер группы параметров, так и начальный и конечный бит для получения одного значения из поля данных шины данных 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 могут встречаться в системе, и они определяются и описываются в следующих случаях.

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

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

Добавить дескриптор устройства в файл передачи данных Добавить 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 = DFFF₁₆). В рамках механизма регистрации данных по умолчанию клиенты отвечают за отправку данных, которые клиенты хотят регистрировать, с интервалом и с помощью триггеров, указанных клиентом. Примеры случаев, для которых определяется этот механизм протоколирования данных, приведены ниже:

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

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

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

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

Пример 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 данных процесса 8D₁₆ и 43₁₆ являются частью набора данных по умолчанию. Это устройство поддерживает механизм данных процесса запроса по умолчанию, который указывается 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^ ТС сохраняет значение А₁ в Data Log 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Клиент 1 отправляет значение DDIА₃: ТС добавляет значение А₃ в 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).

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

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

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

Сообщение о задаче рабочего набора (интервал 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. Схема основана на определениях https://www.w3.org/2001/XMLSchema и типах данных. Схема ISO11783_TaskFile не имеет специфического для ИСО 11783 пространства имен. XML Schemas публикуются по адресу местоположения: //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 публикуются в Интернете по адресу: //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-элементов и сокращения

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

Любой 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 = ’’https://www.w3.org/2001/XMLSchema-instance” xsknoNamespaceSchemaLocation = ”... ” DataTransferOrigin = ”...” >

</ISO11783_TaskData >

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

--'.AFE %

’ 0..®

г-^bsn’"^

! 0..®

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

: о..® о..® Ох

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 — Определения значений записи двоичного файла

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

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

Примечание — Двоичное представление для передачи данных точек введено в стандрате ИСО 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

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

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

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

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

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

• - DeviceProcessDataObject

• - DevicePropertyObject

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

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

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

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

А.4.1 Метод запуска данных процесса устройства — временной интервал

Устройство может предоставлять эти данные процесса на основе временного интервала.

А.4.2 Метод запуска данных процесса устройства — интервал расстояний

Устройство может предоставить данные процесса, основанные на интервале расстояний.

А.4.3 Метод запуска данных процесса устройства — пороговые значения

Устройство может предоставлять эти данные процесса на основе превышения порогового значения.

АЛЛ Метод запуска данных процесса устройства — при изменении

Устройство может предоставлять эти данные процесса при изменении их значения.

А.4.5 Метод запуска данных процесса устройства — общее значение

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

А.5 Определение DevicePropertyObject

DevicePropertyObject — это объектное определение XML-элемента DeviceProperty.

Каждый объект содержит единственное определение DeviceElementProperty (см. таблицу А.4).

Ссылочный дочерний объект: DeviceValuePresentationObject.

Таблица А.4 — Определение DevicePropertyObject

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

А.6 Определение DeviceValuePresentationObject

DeviceValuePresentationObject — это объектное определение XML-элемента DeviceValuePresentation. Этот объект содержит информацию о представлении для отображения значения объекта DeviceProcessData или De-viceProperty. Устройство может обновлять эти объекты при изменении оператором языка и/или единиц измерения (см. таблицу А.5).

Ссылочные дочерние объекты: отсутствуют.

Таблица А.5 — Определение DeviceValuePresentationObject

А.7 Структура объектов

Рисунок А.1 иллюстрирует иерархию объектов, связанных с устройством. Пул объектов дескрипторов устройств должен содержать только один объект устройств и может иметь несколько объектов DeviceElement, DeviceProcessData, DeviceProperty и DeviceValuePresentation. На объекты DeviceProcessData и DeviceProperty можно ссылаться из нескольких объектов DeviceElement. На объект DeviceValuePresentation можно ссылаться из нескольких объектов DeviceProcessData или DeviceProperty.

Рисунок А. 1 — Объектные отношения дескриптора устройства

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

Определения сообщений

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

  • В.1.1 Сообщение данных процесса

Сообщение Process Data используется для передачи данных дескриптора устройства, измеренных данных и/или команд заданных значений одному или нескольким контроллерам. Первый полубайт первого байта сообщения идентифицирует команду или действие, которые требуется выполнить контроллеру (контроллерам). Остальная часть сообщения данных процесса для команд 0₁₆ и 1₁₆ отличается от остальной части сообщения данных процесса команд от 2₁₆ до А₁₆ и от D₁₆ до F₁₆. В таблице В.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 определяется как:

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

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

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

Таблица В.1 — Команды данных процесса

• В.З Команды значений и измерений
  
  В.3.1 Поля параметров

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

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

• В.3.2 Номер элемента

Номер элемента представляет собой 12-битное поле, которое содержит байт 1, биты с 5 по 8 и байт 2. Он указывает конкретный управляемый элемент, который должен действовать по команде. Набор номеров определяется в дескрипторе устройства. Синтаксис {номер элемента, родительский номер} используется для описания конфигурации.

Длина данных: 12 бит

SPN:

Пример. Опрыскиватель с 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 Значение переменной процесса

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

4 байта

в соответствии с определением объекта словаря данных в соответствии с определением объекта словаря данных 5202

• В.4 Сообщения о назначении одноуровневого управления

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

Примечание — Номер элемента назначения в байтах 5 и 6 используется только в том случае, если типом назначения является «Передача». Номер элемента является номером дескриптора устройства пользователя заданного значения. Это значение должно использоваться источником заданного значения в сообщении данных процесса «Команды значения», отправляемом пользователю заданного значения. Для сообщений назначения получателя установить номеру элемента назначения значение FFF16. Существует только один DDI, потому что он должен быть одним и тем же для дескриптора устройства CF источника заданного значения и дескриптора устройства CF целевого контроллера для возможности назначения посредством ТС.

Ответ о назначении производится путем отправки того же сообщения обратно к ТС с типом назначения (байт 5, биты с 4 по 1), измененным на корректное значение. Битам с 8 по 5 байта 5 установлено значение F₁₆, а байтам с 6 по 8 — значение FF₁₆, и сообщение отправлено как единый пакет. Только одно сообщение, о присвоении или отмене назначения, должно быть отправлено к CF до наступления ответа или времени ожидания.

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

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

• В.5 Сообщения технических данных
  
  В.5.1 Общие положения

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

  • В.5.2 Сообщение запроса версии

Сообщение запроса версии позволяет ТС, DL и клиенту определить версию ИСО 11783-10 реализации.

Байт 5: Байт 2 предусмотренных опций

Биты с 1 по 8 = 0 = Зарезервировано для назначения ISO. Определение этого байта

введено в стандарте ИСО 11783-10 версии 3, значением для ИСО 11783-10 версии 2 и более ранних является FF₁₆

Байт 6: Количество штанг для управления секциями. Если сообщается ТС, то это максимальное

поддерживаемое количество штанг для управления секциями³. Если сообщается клиентом, то это количество штанг для управления секциями, которым может управлять клиент³. Штанга для управления секциями определяется как элемент устройства, который ссылается на DDI состояния управления секцией в одном из своих объектов данных процесса устройства (см. F.3.5.3). Определение этого байта введено в стандарте ИСО 11783-10 версии 3, значением для ИСО 11783-10 версии 2 и более ранних является FF₁₆.

Байт 7: Количество секций для управления секциями. Это общее количество секций всех штанг. Если

сообщается ТС, то это максимальное количество секций, которое поддерживается³. Если сообщается клиентом, то это количество секций, которым может управлять клиент³. Определение этого байта введено в стандарте ИСО 11783-10 версии 3, значением для ИСО 11783-10 версии 2 и более ранних является FF₁₆.

Байт 8: Количество каналов управления для управления по положению. Если сообщается ТС, то это

максимальное количество отдельных каналов управления, которое поддерживается³. Если сообщается клиентом, то это количество отдельных каналов управления, которым может управлять клиент³. Канал управления по положению определяется как элемент устройства, который ссылается на DDI состояния управления дифференцированным внесением в одном из своих объектов данных процесса устройства (см. F.3.4.4). Определение этого байта введено в стандарте ИСО 11783-10 версии 3, значением для ИСО 11783-10 версии 2 и более ранних является FF₁₆.

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

• В.5.5 Ответное сообщение об идентификации контроллера задач

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

Примечание 1 — ТС без графического интерфейса может существовать, и в этом случае номер экземпляра может не отображаться.

Примечание 2 — Это сообщение действительно для управляющей функции CF.

Примечание 3 — Это сообщение доступно в стандарте ИСО 11783-10 версии 4 и более поздних.

• В.6 Сообщения дескриптора устройства
  
  В.6.1 Общие положения

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

  • В.6.2 Сообщение запроса обозначения структуры

Сообщение запроса обозначения структуры позволяет клиенту определить доступность запрошенной структуры дескриптора устройства в ТС или DL. Если запрошенное обозначение структуры присутствует, сообщение об обозначении структуры с запрошенным обозначением структуры должно быть передано ТС или DL отправителю сообщения запроса обозначения структуры. В противном случае сообщение об обозначении структуры с 7 байтами обозначения структуры, которым присвоено значение = FF₁₆, должно быть передано ТС или DL отправителю сообщения запроса обозначения структуры.

Если байты с 2 по 8 передаются как FF₁₆, то сообщение запроса обозначения структуры позволяет клиенту определить версию последней структуры дескриптора устройства, присутствующей в ТС или DL. Если обозначение структуры отсутствует, то сообщение об обозначении структуры с 7 байтами обозначения структуры, которым присвоено значение = FF₁₆, должно быть передано ТС или DL отправителю сообщения запроса обозначения структуры. Этот метод является обратно совместимым с ИСО 11783-10 версии 3 и предыдущими версиями.

• В.6.3 Сообщение обозначения структуры

Сообщение обозначения структуры отправляется ТС или DL для информирования клиента о наличии запрошенной версии структуры дескриптора устройства в ТС или DL.

• В.6.4 Сообщение запроса обозначения локализации

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

Если байты с 2 по 8 передаются как FF₁₆, то сообщение запроса обозначения локализации позволяет клиенту определить версию локализации последнего дескриптора устройства, присутствующего в ТС или DL. Если обозначение локализации отсутствует, то сообщение обозначения локализации со всеми байтами обозначения локализации, которым присвоено значение FF₁₆, должно быть передано ТС или DL отправителю сообщения за-

• В.6.5 Сообщение об обозначении локализации

Сообщение запроса обозначения локализации отправляется ТС или DL для информирования клиента о наличии запрашиваемой версии локализации дескриптора устройства на ТС или DL.

• В.6.6 Сообщение запроса передачи пула объектов

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

В.6.7 Ответное сообщение на запрос передачи пула объектов

• В.6.8 Сообщение о передаче пула объектов

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

• В.6.10 Сообщение о включении/выключении пула объектов

Это сообщение отправляется клиентом для завершения процедуры подключения к ТС или DL или для отключения от ТС или DL.

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

Для отключения от ТС или DL это сообщение отправляется со значением байта атрибута команды, установленным на «Деактивировать». Это указывает на то, что клиент намеренно отключается от ТС или DL.

Определение значения байта атрибута команды для деактивации подключения к ТС или DL было введено в стандарте ИСО 11783-10 версии 4.

• В.6.11 Ответное сообщение о включении/выключении пула объектов

Это сообщение отправляется ТС или DL клиенту для подтверждения сообщения о включении/выключении пула объектов дескриптора устройства.

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

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

После успешного выключения пула объектов дескриптора устройства ТС или DL должны ответить байтом 2, установленным для указания отсутствия ошибок. Максимальное время отклика — 2 с.

Байты 5, 6: Идентификатор объекта неисправного объекта, передайте как

нулевой идентификатор объекта, если нет ошибок пула объектов

Байт 7: Коды ошибок пула объектов (0 = нет ошибок)

Бит 1=1= Метод или атрибут не поддерживаются ТС или DL

Бит 2 = 1= Ссылка на неизвестный объект (отсутствующий объект)

Бит 3 = 1= Прочая ошибка

Бит 4 = 1= Пул объектов дескриптора устройства был удален из кратковременной памяти

Биты с 5 по 8 = Зарезервировано, передавать как 0 (ноль)

Байт 8: Зарезервировано, передавать как FF₁₆ ^а Определение этого бита введено в ИСО 11783-10 версии 4.

• В.6.12 Сообщение об удалении пула объектов

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

Могут быть удалены только пулы объектов дескриптора устройства, определенные клиентом. Пулы объектов дескриптора устройства, полученные от FMIS, не затрагиваются.

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

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

В.6.13 Ответное сообщение об удалении пула объектов

^а Определение этого байта введено в стандарте ИСО 11783-10 версии 4, в стандарте ИСО 11783-10 версии 3 и более ранних версиях; этот байт передавался как FF₁₆.

В.6.15 Ответное сообщение об изменении обозначения

• В.7 Сообщение подтверждения данных процесса (PDACK)

Это сообщение отправляется Мастером клиента или ТС или DL для подтверждения или отклонения команд и данных процесса. Причины приведены в наименее значимом байте значения данных процесса. Когда сообщенный код ошибки данных процесса не связан с конкретным номером элемента или определенным DDI, значения номера элемента или DDI должны быть установлены на «недоступно». Значение «недоступно» для номера элемента равно FFF₁₆, а значение «недоступно» для DDI равно FFFF₁₆.

Чтобы избежать ненужной загрузки шины, сообщение подтверждения данных процесса с кодом ошибки данных процесса = 0 не должно передаваться в ответ на команды данных процесса: 0₁₆,1₁₆,2₁₆, 3₁₆,9₁₆, D₁₆, Е₁₆ и F₁₆.

³ Определение этого бита введено в ИСО 11783-10 версии 4.

^ь Определение этих 4 бит введено в стандарт ИСО 11783-10 версии 4.

• В.8 Сообщения о состоянии

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

• В.8.1 Сообщение о состоянии ТС

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

• В.8.2 Сообщение задачи клиента

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

^а Недоступное значение для этого атрибута введено в ИСО 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).

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

XML-элементы и атрибуты

D.1 XML-элементы

XML-атрибуты XML-элемента описаны в настоящем приложении в таблицах с шестью столбцами: - атрибут, имя XML-атрибута.

• - XML, тег атрибута XML.

• - использование, «г» обозначает обязательный (required), “о” — необязательный (optional).

• - тип, спецификация типа XML-атрибута.

• - длина/диапазон, количество символов или диапазон значений этого атрибута.

• - комментарий, дополнительное объяснение или ограничения на формат атрибута.

Примечание — В XML-атрибутах также перечислены дочерние XML-элементы.

Таблица D.1 — Пример атрибутов XML-элементов

Тип 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

ПРИМЕР 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

ПРИМЕР.

<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

ПРИМЕР.

<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

ПРИМЕР 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 шт/м²”/>

<CCL A=”CCL2” В-”20 шт/м²”/>

<CCL A-”CCL3” В=”30 шт/м²”/>

</ССТ>

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

ПРИМЕР.

<CCG A="CCG1" В=”Сорняки”/>

<ССТ А=”ССТ6” В=”Чертополох” С =” 3” D=”CCG1”>

<CCL A=”CCL37" В=”10 шт/м²”/>

<CCL A=”CCL38” В=”20 шт/м²"1>

<CCL A=”CCL39” В=”30 шт/м²"!>

</ССТ>

D.7 CodedCommentListValue — CCL

Тип:

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

Описание:

XML-элемент CodedCommentListValue (значение списка закодированных комментариев) предоставляет значение для определенного закодированного комментария. Каждое значение CodedCommentListValue всегда принадлежит только одному CodedComment. Одно из значений CodedCommentListValue, принадлежащее CodedComment, может быть указано в CommentAllocation, когда данный CodedComment назначается на задачу. Примерами значений CodedCommentListValue являются наборы типа «низкий», «средний» и «высокий» или определения типа «коды стадий созревания сельскохозяйственных культур».

Указан XML-элементами:

— CommentAllocation

Включен XML-элементом:

— CodedComment

Таблица D.7 — Атрибуты CodedCommentListValue

ПРИМЕР.

<CCL A=”CCL37” В=”10 шт/м²”/>

<CCL A=”CCL38” В=”20 шт/м²”/>

<CCL A=”CCL39” В=”30 шт/м²’Т>

D.8 ColourLegend — CLD

Тип:

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

Описание:

XML-элемент ColorLegend (цветовое обозначение) описывает цветовое обозначение, которое может использоваться для отображения значений в различных цветах на картах с координатной сеткой. XML-элемент ColorLegend включает в себя XML-элементы ColourRange, которые определяют цвет, используемый при представлении значения. Атрибут Defaultcolour используется для представления значения в случае, если не указан ColourRange, в который попадает значение.

Указан XML-элементами: — ValuePresentation Включает XML-элемент: — ColourRange

Таблица D.8 — Атрибуты ColourLegend

ПРИМЕР.

<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

ПРИМЕР.

<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

ПРИМЕР 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

ПРИМЕР.

<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

Окончание таблицы D.12

ПРИМЕР 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 — Атрибуты СгорТуре

ПРИМЕР 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

ПРИМЕР 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

ПРИМЕР.

<СРС А=”СРС1” В=”внесение удобрений”>

<OTR A=”OTQ1”/>

</СРС>

<СРС А=”СРС2” В=”посев”/>

<СРС А=”СРСЗ” В=”уборка урожая ”/>

D.16 Customer — CTR

Тип:

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

Описание:

XML-элемент Customer (потребитель) описывает потребителя. Потребитель может быть указан в элементах задача, ферма и участок поля. Взаимосвязи между потребителем и фермами и участками поля могут быть множественными. Чтобы определить, какие фермы или участки поля принадлежат конкретному потребителю, значения CustomerldRef всех ферм или участков полей, соответственно, должны быть проверены на соответствие конкретному значению Customerld.

Указан XML-элементами:

• — Task

• — Farm

• — Partfield

Таблица D.16 — Атрибуты Customer

Окончание таблицы D.16

ПРИМЕР.

<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 должно быть установлено в DFFE₁₆ (значение журнала PGN).

Включен XML-элементом:

• — Task

Ссылается на XML-элементы:

• — DeviceElement

Таблица D.17 — Атрибуты DataLogTrigger

Окончание таблицы D.17

ПРИМЕР.

<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 должно быть установлено значение в DFFE₁₆ (значения журнала PGN).

Включен XML-элементом:

• — Time

Ссылается на XML-элементы:

• — DeviceElement

Таблица D.18 — Атрибуты DataLogValue

ПРИМЕР.

<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

ПРИМЕР 1. Метка структуры и метка локализации

Байты 1 и 2 языковой команды содержат код языка. Например, код языка ‘еп’ представлен байтами 65₁₆ и 6Е₁₆, наименее значимый байт в обозначении локализации в этом случае имеет значение 65₁₆.

Порядок байтов в 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

ПРИМЕР 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

ПРИМЕР.

<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

ПРИМЕР.

<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

ПРИМЕР.

<DPD А=”1” В=”1234” С=”3” D=”1”/>

D.24 DeviceProperty — DPT

Тип:

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

Описание:

XML-элемент DeviceProperty (свойство устройства) описывает свойство DeviceElement посредством ссылки и значения для DDL Этот элемент является частью дескриптора устройства.

Ссылается на XML-элементы: — DeviceValuePresentation Указан XML-элементами: — DeviceObjectReference Включен XML-элементом: — Device

Таблица D.24 — Атрибуты DeviceProperty

ПРИМЕР.

<DPT А=”8” В=”1235” С=”-65233”/>

D.25 DeviceValuePresentation — DVP

Тип:

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

Описание:

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

Представленные значения = (целое числовое значение + смещение) * масштаб.

Представленное значение всегда округляют к количеству десятичных чисел, указанных в атрибуте NumberOfDecimals.

Указан XML-элементами:

— DeviceProcessData

— DeviceProperty

Включен XML-элементом:

— Device

Таблица D.25 — Атрибуты DeviceValuePresentation

Окончание таблицы D.25

ПРИМЕР.

<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