transportlĪdzekĻu un konteineru · 2.1.1 bp_1 procesu grupa “muitas noteikumu (es robežas) ......

1.pielikums

Valsts ieņēmumu dienesta rīkotā atklātā konkursa nolikumam

“<Iepirkuma nosaukums>”

publiskā iepirkuma identifikācijas

Nr. FM VID 2018/061

TRANSPORTLĪDZEKĻU UN KONTEINERU

AUTOMĀTISKĀS IDENTIFIKĀCIJAS SISTĒMA

TEHNISKĀ SPECIFIKĀCIJA

2

Pieļaujama dokumentā iekļautās informācijas citēšana un izmantošana atvasinātu darbu veidošanai,

iekļaujot atsauci uz šo dokumentu.

Visas tekstā izmantotās tirdzniecības zīmes pieder to īpašniekiem un ir izmantotas tikai kā atsauces.

SATURA RĀDĪTĀJS

1 Ievads ....................................................................................................... 5

1.1 Dokumenta nolūks un darbības sfēra ...................................................................... 5

1.2 Definīcijas un saīsinājumi ............................................................................................. 5

1.3 Saistītie dokumenti ...................................................................................................... 10

1.4 Dokumenta pārskats ................................................................................................... 10

2 Vispārīgās prasības ............................................................................... 12

2.1 SISTĒMAS darbības principi un darbības vide ................................................... 12

2.1.1 BP_1 procesu grupa “Muitas noteikumu (ES robežas) pārkāpumu

atklāšana, novēršana un preventīvās darbības” ............................................................... 15

2.1.2 BP_2 procesu grupa “Muitas risku analīze un vadība” ................................. 31

2.2 SISTĒMAS elementu uzstādīšanas vietas ............................................................. 44

3 Funkcionālās prasības .......................................................................... 46

3.1 (AIA) Prasības TL attēlu ieguvei un apstrādei ..................................................... 46

3.2 (NK) Prasības Notikuma izveidei un aprakstīšanai SISTĒMĀ ........................ 46

3.3 (NS) Prasības Notikumu sasaistei ........................................................................... 52

3.4 (NP) Prasības Notikuma pārbaudei........................................................................ 52

3.5 (RP) Prasības Riska profila izveidei un pārvaldībai ........................................... 53

3.6 (TR) Prasības Trauksmes ierakstam ........................................................................ 57

3.7 (MFP) Prasības meklēšanai, datu atlasei un filtrēšanai ................................... 60

3.8 (AP) Prasības SISTĒMAS auditācijai ........................................................................ 61

3.9 (KZP) Prasības SISTĒMAS kļūdu ziņojumiem ...................................................... 62

3.10 (ADMP) Prasības SISTĒMAS administrēšanai ..................................................... 63

3.11 (LTP) Lietotāju tiesību pārvaldība ........................................................................... 64

3.12 (INP) Prasības integrācijai ar citām IS ................................................................... 66

3

3.13 (ATP) Prasības atskaitēm ............................................................................................ 68

3.14 (DP) Prasības datu plūsmai, apmaiņai un glabāšanai ...................................... 69

3.15 (IDK) Prasības ievadīto datu kontrolēm ............................................................... 70

3.16 (CIT) Citas prasības ...................................................................................................... 71

4 Infrastruktūras prasības ....................................................................... 72

4.1 (IVP) Infrastruktūras vispārīgās prasības .............................................................. 72

4.2 (IDP) Infrastruktūras detalizētākās prasības ........................................................ 81

5 Nefunkcionālās prasības .................................................................... 116

5.1 Prasības saskarnēm un dizainam .......................................................................... 116

5.2 Prasības SISTĒMAS veiktspējai .............................................................................. 117

5.3 Prasības SISTĒMAS uzturamībai ............................................................................ 121

5.4 Prasības autentifikācijai un autorizācijai ............................................................ 122

5.5 Prasības SISTĒMAS konfigurācijai ........................................................................ 124

5.6 Prasības datu migrēšanai ........................................................................................ 125

5.7 Prasības SISTĒMAS darbības pārbaudei............................................................. 126

5.8 Prasības SISTĒMAS drošībai ................................................................................... 127

5.9 Prasības datu un dokumentu arhivēšanai ......................................................... 128

5.10 Prasības SISTĒMAS ieviešanai ................................................................................ 129

6 Organizatoriskās prasības ................................................................. 130

6.1 Prasības nodevumiem un dokumentācijai ........................................................ 130

6.2 Prasības SISTĒMAS izstrādei ................................................................................... 139

6.3 Prasības garantijai un uzturēšanai........................................................................ 140

6.4 Prasības pārvaldības metodēm ............................................................................. 145

6.5 Citas organizatoriskās prasības ............................................................................. 147

7 Pielikums Nr.1 – Ventspils ostas MKP SISTĒMAS elementu plānotā

izvietojuma vieta ................................................................................ 149

8 Pielikums Nr.2 - Liepājas ostas MKP SISTĒMAS elementu plānotā


4

9 Pielikums Nr.3 – Meikšānu RŠV SISTĒMAS elementu plānotā


10 Pielikums Nr.4 – Kaplavas RŠV SISTĒMAS elementu plānotā


11 Pielikums Nr.5 – Pededzes RŠV SISTĒMAS elementu plānotā


5

1 IEVADS

1.1 Dokumenta nolūks un darbības sfēra

Šis dokuments ir izstrādāts kā pielikums Transportlīdzekļu un konteineru automātiskās identifikācijas

sistēmas (turpmāk – TLKAIS) modernizēšanas (uzlabošanas, papildināšanas) iepirkuma nolikumam.

Pamatojoties uz šo dokumentu, ieinteresētie Pretendenti veiks Tehniskā piedāvājuma sagatavošanu.

Šo dokumentu iepirkuma komisija izmantos Piedāvājumu vērtēšanas procesā.

Dokuments izstrādāts, ņemot vērā esošo situāciju, kas aprakstīta dokumentā “Transportlīdzekļu un

konteineru automātiskās identifikācijas sistēmas esošās situācijas izpētes ziņojums” [1].

1.2 Definīcijas un saīsinājumi

1.tabula. Definīcijas un saīsinājumi

Saīsinājums, termins Skaidrojums

DB Datu bāze

EE (EST) Igaunijas valsts kods

e-pasts Elektroniskais pasts

ES Eiropas Savienība

EXCEL XLSX XML bāzēts Excel lietojumprogrammatūras dokumentu formāts

EXP Eksports (Eksporta josla) vai arī izbraukšanas josla kontekstā ar TL

kustību Latvijas pierobežā

FTP Failu pārsūtīšanas protokols (angļu val. – File Transfer Protocol)

GSM Globālā mobilo sakaru sistēma (angļu val. - Global System for Mobile

communications)

HVI Kabelis ar aizsardzību pret augstsprieguma izlādi (angļu val. – High-

Voltage-resistance Insulated down conductors)

ID Identifikators

6


Identifikācijas punkts MKP un RŠV, kur notiek TL numuru un konteinera numuru

automātiska atpazīšana

ILU kods Intermodālo pārvadājumu kravas vienības kods (angļu val.-

Intermodal Loading Units)

IMO Starptautiskā Jūrniecības organizācija (angļu val. – International

Maritime organization)

IMP Imports (Importa josla) vai arī iebraukšanas josla kontekstā ar TL

kustību Latvijas pierobežā

IPPV Izpildītāja projekta pārvaldības vide, kurā IZPILDĪTĀJS izstrādā,

iesniedz VID (sinhronizējot no IPPV uz ISIPS) un uztur reģistrētos

pieteikumus, testēšanas piemērus, testēšanas procesa vēsturi,

pieteiktās kļūdas, izmaiņu pieprasījumus, informāciju par kļūdu

novēršanu, konsultāciju, uzturēšanas pakalpojumu un pēcgarantijas

kļūdu novēršanu.

IS Informācijas sistēma

ISIPS VID informācijas sistēmu izmaiņu pārvaldības sistēma, kurā VID

uztur reģistrētos pieteikumus, testēšanas piemērus, testēšanas

procesa vēsturi, pieteiktās kļūdas, izmaiņu pieprasījumus,

informāciju par kļūdu novēršanu, konsultāciju, uzturēšanas

pakalpojumu un pēcgarantijas kļūdu novēršanu, kā arī uztur saistītās

dokumentācijas izskatīšanas vēsturi.

Izpilddokumentācija Pretendenta sagatavotā dokumentācija objekta IKT infrastruktūras

nodošanas procesā, kas balstīta uz izstrādāto Būvprojektu objektam

un iekļauj visas veiktās izmaiņas IKT infrastruktūras izbūves laikā.

Izpildītājs Komersants vai komersantu grupa, kas saskaņā ar iepirkuma

rezultātiem, veiks pasūtījuma izpildi

Full HD Attēlu attēlošanas sistēmu izšķiršanas spēja ar 1920x1080 (hor. x

vert) pikseļiem

7


Konteiners Kravu pārvietošanas standartizēta vienība, ko izmanto gan

sauszemes, gan jūras, gan dzelzceļa pārvadājumiem. Izmanto

standartizētu identifikāciju un marķēšanu sistēmu. Papildus izmanto

arī standartizētus bīstamu kravu tipu un grupu apzīmējumus (tā

saucamās IMO klases).

Kravu TL plūsmas josla Josla RŠV, kur uzstādīti ass svari

LAN Lokālais tīkls (angļu val. – Local Area Network)

LT Lietuvas valsts kods

MK Muitas kontrole

MK_1610 Ministru kabineta 2009. gada 22.decembra noteikumi Nr. 1610

“Transportlīdzekļu reģistrācijas noteikumi”

MK_279 Ministru kabineta 2015. gada 2.jūnija noteikumi Nr. 279 “Ceļu

satiksmes noteikumi”

MKP Muitas kontroles punkts

NCP Nacionālais kontaktpunkts

Notikums Brīdis, kad TL šķērso transportlīdzekļu identifikācijas punktu

NVA Latvijas Republikas Iekšlietu ministrijas Nodrošinājuma valsts

aģentūra

Oracle SOA Suite

standartprodukts

Sistēmu integrācijas platforma

Partneris Citas valsts muitas, ar kurām VID Muitas pārvaldei ir noslēgts līgums

par datu apmaiņu

Pasūtītājs Valsts ieņēmumu dienests

PDF Portatīvā dokumentu formāts (no angļu val. – Portable Document

Format)

PDU Elektrobarošanas rozešu bloks (no angļu val. – Power Distribution

Unit)

8


Riska profils jeb Trauksmes

nosacījums

SISTĒMĀ ievadīta informācija par uzraudzībai pakļautu RŠ notikumu

PL Polijas valsts kods

Pretendents Komersants vai komersantu grupa, kas sagatavo Tehnisko

piedāvājumu.

Projekts VID Transportlīdzekļu un konteineru automātiskās identificēšanas

sistēmas iegāde, modernizācija un uzturēšana

POE Elektrobarošanas nodrošināšana pa datu pārraides kabeli (no angļu

val. – Power Over Ethernet)

RŠ Robežšķērsošana

RŠV Robežšķērsošanas vietas

SISTĒMA Nākotnes risinājums, kas paredzēts TL un konteineru numuru

automātiskai identifikācijai un sastāv no dažādiem sensoriem (t.sk.

svariem), programmatūras un tehniskās infrastruktūras.

SNMP Datu pārraide tīkla protokols (angļu val. - Simple Network

Management Protocol)

TL Transportlīdzeklis (šī dokumenta kontekstā – gan vieglie, gan

smagie (t.sk. ar piekabēm un konteineriem) transportlīdzekļi)

TLKAIS Esošā VID Transportlīdzekļu un konteineru automātiskās

identifikācijas sistēma

TP (Piedāvājums) Pretendenta izstrādātais SISTĒMAS Tehniskais piedāvājums, kas tiks

vērtēts, lai izvēlētos Izpildītāju

Trauksme Gadījums, kad SISTĒMA, validējot Notikumu parametrus pret

SISTĒMĀ definētajiem aktīvajiem Risku profiliem, nosaka sakritību.

Trauksmes paziņojums SISTĒMA līdz ar Trauksmes ierakstu reālā laika režīmā izveido un

nosūta informāciju par Trauksmi konkrētiem šīs informācijas

saņēmējiem uz e-pastu un/ vai mobilo ierīci.

TS Tehniskā specifikācija, kas ietver SISTĒMAS prasības

9


UPS Nepārtrauktās barošanas avots (angļu val. – Uninterruptible Power

Supply)

VID Valsts ieņēmumu dienests

VID DNS VID datu noliktavas sistēma

VID ISS VID informācijas sistēmu savietotājs

VID VNS VID Videonovērošanas sistēmas risinājums, kas izmanto Bosch

vadības un datu glabāšanas tehnoloģiju

WEB Globālais tīmeklis (angļu val. – World Wide Web)

WDR Apgaismojuma balansa regulēšanas īpašība (angļu val. – Wide

Dynamic Range)

XML Paplašināmās iezīmes valoda (angļu val. – eXtensible Markup

Language)

Dokumentā iekļauto prasību prioritāšu skaidrojums ir dots nākamajā tabulā (skat. 2. tabulā).

2.tabula. Prasību prioritāšu skaidrojums

Prasības prioritāte Skaidrojums

Obligāta Obligātās prasības ir svarīgākās prasības, kuras ir obligāti nepieciešamas,

izstrādājot SISTĒMU. Izpildītājam ir jārealizē visas obligātās prasības.

Pasūtītājs noraida tos Piedāvājumus, kuros netiks nodrošināta obligāto

prasību izpilde.

Vēlama Vēlamās prasības ir nepieciešamas, tomēr tās ir mazāk svarīgas kā

obligātās prasības. Vēlamās prasības ir jārealizē pēc Pasūtītāja

pieprasījuma. Projekta laikā Pasūtītājam ir tiesības pasūtīt vai nepasūtīt

vēlamās prasības. Ja nav konkrēti norādīts savādāk, tad uzskatāms, ka

prasība ir vēlama. Pasūtītājs noraida tos Piedāvājumus, kuros netiks

nodrošināta vēlamo prasību izpildes iespēja.

10

Prasības prioritāte Skaidrojums

Vērtējama Vērtējamo prasību realizāciju Izpildītājs var arī nenodrošināt, bet, ja

prasība tiks nodrošināta (bez papildus samaksas, piemēram, ja SISTĒMĀ

jau ir realizēta nepieciešamā prasība), tad Piedāvājuma vērtēšanā tas tiks

ņemts vērā ar papildus punktiem, tādejādi dodot ieguldījumu saimnieciski

izdevīgākā Piedāvājuma noteikšanā.

1.3 Saistītie dokumenti

3. tabula. Saistītie dokumenti

Nr.p.k. Dokumenta nosaukums Kods Datums

[1] Valsts ieņēmumu dienests. Transportlīdzekļu un

konteineru automātiskās identifikācijas sistēma.

Esošās situācijas izpētes ziņojums

VID_TLKAIS_ESIZ_v.1.5 2017.gads

1.4 Dokumenta pārskats

Šajā dokumentā konkrētās prasības ir sanumurētas un nosauktas īsā nosaukumā. Pēc prasības

nosaukuma un numura seko detalizētāks prasības izklāsts – tas turpinās līdz nākamās konkrētās

prasības nosaukumam un numuram vai numurētam dokumenta nodalījuma nosaukumam. Katrai

prasībai ir norādīta tās izpildes prioritāte. Numurēti dokumenta nodalījumi lietoti tikai dokumenta

lasāmības vienkāršošanai.

Šis dokuments satur sešas nodaļas:

1.nodaļa “ Ievads” ir sniegts vispārējs dokumenta raksturojums – dokumenta nolūks un

darbības sfēra, iekļauts dokumentā izmantoto jēdzienu un saīsinājumu atšifrējums,

aprakstīta dokumenta organizācija;

2.nodaļa “Vispārīgās prasības” aprakstītas plānotās SISTĒMAS vispārīgās prasības.

3.nodaļa “Funkcionālās prasības” ir aprakstītas plānotās SISTĒMAS funkcionālās prasības;

4.nodaļa “Infrastruktūras prasības” ir aprakstītas plānotās SISTĒMAS infrastruktūras prasības;

5.nodaļa “ Nefunkcionālās prasības” ir aprakstītas plānotās SISTĒMAS nefunkcionālās

prasības;

11

6.nodaļa “ Organizatoriskās prasības” ir aprakstītas plānotās SISTĒMAS izstrādes un

uzturēšanas projekta organizatoriskās prasības.

12

2 VISPĀRĪGĀS PRASĪBAS

Šajā nodaļā ir aprakstītas nākotnes risinājuma, kas paredzēts TL un konteineru numuru automātiskai

identifikācijai, vispārīgās prasības.

2.1 SISTĒMAS darbības principi un darbības vide

KOP-01 SISTĒMAS konceptuālā arhitektūra (obligāta)

Nākotnes SISTĒMAS konceptuālā arhitektūras shēma parādīta zemāk (skat. 1. attēlu).

1. attēls. Nākotnes SISTĒMAS konceptuālā arhitektūra

Attēlā redzamajam piemēram ir informatīvs raksturs, kas parāda kopējo nepieciešamo SISTĒMAS

konceptuālo funkcionalitāti, kā arī ataino plānotās nepieciešamās integrācijas ar citām IS.

13

Attēls 2. Nākotnes SISTĒMAS topoloģija

SISTĒMAS programmatūrai (informācijas sistēmai) jābūt veidotai kā trīs līmeņu tīmekļa informācijas

sistēmai, kurā trijos līmeņos ir nodalīta informācijas prezentācija (lietotāja saskarnes) no biznesa

loģikas (sistēmas funkcionalitāte) un no datu glabāšanas (datu bāze).

Pretendentam, sagatavojot Piedāvājumu, ir jāiesniedz detalizēts SISTĒMAS tehnoloģiskās un

funkcionālās arhitektūras plānojums un apraksts.

KOP-02 SISTĒMAS darbības principi un darbības vide (obligāta)

SISTĒMAI jāpārņem TLKAIS dati, datu apmaiņas saskarnes un funkcionalitāte vismaz tādā apmērā,

kas ir pietiekams pilnvērtīgam prasībā KOP-03 “TLKAIS atbalstāmie VID darbības procesi” aprakstīto

procesu atbalstam.

Detalizēti TLKAIS esošā situācija ir aprakstīta dokumentā “Transportlīdzekļu un konteineru

automātiskās identifikācijas sistēmas esošās situācijas izpētes ziņojums” [1]. Pretendentam

14

Piedāvājums jāsagatavo, ņemot vērā to, kāda šobrīd ir darbības vide, esošā TLKAIS tehnoloģiskā un

funkcionālā arhitektūra un sistēmas darbības principi tādā mērā, cik tas ietekmē šo pašu vai

līdzvērtīgu funkciju nodrošināšanu piedāvātajā SISTĒMĀ, kā arī esošo TLKAIS datu migrāciju uz

piedāvāto SISTĒMU.

KOP-03 TLKAIS atbalstāmie VID darbības procesi (obligāta)

Izpildītājam SISTĒMA jāveido tā, lai nodrošinātu vismaz nākamajā tabulā (skat. 4. tabulu) uzskaitītos

biznesa procesus, ņemot vērā funkcionālās prasības un to realizācijas prioritātes. Ar esošajiem TLKAIS

atbalstāmajiem procesiem un to izpildi ir iespējams iepazīties dokumentā “Transportlīdzekļu un

konteineru automātiskās identifikācijas sistēmas esošās situācijas izpētes ziņojums” [1]. SISTĒMAS

pamata procesu detalizētais izvērsums ir sniegts zemāk.

Biznesa procesu un prasību analīzes laikā Pasūtītājs var precizēt procesu izpildi, ņemot vērā

piedāvātās SISTĒMAS iespējas un ierobežojumus, bet tie ir jāskaņo ar Pasūtītāju.

4. tabula. SISTĒMAS biznesa procesi

Biznesa

procesa

identifikators

Biznesa

procesa/procesu

grupas

nosaukums

Biznesa procesa nosaukums

BP_1 Muitas noteikumu (ES robežas) pārkāpumu atklāšana, novēršana un

preventīvās darbības

BP_1_1 Transportlīdzekļa numura zīmes (arī konteinera

identifikatora) atpazīšana, Notikuma izveide / labošana

BP_1_2 Riska Notikuma noteikšana un muitas kontroles pasākumu

piemērošana

BP_1_3 Muitas kontroles rezultātu ziņošana

BP_1_4 SISTĒMAS darbības atbilstības regulārā pārbaude (MKP)

BP_1_5 Neidentificēto un kļūdaini identificēto TL numuru analīze

BP_2 Muitas risku analīze un vadība

BP_2_1 Informācijas analīze par TL robežas šķērsošanas

gadījumiem

15

Biznesa

procesa

identifikators

Biznesa

procesa/procesu

grupas

nosaukums

Biznesa procesa nosaukums

BP_ 2_2 Riska profila izveide

BP_ 2_3 Riska profila darbības izbeigšana

BP_ 2_4 Pārskatu par Risku profilu darbību sagatavošana

2.1.1 BP_1 procesu grupa “Muitas noteikumu (ES robežas)

pārkāpumu atklāšana, novēršana un preventīvās darbības”

Procesu grupas “Muitas noteikumu (ES robežas) pārkāpumu atklāšana, novēršana un preventīvās

darbības” ietvarā VID ikdienas operatīvajā darbībā SISTĒMA tiek izmantota muitas kontroles punktos,

lai nodrošinātu robežu šķērsojošo transportlīdzekļu (t.sk. piekabju un konteineru) numura zīmju un

identifikatoru atpazīšanu, tādējādi veicot transportlīdzekļu identificēšanu. Uz iegūtās informācijas

pamata tiek veikta uzraudzībā esošo Notikumu gadījumu (MKP) kontrole reālā laikā.

MKP tiek veikti šādi procesi (skat. 3. attēlu):

BP_1_1 Transportlīdzekļa numura zīmes (arī konteinera identifikatora) atpazīšana, Notikuma

izveide / labošana - 2 scenāriji:

□ BP_1_1a - vieglo TL un pasažieru pārvadājumu TL plūsma;

□ BP1_1b - kravu TL plūsma;

BP_1_2 Riska Notikuma noteikšana un muitas kontroles pasākumu piemērošana;

BP_1_3 Muitas kontroles rezultātu ziņošana (informācijas ievade);

BP_1_4 SISTĒMAS darbības atbilstības regulārā pārbaude (MKP);

BP_1_5 Neidentificēto un kļūdaini identificēto transportlīdzekļu numuru analīze.

16

3. attēls. BP_1 procesu grupa “Muitas noteikumu pārkāpumu atklāšana un preventtīvās

darbības”

Detalizēta BP_1 procesu izpilde aprakstīta zemāk.

17

BP_1_1a Transportlīdzekļa numura zīmes (vieglo TL un pasažieru pārvadājuma TL plūsma) -

atpazīšana, Notikuma izveide / labošana

18

4.attēls. BP_1_1a Transportlīdzekļa numura zīmes (vieglo TL un pasažieru pārvadājumu TL plūsma) atpazīšana, Notikuma izveide / labošana

5. tabula. BP_1_1a Transportlīdzekļa numura zīmes (vieglo TL un pasažieru pārvadājumu TL plūsma) atpazīšana, Notikuma izveide/ labošana

Procesa/

soļa ID

Ievade (input) Procesa darbība/ darbības apraksts Izpildītājs Rezultāts

BP_1_1a.1 Ar SISTĒMAS

sensoriem fiksēts TL

identifikācijas punkta

šķērsošanas gadījums

Automātiski izveido Notikuma ierakstu, fiksē Notikuma

vietu (MKP/ RŠV un joslu), datumu un laiku, piešķir

Notikumam ID, pievieno fiksēto vizuālo informāciju

(attēlus).

SISTĒMA, t.sk., MKP/RŠV

SISTĒMAS

komponentes

SISTĒMĀ izveidots

Notikums un

pievienota Notikuma

pamatinformācija.

BP_1_1a.2 BP_1_1a.1 rezultāts Veic TL numura atpazīšanu, pievieno atpazītā TL numura

datus (t.sk., valsts piederību) Notikumam.

SISTĒMA, t.sk., MKP/

RŠV SISTĒMAS

komponentes

Notikumam pievienota

TL informācija.

BP_1_1a.3 BP_1_1a.2 rezultāts Aprēķina un atrāda pie Notikuma datiem TL atpazīšanas

varbūtību.


RŠV SISTĒMAS

komponentes

Aprēķināta atpazīšanas

varbūtība.

BP_1_1a.4 PL, LT un/ vai EE

muitas kontroles IS

reģistrēts notikums

Automātiski izveido Notikuma ierakstu ar saņemtajiem

datiem, pievieno Notikuma norises vietas valsts

apzīmējumu.


RŠV SISTĒMAS

komponentes

SISTĒMĀ ir reģistrēti

notikumi no LT, PL un

EE.

BP_1_1a.5 Gadījums, kad

nepieciešams

Notikumu izveidot

manuāli

Atver SISTĒMU. MKP lokālais SISTĒMAS

(automātisks SISTĒMAS

solis)

Tiek atvērta SISTĒMAS

lietotāja saskarne.

19

Procesa/

soļa ID


BP_1_1a.6 BP_1_1a.5 rezultāts Manuāli izveido Notikumu, atverot jaunu Notikuma

ierakstu (SISTĒMA automātiski piešķir Notikuma ID).

VID atbildīgais

darbinieks

Izveidots Notikums.

BP_1_1a.7 BP_1_1a.2 un/ vai

BP_1_1a.6 rezultāts

Ievada/ labo TL numura datus, valsts piederību, jaunam

ierakstam (kad informācija tiek pirmreizēji ievadīta) -

norāda Notikuma vietu un joslu, pievieno Notikuma

attēlus. Notikuma informācijas labošanas gadījumā attēlus

pievienot nevar!

VID atbildīgais

darbinieks

Notikumam pievienota

nepieciešamā

informācija.

BP_1_1a.8 BP_1_1a.3, BP_1_1b.4

vai BP_1_1a.7 rezultāts

Saglabā. SISTĒMA, t.sk., MKP/

RŠV SISTĒMAS

komponentes

Dati ir saglabāti.

20

BP_1_1b Transportlīdzekļa numura zīmes (kravu TL plūsma) atpazīšana, Notikuma izveide

5. attēls. BP_1_1b Transportlīdzekļa numura zīmes (kravu TL plūsma) atpazīšana, Notikuma izveide

21

6. tabula. BP_1_1b Transportlīdzekļa numura zīmes (kravu TL plūsma) atpazīšana, Notikuma izveide

Procesa/

soļa ID


BP_1_1b.1 Ar SISTĒMAS

sensoriem fiksēts TL

identifikācijas punkta

šķērsošanas gadījums

Automātiski izveido Notikuma ierakstu, fiksē Notikuma vietu

(MKP/ RŠV un joslu), datumu un laiku, piešķir Notikumam ID,

pievieno fiksēto vizuālo informāciju (attēlus).

SISTĒMA, t.sk., MKP/ RŠV

SISTĒMAS komponentes

SISTĒMĀ izveidots

Notikums un

pievienota Notikuma

pamatinformācija.

BP_1_1b.2 BP_1_1b.1 rezultāts Veic TL priekšējā numura atpazīšanu, piekabes numura

atpazīšanu un/ vai TL konteinera/-u numurus, pievieno atpazītā

TL numura datus (t.sk., valsts piederību) Notikumam.



Notikumam

pievienota TL un/ vai

konteinera

informācija.

BP_1_1b.3 BP_1_1b.2 rezultāts Aprēķina un atrāda pie Notikuma datiem TL atpazīšanas

varbūtību.



Aprēķināta

atpazīšanas varbūtība.

BP_1_1b.4 BP_1_1b.2 rezultāts Notikumam automātiski pievieno svaru informāciju. SISTĒMA, t.sk., MKP/ RŠV


Pievienota ass svaru

informācija.

BP_1_1b.5 PL, LT un/ vai EE muitas

kontroles IS reģistrēts

notikums

Automātiski izveido notikuma ierakstu ar saņemtajiem datiem,

pievieno notikuma norises vietas valsts apzīmējumu.



SISTĒMĀ ir reģistrēti

notikumi no LT, PL un

EE.

22

Procesa/

soļa ID


BP_1_1b.6 Gadījums, kad

nepieciešams

Notikumu izveidot

manuāli

Atver SISTĒMU. VID atbildīgais darbinieks Tiek atvērta SISTĒMAS


BP_1_1b.7 BP_1_1b.6 rezultāts Manuāli izveido Notikumu, atverot jaunu Notikuma ierakstu

(SISTĒMA automātiski piešķir notikuma ID).

VID atbildīgais darbinieks Izveidots Notikums.

BP_1_1b.8 BP_1_1b.7 rezultāts Ievada/ labo TL numura datus, valsts piederību, konteinera/-u

numurus, svaru informāciju.

Jaunam ierakstam - norāda Notikuma vietu un joslu, pievieno

Notikuma attēlus.

VID atbildīgais darbinieks Notikumam

pievienota

nepieciešamā

informācija.

BP_1_1b.9 BP_1_1b.3, BP_1_1b.4,

BP_1_1b.5 vai

BP_1_1b.8 rezultāts

Saglabā. SISTĒMA, t.sk., MKP/ RŠV


Dati ir saglabāti.

23

BP_1_2 Riska Notikuma noteikšana un muitas kontroles pasākumu piemērošana

6. attēls. BP_1_2 Riska Notikuma noteikšana un muitas kontroles pasākumu piemērošana

7. tabula. BP_1_2 Riska Notikuma noteikšana un muitas kontroles pasākumu piemērošana

Procesa/

soļa ID


BP_1_2.1 Izveidots jauns/ labots

esošs Notikums

(BP_1_1)

Jaunas Trauksmes paziņojumu attēlo lietotāja saskarnē SISTĒMA Darbiniekam lietotāja

saskarnē tiek attēlots

Trauksmes paziņojums.

24

Procesa/

soļa ID


SISTĒMA veic atpazītā TL reģistrācijas numura (arī piekabes un

konteinera numura) salīdzināšanu ar uzraudzībā norādītajiem

TL datiem (definētajām aktīvajām Trauksmēm). Gadījumā, ja

tiek noteikta Notikuma datu sakritība ar uzraudzībā noteiktu

informāciju (uzraudzības parametriem), SISTĒMA izveido

Trauksmes paziņojumu.

BP_1_2.2 BP_1_2.1 rezultāts Nosūta jaunas Trauksmes informāciju uz mobilo ierīci un e-

pasta adresi - atbilstoši tam, kā noteikts konkrētajā Riska

profilā, SISTĒMA nosūta informāciju par Trauksmi uz

norādītajiem mobilo tālruņu numuriem un e-pasta adresēm.

SISTĒMA SISTĒMA nosūta

informāciju par

Trauksmi.

BP_1_2.3 BP_1_2.1 un BP_1_2.2

rezultāts

Saņem operatīvo informāciju par Trauksmi.

VID atbildīgais

darbinieks

Darbinieks saņem

Trauksmes informāciju.

BP_1_2.4 BP_1_2.3 rezultāts Apstiprina trauksmes saņemšanu.

VID atbildīgais

darbinieks

Trauksme ir

apstiprināta.

BP_1_2.5 BP_1_2.4 rezultāts Saglabā apstiprinājumu. SISTĒMA Apstiprinājums ir

saglabāts.

25

Procesa/

soļa ID


BP_1_2.6 BP_1_2.5 rezultāts Nodrošina muitas kontroles pasākumu izpildi - Riska profilos

norādītā rīcības informācija (veicamās darbības) var būt ļoti

dažāda, tomēr aktīvās rīcības darbības parasti attiecas uz

nekavējošu rīcību uzreiz muitas kontroles punktā.

VID atbildīgais

darbinieks

Darbinieks izpilda

profilā norādītās

darbības.

26

BP_1_3 Muitas kontroles rezultātu ziņošana

7. attēls. BP_1_3 Muitas kontroles rezultātu ziņošana

27

8. tabula BP_1_3 Muitas kontroles rezultātu ziņošana

Procesa/

soļa ID


BP_1_3.1 Veiktas Riska profilā

norādītās darbības.

Atver SISTĒMU, atrod atbilstošo Trauksmes

ierakstu.

VID atbildīgais

darbinieks

Tiek atvērta SISTĒMAS lietotāja saskarne.

BP_1_3.2 BP_1_3.1 rezultāts Ievada informāciju par muitas kontroles

rezultātiem pēc Riska profilā noteikto darbību

izpildes.

Tiek aizpildīta detalizēta informācija par

kontroles laikā veiktajām darbībām un

rezultātiem.

VID atbildīgais

darbinieks

Ir ievadīta informācija par muitas

kontroles rezultātiem.

BP_1_3.3 BP_1_3.2 rezultāts Saglabā. SISTĒMA Dati tiek saglabāti.

28

BP_1_4 SISTĒMAS darbības atbilstības regulārā pārbaude

29

8. attēls. BP_1_4 SISTĒMAS darbības atbilstības regulārā pārbaude

9. tabula. BP_1_4 SISTĒMAS darbības atbilstības regulārā pārbaude (MKP)

Procesa/

soļa ID


BP_1_4.1 VID iekšējie normatīvi Atver SISTĒMU.

Atver Notikumu sarakstu.

VID atbildīgais darbinieks Tiek atvērta SISTĒMAS


BP_1_4.2 BP_1_4.1 rezultāts Apskata SISTĒMAS health ckeck rīkā, vai SISTĒMAS

darbība ir atbilstoša prasībām.

VID atbildīgais darbinieks Ir veikta pārbaude.

BP_1_4.3 BP_1_4.2 rezultāts Ziņo SISTĒMAS administratoram.

Ja ir SISTĒMAS darbības traucējumi, nosūta ziņu

SISTĒMAS administratoram.

VID atbildīgais darbinieks Administratoram ir nosūtīta

ziņa par darbības

traucējumiem.

BP_1_4.4 SISTĒMĀ ir realizēta automatizēta nepārtraukta

SISTĒMAS darbības uzraudzība, kuras ietvarā:

SISTĒMA identificē problēmu;

Ziņo SISTĒMAS administratoram par darbības

kļūdu.

SISTĒMA Administratoram ir nosūtīta

informācija par SISTĒMAS

darbības traucējumiem.

BP_1_4.5 BP_1_4.3 un BP_1_4.4

rezultāts

Saņem ziņojumu, rīkojas atbilstoši, lai nodrošinātu

korektu SISTĒMAS darbību.

SISTĒMAS administrators Veikti pasākumi SISTĒMAS

darbības atjaunošanai.

30

BP_1_5 Neidentificēto un kļūdaini identificēto TL numuru analīze

9. attēls. BP_1_5 Neidentificēto un kļūdaini identificēto TL numuru analīze

10. tabula. BP_1_5 Neidentificēto un kļūdaini identificēto TL numuru analīze

Procesa/

soļa ID


BP_1_5.1 VID iekšējie noteikumi

nr.30

Atver SISTĒMU.

Atver Notikumu sarakstu.

VID atbildīgais

darbinieks

Tiek atvērta SISTĒMAS lietotāja saskarne.

BP_1_5.2 BP_1_5.1 rezultāts Iegūst atskaiti par neatpazītiem vai kļūdaini

atpazītiem Notikumiem noteiktā laika

periodā.

VID atbildīgais

darbinieks

Ir iegūta nepieciešamā atskaite.

BP_1_5.3 BP_1_5.2 rezultāts Eksportē datus nepieciešamajā formātā,

saglabā darbstacijas cietajā diskā, pēc

vajadzības - izdrukā.

VID atbildīgais

darbinieks

Atskaite saglabāta darbstacijas cietajā

diskā un/ vai izdrukāta.

31

2.1.2 BP_2 procesu grupa “Muitas risku analīze un vadība”

SISTĒMAS izmantošana Muitas risku analīzes un vadības nodrošināšanai tiek realizēta sekojoši – šajā

procesu grupā detalizēti tiek apskatīti šādi procesi (skat. 10. attēlu):

BP_2_1 Informācijas analīze par TL robežas šķērsošanas gadījumiem;

BP_ 2_2 Riska profila izveide / labošana;

BP_2_3 Riska profila darbības izbeigšana;

BP_2_4 Pārskatu par Risku profilu darbību sagatavošana.

10. attēls. BP_2 procesu grupa “Muitas risku analīze un vadība”

Detalizēta BP_2 procesu izpilde aprakstīta zemāk.

32

BP_2_1 Informācijas analīze par TL robežas šķērsošanas gadījumiem

11. attēls. BP_2_1 Informācijas analīze par TL robežas šķērsošanas gadījumiem

11.tabula. BP_2_1 Informācijas analīze par TL robežas šķērsošanas gadījumiem

Procesa/

soļa ID


BP_2_1.1 SISTĒMAS dati par

Notikumiem, t.sk. neatpazītu

TL informācija.

Atver SISTĒMU. VID atbildīgais

darbinieks

Tiek atvērta SISTĒMAS lietotāja

saskarne.

BP_2_1.2 BP_2_1.1 rezultāts Izveido atskaiti. VID atbildīgais

darbinieks

Ir izveidota nepieciešamā

atskaite.

BP_2_1.3 BP_2_1.2 rezultāts Eksportē datus nepieciešamajā formātā.

VID atbildīgais

darbinieks

Atskaites dati ir eksportēti

nepieciešamajā formātā.

33

BP_2_2 Riska profila izveide / labošana

34

12. attēls. BP_2_2 Riska profila izveide / labošana

12. tabula. BP_2_2 Riska profila izveide / labošana

Procesa/

soļa ID


BP_2_2.1 Informācijas par

robežas šķērsošanas

gadījumiem analīzes

rezultāti.

Izveido/ labo

Riska profilu

Ievada/labo informāciju par uzraudzībai

pakļauto TL (t.sk. kravu, konteineri), norāda

identifikācijas punktus un nepieciešamās

darbības (muitas kontroles procesa izpildei).

Risku vadības nodaļas

atbildīgais darbinieks

SISTĒMĀ izveidots Riska

profils, kurā ir norādīta

nepieciešamā informācija

TL uzraudzības

nodrošināšanai.

Ievada/ labo Trauksmes paziņojuma

informāciju.

Norāda/ labo Trauksmes saņēmējus.

BP_2_2.2 Riska profila

informācija no PL, LT

vai EE muitas

informācijas

sistēmas.

Izvērtē

informāciju un

nepieciešamības

gadījumā

izveido/ labo

Riska profilu.

Tulko saņemto informāciju un nosaka

nepieciešamās darbības muitas kontroles

procesam.

SISTĒMAS nacionālā

kontaktcentra VID

atbildīgais darbinieks

SISTĒMĀ no informācijas,

kas saņemta no PL, LT vai

EE, izveidots Riska profils,

kurā ir norādīta

nepieciešamā informācija

TL uzraudzības

nodrošināšanai.

Ievada/ labo Trauksmes paziņojuma

informāciju.

Norāda/ labo Trauksmes saņēmējus.

BP_2_2.2 BP_2_2.1 un

BP_2_2.2 rezultāti

Saglabā. SISTĒMA Dati ir saglabāti SISTĒMĀ.

35

BP_2_3 Riska profila darbības izbeigšana

13. attēls. BP_2_3 Riska profila darbības izbeigšana

36

13. tabula. BP_2_3 Riska profila darbības izbeigšana

Procesa/

soļa ID


BP_2_3.1 Riska profila

darbības derīguma

perioda beigšanās

Pēc Riska profila derīguma perioda beigām pārtrauc Notikumu

datu validāciju pret Riska profilā definētiem parametriem.

SISTĒMA Riska profila statuss ir

neaktīvs.

BP_2_3.2 BP_2_3.1

rezultāts;

Informācijas par

robežas

šķērsošanas

gadījumiem

analīzes rezultāti

u.c. BP_2_1

rezultāti

Atrod noteikto Riska profilu. Risku vadības

nodaļas muitas

amatpersona

Atrasts nepieciešamais

Riska profils.

BP_2_3.3 BP_2_3.2 rezultāts

Dzēš nevajadzīgo Riska profilu. Risku vadības

nodaļas muitas

amatpersona

Dzēsts nevajadzīgs vai

aktualitāti zaudējis Riska

profils.

BP_2_3.4 BP_2_3.3 rezultāts Saglabā. SISTĒMA Izmaiņas ir saglabātas

SISTĒMĀ.

37

BP_2_4 Pārskatu par Risku profilu darbību sagatavošana

14. attēls. BP_2_4 Pārskatu par Risku profilu darbību sagatavošana

14. tabula. BP_2_4 Pārskatu par Risku profilu darbību sagatavošana

Procesa/

soļa ID


BP_2_4.1 VID iekšējie

normatīvi

Atver SISTĒMU. VID atbildīgais

darbinieks

Tiek atvērta SISTĒMAS


BP_2_4.2 BP_2_4.1 rezultāts; Izveido atskaiti – pārskatu par Risku profilu darbību. VID atbildīgais

darbinieks

Ir izveidota nepieciešamā

atskaite.

BP_2_4.3 BP_2_3.2 rezultāts Eksportē datus nepieciešamajā formātā. VID atbildīgais

darbinieks

Atskaites dati ir eksportēti

nepieciešamajā formātā.

38

KOP-04 SISTĒMAS lietotāji (obligāta)

Ir plānots, ka SISTĒMU izmantos iekšējie lietotāji (VID darbinieki – detalizētu lietotāju dalījumu pa

struktūrvienībām skatīt dokumentā “Transportlīdzekļu un konteineru automātiskās identifikācijas

sistēmas esošās situācijas izpētes ziņojums” [1]) un citu institūciju pārstāvji – ārējie lietotāji. SISTĒMAI

ir jānodrošina lietotāju dalījums pēc piekļuves institūciju (organizāciju) specificētiem informācijas

apgabaliem (biznesa datiem) SISTĒMĀ, proti, ir jānodrošina pilnībā neatkarīga tās informācijas ievade

un pārvaldība katras organizācijas ietvarā, ko veic SISTĒMAS lietotājs atbilstoši lietotāja piederībai

konkrētai institūcijai (organizācijai).

Lietotājiem ar SISTĒMAS administrēšanas tiesībām ir jānodrošina SISTĒMAS satura - biznesa datu, t.i.,

Risku profilu (Trauksmju nosacījumu) un Trauksmju - apskates ierobežošana.

KOP-05 SISTĒMAS lietotāju kategorijas un tiesību grupas (obligāta)

SISTĒMAI ir jānodrošina lietotāju dalījums pēc lomām un tiesībām darbībai SISTĒMĀ, piemēram:

lietotāji ar SISTĒMAS administrēšanas tiesībām (detalizētas administrēšanas prasības

aprakstītas 3.10. nodaļā);

lietotāji, kuri var:

□ izveidot jaunu Notikumu, veikt Notikuma ieraksta papildinājumus/ labojumus;

□ izveidot jaunu Riska profilu, labot Riska profilu, dzēst neaktuālu Risku profilu;

□ saņemt Riska iestāšanās gadījuma (Trauksmes) paziņojumu un veikt aktuālās

Trauksmes informācijas apstrādi;

□ papildināt/ labot noteiktus klasifikatorus (katalogus);

lietotāji, kuri var tikai:

□ saņemt Trauksmes paziņojumu, Trauksmes ierakstā aizpildīt noteiktu informāciju

(datu laukus);

□ apstrādāt Notikuma datus – Notikuma ierakstam labot noteiktus datu laukus.

SISTĒMAS lietotāju tiesības ir attēlotas matricās (skat. 15. tabulu un 16. tabulu), bet SISTĒMAS prasību

analīzes fāzē noteikti jāveic detalizēta lietotāju lomu un tiesību analīze – atbilstoši esošo TLKAIS

lietotāju lomu dalījumam. Līdz ar to matricā var tikt papildinātas gan lietotāju kategorijas, gan

SISTĒMAS objekti, gan lietotājiem pieejamajās tiesības* jeb darbības ar SISTĒMAS objektiem (darbības

un darbību apzīmējumus skatīt zem 15. un 16. tabulas).

39

15. tabula. SISTĒMAS VID lietotāju tiesību matrica

Lietotāju

kategorijas

Sistēmas

objekti

No

tik

um

i

Tra

uksm

es

Ris

ka p

rofi

li

Au

dit

ācij

as

iera

kst

i

Sis

tēm

as

ad

min

istr

ēša

na

Lie

totā

ju

ad

min

istr

ēša

na

Kla

sifi

kato

ri

Ats

kait

es

MKP darbinieki CRU RU R

VID Riska vadības nodaļa R CRU CRUD R R

Muitas pārvaldes darbinieki CRU CRU CRUD R R R

SISTĒMAS administrators R CRUD

Klasifikatoru satura

pārvaldnieks

CRUD

Lietotāju pārvaldnieks CRUD

Atskaišu pārvaldnieks CRU

* C – Izveidot (create), R – Apskatīt (read), U – Rediģēt (update), D – Dzēst (delete)

16. tabula. SISTĒMAS Ārējas organizācijas lietotāju tiesību matrica

Lietotāju

kategorijas

Sistēmas

objekti

No

tik

um

i

Tra

uksm

es

Ris

ka p

rofi

li

Au

dit

ācij

as

iera

kst

i

Sis

tēm

as

ad

min

istr

ēša

na

Lie

totā

ju

ad

min

istr

ēša

na

Kla

sifi

kato

ri

Ats

kait

es

Lietotājs (darbinieks) R R CR R

Klasifikatoru satura

pārvaldnieks

CRUD

* C – Izveidot (create), R – Apskatīt (read), U – Rediģēt (update), D – Dzēst (delete).

KOP-06 Notikumu datu plūsmu apstrāde (obligāta)

Notikuma datus SISTĒMAI ir jāvar apstrādāt neatkarīgi no tā, vai tie ir radīti SISTĒMĀ vai importēti no

Igaunijas, Lietuvas un Polijas muitas kontroles punktu/ robežas šķērsošanas vietu specifiskajām IS.

KOP-07 SISTĒMAS infrastruktūras izveides aktivitātes esošajiem MKP, kuros jau bija izveidota TLKAIS infrastruktūra (obligāta)

Infrastruktūras darbu realizācijas ietvaros ir jānodrošina vismaz šādu darbu un aktivitāšu realizācija:

40

1. POSMS – Būvprojekta izstrāde nepieciešamo SISTĒMAS infrastruktūras elementu papildināšanai vai

pārbūvei:

Esošās infrastruktūras praktiskā apsekošana.

Iepazīšanās ar pieejamo VID dokumentāciju par TLKAIS projekta realizāciju iepriekšējā

periodā.

Iepazīšanās ar pieejamo VAS “Valsts nekustamie īpašumi” un Iekšlietu ministrijas

Nodrošinājuma valsts aģentūras dokumentāciju par MKP infrastruktūras elementiem – ēkām,

teritoriju, komunikācijām.

Objekta zemes īpašumtiesību dokumentācijas precizēšana.

Objekta digitālās topogrāfijas izstrāde visā SISTĒMAS elementu (tajā skaitā kabeļu

kanalizācijas trases, akas utt.) izvietojuma zonā (Imports/Eksports).

Būvprojekta izstrāde atbilstoši Latvijas normatīvajiem aktiem.

Pēc akcepta saņemšanas no VID (jāparedz Būvprojekta pārbaudes posms, ko realizē

Pasūtītājs) vai pēc konstatēto trūkumu novēršanas sagatavot dokumentāciju iesniegšanai

attiecīgās pašvaldības būvvaldei.

Būvniecības laika satiksmes organizācijas plānu Izstrāde, lai organizētu un nodrošinātu drošu

transportlīdzekļu kustību būvdarbu laikā, tiek iesniegts VID kopā ar izstrādāto būvprojektu.

Būvprojekta iesniegšana būvvaldei un atbilstošā saskaņotā Būvprojekta saņemšana.

Ventspilī tiek sagatavoti un iesniegti divi būvprojekti – par objektiem Plosta ielā 7 un Plosta

ielu 20/14.

2. POSMS – Darbu realizācijas posms:

Uzsāk pēc būvatļaujas saņemšanas un veic atbilstoši saskaņotajam Būvprojektam plānoto

izbūves darbu realizācijai:

□ VID centrālā mezgla (Rīga, Talejas iela 1) izveidošana Pasūtītāja datu centra telpās

(esošajās serveru statnēs), nodrošinot:

Serveru un datu glabāšanas iekārtu piegādi;

Sistēmas darbināšanai nepieciešamās programmatūras (kopā ar instalācijas

instrukcijām) piegādi.

□ MKP serveru telpās nepieciešamās infrastruktūras pārbūve (esošās aparatūras

aizvietošana ar jaunu, nepieciešamo elektrobarošanas savienojumu (tajā skaitā arī

pārsprieguma aizsardzības elementu) pārslēgšana vai nomainīšana, nepieciešamo

optikas savienojumu pārslēgšana un lokālā iekārtu savienojuma pārslēgšana). Darbu

veikšana ir jāplāno atvēlētajā un saskaņotajā laikā - orientējoši 5 (piecu) dienu laikā,

taču šie termiņi tiek saskaņoti katrā objektā atsevišķi.. Aparatūru uzstāda VID esošajās

dalītās statnes sekcijā (11U), paredzot tur uzstādīt divus rozešu blokus (PDU) ar

vismaz 6 gab. C13 konektoriem. Vientuļu MKP risinājums tiek izvietots esošajā TLKAIS

42U statnē, bet Atlantijas ielas MKP – esošajā 12U, 600x1000mm statnē, kas ir

izvietota Ostas policijas dežūrtelpā.

□ Elektrobarošanas risinājuma papildināšana, pārbūve vai nomaiņā uz jaunu posmā no

MKP serveru telpās līdz Importa un Eksporta joslām. Savienojumu Importa un

Eksporta joslu tuvumā realizē jaunajā aparatūras skapī, ko uzstāda visu nepieciešamo

41

attēla iegūšanai, satiksmes vadīšanai un transportlīdzekļu kustības kontrolei

nepieciešamo elementu pieslēgšanai.

□ Esošo optisko savienojumu papildināšana, pārbūve vai nomaiņa uz jaunu posmā no

MKP serveru telpās līdz Importa un Eksporta joslām. Savienojumu Importa un

Eksporta joslu tuvumā realizē jaunajā aparatūras skapī.

□ Jauno SISTĒMAS kameru un apgaismojumu elementu uzstādīšana un esošajiem vai

jaunajiem mastiem. Zibens aizsardzības sistēmas izveidošana uz šiem mastiem.

Pieslēgšana pie esošā zemējuma kontūra vai jauna izveide (ja esošā kontūra

pretestība neatbilst minimālajām tehniskajām prasībām).

□ Jauna aparatūras skapja uzstādīšana Importa un Eksporta joslu aprīkojuma

pieslēgšanai. Esošā ass svaru kontrollera pārnešana uz šo aparatūras skapi. Visu

transporta kustības elementu pārnešana (ja tiek izmantoti esošie) vai jaunu

uzstādīšana un pieslēgšana šajā aparatūras skapī. Aparatūras skapja mikrovides

nodrošināšanas elementu (dzesēšana un sildīšana), temperatūras sensoru

uzstādīšana un pieslēgšana kontrolleram, kas nodrošina pieslēgumu VID LAN tīklam

un centralizētā monitoringa iespējas visiem elementiem, kam ir piešķirta IP adrese,

kā arī temperatūras un durvju atvēršanas sensoriem, izmantojot “sauso kontaktu”

pieslēgumus.

□ Smagā transporta kontroles joslās uzstāda papildus mehāniskās drošības elementus

(atdures), lai pasargātu aparatūru uz masta gadījumā, ja transportlīdzekļa durvis nav

nostiprinātas.

Projekta autoruzraudzības darbu realizācija visā būvniecības laikā no būvatļaujas saņemšanas

dienas līdz pieņemšanai ekspluatācijā saskaņā ar Latvijas būvnormatīvu prasībām un

reģionālās būvvaldes akceptēto būvprojektu.

3. POSMS – akcepttestu realizācijas posms:

Izpildītājs sagatavo visu nepieciešamo izpilddokumentāciju.

Tiek veikta dokumentācijas komplektācijas (materiālu īpašību deklarācijas, segto darbu akti,

mērījumu protokoli kabeļiem, zemējuma kontūram utt.) un satura atbilstības pārbaude

realizētajam risinājumam.

Tiek veikti nepieciešami digitālie uzmērījumi infrastruktūras elementu (elektrobarošanas un

optikas kabeļi, kabeļu kanalizācijas akas, kameru balsta masti, citi uzstādītie risinājuma

elementi), kas tiek iestrādāti objekta topogrāfijas informācijā elektroniskā formātā.

Izpildītājs sagatavo risinājuma akcepttestēšanas plānus:

□ Atsevišķo elementu darbības testēšanai (atbilstoši prasībām vai ražotāja noteiktajam).

□ SISTĒMAS darbības kopējam testam, izmantojot testēšanai paredzētus resursus,

piem., definētas specifikācijas transportlīdzekļus utt.

□ Tiek sagatavots testēšanas plāns SISTĒMAS lokālā punkta darbība kopā ar centrālā

punkta infrastruktūru (datu kanālā pietiekamība, datu nodošanas un saņemšanas

pārbaude). Attiecīgi SISTĒMAS centrālajā izvietošanas vietā tiek plānots sistēmas

elementu (lietotnes, datu bāzes, web servera utt.) darbības pārbaude saņemt un

apstrādāt lokālo MKP objektu datus. Papildus tam tiek testēta SISTĒMAS centrālā

mezgla sadarbība ar citām iesaistītājām VID informācijas sistēmām.

□ SISTĒMAS darbības nepārtrauktības testēšanas plāns, pārbaudot visus dublētos un

rezervētos elementus, kā arī imitējot iespējamās avārijas situācijas.

42

Tiek realizēti augstāk minētie testi. Par tiem tiek sagatavoti protokoli, kuros tiek fiksētas

konstatētās neatbilstības vai nepilnības. Pēc trūkumu novēršanas Izpildītājs iesniedz lokālajā

pašvaldības būvvaldē dokumentus saskaņošanai.

4. POSMS – nodotā risinājuma garantijas termiņa (5 gadi) un uzturēšanas darbu nodrošināšana:

Atbilstoši SISTĒMAI definētajai garantijas prasību realizācijai, kas ir iekļauts kopējās SLA

prasībās, tiek nodrošināta SISTĒMAS kā risinājuma un arī atsevišķo tās elementu bojājumu

novēršana garantijas perioda laikā.

Papildus tam, atbilstoši saskaņotajam darbu veikšanas grafikam, tiek veikti arī SISTĒMAS

elementu (gan programmatūras, gan aparatūras) uzturēšanas darbi. Šo darbu regularitāte,

saturs un atskaites forma ir noteikta šajā dokumentā.

KOP-08 SISTĒMAS infrastruktūras izveides aktivitātes MKP un RŠV, kurās TLKAIS infrastruktūra iepriekš nav bijusi izveidota (obligāta)

Infrastruktūras darbu realizācijas ietvaros ir jānodrošina vismaz šādu darbu un aktivitāšu realizācija:

1. POSMS – Būvprojekta izstrāde nepieciešamo SISTĒMAS infrastruktūras elementu izveidei:

Atšķirībā no punktā KOP-07 minētajām prasībām ir saistīta ar to, ka nepieciešams veikt pašas

MKP vai RŠV serveru vai komunikāciju telpas izvērtēšanu, par iespēju tajā izvietot un ienest

(durvju, kāpņu izmēru ierobežojumu dēļ) nepieciešamo aparatūras statni, kā arī RŠV objektu

gadījumā - statnes izvietošanas saskaņošanu ar ēkas īpašnieku – Iekšlietu ministrijas NVA.

Papildus jānodrošina optimālākās elektrobarošanas pieslēguma trases izveide no esošajām

sadalnēm - jāparedz divus (rezervētus) pievadus līdz serveru telpas aparatūras statnei.

Trases no serveru telpas līdz MKP vai RŠV IMP/EXP vietām jāplāno, izbūvējot jaunu kabeļu

kanalizāciju elektrobarošanas un optikas savienojumiem. Jāņem vērā, ka esošajiem objektiem

nav veikti digitālie uzmērījumi un Valsts nekustamie īpašumi rīcībā, kas ir šo objektu

apsaimniekotājs, nav detalizētas un precīzas esošo teritoriju topogrāfijas.

Kameru un apgaismojuma elementu mastus un aparatūras skapjus izvietojumu vietas plāno,

ņemot vērā esošo transportlīdzekļu kustības plānu. Nepieciešamas gadījumā tajā plāno veikt

izmaiņas, ja to akceptē VID, lai nodrošinātu SISTĒMAS prasību realizāciju par definēto TL

reģistrācijas numura atpazīšanas procenta nodrošināšanu.

Uz kameru mastiem uzstāda vairākas papildus videonovērošanas kameras, kam ir jānodrošina

videonovērošana uzstādītā aprīkojuma kontrolei (vandālisms, transportlīdzekļa izraisīta

sadursme utt.). Jānodrošina arī pašu kameru drošības risinājuma realizācija, lai nav iespējams

tuvoties šim aizsargātajam sektoram, neiekļūstot kameru redzes leņķī (Field of View) –

kamerām “jāredz viena otru”. Videonovērošanas risinājumam (Ventspils, Liepājas MKP)

jāparedz iespēju integrēties ar izveidoto VID VNS lokālo serveri, kas izmanto Bosch BVMS

vadības un datu apstrādes risinājumu. Videonovērošanas risinājumam RŠV jānodrošina video

informācijas lokāla saglabāšana un paralēla straumēšana uz VID VNS centrālo mezglu Rīgā,

Talejas ielā 1..

2. POSMS – Darbu realizācijas posms:

Atbilstoši saskaņotajam Būvprojektam plānoto izbūves darbu realizācija tiek realizēta līdzīgi

kā norādīts KOP-07 prasībās, taču šajā gadījumā darbu termiņš nav saistīts ar saskaņojumu

par noteikta laika posma imitāciju (esošā sistēma netiek aizskarta).

43

Jauno objektu gadījumā no jauna tiek izbūvētas kabeļu kanalizācijas trases elektrobarošanas

un vājstrāvas vadiem līdz MKP/RŠV IMP/EXP` vietām (līdz tur novietotajiem aparatūras

skapjiem).

Tiek uzstādīti aparatūras skapji, kuros tiek veikta visas nepieciešamās aparatūras izvietošana.

Tiek uzstādīti kameru masti, kuros uzstāda pašas kameras un apgaismes elementus, izveido

zibensaizsardzības risinājumu.

Izveido zemējuma kontūru ar noteikto minimālo zemējuma kontūra pretestību.

3. POSMS – akcepttestu realizācijas posms:

Šo posms tiek realizēts līdzīgi, kā tas ir norādīts KOP-07 prasībās.

4. POSMS – nodotā risinājuma garantijas termiņa (3 gadi) un uzturēšanas darbu nodrošināšana:

Šis posms tiek realizēts līdzīgi, kā tas ir norādīts KOP-07 prasībās.

KOP-09 SISTĒMAS infrastruktūras ieviešanas secība (obligāta)

SISTĒMAS infrastruktūras darbu realizācijas ietvaros ir jāparedz un jānodrošina šāda darbu un

aktivitāšu realizācijas secība, kas pirms darbu uzsākšanas tiek saskaņota ar Pasūtītāju:

SISTĒMAS centrālās infrastruktūras (Rīga, Talejas iela 1) ieviešana, 1 (viena) vai līdz 5 (piecu)

jauno objekta ieviešana (KOP-08), integrēšana ar esošo TLKAIS, (skat. NEF-27);

SISTĒMAS pārējo jauno objektu ieviešana (KOP-08);

SISTĒMAS esošo objektu pārbūve (KOP-07);

Datu migrācijas nodrošinana no esošas TLKAIS sistēmas centrālās infrastruktūras uz izveidoto

(jauno) SISTĒMAS centrālo infrastruktūru.

KOP-10 SISTĒMAS ieviešanas 1.posms (obligāta)

SISTĒMAS ieviešanas 1.posma rezultātā jānodrošina vismaz šāda prasības (skat. 15.attēlā):

Visiem SISTĒMAS lietotājiem (t.sk. visos MKP un RŠV) nodrošinātas visas Tehniskās

specifikācijas obligātās un Izpildītāja piedāvātās vērtējamās prasības programmatūrai un

Pasūtītāja pasūtītās vēlamās prasības;

Pasūtītāja norādītā 1 (vienā) vai vairākos objektos ir veiktas SISTĒMAS infrastruktūras izveides

aktivitātes;

Caur SISTĒMU ir tiešsaistē pieejami esošajā TLKAIS sistēmā, kura turpina darboties esošajos

objektos, radītie dati;

Caur SISTĒMU ir tieši pieejami un vadāmi esošās TLKAIS sistēmas ass un platformu svari;

SISTĒMĀ ar notikumu tiek sasaistīti platformas svaru un ass svaru rādījumi no visiem

objektiem (attēlā dzeltenas krāsas saites).

44

15.attēls. Kopējā SISTĒMAS un esošās TLKAIS sistēmas mijiedarbība pēc 1.posma ieveiešanas

2.2 SISTĒMAS elementu uzstādīšanas vietas

KOP-11 SISTĒMAS elementu uzstādīšanas vietas (obligāta)

SISTĒMAS elementu plānotās uzstādīšanas vietas ir norādītas 17. tabulā.

17. tabula. SISTĒMAS elementu plānotās uzstādīšanas vietas

Nr.p.k. Uzstādīšanas

objekts

Uzstādīšanas

vieta

Jauna/

esoša

Kravas transporta

joslas

Vieglā transporta

joslas

1. Sistēmas

centrālās

infrastruktūras

objekts

Rīga, Talejas iela 1 esoša nav attiecināms nav attiecināms

2. Vientuļu MKP Vientuļu MKP esoša 2 IMP un 1 EXP josla 1 IMP un 1 EXP

josla

45

Nr.p.k. Uzstādīšanas

objekts

Uzstādīšanas

vieta

Jauna/

esoša

Kravas transporta

joslas

Vieglā transporta

joslas

3. Terehovas

MKP

Terehovas MKP esoša 1 IMP un 1 EXP josla 1 IMP un 1 EXP

josla

4. Grebņevas

MKP

Grebņevas MKP esoša 2 IMP un 1 EXP josla 1 IMP un 1 EXP

josla

5. Pāternieku

MKP

Pāternieku MKP esoša 1 IMP un 1 EXP josla 1 IMP un 1 EXP

josla

6. Silenes MKP Silenes MKP esoša 1 IMP un 1 EXP josla 1 IMP un 1 EXP

josla

7. Rīgas

brīvostas MKP

Kundziņsala, Rīgas

brīvostas MKP

esoša 1 josla (kopējā iebraukšanai un

izbraukšanai)

8. Rīgas

brīvostas MKP

Atlantijas iela 27,

Rīgas brīvostas

MKP

esoša 2 IMP un 2 EXP josla

9. Liepājas MKP Liepājas ostas

teritorija

jauna 1 IMP josla uz Brīvostas ielu un 1 EXP josla

uz Brīvostas ielu

10. Ventspils MKP Ventspils ostas

teritorija

jauna 1 IMP un 1 EXP josla

objektā Plosta ielā

20/14

1 IMP josla un 1

EXP Plosta ielā 7

11. Kaplavas RŠV Kaplavas RŠV jauna nav attiecināms 1 IMP un 1 EXP

josla

12. Meikšānu RŠV Meikšānu RŠV jauna nav attiecināms 1 IMP un 1 EXP

josla

13. Pededzes RŠV Pededzes RŠV jauna nav attiecināms 1 IMP un 1 EXP

josla

Piezīme.

46

3 FUNKCIONĀLĀS PRASĪBAS


identifikācijai, funkcionālās prasības.

3.1 (AIA) Prasības TL attēlu ieguvei un apstrādei

AIA-01 Attēlu ieguve (obligāta)

SISTĒMAI jānodrošina automātiska attēla ieguve:

attēli jātver, jāpārraida un jāsaglabā ciparu formātā;

attēla ieguves laikā var izmantot redzamā vai infrasarkanā diapazona apgaismojumu, bet tas

nedrīkst apžilbināt SISTĒMAS iekārtām garām braucošos TL autovadītājus vai pasažierus;

kameras/ apgaismojuma sistēmai jānodrošina atpazīstamu attēlu iegūšana visos laika

apstākļos (piem., rītausmā, spīdot saulei, saulrietā, naktī, lietus, sniega apstākļos, miglā u.tml.)

(detalizēti skatīt NEF-07 prasībā).

AIA-02 Attēlu apstrāde (obligāta)

SISTĒMAI jāspēj iegūt un apstrādāt transportlīdzekļu un to piekabju attēlus.

SISTĒMAI jāspēj apstrādāt tādu kravas automobiļu/piekabju attēlus, kas aprīkoti ar vismaz 2 (diviem)

konteineriem.

Attēlu apstrādei jābūt pilnīgi automatizētai.

SISTĒMĀ tverto attēlu dati jāsaglabā tādā formātā, lai aizņemtu pēc iespējas mazāk resursu, nemazinot

attēla redzamo kvalitāti (saspiešanas kompresijas pakāpei ir jābūt konfigurējamai) un tos varētu atvērt

arī pēc 11 (vienpadsmit) gadiem.

3.2 (NK) Prasības Notikuma izveidei un aprakstīšanai

SISTĒMĀ

NK-01 Notikuma izveides iniciēšana (obligāta)

Brīdis, kad TL šķērso transportlīdzekļu identifikācijas punktu, uzskatāms par Notikumu TL atpazīšanas

procesa kontekstā. SISTĒMAI jāveic automātiska attēla ieguve, automātiski jāidentificē TL kā atsevišķa

47

vienība, jāfiksē un jāatpazīst TL numura zīmes (t.sk., valsts piederība), kā arī jāvar fiksēt un atpazīt

pārvadāšanai iekrautie konteineri (ja tādi ir) – skaits un katra konteinera numurs (identifikators).

SISTĒMAI jānodrošina ass svaru un platformas svaru svērumu veikšana.

SISTĒMĀ jāizveido Notikuma ieraksts, Notikuma brīdī SISTĒMAI ir jāfiksē šāda informācija:

Notikuma datums un laiks;

Notikuma identifikācijas punkts - MKP/ RŠV un tā valstiskā piederība;

joslas identifikācijas numurs;

TL svara informācija (ja MKP/RŠV ir uzstādīti ass svari) – kravas TL plūsmai;

TL MKP/ RŠV vietā fiksētā ātruma informācija;

attēli – transportlīdzekļa priekšpuses un aizmugures, priekšējo un aizmugurējo numura zīmju,

kravas TL sānu (t.sk. konteineru), konteineru identifikācijas numura kopskata attēls

(konteinera sāna attēls).

NK-02 TL (t.sk., piekabes, konteinera/-ru) numuru atpazīšana (obligāta)

Atpazīšanas procesam jānotiek reālā laika režīmā, t.i., gan numura zīmes, gan konteinera numura

atpazīšana jāveic maksimāli 1 (vienas) sekundes laikā no attēlu ieguves brīža.

SISTĒMAI no Notikuma brīdī iegūtās informācijas jāvar atpazīt:

TL valsts piederība un reģistrācijas numurs;

katra konteinera numurs vai identifikators (ja TL pārvadā konteineri/ konteinerus).

SISTĒMAI jāatpazīst vismaz šādās valstīs izdotas numura zīmes: Albānija, Alžīrija, Armēnija, ASV,

Austrija, Azerbaidžāna, Baltkrievija, Beļģija, Bosnija un Hercegovina, Bulgārija, Čehija, Dānija, Francija,

Gibraltāra, Grieķija, Gruzija, Horvātija, Igaunija, Īrija, Itālija, Kazahstāna, Kirgīzija, Krievija, Kipra, Latvija,

Lielbritānija, Lietuva, Luksemburga, Maķedonija, Moldova, Nīderlande, Norvēģija, Polija, Portugāle,

Rumānija, Serbija, Melnkalne, Slovākija, Slovēnija, Somija, Spānija, Šveice, Tadžikistāna,

Turkmenistāna, Ukraina, Ungārija, Uzbekistāna, Vācija, Zviedrija.

SISTĒMAI jāatpazīst tādas Latvijas Republikā izdotas numura zīmes, kuras aprakstītas [MK_1610

7.pielikumā].

Izstrādātājam garantijas periodā jānodrošina regulāra numura zīmju atpazīšanas algoritma

atjaunināšana (vismaz 1 (vienu) reizi pusgadā).

SISTĒMAI jāspēj identificēt visus standartizmēra konteinerus (20, 40, 45, 20/20 pēdas).

SISTĒMAI jāatpazīst tvertnes tipa un platformas tipa konteineri.

48

SISTĒMAS izstrādes analīzes fāzē nepieciešams precizēt prasību, ņemot vērā piedāvātās SISTĒMAS

iespējas un ierobežojumus, kas ir jāskaņo ar Pasūtītāju.

NK-03 TL citu parametru atpazīšana (vērtējama)

SISTĒMAI jāvar atpazīt TL:

krāsa;

tips;

zīmols;

modelis.

SISTĒMAI jāvar noteikt vieglajā TL esošo pasažieru skaits (vai TL atrodas tikai vadītājs, vai arī vadītājs

un vismaz 1 (viens) pasažieris (vai vairāk)).

NK-04 Kravas TL konteineru citu parametru atpazīšana (obligāta)

SISTĒMAI jāvar atpazīt konteineru numurus saskaņā ar standartu ISO 6346 (ABCD1234567 tips), kā arī

īpašnieku BIC kodu, sērijas numuru un pārbaudes ciparus.

NK-05 Kravas TL konteineru citu parametru atpazīšana (vērtējama)

SISTĒMAI jāvar:

atpazīt kravas TL konteinera plomba;

kravas TL konteineriem noteikt IMO klase (standartizēto bīstamu kravu tipu un grupu

apzīmējumus);

saskaņā ar EN 13044 nodrošināt ILU kodu atpazīšanu.



NK-06 TL ātrums Notikuma brīdī (obligāta)

SISTĒMAI jānodrošina, ka tā spēj identificēt un atpazīt tādus transportlīdzekļus (tai skaitā ar piekabēm

un/ vai konteineriem), kuri šķērso SISTĒMAS darbības zonu ar ātrumu līdz 70 km/h.

NK-07 TL numura neatpazīta simbola apzīmējums (obligāta)

Ja kādu no numura zīmes simboliem SISTĒMA viennozīmīgi nevar atpazīt, tad tā simbola vietā tiek

atrādīts tieši šādam gadījumam paredzēts un SISTĒMAS aprakstošā dokumentācijā atrunāts

apzīmējums.

49

NK-08 Numura (gan TL, gan konteinera) atpazīšanas varbūtības aprēķins (obligāta)

SISTĒMAI automātiski ir jāveic atpazīšanas varbūtības aprēķins pēc SISTĒMAS izstrādes analīzes fāzē

precizētiem kritērijiem. Atpazīšanas aprēķina rezultātam jābūt attēlotam Notikuma ierakstā un

Notikumu pārskatā (sarakstā).

NK-09 Notikuma ieraksts (obligāta)

Katram SISTĒMĀ saglabātajam Notikumam jānodrošina Notikuma ieraksts, kas satur Notikumu

aprakstošu informāciju. Notikuma ierakstam ir jāsatur vismaz šāda informācija:

unikāls Notikuma identifikācijas numurs;


Notikuma valsts;

identifikācijas punkts (MKP/ RŠV);

TL kustības joslas (MKP/ RŠV) identifikācijas nosaukums un virziens;

priekšējo un aizmugurējo numura zīmju un to attiecīgo valstu kodu identifikācijas dati;

uzticamības līmenis visiem konkrētā Notikuma numura zīmju atpazīšanas gadījumiem;

svara informācija (ass svaru dati, platformas svaru dati) – detalizēti aprakstīts prasībā NK-11;

TL identifikācijas punktā fiksētā ātruma informācija;

konteinera identifikācijas numurs (katram konteineram);

konteinera identifikācijas numura atpazīšanas uzticamības līmenis;

pazīme par konteinera esamību;

sasaiste ar Trauksmju ierakstiem;

kravas TL pilns garums (kabīnes un piekabes vai konteinera);

cita SISTĒMAS piedāvāta informācija par TL (piemēram, TL krāsa, TL tips, modelis), kā arī

SISTĒMAS izstrādes analīzes fāzē noteikta informācija, kas saskaņojama ar Pasūtītāju.

Jānodrošina iespēja atvērt un apskatīt šajā Notikumā atpazītā TL vēsturisko Notikumu informāciju.

Notikumam ir jābūt pievienotiem šādiem Notikuma attēliem:

TL priekšpuses attēls (krāsu attēls);

TL aizmugures attēls (krāsu attēls);

TL sānu (ieskaitot kravu/konteinerus) attēls (krāsu attēls);

priekšējās numura zīmes attēls;

aizmugures numura zīmes attēls;

visu TL konteineru identifikācijas numuru attēli;

50

konteineru identifikācijas numura kopskata attēls (konteinera sānu attēls);

piekabē esoša pēdējā konteinera aizmugures attēls.

Katru Notikuma ierakstu lietotājam jāvar apskatīt detaļās, arī attēliem ir jābūt pieejamiem detalizētai

apskatei.

NK-10 Notikuma attēlu apskate (obligāta)

Notikuma attēlu detaļu apskates laikā SISTĒMAI ir jānodrošina iespēja Notikumam veikt vienkāršu

attēla apstrādi - vismaz attēla palielināšanu/ samazināšanu, kontrastu un krāsu maiņu.

NK-11 Notikuma ātruma apskate (obligāta)

Lietotājam SISTĒMĀ jāvar apskatīt Notikuma TL ātruma informācija MKP/ RŠ vietas šķērsošanas brīdī.

NK-12 Notikuma svara apskate (obligāta)

Lietotājam SISTĒMĀ jāvar apskatīt Notikuma TL svara informāciju:

fiksēto TL ass svaru;

fiksēto TL platformas svaru (ja tāds ir pievienots).

SISTĒMĀ jānodrošina un jābūt pieejamai (attēlotai) šādai informācijai par TL svaru:

Ass svaru dati:

□ svaru kompleksa ID numurs;

□ svēruma kārtas numurs;

□ svēruma kopējais svars (kilogramos);

□ asu skaits;

□ svēruma ass svars (no 1 līdz n) - katrs sava ieraksta rindā;

□ svēruma kvalitātes statuss.

Platformas svaru dati:

□ platformas svaru kompleksa ID;

□ platformas svaru kompleksa svērums;

□ svēruma laiks.

SISTĒMAI ir jāvar Notikumam automātiski pievienot platformas svaru informāciju (atbilstoši Notikuma

izpildes/ apstrādes nosacījumiem), kā arī jābūt iespējai informāciju no platformas svariem pieprasīt un

pievienot konkrētajam Notikumam manuāli.

SISTĒMĀ lietotājam jāvar izdrukāt platformas svaru svērumu rezultātus. Izdrukas formā jāparādās

vismaz šādai informācijai:

Izdrukas datums un laiks;

51

Identifikācijas punkta nosaukums vai ID;

Svaru kompleksa ID;

Notikuma svēruma ID;

Notikuma svērums;

Notikuma svēruma datums un laiks.

NK-13 Jauna Notikuma ieraksta manuāla izveide (obligāta)

SISTĒMAI jānodrošina iespēja lietotājam ar atbilstošām tiesībām manuāli izveidot jaunu Notikumu.

Jaunam Notikumam unikālu identifikācijas numuru (Notikuma ID) SISTĒMA piešķir automātiski, bet

lietotājam jābūt iespējai norādīt šādu informāciju:

Notikuma datums un laiks (SISTĒMA automātiski piešķir Notikuma izveides brīdī, bet

lietotājam jāvar nomainīt uz nepieciešamo);

Notikuma valsts;

identifikācijas punkts (MKP/ RŠV);

TL kustības joslas (MKP/ RŠV) identifikācijas nosaukums un virziens;

priekšējo un aizmugurējo numura zīmju un to attiecīgo valstu kodu identifikācijas dati;

TL ātruma informācija;

konteinera identifikācijas numurs (katram konteineram);

norādīt „bez kravas” vai „ar kravu”,

norādīt TL svara informāciju:

□ kravas deklarēto svaru;

□ ass svaru informāciju;

□ platformas svaru informāciju.

sasaiste ar Trauksmju ierakstiem;

kravas transporta pilns garums (kabīnes un piekabes);

pazīme par Notikuma manuālu izveidi;

cita SISTĒMAS piedāvāta informācija par TL (piemēram, TL krāsa, TL tips, modelis), kā arī

SISTĒMAS izstrādes analīzes fāzē noteikta informācija, kas saskaņojama ar Pasūtītāju;

Pēc deklarētā svara norādīšanas, SISTĒMAI automātiski jāaprēķina un jāparāda starpība starp

konstatēto un deklarēto svaru.

NK-14 Notikuma datu lauku rediģēšana (obligāta)

Lietotājam (ar atbilstošām tiesībām) jāvar labot Notikuma informāciju, bet nedrīkst būt iespējai

pievienot attēlus, kā arī labot Notikuma ID.

52

Notikuma ierakstam jābūt pieejamai izmaiņu vēsturei, kas parāda izmaiņu datumus, autorus un tos

datus, kuri tika mainīti.

Rediģējamo lauku saraksts ir jāsaskaņo ar Pasūtītāju SISTĒMAS izstrādes analīzes fāzē.

Rediģēšanas funkcija ir pieejama tikai, ja Notikumam nav aktīva Trauksme.

3.3 (NS) Prasības Notikumu sasaistei

NS-01 TL vēstures datu veidošana (obligāta)

Pēc SISTĒMĀ saglabāta Notikuma datiem, SISTĒMAI jānodrošina identificēta TL kustības vēstures

izveide – sasaiste ar citiem Notikumiem, kam ir identisks, viennozīmīgi atpazīts TL numurs.

NS-02 Konteineru vēstures datu veidošana (obligāta)

Pēc SISTĒMĀ saglabāta Notikuma datiem, SISTĒMAI jānodrošina identificēta konteinera kustības

vēstures izveide – sasaiste ar citiem Notikumiem, kam ir identisks, viennozīmīgi atpazīts konteinera

numurs.

NS-03 TL piekabes vēstures datu veidošana (obligāta)

Pēc SISTĒMĀ saglabāta Notikuma datiem, SISTĒMAI jānodrošina identificētas TL piekabes kustības

vēstures izveide – sasaiste ar citiem Notikumiem, kam ir identisks, viennozīmīgi atpazīts TL piekabes

numurs.

NS-04 Vēstures datu apskate (obligāta)

TL kustības vēstures datiem ir jābūt pieejamiem apskatei gan no Notikuma ieraksta, gan no TL kustības

vēstures saraksta (atskaites).

3.4 (NP) Prasības Notikuma pārbaudei

NP-01 Izveidota Notikuma pārbaude (obligāta)

Jebkuru izveidotu (automātiski vai manuāli) Notikumu (tā fiksētos parametrus) SISTĒMAI jāpārbauda

attiecībā pret izveidotajiem Riska profiliem - ja jaunam Notikumam atbilst kāds Riska profils, tad

SISTĒMAI jāizveido Trauksmes ieraksts.

53

NP-02 Piekļuve ar Notikumu saistītas aktuālās Trauksmes ierakstam (obligāta)

No Notikuma ieraksta, ja SISTĒMA Notikumam ir noteikusi Riska iestāšanās gadījumu (nostrādājusi

Trauksme), jābūt iespējai lietotājam ar atbilstošām piekļuves tiesībām viegli un vienkārši atvērt šim

Notikumam aktuālo Trauksmi.

3.5 (RP) Prasības Riska profila izveidei un pārvaldībai

RP-01 Jauna Riska profila izveide (obligāta)

Lietotājam (ar atbilstošajām tiesībām) jāvar SISTĒMĀ ievadīt informāciju par uzraudzībai pakļautajiem

RŠ Notikumiem – izveidot jaunu Riska profilu.

RP-02 Riska profila izveide (obligāta)

Lietotājam (ar atbilstošajām tiesībām) jāvar izveidot jauns Riska profils, kur jābūt norādāmai/ norādītai

vismaz šādai informācijai:

Riska/ Trauksmes kods – klasificēta informācija;

Riska/ Trauksmes izveidotāja vārds, uzvārds (SISTĒMAI automātiski jānorāda Riska profila

veidotāja informācija pēc lietotāja identifikācijas datiem);

Riska/ Trauksmes izveidotāja kontaktinformācija;

Riska/ Trauksmes identifikācijas punkti;

Riska iestāšanās gadījuma/ aktuālās Trauksmes paziņojuma saturs;

Riska/ Trauksmi aprakstoša informācija;

Riska/ Trauksmes iestāšanās gadījumā veicamo darbību apraksts;

Riska profila darbības periods;

uzraudzības parametri;

Riska/ Trauksmes klasifikācijas pazīmes;

Riska profila statuss;

saņēmēji, saņēmēju grupas.

Detalizēta informācija par katru datu lauku norādīta zemāk prasību veidā.

Visus iepriekš uzskaitītos informācijas laukus, īpaši - uzraudzības parametrus, jāprecizē un jāsaskaņo

ar Pasūtītāju SISTĒMAS izstrādes analīzes fāzē.

54

RP-02.1 Riska / Trauksmes kods (obligāta)

Riska/ Trauksmes kodiem jābūt klasificētiem. Koda norādīšanas brīdī lietotājam jābūt iespējai

izvēlēties kodu no iepriekš definēta saraksta.

SISTĒMAS Trauksmes kodu klasifikatoru jāvar labot lietotājam, kura lomai ir piešķirtas šādas tiesības.

Riska/ Trauksmes kodu klasifikatoram ir jābūt saistītam ar SISTĒMAS lietotāju grupām (atbilstoši

organizācijai/ institūcijai), kā arī noteiktai organizācijai (līdz ar to piekļuvei noteiktam informācijas

apgabalam). Ārējais (citas organizācijas/ institūcijas) SISTĒMAS lietotājs redz tikai savas organizācijas/

institūcijas izveidotos Trauksmju kodus. SISTĒMAS iekšējie (VID) lietotāji atbilstoši lietotāja grupai redz

tikai savus izveidotos Trauksmju kodus.

Riska/ Trauksmes kodu klasifikatoram ir jābūt saistītam ar Trauksmes iestāšanās gadījumā veicamo

darbību klasificēto informāciju.

SISTĒMAS izstrādes analīzes fāzē nepieciešams precizēt Riska/ Trauksmes kodu klasifikācijas struktūru.

RP-02.2 Riska / Trauksmes identifikācijas punkti (obligāta)

Riska/ Trauksmes identifikācijas punkti - tai ir jābūt klasificētai informācijai, kas ir aktuālo MKP/ RŠV

(kuros tiek realizēta uzraudzība) saraksts. Jānodrošina iespēja vienam Riska profilam norādīt vairākas

vērtības. SISTĒMAS lietotājam ar atbilstošajām tiesībām, jāvar papildināt klasificētā informācija.

SISTĒMAS izstrādes analīzes fāzē nepieciešams precizēt Riska/ Trauksmes identifikācijas punktu

sarakstu, kā arī klasifikācijas struktūru.

RP-02.3 Riska iestāšanās gadījuma / Trauksmes paziņojums (obligāta)

Pie konkrētā Riska profila ir jānodrošina iespēja lietotājam norādīt, vai Trauksmes saņēmējs/ saņēmēji

saņems standarta paziņojumu (sms uz mobilo ierīci un/ vai e-pastu) par Riska iestāšanās gadījumu

jeb Trauksmi.

Kā arī jānodrošina iespēja lietotājam norādīt informāciju, ko SISTĒMA nosūtīs paziņojumā (uz mobilo

ierīci un/ vai e-pastu) par Riska iestāšanās gadījumu jeb Trauksmi, tad ja nav atzīmēta standarta

paziņojuma nosūtīšana (vai ir izvēlēta iespēja izveidot pielāgotu paziņojumu).


iespējas un ierobežojumus, kas ir jāsaskaņo ar Pasūtītāju.

55

RP-02.4 Riska iestāšanās gadījuma jeb Trauksmes paziņojuma izveide (vēlama)

Lietotājam (ar atbilstošajām tiesībām) jānodrošina iespēja konfigurēt Trauksmes paziņojumu no

izveidojamā Riska profilā fiksētās informācijas (norādīt tos Riska profilā aizpildītos datu laukus, ko

nepieciešams parādīt paziņojumā), kā arī brīvā tekstā pievienot paziņojuma informāciju (piemēram,

tekstu).

Standarta paziņojumā jāiekļauj vismaz šāda informācija:


Notikuma MKP;

Notikuma ID;

Notikuma TL numuri;

Notikuma konteineru numuri (ja ir);

IMP vai EXP;

Trauksmes ID.

SISTĒMAI ir jānodrošina izveidotā Trauksmes paziņojuma priekšapskate.



RP-02.5 Riska / Trauksmi aprakstoša informācija (obligāta)

Ir jānodrošina iespēja gan lietotājam pievienot konkrētajam Riska profilam atbilstošu Risku/ Trauksmi

aprakstošu informāciju, gan arī SISTĒMAI jāvar parādīt tā informācija, kas par Risku/ Trauksmi ir

pievienota izvēlētajam Riska kodam (klasificētai informācijai).

RP-02.6 Riska / Trauksmes iestāšanās gadījumā veicamās darbības (obligāta)

Riska profilā lietotājam ir jānodrošina iespēja:

ievadīt informāciju par veicamajām darbībām Riska/ Trauksmes iestāšanās gadījumā

(piemēram, fiziskās kontroles piemērošana) brīvā veidā;

izvēlēties darbību scenāriju no klasificētas informācijas saraksta (standartizētas rīcības

scenārijos darbībām jābūt klasificētām), kā arī SISTĒMAI jāvar parādīt tā veicamo darbību

informācija, kas par Risku/ Trauksmi ir pievienota izvēlētajam Riska kodam (klasificētai

informācijai).

SISTĒMĀ ir jāparedz tādi Riska profila izveides gadījumi, kuros nav plānotas veicamās darbības Riska

iestāšanās Trauksmes gadījumā.

56

SISTĒMAS izstrādes analīzes fāzē nepieciešams precizēt Riska/ Trauksmes iestāšanās gadījumā

veicamo darbību klasifikācijas struktūru.

RP-02.7 Riska profila derīguma periods (obligāta)

Lietotājam jāvar norādīt konkrētā Riska profila derīguma periods, kādā tas ir aktīvs - kad SISTĒMAI

pret definēto Riska profilu jāveic ikkatra jauna Notikuma parametru validācija.

RP-02.8 Uzraudzības parametri (meklējamā rinda) (obligāta)

Lietotājam jāvar norādīt parametri, pēc kuriem tiks veikta Riska profila validēšana pret Notikumiem,

piemēram, TL numura zīme, konteinera numurs. Lietotājam jābūt iespējai gan norādīt precīzu

informāciju par uzraudzībai pakļautu parametru, gan arī neprecīzus datus – nezināmos simbolus

aizvietojot ar noteiktu (SISTĒMAS aprakstošajā dokumentācijā atrunātu) apzīmējumu.

SISTĒMAS izstrādes analīzes fāzē nepieciešams precizēt uzraudzības parametru informācijas ievades

principus, loģiku, kā arī lietojamību, ņemot vērā piedāvātās SISTĒMAS iespējas un ierobežojumus, kas

ir jāsaskaņo ar Pasūtītāju.

RP-02.9 Riska profila klasifikācija (obligāta)

SISTĒMĀ izveidotajiem Risku profiliem ir jābūt klasificētiem, piemēram:

pēc pielietojuma veida (vai Trauksmei ir informatīvs raksturs, vai nepieciešama rīcība

Trauksmes gadījumā);

pēc Trauksmes saņēmēju grupām;

pēc izplatības diapazona;

pēc izveidotāja valsts;

pēc darbības perioda.

Lietotājam jāvar norādīt konkrētam Riska profilam atbilstoša klasifikācija.

SISTĒMAS izstrādes analīzes fāzē nepieciešams precizēt risku profilu klasifikāciju, ņemot vērā

piedāvātās SISTĒMAS iespējas, kas ir jāsaskaņo ar Pasūtītāju.

RP-02.10 Riska iestāšanās gadījuma jeb Trauksmes paziņojuma saņēmēji (obligāta)

Lietotājam izveidotajā Riska profilā jāvar norādīt saņēmēji, kas saņems Riska iestāšanās gadījuma jeb

Trauksmes paziņojumu, ir jāvar norādīt vairāki saņēmēji.

Jābūt iespējai gan pievienot informāciju par saņēmēju un saņemšanas veidu (e-pasts, mobilā ierīce)

brīvā formā, gan jābūt iespējai saņēmējus (saņēmēja vārds, uzvārds, kontaktinformācija) pievienot no

klasificētas informācijas saraksta (piemēram, SISTĒMAS lietotāju, lietotāju grupu saraksta).

57

Jāparedz gadījumi, kad vienam Riska profilam būs nepieciešams norādīt abus saņēmēju veidus (gan

brīvas formas, gan klasificēto informāciju).

SISTĒMAS izstrādes analīzes fāzē nepieciešams prasību precizēt.

RP-03 Riska profila labošana (obligāta)

Lietotājam (ar atbilstošajām tiesībām) jāvar labot izveidotā Riska profila informācija.

Riska profilam jābūt pieejamai izmaiņu vēsturei, kas parāda izmaiņu datumus, autorus un tos datus,

kuri tika mainīti.

RP-04 Riska profila statuss (obligāta)

Ja Riska profila derīguma periods nav sācies vai ir beidzies, tad Riska profils ir neaktīvs (citādi – aktīvs).

Riska profilam ir jāsatur informācija par statusu.

Risku profilu pārskatā (sarakstā) neaktīviem Risku profiliem jābūt vizuāli atšķirīgiem no aktīvajiem.

SISTĒMAS izstrādes analīzes fāzē nepieciešams precizēt gan Riska profila statusa nosaukumu, statusa

maiņas nosacījumus, ka arī statusa attēlošanu, ņemot vērā piedāvātās SISTĒMAS iespējas, kas ir

jāsaskaņo ar Pasūtītāju.

3.6 (TR) Prasības Trauksmes ierakstam

TR-01 Trauksmes ieraksta izveide (obligāta)

SISTĒMAI automātiski reālā laika režīmā ir jāizveido Trauksmes ieraksts un jāvar parādīt informācija

par aktuālo Trauksmi gadījumā, kad, validējot Notikuma parametrus pret definētajiem aktīvajiem

Risku profiliem, SISTĒMĀ tiek noteikta sakritība - realizējas Riska iestāšanās gadījums jeb “nostrādā”

Trauksme.

Uz vienu Notikumu var nostrādāt vienlaicīgi vairākas Trauksmes.

TR-02 Trauksmes ieraksta informācija (obligāta)

Trauksmes ierakstam ir jāsatur informācija, kas identificē un raksturo konkrēto Notikumu, identificē

konkrēto Risku profilu (Riska kods) un nosacījumu /-us, pēc kā Trauksme ir “nostrādājusi”, vietu

(Trauksmes identifikācijas punktu), kā arī jābūt fiksētam Trauksmes datumam un laikam.

Lietotājam ir jāredz informācija par veicamajām darbībām (piemēram, muitas kontroles pasākumiem),

kā arī jābūt nosakāmam Trauksmes statusam (piemēram, vai Trauksmes informācija jau ir/ nav

apstiprināta, ir/ nav apstrādāta).

58

Lietotājam ir jāvar ievadīt Trauksmes saņemšanas apstiprinājums un Trauksmes apstrādes informācija.

SISTĒMAI jānodrošina Trauksmes paziņošana Riska profilā norādītajiem saņēmējiem vismaz šādos

veidos:

SISTĒMAS lietotāja saskarnē - viennozīmīgi saprotama informācija par jaunu Trauksmi;

paziņojums par Trauksmi uz Riska profilā norādīto saņēmēja e-pastu;

paziņojums par Trauksmi uz Riska profilā norādīto saņēmēja mobilo telefonu.

TR-03 Trauksmes paziņošana lietotāja saskarnē (obligāta)

Ja SISTĒMĀ “nostrādā” Trauksme un lietotājs ir šīs Trauksmes saņēmējs, tad reālajā laikā jānotiek

lietotāja informēšanai SISTĒMAS lietotāja saskarnē – Trauksmes informācijas ziņojumam jābūt

lietotājam viennozīmīgi saprotamam, piemēram:

lietotājam MKP jāparādās pop-up logam ar Trauksmes un attiecīgā Notikuma informāciju,

paziņojuma logs pat var ierobežot lietotāja iespējamās darbības lietotāja darbstacijā līdz

brīdim, kad Trauksmes paziņojums tiek apstiprināts;

aktuālā Trauksme var būt izcelta citā krāsā Trauksmju sarakstā, Trauksmju saraksts var būt

parādīts SISTĒMAS sākuma lapā, tas var būt kā citādi izcelts.

Pretendents var piedāvāt citus informācijas par jaunu Trauksmi paziņošanas veidus SISTĒMAS lietotāja

saskarnē, bet tiem ir jābūt viennozīmīgi saprotamiem lietotājam, kā arī pēc iespējas jāveicina

nekavējoša rīcība no lietotāja puses (piemēram, bet ne tikai - kavējot citu uz darbstacijas atvērtu

lietojumprogrammu izmatošanu).

TR-04 Trauksmes paziņojuma izveide (obligāta)

SISTĒMAI automātiski līdz ar Trauksmes ierakstu, reālā laika režīmā ir jāizveido arī Trauksmes

paziņojums (ja Riska profilā tika norādīta paziņojuma informācija un saņēmēji).

Lietotājam (ar atbilstošajām tiesībām) jānodrošina iespēja veidot standarta Trauksmes paziņojumus

no Riska profila metadatu laukiem un brīvā tekstā pievienotas informācijas. Paziņojuma saturā jāvar

iekļaut dati no konkrētā Notikuma. Detalizētas prasības paziņojuma izveidei aprakstītas prasībās RP-

02.3 un RP-02.4.


iespējas, kas ir jāsaskaņo ar Pasūtītāju.

TR-05 Trauksmes paziņojuma nosūtīšana (obligāta)

Trauksmes paziņojumu SISTĒMA izveido automātiski no Riska profilā norādītās informācijas un nosūta

automātiski saņēmējam/ saņēmējiem, atbilstoši Riska profilā norādītajam saņemšanas veidam (e-

pasts, mobilais telefons).

59

TR-06 Trauksmes paziņojuma nosūtīšanas loģika (obligāta)

SISTĒMAS izstrādes analīzes fāzē jāveic Trauksmes paziņojumu izsūtīšanas loģikas detalizēta analīze

un aprakstīšana – atbilstoši SISTĒMAS iespējām, bet SISTĒMAI ir jānodrošina vismaz šāds nosacījums

- par Trauksmi, kas nostrādājusi konkrētā identifikācijas punktā (MKP), tiek informēti tikai konkrētā

identifikācijas punkta darbinieki, kaut arī Riska profils ir definēts viens uz vairākiem (var būt pat visiem)

identifikācijas punktiem (MKP).

TR-07 Trauksmes saņemšanas apstiprinājums (obligāta)

Lietotājam SISTĒMĀ jāvar apstiprināt informāciju par Trauksmes saņemšanu.

TR-08 Trauksmes apstrāde (obligāta)

Lietotājam SISTĒMĀ ir jāvar ievadīt Trauksmes apstrādes apstiprinājums – informācija par veiktajām

darbībām (piemēram, muitas kontroles rezultātiem) vai nu izvēloties vērtību no saraksta (klasifikatora),

vai ievadot informāciju brīvā tekstā. SISTĒMAI automātiski jāģenerē apstiprinājuma datums, kam jābūt

saskaņā ar tekošo datumu.

SISTĒMAI jāparedz, ka vairāki lietotāji (piemēram, fiziskā kontroles veicējs, dokumentu pārbaudes

veicējs) var apstrādāt vienu Trauksmi – katram lietotājam ir jāvar ievadīt sava informācija par

Trauksmes apstrādi.

Trauksmes ierakstam jābūt pieejamai izmaiņu vēsturei, kas parāda izmaiņu datumus, autorus un tos

datus, kuri tika mainīti.

Izpildītajam, ņemot vērā piedāvātās SISTĒMAS iespējas, ir jāpiedāvā savs risinājums, kā tiks realizēta

Trauksmes apstrāde, ja izpildē ir iesaistīti vairāki SISTĒMAS lietotāji. Piedāvātais risinājums ir jāsaskaņo

ar Pasūtītāju.

TR-09 Muitas kontroles rezultātu klasifikācija (obligāta)

Muitas kontroles rezultātiem jābūt klasificētiem - rezultātu (kontroles pasākumu) scenāriji tiks

standartizēti.

SISTĒMAS izstrādes analīzes fāzē Pasūtītājs sniegs informāciju - standartizētus rezultātu (kontroles

pasākumu) scenārijus un to aprakstus.

60

3.7 (MFP) Prasības meklēšanai, datu atlasei un filtrēšanai

MFP-01 Prasības meklēšanai (obligāta)

SISTĒMAI jānodrošina informācijas meklēšanas iespējas visās SISTĒMAS funkcionālajās komponentēs,

datu bāzē (Notikumu, Risku profilu, Trauksmju metadatos) un SISTĒMAS auditācijas ierakstos.

SISTĒMAI jānodrošina iespēja meklēt, izmantojot:

ātrās meklēšanas iespēju, ietverot 2 - 3 parametrus;

pilno meklēšanu, ietverot visus definētos metadatus, kur iespējams veikt meklēšanu,

izmantojot:

□ daļu no metadatiem;

□ pilnus vārdus vai vārdu daļas;

□ simbolus izlaistu rakstu zīmju vai simbolu vietā;

□ loģiskos operatorus (piemēram, >,<,=);

SISTĒMAI jānodrošina iespēja saglabāt meklēšanas parametrus, kā arī dzēst iepriekš saglabātos

meklēšanas parametrus. Lietotājam jāvar meklēšanas procesā atkārtoti izmantot saglabātos

parametrus.

SISTĒMAS izstrādes analīzes fāzē nepieciešams precizēt ātrās un pilnās meklēšanas parametrus un

izpildes nosacījumus.

MFP-02 Meklēšanas rezultātu attēlošana (obligāta)

SISTĒMAI jānodrošina meklēšanas rezultātos atlasīto datu attēlošana strukturētos sarakstos.

Meklēšanas rezultātu sarakstos datus ir jāvar kārtot un filtrēt.

SISTĒMAI jānodrošina meklēšanas rezultātos atlasīto datu attēlošana atbilstoši lietotāja tiesībām.

MFP-03 Prasības filtriem (obligāta)

Ikvienā sarakstā jābūt iespējai filtrēt ierakstus pēc jebkura strukturēta lauka, kolonnās norādītajiem

parametriem, kā arī kārtot ierakstus (piemēram, datuma tipa laukam - kārtot rezultātus dilstošā vai

augošā secībā, teksta tipa laukam – kārtot alfabēta secībā u.tml.).

SISTĒMAS izstrādes analīzes fāzē nepieciešams precizēt filtrēšanas parametrus un izpildes

nosacījumus.

61

3.8 (AP) Prasības SISTĒMAS auditācijai

AP-01 Auditācijas pierakstu veikšana (obligāta)

SISTĒMAI jānodrošina iespēja veikt auditācijas pierakstus. Auditācijas funkcijai jābūt konfigurējamai,

lai varētu norādīt, par kādām darbībām jāveic auditācijas pieraksti, un vajadzības gadījumā būtu

iespējams pārtraukt, vai būtiski samazināt auditācijas pierakstu veikšanu.

Auditācijas pieraksti jāuzglabā vismaz „n” mēnešus (kur „n” ir konfigurējams parametrs), pēc tam tos

automātiski dzēšot, pirms dzēšanas nodrošinot iespēju veikt datu arhivēšanu. Auditācijas pierakstu

glabāšanas sākotnējai vērtībai jābūt 60 mēneši.

AP-02 Auditācijas pierakstu uzkrāšana (obligāta)

SISTĒMAI jāspēj reģistrēt paši SISTĒMAS notikumi, piemēram, attēla ieguve, Trauksmes paziņojumi,

kļūdu paziņojumi u.c.

SISTĒMAI jāspēj reģistrēt visu SISTĒMAS lietotāju veiktās darbības SISTĒMĀ, piemēram, pieslēgšanos

pie SISTĒMAS un atslēgšanos no SISTĒMAS (veiksmīgu, neveiksmīgu), katru reģistrēto, laboto un

dzēsto ierakstu, lietotāju ģenerētajām atskaitēm u.c.

SISTĒMAI jānodrošina visu neparedzēto kļūdu (neskaitot paredzēto loģisko validāciju apstrādes laikā

identificētās datu kļūdas) auditācija. Par katru kļūdu jāsaglabā visa pieejamā ar kļūdu saistītā

informācija. Atbilstoši auditācijas pierakstu uzstādījumiem, jānodrošina iespēja nosūtīt ziņojumu par

kļūdu SISTĒMAS administratoram.

Auditācijas pierakstos par vienu darbību jāreģistrē vismaz šāda informācija:

darbības izpildītājs – SISTĒMAS lietotāja vārds;

darbības veids (kāda tieši darbība veikta – dzēšana, rediģēšana, apskate u.c.);

darbības apraksts, kurā jāiekļauj identificējoša informācija: vecā un jaunā informācija;

darbības izpildes laiks.

AP-03 Lietotāja konta informācija (obligāta)

SISTĒMAI jāuzglabā un lietotājam jāvar apskatīt vismaz šādu informācija par lietotāju kontu:

lietotāja vārds;

pievienošanas datums;

piekļuves tiesību izmaiņu veikšanas laiks un raksturs;

piekļuves tiesību slēgšanas datums;

62

cita par lietotāju uzturamā informācija, kas var tikt identificēta SISTĒMAS izstrādes prasību

analīzes fāzē.

AP-04 Darbības ar auditācijas pierakstiem (obligāta)

Lietotājam jāvar eksportēt auditācijas pierakstus Excel XLSX formātā.

SISTĒMAI jānodrošina auditācijas pierakstu arhivēšana un piekļūšana arhivētajiem datiem datu

analīzes vajadzībām (tai skaitā pārnešana uz citiem datu nesējiem).

SISTĒMAI jānodrošina iespēja parsūtīt auditācijas pierakstus pārsūtīšanu uz VID izmantoto datortīkla

drošības pārvaldības risinājumu IBM Security Qradar SIEM.

AP-05 Auditācijas ierakstu filtrēšana (obligāta)

SISTĒMAI jānodrošina iespēja filtrēt SISTĒMAS auditācijas ierakstus ar SISTĒMAS darbībām vismaz pēc

šādiem kritērijiem:

aktivitātes datums un laiks;

SISTĒMAS process;

darbības tips/ raksturs.

SISTĒMAI jānodrošina iespēja filtrēt SISTĒMAS auditācijas ierakstus ar lietotāju darbībām pēc vismaz

šādiem kritērijiem:

aktivitātes datums un laiks,

cita atslēgas vārda, piemēram, lietotāja ID, Notikuma informācija - nepieciešams precizēt

SISTĒMAS izstrādes analīzes fāzē.

3.9 (KZP) Prasības SISTĒMAS kļūdu ziņojumiem

KZP-01 Klasificēta paziņojuma izveide (obligāta)

SISTĒMAI ir jāattēlo klasificēts kļūdas paziņojums (kļūda, brīdinājums, informācija) ar detalizētu

aprakstu un iespējamām turpmākām darbībām. Kļūdu paziņojumā jābūt lietotājam saprotamai

informācijai par problēmu un turpmākajām darbībām, kas jāveic.

KZP-02 Kļūdas paziņojuma izplatīšana (obligāta)

Kļūdas situācijās SISTĒMAI administratoram jāparāda nepieciešamā informācija e-pastā (vai tālrunī kā

īsziņu), jānosūta detalizēta tehniskā informācija SISTĒMAS administratoram no paša nodefinētas

SISTĒMAS daļas, kā arī jāveic informācijas ierakstīšana SISTĒMAS auditācijas pierakstos.

63

KZP-03 Kļūdas paziņojums par infrastruktūras elementu (obligāta)

Jebkuru SISTĒMAS infrastruktūras elementu, kas pieslēgti pie datortīkla (piem., kameras, kontrollers,

energoapgādes iekārtas utt.) problēmu gadījumā, SISTĒMAI jāģenerē brīdinājuma ziņojums un

jānosūta uz centrālo monitoringu. Kļūmīgās transakcijas jāuzkrāj un atkārtoti jāapstrādā pēc

savienojuma atjaunošanas.

KZP-04 Kļūdas paziņojums par sensoriem (obligāta)

SISTĒMAI jāizveido kļūdas paziņojums, ja nav iespējams iegūt informāciju no MKP/ RŠV sensoriem

(kamerām, svariem).

3.10 (ADMP) Prasības SISTĒMAS administrēšanai

ADMP-01 SISTĒMAS administratora tiesības (obligāta)

SISTĒMAS administratoram jāvar veikt lietotāju tiesību administrēšana, SISTĒMAS klasifikatoru

uzturēšana un dažādu citu SISTĒMAS parametru administrēšana. SISTĒMAS administrēšanu jāvar veikt

no administratora moduļa lietotāja saskarnes tā, lai nebūtu nepieciešams programmatūras izejas koda

izmaiņas un jaunas programmatūras versijas uzstādīšana.

Prasība jāprecizē un jāsaskaņo ar Pasūtītāju SISTĒMAS izstrādes analīzes fāzē atbilstoši SISTĒMAS

iespējām.

ADMP-02 Klasifikatoru pārvaldība (obligāta)

SISTEMAI jāļauj lietotājam papildināt/ mainīt visu SISTĒMAS klasifikatoru (t.sk. Notikuma valsts,

Notikuma identifikācijas punkta (MKP/ RŠV) un TL kustības joslas klasifikatoru) vērtības, šai funkcijai

ir jābūt pieejamai lietotājam ar noteiktām pieejas tiesībām. Par katru klasifikatora izmaiņu jāsaglabā

atbilstošs auditācijas pieraksts.

ADMP-03 Trauksmju administrēšana (obligāta)

Risku profilu (Trauksmju nosacījumu) un Trauksmju administrēšanas iespējām jābūt noteiktām

atbilstoši lietotāja lomai.

ADMP-04 SISTĒMAS darbības stāvokļa pārraudzība (obligāta)

SISTĒMAI draudzīgā veidā ir jānodrošina administratoriem iespēju pārraudzīt SISTĒMAS darbības

stāvokli (kļūdas paziņojumi, SISTĒMAS procesu izpildes stāvoklis, SISTĒMAS noslodzes rādītāji,

kļūdaini atpazīto attēlu statistika).

64

ADMP-05 SISTĒMAS MKP/ RŠV saraksta administrēšana (obligāta)

SISTĒMAS lietotājam ar atbilstošām tiesībām jāvar pārvaldīt SISTĒMAS MKP/ RŠV sarakstu

(klasifikatoru):

apskatīt esošos;

pievienot jaunu;

rediģēt esošu;

atspējot esošu.

SISTĒMAS MKP/ RŠV sarakstu (klasifikatoru) lietotājam ar atbilstošām tiesībām jāvar pārvaldīt, lai

nebūtu nepieciešams programmatūras izejas koda izmaiņas un jaunas programmatūras versijas

uzstādīšana.

ADMP-06 Organizatorisko vienību (struktūras) administrēšana (obligāta)

SISTĒMAS lietotājiem ar atbilstošām tiesībām jāvar pārvaldīt (izveidot, apskatīt, labot vai arhivēt):

lietotājus;

struktūrvienības;

institūcijas (organizācijas).

3.11 (LTP) Lietotāju tiesību pārvaldība

LTP-01 Lietotājs organizācijas ietvarā (obligāta)

Lietotāju jāvar piesaistīt vienai organizācijai un vienai organizācijas struktūrvienībai (skat. 16. attēlu).

Lietotāju tiesību pārvaldībai un SISTĒMAS arhitektūrai ir jābūt tādai, lai SISTĒMU varētu izmantot arī

citas (ne VID) organizācijas, nodrošinot lietotāju dalījumu pēc organizāciju specificētiem informācijas

apgabaliem (biznesa datiem) SISTĒMĀ, proti, ir jānodrošina pilnībā neatkarīga tās informācijas ievade

un pārvaldība katras organizācijas ietvarā, ko veic SISTĒMAS lietotājs atbilstoši lietotāja piederībai

konkrētai organizācijai. Katrai organizācijai atsevišķi tiek veidotas lomas un lietotāju grupas.

65

16. attēls. Lietotāja tiesību pārvaldība

LTP-02 Lietotāju tiesību un lomu administrēšana (obligāta)

Lietotājam SISTĒMAS funkcionalitātei jābūt pieejamai atkarībā no lietotājam piešķirtās lomas un tai

piesaistītajām tiesībām (tiesības nosaka, kādas ekrānformas un kādas darbības būs pieejamas

lietotājam) (skat. 16. attēlu). Sistēmā jāvar veidot lietotāju grupas ar dažādām lomām, pamatojoties

uz lietotāju tiesībām. Lietotāju grupai jāvar norādīt tai pieejamos identifikācijas punktus.

SISTĒMAS izstrādes analīzes laikā nepieciešams precizēt un saskaņot ar Pasūtītāju SISTĒMĀ pieejamās

tiesības, lomas un lietotāju grupas.

LTP-03 Lietotāju tiesības uz Riska profilu informāciju (obligāta)

SISTĒMĀ jābūt stingri ierobežotām iespējām administrēt definētos Risku profilus, rediģēt, apskatīt,

izveidot un dzēst datus. Jānodrošina, lai atsevišķas lietotāju grupas varētu rīkoties neatkarīgi, un to

apstrādātā informācija nebūtu pieejama citām lietotāju grupām.

LTP-04 Jauna SISTĒMAS lietotāja izveide (obligāta)

Veidojot jaunu SISTĒMAS lietotāju, lietotājam, ar atbilstošām (piemēram, administrēšanas vai lietotāju

pārvaldības) tiesībām, jāievada un jāpārvalda vismaz šāda informācija:

lietotāja vārds, uzvārds;

66

organizatoriskā piederība (t.sk. piederība organizācijas struktūrai);

kontaktinformācija un komunikācijas kanāli.

SISTĒMAS izstrādes analīzes laikā nepieciešams precizēt prasību, ņemot vērā SISTĒMAS iespējas, kas

jāsaskaņo ar Pasūtītāju.

LTP-05 Tiesību atslēgšana (obligāta)

SISTĒMĀ lietotājam ar atbilstošām tiesībām jāvar atslēgt kāda tiesība.

3.12 (INP) Prasības integrācijai ar citām IS

INP-01 Integrācija ar citām IS (obligāta)

Izpildītājam jānodrošina SISTĒMAS datu integrācija ar citām informācijas sistēmām (t.sk. ārējām IS)

saskaņā ar detalizētajām prasībām, pārliecinoties par IS integrācijas pilnvērtīgu, atbilstošu un drošu

darbību.

INP-02 Integrācija ar VID ISS (obligāta)

Integrācijā ar citām IS SISTĒMAI ir jāizmanto VID informācijas sistēmu savietotājs (VID ISS), kas ir uz

servisu orientētas arhitektūras principiem balstīta integrācijas platforma. VID ISS ir veidots, par

pamatu izmantojot Oracle SOA Suite standartproduktus.

Izejošās datu apmaiņas saskarnes veidojamas kā VID ISS izvietojami tīmekļa pakalpojumi, kam ir

jāatbilst VID ISS tīmekļa pakalpojumu izstrādes vadlīnijām. Ienākošās datu apmaiņas saskarnes

veidojamas, izmantojot VID ISS izmitinātos trešo sistēmu tīmekļa pakalpojumus.

Ja veiktspējas vai citu apsvērumu dēļ kādai no paredzētajām datu apmaiņas saskarnēm tīmekļa

pakalpes nav piemērotākais risinājums, izstrādes gaitā Izpildītājs drīkst ieteikt citu alternatīvu

risinājumu. Šādā gadījumā Izpildītājam ir detalizēti jāapraksta piedāvātais alternatīvais risinājums, kā

arī jānorāda tā priekšrocības un trūkumi salīdzinājumā ar datu nodošanu, izmantojot tīmekļa pakalpes.

Pasūtītājs patur tiesības alternatīvo risinājumu noraidīt.

INP-03 Integrācija ar VID datu noliktavu (obligāta)

SISTĒMAI vismaz 1 (vienu) reizi dienā ir jānodrošina datu (gan biznesa datu, gan auditācijas datu)

nodošana VID datu noliktavas sistēmai (VID DNS). SISTĒMAS izstrādes analīzes laikā nepieciešams

precizēt prasību (datu nodošanas formātu, procesu, datu apjomus, un citus apstākļus).

67

INP-04 Integrācija ar ārējām IS (obligāta)

SISTĒMAI jānodrošina datu apmaiņa ar citām ārējām informācijas sistēmām, realizējot gan Notikumu,

gan Riska profilu informācijas un Trauksmju datu apmaiņu.

Ir plānots, ka citu Latvijas institūciju (organizāciju) IS saņems datus no SISTĒMAS, izmantojot VID ISS.

Savukārt datu apmaiņa ar Lietuvas, Igaunijas un Polijas specializētajām muitas/ robežas šķērsošanas

kontroles un uzraudzības informācijas sistēmām ir jārealizē, izmantojot jau esošo metodi (datu

apmaiņa notiek XML formātā, izmantot FTP serveri). Papildus Pretendentam ir jāizvērtē un jāpiedāvā

iespēja šīs datu apmaiņas realizēt caur VID ISS, kā arī Pretendents var piedāvāt citas metodes -

atbilstoši piedāvātajā SISTĒMĀ realizētajām/ realizējamām iespējām.

Ar datu apmaiņas realizācijā nodrošināmajām datu struktūrām Pretendents var iepazīties Pasūtītāja

telpās, iepriekš piesakoties un vienojoties.

SISTĒMAS izstrādes analīzes laikā nepieciešams precizēt datu apmaiņas ātrdarbības un veiktspējas

prasības.

INP-05 LT, EE vai PL specializēto muitas IS datu apmaiņa – Notikumu datu saņemšana (obligāta)

Notikumu informācijas plūsma - SISTĒMAI jāsaņem Igaunijas, Lietuvas un Polijas muitas kontroles

punktos/ robežas šķērsošanas vietās izveidotie Notikumi - TL un konteineru identifikācijas dati.

SISTĒMĀ jāvar gadā importēt vismaz 20 miljoni ierakstu no Igaunijas, Lietuvas un Polijas muitas

kontroles IS.

INP-06 LT, EE vai PL specializēto muitas IS datu apmaiņa – Notikuma attēlu saņemšana pēc pieprasījuma (obligāta)

SISTĒMĀ jāvar saņemt Notikumu attēlu no LT, EE vai PL specializētas muitas IS pēc atsevišķa

pieprasījuma.

Ja attēli vienreiz ir pieprasīti un ielādēti SISTĒMĀ, SISTĒMAI tie jāpiesaista Notikumam un jāsaglabā

DB.

INP-07 LT, EE vai PL specializēto muitas IS datu apmaiņa – Notikumu datu nodošana (obligāta)

SISTĒMAI jānodod Latvijas muitas kontroles punktos/ robežas šķērsošanas vietās izveidotie Notikumi

uz Lietuvas, Igaunijas un Polijas specializētajām muitas/ robežas šķērsošanas kontroles un uzraudzības

informācijas sistēmām, izmantojot esošo metodi - datu apmaiņu XML servisu līmenī, kā arī jābūt

nodrošinātai iespējai šo datu apmaiņu realizēt caur VID ISS.

68

INP-08 LT, EE vai PL specializēto muitas IS datu apmaiņa – Riska profilu informācijas plūsma (obligāta)

Riska profilu informācijas plūsma - riska profilu izveidošanai ir jābūt koordinētai, piemēram, kā esošajā

situācijā - izmantojot NCP datu validēšanai un informācijas precizēšanai (t.sk. tulkošanai), tomēr

Pretendents var piedāvāt savu risinājumu risku vadības informācijas apmaiņai starp iesaistītajām

Partneru sistēmām.

Riska profiliem jābūt dublētiem tajās iesaistīto Partneru sistēmās, kuras skar konkrētā riska profila

definētos parametrus (piemēram, Trauksmes identifikācija punkta piederības valsts, Trauksmes

saņēmēja grupas piederība).

INP-09 LT, EE vai PL specializēto muitas IS datu apmaiņa – Trauksmju datu plūsma (obligāta)

Trauksmju datu plūsma - SISTĒMAI jāsaņem no Igaunijas, Lietuvas un Polijas specializētajām muitas/

robežas šķērsošanas kontroles un uzraudzības informācijas sistēmās “nostrādājušo” Trauksmju, kurām

Risku profili definēti SISTĒMĀ, informācija. SISTĒMAI jānodod Latvijas muitas kontroles punktos/

robežas šķērsošanas vietās “nostrādājušo” Trauksmju, kurām risku profili definēti Igaunijas, Lietuvas

un Polijas specializētajām muitas/ robežas šķērsošanas kontroles un uzraudzības informācijas

sistēmās – atbilstošai (ierosinātāja) IS.

3.13 (ATP) Prasības atskaitēm

ATP-01 SISTĒMĀ pieejamās atskaites (obligāta)

SISTĒMĀ ir jāparedz iespēja lietotājiem (ar atbilstošām tiesībām) izgūt šādas atskaites:

Atskaite par SISTĒMAS komponenšu nepieejamības laikiem noteiktā laika periodā;

Atskaite par nostrādājušajām un nenostrādājušajām trauksmēm;

Atskaite par SISTĒMAS TL un konteineru numuru atpazīšanas precizitāti;

Atskaite, kuru izmantojot Pasūtītājs veiks SISTĒMAS TL un konteineru numuru atpazīšanas

precizitātes pārbaudi. Atskaitē jāietver vismaz šāda informācija:

□ Identifikācijas punkta nosaukums;

□ Identifikācijas josla;

□ atskaitē ietverto Notikumu laika periods;

□ 50 secīgu Notikumu ID

□ Notikuma datums un laiks;

□ Notikuma fiksētais ātrums;

□ katra Notikuma priekšējais un aizmugurējais attēls;

69

□ Notikuma atpazītie TL numuri;

□ Notikuma atpazītie konteineru numuri;

□ SISTĒMAS atzīme, vai Notikums ir atpazīts vai neatpazīts;

□ iespēja lietotājam atzīmēt, vai SISTĒMAS atpazīšana ir precīza (ņemot vērā NEF-07

prasībā minētos gadījumus, kurus atskaitē neiekļauj)

□ iespēja pievienot komentārus.

u.c. līdz 5 (piecām) citām SISTĒMAS izstrādes laikā Pasūtītāja definētām atskaitēm.

SISTĒMAS izstrādes analīzes laikā Izpildītājam jāsaskaņo ar Pasūtītāju atskaišu formas, parametrus un

citas atskaišu detaļas.

ATP-02 Darbības ar atskaitēm (obligāta)

Visas atskaites jāvar saglabāt lietotāja darbstacijas cietajā diskā *.XLSX un *.PDF formātos, kā arī

izdrukāt.

ATP-03 Datu izguves lietotāja saskarne (obligāta)

SISTĒMĀ jābūt pieejamai lokālā vaicājuma lietotāja saskarnei, lai to varētu izmantot statistikas un

ekspluatācijas vajadzībām datu izguvei. Iespējai jābūt pieejamai SISTĒMAS administratoriem.

3.14 (DP) Prasības datu plūsmai, apmaiņai un glabāšanai

DP-01 Datu plūsma (obligāta)

Datu plūsmas pārtraukuma gadījumā informācija par RŠ Notikumiem uz laiku līdz 3 (trīs) nedēļām

jāsaglabā lokāli (MKP/ RŠV). Pēc savienojuma atjaunošanas informācija par Notikumiem jāsaglabā

SISTĒMĀ centrāli, t.i. jānodrošina zero-data-loss principa ievērošana.

DP-02 Datu apmaiņa (obligāta)

Datu apmaiņai jānodrošina datu apmaiņas automātiskās kontroles, saskaņā ar labāko praksi

(piemēram, rekonsilācija pēc ierakstu skaita, kopsummām u.tml.).

DP-03 Datu glabāšana (obligāta)

SISTĒMAS dati jāsaglabā uz lokālā servera datubāzē, ka arī nekavējoties jānosūta uz centralizēto

servera datubāzi.

Datus gan lokālajā, gan centrālajā DB jāuzglabā vismaz „n” mēnešus (kur „n” ir konfigurējams

parametrs), pēc tam tos automātiski dzēšot, pirms dzēšanas nodrošinot iespēju veikt datu arhivēšanu.

SISTĒMĀ jābūt iespējai Notikuma datiem un attēliem glabāšanas laiku noteikt atšķirīgu, t.i.

jānodrošina atšķirīgi glabāšanas laika konfigurācijas parametri.

70

Notikuma datu un attēlu glabāšanas laikus ir jābūt atsevišķi konfigurējamam parametram, t.i.,

SISTĒMĀ Notikumu datu glabāšanas laikam būs viens parametrs, attēlu glabāšanas laikam – cits.

3.15 (IDK) Prasības ievadīto datu kontrolēm

IDK-01 Datu lauku validācija (obligāta)

Sintaktiskās kontroles jāveido kā ievadlauku validācija tiem datu ievadlaukiem, kuros paredzēts ievadīt

noteikta formāta datus, piemēram, datuma ievadlaukā ievadāmajiem datiem jābūt atbilstošiem

SISTĒMĀ konfigurētam datuma formātam. Līdzīgi, jākontrolē, lai datu ievadlaukos, kas paredzēti

skaitliskiem datiem, tiktu ierobežotas iespējas ievadīt citus simbolus.

Lai uzlabotu ievadīto datu korektumu, visās vietās, kur iespējams, jāizmanto izvēle no sarakstiem,

klasifikatoriem, nevis brīva teksta ievade.

SISTĒMAI jāspēj veikt vismaz šādas SISTĒMAS ievaddatu pārbaudes:

attēla formāta atbilstība (tips, izmērs);

jauna identificēšanas gadījuma (Notikuma) atbilstība jau esošam identificēšanas gadījumam

(Notikumam) gan lokālajā, gan centrālajā datu bāzē;

laika ievaddatu korektuma pārbaude;

konteinera numura ievaddatu korektuma pārbaude;

transportlīdzekļa numura ievaddatu korektuma pārbaude.

IDK-02 Loģiskās kontroles (obligāta)

SISTĒMAI datu saglabāšanas brīdī jāveic atbilstošas loģiskās kontroles, piemēram, ievadot intervālu ar

diviem datumiem, SISTĒMAI jāpārbauda, vai norādītā intervāla sākuma datums un laiks ir agrāki par

intervāla beigu datumu un laiku. SISTĒMAS loģiskās kontroles jāparedz maksimāli parametrizējamas,

t.i., SISTĒMĀ jābūt iespējai uzstādīt loģiskās kontroles parametrus, lai nebūtu nepieciešamas

programmatūras izejas koda izmaiņas un jaunas programmatūras versijas uzstādīšana.



71

3.16 (CIT) Citas prasības

CIT-01 Datu eksports (obligāta)

Visos lietotāja saskarnes ekrānos redzamos datus (sarakstus vai konkrētu saraksta rindu, rindas

detaļas) jāvar izdrukāt, saglabāt datus PDF un Excel XLSX formātos.

72

4 INFRASTRUKTŪRAS PRASĪBAS

Šajā nodaļā ir aprakstīts risinājums, kas paredzēts TL un konteineru numuru automātiskai

identifikācijai, infrastruktūras prasības.

4.1 (IVP) Infrastruktūras vispārīgās prasības

IVP-01 SISTĒMAS uzstādīšanas vietas (obligāta)

SISTĒMAS infrastruktūras ieviešanas ietvaros ir paredzētas šādas uzstādīšanas vietās (skat. 18. tabulā).

18. tabula. Plānotās Sistēmas elementu uzstādīšanas vietas

Nr. p.k. Vieta Statuss Esoša vai jauna

uzstādīšanas vieta

Komentāri

1. Terehovas MKP MKP Esošā

2. Kundziņsala,

Rīgas brīvostas

MKP

MKP Esošā Ir tikai viena, kopēja josla TL kustībai

IMP un EXP virzienos

3. Atlantijas iela 27

(Birztalu iela),

Rīgas brīvostas

MKP

MKP Esošā + Jaunā

4. Grebņevas MKP MKP Esošā

5. Pāternieku MKP MKP Esošā

6. Silenes MKP MKP Esošā

7. Vientuļu MKP MKP Esošā

8. Liepājas MKP MKP Jaunā

9. Ventspils MKP MKP Jaunā

9.1 Plosta ielā 7

9.2 Plosta ielā 20/14

10. Kaplavas RŠV RŠV Jaunā

73

Nr. p.k. Vieta Statuss Esoša vai jauna

uzstādīšanas vieta

Komentāri

11. Meikšānu RŠV RŠV Jaunā

12. Pededzes RŠV RŠV Jaunā

SISTĒMAS elementu infrastruktūras raksturojums ir norādīts 19. tabulā.

74

19. tabula. Plānotās SISTĒMAS uzstādīšanas vietas tehnoloģiskais raksturojums

Nr.p.k. Vieta Kravas /

vieglie TL

Joslu

skaits

(EXP/ IMP)

Nep.

jauna

josla

Ass

svaru

skaits

Modelis Platformas

svaru

skaits

Modelis Komentāri

1. Terehovas MKP Kravas un

vieglie

2/2 2 Avery Weigh-

Tronix

Supaweigh 4000

2 Mettler-

Toledo IND

560/560x

2. Kundziņsala, Rīgas

brīvostas MKP

Kravas 2 1 Avery Weigh-

Tronix

Supaweigh 5000

1 Mettler-

Toledo IND

560/560x

3. Atlantijas iela 27,

Rīgas brīvostas

MKP

Kravas 2 2(1 EXP,

1 IMP)

_ _ _

4. Grebņevas MKP Kravas un

vieglie

3/2 1 (EXP) 3 Avery Weigh-

Tronix

Supaweigh 5000c

2 Mettler-

Toledo IND

560/560x un

IND 310

Platformas svari IND

310 nav sasaistīti ar

esošo TLKAIS sistēmu.

Ir 3 ass svari, tomēr tie

nestrādā.

1 no joslām (EXP) nav

aprīkota ar esošo

TLKAIS sistēmu.

75

Nr.p.k. Vieta Kravas /

vieglie TL

Joslu

skaits

(EXP/ IMP)

Nep.

jauna

josla

Ass

svaru

skaits

Modelis Platformas

svaru

skaits

Modelis Komentāri

5. Pāternieku MKP Kravas un

vieglie

2/2 2 Avery Weigh-

Tronix

Supaweigh 4000

1 Mettler-

Toledo IND

560/560x

6. Silenes MKP Kravas un

vieglie

2/2 2 Avery Weigh-

Tronix

Supaweigh 4000

1 Mettler-

Toledo IND

560/560x

7. Vientuļu MKP Kravas un

vieglie

3/2 3 Avery Weigh-

Tronix

Supaweigh

5000

1 Mettler-

Toledo IND

560/560x

8. Liepājas MKP Kravas 1/1 _ _ 1 Mettler-

Toledo IND

560/560x

9. Ventspils MKP Kravas un

vieglie

2/2 _ _ 1 Mettler-

Toledo IND

560/560x

76

IVP-02 SISTĒMAS infrastruktūras minimālās tehnoloģiskās komponentes (obligāta)

SISTĒMAS infrastruktūras elementus jāplāno atbilstoši šādai infrastruktūras izvietošanas topoloģijai:

MKP serveru telpā tiek izvietoti serveri, datu glabāšanas iekārtas, komutatori, konvertori utt.

No serveru telpas UPS iekārtas tiek nodrošināta arī abās TL pusēs (Importa un Eksporta)

izvietotās tehnoloģiskā aprīkojuma nepārtrauktās elektrobarošanas nodrošināšana. MKP

serveru telpā tiek nodrošināts arī savienojums LAN tīkla segmenta veidā ar MKP platformas

svariem.

MKP serveru telpā (izņemot 19. tabulā norādītās trīs RŠV un Vientuļu MKP) ir paredzēta

nodalīta (ar atsevišķu atslēgu) 11U vieta esošajās aparatūras statnēs. SISTEMAS ieviešanas

brīdī tajā atradīsies esošā TLKAIS risinājuma elementi, kurus iespējams pārizmantot vai pilnībā

nomainīt. Vientuļu MKP TLKAIS aparatūra ir uzstādīta pilna augstuma 42U statnē. Atlantijas

ielas MKP (Rīgas Brīvosta) aparatūra ir izvietota 12U, 600x1000m aparatūras statnē.

TL braukšanas pusēs (Importa un Eksporta) tehnoloģiskais aprīkojums ir izvietots āra

aparatūras skapī un uz vairākiem mastiem (attēlu iegūšanas kameras un apgaismojuma

elementi).

tiešā tuvumā asfalta segumā ir iestrādāti un iebūvēti TL kustības detektēšanas sensori un/vai

tiek izmantoti attāluma lāzermērītājs.

RŠV (Kaplavas, Meikšānu un Pededzes), kurās tiek ierīkota jauna infrastruktūra, jāuzstāda

jauna slēdzama aparatūras statne (vismaz 22U, perforētas metāla durvis priekšā un

aizmugurē, 600x1000mm) esošajās Robežsardzes komunikāciju telpās. Aparatūras statnes

stiprināšana jāsaskaņo katrā objektā atsevišķi, taču ir jāparedz arī risinājums ar tās

piestiprināšanai pie telpas sienas (ja nav brīvas vietas novietošanai uz grīdas).

IVP-03 SISTĒMAS esošās atbalsta infrastruktūras izmantošanas iespējas (obligāta)

Plānojot esošā MKP infrastruktūras pārbūves darbus, tiek pieļauts, ka MKP esošās SISTĒMAS darbība

varētu tikt apturēta līdz 5 (piecām) dienām pārslēgšanas un konfigurācijas darbu veikšanai.

Esošos savienojošos elektrobarošanas kabeļus un optikas kabeļus no MKP serveru telpas līdz joslu

zonā izvietotajiem sadalnes skapjiem var izmantot SISTĒMAS elementu pieslēgšanai, ja to tehniskie

parametri ir atbilstoši jaunā risinājuma prasībām.

Var tikt izmantoti arī transporta joslās iestrādātie kustības sensori (cilpas).

Var tikt izmantoti arī esošie kameru stiprināšanas masti, ja to izvietojums ir atbilstošs jaunā risinājuma

elementu izmantošanai.

Pieļaujams izmantot esošo zemējumu kontūrus Importa un Eksporta joslu tuvumā, ja to zemējuma

pretestība nepārsniedz 10 (desmit) omus.

77

IVP-04 SISTĒMAS infrastruktūras komponentes – izvietotās MKP serveru telpās - minimālās tehniskās prasības (obligāta)

SISTĒMAS centrālās daļas (kas paredzēta datu savākšanai un apstrādei) infrastruktūra ietver visu

aparatūru un programmatūru, kas vajadzīga transportlīdzekļu attēlu tveršanai/pārvaldībai. Jāparedz

vismaz šāds aprīkojums:

1. serveris/serveri (ar Windows vai Linux operētājsistēmu, datu bāzi) ar attēlu apstrādes risinājumu,

nepieciešamo programmatūru un lokālo datu bāzi. Uz šī servera jāparedz resursi (skaitļošanas jaudas,

operatīvā atmiņā, vieta uz vietā diska) arī SISTĒMĀ integrējamo platformas un ass svaru servera

programmatūras uzstādīšanai, jā tāda nepieciešama.. Servera un Sistēmas antivīrusa programmatūru

un antivīrusa licenču uzturēšana jānodrošina Izpildītājam. SISTĒMAS programmatūrai jānodrošina arī

saņemto/ienākošo datņu apstrāde (piemēram, XML failu no citām valstīm) pret ļaundabīgo kodu un

vīrusiem.

2. komutatori kameru un cita aprīkojuma pieslēgšanai kopējā LAN segmentā;

3. optiskais kabelis visu kameru un cita aprīkojuma pie transporta joslām saslēgšanai ar serveri;

4. elektrobarošanas kabelis visu kameru un cita aprīkojuma saslēgšanai ar centralizēto UPS;

5. centralizētais UPS visu SISTĒMAS elementu bez pārtraukuma risinājuma nodrošināšanai, kura jauda

paredzēta visu pieslēgto elementu vismaz 10 (desmit) minūšu darbības autonomijas nodrošināšana.

6. Elektrobarošanas pieslēgšanas sadalne ar atbilstošiem pārsprieguma aizsardzības elementiem.

7. Triju RŠV serveru/komunikāciju telpās arī ir jāuzstāda nepieciešamais videonovērošanas sistēmas

serveris, kas apstrādā un uzkrāj datus no lokālajām videonovērošanas kamerām, kas nodrošina

SISTĒMAS aparatūras videonovērošanu (aizsardzībai pret vandālismu vai citiem bojājumiem).

Serverim jābūt savietojamiem un uz tiem jāuzstāda nepieciešamais programmnodrošinājums, lai to

būtu iespējams ieslēgt izveidotajā VID centralizētājā videonovērošanas risinājumā, kas videokameru

vadībai izmanto Bosch BVMS sistēmu. Jāizmanto tikai IP tehnoloģijas kameras. Jānodrošina

nepieciešamās papildus licences visu videonovērošanas kameru pieslēgšanai VID Bosch BVMS

sistēmai divu straumju ieraksta veikšanai (lokāli un uz centrālo VID Bosch BVMS sistēmu).

IVP-05 SISTĒMAS infrastruktūras komponentes – izvietotās TL Importa un Eksporta joslu tuvumā - minimālās tehniskās prasības (obligāta)

SISTĒMAS perifērijas daļas (kas paredzēta attēlu un datu par TL savākšanai) infrastruktūra ietver visu

aparatūru, kas vajadzīga transportlīdzekļu attēlu tveršanai/pārvaldībai. Jāparedz vismaz šāds

aprīkojums:

1. aparatūras skapis iekārtu izvietošanai;

78

2. transportlīdzekļa vietas uz brauktuves (noteiktas zonas šķērsošanas) noteikšanas ierīce (optiskais

sensors un/ vai magnētiskā cilpa) un atbilstošais kontrollers;

3. kamera TL priekšējās daļas krāsaina attēla iegūšanai;

4. kamera (var būt apvienota ar 3. kameru vienā korpusā) TL priekšējā numura attēla iegūšanai (arī TL

kustības ātruma noteikšanai);

5. kamera TL aizmugurējās daļas krāsaina attēla iegūšanai;

6. kamera (var būt apvienota ar 5. kameru vienā korpusā) TL aizmugurējā numura attēla iegūšanai;

7. kamera / kameras (tikai kravas TL joslās) TL sānu daļas krāsaina attēla visā garumā un konteineru

sānu numura iegūšanai;

8. kameras videonovērošanas veikšanai SISTĒMAS infrastruktūras elementu atrašanas vietā kontrolei

pret vandālismu, neapzinātiem bojājumiem utt. (tikai trijās RŠV, kā arī Liepājas un Ventspils MKP (abās

adresēs – Plosta ielā 7 un Plosta ielā 20/14)), kas nodrošina zonā blakus transporta joslām izvietotās

SISTĒMAS aparatūras videonovērošanu (aizsardzībai pret vandālismu vai citiem bojājumiem). Kameru

skaits tiek izvēlēts, lai nodrošinātu visu SISTĒMAS elementu izvietojuma vietas pārklājamību, kā arī

nodrošina drošības principu, kad “kamera redz citu kameru”;

9. apgaismojuma ierīces (redzamā un/ vai infrasarkanā diapazona) priekšējām, aizmugures un sānu

kamerām – ja tas nepieciešamas kvalitatīva materiāla iegūšanai nelabvēlīgos apstākļos (nepietiekošs

apgaismojums, migla utt.);

10. masti kameru piestiprināšanai un nepieciešamie stiprinājumi, nozarkārbas, zibensaizsardzības

risinājums;

11. zemējuma kontūrs (ar kontūra pretestību mazāku kā 10 (desmit) omi);

12. zibensaizsardzības sistēma uz kameru mastiem - veido, izmantojot strāvu vadošo novadītāja

elementus (antenu) kopā ar speciālo izolēto novadītāju (HVI) savienošanai ar zemējuma kontūru.

13. kontrollers ārējo iekārtu pieslēgšanai/vadībai;

14. industriālais lokālā tīkla komutators (ja nepieciešams elektrobarošanas nodrošināšana kamerām –

ar PoE funkciju).

SISTĒMAS aparatūras skapī jāparedz esošā Ass svaru kontrollera (procesora) uzstādīšana (pārnešana

no esošā aparatūras skapja) un pieslēgšana lokālajam LAN komutācijas elementam.

SISTĒMAS attēlu iegūšanas risinājumam jāparedz, lai tas spēj nodrošināt (ar esošo kameru,

lāzeriekārtu vai citu tehnisko līdzekli) arī informācijas par TL ātrumu ieguvi un nodošanu SISTĒMAI.

79

Objektam Ventspils ostas MKP (Plosta iela 7), kas atrodas vairāk kā 600 m attālumā no esošās serveru

telpas (Sarkanmuižas dambis 25A), izvērtēt un piedāvājumā iekļaut alternatīvo risinājumu ar iespēju

uzstādīt atsevišķu aparatūras skapi (ar atbilstoši mikrovides nodrošināšanas iespēju) kopā ar lokālo

serveri un UPS iekārtu (piem., lielo elektrobarošanas zudumu dēļ savienojošajā kabelī).

IVP-06 SISTĒMAS objektu datu pārraides pieslēguma tehniskie parametri (obligāta)

SISTĒMAS esošo objektu datu pārraides pieslēgums ir realizēts kā VID korporatīvā tīkla sastāvdaļa.

VNS projekta darbības uzsākšanas rezultātā būtiski mainīsies esošā datu pārraides kanālu noslodze,

tāpēc SISTĒMAS datu apmaiņas plānošanai Izpildītājs var plānot, ka tiks nodrošināts 2Mbps datu

pārraides kanāls. Izpildītājam jāprecizē datu pārraides risinājumu starp MKP/RŠV un VID centrālo datu

centru Rīgā, Talejas ielā 1 Būvprojekta izstrādes laikā.

Projektējot optiskā savienojuma izveidi Ventspils ostas MKP (Plosta iela 7), kas atrodas vairāk kā 600

m attālumā no esošās serveru telpas (Sarkanmuižas dambis 25A) (skat. 17. attēlu), jāņem vērā, ka

potenciālo savienojuma trase varētu šķērsot juridiskās personas (Ventspils Svētā Nikolaja pareizticīgās

baznīcas) teritoriju. Sagatavojot Piedāvājumu, ir jāizvērtē un piedāvājumā jāiekļauj alternatīvi

risinājumi savienojuma izveidei starp šiem diviem objektiem (optikas trases izveide vai bezvadu

savienojums, piem., mobilo datu pārraides iespēja). Pretendents savā piedāvājumā norāda abu

risinājumu iespējamo tehnisko realizāciju un ierīkošanas izmaksas. Bezvadu savienojuma gadījumā

pakalpojuma abonēšanas izmaksas nodrošinātu Pasūtītājs.

80

17. attēls. Datu pārraides savienojuma izveide no objekta Plosta ielā 7 līdz Sarkanmuižas

dambim 25A.

Pārējos MKP un RŠV objektos optiskā savienojuma izveidi starp TL joslu kontroles vietām un

komunikāciju telpu veido, izbūvējot nepieciešamo kabeļu kanalizāciju (ar nepieciešamajām

kanalizācijas akām). Šajā kabeļu kanalizācijā izvieto vismaz 12 (divpadsmit) dzīslu daudzmodu optisko

kabeli.

IVP-07 SISTĒMAS objektu elektrobarošanas pieslēguma tehniskie parametri (obligāta)

SISTĒMAS jauno objektu elektrobarošanas risinājumam starp komunikāciju (serveru) telpām un TL

joslu kontroles vietām veido, izmantojot esošās kabeļu kanalizācijas trases vai būvējot jaunas.

Izmantojamo elektrobarošanas kabeļu pieļaujamo slodzi un UPS iekārtu jaudu plāno, paredzot vismaz

20% rezervi pret iekārtu nominālo jaudu. Papildus jāņem vērā arī slodze, ko rada mikroklimata

nodrošināšanas elementi (sildīšana vai dzesēšana) ārējos aparatūras skapjos. Elektrobarošanas

savienojuma abās pusēs (gan komunikāciju (serveru) telpās, gan aparatūras skapī pie TL joslu

kontroles vietām) izveido pārspriegumu aizsardzības elementus, lai minimizētu riskus par netiešās

izlādes ietekmi uz pieslēgtajiem SISTĒMAS elementiem. Visiem SISTĒMAS elementiem jānodrošina

bezpārtraukuma elektrobarošana, izmantojot UPS elementus, izvietojot tos MKP serveru telpā vai

aparatūras skapjos pie transporta joslām. Ja UPS tiek uzstādīti aparatūras skapjos pie transporta

joslām, tiem jānodrošina ražotāja noteikto mikrovides parametrus, organizējot lokālo gaisa dzesēšanu

(karstajam laikam) un sildīšanu (aukstajam laikam). RŠV objektos elektrobarošanas pievienojuma

vietās papildus jāuzstāda elektroniskie elektrobarošanas skaitītāji, kuriem jānodrošina attālināta

patēriņā rādījumu nolasīšana (izmantojot VID korporatīvo tīkla pieslēgumu). Visus SISTĒMAS

elementus, kas atrodas strāvu vadošos korpusos vai pievienoti metāla mastiem, sazemē.

Objektos, kuros zemējuma kontūri ir izbūvēti, un to zemējuma kontūra pretestība nepārsniedz 10

(desmit) omus, tos ir iespējams izmantot risinājuma elementu pieslēgumiem. Ja kontūra pretestība

pārsniedz šo robežvērtību, veic esošā kontūra uzlabošanas darbus vai būvē jaunu.

Elektrobarošanas risinājuma elementiem sagatavo atbilstošo izpilddokumentāciju un veic

nepieciešamos kabeļu un sadaļņu mērījumus, ko nosaka Latvijas likumdošana un normatīvie akti.

81

4.2 (IDP) Infrastruktūras detalizētākās prasības

IDP-01 SISTĒMAS centrālā mezgla infrastruktūras komponentes – izvietotas VID centrālajā datu centrā Rīgā, Talejas ielā 1 - minimālās tehniskās prasības (obligāta)

Prasības SISTĒMAS centrālā mezgla serveru, kas tiks izvietoti VID centrālajā datu centrā, nodrošināšanai norādītas 20. tabulā.

20. tabula. Prasības VID centrālā datu centra serveriem

Nr.

p.

k.

Servera komponente Minimālās tehniskās prasības Minimālais skaits Piedāvātās

komponentes

nosaukums un ražotāja

kataloga numurs*

Norāde uz ražotāja

tehnisko dokumentāciju

vai pievienotās

dokumentācijas lpp.*

Identifikators Norādīt ražotāju, modeli un nomenklatūras numuru

82

Nr.

p.

k.


komponentes


kataloga numurs*



vai pievienotās


1. Izpildījums Statnē montējams (Rack

mount) augstums ne vairāk

kā 2U; komplektā iekļautas

regulējama garuma

izvelkamas servera statnes

montāžas sliedes, kas

nodrošina iespēju veikt

serveru remontu neizņemot

no statnes; kabeļu

organizators un citi

nepieciešamie komponenti

servera montāžai 19` statnē

(square hole sliežu

stiprinājumi).

2. Procesors Intel® Xeon® Gold ar vismaz

16 kodoliem.

2

3.1. Operatīvā atmiņa DDR4 ar kļūdu labošanas

mehānismu, komplektācijai

jānodrošina vismaz 2400

frekvences izmantošana.

256GB

83

Nr.

p.

k.


komponentes


kataloga numurs*



vai pievienotās


Serverim jānodrošina iespēja

esošai atmiņai pievienot

papildu moduļus un

paplašināt izmantojamo

operatīvo atmiņu līdz vismaz

384 GB.

3.2. Operatīvā atmiņa Atmiņas slotu minimālais

skaits

16

4. RAID adapteris RAID 0, 1, 5 un 10 atbalsts.

Kešatmiņa vismaz 1024 MB).

1

5. Diskdziņi Karsti maināmi (hot swap),

480 GB Solid Stat drive

6

6. Grafiskais adapteris Grafiskais adapteris ar

izšķirtspēju SXGA

(1280x1024);

1

84

Nr.

p.

k.


komponentes


kataloga numurs*



vai pievienotās


7.1. Tīkla adapteris I 2 portu 10 Gigabit Ethernet

tīkla karte 10GBASE-SR

(Iekļauti divi SFP+ transīveri,

multimode, LC konektors).

Savietojama ar Cisco Nexus

5596 komutatoru un Cisco

Nexus 2232 PP 10GE Fabric

Extender, kurš aprīkots ar

10GBASE-SR SFP transīveri.

Adapterim jānodrošina

funkcionalitāte slodzes

līdzsvarošanas (Load

balancing) režīmā un portu

dublēšana (Redundancy)

režīmā Linux

operētājsistēmās.

Jānodrošina Link aggregation

atbalsts (IEEE 802.1AX vai

IEEE 802.ad)

1

85

Nr.

p.

k.


komponentes


kataloga numurs*



vai pievienotās


7.2. Tīkla adapteris II Storage area network (SAN)

FC 8Gbps ar 2 (diviem)

portiem un iekļautiem 8Gbps

transīveriem. Savietojams ar

Cisco MDS 9506 FC

komutatoru.

1

8. Barošanas bloki Karsti maināms (hot swap),

bojājumpiecietīgi (N+1).

2

9. Ventilatori Karsti maināmi (hot swap),

bojājumpiecietīgi (N+1).

2

10. Diagnostikas iespējas Diagnostikas iespējas,

neapstādinot sistēmu (online

diagnostics), kas nodrošina

iespēju paredzēt sistēmas

bojājumus vai darbaspējas

zudumus šādām

komponentēm: cietajiem

diskiem, operatīvajai atmiņai,

ventilatoriem, barošanas

blokiem.

-

86

Nr.

p.

k.


komponentes


kataloga numurs*



vai pievienotās


11. Pārvaldība Sistēmas pārvaldības

apakšsistēma ar 10/100

BaseT Ethernet port (RJ-45)

interfeisa portu Servera

pārvaldībai, arī tad, ja

Serveris ir “Power Off”

stāvoklī, bet ir pievienots pie

elektrobarošanas tīkla.

Pārvaldības nodrošināšanai

paredzētā programmatūra ar

šādu funkcionalitāti:

- grafiskā konsole attālinātai

servera vadībai;

- attālinātas instalācijas

iespēja izmantojot virtuālo

cdrom;

- SNMPv2 vai IPMI protokola

atbalsts un MIB datnes;

- SSL tehnoloģija

savienojuma drošībai visos

režīmos;

-

87

Nr.

p.

k.


komponentes


kataloga numurs*



vai pievienotās


- iespēja veikt attālinātu

operētājsistēmas instalāciju.

Visām nepieciešamajām

pārvaldības programmatūras

licencēm jābūt iekļautām

piegādē.

12. Operētājsistēma Windows Server 2016

Standart OEM vai ekvivalents

SISTĒMAS darbības

nodrošināšanai

-

13. Slotu skaits 2 gab. PCIe Gen3.0 -

14. Ražotāja garantija 5 gadu periods, bojājumu

novēršana nākošā darba

dienā (next business day on

site, on-site), ierodoties

Iekārtu ekspluatācijas vietā.

88

Nr.

p.

k.


komponentes


kataloga numurs*



vai pievienotās


15. Virtualizācijas iespējas Jānodrošina nepieciešamās

licences, lai uz šiem

fiziskajiem resursserveriem

varētu nodrošināt SISTĒMAS

serveru (risinājuma serveri,

datu bāze, web, testa vide un

FTP serveris,) virtualizāciju.

16. Uzstādīšanas vieta Rīga, Talejas iela 1

17. Iekārtu skaits 2

Prasības SISTĒMAS centrālā mezgla datu masīvu, kas tiks izvietoti VID centrālajā datu centrā, nodrošināšanai norādītas 21. tabulā.

89

21. tabula. Prasības SISTĒMAS datu masīvām N

r. p

.k.

Komponente,

parametrs

Minimālās tehniskās prasības Pretendenta piedāvātais**

Komponentes, parametra raksturojums Minimālais

skaits

Kompone

ntes,

parametra

raksturoju

ms

Kopējais

skaits



(URL) vai pievienotās

ražotāja dokumentācijas

lpp.

1. Kontroles apakšsistēma

1.1. Kopējais Pretendentam jāpiegādā disku masīvs ar diviem

aktīviem kontrolieru mezgliem

1.2. Kontrolieru

mezglu skaits

Kontrolieru mezglu skaits 2

1.3. Kešatmiņa

(Cache memory)

Vismaz 24 GB katram kontroliera mezglam.

Jānodrošina elektrobarošanas pārrāvumu

aizsardzība kešatmiņai

-

1.4. RAID adaptera

atbalstītie līmeņi

RAID līmenis, kas nodrošina aizsardzību vismaz

divu disku vienlaicīga bojājuma gadījumā

-

1.5. Diskdziņu

atvilktņu

pieslēgšanas

veids

Dublēts SAS. 12Gbps

1.6. Diskdziņu

atvilktņu skaits

Iespējams paplašināt kopējo disku masīva lāžu

skaitu

90


1.7.1 SAN pieslēguma

veids tīklam

FC 16Gbps Katram

kontroliera

mezglam

vismaz 4

1.7.2 LAN pieslēguma

veids tīklam

FC 10Gbps ar iekļautiem SFP+ transīveriem Katram

kontroliera

mezglam

vismaz 2

1.8. Apjoms SSD diskdziņi vai ekvivalents Flash apjoms (raw

space) Tiering funkcionalitātei

vismaz 4gab.

1,6TB

1.9. HDD diskdziņu skaits un apjoms (raw space).

SAS 10 000 rpm

vismaz 44gab.

79,2TB

1.10.1. Garantijas remonta gadījumā bojātus datu

nesējus nav jāatgriež (non-returnable disks)

1.10.2. Visām disku vietām masīvā jābūt aizpildītiem

1.11. Diskdziņu

parametri

karsti maināmi (hot swap).

1.12. LUN skaits Vismaz 128

1.13. Savietojamība

ar SAN tīklu

Disku masīvam jābūt savietojamam ar

91


Valsts ieņēmumu dienesta (VID) rīcībā esošo

SAN komutatoru CISCO MDS 9506, FC 8Gbps

portiem. Bāzes modulis (DS-C9506),

supervisor/fabric modulis (DS-X9530-

SF2AK9)

1.14.

Funkcionalitāte.

Jānodrošina un piedāvājumā jāiekļauj visas

nepieciešamās licences vismaz šādu

funkcionalitāšu nodrošināšanai (visam disku

apjomam, kas iekļauts šajā komplektā):

-

Jānodrošina biežāk lietoto datu automātisku

izvietošanu starp Flash kartēm, SSD, HDD

diskiem (piemēram, Fully Automated Storage

Tiering tehnoloģija vai ekvivalenta tehnoloģija)

-

Jānodrošina momentuzņēmumu veidošana

(piemēram, Snapshot tehnoloģija), veicot

vismaz 32 momentuzņēmumu uzņemšanu

katram LUN, kuros iespējams veikt datu

izmaiņas, tām papildus nerezervējot pilna

apjoma LUN vietu

-

1.15. Jānodrošina loģisko disku izveide bez disku

kapacitātes rezervēšanas (piemēram, Thin

Provisioning tehnoloģija).

1.16. Jānodrošina bezpārtraukuma programmatūras

(firmware) atjaunošana

92




1.17. Iespēja paplašināt disku masīva RAID grupas

neapstādinot disku masīvu pievienojot papildus

diskus vai lādes

1.18. Barošanas bloki

un ventilatori

Dublēti, karsti maināmi (Redundant, Hot Swap)

atbilstoši ražotāja un šīs tehniskās specifikācijas

noteikumiem.

Disku masīviem un lādēm ir jābūt aprīkotām ar

vismaz diviem 230 V barošanas blokiem, kuru

efektivitāte pie 50 procentu noslodzes ir vismaz

89 procenti.

1.19 Operētājsistēmu

atbalsts

Jānodrošina un piedāvājumā jāiekļauj

nepieciešamās licences vienlaicīgam darbam ar

augstu pieejamību (multipath) sekojošām

operētājsistēmām - Red Hat Enterprise Linux 7.x,

MS Windows Server 2012 R2, MS Windows

Server 2016.

-

2. Konfigurācija

2.1. Jānodrošina augstas pieejamības slēgums ar

dublētiem SAN tīkla savienojumiem.

Jānodrošina visu nepieciešamo pārveidotāju

(transceiver) un savienojumu kabeļu piegādi un

uzstādīšanu.

Atbilstoši

ražotāja un

šīs tehniskās

specifikācijas

noteikumiem

.

93




Jānodrošina visu nepieciešamo licenču piegāde

un aktivizācija atbilstoši piedāvāto disku masīvu

ražotāja licencēšanas noteikumiem, lai tiktu

izpildītas minimālās tehniskās prasības.

2.2. Korpuss 19` statnē iebūvējams (square hole sliežu

stiprinājumi) montējams pasūtītāja statnēs,

kuru dziļums ir 1 m (no priekšējām iekārtu

stiprināšanas sliedēm līdz aizmugures durvīm).

2.3. Piederumi Visi nepieciešamie piederumi (kabeļi, pārvadi,

skrūves, sliedes u. c. nepieciešamie piederumi),

lai uzstādītu disku masīvu statnē.

3. Disku masīva komplektācija

3.1. Disku masīvam jābūt komplektētam ar viena

ražotāja programmatūru un iekārtām

3.2. Visai tehniskajā specifikācijā prasītajai

funkcionalitātei jābūt strādājošai uz

piedāvājuma iesniegšanas dienu aktuālajā

rekomendētajā disku masīva programmatūras

versijā.

4. Piegādes vieta Rīga, Talejas iela 1

94

IDP-02 SISTĒMAS infrastruktūras komponentes – izvietotās MKP/RŠV serveru telpās - minimālās tehniskās prasības (obligāta)

Prasības SISTĒMAS serveru nodrošināšanai norādītas 22. tabulā.

22. tabula Prasības serveriem MKP/RŠV serveru telpās

Nr.

p.

k.

Servera

komponente

Minimālās tehniskās prasības Minimālais

skaits

Piedāvātās

komponentes

nosaukums un

ražotāja

kataloga

numurs*

Norāde uz

ražotāja tehnisko

dokumentāciju

vai pievienotās

dokumentācijas

lpp.*

Identifikators Norādīt ražotāju, modeli un nomenklatūras numuru

1. Izpildījums Statnē montējams (Rack mount) augstums ne vairāk kā 2U;

komplektā iekļautas regulējama garuma izvelkamas servera

statnes montāžas sliedes, kas nodrošina iespēju veikt serveru

remontu neizņemot no statnes; kabeļu organizators un citi

nepieciešamie komponenti servera montāžai 19` statnē (square

hole sliežu stiprinājumi).

2. Procesors Ar vismaz sešiem kodoliem uz katru fizisko procesoru ar skaitļošanas

jaudu vismaz 36 punkti uz vienu kodolu pēc www.spec.org

“SPECint2006 Rate” specifikācijas.

2

3.1. Operatīvā atmiņa DDR4 ar kļūdu labošanas mehānismu, komplektācijai

jānodrošina vismaz 1866 frekvences izmantošana.

64GB

95

Nr.

p.

k.

Servera

komponente


skaits

Piedāvātās

komponentes

nosaukums un

ražotāja

kataloga

numurs*

Norāde uz

ražotāja tehnisko

dokumentāciju

vai pievienotās

dokumentācijas

lpp.*

Serverim jānodrošina iespēja esošai atmiņai pievienot papildu

moduļus un paplašināt izmantojamo operatīvo atmiņu līdz

vismaz 64GB.

3.2. Operatīvā atmiņa Atmiņas slotu minimālais skaits 8

4. RAID adapteris RAID 0, 1, 5 un 10 atbalsts. Kešatmiņa vismaz 1024 MB. 1

5. Diskdziņi Karsti maināmi (hot swap), 1200 GB SAS 10000 rpm HDD 8

6. Grafiskais

adapteris

Grafiskais adapteris ar izšķirtspēju vismaz SXGA (1280x1024); 1

7. Tīkla adapteris 4 portu 1 Gigabit Ethernet tīkla karte RJ45. Adapterim

jānodrošina funkcionalitāte slodzes līdzsvarošanas (Load

balancing) režīmā un portu dublēšana (Redundancy) režīmā

Linux operētājsistēmās. Jānodrošina Link aggregation atbalsts

(IEEE 802.1AX vai IEEE 802.ad)

1

8. Barošanas bloki Karsti maināmi (hot swap), bojājumpiecietīgi (N+1). 2

9. Ventilatori Karsti maināmi (hot swap), bojājumpiecietīgi (N+1). 2

96

Nr.

p.

k.

Servera

komponente


skaits

Piedāvātās

komponentes

nosaukums un

ražotāja

kataloga

numurs*

Norāde uz

ražotāja tehnisko

dokumentāciju

vai pievienotās

dokumentācijas

lpp.*

10. Diagnostikas

iespējas

Diagnostikas iespējas, neapstādinot sistēmu (online

diagnostics), kas nodrošina iespēju paredzēt sistēmas

bojājumus vai darbaspējas zudumus šādām komponentēm:

cietajiem diskiem, operatīvajai atmiņai, ventilatoriem,

barošanas blokiem.

-

11. Pārvaldība Sistēmas pārvaldības apakšsistēma ar 10/100 BaseT Ethernet

port (RJ-45) interfeisa portu Servera pārvaldībai, arī tad, ja

Serveris ir “Power Off” stāvoklī, bet ir pievienots pie

elektrobarošanas tīkla. Pārvaldības nodrošināšanai paredzētā

programmatūra ar šādu funkcionalitāti:

- grafiskā konsole attālinātai Servera vadībai;

- attālinātas instalācijas iespēja izmantojot virtuālo CDROM;

- SNMPv2 vai IPMI protokola atbalsts un MIB datnes;

- SSL tehnoloģija savienojuma drošībai visos režīmos;

- iespēja veikt attālinātu operētājsistēmas instalāciju.

Visām pārvaldības programmatūras licencēm jābūt iekļautām.

-

12. Operētājsistēma Windows Server 2016 Standart OEM vai ekvivalents -

13. Sloti PCIe Gen3.0 -2

97

Nr.

p.

k.

Servera

komponente


skaits

Piedāvātās

komponentes

nosaukums un

ražotāja

kataloga

numurs*

Norāde uz

ražotāja tehnisko

dokumentāciju

vai pievienotās

dokumentācijas

lpp.*

14. Ražotāja garantija 5 gadu periods, bojājumu novēršana nākošā darba dienā (next

business day on site, on-site), ierodoties Iekārtu ekspluatācijas

vietā.

15. Uzstādīšanas

vietas

Norādītajos MKP/RŠV

16. Skaits Vismaz 1 katrā norādītājā MKP/RŠV 12*

*Piezīme. Ja risinājumam Ventspilī, Plosta ielā 7 nepieciešams serveri uzstādīt tuvāk transporta joslai, tad to uzstāda papildus serveri aparatūras skapī pie

transporta joslas, nodrošinot atbilstošo mikrovidi.

Prasības SISTĒMAS komutatoru nodrošināšanai MKP/RŠV serveru telpās (ja tie ir nepieciešami SISTĒMAS elementu savienošanai) norādītas 23. tabulā.

23. tabula. Prasības komutatoriem MKP/RŠV serveru telpās

Nr.

p.k. Minimālās tehniskās prasības Pretendenta piedāvātais

1. Maksimālais portu skaits vienam komutatoram – 24 porti

2. Ja tiek izmantoti 2 vai vairāk komutatori, tie jāgrēdo (stack)

98

3. Komutatori VID lokālā tīkla infrastruktūrai jāpieslēdz linku agregācijas konfigurācijā (Link

Aggregation Control Protocol (LACP) (802.3ad)). Risinājumiem ar 2 vai vairāk grēdotiem

komutatoriem, LACP pieslēguma porti jākonfigurē no diviem dažādiem komutatoriem grēdā.

4. Komutatoriem jābūt uzstādāmiem 19” statnē (jāpiegādā arī visi nepieciešamie stiprinājumi)

5. Komutatoriem ar portu skaitu līdz 10 jānodrošina vismaz 5 Gbit/s kopējais forwarding ātrums.

6. Visiem piedāvātajiem komutatoriem ir jābūt no viena ražotāja un no vienas sērijas modeļu

grupas, kura nav noņemta no ražošanas un līguma darbības laikā nav paredzēta komutatoru

pārdošanas pārtraukšana (End of sale).

7. Komutatoriem ar 24 portiem jānodrošina vismaz 20 Gbit/s kopējais forwarding ātrums.

Visiem piedāvātajiem komutatoriem jānodrošina VLAN funkcionalitāte, VLAN trunking (802.1Q),

Priority (802.1p), Port-based Network Access Control (802.1x).

Jānodrošina Multilink trunking.

Jānodrošina SNMPv2 un SNMPv3 atbalsts.

Jānodrošina elastīga pārvaldība (ar konsoli, SSH, WEB). SSH pārvaldībai jānodrošina pilna

komutatora vadība. Komutatoram jābūt savietojamiem ar VID rīcībā esošo Cisco prime

infrastructure pārvaldības rīku.

Visiem komutatora portiem jāatbalsta Full-Duplex un Autosensing režīmi.

Komutatoriem jānodrošina Power over Etherner (IEEE 802.3af, IEEE 802.3at) videokameru

darbības nodrošināšanai.

8. Komutatoram jābūt pilnībā integrējamam pasūtītāja rīcībā esošajā Cisco Identity Services Engine

infrastruktūrā. Atbalsta integrāciju ar RADIUS autentifikācijas un autorizācijas servisiem, Port-

based Network Access Control (802.1x).

9. Visiem piedāvātajiem optiskajiem moduļiem (Transīveriem, DAC kabeļiem) jābūt savietojamiem

ar piedāvātajiem komutatoru modeļiem

http://en.wikipedia.org/wiki/Network_Access_Control

99

Prasības SISTĒMAS komutatoru nodrošināšanai aparatūras skapī pie transporta joslām norādītas 24. tabulā.

24. tabula Prasības komutatoru nodrošināšanai aparatūras skapī pie transporta joslām

Nr.


1.. Komutatoriem jābūt savienojamiem ar piedāvātajiem MKP serveru telpu komutatoriem

2. Visiem komutatora portiem jāatbalsta Full-Duplex un Autosensing režīmi.

3. Komutatoriem jānodrošina Power over Etherner (IEEE 802.3af) videokameru darbības

nodrošināšanai.

4. Komutatoriem jāspēj darboties temperatūras robežās no -30 līdz +40 °C. Ja pretendents

Sistēmā izmanto apsildāmus un dzesējamus komunikācijas skapjus komutatoru izvietošanai,

kuras nodrošina komutatoru ražotāja tehniskajā specifikācijā norādīto vidi komutatoru darbībai

ārā temperatūras apstākļos no -30 līdz +40 °C, šī prasība nav spēkā.

5. Komutatoriem jābūt attālināti vadāmiem, izmantojot komandrindu (SSH) vai grafisko interfeisu

(GUI). Jānodrošina monitoringa iespēja (SNMP v2., v3 atbalsts).

6. Iekārtas korpuss - paredzēts uzstādīšanai uz 35 mm DIN-sliedes

7. Elektrobarošana - maiņspriegums 230±5V, 50Hz vai 12/24/48V līdzspriegums

8. Korpusa aizsardzība pret mitrumu un putekļiem – vismaz IP30

100

Prasības SISTĒMAS UPS iekārtas nodrošināšanai norādītas 25. tabulā.

25. tabula. Prasības UPS nodrošināšanai iekārtai

Nr.


1. Pretendentam jāpiegādā katrā objektā nepārtrauktās elektrobarošanas iekārtas, kuras

nodrošinās visu iekārtu darbību vismaz 10 minūtes pēc elektrobarošanas pazušanas.

2. Objektu serveru telpās UPS iekārtām jābūt statnē montējamām (rackmount).

3. UPS jābūt attālinātās vadības un uzraudzības modulim ar datortīkla pieslēgumu. Tas jāpieslēdz

un jānokonfigurē pie piegādājamajiem komutatoriem.

4. UPS jānodrošina attālināta tīkla uzraudzība Zabbix sistēmā (noslodzes, bateriju stāvokļa un

bojājumu ziņojumu nosūtīšana Zabbix sistēmai un grafiska attēlošana).

5. Pretendentam jānodrošina UPS iekārtu pieslēgšana ēkas elektrobarošanas tīklam Pasūtītāja

norādītā vietā.

6. Jānodrošina pārsprieguma aizsardzība visiem elektrobarošanas savienojumiem, kas tiek

pievadīti ārpus serveru telpas (uz TL joslu aparatūras skapjiem).

7. Iekārtu skaits – katrā MKP/RŠV vietā. 12*

*Piezīme. Ja risinājumam Ventspilī, Plosta ielā 7 nepieciešams iekārtas uzstādīt tuvāk transporta joslai, tad uzstāda papildus UPS iekārtu aparatūras skapī pie

transporta joslas, nodrošinot atbilstošo mikrovidi.

101

Prasības SISTĒMAS UPS nodrošināšanai RŠV objektos norādītas 26. tabulā.

26. tabula. Prasības UPS iekārtām RŠV objektos

Nr.p.k. Parametrs Parametra detalizācija

1. Korpuss Statnē montējams 19” statnē, (ja tos uzstāda lokālajos

aparatūras skapjos, tie var būt arī “tower” korpusā. .

2. Aizsargāto

elektrobarošanas

pieslēguma vietu

skaits

Ne mazāk kā 8, IEC 320 C13

3. Maksimālā

darbības jauda, W

Jānodrošina visu pieslēgto iekārtu jauda (ar vismaz 20%

rezervi), ar vismaz 10 min. darbību pilnas noslodzes apstākļos

4. Monitoringa

iespējas

Jānodrošina Ethernet LAN (RJ-45) pieslēgvieta, jāslēdz VID

lokālajā tīklā. Atbalstāmie tīkla protokoli - SNMP v2, SNMP v3

5. LCD ekrāns LCD ekrāns ar teksta un grafisku attēlojumu par darbības

režīmiem un sistēmas parametriem

102

Nr.p.k. Parametrs Parametra detalizācija

6. Pārsprieguma

aizsardzība

Visi elektrobarošanas savienojumi, kas no UPS iekārtas tiek

pievadīti ārpusē esošajiem patērētājiem, nepieciešamas

aizsargāt ar atbilstošu pārsprieguma aizsardzības risinājumu.

7. Skaits Norāda risinājuma nepieciešamo daudzumu

8. Montāža Jāuzstāda MKP/RŠV serveru telpā vai lokālajos aparatūras

skapjos, ja tiem tiek nodrošināta ražotāja noteiktie mikrovides

parametri, organizējot lokālo gaisa dzesēšanu (karstajam

laikam) un sildīšanu (aukstajam laikam).

Prasības SISTĒMAS aparatūras statņu nodrošināšanai RŠV objektos norādītas Error! Reference source not found..27. tabulā.

27. tabula. Prasības aparatūras nodrošināšanai RŠV objektos

Nr.p.k. Parametrs Parametra detalizācija Pretendenta piedāvātais

1. Korpuss 19” statne, 22U, ar slēdzamām durvīm (22U, ar metāla

perforētām durvīm priekšā un aizmugurē, 600x1000mm),

jāparedz iespēja statni piestiprināt pie sienas.

103


2. Statņu priekšējās

un aizmugurējās

durvis

Metāla, perforētas (vismaz ar 70% gaisa caurlaidība)

3. Slodzes spēja Vismaz 600 kg

4. Elektrobarošanas

pieslēguma vietu

bloki (PDU)

1-fāzu PDU komplekts (sastāv no 2 iekārtām), ar lokālu strāvas

mērīšanu, vismaz 3kW nodrošināto jaudu, paredzēts novietot

horizontāli:

a. Ar vismaz 8 (astoņām) C13 rozetēm katrā;

b. Ethernet ports SNMP monitoringa pieslēgšanai;

c. 2 gab. temperatūras / rel. mitruma sensori;

5. Monitoringa vide Sensoru kontrollers:

a. Ar vismaz 16 sensoru pieslēgšanas iespēju;

b. Katras statņu durvju atvēršanas sensori (herkoni) – atkarībā

no durvju skaita;

c. Kombinētie temperatūras / rel. mitruma sensori – 2 gab.;

d. Web pieslēguma iespēja, izmantojot RJ-45 10/100 Mbit/s

pieslēguma vietu

e. IP/4, IP/6, SNMP, HTTPS atbalsts;

104


f. Programmatūra sensoru informācijas apstrādei un

trauksmes paziņojumu nosūtīšanai par avārijas situācijām.

6. Kabeļu kārtotāji Statnē jābūt uzstādītiem gan horizontālajiem, gan

vertikālajiem savienojošo vadu kārtotājiem. Pie katra

komutācijas paneļa vai iekārtas jābūt uzstādītam vienam

horizontālajam kabeļu kārtotājam.

7. Statnes

zemējums

Aprīkots ar zemējuma kopni, visu durvju un rāmja

sazemējumam

8. Papildus

aprīkojums

Statnes lokālie ventilatori ar termostatu statnes jumta daļā.

Prasības SISTĒMAS rezerves aparatūras statņu nodrošināšanai objektos norādītas 28. tabulā.

28. tabula. Prasības rezerves aparatūras statnēm objektos*


1. Korpuss 19” statne, vismaz 42U, ar vismaz 3 sadalītajām (vertikāli)

sekcijām, ar slēdzamām durvīm, katrai sekcijai unikāla atslēga

(metāla perforētām durvīm priekšā un aizmugurē), pl.600 x

dz.1200mm.

105


2. Statņu priekšējās

un aizmugurējās

durvis

Metāla, perforētas (vismaz ar 70% gaisa caurlaidība)

3. Slodzes spēja Vismaz 800 kg

4. Elektrobarošanas

pieslēguma vietu

bloki (PDU)

1-fāzu PDU komplekts (sastāv no 2 iekārtām), paredzēts katrā

no sekcijām, ar lokālu strāvas mērīšanu, vismaz 3kW

nodrošināto jaudu, paredzēts novietot horizontāli:

a. Ar vismaz 8 (astoņām) C13 rozetēm katrā;

b. Ethernet ports SNMP monitoringa pieslēgšanai;

c. 2 gab. temperatūras / rel. mitruma sensori;

5. Monitoringa vide Sensoru kontrollers (kopējs visai statnei):

a. Ar vismaz 16 sensoru pieslēgšanas iespēju;

b. Katras statņu durvju atvēršanas sensori (herkoni) – atkarībā

no durvju skaita;

c. Kombinētie temperatūras / rel. mitruma sensori – 2 gab.;

d. Web pieslēguma iespēja, izmantojot RJ-45 10/100 Mbit/s

pieslēguma vietu

e. IP/4, IP/6, SNMP, HTTPS atbalsts;

106


f. Programmatūra sensoru informācijas apstrādei un

trauksmes paziņojumu nosūtīšanai par avārijas situācijām.

6. Kabeļu kārtotāji Statnē jābūt uzstādītiem gan horizontālajiem, gan

vertikālajiem savienojošo vadu kārtotājiem. Pie katra

komutācijas paneļa vai iekārtas jābūt uzstādītam vienam

horizontālajam kabeļu kārtotājam.

7. Statnes

zemējums

Aprīkots ar zemējuma kopni, visu durvju un rāmja

sazemējumam

*Piezīme. Iekļauj kopējos piegādes apjomos, uzstāda atbilstoši Pasūtītāja norādījumiem projekta uzsākšanas fāzē.

IDP-03 SISTĒMAS infrastruktūras komponentes – izvietotās TL Importa un Eksporta joslu tuvumā - minimālās tehniskās prasības (obligāta)

SISTĒMAS TL Importa un Eksporta joslu tuvumā uzstādītajam ārējam aparatūras skapim prasības ir norādītas 29. tabulā.

107

29. tabula. Prasības ārējam aparatūras skapim


1. Komplektācija

un gabarīti

Skapja gabarītu izvēlas tādu, lai tajā ir pietiekoša vieta visiem paredzētajiem

SISTĒMAS elementiem, vadu montāžas un kārtošanas paneļiem, kā arī esošā Ass

svaru kontrollera (procesora) uzstādīšanai.

2. Korpuss Skapis izgatavots atbilstoši LVS EN 60439 prasībām. Skapja korpuss izgatavots

vismaz no 1,5 mm bieza cinkota tērauda lokšņu materiāla un pārklāts ar gaišas

krāsas UV starojuma noturīgu polimēru pārklājumu ar pulvertehnoloģijas metodi,

kas atbilst apkārtējās vides apstākļu klasifikācijas klasei C4. Skapja augšējai daļai

jānodrošina lietus ūdeņu novadīšana no skapja durvīm. Aizsardzības pakāpe vismaz

IP 55 atbilstoši IEC 60529. Pieslēgts pie zemējuma kontūra (ar atbilstošu

savienojuma marķēšanu). Skapi marķē ar atbilstošiem drošības brīdinājumiem

atbilstoši MK noteikumiem Nr. 238 “Ugunsdrošības noteikumi”.

3. Mikroklimata

nodrošināšana

Skapī jānodrošina atbilstošs klimata režīms ar dzesēšanu un apsildi, atbilstoši

iekārtu darba režīma prasībām, vismaz robežās no -0C līdz +40C (ja kādai no

izvietotajām aktīvajām iekārtām ir noteiktas augstākas prasības, tad to norāda

Piedāvājumā), ar izveidotu sildīšanas un dzesēšanas risinājumu. Sistēmas sildīšanas

jaudas nodrošināšanai var izmantot pieslēgumu pie tuvumā esošā Ass svaru betona

pamatnes sildīšanas vadības bloka, kas atrodas atsevišķā aparatūras skapī.

4. Skapja drošība Skapja durvīm jābūt slēdzamām ar mehānisku vai elektronisku atslēgu, jāuzstāda

durvju atvēršanas sensors, kas tiek pieslēgts pie VID centralizēta monitoringa

(izmantojot kontrolleri).

108


5. Monitoringa

elementi

Skapī uzstāda kontrolleri, kam var pieslēgt vismaz temperatūras un durvju

atvēršanas sensorus, kas nodrošina datu pārraidi uz VID monitoringa sistēmu

SNMP protokola veidā. Dati par aparatūras skapja klimata parametriem un durvju

atvēšanu jāintegrē Pasūtītāja pārvaldības sistēmā Zabbix.

6. Montāžas

prasības

Skapī jāuzstāda uz betona pamatnes, kas ir nolīmeņota visās dimensijās. Skapja

apakšējās malas augstumu izvēlās tādā augstumā, lai skapī neiekļūtu lietus un

sniega kušanas ūdens, kā arī ir iespējams atvērt durvis ziemā, bieza sniega

apstākļos. Neizmantotajos stiprināšanas urbumos jāieskrūvē skrūves, kabeļu

ievadus hermetizēt, lai saglabātu atbilstošu aizsardzības pakāpi.

7. Skaits Vismaz viens katrā joslu Importa un Eksporta pusē (pieļaujams apvienot vienā, ja

abas joslas izvietotas vienā no pusēm (Importa vai Eksporta)).

8 Elementu

uzstādīšana

Veic visu nepieciešamo kabeļu komutāciju, iekārtu uzstādīšanu atbilstoši ražotāju

tehniskajiem noteikumiem un prasībām, kā arī Ass svaru kontrollera parvietošanu

no esošā skapja uz jauno, saskaņojot to ar iekārtas uzturēšanas puses pārstāvi.

SISTĒMAS TL Importa un Eksporta joslu tuvumā uzstādītajam attēla iegūšanas kameru prasības ir norādītas 30. tabulā. Papildus ir norādītas prasības

videonovērošanas kamerām, kuras paredzētas uzstādīt no jauna izbūvējamajos objektos.

109

30. tabula. Prasības attēlu iegūšanas un videonovērošanas kamerām

Nr.p.k. Parametrs Minimālās tehniskās prasības Pretendenta piedāvātais

1. Kamera TL priekšējās un aizmugurējās daļas krāsaina attēla iegūšanai

Kameras tips Fiksēta āra izpildījuma kamera (ar korpusa apsildi, ja to nosaka iekārtas

ražotājs)

Gaismas jūtība Krāsu režīmā: 0.18 Lux, melnbaltā režīmā: 0.04 Lux

Nepieciešamais

apgaismojums

sliktos laika

apstākļos

Iebūvētais gaismas elements vai ārējā elementa izmantošana

Izšķirtspēja un

kadru skaits

sekundē

Full HD 1920x1080 – 25 kadri/sekundē ar ieslēgtu WDR funkciju

Tīkla drošība

un atbalstāmie

protokoli

Aizsardzība ar paroli, IP adrešu filtrs, HTTPS šifrēšana, IEEE 802.1X tīkla

piekļuves kontrole. IPv4/v6, HTTP, HTTPS, SSL/TLS, QoS Layer 3 DiffServ,

FTP, SNMPv1/v2c/v3 (MIB-II), DNS, NTP, RTP, TCP, UDP, DHCP

Barošana PoE IEEE 802.3af/802.3at vai 12V/24V DC

110


Pieļaujamiem

klimatiskie

nosacījumi

-30 °C to 40 °C

Skaits 2 gab. katrā joslā

2. Kamera TL sānu daļas (tikai kravas TL joslās) krāsaina attēla visā garumā un konteineru

sānu numura iegūšanai

Kameras tips Line Scan vismaz 2K krāsu kamera, āra izpildījums (ar korpusa apsildi, ja to

nosaka iekārtas ražotājs)

Sinhronizācijas

iespējas

Ar programmatūras vai aparatūras trigeri

Nepieciešamais

apgaismojums

sliktos laika

apstākļos


Barošana PoE IEEE 802.3af/802.3at vai 12V/24V DC

Datu pārraides

kanāls Vismaz 1000 Mbps Ethernet

111


Pieļaujamiem

klimatiskie

nosacījumi

-30 °C to 40 °C

Skaits 1 gab. tikai kravas TL joslā

3. Kamera TL priekšējā un aizmugurējā numura attēla iegūšanai

Kameras tips Āra izpildījums

Sinhronizācijas

iespējas

Ar programmatūras vai aparatūras trigeri

Nepieciešamais

apgaismojums

sliktos laika

apstākļos


Barošana PoE IEEE 802.3af/802.3at vai 12V/24VDC

Datu pārraides

kanāls Vismaz 10/100 Mbps Ethernet

Ātruma

noteikšanas

iespēja

Iebūvēta radara (ātruma noteikšanas) funkcija, ar ātrumu vismaz 70km/h

112


Pieļaujamiem

klimatiskie

nosacījumi

-30 °C to 40 °C

Skaits 2 gab. katrā kravas TL joslā

4 Kameras SISTĒMAS objektu videonovērošanas veikšanai (tikai trijos RŠV, kā arī

Liepājas, Ventspils un Kundziņsalas (Rīgas brīvostas) MKP)

Kameras tips Fiksēta āra izpildījuma kamera

Gaismas jūtība Krāsu režīmā: 0.18 Lux, melnbaltā režīmā: 0.04 Lux

Nepieciešamais

apgaismojums

sliktos laika

apstākļos


Izšķirtspēja un

kadru skaits

sekundē

Full HD 1920x1080 – 25 kadri/sekundē ar ieslēgtu WDR funkciju

Tīkla drošība

un atbalstāmie

protokoli

Aizsardzība ar paroli, IP adrešu filtrs, HTTPS šifrēšana, IEEE 802.1X tīkla

piekļuves kontrole. IPv4/v6, HTTP, HTTPS, SSL/TLS, QoS Layer 3 DiffServ,

FTP, SNMPv1/v2c/v3 (MIB-II), DNS, NTP, RTP, TCP, UDP, DHCP

113


Barošana PoE IEEE 802.3af/802.3at vai 12V/24VDC

Pieļaujamiem

klimatiskie

nosacījumi

-30 °C to 40 °C

Skaits Skaits tiek nodrošināts atkarībā no realizētā kameru redzamības

pārklājamības risinājuma, lai nodrošinātu videonovērošanu uzstādītā

aprīkojuma kontroles zonā (vandālisms, transportlīdzekļa izraisīta

sadursme utt.). Jānodrošina arī pašu kameru drošības risinājuma

realizācija, lai nav iespējams tuvoties šai aizsargātajai zonai, neiekļūstot

kameru redzamības sektorā (Fiel of View) – kamerām “jāredz vienai otru”.

Integrācija ar

esošo VID VNS

risinājumu

Videonovērošanas risinājumam (Ventspils, Liepājas MKP) jāparedz iespēju

nodrošināt videoinformācijas apmaiņu ar VID VNS lokālo serveri, kas

izmanto Bosch BVMS vadības un datu apstrādes risinājumu.

Videonovērošanas risinājumam RŠV jānodrošina attēlu straumēšana uz

VID VNS centrālo mezglu Rīgā, Talejas ielā 1.

Papildus

licences

kamerām

Jānodrošina nepieciešamās licences kamerām, lai tās var pieslēgt pie VID

VNS centrālā mezgla Bosch vadības un datu apstrādes risinājuma.

5.

Apgaismojuma ierīces priekšējām, aizmugures un sānu kamerām

Apgaismojuma

veids

Var tikt izmantoti redzamā un/ vai infrasarkanā diapazona apgaismojuma

elementi;

114


Darbības

režīms

Pieļaujama patstāvīga piegaismošana vai arī ieslēdzot ierīci pirms TL

tuvošanās

Spilgtuma

regulēšanas

iespēja

Jānodrošina

Pieļaujamiem

klimatiskie

nosacījumi

-30 °C to 40 °C

Skaits Atkarībā no izmantotā kameru skaita

IDP-04 SISTĒMAS infrastruktūras komponentes – datu pārraides risinājums MKP teritorijā - minimālās tehniskās prasības (obligāta)

Jauno datu pārraides savienojumu izveidei MKP teritorijā starp SISTĒMAS, ass svaru un platformas svaru elementiem ir jāizmanto optisko dzīslu kabeļi ar vismaz

12 daudzmodu (Multi Mode) optiskajām dzīslām. Prasības optisko starpsavienojumu izveidei norādītas 31. tabulā.

Projektējot optiskā savienojuma izveidi Ventspils ostas MKP (Plosta iela 7), kas atrodas vairāk kā 600 m attālumā no esošās serveru telpas (Sarkanmuižas

dambis 25A), jāņem vērā, ka potenciālo savienojuma trase varētu šķērsot juridiskās personas (Ventspils Svētā Nikolaja pareizticīgās baznīcas) teritoriju.

Sagatavojot Piedāvājumu, ir jāizvērtē un piedāvājumā arī jāiekļauj alternatīvi risinājumi savienojuma izveidei starp šiem diviem objektiem.

115

31. tabula. Prasības optisko starpsavienojumu izveidei MKP infrastruktūras ietvaros


1. Darba

frekvences viļņa

garums

Robežās λ=1310 nm – 1550 nm;

2. Optisko šķiedru

vājinājums

Mērījumi, kas veikti 20°C temperatūrā, nepārsniedz

sekojošos rādītājus:

a) 0,5 dB/km pie viļņa garuma 1310 nm;

b) 0,3 dB/km pie viļņa garuma 1550 nm.


metināšana

Visi savienojumi līdz servera telpai tiek veikti ar optisko

šķiedru metināšanas tehnoloģiju;

Gadījumā, ja kādā posmā objektīvu apstākļu dēļ nav

iespējams veikt savienojumu metināšanu, tas jānorāda

optisko starpsavienojumu pieņemšanas nodošanas

aktā.


savienošana

Savienojot optiskās šķiedras, jāievēro ražotāja noteikto

krāsu gammas atbilstoši standartam IEC 304.

5. Savienojumu

mērījumu

veikšana

Pēc starpsavienojumu ierīkošanas jāveic ierīkoto

savienojumu mērīšana. Mērījumu rezultātā iegūtās

reflektogrammas jāiesniedz Pasūtītājam.

116

5 NEFUNKCIONĀLĀS PRASĪBAS

Šajā nodaļā ir aprakstīts risinājums, kas paredzēts TL un konteineru numuru automātiskai

identifikācijai, nefunkcionālās prasības.

5.1 Prasības saskarnēm un dizainam

NEF-01 SISTĒMAS saskarnes īpašības (obligāta)

SISTĒMAS lietotāju saskarnei ir jābūt ērtai un ergonomiskai (tādai, kas minimizē SISTĒMAS lietotāja

slodzi, piemēram, viegli uztveramai). SISTĒMA maksimāli izmanto visu tai pieejamo informāciju, lai

atvieglotu un paātrinātu darbu, minimizējot lietotāja manipulāciju skaitu ar ievadierīcēm.

Visai informācijai jābūt attēlotai vienā ekrānā, attēlotajai informācijai dinamiski jāpielāgojas ekrāna

izmēram.

Visas (ekrānformas) SISTĒMAS lietotāja saskarnē attēlojamie un pēc noklusējuma atrādāmie lauki ir

jāprecizē un jāsaskaņo ar Pasūtītāju SISTĒMAS izstrādes analīzes fāzē.

Lietotāja saskarnē iekļautie grafiskie elementi nedrīkst būtiski ietekmēt saskarnes ielādes procesu.

Izstrādes ietvaros, lietotāju saskarnes izveide un ieviešana ir jāveic, ievērojot standartu LVS EN ISO

9241-210:2011 (Cilvēka un sistēmas mijiedarbības ergonomika. 210.daļa: Uz lietotāju orientētie

projektēšanas procesi interaktīvajām sistēmām).

SISTĒMAI jābūt veidotai tā, lai lietotājs to varētu pilnvērtīgi lietot vienlaicīgi vairākos logos, vienlaicīgi

vairākos pārlūkprogrammas logos un cilnēs.

NEF-01.1 SISTĒMAS saskarnes pielāgojamība (vērtējama)

Katram SISTĒMAS lietotājam ir jāspēj pielāgot (konfigurēt) savu SISTĒMAS lietotāju saskarni gan

sarakstos, gan ekrānformās, piemēram, konfigurēt sarakstos attēlojamās kolonnas, kolonnu secību,

noklusētos kārtošanas nosacījumus, konfigurēt ekrānformās attēlojamās informācijas apjomu un

izkārtojumu.

NEF-02 SISTĒMAS saskarnes valoda (obligāta)

SISTĒMAS saskarnei jābūt pieejamai latviešu valodā. Saskarnē izmantotie vārdi un frāzes ir gramatiski

pareizi un atbilst attiecīgajai latviešu valodas terminoloģijai. Saskarnē izmantotajai valodai (vārdiem,

frāzēm) jābūt intuitīvi saprotamai lietotājiem.

117

SISTĒMAS ietvaros, apzīmējot vienu un to pašu lietu dažādās ekrānformās, jābūt izmantotiem vieniem

un tiem pašiem terminiem un zīmēm.

Visiem SISTĒMAS ziņojumiem lietotājiem (t.sk. biznesa kļūdu paziņojumiem) ir jābūt latviešu valodā.

Izņēmums var būt tehniskie paziņojumi, kuri var būt arī angļu valodā, ja iekšējā SISTĒMAS saskarne

tiek veidota, izmantojot trešo pušu izstrādātās programmatūras.

Paziņojumiem ir jābūt lietotājiem viegli saprotamā valodā, precīzi jāskaidro radušās situācijas būtība

un jāpiedāvā tālākās rīcības variants.

NEF-03 Saskarnes izmantošanas ekrāns (obligāta)

SISTĒMAS lietotāja saskarni jāvar lietot uz ekrāna, kas dinamiski pielāgojas lietotāja ekrāna izmēriem (ekrāna izšķirtspējai) – responsīvs dizains. Jānodrošina iespēja atvērt vairākus SISTĒMAS logus vienlaicīgi dažādās cilnēs. NEF-04 Darbības pārtraukšana (obligāta)

Katrai SISTĒMAS lietotāja darbībai jābūt iespējai atcelt tās izvēli līdz datu saglabāšanai SISTĒMĀ,

pārtraucot iecerēto darbību un atstājot datus SISTĒMĀ bez izmaiņām. Darbības pārtraukšanas iespējai

jābūt skaidri redzamai un viegli pieejamai lietotājam.

NEF-05 SISTĒMAS vide (obligāta)

SISTĒMAI jābūt izmantojamai lietotājiem, kuri lieto vismaz Windows operētājsistēmu (versijas

Windows 8.1, Windows 10) un šādas pārlūkprogrammas (Internet Explorer 11.*, Microsoft Edge,

Mozilla Firefox 58+, Google Chrome 65+).

NEF-06 SISTĒMAS laika sinhronizācija (obligāta)

SISTĒMAS programmatūras daļai ir jānodrošina laika sinhronizācija atbilstoši NTP (Network time

protocol) protokolam, precīza laika saņemšana jārealizē no vismaz 1 (viena) VID avota (ar atbilstību

vismaz NTP).

5.2 Prasības SISTĒMAS veiktspējai

NEF-07 SISTĒMAS veiktspējas prasības Notikumu atpazīšanā (obligāta)

SISTĒMAI jāveic visu transportlīdzekļu un kravu konteineru automātisku atpazīšanu, ar precizitāti

vismaz 95% gan transportlīdzekļu numura zīmju, gan konteineru numuru atpazīšanā. Valsts koda

atpazīšanas precizitātei jābūt vismaz 75%.

118

Transportlīdzekļu reģistrācijas numura zīmju un konteineru numuru precizitātes aprēķinā neiekļauj

šādus gadījumus:

Transportlīdzeklis šķērsojis SISTĒMAS darbības zonu ar ātrumu, kas pārsniedz 70km/h;

Transportlīdzeklis ir šķērsojis SISTĒMAS transportlīdzekļu identifikācijas punktu pretējā

virzienā;

Transportlīdzekļi SISTĒMAS TL identifikācijas punktu šķērso ar intervālu, kas ir mazāks par 2

(diviem) metriem (nepārtrauktas secīgas TL plūsmas gadījumā);

Transportlīdzekļa reģistrācijas numura zīmes plāksne vai konteinera numurs ir aizklāts ar

virvēm, rezerves riteni vai citiem objektiem;

Transportlīdzekļa konteinera numura vai reģistrācijas numura zīmes plāksne SISTĒMAS

transportlīdzekļu identifikācijas punkta šķērsošanas gadījuma uzņemtajā attēlā nav cilvēkam

saskatāma, piemēram, numurs vai numura zīme ir netīra, norūsējusi, liekta, tai ir padzisuši

cipari un/ vai burti, vai plāksnes ciparos un/ vai burtos ir iemontētas neparedzētas detaļas

(piemēram, skrūves).

Par objektīvi tīru un salasāmu reģistrācijas numura zīmi tiek uzskatīta numura zīme, kas atbilst

[MK_279 227. punktam].

SISTĒMAS Notikumu apstrādes jaudai jāatbilst paredzamajai satiksmes intensitātei katrā MKP/ RŠV

(skat. 32. tabulā).

32. tabula. Paredzamā satiksmes intensitāte MKP/ RŠV diennakts laikā

MKP/ RŠV TL iebrauc identifikācijas

punktā

TL izbrauc no identifikācijas

punkta

Kaplava 28 36

Meikšāni 12 12

Pededze 100 80

Ventspils (Plosta iela 20/14) 500 500

Liepāja 550 550

Ventspils (Plosta iela 7) 400 400

Silene 540 500

Pāternieki 295 231

Terehova 475 600

Vientuļi 120 120

Rīgas Brīvosta (Kundziņsala) 400 300

Rīgas Brīvosta (Atlantijas iela) 300 350

Grebņeva 240 240

119

TL un konteineru numuru SISTĒMAS atpazīšanas precizitātes mērījumi tiks veikti atbilstoši šādiem

nosacījumiem:

atpazīšanas precizitāte tiek mērīta katra MKP/ RŠV katrai TL plūsmas joslai atsevišķi;

atpazīšanas precizitāte tiek mērīta 1 (vienu) reizi mēnesī (Pasūtītāja noteiktā datumā) visos

MKP/ RŠV (izņemot Kaplavas RŠV, Meikšānu RŠV un Pededzes RŠV) katrai TL plūsmas joslai

atsevišķi, noteiktā datumā un laikā fiksējot secīgus 50 (piecdesmit) notikumu gadījumus, kad

transportlīdzekļi šķērso identifikācijas punktu;

Kaplavas, Meikšānu un Pededzes robežas šķērsošanas vietās katrai TL plūsmas joslai atsevišķi

tiek veikta visu identifikācijas punktu šķērsošanas gadījumu precizitātes analīze katru 3 (trīs)

mēnešu periodā.

SISTĒMAS TL un konteineru numuru atpazīšanas precizitātes manuālai pārbaudei Pasūtītājs izgūs

atskaiti(atskaites saturu skatīt ATP-01 prasībā).

NEF-08 SISTĒMAS ātrdarbība (obligāta)

Veicot SISTĒMAS izstrādi un uzturēšanu, Izpildītājam ir nepieciešams nodrošināt šādas veiktspējas

prasības un ātrdarbība:

SISTĒMAI jānodrošina līdz 500 (pieci simti) vienlaicīgu lietotāju darbība (tiešsaistes režīmā), ja

lietotājs veic 1 (vienu) pieprasījumu katras 10 (desmit) sekundes;

jānodrošina šādu SISTĒMAS ātrdarbības prasību izpilde:

□ visām ekrāna formām, kas nesatur apjomīgu biznesa loģiku, ir pilnībā jāparādās ne

vairāk kā 1 (vienas) sekundes laikā;

□ meklēšanai, kurā datu bāzē atrod līdz 100 (vienam simtam) meklējamām vienībām,

95% (deviņdesmit piecos procentos) gadījumu jānotiek ātrāk par 4 (četrām)

sekundēm;

□ meklēšanai, kurā datu bāzē atrod vairāk kā 100 (vienam simtam) meklējamo vienību,

90% (deviņdesmit procentos) gadījumu jānotiek ātrāk par 10 (desmit) sekundēm. Ja

paredzamais pieprasījuma izpildes laiks ir lielāks par 10 (desmit) sekundēm, tad par

to jāinformē lietotājs;

□ viena ieraksta pievienošanai, aktualizācijai, dzēšanai vai lietojuma funkcijas izpildei

(no brīža, kad lietotājs izsauc komandu, līdz brīdim, kad pieejama informācija par

sekmīgu rezultātu) 95% (deviņdesmit piecos procentos) gadījumu jānotiek ātrāk par

2 (divām) sekundēm.

Gadījumā, ja TS noteiktā minimālā centrālo serveru vai lokālo MKP/RŠV serveru konfigurācija nav

pietiekoša, Pretendentam jāpiedāvā papildus resursi, lai nodrošinātu, ka SISTĒMA nodrošinātu

augstākminētos veiktspējas rādītājus un vienlaicīgi SISTĒMAS tehnisko resursu noslodze nepārsniegtu

60%.(sešdesmit procentus) Jānodrošina iespēja SISTĒMAS administratoriem uzraudzīt SISTĒMAS

veiktspēju, uzkrājot informāciju par būtiskākajiem SISTĒMAS darbības parametriem.

120

NEF-09 SISTĒMAS veiktspējas prasības datu pārsūtīšanai no TL identifikācijas punktiem uz centrālo DB (obligāta)

SISTĒMAI jānodrošina, ka transportlīdzekļu vai kravu konteineru atpazīšanā vizuāli fiksētā informācija

un atpazītie dati no lokālajām transportlīdzekļu identifikācijas punktiem uz centrālo datubāzi tiek

nosūtīti ne ilgāk kā 15 (piecpadsmit) sekundēs no transportlīdzekļa vai kravu konteinera vizuālās

fiksēšanas brīža.

NEF-10 SISTĒMAS datu apstrāde un saglabāšana (obligāta)

SISTĒMAI jāapstrādā un jāsaglabā reāla laika dati par visiem identifikācijas punktu šķērsojušajiem

transportlīdzekļiem (numuru zīmes, konteineru numuri un citi TL parametri), kas iebrauc ES teritorijā

un izbrauc no tās.

NEF-11 SISTĒMAS izmantošanas ietekme uz darbinieku veiktspēju (obligāta)

SISTĒMAS izmantošana nedrīkst ierobežot vai kavēt robežkontroles procesu.

SISTĒMAS uzturēšanas darbi un dublējuma operācijas nedrīkst negatīvi ietekmēt SISTĒMAS ikdienas

operatīvo darbību.

NEF-12 SISTĒMAS darbības nepārtrauktība (obligāta)

SISTĒMAI jābūt nepārtrauktai pieejamībai 24 (divdesmit četras) stundas diennaktī un 7 (septiņas)

dienas nedēļā. Dīkstāves laiks, kas radies kritisku (saskaņā ar prasībā ORG-11 “SISTĒMAS

programmatūras piegāde un uzstādīšana” aprakstīto problēmu klasifikāciju) bojājumu, trūkumu un

darbības traucējumu rezultātā, nedrīkst pārsniegt 120 (simts divdesmit) stundas 3 (trīs) mēnešu

periodā. SISTĒMAS dīkstāves laiks tiek aprēķināts, skaitot kopā laiku, kurā netiek nodrošināta

pilnvērtīga (atbilstoši visām TS prasībām) SISTĒMAS darbība 1 (vienā) transporta braukšanas joslā.

10 – koeficients, ja SISTĒMAS darbība nav pilnvērtīga centrāli, bet darbojas visi identifikācijas punkti,

piemēram,

Ja SISTĒMAS darbība nav pilnvērtīga tikai centrāli, bet visi identifikācijas punkti darbojas

pilnvērtīgi 2 stundas:

□ Dīkstāves laiks = 10 * 2

Dīkstāves laiks tiek rēķināts pusstundās, katru iesākušos pusstundu noapaļojot uz augšu, piemēram:

Ja SISTĒMAS darbība nav pilnvērtīga 1 identifikācijas punkta 1 joslā 2 stundas un 35 minūtes:

□ Dīkstāves laiks = 1* 3

Ja SISTĒMAS darbība nav pilnvērtīga 1 identifikācijas punkta 3 joslās 1 stundu un 59 minūtes:


121

Ja SISTĒMAS darbība nav pilnvērtīga 1 visā identifikācijas punktā, kurā ir 6 joslas, 2 stundas

un 15 minūtes:

□ Dīkstāves laiks = 6 * 2,5

Ja SISTĒMAS darbība nav pilnvērtīga 2 identifikācijas punktos, kuros ir 5 un 3 joslas, 2 stundas

un 1 minūte:

□ Dīkstāves laiks = 8 * 2,5

Ja SISTĒMAS darbība nav pilnvērtīga gan centrāli, gan 9 identifikācijas punktos (kopā ir 9

identifikācijas punkti ar kopēji 30 joslām) 2 stundas:


Vienas joslas nepārtraukta dīkstāve nedrīkst pārsniegt 24 (divdesmit četras) stundas, un vienas joslas

dīkstāves periodi nedrīkst būt tuvāki par 12 (divpadsmit) stundām.

Dīkstāves laiks tiek rēķināts no brīža, kad informācija par SISTĒMAS darbības traucējumiem ir

reģistrēta Pasūtītāja Informācijas sistēmu izmaiņu pārvaldības sistēmā (ISIPS) līdz brīdim, kad šajā pašā

vidē saņemts paziņojums par SISTĒMAS darbības traucējumu novēršanu.

NEF-13 Programmatūras nodevumu uzstādīšanas ietekme uz SISTĒMAS pieejamību (obligāta)

SISTĒMAI nepieciešams nodrošināt augstu pieejamību tās lietotājiem un tādu SISTĒMAS arhitektūras

kvalitāti, lai SISTĒMAS darbība ir stabila, un SISTĒMAS programmatūras nodevumu uzstādīšanu ir

iespējams veikt ar minimāliem pārtraukumiem. Uzstādot SISTĒMAS programmatūras nodevumus,

SISTĒMAS darbības pārtraukumi kopumā nedrīkst pārsniegt 24 (divdesmit četras) stundas 12

(divpadsmit) mēnešu laikā.

NEF-14 Lietotāju aizvietošana (vērtējama)

SISTĒMAI jānodrošina lietotāju aizvietošanas funkcionalitāte, lai realizētu informācijas apstrādes

nepārtrauktību, piemēram, viena lietotāja ilgstošas prombūtnes gadījumā ir jābūt iespējai norādīt citu

lietotāju, kas var izpildīt prombūtnē esošā lietotāja lomas un aktivitātes SISTĒMĀ.

5.3 Prasības SISTĒMAS uzturamībai

Uzturamība nozīmē to, cik viegli var uzturēt SISTĒMU normālā darbības stāvoklī - atjaunot, paplašināt

vai kā citādi modificēt, lai atspoguļotu mainīgās prasības. SISTĒMAS labākai uzturamībai jānodrošina

šādi nosacījumi:

122

NEF-15 SISTĒMAS funkcionalitātes definēšana un mainīšana (obligāta)

Iespēja definēt un mainīt SISTĒMAS funkcionalitāti ar SISTĒMAS lietotāja definētu parametru

palīdzību, iespēja mainīt SISTĒMĀ izmantotās formulas (pretēji gadījumam, kad izmaiņas jāievieš

SISTĒMAS pirmkodā).

NEF-16 Dalījums moduļos (obligāta)

Piedāvātajai SISTĒMAI jābūt modulārai, maksimāli paredzot savstarpēji nesaistītus moduļus, kas

nodrošinātu, ka SISTĒMA ir viegli uzturama, pielāgojama un ar iespēju mainīt konkrēto moduli, pēc

iespējas minimāli ietekmējot visu SISTĒMU. Kā atsevišķs modulis ir jānodrošina TL (t.sk. piekabes,

konteinera/-u) numuru atpazīšanas algoritms, lai tas būtu atjaunināms un aizvietojams.

NEF-17 SISTĒMAS pielāgojamības un turpmākās attīstības prasības (obligāta)

Piedāvātajai SISTĒMAI ir jābūt izstrādātai tā, lai būtu iespējama tās turpmākā attīstība, pilnveidojot

programmatūras funkcionalitāti un integrējot SISTĒMAS centrālās DB un centrālās

lietojumprogrammatūras pilnveidojumus.

Piemērs nākotnes iespējamiem SISTĒMAS pilnveidojumiem ir atpazīto transportlīdzekļu vai kravu

konteineru datu sasaiste ar kravu rentgena iekārtas ieskenētajiem datiem.

5.4 Prasības autentifikācijai un autorizācijai

NEF-18 Autentifikācija (obligāta)

Pirms uzsākt jebkuras darbības ar SISTĒMU, SISTĒMAS lietotājam ir jāautentificējas SISTĒMĀ.

Lietotājam jānodrošina iespēja darba pārtraukšanai (log-out).

NEF-19 Autentifikācijas veidi (obligāta)

SISTĒMĀ jānodrošina divu veidu lietotāju autentifikācijas iespējas, izmantojot AD lietotāju ierakstus,

ko izmantos VID darbinieki, un SISTĒMAS lietotāju ierakstus, ko izmantos ārējie lietotāji.

NEF-20 Ielogošanās SISTĒMĀ (obligāta)

Lietotāja autentifikācija SISTĒMĀ jānodrošina ar lietotāja identifikāciju un lietotāja paroli.

SISTĒMA neierobežo nepareizu datu ievadīšanas skaitu, tomēr reģistrē katru neveiksmīgu

pieslēgšanās mēģinājumu.

Lietotājam ir jāvar apstiprināt ievadītos autentifikācijas datus un pieslēgties SISTĒMAI.

123

Pēc veiksmīgas lietotāja reģistrācijas, SISTĒMAI jāuzsāk lietotāja darbību reģistrācija.

Lietotāja aktīvā sesija netiek pārtraukta pat tad, ja lietotājs nav lietojis SISTĒMU ilgāku (konfigurācijā

norādāmu) laiku.

NEF-21 Autentifikācijas datu validācija (obligāta)

SISTĒMAI jāveic autentifikācijas datu validācija.

Validācijas paziņojumi ir sekojoši:

ja nav ievadīts lietotājvārds - Ievadiet lietotājvārdu;

ja nav ievadīta parole - Ievadiet paroli;

ja ievadītā paroles un lietotājvārda kombinācija nesakrīt ar datubāzes datiem - lietotājvārds

vai parole nav pareizas.

SISTĒMA nepaziņo par to, kurš no diviem laukiem ir nepareizs neveiksmīgas pieslēgšanās gadījumā,

lai paaugstinātu drošības līmeni.

NEF-22 Lietotāja parole (obligāta)

SISTĒMAI jāveic ārējā lietotāja paroles derīguma termiņa pārbaude un ik pēc noteikta laika jāparāda

ārējam lietotājam paziņojums, par to, ka paroles derīguma termiņš ir beidzies un parole ir jānomaina.

SISTĒMA neļauj ārējām lietotājam ielogoties, kamēr parole nav nomainīta.

SISTĒMAI datu bāzē jāglabā katra lietotāja paroles izveidošanas datums. Tāpat tiek saglabātas 3 (trīs)

pēdējās paroļu kontrolsummas, tādejādi neļaujot lietotājiem izmantot paroles, kuras jau ir izmantotas

nesenā vēsturē.

NEF-23 Lietotāja identificēšana (obligāta)

SISTĒMAI jānodrošina, ka lietotājs tiek identificēts, pirms tiek atļauta jebkāda cita darbība ar SISTĒMU.

Nesekmīgas identifikācijas gadījumā lietotājam jāsaņem paziņojums, ka identifikācija ir nesekmīga,

nedodot papildu informāciju, kas var palīdzēt veikt lietotājvārdu vai paroļu pārlasi.

Jānodrošina, ka neidentificētiem lietotājiem SISTĒMĀ ir atļauts veikt tikai sevis identifikāciju un uzsākt

autentifikāciju SISTĒMĀ.

NEF-24 Autorizācija (obligāta)

Labvēlīgas autentifikācijas gadījumā SISTĒMA piešķir lietotājam atbilstošu tiesību komplektu –

autorizē lietotāju veikt šim lietotājam atļautās darbības, atbilstoši piešķirtajām lietotāja tiesībām.

124

5.5 Prasības SISTĒMAS konfigurācijai

NEF-25 SISTĒMAS parametrizācija (obligāta)

Ņemot vērā iespējamās izmaiņas likumdošanā, normatīvajos aktos un SISTĒMAS lietotāju vajadzībās,

ir jāparedz SISTĒMAS parametrizācijas izmantošana. Parametru izmaiņas jāvar nodrošināt SISTĒMAS

administratoram vai deleģētai personai, izmantojot SISTĒMAS līdzekļus, mainot parametru, nevis

izdarot izmaiņas programmatūras pirmkodā un uzstādot jaunu programmatūras versiju.

NEF-26 SISTĒMĀ paredzētā konfigurācija (obligāta)

SISTĒMĀ jāparedz vismaz šāda kopēja SISTĒMAS konfigurācija:

SISTĒMAI jābūt konfigurējamai ar iespēju datu apmaiņai ar citām valstīm.

SISTĒMAI jābūt konfigurējamai, lai būtu iespējams izveidot un pielāgot filtrus atbilstoši

lietotāju vajadzībām.

SISTĒMAI jābūt konfigurējamai ar iespēju lietotājam ar atbilstošām tiesībām mainīt

atpazīšanas precizitātes noteikšanas parametrus. SISTĒMĀ jābūt konfigurējamai lietotāja

paroles sarežģītībai.

SISTĒMĀ jāvar konfigurēt tehnoloģiskos lietotājus. Izpildītājam jānodrošina, ka SISTĒMAS

servisi, iekšējie un ārējie datu apmaiņas procesi tiek pildīti tikai ar tehnoloģisko lietotāju

kontiem, kuriem informācija ir pieejama tikai tādā apjomā, kas nepieciešama attiecīgās datu

apmaiņas nodrošināšanai, lai nepamatoti augstu privilēģiju izmantošana, kur tas nav

nepieciešams, neradītu nevajadzīgus datu integritātes, konfidencialitātes un pieejamības

riskus.

SISTĒMAI jābūt konfigurējamai, lai atpazītu visas prasībā NK-02 definētajās valstīs izsniegtās

numura zīmes. SISTĒMAI jābūt konfigurējamai, lai nepieciešamības gadījumā SISTĒMA spētu

atpazīt arī citās valstīs izsniegtās numura zīmes.

SISTĒMAI jābūt konfigurējamai, lai lietotājiem ar atbilstošām tiesībām ir iespēja izveidot

dažāda veida atskaites.

Kopēju SISTĒMAS konfigurāciju lietotājam ar atbilstošām tiesībām jāvar pārvaldīt no administratora

moduļa lietotāja saskarnes tā, lai nebūtu nepieciešams programmatūras izejas koda izmaiņas un

jaunas programmatūras versijas uzstādīšana.

SISTĒMĀ jāparedz vismaz šāda individuāla SISTĒMAS konfigurācija:

SISTĒMAI ir jābūt konfigurējamai, lai lietotājs varētu mainīt saskarnes krāsas.

SISTĒMAI jābūt konfigurējamai, lai lietotājam atbilstoši piekļuves tiesībām būtu iespēja

konfigurēt lietotāja saskarni.

Individuālu SISTĒMAS konfigurāciju lietotājam ar atbilstošām tiesībām jāvar pārvaldīt tā, lai nebūtu

nepieciešams programmatūras izejas koda izmaiņas un jaunas programmatūras versijas uzstādīšana.

125

5.6 Prasības datu migrēšanai

NEF-27 Datu migrācija (obligāta)

SISTĒMAS ieviešanas 1.posma rezultātā Izpildītājam jānodrošina, ka SISTĒMĀ lietotāji vienkopus un

vienveidīgi var strādāt ar SISTĒMĀ radītajiem datiem (no jaunā/-iem objekta/-iem) un ar esošajā

TLKAIS sistēmā radītiem datiem (kurus turpina radīt MKP/RŠV objektos esošās TLKAIS sistēmas

komponentes, kamēr tās nav pārbūvētas/papildinātas ar SISTĒMAS elementiem).

Līdz ar SISTĒMAS uzstādīšanu visos objektos (skat. 11.tabulā), t.i. esošā TLKAIS sistēma ir pilnībā

pārbūvēta/papildināta atbilstoši šīs tehniskās specifikācijas prasībām, Izpildītājam ir jānodrošina

vēsturisko datu migrācija no esošās TLKAIS sistēmas uz jauno SISTĒMU (lai vairs nav jādarbina

1.posma rezultātā radītā iespēja strādāt vienlaicīgi ar abu sistēmu datiem), pirms tam veicot vismaz

šādas aktivitātes:

jāizstrādā un ar Pasūtītāju jāsaskaņo datu migrācijas plāns;

jāsagatavo datu migrācijas skripti un datu migrācijas instrukcijas;

jāsagatavo datu migrācijas kvalitātes pārbaudes (skriptu veidā vai kā savādāk), kas ļauj

pārliecināties par datu migrācijas kvalitatīvajiem un kvantitatīvajiem rezultātiem,

Migrācijas procesā jāpārnes vismaz šādi dati:

Notikumu ieraksti;

Trauksmju ieraksti;

Riska profili.

Laika periods, kurā dati jāmigrē, precizējams analīzes fāzes laikā.

Izpildītājs nav atbildīgs par pārņemamo vēsturisko datu līdzšinējo kvalitāti (t.sk. neprecizitātes datos

u.tml.) un Izpildītājam nav jāveic šo kvalitātes nepilnību labošana (jāparedz, ka to veiks Pasūtītājs).

Datu migrācijas procesā jāveic datu savstarpēja validācija un sasaiste. Konflikta gadījumus jāreģistrē

sarakstā. Datu migrācijas laikā jāveido migrācijas procesa žurnalifikācija, kurā jāizceļ datu

konfliktsituācijas, migrācijas kļūdas.

Izpildītājam bez papildus maksas latviešu valodā jānodrošina konsultatīvs atbalsts Pasūtītājam esošās

TLKAIS sistēmas datu migrēšanā uz jauno SISTĒMU.

126

5.7 Prasības SISTĒMAS darbības pārbaudei

NEF-28 SISTĒMAS darbības pārbaude (obligāta)

SISTĒMĀ jābūt realizētai automatizētai nepārtrauktai SISTĒMAS darbības uzraudzībai, informāciju par

darbības traucējumu (t.sk. bojājumu/ bojājumiem) SISTĒMA nosūta automātiski SISTĒMAS

administratoram vai citam norādītam SISTĒMAS lietotājam.

SISTĒMĀ jābūt iespējai konfigurēt informāciju par bojājumu - vismaz informācijas saņēmējus un

saņemšanas veidu.

SISTĒMAS izstrādes analīzes fāzē nepieciešams precizēt prasību.

NEF-29 Piekļuve SISTĒMAS darbības pārraudzības komponentei (obligāta)

Piekļuve SISTĒMAS darbības pārraudzības komponentei jānodrošina atsevišķai lietotāju grupai, kas

var tiešsaistē skatīt SISTĒMAS darbības korektuma informāciju un, nepieciešamības gadījumā, pieteikt

bojājumu, kļūdu u.tml.



NEF-30 Prasības SISTĒMAS programmatūras monitoringam (obligāta)

Piedāvātās SISTĒMAS (t.sk ass svaru un platformas svaru) programmatūras darbības monitoringam

jābūt savietojamam ar VID rīcībā esošo uzraudzības sistēmu Zabbix un VID izmantoto datortīkla

drošības pārvaldības risinājumu IBM Security Qradar SIEM. Pretendentam jāveic visu SISTĒMAS

elementu integrācija VID uzraudzības sistēmā Zabbix (v.3.4 vai uz integrācijas brīdi jaunākā) un VID

datortīkla drošības pārvaldības risinājumā IBM Security Qradar SIEM (nodrošinot SISTĒMAS notikumu

nodošanu, izmantojot syslog protokolu), jāizstrādā SISTĒMAS iekārtu un programmatūras

uzraudzības parametrus (items), bojājumu ziņojumus (triggers) vienotā šablonā (template) un

jāizveido SISTĒMAS grafiskā attēlojuma karte (map) un svarīgāko SISTĒMAS darbības parametru

attēlojošu logu (screen).

NEF-31 SISTĒMAS pārvaldības uzraudzība (obligāta)

SISTĒMAI jānodrošina tiešsaistes integrācija ar VID centralizēto drošības uzraudzības risinājumu IBM

Security Qradar SIEM, kas savāc un analizē žurnālierakstus:

no sistēmu un notikumu žurnāliem (piem., izmantojot Syslog/Eventlog u.c.);

no datu bāzēm (piem., izmantojot Oracle DB listener u.c.);

no datnēm (piem., izmantojot SMB Tail u.c.);

127

no tīklā pieslēgtajām ierīcēm (piem., izmantojot SNMP v1, v2, v3, TLS, PCAP u.c.).

Prasības realizācijas risinājums var būt atkarīgs no Pretendenta piedāvātā risinājuma un var tikt

precizēts analīzes un projektējuma izstrādes laikā. Monitorējamie žurnālieraksti un notikumi jāprecizē

un jādefinē analīzes un projektējuma izstrādes laikā.

5.8 Prasības SISTĒMAS drošībai

NEF-32 SISTĒMAS drošībai izmantojamie standarti (obligāta)

SISTĒMAS programmatūrai jābūt izstrādātai bez OWASP mājas lapā reģistrētām biežāk pieļautajām

drošības ievainojamībām, kā arī Pretendentam jānodrošina SISTĒMAS atbilstība LVS ISO/IEC 15408-

2:2011 “Informācijas tehnoloģija. Drošības metodes. Kritēriji informācijas tehnoloģiju drošības

novērtēšanai. 2. daļa: Drošības funkcionālās prasības” noteiktajām funkcionālajām drošības prasībām,

par ko Pasūtītājs pārliecināsies pirms SISTĒMAS nodošanas ekspluatācijā, pasūtot drošības auditus.

Pretendentam jāievēro 2015. gada 28. jūlija Ministru kabineta noteikumi Nr. 442 “Kārtība, kādā tiek

nodrošināta informācijas un komunikācijas tehnoloģiju sistēmu atbilstība minimālajām drošības

prasībām”.

NEF-33 Prasības SISTĒMAS antivīrusa programmai (obligāta)

SISTĒMAS programmatūrai jābūt aizsargātai ar antivīrusa programmatūru. SISTĒMAS programmatūrai

jānodrošina arī saņemto/ienākošo datņu apstrāde (piemēram, XML failu no citām valstīm) pret

ļaundabīgo kodu un vīrusiem.

SISTĒMAS un operētājsistēmas antivīrusa programmas un antivīrusa licenču uzturēšanu jānodrošina

Izpildītājam.

NEF-34 Datu apmaiņas drošības prasības (obligāta)

Realizējot datu apmaiņu starp SISTĒMAS komponentēm, piemēram, starp lietojumserveri un

datubāzi, jāparedz, ka pārraidāmos datus nevar izsekot un dabūt datus, vienkārši mainot parametrus

servisa pieprasījumā.

NEF-35 Prasības datu atjaunošanai (obligāta)

Jānodrošina iespēja veikt SISTĒMAS datu rezerves kopiju veidošanu un atjaunošanu no rezerves

kopijas izmantojot IBM Spectrum Protect programmatūru. Visas nepieciešamās licences jāiekļauj

piedāvājumā. Datu bāzei un lietotnes serveriem rezerves kopijas izveidošana jānodrošina bez

128

SISTĒMAS darbības pārtraukšanas. Izpildītājam jāizstrādā un jānotestē SISTĒMAS darbības

atjaunošanas plāns.

NEF-36 SISTĒMAS drošības prasības (obligāta)

Veicot SISTĒMAS izstrādi vai uzturēšanu, Izpildītājam ir nepieciešams nodrošināt sekojošas drošības

prasības:

savienojumi gan administrēšanas vajadzībām, gan starp lietotājiem, kuri izmanto SISTĒMU, ir

šifrēti (ar vismaz 256 bitu atslēgu);

nepieļaut Cross-site scripting (XSS) ievainojamības web lietojumprogrammā, kad ir iespējams

izsaukt formu ar mainītiem parametriem, kas izpilda JavaScript kodu;

nepieļaut SQL injekcijas tipa ievainojamību un nekorekto SQL vaicājumu izsaukumu, pielietot

parametrizēto SQL vaicājumu izsaukumu;

nodrošināt SISTĒMAS programmatūras darbību ar konfigurāciju, kas pieļauj tikai HTTP GET,

HTTP POST, HTTP HEAD metožu izmantošanu;

nodrošināt, ka SISTĒMAS programmatūra lietotājam nesniedz informāciju, kas varētu

apdraudēt SISTĒMAS un/ vai VID IS drošību, tai skaitā, nepieļaujot iespēju lietotājam veikt

analīzi par kļūdas un veikto SISTĒMAS pārbaužu raksturu. Kļūdas situācijās lietotājam parādīt

nepieciešamo informāciju, detalizētu tehnisko informāciju, nosūtot SISTĒMAS

administratoram un veicot informācijas ierakstīšanu SISTĒMAS auditācijas pierakstos, lai

pārāk detalizēti kļūdu paziņojumi neļauj lietotājam iegūt nevēlamu informāciju par

izmantotajām tehnoloģijām, SISTĒMAS un VID IS arhitektūru un veiktajām drošības

pārbaudēm, kas varētu atvieglot tālākos uzbrukumus SISTĒMAS un/ vai VID IS;

Izpildītājam ar darbiniekiem ir noslēgti konfidencialitātes līgumi, kas paredz noteikumus un

atbildību darbā ar klientu datiem, kā arī esošie darba līgumi un procedūras paredz

noteikumus darbībām ar parolēm un citiem parametriem, kas nosaka piekļuvi.

Pirms SISTĒMAS nodošinas tiks veikts

5.9 Prasības datu un dokumentu arhivēšanai

NEF-37 Datu arhivēšana (obligāta)

SISTĒMAI jānodrošina iespēja veikt visu datu arhivēšanu.

Arhivēšanas funkciju izpildi jāvar organizēt automātiski bez lietotāja iesaistes.

Lietotājam (ar atbilstošajām tiesībām) jābūt iespējai norādīt un mainīt parametrus, kas nosaka, cik ilgi

dati jāglabā arhīvā.

Arhivējamie dati un to noklusētie arhivēšanas nosacījumi jāprecizē analīzes fāzes laikā.

129

5.10 Prasības SISTĒMAS ieviešanai

NEF-38 SISTĒMAS elementu ieviešanas secība (obligāta)

SISTĒMAI izstrādes un ieviešanas process varētu tikt realizēts vairākās kārtās, atkarībā no Pasūtītājam

pieejamā budžeta un iesniegtajiem Pretendentu piedāvājumiem.

Lai nodrošinātu jaunās Sistēmas darbību, vienlaicīgi turpinot esošā TLKAIS risinājuma ekspluatāciju

līdz tā pilnīgai nomaiņai, tiek paredzēts šāds projekta realizācijas scenārijs:

Sistēmas centrālā objekta un Pasūtītāja norādīto 1 (viena) vai vairāku objektu projektēšana un

būvniecība sākas no līguma noslēgšanas brīža. Objektu projektēšana tiek uzsākta pēc

pasūtījuma veikšanas, ievērojot ORG-37 noteiktos darbu izpildes termiņus;

Atbilstoši uzvarējušā Pretendentu sagatavotajiem piedāvājumiem un to kopējās summas

Pasūtītājs izvērtē projekta ieviešanas iespējas vienā posmā vai vairākos posmos;

Tas paredz sagatavot detalizētu ieviešanas plānu, ņemot vērā augstāk minētos faktorus.

Kopējā pieeja projekta posmu realizācijai ir sekojoša:

Sistēmas izstrāde un centrālā mezgla infrastruktūras ieviešana;

Pasūtītāja norādīto Sistēmas objektu infrastruktūras projektēšana un ieviešana (saskaņojot to

ar Sistēmas centrālā mezgla infrastruktūras ieviešanu) – objektu ieviešanu uzsāk tikai pēc

centrālā mezgla ieviešanas;

Tiek veikta pakāpeniska Sistēmas objektu ieviešana un pieslēgšana centrālā mezgla

infrastruktūrai, attiecīgi izslēdzot attiecīgo objektu TLKAIS infrastruktūru;

Paralēli tiek darbināta TLKAIS infrastruktūra vēl nepārbūvētajos objektos;

Pēc visu esošo TLKAIS objektu pārbūves un Sistēmas jauno objektu ieviešanas veic esošās

TLKAIS sistēmas centrālās infrastruktūras datu migrāciju uz Sistēmas centrālā mezgla

infrastruktūru.

Pēc augstāk minētās datu migrācijas esošā TLKAIS risinājuma elementi tiek izslēgti un

Pasūtītāja darbinieki izmanto tikai jaunās Sistēmas resursus.

130

6 ORGANIZATORISKĀS PRASĪBAS


identifikācijai, organizatoriskās prasības.

6.1 Prasības nodevumiem un dokumentācijai

ORG-01 Nodevumu piegāde (obligāta)

Visi Nodevumi (gan programmatūras nodevumi, gan dokumentācijas nodevumi) Izpildītājam ir

jāpiegādā saskaņā ar līguma projekta 5. un 6.punktu un līguma projekta 0.1.0.pielikumā aprakstīto

sadarbības kārtību.

ORG-02 Programmatūras nodevumu piegāde (obligāta)

Programmatūras nodevumus jāpiegādā uzstādīšanai gan Pasūtītāja akcepttesta vidē, gan Pasūtītāja

produkcijas vidē, ar norādi par programmatūras nodevuma instalēšanas paketes uzstādīšanas vidi, ja

tehniski nav iespējams piegādāt programmatūras nodevuma instalēšanas paketi, kas izmantojama

abās vidēs. Programmatūras instalēšanas paketei jābūt “inkrementālai” t.i. tās uzstādīšana ir veicama

uz iepriekš piegādātas versijas. Programmatūras nodevumi nedrīkst ietekmēt datu bāzē jau esošos

datus, ja vien tas nav iepriekš īpaši saskaņots vai nav nodevumu objekts. Gadījumos, ja tiek mainīta

datu bāzes struktūra, jāpiegādā arī atbilstošie datu migrācijas skripti. Visiem nodevumiem ir

jānodrošina versiju identifikācija un kontrole.

Programmatūras nodevumā ietilpst vismaz sagatavotā programmatūra ar pavaddokumentiem (skat.

ORG-04 prasību), programmatūras pirmkodi, instalācijas pakotne ar programmatūras izpildkodiem,

datubāzes skripti, datubāzes modelis.

Kopā ar programmatūras nodevumiem ir jāpiegādā programmatūras nodevumu uzstādīšanas

instrukcija, lai programmatūras nodevumu uzstādīšanu Pasūtītāja akcepttesta un produkcijas vidēs

var veikt Pasūtītāja darbinieki.

ORG-03 Izstrādājamie kopējie Projekta dokumenti (obligāta)

Izpildītājam jāizstrādā un jāiesniedz VID vismaz šāda dokumentācija saskaņā ar projekta plānu:

Projekta pārvaldības plāns (tajā skaitā projekta laika grafiks (projekta plāns) un projekta

kvalitātes nodrošināšanas plāns);

SISTĒMAS arhitektūras apraksts (tajā skaitā SISTĒMAS loģiskā un fiziskā arhitektūra un to

komponenšu apraksts);

131

SISTĒMAS darbības uzraudzības instrukcija un darbības atjaunošanas plāns;

SISTĒMAS instalēšanas plāns;

jebkāda cita dokumentācija, kas tiek radīta un būtiski ietekmē SISTĒMAS ieviešanu vai tās

turpmāku ekspluatāciju.

Visi Projekta dokumenti jāsagatavo latviešu valodā.

Izpildītājam, nepieprasot papildus samaksu, jānodrošina Projekta dokumentu aktualizēšana un

atkārtota iesniegšana Pasūtītājam, ja Projekta laikā ir veiktas izmaiņas.

Projektu dokumentu saraksts var tikt precizēts Projekta gaitā un ir iespējams apvienot vai izstrādāt

papildus Projekta dokumentus, saskaņojot ar VID.

ORG-04 Izstrādājamie dokumenti programmatūras sadaļai (obligāta)

Izpildītājam izstrādes laikā jāizstrādā un jāiesniedz VID programmatūras sadaļas dokumentācija:

SISTĒMAS programmatūras prasību specifikācija;

SISTĒMAS programmatūras projektējuma apraksts;

izmaiņu projektējuma apraksts;

Numuru atpazīšanas algoritmu apraksts;

datubāzes struktūras apraksts;

SISTĒMAS testēšanas dokumentācija (tajā skaitā testēšanas plāns, testpiemēru specifikācija,

testēšanas kopsavilkuma pārskats un testu protokoli);

SISTĒMAS lietotāja dokumentācija (tajā skaitā administratora rokasgrāmata un SISTĒMAS

lietošanas instrukcija);

SISTĒMAS programmatūras instalēšanas/uzstādīšanas instrukcija.

ORG-05 Izstrādājamie projekta fāzes dokumenti infrastruktūras sadaļai (obligāta)

Jānodrošina detalizētas SISTĒMAS infrastruktūras projekta fāzes dokumentācijas komplekts:

jānodrošina SISTĒMAS infrastruktūras dokumentācijas izstrāde atbilstoši MK noteikumu Nr.

281 “Noteikumi par Latvijas būvnormatīvu LBN 202-15 "Būvprojekta saturs un noformēšana"”

prasībām;

jānodrošina arī Serveru telpā un pie TL joslām esošo skapju elementu principiālās shēmas un

fasāžu rasējumus;

SISTĒMAS risinājuma slēguma blokshēma, ieskaitot arī serveru telpā izvietotos elementus;

SISTĒMAS risinājuma elektrobarošanas principiālā shēma;

SISTĒMAS risinājuma vājstrāvas risinājuma principiālā shēma;

uz mastiem montējamo savienojumu elementu savienojuma shēma;

132

zibensaizsardzības risinājuma aprēķins un rasējumi atbilstoši LVS EN 62305;

katra stiprinājuma masta detalizācija ar piestiprināto elementu augstuma atzīmēm un

stiprinājumu pret asfalta līmeni (fasāde), ar izmantotajiem zibensaizsardzības risinājuma

elementiem;

stiprinājuma mastu un aparatūras skapju izvietojums (fasāde) attiecībā pret pārvietojamajām

transporta vienībām uz ceļa segumu (arī ar iespējamās apdraudējuma zonas norādi, ko var

izraisīt nenostiprinātās transportlīdzekļu aizmugurējās durvis), iespējamo norobežotāju

izvietojums.

ORG-06 Izstrādājamie nodošanas dokumenti infrastruktūras sadaļai (obligāta)

Jānodrošina detalizētas SISTĒMAS infrastruktūras nodošanas fāzes dokumentācijas komplekts:

SISTĒMAS infrastruktūras izpilddokumentācijas komplekts (elektroniski un papīra

dokumentācijas veidā);

segto darbu protokoli un izmantoto materiālu ekspluatācijas īpašību deklarācijas latviešu

valodā;

veikto kabeļu (optikas un vara) mērījumu protokoli;

elektrobarošanas kabeļu izolācijas pretestības un fāze-nulle pretestības mērījumi;

zemējuma kontūra pretestības mērījumi;

akcepttestu sagatavotie protokoli;

izmantoto materiālu/iekārtu specifikācijas tabula, ar norādīto materiāla ražotāju, modeli un

sērijas numurs (ja tāds eksistē).

ORG-07 Prasības programmatūras piegādēm (obligāta)

Izpildītājam jāpiegādā Pasūtītājam izpildfaili un programmatūras pirmkods. Piegādes veids (datu

nesējos, Pasūtītāja koda repozitorijā vai citādi) jāsaskaņo ar Pasūtītāju pirms pirmkoda piegādes.

Izpildītājam jāpiegādā Pasūtītājam visas SISTĒMAS programmatūras pirmkods tādā formā, lai to (visu

vai konkrētu daļu – saskaņā ar Izpildītāja norādījumiem) bez modifikācijām Pasūtītājs var nokompilēt

(ja piegādātais programmatūras pirmkods ir kompilējams). Kopā ar piegādāto pirmkodu, ir jāpiegādā

arī kompilēšanas instrukcija, t.sk. prasības kompilēšanas videi.

Programmatūras nodevumos iekļautajiem programmatūras pirmkodiem ir jābūt skaidri un precīzi

dokumentētiem, tai skaitā programmatūras kodam jāsatur komentāri latviešu vai angļu valodā, kas ir

viegli saprotami atbilstošas kvalifikācijas speciālistiem bez pirmkoda autora palīdzības, un tie atbilst

Līguma 0.5.0.pielikumā norādītajiem programmatūras izstrādes standartiem. Programmatūras

pirmkodā komentāru veidā ir jābūt norādītai vismaz šādai informācijai:

funkcijas atribūtu apraksts, tai skaitā tās uzdevumu, parametru, paredzamo kļūdu, iespējamo

rezultātu uzskaitījums un detalizējums (metožu līmenī);

133

veiktie labojumi, to autori un labošanas datumi (klašu līmenī);

konkrētā faila autors, izveidošanas datums (klašu līmenī).

Piegādātā programmatūras pirmkoda kvalitātei ir jābūt pietiekošai, lai Pasūtītāja paša vai tā nolīgts

trešās puses kvalificēts personāls varētu nodrošināt programmatūras turpmāko uzturēšanu,

modificēšanu, paplašināšanu, kā arī iespējamo migrēšanu.

SISTĒMAS programmatūras modulim, kas veic TL numura zīmju un konteineru identifikācijas numuru

atpazīšanu (optical character recognition engine) jābūt nomainām (t.i. aizstājams ar citu standarta

programmatūras moduli, kas veic to pašu funkcionalitāti). Šādam modulim programmatūras pirmkods

var netikt piegādāts.

Ja Izpildītājs SISTĒMAS risinājumam izmanto standarta programmatūru, tad Izpildītājam ir jāpiegādā

programmatūras pirmkods, pielāgojumu pirmkodi un konfigurācijas datnes (skripti). Standarta

programmatūras lietošanas gadījumā Izpildītājam jāpiegādā dokumentācija, kurā detalizēti aprakstīti

ievades un izvades parametri. Standarta programmatūras lietošanas gadījumā Izpildītājam un

Pasūtītājām ir jābūt neierobežotām tiesībām lietot šo programmatūru.

Programmatūras izpildkods ir Izpildītājam jāpiegādā Pasūtītājam instalācijas pakotnēs, kas ļauj to

uzstādīt akcepttestēšanas un produkcijas vidē atbilstoši uzstādīšanas instrukcijai, administratora

rokasgrāmatai un citai dokumentācijai. Kopā ar programmatūras izpildkodu ir jāpiegādā arī

konfigurācijas skripti vai datnes, kas nepieciešamas programmatūras uzstādīšanai un darbināšanai.

Izstrādātājam TP ir jāapraksta programmatūras dokumentēšanas principi, apjoms un jāsniedz

programmatūras dokumentācijas un pirmkodu piemēri.

ORG-08 Prasības dokumentācijas nodevumiem (obligāta)

Izpildītājam jāpiegādā Pasūtītājam dokumenti kā shēmas, attēli, grafiki u.tml. arī izejas failu veidā.

Visiem dokumentiem jābūt nolasāmiem un rediģējamiem ar MS Office 2007 vai jaunākas versijas

programmatūru.

Projekta dokumentu nodevumu iesniegšana jāveic, ievērojot šādus nosacījumus:

Projekta dokumenta nodevumi jāiesniedz izskatīšanai Pasūtītājam gan papīra formātā, gan

elektroniski, nosūtot dokumentu uz līgumā norādīto Pasūtītāja e-pasta adresi vai iesniedzot

elektroniskajā datu nesējā;

Pasūtītājs ir tiesīgs pārtraukt nodevuma izskatīšanu, ja nodevumā konstatētas neatbilstības

TS prasībām;

Pasūtītājs ir tiesīgs nepieņemt dokumenta nodevumu šādos gadījumos:

□ dokuments un tā saturs neatbilst TS prasībām;

134

□ dokuments un tā saturs neatbilst citām Pasūtītāja prasībām, kas dokumentētas

interviju vai sapulču laikā;

□ dokumentā gramatisko kļūdu skaits pārsniedz vidēji 1 (vienu) kļūdu 1 (vienu)

dokumenta (A4) lapu.

Iesniegto nodevumu nepieņemšanas gadījumā, Pasūtītājs komentārus nosūta uz e-pastu

Izpildītāja norādītajai pilnvarotajai personai;

Piegādātajiem dokumentiem jābūt latviešu valodā, ar sintaktiski un gramatiski pareizi lietotu

Pasūtītājam saprotamu un pieņemamu terminoloģiju. Gramatiskas kļūdas, ja to skaits nepārsniedz

vidēji 1 (vienu) kļūdu uz 1 (vienu) dokumenta (A4) lapu, nevar būt par iemeslu dokumenta

nepieņemšanai. Šādas kļūdas (arī dokumenta kļūdas, kuras tiek atklātas pēc dokumenta akceptēšanas)

Izstrādātājam ir jālabo garantijas ietvaros.

ORG-09 Atbilstība standartiem (obligāta)

Izpildītājam ir jāveic darbi un jāpiegādā nodevumi saskaņā ar šīs specifikācijas prasībām, iepirkuma

nosacījumiem, Latvijas Republikas normatīvo aktu un Eiropas Komisijas direktīvu prasībām, Latvijas

Republikas un starptautiskajiem programmatūras izstrādes standartiem.

Izpildītājam SISTĒMAS ieviešanas Projekta laikā jāizstrādā un jāiesniedz VID dokumentācija, kura ir

atbilstoša šādiem standartiem (skat. 33. tabulu):

33. tabula. Izmantojamie standarti

Nr.p.k. Nodevums Atbilstība Paskaidrojums

1. SISTĒMAS

arhitektūras

apraksts

ISO/IEC/IEEE

42010

SISTĒMAS programmatūras konceptuālā

arhitektūra ir augsta līmeņa dokuments, kas

specificē SISTĒMAS galvenās komponentes,

iekšējās un ārējās saskarnes, satur vadošu

informācijas SISTĒMAS projektēšanai un

pilnveidošanai, apraksta izmantojamās

tehnoloģijas, izstrādes rīkus un vidi.

2. Projekta

pārvaldības plāns

LVS 67:1996 Projekta pārvaldības plānā jānosaka projekta

tehniskās un pārvaldības funkcijas, pasākumi

un uzdevumi, kas nepieciešami, lai izpildītu

Līgumā noteiktās prasības.

135


Programmatūras

instalēšanas

instrukcija

IEEE/EIA J-STD016

(1.2.2.)

Aprakstā jāietver konkrētās produkta versijas

instalēšanas instrukcijas, nepieciešamā

apkārtne (environment), personāla

apmācīšana, kā arī jebkura cita informācija, kas

nepieciešama, lai programmatūru sagatavotu

darbināšanai.

3. SISTĒMAS

instalēšanas

plāns

IEEE/EIA J-STD-

016 (E.2.3.)

Instalēšanas plānā jāparedz aparatūras un

programmatūras sagatavošana, lietotāju

apmācīšana, kā arī visi citi pasākumi, kuri

nepieciešami, lai lietotāji varētu sākt darbināt

SISTĒMU.

4. Programmatūras

prasību

specifikācija

ISO/IEC 12207 un

SO/IEC/IEEE

15289:2015

Programmatūras prasību specifikācijā tiek

aprakstītas detalizētas prasības katram

SISTĒMAS programmatūras vienumam un tas ir

galvenais dokuments, atbilstībā pret kuru

turpmākā projekta izstrādes gaitā tiek veikta

SISTĒMAS testēšana un pieņemšana.

136


5. Programmatūras

projektējuma

apraksts

ISO/IEC 12207 un

ISO/IEC/IEEE

15289:2015

PPA jāietver gan SISTĒMAS programmatūras,

gan saskarņu, gan datu bāzu projektējuma

aprakstu. PPA pārbauda atbilstībā pret prasību

specifikāciju. PPA jāapraksta gan loģiskais, gan

fiziskais SISTĒMAS programmatūras

projektējums. Loģiskajā projektējumā ir jābūt

aprakstītiem visiem programmatūras

vienumiem, to nozīmei, funkcionalitātei un

savstarpējai mijiedarbībai. Fiziskajā

projektējumā detalizē, kā plānotā

programmatūras funkcionalitāte un citas

prasību specifikācijā ietvertās prasības tiks

realizētas. Saskarņu projektējuma aprakstā

jāapraksta sistēmu , apakšsistēmu, aparatūras,

programmatūras, lietotāja iedarbību un citu

SISTĒMAS komponentu savstarpējā sadarbība.

Datu bāzu projektējuma aprakstam jāsatur

informācija par datu bāzu struktūru, datu bāzes

elementu funkcionālo saturu, saistīto

programmatūru, informācija par prasībām, kas

noteiktas datu bāzei un tās elementiem, kā,

piemēram, drošība, integritāte u.c., kā arī

jebkura cita veida informācija, kas

nepieciešama datu pārbaudei, modificēšanai

u.tml.

6. Programmatūras

testēšanas plāns

ISO/IEC 12207 un

ISO/IEC/IEEE

15289:2015

Programmatūras testēšanas plānā jādod

Projekta laikā veicamo testēšanas pasākumu

plāns, kā arī jāapraksta šo pasākumu darbības

sfēra, izvēlētā pieeja, resursi u.c. Jāidentificē

testējamie vienumi, raksturiezīmes, kuras

jātestē, testēšanas uzdevumi, kas jāizpilda, un

risks, kurš ir saistīts ar plānu.

7. Testu

projektējuma

specifikācija

LVS 70:1996; IEEE

829

Testu projektējuma specifikācijā jāapraksta

programmatūras pazīmju vai to kombināciju

testēšanas pieejas detaļas un jāidentificē

atbilstošie testi un jāapraksta katrs testpiemērs.

137


8. SISTĒMAS

lietotāja

rokasgrāmata

ISO/IEC 12207 un

ISO/IEC/IEEE

15289:2015

Programmatūras lietotāja rokasgrāmatai ir

jānodrošina nepieciešamais informācijas

līmenis, kas nepieciešams SISTĒMAS

programmatūras lietotājiem, lai varētu

izmantot SISTĒMAS programmatūru.

Programmatūras lietotāja rokasgrāmatai ir

jābūt izstrādātai veidā, kas ir piemērots

izmantošanai gan drukātā, gan tiešsaistes

formā.

9. Programmatūras

administratora

rokasgrāmata

LVS 66:1996;

IEEE/EIA J-STD016

(J.2.4.)

Programmatūras administratora rokasgrāmatai

ir jāietver vismaz tādi aspekti kā

programmatūras instalācija, konfigurēšana,

lietotāju administrēšana, programmatūras

rezerves kopiju veikšana, atjaunošana,

nepārtrauktības nodrošināšana, regulārie

ikdienas uzdevumi (piemēram audita ierakstu

kontrole un arhivēšana), problēmu

identificēšana, programmatūras veiktspējas un

kapacitātes monitorēšana u.c. Piezīme:

papildus Izpildītāja izstrādātajai

programmatūras administratora rokasgrāmatai

ir jāpiegādā arī oriģinālās trešās puses

programmatūras dokumentācija, kas ir iekļauta

programmatūrā (kura tiek piegādāta SISTĒMAS

izveidošanas ietvaros).

10. SISTĒMAS

programmatūras

instalēšanas/

uzstādīšanas

instrukcija.

IEEE/EIA J-STD-

016 (1.2.2.)

Aprakstā jāietver konkrētās produkta versijas

instalēšanas instrukcijas, nepieciešamā

apkārtne (environment), personāla

apmācīšana, kā arī jebkura cita informācija, kas

nepieciešama, lai programmatūru sagatavotu

darbināšanai.

ORG-10 Akcepttestēšanas vide (obligāta)

Izpildītājam jāsagatavo instrukcija Pasūtītāja akcepttestēšanas vides izveidei Pasūtītāja īpašumā

esošajā infrastruktūrā, kas satur programmatūras instalācijas, konfigurācijas aprakstus, kā arī pilnu

informāciju par Pasūtītāja akcepttestēšanas videi nepieciešamo tehnisko infrastruktūru un

nepieciešamo standarta programmatūru. Izpildītājam bez papildus atlīdzības jānodrošina Pasūtītāja

konsultēšana par visiem nepieciešamajiem darbiem, kas saistīti ar Pasūtītāja akcepttesta vides

138

izveidošanas darbiem Pasūtītāja infrastruktūrā, kā arī jānodrošina bezmaksas konsultācijas

akcepttestu norises laikā.

ORG-11 SISTĒMAS programmatūras piegāde un uzstādīšana (obligāta)

Pēc programmatūras nodevuma saņemšanas Pasūtītājs veiks SISTĒMAS programmatūras uzstādīšanu

un konfigurēšanu Pasūtītāja akcepttesta vidē. Izpildītājam ir jānodrošina nepieciešamais Pasūtītāja

darbinieku atbalsts SISTĒMAS programmatūras uzstādīšanas un konfigurēšanas akcepttesta vidē laikā.

Pēc akcepttestēšanas pabeigšanas Pasūtītājs veiks SISTĒMAS programmatūras uzstādīšanu un

konfigurēšanu produkcijas vidē. Izpildītājam ir jāpiegādā pēdējās atkļūdotās programmatūras un

dokumentācijas versijas, kā arī jānodrošina nepieciešamais Pasūtītāja darbinieku atbalsts SISTĒMAS

uzstādīšanas un konfigurēšanas produkcijas vidē laikā. Testus veiks Pasūtītājs vai Pasūtītāja deleģēta

trešā puse. Programmatūras nodevumus Pasūtītājs akceptē, ja nodevuma akcepttestēšanas laikā

netiek konstatētas 1., 2. vai 3. klases problēmas (skat. 34. tabulu).

34. tabula. Problēmu klasifikācija

Klase Problēmas īss raksturojums Svarīgums

1. Nevar izpildīt SISTĒMAS un/ vai saistīto VID IS funkciju vai apdraud

SISTĒMAS un/ vai visu saistīto VID IS drošību, vai iesniegtā nodevuma

saturs neļauj sasniegt darba uzdevumā izvirzītos mērķus

Kritisks

2. Traucē izpildīt SISTĒMAS un/ vai saistīto VID IS funkciju, nav zināms cits

izpildes variants vai var apdraudēt SISTĒMAS un/ vai visu saistīto VID IS

drošību, vai iesniegtā nodevuma saturs neļauj sasniegt būtiskākos darba

uzdevumā izvirzītos mērķus

Kritisks

3. Traucē izpildīt SISTĒMAS un/ vai saistīto VID IS funkciju, ir zināms cits

izpildes variants, vai iesniegtā nodevuma saturs daļēji neļauj sasniegt

darba uzdevumā izvirzītos mērķus

Steidzams

4. Sagādā neērtības darbā, bet neiespaido SISTĒMAS un/ vai saistīto VID IS

funkciju, vai iesniegtā nodevuma saturs ļauj sasniegt darba uzdevumā

izvirzītos mērķus, bet nepieciešami precizējumi

Parasts

5. Jebkurš cits nodevuma defekts Parasts

Ja SISTĒMAS numuru atpazīšanas precizitāte ir zem 80%, tad tā uzskatāma ne zemāka par 2.klases

problēmu.

Ja SISTĒMAS numuru atpazīšanas precizitāte ir no 80% līdz 95% (neieskaitot), tad tā uzskatāma par

3.klases problēmu.

139

6.2 Prasības SISTĒMAS izstrādei

ORG-12 Izstrādes vides nodrošināšana (obligāta)

Izpildītājam ir jānodrošina sava vide (aparatūra, programmatūra, biroja telpas) līguma ietvaros

izpildāmo darbu un uzdevumu veikšanai. Izpildītājam izstrāde jāveic, izmantojot tikai licencētu

programmatūru. Pasūtītājs nenodrošina Izpildītāju ar licencēm.

Izpildītājs nedrīkst izmantot programmēšanas rīkus vai līdzekļus, kas prasītu papildu licenču iegādi

Pasūtītājam pēc programmatūras izvēršanas. Pretendentam TP ir jāapraksta, kā tiks nodrošināta

projekta projektēšanas un izstrādes vide, tajā skaitā projekta bibliotēka projekta dokumentācijas

uzglabāšanai, vide projekta nodevumu izstrādei, vide Izpildītāja testu veikšanai. TP jāapraksta, kādi

izstrādes rīki tiks izmantoti SISTĒMAS programmatūras izstrādes nodrošināšanā.

ORG-13 SISTĒMAS Izpildītāja testēšanas vide (obligāta)

Izpildītāja testēšanas vidi SISTĒMAS izstrādes un uzturēšanas gaitā ir jānodrošina Izpildītājam.

Izpildītāja testēšana videi ir jābūt ar atbilstošu konfigurāciju kā Pasūtītāja produkcijas videi. Testa vide

var būt var būt ar mazāku jaudu (mazāk vai vājākām iekārtām), taču tai ir jābūt ar tādu pašu arhitektūru

(var izmantot virtualizāciju) un topoloģiju kā produkcijas videi.

ORG-14 Nodevumu testēšana (obligāta)

Izpildītājam jānodrošina SISTĒMAS iekšējā testēšana Izpildītāja testa vidē atbilstoši kādai no zināmām

testēšanas metodoloģijām un testēšanas dokumentācijas sagatavošana. Pretendentam TP jāapraksta:

kāds būs testēšanas process;

kādi būs testēšanas veidi (manuālā, automātiskā);

kādi testēšanas rīki tiks izmantoti, lai veiktu nodevumu kvalitatīvu testēšanu;

kādā formātā tiks piegādāti testēšanas scenāriji un dokumentācija;

kā tiks saskaņoti un iesniegti testpiemēri;

kad, kādā formātā un ar kādu saturu tiks iesniegti testu žurnāli;

kā Izpildītājs nodrošinās testa datu (t.sk. dažāda veidu/tipu TL) pieejamību testa vidē.

ORG-15 SISTĒMAS Izpildītāja nodevumu testi (obligāta)

Lai nodrošinātu nodevuma atbilstību visām nodevumam un tā sastāvdaļām noteiktajām prasībām,

Izpildītājam ir jānodrošina nodevumu iekšējā testēšana atbilstoši kādai no zināmām testēšanas

metodoloģijām un testēšanas dokumentācijas sagatavošana. Izpildītājam jānodrošina vismaz

nodevumu:

140

a) funkcionalitātes testēšana;

b) integritātes testēšana;

c) drošības testēšana;

d) veiktspējas, ātrdarbības un slodzes testēšana.

Testēšanu veic Izpildītājs ar saviem resursiem, neiesaistot Pasūtītāju, pirms nodevuma iesniegšanas,

lai pārliecinātos, ka nodevums ir gatavs akcepttestēšanai. Programmatūras nodevumi ir jāiesniedz

kopā ar Izpildītāja veiktās testēšanas dokumentāciju (tajā skaitā testēšanas plāns, testpiemēru

specifikācija, testēšanas kopsavilkuma pārskats un testu protokoli).

Veicot SISTĒMAS programmatūras nodevumu piegādi, jānodrošina visu iepriekš piegādātu SISTĒMAS

daļu testēšana, ieskaitot to SISTĒMAS daļu atkārtoto testēšanu, kas netika modificētas, ar mērķi

pārliecināties, ka veiktās modifikācijas nav negatīvi ietekmējušas līdz šim izstrādātās SISTĒMAS daļas.

Jauni programmatūras nodevumi nedrīkst pasliktināt esošo SISTĒMAS funkcionalitāti.

6.3 Prasības garantijai un uzturēšanai

ORG-17 Garantijas periods (obligāta)

SISTĒMAS garantijas periods ir 5 (pieci) gadi saskaņā ar līgumprojekta noteikumiem. Specifikācijā

norādītajām atsevišķajām iekārtām ir jānodrošina arī 5 (piecu) gadu iekārtu ražotāja garantija.

ORG-18 Reakcijas laiki no problēmas pieteikšanas brīža (obligāta)

Izpildītājam jānodrošina šādi reakcijas laiki no problēmas pieteikšanas brīža ISIPS:

kritiskos gadījumos, kad atklātā problēma neļauj vai traucē izpildīt būtisku SISTĒMAS funkciju

un nav zināms cits tās izpildes variants, vai kad atklātā problēma apdraud SISTĒMAS drošību

- ne lielāks par 4 (četrām) VID darba stundām. Ja kritiska problēma tiek pieteikta ārpus VID

darba laika (no pirmdienas līdz ceturtdienai no plkst.8.15 līdz plkst.17.00, piektdienās no

plkst.8.15 līdz plkst.15.45), tad reakcijas laikā tiek skaitīts tikai VID darba laiks;

steidzamos gadījumos, kad atklātā problēma traucē izpildīt būtisku SISTĒMAS funkciju, bet ir

zināms cits tās izpildes variants, vai pastāv risks, ka atklātā problēma apdraud SISTĒMAS

drošību - ne lielāks par 8 (astoņām) VID darba stundām. Ja steidzama problēma tiek pieteikta

ārpus VID darba laika (no pirmdienas līdz ceturtdienai no plkst.8.15 līdz plkst.17.00,

piektdienās no plkst.8.15 līdz plkst.15.45), tad reakcijas laikā tiek skaitīts tikai VID darba laiks;

parastos gadījumos - ne lielāks par 24 (divdesmit četrām) VID darba stundām. Ja problēma

tiek pieteikta ārpus VID darba laika (no pirmdienas līdz ceturtdienai no plkst.8.15 līdz

plkst.17.00, piektdienās no plkst.8.15 līdz plkst.15.45), tad reakcijas laikā tiek skaitīts tikai VID

darba laiks).

Problēmas svarīgumu sākotnēji nosaka Pasūtītājs.

141

Reakcijas laikā Izpildītājam jānodrošina pieteikumu izpēte, klasifikācija un atbildes sniegšana –

reakcijas laiki (stundās), par pieteikumā norādītās problēmas cēloni un novēršanas laiku vai izmaiņu

pieprasījuma realizēšanai prognozējamo darbietilpību un realizēšanai nepieciešamo laiku no

pieteikuma nosūtīšanas brīža.

ORG-19 Problēmu novēršanas laiki no problēmas pieteikšanas brīža (obligāta)

Izpildītājam jānodrošina šādi problēmu novēršanas laiki no problēmas pieteikšanas brīža ISIPS:

kritiskos gadījumos, kad atklātā problēma neļauj vai traucē izpildīt būtisku SISTĒMAS funkciju,

vai kad atklātā problēma apdraud SISTĒMAS drošību, problēmas tiek novērstas ne vēlāk kā

24 (divdesmit četru) VID darba stundu laikā, vai tiek realizēts cits VID pieņemams risinājums.

Ja kritiska problēma tiek pieteikta ārpus VID darba laika (no pirmdienas līdz ceturtdienai no

plkst.8.15 līdz plkst.17.00, piektdienās no plkst.8.15 līdz plkst.15.45), tad problēmas

novēršanas laikā tiek skaitīts tikai VID darba laiks;

steidzamos gadījumos, kad atklātā problēma traucē izpildīt būtisku SISTĒMAS funkciju, bet ir

zināms cits tās izpildes variants, vai pastāv risks, ka atklātā problēma apdraud SISTĒMAS

drošību, problēmas tiek novērstas ne vēlāk kā 5 (piecu) VID darba dienu laikā, vai tiek realizēts

cits VID pieņemams risinājums;

parastos gadījumos – ne vēlāk kā 40 (četrdesmit) kalendāro dienu laikā vai plānojamo termiņu

ierosina pretendents un apstiprina SISTĒMAS Izmaiņu vadības padomē.

Pieteiktās problēmas statusa izmaiņas un risināšanas gaita Pasūtītājam būs redzama ISIPS.

ORG-20 Palīdzības un konsultāciju pieejamība garantijas pakalpojuma nodrošināšanas laikā (obligāta)

Izpildītājam garantijas ietvaros bez papildus maksas latviešu valodā pēc Pasūtītāja pieprasījuma

jānodrošina palīdzība un konsultācijas SISTĒMAS izmantošanā VID darba dienās no pirmdienas līdz

ceturtdienai no plkst. 8:15 līdz plkst.17:00, piektdien no plkst.8:15 līdz plkst.15:45. Garantijas ietvaros

tehniskais atbalsts, palīdzība un konsultācijas sniedzamas, izmantojot sekojošus komunikācijas

kanālus – telefoniski, pa e-pastu un klātienē. Izpildītājam ir jānodrošina visi norādītie komunikācijas

kanāli, tomēr Izpildītājs, vienojoties ar Pasūtītāju, var noteikt primāri izmantojamo komunikācijas

kanālu.

ORG-21 SISTĒMAS uzturēšanas darbi (obligāta)

Izpildītājam vismaz 1 (vienu) reizi 3 (trijos) mēnešos jānodrošina tehniskās apkopes, lai SISTĒMAS

darbība būtu korekta. Ja ārēju apstākļu dēļ (piemēram, intensīvs sniegs, apledojums utt.) ir

nepieciešams veikt iekārtu apkopi, lai nodrošinātu to normālu darbspēju, tas ir jāparedz apkopes

darbu plānā. Apkopju laikā veikto pārbaužu, testēšanas un bojājumu novēršanas rezultātus (ar VID

142

saskaņota darbu veikšanas akta formātā) iesniedz Pasūtītāja pilnvarotajai personai pēc tehniskās

apkopes veikšanas kopā ar rēķinu.

SISTĒMAS bojājumu, problēmu gadījumos Izpildītājam jāsniedz detalizētās rekomendācijas bojājumu

novēršanai.

Akta formai jāsatur vismaz šāda informācija:

Apkopju veicēji;

Apkopju datums;

Veicamie apkopes darbi:

□ video kameru pārbaude/tīrīšana (kondensāts, mitrums korpusa iekšpusē, mehāniskie

bojājumi, mehāniskā stabilitāte utt.);

□ apgaismes iekārtu pārbaude/ tīrīšana;

□ lokālo iekārtu skapju pārbaude (kondensāts, mitrums, kukaiņi tās iekšpusē,

mikrovides parametru kontrole iepriekšējā perioda laikā utt.);

□ video kabeļu un savienojumu pārbaude;

□ video attēlu kvalitātes pārbaude;

□ UPS iekārtas pārbaude (iekārtas bateriju kapacitātes izmaiņu novērtēšana);

□ optisko konvertoru darbības pārbaude;

□ zibens aizsardzības un pārsprieguma aizsardzības sistēmas pārbaude (kontaktu

pārbaude, periodiska zemējuma pretestības pārbaude);

□ nepieciešamie darbi infrastruktūras, datortehnikas un SISTĒMAS iekārtu pārbaudei;

□ infrastruktūras, datortehnikas un SISTĒMAS iekārtu periodiskās servisa operācijas

SISTĒMAS nepārtrauktās darbības pārbaudei un nodrošināšanai.

Norādītas katrā uzdevumā veiktās aktivitātes, konstatētie bojājumi, izmantotie materiāli.

Norādītas katra uzdevuma nākamās aktivitātes (t.sk. aktivitāšu laiks).

ORG-22 Prasības infrastruktūras uzturēšanai (obligāta)

Tehniskās infrastruktūras uzturēšanas prasības ietver (minimālais apjoms):

video kameru pārbaude – vai tā objektīvs vai kameras priekšējais stikls nav nosmērējies, vai

nav bojātas, nav putekļi un mitrums iekšpusē, termostati un sildītājs strādā, kameru

stiprinājums ir drošs, vai uzstādītais iekārtas darbības virziens nav mainījies;

numura piegaismošanas elementu virsmas tīrības pārbaude – vai tā nav nosmērējusies, vai

apsalusi;

lokālo iekārtu skapju pārbaude – vai pa kabeļu ievadiem skapī nav iekļuvuši svešķermeņi,

iekšpusē nav sakrājušies putekļi un mitrums (kondensāta veidošanās rezultātā vai iekļūstot

lietus ūdenim). Jāpārbauda, vai ierīkotie gaisa pievades un izvadīšanas kanāli nav aizsērējuši.

Jāveic temperatūras mērījumi, lai pārliecinātos par temperatūras skapju iekšpusē atbilstu

darba robežām, ko nosaka tajā ievietoto iekārtu ražotāju, piem., ass svaru kontrollera,

noteiktie ierobežojumi.

143

video kabeļu un savienojumu pārbaude (ja ir saņemtas sūdzības par datu apmaiņas kvalitātes

pasliktināšanos – arī veicot kabeļu parametru fizisko mērīšanu ar testēšanas ierīcēm);

video attēlu pārbaude, izmantojot testa monitoru, nepieciešamības gadījumā - pielāgojumu

nodrošināšana;

UPS iekārtas akumulatoru uzlādes līmeņa un kapacitātes pietiekamības pārbaude;

pārbaude, vai nostrādā detektori, automašīnai izbraucot SISTĒMAS darbības zonai;

optisko konvertoru darbības testēšana;

zibens aizsardzības un pārsprieguma aizsardzības sistēmas pārbaude (t.sk. zemējuma kontūru

pretestības mērījumu veikšana vismaz vienu reizi divos gados);

infrastruktūras, datortehnikas un SISTĒMAS iekārtu periodiskās servisa operācijas SISTĒMAS

nepārtrauktās darbības pārbaudei un nodrošināšanai.

ORG-23 Prasības programmatūras uzturēšanai (obligāta)

Programmatūras uzturēšanas prasības ietver (minimālais apjoms):

a) programmatūras darbības pārbaude un nepieciešamo konfigurāciju vai, piemēram,

jaunāko drošības atjaunojumu uzstādīšanas instrukciju iesniegšana Pasūtītājam SISTĒMAS

darbības uzlabošanai;

b) programmatūras darbības problēmu izpēte un novēršana;

c) programmatūras kļūdu labošana;

d) programmatūras pilnveidojumu un izmaiņu pieprasījumu realizēšana;

e) licenču uzturēšana, t.sk., licenču uzturēšana standartprogrammatūrai,

standartprogrammatūras kļūdu novēršana esošajās versijās un jaunu piegāde, ja tādas ir

paredzētas, trešo pušu produkcijas licenču uzturēšana (piemēram, datubāzu vadības sistēmas

u.c.). Finanšu piedāvājumā licenču uzturēšanas maksa jāparedz katram gadam atsevišķi.

Pasūtītājs var Izpildītājam pieprasīt iesniegt trešās puses apliecinājumu, ka uzturēšana ir

iegādāta tieši Pasūtītāja vajadzībām.

f) konsultatīvs atbalsts (a, b, c, e, f punktos bez maksas).

SISTĒMAS uzturēšanas pakalpojuma ietvaros, gadījumos, kad tiek izdoti SISTĒMAS darbības

nodrošināšanā izmantotās programmatūras (trešās puses programmatūras, tajā skaitā

operētājsistēmu programmatūras) jauninājumi vai kritiskie ielāpi, Izpildītājs bez papildus samaksas:

iesniedz Pasūtītājam atzinumu par jauninājuma vai kritiskā ielāpa ietekmi uz SISTĒMAS un/

vai saistīto VID IS darbību 24 (divdesmit četru) VID darba stundu laikā no Pasūtītāja

pieprasījuma saņemšanas brīža. Ja programmatūras jauninājums ir kritisks SISTĒMAS un/ vai

saistīto VID IS drošībai, Izpildītājam jāiesniedz atzinums īsākā laikā, abpusēji vienojoties ar

Pasūtītāju;

gadījumos, kad, lai nodrošinātu programmatūras jaunās versijas vai labojumu uzstādīšanu

Pasūtītāja akcepttesta/ produkcijas vidē, nepieciešamas izmaiņas SISTĒMAS programmatūrā,

iesniedz Pasūtītājam izvērtējumu par šādu izmaiņu darbietilpību.

144

ORG-24 Ārpusgarantijas darbi

SISTĒMAS iekārtu bojājumu, trūkumu un darbības traucējumu novēršanas darbi, kas radušies lietojot

SISTĒMAS iekārtas neatbilstoši rokasgrāmatās norādītajām lietošanas instrukcijām, kā arī bojājumu,

trūkumu un darbības traucējumu novēršana, kas radušies trešo personu rīcības rezultātā, (turpmāk –

Ārpusgarantijas remontdarbi) veicami saskaņā ar šādiem nosacījumiem:

Ārpusgarantijas remontdarbi veicami saskaņā ar Izpildītāja un VID pilnvarotās personas

iepriekš saskaņotu tāmi.

Izpildītājam 2 (divu) darba dienu laikā no pieteikuma par Ārpusgarantijas remontdarbu

nepieciešamību nosūtīšanas dienas jāveic bojāto SISTĒMAS iekārtu diagnostika un jāiesniedz

Pasūtītājam Ārpusgarantijas remontdarbu tāmi, kurā tiek norādītas remontdarbu izmaksas un

remontdarbiem nepieciešamais laiks.

Ārpusgarantijas remontdarbi veicami tikai pēc tāmes saskaņošanas un tie jānodrošina tāmē

norādītajā termiņā.

Dīkstāve, kas radusies Ārpusgarantijas remontdarbu veikšanas nepieciešamības dēļ, netiek

iekļauta atļautajā dīkstāves laikā.

Ja Ārpusgarantijas remontdarbi netiek izpildīti tāmē norādītajā termiņā, tad nokavētais laiks

tiek atskaitīts no pieļaujamā dīkstāves laika (gadījumā, ja dīkstāve ir iestājusies).

Pēc katru Ārpusgarantijas remontdarbu veikšanas jāiesniedz parakstīšanai Pasūtītāja

atbildīgajai personai remontdarbu nodošanas-pieņemšanas akts, kurā noteikti jābūt

norādītam problēmu Ārpusgarantijas remontdarbu tāmes saskaņošanas datumam, tāmē

norādītajam remontdarbu izpildes laikam un faktiskajam remontdarbu pabeigšanas laikam.

Ārpusgarantijas remontu darbu izmaksu aprēķināšanai piemēro Finanšu piedāvājuma

noteikto Ārpusgarantijas remontdarbu veikšanas stundas cenas likmi. Ārpusgarantijas darbos

izmantojamo rezerves daļu cenām jāatbilst attiecīgās rezerves daļas cenai būvniecības un/vai

uzstādīšanas laikā, bet, ja konkrēta cena būvniecības un/vai uzstādīšanas laikā nav norādīta,

tad šo rezerves daļu cena tiek saskaņota remontdarbu tāmē.

Garantija Ārpusgarantijas remontdarbiem un to ietvaros nomainītajām rezerves daļām:

□ Veiktajiem Ārpusgarantijas remontdarbiem jānodrošina ne mazāk kā 1 (viena) gada

garantija.

□ Nomainītajām rezerves daļām jānodrošina ražotāja noteiktā garantija.

ORG-25 Samaksa par uzturēšanas darbiem

Veicot SISTĒMAS uzturēšanas darbu pieņemšanu, Pasūtītājs veic SISTĒMAS atpazīšanas precizitātes

pārbaudi atbilstoši prasībā NEF-07 noteiktajam.

Ja tiek konstatēts, ka precizitāte ir neatbilstoša prasībās noteiktajam, Izpildītājam tiek pieteikts

atbilstošs problēmas pieteikums. Izpildītāja pienākums ir novērst pieteikto problēmu, iekļaujoties

pielīgtajos problēmas novēršanas termiņos. Ja problēmas novēršana neiekļaujas pielīgtajos

problēmas novēršanas termiņos, tad uzskatāms, ka Izpildītājs nenodrošina prasībām atbilstošu

SISTĒMAS uzturēšanas pakalpojumu un Pasūtītājs piemēro papildus līgumsodu – uzturēšanas

145

samaksas samazinājumu, rēķinot katra MKP/ RŠV katrai TL plūsmas joslai, kas aprīkota ar SISTĒMAS

elementiem, atsevišķi:

Ja SISTĒMAS atpazīšanas precizitāte mēnesī bijusi zem 80%, tad uzturēšanas samaksas

samazinājums par atbilstošo mēnesi ir 100%.

Ja SISTĒMAS atpazīšanas precizitāte mēnesī bijusi no 80% līdz 90% (neieskaitot), tad

uzturēšanas samaksas samazinājums par atbilstošo mēnesi ir 50%.

Ja SISTĒMAS atpazīšanas precizitāte mēnesī bijusi no 90% līdz 95% (neieskaitot), tad

uzturēšanas samaksas samazinājums par atbilstošo mēnesi ir 25%.

6.4 Prasības pārvaldības metodēm

Izpildītājam jānodrošina SISTĒMAS izstrādes un uzturēšanas kvalitāte un pārvaldība Izpildītāja pusē

atbilstoši šādām prasībām:

ORG-26 Plānu pārvaldība (obligāta)

Pēc Pasūtītāja pilnvaroto personu pieprasījuma Izpildītājam 10 (desmit) darba dienu laikā jāiesniedz

SISTĒMAS izstrādei un uzturēšanai nepieciešamie plāni (laika, izmaksu, izstrādes utt.). Izpildītājam

jāpiedalās nodevumu un versiju plānošanā, sagatavojot un, pēc VID pieprasījuma, nosūtot versiju

plānus.

ORG-27 Konfigurācijas un versiju pārvaldība (obligāta)

Izpildītājam jānodrošina dažādu versiju programmatūras vienumu konfigurāciju pārvaldība

(konfigurāciju informācijas uzkrāšana, savietojamība, atjaunošana utt.). Sistēmas izstrādes gaitā visām

konfigurācijas vienībām (Pretendentam jādefinē, kuri objekti tiks pakļauti konfigurācijas pārvaldībai)

un to versijām ir jābūt identificētām, visām izmaiņām trasējamām un sasaistāmām ar konkrētiem

darba uzdevumiem un atbildīgajiem. Visā projekta norises laikā bez aktuālo darba versiju uzturēšanas

vienmēr jāsaglabā arī visas Pasūtītājam iesniegto nodevumu versijas (tas attiecas kā uz

programmatūru, tā arī dokumentāliem nodevumiem), tām jābūt piegādātām atsevišķi, pievienojot

izmaiņu vēsturi. Izpildītājam Projekta pārvaldības plānā jāapraksta piedāvātā pieeja Projekta

konfigurācijas vadības nodrošināšanai. Izpildītājam jāizmanto Pasūtītāja norādītā nodevumu un citu

konfigurācijas vienumu identifikācijas shēma.

ORG-28 Izmaiņu pārvaldība (obligāta)

Izpildītājam jānodrošina izmaiņu pieprasījumu pārvaldība. Visām izmaiņām SISTĒMĀ ir jābūt

dokumentētām, katrā nodevumā iekļaujot aprakstu, kas identificē jaunizveidoto funkcionalitāti,

realizētās izmaiņas un novērstās kļūdas. Veicot izmaiņas SISTĒMĀ, Izpildītājam jāidentificē ietekme uz

146

citām saistītajām informācijas sistēmām un jāinformē Pasūtītājs, kā arī jānodrošina datu integritāte un

datu apmaiņas procesu savietojamība.

ORG-29 Izmaiņu pieprasījumi (obligāta)

Saņemot SISTĒMAS izmaiņu pieprasījumu, pirms tā realizācijas uzsākšanas, Izpildītājs ar Pasūtītāju

saskaņo SISTĒMAS nepieciešamo izmaiņu vai papildināšanas pieprasījuma precīzas realizācijas

izmaksas, sagaidāmo rezultātu, izpildes termiņus, pieņemšanas – nodošanas kārtību un citus

nepieciešamos nosacījumus.

ORG-30 Problēmu ziņojumu pārvaldība (obligāta)

Izpildītājam jānodrošina pilna problēmas (gan infrastruktūras, gan programmatūras) dzīves cikla

pārvaldība, sākot ar problēmas atklāšanu, reģistrēšanu, novēršanu, testēšanu un beidzot ar labojumu

ieviešanu produkcijas vidē. Visi problēmu ziņojumi un izmaiņu pieprasījumi Līguma darbības laikā tiks

pieteikti, izmantojot VID Informācijas sistēmu izmaiņu pārvaldības sistēmu (ISIPS), saskaņā ar līguma

projektā 0.1.0.pielikumā aprakstīto kārtību. Līguma izpildes laikā tiesības noteikt pieteikuma prioritāti

(kritiska, steidzama vai parasta) ir attiecīgajām Pasūtītāja pilnvarotajām personām.

ORG-31 Risku pārvaldība (obligāta)

Izpildītājam visā Projekta laikā ir jāveic Projekta risku identificēšana, analīze, novērtēšana, uzraudzība

un kontrole, risku mazināšanas un/vai novēršanas darbu plānošana un īstenošana.

Pretendentam Tehniskajā piedāvājumā ir jāapraksta Projekta sākotnējo risku novērtējums, kā arī

pieņēmumi, atkarības un ārējās ietekmes, kas tika ņemtas vērā, sagatavojot Tehnisko piedāvājumu.

ORG-32 Kvalitātes pārvaldības process (obligāta)

Dokumentācijas izstrāde jānodrošina atbilstoši standartiem. Darbu izpildes rezultātā izveidotā

(modificētā) SISTĒMAS dokumentācija ir jāpiegādā, integrējot to attiecīgā dokumenta veida

pēdējā (aktuālajā) versijā, saglabājot izmaiņu trasējamību, tādejādi novēršot dokumentācijas

sadrumstalošanos.

SISTĒMAS izstrādes, uzturēšanas un garantijas laikā ir jāuztur projekta bibliotēka, kurā

jāizvieto SISTĒMAS darba dokumenti – prasību specifikācijas, projektējuma apraksti,

testēšanas dokumentācija u.c.

Izpildītājam jāņem vērā, ka Projekta izpildes laikā VID ir tiesīgs prasīt Izpildītājam jebkādu

informāciju saistībā ar SISTĒMAS izstrādes un uzturēšanas kvalitātes nodrošināšanu, bez

papildus maksas.

147

6.5 Citas organizatoriskās prasības

ORG-33 Projekta komunikācija (obligāta)

Izpildītājam komunikācija ar Pasūtītāju jānodrošina latviešu valodā. Ja tiks piesaistīti speciālisti, kuri

nepārvalda latviešu valodu, Izpildītājam šo speciālistu saziņā ar Pasūtītāju jānodrošina tulkošana bez

papildu maksas.

ORG-34 Darbietilpības novērtēšana (obligāta)

Pretendentam detalizēti jāapraksta sākotnējās darbietilpības novērtēšanas (aprēķināšanas) metodes

un risinājums speciālistu veikto darbu apjoma (patērētā laika) uzskaitei, kuru Pretendents apņemas

izmantot līguma izpildes laikā. Pretendentam jāizmanto vismaz viena formālā metode, balstoties uz

COCOMO (Constructive Cost Model) un vismaz viena neformālā metode.

ORG-35 Prasības administratoru un lietotāju apmācībai (obligāta)

SISTĒMAS ieviešanas ietvaros ir jāveic:

vismaz 6 (sešu) SISTĒMAS administratoru apmācības. Apmācībās jāietver gan teorētiskās, gan

praktiskās nodarbības, nodrošinot zināšanu apguvi par SISTĒMAS funkcionalitāti, SISTĒMAS

administrēšanu un uzturēšanu (t.sk. nepieciešamo rezerves kopiju veidošanu un SISTĒMAS

darbības atjaunošanu), lietotāju administrēšanu, SISTĒMAS konfigurēšanu. Paredzamais

apmācību ilgums 6 (sešas) stundas;

vismaz 20 (divdesmit) SISTĒMAS lietotāju apmācības. Apmācībās jāietver gan teorētiskās, gan

praktiskās nodarbības, nodrošinot zināšanu apguvi par SISTĒMAS funkcionalitāti (tādā līmenī,

lai apmācītais varētu apmācīt citus SISTĒMAS lietotājus). Paredzamais apmācību ilgums 6

(sešas) stundas;

mācību plānu un mācību (izdales) materiālu sagatavošana:

□ mācību plāni - apmācību plānā ir jāapraksta mācību mērķis, saturs, laika grafiks,

jānosaka prasības apmācāmo grupai. Apmācībām ir jāietver teorētiskā daļa, kā arī

praktiskā. Pirms apmācību veikšanas ir jābūt izstrādātai pietiekoši stabilai SISTĒMAS

versijai, lai nodrošinātu apmācību praktisko daļu, kā arī jābūt pabeigtai attiecīgajai

dokumentācijai;

□ mācību (izdales) materiāli - Pretendentam ir jāizstrādā vai jāpapildina, jāsaskaņo ar

VID un jāpiegādā mācību materiāli - MS PowerPoint, MS Word vai cita formāta

dokumentācija atbilstoši Piedāvājumam. Mācību materiāliem ir jātiek iesniegtiem

pārskatīšanai un akceptēšanai no VID puses vismaz 10 (desmit) darba dienas pirms

mācību norises. Mācību materiāliem jābūt tādiem, lai tos varētu izmantot tālākai

lietotāju apmācībai.

Pretendentam ir jāizstrādā un kopā ar TP jāiesniedz Pasūtītājam mācību plāna saturs, kas apraksta, kā

prasība tiks izpildīta.

148

ORG-36 Projekta pārvaldības plāns (obligāta)

Izpildītājam 3 (trīs) kalendāro nedēļu laikā pēc līguma abpusējas parakstīšanas dienas ir jāizstrādā un

jāiesniedz Pasūtītājam izskatīšanai un saskaņošanai projekta pārvaldības plāns. Projekta pārvaldības

plānā jānosaka tehniskās un pārvaldošās projekta funkcijas, aktivitātes un uzdevumi, kas nepieciešami

Pasūtītāja TS noteikto projekta prasību apmierināšanai. Projekta pārvaldības plānā jāapraksta (bet

neaprobežojoties) projekta pārvaldības aktivitātes un uzdevumi, to norises kārtība, atbildīgie, risku

pārvaldības pasākumi, projekta kvalitātes nodrošināšanas pasākumi.

ORG-37 Darbu plāns (obligāta)

Izpildītājam ir jāizstrādā un kopā ar TP jāiesniedz Pasūtītājam SISTĒMAS piegādes un ieviešanas darbu

plāns, kurā jāapraksta projekta ietvaros izpildāmie darbi un uzdevumi, to izpildes laika plāns (izpildei

nepieciešamais laiks, kalendārais plāns), iesaistīto darbinieku darbietilpība (slodze).

Plānotie projekta realizācijas etapi:

- objekta Būvprojekta izstrāde un saskaņošana – līdz 4 mēnešiem (jāparedz arī Būvprojekta

pārbaudes posms, ko realizē Pasūtītājs);

- kopējā projekta realizācijas termiņš - līdz 12 mēnešiem no līguma parakstīšanas dienas.

ORG-38 Integrācija ar ISIPS (obligāta)

Izpildītājām jānodrošina savas pieteikumu pārvaldības sistēmas (IPPV) integrācija ar VID informācijas

sistēmu izmaiņu pārvaldības sistēmu (ISIPS), kurā Pasūtītājs reģistrēs problēmu un izmaiņu

pieprasījuma pieteikumus Izpildītājam.

149

7 PIELIKUMS NR.1 – VENTSPILS OSTAS MKP SISTĒMAS

ELEMENTU PLĀNOTĀ IZVIETOJUMA VIETA

Pielikumā norādīta informācija par plānotajām SISTĒMAS elementu izvietošanas un serveru telpas

atrašanās vietas.

Adrese: Ventspils, Plosta iela 7 (Vieta Nr.3 un Nr.4)

Adrese: Ventspils, Plosta iela 20/14 – vieta Nr.1 un Nr.2 (Sarkanmuižas dambis 25A- serveru telpa)

150

8 PIELIKUMS NR.2 - LIEPĀJAS OSTAS MKP SISTĒMAS


Pielikumā norādīta informācija par plānotajām SISTĒMAS elementu izvietošanas un serveru telpas

atrašanās vietas.

Adrese: Liepāja, Brīvostas iela. Serveru telpas atrašanās vieta – O. Kalpaka iela 111

151

9 PIELIKUMS NR.3 – MEIKŠĀNU RŠV SISTĒMAS


Pielikumā norādīta informācija par plānotajām SISTĒMAS elementu izvietošanas un komunikāciju

telpas atrašanās vietas.

Adrese: Meikšānu RŠV, Zilupes novads, Pasienes pagasts.

Komunikāciju telpas atrašanās vieta ēkā (telpa Nr.005)

152

10 PIELIKUMS NR.4 – KAPLAVAS RŠV SISTĒMAS ELEMENTU

PLĀNOTĀ IZVIETOJUMA VIETA



Adrese: Kaplavas RŠV, Krāslavas novads, Kaplavas pagasts.

Komunikāciju telpas atrašanās vieta ēkā (telpa Nr.11)

153

11 PIELIKUMS NR.5 – PEDEDZES RŠV SISTĒMAS ELEMENTU

PLĀNOTĀ IZVIETOJUMA VIETA



Adrese: Pededzes RŠV, Alūksnes novads, Pededzes pagasts.

Komunikāciju telpas atrašanās vieta ēkā ir norādīta attēlā.

transportlĪdzekĻu un konteineru · 2.1.1 bp_1 procesu grupa “muitas noteikumu (es robežas) ......

Documents