Neclasificat
Neclasificat 1/15
ANEXA 1
Descrierea generală a fluxului de recepționare a apelurilor de
urgență, a interfeţelor cu sistemele existente și a tipurilor de
echipamente ce vor fi menținute în utilizare
Neclasificat
Neclasificat 2/15
CUPRINS
1. Fluxul de recepţionare al apelurilor de urgenţă în sistemul actual şi principalele elemente
componente ale SNUAU ................................................................................................................................ 3
1.1. Fluxul de recepţionare al apelurilor de urgenţă .......................................................................... 3
1.2. Descriere generală a subsistemului eCall .................................................................................. 4
1.3. Descriere generală a subsistemului de localizare a apelurilor de urgenţă ........................... 6
1.4. Subsistemul de comunicaţie cu resursele mobile de intervenţie medicală ............................ 7
1.5. Interfeţe de comunicaţie interne/externe ..................................................................................... 8
1.5.1. Interfaţa de comunicaţie cu aplicaţiile de preluare şi dispecerizare apeluri de urgenţă
din cadrul Centrelor 112 ......................................................................................................................... 8
1.5.2. Interfaţa cu sistemul de comunicaţii cu resursele mobile de intervenţie ........................ 8
1.5.3. Interfaţa subsistem eCall aplicaţie 112 ................................................................................ 9
1.5.4. Interfaţă ARLS STS TETRA cu sistemul ARLS 112 existent ......................................... 11
1.5.5. Interfaţa SMS ......................................................................................................................... 11
1.5.6. Interfaţa VoWiFi ..................................................................................................................... 12
1.5.7. Interfaţa transfer fişă de caz în format XML şi fişiere asociate ..................................... 13
1.5.8. Interfaţa transfer fişă de caz Romatsa ............................................................................... 13
1.5.9. Interfaţa transfer fişă de caz aferente agenţiilor Poliţie, Jandarmi, ISU către sistemul
informatic central SIMIEOP ................................................................................................................. 13
1.5.10. Interfaţa de comunicaţie bidirecţională aplicaţie 112 cu SMISU la nivelul fiecărui
Centru 112 14
1.5.11. Interfaţă de comunicaţie bidirecţională aplicaţie 112 cu aplicaţii de dispecerizare
medicală de tip Romsys ....................................................................................................................... 14
2. Caracteristici tehnice ale echipamentelor terminale existente în amplasamentele operaţionale
care nu fac obiectul prezentului proiect ..................................................................................................... 15
2.1 Specificaţii hardware .................................................................................................................... 15
2.2 Specificaţii software ...................................................................................................................... 15
NOTĂ: În prezentul document este prezentată o scurtă descriere a fluxului de
recepţionare al apelurilor de urgenţă în sistemul actual precum şi a elementelor
componente, sunt detaliate interfeţele interne actuale dintre diversele componente
ale SNUAU şi cele de comunicare uni/bi-direcţională cu diverse sisteme externe,
precum şi caracteristicile tehnico-funcţionale ale echipamentelor terminale care vor
fi menţinute în utilizare şi după implementarea proiectului. Modul de implementare
al interfeţelor de comunicaţie cu sisteme informatice care vor fi menţinute în
funcţiune sau care vor fi utilizate pe durata migrării la noul sistem informatic,
precum şi cele cu sistemele externe interconectate în prezent cu SNUAU, vor fi
stabilite de comun acord între Achizitor și Furnizor, după intrarea în vigoare a
contractului de furnizare, în etapa de analiză a proiectului.
Neclasificat
Neclasificat 3/15
1. Fluxul de recepţionare al apelurilor de urgenţă în sistemul actual şi
principalele elemente componente ale SNUAU
SNUAU reprezintă ansamblul subsistemelor ce asigură funcţionarea serviciilor critice şi de suport în gestionarea apelurilor de urgenţă şi a misiunilor de intervenţie specifice agenţiilor de urgenţă.
1.1. Fluxul de recepţionare al apelurilor de urgenţă
Apelurile de urgenţă iniţiate din reţele publice de telefonie sunt concentrate de către operatorul Telekom Romania, de unde prin intermediul unor conexiuni de tip SS7 sunt direcţionate către 7 puncte de interconectare SS7 ale STS (9 echipamente voce şi 2 echipamente semnalizare SS7), apoi sunt transferate în reţeaua MSS (reţea multi-servicii) a STS (comutare ISDN) şi transportate către Centrele 112 din a căror arie de responsabilitate sunt iniţiate apelurile. La acest nivel apelurile sunt preluate într-un echipament de tip PBX şi transferate (ISDN/SIP) într-un echipament de tip soft-exchange, care realizează conversia în format VoIP, punându-le apoi la dispoziția operatorilor în aplicaţiile voce/date 112 disponibile pe terminalele operaţionale. Prin intermediul funcţiilor date-voce aferente aplicaţiilor 112, operatorii şi dispecerii agenţiilor de intervenţie la urgenţă conlucrează la rezolvarea aceluiaşi caz, având o imagine operaţională comună asupra acestuia. Aceştia au la dispoziție mijloace de comunicaţie radio TETRA şi convenționale, ieşiri în reţele de telefonie private / de cooperare (112, IC, MAI) şi publice, fax şi imprimare. Schematic, arhitectura sistemului actual este reprezentat astfel:
RETEA PSTN
TELEKOM
112
RETEA RADIO
STS
EONES
SS7
RE
TE
A IS
DN
AT
M
RETEA IP ATM
MD 110
112LAN 112
GIS
ECALL
LOCALIZARE
FO
SS7 14xE1
AGENTII
Resedinta/municipii
WAN DTI STS
FO
1xE1
CTD
IC1xE1
1xE
1
TELEKOM
TELEKOM
E1/2Wire
MNO
SS7
112
2
wire
1xE1
FO
ETH
ISDNISDN
Modem Ecall
FO2xE1
Modem Ecall
TERTI
FO
FO
CNADR
GRUP ACD
IVS
GPS
Ecall
PSAP
Rack Eones
Bucuresti/Brasov TETRA
STS
EUCARIS
v35
DATA CENTER
Bucuresti/Brasov
Internet
Judet
Punctul de intrare al apelurilor de urgenţă în SNUAU este reprezentat de
echipamentele de interfaţare cu Telekom (Eones) acestea asigurând totodată interfaţarea cu infrastructura MSS ISDN/IP a STS pentru rutarea apelurilor în cadrul SNUAU către Centrul 112 din a cărui aria de responsabilitate s-a iniţiat apelul. Acestea sunt dispuse în 7 puncte de interconectare cu operatorul Telekom şi au rolul de conversie a semnalizării SS7 la ISDN, de rutare a apelurilor către centrele judeţene folosind infrastructura ISDN a STS, de identificare şi rutare a apelurilor eCall către modem-urile eCall, de extragere a
Neclasificat
Neclasificat 4/15
informaţiilor de localizare a apelantului recepţionate în cadrul semnalizării SS7 şi de injectare a acestora în serverele de localizare actuale din SNUAU. Injectarea informaţiilor de localizare către cele 2 servere de procesare a localizării se realizează pe interfeţe specializate utilizând protocolul Radius, conform specificaţiilor din RFC 2865.
Infrastructura ISDN/IP
STS
Mod
ule
cone
ctar
e
Retea SS7
TELEKOM
5 x E1 ISDNEones 1
Eones 2 5 x E1 ISDN
5 x E1 SS7
5 x E1 SS7
IP
IP
Subsistem
Localizare
Bucuresti/Brasov
Eones 1
Eones 2
IP
Mod
ule
cone
ctar
e2 x E1 ISDN
2 x E1 ISDN
IP
IP
Eones3 x E1 ISDN
IPM
odul
e co
nect
are
2 x E1 SS7
2 x E1 SS7
3 x E1 SS7
Informatii localizare
Modem eCall
Modem eCall
IP
IP
Subsistem eCall
Procesare/Decodare
Bucuresti/Brasov
IP
Informatii MSD
Bucuresti
Brasov
Cluj/Timis/Dolj/Bacau/Galati
E1
E1
E1
E1
1.2. Descriere generală a subsistemului eCall
În cazul producerii unui eveniment de tip eCall, un dispozitiv IVS montat pe vehicul va transmite un apel de urgenţă, clar diferenţiat prin eCall flag în reţelele operatorilor de telefonie mobilă, printr-un un modem PSAP dedicat (dispus în SNUAU) către Centrul 112 eCall. La preluarea apelului de către operatorii 112, modemul PSAP va solicita echipamentului de pe vehicul un set minim de informaţii (MSD) privind localizarea incidentului, direcţia de deplasare, tipul de apel, numărul de pasageri, data şi ora producerii incidentului, seria VIN, modalitatea de stocare a energiei, tipul autovehiculului şi alte informaţii adiţionale. Datele in-band recepţionate sunt decodate de către modem vor fi transmise către un server de procesare MSD, care le furnizează aplicaţiilor de preluare şi dispecerizare 112. Schema generică de implementare a soluţiei eCall şi fluxul operaţional sunt prezentate în schema de mai jos:
Neclasificat
Neclasificat 5/15
1. Un eveniment din vehicul (automat/manual) determină comandarea unui apel eCall
către echipamentul IVS; 2. Apelul este preluat de către cel mai apropiat site GSM PLMN; 3. Din reţeaua GSM apelul este rutat în reţeaua TELEKOM; 4. Din reţeaua TELEKOM apelul este rutat în reţeaua SS7 (Eones) a STS în punctele
de interconectare SS7 Bucureşti şi Braşov; 5. Apelul este rutat funcţie de B-number către modemurile eCall PSAP, 6. Apelul tranzitează modemul PSAP şi este întors în Eones care îl rutează către
reţeaua MSS; 7. Reţeaua MSS pe baza prefixului îl va ruta către PSAP Bucureşti; 8. Apelul voce este recepţionat şi distribuit de către centrala PBX PSAP către
serverele soft-exchange; 9. Apelul este direcţionat în reţeaua VoiP a 112 şi afişat pe consolele operatorilor 112,
fiind executate secvenţial următoarele etape: A. Modemul eCall PSAP recepţionează mesajul MSD de la modulul IVS şi îl transmite la modulul de decodare MSD; B. Modulul de decodare MSD decodifică mesajul, extrage VIN şi îl transmite către modulul de procesare VIN; C. Modulul de decodare MSD decodifică mesajul şi transmite datele MSD către modulul de procesare MSD; D. Datele din MSD procesate sunt inserate în aplicaţia GIS 112 şi apoi în aplicaţia voce/date 112;
10. Datele recepţionate sunt transferate la dispeceratele judeţului de unde a fost generat apelul;
11. Fişa de caz cu date completate şi apelul sunt prezentate la operatorul de la agenţie; I. Operatorul de la agenţie solicită date VIN la modulul de procesare MSD; II. Modulul de procesare MSD solicită date VIN la modulul de decodare MSD.
Neclasificat
Neclasificat 6/15
Setul de date asociat unui apel eCall recepţionat şi afişat în fişa de caz a operatorilor / dispecerilor din sistemul de preluare dispecerizare apeluri respectă standardele europene în domeniu.
1.3. Descriere generală a subsistemului de localizare a apelurilor de urgenţă
După extragerea informaţiilor de localizare a apelantului recepţionate în cadrul semnalizării SS7, injectarea acestora în serverele de localizare actuale din SNUAU, se face redundant prin transmiterea către două servere de localizare dispuse geo-redundant în Bucureşti şi Braşov a unui mesaj RADIUS de tip AccountingRequest, care conţine:
a. Un id de sesiune unic; b. MSISDN; c. Informaţia de localizare (site id, sector id); d. Status-ul setat la “Start”; e. B-number.
Informaţiile recepţionate de către sistemul de localizare sunt inserate într-o bază de date şi în baza unui request de tip MLP (conform ultimei versiuni de standard) sunt furnizate spre aplicaţiile de procesare dispecerizare apeluri de urgenţă.
Neclasificat
Neclasificat 7/15
Cererile de localizare sunt în format MLP, iar informații detaliate cu privire la acestea vor fi puse la dispoziție furnizorului după intrarea în vigoare a contractului.
1.4. Subsistemul de comunicaţie cu resursele mobile de intervenţie medicală
Acest subsistem informatic integrat reprezintă o extensie SNUAU, care permite informatizarea proceselor operaţionale ce stau la baza acordării asistenţei medicale de urgenţă.
Din punct de vedere arhitectural se bazează pe o abordare mixtă fiind un sistem cu componente atât distribuite cât şi centralizate, conform schemei de mai jos:
Server Captere ISUP Server RADIUS Server DB
1: AccountingRequest
3: AccountingResponse
2: SQL INSERT
4: AccountingRequest
5: SQL UPDATE
6: AccountingResponse
Sistem localizare
Neclasificat
Neclasificat 8/15
Dimensionarea subsistemului este următoarea: • 1873 de resurse de intervenţie; • 68 de unităţi UPU; • 41 Servicii Judeţene de Ambulanţă; • 41 Dispecerate de Ambulanţă şi SMURD.
1.5. Interfeţe de comunicaţie interne/externe
1.5.1. Interfaţa de comunicaţie cu aplicaţiile de preluare şi dispecerizare apeluri
de urgenţă din cadrul Centrelor 112
Această interfaţă permite realizarea transferului bidirecţional de date între platformele de preluare şi dispecerizare urgenţe 112 utilizate în SNUAU. Prin implementarea acestei interfeţe se va asigura interoperabilitatea între sistemele informatice voce/date 112 existente şi sistemul informatic furnizat în cadrul proiectului precum şi interoperabilitatea la nivel operaţional între entităţile care exploatează sistemul informatic. Pentru asigurarea unor comunicaţii sincrone voce şi date între cele două sisteme informatice această interfaţa va trebui să respecte următorul flux tehnic şi operaţional:
a. La nivelul interfeţelor client voce/date 112, prin apelarea unui contact (asociat unui element din interfaţa client a aplicaţiei voce/date client) definit în prealabil în zona de administrare ca fiind de tip transfer interjudeţean se iniţiază un apel vocal;
b. În paralel cu apelul vocal sunt extrase datele din fişa de eveniment (conform unui profil de expediere pre-configurat în zona de administrare) şi sunt inserate într-o bază de date “tampon” (Microsoft SQL) existentă la nivel central (cu conexiuni de tip link server cu toate instanţele SQL din Centrele 112);
c. La preluarea apelului de către entitatea operaţională destinatară a apelului, aplicaţia client voce/date 112 verifică prin corespondenţă cu numărul de telefon recepţionat în Inbox, existenţă datelor de transfer interjudeţean în bază de date “tampon”;
d. În situaţia în care se identifică date, fişa de eveniment generată automat la preluarea apelului se va deschide pre-completată cu datele transmise de judeţul sursă;
e. După preluarea şi integrarea datelor de transfer interjudeţean, mecanisme special implementate în aplicaţia voce/date 112 destinaţie, va muta liniile corespunzătoare cazului respectiv în tabele istorice.
Fluxul tehnic şi operaţional de implementare a soluţiei de transfer interjudeţean va fi stabilit de comun acord între Achizitor și Furnizor în perioada de analiză în vederea implementării.
1.5.2. Interfaţa cu sistemul de comunicaţii cu resursele mobile de intervenţie
Această interfaţă dispusă la nivel central, în Centrul 112 Bucureşti-Ilfov, asigură transferul datelor colectate la nivel naţional din aplicaţiile 112, spre sistemul informatic de transmitere a urgenţelor către resursele mobile de intervenţie medicală (numit RM în continuare), pentru o gestionare mai eficientă a cazurilor de urgenţă. De asemenea interfaţa permite actualizarea stărilor resurselor de intervenţie prin accesarea distantă (la nivel judeţean) a unei proceduri stocate din sistemul voce/date 112 existent. Transferul de date 112 către sistemul RM se realizează astfel:
Neclasificat
Neclasificat 9/15
I. Soluţia tehnică de transmitere/actualizare misiuni, presupune expedierea unui mesaj XML către un server socket TCP/IP, cu posibilitatea de recepţionare pe aceeaşi conexiune a unui mesaj de confirmare tip ACK.
II. Fluxul pentru trimitere date din aplicaţia voce/date 112 către RM este:
aplicaţia voce/date 112 se conectează ca şi client socket TCP/IP la server socket TCP/IP (RM) şi expediază un XML. XML-ul va fi precedat de lungimea mesajului XML în format LE-BE pe 4 bytes. RM va confirma recepţionarea datelor transmiţând pe aceeaşi conexiune mesajul "xml receptionat".
Aplicaţia date-voce 112 deschide un server socket TCP/IP (pe ReplyIp+ ReplyPort) şi va declanşa automat actualizarea cazului 112 dacă va primii un XML dinspre RM.
Menţiune: Detalierea semnificaţiilor câmpurilor care compun XML-urile se va realiza în faza de implementare a interfeţei.
1.5.3. Interfaţa subsistem eCall aplicaţie 112
Integrarea datelor eCall la nivel de client (aplicaţie 112 / GIS) se face, la preluarea apelului eCall de către operatorul 112, de către clientul GIS prin interogarea, pe baza numărului de telefon al apelantului, a unor tabele cu informaţii MSD decodificate din baza de date a sistemului eCall. Se va avea în vedere că soluţia eCall prezintă redundanţă la nivel de site în centrele Bucureşti şi Braşov.
A. Interfaţa de comunicaţie dintre sistemul eCall cu aplicaţiile 112 şi GIS permite următoarele seturi de funcţionalităţi:
i. Preluare informaţii MSD prin interogare tabele cu informaţii MSD; ii. Transmitere cereri “Resend MSD” către echipamentele IVS; iii. Transmitere cereri “Clear down” către echipamentele IVS; iv. Interogare Eucaris pe baza VIN.
Transmiterea de comenzi eCall din aplicaţiile 112 şi GIS, se realizează prin apelarea unui web-service eCall.
Detalierea tabelelor cu informaţii MSD decodificate din baza de date a sistemului eCall, a comenzilor eCall transmise din aplicaţiile 112 şi GIS și schema WSDL a serviciilor vor fi puse la dispoziţia furnizorului în faza de analiză a proiectului.
B. În cadrul sistemului eCall actual este implementată şi interfaţa de publicare cazuri de urgenţă către CNAIR cu următoarele specificaţii:
transferul de date este realizat prin identificarea automată şi inserarea directă într-o bază de date, găzduită de un server specific din zona DMZ, în baza unor elemente declanşatoare de tipul categorii de evenimente şi agenţii, pre-configurabile (ex. inserare cazuri de Poliţie de tipul “Accidente rutiere”).
Neclasificat
Neclasificat 10/15
C. Interfaţa eCall TPSP
Această interfaţă permite transferul unidirecțional al informaţiilor de tip eCall MSD provenite de la un Centru de asistenţă rutieră - TPSP către PSAP-urile eCall responsabile. Practic, fluxul de gestionare al unui apel identificat drept urgenţă într-un centru TPS şi direcţionat către SNUAU la nivelul Centrului 112 Bucureşti/Braşov va respecta modul operaţional de gestionare a apelurilor eCall implementat în România.
eCall clasic şi eCall TPSP - Arhitectură generică.
Operatori telefonieTPSP
Apelare centru de asistență rutieră
Identificare urgență
Transfer date + apelare Centru 112
Apel vocal PSAP București(rută națională/internaționala)
Transfer date CAP
IP PUBLIC CU ASIGNARE STATICĂ
TELEKOM
STS BUCUREȘTI
DMZ CIC
IP PUBLIC CU ASIGNARE STATICĂFILTRARE IP + PORT
IPS (Intrusion Prevention System)
INTERFEȚE EXISTENTE CU TELEKOM (E1-ISDN, SS7)
FIREWALL DMZFORTIGATE 100d
FIREWALL 112FORTIGATE 500d
Internet Integrare dateConform soluție
de transfer interjudețean
Et. 6 + CIC
SERVER DMZSERVER EXPUNERE SERVICIU HTTPS
MAȘINA VIRTUALĂ SOFTSWITCH
PSAP B-IF
CTD MX-ONE
Arhitectura de interconectare TPSP - SNUAU Flux de lucru: În situaţia identificării de către un TPSP a unui apel de asistenţă rutieră ca fiind unul de urgenţă 112, vor trebui realizate următoarele acţiuni:
I. TPSP colectează datele eCall MSD de la IVS le completează cu alte date de interes în soluţionarea urgenţei şi le transmite (push) prin interfaţa dedicată HTTPS expusă la nivelul reţelei DMZ 112 către Centrul 112 Bucureşti/Braşov (eveniment de tip insert);
Neclasificat
Neclasificat 11/15
II. TPSP iniţiază apel de voce către PSAP 112 Bucureşti/Braşov şi, dacă i se solicită, asigură conferinţa audio între IVS (ocupanţii autovehiculului) şi PSAP 112 Bucureşti/Braşov. La preluarea apelului audio în Centrul 112 Bucureşti/Braşov, automat, în platforma SNUAU de preluare şi dispecerizare apeluri de urgenţă se generează o fişă de caz 112 pentru urgenţe eCall care se completează automat cu datele MSD primite la pasul I;
III. dacă se recepţionează date noi MSD pentru acelaşi IVS, TPSP le transmite (push) prin interfaţa dedicată către PSAP-ul 112 Bucureşti/Braşov (eveniment de tip update), iar în platforma SNUAU de preluare şi dispecerizare apeluri de urgenţă se generează o alertă (vizuală şi audio) care va indica faptul că există o actualizare a datelor MSD pentru un caz eCall în curs.
Descriere
I. Soluţia tehnică presupune apelare unui serviciu web tip proxy, găzduit în DMZ 112, conform următorilor paşi:
TPSP apelează metoda de autentificare a serviciului tip proxy (2 parametrii: utilizator+parolă administrate de către 112), proxy-ul verifică credenţialele şi dacă sunt corecte întoarce către TPSP un token generat intern, în caz contrar întoarce mesajul de eroare la autentificare;
TPSP apelează metoda de transmitere eveniment a serviciului tip proxy (2 parametrii: token, eveniment de tip insert/update pentru date eCall TPSP încapsulate în format CAP 1.2);
proxy-ul loghează, valideză, procesează şi inserează datele eCall TPSP încapsulate în format CAP 1.2, într-o bază de date MS SQL, de pe un server dedicat din centrul 112 Bucureşti/Braşov.
II. Datele necesare pentru apelarea serviciului web tip proxy vor fi puse la dispoziția furnizorului după intrarea în vigoare a contractului.
Menţiune: Schema WSDL a serviciului se va pune la dispoziţia TPSP după semnarea protocolului de colaborare cu S.T.S. Detalierea semnificaţiilor câmpurilor care compun XML-urile se va realiza în faza de implementare a interfeţei.
1.5.4. Interfaţă ARLS STS TETRA cu sistemul ARLS 112 existent
Această interfaţă permite transferul bidirecţional al informaţiilor de tip ARLS între sistemul ARLS STS TETRA şi sistemul ARLS 112 existent. Soluţia tehnică presupune conectarea sistemului ARLS 112 ca şi client socket TCP/IP la un server dedicat ARLS TETRA STS şi schimbul de date pe aceaşi conexiune, folosind comenzi ce vor fi detaliate în faza de implementare a proiectului.
1.5.5. Interfaţa SMS
În prezent în SNUAU, subsistemul SMS permite recepţionarea/transmiterea mesajelor scurte (de tip SMS de urgenţă, SMS de localizare, SMS alertare resurse) şi integrarea acestora în aplicaţiile de date 112 la nivel naţional.
Neclasificat
Neclasificat 12/15
Modul de funcționare al interfeței presupune:
recepţionarea unui SMS 113 în SNUAU, folosind un XML primit de către un server socket TCP/IP de la SMSC STS; actualizarea datelor de identificare a personelor cu dizabilităţi la nivel de client se face rulând o procedură stocată specifcă. Datele necesare pentru conectarea la socket server TCP/IP şi pentru conectarea la baza de date vor fi furnizate în etapa de analiză a proiectului.
recepţionarea mesajelor de localizare AML - Soluţia tehnică presupune inserarea datelor recepţionate prin SMS într-o bază de date centrală MS SQL din Centrul 112 Bucureşti, prin executarea unei proceduri stocate dedicate „AML_insert” de către un script existent la nivelul SMSC STS. De la nivel central datele sunt inserate în bazele de date aferente judeţului unde a fost recepţionat apelul prin corespondenţă cu numărul de telefon şi integrate în aplicaţiile 112.
transmiterea unui SMS 113 din SNUAU, se realizează trimiterea mesajului introdus de operator în interfața client 112 în format XML, către un web-service SMSC STS.
Menţiune: Schema WSDL a serviciului se va pune la dispoziţia furnizorului la momentul implementării interfeţei. Detalierea semnificaţiilor câmpurilor care compun XML-urile precum şi a câmpurilor rezultate ca urmare a rulării procedurii stocate, se va realiza în faza de implementare a interfeţei.
1.5.6. Interfaţa VoWiFi
Acestă soluţie asigură transferul unidirecţional de date de localizare istorică şi
amprenta de timp asociată provenite de la furnizorii de servicii de telefonie mobilă, către
aplicaţiile 112. Mesajele de localizare sunt transmise de reţeaua operatorului de origine
în situaţia în care apelantul nu are semnal în nici o reţea de telefonie mobilă dar are
acces la o conexiune WiFi internet. Operatorul de telefonie transmite identificatorul
ultimei celule în care a fost înregistrat terminalul apelantului şi amprenta de timp
asociată.
Interfaţa presupune recepţionarea unui XML de către un server socket TCP/IP (VoWiFi) pe un server dedicat din Centrul 112 Bucureşti-Ilfov şi apoi integrarea informaţiilor la nivel de aplicaţie client 112. Fluxul pentru trimitere date de la un furnizor de servicii de telefonie mobilă către aplicaţiile 112 este:
furnizorul de servicii de telefonie mobilă se conectează ca şi client socket TCP/IP la server socket TCP/IP (VoWifi) şi expediază un XML encodat UTF-8.
Menţiune: Detalierea semnificaţiilor câmpurilor care compun XML-ul se va realiza în faza de implementare a interfeţei.
Neclasificat
Neclasificat 13/15
1.5.7. Interfaţa transfer fişă de caz în format XML şi fişiere asociate
Interfaţa presupune extragerea automată a datelor aferente fişei de caz, a
înregistrărilor de sunet şi imaginea de localizare asociate acesteia, la declanşarea unui
eveniment operaţional configurabil (selectare index de caz, număr victime etc.) şi
copierea acestor informaţii într-o cale de reţea configurabilă.
Menţiune: Detalierea semnificaţiilor câmpurilor care compun XML-ul, fişierele asociate
precum şi elementele operaţionale declanşatoare se vor detalia în faza de analiză a
proiectului.
1.5.8. Interfaţa transfer fişă de caz Romatsa
Soluţia tehnică presupune expedierea unui XML conform unui profil de expediere
configurabil în zona de administrare, către un server socket TCP/IP (ROMATSA) în
situaţia unui incident aviatic. De asemenea, în interfaţa client 112, există un mecanism
de selectare a unei opţiuni de tipul caz real/caz de test (valoare inclusă în XML), utilizat
pentru a diferenţia cazurile reale de testele de verificare a funcţionării interfeţei.
Menţiune: Detalierea semnificaţiilor câmpurilor care compun XML-ul se va realiza în
faza de analiză a proiectului.
1.5.9. Interfaţa transfer fişă de caz aferente agenţiilor Poliţie, Jandarmi, ISU
către sistemul informatic central SIMIEOP
Acestă interfaţă asigură în timp real, transferul bidirecţional de date între aplicaţia 112 şi platforma SIMIEOP utilizată la nivel de structură centrală MAI (Bucureşti). Transferul de date 112 către SIMIEOP se va realiza în funcţie de următorii declanşatori:
A. Cazuistica obişnuită Pentru cazurile obişnuite, în momentul în care prima agenţie M.A.I. (Ministerul Afacerilor Interne - Poliţie, ISU-SMURD sau Jandarmi) crează o notă de caz, se transmite automat în SIMIEOP un “snapshot” cu datele care se aflau la momentul respectiv în baza de date. La închiderea cazului, se transmite un nou “snapshot” cu datele care se află în baza de date la momentul închiderii cazului.
B. Cazurile urgente Pentru cazurile urgente, din momentul în care prima agentie M.A.I. (Ministerul Afacerilor Interne - Poliţie, ISU-SMURD sau Jandarmi) apelează un contact specific, orice informaţie nouă din baza de date referitoare la cazul respectiv, se transmite automat în SIMIEOP până la finalizarea cazului, când se transmite un “snapshot” cu datele care se află în baza de date la momentul închiderii cazului. În zona de administrare există mapare între contact şi IP-ul + port-ul serverului SIMIEOP. Soluţia tehnică presupune expedierea unui XML către un server socket TCP/IP (SIMIEOP) cu posibilitatea de recepţionare pe aceaşi conexiune a unui alt tip de XML. Menţiune: Detalierea semnificaţiilor câmpurilor care compun XML-urile se va realiza în faza de analiză a proiectului.
Neclasificat
Neclasificat 14/15
Fluxul pentru trimitere date din aplicaţia 112 către SIMIEOP este:
aplicaţia 112 se conectează ca şi client socket TCP/IP la server socket TCP/IP (SIMIEOP) şi expediază un XML.
aplicaţia 112 va declanşa automat notificare asociată cazului 112 dacă va primi pe aceaşi conexiune un XML de confirmare dinspre SIMIEOP.
Structura mesajelor XML trimise între aplicaţia 112 și SIMIEOP va fi pusă la dispoziție în faza de implementare a proiectului.
1.5.10. Interfaţa de comunicaţie bidirecţională aplicaţie 112 cu SMISU la nivelul
fiecărui Centru 112
Acestă interfaţă asigură în timp real, transferul bidirecţional de date (mesaje XML) între aplicaţia 112 şi platforma SMISU utilizată la nivelul fiecărui judeţ de agenţia ISU. Soluţia tehnică presupune expedierea unui XML cu date aferente fişei de caz către un server socket TCP/IP (SMISU) şi recepţionarea pe aceeaşi conexiune a unui XML de închidere a fişei de caz. Menţiune: Detalierea semnificaţiilor câmpurilor care compun XML-urile se va realiza în faza de analiză a proiectului. Fluxul pentru trimitere date din aplicaţia 112 către SMISU este:
- Aplicaţia 112 se conectează ca şi client socket TCP/IP la server socket TCP/IP
(SMISU) şi expediază un XML. XML-ul va fi precedat de lungimea mesajului XML în format LE-BE pe 4 bytes.
- Aplicaţia 112 va declanşa automat finalizarea cazului 112 dacă va primi pe aceeaşi conexiune un XML dinspre SMISU. XML-ul va fi precedat de lungimea mesajului XML în format LE-BE pe 4 bytes.
Structura mesajelor XML trimise între aplicaţia 112 și SMISU va fi pusă la dispoziție în faza de implementare a proiectului.
1.5.11. Interfaţă de comunicaţie bidirecţională aplicaţie 112 cu aplicaţii de
dispecerizare medicală de tip Romsys
Interfaţă presupune expedierea unui XML cu date din fişa de caz către un server socket TCP/IP (Romsys) cu posibilitatea de recepţionare pe aceaşi conexiune a unui mesaj XML de închidere fişă de caz. Menţiune: Detalierea semnificaţiilor câmpurilor care compun XML-urile se va realiza în faza de implementare a interfeţei. Fluxul pentru trimitere date din Aplicaţia 112 către Romsys este:
Aplicaţia 112 se conectează ca şi client socket TCP/IP la server socket TCP/IP (Romsys) şi expediază un XML. XML-ul va fi precedat de lungimea mesajului XML în format LE-BE pe 4 bytes.
Aplicaţia 112 va declanşa automat finalizarea cazului 112 dacă va primii pe aceaşi conexiune un XML dinspre Romsys. XML-ul va fi precedat de lungimea mesajului XML în format LE-BE pe 4 bytes
Neclasificat
Neclasificat 15/15
Structura mesajelor XML trimise între aplicaţia 112 și Romsys va fi pusă la dispoziție în faza de implementare a proiectului.
2. Caracteristici tehnice ale echipamentelor terminale existente în
amplasamentele operaţionale care nu fac obiectul prezentului
proiect
2.1 Specificaţii hardware nr. crt.
tip terminal model monitor placă de
bază procesor RAM HDD placă video placă audio
1 HP EliteDesk 800G1 SFF
(cu 3x monitor)
HP EliteDisplay E221c
PN1: 725153-001 PN2: 725081-001
PN1: 796108-001
PN2: 717372-003
Intel Core i3-4160
(@3.6GHz)
4GB - DDR3 (@1600MHz)
SEAGATE (@500GB)
PN: 1BD142
Matrox M9138 LP
PN: M9138-E1024LAF
ASUS Xonar DX PN: 359280-00255
YAD060-A17
2 HP EliteDesk 800G1 SFF
(cu 2x monitor)
HP ProDisplay P201
PN1: 711302-001 PN2: 710981-200
PN1: 737728-001
PN2: 717372-002
Intel Core i3-4130
(@3.4GHz)
4GB - DDR3 (@1600MHz)
SEAGATE (@500GB)
PN: 1BD142
Nvidia NVS 315 (cu DMS-59) PN1: 720837-
001 PN2: 720625-
001
ASUS Xonar DSX PN: 252202-00282
YA0010-A16
3
HP Compaq Pro
6300 SFF (cu 2x monitor)
HP EliteDisplay E222
PN1: 820428-001 PN2: 820430-001
PN1: 657239-001
PN2: 656961-001
Intel Celeron G1610
(@2.6GHz)
2GB - DDR3 (@1333MHz)
TOSHIBA (@500TB)
PN: 9F13178
Nvidia NVS 315 (cu DMS-59) PN1: 720837-
001 PN2: 720625-
001
ASUS Xonar DX PN: 359280-00255
YAD060-A17
4
HP Compaq Pro
6300 SFF (cu 2x monitor)
HP EliteDisplay E222
PN1: 820428-001 PN2: 820430-001
PN1: 657239-001
PN2: 656961-001
Intel Celeron G1610
(@2.6GHz)
2GB - DDR3 (@1333MHz)
TOSHIBA (@500TB)
PN: 9F13178
Matrox M9148 LP
PN: M9148-E1024LAF
Onboard
5 HP ProDesk 600G1 SFF
(cu 3x monitor)
HP EliteDisplay E222
PN1: 820428-001 PN2: 820430-001
PN1: 795972-001
PN2: 739678-001
Intel Core i5-4570
(@3.2GHz)
4GB - DDR3 (@1600MHz)
SEAGATE (@500GB) PN: 1EJ062
Matrox M9148 LP
PN: M9148-E1024LAF
ASUS Xonar DSX PN: 252202-00282
YA0010-A16
6 HP ProDesk 600G1 SFF
(cu 2x monitor)
HP EliteDisplay E222
PN1: 820428-001 PN2: 820430-001
PN1: 795972-001
PN2: 739678-001
Intel Core i5-4570
(@3.2GHz)
4GB - DDR3 (@1600MHz)
SEAGATE (@500GB) PN: 1EJ062
Nvidia NVS 315 (cu DMS-59) PN1: 720837-
001 PN2: 720625-
001
ASUS Xonar DSX PN: 252202-00282
YA0010-A16
7 DELL Vostro 3900 series
(cu 2x monitor)
HP EliteDisplay E222
PN1: 820428-001 PN2: 820430-001
PN: 0T1D10 Intel Core i7-4790
(@3.6GHz)
8GB - DDR3 (@1600MHz)
TOSHIBA (@1TB)
PN: 0CW76M
GeForce GTX 475 (M302N) PN: 0TC2P0
ASUS Xonar DSX PN: 252202-00282
YA0010-A16
2.2 Specificaţii software
nr. crt.
tip terminal OS
1 HP EliteDesk 800G1 SFF(cu 3x monitor) Windows 7 Profesional (SP1 @64bit)
2 HP EliteDesk 800G1 SFF(cu 2x monitor) Windows 7 Profesional (SP1 @64bit)
3 HP Compaq Pro 6300 SFF(cu 2x monitor) Windows 7 Profesional (SP1 @64bit)
4 HP Compaq Pro 6300 SFF(cu 2x monitor) Windows 7 Profesional (SP1 @64bit)
5 HP ProDesk 600G1 SFF(cu 3x monitor) Windows 7 Profesional (SP1 @64bit)
6 HP ProDesk 600G1 SFF(cu 2x monitor) Windows 7 Profesional (SP1 @64bit)
7 DELL Vostro 3900 series(cu 2x monitor) Windows 7 Profesional (SP1 @64bit)
