CAIET DE SARCINI

Continut
1. Prezentarea Autoritatii Contractante............................................................................................3
2. Cadrul legal....................................................................................................................................4
3. Scopul proiectului..........................................................................................................................6
4. Obiectivele proiectului...................................................................................................................7
5. Cerinte generale............................................................................................................................8
5.1 Situatie existenta si dispozitii generale..................................................................................8
5.2 Arhitectura.............................................................................................................................8
5.2.1 Arhitectura de infrastructura.......................................................................................11
5.2.2 Arhitectura de comunicatii..........................................................................................11
5.2.3 Arhitectura hardware..................................................................................................14
5.2.4 Arhitectura software....................................................................................................14
5.2.5 Arhitectura de securitate.............................................................................................15
5.3 Servicii..................................................................................................................................16
5.3.1 Servicii management....................................................................................................16
5.3.2 Servicii implementare..................................................................................................18
5.3.3 Servicii suport, mentananta si garantie........................................................................25
5.3.4 Instruire.......................................................................................................................30
6. Cerinte functionale......................................................................................................................33
6.1 Capabilitati generale ale sistemului SIA 112........................................................................36
6.2 Comunicatii..........................................................................................................................36
6.2.1 Funcție de preluare apeluri..........................................................................................38
6.2.2 Sistemul de comunicatii vocale va fi compus din urmatoarele componente...............42
6.2.3 Managementul sistemului de comunicatii...................................................................49
6.2.4 Solutia de supravieturire..............................................................................................50
6.3 Managementul cazurilor de urgenta...................................................................................53
6.3.1 Clasificarea Incidentelor...............................................................................................56
6.3.2 Suport pentru interviu.................................................................................................58
6.3.3 Jurnalizare....................................................................................................................58
6.3.4 Regasire evenimente...................................................................................................59
6.3.5 Monitorizare desfasurare interventie..........................................................................59
6.3.6 Aplicatie unica de tip Administrator.............................................................................60
6.4 Platforma informational-geografica.....................................................................................61
6.4.1 Aplicația GIS specializata pentru managementul situatiilor de urgenta.......................63
 6.5 Managementul identitatii, autentificare, autorizare............................................................81
7. Cerinte non-functionale...............................................................................................................82
7.1 Infrastructura Software........................................................................................................82
7.1.1 Sistemul de virtualizare................................................................................................82
7.1.2 Sistemul de operare.....................................................................................................83
7.1.3 Sistemul de baze de date.............................................................................................85
7.1.4 Sistemul de integrare si preluare date.........................................................................86
7.1.5 Sistemul de securitate..................................................................................................87
7.1.6 Sistemul de management si monitorizare infrastructura.............................................98
7.1.7 Sistemul de audit.......................................................................................................100
7.2 Infrastructura hardware....................................................................................................107
7.2.1 Sistemul de procesare................................................................................................107
7.2.2 Sistemul de stocare....................................................................................................113
7.2.3 Sistemul de sustinere si protectie..............................................................................118
7.3 Infrastructura de retea......................................................................................................122
7.3.1 Sistemul Core Data Center Switch.............................................................................123
7.3.2 Extensie Core Data Center Switch..............................................................................125
7.3.3 Layer 3 aggregation switch........................................................................................126
7.3.4 Layer 2 access switch.................................................................................................127
7.3.5 Sistemul Internet routing și Voice gateway................................................................130
7.3.6 Sistemul WAN routing................................................................................................134
7.3.7 Sistemul de securitate................................................................................................137
7.3.8 Sistemul Telefonie IP-PBX..........................................................................................140
7.3.9 Terminale Voce..........................................................................................................144
7.3.10 Sistemul de balansare................................................................................................145
7.3.11 Sistem de comunicații backup....................................................................................147
8. Cerinte privind oferta tehnica....................................................................................................149
9. Considerente generale..............................................................................................................151
10. Capabilitatile solutiei ofertate...............................................................................................152
 1. Prezentarea Autoritatii Contractante
Guvernul a susținut în ședința de miercuri, 17 februarie 2016, pachetul de proiecte
prezentat de Ministerul Tehnologiei Informației și Comunicațiilor, care au ca scop
crearea bazei legislativ-normative pentru instituirea serviciului apelurilor de urgență.

Astfel în Moldova va fi lansat Serviciul Unic al Apelurilor de Urgență de model

european 112.

Serviciul 112 va fi organizat ca o structură aparte, cu statut de instituţie publică și va

funcționa în baza alocaţiilor din bugetul de stat, mijloacele extrabugetare și din
fondurile donatorilor.

Crearea Serviciului de Urgență 112 este o prevedere a Acordului de Asociere cu

Uniunea Europeană. Prin apelarea gratuită a unui singur număr 112, 24 din 24 ore
vor putea fi accesate trei servicii: de poliţie, pompieri si asistenţă medicală de
urgenţă.

Coordonate de contact:

Serviciul Național Unic pentru Apeluri de Urgență 112, Adresa: mun.Chișinău

str.Stefan cel Mare 134, bir. 315, Telefon: +373 22-25-11-98, Email:
office@112.md
 2. Cadrul legal
Cadrul legal este asigurat de o serie de legi si hotarari de guvern ce reglementeaza
modul de funtionare si organizare a instituiei.

 Legea nr.174 din 25 iulie 2014, cu privire la organizarea și funcționarea

Serviciului național unic pentru apelurile de urgență 112.
 H.G. nr .241 din 3 martie 2016, cu privire la aprobarea Programului național
privind implimentarea Serviciului național unic pentru apelurile de urgență
112.
 H.G.nr .242 din 3 martie 2016, cu privire la aprobarea Regulamentului privind
organizarea și funcționarea Comitetului coordonator interdepartamental pentru
asigurarea interacțiunii dintre Serviciul Național Unic pentru Apelurile de
Urgență 112 și serviciile specializate de urgență.
 H.G. nr.243 din 3 martie 2016, cu privind crearea Serviciului Național Unic
pentru Apelurile de Urgență 112.
 H.G. nr.244 din 3 martie 2016, cu privire la aprobarea Conceptului tehnic al
Sistemului informațional automatizat al Serviciului național unic pentru
apelurile de urgență 112.
 Legea nr.241-XVI din 15 noiembrie 2007 cu privire la comunicațiile
electronice.
 LEGE Nr. 133 din 08 iulie 2011 privind protecţia datelor cu caracter personal

Totodata, in vederea realizarii si livrarii unui serviciu de inalta calitate institutia are
in vedere asigurarea cadrului respectarii directivelor, standardelor si reglementarilor
internationale in domeniu acestea fiind stipulate in urmatoarele documente:

Directive:

 Directiva 98/10/EC, care stipulează garantarea apelării gratuite a serviciilor

de urgenţă prin intermediul numărului 112;
 Directiva 2002/22/EC (cunoscută ca Directiva Serviciului Universal), care
oferă drepturi legate de utilizarea serviciului universal în reţelele de
comunicaţii electronice şi stipulează obligaţia statelor membre ale UE de a
asigura localizarea apelurilor de urgenţă, pentru a permite găsirea în timp util
a victimelor.

Standarde și reglementări:

 Reglementarea tehnică “Procesele ciclului de viata al software-lui” RT

38370656-002:2006;
 Standardul Republicii Moldova SM ISO/ CEI/IEEE 15288:2015 “Ingineria
sistemelor și software-ului. Procesele ciclului de viață al sistemului”;
 Standardul Republicii Moldova SM ISO/ CEI 12207:2014 “Ingineria sistemelor
și software-ului. Procesele ciclului de viață al software-ului”;
 SM ETSI TR 102 410 V1.1.1:2014 “Comunicații de urgență(EMTEL). Cerinţe
de bază pentru comunicaţii între persoanele fizice şi între persoane fizice şi
autorităţi în timpul situaţiilor de urgenţă în curs de desfăşurare”;
 SM ETSI TS 102 181 V1.2.1:2014 “Comunicaţii de urgenţă (EMTEL). Cerinţe
pentru comunicaţii între autorităţi/ organizaţii în timpul situaţiilor de urgenţă”;
 SM ETSI TS 102 182 V1.4.1:2014 “Comunicaţii de urgenţă (EMTEL). Cerinţe
pentru comunicaţii între autorităţi/ organizaţii şi persoane fizice, grupuri sau
publicul larg în timpul situaţiilor de urgenţă”.
 3. Scopul proiectului
In cadrul proiectului se are in vedere crearea și dezvoltarea infrastructurii de
comunicații a SIA in vederea asigurarii functionalitatilor necesare Serviciului Național
Unic Pentru Apelurile de Urgență 112.
 4. Obiectivele proiectului
Crearea Serviciului 112 în Republica Moldova urmăreşte realizarea obiectivelor:
• creşterea nivelului de securitate şi protecţie a populaţiei pe întreg teritoriul
Republicii Moldova, prin asigurarea accesului la serviciile de urgenţă în
conformitate cu reglementările şi standardele Uniunii Europene;
• reducerea numărului persoanelor decedate şi accidentate şi diminuarea
pagubelor provocate de situaţiile de urgenţă;
• simplificarea modalităţii de accesare a serviciilor de urgenţă prin organizarea
serviciilor specializate de urgenţă conform principiului „ghişeului unic”, ce va
permite apelarea unui număr naţional unic în cazul situaţiilor de urgenţă;
• promptitudinea reacţionării la diferite situaţii de urgenţă, care prezintă pericol
pentru viaţă, sănătate sau bunuri;
• organizarea interacţiunii şi cooperării eficiente a serviciilor specializate de
urgenţă;
• asigurarea unui spaţiu informaţional, tehnologic şi de comunicaţii integrat
pentru sporirea eficienţei serviciilor specializate de urgenţă;
• crearea unui instrument eficient de colectare, procesare şi păstrare a datelor
privind reacţia la apelurile de urgenţă;
• reducerea considerabilă a numărului de apeluri false şi abuzive, precum şi
fraudarea datelor privind nivelul de intervenţie a serviciilor specializate de
urgenţă.
Prevederile hotărîrii de Guvern se referă la crearea Instituţiei Publice “Serviciul
Naţional Unic pentru Apelurile de Urgenţă 112”, aprobarea Regulamentului privind
organizarea şi funcţionarea Serviciului 112 şi a Structurii Serviciului 112.
Regulamentul privind organizarea şi funcţionarea Serviciului 112 reglementează:
principiile de activitate, funcţiile, atribuţiile şi drepturile, organizarea activităţii,
patrimoniul, reorganizarea şi dizolvarea Instituţiei.
 5. Cerinte generale
5.1 Situatie existenta si dispozitii generale

In cadrul proiectului se are in vedere asigurarea mijloacelor tehnice si a resurselor

necesare in vederea funtionarii Serviciului Național Unic Pentru Apelurile de Urgență
112. In acest sens, autoritatea contractanta pune la dispozitia proiectului doua locatii
distincte ce vor acomoda cele doua centre ale Serviciului Național Unic Pentru
Apelurile de Urgență 112. Totodata, autoritatea contractanta, prin protocoalele
incheiate, va pune la dispozitia proiectului, legaturile primare de date si voce
asigurate de principalul furnizor de servicii de acest tip din Moldova, Moldtelecom.
Obligatiile ofertantului includ amenajarea celor doua centre, asigurarea dotarilor
mentionate in prezenta documentatie de atribuire, incluzand amenajarea posturilor de
lucru incluzand echipamentele de voce (casti, telefoane etc), birouri ergonomice,
scaune ergonomice, etc. Totodata se va include cablarea celor doua centre,
montarea panourilor de electricitate si a elementelor adiacente, asigurarea legaturii
comunicatii de date secundare (intre cele doua centre) dar si amenajarea spatiilor
auxiliare. De asemenea, se va lua in calcul instalarea si implementarea unei solutii
integrate de control acces care sa includa toate echipamentele si accesoriile
necesare.
In vederea asigurarii transparentei si pentru ca ofertantii sa poata intelege si evalua
in detaliu sistuatia actuala, ofertantii pot programa o vizita in cele doua locatii.

5.2 Arhitectura

Sistemul de preluare si procesare apeluri, gestionare evenimente va fi compus din

cel putin urmatoarele elemente:

o Hardware de tip server (fizic/virtual) pentru:

 Logica aplicaţiei
 Baze de date
 Comunicaţii
 Stocare inregistrari si arhivare
 Platforma GIS
 Gestiune logica a resurselor si acces in sistem
 Platforma de interoperabilitate
o Hardware de tip staţii de lucru, monitoare, tastaturi si console pentru
Operatori si Dispeceri;
o Aplicaţie informatică pentru gestionarea apelurilor de urgenţă, voce şi
date
 o

Sistemul va trebui sa implementeze:

 O arhitectura fara puncte critice unice de defect („single point of

failure”);
 Disponibilitate de 99,999% asigurata la nivel de serviciilor de preluare si
management al apelurior de urgență 112
 Arhitectura modulara, care să permită atat flexibilitate in alegerea
tehnologiilor pentru asigurarea functionalitatilor critice, cat si integrarea
facila a acestora;
Arhitectura sistemului trebuie sa fie una care sa asigure redundanta la nivelul
sistemului si autonomia ad-hoc la nivel de centru de date, in conformitate cu cerinta
de disponibilitate a serviciului, enuntata mai sus.

In vederea asigurarii unei implementari rapide, ce are la baza solutii mature si

stabile, sistemul propus trebuie sa includa solutii de tip COTS, solutii ce confera
avantajul unor implementari anterioare, care au fost rulate in medii de productie si
care in mare masura au demonstrat funtionarea in mediu real.

Singurele dezvoltari ce vor fi admise sunt cele legate de interoperabiltatea cu alte

sisteme externe, cu care SNUAU 112 se interconecteaza:

- Managementul Situatiilor de Urgenta al MAI - pentru informatiile asociate

evenimentelor de urgenta, in vederea dispecerizarii
- Operatorii Telecom – pentru preluarea datelor ANI/ALI
- Resursele informaționale de stat(CRIS Registru, IS Cadastru ș.a.)

In vederea asigurarii dovedirii capabilitatilor sistemului propus, ofertantii trebuie sa

prezinte un sistem in operare activa de serviciu 112.

5.2.1 Arhitectura de infrastructura

Sistemul integrat 112 va trebui sa beneficieze de o infrastructura ce poate asigura, in
caz de necesitate, funtionarea sistemului in mod independent de mediul exterior pe o
durata de 72 ore. In acest sens, in oferta se vor include toate echipamentele si
serviciile necesare atingerii acestui deziderat.
Acestea trebuie sa includa, fara a se limita la acestea, cel putin urmatoarele:

• sistem de generatoare de enegie electrica dimensionat pentru a suporta

necesarul specific de putere al fiecarui centru
• sisteme de tip “sursa neinteruptibila de curent”
• sistem de supresie foc
• sistem alternativ de comunicatie intre centre

In cadrul ofertei se vor prezenta toate componentele incluse, calculele de autonomie,

masurile de automatizare si schema conceptuala a acestui sistem, evidentiind toti
parametrii esentiali ai infrastructurii.

5.2.2 Arhitectura de comunicatii

Arhitectura de comunicatii propusa va include redundandata atat la nivel de
echipamente cat si la nivel de cai de comunicatii, restaurarea in caz de defect
efectuandu-se fara intreruperea functionarii Serviciului 112. Din punct de vedere a
arhitecturii de date sistemul trebuie sa includa mecanisme de transfer ce asigura
confidentialitatea datelor oferind capabilitati de vehiculare date peste canale de
comunicatie in mod privat. In cele ce urmeaza se ofera o viziune de principiu a
schemei de date din cadrul sistemului.

Tehnologia inclusa in oferta trebuie sa asigure nu numai redundanta sistemului de

voce, ci si o comutare automata in caz de defect. Solutia oferita trebuie sa asigure
interconectarea directa, cu comutare automata, cu prinicpalii trei operatori telecom
(Moldtelecom, Orange si Moldcell), precum si o interconectare prin intermediul cel
putin a unui operator de tranzit pentru restul furnizorilor de servicii telecom.
Se va avea in vedere realizarea unei configuratii de inalta disponilitate, la nivelul
arhitecturii de comunicatii, care sa asigure indeplinirea cerintei de disponibilitate a
serviciului 112.

In ceea ce priveste arhitectura de voce, aceasta va oferi cel putin elementele

evidentiate in urmatoarea schema:

ofertantul avand obligatia de a exlica modul in care acesta va realiza concret aceasta
arhitectura, indicand propria viziune, dar si toate elementele incluse in aceasta.

Pentru a inlesni activitatea operatorilor de telefonie 112 si pentru a conduce la

reducerea timpului in care apelurile de urgenta sunt tratate, arhitectura va presupune
existenta console unice pentru acesti operatori, utilizabila prin intermediul unor casti
telefonice, tastatura si mouse de calculator, pentru toate tipurile de comunicatii
(telefonie fixa si mobile, Tetra, Analogic). Operatorii trebuie sa nu foloseasca alte
terminale pentru a comunica in alte retele. Singura exceptie permisa este in situatia
aparitiei unui deranjament, moment in care cand apelurile vor putea fi preluate prin
intermediul unui terminal de tip telefon fix.

In cadrul acestei sectiuni se vor oferi schemele de comunicatie in cadrul sistemului

atat in interiorul centrului de date cat si intre cele doua centre. Se vor oferii detalii
privind modalitatile de asigurare a redundantei comunicatiilor, evidentiindu-se
tipurile, canalele si protocoalele de comunicatie utilizate. Totodata se vor evidentia
modalitatile de automatizare a proceselor de comutatie intre canalele de comunicatie
si potentialii declansatori ce pot fi configurati in acest sens.

5.2.3 Arhitectura hardware

Arhitectura hardware va prezenta mecanisme de asigurarea disponibilitatii la acest
nivel, implementand capacitati de procesare cu redundanta la nivelul fiecarui centru
dar si capabilitati de preluare a intregii sarcini de procesare de catre oricare din cele
doua centre. Toate echipamentele de calcul centralizat (serverele, storage-ul,
echipamentul de backup, echipamentele de interconectare) vor fi instalate si
configurate sau vor propune componente de redundata, incluzand mecanisme atat
automate cat si manuale de preluare a incarcarii, care sa asigure o disponibitate a
serviciului 112, in conformitate cu cerinta de la capitolul 5.2.

La nivel client, fiecare post de lucru trebuie sa aibe la dispozitie capabilitati de

procesare suficiente in vederea asigurarii funtionarii in parametrii de disponibilitate a
serviciului 112, in conformitate cu cerinta de la capitolul 5.2.

In cadrul sistemului se vor lua in considerare dotarea fiecarui centru cu un numar de

15 posturi de lucru (call takers) si 15 posturi instruire si asigurarea unei rezerve de
30% pentru posturile de lucru ( 4 posturi ). Pentru acestia se va asigura un mediu de
lucru optim ce include climatizare eficienta, ambianta fara perturbatii sonore (fara
echipamente de procesare in sala de productie) si posturi de lucru ergonomice.

In cadrul sistemului se vor lua in considerare dotarea fiecarui serviciu specializat cu

un numar total de 36 posturi de lucru (call takers) distribuite în patru centre
regionale si asigurarea unei rezerve de minim 10% pentru posturile de lucru ( 4
posturi ). De asemenea, sistemul va pune la dispozitie un mecanism de realizare de
copii de date pe fiecare nivel (procesare centralizata si/sau echipament de tip client)
astfel incat in caz extrem, sa se poata realiza activitati de recuperare si repunere in
functiune a unui post de lucru chiar si dupa aceste cazuri.

5.2.4 Arhitectura software

Arhitectura software propusa va trebui sa fie una modulara si stratificata in vederea
asigurarii funtionarii continue a diverselor module prin asigurarea reutilizarii
acestora. Totodata, se asigura capabilitati facile de dezvoltare si augmentare a
solutiei implementate prin mecanisme simple de mentenanta evolutiva precum
adaugarea de module functionale.

Arhitectura va respecta principiile SOA (Service Oriented Architecture) in vederea

asigurarii unei capacitati de modularizare si interconectare facila.

Arhitectura software va implementa de asemenea capabilitati de asigurare a

disponibilitatii incluzandu-se mecanisme de preluare a sarcinii in cazul in care una
din instantele software de procesare intra in avarie.
 5.2.5 Arhitectura de securitate
Arhitectura de securitate va trebui sa respecte principiile de securitate indicate de
modelul “defense in depth”. Astfel, sistemul de securitate trebuie sa includa
mecanisme de securitate pe toate palierele si nu se limiteaza la:

- Securitate fizica – acces fizic reglementat la nivel de individ

- Securitate la nivel de retea – acces reglementat la nivel de individ,
echipament sau rol, mecanisme de filtrare, detectie si preventie intruziune,
antivirus si antimalware, whitelisting si audit trail
- Securitate la nivel de servere – sisteme de operare, aplicatii si baze de date
- Securitate la nivel de puncte de lucru – statii de lucru, imprimante,
echipamente mobile
- Securitatea la nivel de comunicatii – comunicatiile vor fi securizate prin
proceduri reglementate si protocoale acceptate la nivel international.
- Securitatea la nivel institutional – Reglementat prin legislatie, politici,
proceduri interne, regulamente interne, fisa postului.

Astfel, sistemul propus trebuie sa includa o abordare multistrat cu mecanisme de

filtrare si reglementare acces si cu capabilitati de detectie si prevenire a accesului
neautorizat. Totodata sistemul trebuie sa includa mecanisme de detectie a
vulnerabilitatilor si remediere a acestora. Sistemul va include module de
monitorizare, audit si corelare evenimente, aceastea avand rolul de a asigura
capabilitati de verificare, interventie proactiva si reactiva in vederea realizarii unui
management optim.

In vederea asigurarii trasabilitatii si cursivitatii informatiei stocate, sistemul va fi

prevazut cu mecanisme de asigurarea sincronizarii timpului. Acestea vor include cel
putin urmatoarele:

- ceas atomic, care sa asigure sincronizarea de timp a tuturor elementelor din

solutia tehnologica.
- Un sistem unic de jurnalizare a actiunilor realizate de catre operatorii 112 in
cadrul SNUAU 112, precum si evenimentelor externe care au impact in
progresul actiunilor de rezolvare a incidentelor.

In acest sens oferta va include o descriere detaliata a sistemului cu evidentierea

tuturor mecanismelor si uneltelor de securitate, modul in care acestea concura la
asigurarea secutitatii sistemului si modul in care acestea elimina riscurile de
securitate. In vederea respectarii legislatiei in vigoare si anume a legii Nr. 133 din
08 iulie 2011 privind protecţia datelor cu caracter personal, solutia ofertată va
urmari standardele de securitate informationala recunoscute international si nu se va
limita la:

SR ISO/CEI 27001:2006: Tehnologia informaţiei. Tehnici de securitate. Sisteme de

management al securităţii informaţiei.

SR ISO/CEI 27002:2008: Tehnologia informaţiei. Tehnici de securitate. Cod de bună

practică pentru managementul securităţii informaţiei
ISO/IEC 27005:2008: Information technology – Security techniques – Information
security risk management

ISO/IEC 27007:2011: Information technology -- Security techniques -- Guidelines

for information security management systems auditing

ISO/IEC TR 27008:2011 Information technology -- Security techniques --

Guidelines for auditors on information security controls

5.3 Servicii

Aceasta sectiune descrie specificatiile minime in ceea ce priveste modalitatea de

livrare a serviciilor, tipul acestora si reglementeaza modul in care Autoritatea
considera ca trebuie derulate activitatile in cadrul proiectului.
5.3.1 Servicii management
Activitatea de management de proiect trebuie să se desfăşoare conform unui cadru
(framework) de management de proiect recunoscut internațional de către organisme
profesionale specifice de Project Management.

Ofertantul trebuie să prezinte în cadrul propunerii tehnice descrierea detaliată a

metodologiei proprii de management de proiect pe care o va utiliza în cadrul
proiectului.

Ofertantul trebuie să prezinte în cadrul propunerii tehnice planul de proiect pentru

prestarea serviciilor pe toată durata contractului. Planul de proiect trebuie să conţină
toate activitățile precum și etapele/subetapele determinante de realizare a
activităţilor, dependențele dintre activități, jaloanele de proiect (milestones),
rezultatele activităților și alocarea resurselor în vederea prestării serviciilor ofertate
astfel încât să fie atinse obiectivele proiectului. Ofertantul trebuie să propună planul
de proiect cât mai detaliat posibil și să răspundă cerințelor de etapizare şi înscriere în
termenele de realizare ale proiectului. În perioada de inițiere a proiectului, ulterior
semnării contractului, planul de proiect poate fi modificat doar cu aprobarea
Beneficiarului.

Implementarea întregului sistem trebuie să acopere următoarele:

o Analiza;
o Proiectare;
o Dezvoltare/configurare inclusiv testare internă;
o Implementare (deployment);
o Testare și teste de acceptanţă;
o Intrarea în producție;
o Asistenta operationala post implementare;
o Asistenta tehnica si suport.

Planul care va fi prezentat împreună cu oferta trebuie să acopere toate tipurile de

activități menționate mai sus.
Ofertantul trebuie să prezinte în cadrul propunerii tehnice modalitatea în care se va
realiza raportarea progresului pentru activităţile din cadrul proiectului. Se va detalia
modul de raportare în ceea ce priveşte intervalele de raportare, formularele folosite,
conţinutul informaţional al raportării precum şi circuitul de aprobare al raportărilor
de progres.

Ofertantul trebuie să prezinte în cadrul proiectului modalitatea prin care se va realiza

comunicarea între participanţii la proiect.

Ofertantul va prezenta în cadrul propunerii tehnice modul în care se va gestiona

rezolvarea problemelor care pot să apară pe parcursul proiectului. Se va descrie
procesul de management al problemelor şi formularele care vor fi utilizate pentru
managementul problemelor, escaladarea şi rezolvarea acestora.

Ofertantul va prezenta în cadrul propunerii tehnice planul de acceptanţă care va fi

utilizat în cadrul proiectului pentru recepţiile/acceptanţele parţiale şi
recepţia/acceptanţa finală. Se va prezenta planul împărţit pe etape precum şi
formularele aferente recepţiilor/acceptanţelor parţiale şi recepţiei/acceptanţei finale.

Ofertantul va prezenta în cadrul propunerii tehnice şi modalitatea de tratare a

schimbărilor în cadrul proiectului. Se va prezenta procedura de management al
schimbărilor precum şi formularele care vor fi utilizate în cadrul acestui proces pe
durata proiectului.

Având în vedere complexitatea şi durata proiectului, ofertanţii trebuie să ia în

considerare necesitatea prestării unui număr corespunzător de zile-om pentru
activităţile proiectului prin alocarea experților necesari. În vederea atingerii
obiectivelor proiectului, prestatorul poate suplimenta numărul de resurse alocat
activităților pe perioada derulării proiectului.

Pentru a asigura vizibilitate cât mai rapid asupra soluţiei Beneficiarului, respectiv
pentru a permite Beneficiarului monitorizarea şi controlul eficient asupra modului de
derulare a proiectului, abordarea de implementare trebuie să fie una iterativă, bazată
pe feedback şi ajustare din mers a soluţiei tehnice.

5.3.2 Servicii implementare

Analiza si proiectare
Rolul principal al fazei de analiză este de a înţelege corect nevoile utilizatorilor
înainte de proiectarea şi implementarea unui sistem care să le îndeplinească.

În vederea implementării sistemului, Prestatorul va trebui să execute activităţi de

analiză care să asigure premizele unei implementări eficiente. Informațiile care stau
la baza procesului de analiză sunt:

o Contractul, pentru termene şi condiţii;

o Caietul de sarcini şi propunerea tehnică, pentru aria de acoperire a
proiectului;
o Cerinţele clientului colectate şi evaluate în timpul acestei faze.

Beneficiarul va acorda tot sprijinul necesar pentru înțelegerea cât mai bună și
completă a contextului în care va fi implementat sistemul.
Ofertanții trebuie să descrie în detaliu metodologia după care vor derula activitățile
de analiză în cadrul propriei organizații.

Ofertanții trebuie să prezinte detaliat livrabilele care vor rezulta în urma prestării
serviciilor corespunzătoare etapei de analiză. Descrierea trebuie să conțină cel puţin
următoarele informații:

o formularul/formularele care vor fi utilizate pentru fiecare livrabil;

o descrierea conținutului fiecărui livrabil;
o modul în care va fi interpretat conținutul livrabilelor.

Analiza se va efectua după caz la sediul Beneficiarului sau la Prestator şi va avea ca

finalitate un pachet de specificaţii funcţionale agreat de comun acord cu acesta.

Serviciile de analiză vor acoperi cel puțin următoarele aspecte:

o Analiza contextului existent;

o Înţelegerea structurii organizatorice a Beneficiarului;
o Analiza situației din momentul de faţă din cadrul instituției
Beneficiarului prin ședințe de analiză, chestionare etc. Se vor identifica
procesele operaţionale (la nivelul organizaţiei) care vor fi impactate
prin implementarea soluţiei proiectului;
o Identificarea nevoilor şi neajunsurilor din cadrul sistemului existent pe
care instituția dorește să le rezolve prin realizarea acestui proiect. Prin
aceasta se va avea în vedere înţelegerea în detaliu a obiectivelor
generale şi specifice ale proiectului;
o Definirea cerințelor informaționale pentru noul sistem ca urmare a
analizei sistemului existent. Se va contura astfel, imaginea viitorului
sistem informaţional prin stabilirea proceselor operaţionale care să
precizeze participanţii, momentul intervenţiei acestora, locaţia sau
contextul, modalitatea de intervenţie şi informaţia procesată. Pentru
prezentarea proceselor operaţionale se vor utiliza instrumente de
modelare a proceselor şi activităţilor în conformitate cu standarde de
modelare şi reprezentare recunoscute (UML sau echivalent);
o Stabilirea actorilor de business care vor interacţiona în viitorul sistem;
o Se vor evidenţia activităţile care urmează a fi automatizate dacă este
cazul, astfel încât să se identifice clar funcţiile viitorului sistem
informatic şi modul în care acesta va ajuta la îndeplinirea obiectivelor
proiectului;
o La realizarea imaginii viitorului sistem, se vor avea în vedere sistemele
informatice existente, dacă este cazul, care vor conlucra la îndeplinirea
obiectivelor proiectului, indiferent dacă acestea sunt interne sau
externe organizaţiei Beneficiarului. Se vor avea în vedere volumul și
frecvenţa interacţiunilor de integrare între sisteme.

Rolul principal al fazei de proiectare este de a descrie la un nivel suficient de detaliu

sistemul care urmează a fi implementat.
În vederea implementării sistemului, Prestatorul va trebui să execute activităţi de
proiectare care să asigure premizele unei implementări eficiente.

Proiectarea sistemului dorit, care va contine detalierea la nivel tehnic a cerințelor şi

specificațiilor rezultate din activitatea de analiză pentru toate nivelurile şi
componentele sistemului care va fi realizat:

o Arhitectura de sistem – va prezenta cel puţin următoarele niveluri:

hardware, comunicaţii, componente software instalate (sisteme de
operare, produse COTS), arhitectura logică cuprinzând descrierea
componentelor de sistem, a celor dezvoltate sau personalizate și
caracteristicile funcţionale şi non-funcţionale ale acestora;
o Scenarii (cazuri) de utilizare – din care să reiasă modul de utilizare a
sistemului informatic din perspectiva utilizatorului final, modul în care
utilizatorii interacţionează cu sistemul, în corespondenţă directă cu
activităţile menţionate în cadrul proceselor operaţionale ale acestor
utilizatori. Scenariile de utilizare trebuie să cuprindă şi interacţiunile cu
sistemele externe, astfel încât să fie evidenţiat exact modul în care
este fructificată o integrare la nivel de sistem informatic. De asemenea,
scenariile de utilizare vor fi însoţite de o listă a actorilor sistemului şi
maparea acestora cu actorii de business. Pentru prezentarea cazurilor
de utilizare se vor folosi instrumente in conformitate cu standarde de
modelare şi reprezentare recunoscute (UML sau echivalent);
o Modelul de securitate – la nivel logic (organizarea pe roluri, grupuri,
drepturi, poziţia în structura organizatorică etc.) şi la nivel fizic
(servere, comunicaţii, aplicaţii etc.);
o Integrările la nivel de componentă software – pentru fiecare
interacţiune se va specifica sistemul sursă/destinaţie, modalitatea de
implementare, canal de comunicare, setul şi structura de date
transferate, reguli specifice de validare etc);

Proiectarea sistemului trebuie să ofere o soluţie optimă, urmărindu-se uşurinţa şi

eficienţa realizării şi implementării soluției, în cadrul restricţiilor de ordin tehnic,
organizatoric sau financiar. În procesul de proiectare, implicarea Beneficiarului este
esenţială în confirmarea cerinţelor informaţionale şi a priorităţilor din organizaţie,
realizându-se în acest mod înţelegerea şi pregătirea pentru acceptanţa noului sistem.
De aceea, este esenţial ca Prestatorul să comunice frecvent cu echipa Beneficiarului
pe tot parcursul derulării proiectului.

Documentul/documentele de specificații, rezultate în urma activităților de analiză şi

proiectare, vor descrie soluția în detaliu, vor conține informaţii privind toate
funcţionalităţile necesare şi vor sta la baza stabilirii şi realizării testelor de
acceptanţă.

În urma activităților de analiză și proiectare, pentru a se obține un sistem final

operațional se vor desfășura activități de dezvoltare, configurare, testare şi
implementare (deployment).
Dezvoltare/configurare si testare interna
Ofertanții trebuie să descrie în detaliu metodologia după care vor derula activitățile
de dezvoltare/configurare şi testare internă şi vor demonstra integrarea acestor
proceduri cu procedurile de analiză şi proiectare.

Ofertanții trebuie să prezinte împreuna cu oferta procedurile de

dezvoltare/configurare şi testare internă implementate în cadrul propriei organizații.

Ofertanții trebuie să prezinte detaliat livrabilele care vor rezulta în urma prestării
serviciilor corespunzătoare etapelor de dezvoltare/configurare şi testare internă.

Implementare
Ofertanții trebuie să descrie în detaliu metodologia după care vor derula activitățile
de implementare.

Ofertanții trebuie să prezinte împreună cu oferta procedurile de implementare din

cadrul propriei organizații și vor demonstra integrarea acestor proceduri cu
procedurile referitoare la dezvoltare/configurare și testare internă.

Ofertanții trebuie să prezinte detaliat livrabilele care vor rezulta în urma prestării
serviciilor corespunzătoare etapei de implementare. Descrierea trebuie să conțină cel
puțin următoarele informații:

o formularul/formularele care vor fi utilizate pentru fiecare livrabil

o descrierea conținutului fiecărui livrabil
o modul în care va fi interpretat conținutul livrabilelor

Testarea si asigurarea calitatii

Ofertantul trebuie să descrie modalitatea în care va realiza testarea sistemului și
testele de acceptanță specifice. Ofertantul trebuie să prezinte metodologia de testare
după care se vor realiza activitățile de testare în timpul desfășurării proiectului.
Ofertantul trebuie să prezinte instrumentele de testare folosite.

Beneficiarul (cu asistența Prestatorului) va rula toate scenariile pentru testele de

acceptanță ale întregului sistem sau componentă livrată. Testele de acceptanţă se
vor derula în conformitate cu Planul de Teste realizat de Prestator și agreat de
Beneficiar, plan ce va fi în concordanţă cu întregul ciclu de realizare al proiectului:
etape de testare distribuite pe iteraţii, seturi de funcţionalităţi sau alte tipuri de
teste.

Planul de testare pentru acceptanţă va cuprinde toate testele necesare pentru a

demonstra acoperirea în întregime a cerinţelor din prezentul caiet de sarcini. Astfel,
se va avea în vedere faptul că sistemul funcționează corect din punct de vedere al
respectării cerinţelor, consistenței datelor, al constrângerilor de timp, al validărilor
de date și al gestiunii erorilor, inclusiv pentru funcționalitățile existente care au fost
extinse sau modificate. Criteriul de succes – sistemul trece toate testele definite în
planul de testare agreat împreună cu Beneficiarul.
O primă variantă a planului de testare va fi prezentată odată cu oferta. Planul detaliat
de testare, însoțit de scenariile de testare, va fi realizat de către Prestator și aprobat
de Beneficiar înainte de fiecare etapă de testare agreată prin planul de proiect.

Intrarea in productie
Ofertanții trebuie să prezinte planul care va fi utilizat la trecerea în producție a
sistemului.

Planul prezentat trebuie să țină cont de legăturile logice între subsisteme astfel încât
să se asigure o trecere în producție coerentă şi cu impact minim asupra activităţilor
zilnice a angajaţilor Beneficiarului.

Asistenta operationala post implementare

Furnizorul va asigura asistenta operationala post implementare constand din prezenta
in facilitatile Beneficiarului in scopul suportului operativ al operatorilor in situatii
complexe.

Pe timpul asitentei operationale se mai pot derula sesiuni de instruire care sa

acopere eventuale probleme de asimilare a modului de lucru, descoperite in perioada
initala de intrare in productie.

Asistenta operationala va fi oferit pentru o perioada de o luna de la data intrarii in

productie a sistemului.

Asistenta operationala va fi oferit in regim 24/7 in prima saptamana de operare si pe

perioada zilei in regim 8 – 20 pana la sfarsitul lunii de asistenta operationala.

Asistenta operationala va fi asigurata in amble centre de preluare apeluri.

Asistenta tehnica si suport

Ofertanții trebuie să descrie în detaliu metodologia după care vor derula activitățile
de asistenţă tehnica și suport.

Ofertanții trebuie să prezinte împreună cu oferta procedurile de asistență tehnică și

suport din cadrul propriei organizații.

Ofertanții trebuie să prezinte detaliat livrabilele care vor rezulta în urma prestării
serviciilor corespunzătoare etapei de asistență tehnică și suport. Descrierea trebuie
să conțină cel puțin următoarele informații:

o formularul/formularele care vor fi utilizate pentru fiecare livrabil

o descrierea conținutului fiecărui livrabil
o modul în care va fi interpretat conținutul livrabilelor

Serviciile de suport și asistență software vor deveni operaționale încă de la intrarea

în producție a sistemului ofertat. Sistemul de suport va asigura, dar nu se va limita la
următoarele tipuri de probleme:

o Întrebări de natură tehnică post implementare

 o Preluare de bug-uri (erori la nivel software)
o Optimizarea utilizării sistemului

Ofertantii trebuie sa prezinte impreuna cu oferta procedurile si instructiunile de

lucru de asistenta tehnica si suport din cadrul organizatiei.
Asigurarea si controlul calitatii pe durata proiectului
Ofertantul trebuie să prezinte în cadrul propunerii tehnice o descriere a procedurilor
de asigurare şi control al calităţii aplicabile proceselor pe care le derulează în
activitatea curentă. Se va prezenta o copie a manualului calităţii semnată de către
reprezentantul legal al ofertantului.

Ofertantul trebuie să aloce în planul de proiect timpi suficienţi de verificare şi

validare din punct de vedere calitativ pentru serviciile prestate în cadrul contractului
şi pentru livrabilele/documentele rezultate. Ofertantul va lua în considerare
necesitatea prestării unui număr corespunzător de zile-om pe durata proiectului, de
către personalul specializat în asigurarea şi controlul calităţii prin alocarea experților
cheie și non-cheie.

Trebuie să fie incluse în oferta următoarele proceduri de lucru: Metodologia de

Enterprise Architecture utilizata, Metodologia de implementare, Metodologia de
analiza, Metodologia de testare și design precum si Procedura de asistență tehnică și
suport si draftul Planului de Management al Proiectului. Neprezentarea în oferta a
acestor documente va duce la descalificarea ofertei ca fiind neconformă.

5.3.3 Servicii suport, mentananta si garantie

Pentru gestionarea activității de suport în perioada de garanție, Furnizorul trebuie să
pună la dispoziția Beneficiarului o aplicație software de gestionare a tichetelor.
Aplicația va avea următoarele caracteristici:

• înregistrarea solicitărilor de suport și alocarea unui identificator unic

fiecărei solicitări;
• posibilitatea de definire a unor categorii de apeluri de asistență;
• posibilitatea de definire și de încadrare a solicitărilor în categorii: defect,
eroare, solicitare de informații, cerere de schimbare.
• posibilitatea de înregistrare a datelor de identificare ale apelantului -
include atribuirea incidentului unei persoane care raportează în aplicația
software (inginerul de suport), persoana care soluționează incidentul (de la
orice nivel), persoana care a raportat un incident. Toate datele prezente
aici includ atât date personale, cât și date de contact, activitate curentă
etc., aceasta aplicație putând fi personalizata să primească detalii diferite
pentru aceste puncte de reper în mod diferit și definit în totalitate de către
un administrator de aplicație.
• posibilitatea de înregistrare a descrierii problemei și de atașare a unor
documente suplimentare. Aplicația software să permită atașarea oricăror
tipuri de fișiere (doc, xls, jpg, xml etc.) precum și postarea a unor capturi
de ecran din aplicații.
 • posibilitatea de alocare a unui criteriu de urgență. Aplicația software să
permită clasificarea incidentelor în funcție de tipul stabilit, putând să emită
notificări pe mail privind alocarea incidentelor către persoanele implicate
în incident.
• posibilitatea de alocare automata a unor coduri de incident care să indice
cauza probabilă a incidentului. Aplicația software să aloce coduri unice
fiecărui incident. Aplicația software să permită de asemenea și gruparea pe
module a incidentelor.
• posibilitatea de gestionare a informațiilor despre personalul de suport
căruia i se pot aloca spre rezolvare incidentele. Aplicația software conține
implicit toate datele de contact și deci persoanele, care pot fi considerate
alocabile sau care pot aloca un incident. Aceste date pot fi folosite în mod
facil în cazul unui audit.
• înregistrarea automată a datei și a orei primirii unei solicitări de asistență.
• posibilitatea de definire a criteriilor de calitate și performanta pentru
rezolvarea diferitelor categorii de solicitări de asistență.
• posibilitatea de atenționare automată în momentul depășirii unor praguri
temporale de rezolvare a diferitelor categorii de solicitări de asistență.
• posibilitatea de definire a unor fluxuri de evoluție a solicitărilor de suport,
în cazul în care ele trec prin mai multe nivele de competență până în
momentul finalizării.
• posibilitatea de escaladare a cererilor de suport.
• posibilitatea de înregistrare a datelor de contact pentru responsabilii
pentru activitățile de suport de nivel 1, 2 și 3 pentru diferitele componente
ale sistemului informatic.
• posibilitatea de definire a unor rapoarte personalizate folosind criterii cum
ar fi: tipul de incident, nivelul de urgență, timpul de rezolvare, persoana și
locația de unde a fost semnalat un incident, modulul sau funcția care a
cauzat incidentul, numărul de incidente, etc.
• sa permită în orice moment accesul la baza de date a personalului autorizat
al sistemului pentru verificarea modului de tratare a incidentelor și pentru
rularea de rapoarte de performanță a serviciului de suport. Accesul se va
face numai pentru citire și nu va fi condiționat în niciun fel de către
operatorii sau administratorii serviciului.

Serviciile de asistenta tehnica si suport, desfasurate pe o perioada de 12 luni de la

finalizarea implementarii proiectului, vor trebuie sa includa:

 Activitati continue de suport nivel 1, 2 si 3, realizate pe intreaga perioada de

derulare a proiectului;
 Activitati ocazionale, realizate cand este necesar pentru buna functionare a
sistemului informatic;
 Activitățile necesare pentru modificarea în timp a sistemului astfel încât să se
asigure actualizarea acestuia conform nevoilor curente și conform cerințelor
noi apărute în funcționare.
Ofertantul trebuie sa asigure servicii de tip call center 24 din 24 prin care sa asigure
suportul tehnic necesar utilizatorilor.
Timpii de intervenţie minimi şi obligatorii sunt:

 timp de răspuns: maxim 4 ore;

 timp de soluţionare:
o pentru defect minor: 3 zile;
o pentru defect normal: 24 de ore;
o pentru defect major: 4 de ore.

Unde:

 Prin defect minor se înţelege o problemă semnalată care nu are impact

asupra funcţionării sistemului şi asupra activităţii utilizatorilor;
 Prin defect normal se înţelege o problemă semnalată care afectează
funcţionalităţile sistemului, dar sistemul per ansamblu este încă
funcțional;
 Prin defect major se înţelege că sistemul este indisponibil utilizatorilor.
Serviciile vor consta în:

 Servicii de Help-Desk;
 Preluarea proactiva si asumarea responsabilitatii pentru problemele
semnalate in cererile de suport
 Raspuns conform timpilor de intervenţie asumaţi în oferta tehnică;
 Posibilitatea de centralizare a solicitărilor telefonice;
 Suport tehnic nivel 1, 2 si 3 (prin telefon / e-mail);
 Analizare, planificare, administrare, rezolvare, monitorizare a
progresului, prioritizarea cererilor de suport
 Identificarea si propunerii de solutii pentru probleme
 Cunoasterea foarte bună a proceselor de lucru ale sistemului si clientului
si intelegerea a ce doreste sa faca utilizatorii. Identificarea celei mai
bune rezolvari pentru problemele sesizate si propunerea si de alte solutii
decat cele solicitate in mod direct
 Servicii de asistenta si suport preventiv pentru evaluarea şi corectarea
defectelor/optimizarea aplicaţiilor software:
- monitorizare parametri de funcţionare ai aplicaţiei;
- identificare funcţionare incorectă;
- analiza - identificare defect şi determinare impact;
- izolarea defectelor;
- rezolvarea defectelor;
- testare;
 - restabilirea funcţionalităţilor şi restaurarea datelor;
- actualizare documentaţie sistem (dacă este cazul).
Suportul tehnic trebuie de asemenea sa conțina și activitati proactive, reactive și
ocazionale:

Servicii proactive – menite sa preintampine aparitia de disfunctionalitati in operarea

aplicatiei si sa identifice potentialele probleme inainte de manifestarea lor, atunci
cand se poate realiza acest lucru:

 Monitorizare aplicatii;
 Testare aplicatii;
 Verificarea backup-urilor pe baza de date;
 Verificari periodice ale sistemului;
Servicii reactive – la cerere – bazate pe sesizari interne/externe:

 Ajutor utilizatori pentru utilizarea corecta a functionalitatilor sistemului

informatic;
 Administrare: aplicatie, conturi, drepturi, functionalitati;
 Rezolvare probleme prin workaround-uri;
 Configurari;
 Gestionare sesizare: urmarire fluxuri rezolvare sesizare;
 Ajutor pentru corectii cu ajutorul aplicatiei;
 Verificare/interpretare log-uri aplicatie;
 Reproducere scenariu sesizare;
 Rezolvare sesizare in aplicatie;
 Testarea rezolvării sesizării.
Serviciile de suport trebuie sa se desfasoare conform standardului ISO 20000. In
fluxul de suport sunt incluse activitatile de: monitorizare si intreprindere actiuni
necesare pentru rezolvarea problemelor conform SLA, monitorizare si intreprindere
actiuni pentru actualizarea continua a starii problemei si activitatile executate in
aplicatia de ticketing, transmiterea rezultatelor clientului, actualizarea continua a
clientului continuu despre starea problemei, verificarea rezolvarii problemei si
confirmarea de catre client a rezolvarii ei, inchiderea problema.

Furnizorul va efectua toate reparaţiile necesare asupra produselor software

pentru aducerea acestora la starea operaţională.
Garantie
Se vor oferi indica in oferta tehnica detalii despre modul de asigurare a garanţiei si
suportului tehnic, resursele umane alocate si calificarea acestora.

Servicii de garantie includ:

1. Pentru sistemul integrat se vor oferi 12 luni de garantie de la data finalizarii
implementarii
2. Toate echipamentele hardware trebuie să beneficieze de minim 12 luni garanție
de la data livrării.

În cadrul perioadei de garantie se vor asigura:

• rezolvarea bug-urilor care nu au fost identificate în timpul implementării şi

care apar în faza de producţie;
• întreţinerea şi buna funcţionare a sistemului furnizat în parametrii agreaţi
(funcțional, performanţă, disponibilitate, integritatea datelor etc.);
• instalarea de noi versiuni ale aplicațiilor în urma efectuării corecțiilor;
• actualizarea manualelor de utilizare și altor documente în urma efectuării
corecțiilor;
• toate incidentele vor fi gestionate prin intermediul aplicației software de
gestionare a tichetelor.

5.3.4 Instruire
Oferta trebuie să cuprindă sesiuni de instruire pentru personalul autoritatii
contractante, utilizatori finali şi personal administrativ IT.

Ofertanţii vor propune în cadrul ofertelor un plan (calendar) de sesiuni de instruire,

cu menţiunea că aceste sesiuni se vor încadra în ultimele 3 luni din calendarul
implementării proiectului.
Sesiunile de instruire se vor efectua după modelul ”în clasă” si “instruire la locul de
munca” efectuate pe platforma de instruire livrata in cadrul proiectului, platforma
care implementeaza toate capabilitatile si configuratia sistemului implementat.
Totodata se vor asigura mecanisme de instruire si perfectionare continua. Grupele
de cursanți se vor stabili de comun acord cu Beneficiarul înainte de începerea
sesiunilor de instruire.

Platforma de instruire va permite în procesul de învațare folosirea ei atât din punct

de vedere al activităților de preluare de apeluri telefonice cat si scenariile de
raspuns si ghidare a interviului in functie de cazuistica prezentata.

Serviciile de instruire, model “în clasă”, vor fi susţinute în Limba Română de către
instructori specializaţi ai Ofertantului şi vor avea loc în locaţii pusă la dispoziţie de
către Autoritate.

Programul de formare se va furniza în centre la nivel naţional (vor fi comunicate

Furnizorului). Fiecare grupă va avea între 15-20 cursanţi. Cursul va avea 8 ore
teorie, 8 ore practică, 4 ore evaluare.
Tot supportul de curs va fi publicat intr-o platforma de E-learning ce se va livra in
cadrul proiectului.
Platforma de e-learning ofertata va permite invatarea la distanta a cursantilor in
regim propriu. Acestora li se vor crea conturi si vor accesa platfoma pe baza de user
si parola.
Platforma de e-learning va fi o soluţie integrată pentru crearea şi punerea în aplicare
a testelor şi evaluărilor.
Platforma de e-learning va fi certificata ca fiind compatibil cu SCORM 2004.
Platforma de e-learning va oferi posibilitatea instructorullui sa vada utilizatorii
conectati in sistem.
Platforma de e-learning va oferii posibilitatea monitorizarii progresului de învăţare atât
de către utilizatori, cât şi de către tutori şi examinatori.
Platforma de e-learning va oferi posibilitatea testarii.
Testele de evaluare vor putea gestiona cel putin urmatoarele tipuri de întrebari :
 cu răspunsuri multiple,
 cu o singură alegere,
 întrebări incluse in text (cu raspuns impus, sau la alegere),
 ordonare sau potrivire raspunsuri
 click pe optiune pe baza de imagine
Platforma de e-learning va oferi functionalitati de chat
Platforma de e-learning va putea grupa intrebarile asociate unui modul in grupuri de
intrebari din care va putea genera teste.
Platforma de e-learning va putea stabili criterii de succes al unui test.
Platforma de e-learning va crea spatiu de lucru fiecarui utilizator unde se vor grupa
toate resursele, care sunt necesare în procesul de învăţare pentru îndeplinirea
sarcinilor zilnice de studiu.
Spaţiul de lucru personal va cuprinde mai multe instrumente: Ştiri (News), Mesaje
personale (Personal Messages), Resurse de învăţare (Learning Resources), Note
personale (Personal Notes), Marcaje (Bookmarks), Fluxuri WEB (External WEB
Feeds) şi alte informaţii.
Fiecare utilizator îşi va poatea re-aranja aceste blocuri de informaţii, în funcţie de
nevoile proprii.
Instructorii vor dispune de un spatiu propriu unde vor putea organiza continuturile
educationale proprii in suporturi de curs pe care le va utiliza in sesiuni de instruire si
evaluare cu precizarea ordinii continuturilor in planul suportului de curs, a duratelor
de parcurgere recomandate si a domeniilor carora li se adreseaza.
Sistemul va permite importul materialelor educationale ce pot fi rulate in browser
(ex. html, doc, pdf, ppt, jpeg, swf...)
Sistemul va oferi posibilitatea crearii de obiecte de invatare. Obiectele create vor
putea sa contina text, imagini, filme, animatii.
Platforma de e-learning va dispune de o functionalitate e tip wiki ce va permite
crearea colectiva a documentelor, cu pastrarea unui istoric al tuturor modificarilor
efectuate. La un wiki va putea lucra intreaga clasa/grupa sau un singur elev, ajutat
de profesor.

Cerințe privind arhitectura funcțională a platformei dedicate de instruire a operatorilor

Obiectivul funcţionalităţii Sub-sistemul dedicat de Instruire trebuie sa fie aceea de a

oferi beneficiarului un instrument de formare continua si perfectionare a Operatorilor
Serviciului 112, precum si posibilitatea de a verifica impactul unor eventuale
schimbari ale procedurilor curente de lucru, într-un mediu care nu alterează sistemul
aflat in producţie, iar pe de altă parte trebuie sa fie cât mai similar posibil cu
sistemul din producţie.
Această secţiune descrie cerintele pentru diferitele caracteristici legate de formarea
profesională a Operatorilor.

Modul Instruire
Aplicatia dedicata Operatorilor poate fi rulata în modul instrucţie. În acest mod,
actualizările nu sunt efectuate în sistemul operaţional.

Scripturi
Când se rulează Aplicatia dedicata Operator în modul Instruire, trebuie sa fie posibil
să se înregistreze scripturi. Un script reprezintă date structurate în format XML, care
conţin informaţii despre utilizator şi interacţiunea cu sistemul în timpul sesiunii
înregistrate. Scriptul conţine suficient de multe informaţii pentru a putea fi rulat fără
a fi nevoie de vreo bază de date.

Un script trebuie sa fie construit din mai multe Stări, fiecare Stare fiind o operaţie a
utilizatorului. Pentru fiecare Stare se înregistrează următoarele date:

o Timpul petrecut
o Interacţiunea cu restul sistemului
o Informaţii despre fişierul de stocare a înregistrărilor audio, dacă exista
vreuna, care a fost efectuată în timpul acelei Stări
Editorul de Scripturi Sistem
Trebuie sa fie posibil să editezi un Script folosind Editor de Scripturi. În acest editor,
tipul scriptului se va putea seta ca fiind poate fi unul din următoarele:

o Redare
o Scenariu
o Test
o Simulare de Sistem Operator

Tipul Scriptului controlează comportamentului Scriptului atunci când acesta va fi

redat.

În Editorul de Scripturi toate datele pentru Scripturi şi Stările sunt configurate, ca în

exemplele de mai jos:

o Diferite mesaje text sunt prezentate Operatorului când trebuie sa fie

redat Scriptul
o Diferite fişiere de sunet sunt redate când trebuie sa fie rulat Scriptul
o Numărul de erori pentru a trece un test atunci când se rulează un Script
de Test
Roluri
Platforma de instruire trebuie sa poata implementa acelasi roluri ca si sistemul aflat
in productie, sa prezinte aceleasi proceduri operationale in asa fel incat sa permita
instruirea noilor operatori intr-un mod cat mai apropiat de mediul real.
Cursuri
Platforma de instruire trebuie sa poata implementa cursuri formate dintr-un numar
de lectii ce se prezinta sub forma unor scripturi inregistrate ce funizeaza un anumit
scenariu de instruire.

Platforma de instruire trebuie sa poata atribui unui cursant un numar de cursuri pe

care sa le parcuga in conformitate cu o anumita strategie de dezvoltare a
competentei necesare.

Platforma trebuie sa permita urmarirea procesului de invatare prin prezentarea

progresului de parcurgere a cursurilor atribuite unui cursant.

Scripturi de instruire (inregistrate)

Platforma trebuie sa creeze scripturi pre-inregistrate care pot demonstra un mod de
actiune intr-o situatie de lucru.

Un cursant trebuie sa poata vedea toti pasii de procesare a unei situatii prin rularea
scripturilor inregistrate.

Sistemul nu trebuie sa genereze tranzactii sau interactiune cu bazele de date pentru

a reda un script de instruire.

Scripturi care definesc scenarii

Platforma de insturire trebuie sa permita implementarea de scenarii ce se vor rula
via scripturi si prin care operatorul participa la rezolvarea situatiei prezentate de
catre scenariu.

In cadrul scenariului, sistemul va realiza sarcinile altor elemnte ale interventiei in

vreme ce operatorul este asteptat sa desfasoare activitatile asociate pozitiei de
coordonator.

Scenarii de test
Platforma trebuie sa poata implementa scripturi care implementeaza scenarii cu rolul
de a testa cunostintele operatorului cu privire la modul de rezolvare a scenariului
respectiv.

Platforma va finaliza automat testul in conditiile in care operatorul depaseste un

numar maxim de erori de procesare a situatiei, admise.

Realizarea scripturilor de instruire (inregistrate)

Platforma de instruire trebuie sa permita inregistrarea scenariilor pe masura ce
operatorul executa actiunile asociate.

Inregistrarea trebuie sa se poata face atat pentru analiza ulterioara in vederea

crectarii erorilor de operare cat si pentru definirea de noi scenarii si proceduri de
operare ce vor fi prezentate ulterior noilor cursanti.
 6. Cerinte functionale
Scopul acestui capitol este de a descrie functionalitatile de business minime ale
sistemului integrat, acesta acoperind practic fluxul de lucru si uneltele necesare
operatorilor 112 si al personalului desemnat cu drepturi de supraveghere in vederea
asigurarii unui serviciu 112 de inalta calitate.

Din puncte de vedere functional, SIA va implementa urmatoarele functionalitati:

 Comunicatii:
o realizeaza preluarea si managementul apelurilor de voce provenite de
la apelanti, si a metadatelor asociate acestora; realizeaza transmiterea
fluxurilor de voce intre Operatorii 112 si intre acestia si Operatorii
SSU; va putea realiza comunicarea bi-directionala cu resursele de
interventie, prin sisteme radio (PMR, TETRA), GSM (2G, 3G, LTE),
satelitar, in prima faza a proiectului, cat si comunicarea cu dispeceratul
mobil, in etapa a doua a proiectului; sistemul trebuie sa asigure o
corelare automata, unica si integrata intre toate fluxurile de voce si
toate fluxurile de date asociate unui incident, necesare in cazul unui
audit.
o Capabilitatea de a asigura comutarea automata a cailor de comunicatii
in situatii de defect atat in infrastructura proprie, cat si in
infrastructura operatorilor de telecomunicatii
o Localizarea apelantului – atat pentru apelurile din telefonia mobila, cat
si cele din telefonia fixa
o Capabilitati de filtrare a apelurilor false si de asistenta a apelantului in
vederea aplicarii primelor masuri de atentionarea automata a
apelantului abuziv ( transmiterea automata de SMS de avertizare ).
o Inregistrarea sincrona a vocii si datelor asociate unui dosar de incident
 Managementul incidentelor:
o Posibilitatea de a construi dosare de caz ce vor contine fise de caz
specifice agentiilor care intervin, in asa fel incat o interventie sa poata
fi analizata integrat
o executa procesarea logicii aplicative pentru functionalitatile de baza ale
sistemului (managementul evenimentelor si suport culegere date);
o Posbilitatea de a clasifica evenimentelor pe baza de nomenclator
o Culegerea asistata de informatii de la apelant, in functie de tipul
evenimentului
o Suport pentru consilierea initiala a apelantului in vederea limitarii
efectelor evenimentului semnalat, in concordanta cu proceduri
prestabilite
 Platforma informational-geografica (GIS):
o realizeaza gestionarea informatiilor geo-spatiale, si prezentarea
localizarii apelantului si a evenimentului semnalat pe o interfata grafica
de tip harta, cu reliefarea detaliilor relevante pentru gestionarea
 situatiei specifice- cel putin: locatia incidentului, tipul incidentului, ora
si data incidentului;
o comunica cu componta de managementul incidentelor in vederea
actualizarii dosarului de incident cu informatii specifice sistemelor
geografice (locatia incidentlui, coordonate incident, adresa incident,
implicatii ale evenimentului asupra altor obiective din zona incidentului)
 Gestiunea bazelor de date relationale:
o pastreaza replica locala a bazelor de date ANI/ALI; stocheaza toate
informatiile legate de apelurile primite, si detaliile legate de procesarea
evenimentelor in sistem;
o Comunica cu sisteme informatice externe, prin intermediul platformei
de interoperabilitate, in situatia in care se pot obtine informatii cu
privire la ANI/ALI in timp real;
 Managementul identitatii, autentificare, autorizare:
o Evidenta, autentificarea si autorizarea resurselor de sistem: realizeaza
organizarea in structuri logice, de tip arborescent; gestioneaza
autentificarea si autorizarea elementelor din sistem, inclusiv a
utilizatorilor umani („directory”);
 Interfata cu sisteme externe:
o realizeza integrarea SIA cu sisteme informationale aflate in afara
controlului propriu, pentru importul datelor din sisteme externe in
scopul documentarii de baza a cazurilor, si transferul fisei de caz catre
sisteme externe (in principal sisteme automatizate ale SSU);
o asigura transferul informatiilor asociate incidentelor (voce si date)
catre SSU-urile care au imlementate sisteme pentru managementul
situatiilor de urgenta, prin intermediul platformei de interoperabilitate
si in conformitate cu protocoalele institutionale existente, si asigurarea
confidentialitatii informationale
 Monitorizarea si auditul sistemului:
o realizeaza inregistrarea tuturor interactiunilor componentelor
sistemului integrat la toate nivele, realizeaza inregistarea tuturor
interaciunilor operatorilor cu sistemul informatic
o Toate actiunile intreprinse in afara sistemului trebuie sa poata fi
jurnalizate, pentru ca la incheiera incidentului, totalitatea actiunilor
intreprinse sa fie disponibile in jurnalul incidentului.
o emite notificari si alertari in cazul incidentelor de exploatare si
operare, ofera capabilitati de statistica a consumului de resurse
tehnice, informatii despre sanatatea si performata componentelor,
capabilitati de identificare proactiva si reactiva a anomaliilor in
funtionare si ofera capabilitati si sugestii de actiuni in vederea
remedierii problemelor.
o Ofera informatii de utilizare a interfetelor cu operatorii de
telecomunicatii
 Mediu de instruire si testare:
o Este identic cu cel din productie, dar separat de acesta, si fara a
indeplini cerintele de inalta disponibilitate, si asigura implementarea
 scenariilor de instruire, in asa fel incat sa asigure instruirea
personalului, in mod simulat, sincronizat cu procedurile de lucru din
sistemul operational.
o Permite implementarea de scenarii de instruire cu scopul de a
imbunatati procedurile operationale.
o Pune la dispozitie capacitati de dezvoltare si testare pre-productie a
noilor functionalitati, update-uri si patchuri pentru software-ul si
hardware-ul existent
o In caz de nevoie, poate constitui solutie de back-up pentru sistemul
aflat in productie,
o Contribuie la cresterea numarului total de pozitii de operare in situatii
exceptionale de incidente majore.
 Backup si arhivare:
o Asigura capacitatea necesara pentru inregistrarea, catalogarea si
stocarea tuturor actiunilor intreprinse si a tuturor evenimentelor din
cadrul SNUAU.

6.1 Capabilitati generale ale sistemului SIA 112

SIA 112 trebuie să asigure implementarea următoarelor funcţionalităţi de bază:

o autentificarea, autorizarea si atribuirea de roluri utilizatorilor, dupa criterii

organizationale si legate de competenţe
o multi-organizație - Sistemul trebuie să fie capabil să ofere suport simultan
pentru diferite organizații, fiecare cu proprii operatori și dispeceri, resurse
și protocoale operaționale (planuri pentru diferite tipuri de incidente)
specifice, și propriile cozi de apeluri
o Sistemul trebuie să asigure mecanisme de confidențialitate, astfel încât
operatorii unei organizații să nu poată să vadă și să administreze resursele
și planurile altei organizații
o Sistemul trebuie să ofere mecanisme de colaborare, astfel încât, dacă mai
Smulte organizații colaborează în cadrul aceluiași incident, să poată să
împartă informații despre incident și resursele proprii alocate respectivului
incident
Toate funcțiile soluției (comunicații, înregistrare vocală, preluare apeluri,
dispecerizare, GIS) trebuie să fie integrate complet și funcțional într-o interfață
grafică unică și unitară pentru operatori. Modificările și selecțiile efectuate în
interfețele de tip câmpuri de text trebuie să se reflecte automat și în interfețele de
tip hartă și viceversa, fără ca operatorul să facă operații suplimentare.

6.2 Comunicatii

Funcționalitățile generice de telefonie trebuie sa includa operarea cozilor de apeluri

de intrare asociate cu telefonia digitală și IP, sistemul trebuie sa suporte mesagerie
de tip SMS, funcții de apelare in masa, distribuire automată a apelurilor, sistem
automat de preluare cu ghidare vocala. Functionalitatile de telefonie trebuie
integrate nativ cu componenta de management al incidentelor, astfel incat apelarea
unor contacte predefinite (atat telefonice cat si statii radio) sa se poata efectua
automat de catre sistem, din modul de management al incidentului, in functie de calea
de comunicatii declarata disponibila in intervalul de timp asociat.

Sistemul trebuie sa asigure necesarul pentru capacitatea de preluare, procesare si

transfer al apelurilor vocale intre Operatori, Dispeceri si intervenanti externi, si
necesarul pentru comunicatii de voce catre exterior,

Sistemul oferit trebuie să își bazeze toate comunicațiile interne pe tehnologie IP

o Comunicațiile de Voce & Date între nodurile sistemului

o Comunicațiile de Voce & Date între stațiile de lucru și nodurile sistemului
o Comunicațiile de Voce & Date între stațiile utilizatorilor

Sistemul trebuie să ofere posibilitatea de a comunica cu rețele externe de telefonie

prin intermediul

o Implementarii unei arhitecturi distribuite prin separarea semnalizarii de

voce
o Protocolului SIP, ISUP si/sau SIGTRAN
o Protocolului ISDN, peste legături tip E1 – doar pentru solutia de
supravieturie cand ambele noduri de comunicatie sunt defecte

Sistemul trebuie să fie posibila legarea unor stații distribuite geografic, cu

funcționalitate complete în raport cu stațiile din centrele de dispecerizare, conectate
la serverele sistemului peste o legătura IP de tip wide area network (WAN).

Sistemul va suporta comunicatii integrate, de la aceeasi consola operator cu

urmatoarele sisteme:

o Linii de apel de urgență și linii telefonice gratuite, reteaua de telefonie

comutata publica și centrale telefonice
o Sisteme radio-comunicatii convenționale, trunking și digital mobil pentru
(Analog, TETRA):
o Apeluri individuale
o Apeluri in grup
o Mesaje scurte de tip SMS
o Mesaje scurte de tip SDS
o Sisteme de informare publica si alarmare in masa (PAGA)
o Sisteme de video-supraveghere

Infrastructura de comunicatii ce va asigura transportul informatiilor intre centrele de

date va trebui sa indeplineasca urmatoarele cerinte relativ la calitatea serviciului:

Parametru Valoare

Delay mediu < 25 ms

Delay maxim < 100 ms

 Jitter < 10 ms

Pierdere de pachete < 0.1 %

Interval de recuperare (failover), max 1 secunda

Necesar latime de banda per post de ~ 1.5 Mbps

lucru, min

6.2.1 Funcție de preluare apeluri

SIA va implementa urmatoarele functionalitati:
o Sistemul trebuie sa poata implementa cozi de apeluri de intrare pentru
diferite tipuri de apeluri (în funcție de numărul apelat, numărul care a
apelat, sau prefix al numărului care a apelat, pentru SMS-uri, pentru
email-uri, etc.)
o La răspunsul la un apel, sistemul trebuie sa poata prezenta istoricului
pentru apelurile recepționate de la același număr telefonic, listarea
timpilor de apel, cum au fost clasificate apelurile anterioare (tip de
incident) și, în cazul în care apelul este respins, motivul pentru care apelul
a fost respins (ex: apel abuziv)
o sistemul trebuie sa ofere capabilitatea de asigurare a confidenţialitatii
unor convorbiri sau doar a unor anumite parti din convorbire, prin
izolarea unora dintre participantii la conferinta;
o sistemul trebuie sa includa capabilitatea de a inregistra automat si
complet apelul de voce catre 112 si a tuturor apelurilor si/sau a
conferintelor vocale subsecvente, initiate pentru a trata evenimentul
semnalat, incepand din momentul preluarii apelului de catre Operatorul
112 si pana la finalizarea tratarii incidentului, sistemul asigurand o
asociere unica intre toate fisierele vocale specifice unei interventii si
evenimentul semnalat;

o obtinerea informatiilor despre apelant, in urma unei interogari efectuate,

pornind de la identificarea apelantului, si completarea campurilor din foaia
de eveniment cu aceste informatii, fara sa fie necesara interventia
Operatorului. Informatiile despre apelant trebuie sa fie obtinute, in mod
automat, doar in situatia receptionarii unui apel la numarul unic de urgenta
112. Operatorul 112 nu va avea posibilitatea sa caute informatii in baza de
date ANI.
Functionalitati de telefonie
SIA va implementa urmatoarele functionalitati:
o preluarea apelurilor de urgenţă inițiate in rețelele operatorilor de servicii
de telefonie fixa si mobila;
o preluarea si tratarea altor tipuri de alertări de urgenta, prin SMS, Fax,
eCall, ş.a.
o Inițierea apelurilor
 o Afișarea ID apelantului
o Apelare folosind numere complete
o Apelare folosind numere scurte
o Apelare directă
o Conectarea la o linie externă
o Punere in așteptare
o Cadran numeric de apelare DTMF
o Conferință
o Atribuire de priorități pentru apelurile primite
o Identificarea automată a numărului apelant
o Agenda telefonica
o Grupuri de apelare secvențială
o Reapelarea ultimului număr
o Interconectarea liniilor de comunicații radio si telefonice
o Transfer intern și extern

Mecanisme de distributie a apelurilor

Sistemul trebuie sa permita distribuirea automata a apelurilor (ACD):
o Odata ACD activat, apelurile telefonice vor fi distribuite automat de către
sistem într-un mod care echilibrează încărcarea între operatori. In acest
mod se va putea elimina necesitatea de a apasa o tastă de catre Operator
pentru a răspunde la un apel aparut pe o linie specifică;
o În cazul în care niciun operator nu este disponibil pentru a răspunde, orice
nou apel primit va fi plasat într-o coadă de asteptare, din care va fi
preluat de catre primul operator disponibil cu drepturi de acces la coada
respectiva. În cazul în care nici un Operator cu drepturi de acces la
respectiva coada de apeluri nu este disponibil, funcția ACD va escalada
automat apelul catre alta grupa de operatori, marcată pentru preaplin
(„overflow”).
Sistem automat de preluare cu ghidare vocala
SIA va implementa urmatoarele functionalitati:
o Va dispune de functionalitatea de mesaje vocale interactive care va putea
fi utilizata fie ca atare, fie împreună cu ACD și modul de operare bazat pe
roluri si responsabilitati. Pe baza optiunilor introduse de catre apelant de
la tastatura telefonului, apelul sau va fi direcționat către un anumit grup de
Operatori
Înregistrare vocală
SIA va implementa urmatoarele functionalitati:
o Toate comunicațiile vocale (telefonice, radio) trebuie înregistrate
o Înregistrările vocale trebuie asociate unui caz specific
o Trebuie să fie posibil să se găsească toate înregistrările vocale ale unui
caz specific
o Operator trebuie să poată să asculte înregistrările dintr-un caz
 o Trebuie să fie posibil să se controleze drepturile de acces la
înregistrări
Carte de telefon
Cartea de telefon va implementa functionalitatea de Contacte necesara sistemului in
implementarea functionalitatilor de automatizare a alarmarii si comunicarii.

o Definiţia unui Contact va trebui sa includa date precum numele şi adresa.

o Trebuie sa exista atat Contacte globale (valabile pentru toti utilizatorii
sistemului), dar si optiunea ca Operatorul sa poata crea Contacte
personale, specifice doar acelui Operator.
o Vor trebuie sa existe diferitele moduri de a defini modalitatea de a ajunge
la un contact - precum numărul de telefon de acasă, număr de mobil,
radio, fax, e-mail şi Radio Digital Short Message (SDS).
o Una dintre aceste modalitati trebuie sa poate fi indicată ca fiind activă, iar
aceasta poate avea validităţi diferite în funcţie de un anumit orar. Sistemul
va utiliza un orar de validitate când evaluează ce modalitate de contact să
folosească.
o În cazul în care Contactul va fi o Resursă ce va putea fi folosita in Misiuni,
diferitele modalitati de contact asociate vor putea asocia un status de
Resursa. Sistemul „Centru de Comunicare pentru Situatii de Urgenta” va
lua in considerare statusul curent al respectivei Resurse când evaluează
modalitatea de lua legatura cu Contactul.
o Contactele vor fi grupate in Agenda de Contacte în care să se poate căuta
resurse interne sau externe, din care să se poată activa atât comunicațiile
de tip apeluri telefonice sau apeluri radio, precum și SMS, SDS si emailuri.
o Operatorul sistemului „Centru de Comunicare pentru Situatii de Urgenta”
va trebui sa aiba acces la Contacte si Lista de Contacte prin intermediul
Agendei de Contacte. Aceasta din urmă va trebui sa cuprinda următoarele
funcţii:

o Căutarea Contactelor, Serviciilor şi Listelor de Contacte

o Iniţierea unui apel prin introducerea numărului de telefon
o Accesarea Interfeţei de Contacte relevante
o Crearea de noi Contacte personale
o Crearea de Excepţii la toate nivelele
o Afişarea unei liste ce conţine toţi Operatorii conectaţi la Sistem şi
posibilitatea de a iniţia apeluri vocale interne oricăruia dintre aceştia
o Afişarea apelurilor de intrare şi ieşire făcute într-un interval de 10
ore precum şi afişarea informaţiilor privind aceste apeluri
o Căutarea contactelor, Serviciilor şi Listelor de Contacte în funcţie de
geografie
o Căutarea şi Utilizarea unei cărţi de telefoane printr-o interfaţă LDAP
o Folosirea comenzilor rapide configurabile, pentru contactarea unui
Contact sau Serviciu.
Date de Contact Ascunse
SIA va implementa urmatoarele functionalitati:
o Sistem va putea fi configurat pentru a putea ascunde Operatorului detaliile
de contact al unor resurse, precum numărul de telefon sau adresa. Vor fi
incluse opţiunile ca pentru informaţiile ascunse Operatorul să trebuiască
să furnizeze coduri de acces pentru a putea notifica respectivul Contact,
si sa poata sa fie notificat Contactul fără interacţiunea directă a
Operatorului.
Algoritimi de notificare a listelor de contacte
SIA va implementa urmatoarele functionalitati:
o Sistemul trebuie sa includa următoarele două tipuri de Liste de Contacte:

o Toţi activi în paralel: Aceasta înseamnă că prin sistem se vor putea

notifica toate Contactele incluse când Lista de Contacte, in acelasi
timp.
o Notificare secvenţiala: Aceasta înseamnă că prin sistem se vor putea
notifica toate Contactele incluse când Lista de Contacte, unul cate
unul, până când unul dintre contacte confirma notificarea.

6.2.2 Sistemul de comunicatii vocale va fi compus din urmatoarele componente

o Servere de comunicatii (voce), in care sunt instalate:
o interfetele cu sistemele externe avand 28 de porturi distribuite in mod
egal intre cele doua centre, dupa cum urmeaza:

 8 linii digitale echivalent E1 pentru preluarea apelurilor de

urgenta si efectuarea de apeluri catre retelele de telefonie;
 6 linii de semnalizare ISUP

o 60 linii digitale VoIP pentru convorbiri interne, intre operatori si intre

operatori si dispeceri.
o Cate 2 module modem in fiecare CPAU pentru preluare faxuri, SMS
o Cate 2 module specializate de tip modem pentru preluare eCall in fiecare
CPAU;
o Sistem de comunicatii vocale pentru regim de avarie, ce va fi folosit doar
in caz de indisponibilitate a sistemului de voce principal;
o acest sistem va fi reprezentat de un PABX si va indeplini si roul de
centrala telefonica interna.
o Fiecare Operator 112 va dispune de un telefon dedicat, conectat la
aceasta centrala telefonica, care va putea fi folosit pentru preluarea
apelurilor de urgenta si efectuarea de apeluri in exterior, in caz de
indisponibilitate a sistemului principal de voce.
Functionalitati de management al apelurilor
Prioritatea şi Categoria unui Apel
o Liniile de intrare şi alte entităţi generând Apeluri, vor avea configurata o
Prioritate a Apelului. Atunci când un apel intra în Sistem, Prioritatea
Apelului îi validează importanta.
o Administratorul va crea Priorităţile de Apel cu setări de comportament
precum prioritatea Apelului şi stabilind care dintre fişierele de sunet se
vor auzi pentru Apelurile care intră.
o Administratorul va putea să configureze Categoriile de Apeluri. Scopul
Categoriilor de Apeluri trebuie sa fie acela de a clasifica Apelurile pentru
urmărire.
Apeluri la Poziţia de Operator
o Fereastra aferenta Cozilor de de Apeluri va arata Inbox-urile relevante
pentru Opţiunea de Lucru actuala. Se va putea configura pentru fiecare tip
de Sarcina către ce Inbox de Apeluri se va distribui apelul.
o Sunetul pentru Apeluri de intrare va putea fi ascultat în căştile
Operatorului sau în boxe în conformitate cu setările sistemului.
o Se va putea folosi un Sunet de Alertă Continuu când intră un Apel nou în
Inbox.
Răspunsul la Apel
o Când Operatorul va răspunde unui Apel din unul din Inboxuri, prin
accesarea Inboxului sau utilizând scurtături ale tastaturii, Sistemul va
alege automat un Apel pe baza Priorităţii Apelului şi a duratei petrecute în
coada de aşteptare. Operatorul va putea sa extinda un Inbox şi sa
răspunda oricărui Apel din Coadă de Aşteptare a Apelurilor.
Distribuirea Apelului
o Când un Apel va aparea in Sistem, de exemplu datorită unui apel care
intră, Apelul trebuie sa fie distribuit către Operatorii relevanţi.
o Distribuirea trebuie sa fie bazată pe o Sarcină. Un Apel pentru un apel
telefonic care intra va fi distribuit către Operatorul logat cu o Opţiune de
Lucru inclusiv Sarcina configurata pentru linia de intrare.
o Distribuirea Apelului poate fi setata cu un parametru de Distribuire a
Încărcării. Distribuirea Încărcării înseamnă ca Operatorul care a stat fără
un apel telefonic o perioadă de timp mai îndelungată comparativ cu restul
Operatorilor logaţi pentru aceeaşi Sarcină, va primi următorul apel care
intră. O perioadă de finalizare poate fi adăugată pentru Distribuirea
Încărcării. Perioada de finalizare trebuie sa fie timpul rezervat
Operatorului pentru finalizarea Cazului anterior.
o Când un Operator răspunde unui apel, acel Apel va disparea din coada de
aşteptare a Apelulrilor pentru toate Poziţiile de Operator către care a fost
distribuit.
o Dacă Apelul nu poate fie preluat într-o perioada de timp configurabila,
Apelul va fi distribuit unui număr mai mare de Operatori. Aceasta se
numeşte Distribuţie Secundară. Dacă nu sunt găsiţi Operatori pentru
Distribuţia Secundară sistemul va încerca o Distribuţie Extinsă în intreg
 Call Center. Dacă Apelul nu poate sa fie preluat în timp atunci când
trebuie sa fie distribuit în conformitate cu Distribuirea Extinsă în Call
Center sau dacă nu au fost găsiţi Operatori, Sistem va trebui sa incerce un
Distribuţia Apelului la nivel de Sistem.
o Setările pentru Distribuirea Apelului vor consta în Scheme incluzând
parametrii de timp între diferite Distribuţii, perioada pentru prima
avertizare şi perioada pentru o a doua avertizare şi de asemenea, dacă se
va folosi o a treia şi o a patra distribuţie sau nu.
o Pentru a primi Apeluri, în diferitele moduri de Distribuiri de apeluri,
Operatorul va putea selecta diferitele Roluri ale unei Opţiuni de Lucru.
o Culoarea Apelului în Coada de Aşteptare a Apelului va indica dacă un Apel
a fost lăsat fără să se răspundă pentru prea mult timp. Culoarea se va
schimba, ca o primă şi o a doua avertizare.
o Trebuie sa fie posibil să se configureze o Schemă de Distribuţie a
Apelurilor pentru fiecare entitate generatoare de apel. Implicit pentru
fiecare Prioritate de Apel trebuie sa fie configurata o Schemă de
Distribuire a Apelurilor.
Ocupat şi Blocat
o Un Operator se va putea seta pe sine ca „Ocupat”, însemnând că nici un
Apel Distribuit cu Prioritate nu va ajunge la respectiva poziţie de
Operator.
o Date Statistice despre Apeluri
o Pentru fiecare Apel, Sistem va stochează datele relevante pentru urmărire
în scopuri statistice. Exemple de date stocate atunci când Apelul a fost
creat şi perioada de timp petrecută în Coada de Aşteptare până cand un
Operator a răspuns Apelului.
o Managementul Apelurilor Telefonice
o Sistemul trebuie sa suporte rmătoarele funcţiuni pentru operarea
apelurilor telefonice:
o Întoarcerea în Coada de Apelului
o Apel în Aşteptare
o Transferul Apelului
o Conferinţa
o Medierea
o Cererea de Alăturare
o Asistent de Monitorizare
o Apel de voce intern
o Apel de ieşire
o Surdină
o Izolaţi şi Ascultaţi
o Închideri apel
Apeluri telefonice de intrare
o Apelurile telefonice de intrare vor aparea ca Apeluri în Inbox-ul Cozii de
Aşteptare a Apelurilor. Pentru fiecare linie de intrare următoarele setări
se vor putea realiza:
o Distribuirea Apelului
o Textul Apelului în Coada de Aşteptare a Apelului
o Fraze de salut relevante de prezentat către Operatorul care răspunde.
o Când Operatorul răspunde la un Apel generat printr-un apel telefonic de
intrare, legătura trebuie sa fie stabilită şi orice alte legături la Poziţia de
Operator sunt automat puse în aşteptare. De asemenea, un Caz relevant
se va crea automat.
Blocarea Apelurilor de Intrare
o Operatorul poate bloca intrarea apelurilor, precizand A-number, în Coada
de Aşteptate a Apelului. Când un Apel dintre cele blocate A-number este
recepţionat în Sistem, apelantul va auzi un mesaj Vocal (sau un ton de
ocupat dacă nu trebuie sa fie definit niciun Mesaj Vocal pentru blocaj).
o Operatorul poate putea vedea toate blocajele active pentru toate Rolurile
pe care un Operator trebuie sa fie logat şi poate modifica sau înlătura
blocajele singulare. Un blocaj total poate fi configurat numai de către un
Administrator.
o Sistem va respinge un apel iniţiat dintr-un apel SIP, ISUP sau un apel
iniţial din ISDN, când anumite părţi ale sistemului au detectat faptul că
apelul nu poate fi administrat corect de către sistem.
o Reţeaua de telefonie, care a trimis iniţial apelul ISUP sau ISDN, va fi
notificata asupra faptului că Sistem nu poate gestiona apelul de intrare în
mod corect.
Întoarcerea în Coada de Apel
o Un apel telefonic care intra şi la care s-a răspuns va putea fi retrimis în
Coada de Aşteptare.
o Cazul corespunzător primului Apel va rămâne şi va fi prezentat atunci
când noul Apel este preluat.
Apel în Aşteptare
o Un apel pe care Operatorul doreşte să îl lase de-o parte pentru moment,
va putea fi pus in Aşteptare, însemnând că Operatorul nu va auzi soneria
(sau sunetul), iar apelantul nu va auzi Operatorul. Dacă Operatorul doreşte
să monitorizeze apelul, aceasta însemnând, ascultarea apelanului, o va
putea face.
o Operatorul poate reda un Mesaj de Voce celeilalte părţi atunci când un
apel este în aşteptare.
Transferul
o Un apel telefonic în desfăşurare poate fi transferat unui alt Operator sau
către o altă Echipă de Operatori.
 o Apelul va apărea ca Apel în Coada de Aşteptare a Apelului a Operatorului
receptor şi când i se răspunde, conexiunea trebuie sa fie stabilită şi Cazul
corespunzător trebuie sa fie prezentat.
Conferinţa
o Operatorul va putea crea o Conferinţă, cu doi sau mai mulţi participanţi,
interni sau externi, unde fiecare participant aude pe fiecare dintre ceilalţi
participanţi.
o Oricare Operator participant poate adăugă noi membri la Conferinţă sau
poate închide oricărui membru existent.
Medierea
o Operatorul va putea conecta două părţi externe fără a participa ea/el
însăşi/însuşi, prin functia de Mediere.
o Când Medierea trebuie sa fie efectuată pentru un telefon de ieşire, la care
încă nu s-a răspuns, Sistemul va supraveghea ca apelului de ieşire să i se
răspundă într-o perioadă specifică (configurabila) de timp. În caz contrar,
un Apel trebuie sa fie generat către Operatorii relevanţi şi atunci când i se
răspunde, conexiunea trebuie sa fie stabilită cu apelantul.
o Operatorul poate vedea şi se poate alătura Medierilor relevante pentru
Profilul său de Lucru actual.
Cererea de alăturare
o Un Operator se va putea alătura unei conversaţii în derulare prin
transmiterea unei Cereri de Alăturare către Operatorul care controlează
conversaţia.
o Operatorul care controlează conversaţia va putea, fie să accepte, fie să
nege cererea. Cazul corespunzător, ulterior acceptării cererii,trebuie sa
fie prezentat către Operatorul solicitant.
Monitorizare Asistată
o Un Operator care controlează un apel poate solicita asistenta unuia sau
mai multor Operatori care să gestioneze apelul.
o Operatorul poate alege să selecteze un alt Operator specific atunci când
solicita asistenta sau să selecteze o cerere generală de asistentă.
o Solicitările vor fi prezentate ca Apeluri în Coada de Aşteptare a Apelului.
Când Operatorul asistent a răspuns la solicitare, trebuie sa fie posibil ca
Operatorul care controlează apelul să schimbe funcţia cu cea de Operator
asistent (aceasta însemnând că Operatorul care controlează va deveni
asistent şi viceversa). Când un Operator răspunde la solicitarea pentru
Monitorizare Asistata, Cazul corelat trebuie sa fie prezentat acestuia.
o Când solicitantul ajutorului lasă apelul părţilor interne (Operatori) va
rămâne în conferinţă internă.
Monitorizare Asistată Externă
o Monitorizare Asistata Externă va da posibilitatea unui Operator să solicite
monitorizarea asistata de la una sau mai multe părţi care nu folosesc
Sistemul. Asistentul extern va putea discuta cu Operatorul pentru a da
sfaturi cu privire la situaţie sau alegerea resurselor.
Apel de Voce Intern
o Un apel de voce intern trebuie sa fie un Apel efectuat de la un Operator la
altul. Apelul trebuie sa fie prezentat Operatorului contactat în Coada de
Aşteptare a Apelurilor. Când Operatorul va răspunde Apelului, Cazul
corespunzător Apelului va fi prezentat.
Apel de ieşire
o Operatorul poate efectua şi apeluri telefonice de ieşire din Sistem.
o Când Operatorul efectuează apeluri telefonice de ieşire şi adresantul este
ocupat, Sistem va incerca să ajungă la destinatar prin re-apelare
automată. Re-apelarea automatica va continua până când perioada de timp
limită (stabilită la nivel de sistem) va fi atinsă sau până când Operatorul
închide apelul.
o Trebuie sa fie de asemenea posibil, ca Operatorul sa sune înapoi, avand in
prezentate automat Cazul asociat cu numărul de telefon.
Surdina/Mut
o Operatorul va putea dezactiva microfonul setului cu casca, spre exemplu
în cazul în care el sau ea au nevoie să tuşească. Ca urmare, cealaltă parte
sau parţi în conversaţie, nu il va/vor auzi pe Operator.
Izolaţi şi Ascultaţi
o Într-o conversatie, Operatorul va putea izola orice alt participant la apelul
vocal. Rezultatul trebuie sa fie ca partea izolata nu va auzi nicio alta
parte. Dupa izolare numai Operatorul care a iniţiat izolarea va auzi partea
izolată. Partea izolată nu va auzi nimic din conversaţia în desfăşurare în
timp ce este izolată.
Închidere Apel
o Un apel telefonic va putea fi terminat când oricare dintre cele două părţi
încheie Apelul.
Semnalizarea cu Tonuri
o Apelurile telefonice de ieşire (printr-un Contact), vor putea fi configurate
pentru a avea semanlizare cu Tonuri. Semnalizarea cu Tonuri va include
trimiterea sau detectarea tonurilor.
o Dacă Operatorul trebuie sa fie implicat în transmiterea de Tonuri, poate,
fie să insereze caracterele specifice sau poate utiliza Pachetele de Tonuri
predefinite.

Sistemele suportate prestabilite de ton sunt DTMF (Dual Tone Mulţi Frequency) şi
CCIR. Trebuie sa fie posibil să se configureze noile sisteme de sunet într-o manieră
generală, în care tonurile unice sunt definite de frecvenţa şi durată

6.2.3 Managementul sistemului de comunicatii.

Sa permita definirea si alocarea de roluri si responsabilitati:

o Va permite administratorului sistemului sa defineasca roluri si

responsabilitati pentru toti utilizatorii sistemului;
 o Va permite Operatorului, in functie de nivelul de autorizare, să modifice în
timpul funcționării cozile de apeluri telefonice la care are acces și
propriile roluri, fără a fi nevoie ca mai întâi să se deconecteze si sa se re-
conecteze pentru a încarca un profil de utilizator diferit, sau o interfata
grafica diferita
o Va permite subscrierea la anumite cozi de primire apeluri, si la
participarea in absorbirea preaplinului („overflow”) din alte cozi; spre
deosebire de modul de operare bazat pe ACD, in modul de operare bazat
pe roluri si responsabilitati Operatorului i se vor prezenta cozi de apeluri
la care are acces, si pentru care va trebui sa efectueze o actiune („click”)
pentru a prelua un apel de urgenta
o Modul de operare bazat pe roluri si responsabilitati va permite
modificarea seturilor de atributii și a posibilitatilor de preluare a
preaplinului
o Nu vor exista restrictii în privința numărului de roluri si responsabilitati
atribuite unui Operator
o Nu vor exista restricții privind numărul de Operatori atribuiti unui singur
rol;
o Va fi generată o alarmă în cazul în care nici o resursă nu este atribuită
unui anumit rol;
o Dacă un apel rămâne fără răspuns pentru un anumit interval de timp
configurabil, acesta va fi redirectionat catre toti ceilalți utilizatori care au
atribuit rolul de „preaplin” adecvat și va fi identificat ca atare ca apel fără
răspuns/redirecționat
o Un buton de „parasire” va permite unui Operator să elibereze toate
rolurile care ii sunt atribuite in mod curent, pentru a prelua alte roluri IVR
o identificat ca atare ca apel fără răspuns/redirecționat
o Un buton de „parasire” va permite unui Operator să elibereze toate
rolurile care ii sunt atribuite in mod curent, pentru a prelua alte roluri

6.2.4 Solutia de supravieturire

Solutia de supravieturire va fi reprezentata de o centrala telefonica (PABX) ce va
functiona ca si centrala telefonica de intreprindere in situatia functionarii normale a
sitemului SIA112 Sistemul de comutatie telefonica va trebui sa realizeze urmatoarele
sarcini
o Va asigura funcţia de backup pentru preluarea apelurilor de
urgenţă, pentru un număr de minim 60 apeluri simultane pe terminale
proprii şi transferul acestora către dispeceratele de urgenţă tot pe
terminalele proprii;
o Va avea o structură modulară, extensia capacităţii să se poată face uşor,
prin adăugarea de noi module, cu modificări minime hardware şi software,
fără întreruperea funcţionării sistemului;
o Va avea redundanţă hardware şi software la nivelul componentei de
procesare astfel încât traficul de intrare şi convorbirile telefonice în
desfăşurare să nu fie întrerupte la momentul producerii unei defecţiuni la
nivelul acestei componente;
o Va avea redundanţă hardware/software la nivelul componentei de
comutaţie astfel încât convorbirile telefonice în desfăşurare să nu fie
întrerupte la momentul producerii unei defecţiuni la nivelul acestei
componente;
o Va permite salvarea tuturor configuraţiilor software pe mediu dedicat
de stocare intern şi restaurarea configuraţiilor software de pe mediu de
stocare extern;
o Va implementa o următoarele concepte:

o “High Availability” = arhitectură distribuită, flexibilă care

permite dezvoltarea pas cu pas în funcţie de necesităţile
beneficiarului, astfel încât orice extensie ulterioară a capacităţii să
se poată face uşor, prin adăugarea de noi module, cu modificări
minime hardware şi software, fără întreruperea funcţionării
sistemului;
o “Hot pluggable” = va p ermite inlaturarea şi adaugarea d e
componente hardware în sistem fără oprirea alimentării sau a
funcţionării s i s t e m u l u i .
o Va trebui să permită accesul facil pentru diverse operaţii ca: înlocuiri de
acumulatori, conectarea/deconectarea unor cabluri (conectori), efectuarea
unor eventuale măsurători electrice fără a fi necesară oprirea
echipamentului;
o Va avea minim un certificat care respectă un standard european sau
internaţional pentru următorii parametrii: electric, compatibilitate
electromagnetică şi securitate în exploatare;
o Va avea redundanţă hardware la nivelul componentei de electroalimentare
astfel încât traficul de intrare şi convorbirile telefonice în desfăşurare să
nu fie întrerupte la momentul producerii unei defecţiuni la nivelul acestei
componente;
o Va asigura legături telefonice interne şi externe cu eliberarea automată a
circuitelor;
o Va asigura legături telefonice trunchi la trunchi cu eliberarea automată a
circuitelor;
o Va asigura posibilitatea configurării soft a echipamentului în mai multe
departamente, grupuri de utilizatori, independente din punct de vedere al
traficului şi al serviciilor;
o Va asigura funcţii de diagnosticare şi alarmare în timp real, incluzând
autotestarea echipamentului, izolarea defecţiunilor, afectări minime ale
grupurilor de abonaţi şi trunchiuri;
o Va asigura activarea serviciilor şi a facilităţilor prin coduri de acces
programabile;
o Va asigura modalităţi de restricţionare a accesului la abonaţi, trunchiuri,
servicii;
o Va permite tonuri (semnalizări) pentru toate stările relevante în faza de
repaus, de proces sau de progres a unei legături;
o Va permite tonuri şi semnalizări de apel sosire diferite pentru apeluri:
interne şi externe;
o Va asigura serviciul de tip ACD (Automatic Call Distribution) prin
configurarea a cel putin 2 grupuri ACD;
o Va asigura funcţia de apel în aşteptare;
o Va permite reapelarea ultimului număr format atât pe linie de interior cât
şi pe trunchi;
o Va permite plan de numerotare flexibil;
o • Va permite funcţie de redirecţionare a apelurilor;
o Va permite funcţia de deblocare automată după un timp prestabilit pentru
apelurile nefinalizate din diferite cauze;
o Va permite setarea şi modalităţile de redare a mesajelor vocale de
preîntâmpinare a unui apel;
o Va permite redarea de fişiere de sunet pentru aşteptare/parcare din sursă
internă şi externă;
o Va permite transmiterea tonalităţilor de revers apel (sonerie şi ocupat),
atât către abonaţii externi (în urma transferului unei legături externe), cât
şi către operatoare;
o Va permite convorbiri între terminalele VoiP şi între terminale VoiP
şi alte terminale/trunchiuri;
o Va permite rutare alternativă realizând rutarea apelului către o destinaţie
prin diferite rute;
o Va permite apelare directă pentru ca apelurile sosite pe liniile externe de
intrare să poată fi rutate direct către extensii;
o Va permite programarea conectării directe a apelurilor primite pe linii de
intrare la terminale predefinite;
o Va avea funcţia de acces direct în sistem – facilitate care permite
utilizatorilor externi (apeluri de voce) să apeleze utilizatorii interni unei
centrale;
o Va permite configurarea de extensie virtuală, afiliată unui număr, ceea
ce oferă posibilitatea utilizării facilităţilor de “Mobilitate”;
o Va permite rutare cu cost redus prin posibilitatea sistemului de a selecta
rutele economice din punct de vedere costuri, pentru apelurile de ieşire în
reţeaua publică;
o Va permite, pentru convorbiri între terminalele interne/locale,
identificarea apelantului după nume;
o Va permite analiza şi conversia numerelor formate sau recepţionate (A-
number şi B- number), precum şi bararea (blocarea) unor numere aflate
într-o listă şi a codurilor pentru servicii;
o Va permite rutarea în reţea privată de capacitate mare şi capabilitatea de
conversie de numerotaţie pentru o reţea privată;
o Va permite rerutare automată – oferă posibilitatea de a programa rutele
sau liniile externe individuale pentru rerutare către o poziţie de răspuns
atunci când un apel de pe o linie externă găseşte congestie, număr vacant,
ocupat, indisponibil sau nu răspunde;
 o Va permite stocarea informaţiilor privind apelurile, înregistrarea tuturor
tipurilor de apeluri efectuate, cu informaţii despre număr, dată, oră,
durata convorbire, durata revers apel şi porturile externe utilizate;
o Va permite alegerea limbii în care se doreşte să fie afişat textul mesajelor
pe ecran;
o Va permite stocarea informaţiilor de trafic – datele să poată fi transmise
prin portul Ethernet la un server din reţea.

6.3 Managementul cazurilor de urgenta

Primul obiectiv al procesului de management al incidentelor este de a restabili

situatia normala, cât mai repede posibil și pentru a minimiza impactul situatiei de de
criza, asigurându-se astfel că cele mai bune niveluri posibile ale calității serviciilor și
disponibilitatea sunt menținute.

Astfel sistemul trebuie sa propuna si sa ofere mecanisme pentru:

o înregistrarea incidentelor
o preluarea informațiile apelantului despre apelant din bazele de date ANI
ale operatorilor de comunicatii
o vizualizare istorica a datele apelantului, în cazul în care acesta are apeluri
anterioare din același număr
o clasificarea evenimentului pe baza unui nomenclator si completarea
automata a informatiilor specifice tipului de eveniment.
o determinarea locației apelantului cat și a locației incidentelor
o afișarea locației incidentului pe platforma informational-geografica
o schimbare locației incidentului, fără a schimba datele despre apelant
o actualizare date despre incidente, de câte ori este necesar
o introducerea informatiilor suplimentare și realizarea unui rezumat de
incident.
o transmitere fisa de caz catre unul sau mai multe agentii cu responsabilitati
in rezolvarea solicitarii/sesizarii.
o evidentierea în mod automat a unor incidente relevante pentru incident, în
funcție de clasificarea incidentului.
o generarea de rapoarte pentru incidentele închise.

In acest sens sistemul de management de incidente trebuie sa includa cel putin

urmatoarele functionalitati si capabilitati, intr-o singura interfata:

o sistemul trebuie sa includa functia de primire apel nou de solicitare si sa

semnaleze cazul catre Operator.
o sistemul trebuie sa ofere posibilitatea Operatorului de a prelua in mod
automat sau manual, informațiile apelantului fie din baza de date cu
abonati telefonici, fie transmise de catre operatorul telecom, pentru a
crea o înregistrare de incident.
 o Sistemul trebuie sa prezinte in mod automat date precum numarul de
telefon, nume propietar, adresa pentru aplurile de pe fix, sau informatia
de celulta pentru apelurile mobil, alte informatii ale locatiei, unde este
posibil si suplimentar sa poata prelua manual date la cererea operatorului.

Functiile de management al incidentelor trebuie sa acopere cel putin urmatorele

functionalitati de lucru:

o La preluarea unui apel, sau la acțiunea benevola a unui operator, sistemul

trebuie să deschidă un caz nou, unde toate informațiile relative la un
incident trebuie înregistrate: clasificarea, poziția, întrebările și
răspunsurile din funcția de suport de interviu, protocolul operațional
propus de către sistem, acțiunile intreprinse de către fiecare operator,
etc.
o Este posibil transferul unui caz către alt grup de operatori.
o Este posibil ca mai multi operatori să lucreze simultan la același caz

Sistemul trebuie sa ofere interfeţe grafice pentru utilizatori ergonomice si

prietenoase, orientate spre introducerea cat mai eficienta a informatiilor aceste
incluzand:

o liste derulante pentru toate campurile care pot accepta doar valori
standard (nomenclatoarele de caz nivelul 1 si nivelul 2, etc);
o propunerea de variante de auto-completare a campurilor, pe baza
caracterelor introduse de catre Operatorul 112 si a datelor introduse
anterior;
o casute de selectie de tip buton radio si/sau check-box;
o validarea datelor introduse;
o acces direct („one click”) la funcţiile frecvent utilizate (exemplu: initierea
unui apel vocal printr-un singur click pe un hyperlink dintr-un material
suport de tip ghid/sfat);
o navigare rapidă folosind combinatii de taste.

Sistemul trebuie sa ofere capabilitatea realizarii unor interfete flexible pentru

diferitele categorii de forte implicate in managementul situatiilor de urgenta, fara
dezvoltarea de cod. In acest sens fisa de caz trebuie sa poata fi construita din
blocuri de informatie grupate pe tipuri de informatii, in functie de bunele practici
din domeniu.

Sistemul va trebui sa ofere posibilitatea construirii interfetei finale prin

amplasarea bolourilor functionale ale unei categorii de resurse in functie de
strategia definita de fiecare categorie. In acest fel sistemul va permite
implementarea unor interfete diferite in functie de necesitatile categoriilor de
forte gestionate de sistem.

Sistemul va permite adaugarea de informatii specifice unei categorii de forte, prin

adaugarea unui bloc functional definit in functie de nevoile si particularitatile
categoriei de forte.
Sistemul va putea adauga butoane de functii in meniul aplicatiei, fara ca pentru
aceasta sa fie nevoie dezvoltarea de cod.

Sistemul va permite comunicatia bidirectionala, in scopul schimbului de informatii

cu alte sisteme externe care pot contribui la realizarea imagnii operationale
comune.

Informatiile vor putea fi transmise/receptionate prin interfete standard de tip web

services.

Sistemul trebuie sa includa capabilitatea de semnalarea similitudinilor intre

informatiile provenite de la mai multe apeluri distincte, pe baza unor atribute
comune, si oferirea de suport Operatorului 112 pentru a le corela, si a lua decizia
de a le consolida, daca este cazul, la nivelul unui singur incident tratat in sistem;

Sistemul trebuie sa includa capabilitatea de a notificare imediat respondenti

(departamente, institutii sau persoane), la nivel individual sau grupati in liste de
distributie, prin canale de comunicatie diferite (apel telefonic, email, fax, SMS,
sisteme de tip PA/PAGA)

Sistemul trebuie sa includa capabilitatea de evaluare a credibilitatii apelului, prin

afisarea automata a istoricului de evenimente semnalate anterior de catre acesta,
in cazul in care asemenea semnalari au existat, si etichetarea credibilitatii
apelului de catre Operatorul 112, pe baza suportului de decizie oferit de sistemul
informatic, si a evaluarii proprii;

Sistemul trebuie sa includa capabilitatea de asociere a apelului de urgenta cu

surse de documentare de tip multimedia, prin care operatorul sa poata atașa
imagini, fisiere video si de alte tipuri, primite in direct sau inregistrate, in cadrul
aceluiasi dosar de caz;

Sistemul trebuie sa includa capabilitatea de investigare a incidentelor, incluzand

cautare incident utilizând criterii multiple.

Sistemul trebuie sa poata asigura initializarea dosarului de caz, automat, odata

cu preluarea apelului din coada de apeluri.

Sistemul trebuie sa asigure initializare fisa de caz, pentru inregistrare solicitare,

pentru distribuirea acesteia catre factori de decizie, urmarirea si rezolvarea
sesizarii/solicitarii.

Fisa de caz, trebuie sa fie cel putin in limba romana, cu campuri de completare
caz si ferestre de selectie, configurabile, la instalare pe necesitati beneficiar si
ulterior usor de modificat, la cerinte procedurale ulterioare care se pot solicita
a fi implementate (shimbare legislative, imbunatatire procedurala).

Sistemul trebuie sa fie capabil să lucreze cu si fără functionarea concomitenta a

componentei GIS. Atunci când se lucrează fără ajutor componentei GIS sistemul ar
trebui să păstreze cele mai importante functionalitati printre care:

o Preluarea si dispecerizarea apelurilor de urgenta

o Gestionare de functionalitatilor complete de voce și transferuri de date
integrate
 o Identificare Automată Număr Apel Telefonic (ANI/ALI)
o Clasificarea incidentelor, cazurilor, planuri și sfaturi
o Managementul resurselor, inclusiv sugestia cele mai potrivite resurse
pentru o interventie

6.3.1 Clasificarea Incidentelor

Functia de clasificare a incidentului, trebuie sa fie capabila să:

o clasifice automat incidentul pe baza răspunsurilor la întrebările din

instrumentul de suport de interviu
o posibilitatea de a clasifica automat un incident pe baza numerelor de apel
speciale (ex. apel venit de la un obiectiv special se clasifica automat pe
cazul specific al obiectibului special)
o clasificarea manuală a incidentului în funcție de arborele de indecși de
clasificare a incidentelor
o Propunerea automată de protocol operațional
o In funcție de clasificarea incidentului și localizarea apelantului, respectiv a
incidentului, sistemul trebuie să ii furnizeze operatorului un protocol
operațional care sa-l ghideze in clasificarea incidentului
o Protocolul operațional trebuie să aibă etape obligatorii și/sau acțiuni
opționale care trebuie efectuate
o Fiecare nod de nomenclator trebuie sa poata avea asociata o prioritate.
o Nomenclatorul trebuie sa poata fi structurat pe cel putin trei niveluri de
detaliere
o Tipurile de acțiuni trebuie să fie, cel puțin:
o Declanșarea unui apel telefonic către una sau mai multe destinații
predefinita, in functie de diferiti algoritmi (cel putin mecanismele de a
suna secvential pana primeste un raspuns, si cel de a suna concomitent
o lista de apelanti)
o Transmiterea unui SMS către o destinație predefinita
o Transmiterea unui email către o destinație predefinita
o Transferul informației cazului curent către alt rol de operator (fie din
cadrul aceleași organizații, fie din cadrul altei organizații)
o Transmiterea datelor incidentului către sisteme externe
o Acces la documente și linkuri http
o Sistemul trebuie sa includa capabilitatea de a oferi scenarii in mod
automat de catre sistem Operatorului 112, in functie de datele
introduse de acesta, pe baza raspunsurilor apelantului, operatorul
avand posibilitatea de a accepta scenariul implicit propus, sa poata
selecta un altul sau sa il modifice ulterior, in timpul derularii
interviului;
o sistemul trebuie sa includa capabilitatea de reevaluare si actualizare
automata a nivelului de criticitate (escaladare) al cazurilor deja
inregistrate, pe baza unor criterii prestabilite, configurabile si
incadrarea acestuia in alta categorie. Odata reincadrat sistemul va
 actualiza dinamic informatiile (suportul de interviu, elementele de
automatizare) in conformitate cu noua clasificare;
o In functie de clasificarea incidentului sistemul trebuie sa poata oferi
capabilitatea de notificare a diverselor persoane si entitati prin:
o asigurarea facilitatii de notificare instantanee a unui incident.
o agentul sa poata notifica, alte departamente sau personal direct, după
sau in timpul înregistrarii unui incident.
o listele de notificare pot fi create în prealabil de către personalul
operational.

6.3.2 Suport pentru interviu

o Sistemul trebuie sa ofere capabilitatea de ghidare a Operatorului 112
pentru colectarea in mod eficient a informatiilor utile de la apelant, in
functie de tipul de situatie de urgenta, prin definirea de scenarii
sablon, care contin intrebari-tip intr-o anumita succesiune, sfaturi sau
recomandari;
o Suportul pentru interviu trebuie sa permita definirea de campuri sau
actiuni obligatorii pentru operator.
o Sistemul trebuie sa nu permita actiuni ulterioare unei actiuni
obligatorii in situatia in care acesata nu a fost executata iar ordinea
executarii ei este stricta.
o Sistemul trebuie sa permita capabilitatea de accesare a altor baze
informationale pentru clarificari suplimentare asupra
sesizarii/solicitarii.

6.3.3 Jurnalizare
Sistemul trebuie sa ofere capabilitatea inregistrare automata a evenimentelor
externe care declanseaza lantul de procesare al evenimentelor de urgenta, si a
etichetelor temporale asociate acestora:

o aparitia unui apel de voce catre 112;

o primirea unui SMS de la unul dintre numerele pre-inregistrate in
sistem ca fiind asociate unor persoane cu nevoi speciale;
o primirea unui fax de la unul dintre numerele pre-inregistrate in sistem
ca fiind asociate unor persoane cu nevoi speciale;
o primirea unei semnalari de tip eCall.

Sistemul trebuie sa permita inregistrarea automata a tuturor actiunilor intreprinse

de catre Operatori si Dispeceri in sistem, si a etichetelor temporale asociate
acestor actiuni:

o preluarea apelului de catre un Operator 112;

o introducerea de caractere in campurile de text ale fisei de incident;
o stergerea unor caractere introduse anterior;
o efectuarea unei alegeri intr-un camp cu valori predefinite;
 o initierea transferului catre un Dispecer SSU;
o preluarea apelului de catre Dispecerul SSU;
o asocierea unui fisier multimedia cu incidentul semnalat;
o introducerea de informatii specifice si actualizarea fisei de incident de
catre Dispecerul SSU, inclusiv alocarea de resurse de interventie,
acceptarea misiunii de catre resursa de interventie, interventie in
desfasurare la locul incidentului, interventie finalizata.

Sistemul trebuie sa ofere capabilitatea de reconstituire exacta, pas-cu-pas, a

fiecărui caz de urgenţă care a fost tratat in sistem („audit trail”);

6.3.4 Regasire evenimente

Sistemul trebuie sa ofere mecanisme Supervizorului astfel incat acesta sa poata:

o Căuta orice incident, utilizând criterii multiple, minim: numărul de

incident, ID-ul apelantului, numele apelantului, localizarea apelantului
o Asculta apelurile înregistrate și să le descarce.

6.3.5 Monitorizare desfasurare interventie

o sistemul trebuie sa ofere capabilitatea de monitorizare şi management
centralizat al operaţiunilor, de catre utilizatorii autorizati (Sef serviciu,
Sef CPAU, Sef tura/supervizor);

6.3.6 Managementul resurselor de interventie (etapa a doua a)

Sistemul trebuie sa poata implementa managementul resurselor aflate la
dispozitia diferitelor categorii de forte. Aceasta caracteristica va permite
SSUurilor sa realizeze un o gestiune unitara a resurselor.

Stucturile de date ce vor trebui gestionate de sistem astfel incat acesta sa fie
agnostic din punct de vedere al tipului de organizatie detinatoare de forte si
mijloace de interventie sunt prezentate in figura de mai jos.

Sistemul va putea defini pentru fiecare Organizatie una sau mai multe
Suborganizatii, pentru fiecare Suborganizatie una sau mai multe Resurse.
Suborganizatie
O suborganizatie este o entitate subordonata din punct de vedere organizational
unei organizatii si care detine un numar variabil de resurse.

Sistemul trebuie sa poata asocia unei suborganizatii o zona de responsabilitate

geografica.

Sistemul va trebui sa poata defini suborganizatiile de acleasi tip cu care o

anumita suborganizatie poate coopera in situatia in care amploarea evenimentului
de urgenta depaseste capacitatea acesteia.
Planificarea schimburilor
Sistemul va putea implementa un mecanism de planificare a schimburilor unei
suborganizatii.

Planificarea schimburilor va avea in vedere cel putin urmatoarele criterii:

 o Data si ora la care incepe schimbui
o Data si ora la care setermina schimbui
o Componenta schimbului in termeni de:
 Resurse
 Personal
 Echipamente 

Sistemul trebuie sa considere in mod automat resursele planificate in schimburi

ca fiind disponibile pe durata schimbului si sa scoata de la dispecerizare
resursele asociate unui schimb cand acesta se termina.
Resursa
Sistemul trebuie sa implementeze conceptul de resursa.

O resursa apartine unei suborganizatii.

Sistemul trebuie sa permita clasificarea resurselor unei organizatii in categorii de

resurse.

Pentru a putea asigura managementul eficient al resurselor de interventie,

fiecare resursa va avea definite responsabilitatile geografice.
Competente
Sistemul va putea defini, pentru fiecare Organizatie, tipurile de competente
existente la nivel de suborganizatii si/sau resurse. Aceasta informatie se va avea
relevanta pana la nivelul suborganizatiilor si resurselor asociate organizatiei.
Echipaje
Sistemul trebuie sa aibe capabilitatea de a construi echipaje asociate resurselor.
Puncte de contact
Sistemul trebuie sa poata defini puncte de contact asociate resurselor.

O resursa poate avea mai multe puncte de contact in functie de tehnologia avuta
la dispozitie. Astfel, o resursa poate avea un numar de telefon mobil si/sau un
echipament radio Tetra sau Analogic.

Sistemul trebuie sa poata considera punctele de contact ale unei resurse in

mecanismele de planificare a interventiei. Astfel, in situatia in care o anumita
resursa este de serviciu intr-o anumita regiune, sistemul va putea lua legatura
automat folosind echipamentul definit ca fiind activ.
Echipamentele unei resurse
Sistemul trebuie sa poata gestiona echipamentele existente la nivelul
suborganizatiilor. Astfel, echipamentele pot fi asociate unor resurse.

In vederea unei gestionari unitare a unei baze eterogene de echipamente sistemul

va trebui sa poata defini categorii de echipamente.

Sistemul trebuie sa poata implementa un mecanism de suport al deciziei prin

care, pentru o anumita situatie de urgenta sa poata propune operatorului din SSU
sau coordonatorului interventiei, resursele necesare pentru interventie pe baza
informatiilor preplanificate in procedurile operationale, a categoriei de resurse,
categoriilor de echipamente existente pe resursa si/sau a competentelor
acesteia.
Misiune
O misiune este o actiune specifica ce se executa de o resursa intr-un context de
interventie la dezastru.

O misiune este formata dintr-un set de actiuni in conformitate cu o procedura

operationala.

O misiune trebuie intotdeauna sa aibe o stare care sa reflecte gradul de

indepinire a misiunii.

Sistemul trebuie sa poata implementa conceptul de misiune.

Sistemul trebuie sa poata asocia o misine unei resurse in urmatoarele moduri:

o Automat prin executia unei linii din procedura operationala unui nod
de nomenclator
o Manual, de catre coordonatorul interventiei in functie de
disponibilitatea resursei respective.

Sistemul trebuie sa permita atribuirea mai multor misiuni unei resurse.

Sistemul trebuie sa permita implicarea mai multor resurse in gestionarea unei

situatii de urgenta.

Sistemul trebuie sa poata limita numarul de resurse implicate in gestionarea unei

situatii de urgenta sau a numarului de misiuni asociate unei resurse.

In momentul implicarii unei resurse intr-o situatie de urgenta sistemul va crea

automat o misiune pentru aceasta.

Sistemul trebuie sa poata jurnaliza informatiile legate de resursa si misiunile

acestora in vederea realizarii de rapoarte operationale despre acestea.
Starea resursei si a misiunii
O resursa fara misiune trebuie sa se poata afla intr-o anumita stare.

Cand unei resurse i se va atribui una sau mai multe misiuni trebuie ca pentru
fiecare misiune sa existe o stare asociata acesteia.

Sistemul trebuie sa permita gruparea starilor unei misiuni in urmatoarele

categorii:

o Fara misiune
o Planificata pentru misiune
o Misiune atribuita dar neconfirmata
o In desfasurare

In vederea implementarii unor modalitati eterogene de operare al diferitelor

structure/organizatii, sistemul va putea defini stari particulare ale resurselor
pentru categoriile:

o Fara misiune
 o Implicat in misiune

Sistemul trebuie sa implementeze un mecanism de suport decizional care sa aibe

in vedere starea resurselor si a misiunilor asociate acestora. Ca rezultat al
acestui mecanism si in functie de clasificarea interna a dezastrelor implementata
in modulul de clasificare/elaborare planuri de interventie, sistemul trebie sa ofere
coordonatorului interventiei/operatorului din centrul de coordonare o propunere
de resurse ce pot fi implicate in gestionarea situatiei respective.
Atribute specifice
Sistemul trebuie sa permita definirea de noi parametrii la nivelul resurselor in asa
fel incat, modulul de management al resurselor de interventie sa permita
gestionarea unui numar cat mai mare de situatii particulare.
Corelatia stare resursa si stare misiune
Sistemul trebuie sa poata combina starile resursei si a misiunii acesteia pentru a
propune automat o noua resursa ce poate interveni intr-o situatie.

O resursa va avea intotdeauna o stare a sa care este un parametru de planificare

si urmarire a ceea ce executa acea resursa.

Similar, o misiune va avea asociata starea acesteia care reprezinta un parametru

de planificare si urmarire a progresului activitatilor asociate misiunii.

Sistemul trebuie sa implementeze un mecanism care sa poata urmari corelatia

dintre starea resursei si starea misiunii, astfel incat in sitatia in care aceasta
corelatie permite, sa poata decide automat daca resursa poate fi propusa pentru
o noua interventie sau nu.

In vederea urmaririi usoare a implicarii resurselor in rezolvarea unei situatii si

posibilitatea de a defini noi stari, relevante pentru fiecare subunitate implicata in
gestionarea dezastrelor, atat la nivel de resursa cat si la nivel de misiune
sistemul va implementa conceptul de categorie de stare (atat pentru resursa cat
si pentru misiune).

Sistemul va avea in vedere categorii de stari in analiza situatiei si furnizarea

suportului decisional.
Angajarea resurselor
In situatia in care coordonatorul interventiei implica o resursa in rezolvarea unei
situatii sistemul trebuie sa creeze automat o misiune pentru acea resursa. In acel
moment resursa trebuie sa aibe starea “Implicat in misiune" iar misunea va avea
una dintre categoriile de stare “Planificat pentru misiune”, “Misiune atribuita dar
neconfirmata” sau “Implicat in misiune”.

Dispecerul trebuie sa poata planifica resurse pentru a efectua o misiune in viitor.

In acel moment sistemul va trebui sa marcheze starea resursei “Fara misiune” iar
a misiunii “Planificat pentru misiune”. Sistemul va trebui sa poata schima automat
starea resursei si respective a misiunii in momentul in care resursa trebuie sa
execute misiunea si sa avertizeze coordonatorul/operatorii centrului.
In vederea obtinerii celei mai bune resurse disponibile pentru interventie
dispecerul va avea la dispozitie diferite posibilitati de a analiza starea resurselor
astfel:

o Situatia resurselor disponibile intr-o subunitate - functionalitate

necesara pentru situatiile in care resursele raman pentru mai mult
timp in subunitati
o Situatia resurselor disponibile intr-o anumita arie geografica -
functionalitate necesara pentru situatiile care necesita implicarea
dinamica a resurselor in gestionarea unei situatii
o Situatia resurselor planificate pentru misiune
o Propuneri facute de sistem prin mecanismele sale interne, mecanisme
ce au in vedere urmatoarele criterii:
 Starea resursei
 Starea misiunii
 Aria geografica
 Tipul de interventie
 Tipul de echipare necesara
 Tipul de competente necesare

6.3.7 Aplicatie unica de tip Administrator

o Aplicaţia unica de tip Administrator trebuie sa fie utilizată pentru a
putea configura toate componentele majore Sistemului (care sa
acopere cel putin in totalitate functionalitatile de Management
Incident, Comunicatii, managemetul pragurilor de escalare,
managementul planurilor de interventie, managementul suporturilor de
interviu, customizarea interfetei de utilizator, access Operatori,
definirea oragnizatiilor), precum şi pentru a introduce parametrii
operaţionali in Sistem. Trebuie sa poata fi de asemenea utilizată
pentru a configura sistemul, pentru a defini rolurile de lucru, accesul
şi autorizările la anumite funcţionalităţi din Sistem.
o Un Administrator cu nivel maxim de autoritate, va avea posibilitatea
de a permite sau restricţiona accesul la unul, mai multe sau toate
nodurile din Sistem pentru alţi Administratori sau Operatori ai Sistem-
ului. Un profil de Autoritate va guverna drepturile de acces la
aplicaţiile Operator şi Administrator.
o Sabloanele de Interfete Utilizator vor putea fi configurate în Aplicatia
Administrator. Modul de aranjare a subcomponentelor grafice ale
interfetei grafice a unui Caz trebuie sa poata sa fie configurat printr-
un set de blocuri de funcţii.
o In Aplicatia Administrator trebuie sa fie posibilă configurarea unor
răspunsuri pentru anumite întrebări care să declanşeze anumite sfaturi
şi întrebări prin conectări intre sfaturi şi întrebări. Un anumit răspuns
la o întrebare trebuie sa permita sa fie configurat să extindă domeniul
unui Caz, şi chiar să schimbe selecţia Indexului. Trebuie sa fie posibil
să permită Operatorului se selecteze mai multe Indexuri pentru un
 anumit Caz prin configurarea opţiunii de Selectare de Indexuri
Multiple
o Planurile de Acţiune vor putea de asemenea sa fie configurate în
Aplicatia Administrator pentru a ghida Operatorii să rezolve un Caz.
Planurile de Acţiune vor putea avea instrucţiuni care variază în funcţie
de data şi ora. Trebuie sa fie posibil să fie definite diferite Tipuri de
Zile care să aibă diferite caracteristici bazate pe ziua săptămânii sau
data calendaristica. Anumite instrucţiuni se vor putea marca ca fiind
obligatorii pentru rezolvarea Cazului. Dacă o instrucţiune obligatorie
trebuie sa fie inclusă, Cazul nu va putea fi închis până când acea
instrucţiune nu este marcată ca fiind executată.

6.4 Platforma informational-geografica

Aplicatia GIS din cadrul aplicatiei de dispecerizare a Centrului de Preluare Apeluri de

Urgenta (CPAU) trebuie sa fie integrata in ceea ce priveste managementul de
resurse, al functiilor de comunicatie, al pozitionarii evenimentului cu transportul
informatiilor in fisa de caz in aplicatia receptionare si de dispecerizare a apelurilor
112. Transferul de informatii trebuie sa se faca fara operatii suplimentare din partea
operatorului (precum copiere/lipire).

Odata cu cresterea informatiilor primite in Centrul de Preluare Apeluri de Urgenta

112, instrumentele si aplicatiile GIS ofera o interpretare vizuala si o corelare a
datelor din punct de vedere spatial, lucru extrem de important in conditiile unei
situatii de urgenta.

Sistemul va include o interfaţă bine definită care se poate integra cu Sisteme

Informaţionale Geografice (Geographical Information System - GIS). Sistemul GIS îi
va apărea Operatorului ca o altă componentă a aplicaţiei Operator, care oferă un
concept geografic mai precis.

Prin intermediul interfeţei, Sistemul şi Sistemul GIS vor schimba date despre
Resurse, Cazuri şi Obiectele de Risc. Datele schimbate sunt, ca exemplu, poziţiile
Resurselor şi Cazurilor, Statusul Resurselor, şi raza de Risc pentru un Punct de
Interes.

Poziţia curentă a unei Resurse, de exemplu, va trebui sa fie transmisă de la Sistem

către sistemul GIS, imediat cum această se schimbă. Dacă Resursa comunica în mod
continuu informaţiile de localizare (prin intermediul sistemului radio integrat),
mişcările resursei vor fi vizibile în aplicaţia GIS.

Funcţiile din Sistem pot fi declanşate de acţiunile Operatorului în sistemul GIS şi vice
versa. Două astfel de exemple sunt:

o din Sistem, Operatorul solicita să se găsească poziţia (coordonatele)

unui Caz pe baza adresei. Ca rezultat, Cazul trebuie sa fie poziţionat şi
prezentat pe ecran în aplicaţia GIS.
o În aplicaţia GIS, Operatorul muta o resursă sau un Caz în altă poziţie.
Ca urmare, coordonatele for fi actualizate şi baza de date Sistem.
Sistem va putea folosi trei tipuri de coordonate, WGS84 şi alte două sisteme de
referinţă arbitrare.

Aplicatiile de harta furnizate impreuna cu solutia de dispecerizare trebuie sa

pozitioneze instantaneu pe harta locatia apelantului sau a unui punct de interes
descris in urma apelului, avand ca harta suport harta topografica a tarii furnizata de
catre Cadastru sau imagini satelitare/aeriene daca acestea sunt disponibile. Odata cu
locatia apelantului, aplicatia GIS trebuie sa afiseze detaliile apelantului, nume
prenume, numar de telefon, adresa de resedinta a acestuia, locatia/adresa de unde
suna obtinuta prin capabilitatea aplicatiei GIS de reverse-geocoding sau geocoding.

Solutia trebuie sa permita interogarea retelelor de telefonie mobila, folosind

protocoale standard, cu privire la pozitia apelului sosit in centrul de apel in vederea
localizarii apelului initiat de pe telefon mobil si afisare pozitiei apelantului pe harta.

Transmiterea cererii trebuie sa se poata face atat manual cat si automat si numai
atunci cand abonatul a format numarul pentru apeluri de urgenta 112.

Cel putin urmatoarele protocoale trebuie sa fie suportate:

o MLP (Mobile Location Protocol) – prin care se transmite o cerere

catre reteaua de telefonie mobila
o AML (Advanced Mobile Location) – prin care telefonul mobil trimite un
SMS cu pozitia geografica a acestuia, catre centrul de apel

Solutia trebuie sa permita configurarea tipului de MSID pe care MLP-ul il solicita de

la in functie de parametrii specifici retelei de telefonie mobila (ex. Nature of Address
Indicator and Numbering Plan Information).

In situatia folosirii protocolului AML solutia trebuie sa permita corelarea automata

intre fisa de caz asociata numarului de pe care s-a initiat apleul si sms-ul continand
pozitia apelantului.

In situatia in care exista mai multe fise de caz deschise ca urmare a aceluiasi
apelant, pozitia trebuie conectata cu toate fisele de caz astfel incat acestea sa poata
fi localizate.

Solutia de pozitionare a apelurilor initiate de pe terminale mobile, independenta de

operatorul de telefonie mobile, trebuie sa permita terminalelor de tip smartphone,
care dispun de modul GPS, sa poata transmite automat, in centrul de apel, informatia
de pozitionare.

Solutia va contine o aplicatie deschisa, ce se va plasa atat in Google play cat si in

Appstore in asa fel incat oricine sa o poata descarca si configura.

Aplicatiile trebuie sa functioneze in fundal si sa initieze transferul informatiei de

pozitionare numai atunci cand utilizatorul telefonului mobil a initiat una apel la
numarul de urgenta 112.

Aplicatiile trebuie sa poata implementa protocolul AML in situatia in care apelantul

se afla intr-o zona fara acoperire cu servicii de date.
Harta trebuie sa permita afisearea si a altor informatii precum retelele de utilitati
aflate in zona si alte entitati importante si necesare gestionarii situatiei: hidranti,
materiale explozive s.a.m.d. Interfata de lucru GIS din cadrul Centrului de Preluare
Apeluri de Urgenta (CPAU) trebuie sa aiba capacitatea de a oferi dispecerilor
informatii privind rutele optime si asistenta privind punctele de reper din apropierea
evenimentului catre personalul de interventie din teren.

Toate capabilitatile GIS descrise vor fi parte integranta din solutia de dispecerizare
pusa la dispozitia operatorului din Centrului de Preluare a Apelurilor 112, aceasta
oferindu-i operatorului o singura experienta de lucru, intr-o interfata familiara si
usor de utilizat.

6.4.1 Aplicația GIS specializata pentru managementul situatiilor de urgenta

Funcționalități de bază
Aplicația GIS va avea funcționalități specifice planificării, managementului și
coordonării intervenției după cum urmează:

o Managementul incidentelor - conține funcționalități de poziționare,

vizualizare , căutare și filtrare a evenimentelor - integrarea cu
modului de management și coordonare a intervenției
o Managementul resurselor - conține funcționalități cu privire la
poziționarea și monitorizarea resurselor precum și apartenenta
acestora la intervenții - integrarea cu modului de management al
resurselor
o Rutare - conține funcționalități de calcul de distante/rute în vederea
determinării celei mai potrivite resurse de intervenție
o Căutare - conține funcționalități avansate de căutare
o Grad de pregătire pentru intervenție - conține funcționalități avansate
de monitorizare a forțelor și mijloacelor de intervenție. Furnizează
feedback vizual cu privire la gradul de servire a evenimentului cu
resurse și daca ele sunt plasate în poziții optime pentru a putea
interveni.

Pentru integrarea cu modului de management și coordonare resurse aplicația GIS

trebuie să implementeze cel puțin următoarele niveluri:

o Nivelul gestiune eveniment - folosit de operatorii din SIA 112 pentru

a poziționarea evenimentul și culege informații despre acesta. Nivelul
va conține funcționalități de utile acestei activități cum ar fi: căutare
adresa, manipulare straturi de hartă (ex. strat informațional)
o Nivelul coordonare resurse - folosit pentru operatorii din SIA 112
pentru coordonarea intervenției. Nivelul va conține posibilități de
coordonare a resurselor, inclusiv funcționalități de urmărire în timp
real a deplasării resurselor la intervenție
Accesul în aplicația GIS
Sistemul de control al accesului la aplicația GIS va fi integrat cu cel al modului de
management și coordonare intervenție în scopul obținerii contextului de lucru al
operatorului.
Fereastra principală
Fereastra principală a aplicației GIS va conține, cel puțin următoarele informații:

o Harta de lucru a zonei împreună cu evenimentele, resursele și

straturile de informații asociate gestionate de operatorul conectat la
sistem
o Bara cu instrumente ce conține accesul la funcționalitățile principale
de GIS
o Panouri ascunse conținând funcționalități specific unui sistem de
management și coordonare a intervenției (ex. căutare de adrese,
control al straturilor)
o Bara de stare ce va conține, cel puțin, starea conexiunii către serverul
GIS și coordonatele cursorului

Panourile ascunse
Panourile ascunse trebuie să poată fi accesate prin apropierea mausului de marginile
ferestrei de hartă astfel încât sa nu obtureze imaginea hărții atunci când acestea nu
sunt folosite.

Cel puțin următoarele panouri ascunse trebuie implementate:

Căutare adrese
Va fi utilizat de către operatorul din SIA 112 pentru căutarea unei adrese.

Căutarea trebuie să se poată face furnizând ca elemente de căutare adresa și

(opțional) numărul adresei.

Căutarea trebuie să poată fi făcută folosind substituenți (de exemplu * pentru a căuta
tot ceea ce începe, conține sau se sfârșește cu un text furnizat).

Rezultatul căutării trebuie să se afișeze într-o lista din care operatorul sa poată
selecta o opțiune și atribui unui eveniment.

Straturi de hartă
Straturile de hartă trebuie să poată fi folosite pentru managementul și coordonarea
intervenției. Prin panoul ce poate gestiona straturile de hartă se va putea
ascunde/afișa straturi precum:

o Fundalurile de hartă locale

o Straturile informative

Panourile care gestionează straturile de hartă vor mai implementa funcționalități

precum:

o Filtrarea resurselor per organizație si/sau categoria de resurse

Un operator va putea salva cel puțin 3 straturi de hartă particularizate situațiilor pe
care le gestionează.

Numele straturilor de hartă particularizate vor fi afișate similar cu meniul aplicației.

Panoul locațiilor salvate

Un operator trebuie să își poată salva locații de interes pentru evenimentele pe care
le coordonează. Aceste locații vor fi menținute intr-un panou al locațiilor salvate.

Acest lucru ii va permite o navigare rapida intre locații frecvent folosite de el.

Panoul de filtrare
Panoul de filtrare va permite realizarea funcțiilor complexe de filtrare a conținutului
afișat.

Se vor implementa mecanisme de filtrare folosind cel puțin următoarele criterii

independente sau combinate:

o Centrul de apel
o Organizația
o Resursele
o Documente din straturile informaționale
o Elementele ce pot fi puse în pericol de un eveniment
o Etichetele utilizate de operator

Panoul cu evenimentele coordonate

Panoul cu evenimentele coordonate de operator va prezenta Informații legate de
cazurile selectate a fi afișate în harta.

Un eveniment aflat în coordonare poate fi selectat din:

o Harta
o dropdown list-ul din acest panou.
o Modului de management și coordonare a intervențiilor

Daca un caz selectat în harta nu este deschis în modulul de management și

coordonare a intervenției, va exista posibilitatea deschiderii sale în acest modul
folosind opțiuni furnizate de hartă.

Documente atașate
Acest panou trebuie să permită operatorului sa adauge documente de genul imagini,
documente text, schițe sau conținut video unor obiecte de hartă folosind straturile
informaționale.

Documentul poate fi un fișier sau un link către o pagina de web.

Un document atașat va putea avea configurat o perioada și o raza de validitate. Acești

parametrii controlează situațiile în care documentul va fi prezentat operatorului într-
o lista a documentelor atașate zonei geografice.
Va exista posibilitatea de a specifica sistemului informații de filtrare a documentelor
prezentate operatorului ce coordonează intervenția în funcție de:

o Centrul de apel
o Organizație
o Resurse
o Relevanta:
o Pentru evenimentul în desfășurare
o In interiorul unui cerc cu o raza specificata
o In interiorul unei arii geografice
o Obiectivele în pericol

Elementele în pericol (obiective de risc)

Aplicația GIS trebui sa permită definirea obiectelor de risc în modulul de
clasificare/elaborare planuri ca urmare a faptului ca pot exista planuri speciale
pentru obiectivele de risc.

Obiectivele de risc din modulul pentru clasificarea/elaborarea planurilor trebuie să

fie vizibile în aplicația GIS.

Aplicația GIS trebuie să avertizeze operatorul despre posibilitatea ca un obiectiv din

apropierea unui eveniment poate ridica noi riscuri. De exemplu, daca are loc un
incendiu la o locuința aflata în apropierea unei fabrici de material inflamabile
operatorul trebuie să fie atenționat asupra acestui fapt.

Aplicația GIS va permite atașarea obiectivului de risc la eveniment în vederea

integrării planului de intervenție la eveniment cu planul de intervenție pentru
prevenirea riscurilor asociate obiectivului de risc.

Aplicația GIS trebuie să aibă implementat un mecanism de filtrare a obiectivelor de

risc astfel încât operatorul să poată analiza diferite situații posibile. Principalele
criterii de filtrare necesare a fi implementate sunt:

o Centrul de contact
o Organizația responsabila pentru intervenția la obiectivul de risc
o Resursele ce trebuie implicate
o Documentele ajutătoare
o Obiectivele de risc
o Atașate deja evenimentului curent
o Aflate într-o raza de ... (selectabil)
o Aflate în aria de desfășurare a evenimentului

Centrare și scala
Aplicația GIS trebuie să aibă un panou cu instrumente pentru definirea centrului ce
trebuie menținut în fereastra de hartă și scala hărții.
Ferestre multiple
Aplicația GIS trebuie să permită operatorului sa definească ferestre multiple cu hărți
(hărți utilizator).

Fiecare harta utilizator va putea avea prefiltrat Organizația și stratul de hartă.

Va fi posibil conectarea unui caz unei hărți utilizator în așa fel încât daca în modului
de management și coordonare intervenții se deschide evenimentul acesta să
declanșeze selectarea și actualizarea ferestrei de hartă corespunzătoare.

Marcaje temporare
Aplicația GIS trebuie să permită plasarea de marcaje temporare a căror poziție
geografică să poată fi specificată în diferite sisteme de coordonate.

Straturi ale hărții

Fundal global sau local
Aplicația GIS trebuie să permită existenta a doua tipuri de fundal:

o Fundal globale, folosit pentru hărți care acoperă o zona mare (ex.
întreaga tară). Acesta se va configura cu ajutorul unui fișier de
configurare la nivelul clientului astfel încât sa poată exista diferiți
clienți având diferite fundaluri
o Fundaluri locale, folosite pentru acoperirea unei anumite regiuni (ex.
Municipiul Chisinau). Acesta va putea fi afișat peste fundalul global.

Aplicația GIS va putea lucra cu mai multe fundaluri locale selectabile dintr-o lista.

Fundalurile locale pot fi configurate în același fel ca cel global sau va putea fi
reprezentat de un strat WMS/WMF. în acest caz informația asociata stratului nu va fi
accesata local de către client ci prin intermediul serverului de GIS ce va publica
stratul sub forma unui serviciu web. Clientul va fi configurat să poată accesa stratul
respectiv în secțiunea client din modulul de administrare.

Trebuie să fie posibila existenta a doua tipuri diferite de straturi ce pot fi suprapuse:

o O configurație de hartă plasata local pe client.

o Un strat OGC WMS, în care datele sunt primite de la un serviciu web
disponibil pe serverul de GIS în același fel ca și fundalurile locale.
o Un strat OGC WMS, în care datele sunt primite de la un serviciu web
disponibil pe serverul de GIS dar a cărui modalitate vizualizare va fi
configurata în modulul de administrare.

Straturile ce pot fi suprapuse vor fi prezentate într-o listă separată.

Se vor putea suprapune mai multe astfel de straturi la un moment dat.

Straturi informaționale
Aplicația GIS va permite operatorilor crearea de straturi cu informații ce pot fi
partajate cu alți operatori.
Va fi posibil ca informația de pe un strat de informație sa fie distribuita imediat intre
operatorii cu care acel strat informațional se partajează.

Un strat informațional va putea conține:

o Informație în format text

o Simboluri - aplicația GIS va include un set de simboluri și va permite
adăugarea de noi simboluri din aplicația de administrare
o Linii
o Arii/Poligoane

Aplicația GIS va permite configurarea unor intervale de timp în care un nivel

informațional este vizibil și a drepturilor de acces în funcție de profilurile de acces
definite sau/si a evenimentelor în curs de procesare aparținând unui:

o SIA 112
o Sub organizație
o Organizație

Aplicația GIS și planurile de intervenție

Aplicația GIS trebuie să fie integrata cu modului de clasificare/elaborare planuri
permițând interacția dintre o linie de plan și aceasta.

Va fi posibila gruparea mai multor comenzi către aplicația GIS într-o instrucțiune de
tip GIS din planul de intervenție. Spre exemplu sistemul trebuie să permită realizarea
unor instrucțiuni de genul “focalizează aria geografica și afișează toate elementele de
dispozitiv”.

Va fi posibila cel puțin modificarea următoarelor entități ale aplicației GIS:

Obiectul de hartă Acțiunea

Straturi cu informații Pornit/ Oprit pe strat
Straturi OGC Pornit / Oprit pe strat
Zonele de responsabilitate per Pornit / Oprit pe tip
organizație
Categorii de resurse Pornit / Oprit pe categorie
Categorii de locații special Pornit / Oprit pe categorie
Zona individuale de responsabilitate per Arata / Ascunde de responsabilitate
organizație implicate în evenimentul curent
Sub organizații Arata/Ascunde
Arata pentru evenimentul selectat I arata în
Documente asociate proximitatea cazului / Ascunde
Arata pentru evenimentul selectat/arata
Pericole cunoscute în proximitatea cazului / Ascunde
Urmărirea resurselor
Aplicația GIS va permite deschiderea unei ferestre separate destinată urmăririi unei
resurse.

Resursa afișată sub lupă va fi menținută în permanentă în centrul ferestrei dedicate.

Fereastra asociată urmăririi unei resurse va putea fi minimizată în același fel în care
este minimizată o fereastră utilizator.

Locații speciale
Aplicația GIS va permite definirea unor locații pe hartă care vor avea asociate
informații suplimentare cum ar fi o persoană de contact sau o anumită facilitate.

Astfel de locații vor fi grupate în categorii în vederea structurării acestor cazuri.

Fiecare astfel de locație va avea asociate cel puțin următoarele informații:

o poziție pe hartă
o numele
o descrierea
o organizația/sub organizația de care aparține
o centrul de coordonare de care aparține

Aplicația GIS va putea distribui mesaje către toate locațiile speciale aflata într-o arie
geografica în proximitatea unui eveniment.

Funcționalitatea de transmitere automată de mesaje unui număr de locații speciale va

fi coordonata cu opțiunea "selectabil pentru alertare generală” asociata unui contact
din modului de management și coordonare a intervenției.

Pentru a active alarmarea în masa aplicația GIS va permite selectarea unei arii
geografice, selecție care va genera o lista de contacte către care va transmite
informarea.

Analiza coordonatelor geografice

Aplicația GIS trebuie să implementeze o funcționalitate care sa interpreteze
coordonate necunoscute (valori introduse fără a cunoaște formatul exact al unui
sistem de referință sau valori aproximative),

Aplicația GIS va interpreta coordonatele introduse și va poziționa pe harta valori

relevante în astfel încât operatorul sa poată selecta varianta cea mai apropiata de
realitate.

Sistemul de control al accesului

Aplicația GIS trebuie să suporte modelul de autorizare a accesului în sistem bazat pe
organizație, model folosit de celelalte module ale sistemului.

Pe lângă modelul de autorizare a accesului orientat organizație, aplicația GIS trebuie

să poată controla accesul diferențial la funcționalitățile de administrare și cele de
utilizare.
Cai rapide de acces de la tastatura
Aplicația GIS trebuie să permită fiecărui utilizator sa-si definească cai rapide de
acces la funcțiile aplicației

Alinierea contextului de lucru

Aplicația GIS trebuie să permită sincronizarea contextului de lucru cel puțin în ceea
ce privește organizațiile/sub organizațiile și resursele definite în modulul de
management al resurselor.

Management de resurse
Aplicația GIS trebuie să fie integrata cu modulele: management și coordonarea
intervenției și management de resurse. Integrarea cu modulul management și
coordonarea intervenție se va face, în principal, pentru a obține contextul de lucru
(ex. un operator aparține unei organizații, care gestionează anumite tipuri de
intervenții într-o anumita zona de responsabilitate).

Integrarea cu modulul de management al resurselor se va face în scopul alinierii în

ceea ce privește resursele asociate contextului de lucru, capabilitățile și stările
acestora.

Panoul Resurse
Aplicația de GIS trebuie să poată prezenta informațiile asociate unei resurse.

Afișarea informațiilor aferente unei resurse se va face în contextual de lucru preluat

de la modulul de management și coordonare intervenții sau global în situația în care
rolul operatorului permite acest lucru.

Filtrarea elementelor de hartă

Aplicația GIS trebuie să poată filtra obiectele de hartă în funcție de contextul de

lucru.

In cazul resurselor aplicația GIS trebuie să poată filtra resursele cel puțin după
următoarele criterii:

o Resursele implicate intr-un eveniment și aparțin unei sub organizații

o Toate resursele implicate intr-un eveniment

Filtrarea elementelor de hartă trebuie să se facă în conformitate cu mecanismul de

control al accesului din modulul de management și coordonare a intervenției.

Panoul Suborganizații
Aplicația GIS trebuie să poată să poziționeze pe hartă toate sub organizațiile definite
în modulul de management al resurselor și sa prezinte aceste informații în context de
hartă.
Rutare
Rutare de la un punct la altul
Aplicația GIS trebuie să aibă un mecanism de căutare a unei rute intre doua puncte
fumizând cel puțin următoarele informații:
 o Timpul mediu pana la destinație
o Distanta
o Ruta

Căutarea unei resurse

Aplicația de GIS trebuie să poată iniția căutarea unei resurse plecând de la locația
producerii evenimentului. Căutarea se va face în conformitate cu contextul de lucru
al operatorului care inițiază căutarea și va tine cont de cel puțin următoarele criterii:

o Starea resursei - în conformitate cu stările definite în modulul pentru

managementul resurselor
o Distanta pana la eveniment

Propunerea unei resurse

Aplicația de GIS trebuie să implementeze un mecanism care sa permită operatorului
modului de management și coordonare a intervenției sa inițieze din aplicația de hartă
o căutare de resursa necesara intervenției.

Acest lucru presupune ca aplicația de GIS înțelege contextul în care se afla

operatorul modulului de management și coordonare a intervenției (ex. organizația,
sub organizația, dosarul/sub dosarul de caz) și realizează căutarea resurselor
gestionate de către modulul de management al resurselor în conformitate cu acest
context.
Gradul de pregătire/acoperire
Aceasta funcționalitate trebuie să permită analiza gradului de acoperire cu resurse a
unei zone geografice. Gradul de acoperire trebuie calculat plecând de la existenta
resurselor într-o anumita arie.

Gradul de acoperire trebuie să conțină următoarele funcționalități:

o Calculul gradului de acoperire al unei anumite arii geografice cu

resursele modului de management al resurselor - rezultatul calcului
va prezenta, în timp real, în mod vizual, diferitele nivele de acoperire
o Sugestie pentru asocierea de resurse - rezultatul calculului va tine
cont cel puțin următoarele criterii:
o tipul de eveniment,
o timpul de ajungere la incident,
o modul în care deplasarea resursei va afecta gradul de pregătire
pentru intervenție în zona
o Necesarul de relocare de resurse - funcționalitatea va identifica ariile
în care gradul de pregătire pentru intervenție a scăzut sub un anumit
nivel. în vederea ridicării gradului de pregătire aplicația va trebui să
poată propune resurse pentru relocare.

Sistemul va trebui să poată calcula atât gradul de pregătire a unei regiuni pentru
intervenție cat și gradul de acoperire a zonei cu resurse. Spre exemplu, în situația în
care într-o regiune sa va amplasa o noua resursa de același tip și în aceeași locație,
aceasta nu va trebui să influențeze gradul de acoperire însă va trebui să influențeze
gradul de pregătire.

Sistemul va trebui să permită afișarea simultană, în ferestre diferite, gradul de

acoperire și gradul de pregătire a zonei.

Planificarea Acoperirii
Funcționalitatea trebuie să permită planificarea pe termen lung a zonei geografice.
Sistemul va putea plasa pe harta punctele existente sau viitoare în care se afla/se
vor afla resurse de diferite competente (ex. ambulante, mașini de intervenție la
incendiu, etc). Pe baza pozițiilor respective sistemul va trebui să poată calcula
izocronele timpilor de deplasare și sa afișeze în culori diferite cel puțin trei zone de
acoperire.

Înregistrarea resurselor și vizualizarea ulterioara activității acestora

Funcționalitatea trebuie să permită înregistrarea continua a deplasării unei resurse și
modificarea stării acesteia.

Funcționalitatea va putea afișa, într-o interfață specializata pentru vizualizarea

ulterioara a activității resurselor.

Pentru vizualizarea ulterioara se va putea selecta resursa a cărei activitate va fi

analizata și intervalul de timp.

Posibilități de administrare
Modului de administrare al aplicației GIS va permite controlul accesului la diferitele
funcționalități ale aplicației.

Sistemul de permisiuni
Aplicația trebuie să permită definirea de profile de permisiuni ce vor putea fi aplicate
diferitelor grupe de utilizatori (ex. responsabil cu planificarea - care va avea acces
la funcționalitățile de determinare a gradului de acoperire/pregătire)

Trebuie să existe sincronizare intre utilizatorii modulelor de gestionare, coordonare

a intervenției, management al resurselor și clasificare/elaborare planuri.

In situația în care operatorul modului de gestiune și coordonare a intervenției

aparține unui anumit rol având responsabilități de coordonare a unei anumite arii, a
unei anumite problematici și având la dispoziție anumite resurse, aceste drepturi
trebuie să se răsfrângă și la nivelul aplicației GIS. De exemplu, daca un operator are
în responsabilitate coordonarea intervențiilor medicale, acesta va avea acces numai
la tipurile de evenimente asociate domeniului - modulul de clasificare/elaborare
planuri, la resursele de intervenție specializate (ex. ambulante) și la aria de
responsabilitate corespunzătoare. Toate aceste informații trebuie să poată fi puse în
context geografic, aplicația de GIS fiind aliniata în ceea ce privește rolurile și zonele
de responsabilitate definite în sistem.

Documentele straturilor informative

Aplicația GIS va putea configura parametrii documentelor ce vor fi folosite în
straturile informative.
Configurări specifice intervențiilor
Aplicația GIS va putea defini zonele de responsabilitate ale organizațiilor/sub
organizațiilor.

Sistemul va putea afișa selectiv, în funcție de schema de control al accesului

implementata zonele de responsabilitate. Astfel, un operator de ambulanta va putea
vedea zonele de responsabilitate ale stațiilor de salvare din regiune, în vreme ce un
coordonator al unei situații complexe va putea vizualiza zonele de responsabilitate
ale tuturor tipurilor de resurse aflate în aria de producere a evenimentului,

Modulul de administrare va putea configura parametrii relevanți pentru calculul

gradului de pregătire/acoperire al regiunii.

Modulul de administrare va permite configurarea de sinonime pentru adrese.

Sinonimele pentru adrese reprezintă informații pe baza cărora se va putea face
căutarea și desemnează nume populare pentru locuri publice, nume mai vechi pentru
străzi, alte informații cunoscute de publicul larg ce ar putea fi utile în procesul de
poziționare a evenimentelor.

Sinonimele pot fi de asemenea folosite pentru situații de adrese care nu au fost încă
introduse în baza de date de adrese.

Sistemul trebuie să permită atribuirea unui sinonim de adresa cel puțin pentru
următoarele elemente:

o Un punct
o O linie
o O arie (poligon)

Modulul de administrare va putea defini care resurse trebuie luate în calcul pentru
determinarea pregătirii/acoperiri cu resurse. Astfel, se vor defini resursele în funcție
de:

o Categorie
o Stare
o Criterii de excluziune

Modulul de administrare trebuie să permită configurarea intervalului de timp în care

o resursa este considerata actualizata cu privire la informațiile de stare și
poziționare.

O resursa considerata neactualizata va trebui să fie marcata distinct pe harta pentru

a semnaliza operatorul modului de gestiune și coordonare intervenții acest fapt.

Modulul de administrare va putea configura nivelurile asociate zonelor de trasarea a

izocronelor de timp de deplasare.

Modulul de administrare va putea configura straturile OGS WMS/WFS în conformitate

cu sistemul de control al accesului.
Modulul de administrare va putea importa straturi ce se vor suprapune peste harta
din format XLS sau CSV.

Modulul de administrare va putea defini simbolurile cu care se vor afișa pe harta

forțele și mijloacele de intervenție.

Modulul de administrare va putea pofilele de rutare în conformitate cu tipul de

resurse configurat în modulul de management al resurselor.

Pe baza acestor profile de rutare se vor putea calcul a timpul necesar unei resurse
pentru a ajunge din poziția curenta la locul evenimentului.

Pentru profilurile de rutare se vor putea defini cel puțin:

o Tipul de vehicul (normal sau de teren)

o Dimensiunile de gabarit
o Viteza medie de deplasare

Modulul de administrare va putea defini instrucțiunile GIS ce se vor folosi în modulul

de clasificare/elaborare planuri pentru automatizarea obținerii informației relative la
evenimentul în coordonare.

Funcționalități Interfața Web

Aplicația GIS trebuie să poată expune o interfață web care sa aibă cel puțin
următoarele panouri de ustensile:

o Căutare de adrese
o Gestiune de resurse
o Gestiune de straturi
o Locații salvate

Mecanism de control al accesului

Interfața web trebuie să aibă implementata propriul modul de control al accesului prin
care sa se poată controla accesul la nivel de:

o Conținut
o Resurse și evenimente la nivel de SIA 112
o Resurse și evenimente la nivel de organizația
o Resurse filtrate la nivel de ID
o Funcționalități
o Managementul resurselor
o Managementul straturilor
o Căutare adrese
o Izocrone

Timp de deplasare (Izocrone)

Interfața web trebuie să poată prezenta izocronele timpului de deplasare descrisa în
secțiunea funcționalități de baza.

Înaltă disponibilitate
Înaltă disponibilitate la nivel local

Modulul GIS va avea implementat un mecanism propriu de protecție la deranjament,

prin care serverul de aplicație care implementează modulele de management și
coordonare intervenție și gestiune resurse vor putea comuta de pe serverul primar
ce găzduiește modului GIS pe serverul secundar în situația în care acesta devine
indisponibil.

Înaltă disponibilitate geografica

Modulul GIS va putea implementa, prin mecanisme proprii redundanta geografica.

Integrarea cu alte aplicații

Modulul GIS trebuie să furnizeze un API ce va putea asigura necesarul de
interconectare cu terțe sisteme existente sau viitoare.

Motorul de hărți al modului GIS

Toate hărțile necesare operării modului GIS vor fi gestionate de un motor de hărți.

Motorul de hărți trebuie să poată importa fără conversii intermediare cel puțin
următoarele formate:

o Date legate de elevație: formate DTED și GeoTiff

o Hărți nautice: IHO S57 și Jeppesen C-MAP CM93
o Hărți raster: GeoTiff, JPEG2000, ECW, MrSID, Erdas IMG, CMRG
(PcMap), CADRG, ASRP și USRP
o Vector: ESRI Shapefiles, fișiere Maplnfo TAB și Vector Product
Format (VPF)

Motorul de hărți trebuie să poată manipula un număr mare de hărți, asociat operării
unui sistem complex, fără degradarea performantei.

Motorul de hărți trebuie să poată combina straturi vectoriale și raster.

Motorul de hărți trebuie să poată folosi straturi structurate ierarhic și straturi

dependente de scara.

Motorul de hărți trebuie să poată implementa animație de înaltă calitate (care sa

confere imaginii naturalețe, fără ca mișcarea sa dea senzația de întrerupere).

Motorul de hărți trebuie să permită prezentarea simbolurilor în conformitate cu

atributele acestora.

Motorul de hărți trebuie să implementeze mecanisme de grupare, filtrare și sortare a

simbolurilor prezentate pe harta

Motorul de hartă trebuie să poată folosi hărți accelerate hardware atât în format 2D
cat și 3D.
Motorul de hartă trebuie să ofere cel puțin următoarele mecanisme integrate de
analiza geospațială:

o Analiza vizibilității:
o profile verticale
o line of sight
o Mecanisme avansate de calcul al rutei
o Izocrone
o Analiza terenului
o Analiza SIA 112

Motorul de hartă trebuie să nu limiteze numărul de straturi ce pot fi afișate.

Motorul de hartă trebuie să poată combina fără restricții straturi raster și vector.

Datorita diversității în ceea ce privește formatele de hartă motorul de hartă trebuie să

suporte peste 60 de formate.

Motorul de hartă trebuie să permită încărcarea asincrona a hărților de fundal pentru a

nu afecta performantele aplicației de GIS în special în perioadele cu evenimente
majore.

Serverul de GIS
Serverul de GIS trebuie să fie compatibil OGC WMS/WFS și sa furnizeze toate
funcționalitățile necesare pentru managementul, publicarea și distribuirea hărților și a
altor date geospațiale către stațiile de lucru peste rețele locale (LAN) și larg
răspândite (WAN).
Tablou de comanda operativ pentru monitorizarea in timp real a evenimentelor deschise
Este necesara centralizarea tuturor cazurilor deschise de catre operatorul 112 de
catre Seful de Tura care va monitoriza prin intermediul unui tablou de comanda
activitatea Centrului de Preluare a Apelurilor 112. Astfel, seful de tura va avea o
privire de ansamblu centralizata asupra tuturor evenimentelor deschise de catre
operatorii 112.

Generic, dar fara a se limita la aceste informatii, tabloul de comanda si control al

centrului operativ 112 este recomandat sa contina:

- Panouri cu informatii descriptive si harta integrate

- Tabloul de comanda sa poate fi creat pentru a acoperi unul sau mai
multe monitoare, aceasta capabilitate nefiind similara cu “full extend”
su “duplicate” pentru ecran. Astfel in cadrul CPAU 112, pe videowall
vor fi alese inca de la inceput, ce panouri ale tabloului de comanda sa
vor regasi pe fiecare ecran al videowall-ului
Panourile informative se recomanda a fi urmatoarele:
o Panou cu lista tuturor evenimentelor deschise de operatorii CPAU,
afisate in ordinea orara, impreuna cu pozitionarea acestor evenimente pe
harta;
o Panou ce va afisa data si ora la care o resursa a ajuns la eveniment,
timpul de stationare la eveniment si data si ora plecarii de la eveniment.
 oPanou de cautare a unui eveniment in functie de ID-ul acestuia, cu
posibilitatea de afisare atribute: adresa, tip eveniment, data si ora
inregistrarii apelului, si de evidentiere pe harta a evenimentului
Harta din tabloul de comanda va afisa:
o Harta topografica furnizata de IS Cadastru sau cu imagini
aeriene/satelitare, cu posibilitatea comutarii intre acestea;
o Afisarea pe harta a tuturor cazurilor deschise cu toate informatiile
aferente
o Locatiile resurselor de interventie, primite prin intermediul subsistemului
AVL, cu asociate cu tipul acestora, dotarile si identificatorul resursei;
o Integrare a senzorilor si camerelor video cu posibilitatea accesarii
streaming-ului video sau informatiilor printr-un simplu clic pe harta
6.5 Managementul identitatii, autentificare, autorizare

Sistemul trebuie sa ofere capabilitatea de definire de roluri pentru utilizatori, pe baza

unor criterii de
 autoritate: Operator preluare apeluri 112, Dispecer SSU, Sef serviciu
112, Sef CPAU, Sef de tura/supervisor;
 competente: nivel de senioritate, limbi straine vorbite, cunostinte de
specialitate
Sistemul trebuie sa ofere capabilitatea de definire de roluri pentru utilizatori pentru a
realiza controlul drepturilor de acces la funcţiile sistemului, si al permisiunilor de
acces la informatiile asociate, la nivel de:

 organizaţie: 112, SSU, altele;

 grup de utilizatori: Administratori sistem, Manageri functional,
Manageri organizationali, Operatori, Dispeceri;
 utilizatori individuali: fiecare utilizator din sistem va fi identificat
nominal.
Sistemul trebuie sa se integreze cu o solutie de management al identitatii bazata pe
tehnologie LDAP.
 7. Cerinte non-functionale
Scopul acestui capitol este de a defini specificatiile minime privind caracteristicile si
capabilitatile non-funtionale ale sistemului. Acestea acopera cerintele minime de
infrastructura software si hardware si ele sunt obligatorii in vederea atingerii
parametrilor de performanta ai sistemului.

In vederea asigurarii dotarii corespunzatoare a sistemului integrat, se vor lua in

considerare cerintele evidentiate in cele ce urmeaza acestea fiind coroborate cu
cerintele evidentiate in cadrul capitolului 5.2 Arhitecura.

7.1 Infrastructura Software

Infrastructura software solicitata are ca scop crearea unui mediu de lucru facil, pe
cat posibil omogen si care sa confere licentiere completa si corecta raportat la
reglementarile producatorului solutiilor. Astfel, ofertantii au obligatia de a oferi
solutii software ce acopera minim intreaga capacitate de procesare pe care acestea
ruleaza cu respectarea politicilor de licentiere ale producatorului. In acest sens,
ofertantii vor oferi un tabel centralizator cu toate licentele propuse care sa indice
numele producatorului, editia produsului software ofertat, numarul de licente, metrica
si explicitarea politicii de licentiere insotita de documente doveditoare. Ofertantul
declarat castigator are obligatia de a livra ultima versiune stabila disponibila
comercial la data implementarii.

7.1.1 Sistemul de virtualizare

In vederea asigurarii unui strat suplimentar de management si redundanta, sistemul
integrat trebui sa ruleze in mediu virtualizat. Acest mediu de virtualizare va fi unul
robust, consacrat si scalabil, in vederea asigurarii extinderilor viitoare.

In acest sens, sistemul de virtualizare va oferi urmatoarele specificatii si capabilitati:

 componenta de virtualizare va fi instalată direct pe platforma hardware și va

beneficia de suportul acestei platforme atât la nivelul capacității de
procesare, cât și la nivelul opțiunilor de conectică și integrare cu restul
elementelor de infrastructură.
 va suporta cel putin urmatoarele sisteme de operare: Suse Linux, Red Hat
Linix, Windows Server, Ubuntu, CentOS, Oracle Linux
 Hypervisor-ul pe care aceasta platformă se bazează trebuie să fie
independent de producătorul sau de metoda de stocare internă/externă
disponibilă în platforma de procesare și/sau stocare pe care rulează.
 va permite definirea a minimum 1024 de masini virtuale per host
 Sa permita definirea a minimum 8000 de masini virtuale la nivelul clusterului
de virtualizare in scopul atingerii unui nivel crescut de scalabilitate
 va putea fi instalat pe o infrastructura mai mare de 480 de procesoare si 12
TB RAM
 va suporta masini virtuale de 128 procesoare virtuale si 4 TB vRAM
 va fi capabil sa aloce suplimentar memorie unei masini virtuale fara oprirea
din funtionare a acesteia
  va fi capabil sa aloce suplimentar capabilitati de retea suplimentare
 capabil sa creeze imagini ale oricarei masini virtuale in vederea asigurarii
unui backup
 va asigura capabilitatea se a aloca direct si exclusiv unie singure masini
acces la o resursa fizica a serverului fizic
 va include capabilitati de recuperare dupa dezastru prin asigurarea de copii
relocate fizic in alt site.
 va asigura capabilitati de migrare a masinilor virtuale de pe un server fizic
pe altul fara oprirea functionarii aplicatiilor din interiorul masinii virtuale
 sa permita criptarea la nivel de masina virtuala

7.1.2 Sistemul de operare

Platforma sistemului trebuie să aibă la bază hardware comercial de tip x86-64, atât
pentru servere cat și pentru stațiile de lucru

Platforma sistemului trebuie să aibă la bază un sistem de operare comercial de largă

răspândire.

Sistemele de operare de tip server trebuie să îndeplinească minim următoarele

cerințe:

 Să fie compatibile cu toate componentele software incluse în cadrul soluției;

 Să permită rularea pe procesoare cu 64 biți;
 Să aibă capabilitatea de a rula în mediu virtualizat;
 Să permită folosirea unor cantități mari de memorie de cel puțin 64 GB;
 Să permită dezactivarea serviciilor care nu sunt utilizate pentru a degreva
resursele de procesare de rularea acestora și pentru a limita numărul de
servicii care pot reprezenta puncte de acces în sistem pentru atacatori;
 Să ofere suport pentru integrare cu serviciu de director;
 Serviciul de director pentru administrarea identităților trebuie să suporte
LDAP;
 Să ofere suport pentru tehnologie Load Balancing;
 Să ofere suport pentru IPv6;
 Să poată fi configurat în topologii de tip cluster;
 Să ofere suport pentru implementare serviciu de director în virtualizare;
 Să permită folosirea structurii de director, constând din servicii de director
pentru administrarea identităților si servicii de meta-director în scopul
îmbunătățirii administrării;
 Serviciile de director pentru administrarea identităților trebuie să poată
suporta replicarea conținutului;
 Structura de director trebuie să poată fi administrată direct de un utilizator
sau de aplicație;
 Serviciul de director trebuie să permită definirea politicilor de securitate;
 Să permită stocarea certificate și CRL-uri;
 Să asigure integrare cu serviciul de DNS;
 Să permită efectuarea de legături multiple prin Lightweight Directory Access
Protocol pe o conexiune, în scopul autentificării utilizatorilor;
  Să ofere o interfața unică pentru configurarea și monitorizarea serverului, cu
programe de tip expert pentru optimizarea sarcinilor comune de administrare
a serverului;
 Să ofere capabilități de tip linie de comandă și limbaj de script care să ajute
administratorii să automatizeze sarcinile de rutină de administrare a sistemului
pe mai multe servere;
 Să ofere instrumente de diagnosticare care să ofere vizibilitate permanentă
asupra mediului serverului, fizic și virtual, pentru a identifica și rezolva rapid
problemele care apar;
 Să permită instalări minimale, în care sunt instalate numai rolurile și
caracteristicile de care e nevoie, minimizând nevoile de întreținere și reducând
zonele de atac de pe server;
 Să integreze tehnologii de backup care să simplifice restaurarea datelor sau a
sistemului de operare;
 Să conțină un design modular și opțiuni de instalare ce permit numai instalarea
caracteristicilor strict necesare, reducând zonele de atac și simplificând
administrarea actualizărilor;
 Să ofere suport pentru protocol HTML 5 și WebSocket;
 Să ofere un depozit central pentru stocarea certificatelor digitale folosite
pentru protecția site-urilor web;
 Să ofere administrare la distanță pentru mai multe servere web dintr-o
singură consolă;
 Să permită măsurarea consumului de resurse al serverelor web partajate;
 Să permită limitarea consumul de resurse de procesor, memorie sau lățime de
bandă consumate de serverul web;
 Să ofere un mecanism ce asigură că rețeaua și sistemele nu sunt compromise
de calculatoare virusate, izolând și/sau depanând calculatoarele care nu se
conformează politicilor de securitate stabilite de administrator;
 Să ofere un mecanism de protecție împotriva aplicațiilor periculoase;
 Să ofere flexibilitate criptografică suportând algoritmi de criptare standard și
definiți de utilizator, permițând crearea, stocarea și preluarea mai facilă a
cheilor criptografice;
 Să conțină un modul pentru monitorizarea stării autorităților de certificare
(CA).

Daca pentru sistemele de operare sunt necesare licențe pentru a asigura acces,
trebuie sa fie incluse pentru acces simultan de către 100 de utilizatori interni și
număr nelimitat de utilizatori externi.

7.1.3 Sistemul de baze de date

Baza de date trebuie sa fie din clasa platformelor tip enterprise, folosita pe larg in
domeniu si trebuie sa aiba urmatoarele caracteristici:

 Trebuie să fie un sistem de baze de date relaţionale

 Sa permita importul si exportul de date in formate de date general
acceptate.
 Sa permita mecanisme de securitatea la nivel de linie
  Sa ofere posibilitatea de stocare si gestiune a structurilor de date tip xml,
utilizand mecanisme native ale bazei de date.
 Trebuie să poată rula pe arhitecturi de procesoare pe 64 de biţi si cu suport
pentru cel putin 2 sisteme de operare de la producatori diferiti
 Compatibilitate cu standardul ANSI SQL
 Trebuie să permită executarea de operaţiuni SELECT, INSERT, UPDATE,
DELETE
 Trebuie să aiba suport pentru proprietăţile ACID
 Suport pentru Unicode UTF-8 sau echivalent
 Suport pentru proceduri stocate şi triggere
 Sa permita optimizarea conexiunilor la baza de date prin folosirea unui
mecanism de tip database connection pooling
 Trebuie să permită definirea de indexi cluster şi non-cluster
 Suport pentru căutare în câmpuri de text folosind șabloane de căutare
 Să permită restricţionarea accesului la obiectele bazei de date (tabele, view-
uri, etc)
 Să includă mecanisme pentru restricţionarea accesului utilizatorilor la date şi
obiectele bazei de date
 Sa permita modificarea parametrilor in cazul suplimentarii sistemului cu
memorie, procesoare si spatiu de stocare, baza trebuind sa se ajusteze la
aceste modificari
 Suport pentru replicarea bazei de date
 Sa permita salvarea/restaurarea si arhivarea/dezarhivarea datelor in regim
de lucru online
 Sa pemita salvarea totala si/sau partiala a bazei de date
 Posibilitatea de backup şi restaurare a datelor în mod automat
 Sa permita efectuarea de backup automat intr-o forma unitara, centralizata
si usor de administrat

7.1.4 Sistemul de integrare si preluare date

Soluția informatică va avea posibilitatea de a interacţiona/ interfaţa in mod redundant
si sigur cu alte sisteme informatice implementate (sau în curs de implementare).

Furnizorul selectat va trebui să proiecteze în cadrul aplicației interfeţe specializate

și standardizate pentru interoperabilitatea cu alte sisteme informatice specializate în
gestiunea evenimente/incidente de ordine publică (informaţii alfa-numerice și
geocodate), precum și o interfaţă de transmitere a datelor către aceste sisteme (sau
de citire a datelor din sisteme externe), împreună cu mecanismele aferente de
sincronizare și corecţie a erorilor. Interfeţele proiectate și implementate vor fi
generale, astfel încât să poată fi configurate în viitor (pentru a primi/transmite și alte
seturi de date) și pentru a permite comunicarea cu sisteme care nu există la
momentul implementării aplicației. Împreună cu aceste interfețe va fi livrată și
documentația tehnică de utilizare și de adaptare a lor.
 7.1.5 Sistemul de securitate
Sistemul informatic trebuie protejat impotriva incercarilor deliberate sau accidentale
de acces neautorizat la datele pe care acesta le vehiculeaza si stocheaza. Din acest
motiv, sistemul trebuie sa includa mecanisme de securizare software ce asigura
reglementarea accesului atat la nivel hardware cat si la software. Totodata sistemul
trebuie sa prevada mecanisme de detectie si rezolvare automata a vulnerabilitatilor
ce realizeaza semnalarea vulnerabilitatilor sistemului, propune metode de remediere
si ofera unelte in vederea aplicarii manuale sau automate a actiunilor de asigurarea
eliminarii problemelor de securitate. Astfel, sistemul va include capabilitati de
securizare a accesului la reteua informatica a sistemului ce va include urmatoarele
funtionalitati:

 sa suporte capabilitati avansate si detaliate de inventariere incluzand aici

toate proprietatile hardware, software sau de configuratie
 sa ofere capabilitati de descoperire si inventariere folosind aceiasi consola
 sa suporte capabilitati de cautare, browsing si editare a unui catalog de
identificare software ce contine mai mult de 100.000 semnaturi out-of-the-
box, si al carui continut este mentinut la zi prin intermediul schimbarilor din
industria software
 sa permita customizari simple, bazate pe “wizarduri”, a catalogului de
produse software astfel incat sa poata analiza/monitoriza atat aplicatii
dezvoltate intern cat si aplicatii proprietare
 sa ofera informatii de tip drill down despre aplicatiile software descoperite
la nivel de endpointuri
 sa permita capabilitati de monitorizare care sa coreleze statistici istorice cu
informatii legate de performanta si utilizare.
 sa identifice tendinte si tipare la nivel de endpointuri Microsoft, Unix sau
Linux
 sa coreleze informatii privind utilizarea licentelor software cu un set de
informatii privind managementul de reconciliere imediat al licentelor ce
identifica instante necompliante, actiune urmata de cele mai multe ori de
marcare corespunzatoare precum si stergere.
 să ofere un set de date pentru raportarea și integrarea cu alte sisteme
enterprise care au nevoie de inventariere exacta (service desk, asset
management system, inventory warehouse, configuration management
databases)
 să suporte integrare out-of-the-box cu solutii de service desk pentru a
oferi funcții avansate, cum ar fi punerea în aplicare a unei aplicații de tip
“magazine de aplicatii”
 să permită integrare cu alte instrumente de service desk și de gestionare a
activelor prin intermediul unor APIuri de tip REST (representational state
transfer)
 să ofere o integrare strânsă cu solutiile de securitate endpoint și
management al conformității
 să includă atat arhitectură distribuită pe bază de agent cat și fără agenți de
scanare pentru impact redus, dispozitiv de detectare cu latență redusă,
precum și o verificare amănunțită sau raportare
 să identifice rapid toate dispozitivele IP adresabile inclusiv dispozitivele
periferice și de rețea, cum ar fi imprimante, scannere, routere si switch-uri
 să descopere obiective nedocumentate în cadrul mediului și identifică
dispozitive suspecte "rogue"
 să ofere raportarea în timp real a porturilor și servicii deschise în uz
 să suporte interogări ad-hoc pentru endpointuri - de exemplu: "Arata
numerele de serie ale tuturor monitoarelor de calculator" -și oferă rezultate
în câteva minute, cu impact minim la scară
 să ofere vizibilitate la nivelul endpointurilor, indiferent de locația acestora,
atat on cat si off in rețea, și păstrează curent datele de inventar, chiar și
pentru cele neconectate în mod constant la rețea
 să asigure managementul automat al patch-urilor de la o singură consolă de
management
 să gestioneze automat patch-uri pentru sisteme de operare multiple, inclusiv
Microsoft Windows, UNIX, Linux și Mac OS, de la aceeași consolă
 să gestioneze automat patch-uri pentru aplicații inclusiv Microsoft, Apple,
Adobe, Mozilla, Google, și Java
 să reducă ciclurile de remediere la săptămâni, minute sau ore, minimizând
riscurile de securitate și conformitate
 să permită managementul patch-urilor pentru endpointuri atat in retea cat si
în afara ei, inclusiv in roaming, sau dispozitive conectate la Internet
 să ofere funcționalitate optima chiar și in conditii slabe de lățime de bandă
sau de rețele distribuite la nivel global
 să crească rata de success a aplicatii patchurilor la peste 98 la sută (de la un
tipic 60-75 la suta) și confirmă remedierea
 să ofere politici de pretestare de patchuri pentru administratori
 să permită gruparea patch-urilor într-o singură sarcină de implementare cu
scopul de a simplifica managementul, rezolvand automat orice dependențe
 să descarce și să aplice numai patch-urile relevante pentru fiecare endpoint
 să permită administratorilor de sistem să creeze și să implementeze rapid
patch-uri personalizate pentru a remedia vulnerabilitățile zero-day
 să permită patching de mașini virtuale on-line pentru a îmbunătăți
securitatea în medii virtuale
 să permită patchingul masinilor virtuale offline, astfel încât mașini virtuale
latente nu sunt exploatate atunci când acestea sunt aduse înapoi în funcțiune
 să coordoneze patchingul sistemelor de operare ale serverelor ce sustin
aplicatii complexe, în ambele medii fizice și virtuale
 să suporte secventierea sarcinilor
 să imbunatateasca vizibilitatea in ceea ce priveste complianta patchurilor,
printr-o monitorizare flexibila
 să permită afișarea statusului patchurilor: tendinte, in curs de derulare,
instalat cu success, eroare etc
 să furnizeze informații cu privire la ce patch-uri au fost istalate, când și cine
a realizat instalarea
 să evalueze în mod automat complianta endpointurilor împotriva politicilor
definite, cum ar fi nivelurile de patch-uri obligatorii
 să detecteze și remediază problemele în care un patch instalat anterior a fost
dezinstalat ulterior sau suprascris, și permite depunerea unei noi cereri
automate a patch-urilor dezinstalate
 să permită prezentarea patch-urilor disponibile catre utilizatori sub forma
unor "oferte", cu sau fără date de punere în aplicare obligatorii, pentru a
minimiza întreruperile
 să permită gruparea patchurilor și instalarea lor rapida în timpul ferestrelor
de schimbare definite
 să asigure managementul distribuției de software pe mai multe platforme
dintr-un singur punct unic de control
 să distribuie actualizări de software peste retele cu latime de banda slaba
sau distribuite la nivel global
 să suporte instalari de pachete software (noi sau update) peste medii
distribuite atat prin politici cat si la nivel de grupuri de calculatoare.
 să suporte verificare în buclă închisă a software-ului de instalare / de-
instalare
 să permită provizionarea si deprovizionarea a nivel de utilizator a aplicatiilor
si pachetelor software autorizate
 să suporte pre-caching local al pachetelor software pentru a îmbunătăți
fiabilitatea la instalare
 să elimine necesitatea de a duplica fișiere pentru distributia de software
 să suporte politici de distribuție software “follow the user”
 să ofere capabilități de personalizare pentru o direcționare precisă a
pachetelor software
 să minimizeze impactul la nivel de rețea prin optimizarea lățimii de bandă în
conformitate cu politicile, atât statice, cât și dinamice, pe toate platformele
de sisteme de operare
 să mentina fișiere de configurare, cum ar fi Microsoft Software Transform
(MST) și Microsoft Software Patch (MSP) separat de componentele software
de bază pentru a gestiona eficient mai multe configurații de pachete
 fie compatibila cu instrumentele de distribuție de software si formatele
pachetelor
 să ofere suport pentru instalarea “bare metal” a sistemelor de operare
pentru noile statii de lucru, laptop-uri și servere în întreaga rețea, precum și
migrarea sistemului de operare sau updatarea endpointurilor existente
 să utilizeze infrastructura central de management a endpointurilor pentru
migrarea sistemului de operare, eliminand costurile asociate cu menținerea
unei infrastructuri de implementare a sistemului de operare de sine
stătătoare
 să suporte inclusiv programare de tip “wake-up” de la distanta precum si a
implementarii
 să implementeze imagini independente hardware, prin injectarea de drivere
de dispozitiv corespunzătoare după cum este necesar
 să permită migrarea pe loc a profiluri de utilizator și a datelor
 să ofere control de la distanță independent de platforma precum si
capabilitati de depanare
 să ofere informatii in timp real despre endpointuri administratorilor, cu
capabilități de diagnosticare de la distanță care pot simplifica și eficientiza
apeluri help-desk și rezolvarea problemelor
 să trimită actiuni specifice la nivelul endpointurilor in functie de configuratie
si tipul lor
 să ofere capabilitati de descoperire de la distanță și o analiza a aplicatiilor
instalate
 să permită administratorilor să stabilească accesul bazat pe roluri pentru a
sprijini responsabilitățile diferite ale utilizatorilor precum si cerintele de
business.
 să simplifice și operationalizeaza securitatea prin încorporarea de practici de
securitate și inițiative de conformare, ca parte a procesului de operațiuni de
IT
 să gestioneze configurația endpointurilor fizice si virtuale, indiferent de
locatie, sistem de operare, aplicațiile instalate sau conexiune (inclusiv
computere conectate prin cablu sau dispozitive mobile conectate
intermitent)
 să remedieze endpointuri conform cu o baza de conformitate și apoi impune
în mod continuu politicile de configurare in sau în afara rețelei
 să automatizeze remedierea endpointului fără interacțiunea factorului uman-
un factor critic în răspunsul rapid ce trebuie dat la încălcările cibernetice
înainte de a se produce daune pe scară largă
 să ofere vizibilitate precum și aplicarea continuă a configurațiilor de
securitate și patch-uri de la o singură consolă de management
 să permită raspuns in timp real la atacuri zero-day printr-o remediere in
buclă închisă, ce permite administratorilor să creeze rapid și ușor politicile
de remediere si sa le implementeze în cadrul organizației în câteva ore, atat
in interior cat si in afara retelei
 să furnizeze în timp real informatii legate de situatia actuala și reacția la
incidente la nivelul tuturor endpointurilor - indiferent de localizare și lățimea
de bandă
 să ofere integrare cu un SIEM pentru a accelera remedierea
vulnerabilităților descoperite si prioritizate
 Prin integrarea cu SIEM, Solutia să împingă lista de priorități cu
vulnerabilități direct la consola de administrare, pentru remedierea automata
a endpointurilo (carantină / patch / reconfigurare)
 să detecteze nivelul de expunere al endpointului prin indicatori de
compromis (CIO)
 conține o bibliotecă completă de controale tehnice bazate pe cele mai bune
practici bine-cunoscute, care ajuta la atingerea nivelului de securitate dorit
prin detectarea și punerea în aplicare a configurațiilor de securitate
 să suporte protocolul SCAP (Security Content Automation Protocol)
 Solutia folosește, politici predefinite, bazate pe standardul OVAL (Open
Vulnerability and Assessment Language) cu scopul de a evalua endpointurile
împotriva vulnerabilităților cunoscute
 Solutia fie capabila sa acționeze la nivelul vulnerabilitatilor si a factorilor de
risc publicati de catre institutul SANS
 mapeaza vulnerabilitățile cu standardele din industrie pentru a furniza
descrieri CVE și sisteme de punctaj CVSS precum și link-uri către Baza
națională de date pentru vulnerabilitati (NVD)
 să ofere liste de verificare predefinite care conțin mai mult de 5.000 de
setări de configurare standard, mapate la standardele industriei pentru
Windows, UNIX și Linux
 să automatizeze și simplifică raportarea de conformitate conform SOX,
HIPAA sau UK Financial Services Act
 să ofere bune practici predefinite care respectă US Federal Desktop Core
Configuration (FDCC) și United States Government Configuration Baseline
(USGCB)
 să ofere bune practici predefinite care respectă ghidul de implementare
Defense Information Systems Agency Security Technical Implementation
Guides (DISA Stigs)
 să ofere bune practici predefinite bazate pe referințe de securitate CIS
(Center for Internet Security)
 să identifice și elimină vulnerabilitățile cunoscute utilizând aplicarea
politicilor automate sau manuale de implementare
 să permită integrarea ușoară cu tehnologii asociate, cum ar fi sistemele de
help-desk, sisteme de management al activelor, baze de date de
management a configurației (CMDBs) și sisteme SIEM
 seteaza alarme pentru a identifica rapid endpointuri de tip “rogue” sau
configurate greșit și ia măsuri pentru a le localiza pentru remediere sau
eliminare
 Solutia poate plasa automat endpointuri non-compliant în carantină
păstrându-le în același timp sub supraveghere pana in momentul în care
remedierea este completă
 să ofere panouri pentru formularea politicilor personalizate, raportare și
aplicare
 Solutia fie atestata de Institutul Național de Standarde și Tehnologie (NIST)
atât pentru evaluare cat și remediere
 să permită personalizarea rapidă printr-un API usor de utilizat care suportă
mai multe platforme folosind aceeași limbă
 să ofere un punct central pentru toate instrumentele de automatizare
sistemelor de management, ce permite administratorilor să folosească
 instrumentele pe care le cunosc (scripting shell în UNIX, fișierele batch în
Windows, script-ul Apple, și așa mai departe)
 colecteaza si arhiveaza rezultatele controlului automat de securitate pentru
a identifica problemele de configurare și a raporta nivelurile de conformitate
IT legate de securitate
 să ofere capabilități de analiză ce sprijină punerea în aplicare a politicilor
tehnice și de configurare ale organizației prin monitorizare, raportare,
precum și determinarea succesului inițiativelor de securitate
 să ofere rapoarte istorice, pentru a determina progresele realizate spre
obiectivele de conformitate
 să ofere semnificativ rapoarte istorice relevante in timp real privind starea
si securitatea endpointurilor, rapoarte ce pot fi folosite în remedierea
neconformitatilor și confirmarea remedierilor
 să ofere tablouri de bord de ansamblu precum si informatii executive in ceea
ce priveste complianta, cu capacitatea de a detalia pentru informații detaliate
 să ofere rapoarte de actiune consolidate prin tehnici de remediere (cum ar fi
un anumit patch), nu doar o "listă lungă" de suprapunere, vulnerabilități de
multe ori redundante
 să identifice, gestionează și rapoarteaza excepțiile de politică și abateri
 să ofere o gamă completă de rapoarte pentru gestionarea controalelor IT,
inclusiv starea de conformitate și istorie, rapoarte la nivel de endpoint sau
grup precum si exceptii
 să permită crearea de interogari si rapoarte personalizate, flexibile, la
cerere
 să ofere flexibilitate in raportare, inclusiv filtre de raport (de exemplu,
complianta istorica, metadate de calculator, metadate de verificare, și așa
mai departe)
 să permită utilizatorilor să creeze cu ușurință liste de verificare
particularizate, în câteva minute, prin combinarea controalelor incluse cu
cele mai bune practici personalizate
 să ofere tendinte si analize de conformitate la nivelul configuratiilor si a
schimbarilor de securitate prin raportare avansata
 să ofere vizibilitate globala la nivel de infrastructura pornind de la un singur
echipament si pana la grupuri de echipamente
 să includă o baza de date de tip “data warehouse” pentru analiza de
securitate a datelor de conformitate istorice
 să ofere o imagine de ansamblu a stării de conformitate, plus statusul de
vulnerabilitati în același raport sau pentru a vizualiza on-line
 să suporte solicitări de audit prin furnizarea unui status istoric versus
vederea stadiului actual
 să suporte un server de raportare pentru auditori, cu acces de citire și acces
la informație selectată
 se integrează cu alte motoare de automatizare in sistem, cum ar fi Chef
 să restricționeze accesul la endpointuri și rapoarte prin permisiunile de
utilizator și roluri
 să utilizeze aceeași consolă, arhitectura și agent in managementul
endpointurilor
 să ofere o abordare consolidată, unificata realizand gestionarea antivirus,
anti-spyware, firewall si servicii de criptare pentru produse de la furnizori
diferiti, cum ar fi Symantec, McAfee, Trend Micro, Microsoft și Sophos
 să ofere monitorizarea starii de sanatate a sistemului pentru a se asigura că
agentul de protectie a endpointurilor ruleaza si este la zi
 facilitează migrarea endpointurilor de la o solutie de securitate la alta, prin
dezinstalarea software-ului printr-un singur click și reinstalarea lui.
 să utilizeze verificarea cu buclă închisă pentru a se asigura că setările de
securitate au fost aplicate și executate și că actualizările și alte modificări
sunt finalizate
 previne accesul utilizatorilor la site-uri infectate, fie prin propriile acțiuni
sau a unor acțiuni ascunse, automate efectuate de către programe malware
pe computerul lor
 să utilizeze o tehnologie de reputație web-based care in mod dinamic
seteaza scoruri pentru milioane de pagini web individuale în fiecare zi pentru
a proteja împotriva malware-ului web, inclusiv amenintari web 2.0 sau
orientate catre furtul de informatie
 să protejeze endpointurile împotriva virușilor, troienilor, viermilor, spyware,
rootkits, noi variante de malware și site-uri infectate, folosind date in timp
real din cloud pentru a stabili nivelul de securitate al site-urilor web si a
fisierelor
 să identifice și elimina complet spyware-ul descoperit inclusiv rootkituri
 să ofere o soluție complet integrată de antivirus și firewall cu consola
globala de management a endpointurilor și a infrastructurii, eliminând
costurile și complexitatea asociate cu administrarea unei asemenea
infrastructuri antivirus si firewall de sine stătătoare
 să ofere capabilitati integrate de prevenire a pierderilor de date (DLP)
implementate utilizând o singură consolă și un singur agent distribuit la nivel
de infrastructura
 să includă capabilitati DLP cu scopul de a securiza datele pe toate
dispozitivele, a aplica politicile de securitate astfel încât utilizatorii să poată
accesa datele sensibile in mod correct si fara pierderi, și de a ajuta să se
respecte reglementările privind confidențialitatea datelor
 protejează împotriva utilizării abuzive a datelor pe baza cuvintelor cheie,
expresii regulate și reguli configurabile, care pot verifica formatare sau
chiar de codificare (de exemplu cod Java) specifica și răspunde în mod
corespunzător
 să includă șabloane predefinite pentru respectarea reglementărilor specifice,
cum ar fi Gramm-Leach- Bliley Act (GLBA), HIPAA, PCI-DSS, California
SB-1386 sau US PII
 să ofere capabilitati de monitorizare si blocare atunci cand datele sunt
copiate sau trimise printr-o varietate de canale inclusiv e-mail, clipboard,
FTP, HTTP, HTTPS, SMB, IM, webmail și altele, precum și monitorizarea
 canalelor fizice, cum ar fi solutii de inregistrare de date, criptare, aplicații
peer to peer și așa mai departe
 să permită raspunsuri personalizate-de la blocarea acțiunilor și avertizarea
utilizatorilor finali pana la notificarea automată a administratorilor
 să monitorizeze și să controleaze porturile fizice și poate activa sau
dezactiva aceste porturi în funcție de tipul de dispozitiv și restricțiile
aferente
 să includă un nivel de control granular al dispozitivului pentru a restricționa
accesul USB
 să ofere o vizibilitate în timp real și control pentru toate serverele (fizice și
virtuale) cu management bazat pe politici concepute pentru a reduce
costurile.
 să realizeze managementul serverelor fizice și virtuale – inclusiv patchingul
sistemelor de operare petru medii cluster – dintr-o simpla interfata unitara.
 să suporte secventierea sarcinilor folosind tool-uri commune ce pot fi
folosite pentru sarcini critice cum ar fi instalarea unui server bare metal
(sisteme de operare, configurare, instalare software, patching, schimbare
nume de gazdă și repornirea calculatoarelor)
 să automatizeze procesul de patching pentru sisteme de operare si
middleware pentru medii cluster, minimizând costurile forței de muncă si
asigurând în același timp că toate serverele sunt patch-uite și configurate
conform politicilor de securitate.
 să coordoneze procesul de patching al sistemelor de operare pentru aplicatii
complexe la nivel de server pe mai multe nivele, în ambele medii fizice și
virtuale
 să permită gestionarea setărilor de alimentare de pe același server
centralizat si din aceiasi consola pentru toate endpointurile ce rulează
sistemele de operare Windows și Mac
 să ofere capabilități out-of-the-box pentru a rezolva problemele de
gestionare a energiei comune, cum ar fi insomnie PC-uri și narcolepsie PC
 să asigure precizia necesară pentru a aplica politici la un singur calculator
atunci când este necesar
 să permită administratorilor să atribuie diferite valori de utilizare a
alimentarii pentru sistemele bazate pe caracteristicile detectate
 să ofere comenzi cu granulatie fina pentru optiuni ca: hibernare, standby sau
"salvați lucrul înainte de oprire"
 să permită utilizatorilor finali cu o abordare opt-in să selecteze profilul lor
de energie dintr-un meniu de opțiuni de configurare definit de administrator
 implică utilizatorii finali in inițiative de conservare prin intermediul unui
tablou de bord cu vizibilitate asupra consumului de energie individual și de
economii
 să permită crearea de scenarii de utilizare a energiei de tip "what if" și oferă
rapoarte de impact asupra mediului pentru a încuraja participarea la
inițiative de conservare
 să identifice și stabilește automat greseli ale profilului de alimentare
  păstrează datele utilizatorului, prin salvarea automată a documentelor înainte
de a începe o oprire sau o procedura de sleep/standby
 seteaza orare Wake-on-LAN (WOL) pentru a permite endpointului sa
porneasca înainte de începerea zilei de lucru sau a întreținerii programate
inclusiv suport pentru o “trezire” de la distanta
 Solutia să ofere raportare grafică in ceea ce privește utilizarea energiei
agregate și economiile realizate, cu capacitatea de a exporta datele de
raportare cu Microsoft Excel pentru analize suplimentare

7.1.6 Sistemul de management si monitorizare infrastructura

Sistemul trebuie sa includa o aplicatie care sa permita monitorizarea tuturor
echipamentelor.

Acest subsistem trebuie sa realizeze:

 Monitorizarea in mod centralizat, in timp real, a disponibilitatii si performantei

in exploatare a echipamentelor din componenta SIA al RS 112;
 Implementarea de functionalitati de analiza predictiva a functionarii
defectuoase a diverselor componente ale capacitatilor de calcul;
 Izolare automata a componentelor cu functionalitate defectuoasa;
 Va oferi capabilitati de avertizare in vederea asigurarii pieselor de schimb,
acest lucru concurand la maximizarea disponibilitatii fizice;
 Va oferi capabilitati de prezentare de informatii privind resursele utilizate,
gradul de integritate al diverselor componente, precum si posibilitatea
definirii si evidentierea unor praguri critice de utilizare.
 Posibilitatea de a minitoriza Private Automatic Branch Exchange (PABX)
voice switches; and Signaling System 7 (SS7 sau C7), network transport,
componente multiservice, etc.
Sistemul trebuie sa detina o unealta speciala ce adreseaza necesitatea securizarii
sporite a utilizatorilor cu drepturi depline (administrator). In vederea asigurarii
capacitatii de acces la sistem si securizarii acestuia trebuie oferita capabilitatea de
stoca si cripta parolele de tip administrator intr-baza de date speciala cu o cheie
unica de criptare de minim 200 bit.

• aceasta unealta trebuie sa fie compatibila FIPS 140-2.

• trebuie sa asigure capacitatea de pune capat unei sesiuni dupa o perioada
predefinita de inactivitate a utilizatoruli.
• sa trimita notificari rapide utilizatorui atunci cand parola este accesata sau
schimbata
• unealta trebuie sa ofere capabilitati offline

Sistemul trebuie sa puna la dispozitie urmatoarele functionalitati:

• Administrarea evenimentelor sistemelor de operare, printr-un jurnal de

evenimente la nivel de întreprindere care colectează şi raportează
problemele şi informaţiile generate referitoare la sistemele şi aplicaţiile
din reţeaua companiei;
 • Monitorizarea switch-urilor, routerelor şi altor dispozitive prin SNMP;
• Raportarea şi analiza tendinţelor necesare pentru urmărirea problemelor în
timp şi generarea rapoartelor detaliate despre starea de funcţionare
generală a mediului administrat;
• Monitorizarea aplicaţiilor distribuite pe mai multe servere;
• Soluția trebuie să dispună de un editor în mod grafic de componente ale
unui serviciu;
• Permita monitorizarea şi raportarea evenimentelor, urmărirea nivelului de
sănătate al sistemului;
• Permita identificarea fiecărui echipament din reţea printr-o icoană grafică;
• Aceste rapoarte trebuie să poată fi accesate local sau să poată fi publicate
în site-urile Web pentru accesul facil la informaţiile de administrare ale
sistemelor.
• Soluția trebuie să permită definirea de hărţi de monitorizare într-un editor
grafic, cu posibilităţi de a crea prin operaţii de tip wizard şi drag-n-drop:
o Harta echipamentelor în rack;
o Harta aplicaţiilor pe echipamente;
o Harta echipamentelor/aplicaţiilor în camerele unde sunt instalate;
o Harta camerelor în cadrul clădirilor;
o Harta clădirilor în cadrul oraşelor;
o Harta tuturor elementelor monitorizate la nivel de ţara sau glob.
• Utilizatorul trebuie să poată naviga între hărţi astfel încât să comute de la
un nivel de detaliere la altul, vizualizând oricând, în timp real, starea
aplicaţiilor şi a echipamentelor monitorizate;
• În cadrul unui proces informaţional utilizatorul trebuie să poată să ajungă
repede, din elementele de proces monitorizate până la poziţia în rack a
echipamentului care a produs defecţiunea;
• Modulul trebuie să permită crearea de hărţi de proces, geografice,
topologice sau de tip panou de bord pe care să se poziţioneze elementele
monitorizate;
• Hărţile elementelor monitorizate trebuie să poată fi afişate în baza rolurilor
utilizatorilor printr-un browser web;
• Să prezinte portleti specifici pentru cel puţin un portal (ex: Sharepoint,
Websphere, WebLogic etc);
• Crearea de rapoarte de disponibilitate a aplicaţiilor pe baza
interdependentelor între hărţi.
• Sa contina un modul SCADA pentru monitorizarea echipamentelor de
electroalimentare, climatizare si access control.

7.1.7 Sistemul de audit

Solutia trebuie sa fie din punct de vedere al securitatii compatibila cu standarde DSS.

Solutia trebuie sa fie livrata sub forma unui echipament fizic care sa indeplineasca
toate functionalitatile descrise in acest document.

Set de licențe permanente care vor asigura:

 • posibilitatea de colectare a log-urilor cu o performanță nu mai mică de
2500 EPS (înregistrări pe secundă);

Functii de baza:

• Soluția trebuie să aibă o arhitectură scalabilă;

• Soluția trebuie sa ofere posibilitatea de colectare și parsare a logurilor de
la diverse surse de date prin syslog, CEF, SNMP v1 & v3, SMTP, WMI,
SQL, SDEE, RDEP, OPSEC, XML, ODBC sau din “flat files” folosind SCP,
FTP sau HTTP de la surse CIFS sau NFS
• Soluția trebuie sa se folosească de o baza de date optimizată si indexată
pentru a pentru a permite stocarea si analiza istorica, la viteze ridicate
asupra evenimentelor.
• Soluția trebuie să ofere posibilitatea atât de management fișiere log cât și
management de evenimente;
• Soluția trebuie să ofere posibilitatea de a înţelege fişiere log de formate
diferite, cât şi definirea formatelor de către administrator;
• Soluția trebuie să permită corelarea datelor din diferite surse şi generarea
de alerte automate;
• Soluția nu trebuie să necesite utilizarea aplicațiilor soft terțe în procesul de
colectare a fişierelor log, pentru care ar fi necesare achiziții suplimentare
de careva licențe.
• Soluția trebuie să poată lucra atât în regim de lucru în timp real cât şi în
baza log-urilor existente;
• Soluția trebuie să ofere posibilitatea de limitare a benzii/volumului de date
colectat de la surse de date;
• Soluția trebuie să ofere un mecanism care să asigure livrarea/primirea
ulterioară a evenimentelor de la surse în cazul indisponibilităţii sale
temporare;
• Soluția trebuie să permită stocarea evidenţelor atât local pe disc cât şi
posibilitatea de fi integrate cu NAS/SAN;
• Soluția trebuie să poată verifica în regim automat operabilitatea
componentelor sistemului și să notifice în cazul apariției deficiențelor;
• Soluția trebuie să poată recepționa date criptate;
• Soluția trebuie să poată identifica și adăuga surse în mod automatizat
(autodiscovery), dar și manual de către administrator;
• Soluția trebuie să asigure independența funcțională a componentelor (ex.
dacă consola de management se oprește, sistemul va continua colectarea și
analiza log-urilor);
• Soluția trebuie să poată colecta și procesa logurile generate de cel puțin
următoarele sisteme:
o Bazelor de date;
o Echipamente de retea si communicatii, securitate;
o Sisteme Operaţionale și virtuale
• Soluția trebuie sa ofere mecanisme de integrare cu servicii de
autentificare si autorizare precum: Active Directory, RADIUS, LDAP.
 • In cazul folosirii de colectori pentru strângerea evidențelor, şi întreruperii
legăturii cu instanța de prelucrare, colectorii trebuie să stocheze datele
local şi să le transmit online la consola centrală;
• Soluția trebuie să ofere mecanisme împotriva falsificării evidenţelor şi
modificării datelor colectate;
• Soluția nu trebuie să modifice marcajele originale de timp din cadrul
evenimentelor prelucrate;
• Soluția trebuie să poată corela evenimente primite de la surse cu fusuri
orare diferite;
• Soluția trebuie să permită crearea de politici grupate după tipul logurilor şi
evenimentelor prelucrate;
• Soluția trebuie să permită ca din cadrul dashboardului, din informații
generale, prin accesarea acestora să fie posibilă trecerea la un nivel mai
detaliat de prezentare;
• Soluția trebuie să accepte ca parametri de căutare atât exemple simple
precum şi mai avansate, precum utilizarea de expresii regulare, interogări
SQL, etc.;
• Soluţia trebuie să permită căutarea datelor prin combinarea interogărilor
de diferite tipuri: textuale, expresii regulate, căutări în date deja
structurate sau în cele nestructurate
• Soluția trebuie să permită căutarea fără reţineri printr-un număr mare de
înscrieri structurate (indexate). Timpul de căutare trebuie să fie unul
rezonabil;
• Soluția trebuie să permită căutarea oricărui element prezent în cadrul
fişierelor log colectate;
• Soluția trebuie să permită căutarea utilizând expresii logice “şi”, “sau”, “nu”,
precum şi combinaţii ale acestora;
• Soluția trebuie să permită căutarea pe intervale de timp fixe cât şi dinamice
(exemplu: “Acum – 2h”);

Arhivare și restabilire:

• Soluția trebuie să poată arhiva/restabili fișiere log nenormalizate;

• Setarea modului/procedurilor de arhivare/restabilire trebuie să fie
accesibil şi configurabil din interfaţa de utilizator;
• Soluția trebuie să permită stocarea datelor pe dispozitive externe;
• Soluția trebuie să asigure integritatea datelor ce au fost arhivate;
• Soluția trebuie să poată asigura stocarea în formă arhivată a logurilor
pentru o perioadă de cel puţin 12 luni, cu posibilitatea vizualizării (analizei)
online a informaţiei pentru cel puţin ultimele 3 luni.

Analiza logurilor si evenimentelor:

• Soluția trebuie să permita analiza logurilor şi altor evenimente în timp real;

• Soluția trebuie să permită căutarea simultană prin evenimentele parvenite
de la toate sursele conectate;
• Soluția trebuie să permită corelarea evenimentelor şi prioritizarea lor şi a
alertelor care sunt declanşate;
• Soluția trebuie să permită monitorizarea integrităţii fişierelor;
• Soluţia trebuie să permită analiza fluxurilor de date în reţea;
• Soluția trebuie să permită colectarea distribuită a fişierelor log astfel încât
să fie posibilă divizarea pe echipamente a sarcinilor de prelucrare,
agregare, compresie, criptare etc.;
• Soluția trebuie sa ofere posibilitatea de audit asupra utilizatorilor
privilegiați.
• Soluția trebuie să aducă evenimentele la o formă lizibilă eliminând date
specifice şi neinformative;
• Soluţia trebuie să includă reguli predefinite de corelare a datelor de la
diferite surse, tipuri de evenimente şi fişiere log atât în timp real cât şi
colectate deja;
• Soluția trebuie să permită monitorizarea atacurilor asupra resurselor sau
utilizatorilor critici;
• Soluția trebuie să detecteze atacurile „Zero Day”, „DoS”/”DDoS”a
aplicațiilor malițioase sau cu potențial riscant (peer-to-peer, file sharing)
și să analizeze severitatea evenimentului;
• Soluția trebuie să permită monitorizarea activităţilor la nivelul bazelor de
date şi determinarea dacă au loc activităţi neautorizate;
• Soluția trebuie să poată identifica tentativele de scoatere a informațiilor
sensibile în afara perimetrului rețelei;
• Soluția trebuie să permită corelarea datelor dintre DHCP, VPN şi Directory
Service (Active Directory) pentru a putea urmări activitatea oricărui
utilizator în cazul investigării unui incident;
• Soluția trebuie să permită corelarea evenimentelor atât cu liste statice de
elemente permise (gen listă a protocoalelor nesecurizate) cît şi crearea
listelor dinamice cum ar fi atacuri, sesiuni, încălcări de politici;
• Soluția trebuie să poată grupa logic evenimentele recepționate în grupuri în
funcție de sursa acestora, caracterul critic, aplicația generatoare sau
rețeaua din care provin. Gruparea dată trebuie să fie disponibilă și să asiste
filtrarea și segregarea a evenimentelor la formarea rapoartelor sau la
vizualizare din interfața de onitorizare/administrare;
• Soluția trebuie să permită detectarea şabloanelor de activitate care de
altfel în timp real nu pot fi detectate;
• Soluția trebuie să poată agrega, dar și elimina/suspenda alertarea în baza
unor setări prestabilite de către administrator;
• Soluția trebuie sa suporte RBAC (Role based access) pentru utilizatori si
grupuri de utilizatori.
• Soluția trebuie să includă instrumente de investigare a incidentelor cum ar
fi WHOIS, DIG, NSLOOKUP, TRACEROUTE etc.;
• Soluția trebuie să dispună de interfețe ce ar permite integrarea cu alte
soluții de securitate sau instrumente de administrare a rețelei necesare în
investigarea incidentelor;
 • Soluția trebuie să ducă înregistrări de audit pentru toate activitățile
desfășurate pentru investigarea și managementul incidentelor identificate;
• Soluția trebuie să dispună de instrumente ce ar identifică şi remedia
incidentele pe măsura apariției acestora.
• Soluția trebuie să permită creare de job-uri automatizate.

Notificare si alerte:

• Soluția trebuie să detecteze automat întreruperile în procesul de colectare

a fişierelor log de la surse și să poată ridica/expedia alerte persoanelor
desemnate/prestabilite.
• Soluția trebuie să permită generarea de alerte în baza unor
parametri/indicatori prestabiliţi;
• Soluția trebuie să permită generarea alertelor prin diferite metode cum ar
fi SMS, SMTP, SNMP etc.
• Soluția trebuie să conţină alerte predefinite şi customizabile.
• Soluția trebuie să permită generarea de alerte în baza priorităţilor
evenimentelor.
• Soluţia trebuie să permită customizarea textelor alertelor.
• Soluția trebuie să detecteze atacurile (nivel rețea/baze de date) și
anomaliile în comportament și să notifice/alerteze persoanele predefinite.

Raportare:

• Soluția trebuie să poată genera rapoarte pentru perioade de până la un an

calendaristic;
• Soluția trebuie să poată genera rapoarte privind activitatea utilizatorilor
acesteia: (ex. creare rapoarte, creare/modificare politici etc. );
• Soluția trebuie sa conțină o serie de rapoarte predefinite, folosite in
industrie precum: PCI, Basel, FISMA, GLBA, HIPPA, NERC, Sarbanes-
Oxley, SOX, ISO 27002 fără a fi necesara cumpărarea unor licențe
suplimentare.
• Soluția trebuie să permită raportare automată în funcție de un calendar
prestabilit (în anumite zile, la anumite ore sau cu o anumită periodicitate)
cu livrarea rapoartelor către destinatari;
• Soluția trebuie sa ofere cel puțin, dar sa nu fie limitată la, 600 rapoarte
standarde predefinite incorporate.
• Soluţia trebuie să permită creare de rapoarte prin interfeţe intuitive și
asistate;
• Soluția trebuie să permită importarea imaginilor, graficelor în cadrul
şabloanelor rapoartelor;
• Soluția trebuie să permită vizualizarea datelor prin intermediul graficelor
dinamice, precum și exportarea acestora în afara aplicației;
• Soluția trebuie să poată exporta rapoartele în cel puțin următoarele
formate: PDF, XML, HTML, CSV.

Interfete:
 • Soluția trebuie sa ofere o interfață de management “web based” care sa fie
accesibila folosind protocolul HTTPS.
• Să permită managementul centralizat al tuturor componentelor din cadrul
interfeței de management;
• Soluția trebuie sa ofere posibilitatea de customizare a panourilor de
control, precum si posibilitatea de a crea spatii de lucru specifice in funcție
de necesitățile utilizatorului.
• Soluţia trebuie să permită vizualizarea utilizatorilor ce sunt autentificaţi în
sistem;
• Soluţia trebuie să permită monitorizarea echipamentului pe care este
instalat;
• Soluția trebuie să permită determinarea vizuală la nivel de interfeţe, care
surse furnizează evenimente şi care nu;

Comunicare dintre agent si server – controlul accesului:

• Soluția trebuie să permită controlul accesului asupra interfeţelor, datelor,

surselor, rapoartelor;
• Soluția trebuie să asigure ca accesul în sistem să fie efectuat prin utilizarea
conturilor de acces personalizate (username personalizat + parole
complexe);
• Soluția trebuie să asigure ca comunicarea dintre agenții colectori și server
să se producă în formă criptată.

Instalarea produsului trebuie să fie simplă, directă și nu trebuie să necesite multe

resurse.

7.2 Infrastructura hardware

Specificatiile de mai jos se refera la specificatiile minime de procesare, stocare si

backup la nivel de centru.

Toate echipamente de procesare, stocare si backup, retea si comunicatii la nivel de

centru trebuie sa fie compatibile cu standard EIA-310 19 inch RETMA (EIA-310D
Type A cabinet per section 4.1.1), UL/CES Certification, RoHS, WEEE. Cantitatea
minima a dulapurilor pentru echipamente instalate este 3 dulapuri de 42U. La final
minimum 42U trebuie sa fie disponibile/libere.

Toate echipamentele trebuie sa fie acoperite cu Garantie de la Producator pe o

perioada de minim 3 ani din momentul livrarii.

7.2.1 Sistemul de procesare

In cadul acestei sectiuni sunt prezentate specificatiile minime aferente fiecarui
element de procesare ce trebuie inclus in oferta tehnica. Specificatiile acestora
reprezinta minimul considerat acceptabil pentru necesitatile autoritatii. Ofertantii vor
tine seama de toate cerintele caietului de sarcini, vor dimensiona solutia avand in
vedere toate aceste specificatii si va prezenta o justificare a resurselor incluse,
propunand un tabel centralizator in care sunt incluse cel putin numarul de
echipamente propuse pentru fiecare centru, resursele de procesare evidentiindu-se
alocarea solutiilor software in cadrul fiecarui element de procesare si va dimensiona
sistemul in asa fel incat licentierea sa acopere toate resursele fizice.

Suplimentar se vor include in oferta, suplimentar fata de sistem, o cantitate resurse

suplimentare de procesare care sa asigure 20% din resursele necesare sistemului.

Sistemul de procesare trebuie sa respecte arhitecturi moderne de datacenter.

7.2.1.1Procesare centralizata la nivel de centru

Sistemul de procesare centralizata trebuie sa asigure înalta disponibilitate la nivel
hardware. In acest sens fiecare element de procesare va fi asigurat cu un nivel de
redundanta fizica integrata ce va realiza disponibilitatea puterii minime de calcul
specificate chiar si in condiții de defect localizat prin metode de izolare a
componentei defecte si înlocuire cu o componenta funcțională fără întreruperea
procesului de calcul.

Sistemul de procesare centralizata trebuie sa asigure acomodarea mai multe servere

și comutatori de rețea într-o singură carcasă redundantă pentru toate componente
(inclusiv management, ventilarea, răcirea), asigurând consum minim de energia
electrică si sistem de cablare simplu.

In caz de necesitatea pentru funcții specifice pot fi utilizate si servere de tip rack
mount.

Toate conexiunile la nivel central trebuie sa fie redundante si minimum:

 10Gb pentru conexiuni Ethernet/iSCSI

 16Gb pentru conexiuni Fibre Channel
 100Mb/1Gb pentru interfețele de management (redundanța este opțională)

Specificații element procesare:

 Procesare centralizata la nivel de centru trebuie sa fie bazata pe solutia de tip

„Blade”
 Cantitatea minima de servere de procesare est 8 bucati
 Procesare – 2 procesoare E5-2600 generație v4 12 core, viteza de calcul de
baza minim 2,2 GHz, minim 30 MB cache, 9.6GT-s QPI, 90W
 Chipset: Intel® C610 sau superior
 Stocare – 2 x 400GB 2.5-inch 12G SAS Write Intensive SFF Solid State Drive
 Memorie - DDR4 – 128GB, expandabil pana la 2TB (16 x 128GB) up to
2400MT/s at 1.2V, minim 16 slot
 Conexiuni pentru server de tip rack mount – 2 x USB 3.0 port, 1 x MicroSD
card slot, 1x VGA port, 2x RS232 serial port, 2 x 10GbE port, 1x GbE RJ45
management port dedicat
 Slot de expansiune: 1x PCIe gen3 x8 OCP slot, 1x PCIe gen3 x16 FHHL, 1x
PCIe gen3 x16 HHHL
 Trusted platform module (TPM)
 EMC : EMC Directive, 2014/30/EU, ETSI EN 300 386
 Siguranța: Low Voltage Directive 2014/35/EU IEC/EN 60 950-1:
  Safety of information technology equipment
 RoHS: RoHS Directive, 2011/65/EU EN 50 821

7.2.1.2Procesare de tip client la nivel de centru

Se vor asigura resurse de procesare pentru fiecare client ce vor urmări următoarele
capacități si specificații:

 Procesare – 4 core, 8 fire de execuție, viteza de calcul de baza minim 2 GHz,

minim 25 MB cache
 Stocare – 240 GB redundant
 Memorie – 16 GB, expandabil pana la 32 GB
 Video – 3 ieșiri video distincte (afișare imagini diferite) rezoluție nativă pentru
monitor 1920 × 1080 (compatibile fără adaptor cu monitoarele ofertate)
 Slot de expansiune PCIe x16 liber
 Conexiuni – minim 2x Gigabit Ethernet, minim 2x USB 3.0, minim 2 x jack
audio in / aut
 Carcasa – minitower
 Monitor – 3 unități, 23in, oferind o rezoluție totală de 5760 × 3240, mărimea
pixului nu mai mult de 0.28mm, timp de răspuns maxim 7ms, contrast static
minim 1000:1, unghi de vizibilitate 170/160, VESA 100 x 100 mm, conector
compatibil fără adaptor cu resursa de procesare, mutabile fie in cadrul
punctului de lucru fie pe un singur stand.
 USB Tastatura multifuncțională, USB 1000dpi Laser Mouse

7.2.1.3Procesare de tip client pentru mediul de instruire

Se vor asigura resurse de procesare pentru fiecare client ce vor urmări următoarele
capacități si specificații:

 Procesare – 4 core, 8 fire de execuție, viteza de calcul de baza minim 2 GHz,

minim 25 MB cache
 Stocare – 240 GB redundant
 Memorie – 16 GB, expandabil pana la 32 GB
 Video – 3 ieșiri video distincte (afișare imagini diferite) rezoluție nativă pentru
monitor 1920 × 1080 (compatibile fără adaptor cu monitoarele ofertate)
 Slot de expansiune PCIe x16 liber
 Conexiuni – minim 2x Gigabit Ethernet, minim 2x USB 3.0, minim 2 x jack
audio in / aut
 Carcasa – minitower
 Monitor – 3 unități, 23in, oferind o rezoluție totală de 5760 × 3240, mărimea
pixului nu mai mult de 0.28mm, timp de răspuns maxim 7ms, contrast static
minim 1000:1, unghi de vizibilitate 170/160, VESA 100 x 100 mm, conector
compatibil fără adaptor cu resursa de procesare, mutabile fie in cadrul
punctului de lucru fie pe un singur stand.
 USB Tastatura multifuncțională, USB 1000dpi Laser Mouse
7.2.1.4Procesare de tip client la nivel dispecer

Se vor asigura resurse de procesare pentru fiecare client ce vor urmări următoarele
capacități si specificații:

 Procesare – 4 core, 8 fire de execuție, viteza de calcul de baza minim 2 GHz,

minim 25 MB cache
 Stocare – 240 GB redundant
 Memorie – 16 GB, expandabil pana la 32 GB
 Video – 3 ieșiri video distincte (afișare imagini diferite) rezoluție nativă pentru
monitor 1920 × 1080 (compatibile fără adaptor cu monitoarele ofertate)
 Slot de expansiune PCIe x16 liber
 Conexiuni – minim 2x Gigabit Ethernet, minim 2x USB 3.0, minim 2 x jack
audio in / aut
 Carcasa – minitower
 Monitor – 3 unități, 23in, rezoluție sumară 5760 × 3240, mărimea pixului nu
mai mult de 0.28mm, timp de răspuns maxim 7ms, contrast static minim
1000:1, unghi de vizibilitate 170/160, VESA 100 x 100 mm, conector
compatibil fără adaptor cu resursa de procesare, mutabile fie in cadrul
punctului de lucru fie pe un singur stand.
 USB Tastatura multifuncțională, USB 1000dpi Laser Mouse

7.2.1.5Sistem de afisare generala

Camera operatorilor vor prevazuta cu un perete de prezentare generala (de tip

„VideoWall”) format din 12 ecrane cu diagonala totala de minim 4,5 metri cu
posibilitatea de a administra centralizat si rezolutie totala de minim 4k si care va
respecta urmatoarele:

 Technologie- SPVA LED

 Diagonala - minim 1300 mm
 Pixel Pitch - maxim 0.65mm
 Luminozitate - 700cd/m2
 Contrast - 3300:1
 Unghi - 178° orizontal 178° veritacal
 Refresh Rate - 60Hz
 Disipare de caldura (max) - 750 BTU/h
 Regim de functionare 24/7 – garantat 100.000 ore
 Rama monitor – maxim 3.9 mm

Se vor livra suplimentar 4 monitoare de expunere date diverse. Acestea vor respecta
urmatoarele cerinte:

 Technologie- SPVA LED

 Diagonala - minim 1300 mm
 Pixel Pitch - maxim 0.65mm
 Luminozitate - 700cd/m2
 Contrast - 3300:1
  Unghi - 178° orizontal 178° veritacal
 Refresh Rate - 60Hz
 Disipare de caldura (max) - 750 BTU/h
 Regim de functionare 24/7 – garantat 100.000 ore
 Rama monitor – maxim 3.9 mm

7.2.1.6Sisteme de imprimare

Centul va fi dotat cu 2 sisteme de imprimare care sa asigure cel putin urmatorele:

Functii disponibile Copiator, imprimanta retea, scaner

retea, optional fax
Dimensiune hartie A5-A3
Duplex automat inclus, fara limita de pagini
Suport echipament cu roti inclus
Viteza copiere/imprimare alb-negru si color minim 25 ppm
(A4)
Viteza copiere/imprimare alb-negru si color minim 13 ppm
(A3)
Greutate maxima hartie din toate casetele minim 256 g/mp
Greutate maxima hartie in mod duplex minim 220 g/mp
automat
Greutate maxima hartie din bypass minim 256 g/mp
Timp de incalzire maxim 45s
Tava manuala de hartie (bypass) 100 coli la 80 g/mp
Alimentator automat de documente reversibil 50 coli la 80 g/mp
Alimentare hartie standard minim 500 coli la 80g/mp
Memorie minim 1.5 GB RAM cu posibilitate
de extindere pana la 2GB RAM
Procesor Minim 800 MHz
Conexiuni standard USB 2.0 (Hi-Speed), USB Host
2.0, Fast Ethernet
10BaseT/100BaseTX/1000BaseT,
optional paralel
Coduri de acces 100 coduri de departament
Ecran tactil color
Consum de energie in modul de asteptare 1W
Putere consumata in regim de Maxim 600 W
copiere/tiparire
Functii Copiere
Copiere multipla 1-999copii
Prima copie maxim 11.7s (alb-negru) si maxim
13.6s (color)
Zoom 25-400% in pasi de 1%
Rezolutie copiere 600 x 600 dpi, interpolat 9600 x
600 dpi sau 4800 x 1200dpi
 Functii Scanare
Destinatii de scanare catre USB stick, catre adresa e-
mail, catre Fisier (SMB, FTP
Server)
Formate fisiere scanate TI FF, PDF, PDF/A, JPEG, XPS
Functii Tiparire
Prima pagina Maxim 10s (alb-negru) si maxim
12s (color)
Limbaj de imprimare PCL6, XPS
Sisteme de operare compatibile Windows 2000, Windows XP,
Windows Server 2003 (32/64 bit),
Windows Server 2008 R2 (64 bit),
Windows Vista, Windows 7, Mac
OS X, Linux/UNIX
Consumabile incluse: Tonere: - pentru min. 3.000 pagini
A4 pentru alb negru si 1.500
pagini A4 pentru color
Cilindrii si developere – pentru
minim 200.000 pagini

7.2.2 Sistemul de stocare

Toate conexiunile pentru sistem de stocare trebuie sa fie redundante si minimum
16Gb pentru conexiuni Fibre Channel. Conexiuni iSCSI nu sunt acceptabile.

7.2.2.1Dispozitiv de stocare

Pentru stocarea datelor de productie, se doreste achizitionarea unei solutii de

stocare de inalta disponibilitate compus din 2 x (doua) dispozitive de stocare, ce
include capabilitati dual-controller cu functionalitati de tip Metro Cluster (sau
echivalent pentru dispozitive), pentru asigurarea accesului neintrerupt la datele
stocate, chiar si in cazul in care un dispozitiv de stocare devine indisponibil. Sistemul
trebuie sa respecte urmatoarele cerinte minimale:

Capacitate utila instalata la livrare pentru fiecare dispozitiv de stocare:

 Minim 6 TB pe drive-uri SSD / Flash in configuratie RAID 1+0

 Minim 18 TB pe drive-uri SAS folosind disk-uri in configuratie RAID 6.

Sistemul trebuie sa includa cel putin cate un disc de rezerva (Spare) pentru fiecare
tip de drive sau alte mecanizme de rezerva. Capacitatile utile propuse vor fi cele
disponibile efectiv serverelor.

In vederea asigurarii capacitatilor de extindere, sistemul trebuie sa poata acomoda

minim 700 TB.

Sistemul trebuie sa permita crearea de LUN-uri de pana la 50 TB.

Numar de hosturi suportate minim 2048.

Sistemul trebuie sa includa 2 controllere, capacitatea memorie cache instalata minim
64 GB RAM.

Memoria cache sa poata fi impartita in mai multe zone, care sa poata fi folosite
exclusiv de anumite LUN-uri / aplicatii, astfel incat sa se poata garanta alocarea
unei anumite zone din memoria cache pentru aplicatiile intensive IOPS.

Porturi de acces:

 Sistemul trebuie sa suporte conexiuni FC la 4/8/16 Gbps si porturi iSCSI la 10

Gbps.
 In configuratia livrata, sistemul va fi echipat numai cu porturi FC la 16 Gbps.

Numar de porturi FC la 16 Gbps: 4 porturi FC la 16 Gbps instalate in configuratia

propusa.

Arhitectura back-end:

 Controller-ele sistemului trebuie sa aiba legaturi SAS la 12 Gbps catre

discuri.
 Latimea de banda totala a legaturilor SAS catre discuri: minim 96 Gbps.

Discuri suportate minim NL-SAS, SAS si SSD / Flash.

Nivele RAID suportate minim 0, 1, 5, 6.

Sisteme de operare suportate (cu drivere si software aferent pentru hosturi inclus):
Microsoft Windows Server, Red Hat Enterprise Linux, SuSE Linux Enterprise
Server, Oracle Enterprise Linux si Vmware.

Management:

 Software de management si configurare a echipamentului.

 Consola de management trebuie sa permita partitionarea sistemului de stocare
in mai multe sisteme virtuale, astfel incat pentru diverse aplicatii / grupuri de
aplicatii / departamente sa poata fi dedicate partitii individuale ale sistemului
de stocare.
 Daca Software-ul trebuie licentiat, atunci pentru intreg sistemul, indiferent de
capacitatea initiala sau viitoare a acestuia.

Multipathing:

 Sistemul trebuie sa includa capabilitati de multipathing: failover si load

balancing, indiferent de numarul de servere care se vor conecta la sistem
(initial si ulterior).
 Aplicatia de multipathing trebuie sa fie disponibila cel putin pentru sisteme de
operare Microsoft Windows Server, Red Hat Enterprise Linux, SuSE Linux
Enterprise Server, Oracle Enterprise Linux si VMware.
 Aplicatia trebuie sa dispuna de o consola centrala de management care sa
permita monitorizarea tuturor instantelor de pe serverele care acceseaza
sistemul de stocare.
  Aplicatia trebuie sa dispuna de o consola centrala de management care sa
permita configurarea de alerte prin email, in mod centralizat, despre starea /
indisponibilitatea cailor de acces.

Disponibilitate:

 Capabilitati hot sparing.

 Upgrade-urile de firmware, software si hardware trebuie sa se poata face
fara oprirea sistemului.
 Protectia memoriei cache la caderile de curent prin descarcarea datelor direct
pe discuri sau memorie non-volatila.

Securitatea datelor:

 Suport pentru criptarea datelor stocate (“at rest”) in cadrul sistemului. Licenta
pentru functia trebuie sa fie inclusa in configuratia propusa.

Optimizare capacitatii pe disk-uri de tip Flash: functionalitate care sa permita

compresia datelor stocate pe drive-urile SSD / Flash, cu o rata de compresie de cel
putin 2:1, astfel incat capacitatea utila oferita pe drive-urile Flash sa fie dubla.

Replicare locala: Sistemul trebuie sa ofere suport pentru replicarea locala a

volumelor, atat de tip snapshot cat si clona.

Replicare la distanta: Sistemul trebuie sa includa suport replicarea la distanta a

volumelor, atat de tip sincron cat si asincron prin canalele IP si FC.

Solutia Metro Storage Cluster:

 Suport pentru creare de cluster activ-activ intre doua sisteme de stocare de

acelasi tip, in vederea asigurarii unei disponibilitati maxime a datelor (chiar si
intre doua locatii diferite).
 Functia trebuie sa permita acces de tip read / write la aceleasi date in cele 2
sisteme membre ale cluster-ului (chiar si in doua locatii diferite) si comutarea
automata a accesului la date de pe un sistem pe altul, in cazul in care un
sistem devine indisponibil.
 Functia trebuie sa fie inclusa in configuratia propusa, licentiata pentru intreg
sistemul, indiferent de capacitatea initiala sau viitoare a acestuia, si va fi
folosita pentru crearea solutiei de stocare de inalta disponibilitate pentru
mediul de productie.

Multi-tiering: Prezenta unei funcționalități (licențiată pentru întreg sistemul,

indiferent de capacitatea inițială sau viitoare a acestuia) care sa permită definirea de
volume logice pe mai multe tier-uri de stocare (mai multe tipuri de discuri) si
migrării automate a blocurilor de date de pe un tier pe altul, in funcție de rata de
acces a acelor blocuri de date.

Virtualizare externa: Prezenta unei functionalitati (licentiata pentru intreg sistemul,

indiferent de capacitatea initiala sau viitoare a acestuia) care sa permita virtualizarea
de sisteme de stocare externe eterogene, incluzand capabilitati de multi-tiering
(intre discuri interne si discuri de pe sistemele de stocare externe virtualizate), thin
provisioning (si pentru volumele logice definite pe sistemele de stocare externe
virtualizate) si migrare date (intre discuri interne si discuri de pe sistemele de
stocare externe virtualizate).

Monitorizare preventiva: Facilitate de monitorizare si mentenanta preventiva, care sa

permita raportarea starii sistemului si alertarea asupra eventualelor probleme
aparute. Facilitatea trebuie licentiata pentru intreg sistemul, indiferent de capacitatea
initiala sau viitoare a acestuia.

Monitorizare performanta: Facilitate de monitorizare a performantei sistemului de

stocare in timp real. Facilitatea trebuie licentiata pentru intreg sistemul, indiferent de
capacitatea initiala sau viitoare a acestuia.

Alocare spatiu: Posibilitatea alocarii spatiului de stocare date, fara ca spatiul sa fie
disponibil fizic (virtual storage / thin provisioning).

Migrare date:

 Posibilitatea migrarii / mutarii datelor in interiorul echipamentului, de pe o

matrice RAID pe alta, de pe discuri de un anumit model pe discuri diferite,
fara oprirea sistemului sau aplicatiilor.
 Migrarea datelor trebuie sa fie facuta la nivel de volum logic (LUN) si trebuie
sa poata fi programata astfel incat sa aiba un impact minim asupra accesului la
datele migrate.
 Functia trebuie sa fie inclusa in configuratia propusa si licentiata pentru intreg
sistemul, indiferent de capacitatea initiala sau viitoare a acestuia.

Asigurarea calitatii:

 Suport pentru configurarea de prioritati in utilizarea echipamentului de stocare

de catre anumite aplicatii, in anumite momente.
 Functia trebuie sa fie inclusa in configuratia propusa si licentiata pentru intreg
sistemul, indiferent de capacitatea initiala sau viitoare a acestuia.

7.2.2.2Echipamente de conectare.

Echipamente de conectare redundante. Număr si tip de porturi active Fibre Channel

pentru conectarea dispozitivelor: minimum 24 porturi FC la 16 Gbps active, toate
echipate cu transceiver-e SFP+.

Tip conector pentru interfețele FC din switch: 16 Gbps ShortWave Length (SWL)
Fibre Channel SFP+ Tranceiver.

Bandwidth agregat: Non-blocking architecture, Min. 384 Gbps full duplex.

Patch cord-uri fibra optica: patch cord-uri multimode OM4 LC-LC de 5m pentru
toate conexiunele.

Scalabilitate: minim 200 switch-uri in arhitectura full-fabric.

Capabilitati zonare: Switch-ul trebuie sa permita definirea de zone de acces la nivel

de porturi sau de adrese WWN.
7.2.2.3Sistemul de backup

Pentru stocarea datelor de salvare si restaurare, se doreste achizitionarea unei

solutii de stocare de 2 nivele (production – disk backup – tape backup), aceasta
trebuie sa respecte urmatoarele cerinte minimale:

Capacitate instalata la livrare minim 40 TB raw space pentru disk backup.

Capacitate instalata la livrare minim 70 TB space pentru tape backup.

Pentru a optimiza procesul de backup solutia propusa trebuie sa fie solutia

compatibila cu dispozitive de stocare propuse. Software necesar cu toate licente
necesare trebuie sa fie incluse.

7.2.3 Sistemul de sustinere si protectie

In vederea asigurarii automatizarii sistemului de sustinere si protectie a activitatilor
din cadrul centrelor se va implementa o aplicatie de tip SCADA de monitorizare si
control a DC

Caracteristici Cerinta tehnica minimala

Tip aplicatie Web based, pentru accesarea HMI si configurarea

sistemului va fi folosit exclusiv un browser web

Baze de date Pentru fiabilitate, aplicatia nu va utiliza un motor de

baze de date relational distinct

Functionalitati Monitorizeaza functionarea sistemelor datacenter:

tablou alimentare, tablou automatizare generator,
UPS-uri, sisteme climatizare, sistem acces, sistem
antiincendiu

Controleaza sistemele mentionate mai sus pentru a

mentine parametrii optimi de functionare a
echipamentelor in fuctie de conditiile de mediu si de
exploatare.

Monitorizeaza functionarea echipamentelor gazduite in

datacenter (temeperaturi, vibratii, tensiuni) si
ajusteaza caracterisiticile mediului ambiant in
consecinta.

Afiseaza grafice privind marimile monitorizate si

controlate. Proiecteaza trenduri cu privire la acestea.

7.2.3.1 Sistem de acces si control fizic

Solutia propusa va include o aplicatie ce va fi integrata cu sistemul de reglementare
a accesului in sistem prin protocol LDAP. Sistemul va include panouri de control,
card readere, senzori de citire carduri, incuietori magnetice, mecanisme de
deblocare in caz de urgenta, senzori de fum, foc, prezenta si camere de
supraveghere.
 1. Caracteristici Cerinta tehnica minimala

Tip sistem acces Incuietori de tip yale electromangentice, panouri de

autentificare RFID/NFC + cod personal sau biometrice
+ cod personal

Autonomie: 72 de ore in cazul opririi alimentarii cu energie

electrica

Management local si remote Interfata de administrare WEB. Integrare LDAP.

Integrat in aplicatia SCADA de monitorizare a DC

Garantie: 24 luni cu interventie de tip next business day

7.2.3.2 Sistem generare energie

Caracteristici Cerinta tehnica minimala

Tip generator Diesel, 400V 3Ph. Minimum 120kVA

Autonomie: 72 ore pentru echipamentele ofertate inclusiv pentru

racire

Management local si remote Automatizare pentru pornirea automata. Integrat in

aplicatia SCADA de monitorizare a DC

Garantie: 24 luni cu interventie de tip next business day

Alte cerinte Ofertantul va urmari ca intreaga infrastructura sa aiba

un consum cat mai redus de energie electrica,
prezentand in acest sens o schema detaliata a
conexiunilor electrice si un bilant energetic al
echipamentelor in functie de incarcare.

7.2.3.3 Sistem alimentare neintrerupta

Caracteristici Cerinta tehnica minimala

Tip UPS UPS online funcționare redundanta 1+1 cu design

redundant intern

Autonomie: cca 30min pentru echipamentele ofertate inclusiv

pentru racirea de urgenta

Tehnologie: online cu dubla conversie cu intrare PFC si bypass

automat, unda sinusoidala la iesire; protectie integrata
impotriva fenomenului de backfeed (retur de energie
in retea)

Format rackmount cu accesorii de montaj in rack incluse sau

deja montat in rack (tower)

Tensiune intrare: 400V 3ph; eficienta iesire: 92% in mod online la

 incarcarea generata de echipamentele ofertate

Management local si remote Afisaj LCD; Management Web/SNMP cu port ethernet

RJ45. Integrat in aplicatia SCADA de monitorizare a
DC

Scalabilitatea Power ratiing 20-400kW cu posibilitatea de a conecta

in paralel cu alt UPS. La livrare minimum 120kVA

Alte cerinte Ofertantul va urmari ca intreaga infrastructura sa aiba

un consum cat mai redus de energie electrica,
prezentand in acest sens o schema detaliata a
conexiunilor electrice si un bilant energetic al
echipamentelor in functie de incarcare.

7.2.3.4 Sistem climatizare

Sistem climatizare pentru Data Centre.

Tip sistem racire -Unitate aer conditionat pentru camera tehnica,

configuratie redundanta
-Functionare prin condensare cu condensator extern;
-Conectarea conductelor on site prin conexiuni lipite;
-Valva de siguranta inclusa;
-Posibilitate de oprire individuala a conexiunilor;
-Sistem racire de urgenta in cazul opripirii alimentarii
- Free cooling
Capacitate neta racire Minim 20 KW
Energy Efficiency Ratio Minim 3 kW/kW
(EER)
Nivelul de zgomot Maxim 80 dB(A)
Flux de aer Minim 7000 m3/h
Dimensiuni inaltime x latime Maxim 1900x1000x850 mm
x adancime
Greutate Maxim 350 kg
Alimentare energie electrica 380-415 Vac
Viteza aer Minim 2,5 m/s
Ventilator
- Consum electric Maxim 1,7 kW
- Viteza rotatie Minim 1400 rpm
- Eficienta Minim 80%
Compresor
-Consum electric Maxim 5.2 kW
-Coeficient de Minim 3.9 kW/kW
performanta (COP)
Condensator
-Flux de aer Minim 11000 m3/h
-Numar ventilatoare Minim 2
-Greutate Maxim 95 kg
 -Dimensiuni inaltime Maxim 950x1900x800 mm
x latime x adancime
Management local si remote Afisaj LCD
Alerte acustice si vizuale
RS 485, RS 232
Integrat in aplicatia SCADA de monitorizare a DC
Certificari CE
DIN EN 61340-5-1
Umidificator:
Capacitate 4 kg / h
Sensor de nivel Da
Panou de control cu Da
microprocessor Tip display cu LED
Alarma 1 – 9 bar
Presiunea apei

7.2.3.5 Sistem supresie foc

Sistem supresie foc pentru Data Centre.

Tip sistem antiincendiu Stingere automata, cu gaz inert, sirena de exterior si

mecanism optic de exterior pentru avertizare incendiu.

Management local si remote Integrat in aplicatia SCADA de monitorizare a DC

7.3 Infrastructura de retea

In aceasta secțiune sunt descrise specificațiile tehnice necesare echipamentelor de

rețea si de securitate incluse in cadrul sistemului. Sistemul va fi prevăzut pentru o
capacitate înaltă de procesare și cu nivel înalt de redundanță. Infrastructura de rețea
va fi geografic distribuită în două centre ce calcul, care vor asigura continuitate
serviciilor pentru majoritatea situațiilor excepționale. Fiecare componentă descrisă
mai jos va fi dublată pentru fiecare Centru de Calcul.

Se vor analiza soluțiile propuse care vor demonstra compatibilitate maximă între
sistemele ofertate. De aceea se recomanda ca sistemele de tip switching, routing si
IP-PBX să fie de la același producător.

7.3.1 Sistemul Core Data Center Switch

Echipamentul va avea caracteristicile unui switch convergent, de tip „Unified
Fabric”, capabil sa asigure simultan următoarele funcționalități:

 Switch Ethernet Layer 2;

 Switch Ethernet Layer 3;
 Switch Fiber Channel over Ethernet (FCoE), cu operare single-hop si multi-
hop;
 Switch Fiber Channel;
  Suport de VXLAN in mod bridging si de rutare pe toate interfețele.
 Șasiu modular, care sa poată fi extins cu minim 10 module externe;
 Porturi suportate in interiorul sasiului – minim 48 SFP+, de tip:
o 1/10 GBASE-X;
o 10 Gigabit Fiber Channel over Ethernet (FCoE);
o 8 sau 16 Gbps Fiber Channel;
 minim 4 interfețe 40 Gbit Ethernet tip QSFP+.
 Echipamentul trebuie să furnizeze comutare de pachete L2/L3 la viteză de
canal - pentru toate porturile, activate în orice funcțional
 Acces virtualizat

Performanțe

 Capacitate de switch-ing L2/L3: minim 1.4Tbps;

 Capacitate de forward-are pachete: minim 1000Mpps;
 Latență: 2 microsecunde;

Cerințe funcționale software

 Caracteristici Layer 2:
o Bridge management cu STP (IEEE 802.1d), RSTP (IEEE 802.1w),
PVRST, PVST, bridge assurance, BPDU guard, BPDU filter;
o IGMPv2/v3 snooping, MLDv1/v2 snooping;
o Virtual Router Redundancy (VRRP - Active-active first hop redundancy
protocol);
o VLANs, VLAN trunks (IEEE 802.1q), LACP (IEEE 802.3ad), LACP
bypass, LLDP, CDP;
o VLAN-uri minim 4000;
o Multiple Spanning Tree Protocol (MSTP) minim 64 instanțe;
o Protocoale layer 2: toate protocoalele inclusiv IPv4 si IPv6;
 Caracteristici Layer 3:
o OSPFv2, OSPFv3, BGPv4/v6, RIP, RIPv6;
o Virtual Routing and Forwarding (VRF);
o Equal-Cost Multi-Path (ECMP) și ECMP Resilient Hashing pentru trafic
IPv4 și IPv6;
o Bidirectional Forwarding Detection (BFD) pe toate platformele și
tipurile de interfață, IPv4 șiIPv6, BGP și OSPF, VXLAN;
o protocoale layer 3: IPv4 și IPv6;
o mărime tabela host-uri IPv4: minim 28000;
o mărime tabela host-uri IPv6: minim 8000;
o mărime tabela multicast Ipv4: minim 8000;
 Caracteristici FC si FCoE
o Conformitate cu standardele T11 si FCoE Initialization Protocol (FC-
BB-5);
o Orice port 10 Gigabit Ethernet sa poată funcționa in mod FCoE;
 o Tipuri de porturi Fibre Channel: E, F, NP, VE, TE si VF;
o F-port trunking si F-port channeling;
o Fibre Channel Forwarding (FCF);
o Conectarea directa la un storage;
o N-Port Virtualization (NPV) si N-port Identifier Virtualization (NPIV);

Management:

 SSH, SCP, FTPS;

 suport scripting;
 management VRF;
 suport pentru VXLAN;
 integrare L2 Gateway cu VMware NSX;
 DHCP IPv4/v6;
 Autentificare prin LDAP;
 suport NTP;
 Management - 1 port de management/consola RJ-45 RS-232

Surse de alimentare

 Surse de alimentare și ventilatoare redundante și hot-swappable cu ventilație

din față spre spate sau din spate spre în față;

Module

 Slot SFP+ 48 porturi - echipate cu 16 module SFP+ 10GbE SR cu lungimea

de undă 850nm suportând o lungime de minim 300m de FO
 Slot QSFP+ 4 porturi - echipate cu 2 module QSFP+ 40GbE

7.3.2 Extensie Core Data Center Switch

Sistem modular distribuit care să reprezinte un modul de extindere pentru Data
Center Fabric Switch și să creeze un mediu de acces scalabil la servere, oferind
coerență între servere de tip blade si infrastructura de rețea.

Un singur punct de gestionare și aplicare a politicii din DataCenter Fabric Switch.

Interfețe

 16 x 1/10GBASE-x interfețe pentru servere

 8 x 10 Gigabit Ethernet SFP+, uplink-uri cu DataCenter Fabric Switch

Performanță

 Hardware forwarding - 400 Gbps sau 290 mpps

 Fabric speed - 160-Gbps full duplex

Caracteristici Layer 2

 Layer 2 VLAN trunks

 IEEE 802.1Q VLAN encapsulation
 Jumbo frames – pînă 9216 octeți
  Pause frames (priority flow control [PFC] and IEEE 802.3x)
 Private VLANs
 Local multicast replication

Management

 Data Center fabric switch management, in-band management

 UID and health LEDs
 Syslog
 Simple Network Management Protocol Versions 1, 2, and 3 (SNMP v1, v2, and
v3)
 Enhanced SNMP MIB support
 XML (NETCONF) support
 Remotemonitoring (RMON)
 Power-on self-test (POST)

7.3.3 Layer 3 aggregation switch

Switch de agregare cu capacitați Layer 2 și Layer 3

 48 porturi RJ45 de 1Gb

 2 porturi 10GbE SFP+ uplink echipate cu module SR cu lungimea de undă
850nm suportând o lungime de minim 300m de FO

Performanțe

 minim 170 Gbps în mod full-duplex

 Putere procesare: minim 130 Mpps;
 Adrese MAC: minim 32000;
 Rute IPv4: minim 24000 (IPv4);
 VLAN Layer 2: minim 4000;
 Jumbo frame: 9198 octeti
 mărime tabela host-uri IPv4 : minim 35000;
 mărime tabela host-uri IPv6 : minim 5000;
 mărime tabela multicast Ipv4 : minim 5000;

Timpul mediu între defecțiuni

 MTBF (Mean time between failures) de peste 300.000 de ore

Protocoale: DTP, LACP, UDLD, VTP, DHCP, NTP, IGMP (v1, v2 si v3), MLD, RMON,
802.1X, RADIUS CoA (RFC 5176), RADIUS, SSH, STP, MSTP, RSTP, OSPF, ISIS,
BGP, PIM

Stacare

 Tehnologie de stacking de pana la 400 Gbps. Minim 6 echipamente trebuie

suportate in stiva.
 Organizarea si configurarea funcției stack trebuie să se facă automat la
conectarea cablului-Stack, fără intervenția administratorului;
 Sa fie asamblat cu modulul de stack si cablu de lungime nu mai putin de 0.5m.
Functionalitati de acces unificat

 posibilitatea de a termina tunele CAPWAP si capabilitatea de a controla

access point-uri

Management

 1 x Ethernet pentru management de tip out-of-band

 1 x Consola de tip USB
 1 x Interfata externa de stocare de tip USB
 Administrabil (nu doar cu management web) din linie comanda (CLI) prin
telnet, SSH
 Update/upgrade software gratuit de pe site-ul producatorului

Surse de alimentare și ventilatoare redundante și modulare.

7.3.4 Layer 2 access switch

Switch Layer 2 pentru acces utilizatori

 48 Ethernet ports 10/100/1000 Мbps cu suport PoE+ (IEEE 802.3at) 24 port

х 30W, PoE (IEEE 802.3af) – 48 porturi x 15,4W;
 Sa fie asamblate cu 2 porturi SFP+ Ethernet 10Gbps, pentru uplink cu
comutatoarele de agregare;

Performanțe

 minim 200 Gbps comutare pachete

 Putere procesare: minim 130 Mpps;
 Adrese MAC: minim 16000;
 Rute IPv4: minim 2000;
 VLAN Layer 2: minim 4000;
 Jumbo frame: 9216 octeti
 mărime tabela multicast Ipv4 : minim 5000;

Securitate

 Posibilitatea de a izola porturi intre ele care sa comunice numai pe legaturi

presetate (up-link)
 802.1X– autentificare multipla 802.1x pe un port, concurenta pentru 802.1x,
Web si MAC , Autorizare flexibila, CoA prin Radius (Change of Authorization)
 Autentificare bazata pe MAC
 Port Security, Dynamic ARP Inspection
 STP BPDU port protection
 STP Root Guard
 Protetcie ARP Dinamica
 Protectie impotriva atacurilor de tip DoS prin DHCP
 Limitare trafic broadcast per port
 TACACS+
 RADIUS
 Ipv6 First hop security
  Reverse Path Forwarding pentru pachete unicast
 Access list-uri pentru Ipv4 si Ipv6
 Posibilitatea agregare mai multe porturi fizice intr-un singur port logic.
 Storm control per port pentru unicast, broadbast si muticast.
 Port monitor remote – posibilitatea de a monitoriza remote un port din switch
 Traceroute layer 2
 Unidirectional Link Detection Protocol

Caracteristici Layer3

 Rutare statica
 RIPv2 si RIPng
 OSPF
 Policy based routing
 VRRP
 Suport pentru multicast : PIM cu suport pentu sparse mode, dense mode si
SSM, IGMP, MVR (Multicast VLAN Registration)

QoS

 Flexibilitatea in utilizarea cozilor prin specificare numarului de cozi si a

memoriei asociate acestora
 Opt cozi de egress
 Suport pentru Shaped Round robin sau Weighted Tail Drop sau alte
mecanisme similare de evitare a congestiei
 Rate limiting in functie de : IP sursa/destinatie, MAC sursa/destinatie, port
TCP/UDP

Stacare

 Tehnologie de stacking de pana la 400 Gbps. Minim 6 echipamente să fie

suportate in stiva.
 Organizarea si configurarea funcției stack trebuie să se facă automat la
conectarea cablului-Stack, fără intervenția administratorului;
 Sa fie asamblat cu modulul de stack si cablu de lungime nu mai putin de 0.5m.

Timpul mediu între defecțiuni

 MTBF (Mean time between failures) de peste 230.000 de ore

Management

 1 x Ethernet pentru management de tip out-of-band

 1 x Consola de tip USB
 1 x Interfață externa de stocare de tip USB
 Complet administrabil (nu doar cu management web) din linie comanda (CLI)
prin telnet, SSH
 Simple Network Management Protocol Versions 1, 2, and 3 (SNMP v1, v2, and
v3)
 Update/upgrade software gratuit de pe site-ul producătorului
Surse de alimentare și ventilatoare redundante și modulare.

7.3.5 Sistemul Internet routing și Voice gateway

Echipament de tip router cu funcționalități avansate de rutare, destinat pentru
Internet acces si Voice Gateway

Interfețe

 Număr de inerfețe Ethernet RJ-45/SFP 10/100/1000Mbps : cel putin 4

 Modul instalat E1 PRI (Trunk Voice T1/E1 Module): 2

Arhitectură și Performanță

 IPv4 Forwarding 2000 Mbps

 Criptare IPSec 1600 Mbps
 Echipamentul va avea o arhitectură multiprocesor și o arhitectură hardware
modulară
 Echipamentul va oferi posibilitatea schimbarea unui modul defect cu unul
funcțional fără a afecta operațiunile sistemului
 Echipamentul va avea o arhitectură internă ce va oferi posibilitatea
comunicării de viteză mare de la un modul la altul, fără a compromite
capacitatea de rutare a echipamentului
 Echipamentul va oferi posibilitatea management out-of-band folosind un port
Ethernet
 Echipamentul va oferi posibilitatea managementului out-of-band folosind un
port USB, tip Consolă sau AUX
 Echipamentul va oferi o singură imagine software universală cu toate
funcționalitățile incluse, acestea putând fi activate prin intermediul de licențe
software
 Porturile USB onboard vor oferi posibilitatea de atașare a unui sistem de
stocare de date extern
 Porturile USB onboard vor oferi posibilitatea stocării pe memorie flash a
fișierelor de configurare

Securitate

 Securitate generală:
o Echipamentul va oferi posibilitatea configurării listelor de acces(ACL)
bazate pe adresă sursă și destinație IP, sursă și destinație MAC sau
porturi UDP/TCP
o Echipamentul va oferi posibilitatea configurării listelor de acces(ACL)
bazate pe intervale de timp
o Echipamentul va oferi posibilitatea inspecției la nivel de aplicație(DPI)
pentru 1000 de protocoale de nivel aplicație
o Echipamentul va avea implementat 802.1x
o Echipamentul va oferi posibilitatea protejării procesorului de rutare de
la atacuri malițioase, acestea incluzând atacurile de tip Denial of
Service
  Firewall:
o Echipamentul va oferi posibilitatea de provizionare securizată
o Echipamentul va oferi implementarea unui firewall de tip stateful
o Echiapementul va oferi posibilitatea implementării unui firewall bazat
pe zone de securitate
o Echipamentul va oferi funcționalitatea unui firewall de tip VRF-aware
o Firewallul echipamentului va oferi toate funcționalitățile sale atât pentru
Ipv4 cât și pentru Ipv6

Funcționalități de rutare

Sistemul de operare al echipamentului va include suport pentru următoarele

protocoale:

 IPv6 (Internet Protocol Version 6)

 IPv4/IPv6 Dual Stack
 Bidirectional Forward Detection (BFD)
 MPLS VPN
 MPLS
 Rute statice
 Open Shortest Path First (OSPF)
 Border Gateway Protocol (BGP)
 BGP Router Reflector
 Intermediate System-to-Intermediate System (IS-IS)
 The Router should suppport IS-IS BFD TLV
 The Router should suppport IS-IS Client for BFD C-Bit Support
 The Router should suppport IS-IS IPv6 Client for BFD
 Policy-Based Routing (PBR) for Traffic Management
 Classless InterDomain Routing (CIDR) IP Default Gateway
 Multicast Internet Group Management Protocol (IGMPv2)
 Multicast Internet Group Management Protocol (IGMPv3)
 IGMP Fast Leave
 IGMP MIB Support Enhancements for SNMP
 IGMP Snooping
 IGMP State Limit
 IGMP Static Group Range Support
 IGMP Version 3 - Explicit Tracking of Hosts, Groups, and Channels
 Protocol Independent Multicast sparse mode (PIM SM),
 Protocol Independent Multicast Source Specific Multicast (SSM)
 Distance Vector Multicast Routing Protocol (DVMRP)
 IP Multicast Load Splitting - Equal Cost Multipath (ECMP) using S, G and
Next-hop
 IP Multicast Load Splitting across Equal-Cost Paths
 IPv4-to-IPv6 Multicast
 Multicast BGP (MBGP)
 Multicast BGP (MBGP) for IPv6
  Multicast Performance Improvement
 Multicast NAT
 Multicast Routing Monitor (MRM)
 Multicast Service Reflection
 Multicast Source Discovery Protocol (MSDP)
 Multicast Subsecond Convergence
 Multicast User Authentication & Profile support
 Multicast VPN Extranet Support
 Multicast VPN Extranet VRF Select
 Multicast VPN Inter-AS Support
 Multicast VPN MIB
 Multicast-VPN: Multicast Support for MPLS VPN
 Multiclass Multilink PPP
 Unicast Reverse Path Forwarding (uRPF)

Tipuri de Encapsulare

 Ethernet
 Generic routing encapsulation (GRE)
 802.1q VLAN
 Point-to-Point Protocol (PPP)
 Multilink Point-to-Point Protocol (MLPPP)
 Frame Relay, Multilink Frame Relay (MLFR) (FR.15 and FR.16)
 High-Level Data Link Control (HDLC)
 Serial (RS-232, RS-449, X.21, V.35, and EIA-530)
 PPP over Ethernet (PPPoE)

Algoritmi de criptare

 Criptare: DES, 3DES, AES-128 та AES-256 (în regim CBC tа GCM).

 Autentificare: RSA (748/1024/2048 біт), ECDSA (256/384 біт).
 Hash: MD5, SHA, SHA-256, SHA-384, SHA-512.
 Suport Next Generation Encryption (NGE).

Suport Caracteristici Voce

 Posibilitate de a gestiona traficul de voce, inclusiv conversia traficului

analog-digital.
 Suport integrat a centralei telefonice cu toate licentele instalate.
 Suport conectare trunchiuri SIP (SBC)
 Suportul funcționalității autonome pentru telefonie, în cazul pierderii legăturii
cu centrala IP-PBX principală.
 Sa fie instalate toate modulele necesare pentru procesarea vocei a cel putin
64 canale de voce concomitente

Codecuri și capacități voce

 G.711, Fax and modem pass-through, G.722, G.726, G.728, G.729, G.729a,
G.729b, G.729ab
  Echo cancellation, Tone detection, Noise reduction, Acoustic shock
prevention, Gain control

7.3.6 Sistemul WAN routing

Echipament de tip router cu funcționalități avansate de rutare, destinat pentru WAN
acces, care va asigura legătura securizată, tip VPN, între cele două Centre de Calcul
și alte oficii teritoriale.

Interfețe

 Număr de inerfețe Ethernet RJ-45/SFP 10/100/1000Mbps : cel putin 4

Arhitectură și Performanță

 IPv4 Forwarding 2000 Mbps

 Criptare IPSec 1600 Mbps
 Echipamentul va avea o arhitectură multiprocesor și o arhitectură hardware
modulară
 Echipamentul va oferi posibilitatea schimbarea unui modul defect cu unul
funcțional fără a afecta operațiunile sistemului
 Echipamentul va avea o arhitectură internă ce va oferi posibilitatea
comunicării de viteză mare de la un modul la altul, fără a compromite
capacitatea de rutare a echipamentului
 Echipamentul va oferi posibilitatea management out-of-band folosind un port
Ethernet
 Echipamentul va oferi posibilitatea managementului out-of-band folosind un
port USB, tip Consolă sau AUX
 Echipamentul va oferi o singură imagine software universală cu toate
funcționalitățile incluse, acestea putând fi activate prin intermediul de licențe
software
 Porturile USB onboard vor oferi posibilitatea de atașare a unui sistem de
stocare de date extern
 Porturile USB onboard vor oferi posibilitatea stocării pe memorie flash a
fișierelor de configurare

Securitate

 Securitate generală:
o Echipamentul va oferi posibilitatea configurării listelor de acces(ACL)
bazate pe adresă sursă și destinație IP, sursă și destinație MAC sau
porturi UDP/TCP
o Echipamentul va oferi posibilitatea configurării listelor de acces(ACL)
bazate pe intervale de timp
o Echipamentul va oferi posibilitatea inspecției la nivel de aplicație(DPI)
pentru 1000 de protocoale de nivel aplicație
o Echipamentul va avea implementat 802.1x
 o Echipamentul va oferi posibilitatea protejării procesorului de rutare de
la atacuri malițioase, acestea incluzând atacurile de tip Denial of
Service
 Firewall:
o Echipamentul va oferi posibilitatea de provizionare securizată
o Echipamentul va oferi implementarea unui firewall de tip stateful
o Echiapementul va oferi posibilitatea implementării unui firewall bazat
pe zone de securitate
o Echipamentul va oferi funcționalitatea unui firewall de tip VRF-aware
o Firewallul echipamentului va oferi toate funcționalitățile sale atât pentru
Ipv4 cât și pentru Ipv6

Funcționalități de rutare

Sistemul de operare al echipamentului va include suport pentru următoarele

protocoale:

 IPv6 (Internet Protocol Version 6)

 IPv4/IPv6 Dual Stack
 Bidirectional Forward Detection (BFD)
 MPLS VPN
 MPLS
 Rute statice
 Open Shortest Path First (OSPF)
 Border Gateway Protocol (BGP)
 BGP Router Reflector
 Intermediate System-to-Intermediate System (IS-IS)
 The Router should suppport IS-IS BFD TLV
 The Router should suppport IS-IS Client for BFD C-Bit Support
 The Router should suppport IS-IS IPv6 Client for BFD
 Policy-Based Routing (PBR) for Traffic Management
 Classless InterDomain Routing (CIDR) IP Default Gateway
 Multicast Internet Group Management Protocol (IGMPv2)
 Multicast Internet Group Management Protocol (IGMPv3)
 IGMP Fast Leave
 IGMP MIB Support Enhancements for SNMP
 IGMP Snooping
 IGMP State Limit
 IGMP Static Group Range Support
 IGMP Version 3 - Explicit Tracking of Hosts, Groups, and Channels
 Protocol Independent Multicast sparse mode (PIM SM),
 Protocol Independent Multicast Source Specific Multicast (SSM)
 Distance Vector Multicast Routing Protocol (DVMRP)
 IP Multicast Load Splitting - Equal Cost Multipath (ECMP) using S, G and
Next-hop
 IP Multicast Load Splitting across Equal-Cost Paths
  IPv4-to-IPv6 Multicast
 Multicast BGP (MBGP)
 Multicast BGP (MBGP) for IPv6
 Multicast Performance Improvement
 Multicast NAT
 Multicast Routing Monitor (MRM)
 Multicast Service Reflection
 Multicast Source Discovery Protocol (MSDP)
 Multicast Subsecond Convergence
 Multicast User Authentication & Profile support
 Multicast VPN Extranet Support
 Multicast VPN Extranet VRF Select
 Multicast VPN Inter-AS Support
 Multicast VPN MIB
 Multicast-VPN: Multicast Support for MPLS VPN
 Multiclass Multilink PPP
 Unicast Reverse Path Forwarding (uRPF)

Tipuri de Encapsulare

 Ethernet
 Generic routing encapsulation (GRE)
 802.1q VLAN
 Point-to-Point Protocol (PPP)
 Multilink Point-to-Point Protocol (MLPPP)
 Frame Relay, Multilink Frame Relay (MLFR) (FR.15 and FR.16)
 High-Level Data Link Control (HDLC)
 Serial (RS-232, RS-449, X.21, V.35, and EIA-530)
 PPP over Ethernet (PPPoE)

Algoritmi de criptare

 Criptare: DES, 3DES, AES-128 та AES-256 (în regim CBC tа GCM).

 Autentificare: RSA (748/1024/2048 біт), ECDSA (256/384 біт).
 Hash: MD5, SHA, SHA-256, SHA-384, SHA-512.
 Suport Next Generation Encryption (NGE).

7.3.7 Sistemul de securitate

Sistemul de securitate vor include echipamente de tip firewall ce trebuie sa includă
capabilități de inspectare a pachetelor, filtrare a traficului si controlul aplicațiilor in
vederea asigurării unei securități sporite in cadrul sistemului integrat

Interfețe

 Minim 7 porturi 10/100/1000GE si minim 2 porturi 10GE cu interfete optice

SFP+
 Minim 1 port de consola
Caracteristici Generale

 echipament de securitate cu functionalitati simultane de firewall, firewall la

nivel de aplicatie de tip stateful, pentru IPv4 si IPv6;
 functii pentru detectia si prevenirea intruziunilor IDS/IPS operationale pe
procesoare dedicate integrate;
 protectie antivirus si antimalware web, protectie prin mecanisme de verificare
a reputatiei site-urilor accesate;
 functii de criptare prin IPSec VPN si SSL VPN cu sau fara necesitatea
clientului VPN, pentru IPv4 si pentru IPv6;
 functii de QoS ce includ traffic shaping, traffic policing si coada prioritara;
 functii pentru detectia si prevenirea intruziunilor IDS/IPS operationale pe
procesoare dedicate integrate, pentru IPv4 si IPv6;
 functii de translatare NAT de la IPv4 la IPv6 si reciproc, NAT64, NAT46;
 Rutare: static, policy-based routing, OSPF v2 si v3, BGP (cu suport ipv6)
 Echipamentul trebuie sa ofere protectie integrata impotriva amenintarilor, de-
a lungul intregului ciclu de atac - inainte, in timpul si dupa.
 Serviciile de IPS si ANTI-MALWARE trebuie sa ofere o vizibilitate sporita in
retea, nu doar asupra amenintarilor si aplicatiilor, ci si utilizatori, sisteme de
operare, terminale.
 IPSul trebuie sa ofere automatizări de securitate prin indicații de compromis
pentru prioritizarea amenintarilor in functie de impactul pe care il pot aduce in
retea, precum si recomandari automate de politici de securitate in functie de
elementele prezente in retea.
 Hosturile care au fost infectate trebuie identificate cu un "tag" pentru a sugera
compromiterea acestora.
 Serviciul de IPS trebuie sa folosească standarde open (ex: Snort, OpenAppID,
open APIs).
 Serviciul de IPS trebuie sa ofere preprocesare, pentru a normaliza traficul la
nivel de aplicație si a detecta eventualele anomalii.
 Serviciul de IPS trebuie sa folosească semnături actualizate automat sau
manual.
 Daca functionalitatile de IPS si ANTI-MALWARE sunt conditionate de
existenta unei licente sau a unei subscriptii, acestea trebuiesc incluse pe o
durata minima de 5 ani.
 Serviciile de IPS si ANTI-MALWARE trebuie sa ofere corelarea
evenimentelor si vizualizarea acestor informatii pe un sistem de management
centralizat.
 Serviciul de ANTI-MALWARE trebuie sa foloseasca o analiza continua a
traficului si fisierelor din retea, inclusiv retrospectiva.
 Serviciul de ANTI-MALWARE trebuie sa ofere protectie malware zero-day
precum si traiectoria fisierului infectat cu malware prin retea, terminalele
infectate
 Serviciul de ANTI-MALWARE trebuie sa ofere analiza fisierelor din retea
pentru a detecta si bloca malware-ul.
  Serviciul de ANTI-MALWARE trebuie sa ofere functia de amprentare bazata
pe algoritm SHA256 pentru pastrarea confidentialitatii fisierelor supuse
analizei de risc si compromitere;
 Serviciul de ANTI-MALWARE trebuie sa se bazeze pe o verificare in Cloud a
reputatiei fisierului pentru a beneficia de big data analytics si analiza continua,
precum si pentru a identifica cele mai noi malware.
 Serviciul de ANTI-MALWARE trebuie sa ofere analiza retrospectiva pentru a
realiza traiectoria in retea si vizibilitate asupra originii precum si imprastierii
in retea.
 Echipamentul impreuna cu serviciile activate vor fi controlate, configurate si
monitorizate dintr-o platforma de management centralizat, ce ofera rapoarte
si logging, descrisa in sectiunea « Solutie de management, monitorizare,
corelare de evenimente si preventie a intruziunilor de securitate informatica »
 Echipamentul se va integra si cu Solutie centralizata de management a
politicilor de acces in infrastructura de retea pentru a primi in mod automat
regulile de catalogare pentru restrictionarea a traficului.

Caracteristici tehnice

 Trafic IPSec VPN (AES256 si SHA-384 sau AES256 si SHA-512) : minim

1Gbps
 Trafic IPS pentru trafic multiprotocol ( trafic ce include minim HTTP, SMTP,
FTP, IMAPv4) : minim 1,8Gbps;
 Filtrare trafic web antivirus si antimalware : minim 500Mbps;
 Număr de tunele IPSec VPN : minim 5000;
 Număr de tunele SSL VPN concurente : minim 100 incluse cu posibilitatea de
scalabilatate la 5000;
 Număr de clienti VPN concurenți: minim 5000;
 Număr de VLAN-uri procesabile : minim 1000;
 Performanta procesare pachete: minim 1,3Mpps;
 Funcție de instanțe virtuale configurabile : minim 5 disponibile cu posibilitatea
de scalabilitate la 100;

Disponibilitate si fiabilitate

 Posibilitate de funcționare in mod High availability de tip active/passive,

active/active, link failover;
 Posibilitate de funcționare in mod cluster in care minim 3 sau mai multe
echipamente pot funcționa active/active cu balansarea dinamica a sesiunilor in
modul cluster;
 Balansare trafic pentru minim 8 servere;

Management

 Administrare prin Web UI (http/https), telnet, SSH, CLI

 Utilizatori cu drepturi configurabile
 Integrare prin Radius, TACACS+ si LDAP
 Suport pentru autentificarea grupurilor de utilizatori prin LDAP
Surse de alimentare

 Două surse de alimentare AC 220V redundante;

7.3.8 Sistemul Telefonie IP-PBX

Sistemul telefonie IP-PBX va avea funcția unei centrale telefonice IP, care va
asigura redundanța serviciilor pentru sistemul informațional principal de preluare a
apelurilor 112. Această centrală va fi un nivel adițional de backup pentru apelurile de
urgență, care vor fi preluate în cazul unor defecțiuni la nivelul central de preluare a
apelurilor. De asemenea această centrală telefonică va fi utilizată pentru uz intern al
colaboratorilor din cadrul centrului.

Cerințe tehnice generale

 Sistemul trebuie sa fie in măsura sa integreze si sa facă posibile comunicațiile

de voce dintre gateway-urile de voce peste IP, telefoanele IP, dispozitivele de
procesare multimedia (MCU) si aplicațiile multimedia precum: centrul de
contact, mesageria unificata (voice-mail), conferințele multimedia si sistemele
IVR;
 Administrarea tuturor componentelor de telefonie (Noduri centrala telefonica
IP, Gateway de Voce, Telefoane IP) se va realiza in mod centralizat, dintr-o
interfața unica de administrare (cea a Centralei telefonice IP cu funcție de
“master”).
 Toate componentele sistemului trebuie sa provina de la acelasi producator,
complet integrabile si sa nu fie declarate ca EoS (End of Sale) sau EoL (End of
Life). De asemenea, nu sunt acceptate echipamente catalogate de producator
ca fiind refolosite (“refurbished”).
 Serverele de procesare a apelurilor vor fi instalate intr-un Data Center
consolidat prin mecanisme de virtualizare
 Arhitectura centralei IP va fi complet distribuita, şi va oferi posibilitatea
realizarii redundantei geografice active prin duplicarea părților vitale ale
sistemului.
 Centrala telefonica IP trebuie sa poata fi imbunatatit - upgrade prin investitii
minime, in vederea mentinerii facilitatilor la cel mai inalt nivel de performanta

Utilizatori

 Sistemul va fi livrat cu resurse hardware suficiente pentru 400 de utilizatori

si licente software pentru 100 de utilizatori.
 Utilizatorii vor fi livrati cu aplicatie de tip softphone de la acelasi producator
cu centrala telefonica
 Furnizorul va livra servicii de support software care sa permita upgrade-ul
utilizatorilor existenti la ultima versiune de soft pe o durata de 3 ani.

Tratarea apelurilor telefonice

 Rutare alternativa automata a apelurilor (AAR);

 Suport pentru rutarea imediata a apelurilor spre voice mail;
  Mecanisme pentru permisiunea si controlul apelurilor (CAC) intra si inter
cluster;
 Mecanisme pentru înregistrarea apelurilor;
 Suport pentru videotelefonie (H.323, SIP);
 Restricționare apeluri in funcție de ora din zi, zi din saptamana, si zi din an;
 Silent monitoring
 Suport pentru coduri de autorizare a apelurilor;
 Suport pentru butoane/linii programabile pe telefoanele IP;
 Suport pentru grupuri de hunt;
 Suport pentru partitionarea planului de numerotare (drepturi de apelare);
 Suport pentru rutare cu cost redus (facilitatea sistemului de a selecta automat
rutele cu cost minim pentru iesirea in telefonia publica);
 Suport pentru Caller ID pentru apeluri sosite pe porturi FXO controlate prin
intermediul protocolului MGCP;

Codecuri suportate
 Audio: G.711, G.722, G.722.1, G.723.1, G.728, G.729A / B, GSM-EFR, GSM-
FR, wideband audio, AAC, iLBC, iSAC;
 Video: H.261, H.263, H.264, H.235, H.239 si Wideband Video Codec;

Protocoale suportate
 MGCP, H.323, SRST, SIP;
 Q.SIG, ISDN;
 FAX over IP (Pass-Through si Fax Relay);
 Suport FAX T.38 (H.323, MGCP, si SIP);
 DTMF over IP;

Securitatea
 Suport pentru conferințe securizate pentru toti membrii unei conferinte;
 Posibilitate selectie intre modurile Nonsecure si Secure;
 Suport pentru autentificarea la nivel de dispozitive prin intermediul
certificatelor digitale (X.509v3);
 Suport pentru eToken –uri X.509v3 pe USB;
 Centrala telefonica poate facilita criptarea in standard AES, cu lungimea
minima a cheii criptografice de 128 biti, pentru trunchiurile şi terminalele IP.

Scalabilitate
 Arhitectura redundanta scalabila pana la 4 noduri per cluster cu posibilitatea
balansării încărcării si asigurării redundantei procesării apelurilor;
 pana la 1000 echipamente H323 (gateway, trunk, clienti), MGCP si trunk-uri
SIP inregistrate;
 pana la 400 locatii remote;

Mobilitate
  Suport pentru mobilitatea utilizatorilor asigurata prin încărcarea profilului
propriu (numar de telefon, drepturi de apelare, linii de apelare directa) după
introducerea credentialelor (Nume utilizator si PIN) pe telefonul curent;
 Suport pentru aplicații de colaborare care se instalează pe device-urile mobile
ale utilizatorilor(iPhone, iPad, Telefoane sau Tablete Android), se conectează
la Centrala Telefonica IP prin intermediul unor conexiuni securizate si permit
colaborarea audio/video a utilizatorilor;

Facilitati la nivel utilizator

 Indicator auditiv si visual pentru “mesaj in asteptare”;
 Suport pentru autoanswer si intercom;
 Intercom cu posibilitate de “whisper”;
 Suport pentru call park si call pick-up;
 Suport pentru Direct Inward Dial (DID) si Direct Outward Dial (DOD);
 Acces de pe telefon la servicii web;
 Suport pentru indicare stare apel per linie (stare, durata si numar);
 Apelare directa din telefon pe baza agendei telefonice personala sau la nivel
de organizatie;
 Configurare facilitati apelare rapida (“speed dial”) si “call forward” prin
intermediul interfetei WEB a abonatului;
 CallBack Automat;
 Apelare Abreviata;
 Facilitate Do Not Disturb;
 Facilitate BargeIN;
 Posibilitatea realizarii de apeluri cu prioritate atat spre extensiile interne cat
si pe fluxuri E1;
 Apelare cu receptorul in furca;
 Music on Hold;
 Privacy;
 Posibilitatea apelării dintr-o interfata WEB;
 Posibilitatea apelarii din butoane configurabile pe terminale fixe
 Posibilitatea apelarii unui numar telefonic din orice aplicatie office prin
integrarea CTI cu telefonul IP;
 VPN client direct pe telefonul IP;
 Integrarea centralei telefonice IP cu sistemul LDAP al beneficiarului;
posibilitatea de a filtra utilizatorii LDAP pe centrala telefonica;

7.3.9 Terminale Voce

Terminalele să fie complet compatibile cu soluția de IP-PBX ofertată

Protocoale Voce - SIP 2.0;

Codecuri voce

 G.711a-law
 G.711μ-law
 G.722
  G.729a

Interfata de retea: Ethernet switch cu două interfețe 10/100BASE-T (connector RJ

45)
Funcționalități incluse

 NAT transverse: „STUN mode”;

 Client DHCP;
 „in-band DTMF” si „out-of band RFC2833 DTMF”;
 „proxy mode” si „peer-to-peer SIP link mode”;
 “Call forward”, „3-way Conference”, „Call Hold”, „Caller ID Display” și „Call
Waiting”;
 Display LCD, dimensiuni minime 3.2”;
 20 de butoane fizice programabile
 Ajustarea volum difuzor,sunet de apel, agendă telefonică, „Speed Dial”,
„Flash” și „Speaker Phone”;

Administrare prin Web si direct din interfatra de management a PBX-ului

Security

 Certificate
 Autentificarea imaginilor
 Autentificarea dispozitivelor
 Autentificarea fișierelor
 Autentificarea semnalizării
 Criptarea semnalizării utilizând protocoalele de criptare TLS cu AES-128 si
AES-256
 Fișiere de configurare criptate
 Suport pentru autentificare 802.1X
 Criptografie

QoS

 Suport pentru standardul 802.1Q/p.

Alimentare electrica IEEE PoE class 1, suport IEEE 802.3af PoE;

7.3.10 Sistemul de balansare

Sistemul de balansare are rolul de a asigura echilibra incarcara pe aplicatii si sisteme
in vederea oferirii unei performante optime si un timp de raspuns imbunatatit al
sistemului.

Echipament echilibrare incarcare a centrului de date:

 Arhitectura software instalabila pe servere comerciale cu posibilitatea de

scalare automata in functie de nevoile de procesare
 Arhitectura distribuita prin care se spara nivelul de control de cel de
procesare
 Scalabilitatea solutiei trebuie sa se poata realiza cel putin folosind urmarele
tehnici de scalare:
o Scalare verticala prin care se adauga automat noi balansoare
individuale in functie de nevoile de procesare a trafiului
o Scalare orizontala prin care creste numarul de balansoare dintr-un
grup
o Scalare pe orizontala bazata pe protocol BGP
 Sistemul trebuie sa suporte, cel putin, urmatorii algoritmii de balansare
suportati:
o Hashing consistent – prin care distributia incarcarii se face printr-un
algoritm de hashing
o Cel mai rapid raspuns – prin care noile sesiuni se distribuie catre
balansorul care raspunde cel mai repede la o cerere de conectare
o Cele mai putine servere – prin care se minimizeaza numarul de
balansoare din configuratie in functie de nevoia totala de trafic ce
trebuie procesat la un moment dat. Cererile de conectare vor fi
distribuite in acest fel catre un numar minimal de balansoare dispuse pe
serverele din infrastructura
o Cele mai putine conexiuni – prin care noile cereri de conectare se
directioneaza catre balansoarele care au cel mai putin numar de
conexiuni active
o Cel mai putin incarcat - prin care noile cereri de conectare se
directioneaza catre balansoarele care au cele mai multe resurse de
procesare disponibile
o Round robin – Noile conexiuni se directioneaza secvential catre
balansoarele dintr-un grup
 Arhitectura de inalta disponibilitate atat la nivelul unitatii de control cat si al
unitatii de procesare
 Cerinte minime pentru instalarea unei unitati de control:
o Memorie – 24GB
o Nuclee procesor – 8
o Spatiu pe disc – 60GB
 Cerinte minime pentru instalarea unei unitati de procesare relativ la un nucleu
procesor:
o Capacitate de procesare trafic – 4Gbps
o Numar de conexiuni active – 64K
o Capacitate procesare conexiuni SSL – 1Gbps
o Numarul de conexiuni SSL TPS (RSA) - 500
o Numarul de conexiuni SSL TPS (ECC) – 2000
 Principalii parametrii hardware – memoria si nucleele de procesare trebuie sa
scaleze liniar
 Solutia de balansare trebuie sa se poata instala atat in mediu fizic cat si in
mediu virtual
  Solutia de balansare trebuie sa poata lucra cu solutia de virtualizare ofertata
si sa aibe suport pentru lucrul cu cele mai cunoscute solutii de cloud
o VMWare
o OpenStack
 Solutia de balansare trebuie sa dispuna de un modul de analiza a traficului
 Trebuie sa dispuna de un modul care sa permita indentificarea eventualelor
erori de configurare a serviciilor oferite de centrul de date
 Sistemul de management al echipamentelor trebuie sa fie centralizat, sub
forma de appliance hw sau virtual, cu urmatoarele capabilitati minime:
 posibilitatea configurarii de profile si privilegii utilizator pentru diverse roluri:
administrator, operator, auditor/viewer, etc.;
 posibilitatea configurarii de rapoarte, alerte, informatii afisate functie de
profilul utilizator definit;
 sa ofere capabilitati de integrare/transmitere de alerte catre alte sisteme
interne tip SIEM (security information and event management), prin
prezentarea unor modalitati de conectare documentate;

7.3.11 Sistem de comunicații backup

Realizare legătură Ethernet, fără fir/wireless, intre cele doua locații ale centrelor de
112 din Chișinău.

Cerințe Generale

 Soluție punct la punct,

 Redundanta inclusa (1+1 sau 2+0 – Radio link aggregation).
 Proiectare dedicate pentru aplicații de tipul
o 24/7
o disaster recovery
o network redundancy
 Soluție completa funcțională, compusa din
o Echipament de exterior, cu partea radio si protecție climatica avansata
o Carcasa cu protecție mediu IP66/67, praf- apa
o Modul radio, set antena, sistem de prindere pe pilon, alimentare PoE
o Accesorii de prindere, pozare, etc, inclusiv cabluri de legătura la rețea
LAN din centrul de 112.
o Aplicație management
o Servicii de proiectare, realizare proiect radio, obținere autorizație de
funcționare.
o setare, punere in funcție, teste

NOTA: funcție de condițiile de teren, proiect radio si echipament oferit, se vor

asigura toate construcțiile si accesoriile necesare asigurării unei transmisii continue,
de calitate, cu viteza de minim 100Mbps, adaptate condițiilor climaterice specifice
Republicii Moldova, care sa asigure un uptime al acestei legături de cel puțin
99,999% anual.
Cerințe conectare Ethernet, punct la punct

 Protocol IEEE 802.3

 Transfer date Variabil dinamic pana la 100 Mbps
 Întârziere pe o direcție max 10 ms
 Suport VLAN
 Suport VLAN tagging (802.1Q)
 Suport prioritare de pachete (biții PCP sau DSCP)
 Auto negociere 10/100/1000 Mbps

Management

 Management la distanta
 Sa permită monitorizare performantei radio (erori, putere Rx)

Atestare, conformitate cu standardele industriale telecom pentru asigurare

interoperabilitate, securitate si siguranța in funcționare.

hy

klmml;m
 8. Cerinte privind oferta tehnica
Se va raspunde punct cu punct tuturor cerintelor caietului de sarcini, cu detalierea
serviciilor, tehnologiilor si produselor ofertate. Ofertantul va realiza un documnet
numit „Descirere solutiei tehnice” in care, va prezneta in confomitate cu metodologia
de Enterprise Architecture – TOGAF, modalitatea de indeplinire a cerintei tehnice.
Pentru cerintele strict tehnice se vor face trimiteri la documentatia producatorului,
care sa dovedeasca indeplinirea cerintelor, indicand sectiunea in care acesta atesta
indeplinirea cerintei sau evidentierea ecranului care atesta existenta functionalitatii.

Pentru toate echipamentele hardware ofertate se va detalia configuratia ofertata

specificand toate componentele si licentele incluse in oferta.

Se va prezenta lista tuturor licentelor oferite cu numele oficiale ale producatorilor

detaliind instalarea pentru fiecare partitie pe server si modul de licentiere ofertat
(inclusiv cantitati in functie de modul de licentiere propus) pentru fiecare licenta in
parte.

Propunera ofertantului va include si urmatoarele:

Prezentarea contextului, obiectivelor şi a rezultatelor aşteptate ale proiectului:

În această secţiune, ofertanții vor prezenta, pe baza informaţiilor menţionate în

caietul de sarcini din documentaţia de atribuire şi a cunoştinţelor proprii,
următoarele:

 contextul proiectului aşa cum este înţeles de ofertant, din care să rezulte că
atât informaţiile generale relevante cât şi situaţia actuală a sectorului de
activitate sunt cunoscute şi înţelese de ofertant, precum şi descrierea
potenţialelor riscuri care pot afecta buna desfăşurare a proiectului, împreună
cu măsurile de reducere/eliminare a acestora;

 obiectivele şi rezultatele aşteptate ale proiectului, aşa cum sunt acestea

înţelese de către ofertant şi din care să rezulte aspectele considerate ca fiind
esenţiale pentru realizarea obiectului contractului.

Lipsa acestora din oferta sau prezentarea unor descrieri nerelevante sau care nu
demonstreaza intelegerea contextului si obiectivelor proiectului va duce la
descalificarea ofertantului. Nerespectarea cerintelor din caietul de sarcini sau
absenta in cadrul continutului ofertei a specificatiilor si serviciilor ofertate pentru
fiecare din cerintele din caietul de sarcini va atrage incadrarea ofertei ca fiind
neconforma.

Nu se admit raspunsuri de tip reformularea cerintei. Existenta unei astfel de abordari

va conduce la incadrarea ofertei ca fiind neconforma.
 9. Considerente generale
Specificatiile tehnice definite in cadrul prezentului caiet de sarcini corespund
necesitatilor si exigentelor autoritatii contractante. Toate specificatiile, serviciile si
cerintele mentionate si solicitate in cadrul acestui caiet de sarcini sunt insotite de
mentiunea „sau echivalent”. Toate echiapmentele livrate vor fi noi si nefolosite,
autoritatea avand dreptul de a refuza orice produs care este refabricat, uzat sau
prezinta defecte vizibile sau defecte de fabricatie. In acest sens, la constatarea
oricarui defect mentionat mai sus de catre autoritate, Furnizorul este obligat sa
inlocuiasca produsul in termen de 10 zile de la instiintare.

Totodata, ofertantul va include in cadrul documentatiei inaintata Autoritatii

Contractante, documente de autorizare de livrare pentru toate produsele software si
hardware incluse in propunerea tehnica.
 10. Capabilitatile solutiei ofertate
In aceasta sectiune se evidentiaza specificatiile necesare a fi testate in timpul
prezentarii, in vedera atestarii capabilitatilor “out of the box” ale solutiei ofertate:

SIA 112 trebuie să asigure implementarea următoarelor funcţionalităţi de bază:

o autentificarea, autorizarea si atribuirea de roluri utilizatorilor, dupa criterii

organizationale si legate de competenţe
o simularea preluarii apelurilor de urgenţă;
o preluarea si tratarea altor tipuri de alertări de urgenta, prin SMS, Fax,
eCall, Alarme ş.a.
o obtinerea informatiilor despre apelant, in urma unei interogari efectuate,
pornind de la identificarea apelantului, si completarea campurilor din foaia
de eveniment cu aceste informatii, fara sa fie necesara interventia
Operatorului
o inregistrarea integrala a convorbirilor vocale si a secventei de actiuni
intreprinse de Operatorul 112 si de Dispecerii SSU
o inregistrarea integrala a convorbirilor de voce
o posibilitatea de a reface secventa de actiuni a operatorului pentru un
incident anterior
o simularea localizarii apelului de pe terminale mobile de tip smartphone si
prezentarea informatiei de localizare printr-o interfata de tip harta
o asistarea Operatorului 112 pentru obtinerea eficienta de informatii prin
conversatia cu apelantul
o Managementul incidentelor
o agendă telefonică specifică organizatiei din care face parte operatorul cu
actorii relevanti in tratarea situatiilor de urgenta si sa ofere capacitatea
de apelare
o agenda telefonică specifică operatorului individual
o realizarea de conferinte de voce cu, si transferul apelurilor catre,
Dispecerii SSU, alti Operatori 112 sau colaboratori externi
o transmiterea informatiilor documentate din foaia de eveniment catre
sisteme informatice externe, prin intermediul unei componente de
integrare
o furnizarea de rapoarte pe baza datelor istorice şi realizarea de analize
statistice
o Rularea aplicatei specifice de Operator în modul Instruire
o Suport pentru mai multe multi-organizație simultan pentru diferite
organizații, fiecare cu proprii operatori și dispeceri, resurse și protocoale
operaționale spefice
o Transferul incidentelor inspre si dinspre diferite organizatii
o prezentarea istoricului pentru apelurile recepționate de la același număr
telefonic
o Instrument de clasificare a incidentului
 o Propunerea automată de protocol operational
o Distribuția apelurile de intrare
o Inregistrarea apelurilor
o Reascultarea apelurilor de voce
o Blocarea anumitor numere de telefon de catre operator
o Interfata unica de comunicatii (Cozi de apeluri, apeluri, conferinta, agenda
telefonica, liste de contacte) specifica operatorului

Pentru sistemul GIS se vor evidentia urmatoarele:

o Posibilitate de a deschide un caz nou direct din fereastra de hartă

o Administrarea și reprezentarea poziției unui incident
o Funcții de căutare avansată geografică
o Administrarea poziției unor sisteme de alarmă, senzori și camere video
direct de pe hartă
o Vizualizarea resursei(lor) propuse de către sistem pentru a adresa un
anumit caz, afișând rutele propuse și timpii de a ajunge la locația
incidentului
o Administrarea și poziționarea resurselor
o Posibilitatea de a asigna resurse la un incident din fereastra de hartă