Уровни соответствия программного обеспечения

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

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

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

На основе сформулированных критериев предлагается следующая классификация классов риска.

Риск класса А: Это наименьший класс риска из всех. Никаких конкретных мер не требуется против намеренных изменений программного обеспечения. Проверка программного обеспечения является частью функционального тестирования прибора. Установление соответствия требуется на уровне документации. Не ожидается, что какие-то средства измерений будут классифицироваться с риском класса А. Однако введением такого класса соответствующая вероятность предусматривается.

Риск класса В: По сравнению с риском класса А требуется «средний» уровень защиты программного обеспечения. Соответственно уровень проверки должен быть повышен к «среднему» уровню. Соответствие остается неизменным по сравнению с риском класса А.

Риск класса С: По сравнению с риском класса В уровень соответствия повышается к «среднему». Это означает, что часть программного обеспечения может быть декларирована как неизменяемая при утверждении типа. Для остальной части программного обеспечения соответствие требуется только на функциональном уровне. Уровни защиты и проверки остаются неизменными, как и при риске класса В.

Риск класса Б: Существенное отличие по сравнению с риском класса С заключается в повышении уровня защиты до «высокого». Уровень проверки остается неизменным на «среднем» уровне, существенно то, что информационная документация должна показать, что предпринятые меры защиты являются подходящими. Уровень соответствия остается неизменным, как и при риске класса С.

Риск класса Е: По сравнению с риском класса О уровень проверки повышается до «высокого». Уровни защиты и соответствия остаются неизменными.

Риск класса Е: Уровни по отношению ко всем аспектам (защита, проверка и соответствие) назначаются «высокими». Как и для риска класса А, не ожидается, что какое-нибудь средство измерений будет классифицироваться с риском класса Б. Однако введением такого класса соответствующая вероятность предусматривается.

Согласно Руководству проблема назначения классов рисков, сопровождающих использование ПО, является прерогативой соответствующих Рабочих групп YELMEC. Так, согласно решению Рабочей группы 11 VELMEC (2-е заседание, 3-4 марта 2005 г.), для счетчиков количества теплоты, контролируемых ПО в соответствии с требованиями на основе Руководства УЕЬМЕС 7.2, устанавливается риск класса С для СИ типа Р.

Схематическое представление типового блока требований к ПО, сформулированных в Руководстве YELMEC 7.2, показано в табл. 1.

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

Таблица 1

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

Главное содержание требования

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

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

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

Предусмотренная документация

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

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

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

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

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

...

Пример

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

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

Пример

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

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

...

Каждый блок требований содержит отчетливо выраженное требование. Он состоит из текста, поясняющего определения и разъясняющего специальные примечания из предусмотренной документации, руководства по подтверждению и примеров приемлемых решений (если они имеются). Содержимое блока требований может подразделяться в соответствии с классами риска.

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

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

  • 1. В обсуждаемом Руководстве значительное внимание уделено требованиям к встроенному ПО, используемому в СИ типа Р. Вместе с тем не ясно, как можно проконтролировать реализацию этих требований, поскольку доступ к ПО в большинстве случаев невозможен.
  • 2. Как уже отмечалось, в тексте требований присутствуют понятия, относящиеся к криптографическим методам защиты (контрольная сумма, алгоритм электронной подписи СЯС-16, номер ТАС — сертификата об утверждении типа и т.п.). Некоторые из этих терминов поясняются в Руководстве, некоторые, к сожалению, остаются понятными только узкому кругу специалистов по криптографическим методам защиты информации.
  • 3. Основную ценность, прежде всего для разработчиков ПО, представляют содержащиеся в каждом блоке примеры приемлемых решений для удовлетворения конкретных требований к ПО.
  • 4. Дополнения для риска класса Е содержат требования к исходному коду программы. Эта особенность в нормативных документах по метрологии встречается впервые. До сих пор под предлогом сохранения авторских прав этот вопрос оставался за пределами рассмотрения. Как показывает практика тестирования программных продуктов, в ряде случаев делать какие-то определенные заключения о качестве ПО можно только на основе анализа исходного кода или его фрагментов. Разумеется, это делается только с согласия разработчиков ПО, при этом в необходимых случаях заключается дополнительное соглашение о соблюдении конфиденциальности при тестировании ПО.

В Приложении к Руководству приведен пример тестирования программного обеспечения расходомера Эупайош. В принципе этим примером, как и всем Руководством УЕЬМЕС 7.2, можно пользоваться для тестирования как аналогичного ПО, так и других программных продуктов.

Требования к ПО, которые соотносятся с приведенными выше, содержатся также и в ГОСТ Р ИСО/МЭК 17025-2006 [16]. Для подтверждения этого приведем ряд положений этого документа.

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

a) разработанное пользователем компьютерное ПО достаточно подробно задокументировано и должным образом оценено как пригодное для применения;

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

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

  • 5.5.2. Оборудование и его программное обеспечение, используемые для проведения испытаний, калибровки и отбора образцов, должны обеспечивать требуемую точность и соответствовать техническим требованиям, предъявляемым к испытательным и/или калибровочным работам.
  • 5.5.4. Каждая единица оборудования и ее программное обеспечение, используемые при проведении испытаний и/или калибровок и оказывающие влияние на результат, должны быть, если это практически осуществимо, однозначно идентифицируемы.
  • 5.5.12. Регулировка испытательного и калибровочного оборудования, включая аппаратные средства и ПО, которые могут сделать недействительными результаты испытаний и/или калибровок, должна быть исключена».

Требования к ПО СИ содержатся также в Рекомендации КООМЕТ К/ЕМ/10:2004 [17] и в ряде других международных документов и рекомендаций.

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ ОРИГИНАЛ   След >