WELMEC 7.2 Руководство по программному обеспечению

Всероссийский научно-исследовательский институт
метрологической службы
(ВНИИМС)
ВЭЛМЭК – 7.2
Руководство по программному обеспечению
(основано на Директиве по измерительным приборам
2004/22/ЕС)
МОСКВА 2009
Научно-техническое редактирование:
Профессор, д.т.н. Л.К. Исаев
Профессор, д.ф.-м.н. Ю.А. Кудеяров
Перевод:
Профессор, д.ф.-м.н. Ю.А. Кудеяров, А.Н. Паньков
2
WELMEC 7.2
Издание 1
WELMEC
Европейское сотрудничество по законодательной метрологии
WELMEC - это организация по сотрудничеству в области законодательной метрологии между членами Европейского Союза (ЕС) и EFTA (Европейской ассоциация свободной торговли). Этот документ является одним из ряда Руководств, опубликованных
WELMEC и предназначенных, как для производителей средств измерений, так и для организаций, ответственных за подтверждение соответствия производимой ими продукции.
Руководство является чисто рекомендательным и не налагает какие-либо ограничения или дополнительные технические требования сверх тех, которые содержатся в соответствующих Директивах ЕС. Хотя возможны и альтернативные подходы, но рекомендации, содержащиеся в этом документе, представляют точку зрения WELMEC, основанную на результатах наилучшего использования.
Опубликовано секретариатом WELMEC
BEV
Arltgasse 35
A-1160 Vienna
Austria
Tel: +43 1 21176 3608
Fax: +43 1 49 20 875
E-mail: welmec@metrologie.at
Website: www.welmec.org
3
РУКОВОДСТВО ПО ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
(основано на Директиве по измерительным приборам (Measuring Instruments Directive)
(MID) 2004/22/ЕС)
Содержание.
Предисловие……………………………………………………………………………………4
1. Введение……………………………………………………………………………………..5
2. Терминология ……………………………………………………………………………….6
3. Как пользоваться этим Руководством……………………………………………………...9
3.1. Общая структура Руководства……………………………………………………………9
3.2. Как выбирать подходящие части Руководства…………………………………………10
3.3. Как работать с блоком требований……………………………………………………...12
3.4. Как работать с контрольными таблицами………………………………………………13.
4. Основные требования к встроенному в средства измерений программному обеспечению
(тип P)…………………………………………………………………………………………..13
4.1. Техническое описание……………………………………………………………………13
4.2. Специальные требования для программного обеспечения средств измерений типа P.14
5. Основные требования для программного обеспечения средств измерений, использующих универсальный компьютер (тип U)……………………………………………………..24
5.1. Техническое описание……………………………………………………………………24
5.2. Специальные программные требования для типа U……………………………………24
6. Приложение L: Долговременное сохранение данных измерений……………………...39
6.1. Техническое описание……………………………………………………………………39
6.2. Специальные требования к программному обеспечению для долговременного сохранения……………………………………………………………………………………………39
7. Приложение T: Передача данных измерений через телекоммуникационные сети…….52
7.1. Техническое описание…………………………………………………………………….52
7.2. Специальные требования к программному обеспечению для передачи данных……..53
8. Приложение S: Разделение программного обеспечения………………………………….63
8.1. Техническое описание…………………………………………………………………….63
8.2.Специальные программные требования для разделения программного обеспечения..64
9. Приложение D: Загрузка юридически значимого программного обеспечения…………69
9.1. Техническое описание…………………………………………………………………….69
9.2. Специальные программные требования…………………………………………………70
10. Приложение I: Специальные приборные требования к программному обеспечению..77
10.1. Счетчики воды……………………………………………………………………………80
10.2. Счетчики газа и преобразователи объема………………………………………………84
10.3. Счетчики активной электрической энергии……………………………………………90
10.4. Счетчики количества теплоты…………………………………………………………..95
10.5. Измерительные системы для непрерывных и динамических измерений количества
жидкости (кроме воды)………………………………………………………………………..99
10.6. Взвешивающие приборы……………………………………………………………….100
10.7. Таксометры........................................................................................................................106
10.8. Средства измерений свойств материалов……………………………………………..109
10.9. Средства измерений размеров……………………………………………………….. .110
10.10. Анализаторы выхлопных газов……………………………………………………….111
11. Определение классов риска………………………………………………………………112
11.1. Основной принцип……………………………………………………………………...112
11.2. Описаний уровней для защиты, проверки и соответствия…………………………...112
11.3. Определение классов риска…………………………………………………………….113
11.4. Интерпретация классов риска………………………………………………………….113
4
12. Образец для акта испытаний (включая контрольные таблицы)……………………..115
12.1. Образец для общей части акта испытаний………………………………………….116
12.2. Приложение 1 для акта испытаний: контрольные таблицы, содержащие выбор подходящих наборов требований……………………………………………………………...119
12.3. Приложение 2 для акта испытаний: специальные контрольные таблицы для соответствующих технических частей……………………………………………………………..120
12.4 Информация, которые нужно включать в сертификат утверждения типа………...125
13. Перекрестные ссылки для программных требований MID, статьи и дополнения в
MID………………………………………………………………….......................................126
14. Ссылки и литература…………………………………………………………………….127
5
Предисловие
Настоящее руководство основано на «Требованиях к программному обеспечению и руководстве по подтверждению», версия 1.00, 29 октября 2004 г., разработанных и представленных Европейской сетью развития «MID - Software» («Measuring Instruments Directive –
Software»). Сеть поддерживалась с января 2002 г. по декабрь 2004 г. комиссией EС по
контракту G7RT-CT-2001-05064.
Руководство является чисто рекомендательным и не налагает какие-либо ограничения или
дополнительные технические требования сверх тех, которые содержатся в MID. Альтернативные методы могут быть рассмотрены, но рекомендации, приведенные в этом документе, представляет точку зрения WELMEC, основанную на наилучших результатах использования. Хотя Руководство ориентировано на СИ, включенные как объекты регулирования в MID, его рекомендации носят общий характер и могут быть применимы и к
другим СИ.
6
1 Введение
Этот документ содержит рекомендации, относящиеся к таким средствам измерений, которые попадают под действие MID, но в первую очередь к средствам измерений, оснащенным программным обеспечением. Он адресован как изготовителям средств измерений, так
и организациям, ответственным за оценку их соответствия.
В основе Руководства лежит предположение, что требования к программному обеспечению, содержащиеся в MID, принимаются. Более того, предполагается, что все уполномоченные органы (организации) принимают это Руководство как наиболее подходящую интерпретацию MID в том, что касается программного обеспечения. Чтобы показать, как
требования в этом Руководстве соотносятся с соответствующими требованиями MID, в
Руководство в виде приложения (глава 13) включена соответствующая перекрестная
ссылка.
Предшественником этого Руководства было Руководство 7.1, разработанное Рабочей
группой 7 WELMEC. Оба Руководства основаны на одинаковых принципах и были производными от требований MID. Руководство WELMEC 7.1 было апробировано и продолжило дальнейшее существование (Издание 2), но оно носит в основном информационный
характер, в то время как Руководство WELMEC 7.2 рекомендуется WELMEC для использования при разработке, проверке и утверждении программного обеспечения, контролирующего средства измерений, попадающие под действие MID.
Самая последняя информация, относящаяся к Руководствам и Рабочей группе 7
WELMEC, доступна на вэб-сайте http://www.welmecwg7.ptb.de.
7
2. Терминология
Терминология, приведенная в этом разделе, поясняет словарь, используемый в Руководстве. Даются ссылки на стандарт или на любой другой источник, если определение полностью или в основных частях взято из них.
(Примечание переводчика: термины приводятся в той же последовательности, что и в
оригинале на английском языке).
Приемлемое (возможное) решение: Исполнение или принципы построения программного модуля или аппаратной части (hardware), а также характеристики, которые могут рассматриваться как удовлетворяющие определенному требованию. Приемлемое решение
является примером того, как конкретное требование может быть удовлетворено. Это не
ставит под сомнение любое другое решение, которое также удовлетворяет требованию.
Контрольный журнал: Программный счетчик (например, «счетчик событий») и/или информационная запись (например, «журнал событий») изменений в законодательно контролируемом (юридически значимом) программном обеспечении или параметре.
Аутентификация: Проверка заявленной или предполагаемой идентичности пользователя,
процесса или устройства.
Основная конфигурация: Исполнение средства измерений в соответствии с основной
архитектурой. Имеется две различные основные конфигурации: средства измерений, созданные для конкретной цели и средства измерений, использующие универсальный компьютер. Эти термины применимы также и к соответствующим подсистемам.
Измерительное оборудование, созданное для конкретной цели (специализированное
средство измерений) (тип Р): Средство измерений, разработанное и созданное специально для конкретной измерительной задачи. Программное приложение целиком разработано
для решения измерительной задачи. Более детальное определение дано в главе 4.1.
(Примечание переводчика: в дальнейшем такие средства измерений иногда будут называться «средствами измерений с встроенным программным обеспечением»).
Закрытая сеть: сеть с фиксированным числом участников с известной идентификацией,
функциональностью и локализацией (см. также Открытая сеть).
Интерфейс связи: электронное, оптическое, радио- или другое техническое устройство,
которое позволяет информации автоматически проходить между компонентами средства
измерений или подсистем.
Параметр устройства: Юридически (законодательно) значимый параметр, значение которого зависит от конкретного средства измерений. Параметры устройства включают в
себя параметры калибровки (например, регулировку диапазона или другие установки (регулировки или коррекции)) и параметры конфигурации (например, максимальное и минимальное значение, единицы измерений и т.д.). Они регулируются или устанавливаются
только в специальном операционном (сервисном) режиме работы средства измерений.
Параметры устройства могут быть разделены на те, которые должны быть защищены
(быть неизменными), и на те, которые могут быть доступны (установочные параметры)
уполномоченному лицу, например, владельцу средства измерений или продавцу прибора.
Интегрированная память: встроенное (несменяемое) запоминающее устройство, являющееся частью средства измерений, например, RAM, EEPROM, жесткий диск.
8
Целостность данных и программного обеспечения: Гарантия того, что данные и программное обеспечение не подвергаются любым несанкционированным изменениям во
время использования, при передаче или сохранении.
IT конфигурация: Исполнение средства измерений в соответствии с функциями и особенностями, предусмотренными информационными технологиями (IT), что в части, касающихся требований, не зависит от назначения средства измерения. Имеется четыре IT
конфигурации, рассматриваемые в этом Руководстве: долговременное сохранение измеренных данных, передача измеренных данных, загрузка программного обеспечения и разделение программного обеспечения (см. также Основная конфигурация). Термины применимы также и к соответствующим подсистемам.
Законодательно контролируемый параметр: Параметр средства измерений или подсистемы, подлежащий законодательному контролю (контролю, предусмотренному законодательной метрологией). Различают следующие виды таких параметров: параметры,
определяющие тип средства измерений, и параметры, характеризующие само средство
измерений.
Законодательно контролируемое программное обеспечение: Программы, данные и параметры, определяющие тип средства измерений, которые относятся к средству измерений или подсистеме и которые определяют и выполняют функции, подлежащие законодательному контролю.
Долговременное сохранение данных измерений: Сохранение, используемое для удержания данных измерений, готовых после завершения измерений для последующего использования в юридически значимых операциях (например, для заключения коммерческой сделки).
Измерительный инструмент (средство измерений): Любое устройство или система с
функцией измерения. Прилагательное «измерительный» может опускаться, если это не
приводит к недоразумениям [MID, статья 4].
Средство измерений с использованием универсального компьютера (тип U): Средство измерений, которое включает компьютер общего назначения, обычно базирующийся
на персональном компьютере (PC), и используемый для выполнения контрольных функций. Система типа U используется в тех случаях, когда условия для использования специализированного средства измерений (тип P), не выполняются.
Открытая сеть: Сеть с произвольным числом участников (устройств с произвольными
функциями). Число, идентификация и локализация участников могут меняться и быть неизвестными другим участникам (см. также Закрытая сеть).
Класс риска: Класс типов средств измерений с сопоставимыми оценками риска.
Загрузка программного обеспечения: Процесс автоматической передачи программного
обеспечения в средство измерений или аппаратное устройство с использованием любых
технических средств из локализованного или отдаленного источника (например, сменного
носителя памяти, портативного компьютера, удаленного компьютера) через произвольные
связи (например, прямые связи, сети).
9
Программная идентификация: Последовательность считываемых характеристик программного обеспечения, однозначно связанных с программным обеспечением (например,
номер версии, контрольная сумма).
Программное разделение: Однозначное (недвусмысленное) разделение программного
обеспечения на законодательно контролируемые и неконтролируемые части. Если программное разделение не проведено, все программное обеспечение должно рассматриваться как подлежащее законодательному контролю.
Подсистема (Sub-assembly): Аппаратная часть (hardware unit), которая функционирует
независимо в составе средства измерений совместно с другими подсистемами (или средствами измерений), с которыми она совместима [MID, статья 4].
Передача измеренных данных: Передача данных измерения через сети связи или другие
средства на отдаленное устройство, где они в дальнейшем обрабатываются и/или используются для юридически значимых целей.
Параметр, определяющий тип: Юридически значимый параметр, значение которого зависит только от типа средства измерений. Параметры, определяющие тип, относятся к
юридически значимой части программного обеспечения. Они определяются и фиксируются при испытаниях средств измерений с целью утверждения типа.
Интерфейс пользователя: Интерфейс, обеспечивающий прохождение информации между пользователем (человеком) и средством измерений или его аппаратными, или программными компонентами, такими, как, например, выключатель, клавиатура, мышь, дисплей, монитор, принтер, сенсорный экран (точскрин).
Валидация (подтверждение): Подтверждение, посредством представления объективных
свидетельств (т.е. информации, истинность которой может быть основана на фактах, полученных из наблюдений, измерений, тестирования и т.п.) того, что требования, предназначенные для конкретного предполагаемого использования или применения выполнены.
В рассматриваемом случае, относящиеся к делу требования являются теми, что сформулированы в MID.
Последующие определения являются специфическими. Они используются только в некоторых дополнениях и для классов риска D или выше.
Алгоритм хэширования: Алгоритм, который сжимает содержимое блока данных в число
определенной длины (хэш-код), такое, что изменение любого бита блока данных приводит
на практике к другому хэш-коду. Алгоритмы хэширования выбираются такими, чтобы
теоретическая вероятность того, что два разных блока данных будут иметь тот же самый
хэш-код, является очень малой.
Алгоритм подписи: Криптографический алгоритм, который шифрует (кодирует) открытый текст в зашифрованный текст (перемешанный или секретный текст) с использованием ключа подписи. Алгоритм позволяет декодировать зашифрованный текст, если доступен соответствующий ключ подписи дешифровки.
Ключ (код) подписи: Любое число или последовательность символов, используемых для
кодирования и декодирования информации. Имеется два разных вида ключей (кодов)
подписи: симметричные и асимметричные системы кодов. Симметричная система кодов
означает, что отправитель и получатель информации использует тот же самый код. Си-
10
стема кодов называется асимметричной, если коды для отправителя и получателя разные,
но совместимые. Обычно ключ (код) отправителя известен отправителю, а код получателя
доступен определенному окружению.
Система общедоступного ключа (кода) (Public Key System (PKS)): Пара двух различных кодов подписи, один из которых является секретным, другой – общедоступным (открытым). Для проверки целостности и достоверности информации значение хэш-кода
информации, сгенерированного алгоритмом хэширования, шифруется секретным кодом
отправителя, чтобы создать подпись, которая дешифруется впоследствии получателем,
использующим общедоступный (открытый) ключ (код) отправителя.
Инфраструктура PKI: Организация, гарантирующая надежность системы с общедоступным (открытым) ключом (кодом). Это подразумевает предоставление и распространение цифровых сертификатов всем участникам, участвующим в информационном обмене.
Сертификация ключей: Процесс закрепления значения общедоступного (открытого)
ключа (кода) за физическим лицом, организацией или другим объектом.
Электронная подпись: Короткий код (подпись), однозначно закрепленный за текстовым
файлом, файлом блока данных или двоичным программным файлом, для доказательства
целостности и достоверности загруженных или переданных данных. Подпись создается
с использованием алгоритма подписи и секретного ключа подписи. Обычно генерация
электронной подписи состоит из двух шагов: (1) сначала алгоритм хэширования сжимает
содержание информации в короткую величину (число), и (2) затем алгоритм подписи объединяет это число с секретным ключом, чтобы генерировать подпись.
Центр доверия (Trust Centre): Заслуживающая доверия ассоциация (организация), которая генерирует, содержит и издает информацию о достоверности общедоступных (открытых) ключей физических лиц или других объектов, например, средств измерений.
3 Как пользоваться этим Руководством
Этот раздел описывает, что представляет собой Руководство, и объясняет, как пользоваться им.
3.1 Общая структура Руководства
Руководство построено как структурированный набор блоков требований. Из общей
структуры Руководства следует классификация СИ на основе базовых конфигураций и
классификация так называемых IT конфигураций. Набор требований дополняется специальными требованиями к СИ. Следовательно, имеется три типа наборов требований:
1. требования для двух основных конфигураций СИ (названных типами P и U),
2. требования для четырех IT конфигураций (названных Приложениями L, T, S и
D),
3. специальные требования к СИ (названные Приложениями I.1, I.2,…).
Первый тип требований применим ко всем СИ. Второй тип требований имеет отношение к
следующим IP функциям, предусмотренным информационными технологиями: долговременное сохранение данных измерений (L), передача данных измерений (T), программная
загрузка (D) и программное разделение (S). Каждый набор требований используется только в том случае, если соответствующая функция существует. Последний тип - набор дополнительных специальных требований к СИ. Нумерация следует за нумерацией допол-
11
нений в MID, относящихся к специальным требованиям к СИ. Каким образом набор блоков требований должен применяться к данному СИ, схематически показано на рис. 3.1.
Требования
для
одной из базовых
конфигураций СИ
+
Требования для тех
IT конфигураций,
которые применимы
+
Специальные требования к СИ, которые
применимы
Рис. 3.1. Типы наборов требований, которые должны применяться к СИ
Следующий рисунок 3.2 показывает, какие наборы требований существуют.
В дополнение к описанной структуре, требования этого Руководства различаются в соответствии с классами риска. Вводятся шесть классов риска, обозначаемые буквами от А до
F в направлении повышения риска. Низший класс риска А и высший класс F не рассматриваются. Они вводятся для возможного случая в будущем, когда они могут понадобиться. Остальные классы риска от B до E перекрывают все классы СИ, попадающие под регулирование MID. Более того, они обеспечивают достаточное поле возможностей в случае
изменения оценок риска. Классы определены в главе 11 этого руководства, которая носит
только информационный характер.
Для каждого СИ должна быть произведена оценка класса риска, потому что конкретные
требования к ПО определяются, прежде всего, классом риска, присущим прибору.
3.2 Как выбрать необходимые части Руководства
Это исчерпывающее Руководство по программному обеспечению применимо к большому
разнообразию СИ. Руководство построено по модульному принципу. Необходимые наборы требований могут быть легко выбраны при соблюдении следующих процедур.
Шаг 1: Выбор основной конфигурации (P или U).
Необходимо использовать только один из двух наборов требований для основных конфигураций. Решите, к какой основной конфигурации относится данное средство измерений:
к специализированному средству измерений (тип P, см. главу 4.1) или к средству измерений, использующему универсальный компьютер (тип U, см. главу 5.1). Если не все средство измерений, а только его часть представляет интерес с этой точки зрения, тогда необходимо принять решение по отношению к этой части. Используйте полный набор требований, относящийся к соответствующей основной конфигурации.
Шаг 2: Выбор необходимой конфигурации, предлагаемой информационными технологиями (Приложения L, T, S и D).
Конфигурации, предлагаемые информационными технологиями, включают в себя: долговременное сохранение законодательно контролируемых данных (L), передачу таких данных (T), программное разделение (S) и загрузку законодательно контролируемого программного обеспечения (D). Соответствующие наборы требований, называемые модульными Приложениями, независимы друг от друга. Выбранные наборы требований зависят
только от конфигурации, предлагаемой информационными технологиями. Если модульное Приложение выбрано, оно должна быть использовано полностью. Решите, какие из
имеющихся в наличии модульных Приложений применимы, и используйте их соответственно (Рис. 3.2).
12
Требования к программному обеспечению для основных конфигураций средств измерений
Требования для средств измерений со встроенным программным обеспечением (тип P)
Требования для средств измерений, использующих универсальный компьютер (тип U)
Блок требований Р1
Блок требований U1
Блок требований Р2
Блок требований U2
Требования к программному обеспечению для IT конфигураций
Требования для долговременного
сохранения контролируемых данных
(Приложение L)
Требования по разделению программного обеспечения (Приложение S)
Требования для загрузки контролируемого программного обеспечения (Приложение D)
Требования для передачи контролируемых данных (Приложение Т)
Блок требований L1
Блок требований Т1
Блок требований L2
Блок требований Т2
Блок требований S1
Блок требований D1
Блок требований S2
Блок требований D2
Специальные программные требования для средств измерений
Счетчики воды
Газовые счетчики
Блок требований I1-1
Блок требований I2-1
Электрические
счетчики
Счетчики количества
теплоты
Блок требований I3-1
Блок требований I4-1
Счетчики жидкости
Взвешивающие
инструменты
Блок требований I5-1
Блок требований
I6-1
Рис. 3.2. Наборы требований
13
Шаг 3: Выбор специальных программных требований для средств измерений (Приложение I).
Выбор сводится к применению специальных программных требований, относящихся к
Iму средству измерений, и если эти требования к программному обеспечению наличествуют, то их необходимо соответствующим образом использовать (Рис. 3.2).
Шаг 4: Выбор необходимого класса риска (Приложение I).
Выберите класс риска, как это определено в специальном дополнении I.x, подпункт I.x.6.
Там предлагается класс риска определять либо единым образом для всего класса средств
измерений, либо различать эти классы для категорий СИ, областей применения и т.п. Как
только класс риска выбран, должны рассматриваться только соответствующие ему требования и процедура подтверждения типа.
3.2 Как работать с блоком требований
Каждый блок требований содержит отчетливо выраженное требование. Он состоит из текста, поясняющего определения и разъясняющего специальные примечания из предусмотренной документации, руководства по подтверждению и примеров приемлемых решений
(если они имеются). Содержимое блока требований может подразделяться в соответствии
с классами риска. Схематическое представление блока требований показано на рис. 3.3.
Название требования
Главное содержание требования (возможно различающееся в соответствии с классами
риска)
Специальные примечания (область применения, дополнительные пояснения, исключительные случаи и т.п.)
Предусмотренная документация (возможно различающаяся в соответствии с классами
риска)
Руководство по подтвер- Руководство по подтвер- …
ждению для одного класса ждению для другого класса
риска
риска
Пример приемлемых ре- Пример приемлемых ре- …
шений для одного класса шений для другого класса
риска
риска
Рис. 3.3. Структура блока требований
Блок требований представляет собой техническое содержание требования, включая руководство по подтверждению. Блок адресован как изготовителю, так и уполномоченным органам (организациям) с двумя целями: (1) чтобы рассматривать это требование как минимальное условие и (2) не налагать какие-то дополнительные требования.
(Примечание переводчика: под уполномоченными органами (организациями) (notified
bodies - NB) понимаются органы (организации), уполномоченные (аккредитованные) в
установленном порядке для проведения работ по испытаниям средств измерений с целью
утверждения типа, по их поверке и калибровке и/или подтверждению их соответствия
определенным требованиям - сертификации).
Рекомендации для изготовителя:
- Обратить внимание на главное содержание требования и дополнительные специальные примечания.
- Обеспечить документацию в соответствии с требованием.
- Приемлемые решения являются примерами того, как требования исполняются. Тем
не менее, не обязательно следовать им.
- Руководство по подтверждению имеет информационный характер.
14
Рекомендации для уполномоченных органов (организаций):
- Обратить внимание на главное содержание требования и дополнительные специальные примечания.
- Следовать руководству по подтверждению.
- Подтверждать полноту представленной документации.
3.2. Как работать с контрольными таблицами.
Контрольные таблицы являются средством, с помощью которого можно удостоверится,
что все требования, изложенные в главе, полностью выполнены изготовителем или проверяющим. Они являются частью акта испытаний образца. Необходимо подчеркнуть, что
контрольные таблицы носят подытоживающий характер, и не делают различия между
классами риска. Контрольные таблицы не заменяют определения требований. Для полного
описания необходимо иметь дело с блоками требований.
Рекомендуемая процедура:
- Составить контрольные таблицы, которые соответствуют процедурам, описанным в
шагах 1, 2 и 3 раздела 3.2.
- Следовать контрольным таблицам и убедиться, что все требования удовлетворены.
- Заполнять контрольные таблицы как требуется.
4
Основные требования к встроенному в специализированные средства измерений
программному обеспечению (тип Р)
Набор требований, приводимый в этом разделе, предъявляется к специализированным
средствам измерений с встроенным программным обеспечением или к компоненту средства измерений, который использует такое же программное обеспечение. Требования
предъявляются и к программному обеспечению подсистем, даже если о них не упоминается в тексте.
Если же средство измерений используется с универсальным компьютером (в общем случае с РС), к нему предъявляются требования, изложенные в следующем разделе (средства
измерений типа U). Требования, предъявляемые к средствам измерений типа U, должны
использоваться и в том случае, если в последующем техническом описании отсутствует
упоминание о специализированных средствах измерений с встроенным программным
обеспечением.
4.1 Техническое описание
Средство измерений типа Р является измерительным прибором с встроенной информационно-технологической системой (в общем случае это микропроцессорная или микроконтроллерная система). Оно характеризуется следующими особенностями:
 Все прикладное программное обеспечение разрабатывается для конкретной измерительной задачи. Оно включает в себя как функции, подлежащие контролю, так и
иные функции.
 Программное обеспечение разрабатывается и используется как целое без его разделения, подобного тому, которое описано в Приложении S.
 Интерфейс пользователя приспособлен для измерительной цели, т.е. в обычном
режиме является предметом законодательного (метрологического) контроля. Если
возможно, то переключение между режимами законодательно не контролируется.
 Отсутствует операционная система, имеющая оболочку, доступную пользователю
(загрузочные программы, передача команд операционной системе и т.п.).
15



Программное обеспечение и его окружение являются неизменными, отсутствуют
средства для программирования или изменения его юридически значимых функций.
Допускаются интерфейсы для передачи измеренных данных посредством отрытых
или закрытых сетей связи (см. Приложение D).
Допускается сохранение измеренных данных на встроенном, удаленном или переносном носителе (см. Приложение L).
4.2 Специальные требования для программного обеспечения средств измерений типа
Р
Риски классов от В до Е
Р1: Документация
В дополнение к специальной документации, необходимой в каждом из последующих требований,
документация должна включать в себя следующие основные документы:
а. Описание юридически значимого программного обеспечения.
b. Описание точности измерительных алгоритмов (т.е. точности вычислений и алгоритмы
округления).
c. Описание интерфейса пользователя, меню и диалогов.
d. Однозначную идентификацию программного обеспечения..
e. Обзор системного аппаратного обеспечения, например, топологию блочной диаграммы, тип
компьютера(ов), тип сети и т.п., если это не описано в руководстве оператора.
f. Руководство оператора.
Риск класса В
Риск класса С
Риск класса D
Р2: Идентификация программного обеспечения
Юридически значимое программное обеспечение должно быть однозначно идентифицируемо.
Идентификация должна быть жестко привязана к самой программе. Она должна быть представлена либо в виде команды, либо проявляться в течение действия программы.
Специальные примечания:
Специальные примечания:
1. Изменения юридически
1. В дополнение к 1В: Каждое изменение юридически зназначимого
программного
чимого программного обеспечения, зафиксированнообеспечения требует инфорго при утверждения типа, требует новой программной
мирования об этом уполномоидентификации.
ченного органа. Уполномоченный орган решает, необходима ли идентификация нового программного обеспечения или нет. Новая идентификация
программного
обеспечения требуется только
тогда, когда изменения программного обеспечения приводят к изменению уже утвержденных функций или характеристик.
2. Программная идентификация должна иметь структуру, которая однозначно идентифицирует версии, необходимые при утверждения типа, а также версии, которые не нужны при
таком утверждении.
3. Если функции программного обеспечения могут переключаться параметрами типа, то
каждая функция или вариант могут идентифицироваться отдельно или, как альтернатива,
весь программный пакет может быть идентифицирован как целое.
16
Требования к документации:
Документация должна содержать список программной идентификации и описывать, как создается программная идентификация, как она встроена в программный продукт, как она может быть доступна для рассмотрения и как она структурирована для того, чтобы различать изменения версий, требуемые или
не требуемые при утверждении типа.
Требования к документации
(в дополнение к требованиям к
документации для риска классов В и С):
Документация должна показывать меры, предпринимаемые
для защиты программной идентификации от фальсификации.
Руководство по подтверждению:
Проверки, основанные на документации:
 Оценивается описание генерации и визуализации программной идентификации.
 Проверяется, все ли юридически значимые функции
программного обеспечения четко идентифицированы и
описаны так, что как уполномоченному органу, так и
производителю ясно, какие программные функции
охватываются идентификацией, а какие нет.
 Проверяется, поставляется ли производителем номинальное значение идентификации (номер версии или
контрольная сумма). На это значение должна быть
ссылка в сертификате тестирования.
Функциональные проверки:
 Программная идентификация может визуализироваться
так, как это описано в документации.
 Представление идентификации должно быть точным.
Документация (плюс исходный код, если необходимо) должна
храниться у уполномоченного органа.
Руководство по подтверждению (в дополнение к руководству для риска классов В и С):
Проверки, основанные на документации:
 Проверяется, все ли меры, предпринятые для
предотвращения фальсификации,
являются
достаточными.
Пример приемлемого решения:
 Идентификация юридически значимого программного обеспечения содержит две части. В
первой части (А) происходит изменение идентификации, если измененное программное
обеспечение требует нового утверждения. Часть (В) показывает только незначительные
изменения в программном обеспечении, например, исправление промахов (bug fixes), которые не требуют нового утверждения.
 Идентификация генерируется и показывается по команде.
 Часть (А) идентифика Часть (А) идентификации состоит из автоматически
ции состоит из номера
сгенерированной контрольной суммы, полученной на
версии или номера ТАС
основе юридически значимого программного обеспе(Type Approval Certificate
чения, которое объявляется неизменным при утвержде– сертификат утверждении типа. Для другой части юридически значимого
ния типа).
программного обеспечения часть (А) состоит из номера
версии или номера ТАС.
 Примером приемлемого решения для получения контрольной суммы является алгоритм электронной подписи (the CRC-16 algorithm).
Дополнения для риска класса Е
Требования к документации (в дополнение к требованиям к документации для риска классов В и
С):
Исходный код, содержащий генерацию идентификации.
Руководство по подтверждению (в дополнение к руководству для риска классов В и С):
Проверки, основанные на анализе исходного кода:
 Проверяется, вся ли соответствующая программная часть охвачена алгоритмом генерации
идентификации.
 Проверяется корректность исполнения алгоритма.
17
Риск класса В
Риск класса С
Риск класса D
Р3: Влияние через интерфейс пользователя
Команды, введенные через интерфейс пользователя, не должны оказывать недопустимое влияние
на юридически значимое программное обеспечение и данные измерений.
Специальные примечания:
1. Команды могут быть как единичными командами, так и в виде последовательности переключений или клавишных манипуляций, выполняемых вручную.
2. Это означает, что имеется однозначное назначение каждой команды для инициирования
функции или изменения данных.
3. Это означает, что переключение или клавишные манипуляции, которые не декларированы
и не документированы как команды, не должны оказывать воздействия на функции прибора
и данные измерений.
Требования к документации (в
Требования к документации:
Если прибор обладает способностью воспринимать команды, дополнение к требованиям к додокументация должна включать:
кументации для риска классов В
 Полный перечень всех команд (например, список ме- и С):
 Документация
должна
ню) вместе с декларированием его полноты.
показывать меры, пред Краткое описание их назначения и их воздействия на
принятые для подтверфункции и данные измерений.
ждения полноты документации на команды.
 Документация
должна
содержать протокол, который показывал бы проверку (тестирование) всех
команд.
Руководство по подтверждению:
Руководство по подтверждению
Проверки, основанные на документации:
(в дополнение к руководству для
 Делается заключение о том, все ли команды приемле- риска классов В и С):
мы, т.е. позволяют ли они влиять на измерительные Проверки, основанные на документации:
функции (и соответствующие данные) или нет.
 Проверяется,
действи Проверяется, действительно ли точно декларирована
тельно ли предпринятые
полнота поставленной производителем программной
меры и тестовые протодокументации.
колы соответствуют выФункциональные проверки:
сокому уровню защиты.
 Выполняются практические тесты (выборочные проверки) как документированных, так и не документированных команд. Тестируется весь список меню, если он
имеется.
Пример приемлемого решения:
Имеется программный модуль, который получает и интерпретирует команды от интерфейса пользователя. Этот модуль относится к юридически значимому программному обеспечению. Он только
пересылает дозволенные команды другим юридически значимым программным модулям. Все неизвестные или недозволенные последовательности переключений или клавишные манипуляции
отвергаются и не влияют на юридически значимое программное обеспечение или данные измерений.
Дополнения для риска класса Е
Требования к документации (в дополнение к требованиям к документации для риска классов В и
С):
Исходный код прибора.
Руководство по подтверждению (в дополнение к руководству для риска классов В и С):
Проверки, основанные на анализе исходного кода:
 Поверяется исполнение программы на предмет того, однозначно ли определен поток данных, относящихся к командам в юридически значимом программном обеспечении, или он
18


может меняться.
Исследуется наличие защиты от недопустимого потока данных от интерфейса пользователя
к другим областям программного обеспечения.
Проверяется с помощью программных средств или вручную, что команды декодируются
корректно и что недокументированные команды отсутствуют.
19
Риск класса В
Риск класса С
Риск класса D
Р4: Влияние через интерфейс связи
Команды, введенные через интерфейс связи средства измерений, не должны оказывать недопустимое влияние на юридически значимое программное обеспечение и данные (результаты) измерений.
Специальные примечания:
1. Это означает, что должно быть однозначное назначение каждой команды для инициирования функции или изменения данных.
2. Это означает, что сигналы или коды, которые не декларированы и не документированы как
команды, не должны оказывать никакого влияния на функции средства измерений и данные.
3. Команды могут быть последовательностью электрических (оптических, электромагнитных
и т.п.) сигналов на входных каналах или кодах в протоколах передачи данных.
4. Ограничения этого требования приостанавливаются, когда проводится загрузка программного обеспечения в соответствии с Приложением D.
5. Это требование применяется только к интерфейсам, которые не опечатаны.
Требования к документации (в
Требования к документации:
Если средство измерений имеет интерфейс, то документация дополнение к требованиям к додолжна включать:
кументации для риска классов В
 Полный список всех команд вместе с декларацией об и С):
его полноте.
 Документация
должна
показывать меры, пред Краткое описание их назначения и их воздействия на
принятые для подтверданные и функции средства измерений.
ждения полноты документации команд.
 Документация
должна
содержать протокол, который показывает тесты
команд или, как альтернативу, любые другие подходящие меры, доказывающие их правильность.
Руководство по подтверждению:
Руководство по подтверждению
Проверки, основанные на документации:
(в дополнение к руководству для
 Делается заключение о том, что все документирован- риска классов В и С):
ные команды допустимы, т.е. они обладают допусти- Проверки, основанные на докумым влиянием на функции средства измерений (и соот- ментации:
 Проверяется,
действиветствующие данные) или совсем не обладают.
тельно ли предпринятые
 Проверяется, предоставил ли производитель точную
меры и тестовые протодекларацию полноты командной документации.
колы соответствуют выФункциональные проверки:
сокому уровню защиты.
 Выполняются практические тесты (выборочные проверки) с использованием периферийного оборудования,
если оно доступно.
Примечание: Если невозможно исключить недопустимое воздействие
на измерительные функции (или соответствующие данные) через
интерфейс и программное обеспечение не может быть скорректировано соответствующим образом, тогда сертификат тестирования
должен содержать указание о том, что интерфейс не защищен, и описывать требуемые защитные/пломбировочные средства. Это также
относится к интерфейсам, которые не описаны в документации.
Пример приемлемого решения:
Имеется программный модуль, который получает и интерпретирует данные с интерфейса. Этот модуль является частью юридически значимого программного обеспечения. Он только пересылает
дозволенные команды другим юридически значимым программным модулям. Все неизвестные или
недозволенные последовательности сигналов или кодов отвергаются и не влияют на юридически
20
значимое программное обеспечение или данные измерений.
Дополнения для риска класса Е
Требования к документации (в дополнение к требованиям к документации для риска классов В и
С):
Исходный код прибора.
Руководство по подтверждению (в дополнение к руководству для риска классов В и С):
Проверки, основанные на анализе исходного кода:
 Поверяется исполнение программы на предмет того, однозначно ли определен поток данных, относящихся к командам в юридически значимом программном обеспечении, или он
может меняться.
 Исследуется наличие защиты от недопустимого потока данных от интерфейса к другим областям программного обеспечения.
 Проверяется с помощью программных средств или вручную, что команды декодируются
корректно и что недокументированные команды отсутствуют.
21
Риск класса В
Риск класса С
Риск класса D
Р5: Защита от случайных или непреднамеренных изменений
Юридически значимое программное обеспечение и измеренные данные должны быть защищены
от случайных или непреднамеренных изменений.
Специальные примечания:
Возможными причинами случайных изменений и дефектов программных продуктов могут быть:
непредсказуемые физические воздействия, эффекты, обусловленные действиями пользователя и
остаточными дефектами программного обеспечения, даже если используются современные методы разработки. Это требование включает:
a) Физические воздействия: Сохраненные данные измерений должны быть защищены от искажения или удаления, когда дефект имеет место, или, как альтернатива, дефект должен быть обнаруживаемым.
b) Действия пользователя: Должно требоваться подтверждение перед удалением или изменением
данных.
c) Дефекты программного обеспечения: Должны быть предприняты необходимые меры для защиты данных от непреднамеренных изменений, которые могут происходить из-за некорректного программного исполнения или ошибок программирования, например, проверки правильности (правдоподобия).
Требования к документации:
Документация должна показывать меры, предпринятые для защиты программного обеспечения и
данных от непреднамеренных изменений.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, что контрольная сумма программного кода и важных параметров генерируется и проверяется автоматически.
 Проверяется, что перезапись данных не может происходить до конца их периода сохранения, который предложен и документирован производителем.
 Проверяется, что предупреждение доводится до пользователя, если он собирается удалять
файлы данных измерений.
Функциональные проверки:
 Посредством выборочных проверок убеждаются, что если возможно полное удаление, то
предупреждение выдается до уничтожения данных измерений.
Пример приемлемого решения:
 Случайная модификация программного обеспечения и данных измерений может быть проверена расчетом контрольной суммы для значимых частей и сравнением ее с номинальным
значением и остановкой функционирования программы, если она была модифицирована.
 Данные измерений не удаляются без предшествующего разрешения, например, в виде диалогового утверждения или окна, требующего подтверждение удаления.
 Для обнаружения дефектов см. также Приложение I.
Дополнения для риска класса Е
Требования к документации (в дополнение к требованиям к документации для риска классов В, С
и D):
Исходный код прибора.
Руководство по подтверждению (в дополнение к руководству для риска классов В, С и D):
Проверки, основанные на анализе исходного кода:
 Проверяется, все ли необходимые меры предприняты по обнаружению изменений (дефектов).
 Если используется контрольная сумма, то проверятся, что все части юридически значимого программного обеспечения ею охвачены.
22
Риск класса В
Риск класса С
Риск класса D
Р6: Защита от преднамеренных изменений
Юридически значимое программное обеспечение должно быть защищено от несанкционированной модификации, загрузки или перекачки аппаратной памяти (hardware memory).
Специальные примечания:
1. Прибор без интерфейса: Манипуляции с программным кодом могут быть возможны посредством манипуляций с физической памятью, т.е. запоминающее устройство физически удаляется и заменяется другим, содержащим мошенническое программное обеспечением или данные.
Для предотвращения этого как конструкция прибора, так и сама физическая память должны
быть защищены от несанкционированного удаления.
2. Прибор с интерфейсом: Интерфейс должен обладать только такими функциями, которые могут быть подвергнуты проверке. Все функции интерфейса должны подвергаться проверке (см.
P4). Там, где интерфейс используется для программной загрузки, это должно проводиться в соответствии с Приложением D.
3. Данные считаются достаточно защищенными, если они обрабатываются только юридически
значимым программным обеспечением. Если собираются изменять юридически не значимое
программное обеспечение после его утверждения, то это должно сопровождаться требованиями Приложения S.
Требования к документации:
Требования к документации
Документация должна гарантировать, что юридически зна- (в дополнение к требованиям к
чимое программное обеспечение не может быть модифици- документации для риска класровано недопустимым образом.
сов В и С):
Должны быть показаны меры,
предпринятые для защиты от
преднамеренных изменений.
Руководство по подтверждению:
Руководство по подтверждеПроверки, основанные на документации:
нию (в дополнение к руковод Проверяют, что документированные средства, обеспечи- ству для риска классов В и С):
вающие защиту от несанкционированного обмена памяти Проверки, основанные на докуи содержащиеся в программном обеспечении, являются ментации:
Проверяется, действительно ли
достаточными.
 Если память может программироваться внутри схемы предпринятые меры соответ(без съема), проверяется, может ли режим программиро- ствуют требованиям к совревания выводиться из строя электрически и могут ли быть менному высокому уровню зазащищены/опломбированы средства блокировки этого. щиты.
(Для проверки средств загрузки см. Приложение D).
Функциональные проверки:
 Практически тестируется режим программирования и
проверяется, работает ли блокировка.
Пример приемлемого решения:
Прибор опечатывается, и интерфейсы исполняются в соответствии с требованиями Р3 и Р4.
Дополнения для риска класса Е
Требования к документации (в дополнение к требованиям к документации для риска классов В и
С):
Исходный код прибора.
Руководство по подтверждению (в дополнение к руководству для риска классов В и С):
Проверки, основанные на анализе исходного кода:
 В исходном коде проверяется, являются ли соответствующими (достаточными) меры,
предпринятые для обнаружения преднамеренных изменений.
Риск класса В
Риск класса С
Риск класса D
Р7: Защита параметров
Параметры, относящиеся к юридически значимым характеристикам средства измерений, должны
быть защищены от несанкционированной модификации.
23
Специальные примечания:
1. Параметры, определяющие тип средства измерений, должны быть идентичными для каждого
конкретного средства измерений того же типа и в общем случае являться частью программного кода. Следовательно, к ним применимы требования Р6.
2. Защищенные параметры средства измерений могут быть изменены с использованием приборной клавиатуры или переключателя или через интерфейсы, но только до их защиты.
3. Начальные (установочные) параметры средства измерений могут быть изменены после их
защиты.
Требования к документации:
Документация должна описывать все контролируемые параметры, их диапазоны и номинальные значения, где они хранятся, как они могут быть просмотрены, как и когда они защищены, например, до или после подтверждения (верификации).
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, что изменение или подгонка защищаемых параметров прибора является невозможной после
защиты.
 Проверяется, все ли значимые параметры в соответствии со списками (данными в Приложении I) классифицируются как защищаемые.
Функциональные проверки:
 Тестируется настроечный (конфигурационный) режим и
проверяется, делается ли невозможным его функционирование после работ по защите.
 Проверяется классификация и состояние параметров (защищен/начальный – установочный) на дисплее прибора,
если обеспечено подходящее меню.
Требования к документации
(в дополнение к требованиям к
документации для риска классов В и С):
Должны быть показаны меры,
предпринятые для защиты от
изменений.
Руководство по подтверждению (в дополнение к руководству для риска классов В и С):
Проверки, основанные на документации:
Проверяется, действительно ли
предпринятые меры соответствуют требованиям к современному высокому уровню защиты.
Пример приемлемого решения:
a) Параметры защищаются посредством опломбирования прибора или носителя памяти и
придания невозможности записи через вход микросхемы памяти «возможно/невозможно»
посредством перемычки или переключателя, которые пломбируются.
Контрольный журнал:
b) Счетчик событий записывает каждое изменение значения параметра. Фактическое значение счета может
отображаться и сравниваться с начальным значением
счетчика, которое было записано при последнем официальном подтверждении (верификации) и нанесено на
прибор.
c) Изменения параметров регистрируются в журнале со÷
бытий. Это информация записывается для сохранения
в неизменяемой памяти. Каждый вход автоматически
генерируется и содержит:
 идентификацию параметра (например, название).
 значение параметра (текущее или предыдущее значение),
 отметку времени изменения.
Журнал событий не может быть уничтожен или изменен без
нарушения пломбы.
24
Риск класса Е
Требования к документации (в дополнение к требованиям к документации для риска классов В и
С):
Исходный код, показывающий способ защиты и наблюдения юридически значимых параметров.
Руководство по подтверждению (в дополнение к руководству для риска классов В и С):
Проверки, основанные на анализе исходного кода:
 В исходном коде проверяется, являются ли соответствующими (достаточными) меры,
предпринятые для обнаружения преднамеренных изменений (подстройка, например, режима блокировки после защиты).
25
5 Основные требования к программному обеспечению средств измерений, использующих универсальный компьютер (тип U)
5.1 Техническое описание
Набор требований к программному обеспечению, приводимый в этом разделе, применим
к средствам измерений, использующим компьютер общего назначения. Техническое описание измерительных систем типа U обобщается в таб. 5.1, приводимой ниже. С системой
типа U имеют дело тогда, когда условия реализации средства измерений типа Р (см. главу
4.1) не выполняются.
Таблица 5.1 Техническое описание средства измерений типа U
Аппаратная конфигурация
а) Система основывается на компьютере общего назначения. Компьютерная система может состоять из единственного компьютера, быть частью закрытой сети, например, кабельной, многопроцессорной системы LAN, или частью открытой сети, например, Интернета.
b) Поскольку система является системой общего назначения, то датчик должен быть внешним
устройством по отношению к компьютеру и должен быть связан с ним посредством закрытой линии связи. Однако линия связи может быть также и открытой, например, может быть сетью, посредством которой могут быть связаны несколько датчиков.
c) Интерфейс пользователя может переключаться от режима функционирования, который не подлежит законодательному (метрологическому) контролю, к режиму, который является объектом
контроля, и наоборот.
d) Сохранение данных может быть локализованным, например, на твердом диске, или удаленным,
например, на сервере (центральном компьютере сети) файлов. Удаленное сохранение может быть
локализовано где угодно, например, в том же самом здании или даже в другой стране, которая
может и не входить в состав ЕС. Таким образом, линия связи с сохраняющими устройствами может быть прямой с аппаратным подтверждением связи, или не прямой, состоящей из промежуточных фаз сохранения, не контролируемых пользователем, например, из вызова по номеру через Интернет. Сохранение может быть фиксированным, например, на твердом диске, или переносным,
например, на дискетах и CD.
Конфигурация программного обеспечения
e) Может использоваться любая операционная система. В дополнение к приложению, используемому для средства измерений, в системе в то же самое время могут также существовать другие
программные приложения. Часть программного обеспечения, например, относящаяся к приложению для средства измерений, является предметом законодательного контроля и не может модифицироваться после утверждения типа. Часть программного обеспечения, не являющаяся
предметом контроля, может быть свободно модифицирована.
f) Операционная система и драйверы низкого уровня, например, видеодрайверы, драйверы принтера, драйверы дисков и т.п. не подлежат законодательному (метрологическому) контролю до тех
пор, пока они специально не запрограммированы для выполнения измерительной задачи.
26
5.2 Специальные требования для программного обеспечения средств измерений типа
U
Риски классов от В до Е
U1: Документация
В дополнение к специальной документации, необходимой в каждом из последующих требований,
документация должна включать в себя следующие основные документы:
а. Описание юридически значимых программных функций, значимых данных и т.п.
b. Описание точности измерительных алгоритмов (т.е. точности вычислений и алгоритмы округления).
c. Описание интерфейса пользователя, меню и диалогов.
d. Идентификацию юридически значимого программного обеспечения.
e. Обзор аппаратной системы (of the system hardware), например, топологию блочной диаграммы,
тип компьютера(ов), тип сети и т.п., если это не описано в руководстве оператора.
f. Обзор аспектов безопасности операционной системы, например, защиты, допуска пользователя, привилегий и.т.п.
g. Руководство оператора.
Риск класса В
Риск класса С
Риск класса D
U2: Идентификация программного обеспечения
Юридически значимое программное обеспечение должно быть однозначно идентифицируемо.
Идентификация должна быть жестко привязана к самой программе. Она должна быть представлена либо в виде команды, либо проявляться в течение действия программы.
Специальные примечания:
Специальные примечания:
1. Идентификация не распро- 1. Ограничение 1В: Драйверы (низкого уровня), которые опрестраняется на операционную
делены как значимые для утверждения типа, должны быть
систему и драйверы низкого
идентифицированы.
уровня, например, видеодрай- 2. Дополнение к 2В. Каждое изменение юридически значимого
веры, драйверы принтера,
программного обеспечения, зафиксированного при утвердрайверы дисков и т.п., но она
ждения типа, или изменение параметров, определяющих тип
распространяется на драйверы,
средства измерений, требует новой программной идентифиспециально
запрограммирокации.
ванные для выполнения юридически значимых измерительных задач.
2. Изменения юридически значимого программного обеспечения требуют информирования об этом уполномоченного
органа. Уполномоченный орган решает, необходима ли
идентификация нового программного обеспечения или
нет. Новая идентификация
программного
обеспечения
требуется только тогда, когда
его изменения приводят к изменению уже утвержденных
функций или характеристик.
27
3. Программная идентификация должна иметь структуру, которая однозначно идентифицирует
версии, необходимые при утверждения типа, а также версии, которые не нужны при таком
утверждении.
4. Идентификация может применяться к разным уровням, например, к программе в целом, к модулям, функциям и т.п.
5. Если функции программного обеспечения могут переключаться с помощью параметров, то
каждая функция или вариант могут идентифицироваться отдельно или весь программный пакет может быть идентифицирован как целое.
Требования к документации (в
Требования к документации:
Документация должна содержать список программной иден- дополнение к требованиям к дотификации и описывать, как создается программная идентифи- кументации для риска классов В
кация, как она встроена в программный продукт, как она мо- и С):
жет быть доступна для рассмотрения и как она структурирова- Документация должна показына для того, чтобы различать версии с изменениями, требую- вать меры, предпринимаемые для
щими или не требующими утверждения.
предохранения
программной
идентификации от фальсификации.
Руководство по подтверждению:
Руководство по подтверждению
Проверки, основанные на документации:
(в дополнение к требованиям к
 Оценивается описание генерации и визуализации про- документации для риска классов
В и С):
граммной идентификации.
 Проверяется, все ли юридически значимые функции Проверки, основанные на докупрограммного обеспечения четко идентифицированы и ментации:
 Проверяется,
являются
описаны так, что как уполномоченному органу, так и
ли достаточными меры,
производителю ясно, какие программные функции
предпринятые
для
охватываются идентификацией, а какие нет.
предотвращения
фальси Проверяется, поставляется ли производителем номификации.
нальное значение идентификации (номер версии или
контрольная сумма). На это значение должна быть
ссылка в сертификате тестирования.
Функциональные проверки:
 Проверяется, может ли программная идентификация
визуализироваться так, как это описано в документации.
 Проверяется, является ли представление идентификации точным.
Документация (плюс исходный код, если необходимо) тестируемого ПО должны храниться у уполномоченного органа.
Пример приемлемого решения:
 Идентификация юридически значимого программного обеспечения содержит две части. В
первой части (А) происходит изменение идентификации, если измененное программное
обеспечение требует нового утверждения. Часть (В) показывает только незначительные
изменения в программном обеспечении, например, промахи (bug fixes), которые не требуют нового утверждения.
 Идентификация части (В) генерируется и показывается по команде.
 Часть (А) идентифика Часть (А) идентификации состоит из автоматически
ции состоит из номера
сгенерированной контрольной суммы, полученной на
версии или номера ТАС.
основе фиксированного кода. Для другой части юридиДля предотвращения ее
чески значимого программного обеспечения часть (А)
изменений с помощью
состоит из номера версии или номера ТАС. Для
простых программных
предотвращения изменения идентификации с помощью
средств она сохраняется
простых программных средств она сохраняется в двов двоичной форме в исичной форме в исполнительном программном файле.
28
полнительном
граммном файле.
про-

Примером приемлемого решения для получения контрольной
суммы является алгоритм CRC-16.
Приемлемыми алгоритмами для получения контрольной суммы является
алгоритм CRC-32 или алгоритмы хэширования, подобные SHA-1, MD5,
RipeMD160 и т.п.
Дополнения для риска класса Е
Требования к документации (в дополнение к требованиям к документации для риска классов В
и С):
Исходный код, содержащий генерацию идентификации.
Руководство по подтверждению (в дополнение к руководству для риска классов В и С):
Проверки, основанные на анализе исходного кода:
 Проверяется, все ли значимые программные части охвачены алгоритмом генерации идентификации.
 Проверяется корректность исполнения алгоритма.
Риск класса В
Риск класса С
Риск класса D
U3: Влияние через интерфейс пользователя
Команды, введенные через интерфейс пользователя, не должны оказывать недопустимое влияние
на юридически значимое программное обеспечение и данные (результаты) измерений.
Специальные примечания:
1. Это означает, что имеется однозначное назначение каждой команды для инициирования
функции или изменения данных.
2. Это означает, что переключение или клавишные манипуляции, которые не декларированы
и не документированы как команды, не должны оказывать воздействия на функции прибора
и данные изменений.
3. Команды могут быть как единичными, так и в виде последовательности действий, выполняемых оператором. Пользователь должен быть проинформирован о том, какие команды
позволены.

Требования к документации:
Документация должна включать:
 Полный перечень всех команд вместе с декларированием его полноты.
 Краткое описание их назначения и их воздействия на
функции средства измерений и данные изменений.
4. Пользователь
должен
быть закрытым, т.е. он не
должен быть способен загружать программы, записывать программы или
выполнять команды, относящиеся к операционной системе.
Требования к документации (в
дополнение к требованиям к документации для риска классов В
и С):
 Документация
должна
показывать меры, предпринятые для подтверждения полноты документации на команды.
 Документация
должна
содержать протокол, который показывал бы проверку (тестирование) всех
команд.
29
Руководство по подтверждению:
Проверки, основанные на документации:
 Оценивается, приемлемы ли документированные команды, т.е. позволяют ли они влиять на измерительные
функции (и соответствующие данные) или нет.
 Проверяется, что производитель действительно точно
декларировал полноту командной документации.
Функциональные проверки:
 Выполняются практические тесты (выборочные
проверки) как документированных, так и не документированных команд. Тестируется весь список
меню, если он имеется.
Руководство по подтверждению
(в дополнение к руководству для
риска классов В и С):
Проверки, основанные на документации:
 Проверяется,
действительно ли предпринятые
меры и тестовые протоколы соответствуют высокому уровню защиты.
Пример приемлемого решения:
 Программный модуль в юридически значимом программном обеспечении отфильтровывает
неприемлемые команды. Только этот модуль воспринимает команды, и отсутствуют какиелибо пути его обхода. Любой ложный вход блокируется. Пользователь контролируется или
информируется о входных командах посредством специального программного модуля.
Этот модуль непосредственно связан с модулем, отфильтровывающим неприемлемые команды.
 Доступ к операционной

системе блокируется.
Дополнения для риска класса Е
Требования к документации (в дополнение к требованиям к документации для риска классов В и
С):
Исходный код юридически значимого программного обеспечения.
Руководство по подтверждению (в дополнение к руководству для риска классов В и С):
Проверки, основанные на анализе исходного кода:
 Поверяется исполнение программы на предмет того, однозначно ли определен в юридически значимом программном обеспечении поток данных, относящихся к командам, или он
может меняться.
 Исследуется наличие защиты от недопустимого потока данных от интерфейса пользователя
к другим доменам данных.
 Проверяется с помощью программных средств или вручную, что команды декодируются
корректно и что недокументированные команды отсутствуют.
30
Риск класса В
Риск класса С
Риск класса D
U4: Влияние через интерфейс связи
Команды, введенные через не опечатанные интерфейсы связи, не должны оказывать недопустимое влияние на юридически значимое программное обеспечение и данные (результаты) изменений.
Специальные примечания:
1. Это означает, что имеется однозначное назначение каждой команды для инициирования
функции или изменения данных.
2. Это означает, что сигналы или коды, которые не декларированы и не документированы как
команды, не должны оказывать никакого влияния на измерительные функции и данные.
3. Команды могут быть последовательностью электрических (оптических, электромагнитных
и т.п.) сигналов на входных каналах или кодами в протоколах передачи данных.
4. Ограничения этого требования приостанавливаются, когда проводится загрузка программного обеспечения в соответствии с Приложением D.
5. Те части операционной системы, которые интерпре5. Все программы и программтируют юридически значимые команды, должны расные части, вовлеченные в пересматриваться как относящиеся к юридически значидачу и прием юридически знамому программному обеспечению.
чимых команд или данных,
6. Другие части программного обеспечения могут исдолжны
контролироваться
пользовать интерфейс при условии, что они не искаюридически значимым прожают или не фальсифицируют прием или передачу
граммным обеспечением.
юридически значимых команд или данных.
Интерфейс, который принимает
и передает юридически значимые команды или данные, должен быть предназначен для
этой роли и может использоваться только посредством
юридически значимого программного обеспечения. Стандартные интерфейсы не являются исключением при условии, что средства защиты программного обеспечения исполнены в соответствии с требованиями Приложения T.
Требования к документации (в
Требования к документации:
Документация должна включать:
дополнение к требованиям к доку Полный список всех команд вместе с декларацией об ментации для риска классов В и С):
его полноте.
 Документация должна показывать меры, предприня Краткое описание их назначения и их действия на
тые для подтверждения
функции средства измерений и данные.
полноты документации команд.
 Документация должна содержать протокол, который
показывает тесты команд
или, как альтернативу, любые другие
подходящие
меры, доказывающие их
правильность.
31
Руководство по подтверждению:
Проверки, основанные на документации:
 Делается заключение о том, что все документированные команды допустимы, т.е. что они обладают
допустимым влиянием на юридически значимое программное обеспечение (и соответствующие данные)
или совсем не обладают.
 Проверяется, предоставил ли изготовитель точную
декларацию полноты командной документации.
Функциональные проверки:
 Выполняются практические тесты (выборочные проверки) с использованием периферийного оборудования, если оно доступно.
Руководство по подтверждению
(в дополнение к руководству для
риска классов В и С):
Проверки, основанные на документации:
 Проверяется, действительно ли предпринятые меры и
тестовые протоколы соответствуют высокому уровню защиты.
Пример приемлемого решения:
Имеется программный модуль, который получает и интерпретирует команды с интерфейса. Этот
модуль является частью юридически значимого программного обеспечения. Он только пересылает
дозволенные команды другим юридически значимым программным модулям. Все неизвестные или
недозволенные последовательности сигналов или кодов отвергаются и не влияют на юридически
значимое программное обеспечение или данные измерений.
Дополнения для риска класса Е
Требования к документации (в дополнение к требованиям к документации для риска классов В и
С):
Исходный код прибора.
Руководство по подтверждению (в дополнение к руководству для риска классов В и С):
Проверки, основанные на анализе исходного кода:
 Поверяется исполнение программы на предмет того, однозначно ли определены в юридически значимом программном обеспечении команды, относящиеся к потоку данных, и могут
ли они быть подтверждены (аттестованы).
 Исследуется наличие защиты от недопустимого потока данных от интерфейса к другим доменам данных.
 Проверяется с помощью программных средств или вручную, что команды декодируются
корректно и что недокументированные команды отсутствуют.
32
Риск класса В
Риск класса С
Риск класса D
U5: Защита от случайных или непреднамеренных изменений
Юридически значимое программное обеспечение и данные измерений должны быть защищены от
случайных или непреднамеренных изменений.
Специальные примечания:
1. Непреднамеренные изменения могут быть вызваны:
a. Некорректным программным исполнением, например, некорректным исполнением цикла, изменением глобальных переменных в функциях и т.п.
b. Неправильным использованием операционной системы.
c. Случайной перезаписью или уничтожением сохраняемых данных и программ (см. также Приложение L).
d. Неправильным заданием протокола данных измерений. Измерения и данные, принадлежащие к
одному измерительному протоколу, не должны смешиваться с другим протоколом, что может быть
обусловлено некорректным программированием или сохранением.
e. Физическими эффектами (электромагнитные воздействия, температура, вибрация и т.п.).
Требования к документации (в
Требования к документации:
Документация должна показывать меры, предпринятые для дополнение к требованиям к докузащиты программного обеспечения и данных от непредна- ментации для риска классов В и С):
меренных изменений.
Документация должна показывать
меры, предпринятые для подтверждения эффективности средств защиты.
Руководство по подтверждению:
Руководство по подтверждению
Проверки, основанные на документации:
(в дополнение к руководству для
 Проверяется, что контрольная сумма программного риска классов В и С):
кода и важных параметров генерируется и проверяет- Проверки, основанные на документации:
ся автоматически.
 Проверяется, действитель Проверяется, что перезапись данных не может происно ли предпринятые меры
ходить до конца их периода сохранения, который
соответствуют
высокому
предложен и документирован изготовителем.
уровню защиты.
 Проверяется, что до пользователя доводится предупреждение, если он собирается удалять файлы данных измерений.
Функциональные проверки:
 Посредством выборочных проверок убеждаются,
что если возможно полное удаление, то предупреждение выдается до уничтожения данных измерений.
Пример приемлемого решения:
 Защита от некорректного программного исполнения – быть вне таких классов риска.
 Неправильное использование операционной системы, случайная перезапись или уничтожение сохраняемых данных и программ – производитель должен полностью использовать меры защиты или права собственника производителя операционной системы или программного языка.
 Случайная модификация программного обеспечения и файлов данных может быть проверена расчетом контрольной суммы для значимого кода и сравнением ее с номинальным
значением, а также остановкой функционирования программы, если код был модифицирован или соответствующим образом видоизменен, если параметры или данные представляют
интерес.
 Там, где операционная система позволяет, рекомендуется, чтобы все права пользователя на
удаление, передвижение или исправление юридически значимого программного обеспечения были исключены и должны контролироваться посредством обслуживающих программ.
Рекомендуется доступный контроль программ и данных с помощью паролей, т.е. с использованием только механизмов чтения. Система надзора должна восстанавливать права только тогда, когда требуется.
33
Дополнения для риска класса Е
Требования к документации (в дополнение к требованиям к документации для риска классов В и
С):
Исходный код прибора.
Руководство по подтверждению (в дополнение к руководству для риска классов В и С):
Проверки, основанные на анализе исходного кода:
 Проверяется, предприняты ли все необходимые меры по обнаружению изменений (дефектов).
 Если используется контрольная сумма, то проверятся, все ли части юридически значимого
программного обеспечения охвачены ею.
34
Риск класса В
Риск класса С
Риск класса D
U6: Защита от преднамеренных изменений
Юридически значимое программное обеспечение и данные измерений должны быть защищены от
несанкционированной модификации.
Специальные примечания:
Специальные примечания:
1. Изменения с фальсификационными намерениями могут
1. Уровень защиты должен
быть предприняты посредством:
быть эквивалентен тому,
а. Изменения программного кода, включая интегрированные
который используется при
данные – если программный код представлен исполнительэлектронной оплате.
ным форматом (.exe) и имеет достаточную защиту для рис- В общем случае, этот класс риска
ков классов В и С.
рассматривается только для униb. Изменения данных измерений – см. также Приложение L.
версального компьютера с допол2. Замена лицензионного программного обеспечения не нительной аппаратной частью для
должна быть возможной простым использованием операци- обеспечения безопасности.
онной системы, например, загрузкой и использованием вместо него нелицензионного программного обеспечения (см.,
например, U3). Для загрузки программного обеспечения см.
Приложение D.
3. Если необходимо, должны быть предприняты меры защиты юридически значимого программного обеспечения от модификации с помощью простых средств, например, с помощью текстового или «оконного» редакторов.
Требования к документации (в
Требования к документации:
Документация должна гарантировать, что программное обес- дополнение к требованиям к докупечение и измеренные данные не могут быть модифицирова- ментации для риска классов В и С):
ны недопустимым образом.
Должны быть показаны меры защиты.
Руководство по подтверждению:
Руководство по подтверждению
Случай 1. Закрытая оболочка программного обеспечения (в дополнение к руководству для
является предметом метрологического контроля.
риска классов В и С):
Проверки, основанные на документации:
Проверки, основанные на докумен Начальная загрузка модулей программного обеспече- тации:
 Проверяется, действительния проводится автоматически.
но ли предпринятые меры
 Пользователь не имеет доступа к операционной сисоответствуют
современстеме РС.
ному
высокому
уровню
за Пользователь имеет доступ только к той части прощиты.
граммного обеспечения, с которой он работает.
 Предоставляется письменная декларация, заверяющая, что в программном обеспечении отсутствуют
скрытые функции, обходящие его закрытую оболочку.
Случай 2. Пользователю доступны операционная система
и/или программное обеспечение.
Проверки, основанные на документации:
 Генерируется контрольная сумма всего машинного
кода модулей программного обеспечения.
Юридически значимое программное обеспечение не может
быть запущено, если его код изменен.
Пример приемлемого решения:
Пример приемлемого решения:
 Программный код и данные могут быть защищены
 Программный код может
посредством контрольной суммы. Программа вычисбыть защищен хранением
ляет собственную контрольную сумму и сравнивает
юридически
значимого
ее с требуемым значением, которое скрыто в исполпрограммного обеспечения
няемом коде. Если самопроверка ошибочна, пров специальном сменном
грамма блокируется.
модуле, который пломбируется. Специальный смен Любой алгоритм подписи должен иметь код длинной
35

не меньше 2 байт; контрольная сумма CRC-16 c секретным начальным вектором (скрытым в исполнительном коде) должна быть правильной. (См. также
Приложения L и T).
Запрещенные манипуляции с юридически значимым
программным обеспечением могут контролироваться
допускным контролем или персональными атрибутами защиты операционной системы. Уровень администратора таких систем должен быть защищен пломбированием или эквивалентным средством.
ный модуль может состоять, например, из памяти,
предназначенной
только
для чтения, или микроконтроллера.
Дополнения для риска класса Е
Требования к документации (в дополнение к требованиям к документации для риска классов В и
С):
Исходный код прибора.
Руководство по подтверждению (в дополнение к руководству для риска классов В и С):
Проверки, основанные на анализе исходного кода:
 Проверяется связь с дополнительным охранным аппаратным обеспечением.
 Проверяется, что изменения в программе или в данных обнаруживаются, и в этом случае
выполнение программы останавливается.
36
Риск класса В
Риск класса С
Риск класса D
U7: Защита параметров
Юридически значимые параметры должны быть защищены от несанкционированной модификации.
Специальные примечания:
1. Параметры, определяющие тип средства измерений, должны быть идентичными для каждого конкретного средства измерений того же типа и в общем случае являются частью программного кода, т.е. частью юридически значимого программного обеспечения. Следовательно, к ним применимы требования U6.
2. Параметры средства измерений:
 «Защищенные» параметры могут быть изменены с использованием приборной клавиатуры или переключателя, или через интерфейсы, но только до их защиты. Поскольку
параметры средства измерений могут видоизменяться с использованием средств универсального компьютера, то они не должны храниться в стандартной памяти компьютера. Сохранение таких параметров допустимо только в дополнительных аппаратных
средствах.
 Начальные (установочные) параметры средства измерений могут быть изменены после
их защиты.
Требования к документации:
Документация должна описывать все юридически значимые
параметры, их области изменений и номинальные значения,
где они хранятся, как они могут визуализироваться, как и когда они защищены, т.е. до или после их подтверждения.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяют, что метод защиты параметров, характеризующих тип, является подходящим.
 Проверяется, что параметры средства измерения не сохраняются в стандартной памяти универсального компьютера, но хранятся в отдельном аппаратном средстве, которое может опечатываться и быть недоступным для перезаписи.
Функциональные проверки:
 Тестируется режим регулировки (конфигурации) и проверяется, заблокирован ли он после защиты.
 Проверяется классификация и состояние параметров (защищен/установлен) на дисплее прибора, если имеется соответствующее меню.
ТАС должен иметь список тех параметров, которые устанавливаются, и как они могут быть расположены.
Требования к документации
(в дополнение к требованиям к
документации для риска классов В и С):
Должны быть показаны меры,
предпринятые для защиты параметров от изменений.
Руководство по подтверждению (в дополнение к руководству для риска классов В и С):
Проверки, основанные на документации:
Проверяется, предприняты ли
все необходимые меры в соответствии с требованиями к современному высокому уровню
защиты.
Пример приемлемого решения:
 Параметры средства измерения сохраняются на сменном сохраняющем устройстве, которое опечатывается для предотвращения изъятия, или напрямую выводятся на сенсорное устройство. Запись параметров блокируется опечатыванием перезаписывающего
переключателя в блокирующем состоянии. Контрольный журнал возможен в комбинации с защитным аппаратным обеспечением (см. Р7).
 Установочные параметры хранятся в стандартной памяти универсального компьютера.
37
Дополнения для риска класса Е
Требования к документации (в дополнение к требованиям к документации для риска классов В и
С):
Исходный код прибора.
Руководство по подтверждению (в дополнение к руководству для риска классов В и С):
Проверки, основанные на анализе исходного кода:
Проверяется, являются ли достаточными меры, предпринятые для предохранения параметров.
38
Риск класса В
Риск класса С
Риск класса D
U8: Подлинность программного обеспечения и представления результатов
Должны быть использованы средства, гарантирующие подлинность юридически значимого программного обеспечения. Должна быть гарантирована подлинность представляемых результатов.
Специальные примечания:
Специальные примечания:
1. Не должна быть возможной мошенническая подделка (фаль1. Ограничения к 1ВС и
сификация) утвержденного юридически значимого про2ВС:
граммного обеспечения с помощью простых программных
Средства, требуемые для
средств.
предохранения
против
2. Представляемые результаты могут рассматриваться как подпреднамеренного злоуполинные, если представление имеет своим источником юритребления, включая поддически значимое программное обеспечение.
делку, основываются на
дополнительном аппаратном обеспечении.
3. Представляемые значения измерений должны сопровождаться информацией, необходимой для
избежания путаницы с другой (юридически не значимой) информацией.
4. С помощью технических средств должно гарантироваться, что программное обеспечение универсального компьютера, утвержденное для юридически значимых целей, может выполнять
только юридически значимые функции (например, датчик может работать только вместе с
утвержденной программой).
Требования к документации:
Требования к документации
Документация должна описывать, как гарантируется подлин- (в дополнение к требованиям к
ность программного обеспечения.
документации для риска классов В и С):
Должны быть показаны меры
защиты.
Руководство по подтверждению:
Руководство по подтверждеПроверки, основанные на документации:
нию (в дополнение к руковод Необходима проверка для определения того, что ству для риска классов В и С):
представление результатов производятся юридически Проверки, основанные на докузначимым программным обеспечением, и того, как ментации:
может быть предотвращена подделка посредством
 Проверяется, предприюридически не значимых программ.
няты ли все необходимые меры в соответ Проверяется, что юридически значимые задания моствии с требованиями к
гут быть выполнены только утвержденным юридичесовременному высокоски значимым программным обеспечением.
му уровню защиты.
Функциональные проверки:
 Посредством визуального контроля проверяется, что
если представляются результаты, то они легко отличаются от другой информации, которая может быть
также представлена.
 В соответствии с документацией проверяется, что
представляемая информация является полной.
Пример приемлемого решения:
Формальные средства:
1. Идентификационная часть (В) (контрольная сумма, номер версии или номер ТАС, см. U2),
показываемая программным обеспечением, сравнивается с нужным значением ТАС.
Технические средства:
1. Измерительное прикладное «окно» генерируется юридически значимым программным
обеспечением. Технические средства, требуемые для такого «окна»:
 Никакого доступа к значениям измерений не должно даваться юридически не значимыми программами до тех пор, пока значения измерений не будут показаны.
 «Окно» периодически обновляется. Соответствующие программные проверки всегда явны.
 Обработка значений измерений останавливается, если «окно» закрыто или не пол-
39
ностью видимо.
Руководство по эксплуатации (и ТАС) должно содержать копию «окна» для целей сравнения.
2а Датчик шифрует значения измерений ключом, известным утвержденному программному обеспечению, запускаемому на универсальном компьютере (например, его номером версии). Только утвержденное программное обеспечение может дешифровать и использовать
значения измерений, поскольку не утвержденные программы на универсальном компьютере не могут этого сделать, так как для них ключ не известен. Для обращения с ключом см.
Приложение Т.
2b До пересылки значений измерений датчик инициирует процесс подтверждения связи с
юридически значимым программным обеспечением на универсальном компьютере, основанный на секретных ключах. Только в том случае, если программа на универсальном компьютере обеспечивает связь корректно, датчик пересылает свои значения измерений. Для
обращения с ключом см. Приложение Т.
3. Ключи, используемые
3. Ключи, используемые в 2а / 2b являются кодом хэширов 2а / 2b, могут быть
вания программы на универсальном компьютере. Периоизменены и введены в
дически программное обеспечение на универсальном
датчики и программное
компьютере обновляется, при этом новый ключ вводится
обеспечение на персов датчик и опечатывается.
нальном компьютере
без нарушения клейма
(опечатывания).
Дополнения для риска класса Е
Требования к документации (в дополнение к требованиям к документации для риска классов В и
С):
Исходный код юридически значимого программного обеспечения.
Руководство по подтверждению (в дополнение к руководству для риска классов В и С):
Проверки, основанные на анализе исходного кода:
 Проверяется, что юридически значимое программное обеспечение генерирует представление результатов измерений.
 Проверяется, все ли предпринятые меры достаточны и корректны для гарантирования
подлинности программного обеспечения (например, что только юридически значимые
задачи исполняются утвержденным юридически значимым программным обеспечением).
Риск классов от В до Е
U9: Влияние другого программного обеспечения.
Юридически значимое программное обеспечение должно быть исполнено таким образом, чтобы
другое программное обеспечение не могло оказывать на него недопустимое влияние.
Специальные примечания:
Такое требование подразумевает разделение между юридически значимым и не значимым программным обеспечением. Должно приниматься во внимание Приложение S. Это стандартная ситуация для универсальных компьютеров.
Требования к документации:
См. Приложение S.
Руководство по подтверждению:
См. Приложение S.
Пример приемлемого решения:
См. Приложение S.
40
6 Приложение L: Долговременное сохранение данных измерений
В этом Приложении приводятся специальные требования к программному обеспечению,
встроенному в средства измерений целевого назначения (требования типа P), и к программному обеспечению для средств измерений, использующих универсальный компьютер (требования типа U). В нем описываются требования к накопителю измерительной
информации от момента, когда измерение физически закончено, до момента, когда все
процессы, выполняемые юридически значимым программным обеспечением, также закончены. С этого момента они также применимы и к накопителю для длительного хранения измерительной информации.
6.1 Техническое описание
Набор требований, устанавливаемых этим Приложением, применяется только тогда, когда
подключен накопитель для длительного хранения измерительной информации. Это касается только тех данных измерений, которые являются юридически значимыми.
Существует три различные конфигурации для накопителей длительного хранения, приведенные в таб. 6.1. Для средств измерений целевого назначения типичен вариант встроенного накопителя: здесь накопитель является частью метрологически необходимого программного и аппаратного обеспечения. Для средств измерений на основе универсального
компьютера типичен другой вариант: использование уже существующих ресурсов,
например жестких дисков. Третий вариант относится к съемным накопителям: здесь
накопитель может быть извлечен из прибора, который может быть как средством измерения целевого назначения, так и на основе универсального компьютера, а также взят где-то
в другом месте. Когда информация для юридически значимых целей берется со съемного
накопителя, например, отображается, выводится на принтер и т.д., выдающий ее прибор
должен попадать под законодательный (метрологический) контроль.
Таблица 6.1 Техническое описание измерительного оборудования Типа U
Встроенный накопитель
Простое специализированное устройство, существенно не использующее способы или методы для
правки или изменения данных; встроенный накопитель данных измерений или параметров,
например, оперативная память, флэш-память, жесткий диск.
Накопитель для универсального компьютера
Универсальный компьютер, графический пользовательский интерфейс, многофункциональная
операционная система, выполняющая параллельно задачи, являющиеся и не являющиеся предметом законодательного (метрологического) контроля. Накопитель может быть извлечен из устройства, при этом его содержимое может быть скопировано куда-нибудь или внутрь компьютера или
во вне.
Съемный или удаленный накопитель
Произвольное стандартное устройство (предназначенное для конкретной цели или устройство,
использующее универсальный компьютер), накопитель может быть изъят из прибора. Это могут
быть, например, флоппи диски, флэш - карты или удаленные базы данных, подключаемые через
сеть.
6.2 Специальные требования к программному обеспечению для долговременного сохранения
Требования, изложенные в этом разделе, предъявляются в дополнение к набору требований для специализированных средств измерений, или к приборам, использующим универсальный компьютер.
41
Риск класса В
Риск класса С
Риск класса D
L1: Полнота сохраняемых данных измерений
Сохраняемые данные измерений должны содержать всю значимую информацию, необходимую для
восстановления более ранних измерений.
Специальные примечания:
1. Сохраняемые данные измерений могут понадобиться для ссылки на более старые данные,
например, для выставления счетов. Все данные, необходимые для юридических и метрологических
оснований, должны храниться вместе с измеренным значением.
Требования к документации:
Описание всех областей массива данных.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, вся ли информация, необходимая для юридических и метрологических целей,
содержится в массиве данных.
Пример приемлемого решения:
 Юридически и метрологически полный массив данных включает в себя следующие сведения:
o измеренные значения с заданной погрешностью,
o юридически корректная единица измерения,
o цена единицы или полная стоимость (если применяется),
o место и время проведения измерений (если применяется),
o идентификация инструмента, если применяется (внешний накопитель).
 Данные сохраняются с теми же разрешением, значениями, единицами и т.д., что и в выводимой или печатаемой накладной.
Дополнения для риска класса Е
Требования к документации (в дополнение к требованиям к документации для риска классов В,
С и D):
Исходный код, генерирующий массивы данных для хранения.
Руководство по подтверждению (в дополнение к руководству для риска классов В, С и D):
Проверки, основанные на исходном коде:

Проверяется, все ли массивы данных построены корректно.
42
Риск класса В
Риск класса С
Риск класса D
L2: Защита от случайных или непреднамеренных изменений
Сохраняемые данные должны быть защищены от случайных и непреднамеренных изменений.
Специальные примечания:
1. Случайные изменения данных могут быть вызваны физическими эффектами.
2. Непреднамеренные изменения данных производятся пользователем прибора. Дежурный
администратор данных может потребовать удалять время от времени данные, относящиеся
к полностью оплаченным счетам или к счетам с истекшим сроком. Должны использоваться
автоматические и полуавтоматические средства для гарантии того, что удаляются только
специальные данные, и случайное удаление «живых» данных невозможно. Это особенно
важно в сетевых системах и в удаленных или съемных носителях, где пользователь может
не представлять значимость данных.
3. Контрольная сумма должна вычисляться принимающей стороной и сравниваться с прилагаемым номинальным значением. Если значения совпадают, массив верен и может быть использован; в противном случае он должен быть удален или помечен как неверный.
Требования к документации (в
Требования к документации:
Описание мер защиты (например, алгоритма контрольной дополнение к требованиям к досуммы, включая длину образующего полинома).
кументации для риска классов В
и С):
Документация должна показывать меры, принятые для подтверждения эффективности мер
защиты.
Руководство по подтверждению:
Руководство по подтверждению
Проверки, основанные на документации:
(в дополнение к руководству для
 Проверяется, что контрольная сумма всех данных гене- риска классов В и С):
Проверки, основанные на докурируется.
 Проверяется, что юридически значимое программное ментации:
обеспечение, которое читает данные и вычисляет кон- Проверяется, соответствуют ли
трольную сумму, действительно сравнивает вычислен- предпринятые меры высокому
уровню защиты.
ные и номинальные значения.
 Проверяется, что перезапись данных не может происходить до окончания периода их сохранения, который
предусмотрен и документирован производителем.
 Проверяется, что существует предупреждение, выводимое пользователю, если он удаляет файлы с данными
измерений.
Функциональные проверки:

Посредством выборочной проверки убеждаются, что
перед удалением данных измерений, если удаление
возможно, выводится предупреждение.
Пример приемлемого решения:
 Для того, чтобы установить изменение данных вследствие физического эффекта, вычисляется контрольная сумма по всему вводимому массиву данных по алгоритму CRC-16 и выводится в массив данных для сохранения.
Примечание: Алгоритм не является секретным и, в противоположность требованию L3 не является ни
начальным вектором CRC-16, ни образующим полиномом, т.е. делителем. Начальный вектор и образующий полином известны как программам, которые их создают, так и тем, которые проверяют контрольные суммы.


Файлы измеренных данных/счетов должны быть защищены автоматическим добавлением
отметки о дате создания и флага или ярлыка, удостоверяющих оплачен ли счет или нет.
Сервисная программа (утилита) может только удалять/перемещать файлы, если счет был
оплачен или просрочен.
Данные измерений не могут быть удалены без предварительного разрешения, например,
диалоговое сообщение или «окно» задают вопрос о подтверждении удаления.
43
Дополнения для риска класса Е
Требования к документации (в дополнение к требованиям к документации для риска классов В, С
и D):
Исходный код, реализующий защиту сохраняемых данных.
Руководство по подтверждению (в дополнение к руководству для риска классов В, С и D):
Проверки, основанные на исходном коде:

Проверяется, все ли меры, предпринятые для защиты сохраняемых данных, являются достаточными и точно исполняемыми.
44
Риск класса В
Риск класса С
Риск класса D
L3: Целостность данных
Сохраняемые данные измерений должны быть защищены от умышленных изменений.
Специальные примечания:
Специальные примечания:
1. Данное требование применимо ко всем типам
1. Данное требование применимо ко
носителей, кроме встроенных.
всем типам носителей, кроме
2. Защита должна быть направлена против умышвстроенных.
ленных изменений, выполняемых простыми
2. Защита должна быть направлена
распространенными программными средствами.
против умышленных изменений,
3. Под простыми распространенными программвыполняемых
специальными
ными средствами понимаются такие средства,
(фальсифицирующими)
прокоторые легко доступны и управляемы, наприграммными средствами.
мер, офисные пакеты.
3. «Специальными
(фальсифицирующими) программными средствами» являются, например, отладчики, декомпиляторы, средства для разработки программного обеспечения и т.п.
4. Уровень защиты должен быть эквивалентным уровню защиты,
применяемому при электронных
платежах.
5. Защита реализована посредством
электронной подписи с применением алгоритма, гарантирующего, что отсутствуют идентичные
результаты подписей у различных массивов данных.
Примечание: Даже если алгоритм и ключ
отвечают высокому уровню, техническое
решение для стандартного РС не должно реализовывать защиту такого уровня, потому
что нет соответствующих средств защиты
для программ, участвующих в признании и
проверке массива данных (см. основное Руководство U для универсальных компьютеров, комментарий к требованию U6-D).
Требования к документации (в дополТребования к документации:
Метод реализации защиты должен быть документиро- нение к требованиям к документации для
ван.
риска классов B и С):
Принятые меры защиты должны быть
отображены.
45
Руководство по подтверждению:
Проверки, основанные на документации:
 Если используется контрольная сумма или цифровая подпись, то
Проверяется, что контрольная сумма или
подпись генерируется по всему массиву данных.
Проверяется, что юридически значимое
программное обеспечение, которое читает
данные и вычисляет контрольную сумму или
дешифрует подпись, действительно сравнивает
вычисленное и номинальное значения.
 Проверяется, что секретные данные (например,
ключ исходного значения, если применяется)
закрыты от считывания простыми средствами.
Руководство по подтверждению (в дополнение к руководству для риска классов B и С):
Проверки, основанные на документации:
 Проверяется, действительно ли
предпринятые меры соответствуют современным требованиям к высокому уровню защиты.
Функциональные проверки:

Проверяется, что поддельный массив данных не
принимается программой.
Пример приемлемого решения:
Значение контрольной суммы вычисляется повторно и
сравнивается с сохраняемым номинальным значением
только перед повторным использованием данных. Если
значения совпадают, массив данных принимается и
может быть использован; в противном случае он должен быть удален или помечен как неверный.
Приемлемым решением может быть использование
CRC-16 алгоритма.
Пример приемлемого решения:
Вместо использования алгоритма CRC
вычисляется цифровая подпись. Подходящим алгоритмом подписи может быть
один из алгоритмов хэширования,
например, SHA-1 или RipeMD160 в сочетании с шифровальным алгоритмом, таким как RSA или эллиптические кривые.
Минимальная длина ключа - 768 бит
Примечание: Алгоритм не является секретным, но в отличие (RSA) или 128-160 бит (EC).
от требования L2, начальный вектор CRC или образующий
полином (т.е. делитель) должны быть в наличии. Начальный
вектор и образующий полином известны только программе,
генерирующей и проверяющей контрольные суммы. С ними
необходимо обращаться, как с ключами (см. L5).
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код, реализующий целостность сохраняемых данных.
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
Проверяется, реализованы ли корректно и должным образом меры, гарантирующие целостность.
46
Риск класса B
Риск класса C
Риск класса D
L4: Достоверность сохраняемых данных измерений
Сохраняемые данные измерений должны обладать способностью обратного достоверного прослеживания процедуры измерения, с помощью которой они были получены.
Специальные примечания:
1. Достоверность данных измерений может понадобиться для ссылки на более поздние данные, например, для выставления счетов.
2. Достоверность требует точного указания (связи) на процедуру измерения, с помощью которой данные измерений были получены.
3. Достоверность предполагает идентификацию массива данных.
4. Обеспечение достоверности не является необходимым требованием при шифровании данных.
Требования к документации:
Требования к документации
Описание метода, используемого для обеспечения достоверно- (в дополнение к требованиям к
сти.
документации для риска классов B и С):
Предпринятые меры защиты
должны быть отображены.
Руководство по подтверждению:
Руководство по подтверждеПроверки, основанные на документации:
нию (в дополнение к руковод Проверяется, чтобы связь между каждым измеренным ству для риска классов B и С):
значением и соответствующим ему процессом измерения Проверки, основанные на документации:
была корректна.
 Проверяется, действи Если используется контрольная сумма или подпись, протельно ли предприняверяется, чтобы контрольная сумма или подпись генеритые меры соответствуровались по всему массиву данных.
ют современным тре Проверяется, что секретные данные (например, ключ исбованиям к высокому
ходного значения, если применяется) закрыты от считыуровню защиты.
вания простыми средствами.
Функциональные проверки:
 Проверяется, идентичны ли соответствующие сохраняемые данные и данные, печатаемые на паспорте или счете.
Пример приемлемого решения:
Сохраняемый массив данных содержит следующие поля данных (в дополнении к полям, определенным в L3):
 Текущий идентификационный номер. Идентификационный номер также копируется на
накладную.
 Время, когда измерение было выполнено (отметка времени). Отметка времени также копируется в накладную.
 Идентификацию средства измерений, с помощью которого были получены данные.
 Подпись, которая используется для подтверждения целостности данных и одновременно
может быть использована для подтверждения достоверности данных. Подпись охватывает
все поля массива данных. См. также требования L2, L3.
 В свидетельстве может быть указано, что значения измерений могут быть сопоставлены с
опорными (эталонными) данными, средства сохранения которых являются предметом законодательного (метрологического) контроля. Достоверность свидетельства может быть
продемонстрирована сравнением напечатанного идентификационного номера или даты
создания с теми, которые имеются у сохраняемых данных.
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код, который генерирует массивы данных для последующего сохранения и реализует
их достоверность.
47
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
 Проверяется, корректно ли строятся массивы данных и надежно ли проводится их аутентификация.
48
Риск класса B
Риск класса C
Риск класса D
L5: Конфиденциальность ключей
Ключи и сопроводительная информация должны обрабатываться, как юридически значимые
данные, и должны быть засекречены и защищены от раскрытия (компрометации) программными средствами.
Специальные примечания:
Специальные примечания:
1. Это требование применяется, только если
1. Это требование применяется к
используется секретный ключ.
накопителям на универсальных
2. Это требование применяется к накопителю
компьютерах и к внешним накопиданных измерений, который является внештелям.
ним по отношению к средству измерений
2. Защита должна применяться против
или реализован на универсальном компьюумышленных изменений, выполтере.
ненных специальными (фальсифи3. Защита должна применяться против умышцирующими) программными средленных изменений, выполненных распроствами.
страненными простыми программными
3. Должны применяться методы, эксредствами.
вивалентные электронным плате4. Если доступ к секретным ключам закрыт,
жам. Пользователь должен иметь
например, пломбированием места подклювозможность проверить подлинчения устройства, то вспомогательных проность открытого ключа.
граммных защитных мер не требуется.
Требования к документации:
Описание процедуры управления ключами и мер
для содержания ключей и связанной с этим секретной информации.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, что секретная информация не
может быть раскрыта.
Пример приемлемого решения:
Секретный ключ и сопутствующие данные хранятся
в бинарном формате в исполнительном коде юридически значимого программного обеспечения. Это
делается в том случае, когда не очевидно, по какому
адресу данная информация располагается. Система
программного обеспечения не предоставляет какихлибо возможностей увидеть или редактировать эти
данные. Если алгоритм CRC применяется как подпись, начальный вектор или образующий полином
играют роль ключа.
Требования к документации (в дополнение к требованиям к документации для
риска классов B и С):
Принятые меры защиты должны быть показаны.
Руководство по подтверждению (в дополнение к руководству для риска классов
B и С):
Проверки, основанные на документации:
 Проверяется, действительно ли
предпринятые меры соответствуют
современным требованиям к высокому уровню защиты.
Пример приемлемого решения:
Секретный ключ хранится в той части аппаратного обеспечения, которая может
быть опечатана. Программное обеспечение
не предоставляет каких-либо возможностей
увидеть или редактировать эти данные.
Примечание: Техническое решение со стандартным персональным компьютером не будет
достаточным для того, чтобы гарантировать
высокий уровень защиты, если отсутствуют
аппаратные средства защиты для ключа и других секретных данных (см. основное Руководство для универсального компьютера U6).
1) Инфраструктура открытого ключа (кода): Открытый ключ (код)
накопителя – предмет законодательного (метрологического) контроля, проводимого аккредитованным Центром доверия (Trust Centre).
2) Доверие напрямую: нет необходимости привлекать Центр доверия,
49
если по предварительному соглашению обе стороны способны считывать открытый ключ средства
измерений напрямую с прибора, являющегося предметом законодательного (метрологического) контроля и отображающего юридически значимый массив данных.
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код, реализующий процедуру управления ключами.
Руководство по утверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
Проверяется, соответствуют ли принятые меры процедуре управления ключами.
50
Риск класса B
Риск класса C
Риск класса D
L6: Восстановление сохраняемых данных
Программное обеспечение, используемое для контроля сохраняемых массивов данных измерений,
должно отображать или печатать данные, проверять данные на изменения и предупреждать,
если изменение происходит. Данные, которые были определены как поврежденные, не должны
использоваться.
Специальные примечания:
1. Для сохраняемых данных измерений может понадобиться ссылка на более поздние данные, например, на запрашиваемые протоколы (дела). Если есть сомнение в корректности
предоставляемых накладной или паспорте, то должна иметься возможность недвусмысленной идентификации сохраняемых данных измерений при сомнительном измерении (см.
также L1, L3, L4 и L5).
2. Для пользователя идентификационный номер (см. L1) должен быть распечатан на накладную/паспорт с пояснением и ссылкой на накопитель, подпадающий под действие законодательного (метрологического) контроля.
3. Средства проверки для контроля целостности, достоверности и корректности представляемых данных измерений сохраняются.
4. Подтверждающее (верифицирующее) программное обеспечение, используемое для вывода
на дисплей или на принтер сохраняемых данных, должно подпадать под действие законодательного (метрологического) контроля.
5. Требования к специальному измерительному оборудованию, см. Приложение I.
Требования к документации:
Требования к документации
(в дополнение к требованиям к
 Описание функций восстанавливающей программы.
документации для риска клас Описание обнаружения повреждения данных.
сов B и С):
 Руководство по эксплуатации для этой программы.
Принятые меры защиты должны быть показаны.
Руководство по подтверждению:
Руководство по подтверждеПроверки, основанные на документации:
нию (в дополнение к руковод Проверяется, что восстанавливающее программное обес- ству для риска классов B и С):
печение действительно сравнивает вычисляемые и номи- Проверки, основанные на документации:
нальные значения.
 Проверяется, действи Проверяется, что восстанавливающее программное обестельно ли предприняпечение является частью юридически значимого протые меры соответствуграммного обеспечения.
ют современным треФункциональные проверки:
бованиям к высокому
 Проверяется, выявляет ли программа поврежденные масуровню защиты.
сивы данных.
 Выполняется выборочная проверка контроля того, что
восстановление воспроизводит всю необходимую информацию.
Пример приемлемого решения:
Массив данных считывается из накопителя подтверждающей (верифицирующей) программой, и
по всему диапазону данных вновь вычисляется цифровая подпись, которая сравнивается с сохраняемым номинальным значением. Если оба значения совпадают, данные признаются корректными, в противном случае данные не используются и удаляются или помечаются программой как
неверные.
Дополнения к риску класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код восстанавливающей программы
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
 Проверяется, соответствуют ли и корректно ли выполнены принятые меры для восстанов-
51
ления, контроля цифровых подписей и т.п.
Риск класса B
Риск класса C
Риск класса D
L7: Автоматическое сохранение
Когда измерение закончено, данные измерений должны сохраняться автоматически.
Специальные примечания:
1. Это требование относится ко всем типам сохранения.
2. Это требование означает, что функция сохранения не должна зависеть от решения оператора.
Однако в некоторых типах средств измерений, например во взвешивающих приборах, требуется
решение или команда от оператора - принять результат или нет. Другими словами, могут быть
некоторые промежуточные измерения, которые не сохраняются (например, во время загрузки или
перед тем, как продукт окажется на приемнике загрузки). Однако, даже в этом случае, результат
будет сохранен автоматически, после того, как оператор примет результат.
3. Для случая полного сохранения следует обратиться к требованию L8.
Требования к документации:
Подтверждение, что хранение автоматически выполнено. Описание Графического Интерфейса
Пользователя.
Руководство по подтверждению:
Функциональные проверки:
 Выборочными проверками удостоверяется, что значения измерения сохраняются
автоматически после измерения или по окончанию процедуры измерения. Проверяется,
что нет никаких кнопок или пунктов меню для прерывания или отмены автоматического
сохранения.
Пример приемлемого решения:
Нет никакого пункта меню или кнопки в Графическом Интерфейсе Пользователя (GUI), который
поддерживает ручное сохранение результатов измерения. Значения измерений представлены в
массиве данных наряду с дополнительной информацией, такой как отметка времени (timestamp) и
подпись, и сохраняются сразу же после измерения или принятия измерения, соответственно.
Дополнения к риску класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код прибора.
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
 Проверяется, соответствуют ли и корректно ли выполнены принятые меры для осуществления автоматического сохранения.
52
Риск класса B
Риск класса C
Риск класса D
L8: Емкость запоминающего устройства и непрерывность
Устройство сохранения должно быть достаточно вместительным для намеченной задачи.
Специальные примечания:
1. Когда устройство сохранения полностью заполнено или вынуто/отключено из/от средства
измерения, оператору должно быть сделано предупреждение. Для дальнейших действий
необходимо обратиться к специальным требованиям для средств измерений (Приложение I).
2. Регулирование, относящееся к минимальному периоду сохранения данных измерений, лежит
вне сферы этого требования и закрепляется национальными инструкциями. Обязанность
владельца - иметь устройство с достаточной емкостью сохранения, чтобы выполнить требования,
предъявляемые к его деятельности. Только лицо, уполномоченное ЕС, может проверить, что
данные сохраняются и восстанавливаются правильно и что новая активность запрещена, когда
устройство сохранения заполнено полностью.
3. Также вне сферы этого требования находится требование наличия определенных надписей на
устройстве сохранения, относящихся к его ёмкости либо к другой сопровождающей информации,
которая позволяет вычислить ёмкость. Однако изготовитель должен сделать доступной
информацию, относящуюся к ёмкости.
Требования к документации:
Описание управления исключительными случаями при сохранении значений измерения.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, что ёмкость хранилища или формулы для её вычисления изготовителем
предоставлены.
 Проверяется, что перезапись данных не может произойти до окончания периода
сохранения данных, который предложен и документирован изготовителем.
Функциональные проверки:
 Проверяется, что пользователю делается предупреждение об удалении файлов данных
измерений (если удаление в принципе возможно).
 Проверяется, что делается предупреждение, когда устройство сохранения заполнено или
отключено.
Пример приемлемого решения:
 Для дискретных измерений, которые могут быть остановлены легко и быстро, например,
при взвешивании, измерении топлива и т.д., измерения могут выполняться, даже если
сохранение становится невозможным. Средство измерений или прибор должны иметь
достаточно большой буфер для сохранения текущих данных. После этого никакая новая
активность не может быть начата, и значения из буфера сохраняются для последующей
передачи в новое устройство сохранения.
 Измерения, которые не являются дискретными, например, измерения энергии, объема и
т.д., не нуждаются в специальном промежуточном буфере, потому что эти измерения
всегда являются накопительными. Накопительное измерение может считываться и
передаваться в устройство сохранения позже, когда оно снова становится доступным.
 Данные измерения могут быть автоматически переписаны утилитой, которая проверяет,
устарели ли они (со ссылкой на национальные инструкции для соответствующего периода
времени), или что счет был оплачен. Утилита должна запрашивать у пользователя
разрешение на удаление, и данные должны быть удалены в порядке, когда в первую
очередь удаляются более старые.
Дополнения к риску класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B,
C и D):
Исходный код, реализующий сохранение данных.
Руководство по подтверждению (в дополнение к руководству для риска классов B, C и D):
Проверки, основанные на исходном коде:
Проверяется, соответствуют ли и корректно ли выполнены принятые меры для осуществления со-
53
хранения.
7 Приложение T: Передача данных измерений через телекоммуникационные сети
Это Приложение относится к требованиям к программному обеспечению, основанным на
Руководствах P и U. Оно должно использоваться только в том случае, если данные
измерений передаются через сети связи к удаленному устройству, где далее они
обрабатываются и/или используются в юридически значимых целях. Это Приложение не
применяется, если нет никакой последующей юридически значимой обработки данных.
Если программное обеспечение загружено на устройство, подлежащее законодательному
(метрологическому) контролю, то применяются требования из Приложения D.
7.1 Техническое описание
Набор требований этого Приложения применяется только в том случае, если
рассматриваемое устройство связано с сетью и передает или получает данные измерений,
которые являются юридически значимыми. В следующей таблице описаны три
конфигурации сети. Самая простая - массив устройств, которые все подлежат
законодательному (метрологическому) контролю. Участники сети (составные части)
устанавливаются законодательным подтверждением. Как вариант (закрытая сеть,
частично под законодательным (метрологическим) контролем) – это сеть с участниками
(составными частями), которые не подлежат контролю, но они все известны и не
меняются во время функционирования. У открытой сети нет никакого ограничения в
идентификации, функциональных возможностях, присутствии и местоположении
участников (составных частей).
Таблица 7.1: Техническое описание средства измерений типа U
Описание конфигураций
Закрытая сеть, полностью под законодательным (метрологическим) контролем
Сеть связывает только фиксированное число участников (составных частей)
с
известными идентификацией, функциональными возможностями и местоположением. Все
устройства подлежат законодательному (метрологическому) контролю. В сети не
существуют никаких устройств, не подлежащих законодательному (метрологическому)
контролю.
Закрытая сеть, частично под законодательным (метрологическим) контролем
Сеть связывает фиксированное число участников (составных частей) с известными
идентификацией и местоположением. Не все устройства подлежат законодательному
(метрологическому) контролю, и, следовательно, их функциональные возможности
неизвестны.
Открытая сеть
Произвольные участники (устройства с произвольными функциями) могут быть связаны с
сетью. Идентификация и функциональные возможности задействованного устройства и
его местоположение могут быть неизвестными другим участникам. Любая сеть,
содержащая законодательно (метрологически) контролируемые устройства с
инфракрасной связью (IR) или интерфейсами беспроводной связи, должна
рассматриваться как открытая сеть.
.
54
7.2 Специальные требования к программному обеспечению для передачи данных
Риск класса B
Риск класса C
Риск класса D
T1: Полнота переданных данных
Переданные данные должны содержать всю значимую информацию, необходимую для ее
представления или для дальнейшей обработки результата измерения в принимающем
устройстве.
Специальные примечания:
1. Метрологическая часть переданных данных включает одно или несколько значений измерения с
заданной погрешностью, законодательно принятую единицу измерения и в зависимости от задачи
цену деления или шкалу и место проведения измерения.
Требования к документации:
Документирование всех областей массива данных.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, вся ли информация, используемая для дальнейшей обработки измеренных
значений в получающем устройстве, содержится в массиве данных.
Пример приемлемого решения:
Массив данных содержит следующую информацию:
 значение(я) измерений с заданной погрешностью
 узаконенная единица измерения
 цена деления или шкала (если содержится)
 время и дата измерения (если содержится)
 идентификация прибора, если содержится (передача данных)
 место измерения (если содержится)
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B,
C и D):
Исходный код, генерирующий массивы данных для последующей передачи.
Руководство по утверждению (в дополнение к руководству для риска классов B, C и D):
Проверки, основанные на исходном коде:
 Проверяется, корректно ли построены массивы данных.
55
Риск класса B
Риск класса C
Риск класса D
T2: Защита против случайных или неумышленных изменений
Переданные данные должны быть защищены против случайных и неумышленных изменений.
Специальные примечания:
1. Случайные изменения данных могут быть вызваны физическими эффектами.
2. Неумышленные изменения вызываются пользователем устройства.
3. Должны быть предоставлены средства для обнаружения ошибок передачи.
Требования к документации (в
Требования к документации:
Описание алгоритма контрольной суммы, если она дополнение к требованиям к
используется, включая длину образующего полинома.
документации для риска классов
Описание альтернативного метода, если он используется.
B и C).
Документация
должна
отображать меры, принятые для
проверки эффективности мер
защиты.
Руководство по подтверждению:
Руководство по подтверждеПроверки, основанные на документации:
нию (в дополнение к рекомен Проверяется, что контрольная сумма генерируется по дации для риска классов B и С):
Проверки, основанные на докувсем данным.
 Проверяется, что юридически значимое программное ментации:
 Проверяется,
действиобеспечение, которое получает данные, пересчитывает
тельно
ли
предпринятые
контрольную сумму и сравнивает ее с номинальным
меры соответствуют трезначением, содержащимся в массиве данных.
бованиям к высокому
уровню защиты.
Пример приемлемого решения:
1) Чтобы обнаружить изменения данных, контрольная сумма с алгоритмом CRC-16
вычисляется по всем байтам данных и вставляется в массив данных для последующей
передачи. Непосредственно перед повторным использованием данных, значение
контрольной суммы пересчитывается приемником и сравнивается с прилагаемым
номинальным значением. Если значения совпадают, массив данных принимается и может
использоваться, в противном случае он должен быть удалён или помечен как неисправный.
Примечание: Алгоритм не является секретным и, в противоположность требованию Т3, не
является ни начальным вектором СRC-16, ни его образующим полиномом, т.е. делителем.
Начальный вектор и образующий полином известны как создающей их программе, так и
программе, проверяющей контрольную сумму.
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B,
C и D):
Исходный код, который реализует защиту передаваемых данных.
Руководство по подтверждению (в дополнение к руководству для риска классов B, C и D):
Проверки, основанные на исходном коде:
 Проверяется, являются ли достаточными меры защиты передаваемых данных.
56
Риск класса B
Риск класса C
Риск класса D
T3: Целостность данных
Юридически значимые передаваемые данные должны быть защищены от намеренных изменений
с применением программных средств.
Специальные примечания:
Специальные примечания:
1. Это требование применяется только для открытых сетей
1. Это требование применяили для сетей, частично подпадающих под действие зается только для открытых
конодательного (метрологического) контроля, но не для
сетей и закрытых сетей,
закрытых сетей.
частично подпадающих
2. Защита должна применяться от намеренных изменений,
под действие законодавыполненных с применением общеизвестных простых
тельного (метрологичепрограммных средств.
ского) контроля.
3. Под общеизвестными простыми программными сред2. Защита реализована на
ствами понимаются средства, которые легко доступны и
основе электронной подуправляемы, например, офисные пакеты.
писи с применением алгоритма, гарантирующего, что не существует
идентичной подписи для
различных массивов данных.
3. Защита должна применяться против умышленных изменений, выполненных
специальными
фальсифицирующими
программными средствами.
4. «Фальсифицирующими
программными средствами» являются, например,
отладчики, декомпилеры,
средства для разработки
программных продуктов
и т.д.
5. Уровень защиты должен
быть
эквивалентным
уровню защиты, применяемому для электронных
платежей.
Примечание: Даже если бы алгоритм и ключ удовлетворяли высокому уровню, техническое решение со стандартным персональным компьютером не сможет реализовать этот уровень защиты,
поскольку отсутствует подходящие защитные средства для программ, что подписывают или проверяют массивы данных (см. основное Руководство U для универсальных компьютеров, разъяснение по требованию U6-D).
Требование к документации:
Описание метода защиты
Требования к документации
(в дополнение к требованиям к
документации для риска клас-
57
сов B и С):
Принятые меры защиты должны быть отображены.
Руководство по подтверждению (в дополнение к руководству для риска классов B и С):
Проверки, основанные на документации:
 Проверяется, действительно ли предпринятые меры соответствуют современным требованиям к высокому
уровню защиты.
Руководство по подтверждению:
Проверки, основанные на документации:
 Если используется контрольная сумма или цифровая
подпись:
Проверяется, что контрольная сумма или цифровая подпись генерируется по всему массиву данных.
Проверяется, что юридически значимое программное обеспечение, которое получает данные, пересчитывает контрольную
сумму или дешифрует электронную подпись и сравнивает ее с
номинальным значением, содержащимся в массиве данных.
 Проверяется, что засекреченные данные (например, ключ
исходного значения, если он применяется) закрыты от
прочтения простыми средствами.
Пример приемлемого решения:
Пример приемлемого реше Передается сгенерированная контрольная сумма массива ния:
Вместо алгоритма CRC
данных. Значение контрольной суммы пересчитывается
вычисляется электронная
только перед повторным использованием данных и сравподпись. Подходящим алнивается с номинальным значением, которое содержится
горитмом подписи может
в получаемом массиве данных. Если значения совпадабыть один из алгоритмов
ют, массив данных считается правильным и может быть
хэширования,
например,
использован, в противном случае он должен быть удален
SHA-1 или RipeMD160 в
или помечен как неверный.
сочетании с шифрующим
 Как допустимое решение можно принять алгоритм CRCалгоритмом, таким как
16.
RSA или Эллиптические
Примечание: Алгоритм является не секретным, но в противопоКривые.
Минимальная
ложность требованию T2, начальный вектор CRC-16 или обрадлина ключа 768 бит (RSA)
зующий полином (т. е. делитель в алгоритме) являются секретили 128-160 бит (EC).
ными. Начальный вектор и образующий полином известны
Защита обеспечивается нетолько программам, генерирующим и проверяющим контролькоторыми протоколами пеные суммы.
редачи данных, например
Они должны рассматриваться как ключи (см. T5).
HTTPS.
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код, который реализует целостность передаваемых данных.
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
Проверяется, адекватны ли принятые меры для гарантирования целостности передаваемых данных.
58
Риск класса B
Риск класса C
Риск класса D
T4: Подлинность переданных данных
Для программы, принимающей передаваемые значимые данные, должна быть возможность
подтверждения подлинности и принадлежности
измеренных значений к определенному
измерению.
Специальные примечания:
1a. В сети с неизвестными участниками необходимо идентифицировать происхождение
переданных однозначно данных измерений. (Проверка подлинности основывается на
идентификационном номере массива данных и сетевом адресе).
1b. В закрытой сети все участники известны. Нет необходимости в дополнительных IT условиях,
но топология сети (число участников) должна быть зафиксирована опечатыванием.
2. Во время передачи возможны непредвиденные задержки. Для определения правильной
принадлежности полученных значений измерений к определенному измерению должно быть
зарегистрировано время измерения.
3. Шифрование данных измерений для гарантии их подлинности не требуется.
Требования к документации:
Требования к документации
Сеть с неизвестными участниками: Описание IT – средств для (в дополнение к требованиям к
точного определения предназначения измеренного значения.
документации для риска класЗакрытая сеть: Описание аппаратных средств, сохраняющих сов B и С):
номер участников сети. Описание процедуры начальной иден- Принятые меры защиты должтификации участников.
ны быть показаны.
Руководство по подтверждению:
Руководство по подтверждеПроверки, основанные на документации:
нию (в дополнение к руковод Проверяется, что существует корректная связь между ству для риска классов B и С):
каждым измеренным значением и соответствующим из- Проверки, основанные на документации:
мерением.
 Проверяется, действи Проверяется, что данные защищены цифровой подписью
тельно ли предпринядля гарантии их надлежащей идентификации и подлинтые меры соответствуности.
ют современным требованиям к высокому
уровню защиты.
Пример приемлемого решения:
 Каждый массив данных имеет единственный (текущий) идентификационный номер,
который может содержать информацию о времени, когда измерение было выполнено
(отметка времени).
 Каждый массив данных содержит информацию о происхождении данных измерения, т.е.
регистрационный номер или идентификацию средства измерения, который произвел
измерение.
 В сети с неизвестными участниками подлинность гарантируется, если массив данных
имеет однозначную подпись. Цифровая подпись перекрывает все области массива данных.
 Приёмник массива данных проверяет все данные на подлинность.
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код принимающего и отправляющего устройств.
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
Проверяется, адекватны ли принятые меры для гарантии подлинности передаваемых данных.
59
Риск класса B
Риск класса C
Риск класса D
T5: Конфиденциальность ключей
Ключи и сопровождающие их данные должны рассматриваться, как юридически значимые,
должны держаться в секрете и быть защищены от раскрытия посредством программных
средств.
Специальные примечания:
Специальные примечания:
1. Это требование применяется, если в системе су1. Это требование применяется,
ществует секретный ключ. (Обычно не в закрыесли в системе существует
тых сетях).
секретный ключ (обычно не в
2. Защита должна применяться против преднамезакрытых сетях)
ренных изменений, выполняемых с применением
2. Защита должна применяться
простых общераспространенных программных
против умышленных изменесредств.
ний, выполняемых специаль3. Если доступ к секретным ключам защищен,
ными
фальсифицирующими
например, пломбированием места монтажа средпрограммными средствами.
ства измерений со встроенным программным
3. Принимаемые значения измеобеспечением, тогда дополнительных мер прорений считываются из массива
граммной защиты не требуется.
данных и их цифровая подпись
проверяется с помощью открытого ключа посылающего
средства
измерений
(или
устройства, которое генерирует значимые массивы данных).
Этой проверкой приемник может убедиться, что значение и
цифровая подпись соответствуют друг другу.
4. Должны использоваться методы, эквивалентные тем, что
используются при электронных платежах.
Требования к документации (в доТребования к документации:
Описание процедуры управления ключами и мер, пред- полнение к требованиям к документапринимаемых для хранения ключей и сопровождающей ции для риска классов B и С):
секретной информации.
Принятые меры защиты должны быть
показаны.
Руководство по подтверждению (в
Руководство по подтверждению:
Проверки, основанные на документации:
дополнение к руководству для риска
 Проверяется, что секретная информация не может классов B и С):
Проверки, основанные на документабыть раскрыта.
ции:
 Проверяется,
действительно
ли предпринятые меры соответствуют современным требованиям к высокому уровню
защиты.
Пример приемлемого решения решения:
Пример приемлемого решения:
Секретный ключ и сопутствующие данные хранятся в Секретный ключ хранится в той части
бинарном формате в исполнительном коде юридически аппаратного обеспечения, которая
значимого программного обеспечения. Это делается то- может быть опечатана. Программное
гда, когда не известно, по какому адресу данная инфор- обеспечение не позволяет увидеть камация хранится. Программная система не позволяет уви- кие-либо свойства или редактировать
деть какие-либо свойства или редактировать эти данные. эти данные.
Если CRC алгоритм применяется как подпись, начальный Примечание: Техническое решение со
60
вектор или порождающий многочлен играют роль ключа.
стандартным персональным компьютером
не может гарантировать высокий уровень
защиты, поскольку отсутствуют подходящие защитные средства для ключа и других секретных данных (смотри основное
руководство для универсальных компьютеров U6).
1) Инфраструктура открытого
ключа: Открытый ключ накопителя – предмет законодательного (метрологического)
контроля,
подтверждаемый
аккредитованным Центром доверия.
2) Доверие напрямую: нет необходимости привлекать Центр
доверия, если по предшествующему соглашению обе стороны способны считать открытый ключ средства измерений
напрямую с прибора, являющегося предметом законодательного (метрологического)
контроля, и показывающего
юридически значимые массивы данных.
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код, реализующий процедуру управления ключами.
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
 Проверяется, соответствуют ли принятые меры процедуре управления ключами.
61
Риск класса B
Риск класса C
Риск класса D
T6: Оперирование с поврежденными данными
Данные, которые опознаны как искаженные, не должны использоваться.
Специальные примечания:
1. Хотя протоколы связи обычно повторяют передачу, пока она успешно не завершится, однако
возможно, что будет получен искаженный массив данных.
Требования к документации:
Требования к документации
Описание выявления передаваемых ошибок или умышленных (в дополнение к требованиям к
изменений.
документации для риска классов B и С):
Меры, предпринятые для корректного обращения с поврежденными данными, должны
быть показаны.
Руководство по подтверждению:
Руководство по подтверждеПроверки, основанные на документации и функциональных про- нию (в дополнение к руководверках:
ству для риска классов B и С):
 Проверяется, чтобы поврежденные данные согласно Проверки, основанные на документации:
концепции доставки не использовались.
 Проверяется, действительно ли предпринятые меры соответствуют современным требованиям к высокому
уровню защиты.
Пример приемлемого решения:
Когда программа, которая принимает данные, обнаруживает несоответствие между массивом
данных и номинальным значением цифровой подписи, она сначала пытается восстановить
оригинальное значение, если доступна избыточная (добавочная) информация. Если
восстановление невозможно, генерируется предупреждение пользователю, измеренное значение
не выводится и
 Устанавливается значок в специальной области массива данных (область статуса) со
значением «не действительно»
ИЛИ
 Искаженный массив данных удаляется.
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код принимающего устройства.
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
Проверяется, соответствуют ли предпринятые меры оперированию с поврежденными данными.
62
Риск класса B
Риск класса C
Риск класса D
T7: Задержка передачи
Измерение не должно быть подвержено недопустимому влиянию задержки передачи.
Специальные примечания:
Изготовитель должен исследовать время передачи данных и должен гарантировать, что даже в
худшем случае измерения не будут подвержены недопустимому влиянию.
Требования к документации:
Описание решения того, как измерение защищено от задержки передачи.
Руководство по подтверждению:
 Убеждаются, что измерение не находится под влиянием задержки передачи.
Пример приемлемого решения:
Осуществление протоколов передачи для основных областей.
Дополнения к риску класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B,
C и D):
Исходный код, реализующий передачу данных.
Руководство по подтверждению (в дополнение к руководству для риска классов B, C и D):
Проверки, основанные на исходном коде:
Проверяется, подходят ли принятые меры для управления задержкой передачи.
63
Риск класса B
Риск класса C
Риск класса D
T8: Наличие услуг передачи
Если услуги сети становятся недоступными, никакие данные измерений не должны теряться.
Специальные примечания:
1. Пользователь измерительной системы не должен быть способен повредить данные измерений,
запрещая их передачу.
2. Не могут быть исключены случайные возмущения (нарушения) передачи. Устройство передачи
должно быть способно реагировать на такую ситуацию.
3. Если услуги передачи становятся недоступными, то реакция средства измерений, зависит от
принципа измерения (см. часть I).
Требования к документации:
Описание защиты данных измерений от прерывания передачи или других отказов.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, какие меры осуществлены для защиты от потери данных.
 Проверяется, какие меры предприняты на случай отказа передачи.
Функциональные проверки:
 Выборочные проверки должны показать, что никакие значимые данные не теряются из-за
прерывания передачи.
Пример приемлемого решения:
1) Для дискретных измерений, которые могут быть остановлены легко и быстро, например, для
взвешивания, измерения топлива и т.д., измерение может быть закончено даже при прекращении
передачи. Однако при этом средство измерений или устройство, которые передают юридически
значимые данные, должны иметь буфер, являющийся достаточно большим, чтобы сохранять
текущую операцию. После этого никакая новая передача не может быть начата, и буферные
значения сохраняются для последующей передачи. Другие примеры приведены в части I.
2) Измерения, которые не являются дискретными, например, измерения энергии, объема и т.д., не
нуждаются в специальном промежуточном буфере, потому что эти измерения всегда являются
накопительными. Накопительный регистр может считываться и передаваться в более позднее
время, когда связь снова восстановлена.
Дополнения к риску класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B,
C и D):
Исходный код, реализующий передачу данных.
Руководство по подтверждению (в дополнение к руководству для риска классов B, C и D):
Проверки, основанные на исходном коде:
 Проверяется, являются ли достаточными меры, предпринятые для реагирования на
прерывание процедуры передачи.
64
8 Приложение S: Разделение программного обеспечения
Разделение программного обеспечения является необязательным исполнением методологии, которое позволяет легко модифицировать законодательно (метрологически)
не значимое программное обеспечение. Если разделение программного обеспечения
произведено, то это приложение должно рассматриваться как дополнение к основным
требованиям к средствам измерений типа P и U.
8.1 Техническое описание
Программное обеспечение средств измерений или измерительных систем в общем
случае имеет сложную структуру и содержит как законодательно (метрологически)
значимые модули, так и модули, которые таковыми не являются. Хотя это не предписывается, тем не менее, производителям и проверяющим выгодно разделять такие модули измерительной системы.
В следующей таблице описываются два способа разделения программного обеспечения. Оба варианта характеризуются своим набором требований.
Таблица 8.1. Техническое описание средств измерений типа U
Описание
Разделение программного обеспечения реализуется независимо от операционной системы внутри домена приложений, т.е. на уровне языка программирования (Низкий
уровень разделения).
Примечание: Такая особенность реализуется как в специализированных средствах измерений, так и в средствах измерений на базе универсального компьютера.
Разделенные модули программного обеспечения реализуются как независимые объекты в терминах операционной системы (Высокий уровень разделения).
Примечание: Такое разделение возможно только с универсальным компьютером.
Примером решений являются независимо действующие исполнительные программы, динамически связанные библиотеки и т.д.
Блок (алгоритм) защиты от недозволенных изменений значений измерений и параметров должен вызываться только путем косвенной адресации, чтобы программист той
части программного обеспечения, которая не является объектом законодательного
(метрологического) контроля, не предоставил пользователю измерительной системы
возможность для искажений. Но в любом случае это будет учитываться программистом (с или без разделения), и соответствующие требования содержатся в основных
частях P и U (главы 4 и 5) Руководства.
65
8.2 Специальные программные требования для разделения программного обеспечения
Риск класса B
Риск класса C
Риск класса D
S1: Реализация программного разделения
Должна быть часть программного обеспечения, содержащая все юридически значимое
программное обеспечение и параметры, которые четко отделены от других частей
программного обеспечения.
Специальные примечания:
1. В случае низкого уровня разделения все программные единицы (подпрограммы,
процедуры, функции, классы и т.д.) и в случае высокого уровня разделения все программы и библиотеки,
o что принимают участие в расчетах значений измерений или влияют на них,
o что принимают участие во вспомогательных функциях таких, как представление данных,
их защита и сохранение, идентификация программного обеспечения, осуществление его
загрузки, передача данных и сохранение, проверка принятых или сохраненных данных и
т.д.,
относятся к юридически значимому программному обеспечению.
2. Все переменные, временные файлы и параметры, которые влияют на значения измерений или на юридически значимые функции или данные, относятся к юридически значимому программному обеспечению.
3. Компоненты защищенного программного интерфейса (см. S3) являются частью
юридически значимого программного обеспечения.
4. Юридически не значащее программное обеспечение включает в себя оставшиеся
программные единицы, данные или параметры, не указанные выше. Модификация
такой части разрешается без информирования уполномоченного органа при условии, что все другие требования к программному разделению соблюдены.
Требования к документации:
Описание всех компонент, упомянутых выше в специальных
примечаниях, также относится к юридически значимому программному обеспечению.
Требования к документации
(в дополнение к требованиям к
документации для риска классов B и С):
В документации должно быть
корректно показано программное разделение.
Руководство по подтверждению:
Руководство по подтверждеПроверки, основанные на документации:
нию (в дополнение к руковод Проверяется, что юридически значимые компоненты, ству для риска классов B и С):
упомянутые в специальных примечаниях 1 – 3 включены Проверки, основанные на документации:
в юридически значимое программное обеспечение.
 Проверяется, что реализация программного
разделения
является
корректной.
Пример приемлемого решения:
Так, как описано в самих требованиях.
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код юридически значимого программного обеспечения.
66
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
 Проверяется, что исполнение программного обеспечения и потоков данных, относящихся
к юридически значимому программному обеспечению, ясно и недвусмысленно определено
в юридически значимом программном обеспечении и может быть проверено.
 Проверяется (например, с помощью анализа потока данных или вручную), что все программные единицы, программы и библиотеки, которые принимают участие в обработке
значений измерений, действительно отнесены к юридически значимому программному
обеспечению.
 Исследуется, что должна быть защита от недопустимого потока данных от частей, не
относящихся к законодательно (метрологически) контролируемым.
67
Риск класса B
Риск класса C
Риск класса D
S2: Смешанная индикация
Дополнительная информация, сгенерированная юридически не значимым программным
обеспечением, может быть показана на дисплее или распечатана только тогда, когда она не
может быть спутана с информацией, исходящей от юридически значимой части.
Специальные примечания:
Так как программист юридически не значимого программного обеспечения может не знать о
допустимости индикации, на производителе лежит ответственность за гарантию того, что вся
показываемая информация удовлетворяет необходимым требованиям.
Требования к документации:
Требования к документации
Описание программного обеспечения, реализующего индика- (в дополнение к требованиям к
цию.
документации для риска класОписание того, каким образом обеспечивается индикация юри- сов B и С):
дически значимого программного обеспечения.
В документации должна быть
отражена реализация смешанной индикации.
Руководство по подтверждению:
Руководство по подтверждеФункциональные проверки:
нию (в дополнение к руководству для риска классов B и С):
 Посредством визуальной проверки делается заключение
о том, что дополнительная информация, сгенерированная Проверки, основанные на доюридически не значимым программным обеспечением и кументации:
показанная на дисплее или распечатанная, не может быть
 Проверяется, что реаспутана с информацией, исходящей от юридически знализованное исполнение
чимой части.
смешанной индикации
является корректным.
Пример приемлемого решения:
 Информация, отображаемая юридически не значимым программным обеспечением,
передается через защищенный интерфейс (см. S3) юридически значимой части.
За
интерфейсом она проходит сквозь фильтр, который отсекает недозволенную информацию.
Допустимая информация затем включается в индикацию, контролируемую юридически
значимым программным обеспечением.
 На дисплее с окнами (универсальный компьютер) проверки юридически значимого
программного обеспечения за кратковременные интервалы или окно с юридически
значимой информацией всегда видны в верхней части совокупности окон. Если это
скрыто, минимизировано или находится за границами видимой области, программное
обеспечение генерирует предупреждение или останавливает вывод и обработку значений
измерений. Когда измерения заканчиваются, окно для проверки юридически значимого
программного обеспечения может быть закрыто.
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код юридически значимого программного обеспечения.
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
 Проверяется, что юридически значимое программное обеспечение генерирует индикацию
значений измерений.
 Проверяется, что индикация не может изменяться или подавляться юридически не
значимыми программами.
68
Риск класса B
Риск класса C
Риск класса D
S3: Защищенный интерфейс программного обеспечения
Обмен данными между юридически значимыми и не значимыми частями программного
обеспечения должен происходить через защищенный интерфейс программного обеспечения,
который охватывает взаимодействия между частями программного обеспечения и поток
данных.
Специальные примечания:
1. Все взаимодействия и потоки данных не должны оказывать недопустимое влияние на
юридически значимое программное обеспечение, включая динамический характер
измерительного процесса.
2. Должно быть однозначное назначение каждого набора команд, переданных через
интерфейс программного обеспечения, для инициации функций или изменения данных в
юридически значимом программном обеспечении.
3. Коды и данные, которые не декларированы и не документированы как команды, не
должны оказывать никакого эффекта на юридически значимое программное обеспечение.
4. Интерфейс должен быть полностью документирован, и никакое другое не
документированное воздействие или поток данных не должны реализоваться как
программистом юридически значимого программного обеспечения, так и программистами
юридически не значимого программного обеспечения.
Примечание: Программисты ответственны за соблюдение этих ограничений. Технические средства для
предотвращения от нарушения юридически значимого программного обеспечения с их стороны
отсутствуют. Программист защищенного интерфейса должен быть проинструктирован об этом
требовании.
Требования к документации:
Требования к документации
 Описание интерфейса программного обеспечения, осо- (в дополнение к требованиям к
бенно той части, которая реализует взаимодействие с документации для риска классов B и С):
доменами данных.
 Полный список всех команд совместно с декларацией об В документации должна быть
показана реализация защищених полноте.
 Краткое описание их назначения и их воздействия на ного интерфейса программного
обеспечения.
функции средства измерений и данные.
Руководство по подтверждению:
Руководство по подтверждеПроверки, основанные на документации:
нию (в дополнение к руковод Проверяются, что функции юридически значимого про- ству для риска классов B и С):
граммного обеспечения, которые могут быть запущены Проверки, основанные на дочерез защищенный интерфейс программного обеспече- кументации:
 Проверяется, что реания, являются определенными и описанными.
лизация программного
 Проверяется, что параметры, которые изменены через
интерфейса
является
интерфейс, являются определенными и описанными.
корректной.
 Проверяется, что описание функций и параметров является окончательным и полным.
Пример приемлемого решения:
 Домены данных юридически значимой части программного обеспечения инкапсулированы
(скрыты) и доступ к ним осуществляется только с помощью локальных переменных в
юридически значимой части.
 Интерфейс реализован как подпрограмма, относящаяся к юридически значимому
программному обеспечению, которая вызывается из юридически не значимого
программного обеспечения. Данные, передаваемые в юридически значимое программное
обеспечение, проходят как параметры подпрограммы.
 Юридически значимое программное обеспечение отсекает недозволенные команды
интерфейса.
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
69
Исходный код юридически значимого программного обеспечения.
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
 Проверяется, что как программное исполнение, так и поток данных однозначно
определены в юридически значимом программном обеспечении и могут быть проверены.
 Проверяется, что поток данных через программный интерфейс вводится либо
программными средствами, либо вручную. Проверяется, документирован ли поток данных
между частями программного обеспечения (нет обхода декларированного программного
интерфейса).
 Исследуется, имеется ли предохранение от недопустимого потока данных от части, не
являющейся предметом контроля.
 Проверяется, что команды, если они есть, дешифруются корректно и что не существует не
документированных команд.
70
9 Приложение D: Загрузка юридически значимого программного обеспечения
Это приложение должно использоваться для загрузки юридически значимого программного обеспечения, например, такого как обнаружение грубых ошибок, обновление, новые
приложения и т.п. в средствах измерений обоих типов U и P. Эти требования должны рассматриваться как дополнение к основным требованиям для средств измерений типов U и
P, описанных в главах 4 и 5 Руководства.
9.1 Техническое описание.
Программное обеспечение может быть загружено только в средства измерений, которые
характеризуются свойствами, представленными в таблице 9.1.
Таблица 9.1. Техническое описание средства измерений типа U
Аппаратная конфигурация
Целевой прибор должен быть объектом законодательного (метрологического) контроля.
Он может быть разработанным для конкретной цели (тип P) или на основе универсального
компьютера (тип U). Линии связи для загрузки могут быть прямыми, например, RS 232,
USB, через закрытую сеть, частично или полностью законодательно контролируемую,
например, через кабельную сеть, локальную сеть token – ring, или через открытую сеть,
например, Интернет.
Программная конфигурация
Программное обеспечение целевого прибора может быть полностью законодательно (метрологически) контролируемым или может иметь программное разделение. Загрузка юридически значимого программного обеспечения должна удовлетворять требованиям, изложенным ниже. Если программное разделение отсутствует в средстве измерений, то все
требования, изложенные ниже, применимы ко всей загрузке.
71
9.2 Специальные программные требования
Риск класса B
Риск класса C
Риск класса D
D1: Механизм загрузки
Загрузка и последующая инсталляция программного обеспечения должны быть автоматическими
и должны гарантировать, что защитная оболочка программного обеспечения находится на
утвержденном уровне полноты.
Специальные примечания:
1. Загрузка должна быть автоматической и гарантировать, что существующий уровень
защиты не нарушен.
2. Целевой прибор должен иметь фиксированное юридически значимое программное
обеспечение, которое содержит все проверочные функции, необходимые для
удовлетворения требованиям от D2 до D5.
3. Средство измерений должно быть способным определять, что загрузка или инсталляция
являются ошибочными. Должно даваться предупреждение. Если загрузка или инсталляция
неуспешны или прерваны, первоначальное состояние средства измерений должно остаться
неизменным. Как альтернатива этому, средство измерений должно показывать постоянное
сообщение об ошибке, и его метрологическая функциональность должна быть
приостановлена до тех пор, пока причина ошибки не будет устранена.
4. По завершении успешной инсталляции все средства защиты должны быть приведены в их
первоначальное состояние, если загруженное программное обеспечение не имеет
разрешение уполномоченного органа для внесения изменений в сертификат об
утверждении типа с целью его улучшения.
5. В течение загрузки и последующей инсталляции программного обеспечения измерения с
помощью средства измерений должны быть приостановлены или должна быть
гарантирована корректность измерений.
6. Требования к обработке сбоев, описанные в приложении I, могут быть исполнены, если
нарушения происходят во время загрузки. Число попыток повторения инсталляции должно
быть ограничено.
7. Если требования D2 – D5 не могут быть удовлетворены, тем не менее, загрузка
юридически не значимой части все еще возможна. В этом случае должны удовлетворяться
следующие требования:
 Имеется четкое разделение между юридически значимым и не значимым
программным обеспечением в соответствии с приложением S.
 Полнота юридически значимого
программного обеспечения должна быть
зафиксирована, т.е. оно не может быть загружено или изменено без нарушения
пломбы.
 В сертификате об утверждении типа отмечается, что загрузка юридически не
значимого программного обеспечения является приемлемой.
Требования к документации:
Требования к документации
Документация должна кратко описывать автоматическую при- (в дополнение к требованиям к
роду загрузки, проверки, как гарантируется уровень защиты, что документации для риска класслучится, если происходит сбой.
сов B и С):
В документации должна быть
отражена реализация механизма загрузки.
Руководство по подтверждению:
Руководство по подтверждеПроверки, основанные на документации:
нию (в дополнение к руководству для риска классов B и С):
 Проверяется, как управляется процедура загрузки.
 Проверяется, что загрузка и инсталляция происходят ав- Проверки, основанные на дотоматически, что средство измерений запирается (если кументации:
 Проверяется, что реапредусмотрено) и что защита программного обеспечелизация механизма зания не нарушается в результате загрузки.
грузки является кор Проверяется, что имеется не загружаемое юридически
ректным.
значимое программное обеспечение для проверки аутентичности и полноты.
 Проверяется, что во время загрузки никакое измерение
72
невозможно, или гарантируется корректность измерений.
Функциональные проверки:
 Проводится, наконец, одна программная загрузка для
проверки загрузки программного обеспечения.
Пример приемлемого решения:
Вспомогательная программа, находящаяся в установленной части программного обеспечения:
a. Обеспечивает контроль установления согласования отправителя с проверяющим
органом;
b. Автоматически препятствует измерениям до тех пор, пока могут быть
гарантированы корректные измерения;
c. Автоматически загружает юридически значимое программное обеспечение в
защищенную область;
d. Автоматически осуществляет проверки, требуемые D2 – D4;
e. Автоматически инсталлирует программное обеспечение в надлежащее место;
f. Заботится о «хозяйстве», например, уничтожает излишние файлы и т.п.;
g. Гарантирует, что любое снижение защиты, проведенное для облегчения загрузки и
инсталляции, после их завершения автоматически восстанавливается до
утвержденного (исходного) уровня;
h. Инициирует соответствующие процедуры управления сбоем, если нарушение
имеет место.
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код установленной части программного обеспечения, ответственного за управление
процессом загрузки.
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
 Проверяется, что меры, предпринятые для управления процессом загрузки, являются
подходящими.
73
Риск класса B
Риск класса C
Риск класса D
D2: Подлинность загружаемого программного обеспечения
Должны быть предусмотрены средства, гарантирующие, что загружаемое программное
обеспечение является подлинным, и показывающие, что загружаемое программное обеспечение
утверждено уполномоченным органом.
Специальные примечания:
1. До загрузки программного обеспечения, используемого впервые, средство измерений
должно автоматически проверить, что:
a. Программное обеспечение является подлинным (не является мошеннически
смоделированным).
b. Программное обеспечение является утвержденным для типа средств измерений.
2. Средства, с помощью которых идентифицируется статус утверждения программного
обеспечения уполномоченным органом, должны быть защищены для предотвращения
подделки этого статуса.
3. Если загрузка программного обеспечения нарушается любыми описанными выше тестами,
см. D1.
Требования к документации:
Требования к документации
Документация должна описывать:
(в дополнение к требованиям к
 Как гарантируется подлинность программной идентифи- документации для риска классов B и С):
кации.
 Как гарантируется подлинность утверждения уполномо- В документации должна быть
отражена реализация подлинченным органом.
 Как гарантируется, что загружаемое программное обес- ности.
печение является утвержденным для типа средств измерений, в которые оно загружается.
Руководство по подтверждению:
Руководство по подтверждеПроверки, основанные на документации, и функциональные про- нию (в дополнение к руководверки:
ству для риска классов B и С):
 Проверяется документация, описывающая, каким обра- Проверки, основанные на дозом происходит предотвращение загрузки мошенниче- кументации:
 Проверяется, отвечают
ского программного обеспечения.
ли предпринятые меры
 Посредством функциональных тестов проверяется, что
современному состоязагрузка мошеннического программного обеспечения
нию требований к выпредотвращается.
сокому уровню защиГарантируется подлинность проверок программного
ты.
обеспечения в соответствии с документацией и посредством функциональных тестов.
Пример приемлемого решения:
1. Подлинность. Для сохранения целостности (см.D3) генерируется электронная
подпись для загружаемой части программного обеспечения. Подлинность
гарантируется, если ключ, сохраняемый в установленной части программного
обеспечения прибора, подтверждается подписью разработчика. Соответствие
ключа должно производиться автоматически.
2. Уполномоченный орган.
Ключ сохраняется
в установленной части
программного обеспечения до начальной проверки.
3. Правильность типа средства измерений.
Проверка типа средства измерений требует автоматической идентификации
(сравнения) типа средства измерений, запись о котором хранится в фиксированной
части программного обеспечения, со списком, вложенным в программное
обеспечение.
4. Утверждение уполномоченным органом.
4. Утверждение
Если подлинность гарантируется использованием ключа
уполномоченным
разработчика, то может предполагаться утверждение
органом.
уполномоченным органом.
Для проверки того, что
программное
обеспечение
действительно
утверждено,
74
одно из решений заключается
в том, что все загруженное
программное
обеспечение
содержит
ответственную
подпись
авторизации.
Открытый
ключ
ответственной
подписи
авторизации сохраняется в
средстве
измерений
и
используется
для
автоматической
проверки
подписи,
приложенной
к
программному обеспечению.
Итоги
проверки
могут
отображаться
на
дисплее
средства
измерений
сравнением
с
открытым
ключом
ответственного
уполномоченного.
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код установленной части программного обеспечения для проверки подлинности загруженного программного обеспечения
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
 Проверяется, что меры, предпринятые для проверки подлинности, являются подходящими.
75
Риск класса B
Риск класса C
Риск класса D
D3: Целостность загружаемого программного обеспечения
Должны применяться средства гарантирующие, что загружаемое программное обеспечение в
течение загрузки не изменяется недопустимым образом.
Специальные примечания:
1. До загрузки программного обеспечения, используемого впервые, средство
измерений должно автоматически проверять, что загружаемое программное
обеспечение не изменяется недопустимым образом.
2. Если загружаемое программное обеспечение не проходит этот тест, см. D1.
Требования к документации:
Требования к документации
Документация должна описывать, как гарантируется целост- (в дополнение к требованиям к
ность программного обеспечения.
документации для риска классов B и С):
В документации должны быть
показаны гарантии целостности.
Руководство по подтверждению:
Руководство по подтвержде Для гарантии целостности программное обеспечение нию (в дополнение к руководпроверяется после загрузки в соответствии с документа- ству для риска классов B и С):
Проверки, основанные на доцией и посредством функциональных проверок.
кументации:
 Проверяется, отвечают
ли предпринятые меры
современному состоянию требований к высокому уровню защиты.
Пример приемлемого решения:
Пример
приемлемого
 Целостность может быть продемонстрирована с решения:
помощью вычисления контрольной суммы для
 Загружается
юридически значимого программного обеспечения и
генерируемое
хэш–
сравнением ее с контрольной суммой, введенной в
значение программного
программное
обеспечение
(см.
также
пример
обеспечения
приемлемого решения в U2).
(алгоритмы, например,
SHA-1, RipeMD -160) и
 Приемлемый алгоритм: CRC, секретный начальный
шифруется
(RSA,
вектор, длина 32 бит. Начальный вектор сохраняется в
Elliptic
Curves)
с
установленной части программного обеспечения.
ключом
подходящей
длины.
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код установленной части программного обеспечения, ответственного за целостность
загружаемого программного обеспечения.
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
 Проверяется, что меры, предпринятые для проверки целостности, являются подходящими.
76
Риск класса B
Риск класса C
Риск класса D
D4: Прослеживаемость загружаемого юридически значимого программного обеспечения
С помощью подходящих технических средств должно гарантироваться, что загружаемое
юридически значимое программное обеспечение является достаточно прослеживаемым в
средстве измерений для последующего контроля.
Специальные примечания:
1. Это требование дает возможность инспектирующим органам, которые ответственны за
метрологический контроль юридически значимого программного обеспечения, провести
обратное прослеживание загрузок юридически значимого программного обеспечения за
достаточный период времени (который зависит от национальной юрисдикции).
2. Средства прослеживаемости и соответствующие записи являются частью юридически
значимого программного обеспечения и, как таковые, должны защищаться.
Требования к документации:
Требования к документации
Документация должна:
(в дополнение к требованиям к
 Кратко описывать, как средства прослеживаемости ис- документации для риска классов B и С):
полняются и защищаются.
 Устанавливать, как загружаемое программное обеспече- В документации должны быть
показаны гарантии прослежиние может быть прослежено.
ваемости.
Руководство по подтверждению:
Руководство по подтверждеПроверки, основанные на документации:
нию (в дополнение к руковод Проверяется, что средства прослеживаемости исполня- ству для риска классов B и С):
Проверки, основанные на доются и защищены.
кументации:
Функциональные проверки:
 Проверяется, отвечают
 Выборочными проверками проверяется функциональли предпринятые меры
ность средств прослеживаемости.
современному состоянию требований к высокому уровню защиты.
Пример приемлемого решения:
 Контрольный журнал. Средство измерений может быть снабжено файлом событий, где
автоматически записываются, как минимум, дата и время загрузки, идентификация
загружаемого юридически значимого программного обеспечения, идентификация
загружаемой части и запись об успешной загрузке. Запись создается для каждой попытки
загрузки, независимо от ее успешности.
 После заполнения файла событий техническими средствами должно гарантироваться, что
дальнейшая загрузка невозможна. Журнал событий может быть стерт разрушением
физической или электронной пломбы, и может быть снова запломбирован только
инспектирующими органами.
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код установленной части программного обеспечения, ответственный за прослеживание
процессов загрузки и управление журналом событий.
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
 Проверяется, что средства, осуществляющие прослеживаемость процессов загрузки,
являются подходящими.
 Проверяется, что средства, осуществляющие защиту журнала событий, являются
подходящими.
77
Риск класса B
Риск класса C
Риск класса D
D5: Разрешение на загрузку
Техническими средствами должно гарантироваться, что программное обеспечение может быть
загружено только с разрешения пользователя или владельца средства измерений.
Специальные примечания:
1. Как только средство измерений передается на обслуживание пользователю или владельцу,
они становятся ответственными за него. Это требование гарантирует, что изготовитель не
может изменить юридически значимое программное обеспечение средства измерений без
согласия ответственных за него лиц.
2. Средства, которыми пользователь/собственник выражает свое разрешение, являются
частью юридически значимого программного обеспечения и, как таковые, должны быть
защищены. Его разрешение требуется обязательно, если не оговорено иное
3. Готовность прибора к загрузке для пользователя/собственника должна показываться.
Требования к документации:
Документация должна кратко описывать технические средства, с помощью которых пользователем/собственником подтверждается разрешение на процесс загрузки.
Руководство по подтверждению:
Проверки, основанные на документации:
 С помощью документации проверяется, что технические средства предотвращения загрузки юридически значимого программного обеспечения без полного согласия пользователя
исполняются.
Функциональные проверки:
 Проверяется, что после каждой загрузки для новой загрузки требуется новое согласие
пользователя.
 Выборочными проверками проверяется, что программное обеспечение, загружаемое без
согласия пользователя, не может быть загружено.
Пример приемлемого решения:
 Используются подходящие выключатель или ключ, когда пользователь/собственник
осуществляют первоначальную загрузку.
 Для удаленной загрузки юридически значимое программное обеспечение средства
измерений может содержать защищенный программный выключатель, которым
пользователь/собственник разрешает удаленную загрузку в свое отсутствие.
 Разрешение может ограничиваться одной загрузкой (или ограниченным числом загрузок),
и должен быть предусмотрен период ожидания после получения разрешения.
 Если для распознавания отправителя используется числовая подпись, открытый ключ
письма должен сохраняться в установленной части программного обеспечения средства
измерений. Автоматизированные средства должны устанавливать подлинность подписи,
присоединенной к программному обеспечению.
Дополнения для риска класса E
Требования к документации (в дополнение к требованиям к документации для риска классов B и
C):
Исходный код установленной части программного обеспечения, ответственный за получение разрешения пользователя/собственника для загрузки.
Руководство по подтверждению (в дополнение к руководству для риска классов B и C):
Проверки, основанные на исходном коде:
 Проверяется,
что
средства,
осуществляющие
получение
разрешения
пользователя/собственника для загрузки, являются подходящими.
78
10 Приложение I: Специальные приборные требования к программному обеспечению
Это Приложение предназначено для дополнения общих требований к программному
обеспечению, изложенных в предыдущих главах, и не может рассматриваться изолировано от частей P и U и других Приложений (см. главу 3). Это отражает существование Приложения MID MI-x, содержащего специальные аспекты и требования для
средств измерений или систем (или подсистем). Эти требования, однако, не означают
уход от требований MID. Если делается ссылка на рекомендации МОЗМ или на стандарты ИСО/МЭК, то это делается только тогда, когда они могут быть рассмотрены как
нормативные документы MID и если они поддерживают согласованную интерпретацию требований MID.
Кроме специальных аспектов программного обеспечения средств измерений и требований, Приложение I содержит специальные назначения классов риска для средств измерений (или категорий), которые гарантируют согласованный уровень проверок, защиты и соответствия программного обеспечения.
Пока Приложение I является первоначальной редакцией, которая должна быть завершена представительной Рабочей группой WELMEC, обладающей соответствующими
специальными сведениями. Следовательно, Приложение I является «открытой структурой», т.е. оно представляет собой - кроме начального назначения классов риска - частично заполненную схему (например, подпрограмма для счетчиков и автоматических
весов). Оно может быть также использовано для других средств измерений, удовлетворяющих (или не удовлетворяющих) MID в соответствии с опытом и решениями
представительной Рабочей группы WELMEC. Нумерация x подразделов, имеющая
вид 10.x, следует из нумерации специального приложения MID MI-x. Средства измерений, не удовлетворяющие требованиям MID, могут добавляться, начиная с 10.11.
Имеются различные аспекты программного обеспечения средств измерений, которые
нуждаются в рассмотрении для определенных типов x средств измерений. Эти аспектами следует систематизировать следующим образом: каждый подраздел 10.x должен
быть подразделен на секции 10.x.y, где y относится к последующим аспектам.
10.x.1 Специальные правила, стандарты и другие нормативные документы
Специальные правила для средств измерений (или их категорий), стандарты и
другие нормативные документы (например, рекомендации МОЗМ) или руководства
WELMEC должны здесь упоминаться, потому что они помогают формировать специальные требования к программному обеспечению средств измерений (или их категорий) как интерпретацию требований приложения I MID и специальных приложений
MI-x .
Обычно специальные требования к программному обеспечению прилагаются в дополнение к общим требованиям в предыдущих главах. Кроме того, должно быть ясно
установлено, заменяют ли специальные требования к программному обеспечению одно (или более) общее требование к программному обеспечению, или одно (или более)
общее требование не применимо, и по какой причине.
10.x.2 Техническое описание
Здесь могут быть даны:
- примеры наиболее общих специальных технических конфигураций,
- применения частей P , U и приложений к этим примерам, и
79
-
-
-
полезные (с точки зрения специфики средств измерений) списки проверок,
как для изготовителя, так и для проверяющего. В описании должны быть
упомянуты
принцип измерений (совокупные или отдельные независимые измерения;
повторяемые или не повторяемые измерения, статические или динамические измерения), и
определение сбоя и реакция; здесь возможны два случая:
наличие сбоя является очевидным или может быть просто проверено, или имеются аппаратные средства для обнаружения сбоя,
b) наличие сбоя не очевидно и не может быть легко проверено, и отсутствуют аппаратные
средства для обнаружения сбоя.
a)
В последнем случае (b) обнаружение сбоя и реакция требуют подходящих программных средств и, следовательно, соответствующих программных требований.
- программная конфигурация; должны быть поставлены, по крайней мере,
следующие вопросы:
a)
b)
c)
d)
e)
f)
-
Имеем дело с модульной, основанной на компьютере общего назначения, системой или со
специализированным средством измерений со встроенной системой, являющейся предметом законодательного (метрологического) контроля?
Компьютерная система является отдельной или частью закрытой сети, например, кабельной сети, token-ring LAN, или открытой сети, например, Интернета?
Датчик отделен (отделение местоположения и отделение питания) от системы типа U или
является частью или полностью встроен в нее?
Интерфейс пользователя всегда находится под законодательным (метрологическим) контролем (как для средств измерений типа P, так и для типа U) или может быть подключен к
операционной части, не попадающей под законодательный (метрологический) контроль?
Предусматривается ли долговременное сохранение данных? Если да, то сохранение является локальным (например, на твердом диске) или удаленным (например, на файловом сервере)?
Является ли среда сохранения фиксированной (например, внутренний ROM) или перемещаемой (например, флоппи – диск, микропроцессорная карта)?
программная конфигурация и окружение; должны быть поставлены, по
крайней мере, следующие вопросы:
a) Какая операционная система используется или может быть использована?
b) Какие другие программные приложения существуют в системе, кроме юридически значимого программного обеспечения?
c) Имеется ли программное обеспечение, не являющееся субъектом законодательного (метрологического) контроля и относительно которого подразумевается свободная модификация
после утверждения?
10.x.3 Специальные требования к программному обеспечению
Здесь должен быть приведен список специальных требований к программному обеспечению и комментарии с использование подобных форм из предыдущих глав.
10.x.4 Примеры юридически значимых функций и данных
Здесь должны быть даны примеры
- специальных параметров прибора (например, индивидуальная конфигурация и параметры калибровки специализированного средства измерений),
- специальных параметров типа (например, специальные параметры, которые
фиксируются при испытаниях с целью утверждения типа) или
- юридически значимые, специальные функции.
10.x.5 Другие аспекты
Здесь могут быть упомянуты другие аспекты, например, специальные требования к
документации для проверки типа (программного обеспечения), специальные описания
80
и инструкции, используемые в сертификатах об утверждении типа, или другие аспекты
(например, требования, относящиеся к возможности тестирования).
10.x.6 Назначение класса риска
Здесь должен быть определен соответствующий класс риска для средства измерений
типа x. Это может быть сделано
- или вообще (для всех категорий в пределах соответствующего типа), или
- в зависимости от области применения, или категории, или других аспектов,
если они существуют.
81
10.1 Счетчики воды
10.1.1 Специальные правила, стандарты и другие нормативные документы
Статус счетчиков воды, используемых в жилищной, коммерческой сфере и в легкой промышленности, в соответствии со статьей 2 MID, предписывает им быть объектом регулирования в MID.
Специальные требования этой главы основаны только на Приложении MI-001.
Рекомендации и стандарты МОЗМ во внимание не принимаются.
10.1.2 Техническое описание
10.1.2.1 Аппаратная конфигурация
Счетчики воды обычно относятся к средствам измерений, предназначенным для конкретной цели (тип Р в этом документе).
10.2.2.2 Конфигурация программного обеспечения
Она является специфической для каждого изготовителя, но обычно ожидается, что она
следует рекомендациям, данным в основной части этого Руководства.
10.1.2.3 Принцип измерения
Счетчики воды непрерывно накапливают потребляемый объем (измеряют потребляемый
объем с нарастающим итогом). Накопленный объем отображается средством измерений.
При этом используются разные принципы исполнения.
Измерения объема могут проводиться однократно.
10.1.2.4 Обнаружение сбоев и реакция
Требование MI-001, 7.1.2. имеет дело с электромагнитными возмущениями. Существует
необходимость в толковании этого требования для программного обеспечения, контролирующего средства измерений, потому что обнаружение возмущения и восстановление
являются возможными только с помощью привлечения специальных аппаратных частей и
специального программного обеспечения. С точки зрения программного обеспечения нет
никакой разницы в причинах возмущений (электромагнитные, электрические, механические и т.п.), поскольку процедура восстановления во всех случаях одна и та же.
82
10.1.3 Специальные программные требования (Счетчики воды)
Риск класса В
Риск класса С
Риск класса D
I1-1: Восстановление от сбоев
Программное обеспечение должно восстанавливаться при возмущении нормального функционирования.
Специальные примечания:
Должна появляться отметка даты для помощи в регистрации периодов сбоев.
Требования к документации:
Краткое описание механизма восстановления от сбоев и когда он вызывается.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, все ли реализации восстановления от сбоев являются подходящими.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин.
Пример приемлемого решения:
Схема обеспечения безопасности перезагружается периодически подпрограммой микропроцессора для задержки ее срабатывания. Если какая-либо функция не срабатывает, или, в худшем
случае, когда микропроцессор зависает в произвольном бесконечном цикле, перезагрузка схемы
безопасности не происходит, и она срабатывает после определенного промежутка времени.
Риск класса В
Риск класса С
Риск класса D
I1-2: Дублирующее оборудование
Должно быть оборудование, обеспечивающее периодическое дублирование юридически значимых
данных, таких как измеренные значения и текущее состояние процесса измерений, в случае
нарушений. Эти данные должны быть сохранены в энергонезависимой памяти.
Специальные примечания:
Интервал сохранения должен быть достаточно малым для того, чтобы расхождение между текущими и накопленными сохраненными данными было малым.
Требования к документации:
Краткое описание того, какие данные дублируются, и когда это имеет место. Может быть произведен расчет максимальной погрешности накопленных значений.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, все ли юридически значимые данные сохраняются и могут ли они быть восстановлены.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин.
Пример приемлемого решения:
Юридически значимые данные дублируются так, как требуется (например, каждые 60 мин).
83
Риск класса В
Риск класса С
Риск класса D
I1-3: Приложение 1, 8. 5 MID (препятствование переустановке накопленных измеренных значений)
Подпрограмма средства измерений изображения поставленного количества или изображения,
из которого может быть получено общее количество поставки, полная или частичная ссылка
на которую является основой для платежей, не должна быть способной к переустановке в процессе использования.
Специальные примечания:
Накопленные записи средства измерений могут быть переустановлены прежде, чем они будут
использованы.
Требования к документации:
Документация на средства защиты от переустановки записей объема.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, что накопленные юридически значимые значения не могут быть бесследно
переустановлены.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин.
Пример приемлемого решения:
Записи для объема защищены от изменений и переустановки с помощью тех же средств, как
и параметры (см. Р7).
Риск класса В
Риск класса С
Риск класса D
I1-4: Динамическое поведение
Юридически не значимое программное обеспечение не должно оказывать недопустимое влияние
на динамическое поведение процесса измерений.
Специальные примечания:
 Это требование применяется в дополнение к требованиям S1, S2 и S3, если реализовано
разделение программного обеспечения в соответствии с приложением S.
 Дополнительное требование гарантирует, что в масштабе реального времени использования счетчиков динамическое поведение юридически значимого программного обеспечения не подвергается недопустимому влиянию со стороны юридически не значимого программного обеспечения, т.е. возможности юридически значимого программного обеспечения не уменьшаются недопустимо юридически не значимым программным обеспечением.
Требования к документации:
 Описание иерархии прерывания.
 Временная диаграмма проверок программного обеспечения. Временные ограничения на
юридически не значимые проверки.
Руководство по подтверждению:
Проверки, основанные на документации:
 Документация на пределы временного ограничения для юридически не значимых проверок является необходимой для программиста юридически не значимой части программного обеспечения.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин.
Пример приемлемого решения:
Иерархия прерывания исполняется таким образом, чтобы избежать недопустимое влияние.
84
10.1.4 Примеры юридически значимых параметров
Счетчики воды имеют параметры, подобные константам для расчетов, для конфигурирования и т.д., но также для установки функций прибора. Относительно идентификации и
защиты параметров и наборов параметров следует обращаться к требованиям Р2 и Р7 Руководства Р.
Далее приводятся некоторые типичные параметры счетчиков воды. (Эта таблица будет
скорректирована после того, как Рабочая группа 11 WELMEC придет к окончательному
решению об ее содержании).
Параметр
Защита
Установка
Примечание
Коэффициент калибровки
×
Коэффициент линеаризации
×
10.1.5 Другие аспекты
Для коммунальных приложений ожидается, что загрузка программного обеспечения
(Приложение D, глава 9) не является очень важной.
Накопленные энергия и объем, записанные квартирными счетчиками, не являются длительно сохраняемыми согласно Приложению L (глава 6). Для средств измерений, которые
только измеряют накопленные энергию/объем, применение Приложения L не является необходимым.
10.1.6 Назначение класса риска
Пока, в соответствии с решениями представительной Рабочей группы 11 WELMEC (2-е
заседание, 3-4 марта 2005 г.), следующий класс риска рассматривается как подходящий и
должен применяться, если проверки программного обеспечения основаны на этом Руководстве и выполняются для (программно контролируемых) счетчиков воды:
- Риск класса С для средств измерений типа Р
Окончательное решение, однако, пока не принято, и Рабочая группа 11 пересмотрит это
значение в связи с обсуждением соответствующего класса риска для средств измерений
типа U.
85
10.2 Счетчики газа и преобразователи объема
10.2.1 Специальные правила, стандарты и другие нормативные документы
Статус счетчиков газа и преобразователей объема, используемых в жилищной, коммерческой сфере и в легкой промышленности, в соответствии со статьей 2 MID, предписывает
им быть субъектом регулирования в MID.
Специальные требования этой главы основаны только на Приложении MI-002.
Рекомендации и стандарты МОЗМ во внимание не принимаются.
10.2.2 Техническое описание
10.2.2.1 Аппаратная конфигурация
Счетчики газа и преобразователи объема обычно относятся к средствам измерений, предназначенным для конкретной цели (Тип Р в этом документе). Они могут иметь один или
более входов от внешних датчиков и могут быть различными аппаратными единицами.
10.2.2.2 Конфигурация программного обеспечения
Она является специфической для каждого изготовителя, но обычно ожидается, что она
следует рекомендациям, данным в основной части этого Руководства.
10.2.2.3 Принцип измерения
Счетчики газа непрерывно накапливают потребляемый объем (измеряют потребляемый
объем с нарастающим итогом). Накопленный объем отображается средством измерений.
При этом используются разные принципы исполнения. Преобразователь объема используется для приведения объема к нормальным условиям. Преобразователь может составлять
единое целое со счетчиком.
Измерения объема могут проводиться однократно.
10.2.2.4 Обнаружение сбоев и реакция
Требование MI-002, 4.3.1 имеет дело с электромагнитными возмущениями. Существует
необходимость в толковании этого требования для программного обеспечения, контролирующего средства измерений, потому что обнаружение возмущения и восстановление
являются возможными только с помощью привлечения специальных аппаратных частей и
специального программного обеспечения. С точки зрения программного обеспечения, нет
никакой разницы в причинах возмущений (электромагнитные, электрические, механические и т.п.), поскольку процедура восстановления во всех случаях одна и та же.
86
10.2.3 Специальные программные требования (Счетчики газа и преобразователи
объема)
Риск класса В
Риск класса С
Риск класса D
I2-1: Восстановление от сбоев
Программное обеспечение должно восстанавливаться при возмущении нормального функционирования.
Специальные примечания:
Должна появляться отметка даты для помощи в регистрации периодов сбоев.
Требования к документации:
Краткое описание механизма восстановления от сбоев и когда он вызывается.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, все ли реализации восстановления от сбоев являются подходящими.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин.
Пример приемлемого решения:
Схема обеспечения безопасности перезагружается периодически подпрограммой микропроцессора для задержки ее срабатывания. Если какая-либо функция не срабатывает, или, в худшем
случае, когда микропроцессор зависает в произвольном бесконечном цикле, перезагрузка схемы
безопасности не происходит, и она срабатывает после определенного промежутка времени.
Риск класса В
Риск класса С
Риск класса D
I2-2: Дублирующее оборудование
Должно быть оборудование, обеспечивающее периодическое дублирование юридически значимых данных, таких как измеренные значения и текущее состояние процесса измерений, в случае
нарушений. Эти данные должны быть сохранены в энергонезависимой памяти.
Специальные примечания:
Интервал сохранения должен быть достаточно малым для того, чтобы расхождение между текущими и накопленными сохраненными данными было малым.
Требования к документации:
Краткое описание того, какие данные дублируютс, и когда это имеет место. Может быть произведен расчет максимальной погрешности накопленных значений.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, все ли юридически значимые данные сохраняются и могут ли они быть восстановлены.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин.
Пример приемлемого решения:
Юридически значимые данные дублируются так, как требуется (например, каждые 60 мин).
87
Риск класса В
Риск класса С
Риск класса D
I2-3: MI-002, 5.2 (индикация пригодности)
Индикация общего некорректированного объема должна иметь достаточное число цифр для
гарантии того, что, когда счетчик работает в течение 8000 часов при Qmax , его показания не
возвращаются к начальному значению.
Специальные примечания:
Требования к документации:
Документация на внутреннее представление записи объема.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, является ли емкость сохранения достаточной.
Пример приемлемого решения:
Типичные значения расхода для квартирного счетчика Qmax = 6 м3 /ч. Требуемое предельное
значение 48000 м3 (электронные газовые счетчики показывают до 99999 м3).
Риск класса В
Риск класса С
Риск класса D
I2-4: Приложения MID 1, 8. 5 (Препятствование переустановке накопленных измеренных значений)
Подпрограмма средства измерений изображения поставленного количества или изображения,
из которого может быть получено общее количество поставки, полная или частичная ссылка
на которую является основой для платежей, не должна быть способной к перезагрузке в процессе использования.
Специальные примечания:
Накопленные записи средства измерений могут быть перезагружены прежде, чем они будут использованы.
Требования к документации:
Документация на средства защиты от переустановки записей объема.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, что накопленные юридически значимые значения не могут быть бесследно
перезагружены.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин.
Пример приемлемого решения:
Записи для объема защищены от изменений и перезагрузки с помощью тех же средств, как и параметры (см. Р7).
88
Риск класса В
Риск класса С
Риск класса D
I2-5: MI-002, 5.2 (Срок службы источника питания)
Предназначенный источник питания должен иметь срок службы не менее пяти лет. После достижения 90 % срока службы должно показываться предупреждение.
Специальные примечания:
Срок службы используется здесь в смысле наличной энергетической мощности.
Если источник питания может быть заменен, то в области применения, параметров и юридически
значимых данных не должно происходить никаких нарушений, обусловленных заменой.
Требования к документации:
Документация на источник энергетической мощности, максимальный срок службы (независимый
от потребления энергии), измерения для определения потребления или наличной энергии; описание средств предупреждения малого значения наличной энергии.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, являются ли произведенные измерения достаточными для надзора за наличной энергией.
Пример приемлемого решения:
Часы работы или случаи «пробуждения» прибора фиксируются, сохраняются в неизменяемой
памяти и сравниваются с номинальным значением срока службы источника. Если достигается
90% срока службы, то появляется соответствующее предупреждение. Программное обеспечение
определяет замену источника питания и переустанавливает счетчик.
Могут использоваться другие решения непрерывного отображения состояния энергетического
запаса.
Риск класса В
Риск класса С
Риск класса D
I2-6: MI-002, 9.1 (Устройство электронного преобразования)
Устройство электронного преобразования должно быть способным фиксировать выход измеренных значений за пределы, заданные изготовителем для параметров, как условие для достижения требуемой точности. В случае выхода измеренных значений за эти пределы устройство
преобразования должно останавливать суммирование преобразуемого значения и может суммировать преобразуемые значения отдельно для времени их выхода за эти пределы.
Специальные примечания:
Должен быть дисплей, отображающий нарушенное состояние.
Требования к документации:
Документация на отдельные записи для преобразованного количества и нарушенного количества.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, являются ли произведенные измерения достаточными для управления в
условиях, отличных от нормальных.
Пример приемлемого решения:
Программное обеспечение отображает значимые входные значения и сравнивает их с предписанными ограничениями. Если все значения находятся в пределах допусков, то преобразованные
значения суммируются и записываются в предназначенный для этого регистр (назначенное переменное). В ином случае (при выходе данных за пределы допуска) запись проводится в другой
переменной.
При другом решении должна быть только одна накопительная запись, но при этом записываются
в файл событий (см. Р7) начальная и конечная даты, время и зафиксированные значения периода
функционирования вне операционной области.
Могут быть показаны обе величины. Пользователь может ясно идентифицировать и различать
правильную и нарушенную индикацию средствами штатной индикации.
89
Риск класса В
Риск класса С
Риск класса D
I2-7: MI-002, 5.5 (Тестирующий элемент)
Счетчик газа должен иметь тестирующий элемент, который должен обеспечить выполнение
тестирования в течение разумного времени.
Специальные примечания:
Тестирующий элемент для уменьшения времени, затрачиваемого на тестовые процедуры, обычно
используется до инсталляции и нормального функционирования счетчика.
В течение тестирования должны использоваться тот же способ и соответствующие записи, что и
в течение стандартной моды функционирования.
Требования к документации:
Документация на тестирующий элемент и инструкции для активации способа тестирования.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, обеспечено ли средствами тестирующего элемента тестовая процедура
счетчика газа в течение всего времени, затраченного на тестирование.
Пример приемлемого решения:
Внутренние часы могут быть ускорены. Процессы, продолжающиеся, например, в течение недели, месяца или даже года, и переполняющие записи, могут быть испытаны в режиме тестирования в течение промежутка времени, равного минутам или часам.
Риск класса В
Риск класса С
Риск класса D
I2-8: Динамическое поведение
Юридически не значимая часть программного обеспечения не должна недопустимым образом
влиять на динамическое поведение процесса измерения.
Специальные примечания:
 Это требование применяется в дополнение к S-1, S-2 и S-3, если реализовано разделение
программного обеспечения в соответствии с Приложением S.
 Дополнительное требование гарантирует, что в течение реального времени действия
счетчика динамическое поведение юридически значимого программного обеспечения не
будет подвержено недопустимому влиянию со стороны юридически не значимого программного обеспечения, т.е. ресурсы юридически значимого программного обеспечения
недопустимо не уменьшаются посредством юридически не значимой части.
Требования к документации:
 Описание иерархии нарушений.
 Временная диаграмма проверок программного обеспечения. Пределы на время действия
юридически не значимых проверок.
Руководство по подтверждению:
Проверки, основанные на документации:
 Документация на ограничение времени действия юридически не значимых проверок является доступной для программиста юридически не значимой части программного обеспечения.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин.
Пример приемлемого решения:
Иерархия нарушений управляется способом, который исключает недопустимое влияние.
10.2.4 Примеры юридически значимых параметров
Счетчики газа и преобразователи объема часто имеют большой набор параметров. Они
используются как константы для расчетов, как параметры конфигурации т.д., но также для
90
установки функций прибора. Относительно идентификации и защиты параметров и наборов параметров следует обращаться к требованиям Р2 и Р7 Руководства Р.
Далее приводятся некоторые типичные параметры счетчиков газа и преобразователей
объема. (Эта таблица будет скорректирована после того, как Рабочая группа 11 WELMEC
придет к окончательному решению об ее содержании).
Параметр
Защита
Установка
Примечание
Коэффициент калибровки
×
Коэффициент линеаризации
×
10.2.5 Другие аспекты
Для коммунальных приложений ожидается, что загрузка программного обеспечения
(Приложение D главы 9) не является очень важной.
Накопленные энергия или объем, записанные квартирными счетчиками, не являются длительно сохраняемыми согласно Приложению L (глава 6). Для средств измерений, которые
только измеряют накопленные энергию/объем, применение Приложения L не является необходимым.
10.2.6 Назначение класса риска
Пока, в соответствии с решениями представительной Рабочей группы 11 WELMEC (2-е
заседание, 3-4 марта 2005 г.), следующий класс риска рассматривается как подходящий и
должен применяться, если проверки программного обеспечения основаны на этом Руководстве и выполняются для (программно контролируемых) счетчиков газа и преобразователей объема:
- Риск класса С для средств измерений типа Р
Окончательное решение, однако, пока не принято, и Рабочая группа 11 пересмотрит это
значение в связи с обсуждением соответствующего класса риска для средств измерений
типа U.
Рабочая группа 11 WELMEC считает, что предоплата и интервал счета являются дополнительными к тем существенным измерительным функциям, которые регламентируются
Приложением MI-002 MID. Следовательно, отсутствуют более высокие категории риска,
назначаемые в дополнение к тем вариантам, которые уже фигурируют в этом Руководстве
по программному обеспечению. Однако основная измерительная функция должна быть
оценена, поскольку для всех других средств измерений типа Р, обладающими любой другой оценкой, необходимо продемонстрировать, что соответствующее программное обеспечение, выполняющее эти функции, не оказывает недопустимое влияние на основное измерение.
91
10.3 Счетчики активной электрической энергии
10.3.1 Специальные правила, стандарты и другие нормативные документы
Статус счетчиков, используемых в жилищной, коммерческой сфере и в легкой промышленности, в соответствии со статьей 2 MID, предписывает счетчикам активной электрической энергии быть объектом регулирования в MID. Специальные требования этой главы
основаны только на Приложении MI-003.
Рекомендации МОЗМ и стандарты МЭК во внимание не принимаются.
10.3.2. Техническое описание
Счетчики активной электрической энергии используют измерения напряжения и тока как
входные величины для вычисления с их помощью активной электрической энергии и
суммирует ее по времени подачи.
10.3.2.1 Аппаратная конфигурация
Счетчики активной электрической энергии обычно относятся к средствам измерений,
предназначенным для конкретной цели (Тип Р в этом документе). Они могут иметь один
или более входов и могут быть использованы в комбинации с внешними преобразователями.
10.3.2.2 Конфигурация программного обеспечения
Она является специфической для каждого изготовителя, но обычно ожидается, что она
следует рекомендациям, данным в основной части этого Руководства.
10.3.2.3 Принцип измерения
Счетчики активной электрической энергии непрерывно накапливают значения потребляемой энергии в сети. Накопленная энергия отображается средством измерений. При этом
используются различные измерительные преобразователи и многоуровневые принципы.
Измерения энергии может проводиться однократно.
10.3.2.4 Обнаружение сбоев и реакция
Требование MI-003, 4.3.1 имеет дело с электромагнитными возмущениями. Существует
необходимость в толковании этого требования для программного обеспечения, контролирующего средства измерений, потому что обнаружение возмущения и восстановление
являются возможными только с помощью привлечения специальных аппаратных частей и
специального программного обеспечения. С точки зрения программного обеспечения, нет
никакой разницы в причинах возмущений (электромагнитные, электрические, механические и т.п.), поскольку процедура восстановления во всех случаях одна и та же.
92
10.3.3 Специальные программные требования (Счетчики активной электрической
энергии)
Риск класса В
Риск класса С
Риск класса D
I3-1: Восстановление от сбоев
Программное обеспечение должно восстанавливаться при возмущении нормального функционирования.
Специальные примечания:
Требования к документации:
Краткое описание механизма восстановления от сбоев и когда он вызывается. Краткое описание
тестов, выполняемых изготовителем.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, все ли реализации восстановления от сбоев являются подходящими.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин..
Пример приемлемого решения:
Схема обеспечения безопасности переустанавливается периодически подпрограммой микропроцессора для задержки ее срабатывания. Если любая функция не срабатывает, или, в худшем случае, когда микропроцессор зависает в произвольном бесконечном цикле, переустановка схемы
безопасности не происходит, и она срабатывает после определенного промежутка времени, в течение которого переустанавливается микропроцессор.
Риск класса В
Риск класса С
Риск класса D
I3-2: Дублирующее оборудование
Должно быть оборудование, обеспечивающее периодическое дублирование юридически значимых данных, таких как измеренные значения и текущее состояние процесса измерений, в случае
нарушений. Эти данные должны быть сохранены в энергонезависимой памяти.
Специальные примечания:
Если устройство дублирования используется для восстановления повреждения (сбоя), должен
быть рассчитан минимальный интервал для гарантии того, что критическое изменение значения
не превышается.
Требования к документации:
Краткое описание того, какие данные дублируются, и когда это имеет место.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, все ли юридически значимые данные сохраняются и могут ли они быть восстановлены.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин.
Пример приемлемого решения:
Юридически значимые данные дублируются так, как требуется.
93
Риск класса В
Риск класса С
Риск класса D
I3-3: MI-003, 5.2 (индикация пригодности)
Индикация полной энергии должна иметь достаточное число цифр для гарантии того, что когда счетчик работает в течение 4000 часов при полной загрузке (I=Imax, U=Un и PF=1), его показания не возвращаются к начальному значению.
Специальные примечания:
Требования к документации:
Документация на внутреннее представление записи электрической энергии и вспомогательных
величин (переменных типов).
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, является ли емкость сохранения достаточной.
Пример приемлемого решения:
Типичными значениями для трехфазных электрических счетчиков являются: Pmax (4000 ч) =
3*60 A*230 V*4000 ч = 165600 кВт · ч. Это требует внутреннего представления в 4 байта.
Риск класса В
Риск класса С
Риск класса D
I3-4: Приложения MID 1, 8. 5 (Препятствование переустановке накопленных измеренных значений)
Подпрограмма средства измерений изображения поставленного количества или изображения,
из которого может быть получено общее количество поставки, полная или частичная ссылка
на которую является основой для платежей, не должна быть способной к переустановке в процессе использования.
Специальные примечания:
Накопленные записи средства измерений могут быть переустановлены прежде, чем они будут
использованы.
Требования к документации:
Документация на средства защиты от переустановки записей объема.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, что накопленные юридически значимые значения не могут быть бесследно
переустановлены.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования. Ссылка на Р3 и Р4.
Пример приемлемого решения:
Записи для энергии защищены от изменений и переустановки с помощью тех же средств, как и
параметры (см. Р7).
94
Риск класса В
Риск класса С
Риск класса D
I3-5: Динамическое поведение
Юридически не значимая часть программного обеспечения не должна недопустимым образом
влиять на динамическое поведение процесса измерения.
Специальные примечания:
 Это требование применяется в дополнение к S-1, S-2 и S-3, если реализовано разделение
программного обеспечения в соответствии с Приложением S.
 Дополнительное требование гарантирует, что в течение реального времени действия
счетчика динамическое поведение юридически значимого программного обеспечения не
будет подвержено недопустимому влиянию со стороны юридически не значимого программного обеспечения, т.е. ресурсы юридически значимого программного обеспечения
недопустимо не уменьшаются посредством юридически не значимой части.
Требования к документации:
 Описание иерархии нарушений.
 Временная диаграмма проверок программного обеспечения. Пределы на время действия
юридически не значимых проверок.
Руководство по подтверждению:
Проверки, основанные на документации:
 Документация на ограничение времени действия юридически не значимых проверок является доступной для программиста юридически не значимой части программного обеспечения.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин.
Пример приемлемого решения:
Иерархия нарушений управляется способом, который исключает недопустимое влияние.
10.3.4 Примеры юридически значимых параметров
Электронные счетчики часто имеют большой набор параметров. Они используются как
константы для расчетов, как конфигурационные параметры и т.д., но также для установки
функциональности прибора. Относительно идентификации и защиты параметров и наборов параметров следует обращаться к требованиям Р2 и Р7 Руководства Р.
Далее приводятся некоторые типичные параметры счетчиков активной электрической
энергии. (Эта таблица будет скорректирована после того, как Рабочая группа 11 WELMEC
придет к окончательному решению об ее содержании).
Параметр
Защита
Установка
Примечание
Коэффициент калибровки
×
Коэффициент линеаризации
×
10.3.5 Другие аспекты
Для коммунальных приложений ожидается, что загрузка программного обеспечения
(Приложение D главы 9) не является очень важной.
Накопленные энергия или объем, записанные квартирными счетчиками, не являются длительно сохраняемыми в смысле Приложения L (глава 6). Для средств измерений, которые
только измеряют накопленные энергию/объем, применение Приложения L не является необходимым.
95
10.3.6 Назначение класса риска
Пока, в соответствии с решениями представительной Рабочей группы 11 WELMEC (2-е
заседание, 3-4 марта 2005 г.) следующий класс риска рассматривается как подходящий и
должен применяться, если проверки программного обеспечения основаны на этом Руководстве и выполняются для (программно контролируемых) счетчиков активной электрической энергии:
- Риск класса С для средств измерений типа Р
Окончательное решение, однако, пока не принято, и Рабочая группа 11 пересмотрит это
значение в связи с обсуждением соответствующего класса риска для средств измерений
типа U.
Рабочая группа 11 WELMEC считает, что предоплата и интервал счета являются дополнительными к тем существенным измерительным функциям, которые регламентируются
Приложением MI-002 MID. Следовательно, отсутствуют более высокие категории риска,
назначаемые в дополнение к тем вариантам, которые уже фигурируют в этом Руководстве
по программному обеспечению. Однако, основная измерительная функция должна быть
оценена, поскольку для всех других средств измерений типа Р, обладающими любой другой оценкой, необходимо продемонстрировать, что соответствующее программное обеспечение, выполняющее эти функции, не оказывает недопустимое влияние на основное измерение.
96
10.4 Счетчики количества теплоты
10.4.1 Специальные правила, стандарты и другие нормативные документы
Статус счетчиков, используемых в жилищной, коммерческой сфере и в легкой промышленности, в соответствии со статьей 2 MID, предписывает счетчикам количества теплоты
быть объектом регулирования в MID. Специальные требования этой главы основаны
только на Приложении MI-004.
Рекомендации и стандарты МОЗМ во внимание не принимаются.
10.4.2 Техническое описание
10.4.2.1 Аппаратная конфигурация
Счетчики количества теплоты обычно реализуются как средства измерений, предназначенные для конкретной цели (тип Р в этом документе). Счетчик количества теплоты является или полным инструментом, или комбинированным средством измерений, состоящим
из подсистем датчика потока, пар температурных датчиков и вычислителя, как это определено в Статье 4 (b) MID, или комбинацией того и другого.
10.4.2.2 Конфигурация программного обеспечения
Она является специфической для каждого изготовителя, но обычно ожидается, что она
следует рекомендациям, данным в основной части этого Руководства.
10.4.2.3 Принцип измерения
Счетчики количества теплоты непрерывно накапливают значения энергии, потребляемой
в тепловой сети. Накопленное количество тепловой энергии отображается средством измерений. При этом используются различные принципы.
Измерения энергии могут проводиться однократно.
10.4.2.4 Обнаружение сбоев и реакция
Требование MI-004, 4.1 и 4.2 имеет дело с электромагнитными возмущениями. Существует необходимость в толковании этого требования для программного обеспечения,
контролирующего средства измерений, потому что обнаружение возмущения и восстановление являются возможными только с помощью привлечения специальных аппаратных частей и специального программного обеспечения. С точки зрения программного
обеспечения, нет никакой разницы в причинах возмущений (электромагнитные, электрические, механические и т.п.), поскольку процедура восстановления во всех случаях одна и
та же.
97
10.4.3 Специальные программные требования (Счетчики количества теплоты)
Риск класса В
Риск класса С
Риск класса D
I4-1: Восстановление от сбоев
Программное обеспечение должно восстанавливаться при возмущении нормального функционирования.
Специальные примечания:
Должны быть расставлены отметки дат для помощи в записи периодов сбоев.
Требования к документации:
Краткое описание механизма восстановления от сбоев и когда он вызывается.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, все ли реализации восстановления от сбоев являются подходящими.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин.
Пример приемлемого решения:
Схема обеспечения безопасности переустанавливается периодически подпрограммой микропроцессора для задержки ее срабатывания. Если любая функция не срабатывает, или, в худшем случае, когда микропроцессор зависает в произвольном бесконечном цикле, переустановка схемы
безопасности не происходит, и она срабатывает после определенного промежутка времени, в течение которого переустанавливается микропроцессор.
Риск класса В
Риск класса С
Риск класса D
I4-2: Дублирующее оборудование
Должно быть оборудование, обеспечивающее периодическое дублирование юридически значимых
данных, таких как измеренные значения и текущее состояние процесса измерения, в случае
нарушений. Эти данные должны быть сохранены в энергонезависимой памяти.
Специальные примечания:
Интервалы сохранения должны быть достаточно малыми для того, чтобы расхождение между
текущими и сохраненными накопленными значениями было малым.
Требования к документации:
Краткое описание того, какие данные дублируются, и когда это имеет место. Расчет максимальной погрешности, которая может иметь место для накопленных значений.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, все ли юридически значимые данные сохраняются в неизменяемой памяти и
могут ли они быть восстановлены.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин.
Пример приемлемого решения:
Юридически значимые данные восстанавливаются, как требуется (например, каждые 60 мин).
98
Риск класса В
Риск класса С
Риск класса D
I4-3: Приложения MID 1, 8. 5 (Препятствование переустановке накопленных измеренных значений)
Подпрограмма средства измерений изображения поставленного количества или изображения,
из которого может быть получено общее количество поставки, полная или частичная ссылка
на которую является основой для платежей, не должна быть способной к переустановке в процессе использования.
Специальные примечания:
Накопленные записи средства измерений могут быть переустановлены прежде, чем они будут
использованы.
Требования к документации:
Документация на средства защиты от переустановки записей объема.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, что накопленные юридически значимые значения не могут быть бесследно
переустановлены.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин.
Пример приемлемого решения:
Записи для количества теплоты защищены от изменений и переустановки с помощью тех же
средств, как и параметры (см. Р7).
Риск класса В
Риск класса С
Риск класса D
I4-4: Динамическое поведение
Юридически не значимая часть программного обеспечения не должна недопустимым образом
влиять на динамическое поведение процесса измерения.
Специальные примечания:
 Это требование применяется в дополнение к S-1, S-2 и S-3, если реализовано разделение
программного обеспечения в соответствии с Приложением S.
 Дополнительное требование гарантирует, что в течение реального времени действия
счетчика динамическое поведение юридически значимого программного обеспечения не
будет подвержено недопустимому влиянию со стороны юридически не значимого программного обеспечения, т.е. ресурсы юридически значимого программного обеспечения
недопустимо не уменьшаются посредством юридически не значимой части.
Требования к документации:
 Описание иерархии нарушений.
 Временная диаграмма проверок программного обеспечения. Пределы на время действия
юридически не значимых проверок.
Руководство по подтверждению:
Проверки, основанные на документации:
 Документация на ограничение времени действия юридически не значимых проверок является доступной для программиста юридически не значимой части программного обеспечения.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин.
Пример приемлемого решения:
Иерархия нарушений управляется способом, который исключает недопустимое влияние.
99
10.4.4 Примеры юридически значимых параметров
Счетчики количества теплоты имеют параметры, подобные константам для вычислений,
для конфигурации и т.д., но также и для установки функциональности прибора. Относительно идентификации и защиты параметров и наборов параметров следует обращаться к
требованиям Р2 и Р7 Руководства Р.
Далее приводятся некоторые типичные параметры счетчиков количества теплоты. (Эта
таблица будет скорректирована после того, как Рабочая группа 11 WELMEC придет к
окончательному решению об ее содержании).
Параметр
Защита
Установка
Примечание
Коэффициент калибровки
×
Коэффициент линеаризации
×
10.4.5 Другие аспекты
Для коммунальных приложений ожидается, что загрузка программного обеспечения
(Приложение D, глава 9) не является очень важной.
Накопленные энергия или объем, записанные квартирными счетчиками, не являются длительно сохраняемыми согласно Приложения L (глава 6). Для средств измерений, которые
только измеряют накопленные энергию/объем, применение Приложения L не является необходимым.
10.4.6 Назначение класса риска
Пока, в соответствии с решениями представительной Рабочей группы 11 WELMEC (2-е
заседание, 3-4 марта 2005 г.) следующий класс риска рассматривается как подходящий и
должен применяться, если проверки программного обеспечения основаны на этом Руководстве и выполняются для (программно контролируемых) счетчиков количества теплоты:
- Риск класса С для средств измерений типа Р
Окончательное решение, однако, пока не принято, и Рабочая группа 11 пересмотрит это
значение в связи с обсуждением соответствующего класса риска для средств измерений
типа U.
100
10.5 Измерительные системы для непрерывных и динамических измерений количества жидкостей (кроме воды)
Измерительные системы для непрерывных и динамических измерений количества жидкостей (кроме воды) являются объектом регулирования в MID. Специальные требования
приводятся в Приложении MI-005. Никакие другие специальные требования и любые
нормативные документы не рассматриваются.
10.5.1 – 10.5.5 будут наполняться, если возникнет необходимость рассмотрения в будущем.
10.5.6 Оценка класса риска.
Пока, в соответствии с решениями представительной Рабочей группы 7 WELMEC (2004
г.) и предметом будущих решений ответственной Рабочей группы WELMEC следующий
класс риска должен применяться, если проверки программного обеспечения основаны на
этом Руководстве и выполняются для (программно контролируемых) измерительных систем для непрерывных и динамических измерений количества жидкостей (кроме воды).
- Риск класса В для инструментов и приборов типа Р, если они принадлежат к некритичным категориям и некритичным областям применений
- Риск класса С для инструментов и приборов типа Р, если они принадлежат к критичным категориям и критичным областям применений
- Риск класса С для инструментов и приборов типа U, если они принадлежат к некритичным категориям и некритичным областям применений
- Риск класса D для инструментов и приборов типа U, если они принадлежат к критичным категориям и критичным областям применений
Ответственная Рабочая группа WELMEC (Рабочая группа 10) будет определять критичные и некритичные категории и области применений.
101
10.6 Взвешивающие средства измерений
Взвешивающие средства измерений разделяются на две основные категории:
1. Неавтоматические взвешивающие СИ (НАВСИ), и
2. Автоматические взвешивающие СИ (АВСИ).
В то время как АВСИ попадают под действие MID, НАВСИ таковыми не являются; они
все еще попадают под действие Европейской директивы 90/384/ЕЕС. Следовательно, Руководство по программному обеспечению WELMEC 2.3 применимо к НАВСИ, в то
время как это Руководство по программному обеспечению применяется для АВСИ.
Специальные требования этой главы основаны на приложении MI-006 и на нормативных
документах, упомянутых в 10.6.1, поскольку они поддерживают интерпретацию требований MID.
10.6.1 Специальные правила, стандарты и другие нормативные документы
5 категорий АВСИ являются объектами регулирования в Приложении MI-006 MID:
- Автоматические фиксаторы веса для доз (весы – дозаторы) (R51)
- Автоматические весы – дозаторы для расфасовывания (R61)
- Дискретные сумматоры (R107)
- Непрерывные сумматоры (конвейерные весы) (R50)
- Автоматические рельсовые мостовые весы (R106).
Номера в скобках относятся к соответствующим рекомендациям МОЗМ, которые являются нормативными документами в смысле MID. В дополнение к этому, WELMEC издала
Руководство WELMEC 2.6, которое относится к тестированию автоматических фиксаторов веса для доз (весов – дозаторов).
Существует одна категория АВСИ, которая не попадает под действие MID:
- Автоматические СИ для взвешивания дорожных транспортных средств в
движении (R134).
АВСИ всех категорий могут быть выполнены как средства измерений типа Р или U, и все
Приложения будут применимы к каждой категории.
Однако, из всех 6 категорий только дискретные сумматоры и непрерывные сумматоры (конвейерные весы) могут рассматриваться как СИ со специальными требованиями
к программному обеспечению (см. 10.6.3). Причина состоит в том, что в них измерения
накапливаются в течение относительно длительного периода времени и не могут быть повторены, если имеет место существенный сбой.
10.6.2 Техническое описание
10.6.2.1 Аппаратная конфигурация
Дискретный сумматор - это суммирующие накопительные весы - дозаторы, которые
определяют массу насыпного продукта (например, зерна), разделяя его на дискретные
порции. Система обычно состоит из одного или нескольких бункеров, снабженных загрузочными датчиками, источником электропитания, электронными контрольными и индикаторными устройствами.
Непрерывный сумматор - это конвейерные весы, которые измеряют массу продукта при
прохождении ленты над датчиком загрузки. Система обычно включает в себя транспортерную ленту, ролики, грузоприемник, снабженный датчиками загрузки, источником
электропитания, электронными контрольными и индикаторными устройствами. Могут
быть средства регулировки натяжения ленты.
102
10.6.2.2 Конфигурация программного обеспечения
Она является индивидуальной для каждого изготовителя, но обычно ожидается, что она
следует рекомендациям, данным в основной части этого Руководства.
10.6.2.3 Принцип измерения
В случае дискретного сумматора насыпной продукт подается в бункер и взвешивается.
Масса каждой дискретной порции определяется последовательно и суммируется. Каждая
дискретная порция затем добавляется к общей массе.
В случае непрерывного сумматора масса непрерывно измеряется по мере прохождения
продукта через грузоприемник. Измерения проводятся в дискретные моменты времени,
которые зависят от скорости ленты и силы на грузоприемнике. Отсутствует предумышленное разделение продукта или прерывание движения конвейерной ленты, как в случае
дискретного сумматора. Итоговая масса является суммой дискретных порций. Необходимо отметить, что в загрузочном приемнике могут использоваться силоизмерительные датчики или другие технологии, такие как вибрирующая проволока.
10.6.2.4 Дефекты
Сочленения в ленте могут быть причиной ударных эффектов, которые могут приводить к
обнулению показаний. В случае дискретного сумматора отдельный или все результаты
взвешивания дискретных порций могут быть потеряны до их суммирования.
10.6.3.Специальные программные требования (Непрерывные и дискретные сумматоры)
Приложения MI-006, глава IV, пункт 8 и глава V, пункт 6 рассматривают электромагнитные возмущения. Существует необходимость интерпретации этого требования для программно управляемых СИ, потому что обнаружение возмущения (сбоя) и последующее
восстановление возможны только с помощью привлечения специальных аппаратных
средств и специального программного обеспечения. С точки зрения программного обеспечения, нет никакой разницы в причинах возмущений (электромагнитные, электрические, механические и т.п.), поскольку процедура восстановления во всех случаях одинакова.
103
Риск класса В
Риск класса С
Риск класса D
I6-1: Обнаружение сбоев
Программное обеспечение должно обнаруживать нарушение нормального функционирования.
Специальные примечания:
При обнаружении сбоя:
a. Накопленное измерение и другие юридически значимые данные должны автоматически сохраняться в энергонезависимом накопителе информации (см. требование I6-2), и
b. грузоприемник или конвейерная лента должны автоматически останавливаться, или должен
даваться визуальный или звуковой предупреждающий сигнал (см. Требования к документации).
Требования к документации:
Краткое описание того, что проверяется, что требуется для запуска процесса обнаружения сбоя,
как действовать, если выдается сигнал об обнаружении сбоя.
Если при обнаружении сбоя невозможна немедленная автоматическая остановка конвейерной
системы (например, по соображениям безопасности), документация должна содержать описание
того, как обходиться с неизмеренным материалом и как следует его принимать в расчет.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, все ли реализации обнаружения сбоев приемлемы.
Функциональные проверки:
 Если возможно: моделируется определенная неисправность аппаратной части и проверяется, обнаруживается ли она и реагирует ли на нее программное обеспечение так, как
описано в документации.
Пример приемлемого решения:
Схема обеспечения безопасности периодически перезагружается подпрограммой микропроцессора для задержки ее срабатывания. До перезагрузки подпрограмма проверяет состояние системы, например, все ли метрологически значимые подпрограммы функционировали в течение последнего временного интервала. Если любая функция не срабатывает, или, в худшем случае, когда микропроцессор зависает в произвольном бесконечном цикле, перезагрузки схемы безопасности не происходит, и она срабатывает после определенного промежутка времени.
104
Риск класса В
Риск класса С
Риск класса D
I6-2: Дублирующее оборудование
Должно существовать оборудование, предназначенное для периодического дублирования в случае нарушения предшествующего состояния юридически значимых данных, таких как измеренные значения и текущее состояние процесса.
Специальные примечания:
a. Характеристики состояния и важные данные должны сохраняться в энергонезависимой
памяти.
b. Требование подразумевает наличие контрольного устройства сохранения, обеспечивающего автоматическое дублирование в случае нарушения. Периодическое дублирование проводится только тогда, когда контролируемое устройство сохранения недоступно
из-за аппаратных или функциональных ограничений. В таком исключительном случае
интервалы сохранения должны быть достаточно малыми, т.е. максимально возможное
расхождение между текущими и сохраненными значениями должно укладываться в
определенную часть максимально допустимой погрешности (см. Требования к документации).
c. Дублирующее оборудование обычно должно включать в себя устройство выхода из
режима ожидания для того, чтобы взвешивающая система, включая программное обеспечение, не могла приходить в неопределенное состояние, обусловленное нарушением.
Требования к документации:
Краткое описание механизма дублирования и данных, которые дублируются, и того, когда это
имеет место. Спецификация или расчет максимальной погрешности, которая может возникнуть
для накопленных значений, если реализовано циклическое (периодическое) дублирование.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, что в случае нарушения все ли юридически значимые данные сохраняются.
Функциональные проверки:
 Проверяется с помощью моделирования нарушения, работает ли механизм дублирования
так, как это описано в документации.
Пример приемлемого решения:
Схема обеспечения безопасности срабатывает, когда нет циклической перезагрузки. Это приводит к прерыванию в микропроцессоре. Программа прерывания тотчас собирает значения измерений, значения состояния и другие значимые данные и сохраняет их в энергонезависимой памяти,
например, на EEPROM или на другом подходящем носителе.
Примечание: Предполагается, что прерывание системой защиты имеет высший приоритет и преобладает по отношению к любой нормальной работе или к любому бесконечному циклу, т.е. программное управление всегда переходит к подпрограмме прерывания, если срабатывает система
безопасности.
105
10.6.4 Примеры юридически значимых функций и данных
Таблица 10.1 содержит примеры юридически значимых функций, характеризующих СИ,
их тип и данные (обозначаемые как ФУ, ДУ, ФТ, ДТ) для АВСИ по сравнению с неавтоматическими взвешивающими СИ (R76), а также ссылки на Рекомендации МОЗМ, которые в данном Руководстве не приводятся. Символ ПЗ обозначает переменные значения.
Таблица 10.1 Примеры юридически значимых функций и данных, характеризующих СИ
и тип
Функции/данные
Номер Рекомендации МОЗМ
Tип
50
51
(X)
51
(Y)
61
76
X
X
X
X
X
X
X
X
X
X
X
X
Вычисление веса
ФТ, ДТ
Анализ стабильности
ФТ, ДТ
Вычисление цены
ФТ, ДТ
X
X
Алгоритм округления для цены
ФТ,ДТ
X
X
Диапазон (чувствительность)
X
106 107
ДУ
X
X
X
X
X
X
X
Коррекция нелинейности
ДУ (ДТ)
X
X
X
X
X
X
X
Max, Min, e (диапазон), d (цена поверочного деления)
ДУ (ДТ)
X
X
X
X
X
X
X
Единицы измерения (например
, г, кг)
ДУ (ДТ))
X
X
X
X
X
X
X
ПЗ
X
X
X
X
X
X
X
Показываемое значения веса
(округленное до кратных e или d)
ПЗ
X
X
X
Тара, предварительная тара
ПЗ
Цена за единицу оплаты, цена для
оплаты
Значение веса для внутреннего разрешении
X
X
X
ПЗ
X
X
X
X
X
X
X
Сигналы состояния (например, индикация нуля, стабилизация колебаний)
ФТ
X
X
X
X
X
X
X
Сравнение действительного веса с
предварительным значением
ФТ
Автоматическое прекращение распечатки (например, при прерывании автоматического действия)
ФТ
X
ФТ (ДТ)
ФТ
X
Время прогрева
переключения между функциями,
например, нулевая загрузка/тара,
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
106
автоматическое/неавтоматическое
действие,
установка нуля/суммирование
X
X
Запись доступа к динамической
установке
ФТ (ПЗ)
Максимальный масштаб работы/диапазон рабочих скоростей
(динамическое взвешивание)
ДУ (ДТ)
Х
X
X
X
X
X
X
Параметры (продукта) для вычисления динамического взвешивания
ПЗ
X
Предварительное значение веса
ПЗ
X
Ширина регулируемого диапазона
ДУ (ДТ)
X
X
Критерий для автоматической установки нуля (напр., временной интервал, конец цикла взвешивания)
ДУ (ДТ)
X
X
Минимальная разгрузка, относительное минимальное наполнение
X
X
X
X
ДУ)
X
X
X
Предельное значение значимой
погрешности (если не 1e или 1d)
ДУ (ДТ)
X
Предельное значение
источника питания
ДУ (ДТ)
X
X
X
X
X
мощности
X
X
X
X
X
X
Указанные функции и параметры подходят для различных типов взвешивающих СИ. Если
хотя бы один из них имеется, то с ним следует обращаться как с «юридически значимым».
Таблица, однако, не означает, что это обязательный список и что любая функция или параметр, упомянутые в ней, должны быть реализованы в каждом СИ.
10.6.5 Другие аспекты
Отсутствуют
10.6.6 Назначение класса риска
Пока, в соответствии с решениями представительной Рабочей группы WELMEC (24-е заседание Рабочей группы 2, 22-23 января 2004 г.) риск класса «В» должен обычно применяться ко всем категориям АВСИ, не считаясь с типом (P или U).
107
Однако, как результат обсуждения Рабочей группы 7 (2004 г.), следующее подразделение
по отношению к инструментам типа P и U, и по отношению к дискретным и непрерывным
сумматорам, является более подходящим и будет обсуждаться снова на Рабочей группе 2
WELMEC (решение 25-го заседания Рабочей группы 2, 14-15 октября 2004 г.):
- Риск класс В для средств измерений типа Р (исключая сумматоры)
- Риск класса С для сумматоров типа Р и для других АВП типа U
- Риск класса D для сумматоров типа U
108
10.7 Таксометры
Таксометры являются объектами регулирования в MID. Специальные требования изложены в Приложении MI-007. Никакие другие специальные требования и нормативные документы пока еще не рассматриваются.
10.7.1 Специальные правила, стандарты и другие нормативные документы
Европейский стандарт EN50148, который с точки зрения MID мог бы быть нормативным
документом, пока еще не рассматривался. Имеется публикация руководящего документа о
таксометрах, как результат проекта в рамках MID-процедуры. В будущем этот документ
будет основой для соответствующего Руководства WELMEC. Также имеется предварительный документ МОЗМ как Рекомендация по таксометрам. Однако документ МОЗМ
находится на той стадии, когда он не может использоваться как нормативный документ
(по состоянию на октябрь 2004 г).
10.7.2 Техническое описание
Таксометры, как это определено в MID, измеряют время, расстояние (используя выход
удаленного генератора сигналов, не попадающего по действие MID) и рассчитывает плату
за поездку, основанную на соответствующих тарифах.
Находящиеся в обращении таксометры используют встроенную архитектуру, которая
означает, что таксометры являются специализированными СИ (типа Р) с точки зрения этого Руководства. В будущем ожидается, что таксометры будут также изготавливаться как
приборы с использованием универсального компьютера (тип U).
10.7.3 Специальные программные требования
MID Приложение MI-007, 9:
В случае снижения напряжения источника питания до значения, ниже наименьшего предела функционирования, который определен изготовителем, таксометр должен:
- продолжать работать правильно или возобновлять свое корректное функционирование без потери имеющих отношение к делу данных до падения
напряжения, если падение напряжения является временным, т.е. результатом перезапуска двигателя.
- сбрасывать существующее измерение и возвращаться в положение «Прокат», если падение напряжения является длительным.
Таксометр также нуждается в долговременном накоплении информации; данные в таксометре должны быть доступными как минимум год, см. MI-007, 15.2.
109
Риск класса В
Риск класса С
Риск класса D
I7-1: Дублирующее оборудование
Должно существовать устройство, которое автоматически дублирует значимые данные,
например, измеренные значения и текущее состояние процесса измерений, если напряжение упало ниже предела на длительное время.
Специальные примечания:
1) Эти данные должны нормально сохраняться в энергонезависимой памяти.
2) Показывается уровень напряжения, когда необходимо сохранять измеренное значение.
3) Устройства дублирования должны включать также аппаратуру для выхода из режима
ожидания, для того чтобы таксометр, включая его программное обеспечение, не оставался
в неопределенном состоянии.
Требования к документации:
Краткое описание того, какие данные восстанавливаются, и когда это имеет место.
Руководство по подтверждению:
Проверки, основанные на документации:
 Проверяется, является ли приемлемой реализация восстановления сбоя.
Функциональные проверки:
 Не требуется никаких дополнительных проверок к тем, что были выполнены при утверждении типа для подтверждения точности функционирования при наличии определенных
влияющих величин.
Пример приемлемого решения:
Детектор уровня напряжения инициирует прерывание, когда уровень напряжения падает за время
15 с. Заданная процедура прерывания собирает измеренные значения, значения состояния и другие значимые данные и сохраняет их в энергонезависимой памяти, например в EEPROM. После
повышения напряжения данные восстанавливаются, и функционирование продолжается, или
прекращается (см. MI-007, 9).
Примечание: Предполагается, что прерывание уровня напряжения имеет наивысший приоритет и может
доминировать над любой нормальной работой или над любым произвольным бесконечным циклом, т.е.
программа контроля всегда осуществляет прерывание, если напряжение падает.
10.7.4 Примеры юридически значимых функций и данных
Далее приводятся некоторые типичные параметры таксометров.
Параметр
Защита
Установка
Примечание
k-фактор
×
Число импульсов на километр
Тарифы
×
×
Находящиеся
в
обращении
ед./км и ед./ч
Параметры интерфейса
×
Бод (ед. измерения скорости передачи информации) и т.д.
10.7.5 Другие аспекты
Рекомендуется, что проверки по Директиве по автоматизации или любым другим правилам можно использовать для того, чтобы сформулировать требования для генератора сигнала расстояния, пройденного средством передвижения, используемым как такси. Предварительное предложение выглядит так:
Для средств передвижения, предполагаемых для использования в качестве такси, применяются следующие требования:
1. Генератор сигнала расстояния должен подавать сигнал с разрешением не менее 2м.
2. Генератор сигнала расстояния должен давать стабильный сигнал при любой скорости движения.
110
3. Генератор сигнала пройденного расстояния должен обладать определенными характеристиками, относящимися к уровню напряжения, ширине импульса и отношению скорости и частоты.
4. Тестируемость…
10.7.6 Назначение класса риска
Пока, в соответствии с результатами обсуждения Рабочей группы 11 WELMEC (2004 г.) и
будущими решениями представительной Рабочей группы WELMEC, следующий класс
риска рассматривается как подходящий и должен применяться, если проверки программного обеспечения основаны на этом Руководстве и выполняются для (программно контролируемых) таксометров:
- Риск класса С для средств измерений типа Р
- Риск класса D для средств измерений типа U
111
10.8. Средства измерений свойств материалов
Измерения свойств материалов являются объектом регулирования в MID. Специальные
требования приведены в Приложении MI-008.
Предмет будущих решений и обсуждений измерений свойств материалов в смысле Приложения MI-008 MID не рассматривается как относящийся к средствам измерений, контролируемым программным обеспечением.
Таким образом, в настоящее время данное Руководство по программному обеспечению не
применяется к измерениям свойств материалов.
112
10.9 Средства измерений размеров
Средства измерений размеров являются объектом регулирования в MID. Специальные
требования приведены в Приложении MI-009. Ни эти специальные требования и никакие
другие нормативные документы еще не рассматривались.
10.9.1 – 10.9.5 будут наполняться, если возникнет необходимость их рассмотрения в будущем.
10.9.6 Назначение класса риска
Пока, в соответствии с результатами обсуждения Рабочей группы 7 WELMEC (2004 г.) и
будущими решениями представительной Рабочей группы WELMEC, следующий класс
риска рассматривается как подходящий и должен применяться, если проверки программного обеспечения основаны на этом Руководстве и выполняются для (программно контролируемых ) средств измерений размеров:
- Риск класса В для средств измерений типа Р
- Риск класса С для средств измерений типа U
113
10.10. Анализаторы выхлопных газов
Анализаторы выхлопных газов являются объектом регулирования в MID. Специальные
требования приведены в Приложении MI-010. Ни эти специальные требования и никакие
другие нормативные документы еще не рассматривались.
10.10.1 – 10.10.5 будут наполняться, если возникнет необходимость их рассмотрения в будущем.
10.10.6 Назначение класса риска
Пока, в соответствии с результатами обсуждения Рабочей группы 7 WELMEC (2004 г.) и
будущими решениями представительной Рабочей группы WELMEC, следующий класс
риска рассматривается как подходящий и должен применяться, если проверки программного обеспечения основаны на этом Руководстве и выполняются для (программно контролируемых ) анализаторов выхлопных газов:
- Риск класса В для средств измерений типа Р
- Риск класса С для средств измерений типа U
114
11 Определение классов риска
Основной принцип
Требования этого Руководства различаются в зависимости от классов риска (программного обеспечения). Риски относятся к программному обеспечению средств измерений, и не к каким другим рискам. Из соображений удобства используется короткий термин «класс риска». Для каждого средства измерений должен быть назначен
класс риска, поскольку конкретные требования, относящиеся к программному обеспечению, определяются классом риска, характеризующим средство измерений.
Класс риска определяется совокупностью соответствующих уровней, требуемых для
защиты программного обеспечения, его проверки и соответствия. Для каждой из этих
категорий вводятся три уровня – низкий, средний и высокий.
Описание уровней для защиты, проверки и соответствия
Следующие определения используются для соответствующих уровней.
Уровни защиты программного обеспечения
Низкий:
Не требуется никаких средств защиты от намеренных изменений.
Средний:
Программное обеспечение защищено от намеренных изменений с
помощью легко доступных и простых программных средств (например, с помощью текстового редактора).
Программное обеспечение защищено от намеренных изменений с
помощью специальных программных средств (программы-отладчики
и редакторы жесткого диска, средства программной разработки и
т.д.).
Высокий:
Уровни проверки программного обеспечения
Низкий:
Средний:
Высокий:
Исполняется обычный набор функциональных проверок средства измерений. Никакого тестирования программного обеспечения сверх
этого не требуется.
В дополнение к низкому уровню, программное обеспечение проверяется на основе анализа документации. Документация включает в себя
описание функций программного обеспечения, параметров и т.д.
Практическая проверка программно поддерживаемых функций (выборочные проверки) может быть проверкой правильности документации и эффективности защиты измерений.
В дополнение к среднему уровню, осуществляется всестороннее тестирование программного обеспечения, обычно основанное на анализе исходного кода.
Уровни соответствия программного обеспечения
115
Низкий:
Средний:
Высокий:
Функциональность программного обеспечения, исполняемая для
каждого конкретного средства измерений, находится в соответствии
с утвержденной документацией.
В дополнение к «низкому» уровню соответствия, зависящему от технических особенностей, часть программного обеспечения должна
быть определена как зафиксированная при утверждении типа, т.е. как
неизменяемая без утверждения уполномоченным органом. Неизменяемая часть должна быть одинаковой для всех конкретных средств измерений.
Исполнение программного обеспечения в конкретных средствах измерений полностью идентично тому, которое было зафиксировано
при утверждении типа.
11.3 Определение классов риска
Из 27 теоретически возможных перестановок, только 4 или в лучшем случае 5 представляют практический интерес (риск классов B, C, D и E, возможно F). Они охватывают все классы средств измерений, попадающих под действие MID. Более того, они
предоставляют достаточные возможности для случая изменения оценок риска. Классы
определены в таблице, приводимой ниже.
Риск класса
A
B
C
D
E
F
Таблица 11.1 Определение классов риска
Защита программПроверка проСтепень
соответного обеспечения
граммного обеспе- ствия программного
чения
обеспечения
низкий
низкий
низкий
средний
средний
низкий
средний
средний
средний
высокий
средний
средний
высокий
высокий
средний
высокий
высокий
высокий
11.4 Интерпретация классов риска
Риск класса A: Это наименьший класс риска из всех. Никаких конкретных мер не
требуется против намеренных изменений программного обеспечения.
Проверка программного обеспечения является частью функционального тестирования прибора. Установление соответствия требуется на
уровне документации. Не ожидается, что какие-то средства измерений будут классифицироваться с риском класса А. Однако введением
такого класса соответствующая вероятность предусматривается.
Риск класса В: По сравнению с риском класса А требуется средний уровень защиты
программного обеспечения. Соответственно уровень проверки должен быть повышен к среднему уровню. Соответствие остается неизменным по сравнению с риском класса А.
Риск класса С: По сравнению с риском класса В, уровень соответствия повышается к
«среднему». Это означает, что часть программного обеспечения может быть декларирована как неизменяемая при утверждении типа.
Для остальной части программного обеспечения соответствие требуется только на функциональном уровне. Уровни защиты и проверки
остаются неизменными, как и при риске класса В.
116
Риск класса D: Существенное отличие по сравнению с риском класса С заключается
в повышении уровня защиты до «высокого». Уровень проверки остается неизменным на «среднем», существенно то, что информационная
документация должна показать, что предпринятые меры защиты являются подходящими. Уровень соответствия остается неизменным,
как и при риске класса С.
Риск класса Е: По сравнению с риском класса D уровень проверки повышается до
«высокого». Уровни защиты и соответствия остаются неизменными.
Риск класса F: Уровни по отношению ко всем аспектам (защита, проверка и соответствие) назначаются «высокими». Как и в случае риска класса А, не
ожидается, что какое-нибудь средство измерений будет классифицироваться с риском класса F. Однако введением такого класса соответствующая вероятность предусматривается.
117
12. Образец акта испытаний (включая контрольные таблицы)
Это образец акта испытаний, который состоит из главной части и двух приложений.
Главная часть содержит общие утверждения об объекте тестирования. Она должна соответствующим образом адаптироваться к практическому применению. Приложение 1
содержит две контрольные таблицы, состоящие из подборок, к которым применимы
соответствующие части Руководства. Приложение 2 содержит две специальные контрольные таблицы для соответственных технических частей Руководства. Они рекомендуются как конечный результат для изготовителя и проверяющего в качестве доказательства того, что они рассмотрели все имеющие отношение к делу требования.
В дополнение к образцу акта испытаний и контрольным таблицам в последнем разделе этой главы приводится информация, требуемая для сертификата об утверждении
типа.
118
12.1 Образец для общей части акта испытаний
Акт испытаний № XYZ122344
Расходомер Dynaflow модель DF101
Валидация (подтверждение правильности) программного обеспечения
(n приложений)
Полномочия
Директива по измерительным приборам (MID) устанавливает основные требования для
средств измерений, используемых в Европейском Союзе. Программное обеспечение средства измерений прошло процедуру подтверждения (валидации), чтобы показать соответствие основным требованиям MID.
Подтверждение было основано на документе WELMEC MID «Руководство по требованиям к программному обеспечению» (РуководствоWELMEC 7.2), в котором интерпретируются и объясняются основные требования к программному обеспечению. Этот документ
описывает проверки программного обеспечения, необходимые для установления соответствия требованиям MID.
Клиент
Dynaflow
P.O. Box 1120333
100 Reykjavik
Iceland
Reference: Mr Bjarnur Sigfridson
Объект тестирования
Расходомер DF100 является средством измерения, предназначенным для измерения расхода жидкостей.
Область измерений от 1 л/с до 2000 л/с. Основными функциями средства измерения являются:
- измерение расхода жидкостей
- индикация измеренного объема
- взаимодействие с датчиком.
Согласно Руководству WELMEC 7.2, расходомер описывается следующим образом:
- средство измерений для конкретной измерительной цели (встроенная система)
- долговременное сохранение юридически значимых данных
Расходомер DF100 это независимое средство измерений с первичным измерительным
преобразователем (датчиком, трансдюсером). Измерительный преобразователь встроен в
средство измерений и не может быть отсоединен. Измеренный объем показывается на
дисплее. Никакая связь с другими приборами невозможна.
Встроенное программное обеспечение средства измерений было разработано фирмой
119
Dynaflow, P.O. Box 1120333, 100 Reykjavik, Iceland.
Версия тестируемого программного обеспечения V1.2c. Исходный код включает в себя
следующие файлы:
main.c
12301 байт
23 нояб. 2003
int. c
6509 байт
23 нояб. 2003
filter.c
10897 байт
20 окт.2003
input.c
2004 байт
20 окт. 2003
display.c
32000 байт
23 нояб.2003
Ethernet.c
23455 байт
15 июнь 2002
driver.c
11670 байт
15 июнь2002
calculate.c
6788 байт
23 нояб.2003
Подтверждение было поддержано следующей документацией от изготовителя:
- DF 100 Руководство пользователя
- DF 100 Руководство по технической эксплуатации
- Описание программного обеспечения DF100 (внутренний документ, датированный 22
ноября 2003)
- Схема электронной микросхемы DF100 (рисунок № 222-31, датированный 15 октября
2003)
Окончательная версия тестируемого объекта была представлена в National Testing &
Measurement Laboratory 25 ноября 2003.
Процедура проверки
Процедура подтверждения была выполнена в соответствии с Руководством WELMEC 7.2,
Издание 1 (загруженное с www.welmec.org ).
Процедура подтверждения происходила с 1 ноября по 23 декабря 2003. Описание исполнения было проведено 3 декабря доктором K. Fehler в главном офисе Dynaflow в Рейкьявике. Другие работы по процедуре подтверждения были выполнены в Национальной испытательной и измерительной лаборатории доктором K. Fehler и M. S. Problème.
Были подтверждены следующие требования:
- Специальные требования для встроенного программного обеспечения средства измерений для конкретной измерительной цели (тип Р)
- Приложение L: Долговременное сохранение для юридически значимых данных
Контрольный лист для отобранной конфигурации находится в приложении 1 к этому отчету.
Для средства измерений был определен риск класса C.
Для подтверждения были применены следующие методы:
- идентификация программного обеспечения
- оценка полноты документации
- проверка руководства по эксплуатации
- функциональное тестирование
- описание исполнения программного обеспечения
- обзор программной документации
- анализы данных по расходу
120
- моделирование входных сигналов
Результат
Были подтверждены следующие требования Руководства WELMEC 7.2, Издание 1 без
обнаружения сбоев:
- P1, P2, P3, P5, P6, P7
(Требование P4 рассматривалось как неприменимое).
- L1, L2, L3, L4, L5, L6, L7
Контрольные листы для P-требований находятся в приложении 2.1.
Контрольные листы для L -требований находятся в приложении 2.2.
Были обнаружены две команды, которые первоначально не были описаны в руководстве по эксплуатации. Эти две команды были включены в руководство 10 декабря
2003.
Сбой программного обеспечения, который ограничивал февраль 28 днями также и в
високосном году, был обнаружен в программном пакете V1.2b. Это было скорректировано в версии V1.2c.
Программное обеспечение Dynaflow DF100 V1.2c реализует основные требования
MID.
Результаты относятся только к тестируемому объекту.
National Testing & Measurement Lab
Software Department
(Национальная испытательная и
измерительная лаборатория
Отдел программного обеспечения)
Доктор K.E.I.N. Fehler
Технический руководитель
M. S.A.N.S Problème
Технический служащий
Дата: 23 декабря 2003
121
12.2 Приложение 1 к акту испытаний: Контрольные таблицы по отдельным
наборам соответствующих требований
Первая контрольная таблица относится к решению пользователя, к какой конфигурации P или U относить тестируемое средство измерений.
Решение о типе средства измерений
Примечания
(Р)
Предлагаемое программное обеспечение всецело создано
(Да)
для измерительной задачи?
Если имеется программное обеспечение общего назначения, доступно ли оно явно пользователю?
1
2
(Нет)
Если пользователь лишен доступа к операционной системе,
возможно ли переключение операционной моды, не явля- (Да)
ющейся объектом законодательного (метрологического)
контроля?
Исполнительные программы и программная оболочка являются неизменными (кроме обновления)?
(Да)
Имеются ли средства программирования?
3
4
5
(Нет)
Заполните пустые места, как указано
Если только все ответы на 5 вопросов могут быть даны в (Р) колонке, то применимы требования части Р (Глава 4). Во всех других случаях необходимо применять требования части U (Глава 5).
Вторая контрольная таблица необходима для решения, какая из IT конфигураций применима для тестируемого средства измерений.
Решение о типе средства измерений
Приложения
требований
Да
Нет
Не
применимо
Примечания
Обладает ли прибор способностью сохранять измеренные данные в интегрированной памяти или на
удаленных, или переносных устройствах памяти?
T
Имеет ли прибор интерфейс для передачи данных,
являющихся предметом законодательного (метрологического) контроля, или прибор пересылает
данные от другого прибора, являющегося предметом контроля?
S
Имеются ли части программного обеспечения с
функциями, не являющимися предметом законодательного (метрологического) контроля, и желательно ли эти части программного обеспечения изменять после утверждения типа?
D
Загрузка программного обеспечения возможна или
желательна?
Рассматриваются Приложения требований для каждого вопроса,
на который отвечено «Да»!
L
122
Рассматриваются Приложения требований для каждого вопроса, на который отвечено
«Да»!
12.3 Приложение 2 к акту испытаний: Специальные контрольные таблицы для
соответствующих технических частей
1) Контрольная таблица основных требований для средств измерений типа Р
Контрольный лист требований для типа Р
Требование
Процедуры
тестирования
Про
ходит
Не
проходит
Не
применимо
Примечания*
Документация изготовителя отражает требования Р1 (а-g)?
Р2
Идентификация программного обеспечения реализуется так, как того требует Р2?
Р3
Команды, вводимые через интерфейс пользователя, защищены от недопустимого влияния на
юридически значимые программное обеспечение и измеренные данные?
Р4
Команды, входящие в не опечатанный интерфейс связи средства измерений, предотвращены
от недопустимого влияния на юридически значимые программное обеспечение и данные измерений?
Р5
Юридически значимое программное обеспечение и данные измерений защищены от случайных или непреднамеренных изменений?
Р6
Юридически значимое программное обеспечение защищено от недопустимой модификации,
загрузки или скачивания содержимого жесткого
диска?
Р7
Параметры, фиксирующие юридически значимые характеристики средства измерений, защищены от неавторизованных модификаций?
*Необходимы объяснения, если имеются отклонения от требований к
программному обеспечению.
Р1
2) Контрольная таблица основных требований для средств измерений типа U
Контрольный лист требований для типа U
Требование
U1
U2
U3
Процедуры
тестирования
Про
ходит
Не
проходит
Не
применимо
Примечания*
Документация изготовителя отражает требования U1 (а-g)?
Идентификация программного обеспечения реализуется так, как того требует U2?
Команды, вводимые через интерфейс пользователя, защищены от недопустимого влияния на
юридически значимые программное обеспечение и данные измерений?
123
Защищены ли команды, входящие в не опечатанный интерфейс связи средства измерений, от
недопустимого влияния на юридически значимые программное обеспечение и данные измерений?
Юридически значимое программное обеспечеU5
ние и измеренные данные защищены от случайных или непреднамеренных изменений?
Юридически значимое программное обеспечеU6
ние защищено от недопустимой модификации?
Юридически значимые параметры защищены
U7
от неавторизованных модификаций?
Средства, используемые для гарантии достоU8
верности юридически значимого программного
обеспечения и результатов, предоставляют такие гарантии?
Юридически значимое программное обеспечеU9
ние исполнено таким образом, что другие программные продукты не оказывают на него недопустимого влияния?
*Необходимы объяснения, если имеются отклонения от требований к
программному обеспечению
U4
3) Контрольная таблица для специальных требований Приложения L
Требование
L1
L2
L3
L4
L5
Процедуры
тестирования
Контрольный лист для требований Приложения L
Про
ходит
Не
проходит
Не
применимо
Примечания*
Сохраненные измеренные данные содержат всю
значимую информацию, необходимую для восстановления предыдущего измерения?
Сохраненные данные защищены от случайных
и непреднамеренных изменений?
Сохраненные измеренные данные защищены от
преднамеренных изменений, выполняемых простыми общими программными средствами
(для риска классов В и С) или специальными
фальсифицирующими программными средствами (для риска классов D и E)?
Обладают ли сохраненные измеренные данные
способностью быть достоверно прослеженными
к измерению, получившему их?
(Риск классов В и С) Обрабатываются ли ключи
и соответствующие данные как юридически
значимые и защищены ли они от искажения
посредством простых программных средств?
124
(Риски классов D и E) Являются ли ключи и
соответствующие данные, являющиеся юридически значимыми данными и хранящими секретную информацию, защищенными от искажения посредством специальных программных средств? Являются ли в этом случае подходящими методы, используемые при электронных платежах? Способен ли пользователь
проверить достоверность с помощью открытого
ключа?
Программное обеспечение, используемое для
L6
проверки сохраненных данных измерений,
осуществляет ли изображение или печать данных, проверяет изменения данных и выдает
предупреждение, если изменение имеет место?
Имеются ли средства, не позволяющие использование данных, которые были определены как
искаженные?
Данные измерений сохраняются автоматически,
L7
когда измерение закончено?
Долговременное сохранение обладает вместиL8
мостью, достаточной для намеченной цели?
*Необходимы объяснения, если имеются отклонения от требований к
программному обеспечению.
125
4) Контрольная таблица для специальных требований Приложения Т
Требование
Процедуры
тестирования
Контрольный лист для требований Приложения Т
Про
ходит
Не
проходит
Не
применимо
Примечания*
Переданные данные содержат всю значимую
информацию, необходимую для представления
или для дальнейшего использования в принимающем модуле?
Переданные данные защищены от случайных и
Т2
непреднамеренных изменений?
Юридически значимые переданные данные заТ3
щищены от преднамеренных изменений, выполняемых простыми общими программными
средствами (для риска классов В и С) или специальными фальсифицирующими программными средствами (для риска классов D и E)?
Возможно ли для программ, передающих знаТ4
чимые данные, проверять их достоверность и
относить измеренные значения к конкретному
измерению?
(Риск классов В и С) Обрабатываются ли ключи
Т5
и соответствующие данные как юридически
значимые и защищены ли они от искажения
посредством простых программных средств?
(Риски классов D и E) Являются ли ключи и
соответствующие данные, являющиеся юридически значимыми данными и хранящими секретную информацию, защищенными от искажения посредством специальных программных средств? Являются ли в этом случае подходящими методы, используемые при электронных платежах? Способен ли пользователь
проверить достоверность с помощью открытого
ключа?
Предотвращается ли использование данных,
Т6
которые были определены как искаженные?
Гарантируется ли, что измерение не подвергаТ7
лось недопустимому влиянию при передаче?
Есть ли гарантии, что измеренные данные не
Т8
будут потеряны при нарушении связи с сетевыми сервисами?
*Необходимы объяснения, если имеются отклонения от требований к
программному обеспечению.
Т1
126
5) Контрольная таблица для специальных требований Приложения S
Требование
Процедуры
тестирования
Контрольный лист для требований Приложения S
Про
ходит
Не
проходит
Не
применимо
Примечания*
Программное обеспечение, являющееся предметом законодательного (метрологического)
контроля, содержит все юридически значимое
программное обеспечение и параметры?
Гарантируется ли, что дополнительная инфорS2
мация, производимая юридически не значимым
программным обеспечением и показанная на
дисплее или распечатанная, не может искажаться информацией, источником которой явилась
юридически значимая часть?
Обмен данными между юридически значимым
S3
и не значимым программным обеспечением
осуществляется через защищенный программный интерфейс, контролирующий взаимодействие и поток данных?
*Необходимы объяснения, если имеются отклонения от требований к
программному обеспечению.
S1
127
6) Контрольная таблица для специальных требований Приложения D
Требование
Процедуры
тестирования
Контрольный лист для требований Приложения D
Про
ходит
Не
проходит
Не
применимо
Примечания*
Загрузка и последующая инсталляция программного обеспечения осуществляются автоматически? Гарантируется ли, что защищающая
оболочка программного обеспечения находится
на утвержденном уровне полноты?
Имеются ли средства, гарантирующие, что заD2
гружаемое программное обеспечение достоверно, и показывающие, что загружаемое программное обеспечение было утверждено уполномоченным органом?
Имеются ли средства, гарантирующие, что заD3
гружаемое программное обеспечение не было
недопустимым образом изменено в течение загрузки?
Гарантируется ли с помощью соответствующих
D4
средств, что загруженное юридически значимое
программное обеспечение адекватно прослеживается в пределах средства измерений для последующего контроля?
Гарантируется ли с помощью технических
D5
средств, что программное обеспечение может
быть загружено, как и положено, только с не
оставляющего сомнения разрешения пользователя или собственника средства измерений?
*Необходимы объяснения, если имеются отклонения от требований к
программному обеспечению.
D1
12.4 Информация, включаемая в сертификат об утверждении типа
В то время как полный акт испытаний является документом, относящимся к предмету
тестирования, выполняется также и процедура подтверждения, и ее результаты с определенным отбором информации, содержащейся в акте испытаний, требуются для составления Сертификата утверждения типа (ТАС). Это относится к следующей информации, которая должна быть обязательно включена в Сертификат:
 Ссылка на документацию, предоставляемую для утверждения типа,
 Идентификация и описание электронных (аппаратных) компонент (подсистем, модулей), которые важны для программных/ИТ функций средства измерений,
128






Обзор программной конфигурации (окружения), которая необходима для функционирования программного обеспечения,
Обзор модулей программного обеспечения, попадающих под законодательный
(метрологический) контроль (также и для случая разделения программного обеспечения, если оно выполнено),
Обзор и идентификация аппаратных и программных (если применяются) интерфейсов, которые важны для программных/ИТ функций средства измерений (включая, инфракрасные, беспроводного обмена данными (Bluetooth), беспроводной сетевой системы (Wireless LAN) и т.д.),
Идентификация и описание положений (местонахождения) программных компонент в средстве измерений (например, EPROM, процессор, жесткий диск и т.д.),
которые необходимо опечатывать или защищать,
Инструкции по проверке идентификации программного обеспечения (для метрологического надзора),
В случае электронного «опечатывания»: инструкция для проверки контрольного
журнала (журнала событий).
Раздел 13 Руководства содержит перекрестные ссылки на статьи и приложения MID,
которые не являются предметом непосредственного рассмотрения в данном Руководстве.
129
14 Ссылки и литература
[1] Directive 2004/22/EC of European Parliament and of the Council of 31 March 2004 on
measuring instruments. Official Journal of the European Union L 135/1, 30.4.2004
[2] Software Requirements and Validation Guide, Version 1.00, 29 October 2004, European
Growth Network «MID-Software», contract number G7RT-CT-2001-05064, 2004
[3] Software Requirements on the Basis of Measuring Instruments Directive, WELMEC 7.1,
Issue 2, 2005
130