Grįžti į sąrašą

Elektroninės krovinių vežimo informacijos apsikeitimo aplinkos kompetentingos institucijos prieigos taško programinės įrangos sukūrimo paslaugų pirkimas

Išanalizuota

Akcinė bendrovė Klaipėdos valstybinio jūrų uosto direkcija (PV)

Atviras konkursasCPV: 72212517 - IT programinės įrangos kūrimo paslaugos
ID: 73246412026-04-09 16:14
Atidaryti CVP IS

Aprašymas

Šis pirkimas skirtas sukurti elektroninės krovinių vežimo informacijos apsikeitimo aplinkos kompetentingos institucijos prieigos taško (AAP) programinę įrangą su integruota naudotojo programa (UAP) Klaipėdos valstybinio jūrų uosto direkcijai. Projektas taip pat apima visapusiškos techninės testavimo aplinkos, įskaitant eFTI vartus ir eFTI platformą, sukūrimą. Sistema leis kompetentingai institucijai efektyviai kontroliuoti pavojingų krovinių duomenis.

Kvalifikaciniai reikalavimai

  • 1Tiekėjo patirtis – per pastaruosius 3 metus (skaičiuoti iki pasiūlymo pateikimo termino pabaigos) arba per laiką nuo tiekėjo įregistravimo dienos (jei tiekėjas vykdė veiklą mažiau nei 3 metus) yra savo jėgomis tinkamai suteikęs taikomosios programinės įrangos sukūrimo paslaugas, kurios vertė ne mažesnė kaip 150 000,00 Eur be PVM.
  • 2Tiekėjas turi užtikrinti, kad paslaugoms vykdyti turės patyrusį bent vieną projekto vadovą, kuris turi: ne trumpesnę kaip 12 mėnesių darbo patirtį vadovaujant informacinių sistemų kūrimo ir/arba vystymo projektuose (skaičiuojant bendrą darbo patirtį nurodytoje srityje, vienu metu vykdomų projektų trukmės nesumuojamos).
  • 3Tiekėjas turi užtikrinti, kad paslaugoms vykdyti turės kvalifikuotą bent vieną ekspertą-analitiką, kuris turi: kvalifikaciją patvirtinantį sertifikatą OMG-Certified arba UML Professional Fundamental arba IBM Certified Solution Designer (vUML2) arba lygiavertį.
  • 4Tiekėjas turi užtikrinti, kad paslaugoms vykdyti turės patyrusį IT architektą, kuris turi: ne mažiau kaip 12 mėnesių darbo patirtį projektuojant ir diegiant paskirstytas IT sistemas, įskaitant paslaugomis pagrįstą architektūrą (SOA), API pagrindu veikiančias integracijas ir pranešimais pagrįstą komunikaciją.
  • 5Tiekėjas turi užtikrinti, kad paslaugoms vykdyti turės pavojingų krovinių ekspertą, turintį specializuotų žinių apie pavojingų krovinių reglamentus (ADR arba RID arba IMDG arba lygiaverčio).
  • 6Paslaugų tiekėjas ar jį kontroliuojantis asmuo negali būti registruoti (jeigu gamintojas ar jį kontroliuojantis asmuo yra fizinis asmuo – nuolat gyvenantis ar turintis pilietybę) Viešųjų pirkimų įstatymo 92 straipsnio 14 dalyje numatytame sąraše nurodytose valstybėse ar teritorijose.
  • 7Sukurta programinė įranga negali būti palaikoma iš LR viešųjų pirkimų įstatymo 92 straipsnio 14 dalyje numatytame sąraše nurodytų valstybių ar teritorijų.

Techniniai reikalavimai

Darbo apimtis

  • 1Institucijų prieigos taško kūrimas.
  • 2Techninių komponentų, skirtų visapusiškam eFTI ekosistemos bandymui (eFTI vartai, eFTI platforma, sistemų integracija), teikimas.
  • 3eDelivery konfigūravimas, kad būtų galima prisijungti prie eFTI4EU bandymo aplinkos.
  • 4Išsamus bandomasis projektas, demonstruojantis institucijų prieigos taško naudojimo atvejus.
  • 5Testavimas pagal eFTI4EU testavimo planą.
  • 6Ataskaita apie: techninius rezultatus pagal eFTI4EU testavimo planą; komponentų veikimą; sistemos naudojimą pavojingų krovinių duomenims kontroliuoti.

Kitos sąlygos

  • 1Prekei taikomas LR aplinkos ministro 2011 m. birželio 28 d. įsakymu Nr. D1-508 4.4.3 p., t. y. pirkimas laikomas žaliu, nes perkama prekė - programinė įranga.

Bandymų apimtis

  • 1AAP su integruotu UAP funkcijos: UIL užklausos kelioms nuotolinėms eFTI platformoms, susietoms su kitais vartais, nei tie, prie kurių prijungtas užklausą teikiantis AAP; Identifikatoriaus (-ių) paieškos užklausa eFTI vartams; Tolesnė komunikacija; eFTI duomenų rinkinių filtravimas pagal KI pareigūno autorizaciją.
  • 2Bandymų scenarijai: Sėkmingas atvejis (angl. happy path). Teisingas duomenų užklausimas grąžina teisingą ir tikėtiną rezultatą; Neigiamas testavimas (angl. negative testing). Neteisingi įvesties duomenys, už leistų ribų esantys užklausimai, nepalaikomi formatai; Užklausos laiko limitas ir vėlavimas; Užklausos klaidos; Saugumas. Prieiga su nepakankamomis teisėmis arba su klaidingais vartotojo prisijungimo duomenimis.

Bandymų tikslai

  • 1Bandymų metu turi būti įrodyta, kad AAP su įdiegta UAP gali atlikti numatytus naudojimo atvejus (angl. use cases).
  • 2Išsamūs bandymai internetu: Duomenų užklausos pateikimas ir atsakymo gavimas naudojant eDelivery; Testavimas su platforma ir APP, pademonstruojant duomenų užklausos pateikimą (arba bandomųjų duomenų pateikimą, jei suderintas toks bandomasis scenarijus); Duomenų užklausos pateikimas ir atsakymo į duomenų užklausą pateikimas iš bent vienų eFTI vartų kitoje ES šalyje nei Lietuva.
  • 3Tarpsisteminių žinučių apsikeitimas: uilQuery ir uilResponse (duomenų rinkinio užklausos pateikimas ir atsakymas); identifierQuery ir identifierResponse (identifikatorių paieškos užklausa ir atsakymas); PostFollowUpRequest (tolesnės komunikacijos pateikimas).

Aplinkos reikalavimai

  • 1Sukurtas AAP ir jam išbandyti reikalingi eFTI techninės aplinkos komponentai turi būti diegiami Tiekėjo (suderinus su Pirkėju) pasirinktoje debesijos paslaugų teikėjo duomenų centro infrastruktūroje, naudojant išnuomotus (IaaS/PaaS) serverių, saugyklų ir tinklo resursus.
  • 2Tiekėjas privalo užtikrinti, kad visa diegimui ir sutartame eksploatacijos laikotarpyje reikalinga debesijos infrastruktūra būtų numatyta ir jos kaštai būtų pilnai įtraukti į Tiekėjo pasiūlymo kainą.
  • 3Tiekėjas turi užtikrinti, kad visi bandomojo sprendimo duomenys (įskaitant žurnalus) būtų saugomi ir apdorojami Europos Sąjungos teritorijoje. Jei samdomi subrangovai ar naudojamos valdomos paslaugos (PaaS), ši taisyklė taikoma ir jiems.

Bandymų dokumentacija

  • 1Tiekėjas privalo įtraukti nustatytas klaidas į bandymų ataskaitą.
  • 2Klaidų ataskaitoje privalo būti pateikta bent ši informacija: Aprašymas, kas įvyko ir kuo tai skiriasi nuo to, kas turėjo įvykti, kad visi galėtų suprasti problemą; Nuoroda į testą (numeris ar pavadinimas), kurio metu tai įvyko; Informacija, kaip atkurti klaidą (jei įmanoma); Informacija apie naudotą sistemos aplinką (pvz. testavimo, gamybinė); Klaidos klasifikacija: „Veiklos nutrūkimas“, „Veiklos sutrikdymas“, „Nedidelis defektas“.

Rezultatai ir ataskaitos

  • 1Sukurtas institucijų prieigos taškas su integruotu UAP: programinis kodas, įskaitant skriptus ir API, kartu su technine dokumentacija turi būti pateiktas Pirkėjui; Intelektinės teisės perduodamos Pirkėjui. Pirkėjas turi turėti galimybę naudoti ir keisti teises bei platinti kodą; Turi būti įgyvendinti visi šioje techninėje specifikacijoje nurodyti reikalavimai. Jei yra abipusiai suderinti techninės specifikacijos įgyvendinimo pakeitimai, jie turi būti užfiksuoti raštu ir pateikti kartu su galutine sistemos dokumentacija; Įgyvendinta integracija su KIPIS; Suteikta 6 mėn. garantinė kodo priežiūra.
  • 2Aplinką, kurioje atliekami techniniai bandymai, turi būti galima naudoti iki eFTI4EU projekto bandomųjų veiklų pabaigos (vėliausia data – 2026 m. lapkričio mėn.).
  • 3Užbaigti bandymai ir ataskaita anglų kalba apie techninius rezultatus pagal eFTI4EU bandymų planą. Ataskaitoje turi būti pateiktas išsamus bandymo, kuriame demonstruojami AAP naudojimo atvejai, aprašymas.
  • 4Aprašomojo pobūdžio ataskaita anglų kalba apie bandymo rezultatus, įskaitant tokius aspektus kaip komponentų veikimo apibendrinimas ir sistemos naudojimas pavojingų krovinių duomenims kontroliuoti. Ataskaitos šabloną su struktūra ir pagrindiniais klausimais pateiks eFTI4EU projektas.

Projekto įgyvendinimo grafikas

  • 1Planavimas ir suderinimas (Per 1 mėnesį nuo sutarties pasirašymo): Atnaujintas darbo planas, įskaitant susitarimus dėl: siūlomo aplinkos, skirtos išsamiems bandymams, įgyvendinimo scenarijaus; siūlomo techninio sprendimo AAP ir eFTI vartų integracijai; siūlomo bandomųjų eFTI duomenų užtikrinimo metodo; susitarimų dėl bet kokių techninių specifikacijų reikalavimų įgyvendinimo pakeitimų.
  • 2Kūrimo darbai (Per 5 mėnesius nuo sutarties pasirašymo): Sukurtas ir išbandytas institucijų prieigos taškas su integruotu UAP; Aplinkos, skirtos visapusiškam bandymui, sukūrimas.
  • 3Bandymai ir bandomojo projekto įgyvendinimas (Per 6 mėnesius nuo sutarties pasirašymo): Įvykdyti šioje techninėje specifikacijoje nustatyti bandymų ir bandomojo projekto tikslai.
  • 4Bandymų ir bandomojo projekto apibendrinimas (Per 7 mėnesius nuo sutarties pasirašymo): Bandymų ir bandomosios veiklos rezultatai apibendrinami rašytinėje ataskaitoje.
  • 5Perduodami rezultatai ir užbaigiamas projektas (Per 8 mėnesius nuo sutarties pasirašymo): Galutinė AAP versija perduodama Pirkėjui kartu su technine dokumentacija; Projekto rezultatai pristatomi Pirkėjo darbuotojams, patalpas suteiks Pirkėjas.

Paslaugų rezultatų priėmimo tvarka

  • 1Projekto rezultatai bus patvirtinti: Pirkėjo, siekiant užtikrinti, kad būtų įvykdyti visi techninių specifikacijų reikalavimai; vykdant eFTI4EU bandymų planą. Bandymų planas gali būti keičiamas atsižvelgiant į pavyzdinio programinio kodo atnaujinimus bei Europos Komisijos nustatytus techninius reikalavimus; Dalyvaujant eFTI4EU organizuojamame sistemų bandymų renginyje. Renginio formatas – 2 dienų trukmės fizinis susitikimas, kurio metu bandomi tarpsisteminių žinučių apsikeitimai tarp eFTI4EU projekto dalyvių. Susitikimas vyks ES valstybėje (konkreti vieta dar nėra žinoma). Tiekėjas visus dalyvavimo susitikime kaštus turi įsiskaičiuoti į Sutarties kainą.

AAP su integruota UAP: Veiklos žurnalas

  • 1AAP komponentas turi registruoti kiekvieną veiksmą atliktą AAP (įskaitant prieigos užklausas, atsakymus, klaidų atsiradimą ir tolesnius pranešimus), kad užtikrintas veiksmų eigos atsekamumas.
  • 2Veiklos žurnalas turi užfiksuoti: tikslų kiekvieno įvykio laiką, įvykio tipą (užklausa, atsakymas, klaida, tolesnė komunikacija), unikalų užklausos identifikatorių (URID), pareigūno identifikatorių (jei taikoma), klaidos informaciją (jei taikoma).
  • 3Visi žurnalai turi būti saugiai archyvuojami ne trumpiau kaip dvejus metus arba pagal nacionalinius teisės aktus.
  • 4AAP turi registruoti kiekvieną pateiktą tolesnį pranešimą, priskirdamas jam URID.
  • 5AAP privalo užregistruoti kiekvieną pateiktą prašymą: pirminio prašymo arba ankstesnio tolesnio pranešimo URID, eFTI duomenų UIL, pareigūno identifikavimo duomenis, Pateikimo datą ir laiką, Tolesnių veiksmų turinį.

AAP su integruota UAP: Autorizacijos valdymas

  • 1AAP turi palaikyti dinaminį Autorizacijos registrą su kiekvieno pareigūno prieigos ir tvarkymo teisėmis ir prieš bet kurią užklausą patikrinti prieigos teises.
  • 2Prieš priimdamas duomenų užklausą, AAP turi patikrinti kiekvieno pareigūno prieigos ir tvarkymo teises, kaip įrašyta leidimų registre.
  • 3AAP turi autorizuoti kiekvieną prašymą prieš leidžiant bet kokias duomenų užklausas, atmesdama prašymą, jei pareigūnas neturi aktyvių teisių.
  • 4AAP turi turėti pareigūnų prieigos teisių registro komponentą.
  • 5Autorizacijos registre turi būti saugoma ši informacija apie kiekvieną pareigūną: unikalus pareigūno identifikatorius, prieigos teisės (atsižvelgiant į atitinkamus ES / nacionalinius teisės aktus) pasiekti eFTI duomenų rinkinius, apdorojimo teisės (veiksmai, kuriuos leidžiama atlikti su eFTI duomenimis), registre atliktų pareigūno teisių pakeitimų žurnalas.
  • 6AAP turi patikrinti registre pareigūno teises gauti eFTI duomenų rinkinius prieš perduodamas užklausą į vartus.
  • 7Visi pakeitimai (atšauktos arba pasibaigusios teisės) turi būti atnaujinti registre realiu arba artimu realiam laikui ir užkirsti kelią tolesniems prieigos bandymams.
  • 8AAP turi įvykdyti kiekvieną prašymą, kuris pateikiamas pareigūno su galiojančiomis prieigos teisėmis.

AAP su integruota UAP: Sąsaja su eFTI vartais

  • 1AAP turi užmegzti ir palaikyti saugią, autentifikuotą sąsają su vietiniais eFTI vartais, kad galėtų perduoti duomenų užklausas ir apdoroti atsakymus į duomenų užklausas arba tolesnius pranešimus.
  • 2AAP perduodamose užklausose turi būti nurodoma unikalus užklausos ID, UIL (ar kitas identifikatorius) ir pareigūno teisių gauti informaciją patvirtinimas.
  • 3Sąsaja su eFTI vartais turi būti dvikryptė, kad būtų galima gauti atsakymus iš vartų.
  • 4Sąsaja turi palaikyti: autorizuotų prašymų perdavimą, atsakymų iš kitų vartų eFTI mainų aplinkoje gavimą, tolesnių ryšių apdorojimą.
  • 5Sąsaja turi būti paremta saugios viešojo rakto infrastruktūros (Public Key Infrastructure) naudojimu.

eFTI ekosistemos testavimo aplinka: eFTI vartai

  • 1eFTI vartų komponentas turi sukurti ir palaikyti saugias, autentifikuotas ir autorizuotas integracijas su išoriniais AAP, skirtas eFTI identifikatorių paieškos užklausoms ir atsakymams, eFTI duomenų rinkinių užklausoms ir atsakymams bei eFTI tolesnių pranešimų perdavimui.
  • 2Atsakymai į AAP užklausas, kuriuos siunčia eFTI vartai, perduodant eFTI identifikatorių rinkinius arba eFTI duomenų rinkinius, turi turėti visą eFTI identifikatorių rinkinį ir (arba) neapdorotus duomenų rinkinius, kuriuos eFTI vartai gavo iš eFTI platformų ir (arba) kitų susijusių eFTI vartų.
  • 3eFTI vartai turi apdoroti duomenų užklausas bei atsakymus į duomenų užklausas tarp eFTI vartų ir eFTI platformos, naudojant eDelivery arba lygiavertį saugų integracijos protokolą.
  • 4Sistema gali perduoti ir gauti duomenų užklausas bei atsakymus naudodama standartizuotą XML pranešimų formatą.
  • 5Vartai turi palaikyti tiesioginę sąsają su UAP, jei jis integruotas AAP.

AAP su integruota UAP: Duomenų rinkinių apdorojimas

  • 1AAP turi perduoti duomenų rinkinių užklausas su UIL eFTI vartams ir saugiai grąžinti atsakymus prašymą pateikusiam komponentui.
  • 2AAP turi perduoti eFTI duomenų užklausas vietiniams eFTI vartams ir priimti atsakymus su duomenų rinkiniais, kai šios užklausos įvykdomos.
  • 3Kiekviename duomenų užklausime turi būti pateikta visa reikalinga informacija užklausai įvykdyti (UIL, unikalus užklausos ID ir kompetentingos institucijos pareigūno prieigos teisės).
  • 4AAP gali palaikyti pakartotinį užklausos pateikimą tinklo ar apdorojimo klaidų atveju.
  • 5Atsakymas su eFTI duomenų rinkiniu turi būti gautas per 60 sekundžių (jei įmanoma) ir parodytas pareigūno UAP.
  • 6Jei duomenų rinkinio negalima pasiekti arba rasti, turi būti grąžintas klaidos pranešimas arba pranešimas, kad „nėra atsakymo“.
  • 7Visos duomenų užklausos bei atsakymai turi būti registruojami veiklos žurnale su laiko žymėmis ir užklausos įgyvendinimo rezultatu.

AAP su integruota UAP: KI pareigūno grafinė sąsaja

  • 1Integruotas UAP turi turėti grafinę naudotojo sąsają lietuvių kalba.
  • 2Ši sąsaja turi palaikyti funkcionalumus: pateikti identifikatorių paieškos užklausas, atsakymų į užklausas atvaizdavimą (pvz., eFTI duomenys, klaidų pranešimai), prisijungimą darbui su eFTI aplinka, atitinkantį IAA reikalavimus nurodytus šioje techninėje specifikacijoje ir eFTI Reglamente.

eFTI ekosistemos testavimo aplinka: Bendrieji reikalavimai

  • 1Turi būti pateikta techninė aplinka visapusiškam (angl. end to end) testavimui perduodant informaciją iš eFTI platformos į sukurtą AAP per eFTI vartus.
  • 2eFTI vartai gali būti: sukurti Tiekėjo naudojant eFTI4EU pavyzdinį programinį kodą. Turi būti naudojama naujausia prieinama versija, jei ji išleidžiama iki 4 šio bandomojo projekto įgyvendinimo mėnesio; pateiktas tiekėjo. Tiekėjas gali pasiūlyti savo eFTI vartų versiją. Siūlomi eFTI vartai turi atitikti visus šioje techninėje specifikacijoje nustatytus reikalavimus, kad būtų galima tinkamai išbandyti AAP.
  • 3Identifikatorių registras, kuris yra neatskiriama eFTI vartų dalis ir palaiko paieškos mechanizmą eFTI aplinkoje.
  • 4eDelivery konfigūracija ryšiui su kitais eFTI vartais. eDelivery yra privaloma sąsaja tarp eFTI vartų ir turi būti įdiegiama kartu su eFTI vartais. eDelivery konfigūraciją, reikalingą prisijungti prie eFTI aplinkos, suteiks eFTI4EU.
  • 5eFTI platforma arba imitacinė eFTI platforma, skirta sukurti ir pateikti bandomiesiems pavojingo krovinio duomenims.

eFTI ekosistemos testavimo aplinka: eFTI vartų ir AAP integracija

  • 1Vartai turi tvarkyti registrą su patvirtintų AAP identifikatoriais ir saugumo sertifikatais. Kiekvienas AAP bandymas autentifikuotis vartuose turi būti registruojamas veiklos žurnale.
  • 2Jei autentifikavimas nepavyksta, ryšys turi būti nutrauktas, pateikiant atmestam AAP klaidos pranešimą.
  • 3Sistema turi grąžinti klaidos pranešimus, jei negalima užmegzti arba išlaikyti saugaus ryšio.

eFTI ekosistemos testavimo aplinka: Identifikatorių registras (ROI)

  • 1eFTI vartų sprendimas turi užtikrinti visas eFTI reglamente ir eFTI4EU techninėse specifikacijose nustatytas identifikatorių registro funkcijas.
  • 2Identifikatorių registras (ROI) turi saugoti duomenų elementus (identifikatorių rinkinį), susijusius su eFTI duomenų rinkinio UIL: Siunta (eFTI39 Data, kurią vežėjas priima siuntą (Tipas=DataLaikas); eFTI188 Faktinė įvykio data ir laikas (Tipas=Data ir laikas)); Pagrindinis vežimas (eFTI581 Transporto rūšies kodas (Tipas=kodas, formatas=n1, Vertė= 1,2,3,4 arba 8); eFTI618 ID Transporto priemonės identifikatorius (Formatas=an..17); eFTI620 Registracijos šalies kodas (Tipas=kodas, Format=a2, Visi kodai pagal ISO63166-1 alpha-2); eFTI1451 Pavojingų krovinių žymė (Vertė = „true“ arba „false“)); Naudota transporto įranga (eFTI987 Eilės numeris (Tipas = skaitmeninis, formatas = n..16); eFTI374 ID Transporto priemonės identifikatorius (Formatas=an..17); eFTI578 Registracijos šalies kodas (Tipas=kodas, formatas=a2, Visi kodai pagal ISO63166-1 alpha-2); eFTI378 Kategorijos kodas (Tipas=kodas, formatas=an..3, Vertė=AE, AM, BR, BX, BPO, BPP, BQP, BPR, BPX, CN, DPL, RF, RR, SM, SW, TE, TN, T1, T2, T3, T4, T5, T6, T7, T9, T10, T11, T12, T13, T14, DV, GT, CT, NT)); Vežimo įranga (eFTI1000 Eilės numeris (Tipas = skaitmeninis, formatas = n..16); eFTI1448 ID Vežamos transporto priemonės identifikatorius (Formatas=an..17)).
  • 3eFTI vartai turi turėti galimybę identifikatorių registre (ROI) pridėti ir atnaujinti identifikatorių rinkinį (susijusį su eFTI duomenų rinkinio UIL).
  • 4Naujas identifikatorių rinkinys turi būti pridėtas / atnaujintas tik tuo atveju, jei jis yra galiojantis. Privalomi laukai turi būti užpildyti; Duomenų elementų tipas, formatas ir reikšmės turi atitikti numatytus, kaip apibrėžta eFTI4EU pavyzdiniame programiniame kode.
  • 5Įkėlus ar atnaujinus, identifikatorių rinkinys turi būti aktyvuotas ir prieinamas paieškai.

AAP su integruota UAP: Integracija su uosto informacine sistema KIPIS

  • 1AAP turi būti įgyvendinta įvykių perdavimo integracija su KIPIS, informuojanti atsakingą pareigūną apie įvykius, kai transporto priemonė su pavojingu kroviniu atvyksta į uostą. Integracija skirta perduoti informaciją iš KIPIS į AAP, atsakymas neteikiamas.
  • 2AAP turi būti įgyvendinta integracija su KIPIS perduoti informaciją, kai Uosto priežiūros tarnyba suteikia leidimą į Uostą įvežti 1 ir 7 klasės pavojingus krovinius. Integracija skirta perduoti informaciją iš KIPIS į AAP, atsakymas neteikiamas.
  • 3KIPIS programinio kodo pakeitimo darbus, reikalingus integracinei sąsajai su AAP sukurti, atliks Pirkėjas.

AAP su integruota UAP: Prisijungimas prie eFTI duomenų mainų aplinkos

  • 1AAP komponentas turi prisijungti prie eFTI vartų, užmegzdamas saugų ryšį ir perduodamas reikiamus registracijos duomenis (unikalų identifikatorių, saugos kredencialus).
  • 2Tik autorizuoti AAP turi gauti prieigą prie eFTI aplinkos per eFTI vartus; neautorizuoti ar nežinomi AAP su vartais komunikuoti negali.
  • 3AAP turi palaikyti bent vieną KI pareigūno profilį, skirtą gauti pavojingų krovinių eFTI duomenis.
  • 4Vartuose taikomos autentifikavimo procedūros turi leisti patikrinti AAP tapatybę ir autentiškumą pagal eFTI Reglamento ir techninius reikalavimus. Turi būti užtikrinamas saugus ryšys.

eFTI ekosistemos testavimo aplinka: Identifikatorių paieškos parametrai

  • 1Identifikatorius (identifikavimo numeris) (Privaloma): Tipas=Tekstas, Formatas=an..17 (pvz., transporto priemonės registracijos numeris).
  • 2Identifikatoriaus tipas (Neprivaloma): Vertės sąrašas (0..3) iš „priemonės“, „įranga“ arba „vežama“. Parametras tuščias = paieška tarp visų duomenų elementų (eFTI618 AR eFTI374 AR eFTI448 atitikimas).
  • 3Registracijos šalies kodas (Neprivaloma): Tipas=kodas, formatas=a2, Visi kodai pagal ISO63166-1 alpha-2. Ignoruojama, jei atliekama „pernešto“ tipo paieška (eFTI1448). Naudojamas tik tuo atveju, jei identifikavimo numerio paieška grąžina kokius nors rezultatus. Tokiu atveju jis naudojamas rezultatams filtruoti (duomenų elementai eFTI578 IR eFTI620, priklausomai nuo paieškos identifikatorių tipų).
  • 4Režimo kodas (Neprivaloma): Tipas=kodas, formatas=n1, Vertė = 1, 2, 3, 4 arba 8. eFTI581 pagrindinio vežimo transporto judėjimo režimo kodas yra filtruojamas pagal tą parametrą, o tai reiškia, kad visi UIL, kurių pagrindinio vežimo transporto judėjimo kodas „ “ nėra lygus įvestam parametrui, nebus grąžinti.
  • 5Pavojingų krovinių indikatorius (Neprivaloma): Tipas=Boolean, Vertė = true arba false. eFTI1451 pagrindinio vežimo transporto judėjimo pavojingų krovinių indikatorius tada yra filtruojamas pagal tą parametrą, o tai reiškia, kad visi UIL su (true) arba be (false) pavojingų krovinių nebus grąžinti. Jei UIL eFTI1451 neturi vertės ROI, tada ieškant true arba false vertės, tas UIL neturi būti grąžintas.

eFTI ekosistemos testavimo aplinka: Identifikatorių paieškos rezultatai

  • 1Identifikatorių paieškos užklausą atitinkantys atsakymai su susijusiu UIL (UIL sąrašas su susietais identifikatoriais) grąžinami paieškos užklausą pateikusiam KI pareigūnui per eFTI vartus. Jei susijusios UIL nerandama, grąžinamas tuščias sąrašas.
  • 2Neaktyvūs ROI UIL / identifikatorių rinkiniai turi būti pašalinti iš paieškos rezultatų.

eFTI ekosistemos testavimo aplinka: Identifikatorių registro paieškos mechanizmas

  • 1eFTI vartai turi palaikyti identifikatorių paieškas, ateinančias iš tų pačių eFTI vartų, kuriems priklauso ROI, ir iš kitų eFTI ekosistemos eFTI vartų.
  • 2eFTI vartai turi įgyvendinti funkciją gauti UIL į duomenų rinkinį, kuomet ROI randamas su konkrečiu identifikatoriumi susijęs duomenų rinkinys ar rinkiniai.
  • 3Turi būti įgyvendintos šios paieškos taisyklės ir parametrai: Vienas iš galimų identifikavimo numerių (ID) turi būti paieškos kriterijus (eFTI618, eFTI374, eFTI1448).
  • 4Negalima leisti naudoti simbolių pakaitų.
  • 5Paieška turi būti neatspari didžiųjų ir mažųjų raidžių skirtumui.

AAP su integruota UAP: eFTI duomenų užklausos naudojant identifikatoriaus paiešką

  • 1AAP komponentas turi užtikrinti galimybę atlikti identifikatoriais grįstą paiešką, nurodant vieną ar kelis identifikatorius, kad gautų atitinkamus unikalius identifikavimo nuorodas (UIL), reikalingas eFTI duomenų prieigai.
  • 2AAP turi perduoti UIL užklausas vietiniams vartams; pranešime turi būti vienas ar daugiau Reglamente apibrėžtų identifikatorių paieškai atlikti.
  • 3Užklausos pranešime turi būti vienas ar daugiau eFTI reglamente apibrėžtų identifikatorių.
  • 4Atsakymas su identifikatorių paiešką atitinkančiais UIL turi būti gautas ir grąžintas prašymą pateikusiai UAP per 60 sekundžių, jei randamas susijęs duomenų rinkinys.
  • 5Jei atitikimo identifikatoriaus nerasta, turi būti grąžintas klaidos pranešimas.
  • 6Visi perdavimai turi būti registruojami veiklos žurnale su laiko žymėmis ir užklausos įvykdymo rezultatais užtikrinti atsekamumą auditui.

eFTI ekosistemos testavimo aplinka: Identifikatorių paieškos rezultatų konsolidavimas

  • 1eFTI vartai turi sujungti (angl. contcatenate) identifikatorių paieškos rezultatus (susijusius su gauta užklausa iš UAP) iš visų kitų vartų (priimančiųjų / nuotolinių vartų), kad būtų užtikrinta, jog grąžinami visi atitinkami rezultatai. Vartai neturi atlikti jokio tolesnio identifikatorių paieškos rezultatų apdorojimo.
  • 2Visi rezultatai turi būti sujungti į vieną atsakymą, kuris yra UIL sąrašas ir su šiais UIL susijusių identifikatorių sąrašas.
  • 3Konsoliduota būsena yra: ERROR, jei iš nuotolinių vartų gauta viena ar daugiau klaidų; TIMEOUT, jei klaidų negauta, tačiau bent pasibaigė laikas rezultatams atsiųsti ir negautas bent vienas atsakymas; COMPLETE, jei negauta jokių klaidų ir nė vieni eFTI vartai neviršijo numatyto atsakymo laiko rezultatams atsiųsti.

eFTI ekosistemos testavimo aplinka: eDelivery konfigūracija ryšiui su kitais eFTI vartais

  • 1eFTI vartai turi turėti eDelivery prieigos tašką, skirtą keistis žinutėmis su kitais eFTI vartais, užtikrinant: saugius duomenų mainus, sąveiką, standartizuotą AS4 protokolą, saugą ir atitiktį, duomenų šifravimą tarp sistemos komponentų nuo pradžios iki galo, veiksmų registrą ir atsekamumą audito tikslais, pranešimų patikimumą.
  • 2Kiekvieno eFTI vartų eDelivery įgyvendinimas turi atitikti bendrą P-mode režimą (Processing Mode), kuris apibrėžia, kaip keičiamasi pranešimais tarp eFTI aplinkos dalyvių.
  • 3„eDelivery“ konfigūracija turi atitikti eFTI4EU pavyzdinį kodą, kuris pateikiamas https://github.com/EFTI4EU/reference-implementation

eFTI ekosistemos testavimo aplinka: eFTI platforma arba imituota eFTI platforma bandomiesiems duomenims

  • 1Tiekėjas turi suteikti prieigą prie eFTI platformos duomenų.
  • 2Preliminarūs scenarijai apima: eFTI platformos, galinčios kurti ir atsakyti užklausas su atitinkamais pavojingų krovinių eFTI duomenų rinkiniais, prijungimą. Prieiga prie eFTI platformos suteikiama Paslaugų įgyvendinimo apimtyje; bandomųjų duomenų generavimą ir būtiną konfigūraciją eFTI platformų funkcijoms atlikti, užtikrinant minimalius reikalingus eFTI platformos funkcionalumus.
  • 3Tiekėjas privalo pasiūlyti ir suderinti su Pirkėju scenarijų bandomųjų duomenų teikimui per 1 mėnesį nuo Paslaugų teikimo sutarties pasirašymo. Sutartas scenarijus turi būti įtrauktas į atnaujintą darbo planą.

AAP su integruota UAP: Kompetentingų institucijų pareigūnų identifikavimas, autentifikavimas ir autorizavimas

  • 1AAP turi identifikuoti, autentifikuoti ir autorizuoti kompetentingų institucijų (KI) pareigūnus, vadovaujantis Autorizacijos registre nurodytomis jų prieigos ir tvarkymo teisėmis, prieš suteikdamas tolesnę prieigą prie eFTI aplinkos.
  • 2AAP turi identifikuoti kiekvieną kompetentingos institucijos pareigūną panaudojant integruotą autentifikavimo procesą.
  • 3AAP turi užtikrinti, kad gauta užklausa būtų pateikta tik KI, kuri naudoja šią AAP, pareigūno.
  • 4AAP turi užtikrinti, kad tik autentifikuoti ir autorizuoti pareigūnai galėtų pateikti prašymus ir gauti duomenis kontrolei per AAP.

eFTI ekosistemos testavimo aplinka: Automatinis identifikatorių, įtrauktų į identifikatorių registrą, deaktyvavimas ir ištrynimas

  • 1Kai faktinė siuntos pristatymo data ir laikas įrašomi / atnaujinami UIL identifikatorių registre, eFTI vartai po sutarto laiko tarpo turi automatiškai deaktyvuoti tą UIL.
  • 2Turi būti galimybė numatyti skirtingą laiko tarpą priklausomai nuo transporto rūšies ir faktinio pristatymo laiko.
  • 3Deaktyvacija turi įvykti sutartam laiko tarpui pasibaigus, ilgiausiai išsaugant įrašą ROI iki 1 dienos.
  • 4Bendra taisyklė: UIL deaktyvavimas ir išbraukimas iš identifikatorių registro turi būti atliktas eFTI vartų kitą dieną po faktinio krovinio pristatymo, išskyrus kelių transportą, kai deaktyvavimas turi būti atliktas 13 dieną po transportavimo pabaigos (kad būtų galimybė gauti informaciją kabotažo patikrinimų atveju).
  • 5Kelių transportas (be kabotažo): Pristatymo data <= Dabartinė diena (minimalus vėlavimas 0 dienų, maksimalus vėlavimas 1 diena); Pristatymo data > Dabartinė diena (minimalus vėlavimas 0 dienų nuo pristatymo datos, maksimalus vėlavimas 1 diena nuo pristatymo datos); Pristatymo data neužpildyta (minimalus vėlavimas 90 dienų nuo vežėjo priėmimo datos, maksimalus vėlavimas 100 dienų nuo vežėjo priėmimo datos).
  • 6Kelių transportas (su kabotažu): Pristatymo data <= Dabartinė diena (minimalus vėlavimas 12 dienų, maksimalus vėlavimas 13 dienų); Pristatymo data > Dabartinė diena (minimalus vėlavimas 12 dienų nuo pristatymo datos, maksimalus vėlavimas 13 dienų nuo pristatymo datos); Pristatymo data neužpildyta (minimalus vėlavimas 90 dienų nuo vežėjo priėmimo datos, maksimalus vėlavimas 100 dienų nuo vežėjo priėmimo datos).

Dokumentai12

  • 2_Draft contract and technical task - annex 9.pdf
  • espd-request.xml
  • espd-request.pdf
  • README.txt
  • 5_Pirkimo dokumentu - 9 priedas.pdf
  • 6_Pirkimo+dokumentai+-+prieigos+tasko+sukurimo+pirkimo+dokumentai.doc.pdf
  • 7_Procurement documents - acces point purchase.pdf
  • 7324641_National Contract notice or Design Contest notice - sectoral directive, standard regime_0.pdf
  • 1_Annexes - 1, 2, 3, 4, 5, 6 ir 7.docx
  • 3_Pirkimo dokumentu - 1, 2, 3, 4, 5, 6 ir 7 priedai.docx
  • 8_c4t_7324641_1.xml
  • 1092_7324641.pdf
tendis.lt · Sukurta recodin.lt