Проверка программного обеспечения испытательного оборудования (ПО ИО) — это документированная оценка программ и программных модулей, которые обеспечивают функционирование испытательного оборудования, задают и поддерживают режимы испытаний, получают и обрабатывают измерительные данные, рассчитывают результаты, ведут журналы и формируют отчётные документы. Цель проверки — подтвердить правильность работы конкретной идентифицированной версии ПО и установить, что её функции согласуются с назначением оборудования, эксплуатационной документацией и программой аттестации.
Проверка ПО — часть оценки испытательного оборудования, а не замена его аттестации
Аттестация испытательного оборудования охватывает способность оборудования воспроизводить условия испытаний с установленными характеристиками и его пригодность к применению. Проверка программного обеспечения рассматривает ту часть доказательной базы, которая относится к программам, алгоритмам, данным, настройкам, интерфейсам и идентификации версии. Итоговые выводы по пригодности испытательного оборудования принимаются по совокупности результатов всей аттестации.
Что относится к программному обеспечению испытательного оборудования
ГОСТ Р 8.568-2017 рассматривает программное обеспечение испытательного оборудования как программы и программные модули, предназначенные для функционирования ИО и обработки данных при измерениях физических величин. На практике программная часть может быть распределена между несколькими устройствами и уровнями системы, поэтому перед испытаниями важно определить не только название основной программы, но и полный состав компонентов, способных повлиять на условия и результаты испытаний.
Встроенное ПО
Прошивки контроллеров, измерительных модулей, регуляторов, приводов, источников воздействий и устройств регистрации.
Управляющее ПО
Программы оператора, HMI, SCADA, автоматизированные рабочие места и сценарии управления последовательностью испытаний.
Расчётные модули
Алгоритмы преобразования сигналов, фильтрации, коррекции, усреднения, вычисления параметров и оценки критериев испытаний.
Программная инфраструктура
Драйверы, библиотеки, службы обмена, базы данных, средства синхронизации времени, архивирования и формирования протоколов.
Если часть функций реализована в конфигурации ПЛК, скриптах, макросах, шаблонах отчётов или параметрах базы данных, такие элементы также могут входить в объект проверки. Решающее значение имеет не формат компонента, а его влияние на воспроизведение условий испытаний, измерительную информацию и документирование результата.
Как проверка ПО связана с аттестацией испытательного оборудования
Основная цель аттестации испытательного оборудования — подтвердить характеристики ИО, возможность воспроизведения условий испытаний в заданных пределах с допускаемыми отклонениями и пригодность оборудования к использованию по назначению. Первичная аттестация включает экспертизу эксплуатационной документации, экспериментальное определение характеристик оборудования и подтверждение правильности работы его программного обеспечения.
Следовательно, проверка ПО ИО не является изолированной формальностью. Она должна быть связана с теми режимами и характеристиками, которые аттестуются. Если программа задаёт температуру, давление, вибрацию, нагрузку, скорость, электрическое воздействие или иной режим, проверка должна показать, как значение вводится, передаётся, контролируется, регистрируется и отражается в результатах.
Ключевой вопрос проверки
Можно ли по документации и объективным результатам испытаний подтвердить, что конкретная версия ПО формирует, поддерживает, контролирует и документирует заданные режимы так, как это предусмотрено назначением испытательного оборудования?
Когда требуется проверка программного обеспечения испытательного оборудования
ГОСТ Р 8.568-2017 различает первичную, периодическую и повторную аттестации. Необходимость и объём проверки ПО зависят от вида аттестации, роли программы и произошедших изменений.
| Вид аттестации | Когда проводится | Как учитывается ПО |
|---|---|---|
| Первичная | До начала эксплуатации испытательного оборудования. | Определяются объект и границы программной части, фиксируется версия, проверяются функции, алгоритмы и влияние ПО на воспроизводимые режимы и результаты. |
| Периодическая | В процессе эксплуатации с интервалами и объёмом, установленными по результатам первичной аттестации. | Подтверждается сохранение характеристик и проверяется фактически используемая программная конфигурация в объёме программы и методики аттестации. |
| Повторная | После ремонта, модернизации, замены ПО, изменения метрологически значимой части, перемещения оборудования и иных воздействий, способных изменить характеристики. | Оценивается влияние изменений, выполняются необходимые регрессионные и повторные проверки, актуализируются версия, контрольные суммы и документы. |
Проверка особенно необходима, когда ПО:
- автоматически задаёт или поддерживает режимы испытаний;
- управляет исполнительными устройствами, регуляторами, приводами или источниками воздействий;
- принимает сигналы от датчиков и средств измерений;
- выполняет пересчёты, фильтрацию, коррекцию, округление или сравнение с критериями;
- определяет момент начала, окончания или перехода между этапами испытаний;
- регистрирует события, ошибки и изменения настроек;
- формирует протокол, отчёт или электронный архив результатов;
- обменивается данными с внешними системами или удалёнными модулями;
- было заменено, обновлено или перенесено на другую аппаратную платформу.
Нормативная и методическая основа работ
Состав нормативных документов определяется видом испытательного оборудования, его назначением, областью применения и целью аттестации. Для программной части базовыми ориентирами являются следующие документы.
ГОСТ Р 8.568-2017 устанавливает общий порядок аттестации ИО и прямо включает подтверждение правильности работы ПО в состав первичной аттестации. Если соответствующие алгоритмы и программы не являются частью функционально законченных технических систем с измерительными функциями или средств измерений, стандарт предусматривает использование требований ГОСТ Р 8.654 и методов испытаний ГОСТ Р 8.883.
Дополнительно применяются эксплуатационная и проектная документация оборудования, методики испытаний продукции, технические условия, требования заказчика, отраслевые документы и программа с методикой аттестации конкретного ИО. Наличие типовой методики не отменяет необходимости конкретизировать объект, функции, версии, сценарии и критерии для конкретного оборудования.
МИ 3645-2021: типовая методика проверки ПО при аттестации ИО
МИ 3645-2021 «Типовая методика подтверждения правильности работы программного обеспечения при аттестации испытательного оборудования» разработана специально для случаев, когда программная часть влияет на функционирование ИО и обработку данных. Документ создаёт единый методический каркас: от идентификации версии и анализа документации до проведения функциональных проверок и оформления результатов.
Методика была утверждена в 2021 году и подготовлена коллективом специалистов метрологических организаций под руководством ВНИИМС. Она опирается на ГОСТ Р 8.568-2017 и предусматривает применение методов испытаний программного обеспечения, установленных ГОСТ Р 8.883-2015.
Типовой каркас
Помогает не пропустить документацию, идентификацию, функции, алгоритмы, данные, защиту и оформление результатов.
Адаптация к объекту
Перечень операций уточняется для конкретного оборудования, версии ПО, режимов испытаний и контролируемых характеристик.
Прослеживаемость
Каждая проверка связывается с требованием, тестовым сценарием, исходными данными, наблюдаемым результатом и выводом.
Использование результата
Протокол проверки ПО может включаться в комплект документов первичной, периодической или повторной аттестации ИО.
Какое испытательное оборудование и программное обеспечение можно проверить
Проверка применима к оборудованию, в котором программы участвуют в формировании условий испытаний, управлении воздействиями, контроле параметров или обработке результатов. Типичные примеры:
Климатическое оборудование
Камеры тепла, холода, влаги, термобарокамеры, установки циклических воздействий и системы программирования режимов.
Механические стенды
Вибрационные, ударные, нагрузочные, усталостные, разрывные, поворотные стенды и системы управления приводами.
Электрические испытательные комплексы
Стенды электрической прочности, изоляции, импульсных воздействий, электромагнитной совместимости и радиотехнических испытаний.
Гидравлические и пневматические установки
Оборудование давления, расхода, герметичности, ресурса, циклических нагрузок и автоматического поддержания режимов.
Технологические и специальные установки
Автоклавы, сушильные, вакуумные, термомеханические и иные установки с программируемой последовательностью операций.
Автоматизированные испытательные системы
Многоканальные комплексы, распределённые стенды, АРМ оператора, базы данных, серверы и средства формирования отчётности.
Конкретное оборудование может не входить в этот перечень. Для предварительной оценки достаточно описать назначение ИО, воспроизводимые режимы и роль программного обеспечения.
Как устанавливаются границы программного объекта
Одна из самых сложных задач — определить, какие компоненты действительно относятся к проверяемому ПО ИО. Простого указания версии пользовательского приложения недостаточно, если результат зависит от прошивки контроллера, драйвера, расчётной библиотеки, конфигурационного файла или шаблона отчёта.
При формировании объекта проверки составляется схема программно-аппаратного взаимодействия. Для каждого компонента устанавливают назначение, разработчика, версию, место исполнения, входные и выходные данные, доступные интерфейсы и влияние на результат.
В объект следует включать всё, что способно изменить результат
Значимыми могут быть не только исполняемые файлы. Конфигурация ПЛК, коэффициенты пересчёта, базы нормативов, сценарии испытаний, формулы в шаблонах, драйверы обмена и настройки округления также требуют идентификации, если их изменение влияет на режимы или результаты.
Что проверяется при испытаниях ПО ИО
Окончательный состав операций фиксируется в программе и методике. В общем случае проверка может включать следующие направления.
Программная документация
Назначение, архитектура, функции, алгоритмы, интерфейсы, режимы, системные требования, установка, эксплуатация и сопровождение.
Идентификация версии
Наименование, версия, дата сборки, перечень значимых файлов и модулей, контрольные суммы и доступный способ проверки.
Управление режимами
Задание уставок, переходы между этапами, поддержание режима, ограничения, блокировки, завершение и аварийная остановка.
Получение измерительных данных
Источники сигналов, каналы, единицы величин, диапазоны, дискретность, частота опроса, признаки достоверности и пропуски.
Вычислительные алгоритмы
Формулы, коэффициенты, преобразования, фильтрация, интерполяция, усреднение, округление и сравнение с критериями.
Интерфейсы и обмен
Протоколы связи, форматы сообщений, команды, подтверждения, тайм-ауты, повторные передачи и обработка некорректных данных.
Хранение и отчётность
Структура записей, метки времени, архивирование, экспорт, резервное копирование, восстановление и формирование протоколов.
Защита и контроль изменений
Роли пользователей, доступ к настройкам, журналы событий, контроль целостности и защита значимых компонентов.
Проверка расчётных алгоритмов и обработки данных
Если итоговый результат формируется программой, необходимо подтвердить не только запуск соответствующей функции, но и правильность вычислений. Для этого подготавливаются контрольные наборы входных данных и эталонные результаты, рассчитанные независимым способом.
В зависимости от задачи оцениваются:
- соответствие формул технической документации и методике испытаний;
- корректность единиц величин и коэффициентов преобразования;
- правила округления, ограничения разрядности и представления результата;
- обработка граничных, нулевых, отрицательных и предельных значений;
- действия при пропусках, ошибках качества и недостоверных входных данных;
- устойчивость результата к повторному выполнению на одинаковых исходных данных;
- соответствие результатов независимому расчёту или опорному программному средству;
- прослеживаемость исходных данных, промежуточных значений и итогового результата.
Для сложных алгоритмов в методику включают несколько классов тестов: типовые, граничные, негативные, регрессионные и контрольные примеры по нормативному документу. Глубина проверки определяется влиянием алгоритма на результат аттестации и последующих испытаний продукции.
Негативные сценарии, сбои и восстановление
Штатная демонстрация интерфейса не показывает, как оборудование поведёт себя при нарушении обмена или недостоверных данных. Поэтому для значимых функций предусматриваются контролируемые негативные сценарии. Они выполняются только в безопасных условиях и в границах, установленных документацией и программой испытаний.
- потеря, задержка или искажение сигнала датчика;
- обрыв связи с контроллером, измерительным модулем или внешней системой;
- передача значения за пределами допустимого диапазона;
- отсутствие обязательного параметра или некорректный формат сообщения;
- отключение и последующее восстановление питания;
- перезапуск программы или контроллера в процессе выполнения сценария;
- недоступность базы данных, каталога архива или сетевого ресурса;
- попытка изменить защищённую настройку пользователем без соответствующих прав;
- несоответствие версии модуля, библиотеки или конфигурационного файла;
- переполнение журнала, недостаток свободного места или нарушение системного времени.
Проверяется, переходит ли система в предусмотренное состояние, исключает ли выдачу недостоверного результата, информирует ли оператора, регистрирует ли событие и корректно ли восстанавливается после устранения причины.
Версия, контрольные суммы и идентификационные признаки ПО
Идентификация связывает протокол с конкретным программным состоянием оборудования. В противном случае невозможно доказать, что после аттестации используется именно проверенная конфигурация.
В протоколе или отдельном перечне могут фиксироваться:
- полное и краткое наименование программного обеспечения;
- номер версии, релиза или сборки;
- версия встроенного ПО контроллеров и измерительных модулей;
- перечень исполняемых файлов, библиотек, скриптов и конфигураций;
- цифровые идентификаторы значимых компонентов;
- алгоритм расчёта контрольных сумм;
- способ отображения версии пользователю;
- аппаратная и системная платформа, если она влияет на воспроизводимость;
- дата получения и проверки идентификационных сведений.
Подробнее о подходе к составу файлов и цифровым идентификаторам см. в статье «Идентификационные признаки программного обеспечения».
Какие документы и материалы желательно предоставить
Для предварительной оценки необязательно сразу иметь идеальный комплект. Но чем полнее описаны оборудование и роль программной части, тем точнее можно определить объём испытаний.
Документы на оборудование
- наименование, тип, модель и назначение ИО;
- паспорт или формуляр;
- эксплуатационная документация;
- технические условия или спецификация;
- описание воспроизводимых режимов;
- материалы предыдущей аттестации.
Документы на ПО
- описание программы и архитектуры;
- руководство оператора;
- сведения о версии и модулях;
- описание алгоритмов;
- интерфейсы и форматы обмена;
- защита, журналы и обновление.
Материалы испытаний
- программа и методика аттестации;
- методики испытаний продукции;
- контрольные примеры;
- ожидаемые результаты;
- сценарии штатных и нештатных режимов;
- формы протоколов и отчётов.
Доступ к объекту
- инсталляционный комплект;
- исполняемая версия;
- учётная запись испытателя;
- доступ к стенду или удалённой сессии;
- средства фиксации результатов;
- контакт технического специалиста.
Исходный код не является обязательным по умолчанию. Он или отдельные фрагменты могут быть запрошены, если значимый алгоритм, механизм защиты или порядок обработки ошибок нельзя достоверно подтвердить по документации, исполняемой версии и результатам функциональных испытаний. Условия конфиденциальности при необходимости закрепляются договором.
Где и как проводятся испытания
Формат определяется конструкцией оборудования и возможностью воспроизвести необходимые режимы.
- В лаборатории. Программное обеспечение и доступные технические средства передаются исполнителю, а контрольные сценарии выполняются на подготовленном стенде.
- На месте эксплуатации. Этот вариант применяется, если оборудование стационарное, чувствительно к транспортированию или связано с инженерной инфраструктурой.
- На площадке изготовителя. Удобно для опытных образцов, сложных стендов и работ, требующих участия разработчика.
- Удалённо. Допустимо для тех функций, которые можно надёжно воспроизвести и зафиксировать через управляемый удалённый доступ.
- Комбинированно. Документы, алгоритмы и идентификацию анализируют дистанционно, а аппаратно-зависимые сценарии выполняют на оборудовании.
При выборе формата учитываются управляемость конфигурации, наблюдаемость результатов, защита доступа, возможность подтвердить версию и сохранность доказательных материалов.
Порядок проведения работ
- Предварительное обращение. Заказчик направляет описание оборудования, назначение ПО, цель проверки и имеющиеся документы.
- Определение объекта. Устанавливаются границы программной конфигурации, значимые функции, оборудование и внешние системы.
- Анализ нормативной базы. Определяются применимые пункты ГОСТ Р 8.568-2017, МИ 3645-2021, эксплуатационных документов и методик испытаний.
- Оценка документации. Проверяются сведения о функциях, алгоритмах, интерфейсах, данных, защите, версиях и обновлении.
- Оформление договора. Согласуются объём, сроки, стоимость, место испытаний, доступ к стенду и условия конфиденциальности.
- Разработка или уточнение методики. Формируются требования, сценарии, исходные данные, ожидаемые результаты и критерии оценки.
- Идентификация версии. Фиксируются состав программных компонентов, версии и цифровые идентификаторы.
- Проведение испытаний. Выполняются функциональные, расчётные, граничные, негативные и восстановительные сценарии.
- Анализ результатов. Оцениваются отклонения, несоответствия, повторяемость и достаточность доказательств.
- Оформление протокола. Документируются объект, условия, методы, результаты, замечания и выводы.
- Использование в аттестации. Протокол включается в комплект материалов и рассматривается комиссией вместе с результатами проверки характеристик всего ИО.
Какие документы получает заказчик
Состав выходных материалов зависит от договора и роли лаборатории в общей процедуре. Обычно результат включает:
- методику или раздел программы проверки программного обеспечения;
- протокол испытаний ПО ИО;
- перечень версий, файлов, модулей и цифровых идентификаторов;
- таблицу соответствия требований и выполненных проверок;
- зафиксированные контрольные примеры и результаты расчётов;
- перечень выявленных замечаний и несоответствий;
- рекомендации по идентификации и контролю изменений;
- материалы, пригодные для включения в протокол аттестации испытательного оборудования.
Протокол проверки ПО подтверждает результаты выполненных операций в установленном объёме. Он не заменяет протокол и аттестат испытательного оборудования, если по применимой процедуре должны быть оформлены отдельные документы на ИО в целом.
Чем проверка ПО ИО отличается от других процедур
| Процедура | Основной объект | Цель и результат |
|---|---|---|
| Проверка ПО ИО | Программная часть конкретного испытательного оборудования. | Подтвердить правильность работы версии ПО и подготовить протокол для аттестации, приёмки или внутреннего контроля. |
| Аттестация испытательного оборудования | Испытательное оборудование в целом, включая воспроизводимые условия, средства контроля и программную часть. | Установить характеристики и пригодность ИО к применению; оформить протокол и при положительном результате аттестат. |
| Добровольная сертификация ПО | Программный продукт как самостоятельный идентифицированный объект. | Подтвердить соответствие выбранным требованиям с выдачей сертификата в рамках добровольной системы. |
| Проверка ПО средства измерений | ПО, влияющее на метрологические характеристики и измерительную информацию средства измерений. | Оценить ПО в рамках испытаний СИ в целях утверждения типа или иной метрологической процедуры. |
| Приёмочные испытания | Оборудование или программно-аппаратный комплекс по техническому заданию и договору. | Подтвердить выполнение договорных требований перед вводом в эксплуатацию или передачей заказчику. |
Обновление ПО и необходимость повторной аттестации
ГОСТ Р 8.568-2017 прямо относит замену программного обеспечения к примерам модернизации, после которой оборудование может подлежать повторной аттестации. Повторная аттестация также предусмотрена после внесения изменений в метрологически значимую часть ПО.
Не каждое обновление автоматически требует повторения всех ранее выполненных операций. Сначала проводится анализ влияния:
- какие файлы, модули и настройки изменены;
- затронуты ли алгоритмы, уставки, единицы, коэффициенты и критерии;
- изменились ли интерфейсы связи или форматы данных;
- повлияло ли обновление на журналы, архив, отчёты или метки времени;
- изменились ли механизмы защиты и разграничения доступа;
- перенесено ли ПО на новую операционную систему, контроллер или вычислительную платформу;
- сохраняются ли прежние идентификационные признаки и контрольные суммы.
По результатам анализа определяется достаточный объём: документальное подтверждение неизменности значимых функций, выборочные регрессионные проверки либо повторная аттестация по правилам первичной или периодической процедуры.
Частые вопросы
Обязательно ли проверять ПО у каждого испытательного оборудования?
Нет, состав аттестации определяется конструкцией и назначением конкретного ИО. Отдельная углублённая проверка необходима, когда программа влияет на создание или поддержание режимов, получение измерительной информации, вычисление результата, его регистрацию либо формирование отчётных документов.
Заменяет ли протокол проверки ПО аттестацию оборудования?
Нет. Протокол подтверждает правильность работы программной части в установленном объёме. Вывод о пригодности испытательного оборудования принимается по совокупности проверки ПО и результатов оценки характеристик ИО в целом.
Нужно ли предоставлять исходный код?
Обычно достаточно документации, исполняемой версии, тестовых данных и доступа к оборудованию. Исходный код или его фрагменты могут потребоваться, если значимый алгоритм, скрытая функция или механизм защиты не могут быть достоверно подтверждены иным способом.
Можно ли провести проверку удалённо?
Да, если удалённый доступ позволяет надёжно идентифицировать версию, воспроизвести необходимые режимы, управлять исходными данными и сохранять доказательства. Аппаратно-зависимые функции могут потребовать работы на стенде или выезда.
Что делать, если документация на ПО неполная?
Можно начать с предварительного аудита. Лаборатория сопоставит имеющиеся материалы с функциями оборудования и подготовит перечень недостающих сведений. До испытаний ключевые требования и ожидаемое поведение должны быть описаны однозначно.
Нужно ли проверять операционную систему и драйверы?
Они включаются в объект, если их версия или настройки способны повлиять на обмен, расчёты, временные характеристики, режимы оборудования или формирование результатов. Иначе достаточно зафиксировать системную платформу и подтвердить совместимость.
Можно ли распространить один протокол на несколько одинаковых стендов?
Это возможно только при доказанной идентичности конструкции, программной конфигурации, значимых настроек и условий применения, а также если программа и методика аттестации предусматривают такой подход. Решение должно быть документировано, а не предполагаться автоматически.
Что требуется после обновления программного обеспечения?
Следует предоставить описание изменений, новую версию, перечень изменённых модулей и идентификационные сведения. После анализа влияния определяется объём регрессионных испытаний и необходимость повторной аттестации.
Какой документ оформляется по результатам?
Основным результатом является протокол проверки или испытаний ПО ИО. В зависимости от договора дополнительно могут оформляться методика, перечень версий и контрольных сумм, таблица требований и рекомендации для включения в материалы аттестации.
От чего зависят сроки и стоимость?
От числа программных компонентов, сложности алгоритмов, количества режимов, полноты документации, доступности оборудования, необходимости разработки методики и объёма штатных, граничных и негативных сценариев. Точный расчёт выполняется после предварительного анализа.
Как начать работу
Для предварительной оценки направьте краткое описание испытательного оборудования, перечень воспроизводимых режимов, сведения о программном обеспечении и его версии, цель проверки, имеющуюся документацию и информацию о том, проводится ли первичная, периодическая или повторная аттестация.
Специалисты лаборатории определят границы объекта, применимые документы, необходимый доступ к оборудованию, состав проверок и возможный формат выходных материалов.
Материал актуализирован 3 сентября 2026 г..
Направьте назначение, версию и имеющуюся документацию. Специалисты лаборатории определят возможный состав работ, перечень исходных материалов и порядок дальнейшего взаимодействия.
Обсудить задачу