Испытания ПО средств измерений: учебное пособие

Ю.А. Кудеяров
ИСПЫТАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СРЕДСТВ ИЗМЕРЕНИЙ
Учебное пособие
Москва
2017 г.
Содержание
Стр.
Предисловие.……………………………………………………………………………………3
Часть 1. ОБЩИЕ ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ СРЕДСТВ ИЗМЕРЕНИЙ………………………………………………………………………………………..6
Глава 1. Основные понятия, термины и определения, относящиеся к программному обеспечению средств измерений……………..……………………………………………………...6
§ 1.1. Определение программного обеспечения……………………………………………….6
§ 1.2. Особенности программного обеспечения, используемого в средствах измерений и
при обработке измерительной информации…………………………………………………...6
§ 1.3. Классификация программного обеспечения……………………………………………8
§ 1.4. Испытания программного обеспечения и их особенности……………………………10
§ 1.5. Источники погрешности программного обеспечения и риски, связанные с его использованием……………………………………………………………………………………13
Глава 2. Нормативная база испытаний программного обеспечения средств измерений….21
§ 2.1. Рекомендации международных организаций по стандартизации и метрологии……21
§ 2.2. Отечественная нормативная база испытаний программного обеспечения средств измерений………………………………………………………………………………………….30
Глава 3. Основные требования, предъявляемые к программному обеспечению средств измерений………………………………………………………………………………………….35
Часть 2. ТИПОВЫЕ МЕТОДЫ ИСПЫТАНИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
СРЕДСТВ ИЗМЕРЕНИЙ………………………………………………………………………39
Глава 4. Методы испытаний и показатели качества программного обеспечения средств
измерений……………………………………………………………………………………….39
§ 4.1. Методы испытаний программного обеспечения средств измерений и их особенности.……………………………...……………...………………………………………………..39
§ 4.2. Характеристики программного обеспечения и исполнительные параметры……….45
Глава 5. Испытания программного обеспечения средств измерений, основанные на использовании опорного программного обеспечения………………………………………….51
§ 5.1. Испытания автономного программного обеспечения…………………………………51
§ 5.2. Испытания встроенного программного обеспечения…………………………………63
Глава 6. Методы испытаний программного обеспечения средств измерений.........……….70
§ 6.1. Метод генерации опорных данных……………………………………………………..70
§ 6.2. Метод моделей исходных данных……………………………………………………...77
§ 6.3. Испытания программного обеспечения сканирующих зондовых микроскопов……81
§ 6.4. Испытания программного обеспечения средств измерений методом перекрестной
проверки (кросс-валидации)…………………………………………………………………..88
§ 6.5. Анализ исходного кода программного обеспечения средств измерений……………92
Глава 7. Испытания программного обеспечения при испытаниях средств измерений с целью утверждения типа………………………………………………………………………….97
Список литературы……………………………………………………………………………102
Приложения……………………………………………………………………………………106
2
Предисловие
Современные средства измерений (СИ) невозможно представить без программных
продуктов, предназначенных для съема, передачи, обработки, хранения и представления
измерительной информации. Такое программное обеспечение (ПО) существенно расширяет функциональные возможности СИ и повышает оперативность обработки измерительной информации. Вместе с тем использование ПО в СИ сопряжено с возможным проявлением рисков, обусловленных как собственными свойствами ПО, так и внешними причинами. Эти риски необходимо оценивать и контролировать. Однако до недавнего времени даже для СИ, попадающих в сферу государственного регулирования в области обеспечения единства измерений, при их испытаниях с целью утверждения типа характеристики
и свойства ПО в большинстве случаев не исследовались и не устанавливались. В настоящее время ситуация изменилась.
В ст. 9 новой редакции Федерального закона РФ «Об обеспечении единства измерений» [1] появилась норма о включении в необходимых случаях в состав обязательных
требований к СИ требований к их составным частям, программному обеспечению и условиям эксплуатации. Что имеется в виду под «необходимыми случаями» в законе не указано, однако очевидно, что в первую очередь речь идет о сфере государственного регулирования в области обеспечения единства измерений. Сюда также следует отнести нормы
п. 7.1 статьи 7 и п. 2 статьи 9 этого закона о конструкции эталонов единиц величин и
средств измерений, которая в целях предотвращения несанкционированных настройки и
вмешательства, могущих привести к искажениям воспроизведения, хранения и передачи
единицы величины, шкалы величины (шкалы измерений), а также результатов измерений,
должна обеспечивать ограничение доступа к их определенным частям (включая программное обеспечение).
Задача специалистов метрологических служб заключается в том, чтобы обеспечить
выполнение этих законодательных норм.
В связи с этим необходимо отметить приказ Минпромторга России от 30 ноября
2009 г. № 1081 [2], определяющий как порядок проведения испытаний стандартных образцов или средств измерений в целях утверждения типа, так и порядок выдачи свидетельств об утверждении типа стандартных образцов или типа средств измерений. Этот
приказ устанавливает, что в описании типа СИ должны быть отражены такие параметры
ПО (если оно используется) как идентификационные признаки, степень влияния ПО на
метрологические характеристики (МХ) СИ и уровень защиты. Положения этого приказа
нашли дальнейшее развитие и закрепление в Административном регламенте по предо3
ставлению Федеральным агентством по техническому регулированию и метрологии государственной услуги по утверждению типа стандартных образцов и или типа средств измерений (утвержден Приказом Минпромторга России от 25 июня № 970) [3] и в рекомендациях Росстандарта Р 50.2.077-2014 «ГСИ. Испытания средств измерений в целях утверждения типа. Проверка защиты программного обеспечения» [4]. Кроме того, во исполнение указанных законодательных норм во Всероссийском научно-исследовательском институте метрологической службы (ФГУП «ВНИИМС) были разработаны и утверждены
два национальных стандарта ГОСТ Р 8.654-2015 «ГСИ. Требования к программному
обеспечению средств измерений. Основные положения» [5] и ГОСТ Р 8.883-2015 «ГСИ.
Программное обеспечение средств измерений. Алгоритмы обработки, хранения, защиты и
передачи измерительной информации. Методы испытаний» [6].
Таким образом, следует констатировать, что перед работниками метрологических
служб появились новые задачи, связанные с необходимостью выполнения указанных законодательных норм в области обеспечения единства измерений, в том числе, с оцениванием свойств и характеристик ПО, используемого в СИ.
Цель предлагаемого пособия заключается в ознакомлении специалистов метрологических служб с имеющимися на данный момент наработками, относящимися к оцениванию свойств и характеристик ПО СИ.
Пособие состоит из двух частей. В первой части (Главы 1,2,3) рассмотрены вопросы терминологии, имеющейся нормативной базы и общих требований к программному
обеспечению, используемому при обработке измерительной информации. Во второй части
(Главы 4,5,6,7) рассматриваются типовые методики испытаний, при этом основное внимание уделено методу «черного ящика». В Приложения вынесены материалы, относящиеся
к некоторым математическим аспектам испытаний ПО, и материалы реальных испытаний
ПО при утверждении типа СИ.
В пособии использованы некоторые отечественные разработки, а также публикации Национального института стандартов и технологий (NIST) (США), Национальной физической лаборатории (NPL) (Великобритания) и Физико-технического бюро (РТВ) (ФРГ)
по обсуждаемой проблеме.
Пособие рассчитано на разработчиков и пользователей соответствующего программного обеспечения, а также на специалистов государственных центров испытаний
(ГЦИ) средств измерений и тех, кто по тем или иным причинам интересуется и занимается
проблемами испытаний ПО СИ.
Автор благодарен своим коллегам:
4
заместителю руководителя Федерального агентства по техническому регулированию и
метрологии С.С. Голубеву за научное сотрудничество при сертификации ПО СИ в бытность его начальником лаборатории ФГУП «ВНИИМС»;
сотрудникам ФГУП «ВНИИМС» А.А. Дудыкину, М.В. Козлову, А.Н. Панькову и А.А.
Сатановскому за активное участие в проведении испытаний ПО, за помощь в проведении
численных расчетов и многократные обсуждения, а также Ю.В. Стефанову, А.Ю. Стефанову и А.Г. Спроге за обсуждение требований к ПО СИ.
5
Часть 1. ОБЩИЕ ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
СРЕДСТВ ИЗМЕРЕНИЙ
Глава 1. Основные понятия, термины и определения, относящиеся к программному
обеспечению средств измерений.
§ 1.1. Определение программного обеспечения.
Прежде чем рассматривать по существу проблему оценивания свойств и характеристик ПО при его испытаниях, необходимо определиться с предметом обсуждения.
В разных нормативных документах имеется разные определения ПО СИ. В настоящем учебном пособии под программным обеспечением средств измерений будет пониматься компьютерная программа или совокупность программ, предназначенных для
использования в средствах измерений и реализующих, в том числе, сбор, передачу,
обработку, хранение и представление измерительной информации, а также программные модули, компоненты и программная документация, необходимые для функционирования этих программ.
При этом, например, алгоритм обработки экспериментальных данных (результатов
измерений), полученных при измерении, представляет собой последовательность арифметических и логических операций, производимых с этими данными (с учетом априорной
информации) с целью определения окончательного результата измерения и характеристик
его погрешности. Некоторые программные продукты реализуют только часть функций,
перечисленных в определении.
В большинстве случаев из всех алгоритмов, реализуемых компьютерной программой, алгоритм обработки экспериментальных данных может оказывать самое существенное влияние на численные результаты обработки.
§ 1.2. Особенности программного обеспечения, используемого в средствах измерений
и при обработке измерительной информации.
Необходимость испытаний ПО СИ, особенно тех средств, которые попадают в сферу государственного регулирования в области обеспечения единства измерений, обусловлена рядом особенностей, присущих такому ПО, что отличает его от ПО, применяемого в
других областях. Эти особенности сводятся к следующему:
1. Использование ПО в СИ не должно приводить к искажению измерительной информации, другими словами, ПО не должно оказывать влияние на метрологические характеристики СИ, или это воздействие должно быть минимальным и оцениваемым;
6
2. ПО СИ должно быть защищено от преднамеренных и случайных изменений программного кода, измерительной информации, параметров, определяющих тип СИ, конструктивных и других параметров, внесенных в программное обеспечение;
3. ПО, используемое в конкретных СИ данного типа, должно обладать необходимыми идентификационными признаками и полностью соответствовать тому, что было
установлено при испытаниях СИ с целью утверждении типа.
Имеется еще одна особенность, относительно которой нет единого мнения даже о
необходимости ее упоминания. Речь идет о затратах и усилиях, требуемых для испытаний
ПО. Если эти затраты и усилия становятся сопоставимыми с затратами и усилиями, требуемыми на его разработку, и даже больше, то возникает вопрос о целесообразности такой
деятельности. Специалисты РТВ (Физико-технического бюро – ведущего метрологического учреждения Германии) предложили следующий условный критерий:
продолжительность и усилия, необходимые для испытаний ПО при утверждении типа СИ
должны быть того же порядка, что и усилия, затрачиваемые при таких испытаниях самих
СИ.
На самом деле все зависит от конкретной ситуации, от свойств конкретного программного продукта. Иногда усилия на испытания могут оказаться и меньше тех, которые
сформулированы в предложенном критерии, иногда больше. Во всяком случае, предложенный критерий, несмотря на его условность, может служить неким ориентиром для
назначения сроков и цены, необходимых для проведения испытаний ПО СИ.
Перечисленные особенности ПО СИ должны лечь в основу решения первой задачи,
поставленной Законом РФ «Об обеспечении единства измерений» перед специалистами
органов, уполномоченных на проведение испытаний ПО СИ (далее - уполномоченных органов): формулировки требований к программному обеспечению средств измерений.
Несколько слов о терминологии. Основная процедура, которая должна использоваться при оценке свойств и характеристик ПО – это его испытания, при этом различают
сертификационные испытания ПО и его испытания при испытаниях автоматизированных
СИ с целью утверждения типа. На самом деле это различие условно. И в том и в другом
случае речь идет об одинаковых технических и программных процедурах, но имеются некоторые отличия. В большинстве случаев сертификационные испытания носят более широкий характер в отличие от испытаний с целью утверждения типа, которые ограничиваются только проверкой идентификационных данных, уровня защиты и оценкой влияния
ПО на МХ СИ. При сертификационных испытаниях, в дополнение к указанным проверкам, может проверяться документация ПО, его структура, разделение на метрологически
7
значимую и не значимую части и другие информационные технологии, взаимодействие
между интерфейсами связи и пользователя, исходный код программ.
Часто используется также термин «тестирование ПО» как синоним термина «испытания». Это не совсем верно. Под тестированием ПО понимается только серия технических операций (функциональных проверок) для подтверждения соответствия испытываемого ПО и его алгоритмов требованиям нормативных документов. Из сказанного следует,
что тестирование является частью испытаний. В пособии этот термин будет употребляться тогда, когда он необходим.
В ранних документах, относящихся к ПО СИ, употреблялся термин «аттестация
программного обеспечения», иногда речь шла даже о его «метрологической аттестации».
Все эти термины в настоящее время являются внесистемными, поскольку в таком исходном нормативном акте, как Закон РФ «Об обеспечении единства измерений» [1], речь идет
только об аттестации методик (методов) измерений. Свое отношение к обсуждаемой проблеме выразило управление метрологии Росстандарта в своих письмах от 07.03.2014 г.
№ 20/30-464 и от 02.04.2014 г. № 120/30-915, в которых, в частности, сказано:
«…Управление метрологии Росстандарта считает недопустимым осуществление деятельности по подтверждению соответствия ПО СИ в форме аттестации программного обеспечения. В целях соблюдения требований законодательства РФ в области обеспечения единства измерений и формирования единого подхода к оценке свойств и характеристик ПО
СИ просим проводить такую оценку в соответствии с действующим законодательством,
т.е. либо в виде процедур, предусмотренных Приказом Минпромторга от 30 ноября
2009 г. № 1081, регламентирующего порядок проведения испытаний стандартных образцов и средств измерений при утверждении типа, либо в виде процедуры подтверждения
соответствия в системах добровольной сертификации».
§ 1.3. Классификация программного обеспечения.
Классификация ПО определяется критериями, положенными в основу такой классификации.
По отношению к аппаратной реализации различают встроенное и автономное ПО.
Встроенное ПО, как правило, предназначено для решения конкретной, частной измерительной задачи. Если ПО встроенное, то вычислительное устройство (микропроцессор) вместе с программным обеспечением, «зашитым» в постоянное запоминающее
устройство (ПЗУ) вычислительного компонента, расположены внутри корпуса средства
измерений и имеют защищенный интерфейс. Прямой доступ к программному обеспечению в большинстве случаев отсутствует.
8
Автономное ПО представляет собой самостоятельный программный продукт, записанный, как правило, на переносных носителях (компакт-диск, флэш – карта и т.п.), который используется в средствах измерений на основе универсального компьютера, в том
числе в СИ на основе персонального компьютера (ПК).
В общем случае деление ПО на встроенное и автономное носит условный характер,
поскольку встречаются измерительные системы, обладающие признаками как того, так и
другого.
По отношению к некоторым функциональным особенностям можно различать:
готовое (коммерческое) ПО;
модифицированное коммерческое ПО;
пользовательское (заказное) ПО.
Готовое (коммерческое) ПО – это ПО, которое приобретено (куплено) и используется без возможности его модификации. К такому ПО относятся, например, программные
продукты Microsoft Excel, Mathcad, Matlab, Mathematica и другие подобные программы. К
этой группе можно отнести и встроенное ПО.
В модифицированном коммерческом ПО код может быть изменен по отношению к
исходному программному продукту для специальных приложений. Примерами такого ПО
являются программы, разработанные в Lab Windows, Lab View и др., которые представляют собой, в частности, интегрированную среду программирования измерительных систем. Такие программные продукты могут выступать как ПО виртуальных приборов,
представляющих собой компьютер, плату ввода/вывода сигналов и программную среду,
разработанную, например, в Lab View. Подобные виртуальные приборы могут использоваться для измерений посредством имитации электрическими сигналами таких физических величин как напряжение, сила тока, мощность, температура, давление, скорость,
ускорение, параметры вибрации и т.п.
Пользовательское (заказное) ПО разрабатывается самим пользователем или субподрядчиком и написано на таких языках программирования как, например, C++, Visual
Basic, Database Design, Delphi и др. Такое ПО требует самой тщательной проверки.
Можно предложить и другие способы классификации ПО. Так в национальном
стандарте ГОСТ Р 8.654 – 2015 [5] рассматриваются следующие виды программного
обеспечения:
ПО СИ, в том числе измерительных и информационно-измерительных систем;
ПО автоматизированных систем управления, функционирующих с использованием СИ
или компонентов измерительных систем;
9
ПО контроллеров и вычислительных блоков, не входящих в состав измерительных систем, а также технических систем и устройств с измерительными функциями, осуществляющих обработку и представление измерительной информации и т.д.
Если в основу классификации положить другие критерии, такие как, например, режим эксплуатации, стабильность, функциональные возможности, требования к вычислительным возможностям, критичность (см. ниже), использование программных данных и
т.п., то для этих целей можно воспользоваться рекомендациями национального стандарта
ГОСТ Р ИСО/МЭК 12182-2002 [7].
§ 1.4. Испытания программного обеспечения и их особенности.
Как известно, все СИ с целью обеспечения единства измерений подвергаются
оценке соответствия определенным требованиям при испытаниях с целью утверждения их
типа и поверке, если они используются в сфере государственного регулирования в области обеспечения единства измерений. Для определения метрологических характеристик
СИ, не используемых в этой сфере, применяется их калибровка. Из сказанного следует,
что ПО, входящее в состав или сопровождающее СИ, должно быть в том или ином виде
оценено. При этом речь должна идти не только об оценивании правильности функционирования ПО, определяемого алгоритмами программы, но и о его документировании, идентификации, защите, а также о других задачах оценивания, общих для всех видов ПО.
Возвращаясь к терминологическим проблемам, следует отметить, что в отличие от
средств измерений программное обеспечение не хранит в себе никаких мер измеряемых
физических величин и никак не используется напрямую в измерительном процессе, поэтому метрологическими характеристиками, присущими средствам измерений (имеется в
виду ГОСТ 8.009-84 «ГСИ. Нормируемые метрологические характеристики средств измерений»), оно не обладает. Как уже говорилось, это всего лишь вспомогательное средство,
расширяющее функциональные возможности средств измерений и повышающее оперативность обработки измерительной информации, не более того. Тот факт, что для оценки
качества программных продуктов иногда используются, как и в метрологии, методы математической статистики, вовсе не означает, что на этом формальном основании следует
приписывать им какие-то метрологические характеристики и заниматься их метрологической аттестацией. Конечно, программное обеспечение, как компонента средства измерений, вносит свой вклад в методическую составляющую его погрешности, подчеркнем, в
составляющую погрешности СИ.
Могут возразить, что в последнее время появились так называемые виртуальные
средства измерений и виртуальные меры, которые хранятся в памяти компьютеров и ис10
пользуются, например, при линейных измерениях в нанометровом диапазоне длин [8]. На
самом деле и в этом случае программное обеспечение выполняет только вспомогательные
функции хранения в памяти и программного воспроизведения виртуальных мер, но при
этом процесс калибровки таких средств измерений и мер основан на вполне реальных
экспериментальных процедурах, не имеющих прямого отношения к программному обеспечению. Конечно, можно согласиться, что в данном случае проблема далеко не очевидна
и требует дальнейшего более детального рассмотрения, но если иметь в виду не виртуальные, а вполне реальные автоматизированные СИ, которых подавляющее большинство, то
здесь обсуждаемая проблема отсутствует.
Составляющие погрешности, вносимой ПО в результаты расчетов и, в конечном
итоге в методическую погрешность средства измерений, хорошо известны, и они подробно будут рассмотрены далее. Это, прежде всего, погрешность численной схемы расчета
математических выражений. Это также погрешности, обусловленные переходом от десятичного представления дробей к двоичному и наоборот, обрывом бесконечных рядов библиотечных функций, округлением на промежуточных и окончательных этапах результатов расчета, заменой точечных (числовых) и вероятностных характеристик измеряемых
величин их приближенными (экспериментальными) значениями, неустойчивостью алгоритмов при определенных наборах входных данных и т.п.
Из сказанного следует, что при использовании ПО в СИ или для обработки измерительной информации необходимо оценивать степень его влияния, как на метрологические
характеристики СИ, так и на результаты обработки. При этом не важно, в каком виде будет проводиться такая оценка, в виде сертификации, или в виде составной части испытаний СИ с целью утверждения их типа. В любом случае методика такой оценки может быть
одинаковой для всех видов оценки, отличие сведется только к разным формам представления (документирования) результатов такой оценки (сертификат соответствия, запись в
описании типа СИ и т.п.).
В дальнейшем, для определенности, будет использоваться термин «испытания программного обеспечения». При этом под испытанием программного обеспечения понимается исследование с целью определения его характеристик и свойств и установления соответствия этих характеристик и свойств требованиям нормативной документации с
последующей регистрацией полученных результатов испытаний в сертификате соответствия или описании типа средства измерений (с указанием использованных методов
испытаний). В качестве характеристик и свойств программного обеспечения могут рассматриваться, например, степень его соответствия сопровождающей (сопутствующей)
документации, способы и методы его идентификации, наличие или отсутствие защищен11
ных интерфейсов, разделение на метрологически значимые и незначимые части, степень
влияния на метрологические характеристики средства измерений, реализованные уровни
защиты от непреднамеренных и преднамеренных изменений и т.д. и т.п., словом, то, что
предусмотрено требованиями к программному обеспечению средств измерений [5]. Это
определение учитывает тот факт, что ПО не является средством измерений и в большинстве случаев является лишь дополнением к СИ, расширяющим его функциональные возможности и повышающим оперативность его функционирования. В силу этого требования, предъявляемые к нему, в общем случае отличаются от требований, предъявляемых к
СИ.
Для полноты рассмотрения необходимо упомянуть еще одну процедуру, которую
предлагается применять для оценки качества ПО. Речь идет о «валидации». Валидация
определена руководством [9] как подтверждение с помощью экспертизы и предоставления
объективных доказательств (т.е. достоверной информации, основанной на фактах, полученных при наблюдении, измерении, тестировании и т.д.) того, что соблюдены конкретные требования для указанного предполагаемого использования программного обеспечения. Таким образом, при валидации необходимо показать, что испытываемое ПО подходит
для решения конкретной измерительной задачи в конкретных условиях. Под такими условиями понимают диапазоны изменения входных величин, требуемую точность конечного
результата, погрешности входных величин и др. Можно, однако, заметить, что валидация,
по сути, является частью процедуры испытаний ПО.
В дополнение к сказанному ранее, испытаниям могут также подвергаться следующие виды программного обеспечения:
программы, сопровождающие и обеспечивающие воспроизведение, хранение и передачу
размеров (шкал) физических величин в эталонах;
алгоритмы и программы обработки данных в методиках поверки и в методиках измерений;
алгоритмы обработки данных, представляющие собой самостоятельные объекты использования;
программы обработки данных, реализующие выбранный алгоритм обработки и представляющие собой самостоятельный программный продукт;
алгоритмы и программы обработки данных в составе прикладного программного обеспечения конкретных измерительных устройств, информационно-вычислительных комплексов и информационно-измерительных систем.
Необходимо отметить также следующее. Существует, так сказать, формальная сторона испытаний ПО, сводящаяся к необходимости оформления методик, протоколов и до12
кументов, отражающих итоги испытаний по установленным формам. Вместе с тем, основой испытаний по существу является методология их проведения, находящая свое отражение в методиках и методах (способах, приемах), используемых при испытаниях ПО. В
настоящем пособии внимание, прежде всего, будет уделено именно этой стороне проблемы.
§ 1.5. Источники погрешности программного обеспечения и риски, связанные с его
использованием.
Источниками погрешности, вносимой ПО в численные результаты измерений, как
было отмечено, могут быть:
погрешность численной схемы расчета математических выражений измерительной задачи;
перевод чисел из десятичной системы счисления в двоичную и наоборот;
округление на промежуточных и окончательном этапах вычислений и ограниченность
разрядной сетки;
обрыв бесконечных рядов, являющихся представлениями большинства используемых при
вычислениях библиотечных функций;
замена точечных (числовых) и вероятностных характеристик измеряемых величин их
приближенными (экспериментальными) и табличными значениями;
неудачный выбор алгоритмов вычислений, в частности, алгоритмов, не обладающих необходимой точностью вычислений, или использование так называемых неустойчивых
(необусловленных) алгоритмов и др.
Пример, относящийся к влиянию на точность ПО перевода чисел из десятичной системы в двоичную и наоборот, взят из работы [10].
Как известно, компьютер проводит операции с числами в двоичной форме. Проблемы возникают тогда, когда число цифр в таком представлении является неопределенным. Типичным примером такой ситуации является представление десятичной дроби 0,1 в
двоичной системе счисления, в которой это число выглядит так: 0.0001100110011. Здесь
чертой подчеркнуты цифры, которые в таком представлении периодически повторяются.
В свою очередь, компьютер не может представить неопределенное число цифр, он это делает с конечной точностью.
Напомним, что указанное представление десятичной дроби 0,1 в двоичной системе
возникает при использовании схемы Горнера. Исходным в этой схеме является утверждение о том, что любое число меньше единицы в двоичной системе счисления может быть
записано в форме
13
x  a1  2 1  a2  2 2  ...  an  2  n ,
(1)
где коэффициенты ai могут принимать значения 0 или 1, и их необходимо определить. По
схеме Горнера это число может быть представлено в следующей эквивалентной форме
x  2 1 (a1  2 1 (a2  2 1 (a3  ...  (2 1 an )...).
(2)
Из этой формы видно, что явное представление коэффициента a1 появляется тогда,
когда исходное число умножается на 2. При этом могут возникнуть два случая:
удвоенное исходное число остается меньше 1, тогда коэффициенту a1 приписывается значение 0 и производится дальнейшее удвоение получившегося результата для определения
последующего коэффициента в представлении (2);
удвоенное исходное число будет больше единицы, тогда коэффициенту a1 приписывается
значение 1, а остаток от результата удвоения остается для дальнейшего удвоения с целью
определения последующего коэффициента в представлении (2).
Для случая десятичной дроби 0,1 эти общие рассуждения конкретизируются в соответствии со схемой, изображенной ниже.
Теперь предположим, что вычисления производятся с обычной точностью, при
этом компьютер представляет десятичные дроби в двоичной системе с 25 значащими
цифрами. В этом случае число 0,1 будет иметь следующее двоичное представление:
0.0001100110011001100110011.
Обращая это двоичное число обратно в десятичное, получаем число 0,099999964 с точностью до седьмого знака после запятой. Это то число, которое «видит» компьютер, когда в
Исходное число 0,1
0,2
0,4
0,8
1,6 (остаток 0,6)
1,2 =(0.6×2)
0,4 = 1,6-1,2
0,8
1,6 (остаток 0,6)
1,2 = (0.6×2)
Коэффициенты ai
0.
0
0
0
1
1
0
0
1
1 и т.д.
Схема Горнера для представления дроби 0,1 в двоичной системе счисления.
него вводится число 0,1. С другой стороны, если ввести число 100000, то его двоичное
представление будет
11000011010100000.0000000
14
и оно обращается точно в число 100000. В написанных выше числах точка разделяет
двойки в положительной и отрицательной степени.
Складывая числа 100000 и 0,1, в двоичном представлении с обычной точностью получаем
11000011010100000.0001100.
Обращая это число обратно в десятичное представление, получаем не 100000,1, а
100000,09375, которое является точным только до двух знаков после запятой. Таким образом, в рассматриваемом случае добавление числа с точностью до семи знаков после запятой к числу той же точности приводит к сумме, точность которой меньше точности исходных чисел. Точно так же вычитание с той же обычной точностью приводит к такому
же результату, поскольку в этом случае компьютер «видит» разность (100000,1 – 100000)
как 0,09375, несмотря на то, что в двоичном представлении исходные числа были заданы с
точностью до седьмого знака после запятой. Приведенный пример показывает, что для
больших чисел, отличающихся только какими-то десятичными долями, компьютер не
способен представить различие между этими числами с необходимой точностью.
Известно, что возможны ситуации, когда при вычислениях с обычной точностью
возникают погрешности округления, которые, в принципе, могут накапливаться и приводить к тому, что окончательный ответ может не содержать точных цифр. В большинстве
случаев такие проблемы обходятся вычислениями с удвоенной точностью, если такие вычисления предусмотрены на всех промежуточных этапах.
Не будем обсуждать очевидный вопрос, связанный с погрешностью, обусловленной обрывом бесконечных рядов при численных расчетах.
Теперь рассмотрим понятия, относящихся к устойчивости (обусловленности) используемых алгоритмов обработки данных.
Проблеме устойчивости алгоритмов при численных расчетах уделено большое
внимание в публикациях NPL (см., например, [11]). Некоторые из аспектов этой проблемы
будут рассмотрены ниже. Пока ограничимся только общими замечаниями.
Устойчивость (обусловленность) алгоритма является параметром, описывающим
чувствительность «точного» решения измерительной задачи к изменению условий задачи
(определение коэффициента устойчивости (обусловленности) дано в Приложении 1).
Если малые изменения в условиях задачи или в данных приводят к малым изменениям в ее решении, то такая задача является устойчивой (хорошо обусловленной). С другой стороны, если малые изменения в данных приводят к значительным изменениям в решении, то задача называется неустойчивой (плохо обусловленной) по отношению к данным. Для некоторых плохо обусловленных задач разработаны методы регуляризации, с
15
помощью которых можно получать результаты с численной точностью, характерной для
хорошо обусловленных задач. Рассмотрение таких задач выходит за рамки обсуждаемых
проблем и поэтому в этом пособии рассматриваться не будет.
Проблему обусловленности поясним на примере хорошо известной метрологам задачи вычисления среднего квадратичного отклонения s (СКО) (пример взят из работы
[11]).
Известно, что для набора измеренных данных {xi : i  1,..., m} существуют две математически эквивалентных формулы для вычисления СКО
s {
1 m
 ( xi  x ) 2 }1 / 2
m  1 i 1
(3)
и
m
1
s {
( xi2  mx 2 )}1 / 2 ,
m  1 i 1
(4)
где среднее арифметическое определяется формулой
x
1 m
 xi .
m i 1
(5)
Формула (4) характеризуется тем, что при малом разбросе данных относительно
среднего значения может теряться точность вычисления СКО. Например, если xi принимает значения {0,98; 0,99; 1,00; 1,01; 1,02}, то в выражении
5
 x  mx = 5,0010 – 5,0000 = 0,0010
i 1
2
i
2
теряется две значащих цифры. Для некоторых наборов данных может получиться так, что
x
2
i
будет равна mx 2 для всех цифр, удерживаемых компьютером. Более того, из-за по-
грешности округления, о которой уже говорилось, может оказаться, что второй член в
написанном выше выражении будет больше первого, и для того, чтобы не оперировать с
мнимыми величинами, компьютер будет выдавать нулевой результат для СКО, которое на
самом деле таковым не является. Все это вовсе не означает, что нельзя пользоваться формулой (4). Это только означает, что при некоторых наборах данных необходимо проявлять
определенную осторожность при ее применении. В то же время формула (3) указанными
особенностями не обладает, и вычисления с ее помощью приводят к корректному результату. К сожалению, в ряде программных продуктов для вычисления СКО используется
формула (4).
Уже отмечалось, что использование ПО в общем случае сопряжено с проявлением
ряда рисков, о некоторых из которых было сказано выше.
16
В литературе [12] различают группы рисков, связанные с:
нефункциональностью, неадекватностью и неполнотой ПО;
некорректностью кода;
неправильной поддержкой данных;
неправильным использованием ПО;
проблемами управления.
Нефункциональность, неадекватность и неполнота ПО проявляются, прежде всего,
на уровне математических алгоритмов, включая математическое обоснование измерительных процедур (т.е. математическую модель измерительной задачи). Эти же проблемы
начинают проявляться, когда ПО начинает использоваться в условиях, на которые оно не
рассчитано. Проблемы, связанные с неполнотой ПО, начинают также проявляться в тех
случаях, когда отсутствует достаточная программная поддержка таких функций, как:
ввод, использование и архивирование так называемых опорных наборов данных (моделей
исходных данных);
ввод параметров тестируемых объектов;
контроль измерительных процедур;
распечатка протоколов испытаний и сертификатов;
архивирование результатов измерений.
Исходный код ПО пишется людьми. Это как раз и является основной причиной того, что абсолютная правильность кода не может быть гарантирована. Нельзя исключить
небрежность и даже систематические ошибки при написании кода. Несмотря на то, что
разработано большое число тестов ПО и программ обнаружения ошибок, однако, при
этом риск их появления в исходном коде исключить полностью нельзя. В качестве иллюстрации обсуждаемой проблемы можно привести полусерьезное, полушутливое утверждение, имеющее хождение среди программистов: «Любая программа содержит, как минимум, три ошибки. После их исправления ошибок будет не менее пяти».
Программная поддержка данных может также явиться критическим фактором, влияющим на погрешность результатов измерений. Малые изменения данных, обусловленные, в первую очередь, их преобразованием, могут иметь самые серьезные последствия
для результатов измерений. Наряду с возмущением данных, обусловленным их численной
обработкой, они могут искажаться при их передаче и преобразовании в различных средах,
системах, а также и людьми.
Неправильное использование или злоупотребление программным обеспечением
представляют собой другую критическую ситуацию, когда система обработки измерительной информации может оказаться несостоятельной. В ряде случаев пользователи бы17
вают даже не осведомлены, когда это случается. Имеется две типичных причины, приводящих к неправильному использованию ПО:
неточность или недостаточность документации, сопровождающей ПО; неточность интерпретации или неполнота комплекта документации у пользователя;
нестабильность поведения ПО при использовании в условиях, на которые оно не рассчитано, или попытки пользователя на свой страх и риск внести в него изменения.
ПО является «живым» продуктом. Оно обладает определенным жизненным циклом, и его характеристики могут по разным причинам с течением времени меняться. Изменение ПО приводит к риску появления управленческих ошибок. Поскольку ПО может
управляться и контролироваться разными субъектами, имеется вероятность появления таких проблем как несовместимость различных частей ПО, незаконные версии, некорректная документация и т.п. С другой стороны, поскольку ПО может достаточно легко изменяться, то отсутствуют естественные барьеры для предотвращения этого. Как следствие,
должны быть установлены строгие правила предотвращения этих проблем. Важное правило заключается в полной и однозначной идентификации частей ПО, подлежащих индивидуальному управлению, а также пользование единой управленческой версией и установление соответствия между версиями и документацией. Более подробно об этом будет
сказано далее.
Контрольные вопросы к Главе 1.
1.
Что имеется в виду, когда говорят о программном обеспечении средств измерений?
2.
По отношению к какой реализации различают встроенное и автономное программное обеспечение?
А) К функциональным особенностям, Б) К аппаратной реализации, В) К программной реализации, Г) К пользовательским возможностям.
3.
Какое программное обеспечение требует самой тщательной проверки?
А) Готовое коммерческое, Б) Модифицированное коммерческое, В) Пользователь
ское (заказное), Г) Приобретенное на Митинском или Савеловском рынках.
4.
Какая часть программного обеспечения может оказывать самое значительное влияние на метрологические характеристики средства измерений?
А) Подпрограмма обработки результатов измерений, Б) Подпрограмма снятия результатов измерений с первичных датчиков, В) Подпрограмма представления результатов обработки, Г) Подпрограмма передачи измерительной информации по
кабелю связи.
18
5. Дайте определение испытаний программного обеспечения средств измерений.
6. Насколько правомочно применение термина «аттестация» по отношению к программному обеспечению средств измерений?
А) Правомочно, Б) Неправомочно, В) Допустимо, чтобы не вносить путаницу в
имеющиеся нормативные документы, Г) Следует избегать его применения.
7. Отличается ли валидация программного обеспечения от его испытаний?
А) Не отличается, Б) Является одним из видов испытаний, поскольку при валидации необходимо показать, что данное программное обеспечение подходит для решения конкретной измерительной задачи в конкретных условиях, В) Отличается
существенно, Г) Отличается частично.
8. Критерий, которым можно пользоваться при оценке затрат на испытания программного обеспечения.
А) Затраты на испытания программного обеспечения должны быть на порядок
меньше затрат на его разработку, Б) Затраты на испытания программного обеспечения могут быть на порядок больше затрат на его разработку, В) Затраты на
испытания программного обеспечения должны сопоставимы с затратами на его
разработку, Г) Затраты на испытания программного обеспечения должны быть то
го же порядка, что и затраты на испытания средства измерения с целью утверждения типа.
9. Перечислите источники погрешности, вносимой программным обеспечением в результаты измерений.
10. К какому виду погрешности относится погрешность, вносимая программным обеспечением в суммарную погрешность средства измерений?
А) К случайной составляющей погрешности, Б) К методической составляющей и в
конечном итоге к неисключенной систематической погрешности, В) К инструментальной составляющей, Г) К погрешности неадекватности.
11. Каковы особенности представления дроби 0,1 в двоичной системе счисления?
А) Никаких особенностей нет, Б) Представление дроби 0,1 в двоичной системе
полностью совпадает с его представлением в десятичной системе, В) Представление является неопределенным с периодически повторяющимся сочетанием нулей и
единиц, Г) Представление является нумерологическим, с таким сочетанием нулей и
единиц, которое указывает на некую мистическую закономерность.
12. Сформулируйте принцип построения схемы Горнера.
19
13. Существуют ли проблемы с потерей точности при сложении (вычитании) больших чисел с десятичной дробью малой разрядности при переводе результата
сложения (вычитания) из двоичной системы в десятичную?
А) Точность вычисления теряется, Б) Точность не теряется, В) Точность теряется
не существенно, Г). Никаких проблем нет.
14. Можно ли пользоваться выражением для среднего квадратического отклонения
вида s  {
m
1
( xi2  mx 2 )}1 / 2 при его численной оценке?
m  1 i 1
А) Нельзя, Б) Можно всегда, В) Можно, проявляя определенную осторожность, поскольку при определенном наборе входных данных xi выражение под корнем в
написанной формуле может либо обращаться в нуль при принятой точности вычислений, либо становиться отрицательным, Г) Можно в зависимости от настроения.
15. Что такое устойчивый алгоритм?
16. Является ли программная поддержка данных измерений фактором риска?
А). Нет, не является, Б) Является, поскольку малые изменения данных, обусловленные, в первую очередь, их преобразованиями при использовании неустойчивых
алгоритмов обработки могут иметь самые серьезные последствия для результатов
измерений, В) Не является даже при использовании неустойчивых алгоритмов, Г)
Является даже при использовании устойчивых алгоритмов.
20
Глава 2. Нормативная база испытаний программного обеспечения средств измерений.
§ 2.1. Рекомендации международных организаций по стандартизации и метрологии.
Следует сразу сказать, что в настоящее время разработана обширная нормативная
база, относящаяся к самым разным аспектам ПО, используемого, в частности, в области
высоких технологий (high tech). Вместе с тем, как уже было отмечено выше, ПО СИ обладает рядом таких особенностей, которые отличают его от других видов ПО и требуют разработки нормативной базы, учитывающей эти особенности. Этим и обусловлено большое
внимание, которое уделяется этому вопросу со стороны международных организаций по
стандартизации и метрологии.
Существующая нормативная база, относящаяся к ПО средств измерений, представлена рядом международных рекомендаций, из которых необходимо выделить в первую
очередь руководства МОЗМ (Международной Организации Законодательной Метрологии) [13] и WELMEC [9, 14]. Напомним, что WELMEC (West European Legal Metrology
Cooperation) представляет собой региональную организацию МОЗМ, объединяющую
страны Европейского союза по взаимодействию в области законодательной метрологии. В
руководстве [13] значительное внимание уделено тестированию ПО при утверждении типа СИ, при этом оно по своему содержанию существенно перекрывается с руководством
WELMEC 7.2 [9]. По этой причине и ряду других значительное внимание в дальнейшем
будет уделено руководству WELMEC 7.2.
Иногда говорят, что перечисленные выше руководства ориентированы, прежде всего, на страны Европейского союза, мало подходят для российских условий и, в силу этого,
нам не указ. Это справедливо лишь в какой-то степени. Во-первых, руководство [9] написано таким образом, чтобы им можно было пользоваться с учетом национального законодательства в области обеспечения единства измерений и метрологии. Во-вторых, следует
помнить, что уровни технической и технологической культуры в странах Европейского
союза, а вместе с этим и производительность труда, несопоставимо, в разы, превосходят
соответствующие российские показатели, чтобы можно было пренебрегать соответствующими европейскими наработками. Кроме того, руководство WELMEC 7.2 представляет
собой настолько детально проработанный документ, что аналогов ему найти трудно, тем
более в отечественной нормативной базе.
Предшественником этого руководства было руководство WELMEC 7.1 [14]. Это
руководство носило, в основном, информационный характер, и продолжило дальнейшее
существование в виде Издания 2. Тем не менее, оно сыграло определенную роль в разра21
ботке и создании, в том числе, некоторых отечественных нормативных документов в области аттестации ПО.
Руководство WELMEC 7.1 акцентирует внимание на том, что нормирование только
метрологических характеристик СИ без должного внимания к ПО, используемому в них, в
настоящее время совершенно недостаточно, так как для большинства современных приборов, управляемых микропроцессорами, или приборов на базе универсальных компьютеров программное обеспечение и его целостность являются существенными факторами,
определяющими метрологические свойства и надежность этих приборов. В руководстве
введено понятие критичности ПО, как параметра, описывающего влияние ПО на метрологические характеристики СИ, хотя каких-либо количественных методов оценивания
этого параметра не предложено.
Согласно WELMEC 7.1 испытаниям (оценке) подлежит не все ПО, а только та
его часть, которая влияет на результаты измерений и на метрологические характеристики средств измерений. Это означает, что перед началом испытаний необходимо определиться с теми частями ПО, которые должны подвергаться испытаниям. К таким частям
могут быть отнесены, например, подпрограммы считывания необработанных результатов
измерений с датчиков, обработки и отображения результатов измерений, параметры,
определяющие тип СИ, и их конструктивные параметры, интегрированные в код программы.
Пример выделения так называемых метрологически значимых подпрограмм изображен на рисунке 1.
Несмотря на то, что выше уже было высказано отношение к метрологической аттестации ПО, в пособии будет использоваться термин «метрологически значимая» часть
ПО. Дело в том, что в западной литературе для этих целей используется термин «legally
relevant software», т.е. юридически значимое ПО, под которым понимается ПО, подлежащее контролю со стороны законодательной метрологии. С учетом особенностей отечественной нормативной базы было решено пользоваться понятием «метрологически значимая» часть ПО, которое, в первую очередь, подразумевает программы и программные
модули, выполняющие функции обработки, идентификации ПО и защиты ПО и измерительной информации, а также
параметры, характеризующие
тип средства измерений
и внесенные в программное обеспечение.
Руководство WELMEC 7.2. рассматривает процедуру выделения в ПО метрологически значимой части (software separation) как вид информационных технологий и формулирует требования, которым этот вид информационных технологий (IT) применительно
к ПО СИ должен удовлетворять.
22
Программы и подпрограммы обычно имеют домен данных, состоящий из всех переменных и констант, к которым программа или подпрограмма может обращаться для
Рисунок 1. Пример выделения метрологически значимой части ПО.
считывания или записи. Домен может принадлежать одной программе/подпрограмме и
никакая другая программа/подпрограмма не может ничего записывать в него или даже
считывать из него. Могут быть домены данных, используемые и другими частями программы, которые все имеют возможность считывать данные из домена или
записывать
их. На рисунке 2 показаны домены данных части программы (выше разделительной линии), подлежащей метрологическому контролю (т.е. метрологически значимая часть), и
другой домен с несколькими переменными, принадлежащими другим частям программы.
Рисунок 2. Пример типовой схемы потока данных ПО с законодательно
контролируемой частью.
Рисунки 1 и 2 взяты из русского перевода WELMEC 7.1
23
Разделение ПО на метрологически значимые и не значимые части приводит к
определенным преимуществам для разработчиков, пользователей и уполномоченных органов по сравнению со случаем, когда разделение не проведено. Если же такого разделения не проведено, то рекомендуется все ПО рассматривать как метрологически значимое.
Следует отметить, что как в руководствах WELMEC, так и в других международных рекомендациях отсутствуют требования к точностным характеристикам программных средств, в частности, требования к влиянию ПО на метрологические характеристики
средств измерений. Это и понятно, поскольку методы таких оценок в существенной степени зависят от конкретной измерительной задачи, от аппаратной и программной реализации ее решения. Тем не менее, несмотря на влияние конкретики, можно сформулировать
некие типовые подходы к решению этой проблемы. Некоторые из таких подходов будут
изложены во второй части пособия.
Руководство WELMEC 7.2 является чисто рекомендательным и не налагает какиелибо ограничения или дополнительные технические требования сверх тех, которые приняты в Европейском союзе. Руководство содержит пояснения специфических терминов и
определений, используемых в области IT, и не очень хорошо известных специалистам, занимающимся традиционной метрологической деятельностью. Определенное внимание
при этом уделено пояснению терминов, используемых при криптографической защите
измерительной информации (алгоритмы хэширования, контрольные суммы, электронные
подписи и т.п.).
Руководство организовано как структурированный набор блоков требований, классификация которых основана на базовых конфигурациях СИ и IT конфигурациях.
Руководство рассматривает две основные базовые конфигурации СИ: СИ, предназначенные для решения частных измерительных задач (тип Р) и СИ, основанные на использовании персональных компьютеров (тип U). Иногда СИ первого типа называют
средствами измерений со встроенным программным обеспечением, а второго типа – СИ с
автономным ПО. Указанный набор требований дополняется специальными требованиями
к СИ. Следовательно, имеется три типа наборов требований:
1. требования для двух основных конфигураций СИ,
2. требования для четырех IT конфигураций (названных Приложениями L, T, S и
D (см. ниже)),
3. специальные требования к СИ (названные Приложениями I.1, I.2 и т.д.).
Первый тип требований применим ко всем СИ.
Второй тип требований имеет отношение к следующим функциям, предусмотренным информационными технологиями:
24
долговременное сохранение данных измерений (long term storage (L)),
передача данных измерений (transmission (T)),
программная загрузка (download (D)) и
программное разделение (separation (S)).
Каждый набор требований используется только в том случае, если соответствующая
функция существует.
Последний тип – набор дополнительных специальных требований к десяти видам
СИ. Иногда на этом основании утверждают, что руководство WELMEC 7.2 распространяется только на десть видов СИ. Это неверное утверждение. Руководство WELMEC 7.2
справедливо для программного обеспечения всех видов СИ, а набор специальных требований для десяти видов СИ введен только для подчеркивания специфики реализации и
использования ПО в таких СИ.
Отметим, что требования этого руководства различаются в соответствии с так
называемыми классами риска. Вводятся шесть классов риска, обозначаемые буквами от А
до F в направлении повышения риска. Низший класс риска А и высший класс F не рассматриваются. Они введены для возможного случая в будущем, когда они могут понадобиться. Остальные классы риска от B до E перекрывают все виды СИ, попадающие под
регулирование, принятое в Европейском союзе. Более того, они обеспечивают достаточное поле возможностей в случае изменения оценок риска. Классы риска определены в
главе 11 этого руководства, которая носит информационный характер. Для каждого СИ
должна быть произведена оценка класса риска, потому что конкретные требования к ПО
определяются, прежде всего, классом риска, присущим прибору. Представляет определенный интерес классификация классов риска, содержащаяся в обсуждаемом руководстве.
Классификация классов риска опирается на такие понятия как «уровень защиты,
проверки и соответствия». В руководстве имеются по этому поводу такие пояснения.
Уровни защиты программного обеспечения
Низкий:
Не требуется никаких средств защиты от намеренных изменений.
Средний:
Программное обеспечение защищено от намеренных изменений с
помощью легко доступных и простых программных средств (например, с помощью текстового редактора).
Высокий:
Программное обеспечение защищено от намеренных изменений с помощью
специальных программных средств (программы-отладчики и редакторы жесткого диска,
средства программной разработки и т.д.) или посредством опечатывания запоминающих
устройств.
25
Уровни проверки программного обеспечения
Низкий:
Исполняется обычный набор функциональных проверок средства измере-
ний. Никакого тестирования программного обеспечения сверх этого не требуется.
Средний:
В добавление к «низкому» уровню, программное обеспечение проверяется
на основе анализа документации. Документация включает в себя описание функций программного обеспечения, параметров и т.д. Практическая проверка программно поддерживаемых функций (выборочные проверки) может быть проверкой правильности документации и эффективности защиты измерений.
Высокий:
В добавление к «среднему» уровню осуществляется всестороннее тестиро-
вание программного обеспечения, в том числе на основе анализа исходного кода.
Уровни соответствия программного обеспечения
Низкий:
Функциональность программного обеспечения, исполняемая для каждого
конкретного средства измерений, находится в соответствии с утвержденной документацией.
Средний:
В добавление к «низкому» уровню соответствия, зависящему от техниче-
ских особенностей, часть программного обеспечения должна быть определена как зафиксированная при утверждении типа, т.е. как неизменяемая без утверждения уполномоченным органом. Неизменяемая часть должна быть одинаковой для всех конкретных средств
измерений одного типа.
Высокий:
Исполнение программного обеспечения в конкретных средствах измерений
полностью идентично тому, которое было зафиксировано при утверждении типа.
На основе сформулированных критериев предлагается следующая классификация
классов риска:
Риск класса A:
Это наименьший класс риска из всех. Никаких конкретных мер не
требуется против намеренных изменений программного обеспечения. Проверка программного обеспечения является частью функционального тестирования прибора. Установление соответствия требуется на уровне документации. Не ожидается, что какие-то
средства измерений будут классифицироваться с риском класса А. Однако, введением такого класса соответствующая вероятность предусматривается.
Риск класса В:
По сравнению с риском класса А требуется «средний» уровень защи-
ты программного обеспечения. Соответственно, уровень проверки должен быть повышен
26
к «среднему» уровню. Соответствие остается неизменным по сравнению с риском класса
А.
Риск класса С:
По сравнению с риском класса В, уровень соответствия повышается к
«среднему». Это означает, что часть программного обеспечения может быть декларирована как неизменяемая при утверждении типа. Для остальной части программного обеспечения соответствие требуется только на функциональном уровне. Уровни защиты и проверки остаются неизменными, как и при риске класса В.
Риск класса D:
Существенное отличие по сравнению с риском класса С заключается
в повышении уровня защиты до «высокого». Уровень проверки остается неизменным на
«среднем» уровне. Существенно то, что документация должна показать достаточность и
пригодность предпринятых меры защиты. Уровень соответствия остается неизменным,
как и при риске класса С.
Риск класса Е:
По сравнению с риском класса D уровень проверки повышается до
«высокого». Уровни защиты и соответствия остаются неизменными.
Риск класса F:
Уровни по отношению ко всем аспектам (защита, проверка и соответ-
ствие) назначаются «высокими». Как и в случае риска класса А, не ожидается, что какоенибудь средство измерений будет классифицироваться с риском класса F. Однако, введением такого класса соответствующая вероятность предусматривается.
Согласно руководству проблема назначения классов рисков, сопровождающих используемое ПО, является прерогативой соответствующих рабочих групп WELMEC. Так,
согласно решению рабочей группы 11 WELMEC, для счетчиков количества теплоты, контролируемых ПО в соответствии с требованиями на основе руководства WELMEC 7.2,
устанавливается риск класса С для СИ типа Р.
Схематическое представление типового блока требований к ПО, сформулированных в руководстве WELMEC 7.2, показано в таблице 1.
Каждый блок требований содержит отчетливо выраженное требование. Блок состоит из текста, поясняющего определения и разъясняющего специальные примечания из
предусмотренной документации, из руководства по подтверждению и примеров приемлемых решений (если они имеются). Содержимое блока требований может подразделяться в
соответствии с классами риска.
Блок адресован как изготовителю, так и уполномоченным органам (организациям)
с двумя целями: (1) чтобы рассматривать это требование как минимальное условие, и (2)
не налагать какие-то дополнительные требования.
27
Название требования
Главное содержание требования (возможно различающееся в соответствии с классами
риска)
Специальные примечания (область применения, дополнительные пояснения, исключительные случаи и т.п.)
Предусмотренная документация (возможно различающаяся в соответствии с классами
риска)
Руководство по подтвержде- Руководство по подтвержде- …
нию для одного класса риска
нию для другого класса риска
Пример приемлемых реше- Пример приемлемых реше- …
ний для одного класса риска
ний для другого класса риска
Таблица 1. Структура блока требований.
Следует обратить внимание на следующие обстоятельства.
1. В обсуждаемом руководстве значительное внимание уделено требованиям к встроенному ПО, используемому в СИ типа Р. Вместе с тем, не ясно, как можно проконтролировать реализацию этих требований, поскольку доступ к ПО в большинстве
случаев невозможен.
2. Как уже отмечалось, в тексте требований присутствуют понятия, относящиеся к
криптографическим методам защиты (контрольная сумма, алгоритм электронной
подписи CRC-32, номер ТАС (сертификата об утверждении типа) и т.п.). Некоторые из этих терминов, поясняются в руководстве, некоторые, к сожалению, остаются понятными только узкому кругу специалистов по криптографическим методам защиты информации.
3. Основную ценность, прежде всего для разработчиков ПО и уполномоченных органов, представляют содержащиеся в каждом блоке примеры приемлемых решений
для удовлетворения конкретных требований к ПО.
4. Дополнения для риска класса Е содержат требования к исходному коду программы. Эта особенность в нормативных документах по метрологии встречается впервые. До сих пор под предлогом сохранения авторских прав этот вопрос оставался
за пределами рассмотрения. Как показывает практика тестирования ряда программных продуктов, в ряде случаев делать какие-то определенные заключения о
качестве ПО можно только на основе анализа исходного кода или его фрагментов.
Разумеется, это делается только с согласия разработчиков ПО, при этом в необходимых случаях заключается дополнительное соглашение о соблюдении конфиденциальности при тестировании ПО.
28
В Приложении к руководству приведен пример испытания программного обеспечения расходомера Dynaflow. В принципе, этим примером, как и всем руководством
WELMEC 7.2, можно пользоваться для испытаний как аналогичного ПО, так и других
программных продуктов, но при этом не следует забывать, что в конечном итоге в описании типа СИ должны быть отражены характеристики и параметры ПО, предусмотренные
приказом Минпромторга РФ от 30 ноября 2009 г. № 1081 [2].
Требования к ПО, которые соотносятся с приведенными выше, содержатся также и
в ГОСТ Р ИСО/МЭК 17025-2006 [15]. Для подтверждения этого приведем ряд положений
этого документа.
«5.4.7.2. Если используются компьютеры или автоматизированное оборудование для сбора, обработки, регистрации, отчетности, хранения или поиска данных испытаний и калибровок, лаборатория должна удостовериться, что:
a) разработанное пользователем компьютерное ПО достаточно подробно задокументировано и должным образом оценено как пригодное для применения;
b) разработаны и внедрены процедуры защиты данных; эти процедуры должны
включать, но не ограничиваться этим, целостность и конфиденциальность ввода
или сбора данных, хранения данных, передачи данных и обработки данных;
c) для обеспечения должного функционирования обеспечивается технический уход
за компьютером и автоматизированным оборудованием, и для них должны быть
созданы условия окружающей среды и работы, необходимые для поддержания
точности данных испытаний и калибровок.
5.5.2. Оборудование и его программное обеспечение, используемые для проведения испытаний, калибровки и отбора образцов, должны обеспечивать требуемую точность и соответствовать техническим требованиям, предъявляемым к испытательным и/или калибровочным работам.
5.5.4. Каждая единица оборудования и ее программное обеспечение, используемые при
проведении испытаний и/или калибровок и оказывающие влияние на результат, должны
быть, если это практически осуществимо, однозначно идентифицируемы.
5.5.12. Регулировка испытательного и калибровочного оборудования, включая аппаратные
средства и ПО, которые могут сделать недействительными результаты испытаний и/или
калибровок, должна быть исключена».
Требования к ПО СИ содержатся также в рекомендации КООМЕТ R/LM/10:2004
[16] и в ряде других международных документов и рекомендаций.
29
§ 2.2. Отечественная нормативная база испытаний программного обеспечения
средств измерений.
Отечественная нормативная база, относящаяся к ПО СИ, представлена национальными стандартами ГОСТ Р 8.654-2015 «ГСИ. Требования к программному обеспечению
средств измерений. Основные положения» [5], ГОСТ Р 8.883-2015 «ГСИ. Программное
обеспечение средств измерений. Алгоритмы обработки, хранения, защиты и передачи измерительной информации. Методы испытаний», ГОСТ Р 8.596-2002 «ГСИ. Метрологическое обеспечение измерительных систем. Основные положения» [17] и рекомендациями
Росстандарта Р 50.2.077-2014 «ГСИ. Испытания средств измерений в целях утверждения
типа. Проверка защиты программного обеспечения» [4]. Кроме того, имеются методики
институтов МИ 2174-91 «ГСИ. Аттестация алгоритмов и программ обработки данных при
измерениях. Основные положения» [18], МИ 2955-2016 «ГСИ. Типовая методика проведения испытаний программного обеспечения средств измерений» [19], а также методики
МИ 2517-99 и МИ 2518-99 [20, 21] и ряд других.
В Указателе нормативных документов в области метрологии можно найти ссылки
на частные методики поверки компьютеров или вычислительных комплексов, применяемых для использования в конкретных измерительных задачах, например, МИ 2454-98
«ГСИ. Вычислитель модели SENTINEL-500 фирмы SPECTRA-TEK. Методика поверки».
Наконец, имеется ряд отраслевых нормативных документов, определяющих порядок проведения испытаний программного обеспечения, используемого в отрасли (Минобороны,
Росатом, Газпром, Роснефть, РЖД и т.п.).
Следует отметить, что ГОСТ Р 8.596 -2002 содержит прямое указание на необходимость аттестации (по терминологии ГОСТа) ПО, когда оно оказывает влияние на результаты и погрешность измерений. Пункт 7.4 этого документа гласит:
«Программы, реализуемые вычислительным компонентом, подлежат метрологической аттестации в соответствии с МИ 2174-91 (необходимо учесть, что на время разработки ГОСТ Р 8.596-2002, никаких других документов, регламентирующих оценивание
свойств и характеристик ПО, кроме МИ 2174, не было), если они влияют на результаты и
погрешности измерений, но при этом не использованы в процессе экспериментальной поверки измерительных каналов при испытаниях измерительных систем (ИС) или комплексного компонента, или если предусмотрена возможность модификации этих программ в процессе эксплуатации ИС. Программы должны быть защищены от несанкционированного доступа.
В любом случае техническая документация на ИС или комплексный компонент,
представляемая на испытания для целей утверждения типа, должна содержать описание
30
алгоритма обработки измерительной информации и идентифицирующие признаки реализующей его программы (номер версии, объем программы и т.п.). При модификации программы разработчиком или в процессе эксплуатации в той части, которая связана с обработкой измерительной информации, новая версия программы должна быть представлена
на метрологическую аттестацию (в современной терминологии, на испытания с целью
утверждения типа, или на сертификацию) в организацию, проводившую испытания ИС
(комплексного компонента) с целью утверждения типа».
Таким образом, ПО ИС в соответствии с этим ГОСТом подлежит аттестации (испытаниям), если оно влияет на результаты и погрешность измерений. К сожалению, убедиться в степени такого влияния можно только в процессе самой аттестации (испытаний).
Условие «но при этом не использованы в процессе экспериментальной поверки измерительных каналов при испытаниях измерительных систем» на практике приводило к тому,
что при испытаниях ИС до недавнего времени характеристики и свойства ПО не определялись и не документировались. При этом можно допустить, что именно в процессе экспериментальной проверки измерительных каналов могут возникнуть подозрения о влиянии ПО на метрологические характеристики СИ, и это может быть поводом для оценивания ПО в полном объеме. Обратим внимание также на то, что если при такой экспериментальной проверке ИС с участием программного обеспечения метрологические характеристики СИ остаются в пределах нормируемого допуска, то это является одним из указаний
на отсутствие влияния ПО на МХ СИ.
Основная идея, лежащая в основе МИ 2174-91, сводится к тому, что аттестацию ПО
предлагается проводить с использованием метода моделей исходных данных, который,
как показала практика испытаний, является действенным методом оценки свойств ПО.
Подробно этот метод будет рассмотрен во второй части пособия.
Особенность методик МИ 2517-99 и МИ 2518-99 заключается в том, что в этих методиках объектом аттестации являются только программы обработки данных. Методики
содержат требования к перечню и форме документации, представляемой для аттестации
ПО, а также требования к содержанию программы метрологической аттестации ПО. В
приложениях содержатся рекомендуемые формы документов, сопровождающих процесс
аттестации ПО. Основным недостатком методик является то, что их рекомендации носят
общий характер и не сопровождаются рассмотрением примеров, поясняющих те или иные
утверждения, непосредственно относящиеся к процедуре аттестации. Кроме того, в этих
методиках широко используется такие термины, как «метрологическая аттестация ПО» и
«метрологические характеристики аттестуемого ПО», относительно которых комментарии
уже были сделаны.
31
Выше говорилось, что испытания ПО СИ должны проводиться при испытаниях СИ
в целях утверждения типа и при его сертификации. Примером системы сертификации
может служить, предусмотренная Законом РФ «О техническом регулировании» система
добровольной сертификации программного обеспечения средств измерений (СДС ПО
СИ), созданная в ФГУП «ВНИИМС» (регистрационный номер в Реестре систем сертификации РОСС RU.B1018.04ЖЗУ0 от 8 февраля 2013 г.), в рамках которой сертифицировано
десятки программных продуктов, используемых в разных областях измерительной техники.
Контрольные вопросы к Главе 2.
1. Перечислите отечественные нормативные документы, регламентирующие требования к ПО СИ и порядок проведения их испытаний.
2. Что имеется в виду, когда говорят о метрологически значимой части программного
обеспечения?
А) Имеется в виду подпрограмма обработки измерительной информации, Б) Часть
программного обеспечения, отвечающая за реализацию его основных функций, В)
Часть программного обеспечения, отвечающая за реализацию представления результатов обработки измерительной информации, Г) Часть программного обеспечения, которая может оказывать влияние на метрологические характеристики программного обеспечения, а также отвечает за его идентификацию и защиту.
3. Могут ли средства измерений относиться одновременно как к типу Р, так и к типу
D по WELMEC 7.2?
А) Нет, не могут, Б) Могут. Примером этому являются Автоматизированные Системы Коммерческого Учета Электроэнергии (АСКУЭ), где программное обеспечение автоматизированных электрических счетчиков является встроенным (т.е.
счетчики относятся к средствам измерений типа Р) в то время как программное
обеспечение системы функционирует на базе универсальных компьютеров, т.е. является автономным (тип D), В) По желанию разработчиков такие системы не относят к средствам измерений, Г) Разработчики настаивают на испытаниях таких систем для целей утверждения типа и внесения их на этом основании в Государственный реестр средств измерений.
4. В каких случаях может возникнуть необходимость в долговременном сохранении
данных измерений?
А) По техническим причинам нет возможности произвести немедленную обработку данных измерений, Б) Такая необходимость не возникает никогда, В) Данные
32
измерений откладываются про запас, на черный день, Г) Астрологи не рекомендуют производить обработку измерительной информации.
5. С какой целью проводится выделение метрологически значимой части программного обеспечения?
А) Когда разработчикам просто так из-за любви к искусству захочется провести такое разделение, Б) Для того, чтобы проверять не все программное обеспечение
вместе,
например,
с программным
обеспечением
дисководов
и
дисплеев, а только ту его часть, которая может оказывать влияние на метрологические характеристики
средства измерений, В) Как и случае встроенного про-
граммного обеспечения выделение не производится никогда, Г) Для того, чтобы
испортить жизнь разработчикам программного обеспечения.
6. Какова
структура
идентификационных
данных
программного
обеспечения
средства измерений типа Р по WELMEC 7.2?
А) Никаких идентификационных данных для программного обеспечения не
нужно, Б) Можно ограничиться только названием программного продукта и указанием его номера версии, В) Написать идентификационные данные так, как бог
на душу положит, Г) Идентификация метрологически значимого программного
обеспечения содержит две части. В первой части (А) происходит изменение
идентификации,
если измененное программное обеспечение требует ново-
го утверждения. Часть (В)
показывает только незначительные изменения
в программном обеспечении, например, исправление
требуют нового утверждения. Первая часть (А)
из
промахов, которые
идентификации
не
состоит
автоматически сгенерированной контрольной суммы (например, с
помо-
щью алгоритма CRC-32 или MD5), полученной на основе метрологически значимого
программного
обеспечения, которое
объявляется
неизменным
при
утверждении типа. В другую часть метрологически значимого программного
обеспечения (А) может входить номер версии или номер свидетельства об утверждении типа.
7. Кто должен учитывать, в первую очередь, требования WELMEC 7.2 и требования отечественных нормативных документов к программному обеспечению
средств измерений?
А). Разработчики и испытатели автоматизированных средств измерений, а также представители уполномоченных организаций, Б) Хакеры, специализирующиеся на взломе измерительных систем, В) Владельцы дачных участков, фальси33
фицирующие показания счетчиков электрической энергии, Г) Продавцы средств
измерений.
8. Каковы требования к структуре программного обеспечения средств измерений?
А) Структура программного обеспечения может быть произвольной, Б) Метрологически значимое программное обеспечение разрабатывается таким образом,
чтобы на него невозможно было оказать искажающее воздействие через интерфейсы пользователя и другие интерфейсы, при этом обмен данными между
метрологически значимыми и не значимыми частями программного обеспечения необходимо проводить через защищенный интерфейс, В) Наличие защищенного интерфейса связи не обязательно, Г) Должен быть защищенный интерфейс связи, а наличие защищенного интерфейса между метрологически значимыми и незначимыми частями программного обеспечения не обязательно.
9. Чем характеризуется уровень «средний» защиты программного обеспечения по
ГОСТ Р 8.883-2015?
А) Метрологически значимая часть ПО СИ и измеренные данные достаточно
защищены с помощью специальных средств защиты от преднамеренных изменений, Б) Программное обеспечение никак не защищено, В) Запоминающее
устройство
защищается опечатыванием, Г) Для защиты используется програм-
ма-отладчик.
34
Глава 3. Основные требования, предъявляемые к программному обеспечению
средств измерений.
В этой главе сосредоточимся на рассмотрении требований к ПО, обусловленных
его особенностями и представленных в национальном стандарте [5] и в других нормативных документах.
Разработка документов, содержащих требования к ПО, необходима из-за того, что
любые испытания, по сути, сводятся к проверке соответствия испытываемого объекта
определенным требованиям, которые должны быть предварительно сформулированы.
При разработке стандарта были, конечно, учтены рекомендации руководств WELMEC. Более того, содержательная часть стандарта в существенной степени следует этим
руководствам, однако, стандарт в значительной степени избирателен по отношению к
ним.
Внимательный анализ руководства WELMEC 7.2 показал, что требования, как к
встроенному, так и к автономному ПО, по сути, не отличаются друг от друга. Поэтому
было решено не делить СИ на два типа (P и U), как это сделано в руководстве WELMEC
7.2. Было также решено отказаться от использования понятия «класс риска» по отношению к программному обеспечению. Несмотря на наличие определенных критериев отнесения ПО к тому или иному классу риска, о которых было сказано выше, окончательное
решение по этому вопросу выносится рабочей группой и поэтому в определенной степени
является субъективным. По мнению разработчиков ГОСТа, уровень требований к ПО зависит от свойств конкретного программного продукта и должен определяться в ходе испытаний в зависимости от уровня значимости (важности) предполагаемого использования, поэтому в стандарте имеет смысл формулировка только основных требований.
Стандарт устанавливает требования к ПО СИ, обусловленные необходимостью его
идентификации, оценки влияния ПО на метрологические характеристики СИ и защиты
обрабатываемой, в том числе измерительной, информации от непреднамеренных и преднамеренных изменений.
Стандарт распространяется на:
ПО СИ, в том числе измерительных и информационно-измерительных систем;
ПО автоматизированных систем, функционирующих с использованием СИ или компонентов измерительных систем;
ПО контролеров и вычислительных блоков, не входящих в состав измерительных систем,
а также технических систем и устройств с измерительными функциями, осуществляющих
обработку и представление измерительной информации.
35
Стандарт устанавливает, что ПО СИ, в том числе измерительных и информационно-измерительных систем, а также технических систем и устройств с измерительными
функциями должно соответствовать наборам общих и специальных требований.
Общие требования к ПО СИ включают в себя требования:
к документации;
к структуре ПО;
к влиянию ПО на метрологические характеристики СИ;
к защите ПО и данных.
Специальные требования к ПО СИ включают в себя:
требования к разделению ПО и его идентификации;
специальные требования к ПО, обусловленные использованием информационных технологий, о которых говорилось выше при обсуждении руководства WELMEC 7.2.
В общих чертах эти требования сводятся к следующему.
1. Требования к документации.
ПО следует сопровождать документацией, соответствующей, в первую очередь,
требованиям международных рекомендаций, стандарта [5] и других нормативных документов, относящихся к программной документации. Здесь необходимо упомянуть об
Единой системе программной документации (ЕСПД) – системе из 19 стандартов, разработанных, в основном, в 70 – 90 х годах прошлого века. По мнению многих эта система
устарела, некоторые особенности современных требований в ней не отражены, а некоторые требования избыточны. Названия отдельных стандартов ЕСПД представлены в ссылке [22]. К сожалению, при всем бурном развитии информационных технологий, альтернативы ЕСПД до сих пор не разработано, и иногда приходится пользоваться нормами и рекомендациями, сформулированными в ЕСПД.
В стандарте [5] перечислен примерный перечень документов, которые необходимо
представлять на испытания ПО, при этом следует помнить, что документация должна
полно и однозначно описывать назначение, основные функции, структуру, параметры и
характеристики ПО. Перечень и содержание документов, сопровождающих ПО при его
испытаниях, могут уточняться и корректироваться по согласованию между Заявителем и
Исполнителем испытаний.
2. Требования к разделению программного обеспечения и его идентификации.
Для СИ, применяемых в сфере государственного регулирования, на этапе разработки рекомендуется выделять метрологически значимую часть ПО.
36
После испытаний СИ с целью утверждения типа метрологически значимое ПО не
должно изменяться. Для каждого конкретного экземпляра СИ должно использоваться
ПО, идентичное утвержденному.
Для проверки соответствия ПО СИ тому, которое было зафиксировано (документировано) при испытаниях с целью утверждения типа СИ, а также для подтверждения его
целостности и подлинности осуществляется идентификация ПО. Для получения идентификационных данных (признаков) рекомендуется обеспечить уполномоченным органам
(организациям) возможность доступа к исполняемому коду метрологически значимой части ПО.
3. Требования к структуре программного обеспечения.
Метрологически значимое ПО разрабатывается таким образом, чтобы на него невозможно было оказать искажающее воздействие через интерфейсы пользователя и другие интерфейсы. Обмен данными между метрологически значимыми и не значимыми частями ПО необходимо проводить через защищенный интерфейс, который охватывает как
все взаимодействия между этими частями ПО, так и прохождение данных.
4. Требования к влиянию ПО на метрологические характеристики СИ.
Влияние ПО на метрологические характеристики СИ должно быть оценено. Некоторые особенности получения такой оценки уже обсуждались, другие особенности будут
обсуждаться далее. При этом необходимо отметить, что выполнение этого пункта требований к ПО встречает серьезные трудности из-за сложности и многофакторности решаемой задачи. Тем не менее, в этой области существует ряд наработок, выполненных как
отечественными, так и зарубежными метрологическими учреждениями, которые частично
обобщены в национальном стандарте [6].
5. Требования к защите программного обеспечения и данных.
ПО СИ должно содержать средства обнаружения, обозначения и/или устранения
сбоев (функциональных дефектов) и искажений, которые нарушают целостность программного обеспечения и данных.
Метрологически значимое ПО СИ и данные должны быть защищены от случайных
или непреднамеренных изменений.
Метрологически значимое ПО СИ и данные должны быть защищены от несанкционированной модификации.
6. Специальные требования к программному обеспечению.
ПО СИ в случае использования в них таких информационных технологий как загрузка, долговременное сохранение, передача и разделение должно удовлетворять требованиям международных рекомендаций [9] и стандарта [5].
37
В заключение этой части пособия следует сказать, что важнейшей задачей уполномоченных органов является надзор за исполнением нормативных требований к ПО СИ.
Некоторые методы реализации такого надзора будут рассмотрены в Части 2 пособия.
Ввиду чрезвычайного многообразия средств измерений, использующих ПО, не представляется возможным разработать такую рекомендацию по его испытаниям, которая была бы
пригодной на все случаи жизни. Речь может идти только о типовом подходе, предусматривающим применение определенной методологии испытаний ПО, используемого в СИ.
Следует помнить, что испытания ПО СИ - это творческий процесс, который требует достаточно высокого уровня квалификации от всех участников этого вида метрологической
деятельности.
Контрольные вопросы к Главе 3.
1. Какова структура требований к ПО СИ?
2. Перечислите требования к документации ПО СИ?
3. Какими нормативными документами регламентируются требования к ПО?
4. Какие виды информационных технологий могут использоваться в ПО СИ?
5. Какие требования предъявляются к ПО и устройствам передачи измерительной
информации?
6. Какие требования предъявляются к ПО при его модернизации и загрузке?
7. Следствием каких особенностей ПО СИ являются требования, предъявляемые к
нему?
38
Часть 2. ТИПОВЫЕ МЕТОДЫ ИСПЫТАНИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
СРЕДСТВ ИЗМЕРЕНИЙ
Глава 4. Методы испытаний и показатели качества программного обеспечения
средств измерений.
§ 4.1. Методы испытаний программного обеспечения средств измерений и их особенности.
Технологически различают испытания программ по методу «черного ящика» (black
box) и методу «белого ящика» (white box или walk through method). Опыт испытаний (сертификации) ПО, вместе с опытом, накопленным зарубежными метрологическими организациями (NPL, NIST, PTB), показывает, что в большинстве метрологических приложений
метод «черного ящика» характеризуется относительной простотой, дешевизной и достаточной глубиной испытаний, что хорошо соотносится с требованием минимизации усилий
по испытаниям ПО.
Метод «белого ящика», когда проводится проверка исходного кода и детальное исследование программных функций, как правило, используется при испытаниях очень
сложных измерительных систем, когда к этим системам предъявляются повышенные требования по безопасности и надежности их функционирования, или, когда возникают серьезные сомнения в правильности функционирования ПО.
Из определения программного обеспечения СИ следует, что испытания ПО должны
сводиться как к оценке свойств и характеристик программы в целом, так и к аналогичному
процессу по отношению к составляющим программу алгоритмам. Иногда трудно разделить факторы, влияющие на окончательный результат обработки измерительной информации, которые могут и не иметь прямого отношения к программному обеспечению, и
факторы, относящиеся к влиянию алгоритмов или программы. Все зависит от того,
например, насколько детально прописаны алгоритмы обработки данных. При оценивании
влияния ПО на метрологические характеристики СИ, программное обеспечение часто выступает как «полупрозрачный» («серый») ящик, где «прозрачная» часть – это описание
алгоритма обработки данных, а «непроницаемая» часть («черный ящик») – это способ реализации такого алгоритма в ПО.
В пособии в дальнейшем речь, в основном, будет идти о методе «черного ящика»
применительно к испытаниям ПО СИ.
39
В общем случае при исследовании какого-то объекта методом «черного ящика»,
этот объект подвергается вполне определенному и известному набору воздействий, и по
его реакции на эти воздействия делаются заключения о некоторых его свойствах.
Если обратиться, например, к методике МИ 2174-91, то в этой методике речь идет
об испытаниях ПО разновидностью метода «черного ящика», при этом свойства ПО оцениваются на основе его реакции на воздействия, вызванные различными моделями исходных данных.
В ряде случаев предлагается использовать другую разновидность метода испытаний, когда происходит сопоставление результатов испытаний с результатами, полученными с помощью опорного («эталонного») программного обеспечения (программного продукта (ПП)).
Термин «опорное программное обеспечение» встречает определенное неприятие со
стороны представителей уполномоченных органов, привыкших работать в рамках существовавшей ранее нормативной базы. Положение осложняется также и тем, что в настоящее время отсутствует согласованная и документированная процедура утверждения ПП в
качестве опорного. В такой ситуации следует поступать по аналогии с тем, как обходятся
с понятием «принятого опорного значения».
Согласно ГОСТ Р ИСО 5725-1 – 2002 [23] под принятым опорным значением понимается значение, которое служит в качестве согласованного для сравнения и получено
как:
а) теоретическое или установленное значение, базирующееся на научных принципах;
b) приписанное или аттестованное значение, базирующееся на экспериментальных работах какой-либо национальной или международной организации;
с) согласованное или аттестованное значение, базирующееся на совместных экспериментальных работах под руководством научной или инженерной группы…
В принципе, из приведенного изъятия из указанного ГОСТа понятно, о чем идет
речь. Поэтому по аналогии с понятием «принятого опорного значения» в ГОСТ Р 8.8832015 под опорным программным обеспечением (программным продуктом) понимается
программное обеспечение, используемое для сравнения с испытываемыми программными
продуктами и отвечающее повышенным требованиям к его вычислительным и функциональным характеристикам, подтвержденным (в ряде случаев независимыми методами)
при его неоднократных испытаниях и применении.
Что касается документированного утверждения конкретного ПП в качестве опорного, то такую процедуру из-за особенностей ПО трудно себе представить, и по этой причине, как бы ни возражали по этому поводу представители государственных метрологиче40
ских служб и метрологического надзора, в настоящее время разумная процедура такого
утверждения сводится к совместному решению Заказчика и Исполнителя испытаний об
отнесении конкретного ПП к опорному. Говорят, что при этом возможен сговор между
участниками испытаний, когда в качестве опорного ПО может быть использован программный продукт, на самом деле таким не являющийся. В принципе, такой сговор возможен всегда, какими бы сдерживающими и контрольными процедурами не обкладывались участники испытаний. Правильнее в этой ситуации было бы исходить из того, что
стороны, принимающие участие в испытаниях, являются добросовестными участниками
этого процесса и заинтересованы в определении действительных характеристик и свойств
программного обеспечения. В тех же случаях, когда возникают сомнения в результатах
испытаний, для представителей уполномоченных органов должен быть обеспечен доступ
к протоколам испытаний и к другим необходимым документам.
Из сказанного следует, что критерии отнесения программного продукта к опорному в настоящее время условны и в значительной степени носят субъективный характер. В
принципе, это нормальная ситуация, поскольку практически невозможно сформулировать
такие критерии, которые были бы пригодны на все случаи жизни, например, такие, как
модернизация ПО или разработка его новых версий. В каждом случае эта проблема должна решаться с учетом измерительной и функциональной конкретики. Так, например, в работе [24] приведен пример программного продукта, который, по мнению автора, обладает
всеми свойствами опорной программы. Речь идет о решении уравнения переноса тепловой
радиации в неоднородной стратифицированной атмосфере методом Монте-Карло с прямым интегрированием при относительных погрешностях порядка 0,1 % и сокращении
времени вычислений по сравнению с известными алгоритмами в 3 – 5 раз. С другой стороны, в работе [25] в качестве опорной программы предлагается использовать программу
обработки хроматографической информации «МультиХром». Эта программа уже давно
используется при обработке хроматографических данных, постоянно совершенствуется и
пользуется высокой степенью доверия среди специалистов. Общим в приведенных примерах должно быть то, что для конкретного опорного программного продукта должна быть
уверенность в том, как это записано в его определении, что он отвечает повышенным требованиям к его вычислительным и функциональным характеристикам. Следует подчеркнуть, что использование термина «опорный» носит вынужденный характер. Дело в том,
что в иностранной литературе для такого ПО используется термин «reference software»,
что иногда переводится как «референтное или эталонное программное обеспечение». Такой перевод представляется неудачным, и было отдано предпочтение термину опорный.
При этом следует помнить, что программное обеспечение – это не средство измерений, и
41
опорное ПО не воспроизводит и не хранит никакую физическую величину. Под опорным
ПО понимается только то, что фигурирует в приведенном выше определении.
Необходимо отметить, что при наличии опорного программного обеспечения проблема испытаний ПО СИ в части оценки его вычислительных возможностей практически
решается полностью. Использование опорного ПО для испытаний конкретных программных продуктов, будет рассмотрено ниже.
Ситуация усложняется, когда опорное программное обеспечение отсутствует или
доступ к нему затруднен. В этом случае могут использоваться разные подходы к испытаниям ПО СИ. Как уже отмечалось, методика [18], например, предлагает использовать модели исходных данных.
Иной подход к испытаниям ПО предложен в работе [11]. Он сводится к получению
и использованию наборов опорных данных (reference data) и опорных (модельных) результатов (reference results) для испытаний программного обеспечения методом «черного
ящика». Этот подход позволяет при априори известном модельном решении измерительной задачи генерировать, имитируя эксперимент, опорные данные (reference data) в соответствии с особенностями задачи, решаемой ПО. Результаты, полученные испытываемым
ПО при воздействии на него опорными данными (test results), сравниваются с модельными
результатами, которые должны быть априори известны, по ряду количественных характеристик ПО и делаются окончательные заключения о его свойствах. Таков, в общих чертах,
подход к испытаниям ПО, предлагаемый NPL.
Таким образом, испытания ПО могут быть осуществлены, по меньшей мере, двумя
способами:
1. Наборами данных воздействуют на опорное и на испытываемое ПО для того,
чтобы получить соответствующие опорные результаты для сравнения с ними
результатов, полученных испытываемым ПО;
2. Опорными (модельными) результатами воздействуют на специальную программу (генератор данных), чтобы получить соответствующий набор опорных
данных, используемых далее для испытаний ПО.
Эти способы схематично изображены на рисунках 3 и 5. На первом рисунке входом
испытательной процедуры является набор опорных данных (reference data set), на втором –
вход реализуется в форме опорных (модельных) результатов (reference results).
Первый способ подобен калибровке СИ и предполагает использование опорного
программного обеспечения, о котором говорилось выше. Можно сказать, что при испытаниях программных продуктов функции опорного ПО аналогичны функциям эталона такой, например, физической величины, как длина, т.е. эталону метра, с которым в процессе
42
калибровки происходит сравнение вторичных эталонов и рабочих СИ. Известно, однако,
что разработка опорного ПО для сложных измерительных задач является серьезной проблемой, требующей для своего решения значительных усилий.
Рисунок 3. Схема испытаний с использованием опорного ПО.
Альтернативой этому способу, как уже отмечалось, является метод генерации
опорных данных. Этот метод может быть использован наряду с моделями исходных данных, который рекомендуется методикой [18] (рисунок 4). Вместе с тем, он обладает той
особенностью, что с его помощью можно добиться максимального соответствия испытываемого ПО рабочим условиям его использования. На самом деле можно утверждать, что
оба метода является разновидностями одного и того же подхода к тестированию ПО, при
этом метод генерации в определенных условиях обладает более строгим математическим
обоснованием. С другой стороны, метод моделей исходных данных позволяет библиотечными программными средствами получать те же самые результаты, но более простым путем.
Для измерительных задач с единственным модельным решением имеется единственный набор опорных результатов, соответствующий данному набору опорных данных
(reference data set) (рисунок 3). В противоположность этому для заданного опорного (модельного) результата (reference results) (рисунок 5) имеется в общем случае неопределенное число соответствующих наборов данных. Например, фиксированная выборка случайных чисел характеризуется единственным СКО, в то время как заданному СКО может отвечать неограниченно большое число наборов случайных чисел. Это свойство может
быть использовано как некая особенность метода генерации данных, поскольку она
43
Source data
Test software
Test results
Comparison
Рисунок 4. Схема испытаний методом моделей исходных данных.
позволяет вести отбор этих данных по степени их соответствия данным, реализуемым
при конкретных измерениях.
Рисунок 5. Схема испытаний с использованием генерации данных.
Для генерации семейств или классов данных в работе [11] предлагается использовать метод «нуль - пространства», который будет рассмотрен ниже на примере задачи линейной регрессии. Будут рассмотрены также методы, которые ранее не упоминались.
44
§ 4.2. Характеристики программного обеспечения и исполнительные параметры.
Для оценки программных продуктов полезно использовать их показатели качества
(quality metrics). Характеризуя ПО в терминах показателей качества, можно произвести
его объективную оценку, иногда даже количественную.
Оценке качества программных продуктов, особенно тех, которые применяются при
производстве промышленной продукции, уделяется самое серьезное внимание. Имеется
ряд нормативных документов, определяющих показатели качества ПО и методы их определения. В качестве примера можно привести стандарты [26] и [27]. Здесь нет необходимости подробно излагать содержание этих документов. Отметим только, что в этих стандартах устанавливаются методы обоснования базовых (требуемых) значений показателей
качества ПО применительно, например, к таким показателям (характеристикам) качества
как надежность, практичность, эффективность, сопровождаемость, мобильность, безопасность. Предлагается классифицировать методы определения этих показателей:
по способам получения (измерительный, регистрационный, органолептический, расчетный);
по источникам получения информации (традиционный, экспертный, социологический).
Качество ПО предлагается также определять путем сравнения полученных расчетных значений показателей с соответствующими базовыми значениями показателей существующего аналога или расчетного ПО, принимаемого за опорный («эталонный») образец.
В качестве аналогов выбираются реально существующее ПО того же функционального
назначения, что и испытываемое, с такими же основными параметрами, подобной структурой и применяемое в условиях эксплуатации.
Видно, что содержание упомянутых документов в значительной степени совпадает
с той методологией испытаний ПО СИ, которая излагалась в предыдущих параграфах.
Вместе с тем, следует иметь в виду, что проблема испытаний ПО СИ требует серьезного
обоснования тех методов испытаний, которые для других видов ПО уже достаточно хорошо разработаны и апробированы. Кроме того, ввиду специфики ПО СИ, о которой говорилось в самом начале пособия, не все показатели качества для него актуальны и применимы.
Если иметь ввиду все эти обстоятельства, то применительно к ПО СИ его показатели качества должны в первую очередь отражать отличие (отклонение) тестовых результатов от опорных. Эти отличия могут быть выражены в разных формах, в том числе:
45
1. в виде отличия между тестовыми и опорными результатами, т.е. как абсолютная
характеристика точности вычислений алгоритмами ПО;
2. в виде числа совпадающих цифр;
3. в виде исполнительной характеристики (performance measure), рассчитываемой
с учетом различных факторов, включая расчетную точность математики, используемой для вычисления тестовых и опорных результатов, и коэффициенты
устойчивости (обусловленности);
4. в виде относительного отличия вычислений, реализуемых алгоритмами тестируемого и опорного ПО.
Могут использоваться и другие показатели качества, такие как, например, требуемый объем памяти, время исполнения и т.п.
Предположим, что опорные и тестовые результаты выражаются в виде векторов.
Пусть при этом
y  y (test )  y ( ref ) ,
где
(6)
y (test ) и y (ref ) - векторы тестовых и опорных результатов, соответствующих опор-
ным данным x .
Обозначим через
d (x) 
y
n
(7)
абсолютное отклонение тестовых результатов от опорных для опорных данных x . При
этом y обозначает норму (длину) вектора y , n - число компонент вектора.
Под нормой вектора
a
понимают неотрицательное действительное число
a  (a  a ) . В скобках стоит скалярное произведение вектора a самого на себя. В частности, если вектор проведен из начала координат в точку с координатами ( a1 , a2 , a3 ), то
норма такого вектора может быть вычислена по формуле a  a12  a22  a32 .
Для скалярных величин или, когда имеют дело с одной компонентой вектора
d ( x )  y (test )  y ( ref ) .
(8)
Пусть d (x ) определяется формулами (7) или (8). Тогда число N (x ) совпадающих
цифр в результатах тестовых и опорных расчетов, соответствующих определенным опорным данным x , может быть рассчитано по формулам [11]:
46
если d ( x )  0
N ( x )  min{M ( x ), lg(1 
y ( ref )
n  d (x)
)},
(9)
если d ( x )  0,
N ( x )  M ( x ).
(10)
Здесь M (x ) - число точных значащих цифр в опорных результатах, соответствующих x . Тем самым принимается во внимание тот факт, что опорные результаты сами по
себе могут иметь ограниченную точность.
Исполнительная характеристика P(x ) , соответствующая опорным данным x ,
определяется соотношением [11]
P( x )  lg(1 
y
1
 (ref ) ).
k ( x ) y
(11)
Эта характеристика является показателем качества, характеризующим тестируемое
ПО, и определяется следующими факторами:
разницей y между тестовыми и опорными результатами;
коэффициентом устойчивости (обусловленности) проблемы k (x) (подробнее о коэффициенте устойчивости смотри в Приложении 1);
вычислительной точностью  .
Вычислительная точность  понимается как наименьшее положительное число u
такое, что значение 1  u , рассчитанное компьютером с использованием представления
чисел с плавающей запятой, становится больше единицы [11]. Для большинства компьютеров   2 52  2  1016.
Из определения N (x) и P(x) (см., формулы (9) и (11)) следует, что эти характеристики в определенном смысле являются дополнительными друг к другу. Как было отмечено выше, N (x) обозначает число совпадающих цифр в результатах, полученных испытываемым и опорным ПО. В частности, когда испытываемое ПО своими вычислительными возможностями не отличается от опорного, то результаты их численных расчетов на
принятом уровне точности совпадают (см. формулу (10)). В то же время P(x) отражает
число потерянных цифр точности, поскольку, когда вычислительные возможности испытываемого и опорного ПО одинаковы, то P( x)  0.
Исполнительная характеристика является более информативной величиной, характеризующей качество ПО, чем N (x) , и, как было сказано, она измеряет потерю значащих
47
цифр при вычислениях с использованием испытываемого программного продукта по
сравнению с опорными вычислениями [11].
Исполнительная характеристика вычисляется как функция так называемых исполнительных параметров (performance parameters). Исполнительные параметры могут включать как модельные параметры, так и параметры, описывающие, например, свойства
входного сигнала такие, как отношение сигнал/шум, или величины, контролирующие
число и распределение входных сигналов. При испытаниях вычислительные возможности
ПО исследуется в зависимости от значений исполнительного параметра, или параметров.
Тем самым в пространстве входных данных выделяются области, в пределах которых
функционирование ПО является адекватным, и области, в которых функционирование таковым не является.
При испытаниях, например, алгоритмов расчета выборочного СКО наборы опорных данных можно характеризовать, например, значениями следующих исполнительных
параметров:
выборочного среднего x ;
выборочного СКО s ;
числа m выборочных значений (объемом выборки).
Такой параметр как
x
, характеризующий устойчивость (обусловленность) задачи
s
вычисления СКО (см. Приложение 1), может быть использован для выделения наборов
опорных данных по степени риска получить неточное значение при вычислении СКО.
Для испытаний алгоритмов расчета по методу наименьших квадратов полиномиальных аппроксимаций измеренных данных {( xi , yi ) : i  1,..., m} наборы опорных данных
могут характеризоваться следующими исполнительными параметрами:
степенью n полинома;
СКО  погрешности измерений;
средним значением x измеренных значений, откладываемых на оси абсцисс;
числом m точек измерения.
По аналогии с поверкой (калибровкой) СИ соотношением
 ( x )  ( y (test )  y ( ref )
y ( ref )
) 100%
(12)
можно ввести в обращение и пользоваться такой количественной характеристикой алгоритма как относительное отличие полученного им численного значения от значения, рассчитанного алгоритмом опорного ПО.
48
Иногда приходиться сталкиваться с другим пониманием вычислительных возможностей ПО, а именно, как отличие результата измерения, полученного посредством СИ с
ПО, от результата, полученного тем же СИ без применения программного продукта. Такая
постановка вопроса лишена какого-либо смысла, поскольку в обычной метрологической
практике подавляющее большинство результатов измерений получается косвенными,
совместными или совокупными методами в рамках методик измерений, когда результаты
измерений вычисляются с использованием тех или иных формул и алгоритмов на основании результатов прямых измерений. Это означает, что реально в большинстве случаев
приходится использовать возможности вычислительной техники независимо от того, в
каком виде они реализованы: в виде расчетов на калькуляторе, в стандартном программном пакете или в виде сложной вычислительной программы. Таким образом, современное
СИ невозможно себе представить без использования в том или ином виде вычислительной
техники.
Контрольные вопросы к Главе 4.
1. В чем заключается суть технологии полупрозрачного ящика при испытаниях программного обеспечения?
А) При такой аттестации известен исходный код, Б) Известны алгоритмы программного
обеспечения, но неизвестен исходный код программы, В) Априори известно решение измерительной задачи, Г) Известны алгоритмы и код, но неизвестен разработчик программного обеспечения.
2. Какова основная функция опорного программного обеспечения?
А) Опорное программное обеспечение лежит в основе используемого в средстве измерений программного продукта, Б) Служит для подпорки средства измерения, чтобы оно не
падало на бок, В) Служит для того, чтобы им любоваться на досуге, Г) Служит для сравнения с испытываемыми программными продуктами.
3. В каких случаях используется генерация опорных данных или метод моделей исходных
данных?
А) Когда отсутствует опорное программное обеспечение или к нему затруднен доступ, Б)
Когда заказчику аттестации не нравится программный продукт, который предлагается использовать в качестве опорного, В) Когда опорный программный продукт испорчен хакерами, Г) Когда опорный программный продукт не представляется возможным разработать по тем или иным причинам.
4. В чем заключается отличие метода генерации опорных данных от метода моделей исходных данных?
49
5. Что характеризует исполнительная характеристика аттестуемого программного продукта?
А) Число сохраненных цифр точности по сравнению с расчетом опорным программным
продуктом, Б) Число потерянных цифр точности по сравнению с расчетом опорным программным продуктом, В) Абсолютную оценку качества аттестуемого программного обеспечения, Г) Изящность исполнения численных расчетов.
6. Каковы требования к моделям исходных данных?
А) Модель исходных данных должна максимально адекватно соответствовать измерительной задаче, численно решаемой программным обеспечением, Б) Модель должна нравиться Заказчику испытаний, В) Модель должна быть произвольной, Г) Модель должна
отражать одну из основных особенностей измерительной задачи.
7. Чем характеризуются вычислительные возможности испытываемой программы?
50
Глава 5. Испытания программного обеспечения средств измерений, основанные на
использовании опорного программного обеспечения.
§ 5.1. Испытания автономного программного обеспечения.
В этом параграфе будут рассмотрены примеры испытаний некоторых конкретных
автономных программных продуктов методом, основанным на использовании опорного
ПО.
Как уже отмечалось, в общем случае, при испытаниях ПО СИ необходимо выполнить весь тот набор проверок, который нужен для подтверждения свойств ПО требованиям нормативной документации, например, требованиям ГОСТ Р 8.654-2015. Этот набор
проверок согласно ГОСТ Р 8.883-2015 включает в себя:
проверку документации, сопровождающей ПО;
проверку соответствия конкретного ПО тому, которое было установлено (зафиксировано)
при испытаниях СИ с целью утверждения типа, и проверку идентификации;
проверку наличия защищенных интерфейсов связи и пользователя, т.е. проверку структуры ПО;
оценку влияния ПО на метрологические характеристики СИ, а также оценку характеристик используемых алгоритмов (программ);
проверку защищенности ПО и данных.
При этом, естественно, предполагается, что организация, проводящая испытания
ПО, располагает квалифицированными кадрами, а также необходимыми аппаратными и
программными средствами для проведения таких испытаний.
Важным элементом испытаний является нахождение параметра  , характеризующего относительное отличие тестовых результатов от опорных. Этот параметр также
определяет как вычислительные возможности испытываемого ПО, так и степень его влияния на метрологические характеристики СИ. При этом предполагается, что влияние опорного ПО на МХ СИ является минимальным. Критерием правильности вычислений, проводимых испытываемым ПО, обычно выбирается условие
  0 ,
(13)
где  0 - предельно допустимое, согласованное между участниками испытаний, относительное отличие тестовых расчетов от опорных. Многолетний опыт испытаний ПО, проводимых ФГУП «ВНИИМС», позволяет утверждать, что при значении  0 = 0,1 % вкладом ПО в методическую составляющую погрешности СИ можно пренебречь по сравнению с другими влияющими факторами.
51
Испытания программного продукта с использованием опорного ПО могут выполняться в разных вариантах. Один из них предусматривает использование уже готового
опорного ПО, выполняющего те же функции, что и испытываемый ПП. Обязательным
элементом испытаний в этом случае, как уже говорилось выше, должно быть соглашение
между Заказчиком и Исполнителем испытаний об отнесении такого ПО к опорному.
Другой вариант требует специальной разработки опорного ПО. Это может быть достаточно легко выполнено в тех случаях, когда алгоритмы тестируемого ПО не являются
сложными и для них без особых усилий и затрат можно написать опорную программу с
использованием какого-нибудь стандартного пакета типа Microsoft Excel, Mathсad или
Matlab.
Наконец, может быть использован и комплексный вариант, когда для испытаний
одних частей ПО используется уже готовый программный продукт, а для тестирования
других частей необходимо специально разрабатывать опорное ПО.
Примером такого комплексного варианта являются испытания ПО хроматографических измерений [25]. Этот автономный программный продукт предназначен для работы
с различными хроматографами. Кроме того, его испытания представляют определенный
исторический интерес, поскольку были одними из первых, проведенных СДС ПО СИ, созданной ФГУП «ВНИИМС».
Представленный на испытания программный продукт (далее Программа) предназначался для использования при проведении качественного и количественного анализа
компонентов исследуемой смеси и выполнял следующие функции:
сбор хроматографических данных с осуществлением контроля условий проведения анализа;
обработка хроматограмм, полученных при анализах;
хранение результатов проведенных анализов;
ведение отчетной документации по результатам анализов.
Программа могла использоваться в комплексе с газовыми, жидкостными или ионными хроматографами, системами капиллярного электрофореза или с хроматомассспектрометрами, предоставляющими измерительную информацию в цифровом виде посредством встроенных или дополнительных АЦП.
Структура Программы была обусловлена ее функциями. В нее входили следующие
основные части:
подпрограмма сбора хроматографической информации, предназначенная для работы с 24разрядным АЦП, выдающим хроматографические данные в оцифрованном виде в соот52
ветствии со своим интерфейсом обмена, сама Программа при этом только отображает и
хранит массив данных, полученных с АЦП;
подпрограмма определения параметров и метрологических характеристик хроматографических пиков на нулевой линии (максимальных погрешностей при определении времени
удерживания, их площадей и высот) для набора значений уровня шумов и дрейфа нулевой
линии;
подпрограмма, содержащая интерпретатор расчетных формул и алгоритмы вычисления
расчетных параметров анализируемых смесей по стандартным методикам;
подпрограммы настроек, режимов работы, графического представления и ряда других
управляющих и вспомогательных функций.
Анализ хроматографических данных проводился в рамках методик измерений (во
время проведения испытаний использовался термин «методика выполнения измерений»).
Под методикой измерений понималось описание условий сбора, обработки и хранения
данных для определенного типа хроматографических анализов. Каждая методика анализа
состава исследуемой смеси выполнялась с использованием результатов обработки нескольких (не более 4) независимых хроматограмм, которые могли собираться как на одном, так и на различных детекторах хроматографического комплекса. Данные первичного
обсчета любой из этих независимых хроматограмм могли использоваться впоследствии
для получения окончательного результата анализа. Для достоверности получаемых результатов при каждом анализе, выполняемом любой методикой, могла использоваться
информация по обработке нескольких независимых измерений (не более десяти) анализируемого образца. Первичная обработка отдельной хроматограммы проводилась одним из
следующих стандартных способов:
методом абсолютной калибровки (включая метод внутреннего стандарта),
методом нормировки,
методом добавки,
методом имитированной дистилляции.
Настройки Программы позволяли использовать необходимое число методик анализов и задавать всю необходимую для их проведения и обработки информацию.
По согласованию участвующих в аттестации сторон было решено провести испытания Программы с использованием опорного («эталонного») ПО, причем в качестве такового использовались два программных продукта: хорошо известный программный пакет Microsoft Excel и программа «МультиХром». Программный пакет Microsoft Excel часто используется для обработки результатов измерений и его вычислительные возможности хорошо известны. О достоинствах программы «МультиХром» уже говорилось.
53
При испытании Программы основное внимание было уделено тем ее частям, которые ответственны за сбор хроматографической информации, за определение параметров и
метрологических характеристик хроматографических пиков на нулевой линии (максимальных погрешностей при определении времени удерживания, их площадей и высот) в
зависимости от уровня шумов и дрейфа нулевой линии и за вычисление расчетных параметров анализируемых смесей по стандартным методикам. Таким образом, процедура испытаний применялась не ко всей Программе в целом, а только к метрологически значимым ее частям, указанным выше.
Результаты испытаний были оформлены в виде протоколов. Таких протоколов оказалось 10:
Протокол № 1 – проверки первичного расчета отдельной хроматограммы методом нормировки с учетом коэффициентов чувствительности детектора по веществам;
Протокол № 2 – проверки работы статистических функций Программы;
Протокол № 3 – проверки работы библиотечных функций Программы;
Протокол № 4 – проверки настроек Программы для расчета по ГОСТ 30319.1-96 молярной
концентрации по значениям объемной концентрации;
Протокол № 5 – проверки настроек Программы для расчета по ГОСТ 22667-82 свойств
природного газа;
Протокол № 6 – проверки результатов вычислений уровня дрейфа и флюктуационных
шумов нулевого сигнала;
Протокол № 7 – проверки погрешности формирования модельных пиков;
Протокол № 8 – проверки погрешности расчета идеальных модельных пиков;
Протокол № 9 – проверки погрешности расчета параметров модельных пиков при наложении помех;
Протокол № 10 – проверки результатов сбора хроматографической информации и вычисления параметров зарегистрированных пиков (времени удерживания, высоты, площади).
Испытания Программы, результаты которого отражены в протоколах №№ 1-5 и 7,
осуществлялось с использованием программного пакета Microsoft Excel, в котором были
записаны соответствующие опорные программы, остальные испытания основывались на
использовании программы «МультиХром».
Из приведенного перечня испытаний рассмотрим более подробно результаты,
представленные протоколом № 10.
Сравнение результатов сбора хроматографической информации и расчетов параметров зарегистрированных пиков (времени удерживания, высоты и площади), полученных при обработке соответствующих хроматограмм Программой и программой «Муль54
тиХром» (протокол № 10), осуществлялось с помощью схемы, изображенной на рисунке
6. Описываемый ниже порядок проведения испытаний был обусловлен стремлением максимально приблизить испытания ПО к реальным условиям работы Программы с хроматографами, которые при испытаниях отсутствовали.
Управляющий код с компьютера поступал на вход ЦАП по последовательному интерфейсу RS-232. ЦАП вырабатывал аналоговый сигнал, имитирующий хроматографический пик с заданными параметрами. Выходной сигнал ЦАП поступал на вход 24-х разрядного АЦП, после чего – в компьютер по интерфейсу RS-232 для последующей параллельной обработки программами «МультиХром» и «Анализатор» (так
называлась
ис-
пытываемая Программа).
Значения относительного отклонения (в %) вычисленных параметров хроматографических пиков от опорных рассчитывались программой «Анализатор» по формуле (см.
формулу (12)):

PAnaliz  PМультиХром
PМультиХром
100% .
(14)
«МультиХром»
ПЭВМ
(опорное ПО)
«Анализатор»
Xi
Yi
ЦАП
Xi -Yi
АЦП
Рисунок 6. Принципиальная схема, используемая при испытаниях программы
«Анализатор»
Результаты испытаний на примере данных, полученных для девяти пиков модельной хроматограммы, приведены в таблице 2. Видно, что результаты вычисления времени
55
удерживания совпадают, в то время как относительная разность в результатах расчета достигает 0,28 % при вычислении высоты и 0,4 % - при вычислении площади.
Известно, что допускаемая основная относительная погрешность ( Q , %) при измерении
опорным программно – аппаратным комплексом «МультиХром» площади и
высоты хроматографического пика на горизонтальной нулевой линии не превышает значения, рассчитанного по формуле:
Q  (0,2  200
Hn
),
H
(15)
где H n - уровень шумов нулевого сигнала (В), H - значение амплитуды измеряемого сигнала (В).
Абсолютная погрешность T измерения времени удерживания пиков с амплитудой
не менее 1/10 диапазона измерения должна быть не более значения, рассчитанного по
формуле
Таблица 2. Результаты расчетов программой «Анализатор» параметров зарегистрированных пиков
«МультиХром»
«Анализатор»
Относительное отличие тестовых
№
п.п.
результатов от опорных, %
T, с
H, мВ
S, мВс
T, с
H, мВ
S, мВс
δT
δH
δS
1
29,9
901,19
5009,84
29,9
898,93
4996,50
0,00000
0,25078
0,26628
2
59,9
450,60
2504,92
59,9
449,47
2498,41
0,00000
0,25078
0,25989
3
89,9
225,30
1252,49
89,9
224,74
1249,30
0,00000
0,24856
0,25469
4
119,9
112,65
626,25
119,9
112,74
624,87
0,00000
0,07989
0,22036
5
149,9
56,32
313,13
149,9
56,20
312,65
0,00000
0,21307
0,15329
6
179,9
28,17
156,58
179,9
28,11
156,61
0,00000
0,21299
0,01916
7
209,9
14,08
78,29
209,9
14,07
78,66
0,00000
0,07102
0,47260
8
239,9
7,04
39,18
239,9
7,04
39,43
0,00000
0,00000
0,63808
9
269,9
3,53
19,58
269,9
3,52
19,67
0,00000
0,28329
0,45965
56
T  (
0,2
 0,1  W ) (с),
F
(16)
где F - частота опроса (Гц), W - значение ширины хроматографического пика (с).
Предшествующие результаты испытаний программы «МультиХром» показывают,
что эта программа обеспечивает выполнение требований (15) - (16), причем это обстоятельство было подтверждено неоднократно при ее использовании и испытаниях.
При уровне шумов нулевого сигнала, характерного для модельных хроматографических пиков, вторым членом в формуле (15) можно пренебречь. Это означает, что погрешность измерения параметров хроматографических пиков опорным комплексом не
должна превышать 0,2%. Из приведенных выше оценок «погрешности» испытаний следует, что вычислительные возможности сравниваемых программ при вычислении времени
удерживания и высоты пиков практически одинаковы.
Вместе с тем, «погрешность» определения программой «Анализатор» площади
хроматографических пиков превышает сформулированные выше нормы. На это обстоятельство было обращено внимание разработчиков Программы. Это замечание было учтено, разработчики Программы внесли соответствующие коррективы, после чего повторные
испытания привели к значениям относительной «погрешности», равным 0,10 % для высоты пиков и 0,15 % - для площади пиков.
Аналогично были исследованы и другие характеристики Программы. Результаты
таких испытаний отражены в протоколах, список которых приведен выше. Замечаний, подобных замечаниям по тестированию Программы, представленному протоколом № 10, к
программе «Анализатор» не было.
Важным показателем и программы является ее соответствие той версии, которая
была установлена (зафиксирована) при испытаниях средств измерений, где эта программа
использовалась, с целью утверждения типа. Для определения степени соответствия была
рассмотрена документация на автоматизированные хроматографические комплексы
«АХК-05» (51Г.500.000 РЭ) и «АХК-06» (61Г.500.000 РЭ), предназначенные для определения компонентного состава природного газа в лабораторных условиях по ГОСТ 2378187 «Газы горючие природные» с последующим расчетом теплоты сгорания, относительной плотности и чисел Воббе. Эти комплексы внесены в Государственный реестр средств
измерений (регистрационный № 21793-01). Они обрабатывают хроматографическую информацию и поверяются с помощью программы «Анализатор». В результате было констатировано соответствие программы «Анализатор» той версии, которая была установлена (зафиксирована) при испытаниях указанных комплексов.
57
Наконец был рассмотрена проблема защиты измерительной информации в программе «Анализатор». По классификации МИ 2891 – 2004 [28] (испытания проводились
на соответствие требованиям этой методики, поскольку ГОСТ Р 8.654 в то время отсутствовал) в Программе реализован средний уровень защиты, т.е. и сама Программа, и измерительная информация защищены от недопустимых изменений с помощью текстового
редактора и организационными мерами (система паролей, многоуровневая система допуска, журнал вмешательств пользователей в настройки и режимы работы Программы).
По результатам аттестации (протоколы № 1-10 и акты испытаний № 1-3) Программы было выдано свидетельство об аттестации, в котором кратко изложены результаты аттестации различных характеристик Программы (еще раз повторим, что во время описываемых испытаний использовалась приведенная терминология).
Уже говорилось о том, что при достаточно простых алгоритмах измерительной задачи опорное ПО может быть разработано Исполнителями испытаний. Примером таких
испытаний являются, например, испытания ПО счетчика – расходомера РМ-5 и счетчика
количества теплоты КМ-5 [29]. ПО этих счетчиков является встроенным, а не автономным. Тем не менее, рассмотрим в самых общих чертах особенности испытаний их ПО для
подтверждения высказанного утверждения о возможности разработки опорного ПО.
В программном обеспечении теплосчетчика для расчета количества теплоты Q используется формула
Q  V    (h1  h2 ),
где V [м3] – объем теплоносителя, протекшего через подающий (обратный) трубопровод
за время наблюдения;  - функция, аппроксимирующая плотность измеряемой среды ( в
общем случае функция температуры t и давления P измеряемой среды) в подающем трубопроводе проводе; h1 , h2 – – удельная энтальпия теплоносителя (сетевой воды), в подающем и обратном трубопроводах, соответственно. Напомним, что энтальпия (тепловая
функция системы) – это термодинамический потенциал, определяемый выражением
h  E  PV , где Е – энергия системы. В свою очередь объем теплоносителя, прошедший
~
~
через расходомер за время t , вычисляется по формуле V (t )  GV  t , где GV - среднее
значение расхода за интервал времени t , определяемое с помощью кусочно-линейной
аппроксимации номинальной градуировочной характеристики расходомера. Описанный
алгоритм расчета количества теплоты без особых проблем был реализован в программном
пакете Matlab и использован в качестве опорного при сертификации ПО расходомера РМ5 и счетчика количества теплоты КМ-5 в работе [29].
58
Рассмотрим более сложный пример разработки опорного ПО и одновременно его
сертификации в качестве такового для испытаний некоторых программных продуктов.
Речь идет о программном обеспечении для испытаний технических средств, осуществляющих передачу мгновенных значений измерений в соответствии с серией стандартов
МЭК 61850 [30].
Необходимость в разработке и сертификации такого ПО связана с тем, что в связи
с развитием цифровых технологий для энергосберегающих систем транспортировки, распределения и использования энергии возникла необходимость в программных и аппаратных средствах для отладки передачи измеренных мгновенных значений параметров электрической энергии в соответствии с требованиями МЭК (Международной Электротехнической Комиссии). Известно, что цифровые технологии обладают рядом существенных
преимуществ по сравнению с традиционными технологиями, основанными на использовании аналоговой информации. Эти преимущества сводятся к обеспечению более высокой
скорости передачи данных и приоритета передаваемого трафика, к возможности синхронизации данных и передачи сервисной информации, к обеспечению контроля целостности
передаваемых данных и т.д. Современная цифровая подстанция представляет собой комплекс интеллектуальных (программно обеспеченных) электронных устройств, реализующих функции учета электрической энергии, контроля ее качества, а также релейной защиты, автоматики и регистрации аварийных событий. При этом структура и функционал
цифровых подстанций регламентируются серией стандартов МЭК 61850 «Сети и системы
связи на подстанциях» [31].
Несмотря на то, что многие организации ведут работы в указанной области, предложение подобного рода программ и аппаратных средств на данный момент носит ограниченный характер, эти разработки стоят дорого, а их функциональные возможности часто не отвечают требованиям пользователей. В ФГУП «ВНИИМС», с учетом опыта института в разработке нормативных документов в области испытаний программного обеспечения средств измерений и наличия в институте соответствующей системы добровольной сертификации, было разработано ПО и проведены его испытания с целью определения его возможностей для оценки ПО технических средств, которыми осуществляется передача и контроль мгновенных значений параметров электрической энергии в соответствии с серией стандартов МЭК 61850, имея в виду его дальнейшее использование в качестве опорного.
Программное обеспечение цифровой подстанции анализирует и контролирует пакеты данных, передаваемых в соответствии с дополнительными рекомендациями МЭК
61850-9.2LE. К указанному ПО предъявляются определенные требования, призванные
59
гарантировать адекватное выполнение этим ПО приписанных функций. В институте разработан ряд нормативных документов – методик института (МИ), конкретизирующих
требования к ПО, используемому при анализе и контроле пакетов данных на соответствие
требованиям стандарта МЭК 61850. Все указанные методики в процессе испытаний
предусматривают анализ документации ПО и проведение функциональных проверок. Методы проведения анализа документации и функциональных проверок изложены во вновь
разработанном национальном стандарте ГОСТ Р 8.883-2015 [6].
Уже отмечалось, что наличие в распоряжении организации, проводящей испытания, опорного ПО, по сути, решает задачу сертификации испытываемого ПО. Сотрудниками института было разработано ПО, предназначенное для сертификации программных
продуктов, используемых для анализа и контроля передачи мгновенных значений результатов измерений параметров электрической энергии в соответствии с серией стандартов
МЭК 61850, которое в будущем предлагается использовать в качестве опорного. При разработке ПО первоначально продумывался интерфейс пользователя программы, а затем
происходило его функциональное наполнение, при этом, кроме требований к интерфейсу
пользователя программы, учитывались также требования к разделению, идентификации и
защите ПО.
При работе с таким ПО пользователь, прежде всего, имеет возможность в соответствующем меню выбрать активный поток, определить перечень анализируемых каналов и
временной интервал для анализа, а также, просмотреть справочную информацию об активных SV потоках (Sampled Values – потоки измерительной информации о мгновенных
значений тока и напряжения). После выбора SV потока необходимо определить перечень
анализируемых каналов (фазы A, B, C или нейтраль N) и выбрать временной интервал для
анализа.
Разработанное ПО, кроме считывания мгновенных значений тока и напряжения из
цифрового потока и выполнения указанных выше функций, обладает также возможностью
осуществлять обработку измерительной информации по алгоритмам, изложенным в патентах [32, 33], в том числе вычисление основной частоты сети, среднеквадратичных значений тока и напряжения, а также фазовых углов сдвига.
Цель испытаний разработанного ПО сводилась к проверке правильности реализации им указанных вычислительных алгоритмов и к оценке его вычислительных возможностей. Для проведения испытаний использовался метод моделей исходных данных, в качестве которых выступали входные данные для программных продуктов, формирующих
SV потоки.
60
В соответствии с этим методом цифровые SV потоки на испытательном стенде (рисунок 7) формировались ПО Volcano и IMerge, воспроизводились ПО Flooder, а также
программным продуктом ООО «Систел» при заданных значениях исходных данных (значениях тока, напряжения, частоты и угла фазового сдвига). Эти цифровые потоки, передаваемые по Ethernet сети (кабельным каналам связи), «перехватывались» тестируемым
ПО и помещались в буфер для последующей обработки (вычисления значений тока,
напряжения, частоты и угла фазового сдвига) по заданным алгоритмам. Результаты обработки сравнивались с исходными данными.
Программа анализа пакетов
протокола IEС 61850-9-2LE
(тестируемое ПО)
IEС 61850-9-2
(SV пакет)
IEС 61850-9-2
(SV пакет)
IEС 61850-9-2
(SV пакет)
ПО Volcano
ПО Flooder
ПО Систел
I, U, w, f, параметры
качества (тестовые
результаты)
Программно задаются: I, U, w, f
Из файла «pcap»
I, U, w, f, параметры качества
Задаются:
I, U, w, f, параметры качества
I, U, w, f, параметры
качества (исходные
данные)
Блок сравнения
Рисунок 7. Схема испытательного стенда для испытаний ПО на соответствие требованиям
стандартов МЭК 61850.
Оценка вычислительных возможностей испытываемого ПО осуществлялась в несколько этапов:
определение состава и схемы испытательного стенда;
проведение испытаний;
обработка результатов испытаний;
61
выбор критерия оценки - условия принятия положительного решения по результатам испытаний;
принятие решения.
В качестве критерия правильности результата испытаний принималось значение
0,1% относительного расхождения между результатами обработки измерительной информации тестируемым ПО и исходными данными, заданными при генерации цифрового
потока. В случае превышения установленного порога считалось, что ПО не прошло испытания. Относительное расхождение вычислялось по формуле (12).
Результаты обработки SV сообщений показаны в Таблице 3 (ввиду того, что объем
информации, получаемой в процессе испытаний, очень велик, информация в таблице приведена не полностью, зафиксированы только критические значения, близкие к уровню,
установленному критерием).
Исходные данные
ООО «Теквел», Volcano,
SV80
IA = 1000 А
UA = 63500 В
ωA = 50 Гц
ϕA0= 1.047197551 рад
ООО «Теквел», IMerge,
SV80
IA = 1000 А
UA = 110000 В
ωA = 50 Гц
ϕA0 = 0,5235987760 рад
ООО «Компания ДЭП», SV
80
IA = 5 А
UA = 100 В
ωA = 50 Гц
ϕA0 = 1,832595715 рад
ООО «Систел», SV 256
UA = 220 В
ωU = 50 Гц
ϕU0 = 1,570796327 рад
ООО «Систел», SV80
UA = 220 В
ωU = 50 Гц
ϕU0 = 1,570796327 рад
Таблица 3.
Тестируемое ПО
Относительное расхождение, %
IA = 999,999593 А
UA = 63499,994968 В
ωA = 49,999999999998806
Гц
ϕA0 = 1.046878141 рад
0.00004070001656447
0.00000792441007826
0.00000000000240163
0.03051071442706810
IA = 999,999593 А
UA = 109999,996102 В
ωA = 50,000000000009479
Гц
ϕA0 = 0,5231536660 рад
0,00004070001656447
0,00000354363648502
0,00000000001880096
0,08508207605679400
IA = 4,998652 А
UA = 100,010244 В
ωA = 49,997491649562726
Гц
ϕA0 = 1,832985405 рад
0,02696727037609590
0,01024295071212920
0,00501695256010878
0,02125983103968060
UA = 219,995601 В
ωU = 50,000000004993794
Гц
ϕU0 = 1,5707963286 рад
0,00199958543716812
0,00000000998740290
0,00000010185915775
UA = 219,895029 В
ωU = 50,0000009633535 Гц
ϕU0 = 1,5707963335 рад
0.04773686812174650
0.00000192670696304
0.00000041380284210
62
Исследования проводились по 4 параметрам, при этом вычислялись среднеквадратичные значения тока и напряжения по фазе А, основная частота сети и углы сдвига по
этой фазе. Из полученных результатов видно, что максимальное относительное расхождение исследуемых параметров наблюдается для угла сдвига по фазе А и имеет значение,
равное 0,085 %.
Значения расхождения того же порядка достигаются при сравнении тестовых результатов со всеми генераторами SV потока, что отражает правильность разработанного
ПО, что, в свою очередь, позволяет использовать его в дальнейшем в качестве опорного
ПО при сертификации программных продуктов, используемых для анализа и контроля передачи мгновенных значений результатов измерений параметров электрической энергии в
соответствии с серией стандартов МЭК 61850.
§ 5.2. Испытания встроенного программного обеспечения.
Еще одним примером необходимости использования опорного ПО являются испытания встроенного ПО.
Упоминание о встроенном ПО содержится, например, в ГОСТ Р 8.596 [17]. В Примечании к п.3.3.3 этого документа записано:
«В отдельных случаях вычислительный компонент (т.е. цифровое вычислительное
устройство с программным обеспечением, выполняющее функции вычисления результатов…измерений по результатам первичных измерительных преобразований в ИС (измерительной системе)), может входить в состав измерительного компонента (т.е. в средство
измерений), метрологические характеристики которого нормированы с учетом программы, реализуемой вычислительным компонентом».
Другими словами, подчеркивается, что испытания встроенного ПО, как такового,
могут не проводится.
Такой подход является выражением распространенной точки зрения, согласно которой важно, чтобы метрологические характеристики средства измерений в целом находились в пределах допуска. Если они выходят за эти пределы, то разбираться в том, какая
часть прибора, инструментальная или программная, ответственна за неисправность – это
проблема изготовителя прибора. Кстати, нахождение МХ прибора в пределах допуска, как
уже упоминалось, действительно являются указанием на отсутствие влияния ПО на МХ
СИ. В то же время рекомендации международных организаций по стандартизации и метрологии настаивают на проведении испытаний ПО и в рассматриваемом случае по той
причине, что, как уже неоднократно подчеркивалось, испытания ПО не ограничиваются
63
только выяснением влияния ПО на МХ СИ. Так в Рекомендации [9] на примере простого
автономного измерительного прибора, состоящего из датчика (или преобразователя,
включая аналоговую электронику), других аналоговых компонент (например, ЦАП), платы микропроцессора, жидкокристаллического экрана и аппаратного интерфейса для подключения периферийного устройства, заключенных внутрь корпуса, детально рассмотрены требования к соответствующему ПО. При этом предполагается, что в ПО не вносится
никаких изменений после утверждения типа, отсутствует разделение на части, подвергаемые метрологическому контролю (по терминологии Рекомендации [9]), и на другие неконтролируемые части. Метод обнаружения возможных ошибок сводится к вычислению
контрольной суммы по содержимому памяти. Основная концепция Рекомендации сводится к так называемому пошаговому подходу, заключающемуся в том, чтобы после назначения уровней защиты, испытаний и соответствия для каждой области применения прибора
устанавливаются специфические требования, учитывающие его технические особенности.
Дальнейшие испытания проводятся с учетом этих требований. В свою очередь, эти требования определяются целым рядом проблем, возникающих при испытаниях встроенного
ПО [34]. Перечислим некоторые из них.
Иногда при испытаниях ПО алгоритм обработки входных сигналов неизвестен. Это
может приводить к неправильному заключению о плохом качестве используемого алгоритма, который, на самом деле, работает правильно. Например, если на вход прибора подается частотно-импульсный сигнал, то, как правило, возможны два алгоритма обработки
при его преобразовании в значение физической величины, а именно,
подсчет числа импульсов и его умножение на коэффициент преобразования,
измерение частоты сигнала и ее интегрирование по времени с последующим умножением
на коэффициент преобразования.
Во втором случае результат вычисления зависит от выбранного временного интервала интегрирования и при малых его значениях погрешность вычисления с помощью такого алгоритма может оказаться значительной, что может привести к неверной оценке его
качества. Эта погрешность уменьшается при увеличении времени тестирования, которое
может оказаться слишком большим. Из сказанного следует, что необходимо добиваться
того, чтобы алгоритм обработки входных сигналов при аттестации встроенного ПО был,
по меньшей мере, известен.
Такое же требование необходимо предъявлять и к используемому алгоритму обработки измерительной информации (алгоритму вычислений). При косвенных измерениях
часто приходится вычислять свойства измеряемых сред (газов, жидкостей, нефтепродуктов). Исходные данные для вычисления этих свойств могут задаваться либо в виде таблиц,
64
либо в виде функциональной (как правило, полиномиальной) зависимости. При этом часто при расчете свойств используется несколько вариантов расчета или их комбинаций.
Основная проблема, возникающая при работе с таблицами, сводится к необходимости
проведения большого объема работы, поскольку при определении погрешности расчета
свойств в большинстве случаев задействуются все узлы таблицы.
Если в ПО средства измерения используется алгоритм вычисления в соответствии с
заданным уравнением косвенных измерений, то при испытаниях ПО может возникнуть
проблема, связанная с отличием разрядности результатов, выдаваемых средством измерений и компьютером, на котором реализован аналогичный алгоритм. При этом при полной
идентичности алгоритмов, заложенных в ПО средства измерений и в компьютер, возможны существенные расхождения в результатах численных расчетов (особенно при использовании уравнений с суммированием сильно отличающихся чисел).
Часто результаты измерений, полученные с помощью средств измерений, предназначенных для измерений с нарастающим итогом, имеют большую разрядность и малое
количество знаков после запятой. Для того чтобы погрешность измерений в этом случае
удовлетворяла необходимым требованиям, следует добиваться того, чтобы погрешность,
обусловленная младшим разрядом (погрешность округления), была, по меньшей мере, не
более 1/5 погрешности вычислений.
Иногда при косвенных измерениях возникает необходимость в проверке погрешности вычисляемых величин, которые не отображаются на дисплее средства измерений.
Решение этой проблемы самым существенным образом зависит от используемого уравнения измерений. Таким образом, в этом случае возникает требование обязательного знания
этого уравнения.
В большинстве случаев при проведении испытаний встроенного ПО используется
сопоставление результатов тестирования с опорными вычислениями (см. ниже). Для
окончательного определения погрешности обработки измерительной информации необходимо знать нормируемую погрешность вторичного преобразования электрических сигналов в значения физических величин, а также то, насколько нормируемая погрешность
обработки информации соответствует заложенному в средство измерений алгоритму обработки. Сказанное поясним таким примером.
В счетчиках количества теплоты с водным теплоносителем датчики давления часто
не используются, хотя информация о давлении необходима для расчета плотности и энтальпии воды. В отечественных счетчиках тепла вместо измерения давления иногда просто вводят его постоянные значения, что может приводить к существенной методической
погрешности измерений. В некоторых импортных счетчиках для расчета количества тепла
65
используются так называемые коэффициенты Штюка, сведенные в таблицы. В таблицах
обычно принимается, что давление в подающем трубопроводе равно 1,6 МПа, а в обратном – 0,1 МПа, и для этих условий коэффициенты рассчитываются. Однако в реальных
условиях эксплуатации давления в подающем и обратном трубопроводах могут существенно отличаться от приведенных значений, особенно при малых разностях температур
в трубопроводах (до единиц процентов). При этом, естественно, возникает вопрос: относительно чего нормировать погрешность обработки – относительно значений коэффициентов, рассчитанных при указанных значениях давления, или определять максимальную
погрешность при других значениях давления в трубопроводах. В настоящее время идут
по первому пути, при этом возникающая методическая погрешность, особенно в условиях
эксплуатации, как правило, никак не учитывается.
При испытаниях ПО больших измерительных систем возникает проблема несинхронного опроса датчиков. В большинстве случаев при проверке вычислений оказывается
невозможным получить и использовать те значения входных параметров, по которым считает ПО средства измерений (измерительная система), поскольку при большом количестве
входных параметров их индикация идет на разных экранах, и при их считывании они
успевают измениться по отношению к значениям, используемым ПО средства измерений.
Проблема большого количества входных параметров может быть решена путем разделения общей задачи тестирования на подзадачи.
Одно из требований, предъявляемых к ПО СИ, сводится к соответствию тестируемого ПО тому, которое было установлено (зафиксировано) при испытаниях СИ с целью
утверждения типа. Проверка такого соответствия сейчас по возможности осуществляется
при поверке СИ, однако, такой подход (проверка соответствия) иногда встречает сопротивление изготовителей СИ.
Наконец, для приборов со встроенным ПО, на предприятии – изготовителе существует калибровочное ПО, использующееся для настройки прибора при выпуске из производства, а также для корректировки калибровочных коэффициентов в случаях, когда прибор не прошел очередную проверку. Понятно, что калибровочные программы должны
быть недоступны широкому кругу лиц. К сожалению, нередки случаи, когда изготовители
приборов передают калибровочные программы внедренческим организациям. Анализ
причин такой передачи не входит в цели настоящего пособия. Следует только констатировать, что в настоящее время, если иметь в виду приборы, используемые для учета энергоресурсов (счетчики воды, газа, тепла, электроэнергии), сложилась такая ситуация, когда и
изготовители приборов, и сервисные (внедренческие) фирмы, и потребители энергоресурсов заинтересованы в негласном распространении специальных программ, способных в
66
обход существующих защит, блокировок и пломб проникать в память микропроцессорных вычислителей с целью ее несанкционированной корректировки. Из сказанного следует актуальность проведения испытаний цифровых приборов по обеспечению надежной
защиты от несанкционированного вмешательства в условиях эксплуатации.
И это только некоторые из проблем, с которыми приходится сталкиваться при испытаниях встроенного ПО.
Решение большинства перечисленных проблем возможно путем введения разработчиками в средство измерения специального режима (обычно это делается для поверки), позволяющего реализовать необходимые проверки программного обеспечения.
Для иллюстрации особенностей испытаний встроенного ПО, наряду с описанными
в предыдущем параграфе испытаниями ПО счетчика количества теплоты КМ-5, рассмотрим испытания ПО электронного счетчика количества теплоты MULTIDATA S1 (фирма
«Ценнер» (ФРГ)). Этот счетчик является типичным примером прибора со встроенным ПО.
В его состав входят:
расходомер для измерения количества теплоносителя, прошедшего через прибор;
температурные датчики, предназначенные для измерения температуры теплоносителя в
подающем и обратном трубопроводах;
необходимые АЦП;
контроллер, состоящий из микропроцессора с программной и оперативной памятью;
жидкокристаллический индикатор;
оптический и шинный интерфейсы для подключения к персональным или ручным компьютерам;
ряд дополнительных устройств для расширения возможностей счетчика и удобства контроля и управления.
Расчет количества теплоты Q (МВт·час, гига- или мегаджоуль), измеренного прибором, ведется по формуле
A  k  V  T ,
(17)
где V -измеренный объем теплоносителя, T - разность температур в прямом и обратном
трубопроводах, k - тепловой коэффициент (коэффициент Штюка), учитывающий температурную зависимость плотности и энтальпии теплоносителя и обеспечивающий необходимую размерность правой части формулы (17) с учетом того, что измерение объема теплоносителя осуществляется импульсным методом, т.е. необходимо знать цену импульса в
литрах или в кубометрах.
67
Особенность прибора заключается в том, что значения коэффициентов Штюка зависят от того, куда установлен прибор – в прямой или в обратный трубопровод. Существуют таблицы коэффициентов Штюка, рассчитанные для разных пар значений разностей температур в прямом и обратном трубопроводах.
При испытаниях рассматриваемого ПО необходимо, по сути, убедиться в двух моментах, а именно: в правильности расчета коэффициентов Штюка и в правильности работы АЦП, преобразующего аналоговый сигнал от температурных датчиков в цифровой код.
Если предположить, что коэффициенты Штюка рассчитаны верно (с точностью до проблемы, отмеченной выше и связанной с тем, что эти коэффициенты рассчитываются только для двух значений давления) и АЦП работает в соответствии с его заявленными характеристиками, что достаточно легко проверяется, то вся аттестация сведется к проверке
правильности работы микропроцессора при вычислениях по формуле (17). Для этого достаточно записать формулу (17) в каком-нибудь программном пакете, например, в Microsoft Excel, и сравнить результаты вычислений в этом пакете с тем, что дает микропроцессор прибора.
Таким образом, видно, что в рассматриваемом случае испытания встроенного программного обеспечения сводится к использованию опорного ПО. Предложенный метод
испытаний встроенного ПО, по всей видимости, может быть использован для большого
числа приборов рассматриваемого типа, поскольку, как правило, алгоритмы, «зашитые» в
них, являются достаточно простыми. Для цифровых приборов, используемых при коммерческом учете энергоресурсов, процедура испытаний должна обязательно включать в
себя, как уже отмечалось, проверку способов защиты ПО и данных от несанкционированного вмешательства. Методы, применяемые при такой проверке, изложены в Рекомендациях Росстандарта Р 50.2.077-2014 [4].
Основная проблема, возникающая при испытаниях встроенного ПО заключается,
как правило, в отсутствии к нему прямого доступа. Эта проблема может быть решена либо
так, как это было отмечено в начале параграфа, когда метрологические характеристики
СИ нормируются с учетом программы, реализуемой вычислительным компонентом, либо
при тесном взаимодействии с разработчиками ПО, как это было сделано в работе [34].
Контрольные вопросы к Главе 5.
1. В чем заключаются основная проблема испытаний встроенного программного
обеспечения?
68
А) Никаких проблем нет, Б) Встроенное программное обеспечение не должно испытываться, В) К встроенному программному обеспечению в большинстве случаев отсутствует прямой доступ, Г) Неизвестны алгоритмы, используемые во встроенном программном обеспечении.
2. Назовите источники методической погрешности при эксплуатации счетчиков количества теплоты, обусловленные особенностями используемого программного
обеспечения.
А) В датчиках давления информация о давлении часто не используются, хотя она
необходима для расчета плотности и энтальпии воды (иногда просто вводят его постоянные значения), в импортных счетчиках коэффициенты Штюка рассчитываются
только при значениях давления, которые в процессе эксплуатации часто не выдерживаются, Б) Методическая погрешность в процессе эксплуатации не возникает, В) При
калибровке прибора используются калибровочная программа для счетчиков другого
типа, Г) Зависание программы.
3. Почему при испытании программного обеспечения хроматографических измерений использовалась сложная схема аттестации, изображенная на рис. 12?
А) Нужно было обеспечить работой испытателей программного обеспечения, Б) В
процессе испытаний программного обеспечения пытались создать условия, максимально
приближенные к тем, что реализуются в условиях эксплуатации, В) Так захотелось Заказчику испытаний, Г) Такая схема приснилась испытателю программного обеспечения.
4. Почему при расчете объема теплоносителя через измеренные значения расхода используется метод прямоугольников оценки интеграла, а не метод Симпсона?
А) Потому что испытатели не знали никаких других методов оценки интегралов, Б)
Испытателям не удалось найти аналитическое выражение для функции, аппроксимирующей зависимость расхода от времени, В) Заказчик аттестации запретил использовать метод Симпсона, потому что не понимал его, Г) Аналитическое выражение для
функции зависимости расхода от времени неизвестно.
6. Какие данные используются в качестве моделей исходных данных при испытаниях
ПО, используемого при цифровых технологиях контроля качества электроэнергии?
69
Глава 6. Методы испытания программного обеспечения средств измерений.
§ 6.1. Метод генерации опорных данных.
В ходе изложения материала в пособии неоднократно подчеркивалось, что наличие
в распоряжении Испытателя опорного ПО решает проблему оценки вычислительных возможностей испытываемого ПО и степени его влияния на МХ СИ. Также говорилось о том,
что отсутствие опорного ПО, или доступа к нему приводит к серьезным проблемам при
испытаниях ПО и вызывает необходимость использования альтернативных методов испытаний таких как, например, генерация опорных данных, метод моделей исходных данных
и другие.
В NPL для испытаний программных продуктов в отсутствие опорного ПО был разработан метод генерации опорных данных. Рассмотрим основные идеи этого метода на
примере генерации опорных данных для задачи простой линейной регрессии, как это сделано в работе [11].
Напомним, что линейный регрессионный анализ объединяет широкий круг задач,
связанных с построением функциональных зависимостей между двумя группами числовых переменных: x1 ,..., xm и y1 ,..., ym . Статистический подход к задаче восстановления
функциональной зависимости y от x основывается на предположении, что известны некоторые исходные (экспериментальные или модельные) данные ( xi , yi ) , где yi - значение
отклика (выхода) при заданном значении входного сигнала xi (i  1,..., m), m - число измерений. Предполагается, что наблюдаемое на опыте значение отклика y можно разделить
на две части: одна из них закономерно зависит от x , т.е. является функцией x , другая –
случайна по отношению к x . Для того, чтобы задача о подборе функции отклика была
осмысленной, необходимо на основе анализа данных ( xi , yi ) определить набор допустимых функций f (x ) . Предполагают также, что множество допустимых функций является
параметрическим семейством f ( x, ), где  - параметр семейства. Таким образом, искомая функция может быть записана в следующем виде
yi  f ( xi , )  ri ,
(18)
где ri - случайная величина.
Теперь перейдем к широко распространенной на практике задаче, когда функция
f ( x, ) линейно зависит от параметров  , т.е. будем предполагать, что формула (18) имеет вид
yi  b1  b2 xi  ri ,
(19)
70
или в векторном виде
y  Ab  r ,
(20)
где матрица наблюдений A (так эта матрица названа в работе[11]) и векторы в формуле
(20), в том числе вектор остатков r , имеют вид
1

1
.
A
.

.
1

x1 
 y1 

 
x2 
 y2 
. 
. 
 , y   ,
. 
. 

 
. 
. 

y 
xm 
 m
 r1 
 
 r2 
. 
b 
b   1  , r   
. 
 b2 
 
. 
r 
 m
.
(21)
Задача нахождения значений параметров b при заданных (известных из эксперимента) векторах y и x называется задачей простой линейной регрессии, а ее решение
находится методом наименьших квадратов (МНК). Задача, рассматриваемая в пособии,
заключается в построении такого набора опорных данных y , который имитировал бы экспериментальные данные при тестировании программных продуктов, реализующих МНК.


Решая эту задачу, подействуем транспонированной матрицей AT  1 1...1  на
 x x ... x 
 1 2 m
обе части равенства (20). В результате получим
AT y  AT Ab  AT r .
Искомая матрица параметров b будет определяться выражением b  A1 y , где A1 - матрица, обратная матрице наблюдений A , при условии, что
AT r  0,
(22)
выполнение которого обеспечивается методом наименьших квадратов. В свою очередь,
условие (22) эквивалентно выполнению двух условий
m
 r  0,
i 1
i
m
 x r  0.
i 1
(23)
i i
Если ri - случайные величины разных знаков, то первое равенство отражает тот известный факт, что при достаточно больших объемах выборки сумма случайных величин с
учетом того, что они могут быть разных знаков, равна нулю.
Второе равенство представляет собой систему однородных (с нулевой правой частью) линейных уравнений относительно остаточных членов ri . Пространство решений
71
такой системы образует так называемое нуль-пространство по терминологии работы [11].
В этой работе предлагается следующий способ решения системы (23)
Прежде всего соотношением
AT N  0.
(24)
вводится базис N в нуль – пространстве матрицы AT . Этот базис представляет собой
набор линейно независимых векторов, которые и образуют матрицу N для входных данных x , определяющих матрицу AT . Методы построения такого базиса разработаны в ряде
стандартных программных пакетов и реализованы в виде библиотечных функций. Так,
например, в Matlab эта функция обозначается как NULL(A).
Из формулы (22) следует, что вектор случайных остатков r принадлежит нуль –
пространству транспонированной матрицы AT . Если известен базис этого нуль – пространства, определяемый формулой (24), то вектор r , компоненты которого являются
случайными числами, может быть представлен в виде линейной комбинации этих базисных векторов, т.е.
r  N u ,
(25)
где вектор u представляет коэффициенты этой линейной комбинации, являющиеся случайными числами.
Отличительной особенностью рассматриваемого метода, как отмечалось, является
то, что замена вектора y в формуле (20) на y  r , где вектор r определяется формулой
(25), оставляет неизменным решение b линейной регрессионной задачи (20). В самом деле, с учетом условия (22), получаем
AT ( y  r )  AT y  AT r  AT y,
(36)
т.е. ничего не меняется по сравнению со случаем, когда остаточного члена не было. Из
написанного соотношения следует, что, построив один набор данных y , выбором вектора
u
можно построить множество наборов данных, имеющих одно и то же решение линей-
ной регрессионной задачи b . Обычно векторы u выбираются в виде набора случайных
чисел, наиболее точно имитирующих измеренные данные.
Таким образом, процедура генерации опорных данных для задачи линейной регрессии в общих чертах состоит из последовательности следующих действий:
1. Предполагая строгую линейную зависимость (линейную модель) откликов системы
на входные воздействия строится модельный вектор наблюдений y0  Ab , где индексом «0» обозначены опорные (модельные) результаты, являющиеся «входом»
для генерации опорных данных (см. рисунок 5).
72
2. С помощью программной функции NULL(A), строится базис N в нуль – пространстве матрицы AT .
3. Соотношением r  N  u строится вектор остатков, при этом компоненты вектора
u выбираются в виде случайных чисел, имитирующих ошибки измерений. Часто
вектор r необходимо видоизменять (масштабировать) таким образом, чтобы он
представлял распределение случайных чисел с заданными средним значением и
СКО.
4. По формуле y  y0  r образуется вектор наблюдений, представляющий собой
сгенерированные опорные данные.
Строгое математическое обоснование изложенного метода возможно только для
ограниченного круга задач, не сильно отличающихся от линейных. В остальных случаях
приходится использовать численные методы, математическое обоснование которых в
большинстве случаев носит скорее эмпирический или интуитивный характер.
В качестве примера реализации изложенных соображений рассмотрим более детально процесс генерации опорных данных для задачи линейной регрессии с помощью
программного продукта Matlab [35]. Этот программный продукт выбран не случайно. Как
показали детальные исследования, проведенные специалистами NPL, из набора стандартных программных пакетов именно эта программа характеризуется наиболее качественными показателями.
В соответствии с методологией задачи линейной регрессии опорными данными
будут последовательности откликов y на входные воздействия x, приводящие при ее
решении МНК к заданным параметрам линейной зависимости. Задача заключается в
нахождении хотя бы одной такой последовательности.
Процесс генерации опорных данных, как было описано выше, сводится к следующим действиям.
1. Задается в виде матрицы последовательность значений xi , программно имитирующая
0.451598709729628 
1.860840356944960 


входные данные, например, x  0.895179433337502 


 0.267034244625225
0.300214127255706 
2. Формируется «матрица наблюдений» A :
73


1 0.451598709729628 


1 1.860840356944960 


A  1 0.895179433337502 


1  0.267034244625225




1 0.300214127255706 
Термин «матрица наблюдений» является условным, т.к. в задаче линейной регрессии
«наблюдениями» являются значения откликов y на входные воздействия x.
3. Программно задаются некоторые значения компонент опорного (модельного) вектора
b , например:
b1  - 0.274534891599586
b2  - 0.840917852481225
Предполагается, что опорные (модельные) результаты априори известны и описываются
строгой линейной зависимостью y0  b1  b2 x , где коэффициенты этой опорной зависимости могут быть такими, какие заданы выше.
4. В соответствии со сказанным, с помощью матрицы A и заданных компонент опорного
(модельного) вектора b формируется вектор опорных (модельных) результатов
 0.654292308768717 
 1.839348768372140 


y 0  Ab   1.027307258267120 


 0.0499810280703859
 0.526990310775980 
5. С помощью библиотечной функции NULL(AТ) программного пакета Matlab формирует-
ся базисная матрица N нуль - пространства транспонированной матрицы AT (например,)
N=
-0.385867517917013
-0.312769200185134
0.859961643102225
-0.0614948764249055
-0.0998300485751729
-0.617532287396196
0.346479483872357
-0.133083227191928
0.648851928596488
-0.244715897880721
-0.504462319453991
0.0247161542996249
-0.136477857694623
-0.209775356233149
0.825999379082139
6. Формируется вектор v  N  u , где компоненты вектора u являются случайными
числами с нормальным
распределением, которое, в свою очередь, характеризуется
средним значением, равным 0, и СКО, равным 1 (генератор случайных чисел (ГСЧ)
программы Matlab «выдает» нормальное распределение именно с такими параметрами).
74
Нормальное
распределение, воспроизводимое ГСЧ программы Matlab, для выборки со
ста элементами изображено на рисунке 8.
Генератор случайных чисел при обращении
ния для компонент вектора u :
к нему выдал следующие значе-
 1.60408556200116
u   0.25730423467749
 1.05647292808148
Рисунок 8. Нормальное распределение случайных чисел.
Число компонент вектора u оказалось равным 3 из-за того, что матрица N имеет только 3
столбца. По формуле v  N  u строится вектор
0.993021625479119 
0.564747248781014 


v   1.269509771559180


0.487217377155740 
 0.775476479856698
Вектор v представляет собой промежуточный результат нахождения остаточных членов,
поскольку, как случайная величина он характеризуется параметрами, присущими нормальному распределению, воспроизводимому ГСЧ. Это означает, что предстоит еще масштабирование этой величины, о котором говорилось выше, для того, чтобы окончательный результат обладал заданными параметрами.
7. Масштабированием вектора v с помощью соотношения r  v  s , где s – задаваемое
СКО, формируется вектор остатков r . В общем случае, когда необходимо также обеспечить заданное среднее значение r , масштабирование должно осуществляться соотношением r  v  s  r . В данном случае масштабирование осуществлялось только изменением
75
СКО (необходимость сдвига на отличное от нуля значение r отпадает из-за условия (23)).
Полагая, например s  0,1 , получаем
0.0993021625479119 
0.0564747248781014 


r  0.1269509771559180 


0.0487217377155740 
 0.0775476479856698
8. С помощью соотношения y  y0  r формируется вектор эталонных данных для отклика системы на внешние воздействия
 0.554990146220805 
 1.782874043494040 


y   1.154258235423040 


 0.001125929035482183
 0.604537958761650 
Окончательно результирующий набор опорных данных состоит из x, y и b . Если
этот набор данных поступит на вход корректно действующего ПО, вычисляющего параметры линейной регрессии по методу наименьших квадратов, то такое ПО на заданном
уровне точности должно получить такие же значения для параметров b1 ,b2 , которые были
использованы для генерации опорных данных на этапе 3 описываемой процедуры. Вычисления методом наименьших квадратов в программном пакете Matlab с точностью до
десятого знака после запятой с полученными выше опорными данными привели к значениям b1  - 0.2745348916, b2  - 0.8409178525. Если бы было новое обращение к ГСЧ на
этапе 6, то он сгенерировал бы другие компоненты вектора u и, следовательно, другой
набор опорных данных y , которые снова бы привели к тем же самым значениям b1 и b2 .
Полученный описанным способом набор опорных данных в дальнейшем использовался для оценки качества некоторых программных продуктов [35].
В заключение этого параграфа необходимо сделать следующие замечания:
1. Уже говорилось, что метод генерации опорных данных является одной из разновидностей метода «черного ящика» и используется в том случае, когда отсутствует опорное программное обеспечение. Описанное выше применение метода генерации опорных
данных для проблемы линейной регрессии можно рассматривать как его использование
для «абсолютной» оценки качества ПО, когда имеется возможность сравнить расчеты тестируемого ПО с опорными (модельными) результатами. Оказывается, что этот метод
может быть применен и при «относительных» оценках качества ПО, когда сравниваются
76
вычислительные возможности двух или нескольких программных продуктов, имеющих в
качестве входа один и тот же набор опорных данных. Детали такого сопоставления можно
найти в работе [11].
2. Кроме метода генерации опорных данных существуют и другие разновидности
метода «черного ящика». Наряду с моделями исходных данных, предлагаемых методикой
МИ 2174, могут быть использованы также проверки на самосогласованность, непрерывность, а также проверки с использованием табличных значений и т.п. [11].
Нельзя также не отметить, что, как уже говорилось, и метод генерации опорных
данных, и метод моделей исходных данных являются разновидностями одного и того метода. Это отчетливо видно из сравнения рисунков 4 и 5. Если на рисунке 5 удалить два
блока «reference generator» и «reference data», то получим схему, изображенную на рисунке 4. В то же время метод моделей исходных данных позволяет библиотечными программными средствами получать те же самые результаты, что и метод генерации опорных
данных, но более простым путем.
3. Метод генерации «эталонных» данных был подвергнут критике в работе [24].
Эта критика в значительной степени не обоснована, поскольку является следствием расширительного толкования назначения и функций ПО.
§ 6.2. Метод моделей исходных данных.
Модель исходных данных была предложена сотрудниками ФГУП «Всероссийский
институт метрологии им. Д.И. Менделеева» (ФГУП «ВНИИМ им. Д.И. Менделеева») в
1991 г. в работе [18] как альтернатива методу опорного ПО. Эта работа явилась одной из
первой отечественных работ по оценке численных возможностей алгоритмов обработки
результатов измерений.
В общих четах метод сводится к выполнению следующих обязательных процедур:
1. Устанавливается набор основных характеристик алгоритмов П1,…,Пn , которые следует оценивать. В частности, такими характеристиками для алгоритмов, используемых
при обработке данных многократных прямых измерений, могут быть
П1 - СКО случайной погрешности результатов измерения;
П2 - границы систематической погрешности  результата измерения.
Иногда указанные характеристики удобно представлять в приведенной форме, отнесенными к соответствующим погрешностям среднего арифметического.
В качестве показателя устойчивости алгоритма принимают точку срыва Пср, т.е. допустимую долю выбросов в данных, наличие которых не приводит к нарушению работоспособности алгоритма.
77
2. Устанавливается набор моделей исходных данных u1,…,um , поступающих на обработку.
В качестве моделей данных могут приниматься, например, независимые случайные
величины со средним xср
и дисперсией s , имеющие гауссовские распределения
(сравни с вычислением опорных данных в предыдущем параграфе); независимые случайные величины, имеющие равномерные распределения на интервале ( L, L) ; линейно изменяющаяся последовательность с интерсептом (отрезком, отсекаемым на оси
ординат линейной зависимостью) b1 и наклоном b2 и т.д.
3. Вычисляются (оцениваются) значения характеристик алгоритмов (программ) на выбранных типовых моделях.
4. Результаты таких оценок представляются в виде таблиц (либо в каком-то другом подходящем виде) значений характеристик алгоритма в зависимости от используемых моделей исходных данных.
5. Оформляется документ об испытаниях алгоритма (программы), включающий указанные таблицы.
Таким образом, видно, что испытания ПО в соответствии с МИ 2174 сводятся к
оценке искажений, вносимых испытываемым ПО в модели исходных данных. В Приложении к методике приведены примеры испытаний простых алгоритмов: алгоритма вычисления усеченного среднего и алгоритма вычисления медианы в упорядоченном наборе
данных.
В Разделе 3 методики содержатся рекомендации по выбору характеристик алгоритмов и программ. Представляет интерес более детальное рассмотрение этих характеристик, потому что это может оказаться полезным при составлении методик испытаний.
Характеристики предлагается разбивать на три группы:
характеристики точности, предназначенные для оценивания погрешностей результатов
измерений, получаемых при использовании алгоритма (программы);
характеристики устойчивости (надежности), которые задают область работоспособности
алгоритма (программы);
характеристики сложности, которые отражают трудоемкость вычислений или вычислительные затраты при однократном применении алгоритма (программы).
В свою очередь характеристики точности подразделяются на основные и вспомогательные. К основным характеристикам точности алгоритмов предлагается относить:
границы методической составляющей погрешности, обусловленной неидеальностью метода обработки результатов измерений;
78
границы систематических составляющих трансформированной погрешности (т.е. составляющей погрешности, обусловленной наличием погрешностей исходных данных, поступающих на обработку, и их преобразованием с помощью алгоритма (программы)) обработки результатов измерений;
СКО случайной составляющей трансформированной погрешности.
Что касается вспомогательных характеристик точности, то под ними понимаются
параметры погрешностей результатов обработки, отличные от основных характеристик
точности. При этом рекомендуется учитывать дополнительные составляющие погрешности результатов, обусловленные особенностями работы программы в конкретной вычислительной среде, в том числе:
округлением промежуточных результатов;
ограниченностью разрядной сетки;
дискретизацией по аргументу;
конечным числом итераций;
использованием конечных разложений вместо бесконечных рядов и др.
К числу основных характеристик устойчивости алгоритмов (программ) алгоритмов,
предлагается относить:
допустимое число или долю данных, которые могли бы содержать промахи (большие погрешности), не нарушающие работоспособность алгоритмов;
границы интервалов (областей) значений параметров исходных данных, в которых алгоритм работает без сбоев (грубых ошибок).
Основными характеристиками сложности алгоритмов являются показатели вычислительной сложности, определяемые числом типовых операций (арифметических и логических), необходимых для однократного вычисления по данному алгоритму. Этот показатель был актуален на начальных этапах использования вычислительной техники для обработки измерительной информации, когда скорость обработки информации была относительно невелика. В настоящее время этот показатель в значительной степени потерял
свою актуальность.
При испытаниях ПО модели исходных данных предлагается формировать как в виде сочетания полезных сигналов, так и в виде моделей погрешности исходных данных.
При этом модели полезных сигналов могут формироваться на основе постановки измерительной задачи с использованием уравнения измерений, сведений о свойствах входных
сигналов СИ и метрологических характеристик СИ. Модели погрешности исходных данных могут формироваться отдельно для случайных и систематических составляющих погрешности, а также с учетом возможных помех на входе и выходе СИ. Для случайных со79
ставляющих погрешности исходных данных могут приниматься модели в виде случайных
функций или последовательностей, имеющих определенные распределения (например,
гауссовское, равномерное, двойное экспоненциальное и т.п.), и/или в виде корреляционных функций. Для систематических составляющих погрешностей возможны модели в виде детерминированных функций или последовательностей (например, постоянной, линейной, синусоидальной и т.д.).
Методика выделяет три основных подхода к определению (оцениванию) характеристик алгоритмов (программ) на моделях исходных данных:
аналитический,
численный расчет показателей точности,
математическое моделирование (прежде всего статистическое).
В принципе, описанная процедура испытаний не требует наличия опорного ПО и
позволяет оценить свойства испытываемого ПО, а также степень его влияния на метрологические характеристики средств измерений. Проблема заключается в удачном выборе
характеристик алгоритма и таких моделей исходных данных, которые в максимальной
степени соответствовали бы той реальной измерительной задаче, которая решается конкретным ПО. Уже отмечалось, что и генерация опорных данных, и метод моделей исходных данных могут рассматриваться как разновидности одного и того же подхода к испытаниям ПО, который можно использовать в отсутствие опорного ПО.
К недостаткам рекомендации МИ 2174 можно отнести то, что в ней количественные характеристики качества программных продуктов приводятся в виде таблиц, интерпретация которых в ряде случаев не ясна.
Несмотря на некоторую структурную рыхлость методики и недостаток конкретных
примеров, поясняющих общие утверждения, эта методика может быть рекомендована как
основа для составления методики испытаний ПО. Более того, практика испытаний программных продуктов показала эффективность и действенность метода моделей исходных
данных для испытаний ПО, используемого в самых разных областях измерительной техники. В параграфе 5.1 был приведен пример использования метода моделей исходных
данных, в качестве которых выступали входные данные для программных продуктов,
формирующих SV потоки при испытаниях технических средств, осуществляющих передачу мгновенных значений измерений в соответствии с серией стандартов МЭК 61850. В
следующем параграфе рассмотрим пример использования метода генерации опорных
данных и метода моделей исходных данных для испытаний сложного программного обеспечения сканирующих зондовых микроскопов [36].
80
§ 6.3. Испытания программного обеспечения сканирующих зондовых микроскопов.
За последние 15–20 лет сканирующие зондовые микроскопы (СЗМ) стали широко
применять как средства измерений параметров рельефа поверхностей нанометрового диапазона (микроэлектронных компонентов, носителей информации, биосенсоров, нанотрубок и т. д.). Потребность в таких СИ очень велика, поскольку перечисленные нанотехнологические направления остро нуждаются в соответствующем метрологическом обеспечении.
Основная особенность СЗМ заключается в том, что они представляют собой полностью компьютеризированные системы. Изображения микрообъектов в них являются компьютерными изображениями, полученными после обработки входных сигналов при помощи довольно сложного программного обеспечения. Система поддержания предельно
малых расстояний между зондом СЗМ и рельефом поверхности по самому физическому
принципу действия таких приборов является автоматизированной и управляться программно. Все это неизбежно приводит к необходимости оценки соответствия ПО тем задачам,
которое оно призвано решать в таких СИ. В этой ситуации разработчики и изготовители
СЗМ, исходя из разных соображений (обеспечение высокого качества и конкурентоспособности выпускаемой продукции, поддержание должного уровня технической и технологической культуры, требования потребителей и т. д.), идут на проведение независимой
экспертизы ПО. Такая экспертиза была проведена в ФГУП «ВНИИМС» в рамках Системы
Добровольной Сертификации ПО СИ.
На сертификационные испытания было представлено следующее оборудование:
ПО «Nova P9»;
линейка СЗМ, состоящая из 12 моделей;
рельефные меры нанометрового диапазона семи типов, используемые для калибровки и
определения метрологических характеристик СЗМ как средств измерений линейных размеров в микро- и нанометровом диапазоне.
Программное обеспечение «Nova P9» предназначено для решения комплекса задач,
связанных с проведением измерений, обработки, визуализации и передачи информации с
использованием СЗМ. Это ПО реализует переход на более высокий уровень управления
нанотехнологическим оборудованием по сравнению с другими программными продуктами, применяемыми в СЗМ. В нем учитывается, что, с одной стороны, многие рутинные
операции должны быть автоматизированы, с другой, что разработчикам стандартного ПО,
управляющего СЗМ, сложно подстроиться под огромное количество разных операций,
производимых пользователями. Решением данных проблем стала разработка и внедрение
81
специального макроязыка в программу управления приборами. Скрипты (текстовые файлы), создаваемые на макроязыке, позволяют задать определенную стандартную последовательность процедур и запуска ее нажатием одной кнопки. Это значительно облегчает
управление СЗМ и повышает эффективность его работы. В программном продукте «Nova
Р9» использован макроязык Nova Power Script, поддерживающий синтаксис VBScript и
JScript.
При помощи «Nova Р9» можно выполнять следующие функции:
настройку оптической системы регистрации изгибов кантилевера (устройства для
размещения исследуемого образца);
получение и обработку частотных характеристик;
подвод образца к зонду;
сканирование поверхности образца;
обработку и анализ полученных данных;
проведение спектроскопических исследований;
модификацию поверхности образца (нанолитографию);
работу с устройствами нагрева образца;
исследование различных сигналов;
настройку датчиков перемещения сканера.
Большинство указанных выше операций относится к автоматизированному управлению различными режимами работы микроскопов. Понятно, что при испытаниях ПО
проверяют не все его части и функции, а в первую очередь метрологически значимые части. Отнесение частей ПО к метрологически значимым обязательно согласуется с Заказчиком испытаний.
Кроме описанного выше оборудования, для проведения испытаний была также
предоставлена программная документация в составе: «Справочное руководство Nova P9.
Программа управления СЗМ» и «Image Analysis 3.5. Модуль обработки изображений».
После ознакомления с оборудованием и документацией было признано, что этих
материалов достаточно для проведения испытаний ПО.
Далее была разработана и согласована с Заказчиком «Методика сертификационных
испытаний программного обеспечения «Nova P9» (далее – Методика). Помимо анализа
документации в Методику был включен раздел «Проведение экспериментальных исследований». В рамках этих исследований проводились функциональные проверки ПО, реализуемые с помощью как программных, так и аппаратных средств (испытательного оборудования), имеющие своей задачей инициацию проверяемых функций, при этом отклик
ПО на инициацию должен соответствовать описанному в документации.
82
Согласно требованиям стандарта [6] экспериментальные исследования ПО включали следующие этапы:
проверку идентификации, т. е. установление идентификационных признаков и проверку их соответствия признакам, заявленным в технической документации;
проверку разделения на метрологически значимые и незначимые части;
опробование и проверку функциональных возможностей;
установление уровня защищенности программного продукта и данных.
Для проверки функциональных возможностей ПО «Nova P9» был собран испытательный стенд, на оборудовании которого выставлялись тестовые данные, подающиеся на
вход ПО. Далее выборочно проверялись функции, заявленные в документации на испытываемый программный продукт. Остановимся более подробно на описании проверки функций обработки СЗМ - топограмм.
Одной из метрологически значимых частей ПО является модуль обработки изображений – топограмм. Важная функция этого модуля – обработка и исправление типичных
для СЗМ искажений изображения поверхности образца, связанных с физическими принципами его работы. Для этого в программе предусмотрены такие функции, как «вычитание» плоскости и поверхности второго порядка (фрагмента поверхности сферы) и устранение относительных сдвигов линий сканирования. Следует учесть, что указанные функции ПО применяются к изображениям, содержащим естественный шумовой фон.
«Вычитание» плоскости необходимо для устранения неплоскостности выставления
образца, а «вычитание» поверхности второго порядка – для устранения влияния на изображение образца изгибов пьезокерамической трубки , на которой находится образец. Понятно, что термин «вычитание» носит жаргонный характер, на самом деле речь идет об
учете воздействий указанных эффектов. Относительные сдвиги линий сканирования обусловлены изменением высоты зонда относительно образца в процессе обратного хода образца (зонда) при сканировании под влиянием различных случайных факторов.
Чтобы оценить возможности модулей ПО, учитывающих воздействие таких эффектов, в Методике предлагалось использовать метод моделей исходных данных [18]. Одним
из основных условий его применения является максимально адекватное соответствие модели исходных данных реально измеряемым образцам. В качестве таких образцов были
взяты линейные меры периода TGZ1 и высоты TGQ1, служащие для передачи единицы
длины и поверки (калибровки) сканирующих зондовых и растровых электронных микроскопов в диапазоне 10-8 – 10-4 м. Меры представляют собой совокупность периодических
структур прямоугольной геометрической формы каждого элемента рельефа на поверхности квадратной кремниевой монокристаллической пластины со стороной квадрата не бо83
лее 5 мм, поверхность которой ориентирована параллельно кристаллографической плоскости (100) (рисунок 9). Сами элементы рельефа меры выполнены из оксида кремния методом фотохимического травления пластин. Мера TGZ1 (рисунок 9, а) имеет трехмерный
прямоугольный рельеф («шашки»), с периодом Т = (3,00+0,01) мкм и высотой структуры h
= (0,0200+0,0015) мкм; мера TGQ1 (рисунок 9, б) обладает двухмерным прямоугольным
рельефом, с периодом Т и высотой h – теми же, что у меры TGQ1.
Рисунок 9, а. Схематическое изображение меры TGZ1. Трехмерный прямоугольный рельеф («шашки»). Период по осям X и Y 3,00±0,01 мкм. Высота структуры
0,020±0,0015 мкм.
Рисунок 9, б. Схематическое изображение меры TGQ1. Двумерный прямоугольный
рельеф. Период 3,00±0,01 мкм. Высота структуры 0,020±0,0015 мкм.
Метод моделей исходных данных было предложено реализовать с помощью специально разработанной вспомогательной программы (MDTGenerator), в которой можно было создавать файлы (модели исходных данных), моделирующие меры с заданными параметрами рельефа (Т, h) и содержащие характерные для СЗМ искажения изображений с известными параметрами (углом наклона плоскости, радиусом области сферы, дисперсиями
шума строк и фонового шума сканирования). Созданный таким образом «виртуальный»
рельеф (исходные данные) затем можно было исследовать с использованием испытываемого ПО, провести коррекцию изображений и по относительному отклонению измеренных параметров рельефа от известных исходных (модельных) значений сделать выводы о
возможностях данного программного продукта по коррекции изображений образцов.
84
Алгоритм работы генератора «виртуального» рельефа MDTGenerator сводится к
тому, что сначала массив данных заполнялся информацией, описывающей модельную
структуру с известными параметрами. При этом учитывались устанавливаемые пользователем программы-генератора значения периодов структуры, высоты выступов, размера
«виртуального» кадра, количества пикселов изображения и т. д. Затем для имитации искажений изображений в СЗМ этот массив данных последовательно подвергался соответствующим геометрическим преобразованиям.
Для имитации естественной зашумленности изображений в СЗМ в Методике применялась генерация опорных данных методом нуль-пространства [11].
Отметим, что сечение поверхности «виртуального» рельефа, о котором говорилось
выше, плоскостью ZX является кусочно-линейным, и описывается следующей зависимостью:
 0 при x   nT ;
nT  T 2  ;
z
h при x   nT  T 2;(n  1)T  ;
(37)
где h – высота выступов; T – период структуры; n  0,1,2... .
Зависимость (37) выступает и как модель исходных данных, и как априори известное решение измерительной задачи, знание которого является необходимым условием
применения метода генерации опорных данных [11].
Для каждой части меры зависимость (37) можно записать в векторном виде [11]:
z  Ab  r ,
где А – «затравочная» матрица, или матрица наблюдений по работе [11]; r – вектор остатков; b – вектор коэффициентов линейной зависимости;
x1 
1


1
x2 

A
при x   nT ; nT  T 2  ;
 ............. 


xm 
1
h
b  b1    при x   nT  T 2;(n  1)T  ;
0
 z1 
 
z
z   2 ;
 ..... 
 
 zm 
 r1 
 
r
r   2 ;
 .... 
 
 rm 
0
b  b 0    при x   nT ; nT  T 2  ;
0
m – число экспериментально измеренных (заданных при модельных расчетах) пар чисел
( z i , xi ), или объем выборки.
Как уже говорилось, компоненты ri вектора остатков являются набором случайных
чисел, учитывающим случайные отклонения экспериментально измеренных значений пар
85
( z i , xi ) от детерминированной зависимости (37), являющейся предметом определения в
задаче простой линейной регрессии. Решив методом нуль - пространства [11] задачу, в
данной постановке обратную простой линейной регрессии, т. е. задачу нахождения компонентов вектора остатков r по экспериментально измеренным (заданным) парам ( z i , xi ),
можно получить поверхность «виртуальной» меры с естественным шумовым фоном как
сумму незашумленной структуры (37) и совокупности случайных компонентов r .
Испытания ПО СЗМ проводились на предприятии – изготовителе микроскопов, а
его результаты изложены в «Протоколе сертификационных испытаний программного
обеспечения «Nova P9». Ограничимся их выборочным и кратким изложением. Прежде
всего, при проверке программной документации было установлено, что она удовлетворяет
требованиям стандартов [5, 6], при этом было рекомендовано дополнить документацию
разделом, содержащим описание реализованных методов защиты ПО и данных.
Как известно [4], к идентификационным признакам программного продукта относят его название, номер версии и контрольные суммы, рассчитанные для метрологически
значимых частей. Номер версии определяется с использованием интерфейса пользователя.
По согласованию с Заказчиком сертификации к метрологически значимым частям ПО были отнесены программные модули XYCalibration.dll и ZCalibration.dll, реализующие
функции обработки топограмм (устранение наклона, искажения и сдвига строк, различные
фильтрации) и калибровки микроскопа по осям X, Y и Z. При этом последняя функция
фактически представляет собой метод автоматического измерения параметров кремниевых структур TGZ1 и TGQ1 (периода и высоты) вдоль этих осей. Контрольные суммы для
указанных модулей, рассчитанные изготовителем по стандартному алгоритму MD5, имеют вид
XYCalibration.dll : 9eb48340c656f5e545923ec839d60040;
ZCalibration.dll : 081da6dd16f81d05ba3c54e1de1a0f0f.
Было также констатировано, что структура тестируемого программного продукта
характерна для автономного ПО СИ [5].
Из функциональных проверок остановимся только на результатах проверок сканирования поверхности образца и функции «вычитания» плоскости (устранения наклона образца). В соответствии с Методикой в окне «Scanning» СЗМ были выставлены начальные
условия и проведено сканирование поверхности тестового образца. В результате испытания установлено, что реализованная в ПО «Nova P9» функция сканирования поверхности
образца соответствует требованиям нормативной и технической документации. Сканер
осуществляет растровое перемещение зонда относительно образца, а в узлах растра происходит оцифровка измеряемых сигналов.
86
В соответствии с Методикой с помощью программы MDTGenerator была построена
поверхность с наклоном на угол 0,1 относительно осей X и Y. При значениях периода
структуры «виртуальной» меры, используемой, как уже говорилось, в качестве исходной
модели, в 3000 нм и высоты ступени 22 нм после «вычитания» наклона образца измеренные значения оказались равными 2998 нм и 21,85 нм, т. е. относительные отличия рассчитанных и опорных значений не превысили 0,07 % по периоду и 0,7 % по высоте. Отметим,
что значение отличия в 0,7 % по высоте не должно вызывать замечаний по поводу возможностей испытываемого ПО, поскольку измерение высот объектов в нанометровом
диапазоне длин представляет собой серьезную физическую и метрологическую проблему,
и получение таких отличий между опорными и тестовыми результатами на самом деле
является достижением. Поэтому на основании полученных данных результаты всех проведенных проверок были признаны положительными.
Наконец, при определении уровня защищенности ПО и данных было установлено,
что в испытываемом программном продукте реализованы журнал событий, режимы архивации и экспорта данных. Файлы «Nova P9» хранятся в бинарном виде, что делает невозможным несанкционированное изменение и воздействие на них без применения специальных программных средств. В соответствии с ГОСТ Р 8.883 [6] защищенность ПО СЗМ
относится к уровню «средний». При этом было рекомендовано для повышения уровня защиты осуществить авторизацию и разделение прав пользователей.
По результатам тестирования ПО «Nova P9» было принято решение о выдаче сертификата соответствия с Приложением, где кратко перечислены основные свойства и характеристики этого программного продукта, установленные в процессе испытаний.
Основной особенностью описанного тестирования ПО СЗМ является использование методов моделей исходных данных и генерации опорных данных. На самом деле
применение метода генерации опорных данных в данной задаче не является обязательным. Уже говорилось, что те же самые результаты (имитация шумов) могут быть получены более простым путем с использованием ГСЧ стандартных программных пакетов.
Применение методов испытаний, описанных выше, обусловлено тем, что разработать соответствующее опорное ПО не представлялось возможным из-за его сложности и
объемности. Приведенный пример испытаний программного продукта показывает, что
проблема оценки свойств и характеристик даже такого сложного ПО СЗМ может быть
успешно решена применением для этих целей метода моделей исходных данных.
В заключение отметим, что работа [36] в 2011 г. заняла первое место на конкурсе
молодых метрологов, проводимом КООМЕТ (региональной организацией МОЗМ), а ее
авторы С.С. Голубев и М.В. Козлов были признаны победителями этого конкурса.
87
§ 6.4. Испытания программного обеспечения средств измерений методом перекрестной проверки (кросс-валидации).
В задачах, решаемых программным обеспечением, часто возникает проблема подбора оптимальных модельно-зависимых параметров при применении различных моделей
аппроксимации/интерполяции. Даже в случае использования одного и того же метода аппроксимации/интерполяции можно получить разные результаты в зависимости от выбора
параметров модели. Выбор оптимальных параметров осуществляется в процессе исследования характера и структуры данных, при этом эффективным инструментом подбора модельных параметров в ряде случаев может служить метод перекрестной проверки (далее
кросс-валидации). Метод кросс-валидации или скользящего контроля широко используется в биоинформатике при распознавании образов, при оценке качества обучаемых моделей в кибернетике, а также в работах, связанных с многомерным статистическим анализом
в финансовой статистике. Как правило, этот подход используется в случаях, где целью является оценка того, насколько предсказывающая модель способна работать на практике.
Можно сказать, что метод кросс-валидации в определенном смысле может быть альтернативой методу наименьших квадратов.
В метрологии метод кросс-валидации применяется также при оценке адекватности
измерительных задач [37]. К сожалению, этот хорошо известный и широко используемый
метод оценки качества ПО не нашел своего отражения в ГОСТ Р 8.883 -2015. Восполняя
этот пробел, в предлагаемом учебном пособии рассматривается возможность применения
метода кросс-валидации для оценки значений модельно-зависимых параметров на примере использования цифровых технологий при обследовании качества передаваемой электроэнергии. Метод основан на проведении оценки для части данных, выбранных из основного набора по остальным данным с последующим вычислением погрешности оценки.
После оценок по всем наборам или выборкам оценивается также среднее значение полученных оценок. По нему сравниваются различные методы и выбираются наилучшие параметры модели.
Процедура кросс-валидации сводится к следующему [38]:
Исходная выборка данных 𝑋 𝐿 разбивается N различными способами на две непересекающиеся подвыборки
𝑋 𝐿 = 𝑋𝑛𝑚 ∪ 𝑋𝑛𝑘 ,
(38)
где 𝑋𝑛𝑚 - обучающая подвыборка длины m, 𝑋𝑛𝑘 - контрольная подвыборка длины k = L- m,
n=1,…,N.
88
Далее, для каждого разбиения n строится алгоритм вычисления модельных параметров сi, сj по правилу f (в качестве такового может выступать модельная функциональная зависимость в задаче регрессии или правило интерполяции), при этом аn и bn обозначают результаты применения построенного алгоритма для обучающей и контрольной
подвыборок, т.е.
𝑎𝑛 = 𝑓(𝑐𝑖 , 𝑋𝑛𝑚 ), 𝑏𝑛 = 𝑓(𝑐𝑗 , 𝑋𝑛𝑘 ),
(39)
что позволяет вычислить значение функционала качества 𝑄𝑛 = 𝑄(𝑎𝑛 , 𝑏𝑛 ), под которым
может пониматься, например, относительное отличие модельных параметров, оцененных
по обучающей и контрольной подвыборкам (см. ниже).
Среднее арифметическое значение 𝑄𝑛 по всем разбиениям называется оценкой
скользящего контроля. Различные варианты кросс-валидации отличаются видами функционала качества и способами разбиения выборки. Так, например, различают кроссвалидацию по блокам, валидацию последовательным случайным сэмплированием и поэлементную кросс-валидацию.
В качестве количественного критерия оценки качества, как уже отмечалось, может
быть использовано относительное расхождение между параметрами модели, описывающее на n-ом разбиении обучающую и контрольную подвыборки, т.е.
|𝑐 −𝑐 |
𝑄𝑛 = ( 𝑖𝑐 𝑗 ) 100%.
𝑗
(40)
Изложим метод кросс-валидации по K блокам для решения задачи подбора оптимальных модельно-зависимых параметров. В этом случае все имеющиеся данные разделяют на K частей (блоков) (см. рисунок 10). Обычно K задают равным 5 или 10 и говорят
о 5-кратной или 10-кратной кросс-валидации. Из K блоков один оставляется для тестирования модели (контрольная подвыборка), а остающиеся K-1 блок используются как тренировочный набор (обучающая подвыборка). Операция повторяется K раз, при этом каждый
из блоков используется один раз как тестовый набор. Полученные таким образом K результатов параметров качества усредняются и дают среднюю оценку. Преимущество такого способа оценки значений параметров в том, что все имеющиеся данные используются и
для тренировки, и для тестирования модели.
Выше отмечалось, что при разработке опорного программного обеспечения, используемого для тестирования ПО цифровых подстанций, применяются алгоритмы, позволяющие по считанным из потока мгновенным значениям (SV) тока или напряжения воспроизвести параметры, используемые при их генерации. В качестве таких параметров выступают среднеквадратичные значения (СКЗ) тока и напряжения I, U, опорная частота 𝜔
89
и фазовый угол сдвига 𝜑0. Для оценки качества получаемых параметров используется
описанный выше метод кросс-валидации.
Блок
Блок
1
2
…
…
Блок K-1
Блок K
Контрольная
Обучающая подвыборка
Шаг 1
Блок
1
2
Блок
Блок
1
2
.
.
подвыборка
…
…
Блок K-1
Блок K
Q1
…
…
Блок K-1
Блок K
Q2
.
.
.
.
.
.
.
.
.
.
Шаг K- Блок
Блок
…
…
Блок K-1
Блок K
QK-1
1
1
2
Шаг K
Блок
Блок
…
…
Блок K-1
Блок K
QK
1
2
Шаг 2
Блок
Точность
1
Итоговая оценка точности 𝐾 ∑𝐾
𝑖=1 𝑄𝐾
Рисунок 10. Кросс-валидация по К блокам
Для испытаний был выбран генератор SV сообщений, разработанный одной из производящих такие генераторы компаний. Через программный интерфейс были заданы
опорные значения для генерации сигнала: I=5А, частота 50Гц, начальная фаза колебаний
74 град (1.291543646… рад). По результатам работы генератора был получен массив данных, часть которых (4000 мгновенных значений тока) была взята в качестве исходной выборки. Далее, в соответствии с алгоритмом кросс-валидации по 10 блокам, исходная выборка была поделена на 10 непересекающихся частей и сформированы обучающие (тренировочный набор) и контрольные подвыборки (тестовый набор) размером по 400 элементов. На следующем этапе из 10 блоков один оставался для тестирования модели, а
оставшиеся 9 блоков использовались как тренировочный набор. Операция повторялась 10
раз, на каждом из этапов осуществлялось вычисление исходных параметров (I, 𝜔, 𝜑0) и
относительного расхождения (параметра качества) 𝑄𝑛 между параметрами тренировочно-
90
го и тестового наборов. Результаты вычислений приведены в Таблице 4. Там же приводится средняя оценка параметров качества.
Таблица 4
Тренировочный
Тестовый набор
Расхождение
набор
1
СКЗ, А
Относительное
расхождение, %
4.998653817307
4.998653836284
0.000000018977
0.000000379648
Гц
49.997490280142
49.997325641753
0.000164638389
0.000329294391
Угол, рад
1.292513352564
1.300401172688
0.007887820124
0.606568210647
СКЗ, А
4.998655225241
4.998641164857
0.000014060385
0.000281284138
Гц
49.997190783005
49.997597431419
0.000406648414
0.000813335910
Угол, рад
1.292693203324
1.298821352437
0.006128149113
0.471823865669
СКЗ, А
4.998652095121
4.998669335933
0.000017240813
0.000344908041
Гц
49.997190795560
49.997324967998
0.000134172438
0.000268359233
Угол, рад
1.292872478413
1.297241698427
0.004369220015
0.336808477541
СКЗ, А
4.998655893115
4.998635153970
0.000020739146
0.000414896172
Гц
49.997190795761
49.997596389939
0.000405594178
0.000811227353
Угол, рад
1.293051048677
1.295669756476
0.002618707799
0.202112288715
СКЗ, А
4.998653770850
4.998654254397
0.000000483547
0.000009673542
Гц
49.997190803531
49.997401679321
0.000210875790
0.000421773498
Угол, рад
1.293230916623
1.294084389389
0.000853472766
0.065951863186
СКЗ, А
4.998654304327
4.998649453102
0.000004851225
0.000097050708
Гц
49.997190801292
49.997518312943
0.000327511651
0.000655055815
Угол, рад
1.293409963122
1.292513391196
0.000896571926
0.069366548309
СКЗ, А
4.998653555487
4.998656192668
0.000002637182
0.000052757813
Гц
49.997190784091
49.997324539457
0.000133755366
0.000267525047
Угол, рад
1.293588036186
1.290948178751
0.002639857436
0.204489806721
СКЗ, А
4.998654527498
4.998647444559
0.000007082939
0.000141697107
Гц
49.997190800054
49.997324322568
0.000133522514
0.000267059319
Угол, рад
1.293768041443
1.289359774203
0.004408267240
0.341895825207
Частота,
2
Частота,
3
Частота,
4
Частота,
5
Частота,
6
Частота,
7
Частота,
8
Частота,
91
9
СКЗ, А
4.998652096204
4.998669326181
0.000017229976
0.000344691260
Гц
49.997190774347
49.997595398545
0.000404624198
0.000809287316
Угол, рад
1.293947770562
1.287780650507
0.006167120055
0.478895225866
СКЗ, А
4.998652906895
4.998662029984
0.000009123088
0.000182510609
Гц
49.997490553166
49.997324062304
0.000166490862
0.000332999546
Угол, рад
1.294091626586
1.286198603529
0.007893023058
0.613670628785
Среднее относительное расхождение
СКЗ, А
0.000186984904
Среднее относительное расхождение
Частота, Гц
0.000497592
Среднее относительное расхождение
Угол, рад
0.339158274
Частота,
10
Частота,
Из полученных результатов можно сделать предварительный вывод, что алгоритм
вычисления фазового угла сдвига, скорее всего, нуждается в доработке, т.к. точность его
воспроизведения может быть недостаточна для ряда метрологических задач.
§ 6.5. Анализ исходного кода программного обеспечения средств измерений.
Для полноты следует рассмотреть еще один метод испытаний ПО, который редко
используется на практике. Это испытание ПО на основе анализа исходного кода. Проверка
требований к ПО на основе анализ исходного кода содержится в рекомендации WELMEC
7.2 [9], когда речь идет о требованиях высокого класса риска – риска класса Е. Конкретное содержание испытаний с использованием анализа исходного кода в значительной степени определяется целями, которые ставятся при таких испытаниях.
Метод обладает как определенными достоинствами, так и недостатками.
К достоинствам метода следует отнести его надежность и возможность получения
ответа на большинство поставленных при испытаниях ПО СИ вопросов, таких, например,
как правильность реализации и соответствия алгоритмов тем, что заявлены в документации, правильность реализации средств защиты ПО СИ и данных, правильность выполнения разделения ПО СИ, правильность генерации идентификации ПО СИ и т.д..
К недостаткам метода относятся его дороговизна, поскольку требуются большие
временные затраты и значительные человеческие ресурсы, необходимость в высокой квалификации специалистов, неприменимость в случае отсутствия доступа к исходному коду
или из-за его чрезвычайной сложности и запутанности.
Для проведения анализа исходного кода необходимо, чтобы Заявитель был готов
предоставить на исследование исходный код программы или часть кода, при этом может
быть заключено соглашение о соблюдении конфиденциальности. Неготовность или не92
желание Заявителя пойти на анализ исходного кода является основным препятствием для
его широкого использования при испытаниях ПО, которое часто оправдывается наличием
проблем с авторскими правами.
Необходимо также соблюдение следующих условий:
объем исходного кода должен быть невелик;
испытываемое ПО используется для решения ответственных задач, например в системах
обеспечения технической, противопожарной, химико-радиационной и экологической безопасности;
все другие методы испытаний не применимы или недоступны;
имеются подозрения или данные о наличии «закладок»;
организация может себе позволить использовать, по сути, неограниченные людские и финансовые ресурсы.
Анализ исходного кода применим к любому виду ПО и программное обеспечение
средств измерений здесь не исключение. В соответствии с рекомендацией МИ 2891 – 2004
[28] при анализе исходного ПО СИ осуществляются следующие проверки.
Таблица 5
Вид проверки
Описание
Соответствие структуры алгорит-
При проверке соответствия структуры алгоритмов представленной
мов представленной документации
документации, по тексту программы могут быть составлены блоксхемы реализуемых алгоритмов, которые сравниваются с алгоритмами, изложенными в документации. В случае нахождения различий в
структуре алгоритмов проводится дополнительный анализ элементов
блок-схем, в которых обнаружены различия.
Правильность записи алгоритмов
Проверяется правильность записи алгоритмов на выбранном языке
на выбранном языке программи-
программирования. При этом устанавливается соответствие кода пра-
рования
вилам программирования, наличие неопределенных переменных и
операторов, правильность организации циклов и т.д.
Адекватность
выбранных
ритмов измерительной задаче
алго-
Соответствие выбранных алгоритмов измерительной задаче может
быть осуществлено путем математического анализа программно реализованных алгоритмов. При этом могут исследоваться логические и
точностные характеристики реализованных алгоритмов, в частности,
анализироваться пригодность и оптимальность примененных численных методов решения измерительной задачи.
93
В дополнение к сказанному, в зависимости от условий испытаний и требуемой глубины анализа исходного кода ПО СИ зарубежными нормативными документами, например [9], рекомендовано осуществлять следующие проверки:
проверку достаточности методов идентификации ПО;
проверку достаточности методов идентификации пользователей ПО;
проверку корректности исполнения алгоритмов;
проверку отсутствия в интерфейсе пользователя недокументированных возможностей;
проверку соответствия команд управления тем, что заявлены в документации;
проверку отсутствия недокументированных команд управления;
проверку достаточности примененных методов проверки целостности ПО;
проверку достаточности примененных методов проверки целостности сохраняемых данных;
проверку достаточности методов проверки целостности передаваемых данных;
проверку достаточности методов защиты интерфейсов настройки ПО;
проверку достаточности методов защиты ПО и данных от несанкционированных изменений;
проверку достаточности методов оценки подлинности данных;
проверку отсутствия недокументированных потоков данных между метрологически значимыми и иными частями ПО;
проверку достаточности и правильности функций поиска, отображения и хранения данных;
проверку достаточности методов защиты сохраняемых данных;
проверку однозначности определения потоков данных, относящихся у управляющим командам испытуемого ПО;
проверку достаточности методов защиты журналов событий или их аналогов;
проверку достаточности методов отслеживания процесса обновления испытуемого ПО и
данных;
проверку достаточности методов защиты от потери данных при их передаче;
проверку достаточности и правильности функционирования процедур сохранения информации.
6.4.1. Виды анализа исходного кода
Среди множества способов анализа исходного кода на практике выделяют три основных: инспекция кода вручную, статический и динамический анализы.
94
Инспекция кода вручную.
Данный подход считается самым эффективным с точки зрения полноты и точности
проверки. При его использовании осуществляется так называемое юнит-тестирование, т.е.
тестирование, при котором исходный код разбивается на мелкие кусочки (юниты) и они
тестируется по отдельности.
Понятно, что только эксперт способен обнаружить сложные уязвимости и замаскированные программные «закладки», а также дать рекомендации по исправлению уязвимостей или ограничению возможности их реализации.
К недостаткам метода относят высокую трудоемкость и высокие требования к квалификации и опыту экспертов. Для исключения субъективизма в работе экспертов, могут
быть привлечены независимые группы тестирования, что является еще более затратным.
Статический анализ.
В этом случае анализ исходного кода ПО производится без реального выполнения
исследуемых программ. В большинстве случаев анализ производится над какой-либо версией исходного кода, хотя иногда анализу подвергается какой-нибудь вид объектного кода.
В зависимости от используемого инструмента глубина анализа может варьироваться от определения поведения отдельных операторов до анализа, включающего весь имеющийся исходный код. Способы использования полученной в ходе анализа информации
также различны – от выявления мест, возможно содержащих ошибки, до формальных методов, позволяющих математически доказать какие-либо свойства программы (например,
соответствие спецификации).
Статический анализ кода заключается в использовании средств автоматизации поиска и анализа потенциально опасных конструкций кода в исходном коде программы. Метод эффективен при поиске несложных уязвимостей и немаскируемых «закладок», таких
как переполнение буфера, парольные константы или логические «бомбы». К автоматизированным средствам проведения статистического метода относят сканеры уязвимостей
кода PREfix, PREfast, АК-ВС, UCA, FlawFinder, ITS4, RATS, FxCop. Использование
средств автоматизации позволяют сократить время проверок в десять-двадцать раз.
К недостаткам метода относят то, что результаты строго ограничены набором
предварительно определенных шаблонов известных классов уязвимостей. Кроме того,
может быть получено огромное количество ложных срабатываний, что снижает производительность труда. Перспективным направлением развития сканеров уязвимостей кода
является внедрение элементов эвристического (приближенного метода, позволяющего с
95
определенной вероятностью предположить наличие уязвимостей) анализа потенциально
опасных операций.
Динамический анализ.
Под динамическим анализом понимается анализ ПО при помощи выполнения программ на реальном или виртуальном процессе. Утилиты динамического анализа могут
требовать загрузки специальных библиотек, перекомпиляцию программного кода. Некоторые утилиты могут инструментировать исполняемый код в процессе исполнения или
перед ним. Для большей эффективности динамического анализа требуется подача тестируемой программе достаточного количества входных данных, чтобы получить более полное использование кода.
Динамический анализ заключатся в мониторинге действия программы при выполнении различных функций, связанных с безопасностью: инсталляции, изменении прав,
пересылке паролей, очистке памяти и др. Наиболее известны процедуры мониторинга работы программы и анализ трассы, а также ручной просмотр в отладочном режиме работы
подсистемы безопасности.
На практике, динамические методы часто экспертами игнорируются по причине
длительности процесса тестирования при отсутствии гарантий выявления нарушений безопасности.
96
Глава 7. Испытания программного обеспечения при испытаниях средств измерений
с целью утверждения типа.
Самый распространенный вид испытаний программного обеспечения в настоящее
время это его испытания при испытаниях СИ с целью утверждения типа. В самом деле,
ежегодно в Государственный реестр средств измерений вносится от 2700 до 3400 средств
измерений, прошедших такие испытания. Большинство из них представляют собой автоматизированные устройства и системы, включающие в себя достаточно сложное программное обеспечение, или сопровождающиеся им. Порядок проведения таких испытаний
программного обеспечения, как уже отмечалось, регламентируется приказом Минпромторга от 30 ноября 2009 г. № 1081 [2].
В Приложении 1 к этому приказу говорится о том, что заявка на проведение испытаний СИ должна содержать, в частности, сведения о наличии программного продукта,
используемого для получения результатов измерений. При его наличии в программе испытаний должны устанавливаться алгоритмы обработки полученных при испытаниях результатов, предусматриваться идентификация программного обеспечения и оценка его
влияния на метрологические характеристики средства измерений, а также анализ конструкции испытываемого средства измерений на наличие ограничений доступа к программному обеспечению с целью предотвращения несанкционированной настройки и
вмешательства, которые могут привести к искажению результатов измерений. При наличии обязательных требований к программному обеспечению программа испытаний должна предусматривать проверку их выполнения.
Указанные требования к испытаниям ПО при проведении испытаний СИ с целью
утверждения типа конкретизированы в методике МИ 3290-2014 [39] и рекомендациях
Р 50.2.077-2014 [4]. Эти нормативные документы при своем внедрении в практику испытаний ПО СИ встретили определенное сопротивление со стороны разработчиков, производителей и распространителей СИ, поскольку это приводило к удорожанию и усложнению процедуры испытаний СИ. Некоторые проблемы, возникшие при внедрении указанных документов в испытательную практику (на них в учебном пособии останавливаться
не будем), отражены в работе [40]. В этой работе также описаны основные особенности
рекомендаций Р 50.2.077. Они сводятся к следующему:
1. Методология испытаний ПО, использованная в рекомендациях Р 50.2.077, практически полностью основана на методологии рекомендации WELMEC 7.2. При этом
структура документа осталась такой, как и в прежней редакции 2010 г. Из текста
документа во избежание повторов там, где это нужно, убрано слово «обеспечение»,
97
добавлены и переформулированы некоторые термины и определения. Теперь документ называется: Рекомендации по метрологии Р 50.2.077-2014 ГСИ. Испытания
средств измерений в целях утверждения типа. Проверка защиты программного
обеспечения.
2. Метрологически значимая часть программного обеспечения определена следующим образом - программы и программные модули, выполняющие обработку измерительной информации и реализующие функции по идентификации и защите ПО
СИ.
3. Изменен подход к проблеме испытаний программного обеспечения, который в
большей степени приведен в соответствие с практикой, изложенной в международных рекомендациях, а именно разработчик (изготовитель, заявитель) должен декларировать полноту документации, отсутствие недекларированных возможностей
и уровень защиты программного обеспечения, а задача аккредитованной организации - провести работу по установлению соответствия СИ декларации, в том числе
заявленному уровню защиты ПО, и зафиксировать это в описании типа СИ. Это,
пожалуй, самая значительная особенность настоящей редакции рекомендаций.
4. В подразделах «Проверка идентификации и защиты ПО СИ» в явном виде выделены проверки документации и функциональные проверки. Сформулированы требования к документам на ПО СИ и скорректирована форма Протокола проверки защиты программного обеспечения.
5. Основными характеристиками программного обеспечения, проверяемыми при испытаниях с целью утверждения типа СИ, является его защита, точнее, ее уровень
(низкий, средний и высокий) и идентификация. Определены случаи, когда проверку защиты ПО и оценку ее уровня допускается не проводить. Поскольку этот случай представляет значительный интерес, воспроизведем его полностью: «Для СИ,
конструкция и/или особенности эксплуатации которых обеспечивают полное ограничение доступа к метрологически значимой части ПО и измерительной информации (наличие механической защиты и отсутствие программно-аппаратных интерфейсов связи), проверку защиты ПО СИ и оценку ее уровня допускается не проводить. В таких случаях, в описании типа СИ следует вносить запись: «Конструкция
СИ исключает возможность несанкционированного влияния на ПО СИ и измерительную информацию»».
6. Поскольку документ посвящен описанию только проверки защиты программного
обеспечения ПО, то из него убрано упоминание об оценке влияния программного
обеспечения на метрологические характеристики СИ. Это вовсе не означает, что
98
такую оценку не следует проводить. Проведения такой оценки, как уже неоднократно отмечалось, требует приказ Минпромторга от 30 ноября 2009 г. № 1081.
При этом возможен случай, когда такую оценку можно не проводить, например,
тогда, когда экспериментальные исследования метрологических характеристик СИ,
проводимые совместно с программным обеспечением, могут показать, что эти МХ
находятся в пределах допуска.
При обсуждении рекомендаций были высказаны предложения о необходимости
введения понятия класса риска для требований к СИ, как это сделано в рекомендации
WELMEC 7.2. Это предложение не было принято, поскольку механизм введения этого понятия не отработан. Кроме того, введение классов риска в обязательные требования при
испытаниях СИ может привести к неоправданному усложнению процедуры испытаний. В
результате обсуждения остановились на варианте, когда глубина проверки уровня защиты
определяется разработчиками СИ и Заявителями испытаний в зависимости от их предполагаемой области применения.
В Приложениях 2 и 3 пособия приводятся примеры протоколов реальных испытаний программного обеспечения при испытаниях СИ с целью утверждения типа. Первый
протокол относится к испытаниям встроенного ПО (Приложение 2), второй – к испытаниям автономного ПО (Приложение 3). Эти протоколы имеют отношение только к испытаниям программного обеспечения СИ. Протоколы примечательны тем, что они наглядно
представляют как содержательную часть испытаний, так и их документальное оформление.
В принципе, к этим протоколам, при желании, можно сделать ряд замечаний.
Например, одно из них сводится к тому, что в обоих протоколах в явном виде отсутствуют
оценки влияния ПО на МХ соответствующих средств измерений. По всей видимости, в
процессе экспериментального определения метрологических характеристик соответствующих СИ было установлено, что их МХ, как было отмечено выше в п. 6 особенностей рекомендаций Р 50.2.077-2014, находятся в пределах допуска. Это означает отсутствие влияния ПО на метрологические характеристики СИ, однако это обстоятельство нигде в явном виде не обозначено.
В протоколе, относящимся, к испытаниям ПО АСКУЭ, отмечено, что выделение
метрологически значимой части не проведено разработчиком ПО, тем не менее, контрольные суммы по метрологически значимым частям рассчитаны. Для полноты следовало бы отметить, кто и на каком этапе испытаний выделил метрологически значимые файлы, по которым в дальнейшем были рассчитаны контрольные суммы.
99
Тем не менее, приведенные протоколы могут служить примером проведения и
оформления испытаний программного обеспечения при испытаниях средств измерений с
целью утверждения типа.
Контрольные вопросы к Главам 6 и 7.
1. Что такое регрессионный анализ?
А) Анализ вырождения функциональных зависимостей, Б) Анализ причин появления умственно отсталых детей, В) Регрессионный анализ объединяет круг задач,
связанных с построением функциональных зависимостей между двумя группами
числовых переменных: x1 ,..., xm и y1 ,..., ym , Г) Анализ причин экономического спада.
2. Для каких целей используется метод генерации опорных данных при испытаниях
ПО СИ?
3. Что такое нуль-пространство матрицы наблюдений (затравочной матрицы)?
4. Какие данные могут использоваться в качестве моделей исходных данных? Каково
основное требование, предъявляемое к моделям исходных данных?
5. Какова структура программного обеспечения сканирующих зондовых микроскопов?
А) Программное обеспечение имеет сложную структуру, Б) Программное обеспечение не обладает структурой, достойной обсуждения, В) Программное обеспечение в большинстве случаев состоит из части, осуществляющей автоматическое
управление средством измерений и/или его фрагментами, и части для обработки и
представления измерительной информации, Г) Структура, в основном, состоит из
частей, поощряющих правильные и грамотные действия оператора.
6. Какие данные использовались в качестве моделей исходных данных при испытанях ПО сканирующих зондовых микроскопов?
7. В чем заключается метод перекрестной проверки при испытаниях ПО СИ
8. Перечислите основные виды анализа исходного кода ПО. В чем заключаются их
достоинства и недостатки?
9. Какие виды проверок ПО должны проводиться при испытаниях СИ с целью утверждения типа?
10. Что должен декларировать Заявитель при представлении ПО СИ на испытания с
целью утверждения типа?
11. Следует ли поверителю проводить испытания ПО, если идентификационные дан100
ные ПО соответствуют тем, что занесены в описании типа?
12. В каких случаях при испытаниях с целью утверждения типа проверку уровня защиты ПО можно не проводить?
101
Приложение 1.
Коэффициенты устойчивости для некоторых алгоритмов (по материалам работы
[11]).
В этом Приложении кратко изложены математические аспекты ряда утверждений,
содержащихся в § 4.2 пособия.
Предположим, что связь между входом x и выходом y измерительной системы
описываются математической моделью (уравнением измерений)
y  f (x ) ,
где f
(1.П)
обозначает векторную функциональную зависимость между входом и выходом.
Эта зависимость может быть разного вида сложности, в частности, она может быть и
неявной.
Пусть
x
обозначает малое возмущение входного воздействия, а
y
-
соответствующую реакцию выхода. Тогда относительный коэффициент устойчивости
модели (далее коэффициент устойчивости) определяется формулой
k (x) 
где символ a
y
x
y
x
(2.П)
,
обозначает норму (длину) вектора a .
Как уже говорилось в тексте пособия, под нормой вектора a понимают
неотрицательное действительное число
a  (a  a ) .
В скобках стоит скалярное
произведение вектора a самого на себя. В частности, если вектор проведен из начала
координат в точку с координатами ( a1 , a2 , a3 ), то норма такого вектора может быть
вычислена по формуле a  a12  a22  a32 . Известно, что норма вектора наряду с другими
свойствами удовлетворяет неравенству Коши - Буняковского (a  b )  a  b .
Коэффициент устойчивости характеризует относительное изменение выхода
системы по отношению
к соответствующему
относительному изменению входа.
Приращение функции (1П) с точностью до членов первого порядка малости
записывается в виде
y  f ( x  x )  f ( x )  J ( x )  x,
(3П)
где функциональная матрица J (x ) определяется формулой
106
 f1
 x ...
 1
 f1 ...
f i
J ( x)  (
)
  x 2
x k P0 
.........
 f1
 x ...
 n
f m 
x1 

f m 
x 2  .

...... 
f m 
x n  P
(4П)
0
В самом деле, пусть имеется вектор входных величин x  {x1 , x2 ,..., xn } и пусть этот
вектор определяет функциональный вектор f (x ) = { f1 ( x1 ,..., xn ),..., f m( x1 ,..., xn )}. Если
функция f дифференцируема в т. P0 ( x10 ,..., xn0 ), то функциональная матрица (4П) имеет
размер n  m. В случае, когда n = m определитель этой матрицы J  det(
f i
) называется
x k
якобианом функции f .
С учетом (3П) формула (2П) может быть записана в виде
J ( x )  x
k (x) 
y
x

J ( x )  x
x
y
x

J (x)  x
y
.
(5П)
x
При записи (5П) было использовано неравенство Коши – Буняковского.
Пусть теперь
y (r ) обозначает опорный отклик, соответствующий входному
воздействию x (отклик на выходе опорного ПО при воздействии входных данных x ).
Предполагается, что опорное ПО реализует правильное
устойчивого алгоритма.
исполнение оптимально
Для устойчивых алгоритмов коэффициент обусловленности
принимает значение порядка единицы.
Напомним, что алгоритм называется
устойчивым, если
для любого   0
существует   0 такое, что при погрешности входных данных, меньшей , максимальная
погрешность выходных данных будет меньше ..
Далее предполагается, что y (t ) – отклик, производимый испытываемым ПО, и пусть
y  y
(t )
y
(r )
.
Из (2П) следует
x 
y
x
y
k (x)

(r )
,
(6П)
где x - возмущение (погрешность) входных данных.
107
Из определения устойчивого алгоритма следует, что при оценке его устойчивости
необходимо определить значение отклика y на минимальное изменение внешнего
воздействия
x , например, такое, когда
x    x ,
где  - относительная
вычислительная точность, которая, как уже отмечалось, в большинстве случаев порядка
10-16. Другими словами, «качество» алгоритма (по отношению к проблеме устойчивости)
количественно может быть оценено его реакцией y на минимальное изменение входных
величин. Такое изменение может, например, возникать при преобразовании входных
данных от десятичной системы в двоичную, и наоборот.
Для опорного ПО можно ожидать, что если
x
 x
 O(1),
(7П)
то, как следует из (6П),
y
1
 ( r )  O(1),
k ( x )  y
(8П)
где О(1) – величина порядка единицы.
Если же для испытываемого ПО отношение в левой части формулы (8П)
оказываются порядка O(10 p ) при том, что входные данные удовлетворяют условию (7П),
это означает, что, как уже отмечалось, тестируемое ПО теряет при вычислениях p
значащих десятичных цифр по сравнению с эталонным. Число потерянных цифр p
можно определить с помощью исполнительной характеристики
P ( x )  lg(1 
y
1
 (r) ) .
k ( x ) y
(9П)
В самом деле, если второе слагаемое под знаком логарифма оказывается порядка
10 p , то даже в самом неблагоприятном случае, когда p  1 , единицей под знаком
логарифма можно пренебречь по сравнению с десятью, и в общем случае с большой
степенью точности можно написать, что
P( x )  lg(10 p )  p.
(10П)
Если же вычислительные возможности испытываемой и опорной программ
совпадают, то y  0, и, следовательно, P( x )  0, т.е. p  0 и никакой потери цифр не
происходит.
С учетом (5П) выражение для исполнительной характеристики (9П) может быть
записано в виде
108
y
P( x )  lg(1 
Получим
аналитические
выражения
J ( x )  x 
для
).
коэффициентов
(11П)
устойчивости
и
исполнительных характеристик некоторых часто используемых в метрологии алгоритмов.
1. Среднее квадратичное отклонение (СКО).
Как известно, квадрат СКО S 2 вычисляется по формуле
n
 (x  x)
S 2  i 1
2
i
(12П)
,
(n  1)
где среднее значение x результатов измерений xi
x
1 n
 xi .
n i 1
(13П)
С учетом (12П) и (13П) можно показать, что
S xi  x

.
xi
nS
Функциональная
(14П)
матрица зависимости (12П) с учетом (14П) может быть
вычислена и записана в виде столбца (вектора)
x1  x
J (x) 
1 x2  x
,
nS ..........
xn  x
(15П)
где вектор результатов измерений имеет вид x  ( x1 , x2 ,..., xn ) .
Норма функциональной матрицы (вектора)
J (x) 
1
nS
n 1
.
n
n
 (x  x) 
2
i 1
i
(16П)
Подставляя это выражение в (5П) и учитывая выражение для нормы вектора
результатов измерений x 
n
 x , а также то, что СКО S (выход функциональной
i 1
зависимости
(12П))
является
2
i
числом,
для
соответствующего
коэффициента
обусловленности получаем выражение
n
k (x) 
n 1

n
x
i 1
S
2
i
.
(17П)
Поскольку, как это следует из (12П),
109
n
 x  (n  1)S  nx ,
i 1
2
i
2
2
то после несложных преобразований получаем следующее выражение для квадрата
коэффициента обусловленности (17П)
 n  1   n  1  x 
k ( x)  
 
  .
 n   n  S 
2
2
2
(18П)
Видно, что первое слагаемое в этом выражении является константой, зависящей от
объема выборки. При больших объемах это слагаемое с большой точностью равно
x
единице. Второе слагаемое зависит от отношения   и равно нулю, когда x  0. Таким
S
образом, при больших объемах выборки значение коэффициента устойчивости в
основном определяется значением указанного отношения и может быть оптимизировано
его подбором.
В работе [11] показано, что коэффициент устойчивости определяет так называемую
степень трудности алгоритма, при этом степень трудности алгоритма вычисления СКО
при фиксированном эталонном значении S дается выражением
x
k ( S )  max{ ,1}.
S
(19П)
Исполнительная характеристика для СКО получается подстановкой формулы (18П)
в выражение (9П).
2. Простая линейная регрессия.
Как уже отмечалось, формальное решение задачи простой линейной регрессии
может быть записано в виде
b  A1 y,
(20П)
где матица A1 является в общем случае псевдообратной по отношению к матрице A .
Изложение деталей теории матриц не входит в задачи пособия.
Интересующимся
математическим обоснованием связи теории линейных уравнений с задачей линейной
регрессии и, в частности, понятием псевдообратной матрицы, можно порекомендовать,
например, монографию Г. Стренга [41].
Вектор остатков r , как это следует из формулы (20), имеет вид
r  y  Ab .
Если решение задачи линейной регрессии определяется формулой (20П), то
выражение для вектора остатков записывается в виде
r  ( I  AA1 ) y,
(21П)
110
где I - единичная матрица.
При таком подходе вектор остатков является функцией выходного вектора y
измерительной системы. Соответствующая функциональная матрица имеет вид (см. (4П))
J ( y)  (
При нахождении выражения
ri
)  I  AA1.
yk
(22П)
для коэффициента устойчивости необходимо
вычислить норму этой матрицы.
Понятие нормы матрицы является более сложным, чем нормы вектора и тесно
связано с коэффициентом устойчивости [41].
По
определению,
нормой
матрицы
A
A  max
Ax
называется
число,
определяемое
соотношением
при x  0 .
x
Из этого определения следует, что норма матрицы
(23П)
A
измеряет значение
наибольшего изменения векторов при умножении их на эту матрицу.
В соответствии с определением (23П) норма матрицы (22П) записывается в виде
J ( y )  max
( I  AA1 ) y
y
.
Максимум этого выражения достигается тогда, когда второе слагаемое в числителе будет
минимальным по сравнению с первым. Это означает, что с большой точностью можно
записать
J ( y) 
y
y
 1.
(24П)
Таким образом, с учетом этого результата искомый коэффициент устойчивости
(5П) имеет вид
k ( y) 
y
r
(25П)
.
Получившееся выражение можно интерпретировать как отношение сигнал/шум для
измеренных данных.
С учетом (25П) соответствующая исполнительная характеристика может быть
записана в виде
P( y )  lg(1 
r
).
y 
(26П)
111
Приложение 2.
ПРОТОКОЛ ИСПЫТАНИЙ В ЦЕЛЯХ УТВЕРЖДЕНИЯ ТИПА
Проверка защиты программного обеспечения средства измерений
Испытатель
Заявитель
Наименование средства
измерений
Изготовитель
Дата проведения
испытаний
Место проведения
испытаний
Методика проведения
испытаний
Испытания провели
Федеральное государственное унитарное предприятие
«Всероссийский научно-исследовательский институт
метрологической службы» (ФГУП «ВНИИМС»)
119361, г. Москва, ул. Озёрная, д. 46
Тел.: +7 (495) 781-86-03; Факс: +7 (495) 781-86-03
ООО «N»
Адрес Заявителя
Счетчики статические активной электрической энергии
«МС-301»
ООО «N»
Адрес изготовителя
Федеральное государственное унитарное предприятие
«Всероссийский научно-исследовательский институт
метрологической службы» (ФГУП «ВНИИМС»)
119361, г. Москва, ул. Озёрная, д. 46
«Счетчики статические активной электрической энергии
«МС-301». Программа испытаний в целях утверждения
типа», раздел 5.
____________________
Результаты испытаний
1 Проверка документации
1.1 Перечень документации, предъявленной для проверки
Нумерация таблиц в Приложениях оставлена такой, какой была в протоколах.
Таблица 1
№
1
2
3
Наименование
Счетчики статические активной электрической энергии
«МС-301». Технические условия.
Счетчики статические активной электрической энергии
«МС-301». паспорт.
Счетчики статические активной электрической энергии
«МС-301». Руководство по эксплуатации.
Обозначение
ТУ 4228-022088900941-2014
--НСКП.411152.022РЭ
112
1.2 Проверка документации в части программного обеспечения
Таблица 2
Требования
1
Наименование ПО, обозначение его
версии и/или версий его модулей
Описание назначения ПО, его
структуры и выполняемых функций
Описание метрологически
значимой части ПО
Описание методов генерации
идентификации ПО
Описание способов визуализации
идентификации ПО и инструкции
по идентификации
Список (перечень) защищаемых
параметров и описание средств их
защиты от несанкционированного
доступа к ним
Описание интерфейсов
пользователя, меню и диалогов
Описание интерфейсов связи ПО
для передачи, обработки и хранения
данных
Описание реализованных методов
защиты ПО и результатов
измерений
Описание способов хранения
результатов измерений на
встроенном, удалённом или
съёмном носителях
Описание требуемых для работы
СИ системных и аппаратных
средств
Результаты
проверки
2
Примечания*
3
Присутствует
НСКП.411152.022РЭ
Присутствует
НСКП.411152.022РЭ
Присутствует
НСКП.411152.022РЭ
Присутствует
НСКП.411152.022РЭ
Присутствует
НСКП.411152.022РЭ
Присутствует
НСКП.411152.022РЭ
Присутствует
НСКП.411152.022РЭ
Присутствует
НСКП.411152.022РЭ,
ТУ 4228-022-088900941-2014
Присутствует
НСКП.411152.022РЭ
Присутствует
НСКП.411152.022РЭ
Присутствует
НСКП.411152.022РЭ
Не
проверялось
2 Проверка идентификации ПО
Наличие исходного ПО
2.1 Идентификационные данные ПО
Таблица 3
Идентификационные данные (признаки)
1
Идентификационное наименование ПО
Значение
2
НСКП.411152.022ПО
Номер версии (идентификационный номер)
ПО
Цифровой идентификатор ПО
D6ADECA2
1.01
113
2.2 Функциональные проверки ПО
Таблица 4
Содержание проверки
Результаты проверки
Описание процедуры
1
2
3
Проверка способов идентификации,
заявленных
в
технической
Соответствует
НСКП.411152.022РЭ
документации на ПО
Проверка
независимости
Альтернативные способы
идентификационных
данных
Не проверялось
идентификации
(признаков)
от
способов
отсутствуют
идентификации
Проверка наличия и достаточности
идентификационных
данных
Соответствует
п. 5.2.2.2 Р 50.2.077-2014
(признаков)
3 Проверка защиты ПО от непреднамеренных и преднамеренных
изменений
3.1 Функциональные проверки защиты ПО от непреднамеренных
изменений
Таблица 5
Результаты
Содержание проверки
Описание процедуры
проверки
1
2
3
Проверка наличия средств защиты
ПО и измерительной информации
от изменения или удаления в случае Соответствует п. 5.3.2.3 Р 50.2.077-2014
возникновения случайных
воздействий
Проверка наличия средств,
После имитации случайного
информирующих об изменении или
изменения измерительной
удалении метрологически значимых
информации должно
файлов ПО и измерительной
Соответствует индицироваться сообщение об
информации
ошибке, в журнале событий
должна появиться
соответствующая запись
Проверка наличия и правильности
функционирования журналов
Соответствует ТУ 4228-022-088900941-2014
регистрации ошибок
Проверка наличия мер от
несанкционированного входа в
калибровочный режим,
Соответствует ТУ 4228-022-088900941-2014
позволяющего изменить значения
калибровочных констант в памяти
СИ
114
3.2 Функциональные проверки защиты ПО от преднамеренных
изменений
Таблица 6
Содержание проверки
1
Проверка наличия средств защиты,
исключающих возможность
несанкционированных модификации,
загрузки, считывания из памяти,
удаления или иных преднамеренных
изменений метрологически значимой
части ПО и измерительной
информации
Проверка наличия процедур проверки
целостности ПО и отсутствия ошибок
Проверка соответствия алгоритма,
используемого для расчета
контрольных сумм, описанным в
документации процедурам
Проверка правильности
функционирования средств
обнаружения и фиксации событий
Проверка соответствия полномочий
(способов доступа) пользователей,
имеющих различные права доступа к
ПО и измеренным данным, заявленным
в технической документации на ПО СИ
Проверка корректности и
правильности реализации управления
доступом пользователя к функциям ПО
и измеренным данным
Результаты
проверки
2
Описание процедуры
3
Соответствует п.5.3.2.4 Р 50.2.077-2014
После подачи питания
проверяется наличие в журнале
Соответствует событий сообщения об
успешном выполнении
самодиагностики
Соответствует НСКП.411152.022РЭ
Соответствует ТУ 4228-022-088900941-2014
Соответствует ТУ 4228-022-088900941-2014
Соответствует ТУ 4228-022-088900941-2014
4 Выводы по результатам проверки
Программные функции, значимые структуры данных и интерфейсы
метрологически значимой части ПО представлены полностью в документации.
Уровень защиты встроенного ПО Счетчиков статических активной электрической
энергии «МС-301» соответствует уровню «средний» по Р 50.2.077-2014.
115
Приложение 3.
Протокол испытаний № 7
Системы автоматизированной информационно-измерительной
коммерческого учета электроэнергии (АИИС КУЭ)
ОАО «М»,
зав. № 001
Проверка защиты программного обеспечения
Испытатель
Федеральное Государственное Унитарное Предприятие «Всероссийский
Научно-Исследовательский Институт Метрологической Службы» (ФГУП «ВНИИМС»)
наименование
119361, г. Москва, ул. Озерная, д. 46
почтовый адрес, юридический адрес
ЗАО «…»
Изготовитель
наименование
…
почтовый адрес
…
юридический адрес
с 12.10.2015 по 16.10.2015 г.
Дата проведения испытаний
указывается дата проведения испытаний
…
Место проведения испытаний
наименование
…
фактический адрес организации, где проводились испытания
116
Методика проведения испытаний
Система автоматизированная информационно-
измерительная коммерческого учета электроэнергии (АИИС КУЭ) ОАО «М».
Программа испытаний в целях утверждения типа.
наименование программы и методики испытаний,
Раздел 7. Оценка защиты и идентификация программного обеспечения
номер и наименование раздела, в котором установлены методы испытаний
Результаты испытаний
Цель испытаний:
Оценка
защиты
и
идентификация
программного
обеспечения
системы
автоматизированной
информационно-измерительной
коммерческого
учета
электроэнергии (АИИС КУЭ) ОАО «М» (далее - ПО АИИС КУЭ) и апробирование
методики подтверждения соответствия ПО АИИС КУЭ при поверке.
7.1 Проверка документации
7.1.1 Перечень документации, предъявленной для проверки
Результаты проверки предъявленного перечня документации в соответствии с
программой и методикой испытаний приведены в таблице 1.
Таблица 1
№
Наименование
Обозначение
1
Ведомость эксплуатационной документации
300-05-07/11.00.000 ВЭ
2
Формуляр
300-05-07/11.00.000 ФО
3
Технологическая инструкция
300-05-07/11.00.000 ТИ
4
Руководство пользователя
300-05-07/11.00.000 РП
5
Инструкция по формированию и ведению базы данных
300-05-07/11.00.000 ИФ
6
Инструкция по эксплуатации
300-05-07/11.00.000 ИЭ
7
Перечень входных данных
300-05-07/11.00.000 ВХД
8
Перечень выходных данных
300-05-07/11.00.000ВЫД
Заключение: Результаты проверки положительные, предъявленный для проверки
перечень документация в соответствии с программой и методикой испытаний представлен
в полном и достаточном объеме.
117
7.1.2 Проверка документации в части программного обеспечения АИИС КУЭ
Результаты проверки документации в части ПО АИИС КУЭ приведены в таблице 2.
Таблица 2
Требования
+/-
1
Наименование ПО АИИС КУЭ,
обозначение его версии и/или версий
его модулей
Описание назначения ПО, его
структуры и выполняемых функций
2
3
«Программное обеспечение «Альфа-Центр».
+
Руководство пользователя
Описание метрологически значимой
частей ПО АИИС КУЭ
«Программное обеспечение «Альфа-Центр».
+ Руководство пользователя
Описание методов генерации
идентификации ПО АИИС КУЭ
Описание способов визуализации
идентификации ПО АИИС КУЭ и
инструкции по идентификации
Список (перечень) защищаемых
параметров и описание средств их
защиты и несанкционированного
доступа к ним
+
Документация
«Программное обеспечение «Альфа-Центр».
Руководство пользователя
«Программное обеспечение «Альфа-Центр».
+ Руководство пользователя
+
«Программное обеспечение «Альфа-Центр».
Руководство пользователя
+
«Программное обеспечение «Альфа-Центр».
Руководство пользователя
Описание интерфейсов пользователя,
«Программное обеспечение «Альфа-Центр».
+
меню и диалогов.
Руководство пользователя
Описание интерфейсов связи ПО
АИИС КУЭ для передачи, обработки
и хранения данных
+
«Программное обеспечение «Альфа-Центр».
Руководство пользователя
Описание реализованных методов
защиты ПО АИИС КУЭ и
результатов измерений.
+
«Программное обеспечение «Альфа-Центр».
Руководство пользователя
Описание способов хранения
результатов измерений на
встроенном, удалённом или съемном
носителях.
+
«Программное обеспечение «Альфа-Центр».
Руководство пользователя
118
Описание требуемых для работы ПО
«Программное обеспечение «Альфа-Центр».
АИИС КУЭ системных и аппаратных +
Руководство пользователя
средств
Наличие исходного ПО
-
-
Заключение: Результаты проверки положительные, предъявленная на проверку
документация в части ПО АИИС КУЭ представлена в полном и достаточном объеме,
удовлетворяет общим требованиям к документации программного обеспечения по
ГОСТ Р 8.654-2009 «ГСИ. Требования к программному обеспечению средств измерений.
Основные положения».
7.2 Проверка идентификации ПО АИИС КУЭ
7.2.1 Проверка идентификационных данных ПО АИИС КУЭ
Результаты проверки идентификационных данных ПО АИИС КУЭ, подлежащие
внесению в описание типа АИИС КУЭ, приведены в таблице 3.
Таблица 3
Идентификационное
наименование
ПО
Наименование
файла
Номер
версии
ПО
Цифровой
идентификатор ПО
(контрольная сумма
исполняемого кода)
Программа –
планировщик
опроса и
передачи
данных
Amrserver.exe
4.10.4.0
2330c0c35c97de61be2746
02e315c3df
Драйвер
ручного опроса
счетчиков и
УСПД
Amrс.exe
4.10.4.2
5af3f894fe65fb575791ca1
54cb427d1
Алгоритм
вычисления
цифрового
идентификатора
ПО
MD5
Драйвер
автоматическог
о опроса
счетчиков и
УСПД
Amra.exe
4.2.1.0
9cf3f689c94a65daad982ea
4622a3b96
Драйвер
работы с БД
Cdbora2.dll
4.10.0.0
eaff6e949f33c19514f47f2
8bbaa1e41
Библиотека
шифрования
encryptdll.dll
2.0.0.0
0939ce05295fbcbbba400e
119
пароля
счетчиков
eae8d0572c
Библиотека
сообщений
планировщика
опросов
b8c331abb5e34444170eee
9317d635cd
alphamess.dll
Заключение:
Результаты
проверки
положительные,
идентификационное
наименование, номер версии (идентификационный номер) и цифровой идентификатор
программного обеспечения соответствуют заявленным.
7.2.2 Функциональные проверки ПО АИИС КУЭ
Результаты проведенных функциональных
испытания ПО АИИС КУЭ, приведены в таблице 4.
проверок,
предоставленного
на
Таблица 4
Вид проверки
Результат проверки
Проверка способов идентификации,
заявленных в технической
Реализованные способы идентификации ПО
документации на ПО
соответствуют заявленным в технической
Проверка реализованных способов документации на ПО АИИС КУЭ.
идентификации ПО
Проверка независимости
Идентификационные данные (признаки) не зависят
идентификационных данных
от способа идентификации.
(признаков) от способов
идентификации
Проверка наличия и достаточности Идентификационные данные (признаки) достаточны
идентификационных данных
для однозначной идентификации ПО.
(признаков).
Заключение: Результаты проверок положительные, функциональные проверки
программного обеспечения соответствуют заявленному.
7.3 Проверка защиты ПО АИИС КУЭ от непреднамеренных и преднамеренных
изменений.
7.3.1 Функциональные проверки защиты ПО АИИС КУЭ от непреднамеренных
изменений.
Результаты
функциональных
проверок
защиты
ПО
АИИС
КУЭ
от
непреднамеренных изменений приведены в Таблице 5
120
Таблица 5
Функциональные проверки защиты метрологически значимых файлов ПО и
измерительной информации от случайных или непреднамеренных изменений
Вид проверки
Результат проверки
1
2
Средства защиты ПО АИИС КУЭ и
измерительной информации от изменения
или удаления в случае возникновения
Проверка наличия средств защиты ПО АИИС случайных воздействий соответствуют
заявленным в технической документации
КУЭ и измерительной информации от
на ПО АИИС КУЭ. При этом:
изменения или удаления в случае
возникновения случайных воздействий.
- в процессе работы ПО осуществляется
периодическая проверка наличия и
целостности метрологически значимых
файлов ПО АИИС КУЭ;
информирующие об изменении
Проверка наличия средств, информирующих Средства,
- осуществляется проверка целостности
или удалении метрологически значимых
об изменении или удалении метрологически
измерительной информации.
файлов ПО АИИС КУЭ и измерительной
значимых файлов ПО АИИС КУЭ и
информации соответствуют заявленным в
измерительной информации
технической документации на ПО АИИС
КУЭ.
Реализованный в ПО АИИС КУЭ журнал
регистрации ошибок соответствует
Проверка наличия и правильность
заявленному в технической документации
функционирования журналов регистрации
на ПО АИИС КУЭ, кроме того
ошибок
средствами базового ПО ОС и СУБД
осуществляется протоколирование
ключевых событий, происходящих в
системе.
Заключение: Результаты проверок положительные, защита метрологически
значимых файлов ПО и измерительной информации от случайных или непреднамеренных
изменений соответствует заявленному в технической документации на ПО АИИС КУЭ.
7.3.2 Функциональные проверки защиты ПО АИИС КУЭ от преднамеренных
изменений
Результаты функциональных проверок защиты ПО АИИС КУЭ от преднамеренных
изменений приведены в Таблице 6.
121
Таблица 6
Функциональные проверки защиты метрологически значимых файлов ПО и
измерительной информации от преднамеренных изменений
Вид проверки
Результат проверки
1
2
Наличие
средств
защиты,
исключающих
Проверка наличия средств защиты,
возможность несанкционированных
исключающих возможность
несанкционированных модификации, загрузки, модификации, загрузки, считывания из
памяти, удаления или иных
считывания из памяти, удаления или иных
преднамеренных изменений
преднамеренных изменений метрологически
метрологически значимых файлов ПО и
значимых файлов ПО АИИС КУЭ и
измерительной информации
измерительной информации.
соответствуют заявленным в технической
документации
на ПО
АИИС КУЭ.
Наличие процедур
проверки
целостности
Проверка наличия процедур проверки
целостности ПО АИИС КУЭ и отсутствия
ошибок.
Проверка, предусматривающая расчет
контрольных сумм ПО АИИС КУЭ.
Проверка правильности функционирования
средств обнаружения и фиксации событий.
ПО и отсутствия ошибок соответствуют
заявленным в технической документации
на ПО АИИС КУЭ.
Алгоритм, используемый для расчета
контрольных сумм ПО АИИС КУЭ,
соответствуют описанным в технической
документации на ПО АИИС КУЭ.
Правильность функционирования средств
обнаружения и фиксации событий
соответствуют заявленным в технической
документации на ПО АИИС КУЭ.
Соответствие полномочий (способов
доступа) пользователей, имеющих
Проверка соответствие полномочий (способов
различные права доступа к ПО АИИС
доступа) пользователей, имеющих различные
КУЭ и измерительной информации
права доступа к ПО АИИС КУЭ и
соответствуют заявленным в технической
измерительной информации.
документации на ПО АИИС КУЭ.
Корректность и правильность реализации
Проверка корректности и правильности
управления доступом пользователя к
реализации управления доступом пользователя функциям ПО АИИС КУЭ и
к функциям ПО АИИС КУЭ и измерительной измерительной информации
информации.
соответствуют заявленным в технической
документации на ПО АИИС КУЭ.
122
Заключение: Результаты проверок положительные, защита метрологически
значимых файлов ПО и измерительной информации от преднамеренных изменений
соответствует заявленному в технической документации на ПО АИИС КУЭ.
7.4 Выводы по результатам проверок
Результаты проверок уровня защиты ПО АИИС КУЭ от непреднамеренных и
преднамеренных изменений согласно с
Р 50.2.077-2014 «ГСИ. Испытания средств
измерений в целях утверждения типа. Проверка защиты программного обеспечения»
соответствует уровню «высокий».
7.5 Апробирование методики подтверждения соответствия ПО АИИС КУЭ при
поверке.
7.5.1 Методика подтверждения соответствия ПО АИИС КУЭ при поверке
При проведении поверки АИИС КУЭ выполняют операцию «Подтверждение
соответствия программного обеспечения».
Операция «Подтверждение соответствия программного обеспечения» состоит из
следующих этапов:
- определение идентификационного наименования ПО АИИС КУЭ и номера
версии (идентификационного номера) ПО АИИС КУЭ;
-
определение цифрового идентификатора (контрольной суммы исполняемого
кода) ПО АИИС КУЭ.
7.5.1.1 Определение идентификационного наименования и номера версии
(идентификационного номера) ПО АИИС КУЭ.
Для определения идентификационного наименования и номера версии ПО АИИС
КУЭ проверяют информацию, приведенную в строке меню «Справка» основного окна
ПО «АльфаЦЕНТР».
Результат
определения
идентификационного
наименования
считать
положительным, если идентификационное наименование и номер версии программного
обеспечения соответствует данным, указанным в разделе «Программное обеспечение»
описания типа средства измерений.
123
7.5.1.2
Определение
цифрового
идентификатора
(контрольной
суммы
исполняемого кода) ПО АИИС КУЭ.
Для определения цифрового идентификатора (контрольной суммы исполняемого
кода) программного обеспечения ПО АИИС КУЭ проверяют цифровые идентификаторы
его
компонентов
наименование
(модулей),
программного
перечисленных
обеспечения»
в
столбце
таблицы
3,
«Идентификационное
которые
относятся
к
метрологически значимым.
Для определения цифровых идентификаторов необходимо выполнить запуск
менеджера файлов, позволяющий производить хэширование файлов (Unreal Commander
v0.96).
Цифровые идентификаторы должны соответствовать тем идентификаторам,
которые перечислены в столбце «Цифровой идентификатор программного обеспечения
(контрольная сумма исполняемого кода)» таблицы 3 настоящего протокола.
Результат подтверждения соответствия ПО считается положительным, если
полученные
идентификационные
данные
ПО
АИИС
КУЭ
(идентификационные
наименования ПО, номер версии (идентификационный номер) ПО и цифровые
идентификаторы ПО) соответствуют идентификационным данным, указанным в разделе
«Программное обеспечение» описания типа средства измерений.
7.5.1.3 Результаты апробирования методики подтверждения соответствия ПО
АИИС КУЭ приведены в таблице 7.
Таблица 7
Вид проверки
Определение
идентификационного
наименования ПО
Результат проверки
Идентификационные наименования ПО и
программных компонентов (модулей) ПО АИИС КУЭ
перечислены в столбце «Идентификационное
наименование программного обеспечения» таблицы 3
настоящего протокола. Результаты апробирования
соответствуют методике подтверждения соответствия
ПО АИИС КУЭ при поверке.
Номер версии ПО АИИС КУЭ – 4.10.
Определение номера версии
Результаты апробирования соответствуют методике
(идентификационного номера) ПО подтверждения соответствия ПО АИИС КУЭ при
поверке.
124
Определение цифрового
идентификатора (контрольной
суммы исполняемого кода) ПО
Цифровые идентификаторы (контрольные суммы
исполняемого кода) предоставленных программных
компонентов ПО АИИС КУЭ перечислены в столбце
«Цифровой идентификатор программного
обеспечения (контрольная сумма исполняемого
кода)» таблицы 3 настоящего протокола. Результаты
апробирования соответствуют методике
подтверждения соответствия ПО АИИС КУЭ при
поверке.
7.6 Заключение по результатам проверки обеспечения защиты ПО АИИС КУЭ
Результаты
положительными.
проверки
обеспечения
защиты
ПО
АИИС
Установленных идентификационных
однозначной идентификации ПО.
данных
(признаков)
КУЭ
признаны
достаточно
для
Уровень защиты ПО АИИС КУЭ от непреднамеренных и преднамеренных
изменений соответствует уровню защиты - уровень «высокий». Метрологически значимая
часть ПО АИИС КУЭ и измеренные данные достаточно защищены с помощью
специальных средств защиты от преднамеренных изменений.
Сведения об уровне защиты ПО АИИС КУЭ вносят в описание типа АИИС КУЭ.
Результаты апробирования методики подтверждения соответствия ПО АИИС КУЭ
соответствуют методике подтверждения соответствия ПО АИИС КУЭ при поверке.
125
Список литературы.
1. Федеральный закон Российской Федерации от 26 июня 2008 г. № 102-ФЗ «Об
обеспечении единства измерений».
2. Порядок проведения испытаний стандартных образцов или средств измерений в
целях утверждения типа (утвержден Приказом Министерства промышленности и
торговли Российской Федерации от 30 ноября 2009 г. № 1081).
О внесении изменений в Порядок утверждения типа стандартных образцов или типа средств измерений, Порядок выдачи свидетельств об утверждении типа стандартных образцов или типа средств измерений, установления и изменения срока
действия указанных свидетельств и интервала между поверками средств измерений, утвержденные приказом Минпромторга России от 30 ноября 2009 г. № 1081
(утвержден приказом Минпромторга России от 30 сентября 2011 г. № 1326).
3. Административный регламент по предоставлению Федеральным агентством по
техническому регулированию и метрологии государственной услуги по утверждению типа стандартных образцов и или типа средств измерений (утвержден Приказом Минпромторга России от 25 июня № 970).
4. Рекомендации Росстандарта Р 50.2.077-2014 «ГСИ. Испытания средств измерений
в целях утверждения типа. Проверка защиты программного обеспечения».
5. ГОСТ Р 8.654-2015 «ГСИ. Требования к программному обеспечению средств измерений. Основные положения».
6. ГОСТ Р 8.883-2015 «ГСИ. Программное обеспечение средств измерений. Алгоритмы обработки, хранения, защиты и передачи измерительной информации. Методы
испытаний».
7. ГОСТ Р ИСО/МЭК ТО 12182-2002 «Информационная технология. Классификация
программных средств».
8. С.А. Кононогов, С.С. Голубев, В.Г. Лысенко. Исследование измерительных и калибровочных возможностей средств измерений нанометрового диапазона. Законодательная и прикладная метрология. № 3, 2008 г.
9. WELMEC 7.2. Руководство по программному обеспечению (основано на Директиве по измерительным приборам 2014/32/EU), 2015.
10. B.D. McCullough. Assessing the Reliability of Statistic Software: Part I. The American
Statistician, v. 52, N 4, 1998, 358-366
102
11. H.R. Cook, M.G. Cox, M.P. Dainton, P.M. Harris. Testing Spreadsheets and Other Packages Used in Mertrology. A Case Study. Report to National Measurements System Policy
Unit. September 1999.
12. U. Grottker, R. Schwartz. Software in legal metrology. OIML Bulletin, April 2003.
13. Рекомендация OIML D31: 2008. Общие требования к программно контролируемым
средствам измерений.
14. WELMEC 7.1. Требования к программному обеспечению на основе Директивы по
измерительным приборам. 2004. Издание 2.
15. ГОСТ Р ИСО/МЭК 17025-2006 «Общие требования к компетентности испытательных и калибровочных лабораторий».
16. Рекомендация КООМЕТ R/LM/10:2004 Программное обеспечение средств измерений. Общие технические требования.
17. ГОСТ Р 8.596-2002 «ГСИ. Метрологическое обеспечение измерительных систем.
Основные положения».
18. МИ 2174-91 «ГСИ. Аттестация алгоритмов и программ обработки данных при измерениях. Основные положения».
19. МИ 2955-2016 «ГСИ. Типовая методика испытаний и подтверждения соответствия
(сертификации) программного обеспечения средств измерений».
20. МИ 2517-99 «ГСИ. Метрологическая аттестация программного обеспечения
средств измерений параметров физических объектов и полей с использованием
компьютерных программ генерации цифровых тестовых сигналов».
21. МИ 2518-99 «ГСИ. Метрологическая аттестация алгоритмов и программ генерации
цифровых тестовых сигналов».
22. ГОСТ 19.202-78. ЕСПД. Спецификация. Требования к содержанию и оформлению.
ГОСТ 19.402-78. ЕСПД. Описание программы.
ГОСТ 19.502-78. ЕСПД. Описание применения. Требования к содержанию и
оформлению.
ГОСТ 19.401-78. ЕСПД. Текст программы. Требования к описанию и оформлению.
23. ГОСТ Р ИСО 5725-1 – 2002. «Точность (правильность и прецизионность) методов
и результатов измерений. Часть I. Основные положения и определения».
24. С.Ф. Левин. Статистические методы и метрологическая аттестация программного
обеспечения измерительных систем. Измерительная техника. № 11, 2008, 14-19.
25. Ю.А. Кудеяров, А.Ю. Мосолов, П.В. Тихонов, Ш.Р. Фаткудинова. Аттестация программного обеспечения хроматографических измерений – программы «Анализатор». Главный метролог, 2006, № 6.
103
26. ГОСТ 28195-89 (переиздание 2001 г.) «Оценка качества программных средств.
Общие положения».
27. ГОСТ Р ИСО/МЭК 9126-2004 (переиздание 2004 г.) «Информационная технология.
Оценка программной продукции. Характеристики качества и руководства по их
применению».
28. МИ 2891 – 2004 «ГСИ. Общие требования
к программному
обеспечению
средств измерений».
29. М.Н. Бурдунин, Ю.А. Кудеяров, А.Н. Паньков. Оценка качества программного
обеспечения счетчика – расходомера РМ-5 и счетчика количества теплоты КМ-5.
Главный метролог. 2007, № 3.
30. В.В. Киселев, Ю.А. Кудеяров, А.Н. Паньков. Программное обеспечение для испытаний технических средств, осуществляющих передачу мгновенных значений измерений в соответствии с серией стандартов МЭК 61850. Заводская лаборатория.
Диагностика материалов, № 8, том 82, 2016, 75-80.
31. Серия стандартов МЭК 61850 «Сети и системы связи на подстанциях».
32. Гольдштейн Е.И., Сулайманов А.О., Бацева Н.Л., Панкратов А.В. Устройство для
измерения фазового угла между напряжениями или токами. Патент РФ 2264631,
2005.
33. Келехсаев Б.Г. Способ определения частоты синусоидального сигнала. Патент РФ
2090897, 1997.
34. А.А. Дудыкин, Ю.А. Кудеяров, А.Н. Паньков. Проблемы аттестации встроенного
программного обеспечения средств измерений. Законодательная и прикладная метрология. 2007, № 1.
35. Ю.А. Кудеяров, А.А. Сатановский. Генерация эталонных данных методом нуль пространства для тестирования электронных таблиц, прикладных математических
пакетов и алгоритмов. Законодательная и прикладная метрология, № 2, 2005, 39-46.
36. С.С. Голубев, М.В. Козлов, Ю.А. Кудеяров. Тестирование программного обеспечения сканирующих зондовых микроскопов. Измерительная техника, № 6, 2012, 2125 (S.S. Golubev, M.V. Kozlov, Yu. A. Kudeyarov. Testing the software of scanning
probe microscopes. Measurement Techniques, vol. 55, issue 6, 2012, 622-629).
37. Р 50.2.004 – 2000 «ГСИ. Определение характеристик математических моделей зависимостей между физическими величинами при решении измерительных задач».
38. Ю.А. Кудеяров, А.Н. Паньков. Испытания программного обеспечения средств измерений методом перекрестной проверки (кросс-валидации). Главный метролог,
№ 6, 2015, 12-14.
104
39. МИ 3290-2014 «ГСИ. Рекомендация по подготовке, оформлению и рассмотрению
материалов испытаний средств измерений в целях утверждения типа».
40. Ю.А. Кудеяров, А.Н. Паньков. Новая
редакция рекомендаций по метрологии
Р 50.2.077-2013. Законодательная и прикладная метрология, 2014, № 2, 13-16.
41. Г. Стренг. Линейная алгебра и ее применения. – М; Мир, 1980, 454 стр.
105