ГОСТ Р 60.2.0.1-2022

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

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

ГОСТР 60.2.0.1— 2022 (ИСО 22166-1: 2021)

Роботы и робототехнические устройства

МОДУЛЬНЫЙ ПРИНЦИП ПОСТРОЕНИЯ СЕРВИСНЫХ РОБОТОВ

Часть 1

Общие требования

(ISO 22166-1:2021, Robotics — Modularity for service robots —

Part 1: General requirements, MOD)

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

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

Предисловие

• 1 ПОДГОТОВЛЕН Федеральным государственным автономным научным учреждением «Центральный научно-исследовательский и опытно-конструкторский институт робототехники и технической кибернетики» (ЦНИИ РТК) совместно с Федеральным государственным бюджетным учреждением «Российский институт стандартизации» (ФГБУ «РОТ») на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

• 2 ВНЕСЕН Техническим комитетом по стандартизации ТК 141 «Робототехника»

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

• 4 Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО 22166-1:2021 «Робототехника. Модульность сервисных роботов. Часть 1. Общие требования» (ISO 22166-1:2021 «Robotics — Modularity for service robots — Part 1: General requirements», MOD) путем внесения технических отклонений, объяснение которых приведено во введении к настоящему стандарту.

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5—2012 (пункт 3.5) и для увязки с наименованиями, принятыми в существующем комплексе национальных стандартов Российской Федерации.

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

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

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

© ISO, 2021

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

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

Содержание

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

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

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

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

• 4.1 Введение

• 4.2 Основные принципы модульности

• 4.3 Абстракция

• 4.4 Электрические интерфейсы и коммуникационные протоколы

• 4.5 Взаимозаменяемость

• 4.6 Характеристики модуля

• 4.7 Компьютерное моделирование

• 4.8 Типы данных для интероперабельности

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

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

• 5.2 Безопасность на уровне робототехнического комплекса

• 5.3 Безопасность на уровне модуля

• 5.4 Основные вопросы защищенности

• 5.5 Действия по проектированию защищенности модуля

• 5.6 Физическая защищенность модулей

• 5.7 Киберзащищенность модулей

• 6 Конструирование модулей с аппаратными свойствами

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

• 6.2 Требования и руководства к аппаратным особенностям модулей

• 7 Конструирование модулей с программными свойствами

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

• 7.2 Информационная модель

• 7.3 Архитектурная модель программных модулей

• 7.4 Требования к программным модулям, связанные с безопасностью и защищенностью

• 8 Руководство по эксплуатации

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

• 8.2 Маркировки или обозначения

• 8.3 Информация для пользователей

• 8.4 Информация по обслуживанию

Приложение А (справочное) Шаблон представления модуля робота

Приложение В (справочное) Примеры модулей роботов

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

Приложение D (справочное) Руководство по испытаниям модулей роботов

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

и межгосударственных стандартов международным стандартам, использованным

в качестве ссылочных в примененном международном стандарте

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

Введение

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

Стандарты комплекса ГОСТ Р 60 представляют собой совокупность отдельно издаваемых стандартов. Стандарты данного комплекса относятся к одной из следующих тематических групп: «Общие положения, основные понятия, термины и определения», «Технические и эксплуатационные характеристики», «Безопасность», «Виды и методы испытаний», «Механические интерфейсы», «Электрические интерфейсы», «Коммуникационные интерфейсы», «Методы моделирования и программирования», «Методы построения траектории движения (навигация)», «Конструктивные элементы». Стандарты любой тематической группы могут относиться как ко всем роботам и робототехническим устройствам, так и к отдельным группам объектов стандартизации — промышленным роботам в целом, промышленным манипуляционным роботам, промышленным транспортным роботам, сервисным роботам в целом, сервисным манипуляционным роботам, сервисным мобильным роботам, а также к морским робототехническим комплексам.

Настоящий стандарт относится к тематической группе «Общие положения, основные понятия, термины и определения» и распространяется на все виды сервисных роботов.

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

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

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

Требования безопасности, установленные в существующих стандартах (например, ГОСТ Р 60.1.2.1, ГОСТ Р 60.1.2.2, ГОСТ Р 60.1.2.3, ГОСТ Р 60.2.2.1), применимы на системном уровне, а также на уровне отдельного модуля. Руководящие указания по безопасности на модульном уровне, сформулированные в настоящем стандарте, обеспечивают соответствие стандартам типа С по безопасности робототехнических комплексов. Проблемы защищенности также важны при реализации открытых модульных подходов, поэтому они также представлены в настоящем стандарте.

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

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

Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО 22166-1:2021.

В настоящий стандарт внесены следующие технические отклонения по отношению к ИСО 22166-1:2021:

• - настоящий стандарт оформлен с соблюдением правил, установленных в ГОСТ Р 1.5, в соответствии с ГОСТ Р 1.7—2014 (пункт 7.2);

• - нормативные ссылки на международные стандарты заменены ссылками на соответствующие идентичные национальные стандарты Российской Федерации и межгосударственные стандарты, действующие в качестве национальных;

• - в разделе 3 определения терминов приведены в соответствии с идентичными национальными стандартами;

• - в подраздел 3.1 добавлено определение термина «киберзащищенность»;

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

ГОСТ Р 60.2.0.1—2022 (ИСО 22166-1:2021)

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

Роботы и робототехнические устройства

МОДУЛЬНЫЙ ПРИНЦИП ПОСТРОЕНИЯ СЕРВИСНЫХ РОБОТОВ

Часть 1

Общие требования

Robots and robotic devices. Modular principle of service robots structure. Part 1. General requirements

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

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

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

Настоящий стандарт предназначен для следующих групп пользователей:

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

• - разработчики и/или изготовители модулей, поставляющие их конечным пользователям или интеграторам роботов;

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

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

Настоящий стандарт не является стандартом безопасности.

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

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

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ IEC 61000 (все части) Электромагнитная совместимость (ЭМС)

ГОСТ IEC 61496-1 Безопасность механизмов. Защитная электрочувствительная аппаратура. Часть 1. Общие требования и испытания

ГОСТ IEC 61984 Соединители. Требования безопасности и испытания

ГОСТ ISO 10993 (все части) Изделия медицинские. Оценка биологического действия медицинских изделий

ГОСТ ISO 12100—2013 Безопасность машин. Общие принципы конструирования. Оценки риска и снижения риска

ГОСТ ISO 13849-1 Безопасность оборудования. Элементы систем управления, связанные с безопасностью. Часть 1. Общие принципы конструирования

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

ГОСТ И СО 14123-1 Безопасность оборудования. Снижение риска для здоровья от опасных веществ, выделяемых оборудованием. Часть 1. Основные положения и технические требования

ГОСТ ISO/IEC 17025 Общие требования к компетентности испытательных и калибровочных лабораторий

ГОСТ ISO/IEC 19896-1 Информационные технологии. Методы и средства обеспечения безопасности. Требования к компетенции специалистов по тестированию и оценке безопасности информационных технологий. Часть 1. Введение, основные понятия и общие требования

ГОСТ Р 60.0.0.3—2016/ИСО 9787:2013 Роботы и робототехнические устройства. Системы координат и обозначение перемещений

ГОСТ Р 60.0.0.4/ИСО 8373:2012 Роботы и робототехнические устройства. Термины и определения

ГОСТ Р 60.0.0.5/ИСО 19649:2017 Роботы и робототехнические устройства. Мобильные роботы. Термины и определения

ГОСТ Р 60.1.2.1/ИСО 10218-1:2011 Роботы и робототехнические устройства. Требования по безопасности для промышленных роботов. Часть 1. Роботы

ГОСТ Р 60.1.2.2/ИСО 10218-2:2011 Роботы и робототехнические устройства. Требования по безопасности для промышленных роботов. Часть 2. Робототехнические системы и их интеграция

ГОСТ Р 60.1.2.3/ISO/TS 15066:2016 Роботы и робототехнические устройства. Требования по безопасности для роботов, работающих совместно с человеком

ГОСТ Р 60.2.2.1/ИСО 13482:2014 Роботы и робототехнические устройства. Требования безопасности для роботов по персональному уходу

ГОСТ Р 60.3.0.1/ИСО 11593:1996 Роботы и робототехнические устройства. Промышленные манипуляционные роботы. Системы автоматической смены рабочего органа. Термины, определения и представление характеристик

ГОСТ Р 60.3.4.1/ИСО 9409-1:2004 Роботы и робототехнические устройства. Промышленные манипуляционные роботы. Механические интерфейсы. Круглые фланцы

ГОСТ Р 60.3.4.2/ИСО 9409-2:2002 Роботы и робототехнические устройства. Промышленные манипуляционные роботы. Механические интерфейсы. Стержни

ГОСТ Р 56205/IEC/TS 62443-1-1:2009 Сети коммуникационные промышленные. Защищенность (кибербезопасность) сети и системы. Часть 1-1. Терминология, концептуальные положения и модели

ГОСТ Р 57193 Системная и программная инженерия. Процессы жизненного цикла систем

ГОСТ Р ИСО/МЭК 7498-1 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель

ГОСТ Р ИСО/МЭК 15408 (все части) Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий

ГОСТ Р ИСО/МЭК 27001 Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования

ГОСТ Р ИСО/МЭК 27002 Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности

ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств

ГОСТ Р МЭК 60068 (все части) Испытания на воздействие внешних факторов

ГОСТ Р МЭК 60086-1 Батареи первичные. Часть 1. Общие требования

ГОСТ Р МЭК 60204-1 Безопасность машин. Электрооборудование машин и механизмов. Часть 1. Общие требования

ГОСТ Р МЭК 60990 Методы измерения тока прикосновения и тока защитного проводника

ГОСТ Р МЭК 61508 (все части) Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью

ГОСТ Р МЭК 61784-3 Промышленные сети. Профили. Часть 3. Функциональная безопасность полевых шин. Общие правила и определения профилей

ГОСТ Р МЭК 61800-5-2 Системы силовых электроприводов с регулируемой скоростью. Часть 5-2. Требования функциональной безопасности

ГОСТ Р МЭК 62061 Безопасность оборудования. Функциональная безопасность систем управления электрических, электронных и программируемых электронных, связанных с безопасностью

ГОСТ Р МЭК 62280 Железные дороги. Системы связи, сигнализации и обработки данных. Требования к обеспечению безопасной передачи информации

ГОСТ Р МЭК 62443-2-1 Сети коммуникационные промышленные. Защищенность (кибербезопасность) сети и системы. Часть 2-1. Составление программы обеспечения защищенности (кибербезопасности) системы управления и промышленной автоматики

ГОСТ Р МЭК 62443-3-3 Сети промышленной коммуникации. Безопасность сетей и систем. Часть 3-3. Требования к системной безопасности и уровни безопасности

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

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

В настоящем стандарте применены термины по ГОСТ Р 60.0.0.4, а также следующие термины с соответствующими определениями.

• 3.1 Общие термины

  • 3.1.1 уровень абстракции (abstraction layer): Интерфейс к системе, позволяющий получить доступ к некоторым или всем возможностям системы другим и, как правило, более абстрактным способом.

Примечание — Уровень абстракции для модуля такой же, как и в случае, когда система является модулем.

• 3.1.2 соединитель (connector): Физический механизм, обеспечивающий соединение и рассоединение частей системы.

Пример — Соединитель для передачи данных, питания, механический соединитель.

• 3.1.3 электрический интерфейс (electrical interface): Совокупность соединителей и электрических параметров, обеспечивающих передачу энергии, аналоговых или цифровых сигналов.

• 3.1.4 жизненный цикл выполнения (execution life cycle): Совокупность взаимосвязанных состояний и событий при выполнении функций части системы (модуля) или всей системы от момента ее создания до утилизации.

• 3.1.5 ошибка (error): Расхождение между расчетным, наблюдаемым или измеренным значением или состоянием и истинным, заданным или теоретически правильным значением или состоянием.

Примечание — См. [1 ], статья 192-03-02.

• 3.1.6 сбой (failure): Потеря способности функционировать должным образом.

Примечание — См. [1 ], статья 192-03-01.

• 3.1.7 дефект (fault): Неспособность функционировать должным образом из-за особого внутреннего состояния.

Примечание — См. [1], статья 192-04-01.

• 3.1.8 функция (function): Заданное целевое или характерное действие системы, компонента или модуля.

Примечание — См. [2], статья 3.1206-5.

• 3.1.9

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

[ГОСТ Р МЭК 61508-4:2012, статья 3.1.12]

• 3.1.10 слой аппаратных абстракций (hardware abstraction layer; HAL): Слой абстракций для ком-понента/модуля с аппаратными свойствами, обеспечивающий управление данным компонентом/моду-лем через программный интерфейс.

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

• 3.1.11 информационная модель (information model): Абстракция и представление объектов в управляемой среде, их свойств, атрибутов и операций, а также способа, которым они связаны друг с другом.

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

• 3.1.12

защищенность (security): Состояние защиты от опасностей, угроз, рисков или потери.

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

[ГОСТ Р ИСО 28002—2019, статья 3.60]

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

• 3.2 Термины, относящиеся к компонентам

  • 3.2.1 компонент (component): Часть некоторого объекта, являющаяся обособленной и идентифицируемой относительно объединения с другими частями для создания более крупного объекта.

Примечания

• 1 Компонент может быть программным или аппаратным. Компонент, который в основном является программным или аппаратным, может называться программным компонентом или аппаратным компонентом соответственно.

• 2 Компоненту не обязательно иметь какие-либо специфические характеристики, относящиеся к модульности.

• 3 В общем случае термины «компонент» и «модуль» используют взаимозаменяемо, но для избегания неоднозначности термин «модуль» использован для обозначения компонента, соответствующего положениям настоящего стандарта.

• 4 Модуль является компонентом, но компонент не обязательно является модулем.

• 3 .2.2 программный компонент (software component): Компонент, реализация которого является представлением алгоритма в виде компьютерной программы.

• 3 .2.3 аппаратный компонент (hardware component): Компонент, реализация которого состоит из физических элементов и, возможно, встроенного программного обеспечения, необходимого для его работы.

• 3.3 Термины, относящиеся к модулям

• 3.3.1 компонуемость (composability): Способность собирать модули логически и физически (без необходимости адаптации модулей или создания дополнительных интерфейсов) с использованием разных комбинаций в новых модулях.

Примечание — Компоновка, в отличие от интеграции, как правило, не требует значительных усилий.

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

Примечания

• 1 В ГОСТ Р 60.0.0.4 определен также термин «конфигурация (шарниров)», который представляет другое понятие.

• 2 Данный термин описывает результат некоторого процесса, т. е. некоторое состояние в нем. Процесс создания данного состояния описывает термин «конфигурирование» (3.3.3).

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

• 3.3.4 глубина детализации (granularity): Уровень, до которого модуль робота может быть разбит на отдельные модули.

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

Примечания

• 1 Информация о физических взаимосвязях включает механические характеристики (материал, форма, расположение, размер, усилия/моменты), электрические и электромагнитные характеристики, пневматические и гидравлические характеристики.

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

• 3.3.6 инфраструктура (infrastructure): Структурированные средства и ресурсы, поддерживающие работу модулей и систем.

• 3.3.7

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

[ГОСТ 30721—2020, статья 01.04.09]

• 3.3.8 интероперабельность (interoperability): Способность осуществлять связь, выполнять программы или передавать данные либо энергию между модулями, а также объединять модули физически и/или логически таким способом, который не требует от пользователя знаний об уникальных характеристиках отдельных модулей.

• 3.3.9 взаимозаменяемость (interchangeability): Характеристика модуля, определяющая возможность его использования для замены другого модуля.

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

• 3.3.10 механический интерфейс (mechanical interface): Физические средства соединения модулей, используемые для передачи физических усилий и облегчающие модулю выполнение своей функции и/или конфигурирование конструкции.

Примечания

• 1 Передаваемые физические усилия включают управляемые усилия для достижения поставленной цели как части запланированной функции и неуправляемые усилия — как преднамеренные (например, поддержка конструкции), так и непреднамеренные (например, демпфирование).

• 2 В ГОСТ Р 60.0.0.4 данный термин определен как механический интерфейс между манипулятором и рабочим органом. В настоящем стандарте данный термин применен в более широком смысле, подразумевая любой механический интерфейс между модулями робота.

• 3.3.11 модульный принцип построения (модульность) (modularity): Совокупность характеристик, позволяющая разделять системы на отдельные модули и перекомпоновывать.

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

Примечания

• 1 Модуль может обладать как аппаратными, так и программными свойствами. Он может состоять из других компонентов (аппаратных и программных) или из других модулей (аппаратных и программных).

• 2 Данное определение не требует и не препятствует использованию программного обеспечения с открытым кодом для реализации частей или всей функциональности открытого модуля.

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

• 4 Открытый модуль не обязательно является составным модулем, а также составной модуль не обязательно является открытым модулем.

• 3.3.13 пакет (package): Совокупность всех программных кодов, конфигурационной информации и файлов поддержки, необходимых для надлежащего функционирования модуля с программными свойствами.

Примечание — Пакеты могут зависеть от других пакетов.

• 3.3.14 характеристика модуля (module property): Атрибут или параметр модуля.

Пример — Характеристикой аппаратного модуля может являться момент привода. Характеристикой программного модуля может являться время отклика на новую команду.

• 3.3.15 профиль характеристик модуля (module property profile): Каталог значений подмножества характеристик модуля.

• 3.3.16 качество сервиса (quality of service): Уровень исполнения модулем своего сервиса для других связанных с ним модулей, обеспечивающий надлежащее выполнение общей работы.

• 3.3.17 реконфигурация (reconfiguration): Изменение конфигурации модульного робота для достижения намеченного изменения его функции.

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

• 3.3.19 модуль робота (robot module): Модуль, предназначенный для использования в качестве части модульного робототехнического комплекса.

Примечания

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

• 2 Примеры модулей робота, важных для модульного принципа построения сервисных роботов, представлены в приложении В.

• 3.3.20 самоконфигурация (self-configuration): Автоматический процесс изменения конфигурации модульного робота без вмешательства извне, за исключением инициации данного процесса при необходимости.

Примечание — Обычно конфигурирование (реконфигурирование) механических и электрических соединений выполняют вручную, а автоматический процесс применяют для конфигурации (реконфигурации) программных свойств.

• 3.3.21 программные свойства (software aspects): Информация о внешних программных характеристиках модуля и его интерфейса, а также о жизненном цикле выполнения функции данного модуля.

• 3.4 Термины, относящиеся к классификации модулей

  • 3.4.1 базовый модуль (basic module): Модуль, который не подлежит декомпозиции на более мелкие модули.

Пример — Базовыми модулями сервисного робота могут быть входные, обрабатывающие, выходные или инфраструктурные модули.

• 3.4.2 составной модуль (composite module): Модуль, состоящий из двух или нескольких модулей.

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

• 3.4.3 аппаратный модуль (hardware module): Модуль, реализация которого состоит только из физических элементов, включая механические элементы, электронные схемы и любое программное обеспечение, например встроенные микропрограммы, недоступное извне через коммуникационный интерфейс.

Примечание — Аппаратный модуль обладает аппаратными свойствами. Он состоит из аппаратных компонентов.

Примеры

• 1 Механический шарнир без электроники; к его аппаратным свойствам относятся размеры, кинематические характеристики, установочные поверхности на обоих концах, материал, жесткость, максимально допустимое усилие и момент и т. д.

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

• 3.4.4

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

[ГОСТ 19781—90, статья 15]

Примечание — Программный модуль обладает программными свойствами. Он состоит из программных компонентов.

• 3.5 Термины, относящиеся к категоризации модулей по их основной функции

  • 3.5.1 модуль привода (приводной модуль) [actuator module (actuating module)]: Выходной модуль, основной функцией которого является физическое перемещение робота или изменение среды вокруг робота в ответ на команды от других модулей с целью выполнения роботом задач по назначению.

  • 3.5.2 коммуникационный модуль (communication module): Модуль, который обеспечивает доступ к коммуникационным интерфейсам из внешней среды или обеспечивает взаимосвязь между модулями.

Примечание — Интерфейсы с внешней средой могут осуществляться с использованием Wi-Fi, мобильной сети, Ethernet и т. д.

• 3.5.3 вычислительный модуль (computing module): Модуль, который предоставляет вычислительные ресурсы для использования программными модулями.

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

• 3.5.4 инфраструктурный модуль (infrastructure module): Модуль, обеспечивающий средства и ресурсы для поддержки работы других модулей.

Примечания

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

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

• 3 .5.5 сенсорный модуль (sensing module): Входной модуль, предназначенный для сбора данных о внешней среде робота или о состоянии робота для использования другими модулями с целью поддержки робототехнического комплекса при выполнении задач по назначению.

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

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

• 4.1 Введение

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

• 4.2 Основные принципы модульности
  
  4.2.1 Общие положения

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

• - документировать выбранный модульный подход;

• - предоставить интеграторам всю необходимую информацию по использованию модуля.

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

• 4.2.2 Компонуемость

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

• 4.2.3 Интегрируемость

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

• 4.2.4 Интероперабельность

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

• 4.2.5 Глубина детализации модулей

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

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

• 4.2.6 Платформенная независимость

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

• 4.2.7 Открытость

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

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

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

• 4.2.8 Возможность повторного использования

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

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

• 4.2.9 Безопасность

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

• 4.2.10 Защищенность

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

• 4.3 Абстракция

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

• - поддерживать интероперабельность и возможность повторного использования модулей;

• - упрощать компьютерное моделирование и макетирование;

• - способствовать независимости реализации и платформенной независимости.

Примечания

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

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

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

• 4 .4 Электрические интерфейсы и коммуникационные протоколы

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

Примечания

• 1 Интерфейсы шин передачи данных и коммуникационные сети включают аппаратные и программные свойства. Концептуальный пример обобщенной компоновки интерфейсов, охватывающий функциональность, питание и рабочую среду, подробно рассмотренный в разделе 6, показан на рисунке 1.

• 2 В таблице 1 приведены некоторые примеры коммуникационных протоколов. Коммуникационные протоколы часто реализуются программно, но могут иметь и аппаратную реализацию. Коммуникационные протоколы представляют уровни со второго по седьмой эталонной модели взаимодействия открытых систем (ВОС), определенной в ГОСТРИСО/МЭК 7498-1.

1 — привод; 2 — датчик; 3 — питание; 4 — внешняя среда; 5 — функциональность; 6 — питание Рисунок 1 — Концептуальный пример компоновки интерфейсов между модулями

Таблица 1 — Примеры коммуникационных протоколов, которые могут быть использованы для модулей

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

• 4 .5 Взаимозаменяемость

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

• - уровень 1: перестановку модулей может осуществлять только изготовитель или интегратор робототехнического комплекса;

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

• - уровень 3: перестановку модулей может осуществлять пользователь при включенном роботе («горячая» замена);

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

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

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

Таблица 2 — Рекомендации для разных уровней взаимозаменяемости

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

• 4 .6 Характеристики модуля
  
  4.6.1 Общие положения

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

Примечание — Организация хранилища характеристик модуля в настоящем стандарте не рассматривается.

• 4.6.2 Идентификация модуля

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

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

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

• - тип модуля и/или идентификатор модуля;

• - наименование изготовителя и/или идентификатор изготовителя;

• - версию модуля;

• - дату изготовления;

• - серийный номер.

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

• 4.7 Компьютерное моделирование

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

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

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

• - электрические характеристики модуля, такие как требования к максимальной и средней мощности, потребляемой при работе;

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

• - интерфейсы для входных (датчики) или выходных (приводы) модулей, которые определяют формат и тип передаваемой информации;

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

• - метод, с помощью которого модуль привода воздействует на моделируемую среду.

Примечания

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

• 2 Можно также предоставить данные для компьютерного моделирования с помощью модели модуля.

• 4 .8 Типы данных для интероперабельности

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

Модульная структура должна также определять соглашения по общим составным типам данных. Рекомендуется определять приведенные ниже соглашения. Кроме того, существует небольшое число общих составных типов данных, построенных на этих соглашениях [14], а именно:

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

• b) ориентация в пространстве, которая может быть определена одним из двух способов. Обычно ориентацию задают в трехмерном пространстве кватернионом, который представлен четырьмя числами , где (и, v, и/) — ось вращения, а с и s — косинус и синус половины угла поворота соответственно. Иначе может быть задано только вращение вокруг оси z углом поворота вокруг этой оси, выраженном в радианах;

• с) позиция и ориентация мобильного робота, задаваемые в его стандартной системе координат, установленной в ГОСТ Р 60.0.0.3 и ГОСТ Р 60.0.0.5;

• d) геометрические данные двумерных и трехмерных объектов выбирают на основании действующих стандартов.

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

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

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

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

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

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

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

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

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

• - ГОСТ ISO 12100 — для оценки риска и снижения риска машин и механизмов;

• - ГОСТ Р 60.1.2.1, ГОСТ Р 60.1.2.2 и ГОСТ Р 60.1.2.3 — для промышленных роботов;

• - ГОСТ Р 60.2.2.1 — для роботов по персональному уходу;

• - ГОСТ ISO 13849-1, комплекс ГОСТ Р МЭК 61508 и ГОСТ Р МЭК 62061 — для функциональной безопасности.

Вопросы безопасности медицинских роботов рассмотрены в [15], [16] и [17].

В модульном робототехническом комплексе программное обеспечение может присутствовать в разных модулях робота. ГОСТ Р ИСО/МЭК 12207 и ГОСТ Р 57193 определяют процессы жизненного цикла при разработке программного обеспечения с целью обеспечения требуемого качества. ГОСТ Р МЭК 61508-3 устанавливает требования безопасности для программного обеспечения части системы управления, связанной с безопасностью. Требования безопасности для программного обеспечения применимы только к частям программного обеспечения, связанным с безопасностью, и рассмотрены в 7.2 и 7.4.

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

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

• - ГОСТ Р 56205, устанавливающий терминологию, концептуальные положения и модели применительно к безопасности систем промышленной автоматики и контроля;

• - ГОСТ Р МЭК 62443-2-1, определяющий элементы управления защищенностью систем промышленной автоматики;

• - ГОСТ Р МЭК 62443-3-3, определяющий уровни защищенности в системах управления.

Вопросы киберзащищенности машин рассмотрены в [18], а основные правила киберзащищенности определены в [19].

На рисунке 2 показана связь между рисками безопасности и защищенности. Изготовители модулей и интеграторы (а при необходимости и разработчики модульной архитектуры) должны следовать правилам и требованиям, установленным в применимых стандартах безопасности. Этому процессу соответствует горизонтальный ряд на рисунке 2. Риски защищенности модуля должны быть оценены с применением тех же условий использования модуля по назначению, прогнозируемого неправильного применения и «ограничений на машину» (по ГОСТ ISO 12100—2013, 5.3), которые использовались при анализе безопасности модуля. Процесс оценки и снижения рисков защищенности (вертикальный ряд на рисунке 2) следует выполнять как итеративный процесс: либо параллельно с шагами 1 и 2, показанными на рисунке 1 ГОСТ ISO 12100—2013 (раздел 4), либо в конце соответствующего процесса. Интегрированный процесс оценки и снижения рисков защищенности и безопасности (диагональный ряд на рисунке 2) следует выполнять как итеративный процесс. Если повышение уровня защищенности может привести к снижению уровня безопасности, то повышение уровня безопасности имеет приоритет над повышением уровня защищенности.

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

Увеличение безопасности

Для безопасности модуля

Рисунок 2 — Риски безопасности и защищенности для модулей роботов

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

Интегратор модулей должен учитывать следующую информацию:

• - взаимосвязь с внешней системой (физическое размещение, интерфейс и т.д.);

• - руководства по техническому обслуживанию на модульном и системном уровнях.

• 5.2 Безопасность на уровне робототехнического комплекса

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

Разработчики структуры модульного сервисного робота отвечают:

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

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

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

Примечания

• 1 Типичные варианты применения могут охватывать разные уровни безопасности, защищенности, совместной безопасности и защищенности, а также качества.

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

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

Интеграторы модулей должны отвечать:

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

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

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

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

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

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

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

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

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

• 5.3 Безопасность на уровне модуля

При разработке модуля необходимо учитывать требования стандартов по электрической и механической безопасности (в приложении D рассмотрены испытания модулей роботов на соответствие данным требованиям). Требования безопасности для программных модулей рассмотрены в 5.4.

Если конструкция двигателей предусматривает функцию останова, то в модуле должна быть предусмотрена функция безопасности, соответствующая требованиям ГОСТ Р МЭК 61800-5-2.

Для того чтобы предотвратить сбои из-за связи между модулями, в системе следует использовать связь по черному каналу (см. ГОСТ Р МЭК 62280 и ГОСТ Р МЭК 61784-3). При этом блок надежности модуля должен быть спроектирован как связанный с безопасностью, а тракт передачи информации должен гарантировать надежность реализации функции безопасности.

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

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

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

• 1 Определить намеченные применения, и для каждого применения описать максимальное число относящихся к нему деталей.

• 2 Для каждого применения гипотетического робототехнического комплекса должна быть представлена его конструкция. Должны быть рассмотрены все предсказуемые применения модуля. Кроме того, должны быть рассмотрены разумно прогнозируемые неправильные применения модуля.

Примечание — При необходимости может быть сделано предположение, что в системе есть супервизор безопасности (7.2 и 7.4).

• 3 Для каждого намеченного применения должны быть идентифицированы потенциальные опасности [в ГОСТ ISO 12100—2013 (приложение В) приведен список потенциальных опасностей, которые следует рассмотреть].

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

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

• 5 Изготовитель модуля должен выполнить оценку риска безопасности для каждого использования по назначению, чтобы определить соответствующий PL для любых относящихся к модулю функций, связанных с безопасностью. Для обеспечения данной функциональности целесообразно разработать для модуля локальные функции, связанные с безопасностью (см. «супервизор безопасности» в 7.2).

Примечание — Перечисленные шаги могут быть применены выборочно в разных ситуациях.

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

• - по использованию модуля;

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

• - о связанных с безопасностью функциях данного модуля;

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

Примечание — Требования безопасности, предъявляемые к интерфейсу оператора и аварийной остановке, установлены в ГОСТ Р МЭК 60204-1 и могут быть применены к модулям.

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

Пример — Два составных модуля, предложенные двумя разными изготовителями, имеют следующие возможности:

• - платформа 1 имеет двигатели с механически ограниченной максимальной скоростью платформы 1 м/с. Контроллер платформы принимает на входе заданную скорость движения и на выходе выдает значение текущей скорости, но оба эти параметра не связаны с безопасностью и для них не определен уровень эффективности защиты;

• - платформа 2 может развить максимальную скорость 2 м/с. Контроллер платформы обеспечивает связанное с безопасностью управление скоростью с высоким уровнем эффективности защиты. Поэтому задаваемое на входе значение скорости и текущее значение скорости на выходе являются связанными с безопасностью.

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

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

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

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

• 5.4 Основные вопросы защищенности

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

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

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

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

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

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

Примечание — В настоящее время не установлены уровни эффективности защищенности, на которые можно было бы сослаться.

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

• - подверженность атакам потенциальных взломщиков (внутренних и внешних);

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

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

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

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

В настоящем стандарте определены следующие объединенные уровни безопасности и защищенности для классификации модулей:

• 1 Никакой безопасности или защищенности модуля не требуется. Данное отсутствие требований к безопасности и защищенности может быть применимо к небольшим и легким роботам, которые не могут причинить вред человеку и не имеют связей с какими-либо внешними системами.

• 2 Требуется защищенность модуля. Данный уровень применим, когда при использовании модуля по назначению присутствуют связи внутри робота или с внешними системами. В разделе 6 определены меры по обеспечению защищенности, связанные с аппаратным обеспечением, а в разделе 7 представлены меры по достижению защищенности модуля, связанные с программным обеспечением и коммуникациями.

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

• 4 Требуется как безопасность, так и защищенность модуля. В данном случае система должна соответствовать требованиям безопасности и требованиям защищенности. На рисунке 2 показан процесс обеспечения адекватной оценки риска безопасности и защищенности.

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

• 5 .5 Действия по проектированию защищенности модуля

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

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

• 2 Рассмотреть предсказуемые использования по назначению и потенциальные прикладные задачи модуля.

Примечание — При необходимости может быть сделано предположение, что в системе присутствует супервизор защищенности (7.2 и 7.4).

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

• 4 Обеспечить соответствие программного обеспечения модуля требованиям защищенности, установленным в 7.4.

• 5 Проверить наличие руководств по защищенному обмену данными в соответствии с 7.4.

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

• 7 Выполнить оценку риска защищенности независимо для каждого модуля и оценить последствия для сценариев применения, определенных на шаге 2.

• 5 .6 Физическая защищенность модулей

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

• - защищенность коммуникационных портов;

• - физический доступ к внутренним компонентам извне.

Примечание — Модули могут быть связаны через системы шин с соседними модулями. Таким образом, нарушения защищенности могут передаваться от одного модуля к другому.

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

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

• - механический замок с физическим ключом;

• - механический замок с приводом задвижки.

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

• 5 .7 Киберзащищенность модулей

Модуль (или его микропрограммы и программное обеспечение) должен:

• - препятствовать несанкционированному вмешательству;

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

• - обеспечивать защищенность коммуникаций.

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

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

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

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

• - применение мер, обеспечивающих целостность и конфиденциальность данных, таких как защита данных, связь по защищенным сетям;

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

Примечание — Общие вопросы защищенности для систем промышленной автоматики рассмотрены в [20], вопросы защищенности, связанные с функциональной безопасностью систем управления, рассмотрены в [21].

• 6 Конструирование модулей с аппаратными свойствами

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

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

Таблица 3 — Примеры модулей и проблемы их соединяемости

Примечание — Проблемы соединяемости модулей с аппаратными свойствами могут быть либо физическими (например, по питанию или данным), либо могут относиться к более абстрактным взаимодействиям (например, по обеспечению безопасности и защищенности, по взаимодействию с внешней средой или с другой механической конструкцией). Например, если модуль отмечен в графе «Защищенность», то это означает, что данный модуль выполняет функцию, связанную с защищенностью, или обменивается какими-либо данными с другими модулями, связанными с защищенностью.

• 6.2 Требования и руководства к аппаратным особенностям модулей
  
  6.2.1 Механические интерфейсы

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

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

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

• - спецификация соединителей с заглушками (слепые или пустые соединители, не востребованные модулем);

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

• - спецификация кабельного канала для шлейфа шины данных и/или питания;

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

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

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

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

• - об отсутствии нарушений в соединениях для данных, сигналов и питания при позиционировании и фиксации интерфейса модуля;

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

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

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

• - коаксиальные и/или конические конструкции для уменьшения углового или поперечного смещения при сопряжении для избегания износа, задира или повреждения точек контакта;

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

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

Примечание — Для модулей сервисных роботов могут быть использованы стандарты на интерфейсы промышленных роботов, такие как ГОСТ Р 60.3.4.1, ГОСТ Р 60.3.4.2 и ГОСТ Р 60.3.0.1.

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

• - данные из системы автоматического проектирования механических узлов;

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

• - данные о разводке контактов.

• 6.2.1.2 Точность и надежность соединения

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

• - питание;

• - данные;

• - сигналы защищенности;

• - сигналы безопасности;

• - механическая конструкция.

  
  
  

а) Соединение между шарнирами Ь) Соединение между шарниром и рабочим органом

• 1 — механическая конструкция; 2 — данные; 3 — питание; 4 — сигналы защищенности; 5 — сигналы безопасности

Рисунок 3 — Пример характеристик сопряжения для модульного шарнира

Связанные с безопасностью модули должны обеспечивать безопасное соединение между ними. Для соединения между модулями должна быть задана точность.

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

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

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

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

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

• 6.2.1.3 Жесткость соединения

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

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

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

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

• 6.2.1.4 Механические соединители и соединения

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

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

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

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

Электрические соединители должны соответствовать требованиям ГОСТ IEC 61984.

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

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

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

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

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

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

• - правильное физическое взаимодействие разных соединителей по размерам и электрическим параметрам;

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

• - отсутствие утечек жидкостей или газов в случае передачи гидравлической или пневматической энергии через интегрированные соединители на интерфейсе.

• 6.2.2 Сопряжение с источниками питания

Источники питания обеспечивают подачу мощности или энергии на все приводы. Изготовитель должен выбрать надлежащий тип энергии, такой как электрическая (постоянного или переменного напряжения), пневматическая или гидравлическая энергия, например, изготовителю следует обратить внимание на широко используемые напряжения питания, такие как 5 В, 12 В, 24 В или 48 В.

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

Пример — Каждому шарниру манипулятора требуется ток 5 А, поэтому если шесть шарниров соединены последовательно, то первый модуль должен быть способен пропускать через себя ток 30 А.

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

• 6.2.3 Другие особенности описания модулей

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

• - кинематические и динамические характеристики, такие как геометрические параметры, масса, центр масс, момент инерции и преобразование координат;

• - классификация по степени защиты (код IP), установленная в [22].

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

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

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

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

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

• - точность и разрешающая способность;

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

• - для приводов: точность, максимальная и номинальная мощность/момент, максимальная и номинальная скорость, а также пространственное расположение во внутренней системе координат при необходимости.

• 7 Конструирование модулей с программными свойствами

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

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

• - модель «публикация/подписка»;

• - модель «клиент/сервер»;

• - модель «доска объявлений с разделяемой памятью».

Программные модули для роботов могут быть разработаны на основе платформы промежуточного программного обеспечения, примерами которой являются ROS, OpenRTM, OPRoS и OROCOS. Требования обеспечения безопасности и защищенности модулей с программными свойствами изложены в разделе 5.

Таблица 4 — Модели программных коммуникационных интерфейсов для разных целей

• 7.2 Информационная модель
  
  7.2.1 Общие положения

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

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

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

Примечание — Программные модули могут быть определены с использованием существующих спецификаций, таких как OMG RolS [23] для интерфейса с сервисами или OMG RLS [14] для представления местоположения и систем координат.

• 7.2.2 Модель обмена информацией между модулями

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

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

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

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

• а) чтение и запись данных;

• Ь) вызов сервисов;

• с) регистрацию и обработку событий:

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

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

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

• - запрос с ответом, запрос без ответа;

• - подписка/публикация;

• - доска объявлений (с разделяемой памятью).

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

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

• - обеспечение поддержки промежуточного программного обеспечения;

• - обеспечение поддержки правил кодирования/декодирования для обмена информацией между двумя или несколькими промежуточными программными платформами;

• - обеспечение поддержки информации для данного подраздела, определенной в 7.2.3, 7.2.4 и 7.4.2.

• 7.2.3 Модель доступа к характеристикам и доступ к ней

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

• а) информация разработчика по данному модулю;

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

• с) поддерживаемый режим связи (например, публикация/подписка, клиент/сервер, доска объявлений и т. д.);

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

• е) информация, связанная с безопасностью (например, требуемые уровни PL и SIL).

Помимо этого, рекомендуется, чтобы модуль имел следующие характеристики:

• f) тип вызова сервисов (блокирующий или неблокирующий) из внешней среды модуля;

• д) информация, поступающая из внешней среды модуля;

• h) значения параметров при инициализации модуля, необходимые для правильного выполнения модулем своих функций;

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

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

Примеры

• 1 Все модули колес должны быть правильно ориентированы до того, как манипуляторы и/или технологическое оборудование робота начнут работать.

• 2 Модуль лазерного датчика или модуль камеры должен быть инициализирован и приведен в работоспособное состояние до того, как его можно будет использовать для навигации.

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

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

• - присвоение значений характеристикам;

• - считывание значений характеристик.

• 7.2.4 Модель обработки и исправления ошибок

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

Примечание — Ошибка является явным проявлением дефекта.

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

Рисунок 4 — Сбои, связанные с безопасностью и не связанные с безопасностью

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

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

• - отправлять и принимать данные о состоянии ошибки и исправлении ошибки внешним модулям и от внешних модулей (например, от модуля менеджера безопасности) в соответствии с 7.4;

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

Примечание — Ошибки, не связанные с безопасностью, относятся к другим ошибкам;

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

• - применять методы обработки неизвестных ошибок.

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

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

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

• 7.2.5 Взаимодействие программных модулей

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

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

• а) информация, которой обмениваются модули, при необходимости (см. 7.2.2);

• Ь) информация для управления модулем (см. 7.4.2);

• с) информация, используемая в профиле характеристик модуля (см. 7.2.3);

• d) информация по обработке и исправлению ошибок (см. 7.2.4).

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

• е) установленная информационная модель обмена информацией между модулями и промежуточным программным обеспечением (см. 7.2.2);

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

• f) установленная модель слоя аппаратных абстракций или драйвера устройства.

Примечание — Профиль характеристик хранится в репозитории профилей.

• 7.3 Архитектурная модель программных модулей
  
  7.3.1 Общие положения

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

  
  
  

  Роботы, серверы, датчики, приводы, интегрированная среда разработки

  
  

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

  
  

Рисунок 5 — Архитектура построения программного обеспечения для модульного принципа построения сервисных роботов

Репозиторий профилей управляет профилями, используемыми модулями.

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

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

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

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

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

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

• 7.3.2 Требования к программным модулям

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

Примеры

• 1 Примерами характеристик модуля являются: номер версии, тип операционной системы, вид выполнения, например периодическое, случайное, в реальном времени или не в реальном времени, а также характеристики модуля, связанные с аппаратным обеспечением. Примерами значений характеристик модуля являются: значения для инициализации модуля, значения, необходимые для выполнения про-граммного модуля, например тип операционной системы, поддерживаемые коммуникационные протоколы, а также поддерживаемые типы сервисов и типы событий.

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

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

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

• а) поддержка обмена информацией с другими модулями с помощью установленной информационной модели (см. 7.2.2);

• Ь) обеспечение гарантированного качества обслуживания (например, характеристик реального времени), при необходимости;

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

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

• d) создание одного или нескольких экземпляров с уникальными идентификаторами для каждого программного модуля в данной прикладной задаче;

• е) поддержка управляемости со стороны задачи, управляющей жизненным циклом выполнения данного модуля, показанного на рисунке 6;

• f) поддержка безопасности на уровне модуля в зависимости от типов ошибок, которые могут возникнуть в программном модуле, в его профиле характеристик и в его связях с другими модулями;

• д) поддержка защищенности на уровне модуля, если модуль имеет доступ ко внешним модулям;

• h) наличие профиля, содержащего значения характеристик модуля (см. 7.2.3);

• i) поддержка платформенной независимости программного обеспечения.

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

Рисунок 6 — Жизненный цикл выполнения программного модуля, включая обработку ошибок

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

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

Для ошибок, обработанных в связанной с безопасностью части системы управления, процедуры исправления ошибок (особенно для события «Исправление при выполнении») должны соответствовать требованиям ГОСТ ISO 12100, чтобы предотвратить опасности из-за неожиданных пусков.

• 7.4 Требования к программным модулям, связанные с безопасностью и защищенностью
  
  7.4.1 Общие положения

  Программные модули, связанные с безопасностью, должны быть разработаны на основе требований, установленных в разделе 5. Защищенность таких модулей относится к киберзащищенности и определена в 5.7—5.10. В данном подразделе определен модуль менеджера безопасности/защищенности (см. рисунок 5), предназначенный для решения проблем безопасности/защищенности, которые не могут быть обработаны внутри функционального программного модуля. Следует отметить, что модуль менеджера безопасности/защищенности может быть реализован как один интегрированный модуль или как два независимых модуля: модуль менеджера безопасности и модуль менеджера защищенности. Данные модули могут также быть реализованы в виде архитектур с избыточностью для обеспечения соответствия подходящим уровням PL/SIL.

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

• 7.4.2 Взаимодействие модулей с менеджером безопасности/защищенности

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

• - информацию об ошибках, предоставляемую модулем;

• - информацию об исправлении ошибок, которую получает модуль.

Модуль менеджера безопасности должен тщательно контролировать информацию об ошибках, получаемую от каждого связанного с безопасностью модуля, и предоставлять каждому модулю информацию для выполнения операции остановки или других операций по обеспечению безопасности. Операция остановки может вызывать остановку робота или остановку модулей, связанных с данным конкретным событием, вызвавшим ошибку. Остановка и перезапуск должны соответствовать требованиям применимых стандартов безопасности, например общие требования к безопасности установлены в ГОСТ ISO 12100, требования к остановке установлены в ГОСТ Р МЭК 60204-1.

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

• - пакетов, программных модулей и их профилей;

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

• - входных и выходных данных модулей.

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

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

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

• 8 Руководство по эксплуатации

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

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

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

• - инструкции по применению всего комплекса;

• - назначение предупреждающих знаков и других маркировок и индикаторов на роботе;

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

Рекомендовано предоставление интегратором сервисного робота руководств по эксплуатации для каждого модуля в роботе.

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

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

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

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

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

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

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

• 8.2 Маркировки или обозначения

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

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

• - наименование изготовителя;

• - серийный номер;

• - знаки сертификации по безопасности и защищенности при наличии.

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

• - наименование разработчика;

• - тип и номер версии программного модуля;

• - тип операционной системы;

• - серийный номер.

• 8.3 Информация для пользователей

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

• а) подробное описание модуля:

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

• - краткое описание входящих в него базовых модулей и/или составных модулей, содержащее: - для аппаратного модуля:

• 1) наименование изготовителя и контактные данные, включая страну;

• 2) тип и номер версии модуля;

• 3) характеристики соединений модуля с другими модулями (направленность соединителей, расположение контактов и т. д.);

• 4) серийный номер при наличии;

• 5) номинальные значения по питанию [например, значение или номинальный диапазон напряжения питания в вольтах (постоянного или переменного), номинальная частота, при необходимости, давление воздуха в пневмосистеме и т д.];

• 6) номинальная мощность в ваттах или номинальный ток в амперах;

• 7) тип связи при необходимости;

• 8) знак сертификации безопасности при наличии;

• 9) характеристики защищенности при наличии;

• 10) масса в килограммах и габариты в миллиметрах;

• - для программного модуля:

• 1) наименование разработчика и контактные данные, включая страну;

• 2) тип и номер версии программного модуля;

• 3) тип операционной системы и другие подробности;

• - серийный номер, если необходимо;

• - особенности сопряжения модуля, например, тип модулей, подходящих для подключения, поддерживаемые аппаратные модули (например, для механического/электрического подключения) или совместимые программные модули;

• - рабочая среда для модуля;

• - способ инсталляции для программных модулей при необходимости;

• - детали подключения к другим модулям;

• - перечень принципов модульности в соответствии с разделом 4, которым соответствует модуль;

• Ь) подходящие варианты применения, включая информацию, связанную с безопасностью и защищенностью, при наличии;

• с) детали задания и корректировки значений характеристик модуля;

• d) перечень заменяемых базовых и составных модулей при наличии;

• е) перечень известных дефектов или ошибок;

• f) способ зарядки аккумуляторной батареи при наличии;

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

• h) перечень расходных материалов и периодичность планового технического обслуживания.

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

• 8.4 Информация по обслуживанию

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

Информация по обслуживанию должна содержать:

• а) подробное описание модуля и требований к его техническому обслуживанию;

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

• с) следующие данные (если применимо к данному модулю):

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

• - последовательность проверочных операций при техническом обслуживании;

• - периодичность осмотра;

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

• - руководство по регулировке, техническому обслуживанию и ремонту при необходимости;

• - перечень рекомендуемых запасных частей для аппаратных модулей;

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

• d) подробные конструкторские чертежи и электрические блок-схемы;

• е) перечень известных дефектов или ошибок и их описание;

• f) перечень расходных материалов и периодичность планового технического обслуживания.

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

Шаблон представления модуля робота

А.1 Общий шаблон

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

Таблица А.1 — Описание стандартного шаблона представления модуля робота

Наименование модуля:

Наименование конкретного модуля или класса модулей

Описание:

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

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

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

Идентификатор модуля:

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

Примеры:

Примеры типичных применений модуля

Аппаратные свойства:

Краткое изложение аппаратных свойств модуля в соответствии с разделом 6 (с использованием примеров, если возможно)

Программные свойства:

Краткое изложение программных свойств модуля в соответствии с разделом 7 (с использованием примеров, если возможно)

Характеристики модуля:

Перечень характеристик модуля в соответствии с разделами 6 и 7

Входы:

Перечень входов модуля

Выходы:

Перечень выходов модуля

Функция/функциональность:

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

Инфраструктура:

Вид предоставляемой инфраструктурной поддержки и/или защиты окружающей среды (например, шины питания, система управления базой данных, шина данных с указанием наличия или отсутствия обеспечения безопасности/защищенности, код защиты IP и т. д.)

Безопасность:

Требования безопасности на уровне модуля и уровне системы (например, для соответствия требуемым уровням эффективности защиты) в соответствии с 5.1—5.3

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

Защищенность:

Требования защищенности на уровне модуля и уровне системы (например, от несанкционированного доступа или для гарантии необходимого уровня конфиденциальности и т. д.). Данные требования защищенности относятся как к аппаратному, так и к программному обеспечению в соответствии с 5.1, 5.4—5.7

Моделирование:

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

А.2 Дополнения к шаблону представления модуля робота, относящиеся к аппаратному обеспечению

В дополнение к описанию общего шаблона, представленного в таблице А.1, в таблице А.2 приведена дополнительная информация, которую следует включать в шаблон представления модулей с аппаратными свойствами.

Таблица А.2 — Дополнительная информация для модулей с аппаратными свойствами

Характеристики модуля:

Перечень характеристик модулей с аппаратными свойствами, таких как физический размер, тип интерфейса, механические и электрические характеристики

Входы:

Перечень входов, таких как цифровой/аналоговый датчик и командные сигналы, а также другие коммуникации между модулями и т. д.

Выходы:

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

Функциональность:

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

Инфраструктура:

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

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

Моделирование:

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

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

Примеры модулей роботов

• В.1 Примеры модулей с аппаратными свойствами

  • В.1.1 Вращательный шарнир с приводом

Наименование модуля:

Вращательный шарнир с приводом

Описание:

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

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

ISO Inc.

Идентификатор модуля:

Шарнир J001

Примеры:

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

Аппаратные свойства:

• - на обоих концах шарнира имеются соединительные фланцы типа 001В с установленными соединителями для передачи питания, шины CAN и сигнала безопасного отключения момента;

• - сервисный порт для непосредственного доступа к интегрированной электронике по протоколу USB;

• - код защиты: IP 54

Программные свойства:

Коммуникационный протокол: CANOpen

Характеристики модуля:

• - размеры: 0 80 мм * 70 мм;

• - вес: 1,2 кг;

• - коэффициент редукции: 1:30;

• - диапазон поворота: ± 270°;

• - максимальная скорость шарнира: 90°/с;

• - максимальный вращающий момент: 100 Нм/20 Нм в прямом/обратном направлениях;

• - жесткость шарнира: максимальное смещение 0,5 мм/1° при максимальной нагрузке;

• - номинальный вращающий момент: 10 Нм;

• - номинальный ток через соединитель: 10 А;

• - потребляемая мощность: 50 Вт;

• - точность: ± 0,5°;

• - повторяемость: ± 0,3°;

• - ограничения [вращающий момент (Нм), положение (рад), скорость (рад/с)]

Входы:

• - заданные значения положения (рад), скорости (рад/с), вращающего момента (Нм);

• - сигналы для функций обеспечения безопасности;

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

Выходы:

• - фактические положение (рад), скорость (рад/с), вращающий момент (Нм);

• - состояние, предупреждения, ошибка, ток, напряжения, температура, диагностическая информация

Функциональность:

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

Инфраструктура:

• - источник питания: 24 В постоянного тока (18 В—30 В), 50 Вт;

• - условия внешней среды: температура от 5 °C до 35 °C, влажность менее 90 % без конденсата

Безопасность:

Функции обеспечения безопасности соответствуют ГОСТ Р МЭК 61800-5-2.

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

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

Защищенность:

Для доступа к фланцу 001В и крышке порта USB требуется стандартный инструмент

Моделирование:

Файлы с кинематической и динамической моделями. Параметры статической модели включают удерживающий, номинальный и опрокидывающий моменты; параметры динамической модели включают скорость, ускорение и ширину полосы пропускания

• В.1.2 Источник питания

Наименование модуля:

Модуль источника питания на аккумуляторной батарее

Описание:

Модуль аккумуляторной батареи с системой управления питанием, обеспечивающий на выходе 24 В постоянного тока

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

ISO Inc.

Идентификатор модуля:

Источник питания Р001

Примеры:

Данный источник может быть использован для питания мобильной платформы или экзоскелета

Аппаратные свойства:

• - соединитель для подачи питания (2 контакта);

• - соединитель для ввода/вывода данных (4 контакта);

• - код защиты: IP 65

Программные свойства:

Коммуникационный протокол RS 232, программное обеспечение управления батареей, включая аварийную сигнализацию

Характеристики модуля:

• - номинальные значения характеристик: 24 В, 5 А постоянного тока, 20 А максимум;

• - емкость: 5 А час;

• - выходное напряжение: 25 В (максимальное), 21 В (отключает управление питанием);

• - зарядка: 28 В—35 В, потребление тока до 5 А

Входы:

• - подключение зарядного устройства;

• - включение/выключение батареи

Выходы:

• - выходная мощность;

• - сигнал ошибки

Функциональность:

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

Инфраструктура:

Условия внешней среды: температура от 5 °C до 35 °C, влажность менее 90 % без конденсата

Безопасность:

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

Защищенность:

Не имеет отношения к данному модулю

Моделирование:

Модели функционирования для разных сценариев использования модуля представлены на веб-сайте (указать URL)

• В.2 Примеры модулей с программными свойствами

  • В.2.1 Распознавание

Наименование модуля:

Модуль распознавания зрительных образов

Описание:

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

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

ISO Inc.

Идентификатор модуля:

VRM001

Примеры:

Распознавание лиц

Аппаратные свойства:

Отсутствуют

Программные свойства:

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

Характеристики модуля:

• - размещение базы данных, например, путь, IP и номер порта, URL;

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

• - размер изображения (в пикселях);

• - число кадров изображения в секунду (если на входе движущееся изображение)

Входы:

Изображение или поток видеоданных

Выходы:

Результат распознавания зрительного образа с заданной степенью достоверности (или точности), например, имя распознанного человека

В.2.2 Локализация

Наименование модуля:

Модуль локализации

Описание:

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

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

ISO Inc.

Идентификатор модуля:

Идентификатор, присвоенный изготовителем

Примеры:

Локализация на основе лазерного сканирования

Аппаратные свойства:

Отсутствуют

Программные свойства:

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

Характеристики модуля:

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

• - размещение опознавательных знаков, картографическая информация или информация об опасных зонах

Входы:

• - данные сканирования (от модуля лазерного сканирования);

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

Выходы:

Пространственное расположение робота с заданным уровнем достоверности (или точности)

Функция/Функциональность:

• - получение данных от модуля лазерного сканирования;

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

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

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

• - корректировка пространственного расположения

Инфраструктура:

Промежуточное программное обеспечение

Безопасность:

Предупреждение или остановка в соответствии с применимым стандартом, если робот входит в опасную зону

Защищенность:

Аутентификация

Моделирование:

Не имеет отношения к данному модулю

• В.З Примеры широко применяемых составных модулей
  
  В.3.1 Общие положения

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

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

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

• В.3.2 Модуль манипулятора

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

Наименование модуля:

Модуль манипулятора

Описание:

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

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

Контактная информация

Идентификатор модуля:

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

Пример:

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

Аппаратные свойства:

• - основание, кожухи, двигатели, механический интерфейс

Программные свойства:

• - кинематический модуль;

• - реализация коммуникационного протокола;

• - модуль управления рукой;

• - модуль координации управления шарнирами

Характеристики модуля:

• - степени подвижности: типы шарниров (2D, 3D, вращательный/призматический), конфигурация манипулятора;

• - диапазоны шарниров: диапазон перемещения, допуски;

• - длина и расположение (или тип) модуля звена, который соединяет шарниры;

• - полезная нагрузка в диапазоне пространственных расположений: допустимый вес (кг) или усилие (Н) на рабочем органе в статических и динамических условиях;

• - рабочий диапазон перемещения руки (м х м х м) относительно основания;

• - максимальная скорость (м/с) и ускорение (м/с2) рабочего органа (могут зависеть от пространственного расположения)

Входы:

Изготовитель должен определить нумерованный список команд, таких как:

• - задание значений для пространственного расположения, скоростей;

• - перемещение в пространственное расположение, заданное кватернионом;

• - ограничения на усилие/скорость рабочего органа

  Выходы: Фактическое пространственное расположение, определенное как х, у, z (в метрах) и ориентация в кватернионах: - фактическая пространственная скорость рабочего органа; - фактическая и проектная пространственная рабочая зона; - фактические скорости в шарнирах (м/с, рад/с), ускорение и усилие (момент) отдельного шарнира; - рабочее состояние, предупреждения, ошибки, фактические токи, напряжения, температуры
  Функция/Функциональность: - прямая кинематическая задача, обратная кинематическая задача, планирование движения, динамика; - начало/прекращение движения (включение, выключение); - функции обнаружения перегрузки, определения состояния (нормально/ошибка), торможения/удержа-ния, включения/выключения; - предоставление интерфейсов для останова, возврата в исходную позицию; - предоставление интерфейсов для задания/получе-ния усилия/момента, задания/получения положения, задания/получения скорости на основе интерфейса со слоем аппаратных абстракций; - периодическая передача значений усилий/момен-тов в шарнирах на все шарниры, если требуется; - прогнозирование генератором траектории движения в рабочей зоне для повышения эффективности		Модуль управления кинематикой	—	Модуль управления рукой с коммуникациями
  				Модуль координации управления шарнирами
  				1	1..*
  				Модуль шарнира

Инфраструктура:

• - несущие конструкции звеньев/шарниров для обеспечения механической поддержки;

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

• - источник питания;

• - коммуникационная шина данных;

• - локальный и/или распределенные контроллеры манипулятора

Безопасность:

Модуль соответствует применимым стандартам безопасности, как установлено в разделе 5 (например, ГОСТ Р МЭК 61508-3 или ГОСТ Р МЭК 60204-1).

Функция защитной остановки модуля соответствует уровню PL d согласно ГОСТ ISO 13849-1

Безопасность на уровне модуля: Модуль предоставляет следующие функции обеспечения безопасности:

• - ограничение усилия при столкновении, имеющее уровень PL b (чувствительная кожа);

• - ограничение перегрузки;

• - управление ограничением скорости в соответствии с ГОСТ Р 60.1.2.1 и ГОСТ Р 60.1.2.2.

Безопасность на уровне системы: Модуль предоставляет следующую, связанную с безопасностью информацию:

• - состояние модуля;

• - прогнозирование генератором траектории движения в рабочей зоне для снижения риска столкновения (уровень PL а);

• - расчет расстояния остановки в трехмерном пространстве для номинальных скоростей;

• - задание скорости рабочего органа;

• - спецификация внутренних ошибок, способных вызвать серьезные неисправности или снижение производительности

Защищенность:

Модуль может обеспечить одну или несколько из следующих функций защищенности:

• - все коммуникации между модулями соответствуют руководствам, представленным в разделе 7;

• - все входы организованы с использованием механизмов обнаружения ошибок;

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

• - информация по использованию команд управления движением, включая авторизацию

Моделирование:

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

• В.3.3 Модуль мобильной платформы

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

Наименование модуля:

Модуль мобильной платформы

Общее описание:

Модуль перемещения включает:

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

• - отсек полезного груза;

• - способы перемещения: традиционные колеса, всенаправленные колеса, шаровые колеса, разнообразные варианты шагания, гибридные способы перемещения, лазание, ползание, плавание и т. д.

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

Контактная информация

Идентификатор модуля:

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

Примеры:

Колесная мобильная платформа с аварийными кнопками, лазерным дальномером и бамперами

Безопасность:

Модуль соответствует применимым стандартам безопасности, как установлено в разделе 5 (например, ГОСТ Р МЭК 61508-3 или ГОСТ Р МЭК 60204-1).

• - выбираемые расстояния остановки на конкретных скоростях для сконфигурированной системы;

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

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

• - уровни эффективности защиты, предоставляемые данным модулем: аварийная остановка (PL d), вход для защитной остановки (PL d)

Защищенность:

Все коммуникации между модулями должны соответствовать руководствам, представленным в разделе 5:

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

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

• - команда движения должна включать информацию об авторизации

Моделирование:

Виртуальная статическая и динамическая модель мобильной платформы

• В.3.4 Модуль взаимодействия человек—робот

Модуль взаимодействия человек—робот (ВЧР) предоставляет человеку средства для взаимодействия с роботом, обеспечивая информацию о намерениях робота и передачу команд или информации роботу.

Наименование модуля:

Модуль взаимодействия человек—робот

Общее описание:

Модуль ВЧР может выполнять следующие функции:

• - обнаружение/идентификацию человека;

• - взаимодействие с человеком (пользователем) с использованием речи, звука, света, сенсорных экранов

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

Контактная информация

Идентификатор модуля:

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

Примеры:

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

• - модуль ВЧР может иметь внутренние субмодули, включая, например, субмодуль распознавания лиц, субмодуль вывода информации через динамик;

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

• - модуль, переводящий текст в речь;

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

Аппаратные свойства:

• - модуль вывода информации через динамик;

• - сенсорный экран;

• - световые сигналы

Программные свойства:

• - программный модуль координации;

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

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

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

  Характеристики модуля: - программный модуль, переводящий текст в речь, формат сообщений для воспроизведения через динамик; - модуль распознавания лиц, формат базы данных; - API для сенсорного экрана; - информация о состоянии и ошибках; - условия эксплуатации, например, диапазоны температуры и влажности внешней среды
  Входы: - сообщения для воспроизведения через динамик; - информация, вводимая пользователем с сенсорного экрана
  Выходы: - результат обнаружения/идентификации человека; - состояние (подключения к базе данных или к серверу распознавания); - ошибки (системы или обнаружения человека); - передача входной информации от пользователя с сенсорного экрана
  Функция/Функциональность: Модуль распознавания лиц с помощью модуля распознавания: - рабочий режим; - речевой программный модуль, конвертирующий текст в речь, воспроизводимую через динамик; - программный модуль координации, управляющий последовательностью подключения интерфейсов и данных; - обработка взаимодействия с пользователем через сенсорный экран; - модуль идентификации жестов; - модуль идентификации голосовых команд
  		Коммуникационный модуль
  		Модуль координации взаимодействия человек-робот (ВЧР)
  		Модуль конвертации текста в речь
  		Модуль динамика		Модуль распознавания
  Инфраструктура: Промежуточное программное обеспечение, внешний сервер распознавания, база данных с изображениями и сообщениями
  Безопасность: Модуль соответствует применимым стандартам безопасности, как установлено в разделе 5 (например, ГОСТ Р МЭК 61508-3 или ГОСТ Р МЭК 60204-1): - оценка модуля на функциональную безопасность (комплекс ГОСТ Р МЭК 61508); - предупреждающие сообщения для пользователя (в соответствии с применимыми стандартами); - учет человеческого фактора и удобства использования
  Защищенность: - модуль доступен только для защищенных данных; - средства предотвращения использования распознавания лиц не по назначению с обеспечением минимального уровня конфиденциальности; - доступ к базе данных и серверу распознавания через защищенное соединение
  Моделирование: Не имеет отношения к данному модулю

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

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

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

В данном приложении представлены типичные примеры модульных конструкций серверных роботов, соответствующих концепциям и руководствам, установленным в настоящем стандарте; они охватывают аппаратную реализацию, программное обеспечение, а также вопросы безопасности и защищенности, представленные в разделах 5—7. В С.2 представлен модульный мобильный робототехнический комплекс, в котором использованы принципы модульного построения для обеспечения расширения его функциональности, например добавления манипуляционных функций для реализации разнообразных сервисных возможностей. В С.З представлен робот по персональному уходу, используемый для оказания физической помощи.

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

1 — внешняя среда; 2 — механика; 3 — данные; 4 — питание; 5 — защищенность; 6 — безопасность

Ь) Круговая диаграмма

• — датчик (S);

• — датчик с обработкой;

• — программное обеспечение (SW);

• — пРив0Д (А);

• — привод с обработкой;

  

  — источник питания (Р);

  — супервизор (SU);

  — пользовательский интерфейс (UI)

  
  

  — вычислительный модуль с программным обеспечением (CS);

  
  

Рисунок С.1 —Диаграммы соединений для представления модульной структуры робота и примеры обозначения модулей

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

Многие модули могут содержать интеллектуальные возможности, для реализации которых им может потребоваться целый ряд соединений для передачи данных, чтобы обеспечить соответствие требованиям интероперабельности. Например, в модуле источника питания может быть использовано интеллектуальное управление питанием, поэтому весьма вероятно, что данному модулю потребуется соединение для передачи данных, которое может быть реализовано с использованием ряда протоколов (например, CAN, I2C, TCP/IP, USB).

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

С.2 Модульное построение мобильных робототехнических комплексов

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

• - перемещение в конкретное заданное место;

• - идентификация объектов и избегание потенциальных опасностей при перемещении.

На рисунке С.2 а) показана конфигурация модулей с аппаратными и программными свойствами для сервисного робота-разносчика, способного перемещаться с обходом препятствий в заполненных людьми помещениях, обеспечивая защищенность данных от доступа неавторизованных лиц с помощью шифрования. На рисунке С.2 Ь) показан внешний вид такого робота. В сценарии типичного применения необходимо предусмотреть обеспечение безопасности, защищенности и защищенности, связанной с безопасностью. Для того чтобы соответствовать требованию безопасности, используемые модули должны обеспечивать соответствие необходимым требованиям безопасности всего сервисного робота-разносчика для конкретного применения. В состав сервисного робота-разносчика входят разные типы модулей с аппаратными свойствами, включая модули колес, модули приводов, модуль лидара, модуль камеры двумерного изображения, модуль инфракрасной камеры, вычислительный модуль и модуль источника питания. Четыре колеса с приводами, установленные на мобильной платформе, управляются вычислительным модулем с целью реализации требуемых перемещений. Следует отметить, что модули должны соответствовать требованиям, установленным в разделе 5, посвященном оценке риска безопасности, защищенности и защищенности, связанной с безопасностью, соответствующей конкретному применению робота-разносчика. Информация, связанная с аппаратными свойствами (или характеристиками), необходима для обеспечения надлежащей работы задействованных программных модулей. В частности, механические модули, предназначенные для доставки пакетов, должны быть хорошо организованы, чтобы облегчить реконфигурацию робота. Статические объекты, присутствующие в рабочей среде, необходимо идентифицировать, чтобы обеспечить надлежащее поведение робота, например, при повороте по направлению к цели или при обходе препятствия. Динамические связанные с безопасностью объекты (например люди) должны требовать соблюдения более строгих требований безопасности.

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

• 1) модуль идентификации;

• 2) один или несколько модулей обмена данными;

• 3) модуль обеспечения защищенности;

• 4) навигационный модуль;

• 5) модуль обхода препятствий;

• 6) модуль управления движением;

• 7) модуль обеспечения безопасности.

Модуль идентификации может состоять из модуля идентификации людей, обеспечивающего распознавание лиц авторизованных пользователей, и модуля идентификации объектов для распознавания связанных с безопасностью объектов. Модуль обмена данными используется для обмена данными между модулями робота-разносчика, серверами и другими роботами, при необходимости. Команды, например, двигаться к месту расположения цели и идентифицировать конкретного человека, поступают через модуль обмена данными. Следовательно, команды должны быть зашифрованы/защищены и иметь разрешение быть переданными и прочитанными модулями, наделенными необходимыми правами. Если расшифрование оказалось неудачным или право на получение данной команды отсутствует, то модуль обеспечения защищенности должен поднять тревогу, отслеживать развитие событий и реализовать надлежащие меры обеспечения защищенности. Если возникшая ситуация с нарушением защищенности может привести к проблемам безопасности, то данный модуль должен уведомить модуль обеспечения безопасности о необходимости обеспечить реализацию надлежащих мер безопасности. Навигационный модуль состоит из модуля картографирования, модуля локализации и модуля планирования маршрута. Навигационный модуль посылает координаты следующей точки на маршруте в модуль управления движением. Кроме того, навигационный модуль проверяет, работает ли робот в опасной зоне, и посылает тревожные сообщения модулю обеспечения безопасности, если робот попадает в опасную ситуацию. Модуль обхода препятствий должен обеспечить навигационный модуль информацией об объектах, которые робот должен объехать. Конечно, модуль обхода препятствий может быть включен в навигационный модуль. Модуль обеспечения безопасности должен управлять связанными с безопасностью угрозами для робота, включая связанные с защищенностью угрозы, выявленные при анализе рисков безопасности и защищенности. Модуль обеспечения безопасности собирает и анализирует связанные с безопасностью данные от модуля идентификации, модулей обмена данными, модуля обеспечения защищенности, навигационного модуля и модуля управления движением. Модуль управления движением содержит программный модуль управления четырьмя приводами (А^д) в модулях колес. В соответствии с результатами анализа должны быть рассмотрены и реализованы надлежащие меры обеспечения защищенности, безопасности и связанной с защищенностью безопасности. Модуль локализации формирует текущее пространственное расположение робота, используя сенсорные модули, включая модуль лидара, модуль двумерной камеры и модуль инфракрасной камеры, для получения необходимой сенсорной информации с помощью соответствующих программных модулей. Следует отметить, что для выполнения запланированных действий сервисного робота-разносчика необходимо наличие файлов с характеристиками программных модулей. Затемненные прямоугольники на рисунке С.2 с) представляют программные модули, обменивающиеся данными с аппаратными модулями.

а) Модули с аппаратными свойствами

Ь) Пример внешнего вида робота-разносчика

Рисунок С.2 — Пример построения робота-разносчика с мобильной платформой, лист 1

с) Программные модули

1 — колесо; 2 — инфракрасная камера; 3 — лидар; 4 — двумерная камера

Рисунок С.2, лист 2

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

• - взять и положить объекты;

• - взять, переместить и положить объекты;

• - идентифицировать объекты и избежать потенциальных рисков при манипулировании.

После перемещения в заданное местоположение, робот может направить свой манипулятор точно к целевому объекту для выполнения требуемого действия по взятию объекта. Обычно точное позиционирование обеспечивают с помощью уточнения положения манипулятора на основании данных сенсорной обратной связи, например, от видеосистемы. На рисунке С.З шесть модулей приводов (А3_8), связанных с сенсорными модулями, предназначены для выполнения действия по взятию объекта. Преимущество применения модульного подхода заключается в том, что модули, связанные с манипуляциями, могут быть легко установлены на существующую мобильную платформу и при этом использовать общие шины данных для получения сенсорной информации совместно с другими модулями в защищенном режиме, а также использовать источник питания (Р), вычислительный модуль с программным обеспечением (CS) и сенсорные модули (S1—S3), уже имеющиеся на мобильной платформе. Таким образом, достоинством применения модульного подхода в данном примере робота на базе мобильной платформы является то, что любое поведение и любая функциональность могут быть обеспечены при использовании подходящей комбинации модулей, а конструкция интерфейсных соединений обеспечивает удобный способ подключения новых модулей, что создает возможность универсального приспособления конструкции робота под разные применения.

а) Модули с аппаратными средствами

Ь) Пример внешнего вида мобильного манипулятора

Рисунок С.З — Пример построения мобильного манипулятора, лист 1

с) Программные модули

ГОСТ Р 60.2.0.1—2022

1 — приводы манипулятора; 2 — колесо; 3 — динамик; 4 — лидар; 5 — двумерная камера; 6 — сенсорный экран; 7 — микрофон

Примечания

• 1 Модуль обеспечения защищенности и модуль обеспечения безопасности могут быть расположены в модуле манипулятора.

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

Рисунок С.3, лист 2

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

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

• - речевое взаимодействие;

• - жестовое взаимодействие;

• - взаимодействие с использованием сенсорного экрана.

На рисунке 4 показаны два датчика, предназначенные для получения инструкций от человека. Первым является модуль сенсорного экрана (S4), обеспечивающий графический интерфейс, с помощью которого пользователь может непосредственно и недвусмысленно выдавать команды роботу. Вторым является сенсорный модуль микрофона (S5), обеспечивающий речевой интерфейс, с помощью которого пользователь может выдавать голосовые команды в естественной разговорной манере. Все датчики могут совместно использовать один и тот же источник питания (Р) и одни и те же вычислительные модули (CS), а также исходные сенсорные модули (S2—S3), показанные на рисунке С.З для мобильного манипулятора. Дополнительные программные модули для взаимодействия между человеком и роботом должны включать модуль распознавания речи для разных языков, модуль синтеза речи, модуль взаимодействия, управляющий сенсорным экраном, и сенсорные модули двумерной и инфракрасной камер для определения пространственного расположения объектов и людей. В частности, необходимо отметить, что модуль взаимодействия, управляющий сенсорным экраном, связан с модулем обеспечения защищенности для того, чтобы предотвращать доступ неавторизованных лиц к управлению роботом.

• а) Модули с аппаратными свойствами Ь) Мобильный обслуживающий робот

Рисунок С.4 — Построение мобильного обслуживающего робота, лист 1

ГОСТ Р 60.2.0.1—2022

с) Программные модули

1 — приводы манипулятора; 2 — колесо; 3 — динамик; 4 — лидар; 5 — двумерная камера; 6 — сенсорный экран; 7 — микрофон

Примечания

• 1 Модуль обеспечения защищенности и модуль обеспечения безопасности могут быть расположены в модуле манипулятора.

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

Рисунок С.4, лист 2

С.З Модульное построение экзоскелетов

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

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

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

Поддержка 1: Удержание равновесия

> Приводы шарниров

Датчики шарниров

।----Помощь 1: Обеспечение 30 % поддер-

I-----/ живающего усилия

и Помощь 2: Обеспечение адаптивного

поддерживающего усилия

Рисунок С.6 — Рабочие действия носимых экзоскелетов

Данные действия могут быть реализованы с помощью применения модульного подхода к управлению желательными движениями отдельного сустава человека. На рисунке С.7 показан общий подход к использованию модульного принципа проектирования приложения физического восстанавливающего/помогающего усилия к отдельному суставу с использованием сенсорных модулей, измеряющих движения человека, включая такие датчики, как инерциальные измерительные устройства (ИИУ), датчики усилия и угла поворота сустава, для определения желаемого движения сустава в качестве входных параметров при определении информации для управления двигателем, обеспечивающим необходимый вращающий момент в шарнире. Вопросы безопасности, рассмотренные в разделе 5, должны быть учтены, чтобы установить принятые при проектировании безопасные ограничения на углы поворота шарнира с помощью интерфейсных протоколов модуля робота. Необходимо отметить, что для облегчения понимания здесь опущены некоторые проблемы, например, детали, касающиеся источника питания и защищенности данных о движениях человека, а также вопросы, связанные с окружающей средой.

Сустав носителя экзоскелета

Интерфейс между экзоскелетом и человеком

I/P — вход; О/Р — выход; Е — внешняя среда; Р — питание; М — механика; D — данные;

Sc — защищенность; Sf — безопасность

Рисунок С.7 — Схема управления отдельным шарниром экзоскелета

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

Со М

1 — внешняя среда; 2 — механика; 3 — данные; 4 — питание; 5 — защищенность; б — безопасность;

7 — датчики шарниров бедра, колена и щиколотки; 8 — приводы шарниров бедра, колена и щиколотки

Рисунок С.8 — Шестистепенной экзоскелет для поддержки двигательных задач, таких как ходьба

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

Руководство по испытаниям модулей роботов

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

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

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

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

D.2 Определение необходимых испытаний

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

В комплекс испытаний могут входить, но не ограничиваться ими, следующие испытания, часть которых представлена в D.3:

• - испытания механической безопасности;

• - испытания механических характеристик;

• - испытания электрической безопасности и электромагнитной совместимости (ЭМС);

• - испытания электрических и электромагнитных характеристик;

• - испытания программного обеспечения, связанного с безопасностью;

• - испытания защищенности;

• - климатические испытания;

• - испытания биологической и химической безопасности;

• - испытания интероперабельности;

• - испытания взаимозаменяемости;

• - испытания на соответствие требованиям эргономики и технической эстетики;

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

D.3 Испытания на соответствие требованиям безопасности и защищенности

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

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

D.3.2 Испытания на механическую безопасность

Технические требования к механическим характеристикам модуля, таким как форма, вес, максимальная нагрузка, центр тяжести и т. д., являются важными факторами для изготовителей при рассмотрении механической безопасности. В нескольких стандартах определены методы испытаний на механическую безопасность, например в ГОСТ ISO 12100 и ГОСТ Р 60.2.2.1 использована оценка риска для построения испытаний на соответствие требованиям безопасности. В [24] определен метод испытания одноосно деформированных образцов с управлением деформацией при постоянной амплитуде, постоянной температуре и фиксированных коэффициентах деформации для определения усталостных характеристик.

D.3.3 Испытания на электрическую безопасность и электромагнитную совместимость

Ток, напряжение, длина пути тока утечки между проводниками, энергия излучаемых волн и т. д. являются общепринятыми измеряемыми параметрами при определении электрической безопасности модулей. Необходимые критерии установлены в стандартах по электрической безопасности и ЭМС. Например, в ГОСТ Р МЭК 60990 определены методы измерения тока, а в комплексе стандартов ГОСТ IEC 61000 рассмотрены вопросы, связанные с ЭМС.

D.3.4 Испытания программного обеспечения, связанного с безопасностью

В ГОСТ Р ИСО/МЭК 12207 и ГОСТ Р 57193 определены процессы жизненного цикла для разработки программного обеспечения. Для того чтобы соответствовать необходимым уровням эффективности защиты, связанным с безопасностью, тесты программного обеспечения включают тесты на основе спецификаций (например, распределение эквивалентности, классификационное дерево, анализ граничных значений), тесты на основе структуры (например, тестирование операторов, тестирование ветвей, тестирование решений) и тесты на основе опыта (например, поиск ошибок). В [25] определены концепция, процесс, документирование и методы тестирования программного обеспечения.

D.3.5 Испытания защищенности

В [26] определены механизмы физической защищенности. Помимо физической конфигурации, в ГОСТ Р ИСО/МЭК 27001 и ГОСТ Р ИСО/МЭК 27002 определены требования к управлению защищенностью, а также нормы и правила управления защищенностью в киберпространстве (см. [19]). В серии стандартов ГОСТ Р ИСО/МЭК 15408 установлены критерии оценки защищенности информационных технологий, а в серии стандартов ГОСТ ISO/IEC 19896-1 определены требования к компетентности тестировщиков и экспертов по оценке.

D.3.6 Испытания биологической и химической безопасности

В ГОСТ ИСО 14123-1 установлены принципы управления рисками для здоровья от опасных веществ, излучаемых машинами. В серии стандартов ГОСТ ISO 10993 представлены методы оценки биосовместимости для определения соответствия требованиям биологической и химической безопасности.

D.4 Испытания на соответствие характеристикам

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

Рабочие характеристики модуля должны быть измерены и испытаны для подтверждения того, что модуль соответствует проектным требованиям. Хотя большинство параметров измеряют изготовители, соответствие требованиям ГОСТ ISO/IEC 17025 также должно быть рассмотрено.

D.4.2 Испытания механических характеристик

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

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

• - силы и моменты, действующие по 1—3 осям (по отдельности или в их комбинации);

• - статические силы и моменты;

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

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

D.4.3 Испытания электрических и электромагнитных характеристик

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

Модуль аккумуляторной батареи является источником питания сервисного робота, и его емкость существенно влияет на рабочее время поддерживаемых функций. ГОСТ Р МЭК 60086-1 обеспечивает стандартизацию характеристик первичных батарей.

Частота и интенсивность детектирующего излучателя влияют на разрешение и чувствительность сенсорного модуля. В [27] определены калибровка и аттестация датчиков с помощью разных методов. Общие требования к конструкции бесконтактных электрочувствительных датчиков установлены в ГОСТ IEC 61496-1.

Уровень сигнала модуля беспроводной связи определяет качество связи. Международные стандарты по информационным и коммуникационным технологиям разрабатывает Совместный технический комитет СТК 1 ИСО/МЭК (ISO/IEC JTC 1).

D.4.4 Испытания характеристик программного обеспечения искусственного интеллекта

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

Одним из важных элементов ИИ являются данные, и в [28] рассмотрены примеры использования больших данных и связанных с ними требований. Стандарты в области ИИ в основном пока еще находятся в стадии разработки.

D.4.5 Климатические испытания

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

В [29] определена классификация групп параметров внешней среды и их влияние на изделия, а в серии стандартов ГОСТ Р МЭК 60068 определены методы испытаний, соответствующие различным условиям внешней среды. В [22] установлены степени защиты, обеспечиваемые корпусами электрического оборудования, для определения IP-кода. Если условия внешней среды изменяются, то с этими новыми условиями должны быть снова проведены климатические испытания.

Для сокращения времени проведения климатических испытаний используют методы ускоренных испытаний. Твердотельный диск (SSD) может быть использован как основной модуль хранения информации в сервисных роботах. Если взять SSD в качестве примера, то испытание на старение SSD, основанного на флэш-памяти с элементами НЕ-И, может быть ускорено с использованием более высокой температуры. По имеющимся данным, испытание на сохранность данных при температуре 66 °C в течение 96 часов эквивалентно испытанию при температуре 30 °C в течение одного года.

D.4.6 Испытания на соответствие требованиям эргономики и технической эстетики

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

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

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

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

• - участников, представляющих предполагаемых пользователей модуля;

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

• - условия внешней среды, соответствующие типичной внешней среде применения модуля по назначению.

Результаты испытаний могут быть оценены с помощью наблюдения за выполнением участниками заданий, регистрации ошибок использования модуля и интервьюирования участников о полученном опыте использования модуля. Собранные данные следует проанализировать, чтобы получить доказательства того, что данный модуль соответствует требованиям эргономики и технической эстетики, заявленным изготовителем. В [30] определен сум-мативный метод испытаний для измерения удобства и простоты использования изделий.

D.4.7 Верификация и валидация

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

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

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

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

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

Таблица ДА.1

RFC 791, Internet protocol version 4 (IPv4)

RFC 2460, Internet protocol, version 6 (IPv6) Specifications

OMG Robotic Localisation Service v1.1, 2012

[23] OMG Robotic interaction service framework (RolS), v 1.2, 2018

УДК 64-83:64.06:007.52:006.86:006.354

ОКС 25.040.30

Ключевые слова: роботы, робототехнические устройства, модульный принцип, сервисные роботы, аппаратные модули, программные модули

Редактор Л.В. Каретникова

Технический редактор И.Е. Черепкова

Корректор Е.Ю. Митрофанова

Компьютерная верстка Е.А. Кондрашовой

Сдано в набор 22.08.2022. Подписано в печать 01.09.2022. Формат 60х841/8. Гарнитура Ариал.

Усл. печ. л. 8,37. Уч.-изд. л. 7,53.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано в единичном исполнении в ФГБУ «РСТ» , 117418 Москва, Нахимовский пр-т, д. 31, к. 2.