Проверка программного обеспечения при утверждении типа средств измерений

Проверка программного обеспечения (ПО) при утверждении типа средств измерений (СИ) — это критически важный этап, так как в современной метрологии именно алгоритм часто является «измерительной системой», а физический датчик лишь передает первичный сигнал.

Испытания регламентируются Приказом Минпромторга РФ № 2510 и методическими рекомендациями Р 50.2.077-2014 «ГСИ. Проверка защиты программного обеспечения».

Основные цели проверки ПО

Эксперт-метролог проверяет программу по трем ключевым критериям:

1. Защищенность: Мог ли кто-то изменить показания со стороны (взлом)?
2. Идентификация: Знаем ли мы точно версию программы, которая сейчас работает?
3. Метрологическая значимость: Какие части кода отвечают за цифры на экране?

Детальный перечень операций (этапы испытаний)

1. Идентификация программного обеспечения.
Это проверка того, что перед экспертом именно та версия программы, которая заявлена в описании типа. Проверка наименования и версии: Сверка названия ПО и номера версии с документацией. Вычисление контрольных сумм (хэш-функций): Эксперт вычисляет значение хэша (например, по алгоритмам MD5 или SHA-256) для исполняемых файлов (.exe, .dll). Это «цифровой отпечаток» файла. Если в коде изменится хотя бы один символ, хэш станет другим. Фиксация носителя: Опломбирование флешки или диска с дистрибутивом, который хранится в архиве ВНИИМС/ГРЦМ как эталонный образец.

2. Оценка структуры и документации.
Анализ того, как программа спроектирована. Анализ документации: Изучение Руководства пользователя, паспорта ПО и «Спецификации метрологически значимых параметров».. Разделение функций: Проверка разделения ПО на метрологически значимую часть (ядро расчетов) и незначимую (интерфейс, отчеты, база данных пользователей). Блок-схема алгоритма: Эксперт изучает логику преобразований: «Каким образом вольты с датчика превращаются в тонны нефти?». Формулы должны соответствовать законам физики и аттестованным МВИ.

3. Проверка защиты от несанкционированного вмешательства. 
Самый строгий этап, подтверждающий доверие к прибору.. Уровни доступа: Наличие системы ролей (Администратор, Инженер, Оператор). У оператора не должно быть прав менять калибровочные коэффициенты. 

Журнал событий. Наличие автоматического лога, который записывает: кто, когда и какое изменение внес (например: 12.09.2026 | User_Ivanov | Changed_K_factor_from_1.0_to_1.05).

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

4. Экспериментальная проверка влияния ПО на погрешность

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

Результат проверок

Все результаты заносятся в Протоколы испытаний ПО. На их основании делается вывод о том, соответствует ли софт требованиям безопасности и может ли оно быть утверждено как часть средства измерения. Данные о контрольных суммах одобренной версии затем вносятся во ФГИС «Аршин».