EUR-Lex Access to European Union law

Back to EUR-Lex homepage

This document is an excerpt from the EUR-Lex website

Document 32008D0616

Padomes Lēmums 2008/616/TI ( 2008. gada 23. jūnijs ) par to, kā īstenot Lēmumu 2008/615/TI par pārrobežu sadarbības pastiprināšanu, jo īpaši – apkarojot terorismu un pārrobežu noziedzību

OJ L 210, 6.8.2008, p. 12–72 (BG, ES, CS, DA, DE, ET, EL, EN, FR, IT, LV, LT, HU, MT, NL, PL, PT, RO, SK, SL, FI, SV)
Special edition in Croatian: Chapter 11 Volume 029 P. 214 - 274

In force

ELI: http://data.europa.eu/eli/dec/2008/616/oj

6.8.2008   

LV

Eiropas Savienības Oficiālais Vēstnesis

L 210/12


PADOMES LĒMUMS 2008/616/TI

(2008. gada 23. jūnijs)

par to, kā īstenot Lēmumu 2008/615/TI par pārrobežu sadarbības pastiprināšanu, jo īpaši – apkarojot terorismu un pārrobežu noziedzību

EIROPAS SAVIENĪBAS PADOME,

ņemot vērā Padomes Lēmuma 2008/615/TI 33. pantu (1),

ņemot vērā Vācijas Federatīvās Republikas ierosmi,

ņemot vērā Eiropas Parlamenta atzinumu (2),

tā kā:

(1)

Padome 2008. gada 23. jūnijā pieņēma Lēmumu 2008/615/TI par pārrobežu sadarbības pastiprināšanu, jo īpaši – apkarojot terorismu un pārrobežu noziedzību.

(2)

Ar Lēmumu 2008/615/TI galvenie elementi, kas ietverti 2005. gada 27. maija Līgumā, ko noslēgusi Beļģijas Karaliste, Vācijas Federatīvā Republika, Spānijas Karaliste, Francijas Republika, Luksemburgas Lielhercogiste, Nīderlandes Karaliste un Austrijas Republika, kurā ir paredzēts pastiprināti izvērst pārrobežu sadarbību, jo īpaši tādu sadarbību, kas saistīta ar terorisma, pārrobežu noziedzības un nelegālas migrācijas apkarošanu (turpmāk “Prīmes Līgums”), ir transponēti Eiropas Savienības tiesiskajā sistēmā.

(3)

Lēmuma 2008/615/TI par pārrobežu sadarbības pastiprināšanu, jo īpaši – apkarojot terorismu un pārrobežu noziedzību, 33. pantā ir noteikts, ka Padomei jāparedz vajadzīgie pasākumi, lai Eiropas Savienības mērogā īstenotu Lēmumu 2008/615/TI, ievērojot Līguma par Eiropas Savienību 34. panta 2. punkta c) apakšpunkta otrajā teikumā paredzēto procedūru. Minēto pasākumu pamatā ir 2006. gada 5. decembrī pieņemtais Īstenošanas nolīgums, lai administratīvi un tehniski īstenotu un piemērotu Prīmes Līgumu.

(4)

Lēmumā ir ietvertas vienotas normas, kas ir obligātas, lai administratīvi un tehniski īstenotu sadarbību Padomes Lēmumā 2008/615/TI izklāstītajās formās. Šā lēmuma pielikumā ir ietvertas tehniskas īstenošanas normas. Turklāt Padomes Ģenerālsekretariāts izstrādās un regulāri atjauninās īpašu rokasgrāmatu, kurā būs norādīts, kādi fakti dalībvalstīm ir jādara zināmi.

(5)

Atkarībā no tehniskām jaudām jaunus DNS profilus pārbaudīs, izmantojot vienotas meklēšanas funkciju, un attiecīgus risinājumus radīs tehniskā līmenī,

IR NOLĒMUSI ŠĀDI.

I NODAĻA

VISPĀRĒJI JAUTĀJUMI

1. pants

Mērķis

Šā lēmuma mērķis ir noteikt administratīvas un tehniskas normas, kas ir vajadzīgas Padomes Lēmuma 2008/615/TI īstenošanai, jo īpaši par automatizētu apmaiņu ar DNS datiem, daktiloskopijas datiem un transportlīdzekļu reģistrācijas datiem, kā izklāstīts minētā lēmuma 2. nodaļā, kā arī citādu sadarbību, kā izklāstīts minētā lēmuma 5. nodaļā.

2. pants

Definīcijas

Šajā lēmumā:

a)

Lēmuma 2008/615/TI 3., 4. un 9. pantā minētā “meklēšana” un “salīdzināšana” ir procedūras, lai attiecīgi noskaidrotu, vai DNS dati vai daktiloskopijas dati, ko viena dalībvalsts ir darījusi zināmus, attiecīgi saskan ar DNS datiem vai daktiloskopijas datiem, kas glabājas kādas dalībvalsts, vairāku dalībvalstu vai visu dalībvalstu datubāzēs;

b)

Lēmuma 2008/615/TI 12. pantā minētā “automatizētā meklēšana” ir tiešsaistes piekļuves procedūra, kurā datus meklē kādas dalībvalsts, vairāku dalībvalstu vai visu dalībvalstu datubāzēs;

c)

“DNS profils” ir burtu vai ciparu kods, ar ko ir atveidots analizētā cilvēka DNS parauga nekodētās daļas identifikācijas parametru komplekss, t. i., konkrēta dažādu DNS vietu (loci) molekulu struktūra;

d)

“DNS nekodētā daļa” ir tās hromosomu daļas, kurās nav ģenētiskas informācijas, t. i., par ko nav zināms, ka tajās būtu informācija par funkcionālām organisma īpašībām;

e)

“DNS atsauces dati” ir DNS profils un atsauces numurs;

f)

“atsauces DNS profils” ir identificētas personas DNS profils;

g)

“neidentificēts DNS profils” ir DNS profils, ko iegūst no lietiskiem pierādījumiem, kuri ir iegūti, izmeklējot kriminālnoziegumus, un kas ir raksturīgs kādai vēl neidentificētai personai;

h)

“atzīme” ir dalībvalsts izdarīts marķējums kādā DNS profilā, kas atrodas tās datubāzē, tāpēc, ka ir atrasta konkrētā DNS profila atbilsme kādas citas dalībvalsts meklētos vai salīdzinātos datos;

i)

“daktiloskopijas dati” ir pirkstu nospiedumu attēli, latentu pirkstu nospiedumu attēli, plaukstu nospiedumi, latentu plaukstu nospiedumu attēli, kā arī tādu attēlu šabloni (kodēti), kas glabājas automatizētās datubāzēs un ar ko tajās darbojas;

j)

“transportlīdzekļu reģistrācijas dati” ir datu kopums, kas aprakstīts šā lēmuma pielikuma 3. nodaļā;

k)

“konkrētas lietas”, kas minētas Lēmuma 2008/615/TI 3. panta 1. punkta otrajā teikumā, 9. panta 1. punkta otrajā teikumā un 12. panta 1. punkta otrajā teikumā, ir konkrētas, saistībā ar izmeklēšanu vai kriminālvajāšanu izmeklējamas lietas. Ja lietā ir vairāk nekā viens DNS profils, vairāk nekā viena daktiloskopijas datu vienība vai vairāk nekā viena transportlīdzekļa reģistrācijas datu vienība, tos var pārsūtīt kopā kā vienu pieprasījumu.

2. NODAĻA

VIENOTI DATU APMAIŅAS NOTEIKUMI

3. pants

Tehniski parametri

Visos pieprasījumos un atbildēs, meklējot un salīdzinot DNS profilus, daktiloskopijas datus un transportlīdzekļu reģistrācijas datus, dalībvalstis ievēro vienotus tehniskus parametrus. Tehniskie parametri ir doti šā lēmuma pielikumā.

4. pants

Saziņas tīkls

Dalībvalstu savstarpēja elektroniska apmaiņa ar DNS datiem, daktiloskopijas datiem un transportlīdzekļu reģistrācijas datiem notiek, izmantojot pārvaldes iestāžu saziņas tīklā (Trans European Services for Telematics between AdministrationsTESTA II) apvienotos Eiropas telemātikas dienestus, kā arī turpmākus šā saziņas tīkla uzlabojumus.

5. pants

Automatizētas datu apmaiņas pieejamība

Dalībvalstis veic visus vajadzīgos pasākumus, lai nodrošinātu, ka automatizēta DNS datu, daktiloskopijas datu un transportlīdzekļu reģistrācijas datu meklēšana un salīdzināšana būtu iespējama 24 stundas dienā un septiņas dienas nedēļā. Tehnisku kļūmju gadījumā dalībvalstu kontaktpunkti tūlīt informē cits citu un vienojas par alternatīviem pagaidu informācijas apmaiņas mehānismiem, ievērojot spēkā esošos tiesību aktus. Automatizētu datu apmaiņu atjauno, cik drīz vien iespējams.

6. pants

DNS datu un daktiloskopijas datu atsauces numerācija

Lēmuma 2008/615/TI 2. un 8. pantā minētajos atsauces numuros ir ietverts:

a)

kods, kas datu sakritības gadījumos ļauj dalībvalstīm iegūt personas datus un citu informāciju no datubāzēm, lai saskaņā ar Lēmuma 2008/615/TI 5. vai 10. pantu to piegādātu vienai, vairākām vai visām dalībvalstīm;

b)

kods, kas rāda, kurā valstī ir iegūts DNS profils vai daktiloskopijas dati; un

c)

DNS datu sakarā – kods, kas rāda DNS profila tipu.

3. NODAĻA

DNS DATI

7. pants

DNS datu apmaiņas principi

1.   Dalībvalstis izmanto spēkā esošos DNS datu apmaiņas standartus, piemēram, Eiropas standartu kompleksu (European Standard Set – ESS) vai Interpola standartu kompleksu (Interpol Standard Set of LociISSOL).

2.   Ja DNS profilus meklē un salīdzina automatizēti, pārsūtīšana notiek, izmantojot decentralizētu struktūru.

3.   Lai nodrošinātu citām dalībvalstīm pārsūtāmu datu konfidencialitāti un integritāti, veic attiecīgus pasākumus, arī šifrēšanu.

4.   Dalībvalstis veic pasākumus, kas vajadzīgi, lai garantētu tādu DNS profilu integritāti, kurus dara pieejamus vai sūta citām dalībvalstīm salīdzināšanai, un lai nodrošinātu, ka minētie pasākumi atbilst starptautiskiem standartiem, piemēram, ISO 17025.

5.   Dalībvalstis izmanto savus kodus saskaņā ar ISO 3166-1 alfa-2 standartu.

8. pants

Noteikumi par pieprasījumiem un atbildēm saistībā ar DNS datiem

1.   Pieprasījumā veikt automatizētu datu meklēšanu vai salīdzināšanu, kā minēts Lēmuma 2008/615/TI 3. vai 4. pantā, iekļauj tikai šādu informāciju:

a)

pieprasījuma iesniedzējas dalībvalsts kodu;

b)

pieprasījuma iesniegšanas datumu, laiku un datu meklējuma kārtas numuru;

c)

DNS profilus un to atsauces numurus;

d)

to, kāda tipa DNS profilus pārsūtīs (neidentificētus DNS profilus vai atsauces DNS profilus); un

e)

informāciju, kas vajadzīga datubāzu sistēmu kontrolei, kā arī automātisko meklēšanas procesu kvalitātes kontrolei.

2.   Atbildē uz 1. punktā minēto pieprasījumu (ziņojumā par atbilsmēm) ir tikai šāda informācija:

a)

norāde, vai ir konstatēta viena vai vairākas sakritības (atbilsmes) vai arī sakritības nav konstatētas (atbilsmju nav);

b)

pieprasījuma iesniegšanas datums, laiks, un datu meklējuma kārtas numurs;

c)

atbildes datums, laiks, un datu meklējuma kārtas numurs;

d)

pieprasījuma iesniedzējas dalībvalsts un pieprasījuma saņēmējas dalībvalsts kods;

e)

pieprasījuma iesniedzējas dalībvalsts un pieprasījuma saņēmējas dalībvalsts atsauces numurs;

f)

kāda tipa DNS profili ir pārsūtīti (neidentificēti DNS profili vai atsauces DNS profili);

g)

DNS profili, par ko ir iesniegts pieprasījums un saņemta pozitīva atbilde par atbilsmi; kā arī

h)

informācija, kas vajadzīga datubāzu sistēmu kontrolei, kā arī automātisko meklēšanas procesu kvalitātes kontrolei.

3.   Automatizētu atbilsmes paziņošanu nodrošina tikai ar noteikumu, ka, automatizēti meklējot vai salīdzinot, ir iegūtas atbilsmes pietiekamā skaitā loci. Pietiekamais skaits ir dots šā lēmuma pielikuma 1. nodaļā.

4.   Dalībvalstis nodrošina pieprasījumu atbilsmi saskaņā ar Lēmuma 2008/615/TI 2. panta 3. punktu izdotām deklarācijām. Deklarācijas pārpublicē šā lēmuma 18. panta 2. punktā minētajā rokasgrāmatā.

9. pants

Pārsūtīšanas procedūra, automatizēti meklējot neidentificētus DNS profilus saskaņā ar Lēmuma 2008/615/TI 3. pantu

1.   Ja kādas valsts datubāzē, veicot meklējumus ar kādu neidentificētu DNS profilu, atbilsme nav atrasta vai ir atrasta atbilsme neidentificētam DNS profilam, neidentificēto DNS profilu var pārsūtīt uz visu citu dalībvalstu datubāzēm, un, ja, veicot meklējumus ar tādu neidentificētu DNS profilu, citu dalībvalstu datubāzēs atrodas atbilsmes atsauces DNS profiliem un/vai neidentificētiem DNS profiliem, pieprasījuma iesniedzējai dalībvalstij automātiski dara zināmas atbilsmes un pārsūta DNS atsauces datus; ja citu dalībvalstu datubāzēs atbilsmes atrast nevar, to automātiski dara zināmu pieprasījuma iesniedzējai dalībvalstij.

2.   Ja citu dalībvalstu datubāzēs, veicot meklējumus ar kādu neidentificētu DNS profilu, atrodas atbilsme, katra attiecīgā iesaistītā dalībvalsts savā datubāzē par to var pievienot atzīmi.

10. pants

Pārsūtīšanas procedūra, automatizēti meklējot atsauces DNS profilus saskaņā ar Lēmuma 2008/615/TI 3. pantu

Ja kādas valsts datubāzē, veicot meklējumus ar atsauces DNS profilu, nav atrasta atbilsme atsauces DNS profilam vai ir atrasta atbilsme neidentificētam DNS profilam, attiecīgo atsauces DNS profilu var pārsūtīt visu citu dalībvalstu datubāzēm, un, ja, veicot meklējumus ar attiecīgo atsauces DNS profilu, citu dalībvalstu datubāzēs atrodas atbilsmes atsauces DNS profiliem un/vai neidentificētiem DNS profiliem, pieprasījuma iesniedzējai dalībvalstij automātiski dara zināmas atbilsmes un pārsūta DNS atsauces datus; ja citu dalībvalstu datubāzēs atbilsmes atrast nevar, to automātiski dara zināmu pieprasījuma iesniedzējai dalībvalstij.

11. pants

Pārsūtīšanas procedūra, automatizēti salīdzinot neidentificētus DNS profilus saskaņā ar Lēmuma 2008/615/TI 4. pantu

1.   Ja, veicot salīdzinājumus ar neidentificētiem DNS profiliem, citas dalībvalsts datubāzēs atrodas atbilsme kādam atsauces DNS profilam un/vai neidentificētam DNS profilam, pieprasījuma iesniedzējai dalībvalstij automātiski dara zināmas atbilsmes un pārsūta DNS atsauces datus.

2.   Ja, veicot salīdzinājumus ar neidentificētiem DNS profiliem, citu dalībvalstu datubāzēs atrodas atbilsme kādam neidentificētam DNS profilam vai atsauces DNS profilam, katra attiecīgā dalībvalsts var savā datubāzē tam pievienot atzīmi.

4. NODAĻA

DAKTILOSKOPIJAS DATI

12. pants

Daktiloskopijas datu apmaiņas principi

1.   Daktiloskopijas datus digitalizē un pārsūta citām dalībvalstīm, izmantojot vienotu datu formātu, kā norādīts šā lēmuma pielikuma 2. nodaļā.

2.   Katra dalībvalsts nodrošina, lai tās pārsūtītie daktiloskopijas dati būtu pietiekami kvalitatīvi, ka tos varētu salīdzināt automatizētās pirkstu nospiedumu identifikācijas sistēmās (automated fingerprint identification systems – AFIS).

3.   Pārsūtīšanas procedūra, automatizēti apmainoties ar daktiloskopijas datiem, notiek, izmantojot decentralizētu struktūru.

4.   Lai daktiloskopijas datiem, ko pārsūta citām dalībvalstīm, nodrošinātu konfidencialitāti un integritāti, veic attiecīgus pasākumus, arī šifrēšanu.

5.   Dalībvalstis izmanto dalībvalstu kodus saskaņā ar ISO 3166-1 alfa-2 standartu.

13. pants

Daktiloskopijas datu meklēšanas jaudas

1.   Katra dalībvalsts nodrošina, lai tās meklējamo datu apjoms nebūtu lielāks par pieprasījuma saņēmējas dalībvalsts uzrādītām datu meklēšanas jaudām. Dalībvalstis Padomes Ģenerālsekretariātam iesniedz šā lēmuma 18. panta 2. punktā minētās deklarācijas, uzrādot vienā dienā maksimāli iespējamās identificētu personu un vēl neidentificētu personu daktiloskopijas datu meklēšanas jaudas.

2.   Šā lēmuma pielikuma 2. nodaļā norādīts maksimāli iespējamais personu skaits, ko var pieņemt pārbaudei vienā pārsūtīšanas reizē.

14. pants

Noteikumi par pieprasījumiem un atbildēm saistībā ar daktiloskopijas datiem

1.   Pieprasījuma saņēmēja dalībvalsts tūlīt pārbauda pārsūtīto daktiloskopijas datu kvalitāti, izmantojot pilnībā automatizētu procedūru. Ja izrādās, ka dati nav izmantojami automatizētai salīdzināšanai, pieprasījuma saņēmēja dalībvalsts tūlīt informē pieprasījuma iesniedzēju dalībvalsti.

2.   Pieprasījuma saņēmēja dalībvalsts veic meklējumus tādā kārtībā, kādā ir saņemti pieprasījumi. Pieprasījumus apstrādā 24 stundās, izmantojot pilnībā automatizētu procedūru. Pieprasījuma iesniedzēja dalībvalsts, ja tas ir paredzēts tās tiesībās, var lūgt paātrināti apstrādāt pieprasījumus, un pieprasījuma saņēmēja dalībvalsts tūlīt veic minētos meklējumus. Ja termiņus nevar ievērot force majeure dēļ, salīdzināšanu veic uzreiz, līdzko šķēršļi ir novērsti.

5. NODAĻA

TRANSPORTLĪDZEKĻU REĢISTRĀCIJAS DATI

15. pants

Automatizētas transportlīdzekļu reģistrācijas datu meklēšanas principi

1.   Lai automatizēti meklētu transportlīdzekļu reģistrācijas datus, dalībvalstis izmanto īpaši Lēmuma 2008/615/TI 12. panta vajadzībām izstrādātu Eiropas transportlīdzekļu un vadītāja apliecību informācijas sistēmas (European Vehicle and Driving Licence Information System – Eucaris) programmatūru un grozītas šīs programmatūras versijas.

2.   Automatizēta transportlīdzekļu reģistrācijas datu meklēšana notiek, izmantojot decentralizētu struktūru.

3.   Informāciju, ar ko apmainās, izmantojot Eucaris sistēmu, pirms pārsūtīšanas šifrē.

4.   Tie transportlīdzekļu reģistrācijas datu elementi, ar ko ir paredzēts apmainīties, ir uzskaitīti šā lēmuma pielikuma 3. nodaļā.

5.   Īstenojot Lēmuma 2008/615/TI 12. pantu, dalībvalstis var piešķirt prioritāti meklējumiem, kas ir saistīti ar smagu noziegumu apkarošanu.

16. pants

Izmaksas

Katra dalībvalsts sedz izmaksas, ko rada 15. panta 1. punktā minētās Eucaris programmatūras apsaimniekošana, lietojums un profilakse.

6. NODAĻA

POLICIJAS SADARBĪBA

17. pants

Kopējas patruļas un citas kopējas operācijas

1.   Saskaņā ar Lēmuma 2008/615/TI 5. nodaļu un jo īpaši – ar deklarācijām, ko iesniedz saskaņā ar minētā lēmuma 17. panta 4. punktu, 19. panta 2. un 4. punktu, katra dalībvalsts norīko vienu vai vairākus kontaktpunktus, lai citas dalībvalstis varētu griezties pie kompetentām iestādēm un katra dalībvalsts varētu konkretizēt procedūras, ko tā izmanto, lai izveidotu kopējas patruļas un citas kopējas operācijas, procedūras, ko izmanto citu dalībvalstu ierosmēm saistībā ar minētajām operācijām, kā arī citus praktiskus aspektus un ar tādām operācijām saistītus mehānismus.

2.   Padomes Ģenerālsekretariāts apkopo un atjaunina kontaktpunktu sarakstu un informē kompetentas iestādes par visiem grozījumiem minētajā sarakstā.

3.   Jebkuras dalībvalsts kompetentas iestādes var nākt klajā ar ierosmi sākt kopēju operāciju. Pirms sākt konkrētu operāciju, 2. punktā minētās kompetentās iestādes rakstiski vai mutiski vienojas par dažiem elementiem, kas var attiekties uz vairākiem konkrētiem aspektiem, piemēram:

a)

kuras kompetentās iestādes dalībvalstīs ir atbildīgas par operāciju;

b)

kāds ir konkrēts operācijas mērķis;

c)

kas ir uzņēmēja dalībvalsts, kurā jānotiek operācijai;

d)

kāda ir tās uzņēmējas dalībvalsts ģeogrāfiskā teritorija, kurā jānotiek operācijai;

e)

cik ilga būs operācija;

f)

kāda būs konkrētā palīdzība, ko sniegs dalībvalsts(-is), kura(-as) norīkos savus pārstāvjus uz uzņēmēju dalībvalsti, kā arī – kas būs norīkotie ierēdņi vai citas amatpersonas, materiāli un finanšu elementi;

g)

kādi ierēdņi piedalīsies operācijā;

h)

kurš ierēdnis būs atbildīgs par operāciju;

i)

kādas pilnvaras uzņēmējā dalībvalstī var būt dotas pārstāvju sūtītāju dalībvalstu ierēdņiem vai citām amatpersonām operācijas laikā;

j)

kādus ieročus, munīciju un ekipējumu nosūtītās amatpersonas konkrēti var izmantot operācijā saskaņā ar Lēmumu 2008/615/TI;

k)

kādi būs materiālās un tehniskās apgādes mehānismi no transporta, izmitināšanas un drošības viedokļa;

l)

kā tiks segti kopējie operācijas izdevumi, ja tā būs citāda nekā Lēmuma 2008/615/TI 34. panta pirmajā teikumā paredzētā operācija;

m)

kādi būs visi citi elementi, kas, iespējams, varētu būt vajadzīgi.

4.   Šajā pantā paredzētās deklarācijas, procedūras un norīkojumus publicē 18. panta 2. punktā minētajā rokasgrāmatā.

7. NODAĻA

NOBEIGUMA NOTEIKUMI

18. pants

Pielikums un rokasgrāmata

1.   Papildu informācija par Lēmuma 2008/615/TI tehnisku un administratīvu īstenošanu ir dota šā lēmuma pielikumā.

2.   Padomes Ģenerālsekretariāts sagatavo un atjaunina rokasgrāmatu, kurā ir tikai fakti, ko dalībvalstis darījušas zināmus deklarācijās, ar ko tās nāk klajā saskaņā ar Lēmumu 2008/615/TI vai šo lēmumu vai arī kas ir iesniegtas kā paziņojumi Padomes Ģenerālsekretariātam. Rokasgrāmata ir Padomes dokuments.

19. pants

Neatkarīgas datu aizsardzības iestādes

Dalībvalstis saskaņā ar šā lēmuma 18. panta 2. punktu informē Padomes Ģenerālsekretariātu par neatkarīgām datu aizsardzības iestādēm vai tiesu iestādēm, kā minēts Lēmuma 2008/615/TI 30. panta 5. punktā.

20. pants

Lēmumu sagatavošana, kā minēts Lēmuma 2008/615/TI 25. panta 2. punktā

1.   Padome pieņem lēmumus, kā minēts Lēmuma 2008/615/TI 25. panta 2. punktā, pamatojoties uz izvērtējuma ziņojumiem, ko izstrādā ar anketas palīdzību.

2.   Izvērtējuma ziņojumiem par automatizētu datu apmaiņu saskaņā ar Lēmuma 2008/615/TI 2. nodaļu pamatā var būt arī izvērtējuma inspekcijas un izmēģinājuma darbības, ko veic, kad attiecīgā dalībvalsts ir informējusi Ģenerālsekretariātu saskaņā ar Lēmuma 2008/615/TI 36. panta 2. punkta pirmo teikumu.

3.   Sīkāki šīs procedūras nosacījumi ir izklāstīti šā lēmuma pielikuma 4. nodaļā.

21. pants

Datu apmaiņas izvērtējums

1.   Saskaņā ar Lēmuma 2008/615/TI 2. nodaļu regulāri izvērtē datu apmaiņas administratīvos, tehniskos un finanšu aspektus, un jo īpaši – 15. panta 5. punktā paredzēto mehānismu. Izvērtējumi attiecas uz dalībvalstīm, kas izvērtējuma laikā jau piemēro Lēmumu 2008/615/TI, un tos veic par to kategoriju datiem, ar ko attiecīgās dalībvalstis ir sākušas apmainīties. Izvērtējumu pamatā ir attiecīgo dalībvalstu ziņojumi.

2.   Sīkāki šīs procedūras nosacījumi ir izklāstīti šā lēmuma pielikuma 4. nodaļā.

22. pants

Saistība ar Prīmes Līguma īstenošanas nolīgumu

Dalībvalstīs, kam saistības uzliek Prīmes Līgums, piemēro attiecīgus šā lēmuma un pielikuma noteikumus, kad tie būs pilnībā īstenoti, nevis attiecīgos Prīmes Līguma īstenošanas nolīgumā ietvertos noteikumus. Prīmes Līguma līgumslēdzējām pusēm joprojām piemēro visus pārējos īstenošanas nolīguma noteikumus.

23. pants

Īstenošana

Dalībvalstis veic vajadzīgos pasākumus, lai izpildītu šā lēmuma prasības Lēmuma 2008/615/TI 36. panta 1. punktā minētajos termiņos.

24. pants

Piemērošana

Šis lēmums stājas spēkā divdesmitajā dienā pēc tā publicēšanas Eiropas Savienības Oficiālajā Vēstnesī.

Luksemburgā, 2008. gada 23. jūnijā

Padomes vārdā –

priekšsēdētājs

I. JARC


(1)  Skatīt šā Oficiālā Vēstneša 1. lpp.

(2)  2008. gada 21. aprīļa Atzinums (Oficiālajā Vēstnesī vēl nav publicēts).


PIELIKUMS

SATURS

1. NODAĻA.

DNS datu apmaiņa

1.

Kriminālistikas jautājumi, sakritības noteikumi un algoritmi saistībā ar DNS

1.1.

DNS profilu pazīmes

1.2.

Sakritības noteikumi

1.3.

Ziņojumu sastādīšanas noteikumi

2.

Dalībvalstu kodu tabula

3.

Funkcionāla analīze

3.1.

Sistēmas pieejamība

3.2.

Nākamais solis

4.

DNS saskarņu kontroles dokuments

4.1.

Ievads

4.2.

XML struktūras definējums

5.

Programmatūras, drošības un sakaru arhitektūra

5.1.

Pārskats

5.2.

Augstākā līmeņa arhitektūra (Upper Level Architecture)

5.3.

Drošības standarti un datu aizsardzība

5.4.

Šifrēšanas mehānismā izmantotie protokoli un standarti: s/MIME un saistītas pakotnes (packages)

5.5.

Lietojumprogrammas arhitektūra

5.6.

Lietojumprogrammas arhitektūrā izmantotie protokoli un standarti

5.7.

Sakaru sistēmas

2. NODAĻA.

Daktiloskopijas datu apmaiņa (saskarņu kontroles dokuments – interface control document)

1.

Datņu satura pārskats

2.

Ierakstu forma

3.

1. tipa loģiski dati – datnes galvene

4.

2. tipa loģiski dati – ieraksts

5.

4. tipa loģiski dati – melnbalti tonāli attēli ar lielu izšķirtspēju

6.

9. tipa loģiski dati – papilārlīniju detaļu ieraksts

7.

13. tips – latentu attēlu ieraksti ar maināmu izšķirtspēju

8.

15. tips – plaukstu nospiedumu attēli ar maināmu izšķirtspēju

9.

2. nodaļas papildinājumi (daktiloskopijas datu apmaiņa)

9.1.

ASCII nošķīrēji kodi

9.2.

Burtu vai ciparu pārbaudes zīmju aprēķini

9.3.

Zīmju kodi

9.4.

Darbību kopsavilkums

9.5.

1. tipa ierakstu definīcijas

9.6.

2. tipa ierakstu definīcijas

9.7.

Melnbaltu tonālu attēlu saspiešanas kodi

9.8.

Sūtījumu parametri

3. NODAĻA.

Transportlīdzekļu reģistrācijas datu apmaiņa

1.

Kopējs datu kopums automatizētai transportlīdzekļu reģistrācijas datu meklēšanai

1.1.

Definīcijas

1.2.

Transportlīdzekļu īpašnieku vai turētāju meklēšana

2.

Datu drošība

2.1.

Pārskats

2.2.

Sūtījumu apmaiņas drošības iezīmes

2.3.

Ar sūtījumu apmaiņu nesaistītas drošības iezīmes

3.

Datu apmaiņas tehniskie nosacījumi

3.1.

Vispārējs Eucaris lietojumprogrammas apraksts

3.2.

Funkcionālas prasības un nefunkcionālas prasības

4. NODAĻA.

Izvērtējums

1.

Izvērtējuma procedūra saskaņā ar 20. pantu (Lēmumu gatavošana saskaņā ar Lēmuma 2008/615/TI 25. panta 2. punktu)

1.1.

Anketa

1.2.

Izmēģinājums

1.3.

Izvērtējuma inspekcija

1.4.

Ziņojums Padomei

2.

Izvērtējuma procedūra saskaņā ar 21. pantu

2.1.

Statistika un ziņojumi

2.2.

Pārskatīšana

3.

Ekspertu sanāksmes

1. NODAĻA. DNS datu apmaiņa

1.   Kriminālistikas jautājumi, sakritības noteikumi un algoritmi saistībā ar DNS

1.1.   DNS profilu pazīmes

DNS profilā var būt 24 ciparu pāri, kas atbilst 24 lokusu alēlēm, ko izmanto arī Interpola DNS procedūrās. Lokusu (loci) nosaukumi ir doti šajā tabulā:

VWA

TH01

D21S11

FGA

D8S1179

D3S1358

D18S51

Amelogenin

TPOX

CSF1P0

D13S317

D7S820

D5S818

D16S539

D2S1338

D19S433

Penta D

Penta E

FES

F13A1

F13B

SE33

CD4

GABA

Septiņi pelēki iekrāsotie lokusi augšējā rindā ir iekļauti gan Eiropas lokusu standartkompleksā (European Standard SetESS), gan arī Interpola lokusu standartkompleksā (Interpol Standard Set of Loci – ISSOL).

Lietošanas noteikumi:

DNS profilos, ko dalībvalstis dara pieejamus meklēšanai un salīdzināšanai, kā arī DNS profilos, ko nosūta meklēšanas un salīdzināšanas vajadzībām, ir jābūt vismaz sešiem pilnīgiem (1) lokusiem, turklāt tajos – atkarībā no pieejamības – var būt arī papildu lokusi vai atstātas tukšas vietas. Atsauces DNS profilos ir jābūt vismaz sešiem no septiņiem Eiropas standartu kompleksa (ESS) lokusiem. Lai celtu meklēšanas rezultātu sakritību precizitāti, visas pieejamās alēles glabā indeksētā DNS profilu datubāzē un izmanto meklējumos un salīdzinājumos. Katrai dalībvalstij tik drīz, cik vien tas praktiski iespējams, būtu jāīsteno jebkurš jauns Eiropas Savienībā pieņemts ESS.

Jaukti profili (mixed profiles) nav atļauti, jo tad katra lokusa alēles vērtība būs tikai divi cipari, kas var būt tādi paši, ja attiecīgais lokuss ir homozigots.

Aizstājējzīmes funkciju (wild-cards) un mikrovariantus (micro-variants) izmanto saskaņā ar šādiem noteikumiem:

jebkura neskaitliska vērtība (piemēram, “o”, “f”, “r”, “na”, “nr” vai “un”), izņemot profilā iekļautu amelogenīnu, ir automātiski jākonvertē, lai to lietotu ar aizstājējzīmes (*) funkciju, un meklēšana būtu jāveic, salīdzinājumos izmantojot visus meklēšanas kritērijus,

profilā iekļautas skaitliskas vērtības “0”, “1” vai “99” ir automātiski jākonvertē, lai tās lietotu ar aizstājējzīmes (*) funkciju, un meklēšana būtu jāveic, salīdzinājumos izmantojot visus meklēšanas kritērijus,

ja vienam lokusam ir dotas trīs alēles, tad pieņem tikai pirmo alēli, bet pārējās divas alēles automātiski jākonvertē, lai tās lietotu ar aizstājējzīmes (*) funkciju, un meklēšana būtu jāveic, salīdzinājumos izmantojot visus meklēšanas kritērijus,

ja aizstājējzīmes vērtības (wild card values) ir dotas 1. vai 2. alēlei, tad meklēs abas attiecīgās lokusa skaitliskās vērtības permutācijas (piemēram, 12, * varētu sakrist ar 12,14 vai 9,12),

pentanukleotīdu (Penta D, Penta E & CD4) mikrovariantu sakritību nosaka saskaņā ar šādu formulu:

x.1 = x, x.1, x.2

x.2 = x.1, x.2, x.3

x.3 = x.2, x.3, x.4

x.4 = x.3, x.4, x + 1

tetranukleotīdu (pārējie lokusi datubāzē ir tetranukleotīdi) mikrovariantu sakritību nosaka saskaņā ar šādu formulu:

x.1 = x, x.1, x.2

x.2 = x.1, x.2, x.3

x.3 = x.2, x.3, x + 1

1.2.   Sakritības noteikumi (Matching rules)

Divu DNS profilu salīdzināšanu veiks, pamatojoties uz lokusiem, kuriem abos DNS profilos ir pieejams alēles vērtību pāris. Abos DNS profilos ir jāsakrīt vismaz sešiem pilnīgiem lokusiem (izņemot amelogenīnu), pirms dot atbildi par konstatētu sakritību.

Pilnīga sakritība (1. ticamības pakāpe) ir sakritība, kurā ir vienādas visas salīdzināto to lokusu alēļu vērtības, kas atrodas abos salīdzinātajos DNS profila paraugos. Daļēja sakritība ir sakritība, kurā divos DNS profilos atšķiras tikai viena no visu salīdzināto lokusu alēļu vērtībām (2., 3. un 4. ticamības pakāpe). Daļēju sakritību akceptē tikai tad, ja ir reģistrēta sakritība vismaz sešas pilnīgos abu salīdzināto DNS profilu lokusos.

Daļējas sakritības iemesls var būt:

ir pieļauta pārrakstīšanās kļūda, ievadot vienu DNS profilu meklēšanas funkcijā vai DNS datubāzē,

izstrādājot DNS profilu, ir pieļauta alēles noteikšanas (allele-determination) vai alēlēs identifikācijas (allele-calling) kļūda.

1.3.   Ziņojumu sastādīšanas noteikumi

Ziņojumus sastāda gan par pilnīgām sakritībām, gan daļējām sakritībām, gan par to, ka sakritības nav konstatētas.

Sakritības ziņojumu nosūta valsts kontaktpunktam, kas iesniedzis pieprasījumu, kā arī to dara pieejamu tās valsts kontaktpunktam, kurā pieprasījums ir iesniegts (lai dotu iespēju tam novērtēt iespējamus turpmākus pieprasījumus par citiem pieejamiem personas datiem vai citu informāciju saistībā ar DNS profilu, kura saistīta ar atbilsmi saskaņā ar Lēmuma 2008/615/TI 5. un 10. pantu).

2.   Dalībvalstu kodu tabula

Saskaņā ar Lēmumu 2008/615/TI, lai izveidotu domēnu nosaukumus un citus Prīmes Līgumā paredzētus konfigurācijas parametrus, ko slēgtā tīklā lietot DNS datu apmaiņas programmatūrās, izmanto ISO kodu 3166-1 alpha-2.

ISO 3166-1 alpha-2 kodi ir šādi dalībvalstu kodi, kas sastāv no diviem burtiem.

Dalībvalsts nosaukums

Kods

Dalībvalsts nosaukums

Kods

Beļģija

BE

Luksemburga

LU

Bulgārija

BG

Ungārija

HU

Čehija

CZ

Malta

MT

Dānija

DK

Nīderlande

NL

Vācija

DE

Austrija

AT

Igaunija

EE

Polija

PL

Grieķija

EL

Portugāle

PT

Spānija

ES

Rumānija

RO

Francija

FR

Slovākija

SK

Īrija

IE

Slovēnija

SI

Itālija

IT

Somija

FI

Kipra

CY

Zviedrija

SE

Latvija

LV

Apvienotā Karaliste

UK

Lietuva

LT

 

 

3.   Funkcionāla analīze

3.1.   Sistēmas pieejamība

Pieprasījumiem saskaņā ar Lēmuma 2008/615/TI 3. pantu būtu attiecīgā datubāzē jānonāk hronoloģiskā pieprasījumu izsūtīšanas secībā, savukārt atbildēm pieprasījuma iesniedzējā dalībvalstī būtu jānonāk 15 minūtēs pēc pieprasījumu pienākšanas.

3.2.   Nākamais solis

Ja dalībvalsts saņem ziņojumu par sakritību, tās kontaktpunkts ir atbildīgs par attiecīgā iesniegtā profila vērtības un atbildē saņemtā profila(-u) vērtības salīdzināšanu, lai apstiprinātu un pārbaudītu profila iespējamo vērtību. Valstu kontaktpunkti apstiprināšanas sakarā var tieši sazināties cits ar citu.

Pēc divu profilu sakritības apstiprinājuma sākas tiesiskās palīdzības procedūras, pamatojoties uz “pilnīgu sakritību” (full match) vai “daļēju sakritību” (near match), kas ir iegūta automatizēto konsultāciju fāzē.

4.   DNS saskarņu kontroles dokuments

4.1.   Ievads

4.1.1.   Mērķi

Šajā nodaļā ir definētas prasības, lai veiktu DNS profilu informāciju apmaiņu starp visu dalībvalstu datubāzu sistēmām. Galvenes laukumi ir definēti īpaši Prīmes DNS datu apmaiņas vajadzībām, savukārt datu daļas pamatojumā ir izmantota XML shēmas DNS profila datu daļa, kas noteikta Interpola DNS datu apmaiņas vārtejas (Interpol DNA exchange gateway) vajadzībām.

Datu apmaiņa notiek ar SMTP protokolu (Simple Mail Transfer Protocol – vienkāršais pasta pārsūtīšanas protokols) un citu modernu tehnoloģiju starpniecību, izmantojot centrālā releja pasta serveri (central relay mail server), ko nodrošina tīkla pakalpojumu sniedzējs. XML valodā izstrādātu datni pārsūta kā e-pasta pamattekstu.

4.1.2.   Darbības joma

Saskarņu kontroles dokumentā (ICD) ir definēts tikai sūtījuma (e-pasta) saturs. Visi ar tīkla darbību un e-pastiem saistītie jautājumi ir definēti vienotā formātā, lai varētu izveidot vienotu DNS datu apmaiņas tehnisko bāzi.

Tas ietver:

sūtījuma temata formātu, lai dotu iespēju veikt sūtījuma automatizētu apstrādi,

vai ir vajadzīga satura šifrēšana un, ja jā, kāda metode būtu jāizvēlas,

sūtījuma maksimālais garums.

4.1.3.    XML struktūra un principi

XML sūtījums ir strukturēts šādi:

galvenes daļa, kurā ir iekļauta informācija par pārsūtījumu, un

datu daļa, kurā ir iekļauta konkrēta profila informācija, kā arī pats profils.

Tādu pašu XML shēmu izmanto pieprasījumos un atbildēs.

Lai veiktu pilnīgas pārbaudes par neidentificētiem DNS profiliem (Lēmuma 2008/615/TI 4. pants), jāparedz iespēja, ka vienā sūtījumā iekļauj vairākus profilus. Jānosaka maksimālais vienā sūtījumā iekļaujamo profilu skaits. Skaits ir atkarīgs no maksimāli pieļaujamā e-pasta lieluma, un tas būtu jānosaka pēc tam, kad ir notikusi pasta servera izvēle.

XML piemērs:

<?version=“1.0” standalone=“yes”?>

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

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

<header>

(…)

</header>

<datas>

(…)

</datas>

[<datas> datu struktūra ir atkārtota, ja vienā SMTP sūtījumā

(....) ir nosūtīti vairāki profili; tas atļauts tikai lietās, uz ko attiecas 4. pants

</datas>]

</PRUEMDNA>

4.2.   XML struktūras definējums

Šis definējums ir paredzēts dokumentācijas un labākas salasāmības nolūkos, savukārt informācija, kas uzliek saistības, ir paredzēta XML shēmas datnē (PRUEM DNA.xsd).

4.2.1.    PRUEMDNAx shēma

Tā ietver šādus laukus:

Fields

Type

Description

header

PRUEM_header

Occurs: 1

datas

PRUEM_datas

Occurs: 1 ... 500

4.2.2.   Galvenes struktūras saturs

4.2.2.1.

PRUEM galvene

Šajā struktūrā ir aprakstīta XML galvene. Tā ietver šādus laukus:

Fields

Type

Description

direction

PRUEM_header_dir

Direction of message flow

ref

String

Reference of the XML file

generator

String

Generator of XML file

schema_version

String

Version number of schema to use

requesting

PRUEM_header_info

Requesting Member State info

requested

PRUEM_header_info

Requested Member State info

4.2.2.2.

PRUEM_header dir

Sūtījumā iekļauto datu tips, kuru vērtība var būt:

Value

Description

R

Request

A

Answer

4.2.2.3.

PRUEM galvenes informācija

Struktūra, lai aprakstītu dalībvalsti, kā arī sūtījuma datumu/laiku. Tā ietver šādus laukus:

Fields

Type

Description

source_isocode

String

ISO 3166-2 code of the requesting Member State

destination_isocode

String

ISO 3166-2 code of the requested Member 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.    PRUEM profilu datu saturs

4.2.3.1.

PRUEM_datas

Šajā struktūrā ir aprakstīta XML profila datu daļa. Tā ietver šādus laukus:

Fields

Type

Description

reqtype

PRUEM request type

Type of request (Article 3 or 4)

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 Member 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

Sūtījumā iekļauto datu tips, kuru vērtība var būt:

Value

Description

3

Requests pursuant to Article 3 of Decision 2008/615/JHA

4

Requests pursuant to Article 4 of Decision 2008/615/JHA

4.2.3.3.

PRUEM_hitquality_type

Value

Description

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

Sūtījumā iekļauto datu tips, kuru vērtība var būt:

Value

Description

P

Person profile

S

Stain

4.2.2.5.

PRUEM_data_result

Sūtījumā iekļauto datu tips, kuru vērtība var būt:

Value

Description

U

Undefined, If direction = R (request)

H

Hit

N

No Hit

E

Error

4.2.3.6.

IPSG_DNA_profile

DNS profila apraksta struktūra. Tā ietver šādus laukus:

Fields

Type

Description

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

Struktūra, kurā iekļauti ISSOL lokusi (Interpola lokusu standarta komplekss). Tā ietver šādus laukus:

Fields

Type

Description

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

Struktūra, kurā iekļauti citi lokusi. Tā ietver šādus laukus:

Fields

Type

Description

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 gaba

4.2.3.9.

IPSG_DNA_locus

Lokusa apraksta struktūra. Tā ietver šādus laukus:

Fields

Type

Description

low_allele

String

Lowest value of an allele

high_allele

String

Highest value of an allele

5.   Programmatūras, drošības un sakaru arhitektūra

5.1.   Pārskats

Īstenojot lietojumprogrammu, lai veiktu DNS datu apmaiņu saistībā ar Lēmumu 2008/615/TI, izmanto kopēju saziņas tīklu, ko loģiski saslēgs dalībvalstu starpā. Lai kopējo saziņas infrastruktūru efektīvāk izmantotu pieprasījumu nosūtīšanai un atbilžu saņemšanai, ir izstrādāts asinhrons mehānisms, ar ko DNS un daktiloskopijas datu pieprasījumus konvertē par SMTP e-pasta sūtījumiem. Ņemot vērā drošības apsvērumus, kā SMTP protokola paplašinājumu izmantos s/MIME mehānismu, lai tīklā nodrošinātu drošu datu pārraidi visā sakaru tuneļa garumā (true end-to-end secure tunnel).

Operatīvo TESTA (Trans European Services for Telematics between Administrations – Eiropas pārvaldes iestāžu saziņas tīkls) dalībvalstis izmanto kā sakaru tīklu, lai apmainītos ar datiem. Par TESTA darbību ir atbildīga Eiropas Komisija. Ņemot vērā valstu DNS datubāzes un to, ka pašreizējie valstu piekļuves punkti TESTA var atrasties dažādās dalībvalstu vietās, piekļuvi TESTA var izstrādāt:

1)

izmantojot pašreizējo valsts piekļuves punktu vai izveidojot jaunu valsts TESTA piekļuves punktu, vai

2)

izveidojot drošu vietēju saiti no vietnes, kurā atrodas kompetentas valsts aģentūras pārvaldītā DNS datubāze, līdz pastāvošajam valsts TESTA piekļuves punktam.

Protokoli un standarti, ko izmanto, lai īstenotu Lēmumu 2008/615/TI, ir saskaņā ar atvērtiem standartiem (open standards) un prasībām, ko paredzējuši dalībvalstu valsts drošības politikas veidotāji.

5.2.   Augstākā līmeņa arhitektūra (Upper Level Architecture)

Lēmuma 2008/615/TI darbības jomā paredzēts, ka katra dalībvalsts darīs pieejamus DNS datus, lai veiktu to apmaiņu ar citām dalībvalstīm un/vai lai citas dalībvalstis varētu datus izmantot meklēšanā saskaņā ar standartizētu un kopēju datu formātu. Arhitektūra ir veidota tā, lai būtu iespējama jebkura tīkla dalībnieka komunikācija ar jebkuru citu tīkla dalībnieku. Tādējādi nav nedz centrāla datora servera, nedz centralizētas datubāzes, kurā uzglabā DNS profilus.

1.attēls. DNS datu apmaiņas topoloģija

Image

Papildus tam, ka dalībvalstu vietnēs ievēro valstu juridiskos ierobežojumus, katra dalībvalsts var nolemt, kāda tipa aparatūra un programmatūra būtu jāizmanto, lai tās vietnē veiktu konfigurāciju saskaņā ar Lēmumā 2008/615/TI paredzētajām prasībām.

5.3.   Drošības standarti un datu aizsardzība

Ir apsvērti un ieviesti trīs drošības līmeņi.

5.3.1.   Datu līmenis

DNS profilu datus, ko iesniegusi katra dalībvalsts, paredzēts sagatavot saskaņā ar kopējiem datu aizsardzības standartiem, lai pieprasījuma iesniedzējas dalībvalstis saņemtu atbildi, kurā galvenokārt būtu norādīts vai IR vai NAV konstatēta ATBILSME, kā arī – ja ir konstatēta ATBILSME – norāda identifikācijas numuru, kurā nav iekļauti nekādi personas dati. Pēc tam, kad saņemts paziņojums par ATBILSMI, turpmāku izmeklēšanu veiks divpusēji saskaņā ar spēkā esošiem juridiskiem un organizatoriskiem noteikumiem par attiecīgo dalībvalstu piekļuves punktu izmantošanu.

5.3.2.   Sakaru līmenis

DNS profila informācijas sūtījumus (pieprasījumus un atbildes) pirms pārsūtīšanas citām dalībvalstīm šifrēs, izmantojot modernu mehānismu, kas ir saskaņā ar atvērtiem standartiem, piemēram, s/MIME.

5.3.3.   Pārsūtīšanas līmenis

Visus šifrētos DNS profila informācijas sūtījumus pārsūtīs citām dalībvalstīm, starptautiskā mērogā izmantojot virtuālu privātu tunelēšanas sistēmu (tunneling system), ko apsaimnieko uzticams tīkla pakalpojumu sniedzējs, valstu mērogā savukārt nodrošinot drošas saites ar tunelēšanas sistēmu, par kurām ir atbildīgas attiecīgās valstis. Tādai virtuālai privātai tunelēšanas sistēmai nav savienojuma punktu ar atklātībā pieejamo internetu.

5.4.   Šifrēšanas mehānisma protokoli un standarti: s/MIME un saistītas pakotnes (packages)

Lai šifrētu DNS profila informācijas sūtījumus, izmantos atvērtā standarta protokola s/MIME paplašinājumu, ko pievienos e-pasta standartam SMTP. Protokols s/MIME (V3) ļauj izmantot parakstītus sūtījumus, drošības iezīmes (security labels) un drošus e-pastu sarakstus, turklāt tas ir papildu slānis (layer) CMS sintaksei (Cryptographic Message Syntax – CMS), kas ir Interneta tehniskās uzdevumgrupas (IETF) specifikācija, lai nodrošinātu sūtījumu kriptogrāfisku aizsardzību. To var izmantot, lai digitāli parakstītu, apstrādātu (digest), autentificētu vai šifrētu jebkuru digitālu datu formu.

s/MIME mehānisma pamatā esošajam un tajā izmantotajam sertifikātam (certificate) ir jāatbilst X.509 standartam. Lai nodrošinātu ar citām Prīmes lietojumprogrammām kopējus standartus un procedūras, s/MIME šifrēšanas darbībām vai darbībām, ko paredzēts veikt dažādās komercializētās, publiski pieejamās sistēmās (COTS – Commercial Product of the Shelves) piemēro šādus noteikumus:

darbību secība ir šāda: no sākuma šifrē, pēc tam paraksta,

šifrēšanas algoritmu AES (Advanced Encryption Standard) ar 256 bitu atslēgas garumu (key length) un RSA ar 1 024 bitu atslēgas garumu attiecīgi piemēro simetriskai un asimetriskai šifrēšanai,

piemēro jaucējfunkcijas algoritmu (“hash algorithm”) SHA-1.

s/MIME funkcionalitāte ir integrēta ļoti daudzās modernās e-pasta programmatūras pakotnēs, tostarp Outlook, Mozilla Mail, kā arī Netscape Communicator 4.x, turklāt to izmanto savstarpējā komunikācijā visās galvenās e-pastu programmatūru pakotnēs.

Tā kā s/MIME standartu ir vienkārši integrēt visu valstu vietņu IT infrastruktūrā, tas ir izvēlēts kā lietderīgs mehānisms, lai nodrošinātu saziņas drošības līmeni. Lai efektīvāk sasniegtu mērķi “Koncepcijas pierādījums” (“Proof of Concept”) un lai mazinātu izmaksas, DNS datu apmaiņas prototipa pamatā savukārt ir izvēlēts atvērtais standarts JavaMail API. JavaMail API nodrošina vienkāršas e-pastu šifrēšanas un atšifrēšanas funkcijas, izmantojot s/MIME un/vai OpenPGP. Iecere ir sniegt vienu viegli izmantojamu API saskarni tiem e-pasta klientiem, kas vēlas sūtīt un saņemt šifrētus e-pastus, izmantojot vienu no abiem populārākajiem e-pastu šifrēšanas formātiem. Tāpēc jebkāds moderns JavaMail API īstenojums būs pietiekams, lai izpildītu Lēmumā 2008/615/TI izvirzītās prasības, piemēram, Bouncy Castle JCE (Java Cryptographic Extension) izstrādājums, ko izmantos, lai īstenotu s/MIME standartu, kas būtu visu dalībvalstu starpā veidotās DNS datu apmaiņas sistēmas prototipa pamatā.

5.5.   Lietojumprogrammu arhitektūra

Katra dalībvalsts citām dalībvalstīm iesniedz standartizētus DNS profilu datus, kas saskan ar pašreizējo kopējo ICD. To var izdarīt, sniedzot loģisku pārskatu par konkrētu valstu datubāzēm vai nodrošinot fiziski eksportētu datubāzi (indeksētu datubāzi).

Lietojumprogrammas darbības loģiku neatkarīgi no izmantotā izstrādājuma īsteno četri šādi galvenie komponenti: e-pasta serveris/s/MIME, lietojumprogrammas serveris, datu struktūras protokols (Data Structure Area), lai veiktu datu ienesi (fetching) un ievadīšanu (feeding) un reģistrētu saņemtos un nosūtītos sūtījumus, kā arī sakritību apstrādes sistēma (Match Engine).

Lai visām dalībvalstīm atvieglotu komponentu integrāciju to attiecīgajās valstu vietnēs, ir īstenota īpaša kopēja funkcionalitāte, izmantojot atvērto avotu komponentus, ko katra dalībvalsts var izvēlēties saskaņā ar savu IT politiku un noteikumiem. Tā kā ir paredzēts īstenot neatkarīgas iezīmes, lai gūtu piekļuvi indeksētām datubāzēm, kurās iekļauti ar Lēmumu 2008/615/TI reglamentētie DNS profili, katra dalībvalsts var brīvi izraudzīties aparatūras un programmatūras platformu, tostarp datubāzi un operētājsistēmas.

Ir izstrādāts un pastāvošajā kopējā tīklā sekmīgi pārbaudīts DNS datu apmaiņas prototips. Versija 1.0 jau darbojas reāla darba apstākļos, un to izmanto, veicot ikdienas darbības. Dalībvalstis var izmantot kopīgi izstrādātus IT izstrādājumus, tomēr tās var arī attīstīt savus izstrādājumus. Kopējā izstrādājuma komponentus uzturēs, piemēros un turpinās attīstīt saskaņā ar izmaiņām IT tehnoloģijās, kriminālistikā un/vai saskaņā ar funkcionālām policijas vajadzībām.

2.attēls. Lietojumprogrammas topoloģijas pārskats

Image

5.6.   Lietojumprogrammas arhitektūrā izmantotie protokoli un standarti:

5.6.1.    XML

DNS datu apmaiņā kā pielikumu SMTP e-pasta sūtījumiem pilnībā izmantos XML shēmu. Paplašināmās iezīmēšanas valoda (eXtensible Markup Language – XML) ir Pasaules tīmekļa konsorcija (W3C) ieteikta vispārēja iezīmēšanas valoda (markup language), lai izstrādātu īpašas iezīmēšanas valodas, kas ļautu aprakstīt daudzus dažādu tipu datus. DNS profila apraksts, kas ir piemērots, lai visas dalībvalstis apmainītos ar datiem, ir izstrādāts, ICD dokumentos izmantojot XML valodu un XML shēmu.

5.6.2.    ODBC

Atvērto datubāzu savienojamība (Open DataBase Connectivity) dod iespēju izmantot standarta programmatūras API saskarnes metodi, lai piekļūtu datubāzu pārvaldības sistēmām (database management systems), turklāt tā darbojas neatkarīgi no programmēšanas valodām, datubāzes un operētājsistēmām. Tomēr ODBC ir arī savi trūkumi. Liela skaita klientu aparatūras administrēšana var būt saistīta ar daudziem draiveriem un DLLs. Šī sarežģītība var palielināt sistēmas administrēšanas izmaksas.

5.6.3.    JDBC

Java datubāzes savienojamība (Java DataBase Connectivity – JDBC) ir API saskarne ar Java programmēšanas valodu, ar ko nosaka, kā klients piekļūst datubāzei. Pretstatā ODBC, lietojot JDBC, darbvirsmā (desktop) nav vajadzīgs lietot konkrētu lokālu DLLs kopumu.

Šajā diagrammā ir parādīta katras dalībvalsts vietnē veiktās DNS profilu pieprasījumu un atbilžu apstrādes darbību loģika. Gan pieprasījumu, gan atbilžu datu plūsma ir mijiedarbībā ar neitrāliem datiem (neutral data), kas aptver dažādu datu kopumus ar kopēju struktūru.

3. attēls. Pārskats par katrā dalībvalsts vietnē notiekošo lietojumprogrammu datu plūsmu

Image

5.7.   Saziņas sistēmas

5.7.1.   Kopējais saziņas tīkls: TESTA un ar to saistīta infrastruktūra

Lai dalībvalstis savstarpēji nosūtītu pieprasījumus un saņemtu atbildes, lietojumprogrammās DNS datu apmaiņai izmantos e-pastu, kas ir asinhrons mehānisms. Tā kā katrai dalībvalstij ir vismaz viens valsts piekļuves punkts TESTA tīklam, DNS datu apmaiņu veiks, izmantojot TESTA tīklu. TESTA tīklā e-pasta releja serveris dod iespēju izmantot vairākus papildu pakalpojumus. Papildus tam, ka TESTA tīklā uztur īpašas e-pasta sistēmas, tās infrastruktūra var īstenot e-pasta sarakstu izsūtīšanu un maršrutēšanas principus. Tas ļauj TESTA tīklu izmantot par datu sadales sistēmu (clearing house) tām iestādēm adresētiem sūtījumiem, kuras ir savienotas ar ES domēniem. Var uzstādīt arī vīrusu apkarošanas mehānismus.

TESTA e-pasta releja pamatā ir augstas pieejamības aparatūras platforma (high availability hardware platform), kura ir izvietota centrālajā TESTA lietojumprogrammas objektā un kuru aizsargā ar ugunssienu. TESTA tīkla domēna vārdu sistēma (Domain Name Services – DNS) pārveidos resursu norādes IP adresēs un slēps adresēto informāciju no lietotāja un no lietojumprogrammas.

5.7.2.   Drošības apsvērumi

TESTA sistēma ir īstenota saskaņā ar virtuāla privāta tīkla (Virtual Private Network – VPN) koncepciju. VPN tīklu izveidē izmantoto marķējumu komutācijas tehnoloģiju (Tag Switching Technology) attīstīs, lai tā strādātu ar vairākprotokolu iezīmju komutāciju (Multi-Protocol Label Switching – MPLS) standartu, ko ir izstrādājusi Interneta tehniskā uzdevumgrupa (IETF).

Image

MPLS ir IETF standarta tehnoloģija, ar ko paātrina tīklā notiekošās datu plūsmas ātrumu, izvairoties no starpnieku maršrutētāju (intermediate routers (hops)) veiktas pakešu analīzes. To dara, pamatojoties uz tā sauktajām iezīmēm (labels), ko paketei pievieno pamatsistēmas malas maršrutētāji (edge routers of the backbone), pamatojoties uz pārsūtīšanas informācijas bāzē (forwarding information base – FIB) iekļauto informāciju. Iezīmes izmanto arī, lai īstenotu virtuālus privātus tīklus (VPN).

MPLS ļauj gūt labumu gan no 3. slāņa maršrutēšanas (layer 3 routing), gan izmantot 2. slāņa komutāciju (layer 2 switching) priekšrocības. Tā kā IP adresēm pārsūtot caur pamatsistēmu (backbone), nenotiek to izvērtējums, MPLS neuzliek nekādus ierobežojumus IP adresēšanai.

Turklāt e-pastu sūtījumiem TESTA tīklā piemēro s/MIME šifrēšanas mehānismu. Nezinot atslēgu un bez pareiza sertifikāta, šajā tīklā nav iespējams atšifrēt sūtījumus.

5.7.3.   Saziņas tīklā izmantotie protokoli un standarti

5.7.3.1.

SMTP

Vienkāršo pasta pārsūtīšanas protokolu (Simple Mail Transfer Protocol) faktiski internetā izmanto kā e-pasta pārsūtīšanas standartu. SMTP standarts ir samērā vienkāršs teksta protokols, kurā ir precizēts viens vai vairāki sūtījuma saņēmēji un pēc tam notiek sūtījuma teksta pārsūtīšana. SMTP standarts saskaņā ar IETF norādēm izmanto TCP protokola 25. pieslēgvietu (port). Lai attiecīgam domēna vārdam noteiktu SMTP serveri, izmanto MX (Mail eXchange) DNS (Domain Name Systems) sistēmas ierakstu.

Tā kā šis protokols sākotnēji bija teksta formāta ASCII standartkods, pastāvēja bināru datņu apstrāde sproblēmas. Tādus standartus kā MIME izstrādāja, lai varētu kodēt bināras datnes to pārsūtīšanai, izmantojot SMTP. Pašlaik vairums SMTP serveru darbojas ar 8BITMIME un s/MIME paplašinājumu, kas ļauj bināras datnes pārsūtīt gandrīz tikpat viegli kā parastu tekstu. s/MIME apstrādes noteikumi ir aprakstīti iedaļā s/MIME (skatīt 5.4. nodaļu).

SMTP ir stūmējtehnoloģijas protokols (“push” protocol), kas nedod iespēju no attālas piekļuves servera izmantot vilcējtehnoloģijas un pēc pieprasījuma lejupielādēt (“pull”) sūtījumus. Lai to darītu, pasta klientam ir jāizmanto POP3 vai IMAP. Lai veiktu DNS datu apmaiņu, ir pieņemts lēmums izmantot POP3 protokolu.

5.7.3.2.

POP

Vietēji e-pasta klienti izmanto pasta nodaļas protokola 3. versiju (Post Office Protocol version 3 – POP3), kas ir lietojumslāņa (application-layer) interneta standarta protokols, lai e-pastam piekļūtu no attāla servera, izmantojot TCP/IP savienojumu. Ar SMTP protokola SMTP Submit profilu, e-pasta klienti sūta sūtījumus internetā vai privātā tīklā (corporate network). MIME izmanto kā standartu pielikumiem un e-pastu tekstam, kas nav ASCII standartkodā. Kaut gan, izmantojot gan POP3, gan SMTP protokolu nav vajadzīgs, lai e-pasti būtu MIME standartā, tomēr MIME parasti izmanto interneta e-pastos, tāpēc POP klientiem arī ir jāsaprot un jāizmanto MIME standarts. Tāpēc Lēmumā 2008/615/TI paredzētajās saziņas darbībās iekļaus POP komponentus.

5.7.4.   Tīkla adrešu piešķire

Darbības vide

Eiropas IP reģistrācijas iestāde (European IP registration authority – RIPE) pašlaik TESTA vajadzībām ir atvēlējusi īpašu C klases apakštīkla adrešu kopumu (C class subnet). Vajadzības gadījumā TESTA tīklam turpmāk var piešķirt papildu adrešu kopumus. IP adreses dalībvalstīm piešķir, pamatojoties uz ģeogrāfisku Eiropas shēmu. Datu apmaiņa dalībvalstu starpā saistībā ar Lēmumu 2008/615/TI notiek Eiropas mēroga loģiski slēgtā IP tīklā.

Testēšanas vide

Lai ikdienā visām dalībvalstīm, kas pieslēgušās tīklam, nodrošinātu efektīvus darbības apstākļus, slēgtā tīklā jāizveido testēšanas sistēma, kurai pieslēgtos dalībvalstis, kas gatavojas pievienoties tīklam. Attiecīgo dalībvalstu vietnēs būtu jādara pieejams precizētu parametru saraksts, tostarp IP adreses, tīkla iestatījumi, e-pasta domēni, kā arī lietojuma lietotāja konti. Turklāt testēšanas nolūkos ir izveidots DNS pseidoprofilu kopums.

5.7.5.   Konfigurācijas parametri

Ir izveidota droša e-pastu sistēma, izmantojot domēnu eu-admin.net. Šis domēns un tā adreses nebūs pieejamas no adresēm, kas neatrodas ES TESTA tīkla domēnā, jo vārdus atpazītu tikai TESTA centrālais DNS serveris, kas nav pieslēgts internetam.

TESTA vietņu adrešu (resursdatora vārdu) kartēšanu (mapping) attiecībā uz to IP adresēm veic TESTA DNS sistēma. Attiecībā uz katru lokālo domēnu šim TESTA centrālam DNS serverim pievienos e-pasta ierakstu, kas visus TESTA lokāliem domēniem sūtītos e-pasta sūtījumus pārsūtīs TESTA centrālajam pasta relejam. Šis TESTA centrālais pasta relejs pēc tam tos pārsūtīs konkrētiem lokālā domēna e-pasta serveriem, izmantojot lokālā domēna e-pasta adreses. Šādi pārsūtot e-pastu, tajos iekļautā nozīmīgā informācija būs nosūtīta, izmantojot tikai Eiropas mēroga slēgto tīkla infrastruktūru un apejot nedrošo internetu.

Visu dalībvalstu vietnēs jāizveido apakšdomēni ( kursīvā treknrakstā ) saskaņā ar šādu sintaksi:

application-type.pruem. Member State-code.eu-admin.net”, kur

Member State-code”(dalībvalsts kods) ir dalībvalstu divu burtu kods (t. i., AT, BE u. c.);

savukārt “ application-type ” (lietojuma tips) ir viena no vienībām – DNA un FP.

Minētās sintakses piemērošanai vajadzīgie dalībvalstu apakšdomēni ir parādīti šajā tabulā:

MS

Sub Domains

Comments

BE

dna.pruem.be.eu-admin.net

Setting up a secure local link to the existing TESTA II access point

fp.pruem.be.eu-admin.net

 

BG

dna.pruem.bg.eu-admin.net

 

fp.pruem.bg.eu-admin.net

 

CZ

dna.pruem.cz.eu-admin.net

 

fp.pruem.cz.eu-admin.net

 

DK

dna.pruem.dk.eu-admin.net

 

fp.pruem.dk.eu-admin.net

 

DE

dna.pruem.de.eu-admin.net

Using the existing TESTA II national access points

fp.pruem.de.eu-admin.net

 

EE

dna.pruem.ee.eu-admin.net

 

fp.pruem.ee.eu-admin.net

 

IE

dna.pruem.ie.eu-admin.net

 

fp.pruem.ie.eu-admin.net

 

EL

dna.pruem.el.eu-admin.net

 

fp.pruem.el.eu-admin.net

 

ES

dna.pruem.es.eu-admin.net

Using the existing TESTA II national access point

fp.pruem.es.eu-admin.net

 

FR

dna.pruem.fr.eu-admin.net

Using the existing TESTA II national access point

fp.pruem.fr.eu-admin.net

 

IT

dna.pruem.it.eu-admin.net

 

fp.pruem.it.eu-admin.net

 

CY

dna.pruem.cy.eu-admin.net

 

fp.pruem.cy.eu-admin.net

 

LV

dna.pruem.lv.eu-admin.net

 

fp.pruem.lv.eu-admin.net

 

LT

dna.pruem.lt.eu-admin.net

 

fp.pruem.lt.eu-admin.net

 

LU

dna.pruem.lu.eu-admin.net

Using the existing TESTA II national access point

fp.pruem.lu.eu-admin.net

 

HU

dna.pruem.hu.eu-admin.net

 

fp.pruem.hu.eu-admin.net

 

MT

dna.pruem.mt.eu-admin.net

 

fp.pruem.mt.eu-admin.net

 

NL

dna.pruem.nl.eu-admin.net

Intending to establish a new TESTA II access point at the NFI

fp.pruem.nl.eu-admin.net

 

AT

dna.pruem.at.eu-admin.net

Using the existing TESTA II national access point

fp.pruem.at.eu-admin.net

 

PL

dna.pruem.pl.eu-admin.net

 

fp.pruem.pl.eu-admin.net

 

PT

dna.pruem.pt.eu-admin.net

......

fp.pruem.pt.eu-admin.net

......

RO

dna.pruem.ro.eu-admin.net

 

fp.pruem.ro.eu-admin.net

 

SI

dna.pruem.si.eu-admin.net

......

fp.pruem.si.eu-admin.net

.......

SK

dna.pruem.sk.eu-admin.net

 

fp.pruem.sk.eu-admin.net

 

FI

dna.pruem.fi.eu-admin.net

[To be inserted]

fp.pruem.fi.eu-admin.net

 

SE

dna.pruem.se.eu-admin.net

 

fp.pruem.se.eu-admin.net

 

UK

dna.pruem.uk.eu-admin.net

 

fp.pruem.uk.eu-admin.net

 

2. NODAĻA. Daktiloskopijas datu apmaiņa (saskarņu kontroles dokuments – interface control document)

Dokumentu saskarne “Control Document (dokumentu kontrole)” ir izstrādāta, lai noteiktu prasības, ka jāievēro, dalībvalstīm savstarpēji veicot daktiloskopijas informācijas apmaiņu, izmantojot automatizētas pirkstu nospiedumu identifikācijas sistēmas (Automated Fingerprint Identification Systems – AFIS). Tajā ir izmantots Interpola īstenotais ANSI/NIST-ITL 1-2000 (INT-I, Version 4.22b).

Šī versija attiecas uz visām 1. tipa, 2. tipa, 4. tipa, 9. tipa, 13. tipa un 15. tipa loģisku ierakstu pamatdefinīcijām, kuras ir vajadzīgas daktiloskopijas apstrādei, kurā izmanto attēlus un papilārlīniju detaļas.

1.   Datņu satura pārskats

Vienā daktiloskopijas datnē ir vairāki loģiski elementi. Oriģinālajā ANSI/NIST-ITL 1-2000 standartā ir sešpadsmit dažādu tipu elementu. Attiecīgas ASCII nošķīrējzīmes lieto, nodalot katru ierakstu, un ierakstos – laukus un pakārtotus laukus.

Tikai sešu tipu ierakstus lieto, lai datu izcelsmes aģentūra dalītos informācijā ar datu saņēmēju aģentūru:

1. tips

informācija par darbību

2. tips

burtu un skaitļu dati par personām un attiecīgām lietām

4. tips

melnbalti tonāli daktiloskopiski attēli ar lielu izšķirtspēju

9. tips

papilārlīniju detaļu uzskaitījums

13. tips

ierakstīti latenti attēli ar maināmu izšķirtspēju

15. tips

ierakstīti plaukstu nospiedumu attēli ar maināmu izšķirtspēju

1.1.   1. tips – datnes galvene

Šajos ierakstos ir maršrutēšanas informācija un informācija par pārējo datnes struktūru. Šajos ierakstos ir noteikti arī darbību tipi, kas atbilst šādām plašām kategorijām.

1.2.   2. tips – apraksts

Šajos ierakstos ir tekstuāla informācija, kas attiecas gan uz sūtītāju, gan uz saņēmēju aģentūru.

1.3.   4. tips – ierakstīti melnbalti tonāli attēli ar lielu izšķirtspēju

Tādus ierakstus izmanto, lai dalītos ar melnbaltiem tonāliem daktiloskopijas attēliem, kas ir nolasīti ar lielu (astoņu bitu) izšķirtspēju, 500 pikseļiem collā. Daktiloskopijas attēlus saspiež, izmantojot WSQ algoritmu, ar koeficientu līdz 15:1. Nedrīkst lietot citus saspiešanas algoritmus vai nesaspiestus attēlus.

1.4.   9. tips – ierakstītas papilārlīniju detaļas

9. tipa ierakstus izmanto, lai veiktu apmaiņu ar papilārlīniju parametriem vai papilārlīniju detaļu datiem. Viens iemesls to izmantojumam ir izvairīties no nevajadzīgas AFIS kodēšanas procesu atkārtošanās un daļēji – lai varētu pārraidīt AFIS kodus, kuros ir mazāk datu nekā atbilstošos attēlos.

1.5.   13. tips – ierakstīti latenti attēli ar maināmu izšķirtspēju

Tādus ierakstus izmanto, lai apmainītos ar ierakstītiem latentiem attēliem ar maināmu izšķirtspēju un latentiem plaukstu nospieduma attēliem, kā arī ar tekstuālu burtu un skaitļu informāciju. Attēlu skenējuma izšķirtspējai ir jābūt 500 pikseļiem collā ar 256 toņu pelēkumu. Ja latentā attēla kvalitāte ir pietiekama, to saspiež, izmantojot WSQ algoritmu. Vajadzības gadījumā attēlu izšķirtspēju var atspiest vairāk nekā līdz 500 pikseļiem collā un vairāk nekā līdz 256 toņu pelēkumam saskaņā ar divpusēju vienošanos. Šādos gadījumos ļoti ieteicams lietot JPEG 2000 (sk. 7. papildinājumu).

1.6.   Ierakstīti plaukstu nospiedumu attēli ar maināmu izšķirtspēju

15. tipa marķētus lauka attēlu ierakstus izmanto, lai veiktu apmaiņu ar plaukstu nospiedumu attēliem ar maināmu izšķirtspēju, kā arī ar tekstuālu burtu un skaitļu informāciju. Skenēto attēlu izšķirtspējai ir jābūt 500 pikseļiem collā ar 256 toņu pelēkumu. Lai mazinātu visu plaukstu nospiedumu attēlu datu apjomu, tie jāsaspiež, izmantojot WSQ algoritmu. Vajadzības gadījumā attēlu izšķirtspēju var atspiest vairāk nekā līdz 500 pikseļiem collā un vairāk nekā līdz 256 toņu pelēkumam saskaņā ar divpusēju vienošanos. Šādos gadījumos ļoti ieteicams ir lietot JPEG 2000 (sk. 7. papildinājumu).

2.   Ierakstu forma

Vienā darbību datnē ir viens vai vairāki loģiski ieraksti. Katram loģiskam ierakstam datnē ir vairāki informācijas lauki, kas ir piemēroti attiecīga tipa ierakstiem. Katrā informācijas laukā var būt viens vai vairāki elementāri vienvērtīgi informācijas elementi. Kopumā minētos elementus izmanto, lai atklātu dažādus attiecīgā lauka datu aspektus. Informācijas laukā var būt arī viens vai vairāki sagrupēti informācijas elementi, kas laukā atkārtojas vairākkārt. Tādas informācijas elementu grupas dēvē par pakārtotiem laukiem. Tādējādi informācijas laukā var būt viens vai vairāki pakārtoti informācijas elementu lauki.

2.1.   Informācijas nošķīrēji

Marķētu lauku loģiskos ierakstos liek lietā informācijas norobežošanas mehānismus, izmantojot četrus ASCII informācijas nošķīrējus. Norobežota informācija var būt elementi kādā laukā vai pakārtotā laukā, laukos, kas atrodas loģiskos ierakstos, vai arī daudzkārtējos pakārtotos laukos. Informācijas nošķīrējus nosaka pēc standarta ANSI X3.4. Tādas zīmes izmanto, lai nošķirtu un klasificētu informāciju loģiskā nozīmē. Hierarhiski datnes nošķīrēja (File Separator – “FS”) zīme aptver visvairāk informācijas, nākamā ir grupu nošķīrēja (Group Separator – “GS”), ierakstu nošķīrēja (Record Separator – “RS”) un visbeidzot vienību nošķīrēja (Unit Separator – “US”) zīme. 1. tabulā ir uzskaitīti minētie ASCII nošķīrēji un aprakstīts to lietojums saskaņā ar minēto standartu.

Informācijas nošķīrēji no funkciju viedokļa būtu jāuzskata par norādēm, kāda tipa dati tām seko. Zīme “US” nošķir atsevišķus informācijas elementus kādā laukā vai pakārtotā laukā. Tas nozīmē, ka nākamais informācijas elements ir attiecīga lauka vai pakārtota lauka datu fragments. Vairāki pakārtoti lauki vienā laukā, kas ir nošķirts ar “RS” zīmi, liecina, ka sākas nākamā atkārtota(-u) informācijas elementa(-u) grupa. Nošķīrējzīme “GS”, ko lieto starp informācijas laukiem, liecina, ka sākas jauns lauks – pirms lauka identifikācijas numura, kas tai tūdaļ seko. Līdzīgi – par jauna loģiska ieraksta sākumu liecina “FS” zīme.

Šīm četrām zīmēm ir nozīme tikai tad, ja tās ASCII teksta ierakstu laukos lieto kā datu elementu nošķīrējas. Šīm zīmēm, kas ir sastopamas bināros attēlu ierakstos un bināros laukos, nav patstāvīgas nozīmes – tās tikai pieder pie datiem, ar kuriem veic apmaiņu.

Parastos apstākļos nevajadzētu būt tukšiem laukiem vai informācijas elementiem, tāpēc starp katriem diviem datu elementiem būtu jābūt tikai vienai nošķīrējzīmei. Šim likumam izņēmums ir gadījumos, ja kādā darbībā dati laukos vai informācijas elementos nav pieejami, to nav vai tie nav obligāti, un darbības apstrāde nav atkarīga no tā, vai attiecīgie dati ir pieejami. Tādos gadījumos vairākas un blakus esošas nošķīrējzīmes parādīsies kopā, un nošķīrējzīmju starpā nevajadzēs iespraust butaforiskus datus.

Uz tādu lauku definīciju, kuri sastāv no trijiem informācijas elementiem, attiecas šādi noteikumi. Ja otrajā informācijas elementā nav informācijas, tad divas blakus esošas “US” informācijas nošķīrējzīmes atradīsies starp pirmo un trešo informācijas elementu. Ja nav informācijas nedz otrajā, nedz trešajā informācijas elementā, būtu jālieto trīs nošķīrējzīmes – divas “US” zīmes, kas papildina beigu lauka vai pakārtota lauka nošķīrējzīmi. Īsumā – ja viens vai vairāki obligāti vai fakultatīvi lauka vai pakārtota lauka informācijas elementi nav pieejami, būtu jāiesprauž attiecīgs skaits nošķīrējzīmju.

Ir iespējams, ka blakus atrodas divas vai vairākas no četrām izmantojamām nošķīrējzīmēm. Ja trūkst datu vai tādu nav informācijas elementos, pakārtotos laukos vai laukos, ir jābūt par vienu nošķīrējzīmi mazāk nekā ir datu elementu, pakārtotu lauku vai prasītu lauku.

1. tabula. Izmantotie nošķīrēji

Code

Type

Description

Hexadecimal Value

Decimal Value

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.   Ierakstu izkārtojums

Loģiskos ierakstos ar marķētiem laukiem katru izmantoto informācijas lauku numurē saskaņā ar šo standartu. Katra lauka formā ir loģiskā ieraksta tipa numurs, kam seko punkts “.”, lauka numurs, kam seko kols “:”, kam savukārt seko informācija, kas piederas attiecīgā laukā. Marķētu lauku numurs var būt jebkurš skaitlis no viens līdz deviņi, ko raksta starp punktu “.” un kolu “:”. To interpretē kā lauka numuru nenegatīvos skaitļos. Tas nozīmē, ka lauks numur “2.123:” ir līdzvērtīgs laukam numur “2.000000123:”, un tas ir jāinterpretē tāpat.

Visā šajā dokumentā skaidrojumam trīsciparu skaitļi ir lietoti tādu lauku numurēšanai, kas atrodas katrā šeit aprakstītā marķētu lauku loģiskā ierakstā. Lauku numuri būs doti šādā formā – “TT.xxx:”, un “TT” apzīmē vienzīmes vai divzīmju tipa ierakstus, kam seko punkts. Nākamās trīs zīmes ir attiecīgā lauka numurs, kam seko kols. Kolam seko informatīvs ASCII apraksts vai attēla dati.

1. tipa un 2. tipa loģiskos ierakstos ir tikai ASCII teksta datu lauki. Katrā šā tipa ierakstā kā pirmo ASCII lauku ieraksta visu ierakstu pilnībā (arī lauku numurus, kolus un nošķīrējzīmes). ASCII datņu nošķīrēja “ASCII File Separator – FS” zīme (ar ko apzīmē loģisku ierakstu vai darbību beigas) seko pēdējam ASCII informācijas baitam, un to iekļauj ierakstā.

Pretstatā marķētu lauku jēdzienam 4. tipa ierakstos ir tikai bināri dati, ko ieraksta kā sakārtotus fiksēta garuma binārus laukus. Ierakstu visā garumā ieraksta pirmajā katra ieraksta četru baitu binārā laukā. Tādiem bināriem ierakstiem nepieraksta ne ieraksta numuru līdz ar punktu, ne lauka identifikācijas numuru līdz ar sekojošu kolu. Turklāt, tā kā tādu ierakstu lauku garumi ir vai nu fiksēti, vai konkrēti noteikti, nevienu no četrām nošķīrējzīmēm (“US”, “RS”, “GS” vai “FS”) neinterpretē citādi kā vien binārus datus. Bināros ierakstos “FS” zīmi nelieto kā ierakstu nošķīrēju vai darbības beigu zīmi.

3.   1. tipa loģiski dati – datnes galvene

Šajā ierakstā ir aprakstīta datnes struktūra, datnes tips un dota cita svarīga informācija. Zīmju kompleksā, ko izmanto 1. tipa laukos, ir tikai 7 bitu ANSI kods savstarpējai informācijas apmaiņai.

3.1.   1. tipa loģisku datu lauki

3.1.1.   1.001. lauks – loģiskā ieraksta garums (Logical Record Length – LEN)

Šajā laukā ir visa 1. tipa loģiskā ieraksta baitu kopskaits. Lauks sākas ar “1.001:”, kam seko ieraksta kopgarums, kurā ietverta katra zīme, kas atrodas katrā laukā, un informācijas nošķīrēji.

3.1.2.   1.002. lauks – versijas numurs (Version Number – VER)

Lai lietotāji zinātu, kādu ANSI/NIST standarta versiju lieto programmatūra vai sistēma, kas izstrādā datni, šajā četru baitu laukā ir konkrēti norādīts īstenotā standarta versijas numurs. Pirmie divi baiti norāda uz pamatversijas atsauces numuru, nākamie divi – uz mazāk būtisku uzlabojumu numuru. Piemēram, oriģinālais 1986. gada standarts būtu uzskatāms par pirmo versiju, un to apzīmētu ar “0100”, bet pašreizējais ANSI/NIST-ITL 1-2000 standarts ir “0300”.

3.1.3.   1.003. lauks – datnes saturs (File Content – CNT)

Šajā laukā ir uzskaitīts katrs datnes ieraksts pēc ieraksta tipa un secība, kādā ieraksti ir fiksēti loģiskā datnē. Tajā ir viens vai vairāki pakārtoti lauki, un katrā no tiem savukārt ir divi informācijas elementi, kuros ir aprakstīts vienīgais loģiskais ieraksts, kas atrodas aplūkojamā datnē. Pakārtotos laukus aizpilda tādā pašā secībā, kā ieraksta un pārraida ierakstus.

Pirmais informācijas elements pirmajā pakārtotajā laukā ir “1”, lai dotu atsauci uz 1. tipa ierakstu. Tam seko otrs informācijas elements, kurā ir pārējo datnes ierakstu skaits. Turklāt skaits ir vienāds ar 1.003. lauka atlikušo pakārtoto lauku skaitu.

Katrs no atlikušajiem pakārtotajiem laukiem ir saistīts ar vienu ierakstu datnē, un pakārtoto lauku secība atbilst ierakstu secībai. Katrā pakārtotā laukā ir divi informācijas elementi. Ar pirmo identificē ieraksta tipu. Otrais ir ieraksta IDC. “US” zīmi lieto, lai nošķirtu abus informācijas elementus.

3.1.4.   1.004. lauks – darbību tips (Type of Transaction – TOT)

Šajā laukā ir mnemonisks kods (piekļuves atslēga) no trijiem burtiem, kurš apzīmē darbības tipu. Kodi var atšķirties no tiem kodiem, ko lieto citos ANSI/NIST standartu īstenojumos.

CPS (Criminal Print-to-Print Search) – meklējumi, salīdzinot kriminālnoziedznieku atstātos nospiedumus. Šī darbība ir pieprasījums nospiedumu datubāzē meklēt ierakstus, kas attiecas uz kādu kriminālnoziegumu. Attiecīgās personas atstātie nospiedumi ir jāiekļauj datnē kā ar WSQ saspiesti attēli.

Ja dati nebūs atrasti (No-HIT), atbildē būs šādi loģiski ieraksti:

1 1. tipa ieraksts,

1 2. tipa ieraksts.

Ja dati būs atrasti (HIT), atbildē būs šādi loģiski ieraksti:

1 1. tipa ieraksts,

1 2. tipa ieraksts,

1-14 4. tipa ieraksti.

CPS TOT ir apkopoti A.6.1. tabulā (6. papildinājums).

PMS (Print-to-Latent Search) – datu meklējumi neidentificētu latentu nospiedumu datubāzē. Šādu darbību izmanto, ja kādu nospiedumu kompleksa atbilsme ir jāmeklē neidentificētu latentu nospiedumu datubāzē (Unidentified Latent database). Atbildē būs AFIS meklējumā iegūts lēmums “dati ir atrasti/dati nav atrasti” (Hit/No-Hit). Ja ir vairāki neidentificēti latenti nospiedumi, būs vairākas atbildes par SRE darbībām un katrā darbībā būs apstrādāts viens latentais nospiedums. Attiecīgās personas atstātie nospiedumi ir jāiekļauj datnē kā ar WSQ saspiesti attēli.

Ja dati nebūs atrasti (No-HIT), atbildē būs šādi loģiski ieraksti:

1 1. tipa ieraksts,

1 2. tipa ieraksts.

Ja dati būs atrasti (HIT), atbildē būs šādi loģiski ieraksti:

1 1. tipa ieraksts,

1 2. tipa ieraksts,

1 13. tipa ieraksts.

PMS TOT ir apkopoti A.6.1. tabulā (6. papildinājums).

MPS (Latent-to-Print Search) – latentu nospiedumu datu meklējumi nospiedumu datubāzē. Šādu darbību izmanto, ja latenti nospiedumi ir jāmeklē nospiedumu datubāzē. Datnē ir jāiekļauj informācija par latentām papilārlīniju detaļām un attēls (saspiests ar WSQ).

Ja dati nebūs atrasti (No-HIT), atbildē būs šādi loģiski ieraksti:

1 1. tipa ieraksts,

1 2. tipa ieraksts.

Ja dati būs atrasti (HIT), atbildē būs šādi loģiski ieraksti:

1 1. tipa ieraksts,

1 2. tipa ieraksts,

1 4. tipa vai 15. tipa ieraksts.

MPS TOT ir apkopoti A.6.4. tabulā (6. papildinājums).

MMS (Latent-to-Latent Search) – latentu nospiedumu salīdzinājums savā starpā. Veicot šo darbību, datnē ir latents nospiedums, kas jāsalīdzina ar neidentificētu latentu nospiedumu datubāzē (Unidentified Latent database) glabātiem datiem, lai noskaidrotu dažādu noziegumu vietu savstarpējo saistību. Datnē ir jāiekļauj informācija par latentām papilārlīniju detaļām un attēls (saspiests ar WSQ).

Ja dati nebūs atrasti (No-HIT), atbildē būs šādi loģiski ieraksti:

1 1. tipa ieraksts,

1 2. tipa ieraksts.

Ja dati būs atrasti (HIT), atbildē būs šādi loģiski ieraksti:

1 1. tipa ieraksts,

1 2. tipa ieraksts,

1 13. tipa ieraksts.

MMS TOT ir apkopoti A.6.4. tabulā (6. papildinājums).

SRE – šo darbību datu saņēmēja aģentūra sūta atpakaļ kā atbildi uz iesūtītiem daktiloskopijas datiem. Atbildē būs AFIS meklējumā iegūts lēmums “dati ir atrasti/dati nav atrasti” (Hit/No-Hit). Ja kandidātu ir vairāki, atpakaļ sūtīs vairākas SRE darbības un katram kandidātam būs veltīta viena darbība.

SRE TOT ir apkopoti A.6.2. tabulā (6. papildinājums).

ERR – šo darbību datu saņēmēja AFIS sūta atpakaļ kā atbildi, lai norādītu uz kļūdu darbībā. Tajā ir vēstījuma lauks (message field – ERM), kurā ir norādīta konstatētā kļūda. Atbildē būs šādi loģiski ieraksti:

1 1. tipa ieraksts,

1 2. tipa ieraksts.

ERR TOT ir apkopoti A.6.3. tabulā (6. papildinājums).

2. tabula. Pieļaujami darbību kodi

Transaction Type

Logical Record Type

1

2

4

9

13

15

CPS

M

M

M

SRE

M

M

C

(C in case of latent hits)

C

C

MPS

M

M

M (1*)

M

MMS

M

M

M (1*)

M

PMS

M

M

M*

M*

ERR

M

M

Atšifrējums:

M

=

obligāts (Mandatory)

M*

=

var iekļaut tikai vienu no abu tipu ierakstiem

O

=

fakultatīvs (Optional)

C

=

ar nosacījumu, ka dati ir pieejami (Conditional)

=

nav piekļuves

1*

=

ar nosacījumu – atkarībā no tā, kādas uzstādītas sistēmas izmanto darbā

3.1.5.   1.005. lauks – darbības datums (Date of Transaction – DAT)

Šajā laukā ir norādīts datums, kad darbība ir sākta, un tam ir jāatbilst ISO standartapzīmējumam –YYYYMMDD,

kur YYYY ir gads, MM ir mēnesis un DD ir mēneša diena. Viencipara skaitļu priekšā liek nulles. Piemēram, “19931004” nozīmē 1993. gada 4. oktobri.

3.1.6.   1.006. lauks – prioritāte (Priority – PRY)

Šajā fakultatīvajā laukā ir uzrādīta pieprasījuma prioritāte pakāpēs no 1 līdz 9. “1” ir lielākā prioritāte, un “9” – mazākā. “1. prioritātes” darbības apstrādā uzreiz.

3.1.7.   1.007. lauks – pieprasījuma saņēmējas aģentūras identifikators (Destination Agency Identifie – DAI)

Šajā laukā ir konkrēti norādīta darbības veicēja aģentūra.

Tajā ir divi informācijas elementi šādā formā – valsts kods un aģentūra (CC/agency).

Pirmajā informācijas elementā ir valsts kods (Country Code), ko definē, izmantojot ISO 3166 – tajā ir divas burtu vai ciparu zīmes. Otrs elements, aģentūra (agency), ir līdz 32 burtu vai ciparu zīmes garš brīvs teksts, un ar to identificē aģentūru.

3.1.8.   1.008. lauks – pieprasījuma iesniedzējas aģentūras identifikators (Originating Agency Identifier – ORI)

Šajā laukā ir konkrēti norādīta datnes izcelsmes aģentūra, un tā forma ir tāda pati kā DAI (1.007. lauks).

3.1.9.   1.009. lauks – darbības kontrolnumurs (Transaction Control Number TCN)

Kontrolnumurs ir domāts atsaucēm. Tam būtu jābūt datora ģenerētam un šādā formā –YYSSSSSSSSA,

kur YY ir darbības gads, SSSSSSSS ir astoņciparu sērijas numurs un A ir pārbaudes zīme, kas ģenerēta, ievērojot 2. papildinājumā paredzēto procedūru.

Ja TCN nav pieejams, lauku YYSSSSSSSS aizpilda ar nullēm un pārbaudes zīmi ģenerē, kā iepriekš norādīts.

3.1.10.   1.010. lauks – darbības atbildes kontrolnumurs (Transaction Control Response – TCR)

Ja ir izsūtīts pieprasījums, uz ko saņemta šāda atbilde, šajā fakultatīvajā laukā būs pieprasījuma atbildes darbības kontrolnumurs. Tālab tam ir tāda pati forma kā TCN (1.009. lauks).

3.1.11.   1.011. lauks – oriģinālā skenējuma izšķirtspēja (Native Scanning Resolution – NSR)

Šajā laukā ir uzrādīta normālā skenējuma izšķirtspēja sistēmai, ko izmanto darbības veicējs. Izšķirtspēju raksturo ar diviem cipariem, kam seko decimāldaļas punkts un pēc tā – vēl divi skaitļi.

Visām darbībām saskaņā ar Lēmumu 2008/615/TI nolasījumu koeficients ir 500 pikseļi collā jeb 19,68 pikseļi milimetrā.

3.1.12.   1.012. lauks – nominālā pārraides izšķirtspēja (Nominal Transmitting Resolution – NTR)

Šajā piecu baitu laukā ir konkrēti norādīta nominālā pārraides izšķirtspēja attēliem, ko pārraida. Izšķirtspēju izsaka pikseļos milimetrā – tādā pašā formā kā NSR (1.011. lauks).

3.1.13.   1.013. lauks – domēna nosaukums (Domain name – DOM)

Šajā obligātajā laukā ir identificēts domēna nosaukums lietotāja noteiktai 2. tipa loģiska ieraksta īstenošanai. Tajā ir divi informācijas elementi, un tie ir “INT-I{US}4.22{GS}”.

3.1.14.   1.014. lauks – Griničas laiks (Greenwich mean time – GMT)

Šis obligātais lauks nodrošina mehānismu, kā izteikt datumu un pulksteņa laiku Griničas laika (Greenwich Mean Time – GMT) vienībās. GMT laukā, ja to lieto, ir vispārējs datums, kas papildinās vietējo datumu, kas ir dots 1.005. laukā (DAT). GMT lauka lietojums likvidē vietējā laika nekonsekvences, kas izpaužas, ja darbību un atbildi pārraida starp divām vietām, ko šķir vairākas laika zonas. GMT laukā ir vispārpiemērojams datums un 24 stundu pulkstenis, kas nav atkarīgs no laika zonām. To atveido “CCYYMMDDHHMMSSZ” – kā 15 zīmju virkni, kurā datums ir sasaistīts ar GMT un kas beidzas ar “Z”. Zīmes “CCYY” rāda darbības gadu, zīmes “MM” rāda mēnešus, un zīmes “DD” rāda mēneša dienas, zīmes “HH” rāda stundas, “MM” rāda minūtes, un “SS” – sekundes. Pilnais datums nav lielāks par attiecīgās dienas datumu.

4.   2. tipa loģiski dati – ieraksts

Tādu ierakstu struktūras lielāko daļu nedefinē ar oriģinālo ANSI/NIST standartu. Šajos ierakstos ir informācija, kas rada īpašu ieinteresētību aģentūrām, kas sūta vai saņem attiecīgo datni. Lai nodrošinātu to, ka daktiloskopijas sistēmas, kas savā starpā sazinās, būtu saderīgas, ierakstā ir jābūt tikai šeit turpmāk uzskaitītiem laukiem. Šajā dokumentā ir konkrēti norādīts, kuri lauki ir obligāti, kuri fakultatīvi, un arī definēta atsevišķu lauku struktūra.

4.1.   2. tipa loģisku datu lauki

4.1.1.   2.001. lauks – loģiska ieraksta garums (Logical Record Length – LEN)

Šajā obligātajā laukā ir fiksēts attiecīgā 2. tipa ieraksta garums un konkrēti norādīts baitu kopskaits, ietverot katru ieraksta lauka zīmi un informācijas nošķīrējus.

4.1.2.   2.002. lauks – attēla raksturotāja zīme (Image Designation Character – IDC)

IDC, kas atrodas šajā obligātajā laukā, ASCII izteiksmē pārstāv IDC, kas ir definēta 1. tipa ieraksta datņu satura laukā (File Content field – CNT) (1.003. lauks).

4.1.3.   2.003. lauks – sistēmas informācija (System Information – SYS)

Šis lauks ir obligāts, un tajā ir četri baiti, kas rāda, kurai INT-I versijai atbilst konkrētais 2. tipa ieraksts.

Pirmie divi baiti norāda uz pamatversijas numuru, nākamie divi – uz mazāk būtisku uzlabojumu numuru. Piemēram, šajā īstenojumā ir izmantota INT-I 4. versija 22. pārskatījumā, un to atveido “0422”.

4.1.4.   2.007. lauks – lietas numurs (Case Number – CNO)

Šis ir numurs, ko vietējais daktiloskopijas birojs ir piešķīris nozieguma vietā savāktajiem latentajiem nospiedumiem. Izmanto šādu formu – CC/numurs (CC/number),

kur “CC” ir interpola valsts kods (Interpol Country Code) no divām burtu vai ciparu zīmēm, bet numurs atbilst attiecīgām vietējām pamatnorādēm, un tajā var būt līdz 32 burtu vai ciparu zīmes.

Šis lauks ļauj sistēmai identificēt latentos nospiedumus, kas ir saistīti ar konkrētu noziegumu.

4.1.5.   2.008. lauks – secības numurs (Sequence Number – SQN)

Tajā ir norādīta visu lietas latento nospiedumu secība. Tajā var būt līdz četras ciparu zīmes. Secība ir latentu nospiedumu attēls vai latentu nospiedumu attēlu sērija, kas sagrupēta uzskaites un/vai meklēšanas vajadzībām. Šī definīcija paredz, ka pat atsevišķiem latentiem nospiedumu attēliem būs jāpiešķir secības numurs.

Šo lauku līdz ar MID (2.009. lauks) var iekļaut, lai identificētu konkrētu latentu attēlu kādas secīgā virknē.

4.1.6.   2.009. lauks – latento nospiedumu identifikators (Latent Identifier – MID)

Ar šo ir konkrēti norādīts konkrēts latents nospiedums kādā secīgā virknē. Vērtība ir viens vai divi burti, un ar burtu “A” apzīmē pirmo latento attēlu, ar “B” – otro, un tā tālāk – līdz robežlielumam “ZZ”. Lauku izmanto analogi latento attēlu secības numuram, par ko ir runāts, aprakstot SQN (2.008. lauks).

4.1.7.   2.010. lauks – noziedznieka atsauces numurs (Criminal Reference Number – CRN)

Šis ir unikāls atsauces numurs, ko attiecīgas valsts aģentūra piešķir indivīdam, kas pirmo reizi ir notiesāts par izdarītu noziegumu. Vienā valstī nevienam indivīdam nekad nav vairāk par vienu CRN, un tas viņam nav kopīgs ne ar vienu citu cilvēku. Vienam un tam pašam cilvēkam gan var būt noziedznieka atsauces numurs vairākās valstīs, un to varēs atšķirt pēc valsts koda.

CRN laukam ir izstrādāta šāda forma – CC/numurs (CC/number),

kur “CC” ir valsts kods (Country Code), kas noteikts saskaņā ar ISO 3166, kurā ir divas burtu vai ciparu zīmes, un numurs atbilst attiecīgas valsts pieprasījuma izdevējas aģentūras pamatnorādēm, un tajā var būt līdz 32 burtu vai ciparu zīmes.

Darbībām saskaņā ar Lēmumu 2008/615/TI šo lauku izmantos attiecīgas valsts pieprasījuma izdevējas aģentūras nozieguma atsauces numuram, kas ir saistīts ar 4. tipa vai 15. tipa ierakstu attēliem.

4.1.8.   2.012. lauks – identifikācijas numurs dažādām vajadzībām (Miscellaneous Identification Number – MN1)

Šajā laukā ir CRN (2.010. lauks), ko pārraida, izmantojot CPS vai PMS darbības – bez iepriekš uzrādīta valsts koda.

4.1.9.   2.013. lauks – identifikācijas numurs dažādām vajadzībām (Miscellaneous Identification Number – MN2)

Šajā laukā ir CNO (2.007. lauks), ko pārraida, izmantojot MPS vai MMS darbības – bez iepriekš uzrādīta valsts koda.

4.1.10.   2.014. lauks – identifikācijas numurs dažādām vajadzībām (Miscellaneous Identification Number – MN3)

Šajā laukā ir SQN (2.008. lauks), ko pārraida, izmantojot MPS vai MMS darbības.

4.1.11.   2.015. lauks – identifikācijas numurs dažādām vajadzībām (Miscellaneous Identification Number – MN4)

Šajā laukā ir MID (2.009. lauks), ko pārraida, izmantojot MPS vai MMS darbības.

4.1.12.   2.063. lauks – papildu informācija (Additional Information – INF)

Ja notiek SRE darbība, atbildot uz PMS pieprasījumu, šajā laukā dod informāciju par pirkstu, kura parametri devuši iespējamu pozitīvu dokumentu atrašanas rezultātu (HIT). Lauka forma ir:

NN, kur NN ir 5. tabulā dotais pirksta novietojuma kods no diviem cipariem.

Citos gadījumos lauku izmantot nav obligāti. Tajā ir līdz 32 burtu vai ciparu zīmes, un tas var dot papildu informāciju par pieprasījumu.

4.1.13.   2.064. lauks – atbildētāju saraksts (Respondents List – RLS)

Šajā laukā ir vismaz divi pakārtoti lauki. Pirmajā pakārtotajā laukā ir aprakstīts veiktā meklējuma tips, izmantojot mnemonisku kodu no trijiem burtiem, kurš norāda uz darbības tipu TOT laukā (1.004. lauks). Otrajā pakārtotajā laukā ir viena zīme. Zīmi “I” lieto, lai norādītu, ka dati ir atrasti (HIT), un zīmi “N” lieto, lai norādītu, ka sakritīgi dati nav atrasti (NOHIT). Trešajā pakārtotajā laukā ir secības identifikators, kas attiecas uz kandidāta rezultātu un kandidātu kopskaitu, ko vienu no otra atdala slīpsvītra. Ja kandidāti ir vairāki, arī atbildes būs vairākas.

Iespējamā datu atrašanas gadījumā (HIT) ceturtā pakārtotā laukā būs rezultāts – līdz sešiem cipariem. Ja datu atrašana (HIT) ir apstiprināta, šā pakārtotā lauka vērtība ir definēta kā “999999”.

Piemērs – “CPS{RS}I{RS}001/001{RS}999999{GS}”.

Ja attālinātā AFIS nedod datus par rezultātiem, attiecīgā punktā būtu jādod rezultāts nulle.

4.1.14.   2.074. lauks – statusa lauks/lauks ar paziņojumu par kļūdu (Status/Error Message – ERM)

Šajā laukā ir paziņojumi par kļūdām, kas radušās darbībās un ko sūtīs atpakaļ pieprasījuma iesniedzējam kā piederīgu pie kļūdainas darbības (Error Transaction).

3. tabula. Paziņojumi par kļūdām

Numeric Code (1-3)

Meaning (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

Paziņojumi par kļūdām diapazonā no 100 līdz 199:

Paziņojumi par kļūdām ir saistīti ar ANSI/NIST ierakstu apstiprināšanu, un tos definē šādi:

<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>...

kur:

error_code” ir kods, kas ir saistīts tikai ar konkrētu iemeslu (sk. 3. tabulu),

“field_id” ir nepareiza ANSI/NIST lauka numurs (piem., 1.001, 2.001, ...) šādā formā – “<record_type>.<field_id>.<sub_field_id>”,

dinamisks teksts (dynamic text) ir sīkāks, dinamisks kļūdas apraksts,

LF (Line Feed) ir rindas pārnesums, kas atdala kļūdas, ja ir sastapta vairāk nekā viena kļūda,

1. tipa ierakstiem ICD ir definēts kā “-1”.

Piemērs:

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

Šis lauks ir obligāts kļūdainu darbību gadījumā.

4.1.15.   2.320. lauks – paredzamais kandidātu skaits (Expected Number of Candidates – ENC)

Šajā laukā ir dots lielākais iespējamais kandidātu skaits pārbaudei, ko pieprasījuma iesniedzēja aģentūra var paredzēt. ENC vērtība nevar būt lielāka par 11. tabulā noteiktajām vērtībām.

5.   4. tipa loģiski dati – melnbalti tonāli attēli ar lielu izšķirtspēju

Būtu jāņem vērā, ka 4. tipa ieraksti būtībā ir bināri, nevis ASCII. Tālab katram laukam ierakstā atvēl īpašu vietu, un tas nozīmē, ka visi lauki ir obligāti.

Standarts ļauj ierakstā konkrēti uzrādīt gan attēla lielumu, gan izšķirtspēju. Ir vajadzīgi 4. tipa loģiski ieraksti, lai varētu glabāt daktiloskopijas attēlu datus, ko pārraida ar nominālu pikseļu blīvumu – 500 līdz 520 pikseļu collā. Ieteicamais jaunu izstrādņu koeficients ir paredzēt pikseļu blīvumu – 500 pikseļu collā jeb 19,68 pikseļu milimetrā. 500 pikseļu collā ir blīvums, kas ir paredzēts ar INT-I, izņemot to, ka līdzīgas sistēmas var savā starpā sazināties, neizmantojot ieteicamo koeficientu un izmantojot ieteicamo robežlielumu – 500 līdz 520 pikseļiem collā.

5.1.   4. tipa loģisku datu lauki

5.1.1.   4.001. lauks – loģisku ierakstu garums (Logical Record Length – LEN)

Šajā četru baitu laukā ir fiksēts minētā 4. tipa ieraksta garums un konkrēti norādīts baitu kopskaits, aptverot katru baitu katrā ieraksta laukā.

5.1.2.   4.002. lauks – attēla zīme (Image Designation Character – IDC)

Šis ir datnes galvenē dotā IDC numura binārs atveidojums vienā baitā.

5.1.3.   4.003. lauks – nospieduma tips (Impression Type – IMP)

Nospieduma tips ir viena baita lauks, kas aizņem ieraksta sesto baitu.

4. tabula. Pirkstu nospiedumu tipi

Code

Description

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. lauks – pirksta novietojums (Finger Position – FGP)

Šis fiksēta garuma 6 baitu lauks aizņem no septītā līdz divpadsmitajam baitam 4. tipa ierakstā. Tajā ir uzrādīti iespējamie pirkstu novietojumi, sākot no baita, kas atrodas vistālāk pa kreisi (ieraksta 7. baits). Zināms vai visticamākais pirksta novietojums ir ņemts no 5. tabulas. Var dot atsauces vēl līdz pat pieciem citiem pirkstiem, ierakstot citu pirkstu novietojumus atlikušos piecos baitos – tādā pašā formā. Ja ir paredzams izmantot mazāk nekā piecu pirkstu novietojumu atsauces, neizmantotos baitus aizpilda ar bināriem “255”. Lai dotu atsauci uz visiem pirkstu novietojumiem, lieto kodu “0” – “nav zināms”.

5. tabula. Pirkstu novietojuma kodi un maksimāli iespējamie lielumi

Finger position

Finger code

Width

(mm)

Length

(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

Apzīmējot noziegumu vietās atrastus latentus nospiedumus, būtu jāizmanto tikai kodi no “0” līdz “10”.

5.1.5.   4.005. lauks – attēla skenējuma izšķirtspēja (Image Scanning Resolution – ISR)

Šis viena baita lauks 4. tipa ierakstā aizņem 13. baitu. Ja tajā ir “0”, tad attēls ir nolasīts ar ieteicamo skenējuma koeficientu – 19,68 pikseļi milimetrā (500 pikseļu collā). Ja tajā ir “1”, tad attēls ir nolasīts ar citu skenējuma koeficientu, kas ir konkrēti norādīts 1. tipa ierakstā.

5.1.6.   4.006. lauks – horizontālu līniju garums (Horizontal Line Length – HLL)

Šis lauks 4. tipa ierakstā atrodas pie 14. un 15. baita. Tajā ir norādīts katras skenējuma līnijas pikseļu skaits. Pirmais baits būs pats svarīgākais.

5.1.7.   4.007. lauks – vertikālu līniju garums (Vertical Line Length – VLL)

Šā lauka 16. un 17. baitā ir fiksēts attēla skenējuma līniju skaits. Pirmais baits ir pats svarīgākais.

5.1.8.   4.008. lauks – melnbaltu tonālu attēlu saspiešanas algoritms (Gray-scale Compression Algorithm – GCA)

Šajā viena baita laukā norāda melnbaltu tonālu attēlu saspiešanas algoritmu, ko izmanto, lai kodētu attēla datus. Šādā īstenojumā binārs kods “1” norāda, ka ir lietota WSQ saspiešana (7. papildinājums).

5.1.9.   4.009. lauks – attēls

Šajā laukā ir attēla atveidotāju baitu straume. Tās struktūra acīmredzot būs atkarīga no izmantotā saspiešanas algoritma.

6.   9. tipa loģiski dati – papilārlīniju detaļu ieraksts

9. tipa ierakstos ir ASCII teksts, kurā ir aprakstītas papilārlīniju detaļas un saistīta informācija, kas ir kodēta no latenta nospieduma. Latentu nospiedumu meklēšanas darbībās tādiem 9. tipa ierakstiem datnē nav nekādu ierobežojumu, jo katrs no tiem būs citā leņķī – vai cits latents nospiedums.

6.1.   Papilārlīniju detaļu konstatācija

6.1.1.   Papilārlīniju detaļu tipa identifikācija

Šajā standartā ir definēti trīs identifikācijas numuri, ko lieto, lai raksturotu papilārlīniju detaļu tipu. Tie ir uzskaitīti 6. tabulā. Papilārlīniju nobeigumu dēvē par 1. tipu. Bifurkāciju dēvē par 2. tipu. Ja papilārlīniju detaļas nevar skaidri klasificēt kā vienu no abiem iepriekš minētajiem tipiem, to dēvē par “citu (other)”, 0. tipu.

6. tabula. Papilārlīniju detaļu tipi

Type

Description

0

Other

1

Ridge ending

2

Bifurcation

6.1.2.   Papilārlīniju detaļu atrašanās vieta un tips

Lai paraugi būtu saderīgi ar ANSI INCITS 378-2004 standarta 5. iedaļu, atsevišķu papilārlīniju detaļu atrašanās vietas (vietas un novietojuma leņķa) noteikšanai izmanto šādu metodi, kas papildina pašlaik spēkā esošo INCITS 378-2004 standartu.

Papilārlīniju detaļu, t. i., papilārlīnijas gals ir viduspunkts, kurā tieši pirms papilārlīnijas gala sazarojas starplīniju iedobes. Ja trīs starplīniju iedobju atzarlīnijas sašaurina līdz viena pikseļa platai līnijai, krustpunkts ir papilārlīniju detaļu atrašanās vieta. Līdzīgi bifurkāciju papilārlīniju detaļu atrašanās vieta ir punkts, kur sazarojas papilārlīniju viduslīnija. Ja papilārlīniju trīs atzarlīnijas sašaurina līdz viena pikseļa platai līnijai, punkts, kur trīs atzarlīnijas šķērso cita citu, ir papilārlīniju detaļu atrašanās vieta.

Kad visi papilārlīniju gali ir pārvērsti bifurkācijās, visas daktiloskopijas attēla papilārlīniju detaļas parādās kā bifurkācijas. Pikseļu X un Y koordināšu līnijas katru papilārlīniju detaļu triju atzarlīniju krustpunktā var formatēt tieši. Papilārlīniju detaļu virzienu var atvasināt pēc katras līnijas bifurkācijas. Katras līnijas bifurkācijas trīs atzarlīnijas ir jāanalizē, un jānosaka katras atzarlīnijas gals. 6.1.2. attēlā ir rādītas trīs metodes, ko izmanto, lai noteiktu atzarlīniju galu, izmantojot skenējuma izšķirtspēju 500. punkti collā.

Atzarlīniju galu nosaka atkarībā no tā, kas ir pirmais. Pikseļu skaitu nosaka pēc skenējuma ar izšķirtspēju 500. punkti collā. Dažādu skenējumu izšķirtspēja nozīmētu dažādu pikseļu skaitu.

Attālums – .064” (32. pikselis),

gala līniju atzarlīnijas, kas sākas attālumā no .02” līdz .064” (no 10. līdz 32. pikselim ieskaitot); īsākas atzarlīnijas neņem vērā,

konstatēta otra bifurkācija .064” attālumā (pirms 32. pikseļa).

6.1.2. zīmējums

Image

Papilārlīniju detaļu leņķi nosaka, konstruējot trīs iedomātas līnijas no bifurkācijas punkta un velkot tās līdz katras atzarlīnijas galam. Mazāko no trijiem līniju veidotajiem leņķiem sadala uz pusēm, lai rādītu papilārlīniju detaļu virzienu.

6.1.3.   Koordinātu sistēma

Koordinātu sistēma, ko izmanto, lai raksturotu pirkstu nospiedumu papilārlīniju detaļas, ir Dekarta koordinātu sistēma. Papilārlīniju detaļu atrašanās vietu raksturo to x un y koordinātes. Koordinātu sistēmas sākumpunkts ir oriģinālā attēla kreisais augšējais stūris, no kā x virzās pa labi un y virzās lejup. Gan papilārlīniju detaļu x, gan y koordinātes atveido pikseļu vienībās, sākot no sākumpunkta. Būtu jāņem vērā, ka sākumpunkta vieta un mērvienības neatbilst parastajām, ko izmanto 9. tipa definīcijās, kas dotas standartā ANSI/NIST-ITL 1-2000.

6.1.4.   Papilārlīniju detaļu virziens

Leņķus izsaka parastā matemātiskā formā, ar nulli grādu labajā pusē un leņķiem, kas palielinās pretēji pulksteņa rādītāja virzienam. Papilārlīniju galu leņķus fiksē atpakaļvirzienā gar papilārlīnijām un bifurkāciju leņķus – virzienā uz iedobes vidu. Tas ir 180 grādus pretī 9. tipa standartā ANSI/NIST-ITL 1-2000 aprakstītajiem leņķiem.

6.2.   Lauki 9. tipa loģiskiem ierakstiem INCITS-378 formā

Visos 9. tipa ierakstu laukos tekstu raksta ASCII formā. Šajos marķētu lauku ierakstos nav pieļaujami bināri lauki.

6.2.1.   9.001. lauks – loģisku ierakstu garums (Logical record length – LEN)

Šajā obligātajā ASCII laukā ir loģisku ierakstu garums, konkrēti norādot baitu kopskaitu, ietverot katru ieraksta lauka zīmi.

6.2.2.   9.002. lauks – attēla raksturotāja zīme (Image designation character – IDC)

Šo obligāto divu baitu lauku izmanto papilārlīniju detaļu datu identifikācijai un atrašanās vietas norādei. Šajā laukā dotais IDC saskan ar IDC, kas atrodas 1. tipa ieraksta datnes satura laukā.

6.2.3.   9.003. lauks – nospieduma tips (Impression type – IMP)

Šajā obligātajā viena baita laukā ir aprakstīts, kā iegūta daktiloskopijas attēla informācija. Atbilstošā 4. tabulā izvēlētā koda ASCII vērtību ieraksta šajā laukā, lai raksturotu nospieduma tipu.

6.2.4.   9.004. lauks – papilārlīniju detaļu forma (Minutiæ format – FMT)

Šajā laukā ir “U”, kas norāda, ka papilārlīniju detaļas ir formatētas saskaņā ar M1-378. Kaut arī informācija var būt kodēta saskaņā ar standartu M1-378, visiem 9. tipa ieraksta datu laukiem ir jāpaliek ASCII teksta laukiem.

6.2.5.   9.126. lauks – CBEFF informācija

Šajā laukā ir trīs informācijas elementi. Pirmajā informācijas elementā ir vērtība “27” (0x1B). Tā identificē CBEFF formu (CBEFF Format Owner), ko Starptautiskā Biometrijas nozares apvienība (International Biometric Industry Association – IBIA) piešķīrusi INCITS tehniskai komitejai M1 (INCITS Technical Committee M1). Zīme <US> norobežo šo elementu no CBEFF formas tipa (CBEFF Format Type), kam ir piešķirta vērtība“513” (0x0201), lai norādītu, ka šajā ierakstā ir tikai atrašanās vietas un virziena leņķa dati bez kādas paplašinātas datu bloku informācijas (Extended Data Block information). Zīme <US> norobežo šo elementu no CBEFF ražojuma identifikatora (Product Identifier – PID), kas identificē kodēšanas iekārtas nosacīto īpašnieku. Šo vērtību nosaka iekārtas pārdevējs. To var saņemt IBIA tīkla lapā (www.ibia.org), ja tā ir paredzēts.

6.2.6.   9.127. lauks – fiksācijas iekārtu identifikācija

Šajā laukā ir divi informācijas elementi, ko nošķir <US> zīme. Pirmajā ir “APPF”, ja attēla ieguvei lietotā iekārta ir sertificēta kā atbilstoša Federālā izmeklēšanas biroja elektroniskas pirkstu nospiedumu pārsūtīšanas parametru CJIS-RS-0010 (Federal Bureau of Investigation s Electronic Fingerprint Transmission Specification) F papildinājumam (IAFIS Image Quality Specification, January 29, 1999). Ja iekārta tam neatbilst, laukā būs vērtība “NONE”. Otrā informācijas elementā ir fiksācijas iekārtas identifikācija (Capture Equipment ID), fiksācijas iekārtas pārdevēja piešķirts ražojuma numurs. Vērtība “0” rāda, ka fiksācijas iekārtas identifikācija (ID) nav darīta zināma.

6.2.7.   9.128. lauks – horizontālu līniju garums (Horizontal line length – HLL)

Šajā obligātajā ASCII laukā ir vienā horizontālā pārraidītā attēla līnijā esošo pikseļu skaits. Maksimālais pieļaujamais horizontālais lielums ir 65 534 pikseļi.

6.2.8.   9.129. lauks – vertikālo līniju garums (Vertical line length – VLL)

Šajā obligātajā ASCII laukā ir pārraidītā attēla horizontālo līniju skaits. Maksimālais pieļaujamais vertikālais lielums ir 65 534 pikseļi.

6.2.9.   9.130. lauks – mērogi (Scale units – SLC)

Šajā obligātajā ASCII laukā ir norādītas vienības, ko izmanto, lai aprakstītu attēla nolasīšanas frekvenci (pikseļu blīvumu). Cipars “1” šajā laukā rāda pikseļus collā, savukārt “2” rāda pikseļus centimetrā. Cipars “0” šajā laukā rāda, ka mērogs nav uzrādīts. Tādos gadījumos HPS/VPS dalījums dod pikseļu attiecības koeficientu.

6.2.10.   9.131. lauks – horizontāls pikseļu mērogs (Horizontal pixel scale – HPS)

Šajā obligātajā ASCII laukā konkrēti norāda horizontālā virzienā izmantoto pikseļu blīvumu veselos skaitļos, ja SLC ir ar “1” vai “2”. Ja tā nav, tas rāda pikseļu attiecības koeficienta horizontālo komponentu.

6.2.11.   9.132. lauks – vertikāls pikseļu mērogs (Vertical pixel scale – VPS)

Šajā obligātajā ASCII laukā konkrēti norāda vertikālā virzienā izmantoto pikseļu blīvumu veselos skaitļos, ja SLC ir ar “1” vai “2”. Ja tā nav, tas rāda pikseļu attiecības koeficienta vertikālo komponentu.

6.2.12.   9.133. lauks – pirksta attēls

Šajā obligātajā laukā ir ar ieraksta datiem saistītā pirksta attēls. Attēlu kārtas skaitlis sākas ar “0”, un mainās pa vienam līdz “15”.

6.2.13.   9.134. lauks – pirksta novietojums (Finger position – FGP)

Šajā laukā ir kods, kas apzīmē pirksta novietojumu, kādā ir iegūta šā 9. tipa ieraksta informācija. Kodu no 1 līdz 10, ņemtu no 5. tabulas vai attiecīgi 10. plaukstu koda tabulas, izmanto, lai norādītu pirksta vai plaukstas novietojumu.

6.2.14.   9.135. lauks – pirksta kvalitāte

Laukā ir visu pirksta papilārlīniju detaļu datu kvalitāte, un to raksturo skaitlis no 0 līdz 100. Šis skaitlis kopumā raksturo pirksta attēla ieraksta kvalitāti, kā arī rāda iegūtā attēla kvalitāti, iespēju nošķirt papilārlīniju detaļas un veikt visas papildu darbības, kas var iespaidot papilārlīniju detaļu ierakstus.

6.2.15.   9.136. lauks – papilārlīniju detaļu skaits

Šajā obligātajā laukā ir attiecīgajā loģiskajā ierakstā fiksēts papilārlīniju detaļu skaits.

6.2.16.   9.137. lauks – pirkstu papilārlīniju detaļu dati

Šajā obligātajā laukā ir seši informācijas elementi, nošķirti ar <US> zīmi. Tajā ir vairāki pakārtoti lauki, un katrā no tiem ir kādas papilārlīnijas sīkākas detaļas. Papilārlīniju detaļu pakārtoto lauku kopskaitam jāsaskan ar 136. laukā doto skaitu. Pirmais informācijas elements ir papilārlīniju detaļu kārtas numurs, ko raksta kā pirmo “1” un palielina par “1” katrai papildu papilārlīniju detaļai pirksta nospiedumā. Otrais un trešais informācijas elements ir papilārlīniju detaļu “x” un “y” koordinātes pikseļu vienībās. Ceturtais informācijas elements ir papilārlīniju detaļu leņķis, fiksēts divu grādu vienībās. Tā vērtība ir nenegatīva, no 0 līdz 179. Piektais informācijas elements ir papilārlīniju detaļu tips. Vērtību “0” lieto, lai raksturotu “OTHER” tipa papilārlīniju detaļas, vērtība “1” papilārlīniju galiem un vērtība “2” – papilārlīniju bifurkācijām. Sestais informācijas elements raksturo katras papilārlīniju detaļas kvalitāti. Tā vērtība sākas no 1 – sliktākās – līdz 100 – labākajai. Vērtība “0” rāda, ka kvalitātes vērtība nav zināma. Katru pakārtoto lauku nošķir no nākamā ar <RS> nošķīrējzīmi.

6.2.17.   9.138. lauks – papilārlīniju skaita informācija

Šajā laukā ir vairāki pakārtoti lauki, no kuriem katrā ir trīs informācijas elementi. Pirmā pakārtotā lauka pirmais informācijas elements rāda papilārlīniju skaitīšanas metodi. “0” rāda, ka par papilārlīniju skaitīšanas metodi vai par to kārtību ierakstā neizdara nekādus pieņēmumus. “1” rāda, ka dati par visām centra papilārlīniju detaļām, papilārlīniju skaitu ir iegūti līdz tuvākajai blakus esošajai papilārlīniju detaļai četros kvadrantos un visu centra papilārlīniju detaļu papilārlīniju skaits ir apkopots. “2” rāda, ka visām centra papilārlīniju detaļām papilārlīniju skaita dati ir iegūti līdz tuvākajai blakus esošajai papilārlīniju detaļai astoņos oktantos un visu centra papilārlīniju detaļu papilārlīniju skaits ir apkopots. Atlikušajos divos pirmā pakārtotā lauka informācijas elementos ir “0”. Informācijas elementus nošķir ar <US> nošķīrējzīmi. Pārējos pakārtotos laukos tāpat kā pirmajā informācijas elementā būs centra papilārlīniju detaļu kārtas numurs, blakus esošo papilārlīniju detaļu kārtas numurs kā otrs informācijas elements un šķērsotu papilārlīniju skaits kā trešais informācijas elements. Pakārtotos laukus nošķir ar <RS> nošķīrējzīmi.

6.2.18.   9.139. lauks – informācija par centriem

Šajā laukā būs viens pakārtots lauks katram attēlā redzamajam centram. Katrā pakārtotajā laukā ir trīs informācijas elementi. Pirmie divi elementi ir “x” un “y” koordinātes pikseļu vienībās. Trešajā informācijas elementā ir centra leņķis, fiksēts 2 grādu vienībās. Tā vērtība ir nenegatīva, no 0 līdz 179. Vairākus centrus nošķir ar <RS> nošķīrējzīmi.

6.2.19.   9.140. lauks – informācija par deltām

Šajā laukā ir viens pakārtots lauks katrai attēlā redzamajai deltai. Katrā pakārtotajā laukā ir trīs informācijas elementi. Pirmie divi elementi ir “x” un “y” koordinātes pikseļu vienībās. Trešajā informācijas elementā ir deltas leņķis, fiksēts 2 grādu vienībās. Tā vērtība ir nenegatīva, no 0 līdz 179. Vairākus centrus nošķir ar <RS> nošķīrējzīmi.

7.   13. tips – latentu attēlu ieraksti ar maināmu izšķirtspēju

13. tipa marķētu lauku loģiskos ierakstos ir no latentiem attēliem iegūti dati. Minētie attēli ir domāti pārraidīšanai aģentūrām, kas automatizēti iegūs vai ar cilvēku iejaukšanos un apstrādi iegūs vajadzīgo elementu informāciju no attēliem.

Informācija par izmantoto skenējuma izšķirtspēju, attēla lielumu un citiem parametriem, kas vajadzīgi, lai apstrādātu attēlu, ierakstā ir fiksēta kā marķēti lauki.

7. tabula. 13. tipa latenti attēli ar maināmu izšķirtspēju – ierakstu izkārtojums

Ident

Cond. code

Field Number

Field Name

Char type

Field size per occurrence

Occur count

Max byte count

min.

max.

min

max

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

13.019

RESERVED FOR FUTURE DEFINITION

COM

O

13.020

COMMENT

A

2

128

0

1

135

RSV

 

13.021

13.199

RESERVED FOR FUTURE DEFINITION

UDF

O

13.200

13.998

USER-DEFINED FIELDS

DAT

M

13.999

IMAGE DATA

B

2

1

1

Simbolu atšifrējums: N = ciparu; A = burtu; AN = ciparu un burtu; B = binārs.

7.1.   13. tipa loģisku datu lauki

Šajos punktos ir aprakstīti dati, kas atrodas katrā 13. tipa loģisku ierakstu laukā.

13. tipa loģiskos ierakstos ierakstu lauki ir numurēti. Pirmajiem diviem ieraksta laukiem noteikti jābūt sakārtotiem, un lauks ar attēla datiem ir ieraksta pēdējais fiziskais lauks. Katram 13. tipa ieraksta laukam 7. tabulā ir uzskaitīts “nosacījumu kods” – obligāts “M” vai fakultatīvs “O”, lauka numurs, lauka nosaukums, zīmes tips, lauka lielums un sastopamības robežlielumi. Izmantojot trīsciparu lauka numuru, lielākais iespējamais baitu skaits laukā ir dots pēdējā ailē. Ja vairāk ciparu lieto lauka numura apzīmēšanai, attiecīgi pieaugs arī lielākais iespējamais baitu skaits. Divos ierakstos “lauka lielums katrā sastopamības gadījumā” ir visas nošķīrējzīmes, kas izmantotas laukā. “Lielākais iespējamais baitu skaits” ietver lauka numuru, informāciju un visas nošķīrējzīmes, arī “GS” zīmi.

7.1.1.   13.001. lauks – loģisku ierakstu garums (Logical record length – LEN)

Šajā obligātajā ASCII laukā ir 13. tipa loģiskā ieraksta baitu kopskaits. 13.001. laukā konkrēti norāda ieraksta garumu, ietverot katru ieraksta lauka zīmi un informācijas nošķīrējus.

7.1.2.   13.002. lauks – attēla raksturotāja zīme (Image designation character – IDC)

Šo obligāto ASCII lauku izmanto, lai identificētu latentā attēla datus ierakstā. Šis IDC atbilst IDC, kas atrodas 1. tipa ieraksta datnes satura (CNT) laukā.

7.1.3.   13.003. lauks – nospieduma tips (Impression type – IMP)

Šis obligātais viena vai divu baitu ASCII lauks rāda, kā iegūta latentā attēla informācija. Šajā laukā ieraksta attiecīgi izvēlētu latento attēlu kodu no 4. tabulas (pirksti) vai 9. tabulas (plaukstas).

7.1.4.   13.004. lauks – attēla ieguvēja aģentūra (Source agency/ORISRC)

Šajā obligātajā ASCII laukā ir identificēta pārvalde vai organizācija, kas ieguvusi ierakstā ietverto sejas attēlu. Parastos apstākļos šajā laukā uzrāda izcelsmes aģentūras identifikatoru (Originating Agency Identifier – ORI) – kura aģentūra ir ieguvusi attēlu. Tajā ir divi informācijas elementi šādā formā – CC/aģentūra (CC/agency).

Pirmajā informācijas elementā ir Interpola izstrādātais valsts kods (Country Code), divas burtu vai ciparu zīmes. Otrs elements, aģentūra (agency), ir līdz 32 burtu vai ciparu zīmes garš brīvs teksts, un ar to identificē aģentūru.

7.1.5.   13.005. lauks – latentā attēla fiksācijas datums (Latent capture date – LCD)

Šajā obligātajā ASCII laukā ir datums – kad fiksēts ierakstā dotais latentais attēls. Datumam no astoņiem cipariem ir šāda forma “CCYYMMDD”. Zīmes “CCYY” rāda gadu, kad attēls ir fiksēts, zīmes “MM” rāda mēnešus, un zīmes “DD” rāda mēneša dienas. Piemēram, 20000229 nozīmē 2000. gada 29. februāri. Pilnam datumam ir jābūt likumīgam datumam.

7.1.6.   13.006. lauks – horizontālu līniju garums (Horizontal line length – HLL)

Šajā obligātajā ASCII laukā pikseļu skaits vienā horizontālā pārraidītā attēla līnijā.

7.1.7.   13.007. lauks – vertikālu līniju garums (Vertical line length – VLL)

Šajā obligātajā ASCII laukā ir pārraidītā attēla horizontālo līniju skaits.

7.1.8.   13.008. lauks – mēroga mērvienības (SLC)

Šajā obligātajā ASCII laukā ir norādītas vienības, ko izmanto, lai aprakstītu attēla nolasīšanas frekvenci (pikseļu blīvumu). Cipars “1” šajā laukā rāda pikseļus collā, savukārt “2” rāda pikseļus centimetrā. Cipars “0” šajā laukā nozīmē, ka mērogs nav uzrādīts. Tādos gadījumos HPS/VPS dalījums dod pikseļu attiecības koeficientu.

7.1.9.   13.009. lauks – horizontāls pikseļu mērogs (Horizontal pixel scale – HPS)

Šajā obligātajā ASCII laukā konkrēti norāda horizontālā virzienā izmantoto pikseļu blīvumu veselos skaitļos, ja SLC ir ar “1” vai “2”. Ja tā nav, tas rāda pikseļu attiecības koeficienta horizontālo komponentu.

7.1.10.   13.010. lauks – vertikāls pikseļu mērogs (Vertical pixel scale – VPS)

Šajā obligātajā ASCII laukā konkrēti norāda vertikālā virzienā izmantoto pikseļu blīvumu veselos skaitļos, ja SLC ir ar “1” vai “2”. Ja tā nav, tas rāda pikseļu attiecības koeficienta vertikālo komponentu.

7.1.11.   13.011. lauks – saspiešanas algoritms (Compression algorithm – CGA)

Šajā obligātajā ASCII laukā konkrēti norāda algoritmu, ko lieto, lai saspiestu melnbaltus tonālus attēlus. Saspiešanas kodus sk. 7. papildinājumā.

7.1.12.   13.012. lauks – biti pikselī (Bits per pixel – BPX)

Šajā obligātajā ASCII laukā ir bitu skaits, kas izmantots, lai izveidotu pikseli. Šajā laukā ir cipars “8” normālu melnbaltu tonālu attēlu vērtībām no “0” līdz “255”. Jebkurš ieraksts šajā laukā, lielāks par “8”, raksturo melnbaltu tonālu attēlu pikseli, kam ir palielināta precizitāte.

7.1.13.   13.013. lauks – pirkstu/plaukstu atrašanās vieta (Finger/palm position – FGP)

Šajā obligātajā marķētajā laukā ir viena vai vairākas iespējamas pirkstu vai plaukstu atrašanās vietas, kas var atbilst latentajam attēlam. Decimālciparu koda numuru, kas atbilst zināmam vai visiespējamākam pirksta novietojumam, atrod 5. tabulā – vai visiespējamākajam plaukstas novietojumam – 10. tabulā, un ieraksta kā vienu vai divas zīmes pakārtotā ASCII laukā. Atsauces par papildu pirkstu un/vai plaukstu atrašanās vietām var ierakstīt, izmantojot citu atrašanās vietu kodus kā pakārtotus laukus, ko nošķir ar “RS” nošķīrējzīmi. Kodu “0”, lai apzīmētu “nezināmu pirkstu (Unknown Finger)”, izmanto, lai dotu atsauci par katru pirksta novietojumu no viena līdz desmit. Kodu “20”, lai apzīmētu “nezināmu plaukstu (Unknown Palm)”, izmanto, lai dotu atsauci par katru uzskaitītu plaukstas nospieduma atrašanās vietu.

7.1.14.   13.014–019. lauks – rezervēts nākotnē iespējamām vajadzībām (Reserved for future definition – RSV)

Šie lauki ir atstāti tukši, lai tajos varētu nākotnē ierakstīt šā standarta pārstrādājumus. Neviens no šiem laukiem nav jālieto pašreizējā izstrādes līmenī. Ja kāds no šiem laukiem parādās, tas jāignorē.

7.1.15.   13.020. lauks – piebildes (Comment – COM)

Šajā fakultatīvajā laukā var ierakstīt piebildes vai citu ASCII teksta informāciju par latentā attēla datiem.

7.1.16.   13.021–199. lauks – rezervēts nākotnē iespējamām vajadzībām (Reserved for future definition – RSV)

Šie lauki ir atstāti tukši, lai tajos varētu nākotnē ierakstīt šā standarta pārstrādājumus. Neviens no šiem laukiem nav jālieto pašreizējā izstrādes līmenī. Ja kāds no šiem laukiem parādās, tas jāignorē.

7.1.17.   13.200–998. lauks – lietotāju definēti lauki (User-defined fields – UDF)

Šos laukus var savām vajadzībām piemērot paši lietotāji, un tos lietos nākotnē. To lielumu un saturu definē paši lietotāji saskaņā ar saņēmēju aģentūru. Ja tādi parādās, tajos ir ASCII teksta informācija.

7.1.18.   13.999. lauks – attēla dati (Image data – DAT)

Šajā laukā ir visi fiksētā latentā attēla dati. Tam vienmēr piešķir lauka numuru 999, un tam jābūt pēdējam fiziskam laukam ierakstā. Piemēram, pēc “13.999:” ir doti attēla dati binārā formā.

Katru nesaspiestu melnbaltu tonālu attēlu datu pikseli parasti kvantē par astoņiem bitiem (256 toņu pelēkumu) vienā baitā. Ja ieraksts 13.012. (BPX) laukā ir lielāks vai mazāks par “8”, baitu skaits, kas vajadzīgs vienam pikselim, būs citāds. Ja lieto saspiešanu, pikseļu dati ir saspiesti saskaņā ar GCA laukā norādīto saspiešanas paņēmienu.

7.2.   13. tips – latents attēls ar maināmu izšķirtspēju – beigas

Konsekvences labad tūlīt pēc pēdēja datu baita 13.999. laukā lieto “FS” nošķīrēju, lai nošķirtu to no nākamā loģiskā ieraksta. Šis nošķīrējs ir jāiekļauj 13. tipa ieraksta garuma laukā.

8.   15. tips – plaukstu nospiedumu attēli ar maināmu izšķirtspēju

15. tipa marķētu lauku loģiskos ierakstos ir – un tos lieto apmainoties ar – plaukstu nospiedumu attēlu dati līdz ar fiksētiem un lietotāju definētiem teksta informācijas laukiem, kas atbilst digitalizētiem attēliem. Informācija par lietoto skenējuma izšķirtspēju, attēla lielumu un citiem parametriem vai piebildēm, kas vajadzīgas, lai apstrādātu ierakstus, ierakstā ir fiksēta kā marķēti lauki. Plaukstu nospiedumu attēlus, ko pārraida citām aģentūrām, apstrādās saņēmējas aģentūras, lai iegūtu vajadzīgo informāciju, kas vajadzīga salīdzināšanai.

Attēlu datus iegūst tieši no subjekta, izmantojot daktiloskopijas skenerus, vai arī no plaukstu nospiedumu kartēm vai citiem informācijas nesējiem, uz kā ir subjektu plaukstu nospiedumi.

Jebkura metode, ko izmanto, lai iegūtu plaukstu nospiedumu attēlus, spēj fiksēt katras rokas nospiedumu attēlu kompleksus. Kompleksā ietilpst rakstīšanai savilkta plauksta kā viens skenēts attēls, un visas, izplestas plaukstas laukums no plaukstas locītavas līdz pirkstu galiem – kā viens vai divi skenēti attēli. Ja izmanto divus attēlus, lai atveidotu visu plaukstu, zemākais attēls sākas no plaukstas locītavas un sniedzas līdz starppirkstu joslas augšai (trešā pirksta locītavai), un tajā ietver plaukstas tenāra un hipotenāra apgabalu. Augstākais attēls sākas no starppirkstu joslas apakšas un sniedzas līdz pirkstu galiem. Tas nodrošina pietiekamu pārklāšanos abiem attēliem, kas abi sniedzas tālāk par plaukstas starppirkstu joslu. Salāgojot papilārlīniju struktūru un detaļas, kas atrodas attēlu kopīgajā joslā, eksperts var droši konstatēt, ka abi attēli ir iegūti no vienas plaukstas.

Tā kā darbības ar plaukstu nospiedumiem var izmantot dažādām vajadzībām, tajās var būt viena vai vairākas unikālas attēla joslas, fiksētas no plaukstas vai rokas. Pilnīgā viena cilvēka plaukstas nospiedumu ierakstu kompleksā parasti ietilpst rakstīšanai savilkta katras rokas plauksta un izplestas(-u) plaukstas(-u) attēli. Loģiska attēla ieraksta marķētos laukos var būt tikai viens binārs lauks, viens 15. tipa ieraksts būs vajadzīgs katrai rakstīšanai savilktai plaukstai un viens vai divi 15. tipa ieraksti – katrai izplestai plaukstai. Tādējādi būs vajadzīgi četri līdz seši 15. tipa ieraksti, lai atveidotu subjekta plaukstu nospiedumus vienā parastā plaukstas nospiedumu darbībā.

8.1.   15. tipa loģisku datu lauki

Šajos punktos aprakstīti dati katrā 15. tipa loģisku ierakstu laukā.

15. tipa loģiskos ierakstus veic numurētos laukos. Ir prasība, lai pirmie divi ieraksta lauki būtu sakārtoti, un lauks ar attēla datiem ir ieraksta pēdējais fiziskais lauks. Katram 15. tipa ierakstu laukam 8. tabulā ir dots “nosacījumu kods” – obligāts “M” vai fakultatīvs “O”, lauka numurs, lauka nosaukums, zīmes tips, lauka lielums un sastopamības robežlielumi. Izmantojot trīsciparu lauka numuru, lielākais iespējamais lauka baitu skaits ir dots pēdējā ailē. Jo vairāk ciparu ir izmantots lauka numurā, jo vairāk palielinās arī lielākais iespējamais baitu skaits. Divos ierakstos “lauka lielums katrā konkrētā gadījumā” ir ietverti visi zīmju nošķīrēji, kas laukā ir izmantoti. “Lielākais iespējamais baitu skaits” ietver lauka numuru, informāciju un visus zīmju nošķīrējus, arī “GS” zīmi.

8.1.1.   15.001. lauks – loģiskā ieraksta garums (Logical record length – LEN)

Šajā obligātajā ASCII laukā ir 15. tipa loģiska ieraksta baitu kopskaits. 15.001. laukā ir dots ieraksta garums, ietverot katru ieraksta lauka zīmi visos laukos un informācijas nošķīrējus.

8.1.2.   15.002. lauks – attēla raksturotāja zīme (Image designation character – IDC)

Šo obligāto ASCII lauku izmanto, lai identificētu ieraksta plaukstas nospieduma attēlu. Šis IDC atbilst IDC, kas atrodas 1. tipa ieraksta datnes satura (CNT) laukā.

8.1.3.   15.003. lauks – nospieduma tips (Impression type – IMP)

Šajā obligātā viena baita ASCII laukā norāda, kā iegūta plaukstas nospieduma attēla informācija. Šajā laukā ieraksta attiecīgus kodus no 9. tabulas.

8.1.4.   15.004. lauks – aģentūra, kas ir ieguvusi attēlu (Source agency/ORI – SRC)

Šajā obligātajā ASCII laukā ir identificēta pārvalde vai organizācija, kas ieguvusi ierakstā doto sejas attēlu. Parastos apstākļos šajā laukā uzrāda izcelsmes aģentūras identifikatoru (Originating Agency Identifier – ORI) – kura aģentūra ir ieguvusi attēlu. Tajā ir divi informācijas elementi šādā formā – CC/aģentūra (CC/agency).

Pirmajā informācijas elementā ir Interpola izstrādātais valsts kods (Country Code), divas burtu vai ciparu zīmes. Otrs elements, aģentūra (agency), ir līdz 32 burtu vai ciparu zīmes garš brīvs teksts, un ar to identificē aģentūru.

8.1.5.   15.005. lauks – plaukstas nospieduma fiksācijas datums (Palmprint capture date – PCD)

Šajā obligātajā ASCII laukā ir datums, kad ir fiksēts plaukstas nospieduma attēls. Datumam no astoņiem cipariem ir šāda forma “CCYYMMDD”. Zīmes “CCYY” rāda gadu, kad fiksēts attēls, zīmes “MM” rāda mēnešus, un zīmes “DD” rāda mēneša dienas. Piemēram, 20000229 nozīmē 2000. gada 29. februāri. Pilnam datumam ir jābūt likumīgam datumam.

8.1.6.   15.006. lauks – horizontālu līniju garums (Horizontal line length – HLL)

Šajā obligātajā ASCII laukā ir vienā horizontālā pārraidītā attēla līnijā esošo pikseļu skaits.

8.1.7.   15.007. lauks – vertikālu līniju garums (Vertical line length – VLL)

Šajā obligātajā ASCII laukā ir pārraidītā attēla horizontālo līniju skaits.

8.1.8.   15.008. lauks – mēroga mērvienības (Scale units – SLC)

Šajā obligātajā ASCII laukā ir norādītas vienības, ko izmanto, lai aprakstītu attēla nolasīšanas frekvenci (pikseļu blīvumu). Cipars “1” šajā laukā rāda pikseļus collā, savukārt “2” rāda pikseļus centimetrā. Cipars “0” šajā laukā nozīmē, ka mērogs nav uzrādīts. Tādos gadījumos HPS/VPS dalījums dod pikseļu attiecības koeficientu.

8.1.9.   15.009. lauks – horizontāls pikseļu mērogs (Horizontal pixel scale – HPS)

Šajā obligātajā ASCII laukā konkrēti norāda horizontālā virzienā izmantoto pikseļu blīvumu veselos skaitļos, ja SLC ir ar “1” vai “2”. Ja tā nav, tas rāda pikseļu attiecības koeficienta horizontālo komponentu.

8.1.10.   15.010. lauks – vertikāls pikseļu mērogs (Vertical pixel scale – VPS)

Šajā obligātajā ASCII laukā konkrēti norāda vertikālā virzienā izmantoto pikseļu blīvumu veselos skaitļos, ja SLC ir ar “1” vai “2”. Ja tā nav, tas rāda pikseļu attiecības koeficienta vertikālo komponentu.

8. tabula. 15. tipa plaukstu nospiedumu attēli ar maināmu izšķirtspēju – ierakstu izkārtojums

Ident

Cond. code

Field Number

Field Name

Char type

Field size per occurrence

Occur count

Max byte count

min.

max.

min

max

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

1

1

10

PLP

M

15.013

PALMPRINT POSITION

N

2

3

1

1

10

RSV

 

15.014

15.019

RESERVED FOR FUTURE INCLUSION

COM

O

15.020

COMMENT

AN

2

128

0

1

128

RSV

 

15.021

15.199

RESERVED FOR FUTURE INCLUSION

UDF

O

15.200

15.998

USER-DEFINED FIELDS

DAT

M

15.999

IMAGE DATA

B

2

1

1


9. tabula. Plaukstu nospiedumu tipi

Description

Code

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. lauks – saspiešanas algoritms (Compression algorithm – CGA)

Šajā obligātajā ASCII laukā konkrēti norāda algoritmu, ko lieto, lai saspiestu melnbaltus tonālus attēlus. Ieraksts “NONE” šajā laukā norāda, ka dati ierakstā nav saspiesti. Attēliem, ko paredzēts saspiest, šajā laukā ir dota ieteicamā desmit pirkstu nospiedumu attēlu saspiešanas metode. Izmantojami saspiešanas kodi ir definēti 7. papildinājumā.

8.1.12.   15.012. lauks – biti pikselī (Bits per pixel – BPX)

Šajā obligātajā ASCII laukā ir bitu skaits, kas izmantots, lai izveidotu pikseli. Šajā laukā ir cipars “8” normālu melnbaltu tonālu attēlu vērtībām no “0” līdz “255”. Jebkurš ieraksts šajā laukā, lielāks par “8”, raksturo melnbaltu tonālu attēlu pikseli, kam ir palielināta precizitāte.

10. tabula. Plaukstu kodi, laukumi un lielumi

Palm Position

Palm code

Image area (mm2)

Width (mm)

Height (mm)

Unknown Palm

20

28 387

139,7

203,2

Right Full Palm

21

28 387

139,7

203,2

Right Writer s Palm

22

5 645

44,5

127,0

Left Full Palm

23

28 387

139,7

203,2

Left Writer s Palm

24

5 645

44,5

127,0

Right Lower Palm

25

19 516

139,7

139,7

Right Upper Palm

26

19 516

139,7

139,7

Left Lower Palm

27

19 516

139,7

139,7

Left Upper Palm

28

19 516

139,7

139,7

Right Other

29

28 387

139,7

203,2

Left Other

30

28 387

139,7

203,2

8.1.13.   15.013. lauks – plaukstas nospieduma vieta (Palmprint position – PLP)

Šajā obligātajā marķētajā laukā ir plaukstas nospieduma vieta, kas atbilst plaukstas nospieduma attēlam. Decimālciparu koda numuru, kas atbilst zināmai vai visiespējamākai plaukstas nospieduma vietai ņem no 10. tabulas un ieraksta kā pakārtotu ASCII lauku. 10. tabulā arī ir uzskaitīti lielākie iespējamie katra iespējamā plaukstas novietojuma nospieduma laukumi un izmēri.

8.1.14.   15.014–019. lauks – rezervēts turpmākām vajadzībām (Reserved for future definition – RSV)

Šie lauki ir atstāti tukši, lai tajos varētu nākotnē ierakstīt šā standarta pārstrādājumus. Neviens no šiem laukiem nav jālieto pašreizējā izstrādes līmenī. Ja kāds no šiem laukiem parādās, tas jāignorē.

8.1.15.   15.020. lauks – piebildes (Comment – COM)

Šo fakultatīvo lauku var izmantot piebildēm vai citai ASCII teksta informācijai par plaukstas nospieduma attēla datiem.

8.1.16.   15.021–199. lauks – rezervēts turpmākām vajadzībām (Reserved for future definition – RSV)

Šie lauki ir atstāti tukši, lai tajos varētu nākotnē ierakstīt šā standarta pārstrādājumus. Neviens no šiem laukiem nav jālieto pašreizējā izstrādes līmenī. Ja kāds no šiem laukiem parādās, tas jāignorē.

8.1.17.   15.200–998. lauks – lietotāju definēti lauki (User-defined fields – UDF)

Šos laukus var savām vajadzībām piemērot paši lietotāji, un tos lietos nākotnē. To lielumu un saturu definē paši lietotāji saskaņā ar saņēmēju aģentūru. Ja tādi parādās, tajos ir ASCII teksta informācija.

8.1.18.   15.999. lauks – attēlu dati (Image dataDAT)

Šajā laukā ir visi fiksēta plaukstas nospieduma attēla dati. Tam vienmēr piešķir lauka numuru 999, un tam jābūt pēdējam fiziskam laukam ierakstā. Piemēram, pēc “15.999:” ir doti attēla dati binārā formā. Katru nesaspiestu melnbaltu tonālu attēlu datu pikseli parasti kvantē par astoņiem bitiem (256 toņu pelēkumu) vienā baitā. Ja ieraksts BPX laukā 15.012 ir lielāks vai mazāks par 8, baitu skaits, kas vajadzīgs, lai fiksētu pikseli, būs citāds. Ja izmanto saspiešanu, pikseļu datus saspiež saskaņā ar CGA laukā norādīto saspiešanas paņēmienu.

8.2.   15. tips – plaukstu nospiedumu attēli ar maināmu izšķirtspēju – beigas

Konsekvences labad tūlīt pēc pēdējā datu baita 15.999. laukā lieto nošķīrēju “FS”, lai to nošķirtu no nākamā loģiskā ieraksta. Tāds nošķīrējs ir jāiekļauj 15. tipa lauka garuma ierakstā.

8.3.   Papildu 15. tipa plaukstu nospiedumu attēlu ieraksti ar maināmu izšķirtspēju

Datnē var iekļaut papildu 15. tipa ierakstus. Katram papildu plaukstas nospieduma attēlam ir vajadzīgs pilnīgs 15. tipa loģisks ieraksts līdz ar “FS” nošķīrēju.

11. tabula. Lielākais iespējamais kandidātu skaits, ko pieņem pārbaudei vienā datu pārsūtīšanas reizē

Type of AFIS Search

TP/TP

LT/TP

LP/PP

TP/UL

LT/UL

PP/ULP

LP/ULP

Maximum Number of Candidates

1

10

5

5

5

5

5

Meklējumu tipi:

 

TP/TP (ten-print against ten-print): desmit pirkstu nospiedumu salīdzināšana ar desmit pirkstu nospiedumiem

 

LT/TP (fingerprint latent against ten-print): latentu pirkstu nospiedumu salīdzināšana ar desmit pirkstu nospiedumiem

 

LP/PP (palmprint latent against palmprint): latentu plaukstu nospiedumu salīdzināšana ar plaukstu nospiedumiem

 

TP/UL (ten-print against unsolved fingerprint latent): desmit pirkstu nospiedumu salīdzināšana ar neatrisinātiem latentiem pirkstu nospiedumiem

 

LT/UL (fingerprint latent against unsolved fingerprint latent): latentu pirkstu nospiedumu salīdzināšana ar neatrisinātiem latentiem pirkstu nospiedumiem

 

PP/ULP (palmprint against unsolved palmprint latent): plaukstu nospiedumu salīdzināšana ar neatrisinātiem latentiem plaukstu nospiedumiem

 

LP/ULP (palmprint latent against unsolved palmprint latent): latentu plaukstu nospiedumu salīdzināšana ar neatrisinātiem latentiem plaukstu nospiedumiem

9.   2. nodaļas papildinājumi (daktiloskopijas datu apmaiņa)

9.1.   1. papildinājums – ASCII nošķīrēji kodi

ASCII

Position (2)

Description

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 a record field

US

1/15

Separates individual information items of the field or subfield

9.2.   2. papildinājums – Burtu vai ciparu pārbaudes zīmju aprēķini

TCN un TCR aprēķiniem (1.09. un 1.10. lauks):

Skaitli, kas atbilst pārbaudes zīmei, ģenerē, izmantojot šādu formulu:

(YY * 108 + SSSSSSSS) modulis 23

Kur YY un SSSSSSSS attiecīgi ir gada divu pēdējo ciparu skaitliskās vērtības un sērijas numurs.

Pārbaudes zīmi ģenerē no šeit turpmāk dotās salīdzinājumu tabulas.

CRO aprēķiniem (2.010. lauks)

Skaitli, kas atbilst pārbaudes zīmei, ģenerē, izmantojot šādu formulu:

(YY * 106 + NNNNNN) modulis 23

Kur YY un NNNNNN attiecīgi ir gada divu pēdējo ciparu skaitliskās vērtības un sērijas numurs.

Pārbaudes zīmi ģenerē no šeit turpmāk dotās salīdzinājumu tabulas.

Pārbaudes zīmju tabula

1-A

9-J

17-T

2-B

10-K

18-U

3-C

11-L

19-V

4-D

12-M

20-W

5-E

13-N

21-X

6-F

14-P

22-Y

7-G

15-Q

0-Z

8-H

16-R

 

9.3.   3. papildinājums – Zīmju kodi

7 bitu ANSI kods savstarpējai informācijas apmaiņai

ASCII Character Set

+

0

1

2

3

4

5

6

7

8

9

30

 

 

 

!

#

$

%

&

'

40

(

)

*

+

,

-

.

/

0

1

50

2

3

4

5

6

7

8

9

:

;

60

<

=

>

?

@

A

B

C

D

E

70

F

G

H

I

J

K

L

M

N

O

80

P

Q

R

S

T

U

V

W

X

Y

90

Z

[

\

]

^

_

`

a

b

c

100

d

e

f

g

h

i

j

k

l

m

110

n

o

p

q

r

s

t

u

v

w

120

x

y

z

{

|

}

~

 

 

 

9.4.   4. papildinājums – Darbību kopsavilkums

1. tipa ieraksti (obligāti)

Identifier

Field Number

Field Name

CPS/PMS

SRE

ERR

LEN

1.001

Logical Record Length

M

M

M

VER

1.002

Version Number

M

M

M

CNT

1.003

File Content

M

M

M

TOT

1.004

Type of Transaction

M

M

M

DAT

1.005

Date

M

M

M

PRY

1.006

Priority

M

M

M

DAI

1.007

Destination Agency

M

M

M

ORI

1.008

Originating Agency

M

M

M

TCN

1.009

Transaction Control Number

M

M

M

TCR

1.010

Transaction Control Reference

C

M

M

NSR

1.011

Native Scanning Resolution

M

M

M

NTR

1.012

Nominal Transmitting Resolution

M

M

M

DOM

1.013

Domain name

M

M

M

GMT

1.014

Greenwich mean time

M

M

M

Nosacījumu ailē:

O = fakultatīvi (optional); M = obligāti (mandatory); C = ar nosacījumu (conditional), ka darbība ir atbilde attēla ieguvējai aģentūrai.

2. tipa ieraksti (obligāti)

Identifier

Field Number

Field Name

CPS/PMS

MPS/MMS

SRE

ERR

LEN

2.001

Logical Record Length

M

M

M

M

IDC

2.002

Image Designation Character

M

M

M

M

SYS

2.003

System Information

M

M

M

M

CNO

2.007

Case Number

M

C

SQN

2.008

Sequence Number

C

C

MID

2.009

Latent Identifier

C

C

CRN

2.010

Criminal Reference Number

M

C

MN1

2.012

Miscellaneous Identification Number

C

C

MN2

2.013

Miscellaneous Identification Number

C

C

MN3

2.014

Miscellaneous Identification Number

C

C

MN4

2.015

Miscellaneous Identification Number

C

C

INF

2.063

Additional Information

O

O

O

O

RLS

2.064

Respondents List

M

ERM

2.074

Status/Error Message Field

M

ENC

2.320

Expected Number of Candidates

M

M

Nosacījumu ailē:

O = fakultatīvi (optional); M = obligāti (mandatory); C = ar nosacījumu (conditional), ka dati ir pieejami,

*

=

ja datu pārraide saskan ar attiecīgās valsts tiesībām (uz ko neattiecas Lēmums 2008/615/TI).

9.5.   5. papildinājums – 1. tipa ierakstu definīcijas

Identifier

Condition

Field Number

Field Name

Character Type

Example Data

LEN

M

1.001

Logical Record Length

N

1.001:230{GS}

VER

M

1.002

Version Number

N

1.002:0300{GS}

CNT

M

1.003

File Content

N

1.003:1{US}15{RS}2{US}00{RS}4{US}01{RS}4{US}02{RS}4{US}03{RS}4{US}04{RS}4{US}05{RS}4{US}06{RS}4{US}07{RS}4{US}08{RS}4{US}09{RS}4{US}10{RS}4{US}11{RS}4{US}12{RS}4{US}13{RS}4{US}14{GS}

TOT

M

1.004

Type of Transaction

A

1.004:CPS{GS}

DAT

M

1.005

Date

N

1.005:20050101{GS}

PRY

M

1.006

Priority

N

1.006:4{GS}

DAI

M

1.007

Destination Agency

1*

1.007:DE/BKA{GS}

ORI

M

1.008

Originating Agency

1*

1.008:NL/NAFIS{GS}

TCN

M

1.009

Transaction Control Number

AN

1.009:0200000004F{GS}

TCR

C

1.010

Transaction Control Reference

AN

1.010:0200000004F{GS}

NSR

M

1.011

Native Scanning Resolution

AN

1.011:19.68{GS}

NTR

M

1.012

Nominal Transmitting Resolution

AN

1.012:19.68{GS}

DOM

M

1.013

Domain Name

AN

1.013: INT-I{US}4.22{GS}

GMT

M

1.014

Greenwich Mean Time

AN

1.014:20050101125959Z

Nosacījumu ailē: O = fakultatīvi (optional); M = obligāti (mandatory); C = ar nosacījumiem (conditional).

Zīmju tipa ailē: A = burtu; N = ciparu; B = bināri.

1* pieļaujamās aģentūras nosaukuma zīmes ir [“0..9”, “A..Z”, “a..z”, “_”, ”.”, ““, “-”].

9.6.   6. papildinājums – 2. tipa ierakstu definīcijas

A.6.1. tabula. CPS un PMS darbības

Identifier

Condition

Field Number

Field Name

Character Type

Example Data

LEN

M

2.001

Logical Record Length

N

2.001:909{GS}

IDC

M

2.002

Image Designation Character

N

2.002:00{GS}

SYS

M

2.003

System Information

N

2.003:0422{GS}

CRN

M

2.010

Criminal Reference Number

AN

2.010:DE/E999999999{GS}

INF

O

2.063

Additional Information

1*

2.063:Additional Information 123{GS}

ENC

M

2.320

Expected Number of Candidates

N

2.320:1{GS}


A.6.2. tabula. SRE darbības

Identifier

Condition

Field Number

Field Name

Character Type

Example Data

LEN

M

2.001

Logical Record Length

N

2.001:909{GS}

IDC

M

2.002

Image Designation Character

N

2.002:00{GS}

SYS

M

2.003

System Information

N

2.003:0422{GS}

CRN

C

2.010

Criminal Reference Number

AN

2.010:NL/2222222222{GS}

MN1

C

2.012

Miscellaneous Identification Number

AN

2.012:E999999999{GS}

MN2

C

2.013

Miscellaneous Identification Number

AN

2.013:E999999999{GS}

MN3

C

2.014

Miscellaneous Identification Number

N

2.014:0001{GS}

MN4

C

2.015

Miscellaneous Identification Number

A

2.015:A{GS}

INF

O

2.063

Additional Information

1*

2.063:Additional Information 123{GS}

RLS

M

2.064

Respondents List

AN

2.064:CPS{RS}I{RS}001/001{RS}999999{GS}


A.6.3. tabula. ERR darbības

Identifier

Condition

Field Number

Field Name

Character Type

Example Data

LEN

M

2.001

Logical Record Length

N

2.001:909{GS}

IDC

M

2.002

Image Designation Character

N

2.002:00{GS}

SYS

M

2.003

System Information

N

2.003:0422{GS}

MN1

M

2.012

Miscellaneous Identification Number

AN

2.012:E999999999{GS}

MN2

C

2.013

Miscellaneous Identification Number

AN

2.013:E999999999{GS}

MN3

C

2.014

Miscellaneous Identification Number

N

2.014:0001{GS}

MN4

C

2.015

Miscellaneous Identification Number

A

2.015:A{GS}

INF

O

2.063

Additional Information

1*

2.063:Additional Information 123{GS}

ERM

M

2.074

Status/Error Message Field

AN

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


A.6.4. tabula. MPS un MMS darbības

Identifier

Condition

Field Number

Field Name

Character Type

Example Data

LEN

M

2.001

Logical Record Length

N

2.001:909{GS}

IDC

M

2.002

Image Designation Character

N

2.002:00{GS}

SYS

M

2.003

System Information

N

2.003:0422{GS}

CNO

M

2.007

Case Number

AN

2.007:E999999999{GS}

SQN

C

2.008

Sequence Number

N

2.008:0001{GS}

MID

C

2.009

Latent Identifier

A

2.009:A{GS}

INF

O

2.063

Additional Information

1*

2.063:Additional Information 123{GS}

ENC

M

2.320

Expected Number of Candidates

N

2.320:1{GS}

Nosacījumu ailē: O = fakultatīvi (optional); M = obligāti (mandatory); C = ar nosacījumiem (conditional).

Zīmju tipa ailē: A = burtu; N = ciparu; B = bināri.

1* pieļaujamās zīmes ir [“0..9”, “A..Z”, “a..z”, “_”,“.”, ““, “-”].

9.7.   7. papildinājums – Melnbaltu tonālu attēlu saspiešanas kodi

Saspiešanas kodi

Compression

Value

Remarks

Wavelet Scalar Quantization Grayscale Fingerprint Image Compression Specification

IAFIS-IC-0010(V3), dated December 19, 1997

WSQ

Algorithm to be used for the compression of grayscale images in Type-4, Type-7 and Type-13 to Type-15 records. Shall not be used for resolutions > 500 dpi.

JPEG 2000

[ISO 15444/ITU T.800]

J2K

To be used for lossy and losslessly compression of grayscale images in Type-13 to Type-15 records. Strongly recommended for resolutions > 500 dpi

9.8.   8. papildinājums – Sūtījumu parametri

Lai uzlabotu sūtījumu saņēmēju iekšējo darba plūsmu, PRUEM darbībās ir jāieraksta tās dalībvalsts kods (country code – CC), kura ir sūtījusi ziņu, un darbības tips (TOT, 1.004. lauks).

Forma – CC/darbības tips

Piemēram, “DE/CPS”.

Sūtījuma satura lauks var būt tukšs.

3. NODAĻA. Transportlīdzekļu reģistrācijas datu apmaiņa

1.   Kopējs datu kopums automatizētai transportlīdzekļu reģistrācijas datu meklēšanai

1.1.   Definīcijas

Lēmuma 16. panta 4. punktā izklāstīto obligāto un fakultatīvo datu elementu definīcijas ir šādas:

Obligāts (M – mandatory):

Šie datu elementi ir jādara zināmi, ja šāda informācija ir pieejama dalībvalsts reģistrā. Tādējādi ir obligāti jāapmainās ar informāciju, ja tāda ir pieejama.

Fakultatīvs (O – optional):

Šos datu elementus var darīt zināmus, ja šāda informācija ir pieejama dalībvalsts reģistrā. Tādējādi nav obligāti apmainīties ar informāciju, pat ja tāda ir pieejama.

Katram datu kopuma elementam dod norādi (Y), ja šis elements ir īpaši apzināts kā tāds, kas ir nozīmīgs saistībā ar Lēmumu 2008/615/TI.

1.2.   Transportlīdzekļa īpašnieka vai turētāja meklēšana

1.2.1.   Meklēšanas parametri

Ir divi dažādi paņēmieni, kā veikt nākamajā punktā minētās informācijas meklēšanu:

izmantojot šasijas numuru (VIN), atsauces datumu un laiku (fakultatīvs),

izmantojot numura zīmi reģistrācijas numurā, šasijas numuru (VIN) (fakultatīvs), atsauces datumu un laiku (fakultatīvs).

Izmantojot šos meklēšanas kritērijus, var atrast informāciju par vienu vai dažkārt vairākiem transportlīdzekļiem. Ja ir jāsniedz informācija tikai par vienu transportlīdzekli, tad visus datus nosūta vienā atbildē. Ja ir atrasts vairāk nekā viens transportlīdzeklis, pieprasījuma saņēmēja dalībvalsts pati var izlemt, kurus datus nosūtīt; vai būtu jānosūta visi dati vai tikai dati, kas dotu iespēju sīkāk ierobežot meklēšanu (piemēram, jo ņem vērā personas datu aizsardzību vai efektivitātes apsvērumus).

1.2.2.1. punktā ir uzskaitīti dati, kas vajadzīgi, lai sīkāk ierobežotu meklēšanas kritērijus. 1.2.2.2. punktā ir aprakstīts viss informācijas datu kopums.

Ja meklēšanu veic, izmantojot šasijas numuru, atsauces datumu un laiku, to var veikt vienā vai visās dalībvalstīs, kas ir pieslēgušās sistēmai.

Ja meklēšanu veic, izmantojot apliecības numuru, atsauces datumu un laiku, to var veikt vienā konkrētā dalībvalstī.

Parasti, lai veiktu meklēšanu, izmanto faktisku datumu un laiku, tomēr to ir iespējams veikt izmantojot agrāku atsauces datumu un laiku. Ja meklēšanu veic, izmantojot agrāku atsauces datumu un laiku un attiecīgās dalībvalsts reģistrā šī senākā informācija nav pieejama, jo šāda informācija nav reģistrēta, faktisko informāciju var nosūtīt atpakaļ ar norādi, ka tā ir faktiska informācija.

1.2.2.   Datu kopa

1.2.2.1.

Sīkākai meklēšanas kritēriju ierobežošanai nosūtāmi dati

Item

M/O (3)

Remarks

Prüm Y/N (4)

Data relating to vehicles

 

 

 

Licence number

M

 

Y

Chassis number/VIN

M

 

Y

Country of registration

M

 

Y

Make

M

(D.1) (5) e.g. Ford, Opel, Renault etc.

Y

Commercial type of the vehicle

M

(D.3) e.g. Focus, Astra, Megane

Y

EU Category Code

M

J) mopeds, motorbikes, cars etc.

Y

1.2.2.2.

Pilnīgs datu kopums

Item

M/O (6)

Remarks

Prüm Y/N

Data relating to holders of the vehicle

 

(C.1) (7) The data refer to the holder of the specific registration certificate.

 

Registration holders’ (company) name

M

(C.1.1.)

separate fields will be used for surname, infixes, titles etc.,

and

the name in printable format will be communicated

Y

First name

M

(C.1.2)

separate fields for first name(s) and initials will be used,

and

the name in printable format will be communicated

Y

Address

M

(C.1.3)

separate fields will be used for Street, House number and Annex, Zip code, Place of residence, Country of residence etc.,

and

the Address in printable format will be communicated

Y

Gender

M

Male, female

Y

Date of birth

M

 

Y

Legal entity

M

individual, association, company, firm etc.

Y

Place of Birth

O

 

Y

ID Number

O

An identifier that uniquely identifies the person or the company.

N

Type of ID Number

O

The type of ID Number (e.g. passport number).

N

Start date holdership

O

Start date of the holdership of the car. This date will often be the same as printed under (I) on the registration certificate of the vehicle.

N

End date holdership

O

End data of the holdership of the car.

N

Type of holder

O

If there is no owner of the vehicle (C.2) the reference to the fact that the holder of the registration certificate:

is the vehicle owner

is not the vehicle owner

is not identified by the registration certificate as being the vehicle owner

N

Data relating to owners of the vehicle

 

(C.2)

 

Owners’ (company) name

M

(C.2.1)

Y

First name

M

(C.2.2)

Y

Address

M

(C.2.3)

Y

Gender

M

male, female

Y

Date of birth

M

 

Y

Legal entity

M

individual, association, company, firm etc.

Y

Place of Birth

O

 

Y

ID Number

O

An identifier that uniquely identifies the person or the company.

N

Type of ID Number

O

The type of ID Number (e.g. passport number).

N

Start date ownership

O

Start date of the ownership of the car.

N

End date ownership

O

End data of the ownership of the car.

N

Data relating to vehicles

 

 

 

Licence number

M

 

Y

Chassis number/VIN

M

 

Y

Country of registration

M

 

Y

Make

M

(D.1) e.g. Ford, Opel, Renault etc.

Y

Commercial type of the vehicle

M

(D.3) e.g. Focus, Astra, Megane

Y

Nature of the vehicle/EU Category Code

M

(J) mopeds, motorbikes, cars etc.

Y

Date of first registration

M

(B) date of first registration of the vehicle somewhere in the world

Y

Start date (actual) registration

M

Date of the registration to which the specific certificate of the vehicle refers

Y

End date registration

M

(I) End data of the registration to which the specific certificate of the vehicle refers. It is possible this date indicates the period of validity as printed on the document if not unlimited (document abbreviation = H).

Y

Status

M

scrapped, stolen, exported etc.

Y

Start date status

M

 

Y

End date status

O

 

N

kW

O

(P.2)

Y

Capacity

O

(P.1)

Y

Type of licence number

O

Regular, transito etc.

Y

Vehicle document id 1

O

The first unique document ID as printed on the vehicle document

Y

Vehicle document id 2 (8)

O

A second document ID as printed on the vehicle document.

Y

Data relating to insurances

 

 

 

Insurance company name

O

 

Y

Begin date insurance

O

 

Y

End date insurance

O

 

Y

Address

O

 

Y

Insurance number

O

 

Y

ID Number

O

An identifier that uniquely identifies the company.

N

Type of ID Number

O

The type of ID Number (e.g. number of the Chamber of Commerce)

N

2.   Datu drošība

2.1.   Pārskats

Eucaris lietojumprogrammatūra nodrošina drošu komunikāciju ar citām dalībvalstīm un, izmantojot XML, nodrošina komunikāciju ar dalībvalstu uzstādītajām aizmugursistēmām. Atbildes sūtījumu dalībvalstis nosūta tieši saņēmējam. Dalībvalsts datu centrs ir savienots ar ES TESTA tīklu.

XML sūtījumus sūta šifrēti. Šo sūtījumu šifrēšanā izmanto SSL tehniku. Aizmugursistēmai sūta parasta teksta XML sūtījumus, jo lietojumprogrammas un aizmugursistēmas sakariem jābūt aizsargātiem.

Ir paredzēta klientu lietojumprogramma (client application), ko var lietot dalībvalstī, lai veiktu meklēšanu šīs valsts reģistrā vai citu dalībvalstu reģistros. Klientus identificēs, izmantojot lietotājvārdu un paroli vai klienta sertifikātu. Savienojumus ar lietotājiem var šifrēt, bet tā ir katras dalībvalsts individuāla atbildība.

2.2.   Ar sūtījumu apmaiņu saistītas drošības iezīmes

Drošības sistēmas pamatā ir HTTPS un XML paraksta kombinācija. Tas ļauj izmantot XML parakstu, lai parakstītu visus serverim nosūtītos sūtījumus, turklāt tā var autentificēt sūtījuma autoru, pārbaudot parakstu. Vienas puses SSL (1-sided SSL) drošības standartu (tikai servera sertifikāts) izmanto, lai aizsargātu sūtījuma konfidencialitāti un integritāti un lai nodrošinātu aizsardzību pret dzēšanas, atbildes un nesankcionētas datu iekļaušanas uzbrukumiem. Tā vietā, lai attīstītu īpašu programmatūru, kas nodrošinātu divu pušu SSL standartu, izmanto XML parakstu. XML paraksta izmantojums ir tuvāks tīkla pakalpojumu standartam nekā divu pušu SSL, un tāpēc tā lietojums ir stratēģiski izdevīgāks.

XML parakstu var īstenot dažādi, bet ir izvēlēta pieeja, ka XML parakstu izmanto kā tīkla pakalpojumu drošības daļu (Web Services Security – WSS). WSS nosaka, kā izmantot XML parakstu. Tā kā WSS pamatā ir SOAP standarts, būtu loģiski pēc iespējas rīkoties saskaņā ar SOAP standartu.

2.3.   Ar sūtījumu apmaiņu nesaistītas drošības iezīmes

2.3.1.   Lietotāju autentifikācija

Eucaris tīkla lietojumprogrammas lietotāji autentificējas, izmantojot lietotājvārdu un paroli. Tā kā izmanto Windows standarta autentifikāciju, dalībvalstis vajadzības gadījumā lietotāju autentifikācijas drošību var paaugstināt, izmantojot klientu sertifikāciju.

2.3.2.   Lietotāju lomas

Eucaris lietojumprogramma veic dažādas lietotāju lomas. Katram pakalpojumu kopumam ir sava autorizācija. Piemēram, “Eucaris līguma funkcionalitātes” (konkrētiem) lietotājiem var nebūt pieeja “Prīmes funkcionalitātei”. Administratora funkcijas ir nošķirtas no regulāru tiešo lietotāju funkcijām.

2.3.3.   Reģistrēšana (logging) un sūtījumu apmaiņas trasēšana (tracing)

Eucaris lietojumprogramma veicina visu sūtījumu tipu reģistrēšanu (logging). Administratora funkcijas dod iespēju valstu administratoriem noteikt, kuri sūtījumi ir reģistrēti: tiešo lietotāju pieprasījumi, no citām dalībvalstīm saņemti pieprasījumi, valstu reģistru sniegta informācija u. c.

Lietojumprogrammu var konfigurēt, lai tā, veicot šo reģistrēšanu, izmantotu iekšēju datubāzi vai ārēju (Oracle) datubāzi. Lēmumi par to, kuri sūtījumi ir jāreģistrē, nepārprotami ir atkarīgi no citām uzstādīto sistēmu (legacy systems) reģistrācijas iekārtām un to klientu lietojumprogrammām, kas ir pieslēgušies.

Katra sūtījuma galvenē ir informācija par pieprasījuma iesniedzēju dalībvalsti, par šīs dalībvalsts pieprasījuma iesniedzēju organizāciju un iesaistītiem lietotājiem. Ir norādīts arī pieprasījuma iemesls.

Izmantojot kombinētu reģistrēšanu (combined logging) pieprasījuma iesniedzējā un atbildes sniedzējā dalībvalstī, ir iespējams veikt pilnīgu jebkura sūtījuma trasēšanu (piemēram, ja to lūdz attiecīgais iesaistītais pilsonis).

Reģistrēšanu konfigurē, izmantojot Eucaris tīkla klientu (web client) (izvēlņu administrēšana, reģistrēšanas konfigurācija). Reģistrēšanas funkcionalitāti pilda pamatsistēma (Core System). Kad ir aktivizēta reģistrēšanas funkcija, visu sūtījumu (galveni un pamattekstu) saglabā vienā reģistrācijas ierakstā (logging record). Katram definētam pakalpojumam un katram sūtījumu tipam, kas nonāk pamatsistēmā, var iestatīt reģistrācijas līmeni (logging level).

Reģistrācijas līmeņi

Ir iespējami šādi reģistrācijas līmeņi (logging levels):

Privāts – sūtījums ir reģistrēts: reģistrācija NAV pieejama konkrētam reģistrācijas pakalpojumam (extract logging service), tomēr tā ir pieejama valsts līmenī, lai veiktu revīziju un risinātu problēmas.

Nav (none) – sūtījums nav reģistrēts vispār.

Sūtījuma tipi

Dalībvalstu savstarpēja informācijas apmaiņa notiek ar vairākiem sūtījumiem, kuri shematiski ir attēloti zemāk dotajā attēlā.

Iespējamie sūtījumu tipi (kas attēlā parādīti ar dalībvalsts X Eucaris pamatsistēmu) ir šādi:

1.

Request to Core System_Request message by Client.

2.

Request to Other Member State_Request message by Core System of this Member State.

3.

Request to Core System of this Member State_Request message by Core System of other Member State.

4.

Request to Legacy Register_Request message by Core System.

5.

Request to Core System_Request message by Legacy Register.

6.

Response from Core System_Request message by Client.

7.

Response from Other Member State_Request message by Core System of this Member Stat.

8.

Response from Core System of this Member State_Request message by other Member State.

9.

Response from Legacy Register_Request message by Core System.

10.

Response from Core System_Request message by Legacy Register.

Attēlā parādīta šāda informācijas apmaiņa:

ar zilām bultām attēlots informācijas pieprasījums, ko dalībvalsts X sūta dalībvalstij Y. Šie pieprasījumi un atbildes attiecīgi sastāv no 1., 2., 7. un 6. sūtījumu tipa,

ar sarkanām bultām attēlots informācijas pieprasījums, ko dalībvalsts Z nosūta dalībvalstij X. Šie pieprasījumi un atbildes attiecīgi sastāv no 3., 4., 9. un 8. sūtījumu tipa,

ar zaļām bultām attēlots uzstādītā reģistra sūtīts informācijas pieprasījums tā pamatsistēmai (šajā datu plūsmā ir iekļauts arī mantotā reģistra klienta nosūtīts pieprasījums). Šādi pieprasījumi attiecīgi sastāv no 5. un 10. sūtījuma tipa.

Attēls. Reģistrācijā izmantotie sūtījumu tipi

Image

2.3.4.   Aparatūras drošības modulis (Hardware Security Module)

Aparatūras drošības moduli neizmanto.

Ar aparatūras drošības moduli (Hardware Security Module (HSM)) nodrošina labu aizsardzību atslēgai, ar ko paraksta sūtījumus un identificē serverus. Tas palielina vispārējo drošības līmeni, tomēr HSM moduļa pirkšanas un uzturēšanas izmaksas ir augstas, turklāt nav paredzētas prasības ieviest “FIPS 140-2” 2. vai 3. līmeņa HSM. Tā kā izmanto slēgtu tīklu, tas lielā mērā mazina apdraudējumu, tāpēc ir pieņemts lēmums sākotnēji neizmantot HSM. Ja HSM ir vajadzīgs, piemēram, lai iegūtu akreditāciju, to var pievienot arhitektūrai vēlāk.

3.   Datu apmaiņas tehniskie nosacījumi

3.1.   Vispārējs Eucaris lietojumprogrammas apraksts

3.1.1.   Pārskats

Eucaris lietojumprogramma savieno visas iesaistītās dalībvalstis vienotā tīklā, ar kā starpniecību jebkura dalībvalsts tieši sazinās ar citām dalībvalstīm. Lai notiktu saziņa, nav vajadzības izmantot centrālu elementu. Eucaris lietojumprogrammatūra garantē drošu komunikāciju ar citām dalībvalstīm un, izmantojot XML, nodrošina komunikāciju ar dalībvalstu uzstādīto aizmugursistēmu (back-end legacy system). Šī arhitektūra ir atainota šajā attēlā.

Image

Dalībvalstis ar sūtījumiem apmainās, tos nosūtot tieši saņēmējam. Dalībvalsts datu centrs ir savienots ar tīklu, ko izmanto sūtījumu apmaiņai (TESTA). Lai piekļūtu TESTA tīklam, dalībvalstis tajā ieslēdzas, izmantojot savu pieslēguma līniju (national gate). Lai pieslēgtos tīklam, izmanto ugunssienu, turklāt Eucaris lietojumprogrammu ugunssienai pievieno ar maršrutētāju. Atkarībā no izvēlētās sūtījumu aizsardzības vai nu maršrutētājs, vai Eucaris lietojumprogramma izmanto sertifikātu.

Ir paredzēta klientu lietojumprogramma, ko var lietot dalībvalstī, lai veiktu meklēšanu šīs valsts reģistrā, vai citu dalībvalstu reģistros. Klientu lietojumprogramma pieslēdzas Eucaris. Klientus identificēs, izmantojot lietotājvārdu un paroli vai klienta sertifikātu. Savienojumu ar lietotājiem ārējā organizācijā (piemēram, policijā) var šifrēt, bet tā ir katras dalībvalsts individuāla atbildība.

3.1.2.   Sistēmas darbības joma

Eucaris sistēmas darbības joma ir ierobežota no dalībvalstu reģistrācijas iestāžu savstarpējas informācijas apmaiņas procesu viedokļa un no informācijas pasniegšanas paņēmiena viedokļa. Procedūras un automatizēti procesi, kuros informāciju ir paredzēts izmantot, neietilpst sistēmas darbības jomā.

Dalībvalstis var vai nu izvēlēties Eucaris klienta funkcionalitāti, vai arī izveidot pašas savu pielāgotu klientu lietojumprogrammu. Šajā tabulā ir aprakstīts, kuri Eucaris sistēmas aspekti ir obligāti jāizmanto un/vai jāparedz un kurus var izmantot fakultatīvi, un/vai kurus var izmantot pēc dalībvalstu brīvas izvēles.

EUCARIS aspects

M/O (9)

Remark

Network concept

M

The concept is an “any-to-any” communication.

Physical network

M

TESTA

Core application

M

The core application of EUCARIS has to be used to connect to the other Member States. The following functionality is offered by the core:

Encrypting and signing of the messages

Checking of the identity of the sender

Authorization of Member States and local users

Routing of messages

Queuing of asynchronous messages if the recipient service is temporally unavailable

Multiple country inquiry functionality

Logging of the exchange of messages

Storage of incoming messages

Client application

O

In addition to the core application the EUCARIS II client application can be used by a Member State. When applicable, the core and client application are modified under auspices of the EUCARIS organisation.

Security concept

M

The concept is based on XML-signing by means of client certificates and SSL-encryption by means of service certificates.

Message specifications

M

Every Member State has to comply with the message specifications as set by the EUCARIS organisation and this Council Decision. The specifications can only be changed by the EUCARIS organisation in consultation with the Member States.

Operation and Support

M

The acceptance of new Member States or a new functionality is under auspices of the EUCARIS organisation. Monitoring and help desk functions are managed centrally by an appointed Member State.

3.2.   Funkcionālas prasības un nefunkcionālas prasības

3.2.1.   Vispārējas funkcijas

Šajā iedaļā vispārīgi ir aprakstītas galvenās vispārējās funkcijas.

Nr.

Apraksts

1.

Sistēma dod iespēju dalībvalstu reģistrācijas iestādēm interaktīvi apmainīties ar pieprasījuma un atbilžu sūtījumiem.

2.

Sistēmā ir iekļauta klientu lietojumprogramma, kas dod iespēju tiešiem lietotājiem nosūtīt savus pieprasījumus un sniegt atbildes informāciju manuālai apstrādei.

3.

Sistēma veicina informācijas izplatīšanas darbības, ļaujot dalībvalstij pieprasījumu nosūtīt visām pārējām dalībvalstīm. Saņemtās atbildes pamata lietojumprogramma (core application) apvieno vienā klienta lietojumprogrammai (client application) adresētā atbildes sūtījumā (šo funkcionalitāti sauc “vairāku valstu izziņa” (“Multiple Country Inquiry”)).

4.

Sistēma spēj apstrādāt dažādu tipu sūtījumus. Katram lietojuma pakalpojumam definē savas lietotāju lomas: autorizāciju, maršrutēšanu, parakstus un reģistrāciju.

5.

Sistēma dod iespēju dalībvalstīm apmainīties ar sūtījumu paketēm vai sūtījumiem, kuros ir liels skaits pieprasījumu vai atbilžu. Šo sūtījumu apstrāde notiek asinhroni.

6.

Sistēma uzkrāj asinhronos sūtījumus, ja saņēmēja dalībvalsts īslaicīgi nav pieejama, un garantē to nosūtīšanu, tiklīdz saņēmējs atkal ir pieejams.

7.

Sistēma uzglabā ienākošos asinhronos sūtījumus līdz brīdim, kad tos var apstrādāt.

8.

Sistēma dod piekļuvi tikai citu valstu Eucaris lietojumiem, nevis atsevišķām organizācijām šajās citās dalībvalstīs, proti, katra reģistrācijas iestāde darbojas kā vienīgā pieslēguma līnija starp attiecīgās valsts tiešiem lietotājiem un attiecīgām citu valstu iestādēm.

9.

Vienā Eucaris serverī ir iespējams definēt dažādu dalībvalstu lietotājus un autorizēt tos saskaņā ar attiecīgās valsts piekļuves tiesībām.

10.

Sūtījumos ir iekļauta informācija par pieprasījuma iesniedzēju dalībvalsti, organizāciju un tiešo lietotāju.

11.

Ar šo sistēmu veicina dažādu dalībvalstu un pamata lietojumprogrammas un valstu reģistrācijas sistēmu starpā sūtīto sūtījumu apmaiņas reģistrēšanu (logging).

12.

Sistēma ļauj veidot īpašu sekretariātu, kas ir organizācija vai dalībvalsts, kas ir nepārprotami deleģēta veikt šo uzdevumu – apkopot reģistrēto informāciju (logged information) par visu iesaistīto dalībvalstu nosūtītajiem un saņemtajiem sūtījumiem, lai izstrādātu statistikas ziņojumus.

13.

Katra dalībvalsts pati norāda, kāda reģistrētā informācija ir darīta pieejama sekretariātam un kāda informācija ir “privāta”.

14.

Šī sistēma ļauj valstu administratoriem katrā dalībvalstī apkopot izmantošanas statistiku.

15.

Sistēma dod iespēju, izpildot dažus vienkāršus administratīvus uzdevumus, pievienoties jaunām dalībvalstīm.

3.2.2.   Izmantojamība

Nr.

Apraksts

16.

Sistēma nodrošina saskarni, lai veiktu automatizētu sūtījumu apstrādi, izmantojot aizmugursistēmu un uzstādītu sistēmas (back-end systems/legacy), un dod iespēju integrēt lietotāja saskarni šajās sistēmās (pielāgota lietotāja saskarne (customised user-interface).

17.

Sistēmu ir viegli apgūt, tā ir viegli saprotama, un tajā ir iekļauti palīdzības skaidrojumi.

18.

Sistēma ir dokumentēta, lai dalībvalstīm palīdzētu nodrošināt integrāciju, sistēmas darbību un turpmāku uzturēšanu (piemēram, uzziņu rokasgrāmatas, funkcionāla un tehniska dokumentācija, darbības instrukcija...).

19.

Lietotāja saskarne ir vairākās valodās un dod iespēju tiešam lietotājam izvēlēties lietojuma valodu.

20.

Lietotāja saskarnē ir paredzēta iespēja, lai vietējais administrators varētu valsts valodā iztulkot gan redzamo, gan kodēto informāciju.

3.2.3.   Uzticamība

Nr.

Apraksts

21.

Sistēma ir izveidota kā droša un darbā uzticama sistēma, kas pieļauj zināmas operatoru kļūdas un kas atkopsies (clean recovery) pēc elektroenerģijas padeves pārtraukumiem vai citiem traucējumiem. Ir jābūt iespējamam restartēt sistēmu, izvairoties no datu zuduma vai pieļaujot tikai minimālu datu zudumu.

22.

Sistēmas darbības rezultātiem ir jābūt stabiliem un atkārtojamiem.

23.

Sistēma ir izstrādāta tā, lai tās darbība būtu uzticama. Ir iespējams īstenot sistēmu konfigurācijā, kas katrā divpusējā komunikācijā garantētu 98 % pieejamību (izmantojot papildelementus (redundancy), dublējuma serverus (back-up servers) u. c.).

24.

Ir iespējams izmantot sistēmas daļu pat tad, ja daži komponenti nedarbojas (ja dalībvalsts C nav pieejama, dalībvalstis A un B var turpināt uzturēt sakarus). Vajadzētu pēc iespējas novērst atsevišķu informācijas ķēdes punktu kļūdainu darbību.

25.

Atkopšanās laikam pēc nopietnas sistēmas kļūmes vajadzētu būt mazākam nekā viena diena. Vajadzētu pēc iespējas samazināt laiku, kad sistēma nedarbojas, izmantojot tālvadību, ko, piemēram, veiktu no centrāla sistēmas kontrolpunkta (central service desk).

3.2.4.   Darbība

Nr.

Apraksts

26.

Sistēmu var izmantot cauru diennakti septiņas dienas nedēļā. Šīs darbības laika (time-window 24x7) prasības ir jāievēro arī dalībvalstu uzstādītām sistēmām.

27.

Sistēma ātri reaģē uz lietotāja prasījumiem neatkarīgi no fonā risinātiem uzdevumiem. Tāda prasība ir izvirzīta arī pušu uzstādītām sistēmām, lai nodrošinātu pieņemamu atbildes laiku. Par pieņemamu uzskata vispārēju atbildes laiku, kas vienam prasījumam nav ilgāks kā 10 sekundes.

28.

Sistēma ir izstrādāta tā, lai to varētu lietot vairāki lietotāji un lai fonā risināmie uzdevumi varētu turpināt darbību, kamēr lietotājs risina priekšplāna uzdevumus.

29.

Sistēma ir izstrādāta, lai tā būtu adaptīva un tā varētu tikt galā ar iespējamu sūtījumu skaita pieaugumu, ja sistēmai pievieno jaunu funkcionalitāti vai arī tai pievienojas jauna organizācija vai dalībvalsts.

3.2.5.   Drošība

Nr.

Apraksts

30.

Sistēma ir piemērota (proti, ir paredzēti atbilstīgi drošības pasākumi), lai varētu veikt apmaiņu ar sūtījumiem, kas satur personas datus (piemēram, transportlīdzekļu īpašnieki/turētāji), kuri ir klasificēti kā ES dati ar ierobežotu piekļuvi (EU restricted).

31.

Sistēmu uztur tā, lai novērstu neatļautu piekļuvi datiem.

32.

Sistēmā ir integrēta valstu tiešo lietotāju piekļuves tiesību un atļauju pārvaldības funkcija.

33.

Dalībvalstīm ir iespējams pārbaudīt sūtītāja identitāti (dalībvalsts mērogā), izmantojot XML parakstu.

34.

Dalībvalstīm ir skaidri jāautorizē citas dalībvalstis, lai tās lūgtu konkrētu informāciju.

35.

Sistēma lietojumprogrammas līmenī nodrošina pilnīgu drošības un šifrēšanas politiku, kas ir saskaņā ar šādās situācijās vajadzīgo drošības pakāpi. Informācijas pilnīgu aizsardzību un integritāti garantē XML paraksta un šifrēšanas izmantojums, ko veic ar SSL tunelēšanas (SSL-tunnelling) palīdzību.

36.

Jebkuru sūtījumu apmaiņu var izsekot, izmantojot reģistrēšanu (logging).

37.

Aizsardzību nodrošina pret informācijas dzēšanas uzbrukumiem (trešā puse dzēš sūtījumu) un atbildes vai datu iekļaušanas uzbrukumiem (trešā puse atbild vai iekļauj sūtījumu).

38.

Sistēma izmanto uzticamas trešās puses sertifikātu (Trusted Third Party – TTP).

39.

Sistēma var attiecībā uz katru dalībvalsti apstrādāt dažādus sertifikātus atkarībā no sūtījuma vai konkrētās darbības tipa.

40.

Lietojumprogrammas drošības pasākumi ir pietiekami, lai varētu izmantot neakreditētus tīklus.

41.

Sistēma spēj izmantot novatoriskus drošības risinājumus, piemēram, XML ugunssienu.

3.2.6.   Pielāgošanās spēja

Nr.

Apraksts

42.

Sistēma var apstrādāt jaunus sūtījumus, un to var papildināt ar jaunām funkcijām. Pielāgojumu izmaksas ir minimālas, jo lietojumprogrammas komponentus izstrādā centralizēti.

43.

Dalībvalstīm ir iespēja divpusēja izmantojuma vajadzībām definēt jaunu sūtījumu tipus. Visām dalībvalstīm nav izvirzītas prasības strādāt ar visiem sūtījumu tipiem.

3.2.7.   Atbalsts un uzturēšana

Nr.

Apraksts

44.

Sistēmā ir integrētas pārraudzības funkcijas, ko attiecībā uz dažādu dalībvalstu tīkliem un serveriem veic centrālais sistēmas kontrolpunkts un/vai operatori.

45.

Sistēma dod iespēju centrālajam sistēmas kontrolpunktam veikt tālvadību.

46.

Sistēmas funkcijas ļauj veikt problēmu analīzi.

47.

Sistēmai var pievienoties arī jaunas dalībvalstis.

48.

Lietojumprogrammu var viegli instalēt darbinieki, kuriem ir minimālas IT zināšanas un pieredze. Instalācijas procedūra ir maksimāli automatizēta.

49.

Sistēmā paredzētas pastāvīgas testēšanas un kontroles funkcijas.

50.

Tā kā sistēma ir veidota atbilstīgi tirgū pieejamiem standartiem, turklāt lietojumprogramma ir izstrādāta tā, lai centrālā sistēmas kontrolpunkta palīdzība būtu pēc iespējas mazāk vajadzīga, tad sistēmas apkopes un uzturēšanas gada izmaksas ir saglabātas iespējami zemā līmenī.

3.2.8.   Izstrādes prasības

Nr.

Apraksts

51.

Sistēma ir izstrādāta un dokumentēta, lai to varētu ekspluatēt daudzu gadu garumā.

52.

Sistēma ir izstrādāta, lai tās darbība būtu neatkarīga no tīkla pakalpojumu sniedzēja.

53.

Sistēma ir saderīga ar pašreizējo dalībvalstīs lietoto aparatūru un programmatūru un mijiedarbojas ar šīm reģistrācijas sistēmām, izmantojot atvērto standartu tīkla pakalpojumu tehnoloģijas (XML, XSD, SOAP, WSDL, HTTP(s), Web services, WSS, X.509 u. c.).

3.2.9.   Piemērojamie standarti

Nr.

Apraksts

54.

Sistēma ir saskaņā ar datu aizsardzības standartiem, kas izklāstīti Regulā (EK) Nr. 45/2001 (21., 22. un 23. pantā) un Direktīvā 95/46/EK.

55.

Sistēma ir saderīga ar IDA standartiem.

56.

Sistēma darbojas ar UTF8.

4. NODAĻA. Izvērtējums

1.   Izvērtējuma procedūra saskaņā ar 20. pantu (Lēmuma gatavošana saskaņā ar Lēmuma 2008/615/TI 25. panta 2. punktu)

1.1.   Anketa

Attiecīgā Padomes darba grupa izstrādā anketu par katru no Lēmuma 2008/615/TI 2. nodaļā izklāstītajiem automatizētiem datu apmaiņas paņēmieniem.

Tiklīdz dalībvalsts uzskata, ka tā izpilda priekšnosacījumus, lai veiktu attiecīgās kategorijas datu apmaiņu, tā izpilda attiecīgo anketu.

1.2.   Izmēģinājumi

Lai izvērtētu anketas rezultātus, dalībvalsts, kas vēlas sākt datu apmaiņu, veic izmēģinājumus kopā ar vienu vai vairākām citām dalībvalstīm, kuras saskaņā ar Padomes lēmumu jau piedalās datu apmaiņā. Izmēģinājumus veic vai nu īsi pirms, vai īsi pēc izvērtējuma inspekcijas.

Izmēģinājumu apstākļus un mehānismus noteiks attiecīgā Padomes darba grupa, un tos veiks saskaņā ar iepriekš panāktu konkrētu vienošanos ar attiecīgo dalībvalsti. Par izmēģinājumu praktiskiem aspektiem lēmumu pieņems dalībvalstis, kas tajās piedalās.

1.3.   Izvērtējuma inspekcija

Lai izvērtētu anketas rezultātus, dalībvalstīs, kas vēlas sākt piedalīties datu apmaiņā, rīkos izvērtējuma inspekcijas.

Šo inspekciju apstākļus un mehānismus noteiks attiecīgā Padomes darba grupa, un tās rīkos saskaņā ar konkrēto vienošanos, kas pirms tam panākta starp attiecīgo dalībvalsti un izvērtējuma grupu. Attiecīgā dalībvalsts dos iespēju izvērtējuma grupai pārbaudīt automatizēto datu apmaiņu datu kategorijā vai kategorijās, kuras paredzēts izvērtēt, jo īpaši saskaņā ar izvērtējuma grupas pieprasījumiem organizējot inspekcijas norises programmu.

Viena mēneša laikā izvērtējuma grupa izstrādā izvērtējuma inspekcijas ziņojumu, ko tā nosūta attiecīgai dalībvalstij, lai tā to komentētu. Vajadzības gadījumā izvērtējuma grupa pārskatīs šo ziņojumu, pamatojoties uz dalībvalsts sniegtajiem komentāriem.

Izvērtējuma grupā ir ne vairāk kā trīs eksperti, ko izraudzījušās dalībvalstis, kas piedalās automatizētā datu apmaiņā ar tām datu kategorijām, ko paredzēts izvērtēt, turklāt šiem ekspertiem ir darba pieredze ar attiecīgo datu kategoriju, viņiem ir atbilstīga valsts izsniegta drošības pielaide darbam ar šiem jautājumiem, un viņi pauduši vēlmi piedalīties vismaz vienā izvērtējuma inspekcijā citā dalībvalstī. Komisiju aicinās piedalīties izvērtējuma grupā novērotāja statusā.

Izvērtējuma grupas dalībnieki ievēros slepenības statusu informācijai, kas viņiem būs kļuvusi zināma, pildot darba uzdevumus.

1.4.   Ziņojums Padomei

Padomei iesniegs vispārēju izvērtējuma ziņojumu, kurā apkopoti anketu, izvērtējuma inspekciju un izmēģinājumu rezultāti, lai tā pieņemtu lēmumu saskaņā ar Lēmuma 2008/615/TI 25. panta 2. punktu.

2.   Saskaņā ar 21. pantu veiktā izvērtēšanas procedūra

2.1.   Statistika un ziņojumi

Katra dalībvalsts apkopo statistiku par automatizētas datu apmaiņas rezultātiem. Lai nodrošinātu iespēju statistiku salīdzināt, attiecīgā Padomes darba grupa izstrādās statistikas modeli.

Statistikas datus reizi gadā pārsūtīs Komisijai un Ģenerālsekretariātam, kas sagatavos apkopotu pārskatu par iepriekšējo gadu.

Turklāt dalībvalstīm lūgs regulāri, ne biežāk kā reizi gadā iesniegt papildu informāciju par automatizētās datu apmaiņas administratīvu, tehnisku un finansiālu īstenošanu, lai informāciju analizētu un izmantotu procesa uzlabošanai. Pamatojoties uz tādu informāciju, izstrādās ziņojumu, ko iesniegt Padomei.

2.2.   Pārskatīšana

Padome izskata šeit aprakstītos izvērtēšanas mehānismus pienācīgā laikā un vajadzības gadījumā tos pārskata.

3.    Ekspertu sanāksmes

Attiecīgajā Padomes darba grupā eksperti regulāri rīkos sanāksmes, lai organizētu un īstenotu minētās izvērtēšanas procedūras, kā arī lai dalītos pieredzē un pārrunātu iespējamus uzlabojumus. Vajadzības gadījumā šo ekspertu pārrunu rezultātus integrēs 2.1. punktā minētajā ziņojumā.


(1)  “Pilnīgs” nozīmē to, ka izmanto arī reti sastopamu alēļu vērtības.

(2)  Šī pozīcija ir definēta ASCII standartā.

(3)  M = obligāts (mandatory), ja pieejams valsts reģistrā; O = fakultatīvs (optional).

(4)  Visi dalībvalstu īpaši norādītie atribūti ir atzīmēti ar Y.

(5)  Saskaņotā dokumenta saīsinājums, skatīt Padomes Direktīvu 1999/37/EK, 29.4.1999.

(6)  M = obligāts (mandatory), ja pieejams valsts reģistrā; O = fakultatīvs (optional).

(7)  Saskaņotā dokumenta saīsinājums, skatīt Padomes Direktīvu 1999/37/EK, 29.4.1999.

(8)  Luksemburgā izmanto divus dažādus transportlīdzekļu dokumentu reģistrācijas ID.

(9)  M = obligāts (mandatory) jāizmanto vai jāievēro; O = fakultatīvs (optional) izmantojums vai ievērošana.


Top