9 лучших инструментов управления требованиями для функциональной безопасности в 2026 году06.10.2026 16:02

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

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

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

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

Что IEC 61508 требует от процесса управления требованиями

IEC 61508 — базовый стандарт функциональной безопасности электрических, электронных и программируемых систем. Его отраслевые версии определяют большинство промышленных разработок: ISO 13849 и IEC 62061 для машин, ISO 10218 для промышленных роботов, IEC 61511 для технологических установок, EN 50128 для железнодорожного программного обеспечения и ISO 26262 для дорожных транспортных средств. В основе у них общие принципы, поэтому инструмент, подходящий для IEC 61508, обычно подходит и для остальных стандартов.

Стандарт распределяет функции безопасности по четырём уровням полноты безопасности. SIL 1 соответствует наименьшему снижению риска, а SIL 4 — наибольшему; целевой уровень определяет, насколько строгими должны быть доказательства. Независимо от уровня IEC 61508 требует единой связанной последовательности: анализа опасностей, на основе которого формируются требования безопасности, прослеживаемой до этих требований конструкции и верификации, которая замыкает цикл доказательствами.

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

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

Что функциональная безопасность требует от инструмента управления требованиями

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

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

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

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

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

Что IEC 61508 требует от процесса управления требованиями

IEC 61508 — базовый стандарт функциональной безопасности электрических, электронных и программируемых систем. Его отраслевые стандарты определяют большинство промышленных разработок: IEC 62061 для машин, IEC 61511 для технологических установок, EN 50128 для железнодорожного программного обеспечения и ISO 26262 для дорожных транспортных средств. ISO 13849 для машин и ISO 10218 для промышленных роботов — отдельные стандарты, дополняющие его.

Отраслевые стандарты основаны на общих принципах, поэтому инструмент, подходящий для IEC 61508, обычно подходит и для остальных.

Стандарт распределяет функции безопасности по четырём уровням полноты безопасности. SIL 1 соответствует наименьшему снижению риска, а SIL 4 — наибольшему; целевой уровень определяет, насколько строгими должны быть доказательства. Независимо от уровня IEC 61508 требует единой связанной последовательности: анализа опасностей, на основе которого формируются требования безопасности, прослеживаемой до этих требований конструкции и верификации, которая замыкает цикл доказательствами.

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

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

Что функциональная безопасность требует от инструмента управления требованиями

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

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

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

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

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

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

Jama Connect

Скриншот: Jama Software

Jama Connect® объединяет требования безопасности и верификацию в контролируемой среде вместе с управлением рисками. Трассируемость помогает командам выявлять связанные элементы, которые могут потребовать проверки после изменения требования. Кроме того, TÜV SÜD сертифицировала платформу для разработки систем, связанных с безопасностью, до SIL 3 по IEC 61508 и ASIL D по ISO 26262.

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

Jama Connect также помогает командам подготовиться к Закону ЕС о киберустойчивости, связывая требования к кибербезопасности с работами по разработке и верификации. Это обеспечивает трассируемость от требований безопасности через реализацию до испытаний, пока команды готовятся к соблюдению CRA.

Преимущества:

• Сертификация TÜV SÜD может упростить квалификацию инструмента для программ функциональной безопасности
• Трассируемость выявляет связанные элементы, которые могут потребовать проверки после изменения требований
• Рабочие процессы проверки и история изменений обеспечивают документированные записи для аудитов
• Поддерживается трассируемость между направлениями разработки аппаратного и программного обеспечения
• Рабочие процессы проверки и электронные подписи помогают сохранять документированные записи об утверждении
• Поддерживается работа с междисциплинарными требованиями при разработке аппаратного и программного обеспечения

Недостатки:

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

Visure Requirements

Скриншот: Visure Solutions

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

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

Преимущества:

• Единый инструмент для работы с требованиями, рисками, FMEA и испытаниями, ориентированный на безопасность
• Шаблоны, соответствующие стандартам функциональной безопасности

Недостатки:

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

Siemens Polarion

Скриншот: Siemens

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

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

Преимущества:

• Требования, изменения и документация объединены в одной системе с развитой трассируемостью
• Тесная интеграция с Teamcenter и всей линейкой инструментов Siemens

Недостатки:

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

PTC Codebeamer

Скриншот: PTC

Codebeamer, вошедший в состав PTC после приобретения Intland в 2022 году, предлагает требования, испытания и управление рисками в одной платформе ALM, а также шаблоны по безопасности и поддержку ASPICE. Для программ обеспечения безопасности с ориентацией на разработку ПО, которые уже используют PTC Windchill, эти компоненты хорошо сочетаются.

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

Преимущества:

• Сквозная трассируемость ALM с шаблонами по функциональной безопасности и ASPICE
• Интеграция с PTC Windchill для управления данными об изделиях

Недостатки:

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

IBM DOORS Next

Скриншот: IBM

DOORS Next уже много лет используют для управления требованиями в программах, критичных с точки зрения безопасности, в аэрокосмической и оборонной отраслях, а также на железнодорожном транспорте. Этот опыт по-прежнему имеет значение. Инструмент входит в более широкое семейство IBM Engineering Lifecycle Management и поддерживает создание базовых версий и пометки подозрительных связей для контроля изменений.

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

Преимущества:

• Большой опыт управления требованиями в крупных программах обеспечения безопасности
• Создание базовых версий и отслеживание подозрительных связей для контроля изменений

Недостатки:

• Согласно отзывам пользователей, инструмент сложно осваивать и администрировать
• Переход с DOORS Classic требует отдельного проекта, а стоимость часто вызывает нарекания

Modern Requirements

Скриншот: Modern Requirements

Modern Requirements работает внутри Microsoft Azure DevOps и позволяет командам, уже использующим эту среду, создавать базовые версии требований безопасности и отслеживать их без перехода в другую систему. Компания публикует материалы по функциональной безопасности и делает ставку на создание требований с помощью ИИ.

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

Преимущества:

• Нативная поддержка работы с требованиями безопасности в Azure DevOps
• Создание требований с помощью ИИ и трассируемость в привычной среде Microsoft

Недостатки:

• Ценность инструмента зависит от перехода на Azure DevOps в качестве стандартной среды
• Меньше возможностей для работы с аппаратной частью и междисциплинарной системной разработкой

Perforce ALM

Скриншот: Perforce

Perforce ALM, ранее известная как Helix ALM, объединяет требования, тестовые сценарии и задачи, а также обеспечивает матрицу трассируемости между ними. Компания Perforce позиционирует её как инструмент для критичных с точки зрения безопасности и регулируемых разработок. Команды, которым нужны требования и испытания в одном инструменте, оценят широкий охват функций.

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

Преимущества:

• Требования, испытания и задачи объединены общей матрицей трассируемости
• Гибкие рабочие процессы и автоматизация

Недостатки:

• Согласно отзывам на G2, настройка, адаптация и интеграция сопряжены с трудностями
• Высокая цена для инструмента такого масштаба

Инструменты с упором на моделирование и лёгкие решения

Sparx Enterprise Architect

Скриншот: Sparx Systems

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

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

Преимущества:

• Моделирование в SysML и UML с привязкой требований к модели
• Доступная цена по сравнению с корпоративными пакетами управления требованиями

Недостатки:

• Нет регламентированного процесса утверждения и аудита, характерного для системы учёта требований
• Сложен для инженеров, не работающих в рамках практики моделирования

ReqView

Скриншот: ReqView

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

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

Преимущества:

• Простое внедрение и надёжный обмен ReqIF с поставщиками
• Понятная матрица трассируемости при низкой цене

Недостатки:

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

Какой инструмент управления требованиями функциональной безопасности подойдёт вашей команде

Выбор зависит от структуры программы. Командам, работающим в среде Siemens PLM, может подойти Polarion, а группы разработчиков ПО, ориентированные на Microsoft, могут использовать Modern Requirements внутри Azure DevOps. Команды, опирающиеся на моделирование, могут хранить требования рядом с архитектурой в Sparx, а небольшим поставщикам может хватить возможностей ReqView для решения основных задач.

Для программ, охватывающих несколько инженерных дисциплин, стоит рассмотреть и Jama Connect. Платформа поддерживает трассируемость при разработке аппаратного и программного обеспечения, а также обеспечивает контролируемые проверки и записи об изменениях. Сертификация TÜV SÜD может быть важна и для команд, разрабатывающих связанные с безопасностью изделия по IEC 61508.

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

Что такое IEC 61508 и что означают уровни SIL?

IEC 61508 — базовый международный стандарт функциональной безопасности электрических, электронных и программируемых систем. Он определяет четыре уровня полноты безопасности: от SIL 1 с наименьшим снижением риска до SIL 4 с наибольшим. Целевой уровень определяет, насколько строгими должны быть требования, конструкция и доказательства верификации. Отраслевые стандарты, такие как IEC 61511 и ISO 26262, адаптируют ту же систему к конкретным отраслям.

Чем функциональная безопасность отличается от общей безопасности изделия?

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

Нужна ли инструментам управления требованиями собственная сертификация безопасности?

Не всегда, но она полезна. Если орган по сертификации оценивает инструмент, с помощью которого вы управляете доказательствами безопасности, можно опереться на эту оценку, а не квалифицировать инструмент самостоятельно. Это экономит время при работе над программой с уровнем SIL. Глубина подтверждения может различаться: некоторые поставщики предлагают знаки доверенного инструмента или комплекты для квалификации, тогда как в сертификате TÜV SÜD для Jama Connect прямо указаны уровни — до SIL 3 и ASIL D. При выборе проверьте область действия любого сертификата.

Как ISO 26262 и стандарты для машин соотносятся с IEC 61508?

Они происходят от этого стандарта. ISO 26262 адаптирует IEC 61508 для дорожных транспортных средств и использует уровни ASIL, а IEC 62061 адаптирует его для машин; EN 50128 распространяется на железнодорожное программное обеспечение. ISO 13849 также охватывает машины, но существует наряду с IEC 62061, а не происходит от IEC 61508. Поскольку у них общая основа, подход к управлению требованиями, соответствующий IEC 61508, обычно можно перенести на отраслевой стандарт с небольшими корректировками. Например, Visure предлагает шаблоны сразу для нескольких стандартов.

Можно ли обеспечить функциональную безопасность с помощью Jira или нужен специализированный инструмент?

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

Полный текст статьи читайте на TheNextWeb.ru прочитано 687 раз