О перспективах испытаний программного обеспечения средств измерений в Беларуси М.В. Шабанов, начальник научно-исследовательского отдела законодательной и теоретической метрологии БелГИМ О необходимости контроля программного обеспечения (ПО) средств измерений (СИ) и закрепления этих требований в нормативных документах первыми заговорили метрологи Европы, что нашло отражение в Директиве № 2004\22\ЕС «Measuring Instruments Directive». Так называемые «существенные требования» Директивы, раздел 8, устанавливают, что ПО средства измерений, влияющее на его метрологические характеристики должно быть идентифицировано как таковое и защищено. Данное требование действует в отношении счетчиков воды, газосчетчиков, счетчиков электроэнергии, теплосчетчиков, измерительных систем для жидкостей кроме воды, автоматических взвешивающих устройств, таксиметров, анализаторов выхлопных газов и др. т.е. средств измерений, применяемых, в первую очередь, в сфере законодательной метрологии. Техническое решение испытаний (валидации) ПО с целью реализации указанного требования Директивы устанавливается методическими документами, например, Руководством WELMEC 7.2. Закон Российской Федерации статья 9. «Требования к средствам измерений» устанавливает: «Конструкция средств измерений должна обеспечивать ограничение доступа к определенным частям средств измерений (включая программное обеспечение) в целях предотвращения несанкционированных настройки и вмешательства, которые могут привести к искажениям результатов измерений». Реализация государственными метрологическими службами данного требования в части доступа к ПО, привела в последнее время к активному обсуждению вопроса испытаний ПО средств измерений в метрологических журналах Российской Федерации. Остановимся только на концептуальных моментах данного вопроса. В [1] авторы от государственной метрологической службы говорят о том, что «жесткость» испытаний и проверки ПО должны отражаться в индивидуальной методике испытаний для конкретного вида СИ. Д.Р. Васильев в том же [1] поддерживает идею, принятую в международных документах [3-4], по установлению уровня «жесткости» испытаний ПО до испытаний на законодательном уровне. БелГИМ также поддерживает подход с установлением уровня «жесткости» до проведения работ, поскольку исходя из этого оцениваются необходимые ресурсы и объем работ. На НТК по метрологии Госстандарта №4-2011 БелГИМ предложил утвердить Постановлением Госстандарта в 2011 году нижеприведенный перечень видов средств измерений, применяемых в сфере законодательной метрологии, «высокого риска» манипуляций и мошенничества, в отношении которых требуется анализ их программного обеспечения. Колонки топливораздаточные; Таксометры; стр. 1 из 4 Водо- и теплосчетчики; Счетчики электрической энергии; Весоизмерительные приборы. Стремление идти в ногу со временем - хорошая идея, однако для небольших рынков, каким является рынок средств измерений Беларуси, следует оценивать все возможные риски и не только метрологического характера. Если вышеуказанное постановление утверждается, то возникают технические вопросы, не позволяющие в полной мере выполнять требования [3-4]. Например, при испытаниях ПО, в т.ч. зарубежных СИ, требуется присутствие специалиста-программиста на производственной базе изготовителя/разработчика ПО для работы с материалами, защищенными авторскими правами и другими нормами законодательства. Даже при таком условии, вероятность согласия зарубежного изготовителя/разработчика на раскрытие исходного кода ПО, хотя бы в части реализации метрологических функций минимальна. Таким образом, невозможно реализовать единый подход для отечественных и зарубежных изготовителей СИ, что создаст дискриминационные условия. Прогнозируемый результат при жесткой политике Госстандарта в отношении испытаний ПО – уход с рынка измерительной техники зарубежных изготовителей современных средств измерений. Оценивая риски использования ПО средств измерений в мошеннических целях однозначны два риска: оригинальное ПО включает средства мошенничества и подмена оригинального ПО. Глупо полагать, что разработчик ПО специально заложит возможность мошенничества с помощью прибора, однако, гипотетически подмена оригинальной программы возможна, если злоумышленник располагает исходным кодом программы – «прошивкой» и программатором, с помощью которого можно перепрограммировать микросхему. Как правило, для исключения таких ситуаций изготовитель СИ включает в аппаратную часть дополнительные средства проверки неизменности исходного кода – проверку его аутентичности (хэш, контрольная сумма, цифровая подпись и т.п.). Таким образом, проверка ПО и ограничение доступа к нему даже способом механического пломбирования (при отсутствии функций обновления ПО через съемные носители и внешние интерфейсы) позволяют говорить о достаточности защиты законодательно контролируемого ПО. В [1] представителями государственной метрологической службы говорится «…для чего нужна вся эта затея с доступом к исполняемому коду программы? Все это нужно только для одного единственного случая, когда разработчик автоматизированного СИ не представил на испытания информацию об идентификационных признаках ПО, в частности, не представил контрольные суммы для метрологических значимых частей ПО.» Таким образом, в РФ считают, что то, что запрограммировано в приборе должно быть только идентифицировано. Согласится с этим нельзя, поскольку ПО – «троянский конь» со всеми вытекающими последствиями. Пример: стр. 2 из 4 Идентификация версии ПО жестко «прошита» в исходном коде. Идентификация выводится каждый раз при включении прибора. Все хорошо? Отнюдь. Размер программы в EEPROM свободным образом изменяется при перепрограммировании без дополнительной визуализации. Изготовитель говорит, что работает CRC проверка. Как без рассмотрения исходного кода удостоверится в этом заявлении? Если верить изготовителю на слово, то идентификация ПО является только формальной отпиской для контролирующего органа. Та же ситуация с заявляемыми командами, пропускаемыми через интерфейс, как клавиатурный так и внешний (RS485 и т.п.) Не располагая исходным кодом нельзя утверждать, что функция обновления ПО через аппаратный интерфейс отсутствует или последовательность нажатий клавиш не обнуляет долговременную память прибора. Можно ли обойтись без анализа исходного кода прикладного ПО для СИ в сфере законодательной метрологии рассмотрим на примере работы АЗС. На сегодняшний день утверждение типа ТРК выполняется без проверки программного обеспечения. Из этого следует, что мы не знаем какие команды (в виде программных переменных или кодов) могут быть переданы на ТРК. Стандарт на ТРК говорит, что суммарный счетчик должен быть «необнуляемым», поскольку он участвует в исчислении налога. Как можно проверить данное требование в электронной ТРК не зная, каким образом происходит запись значений отпущенного объема топлива в электронную память, реализующую суммарный счетчик? Гипотетически существует возможность обнуления или изменение содержимого памяти ТРК командой, поданной через внешний интерфейс ТРК, например, из программы управления работой АЗС. В данном примере критическим с точки зрения законодательной метрологии является как раз отсутствие такой возможности, поскольку точность измерений мы можем оценить с помощью эталонов. Практическим решением является изучение, как минимум, переменных и команд, которые могут быть переданы/получены через внешний интерфейс и их связи с веткой алгоритма ПО, изменяющей значение суммарного счетчика. Сделать это «безболезненно» для разработчика, попросив у него официальное описание команд/переменных проходящих через внешний интерфейс не получится, поскольку требуется проверка отсутствия «потенциально опасных» команд/переменных в «критической» части ПО. Реально реализуемое решение в этом случае - принять на веру заявленные команды/переменные и при необходимости проверить их работу. Из данного примера также следует важный вывод: «Проверка прикладного ПО нецелесообразна без проверки ПО средства измерений». Международная законодательная метрология ушла от проверки программных «надстроек» в виде АСКУЭ и т.п. На сегодняшний день основа для реализации фискальных операций в сфере учета – электронная память средства измерений, в первую очередь, реализующая суммарный учет результатов измерений. Поэтому в Директиве ЕС по средствам измерений особое внимание уделяется вопросам обеспечения целостности и неизменности стр. 3 из 4 измерительных данных, хранящихся в средстве измерений в течение законодательно установленного периода времени. Разумеется, для Беларуси такая схема потребует замены парка средств измерений, реализующих учетные операции, c пересмотром действующих правил учета или договорных отношений поставщика-потребителя в пользу потребителя, что маловероятно в ближайшие годы. Перспективы развития направления испытаний ПО средств измерений в Беларуси такие же неопределенные, как и 7 лет назад. Исходя из предпосылок развития данного направления в Физико-техническом институте Германии (PTB) изначально необходимы жесткие требования законодательства и значительные государственные инвестиции, как в сферу развития IT. Возможно, при создании таможенного союза и его системы обеспечения единства измерений такой IT-центр для проведения испытаний ПО СИ будет создан, что позволит сократить издержки изготовителя СИ и увеличит вероятность предъявления ПО на испытания, учитывая огромный рынок ТС. Что касается краткосрочной перспективы для Беларуси, то организации Госстандарта Беларуси, проводящие государственные испытания, могут лишь фиксировать контрольные суммы (как и в [1]) или иную идентификацию, не получив ответа на главный вопрос: «все ли работает так, как заявлено?». [1] журнал «Законодательная и прикладная метрология» №2-2011, РФ [2] журнал «Мир измерений» 2/2011, РФ [3] WELMEC Guide 7.2 [4] OIML D31 “General requirements for software controlled measuring instruments”, 2008 [5] R 76-1 “Non-automatic weighing instruments. Part 1: Metrological and technical requirements – Tests”, 2006 стр. 4 из 4