---

ПРИЛОЖЕНИЕ

СЪДЪРЖАНИЕ
ГЛАВА 1:	Обмен на ДНК данни
1.	Свързани с ДНК криминалистични въпроси, правила и алгоритми за сравняване
1.1.	Свойства на ДНК профилите
1.2.	Правила за сравняване
1.3.	Правила за съобщаване на резултатите
2.	Таблица на кодовите номера на държавите-членки
3.	Функционален анализ
3.1.	Наличност на системата
3.2.	Втори етап
4.	Документ за контрол на интерфейса при обмен на ДНК данни
4.1.	Въведение
4.2.	Дефиниране на XML-структурата
5.	Архитектура на приложението, сигурността и комуникациите
5.1.	Обзорен преглед
5.2.	Архитектура на горното ниво
5.3.	Стандарти за сигурност и защита на данните
5.4.	Протоколи и стандарти, които да се използват за механизма за криптиране sMIME и свързани пакети
5.5.	Архитектура на приложението
5.6.	Протоколи и стандарти, които да се използват за архитектурата на приложението
5.7.	Комуникационна среда
ГЛАВА 2:	Обмен на дактилоскопични данни (документ за контрол на интерфейса)
1.	Обзор на съдържанието на файловете
2.	Формат на записите
3.	Логически запис тип-1: заглавна част на файла
4.	Логически запис тип-2: описателен текст
5.	Логически запис тип-4: изображение с висока резолюция в сивата скала
6.	Логически запис тип-9: запис на признаци (minutiae)
7.	Запис тип-13 на изображение на следи с променлива резолюция
8.	Запис тип-15 на изображение на отпечатък от длан с променлива резолюция
9.	Допълнения към глава 2 (обмен на дактилоскопични данни)
9.1.	ASCII разделителни кодове
9.2.	Изчисляване на буквено-цифровия контролен символ
9.3.	Символни кодове
9.4.	Кратко описание на транзакция
9.5.	Дефиниции на запис тип-1
9.6.	Дефиниции на запис тип-2
9.7.	Кодове за компресия в сивата скала
9.8.	Спецификация на съобщенията
ГЛАВА 3:	Обмен на данни за регистрацията на превозни средства
1.	Общ набор от данни за автоматизирано търсене на данни за регистрацията на превозни средства
1.1.	Определения
1.2.	Търсене на превозно средство/собственик/ползвател
2.	Сигурност на данните
2.1.	Обзорен преглед
2.2.	Характеристики на сигурността, свързани с обмена на съобщения
2.3.	Характеристики на сигурността, несвързани с обмена на съобщения
3.	Технически условия на обмена на данните
3.1.	Общо описание на приложението EUCARIS
3.2.	Функционални и нефункционални изисквания
ГЛАВА 4:	Оценяване
1.	Процедура за оценяване съгласно член 20 (подготовка на решения в съответствие с член 25, параграф 2 от Решение 2008/615/ПВР)
1.1.	Въпросник
1.2.	Пилотно изпитване
1.3.	Посещение за оценка
1.4.	Докладване на Съвета
2.	Процедура за оценяване съгласно член 21
2.1.	Статистика и доклад
2.2.	Преразглеждане
3.	Експертни заседания

ГЛАВА 1: Обмен на ДНК данни

1.   Свързани с ДНК криминалистични въпроси, правила и алгоритми за сравняване

1.1.   Свойства на ДНК профилите

ДНК профилът може да съдържа 24 двойки числа, представляващи алелите на 24-те локуса, които също се използват в ДНК процедурите на Интерпол. Наименованията на тези локуси са показани в следната таблица:

Седемте отбелязани в сиво локуса на най-горния ред представляват както настоящия европейски стандартен набор от локуси (ESS), така и стандартния набор на Интерпол от локуси (ISSOL).

Правила за включване:

ДНК профилите, до които държавите-членки предоставят достъп с цел търсене и сравняване, както и ДНК профилите, изпращани с цел търсене и сравняване, трябва да съдържат поне 6 изцяло обозначени ( 1 ) локуса, като могат да съдържат допълнителни локуси или непопълнени такива в зависимост от наличността им. Референтните ДНК профили трябва да съдържат поне 6 от седемте локуса на ESS. За да се повиши точността на съвпаденията, всички налични алели се съхраняват в индексираната база данни с ДНК профили и се използват за търсене и сравняване. Всяка държава-членка следва да приложи в най-краткия практически възможен срок всеки нов вариант на ESS от локуси, приет от ЕС.

Не се допускат смесени профили, така че алелните стойности на всеки локус ще се състоят само от 2 цифри, които могат да бъдат еднакви при наличие на хомозиготност в даден локус.

При заявка за търсене с неизвестна стойност „жокер“ („wild-cards“) или с микроварианти се спазват следните правила:

1.2.   Правила за сравняване

Сравняването на 2 ДНК профила се извършва въз основа на локусите, за които и в двата ДНК профила е налице една и съща алелна двойка. В двата ДНК профила трябва да има съвпадение на поне 6 изцяло обозначени локуса (без амелогенин), преди да се изпрати отговор за наличие на съвпадение.

Пълно съвпадение (качество 1) се определя като съвпадение, когато са еднакви всички алелни стойности на сравняваните локуси, обикновено съдържащи се в искането и отговора на справка за ДНК профили. Близко съвпадение се определя като съвпадение, при което е налице различна стойност само за една от всичките сравнявани алели в двата ДНК профила (качества 2, 3 и 4). Приема се, че има близко съвпадение, само ако в двата сравнявани ДНК профила е налице съвпадение на поне 6 изцяло обозначени локуса.

Причините за близко съвпадение могат да бъдат следните:

1.3.   Правила за съобщаване на резултатите

Съобщават се както пълните, така и близките съвпадения и липсата на съвпадение.

Съобщението за резултатите се изпраща на националната точка за контакт, отправила искането, като се предоставя на разположение и на националната точка за контакт, до която е отправено искането (за да може тя да прецени естеството и броя на евентуалните следващи искания за допълнителни налични лични данни и друга информация, която е свързана с ДНК профила, съответстващ на съвпадението в съответствие с членове 5 и 10 от Решение 2008/615/ПВР).

2.   Таблица на кодовите номера на държавите-членки

В съответствие с Решение 2008/615/ПВР за определяне на наименованията на домейни, както и за другите конфигуративни параметри, които се изискват от приложенията за обмен на ДНК данни по защитени мрежи съгласно договореностите от Прюм, се използва кодиране по стандарта ISO 3166-1 alpha-2.

Кодовете по ISO 3166-1 alpha-2 са следните двубуквени кодове за държавите-членки.

3.   Функционален анализ

3.1.   Наличност на системата

Исканията по член 3 от Решение 2008/615/ПВР следва да пристигат в съответната база данни по хронологичен ред съгласно реда им на изпращане, а отговорите следва да се изпращат така че да пристигат в поискалата ги държава-членка в 15-минутен срок от пристигането на искането.

3.2.   Втори етап

Когато държава-членка получи съобщение за съвпадение, нейната национална точка за контакт отговаря за сравняването на стойностите на профила, предаден като запитване, и стойностите на профила(ите), получени като отговор, за да валидира и провери доказателствената стойност на профила. Националните точки за контакт могат да осъществяват пряк контакт помежду си с цел валидиране.

Процедурите за правна помощ започват след валидирането на съществуващо съвпадение между два профила, въз основа на получените по време на фазата за автоматизирано консултиране съобщения за „пълно съвпадение“ и „близко съвпадение“.

4.   Документ за контрол на интерфейса при обмен на ДНК данни

4.1.   Въведение

4.1.1.    Цели

В тази глава се определят изискванията за обмена на информация за ДНК профили между системите от ДНК бази данни на всички държави-членки. Полетата в заглавната част са дефинирани специално за целите на обмена на ДНК данни по линия на Прюм, а съдържащата данните част е разработена на базата на частта за данните за ДНК профили в XML-схемата, дефинирана за електронния портал на Интерпол за обмен на ДНК данни.

Данните се обменят чрез SMTP (Simple Mail Transfer Protocol) и други модерни технологии, като се използва сървър за централизирано предаване на съобщенията, предоставен от доставчика на мрежови услуги. XML-файлът се транспортира в съдържателната част на съобщението.

4.1.2.    Обхват

Този ICD определя само съдържанието на съобщението. Всички специфични за мрежата и съобщението въпроси, се дефинират еднообразно, за да се осигури обща техническа база за обмен на ДНК данни.

Това включва:

4.1.3.    XML-структура и принципи

Съобщението във XML-формат е структурирано в:

За исканията и за отговорите се използва една и съща XML-схема.

За да могат да се правят изчерпателни проверки на неидентифицирани ДНК профили (член 4 от Решение 2008/615/ПВР), е възможно да се изпращат по няколко профила в едно съобщение. Максималният брой на профилите в едно съобщение трябва да бъде определен. Броят им зависи от максималния допустим размер на съобщенията и се определя след избора на пощенски сървър.

XML пример:

<?version="1.0" standalone="yes"?>

<PRUEMDNAx xmlns:msxsl="urn:schemas-microsoft-com:xslt"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<header>

(…)

</header>

<datas>

(…)

</datas>

[<datas> структурата на данните се повтаря, когато се изпращат повече профили (….) в едно SMTP-съобщение, разрешено само за случаите по член 4

</datas>]

</PRUEMDNA>

4.2.   Дефиниране на XML-структурата

Следните дефиниции са само за целите на документирането и по-добрата четивност, а информацията със задължителен характер се дава във файла с XML-схема (PRUEM DNA.xsd).

4.2.1.    Схема PRUEMDNAx (Schema PRUEMDNAx)

Тази схема съдържа следните полета:

4.2.2.    Съдържание на заглавната структура

Тази структура описва заглавната част на XML-файла. Тя съдържа следните полета:

Тип данни, съдържащи се в съобщението — възможни стойности:

Структура, описваща държавата-членка и датата/часа на съобщението. Съдържа следните полета:

4.2.3.    Съдържание на данните за профили по линия на Прюм (PRUEM Profile data)

Тази структура описва частта за данни за профила на XML-файла. Съдържа следните полета:

Тип данни, съдържащи се в съобщението — възможни стойности:

Тип данни, съдържащи се в съобщението — възможни стойности:

Тип данни, съдържащи се в съобщението — възможни стойности:

Структура, описваща ДНК профил. Съдържа следните полета:

Структура, съдържаща локусите на ISSOL (стандартния набор на Интерпол от локуси). Съдържа следните полета:

Структура, съдържаща другите локуси. Съдържа следните полета:

Структура, описваща локус. Съдържа следните полета:

5.   Архитектура на приложението, сигурността и комуникациите

5.1.   Обзорен преглед

При внедряването на приложенията за обмен на ДНК данни в рамките на Решение 2008/615/ПВР се използва обща комуникационна мрежа, която е логически затворена между държавите-членки. С цел експлоатиране по по-ефективен начин на тази обща комуникационна инфраструктура за изпращане на искания и получаване на отговори се възприема асинхронен механизъм за предаване на исканията за ДНК данни и дактилоскопични данни в капсулирани SMTP-електронни съобщения. С цел да се удовлетворят изискванията за сигурност, като разширение на SMTP-функционалността ще се използва механизъм sMIME, за да се установи действително затворен сигурен „тунел“ за работата в мрежата.

Оперативната TESTA (трансевропейски телематични услуги между администрациите) се използва за комуникационна мрежа за обмена на данни между държавите-членки. TESTA се управлява от Европейската комисия. С оглед на факта, че националните ДНК бази данни и действащите национални точки за достъп до TESTA могат да бъдат разположени на различни места в държавите-членки, достъпът до TESTA може да се осигури, като:

Протоколите и стандартите, внедрени в приложенията, използвани за изпълнението на Решение 2008/615/ПВР, съответстват на отворените стандарти и отговарят на изискванията, наложени от органите, определящи националната политиката по отношение на сигурността в държавите-членки.

5.2.   Архитектура на горното ниво

В обхвата на Решение 2008/615/ПВР всяка държава-членка ще прави налични нейните ДНК данни за целите на обмена на такива данни и/или търсения в тях от други държави-членки в съответствие със стандартизирания общ формат на данните. Архитектурата е снована на комуникационен модел, при който се осъществява връзка „от всеки до всеки“. Не съществува централен компютърен сървър, нито централизирана база данни за съхранение на ДНК профили.

Фигура 1: Топология на обмена на ДНК данни

Освен спазването на националните правни ограничения, касаещи съответните обекти в държавите-членки, всяка държава-членка може да реши какъв вид хардуер и софтуер следва да се внедри за конфигуриране в съответния обект, така че да са спазени изискванията на Решение 2008/615/ПВР.

5.3.   Стандарти за сигурност и защита на данните

Три са нивата на сигурност, които са взети под внимание и са въведени.

5.3.1.    На ниво данни

Предоставяните от държавите-членки данни за ДНК профили трябва да се изготвят в съответствие с общите стандарти за защита на данните, така че отправилата искането държава-членка да получи отговор, в който основно се посочва наличие на попадение или липса на попадение (HIT/NO-HIT) заедно с идентификационен номер в случай на попадение, но в него не се съдържа никаква лична информация. По-нататъшното разследване след уведомяване за наличие на попадение се води на двустранно равнище съгласно съществуващите национални правни и организационни разпоредби, уреждащи съответните обекти в държавите-членки.

5.3.2.    На ниво комуникация

Съобщенията, съдържащи информация за ДНК профили (искания и отговори), се криптират посредством най-модерен механизъм в съответствие с отворените стандарти, като sMIME, преди да се изпратят в съответните обекти в държавите-членки.

5.3.3.    На ниво предаване

Всички криптирани съобщения, съдържащи информация за ДНК профили, се изпращат в обектите на другите държави-членки посредством виртуална частна тунелираща система администрирана от надежден доставчик на мрежови услуги на национално равнище и връзките за сигурност към тази тунелираща система са под национално управление. Виртуалната частна тунелираща система няма никакъв точка на контакт с откритата интернет мрежа.

5.4.   Протоколи и стандарти, които да се използват за механизма за криптиране sMIME и свързани пакети

Отвореният стандарт sMIME, като разширение на действащия de facto стандарт за електронна поща SMTP, ще се внедри за криптиране на съобщения, съдържащи информация за ДНК профили. Протоколът sMIME (V3) позволява електронно подписана разписка, етикети за сигурност и защитени списъци с електронни адреси (mailing lists), като е базиран върху „пласта“ на Cryptographic Message Syntax (CMS), IETF спецификация за защитени чрез криптиране съобщения. Той може да се използва за електронно подписване, резюмиране, автентификация или криптиране на всякакви форма цифрови данни.

Сертификатът, на базата на който се прилага механизмът sMIME, трябва да съответства на стандарта X.509. С цел да се осигурят стандарти и процедури, които са общи с тези за други приложения, използвани по линия на Прюм, правилата за обработване за операциите по криптиране на базата на sMIME или за прилагане в различни видове среда на базата на готови търговски продукти (Commercial Product of the Shelves — COTS), са следните:

Функционалността s/MIME е вградена в повечето съвременни софтуерни пакети за електронна поща, в т.ч. Outlook, Mozilla Mail и Netscape Communicator 4.x, като позволява оперативна съвместимост между повечето основни софтуерни пакети за електронна поща.

Поради лесното интегриране на sMIME в националната ИТ инфраструктура във всички държави-членки, този механизъм е избран като подходящ с цел осигуряване на сигурността на ниво комуникации. С цел по-ефикасен „тест на концепцията“ („Proof of Concept“) и намаляване на разходите обаче е избран стандартът JavaMail API, с който да се извърши прототипирането на обмена на ДНК данни. JavaMail API предоставя елементарно криптиране и декриптиране на електронни съобщения посредством s/MIME и/или OpenPGP. Целта е да се осигури прост и лесен за употреба програмно-приложен интерфейс (API) за клиентите на електронна поща, които желаят да изпращат и получават криптирани електронни съобщения в един от двата най-популярни формата за криптиране на електронни съобщения. Следователно, за да са изпълнени изискванията на Решение 2008/615/ПВР, ще е достатъчно високотехнологично внедряване на базата на JavaMail API, като например продуктът на Bouncy Castle JCE (Java Cryptographic Extension), който ще се използва за въвеждането на sMIME за прототипирането на обмена на ДНК данни между държавите-членки.

5.5.   Архитектура на приложението

Всяка държава-членка ще предостави на другите държави-членки набор от стандартизирани данни за ДНК профили, които съответстват на използвания в момента общ документ за контрол на интерфейса (ICD). Това може да стане или чрез предоставяне на логически поглед върху индивидуалната национална база данни, или чрез установяване на физически експортирана база данни (индексирана база данни).

Четирите основни компонента: сървърът за електронна поща/sMIME, сървърът за приложението, зоната на структурирани данни (Data Structure Area) за извличане/подаване на данни и регистрация на входящите/изходящите съобщения, както и търсачката за стравняване, внедряват цялостната логика на приложението по начин, който не зависи от конкретните продукти.

За да се осигури на всички държави-членки възможност да интегрират лесно тези компоненти в съответните си национални обекти, конкретно определената обща функционалност е внедрена посредством компоненти с отворен код, които могат да се избират от всяка държава-членка в зависимост от нейната национална политика и уредба в областта на ИТ. Поради независимите характеристики на внедряваната система за получаване на достъп до индексирани бази данни с ДНК профили, обхванати от Решение 2008/615/ПВР, всяка държава-членка може свободно да избира собствената си хардуерна и софтуерна платформа, включително системите за бази данни и операционните системи.

Прототипът за обмена на ДНК данни е разработен и успешно изпитан в съществуващата обща мрежа. Вариант 1.0 е внедрен в работната среда и се използва за ежедневната дейност. Държавите-членки могат да използват разработения съвместно продукт, но също така могат да разработят свои продукти. Компонентите на общия продукт ще се поддържат, приспособяват и доразвиват в съответствие с изменящите се изисквания за функционалност по отношение на ИТ, криминалистиката и/или полицейската работа.

Фигура 2: Обща топология на приложението

5.6.   Протоколи и стандарти, които да се използват за архитектурата на приложението

5.6.1.    XML

Обменът на ДНК данни ще използва изцяло XML-схемата като ги прикачва към SMTP-електронни съобщения. Езикът XML (eXtensible Markup Language) се препоръчва от консорциума World Wide Web (W3C) като общофункционален метаезик за създаване на специализирани метаезици, способни да описват множество различни видове данни. Описанието на ДНК профила, който е подходящ за обмен между всички държави-членки, е изготвено посредством XML и XML-схема в ICD.

5.6.2.    ODBC

ODBC (Open DataBase Connectivity) предоставя стандартен софтуерен API метод за достъп до системи за управление на бази данни, който е независим от езиците за програмиране, от системите за базите данни и операционните системи. ODBC обаче си има своите недостатъци. Администрирането на голям брой клиентски машини може да е свързано с разнообразие на драйверите и DLL файловете. Това усложнение може да повиши разходите за администриране на системата.

5.6.3.    JDBC

JDBC (Java DataBase Connectivity) представлява API за програмния език Java, който определя какъв достъп има клиентът до базата данни. За разлика от работата с ODBC, при JDBC не се изисква да се използва даден набор от местни DLL файлове на десктопа.

Работната логика на обработката на искания и отговори за ДНК профили в съответния обект на всяка държава-членка е описана в дадената по-долу диаграма. Потоците на исканията и на отговорите взаимодействат с неутрална зона за данни, която обхваща различни масиви с еднакво структурирани данни.

Фигура 3: Обща картина на работните потоци в приложенията в съответния обект на всяка държава-членка

5.7.   Комуникационна среда

5.7.1.    Обща комуникационна мрежа: TESTA и нейната последваща инфраструктура

Приложението за обмен на ДНК данни ще използва електронната поща, асинхронен механизъм, за изпращане на искания и получаване на отговори между държавите-членки. Тъй като всички държави-членки разполагат с поне една точка за достъп до мрежата TESTA, обменът на ДНК данни ще се осъществява по мрежата TESTA. TESTA осигурява редица услуги с добавена стойност посредством своята система за предаване на електронна поща. Освен хостването на специално предназначени за TESTA електронни пощенски кутии, инфраструктурата може да работи със списъци за разпределяне на съобщения и политики за маршрутизиране. Това позволява TESTA да се използва като разпределителен център за съобщенията, адресирани до администрациите, свързани с домейните в рамките на ЕС. Възможно е също така да се включат и механизми за проверка за вируси.

Системата на TESTA за предаване на електронна поща е изградена на базата на хардуерна платформа с висока степен на наличност, която е разположена в централното приложение на TESTA и е защитена с firewall. Чрез DNS (Domain Name Services) на TESTA ще се определят ресурсните локатори за IP-адресите и ще се скрива информацията по адресирането от потребителя и от приложението.

5.7.2.    Обезпечаване на сигурността

В рамките на TESTA е приложена концепцията за VPN (Virtual Private Network). Технологията за Tag Switching, която е използвана за изграждане на тази VPN ще бъде доразвита, така че да поддържа стандарта MPLS (Multi-Protocol Label Switching), разработен от IETF (Internet Engineering Task Force).

В MPLS се съчетават ползите от маршрутизирането в пласт 3 с предимствата на суичинга в пласт 2. Тъй като на IP-адресите не се прави оценка при преминаването им през т.нар. „backbone“, MPLS не налага никакви ограничения на IP-адресирането.

Освен това електронните съобщения, предавани по TESTA, ще бъдат защитени с механизъм за криптиране на базата на sMIME. Никой не може да декриптира съобщенията по мрежата, ако не знае ключа и не разполага със съответния сертификат.

5.7.3.    Протоколи и стандарти, които да се използват в комуникационната мрежа

SMTP (Simple Mail Transfer Protocol) е действащият стандарт за пренос на електронна поща по Интернет. SMTP е относително прост текстови протокол, при който се определя един или повече получатели на съобщението, след което то се изпраща. SMTP използва TCP порт 25 по спецификациите на IETF. За да се определи SMTP сървърът за дадено име на домейн, се използва записване по MX (Mail eXchange) DNS (Domain Name Systems).

Тъй като този протокол отначало беше изцяло и само текстови на базата на ASCII, той не работеше добре с бинарни файлове. Стандарти като MIME бяха разработени, за да се кодират бинарни файлове за изпращане чрез SMTP. Днес повечето SMTP сървъри поддържат 8BITMIME и sMIME разширения, позволявайки изпращането на бинарни файлове да става почти толкова лесно, колкото и обикновен текст. Правилата за работа при операции с sMIME са описани в раздела „sMIME“ (вж. точка 5.4).

SMTP представлява push-протокол, който не позволява изтегляне на съобщения от физически отдалечен сървър по заявка. За да изтегли съобщение, клиентът на електронна поща трябва да използва POP3 или IMAP. За осъществяването на обмен на ДНК данни е решено да се използва POP3 протокол.

Местните клиенти за електронна поща използват POP3 (Post Office Protocol version 3), протокол за интернет стандарт за пласта на приложението (application-layer Internet standard protocol), за да извлекат електронното съобщение от физически отдалечен сървър по TCP/IP връзка. Като използва профила SMTP Submit на SMTP протокола, клиентът на електронна поща изпраща съобщения по интернет или по корпоративна мрежа. MIME служи за стандарт за прикрепени файлове и текст, който не е ASCII, в електронното съобщение. Въпреки че нито POP3, нито SMTP изискват електронното съобщение да е в MIME-формат, предаваните по интернет електронни съобщения са основно в MIME-формат, така че POP-клиентите трябва също така да разбират и да използват MIME. Поради това в цялата комуникационна среда на Решение 2008/615/ПВР ще бъдат включени компонентите на POP.

5.7.4.    Определяне на интернет адреси

Операционна среда

Понастоящем Европейският орган за регистрация на IP-адреси (RIPE) е определил за TESTA един специализиран блок от подмрежа клас С. По-нататък, ако е необходимо, за TESTA могат да бъдат определени и други блокове за адреси. Определянето на IP-адреси за държавите-членки се основава на географска схема в Европа. Обменът на данни между държавите-членки в рамките на Решение 2008/615/ПВР се осъществява по логически затворената европейска IP-мрежа.

Изпитателна среда

С цел да се осигури среда за безпрепятствено осъществяване на ежедневната работа между всички свързани държави-членки, е необходимо да се установи изпитателна среда в защитената мрежа за новите държави-членки, които се готвят да се присъединят към тези операции. Изготвен е документ с параметрите, включително IP-адреси, мрежови настройки, домейни за електронна поща, както и потребителски акаунти за приложенията, които следва да се конкретизират и установят в съответните обекти на държавите-членки. Освен това за целите на изпитванията е конструиран масив от псевдо ДНК профили.

5.7.5.    Параметри на конфигурацията

Създадена е защитена мрежа за електронна поща, за което е използван домейнът eu-admin.net. Този домейн с асоциираните му адреси няма да бъде достъпен от места извън домейна на TESTA за ЕС, тъй като имената са известни само на централния DNS-сървър на TESTA, който е отделен от интернет със специална защита.

Превръщането на тези адреси на сайтове (host names) в TESTA в съответните им IP-адреси се осъществява от DNS-услугите на TESTA. В този централен DNS-сървър на TESTA се добавя вписване за пощата, като всички електронни съобщения, изпратени до местните домейни на TESTA, се предават на центъра за предаване на поща на TESTA. Този център за предаване на поща на TESTA след това ги препраща към конкретния сървър за електронна поща на местния домейн, като се използват адресите за електронна поща на местния домейн. Чрез предаването на електронната поща по този начин, критична информация, която се съдържа в електронните съобщения, ще преминава само по европейската защитената мрежова инфраструктура, а не по незащитен интернет.

Необходимо е в обектите на всички държави-членки да се установят поддомейни ( получерен курсив ), следвайки следния синтаксис:

„application-type.pruem.Member State-code.eu-admin.net“, където:

„Member State-code“ приема стойността на един от двубуквените кодове на държавите-членки (напр. AT, BE и т.н.).

„ application-type “ приема една от стойностите: DNA или FP.

Като се приложи горепосоченият синтаксис, поддомейните на държавите-членки са посочени в таблицата по-долу:

ГЛАВА 2: Обмен на дактилоскопични данни (документ за контрол на интерфейса)

Целта на следния документ за контрол на интерфейса е да определи изискванията за обмена на дактилоскопична информация между системите на държавите-членки за автоматизирана идентификация на пръстови отпечатъци (AFIS). Документът се основава на прилагания от Интерпол ANSI/NIST-ITL 1-2000 (INT-I, Version 4.22b).

Настоящата версия обхваща всички основни дефиниции за логически записи тип-1, тип-2, тип-4, тип-9, тип-13 и тип-15, които са необходими за обработката на дактилоскопични данни на базата на изображения и признаци (minutiае).

1.   Обзор на съдържанието на файловете

Дактилоскопичният файл се състои от няколко логически записа. В оригиналния стандарт ANSI/NIST-ITL 1-2000 са определени шестнадесет типа записи. За разделяне на записите и на техните полета и подполета се използват подходящи разделителни ASCII символи.

За обмен на информация между службата по произход и службата по местоназначението се използват само 6 типа записи:

1.1.   Тип-1 — заглавна част на файла

Този запис съдържа маршрутизираща информация и информация, описваща структурата на останалата част от файла. В този тип записи също така се описват типовете транзакции, които попадат в следните по-широки категории:

1.2.   Тип-2 — описателен текст

Този запис съдържа текстова информация, която е от интерес за изпращащата и получаващата служба.

1.3.   Тип-4 — изображение с висока резолюция в сивата скала

Този запис се използва за обмен на дактилоскопични изображения с висока резолюция в сивата скала (осем бита), снети при резолюция 500 пиксела/инч. Дактилоскопичните изображения се компресират, като се използва WSQ-алгоритъм при съотношение не повече от 15:1. Не трябва да се използват други алгоритми за компресия или некомпресирани изображения.

1.4.   Тип-9 — запис на признаци (minutiае)

Записите тип-9 се използват за обмен на характеристики на папиларните линии и данни за признаците. Тяхната цел е от една страна да се избегне ненужното дублиране на процесите за кодиране в AFIS, от друга — да се позволи изпращането на AFIS кодове, които съдържат по-малко информация отколкото съответните изображения.

1.5.   Type-13 — запис на изображение на следи с променлива резолюция

Този запис се използва за обмен на изображения на следи от пръстови отпечатъци и на следи от длан с променлива резолюция, придружавани от буквено-цифрова текстурна информация. Резолюцията на сканиране на изображенията е 500 пиксела/инч с 256 нива на сивото. Ако качеството на изображението на следа е задоволително, то се компресира по WSQ алгоритъм. Ако е необходимо, на основата на двустранно споразумение, може резолюцията на изображенията да се увеличи на повече от 500 пиксела/инч и повече от 256 нива на сивото. В този случай е силно препоръчително да се използва JPEG 2000 (вж. допълнение 7).

1.6.   Запис на изображение на отпечатък от длан с променлива резолюция

Записи тип-15 на изображения с маркировка на полетата се използват за обмен на изображения на отпечатък от длан с променлива резолюция, придружавани от буквено-цифрова текстурна информация. Резолюцията на сканиране на изображенията е 500 пиксела/инч с 256 нива на сивото. За да се намали максимално обемът на данните, всички изображения на отпечатък от длан се компресират като се използва WSQ алгоритъм. Ако е необходимо, на основата на двустранно споразумение, резолюцията на изображенията може да се увеличи на повече от 500 пиксела/инч и повече от 256 нива на сивото. В този случай е препоръчително да се използва JPEG 2000 (вж. допълнение 7).

2.   Формат на записите

Файлът за транзакция се състои от един или повече логически записа. За всеки логически запис, който се съдържа във файла, има по няколко информационни полета, подходящи за типа запис. Всяко информационно поле може да съдържа една или повече на брой информационни единици с единична стойност. Тези единици взети заедно се използват за предаване на различни аспекти на данните, които се съдържат в съответното поле. Информационното поле може да се състои също така от една или повече информационни единици, които са групирани и повторени неколкократно в рамките на полето. Групираните по този начин информационни единици са познати като подполе. Следователно, информационното поле може да се състои от едно или повече подполета от информационни единици.

2.1.   Информационни разделители

В логическите записи с тагови полета, се прилагат механизми за отграничаване на информацията, посредством използването на четири ASCII разделителя. По този начин могат да се отграничават отделни единици в рамките на полето или подполето, полетата в рамките на логическия запис или многократно появяващи се подполета. Разделителите на информацията са дефинирани в стандарта ANSI X3.4. Тези символи се използват за логическо разделяне и категоризиране на информацията. Представени йерархично, символът за разделяне на файлове (FS) има най-широк обхват, следван от символа за разделяне на групи (GS), символа за разделяне на записи (RS) и накрая — символа за разделяне на единици (US). В таблица 1 са изброени тези ASCII разделители и е дадено описание на употребата им в настоящия стандарт.

Във функционално отношение информационните разделители следва да се разглеждат като указание за типа на данните, които следват. Със символ US се разделят отделни информационни единици в рамките на полето или подполето. Това е сигнал, че следващата информационна единица е част от данните за това поле или подполе. Множество подполета в рамките на същото поле, отделено със символ RS, сигнализира за започването на следваща група от повтаряща(и) се информационна(и) единица(и). Разделителният символ GS, използван между информационните полета, сигнализира за началото на ново поле, предшестващо идентификационния номер на полето, което се появява. По същия начин, началото на нов логически запис се сигнализира от появата на символа FS.

Четирите символа имат смисъл само когато са използвани като разделители на информационни единици в полетата на ASCII текстови записи. Когато тези символи се срещат в бинарни записи на изображения и бинарни полета не им се придава конкретен смисъл — те представляват част от обменяните данни.

Обикновено не следва да има празни полета или информационни единици, поради което между две единици данни следва да появява само един разделител. Изключение от това правило възниква в тези случаи, когато данните в полетата или информационните единици на транзакцията не са налични, липсват или не са задължителни и обработката на транзакцията не зависи от присъствието на точно тези данни. В тези случаи се появяват няколко и адаптиращи разделителни символа заедно, вместо да се изисква вмъкване на заместители на данни между разделителните символи.

За дефиниране на поле, което се състои от три информационни единици, се прилага следното: ако липсва информацията за втората информационна единица, тогава се появяват два съседни разделителя US между първата и третата информационна единица; ако липсват и втората и третата информационна единица, тогава се използват три разделителни символа — два символа US в допълнение към символа за край на полето или към разделителния символ на подполето. По принцип ако не са налични една или повече задължителни или незадължителни информационни единици в рамките на едно поле или подполе, следва да се постави съответният брой разделителни символи.

Възможно е да се получат съседни комбинации от два или повече от четирите вида разделителни символи. Когато отсъстват или не са налични данни за информационните единици, подполета или полета, трябва да има един разделителен символ по-малко, отколкото са задължителните информационни единици, подполета или полета.

2.2.   Изглед на записите

При логическите записи с тагови полета всяко използвано информационно поле се номерира в съответствие с настоящия стандарт. Форматът за всяко поле се състои от номера на типа логически запис, следван на разстояние от точка „.“, номер на полето, следван от двоеточие „:“, след което подходяща информация за това поле. Таговото поле може да се номерира с всяка цифра от едно до девет, като номерът се повява между точката „.“ и двоеточието „:“. Интерпретира се като номер на поле с непълно изписване. Това означава, че номерът на поле „2123:“ е равностоен на номера на поле „2.000000123:“ и се интерпретира по същия начин.

С цел илюстрация в настоящия документ се използват трицифрени номера за номериране на полетата, които се съдържат във всеки от описаните тук логическите записи с тагови полета. Номерата на полетата са в следния формат: „TT.xxx:“ където „ТТ“ представлява едносимволен или двусимволен тип запис, следван от точка. Следващите три символа съставят съответния номер на полето, следван от двоеточие След двоеточието се намира описателната ASCII информация или данните на изображението.

Логическите записи тип-1 и тип-2 съдържат само полета с ASCII текст. Цялата дължина на записа (включително номерата на полета, двоеточията и разделителните символи) се записва като първо ASCII поле във всеки от посочените типове записи. Контролният ASCII символ за разделяне на файлове FS (който означава край на логическия запис или транзакция) се поставя след последния байт ASCII информация и се включва в дължината на записа.

За разлика от концепцията за таговите полета, запис тип-4 съдържа само бинарни данни, записани като поредица от бинарни полета с фиксирана дължина. Цялата дължина на записа се отразява в първото четирибайтово бинарно поле на съответния запис. За този бинарен запис не се отразява нито номер на записа със съответната точка в края, нито идентификационен номер на полето със съответното двоеточие. Освен това, тъй като всички дължини на полета на този тип запис са или фиксирани, или конкретно определени, никой от четирите разделителни символа (US, RS, GS или FS) не се интерпретира по друг начин освен като бинарни данни. За бинарния запис символът FS не се използва за разделяне на записите или като символ, завършващ транзакцията.

3.   Логически запис тип-1: заглавна част на файла

Този запис описва структурата на файла, типа на файла и друга важна информация. Наборът от символи, използвани за полета на тип-1 се състои единствено от 7-битов ANSI код за информационен обмен.

3.1.   Полета на логически запис тип-1:

3.1.1.    Поле 1.001: Дължина на логическия запис (Logical Record Length — LEN)

В това поле се съдържа общия брой байтове в целия логически запис тип-1. Полето започва с „1.001:“, следвано от дължината на целия запис, в т.ч. всички символи на всички полета заедно с информационните разделители.

3.1.2.    Поле 1.002: Номер на версията (Version Number — VER)

За да е сигурно, че потребителите знаят коя е използваната версия на стандарта ANSI/NIST, в това четирибайтово поле се посочва номерът на версията на стандарта, който е приложен от софтуера или системата, генерирали този файл. Първите два байта посочват номера на основната версия, а вторите два — номера на подверсията. Например, оригиналният стандарт от 1986 г. се счита за първа версия и се означава с „0100“, докато сегашният стандарт ANSI/NIST-ITL 1-2000 е „0300“.

3.1.3.    Поле 1.003: Съдържание на файла (File Content — CNT)

Това поле изброява всеки от записите във файла според типа и реда, в който записите се появяват в логическия файл. Състои се от едно или повече подполета, всяко от които на свой ред съдържа две информационни единици, описващи един от логическите записи в текущия файл. Подполетата се вписват по реда на записването и изпращането на записите.

Първата информационна единица в първото подполе е „1“, с което се отбелязва, че въпросния запис е тип-1. Той се следва от втора информационна единица, която съдържа числото на броя на останалите записи, които се съдържат във файла. Това число е равно на броя на останалите подполета на поле 1.003.

Всяко от останалите подполета се асоциира с един от записите във файла, а редът на изброяване на подполетата съответства на последователността на записите. Всяко подполе съдържа две информационни единици. Първата показва какъв тип е записът. Втората е символът за означаване на изображението (IDC) в записа. За разделяне на двете информационни единици се използва символът US.

3.1.4.    Поле 1.004: Тип транзакция (Type of Transaction — TOT)

Това поле съдържа трибуквено мнемонично съчетание, с което се означава типът транзакция. Тези кодове могат да се различават кодовете, които се използват в други случаи на прилагане на стандарта ANSI/NIST.

CPS (Criminal Print-to-Print Search): търсене на отпечатъци на правонарушител. Тази транзакция представлява искане за търсене на запис, свързан с престъпление, чрез сравняване на отпечатъци в база данни. Отпечатъците на лицето трябва да се включат във файла като WSQ-компресирани изображения.

Ако не се установи попадение (No-HIT), се изпраща следният логически запис:

Ако се установи попадение (HIT), се изпраща следният логически запис:

В таблица A.6.1 (допълнение 6) е представен накратко TOT CPS.

PMS (Print-to-Latent Search): търсене чрез сравняване на отпечатъци със следи. Тази транзакция се използва, когато в база данни с неидентифицирани следи се извършва търсене за определен набор отпечатъци. В отговора се съдържа решението за наличие или отсъствие на попадение (Hit/No-Hit) при търсенето в AFIS по местоназначение. Ако има повече неидентифицирани следи, се отговаря с няколко SRE транзакции — по една отделна транзакция за всяка следа. Отпечатъците на лицето трябва да се включат във файла като WSQ-компресирани изображения.

Ако не се установи попадение (No-HIT), се изпраща следният логически запис:

Ако се установи попадение (HIT), се изпраща следният логически запис:

В таблица A.6.1 (допълнение 6) е представен накратко TOT PMS.

MPS (Print-to-Latent Search): търсене чрез сравняване на следи с отпечатъци. Тази транзакция се използва, когато трябва да се търсят съответствия на следи в база данни с отпечатъци. Във файла трябва да се включи информацията за признаците (minutiае) на следите и изображението (WSQ-компресия).

Ако не се установи попадение (No-HIT), се изпраща следният логически запис:

Ако се установи попадение (HIT), се изпраща следният логически запис:

В таблица A.6.4 (допълнение 6) е представен накратко TOT MPS.

MMS (Latent-to-Latent Search): търсене чрез сравняване на следи със следи. При тази транзакция файлът съдържа следа, за която се прави търсене в база данни с неидентифицирани следи, за да се установи връзка между различни местопрестъпления. Във файла трябва да се включи информацията за признаците (minutiае) на следите и изображението (WSQ-компресия).

Ако не се установи попадение (No-HIT), се изпраща следният логически запис:

Ако се установи попадение (HIT), се изпраща следният логически запис:

В таблица A.6.4 (допълнение 6) е представен накратко TOT MMS.

SRE: Тази транзакция се изпраща от службата по местоназначение в отговор на заявка с дактилоскопични данни. В отговора се съдържа решението за наличие или отсъствие на попадение (Hit/No-Hit) при търсенето в AFIS по местоназначение. Ако са налице няколко кандидати, се отговаря с няколко SRE транзакции — отделна транзакция за всеки кандидат.

В таблица A.6.2 (допълнение 6) е представен накратко TOT SRE.

ERR: тази транзакция се изпраща от AFIS по местоназначение, за да се посочи, че има грешка. В нея се включва поле за съобщение (ERM), в което се посочва установената грешка. Изпраща се следният логически запис:

В таблица A.6.3 (допълнение 6) е представен накратко TOT ERR.

Легенда:

M

=

задължително

M*

=

може да се включи само един от двата типа записи

O

=

незадължително

C

=

в зависимост от това, дали има налични данни

—

=

недопустимо

1*

=

в зависимост от това какви са „наследените“ системи

3.1.5.    Поле 1.005: Дата на транзакцията (Date of Transaction — DAT)

В това поле се посочва датата, на която е започнала транзакцията, като се използва стандартният формат на ISO: YYYYMMDD

където YYYY е годината, MM е месецът, а DD е денят от месеца. Единичните цифри се предшестват от нула. Например „19931004“ означава 4 октомври 1993 г.

3.1.6.    Поле 1.006: Приоритет (Priority — PRY)

Това незадължително поле описва приоритета на искането по скала от 1 до 9, като „1“ е най-високият приоритет, а „9“ е най-ниският. Транзакциите с приоритет „1“ се обработват незабавно.

3.1.7.    Поле 1.007: Идентификатор на службата по местоназначение (Destination Agency Identifier — DAI)

В това поле се посочва службата по местоназначение на транзакцията.

Състои се от две информационни единици в следния формат: CC/служба.

Първата информационна единица съдържа кода на държавата, определен по ISO 3166, с дължина два буквено-цифрови символа. Втората единица, службата, представлява свободен текст за идентификация на службата — не повече от 32 буквено-цифрови символа.

3.1.8.    Поле 1.008: Идентификатор на службата на произход (Originating Agency Identifier — ORI)

В това поле се посочва службата на произход и се използва същият формат като този за DAI (поле 1.007).

3.1.9.    Поле 1.009: контролен номер на транзакцията (Transaction Control Number — TCN)

Това е контролен номер за справочни цели. Той следва да се генерира от компютъра и е в следния формат: YYSSSSSSSSA

където YY е годината на транзакцията, SSSSSSSS е 8-цифров сериен номер, а A е контролен символ, генериран по процедурата, описана в допълнение 2.

Където няма TCN, полето YYSSSSSSSS се запълва с нули и се генерира контролен символ по начина, описан по-горе.

3.1.10.    Поле 1.010: Контролен номер на отговора на транзакцията (Transaction Control Response — TCR)

Когато има изпратено искане, на което настоящото се явява отговор, в това незадължително поле се дава контролният номер на транзакцията, с която е изпратено искането. Следователно, то има същия формат като TCN (поле 1.009).

3.1.11.    Поле 1.011: Резолюция на сканирането на мястото на произход (Native Scanning Resolution — NSR)

В това поле се посочва нормалната резолюция на сканиране на системата, с която работи службата-подател на транзакцията. Резолюцията се посочва във формат на две числа, следвани от десетична точка и след това още две цифри.

Всички транзакции, осъществявани по силата на Решение 2008/615/ПВР, се подават във формат 500 пиксела/инч или 19,68 пиксела/mm.

3.1.12.    Поле 1.012: Номинална резолюция на предаване (Nominal Transmitting Resolution — NTR)

В това 5-байтово поле се посочва номиналната резолюция на предаване на изпращаните изображения Резолюцията се изразява в пиксели/mm в същия формат като NSR (поле 1.011).

3.1.13.    Поле 1.013: Наименование на домейн (Domain name — DOM)

В това незадължително поле се посочва наименованието на домейна за изпълнението на определения от потребителя логически запис тип-2. Състои се от две информационни единици и е „INT-I{US}4.22{GS}“.

3.1.14.    Поле 1.014: Средно време по Гринуич (Greenwich mean time — GMT)

Това задължително поле предоставя механизъм за отразяване на датата и часа чрез универсалните единици в съответствие със средното време по Гринуич (GMT). Когато се използва полето GMT, в него се отразява тази универсална дата като допълнение към местната дата, дадена в поле 1.005 (DAT). С използването на полето GMT се премахват несъответствията в местното време, които се появяват, когато транзакцията и отговорът се предават между места, разделени от няколко часови зони. В полето GMT се посочва универсална дата и час в 24-часов формат, независимо от часовите зони. Изразява се във формат „CCYYMMDDHHMMSSZ“ — поредица от 15 символа, представляваща съчетанието от датата заедно с GMT и завършва със „Z“. Символите в поредицата „CCYY“ представляват годината на транзакцията, символите в поредицата „MM“ са стойностите на десетицата и единицата на месеца, а символите в поредицата „DD“ са стойностите на десетицата и единицата на деня от месеца, като символите в поредицата „HH“ представляват часа, „MM“ — минутата, а „SS“ — секундата. Пълната дата не може да има стойност по-висока от стойността на настоящата дата.

4.   Логически запис тип-2: описателен текст

Структурата на по-голямата част от този запис не е дефинирана в първоначалния стандарт ANSI/NIST. Записът съдържа информация, която представлява специален интерес за службите, които изпращат или получават файла. За да е сигурно, че съответните дактилоскопични системи, между които се осъществява комуникацията, са съвместими, в записа е необходимо да се включат само изброените по-долу полета. В документа се посочва кои полета са задължителни и кои не са задължителни, като се дефинира и структурата на отделните полета.

4.1.   Полета в логически запис тип-2:

4.1.1.    Поле 2.001: Дължина на логическия запис (Logical Record Length — LEN)

В това задължително поле се дава дължината на настоящия запис тип-2 и се посочва общият брой на байтовете, като се включват всички символи във всички полета на записа плюс разделителите.

4.1.2.    Поле 2.002: Символ за означение на изображението (Image Designation Character — IDC)

Това задължително поле съдържа символа за обозначение на изображението (IDC), представен в ASCII-формат за съответния IDC, определен в съдържанието на файла (CNT) на записа тип-1 (поле 1.003).

4.1.3.    Поле 2.003: Информация за системата (System Information — SYS)

Това поле е задължително и съдържа четири байта, с които се посочва на коя версия на INT-I съответства точно този запис тип-2.

Първите два байта посочват номера на основната версия, а вторите два — номера на подверсията. Например, в настоящия случай се работи по INT-I версия 4, редакция 22, което се изразява като „0422“.

4.1.4.    Поле 2.007: Номер на случая (Case Number — CNO)

Този номер се задава от местната дактилоскопична служба за множеството следи, снети от едно местопрестъпление. Възприет е следният формат: CC/номер.

където „CC“ представлява кода на държавата по Интерпол, с дължина два буквено-цифрови символа, като номерът е съобразен с действащите на място указания и може да има дължина до 32 буквено-цифрови символа.

Това поле позволява на системата да идентифицира следи, които се свързват с определено местопрестъпление.

4.1.5.    Поле 2.008: Номер на поредица (Sequence Number — SQN)

Посочва се всяка поредица от следи в рамките на същия случай. Дължината му е до четири цифрови символа. Поредицата представлява следа или поредица от следи, които са обединени за целите на документирането и/или търсенето. Съгласно тази дефиниция, на отделните единични следи също ще трябва да се даде номер на поредица.

Това поле може да се включи заедно с MID (поле 2.009), за да се идентифицира конкретна следа в поредицата.

4.1.6.    Поле 2.009: Идентификатор на следа (Latent Identifier — MID)

Тук се посочва отделната следа в рамките на поредицата. Стойността представлява единична буква или две букви, като с „A“ се обозначава първата следа, с „B“ — втората и т.н. до „ZZ“. Това поле се използва аналогично на номера на поредицата следи, разгледан в описанието за SQN (поле 2.008).

4.1.7.    Поле 2.010: Референтен номер на правонарушител (Criminal Reference Number — CRN)

Това е уникален референтен номер, който се задава от национален орган за лице, срещу което за пръв път е повдигнато обвинение за извършено престъпление. В рамките на една страна едно лице не може никога да има повече от един референтен номер на правонарушител (CRN), нито да го поделя с друго лице. За едно и също лице обаче е възможно да има референтни номера на правонарушител в различни държави, които се разпознават по кода на съответната държава.

За полето CRN е възприет следният формат: CC/номер

където „CC“ представлява кода на държавата по Интерпол, с дължина два буквено-цифрови символа, като номерът е съобразен с действащите национални указания на издаващия орган и може да има дължина до 32 буквено-цифрови символа.

За транзакциите по силата на Решение 2008/615/ПВР това поле ще се използва за националния референтен номер на правонарушителя, зададен от службата по произход, който е свързан с изображенията в записите тип-4 и тип-15.

4.1.8.    Поле 2.012: Идентификационен номер — разни (Miscellaneous Identification Number — MN1)

В това поле се съдържа CRN (поле 2.010), изпратен чрез транзакция CPS или PMS без въвеждащия код за държавата.

4.1.9.    Поле 2.013: Идентификационен номер — разни (Miscellaneous Identification Number — MN2)

В това поле се съдържа CNO (поле 2.007), изпратен чрез транзакция MPS или MMS без въвеждащия код за държавата.

4.1.10.    Поле 2.014: Идентификационен номер — разни (Miscellaneous Identification Number — MN3)

В това поле се съдържа SQN (поле 2.008), изпратен чрез транзакция MPS или MMS.

4.1.11.    Поле 2.015: Идентификационен номер — разни (Miscellaneous Identification Number — MN4)

В това поле се съдържа MID (поле 2.009), изпратен чрез транзакция MPS или MMS.

4.1.12.    Поле 2.063: Допълнителна информация (Additional Information — INF)

В случай на транзакция SRE във връзка с искане PMS, в това поле се дава информация за пръста, за който се отнася евентуалното попадение (HIT). Полето се попълва във формат:

NN където „ NN “ е кодът на позицията на пръста, определен в таблица 5, с дължина две цифри.

Във всички останали случаи това поле не е задължително. Състои се от най-много 32 буквено-цифрови символа и в него може да се даде допълнителна информация относно искането.

4.1.13.    Поле 2.064: Списък на респондентите (Respondents List — RLS)

Това поле съдържа поне две подполета. В първото подполе се описва видът на извършеното търсене, като се използват трибуквени мнемонични съчетания, с които се определя типа транзакция в TOT (поле 1.004). Второто подполе съдържа само един символ. С „I“ се отбелязва наличие на попадение (HIT), а отсъствие на попадение (NOHIT) за търсения случай се отбелязва с „N“. В третото поле се съдържа идентификаторът на поредицата за кандидата за резултат и общият брой кандидати, разделени с наклонена черта. Ако кандидатите са повече от един, се отговаря с няколко съобщения. В случай на евентуално попадение (HIT) в четвъртото подполе се съдържа резултатът с дължина до шест символа.

Ако попадението (HIT) се потвърди, стойността на това подполе става „999999“.

Пример: „CPS{RS}I{RS}001/001{RS}999999{GS}“

Ако няма подаден резултат от отдалечената система AFIS, на съответното място се отбелязва нулев резултат.

4.1.14.    Поле 2.074: Статус/поле за съобщение за грешка (Status/Error Message Field — ERM)

В това поле се съдържат съобщения за грешка в резултат на осъществена транзакция, които се изпращат на отправилата искането служба като част от транзакция за грешка.

Съобщения за грешка с номер между 100 и 199:

Тези съобщения за грешка са свързани с валидирането на ANSI/NIST записите и се определят като:

<error_code 1>: IDC <idc_number 1> FIELD <field_id 1> <dynamic text 1> LF

<error_code 2>: IDC <idc_number 2> FIELD <field_id 2> <dynamic text 2>...

където:

Пример:

201: IDC - 1 FIELD 1.009 WRONG CONTROL CHARACTER {LF} 115: IDC 0 FIELD 2.003 INVALID SYSTEM INFORMATION

Това поле е задължително за транзакции за грешка.

4.1.15.    Поле 2.320: Очакван брой кандидати (Expected Number of Candidates — ENC)

В това поле се съдържа максималният брой кандидати за верификация според отправилата искането служба. Стойността на ENC не може да надвишава стойностите, определени в таблица 11.

5.   Логически запис тип-4: изображение с висока резолюция в сивата скала

Следва да се отбележи, че записите тип-4 са по-скоро бинарни, отколкото ASCII по характер. Поради това на всяко поле в записа се задава определено място, от което се подразбира, че всички полета са задължителни.

Стандартът позволява в записа да се опишат както размерът на изображението, така и резолюцията. Изискването за логическите записи тип-4 е да съдържат данни на дактилоскопично изображение, което се предава с номинална наситеност 500—520 пиксела на инч. За по-новата техника, предпочитаната резолюция е 500 пиксела на инч или 19,68 пиксела на милиметър. В INT-I е посочена наситеност от 500 пиксела на инч, освен когато сходни системи могат да си общуват с друга резолюция в рамките на зададените предпочитани стойности от 500—520 пиксела на инч.

5.1.   Полета в логически запис тип-4:

5.1.1.    Поле 4.001: Дължина на логическия запис (Logical Record Length — LEN)

В това четирибайтово поле се дава дължината на настоящия запис тип-4 и се посочва общият брой на байтовете, като се включват всички байтове във всички полета на записа.

5.1.2.    Поле 4.002: Символ за означение на изображението (Image Designation Character — IDC)

Това е еднобайтовият бинарен израз на номера на IDC, който е даден в заглавния файл.

5.1.3.    Поле 4.003: Вид отпечатък (Impression Type — IMP)

Видът на отпечатъка е еднобайтово поле, което заема шестият байт на записа.

5.1.4.    Поле 4.004: Позиция на пръста (Finger Position — FGP)

Това поле с фиксирана дължина от 6 байта заема позициите 7—12 на запис тип-4. В него се съдържат възможните пръстови позиции, като се започва от най-левия байт (7-ия байт на записа). Известната или най-вероятна пръстова позиция се взема от таблица 5. Възможно е да се посочат до пет допълнителни пръста, като пръстовите позициите се впишат в съответния порядък в оставащите пет байта, за което се използва същият формат. Ако се посочват по-малко от пет пръстови позиции, неизползваните байтове се запълват с бинарно 255. За рефериране на всички пръстови позиции се използва код „0“ със значение „неизвестно“.

За следи, снети от местопрестъпление, се използват само кодовете от 0 до 10.

5.1.5.    Поле 4.005: Резолюция на сканираното изображение (Image Scanning Resolution — ISR)

Това еднобайтово поле заема 13-ия байт на запис тип-4. Ако съдържа „0“, това означава, че изображението е направено с препоръчителната резолюция от 19,68 пиксела/mm (500 пиксела/инч). Ако съдържа „1“, това означава, че изображението е направено с алтернативната резолюция за сканиране, посочена в запис тип-1.

5.1.6.    Поле 4.006: Дължина на хоризонталния ред (Horizontal Line Length — HLL)

Това поле се намира на мястото на байтове 14—15 в запис тип-4. В него се посочва броят на пикселите, които се съдържат във всеки ред на сканираното изображение. Най-съществен е първият байт.

5.1.7.    Поле 4.007: Дължина на вертикалния ред (Vertical Line Length — VLL)

В 16-17 байт на това поле е записан броят на редовете на сканираното изображение. Най-съществен е първият байт.

5.1.8.    Поле 4.008: Алгоритъм за компресиране в сивата скала (Greyscale Compression Algorithm — GCA)

В това еднобайтово поле се посочва алгоритъмът за компресиране в сивата скала, използван за кодиране на данните на изображението. За целите на прилагането, с бинарен код „1“ се посочва, че е използвана WSQ-компресия (допълнение 7).

5.1.9.    Поле 4.009: Изображение

Това поле съдържа поредица от байтове, която представлява самото изображение. Структурата му очевидно зависи от използвания алгоритъм за компресиране.

6.   Логически запис тип-9: запис на признаци (minutiae)

Записите тип-9 съдържат ASCII-текст, описващ признаците (minutiае) и свързана кодирана информация от следи. При транзакция за търсене на следи няма ограничение за тези записи тип-9 в рамките на един файл, но всеки от тях следва да се отнася за различен изглед или следа.

6.1.   Извличане на признаци (minutiае)

6.1.1.    Идентификация на типа признак

С този стандарт се определят три идентификационни номера, които се използват за описване на типа признак. Изброени са в таблица 6. Край на папиларна линия се означава като тип 1. Бифуркация се означава като тип 2. Ако даден признак не може да се определи ясно като един от горепосочените типове, той се означава като „друг“ („other“) — тип „0“.

6.1.2.    Разположение и тип на признака

За да отговарят образците на раздел 5 от стандарта ANSI INCITS 378-2004, разположението (място и ъгъл на въртене) на отделния признак се описва по следния метод, който е усъвършенстван вариант на действащия стандарт INCITS 378-2004.

Позицията или местоположението на признака, който представлява край на папиларна линия, е точката на раздвояване на срединния скелет на междупапиларната бразда, разположена непосредствено пред края на папиларната линия. Ако трите отсечки на междупапиларната бразда се изтънят до скелет с широчина 1 пиксел, точката на пресичането им е местоположението на признака. Аналогично, местоположението на признака при бифуркация е точката на раздвояване на срединния скелет на папиларната линия. Ако всяка от трите отсечки на папиларната линия се изтъни до скелет с широчина 1 пиксел, точката на пресичане на трите отсечки е местоположението на признака.

След като всички краища на папиларни линии са преобразявани в бифуркации, всички признаци на дактилоскопичното изображение се представят под формата на бифуркации. Пикселовите координати X и Y на пресечната точка на трите отсечки на всеки признак могат да се форматират директно. Определянето на вектора на признака може да се извлече от всяка скелетна бифуркация. Трите отсечки на всяка скелетна бифуркация трябва да се разгледат и да се определи крайната точка на всяка отсечка. На фигура 6.1.2 са илюстрирани трите метода, които се използват за определяне на край на отсечка, което се прави на базата на сканираща резолюция 500 ppi.

Краят се установява според това кое събитие се прояви първо. Броят на пикселите се определя на базата на образ, сканиран с резолюция 500 ppi. Подразбира се, че при друга резолюция ще се използва различен брой пиксели.

Фигура 6.1.2

Ъгълът на признаците се определя, като се построят три виртуални лъча от точката на бифуркация до края на всяка отсечка. Ъглополовящата на най-малкия от трите ъгъла, образувани от лъчите, се използва за означаване на посоката на признака.

6.1.3.    Координатна система

За изразяване на признаците на пръстов отпечатък се използва Декартова координатна система. Местоположението на признаците се представя от техните х и у координати. Началото на координатната система е горният ляв ъгъл на оригиналното изображение, като х нараства надясно, а у нараства надолу. И двете координати (х и у) на признаците се изразяват в пиксел единици, отстоящи от началото. Следва да се отбележи, че началната точка и мерните единици не съответстват на общоприетата система, използвана за дефинициите на тип-9 в ANSI/NIST-ITL 1-2000.

6.1.4.    Ориентация на признаците

Ъглите се изразяват в стандартен математически формат, като нула градуса е вдясно и ъгълът расте обратно на часовниковата стрелка. Ъглите в записите са ориентирани по посоката на папиларната линия за край на папиларна линия и от центъра на междупапиларната бразда при бифуркация. Тази практика се разминава на 180 градуса със системата за определяне на ъглите, описана в дефинициите на тип-9 в ANSI/NIST-ITL 1-2000.

6.2.   Полета в логически запис тип-9, формат INCITS-378

Всички полета от записите тип-9 се записват като ASCII текст. В този запис с тагови полета не се допускат бинарни полета.

6.2.1.    Поле 9.001: Дължина на логическия запис (Logical record length — LEN)

В това задължително ASCII поле се съдържа дължината на логическия запис — посочва се общият брой на байтовете, като се включват всички байтове във всички полета на записа.

6.2.2.    Поле 9.002: Символ за означение на изображението (Image designation character — IDC)

Това задължително двубайтово поле се използва за идентификация и описване на местоположението на данните за признаци. Записаният в това поле символ за IDC съответства на символа за IDC, който се намира в полето за съдържание на файла на записа тип-1.

6.2.3.    Поле 9.003: Вид отпечатък (Impression type — IMP)

В това задължително еднобайтово поле се описва начинът, по който е получена информацията за дактилоскопичното изображение. ASCII стойността на самия код, която се взема от таблица 4, се вписва в това поле, за да се означи типът отпечатък.

6.2.4.    Поле 9.004: Формат на признака (Minutiае format — FMT)

В това поле се съдържа „U“, за да се означи, че признаците са форматирани с M1-378. Въпреки че информацията може да е кодирана в съответствие със стандарта M1-378, всички полета за данни в записа тип-9 трябва да останат във формат ASCII-текст.

6.2.5.    Поле 9.126: Информация CBEFF

В това поле се съдържат три информационни единици. Първата информационна единица има стойност „27“ (0x1B). Това е идентификацията на „притежателя“ на формáта CBEFF, определена от Международната асоциация на биометричната индустрия (IBIA) за Техническия комитет INCITS М1. Тази единица се отделя с разделителен символ <US> от типа формат CBEFF, на който се задава стойност „513“ (0x0201), за да се означи, че в този запис се съдържат само данни за местоположението и ъгловия вектор без информация за Extended Data Block. Тази единица се отделя с разделителен символ <US> от продуктовия идентификатор CBEFF (PID), с който се идентифицира „притежателят“ на кодиращото оборудване. Тази стойност се задава от фирмата производител. Стойността може да се вземе от уебсайта на IBIA (www.ibia.org), ако е публикувана там.

6.2.6.    Поле 9.127: Идентификация на оборудването за „улавяне на образ“

В това поле има две информационни единици, разделени със символ <US>. Първата единица съдържа APPF, ако оборудването, използвано за добиване на първоначалния образ, има сертификат за съответствие с допълнение F (IAFIS Image Quality Specification, 29 януари, 1999 г.) по CJIS-RS-0010, спецификацията на Федералното бюро за разследване за изпращане на пръстови отпечатъци. Ако оборудването не отговаря на това изискване, се вписва стойност NONE. Втората информационна единица съдържа идентификацията на оборудването за „улавяне на образ“, която е продуктовият номер, зададен от фирмата-производител, за съответното оборудване. Стойност 0 показва, че идентификацията на оборудването за „улавяне на образ“ е неизвестна.

6.2.7.    Поле 9.128: Дължина на хоризонталния ред (Horizontal line length — HLL)

В това задължително ASCII поле се съдържа броят на пикселите, които се съдържат в един хоризонтален ред на изпращаното изображение. Максималният размер на хоризонтален ред достига до 65 534 пиксела.

6.2.8.    Поле 9.129: Дължина на вертикалния ред (Vertical line length — VLL)

В това задължително ASCII поле се задава броят на хоризонталните редове, които се съдържат в изпращаното изображение. Максималният размер на вертикален ред достига до 65 534 пиксела.

6.2.9.    Поле 9.130: Мащабни единици (Scale units — SLC)

В това задължително ASCII-поле се посочват единиците, използвани за описание на честотата на дискретизация на изображението (плътност на пикселите). В това поле стойност 1 показва броя на пикселите на 1 инч, а 2 показва пикселите на 1 сантиметър. Стойност 0 в това поле показва, че не е даден мащаб. В този случай съотношението на страните на пикселите се определя като коефициент HPS/VPS.

6.2.10.    Поле 9.131: Хоризонтален мащаб в пиксели (Horizontal pixel scale — HPS)

В това задължително ASCII поле се задава числото на плътността на пикселите по хоризонталата, при условие че в полето SLC има вписана стойност 1 или 2. В останалите случаи тя показва хоризонталния компонент на съотношението на страните на пикселите.

6.2.11.    Поле 9.132: Вертикален мащаб в пиксели (Vertical pixel scale — VPS)

В това задължително ASCII поле се задава числото на плътността на пикселите по вертикалата, при условие че в полето SLC има вписана стойност 1 или 2. В останалите случаи тя показва вертикалния компонент на съотношението на страните на пикселите.

6.2.12.    Поле 9.133: Пръстов изглед

В това задължително поле е даден номерът на изгледа на пръста, за който се отнасят данните в записа. Номерата на изгледите започват от 0 и нарастват с единица до 15.

6.2.13.    Поле 9.134: Позиция на пръста (Finger position — FGP)

В това задължително поле се дава кодът, с който се означава позицията на пръста, от който е получена информацията в този запис тип-9. Позицията на пръста се посочва с код със стойности от 1 до 10, който се взема от таблица 5, а съответният код за позицията на длан се взема от таблица 10.

6.2.14.    Поле 9.135: Качество на пръстовия отпечатък

Полето показва качеството на данните за признаците на пръстовия отпечатък като цяло и има стойност между 0 и 100. Това число е отражение на цялостното качество на записа за пръстовия отпечатък и представя качеството на оригиналното изображение, на извлечените признаци и всякакви допълнителни операции, които биха могли да повлияят на записа за признаците.

6.2.15.    Поле 9.136: Брой признаци

В това задължително поле се съдържа броят на признаците, записани в този логически запис.

6.2.16.    Поле 9.137: Данни за пръстовите признаци

В това поле има шест информационни единици, разделени със символ <US>. Състои се от няколко подполета, във всяко от които има подробни данни за един отделен признак. Общият брой на подполетата за признаци трябва да съответства на броя, посочен в поле 136. Първата информационна единица е индексният номер на признака, който започва от 1 и нараства с единица за всеки допълнителен признак на пръстовия отпечатък. Втората и третата информационна единица представляват „х“ и „у“ координатите на признаците, изразени в пиксели. Четвъртата информационна единица представлява ъгъла на признака, изразен в единици от по два градуса. Тази стойност е положително число между 0 и 179. Петата информационна единица изразява типа на признака. Със стойност 0 се представя тип „ДРУГО“ (OTHER), със стойност 1 се представя край на папиларна линия, а със стойност 2 — бифуркация на папиларната линия. Шестата информационна единица представлява качеството на съответния признак. Стойността ѝ варира между 1 за минималната стойност и 100 за максималната. Стойност 0 показва, че няма налична стойност за качеството. Всяко подполе се разделя от следващото с разделителен символ <RS>.

6.2.17.    Поле 9.138: Информация за броя на папиларните линии

Това поле се състои от поредица подполета, във всяко от които има по три информационни единици. Първата информационна единица на първото подполе показва начина на получаване на броя на папиларните линии. Стойност 0 показва, че не могат да се правят никакви заключения относно начина на получаване на броя на папиларните линии, нито относно реда, в който са дадени в записа. Стойност 1 показва, че за всеки център на признак са получени данни за броя на папиларните линии до най-близките съседни признаци в четири квадранта, като броят на папиларните линии за всеки център на признак са изброени заедно. Стойност 2 показва, че за всеки център на признак са получени данни за броя на папиларните линии до най-близките съседни признаци в осем октанта, като броят на папиларните линии за всеки център на признак са изброени заедно. И двете останали информационни единици от първото подполе са със стойност 0. Информационните единици се разделят с разделителен символ <US>. В следващите подполета се съдържа индексният номер на центъра на признака като първа информационна единица, индексният номер на съседния признак като втора информационна единица и броят на пресечените папиларни линии като трета информационна единица. Подполетата се разделят с разделителен символ <RS>.

6.2.18.    Поле 9.139: Информация за център на папиларен образ

Това поле се състои от по едно подполе за всеки наличен център на папиларен образ в оригиналното изображение. Всяко подполе съдържа три информационни единици. Първите две единици съдържат позиционните „x“ и „y“ координати, изразени в пиксели. Третата информационна единица съдържа ъгловата стойност на центъра на папиларния образ, изразена в единици от по 2 градуса. Стойността е положително число между 0 и 179. При повече центрове на папиларни образи, същите се разделят с разделителен символ <RS>.

6.2.19.    Поле 9.140: Информация за делта

Това поле се състои от по едно подполе за всяка налична делта в оригиналното изображение. Всяко подполе съдържа три информационни единици. Първите две единици съдържат позиционните „x“ и „y“ координати, изразени в пиксели. Третата информационна единица съдържа ъгловата стойност на делтата, изразена в единици от по 2 градуса. Стойността е положително число между 0 и 179. При повече центрове на папиларни образи, същите се разделят с разделителен символ <RS>.

7.   Запис тип-13 на изображение на следи с променлива резолюция

Логическият запис тип-13 с тагови полета съдържа данни на изображение, получено от изображение на следи. Тези изображения са предназначени за изпращане на службите, които автоматично ще извлекат или ще осигурят интервенция на служители и обработка с цел получаване на желаната характеризираща информация от изображенията.

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

Легенда за вида символ: N = цифров; A = буквен; AN = буквено-цифров; B = бинарен

7.1.   Полета в логически запис тип-13:

В следващите няколко параграфа са описани данните, които се съдържат във всяко от полетата в логически запис тип-13.

В логически запис тип-13 данните се въвеждат в номерирани полета. Изискването е първите две полета на записа да са подредени в установен ред, а полето, съдържащо данните на изображението е последното физическо поле в записа. В таблица 7 за всяко поле в запис тип-13 е посочен код за задължителност — задължително „M“ или незадължително „O“, номер на полето, наименование на полето, вид символ, размер на полето и колко пъти може да се използва. Използва се трицифрен номер на полето, като максималният брой на байтовете е даден в последната колонка. С увеличаване броя на цифрите в номера на полето се увеличава и максималният брой на байтовете. Двете стойности, които се вписват в „размер на полето за всяко използване“ се включват всички разделителни символи, използвани в полето. В „максималния брой байтове“ се включва номерът на полето, информацията и всички разделителни символи, в т.ч. и символът GS.

7.1.1.    Поле 13.001: Дължина на логическия запис (Logical record length — LEN)

В това задължително ASCII поле е записано числото на общия брой байтове в целия логически запис тип-13. В поле 13.001 се посочва дължината на записа, като се включват всички символи във всички полета на записа плюс разделителите.

7.1.2.    Поле 13.002: Символ за означение на изображението (Image designation character — IDC)

В това задължително ASCII поле се посочват данните за изображения на следи, които се съдържат в записа. Този IDC съответства на IDC, който се намира в полето за съдържание на файла (CNT) на записа тип-1.

7.1.3.    Поле 13.003: Вид отпечатък (Impression type — IMP)

В това задължително еднобайтово или двубайтово ASCII поле се описва начинът, по който е получена информацията за изображението на следа. В това поле се вписва съответният код за следа, който се взема от таблица 4 (пръст) или от таблица 9 (длан).

7.1.4.    Поле 13.004: Служба на произход/ORI (Source agency/ORI — SRC)

В това задължително ASCII поле се посочва идентификацията на службата или организацията, която първоначално е изготвила изображението на лице, което се съдържа в записа. В това поле обикновено се вписва идентификаторът на службата на произход (Originating Agency Identifier — ORI) за службата, която е изготвила изображението посредством „capture“ технология. Състои се от две информационни единици в следния формат: CC/служба.

Първата информационна единица съдържа кода на държавата по Интерпол — два буквено-цифрови символа. Втората единица, службата, представлява свободен текст за идентификация на службата — не повече от 32 буквено-цифрови символа.

7.1.5.    Поле 13.005: Дата на изготвяне на изображението на следи (Latent capture date — LCD)

В това задължително ASCII поле се посочва датата, на която е изготвено изображението на следи, които се съдържат в записа. Датата се изписва с осем цифри във формат CCYYMMDD. Символите за CCYY представляват годината, в която е изготвено изображението; символите за MM представляват стойностите за десетицата и единицата на месеца; а символите за DD представляват стойностите за десетицата и единицата на деня от месеца; например 20000229 означава 29 февруари 2000 г. Пълната дата трябва да е действителна дата.

7.1.6.    Поле 13.006: Дължина на хоризонталния ред (Horizontal line length — HLL)

В това задължително ASCII поле се задава броят на пикселите, които се съдържат в един хоризонтален ред на изпращаното изображение.

7.1.7.    Поле 13.007: Дължина на вертикалната линия (Vertical line length — VLL)

В това задължително ASCII поле се задава броят на хоризонталните редове, които се съдържат в изпращаното изображение.

7.1.8.    Поле 13.008: Мащабни единици (Scale units — SLC)

В задължително ASCII-поле се посочват единиците, използвани за описание на честотата на дискретизация на изображението (плътност на пикселите). В това поле стойност 1 показва броя на пикселите на 1 инч, а 2 показва пикселите на 1 сантиметър. Стойност 0 в това поле показва, че не е даден мащаб. В този случай съотношението на страните на пикселите се определя като коефициент HPS/VPS.

7.1.9.    Поле 13.009: Хоризонтален мащаб в пиксели (Horizontal pixel scale — HPS)

В това задължително ASCII поле се задава числото на плътността на пикселите по хоризонталата, при условие че в полето SLC има вписана стойност 1 или 2. В останалите случаи тя показва хоризонталния компонент на съотношението на страните на пикселите.

7.1.10.    Поле 13.010: Вертикален мащаб в пиксели (Vertical pixel scale — VPS)

В това задължително ASCII поле се задава числото на плътността на пикселите по вертикалата, при условие че в полето SLC има вписана стойност 1 или 2. В останалите случаи тя показва вертикалния компонент на съотношението на страните на пикселите.

7.1.11.    Поле 13.011: Алгоритъм за компресиране (Compression algorithm — CGA)

В това задължително ASCII поле се посочва алгоритъмът, използван за компресиране на изображения в сивата скала. Вижте в допълнение 7 кодовете за компресия.

7.1.12.    Поле 13.012: Битове на пиксел (Bits per pixel — BPX)

В това задължително ASCII поле се посочва броят на битовете, използвани за представяне на един пиксел. В това поле се вписва 8 за нормалните стойности на сивата скала от 0 до 255. Когато в това поле е въведена стойност, по-голяма от 8, това означава по-висока степен на пикселиране в сивата скала.

7.1.13.    Поле 13.013: Позиция на пръста/дланта (Finger/palm position — FGP)

В това задължително тагово поле се вписва позицията или позициите на пръста или дланта, които е възможно да съвпаднат с изображението на следата. Десетичното кодово число, което съответства на известната или най-вероятна пръстова позиция, се взема от таблица 5, а за най-вероятна позиция на дланта — от таблица 10, и се вписва като едносимволно или двусимволно ASCII подполе. Допълнителни позиции за пръст и/или длан могат да се посочат като се впишат алтернативните позиционни кодове под формата на подполета, отделени с разделителен символ RS. Кодът 0 — за „неизвестен пръст“, се използва за рефериране на всяка пръстова позиция от едно до десет. Кодът 20 — за „неизвестна длан“, се използва за рефериране на всяка вписана позиция на длан.

7.1.14.    Полета 13.014-019: Резервирано за по-нататъшно дефиниране (Reserved for future definition — RSV)

Тези полета са резервирани за включване в по-нататъшни редакции на настоящия стандарт. Никое от тези полета не се използва на този етап на редактиране. Ако някое от тези полета е запълнено, то не се взема под внимание.

7.1.15.    Поле 13.020: Бележки (Comment — COM)

Това незадължително поле може да се използва за вписване на бележки или на друга информация с ASCII-текст към данните за изображение на следи.

7.1.16.    Полета 13.021-199: Резервирано за по-нататъшно дефиниране (Reserved for future definition — RSV)

Тези полета са резервирани за включване в по-нататъшни редакции на настоящия стандарт. Никое от тези полета не се използва на този етап на редактиране. Ако някое от тези полета е запълнено, то не се взема под внимание.

7.1.17.    Полета 13.200-998: Полета, дефинирани от потребителя (User-defined fields — UDF)

Тези полета могат да се дефинират от потребителя и се използват за бъдещи изисквания. Размерът и съдържанието им се определят от потребителя и са съгласувани със службата получател. Когато са попълнени, в тях се съдържа информация под формата на ASCII текст.

7.1.18.    Поле 13.999: Данни на изображението (Image data — DAT)

В това поле се намират всички данни на изображението на следа, направено посредством „capture“ технология. Полето винаги има стойност 999 и е последното физически разположено поле в записа. Например: след „13.999:“ има бинарно представени данни на изображение.

Всеки пиксел от некомпресирани данни в сивата скала обикновено се изразяват количествено в осем бита (256 нива на сивото), които се съдържат в един байт. Ако в BPX поле 13.012 е вписана стойност по-голяма или по-малка от 8, броят на байтовете, в които се съдържа един пиксел, е различен. Ако се използва компресия, пиксел-данните трябва да се компресират по начина, определен в полето GCA начин.

7.2.   Край на запис тип-13: изображение на следи с променлива резолюция

За по-голяма прегледност, непосредствено след последния байт данни на поле 13.999 се поставя разделител FS, за да се раздели този от следващия логически запис. Този разделител трябва да се включи в полето за дължината на запис тип-13.

8.   Запис тип-15: изображение на отпечатък от длан с променлива резолюция

Логически запис тип-15 с тагови полета съдържа и се използва за обмен на данни за изображение на отпечатък от длан, като в него има полета за фиксирана информация и за определена от потребителя информация, свързана с цифровизираното изображение. Под формата на тагови полета в записа се дава информация относно използваната резолюция на сканиране, размера на изображението и други параметри или бележки, необходими за обработката на изображението. Изпращаните на други служби изображения на длан се обработват от службите-получатели за извличане на желаната характеризираща информация, необходима за целите на сравняването.

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

Какъвто и да е методът за добиване на изображението на отпечатъка на длан, той трябва да има възможност за снемане на определен набор от изображения за всяка ръка. Този набор включва хипотенарната част на дланта, под формата на единично сканирано изображение, и пълната зона на изпънатата цяла длан от китката до върха на пръстите под формата на едно или две сканирани изображения. Ако са използвани две изображения за представяне на цялата длан, долното изображение показва дланта от китката до върха на междупръстието (ставата на третия пръст) и включва тенарната и хипотенарната област на дланта. Горното изображение обхваща зоната от долния край на междупръстието до върха на пръстите. По този начин се осигуряват достатъчно голяма зона на припокриване на двете изображения, и двете от които включват междупръстието на дланта. Чрез сравняване на папиларните линии и детайлите, които се съдържат в тази обща част, провеждащият изследването може да твърди с увереност, че двете изображения са на една и съща длан.

Тъй като транзакцията за отпечатък на длан може да се използва за различни цели, тя може да съдържа изображения на една или повече уникални зони на дланта или цялата ръка. Пълният набор от отпечатъци на дланта на едно лице обикновено включва хипотенарната част на дланта и изображение(я) на цялата длан от всяка ръка. Тъй като логическият запис с тагови полета, който се използва за изображение, може да съдържа само едно бинарно поле, за всяка хипотенарна част на длан ще е необходим отделен запис тип-15, както и едни или два записа тип-15 за всяка цяла длан. Поради това ще са необходими 4 — 6 записа тип-15 за представяне на отпечатъците от длан на даден субект в една нормална транзакция за отпечатъци на длан.

8.1.   Полета в логически запис тип-15:

В следващите няколко абзаца са описани данните, които се съдържат във всяко от полетата в логически запис тип-15.

В логически запис тип-15 данните се въвеждат в номерирани полета. Изискването е първите две полета на записа да са подредени в установен ред, а полето с данните на изображението е последното физическо поле в записа. В таблица 8 за всяко поле в запис тип-15 е посочен код за задължителност — задължително „M“ или незадължително „O“, номер на полето, наименование на полето, вид символ, размер на полето и колко пъти може да се използва. Използва се трицифрен номер на полето, като максималният брой на байтовете е даден в последната колонка. С увеличаване броя на цифрите в номера на полето се увеличава и максималният брой на байтовете. Двете стойности, които се вписват в „размер на полето за всяко използване“. В „максималния брой байтове“ се включва номерът на полето, информацията и всички разделителни символи, в т.ч. и символът GS.

8.1.1.    Поле 15.001: Дължина на логическия запис (Logical record length — LEN)

В това задължително ASCII поле е записано числото на общия брой байтове в целия логически запис тип-15. В поле 15.001 се посочва дължината на записа, като се включват всички символи във всички полета на записа плюс разделителите.

8.1.2.    Поле 15.002: Символ за означение на изображението (Image designation character — IDC)

Това задължително ASCII поле се използва за идентифициране на изображението на отпечатък от длан, което се съдържа в записа. Този IDC съответства на IDC, който се намира в полето за съдържание на файла (CNT) на записа тип-1.

8.1.3.    Поле 15.003: Вид отпечатък (Impression type — IMP)

В това задължително еднобайтово ASCII поле се посочва начинът, по който е получена информацията за изображението на отпечатъка на длан. В това поле се вписва съответният код, който се взема от таблица 9.

8.1.4.    Поле 15.004: Служба на произход/ORI (Source agency/ORI — SRC)

В това задължително ASCII поле се вписва идентификацията на службата или организацията, която първоначално е изготвила изображението на лице, което се съдържа в записа. В това поле обикновено се вписва идентификаторът на службата на произход (ORI) за съответната служба, която е изготвила изображението посредством „capture“ технология. Състои се от две информационни единици в следния формат: CC/служба.

Първата информационна единица съдържа кода на държавата по Интерпол — два буквено-цифрови символа. Втората единица, службата, представлява свободен текст за идентификация на службата — не повече от 32 буквено-цифрови символа.

8.1.5.    Поле 15.005: Дата на изготвяне на изображението на отпечатък от длан посредством „capture“ технология (Palmprint capture date — PCD)

В това задължително ASCII поле се вписва датата, на която е изготвено изображението на отпечатък от длан посредством capture-технология. Датата се изписва с осем цифри във формат CCYYMMDD. Символите за CCYY представляват годината, в която е изготвено изображението; символите за MM представляват стойностите за десетицата и единицата на месеца; а символите за DD представляват стойностите за десетицата и единиците на деня от месеца; например, вписаната стойност 20000229 означава 29 февруари 2000 г. Пълната дата трябва да е действително съществуваща дата.

8.1.6.    Поле 15.006: Дължина на хоризонталния ред (Horizontal line length — HLL)

В това задължително ASCII поле се задава броят на пикселите, които се съдържат в един хоризонтален ред на изпращаното изображение.

8.1.7.    Поле 15.007: Дължина на вертикалната линия (Vertical line length -VLL)

В това задължително ASCII поле се задава броят на хоризонталните редове, които се съдържат в изпращаното изображение.

8.1.8.    Поле 15.008: Мащабни единици (Scale units — SLC)

В задължително ASCII-поле се посочват единиците, използвани за описание на честотата на дискретизация на изображението (плътност на пикселите). В това поле стойност 1 показва броя на пикселите на 1 инч, а 2 показва пикселите на 1 сантиметър. Стойност 0 в това поле показва, че не е даден мащаб. В този случай съотношението на страните на пикселите се определя като коефициент HPS/VPS.

8.1.9.    Поле 15.009: Хоризонтален мащаб в пиксели (HPS)

В това задължително ASCII поле се задава числото на наситеност с пиксели по хоризонталата, при условие че в полето SLC има вписана стойност 1 или 2. В останалите случаи тя показва хоризонталния компонент на съотношението на страните на пикселите.

8.1.10.    Поле 15.010: Вертикален мащаб в пиксели (Horizontal pixel scale — VPS)

В това задължително ASCII поле се задава числото на наситеност с пиксели по вертикалата, при условие че в полето SLC има вписана стойност 1 или 2. В останалите случаи тя показва вертикалния компонент на съотношението на страните на пикселите.

8.1.11.    Поле 15.011: Алгоритъм за компресиране (Compression algorithm — CGA)

В това задължително ASCII поле се посочва алгоритъмът, използван за компресиране на изображения в сивата скала. Ако в полето е вписано „NONE“, това показва, че данните в този запис не са компресирани. За изображенията, които следва да се компресират, в това поле се вписва предпочитаният метод на компресиране за изображения с десет пръстови отпечатъка. Валидните кодове за компресията са дефинирани в допълнение 7.

8.1.12.    Поле 15.012: Битове на пиксел (Bits per pixel — BPX)

В това задължително ASCII поле се посочва броят на битовете, използвани за представяне на един пиксел. В това поле се вписва 8 за нормалните стойности на сивата скала от 0 до 255. Когато в това поле е въведена стойност, по-голяма или по-малка от 8, това означава съответно по-висока или по-ниска степен на пикселиране в сивата скала.

8.1.13.    Поле 15.013: Позиция на отпечатъка на длан (Palmprint position — PLP)

В това задължително тагово поле се описва позицията на отпечатъка от длан, съответстваща на изображението на отпечатъка от длан. Десетичният код, съответстващ на известната или най-вероятна позиция на отпечатъка от длан, се взема от таблица 10 и се вписва като двусимволно ASCII подполе. В таблица 10 също така са изброени максималните стойности за площта и размерите на изображението за всяка от възможните позиции на отпечатъка от длан.

8.1.14.    Полета 15.014-019: Резервирано за по-нататъшно дефиниране (Reserved for future definition — RSV)

Тези полета са резервирани за включване в по-нататъшни редакции на настоящия стандарт. Никое от тези полета не се използва на този етап на редактиране. Ако някое от тези полета е запълнено, то не се взема под внимание.

8.1.15.    Поле 15.020: Бележки (Comment — COM)

Това незадължително поле може да се използва за вписване на бележки или на друга информация с ASCII-текст към данните за изображение на отпечатък от длан.

8.1.16.    Полета 15.021-199: Резервирано за по-нататъшно дефиниране (Reserved for future definition — RSV)

Тези полета са резервирани за включване в по-нататъшни редакции на настоящия стандарт. Никое от тези полета не се използва на този етап на редактиране. Ако някое от тези полета е запълнено, то не се взема под внимание.

8.1.17.    Полета 15.200-998: Полета, дефинирани от потребителя (User-defined fields — UDF)

Тези полета могат да се дефинират от потребителя и се използват за бъдещи изисквания. Размерът и съдържанието им се определят от потребителя и са съгласувани със службата-получател. Когато са попълнени, в тях се съдържа информация под формата на ASCII-текст.

8.1.18.    Поле 15.999: Данни на изображението (Image data — DAT)

В това поле се намират всички данни на изображението на отпечатък от длан, направено посредством capture-технология. Полето винаги има стойност 999 и е последното физически разположено поле в записа. Например: след „15.999:“ има бинарно представени данни на изображение. Всеки пиксел от некомпресирани данни в сивата скала обикновено се изразяват количествено в осем бита (256 нива на сивото), които се съдържат в един байт. Ако в BPX поле 15.012 е вписана стойност по-голяма или по-малка от 8, броят на байтовете, в които се съдържа един пиксел, е различен. Ако се използва компресия, пиксел-данните трябва да се компресират по начина, определен в полето CGA начин.

8.2.   Край на запис тип-15 на изображение на отпечатък на длан с променлива резолюция

За по-голяма прегледност, непосредствено след последния байт данни на поле 15.999 се поставя разделител FS, за да се раздели този от следващия логически запис. Този разделител трябва да се включи в полето за дължината на запис тип-15.

8.3.   Допълнителни записи тип-15: изображение на длан с променлива резолюция

Във файла могат да се включат допълнителни записи тип-15. За всяко допълнително изображение на отпечатък от длан е необходим цял логически запис тип-15 заедно със съответния FS разделител.

Видове търсения:

9.   Допълнения към глава 2 (обмен на дактилоскопични данни)

9.1.   Допълнение 1 ASCII разделителни кодове

9.2.   Допълнение 2 Изчисляване на буквено-цифровия контролен символ

За TCN и TCR (полета 1.09 и 1.10):

Числото, съответстващо на контролния символ, се генерира по следната формула:

(YY * 108 + SSSSSSSS) Modulo 23

където YY и SSSSSSSS са числовите стойности, съответстващи на последните две цифри от годината и на серийния номер.

Контролният символ се генерира по дадената по-долу справочна таблица.

За CRO (поле 2.010)

Числото, съответстващо на контролния символ, се генерира по следната формула:

(YY * 106 + NNNNNN) Modulo 23

където YY и NNNNNN са числовите стойности, съответстващи на последните две цифри от годината и на серийния номер.

Контролният символ се генерира по дадената по-долу справочна таблица.

9.3.   Допълнение 3 Символни кодове

9.4.   Допълнение 4 Кратко описание на транзакция

В колонката за задължителност:

O = незадължително; M = задължително; C = в зависимост от това дали транзакцията представлява отговор, изпратен до службата на произход

В колонката за задължителност:

O.= незадължително; M = задължително; C = в зависимост от това дали има налични данни

*

=

ако предаването на данните е в съответствие с националното законодателство (не попада в обхвата на Решение 2008/615/ПВР)

9.5.   Допълнение 5 Дефиниции на запис тип-1:

В колонката за задължителност: O = незадължително, M = задължително, C = под условие

В колонката за вид символ: A = буквен, N = числов, B = бинарен

1* допустими символи за наименованието на службата [„0..9“, „A..Z“, „a..z“, „_“, „.“, „ “, „—“]

9.6.   Допълнение 6 Запис тип-2: дефиниции

В колонката за задължителност: O = незадължително, M = задължително, C = под условие

В колонката за вид символ: A = буквен, N = числов, B = бинарен

1* допустимите символи са [„0..9“, „A..Z“, „a..z“, „_“, „.“, „ “, „—“]

9.7.   Допълнение 7 Кодове за компресия в сивата скала

Кодове за компресия

9.8.   Допълнение 8 Спецификация на съобщенията

За подобряване на вътрешните работни процеси, в полето „Предмет“ на транзакциите, осъществявани по линия на Прюм, трябва да се попълнят кодът (CC) на държавата-членка, която изпраща съобщението, и типът на транзакцията (ТОТ поле 1.004)

Формат: CC/тип транзакция

Пример: „DE/CPS“

Съобщението може да бъде без съдържание.

ГЛАВА 3: Обмен на данни за регистрацията на превозни средства

1.   Общ набор от данни за автоматизирано търсене на данни за регистрацията на превозни средства

1.1.   Определения

Определенията за задължителните елементи и незадължителните елементи на данните, посочени в член 16, параграф 4, са следните:

Задължително (M):

Този елемент трябва да бъде съобщен, когато има налична информация в националния регистър на държавата-членка. Следователно информацията се обменя задължително, когато е налична.

Незадължително (O):

Този елемент може да бъде съобщен, когато има налична информация в националния регистър на държавата-членка. Следователно не е задължително да се обменя информация, дори когато тя е налична.

Всеки елемент от набора данни се обозначава с (Y), когато този елемент се определя като особено важен във връзка с Решение 2008/615/ПВР.

1.2.   Търсене на превозно средство/собственик/ползвател

1.2.1.    Повод за търсене

Съществуват два различни начина за търсене на информацията, които са определени по-долу:

Посредством тези критерии за търсене се получава информация, свързана с едно, а понякога и повече превозни средства. Ако се получи информация само за едно превозно средство, всички единици информация се поместват в един отговор. Ако са намерени повече превозни средства, държавата-членка, към която е отправено искането, може да определи кои информационни единици да изпрати в отговора — всички единици или само единиците, с които да се усъвършенства търсенето (напр. поради съображения, свързани с неприкосновеността на личния живот, или съображения за качество на работата).

Информационните единици, необходими за усъвършенстване на търсенето, са дадени в точка 1.2.2.1. В точка 1.2.2.2 е описана изчерпателно цялата информация.

Когато се прави търсене по номер на шаси, референтна дата и час, то може да се направи в една от участващите държави-членки или във всичките.

Когато се прави търсене по номер на свидетелство за управление, референтна дата и час, то трябва да се направи в една конкретна държава-членка.

Обикновено за търсене се използват датата и часът към момента, но е възможно да се извърши търсене с референтна дата и час в миналото. Когато се извършва търсене по референтна дата и час в миналото, а историческа информация не е налична в регистъра на съответната държава-членка, понеже такава регистрирана информация отсъства, информацията може да се изпрати, като се посочи, че тази информация е информация към момента.

1.2.2.    Набор от данни

2.   Сигурност на данните

2.1.   Обзорен преглед

Софтуерното приложение EUCARIS се използва за защитена комуникация с другите държави-членки и за съобщения, подавани в XML-формат обратно към „наследените“ системи на държавите-членки. Държавите-членки обменят съобщения, като ги изпращат директно на получателя. Центърът за електронни данни на държавата-членка е свързан с мрежата TESTA на ЕС.

По мрежата се изпращат криптирани съобщения в XML-формат. За криптиране на съобщенията се използва методът SSL. Съобщенията, които се връщат обратно, са в обикновен текстови XML-формат, тъй като връзката между приложението и т.нар. „back-end“ става в защитена среда.

Осигурено е клиентско програмно приложение, което се използва в държавата-членка за търсене в собствения ѝ регистър или в регистрите на другите държави-членки. Клиентите се идентифицират посредством потребителско име за идентификация/парола или клиентски сертификат. Връзката с потребителя може да е криптирана, но това е задължение на всяка отделна държава-членка.

2.2.   Характеристики на сигурността, свързани с обмена на съобщения

Сигурността е проектирана на основата на съчетание от HTTPS и XML-подпис. При този вариант се използва XML-подпис за подписване на всички съобщения, които се изпращат до сървъра, като чрез проверка на подписа се удостоверява кой е подателят на съобщението. Едностранен SSL (само сертификат на сървъра) се използва за защита на поверителността и целостта на съобщението по време на изпращане и се осигурява защита от атаки с цел изтриване/„прослушване“ или вмъкване. Вместо първоначално предвидената разработка на софтуер за внедряване на двустранен SSL, беше внедрен XML-подпис. Използването на XML-подпис се доближава повече до пътната карта на уебуслугите отколкото двустранният SSL и следователно е по-стратегическо решение.

XML-подписът може да се внедри по няколко начина, но избраният подход е да се използва XML-подпис като част от сигурността на услугите в глобалната мрежа (WSS). В WSS се уточнява как да се използва XML-подписът. Тъй като WSS е разработен на основата на стандарта SOAP, логично е да спазваме възможно най-точно стандарта SOAP.

2.3.   Характеристики на сигурността, несвързани с обмена на съобщения

2.3.1.    Автентикация на потребителите

Автентикацията на потребителите на уебприложението Eucaris се осъществява посредством потребителско име и парола. Тъй като се използва стандартната автентикация на Windows, държавите-членки могат при необходимост да увеличат степента на автентикация на потребителите, като използват клиентски сертификати.

2.3.2.    Функции на потребителя

Софтуерното приложение на Eucaris поддържа различни потребителски функции. За всяка категория услуги се получава отделно разрешение — напр. потребители (с изключителни права) на функционалността „Договор за Eucaris“ нямат право да използват функционалността „Прюм“. Услугите по администрирането са отделени от обичайните функции на крайния потребител.

2.3.3.    Регистриране и проследяване на обмен на съобщения

Регистрирането на всички видове съобщения е улеснено от софтуерното приложение Eucaris. Посредством една от функциите за администриране националният администратор може да установи кои съобщения са регистрирани: искания от крайни потребители, входящи искания от други държави-членки, информация, предоставяна от национални регистри и т.н.

Приложението може да се конфигурира при това регистриране да използва вътрешна база данни или външна база данни (Oracle). Ясно е, че решението за това какви съобщения да се регистрират зависи от съоръженията за тази цел на други места — в „наследените“ системи, и от това с какви клиентски приложения има връзка.

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

Посредством комбинираното регистриране в двете държави — отправилата искането и отговарящата — е възможно да се проследи напълно всеки обмен на съобщения (напр. по искане на замесено лице).

Регистрирането се потвърждава чрез уебклиента на Eucaris (меню Administration, Logging configuration). Функционалността за регистрирането се изпълнява от централната система. Когато е активирана функцията за регистриране, цялото съобщение (заглавна и съдържателна част) се съхранява в един регистърен запис. Възможно е да се зададе ниво на регистриране за определена услуга и за вид съобщения.

Нива на регистриране

Възможни са следните нива на регистриране:

Private — регистриране на съобщение: Регистрирането НЕ е достъпно за регистърната услуга за извличане, но е достъпно само на национално равнище, за одитиране и решаване на проблеми.

None — съобщението не се регистрира.

Видове съобщения

В информационния обмен между държавите-членки се включват различни видове съобщения, които са представени схематично по-долу.

Възможните видове съобщения (в показаната на фигурата централна система Eucaris за държавата-членка Х) са:

Фигура: Видове съобщения за регистриране

2.3.4.    Хардуерен модул за сигурност

Не се използва хардуерен модул за сигурност.

Хардуерният модул за сигурност (HSM) осигурява добра защита на ключа, който се използва за подписване на съобщенията и идентифициране на сървърите. С това се допълва цялостното ниво на сигурност, на HSM представлява висок разход за покупка/поддръжка и няма изискване за това какво решение да се вземе — за FIPS 140-2 ниво 2 или ниво 3 HSM Тъй като се използва затворена мрежа, при която заплахите се овладяват ефективно, решението е първоначално да не се използва хардуерен модул за сигурност (HSM). Ако се появи необходимост от хардуерен модул за сигурност (HSM), напр. с цел акредитация, той може да се добави към архитектурата.

3.   Технически условия на обмена на данните

3.1.   Общо описание на приложението EUCARIS

3.1.1.    Обзорен преглед

Софтуерното приложение EUCARIS свързва всички участващи държави-членки в мрежа, в която всяка държава-членка комуникира директно с друга държава-членка. За установяване на комуникацията не е необходим централен компонент. Приложението EUCARIS се използва за защитена комуникация с другите държави-членки и за съобщения, подавани в XML-формат обратно към „наследените“ системи на държавите-членки. Тази архитектура е показана на схемата по-долу.

Държавите-членки обменят съобщения, като ги изпращат директно на получателя. Центърът за електронни данни на държавата-членка е свързан с мрежата, която се използва за обмен на съобщенията (TESTA). Държавите-членки получават достъп до мрежата TESTA посредством националния си портал за достъп до мрежата TESTA. За връзката с мрежата е необходимо да се използва firewall, а приложението Eucaris да е свързано чрез рутер с този firewall. В зависимост от избрания вариант за защита на съобщенията, се използва сертификат или от рутера, или от приложението Eucaris.

Осигурено е клиентско програмно приложение, което се използва в дадена държава-членка за търсене в собствения ѝ регистър или в регистрите на други държави-членки. Клиентското приложение се свързва с Eucaris. Клиентите се идентифицират посредством потребителско име за идентификация/парола или клиентски сертификат. Връзката с потребител във външна организация (напр. полицейска служба) може да е криптирана, но това е задължение на всяка отделна държава-членка.

3.1.2.    Обхват на системата

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

Държавите-членки могат да изберат да използват функционалността „Eucaris клиент“ или да си направят собствено клиентско приложение. В таблицата по-долу е описано кои аспекти на системата Eucaris се използват задължително и/или се препоръчват и кои не е задължително да се използват и/или се определят по преценка на държавата-членка.

3.2.   Функционални и нефункционални изисквания

3.2.1.    Обща функционалност

В този раздел се прави общо описание на общите функции.

3.2.2.    Използваемост

3.2.3.    Надеждност

3.2.4.    Работни показатели

3.2.5.    Сигурност

3.2.6.    Приспособимост

3.2.7.    Обслужване и поддръжка

3.2.8.    Проектни изисквания

3.2.9.    Приложими стандарти

ГЛАВА 4: Оценяване

1.   Процедура за оценяване съгласно член 20 (подготовка на решения в съответствие с член 25, параграф 2 от Решение 2008/615/ПВР)

1.1.   Въпросник

Съответната работна група на Съвета съставя въпросник във връзка с всеки автоматизиран обмен на данни, както е посочено в глава 2 от Решение 2008/615/ПВР.

Държавата-членка попълва съответния въпросник веднага щом счете, че е изпълнила необходимите условия за дадена категория данни.

1.2.   Пилотно изпитване

С цел оценяване на резултатите от въпросника държавата-членка, която желае да започне обмен на данни, провежда изпитване заедно с една или повече държави-членки, които вече обменят данни по решението на Съвета. Пилотното изпитване се провежда преди или скоро след посещението за оценка.

Условията и редът за пилотното изпитване ще се установят от съответната работна група на Съвета и ще се основават на предварителни, отделно сключени споразумения със съответната държава-членка. Държавите-членки, които участват в пилотното изпитване, ще вземат решение по отношение на практическите подробности.

1.3.   Посещение за оценка

С цел оценяване на резултатите от въпросника се провежда посещение за оценка в държавата-членка, която желае да започне обмен на данни.

Условията и редът за провеждане на посещението ще се установят от съответната работна група и ще се основават на предварителни индивидуални споразумения със съответната държава-членка и екипа, който ще извърши оценката. Съответната държава-членка ще създаде условия на оценяващия екип да провери автоматизирания обмен на данни от категорията или категориите, които са предмет на оценката, по-специално като организира програмата за посещението съобразно изискванията на оценяващия екип.

В срок от един месец оценяващият екип ще изготви доклад за посещението за оценка и ще го изпрати на съответната държава-членка за коментар. Ако е уместно, оценяващият екип ще преработи този доклад въз основа на направените от държавата-членка коментари.

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

Членовете на оценяващия екип ще се съобразят с поверителния характер на информацията, която им стане известна по време на изпълнение на тази задача.

1.4.   Докладване на Съвета

Съгласно член 25, параграф 2 от Решение 2008/615/ПВР, на Съвета се предоставя пълен доклад за оценката, в който са представени обобщено резултатите от въпросниците, посещението за оценка и пилотното изпитване.

2.   Процедура за оценяване съгласно член 21

2.1.   Статистика и доклад

Всяка държава-членка ще съставя статистика относно резултатите от автоматизирания обмен на данни. За да се осигури съпоставимост, моделът за съставяне на статистиката ще се определи от съответната работна група на Съвета.

Тази статистика ще се изпраща ежегодно на генералния секретариат, който ще изготвя обобщен преглед за изтеклата година, а също и на Комисията.

Освен това, от държавите-членки ще се изисква редовно, но не по-често от веднъж годишно, да подават информация за административните, техническите и финансовите аспекти на осъществявания автоматизиран обмен на данни, която е необходима за анализиране и усъвършенстване на процеса. Въз основа на тази информация ще бъде изготвен доклад за Съвета.

2.2.   Преразглеждане

В разумен срок Съветът ще разгледа механизма за оценяване, който е описан тук, и ще го преработи както е необходимо.

3.    Експертни заседания

В рамките на съответната работна група на Съвета ще се провеждат редовни срещи на експерти с цел организирането и изпълнението на горепосочените процедури за оценяване, както и за обмен на опит и обсъждане на евентуални подобрения. При възможност, резултатите от обсъжданията на експертите ще се включват в доклада, посочен в точка 2.1 по-горе.