авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 || 3 | 4 |   ...   | 7 |

«В.А. Слаев, А.Г. Чуновкина АТТЕСТАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, ИСПОЛЬЗУЕМОГО В МЕТРОЛОГИИ: СПРАВОЧНАЯ КНИГА Под редакцией доктора ...»

-- [ Страница 2 ] --

В документах, разработанных НФЛ, предлагается метод «нуль пространства» формирования «эталонных» данных. Входные «эталонные» данные формируются таким образом, чтобы «эта лонные» выходные данные оставались неизменными — так на зываемый метод «нуль-пространства». При таком подходе раз личным наборам (векторам) входных «эталонных» данных со ответствует единственный выходной набор (вектор) «эталон ных» данных. Рассмотрим его подробнее на примере задачи ли нейной регрессии. Предположим, что решается задача линейной регрессии: задан вектор y = [ y1 y2 K ym ] T результатов на блюдений, проводившихся в дискретные моменты времени xi, i = 1, m, при этом считаем, что результаты y i определяются ли нейной зависимостью yi = b1 + b2 xi + ri, i = 1, m, где b1,2 — пара метры, подлежащие оценке, ri — случайные ошибки, возникаю щие в процессе измерения. Перепишем систему уравнений в мат ричной форме:

y = Ab + r, (2.2) где A — матрица наблюдений, y — вектор результатов наблю дения, b — вектор параметров модели, r — вектор остатков;

1 x1 y1 r 1 x y 2, r = r2, b = b1.

A= y=, b M M M M 1 xm ym rm Известно, что решение задачи линейной регрессии по методу наименьших квадратов характеризуется тем, что AT r = 0.

Следовательно, m m ri = 0, xi ri = 0.

i =1 i = Пусть N — матрица, столбцы которой являются базисными векторами нуль-пространства матрицы AT, тогда AT N = 0. Пусть r = N u, тогда для различных векторов результатов наблюдения y и y + r получаем одинаковые значения параметров bi. Действи тельно, AT Ab = AT y и AT ( y + r ) = AT y + AT N u = AT y.

Таким образом, алгоритм построения тестовых наборов данных выглядит следующим образом:

1. вычисляется вектор результатов наблюдения y0 = Ab ;

2. строится матрица N, столбцы которой представляют собой базис нуль-пространства для матрицы AT ;

3. формируется вектор остатков r = N u, где элементы вектора u генерируются при помощи датчика случайных чисел;

4. проводится нормировка вектора r таким образом, чтобы он и его компоненты имели распределение с заданным средним значе нием и СКО;

5. формируется вектор результатов наблюдения y в соответст вии с формулой y = y0 + r.

Такой подход позволяет проконтролировать корректность при меняемого ПО, и для количественного выражения влияния ПО на точность результата вводятся следующие меры [36, 37], которые оцениваются по «эталонным» данным или сравнением с результа тами, получаемыми «эталонным» ПО.

• Абсолютные меры точности. Пусть y = y ( test ) y ( ref ), (2.3) где y (test ) — тестовые выходные результаты, а y ( ref ) — «эталон ные» выходные результаты, отвечающие «эталонному» входному вектору x.

Тогда величина d ( x ) = y n представляет собой абсо лютную меру отклонения тестового результата от «эталонного»

при «эталонном» входном векторе x.

• Относительные меры точности. Обозначим через M (x) число точных значащих цифр в «эталонных» результатах, от вечающих «эталонному» входному вектору x. Тогда число совпадающих цифр в результатах тестовых расчетов и «эта лонных» результатах вычисляется по формуле [32]:

y ( ref ), если M ( x) 0, 1 + (2.4) N ( x ) = min M ( x ), log10 y и N ( x) = M ( x) — в противном случае.

• Исполнительная характеристика — это величина y ( ref ) P ( x ) = log 10 1 +, (2.5) y ( x) где — вычислительная точность;

( x) — коэффициент обу словленности задачи, который представляет собой частное от де ления относительного изменения выхода на относительное изме y x нение входа: ( x ) =.

y x Исполнительная характеристика представляет собой число точ ных значащих цифр, «потерянных» в результате тестовых расчетов по сравнению с результатами, полученными программой, реали зующей оптимально устойчивый алгоритм. Для «эталонного» ПО { } предполагается, что y J ( x) x, где J ( x) = fi x j — якоби ан функции f(x).

Другими словами, «эталонное» ПО трактуется как полностью «прозрачный» ящик, для которого зависимость выходных данных от входных описывается функцией f(x). Дополнительные погреш ности, обусловленные «эталонным» ПО, — это только погрешно сти округления x x, где — относительная точность, и, следовательно, (x ) ( x ) r e f y ref =J x =J = x ref (2.6) = k ( x ) r e f y ref Если тестирование ПО выполнялось на основе «эталонных»

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

(x ) ( x ) te s t y lim =J x =J = x ref (2.7) = k ( x ) te s t y ref.

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

y y =.

k ( x ) test y ref y lim Следовательно, в (2.5) нужно использовать показатель вычис лительной точности «эталонного» или тестируемого ПО в зависи мости от способа тестирования.

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

Если все-таки необходимо количественно охарактеризовать вклад ПО в суммарную неопределенность, то можно предложить следующий способ. В результате тестирования получается набор расхождений { i }, которые соответствуют разным значениям входных величин. Эти значения выбираются таким образом, чтобы перекрывались диапазоны их изменения. Стандартная неопреде ленность, обусловленная реализацией ПО, может быть оценена max i как usoft =. Необходимо подчеркнуть, что эта оценка явля ется оценкой «сверху», а именно — суммарной оценкой несколь ких влияющих факторов, поскольку, например, невозможно выде лить составляющую неопределенности, обусловленную формиро ванием «эталонных» данных. Кроме того, если «эталонные» набо ры данных создавались независимо от реализованного в ПО алго ритма обработки, то расхождения между «эталонными» выходны ми значениями и значениями, полученными с помощью исследуе мого ПО, отражают не только неопределенность, привносимую ПО, но и методические погрешности алгоритма обработки данных.

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

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

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

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

Рис. 2.1. Схема обобщенного тестирования 2.1.5. Выводы В итоге можно резюмировать, что решение задачи оценивания точности результата измерения, полученного с использованием ПО, целесообразно разбить на три этапа в соответствии с этапами оценивания основных составляющих неопределенности.

1. На первом этапе проводится проверка корректности уравне ния измерения (2.1) и его соответствия конкретной измерительной задаче. Другими словами, проводится валидация, т. е. определение пригодности, модели измерения. Если принимаются какие-либо упрощения модели, то оценивается обусловленная этими прибли жениями неопределенность конечного результата. Следует отме тить, что если измерения проводятся по аттестованной методике выполнения измерений, то задача первого этапа уже была решена при разработке и аттестации МВИ.

2. На втором этапе выполняют оценивание «трансформирован ной» неопределенности результата измерения по неопределенно стям входных данных. Способ оценивания выбирают в зависимо сти от вида (нелинейности) уравнения измерений.

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

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

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

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

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

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

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

2. как обеспечить полноту тестирования, поскольку тестирова ние — это проверка в отдельных точках, а результаты тестирова ния — это распространение полученных при тестировании оценок на весь диапазон варьирования параметров.

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

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

2.2.1. Схема аттестации алгоритмов обработки экспериментальных данных при измерениях Ниже кратко излагается схема метрологической аттестации ал горитмов обработки данных при измерениях. Методология атте стации алгоритмов и программ обработки данных была разработа на во ВНИИМ им. Д.И. Менделеева около двадцати лет тому назад [17]. Аттестацией называется исследование алгоритма обработки на унифицированных моделях исходных данных с целью опреде ления характеристик его точности, надежности и сложности.

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

Для группы алгоритмов A = {a} придерживаются следующей последовательности этапов:

1) установление показателей алгоритма 1,..., n, которые бу дут использоваться для сопоставления и обоснованного выбора алгоритмов в группе A;

2) выбор тестовых моделей исходных данных, поступающих на вход алгоритма: 1,..., m, которые соответствуют рассматривае мой измерительной задаче;

3) оценка значений характеристик алгоритма на типовых моде лях исходных данных:

ij (a) = i (a, j ), i = 1... n, j = 1... m.

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

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

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

Модели исходных данных, т. е. тестовые модели, являются комбинацией моделей полезных сигналов и моделей шума. Выбор моделей полезных сигналов базируется на уравнении измерения.

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

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

2.2.2. Аттестация алгоритмов определения информативных параметров аналитических сигналов (Пример) В качестве иллюстрации применения методологии аттестации алгоритмов обработки данных при измерениях рассмотрим атте стацию алгоритмов определения информативных параметров сиг налов количественного химического анализа (КХА), которые час то называют аналитическими. Алгоритм определения информа тивного параметра сигнала КХА представляет собой последова тельность операций, производимых над выходным сигналом пер вичного измерительного преобразователя, с целью определения значения информативного параметра и оценивания его погрешно сти. Сигнал КХА — это выходной сигнал первичного преобразо вателя, несущий информацию, в частности, о качественном и ко личественном составе анализируемого вещества. Под информа тивными параметрами понимаются параметры сигнала КХА, по зволяющие идентифицировать качественный состав анализируе мой пробы, а также функционально связанные со значениями кон центраций определяемых компонентов. Примерами информатив ных параметров являются: время удерживания в хроматографии;

высота пика, площадь под пиком и др.

Среди составляющих погрешности алгоритма обычно выделяют:

– методические, которые обусловлены конкретной реализацией алгоритма обработки. Например погрешности, обусловленные приближенным выполнением арифметических операций, линеари зацией функций, дискретизацией КХА и др.;

– трансформированные, которые обусловлены погрешностями входных данных и их преобразованиями в ходе выполнения алго ритма. Трансформированные погрешности делятся на системати ческие и случайные. Например, к систематическим трансформиро ванным погрешностям следует относить погрешности, обуслов ленные наложением пиков при обработке хроматограмм и спек трограмм, а также погрешности, обусловленные нелинейностью выполняемых операций, к случайным — погрешности, обуслов ленные случайными погрешностями исходных данных и изме няющиеся случайным образом при повторной обработке другой реализации сигнала КХА.

Составляющие погрешности алгоритма характеризуются:

• методические — границами;

• систематические — границами или стандартной неопреде ленностью, оцененной по типу В;

• случайные — стандартной неопределенностью, оцененной по типу А.

При метрологической аттестации алгоритмов определения ин формативного параметра устанавливают модели: полезного сигна ла, фонового сигнала (дрейфа нуля), случайной помехи (шума).

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

• характеристики пика аналитического сигнала: симметричный или несимметричный;

одиночный или накладывающийся на другой пик;

гауссовский, лоренцовский или произвольной формы;

• априорную информацию о фоновом сигнале;

• сведения о характеристиках случайной помехи (уровень, спектральные характеристики, интервал корреляции и т. д.).

Модель полезного сигнала может быть представлена в виде:

m s (t ) = Ai g (t ti ), где g (t ) — нормированные импульсы.

В качестве моделей g (t ) обычно рассматривают:

– гауссовскую модель:

exp(t 2 / 2 2 ) — для симметричных пиков;

s (t ) = 2 exp(t / 21 ) t 2 s (t ) = для несимметричных 1 exp(t 2 / 2 2 ) t 2 2 пиков;

s (t ) = t 2 t / ;

– квадратичную модель s (t ) = 1/(1 + t 2 / 2 ), и др.

– лоренцовскую модель В качестве моделей фонового сигнала обычно используют:

n(t ) = a0 + a1t ;

– линейную:

n(t ) = a0 + a1t + a2t 2.

– квадратичную:

В качестве моделей шума используют случайные последова тельности и сигналы:

– случайные последовательности с независимыми членами, распределенные по нормальному закону распределения вероятно exp( x 2 / 2 2 ) ;

стей: p ( x) = – случайные последовательности с независимыми членами, распределенные по «засоренному» нормальному закону с плотно стью вероятности:

p ( x) = (1 ) p1 ( x) + p2 ( x), exp( x 2 / 2 2 ), p1 ( x) = где exp( x 2 / 200 2 ) ;

p2 ( x) = 2 – случайные последовательности с независимыми членами, распределенные по закону Пуассона с плотностью вероятности:

k p(k ) = e k ;

k!

– случайные стационарные процессы с корреляционными функциями вида:

K1 ( ) = 2 exp( 2 ), K 2 ( ) = 2 exp( ), и др.

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

В число исследуемых алгоритмов включены следующие алго ритмы определения положения пика ( t * ) и пикового значения ( x * ) на основании последовательности экспериментальных дан ных (ti, xi ) :

А: x * определяется как максимальный член последователь ности ( xi ), т. е. как соответствующее значение аргумента после довательности:

x* = max( xi ), t * = arg( x * );

В: x * и t * определяются по локальной квадратичной ап проксимации x (t ) вблизи максимального члена последователь ности ( xi ) :

x* = max x (t ), t* = arg max x (t ).

Аналитически алгоритм записывается следующим образом:

( x j +1 x j 1 ) 2 h( x j +1 x j 1 ) x* = x j t* = t j,, 8( x j +1 + x j 1 2 x j ) 2( x j +1 + x j 1 2 x j ) где x j и t j — оценки, полученные по алгоритму А;

h — шаг дис кретизации.

С: x * и t * определяются по квадратичной аппроксимации функции s (t ) методом наименьших квадратов по (ti, xi ) :

x* = max x (t ), t* = arg max x (t ).

Аналитически алгоритм записывается следующим образом:

T 2 ( N + 2) d d t* = t, x* = d 0 d2 1, 12 N 4d 2d где d 0, d1, d 2 — коэффициенты при ортогональных полиномах P0 (t ), P (t ), P2 (t ) соответственно нулевой, первой и второй степе ней.

D: x*, t * определяются по локальной кубической аппрокси мации x (t ) вблизи максимума последовательности ( xi ):

x* = max x (t ), t* = arg max x (t ).

Аналитически алгоритм записывается следующим образом:

h( x j x j 1 ) t* = t j, x j +1 2 x j + x j x = M 3 (t * t j +1 )(t * t j )(t * t j 1 ) + M 2 (t t j )1 (t * t j 1 ) + + M 1 (t * t j 1 ) + x j 1, где M 3 = ( x j +1 3 x j + 3 x j 1 x j 2 ) / 6h3, M 2 = ( x j +1 2 x j + x j 1 ) / 2h 2, M 1 = ( x j x j 1 ) / h, t j, x j — оценки, полученные по алгоритму А.

G: t * определяются на основании кубической сплайн интерполяции вблизи максимума последовательности ( x j ):

25M1M t j 1 + 4t j M 2 M3 2 M t* = 1 (1 h ) h ;

5 5M 3 M2 M2 M2 ( x j 1 x j )t j x* = x j + 0,4h2 M 2 + (M1 1,2h2 M 3 )t * + h 2 + (M 2 4hM 3 )(t j t*)3 + (M 2 + hM 3 )(t * t j 1 )3.

5h 5h F: x * определяется как максимальный член сглаженной по zi = (1 k ) zi 1 + kxi ;

t * — соответст следовательности zi, где вующее значение аргумента:

x* = max( zi ), t* = arg max( zi ).

В качестве моделей полезного сигнала s (t ) выбирались сле дующие:

s1 (t ) = a2 t 2 + a1t + a0, s2 ( t ) = A sin(t + ), s3 (t ) = k t + A.

В качестве моделей случайных погрешностей i выбирались случайные последовательности, распределенные по гауссовскому закону с параметрами ( 0, ) или равномерному закону с парамет рами ( 0, ). Предполагалось, что систематические погрешности предварительно исключены из результатов измерений, а для неис ключенных остатков систематических погрешностей во многих случаях подходят модели случайных погрешностей.

В результате метрологической аттестации алгоритмов обработ ки данных определялись следующие показатели:

• границы методической составляющей погрешности;

• границы систематического сдвига результата;

• стандартная неопределенность, обусловленная случайными факторами.

Результаты аналитического исследования кратко отражены в табл. 2.3. Параметры и в зависимости от модели s (t ) прини мают следующие значения:

1 = a2 h 2 / 4, 2 = A 2 h 2 / 8, 3 = kh / 8, 1 = a2 h 2, 2 = A 2 h 2 / 2, 3 = kh.

Параметр характеризует степень подавления помехи при 180 N применении алгоритма С: =, q — пара ( N 2 1)( N + 1)( N + 3) метр исходных данных, равный отношению числа наблюдений в моменты ti 0 ко всему числу наблюдений.

Таблица 2. Алгоритмы Трансформированная неопределенность Модель Границы методической составляющей Границы систематиче- Верхний предел стандартной ского сдвига неопределенности h / 2 t h / А st 0, t = 0 x a2 h 2 / 0 x 0, 45 sx 4, 3 h / 2 t h / kh / 2 x В 1 t = x = 0, 75h t 2 t A h /12 st 0, 7 h / 2 sx 0, 02 A h x 4 0 x 3 t h / 3 0,5kh x D(G) 1 t = 0, 75h x = 0 t st 0, 7 h / 3 t h / sx 4,5 0,5kh x 0 0 x Окончание табл. 2. Алгоритмы Трансформированная неопределенность Модель Границы методической составляющей Границы систематиче- Верхний предел стандартной ского сдвига неопределенности D t A 2 h 2 /12 0, 75h t 2 st 0, 7 h / x 8 10 A h 9 6 4,5 sx G t h /12 0 x x 0, 06 A h 2 C 1 t = 0 st = t = (t * t ) ( N 1) ( N 1) x = 0 2 3 t = 167,5(q 0,5)3 ( t t*) 2 + T 2 / x = ( N 1) 4 8,3(q 0,5) 1 12 t t * sx = 2 + ( ) + ( ( t t*) 2 + T 2 / 60 ) x = 245,9(q 0,5) N N T t t * 2 N + 24, 2(q 0,5) 2 0, + 2 ( ) T 12 N Раздел II ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ И МЕТОДЫ ЕГО АТТЕСТАЦИИ Глава ТРЕБОВАНИЯ К СРЕДСТВАМ ИЗМЕРЕНИЙ, КАСАЮЩИЕСЯ ПРИМЕНЕНИЯ ИХ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Средства измерений, установленные и используемые в соответст вии с заводскими инструкциями, должны соответствовать следую щим требованиям, не противореча при этом всем остальным техни ческим и метрологическим требованиям Рекомендаций МОЗМ.

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

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

эти требо вания должны быть указаны в соответствующей Рекомендации, например, для взвешивающих приборов, счетчиков воды и др. По скольку устройства с программным управлением, как правило, всегда электронные, необходимо также учитывать Документ МОЗМ D 11 Общие требования к электронным средствам измере ний [25].

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

Примечание: Использованы следующие условные обозначения уровней жесткости испытаний:

(I) — техническое решение, приемлемое в случае нормального уровня жесткости испытаний;

(II) — техническое решение, приемлемое в случае повышенно го уровня жесткости.

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

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

В виде исключения, для непрерываемых измерений приемле мым решением может стать штамп с идентификационным номе ром на приборе/электронном устройстве при следующих обстоя тельствах:

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

• прибор/электронное устройство не имеет интерфейса для пе редачи идентификатора;

• после изготовления прибора/электронного устройства изме нение программного обеспечения невозможно или возможно только в том случае, когда изменяется аппаратное обеспече ние или его компонента.

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

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

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

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

Номер версии может иметь следующую структуру: А, Y, Z. Ес ли рассматриваем компьютер расходомера, то А будет представ лять версию основного программного обеспечения, которое под считывает импульсы, Y — версию функции пересчета (отсутству ет, при 15 °С, при 20 °С) и Z — язык интерфейса пользователя.

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

например, алгоритм CRC16 является допустимым решением для этого вычисления. Решение (II) является приемлемым, когда требуется повышенная степень соответствия, например — идентичность всего исполняемого кода (см. 3.2.5).

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

Требования к СИ типа U также должны применяться, если пред ставленное далее техническое описание для специализированных СИ не подходит.

Техническое описание СИ типа Р — это средство измерений со встроенной системой ИТ (в основном это система, основанная на микропроцессоре или микроконтроллере). Она характеризуется следующими чертами:

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

• ПО проектируется и используется как единое целое, за ис ключением тех случаев, когда применяется разделение ПО согласно расширению S.

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

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

• ПО и его окружение неизменны, и не существует способов для перепрограммирования или изменения законодательно контролируемого ПО. Загрузка ПО допускается, если только соблюдается расширение D.

• Допускается существование интерфейсов для передачи дан ных измерений по открытым или закрытым сетям (соблюда ется расширение Т).

• Допускается хранение данных измерений либо на встроен ном накопителе информации, либо на удаленном или съем ном накопителе информации (соблюдается расширение L).

Для СИ типа Р предъявляются следующие требования по пред ставляемой документации.

Примечание. Далее требования приводятся, в основном, в таб личной форме без нумерации таблиц.

P1. Документация В дополнение к специальной документации, необходимой в каждом из последующих требований, документация, в основ ном, должна включать:

a) Описание законодательно контролируемого ПО.

б) Описание точности алгоритмов измерения (например, вычисления цены и алгоритмов округления).

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

г) Однозначную идентификацию ПО.

д) Обзор аппаратного обеспечения системы, например то пологическая блок-диаграмма, тип компьютера(ов), тип сети и т. д., если это не описано в Руководстве пользователя.

е) Руководство пользователя.

Что касается идентификации, то требования к ней, примени тельно к средствам измерений типа Р, приведены в следующей таблице.

Класс риска B Класс риска С Класс риска D P2. Идентификация ПО Законодательно контролируемое ПО должно четко идентифи цироваться. Идентификационный номер программного обеспе чения должен быть сложным путем связан с самим ПО. Он должен указываться по команде или во время действия.

Определяющие Определяющие комментарии:

1. В дополнение к 1В: Каждое изменение комментарии:

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

мировать аккредито ванный орган (АО).

АО решает, необхо дим или нет новый уникальный иденти фикационный номер.

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

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

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

Требуемая документация: Требуемая доку Документация должна включать иден- ментация (в допол тификационные номера ПО и описывать, нение к документа как идентификационный номер создает- ции, требуемой для ся, как он сложным путем связан с самим классов риска В и С):

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

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

нение к руководству • Проверить описание генерирования и для классов риска В визуализации идентификационного но и С):

мера ПО.

Проверки основан • Проверить, все ли программы, выпол ные на документа няющие законодательно контроли ции:

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

идентификацией ПО, а какие нет.

• Проверить, представлено ли произво дителем номинальное значение иденти фикационного номера (номер версии или функциональная контрольная сумма).

Это должно быть указано в сертификате испытаний.

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

• Идентификационный номер может быть визуализирован так, как это описа но в документации.

• Представленный идентификационный номер верен.

Документация (плюс рабочая программа, если необходимо) образца хранится в АО.

Пример допустимого решения:

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

• Идентификационный номер генерируется и показывается по команде.

• Часть (А) иденти- • Часть (А) идентификационного номера фикационного номе- состоит из автоматически генерируемой ра состоит из номера контрольной суммы законодательно версии и номера контролируемого ПО, которая была объ контроллера доступа явлена фиксированной при утверждении терминалов (к сети) типа. Для других законодательно кон ТАС. тролируемых ПО идентификационный номер — это номер версии или номер ТАС.

• Примером допустимого решения для получения контрольной суммы может служить алгоритм CRC-16.

Добавления для класса риска Е Требуемая документация (в дополнение к документации, тре буемой для классов В, С и D):

Исходный код, содержащий генерирование идентификационно го номера.

Руководство по аттестации (в дополнение к документации для классов рисков В, С и D):

Проверки, основанные на исходном коде:

• Проверить, покрываются ли все контролируемые части ПО ал горитмом генерирования идентификационного номера.

• Проверить правильность выполнения алгоритма.

3.1.1.2. Специальные требования для средств измерений типа U Техническое описание Набор программных требований в этом подразделе применяет ся для СИ, основанных на компьютере общего назначения. Техни ческое описание измерительной системы типа U подытожено в табл. 3.1. В основном, системе должен присваиваться тип U, если не выполняются условия для СИ типа Р.

Таблица 3. Техническое описание СИ типа U Конфигурация аппаратного обеспечения а) Модульная система, основанная на компьютере общего на значения. Компьютерная система может быть автономной, яв ляться частью закрытой сети, например Ethernet, кольцевой сети с маркерным доступом LAN или частью открытой сети, напри мер Интернет.

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

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

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

Таким образом, линия связи с устройствами накопления инфор мации может быть прямой, что позволяет взаимодействовать, или непрямой, из-за чего может быть промежуточная фаза хра нения, не находящаяся под контролем пользователя, например по dial-up в Интернет. Накопитель информации может быть же стко закрепленным, например жесткий диск, или съемным на пример дискеты, CD-RW.

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

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

Для СИ типа U предъявляются следующие требования по пред ставляемой документации.

Классы риска от B до E U1. Документация В дополнение к специальной документации, требуемой в ка ждом из последующих требований, документация, по сущест ву, должна включать:

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

б) Описание точности вычислительных алгоритмов (напри мер, вычисление цены и алгоритмы округления).

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

г) Идентификацию законодательно контролируемого ПО.

д) Обзор аппаратного обеспечения системы, например то пологическая блок-диаграмма, тип компьютера(ов), тип сети и т. д., если это не указано в Руководстве пользователя.

е) Обзор аспектов безопасности операционной системы, на пример, защита, пользовательские счета, привилегии и т. д.

ж) Руководство пользователя.

Что касается идентификации, то требования к ней, примени тельно к средствам измерений типа U, приведены в следующей таблице.

Класс риска B Класс риска С Класс риска D U2. Идентификация программного обеспечения Законодательно контролируемое ПО должно четко идентифи цироваться. Идентификационный номер программного обеспе чения должен быть сложным путем связан с самим ПО. Он должен определяться и указываться по команде или во время действия.

Определяющие Определяющие комментарии:

1. Ограничение для 1B: драйверы комментарии:

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

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

конкретной законода тельно контролируемой цели.

2. При изменении мет рологически контроли руемого ПО необходи мо информировать АО.

АО решает, необходим ли новый уникальный идентификационный номер или нет. Новый идентификационный номер требуется толь ко, если изменения ПО ведут к изменению утвержденных функций или характеристик.

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

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

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

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

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

Руководство по аттестации: Руководство по Проверки, основанные на документации: аттестации (в до полнение к руко • Проверить описание генерирования и водству для клас визуализации идентификационного номе сов риска В и С):

ра ПО.

Проверки, осно • Проверить, все ли программы, выпол ванные на доку няющие законодательно контролируемые функции, четко идентифицируются и опи- ментации:

• Проверить, явля саны так, что и Аккредитованному Орга ются ли меры, ну, и производителю ясно, какие про граммные функции покрываются иденти- предпринятые для фикацией ПО, а какие нет. защиты от фальси • Проверить, поставляется ли номинальное фикации, приемле мыми.

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

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

• Проверить, может ли идентификацион ный номер быть визуализирован так, как это описано в документации.

• Проверить, верен ли представленный идентификационный номер.

Документация (плюс рабочая программа, если это необходимо) образца хранится в АО.

Пример допустимого решения:

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

• Часть (В) идентификационного номера генерируется и показы вается по команде.

• Часть (А) иденти- • Часть (А) идентификационного номера фикационного номе- состоит из автоматически генерируемой ра состоит из номера контрольной суммы на фиксированном версии и номера кон- коде. Часть (А) для других законода троллера доступа тельно контролируемых ПО — это но терминалов к сети мер версии или номер ТАС. Чтобы пре ТАС. Чтобы предот- дотвратить его изменения простыми вратить его измене- программными средствами, он хранится ния простыми про- в двоичном формате в файле с рабочей граммными средст- программой.

вами, он хранится в двоичном формате • Примером до- • Допустимыми ал в файле с рабочей пустимого реше- горитмами для кон программой. ния для кон- трольной суммы трольной суммы являются CRC- может служить или хэш-алгоритмы алгоритм CRC-16. типа SHA-1, MD5, RipeMD160 и др.

Добавления для класса риска Е Требуемая документация (в дополнение к документации, тре буемой для классов риска В, С и D):


Исходный код, содержащий генерирование идентификационно го номера.

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

Проверки, основанные на исходном коде:

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

• Проверить правильность выполнения алгоритма.

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

Результат измерения и сопроводительная информация, требуе мая специальными Рекомендациями МОЗМ или национальным законодательством, должны отображаться на дисплее или печа таться правильно.

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

3.1.2.1. Специальные требования для средств измерений типа Р Для средств измерений типа Р в [53] добавлены следующие требования.

Класс риска B Класс риска С Класс риска D P3. Влияние через интерфейс пользователя Команды, вводимые через интерфейс пользователя, не должны недопустимо влиять на законодательно контролируемое ПО и данные измерений.

Определяющие комментарии:

1. Команды могут представлять собой однократные или после довательные включения или нажатия на клавиши, осуществляе мые вручную.

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

3. Это предполагает, что включение или нажатие клавиш, кото рые не заявлены и не внесены в документацию как команды, не окажет никакого эффекта на функции СИ и данные измерений.

Требуемая документация: Требуемая докумен Если в СИ есть возможность получения тация (в дополнение к команд, то документация должна документации, требуе включать: мой для классов риска • Полный список всех команд (напри- В и С):

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

ды.

• Документация дол жна содержать прото кол, в котором указа ны тесты для всех ко манд.

Руководство по аттестации: Руководство по атте Проверки, основанные на документации: стации: (в дополнение • Оценить, допустимы ли все докумен- к руководству для тированные функции, т. е. оказывают классов риска В и С):

ли они разрешенное воздействие на Проверки, основанные измерительные функции (и контроли- на документации:

• Проверить, соответ руемые данные), или нет.

• Проверить, представил ли производи- ствуют ли предприня тель подробное заявление о полноте тые меры и протоколы испытаний высокому документации на команды.

уровню защиты.

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

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

Пример допустимого решения:

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

Этот модуль принадлежит законодательно контролируемому ПО. Он только пересылает допустимые команды другим законо дательно контролируемым программным модулям. Все неизвест ные или недопустимые последовательности переключения или нажатия на клавиши отвергаются и не оказывают влияния на за конодательно контролируемое ПО или данные измерений.

Добавления для класса риска Е Требуемая документация (в дополнение к документации, тре буемой для классов В, С и D):

Исходный код СИ.

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

Проверки, основанные на исходном коде:

• Проверить строение ПО: однозначно ли определяются потоки данных, касающиеся команд в законодательно контролируемом ПО, и можно ли это подтвердить.

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

• Проверить с помощью оборудования или вручную, что коман ды корректно расшифровываются и не существует недокумен тированных команд.

Класс риска B Класс риска С Класс риска D P4. Влияние через интерфейсы связи Команды, вводимые через интерфейсы связи СИ, не должны недопустимо влиять на законодательно контролируемое ПО и данные измерений.

Определяющие комментарии:

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

2. Это означает, что сигналы или коды, которые не заявлены и не документированы как команды, не оказывают никакого эф фекта на функции СИ и данные.

3. Команды могут представлять собой последовательность элек тронных (оптических, электромагнитных и т. п.) сигналов, пода ваемых на входные каналы, или коды в протоколах передачи данных.

4. Ограничения этого требования временно прекращаются, когда производится загрузка ПО согласно расширению D.

5. Это требование применяется только к интерфейсам, которые не опечатаны.

Требуемая документация: Требуемая докумен Если в СИ есть интерфейс, то докумен- тация (в дополнение тация должна включать: к документации, тре • Полный список всех команд вместе буемой для классов риска В и С):

с заявлением о его полноте.

• Краткое описание их значения и их • Документация влияния на функции и данные измере- должна указывать ме ры, предпринятые для ний СИ.

подтверждения пол ноты документации на команды.

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

Руководство по аттестации: Руководство по атте Проверки, основанные на документации: стации (в дополнение к руководству для • Оценить, допустимы ли все докумен классов риска В и С):

тированные команды, т. е. оказывают Проверки, основанные ли они разрешенное влияние на изме на документации:

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

документации на команды.

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

• Провести практические испытания (выборочные проверки), используя пе риферийное оборудование, если оно доступно.

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

Пример допустимого решения:

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

Добавления для класса риска Е Требуемая документация (в дополнение к документации, тре буемой для классов риска В, С и D):

Исходный код СИ.

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

Проверки, основанные на исходном коде:

• Проверить строение ПО: однозначно ли определяются потоки данных, касающиеся команд в законодательно контролируемом ПО, и можно ли это подтвердить.

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

• Проверить с помощью оборудования или вручную, что коман ды корректно расшифровываются и не существует недокумен тированных команд.

3.1.2.2. Специальные требования для средств измерений типа U Для средств измерений типа U в [53] добавлены следующие требования.

Класс риска B Класс риска С Класс риска D U3. Влияние через интерфейс пользователя Команды, вводимые через интерфейс пользователя, не должны недопустимо влиять на законодательно контролируемое ПО и данные измерений.

Определяющие комментарии:

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

2. Это предполагает, что включение или нажатие клавиш, кото рые не заявлены и не документированы как команды, не окажет никакого эффекта на функции СИ и данные измерений.

3. Команды могут представлять собой единичные действия или последовательность действий, осуществляемых оператором.

Пользователь должен быть осведомлен, какие команды допус каются.

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

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

риска В и С):

• Краткое описание значения команд и • Документация дол их влияния на функции СИ и данные жна указывать меры измерений.

для подтверждения полноты списка всех команд.

• Документация дол жна содержать прото кол, в котором указа ны испытания для всех команд.

Руководство по аттестации: Руководство по ат тестации (в дополне Проверки, основанные на документа ции: ние к руководству для классов риска В и С):

• Оценить, допустимы ли документи Проверки, основанные рованные команды, т. е. оказывают ли на документации:


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

тель подробное заявление о полноте документации на команды.

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

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

Пример допустимого решения:

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

Доступ к операцион — ной системе заблоки рован.

Добавления для класса риска Е Требуемая документация (в дополнение к документации, тре буемой для классов риска В, С и D):

Исходный код законодательно контролируемого программного обеспечения.

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

Проверки, основанные на исходном коде:

• Проверить строение ПО: однозначно ли определяются потоки данных, касающиеся команд в законодательно контролируемом ПО, и можно ли их проверить.

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

• Проверить с помощью оборудования или вручную, что коман ды корректно расшифровываются и не существует недокумен тированных команд.

Класс риска B Класс риска С Класс риска D U4. Влияние через интерфейс связи Ввод команд через неопечатанные интерфейсы связи СИ не должен недопустимо влиять на законодательно контролируе мое ПО и данные измерений.

Определяющие комментарии:

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

2. Это означает, что сигналы или коды, которые не заявлены и не документированы как команды, не оказывают никакого влия ния на функции СИ и данные.

3. Команды могут представлять собой последовательность элек трических (оптических, электромагнитных и т. п.) сигналов на входных каналах или коды в протоколах передачи данных.

4. Ограничения этого требования временно приостанавливают ся, когда производится загрузка ПО согласно Расширению D.

5. Те части операционной систе- 5. Все программы и части мы, которые интерпретируют программ, занятые в переда законодательно контролируемые че и получении законода команды, должны быть причис- тельно контролируемых ко лены к законодательно контро- манд или данных, должны лируемому ПО. быть под надзором законо 6. Другие части ПО могут ис- дательно контролируемого пользовать предоставляемый ин- ПО.

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

Однако стандартные интер фейсы не исключаются, если средства защиты ПО выпол няются согласно Расшире нию T.

Требуемая документация: Требуемая документация (в дополнение к документа Документация должна включать:

ции, требуемой для классов • Полный список всех команд риска В и С):

вместе с заявлением о его полноте.

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

списка команд.

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

Руководство по аттестации: Руководство по аттестации (в дополнение к руководству Проверки, основанные на доку для классов риска В и С):

ментации:

Проверки, основанные на • Оценить, допустимы ли все до документации:

кументированные команды, т. е.

• Проверить, соответствуют оказывают ли они разрешенное влияние на законодательно кон- ли предпринятые меры и тролируемое ПО (и контроли- протоколы испытаний высо руемые данные измерений) или кому уровню защиты.

не оказывают вообще никакого влияния.

• Проверить, представил ли про изводитель подробное заявление о полноте документации на ко манды.

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

• Провести практические испы тания (выборочную проверку), используя периферийное обору дование, если оно доступно.

Пример допустимого решения:

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

Добавления для класса риска Е Требуемая документация (в дополнение к документации, тре буемой для классов риска В, С и D):

Исходный код СИ.

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

Проверки, основанные на исходном коде:

• Проверить строение ПО: однозначно ли определяется потоки данных, касающиеся команд в законодательно контролируемом ПО, и можно ли это проверить.

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

• Проверить с помощью оборудования или вручную, что коман ды корректно расшифровываются и не существует недокумен тированных команд.

3.1.3. Защита программного обеспечения 3.1.3.1. Предотвращение неправильного использования Средство измерений должно быть разработано таким образом, чтобы возможности непреднамеренного случайного или предна меренного неправильного использования свести к минимуму, осо бенно если это касается его программного обеспечения. Представ ление результата измерений должно быть однозначно для всех за интересованных сторон.

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

Пример: Пользователь руководствуется меню. Законодательно контролируемые функции собраны в одной из ветвей этого меню.

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

Для средств измерений типа Р это требование выглядит сле дующим образом [53]:

Класс риска B Класс риска С Класс риска D P5. Защита от случайных и непреднамеренных изменений Законодательно контролируемое программное обеспечение и данные измерений должны быть защищены от случайных и не преднамеренных изменений.

Определяющие комментарии:

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

а) Физические воздействия: хранимые измерительные данные должны быть защищены от повреждения или удаления при воз никновении ошибок или, в противном случае, должна иметься возможность обнаружения ошибок.

б) Пользовательские функции: перед удалением или изменением данных должно запрашиваться подтверждение.

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

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

Документация должна отражать меры, которые были предпри няты для защиты ПО и данных от непреднамеренных измене ний.

Руководство по аттестации:

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

• Проконтролировать, что контрольная сумма программного ко да и контролируемые параметры генерируются и проверяются автоматически.

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

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

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

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

Пример допустимого решения:

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

• Данные измерений не удаляются без предшествующего разре шения, например, без диалогового подтверждения или окна с запросом о подтверждении удаления.

• Для обнаружения ошибок см. также Расширение I.

Добавления для класса риска Е Требуемая документация (в дополнение к документации, тре буемой для классов В, С и D):

Исходный код СИ.

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

Проверки, основанные на исходном коде:

• Проверить, что меры, предпринятые для обнаружения измене ний (ошибок), приемлемы.

• Если получена контрольная сумма, проверить, все ли законо дательно контролируемые части она охватывает.

Для средств измерений типа U это требование выглядит сле дующим образом [53]:

Класс риска B Класс риска С Класс риска D U5. Защита от случайных и непреднамеренных изменений Законодательно контролируемое программное обеспечение и данные измерений должны быть защищены от случайных и не преднамеренных изменений.

Определяющие комментарии:

Непреднамеренные изменения могут произойти по следующим причинам:

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

б) Неправильное использование ОС.

в) Случайная перезапись или удаление хранимых данных и про грамм (см. также Расширение L).

г) Неверное присваивание данных измерительной операции. Из мерения и данные, принадлежащие одной измерительной опера ции, не должны смешиваться с измерениями и данными другой операции из-за неверного программирования или хранения.

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

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

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

Руководство по аттестации: Руководство по ат Проверки, основанные на документа- тестации ции: (в дополнение к руко • Проконтролировать, что контрольная водству для классов сумма программного кода и контроли- риска В и С):

руемые параметры генерируются и про- Проверки, основан ные на документа веряются автоматически.

• Проконтролировать, что перезапись ции:

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

но производителем.

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

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

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

Пример допустимого решения:

• Препятствование неверному строению программы — это нахо дится за пределами используемых классов риска.

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

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

• Где операционная система позволяет, рекомендуется, чтобы все права пользователя на удаление, перемещение или исправ ление законодательно контролируемого ПО были исключены и доступ контролировался обслуживающими программами. Реко мендуется контроль доступа к программам и данным с исполь зованием паролей, так же как и использование механизмов «только чтение». Управляющая программа системы должна вос станавливать права только тогда, когда это требуется.

Добавления для класса риска Е Требуемая документация (в дополнение к документации, тре буемой для классов В, С и D):

Исходный код СИ.

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

Проверки, основанные на исходном коде:

• Проверить, приемлемы ли меры, предпринятые для обнаруже ния изменений (ошибок).

• Если контрольная сумма реализуется, проверить все ли зако нодательно контролируемые части ПО она охватывает.

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

Примечание: Когда программное обеспечение хранится в не доступном устройстве памяти (например в опечатанном постоян ном запоминающем устройстве (ПЗУ) с масочным программиро ванием), необходимость в таких технических средствах соответст венно уменьшается.

Примеры: (I)/(II) Корпус, содержащий устройство памяти, опе чатан, или запоминающее устройство запломбировано в много слойной печатной плате.

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

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

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

3.1.3.2.б. Разрешается активировать с помощью интерфейса пользователя только документированные функции. Пользователь ский интерфейс должен быть выполнен таким образом, чтобы он не мог содействовать мошенническому использованию. Представ ление информации должно подчиняться 3.2.2.

Примечание: Контролирующее лицо решает, приемлемы ли все документированные команды.

Пример: (I)/(II) Все входы от пользовательского интерфейса пе ренаправляются к программе, которая фильтрует поступающие команды. Она пропускает только документированные команды и блокирует все остальные. Эта программа или программный мо дуль является частью законодательно контролируемого программ ного обеспечения.

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

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

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

Пример: (I)/(II) Параметры, характерные для устройства, долж ны быть защищены и храниться в постоянной памяти. Ее записы вающий вход закрыт выключателем, который может быть опеча тан или может контролироваться программным обеспечением (сравни с примерами 3.1.3.2.г (1–3)).

3.1.3.2.г. Защита программного обеспечения состоит из меха нического пломбирования и электронных или криптографических средств, которые делают невозможным или очевидным несанк ционированное вмешательство.

Примеры:

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

2) (I)/(II) Программное обеспечение средства измерений по строено таким образом (см. Пример 3.1.3.2.а), что не существует пути доступа к параметрам и законодательно контролируемой конфигурации, кроме как через меню, защищенное выключателем.

Этот выключатель механически опечатан в выключенной позиции.

Это делает невозможной модификацию параметров и законода тельно контролируемой конфигурации.

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

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

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



Pages:     | 1 || 3 | 4 |   ...   | 7 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.