"ГОСТ Р 60.2.0.1-2022 (ИСО 22166-1:2021). Национальный стандарт Российской Федерации. Роботы и робототехнические устройства. Модульный принцип построения сервисных роботов. Часть 1. Общие требования"
(утв. и введен в действие Приказом Росстандарта от 19.08.2022 N 798-ст)

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

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 19 августа 2022 г. N 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 ВВЕДЕН ВПЕРВЫЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.9

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

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

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

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

3.1.12

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

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

Примечания

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

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

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

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

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

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

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

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 Примеры модулей робота, важных для модульного принципа построения сервисных роботов, представлены в приложении B.

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

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

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

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

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

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

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

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

3.4.4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

b) ориентация в пространстве, которая может быть определена одним из двух способов. Обычно ориентацию задают в трехмерном пространстве кватернионом, который представлен четырьмя числами <c, su, sv, sw>, где (u, v, w) - ось вращения, а c и s - косинус и синус половины угла поворота соответственно. Иначе может быть задано только вращение вокруг оси z углом поворота вокруг этой оси, выраженном в радианах;

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

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

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

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

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

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

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

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

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

- ГОСТ 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) следует выполнять как итеративный процесс. Если повышение уровня защищенности может привести к снижению уровня безопасности, то повышение уровня безопасности имеет приоритет над повышением уровня защищенности.

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

При разработке модуля необходимо учитывать требования стандартов по электрической и механической безопасности (в приложении 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 (приложение B) приведен список потенциальных опасностей, которые следует рассмотреть].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- питание;

- данные;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

b) вызов сервисов;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модуль взаимодействия человек - робот (ВЧР) предоставляет человеку средства для взаимодействия с роботом, обеспечивая информацию о намерениях робота и передачу команд или информации роботу.

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

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

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

Многие модули могут содержать интеллектуальные возможности, для реализации которых им может потребоваться целый ряд соединений для передачи данных, чтобы обеспечить соответствие требованиям интероперабельности. Например, в модуле источника питания может быть использовано интеллектуальное управление питанием, поэтому весьма вероятно, что данному модулю потребуется соединение для передачи данных, которое может быть реализовано с использованием ряда протоколов (например, CAN, I2C, TCP/IP, USB).

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

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

- перемещение в конкретное заданное место;

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

На рисунке C.2 a) показана конфигурация модулей с аппаратными и программными свойствами для сервисного робота-разносчика, способного перемещаться с обходом препятствий в заполненных людьми помещениях, обеспечивая защищенность данных от доступа неавторизованных лиц с помощью шифрования. На рисунке C.2 b) показан внешний вид такого робота. В сценарии типичного применения необходимо предусмотреть обеспечение безопасности, защищенности и защищенности, связанной с безопасностью. Для того чтобы соответствовать требованию безопасности, используемые модули должны обеспечивать соответствие необходимым требованиям безопасности всего сервисного робота-разносчика для конкретного применения. В состав сервисного робота-разносчика входят разные типы модулей с аппаратными свойствами, включая модули колес, модули приводов, модуль лидара, модуль камеры двумерного изображения, модуль инфракрасной камеры, вычислительный модуль и модуль источника питания. Четыре колеса с приводами, установленные на мобильной платформе, управляются вычислительным модулем с целью реализации требуемых перемещений. Следует отметить, что модули должны соответствовать требованиям, установленным в разделе 5, посвященном оценке риска безопасности, защищенности и защищенности, связанной с безопасностью, соответствующей конкретному применению робота-разносчика. Информация, связанная с аппаратными свойствами (или характеристиками), необходима для обеспечения надлежащей работы задействованных программных модулей. В частности, механические модули, предназначенные для доставки пакетов, должны быть хорошо организованы, чтобы облегчить реконфигурацию робота. Статические объекты, присутствующие в рабочей среде, необходимо идентифицировать, чтобы обеспечить надлежащее поведение робота, например, при повороте по направлению к цели или при обходе препятствия. Динамические связанные с безопасностью объекты (например люди) должны требовать соблюдения более строгих требований безопасности.

На рисунке C.2 c) показана конфигурация программных модулей, способных обеспечить желаемое поведение робота с использованием модулей с аппаратными свойствами, показанными на рисунке C.2 a). Следует отметить, что соответствие между аппаратными и программными свойствами модулей здесь не рассматривается. На рисунке C.2 c) выделена общая функциональность разных программных модулей, необходимых для сценария типичного применения. Программные модули сервисного робота-разносчика можно классифицировать следующим образом:

1) модуль идентификации;

2) один или несколько модулей обмена данными;

3) модуль обеспечения защищенности;

4) навигационный модуль;

5) модуль обхода препятствий;

6) модуль управления движением;

7) модуль обеспечения безопасности.

Модуль идентификации может состоять из модуля идентификации людей, обеспечивающего распознавание лиц авторизованных пользователей, и модуля идентификации объектов для распознавания связанных с безопасностью объектов. Модуль обмена данными используется для обмена данными между модулями робота-разносчика, серверами и другими роботами, при необходимости. Команды, например, двигаться к месту расположения цели и идентифицировать конкретного человека, поступают через модуль обмена данными. Следовательно, команды должны быть зашифрованы/защищены и иметь разрешение быть переданными и прочитанными модулями, наделенными необходимыми правами. Если расшифрование оказалось неудачным или право на получение данной команды отсутствует, то модуль обеспечения защищенности должен поднять тревогу, отслеживать развитие событий и реализовать надлежащие меры обеспечения защищенности. Если возникшая ситуация с нарушением защищенности может привести к проблемам безопасности, то данный модуль должен уведомить модуль обеспечения безопасности о необходимости обеспечить реализацию надлежащих мер безопасности. Навигационный модуль состоит из модуля картографирования, модуля локализации и модуля планирования маршрута. Навигационный модуль посылает координаты следующей точки на маршруте в модуль управления движением. Кроме того, навигационный модуль проверяет, работает ли робот в опасной зоне, и посылает тревожные сообщения модулю обеспечения безопасности, если робот попадает в опасную ситуацию. Модуль обхода препятствий должен обеспечить навигационный модуль информацией об объектах, которые робот должен объехать. Конечно, модуль обхода препятствий может быть включен в навигационный модуль. Модуль обеспечения безопасности должен управлять связанными с безопасностью угрозами для робота, включая связанные с защищенностью угрозы, выявленные при анализе рисков безопасности и защищенности. Модуль обеспечения безопасности собирает и анализирует связанные с безопасностью данные от модуля идентификации, модулей обмена данными, модуля обеспечения защищенности, навигационного модуля и модуля управления движением. Модуль управления движением содержит программный модуль управления четырьмя приводами (A_1-4) в модулях колес. В соответствии с результатами анализа должны быть рассмотрены и реализованы надлежащие меры обеспечения защищенности, безопасности и связанной с защищенностью безопасности. Модуль локализации формирует текущее пространственное расположение робота, используя сенсорные модули, включая модуль лидара, модуль двумерной камеры и модуль инфракрасной камеры, для получения необходимой сенсорной информации с помощью соответствующих программных модулей. Следует отметить, что для выполнения запланированных действий сервисного робота-разносчика необходимо наличие файлов с характеристиками программных модулей. Затемненные прямоугольники на рисунке C.2 c) представляют программные модули, обменивающиеся данными с аппаратными модулями.

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

- взять и положить объекты;

- взять, переместить и положить объекты;

- идентифицировать объекты и избежать потенциальных рисков при манипулировании.

После перемещения в заданное местоположение, робот может направить свой манипулятор точно к целевому объекту для выполнения требуемого действия по взятию объекта. Обычно точное позиционирование обеспечивают с помощью уточнения положения манипулятора на основании данных сенсорной обратной связи, например, от видеосистемы. На рисунке C.3 шесть модулей приводов (A_{3 - 8}), связанных с сенсорными модулями, предназначены для выполнения действия по взятию объекта. Преимущество применения модульного подхода заключается в том, что модули, связанные с манипуляциями, могут быть легко установлены на существующую мобильную платформу и при этом использовать общие шины данных для получения сенсорной информации совместно с другими модулями в защищенном режиме, а также использовать источник питания (P), вычислительный модуль с программным обеспечением (CS) и сенсорные модули (S₁ - S₃), уже имеющиеся на мобильной платформе. Таким образом, достоинством применения модульного подхода в данном примере робота на базе мобильной платформы является то, что любое поведение и любая функциональность могут быть обеспечены при использовании подходящей комбинации модулей, а конструкция интерфейсных соединений обеспечивает удобный способ подключения новых модулей, что создает возможность универсального приспособления конструкции робота под разные применения.

Примечания

1 Модуль обеспечения защищенности и модуль обеспечения безопасности могут быть расположены в модуле манипулятора.

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

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

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

- речевое взаимодействие;

- жестовое взаимодействие;

- взаимодействие с использованием сенсорного экрана.

На рисунке 4 показаны два датчика, предназначенные для получения инструкций от человека. Первым является модуль сенсорного экрана (S₄), обеспечивающий графический интерфейс, с помощью которого пользователь может непосредственно и недвусмысленно выдавать команды роботу. Вторым является сенсорный модуль микрофона (S₅), обеспечивающий речевой интерфейс, с помощью которого пользователь может выдавать голосовые команды в естественной разговорной манере. Все датчики могут совместно использовать один и тот же источник питания (P) и одни и те же вычислительные модули (CS), а также исходные сенсорные модули (S₂ - S₃), показанные на рисунке C.3 для мобильного манипулятора. Дополнительные программные модули для взаимодействия между человеком и роботом должны включать модуль распознавания речи для разных языков, модуль синтеза речи, модуль взаимодействия, управляющий сенсорным экраном, и сенсорные модули двумерной и инфракрасной камер для определения пространственного расположения объектов и людей. В частности, необходимо отметить, что модуль взаимодействия, управляющий сенсорным экраном, связан с модулем обеспечения защищенности для того, чтобы предотвращать доступ неавторизованных лиц к управлению роботом.

Примечания

1 Модуль обеспечения защищенности и модуль обеспечения безопасности могут быть расположены в модуле манипулятора.

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

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

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

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

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

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

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

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

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

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

- испытания механической безопасности;

- испытания механических характеристик;

- испытания электрической безопасности и электромагнитной совместимости (ЭМС);

- испытания электрических и электромагнитных характеристик;

- испытания программного обеспечения, связанного с безопасностью;

- испытания защищенности;

- климатические испытания;

- испытания биологической и химической безопасности;

- испытания интероперабельности;

- испытания взаимозаменяемости;

- испытания на соответствие требованиям эргономики и технической эстетики;

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

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

Технические требования к механическим характеристикам модуля, таким как форма, вес, максимальная нагрузка, центр тяжести и т.д., являются важными факторами для изготовителей при рассмотрении механической безопасности. В нескольких стандартах определены методы испытаний на механическую безопасность, например в ГОСТ ISO 12100 и ГОСТ Р 60.2.2.1 использована оценка риска для построения испытаний на соответствие требованиям безопасности. В [24] определен метод испытания одноосно деформированных образцов с управлением деформацией при постоянной амплитуде, постоянной температуре и фиксированных коэффициентах деформации для определения усталостных характеристик.

Ток, напряжение, длина пути тока утечки между проводниками, энергия излучаемых волн и т.д. являются общепринятыми измеряемыми параметрами при определении электрической безопасности модулей. Необходимые критерии установлены в стандартах по электрической безопасности и ЭМС. Например, в ГОСТ Р МЭК 60990 определены методы измерения тока, а в комплексе стандартов ГОСТ IEC 61000 рассмотрены вопросы, связанные с ЭМС.

В ГОСТ Р ИСО/МЭК 12207 и ГОСТ Р 57193 определены процессы жизненного цикла для разработки программного обеспечения. Для того чтобы соответствовать необходимым уровням эффективности защиты, связанным с безопасностью, тесты программного обеспечения включают тесты на основе спецификаций (например, распределение эквивалентности, классификационное дерево, анализ граничных значений), тесты на основе структуры (например, тестирование операторов, тестирование ветвей, тестирование решений) и тесты на основе опыта (например, поиск ошибок). В [25] определены концепция, процесс, документирование и методы тестирования программного обеспечения.

В [26] определены механизмы физической защищенности. Помимо физической конфигурации, в ГОСТ Р ИСО/МЭК 27001 и ГОСТ Р ИСО/МЭК 27002 определены требования к управлению защищенностью, а также нормы и правила управления защищенностью в киберпространстве (см. [19]). В серии стандартов ГОСТ Р ИСО/МЭК 15408 установлены критерии оценки защищенности информационных технологий, а в серии стандартов ГОСТ ISO/IEC 19896-1 определены требования к компетентности тестировщиков и экспертов по оценке.

В ГОСТ ИСО 14123-1 установлены принципы управления рисками для здоровья от опасных веществ, излучаемых машинами. В серии стандартов ГОСТ ISO 10993 представлены методы оценки биосовместимости для определения соответствия требованиям биологической и химической безопасности.

Рабочие характеристики модуля должны быть измерены и испытаны для подтверждения того, что модуль соответствует проектным требованиям. Хотя большинство параметров измеряют изготовители, соответствие требованиям ГОСТ ISO/IEC 17025 также должно быть рассмотрено.

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

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

- силы и моменты, действующие по 1 - 3 осям (по отдельности или в их комбинации);

- статические силы и моменты;

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

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

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

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

Частота и интенсивность детектирующего излучателя влияют на разрешение и чувствительность сенсорного модуля. В [27] определены калибровка и аттестация датчиков с помощью разных методов. Общие требования к конструкции бесконтактных электрочувствительных датчиков установлены в ГОСТ IEC 61496-1.

Уровень сигнала модуля беспроводной связи определяет качество связи. Международные стандарты по информационным и коммуникационным технологиям разрабатывает Совместный технический комитет СТК 1 ИСО/МЭК (ISO/IEC JTC 1).

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

Одним из важных элементов ИИ являются данные, и в [28] рассмотрены примеры использования больших данных и связанных с ними требований. Стандарты в области ИИ в основном пока еще находятся в стадии разработки.

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

В [29] определена классификация групп параметров внешней среды и их влияние на изделия, а в серии стандартов ГОСТ Р МЭК 60068 определены методы испытаний, соответствующие различным условиям внешней среды. В [22] установлены степени защиты, обеспечиваемые корпусами электрического оборудования, для определения IP-кода. Если условия внешней среды изменяются, то с этими новыми условиями должны быть снова проведены климатические испытания.

Для сокращения времени проведения климатических испытаний используют методы ускоренных испытаний. Твердотельный диск (SSD) может быть использован как основной модуль хранения информации в сервисных роботах. Если взять SSD в качестве примера, то испытание на старение SSD, основанного на флэш-памяти с элементами НЕ-И, может быть ускорено с использованием более высокой температуры. По имеющимся данным, испытание на сохранность данных при температуре 66 °C в течение 96 часов эквивалентно испытанию при температуре 30 °C в течение одного года.

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

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

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

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

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

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

- условия внешней среды, соответствующие типичной внешней среде применения модуля по назначению.

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

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

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

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