Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Метрологическая экспертиза технической документации. Учебное пособие

.pdf

Скачиваний:

Добавлен:

07.09.2026

Размер:

1 Мб

Скачать

☆

<<< < Предыдущая 1 2 3 4 5 6 7 8 9 1011 / 1311 12 13 > Следующая >>>

101

Таблица 5

Название требования

Главное содержание требования (возможно различающееся в соответствии

с классами риска)

Специальные примечания (область применения, дополнительные пояснения, исключительные случаи и т.п.)

Предусмотренная документация (возможно различающаяся в соответствии с классами риска)

Руководство по подтверждению

для одного класса риска

Руководство по подтверждению

для другого класса риска

…

Пример приемлемых решений

для одного класса риска

Пример приемлемых решений для другого класса риска

…

Структура блока требований

Блок требований представляет собой техническое содержание требования, включая руководство по подтверждению. Блок адресован как изготовителю, так и уполномоченным органам (организациям) с двумя целями: чтобы (1) рассматривать это требование как минимальное условие и (2) не налагать какие-то дополнительные требования.

Здесь встречается термин — уполномоченный орган (организация). Под уполномоченными органами (организациями — notified bodies (NB) понимаются органы (организации), уполномоченные (аккредитованные) в установленном порядке для проведения работ по испытаниям СИ с целью утверждения типа, по их поверке и калибровке и/или подтверждению их соответствия (сертификации). Как известно, в Российской Федерации уполномоченными органами (организациями) являются федеральные органы исполнительной власти, осуществляющие функции в области обеспечения единства измерений, государственные научные метрологические институты, государственные региональные центры метрологии, в том числе государственные центры испытаний средств измерений, метрологические службы юридических лиц, аккредитованные на право поверки и калибровки СИ, а также органы обязательной и/или добровольной сертификации соответствующей продукции.

Приведем пример конкретных требований, относящихся к основным конфигурациям СИ. Например, требования к идентификации встроенного ПО представлены в следующем виде (табл. 6):

102

Таблица 6

Риск класса В

Риск класса С

Риск класса D

Идентификация программного обеспечения

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

Специальные примечания:

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

Специальные примечания:

1. В добавление к 1В: Каждое изменение юридически значимого программного обеспечения, зафиксированного при утверждения типа, требует новой программной идентификации

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

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

Требования к документации:

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

Требования к документации

(в дополнение к требованиям к документации для риска классов В и С): Документация должна показывать меры, предпринимаемые для защиты программной идентификации от фальсификации

Руководство по подтверждению:

Проверки, основанные на документации:

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

Руководство по подтверждению

(в добавление к руководству для риска классов В и С):

Проверки, основанные на документации:

– Проверяется, все ли меры, предпринятые для предотвращения фальсификации, являются достаточными

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

103

– На это значение должна быть ссылка в тексте сертификата

Функциональные проверки:

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

Пример приемлемого решения:

– Идентификация юридически значимого программного обеспечения содержит две части. В первой части (А) происходит изменение идентификации, если измененное программное обеспечение требует нового утверждения. Часть (В) показывает только незначительные изменения в программном обеспечении, например, исправление грубых ошибок (bug fixes), которые не требуют нового утверждения – Идентификация генерируется и показывается по команде

– Часть (А) идентификации состоит из номера версии или номера ТАС (сертификата об утверждении типа)

– Часть (А) идентификации состоит из автоматически сгенерированной контрольной суммы, полученной на основе юридически значимого программного обеспечения, которое объявляется неизменным при утверждении типа. Для другой части юридически значимого программного обеспечения часть (А) состоит из номера версии или номера ТАС – Примером приемлемого решения для получения контрольной суммы является алгоритм электронной подписи (the CRC-16 algorithm)

Дополнения для риска класса Е

Требования к документации (в дополнение к требованиям к документации

для риска классов В и С): Исходный код, содержащий генерацию идентификации

Руководство по подтверждению (в дополнение к руководству для риска классов В и С):

Проверки, основанные на анализе исходного кода:

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

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

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

Для соответствующих уровней используются следующие определения.

104

Уровни защиты программного обеспечения Низкий: Не требуется никаких средств защиты от намерен-

ных изменений.

Средний: Программное обеспечение защищено от намерен-

ных изменений с помощью легкодоступных и простых программных средств (например, с помощью текстового редактора).

Высокий: Программное обеспечение защищено от намерен-

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

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

верок средства измерений. Никакого тестирования программного обеспечения сверх этого не требуется.

Средний: В добавление к низкому уровню, программное

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

Высокий: В добавление к среднему уровню, осуществляется

всестороннее тестирование программного обеспечения, обычно основанное на анализе исходного кода.

Уровни соответствия программного обеспечения Низкий: Функциональность программного обеспечения, ис-

полняемая для каждого конкретного средства измерений, находится в соответствии с утвержденной документацией.

Средний: В добавление к «низкому» уровню соответствия,

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

Высокий: Исполнение программного обеспечения в кон-

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

105

Назначение классов риска

Риск класса

Защита

программного

обеспечения

Проверка

программного

обеспечения

Степень соответствия

программного

обеспечения

низкий

средний

низкий

средний

высокий

средний

высокий

средний

высокий

Классы риска определены в табл. 7.

Таблица 7

Определение классов риска

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

В приведенном материале необходимо обратить внимание на следующие обстоятельства.

1. В требованиях используется термин «юридически значи-

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

криптографическим методам защиты (контрольная сумма, алгоритмы хэширования и электронной подписи CRC-16, номер ТАС и т.п.). Некоторые из этих терминов, поясняются в Руководстве, некоторые, к сожалению, остаются понятными только узкому

2. В тексте требований присутствуют понятия, относящиеся к

106

кругу специалистов по криптографическим методам защиты информации.

3. Основную ценность, прежде всего для разработчиков ПО,

представляют содержащиеся в каждом блоке примеры приемлемых решений для удовлетворения конкретных требований к ПО.

4. Дополнения для риска класса Е содержат требования к ис-

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

Аналогичную структуру имеют блоки требований и по ос-

тальным аспектам требований к ПО.

В 2008 г. Международной организацией законодательной

метрологии (МОЗМ) был принята рекомендация D31 «Общие требования к программно контролируемым средствам измерений», методология которой близка рекомендациям WELMEC, о которых говорилось выше.

Здесь не случайно так детально рассмотрено содержание ре-

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

Основным отечественным нормативным документом, содер-

жащим требования к программному обеспечению средств измерений, в настоящее время является ГОСТ Р 8.654–2009 «ГСИ. Требования к программному обеспечению средств измерений. Основные положения». Эта Рекомендация, как уже было сказано, разработана с учетом требований Рекомендаций международных организаций по стандартизации и метрологии, таких, как Рекомендация КООМЕТ и уже упомянутые Рекомендации WELMEC и МОЗМ. Кроме того, в последнее время были разработаны мето-

107

дики институтов МИ 2955–2010 «ГСИ. Типовая методика аттестации программного обеспечения средств измерений» и МИ 3286–2010 «Проверка защиты программного обеспечения и определение ее уровня при испытаниях средств измерений в целях утверждения типа». Некоторые требования и методы определения соответствия эти требованиям содержатся также и в ГОСТ Р

8.596–2002 «ГСИ. Метрологическое обеспечение измерительных систем. Основные положения».

Если отвлечься от деталей, то характеристиками ПО СИ, подлежащими метрологической экспертизе, являются те характеристики, которые имеют прямое или косвенное отношение к задачам метрологической экспертизы и в конечном итоге качественно или количественно представляют требования, предъявляемые к ПО, которые устанавливаются ГОСТ Р 8.654, а именно:

а) требования к документации;

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

в) требования к соответствию характеристик тем, которые были установлены и приписаны ПО при испытаниях СИ с целью утверждения типа;

г) требования к идентификации;

д) требования к защите измерительной и иной хранимой и передаваемой информации от непреднамеренных и преднамеренных изменений;

е) требования к степени влияния на метрологические и ин- формационные характеристики СИ.

Детали этих требований можно найти как в ГОСТ Р 8.654, так и в учебном пособии [9.1].

3.10.1. Основные задачи метрологической аттестации

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

Основные задачи метрологической экспертизы программного обеспечения средств измерений сводятся к проверке на-

личия необходимой защиты измерительной информации от

непреднамеренных и преднамеренных воздействий, могущих

привести к искажению результатов измерений, а также

к оценке его влияния на метрологические характеристики

тех СИ и ИИС, где оно используется.

108

Понятно, что убедиться в правильности решения этих задач

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

Таким образом, при проведении метрологической экспертизы

ПО необходимо решать следующие основные задачи:

1) контроль правильности представления и изложения функ-

ций и структуры ПО СИ в программной документации, полноты и правильности оформления самой программной документации;

2) проверка структуры ПО СИ и наличия защищенных ин-

терфейсов связи и пользователя, методов и надежности идентификации программного обеспечения;

3) анализ и оценка решений и алгоритмов, заложенных в раз-

рабатываемое ПО, обеспечивающих необходимые требования, предъявляемые к ПО СИ;

4) оценивание наличия, уровня и методов защиты измери-

тельной информации от непреднамеренных и преднамеренных изменений;

5) определение возможных видов и источников погрешно-

стей, вносимых ПО, представляемым на экспертизу;

6) оценивание правильности представления результатов из-

мерений;

7) контроль правильности применения терминов, определе-

ний, наименований величин и их единиц.

Отметим некоторые из проблем, которые необходимо решить

в процессе экспертизы:

выделение той части ПО, которая должна подлежать МЭ, т.е.

выделение метрологически значимой части;

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

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

анализ постановки измерительной задачи, решаемой ПО, и

правильность ее реализации предлагаемыми алгоритмами;

правильность определения точностных характеристик циф-

ровых преобразований, определения и учета погрешностей, вносимых программно-аппаратными средствами при съеме, обработке и передаче измерительной информации;

109

обоснованность выбора конкретных значений и диапазона

%100)/()(

)()()(



refreftest

yyyx



)(ref



)(test



изменения опорных данных и моделей исходных данных;

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

обоснованность и правильность выбора источников измерительной информации;

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

Некоторые из перечисленных задач требуют пояснения.

Наибольшие сложности вызывает оценка точностных характеристик ПО.

Наличие в распоряжении специалистов, проводящих МЭ, опорного ПО позволяет ввести в рассмотрение такую количественную характеристику программного продукта как относительное отклонение результатов его вычислений от вычислений, выполненных опорным ПО, определяемое соотношением [9.8]

где исходных данных (как правило, опорных);

— результаты вычислений опорным ПО при некоторых

— результаты

вычислений тестируемым ПО при тех же исходных данных.

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

Существует ряд рекомендаций, посвященных вопросам так называемой «метрологической аттестации» программного обес-

110

печения [9.11, 9.12, 9.13]. Наиболее полно это направление работ по оценке качества программных продуктов представлено в [9.13]. Эта Рекомендация посвящена в основном методам оценки так называемой «погрешности неадекватности» измерительных задач, которая определяется как разность расчетного значения физической величины, рассматриваемого в качестве переменной математической модели объекта измерений, и результата ее независимого измерения в соответствующих расчету условиях. Следует отметить, что практически реализовать эту Рекомендацию по ряду причин не представляется возможным.

В Рекомендациях [9.11, 9.12] утверждается, что программное

обеспечение обладает метрологическими характеристиками, которые необходимо оценивать, в частности, при проведении МЭ. По нашему мнению, это ошибочная точка зрения. Еще раз подчеркнем, что ПО СИ не является средством измерений, оно не хранит в себе какую-либо меру или единицу измерения физической величины. Чтобы убедиться в этом, попробуйте произвести какое-либо измерение, имея на руках только программный продукт без соответствующего СИ. Правда, в последнее время появились так называемые виртуальные СИ, в которых все основные характеристики СИ, в том числе и метрологические, реализованы в программном виде. В некотором смысле можно говорить о метрологических характеристиках такого ПО, но только опосредствовано, поскольку в этом случае имеем дело, все-таки, с метрологическими характеристиками СИ. В настоящее время можно определенно говорить только о нормируемых метрологических характеристиках СИ и процесса измерений (выборочное среднее значение, СКО и т.п.).

Наиболее последовательно методология «метрологической ат-

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

Нас могут упрекнуть в непоследовательности из-за того, что,

возражая против использования термина «метрологическая аттестация», мы тем не менее пользуемся понятием «метрологическая экспертиза» по отношению к ПО и даже написали по этому пово-

<<< < Предыдущая 1 2 3 4 5 6 7 8 9 1011 / 1311 12 13 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]