Atviro konkurso sąlygų4 priedas

BENDROJO PAGALBOS CENTRO INFORMACINĖS SISTEMOS FUNKCINĖ SPECIFIKACIJA

PIRKIMO OBJEKTAS

1. Pirkimo objektas – esamos Bendrojo pagalbos centro informacinės sistemos BPCIS programinės įrangos diegimas ir konfigūravimas Vilniaus regioniniame padalinyje.

2. Perkamas esamos programinės įrangos diegimo ir konfigūravimo paslaugas sudaro:2.1. Pagalbos skambučių administravimo specializuotos programinės įrangos „Siveillance

ELS Web“ diegimas ir konfigūravimas;2.2. Skambučių paskirstymo programinės įrangos „ProCenter“ diegimas ir konfigūravimas;2.3. Balso įrašymo programinės įrangos „Retia ReDAT3“ diegimas ir konfigūravimas.3. Esamos programinės įrangos nereikia papildomai adaptuoti, modifikuoti ir pritaikyti tam,

kad ji atitiktų 4 priede nurodytas funkcines specifikacijas.4. Bendrojo pagalbos centro informacinės sistemos programinės įrangos diegimo ir

konfigūravimo Vilniaus regioniniame padalinyje pirkimas yra 2010 m. vykdyto pirkimo Nr. 88486 tąsa.

5. Reikalavimai programinės įrangos diegimui ir bandymui:5.1. Tiekėjas privalo:5.1.1. atlikti pasiūlyme įvardintos programinės įrangos diegimą ir konfigūravimą;5.1.2. atlikti testus ir priduoti perkančiajai organizacijai pilnai įdiegtą ir sukonfigūruotą

programinę įrangą pagal konkurso sąlygų 4 priedą;5.1.3. testų metu pademonstruoti funkcinėje specifikacijoje išvardintų reikalavimų

įgyvendinimą.

6. Reikalavimai garantinei priežiūrai ir aptarnavimui:6.1. Įdiegtai ir sukonfigūruotai esamai programinei įrangai turi būti suteikta 3 (trijų)

mėnesių, nuo diegimo ir konfigūravimo darbų atlikimo priėmimo-perdavimo akto pasirašymo datos, garantija, kurios laikotarpiu:

6.1.1. su garantinę priežiūrą vykdančiu subjektu bus komunikuojama lietuvių kalba;6.1.2. bus nemokamai šalinami programinės įrangos veiklos sutrikimai;6.1.3. programinės įrangos darbingumas – funkcinėje specifikacijoje numatytas

programinės įrangos funkcionalumas – turės būti atkuriamas ne vėliau kaip per 24 valandas, skaičiuojant nuo perkančiosios organizacijos išsiųsto pranešimo (el. paštu ir telefonu) apie programinės įrangos darbingumo sutrikimus datos ir laiko.

7. TrumpiniaiSantrumpa Reikšmė

BPC Bendrasis pagalbos centrasDB Duomenų bazėDBVS Duomenų bazių valdymo sistemaGIS Geografinė informacinė sistemaGMPS Greitosios medicinos pagalbos stotisGPRS Mobiliojo ryšio technologija, skirta duomenų perdavimui GSM ir D-AMPS

tinkluose.GPS Padėties nustatymo sistemaGSM Globalus mobilių telefonų ryšio standartas

Santrumpa Reikšmė

IS Informacinė sistemaPGT Priešgaisrinė gelbėjimo tarnybaPK Policijos komisariatasPT Pagalbos tarnybosPT pajėgų vienetai Policijos pėstieji patruliai arba ekipažai, ugniagesių gelbėtojų ekipažai,

greitosios medicinos pagalbos automobiliai (brigados)RBPC Regioninis Bendrasis pagalbos centro padalinysSistema Integrali Bendrojo pagalbos centro informacinės sistema

8. BPC informacinės sistemos funkcionalumo reikalavimai:7.1. Bendrieji Sistemos funkciniai parametrai3.1.1. Sistema privalo būti integrali, t.y. viso Sistemos funkcionalumo valdymas privalo būti integruotas į vieną vartotojo sąsają.3.1.2. Sistema privalo būti lituanizuota. Visi užrašai ir pavadinimai darbo vietos ekrane privalo būti paprastai modifikuojami be programos kodo keitimo. Sistema privalo palaikyti Unicode simbolius.3.1.3. Sistema privalo turėti įrankius naudotojų grupių ir teisių kūrimui ir konfigūravimui atlikti. Kiekvienai naudotojų grupei privalo būti galimybė priskirti teises kiekvienos funkcijos naudojimui bei bet kurio naudotojo sąsajos matymui ir keitimui. Konfigūravimas privalo būti atliekamas Sistemos administratoriaus be programinio kodo keitimo.3.1.4. Sistemoje privalo būti galimybė integruoti PT naudojamas analoginio ir skaitmeninio radijo ryšio sistemas .3.1.5. Sistema privalo veikti nuolat atidarytuose languose be „iššokančių“ langų (angl. pop-ups).3.1.6. Sistema privalo turėti struktūrizuotų klausimų skambinančiajam uždavimo ir atsakymų į juos parinkimo konfigūravimo modulį. Klausimai privalo būti organizuojami į klausimų – atsakymų medį. Šis klausimų-atsakymų modulis privalo turėti sąsają su pagalbos tarnybų teritorijomis ir PT pajėgų vienetais (angl. field unit).3.1.7. Sistema privalo turėti PT pajėgų vienetų automatinio parinkimo modulį, kuris parenka reikiamus atitinkamo statuso vienos ar kelių pagalbos tarnybų pajėgų vienetus (pajėgų vienetų grupes) pagal įvykio vietą (geografines koordinates), įvykio tipą, klausimyno atsakymus ir kitą pranešimo apie pagalbos poreikį kortelės informaciją.3.1.8. Sistema privalo turėti rankinio PT pajėgų vienetų priskyrimo „drag&drop“ veiksmų funkciją.3.1.9. Sistema privalo turėti adreso informacijos paieškos funkciją pagal vietovės ar gatvės pavadinimo pradžią (sinonimai) ir pasiūlyti pasirinkti adreso informacijos lauko užpildymo variantus. Paieška privalo veikti atsižvelgiant į fonetines taisykles.3.1.10. Sistema privalo užtikrinti, kad kiekvienas įvykio valdymo žingsnis būtų išsaugomas istorinėje įvykio duomenų bazėje ir vėliau bet kuriuo momentu gali būti patikrintas. Istorinė informacija privalo būti nekintama net keičiant programos nustatymus, parametrus ir kintamuosius ir bet kada privalo užtikrinti įrašų autentiškumą. Informacija apie tai, kas atliko pakeitimus bei kada, privalo būti prieinama ir pateikiama tik administratoriui.3.1.11. Sistema privalo užtikrinti naudotojo sąsajos duomenų spausdinimo formų generavimą.3.1.12. Sistema privalo užtikrinti kompiuterinės ir telefoninės įrangos integracijos (angl. CTI) funkcijas:3.1.12.1. automatinį naujos pranešimo apie pagalbos poreikį kortelės sukūrimą atsakius į pagalbos skambutį operatoriaus darbo vietoje;3.1.12.2. skambučio iš stacionariojo telefono atveju – skambinančiojo adresą pagal telefonų DB ir adreso vietą žemėlapyje pagal kadastrinių objektų (adresų) DB.3.1.13. Sistema privalo gebėti importuoti duomenis iš išorinės telefonų ir adresų DB.3.1.14. Sistema privalo gebėti importuoti ir saugoti duomenis iš išorinės kadastrinių objektų (adresų) DB. Sistema privalo saugoti kadastrinių objektų DB geodezines koordinates.3.1.15. Sistemoje (DB) privalo būti registruojama ši informacija apie įvykį:3.1.15.1. skambinančiojo telefono numeris;3.1.15.2. skambinančiojo vieta;3.1.15.3. skambinančiojo laikas;3.1.15.4. įvykio tipas;3.1.15.5. įvykio vieta;

2

3.1.15.6. įvyko laikas;3.1.15.7. į įvykį reaguojantys PT pajėgų vienetai.3.1.16. Skirtingos įvykio būklės (pvz., kuriamas, atidarytas (sukurtas), aliarmuotas, baigtas, anuliuotas ir pan.) privalo būti automatiškai žymimos ir pavaizduojamos vartotojui skirtingomis spalvomis.3.1.17. Sistema pagal įvykio informaciją automatiškai privalo nustatyti kokie PT (PGT, PK, GMPS) pajėgų vienetai turi dalyvauti pagalbos teikimo procese.3.1.18. Sistema pagal įvykio informaciją privalo automatiškai siūlyti kokia apimtimi ir kokie specifiniai PT pajėgų vienetai turi dalyvauti pagalbos teikime.3.1.19. Sistema automatiškai privalo suformuoti pranešimo apie pagalbos poreikį kortelę pagal informaciją, surinktą apklausiant skambinantįjį ar pagal sistemos pateiktą klausimyną.3.1.20. Sistemoje privalo būti funkcija, leidžianti vėliau papildyti pranešimą apie pagalbos poreikį pagal vėlesnius skambučius ar gavus papildomą informaciją pagalbos teikimo metu iš PT pajėgų vienetų.3.1.21. Sistema privalo perduoti pranešimą apie pagalbos poreikį atitinkamoms PT automatiškai, iš karto, kai tik toks pranešimas parengtas.3.1.22. Sistema privalo užtikrinti, kad BPC operatorius galėtų išsiųsti pranešimą apie pagalbos poreikį PT iš karto po to, kai tik užregistruojamas įvykis.3.1.23. Sistema privalo perduoti pranešimus apie pagalbos poreikį ir kitą informaciją šioms PT:3.1.23.1. PK – į PK operatyvaus valdymo padalinį ir PK pajėgų vienetų judriuosius terminalus;3.1.23.2. PGT – į PGT valdymo punktą ir PGT pajėgų vienetų judriuosius terminalus;3.1.23.3. GMPS – į GMPS dispečerinę ir GMPS pajėgų vienetų judriuosius terminalus.3.1.24. Sistemoje PT dispečeris privalo turėti galimybę nustatyti tinkamą pajėgų vienetų poreikį (sutikti su Sistemos pasiūlytais PT pajėgų vienetais, papildyti jais, ar pakeisti kitais PT pajėgų vienetais).3.1.25. BPC operatoriai ir PT dispečeriai Sistemoje turi galėti informuoti atitinkamus PT pajėgų vienetus apie pagalbos poreikį sisteminėmis priemonėmis (teksto žinutėmis, balso kanalu) į įvykiui priskirtų PT pajėgų vienetų judriuosius terminalus.3.1.26. Sistema privalo perduoti pranešimus apie pagalbos poreikį ir aliarmo signalą PT pajėgų vienetams naudojantis šiomis priemonėmis:3.1.26.1. GPRS;3.1.26.2. SMS žinutėmis;3.1.26.3. skaitmeniniu radijo ryšiu;3.1.26.4. kompiuterių tinklu spausdinant įvykių korteles į nutolusius spausdintuvus.3.1.27. Sistema privalo užtikrinti, kad PT dispečeris ir PT pajėgų vienetai gautų anksčiau priimto pranešimo apie pagalbos poreikį papildymą.3.1.28. Sistemoje privalo būti funkcija, leidžianti PT dispečeriui atnaujinti (papildyti) pranešimą apie pagalbos poreikį pagal informaciją, gautą iš BPC ar kito šaltinio, ir perduoti ją į priskirtų PT pajėgų vienetų judriuosius terminalus.3.1.29. PT dispečeris ir PT pajėgų vienetai, turintys judriuosius terminalus Sistemoje privalo galėti savarankiškai keisti valdomų pajėgų vienetų (PT dispečeris) arba savo (PT pajėgų vienetas) statusą.3.1.30. BPC operatorius privalo galėti Sistemoje stebėti PT pajėgų vienetų statusus.3.1.31. Sistema privalo automatiškai kontroliuoti laiką, per kurį PT pajėgų vienetai atvyksta į įvykio vietą, fiksuojant statusų pasikeitimo laiką.3.1.32. Sistemos (GIS modulyje) privalo būti grafiškai pavaizduojami PT pajėgų vienetai pagal iš judriųjų terminalų ir GPS imtuvų gautas PT pajėgų vienetų koordinates.3.1.33. Sistema privalo užtikrinti, kad iš judriųjų terminalų ir GPS imtuvų gauti PT pajėgų vienetų statusai būtų rodomi sistemos GIS modulyje kartu su koordinatėmis.3.1.34. Sistema privalo užtikrinti, kad esant poreikiui pagal nustatytus filtrus gautas PT pajėgų vienetų koordinates Sistemoje matytų tik atitinkamų PT dispečeriai ir BPC operatoriai.3.1.35. Sistema privalo užtikrinti, kad PT dispečeriai ir BPC operatoriai galėtų:3.1.35.1. priskirti papildomus PT pajėgų vienetus;3.1.35.2. priskirti kitas PT pajėgas vykti į įvykio vietą perduodant joms pranešimo apie pagalbos poreikį kortelę;3.1.35.3. koordinuoti PT pajėgų vienetų judėjimą realiu laiku pagal gautą informaciją iš GIS teikiamų PT pajėgų vienetų judėjimo koordinačių;3.1.35.4. perduoti papildomą informaciją (gautą iš skambinančiųjų arba kitų pagalbą šiam įvykiui teikiančių tarnybų) į PT pajėgų vienetų judriuosius terminalus.3.1.36. Sistema privalo užtikrinti, kad PT dispečeris ir BPC operatorius savo darbo vietoje matytų, kurios

3

pranešimo apie pagalbos poreikį kortelės buvo uždarytos (užbaigtos).3.2. Sistemos GIS modulio funkciniai parametrai

3.2.1. Žemėlapyje privalo būti rodoma informacija apie pavaizduotų objektų adresus.3.2.2. Žemėlapyje privalo būti pavaizduojami dinaminiai geografiniai duomenys (pvz.: transporto priemonių buvimo vieta).3.2.3. Sistema privalo palaikyti šiuos skaitmeninių žemėlapių formatus:3.2.3.1. GIF (angl. Graphics Interchange Format);3.2.3.2. GDF (angl. Geographic Data Files).3.3. Sistemos telefonijos dalies funkciniai parametrai3.3.1. Sistema privalo užtikrinti skambučio priėmimą rankiniu ir automatiniu būdu.3.3.2. Sistema privalo turėti funkciją, leidžiančią nutraukti pokalbį operatoriaus iniciatyva.3.3.3. Sistema privalo turėti funkciją, leidžiančią nukreipti (angl. forward) ar inicijuoti skambinantįjį į atitinkamą PT ar išorinį numerį.3.3.4. Sistema privalo turėti funkciją, leidžiančią konferenciniu ryšiu susisiekti su reikiamos PT dispečeriu.3.3.5. Sistema privalo turėti funkciją, leidžiančią organizuoti konferencinį ryšį su keliomis PT vienu metu.3.3.6. PT dispečeris turi galėti informuoti atitinkamus PT pajėgų vienetus apie pagalbos poreikį į įvykiui priskirtų PT pajėgų vienetų telefonus.3.3.7. Sistema privalo turėti skambučių įtraukimo į eilę funkciją, jei visi operatoriai užimti.3.3.8. Sistema privalo turėti elektroninį telefonų katalogą išeinančių skambučių inicijavimui, sujungimams bei konferenciniam ryšiui užtikrinti.3.3.9. Sistema privalo turėti pokalbio užlaikymo (angl. Hold) funkciją.3.3.10. Sistema privalo turėti galimybę pasirinkti darbą mikrofonu arba garsiakalbiu.3.3.11. Sistema privalo turėti automatinio skambučio siuntimo funkciją ilgiausiai laisvai esančiai aktyviai (angl. logged in) kompiuterizuotai darbo vietai ir automatinio skambučio siuntimo kitai ilgiausiai laisvai esančiai aktyviai darbo vietai, jei ankstesniojoje vietoje į skambutį nebuvo atsakyta tam tikrą laiką.3.3.12. Sistema privalo turėti funkciją, leidžiančią pagal tam tikrus požymius išskiriamus skambučius (pvz., pagal telefono numerį) siųsti į tam tikrą vieną kompiuterizuotą darbo vietą.3.3.13. Sistema privalo turėti funkciją, leidžiančią iš GSM tinklų priimamus skambučius, inicijuotus telefono be SIM kortelės, nukreipti į specialų pranešimą ir tik po to nukreipti BPC operatoriui.3.3.14. Sistema privalo skirstyti įeinančius skambučius BPC operatoriams pagal jų gebėjimų lygius tolygiai, siekiant išlaikyti vienodą operatorių apkrovimą.3.3.15. Sistema privalo užtikrinti tiesioginį skambučių priėmimą iš „Teo LT, AB“, UAB „Omnitel“, UAB „Bitė Lietuva“ ir UAB „Tele2“ operatorių tinklų.3.3.16. Sistema privalo užtikrinti sujungimą ir integraciją su esama BPC telefonijos sistema, užtikrinant vieningą numeraciją ir skambinančiųjų informacijos (numerio, vardo, pavardės atvaizdavimą telefono aparate ir per kompiuterio-telefono sąsają). Skambinančiojo informacijos perdavimas turi veikti ir skambučio peradresavimo (forward), konsultavimosi bei konferencinio ryšio atvejais.3.3.17. Sistemos telefonijos posistemė turi būti visiškai integruota su Sistema ir užtikrinti 3.1.12 reikalavimo bei automatizuoti 3.1.9 reikalavimo įgyvendinimą.3.4. Sistemos radijo ryšio dalies funkciniai parametrai3.4.1. Kai PT pajėgų vienetai neturi judriųjų terminalų, Sistemoje privalo būti galimybė perduoti informaciją radijo ryšiu naudojant PT eksploatuojamas radijo ryšio sistemas.3.4.2. Sistema privalo užtikrinti informacijos perdavimą tiek individualiai kiekvienam PT pajėgų vienetui, tiek ir PT pajėgų vienetų grupei.3.5. Statistinių duomenų apdorojimo ir pateikimo funkciniai parametrai3.5.1. Privalo užtikrinti paieškos ir analizės funkciją.3.5.2. Privalo būti galimybė ieškoti informacijos pagal bet kurią savybių kombinaciją (naudojant jungtukus, žodžių dalis).3.5.3. Privalo būti šios paieškos galimybės: paieškos atvaizdavimas, saugojimas, spausdinimas.3.5.4. Privalo būti reglamentuotų periodinių ataskaitų automatinis generavimas.3.5.5. Privalo būti vienkartinių statistikos ataskaitų generavimas pagal sistemos duomenis.3.5.6. Privalo būti galimybė atspausdinti sugeneruotas ataskaitas.

9. Papildomi BPC informacinės sistemos funkciniai parametrai

4

4.1. Bendrieji Sistemos funkciniai reikalavimai4.1.1. Sistemą privalo sudaryti integrali techninė ir programinė įranga. Sistema privalo turėti serverinę dalį ir vartotojo dalį – kompiuterizuotas darbo vietas.4.1.2. Sistemos kompiuterizuotos darbo vietos privalo būti universalios, t. y. skirtos atsakyti į pagalbos skambučius, įvertinti pagalbos prašymus, kurti pranešimus apie pagalbos poreikį, aliarmuoti PT pajėgų vienetus, PT pajėgų vienetų pajėgoms operatyviai valdyti.4.1.3. Sistemos pajėgumas – vienu metu aktyvių stacionarių kompiuterizuotų darbo vietų skaičius – ne mažiau nei 200. Toks vienu metu aktyvių stacionarių kompiuterizuotų darbo vietų skaičius neturi neigiamai įtakoti reikalaujamo sistemos patikimumo ir veikimo greičio.4.1.4. Sistemos patikimumo lygis privalo būti – 99,999 procentų.4.1.5. Sistema privalo veikti JAVA technologijų bazėje arba jai lygiavertėje.4.1.6. Sistema privalo būti COTS tipo (angl. Commercial off-the-Shelf).4.1.7. Siūloma programinė įranga turi būti nepriklausoma nuo duomenų bazių valdymo sistemų, t.y. turi veikti su bet kokiomis DBVS (pvz. Oracle,  SQL ir kt.).4.1.8. Siūloma programinė įranga privalo būti nepriklausoma nuo telefoninių stočių (PBX) gamintojų platformų t.y. privalo veikti su bet kokio gamintojo telefoninių stočių programine ranga.4.1.9. Sistema privalo palaikyti prisijungimą ir darbą kompiuterizuotoje darbo vietoje tiek per Internetą (per WEB http arba https protokolais), tiek per intranetą (IP protokolu).4.1.10. Grafinė vartotojo sąsaja privalo būti išbaigta vieningu nepriklausomu atskiru sluoksniu JAVA technologijų bazėje arba jai lygiavertėje.4.1.11. Sistema privalo turėti įrankius, leidžiančius keisti bet kurį Sistemos grafinės vartotojo sąsajos elementą be jokio programinio kodo keitimo ar papildomo programavimo.4.1.12. Sistema privalo veikti ir kaip atskiras centralizuotas vienetas (centras) ir kaip kelių centrų sistema (naudojanti bendrą duomenų bazę).4.1.13. Sistema privalo būti lengvai integruojama su pagalbos tarnybų naudojamomis informacinėmis sistemomis.4.1.14. Sistema privalo gebėti priimti skambinančiojo koordinates ir parodyti vietą žemėlapyje, tiek fiksuotojo, tiek NMT-450, GSM-900/1800, UMTS ryšio naudojimo atveju.4.1.15. Sistema privalo gebėti priimti pagalbos prašymus ir nusiųsti pranešimus apie pagalbos suteikimą SMS ir MMS žinutėmis GSM/UMTS ryšio tinklais.4.1.16. Sistema privalo būti paprastai plečiama ar modifikuojama (tobulinama), pridedant atitinkamas programinės įrangos posistemes.4.1.17. Sistema privalo užtikrinti paprastą įvykio šalinimo priemonių konfigūravimą (laisvai nustatomi įvykio šalinimo kriterijai).4.1.18. Sistema privalo užtikrinti kompiuterio ir telefoninės įrangos integracijos funkcijas:4.1.18.1. automatinį pranešimo apie pagalbos poreikį kortelės laukų užpildymą skambinančiojo telefono numeriu, vietos nustatymo duomenimis (adresas arba koordinatės X, Y, R)), prireikus ir kitais DB duomenimis;4.1.18.2. adreso informacijos nustatymą ir užpildymą į pranešimo apie pagalbos poreikį kortelę pagal skambinančiojo telefono numerį;4.1.18.3. Sistema privalo gebėti gauti ir (ar) užklausti ir gauti duomenis iš išorinės GSM/UMTS skambučių koordinates transliuojančios sistemos.4.1.19. Sistema privalo turėti funkciją, leidžiančią BPC operatoriui prie pranešimo apie pagalbos poreikį informacijos prijungti papildomą informaciją iš BPC DB, Sistema automatiškai turi siūlyti kokią informaciją prijungti.4.1.20. Sistema pagal įvykio tipą privalo automatiškai pateikti skambinančiojo konsultavimui (patarimų teikimui) telefonu iki į įvykio vietą atvyks pagalbos tarnybos reikalingą pagalbos BPC operatoriui vadovą (instrukciją).4.1.21. Sistemoje privalo būti galimybė fiksuoti pirminę minimalią įvykio informaciją ir nedelsiant perduoti pirminį pranešimą apie pagalbos poreikį į PT IS.4.1.22. Sistema privalo automatiškai pateikti pirminę BPC operatoriaus surinktą informaciją į atitinkamą PT tais atvejais, kai skambinantysis yra sujungiamas konferenciniu ryšiu su atitinkama PT.4.1.23. Sistema privalo perduoti pranešimus apie pagalbos poreikį ir aliarmo signalą PT pajėgų vienetams naudojantis šiomis priemonėmis:4.1.23.1. judriuoju skaitmeniniu radijo ryšiu (TETRA);4.1.23.2. telefoninėmis linijomis.

5

4.1.25. Sistema privalo užtikrinti, kad BPC operatoriai ir PT dispečeriai galėtų stebėti ir valdyti šiuos PT pajėgų vienetų statusus:4.1.25.1. pasiekiamas radijo ryšiu;4.1.25.2. pasiekiamas stotyje;4.1.25.3. kelyje;4.1.25.4. įvykio vietoje;4.1.25.5. nepasiekiamas;4.1.25.6. kitus, esant poreikiui Sistemos administratoriaus lygiu sukurtus PT pajėgų vienetų statusus.4.1.26. Skirtingi PT pajėgų vienetų statusai turi būti automatiškai žymimi ir pavaizduojami skirtingomis spalvomis .4.1.27. Sistema privalo turėti telefonų numerių juodojo sąrašo (angl. black list) sudarymo ir valdymo funkcijas.4.1.28. Sistema privalo užtikrinti įvairių išorinių informacijos šaltinių pavaizdavimą (patalpų planai ir kt.) ir pateikimą monitoriuje.4.1.29. Sistema privalo palaikyti šiuos išorinius informacijos šaltinių formatus:4.1.29.1. Interneto/Intraneto nuorodas;4.1.29.2. MS Word, MS Excel, PDF formatų failus;4.1.29.3. išorines taikomąsias programas (statistinių ataskaitų ir pan.);4.1.29.4. paveikslų formatus (jpg, tiff ir pan.).4.1.30. Sistema privalo užtikrinti informacijos paiešką išoriniuose šaltiniuose:4.1.30.1. raktinių žodžių paiešką;4.1.30.2. teksto fragmento paiešką;4.1.30.3. katalogizuotą paiešką;4.1.30.4. geografinę paiešką.4.1.31. Sistema privalo užtikrinti, kad kiekvienam šaltiniui galima sukurti dažnai užduodamų klausimų sąrašą.4.1.32. Sistema privalo automatizuotai atlikti ataskaitas iš joje esančių duomenų MS Word, MS Excel, XML formatais.4.1.33. Sistema privalo turėti spausdinamų ataskaitų formų generatorių.4.1.34. Sistema privalo turėti integruotą aliarmavimo pranešimų (siunčiamų į nutolusius spausdintuvus, SMS žinutėmis ar skaitmeninio radijo ryšio priemonėmis) formų generatorių.4.2. Reikalavimai Sistemos GIS funkcionalumui4.2.1. Sistemos GIS privalo palaikyti tiek rastrinius, tiek vektorinius duomenis.4.2.2. Privalo būti laisvai išjungiami ir įjungiami vektoriniai sluoksniai.4.2.3. Informacija iš duomenų bazių privalo būti rodoma žemėlapyje kaip papildomas sluoksnis.4.2.4. Privalo būti palaikomas 3D vaizdas.4.2.5. Privalo būti užtikrintas automatizuotas ESRI shapefile (*.shp) formato duomenų atvaizdavimas skaitmeniniame žemėlapyje.4.2.6. Privalo būti palaikomi šie skaitmeninių žemėlapių formatai:4.2.6.1. SID (angl. Multiresolution Seamless Image Database);4.2.6.2. TIFF (angl. Tagged Image File);4.2.6.3. BMP (angl. Windows Bitmap Image);4.2.6.4. JPEG (angl. Joint Photographic Experts Group).4.2.7. Privalo būti užtikrintas paprastas naujų vektorinių sluoksnių arba atnaujintų kaip rastrinių, taip ir vektorinių sluoksnių papildymas.4.3. Reikalavimai Sistemos telefonijos funkcionalumui4.3.1. Sistema privalo kaupti ir pateikti pagrindinę statistinę informaciją apie skambučius:4.3.1.1. detalus skambučio duomenų įrašas (angl. Call Detailed Record, CDR);4.3.1.2. registruotų skambučių skaičius;4.3.1.3. priimtų skambučių skaičius ir kiekvieno jų laukimo iki atsiliepimo laikas;4.3.1.4. prarastų (nutrauktų iki atsiliepimo) skambučių skaičius;4.3.1.5. ilgiausia laiko trukmė (sek.) iki atsiliepimo (eilėje);4.3.1.6. vidutiniė laiko trukmė(sek.) iki atsiliepimo;4.3.1.7. ilgiausia laiko trukmė (sek.) iki nesulaukimo atsiliepiant;4.3.1.8. vidutinė laiko trukmė (sek.) iki nesulaukimo atsiliepiant;

6

4.3.1.9. ilgiausia pokalbio trukmė (sek.) ;4.3.1.10. vidutinė pokalbio trukmė (sek.);4.3.1.11. skambučių, nutrauktų BPC operatoriaus iniciatyva, skaičius;4.3.1.12. statistikos pateikimas pjūviais pagal BPC operatorių (vartotojo vardą).4.3.2. Sistema privalo užtikrinti, kad prireikus (kai visi operatoriai užimti arba pagal tam tikrus požymius (pvz., telefono numerį)) skambinančiajam būtų transliuojamas iš anksto įrašytas balso pranešimas (ne mažiau 4 skirtingų pranešimų).4.3.3. Sistema privalo užtikrinti, kad BPC operatoriai kompiuterizuotoje darbo vietoje galėtų laikinai blokuoti įeinančius skambučius pagal pasirinktą telefono numerį ar kitus požymius. Blokavimas turi automatiškai išsijungti po nustatyto laiko.4.3.4. Sistemoje privalo būti galimybė BPC operatoriui, vieno mygtuko paspaudimu, laikinai išsiregistruoti (prisiregistruoti) prie sistemos.4.4. Reikalavimai Sistemos radijo ryšio funkcionalumui4.4.1. Sistema privalo turėti integruotą skaitmeninio radijo ryšio „TETRA“ funkcionalumą arba būti integruota su naudojama PT skaitmeninio radijo ryšio sistema.4.4.2. Naudojant skaitmeninį radijo ryšį Sistema privalo:4.4.2.1. leisti operatyviai sudaryti laikinas (dinamines) PT pajėgų vienetų grupes, priskirtas įvykiui;4.4.2.2. turėti kontrolės priemones, leidžiančias automatiškai perjunti PT pajėgų vienetų grupes į kalbėjimo (klausymo) režimą.4.4.3. Sistemoje privalo būti užtikrinamas abipusis skaitmeninės informacijos perdavimo kanalas.4.4.4. Sistemoje privalo būti funkcija, leidžianti perduoti informaciją PT pajėgų vienetams radijo ryšiu trumpųjų žinučių pagalba.4.4.5. Bendravimas tarp BPC operatorių, PT dispečerių ir PT pajėgų vienetų Sistemoje privalo vykti radijo ryšio pagalba saugiu skaitmeniniu kanalu.4.4.6. Sistema privalo perduoti PT pajėgų vienetų buvimo vietos koordinates pagal palydovų informaciją (GPS).4.4.7. Sistema privalo turėti galimybę žymėti (keisti) PT pajėgų vienetų statusus radijo ryšiu trumpųjų žinučių pagalba.4.5. Reikalavimai Sistemos statistinės informacijos pateikimo funkcionalumui4.5.1. Funkciniai statistinių duomenų apdorojimo ir pateikimo reikalavimai:4.5.1.1. paskutiniu metu sukurtų (pvz.: šios dienos) dokumentų rodymas nenaudojant papildomos paieškos;4.5.1.2. nebaigtų apdoroti dokumentų (pranešimų apie pagalbos poreikį kortelių) sąrašo pateikimas nenaudojant papildomos paieškos;4.5.1.3. informacijos paieška ne tik Sistemos DB sukauptose elektroninėse įvykių kortelėse, bet ir su tuo įvykiu susijusiose telefoninių skambučių registravimo ir kaupimo ir balso įrašymo sistemose;4.5.1.4. galimybė išsaugoti paieškos užklausą ir rezultatus unikaliu identifikatoriumi ir vėliau pakartotinai panaudoti;4.5.1.5. Sistema privalo kaupti ir pateikti pagrindinę statistinę informaciją apie skambučius.4.5.2. Statistinių duomenų atrinkimas:4.5.2.1. Sistemoje duomenų atrinkimas privalo būti automatizuotas ir vykdomas vieno mygtuko paspaudimu;4.5.2.2. skambučių atrinkimas pagal eigos būklę: naujai priimtas skambutis, perduotas vykdymui, užbaigtas, reikalauja papildomo tyrimo;4.5.2.3. skambučių atrinkimas pagal juos priėmusius operatorius, instituciją, kuriai buvo perduotas skambutis, reagavimo laiką, priėmimo laiką ir kitus reikiamus požymius;4.5.2.4. privalo būti išplėstos spausdinamos informacijos galimybes, t.y. ne tik pranešimo apie pagalbos poreikį ataskaitos kortelės, bet ir paros ir pamainos statistinių duomenų ataskaitų bei pagal pareikalavimą sugeneruotų ataskaitų tiesiogiai iš BPC skambučių priėmimo ir tvarkymo sistemos.4.5.3. Ataskaitų pateikimo periodiškumas:4.5.3.1. statistika privalo būti pateikiama nustatytam laikotarpui. Statistinių skaičiavimų atlikimo pradžios ir pabaigos data ir laikas {yyyy-mm-dd, hh:mm:ss};4.5.3.2. statistika privalo būti pateikiama kiekvienai nustatyto laikotarpio tenkančių dienų valandai (nuo 0 val. iki 1 val., nuo 1 val. iki 2 val., .. nuo 22 val. iki 23 val., nuo 23 val. iki 24 val.), sumuojant visų tenkančių dienų atitinkamų valandų (24-rių kasvalandinių intervalų) reikšmes. Ataskaitoje privalo būti pateikiamos ne tik susumuotos nustatytus kriterijus atitinkančios skaičių reikšmės, bet ir išvesti vidurkiai parai ir atitinkamai visiems 24-riems kasvalandiniams intervalams. Vienos ar kelių savaitės dienų

7

parinkimas (išskyrimas) {pirmadienis..sekmadienis} nustatytame laikotarpyje;4.5.3.3. kartu su statistika privalo būti pateikiamas, nustatytus kriterijus atitinkantis, įvykių sąrašas bei galimybė peržiūrėti iš šio sąrašo pasirinktą bet kokį įvykį bei visą su juo susijusią informaciją (įskaitant ir telefoninių pokalbių įrašus);4.5.3.4. kintančių kriterijų sąrašas pasipildyti privalo automatiškai (į sistemą įvedus naujus PT pajėgų vienetus, tarnybas ar zonas, įvykių tipus, adresus ir pan. ir t. t. – statistiniame modulyje ši informacija turi atsinaujinti automatiškai).4.6. Reikalavimai Sistemos PT pajėgų vienetų aliarmavimo funkcionalumui4.6.1. Sistema privalo užtikrinti, kad BPC operatoriai, naudojantis savo kompiuterinių darbo vietų vartotojo įrankiais, galėtų aliarmuoti atitinkamus PT pajėgų vienetus, esančius padaliniuose (pvz., ugniagesių-gelbėtojų komandose), ir išsiųsti į PT padalinius, kuriose yra dislokuojami pajėgų vienetai, pranešimą apie pagalbos poreikį bei gauti į sistemą patvirtinimą, kad pajėgų vienetai aliarmuoti ir pranešimas gautas arba, kad pranešimas negali būti perduotas dėl klaidos.4.6.2. Pranešimą apie pagalbos poreikį privalo sudaryti ši informacija:4.6.2.1. įvykio numeris;4.6.2.2. turintys reaguoti PT pajėgų vienetai;4.6.2.3. įvykio tipas (išvykimo pobūdis);4.6.2.4. įvykio vieta (adresas, kur įvyko įvykis);4.6.2.5. įvykio aplinkybės (pastabos laukas ir klausimynų informacija);4.6.2.6. turimi pranešusiojo asmens duomenys (vardas, pavardė, adresas);4.6.2.7. pranešusiojo asmens telefono numeris;4.6.2.8. pranešimo apie pagalbos poreikį laikas;4.6.2.9. žemėlapio, kuriame vaizduojama įvykio vieta, fragmentas.4.6.3. Sistema privalo aliarmuoti tik reagavimui į šį pranešimą apie pagalbos poreikį priskirtus tam tikros vienos ar kelių PT pajėgų vienetus.4.6.4. Sistema privalo leisti administratoriui laisvai priskirti PT pajėgų vienetus, kuriems turi būti siunčiami pranešimai apie pagalbos poreikį.4.6.5. Pranešimas apie pagalbos poreikį atitinkamiems PT pajėgų vienetams privalo būti išsiunčiamas automatiškai ir iš karto po to, kai Sistemoje pakeičiamas reaguojančių pajėgų užimtumo statusas iš bet kokio į „Pažymėti aliarmuotu“.4.6.6. Jeigu į įvykį reaguoja keli vienos PT pajėgų vienetai, tai pranešimas apie pagalbos poreikį privalo būti siunčiamas iš karto po to, kai Sistemoje esančių visų vienoje dislokacijos vietoje esančių reaguojančių pajėgų vienetų užimtumo statusas bus pakeistas į „Pažymėti aliarmuotu“.4.6.7. Pranešimo apie pagalbos poreikį siuntimas iš Sistemos privalo būti atliekamas naudojant (ne mažiau) kompiuterinį tinklą, skaitmeninį radijo ryšį ir (arba) komutuojamas telefonines ISDN linijas.4.6.8. Pranešimas apie pagalbos poreikį, po statuso pakeitimo į „Pažymėti aliarmuotu“, į PT privalo būti nusiųstas ir atvaizduotas PT darbo vietos ekrane ne vėliau kaip per 5 sekundes, naudojant kompiuterinį tinklą ir (arba) skaitmeninį radijo ryšį, ir ne vėliau kaip per 30 sekundžių, naudojant komutuojamas telefonines ISDN linijas.4.6.9. Gavus pranešimą apie pagalbos poreikį PT darbo vietoje, Sistema privalo aktyvuoti garsinį signalą, perspėjantį apie pranešimo gavimą ir, panaudojant atitinkamas garso įrašų bylas, paeiliui praneši kokie konkretūs PT pajėgų vienetai turi reaguoti (išvykti). Darbo vietos ekrane privalo būti pavaizduojama visa informacija įeinanti į pranešimą apie pagalbos poreikį.4.7. Reikalavimai Sistemos skambinančiųjų vietos nustatymo duomenų ir eCall skabučių priėmimo ir pateikimo funkcionalumui

4.7.1. Sistema priima, apdoroja, saugo ir grafiškai pavaizduoja darbo vietoje mobiliojo ryšio operatorių BPC teikiamus vietos nustatymo duomenis pagal reikalavimus nustatytus šios techninės-funkcinės specifikacijos 1 priede.PASTABA. Mobiliojo ryšio operatoriai vietos nustatymo duomenis BPC teikia pagal BPC parengtą ir jiems pateiktą Viešųjų judriojo telefono ryšio abonentų ir (ar) paslaugų gavėjų, skambinančių bendruoju pagalbos telefono numeriu 112, vietos nustatymo duomenų teikimo Bendrajam pagalbos centrui detalių techninių reikalavimų aprašą (šios techninės-funkcinės specifikacijos 2 priedas).4.7.2. Sistema privalo priimti ir apdoroti eCall skambučius, jei iki sutarties su tiekėju vykdymo pabaigos bus patvirtintas bendras Europos eCall techninis standartas.4.7.3. Sistemos DB vietos nustatymo duomenys privalo būti saugomi ne mažiau nei 6 mėnesius.

8

4.8. Reikalavimai Sistemos balso įrašymo įrangos funkcionalumui4.8.1. Bendrieji pokalbių įrašymo įrenginio fiziniai reikalavimai.4.8.1.1. Pokalbių įrašymo įrenginio maitinimo įtampa: 220 V ±10%, 50 Hz dažnis;4.8.1.2. Pokalbių įrašymo įrenginys turi būti dubliuotas, t.y. sugedus vienam įrenginiui pokalbių įrašymo funkcionalumas negali sutrikti, be to negali būti prarasti anksčiau įrašyti pokalbiai;4.8.1.3. Pokalbių įrašymo įrenginys turi būti montuojamas į 19‘‘ spintą;4.8.1.4. Pokalbių įrašymo įrenginys turi turėti atskirą aušinimo modulį, apsaugotą dulkių filtru;4.8.1.5. Pokalbių įrašymo įrenginys turi turėti galimybę naudoti daugiau kaip vieną aušinimo modulį su „karšto keitimo“ savybe;4.8.1.6. Darbinės temperatūros diapazonas :nuo +5oC iki + 40oC;4.8.1.7. Leistinas darbinės aplinkos drėgnumas: nuo 20% iki 80%;4.8.1.8. Pokalbių įrašymo įrenginio saugumo klasė turi atitikti EN 60529 standarto IP51 lygį;4.8.1.9. Pokalbių įrašymo įrenginio saugumo klasė turi atitikti EN 60950 standarto reikalavimus;4.8.1.10. Pokalbių įrašymo įrenginys turi turėti nepertraukiamo maitinimo šaltinį. Dingus maitinimo įtampai pokalbių įrašymo įrenginio funkcionalumas turi būti užtikrinamas ne mažiau kaip 1 valandą;4.8.1.11. Pokalbių įrašymo įrenginio nepertraukiamo maitinimo šaltinis turi būti montuojamas į 19“ komunikacijos spintą;4.8.1.12. Po maitinimo įtampos dingimo pokalbių įrašymo įrenginys turi automatiškai įsijungti (be techninio darbuotojo įsikišimo);4.8.1.13. Pokalbių įrašymo įrenginys po maitinimo įtampos įjungimo turi pasirengti darbui (įrašymui) ne vėliau kaip per 50 sek;4.8.1.14. Vidutinis darbo laikas tarp gedimų (MTBF - Mean Time Between Failure) daugiau nei 20000 val.;4.8.1.15. Vidutinė pataisymo trukmė (MTTR – Mean Time To Repair) greičiau nei 30 min.;4.8.1.16. Pageidautina, kad įrašymo įrenginyje būtų naudojama specializuota operacijų sistema, maksimaliai apsaugota nuo kompiuterinių virusų pažeidimo;4.8.1.17. Užsakovo, pokalbių įrašymo sistemos administratoriams įrangos gamintojas turi suteikti teisę visiškai administruoti pokalbių įrašymo sistemos aparatinę ir programinę dalis.4.8.1.18. Pokalbių įrašymo įrenginys turi būti montuojamas į 19“ komunikacijos spintą;4.8.1.19. Pokalbių įrašymo įrenginys turi turėti rakinamą apsaugą nuo nesankcionuoto fizinio poveikio.4.8.2. Bendrieji pokalbių įrašymo įrenginio funkciniai reikalavimai.4.8.2.1. Pokalbių įrašymo įrenginys turi turėti realaus laiko įrašomų linijų būsenos (pvz. aktyvi, neveikianti ir pan.) stebėjimo (monitoringo) funkciją;4.8.2.2. Turi būti galimybė stebėti visų pokalbio įrašymo įrenginio įrašomų linijų būsenas viename monitoriaus lange;4.8.2.3. Turi būti galimybė stebėti nurodytas linijas be jų įrašymo;4.8.2.5. Pokalbių įrašymo įrenginys turi turėti automatinę įspėjimų organizavimo funkciją, esant fiziniams įrašomų linijų parametrų pokyčiams. Turi būti galimybė įspėjimus apie pokyčius siųsti E-mail, SMS, telefono linija;4.8.2.6. Pokalbių įrašymo įrenginys turi nustatyti įeinančių, išeinančių ir vidinių pokalbių abonentų numerius;4.8.2.7. Pokalbio įrašymas į pokalbių įrašymo įrenginį turi būti pradėtas vykdyti ne vėliau kaip ir pokalbio pradžia;4.8.2.8. Pokalbio įrašymas niekaip neturi įtakoti paties pokalbio kokybės;4.8.2.9. Pokalbių įrašymo įrenginys turi būti apsaugotas nuo bet kokios galimybės ištrinti įrašytą pokalbį;4.8.2.10. Pokalbių saugojimo trukmė pokalbių įrašymo įrenginyje iki duomenų perrašymo į centrinę duomenų saugyklą - ne trumpiau kaip 12 mėn.;

9

4.8.2.11. Pokalbių įrašymo įrenginys turi automatiškai pervesti vidinio laikrodžio laiką į žiemos ir vasaros laiką bei sinchronizuoti laiką su išoriniu laiko serveriu;4.8.2.12. Pirminių duomenų įrašų kodavimas turi būti vykdomas iš karto, saugiu gamintojo protokolu;4.8.2.13. Pokalbių įrašymo įrenginys turi naudoti nefragmentuotą (tolygų, vientisą) duomenų įrašymo būdą;4.8.2.14. Vienalaikis lokalios veidrodinės duomenų kopijos organizavimas įrašymo įrenginyje (RAID1, mirroring);4.8.2.15. Turi būti galimybė automatiškai kopijuoti duomenis į išorinius įrenginius (pvz. DVD RW);4.8.2.16. Pokalbių įrašymo įrenginys turi palaikyti vienalaikio (realaus laiko) pokalbių įrašymo dubliavimo, į išorinę nuotolinę duomenų bazę, funkciją;4.8.2.17 Pokalbių įrašymo įrenginys, turi palaikyti šiuos garso suspaudimo algoritmus: G.711 64 kbit/s (A-law; μ-law), ADPCM 64, 32, 16 ir 12 kbit, GSM FR 13 kbit;4.8.2.18 Pokalbių įrašymo įrenginys, turi turėti galimybę įrašyti VoIP pokalbius;4.8.2.19 Pokalbių įrašymo įrenginys turi turėti galimybę įrašyti kompiuterio ekrano vaizdą;4.8.2.20 Pokalbių įrašymo įrenginys turi turėti galimybę susieti įrašomo kompiuterio ekrano vaizdą su įrašomu pokalbiu;4.8.2.21 Pokalbių įrašymo įrenginys turi turėti galimybę įrašyti kompiuterio ekrano vaizdą tik telefoninio pokalbio metu;4.8.2.22 Pokalbių įrašymo įrenginys turi turėti galimybę įrašinėti kompiuterio ekrano vaizdą pagal specifinius (laiko, datos) reikalavimus;4.8.2.23 Pokalbių įrašymo įrenginys turi turėti galimybę vykdyti pastovų kompiuterių ekranų vaizdų įrašymą;4.8.2.24 Kompiuterių ekranų vaizdo saugojimo trukmė, pokalbių įrašymo įrenginyje iki duomenų perrašymo, turi būti ne mažesnė nei 1 mėn.;4.8.2.25 Telefoninių pokalbių saugojimo trukmė turi būti ne mažesnė kaip 6 mėn.4.8.2.26 Įrašymo įrenginio administravimas turi būti identiškas nepriklausomai kokią prieigą naudoja aptarnaujantis personalas.4.8.2.27 Turi būti sudarytos galimybės aptarnaujančiam personalui prie pokalbių įrašymo įrenginio prisijungti per šias prieigas:

Tiesioginis prisijungimas (klaviatūros ir pelės pagalba); Nuotolinis prisijungimas per vietinį kompiuterių tinklą; Nuotolinis prisijungimas per modemą;

4.8.3. Bendrieji pokalbių įrašymo įrenginių objektuose technologiniai reikalavimai.4.8.3.1. Pokalbių įrašymo įrenginys turi turėti galimybę įrašinėti informaciją iš žemiau išvardintų sąsajų panaudojant atitinkamus modulius:

analoginių telefoninių sąsajų; analoginių audio sąsajų (pvz. radijo stotys, diskusinės sistemos ,audio mikšeriai, garso

stiprintuvai ir t.t.); ISDN BRI sąsajų; ISDN PRI sąsajų su signalizacija Q-SIG, DSS1, SS7; Skaitmeninių teikiamos telefonų stotelės telefoninių sąsajų; Vidinių Up0 ir S0 sąsajų (nenaudojant analoginių keitiklių); VoIP sąsajų (Ericsson MD-110, Ericsson Business Phone 250, Cisco Call Manager,

Siemens HiPath, Avaya Definity ir kt.4.8.3.2. Visų sąsajų tipai turi būti įrašomi vienu pokalbių įrašymo įrenginiu;4.8.3.3. Pokalbių įrašymo sistema turi turėti galimybę įrašyti visų sąsajų duomenis vienu metu;4.8.3.4. Įrašomų skaitmeninių ir analoginių linijų dažnių juostos plotis 3dB lygyje ne mažesnis kaip: 300 – 3450 Hz;4.8.3.5. Turi būti galimybė filtruoti įrašomų linijų nepageidaujamus trukdžius;

10

4.8.3.6. Įrašomo signalo aptikimo slenksčio reguliavimo diapazonas ne mažesnis kaip: 0 – -54 dBm;4.8.3.7. Įrašymo įrenginys privalo užtikrinti visų telekomunikacijų operatorių dubliuotų telefoninių ISDN PRI srautų bei vidinio tinklo ISDN PRI srautų įrašymą;4.8.3.8. Pageidautina galimybė įrašyti visą skaitmeninę signalizaciją;4.8.3.9. Turi būti galimybė nustatyti signalo įrašymo pradžios ir pabaigos kriterijus kiekvienai linijai atskirai;4.8.3.10. Signalų įrašymas pradedamas ir baigiamas remiantis šiais kriterijais:

Pagal signalizacijos pranešimus; Pastovus ilgalaikis (nenutrūkstantis) signalų įrašymas; TRS tonus; Rankiniu būdu; Išorinės aplikacijos nurodymu per kompiuterinę-telefoninę integraciją (CTI); Sinchroniškai pagal kitą sąsają;

4.8.4. Reikalavimai pokalbių įrašymo sistemos valdymui4.8.4.1. Pokalbių įrašymo valdymo sistema sudaryta iš valdymo posistemės ir pokalbių įrašų archyvavimo posistemės, kurios turi veikti atskiruose fiziniuose serveriuose;4.8.4.2. Pokalbių įrašymo sistemos valdymo serveriai turi būti montuojami į 19“ komunikacijos spintą;4.8.4.3. Pokalbių įrašymo sistemos valdymo serverių saugumo klasė turi atitikti EN 60950 standarto reikalavimus;4.8.4.4. Pokalbių įrašymo sistemos valdymo serveriai turi atitikti elektromagnetinio suderinamumo reikalavimus:

EN 55022 A klasė; EN 55024; EN61000-3-2 / -3;

4.8.4.5. Pokalbių įrašymo sistemos valdymo serveriai turi būti aprūpinti dviem nepriklausomais „karšto keitimo“ maitinimo blokais. Sugedus vienam maitinimo blokui, rezervinis turi įsijungti automatiškai, nenutrūkstant pokalbių įrašymo sistemos valdymo serverio funkcionalumui.4.8.4.6. Pokalbių įrašymo sistemos valdymo serveriai turi turėti garantuotą nepertraukiamo maitinimo šaltinį. Dingus maitinimo įtampai pokalbių įrašymo įrenginio funkcionalumas turi būti užtikrinamas ne mažiau kaip 15 minučių.4.8.4.7. Pokalbių įrašymo valdymo sistema (programinė įranga) turi veikti Windows 2000,Windows XP operacinės sistemos terpėje;4.8.4.8. Pokalbių įrašymo valdymo sistema turi būti sukonfigūruota aptarnauti ir valdyti ne mažiau kaip 15 pokalbių įrašymo įrenginių;4.8.4.9. Pokalbių įrašymo valdymo sistemos valdymas atliekamas per grafinę vartotojo sąsają, pelės ir klaviatūros pagalba;4.8.4.10. Pokalbių įrašymo valdymo sistemoje turi veikti vartotojų teisių išdavimo sistema;4.8.4.11. Vartotojų prieigos kontrolei turi būti parengtos šabloninės sąskaitos (root, administrator, user ir pan.);4.8.4.12. Turi būti galimybė įrašytų pokalbių perklausymo kontrolę organizuoti per „Windows active directory“;4.8.4.13. Pokalbių įrašymo valdymo sistema turi fiksuoti visų prisijungusių vartotojų veiksmus ir rašyti juos į sistemos žurnalą;4.8.4.14. Pokalbių įrašymo valdymo sistema turi turėti galimybę eksportuoti vartotojų veiksmų įrašus į (pvz. MS Excel, MS Word) bylas tolesniam apdorojimui;4.8.4.15. Pokalbių įrašymo valdymo sistema turi centralizuotai sukaupti visų pokalbių įrašymo įrenginių įrašytus pokalbius;4.8.4.16. Pokalbių įrašymo valdymo sistema turi replikuoti įrašą vykstančio pokalbio metu;4.8.4.17. Pokalbių įrašymo valdymo sistema ir ją aptarnaujantis serveris turi užtikrinti įrašyto

11

pokalbio išsaugojimą (ir esant reikalui momentinį pasiekiamumą) ne trumpesniu kaip 3 (trijų) metų laikotarpiu;4.8.4.18. Pokalbių įrašymo valdymo sistema turi leisti klausytis realiu laiku vykstančių pokalbių iš nutolusių darbo vietų;4.8.4.19. Pokalbių įrašymo valdymo sistema turi turėti galimybę pagal vartotojo teises išsaugoti norimus pokalbius WAV, WMF, MP3 formatais;4.8.4.20. Pokalbių įrašymo valdymo sistema turi turėti galimybę pagal vartotojo teises išsiųsti pokalbius el. paštu;4.8.4.21. Informacijos paieška ir/ar filtravimas turi būti atliekamas pagal bet kurį įrašo lauką (data, laikas, linijos numeris, tel. numeris, ir t.t.);4.8.4.22. Turi būti numatyta galimybė papildyti duomenų bazės įrašus naujais laukais;4.8.4.23. Turi būti numatyta galimybė perkelti įrašų duomenis (pvz. A numeris, pokalbio pradžios laikas, pokalbio trukmė ir t.t.) į MS Excel, MS Word ar kitas bylas tolesniam apdorojimui;4.8.4.24. Pokalbių įrašymo valdymo sistema turi turėti galimybę vykdyti centrinio archyvavimo funkciją;4.8.4.25. Pokalbių įrašymo valdymo sistema turi leisti stebėti visų aptarnaujamų įrašymo įrenginių linijų būseną;4.8.4.26. Pokalbių įrašymo valdymo sistema turi atlikti pokalbių įrašymo įrenginių ir pokalbių įrašymo valdymo sistemos laikrodžių sinchronizavimą su NTP serveriu (RFC1305);4.8.4.27. Būtinas pokalbių įrašymo valdymo sistemos veiklos dubliavimas, kita, lygiagrečiai veikiančia valdymo ir archyvavimo sistema, fiziškai įdiegta kitame objekte. Techniniai reikalavimai dubliuojančiai pokalbių įrašymo valdymo bei archyvavimo sistemai turi būti identiški pagrindinei pokalbių įrašymo valdymo bei archyvavimo sistemai.4.8.4.28. Vartotojams turi būti sudarytos galimybės prie pokalbių įrašymo valdymo sistemos prisijungti per šias prieigas:

Tiesioginis prisijungimas (klaviatūros ir pelės pagalba); Nuotolinis prisijungimas per vietinį kompiuterių tinklą (ne mažiau kaip 12 vartotojų); Nuotolinis prisijungimas HTTP protokolu; Nuotolinis prisijungimas per modemą;

4.8.5. Reikalavimai pokalbių įrašymo įrenginio plečiamumui.4.8.5.1. Turi būti galimybė vieno pokalbių įrašymo įrenginio įrašomų ir/ar stebimų analoginių ir/ar skaitmeninių kanalų skaičių išplėsti iki 96 vnt.4.8.5.2. Vienas pokalbių įrašymo įrenginys turi turėti galimybę įrašinėti ne mažiau 30 kompiuterio ekranų vienu metu;4.8.5.3. Kiekvienas pokalbių įrašymo įrenginys turi turėti galimybę įdiegti Ethernet sąsają, skirtą VoIP pokalbių įrašymui;4.8.5.4. Vieno pokalbių įrašymo įrenginio įrašomų IP kanalų skaičius turi būti ne mažesnis kaip 250 vnt.

10. BPC informacinės sistemos techniniai reikalavimai

5.1. Bendrieji reikalavimai5.1.1. Sistemos architektūra:5.1.1.1. Sistema privalo būti realizuota pagal trijų lygių* programų architektūros modelį;5.1.1.2. Grafinė naudotojo sąsaja bei joje esantys valdymo elementai privalo būti kiek galima labiau vienodi bei unifikuoti visoje sistemoje†;5.1.1.3. Visos sistemos dalys privalo būti tarpusavyje integruotos. Visi informacijos pasikeitimai vienoje dalyje privalo atsispindėti susijusiose dalyse be papildomų sistemos naudotojų veiksmų (klasifikatorių ar

* Išskiriami šie lygmenys: vaizdavimo lygmuo, veiklos logikos lygmuo, duomenų lygmuo.† Tiekėjas gali siūlyti nevienodus valdymo elementus tokiu atveju, jei periodinių duomenų suvedimui arba analizei bus pasiūlytas atskiras sprendimas

12

kitų visose sistemos dalyse naudojamų duomenų apsikeitimai privalo vykti realiu laiku‡);5.1.1.4. Sistema privalo palaikyti ir būti suderinama su XML ir XML Web Services;5.1.1.5. Sistema privalo turėti užklausų vykdymo, ataskaitų kūrimo ir analizės įrankius;5.1.1.6. Sistema privalo turėti sistemos darbo našumo stebėjimo modulį, leidžiantį aptarnaujančiam personalui lanksčiai stebėti sistemos būseną bei gauti perspėjimo ar gedimo pranešimus;5.1.1.7. Sistema privalo turėti klaidų toleravimo, trikdžių ir apkrovų tvarkymo bei konfigūravimo įrankius.5.1.2. Duomenų bazių valdymo sistema:5.1.2.1. Duomenų ir informacijos apdorojimui ir saugojimui privalo būti naudojama DBVS. Ji turi pasižymėti aukštu našumo lygiu, pajėgumų plėtimo galimybėmis, patikimumu ir saugumu;5.1.2.2. DBVS privalo turėti pagalbinių ir administravimo priemonių rinkinį. Pagalbinių ir administravimo priemonių sąveikos su DBVS sąsaja turi būti realizuota grafinės naudotojo sąsajos ir komandinės eilutės būdu;5.1.2.3. DBVS privalo užtikrinti vidines duomenų vientisumo užtikrinimo funkcijas, turėti duomenų atstatymo mechanizmus po gedimų ir pažeidimų;5.1.2.4. DBVS privalo palaikyti daugiapakopį saugumo mechanizmą;5.1.2.5. DBVS privalo palaikyti leidimo ir ribojimo naudotis duomenimis lentelių, įrašų ir skilčių (laukų) lygyje, priemones;5.1.2.6. DBVS privalo importuoti duomenis XML formatu.5.1.3. Naudotojo grafinė sąsaja:5.1.3.1. Naudoto darbo vietoje privalo būti naudojama internetinė naršyklė ir (arba) naudotojo grafinė sąsaja. Sistemos naudotojai, dirbsiantys su sistema nutolusiu būdu, turi naudoti internetinę naršyklę;5.1.3.2. Reikalavimai prisijungimui bei darbui su sistema interneto naršyklės pagalba:- sistemoje privalo būti galimybė koduoti bendravimą tarp sistemos ir naudotojo kompiuterio SSL (angl. Secure Socket Layer) kodavimo priemonėmis arba kitomis lygiavertėmis kodavimo priemonėmis;- privalo būti suderinamumas su Microsoft Internet Explorer , Mozilla Firefox ir kitomis paplitusiomis interneto naršyklėmis;5.1.3.3. Naudotojo darbo vietoje sistema privalo būti suderinta su MS Office, Open Office programine įranga (pvz., sistemos suformuotas rinkmenas turi būti galima peržiūrėti tiek MS Office, tiek Open Office programine įranga, naudoti Clipboard funkcionalumą ekraninės formos ar ataskaitos turiniui perkelti tarp sistemos naudotojo darbo vietoje veikiančių programų, kurios palaiko Clipboard funkcionalumą);5.1.3.4. Žmogaus–sistemos sąveika privalo būti realizuota naudotojų grafinėmis sąsajomis. Sistemoje duomenų įvedimas–išvedimas, valdymo komandų priėmimas ir jų įvykdymo rezultatų atvaizdavimas privalo būti atliekamas interaktyviuoju režimu (sąlyginai realiame laike, pagal nustatytus greitaveikos reikalavimus, žr. reikalavimus „Sistemos greitaveika“). Naudotojų grafinės sąsajos privalo atitikti šiuolaikinius ergonomikos reikalavimus, nurodytus ISO 12207 standarte, ir užtikrinti patogų patekimą prie pagrindinių funkcijų ir operacijų, kurios vykdomos sistemoje;5.1.3.5. Naudotojų grafinės sąsajos privalo būti realizuotos taikant kompiuterio pelės navigavimo grafinėje sąsajoje įrenginius (angl. mouse pointing device);5.1.3.6. Sistema privalo palaikyti personalizuotas (pagal naudotoją bei naudotojo vaidmenį) darbo sritis. Naudotojo darbui nereikalingas funkcionalumas neturi būti matomas sukurtame meniu;5.1.3.7. Sistema privalo leisti administratoriui pradinių duomenų įvedimo ar peržiūros languose modifikuoti aplinką, (pavyzdžiui, pasirinkti, kurie laukai yra matomi, nustatyti laukų plotį, filtruoti duomenis atsižvelgiant į pasirinktą aplinką). Sistema privalo užtikrinti funkcionalumą, kad būtų galima išsaugoti pritaikytą aplinką visiems naudotojams;5.1.3.8. Sistema privalo turėti veikiančią kompiuterizuotos informacinės pagalbos suteikimo naudotojui funkciją (pvz., HTML help);5.1.3.9. Sistemoje privalo būti kontekstinė pagalba naudotojui.5.1.4. Bendrieji duomenų pateikimo ir apdorojimo principai:5.1.4.1. Sistemoje privalo būti apdorojami struktūrizuoti (pavyzdžiui, duomenų bazių lentelės), pusiau struktūrizuoti (pavyzdžiui, duomenų bazėse išsaugoti XML dokumentai) duomenys;5.1.4.2. Privalo būti galimybė dirbti su Sistema, kol vykdomi kiti darbai (pavyzdžiui, atliekamas duomenų importas, registravimai), vieno naudotojo veiksmai neblokuotų kito naudotojo veiksmų ir nedarytų įtakos sistemos greitaveikai (išlaikant sistemos greičio reikalavimus, apibrėžtus bendrųjų reikalavimų dalyje „Sistemos greitaveika“);

‡ Jei bus pasiūlytas atskiras nuo konsolidavimo IS analizės įrankis, tai jame duomenų atnaujinimas gali ir nevykti realiu laiku.

13

5.1.4.3. Duomenų tvarkymas privalo atitikti tarptautinį standartą ISO 15489-1:2001 bei Lietuvos Respublikos raštvedybos taisykles (skaitmenų formatas, datos ir laiko formatai);5.1.4.4. Sistemoje duomenys, prie kurių naudotojas neturi prieigos teisių, naudotojui neturi būti pateikiami (tiek ekraninėje formoje, tiek ataskaitų pavidalu);5.1.4.5. Sistemoje privalo būti galimybė įvesti ir importuoti neribotą duomenų eilučių skaičių;5.1.4.6. Sistemoje privalo būti importuojami ir eksportuojami duomenys XML ir kitais sistemos diegimo projekto reikalavimų analizės ir projektavimo metu suderintais formatais;5.1.4.7. Sistemoje įvesti, importuoti ar suformuoti duomenys privalo būti peržiūrimi įvairiais pjūviais. Sistemos administratorius turi pats pasirinkti, kokiais pjūviais nori peržiūrėti duomenis;5.1.4.8. Sistemos administratorius turi galėti duomenis tik įvesti (importuoti), jų neužregistruojant iš karto ir po to užregistruoti (patvirtinti) įvestus (importuotus) duomenis;5.1.4.9. Sistemoje įvesti (importuoti) administratoriaus duomenys privalo būti užregistruojami tik tada, kai užpildomi visi privalomi laukai;5.1.4.10. Sistema privalo duomenų rinkiniams (įrašams), duomenims automatiškai suteikti unikalų kodą ar numerį (pagal nustatytas taisykles). Sistemos administratorius privalo galėti keisti kodo ar numerio sudarymo taisykles pagal diegimo metu suderintas numerių sudarymo taisykles;5.1.4.11. Sistemos administratorius privalo galėti pildyti duomenis pasirinkęs reikšmes iš sudarytų sąrašų ir klasifikatorių;5.1.4.12. Sistemoje dalis duomenų privalo būti užpildomi automatiškai (pvz., duomenų pateikimo data);5.1.4.13. Sistemoje suminiai duomenys privalo būti detalizuojami iki juos sudarančių reikšmių, tiek ekraninėse formose, tiek ataskaitose (angl. Drill Down funkcija);5.1.4.14. Sistemoje privalo būti registruojamas duomenis pateikęs sistemos administratorius, duomenų pateikimo data ir laikas, duomenų šaltinis (pvz., jei duomenys importuoti, tai turi būti saugomas rinkmenos, iš kurios importuotas duomuo, pavadinimas);5.1.4.15. Sistemoje privalo būti registruojami duomenų pakeitimai, juos atlikę administratorius ir pakeitimų atlikimo data bei laikas. Sistemos administratorius privalo galėti nurodyti, kokių duomenų pakeitimai turi būti registruojami;5.1.4.16. Sistemos administratorius privalo galėti lengvai peržiūrėti konkrečių duomenų keitimo istoriją (tiek ekraninėje formoje, tiek ataskaitoje);5.1.4.17. Sistemoje, saugant pakeistus duomenis, privalo būti išsaugoma nauja duomenų versija;5.1.4.18. Sistema pagal nustatytas taisykles privalo automatiškai patikrinti įvedamų duomenų formato korektiškumą;5.1.4.19. Sistema pagal nustatytas taisykles privalo automatiškai patikrinti įvedamų duomenų loginį teisingumą (pvz., įvedant subjekto kodą, sistema privalo patikrinti, ar toks subjektas egzistuoja ir jo neradus, privalo sistemos naudotoją apie tai informuoti);5.1.4.20. Sistema privalo automatiškai tikrinti importuojamų duomenų formato korektiškumą;5.1.4.21. Sistemoje pagal nustatytas taisykles privalo būti tikrinamas importuotų duomenų loginis teisingumas (pvz., ar egzistuoja subjektas pagal nurodytą subjekto kodą);5.1.4.22. Jei įvestuose ar importuotuose duomenyse yra klaidų, sistema tokius įrašus privalo pažymėti kaip klaidingus ir prie kiekvieno klaidingo įrašo pateikti išsamų klaidos (-ų) apibūdinimą (pvz., pateikiamas aprašymas, nusakantis klaidos šaltinį, aprašymas pateikiamas pilnais sakiniais);5.1.4.23. Sistemos administratorius turi galėti peržiūrėti ir atsispausdinti visus klaidingus įrašus su išsamiu klaidos apibūdinimu;5.1.4.24. Sistemoje pagal nustatytas taisykles privalo būti siunčiami klaidų ir informaciniai pranešimai į bet kurią SMTP palaikančią elektroninio pašto sistemą;5.1.4.25. Klaidų aprašymai privalo būti dokumentuoti ir prieinami sistemoje. Klaidų aprašymai privalo būti klasifikuoti pagal jų pobūdį, o kiekviena klaida (jos aprašymas) identifikuojama unikaliu kodu, sudarytu pagal nustatytą taisyklę;5.1.4.26. Klaidų pranešimai, teikiami sistemos naudotojams, privalo būti informatyvūs ir suteikti pakankamai informacijos tolimesniems veiksmams klaidai pašalinti ar jos išvengti;5.1.4.27. Klaidų faktai privalo būti registruojami atskirame sąraše ir (ar) audito informacijos žurnaluose;5.1.4.28. Sistemoje pagal nustatytas taisykles privalo būti automatiškai pateikiami informaciniai pranešimai (pvz., informacija apie tai, kad subjektas vėluoja pateikti reikiamus duomenis);5.1.4.29. Sistemos administratorius privalo galėti atsispausdinti peržiūrimus duomenis (pvz., naudotojui išfiltravus sąrašą konsoliduojamųjų subjektų privalo būti galimybė atsispausdinti visą išfiltruotą konsoliduojamųjų subjektų sąrašą);

14

5.1.4.30. Sistemos administratorius privalo galėti keisti ir šalinti įvestus ir neužregistruotus duomenis bei negalėti keisti ir šalinti užregistruotų duomenų;5.1.4.31. Sistemoje privalo būti galimybė rūšiuoti duomenis pagal pasirinktus parametrus (parametrai turės būti suderinti sistemos diegimo projekto reikalavimų analizės ir projektavimo metu). Duomenys, susidedantys iš lietuviškų rašmenų, rūšiuojami pagal lietuvišką abėcėlę;5.1.4.32. Sistemoje privalo būti galimybė atlikti įrašų paiešką pagal pasirinktus parametrus (parametrai turės būti suderinti sistemos diegimo projekto reikalavimų analizės ir projektavimo metu);5.1.4.33. Sistemoje privalo būti galimybė vykdyti išplėstinę (pvz., kompleksinę, pagal fragmentą ir pan.) paiešką (tikslūs paieškos parametrai privalės būti suderinti sistemos diegimo projekto reikalavimų analizės ir projektavimo metu);5.1.4.34. Sistemoje privalo būti galimybė peržiūrėti paieškos rezultatų skaičių bei paieškos rezultatų sąrašą;5.1.4.35.Sistemoje privalo būti galimybė iš paieškos rezultatų sąrašo pasirinkti ir atidaryti duomenis vienu pelės arba klaviatūros klavišo paspaudimu;5.1.4.36.Sistemoje privalo būti galimybė išsaugoti paieškos rezultatus ir juos vėliau panaudoti nevykdant naujos paieškos.5.1.5. Rezervinio kopijavimo reikalavimai:5.1.5.1. Sistemoje privalo būti visų saugomų duomenų automatinio rezervinio kopijavimo galimybė;5.1.5.2. Privalo būti galimybė daryti rezervines kopijas tiek veikiančioje, tiek neveikiančioje sistemoje;5.1.5.3. Sistemos administratoriai privalo turėti galimybę nustatyti rezervinį kopijavimą pagal periodiškumą ir (arba) laiką ir informacijos saugojimo vietą.5.1.5.4. Sistema privalo turėti rezervinio kopijavimo žurnalą. Privalo būti galimybė peržiūrėti ir atsispausdinti žurnalą;5.1.5.5. Sistemos administratoriai privalo turėti galimybę inicijuoti sistemos duomenų atstatymo iš rezervinės kopijos procedūrą. Atstačius duomenis privalo būti užtikrintas ir išlaikytas duomenų vientisumas ir integralumas.5.1.6. Sistemos greitaveika:§

5.1.6.1. Sistemoje turi būti užtikrinti šie sistemos reakcijos greičiai (įvertinus, jog su sistema vienu metu gali dirbti iki 1500 stacionarių ir mobilių darbo vietų naudotojų):- Paieška –- iki 5 sekundžių (sistemos diegimo projekto reikalavimų analizės metu privalės būti suderinti dažniausiai naudojamų paieškų sąrašas, kuriam taikomas šis reikalavimas). Tačiau 90 % atvejų paieška privalo trukti iki 5 sekundžių;- Ataskaitų generavimas – ne daugiau kaip 1 sekundė vieno nustatytos formos (šablono) ataskaitos puslapio generavimui ir ne daugiau 20 sekundžių vieno suvestinės ataskaitos puslapio generavimui (suvestine ataskaita laikomos tokios ataskaitos, kai jose atvaizduojami duomenys gaunami ataskaitos formavimo metu atliekant papildomus veiksmus su kelių subjektų, subjektų grupių duomenimis). Sistemos diegimo projekto reikalavimų analizės metu visos ataskaitos privalės būti suskirstos į paprastas ir suvestines.5.1.7. Sistemos prieinamumas:5.1.7.1. Sistema privalo užtikrinti korektišką avarinių situacijų, kurias sukėlė neteisingi naudotojo veiksmai, valdymą. Sistemos naudotojui atlikus neteisingą (neleidžiamą) komandą arba nekorektiškai įvedus duomenis, sistema privalo naudotojui rodyti atitinkamus pranešimus ir po to grįžti į pradinę darbo būklę.5.1.7.2. Sistema neprivalo reikalauti, kad sistemos administratorius rankiniu būdu instaliuotų kompiuteryje kokias nors specialias programas ar joms reikalingus komponentus po sistemos įdiegimo.5.1.7.3. Sistema neprivalo reikalauti iš sistemos naudotojų turėti administratoriaus teises savo darbo vietoje tuo atveju, jei siūloma sistema automatiškai instaliuoja būtinus programinius komponentus.5.1.8. Plečiamumas:5.1.8.1. Sistema privalo būti suprojektuota ir realizuota taip, kad būtų lanksti modifikuojant – realizavus funkcionalumo pakeitimus vienoje ar keliose funkcinėse srityse, pakeitimai neprivalo būti visos Sistemos perkūrimo priežastimi;

§ Tiekėjas pateikdamas pasiūlymą turi pateikti techninės įrangos ir infrastruktūros specifikaciją, remdamasis siūlomos Sistemos gamintojo rekomendacijomis (taip pat turi pateikti ir gamintojo rekomendacijas, kuriomis remiantis buvo pateikta specifikacija), kuri leistų 3 metus užtikrinti šioje reikalavimų dalyje pateiktus Sistemos greitaveikos reikalavimus (esant numatytam Sistemos naudotojų skaičiui bei numatytiems duomenų kiekiams). Jei Sistemoje būtų naudojama kitokios specifikacijos techninė įranga ir infrastruktūra nei rekomenduoja Tiekėjas, tai greitaveikos reikalavimai turėtų būti peržiūrėti ir suderinti su Tiekėju. Galutinė techninės įrangos ir infrastruktūros specifikacija galės būti suderinta Sistemos diegimo projekto analizės etapo metu, tačiau jos pakeitimai turi būti neženklūs ir neviršyti 10 % nuo Tiekėjo pateiktos preliminarios pradinės techninės įrangos ir infrastruktūros specifikacijos.

15

5.1.8.2. Sistemoje privalo būti galimybė keisti įrašų atributų skaičių bei jų charakteristikas, pridėti naujus atributus.5.1.9. Sistemos sauga** ir naudotojų administravimas:5.1.9.1. Sistema privalo palaikyti siunčiamų, gaunamų ir saugojamų duomenų užšifravimą ir iššifravimą;5.1.9.2. Sistema privalo palaikyti laiko žymių (angl. Time stamp) generavimą ir patikrinimą;5.1.9.3. Sistema privalo palaikyti dokumento saugumo savybių (angl. Security attributes) patikrinimus;5.1.9.4. Sistemoje privalo būti kaupiama audito informacija apie operacijas su duomenimis. Sistemos administratorius privalo turėti galimybę nustatyti, kokių duomenų audito informacija privalo būti kaupiama;5.1.9.5. Audito istorijoje privalo būti saugoma informacija apie veiksmus su duomenimis, naudotojus, kurie atliko veiksmus su duomenimis, datas, laiko įrašus;5.1.9.6. Sistemos autorizavimo mechanizmas privalo būti realizuotas remiantis vaidmenų modeliu (angl. role-based model);5.1.9.7. Sistemoje kiekvienas naudotojas privalo būti unikaliai identifikuojamas;5.1.9.8. Sistemoje naudotojas privalo patvirtinti savo tapatybę slaptažodžiu arba kita autentiškumo patvirtinimo priemone;5.1.9.9. Sistemoje naudotojas privalo galėti keisti prisijungimo slaptažodį. Sistemos administratorius privalo galėti nustatyti pirmą kartą prie sistemos prisijungiančių naudotojų slaptažodžius bei keisti sistemos naudotojų slaptažodžius;5.1.9.10. Sistemoje naudotojų vardai ir slaptažodžiai privalo būti saugomi su tinkamu prieigos kontrolės užtikrinimu ir informacijos šifravimu (pvz., slaptažodžiai turi būti šifruojami ir pan.);5.1.9.11. Sistemoje privalo būti galimybė registruoti naujus naudotojus;5.1.9.12. Privalo būti galimybė Sistemos naudotoją susieti su konkrečia naudotojų grupe;5.1.9.13. Sistemoje privalo būti galimybė registruoti naujus naudotojų vaidmenis (angl. role);5.1.9.14. Sistemoje privalo būti galimybė suskirstyti naudotojus į atskirus vaidmenis su skirtingomis priėjimo teisėmis prie atskirų sistemos objektų (duomenų struktūrų) ar jų dalių (pvz., lentelių ar konkrečių lentelės įrašų), sistemos programinių vienetų (pvz., formų, ataskaitų, procedūrų ir kt.) ar jų dalių (pvz., formos mygtukas, laukas). Sistemos naudotojas privalo galėti peržiūrėti tik tokią informaciją ir naudotis tik tokiomis funkcijomis, kurios yra nustatytos priėjimo teisėmis (pvz., ataskaitoje gali būti pateikti tik tokie rezultatai, kuriuos subjektas gali peržiūrėti, jei subjektas nori peržiūrėti ir kitą informaciją, sistema privalo pranešti, kad naudotojas neturi teisių peržiūrėti tam tikrų duomenų ar kitais būdais apriboti informacijos peržiūrą);5.1.9.15. Sistemoje privalo būti galimybė naudotojui apibrėžti ir keisti vaidmeniui priskirtas priėjimo teises;5.1.9.16. Sistemoje privalo būti galimybė nukopijuoti (klonuoti) naudotoją su priėjimo teisių nustatymais;5.1.9.17. Sistemoje privalo būti galimybė vienam naudotojui priskirti daug vaidmenų;5.1.9.18. Sistemoje privalo būti galimybė nustatyti naudotojo aktyvumo laikotarpį;5.1.9.19. Sistemoje privalo būti galimybė nurodyti vaidmens (angl. role) galiojimo laikotarpį;5.1.9.20. Sistemoje privalo būti galimybė naudotojui keisti naudotojo statusą (aktyvus, neaktyvus);5.1.9.21. Sistemoje privalo būti galimybė administratoriui nustatyti ir keisti naudotojo prisijungimo slaptažodžio galiojimo laikotarpį;5.1.9.22. Sistemoje privalo būti galimybė nustatyti naudotojo prisijungimo slaptažodžio ilgį. Turi būti galimybė keisti slaptažodžio ilgio reikšmę;5.1.9.23. Sistemoje privalo būti galimybė nustatyti ir keisti naudotojo prisijungimo slaptažodžio sudėtingumą (pvz., slaptažodį turi sudaryti 8 simboliai, iš kurių bent 2 skaičiai ir bent viena didžioji raidė);5.1.9.24. Sistema privalo automatiškai nutraukti naudotojo darbo seansą praėjus parametrais apibrėžtam naudotojo neaktyvumo laikotarpiui ir informuoti naudotoją apie atjungimo priežastį. Privalo būti galimybė keisti neaktyvumo laikotarpio parametro reikšmę;5.1.9.25. Sistemoje privalo būti galimybė valdyti paskutinių naudotojo slaptažodžių istoriją. Sistemoje privalo būti galimybė neleisti naudoti prieš tai buvusių slaptažodžių. Neleidžiamų naudoti slaptažodžių skaičius privalo būti apibrėžtas parametru. Privalo būti galimybė keisti parametro reikšmę;5.1.9.26. Sistemoje privalo būti galimybė nustatyti naudotojo neteisingų prisijungimų skaičių, po kurio naudotojo prisijungimo vardas būtų blokuojamas. Prisijungimų skaičius privalo būti apibrėžtas parametru.

** Sistemos sauga turi būti suderinta su Lietuvos Respublikos vidaus reikalų ministro įsakymu Nr. 1V – 247 „Dėl Valstybės institucijų ir įstaigų informacinių sistemų klasifikavimo pagal jose tvarkomą elektroninę informaciją gairių ir Valstybės institucijų ir įstaigų informacinių sistemų elektroninės informacijos saugos reikalavimų patvirtinimo“ (2007-07-11, aktuali redakcija).

16

Privalo būti galimybė keisti parametro reikšmę;5.1.9.27. Sistemoje privalo būti galimybė nustatyti, kad pirmą kartą į sistemą įsiregistruojantys naudotojai privalėtų pakeisti administratoriaus suteiktą pirminį slaptažodį;5.1.9.28. Sistemoje administratoriaus vaidmuo privalo būti atskirtas nuo kitų sistemos naudotojų vaidmenų.5.1.9.29. Sistema privalo neteikti pagalbos sistemos naudotojui spėliojant slaptažodžius;5.1.9.30. Sistema privalo naudotojo grafinėje sąsajoje nevaizduoti naudotojo ID, išskyrus naudotojui jungiantis prie sistemos;5.1.9.31. Sistema privalo nevaizduoti įvedamo slaptažodžio;5.1.9.32. Prisijungimo prie Sistemos lange privalo būti įspėjimas, kad Sistema gali naudotis tik tas teises turintys asmenys;5.1.9.33. Sistemos administratorius privalo galėti atsispausdinti naudotojų ir naudotojų teisių sąrašus.5.1.10. Duomenų perdavimo internetu ar intranetu saugumo reikalavimai:5.1.10.1. Privalo būti užtikrintas išskirtinio saugaus duomenų perdavimo panaudojimas (VPN, sertifikatų panaudojimas ar kitoks koduotas prisijungimo būdas);5.1.10.2. Privalo būti užtikrintas duomenų kodavimas prieš perduodant duomenis (aktualu, jei duomenų mainai vyksta rinkmenų pavidalu).5.1.11. Duomenų archyvavimas:††

5.1.11.1. Sistemoje privalo būti galimybė archyvuoti duomenis;5.1.11.2. Sistemoje privalo būti galimybė nustatyti duomenų archyvavimo laikotarpį ir periodiškumą;5.1.11.3. Sistemoje privalo būti galimybė keisti duomenų archyvavimo laikotarpį ir periodiškumą;5.1.11.4. Sistemoje privalo būti galimybė peržiūrėti suarchyvuotus duomenis;5.1.11.5. Sistemoje privalo būti galimybė suformuoti ataskaitas iš suarchyvuotų duomenų.5.1.12.Kita:5.1.12.1. Sistema privalo leisti dirbti vienu metu ne mažiau kaip 1500 stacionarių ir mobiliųjų naudotojų arba naudotojų sesijų (išlaikant sistemos greičio reikalavimus, apibrėžtus bendrųjų reikalavimų dalyje „Sistemos greitaveika“);5.1.12.2. Duomenų apdorojimo procedūros ir funkcijos privalo būti realizuotos duomenų arba veiklos logikos programų architektūros lygiu;5.1.12.3. Sistemos naudotojai privalo neturėti galimybės atlikti operacijas tiesiai duomenų bazėje;5.1.12.4. Sistemoje privalo būti numatytos specializuotos (vizualios, stebėjimo realiame laike) sistemos administravimo priemonės.

†† Turima omenyje, kad duomenys supakuojami (pvz., perkeliami į kitą duomenų diską ar duomenų saugyklą ir panašiai) taupant vietą atmintyje.

17

Bendrojo pagalbos centro informacinės sistemos funkcinės specifikacijos1 priedas

MOBILIOJO RYŠIO OPERATORIŲ TEIKIAMŲ SKAMBINANČIŲJŲ VIETOS NUSTATYMO DUOMENŲ PRIĖMIMO APDOROJIMO, SAUGOJIMO SISTEMOJE IR

JŲ GRAFINIO PAVAIZDAVIMO SISTEMOS OPERATORIAUS KOMPIUTERIZUOTOJE DARBO VIETOJE REIKALAVIMŲ APRAŠAS

Sistema turi priimti, apdoroti, saugoti ir grafiškai pavaizduoti Sistemos operatoriaus kompiuterizuotoje darbo vietoje mobiliojo ryšio operatorių teikiamus skambinančiųjų vietos nustatymo duomenis taip, kad:

1. darbo vietoje būtų automatiškai priimti ir grafiškai pavaizduoti vietos nustatymo duomenys (X, Y koordinatės su paklaidos spinduliu R), pateikti ataskaitų (angl. Push) metodu;

2. BPC operatoriui atlikus užklausą Sistemoje būtų priimti ir grafiškai pavaizduoti vietos nustatymo duomenys (X, Y koordinatės su paklaidos spinduliu R), pateikti užklausų (angl. Pull) metodu. Užklausa turi būti atliekama vieno mygtuko paspaudimu. Turi būti užtikrinta, kad BPC operatorius atliktų neribotą užklausų skaičių;

3. Sistema pavaizduotų vietos nustatymo duomenis rankiniu būdu įvedant X ir Y koordinates į atitinkamus laukus;

4. vietos nustatymo duomenys, pateikti ataskaitų (angl. Push) metodu, būtų grafiškai pavaizduoti tik tos darbo vietos skaitmeniniame žemėlapyje, kuria buvo atsiliepta į pagalbos skambutį.

5. darbo vietoje, prie grafiškai pavaizduojamo paklaidos spindulio R, turi būti nurodomas jo dydis metrais;

6. darbo vietoje būtų pateikta, kartu su vietos nustatymo duomenimis gauta papildoma tekstinė vietos aprašymo informacija;

7. visi gauti vietos nustatymo duomenys turi būti saugomi Sistemos duomenų bazėje ne mažiau nei 6 mėnesius;

8. vietos nustatymo duomenys, kurie buvo priskirti konkrečiam įvykiui (įrašyti į konkrečią įvykio kortelę), turi būti papildomai saugomi Sistemos duomenų bazės įvykių lentoje. Jei vietos nustatymo duomenys buvo kelis kartus atnaujinti užklausos būdu, Sistemos duomenų bazės įvykių lentoje turi būti saugomi paskutiniai gauti vietos nustatymo duomenys;

9. paklaidos spindulio R grafinio pavaizdavimo darbo vietoje mastelis turi atitikti žemėlapio mastelį. Paklaidos spindulio R padengimo zona turi būti grafiškai pavaizduota pilnaviduriu aiškiai spalviškai išsiskiriančiu ir permatomu (angl. transparent) skrituliu.

18

Bendrojo pagalbos centro informacinės sistemos funkcinės specifikacijos2 priedas

BENDRASIS PAGALBOS CENTRAS

VIEŠŲJŲ JUDRIOJO TELEFONO RYŠIO ABONENTŲ IR (AR) PASLAUGŲ

GAVĖJŲ, SKAMBINANČIŲ BENDRUOJU PAGALBOS TELEFONO

NUMERIU 112, VIETOS NUSTATYMO DUOMENŲ TEIKIMO

BENDRAJAM PAGALBOS CENTRUI DETALIŲ TECHNINIŲ

REIKALAVIMŲ APRAŠAS

Dokumento versija Nr. 4.3.1

SUDERINTARyšių reguliavimo tarnybos 2008 m. sausio 2 d. raštu Nr. (26.28)-1B-4

Vilnius

2007-12-27

19

Turinys

1. Dokumento paskirtis.........................................................................................................................3

2. Nuorodos..........................................................................................................................................3

3. Santrumpos.......................................................................................................................................3

4. Aprašo apimtis..................................................................................................................................3

5. Bendrieji techniniai reikalavimai VND teikimo techniniam sprendimui.........................................4

6. VND teikimo techninio sprendimo protokolo reikalavimai.............................................................4

7. Techninės rekomendacijos VND teikimo techniniam sprendimui...................................................6

8. Plėtimo ir vystymo reikalavimai VND teikimo techniniam sprendimui..........................................6

20

1. Dokumento paskirtis

Viešųjų judriojo telefono ryšio abonentų ir (ar) paslaugų gavėjų, skambinančių bendruoju pagalbos telefono numeriu 112, vietos nustatymo duomenų teikimo Bendrajam pagalbos centrui detalių techninių reikalavimų aprašas (toliau – Aprašas) nustato technines sąlygas viešųjų judriojo telefono ryšio abonentų ir (ar) paslaugų gavėjų (toliau – abonentai ir (ar) paslaugų gavėjai), skambinančių bendruoju pagalbos telefono numeriu 112, vietos nustatymo duomenų teikimo Bendrajam pagalbos centrui techniniam sprendimui (toliau – VND teikimo techninis sprendimas).

Viešųjų judriojo telefono ryšio paslaugų teikėjai (toliau – operatoriai) turi skirtingai išvystytą infrastruktūrą, todėl Bendrasis pagalbos centras suformulavo bendrus visiems operatoriams techninius reikalavimus pagal ETSI TS 102 164 V1.2.2 (2004-05) standartą.

2. Nuorodos

[1] LIF TS v3.0.0 Specification: ”Location Inter-operability Forum (LIF); Mobile Location Protocol” (http://www.locationforum.org);

[2] ETSI TS 102 164 v1.2.2 (2004-05) Technical Specification “Telecommunication and Internet converged Services and Protocols for Advanced Networking (TISPAN);

[3] Extensible Markup Language – XML/1.0 W3C Recommendation: REC-xml-19980210 (http://www.w3.org);

[4] Hypertext Transfer Protocol – HTTP/1.1 RFC 2068, June 1999 (http://www.w3.org).

3. Santrumpos

BPC Bendrasis pagalbos centrasSIM angl. Subscriber Identity moduleVND Vietos nustatymo duomenysGSM angl. Global System for Mobile CommunicationsUMTS angl. Universal Mobile Telecommunications SystemLBS angl. Location Based ServiceIP angl. Internet ProtocolISDN angl. Integrated Services Digital NetworkSS7 angl. Signaling System 7LKS-94 1994 m. Lietuvos koordinačių sistemaNumeris 112 Bendrasis pagalbos telefono numeris 112

4. Aprašo apimtis

Apraše apibūdinta sąsaja tarp operatoriaus tarnybinės stoties ir VND naudotojo – BPC – tarnybinės stoties.

21

1 pav. Dokumento apimtis – sąsaja tarp operatoriaus ir BPC tarnybinių stočių VND perdavimui

5. Bendrieji techniniai reikalavimai VND teikimo techniniam sprendimui

5.1. VND teikimo techninis sprendimas turi būti realizuotas nepriklausomai nuo operatorių tinklų technologijos, todėl VND protokolo techniniai reikalavimai yra paremti LIF TS v3.0.0 specifikacija, kuri yra duomenų perdavimo tinklų taikomojo lygio, aprašančio sąsają tarp operatoriaus ir BPC tarnybinių stočių.

5.2. VND teikimo techninis sprendimas turi užtikrinti, kad būtų nustatyti ir į BPC perduoti abonento ir (ar) paslaugų gavėjo, skambinančio operatoriaus GSM ir (arba) UMTS tinkle numeriu 112, VND.

5.3. VND teikimo techninis sprendimas turi užtikrinti, kad VND paslauga vienodu kokybės lygiu turi veikti šioms judriojo telefono ryšio abonentų ir (ar) paslaugų gavėjų kategorijoms:

5.3.1. operatoriaus abonentams ir (ar) paslaugų gavėjams, esantiems šio operatoriaus tinkle;5.3.2. operatoriaus tinkle veikiančių „virtualiųjų operatorių“ abonentams;5.3.3. operatoriaus nacionalinio tarptinklinio ryšio abonentams ir (ar) paslaugų gavėjams (angl.

national operator subscribers with roaming agreement);5.3.4. atvykusiems tarptautinio tarptinklinio ryšio abonentams ir (ar) paslaugų gavėjams (angl.

international subscribers with roaming agreement).5.4. VND teikimo techninis sprendimas turi perduoti abonentų ir (ar) paslaugų gavėjų VND į

BPC (Vilnius, Švitrigailos g. 18) per saugią ir patikimą dedikuotą liniją arba dedikuotu IP tuneliu.5.5. VND teikimo techninis sprendimas turi veikti (perduoti VND BPC) ataskaitų (angl. Push) ir

užklausų (angl. Pull) metodais. Naudojant Push metodą, VND turi būti siunčiami sujungimo su BPC tarnybine stotimi metu (angl. during call set-up). Naudojant Pull metodą, VND turi būti siunčiami įvykus sujungimui su BPC tarnybine stotimi (angl. during call).

5.6. VND teikimo techninis sprendimas turi apimti ne tik numerį 112, bet ir trumpuosius pagalbos tarnybų numerius, veikiančius viešojo judriojo telefono ryšio paslaugų teikėjų tinkluose (atitinkamai 101, 102, 103, 011, 022, 033), jei telefono skambučiai į šiuos numerius bus nukreipti į BPC, t. y. jei pagalbos skambučius šiais numeriais administruos BPC.

5.7. Operatorius turi turėti dubliuotą VND teikimo techninį sprendimą, ir užtikrinti ne mažesnį nei 97% VND teikimo patikimumą.

5.8. VND teikimo techninis sprendimas turi pateikti VND koordinates ne mažesniu nei celės su aptarnaujamo sektoriaus (angl. Cell-ID) tikslumu – pateikiamos vietą nusakančio apskritimo centro LKS-94 koordinatės su paklaidos spinduliu metrais (LIF TS 101, skyrius 10.5.2).

5.9. VND paslauga Push metodu turi būti teikiama ir tais atvejais, kai neidentifikuojama skambinančiojo linija (angl. Calling Line Identification, CLI), išskyrus atvejį, kai skambinančiojo linija neidentifikuojama:

5.9.1. nacionalinio operatoriaus abonentui ir (ar) paslaugų gavėjui paskambinus numeriu 112 kito operatoriaus tinklu be tarptinklinio ryšio sutarties (angl. national camping);

5.9.2. užsienio operatoriaus abonentui ir (ar) paslaugų gavėjui paskambinus numeriu 112 kito operatoriaus tinklu be tarptinklinio ryšio sutarties (angl. international subscribers without roaming agreement).

5.10. 95% visų VND turi būti pateikiami į BPC ne didesniu nei 20 sekundžių vėlinimu nuo tada, kai įvyksta sujungimas su BPC tarnybine stotimi (Push metodo atveju) arba nuo Pull užklausos pateikimo momento.

5.11. Operatoriaus nustatytų ir perduotų į BPC VND kopija turi būti saugoma pas operatorių 6 mėnesius. Operatorius turi užtikrinti, kad BPC prašymu jam būtų pateikta informacija apie suteiktas VND teikimo paslaugas (srauto duomenys), kuri turi būti saugoma 6 mėnesius.

6. VND teikimo techninio sprendimo protokolo reikalavimai

LIF TS v3.0.0 standarte išskirti trys VND protokolo lygiai: paslaugų, elementų ir transporto.

22

Pagalbos skambučio VND ataskaita

VND tarnybinė stotis

VND vartotojas

(BPC)

Pagalbos skambučio VND duomenų užklausa

Pagalbos skambučio VND duomenų pateikimas

VND tarnybinė stotis

VND vartotojas

(BPC)

6.1.   Paslaugų lygis Aukščiausias paslaugų lygis apsprendžia VND technologijos funkcijas. Pagalbos skambučių

VND paslaugos turi būti išskirtos į pagrindines ir papildomas. Pagrindinės paslaugos realizuotos Pull ir Push metodais. Papildomų paslaugų šis dokumentas neaprašo, tačiau pagal LIF TS v.3.0.0 specifikacijų 3.3 skyriaus reikalavimus turi būti numatytas papildomų paslaugų funkcionalumo praplėtimas, neįtakojantis pagrindinių paslaugų. (pvz. eCall).

Pagal LIF TS v.3.0.0 specifikaciją, turi būti įdiegtos dvi pagrindines VND paslaugos:1) Pagalbos skambučių vietos nustatymo ataskaitos pateikimo paslauga (angl. Emergency

Location Reporting Service – ELRS).2) Pagalbos skambučių vietos nustatymo nedelsiant paslauga (angl. Emergency Location

Immediate Service – ELIS).

6.1.1. Pagalbos skambučių vietos nustatymo ataskaitos pateikimo paslaugaAtaskaitų metodu Push pagrįsta pagrindinė VND paslauga pagal ETSI TS 102 164 v1.2.2

(2004-05) standartą yra Pagalbos skambučių vietos nustatymo ataskaitos pateikimo paslauga, pateikta 2 pav.

2 pav. Pagalbos skambučių VND paslaugos ataskaitų metodu Push susideda išpagalbos skambučių VND ataskaitos parengimo ir perdavimo BPC

6.1.2. Pagalbos skambučių vietos nustatymo nedelsiant paslaugaUžklausų metodu Pull, pagrįsta pagrindinė VND paslauga pagal ETSI TS 102 164 v1.2.2 (2004-

05) standartą yra Pagalbos skambučių vietos nustatymo nedelsiant paslauga, pateikta 3 pav.

3 pav. Pagalbos skambučių VND paslaugos užklausų metodu Pull susideda iš pagalbosskambučių VND užklausos parengimo BPC ir VND ataskaitos pagal šią užklausą parengimo ir perdavimo BPC

6.2. Elementų lygis LIF TS v3.0.0 specifikacijoje pateikti praplečiamosios dokumentų aprašų kalbos (angl.

eXtensible Markup Language, XML) elementai pagrindinėms paslaugoms. LIF TS v3.0.0 specifikacijoje yra pateiktas kiekvieno elemento detalus aprašymas, o priede pateikiamoje lentelėje, parengtoje remiantis LIF TS v3.0.0 ir ETSI TS 102 164 v1.2.2 (2004-05) techninėmis specifikacijomis, nurodant tik reikalingus elementus.

6.3. Transporto lygis Pull ir Push metodų sprendimai turi būti realizuoti hipertekstų perdavimo protokolu (angl.

Secure HyperText Transfer Protocol, HTTPS) praplečiamąja dokumentų aprašų kalba (angl. eXtensible Markup Language, XML).

23

7. Techninės rekomendacijos VND teikimo techniniam sprendimui

7.1. Rekomenduojama, kad VND teikimo techninis sprendimas turėtų galimybę nustatyti ir perduoti į BPC abonentų ir (ar) paslaugų gavėjų VND kuomet ryšys su BPC regioniniais padaliniais yra pagrįstas įvairiais signalizacijos tipais (pvz., ISDN, SS7).

7.2. Rekomenduojama, kad VND teikimo techninis sprendimas turėtų galimybę nukreipti VND į tam tikrą IP adresą (-us) pagal iš anksto nustatytą ir modifikuojamą skambučio numeriu 112 ir su juo susijusių VND siuntimo algoritmą.

7.3. Kartu su vietą nusakančio apskritimo centro koordinatėmis ir paklaidos spinduliu rekomenduojama pateikti tekstinius vietos aprašymus (angl. Textual location description), šiam tikslui naudojant MLP išplėtimo mechanizmą (angl. MLP extension mechanism).

8. Plėtimo ir vystymo reikalavimai VND teikimo techniniam sprendimui

8.1. VND teikimo techninis sprendimas turi nustatyti skambinančiojo VND ir perduoti į atitinkamą BPC regioninį padalinį pagal iš anksto nustatytą skambučio numeriu 112 ir su juo susijusių VND siuntimo algoritmą. Įvykus gedimui viename ar keliuose BPC regioniniuose padaliniuose, skambučiai kartu su VND turi būti perduodami į kitą BPC regioninį padalinį pagal iš anksto nustatytą skambučių ir VND rezervinio siuntimo algoritmą.

8.2. VND teikimo techninis sprendimas turi būti atviras VND tikslumą pagerinančių technologijų įdiegimui.

8.3. Operatoriaus tinkle įdiegus techninius sprendimus pozicionuoti judriojo ryšio telefoną be SIM kortelės, VND teikimo techninis sprendimas šiuos duomenis turi siųsti į BPC.

8.4. VND teikimo techninis sprendimas turi būti atviras įdiegti papildomas funkcijas (pvz., tokias kaip abonentų ir (ar) paslaugų gavėjų VND atnaujinimas, kai nutrūkus ryšiui BPC operatorius paskambina abonentų ir (ar) paslaugų gavėjų), jei tai būtina užtikrinant visuomenės saugumą, įgyvendinant teisės aktus ar tarpusavio susitarimus.

8.5. Esant techninėms galimybėms operatoriaus tinkle, VND teikimo techninis sprendimas turi užtikrinti, kad VND paslauga vienodu kokybės lygiu turi veikti šioms judriojo telefono ryšio abonentų ir (ar) paslaugų gavėjų kategorijoms:

8.5.1. kitiems nacionalinių operatorių abonentams be tarptinklinio ryšio sutarties (angl. national camping);

8.5.2. atvykusiems tarptautiniams abonentams be tarptinklinio ryšio sutarties (angl. international subscribers without roaming agreement).

24

Viešųjų judriojo telefono ryšio abonentų ir (ar) paslaugų gavėjų, skambinančių bendruoju pagalbos telefono numeriu 112, vietos nustatymo duomenų teikimo Bendrajam pagalbos centrui detalių techninių reikalavimų aprašopriedas

REIKALINGŲ ELEMENTŲ (PAGAL LIF TS V3.0.0 IR ETSI TS 102 164 V1.2.2 (2004-05)) APRAŠYMO LENTELĖ

LIF TS 101 [1]Skyrius ir pavadinimas

Reikalavimai pagalETSI TS 102 164 V1.2.2 (2004-3 05) [2]

Paaiškinimas

3 General3.3 MLP extension mechanism

Required Galimybė išplėsti sąsajos funkcijas, kurie neįtakotų sąsajos pagrindinių funkcijų realizavimo. Rekomenduojama naudoti perduodant tekstinį vietos aprašymą.

4. Mobile Location Service Definitions4.1 Transport Protocol Layer Definitions

Required (See endorsement of Annex B of [1])

Sprendimas realizuotas HTTP protokolu.

4.2 Element Layer Definitions

4.2.1 Identity Element Definitions

The following elements are required to be supported, and where an element is a construction, which elements are required to be supported within the construction: msid msid

o msidOne msid element shall be included in an msids element)

Skambinančiojo identifikacija vykdoma pagal MSISDN.

4.2.3 Location Element Definitions

The following elements are required to be supported, and where an element is a construction, which elements are required to be supported within the construction: eme_pos

o msido pdo poserr

pdo timeo shapeo lev_conf

poserro resulto time

result time lev_conf

Pagalbos skambučio vietos nustatymo duomenys:

MSISDNlaikas, kada gautas skambutis

koordinatėskoordinačių tikslumo patikimumasklaidų ataskaita

4.2.7 Context Element Definitions

The following elements are required to be supported, and where an element is a construction, which elements are required to be supported within the construction: Client

o id

Konteksto duomenys

1) Identifikacija:

LIF TS 101 [1]Skyrius ir pavadinimas

Reikalavimai pagalETSI TS 102 164 V1.2.2 (2004-3 05) [2]

Paaiškinimas

o pwdo requestmode

id pwd requestmode servicetype

1.1) Užregistruoto vartotojo (BPC) identifikacija, kai atliekama užklausa.1.2) LBS teikėjo (operatoriaus) identifikacija, kai pateikiamas atsakymas.

2) Slaptažodis:

2.1) Užregistruoto vartotojo (BPC) slaptažodis, kai atliekama užklausa.2.2) LBS teikėjo slaptažodis, kai pateikiamas atsakymas.

4.3 Service Layer Definitions

4.3.1 Header Components

4.3.1.1 Context DTD

The following elements are required to be supported, and where an element is a construction, which elements are required to be supported within the construction: hdr

o client

Antraštėje turi būti vartotojo identifikacija ir slaptažodis.

4.3.3 Emergency Location Immediate Service

Required Pull technologijos sprendimas kompiuterinių tinklų taikomajame lygyje.

4.3.3.1 Emergency Location ImmediateRequest DTD

The "eme_lir" shall contain the following element: msids

Pull sprendime pateikiant užklausą turi būti nurodomas MSISDN.

4.3.3.2 Emergency Location ImmediateAnswer DTD

The "eme_lia" shall contain the following elements: eme_pos, or result

Pull sprendime gaunat atsakymą turi būti vietos nustatymo duomenys aprašyti LIF TS 101 skyriuje 4.2.3

4.3.5 Emergency Location Reporting Service

Required Push technologijos sprendimas kompiuterinių tinklų taikomajame lygyje

4.3.5.1 Emergency Location Report DTD

The "emerep" shall contain the following elements: eme_event

Push sprendime gaunat atsakymą turi būti vietos nustatymo duomenys aprašyti LIF TS 101 skyriuje 4.2.3

4.3.7 General Error Message Definition

The "gem" shall contain the following elements: result

Klaidų atskaita, indukuojanti užklausos rezultatą.

6 Result codes and error codes

6.1 Result codes Required Klaidų ataskaitos:Vietos nustatymo serverio klaidos;

Užklausos klaidos;Tinklo klaidos;Papildomų funkcijų klaidos;Paslaugų teikėjų klaidos

9 Appendix B - HTTP mapping

The lif-mlp-s (9211/tcp) port or the lif-mlp (9210/tcp) port shall be used.Location client shall use separate HTTP posts and NOT use pipelining for time critical requests to avoid that one request delays other requests. Location Server shall process and respond to theseparate HTTP posts out of order.

lif-mlp-s (9211/tcp) prieiga.Tarnybinės stotys turi palaikyti asinchroniškus patvirtinimus HTTP siuntimams (angl. posts).

9.2.1 Service Initiation DTD

The "svc_init" shall contain the following elements:

Paslaugos inicijavimo elemento "svc_init" atributai: hdr

LIF TS 101 [1]Skyrius ir pavadinimas

Reikalavimai pagalETSI TS 102 164 V1.2.2 (2004-3 05) [2]

Paaiškinimas

hdr eme_lir

eme_lir

9.2.2 Service Result DTD

The "svc_result" shall contain the following elements:

hdr (tik emerep) eme_lia emerep

Paslaugos rezultato elemento "svc_result" atributai: eme_lia emerep