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

(утв. и введен в действие Приказом Росстандарта от 21.10.2021 № 1252-ст)

Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 21 октября 2021 г. № 1252-ст

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

ТРАКТОРЫ И МАШИНЫ ДЛЯ СЕЛЬСКОГО И ЛЕСНОГО ХОЗЯЙСТВА

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

ЧАСТЬ 14

УПРАВЛЕНИЕ ПОСЛЕДОВАТЕЛЬНОСТЬЮ

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

(ISO 11783-14:2013, IDT)

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

ОКС 65.060.01

Дата введения 1 января 2022 года

Предисловие

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

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

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

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

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

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

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

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

Введение

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

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

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

ИСО не занимает какую-либо позицию в отношении существования, действительности и объема этого патента.

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

Robert Bosch GmbH

Wernerstrasse 51

Postfach ₃₀ 02 20

D-70442 Stuttgart-Feuerbach

Germany.

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

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

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

Настоящий стандарт устанавливает систему управления последовательностями, такую как система управления разворотами, которая включает совместное функционирование трактора и орудия. Система позволяет записывать несколько последовательностей, активируемых оператором функций с трактора или любой другой функцией управления в сети ИСО 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: General standard for mobile data communication (Тракторы и машины для сельского и лесного хозяйства. Последовательная сеть управления и передачи данных. Часть 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. Виртуальный терминал)

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

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

3.1 прерывание (abort): Остановка воспроизведения последовательности и немедленная остановка всех движений, начатых во время выполнения последовательности.

Пример - Сцепное устройство останавливается в текущем положении.

3.2 активный мастер управления последовательностью (active sequence control master): Мастер управления последовательностью, выбранный оператором для взаимодействия с системой управления последовательностью.

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

3.3 отмена (cancel): Преждевременная остановка записи последовательности.

3.4 команда клиента (client command): Действие, которое передается клиентом управления последовательностью во время записи и выполняется клиентом управления последовательностью, если оно получено во время воспроизведения последовательности.

Пример - Запуск вала отбора мощности (РТО), остановка РТО, открытие заднего люка пресс-подборщика, закрытие заднего люка пресс-подборщика, включение главного клапана опрыскивателя, выключение главного клапана опрыскивателя

3.5 функция клиента (client function): Механическая, гидравлическая или электрическая функция трактора или агрегата, которая может быть включена/выключена, запущена/остановлена или изменена действием оператора и может принимать команды от мастера управления последовательностью во время воспроизведения последовательности.

Пример - РТО, сцепка, дополнительные клапаны, задний люк пресс-подборщика, главный клапан опрыскивателя.

3.6 клиент с отключенным управлением последовательностью (disabled sequence control client): Клиент управления последовательностью, который не реагирует на изменения состояния активного мастера управления последовательностью и, следовательно, не участвует в воспроизведении и записи последовательности.

3.7 клиент с подключенным управлением последовательностью (enabled sequence control client): Клиент управления последовательностью, выбранный активным мастером управления последовательностью для участия в воспроизведении и записи последовательности.

3.8 графическое отображение объекта (graphical representation object): Объект пула объектов SCCWS (рабочий набор клиента управления последовательностью), на который могут ссылаться объекты SCD (определение данных управления последовательностью) в случаях, когда SCM (мастер управления последовательностью) требуется для отображения графической информации о SCC (клиент управления последовательностью), клиентская функция или состояние функции.

Пример - Объект Графическая Картинка, объект Прямоугольник или объект Полигон могут быть использованы для ссылки на атрибут графического представления объекта состояния SCD.

3.9 неактивный мастер управления последовательностью (inactive sequence control master): Мастер управления последовательностью, подключенный к системе, но не контролирующий систему управления последовательностью.

3.10 безопасный режим (safe state): Режим работы системы с приемлемым уровнем риска для оператора или посторонних лиц в случае полного или частичного отказа систем управления.

3.11 клиент управления последовательностью (sequence control client), SCC: Функции управления, подключенные к сети ИСО 11783, которые предоставляют клиентские функции, которые могут использоваться для управления последовательностью.

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

Примечание 2 — Трактор может идентифицировать себя как SCC со своими функциями клиента, как SCM или как SCC и SCM одновременно.

3.12 рабочий набор клиента управления последовательностью; SCCWS (sequence control client working set): Рабочий набор по ИСО 11783-6, в котором или мастер рабочего набора, и (или) один или несколько элементов рабочего набора действуют как SCC.

3.13 определения данных управления последовательностью; SCD (sequence control data definition): Набор объектов, описывающих записываемые функции, передаваемые клиентами управления последовательностями в мастер управления последовательностями, включая идентификаторы функций, идентификаторы состояний, предпочтительный метод запуска, значки для визуализации и имя функции для каждой из поддерживаемых функций.

Примечание 1 — Подробное описание приведено в приложении A.

3.14 мастер управления последовательностью; SCM (sequence control master): Контроллер системы управления последовательностями, которая инициирует фазу записи и воспроизведения последовательностей и сохраняет клиентские команды, полученные от клиентов управления последовательностями во время записи, с одной из предоставленных ему точек запуска.

3.15 пул объектов мастера управления последовательностью; SCMOP (sequence control master object pool): Пул объектов VT (виртуального терминала), отправленный SCM, предоставляющий пользовательский интерфейс для взаимодействия оператора с SCM.

Примечание 1 — VT и пулы объектов рассмотрены в ИСО 11783-6.

3.16 пул объектов клиента управления последовательностью; SCCOP (sequence control client object pool): Пул объектов VT, отправленный SCCWS, содержащий как минимум все объекты, необходимые для SCM для правильного отображения информации из SCD SCC на VT.

Примечание 1 — Эти объекты обычно являются ссылочными в SCMOP.

Примечание 2 — VT и пулы объектов рассмотрены в ИСО 11783-6.

3.17 последовательность управления последовательностью; SCS (sequence control sequence): Набор функций и (или) действий, выполняемых одним или несколькими клиентами управления последовательностями в системе во время фазы записи, включая соответствующую информацию запуска для активации функций.

3.18 система управления последовательностью; SC (sequence control system): Система с мастером контроля последовательности и одним или более клиентами, выполняющая функционал контроля последовательности как описано в данной части ИСО 11783.

3.19 активатор управления последовательностью (sequence control trigger): Способ активировать функции SCC в последовательности управления последовательностью.

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

Пример 2 — Для активатора расстояния SCM использует пройденное расстояние между активацией двух функций в качестве метода активации функции.

3.20 номер последовательности (sequence number): Номер, который однозначно идентифицирует последовательность(и) в связи SC, позволяя использовать несколько последовательностей в одной системе.

Пример - SCM поддерживает одну последовательность для входа на поворотную полосу (порядковый номер = 1) и одну для выхода с поворотной полосы (порядковый номер = 2).

3.21 текстовое отображение объекта (textual representation object): Объект пула объектов SCCWS, на который могут ссылаться объекты SCD в тех случаях, когда SCM необходимо отобразить текстовую информацию о SCC, клиентской функции или состоянии функции.

Пример - Объект Вывод Строки будет подходящим для ссылки на него через атрибут Обозначение SCD.

3.22 номер операции; TAN (transaction number): Способ синхронизации командных и ответных сообщений.

Примечание 1 — Дополнительную информацию см. 4.6.

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

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

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

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

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

Каждая последовательность имеет уникальный номер в SC; однако реализация SCM должна определить, как операторы могут идентифицировать отдельные последовательности в случае поддержки нескольких (например, ассоциировать собственные имена с каждой отдельной последовательностью). SCM может группировать и сохранять несколько последовательностей (например, одну для приближения к краю поля и одну для движения по полю) под уникальным дескриптором, например «Посев». SCM может указывать записанную последовательность (и) в пользовательском интерфейсе с помощью значков и (или) текстовых обозначений, предоставленных SCC, представляющих каждую функцию или действие. В зависимости от реализации SCM оператор может иметь возможность вручную определять последовательности или редактировать последовательности, изменяя время (точку запуска) между функциями клиента или другими параметрами функции. SCM может предоставить оператору возможность сохранять и перезагружать последовательности для последующего использования с использованием той же конфигурации машины (например, конкретной комбинации трактора и агрегата).

SCM должен предоставлять средства для настройки последовательностей (RECORD или EDIT) и для активации воспроизведения выбранной последовательности (PLAY BACK); SCM может предоставлять оператору средства для настройки SCM (CONFIG).

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

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

4.2 Пользовательский интерфейс управления последовательностями

SCM должен предоставлять пользовательский интерфейс для предупреждений и необходимого взаимодействия с оператором, подключаясь к VT и, соответственно, загружая его макет главного экрана (пул объектов) (более подробная информация о VT и пулах объектов определена в ИСО 11783-6).

Чтобы разрешить дополнительные функции SCM, такие как просмотр деталей последовательности, SCC должны предоставлять графическое и текстовое представление своих функций управления последовательностями и т.д. в SCM. Наличие как текстового обозначения, так и графики для каждого объекта SCD дает реализации SCM свободу быть представленным только с текстом, только графиком или их комбинацией для отображения объектов SCC.

В этой концепции связи используется указатель внешнего объекта, представленный в версии VT 5 (подробности определены в ИСО 11783-6), чтобы избежать требования, что SCM должен обрабатывать большие графические объекты или языковые обновления для отдельных SCC. Для этого требуется, чтобы отдельные SCC или мастер их рабочего набора загружали свои графические и текстовые объекты как часть своего SCCOP в тот же VT, который используется SCM, и предоставляли SCM справочную информацию только в своем SCD. SCM добавляет ссылки на внешние указатели объектов в свои маски данных в местах, где такие объекты могут быть показаны. Эти эталонные объекты указывают на объекты в ссылочной SCCOP, чтобы позволить VT отображать нужную информацию на экране SCM.

SCM и мастер рабочего набора SCCWS должны подключиться и загрузить свой пул объектов в VT с экземпляром функции 0, чтобы избежать дополнительных издержек синхронизации на выбранном VT между SCM и его SCC. Однако это может означать, что SCCWS должен поддерживать два соединения VT параллельно в случае, если взаимодействие основного оператора для SCCWS обрабатывается дополнительным VT (экземпляр функции > 0) (см. рисунок 1). Эта концепция использования VT с экземпляром функции 0 следует определениям дополнительного управления в ИСО 11783-6 и позволяет SCCWS объединять и совместно использовать объекты между обеими функциями в одной SCCOP. Он также позволяет SCC использовать различные языки и наборы символов для своего представления, используя возможности, предоставленные в стандарте ИСО 11783-6 (например, использование Unicode в объектах текстового представления) непосредственно между SCC и VT без взаимодействия с SCM.

Рисунок 1 — Концепция коммуникаций пользовательского интерфейса

4.2.1 Инициализация пользовательского интерфейса

Во время инициализации SCM загружает новый или повторно активирует свой предыдущий загруженный пул объектов в VT.

SCM может использовать ссылки на внешние указатели объектов на текстовые и графические объекты в SCCOP своих клиентов для отображения, например, подробностей последовательности (подробности о внешних ссылочных объектах определены в ИСО 11783-6).

Концепция указателя внешнего объекта основана на NAME, чтобы обеспечить надлежащую идентификацию SCCOP и SCCWS в ссылках на объект. SCMOP включает в себя объекты внешнего ссылочного NAME (подробности определены в ИСО 11783-6), чтобы избежать частой передачи полного NAME при каждом изменении ссылки на объект в SCCOP. Связь SCM с VT включает в себя двухбайтовый идентификатор объекта NAME внешней ссылки (см. 22 и 25 на рисунке 3).

У SCM нет средств для проверки типа объекта в отдельных ссылках на объекты, предоставленных в SCD. Он знает только идентификаторы объекта. Следовательно, SCC несет ответственность за обеспечение использования соответствующих объектов для графического и текстового представления. SCM должны предоставить условия для работы с объектными ссылками, отклоненными VT.

Примечание 1 — Несмотря на то, что в один SC может быть включено несколько SCC, и каждый из них предоставляет несколько ссылок на разные графические и текстовые объекты в структуре, как показано на рисунке A.2, следующий пример фокусируется только на SC с одним SCC и два ссылочных объекта для объяснения концепции, применимой ко всем этим объектам, участвующим в реальной системе.

Во время первоначальной загрузки пула объектов SCM в VT объекты External Reference NAME должны быть отключены, а атрибуты объекта External Object Pointer должны быть установлены в NULL Object Id (подробности см. В ИСО 11783-6).

На рисунке 2 показан пример иерархии объектов в пулах объектов, загруженных в VT для простого SCC и SCM, подключенного к VT. Определение 31 представляет SCCOP, включающий один текстовый объект (определение 33) и один графический объект (определение 34) в памяти VT. SCC также загрузил свой SCD (определение 36) в память SCM; в то время как SCM передал свой пул объектов по умолчанию в память VT (определение 21). В этом примере SCM включает два внешних ссылочных указателя в свой макет экрана (один рисунок с определением 23 и один текст с определением 24), оба из которых отключены после запуска.

Рисунок 2 — Пример начального состояния указателя внешнего объекта

Примечание 2 — Определения для рисунков 2 и 3 перечислены под рисунком 3.

SCCWS должен проверить NAME активного SCM с последующим обновлением поля NAME в своем объекте определения внешнего объекта (определение 32) с помощью команды Изменить атрибут. Активация объекта определения внешнего объекта (Option = enabled; определение 32) позволяет VT устанавливать ссылки из SCMOP на определенные объекты, на которые имеются ссылки (определения 37 и 38), в SCCOP (определение 31). Определение 39 на рисунке 2 представляет установленную ссылку на SCMOP.

SCM также должен проверить NAME упомянутых SCC, с последующим обновлением соответствующего поля NAME в своем объекте NAME внешней ссылки. Активация объекта NAME External Reference с помощью команды Change Attribute установила общее соединение с SCCOP. Определение 26 на рисунке 2 представляет собой установленную ссылку на SCCOP.

SCM конфигурирует свои объекты внешнего указателя объекта (определение 23 и 24) с помощью опорных данных, полученных в SCD (определение 36). Обычно, две команды Change Attribute необходимы для объекта внешнего указателя объекта; один для установки идентификатора объекта External Reference NAME (определение 25), чтобы он указывал на правильный WSOP, а второй для установки идентификатора внешнего объекта (определение 27 и 28) желаемого объекта.

На рисунке 2 показаны установленные ссылки на графический объект (например, значок обозначения рабочего набора) и текстовый объект (например, указатель рабочего набора) в SCCOP подключенного SCC. VT находит ссылочную SCCOP для каждого объекта внешнего указателя объекта в компоновке экрана SCM с помощью определения 25 и 26, в то время как определение 39 позволяет проверить, разрешил ли SCC SCM ссылаться на свои объекты. При установленной ссылке на SCCOP идентификаторы внешних объектов однозначно связаны с указанными объектами. Определения 27 и 37 и 28 и 38 представляют это соединение, в то время как прохождение через объект определения внешнего объекта (определение 32) отражает дополнительную проверку для разрешения доступа; только объекты, перечисленные в объекте «External Object Definition», могут быть ссылочными.

1 — энергозависимая память пула объектов VT; 2 — SCM; 20 — энергозависимая память SCM; 21 — Пул объектов SCM; 22 — Объект External Reference NAME, включая NAME ссылочного SCCWS, необходим один объект для каждого ссылочного SCCWS; 23 — External Object Pointer объект для ссылки на графический объект (заполнитель в маске данных); 24 — Объект External Object Pointer для ссылки на текстовый объект (заполнитель в маске данных); 25 — Виртуальная ссылка на объект External Reference NAME для идентификации ссылочного пула объектов на VT; 26 — Виртуальная ссылка на SCCOP, установленный включенным объектом External Object Pointer в SCMOP; 27 — Виртуальная ссылка, например, на значок рабочего набора SCCWS в SCCOP, установленный включенным External Reference NAME и External Object Pointer; ₂₈ - Виртуальная ссылка, например, на указатель рабочего набора SCCWS в SCCOP, установленный включенным External Reference NAME и External Object Pointer; 3 — SCC; 31 — Пул объектов SCCWS; 32 — Объект External Object Definition, определяющий объекты, на которые может ссылаться SCM, указанный в атрибутах NAME 0 и 1; 33 — Обозначение Рабочего Набора SCCWS; 34 — Иконка Рабочего Набора SCCWS; 35 — NAME SCC полученное через Арбитраж Адресов; 36 — SCD подключенного SCCWS; 37 — Виртуальная ссылка на значок рабочего набора, на который может ссылаться SCM; 38 — Виртуальная ссылка на указатель рабочего набора, которая может быть ссылочной SCM; 39 — Виртуальная ссылка на SCMOP, установленная включенным объектом External Object Pointer в SCCOP; 4 — Связь СКМ-ВТ включая загрузку SCMOP и обновления атрибутов; 5 — Связь SCCWS-VT включая загрузку SCCOP и обновление атрибутов; 6 — Связь SCC-SCM включая арбитраж адресов для идентификации NAME и загрузки SCD в SCM

Рисунок 3 — Пример состояния указателей на внешние объекты после инициализации

4.3 Рабочие наборы с конфигурацией мастер/участник

В конфигурациях системы с мастером рабочего набора и одним или несколькими элементами рабочего набора (как определено в ИСО 11783-6) обязанности по соединениям от SCC к VT и от SCC к SCM должны рассматриваться отдельно.

4.3.1 SCC в качестве мастера рабочего набора

В случаях, когда SCC является мастером рабочего набора, SCC отвечает за управление соединением VT, а также за соединение с SCM.

Поле NAME SCCWS в базовом объекте SCD (определенном в A.3) должно быть установлено в NAME самого SCC.

4.3.2 SCC в качестве элемента рабочего набора

В случаях, когда SCC является элементом рабочего набора, мастер рабочего набора SCC отвечает за управление соединением VT (его пул объектов — это SCCOP, включающий графические и текстовые объекты, на которые ссылается SCC в его SCD). SCC отвечает за подключение к SCM (включая загрузку SCD).

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

В поле NAME мастера SCCWS в базовом объекте SCD (определенном в A.3) должно быть указано NAME мастера рабочего набора.

4.4 Функционал управление последовательностью

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

SCM может ограничивать загрузку определений доступа и определения последовательности управления SCC из-за ограничений памяти или других ограничений. SCM должен хранить только один SCD на SCC в энергонезависимой памяти.

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

4.4.1 Рабочие состояния системы управления последовательностью

В следующих пунктах определяются состояния, сообщаемые активными SCM и SCC, а также переходы между ними. Рисунок 3 и рисунок 4 иллюстрируют переходы между различными состояниями SCM и SCC.

4.4.1.1 Работа SCM

Состояния SCM и SCS:

Состояния «Готов», «Запись», «Завершение записи», «Воспроизведение» и «Прервать» считаются активными состояниями, где активный SCM контролирует связь SC.

Отношения между различными состояниями показаны на рисунке 4.

Рисунок 4 — Диаграмма состояний SCM

4.4.1.2 Работа SCC

Состояния SCC:

Состояния «Готов», «Запись», «Воспроизведение» и «Прервать» считаются включенными состояниями SCC, где SCC участвует в обмене данными SC. Состояния «Готов», «Запись» и «Воспроизведение» разрешено вводить только по команде от активного SCM (см. F.3 или E.6). Состояние «Прервать» разрешено вводить по команде от активного SCM (см. F.2), через глобальный SCClientAbort (см. E.3) от другого SCC или от самого SCC.

Пока SCM сообщает о состоянии «Завершение записи», те SCC, которые выполнили свои функции, должны вернуться к «Готово»; только те, кто еще выполняет функцию, должны оставаться в состоянии «Запись» до тех пор, пока функция не будет выполнена. SCC не должны указывать активацию новых функций во время состояния «Завершение записи». Отношения между различными состояниями показаны на рисунке 5.

Рисунок 5 — Диаграмма состояний SCC

4.4.2 Инициализация

При запуске системы SCM и SCC идентифицируют себя как независимые единицы и участники в сети ИСО 11783 (см. ИСО 11783-5 для процесса запроса адреса).

По умолчанию все SCM должны начинаться неактивно, а все SCC должны быть отключены. И SCM, и SCC должны указать свой запуск, отправив сообщение о состоянии (см. F.2 и F.3) с состоянием отправки, установленным на инициализацию. Это позволяет, например, другим участникам общения обнаруживать неожиданные сбросы. Для получения более подробной информации об инициализации SC см. рисунки 6 - 8.

Рисунок 6 — Диаграмма обмена сообщениями инициализации для SCC в качестве мастера рабочего набора

Рисунок 7 — Диаграмма обмена сообщениями инициализации для SCC в качестве элемента рабочего набора

Рисунок 8 — Диаграмма обмена сообщениями инициализации

4.4.2.1 Инициализация SCM

a) SCM должен идентифицировать себя для VT с экземпляром функции 0 и загрузить свой пул объектов. По умолчанию все указатели внешних объектов неактивны (параметры установлены в FFFF16 — подробности см. в определениях в ИСО 11783-6).

b) Все SCM должны оставаться неактивными до тех пор, пока оператор не активирует их, используя свой пользовательский интерфейс. Оператор должен иметь возможность изменить активный SCM в любое время (см. 4.4.4.1).

c) Выбранный SCM должен объявить о своей активации и запуске путем непрерывной отправки сообщения SCMasterStatus (см. F.2), указывающего его активное состояние SCM и соответствующее состояние последовательности.

d) После запуска активный SCM должен удалить всю загруженную информацию SCD из энергозависимой памяти и NACK все входящие сообщения SCClientStatus (см. F.3), кроме указания запуска (см. F.3 SCClientStatus). Сообщения байта 2) до тех пор, пока SCC не укажет на запуск.

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

e) После получения SCDActivationCommand (см. D.8) SCM должен начать синтаксический анализ SCD. SCM указывает на свою активность синтаксического анализа в своем сообщении SCMasterStatus (см. F.2).

4.4.2.2 Инициализация SCC

a) После получения сообщения SCMasterStatus (см. F.2) от активного SCM, SCC должны начать непрерывно отправлять свои сообщения SCClientStatus (см. F.3) с отключенным состоянием. SCC разрешается изменять свое состояние на включенное, только если активный SCM дает команду на включение SCC (см. 4.4.3). Первое сообщение SCClientStatus (см. F.3) должно указывать инициализацию клиента (см. F.3, байт 2).

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

b) SCC должен начать свою инициализацию, запрашивая возможности активного SCM (см. C.2 и C.3), чтобы обеспечить соответствие версии поддерживаемого стандарта SCM и SCC; кроме того, должно быть обеспечено, чтобы пул объектов SCC удовлетворял требованиям SCM в отношении размера графических объектов (см. C.3, байт 3 и 4) или определений шрифта (см. C.3, байты с 5 до 10), чтобы избежать того, что важная информация обрезается VT, если объекты больше, чем определено.

c) Мастер рабочего набора SCC должен идентифицировать себя для VT с помощью экземпляра функции 0 и запросить у этого VT его возможности, такие как цветовые или монохромные или языковые настройки, соответствующим образом адаптировать свой пул объектов (см. ИСО 11783-6) и загрузить его к VT. Если мастер рабочего набора SCC не предоставляет свой собственный пользовательский интерфейс через этот VT, он должен как минимум загрузить SCCOP, чтобы предоставить текстовые и графические объекты для SCMOP.

d) Следующим шагом SCC является проверка наличия SCD в SCM (см. D.2 и D.3). SCM должен использовать информацию маски NAME, предоставленную в базовых объектах SCD (см. A.3), чтобы определить, соответствует ли доступный SCD запрашивающему SCC (см. A.3).

e) Если имеется SCD, соответствующий информации NAME, доступной в SCM, SCC должен проверить ответ версии (например, обновления SW на SCC могут сделать сохраненный SCD недействительным) и конфигурацию машины, отраженную SCD, чтобы убедиться, что SCD представляет клиентские функции, доступные в SCC (см. A.3, D.4 и D.5).

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

f) Если SCC находит соответствующую версию своего SCD в энергонезависимой памяти или если SCC должен загрузить свое SCD, SCC должен отправить SCMasterMemoryRequest (см. C.4), указывающий размер его SCD, который должен быть загружен или разгружен. SCM должен ответить с помощью SCMasterMemoryResponse (см. C.5), включая индикацию состояния, если SCC может начать загрузку SCD, отправив SCDTransfer (см. D.6) или отправить SCDLoadCommand (см. D.14) загрузить SCD в энергозависимую память

1. Если нет доступного SCD или версия и (или) конфигурация, сохраненная в SCM, не соответствуют данным, доступным из SCC, SCC должен загрузить действительный SCD (см. A.3). Если SCC получает SCMasterMemoryResponse (см. C.5), указывающий, что SCM готов принять или загрузить SCD (код состояния 0016), SCC должен начать загрузку своего SCD с использованием SCDTransfer (см. D.6). Если код состояния 0116, SCC не разрешается загружать свой SCD. Обработка этой ситуации является собственностью проекта SCC.

SCM должен ответить с помощью SCDTransferResponse (см. D.7), указывающего на успех или неудачу передачи SCD.

2. Если в энергонезависимой памяти SCM обнаружен действительный SCD, SCC может принять решение об использовании этого SCD. Как только SCC получает SCMasterMemoryResponse (см. C.5), указывающий, что SCM готов принять или загрузить SCD (код состояния 0016), SCC должен отправить SCDLoadCommand (см. D.14), чтобы инициировать загрузку SCD в энергозависимую память, чтобы сделать его доступным для использования SCM.

SCM должен ответить с помощью SCDLoadResponse (см. D.15), указывающего на успех или неудачу загрузки SCD.

g) После успешной передачи или загрузки SCD, SCC должен активировать SCD (см. D.8). Это инициирует анализ целостности SCD в SCM. SCC должен дождаться положительной обратной связи (см. D.9), прежде чем ему будет разрешено продолжить связь SC, отличную от сообщения SCClientStatus (см. F.3).

h) проанализированного SCD в энергонезависимой памяти SCM, посылая SCDStoreCommand (см. D.12). Обработка возможного отрицательного ответа в SCDStoreCommandResponse (см. D.13) зависит от дизайна SCC.

i) указанную в следующих пунктах; однако он должен оставаться в отключенном состоянии до тех пор, пока активный SCM не даст команду на его включение (см. E.2).

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

4.4.3 Поведение состояний SCM/SCC

Активный SCM контролирует состояние системы. SCM должен передать свое фактическое состояние последовательности («Готов», «Запись», «Завершение записи», «Воспроизведение» или «Прервать») в сеть ИСО 11783 в сообщении SCMasterStatus (см. F.2). Включенные SCC должны передавать в своем сообщении SCClientStatus (см. F.3) одно из следующего:

• «Прервать», если SCC необходимо остановить фазу воспроизведения;
• «Запись», если SCC не завершил выполнение своей функции, а состояние SCM — «Завершение записи»;
• «Готово», если SCC завершил выполнение своей функции и состояние SCM — «Завершение записи»;
• то же самое состояние последовательности, которое передается в сообщении SCMasterStatus (см. F.2) во всех других случаях, даже если одна или несколько клиентских функций неисправны.

Во время состояний «Запись», «Завершение записи», «Воспроизведение» и «Прервать» SCM должен отправить номер выбранной последовательности в своем сообщении SCMasterStatus (см. F.2). Порядковые номера, отправленные SCM и SCC, должны использоваться в диагностических целях (т.е. для обнаружения несогласованности SCM и SCC), а реакция является собственностью SCM или SCC. В большинстве случаев порядковый номер, передаваемый SCM и SCC, будет одинаковым.

Активный SCM должен хранить только клиентские команды включенных SCC, отражающих состояние записи, в своем сообщении SCClientStatus (см. F.3). Поведение состояния для фаз «Запись» и «Завершение записи» описано в 4.4.5.2.

Активный SCM не должен отправлять клиентские команды в SCC, если в их сообщениях SCClientStatus не указано состояние «Воспроизведение» или «Готово» (см. F.3). Поведение состояния для фазы воспроизведения описано в 4.4.7.

Активный SCM должен принимать SCClientAbort (см. E.3) только в состоянии «Воспроизведение». Поведение состояния для остановленного воспроизведения указано в 4.4.7.3.

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

Рисунок 9 — Диаграмма обмена сообщениями команды Состояние

4.4.4 Отключение

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

4.4.4.1 Отключение SCM

Для деактивации SCM должен быть в состоянии «Готов».

Чтобы активировать другой SCM, оператор должен деактивировать активный SCM перед активацией нового. Если оператор пытается активировать SCM, в то время как другой SCM все еще активен, в настоящее время неактивный SCM должен проинформировать оператора о первой отмене выбора все еще активного SCM.

После получения ввода оператора для деактивации активный SCM должен продолжать передавать состояние «Готов» в своем сообщении SCMasterStatus (см. F.2), в то время как он отправляет команды для отключения включенных SCC (см. E.2).

После того как все SCC отражают отключенное состояние SCC, SCM должен указать свое неактивное состояние в своем сообщении SCMasterStatus (см. F.2), прежде чем он прекратит отправку своего сообщения о состоянии. Для SCC, не принимающих команду отключения, см. 4.5.3.5. Это позволяет активному SCM стать неактивным и оператор может активировать еще один доступный SCM. Однако, если SCM пропускают это одно объявление, тайм-аут сообщения SCMasterStatus (см. F.2) должен произойти до предположения, что предыдущий активный SCM был деактивирован.

Деактивированные SCM не должны отправлять дальнейшие сообщения SCMasterStatus (см. F.2).

Отключенные SCC не должны инициировать предупреждения оператора о тайм-аутах сообщения SCMasterStatus (см. F.2), но должны интерпретировать исчезающее сообщение SCMasterStatus (см. F.2) как постепенное завершение работы. Соответственно, SCC должны остановить свое собственное сообщение SCClientStatus (см. F.3), пока SCM не инициирует новую связь SC.

4.4.4.2 Отключение SCC

SCC может предоставить средство (например, экран VT, собственный экран, выделенную кнопку и т.д.) Для отключения SCC, например, чтобы вывести SCC из продолжающейся связи SC. Чтобы избежать ненужных предупреждений, когда оператор отключает SCC, SCC должен сначала установить свое состояние в своем сообщении о состоянии как отключенное (см. байт 2 сообщения SCClientStatus по F.3), чтобы соответствующим образом информировать активный SCM. Сообщение SCClientStatus (см. F.3) должно продолжаться до получения первого NACK этого сообщения, чтобы избежать тайм-аутов сообщения SCClientStatus (см. F.3) (см. 4.5.3.6).

4.4.5 Настройка последовательности

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

Пример 1 — Определение последовательности вручную оператором (РЕДАКТИРОВАТЬ).

Пример 2 — Фаза записи, когда команды оператора записываются SCM (ЗАПИСЬ), в то время как оператор активирует каждую желаемую функцию вручную.

SCM может предоставлять оператору средство для включения/выключения SCC для участия в настройке последовательности (в частности, для уменьшения сложности системы во время определения последовательности вручную).

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

Пример 3 — SCM предоставляет 4 входа для активации 4 отдельных последовательностей для определенных операций в поле; этот SCM должен назначить уникальный порядковый номер отдельным последовательностям, назначенным этим входам.

4.4.5.1 Последовательность управления последовательностью

SCS должен состоять из

• NAME, меток версий SCD и меток конфигурации SCD всех SCC, участвующих в SCS
• задания SCC, идентификатора функции SCC, идентификатора состояния, точек запуска и значение функции (см. 4.4.8) для каждого этапа SCS.

4.4.5.2 Запись последовательности

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

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

SCM разрешается входить в состояние «Запись» только тогда, когда присутствуют все разрешенные SCC, и указывать в своем сообщении SCClientStatus (см. F.3), что они «готовы».

Начало фазы записи указывается SCM путем изменения его состояния на «Запись» в сообщении SCMasterStatus (см. F.2). SCC должны следовать за состоянием SCM немедленно, даже когда ClientFunctionErrorState сообщения SCClientStatus (см. F.3) указывает на ошибки в одной или нескольких клиентских функциях. В данный момент должна быть активна только одна SCS и фаза записи.

SCM должен записывать только клиентские функции включенных SCC, отражающих состояние «Запись», в своем сообщении о состоянии. В случае, если SCC не следует состоянию SCM в течение времени ожидания, определенного в F.3, SCM должен предпринять действие, указанное в 4.5.3.4.

Записанные клиентские функции обычно являются ответом на действие оператора во время записи; оператор вручную активирует клиентскую функцию, которая запускает SCExecutionIndication (см. E.4) от SCC к SCM. SCC не должны отправлять SCExecutionIndication (см. E.4) для неисправных функций. SCC может принять решение не сообщать команду клиента в ответ на каждое действие оператора, например, из-за условия, которое временно или постоянно не позволяет функции реагировать на ввод оператора. В некоторых случаях SCC может также выбрать для отчета клиентские команды шагов, которые являются результатом косвенного действия оператора. Например одно действие оператора во время фазы записи может привести к тому, что опрыскиватель поднимает стрелу и перекрывает поток. В этом случае агрегат может сообщить об этом как две отдельные клиентские команды в SCM или как одна составная клиентская команда. SCC обычно не сообщает о командах, которые являются результатом действия/команды из другой системы, такой как контроллер задач.

После начала записи активный SCM должен записать информацию шага, определенную в 4.4.5.1, для каждого полученного SCExecutionIndication (см. E.4) включенных SCC, отражающих состояние «Запись».

SCM должен записывать связанный триггер всякий раз, когда SCC сообщает о начале выполнения функции для клиентской функции (см. подробности в E.4).

Значение функции должно быть записано, когда SCC указывает на завершение выполнения функции (см. подробности в E.4).

Клиентская функция должна быть сохранена в SCS только в том случае, если SCM получает оба указания для «выполнения функции начато» и «выполнения функции завершено».

Для каждой активации функции SCC должен отправлять SCExecutionIndication (см. E.4) в качестве команды клиента в SCM, включая идентификатор функции, идентификатор состояния и значение функции клиентской функции, которая должна быть записана. TAN этой начальной клиентской команды клиентской функции должен быть предыдущим из SCC, увеличенным на единицу.

SCC должен повторять каждую SCExecutionIndication (см. E.4) с одним и тем же TAN с интервалом в 100 мс, пока SCM не перейдет обратно в состояние «Ready», или до истечения времени ожидания (см. F.2), или до SCM подтверждает команду клиента, отправляя SCExecutionIndicationResponse (см. E.5).

Рисунок 10 иллюстрирует процесс сообщения во время записи последовательности.

Рисунок 10 — Диаграмма потока сообщений записи

Клиентская команда SCC может быть одной из следующих:

a) Комбинированная команда запуска и завершения клиента.

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

b) Индивидуальный старт и полный ответ

SCExecutionIndication (см. E.4) должен иметь состояние выполнения функции, равное 01 (выполнение функции началось), когда запущенная функция продолжает работать в течение определенного времени (например, гидравлический цилиндр движется в течение определенного времени).

Когда выполнение клиентской функции завершено (например, гидравлический цилиндр достиг своей целевой позиции), SCC должен указать это, отправив еще один SCExecutionIndication (см. E.4) с тем же содержанием и TAN, что и выше, но выполнением функции состояние установлено на 10 (выполнение функции завершено). Это второе указание может содержать переменную процесса в значении функции, которая должна быть сохранена с командой в последовательности.

c) Индивидуальное начало и завершение, но с ошибкой между ними

Этот сценарий начинается как (b) с SCExecutionIndication (см. E.4), указывающим начало выполнения, но с ошибкой в клиентской функции до его завершения. В этом случае SCC должен отправить второй SCExecutionIndication (см. E.4) с состоянием выполнения функции, установленным в 11 (ошибка во время выполнения), чтобы указать состояние ошибки и тот же TAN, что и в первой клиентской команде. SCC не должен отправлять дополнительный SCExecutionIndication (см. E.4), чтобы указать, что выполнение функции завершено.

Если есть неисправная функция, SCC должен указать эту ошибку также в своем сообщении SCClientStatus (см. F.3). Если ClientFunctionErrorState (см. байте 5 сообщения SCClientStatus F.3) установлен на 0316 (требуется подтверждение оператора), SCM должен запросить более подробную информацию с помощью SCClientFunctionErrorRequest (см. E.9) и проинформировать оператора о неисправных клиентских функциях, указанные в SCClientFunctionErrorResponse (см. структуре ошибки функции E.10, байт b, бит 8). Если подтверждение оператора не требуется, SCM может запросить более подробную информацию, в то время как SCM может либо проигнорировать неисправную клиентскую функцию и продолжить фазу записи, либо отменить всю деятельность, чтобы позволить оператору решить проблему.

d) Индивидуальное начало и завершение, но с промежуточной активацией оператором той же клиентской функции

Этот сценарий начинается как (b) с SCExecutionIndication (см. E.4), указывающего начало выполнения, но с активацией оператором той же клиентской функции, прежде чем она может быть завершена. В этом случае SCC должен отправить второй SCExecutionIndication (см. E.4) с тем же TAN, что и раньше, но с указанием выполненного выполнения функции.

После отправки второго SCExecutionIndication (см. E.4) для активации первого оператора, SCC должен немедленно отправить другой SCExecutionIndication (см. E.4), используя предыдущий TAN, увеличенный на единицу, и указание состояния выполнения функции в зависимости от случая. Описание (a) - (c).

e) Запуск функции, пока предыдущая не завершена

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

Получив SCExecutionIndication (см. E.4), SCM должен отправить SCExecutionIndicationResponse (см. E.5) со следующей информацией:

• тот же идентификатор функции, идентификатор состояния, состояние выполнения функции и TAN, которые были получены в SCExecutionIndication (см. E.4);
• указание в байте 4, была ли записана команда клиента, или причина, по которой команда клиента была отклонена. SCC отклоненной функции может информировать оператора о том, что отправленная команда клиента была отклонена SCM.

Во время записи прием сообщений SCClientStatus (см. F.3) всех включенных SCC должен быть проверен SCM, и как только состояние SCC возвращается к «отключено» (см. 4.5.3.6), или любому сообщению «Время сообщения SCC истекло» (см. приложение B), полная запись последовательности должна быть отменена SCM (см. 4.5.2). SCM сообщает об отмене, изменяя свое состояние на «Готово».

СКМ должен предоставить оператору возможность остановить этап записи. Когда SCM останавливает фазу записи, он должен выполнить одно из следующих действий:

• если SCM все еще ожидает индикации завершения выполнения какой-либо функции, он должен войти в состояние «Завершение записи». Как только они все получены, SCM должен войти в состояние «Готово»;
• в противном случае SCM должен немедленно войти в состояние «Готово», которое должно быть немедленно отражено SCC.

SCC, получающие состояние SCM «Завершение записи», должны выполнить одно из следующих действий:

• если все клиентские функции этого SCC завершили свое выполнение и послали выполнение функции завершено, указав, что SCC должен перейти в состояние «Готово»;
• в противном случае SCC должен оставаться в состоянии «Запись», завершать текущее выполнение клиентской функции, отправлять указание завершения выполнения функции и, как только SCC завершает все свои клиентские функции, он переходит в состояние «Готово». При завершении состояния «Запись» SCC не разрешается указывать новые клиентские команды.

Если и как записанные или определенные вручную последовательности хранятся в энергонезависимой памяти, зависит от конструкции SCM. SCM может отменить фазу записи, непосредственно войдя в состояние «Готово», что соответственно должно быть отражено активированными SCC. Однако SCC может продолжать выполнять свои клиентские функции, поскольку они активируются не системой управления последовательностью, а оператором.

Если не все SCC переходят в состояние «Готово», SCM должен вести себя так, как определено в 4.5 (см. 4.5.3.4).

4.4.5.3 Редактирование последовательности вручную

«Редактирование вручную» позволяет оператору вручную изменять уже доступную последовательность или определять новую последовательность, не выполняя функции клиента в режиме записи.

Если SCM предоставляет оператору возможность установить последовательность с помощью «Редактирования вручную», это должно быть внутренним состоянием SCM и не должно указываться для SCC. Состояние глобальной системы, предоставляемое SCM, должно быть «Готово» с порядковым номером, установленным в FF16.

В «Редактировании вручную» SCM должен предоставить клиентские функции, связанные состоянием функций из включенных SCC, значение функции в соответствии с настройками представления, определенными в объекте функции SCD (см. A.4), и доступный метод запуска для каждой функции на экранах редактирования (см. приложение A).

«Ручное редактирование» должно предоставлять оператору возможность устанавливать информацию, определенную в 4.4.5.1, для каждого шага СКС.

Если SCC определяет значение функции, которое оператор не может изменить (см. A.4), значение функции должно быть

• установите FFFFFFFF16 при создании нового шага и
• сохраняется при редактировании существующего шага.

4.4.6 Проверка последовательности

Активный SCM должен проверить выбранную последовательность или набор последовательностей в системе SC, прежде чем разрешить воспроизведение этой последовательности (последовательностей) для следующих случаев:

• после загрузки ранее сохраненной последовательности(ей);
• по тайм-ауту любого сообщения SCClientStatus (см. F.3);
• после завершения определения или редактирования последовательности вручную;
• после неожиданного изменения состояния любого SCC (см. F.3, байт 2);
• после любой загрузки SCD.

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

• 64-разрядные Имена подключенных SCC и их хозяев рабочего набора, перечисленные в SCD, соответствуют тем, которые сохранены с выбранной последовательностью. Маска ИМЕНИ SCC должна применяться к этому сравнению, как описано в базовом объекте SCD A.3.
• Метка версии SCD и Метка конфигурации SCD соответствуют тем, которые сохранены с выбранной последовательностью.
• Все функции выбранной последовательности содержатся в загруженных SCD.

SCM должен позволять оператору вносить соответствующие изменения в SCS, чтобы соответствовать требованиям валидации.

После успешной проверки SCM может убедиться, что все участвующие SCC в выбранной последовательности(ях) включены, а SCM может отключить все другие SCC, отправив SCStateCommand (см. E.2) отдельным SCC.

4.4.7 Воспроизведение последовательности

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

SCM может предоставить средство для выбора и загрузки ранее сохраненных последовательностей (см. 4.4.9). SCM должен подтвердить выбранную последовательность(и) (см. 4.4.6); в противном случае оператор должен записать или вручную определить последовательность, которая будет использоваться.

Активация воспроизведения последовательности — проприетарна для активного SCM. Он может предоставлять несколько способов ввода, таких как программные клавиши на VT, дополнительные средства ввода (см. ИСО 11783-6) и (или) специальные кнопки в непосредственной близости от оператора.

SCS должен быть успешно подтвержден (см. 4.4.6), прежде чем SCM будет разрешено воспроизвести последовательность. Если проверка последовательности не удалась из-за того, что, например, SCC включен в последовательность, но отсутствует в сети ИСО 11783, SCM может предоставить оператору запатентованные средства для принятия соответствующих действий для получения последовательности, действительной, например, путем удаления клиента функции от SCS.

Переход от «Готов» к «Воспроизведение» разрешается только в том случае, если все SCC, включенные в выбранную последовательность, указывают в своем сообщении SCClientStatus (см. F.3), что они «Готовы».

Однако для быстрой реакции оператора и системы SCM может предоставить средство для начала следующей фазы воспроизведения, даже если предыдущая еще не завершена (один или несколько SCC все еще находятся в состоянии «Воспроизведение» для предыдущей последовательности, так как они все еще выполняют последние команды). В этом случае SCM должен прекратить отправку команд для первой последовательности и изменить порядковый номер в своем сообщении SCMasterStatus (см. F.2), чтобы указать изменение в SCC перед началом отправки команд для следующей последовательности, потому что только одна последовательность может быть активна в любое время. SCM должен знать, что те SCC, которые все еще выполняют команды из предыдущей последовательности, могут отправлять отзывы об этих действиях, что не должно рассматриваться как ошибка.

SCM указывает начало фазы воспроизведения, устанавливая его состояние «Воспроизведение» в сообщении SCMasterStatus (см. F.2). Включенные SCC должны следовать за состоянием SCM до «Play Back» в своем сообщении SCClientStatus (см. F.3). Однако SCM может отправлять клиентские команды даже тем SCC, которые все еще сообщают о состоянии «Готово», чтобы обеспечить немедленный запуск «Воспроизведения». SCC, пропустивший изменение состояния SCM и получивший первую клиентскую команду, должен интерпретировать эту команду как триггер для изменения своего состояния в состояние «Воспроизведение» перед выполнением клиентской команды. SCC всегда должен следовать последней полученной команде SCM. Если SCC не следует состоянию SCM в течение времени ожидания, определенного в F.3, SCM должен действовать, как указано в 4.5.3.4.

Чтобы гарантировать, что SCM и SCC не выйдут из синхронизации на разных этапах выполнения клиентской функции, следующие правила должны применяться каждый раз, когда достигается событие триггера, сохраненное в выполненной SCS, для выполнения следующей клиентской функции, указанной в повторяемой последовательности:

• SCM должен отправить SCMasterExecutionCommand (см. E.6) клиентской функции, владеющей SCC, включая идентификатор функции, идентификатор состояния и значение функции выполняемой клиентской функции. TAN этой начальной команды выполнения для клиентской функции должен быть предыдущим из SCM, увеличенным на единицу.
• SCM должен повторить SCMasterExecutionCommand (см. E.6) с тем же TAN с интервалом 100 мс, пока SCC не ответит с SCClientExecutionStatus (см. E.7) или до истечения времени ожидания.
• SCC должен ответить на каждую команду SCM с SCClientExecutionStatus (см. E.7), включая идентификатор функции, идентификатор состояния и порядковый номер, полученный SCM, и повторять это сообщение с интервалом в 100 мс до SCM изменяет свое состояние на «Прервать», либо до истечения времени ожидания (см. E.1), либо до тех пор, пока SCC не достигнет точки, чтобы сообщить о выполнении функции, или пока SCC не достигнет условия, требующего прерывания выполнения (см. 4.4.7.3), или пока SCM не подтвердит ответ, отправив подтверждение SCClientExecutionAcknowledgement (см. E.8).
• SCM должен ответить на каждый SCClientExecutionStatus (см. E.7) с SCClientExecutionAcknowledgement (см. E.8) с тем же идентификатором функции, идентификатором состояния и состоянием выполнения функции, что и в связанном SCClientExecutionStatus (см. E.7) и с TAN, как в связанной SCMasterExecutionCommand (см. E.6).

На рисунке 11 показан процесс сообщения во время воспроизведения последовательности.

Рисунок 11 — Диаграмма обмена сообщениями Воспроизведения

4.4.7.2 SCClientExecutionStatus

SCClientExecutionStatus (см. E.7) может быть одним из следующих:

a) Совместное начало и завершение

Ответ SCC должен иметь состояние выполнения функции, установленное на 00 (выполнение функции начинается и завершается одновременно), когда клиентская функция запускается и одновременно завершается снова (например, короткий триггер для включения функции, которая работает непрерывно после команды; означает, что оператор взаимодействие — кратковременное нажатие кнопки). TAN этого ответа аналогичен тому, который используется SCM в SCMasterExecutionCommand (см. E.6).

b) Индивидуальное начало и завершение

Ответ SCC должен иметь состояние выполнения функции, равное 01 (выполнение функции началось), когда запущенная функция продолжает работать в течение определенного периода времени (например, гидравлический цилиндр перемещается в течение определенного периода времени). TAN этого ответа такой же, как и в связанной SCMasterExecutionCommand (см. E.6).

Когда выполнение клиентской функции завершено, SCC должен указать это, отправив другой SCClientExecutionStatus (см. E.7) с тем же содержимым, что и выше, но с состоянием выполнения функции, установленным на 10 (выполнение функции завершено).

c) Индивидуальное начало и завершение, но с ошибкой между

Этот сценарий начинается как (b) с ответа SCC, указывающего начало выполнения, но с ошибкой в функции клиента, прежде чем она может быть завершена. В этом случае SCC должен отправить второй SCClientExecutionStatus (см. E.7) с состоянием выполнения функции, установленным в 11 (ошибка во время выполнения), чтобы указать состояние ошибки. TAN этого ответа такой же, как и в связанной SCMasterExecutionCommand (см. E.6). SCC не должен отправлять дополнительный SCClientExecutionStatus (см. E.7), указывающий, что выполнение функции завершено.

d) Команда выполнения для неисправной клиентской функции

Если SCC не может выполнить управляемую клиентскую функцию из-за ошибки в функции или при вводе оператора, SCC должен сообщить причину в виде кода ошибки в SCClientExecutionStatus (см. E.7) с состоянием выполнения функции, установленным на 11 (ошибка во время выполнения) в SCM. TAN этого ответа такой же, как и в связанной SCMasterExecutionCommand (см. E.6). SCC не должен отправлять дополнительный SCClientExecutionStatus (см. E.7), указывающий, что выполнение функции завершено.

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

Если SCC получает команду выполнения для той же клиентской функции, которую он все еще выполняет, SCC должен сначала отправить один SCClientExecutionStatus (см. E.7), используя TAN первой команды выполнения и указывая завершение этой функции (выполнение функции состояние установлено на 10 = выполнение функции завершено).

После отправки полного указания для первой команды SCC должен немедленно отправить второй SCClientExecutionStatus (см. E.7), используя TAN второй SCMasterExecutionCommand (см. E.6) и указание состояния выполнения функции, зависящее от описания случая (a) - (d).

Всякий раз, когда клиентская функция неисправна, SCC должен указать это в сообщении SCClientStatus (см. F.3) в дополнение к SCClientExecutionStatus (см. E.7). Если ClientFunctionErrorState (см. байте 5 F.3) установлен на 0316 (требуется подтверждение оператора), SCM должен запросить более подробную информацию с помощью SCClientFunctionErrorRequest (см. E.9) и проинформировать оператора о неисправном клиенте. Функции, указанные в SCClientFunctionErrorResponse (см. E.10, байт b бит 8). Если подтверждение оператора не требуется, SCM может запросить более подробную информацию; SCM должен либо проигнорировать неисправную клиентскую функцию и продолжить фазу воспроизведения, либо остановить всю активность, изменив ее состояние на «Abort» (см. 4.4.7.3).

Если SCM не получает ответное сообщение с правильным TAN, идентификатором клиентской функции и идентификатором состояния в течение времени ожидания, SCM (см. E.1) должен остановить «Воспроизведение».

Во время воспроизведения прием сообщений SCClientStatus (см. F.3) всех включенных SCC должен быть проверен SCM, и как только состояние SCC возвращается в отключенное состояние или истекает время ожидания любого сообщения SCC (см. F.3), воспроизведение всей последовательности должно быть остановлено SCM (см. 4.5.2 и 4.4.7.3).

Любая операторская активация клиентских функций во время воспроизведения должна быть сообщена SCM через SCExecutionIndication (см. E.4), установив состояние выполнения функции в 11 (ошибка во время выполнения). SCM может остановить воспроизведение всей последовательности, если активированная клиентская функция является частью выполняемой SCS, или может принять решение не отправлять какие-либо новые команды этой клиентской функции во время этой фазы воспроизведения. SCM также разрешается просто игнорировать SCExecutionIndication (см. E.4) во время воспроизведения в отношении необходимости остановки фазы воспроизведения или для информирования оператора, но не в отношении передачи сообщений.

SCC должен повторить свой SCExecutionIndication (см. E.4) с интервалом в 100 мс, пока SCM не вернется обратно в состояние «Ready», или до истечения времени ожидания (см. E.1), или пока SCM не подтвердит команду клиента отправив SCExecutionIndicationResponse (см. E.5) с тем же идентификатором функции, идентификатором состояния и TAN.

Воспроизведение обычно заканчивается указанием завершения последнего выполнения функции исполняющим SCC. После получения всех невыполненных состояний выполнения функции, как выполненных или основанных на внутренних условиях, SCM должен войти в состояние «Готово», и это должно быть отражено включенными SCC в сообщении SCClientStatus (см. F.3) соответственно. SCM может войти в состояние «Готово», даже если не все невыполненные состояния выполнения функции были приняты как завершенные (например, внутренний тайм-аут SCM для фазы воспроизведения).

4.4.7.3 Прервать воспроизведение

Активный SCM должен предоставить оператору возможность остановить «Воспроизведение». Если во время «Воспроизведения» возникают внутренние условия, требующие «Отмена», SCM может инициировать «Отмена» без участия оператора. Если SCC должен остановить текущую фазу воспроизведения, он должен отправить глобальный SCClientAbort (см. E.3), пока он не получит состояние «Прервать» от активного SCM, и SCC не сообщит «Прервать» активному SCM с состоянием «Abort» в сообщении SCClientStatus (см. F.3). Только во время «Воспроизведения» активный SCM должен немедленно изменить состояние системы на «Прервать» после получения SCClientAbort (см. E.3) от любого включенного SCC или признания того, что SCC передает состояние «Прервать». Если активный SCM должен остановить саму фактическую фазу воспроизведения, он должен войти в состояние «Прервать», которое будет немедленно отражено SCC. Во время состояния «Прервать» SCC отвечают за командование любой клиентской функции (функций), которой SCM дал команду в текущей последовательности, в безопасное состояние, определенное SCC. Функции SCC, не управляемые SCM, не должны зависеть от остановки SCM. В случае «Отмена» SCM может уведомить об этом оператора соответствующим образом.

После того как SCM получает состояние «Прервать» от всех включенных SCC, он должен вернуться в состояние «Готово», и это должно быть отражено в сообщении SCClientStatus (см. F.3) соответствующими SCC.

Рисунок 12 иллюстрирует процесс сообщения для остановки воспроизведения.

Рисунок 12 — Диаграмма обмена сообщениями Прерывания

4.4.8 Значение функции

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

Значение функции обычно отправляется SCC с SCExecutionIndication (см. E.4), указывающем состояние «выполнение функции завершено» во время записи, или определяется оператором вручную в режиме редактирования. Если SCC указывает только начало активации функции клиента, он должен установить значение функции на FFFFFFFF16. SCC определяет в своем функциональном объекте SCD (см. A.4), если и как значение функции отображается на экранах SCM.

Значение функции должно быть сохранено вместе с синхронизацией запуска и идентификатором каждого отдельного шага в SCS. Во время воспроизведения значение функции должно быть отправлено обратно в SCC как часть команды выполнения функции (см. E.6). SCM должен разрешать активацию определенной клиентской функции несколько раз независимо друг от друга в пределах одной или нескольких последовательностей (например, полная высота сцепки может быть достигнута за несколько шагов в одной последовательности, и SCM должен обрабатывать каждый этап отдельно в своей последовательности).

Пример — Во время «Записи» оператор поднимает 3-точечную сцепку в определенное положение. Подверженный SCC указывает начало ввода оператора с SCExecutionIndication (см. E.4) для SCM. Когда сцепка достигает намеченной позиции, оператор останавливает движение сцепки, и SCC указывает «завершение выполнения функции», включая достигнутую позицию, в качестве значения функции для SCM, который сохраняет значение с этой функцией в SCS (см. Подробности в SCExecutionIndication в Д.4).

Во время «Воспроизведения» SCM отправляет это значение функции как часть SCMasterExecutionCommand (см. E.6) обратно в SCC. Это позволяет SCC выполнять функцию так же, как это делал оператор во время записи, и останавливаться в том же положении сцепки.

4.4.9 Управление последовательностями

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

4.4.9.1 Хранение последовательности

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

4.4.9.2 Загрузка последовательности

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

После загрузки последовательности или набора последовательностей SCM должен проверить последовательности, как описано в 4.4.6.

4.4.9.3 Редактор последовательности

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

Пример 1 — Измените триггер с расстояния на время.

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

Пример 2 — BOM не может быть включен до тех пор, пока сцепка не достигнет определенного положения.

Если SCM предоставляет «Режим редактирования», оператор может использовать этот режим для ручного определения последовательности (см. 4.4.5.3).

4.5 Обработка ошибок

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

SCC сообщают о состоянии своих клиентских функций в своем сообщении SCClientStatus (см. F.3). Если SCM распознает, что состояние ошибки одной или нескольких клиентских функций изменилось со времени последнего отчета (см. значение байта 5 в F.3, значение 0216), он может запросить подробную информацию с помощью SCClientFunctionErrorRequest (см. E.9). Если SCC указывает, что одна из его клиентских функций изменила состояние ошибки и нуждается в подтверждении оператора (значение байта 5 F.3 0316), SCM должен запросить подробную информацию. SCClientFunctionErrorResponse (см. E.10), по крайней мере, используется SCM для обнаружения ошибок, когда требуется подтверждение оператора (см. E.10, структура байта 3-N, байт b, бит 8) и, возможно, определяет, клиентская функция в одной из последовательностей неисправна или, если затронуты другие, неиспользуемые клиентские функции. После отправки отчета SCC должен изменить свой ClientFunctionErrorState обратно на 0116. SCM должен немедленно сообщить оператору о неисправных клиентских функциях, которые передаются с установленным битом подтверждения оператора. SCM может включить оператора в процесс принятия решения о дальнейшем разбирательстве.

4.5.1 Сбой функции

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

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

4.5.2 Сбой связи

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

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

Примечание — Более конкретное поведение системы по определенным вопросам связи рассматривается в разделе 4.5.3.

4.5.3 Несоответствующее поведение участника

В следующих подпунктах указано действие, предпринимаемое SCM и SCC для несоответствующего поведения системы.

4.5.3.1 Неожиданные сообщения SCC

SCM должен NACK все сообщения SC, поступающие от SCC, не являющихся частью действующего соединения, в соответствии с определениями 4.4.2. Поскольку загруженный и проверенный SCD является частью успешно завершенного процесса инициализации, подключения к SCC, чей SCD был удален SCM, считаются недействительными (см. примеры в следующих подпунктах 4.5.3).

Если после процесса инициализации SCC отправляет сообщение SC, которое он не должен отправлять, SCM должен НАБЛЮДАТЬ это сообщение.

Пример — Отключенный SCC отправляет scexecutionindication (см. E.4).

SCC может восстановить свое соединение с SCM при получении неожиданных NACK.

4.5.3.2 Отсутствие ответов SCC

SCM должен удалить SCD из энергозависимой памяти SCC, которые не отвечают на команды и запросы в течение времени ожидания, определенного в E.1 и приложении F, или не отправляют свои частые сообщения о состоянии. Это вынуждает эти SCC повторно устанавливать соединение с активным SCM, так как SCM будет отрицательно подтверждать все входящие сообщения SC SCC без доступных SCD (см. подробности в 4.5.3.1).

4.5.3.3 Несколько SCM активны

Если SCC распознает, что в сети ИСО 11783 активно несколько SCM, получая различные сообщения SCMasterStatus (см. F.2), SCC должен немедленно изменить свое состояние на отключенное.

4.5.3.4 SCC не следует состоянию SCM

Если SCC не следует состоянию последовательности SCM в определениях тайм-аута F.3, SCM должен удалить SCD из энергозависимой памяти и NACK сообщения SC этого SCC, чтобы обеспечить надлежащее восстановление соединения. СКМ может информировать оператора об этом шаге. Единственное исключение из общего правила постоянного отслеживания состояния SCM — это состояние «Завершение записи», в котором требуется отклонение от состояния SCC (см. 4.4.5.2).

4.5.3.5 Неправильное поведение SCC

Если SCC не изменяет свое состояние SCC на отключенное или включенное в определениях времени ожидания E.1, SCM должен удалить SCD из энергозависимой памяти и NACK все сообщения SC из этого SCC, включая сообщение SCClientStatus (см. F.3) и не отправлять никаких сообщений в этот SCC, пока SCC не сообщит правильное состояние SCC, в которое он был задан.

4.5.3.6 Неожиданное изменение состояния SCC на отключенное

Если активный SCM обнаруживает неожиданное изменение состояния SCC на отключенное, то SCM должен удалить SCD этого SCC из энергозависимой памяти, чтобы обеспечить надлежащее восстановление соединения и NACK сообщения SC этого SCC. Активный SCM, ответственный за целостность последовательности, должен предпринять соответствующие действия, когда этот SCC является частью выбранной последовательности (последовательностей), чтобы гарантировать, что соответствующие клиентские функции будут удалены из последовательности(ей). Это может потребовать взаимодействия с оператором.

4.6 Стратегия коммуникации

При обмене данными между SCM и SCC возможно, что ответ на команду не получен из-за временных проблем связи. Отказ может произойти во время командного сообщения (то есть SCM не принимает команду клиента), или сбой может произойти во время ответного сообщения (то есть SCC не получает ответ SCM). Инициатор команды не может различить эти два случая и будет повторять команду, чтобы получить необходимое поведение.

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

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

Использование TAN позволяет одновременно активировать несколько клиентских команд. Например, один SCC может иметь более одного SCExecutionIndication (см. E.4), активного в данный момент времени, когда завершение одной команды еще не завершено, пока оператор уже активирует следующую команду.

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

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

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

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

A.1.1 Обзор

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

Определения объекта аналогичны использованию объекта в ИСО 11783-6, включая передачу SCD из SCC в SCM посредством транспортного протокола ИСО 11783 и (или) расширенного транспортного протокола.

Все используемые идентификаторы объекта должны быть уникальными внутри всего SCD в диапазоне номеров от 0 до 65534, тогда как 65535 (FFFF16) зарезервировано для использования в качестве идентификатора объекта «NULL».

Каждый SCC должен представить свой индивидуальный SCD активному SCM. Зависимости между несколькими устройствами или CF в сети должны обрабатываться в рабочем наборе; возможно, только один из них может представлять рабочий набор как SCC и связываться с SCM соответственно

A.1.2 Номенклатура

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

1 — наиболее значимый бит; 2 — наименее значимый бит

Рисунок A.1 — Расположение битов в битовой маске

A.2 Диаграмма взаимосвязей объекта SCD

На рисунке A.2 показана взаимосвязь между объектами SCD и ссылочными объектами VT.

Рисунок A.2 — Диаграмма взаимосвязей объекта SCD

Ссылки на объекты VT используются для обозначения и графического представления отдельных объектов SCD. Объекты SCD содержат идентификатор объекта, используемый в указанном SCCOP. SCM использует эти ссылки для заполнения указателей внешних объектов в своем собственном пуле объектов VT. VT использует ссылочные объекты в компоновках экрана SCM соответственно.

A.3 Базовый объект SCD

Базовый объект SCD (см. таблицу A.1) является корневым объектом пула объектов SCD. Для каждого SCD разрешен только один базовый объект.

Таблица A.1

Базовый объект SCD

SCM должен хранить NAME SCC, владеющего SCD, вместе с SCD. Это не является частью самого SCD. Маска NAME SCC, включенная в базовый объект SCD, будет использоваться SCM для идентификации SCC, соответствующего сохраненному SCD, во время следующего запуска(ов). Маска NAME SCC позволяет производителю SCC определить, насколько строго SCM может фильтровать для той же конфигурации системы при следующем запуске. SCM может быть принудительно ожидать того же самого агрегата, например, путем установки всех битов маски на 1 (все байты маски имени пользователя SCC = FF16). Но он также может разрешить использование одной машины из парка идентичных машин (например, только поле идентификатора в NAME будет другим, и эти биты маски NAME будут установлены в 0). Однако SCM может быть более строгим в своей фильтрации NAME, чем SCC определяет в своей маске NAME.

Имя мастера SCCWS позволяет использовать SC в конфигурации главного элемента, где SCC не является мастером рабочего набора. В этом поле содержится NAME мастера рабочего набора, владеющего пулом объектов в VT, с графикой и текстами, на которые есть ссылки в SCD. Обычно это поле содержит NAME самого SCC, только когда SCC является элементом без собственного OP, тогда оно содержит NAME своего хозяина рабочего набора.

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

Метка версии SCD может отображаться оператору и может использоваться как часть имени файла. Таким образом, SCC должен применять следующие правила. Метки версий SCD должны состоять из видимых символов из набора шрифтов ИСО/IEC 8859-1 (Latin 1). Метки версии SCD должны быть дополнены концевыми пробелами, чтобы получить строку символов длины, определенной в поле Длина метки версии SCD. Кроме того, следующие символы не должны использоваться в строке метки версии SCD:

Метка конфигурации SCD предназначена для использования SCC для идентификации конфигурации машины, представленной SCD, хранящейся в SCM (например, установленных опций на машине и т.д.). Содержимое метки версии SCD и метки конфигурации SCD является собственностью производителя SCC. Задача SCC состоит в том, чтобы запросить и проверить метку версии SCD и метку конфигурации SCD для SCD, сохраненного в SCM, до его активации SCC. Однако для обеспечения целостности SCS SCM должен отслеживать метку версии SCD и метку конфигурации SCD, используемые во время определения SCS. Длина этих двух строк меток ограничена максимум 64 символами, чтобы избежать непропорционального увеличения размера SCS в памяти.

Обозначение SCD и Графика SCD должны предоставлять некоторую репрезентативную информацию о SCC, поскольку SCM может использовать их для отображения оператора определенной последовательности.

Длина строки указателя ограничена ограничениями строкового объекта VT (см. подробные определения в ИСО 11783-6), но SCM может обрезать ее, чтобы соответствовать ограничениям пользовательского интерфейса SCM (относительно, например, размера экрана или макет экрана). Минимальная видимая длина должна составлять 32 символа для обеспечения минимальной информации, видимой для оператора.

SCCOP включает в себя всю информацию макета, включая тип шрифта, размер шрифта, цвет шрифта и т.д. Для объектов текстового представления, на которые ссылаются. Чтобы обеспечить соответствующие макеты, SCM должен предоставить желаемый размер шрифта и т.д. Через SCMasterCapabilityResponse (см. C.3) для SCC, чтобы разрешить корректировки SCCOP.

A.4 Объект функция SCD

Функциональный объект SCD предоставляет всю информацию, о клиентских функциях, поддерживаемых SCC для системы управления последовательностью. Активация этих клиентских функций может быть записана как действия оператора во время фазы записи (SCM сохраняет идентификатор активированной клиентской функции) и может быть инициирована SCM во время фаз воспроизведения. Он также включает предпочтительный режим запуска, который может быть только одним конкретным режимом; это может использоваться SCM в качестве режима запуска по умолчанию во время фазы записи. Графическое и текстовое представление будет использоваться SCM для представления действий в его компоновке экрана (например, при отображении содержимого сохраненной последовательности оператору). Различные состояния, поддерживаемые функциональным объектом SCD (см. таблицу A.2), определены в ссылочных объектах состояния SCD (см. A.5).

Таблица A.2

Объект функция SCD

Идентификатор функции используется для передачи функции по сети ИСО 11783 для сохранения длины поля данных сообщения в пределах максимум 8 байтов в связанных сообщениях CAN. Размер поля в один байт ограничивает максимальное количество функций, которые могут быть определены в одном SCD, до 255.

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

SCC может отправлять числовое значение функции при каждом завершении функции во время записи, которую SCM должен сохранить с активацией этой функции в своей последовательности. SCM должен отправить это значение вместе с сообщением активации во время фазы воспроизведения обратно в SCC. Это позволяет SCC сохранять конкретное значение процесса при каждой активации функции клиента (например, высота сцепки трактора). SCC определяет в своем функциональном объекте SCD, если и как это значение функции может отображаться или в каком диапазоне оно может управляться оператором на экране обзора последовательности; когда такой SCreen поддерживается SCM.

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

Отображаемое значение = (Атрибут значения + смещение) * Коэффициент масштабирования

Передаваемое числовое значение функции = (отображаемое значение/масштабный коэффициент) — смещение = значение атрибута

Масштабированный верхний предел = (верхний предел + смещение) * коэффициент масштабирования

Масштабированный нижний предел = (нижний предел + смещение) * Коэффициент масштабирования

Нижний предел <= значение атрибута <= Верхний предел

Масштабированный нижний предел <= Отображаемое значение <= Масштабированный верхний предел

Каждый объект функции SCD может ссылаться на несколько объектов состояния SCD (см. A.5), представляющих различные состояния функции; например для главного клапана распылителя состояния могут быть включены и выключены. Главный клапан распылителя функции будет представлен своим обозначением и графическим представлением, а два состояния будут представлены соответствующими объектами состояния SCD (см. A.5).

SCM может предоставить средство на своем экране редактирования последовательности для изменения состояния вручную; это может быть объект списка ввода, основанный на обозначениях или графическом представлении ссылочного объекта состояния SCD (см. A.5).

Длина строки обозначения ограничена только ограничениями объекта строки VT (см. ИСО 11783-6), но SCM может обрезать ее, чтобы соответствовать ограничениям пользовательского интерфейса SCM (в отношении, например, размера дисплея или компоновки экрана). Минимальная видимая длина должна составлять 32 символа для обеспечения минимальной информации, видимой для оператора.

SCCOP включает в себя всю информацию макета, включая тип шрифта, размер шрифта, цвет шрифта и т.д. Для объектов текстового представления, на которые ссылаются. Чтобы обеспечить соответствующие макеты, SCM должен предоставить желаемый размер шрифта и т.д. Через SCMasterCapabilityResponse (см. C.3) для SCC, чтобы учесть соответствующие корректировки шрифта.

A.5 Объект состояния SCD

Каждый объект состояния SCD (см. таблицу A.3) определяет одно состояние ссылочного функционального объекта SCD (см. A.4).

Таблица A.3

Объект состояния SCD

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

Идентификатор состояния используется для передачи информации о состоянии по сети ИСО 11783 для сохранения длины поля данных сообщения в пределах максимум 8 байтов одного сообщения. Размер поля в шесть битов ограничивает максимальное число состояний для функции до 64. Идентификатор состояния от 0 до 63 всегда связан с идентификатором родительской функции.

На одно определение объекта состояния SCD могут ссылаться несколько функциональных объектов SCD в SCD, в то время как SCM создает отдельные объекты для отслеживания отдельных состояний.

Длина строки обозначения ограничена только ограничениями объекта строки VT (см. ИСО 11783-6), но SCM может обрезать ее, чтобы соответствовать ограничениям пользовательского интерфейса SCM (пример в отношении размера дисплея или компоновки экрана). Минимальная видимая длина должна составлять 32 символа для обеспечения минимальной информации, видимой для оператора.

SCCOP включает в себя всю информацию макета, включая тип шрифта, размер шрифта, цвет шрифта и т.д. Для объектов текстового представления, на которые ссылаются. Чтобы обеспечить соответствующие макеты, SCM должен предоставить желаемый размер шрифта и т.д. Через SCMasterCapabilityResponse (см. C.3) для SCC, чтобы учесть соответствующие корректировки шрифта.

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

ОПРЕДЕЛЕНИЯ СООБЩЕНИЙ

B.1 Сообщения управления последовательностью

Два PGN зарезервированы для связи SC между SCM и SCC: SCM к SCC; от SCC к SCM.

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

B.2 От SCM к SCC

B.3 От SCC к SCM

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

СООБЩЕНИЯ ТЕХНИЧЕСКИХ ДАННЫХ

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

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

C.2 SCMasterCapabilityRequest

SCMasterCapabilityRequest отправляется SCC для запроса возможностей активного SCM перед загрузкой SCD. SCC сообщает поддерживаемую версию SC Standard для перекрестной проверки SCM.

C.3 SCMasterCapabilityResponse

SCMasterCapabilityResponse должен быть отправлен SCM в качестве ответа на SCMasterCapabilityRequest (см. C.2). Эти данные используются SCC для настройки их SCD до его загрузки в SCM и для настройки SCCOP, загруженного в VT, для соответствия размерам объектов SCM в отношении размера графического объекта или атрибутов шрифта. Это сообщение требует использования транспортного протокола, определенного в ИСО 11783-3.

Чтобы способствовать повторному использованию объектов из SCOOP, SCM должен сообщить размер мягкой клавиши используемого VT для размера графических объектов (байты 3 и 4).

C.4 SCMasterMemoryRequest

SCMasterMemoryRequest отправляется SCC, чтобы определить, имеет ли SCM достаточно энергозависимой памяти, доступной до загрузки SCD.

C.5 SCMasterMemoryResponse

SCMasterMemoryResponse должен быть отправлен SCM как ответ на SCMasterMemoryRequest (см. C.4).

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

СООБЩЕНИЯ РАБОТЫ SCD

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

Операционные сообщения SCD используются во время конфигурации системы. Они состоят из запросов SCC с ответами активного SCM, как определено в следующих пунктах. Сообщения отправляются с использованием PGN, указанных в приложении B.

Для отдельных ответов не определены конкретные тайм-ауты, поскольку необходимая обработка памяти в SCM очень сильно зависит от размера, например, задействованного SCD. Важно, чтобы SCC учитывали флаги занятости в сообщении SCMasterStatus (см. F.2) во время определения их тайм-аутов.

SCM может предоставлять функции для хранения и восстановления полного SCD. Наличие и организация энергонезависимого хранилища зависит от SCM. Хранение и восстановление SCD включает все определения объектов (см. приложение A). Если SCM предоставляет возможность хранить SCD, внутри SCM должен быть способ назначать сохраненную SCD уникально для SCC. Существует только один SCD на SCC, который может храниться в энергонезависимой памяти.

D.2 SCDVersionRequest

SCDVersionRequest используется SCC во время запуска, чтобы проверить, есть ли у активного SCM сохраненный SCD доступного запрашивающего SCC и соответствует ли версия SCD версии SCC. SCM ответит SCDVersionResponse (см. D.3).

D.3 SCDVersionResponse

SCDVersionResponse должен быть отправлен активным SCM как ответ на запрос SCDVersionRequest (см. D.2) SCC. Если код ошибки (байт 2) указывает на отсутствие ошибки, это сообщение будет содержать полную строку метки версии SCD сохраненного пула SCD запрашивающего SCC. В зависимости от длины строки может потребоваться использование транспортного протокола. В случае любого кода ошибки, отличного от нуля, данные версии не включаются, а длина кадра устанавливается равной 8 байтам данных, а байты данных 4-8 отправляются как FF16.

D.4 SCDConfigurationLabelRequest

SCDConfigurationLabelRequest используется SCC для проверки того, имеет ли активный SCM доступный сохраненный SCD запрашивающего SCC и соответствует ли сохраненная в SCD конфигурация текущей конфигурации SCC. SCM ответит SCDConfigurationLabelResponse (см. D.5).

D.5 SCDConfigurationLabelResponse

SCDConfigurationLabelResponse должен быть отправлен активным SCM как ответ на SCDConfigurationLabelRequest (см. D.4) SCC. Если код ошибки указывает на отсутствие ошибки, это сообщение будет содержать полную строку метки конфигурации SCD сохраненного SCD запрашивающего SCC. В зависимости от длины строки может потребоваться использование транспортного протокола. В случае любых ошибок кода, отличных от нуля, данные конфигурации не включаются, а длина кадра устанавливается равной 8 байтам данных, а байты 4-8 отправляются как FF16.

D.6 SCDTransfer

Передача SCD используется SCC для передачи своего SCD активному SCM.

Это сообщение требует использования транспортного протокола, определенного в ИСО 11783-3. Если длина данных превышает 1785 байты, должен использоваться расширенный транспортный протокол, используемый в ИСО 11783-6.

D.7 SCDTransferResponse

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

D.8 SCDActivationCommand

SCDActivationCommand должен быть отправлен SCC для активации его SCD после того, как он был либо успешно передан (ошибки не указаны в D.7 SCDTransferResponse), либо загружен (см. D.14 SCDLoadCommand). Получение этой команды инициирует синтаксический анализ SCD SCM. SCM должен указать текущий анализ в флагах занятости своего сообщения SCMasterStatus (см. F.2). SCM должен ответить SCDActivationResponse (см. D.9), указывающее целостность SCD.

D.9 SCDActivationResponse

SCDActivationResponse отправляется SCM после завершения анализа SCD, чтобы указать целостность SCD в поле кодовых ошибок этого сообщения. Любые коды ошибок, отличные от 0, указывают на то, что система SCD не может использовать SCD.

D.₁₀ SCDDeleteCommand

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

D.₁₁ SCDDeleteResponse

The SCDDeleteResponse отправляется SCM после выполнения удаления SCD.

D.₁₂ SCDStoreCommand

Команда SCDStoreCommand будет отправлена SCC активному SCM, чтобы инициировать сохранение SCD в энергонезависимой памяти SCM, если активация и разбор SCD были успешными. SCM должен гарантировать, что только один SCD конкретного клиента хранится в энергонезависимой памяти, используя информацию маски NAME в базовом объекте SCD (см. A.3) соответственно. Старые версии SCD будут перезаписаны.

D.₁₃ SCDStoreCommandResponse

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

D.₁₄ SCDLoadCommand

Команда SCDLoadCommand будет отправлена SCC активному SCM, чтобы инициировать загрузку SCD, доступного в энергонезависимой памяти SCM, в энергозависимую память (см. 4.4.2).

D.₁₅ SCDLoadResponse

SCDLoadResponse отправляется SCM после завершения загрузки SCD из энергонезависимой в энергозависимую память. Любой код ошибки, кроме 0, указывает на то, что SCD не может быть загружен.

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

СООБЩЕНИЯ УПРАВЛЕНИЯ ПОСЛЕДОВАТЕЛЬНОСТЬЮ

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

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

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

Командующий или запрашивающий CF должен повторять свою команду или запрос с частотой повторения до 5 раз в секунду, пока ответ не будет получен или ответ не может быть получен в течение по меньшей мере 1,6 с. Минимум 100 мс должен быть обеспечен между повторяющимися командами или запросами.

E.2 SCStateCommand

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

Изменение состояния будет отражено в состоянии биты сообщения SCClientStatus (см. F.3) функции; следовательно, отдельное ответное сообщение не определено.

E.3 SCClientAbort

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

Активный SCM должен отражать состояние последовательности «Abort» в своем сообщении SCMasterStatus (см. F.2) в качестве ответа на этот SCClientAbort.

Активный SCM и все включенные SCC должны остановить обработку SC сразу после получения этой команды SCClientAbort. SCC могут перейти в безопасное состояние и ждать дальнейших инструкций оператора. Однако сообщение SCMasterStatus (см. F.2) и сообщение SCClientStatus (см. F.3) продолжаются.

Остановленное воспроизведение не может быть возобновлено без специального подтверждения оператора для активного SCM. СКМ должен предоставить положения для этой задачи.

E.4 SCExecutionIndication

SCExecutionIndication отправляется при активации функции клиента только во время «Запись» или «Воспроизведение». Только активированные SCC могут отправлять это сообщение.

E.5 SCExecutionIndicationResponse

SCExecutionIndicationResponse отправляется активным SCM как ответ на любой SCExecutionIndication (см. E.4) на связанный SCC. Идентификатор функции, идентификатор состояния и состояние выполнения функции должны отражать информацию, отправленную с помощью SCExecutionIndication (см. E.4). Ошибки кода, отличные от 0016, указывают, что SCM не смог сохранить команду клиента в активной SCS. TAN должен совпадать с полученным в ответе на SCExecutionIndication (см. E.4).

E.6 SCMasterExecutionCommand

SCMasterExecutionCommand используется SCM для запуска клиентских функций SCC во время фазы воспроизведения, когда достигается соответствующее условие запуска (например, время или расстояние). SCM отправляет команду непосредственно в функцию, владеющую SCC, которая должна соответствующим образом выполнять клиентскую функцию. Триггерный SCC должен подтвердить начало и завершение этой команды с SCClientExecutionStatus (см. E.7 и 4.4.7).

E.7 SCClientExecutionStatus

SCClientExecutionStatus будет отправлено SCC в качестве ответа на любую SCMasterExecutionCommand (см. E.6), полученную от SCM для подтверждения приема и выполнения команды (см. 4.4.4).

TAN должен совпадать с полученным в SCMasterExecutionCommand (см. E.6).

E.8 SCClientExecutionAcknowledgement

SCClientExecutionAcknowledgement отправляется SCM для подтверждения приема SCClientExecutionStatus (см. E.7) SCC, выполняющего клиентскую функцию во время воспроизведения (см. 4.4.7 Последовательное воспроизведение).

TAN должен быть таким же, как и полученный в SCClientExecutionStatus (см. E.7), на который нужно ответить

E.9 SCClientFunctionErrorRequest

SCClientFunctionErrorRequest используется SCM для запроса фактического состояния неисправных клиентских функций. SCC сообщают в своем сообщении о состоянии, если одна или несколько клиентских функций недоступны для использования, в то время как SCM использует это сообщение для запроса подробностей от отдельных SCC. SCC должен ответить с SCClientFunctionErrorResponse (см. E.10).

E.₁₀ SCClientFunctionErrorResponse

SCClientFunctionErrorResponse отправляется ответом SCC на SCClientFunctionErrorRequest (см. E.9) из активного SCM. SCC должен сообщать идентификаторы клиентских функций неисправных клиентских функций вместе с кодом ошибки, указывающим состояние ошибки неисправной клиентской функции (2 байта на функцию). В зависимости от количества активных ошибок это сообщение может потребовать использования ТР. В случае отправки менее трех неисправных клиентских функций, сообщение должно быть дополнено FF16 до 8 байтов данных.

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

При передаче этого сообщения SCC должен сбросить ClientFunctionErrorState на 0116 в своем сообщении SCClientStatus (см. F.3) до тех пор, пока состояние одной или нескольких клиентских функций снова не изменится.

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

СООБЩЕНИЯ СОСТОЯНИЯ

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

Сообщения о состоянии позволяют SCC определять состояние SCM и наоборот.

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

F.2 Сообщение SCMasterStatus

Это сообщение отправляется активным SCM как широковещательное сообщение всем CF. Оно отправляется немедленно при изменении состояния любого из байтов от 2 до 5, один раз в секунду в состоянии «Готово» и 5 сообщений в секунду во время активного состояния «Запись», «Завершение записи», «Воспроизведение» или «Прервать». Должно быть обеспечено минимум 100 мс между отдельным сообщением SCMasterStatus.

Неактивные SCM не должны разрешать изменение своего состояния, в то время как другой SCM указывает свое активное состояние в своем сообщении о состоянии; активный SCM не должен позволять изменять свое состояние во время записи или воспроизведения последовательности.

Неактивные SCM должны отправлять свое сообщение SCMasterStatus только один раз непосредственно после запуска, указывающего на инициализацию, и один раз непосредственно после изменения состояния (ввод оператора) с состоянием «неактивный».

Тайм-аут 600 мс для сообщения SCMasterStatus должен применяться в состояниях «Запись», «Завершение записи», «Воспроизведение» или «Прервать». Тайм-аут 3 с применяется в состоянии «Готов».

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

F.3 SCClientStatus message

Сообщение SCClientStatus отправляется всеми SCC, поддерживающими концепцию управления последовательностями, в то время как они обнаруживают активный SCM в сети ИСО 11783. Он отправляется немедленно при изменении состояния любого из байтов от 2 до 5, один раз в секунду в состоянии «Готов» или если SCC отключен, и 5 сообщений в секунду во время активных «Запись», «Завершение записи», «Воспроизведение», «Назад» или «Отмена». Должно быть обеспечено минимум 100 мс между отдельными сообщениями SCClientStatus.

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

Получение NACK сообщения SCClientStatus от активного SCM является признаком того, что SCM не синхронизирован с SCC. SCC должен восстановить соединение с активным SCM.

Порядковый номер (байт 3) должен использоваться для указания фактического порядкового номера, для которого SCC отправляет SCExecutionIndication (см. определение в E.4) или для которого SCC фактически выполняет SCMasterExecutionCommand (см. E.6), Порядковый номер в сообщении SCClientStatus предназначен для использования только в диагностических целях.

SCC должны указывать с ClientFunctionErrorState (байт 5) в любой момент времени, если одна или несколько его клиентских функций недоступны для использования в последовательности или если состояние ошибки какой-либо из его клиентских функций изменилось с момента последнего подробного отчета до SCM, чтобы позволить SCM запрашивать состояние отдельных клиентских функций с помощью SCClientFunctionErrorRequest (см. E.9 и E.10).

Время ожидания 600 мс для сообщения SCClientStatus должно применяться в состоянии «Запись», «Воспроизведение» или «Прервать». Тайм-аут 3 с применяется в состоянии «Готов».

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

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

Таблица ДА.1

БИБЛИОГРАФИЯ