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

Символ нового года

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

09.08.2011 | Автор: Д.А. Гривастов | Полемические заметки | Количество просмотров: 23506

Сокращения, используемые в тексте: ПО – программное обеспечение; СИ – средство измерений; МХ – метрологические характеристики; БД – база данных; СУБД – система управления базами данных; ГЦИ – государственный центр испытаний.

Единообразный подход к любому ПО любого СИ, принятый в МИ 3286 и МИ 3290, стал камнем преткновения, серьёзно затрудняющим проведение ГЦИ СИ испытаний СИ, в конструкции которых тем или иным образом используется ПО. Критика (особенно действующих нормативных документов) – вещь нерациональная, если не предлагать альтернативу. Исходя из этого убеждения в приведённом ниже тексте я буду стараться воздерживаться от критических замечаний и излагать свою точку зрения на один из аспектов испытаний ПО при утверждении типа СИ – его идентификацию.

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

Встроенное ПО СИ – исполняемое ПО, размещённое в запоминающих устройствах, расположенных внутри корпуса СИ.

Интегрированное ПО СИ – встроенное ПО СИ, недоступное для изменений через имеющиеся у СИ интерфейсы.

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

Автономное ПО – исполняемое ПО, размещённое вне корпуса СИ.
Примечание:
Определения встроенное ПО СИ, интегрированное ПО СИ, загружаемое ПО СИ, автономное ПО СИ могут использоваться также и в отношении части ПО, например: интегрированная часть ПО СИ, автономная часть ПО СИ.

Аппаратное окружение ПО СИ – комплекс аппаратных средств, с использованием ресурсов которого исполняется ПО СИ.

Программное окружение ПО СИ – комплекс программных средств, с использованием ресурсов которого исполняется ПО СИ.
Примечания:
1. Определения аппаратное окружение ПО СИ и программное окружение ПО СИ могут использоваться также и в отношении части ПО, например: аппаратное окружение интегрированной части ПО СИ, программное окружение автономной части ПО СИ.
2. Термин программное окружение ПО СИ не имеет смысла в случае интегрированного ПО СИ.

Входные данные – информация на входе процесса, в т.ч. исполняемого ПО, алгоритма и т.п.

Конфигурационные данные – изменяемая в процессе эксплуатации СИ информация, влияющая на функционирование исполняемого ПО СИ.

Выходные данные – информация на выходе процесса, в т.ч. исполняемого ПО, алгоритма и т.п.

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

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

Идентификация интегрированного ПО

В качестве одной из причин необходимости идентификации ПО СИ, включая интегрированное ПО, авторы МИ называют потенциальную недобросовестность изготовителя, в силу которой он может попытаться изменить ПО с корыстной целью (видимо, это связано с предыдущей сферой деятельности авторов МИ – игровыми автоматами). Непонятно, почему такое внимание уделено именно ПО СИ – ведь изготовитель ровно с тем же эффектом может изменить схемотехнику СИ и это никак специально не контролируется. Более того, существует практика того, что изготовитель имеет право вносить в конструкцию СИ изменения после подтверждения в рамках «внутренних» типовых испытаний факта того, что вносимые изменения не влекут за собой ухудшения потребительских свойств изделия, в т.ч. МХ СИ. Функционально ПО – это такая же часть конструкции СИ, как, например инструментальный усилитель или АЦП, а лишать производителя права улучшать конструкцию СИ не кажется вполне законным.

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

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

Идентификация загружаемого ПО

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

Загружаемое ПО может вовсе не иметь исполняемого кода в привычном понимании, представляя собой набор конфигурационных данных – «проект», который воспроизводит необходимую мнемосхему вместе с параметрами её функционирования. В этом случае в одном массиве или базе данных могут храниться как неизменные данные, для которых может быть каким-либо образом получен цифровой идентификатор типа значения контрольной хэш-функции, так и изменяющиеся во времени данные – результаты измерений и параметры технологического процесса. Для осуществления контроля соответствия такого ПО экземпляру ПО, представленному на испытания в целях утверждения типа СИ, как один из вариантов, может быть проведено тщательное программное разделение, затем созданы специальные программные сценарии для выделения метрологически значимых неизменных данных, преобразования их в непрерывные последовательности и последующего вычисления для этих последовательностей значений контрольной хэш-функции. Одновременно должны быть применены средства идентификации текущей среды исполнения и загрузчика, так как только вместе эти компоненты точно воспроизводят необходимую функциональность ПО СИ. Очевидно, что этот путь требует значительных затрат средств и времени.

Каждый конкретный случай загружаемого ПО СИ должен рассматриваться индивидуально с точки зрения поиска наиболее экономически целесообразного решения задачи подтверждения его целостности и подлинности. Не факт, что идентификационные признаки загружаемого ПО удастся свести в таблицу подобную приведённой в МИ 3290.

Идентификация автономного ПО

При рассмотрении сопровождающего СИ автономного ПО сперва следует изучить вопрос о том, какую задачу это ПО решает. ПО СИ – это часть его конструкции. Независимо от реализованного «внутри» СИ метода измерений, СИ по определению (5.10, 6.2, 8.1 РМГ 29) решает измерительную задачу так, что результат измерений на его выходе – это результат прямых измерений, даже если в дальнейшем проверка этих результатов измерений осуществляется косвенным методом.

Автономным ПО СИ следует считать только ту часть автономного ПО, которое непосредственно участвует в получении результата измерений в виде показаний СИ (6.43 РМГ 29). Та часть автономного ПО, которая занимается обработкой уже полученных результатов прямых измерений с целью получения на их основе результатов косвенных или совокупных измерений, на самом деле должна быть отнесена к программам обработки результатов измерений. Задача установления показателей точности этих результатов, включающая в себя в том числе идентификацию используемого ПО, решается соответствующей методикой измерений (ГОСТ Р 8.563). «Притягивание за уши» для решения этой задачи каких-то особенных процедур вроде обособленной «аттестации ПО» ? это попытка изобрести велосипед.

Для автономного ПО СИ и программ обработки результатов измерений различаются существенные требования к окружению. В первом случае, как правило, существенны требования как к программному, так и к аппаратному окружению, во втором – только к программному окружению. Во многих случаях, например, когда автономное ПО СИ формирует временные диаграммы управления процессом измерений, аппаратное и программное окружение могут оказывать влияние на функционирование автономного ПО СИ и, как следствие, на МХ СИ. В связи с этим следует отметить, что реализация описанного в ГОСТ Р 8.654 механизма программного разделения автономного ПО СИ на метрологически значимую и незначимую части будет успешной только тогда, когда установлено влияние ПО СИ на МХ СИ при любых разрешённых условиях применения в смысле аппаратного и программного окружения, включая проверку допускаемой нагрузки ПО СИ.

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

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

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

Таблица 1 – Сведения об ОС
 Table1

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

Таблица 2 – Перечень драйверов устройств
 Table2

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

Таблица 3 – Перечень прикладных программ
 Table3
Примечание:
В большинстве случаев СУБД относятся к прикладным программам, тогда как некоторые хранимые процедуры и таблицы БД могут быть классифицированы как часть автономного ПО СИ и конфигурационные данные, влияющие на результаты измерений. В таком случае возникает необходимость провести разделение метрологически значимой и не значимой частей БД.

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

Таблица 4 – Перечень программных модулей автономного ПО СИ
 Table4

Таблица 5 – Характеристики программного модуля «Х»
 Table5

В сопроводительной документации автономного ПО СИ, кроме прочего, должен быть описан способ его конфигурирования. Конфигурационные данные, очевидно, также являются объектом, в каком-то виде (с учётом «изменчивой» природы) подлежащим идентификации и защите от несанкционированного изменения.

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

Сведения об авторе
Гривастов Денис Александрович, ФГУП «СНИИМ», г.Новосибирск, grivastov@mail.ru

Другие статьи раздела

Все статьи раздела "Полемические заметки">> Все статьи нашего блога >>

Добавить комментарий: