ГОСТ Р ИСО/МЭК 24709-1-2009 Автоматическая идентификация. Идентификация биометрическая. Испытания на соответствие биометрическому программному интерфейсу (БиоАПИ). Часть 1. Методы и процедуры.

ГОСТ Р ИСО/МЭК 24709-1-2009

Группа П85

 НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

 Автоматическая идентификация

 ИДЕНТИФИКАЦИЯ БИОМЕТРИЧЕСКАЯ

 Испытания на соответствие биометрическому программному интерфейсу (БиоАПИ)

 Часть 1

 Методы и процедуры

 Automatic identification. Biometric identification. Conformance testing for the biometric application programing interface (BioAPI). Part 1: Methods and procedures

ОКС 35.040

Дата введения 2011-01-01

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 "Стандартизация в Российской Федерации. Основные положения"

Сведения о стандарте

1 ПОДГОТОВЛЕН Научно-исследовательским и испытательным центром биометрической техники Московского государственного технического университета имени Н.Э.Баумана (НИИЦ БТ МГТУ им. Н.Э.Баумана) на основе собственного аутентичного перевода на русский язык стандарта, указанного в пункте 4

2 ВНЕСЕН Управлением технического регулирования и стандартизации Федерального агентства по техническому регулированию и метрологии

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 8 декабря 2009 года N 590-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 24709-1-2007* "Информационные технологии. Испытания на соответствие биометрическому программному интерфейсу (БиоАПИ). Часть 1. Методы и процедуры" (ISO/IEC 24709-1-2007 "Information technology - Conformance testing for the biometric application programming interface (BioAPI). Part 1: Methods and procedures").

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (подраздел 3.5) и учета его принадлежности к группе стандартов "Автоматическая идентификация".

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

5 ВВЕДЕН ВПЕРВЫЕ

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

 Введение

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

Проекты международных стандартов составляются в соответствии с правилами, определенными во второй части Руководящих указаний ИСО/МЭК.

Главной задачей СТК является подготовка международных стандартов. Проекты международных стандартов, официально принятые СТК, распространяются по национальным органам по стандартизации для голосования. Для публикации международного стандарта необходимо, чтобы он был одобрен по меньшей мере 75% национальных органов по стандартизации, участвующих в голосовании.

Следует обратить внимание на то, что некоторые части настоящего стандарта могут являться объектом патентных прав. ИСО и МЭК не несут ответственность за определение некоторых или всех подобных патентных прав.

Стандарт ИСО/МЭК 24709-1 подготовлен соединенным техническим комитетом ИСО/МЭК СТК 1 (Информационные технологии), подкомитетом ПК 37 (Биометрия).

Комплекс стандартов ИСО/МЭК 24709 состоит из следующих частей, объединенных общим заголовком "Информационные технологии. Испытания на соответствие биометрического программного интерфейса":

- часть 1 - методы и процедуры;

- часть 2 - формальные тестовые утверждения для поставщиков биометрических услуг (ПБУ);

- часть 3 - формальные тестовые утверждения для инфраструктур BioAPI;

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

Настоящий стандарт устанавливает метод испытаний биометрических программных интерфейсов на соответствие требованиям ИСО/МЭК 19784-1. В настоящем стандарте приведены три модели испытаний на соответствие, позволяющие проводить испытания следующих компонентов BioAPI: приложения, инфраструктуры и поставщика биометрической услуги (ПБУ). Помимо этого, стандарт устанавливает язык утверждений, который используется для определения формальных тестовых утверждений. Фактические тестовые утверждения для каждого из трех компонентов биометрического программного интерфейса приведены в последующих частях комплекса стандартов ИСО/МЭК 24709.

Помимо определения моделей испытаний на соответствие, в стандарте ИСО/МЭК 19784-1 приведены руководства, в которых определены общие концепции создания программы оценки и сертификации соответствия спецификации BioAPI, а также управления этой программой. Данные руководства определяют виды предпринимаемых мер, ответственность, услуги и документы, рекомендуемые для проведения оценки и сертификации приложений на соответствие спецификации BioAPI. В ИСО/МЭК 19784-1 также приведено руководство по созданию методики полной оценки соответствия приложения спецификации BioAPI.

      1 Область применения

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

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

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

      2 Соответствие

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

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

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

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

Примечания

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

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

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

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

2.6 Комплект тестов должен предоставить пользователю возможность ввода всех входных данных, необходимых для проведения испытания.

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

      3 Нормативные ссылки

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

ИСО/МЭК 19784-1* BioAPI - Биометрический программный интерфейс - Часть 1: Спецификация биометрического программного интерфейса.

      4 Термины и определения

В настоящем стандарте используются термины и определения, приведенные в ИСО/МЭК 19784-1, а также следующие термины с соответствующими определениями.

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

4.2 исходный стандарт: Стандарт, устанавливающий метод испытаний.

4.3 комплект тестов на соответствие BioAPI: Программное обеспечение для проведения испытаний на соответствие ИСО/МЭК 19784-1.

4.4 утверждение соответствия BioAPI: Утверждение, описывающее соответствие тестируемой реализации всем необходимым требованиям BioAPI.

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

4.6 соответствие: Выполнение продукцией, процессом или услугой всех предъявленных требований [ИСО/МЭК 13210:1999].

4.7 требование к соответствию: Требование, установленное в исходном стандарте, устанавливающее необходимое условие в конечной, краткой и точно выраженной форме.

Примечания

1 Одно или совокупность требований к соответствию образуют утверждение.

2 Приведенное выше определение является адаптированной выдержкой из определения, приведенного в ИСО/МЭК 13210:1999.

4.8 оценка соответствия: Любое действие, прямо или косвенно связанное с определением соблюдения соответствующих требований.

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

4.10 стандартный компонент BioAPI: Приложение BioAPI, инфраструктура BioAPI или поставщик биометрической услуги, установленные в ИСО/МЭК 19784-1.

Примечания

1 См. 6.1.3.8.

2 Несмотря на то что, в соответствии с ИСО/МЭК 19784-1, поставщик биометрической функции (ПБФ) также является компонентом BioAPI, он не включен в определение 4.10, поскольку ИСО/МЭК 19784-1 не определяет ни один интерфейс ПБФ.

4.11 стандартный интерфейс BioAPI: Любой интерфейс, установленный в ИСО/МЭК 19784-1, с помощью которого один стандартный компонент BioAPI обращается к другому стандартному компоненту BioAPI.

Примечание - См. 6.1.3.8.

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

4.13 тестовый пример: Описание действий, необходимых для достижения определенной цели испытания или совокупности целей испытания.

Примечание - Приведенное выше определение является адаптированным определением термина "абстрактный тестовый пример", приведенного в ИСО/МЭК 9646-1:1994.

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

4.15 спецификация метода испытания: Документ, устанавливающий требования к функциональным возможностям и поведению, указанным в исходном стандарте в виде утверждений, и обеспечивающий полный набор кодов результатов испытания на соответствие [ИСО/МЭК 13210:1999].

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

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

4.18 код результата испытания (заключение испытания): Значение, описывающее результат испытания.

Примечание - Приведенное выше определение является адаптированной выдержкой из определения, приведенного в ИСО/МЭК 13210:1999.

4.19 сертификация - Процесс испытания программного обеспечения для оценки его соответствия определенной спецификации.

      5 Сокращения

В настоящем стандарте использованы следующие сокращения:

      6 Методика испытаний на соответствие

      6.1 Общие положения

6.1.1 Тестируемая реализация

6.1.1.1 Тестируемая реализация - это объект, который подвергается испытанию на соответствие. Для спецификаций BioAPI тестируемой реализацией является программное обеспечение, которое считается реализующим данную спецификацию. Программное обеспечение и поддерживающее его аппаратное обеспечение представляют собой тестируемую реализацию и должны быть указаны как в отчете об испытании, так и в сертификате соответствия.

6.1.1.2 Биометрическая продукция, претендующая на соответствие спецификации BioAPI, должна соответствовать всем применимым для данной продукции требованиям, изложенным в разделе "Соответствие" спецификации BioAPI. Как правило, в данном разделе установлены следующие виды требований:

a) обязательные требования, которые необходимо соблюдать во всех случаях;

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

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

6.1.1.3 Для оценки соответствия биометрической продукции необходимо утверждение, содержащее список характеристик, реализованных в соответствии со спецификацией BioAPI, для того чтобы тестируемая реализация могла быть испытана на соответствие только определенным требованиям. Такое утверждение называется ПСБПИ и должно быть подготовлено поставщиком ТР до начала испытаний на соответствие. В минимальном варианте ПСБПИ должно содержать перечень всех обязательных, условных и дополнительных требований к соответствию спецификации BioAPI, включенных в ТР.

6.1.2 Метод испытания

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

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

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

a) анализ спецификации BioAPI и разработка документально подтвержденных тестовых примеров в форме обобщенных тестовых утверждений. В дальнейшем тестовые примеры могут быть сгруппированы для формирования тестовых сценариев. Тестовые утверждения описаны в других частях комплекса стандартов ИСО/МЭК 24709;

b) реализация тестовых утверждений в виде выполняемых тестовых сценариев, которые вместе с используемыми файлами данных формируют КТСБПИ;

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

d) оценка результатов испытания с помощью критерия успешного (или неуспешного) прохождения теста.

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

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

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

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

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

6.1.2.6 Реализация метода испытания должна использовать необходимые определения, типы, синтаксис и конструкции тестовых утверждений, определенные в комплексе стандартов ИСО/МЭК 24709. Для результатов испытаний, установленных в настоящем стандарте, необходимо использовать коды результата испытания, приведенные в стандарте.

6.1.2.7 Процесс испытания на соответствие представляет собой законченный процесс выполнения всех действий испытания на соответствие, которые необходимы для оценки соответствия тестируемой реализации спецификации BioAPI. Процесс испытания на соответствие состоит из трех этапов:

a) подготовка к испытанию, включающая в себя анализ ПСБПИ, подготовку плана испытания на соответствие, выбор и настройку КТСБПИ, подготовку ТР и соответствующих условий испытания (средств, необходимых для проведения испытания);

b) проведение испытания, включающее в себя выполнение КТСБПИ и запись наблюдаемых результатов в протоколе испытания на соответствие. Результаты испытания на соответствие применимы только к ТР и среде, в которой выполнялся КТСБПИ;

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

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

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

6.1.3 Стандартные компоненты BioAPI и стандартные интерфейсы BioAPI

6.1.3.1 В настоящем стандарте установлены требования к методу проведения оценки соответствия реализаций ИСО/МЭК 19784 указанному стандарту (ИСО/МЭК 19784-1). Различают три типа реализации ИСО/МЭК 19784-1 (см. рисунок 1):

a) приложение BioAPI;

b) инфраструктура BioAPI;

c) ПБУ BioAPI.

Рисунок 1 - Базовая архитектура компонентов BioAPI

6.1.3.2 Приложение BioAPI является компонентом программного обеспечения (или набором компонентов программного обеспечения), который использует интерфейс BioAPI, определенный в ИСО/МЭК 19784-1, производя один или несколько вызовов функции BioAPI в процессе его выполнения.

6.1.3.3 Инфраструктура BioAPI является компонентом программного обеспечения (или набором компонентов программного обеспечения), который реализует BioAPI, определенный в ИСО/МЭК 19784-1, и его заданное поведение, производя один или несколько вызовов функции BioSPI, определенной в ИСО/МЭК 19784-1, в процессе его выполнения.

6.1.3.4 ПБУ BioAPI - это компонент программного обеспечения (или набор компонентов программного обеспечения), который реализует BioSPI, определенный в ИСО/МЭК 19784-1, и его заданное поведение.

6.1.3.5 ПБФ BioAPI является компонентом структуры BioAPI, но его интерфейс не определен в ИСО/МЭК 19784-1. Поэтому настоящий стандарт не содержит описание данного компонента.

6.1.3.6 Помимо двух основных указанных выше интерфейсов BioAPI и BioSPI, ИСО/МЭК 19784-1 утверждает два других интерфейса, описанные в 6.1.3.6.1-6.1.3.6.5.

6.1.3.6.1 Инфраструктуры BioAPI обеспечивают вспомогательный интерфейс, который поддерживает получение следующих данных от ПБУ:

a) уведомления о событиях, относящихся к элементам BioAPI;

b) потоковые данные (полутоновые битовые образы), которые посылаются во время действий, выполняемых ПБУ или ПБФ (от имени ПБУ);

c) информация о состоянии графического интерфейса пользователя (ГИП), которая посылается во время действий, выполняемых ПБУ или ПБФ от имени ПБУ.

6.1.3.6.2 Интерфейс, описанный в 6.1.3.6.1 и реализованный с помощью инфраструктур BioAPI, называется "интерфейсом обратного вызова инфраструктуры".

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

a) уведомления о событиях, связанных с элементами BioAPI, происходящих в ПБУ или ПБФ и переданных инфраструктурой приложению;

b) потоковые данные (полутоновые битовые образы), которые посылаются во время действий, выполняемых ПБУ или ПБФ (от имени ПБУ) и переданные инфраструктурой приложению;

c) информация о состоянии ГИП, которая посылается во время действий, выполняемых ПБУ или ПБФ (от имени ПБУ), переданная инфраструктурой приложению.

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

6.1.3.6.4 Интерфейс, описанный в 6.1.3.6.3, дополнительно реализуемый приложениями BioAPI, называется "интерфейсом обратного вызова приложения".

6.1.3.6.5 Кроме указанных выше, инфраструктуры BioAPI содержат функции, которые поддерживают установку и удаление ПБУ и ПБФ. В настоящем стандарте эти функции включены в интерфейс BioAPI.

6.1.3.7 ПБУ BioAPI может реализовывать вспомогательный интерфейс, который поддерживает получение информации от ПБФ, но этот интерфейс не определен в ИСО/МЭК 19784-1. Поэтому настоящий стандарт не содержит описание данного вспомогательного интерфейса.

6.1.3.8 Три типа реализаций интерфейса BioAPI (приложение BioAPI, инфраструктура BioAPI и ПБУ BioAPI), описанные выше в настоящем стандарте, называют стандартными компонентами BioAPI. Интерфейсы BioAPI, BioSPI, обратного вызова приложения и обратного вызова инфраструктуры, указанные выше, называют стандартными интерфейсами BioAPI. Настоящий стандарт предполагает, что каждый из стандартных компонентов BioAPI взаимодействует с другим компонентом только путем вызова функций стандартных интерфейсов BioAPI.

6.1.3.9 В настоящем стандарте установлен метод испытания на соответствие на основе трех стандартных компонентов BioAPI и четырех стандартных интерфейсов BioAPI.

6.1.4 Физические архитектуры

6.1.4.1 ИСО/МЭК 19784-1 не устанавливает способ загрузки каких-либо стандартных компонентов BioAPI в память, не утверждает физических связей между стандартными компонентами BioAPI и устройствами, подключенными к сети, а также не ограничивает количество экземпляров каждого стандартного компонента BioAPI в устройстве. Эти характеристики зависят от особенностей платформы и реализации.

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

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

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

6.1.4.5 Учитывая абстрактность архитектуры BioAPI, описанной в ИСО/МЭК 19784-1, метод испытания на соответствие, установленный в настоящем стандарте, не зависит от особенностей физической реализации архитектуры BioAPI. Метод испытания на соответствие BioAPI относится к стандартным компонентам BioAPI как к обобщенным компонентам, обладающим интерфейсом и набором функций, описанными в ИСО/МЭК 19784-1, без учета особенностей их физической реализации.

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

      6.2 Модели испытаний на соответствие

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

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

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

a) реализация приложения BioAPI;

b) реализация инфраструктуры BioAPI;

c) реализация ПБУ BioAPI.

6.2.4 Каждую модель испытания создают на основе базовой архитектуры BioAPI путем внесения определенных изменений.

6.2.5 Базовая архитектура BioAPI содержит обычное приложение BioAPI, обычную инфраструктуру BioAPI и один или более ПБУ BioAPI. Каждая модель испытания дополняет или заменяет элементы базовой архитектуры в соответствии с приведенным ниже описанием.

6.2.5.1 В модели испытания на соответствие приложения BioAPI особый компонент тестирования (называемый инфраструктурой для тестирования приложений) должен находиться между тестируемым приложением и обычной инфраструктурой BioAPI (см. рисунок 2). Этот компонент должен с одной стороны реализовывать стандартный интерфейс BioAPI, а с другой - интерфейс обратного вызова приложения. В результате он должен представлять собой для тестируемого приложения инфраструктуру, а для инфраструктуры - приложение. Компонент тестирования должен обеспечивать возможность передачи вызовов приложения обычной инфраструктуре, а вызовов инфраструктуры - тестируемому приложению, а также следить за потоком входящих вызовов, анализировать и регистрировать эти вызовы, а также формировать дополнительные вызовы для проведения тестирования.

Рисунок 2 - Модель испытания на соответствие для приложений BioAPI

6.2.5.2 В модели испытания на соответствие инфраструктуры BioAPI особый компонент тестирования (называемый приложением для тестирования инфраструктуры) должен заменять обычное приложение, а другой компонент тестирования (называемый ПБУ для тестирования инфраструктуры) должен заменять обычный ПБУ (см. рисунок 3). Между этими двумя компонентами тестирования должна находиться тестируемая инфраструктура. Приложение для тестирования инфраструктуры должно реализовывать интерфейс обратного вызова приложения, а ПБУ для тестирования инфраструктуры должен реализовывать интерфейс BioAPI. Поэтому тестируемая инфраструктура не может отличить обычно используемое приложение от приложения, предназначенного для проведения испытания, а обычного поставщика биометрической услуги - от ПБУ, используемого для испытания. Кроме того, приложение для тестирования инфраструктуры и ПБУ для тестирования инфраструктуры должны обладать специальным интерфейсом тестирования, который позволяет этим компонентам связываться для проведения испытания.

Рисунок 3 - Модель испытания на соответствие для инфраструктур BioAPI

6.2.5.3 В модели испытаний на соответствие ПБУ BioAPI особый компонент тестирования (называемый приложением для тестирования ПБУ) должен заменять обычное приложение и обычную инфраструктуру (см. рисунок 4). Этот компонент тестирования должен выполнять функции как приложения BioAPI, так и инфраструктуры BioAPI, а также реализовывать интерфейс обратного вызова инфраструктуры. В результате он должен представлять собой для тестируемого ПБУ обычную инфраструктуру. Компонент тестирования должен обеспечивать возможность вызова интерфейса BioSPI тестируемого ПБУ.

Рисунок 4 - Модель испытания на соответствие для ПБУ BioAPI

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

      6.3 Абстрактная испытательная машина

6.3.1 Семантика языка формальных утверждений определена с использованием понятия "абстрактная испытательная машина".

6.3.2 Абстрактная испытательная машина является абстрактной вычислительной машиной, обеспечивающей возможность проведения испытания на соответствие стандартного компонента BioAPI (приложения, инфраструктуры или ПБУ). Абстрактная испытательная машина должна обеспечивать проведение испытания путем обработки формальных утверждений, написанных на языке формальных утверждений, определенном в разделе 7.

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

a) при проведении испытания на соответствие приложений BioAPI (см. 6.2.5.1) абстрактная испытательная машина должна ассоциироваться со структурой для испытания приложения;

b) при проведении испытания на соответствие инфраструктур BioAPI (см. 6.2.5.2) абстрактная испытательная машина должна одновременно ассоциироваться с приложением для испытания инфраструктуры и ПБУ для испытания инфраструктуры;

c) при проведении испытаний на соответствие ПБУ BioAPI (см. 6.2.5.3) абстрактная испытательная машина должна ассоциироваться с приложением для испытания ПБУ.

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

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

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

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

a) вызовов, сформированных к точкам входа ее стандартных интерфейсов BioAPI;

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

6.3.8 Процессы, описанные в 6.3.7, перечисление b), могут опосредованно отслеживаться абстрактной испытательной машиной, поскольку эти процессы могут влиять на:

a) один или несколько последовательных вызовов, которые компонент формирует в адрес других компонентов;

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

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

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

      7 Общие свойства языка утверждений

      7.1 Общие положения

7.1.1 В разделах 7-10 установлены требования к языку, целью которого является выражение утверждений, используемых при проведении испытаний на соответствие BioAPI. Язык утверждений является неотъемлемой частью метода испытаний на соответствие BioAPI.

7.1.2 В других частях комплекса стандартов ИСО/МЭК 24709 приведены наборы утверждений, написанные на языке утверждений. Реализации методов испытания на соответствие BioAPI (комплекты тестов на соответствие биометрическому программному интерфейсу), которые претендуют на соответствие требованиям комплекса стандартов ИСО/МЭК 24709 должны использовать (или обеспечивать возможность выполнения) только утверждения, представленные в комплексе стандартов ИСО/МЭК 24709.

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

7.1.4 Синтаксис языка утверждений основан на языке W3C XML 1.0. Далее в настоящем разделе термины "элемент" и "атрибут" используются в значении "XML элемент" и "XML атрибут" соответственно.

7.1.5 Утверждения представлены в виде элементов <assertion> (см. 8.2). Каждое утверждение имеет ряд свойств, представленных в виде атрибутов и дочерних элементов элемента <assertion>. Среди свойств утверждения выделяют имя (атрибут name), модель испытаний на соответствие (атрибут model) и ссылку на исходный процесс (дочерний элемент <invoke>).

Пример

7.1.6 Утверждения группируют в пакеты. Каждый пакет, представленный в виде элемента <package>, являющегося корневым элементом документа XML, имеет имя (атрибут name) и другие свойства для идентификации. Пакет содержит ноль или более утверждений (элементы <assertion>), за которыми следует ноль или более процессов (элементы <process>). Допустимы пустые пакеты, а также пакеты, которые содержат только утверждения или только процессы, или и утверждения, и процессы (при этом все утверждения находятся перед первым процессом в пакете). Ни элемент <assertion>, ни элемент <process> не могут быть корневыми элементами документа XML.

Пример

7.1.7 Утверждения могут иметь входные параметры (но не могут иметь выходных параметров). Входные параметры представляются элементами <input>. В процессе подготовки к испытанию входным параметрам присваиваются фактические значения. В случае утверждений, содержащих параметры, результаты теста могут зависеть от значений, присвоенных параметрам, поэтому эти значения являются важной частью выполняемого теста.

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

7.1.9 Каждое утверждение содержит ссылку на исходный процесс. Исходный процесс утверждения определяет процессы, которые должны быть выполнены во время обработки утверждения.

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

Пример

      7.2 Переменные

7.2.1 Имена переменных в языке утверждений должны состоять из строк символов, соответствующих требованиям ИСО/МЭК 10646, которые подходят для создания "NCName" в пространствах имен W3C XML.

7.2.2 Переменные, имена которых начинаются с символа НИЖНЕЕ ПОДЧЕРКИВАНИЕ ("_"), называют глобальными переменными. Любые другие переменные называют локальными переменными.

7.2.3 Глобальные переменные должны сохраняться в течение обработки всего утверждения. Они могут быть созданы в любом процессе (см. 8.6.2.3, 8.7.2.3, 8.12.2.5.1, 8.17.2.9), но должны быть связаны со всем утверждением и не должны быть уничтожены до завершения обработки утверждения. Глобальные переменные также могут быть созданы как входные параметры утверждений (см. 8.3.2.4).

7.2.4 Локальные переменные могут быть созданы в любом процессе (см. 8.5.2.5, 8.6.2.3, 8.7.2.3, 8.12.2.5.1, 8.17.2.9), должны быть связаны с соответствующим процессом и должны быть уничтожены по завершении этого процесса.

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

7.2.6 Переменные языка утверждений не имеют типа данных. Значения всех переменных представляют собой строки символов, соответствующие требованиям ИСО/МЭК 10646, неограниченной длины.

7.2.7 Значение должно быть воспринято как целое число в следующих случаях:

a) когда его оценивают с помощью числовой операции (см. 8.23-8.28);

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

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

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

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

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

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

      7.3 Встроенные переменные

7.3.1 Ряд глобальных переменных являются частью языка утверждений. Их имена начинаются с двух следующих друг за другом символов НИЖНЕЕ ПОДЧЕРКИВАНИЕ ("__"). Эти переменные определены в разделе 10.

7.3.2 Абстрактная испытательная машина должна создать все встроенные переменные и присвоить им начальные значения до начала основного процесса утверждения и не должна разрушать встроенные переменные до его завершения. Большинство встроенных переменных имеют неизменные значения, определенные в 10.1. Значения других встроенных переменных могут изменяться в соответствии с 10.2.

Примечание - Имена глобальных переменных, которые начинаются с двух следующих друг за другом символов НИЖНЕЕ ПОДЧЕРКИВАНИЕ ("__"), не могут быть значением атрибута setvar элементов <output> (<выходной параметр>), <return> (<возвращаемое значение>) и <wait_until> (<ожидать_пока>) (см. 8.6.2.3, 8.7.2.3 и 8.17.2.9.1 соответственно) или значением атрибута name элементов <input> (<входной параметр>), <set> (<присвоить значение>), <add> (<добавить>) и <subtract> (<вычесть>) (см. 8.3.2.3, 8.12.2.2, 8.13.2.2 и 8.14.2.2 соответственно). Поэтому явное изменение значения встроенной переменной невозможно.

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

Примечание - Для обеспечения надежности следует обращаться к двум или более взаимосвязанным переменным в пределах условий <only_if> (<только_если>), <wait_until> (<ожидать_пока>) и аналогичных. При необходимости обращения к нескольким встроенным переменным в последовательности элементов (например, присвоить значения двух или более встроенных переменных обычным переменным с помощью элемента <set> (<присвоить значение>)), элементы должны быть включены в процесс со значением атрибута atomic="true".

      7.4 Представление целых чисел

7.4.1 Неотрицательные целые числа должны быть представлены в виде строк, состоящих из одного или более символов, указанных в ИСО/МЭК 10646 в интервале от 0 до 9 (от "0" до "9").

7.4.2 Отрицательные целые числа должны быть представлены в виде соответствующих положительных целых чисел, которым предшествует символ "ДЕФИС-МИНУС" ("-").

7.4.3 Стандартное представление положительного целого числа представляет собой число, которое не имеет "0" в старших разрядах. Стандартное представление целого числа 0 представляет собой число, состоящее из одного символа 0 ("0"). Стандартное представление отрицательного целого числа состоит из символа "ДЕФИС-МИНУС" ("-") и стандартного представления соответствующего положительного целого числа.

      7.5 Представление логических значений

7.5.1 Логическое значение "ИСТИНА" (TRUE) должно быть представлено в виде строки символов, указанных в ИСО/МЭК 10646, "true" ("ИСТИНА"). Логическое значение "ЛОЖЬ" (FALSE) должно быть представлено в виде строки символов, указанных в ИСО/МЭК 10646, "false" ("ЛОЖЬ").

7.5.2 Данное представление является стандартным.

      7.6 Представление универсальных уникальных идентификаторов

7.6.1 УУИД должен быть представлен в виде строк символов, указанных в ИСО/МЭК 10646. Каждая строка должна состоять из символов, входящих в объединение следующих множеств:

a) цифры от "0" до "9", каждая из которых представляет собой шестнадцатеричную цифру от 0 до 9;

b) от прописной латинской буквы "А" до прописной латинской буквы "F", каждая из которых представляет собой шестнадцатеричную цифру от А до F;

c) от строчной латинской буквы "а" до строчной латинской буквы "f", каждая из которых представляет собой шестнадцатеричную цифру от А до F;

d) знак "ДЕФИС-МИНУС" ("-").

7.6.2 В состав УУИД должно входить ровно 32 шестнадцатеричные цифры. Также в состав УУИД должно входить четыре символа "ДЕФИС-МИНУС" ("-") в следующих позициях:

a) между восьмой и девятой шестнадцатеричной цифрами;

b) между двенадцатой и тринадцатой шестнадцатеричными цифрами;

c) между шестнадцатой и семнадцатой шестнадцатеричными цифрами;

d) между двадцатой и двадцать первой шестнадцатеричной цифрами.

7.6.3 Стандартным представлением УУИД является такое его представление, в котором не используются символы, отнесенные к категории, указанной в 7.6.1, перечисление b).

      7.7 Представление набора байтов

7.7.1 Набор байтов должен быть представлен в виде строк символов, указанных в ИСО/МЭК 10646. Каждая строка должна содержать четное количество (возможно, ноль) символов из объединения следующих множеств:

a) от цифры "0" до цифры "9", каждая из которых представляет собой шестнадцатеричную цифру от 0 до 9;

b) от прописной латинской буквы "А" до прописной латинской буквы "F", каждая из которых представляет собой шестнадцатеричную цифру от А до F;

c) от строчной латинской буквы "а" до строчной латинской буквы "f", каждая из которых представляет собой шестнадцатеричную цифру от А до F.

7.7.2 Стандартным представлением набора байтов является такое его представление, в котором не используются символы, отнесенные к категории, указанной в 7.7.1, перечисление b).

      7.8 XML-документы

7.8.1 Утверждения и процессы должны быть приведены в документах формата W3C XML 1.0. Должен использоваться расширяемый язык разметки (The Extensible Markup Language, XML) версии "1.0". Для кодировки символов должна использоваться кодировка "utf-8" или "utf-16".

7.8.2 Корневым элементом всех документов формата XML должен быть элемент <package> (см. 8.1).

7.8.3 Документы XML должны соответствовать схеме документов XML, приведенной в приложении А, а также абстрактному синтаксису нотаций (Abstract Syntax Notation, ASN) ASN.1, приведенному в приложении В.

Примечание - Для проверки формальной корректности утверждений реализация может использовать любую из схем XML или ASN.1 в силу их эквивалентности.

      8 Элементы языка утверждений

      8.1 Элемент <package>

8.1.1 Синтаксис

8.1.1.1 Данный элемент должен иметь следующий атрибут:

- name (обязательный атрибут) - значением этого атрибута должно быть корректное имя пакета (см. 8.1.2.5).

8.1.1.2 В состав элемента в указанном порядке должны входить:

а) один элемент <author> - этот элемент должен содержать имя или описание автора пакета (строка символов);

b) один элемент <description> - этот элемент должен содержать описание пакета (строка символов);

c) ноль или более элементов <assertion> - этот элемент представляет собой утверждение и определен в 8.2;

d) ноль или более элементов <activity> - этот элемент представляет собой процесс и определен в 8.9.

8.1.2 Семантика

8.1.2.1 Пакет является контейнером для утверждений и процессов, имеющим имя.

8.1.2.2 К утверждениям и процессам возможно обращение из внешней по отношению к пакету среды.

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

8.1.2.4 Обращение к процессам осуществляется, как правило, из утверждений (в элементах <invoke> или <bind>) или других процессов. В обоих случаях обращение к процессу возможно как из пакета, содержащего данный процесс, так и из внешнего по отношению к данному процессу пакета.

8.1.2.5 Имена пакетов должны состоять из строк символов, указанных в ИСО/МЭК 10646, представляющих собой универсальный уникальный идентификатор (см. 7.6). Каждое имя пакета должно быть уникальным.

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

8.1.2.7 Каждое утверждение, входящее в пакет, должно иметь уникальное имя. Каждый процесс, входящий в пакет, должен иметь уникальное имя.

Примечание - Утверждение и процесс в пределах одного пакета могут иметь одно и то же имя.

8.1.3 Пример

      8.2 Элемент <assertion> (дочерний для элемента <package>)

8.2.1 Синтаксис

8.2.1.1 Данный элемент должен иметь следующие атрибуты:

a) name (обязательный атрибут) - значением этого атрибута должно быть корректное имя утверждения (см. 8.2.2.7).

b) model (обязательный атрибут) - этот атрибут должен принимать одно из следующих значений: "applicationTesting", "frameworkTesting", "BSPTesting"; это значение должно определять модель испытаний на соответствие, используемую утверждением.

8.2.1.2 В состав элемента в указанном порядке должны входить:

a) один элемент <description> - этот элемент должен содержать описание утверждения (строка символов);

b) ноль или более элементов <input> - этот элемент является входным параметром утверждения и определен в 8.3;

c) один элемент <invoke> - этот элемент представляет собой вызов основного процесса утверждения и определен в 8.4;

d) ноль или более элементов <bind> - этот элемент представляет собой связь между функцией стандартного интерфейса BioAPI и процессом и определен в 8.8.

8.2.2 Семантика

8.2.2.1 Атрибут model определяет выбор модели испытаний на соответствие (см. 6.2), используемой для обработки утверждения, и, таким образом, определяет какой(ие) компонент(ы) этой модели должен(ны) ассоциироваться с абстрактной испытательной машиной.

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

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

8.2.2.4 Если атрибут model имеет значение "applicationTesting", то для этого утверждения должна быть выбрана модель испытаний приложения BioAPI (см. 6.2.5.1), а абстрактная испытательная машина должна рассматриваться как инфраструктура, тестирующая приложение.

8.2.2.5 Если атрибут model имеет значение "frameworkTesting", то для этого утверждения должна быть выбрана модель испытаний инфраструктуры BioAPI (см. 6.2.5.2), а абстрактная испытательная машина должна рассматриваться как приложение, тестирующее инфраструктуру, и, одновременно, как ПБУ, тестирующий инфраструктуру.

8.2.2.6 Если атрибут model имеет значение "BSPTesting", то для этого утверждения должна быть выбрана модель испытаний ПБУ BioAPI (см. 6.2.5.1), а абстрактная испытательная машина должна рассматриваться как приложение, тестирующее ПБУ.

8.2.2.7 Имена утверждений должны состоять из строк символов, указанных в ИСО/МЭК 10646, которые подходят для создания имен "NCName" в пространствах имен W3C XML.

8.2.2.8 Имена утверждений в пакете должны быть уникальными.

8.2.3 Пример

      8.3 Элемент <input> (дочерний для элемента <assertion>)

8.3.1 Синтаксис

8.3.1.1 Данный элемент должен иметь следующий атрибут:

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

8.3.1.2 Данный элемент не должен иметь текстового содержимого.

8.3.2 Семантика

8.3.2.1 Данный элемент является входным параметром утверждения.

Примечание - Утверждения не должны содержать выходных параметров.

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

8.3.2.3 Значением атрибута name должно быть корректное имя глобальной переменной (см. 7.2) и не должно начинаться с двух следующих друг за другом символов "НИЖНЕЕ ПОДЧЕРКИВАНИЕ" ("__").

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

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

8.3.2.6 Именами входных параметров утверждения должны быть корректные имена глобальных переменных (см. 7.2). Имена всех глобальных переменных (включая входные параметры) должны быть уникальными.

Примечание - Значения, присвоенные параметрам утверждения, не могут быть изменены в процессе обработки утверждения, потому что все элементы языка утверждений, осуществляющие присваивание или изменение значения глобальной переменной (см. 8.6.2.3, 8.7.2.3, 8.12.2.2, 8.13.2.2, 8.14.2.2 и 8.17.9.1) не позволяют использовать параметр утверждения как переменную, значение которой можно изменять.

8.3.3 Пример

      8.4 Элемент <invoke> (дочерний для элемента <assertion>)

8.4.1 Синтаксис

8.4.1.1 Данный элемент должен иметь следующие атрибуты:

a) activity (обязательный атрибут) - значением этого атрибута должно быть имя процесса;

b) package (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть имя пакета, который содержит процесс, определенный атрибутом activity.

8.4.1.2 В состав элемента в указанном порядке должны входить:

- ноль или более элементов <input> - этот элемент предоставляет значение для входного параметра процесса и определен в 8.5.

8.4.2 Семантика

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

8.4.2.2 Процесс может содержать элементы <assert_condition> с атрибутом break_if_false (см. 8.18.2.3). Если в ходе выполнения процесса произошло прерывание, обработка всего утверждения должна быть завершена.

8.4.2.3 Набор элементов <input> вызова должен соответствовать входным параметрам процесса согласно 8.5.2.2.

8.4.2.4 Атрибут package является обязательным, если процесс находится не в том пакете, в котором находится утверждение; в противном случае атрибут package является необязательным.

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

Примечание - Это аналогично вызову процесса с выходными параметрами другим процессом без предоставления каких-либо элементов <output>, соответствующих выходным параметрам вызываемого процесса. Такой способ вызова допускается и используется тогда, когда вызывающему процессу не нужна информация о значениях выходных параметров вызываемого процесса.

8.4.2.6 У элемента утверждений <invoke> не должно быть атрибута break_on_break (см. 8.15.2.6.5) и дочернего объекта <only_if>.

8.4.3 Пример

      8.5 Элемент <input> (дочерний для элемента <invoke>)

8.5.1 Синтаксис

8.5.1.1 Данный элемент должен иметь следующие атрибуты:

a) name (обязательный атрибут) - значением этого атрибута должно быть имя входного параметра вызываемого процесса или вызываемой функции стандартного интерфейса BioAPI;

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

c) var (необязательный параметр) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2), значение которой присваивается входному параметру с атрибутом name.

8.5.1.2 Должен присутствовать только один из двух необязательных атрибутов - value или var.

8.5.1.3 Данный элемент не должен иметь текстового содержимого.

8.5.2 Семантика

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

8.5.2.2 Набор элементов <input> вызова должен соответствовать входным параметрам процесса или вызываемой функции стандартного интерфейса BioAPI в соответствии с 8.5.2.2.1 и 8.5.2.2.2.

8.5.2.2.1 При вызове процесса для каждого элемента <input> вызывающего процесса должно быть не более одного элемента <input> вызова, значение атрибута name которого равно значению атрибута name элемента <input> вызывающего процесса, и наоборот. Для каждого элемента <input> вызова процесса должен быть элемент <input> вызываемого процесса, значение атрибута name которого равно значению атрибута name вызова. Порядок элементов <input> в процессе и в вызове процесса могут не совпадать.

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

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

8.5.2.3 Если атрибут var присутствует, то его значением должно быть имя предварительно объявленной переменной (см. 7.2). Значение переменной должно быть присвоено входному параметру. Переменная может быть глобальной или локальной.

8.5.2.4 Если атрибут value присутствует, то его значение должно быть присвоено входному параметру.

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

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

8.5.3 Пример

      8.6 Элемент <output> (дочерний для элемента <invoke>)

8.6.1 Синтаксис

8.6.1.1 Данный элемент должен иметь следующие атрибуты:

a) name (обязательный атрибут) - значением этого атрибута должно быть имя выходного параметра процесса или вызываемой функции стандартного интерфейса BioAPI;

b) setvar (обязательный атрибут) - значением этого атрибута должно быть корректное имя переменной (см. 7.2), которой должно быть присвоено значение выходного параметра.

8.6.1.2 Данный элемент не должен иметь текстового содержимого.

8.6.2 Семантика

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

8.6.2.2 Набор элементов <output> вызова должен соответствовать выходным параметрам вызываемого процесса или функции стандартного интерфейса BioAPI в соответствии с 8.6.2.2.1 и 8.6.2.2.2.

8.6.2.2.1 При вызове процесса для каждого элемента <output> вызывающего процесса должно быть не более одного элемента <output> вызова, значение атрибута name которого равно значению атрибута name элемента <output> вызывающего процесса, и наоборот. Для каждого элемента <output> в вызове должен быть элемент <output> вызываемого процесса, значение атрибута name которого равно значению атрибута name элемента <output> в вызове. Порядок элементов <output> в процессе и в вызове процесса могут не совпадать.

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

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

8.6.2.3 Значением атрибута setvar должно быть корректное имя глобальной или локальной переменной (см. 7.2). Значение атрибута setvar не должно быть входным параметром обрабатываемого утверждения (см. 8.3) и не должно начинаться со следующих друг за другом символов "НИЖНЕЕ ПОДЧЕРКИВАНИЕ" ("__"). Переменная может существовать до вызова процесса или функции или может быть новой переменной, которую необходимо создать после завершения вызванного процесса или функции.

8.6.2.4 Все значения атрибутов setvar элементов <output> в вызове должны быть определены.

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

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

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

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

      8.7 Элемент <return> (дочерний для элемента <invoke>)

8.7.1 Синтаксис

8.7.1.1 Данный элемент должен иметь следующие атрибуты:

- setvar (обязательный атрибут) - значением этого атрибута должно быть корректное имя переменной (см. 7.2), которой присваивается возвращаемое значение.

8.7.1.2 Данный элемент не должен иметь текстового содержимого.

8.7.2 Семантика

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

8.7.2.2 В вызове функции стандартного интерфейса BioAPI должно быть не более одного элемента <return>.

8.7.2.3 Значением атрибута setvar должно быть корректное имя глобальной или локальной переменной (см. 7.2). Значение атрибута setvar не должно быть входным параметром обрабатываемого утверждения (см. 8.3) и не должно начинаться с двух следующих друг за другом символов "НИЖНЕЕ ПОДЧЕРКИВАНИЕ" ("_"). Переменная может существовать до вызова функции или может быть новой переменной, которую необходимо создать после завершения вызываемого процесса или функции.

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

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

      8.8 Элемент <bind> (дочерний для элемента <assertion>)

8.8.1 Синтаксис

8.8.1.1 Данный элемент должен иметь следующие атрибуты:

a) function (обязательный атрибут) - значением этого атрибута должно быть имя функции стандартного интерфейса BioAPI (см. раздел 9);

b) activity (обязательный атрибут) - значением этого атрибута должно быть имя процесса;

c) package (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть имя пакета, в котором содержится процесс, определенный атрибутом activity.

8.8.1.2 Данный элемент не должен иметь текстового содержимого.

8.8.2 Семантика

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

8.8.2.2 Указанная связь должна присутствовать в течение всей обработки утверждения.

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

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

8.8.2.4 Нельзя обращаться к одной и той же функции стандартного интерфейса BioAPI в двух разных элементах <bind> одного и того же утверждения.

8.8.2.5 Связанный процесс должен иметь входные и выходные параметры, полученные из входных и выходных параметров схемы вызова функции (определенной в разделе 9) стандартного интерфейса BioAPI, с которой связан данный процесс:

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

b) в модели испытания на соответствие инфраструктуры BioAPI и ПБУ BioAPI все входные параметры вызова функции должны быть выходными параметрами связанного процесса, а все выходные параметры вызова функции должны быть входными параметрами связанного процесса; кроме того, должен присутствовать выходной параметр с именем return.

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

      8.9 Элемент <activity> (дочерний для элемента <package>)

8.9.1 Синтаксис

8.9.1.1 Данный элемент должен иметь следующие атрибуты:

a) name (обязательный атрибут) - значением этого атрибута должно быть корректное имя процесса (см. 8.9.2.22);

b) atomic (необязательный атрибут) - этот атрибут должен определять непрерывность выполнения процесса (по умолчанию атрибут atomic имеет значение "ложно").

8.9.1.2 В состав элемента в указанном порядке должны входить:

а) ноль или более элементов <input> - этот элемент представляет собой входной параметр процесса и определен в 8.10;

b) ноль или более элементов <output> - этот элемент представляет собой выходной параметр процесса и определен в 8.11;

c) ноль или более каких-либо из представленных ниже элементов в любом порядке:

1) <set> - этот элемент представляет собой присвоение значения новой переменной или существующей переменной и определен в 8.12;

2) <add> - этот элемент представляет собой прибавление целого числа к значению существующей переменной (являющейся целым числом) и определен в 8.13;

3) <subtract> - этот элемент представляет собой вычитание целого числа из значения существующей переменной (являющейся целым числом) и определен в 8.14;

4) <wait_until> - этот элемент представляет собой временное прекращение выполнения текущего процесса до тех пор, пока условие не подтверждено, и определен в 8.17;

5) <assert_condition> - этот элемент представляет собой выходной результат испытания на соответствие, основанного на заданном условии, и определен в 8.18;

6) <invoke> - этот элемент представляет собой вызов процесса или функции стандартного интерфейса BioAPI и определен в подразделе 8.15.

8.9.2 Семантика

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

a) присвоение значения переменной;

b) временное прекращение выполнения текущего процесса до тех пор, пока условие не подтверждено;

c) вызов функции стандартного интерфейса BioAPI;

d) выдача результата проверки соответствия при заданном условии;

e) вызов процесса.

8.9.2.2 Абстрактная испытательная машина должна выполнять действия процесса в установленном порядке.

8.9.2.3 Каждый процесс должен иметь приоритет, который может быть низким, средним или высоким. Во время обработки утверждения может выполняться не более одного процесса. Абстрактная испытательная машина должна обеспечивать возможность прерывания процесса с целью выполнения процесса с более высоким приоритетом (см. 8.9.2.21).

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

8.9.2.5 Если один процесс вызывает другой процесс, то вызываемому процессу должен быть присвоен приоритет вызывающего процесса.

8.9.2.6 Когда один из следующих элементов

a) элемент <wait_until> или

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

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

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

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

8.9.2.7.3 Если возврат из переданного вызова осуществляется до возврата первоначального входящего вызова и существует процесс, связанный с вызываемой функцией стандартного интерфейса BioAPI (см. 8.8), абстрактная испытательная машина должна прервать текущий процесс с низким приоритетом и вызвать процесс, связанный с вызываемой функцией стандартного интерфейса BioAPI, с присвоением данному процессу высокого приоритета (с учетом требований, приведенных в 8.9.2.9).

8.9.2.7.4 Входным параметрам вызова связанного процесса должны быть присвоены значения собственных входных параметров входящего вызова и собственных выходных параметров переданного вызова, а также возвращаемое значение переданного вызова сразу же после его завершения в соответствии с пунктами раздела 9 с заголовком "Входные параметры вызова связанного процесса", относящимися к функции стандартного интерфейса BioAPI.

8.9.2.8 В модели испытаний на соответствие инфраструктуры BioAPI (см. 6.2.5.2) и ПБУ BioAPI (см. 6.2.5.3) при получении компонентом тестирования входящего вызова должны быть выполнены действия, описанные в 8.9.2.8.1-8.9.2.8.4.

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

a) если это функция BioSPI_Cancel, должен быть выбран высокий приоритет;

b) если функция принадлежит интерфейсу BioSPI, но не является функцией BioSPI_Cancel, должен быть выбран средний приоритет;

c) в остальных случаях должен быть выбран высокий приоритет.

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

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

8.9.2.8.4 Если вызываемая функция не имеет связанных процессов, то абстрактная тестовая машина должна установить значения собственных выходных параметров и возвращаемое значение входящего вызова в соответствии с пунктами раздела 9 с заголовком "Возвращаемое значение по умолчанию".

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

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

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

8.9.2.12 После создания контекста выполнения необходимо создать входные параметры процесса (как локальные переменные) и присвоить им следующие значения:

a) предоставленное значение, если вызов процесса содержит элемент <input> для соответствующего выходного параметра (см. 8.5.2.5);

b) в противном случае - пустую строку.

8.9.2.13 После этого элементы процесса должны быть обработаны по порядку с первого до последнего до возникновения прерывания (см. 8.9.2.17).

8.9.2.14 Если прерывание не происходит, то после обработки последнего элемента каждый выходной параметр должен быть подвергнут одному из следующих действий:

a) переменной, к которой обращаются в элементе <output>, должно быть присвоено конечное значение выходного параметра, если вызов процесса содержит элемент <output> для соответствующего выходного параметра в соответствии с 8.6.2.3;

b) в противном случае конечное значение выходного параметра должно быть удалено.

8.9.2.15 После этого контекст выполнения данного вызова процесса должен быть удален.

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

8.9.2.17 Прерывание выполнения процесса происходит в следующих случаях:

a) если процесс содержит элемент <assert_condition> с атрибутом break_if_false, имеющим значение "true", а результат оценки условия в элементе <assert_condition> имеет значение "false" и

b) если процесс содержит элемент <invoke> с атрибутом break_on_break, имеющим значение "true", когда вызываемый процесс завершается из-за прерывания, прерывание происходит и в вызывающем процессе (см. 8.9.2.18).

8.9.2.18 Если в процессе происходит прерывание (по одной из причин, указанных в 8.9.2.17, перечисления а), b)) то абстрактная испытательная машина должна:

a) пропустить обработку оставшихся элементов процесса;

b) пропустить присвоение значений выходных параметров переменным, к которым обращаются в соответствующих элементах <output> при вызове процесса (в случае их наличия);

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

Примечания

1 В 8.9.2.18, перечисление b) подразумевается, что если переменная, соответствующая выходному параметру, не существовала до вызова, то при возобновлении вызывающего процесса она не создается.

2 Если положение 8.9.2.17, перечисление b) относится к вызывающему процессу, то выполнение вызывающего процесса будет прекращено сразу же после его возобновления

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

8.9.2.20 Процесс не может быть прерван другим процессом с тем же или более низким приоритетом (см. 8.9.2.9).

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

a) не может произойти прерывание обработки элементов <set>, <add>, <subtract> или <assert_condition>;

b) в процессе обработки элемента <invoke> функции стандартного интерфейса BioAPI прерывание не может произойти во время оценки условий (в случае их наличия), во время присвоения значения входным параметрам и во время передачи выходных параметров и возвращаемого значения.

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

c) в процессе обработки элемента <wait_until> прерывание не может произойти в момент оценки условия.

Примечание - Прерывания могут происходить в промежутке между двумя следующими друг за другом оценками условия;

d) процесс с атрибутом atomic, имеющим значение "true", прерывать не допускается (с момента создания входных параметров и до момента удаления выходных параметров).

8.9.2.22 Имена процессов должны состоять из строк символов, указанных в ИСО/МЭК 10646, которые подходят для создания имени "NCName" (неквалифицированного имени) в пространствах имен W3C XML.

8.9.2.23 Имена процессов в пакете должны быть уникальными.

8.9.3 Примеры

      8.10 Элемент <input> (дочерний для элемента <activity>)

8.10.1 Синтаксис

8.10.1.1 Данный элемент должен иметь следующий атрибут

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

8.10.1.2 Данный элемент не должен иметь текстового содержимого.

8.10.2 Семантика

8.10.2.1 Этот элемент представляет собой входной параметр процесса.

8.10.2.2 Входные параметры процессов являются локальными переменными (см. 7.2).

8.10.2.3 Именами входных параметров процесса должны быть корректные имена локальных переменных (см. 7.2).

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

      8.11 Элемент <output> (дочерний для элемента <activity>)

8.11.1 Синтаксис

8.11.1.1 Данный элемент должен иметь следующий атрибут:

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

8.11.1.2 Данный элемент не должен иметь текстового содержимого.

8.11.2 Семантика

8.11.2.1 Данный элемент представляет собой входной параметр процесса.

8.11.2.2 Выходные параметры процессов являются локальными переменными (см. 7.2).

8.11.2.3 Имена выходных параметров процессов должны быть корректными именами локальных переменных (см. 7.2).

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

      8.12 Элемент <set>

8.12.1 Синтаксис

8.12.1.1 Данный элемент должен иметь следующие атрибуты:

a) name (обязательный атрибут) - значением этого атрибута должно быть корректное имя переменной (см. 7.2), которой должно быть присвоено значение или которая подлежит созданию с последующим присвоением значения;

b) value (необязательный атрибут) - если этот атрибут присутствует, то он должен содержать значение, которое должно быть присвоено переменной с именем, определяемым обязательным атрибутом name;

c) var (необязательный атрибут) - если этот атрибут присутствует, то значением атрибута должно быть корректное имя переменной (см. 7.2), значение которой должно быть присвоено переменной с именем, определяемым обязательным атрибутом name;

8.12.1.2 Должен присутствовать только один из атрибутов value или var.

8.12.1.3 В состав данного элемента может также входить:

- необязательный элемент <only_if>, представляющий собой условие и определенный в 8.16.

8.12.2 Семантика

8.12.2.1 Этот элемент представляет собой присвоение значения переменной с возможной проверкой условия.

8.12.2.2 Значением атрибута name должно быть корректное имя глобальной или локальной переменной (см. 7.2). Значение атрибута name не должно быть входным параметром обрабатываемого утверждения (см. 8.3) и не должно начинаться с двух следующих друг за другом символов "НИЖНЕЕ ПОДЧЕРКИВАНИЕ" ("_"). Переменная может существовать до присвоения значения, а может быть новой переменной, созданной в процессе присвоения значения.

8.12.2.3 Если присутствует дочерний элемент <only_if>, необходимо провести проверку условия (см. 8.16).

8.12.2.4 Результатом проверки должно быть корректное логическое значение (см. 7.5).

8.12.2.5 Если результат проверки имеет значение "true", то присвоение значения переменной, имя которой определено значением атрибута name, осуществляется следующим образом.

8.12.2.5.1 Если переменной не существует, ее необходимо создать.

8.12.2.5.2 Если присутствует атрибут var, то его значением должно быть имя существующей переменной. Значение этой переменной должно быть присвоено переменной, имя которой определяется значением атрибута name.

8.12.2.5.3 Если присутствует атрибут value, то его значение должно быть присвоено переменной, имя которой определяется значением атрибута name.

      8.13 Элемент <add>

8.13.1 Синтаксис

8.13.1.1 Данный элемент должен иметь следующие атрибуты:

a) name (обязательный атрибут) - значением этого атрибута должно быть корректное имя переменной (см. 7.2), значение которой должно быть изменено;

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

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

8.13.1.2 Должен присутствовать только один из атрибутов - value или var.

8.13.1.3 В состав данного элемента может также входить:

- дополнительный элемент <only_if>, представляющий собой условие и определенный в 8.16.

8.13.2 Семантика

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

8.13.2.2 Значением атрибута name должно быть корректное имя глобальной или локальной переменной (см. 7.2). Значение атрибута name не должно быть входным параметром обрабатываемого утверждения (см. 8.3) и не должно начинаться с двух следующих друг за другом символов "НИЖНЕЕ ПОДЧЕРКИВАНИЕ" ("__"). Переменная, имя которой определяется значением атрибута name, должна существовать до присвоения значения, а ее значением должно быть корректное представлением целого числа (см. 7.4).

8.13.2.3 Если присутствует дочерний элемент <only_if>, необходимо провести проверку условия (см. 8.16).

8.13.2.4 Результатом проверки условия должно быть корректное логическое значение (см. 7.5).

8.13.2.5 Если результатом проверки условия является значение "true", то переменной, имя которой определяется значением атрибута name, присваивается новое значение следующим образом.

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

8.13.2.5.2 Если присутствует атрибут var, то его значением должно быть имя существующей переменной. Значением этой переменной должно быть корректное представление целого числа (см. 7.4), которое является вторым операндом.

8.13.2.5.3 Если присутствует атрибут value, то его значением должно быть корректное представление целого числа (см. 7.4), которое является вторым операндом.

      8.14 Элемент <subtract>

8.14.1 Синтаксис

8.14.1.1 Данный элемент должен иметь следующие атрибуты:

a) name (обязательный атрибут) - значением этого атрибута должно быть корректное имя переменной (см. 7.2), значение которой должно быть изменено;

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

c) var (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2), значение которой представляет собой целое число, которое необходимо вычесть из текущего значения переменной, определяемой значением обязательного атрибута name.

8.14.1.2 Должен присутствовать только один из атрибутов - value или var.

8.14.1.3 В состав элемента может также входить:

- дополнительный элемент <only_if>, представляющий собой условие и определенный в 8.16.

8.14.2 Семантика

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

8.14.2.2 Значением атрибута name должно быть корректное имя глобальной или локальной переменной (см. 7.2). Значение атрибута name не должно быть входным параметром обрабатываемого утверждения (см. 8.3) и не должно начинаться с двух следующих друг за другом символов "НИЖНЕЕ ПОДЧЕРКИВАНИЕ" ("_"). Переменная, имя которой определяется значением атрибута name, должна существовать до присвоения значения, а ее значением должно быть корректное представление целого числа (см. 7.4).

8.14.2.3 Если присутствует дочерний элемент <only_if>, необходимо провести проверку условия (см. 8.16).

8.14.2.4 Результатом проверки должно быть корректное представление логического значения (см. 7.5).

8.14.2.5 Если результатом проверки условия является значение "true", то переменной, имя которой определяется значением атрибута name, присваивается новое значение следующим образом.

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

8.14.2.5.2 Если присутствует атрибут var, то его значением должно быть имя существующей переменной. Значением этой переменной должно быть корректное представление целого числа (см. 7.4), которое является вторым операндом.

8.14.2.5.3 Если присутствует атрибут value, то его значением должно быть корректное представлением целого числа (см. 7.4), которое является вторым операндом.

      8.15 Элемент <invoke> (дочерний для элемента <activity>)

8.15.1 Синтаксис

8.15.1.1 Данный элемент должен иметь следующие атрибуты:

a) activity (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть имя процесса;

b) package (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть имя пакета, который содержит процесс, определенный значением атрибута activity;

c) break_on_break (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть одно из логических выражений "true" или "false"; этот атрибут определяет, приводит ли прерывание в вызванном процессе к прекращению выполнения текущего (вызывающего) процесса; по умолчанию атрибут break_on_break имеет значение "false";

d) function (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть имя функции стандартного интерфейса BioAPI;

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

f) timeout_var (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2), значение которой определяет максимальную допустимую продолжительность (в миллисекундах) вызова;

g) setvar (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2).

8.15.1.2 Должен присутствовать только один из атрибутов activity или function.

8.15.1.3 Атрибуты package и break_on_break могут присутствовать только в том случае, если присутствует атрибут activity.

8.15.1.4 Атрибуты timeout_var, timeout_value и setvar могут присутствовать только в том случае, если присутствует атрибут function.

8.15.1.5 Должен присутствовать только один из атрибутов timeout_var или timeout_value.

8.15.1.6 Атрибут setvar может присутствовать только в том случае, если присутствует атрибут timeout_var или атрибут timeout_value.

8.15.1.7 В состав данного элемента в указанном порядке должны входить:

a) необязательный элемент <only_if>, представляющий собой условие и определенный в 8.16;

b) ноль или более элементов <input> - этот элемент представляет собой значение входного параметра процесса или вызываемой функции стандартного интерфейса BioAPI и определен в 8.5;

c) ноль или более элементов <output> - этот элемент указывает на переменную, которой должно быть присвоено значение выходного параметра процесса или вызываемой функции, и определен в 8.6;

d) необязательный элемент <return> - этот элемент указывает на переменную, которой должно быть присвоено возвращаемое значение вызываемой функции, и определен в 8.7.

8.15.2 Семантика

8.15.2.1 Этот элемент представляет собой вызов процессом другого процесса или функции стандартного интерфейса BioAPI.

8.15.2.2 Если присутствует дочерний элемент <only_if>, необходимо провести проверку условия (см. 8.16).

8.15.2.3 Результатом проверки условия должно быть корректное представление логическое значения (см. 7.5).

8.15.2.4 Если результат проверки условия имеет значение "true", то должен быть осуществлен вызов процесса или функции стандартного интерфейса BioAPI в соответствии с изложенным ниже, в противном случае дальнейшую обработку элемента <invoke> прекращают.

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

8.15.2.6 При вызове процесса должны быть соблюдены пять условий, описанных в 8.15.2.6.1-8.15.2.6.5.

8.15.2.6.1 Набор элементов <input> вызова должен соответствовать входным параметрам процесса в соответствии с 8.5.2.2.

8.15.2.6.2 Набор элементов <output> вызова должен соответствовать выходным параметрам процесса в соответствии с 8.6.2.2.

8.15.2.6.3 Элемент <return> должен отсутствовать.

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

8.15.2.6.5 Если атрибут break_on_break присутствует и имеет значение "true", а вызываемый процесс завершается из-за возникновения прерывания (см. 8.9.2.17), то и текущий (вызывающий) процесс должен быть завершен.

8.15.2.7 При вызове функции должны быть соблюдены три условия, описанные в 8.15.2.7.1-8.15.2.7.3.

8.15.2.7.1 Набор элементов <input> вызова должен соответствовать входным параметрам функции в соответствии с 8.5.2.2.

8.15.2.7.2 Набор элементов <output> вызова должен соответствовать выходным параметрам функции в соответствии с 8.6.2.2.

8.15.2.7.3 Допускается присутствие элемента <return> (см. 8.7.2.2)

8.15.2.8 Если присутствует атрибут timeout_value, то его значение должно быть корректным представлением целого числа (см. 7.4), которое определяет максимальную допустимую продолжительность вызова (в миллисекундах). Если присутствует атрибут timeout_var, то его значение должно быть именем существующей переменной, а значение этой переменной должно быть корректным представлением целого числа (см. 7.4), которое определяет максимальную допустимую продолжительность вызова. В противном случае максимальную допустимую продолжительность вызова не устанавливают.

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

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

8.15.2.10 Если присутствует атрибут setvar, то должны быть соблюдены четыре условия, описанные в 8.15.2.10.1-8.15.2.10.4.

8.15.2.10.1 Значение атрибута setvar должно быть корректным именем глобальной или локальной переменной (см. 7.2). Значение атрибута setvar не должно быть входным параметром обрабатываемого утверждения (см. 8.3) и не должно начинаться с двух следующих друг за другом символов "НИЖНЕЕ ПОДЧЕРКИВАНИЕ" ("_"). Переменная, имя которой определяется значением атрибута setvar, может существовать до присвоения ей значения или может быть новой переменной, созданной во время присвоения.

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

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

8.15.2.10.4 Переменная не должна создаваться (если она не существует до вызова функции) и ей не должно присваиваться значение, кроме случаев, описанных в 8.15.2.10.2 и 8.15.2.10.3.

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

8.15.2.12 До начала выполнения вызванных процесса или функции всем входным параметрам, для которых в вызове (при их наличии) был представлен элемент <input>, должны быть присвоены значения переменных или параметров, представленных в элементах <input> в соответствии с 8.5.2.5. Остальным входным параметрам в качестве значения должна быть присвоена пустая строка символов.

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

8.15.2.13.1 Значение каждого выходного параметра, для которого в вызове (в случае их наличия) предоставлен элемент <output>, должно быть присвоено переменной, указанной в элементе <output> в соответствии с 8.6.2.3.

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

8.15.2.14 Если превышена максимальная допустимая продолжительность вызова функции, необходимо выполнить два действия, описанные в 8.15.2.14.1 и 8.15.2.14.2.

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

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

8.15.2.15 Выполнение вызывающего процесса (при его наличии) должно быть продолжено (с учетом положений 8.9.2.17).

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

8.15.3 Примеры

      8.16 Элемент <only_if>

8.16.1 Синтаксис

8.16.1.1 Данный элемент должен иметь следующий атрибут:

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

8.16.1.2 Данный элемент должен включать в себя:

a) необязательный элемент <description>, который (при наличии) должен содержать описание условия (срока символов);

b) ноль или более появлений любого из следующих элементов в произвольном порядке:

1) <and> - этот элемент представляет собой логический оператор AND ("И") и определен в 8.19;

2) <or> - этот элемент представляет собой логический оператор OR ("ИЛИ") и определен в 8.20;

3) <xor> - этот элемент представляет собой логический оператор XOR ("исключающее ИЛИ") и определен в 8.21;

4) <not> - этот элемент представляет собой логический оператор NOT ("НЕ") и определен в 8.22;

5) <equal_to> - этот элемент представляет собой числовой оператор "equal to" ("равно") и определен в 8.23;

6) <not_equal_to> - этот элемент представляет собой числовой оператор "not equal to" ("не равно") и определен в 8.24;

7) <greater_than> - этот элемент представляет собой числовой оператор "greater than" ("больше") и определен в 8.25;

8) <greater_than_or_equal_to> - этот элемент представляет собой числовой оператор "greater than or equal to" ("больше или равно") и определен в 8.26;

9) <less_than> - этот элемент представляет собой числовой оператор "less than" ("меньше") и определен в 8.27;

10) <less_than_or_equal_to> - этот элемент представляет собой числовой оператор "less than or equal to" ("меньше или равно") и определен в 8.28;

11) <same_as> - этот элемент представляет собой оператор для работы со строками символов "equals" ("соответствует") и определен в 8.29;

12) <not_same_as> - этот элемент представляет собой оператор для работы со строками символов "not equal to" ("не соответствует") и определен в 8.30;

13) <existing> - этот элемент представляет собой проверку условия, что переменная существует, и определен в 8.31;

14) <not_existing> - этот элемент представляет собой проверку условия, что переменной не существует, и определен в 8.32.

8.16.1.3 Если атрибут var присутствует, то элемент <only_if> не должен иметь текстового содержимого и дочерних элементов.

8.16.2 Семантика

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

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

8.16.2.3 Если атрибут var отсутствует и нет дочерних элементов, то результатом проверки условия должно быть значение "true".

8.16.2.4 Если присутствуют дочерние элементы, то результатом проверки условия каждого дочернего элемента должно быть корректное представление логического значения (см. 7.5). Результатом проверки условия в элементе <only_if> должно быть значение "true", если результаты проверки условий всех дочерних элементов имеют значение "true", в противном случае результатом проверки условия в элементе <only_if> должно быть значение "false".

8.16.2.5 Проверка условий дочерних элементов проводится во время обработки родительского элемента (см. 8.12.2.3 и 8.15.2.2). Если в результате проверки условий дочерних элементов получают значение "true", то родительский элемент обрабатывается в обычном режиме (как если бы он не содержал дочерних элементов <only_if>), в противном случае его обработка не оказывает никакого влияния на окончательный результат проверки условия.

      8.17 Элемент <wait_until>

8.17.1 Синтаксис

8.17.1.1 Данный элемент должен иметь следующие атрибуты:

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

b) timeout_var (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2), значение которой определяет максимальную допустимую продолжительность (в миллисекундах) ожидания;

c) setvar (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2);

d) var (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2).

8.17.1.2 Должен присутствовать только один из атрибутов timeout_var или timeout_value.

8.17.1.3 Атрибут setvar не должен присутствовать в том случае, если не присутствует атрибут timeout_value или атрибут timeout_var.

8.17.1.4 Содержимое этого элемента должно включать в себя те же дочерние элементы, которые содержит элемент <only_if> (см. 8.16).

8.17.1.5 Если атрибут var присутствует, то элемент <wait_until> не должен иметь текстового содержимого и дочерних элементов.

8.17.2 Семантика

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

8.17.2.2 Условие в элементе <wait_until> основано на одной переменной или на сочетании переменных, значений, логических операторов, числовых операторов и иных операторов.

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

8.17.2.4 Если атрибут var отсутствует и нет дочерних элементов, то результатом проверки условия должно быть значение "true".

8.17.2.5 Если присутствуют дочерние элементы, то результатом проверки условия каждого дочернего элемента должно быть корректное представление логического значения (см. 7.5). Результатом проверки условия в элементе <wait_until> должно быть значение "true", если результаты проверки условий всех дочерних элементов имеют значение "true", в противном случае результатом проверки условия в элементе <wait_until> должно быть значение "false".

8.17.2.6 Если атрибут timeout_value присутствует, то его значением должно быть корректное представление целого числа (см. 7.4), которое определяет максимальную допустимую продолжительность ожидания (в миллисекундах). Если присутствует атрибут timeout_var, то его значением должно быть имя существующей переменной, а значением этой переменной должно быть корректное представление целого числа (см. 7.4), которое определяет максимальную допустимую продолжительность. В противном случае ожидание может длиться (концептуально) в течение неопределенного времени.

Примечание - См. примечание к 8.15.2.8.

8.17.2.7 Проверка условия должна проводиться многократно и постоянно в течение времени ожидания до тех пор, пока в результате проверки условия не получено значение "true" или не достигнута максимальная допустимая продолжительность ожидания (в случае ее наличия).

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

8.17.2.8 Проверку условия следует проводить не менее одного раза. Если в результате первой проверки получено значение "true", то в этом случае максимальную допустимую продолжительность не считают превышенной.

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

8.17.2.9 Если присутствует атрибут setvar, то должны быть соблюдены четыре условия, описанные в 8.17.2.9.1-8.17.2.9.4.

8.17.2.9.1 Значением атрибута setvar должно быть корректное имя глобальной или локальной переменной (см. 7.2). Значением атрибута setvar не должен быть входной параметр обрабатываемого утверждения (см. 8.3) и оно не должно начинаться с двух следующих друг за другом символов "НИЖНЕЕ ПОДЧЕРКИВАНИЕ" ("_"). Переменная, имя которой определяется значением атрибута setvar, может существовать до присвоения ей значения или может быть новой переменной, созданной в процессе присвоения.

8.17.2.9.2 Если максимальная допустимая продолжительность превышена, в то время как результат проверки условия все еще имеет значение "false", то переменная должна быть создана (если она не существует) и ей должно быть присвоено значение "true".

8.17.2.9.3 Если в начале ожидания результат проверки условия уже имеет значение "true" или приобретает значение "true" в течение ожидания, то переменная должна быть создана (если она не существует) и ей должно быть присвоено значение "false".

8.17.2.9.4 Переменная не должна создаваться (если она не существует до ожидания) и ей не должны присваиваться значения, кроме случаев, указанных в 8.17.2.9.2 и 8.17.2.9.3.

Примечание - Это предполагает, что переменная не может быть инициализирована до начала ожидания.

      8.18 Элемент <assert_condition>

8.18.1 Синтаксис

8.18.1.1 Данный элемент должен иметь следующие атрибуты:

a) response_if_true (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть "pass" или "undecided"; этот атрибут определяет, какой выдать ответ о соответствии, если в результате проверки условия получено значение "true"; по умолчанию атрибут response_if_true имеет значение"pass";

b) response_if_false (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть "fail" или "undecided"; этот атрибут определяет, какой выдать ответ о соответствии, если в результате проверки условия получено значение "false"; по умолчанию атрибут response_if_false имеет значение "fail".

c) break_if_false (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть "false" или "true"; этот атрибут определяет, должно ли выполнение текущей операции быть прекращено в случае, если в результате проверки условия получено значение "false"; по умолчанию атрибут break_if_false имеет значение "false";

d) var (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2).

8.18.1.2 Содержимое этого элемента должно включать в себя те же дочерние элементы, которые включает элемент <only_if> (см. 8.16).

8.18.1.3 Если атрибут var присутствует, то элемент не должен иметь текстового содержимого и дочерних элементов.

8.18.2 Семантика

8.18.2.1 Этот элемент определяет:

a) условие, которое позволяет установить определенный аспект функционирования тестируемой реализации;

b) заключение о соответствии ("pass", "undecided"), которое необходимо выдать в случае выполнения условия и

c) заключение о соответствии ("fail", "undecided"), которое необходимо выдать в случае невыполнения условия.

8.18.2.2 Атрибуты элемента <assert_condition> позволяют определить критерий соответствия, согласно которому выполнение определенного условия приводит к выдаче заключения о соответствии "pass", а невыполнение - к выдаче заключения о соответствии "undicided", в то время как невыполнение другого условия приводит к выдаче заключения о соответствии "fail", а его выполнение - к выдаче заключения о соответствии "undecided".

8.18.2.3 Атрибут break_if_false определяет, станет ли отрицательный результат проверки условия ("false") причиной того, что абстрактная испытательная машина прекратит выполнение текущего процесса (см. 8.9.2.18). Этот атрибут позволяет обрабатывать такие типовые случаи, в которых совокупность последовательных действий, соответствующая выдаче определенного заключения о соответствии, является бессмысленной.

8.18.2.4 Условие в элементе <assert_condition> основано на одной переменной или на сочетании переменных, значений, логических операторов, числовых операторов и иных операторов.

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

8.18.2.6 Если атрибут var отсутствует и нет дочерних элементов, то результатом проверки условия должно быть значение "true".

8.18.2.7 Если присутствуют дочерние элементы, то результатом проверки условия каждого дочернего элемента должно быть корректное представление логического значения (см. 7.5). Результатом проверки условия в элементе <assert_condition> должно быть значение "true", если результаты проверки условий всех дочерних элементов имеют значение "true", в противном случае результатом проверки условия в элементе <assert_condition> должно быть значение "false".

8.18.2.8 Если в результате проверки условия получено значение "true", то соответствующее заключение о соответствии (см. 8.18.2.1, перечисление b)) должно быть выдано согласно требованиям раздела 11.

8.18.2.9 Если в результате проверки условия получено значение "false", то соответствующее заключение о соответствии (см. 8.18.2.1, перечисление с)) должно быть выдано согласно требованиям раздела 11. Если атрибут break_if_false имеет значение "true", то выполнение текущего процесса должно быть прекращено (см. 8.9.2.18).

      8.19 Элемент <and>

8.19.1 Синтаксис

8.19.1.1 Данный элемент должен иметь следующие атрибуты:

a) var1 (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2);

b) var2 (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2).

8.19.1.2 Содержимое этого элемента должно включать в себя те же дочерние элементы, что и содержимое элемента <only_if> (см. 8.16), но с ограничением, определенным в 8.19.1.3.

8.19.1.3 Если присутствует один из атрибутов var1 или var2, то должны присутствовать оба атрибута (var1 и var2), а элемент <and> не должен иметь текстового содержимого и дочерних элементов. В противном случае элемент <and> должен иметь два или более дочерних элемента.

8.19.2 Семантика

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

8.19.2.2 Этот элемент представляет собой логический оператор AND ("И"), чьи операнды могут быть предоставлены в качестве атрибутов этого элемента или в качестве дочерних элементов. Если применяются атрибуты, то число операндов должно равняться двум, в противном случае - двум или больше.

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

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

8.19.2.5 Если присутствуют оба атрибута var1 и var2, то операндам присваиваются значения двух переменных, имена которых определены значениями атрибутов var1 и var2. В противном случае операндам присваиваются значения, полученные из текстового содержимого дочерних элементов элемента <and>.

8.19.2.6 Каждый операнд должен быть корректным представлением логического значения (см. 7.5). В результате проверки условия должно быть получено значение "true" в том случае, если все операнды имеют значение "true", в противном случае должно быть получено значение "false".

      8.20 Элемент <or>

8.20.1 Синтаксис

8.20.1.1 Данный элемент должен иметь следующие атрибуты:

a) var1 (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2);

b) var2 (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2).

8.20.1.2 Содержимое этого элемента должно включать в себя те же дочерние элементы, которые содержит элемент <only_if> (см. 8.16), но с ограничением, указанным в 8.20.1.3.

8.20.1.3 Если присутствует один из атрибутов var1 или var2, то должны присутствовать оба атрибута (var1 и var2), а элемент <or> не должен иметь текстового содержимого и дочерних элементов. В противном случае элемент <or> должен иметь два или более дочерних элемента.

8.20.2 Семантика

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

8.20.2.2 Этот элемент представляет собой логический оператор OR ("ИЛИ"), чьи операнды могут быть предоставлены в качестве атрибутов этого элемента или в качестве дочерних элементов. Если применяются атрибуты, то число операндов должно равняться двум, в противном случае - двум или больше.

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

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

8.20.2.5 Если присутствуют оба атрибута var1 и var2, то операндам присваиваются значения двух переменных, имена которых определены значениями атрибутов var1 и var2. В противном случае операндам присваиваются значения, полученные из текстового содержимого дочерних элементов элемента <or>.

8.20.2.6 Каждый операнд должен быть корректным представлением логического значения (см. 7.5). В результате проверки условия должно быть получено значение "false" в том случае, если все операнды имеют значение "false", в противном случае должно быть получено значение "true".

      8.21 Элемент <xor>

8.21.1 Синтаксис

8.21.1.1 Данный элемент должен иметь следующие атрибуты:

a) var1 (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2);

b) var2 (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2).

8.21.1.2 Содержимое этого элемента должно включать в себя те же дочерние элементы, которые содержит элемент <only_if> (см. 8.16), но с ограничением, указанным в 8.21.1.3.

8.21.1.3 Если присутствует один из атрибутов var1 или var2, то должны присутствовать оба атрибута (var1 и var2), а элемент <xor> не должен иметь текстового содержимого и дочерних элементов. В противном случае элемент <xor> должен иметь два дочерних элемента.

8.21.2 Семантика

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

8.21.2.2 Этот элемент представляет собой логический оператор XOR (exclusive OR, "исключающее ИЛИ"), чьи операнды могут быть предоставлены в качестве атрибутов этого элемента или в качестве дочерних элементов. Число операндов должно быть равно двум.

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

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

8.21.2.5 Если присутствуют оба атрибута var1 и var2, то операндам присваиваются значения двух переменных, имена которых определены значениями атрибутов var1 и var2. В противном случае операндам присваиваются значения, полученные из текстового содержимого дочерних элементов элемента <xor>.

8.21.2.6 Каждый операнд должен быть корректным представлением логического значения (см. 7.5). В результате проверки условия должно быть получено значение "true" в том случае, если два операнда имеют различное значение, в противном случае должно быть получено значение "false".

      8.22 Элемент <not>

8.22.1 Синтаксис

8.22.1.1 Данный элемент должен иметь следующий атрибут:

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

8.22.1.2 Содержимое этого элемента должно включать в себя те же дочерние элементы, которые содержит элемент <only_if> (см. 8.16), но с ограничением, указанным в 8.22.1.3.

8.22.1.3 Если присутствует атрибут var, то элемент <not> не должен иметь текстового содержимого и дочерних элементов. В противном случае элемент <not> должен иметь ровно один дочерний элемент.

8.22.2 Семантика

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

8.22.2.2 Этот элемент представляет собой логический оператор NOT ("НЕ"), операнд которого может быть предоставлен в качестве атрибута этого элемента или в качестве дочернего элемента. Число операндов должно быть равно одному.

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

8.22.2.4 Если присутствует атрибут var, то операнду присваивается значение переменной, имя которой определено значением атрибута var. В противном случае операнду присваивается значение, полученное из текстового содержимого дочернего элемента для элемента <not>.

8.22.2.5 Операнд должен быть корректным представлением логического значения (см. 7.5). В результате проверки условия должно быть получено значение "false", если операнд имеет значение "true", в противном случае должно быть получено значение "true".

      8.23 Элемент <equal_to>

8.23.1 Синтаксис

8.23.1.1 Данный элемент должен иметь следующие атрибуты:

a) var1 (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2);

b) var2 (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2);

c) value1 (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное представление целого числа;

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

8.23.1.2 Содержимое этого элемента должно включать в себя те же дочерние элементы, которые содержит элемент <only_if> (см. 8.16), но с ограничением, указанным в 8.23.1.3.

8.23.1.3 Должен присутствовать только один из атрибутов var1 или value1.

8.23.1.4 Должен присутствовать только один из атрибутов var2 или value2.

8.23.1.5 Если присутствуют атрибуты var1 или value1 и атрибуты var2 или value2, то элемент <equal_to> не должен иметь текстового содержимого и дочерних элементов. Если не присутствует ни один из атрибутов, то должно быть два дочерних элемента, в противном случае должен быть только один дочерний элемент.

8.23.2 Семантика

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

8.23.2.2 Этот элемент представляет собой числовую операцию "equals" ("равно"), чьи операнды могут быть предоставлены в качестве атрибутов этого элемента или в качестве дочерних элементов. Число операндов должно быть равно двум.

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

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

8.23.2.5 Если атрибут var1 присутствует, то первому операнду присваивается значение переменной, имя которой определено значением атрибута var1. Если атрибут value1 присутствует, то первому операнду присваивается значение этого атрибута. В противном случае первому операнду присваивается значение, полученное из текстового содержимого первого (или единственного) дочернего элемента.

8.23.2.6 Если атрибут var2 присутствует, то второму операнду присваивается значение переменной, имя которой определено значением атрибута var2. Если атрибут value2 присутствует, то второму операнду присваивается значение этого атрибута. В противном случае второму операнду присваивается значение, полученное из текстового содержимого второго (или единственного) дочернего элемента.

8.23.2.7 Каждый операнд должен быть корректным представлением целого числа (см. 7.4). В результате проверки условия должно быть получено значение "true" в том случае, если целое число, представленное первым операндом, равно целому числу, представленному вторым операндом, в противном случае должно быть получено значение "false".

      8.24 Элемент <not_equal_to>

8.24.1 Синтаксис

Синтаксис данного элемента аналогичен синтаксису элемента <equal_to> (см. 8.23).

8.24.2 Семантика

8.24.2.1 Семантика данного элемента аналогична семантике элемента <equal_to>, за исключением следующего.

8.24.2.2 Этот элемент представляет собой числовую операцию "not equal to" ("не равно"). В результате проверки условия должно быть получено значение "true" в том случае, если целое число, представленное первым операндом, не равно целому числу, представленному вторым операндом, в противном случае должно быть получено значение "false".

      8.25 Элемент <greater_than>

8.25.1 Синтаксис

Синтаксис данного элемента аналогичен синтаксису элемента <equal_to> (см. 8.23).

8.25.2 Семантика

8.25.2.1 Семантика данного элемента аналогична семантике элемента <equal_to>, за исключением следующего.

8.25.2.2 Этот элемент представляет собой числовую операцию "greater than" ("больше"). В результате проверки условия должно быть получено значение "true", если целое число, представленное первым операндом, больше целого числа, представленного вторым операндом, в противном случае должно быть получено значение "false".

      8.26 Элемент <greater_than_or_equal_to>

8.26.1 Синтаксис

Синтаксис данного элемента аналогичен синтаксису элемента <equal_to> (см. 8.23).

8.26.2 Семантика

8.26.2.1 Семантика данного элемента аналогична семантике элемента <equal_to>, за исключением следующего.

8.26.2.2 Этот элемент представляет собой числовую операцию "greater than or equal to" ("больше или равно"). В результате проверки условия должно быть получено значение "true" в том случае, если целое число, представленное первым операндом, больше или равно целому числу, представленному вторым операндом, в противном случае должно быть получено значение "false".

      8.27 Элемент <less_than>

8.27.1 Синтаксис

Синтаксис данного элемента аналогичен синтаксису элемента <equal_to> (см. 8.23).

8.27.2 Семантика

8.27.2.1 Семантика данного элемента аналогична семантике элемента <equal_to>, за исключением следующего.

8.27.2.2 Этот элемент представляет собой числовую операцию "less than" ("меньше"). В результате проверки условия должно быть получено значение "true" в том случае, если целое число, представленное первым операндом, меньше целого числа, представленного вторым операндом, в противном случае должно быть получено значение "false".

      8.28 Элемент <less_than_or_equal_to>

8.28.1 Синтаксис

Синтаксис данного элемента аналогичен синтаксису элемента <equal_to> (см. 8.23).

8.28.2 Семантика

8.28.2.1 Семантика данного элемента аналогична семантике элемента <equal_to>, за исключением следующего.

8.28.2.2 Этот элемент представляет собой числовую операцию "less than or equal to" ("меньше или равно"). В результате проверки условия должно быть получено значение "true", если целое число, представленное первым операндом, меньше или равно целому числу, представленному вторым операндом, в противном случае должно быть получено значение "false".

      8.29 Элемент <same_as>

8.29.1 Синтаксис

8.29.1.1 Данный элемент должен иметь следующие атрибуты:

a) var1 (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2);

b) var2 (необязательный атрибут) - если этот атрибут присутствует, то его значением должно быть корректное имя переменной (см. 7.2);

c) value1 (необязательный атрибут);

d) value2 (необязательный атрибут).

8.29.1.2 Этот элемент должен включать в себя те же дочерние элементы, что и элемент <only_if> (см. 8.16), за исключением следующего.

8.29.1.3 Должен присутствовать только один из атрибутов var1 или value1.

8.29.1.4 Должен присутствовать только один из атрибутов var2 или value2.

8.29.1.5 Если присутствуют атрибуты var1 или value1 и атрибуты var2 или value2, то элемент <same_as> не должен иметь текстового содержимого и дочерних элементов. Если не присутствует ни один из атрибутов, то должно быть два дочерних элемента. В противном случае должен быть один дочерний элемент.

8.29.2 Семантика

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

8.29.2.2 Этот элемент представляет собой строковую операцию "equals" ("соответствует"), чьи операнды могут быть предоставлены в качестве атрибутов этого элемента или в качестве дочерних элементов. Число операндов должно быть равно двум.

8.29.2.3 Если атрибут var1 присутствует, то его значением должно быть имя существующей переменной.

8.29.2.4 Если атрибут var2 присутствует, то его значением должно быть имя существующей переменной.

8.29.2.5 Если атрибут var1 присутствует, то первому операнду присваивается значение переменной, имя которой определено значением атрибута var1. Если атрибут value1 присутствует, то первому операнду присваивается значение этого атрибута. В противном случае первому операнду присваивается значение, полученное из текстового содержимого первого (или единственного) дочернего элемента.

8.29.2.6 Если атрибут var2 присутствует, то второму операнду присваивается значение переменной, имя которой определено значением атрибута var2. Если атрибут value2 присутствует, то второму операнду присваивается значение этого атрибута. В противном случае второму операнду присваивается значение, полученное из текстового содержимого второго (или единственного) дочернего элемента.

8.29.2.7 В результате проверки условия должно быть получено значение "true" в том случае, если строка символов, содержащаяся в первом операнде, совпадает со строкой символов, содержащейся во втором операнде, в противном случае должно быть получено значение "false".

      8.30 Элемент <not_same_as>

8.30.1 Синтаксис

Синтаксис данного элемента аналогичен синтаксису элемента <same_as> (см. 8.29).

8.30.2 Семантика

8.30.2.1 Семантика данного элемента аналогична семантике элемента <same_as>, за исключением следующего.

8.30.2.2 Этот элемент представляет собой строковую операцию "not equal to" ("не соответствует"). В результате проверки условия должно быть получено значение "true" в том случае, если строка символов, содержащаяся в первом операнде, не совпадает со строкой символов, содержащейся во втором операнде, в противном случае должно быть получено значение "false".

      8.31 Элемент <existing>

8.31.1 Синтаксис

8.31.1.1 Данный элемент должен иметь следующий атрибут:

- var (обязательный атрибут) - значением этого атрибута должно быть корректное имя переменной (см. 7.2).

8.31.1.2 Данный элемент не должен иметь текстового содержимого и дочерних элементов.

8.31.2 Семантика

8.31.2.1 Этот элемент представляет собой условие, основанное на переменной. Проверка условия осуществляется во время обработки родительского элемента.

8.31.2.2 Если значением атрибута var является имя существующей глобальной или локальной переменной, то в результате проверки условия должно быть получено значение "true", в противном случае должно быть получено значение "false".

      8.32 Элемент <not_existing>

8.32.1 Синтаксис

Синтаксис данного элемента аналогичен синтаксису элемента <existing> (см. 8.31).

8.32.2 Семантика

8.32.2.1 Семантика данного элемента аналогична семантике элемента <existing>, за исключением следующего.

8.32.2.2 Если значением атрибута var является имя существующей глобальной или локальной переменной, то в результате проверки должно быть получено значение "false", в противном случае должно быть получено значение "true".

      9 Функции стандартного интерфейса

      9.1 Общие положения

9.1.1 В данном разделе установлены требования к использованию функций BioAPI стандартного интерфейса BioAPI при проведении испытания на соответствие. В 9.2 установлены группы параметров с особыми ограничениями, которые необходимо учитывать в дополнение к ограничениям параметров, определенных в последующих подразделах. Каждый подраздел настоящего раздела (начиная с подраздела 9.3 и до конца раздела) устанавливает требования к следующим свойствам функций стандартного интерфейса BioAPI:

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

2) ограничениям на параметры;

3) входным параметрам вызова функции - установке собственных входных параметров базовой функции на основе входных параметров вызова функции;

4) выходным данным вызова функции - установке выходных параметров и возвращаемого значения вызова функции на основе собственных выходных параметров и возвращаемого значения базовой функции;

5) входным данным вызова связанного процесса - настройке входных параметров процесса, связанного с функцией стандартного интерфейса BioAPI на основе собственных входных параметров входящего вызова;

6) выходным данным вызова связанного процесса - установке собственных выходных параметров и возвращаемого значения входящего вызова на основе выходных параметров процесса, связанного с функцией стандартного интерфейса BioAPI;

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

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

9.1.2 "Исходящим значением" (для входного параметра функции) является:

a) значение атрибута value, если соответствующий элемент <input> содержит атрибут value;

b) значение переменной, чье имя является значением атрибута var, если соответствующий элемент <input> содержит атрибут var.

9.1.3 "Входящим значением" (для выходного параметра функции) является значение, которое должно быть присвоено переменной, чье имя является значением атрибута setvar соответствующего элемента <output> (если этот элемент представлен в вызове).

9.1.4 "Возвращаемым значением" функции является значение, которое должно быть присвоено переменной, чье имя является значением атрибута setvar элемента <return> (если этот элемент представлен в вызове).

9.1.5 "Входящим значением" (для входного параметра связанного процесса) является:

a) значение атрибута value, если соответствующий элемент <input> содержит атрибут value;

b) значение переменной, чье имя является значением атрибута var, если соответствующий элемент <input> содержит атрибут var.

9.1.6 "Исходящим значением" (для выходного параметра связанного процесса) является значение, которое должно быть присвоено переменной, чье имя является значением атрибута setvar соответствующего элемента <output> (если этот элемент присутствует в вызове).

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

9.1.8 В каждой модели испытаний на соответствие функции стандартного интерфейса BioAPI должны применяться в соответствии с таблицей 1.

Таблица 1 - Применение функций стандартного интерфейса BioAPI в разных моделях испытания на соответствие

9.1.9 Интерфейс BioAPI включает в себя следующие стандартные функции:

- BioAPI_Init;

- BioAPI_Terminate;

- BioAPI_GetFrameworklnfo;

- BioAPI_EnumBSPs;

- BioAPI_BSPLoad;

- BioAPI_BSPUnload;

- BioAPI_BSPAttach;

- BioAPI_BSPDetach;

- BioAPI_QueryUnits;

- BioAPI_EnumBFPs;

- BioAPI_QueryBFPs;

- BioAPI_ControlUnit;

- BioAPI_FreeBIRHandle;

- BioAPI_GetBIRFromHandle;

- BioAPI_GetHeaderFromHandle;

- BioAPI_EnableEvents;

- BioAPI_SetGUICallbacks;

- BioAPI_Capture;

- BioAPI_CreateTemplate;

- BioAPI_Process;

- BioAPI_ProcessWithAuxBIR;

- BioAPI_VerifyMatch;

- BioAPI_IdentifyMatch;

- BioAPI_Enroll;

- BioAPI_Verify;

- BioAPI_Identify;

- BioAPI_Import;

- BioAPI_PresetldentifyPopulation;

- BioAPI_DbOpen;

- BioAPI_DbClose;

- BioAPI_DbCreate;

- BioAPI_DbDelete;

- BioAPI_DbSetMarker;

- BioAPI_DbFreeMarker;

- BioAPI_DbStoreBIR;

- BioAPI_DbGetBIR;

- BioAPI_DbGetNextBIR;

- BioAPI_DbDeleteBIR;

- BioAPI_SetPowerMode;

- BioAPI_SetlndicatorStatus;

- BioAPI_GetlndicatorStatus;

- BioAPI_CalibrateSensor;

- BioAPI_Cancel;

- BioAPI_Free;

- BioAPI_UtiI_InstallBSP;

- BioAPI_Util_lnstallBFP.

9.1.10 Интерфейс BioSPI включает в себя следующие стандартные функции интерфейса BioAPI:

- BioSPI_BSPLoad;

- BioSPI_BSPUnload;

- BioSPI_BSPAttach;

- BioSPI_BSPDetach;

- BioSPI_QueryUnits;

- BioSPI_QueryBFPs;

- BioSPI_ControlUnit;

- BioSPI_FreeBIRHandle;

- BioSPI_GetBIRFromHandle;

- BioSPI_GetHeaderFromHandle;

- BioSPI_EnableEvents;

- BioSPI_SetGUICallbacks;

- BioSPI_Capture;

- BioSPI_CreateTemplate;

- BioSPI_Process;

- BioSPI_ProcessWithAuxBIR;

- BioSPI_VerifyMatch;

- BioSPI_IdentifyMatch;

-BioSPI_Enroll;

- BioSPI_Verify;

- BioSPI_Identify;

- BioSPI_Import;

- BioSPI_PresetldentifyPopulation;

- BioSPI_DbOpen;

- BioSPI_DbClose;

- BioSPI_DbCreate;

- BioSPI_DbDelete;

- BioSPI_DbSetMarker;

- BioSPI_DbFreeMarker;

- BioSPI_DbStoreBIR;

- BioSPI_DbGetBIR;

- BioSPI_DbGetNextBIR:

- BioSPI_DbDeleteBIR;

- BioSPI_SetPowerMode;

- BioSPI_SetlndicatorStatus;

- BioSPI_GetlndicatorStatus;

- BioSPI_CalibrateSensor;

- BioSPI_Cancel;

- BioSPI_Free.

9.1.11 Интерфейс обратного вызова приложения включает в себя следующие функции стандартного интерфейса BioAPI:

- BioAPI_EventHandler;

- BioAPI_GUI_STATE_CALLBACK;

- BioAPI_GUI_STREAMING_CALLBACK.

9.1.12 Интерфейс обратного вызова инфраструктуры включает в себя следующие функции стандартного интерфейса BioAPI:

- BioSPI_EventHandler;

- BioSPI_GUI_STATE_CALLBACK;

- BioSPI_GUI_STREAMING_CALLBACK;

- BioSPI_BFP_ENUMERATION_HANDLER;

- BioSPI_MEMORY_FREE_HANDLER.

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

      9.2 Группы параметров

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

9.2.1 Группа параметров "Биометрический тип"

9.2.1.1 Группа параметров "Биометрический тип" включает в себя следующие параметры:

- TypeMultiple;

- TypeFacialFeatures;

- TypeVoice;

- TypeFingerprint;

- Typelris;

- TypeRetina;

- TypeHandGeometry;

- TypeSignatureDynamics;

- TypeKeystrokeDynamics;

- TypeLipMovement;

- TypeThermalFacelmage;

- TypeThermalHandlmage;

- TypeGait;

- TypeOther;

- TypePassword.

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

9.2.1.3 Исходящим значением каждого из вышеприведенных параметров должно быть или корректно представленное логическое значение (см. 7.5), или пустая строка. Входящим значением должно быть стандартно представленное логическое значение (см. 7.5.2).

9.2.1.4 Значение (например, V) собственного типа BioAPI_BIR_BIOMETRIC_TYPE, представленное исходящим значением этой группы параметров, должно определяться следующим образом:

1) сначала должно быть установлено значение V, равное нулю;

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

Таблица 2

TypeMultiple	1=2
TypeFacialFeatures	2=2
TypeVoice	4=2
TypeFingerprint	8=2
Typelris	16=2
TypeRetina	32=2
TypeHandGeometry	64=2
TypeSignatureDynamics	128=2
TypeKeystrokeDynamics	256=2
TypeLipMovement	512=2
TypeThermalFacelmage	1024=2
TypeThermalHandlmage	2048=2
TypeGait	4096=2
TypeOther	1073741824=2
TypePassword	2147483648=2

Примечание - Если параметр TypeMultiple имеет значение "false", то только один из параметров, соответствующих другим типам, может иметь значение "true".

9.2.1.5 Если задано целое число (например, V), которое является значением собственного типа BioAPI_BIR_BIOMETRIC_TYPE, то входящее значение этой группы параметров, которое канонически представляет V, определяют следующим образом:

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

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

3) входящим значением всех остальных параметров (в случае их наличия) должно быть "false";

4) четное значение V, не являющееся единственным показателем степени числа 2, указывает на некорректное значение.

9.2.2 Группа параметров "Операции"

9.2.2.1 Группа параметров "Операции" включает в себя следующие параметры:

- OperationEnableEvents;

- OperationSetGUICallbacks;

- OperationCapture;

- OperationCreateTemplate;

- OperationProcess;

- OperationProcessWithAuxBIR;

- OperationVerifyMatch;

- OperationldentifyMatch;

- OperationEnroll;

- OperationVerify;

- Operationldentify;

- Operationlmport;

- OperationPresetldentifyPopulation;

- OperationDatabaseOperations;

- OperationSetPowerMode;

- OperationSetlndicatorStatus;

- OperationGetlndicatorStatus;

- OperationCalibrateSensor;

- OperationUtilities;

- OperationQueryUnits;

- OperationQueryBFPs.

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

9.2.2.3 Исходящим значением каждого из вышеприведенных параметров должно быть или корректно представленное логическое значение (см. 7.5), или пустая строка. Входящим значением должно быть стандартно представленное логическое значение (см. 7.5.2).

9.2.2.4 Значение (например, V) собственного типа BioAPI_OPERATIONS_MASK, представленное исходящим значением этой группы параметров, определяют следующим образом:

1) сначала должно быть установлено значение V, равное нулю;

2) для каждого элемента группы параметров, исходящее значение которого соответствует значению "true", к значению V должно быть прибавлено целое число в соответствии с таблицей 3.

Таблица 3

OperationEnableEvents	1=2
OperationSetGUICallbacks	2=2
OperationCapture	4=2
OperationCreateTemplate	8=2
OperationProcess	16=2
OperationProcessWithAuxBIR	32=2
OperationVerifyMatch	64=2
OperationldentifyMatch	128=2
OperationEnroll	256=2
OperationVerify	512=2
Operationldentify	1024=2
Operationlmport	2048=2
OperationPresetldentify Population	4096=2
OperationDatabaseOperations	8192=2
OperationSetPowerMode	16384=2
OperationSetlndicatorStatus	32768=2
OperationGetlndicatorStatus	65536=2
OperationCalibrateSensor	131072=2
OperationUtilities	262144=2
OperationQueryUnits	1048576=2
OperationQueryBFPs	2097152=2
OperationControlUnit	4194304=2

9.2.2.5 Если задано целое число (например, V), которое является значением собственного типа BioAPI_OPERATIONS_MASK, то входящее значение этой группы параметров, которое канонически представляет V, определяют следующим образом:

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

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

3) входящим значением всех остальных параметров (в случае их наличия) должно быть "false".

9.2.3 Группа параметров "Опции"

9.2.3.1 Группа параметров "Опции" включает в себя следующие параметры:

- OptionRaw;

- OptionQualityRaw;

- OptionQualitylntermediate;

- OptionQualityProcessed;

- OptionAppGUI;

- OptionSourcePresent;

- OptionPayload;

- OptionBIRSign;

- OptionBIREncrypt;

- OptionTemplateUpdate;

- OptionAdaptation;

- OptionBinning;

- OptionSelfContainedDevice;

- OptionMOC;

- OptionSubtypeToCapture;

- OptionSensorBFP;

- OptionArchiveBFP;

- OptionMatchingBFP;

- OptionProcessingBFP;

- OptionCoarseScores.

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

9.2.3.3 Исходящим значением каждого из вышеприведенных параметров должно быть или корректно представленное логическое значение (см. 7.5), или пустая строка. Входящим значением должно быть стандартно представленное логическое значение (см. 7.5.2).

9.2.3.4 Значение (например, V) собственного типа BioAPI_OPTIONS_MASK, представленное исходящим значением этой группы параметров, определяют следующим образом:

1) сначала должно быть установлено значение V, равное нулю;

2) для каждого элемента группы параметров, исходящее значение которого соответствует значению "true", к значению V должно быть прибавлено целое число в соответствии с таблицей 4.

Таблица 4

Option Raw	1=2
OptionQualityRaw	2=2
OptionQualitylntermediate	4=2
OptionQuality Processed	8=2
OptionAppGUI	16=2
OptionSourcePresent	64=2
OptionPayload	128=2
OptionBIRSign	256=2
OptionBIREncrypt	512=2
OptionTemplateUpdate	1024=2
OptionAdaptation	2048=2
OptionBinning	4096=2
OptionSelfContainedDevice	8192=2
OptionMOC	16384=2
OptionSubtypeToCapture	32768=2
OptionSensorBFP	65536=2
OptionArchiveBFP	131072=2
OptionMatchingBFP	262144=2
OptionProcessingBFP	524288=2
OptionCoarseScores	1048576=2

9.2.3.5 Если задано целое число (например, V), которое является значением собственного типа BioAPI_OPTIONS_MASK, то входящее значение этой группы параметров, которое канонически представляет V, определяют следующим образом:

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

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

3) входящим значением всех остальных параметров (в случае их наличия) должно быть "false".

9.2.4 Группа параметров "События"

9.2.4.1 Группа параметров "События" включает в себя следующие параметры:

- EventNotifylnsert;

- EventNotifyRemove;

- EventNotifyFault;

- EventNotifySourcePresent;

- EventNotifySourceRemoved.

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

9.2.4.3 Исходящим значением каждого из вышеприведенных параметров должно быть или корректно представленное логическое значение (см. 7.5), или пустая строка. Входящим значением должно быть стандартно представленное логическое значение (см. 7.5.2).

9.2.4.4 Значение (например, V) собственного типа BioAPI_EVENT_MASK, представленное исходящим значением этой группы параметров, определяют следующим образом:

1) сначала должно быть установлено значение V, равное нулю;

2) для каждого элемента группы параметров, исходящее значение которого соответствует значению "true", к значению V должно быть прибавлено целое число в соответствии с таблицей 5.

Таблица 5

EventNotifylnsert	1=2
EventNotifyRemove	2=2
EventNotifyFault	4=2
EventNotifySourcePresent	8=2
EventNotifySourceRemoved	16=2

9.2.4.5 Если задано целое число (например, V), которое является значением собственного типа BioAPI_EVENT_MASK, то входящее значение этой группы параметров, которое канонически представляет значение V, определяют следующим образом:

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

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

3) входящим значением всех остальных параметров (в случае их наличия) должно быть "false".

9.2.5 Группа параметров "Тип биометрических данных"

9.2.5.1 Группа параметров "Тип биометрических данных" включает в себя следующие параметры:

- ProcessedLevel;

- Encrypted;

- Signed;

- IndexPresent.

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

9.2.5.3 У элементов данной группы параметров должны быть входящие и исходящие значения, соответствующие приведенным в 9.2.5.3.1 и 9.2.5.3.2.

9.2.5.3.1 Исходящим значением ProcessedLevel должно быть или корректно представленное целое число (см. 7.4) в интервале от 0 до 15, или пустая строка.

Входящим значением должно быть стандартно представленное целое число (см. 7.4.3) в том же интервале.

9.2.5.3.2 Исходящими значениями Encrypted, Signed и IndexPresent должны быть или корректно представленные логические значения (см. 7.5), или пустые строки. Входящими значениями должны быть стандартно представленные логические значения (см. 7.5.2).

9.2.5.4 Значение (например, V) собственного типа BioAPI_BIR_DATA_TYPE, представленное исходящим значением этой группы параметров, определяют следующим образом:

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

2) для каждого элемента группы параметров (кроме ProcessedLevel), исходящее значение которого соответствует значению "true", к значению V должно быть прибавлено целое число в соответствии с таблицей 6.

Таблица 6

Encrypted	16=2
Signed	32=2
IndexPresent	128=2

9.2.5.5 Если задано целое число (например, V), которое является значением собственного типа BioAPI_BIR_DATA_TYPE, входящее значение этой группы параметров, которое канонически представляет значение V, определяют следующим образом:

1) целое число V должно быть разбито на сумму:

i) целого числа меньше 16;

ii) значения 16;

iii) значения 32 и

iv) значения 128,

каждое из которых присутствует в сумме показателей не более одного раза;

2) для каждого показателя степени числа 2, указанного в вышеприведенной таблице (16, 32 и 128), который появляется в разбиении целого числа V, входящим значением параметра в соответствующей строке таблицы должно быть "true";

3) входящим значением ProcessedLevel должно быть стандартно представленное целое число, указанное в 1) перечисление i) (см. 7.4.3);

4) входящим значением всех остальных параметров (в случае их наличия) должно быть "false".

9.2.6 Группа параметров "Биометрический подтип"

9.2.6.1 Группа параметров "Биометрический подтип" включает в себя следующие параметры:

- Left (левый);

- Right (правый);

- Thumb (большой палец);

- PointerFinger (указательный палец);

- MiddleFinger (средний палец);

- RingFinger (безымянный палец);

- LittleFinger (мизинец);

- Multiple.

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

9.2.6.3 Исходящим значением каждого из вышеуказанных параметров должно быть или корректно представленное логическое значение (см. 7.5), или пустая строка. Входящим значением должно быть стандартно представленное логическое значение (см. 7.5.2).

9.2.6.4 Значение (например, V) собственного типа BioAPI_BIR_SUBTYPE, представленное исходящим значением этой группы параметров, определяют следующим образом:

1) первоначально значение V должно быть установлено равным нулю;

2) для каждого элемента группы параметров, исходящее значение которого соответствует значению "true", к значению V должно быть прибавлено целое число в соответствии с таблицей 7.

Таблица 7

Left	1=2
Right	2=2
Thumb	4=2
PointerFinger	8=2
MiddleFinger	16=2
RingFinger	32=2
LittleFinger	64=2
Multiple	128=2

9.2.6.5 Если задано целое число (например, V), которое является значением собственного типа BioAPI_BIR_SUBTYPE, то входящее значение этой группы параметров, которое канонически представляет значение V, определяют следующим образом:

1) целое число V должно быть разбито на сумму показателей степеней числа 2, каждый из которых присутствует в сумме показателей не более одного раза;

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

3) входящим значением всех остальных параметров (в случае их наличия) должно быть "false".

9.2.7 Группа параметров "Дата"

9.2.7.1 Группа параметров "Дата" включает в себя следующие параметры:

- Year;

- Month;

- Day.

9.2.7.2 Эта группа параметров поддерживает представление значений собственного типа BioAPI_DATE.

9.2.7.3 У элементов данной группы параметров должны быть входящие и исходящие значения, определенные в соответствии с 9.2.7.3.1 и 9.2.7.3.2.

9.2.7.3.1 Исходящим значением Year должно быть или корректно представленное целое число (см. 7.4) в интервале от 0 до 65535, или пустая строка. Входящим значением должно быть стандартно представленное целое число (см. 7.4.3) в том же интервале.

9.2.7.3.2 Исходящими значениями Month и Day должны быть или корректно представленные целые числа (см. 7.4) в интервале от 0 до 255, или пустые строки. Входящими значениями должны быть стандартно представленные целые числа (см. 7.4.3) в том же интервале.

9.2.7.4 Значение (например, V) собственного типа BioAPI_DATE, представленное исходящим значением этой группы параметров, определяют следующим образом.

Целые числа, представленные исходящими значениями Year, Month и Day (или ноль, если исходящими значениями являются пустые строки), должны быть записаны в поля Year, Month и Day (соответственно) поля Date значения V.

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

Входящими значениями Year, Month и Day должны быть стандартно представленные целые числа (см. 7.4.3) в полях Year, Month и Day (соответственно) поля Date значения V.

9.2.8 Группа параметров "Дата и время"

9.2.8.1 Группа параметров "Дата и время" включает в себя следующие параметры:

- Year;

- Month;

- Day;

- Hour;

- Minute;

- Second.

9.2.8.2 Эта группа параметров поддерживает представление значений собственного типа BioAPI_DTG.

9.2.8.3 У элементов данной группы параметров должны быть входящие и исходящие значения, соответствующие приведенным в 9.2.8.3.1 и 9.2.8.3.2.

9.2.8.3.1 Исходящим значением Year должно быть или корректно представленное целое число (см. 7.4) в интервале от 0 до 65535, или пустая строка. Входящим значением должно быть стандартно представленное целое число (см. 7.4.3) в том же интервале.

9.2.8.3.2 Исходящими значениями Month, Day, Hour, Minute и Second должны быть или корректно представленные целые числа (см. 7.4) в интервале от 0 до 255, или пустые строки. Входящими значениями должны быть стандартно представленные целые числа (см. 7.4.3) в том же интервале.

9.2.8.4 Значение (например, V) собственного типа BioAPI_DTG, представленное исходящим значением этой группы параметров, определяют в соответствии с 9.2.8.4.1 и 9.2.8.4.2.

9.2.8.4.1 Целые числа, представленные исходящими значениями Year, Month и Day (или 0, если исходящими значениями являются пустые строки), должны быть записаны в поля Year, Month и Day (соответственно) поля Date значения V.

9.2.8.4.2 Целые числа, представленные исходящими значениями Hour, Minute и Second (или 0, если исходящими значениями являются пустые строки), должны быть записаны в поля Hour, Minute и Second (соответственно) поля Time значения V.

9.2.8.5 Если задано значение (например, V), то входящее значение этой группы параметров, которое канонически представляет значение V, следует определять в соответствии с 9.2.8.5.1 и 9.2.8.5.2.

9.2.8.5.1 Входящими значениями Year, Month и Day должны быть стандартно представленные целые числа (см. 7.4.3) в полях Year, Month и Day (соответственно) поля Date значения V.

9.2.8.5.2 Входящими значениями Hour, Minute и Second должны быть стандартно представленные целые числа (см. 7.4.3) в полях Hour, Minute и Second (соответственно) поля Time значения V.

9.2.9 Группа параметров "Схема инфраструктуры"

9.2.9.1 Группа параметров "Схема структуры" включает в себя следующие параметры:

- FrameworkUuid;

- Description;

- Path;

- SpecVersion;

- ProductVersion;

- Vendor;

- FwPropertyld;

- FwProperty.

9.2.9.2 Эта группа параметров поддерживает представление значений собственного типа BioAPI_FRAMEWORK_SCHEMA.

9.2.9.3 У элементов данной группы параметров должны быть входящие и исходящие значения, соответствующие приведенным в 9.2.9.3.1-9.2.9.3.5.

9.2.9.3.1 Исходящими значениями FrameworkUuid и Fwpropertyld должны быть или корректно представленные УУИД (см. 7.6), или пустые строки. Входящими значениями должны быть стандартно представленные УУИД (см. 7.6.3).

9.2.9.3.2 Исходящим значением SpecVersion должно быть или корректно представленное целое число в интервале от 0 до 255, или пустая строка. Входящим значением должно быть стандартно представленное целое число в том же интервале.

9.2.9.3.3 Исходящие или входящие значения ProductVersion, Vendor и Description должны представлять собой строку символов, кодировка UTF-8 которой должна быть не длиннее 268 байтов, не содержащую символы NUL (0).

9.2.9.3.4 Исходящим значением FwProperty должен быть корректно представленный набор байтов (см. 7.7). Входящим значением должен быть стандартно представленный набор байтов (см. 7.7.2).

9.2.9.3.5 Исходящее или входящее значение Path должно представлять собой строку символов, не содержащую символов NUL (0).

9.2.9.4 Значение (например, V) собственного типа BioAPI_FRAMEWORK_SCHEMA, представленное исходящим значением этой группы параметров, следует определять в соответствии с 9.2.9.4.1-9.2.9.4.5.

9.2.9.4.1 УУИД, представленные исходящими значениями FrameworkUuid и Fwpropertyld (или УУИД "00000000-0000-0000-0000-000000000000", если исходящим значением является пустая строка) должны быть записаны в поле значения V с тем же именем.

9.2.9.4.2 Целое число, представленное исходящим значением SpecVersion (или 0, если исходящим значением является пустая строка), должно быть записано в поле SpecVersion значения V.

9.2.9.4.3 Строки символов, являющиеся исходящими значениями Description, ProductVersion и Vendor, должны быть записаны в поле значения V с теми же именами, заканчивающимися символом конца строки NUL (0).

9.2.9.4.4 Набор байтов, представленный исходящим значением FwProperty, должен быть записан в блок памяти достаточного объема. Адрес и длина блока памяти должны быть записаны в поля Data и Length (соответственно) переменной типа BioAPI_DATA, адрес которой должен быть записан в поле FwProperty значения V.

9.2.9.4.5 Строка символов, являющаяся исходящим значением Path, должна быть записана с символом NUL (0) в конце в блок памяти достаточного объема, адрес которого должен быть записан в поле Path значения V.

9.2.9.5 Если задано значение (например, V) собственного типа BioAPI_FRAMEWORK_SCHEMA, то входящее значение этой группы параметров, которое канонически представляет V, следует определять в соответствии с 9.2.9.5.1-9.2.9.5.2.

9.2.9.5.1 Входящими значениями FrameworkUuid и Fwpropertyld должны быть стандартно представленные (см. 7.6.3) УУИД в поле значения V с теми же именами.

9.2.9.5.2 Входящим значением SpecVersion должно быть стандартно представленное целое число в поле значения V с тем же именем.

9.2.9.5.3 Входящие значения Description, ProductVersion и Vendor должны представлять собой строки символов в поле V с теми же именами без символа NUL (0) в конце строки.

9.2.9.5.4 Входящим значением FwProperty должен быть стандартно представленный набор байтов в блоке памяти, адрес и длина которого находятся в полях Data и Length (соответственно) переменной типа BioAPI_DATA, на которую указывает значение, находящееся в поле FwProperty значения V.

9.2.9.5.5 Входящее значение Path должно представлять собой строку символов, на которую указывает поле значения V с тем же именем и без символа NUL (0) в конце строки.

9.2.10 Группа параметров "Схема ПБУ"

9.2.10.1 Группа параметров "Схема ПБУ" включает в себя следующие параметры:

- BSPUuid;

- Description;

- Path;

- SpecVersion;

- ProductVersion;

- Vendor;

- Format_1_FormatOwner;

- Format_1_FormatType;

- Format_2_FormatOwner;

- Format_2_FormatType;

- Format_3_FormatOwner;

- Format_3_FormatType;

- Format_4_FormatOwner;

- Format_4_FormatType;

- NumSupportedFormats;

- элементы группы параметров "Биометрический тип" (см. 9.2.1);

- элементы группы параметров "Операции" (см. 9.2.2);

- элементы группы параметров "Опции" (см. 9.2.3);

- PayloadPolicy;

- MaxPayloadSize;

- DefaultVerifyTimeout;

- DefaultldentifyTimeout;

- DefaultCaptureTimeout;

- DefaultEnrollTimeout;

- DefaultCalibrateTimeout;

- MaxBSPDbSize;

- Maxldentify.

9.2.10.2 Эта группа параметров поддерживает представление значений собственного типа BioAPI_BSP_SCHEMA.

9.2.10.3 У элементов данной группы параметров должны быть входящие и исходящие значения, соответствующие приведенным в 9.2.10.3.1-9.2.10.3.2.

9.2.10.3.1 Исходящим значением BSPUuid должен быть или корректно представленный УУИД (см. 7.6), или пустая строка. Входящим значением должен быть стандартно представленный УУИД (см. 7.6.3).

9.2.10.3.2 Исходящие или входящие значения Description, ProductVersion и Vendor должны представлять собой строки символов, кодировка UTF-8 которых не должна быть длиннее 268 байтов, и которые не должны содержать символов NUL (0).

9.2.10.3.3 Исходящее или входящее значение Path должно представлять собой строку символов, не содержащую символов NUL (0).

9.2.10.3.4 Исходящим значением SpecVersion должно быть или корректно представленное целое число (см. 7.4) в интервале от 0 до 255, или пустая строка. Входящим значением должно быть стандартно представленное целое число (см. 7.4.3) в том же интервале.

9.2.10.3.5 Исходящими значениями Format_X_FormatOwner и Format_X_FormatType (где X=1, 2, 3 или 4) должны быть или корректно представленные целые числа (см. 7.4) в интервале от 0 до 65535, или пустые строки. Входящими значениями должны быть стандартно представленные целые числа (см. 7.4.3) в том же интервале или пустые строки.

9.2.10.3.6 Исходящими значениями NumSupportedFormats, MaxPayloadSize, MaxBSPDbSize и Maxldentify должны быть или корректно представленные целые числа (см. 7.4) в интервале от 0 до 4294967295, или пустые строки. Входящими значениями должны быть стандартно представленные целые числа (см. 7.4.3) в том же интервале.

9.2.10.3.7 Исходящими значениями группы параметров "Биометрический тип" должны быть корректно представленные значения собственного типа BioAPI_BIR_DATA_TYPE (см. 9.2.5.4). Входящими значениями должны быть стандартно представленные значения этого типа (см. 9.2.5.5).

9.2.10.3.8 Исходящими значениями группы параметров "Операции" должны быть корректно представленные значения собственного типа BioAPI_OPERATIONS_MASK (см. 9.2.2.4). Входящими значениями должны быть стандартно представленные значения этого типа (см. 9.2.2.5).

9.2.10.3.9 Исходящими значениями группы параметров "Опции" должны быть корректно представленные значения собственного типа BioAPI_OPTIONS_MASK (см. 9.2.3.4). Входящими значениями должны быть стандартно представленные значения этого типа (см. 9.2.3.5).

9.2.10.3.10 Исходящими значениями PayloadPolicy, DefaultVerifyTimeout, DefaultldentifyTimeout, DefaultCaptureTimeout, DefaultEnrollTimeout и DefaultCalibrateTimeout должны быть или корректно представленные целые числа (см. 7.4) в интервале от минус 2147483648 до плюс 2147483647, или пустые строки. Входящими значениями должны быть стандартно представленные целые числа (см. 7.4.3) в том же интервале.

9.2.10.4 Значение (например, V) собственного типа BioAPI_BSP_SCHEMA, представленное исходящим значением этой группы параметров, определяют в соответствии с 9.2.10.4.1-9.2.10.4.8.

9.2.10.4.1 УУИД, представленный исходящим значением BSPUuid (или УУИД "00000000-0000-0000-0000-000000000000", если исходящим значением является пустая строка), должен быть записан в поле значения V с тем же именем.

9.2.10.4.2 Строки символов, которые являются исходящими значениями Description, ProductVersion и Vendor должны быть записаны в поле V с тем же именем, заканчивающимся символом конца строки NUL (0).

9.2.10.4.3 Строка символов, которая является выходным значением Path, должна быть записана в блок памяти достаточного объема, адрес которого должен быть записан в поле Path значения V.

9.2.10.4.4 Целые числа, представленные исходящими значениями SpecVersion, NumSupportedFormats, PayloadPolicy, MaxPayloadSize, DefaultVerify Timeout, DefaultldentifyTimeout, DefaultCaptureTimeout, DefaultEnrollTimeout, DefaultCalibrateTimeout, MaxBSPDbSize и Maxldentify (или 0, если исходящими значениями являются пустые строки) должно быть записано в поле значения V с тем же именем.

9.2.10.4.5 Целые числа, представленные исходящими значениями Format_X_FormatOwner и Format_X_FormatType (где X=1, 2, 3 или 4), или 0, если исходящими значениями являются пустые строки, должны быть записаны в поля FormatOwner и FormatType (соответственно) элемента в позиции X массива четырех элементов типа BioAPI_BIR_BIOMETRIC_DATA_FORMAT. Адрес этого массива должен быть записан в поле BSPSupportedFormats значения V.

9.2.10.4.6 Значение типа BioAPI_BIR_BIOMETRIC_TYPE, представленное (см. 9.2.1.4) исходящим значением группы параметров "Биометрический тип", должно быть записано в поле FactorsMask значения V.

9.2.10.4.7 Значение типа BioAPI_OPERATIONS, представленное (см. 9.2.2.4) исходящим значением группы параметров "Операции", должно быть записано в поле Operations значения V.

9.2.10.4.8 Значение типа BioAPI_OPTIONS, представленное (см. 9.2.3.4) исходящим значением группы параметров "Опции", должно быть записано в поле Options значения V.

9.2.10.5 Если задано значение (например, V) собственного типа BioAPI_BSP_SCHEMA, то входящее значение этой группы параметров, которое канонически представляет V, следует определять в соответствии с 9.2.10.5.1-9.2.10.5.8.

9.2.10.5.1 Входящим значением BSPUuid должен быть стандартно представленный (см. 7.6.3) УУИД в поле значения V с тем же именем.

9.2.10.5.2 Входящие значения Description, ProductVersion и Vendor должны представлять собой строки символов в поле значения V с тем же именем.

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

9.2.10.5.4 Входящими значениями SpecVersion, NumSupportedFormats, PayloadPolicy, MaxPayloadSize, DefaultVerifyTimeout, DefaultldentifyTimeout, DefaultCaptureTimeout, DefaultEnrollTimeout, DefaultCalibrateTimeout, MaxBSPDbSize и Maxldentify должны быть стандартно представленные целые числа в поле значения V с тем же именем.

9.2.10.5.5 Входящие значения Format_X_FormatOwner и Format_X_FormatType (где X=1, 2, 3 или 4) определяют следующим образом. Если поле BSPSupportedFormats значения V содержит NULL-значение или поле NumSupportedFormats значения V содержит значение меньше X, то входящим значением должна быть пустая строка. В противном случае входящим значением должно быть стандартно представленное целое число в полях FormatOwner и FormatType (соответственно) элемента в позиции X массива типа BioAPI_BIR_BIOMETRIC_DATA_FORMAT, на которую указывает поле BSPSupportedFormats значения V.

9.2.10.5.6 Входящими значениями группы параметров "Биометрический тип" должны быть стандартно представленные (см. 9.2.1.5) значения типа BioAPI_BIR_BIOMETRIC_TYPE в поле FactorsMask значения V.

9.2.10.5.7 Входящими значениями группы параметров "Операции" должны быть стандартно представленные (см. 9.2.2.5) значения типа BioAPI_OPERATIONS в поле Operations значения V.

9.2.10.5.8 Входящими значениями группы параметров "Опции" должны быть стандартно представленные (см. 9.2.3.5) значения типа BioAPI_OPTIONS в поле Options значения V.

9.2.11 Группа параметров "Схема ПБФ"

9.2.11.1 Группа параметров "Схема ПБФ" включает в себя следующие параметры:

- BFPUuid;

- BFPCategory;

- BFPDescription;

- Path;

- SpecVersion;

- ProductVersion;

- Vendor;

- Format_1_FormatOwner;

- Format_1_FormatType;

- Format_2_FormatOwner;

- Format_2_FormatType;

- Format_3_FormatOwner;

- Format_3_FormatType;

- Format_4_FormatOwner;

- Format_4_FormatType;

- NumSupportedFormats;

- элементы группы параметров "Биометрический тип" (см. 9.2.1);

- BFPPropertylD;

- BFPProperty.

9.2.11.2 Эта группа параметров поддерживает представление значений собственного типа BioAPI_BFP_SCHEMA.

9.2.11.3 У элементов данной группы параметров должны быть входящие и исходящие значения, соответствующие приведенным в 9.2.11.3.1-9.2.11.3.8.

9.2.11.3.1 Исходящими значениями BFPUuid и BFPPropertylD должны быть или корректно представленные УУИД (см. 7.6), или пустые строки. Входящими значениями должны быть стандартно представленные УУИД (см. 6.3).

9.2.11.3.2 Исходящими значениями BFPCategory и NumSupportedFormats должны быть или корректно представленные целые числа в интервале от 0 до 4294967295, или пустые строки. Входящими значениями должны быть стандартно представленные целые числа в том же интервале.

9.2.11.3.3 Исходящие или входящие значения BFPDescription, ProductVersion и Vendor должны представлять собой строки символов, кодировка UTF-8 которых не должна быть длиннее 268 байтов и которые не должны содержать символов NUL (0).

9.2.11.3.4 Исходящее или входящее значение Path должно представлять собой строку символов, не содержащую символов NUL (0).

9.2.11.3.5 Исходящим значением SpecVersion должно быть или корректно представленное целое число в интервале от 0 до 255, или пустая строка. Входящим значением должно быть стандартно представленное целое число в том же интервале.

9.2.11.3.6 Исходящими значениями Format_X_FormatOwner и Format_X_FormatType (где X=1, 2, 3 или 4) должны быть или корректно представленные целые числа (см. 7.4) в интервале от 0 до 65535, или пустые строки. Входящими значениями должны быть стандартно представленные целые числа (см. 7.4.3) в том же интервале или пустые строки.

9.2.11.3.7 Исходящими значениями группы параметров "Биометрический тип" должны быть корректно представленные значения собственного типа BioAPI_BIR_DATA_TYPE (см. 9.2.5.4). Входящими значениями должны быть стандартно представленные значения этого типа (см. 9.2.5.5).

9.2.11.3.8 Исходящим значением BFPProperty должен быть корректно представленный набор байтов (см. 7.7). Входящим значением должен быть стандартно представленный набор байтов (см. 7.7.2).

9.2.11.4 Значение (например, V) собственного типа BioAPI_BFP_SCHEMA, представленное исходящим значением этой группы параметров, определяют в соответствии с 9.2.11.4.1-9.2.11.4.8.

9.2.11.4.1 УУИД, представленный исходящим значением BSPUuid и BFPPropertylD (или УУИД "00000000-0000-0000-0000-000000000000", если исходящим значением является пустая строка) должен быть записан в поле значения V с тем же именем.

9.2.11.4.2 Целые числа, представленные исходящими значениями BFPCategory, и NumSupportedFormats (или 0, если исходящими значениями являются пустые строки), должны быть записаны в поле значения V с тем же именем.

9.2.11.4.3 Строки символов, являющиеся исходящими значениями BFPDescription, ProductVersion и Vendor должны быть записаны в поле значения V с теми же именами, заканчивающимися символом конца строки NUL (0).

9.2.11.4.4 Строка символов, которая является выходным значением Path, должна быть записана с символом NUL (0) в конце в блок памяти достаточного объема, адрес которого должен быть вписан в поле Path значения V.

9.2.11.4.5 Целое число, представленное исходящим значением SpecVersion (или 0, если исходящим значением является пустая строка), должно быть записано в поле значения V с тем же именем.

9.2.11.4.6 Целые числа, представленные исходящими значениями Format_X_FormatOwner и Format_X_FormatType (где X=1, 2, 3 или 4), или 0, если исходящим значением является пустая строка, должны быть записаны в поля FormatOwner и FormatType (соответственно) элемента в позиции X массива четырех элементов типа BioAPI_BIR_BIOMETRIC_DATA_FORMAT. Адрес этого массива должен быть записан в поле BFPSupportedFormats значения V.

9.2.11.4.7 Значение типа BioAPI_BIR_BIOMETRIC_TYPE, представленное (см. 9.2.1.4) исходящим значением группы параметров "Биометрический тип", должно быть записано в поле FactorsMask значения V.

9.2.11.4.8 Набор байтов, представленный исходящим значением BFPProperty, должен быть записан в блок памяти достаточного объема. Адрес и длина блока памяти должны быть записаны в поля Data и Length (соответственно) переменной типа BioAPI_DATA, адрес которой должен быть записан в поле BFPProperty значения V.

9.2.11.5 Если задано значение (например, V) собственного типа BioAPI_BFP_SCHEMA, то входящее значение этой группы параметров, которое канонически представляет значение V, следует определять в соответствии с 9.2.11.5.1-9.2.11.5.8.

9.2.11.5.1 Входящими значениями BFPUuid и BFPPropertylD должны быть стандартно представленные (см. 7.6.3) УУИД в поле значения V с тем же именем.

9.2.11.5.2 Входящими значениями BFPCategory и NumSupportedFormats должны быть стандартно представленные целые числа в поле значения V с тем же именем.

9.2.11.5.3 Входящие значения BFPDescription, ProductVersion и Vendor должны представлять собой строки символов в поле значения V с тем же именем и без символа NUL (0) в конце строки.

9.2.11.5.4 Входящее значение Path должно представлять собой строку символов, на которую указывает поле значения V с тем же именем и без символа NUL (0) в конце строки.

9.2.11.5.5 Входящим значением SpecVersion должно быть стандартно представленное целое число в поле значения V с тем же именем.

9.2.11.5.6 Входящие значения Format_X_FormatOwner и Format_X_FormatType (где X=1, 2, 3 или 4) определяют следующим образом.

Если поле BFPSupportedFormats значения V содержит значение NULL или значение поля NumSupportedFormats значения V меньше X, то входящим значением должна быть пустая строка. В противном случае входящими значениями должны быть стандартно представленные целые числа в полях FormatOwner и FormatType (соответственно) элемента в позиции X массива типа BioAPI_BIR_BIOMETRIC_DATA_FORMAT, на которую указывает поле BFPSupportedFormats значения V.

9.2.11.5.7 Входящими значениями группы параметров "Биометрический тип" должны быть стандартно представленные (см. 9.2.1.5) значения типа BioAPI_BIR_BIOMETRIC_TYPE в поле FactorsMask значения V.

9.2.11.5.8 Входящим значением BFPProperty должен быть стандартно представленный набор байтов в блоке памяти, адрес и длина которого находятся в полях Data и Length (соответственно) переменной типа BioAPI_DATA, на которую указывает поле BFPProperty значения V.

9.2.12 Группа параметров "Структура элемента"

9.2.12.1 Группа параметров "Структура элемента" включает в себя следующие параметры:

- BSPUuid;

- UnitManagerUuid;

- UnitID;

- UnitCategory;

- UnitProperties;

- Vendorlnformation;

- элементы группы параметров "События" (см. пункт 9.2.4);

- UnitPropertylD;

- UnitProperty;

- HardwareVersion;

- FirmwareVersion;

- SoftwareVersion;

- HardwareSerialNumber;

- AuthenticatedHardware;

- MaxBSPDbSize;

- Maxldentify.

9.2.12.2 Эта группа параметров поддерживает представление значений собственного типа BioAPI_UNIT_SCHEMA.

9.2.12.3 У элементов данной группы параметров должны быть входящие и исходящие значения, соответствующие приведенным в 9.2.12.3.1-9.2.12.3.6.

9.2.12.3.1 Исходящими значениями BSPUuid, UnitManagerUuid, UnitProperties и UnitPropertylD должны быть или корректно представленные УУИД (см. 7.6), или пустые строки. Входящими значениями должны быть стандартно представленные УУИД (см. 7.6.3).

9.2.12.3.2 Исходящими значениями UnitID, UnitCategory, MaxBSPDbSize и Maxldentify должны быть или корректно представленные целые числа в интервале от 0 до 4294967295, или пустые строки. Входящими значениями должны быть стандартно представленные целые числа в том же интервале.

9.2.12.3.3 Исходящие или входящие значения Vendorlnformation, HardwareVersion, FirmwareVersion, SoftwareVersion и HardwareSerialNumber должны представлять собой строки символов, кодировка UTF-8 которых не должна быть длиннее 268 байтов и которые не должны содержать символы NUL (0).

9.2.12.3.4 Исходящими значениями группы параметров "События" должны быть корректно представленные значения собственного типа BioAPI_EVENT_MASK. Входящими значениями должны быть стандартно представленные значения этого типа.

9.2.12.3.5 Исходящим значением UnitProperty должен быть корректно представленный набор байтов (см. 7.7). Входящим значением должен быть стандартно представленный набор байтов (см. 7.7.2).

9.2.12.3.6 Исходящим значением AuthenticatedHardware должно быть или корректно представленное логическое значение (см. 7.5), или пустая строка. Входящим значением должно быть стандартно представленное логическое значение (см. 7.5.2).

9.2.12.4 Значение (например, V) собственного типа BioAPI_UNIT_SCHEMA, представленное исходящим значением этой группы параметров, должно определяться в соответствии с 9.2.12.4.1-9.2.12.4.6.

9.2.12.4.1 УУИД, представленные исходящими значениями BSPUuid, UnitManagerUuid, UnitProperties и UnitPropertylD (или УУИД "00000000-0000-0000-0000-000000000000", если исходящее значение является пустой строкой) должны быть записаны в поле значения V с тем же именем.

9.2.12.4.2 Целые числа, представленные исходящими значениями UnitID, UnitCategory, MaxBSPDbSize и Maxldentify (или 0, если исходящим значением является пустая строка), должны быть записаны в поле значения V с тем же именем.

9.2.12.4.3 Значение типа BioAPI_EVENT_MASK, представленное (см. 9.2.4.4) исходящим значением группы параметров "События", должно быть записано в поле SupportedEvents значения V.

9.2.12.4.4 Строки символов, которые являются исходящими значениями Vendorlnformation, HardwareVersion, FirmwareVersion, SoftwareVersion и HardwareSerialNumber, должны быть записаны в поле значения V с тем же именем, заканчивающимся символом конца строки NUL (0).

9.2.12.4.5 Набор байтов, представленный исходящим значением UnitProperty, должен быть записан в блок памяти достаточного объема. Адрес и длина блока памяти должны быть записаны в поля Data и Length (соответственно) переменной типа BioAPI_DATA, адрес которой должен быть записан в поле UnitProperty значения V.

9.2.12.4.6 Логическое значение, представленное исходящим значением AuthenticatedHardware (или "false", если исходящим значением является пустая строка), должно быть записано в поле значения V с тем же именем.

9.2.12.5 Если задано значение (например, V) собственного типа BioAPI_UNIT_SCHEMA, то входящее значение этой группы параметров, которое канонически представляет значение V, определяют в соответствии с 9.2.12.5.1-9.2.12.5.6.

9.2.12.5.1 Входящими значениями BSPUuid, UnitManagerUuid, UnitProperties и UnitPropertylD должны быть стандартно представленные (см. 7.6.3) УУИД в поле значения V с тем же именем.

9.2.12.5.2 Входящими значениями UnitID, UnitCategory, MaxBSPDbSize и Maxldentify должны быть стандартно представленные целые числа в поле значения V с тем же именем.

9.2.12.5.3 Входящими значениями группы параметров "События" должны быть стандартно представленные (см. 9.2.1.5) значения типа BioAPI_EVENT_MASK в поле SupportedEvents значения V.

9.2.12.5.4 Входящие значения Vendorlnformation, HardwareVersion, FirmwareVersion, SoftwareVersion и HardwareSerialNumber должны представлять собой строки символов в поле V с тем же именем и без символа NUL (0) в конце строки.

9.2.12.5.5 Входящим значением UnitProperty должен быть стандартно представленный набор байтов в блоке памяти, адрес и длина которого находятся в полях Data и Length (соответственно) переменной типа BioAPI_DATA, на которую указывает поле UnitProperty значения V.

9.2.12.5.6 Входящим значением AuthenticatedHardware должно быть стандартно представленное (см. 7.5.2) логическое значение в поле значения V с тем же именем.

9.2.13 Группа параметров "Заголовок ЗБИ"

9.2.13.1 Группа параметров "Заголовок ЗБИ" включает в себя следующие параметры:

- HeaderVersion;

- элементы группы параметров "Тип биометрических данных" (см. 9.2.5);

- FormatOwner;

- FormatType;

- Quality;

- Purpose;

- элементы группы параметров "Биометрический тип" (см. 9.2.1);

- ProductOwner;

- ProductType;

- элементы группы параметров "Дата и время" (см. 9.2.8), с именами, начинающимися с "Creation_";

- элементы группы параметров "Биометрический подтип" (см. 9.2.6);

- элементы группы параметров "Дата" (см. 9.2.7) с именами, начинающимися с "Expiration_";

- SBFormatOwner;

- SBFormatType;

- Index.

9.2.13.2 Эта группа параметров поддерживает представление значений собственного типа BioAPI_BIR_HEADER.

9.2.13.3 У элементов данной группы параметров должны быть входящие и исходящие значения, соответствующие приведенным в 9.2.13.3.1-9.2.13.3.9.

9.2.13.3.1 Исходящими значениями HeaderVersion и Purpose должны быть или корректно представленные целые числа в интервале от 0 до 255, или пустые строки. Входящими значениями должны быть стандартно представленные целые числа в том же интервале.

9.2.13.3.2 Исходящими значениями группы параметров "Тип биометрических данных" должны быть корректно представленные значения собственного типа BioAPI_BIR_DATA_TYPE. Входящими значениями должны быть стандартно представленные значения этого типа.

9.2.13.3.3 Исходящими значениями FormatOwner, FormatType, ProductType, SBFormatOwner и SBFormatType должны быть или корректно представленные целые числа в интервале от 0 до 65535, или пустые строки. Входящими значениями должны быть стандартно представленные целые числа в том же интервале.

9.2.13.3.4 Исходящим значением Quality должно быть или корректно представленное целое число в интервале от минус 128 до плюс 127, или пустая строка. Входящим значением должно быть стандартно представленное целое число в том же интервале.

9.2.13.3.5 Исходящими значениями группы параметров "Биометрический тип" должны быть корректно представленные значения собственного типа BioAPI_BIR_BIOMETRIC_TYPE. Входящими значениями должны быть стандартно представленные значения этого типа.

9.2.13.3.6 Исходящими значениями группы параметров "Дата и время" должны быть корректно представленные значения собственного типа BioAPI_DTG. Входящими значениями должны быть стандартно представленные значения этого типа.

9.2.13.3.7 Исходящими значениями группы параметров "Биометрический подтип" должны быть корректно представленные значения собственного типа BioAPI_BIR_SUBTYPE. Входящими значениями должны быть стандартно представленные значения этого типа.

9.2.13.3.8 Исходящими значениями группы параметров "Дата" должны быть корректно представленные значения собственного типа BioAPI_DATE. Входящими значениями должны быть стандартно представленные значения этого типа.

9.2.13.3.9 Исходящим значением Index должен быть или корректно представленный УУИД (см. 7.6), или пустая строка. Входящим значением должен быть стандартно представленный УУИД (см. 7.6.3).

9.2.13.4 Значение (например, V) собственного типа BioAPI_BIR_HEADER, представленное исходящим значением этой группы параметров, определяют в соответствии с 9.2.13.4.1-9.2.13.4.10.

9.2.13.4.1 Целые числа, представленные исходящими значениями HeaderVersion, Quality и Purpose (или 0, если исходящим значением является пустая строка), должны быть записаны в поле значения V с тем же именем.

9.2.13.4.2 Значение типа BioAPI_BIR_DATA_TYPE, представленное (см. 9.2.5.4) исходящим значением группы параметров "Тип биометрических данных", должно быть записано в поле Туре значения V.

9.2.13.4.3 Целые числа, представленные исходящими значениями FormatOwner и FormatType (или 0, если исходящим значением является пустая строка), должны быть записаны в поля FormatOwner и FormatType (соответственно) поля Format значения V.

9.2.13.4.4 Значение типа BioAPI_BIR_BIOMETRIC_TYPE, представленное (см. 9.2.1.4) исходящим значением группы параметров "Биометрический тип", должно быть записано в поле FactorsMask значения V.

9.2.13.4.5 Целые числа, представленные исходящими значениями ProductOwner и ProductType (или 0, если исходящим значением является пустая строка), должны быть записаны в поля ProductOwner и ProductType (соответственно) поля ProductID значения V.

9.2.13.4.6 Значение типа BioAPI_DTG, представленное (см. 9.2.8.4) исходящим значением группы параметров "Дата и время" (с префиксом "Creation_"), должно быть записано в поле CreationDTG значения V.

9.2.13.4.7 Значение типа BioAPI_BIR_SUBTYPE, представленное (см. 9.2.6.4) исходящим значением группы параметров "Биометрический подтип", должно быть записано в поле Subtype значения V.

9.2.13.4.8 Значение типа BioAPI_DATE, представленное (см. 9.2.7.4) исходящим значением группы параметров "Дата" (с префиксом "Expiration_"), должно быть записано в поле ExpirationDate значения V.

9.2.13.4.9 Целые числа, представленные исходящими значениями SBFormatOwner и SBFormatType (или 0, если исходящим значением является пустая строка), должны быть записаны в поля SecurityFormatOwner и Security FormatType (соответственно) поля SBFormat значения V.

9.2.13.4.10 УУИД, представленный исходящим значением Index (или УУИД "00000000-0000-0000-0000-000000000000", если исходящим значением является пустая строка), должен быть записан в поле значения V с тем же именем.

9.2.13.5 Если задано значение (например, V) собственного типа BioAPI_BIR_HEADER, то входящее значение этой группы параметров, которое канонически представляет значение V, определяют в соответствии с 9.2.13.5.1-9.2.13.5.2.

9.2.13.5.1 Входящими значениями HeaderVersion, Quality и Purpose должны быть стандартно представленные целые числа в поле значения V с тем же именем.

9.2.13.5.2 Входящими значениями группы параметров "Тип биометрических данных" должны быть стандартно представленные (см. 9.2.5.5) значения типа BioAPI_BIR_DATA_TYPE в поле Туре значения V.

9.2.13.5.3 Входящими значениями FormatOwner и FormatType должны быть стандартно представленные целые числа в полях FormatOwner и FormatType (соответственно) поля Format значения V.

9.2.13.5.4 Входящим значением группы параметров "Биометрический тип" должно быть стандартно представленное (см. 9.2.1.5) значение типа BioAPI_BIR_BIOMETRIC_TYPE в поле FactorsMask значения V.

9.2.13.5.5 Входящими значениями ProductOwner и ProductType должны быть стандартно представленные целые числа в полях ProductOwner и ProductType (соответственно) поля ProductID значения V.

9.2.13.5.6 Входящими значениями группы параметров "Дата и время" (с префиксом "Creation_") должны быть стандартно представленные (см. 9.2.8.5) значения типа BioAPI_DTG в поле CreationDTG значения V.

9.2.13.5.7 Входящими значениями группы параметров "Биометрический подтип" должны быть стандартно представленные (см. 9.2.6.5) значения типа BioAPI_BIR_SUBTYPE в поле Subtype значения V.

9.2.13.5.8 Входящими значениями группы параметров "Дата" (с префиксом "Expiration_") должны быть стандартно представленные (см. 9.2.7.5) значения типа BioAPI_DATE в поле ExpirationDate значения V.

9.2.13.5.9 Входящими значениями SBFormatOwner и SBFormatType должны быть стандартно представленные целые числа в полях SecurityFormatOwner и SecurityFormatType (соответственно) поля SBFormat значения V.

9.2.13.5.10 Входящим значением Index должен быть стандартно представленный (см. 7.6.3) УУИД в поле значения V с тем же именем.

9.2.14 Группа параметров "ЗБИ"

9.2.14.1 Группа параметров "ЗБИ" включает в себя следующие параметры:

- элементы группы параметров "Заголовок ЗБИ" (см. 9.2.13);

- BiometricData;

- SecutityBlock.

9.2.14.2 Эта группа параметров поддерживает представление значений собственного типа BioAPI_BIR.

9.2.14.3 У элементов данной группы параметров должны быть входящие и исходящие значения, соответствующие приведенным в 9.2.14.3.1 и 9.2.14.3.2.

9.2.14.3.1 Исходящими значениями группы параметров "Заголовок ЗБИ" должны быть корректно представленные значения собственного типа BioAPI_BIR_HEADER. Входящими значениями должны быть стандартно представленные значения этого типа.

9.2.14.3.2 Исходящими значениями BiometricData и SecurityBlock должны быть корректно представленные наборы байтов (см. 7.7). Входящими значениями должны быть стандартно представленные наборы байтов (см. 7.7.2).

9.2.14.4 Значение (например, V) собственного типа BioAPI_BIR, представленное исходящим значением этой группы параметров, определяют в соответствии с 9.2.14.4.1-9.2.14.4.3.

9.2.14.4.1 Значение типа BioAPI_BIR_HEADER, представленное (см. 9.2.13.4) исходящим значением группы параметров "Заголовок ЗБИ", должно быть записано в поле Header значения V.

9.2.14.4.2 Набор байтов, представленный исходящим значением BiometricData, должен быть записан в блок памяти достаточного объема. Адрес и длина блока памяти должны быть записаны в поля Data и Length (соответственно) поля BiometricData значения V.

9.2.14.4.3 Набор байтов, представленный исходящим значением SecurityBlock, должен быть записан в блок памяти достаточного объема. Адрес и длина блока памяти должны быть записаны в поля Data и Length (соответственно) поля SecurityBlock значения V.

9.2.14.5 Если задано значение (например, V) собственного типа BioAPI_BIR, то входящее значение этой группы параметров, которое канонически представляет значение V, определяют в соответствии с 9.2.14.5.1-9.2.14.5.3.

9.2.14.5.1 Входящими значениями группы параметров "Заголовок ЗБИ" должны быть стандартно представленные (см. 9.2.13.5) значения типа BioAPI_BIR_HEADER в поле Header значения V.

9.2.14.5.2 Входящим значением BiometricData должен быть стандартно представленный набор байтов в блоке памяти, адрес и длина которого находятся в полях Data и Length (соответственно) поля BiometricData значения V.

9.2.14.5.3 Входящим значением SecurityBlock должен быть стандартно представленный набор байтов в блоке памяти, адрес и длина которого находятся в полях Data и Length (соответственно) поля SecurityBlock значения V.

9.2.15 Группа "Входные параметры ЗБИ"

9.2.15.1 Группа "Входные параметры ЗБИ" включает в себя следующие параметры:

- Form;

- DbHandle;

- KeyValue;

- BIRHandle;

- элементы группы параметров "ЗБИ" (см. 9.2.14).

9.2.15.2 Эта группа параметров поддерживает представление значений собственного типа BioAPI_INPUT_BIR.

9.2.15.3 У элементов данной группы параметров должны быть входящие и исходящие значения, соответствующие приведенным в 9.2.15.3.1-9.2.15.3.4.