text:
полета:
 Полета
 Вид
 Описание
 source_isocode
 String
 ISO 3166-2 code of the requesting State
 destination_isocode
 String
 ISO 3166-2 code of the requested State
 request_id
 String
 unique Identifier for a request
 date
 Date
 Date of creation of message
 time
 Time
 Time of creation of message
 4.2.3. Съдържание на данните за профили по линия на Прюм (Content of PRUEM Profile data)
 4.2.3.1.
 Данни по линия на Прюм (PRUEM_datas)
 Тази структура описва частта за данни за профила на XML-файла. Съдържа следните полета:
 Полета
 Вид
 Описание
 reqtype
 PRUEM request type
 Вид искане (член 530 или 531)
 date
 Date
 Date profile stored
 type
 PRUEM_datas_type
 Type of profile
 result
 PRUEM_datas_result
 Result of request
 agency
 String
 Name of corresponding unit responsible for the profile
 profile_ident
 String
 Unique State profile ID
 message
 String
 Error Message, if result = E
 profile
 IPSG_DNA_profile
 If direction = A (Answer) AND result ≠ H (Hit) empty
 match_id
 String
 In case of a HIT PROFILE_ID of the requesting profile
 quality
 PRUEM_hitquality_type
 Quality of HIT
 hitcount
 Integer
 Count of matched Alleles
 rescount
 Integer
 Count of matched profiles. If direction = R (Request), then empty. If quality!=0 (the original requested profile), then empty.
 4.2.3.2.
 Тип искане по линия на Прюм (PRUEM_request_type)
 Тип данни, съдържащи се в съобщението — възможни стойности:
 Стойност
 Описание
 3
 Искания по член 530
 4
 Искания по член 531
 4.2.3.3.
 Тип качество на съвпадения по линия на Прюм (PRUEM_hitquality_type)
 Стойност
 Описание
 0
 Referring original requesting profile:
 Case ‘No HIT’: original requesting profile sent back only;
 Case ‘HIT’: original requesting profile and matched profiles sent back.
 1
 Equal in all available alleles without wildcards
 2
 Equal in all available alleles with wildcards
 3
 HIT with Deviation (Microvariant)
 4
 HIT with mismatch
 4.2.3.4.
 Тип данни по линия на Прюм (PRUEM_data_type)
 Тип данни, съдържащи се в съобщението — възможни стойности:
 Стойност
 Описание
 P
 Person profile
 S
 Stain
 4.2.3.5.
 PRUEM_data_result
 Тип данни, съдържащи се в съобщението — възможни стойности:
 Стойност
 Описание
 U
 Undefined, If direction = R (request)
 H
 HIT
 N
 No HIT
 E
 Error
 4.2.3.6.
 IPSG_DNA_profile
 Структура, описваща ДНК профил. Съдържа следните полета:
 Полета
 Вид
 Описание
 ess_issol
 IPSG_DNA_ISSOL
 Group of loci corresponding to the ISSOL (standard group of Loci of Interpol)
 additional_loci
 IPSG_DNA_additional_loci
 Other loci
 marker
 String
 Method used to generate of DNA
 profile_id
 String
 Unique identifier for DNA profile
 4.2.3.7.
 IPSG_DNA_ISSOL
 Структура, съдържаща локусите на ISSOL (стандартния набор на Интерпол от локуси). Съдържа следните полета:
 Полета
 Вид
 Описание
 vwa
 IPSG_DNA_locus
 Locus vwa
 th01
 IPSG_DNA_locus
 Locus th01
 d21s11
 IPSG_DNA_locus
 Locus d21s11
 fga
 IPSG_DNA_locus
 Locus fga
 d8s1179
 IPSG_DNA_locus
 Locus d8s1179
 d3s1358
 IPSG_DNA_locus
 Locus d3s1358
 d18s51
 IPSG_DNA_locus
 Locus d18s51
 amelogenin
 IPSG_DNA_locus
 Locus amelogin
 4.2.3.8.
 IPSG_DNA_additional_loci
 Структура, съдържаща другите локуси. Съдържа следните полета:
 Полета
 Вид
 Описание
 tpox
 IPSG_DNA_locus
 Locus tpox
 csf1po
 IPSG_DNA_locus
 Locus csf1po
 d13s317
 IPSG_DNA_locus
 Locus d13s317
 d7s820
 IPSG_DNA_locus
 Locus d7s820
 d5s818
 IPSG_DNA_locus
 Locus d5s818
 d16s539
 IPSG_DNA_locus
 Locus d16s539
 d2s1338
 IPSG_DNA_locus
 Locus d2s1338
 d19s433
 IPSG_DNA_locus
 Locus d19s433
 penta_d
 IPSG_DNA_locus
 Locus penta_d
 penta_e
 IPSG_DNA_locus
 Locus penta_e
 fes
 IPSG_DNA_locus
 Locus fes
 f13a1
 IPSG_DNA_locus
 Locus f13a1
 f13b
 IPSG_DNA_locus
 Locus f13b
 se33
 IPSG_DNA_locus
 Locus se33
 cd4
 IPSG_DNA_locus
 Locus cd4
 gaba
 IPSG_DNA_locus
 Locus


text:
gaba
 4.2.3.9.
 IPSG_DNA_locus
 Структура, описваща локус. Съдържа следните полета:
 Полета
 Вид
 Описание
 low_allele
 String
 Lowest value of an allele
 high_allele
 String
 Highest value of an allele
 5. Архитектура на приложението, сигурността и комуникациите
 5.1. Обзорен преглед
 При внедряването на приложенията за обмен на ДНК данни в рамките на трета част, дял II от настоящото споразумение се използва обща комуникационна мрежа, която е логически затворена между държавите. С цел експлоатиране по по-ефективен начин на тази обща комуникационна инфраструктура за изпращане на искания и получаване на отговори се възприема асинхронен механизъм за предаване на исканията за ДНК данни и дактилоскопични данни в капсулирани SMTP електронни съобщения. С цел да се удовлетворят изискванията за сигурност, като разширение на SMTP функционалността ще се използва механизъм s/MIME, за да се установи действително затворен сигурен „тунел“ за работата в мрежата.
 Оперативните трансевропейски телематични услуги между администрациите (TESTA) се използват за комуникационна мрежа за обмена на данни между държавите. TESTA се управлява от Европейската комисия. С оглед на факта, че националните ДНК бази данни и действащите национални точки за достъп до TESTA могат да бъдат разположени на различни места в държавите, достъпът до TESTA може да се осигури, като:
 1.
 се използват съществуващите национални точки за достъп или се създаде нова национална точка за достъп до TESTA; или
 2.
 се създаде защитена местна връзка от обекта, където е разположена ДНК базата данни, управлявана от компетентната национална служба, до съществуващата национална точка за достъп до TESTA.
 Протоколите и стандартите, внедрени в приложенията, използвани за изпълнението на трета част, дял II от настоящото споразумение, съответстват на отворените стандарти и отговарят на изискванията, наложени от органите, определящи националната политика по отношение на сигурността в държавите.
 5.2. Архитектура на горното ниво
 В обхвата на трета част, дял II от настоящото споразумение всяка държава ще прави налични своите ДНК данни за целите на обмена на такива данни и/или търсения в тях от други държави в съответствие със стандартизирания общ формат на данните. Архитектурата е основана на комуникационен модел, при който се осъществява връзка „от всеки до всеки“. Не съществува централен компютърен сървър, нито централизирана база данни за съхранение на ДНК профили.
 Освен спазването на националните правни ограничения, касаещи съответните обекти в държавите, всяка държава може да реши какъв вид хардуер и софтуер следва да се внедри за конфигуриране в съответния обект, така че да са спазени изискванията на трета част, дял II от настоящото споразумение.
 5.3. Стандарти за сигурност и защита на данните
 Три са нивата на сигурност, които са взети под внимание и са въведени.
 5.3.1. На ниво данни
 Предоставяните от всяка държава данни за ДНК профили трябва да се изготвят в съответствие с общите стандарти за защита на данните, така че отправилите искането държави да получат отговор, в който основно се посочва наличие на съответствие или липса на съответствие (HIT/Nо-HIT) заедно с идентификационен номер в случай на съответствие, но в него не се съдържа никаква лична информация. По-нататъшното разследване след уведомяване за наличие на съвпадение се води на двустранно равнище съгласно съществуващите вътрешни правни и организационни разпоредби, уреждащи съответните обекти

type: contracts

jurisdiction: EU


text:
в държавите.
 5.3.2. На ниво комуникация
 Съобщенията, съдържащи информация за ДНК профили (искания и отговори), се криптират посредством най-модерен механизъм в съответствие с отворените стандарти, като s/MIME, преди да се изпратят в съответните обекти в другите държави.
 5.3.3. На ниво предаване
 Всички криптирани съобщения, съдържащи информация за ДНК профили, се изпращат в обектите на другите държави посредством виртуална частна тунелираща система, администрирана от надежден доставчик на мрежови услуги на международно равнище и връзките за сигурност към тази тунелираща система са под национално управление. Виртуалната частна тунелираща система няма никаква точка на контакт с откритата интернет мрежа.
 5.4. Протоколи и стандарти, които да се използват за механизма за криптиране: s/MIME и свързани пакети
 Отвореният стандарт s/MIME, като разширение на действащия de facto стандарт за електронна поща SMTP, ще се внедри за криптиране на съобщения, съдържащи информация за ДНК профили. Протоколът s/MIME (V3) позволява електронно подписани разписки, етикети за сигурност и защитени списъци с електронни адреси (mailing lists), като е базиран върху „пласта“ на Cryptographic Message Syntax (CMS), (Internet Engineering Task Force (IETF) спецификация за защитени чрез криптиране съобщения. Той може да се използва за електронно подписване, резюмиране, автентификация или криптиране на всякакви форма цифрови данни.
 Сертификатът, на базата на който се прилага механизмът s/MIME, трябва да съответства на стандарта X.509. С цел да се осигурят стандарти и процедури, които са общи с тези за други приложения, използвани по линия на Прюм, правилата за обработване за операциите по криптиране на базата на s/MIME или за прилагане в различни видове среда на базата на готови търговски продукти Commercial Product of the Shelves (COTS), са следните:
 —
 последователността на операциите е: първо криптиране и след това подписване,
 —
 за симетрично и асиметрично криптиране се прилагат съответно алгоритмите за криптиране AES (Advanced Encryption Standard) с 256-битов ключ и RSA с 1024-битов ключ,
 —
 прилага се hash алгоритъм SHA-1.
 Функционалността s/MIME е вградена в повечето съвременни софтуерни пакети за електронна поща, в т.ч. Outlook, Mozilla Mail и Netscape Communicator 4.x, като позволява оперативна съвместимост между повечето основни софтуерни пакети за електронна поща.
 Поради лесното интегриране на s/MIME в националната ИТ инфраструктура във всички държави този механизъм е избран като подходящ с цел осигуряване на сигурността на ниво комуникации. С цел по-ефикасен „тест на концепцията“ (Proof of Concept) и намаляване на разходите обаче е избран стандартът JavaMail API, с който да се извърши прототипирането на обмена на ДНК данни. JavaMail API предоставя елементарно криптиране и декриптиране на електронни съобщения посредством s/MIME и/или OpenPGP. Целта е да се осигури прост и лесен за употреба програмно-приложен интерфейс (API) за клиентите за електронна поща, които желаят да изпращат и получават криптирани електронни съобщения в един от двата най-популярни формата за криптиране на електронни съобщения. Следователно, за да са изпълнени изискванията на трета част, дял II от настоящото споразумение, ще е достатъчно високотехнологично внедряване на базата на JavaMail API, като например продуктът на Bouncy Castle JCE (Java Cryptographic Extension), който ще се използва за въвеждането на s/MIME за прототипирането на обмена на ДНК данни между всички държави.
 5.5. Архитектура на приложението


text:
Всяка държава ще предостави на другите държави набор от стандартизирани данни за ДНК профили, които съответстват на използвания в момента общ документ за контрол на интерфейса (ICD). Това може да стане или чрез предоставяне на логически поглед върху индивидуалната национална база данни, или чрез установяване на физически експортирана база данни (индексирана база данни).
 Четирите основни компонента: сървърът за електронна поща/s/MIME, сървърът за приложението, зоната на структурирани данни (Data Structure Area) за извличане/подаване на данни и регистрация на входящите/изходящите съобщения, както и търсачката за сравняване, внедряват цялостната логика на приложението по начин, който не зависи от конкретните продукти.
 За да се осигури на всички държави възможност да интегрират лесно тези компоненти в съответните си национални обекти, конкретно определената обща функционалност е внедрена посредством компоненти с отворен код, които могат да се избират от всяка държава в зависимост от нейната национална политика и уредба в областта на ИТ. Поради независимите характеристики на внедряваната система за получаване на достъп до индексирани бази данни с ДНК профили, обхванати от трета част, дял II от настоящото споразумение, всяка държава може свободно да избира собствената си хардуерна и софтуерна платформа, включително системите за бази данни и операционните системи.
 Прототипът за обмена на ДНК данни е разработен и успешно изпитан в съществуващата обща мрежа. Версия 1.0 е внедрена в работната среда и се използва за ежедневната дейност. Държавите могат да използват разработения съвместно продукт, но също така могат да разработят свои продукти. Компонентите на общия продукт ще се поддържат, приспособяват и доразвиват в съответствие с изменящите се изисквания за функционалност по отношение на ИТ, криминалистиката и/или полицейската работа.
 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 файлове на десктопа.
 Работната логика на обработката на искания и отговори за ДНК профили в съответния обект на всяка държава е описана в дадената по-долу диаграма. Потоците на исканията и на отговорите взаимодействат с неутрална зона за данни, която обхваща различни масиви с еднакво структурирани данни.
 5.7. Комуникационна среда
 5.7.1.


text:
Обща комуникационна мрежа: TESTA и нейната последваща инфраструктура
 Приложението за обмен на ДНК данни ще използва електронната поща, асинхронен механизъм, за изпращане на искания и получаване на отговори между държавите. Тъй като всички държави разполагат с поне една точка за достъп до мрежата TESTA, обменът на ДНК данни ще се осъществява по мрежата TESTA. TESTA осигурява редица услуги с добавена стойност посредством своята система за предаване на електронна поща. Освен хостването на специално предназначени за TESTA електронни пощенски кутии, инфраструктурата може да работи със списъци за разпределяне на съобщения и политики за маршрутизиране. Това позволява TESTA да се използва като разпределителен център за съобщенията, адресирани до администрациите, свързани с домейните в рамките на ЕС. Възможно е също така да се включат и механизми за проверка за вируси.
 Системата на TESTA за предаване на електронна поща е изградена на базата на хардуерна платформа с висока степен на наличност, която е разположена в централното приложение на TESTA и е защитена с firewall. Чрез DNS (Domain Name Services) на TESTA ще се определят ресурсните локатори за IP адресите и ще се скрива информацията по адресирането от потребителя и от приложението.
 5.7.2. Обезпечаване на сигурността
 В рамките на TESTA е приложена концепцията за Virtual Private Network (VPN). Технологията за Tag Switching, която е използвана за изграждане на тази VPN, ще бъде доразвита, така че да поддържа стандарта MPLS (Multi-Protocol Label Switching), разработен от IETF.
 MPLS представлява стандартна технология на IETF, която ускорява мрежовия трафик, като избягва пакетния анализ посредством междинни рутери („hops“). Това се прави на базата на т.нар. „етикети“, които се прикрепват към пакета от edge рутерите в backbone въз основа на информацията, съхранена в информационната база за препращане (FIB). Етикети се използват и за внедряване на VPN.
 В MPLS се съчетават ползите от маршрутизирането в пласт 3 с предимствата на суичинга в пласт 2. Тъй като на IP адресите не се прави оценка при преминаването им през т.нар. „backbone“, MPLS не налага никакви ограничения на IP адресирането.
 Освен това електронните съобщения, предавани по TESTA, ще бъдат защитени с механизъм за криптиране на базата на s/MIME. Никой не може да декриптира съобщенията по мрежата, ако не знае ключа и не разполага със съответния сертификат.
 5.7.3. Протоколи и стандарти, които да се използват в комуникационната мрежа
 5.7.3.1.
 SMTP
 SMTP е действащият стандарт за пренос на електронна поща по Интернет. SMTP е относително прост текстови протокол, при който се определя един или повече получатели на съобщението, след което то се изпраща. SMTP използва TCP порт 25 по спецификациите на IETF. За да се определи SMTP сървърът за дадено име на домейн, се използва записване по MX (Mail eXchange) DNS (Domain Name Systems).
 Тъй като този протокол отначало беше изцяло и само текстови на базата на ASCII, той не работеше добре с бинарни файлове. Стандарти като MIME бяха разработени, за да се кодират бинарни файлове за изпращане чрез SMTP. Днес повечето SMTP сървъри поддържат 8BITMIME и s/MIME разширения, позволявайки изпращането на бинарни файлове да става почти толкова лесно, колкото и на обикновен текст. Правилата за работа


text:
при операции с s/MIME са описани в раздела „s/MIME“ (вж. раздел 5.4).
 SMTP представлява push протокол, който не позволява изтегляне на съобщения от физически отдалечен сървър по заявка. За да изтегли съобщение, клиентът за електронна поща трябва да използва POP3 или IMAP. За осъществяването на обмен на ДНК данни е решено да се използва POP3 протокол.
 5.7.3.2.
 POP
 Местните клиенти за електронна поща използват POP3 (Post Office Protocol version 3), протокол за интернет стандарт за пласта на приложението (application-layer Internet standard protocol), за да извлекат електронното съобщение от физически отдалечен сървър по TCP/IP връзка. Като използва профила SMTP Submit на SMTP протокола, клиентът за електронна поща изпраща съобщения по интернет или по корпоративна мрежа. MIME служи за стандарт за прикрепени файлове и текст, който не е ASCII, в електронното съобщение. Въпреки че нито POP3, нито SMTP изискват електронното съобщение да е в MIME формат, предаваните по интернет електронни съобщения са основно в MIME формат, така че POP клиентите трябва също така да разбират и да използват MIME. Поради това в цялата комуникационна среда на трета част, дял II от настоящото споразумение ще бъдат включени компонентите на POP.
 5.7.4. Определяне на интернет адреси
 Операционна среда
 Към момента Европейският орган за регистрация на IP адреси (RIPE) е определил за TESTA половин специализиран блок от подмрежа клас „В“. Определянето на IP адреси за държавите се основава на географска схема в Европа. Обменът на данни между държавите в рамките на трета част, дял II от настоящото споразумение се осъществява по логически затворената европейска IP мрежа.
 Изпитателна среда
 С цел да се осигури среда за безпрепятствено осъществяване на ежедневната работа между всички свързани държави, е необходимо да се установи изпитателна среда в защитената мрежа за новите държави, които се готвят да се присъединят към тези операции. Изготвен е документ с параметрите, включително IP адреси, мрежови настройки, домейни за електронна поща, както и потребителски акаунти за приложенията, които следва да се конкретизират и установят в съответните обекти на държавите. Освен това за целите на изпитванията е конструиран масив от псевдо-ДНК профили.
 5.7.5. Параметри на конфигурацията
 Създадена е защитена мрежа за електронна поща, за което е използван домейнът eu-admin.net. Този домейн с асоциираните му адреси няма да бъде достъпен от места извън домейна на TESTA за ЕС, тъй като имената са известни само на централния DNS сървър на TESTA, който е отделен от интернет със специална защита.
 Превръщането на тези адреси на сайтове (host names) в TESTA в съответните им IP адреси се осъществява от DNS услугите на TESTA. В този централен DNS сървър на TESTA се добавя вписване за пощата, като всички електронни съобщения, изпратени до местните домейни на TESTA, се предават на центъра за предаване на поща на TESTA. Този център за предаване на поща на TESTA след това ги препраща към конкретния сървър за електронна поща на местния домейн, като се използват адресите за електронна поща на местния домейн. Чрез предаването на електронната поща по този начин, критична информация, която се съдържа в електронните съобщения, ще преминава само по европейската защитената мрежова инфраструктура, а


text:
не по незащитен интернет.
 Необходимо е в обектите на всички държави да се установят поддомейни (получер курсив), следвайки следния синтаксис:
 „application-type.State-code.pruem.testa.eu“, където:
 „State-code“ приема стойността на един от двубуквените кодове на държавите (напр. AT, BE и т.н.).
 „application-type“ приема една от стойностите: DNA, FP или CAR.
 Като се приложи горепосоченият синтаксис, поддомейните на държавите са посочени в таблицата по-долу:
 States’ sub domains syntax
 Държава
 Поддомейн
 Забележки
 BE
 dna.be.pruem.testa.eu
 fp.be.pruem.testa.eu
 car.be.pruem.testa.eu
 test.dna.be.pruem.testa.eu
 test.fp.be.pruem.testa.eu
 test.car.be.pruem.testa.eu
 BG
 dna.bg.pruem.testa.eu
 fp.bg.pruem.testa.eu
 car.bg.pruem.testa.eu
 test.dna.bg.pruem.testa.eu
 test.fp.bg.pruem.testa.eu
 test.car.bg.pruem.testa.eu
 CZ
 dna.cz.pruem.testa.eu
 fp.cz.pruem.testa.eu
 car.cz.pruem.testa.eu
 test.dna.cz.pruem.testa.eu
 test.fp.cz.pruem.testa.eu
 test.car.cz.pruem.testa.eu
 DK
 dna.dk.pruem.testa.eu
 fp.dk.pruem.testa.eu
 car.dk.pruem.testa.eu
 test.dna.dk.pruem.testa.eu
 test.fp.dk.pruem.testa.eu
 test.car.dk.pruem.testa.eu
 DE
 dna.de.pruem.testa.eu
 fp.de.pruem.testa.eu
 car.de.pruem.testa.eu
 test.dna.de.pruem.testa.eu
 test.fp.de.pruem.testa.eu
 test.car.de.pruem.testa.eu
 EE
 dna.ee.pruem.testa.eu
 fp.ee.pruem.testa.eu
 car.ee.pruem.testa.eu
 test.dna.ee.pruem.testa.eu
 test.fp.ee.pruem.testa.eu
 test.car.ee.pruem.testa.eu
 IE
 dna.ie.pruem.testa.eu
 fp.ie.pruem.testa.eu
 car.ie.pruem.testa.eu
 test.dna.ie.pruem.testa.eu
 test.fp.ie.pruem.testa.eu
 test.car.ie.pruem.testa.eu
 EL
 dna.el.pruem.testa.eu
 fp.el.pruem.testa.eu
 car.el.pruem.testa.eu
 test.dna.el.pruem.testa.eu
 test.fp.el.pruem.testa.eu
 test.car.el.pruem.testa.eu
 ES
 dna.es.pruem.testa.eu
 fp.es.pruem.testa.eu
 car.es.pruem.testa.eu
 test.dna.es.pruem.testa.eu
 test.fp.es.pruem.testa.eu
 test.car.es.pruem.testa.eu
 FR
 dna.fr.pruem.testa.eu
 fp.fr.pruem.testa.eu
 car.fr.pruem.testa.eu
 test.dna.fr.pruem.testa.eu
 test.fp.fr.pruem.testa.eu
 test.car.fr.pruem.testa.eu
 HR
 dna.hr.pruem.testa.eu
 fp.hr.pruem.testa.eu
 car.hr.pruem.testa.eu
 test.dna.hr.pruem.testa.eu
 test.fp.hr.pruem.testa.eu
 test.car.hr.pruem.testa.eu
 IT
 dna.it.pruem.testa.eu
 fp.it.pruem.testa.eu
 car.it.pruem.testa.eu
 test.dna.it.pruem.testa.eu
 test.fp.it.pruem.testa.eu
 test.car.it.pruem.testa.eu
 CY
 dna.cy.pruem.testa.eu
 fp.cy.pruem.testa.eu
 car.cy.pruem.testa.eu
 test.dna.cy.pruem.testa.eu
 test.fp.cy.pruem.testa.eu
 test.car.cy.pruem.testa.eu
 LV
 dna.lv.pruem.testa.eu
 fp.lv.pruem.testa.eu
 car.lv.pruem.testa.eu
 test.dna.lv.pruem.testa.eu
 test.fp.lv.pruem.testa.eu
 test.car.lv.pruem.testa.eu
 LT
 dna.lt.pruem.testa.eu
 fp.lt.pruem.testa.eu
 car.lt.pruem.testa.eu
 test.dna.lt.pruem.testa.eu
 test.fp.lt.pruem.testa.eu
 test.car.lt.pruem.testa.eu
 LU
 dna.lu.pruem.testa.eu
 fp.lu.pruem.testa.eu
 car.lu.pruem.testa.eu
 test.dna.lu.pruem.testa.eu
 test.fp.lu.pruem.testa.eu
 test.car.lu.pruem.testa.eu
 HU
 dna.hu.pruem.testa.eu
 fp.hu.pruem.testa.eu
 car.hu.pruem.testa.eu
 test.dna.hu.pruem.testa.eu
 test.fp.hu.pruem.testa.eu
 test.car.hu.pruem.testa.eu
 MT
 dna.mt.pruem.testa.eu
 fp.mt.pruem.testa.eu
 car.mt.pruem.testa.eu
 test.dna.mt.pruem.testa.eu
 test.fp.mt.pruem.testa.eu
 test.car.mt.pruem.testa.eu
 NL
 dna.nl.pruem.nl.testa.eu
 fp.nl.pruem.testa.eu
 car.nl.pruem.testa.eu
 test.dna.nl.pruem.testa.eu
 test.fp.nl.pruem.testa.eu
 test.car.nl.pruem.testa.eu
 AT
 dna.at.pruem.testa.eu
 fp.at.pruem.testa.eu
 car.at.pruem.testa.eu
 test.dna.at.pruem.testa.eu
 test.fp.at.pruem.testa.eu
 test.car.at.pruem.testa.eu
 PL
 dna.pl.pruem.testa.eu
 fp.pl.pruem.testa.eu
 car.pl.pruem.testa.eu
 test.dna.pl.pruem.testa.eu
 test.fp.pl.pruem.testa.eu
 test.car.pl.pruem.testa.eu
 PT
 dna.pt.pruem.testa.eu
 fp.pt.pruem.testa.eu
 car.pt.pruem.testa.eu
 test.dna.pt.pruem.testa.eu
 test.fp.pt.pruem.testa.eu
 test.car.pt.pruem.testa.eu
 RO
 dna.ro.pruem.testa.eu
 fp.ro.pruem.testa.eu
 car.ro.pruem.testa.eu
 test.dna.ro.pruem.testa.eu
 test.fp.ro.pruem.testa.eu
 test.car.ro.pruem.testa.eu
 SI
 dna.si.pruem.testa.eu
 fp.si.pruem.testa.eu
 car.si.pruem.testa.eu
 test.dna.si.pruem.testa.eu
 test.fp.si.pruem.testa.eu
 test.car.si.pruem.testa.eu
 SK
 dna.sk.pruem.testa.eu
 fp.sk.pruem.testa.eu
 car.sk.pruem.testa.eu
 test.dna.sk.pruem.testa.eu
 test.fp.sk.pruem.testa.eu
 test.car.sk.pruem.testa.eu
 FI
 dna.fi.pruem.testa.eu
 fp.fi.pruem.testa.eu
 car.fi.pruem.testa.eu
 test.dna.fi.pruem.testa.eu
 test.fp.fi.pruem.testa.eu
 test.car.fi.pruem.testa.eu
 SE
 dna.se.pruem.testa.eu
 fp.se.pruem.testa.eu
 car.se.pruem.testa.eu
 test.dna.se.pruem.testa.eu
 test.fp.se.pruem.testa.eu
 test.car.se.pruem.testa.eu
 UK
 dna.uk.pruem.testa.eu
 fp.uk.pruem.testa.eu
 car.uk.pruem.testa.eu
 test.dna.uk.pruem.testa.eu
 test.fp.uk.pruem.testa.eu
 test.car.uk.pruem.testa.eu
 ГЛАВА 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
 →
 информация за трансакция
 Тип-2
 →
 буквено-цифрови данни за лица/случай
 Тип-4
 →
 дактилоскопични изображения с висока резолюция в сивата скала
 Тип-9
 →
 запис на признаци (minutiae)
 Тип-13
 →
 запис на изображение на следи с променлива резолюция
 Тип-15
 →
 запис на изображение на отпечатък от длан с променлива резолюция
 1.1. Тип-1 — заглавна част на файла
 Този запис съдържа маршрутизираща информация и информация, описваща структурата на останалата част от файла. В този тип записи също така се описват типовете трансакции, които попадат в следните по-широки категории:
 1.2. Тип-2 — описателен текст
 Този запис съдържа текстова информация, която е


text:
от интерес за изпращащата и получаващата служба.
 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 (вж. допълнение 39-7).
 1.6. Запис на изображение на отпечатък от длан с променлива резолюция
 Записи тип-15 на изображения с маркировка на полетата се използват за обмен на изображения на отпечатък от длан с променлива резолюция, придружавани от буквено-цифрова текстурна информация. Резолюцията на сканиране на изображенията е 500 пиксела/инч с 256 нива на сивото. За да се намали максимално обемът на данните, всички изображения на отпечатък от длан се компресират, като се използва WSQ алгоритъм. Ако е необходимо, по взаимно съгласие, резолюцията на изображенията може да се увеличи на повече от 500 пиксела/инч и повече от 256 нива на сивото. В този случай е препоръчително да се използва JPEG 2000 (вж. допълнение 39-7).
 2. Формат на записите
 Файлът за трансакция се състои от един или повече логически записа. За всеки логически запис, който се съдържа във файла, има по няколко информационни полета, подходящи за типа запис. Всяко информационно поле може да съдържа една или повече на брой информационни единици с единична стойност. Тези единици, взети заедно, се използват за предаване на различни аспекти на данните, които се съдържат в съответното поле. Информационното поле може да се състои също така от една или повече информационни единици, които са групирани и повторени неколкократно в рамките на полето. Групираните по този начин информационни единици са познати като подполе. Следователно информационното поле може да се състои от едно или повече подполета от информационни единици.
 2.1. Информационни разделители
 В логическите записи с тагови полета се прилагат механизми за отграничаване на информацията посредством използването на четири ASCII разделителя. По този начин могат да се отграничават отделни единици в рамките на полето или подполето, полетата в рамките на логическия запис или многократно появяващи се подполета.


text:
Разделителите на информацията са дефинирани в стандарта ANSI X3.4. Тези символи се използват за логическо разделяне и категоризиране на информацията. Представени йерархично, символът за разделяне на файлове (FS) има най-широк обхват, следван от символа за разделяне на групи (GS), символа за разделяне на записи (RS) и накрая — символа за разделяне на единици (US). В таблица 1 са изброени тези ASCII разделители и е дадено описание на употребата им в настоящия стандарт.
 Във функционално отношение информационните разделители следва да се разглеждат като указание за типа на данните, които следват. Със символ US се разделят отделни информационни единици в рамките на полето или подполето. Това е сигнал, че следващата информационна единица е част от данните за това поле или подполе. Множество подполета в рамките на същото поле, отделено със символ RS, сигнализира за започването на следваща група от повтаряща(и) се информационна(и) единица(и). Разделителният символ GS, използван между информационните полета, сигнализира за началото на ново поле, предшестващо идентификационния номер на полето, което се появява. По същия начин началото на нов логически запис се сигнализира от появата на символа FS.
 Четирите символа имат смисъл само когато са използвани като разделители на информационни единици в полетата на ASCII текстови записи. Когато тези символи се срещат в бинарни записи на изображения и бинарни полета, не им се придава конкретен смисъл — те представляват част от обменяните данни.
 Обикновено не следва да има празни полета или информационни единици, поради което между две единици данни следва да се появява само един разделител. Изключение от това правило възниква в тези случаи, когато данните в полетата или информационните единици на трансакцията не са налични, липсват или не са задължителни и обработката на трансакцията не зависи от присъствието на точно тези данни. В тези случаи се появяват няколко и съседни разделителни символа заедно, вместо да се изисква вмъкване на заместители на данни между разделителните символи.
 За дефиниране на поле, което се състои от три информационни единици, се прилага следното: ако липсва информацията за втората информационна единица, тогава се появяват два съседни разделителя US между първата и третата информационна единица; ако липсват и втората и третата информационна единица, тогава се използват три разделителни символа — два символа US в допълнение към символа за край на полето или към разделителния символ на подполето. По принцип, ако не са налични една или повече задължителни или незадължителни информационни единици в рамките на едно поле или подполе, следва да се постави съответният брой разделителни символи.
 Възможно е да се получат съседни комбинации от два или повече от четирите вида разделителни символи. Когато отсъстват или не са налични данни за информационните единици, подполета или полета, трябва да има един разделителен символ по-малко, отколкото са задължителните информационни единици, подполета или полета.
 Таблица 1
 Използвани разделители
 Код
 Тип
 Описание
 Хексадецимална стойност
 Децимална стойност
 US
 Unit Separator
 Separates information items
 1F
 31
 RS
 Record Separator
 Separates subfields
 1E
 30
 GS
 Group Separator
 Separates fields
 1D
 29
 FS
 File Separator
 Separates logical records
 1C
 28
 2.2. Изглед на записите
 При логическите записи с тагови полета всяко използвано информационно поле се


text:
номерира в съответствие с настоящия стандарт. Форматът за всяко поле се състои от номера на типа логически запис, следван от точка „.“, номер на полето, следван от двоеточие „:“, след което подходяща информация за това поле. Таговото поле може да се номерира с всяка цифра от едно до девет, като номерът се повява между точката „.“ и двоеточието „:“. Интерпретира се като номер на поле с непълно изписване. Това означава, че номерът на поле „2.123:“ е равностоен на номера на поле „2.000000123:“ и се интерпретира по същия начин.
 С цел илюстрация в настоящия документ се използват трицифрени номера за номериране на полетата, които се съдържат във всеки от описаните тук логически записи с тагови полета. Номерата на полетата са в следния формат: „TT.xxx:“ където „TT“ представлява едносимволен или двусимволен тип запис, следван от точка. Следващите три символа съставят съответния номер на полето, следван от двоеточие. След двоеточието се намира описателната 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 г. се счита за първа версия и се


text:
означава с „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), се изпраща следният логически запис:
 —
 1 Type-1 Record,
 —
 1 Type-2 Record.
 Ако се установи съвпадение (HIT), се изпраща следният логически запис:
 —
 1 Type-1 Record,
 —
 1 Type-2 Record,
 —
 1-14 Type-4 Record.
 В таблица A.6.1 (допълнение 39-6) е представен накратко TOT CPS.
 PMS (Print-to-Latent Search): търсене чрез сравняване на отпечатъци със следи. Тази трансакция се използва, когато в база данни с неидентифицирани следи се извършва търсене за определен набор отпечатъци. В отговора се съдържа решението за наличие или липса на съвпадение HIT/No-HIT при търсенето в AFIS по местоназначение. Ако има повече неидентифицирани следи, се отговаря с няколко SRE трансакции — по една отделна трансакция за всяка следа. Отпечатъците на лицето трябва да се включат във файла като WSQ компресирани изображения.
 Ако не се установи съвпадение (No-HIT), се изпраща следният логически запис:
 —
 1 Type-1 Record,
 —
 1 Type-2 Record.
 Ако се установи попадение (HIT), се изпраща следният логически запис:
 —
 1 Type-1 Record,
 —
 1 Type-2 Record,
 —
 1 Type-13 Record.
 В таблица A.6.1 (допълнение 39-6) е представен накратко TOT PMS.
 MPS (Latent-to-Print Search): търсене чрез сравняване на следи с отпечатъци. Тази трансакция се използва, когато трябва да се търсят съответствия на следи в база данни с отпечатъци. Във файла трябва да се включи информацията за признаците (minutiае) на следите и изображението (WSQ компресия).
 Ако не се установи попадение (No-HIT), се изпраща следният логически запис:
 —
 1 Type-1 Record,
 —
 1


text:
Type-2 Record.
 Ако се установи попадение (HIT), се изпраща следният логически запис:
 —
 1 Type-1 Record,
 —
 1 Type-2 Record,
 —
 1 Type-4 или Type-15 Record.
 В таблица A.6.4 (допълнение 39-6) е представен накратко TOT MPS.
 MMS (Latent-to-Latent Search): търсене чрез сравняване на следи със следи. При тази трансакция файлът съдържа следа, за която се прави търсене в база данни с неидентифицирани следи, за да се установи връзка между различни местопрестъпления. Във файла трябва да се включи информацията за признаците (minutiае) на следите и изображението (WSQ компресия).
 Ако не се установи попадение (No-HIT), се изпраща следният логически запис:
 —
 1 Type-1 Record,
 —
 1 Type-2 Record.
 Ако се установи попадение (HIT), се изпраща следният логически запис:
 —
 1 Type-1 Record,
 —
 1 Type-2 Record,
 —
 1 Type-13 Record.
 В таблица A.6.4 (допълнение 39-6) е представен накратко TOT MMS.
 SRE: Тази трансакция се изпраща от службата по местоназначение в отговор на заявка с дактилоскопични данни. В отговора се съдържа решението за наличие или липса на попадение HIT/No-HIT при търсенето в AFIS по местоназначение. Ако са налице няколко кандидати, се отговаря с няколко SRE трансакции — отделна трансакция за всеки кандидат.
 В таблица A.6.2 (допълнение 39-6) е представен накратко TOT SRE.
 ERR: тази трансакция се изпраща от AFIS по местоназначение, за да се посочи, че има грешка. В нея се включва поле за съобщение (ERM), в което се посочва установената грешка. Изпраща се следният логически запис:
 —
 1 Type-1 Record,
 —
 1 Type-2 Record.
 В таблица A.6.3 (допълнение 39-6) е представен накратко TOT ERR.
 Таблица 2
 Допустими кодове в трансакциите
 Тип трансакция
 Тип логически запис
 1
 2
 4
 9
 13
 15
 CPS
 M
 M
 M
 —
 —
 —
 SRE
 M
 M
 C
 —
 (C - при наличие на съвпадение на следи)
 C
 C
 MPS
 M
 M
 —
 M (1*)
 M
 —
 MMS
 M
 M
 —
 M (1*)
 M
 —
 PMS
 M
 M
 M*
 —
 —
 M*
 ERR
 M
 M
 —
 —
 —
 —
 Легенда:
 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


text:
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 е контролен символ, генериран по процедурата, описана в допълнение 39-2.
 Когато няма TCN, полето YYSSSSSSSS се запълва с нули и се генерира контролен символ по начина, описан по-горе.
 3.1.10. Поле 1.010: Контролен номер на отговора на трансакцията (Transaction Control Response — TCR)
 Когато има изпратено искане, на което настоящото се явява отговор, в това незадължително поле се дава контролният номер на трансакцията, с която е изпратено искането. Следователно, то има същия формат като TCN (поле 1.009).
 3.1.11. Поле 1.011: Резолюция на сканирането на мястото на произход (Native Scanning Resolution — NSR)
 В това поле се посочва нормалната резолюция на сканиране на системата, с която работи службата-подател на трансакцията. Резолюцията се посочва във формат на две числа, следвани от десетична точка и след това още две цифри.
 Всички трансакции, осъществявани по силата на членове 533 и 534 от настоящото споразумение, се подават във формат 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“ — секундата. Пълната дата не може да има стойност по-висока от


text:
стойността на настоящата дата.
 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)
 Това е уникален референтен номер, който се задава от национален орган за лице, срещу което за пръв път е повдигнато обвинение за извършено престъпление. В рамките на една страна едно лице не може никога да има повече от един


text:
референтен номер на правонарушител (CRN), нито да го поделя с друго лице. За едно и също лице обаче е възможно да има референтни номера на правонарушител в различни държави, които се разпознават по кода на съответната държава.
 За полето CRN е възприет следният формат: CC/номер
 където „CC“ представлява кода на държавата по Интерпол, с дължина два буквено-цифрови символа, като номерът е съобразен с действащите национални указания на издаващия орган и може да има дължина до 32 буквено-цифрови символа.
 За трансакциите по силата на членове 533 и 534 от настоящото споразумение това поле ще се използва за националния референтен номер на правонарушителя, зададен от службата по произход, който е свързан с изображенията в записите тип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), а отсъствие на попадение (No-HIT) за търсения случай се отбелязва с „N“. В третото поле се съдържа идентификаторът на поредицата за кандидата за резултат и общият брой кандидати, разделени с наклонена черта. Ако кандидатите са повече от един, се отговаря с няколко съобщения.
 В случай на евентуално попадение (HIT) в четвъртото подполе се съдържа резултатът с дължина до шест символа. Ако попадение (HIT) се потвърди, стойността на това подполе става „999999“.
 Пример: „CPS{}{RS}}I{}{RS}}001/001{}{RS}}999999{}{GS}}“
 Ако няма подаден резултат от отдалечената система AFIS, на съответното място се отбелязва нулев резултат.
 4.1.14. Поле 2.074: Статус/поле за съобщение за грешка (Status/Error Message Field — ERM)
 В това поле се съдържат съобщения за грешка в резултат на осъществена трансакция, които се изпращат на отправилата искането служба като част от трансакция за грешка.
 Таблица 3
 Съобщения за грешка
 Цифров код (1-3)


text:
Значение (5-128)
 003
 ERROR: UNAUTHORISED ACCESS
 101
 Mandatory field missing
 102
 Invalid record type
 103
 Undefined field
 104
 Exceed the maximum occurrence
 105
 Invalid number of subfields
 106
 Field length too short
 107
 Field length too long
 108
 Field is not a number as expected
 109
 Field number value too small
 110
 Field number value too big
 111
 Invalid character
 112
 Invalid date
 115
 Invalid item value
 116
 Invalid type of transaction
 117
 Invalid record data
 201
 ERROR: INVALID TCN
 501
 ERROR: INSUFFICIENT FINGERPRINT QUALITY
 502
 ERROR: MISSING FINGERPRINTS
 503
 ERROR: FINGERPRINT SEQUENCE CHECK FAILED
 999
 ERROR: ANY OTHER ERROR. FOR FURTHER DETAILS CALL DESTINATION AGENCY.
 Съобщения за грешка с номер между 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>...
 където:
 —
 error_code е код, зададен само за една определена причина (вж. таблица 3),
 —
 field_id е ANSI/NIST номерът на сгрешеното поле (напр. 1.001, 2.001,...) в следния формат <record_type>.<field_id>.<sub_field_id>,
 —
 dynamic text е по-подробното описание на грешката,
 —
 LF означава „въвеждане на ред“ (Line Feed) и служи за разделяне на отделните грешки, когато има повече от една такава,
 —
 за запис тип-1 се определя ICD „-1“.
 Пример:
 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)
 Видът на отпечатъка е еднобайтово


text:
поле, което заема шестият байт на записа.
 Таблица 4
 Вид пръстов отпечатък
 Код
 Описание
 0
 Live-scan of plain fingerprint
 1
 Live-scan of rolled fingerprint
 2
 Non-live scan impression of plain fingerprint captured from paper
 3
 Non-live scan impression of rolled fingerprint captured from paper
 4
 Latent impression captured directly
 5
 Latent tracing
 6
 Latent photo
 7
 Latent lift
 8
 Swipe
 9
 Unknown
 5.1.4. Поле 4.004: Позиция на пръста (Finger Position — FGP)
 Това поле с фиксирана дължина от 6 байта заема позициите 7—12 на запис тип-4. В него се съдържат възможните пръстови позиции, като се започва от най-левия байт (7-ия байт на записа). Известната или най-вероятна пръстова позиция се взема от таблица 5. Възможно е да се посочат до пет допълнителни пръста, като пръстовите позиции се впишат в съответния порядък в оставащите пет байта, за което се използва същият формат. Ако се посочват по-малко от пет пръстови позиции, неизползваните байтове се запълват с бинарно 255. За рефериране на всички пръстови позиции се използва код „0“ със значение „неизвестно“.
 Таблица 5
 Код на пръстовите позиции и максимален размер
 Позиция на пръста
 Пръстов код
 Широчина
 (mm)
 Дължина
 (mm)
 Unknown
 0
 40,0
 40,0
 Right thumb
 1
 45,0
 40,0
 Right index finger
 2
 40,0
 40,0
 Right middle finger
 3
 40,0
 40,0
 Right ring finger
 4
 40,0
 40,0
 Right little finger
 5
 33,0
 40,0
 Left thumb
 6
 45,0
 40,0
 Left index finger
 7
 40,0
 40,0
 Left middle finger
 8
 40,0
 40,0
 Left ring finger
 9
 40,0
 40,0
 Left little finger
 10
 33,0
 40,0
 Plain right thumb
 11
 30,0
 55,0
 Plain left thumb
 12
 30,0
 55,0
 Plain right four fingers
 13
 70,0
 65,0
 Plain left four fingers
 14
 70,0
 65,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-компресия (допълнение 39-7).
 5.1.9. Поле 4.009: Изображение
 Това поле съдържа поредица от байтове, която представлява самото изображение. Структурата му очевидно зависи от използвания алгоритъм за компресиране.
 6. Логически запис тип-9: запис на признаци (minutiae)
 Записите тип-9 съдържат


text:
ASCII-текст, описващ признаците (minutiае) и свързана кодирана информация от следи. При трансакция за търсене на следи няма ограничение за тези записи тип-9 в рамките на един файл, но всеки от тях следва да се отнася за различен изглед или следа.
 6.1. Извличане на признаци (minutiае)
 6.1.1. Идентификация на типа признак
 С този стандарт се определят три идентификационни номера, които се използват за описване на типа признак. Изброени са в таблица 6. Край на папиларна линия се означава като тип 1. Бифуркация се означава като тип 2. Ако даден признак не може да се определи ясно като един от горепосочените типове, той се означава като „друг“ („other“) — тип „0“.
 Таблица 6
 Типове признаци
 Тип
 Описание
 0
 Other
 1
 Ridge ending
 2
 Bifurcation
 6.1.2. Разположение и тип на признака
 За да отговарят образците на раздел 5 от стандарта ANSI INCITS 378-2004, разположението (място и ъгъл на въртене) на отделния признак се описва по следния метод, който е усъвършенстван вариант на действащия стандарт INCITS 378-2004.
 Позицията или местоположението на признака, който представлява край на папиларна линия, е точката на раздвояване на срединния скелет на междупапиларната бразда, разположена непосредствено пред края на папиларната линия. Ако трите отсечки на междупапиларната бразда се изтънят до скелет с широчина 1 пиксел, точката на пресичането им е местоположението на признака. Аналогично, местоположението на признака при бифуркация е точката на раздвояване на срединния скелет на папиларната линия. Ако всяка от трите отсечки на папиларната линия се изтъни до скелет с широчина 1 пиксел, точката на пресичане на трите отсечки е местоположението на признака.
 След като всички краища на папиларни линии са преобразявани в бифуркации, всички признаци на дактилоскопичното изображение се представят под формата на бифуркации. Пикселовите координати X и Y на пресечната точка на трите отсечки на всеки признак могат да се форматират директно. Определянето на вектора на признака може да се извлече от всяка скелетна бифуркация. Трите отсечки на всяка скелетна бифуркация трябва да се разгледат и да се определи крайната точка на всяка отсечка. На фигура 6.1.2 са илюстрирани трите метода, които се използват за определяне на край на отсечка, което се прави на базата на сканираща резолюция 500 ppi.
 Краят се установява според това кое събитие се прояви първо. Броят на пикселите се определя на базата на образ, сканиран с резолюция 500 ppi. Подразбира се, че при друга резолюция ще се използва различен брой пиксели.
 —
 Разстояние от.064" (32-ри пиксел)
 —
 Краят на скелетната отсечка, която се появява в разстоянието между.02" и.064" (от 10-и до 32-ри пиксел); не се използват по-къси отсечки
 —
 Втора бифуркация е открита на разстояние.064" (преди 32-рия пиксел)
 Ъгълът на признаците се определя, като се построят три виртуални лъча от точката на бифуркация до края на всяка отсечка. Ъглополовящата на най-малкия от трите ъгъла, образувани от лъчите, се използва за означаване на посоката на признака.
 6.1.3. Координатна система
 За изразяване на признаците на пръстов отпечатък се използва Декартова координатна система. Местоположението на признаците се представя от техните х и у координати. Началото на координатната система е горният ляв ъгъл на оригиналното


text:
изображение, като х нараства надясно, а у нараства надолу. И двете координати (х и у) на признаците се изразяват в пиксел единици, отстоящи от началото. Следва да се отбележи, че началната точка и мерните единици не съответстват на общоприетата система, използвана за дефинициите на тип-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). Това е идентификацията на „притежателя“ на формáта CBEFF, определена от Международната асоциация на биометричната индустрия (IBIA) за Техническия комитет INCITS М1. Символът <US> се отделя с разделителен символ от типа формат CBEFF, на който се задава стойност „513“ (0x0201), за да се означи, че в този запис се съдържат само данни за местоположението и ъгловия вектор без информация за Extended Data Block. Символът <US> се отделя с разделителен символ от продуктовия идентификатор по CBEFF (CBEFF Product Identifier — PID), с който се идентифицира „притежателят“ на кодиращото оборудване. Тази стойност се задава от фирмата производител. Стойността може да се вземе от уебсайта на IBIA (www.ibia.org), ако е публикувана там.
 6.2.6. Поле 9.127: Идентификация на оборудването за „улавяне на образ“
 В това поле има две информационни единици, разделени със символа <US>. Първата единица съдържа APPF, ако оборудването, използвано за добиване на първоначалния образ, има сертификат за съответствие


text:
с допълнение F (IAFIS Image Quality Specification, 29 януари 1999 г.) по CJIS-RS-0010, спецификацията на Федералното бюро за разследване за изпращане на пръстови отпечатъци. Ако оборудването не отговаря на това изискване, се вписва стойност NONE. Втората информационна единица съдържа идентификацията на оборудването за „улавяне на образ“, която е продуктовият номер, зададен от фирмата-производител, за съответното оборудване. Стойност 0 показва, че идентификацията на оборудването за „улавяне на образ“ е неизвестна.
 6.2.7. Поле 9.128: Дължина на хоризонталния ред (Horizontal line length — HLL)
 В това задължително ASCII поле се задава броят на пикселите, които се съдържат в един хоризонтален ред на изпращаното изображение. Максималният размер на хоризонтален ред достига до 65534 пиксела.
 6.2.8. Поле 9.129: Дължина на вертикалната линия (Vertical line length -VLL)
 В това задължително ASCII поле се задава броят на хоризонталните редове, които се съдържат в изпращаното изображение. Максималният размер на вертикален ред достига до 65534 пиксела.
 6.2.9. Поле 9.130: Мащабни единици (Scale units — SLC)
 В задължително ASCII-поле се посочват единиците, използвани за описание на честотата на дискретизация на изображението (плътност на пикселите). В това поле стойност 1 показва броя на пикселите на 1 инч, а 2 показва пикселите на 1 сантиметър. Стойност 0 в това поле показва, че не е даден мащаб. В този случай съотношението на страните на пикселите се определя като коефициент HPS/VPS.
 6.2.10. Поле 9.131: Хоризонтален мащаб в пиксели (HPS)
 В това задължително ASCII поле се задава числото на наситеност с пиксели по хоризонталата, при условие че в полето SLC има вписана стойност 1 или 2. В останалите случаи тя показва хоризонталния компонент на съотношението на страните на пикселите.
 6.2.11. Поле 9.132: Вертикален мащаб в пиксели (Horizontal 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: Данни за пръстовите признаци


text:
В това задължително поле има шест информационни единици, разделени със символа <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“ координати,


text:
изразени в пиксели. Третата информационна единица съдържа ъгловата стойност на делтата, изразена в единици от по 2 градуса. Стойността е положително число между 0 и 179. При повече центрове на папиларни образи, същите се разделят с разделителния символ <RS>.
 7. Запис тип-13 на изображение на следи с променлива резолюция
 Логическият запис тип-13 с тагови полета съдържа данни на изображение, получено от изображение на следи. Тези изображения са предназначени за изпращане на службите, които автоматично ще извлекат или ще осигурят интервенция на служители и обработка с цел получаване на желаната характеризираща информация от изображенията.
 Под формата на тагови полета в записа се дава информация относно използваната резолюция на сканиране, размера на изображението и други параметри, необходими за обработката на изображението.
 Таблица 7
 Запис тип-13: изображение на следи с променлива резолюция
 Идент.
 Код за задължи-телност
 Номер на полето
 Име на полето
 Вид символ
 Pазмер на полето за всяко използване
 Брой използвания
 Макс. брой байтове
 мин.
 макс.
 мин.
 макс.
 LEN
 M
 13.001
 LOGICAL RECORD LENGTH
 N
 4
 8
 1
 1
 15
 IDC
 M
 13.002
 IMAGE DESIGNATION CHARACTER
 N
 2
 5
 1
 1
 12
 IMP
 M
 13.003
 IMPRESSION TYPE
 A
 2
 2
 1
 1
 9
 SRC
 M
 13.004
 SOURCE AGENCY/ORI
 AN
 6
 35
 1
 1
 42
 LCD
 M
 13.005
 LATENT CAPTURE DATE
 N
 9
 9
 1
 1
 16
 HLL
 M
 13.006
 HORIZONTAL LINE LENGTH
 N
 4
 5
 1
 1
 12
 VLL
 M
 13.007
 VERTICAL LINE LENGTH
 N
 4
 5
 1
 1
 12
 SLC
 M
 13.008
 SCALE UNITS
 N
 2
 2
 1
 1
 9
 HPS
 M
 13.009
 HORIZONTAL PIXEL SCALE
 N
 2
 5
 1
 1
 12
 VPS
 M
 13.010
 VERTICAL PIXEL SCALE
 N
 2
 5
 1
 1
 12
 CGA
 M
 13.011
 COMPRESSION ALGORITHM
 A
 5
 7
 1
 1
 14
 BPX
 M
 13.012
 BITS PER PIXEL
 N
 2
 3
 1
 1
 10
 FGP
 M
 13.013
 FINGER POSITION
 N
 2
 3
 1
 6
 25
 RSV
 13.014
 RESERVED FOR FUTURE DEFINITION
 —
 —
 —
 —
 —
 —
 13.019
 COM
 O
 13.020
 COMMENT
 A
 2
 128
 0
 1
 135
 RSV
 13.021
 RESERVED FOR FUTURE DEFINITION
 —
 —
 —
 —
 —
 —
 13.199
 UDF
 O
 13.200
 USER-DEFINED FIELDS
 —
 —
 —
 —
 —
 —
 13.998
 DAT
 M
 13.999
 IMAGE DATA
 B
 2
 —
 1
 1
 —
 Легенда за вида символ: N = цифров; A = буквен; AN = буквено-цифров; B = бинарен
 7.1. Полета в логически запис тип-13:
 В следващите няколко параграфа са описани данните, които се съдържат във всяко от полетата в логически запис тип-13.
 В логически запис тип-13 данните се въвеждат в номерирани полета. Изискването е първите две полета на записа да са подредени в установен ред, а полето с данните на изображението е последното физическо поле в записа. В таблица 7 за всяко поле в запис тип-13 е посочен код за задължителност — задължително „M“ или незадължително „O“, номер на полето, наименование на полето, вид символ, размер на полето и колко пъти може да се използва. Използва се трицифрен номер на полето, като максималният брой на байтовете е даден в последната колонка. С увеличаване броя на цифрите


text:
в номера на полето се увеличава и максималният брой на байтовете. Двете стойности, които се вписват в „размер на полето за всяко използване“, включват всички разделителни символи, използвани в полето. В „максималния брой байтове“ се включва номерът на полето, информацията и всички разделителни символи, в т.ч. и символът 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 поле се вписва идентификацията на службата или организацията, която първоначално е изготвила изображението на лице, което се съдържа в записа. В това поле обикновено се вписва идентификаторът на службата на произход (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 в това поле показва, че не


text:
е даден мащаб. В този случай съотношението на страните на пикселите се определя като коефициент HPS/VPS.
 7.1.9. Поле 13.009: Хоризонтален мащаб в пиксели (HPS)
 В това задължително ASCII поле се задава числото на наситеност с пиксели по хоризонталата, при условие че в полето SLC има вписана стойност 1 или 2. В останалите случаи тя показва хоризонталния компонент на съотношението на страните на пикселите.
 7.1.10. Поле 13.010: Вертикален мащаб в пиксели (Horizontal pixel scale — VPS)
 В това задължително ASCII поле се задава числото на наситеност с пиксели по вертикалата, при условие че в полето SLC има вписана стойност 1 или 2. В останалите случаи тя показва вертикалния компонент на съотношението на страните на пикселите.
 7.1.11. Поле 13.011: Алгоритъм за компресиране (Compression algorithm — CGA)
 В това задължително ASCII поле се посочва алгоритъмът, използван за компресиране на изображения в сивата скала. Вж. в допълнение 39 кодовете за компресия.
 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)
 Тези полета могат да се дефинират от потребителя и се използват за бъдещи изисквания. Размерът и съдържанието им се определят от потребителя и


text:
са съгласувани със службата получател. Когато са попълнени, в тях се съдържа информация под формата на ASCII-текст.
 7.1.18. Поле 13.999: Данни на изображението (Image data — DAT)
 В това поле се намират всички данни на изображението на следа, направено посредством „capture“ технология. Полето винаги има стойност 999 и е последното физически разположено поле в записа. Например: Например след „13.999:“ има бинарно представени данни на изображение.
 Всеки пиксел от некомпресирани данни в сивата скала обикновено се изразява количествено в осем бита (256 нива на сивото), които се съдържат в един байт. Ако в BPX поле 15.012 е вписана стойност по-голяма или по-малка от 8, броят на байтовете, в които се съдържа един пиксел, е различен. Ако се използва компресия, пиксел-данните трябва да се компресират по начина, определен в полето GCA начин.
 7.2. Край на запис тип-13: изображение на следи с променлива резолюция
 За по-голяма прегледност, непосредствено след последния байт данни на поле 15.999 се поставя разделител FS, за да се раздели този от следващия логически запис. Този разделител трябва да се включи в полето за дължината на запис тип-13.
 8. Запис тип-15: изображение на отпечатък от длан с променлива резолюция
 Логически запис тип-15 с тагови полета съдържа и се използва за обмен на данни за изображение на отпечатък от длан, като в него има полета за фиксирана информация и за определена от потребителя информация, свързана с цифровизираното изображение. Под формата на тагови полета в записа се дава информация относно използваната резолюция на сканиране, размера на изображението и други параметри или бележки, необходими за обработката на изображението. Изпращаните на други служби изображения на длан се обработват от службите-получатели за извличане на желаната характеризираща информация, необходима за целите на сравняването.
 Данните на изображението се получават пряко от субект, който използва уред за сканиране на живо или карта, на която е снет отпечатък на длан, или други носители, на които има отпечатък на длан.
 Какъвто и да е методът за добиване на изображението на отпечатъка на длан, той трябва да има възможност за снемане на определен набор от изображения за всяка ръка. Този набор включва хипотенарната част на дланта, под формата на единично сканирано изображение, и пълната зона на изпънатата цяла длан от китката до върха на пръстите под формата на едно или две сканирани изображения. Ако са използвани две изображения за представяне на цялата длан, долното изображение показва дланта от китката до върха на междупръстието (ставата на третия пръст) и включва тенарната и хипотенарната област на дланта. Горното изображение обхваща зоната от долния край на междупръстието до върха на пръстите. По този начин се осигуряват достатъчно голяма зона на припокриване на двете изображения, и двете от които включват междупръстието на дланта. Чрез сравняване на папиларните линии и детайлите, които се съдържат в тази обща част, провеждащият изследването може да твърди с увереност, че двете изображения са на една и съща длан.
 Тъй като трансакцията за отпечатък на длан може да се използва за различни цели, тя може да съдържа изображения на една или повече уникални зони на дланта или цялата ръка. Пълният набор


text:
от отпечатъци на дланта на едно лице обикновено включва хипотенарната част на дланта и изображение(я) на цялата длан от всяка ръка. Тъй като логическият запис с тагови полета, който се използва за изображение, може да съдържа само едно бинарно поле, за всяка хипотенарна част на длан ще е необходим отделен запис тип-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: Дата на изготвяне


text:
на изображението на отпечатък от длан посредством „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
 Схема на запис тип-15 на изображение на отпечатък от длан с променлива резолюция
 Идент.
 Код за задължи-телност
 Номер на полето
 Име на полето
 Вид символ
 Pазмер на полето за всяко използване
 Брой използвания
 Макс. брой байтове
 мин.
 макс.
 мин.
 макс.
 LEN
 M
 15.001
 LOGICAL RECORD LENGTH
 N
 4
 8
 1
 1
 15
 IDC
 M
 15.002
 IMAGE DESIGNATION CHARACTER
 N
 2
 5
 1
 1
 12
 IMP
 M
 15.003
 IMPRESSION TYPE
 N
 2
 2
 1
 1
 9
 SRC
 M
 15.004
 SOURCE AGENCY/ORI
 AN
 6
 35
 1
 1
 42
 PCD
 M
 15.005
 PALMPRINT CAPTURE DATE
 N
 9
 9
 1
 1
 16
 HLL
 M
 15.006
 HORIZONTAL LINE LENGTH
 N
 4
 5
 1
 1
 12
 VLL
 M
 15.007
 VERTICAL LINE LENGTH
 N
 4
 5
 1
 1
 12
 SLC
 M
 15.008
 SCALE UNITS
 N
 2
 2
 1
 1
 9
 HPS
 M
 15.009
 HORIZONTAL PIXEL SCALE
 N
 2
 5
 1
 1
 12
 VPS
 M
 15.010
 VERTICAL PIXEL SCALE
 N
 2
 5
 1
 1
 12
 CGA
 M
 15.011
 COMPRESSION ALGORITHM
 AN
 5
 7
 1
 1
 14
 BPX
 M
 15.012
 BITS PER PIXEL
 N
 2
 3


text:
1
 1
 10
 PLP
 M
 15.013
 PALMPRINT POSITION
 N
 2
 3
 1
 1
 10
 RSV
 15.014
 RESERVED FOR FUTURE INCLUSION
 —
 —
 —
 —
 —
 —
 15.019
 COM
 O
 15.020
 COMMENT
 AN
 2
 128
 0
 1
 128
 RSV
 15.021
 RESERVED FOR FUTURE INCLUSION
 —
 —
 —
 —
 —
 —
 15.199
 UDF
 O
 15.200
 USER-DEFINED FIELDS
 —
 —
 —
 —
 —
 —
 15.998
 DAT
 M
 15.999
 IMAGE DATA
 B
 2
 —
 1
 1
 —
 Таблица 9
 Вид изображение на длан
 Описание
 Код
 Live-scan palm
 10
 Nonlive-scan palm
 11
 Latent palm impression
 12
 Latent palm tracing
 13
 Latent palm photo
 14
 Latent palm lift
 15
 8.1.11. Поле 15.011: Алгоритъм за компресиране (Compression algorithm — CGA)
 В това задължително ASCII поле се посочва алгоритъмът, използван за компресиране на изображения в сивата скала. Ако в полето е вписано „NONE“, това показва, че данните в този запис не са компресирани. За изображенията, които следва да се компресират, в това поле се вписва предпочитаният метод на компресиране за изображения с десет пръстови отпечатъка. Валидните кодове за компресията са дефинирани в допълнение 39-7.
 8.1.12. Поле 15.012: Битове на пиксел (Bits per pixel — BPX)
 В това задължително ASCII поле се посочва броят на битовете, използвани за представяне на един пиксел. В това поле се вписва 8 за нормалните стойности на сивата скала от 0 до 255. Когато в това поле е въведена стойност, по-голяма или по-малка от 8, това означава съответно по-висока или по-ниска степен на пикселиране в сивата скала.
 Таблица 10
 Кодове, зони и размери на длан
 Положение на дланта
 Код на дланта
 Площ на изображението (mm2)
 Широчина (mm)
 Височина (mm)
 Неизвестна длан
 20
 28387
 139,7
 203,2
 Цяла дясна длан
 21
 28387
 139,7
 203,2
 Длан на десничар
 22
 5645
 44,5
 127,0
 Цяла лява длан
 23
 28387
 139,7
 203,2
 Длан на левичар
 24
 5645
 44,5
 127,0
 Долна част на дясна длан
 25
 19516
 139,7
 139,7
 Горна част на дясна длан
 26
 19516
 139,7
 139,7
 Долна част на лява длан
 27
 19516
 139,7
 139,7
 Горна част на лява длан
 28
 19516
 139,7
 139,7
 Друго, дясна ръка
 29
 28387
 139,7
 203,2
 Друго, лява ръка
 30
 28387
 139,7
 203,2
 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)
 Това незадължително поле може да се използва за вписване на бележки или на друга информация


text:
с 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 разделител.
 Таблица 11
 Максимален допустим брой на кандидатите, които се подават за сверяване в едно съобщение
 Вид търсене AFIS
 TP/TP
 LT/TP
 LP/PP
 TP/UL
 LT/UL
 PP/ULP
 LP/ULP
 Максимален брой кандидати
 1
 10
 5
 5
 5
 5
 5
 Видове търсения:
 TP/TP: десет пръстови отпечатъка спрямо десет пръстови отпечатъка (ten-print against tenprint)
 LT/TP: отпечатък от пръстови следи спрямо десет пръстови отпечатъка (fingerprint latent against ten-print)
 LP/PP: следи от отпечатък от длан спрямо отпечатък от длан (palmprint latent against palmprint)
 TP/UL: десет пръстови отпечатъка спрямо отпечатък от неопределена пръстова следа (ten-print against unsolved fingerprint latent)
 LT/UL: отпечатък от пръстова следа спрямо отпечатък от неопределена пръстова следа (fingerprint latent against unsolved fingerprint latent)
 PP/ULP: отпечатък от длан спрямо неопределен отпечатък от длан (palmprint against unsolved palmprint latent)
 LP/ULP: следа от отпечатък от длан спрямо неопределен отпечатък от длан (palmprint latent against unsolved palmprint latent)
 9. Допълнения към глава 2 (обмен на дактилоскопични данни)
 9.1. Допълнение 39-1: ASCII разделителни кодове
 ASCII
 Позиция (2)
 Описание
 LF
 1/10
 Separates error codes in Field 2.074
 FS
 1/12
 Separates logical records of a file
 GS
 1/13
 Separates fields of a logical record
 RS
 1/14
 Separates the subfields of