82303890 Final Caiet de Sarcini v7

Caiet de sarcini

“SISTEM DE MANAGEMENT AL SITUATIILOR DE URGENTA LA NIVELUL

MUNICIPIULUI BUCURESTI”

1. Introducere ........................................................................................................................ 10

1.1 Concepte generale ..................................................................................................... 10

1.2 Obiectivele urmarite .................................................................................................. 11

1.3 Prezentarea situatiei actuale: ..................................................................................... 15

1.3.1 Situatia actuala din punct de vedere organizatoric si organizational ............................................ 15 1.3.2 Situatia actuala din punct de vedere informational si informatic ................................................... 16

1.4 Conceptia privind reproiectarea SMSUMB: ............................................................. 24

1.4.1 Conceptia generala ......................................................................................................................... 24 1.4.2 Conceptia privind realizarea si implementarea SMSUMB ............................................................. 25 1.4.3 Conceptia de integrare a tuturor sistemelor implicate in situaţiile de urgenţă existente in CMISU

(Centrul municipal integrat pentru situaţii de urgenţă) ............................................................................... 27 1.4.4 Reproiectarea componentei ,,Înştiinţare” ...................................................................................... 28 1.4.5 Reproiectarea componentei „Avertizare” ...................................................................................... 31 1.4.6 Arhitectura de sistem a SMSUMB .................................................................................................. 33

1.4.6.1 Subsistemul Centrul Operaţional al Municipiului Bucuresti .................................................................. 34 1.4.6.2 Subsistemul de colectarea a datelor ....................................................................................................... 34 1.4.6.3 Subsistemul de alarmare/avertizare ........................................................................................................ 35 1.4.6.4 Subsistemul de produse informatice ...................................................................................................... 35 1.4.6.5 Subsistemul de comunicaţii.................................................................................................................... 36

1.5 Contextul legal .......................................................................................................... 37

1.6 Structura organizatorica ............................................................................................ 37

1.6.1 Inspectoratul pentru Situaţii de Urgenţă „Dealul Spirii” al Municipiului Bucureşti .................... 37 1.6.2 Puncte de prezenţă operativă.......................................................................................................... 39 1.6.3 Direcţia Generală de Poliţie a Municipiului Bucureşti .................................................................. 40 1.6.4 Direcţia de Jandarmi a Municipiului Bucureşti ............................................................................. 41 1.6.5 Serviciul de Ambulanţă al Municipiului Bucureşti ......................................................................... 41

1.7 Structuri si cadrul organizatoric – activitati in Situatii de Urgenta grave si dezastre

43

1.8 Componente ale reproiectarii manageriale ................................................................ 44

2 Premise si riscuri .............................................................................................................. 45

3 Cerinte administrare proiect ............................................................................................. 47

3.1 Cerinte generale......................................................................................................... 47

3.1.1 Responsabilitate .............................................................................................................................. 47 3.1.2 Locatie proiect ................................................................................................................................ 47 3.1.3 Limba oficiala ................................................................................................................................. 47 3.1.4 Drept de proprietate ....................................................................................................................... 47 3.1.5 Inspectii .......................................................................................................................................... 48

3.2 Activitati conexe proiectului ..................................................................................... 48

3.2.1 Intalnire initiala .............................................................................................................................. 48 3.2.2 Intalniri periodice de monitorizare ................................................................................................. 49

3.3 Analiza si Managementul Riscurilor ......................................................................... 49

3.4 Arhiva centrala a Proiectului ..................................................................................... 49

3.5 Control asupra configurarii ....................................................................................... 49

3.6 Managementul calitatii .............................................................................................. 50

3.7 Planul de securitate industriala .................................................................................. 50

3.8 Managementul logistic .............................................................................................. 51

3.9 Management de proiect ............................................................................................. 51

3.10 Mentenanta ................................................................................................................ 52

3.11 Furnizare.................................................................................................................... 52

3.12 Locatii suport............................................................................................................. 53

3.13 Personal si training .................................................................................................... 53

3.14 Piese inutile ............................................................................................................... 53

3.15 Referinte de control al proiectului ............................................................................. 53

3.16 Lista de documente ce vor fi livrate Contractorului .................................................. 54

3.17 Planul de continuitate a activitatii ............................................................................. 56

4 Cerinţe de construcţii şi instalatii ..................................................................................... 56

4.1 Cerinţe generale......................................................................................................... 56

4.2 Centrul Municipal Integrat pentru Situatii de Urgenta.............................................. 58

4.2.1 Generalitati ..................................................................................................................................... 58 4.2.2 Cerinţele de proiectare ................................................................................................................... 58 4.2.3 Cerinţele de executie ....................................................................................................................... 58 4.2.4 Cerinţe privind amenajarile interioare ........................................................................................... 58 4.2.5 Cerinte privind securitatea la incendiu .......................................................................................... 59 4.2.6 Alimentare cu energie electrica ...................................................................................................... 59

4.2.6.1 Sursa ne-intreruptibila (UPS) ................................................................................................................. 59 4.2.6.2 Generatorul de curent ............................................................................................................................. 59

5 Arhitectura sistemului....................................................................................................... 60

5.1 Sistemul de comunicatii ............................................................................................ 60

5.1.1 Reteaua locala de date (LAN) ......................................................................................................... 60 5.1.2 Reteaua locala de comunicatii voce................................................................................................ 61 5.1.3 Comunicatiile BEMIS (COM-BEMIS) ............................................................................................ 61

5.1.3.1 Performante si caracteristici ................................................................................................................... 61 5.1.3.2 Sub-Sistemul de control al comunicatiilor integrate (ICOM-BEMIS ) .................................................. 62 5.1.3.3 Comunicatii prin satelit .......................................................................................................................... 63 5.1.3.4 Comunicatii la nivel dispecer ................................................................................................................. 63 5.1.3.5 Staţia pentru apeluri de urgenţă .............................................................................................................. 64

5.1.4 Cerinţe speciale pentru sistemul de comunicaţii ............................................................................ 64 5.1.4.1 Functii speciale ...................................................................................................................................... 64 5.1.4.2 Canale radio prioritare ........................................................................................................................... 65 5.1.4.3 Suport pentru conectarea la faxul de urgenţă şi interogarea ................................................................... 65 5.1.4.4 Managementul sistemului central de comunicatii .................................................................................. 65 5.1.4.5 Conexiuni fizice ..................................................................................................................................... 66 5.1.4.6 Interfeţe proprii ale sistemului de comunicatii ....................................................................................... 66 5.1.4.7 Interconectarea TETRA ......................................................................................................................... 66 5.1.4.8 Comenzi consola integrate operator ....................................................................................................... 67 5.1.4.9 Alte cerinte ............................................................................................................................................. 67 5.1.4.10 Functii si sisteme de suport comunicatii ................................................................................................ 68 5.1.4.11 Modul de apelare urgenţă (server de comunicaţii) ................................................................................. 68

5.2 Sistemul si infrastructura IT ...................................................................................... 69

5.2.1 Infrastructura de servere ................................................................................................................ 69

5.2.2 Aria de stocare a datelor ................................................................................................................ 69 5.2.3 Posturi de lucru .............................................................................................................................. 70 5.2.4 Back-up si recuperare ..................................................................................................................... 71 5.2.5 Specificatii functionale si operationale ale serviciilor ................................................................... 73

5.2.5.1 Servicii de baza ...................................................................................................................................... 73 5.2.5.2 Baza de date operationala ...................................................................................................................... 73 5.2.5.3 Securitatea informatica .......................................................................................................................... 77 5.2.5.4 Gestiunea documentelor ......................................................................................................................... 78 5.2.5.5 Server GIS.............................................................................................................................................. 83 5.2.5.6 Sistem GIS pentru stații de lucru............................................................................................................ 88 5.2.5.7 Modul de monitorizare a sistemului ....................................................................................................... 92 5.2.5.8 Suita de aplicatii de productivitate și colaborare .................................................................................... 93 5.2.5.9 Solutie antivirus ..................................................................................................................................... 95

5.2.5.9.1 Caracteristici generale minimale si eliminatorii: ............................................................................... 96 5.2.5.9.2 Privind serviciile si echipa de suport tehnic: ..................................................................................... 96 5.2.5.9.3 Cerinte minime pentru produsele antivirus: ...................................................................................... 97

5.2.5.9.3.1 Antivirus pentru statii de lucru (mobile sau fixe) cu management centralizat ........................... 97 5.2.5.9.3.2 Caracteristici si functionalitati principale ale modulului antivirus si antispyware : ................... 97 5.2.5.9.3.3 Firewall: ..................................................................................................................................... 98 5.2.5.9.3.4 Antispam: ................................................................................................................................... 99 5.2.5.9.3.5 Carantina: ................................................................................................................................... 99 5.2.5.9.3.6 Administrare si instalare remote: ............................................................................................... 99 5.2.5.9.3.7 Rapoarte si grafice: .................................................................................................................. 100 5.2.5.9.3.8 Backup ..................................................................................................................................... 100 5.2.5.9.3.9 Actualizare: .............................................................................................................................. 100 5.2.5.9.3.10 Antivirus pentru servere de fisiere pe platforma Windows : .................................................. 101 5.2.5.9.3.11 Antivirus pentru servere de fisiere Linux/Unix (Samba File Server) ..................................... 101 5.2.5.9.3.12 Antivirus, antispyware pentru servere e-mail ......................................................................... 102

5.2.5.10 Sisteme de operare ............................................................................................................................... 103 5.2.5.11 Soluţia CRM ........................................................................................................................................ 103

5.2.5.11.1 Cerinte generale ............................................................................................................................. 103 5.2.5.11.2 Gestiunea informaţiilor despre solicitanţi/cetăţeni ......................................................................... 104 5.2.5.11.3 Gestiunea interacţiei cu solicitanţii/cetăţenii .................................................................................. 106 5.2.5.11.4 Canalul telefonie - CTI (Computer Telephony Integration) ........................................................... 106 5.2.5.11.5 Canalul E-mail şi mesagerie .......................................................................................................... 107 5.2.5.11.6 Canalul Fax .................................................................................................................................... 107 5.2.5.11.7 Canalul Web .................................................................................................................................. 108 5.2.5.11.8 Canalul Direct şi Corespondenţa .................................................................................................... 108 5.2.5.11.9 Gestiunea solicitărilor, cererilor, reclamaţiilor ............................................................................... 108 5.2.5.11.10 Înregistrarea solicitărilor .............................................................................................................. 109 5.2.5.11.11 Gestiunea resurselor ..................................................................................................................... 109 5.2.5.11.12 Fluxuri de lucru ............................................................................................................................ 109 5.2.5.11.13 Criterii de alocare ......................................................................................................................... 109 5.2.5.11.14 Baza de cunoştinţe şi proceduri.................................................................................................... 109 5.2.5.11.15 Gestiunea relaţiei cu unităţile, instituţiile şi agenţiile deservite ................................................... 110 5.2.5.11.16 Gestiunea campaniilor de informare şi a sondajelor .................................................................... 110 5.2.5.11.17 Necesităţi şi capabilităţi de integrare ........................................................................................... 110 5.2.5.11.18 Asigurarea calităţii informaţiei .................................................................................................... 111 5.2.5.11.19 Capabilităţi de lucru cu documente scanate ................................................................................. 111

5.2.5.12 Server Web .......................................................................................................................................... 112 5.2.5.13 Server Portal ........................................................................................................................................ 113 5.2.5.14 Server Aplicatie ................................................................................................................................... 115 5.2.5.15 Server integrare .................................................................................................................................... 117

5.2.5.15.1 Componenta Aplicatii SOA ........................................................................................................... 117 5.2.5.15.2 Componenta monitorizare aplicatii SOA ....................................................................................... 119 5.2.5.15.3 Componenta magistrala de mesaje ................................................................................................. 119 5.2.5.15.4 Componenta gateway si securitate aplicatii SOA .......................................................................... 120 5.2.5.15.5 Componenta procesare evenimente ................................................................................................ 121

5.2.5.16 Control acces si gestiune utilizatori ..................................................................................................... 122 5.2.5.16.1 Controlul accesului ........................................................................................................................ 123 5.2.5.16.2 Gestiunea utilizatorilor................................................................................................................... 125 5.2.5.16.3 Stocarea utilizatorilor ..................................................................................................................... 126

5.2.5.17 Server mesagerie electronica ................................................................................................................ 126 5.2.5.18 Configuratia minimala de procesare(mediul de productie) .................................................................. 128 5.2.5.19 Configuratia minimala de procesare(mediul de testare/dezvoltare/instruire) ....................................... 128

5.2.6 Sub-Sistemul operativ mobil ......................................................................................................... 129

5.2.7 Sub-Sistem Monitorizare si Management ..................................................................................... 129 5.2.8 Sistemul de afisare de mari dimensiuni (perete-ecran) ................................................................ 130

5.2.8.1 Generalitati........................................................................................................................................... 130 5.2.8.2 Ecranul principal din Sala Operativa ................................................................................................... 130 5.2.8.3 Alte ecrane ........................................................................................................................................... 131 5.2.8.4 Servere de control video ...................................................................................................................... 131 5.2.8.5 Reteaua video ....................................................................................................................................... 132 5.2.8.6 Aplicatia de management ecranelor si a imaginilor ............................................................................. 132

5.2.9 Sistemul de videoconferinta .......................................................................................................... 132 5.2.10 Sistemul integrat de securitate fizica ........................................................................................ 132

5.2.10.1 Sistemul de alarmă ............................................................................................................................... 132 5.2.10.2 Soluţia de control a accesului ............................................................................................................... 133 5.2.10.3 Supraveghere video .............................................................................................................................. 134

5.2.11 Interfeţe de sistem ..................................................................................................................... 135 5.2.11.1 Cerinţe generale ale interfeţelor ........................................................................................................... 135 5.2.11.2 Cerinţe de bază pentru interfeţele de sistem ......................................................................................... 135 5.2.11.3 Monitorizarea interfeţelor .................................................................................................................... 136 5.2.11.4 Interfaţa pentru serverul de alarmă telefonică / server alarmare telefonică .......................................... 136 5.2.11.5 Interfaţa pentru sistemul de detectare a incendiilor .............................................................................. 137 5.2.11.6 Interfaţa cu sistemul de management trafic (cu integrare video) .......................................................... 137 5.2.11.7 Interfaţa cu pozitiile externe................................................................................................................. 138 5.2.11.8 Interfeţe digitale sistem radio / TETRA ............................................................................................... 138 5.2.11.9 Interfaţa utilizatorului .......................................................................................................................... 138 5.2.11.10 Interfaţă la servere externe .............................................................................................................. 138 5.2.11.11 Interfeţe radio GSM ........................................................................................................................ 139 5.2.11.12 Interfeţe date radio SMS ................................................................................................................. 139 5.2.11.13 Interfeţe FAX .................................................................................................................................. 139 5.2.11.14 Interfaţă e-mail ................................................................................................................................ 140

5.2.12 Sub-Sistemul baza de timp ........................................................................................................ 140 5.2.13 Sistemul de alarmare – avertizare pentru populatie ................................................................ 140

6 Cerinte functionale ......................................................................................................... 141

6.1 Înregistrarea semnalizării ........................................................................................ 142

6.2 Înregistrarea locaţiei / Verificarea locaţiei .............................................................. 144

6.3 Căutare fonetică....................................................................................................... 145

6.4 Serviciul de intervenţie............................................................................................ 145

6.5 Cuvânt-cheie de intervenţie ..................................................................................... 146

6.5.1 Modificarea cuvintelor-cheie legate de obiectiv, zonă, stradă ..................................................... 146 6.5.2 Modificarea cuvântului-cheie de intervenţie ................................................................................ 147

6.6 Tabloul sinoptic al cuvintelor-cheie de intervenţie ................................................. 147

6.6.1 Intervenţii învecinate .................................................................................................................... 148 6.7 Mesaj multiplu in cazul unui incident ..................................................................... 148

6.8 Aparitia stringenta a mesajelor ................................................................................ 149

6.9 Imaginea de ansamblu a aplicatiei .......................................................................... 149

6.9.1 Predarea si expedierea mesajelor si aplicatiilor .......................................................................... 149 6.9.2 Campul de text .............................................................................................................................. 150 6.9.3 Memorare ..................................................................................................................................... 150 6.9.4 Numarul de aplicatie .................................................................................................................... 150 6.9.5 Mesaje informative ....................................................................................................................... 151 6.9.6 Atribuirea imaginii de mesaj conform serviciilor ......................................................................... 151

6.10 Dispozita de interventie (ordinul de executie a operatiunii) ................................... 151

6.10.1 Prezentarea dispozitiei ............................................................................................................. 151 6.10.2 Parametrii dispozitiei ............................................................................................................... 152 6.10.3 Transmisia vocala .................................................................................................................... 153

6.11 Managementul resurselor ........................................................................................ 153

6.11.1 Completari la resurse ............................................................................................................... 154 6.11.2 Cautarea de resurse ................................................................................................................. 154 6.11.3 Tactica de management a resurselor ........................................................................................ 154

6.12 Activitatile dispecerului .......................................................................................... 154

6.13 Fişiere de informaţii ................................................................................................ 155

6.14 Finalizarea planificării............................................................................................. 155

6.15 Sprijinirea si dirijarea intervenţiilor ........................................................................ 155

6.15.1 Redarea intervenţiei ................................................................................................................. 157 6.15.2 Vedere de ansamblu asupra intervenţiilor ............................................................................... 157 6.15.3 Încheierea intervenţiei .............................................................................................................. 157 6.15.4 Încheiere ................................................................................................................................... 157

6.16 Procese complementare şi module de program aferente BEMIS ............................ 158

6.16.1 Prelucrare paralelă a intervenţiilor/măsurilor ........................................................................ 158 6.16.2 Planificarea anterioară intervenţiei ......................................................................................... 159 6.16.3 Caracteristici pentru serviciul de salvare ................................................................................ 159 6.16.4 Planificarea anterioară a transporturilor pentru bolnavi cu privire de ansamblu grafică ...... 160 6.16.5 Planificarea anticipată a mijloacelor de intervenţie ................................................................ 161

6.17 Transporturi multiple / Transporturi colective ........................................................ 161

6.17.1 Continuarea transportului ........................................................................................................ 161 6.18 Situaţii speciale ....................................................................................................... 162

6.19 Baza de date despre personal .................................................................................. 164

6.20 Înregistrarea ulterioară a intervenţiei ...................................................................... 164

6.21 Jurnal de activitate BEMIS ..................................................................................... 165

6.22 Protocolul de intervenţie al computerului central de intervenţie ............................ 165

6.23 Aplicaţii / aplicaţii de sistem suporturi/ gestionarea datelor ................................... 165

6.24 Comanda de alarmare şi decuplare.......................................................................... 167

6.25 Cataloage de măsuri ................................................................................................ 167

6.25.1 Catalog de măsuri centrat pe intervenţie ................................................................................. 167 6.25.2 Indici de performanţă rezumativi ai catalogului de măsuri ..................................................... 168

6.26 Date de informare .................................................................................................... 168

6.27 Prezentarea generală a mijloacelor de intervenţie ................................................... 169

6.28 Disponibilitatea mijloacelor de intervenţie ............................................................. 170

6.29 Administrarea lipsei mijloacelor de intervenţie ...................................................... 170

6.30 Returnarea mijlocului de intervenţie ....................................................................... 171

6.31 Tabloul mijloacelor de intervenţie / Prezentare generală a statusului ..................... 171

6.32 Formate de prezentare ale tabloului mijloacelor de intervenţie .............................. 172

6.33 Sistem grafic ............................................................................................................ 173

6.33.1 Planuri de fundal in GIS........................................................................................................... 173 6.34 Managementul substanţelor periculoase ................................................................. 179

6.35 Afişarea punctelor de blocaj /PUNCT DE plecare/planificarea rutei ..................... 179

6.36 Puncte de blocaJ, PUNCT DE plecare .................................................................... 179

6.37 Planificarea rutei ..................................................................................................... 180

6.38 Sistem de simulare, testare şi training ..................................................................... 180

6.38.1 Training .................................................................................................................................... 181 6.38.2 Testare/simulare ....................................................................................................................... 181

6.39 Sistemul de informaţii al centrelor de intervenţie ................................................... 181

6.40 Managementul senzorilor ........................................................................................ 182

6.40.1 Revizia senzorilor ..................................................................................................................... 182 6.40.2 Informaţii grafice despre senzori ............................................................................................. 183 6.40.3 Protocolul de transfer .............................................................................................................. 183 6.40.4 Protocolul despre senzor din computerul central pentru intervenţii ........................................ 183

6.41 Căutarea intervenţiilor ............................................................................................. 184

6.42 Statistica BEMIS ..................................................................................................... 184

6.43 Cerinţe de operare ................................................................................................... 185

6.44 Parametri statistică .................................................................................................. 185

6.45 Raportare statistica .................................................................................................. 188

6.46 Managementul calităţii ............................................................................................ 188

6.46.1 Cerinţe generale ....................................................................................................................... 188 6.46.2 Cerinţe şi date pentru un sistem de management calitate ........................................................ 188

6.47 Imagine de ansamblu – informaţii, canale de comunicaţie ..................................... 190

6.48 Metoda de transmitere alarme pentru notificări de incendiu ................................... 190

6.48.1 Apel telefonic/ Apel verbal ....................................................................................................... 191 6.48.2 Apel RSS / Apel SDS ................................................................................................................. 191 6.48.3 Sistem de asistenta la alarme multiple ..................................................................................... 192

6.49 Informaţii privind locaţia de prestare a serviciului ................................................. 192

6.49.1 Informaţii privind notificări şi operaţiuni - notificări BEMIS .................................................. 192 6.50 Cerinţe suprafeţe de pe ecran .................................................................................. 193

6.50.1 Ecran de prelucrare ................................................................................................................. 193 6.50.2 Ecran de informaţii şi imagine de ansamblu ............................................................................ 196 6.50.3 Ecran grafic .............................................................................................................................. 196

6.51 Funcţie de ajutor ...................................................................................................... 197

6.52 Documentare/JURNALIZARE OPERATII SISTEM ............................................. 197

6.52.1 Documentaţia în colaborare cu instalaţiile de documentare audio ......................................... 198 6.53 Asigurarea intervenţiilor în curs - Tipărire în fişier ................................................ 199

6.54 Computerul / serverul de coordonare a intervenţiilor ............................................. 200

6.55 Cerinţe cu privire la PERFORMANTA .................................................................. 200

6.55.1 Comportament de pornire după repunerea în funcţiune .......................................................... 200 6.55.2 Randamentul sistemului............................................................................................................ 201

6.56 Capacitatea centrului de comanda ........................................................................... 201

6.57 Cerinţe specifice BEMIS:........................................................................................ 201

6.58 Bazele de date.......................................................................................................... 202

6.58.1 Structura bazei de date ............................................................................................................. 202 6.58.2 Informări - baza de date ........................................................................................................... 202 6.58.3 Baze de date în CMISU ............................................................................................................ 203 6.58.4 Colectarea datelor .................................................................................................................... 203 6.58.5 Preluare din sursele de date ..................................................................................................... 204 6.58.6 Instrumente pentru preluarea şi gestionarea datelor ............................................................... 204 6.58.7 Preluarea datelor ..................................................................................................................... 204 6.58.8 Interconectarea cu alte sisteme externe ................................................................................... 205

6.59 Structura datelor principale esenţiale ...................................................................... 206

6.60 Tipuri de fişiere de informaţii ................................................................................. 209

6.61 Asistarea exportului de informatii ........................................................................... 210

6.62 Volumul bazei de date ............................................................................................. 210

6.63 Asistarea sistemului................................................................................................. 211

6.64 Administrarea datelor .............................................................................................. 211

6.65 Date grafice ............................................................................................................. 211

6.66 Planificarea BEMIS................................................................................................. 212

6.67 Management, MESAJE de eroare şi de operare ...................................................... 212

6.68 Arhivarea datelor ..................................................................................................... 213

6.69 Back-up ................................................................................................................... 213

6.70 Sistemul de management al crizelor........................................................................ 214

6.70.1 Componente generale ............................................................................................................... 215 6.70.2 Integrarea cu BEMIS si alte sisteme in CMISU ....................................................................... 215 6.70.3 Baza de date pentru riscuri si urgente ...................................................................................... 215 6.70.4 Planurile de actiune ................................................................................................................. 215 6.70.5 Catalogul resurselor unificate .................................................................................................. 216 6.70.6 Echipa de colaborare ............................................................................................................... 216 6.70.7 Harta tactica ............................................................................................................................ 216 6.70.8 Managementul documentelor si continutului ........................................................................... 217

6.71 Confidentialitate si autenticitate .............................................................................. 218

6.72 Integrarea camerelor de supraveghere a traficului .................................................. 218

7 Asigurarea calitatii .......................................................................................................... 218

7.1 Metodologia de asigurare a calitatii ........................................................................ 218

7.2 Sistemul de management al calităţii ........................................................................ 219

8 Testare si acceptanta ....................................................................................................... 221

8.1 Generalitati .............................................................................................................. 221

8.2 Teste de acceptanta la fabricant (FAT) ................................................................... 222

8.3 Teste de acceptanta instalare in teren (SAT) ........................................................... 222

8.4 Test de acceptanta finala ......................................................................................... 222

8.5 Rezultate si documentare ........................................................................................ 222

9 Pregatirea personalului ................................................................................................... 223

9.1 Planul de training .................................................................................................... 223

9.2 Pregatirea personalului managerial ......................................................................... 223

9.3 Pregatirea personalului tehnic (administratorii de sistem) ...................................... 224

9.3.1 Generalităţi ................................................................................................................................... 224 9.3.2 Conţinutul programului de training tehnic ................................................................................... 225 9.3.3 Pregatirea personalului opertiv (dispeceri) ................................................................................. 227

10 Documentatie .............................................................................................................. 227

11 Garantie, suport si mentenanta .................................................................................... 228

11.1 Garantie ................................................................................................................... 228

11.2 Servicii de intretinere .............................................................................................. 229

11.3 Servicii de support ................................................................................................... 230

11.3.1 Generalitati .............................................................................................................................. 230 11.3.2 Suport telefonic permanent (tip “Call-center “) ...................................................................... 231 11.3.3 Aplicatie software pentru gestiunea incidentelor ..................................................................... 231 11.3.4 Suport avansat .......................................................................................................................... 232 11.3.5 Calitatea serviciului ................................................................................................................. 233

10 / 234

1. Introducere

1.1 Concepte generale

Municipiul Bucureşti reprezintă o zonă care este expusă atât la riscuri naturale

(cutremure, alunecări şi prăbusiri de teren, inundaţii, fenomene meteorologice periculoase,

incendii de pădure), cat si la riscuri tehnologice (accidente chimice, accidente nucleare,

incendii în masă, accidente grave pe căi de transport), la riscuri biologice (epidemii, epizootii,

zoonoze), la riscuri teroriste si riscuri ecologice.

Astfel, activităţile pentru pregătirea, planificarea şi conducerea intervenţiilor

structurilor operative în vederea atingerii scopului propus privind protecţia şi salvarea vieţii

populaţiei, mediului înconjurător, valorilor materiale şi culturale importante, inclusiv pentru

restabilirea stării de normalitate devin esentiale. Planurile de acţiune şi intervenţie întocmite

şi aprobate, dezvoltă principalele direcţii de utilizare justă a forţelor şi efectivelor angajate în

situaţiile de urgenţă, inclusiv folosirea mijloacelor disponibile în vederea atingerii scopului

propus.

Gestionarea situaţiilor de urgenţă are în vedere studiul, organizarea şi activităţile

pentru concretizarea intervenţiilor cu maximum de eficacitate în funcţie de tipul de risc,

îndeplinind procedurile stabilite de structurile de management.

Având în vedere persistenţa, în domeniul managementului prevenirii şi gestionării

situaţiilor de urgenţă, a unui sistem instituţional parţial închegat, cu funcţionare temporară şi

care se activează abia în momentul producerii situaţiilor de urgenţă, incapabil să asigure un

răspuns adecvat noilor provocări şi implicit să permită restabilirea rapidă a stării de

normalitate, precum şi lipsa spaţiilor şi mijloacelor adecvate, se impune realizarea corecţiilor

necesare în organizarea procesuală, structurală şi informaţională, precum şi la managementul

resurselor umane specifice instituţiilor care asigura prevenirea şi gestionarea situaţiilor de

urgenţă.

Aplicaţia SMSUMB are in vedere realizarea, la nivelul municipalitatii, a unui sistem

integrat si unitar de management al Situaţiilor de Urgenţă, pentru a reduce vulnerabilitatea

sociala si economica printr-un set de masuri de prioritate, cu privire la unele riscuri majore

asociate Municipiului Bucureşti. Proiectul incurajeaza si sustine abordarea globala a

managementului situaţiilor de urgenta si promoveaza cooperarea stransa intre autoritatile

responsabile. Comitetul Municipiului Bucureşti pentru Situaţii de Urgenţă este o componentă

a Sistemului National de Management al Situaţiilor de Urgenţă. Comitetul Municipiului

Bucureşti pentru Situaţii de Urgenţă asigură îndeplinirea atribuţiilor principale prevazute la

art. 23 din Ordonanţa de Urgenţă a Guvernului nr. 21/2004 dintre care:

a) informeaza Comitetul National, prin Inspectoratul General, privind starile potential

generatoare de situatii de urgenta si iminenta amenintarii acestora;

b) evalueaza situatiile de urgenta produse pe teritoriul municipiului Bucuresti,

stabileste masuri si actiuni specifice pentru gestionarea acestora si urmareste

indeplinirea lor;

11 / 234

c) declara, cu acordul ministrului administratiei si internelor, starea de alerta pe

teritoriul municipiului Bucuresti si propune instituirea starii de urgenta;

d) analizeaza si avizeaza planul municipal pentru asigurarea resurselor umane,

materiale si financiare necesare gestionarii situatiilor de urgenta;

SMSUMB trebuie să fie un sistem integrat logic, informatic şi de comunicaţii,

interfaţat cu Sistemul National pentru Managementul Situaţiilor de Urgenţă,

interconectând toate instituţiile implicate în gestionarea situaţiilor de urgenţă,

facilitând accesul acestora la informaţii, reprezentând un suport pentru luarea

deciziilor atât în situaţiile normale de fiecare zi (rutina) cât şi în situaţiile de urgenţă

grave (dezastre), asigurând toale fazele implicate in managementul situaţiilor de

urgenţă: prevenire, pregatire, răspuns şi revenire la starea de normalitate.

Sistemul trebuie să selecteze şi să organizeze diverse tipuri de date colectate şi diseminate de

la toate instituţiile implicate în managementul situaţiilor de urgenţă, trebuie să proceseze

aceste date astfel încât să permită dezvoltarea şi implementarea unor planuri clare de acţiune

ca răspuns la aceste situaţii de urgenţă.

SMSUMB urmăreste să rezolve următoarele aspecte:

- identificarea in cel mai mic timp posibil a iminenţei producerii situaţiilor de urgenţă

şi/sau a dezastrelor, prin achiziţia şi analiza de date provenite din teritoriu în timp

real;

- reducerea vulnerabilităţilor ecologice, sociale şi economice în cazul producerii

dezastrelor;

- realizarea şi operaţionalizarea sistemului de management al situaţiilor de urgenţă la

nivelul municipiului Bucureşti prin includerea tuturor instituţilor, serviciilor publice

deconcentrate, descentralizate şi de gospodărie comunală, regiilor autonome şi

societăţilor comerciale care îndeplinesc funcţii de sprijin în gestionarea situaţiilor de

urgenţă, inclusiv ale agenţilor economici care, prin specificul activităţii, constituie

factori de risc potenţial generatori ai unor situaţii de urgenţă;

- organizarea fluxurilor informaţionale specifice prin interconectarea sistemelor

existente şi asigurarea comunicării datelor şi informaţiilor între CMISU şi CON;

- managementul eficient al situaţiilor de urgenţă;

- menţinerea viabilităţii sistemului în caz de dezastre;

- asigurarea confidenţialităţii informaţiilor în conformitate cu reglementările în

domeniul securităţii sistemelor de informaţii ale NATO, UE şi naţionale.

Centrul Municipal Integrat pentru Situaţii de Urgenţă – CMISU va cuprinde concentrarea

tuturor dispeceratelor/centrelor operative sau operationale a serviciilor descentralizate si

deconcentrate din municipiul Bucureşti inclusiv dispeceratele altor entitati suport.

1.2 Obiectivele urmarite

12 / 234

Fundamentarea si determinarea obiectivelor SMSU din municipiul Bucuresti are, ca

surse informationale principale, strategia si politica globala a Primariei Generale, Prefecturii

Bucuresti si Inspectoratului pentru Situatiile de Urgenta.

Doua sunt etapele distincte ale managementului situatiilor de urgenta: prevenirea si

gestionarea acestora. Pentru fiecare obiectivele sunt diferite, asa cum rezulta din tipologia

prezentata in continuare.

a) Prevenirea

Obiectiv fundamental: cunoasterea caracteristicilor si a formelor de manifestare a

riscurilor, realizarea in timp scurt , in mod organizat si printr-o conceptie unitara a

masurilor necesare, credibile, realiste si adecvate de protectie a populatiei in cazul

aparitiei situatiilor de urgenta, in scopul eliminarii sau limitarii pierderilor de vieti

omenesti, valorilor materiale si protectia mediului.

Obiective derivate:

- identificarea, monitorizarea si gestionarea tipurilor de riscuri generatoare de situatii de

urgenta pe teritorilul municipiului Bucuresti si judetului Ilfov

- sprijinirea si informarea organismelor cu atributii, competente si responsabilitati

privind planificarea, organizarea, pregatirea si asigurarea starii de operativitate a

capacitatii de interventie optime a componentelor SMSUMB

- implicarea specialistilor ISUMB in constituirea, de catre autoritatile administratiei

publice locale, de rezerve (de resurse) financiare si tehnico-materiale

- optimizarea actiunilor preventive a masurilor de securitate in domeniul proiectarii,

executiei, exploatarii si postutilizarii constructiilor si instalatiilor.

- Instiintarea oportuna a autoritatilor locale despre evolutia spre dezastru a factorilor de

risc natural, bilogica sau tehnologica si alarmarea populatiei in cazul producerii

acestora, precum si in situatiile de urgenta ce pot afecta grav viata, bunurile si mediul

- informarea si pregatirea preventiva a populatiei cu privire la pericolele la care este

expusa, masurile de autoprotectie ce trebuie indeplinite, mijloacele de protectie puse

la dispozitie, obligatiile ce ii revin si modul de actiune pe timpul situatiei de urgenta

- dezvoltarea unui sistem de voluntariat care sa permita prin activitati de prevenire si

interventie, cresterea gradului de securitate al fiecarei comunitati

- asigurarea cantitatilor materiale, financiare, de personal pentru indeplinirea atributiilor

ce revin ISUMB ca autoritate in devenire.

b) Gestionarea situatiilor de urgenta, concretizata in:

- Planificarea activitatilor de pregatire a interventiilor

- Organizarea interventiei serviciilor profesioniste pentru situatii de urgenta

- Desfasurarea interventiei

- Asigurarea logisticii necesare desfasurarii interventiei.

13 / 234

Obiectiv fundamental: asigurarea protectiei si salvarii vietii in situatii de urgenta

Obiective derivate:

Prevenirea, in masura in care este posibil si limitarea efectelor situatiilor de urgenta

Respectarea drepturilor si libertatilor fundamentale ale omului.

O schema a obiectivelor SMSUB si a conexiunilor dintre ele ar putea arata in felul urmator:

14 / 234

OBIECTIVE

OPTIUNI STRATEGICE

STRATEGIA

ISUMB

Obiective

economice

Obiective

sociale

Obiective

de mediu

prevenirea situatiilor de urgenta

consolidarea capacitatii institutiilor specializate si a Primariei Municipiului

Bucuresti pentru prevenirea producerii situatiilor de urgenta si gestionarea lor

crearea unui sistem integrat de raspuns la situatiile de urgenta

salvarea de vieti omenesti

cresterea calitatii vietii

diminuarea impactului factorilor distructivi

cresterea rolului autoritatilor si institutiilor publice locale

utilizarea adecvata a resurselor pentru realizarea, intretinerea si exploatarea

infrastructurilor si a masurilor de prevenire, interventie si reabilitare a zonelor

afectate

mentinerea unor activitati economice minimale si asigurarea supravietuirii

populatiei in zonele grav afectate

asigurarea bunei functionari a infrastructurii critice

asigurarea unui sistem modern de avertizare, comunicatii, date si

informatii

interventia operativa si profesionista in caz de situatii de urgenta

organizarea din timp a comunitatii locale pentru gestionarea

situatiilor de urgenta

reducerea pagubelor produse ca urmare a manifestarii situatiilor de

urgenta

asigurarea unui management adecvat de instiintare, alarmare si

evacuare a populatiei din zonele de risc

descentralizarea manageriala

optimizarea capacitatii de autoprotectie si raspuns in caz de situatii

de urgenta

15 / 234

1.3 Prezentarea situatiei actuale:

1.3.1 Situatia actuala din punct de vedere organizatoric si organizational

Starea actuala evidenţiază faptul că, la nivelul municipiului Bucureşti, functioneaza

organisme implicate în prevenirea şi gestionarea situaţiilor de urgenţă pe care le numim în

continuare operatori. Acestia se împart în:

operatori care susţin activităţile de rutină şi de urgenţă: DGPMB, ISUMB, DJMB,

SAMB, Inspectoratul de Aviaţie al MIRA, SNAU, denumiti in continuare operatori de

rutina;

operatori de sprijin: instituţii şi agenţi economici, servicii voluntare, servicii private

pentru situaţii de urgenţă, etc.

Grupul operatoriIor de sprijin se constituie la nivelul Municipiului Bucureşti de către

fiecare instituţie publică deconcentrată şi descentralizată din subordinea ministerelor

şi alte instituţii de interes local care au responsabilităţi privind managementul tipurilor

de risc generatoare de situaţii de urgenţă sau îndelinesc funcţii de sprijin în

gestionarea situaţiilor de urgenţă.

Gestionarea situaţiilor de urgenţă, specifice tipurilor de risc de pe raza municipiului

Bucureşti, se realizează în baza Planului de Analiză şi Acoperire a Riscurilor, denumit în

continuare PAAR, care cuprinde riscurile potenţiale identificate la nivelul municipiului

Bucureşti si enuntate in Schema de Riscuri Teritoriale elaborata de specialistii ISUMB,

măsurile, acţiunile şi resursele necesare pentru managementul riscurilor respective. Planul

este elaborat de Inspectoratul pentru Situaţii de Urgenţă al Municipiului Bucureşti, în baza

prevederilor Ordinului MAI nr. 132/2007 pentru aprobarea Metodologiei de elaborare a

Planului de analiză şi acoperire a riscurilor şi a Structurii-cadru a Planului de analiză şi

acoperire a riscurilor, precum şi a regulamentelor privind prevenirea şi gestionarea situaţiilor

de urgenţă, pe tipuri de risc, emise de către instituţiile care coordonează managementul

situaţiilor de urgenţă, specifice riscurilor respective. PAAR este întocmit în scopul de a

asigura cunoaşterea sarcinilor şi atribuţiilor ce le revin autorităţilor şi agentilor economici

inainte, pe timpul şi după apariţia unei situaţii de urgenţă, de a crea un cadru unitar şi coerent

de acţiune pentru prevenirea şi gestionarea riscurilor generatoare de situaţii de urgenţă şi de a

asigura un răspuns optim în caz de urgenţă, adecvat fiecărui tip de risc identificat.

Acesta urmăreşte următoarele obiective:

a) asigurarea prevenirii riscurilor generatoare de situaţii de urgenţă, prin evitarea manifestării

acestora, reducerea frecvenţei de producere ori limitarea consecinţelor lor, în baza

concluziilor rezultate în urma identificării şi evaluării tipurilor de risc, conform Schemei de

Riscuri Teritoriale;

b) amplasarea şi dimensionarea unităţilor operative şi a celorlalte forţe destinate asigurării

funcţiilor de sprijin privind prevenirea şi gestionarea situaţiilor de urgenţă;

c) stabilirea concepţiei de intervenţie în situaţii de urgenţă şi elaborarea planurilor operative;

16 / 234

d) alocarea şi optimizarea forţelor şi mijloacelor necesare prevenirii şi gestionării situaţiilor

de urgenţă.

1.3.2 Situatia actuala din punct de vedere informational si informatic

Sistemele de comunicatii date/voce la nivelul organizatiilor care apartin structurilor implicate

in sistemul de management al urgentelor, sunt integrate in sistemul de comunicatii voce/date -

RCVD ale MIRA. Aici ne referim la comunicatii date/voce punand un accent deosebit pe

latura operativa care este de un real interes in proiectul de fata.

Inspectoratul pentru Situatii de Urgenta al Municipiului Bucuresti

Inspectoratul pentru situatii de urgenta al municipiului Bucuresti este serviciul de urgenta

profesionist care, prin organul sau de specialitate – Centrul Operational - asigura conducerea

ferma, neintrerupta si directa a subunitatilor de interventie.

Sistemul de conducere este structura decizionala cu rol de a asigura continuitatea actiunilor

de interventie din a carui structura nu poate lipsi subsistemul informational.

Subsistemul informational cuprinde totalitatea informatiilor, circuitelor si fluxului

informational, precum si mijloacele de prelucrare automata a informatiilor. Toate informatiile

despre situatiile de urgenta provenite de la sursele proprii sau de la alte surse trebuie dirijate

catre punctul de comanda al unitatii. Pentru realizarea fluxului informational se folosesc atât

mijloacele din inzestrare, cât si sistemele si circuitele de telecomunicatii din sistemul

teritorial.

Pentru analiza sistemului informational, am analizat activitatile de planificare, pregatire,

organizare, dsfasurarea si conducerea actiunilor de interventie a serviciilor de urgenta

profesioniste.

Documentele care se elaboreaza in functie de destinatia lor, se clasifica in:

documente pentru pregatirea si organizarea interventiei;

documente pentru conducerea si desfasurarea interventiei;

documente pentru evidenta, analiza, evaluare si raportare.

In planificarea operatiunilor de gestionare a situatiilor de urgenta la nivel teritorial se are in

vedere ,,Schema cu riscurile teritoriale din zona de competenta”, document intocmit de catre

specialistii ISUMBMB, pe baza structurii cadru stabilita de catre IGSU si aprobata de

Prefectul Municipiului Bucuresti.

Controlul organizarii si pregatirii operatiunilor de gestionare a situatiilor de urgenta se

planifica si se executa conform dispozitiilor legale in scopul verificarii respectarii

reglementarilor specifice si evaluarii actiunilor intreprinse, precum si a capabilitatilor fortelor

de interventie in situatiile de urgenta.

17 / 234

Luarea in evidenta a obiectivelor si localitatilor din zona de competenta este obligatorie si se

executa in scopul culegerii datelor privind caracteristicile acestora.

Culegerea, centralizarea si actualizarea datelor se asigura, in principal, prin executarea de

studii, studii tactice, recunoasteri preliminare, precum si prin analiza documentatiilor tehnice

de organizare, sistematizare si amenajare a teritoriului, a celor de proiectare si de executare a

constructiilor si instalatiilor, prin studiul documentelor de evidenta ale directiei municipiului

Bucuresti de statistica si registrului comertului, a altor documente ce pot asigura informatiile

necesare elaborarii conceptiei de actiune si intrebuintarii fortelor si mijloacelor in situatii de

urgenta.

Centrul Operational al Inspectoratului pentru Situatii de Urgenta al Municipiului

Bucuresti

Acest serviciu din cadrul Inspectoratului, asigura cele 2 elemente esentiale in situatii de

urgenta: monitorizarea si dispecerizarea situatiilor de urgenta, activitati care impreuna cu cele

de coordonare ale interventiilor in baza planurilor rezultate in urma activitatilor de analiza

evaluare si sinteza – SAESCI (Serviciul analiza evaluare, sinteza si coordonare a interventiei)

precum si alte activitati suport sustinute de alte servicii din cadrul inspectoratului, serviciile

de planificare, de prevenire, protectie civila si logistic,serviciul comunicatii si informatica,

asigura suportul operativ necesar gestionarii situatiilor de urgenta.

Aici se colecteaza si se proceseaza informatiile sosite pe flux-urile informationale identificate

si se intretin canalele informationale stabilite conform reglementarilor in vigoare.

Centrul Operational suporta activitatile de rutina ale institutiilor care activeaza in sistemul

local pentru Situatii de Urgenta si cele din zona operativa pe care o gestioneaza, si desemenea

este o componenta importanta a Sistemului National pentru Situatii de Urgenta asigurand

Secretariatul Tehnic Permanent pentru Comitetul Local CMBSU.

Serviciului Monitorizare Situatii de Urgenta si Dispecerat ISUMB

Deserveste activitatea structurilor proprii si gestioneaza activitatea echipajelor SMURD pe

campul operational, care este cu mult mai mare decat limitele administrative ale Municipiului

Bucuresti actionand si in judetele limitrofe. Pentru imbunatatirea activitatilor de cooperare pe

linia interventiilor operative un reprezentant al ISUMB-Ilfov are activitate permanenta in

structura organizatorica a dispeceratului.

18 / 234

Sistemul 112

Prelucrarea apelurilor de urgenta 112 si alte flux-uri

informationale la nivelul Dispeceratului ISUMB

ISUMB

Dispecerat/Monitorizare

SMURD

NIVEL DISPECERIZARE/

OPERATIV

NIVEL RECEPTOR

MONITORIZARE RISCURI

Sistemul de

Alarmare-Avertizare

Flux 112 sau alte surseApel operativ telefonic/radio

NIVEL EXTERN

Flux informational

Flux-uri Informationale

Date/Voce

Grupuri

de interventie

Inspectoratul de

Aviatie MIRA

SVSU

Acest Dispecerat are in compunere 7 terminale ale sistemului unic pe apeluri de urgenta

SNUAU-112, asigurand preluarea apelurilor de urgenta din intregul camp operational din

componenta ISUMB.

La nivelul Centrului Operational prin Serviciul de monitorizare si Dispecerat este deschis un

canal direct de cooperare cu Inspectoratul de Aviatie al MIRA in cazul urgentelor SMURD.

Serviciul de Comunicatii si Informatica al ISUMB

In cadrul Inspectoratului pentru Situatii de Urgenta al Municipiului Bucuresti, Serviciul

Comunicatii si Informatica reprezinta un segment important in subsistemul informational al

SMSUMB. Datorita activitatilor desfasurate in cadrul structurii pe care o deserveste, el are o

structura complexa, fiid o componenta care asigura in situatiile de urgenta cu caracter de

dezastru suportul operati pe segemntul de comunicatii si informatica al Comitetului

Municipiului Bucuresti pentru situatii de Urgenta.

Directia Generala de Politie a Municipiului Bucuresti

Prezentarea principalelor servicii cu rol important in gestionarea si sprijinul activitatilor

specifice activitatilor de rutina in situatii de urgenta.

Serviciul Comunicatii si Informatica

In cadrul Directiei Generale de Politie a Municipiului Bucuresti, Serviciul Comunicatii si

Informatica reprezinta un segment important in subsistemul informational al SMSUMB.

Datorita activitatilor desfasurate in cadrul structurii pe care o deserveste, el are o structura

complexa, fiind de departe cel mai mare serviciu ca dimensiune si grad de complexitate al

infrastructurii IT , din cadrul IGPR.

Sistemul informational este ansamblul de elemente implicate in procesul de colectare,

transmisie, prelucrare de informatii, un rol important avandu-ll Dispeceratul Directiei:

19 / 234

Dispeceratul Politiei Capitalei

In cadrul unei organizatii implicata in gestionarea situatiilor de urgenta de dimensiunea

DGPMB, rolul sistemului informational este de a asigura persoanele din conducere cu

informatii necesare pentru luarea diferitelor decizii operative sau de alta natura.

Impreuna cu unele servicii din cadrul organigramei DGPMB, Dispeceratul Politie Asigura 24

ore din 24 primirea sesizarilor telefonice ale cetatenilor prin Sistemul National Unic pentru

Apeluri de Urgenta 112, coopereaza cu celelalte agentii (ambulanta, ISUMBMB/SMURD,

jandarmerie), in caz de urgenta, furnizeaza informatii din competenta politiei prin apelarea

numarului telefonic 9545 – taxabil, dirijeaza echipele de interventie ale sectoarelor si sectiilor

la cazurile sesizate de cetateni, prin dispeceratele 112 de la nivelul sectoarelor de politie,

asigura deplasarea la fata locului a echipajelor de interventie la cazurile sesizate de cetateni.

Dispeceratul, este localizat in sediul DGPMB si este alcatuit dintr-un numar de 9 posturi-in

viitorul apropiat se va extinde cu inca 2 posturi si un post de administrare, deservind traficul

de apeluri de intrare via sistemul unic de apeluri de urgenta (SNUAU).

Sistemul 112

Prelucrarea apelurilor via sistemul unic de urgenta 112 si alte

flux-uri de apeluri

DGPMB

POLITIA SECTORULUI 1

Sectia 1


Sectia 6


Sectia 10


Sectia 14


Sectia 17


Sectia 20

Sectii de

Politie

Apeluri direct catre sectiile de

politie 40% din total DGPMBNIVEL DISPECERIZARE/

OPERATIV

9545 9544

BPR

NIVEL RECEPTOR

Servicii/Birouri

Flux informational la nivelul

Dispeceratului 112Apel sosit la nivelul sectiilor de politie

Apel operativ telefonic/radio

Apel sosit pe numere taxabile

NIVEL PRE-DISPECERAT/DISPECERAT/

POST-DISPECERAT

Apel telefonic/radio, dispozitive

automate de alarmare/semnalizare

Inspectoratul de

Aviatie- MIRA

Brigada de Politie Rutiera

Ca structura in cadrul DGPMB, are de asemenea un dispecerat dotat cu 1 statie interconectata

sistemului 112.

La BPR sosesc apeluri si pe 9454, numar telefonic pe care se primesc si inregistreaza

evenimente prin intermediul unei aplicatii denumita ECHO sau fluxuri informationale pe

canalele radio proprii Brigazii de la echipele mobile din teren.

Fluxul informational operativ este coordonat prin telefoanele si statiile radio pe frecventele

proprii.

Dotarea ambelor dispecerate este echipata de catre serviciul 112 cu un ansamblu plasma

display care face posibila urmarirea echipajelor operative prin intermediul dispozitivelor GPS

20 / 234

din dotare sau obtine informatii video din trafic (BPR) de la diverse puncte de interes

selectate de catre lucratorii dispeceratului . Tratarea tehnica a acestei facilitati, pusa la

dispozitie de SNUAU este tratata la capitolul rezervat sistemului 112. Comunicatiile radio

operative se realizeaza pe terminale radio in standard TETRA. BPR si DGPMB avand cea

mai buna dotare la acest capitol (ca numar de statii). La nivelul dispeceratelor DGPMB se

intocmesc rapoarte, sinteze de activitate situatii si alte documente solicitate de conducerea

institutiei.

Directia de Jandarmi a Municipiului Bucuresti – D.J.M.B

Dispeceratul, este localizat in sediul DJMB in cadrul Centrului operational al Directiei si este

alcatuit dintr-un numar de 2 posturi la nivel receptor, deservind traficul de apeluri de intrare

via sistemul unic de apeluri de urgenta (SNUAU).

Sistemul 112


flux-uri de apeluri

DJMB

CENTRUL

OPERATIONAL

Batalionul1


OPERATIV

NIVEL RECEPTOR






POST-DISPECERAT



Batalionul 2 Batalionul 2 Batalionul 2

Detasamentul

1

Detasamentul

2

Prelucrarea flux-ului informational sosit pe 112

Comunicatii Operative la Nivelul DJMB si sprijin aerian

DJMB

CENTRUL OPERATIONAL

Batalionul1


OPERATIV

Apel operativ

telefonic/radio/posta

electronica

Batalionul 2 Batalionul 2 Batalionul 2

Detasamentul

1

Detasamentul

2

IGJR Inspectoratul de

Aviatie al MIRA

MIRACooperare

NIVEL COOPERARE

Prelucrarea flux-ului informationale operative in cadrul IGJR si alte Structuri MIRA

21 / 234

Serviciul de Comunicatii si Informatica al DJMB

Datorita activitatilor desfasurate in cadrul structurii pe care o deserveste, el are o structura

complexa, fiind o componenta care asigura in situatiile de urgenta de rutina sau cele de

dezastru, suportul operational pe segmentul de comunicatii si informatica al Directiei.

o Administreaza, proiecteaza si realizeaza retelele de comunicatii de voce/date utilizate

de catre DLMB.

o Administreaza retelele, bazele de date precum si serverele de date, e-mail si web,

folosite de catre Icomandamentul Directiei si structurile din subordine.

o Asigura comunicatiile "voce" operative, realizeaza cu ajutorul statiilor radio portabile,

mobile sau fixe precum si comunicatiile "clasice" prin fir folosind un sistem complex de

centrale digitale Ericsson intr-o arhitectura de interconectare extrem de complexa tipica

dealtfel si celorlalte structuri ale MIRA.

o Administreaza si intretin sistemul de comunicatii date/voce existent in structura

DJMB, integrat in sistemul de comunicatii voce/date prin reteaua RCVD a Ministerului

Internelor si Reformei Administrative.-MIRA

o Gestioneaza, prin structuri specializate, patrimoniul din domeniile prezentate, alocand

in limita fondurilor bugetare resursele materiale necesare.

Inspectoratul de Aviatie al MIRA

Operatorul aerian asigura pregătirea personalului navigant şi a personalului medical şi de

salvare pentru executarea misiunilor, privind modul de exploatare, la sol şi în zbor, a

aeronavelor, prin organizarea de cursuri pentru pregătirea categoriilor de personal care

participă la misiunile de zbor si pentru exploatarea echipamentelor cat si organizarea

periodică a şedinţelor de analiză a activităţii de intervenţie/salvare aeriană si exerciţii de

intervenţie mixte cu alte servicii de intervenţie medicale şi nemedicale, cum ar fi

salvamontul, jandarmeria si serviciile profesioniste pentru situatii de urgenta.

Comunicatii:

Echipajele elicopterelor tin permanent legătura cu baza pentru furnizarea datelor necesare

executării zborurilor (informare meteorologică, aprobări pentru zbor, aprobări pentru survol

etc.).

La nivelul zonei Metropolitane:

Apelul este preluat de Centrul unic de apel 112 al municipiului Bucureşti în urma preluării

datelor si deschiderii fisei, codarea situatiei conform nomenclatorului unic de codare, apelul

va fi direcţionat către punctul de operare aeromedical şi dispeceratul Centrului Operational al

ISUMBMB, care va alerta echipajul furnizând datele necesare şi numerele de telefon de

contact necesare.

22 / 234

Apelurile pentru elicopter sunt preluate de dispeceratul ISUMBMB, care va alerta echipajul

sau, dacă este necesar, va transfera apelul către baza aeriană de intervenţie via radio sau

reteaua RCVD a MIRA.

Serviciul de Ambulanta al Municipiului Bucuresti – SAMB

Serviciul de Ambulanta al Municipiului Bucuresti asigura asistenta medicala de urgenta

prespitaliceasca atat la locul solicitarii cat si pe durata transportului pacientilor catre spital.

Pe langa aceasta SAMB asigura atat asistenta medicala ambulatorie la locul solicitarii precum

si transporturi nemedicalizate..

Pentru a asigura o mai buna rezolvare a solicitarilor, Serviciul de Ambulanta al Municipiului

Bucuresti are organizate substatii de ambulanta in sectoare 1, 3, 4, 5 si 6 sediul central fiind

si substatie de sector pentru sectorul2.

Substatiile de sector sunt conduse de medici coordonatori de substatii si sunt subordonate

administrativ sediului central care este situat in strada Mihai Eminescu, nr. 226, sectorul 2.

Sistemul 112

SAMB - prelucrarea apelurilor via sistemul unic de urgenta 112

si alte flux-uri de apeluri

Substatie

de

ambulanta

Sector 6


OPERATIV

NIVEL RECEPTOR


Dispeceratului 112




POST-DISPECERAT



Substatia

de

ambulanta

Sector 1

Substatie

de

ambulanta

Sector 3

Substatie

de

ambulanta

Sector 5

Substatie

de

ambulanta

Sector 4

Substatie de

ambulanta

Sector 2

SAMB

DISPEC

Functiile principale ale Sistemului Informatic aferent SAMB sunt:

stabilire diagnostic prezumtiv , furnizare de sfaturi de prim ajutor, preluare date de

identificare pacient, semnalare suprapunere solicitari dispecerizarea solicitarilor in functie de

:

o momentul inregistrarii

o tipul ambulantei si distanta de parcurs

o grad de urgenta, cu mentinerea unui echilibru optim intre competenta si distanta

stabilirea necesarului si structurii resurselor pe baza statisticilor medicale si de

activitate (pe tura, zilnice, saptamanale, lunare, anuale)

Sistemul National Unic pentru Apeluri de Urgenta SNUAU

23 / 234

Principalele sale atributii:

a) Primeste si inregistreaza automat apelurile de urgenta comunicate prin:

telefon,

radio,

dispozitive automate de anuntare,

semnalizare,

alarmare ori prin alte mijloace, confirmand si localizand, pe cat posibil, apelurile

primite;

b) Analizeaza, directioneaza si transmite operativ apelurile de urgenta catre:

servicii specializate de interventie;

autoritati competente (functie de natura evenimentelor si consecintele lor);

c) Primeste si inregistreaza datele si informatiile privind evolutia evenimentelor si a

interventiilor;

d) Centralizeaza, stocheaza si pune la dispozitie autoritatilor abilitate datele privind

apelurile de urgenta gestionate.

Centrele de preluare a apelurilor de urgenta dispun de o baza de date care ii ajuta pe

operatorii de la „112” sa localizeze apelul, incidentul produs si resursele de interventie cele

mai apropiate.

Acest lucru este se realizeaza cu ajutorul a trei procese tehnice:

ANI (Automatic Number Identification) - identificarea automata a numarului de

telefon de la care se face apelul: pe monitorul operatorului apare numarul postului telefonic

de unde apelantul suna.

ALI (Automatic Location Identification) – acest proces este urmarea analizei

numarului apelantului, pentru identificarea automata a locatiei:- date necesare validarii

apelului cat si flux-ului operativ de date catre structurile popsibil implicate in posibila situatie

de urgenta.

Pe monitorul operatorului apar adresa apelantului, locul de unde acesta suna si o serie de

informatii suplimentare necesare pentru a exploata toate resursele in vederea gasirii solutiei

optime pentru a ajunge in timp util la locul incidentului.

AVL (Automatic Vehicle Location) este un proces care se desfasoara on-line,

intre echipajele mobile si echipamentele specializate de monitorizare. Urmare a datelor

primite permanent din teren se identifica pozitia autovehiculelor la un moment dat sau a

celor angajate in procesul de interventie la situatiile de urgenta dotate cu echipamente de

comunicatii radio (conventionale sau digitale)

24 / 234

Sistemul 112


flux-uri de apeluri

ISUMBDGPMB DJMB SAMB


Sectia 1


Sectia 6


Sectia 10


Sectia 14


Sectia 17


Sectia 20

Sectii de

Politie

Apeluri direct catre sectiile de

politie 40% din total DGPMB

Grupuri

de

interventie/

SMURD

Batalioane de

interventie/

Detasamente

Substatii de

ambulanta


OPERATIV

9545 9544

BPR

NIVEL RECEPTOR

Servicii/Birouri






POST-DISPECERAT



1.4 Conceptia privind reproiectarea SMSUMB:

1.4.1 Conceptia generala

Activităţile privind prevenirea, pregătirea şi intervenţia în situaţiile de urgenţă reprezintă un

ansamblu de activităţi specifice, măsuri şi sarcini organizatorice, tehnice, operative, cu

caracter umanitar şi de informare publică planificate, organizate şi realizate în scopul

prevenirii şi reducerii riscurilor de producere a dezastrelor, protejării populaţiei, bunurilor şi

mediului împotriva efectelor situaţiilor de urgenţă.

Autoritatea Contractantă - Primăria Municipiului Bucureşti – trebuie să dispună de un Sistem

de Management pentru Situaţii de Urgenţă complet şi complex, care să integreze, la nivelul

unui Centru de Comandă Unic (numit Centrul de Management Integrat pentru Situaţii de

Urgenţă – CMISU) toate dispeceratele instituţiilor, serviciilor implicate în gestionarea

situaţiilor de urgenţă, precum şi asigurarea unei infrastructuri tehnice şi logistice integrate,

performante, sigure şi fiabile pentru buna funcţionare a acestora. Implementarea proiectului

va asigura bazele extinderii aplicaţiei SMSMUB către intreg arealul zonei metropolitane.

Aplicaţia trebuie să permită, în timp real, furnizarea, procesarea, identificarea deciziilor şi

metodelor de intervenţie optime, care să evite pe cât posibil şi/sau reducă la maximum

pierderile umane şi materiale, în cazul situaţiilor de urgenţă la nivelul Municipiului Bucureşti.

De asemenea, include echiparea completă şi realizarea CMISU complet nou, cu infrastructura

informatică şi de comunicaţii necesare, pentru a permite controlul şi/sau monitorizarea

permanentă a diverselor evenimente, inclusiv înlocuirea şi modernizarea echipamentelor

existente la structurile de intervenţie. Acestea pe durata situaţiilor de urgenţă sau a stărilor

potenţial generatoare de situaţii de urgenţă întreprind, în condiţiile legii, după caz, acţiuni şi

măsuri specifice.

25 / 234

Comitetul Municipiului Bucureşti pentru Situaţii de Urgenţă asigură managementul şi

organizează intervenţia forţelor prin acţiuni specifice desfăşurate în timp şi spaţiu, într-o

succesiune logică după scenarii posibile pentru situaţii de urgenţă (excepţionale) Scenariile

realizate şi analizate reprezintă manifestări probabile ale riscului cu o anumită intensitate şi

pe o zonă de impact precizată, precum şi acţiuni complexe, dinamice şi active ale entităţilor

cu atribuţii în managementul situaţiilor de urgenţă.

Scopurile se stabilesc, pe categorii de participanţi şi riscuri, potrivit tipului şi complexităţii

intervenţiei, gradului de pregătire şi coeziune al structurilor, activităţilor şi acţiunilor ce se

prevăd a se executa.

Problemele urmărite de Comitetul Municipiului Bucureşti pentru Situaţii de Urgenţă sunt

activităţi şi acţiuni privind pregătirea şi executarea măsurilor de prevenire, protecţie, salvare,

intervenţie şi revenire la situaţia de normalitate.

1.4.2 Conceptia privind realizarea si implementarea SMSUMB

SMSUMB impune realizarea unui Centru Municipal Integrat pentru Situaţii de Urgenţă, care

în prezent nu există, pornind de la necesitatea asigurării primirii informaţiilor şi/sau datelor în

timp real, analizării şi prelucrării acestora pentru luarea deciziilor corecte în vederea

coordonării şi conducerii intervenţiilor în situaţii de urgenţă, deoarece prin înfiinţarea lui se

micşorează semnificativ timpul de răspuns la urgenţe şi dezastre, îmbunătăţindu-se vizibil

calitatea serviciilor acordate cetăţenilor.

Centrul Municipal Integrat pentru Situaţii de Urgenţă trebuie să reprezinte un concentrator şi

distribuitor principal de date, informaţii şi mesaje primite de la structurile ierarhice şi

superioare, sau de la operatori econimici sursă de risc, autorităţi ale administraţiei publice

centrale sau locale, precum şi direct din teren. Centrul va beneficia de toate facilităţile

tehnice, logistice şi operaţionale (softuri, aparatură, echipamente electronice şi IT) proiectate

şi implementate, pe tipuri şi domenii de riscuri, astfel încât să ofere parametrii de analiză şi

decizie de tip cauză - efect, sub toate aspectele. Astfel, centrul va beneficia de sisteme de

afisare moderne, comunicaţii interne şi externe în timp real (atât proprii cât şi ale altor

autorităţi responsabile de acţiuni şi/sau intervenţii în teritoriu), achiziţie, înregistrare şi

prelucrare automată a datelor. Totodată, centrul va avea o structură de prelucrare automată a

datelor din teren, cu sarcina şi capacitatea de predicţie, semnalizare şi informare evenimente,

inclusiv de analiza si evaluare a activităţilor desfăşurate in teren a structurilor de interventie

pentru informare, prevenire, intervenţie şi refacere a zonelor afectate.

In cadrul CMISU se colecteaza date, se interpreteaza datele colectate, se iau decizii la

nivelele de competenta corespunzatoare si se transmit mesaje tuturor partilor interesate

corespunzator cu importanta si gravitatea pericolului si cu faza activităţilor de rutină

(cotidiene) sau grave (excepţionale).

SMSUMB va conţine de exemplu mai multe subsisteme intre care amintim:

Subsistemul de colectare automată a datelor

26 / 234

Subsistemul de alarmare şi avertizare

Subsistemul produse informatice

Subsistemul de comunicaţii etc...

Subsistemul de colectare automata a datelor reprezinta ansamblul echipamentelor, care

permit monitorizarea factorilor de risc de la operatorii economici si alte surse de risc, si a

elementelor de infrastructura, care permit transmiterea automată a informaţiei colectate către

CMISU.

Subsistemul de alarmare/avertizare reprezintă totalitatea mijloacelor –echipamente de

avertizare si alarmare acustica si optica, echipamente individuale de avertizare si alarmare,

echipamente de avertizare si alarmare de tip broadcast – prin care poate fi avertizata

populatia, autoritatile, alte institutii, pentru a lua masurile necesare prevenirii si/sau

indepartarii pericolului existent/potential. Toate aceste sisteme pot fi proprii sistemului sau

pot apartine altor entitati (publice sau private). Subsistemul va avea capacitatea de a interfata

cu toate aceste sisteme care pot asigura informare la nivelul populatiei (existente la momentul

lansarii proiectului), asigurand totodata nivelul de standardizare necesar pentru a asigura

capacitatea de conectare ulterioara a altor sisteme, posibil dezvoltate in viitor.

Subsistemul produse informatice reprezinta ansamblul aplicatiilor care deservesc toate

celelalte subsisteme. Acestea trebuie sa permita functionarea in mod automat a mecanismelor

de decizie care trebuie sa functioneze in acest regim, sau sa furnizeze informatiile necesare

complete, corecte, la timp si la destinatia specificata in cazul in care procesul de luare a

deciziilor impune acest lucru, ingloband produse informatice specializate pe tipuri de risc.

Subsistemul produse informatice trebuie sa prevada inlaturarea unor componente ale

sistemului. Subsistemul produse informatice trebuie sa contina si interfetele care asigura caile

de conectare intre componentele sistemului integrat si intre acesta si alte sisteme externe

inclusiv retelele specializate in monitorizarea factorilor de risc.

Subsistemul de comunicaţii reprezinta ansamblul elementelor de infrastructura de

comunicaţii. In componenta sa intra caile de comunicaţii utilizate in vederea transferului de

date, informatii, semnale si mesaje atat cu celelalte subsisteme cat si cu celelalte centre

operationale si operative din cadrul Sistemului National pentru Situaţii de Urgenţă, CON 1 si

CON2 prin intermediul aplicatiei EMIS. Subsistemul de comunicaţii trebuie sa asigure

compatibilitatea si interfatarea CMISU cu sistemele de comunicaţii deja aflate in exploatare,

atat proprii cat si ale altor entitati care pot fi implicate in cazul Situaţiilor de Urgenţă.

Sistemul de management al Situaţiilor de Urgenţă la nivelul Municipiului Bucureşti trebuie

proiectat incat sa asigure colectarea de informatii oportune (din mai multe surse), stocarea,

procesarea si expunerea in ordine logica necesara pentru a permite intreaga percepere a

situatiei, a planurilor de actiune si a resurselor de raspuns disponibile si necesare. Impartirea

informatiilor pe verticala va avea loc ascendent intre SMSUMB si Centrul Operational

National (CON) / Centrul National de Conducere si Coodonarea a Interventiei (CNCCI) si

descendent, intre SMSUMB si centrele operative. Sistemul proiectat va avea acoperire pentru

zona metropolitană si va include toate institutiile, organizatiile si structurile implicate in

situaţii de urgenţă.

27 / 234

1.4.3 Conceptia de integrare a tuturor sistemelor implicate in situaţiile de urgenţă

existente in CMISU (Centrul municipal integrat pentru situaţii de urgenţă)

Problemele curente de rutină, pe care le ridică un oraş de mărimea Bucureştiului devin din ce

în ce mai complexe şi implică intervenţia eficientă a organizaţiilor competente pentru

rezolvarea lor. Cu atât mai mult, în cazul unor situaţii de urgenţă, intervenţiile organizaţiilor

competente trebuie să se desfasoare într-o interoperabilitate bine sincronizată pentru a avea

un timp cât mai bun de răspuns şi pentru a minimiza şi înlătura cât mai rapid efectele unei

astfel de situaţii.

Realizarea Centrului Municipal Integrat pentru Situaţii de Urgenţă - CMISU, prin aducerea

principalelor dispecerate sa lucreze impreuna intr-un centru de monitorizare al Municipiului

Bucureşti, în regim de interoperabilitate nu poate decât să fie benefică pentru rezolvarea atât

a situaţiilor de rutină cât şi a situaţiilor de urgenţă care pot aparea, acest demers fiind una

direcţiile pe care ni le-am propus în realizarea acestui Proiect. Centrul Municipal Integrat

pentru Situaţii de Urgenţă – CMISU, trebuie să asigure suportul pentru gestionarea situaţiilor

de urgenţă atât de rutină, cât şi pentru situaţii mai deosebite, denumite de către noi, în

cuprinsul acestui material, urgenţe grave (excepţionale).

Pe durata unei situaţii de urgenţă este esenţială menţinerea în stare operativă a

CMISU. Decizia de înfiinţare a CMISU a fost fundamentată în primul rând pe

principiul unităţii de decizie şi acţiune (unităţii de comandă). Acestui principiu i s-au

adăugat şi alte cerinţe (principii) ale managementului ştiinţific

Documentarea şi analiza ocazionate de elaborarea Studiului de fezabilitate ne-au

permis identificarea unor elemente de conţinut, ce direcţionează funcţionarea CMISU:

Activităţile depuse de către operatori în gestionarea situaţiilor de urgenţă pe diverse

categorii de risc, cât şi condiţiile speciale ce conduc la întrunirea Comitetului

Municipal Bucureşti pentru Situaţii de Urgenţă (CMBSU) se derulează, în multe

situaţii, disparat.

Conceptul de Integrare are la bază colocarea într-o manieră coerentă, operaţională a

dispeceratelor existente ISUMB, DJMB, SAMB şi DGPMB (nucleul central – Eforie)

în acelaşi spaţiu.

Alte dispecerate, ce sunt mai puţin sau deloc implicate în eforturile depuse în acest

sector de activitate, dar al căror aport ar fi benefic în gestionarea situaţiilor de urgenţă

prin mărirea performanţelor operative ale forţelor aflate pe traseu sau dislocate în

teatrul de operaţii, ar putea fi impulsionate. Ne referim la: Dispeceratul Brigăzii de

Poliţie Rutieră, Dispeceratul Control Trafic şi Dispeceratul Poliţiei Comunitare.

La această arhitectură de bază se vor alătura reprezentanţi ai PMB şi ai furnizorilor de

utilităţi – extensii ale dispeceratelor Apanova, Distrigaz, Eon Muntenia. Această

ultimă grupă va gestiona, în primul rând, apelurile sosite pe Linia Verde a Primăriei

Generale şi va asigura un flux informaţional unitar către operatorii de rutină ai

Centrului, după caz.

28 / 234

Numărul total de posturi de lucru în activităţile de rutină a fost evaluat luându-se în

considerare dispunerea enunţată mai sus, rezultată în urma procesului de integrare.

Prin extinderea ariei operative, urmare a abordării metropolitane a gestionării

situaţiilor de urgenţă, este posibil ca numărul acestor persoane din componenţa

Dispeceratului Centrului Operaţional al ISUMB să fie mai mare în viitorul apropiat.

Acelaşi raţionament poate fi extins şi asupra direcţiilor de dezvoltare ale celorlalţi

operatori.

De-asemenea este necesara integrarea bidirectionala la nivel de flux audio si date cu

Centrul de Comanda si Control Mobil pentru situatii de urgent, achizitionat de

Asociatia de Dezvoltare Intercomunitara Bucuresti-Ilfov (ADIBI), integrare ce va fi

definita la momentul analizei sistemului;

Structura organizatorică poate fi considerată ca fiind coloana vertebrală a Centrului Integrat,

buna funcţionare a acesteia fiind dependentă de modul în care sunt plasate şi utilizate

resursele umane de care dispune într-o anumită etapă. Pornind de la această abordare am

încercat ca prin conceptul de integrare al operatorilor de rutină cât şi prin asigurarea unui

suport operaţional acestui Centru, să îmbunătăţim gradul de utilizare al resurselor existente.

Definită ca ansamblul persoanelor, subdiviziunilor organizatorice şi al relaţiilor dintre

acestea, constituite în aşa fel încât să asigure premisele organizatorice adecvate îndeplinirii

obiectivelor stabilite prin înfiinţarea acestui Centru Municipal Integrat pentru Situaţii de

Urgenţă, structura organizatorică este rezultatul unui demers ce a cuprins:

Elaborarea structurii organizatorice (delimitarea posturilor, compartimentelor etc.)

Întocmirea unor fluxuri informaţionale raţionale

Utilizarea completă, atât a factorului uman, cât şi a celorlaltor resurse

Definirea unor legături eficiente între compartimente şi a unui sistem de relaţii între

organizatie şi mediu.

1.4.4 Reproiectarea componentei ,,Înştiinţare”

Componenta ,,Înştiinţare” din cadrul Subsistemului de Avertizare - Alarmare se bazează pe

fluxuri informaţionale sosite de la o serie larga de entităţi iar din punct de vedere tehnic pe o

varietate de modalităţi si mijloace de comunicaţii. (Elemente ale subsistemului Avertizare -

Alarmare sunt tratate si in cadrul Subsistemului Comunicaţii)

Ordinul MAI nr. 1259/2006 prevede la Art. 11. - Pentru realizarea înştiinţării se folosesc

sisteme şi echipamente ale serviciilor de urgenţă, precum şi mijloace şi canale puse la

dispoziţie de Serviciul de Telecomunicaţii Speciale, pe bază de protocol/plan de cooperare,

posturi de radiodifuziune şi televiziune centrale şi locale, aparate telefonice conectate la

sistemul de telecomunicaţii teritorial, aparate telefonice din reţeaua de cooperare organizată

de Ministerul Apărării Naţionale [RTP/RMNC], căi şi circuite telefonice închiriate permanent

sau preluate temporar pe bază de protocol din sistemul de telecomunicaţii teritorial, staţii şi

receptoare radio, receptoare cu frecvenţe fixe, radiotelefoane din înzestrarea serviciilor de

urgenţă profesioniste, precum şi ale agenţilor economici sursă de risc.

29 / 234

Activităţile de înştiinţare se desfăşoară utilizând sistemul de comunicaţii specific reţelei

speciale naţionale:

Sistemul de radiocomunicaţii UUS convenţional:

Sistemul de radiocomunicaţii TetraPol

Sistemul de radiocomunicatii TETRA

Reteaua IC.

Structura actuala a fluxurilor informaţionale va suferi o serie de modificări de fond si forma

odată ce aplicaţia BEMIS va deveni operaţională, in sensul ca o serie de fluxuri

informaţionale vor sosi direct dinspre CON, via BEMIS pe consolele personalului ISUMB.

Forma acestor fluxuri informaţionale receptionate va fi rezultatul integrarii informatiilor in

aplicaţie/format digital.

In cadrul Centrului Integrat Municipal pentru Situaţii de Urgenta - CMISU, Centrul

Operational al ISUMB va sedimenta acest flux dinspre CON pe platforma BEMIS. Dupa cum

am enuntat criteriile de performanta ale aplicaţiei BEMIS, in cadrul capitolului referitor la

Aplicaţia software ce va trebui dezvoltata pentru CMISU, BEMIS trebuie interpretat ca fiind

o suita de aplicatii software care va trebui sa raspunda standardelor de inteconectare la

BEMIS si in plus va furniza o serie de servicii/facilitati necesare unei mai bune gestiuni a

situaţiilor de urgenta pe plan local.

Din punct de vedere al fluxului de înştiinţare, interpretarea datelor de intrare de la agentiile

care conform legii se ocupa cu monitorizarea riscurilor, va fi distribuita spre zonele de interes

(in tara si in cazul nostru Municipiul Bucureşti/Zona Metropolitana) prin intermediul

platformei BEMIS. Platforma BEMIS va fi prezenta la nivelul ISUMB iar la CMISU fluxul

de înştiinţare va fi integrat in platforma BBEMIS. Consistenta si forma de prezentare a

30 / 234

datelor va fi aceeasi atat in BEMIS/ISUMB cat si in BBEMIS/CMISU, chiar daca interfata

grafica utilizator – GUI poate avea un alt design grafic (conform „‟Cerinte aplicaţie Software

– Interfata Utilizator”).

In situaţia de rutina, fluxurile de date de intrare catre Centrul Operational/CMISU au fost

enuntate in analiza fluxurilor de date si in cerintele de date la nivelul Centrului Oparational si

de realizare a Bazei de Date Operationale.

In situaţia unui dezastru la nivelul capitalei este necesara angrenarea si a altor surse de

informatii, cum ar fi de exemplu Federatia Romana de Radioamatorism – Bucureşti. Astfel de

surse pot asigura un suport important de informatii in situaţii dificile de urgenta care pot

apărea în Municipiul Bucureşti.

Aceasta componenta de sprijin poate fi gestionată in situaţii deosebite prin integrarea in

aplicaţie a fluxurilor sosite la nivelul grupei de call-center din CMISU.

Din punct de vedere al sistemelor si echipamentelor serviciilor de urgenta, in locul platformei

F1001A/B, care din punct de vedere al cerintelor unui management modern este depasita, se

va implementa pentru Municipiul Bucureşti / Zona Metropolitana, un sistem de înştiinţare

bazat pe platforma software care va integra fluxurile informaţionale sosite de la surse

autorizate si va putea accesa schemele de înştiinţare si alarmare întocmite de catre specialistii

COMB si transmite intr-o forma coerenta mesajul/mesajele de înştiinţare. Forma mesajelor

transmise este de tip mesaj text pentru teminale mobile DECT, GSM si pagere alfanumerice.

Utilizarea simultana a sistemelor de comunicatie GSM si paging asigura redundanta in cazul

in care unul din sisteme devine nefunctional la un anumit moment dat.

Utilizarea sistemului paging nu este o noutate, acesta fiind identificat si in analiza de

benchmarking efectuata de noi asupra altor sisteme de management similare.

Aceasta modalitate asigura o transmitere rapida a mesajelor, deci o imbunatatire a fluxului de

înştiinţare.

In cazul fortelor operative înştiinţarea va fi dublata si de transmiterea unui mesaj paging care

poate asigura transmiterea cu succes a mesajului in situaţia congestiei retelei de telefonie

mobila.

Scopul implementarii unui astfel de sistem il constituie trasmiterea de la Serviciului

Monitorizare-Dispecerat al ISUMB-Centrul Municipal Integrat –CMISU de mesaje critice in

mod instantaneu, reconfigurabil pentru necesitatea de moment, pntru o mobilizare rapida si

selectiva a fortelor de interventie. Apelul de grup sau individual permite crearea in timp

operativ de echipe de interventie configurabile functie de eveniment in situatii de urgenta

deosebite.

Sistemul asigura:

contactarea instantanee a personalului operativ dispersat pe o raza mare - aria de

acoperire a componentei de instiintare-alarmare trebuie sa fie Municipiul Bucuresti si

zona Metropolitana

31 / 234

contactarea in timp real a unor echipe de interventie rapida si/sau factori de decizie

implicati in managementul situatiilor de urgenta;

transmiterea de mesaje de grup, care reprezinta un mod facil si rapid de a comunica

unui individ sau grup de indivizi, informatii in functie de responsabilitati in situatii de

urgenta.

transmiterea de detalii personalului instiintat: ce, unde si cum sa raspunda cu actiuni

rapide si ferme;

transmiterea de apeluri individual sau de grup in mod silentios, eliminand atragerea

atentiei generale provocata de un difuzor in functie.

Configurarea sistemului functie de nevoi, astfel incat sa penetreze anumite cladiri si structuri,

sa acopere cartiere, sa realizaze o retea dupa nevoi specifice cazului.

Transmiterea instantanee si simultana a unui mesaj la un numar mare de persoane (10.000 –

20.000 de mii de persoane).

Operarea pe scara larga: asigura raza de acoperire pentru Bucuresti cu capabilitate de

extindere/acoperire a zonei Metropolitane si chiar mai mult. Acesta trebuie să asigure

următoarele facilităţi:

poate fi interfatat cu sisteme de securitate, sisteme de monitorizare si control, sisteme

de management cladiri, sisteme de distributie, etc.

asigura istoricul convorbirilor si statistica traficului precum si inregistrarea mesajelor

vocale transmise pentru a avea evidenta mesajelor transmise

va asigura prioritizare a mesajelor transmise pe mai multe nivele, astfel incat cele de

maxima importanta sa fie primele transmise; gama larga de mesaje in format digital.

Prioritizarea va fi data de schemele de instiintare/avertizare intocmite de catre

specialistii ISUMB. Sistemul este flexibil si modular si are capacitatea de extindere pe

toate directiile (ca numar de operatori, capacitate, optiuni/functii) permitand

dezvoltarea in functie de necesitati. Sistemul este usor de upgradat sau reconfigurat

functie de cerinte noi, de capacitate si optiuni. Sistemul are o configuratie complet

redundanta cu controller standby.

Acesta pemite operare centralizata si redundanta de la oricare din dispecerate - ISUMB si

CMISU, cu operator pe PC si aplicatii dedicate, cu optiune de acces de la un telefon analog

sau digital sau remote PC. Managementul utilizatorilor de servicii paging se va realiza prin

intermediul aplicatiei software dedicate.

1.4.5 Reproiectarea componentei „Avertizare”

Avertizarea constă în aducerea la cunoştinţa populaţiei a informaţiilor despre iminenţa

producerii sau producerea unor dezastre şi se realizează de către autorităţile administraţiei

publice centrale sau locale, după caz, pe baza înştiinţării transmise de structurile abilitate.

Mijloacele de avertizare sunt eficiente pentru conducerea unitara a actiunilor structurilor

abilitate de lege (administratie locala, politie, pompieri, protectie civila, ambulanta, etc.) sa

32 / 234

intervina in prevenirea si lichidarea urmarilor unor catastrofe naturale (cutremure, inundatii,

furtuni, alunecari de teren), accidente (chimice, nucleare, biologice, rutiere, feroviare, navale,

aeriene, cosmice), acte teroriste, tulburari ale ordinii publice etc.

Un segment important al componentei de instiintare-alarmare ar trebui sa-l constitue posturile

nationale si locale de radio si televiziune, precum si operatorii de cablu TV.

In cazul in care posturile de radio si Tv au incheiate protocoale de colaborare pentru situatii

de urgenta trebuie sa fie posibila transmisia mesajelor de avertizare catre acestea.

O alta modalitate de avertizare poate fi realizata prin utilizarea panourilor publicitare

existente in numar mare de-a lungul arterelor capitalei, in cazul in care este reglementata

aceasta modalitate trebuie sa permita trasmiterea mesajelor care sa fie afisate pe acest tip de

afisaj. Aici tratam componenta de Avertizare dar este in mod cert fezabila posibilitatea de

afisare a unor mesaje in scopul pregatirii sau prevenirii populatiei pentru situaţiile de urgenta.

Tinand cont de numarul foarte mare de utilizatori ai metroului care se afla la un anumit

moment intr-un mediu ambiental izolat de exterior, in cazul iminenţei producerii sau la

producerea unor dezastre, se impune realizarea alarmarii atat a calatorilor cat si a personalului

din serviciu. Alarmarea acestora se va realiza prin dispeceratul metroului, care in urma

notificarilor primite de la ISUMB/CMISU sau din alte surse autorizate, va lansa mesaje

despre situatia creeata, precum si pentru coordonarea persoanelor aflate in vagoane si statii,

evitndu-se astfel panica care s-ar produce la auzul unor zvonuri provenite dinspre exterior.

De-asemenea este necesara preluarea din sistemul METROREX a alarmelor in caz de

incendiu si posibilitatea vizualizarii fluxurilor video din sistemul de supraveghere existent.

Descrierea SMSUMB

Sistemul de Management al Situaţiilor de Urgenta al Municipiului Bucureşti va servi ca loc

de stocare central a datelor necesare privind activitatile în situatii de urgenta în toate etapele

prezentate, atat ca furnizor de informaţii pentru planificarea ante-dezastru, cat şi pentru

sprijin în luarea deciziilor în situaţii de dezastru pentru diferitele nivele ale managementului

situatiilor de urgentă.

Principalele funcţii ale SMSUB sunt:

Colectarea de date (on-line sau off-line) de la alte sisteme operaţionale care sunt

relevante pentru managementul situatiilor de urgenta în zona Bucuresti – Ilfov şi sunt

detinute sau rulate de diferite centre, agenţii şi autorităţi cu roluri clar definite în

situatiile de urgentă;

Îndeplinirea funcţiei de centralizare a datelor – agregate sau detaliate – de la diferite

surse şi în diferite momente, care trebuie folosite în luarea deciziilor în managementul

situatiilor de urgenta;

Sprijin în luarea deciziilor la nivele ierarhic superioare ale managementului situatiilor

de urgenta;

Asigurarea şi furnizarea informaţiilor despre deciziile luate la toate nivelele ierarhic

inferioare ale structurilor din cadrul inspectoratelor pentru situatii de urgenta;

33 / 234

Asigurarea sprijinului pentru crearea şi mentenanta planurilor de răspuns în caz de

urgentă;

Asigurarea managementului de resurse: materiale, resurse umane şi financiare în toate

fazele managementului situatiilor de urgentă;

Raportarea în timp real şi efectuarea unor analize predictive, furnizând o soluţie

standardizata pentru managementul electronic al înregistrărilor;

Sprijinirea exerciţiilor în circumstanţe de dezastru simulat.

1.4.6 Arhitectura de sistem a SMSUMB

In figura următoare este ilustrata o vedere de ansamblu de interconectare SMISU şi SMSUB

a diferitelor sisteme şi locaţii:

Backbone

STS

RCVD Bucuresti

MIRA

STS

Bucuresti

RCVD - MIRA

TETRA STS

COMB

CON 1

CON 2

Baza date 1

Baza date 2

Baza date

Bucuresti

(v,2)

Abonati RCVD

Abonati VPN

Abonatii RCVD-MIRA

Abonati STS

Terminale

Comunicatii

fixe / portabile

STS Mobil

Sistemul de Management al Situaţiilor de Urgenta al Municipiului Bucureşti va fi o aplicaţie

centralizata – asigurata prin facilitatile SMISU, astfel ca toate informaţiile vor fi stocate intr-o

bază de date centrală din cadrul Centrului Operaţional al Municipiului Bucureşti (COMB), iar

utilizatorii vor accesa aceste informaţii prin tranzacţiile business-online cu scopul de citi,

scrie, actualiza şi şterge funcţii, conform drepturilor utilizatorului. Din punct de vedere fizic,

aceasta funcţionalitate va consta intr-o aplicaţie pe baza de tehnologie web. SMSUB trebuie

să îndeplinească următoarele roluri cheie:

Informare: oferă o singura vizualizare coeziva intr-o gamă largă de surse de

informaţii;

34 / 234

Aplicaţie (si procese asociate): asigura o interfaţa consistenta unui set vast de

aplicaţii;

Colaborarea dintre oameni: prezintă toate avantajele lucrului în echipa şi specializării

fără nevoia de distribuire fizică;

Soluţia portal trebuie să fie compatibila cu agregarea de performanta superioara a datelor

provenite din mai multe surse de date, inclusiv RDBMS disponibil (Relaţional Data-base

Management System – sistem de management al bazelor de date relaţionale).

1.4.6.1 Subsistemul Centrul Operaţional al Municipiului Bucuresti

Centrul Operaţional al Municipiului Bucureşti (COMB) este hub-ul central de informaţii şi

mesaje primite de la structurile subordonate si cele care intra în aria managementului

situatiilor de urgenta la nivelul municipiului Bucuresti, de la autorităţile locale, centrale

precum şi direct de pe teren. Centrul va beneficia de toate facilităţile tehnice, logistice şi

operaţionale necesare unui Centru Operaţional, incluzând console operator, dispozitive de

video-wall, sisteme de comunicaţii în timp real, sisteme de achiziţie şi înregistrare automată a

datelor etc. De asemenea, Centrul Operaţional va avea capacitatea de prelucrare automata a

datelor primite, obţinându-se astfel o capacitate de predicţie, statistica, semnalizare şi

informare pentru evenimente.

In cadrul COMB se colectează şi se procesează/analizează/interpretează date şi se iau decizii

pe baza acestor date, în funcţie de nivelele de competentă. Centrul Operaţional al

Municipiului Bucureşti îndeplineşte permanent funcţiile de monitorizare, evaluare,

instiintare, avertizare, pre-alarmare, alertare şi coordonare tehnică operaţională a

intervenţiilor pentru gestionarea situaţiilor de urgenta;

1.4.6.2 Subsistemul de colectarea a datelor

Subsistemul de colectare automata a datelor reprezintă ansamblul echipamentelor care permit

monitorizarea factorilor de risc de la operatorii economici şi alte surse de risc, şi a

elementelor de infrastructura, care permit transmiterea automata a informaţiei colectate către

SMSUB.

Acest subsistem are ca sarcina asigurarea existentei în SMSUB a informaţiilor importante în

luarea deciziilor, atât în stare de normalitate cât şi în situaţii de criză. Aceste informaţii

trebuie să fie complete şi actuale şi corelate cu alte informaţii sau cu datele cronologice,

pentru a putea obţine o imagine corecta a situaţiei existente. Sub sistemul are asigurata prin

SMISU o capacitate de stocare a datelor si informatiilor, reprezentata prin serverele care vor

fi instalate în COMB.

Urmare a Studiului de Fezabilitate si a analizelor de situatie si de management realizate,

susbsistemul de colectare a datelor se va implementa prin crearea unei baze de date

specializata pentru situatii de urgenta la ISUMB.

35 / 234

1.4.6.3 Subsistemul de alarmare/avertizare

Subsistemul de alarmare/avertizare reprezintă totalitatea mijloacelor –echipamente de

avertizare şi alarmare acustica şi optica, echipamente individuale de avertizare şi alarmare,

echipamente de avertizare şi alarmare de tip Broadcast – prin care poate fi avertizata

populaţia, autorităţile, alte instituţii pentru a lua masurile necesare prevenirii si/sau

îndepărtării pericolului existent/potenţial.

In cadrul SMSUB, se va putea apela sau transmite informaţii către subsistemul de alarmare,

fie manual, în baza unei decizii a unei persoane responsabile, fie automat în cazul în care sunt

îndeplinite o serie de criterii prestabilite pentru un anumit tip de alarmă.

1.4.6.4 Subsistemul de produse informatice

Subsistemul produse informatice reprezintă ansamblul aplicaţiilor şi echipamentelor (daca

este cazul) care deservesc toate celelalte subsisteme. Acestea trebuie să permită funcţionarea

în mod automat a mecanismelor de decizie care trebuie să funcţioneze în acest regim, şi să

furnizeze informaţiile necesare complete, corecte, la timp şi către destinatarul specificat în

cazul în care procesul de luare a deciziilor impune acest lucru, înglobând produse informatice

specializate pe tipuri de risc.

Subsistemul produse informatice va avea capacitatea de a schimba configuraţia, inclusiv de la

distanta, prin adăugarea, înlocuirea sau înlăturarea unor componente ale sistemului. Acest

sub-sistem va include interfeţele care asigura clăile de conectare intre componentele

sistemului integrat şi intre acesta şi alte sisteme externe, inclusiv reţelele specializate în

monitorizarea factorilor de risc.

In prezent, la nivelul tarii este in curs de implementare un sistem de produse informatice,

implementare coordonata la nivelul IGSU. Acest sistem, numit Sistemul de Management

Informational pentru Situatii de Urgenta (SMISU) va deservi sistemele de reactie la urgente

din Romania, respectiv atât la nivel national cât si regional si local.

Prin conceptie, Sistemul de Management Informational pentru Situatii de Urgenta este

sistemul informatic integrat al SNMSU, care conecteaza toate centrele operationale (CO)

pentru situatii de urgenta, precum si alte organizatii interesate in vederea partajarii de

informatii relevante si suport in luarea deciziilor atat in activitatea de zi cu zi si in situatii de

urgenta care implica gestionarea acestora de către comitetele pentru situatii de urgentă. Acest

sistem va fi utilizat in toate etapele managementului situatiilor de urgentă: prevenire,

planificare, răspuns si restabilirea stării de normalitate. In prezent, in cadrul Sistemului

Naţional de Management al Situaţiilor de Urgentă si urmăreste implementarea a două

componente, complementare si interdependente, respectiv „modernizarea sistemului de

comunicaţii pentru situaţii de urgenţă” şi „dezvoltarea sistemului de management

informaţional pentru situaţii de urgenţă” (actualmente SMISU), acestea având ca obiectiv

fundamental imbunătăţirea capacităţii autorităţilor romane de pregătire, reacţie şi refacere in

urma dezastrelor naturale sau antropice prin interconectarea Centrului Operaţional Naţional

36 / 234

cu Centrele Operative organizate la ministere şi instituţii publice centrale cu atribuţii in

domeniu.

SMISU va asigura imbunatatirea schimbului de informatii intre institutiile implicate in

managementul situatiilor de urgentă si facilitarea adoptării rapide a celor mai bune decizii

pentru situatiile respective. Astfel, SMISU este un sistem integrat destinat sa asigure suportul

informational necesar factorilor decizionali prin colectarea si distribuirea informatiilor despre

urgente de la / intre institutiile implicate in gestionarea acestor situatii, evaluarea situatiilor de

urgenta si a efectelor acestora, coordonării interventiei, monitorizării situatiilor, precum si

pentru elaborarea, stocarea punerii in aplicare, coordonarea planurilor si a procedurilor

standard operationale prevăzute pentru fiecare tip de situatie in parte.

Implementarea completa a SMISU, prevăzuta pentru Iulie 2009. Intre fazele incluse in acest

proiect este prevazuta si implementarea sistemului in locatii pilot, in două Centre

Operationale pentru Situatii de Urgenta la nivel national, la Bucuresti si Ciolpani, si in

Centrele Operationale Judetene pentru Situatii de Urgenta din Arad, Bihor, Botosani, Prahova

si Centrul Operational al Municipiului Bucuresti.

1.4.6.5 Subsistemul de comunicaţii

Subsistemul de comunicaţii reprezintă ansamblul elementelor de infrastructura de

comunicaţii. în componenta să vor intra toate căile de comunicaţii utilizate în vederea

transferului de date, informaţii, semnale şi mesaje atât cu celelalte subsisteme cât şi cu

celelalte entitati din cadrul SMSUB. Subsistemul de comunicaţii trebuie să asigure

compatibilitatea şi interfaţarea COMB cu sisteme de comunicaţie deja aflate în exploatare,

atât proprii cât şi a altor entităţi care pot fi implicate în cazul situaţiilor de urgentă.

Subsistemele de comunicaţii acoperă în momentul de fata toate necesităţile de comunicare

intre SMSUB şi SMISU (entitatile responsabile care iau parte la managementul situatiilor de

urgenta din Municipiul Bucuresti, structuri de interventie profesioniste si voluntare, ale

MIRA)

Subsistemul de comunicaţii prezent este realizat folosind platforme existente, respectiv

servicii dedicate, externe SMSUB. Soluţiile sunt: reţeaua de telecomunicaţii a STS şi reţeaua

proprie a MIRA (RCVD).

Functiile de baza ale sub-sistemului de comunicatii sunt:

Conexiune telefonică (şi alte servicii pe bază de telefonie cum este telefaxul) între

actorii situaţiilor de urgenţă.

Videoconferinţă

Conectare la reţelele publice fixe şi mobile precum şi la alte reţele dedicate, la care

sunt conectate prin PABX-urile existente în Centrul Operational.

Conectarea sistemelor radio profesionale existente, şi integrare totală pentru conectare

la sistem naţional Tetra prin reţeaua backbone STS.

37 / 234

Pentru a asigura utilizarea, întreţinerea şi managementul eficient al situatiilor de urgenta, sub-

sistemul de comunicatii are capacitatea de a asigura funcţionalităţile necesare şi îndeosebi:

Monitorizarea conexiunilor la reţeaua end-to-end, gestionarea şi găzduirea

evenimentului;

Configuraţia reţelei;

Utilizarea, întreţinerea şi administrarea reţelei;

Funcţii fundamentale de managementul reţelei;

1.5 Contextul legal

Necesitatea protejării populaţiei în situaţii de urgenţă, ca urmare a multiplicării şi

diversificării riscurilor de natură nonmilitară, care pot avea efecte dramatice asupra vieţii şi

sănătăţii unui mare număr de persoane, a mediului înconjurator, a valorilor materiale şi

culturale importante, precum şi pe fondul accelerării tendinţelor de globalizare, al

schimbărilor climatice radicale, al dezvoltării experimentelor ştiinţifice cu efecte

imprevizibile, al diversificării activităţilor economice legale - şi nu numai - care utilizează,

produc şi comercializează substanţe periculoase, a determinat Guvernul României să emită

Ordonanţa de urgenţă nr. 21/2004 privind Sistemul Naţional de Management al Situaţiilor de

Urgenţă, ale cărui forţe de intervenţie sunt integrate în Sistemul de Securitate Natională. Ca

instrument naţional ce dă forţă şi valoare practică acestor cerinţe, reprezintă un factor

integrator de sinteză ce se operaţionalizează printr-un ansamblu de decizii, planuri, măsuri şi

acţiuni menite să prevină şi să contracareze eficient riscurile şi ameninţările ce pun în pericol

valorile şi interesele naţionale, precum şi valorile care dau identitate şi unitate construcţiei

europene.

Sistemul de management al situaţiilor de urgenţă cu subsistemele acestuia a impus realizarea

cadrului legislativ modern în domeniul prevenirii şi gestionării situaţiilor de urgenţă, ca un

sistem instituţional parţial închegat, cu funcţionare temporară şi care se activează abia la

momentul producerii situaţiilor de urgenţă, care trebuie să permită un răspuns adecvat şi

coordonat pe timpul unui eveniment deosebit, în scopul restabilirii rapide a condiţiilor

minime de trai a populaţiei, refacere a zonelor afectate şi realizare a stării de normalitate.

Lista actelor normative care reglementeaza domeniul managementului situatiilor de urgenta

se regaseste in Anexa 2.

1.6 Structura organizatorica

1.6.1 Inspectoratul pentru Situaţii de Urgenţă „Dealul Spirii” al Municipiului

Bucureşti

38 / 234

Structurile de intervenţie ale ISUMB execută, cu forţe proprii sau în cooperare, operaţiuni şi

activităţi de recunoaştere, cercetare, evacuare, adăpostire, căutare, salvare, descarcerare,

deblocare, prim ajutor sau asistenţă medicală de urgenţă, stingere a incendiilor, protecţie a

bunurilor materiale şi valorilor din patrimoniul cultural, acordare de sprijin pentru

supravieţuirea populaţiei afectate şi alte măsuri de protecţie a cetăţenilor în caz de situaţii de

urgenţă în zona de competenţă a inspectoratului.

La momentul actual subunităţile de pompieri au raioanele de intervenţie stabilite pe principiul

„timpului de raspuns" şi nu pe principiul împărţirii administrativ-teritoriale a municipiului

Bucureşti.

Subunităţile de intervenţie ale ISUMB au raioane de intervenţie care nu se opresc la limita

administrativă a municipiului Bucureşti, acţionănd şi în judeţul Ilfov.

În continuare sunt prezentate grupurile principale de intervenţie precum şi subunităţile de

intervenţie din subordinea ISUMB:

a) Grupul Special de Salvatori

Detaşamentul Special de Salvatori

Detaşamentul Mobil de Urgenţă Reanimare şi Descarcerare

Staţia de Pompieri

Formaţiunea de protecţie civilă:

Echipa cautare salvare

Echipa cercetare

Echipa comunicaţii radio

b) Grupul de intervenţie nr. 1 de Pompieri “Lt. Col. post mortem Adrian Barbu

Detaşamentul de Pompieri ”Mihai Vodă”

Detaşamentul de Pompieri ”Pieptănari”

Detaşamentul de Pompieri ”Bujoreni”:

Garda nr.1 de intervenţie Bujoreni;

Garda nr.2 de intervenţie Păcii.

Secţia de Pompieri ”Grozăveşti”

c) Grupul de intervenţie nr. 2 de Pompieri

Detaşamentul de Pompieri ”Obor”:

Garda de intervenţie;

Garda nr. 2 de intervenţie Pache Protopopescu.

Detaşamentul de Pompieri ”Băneasa”

Detaşamentul de Pompieri ”Dămăroaia”

Secţia de Pompieri ”Fundeni”

39 / 234

d) Grupul de intervenţie nr. 3 de Pompieri

Detaşamentul de Pompieri ”Vitan”

Detaşamentul de Pompieri ”Apărătorii Patriei”

Detaşamentul de Pompieri ”Chimiştilor”

Detaşamentul de Pompieri ”Morarilor”

e) Grupul de intervenţie nr. 4 de Pompieri

Detaşamentul de Pompieri ”Palatul Parlamentului”

Detaşamentul de Pompieri ”Palatul Victoria”

Detaşamentul de Pompieri ”Expoziţiei”

Detaşamentul de Pompieri ”13 Septembrie”

1.6.2 Puncte de prezenţă operativă

Inspectoratul pentru Situaţii de Urgenţă „Dealul Spirii” al Municipiului Bucureşti şi respectiv

Inspectoratul pentru Situaţii de Urgenţă “Codrii Vlăsiei” al judeţului Ilfov au misiunea de

prevenire, monitorizare şi gestionare a situaţiilor de urgenţă care pot aparea în ariile

teritoriale deservite. Unităţilor de intervenţie operativă, desfăşurate în teritoriu, le revine

misiunea de a acţiona imediat şi cu maxim de forţe disponibile (dacă sunt necesare) la

producerea oricărui eveniment.

Conform legislaţiei în vigoare, la amplasarea în teritoriu a unităţilor şi subunităţilor

specializate în prevenţia şi intervenţia în situaţii de urgenţă se ţine seama de următoarele

aspecte operaţionale:

timpul de alertare: 1 - 3 minute, în funcţie de anotimp, indiferent că urgenţa se

producea în timpul zilei sau noaptea;

timpul de răspuns în obiective în care sunt dislocate permanent unităţi sau subunităţi:

5 – 15 minute;

timpul de răspuns în localităţile în care sunt dislocate permanent unităţi sau subunităţi:

5 – 25 minute ;

timpul de raspuns in localitatile din raionul de intervenþie in care nu se afla unitati sau

subunitati: 15 – 35 minute;

În vederea asigurării performanţelor de timp la intervenţie specificate mai sus, la

dimensionarea raioanelor de intervenţie şi amplasarea (pe cât posibil) a unităţilor şi

subunităţilor operative se au în vedere următorii parametrii:

raza raionului de intervenţie – 15 km (medie) / 30 km (maxim);

viteza medie de deplasare a autospecialelor - 60 km/h.

Dotarea serviciilor profesioniste pentru situaţii de urgenţă la nivelul fiecărei unităţi sau

subunităţi se face ţinându-se seama de următoarele:

cel putin 1 (una) autospecială pentru lucrul cu apă şi spumă pentru fiecare 10.000 -

12.000 de locuitori. În cazul obiectivelor speciale sau atunci când aria este deservită

40 / 234

de servicii publice private sau voluntare, se alocă 1 (una) autospecială pentru lucrul cu

apă şi spumă pentru fiecare 4.000 - 4.500 de locuitori;

cel putin 1 (una) autospecială de descarcerare şi cercetare de specialitate;

Date fiind condiţiile atipice ale oraşului Bucureşti (dezvoltarea demografică şi economică

explozivă, combinate cu lipsa dezvoltării corespunzătoare a infrastructurii de transport) viteza

medie de deplasare a autospecialelor poate fi mult mai mică (scăzând până la o medie de 20-

25 km/h), implicit calitatea serviciului pentru public scăzând semnificativ. În condiţiile

actuale, îmbunătăţirea serviciului pentru public se poate face prin cresterea numărului de

autospeciale de intervenţie, şi, dacă este posibil, distribuirea acestora în teritoriu, crescându-

se în acest mod, densitatea de echipaje operaţionale.

În mod real, amplasarea în teritoriu a echipajelor şi dimensionarea numarului acestora, se

face astfel încât să se îndeplinească următoarele criterii:

acoperirea riscurilor din zonele de competentă din punct de vedere preventiv şi

operaţional, avându-se în vedere concluziile reieşite din Planul de analiză şi acoperire

a riscurilor - PAAR;

corelarea cu specificul atribuţiilor stabilite prin lege şi posibilitatea extinderii sferei de

activitate din domeniul situaţiilor de urgenţă;

executarea oportuna a misiunilor, operaţiunilor şi acţiunilor specifice;

participarea la operaţiuni de intervenţie specifice, la nivel naţional şi/sau în afara

României, la solicitare sau conform acordurilor la care Romania este parte;

interoperabilitatea cu celelalte structuri destinate apararii vietii, bunurilor si protectiei

mediului, din zonele de competenţa, vecine sau din afara spaţiului naţional ori din

zonele de frontieră limitrofe;

adaptabilitatea din punctul de vedere al organizării şi desfăşurarii acţiunilor de

intervenţie;

asigurarea acoperirii din punctul de vedere al comunicaţiilor şi informaticii a zonelor

de competenţă;

Pentru cazuri speciale şi nevoi de decontaminare chimică, biologică şi/sau radioactivă, la

nivelul fiecărui inspectorat se prevăd 1-2 autospeciale de decontaminare a personalului şi 1-2

autospeciale de decontaminare pentru public, a terenului, tehnicii şi instalaţiilor.

1.6.3 Direcţia Generală de Poliţie a Municipiului Bucureşti

Participă cu forţele proprii şi tehnica din dotare la acţiunile specifice de protecţie -

intervenţie, la nivelul Capitalei.

Participă din primele momente la acţiunile de salvare şi evacuare a persoanelor şi valorilor

deosebite aflate în pericol.

Initiază măsurile ce se impun pe linia organizării circulaţiei autovehiculelor stabilind itinerare

de bază şi de rezervă pentru unitaţile care îndeplinesc misiuni speciale in zonele afectate cât

şi rute ocolitoare pentru ceilalţi participanţi la traficul rutier.

41 / 234

Supraveghează îndeaproape acţiunile de evaluare, depozitare şi asigurare a materialelor

supuse autorizării (arme, muniţii, substante toxice, explozive, radioactive) precum şi

recuperarea armamentului şi muniţiei de la deţinătorii legali care au decedat.

Asigură în timp operativ informaţiile necesare organismelor de decizie şi forţele de

intervenţie despre situaţia din raioanele cu distrugeri, în vederea creşterii eficienţei combaterii

efectelor distructive.

Asigură priorităţi de deplasare pentru mijloacele de intervenţie specifice (pompieri, protecţie

civilă, autosanitare, specialişti, etc,).

Conlucrează permanent cu organele de administrare a drumurilor pentru delimitarea,

semnalizarea şi degajarea căilor de comunicaţii afectate, în ordinea importanţei.

Supraveghează direct şi prin reţeaua informativă realitatea datelor raportate de conducerile

intreprinderilor productive şi comerciale în legatură cu pagubele cauzate, pentru prevenirea

însuşirii valorilor şi acoperirii fraudelor.

Previne şi combate specula cu produse alimentare, combustibili, medicamente şi alte produse

de strictă necesitate, precum şi stocarea nejustificată a acestor produse.

1.6.4 Direcţia de Jandarmi a Municipiului Bucureşti

Participă cu forţe şi mijloace proprii la realizarea acţiunilor specifice de protecţie-intervenţie.

Stabileşte unităţile şi formaţiunile proprii care se planifică pentru realizarea acţiunilor de

protecţie-intervenţie, în mod deosebit pentru :

paza raioanelor de adunare şi cazare a sinistraţilor şi populaţiei evacuate;

paza locurilor de adunare a cadavrelor;

paza obiectivelor afectate;

salvarea victimelor din raioanele de distrugeri;

menţinerea ordinii în locurile de adunare a sinistraţilor şi de distribuirea alimentelor

şi îmbracămintei;

limitarea accesului populaţiei în zonele afectate.

1.6.5 Serviciul de Ambulanţă al Municipiului Bucureşti

SAMB este o unitate sanitară cu un caracter de unicitate nu numai la nivelul municipiului

Bucureşti dar chiar şi la nivelul întregii ţări. Este o unitate medicală strategică cu

personalitate juridică, avand ca specific lucrul în regim de aşteptare 24 de ore din 24, 365 de

zile pe an. SAMB. este în subordinea Administraţiei de Sănătate Publică a Municipiului

Bucureşti. Serviciul de Ambulanţă al Municipiului Bucureşti asigură asistenţa medicală de

urgenţă prespitalicească atât la locul solicitarii cât şi pe durata transportului pacienţilor

(bolnavilor, accidentaţilor, gravidelor) câtre spital.

42 / 234

Pe langa aceasta SAMB asigură atât asistenţă medicală ambulatorie la locul solicitării precum

şi transporturi nemedicalizate.Transportul medicamentelor, produselor biologice (sânge şi

organe) şi al personalului medico-sanitar se face în program continuu, asigurându-se

necesarul de asistenţă medicală de urgenţă pe întreg teritoriul Municipiului Bucureşti, iar

dacă este cazul şi în afara acestuia, 24 de ore din 24 SAMB răspunde solicitărilor telefonice

venite atăt din partea populaţiei cât şi a altor unităţi medicale, la 950 de solicitări în medie pe

24 de ore.

Fiind principalul segment al asistenţei medicale ăi transportului pentru urgenţele majore în

etapa prespital, SAMB este implicată şi în asistenţă medicală preventivă a marilor aglomerări

umane cum ar fi activităţile sportive, culturale, social politice, greva foamei, asigurând

asistenţa medicală şi transportul pentru urgenţele individuale, colective şi de masă în cazul

catastrofelor.

Totodată, SAMB efectuează şi alte activităţi cum ar fi asistenţa medicală la domiciliu pentru

urgenţele de gradul 2, eliberarea de certificate constatatoare de deces în zilele de sambătă,

duminică şi sărbători legale, acordând de asemenea asistenţa medicală şi transportul la spital

pentru cazurile sociale, în lipsa unui sistem de asistenţă socială.

Pentru a asigura o mai bună rezolvare a solicitărilor, Serviciul de Ambulanţă al Municipiului

Bucureşti are organizate substaţii de ambulanţă în sectoare 1, 3, 4, 5 şi 6 sediul central fiind şi

substaţie de sector pentru sectorul 2.

Substaţiile de sector sunt conduse de medici coordonatori de substaţii şi sunt subordonate

administrativ sediului central care este situat în strada Mihai Eminescu, nr. 226, sectorul 2.

Celelalte substaţii sunt situate în sectoarele 1,3,4,5,6 la următoarele adrese:

Substaţia sector 1 - Str. Pajurei nr. 15

Substaţia sector 3 – Al. Lunca Bradului nr. 1 A

Substaţia sector 4 – Al. Iuliu Haţeganu nr. 1

Substaţia sector 5 – Str. Lereşti nr. 22

Substaţia sector 6 – Al. Crăieşti nr 1-3

Dispecerizarea şi coordonarea întregului personal operativ în teren se face din Staţia Centrală,

SAMB rezolvând toate solicitările adresate de populaţie la numărul unic de urgenţă 112,

asistată de calculator prin intermediul aplicaţiei computerizate DISPEC, perfecţionată şi

adaptată continuu pe parcursul a 9 ani, pentru a face fată specificului de funcţionare al

SAMB, pornind de la planificarea anticipată a personalului, optimizarea rezolvării cazurilor

cu echipajele corespunzătoare, până la obţinerea diverselor situaţii statistice cerute de

Ministerul Sanătăţii Publice sau de modul de funcţionare al decontării activităţii SAMB cu

Casa de Asigurări de Sănătate a Municipiului Bucureşti.

Funcţiile principale ale Sistemului Informatic aferent SAMB sunt:

o stabilire diagnostic prezumtiv, furnizare de sfaturi de prim ajutor, preluare date de

identificare pacient, semnalare solicitări duble sau triple;

o dispecerizarea solicitărilor în funcţie de :

43 / 234

o momentul înregistrării

o tipul ambulanţei şi distanţa de parcurs

o grad de urgenţă, cu menţinerea unui echilibru optim între competenţă şi

distanţă

o stabilirea necesarului şi structurii resurselor pe bază statisticilor medicale şi de

activitate (pe tură, zilnice, săptămânale, lunare, anuale)

Dotarea prezentă a SAMB cuprinde aproximativ 150 de ambulanţe, din care 24 sunt

Ambulanţe de Resuscitare şi Terapie Intensivă (ARTI) şi 21 sunt Ambulanţe de Urgenţă şi

Resuscitare (AUR), având echipajul format în funcţie de specificul activităţii de asistenţă

medicală, din 1, 2 sau 3 persoane cuprinzând: doctori, asistenţi medicali şi ambulanţieri, sunt

trimise în teritoriu pentru a rezolva cele 950 solicitări în medie pe 24 de ore, număr ce creşte

cu 30-40% în caz de epidemie sau pandemie.

Personalul medical operativ este format din aproximativ 100 medici, 190 personal mediu

sanitar (110 asistenţi, 81 operatori registratori de urgenţă - pregătiţi pentru identificare cât

mai corectă a diagnosticului prezumtiv) şi 240 ambulanţieri (şoferi instruiţi pentru a fi la

nevoie a treia persoană ce completează echipajul specializat în intervenţiile de urgenţă ale

ambulanţei). Programul de lucru al personalului este în ture (zi şi noapte).

1.7 Structuri si cadrul organizatoric – activitati in Situatii de Urgenta grave si

dezastre

Instituţiile cu atribuţii, competenţe şi responsabilităţi în managementul situaţiilor de urgenţă

in arealul operativ al ISUMB sunt:

- Instituţia Prefectului Municipiului Bucureşti

- Primăria Generală a Municipiului Bucureşti

- Primăria Sectoarelor 1-6

- Inspectoratul pentru Situaţii de Urgenţă al Municipiului Bucureşti

- Administrarea Cimitirelor şi Crematoriilor Umane

- Administraţia Lacuri Parcuri şi Agrement Bucureşti

- Direcţia Generală de Poliţie a Municipiului Bucureşti

- Direcţia Generală de Jandarmi a Municipiului Bucureşti

- Poliţia Comunitară a Municipiului Bucureşti

- Comandamentul Garnizonal Bucureşti

- Centrul Militar Zonal Bucureşti

- Oficiu de Mobilizare al Economiei şi Pregătirea Teritoriului pentru Apărare al

Municipiului Bucureşti

- Direcţia Sanitar Veterinară pentru Siguranţa Alimentelor a Municipiului Bucureşti

- Autoritatea de Sănătate Publică a Municipiului Bucureşti

- Serviciul de Ambulanţă a Municipiului Bucureşti

- Consiliul Naţional de Cruce Roşie a României

- Institutul de Medicină Legală Mina Minovici

44 / 234

- Oficiul pentru Protecţia Consumatorului al Municipiului Bucureşti

- Direcţia pentru Sport a Municipiului Bucureşti

- Direcţia de Cultură, Culte şi Patrimoniu Cultural Naţional al Municipiului Bucureşti

- Inspectoratul în Construcţii al Municipiului Bucureşti

- Inspectoratul Teritorial pentru Cazane şi Recipienţi sub presiune (ISCIR)

- Direcţia pentru Agricultură şi Dezvoltare Rurală a Municipiului Bucureşti

- Inspectoratul Şcolar al Municipiului Bucureşti

- Agenţia de Protecţia Mediului Bucureşti

- Direcţia Generală de Evidenţă a Persoanelor

- SNTFM „CFR MARFĂ” – Sucursala Bucureşti

- Regionala Căi Ferate Bucureşti

- RATB

- SC Apa Nova SA

- RADET

- SC Distrigaz – Sud SA Bucureşti

- CN Apele Române - Direcţia Apele Argeş – Vedea SGA Bucureşti

- SC Termoelectrica SA

- SC Electrica Muntenia – Sud Sucursala Bucureşti

- SC Romtelecom SA – Divizia operare reţea acces Bucureşti

- Societatea Comercială METROREX SA

- Regia Naţională a Pădurilor – Direcţia Silvică Bucureşti

- Direcţia Regională de Statistică a Municipiului Bucureşti

- Autoritatea Aeronautică Civilă Română

- Aeroportul Internaţional Bucureşti Băneasa Aurel Vlaicu SA

1.8 Componente ale reproiectarii manageriale

Integrarea sistemelor informationale existente, componente ale managementului

Situaţiilor de Urgenţă sau a sistemelor ce pot sprijini activitatile in acest domeniu

Componenta de dispecerizare operatori de rutina Sistem de alarmare – avertizare

SMISU/BEMIS, controlul traficului, banca de date urbana, Telverde PMB, NetCity,

Managementul resurselor spitalicesti, etc

Realizarea unei aplicatii software pentru suportul managementului integrat pentru

activitatile de gestionare a Situaţiilor de Urgenţă – BBEMIS (Bucharest Emergency

Management Information System)

Realizarea unui sistem suport pentru BBEMIS in scopul crearii unei Baze de Date

Operationale prin preluarea si digitizarea planurilor de actiune existente si

actualizarea permanenta a lor

45 / 234

Integrarea sistemelor de comunicaţii existente, inclusiv BTMS, sau ce urmeaza a fi

achizitionate intr-o platforma unitara pentru un management eficient in toate etapele

de gestionare a unei Situaţii de Urgenţă

Realizarea unui sistem viabil de alarmare – avertizare prin demararea activitatilor de

integrare in noul centru a sistemelor cheie si realizarea proiectului de acoperire pentru

intreaga zona metropolitana

Realizarea arhitecturii hardware pentru noul concept de integrare atat la nivelul

CMISU cat si al operatorilor de rutina sau suport si asimilarea lui in SNMSU/sistemul

national.

2 Premise si riscuri

Dupa analizarea proiectului, pentru o dezvoltare satisfacatoare au fost presupuse urmatoarele:

Angajarea totala a Contractorului fata de indeplinirea obiectivelor proiectului.

De-a lungul contractului, diferite imprejurari pot schimba scenariul initial descris in

caietul de sarcini. Contractorul trebuie sa fie dispus si gata oricand de a adapta solutia

initiala la noile cerinte cu flexibilitate si cu cele mai bune aptitudini tehnice.

Mecanismul de solicitare a unei schimbari trebuie implementat de la inceput si

explicat beneficiarului. Acest mecanism trebuie adoptat de la inceput si folosit pe tot

parcursul proiectului.

Experienta Contractorului in domeniul sistemelor de comanda si control centralizate

Complexitatea proiectului si perioada de executare limitata pretind existena

experientei corespunzatoare si inalte cunostinte cu privire la tehnologiile implicate in

zona specifica a securitatii publice si a sistemelor centralízate de comanda si control.

Experienta Contractorului in Romania

Experienta companiei, directa sau prin intermediul companiilor asociate sau

subcontractoare, in dezvoltarea proiectelor in Romania va usura inceputul proiectului

si indeplinirea aspectelor administrative si legale ale dezvoltarii proiectului.

Deplina disponibilitate si cooperare a institutiilor Primariei Municipiului Bucuresti si

a Inspectoratului pentru Situatii de Urgenta a Municipiului Bucuresti.

Obiectivele proiectului depind partial de suportul si de integrarea mijloacelor cu

diferite institutii. Acestea isi vor asuma colaborarea totala.

Un proiect precum SMISU depinde de buna functionare a institutiilor politice si

organizationale atat pe plan local cat si la nivel national. Aceasta conditie se refera la

stabilitatea institutiilor politice si administrative cat si la absenta unei perturbari

46 / 234

majore care ar putea duce la rearanjarea pe scara larga a administratiei centrale si a

organizarii interne a Primariei Municipiului Bucuresti.

Principalele riscuri identificate care pot afecta dezvoltarea si atingerea pozitiva a obiectivelor

proiectului sunt:

Perioada de executie

Exista riscul ca aceasta perioada de executie sa nu poata fi respectata.

Folosirea infrastructurii entitatiilor partenere

O parte dintre entitatiile care vor fi implicate in proiect beneficiaza de infrastructura

tehnica proprie, care va putea fi folosita, partial, in vederea indeplinirii sopului

functional si operational al proiectului. Trebuie luate din timp toate masuriile astfel

incat sa se evite o posibila indisponibilitate a acesteia.

Integrarea cu sistemele externe

Integrarea cu sistemele prezente si viitoare in cadrul SMISU este una dintre

problemele critice si in acelasi timp cea mai importanta activitate a proiectului.

Integrarea implica adapatarea si conectarea la mai multe surse de informatii astfel

incat este dorita o arhitectura care sa prezinte un grad maxim de adaptabilitate si

flexibilitate.

O atentie speciala trebuie acordata integrarii SMISU cu sisteme complementare ale

Primariei Municipiului Bucuresti (PMB), ale Primariilor de sector (PS1 – PS6), a

Inspectoratului pentru Situatii de Urgenta (ISU), a Sistemului National Unic pentru

Apeluri de Urgenta 112 (SNAU) si cu alte sisteme similare ce vor fi considerate

partenere.

Conditii meteorologice in timpul proiectului

Proiectul va fi desfasurat intr-o zona cu conditii meteorologice normale. Totusi, se va

avea in vedere faptul ca Bucurestiul poate fi expus la conditii meteorologice extreme,

de la inundatii si canicula vara pana la temperaturi extrem de scazute in tipul iernii.

Un aspect foarte important este ca tehnologia aplicata ar putea sa nu fie potrivita

pentru conditiile specifice cum ar fi severitatea si durabilitatea cerute in zona unde

este instalat echipamentul.

Resurse existente

Acest proiect se bazeaza si pe rezultatele existente la nivelul operatorilor existenti.

Se cere folosirea la maxim a facilitatilor si mijloacelor existente dar aceasta trebuie

planificata cu grija.

Lucrari civile si infrastructura

Solutia pentru implementare care va implica preluarea, imbunatatirea si desfasurarea

noilor resurse o sa implice construirea unei cladiri si multiple lucrari de organizare si

amenajare a spatiilor.

47 / 234

3 Cerinte administrare proiect

3.1 Cerinte generale

3.1.1 Responsabilitate

Contractorul este singurul raspunzator de toate activitatile si lucrarile necesare pentru a

indeplini cerintele acestui caiet de sarcini si respectarea tuturor regulilor si legilor aplicabile

in Romania necesare pentru indeplinirea activitatilor din acest Contract.

3.1.2 Locatie proiect

Lucrul asupra prezentului contract se va desfasura la locatiile Contractorului sau

subcontractorilor acestuia, cu exceptia instalarilor, lucrarilor civile si a organizarii interne. In

acest sens, contractorul va trebui sa verifice la fata locului conditiile astfel incat acestea sa fie

in conformitate cu reglementarile cu privire la siguranta si la mijloacele existente si limitari.

3.1.3 Limba oficiala

Limba oficiala este Limba Romana.

Beneficiarul poate sa ceara Contractantului pe parcursul proiectului sa livreze documentele

oficiale atat in limba romana cat si in limba engleza, in format electronic si pe hartie (cel

putin un original si o copie).

3.1.4 Drept de proprietate

Contractorul va livra toate software-urile comerciale utilizate in sistem, documentatia tehnica

aferenta si manualele de utilizare.

In situatia livrarii unor statii de lucru pentru care Ofertantul propune echipare cu software de

baza Microsoft, pentru acestea se va furniza licenta OEM pentru un sistem de operare

Microsoft Windows XP sau o versiune ulterioara.

Contractorul este responsabil pentru punerea la dispozitie a licentei aferente software-ului de

aplicatie necesar implementarii proiectului.

Softwareul de aplicatie anterior mentionat devine proprietatea intelectuala neconditionata a

Beneficiarului. Nu se admit solutii in cadrul carora sa se pretinda licente suplimentare

ulterioare in cazul dezvoltarii software-ului dupa finalizarea contractului.

48 / 234

Orice modificari ale software-ului de aplicatie pe care Beneficiarul le solicita in perioada de

garantie a produsului respectiv se vor realiza de catre Contractant fara costuri suplimentare in

raport cu cele agreate prin contract la data semnarii acestuia.

Toate rezultatele provenite in baza prezentului Contract reprezinta proprietatea Autoritatii

Contractante dupa livrare.

3.1.5 Inspectii

Autoritatea Contractanta va avea dreptul de a inspecta si verifica executia tehnica si conditiile

de dezvoltare a contractului in orice moment.

Autoritatea Contractanta pentru a-si exercita acest drept si de a asista la inspectii si teste ce

vor fi desfasurate de catre Contractor, va avea dreptul de intra in locatiile, premisele

comerciale si de productie ale Contractorului. Administratia va avea dreptul sa:

Inspecteze achizitionarea inainte de livrarea acesteia, la locatiile Contractorului si/sau

furnizorilor.

Inspecteze achizitionarea odata ce a fost livrata, in conformitate cu cerintele prevazute

in contract.

In cazul in care Beneficiarul si Contractorul nu agreeaza rezultatele in urma testelor sau

inspectiilor, fiecare dintre partile contractante va prezenta propria opinie in decurs de 15 zile

de la aparitia unei astfel de dispute. Cientul sau Contractorul pot cere repetarea unor astfel de

teste in aceleasi conditii si termene sau, daca oricare dintre Partile contractante o cere, de

catre un expert desemnat de comun acord. Rezultatele retestarii vor fi concludente. Costul

aferent acestor retestari va fi suportat de catre Partea contractanta a carui opinie s-a dovedit

gresita.

3.2 Activitati conexe proiectului

3.2.1 Intalnire initiala

Acesta se va organiza nu mai tarziu de o saptamana de la semnarea Contractului, pe durata

intalnirii, reprezentantii Autoritatii Contractanta si Contractorul vor prezenta detalii cu privire

la lucrarea ce va fi executata pe tot parcursul implementarii prezentului proiect.

Urmatoarele elemente for fi luate in discutie in cadrul acestei intalniri:

Infrastructura proiectului (de unde si cum va fi condus si livrat proiectul)

Organizarea Biroului Program (Program Office) Contractorului (personal-cheie,

domenii de responsabilitate, elemente de contact etc.)

Furnizori avuti in vedere.

Riscurile majore identificate si planuri de evenimente neprevazute.

Nevoi sau asistenta asteptata de catre Beneficiar.

49 / 234

Contractorul va elabora un Proces Verbal al Intalnirii pentru a prezenta pe scurt activitatea.

3.2.2 Intalniri periodice de monitorizare

Cu o periodicitate de o luna, in fiecare Intalnire periodica de monitorizare, Contractorul isi va

asuma urmatoarele sarcini:

Sa informeze cu privire la statutul activitatilor si posibilelor deviatii de la calendarul

planificat.

Sa raporteze starea aprovizionarilor esentiale.

Sa informeze cu privire la activitatile pe termen scurt.

Sa prezinte riscurile identificate si actiunile adoptate.

Posibile necesitati pentru perioada urmatoare.

Se pot organiza intalniri suplimentare in cazul in care oricare din partile contractante

considera necesar.

Contractorul va elabora un Proces Verbal al Intalnirii pentru a rezuma aceste activitati.

3.3 Analiza si Managementul Riscurilor

Contractorul va desfasura pe durata intregului Proiect o politica de management al riscurilor

in vederea luarii in considerare a urmatoarelor aspecte:

Identificarea si urmarirea potentialelor riscuri.

Identificarea solutiilor si alternativelor de evitare, reducere sau control al riscurilor.

Punerea in practica a solutiilor.

Informatiile privind aceasta activitate vor fi cuprinse in Planul de management al Proiectului

si luate in discutie in cadrul intalnirilor periodice.

3.4 Arhiva centrala a Proiectului

Contractorul va clasifica, stoca si controla toate documentatiile livrate in Arhiva Centrala a

Proiectului. Aceasta va cuprinde documente precum:

Documente si corespondenta aferenta Proiectului (faxuri, scrisori, curier)

Rapoarte interne si documente (rapoarte privind calitatea, teste interne, contracte,

resurse umane, securitatea personalului, securitate si confidentialitate, asigurari etc.)

Reprezentantii Beneficiarului vor avea acces deplin la acest fisier, care va trebui sa fie pus la

dispozitie in decurs de 5 zile de la incheierea proiectului.

Informatiile privind aceasta activitate vor fi incluse in Planul de Management de Proiect.

3.5 Control asupra configurarii

50 / 234

Toate elementele sistemului (de natura hardware si sofware) vor fi inregistrate intr-un registru

central cu o politica de control definita a rezultatelor livrabile ale proiectului.

Contractorul va dispune de o Organizare de management al configurarii care va fi parte din

resursele umane ale proiectului. Informatiile referitoare la aceasta activitate for fi incluse in

Planul de management de proiect.

3.6 Managementul calitatii

Contractorul va avea un Grup de asigurare a calitatii care va face parte din resursele aferente

proiectului. Acest grup va fi independent din punct de vedere tehnic si administrative pentru

functiile de Productie si Inginerie ale proiectului.

Politica ce vizeaza calitatea pentru proiect se va dezvolta in cadrul unui Plan al calitatii, care

va fi livrat nu mai tarziu de trei luni de la data semnarii contractului.

Organizatia pentru Asigurarea Calitatii va fi responsabila cu elaborarea si executarea Planului

calitatii.

Contractorul va informa reprezentantii Beneficiarului cu privire la indeplinirea Planului

calitatii in cadrul intalnirilor periodice.

Fisierele de calitate vor contine informatii relevante cu privire la controlul calitatii si testele

interne, care vor fi la dispozitia reprezentantilor Beneficiarului.

3.7 Planul de securitate industriala

Contractantul are obligatia de a incheia impreuna cu Beneficiarul un Acord de

Confidentialitate in cel mai scurt timp de la intrarea in vigoare a Contractului.

In cadrul Planului de management al proiectului, Contractantul va prezenta reprezentantilor

Beneficiarului, pentru aprobare, un Plan de securitate industriala care va viza, cel putin,

urmatoarele aspecte:

Proceduri pentru protejarea facilitatilor in care se vor desfasura activitatile ce privesc

contractul, bunurile si echipamentele aferente, inclusiv tranportul partilor componente

intre locatii.

Un set de proceduri pentru tratarea, distribuirea si salvarea informatiilor secrete.

O relatie a personalului care va lucra si care va avea acces la Proiect si la nivele de

securitate.

Documentele se vor dezvolta si proteja avand in vedere nivelul de securitate a informatiilor

secrete. Contractorul va fi raspunzator pentru administrarea si obtinerea autorizatiilor de

securitate pentru personalul care va fi implicat in proiect, inainte de inceperea activitatilor.

Contractorul, comerciantii si producatorii vor avea contractele necesare de securitate pentru

desfasurarea sarcinilor ce le revin in baza Contractului.

51 / 234

3.8 Managementul logistic

Contractorul va prezenta reprezentantilor Beneficiarului, pentru obtinerea unei aprobari, un

Plan integrat de suport logistic (ILSP). Acest Plan va acoperi un intreg ciclu de viata al

sistemului si va fi livrat nu mai tarziu de sase luni de la incheierea contractului.

ILSP va include urmatoarele elemente care vor fi detaliate in documente separate:

Analiza suportului logistic.

Analiza costului aferent unui ciclu de viata.

Mentenanta.

Furnizare.

Suport locatii.

Personal si training.

Elemente neutilizate.

Contractorul va include in ILSP sarcinile, Planul, punctele de referinta, lista de documente si

responsabilitatile in executarea activitatilor ILS.

Contractorul va calcula nivelul de exactitate a fiecarui element al sistemului in conformitate

cu IEC/TR 62380, MIL-HDBK-217F sau cu un normativ echivalent.

Contractorul va planifica toate sarcinile necesare in vederea demonstrarii faptului ca Sistemul

este in conformitate cu cerintele privind nivelul de exactitate.

Ofertantul va pune la dispozitie pentru implementarea proiectului un specialist in ciclul de

viata al proiecteleor cu calificari si abilitati care sa demonstreze managementul securităţii -

prin certificate cum ar fi Certified Information Security Manager – CISM/Certified

Information Systems Security Professional – CISSP sau echivalent), expertiza in auditul

sistemelor informatice – prin certificate cum ar fi Certified Information System Auditor –

CISA sau echivalent, bune practici în domeniul IT- măsurarea indicatorilor proceselor şi a

sistemelor informatice – prin certificate cum ar fi Control OBjectives for Information and

related Technology – COBIT sau echivalent, expertiza in adminstrarea si controlul sistemelor

informatice – prin certificate cum ar fi Certified in the Governance of Enterprise IT – CGEIT

sau echivalent), si in managementul serviciilor IT – certificare Information Technology

Infrastructure Library – ITIL Expert sau echivalent. Specialistul va avea experienţă relevantă

în domeniu IT&C de minim 5 ani si experienţă practica dovedita prin participarea la cel

puţin un proiect în calitate de auditor de sisteme informatice informatice complexe (dovedita

prin recomandari de la beneficiari)

3.9 Management de proiect

Contractorul va fi responsabil pentru executarea unui set de activitati care pot fi clasificate in

conformitate cu urmatoarele criterii:

Activitati administrative si de suport pentru dezvoltarea sistemului (activitati

orizontale), care cuprind:

o Organizarea programului birourilor.

o Sedinte periodice.

52 / 234

o Planificare management si aducerea periodica la zi.

o Identificarea management-ului riscurilor si activitati de control.

o Documentatie.

o Activitati de control configuratie.

o Controlul calitatii.

Activitati direct asociate cu succesiunea lucrarilor de proiect (activitati verticale), care

cuprind:

o Analiza cerintelor de sistem

o Proiectarea sistemului conceptual. In aceasta etapa, Contractorul va diviza

sistemul in elemente de configurare hardware (ECH) si elemente de

configurare software (ECS).

o Proiectare preliminara. In aceasta etapa, Contractorul va asocia cerintele

tehnice din Caietul de sarcini cu cerintele tehnice ale fiecarui ECH siECS.

o Proiectare detaliata. In aceasta etapa, Contractorul va proiecta ECH-urile si

ECS-urile in conformitate cu cerintele asociate intre ele.

o Productia/achizitia, integrarea si testarea echipamentului si software-ului.

o Instalare si teste la fata locului.

o Tranzitie, pe perioada acestei etape, sistemul va incepe sa fie operativ.

o Activitati de garantie definite in paragraful referitor la suportul logistic

integrat din Caietul de sarcini.

Ofertantul va pune la dispozitie un expert manager de proiect cu certificare Project

Management Professional - PMP, Projects IN Controlled Environments 2 - PRINCE2 sau

echivalent, Certificare Information Technology Infrastructure Library – ITIL Foundation sau

echivalent, Certificare Management of Risk M_o_R Practitioner, Risk Management

Professional – RMP PMP sau echivalent. Expertul trebuie sa fie absolvent de studii

superioare în domeniul IT&C cu o experienţă relevantă în domeniu IT&C de minim 5 ani, si

sa aiba o experienta practica rezultata din coordonarea (in calitate de Team Leader / Manager

de proiect) a cel putin 1 proiect privind sisteme informatice complexe.

3.10 Mentenanta

Contractorul va prezenta MP (Planul de Mentenanta) reprezentantilor Beneficiarului pentru

aprobare.

MP va cuprinde cel putin:

O descriere a nivelurilor de mentenanta (“O”, “I” si “D”, in conformitate cu

documentatia Caietului de sarcini)

O descriere a sarcinilor privind Mentenanta preventiva, frecventa, durata, masurile

pentru obtinere si toate instrumentele necesare fiecarui nivel de mentenanta.

Stocurile de piese de schimb si infrastructura si locurile de depozitare ale acestora.

3.11 Furnizare

53 / 234

Contractorul va oferi un set de piese de schimb care vor garanta calitatea serviciului si

cerintele de mentenanta, in conformitate cu specificatiile tehnice incluse in documentatia

Caietului de sarcini. Lista pieselor de schimb va fi pusa la dispozitie ca parte integranta a

Planului integrat de suport logistic.

3.12 Locatii suport

Contractorul trebuie sa identifice toate punctele de contact pentru mentenanta elementelor

oferite de sistem.

3.13 Personal si training

Contractorul va pregati o serie de cursuri de instruire care vor include cel putin urmatoarele

aspecte:

Programe teoretice si practice pentru operatorii de sistem in conformitate cu

raspunderile fiecaruia dintre acestia.

Planificare, locatie si lista de subiecte de abordat.

Training specificatii mijloace, documentatie si infrastructura de training.

Contractorul va furniza toate resursele necesare.

3.14 Piese inutile

Toate piesele inutile sau care raman in plus sau consumabile provenind din contract vor

ramane in proprietatea Beneficiarului dupa incheierea perioadei de garantie.

3.15 Referinte de control al proiectului

Executarea proiectului va fi controlata printr-o serie de referinte, care vor permite controlul

executarii proiectului.

Revizuirile ce urmeaza sa se efectueze de catre Contractor cu aprobarea Beneficiarului vor fi:

PDR (Revizuirea de proiectare preliminara), a cuprinde:

o Revizuirea cerintelor identificate si stabilirea faptului ca nu exista discrepante

sau dispute intre Administratie si Contractor.

o Evaluarea arhitecturii hardware, a structurii HCE si SCE de intrerupere a

sistemului si relatia cu cerintele tehnice fata de cerintele HCE si SCE si

operatiile manuale si riscurile asociate cu solutia propusa.

o Revizuirea cerintelor HCE si SCE.

PDR se va efectua pentru fiecare element in vederea:

54 / 234

o Evaluarii progresului si monitorizarea riscurilor cocentrarii proiectarii

sistemului.

o Determinarii compatibilitatii de conceptie cu cerintele de configurare a

elementului.

o Determinarii interfetelor fizice si functionale intre elementele de configuratie

si alte elemente hardware si software, locatii si personal.

o Evaluarii integrarii solutiei sistemului extern.

Contractorul va livra cu 15 zile in avans fata de referinta PDR documentele necesare.

CDR (Revizuirea de baza a Proiectului)

Revizuirea de baza a proiectului se va implementa pentru fiecare element de configuratie sau

set de elemente de configuratie si va urmari:

o Determinarea faptului ca proiectul de baza al elementului de configuratie

satisface cerintele incluse in specificatiile aferente.

o Evaluarea compatibilitatii proiectului de baza al elementului de configurare cu

alte elemente, echipamente, locatii sau personal.

o Evaluarea domeniilor de risc ale elementului de configurare (la nivel ethnic

logistic, economic si de planificare).

o Evaluarea rezultatelor analizelor tehnice hardware ale sistemului.

Contractorul va livra cu 15 zile in avans fata de referinta CDR documentele necesare.

SAT (Test acceptanta sistem)

Referintele cuprind productia, dezvoltarea si testarea sistemului si vor revizui:

o Determinarea faptului ca toate sistemele sunt dezvoltate si pregatite sa inceapa

operarea.

o Evaluarea rezultatelor in urma diferitelor teste.

o Evaluarea rezultatelor in urma cursurilor de instruire.

o Revizuirea documentelor livrabile.

Contractorul va livra cu 15 zile in avans fata de referinta SAT documentele necesare.

3.16 Lista de documente ce vor fi livrate Contractorului

Aceasta sectiune contine o lista minima de documente tehnice si rapoarte ce vor fi emise de

catre Contractor pe durata proiectului. Toate aceste documente vor fi revizuite de catre

Beneficiar si trebuie aprobate de acesta pentru a putea fi considerate valide.

Lista de documente ce vor fi livrate va fi inclusa din Planul de management de proiect.

Management de proiect

Document Acronim Referinta

55 / 234

Plan de management de proiect PMP PDR

Planul calitatii QPN PDR

Planul de suport logistic integrat ILSP CDR

Procese-verbale in urma sedintelor All

Ciclu de viata al proiectului

Document Acronim Referinta

Raport de analiza a sistemului SAR PDR

Document de specificatii de sistem SSD PDR

Proiectare document sistem/segment SSDD PDR

Plan test Hardware si Software HST PDR

Revizuire proiectare preliminara PDR PDR

Plan lucrari civile si instalatii ICW CDR

Revizuirea de baza a proiectului CDR CDR

Descrierea detaliata a interfetelor externe EIDD SAT

Descrierea detaliata a bazei de date DDD SAT

Protocoale test de acceptanta ATP-uri SAT

Istoric test acceptanta ATL-uri SAT

Plan de mentenanta MPN SAT

Plan de instruire TPN SAT

Manual administrator de sistem SAM SAT

Manual supraveghetor sistem SSM SAT

Manual operator sistem SOM SAT

Manual de intretinere sistem SMM SAT

56 / 234

Certificat de conformitate CoC Livrare sistem

Raport de incheiere a perioadei de

garantie PGER Garantie

Propunere de intretinere --- Garantie

3.17 Planul de continuitate a activitatii

PLAN.1 In cadrul documentului Proiect Preliminar, va fi nevoie sa se specifice Planul

de continuitate a activitatii, urmand aceste activitati:

a. Identificarea Riscului

b. Asumarea Riscului

c. Desemnarea prioritatilor in aplicatii

d. Stabilirea cerintelor pentru recuperare

e. Documentatia

f. Verificare si Implementare

g. Distributie si mentenanta

PLAN.2 In timpul prioritizarii aplicatiilor si mai ales in cazul stabilirii cerintelor de

recuperare, va fi necesar detaierea procedurilor pentru recuperarea datelor a fiecarei

aplicatii si rolul fiecaruia in sisteme diferite in situatii diferite de avarii (CMISU,

MCCC, BRS…)

4 Cerinţe de construcţii şi instalatii

4.1 Cerinţe generale

CIV.1 Contractantul va asigura toate lucrariile de proiectare, constructie, amenajare

si finisare a cladirii construire in scopul proiectului, conform specificatiilor din

prezentul caiet de sarcini si din Anexa 4.

CIV.2 Centrul de comandă şi control va fi operational 24 de ore pe zi / 7 zile pe

săptămână.

CIV.3 Contractantul va fi responsabil cu instalarea şi integrarea tuturor elementelor

incluse în acest Contract, şi va adapta facilităţile şi echipamentele existente sau pe

care le furnizează Beneficiarul.

CIV.4 În concordanţă cu solicitarea beneficiarului, Centrul de comandă şi control va

include de asemenea şi birourile administrative şi alte facilitaţi.

CIV.5 Contractantul va furniza o specificaţie de proiectare care va defini exact

proiectul şi adaptările propuse pentru camera.

CIV.6 Contractantul va dezvolta un plan complet (construcţii, servicii, funcţionalitate

şi altele) şi îl va trimite Beneficiarului spre aprobare

57 / 234

CIV.7 Toate proiectele, planul, adaptările şi echipamentele trebuie mai întâi aprobate

de către Beneficiar. Toate specificaţiile, planurile sau lucrările care au nevoie de

aprobarea Beneficiarului vor fi făcute numai după ce Constructorul obţine toate

aprobările scrise de la Beneficiar.

CIV.8 Planurile vor include funcţionalitatea, strategii ergonomice şi de siguranţă în

vederea asigurării condiţiilor optime de lucru pentru întreg personalul şi eficienţă

maximă în ceea ce priveşte spaţiul şi funcţiunile operaţionale. Contractantul va

dezvolta aceste strategii şi le va trimite Beneficiarului spre aprobare.

CIV.9 Sistemele instalate vor fi standarde deschise, astfel incat adăugarea altor

sisteme sa nu necesite reconfigurare semnificativă. In concordanţă cu acest lucru,

Contractantul va lua în considerare sistemele şi proiectele existente şi va dezvolta

proiectul în aşa fel încât să fie perfect compatibil cu acestea.

CIV.10 Toate construcţiile şi adaptările pentru Centrul de Comandă şi Control trebuie

realizate în concordanţă cu o strategie de extindere, oferind cât de multe capacităţi

posibile pentru instalarea viitoare a noilor echipamente.

58 / 234

4.2 Centrul Municipal Integrat pentru Situatii de Urgenta

4.2.1 Generalitati

CCC.1 Constructorul trebuie să livreze un Centru de Comandă şi Control complet, adaptat şi

organizat, denumit in continuare Centrul Municipal Integrat pentru Situatii de Urgenta.

Constructorul va efectua toate lucrarile necesare, in conformitate cu cerintele Beneficiarului

si prezentul caiet de sarcini.

CCC.2 Constructorul trebuie să execute toate propunerile, desenele, proiectele, si lucrările de

constructie si finisaje pentru livrarea Centrului de Comandă şi Control.

CCC.3 Centrul de Comanda va fi implementat intr-o cladire dedicata, precizata in prezentul

Caiet de Sarcini si care va fi amenajata corespunzator.

CCC.4 Contractantul trebuie sa realizeze propunerea pentru modelul Centrului de Comandă

şi Control, care va fi trimisă pentru comentarii şi aprobare Beneficiarului.

CCC.5 Cladirea va include cel putin camerele si spatiile specificate in prezentul caiet de

sarcini. Suplimentar, Beneficiarul va putea sa solicite realizarea de noi spatii sau facilitati in

interiorul cladirii, conform necesitatilor.

CCC.6 Constructorul va fi responsabil pentru pregatirea si realizarea in detaliu a

informatiilor si proiectelor aferente constructiei astfel incat acestea sa permita realizarea

constructiei in conformitate cu normele si regulile privitoare la constructiile civile. Astfel,

constructorul va realiza un proiect de arhitectura si simulari aferente, precum si proiectele de

lucrari, rezistenta, instalatii electrice, instalatii termice si sanitare, ventilatie etc.

CCC.7 Toate proiectele vor fi transmise catre Beneficiar. Inaintea inceperii oricaror lucrari,

proiectele vor trebui aprobate de catre Beneficiar. In caz de necesitate, Beneficiarul poate

solicita modificari sau adaugiri la proiectele prezentate.

CCC.8 Constructorul va fi responsabil de obtinerea tuturor avizelor si a autorizatiilor

conform dispozitiilor in vigoare in scopul desfasurarii lucrarilor.

CCC.9 Constructorul va realiza toate lucrariile de constructii, instalatii, amenajari si finisaje,

interior si exterior.

CCC.10 Toate lucrariile vor fi prezentate initial in proiectul tehnic transmis catre Beneficiar si

aprobat de acesta. Nu se accepta desfasurarea de lucrari inaintea aprobarii proiectului.

CCC.11 Toate lucrariile, amenajarile si finisajele vor fi efectuate numai in conformitate cu

proiectul aprobat.

CCC.12 In exteriorul cladirii trebuie amplasat un container special cu protectie TEMPEST

care va fi utilizat pentru amplasarea echipamentelor aferente solutiei de securitate logica.

Cerintele pentru container si solutia de securitate logica se regasesc in cadrul fiselor tehnice.

4.2.2 Cerinţele de proiectare

Toate lucrarile vor fi executate in conformitate cu Anexa 4.

4.2.3 Cerinţele de executie

Toate lucrarile vor fi executate in conformitate cu Anexa 4.

4.2.4 Cerinţe privind amenajarile interioare

Toate lucrarile vor fi executate in conformitate cu Anexa 4

59 / 234

4.2.5 Cerinte privind securitatea la incendiu

Toate lucrarile vor fi executate in conformitate cu Anexa 4

4.2.6 Alimentare cu energie electrica

4.2.6.1 Sursa ne-intreruptibila (UPS)

ENERGO.1 Alimentarea cu energie electrica va fi organizat in doua nivele: statie de curent

(UPS) si generator.

ENERGO.2 UPS-ul va trebuie sa asigure continuu curentul electric, fara timpi-morti

(circuitele de comutare trebuie sa fie 100% electronice cu sisteme de fiabilitate ridicata)

ENERGO.3 Nivelul de statie de curent va include un grup de baterii de back-up, ce vor

incarca sistemul si un invertor de curent. Invertorul va fi integral electronic, fara nici un

element de comutare electro-mecanic pentru linia de furnizare a curentului. Comutarea

se va realize in sincron cu linia de furnizare a curentului, intr-un timp foarte mic(mai

putin de 3 ms).

ENERGO.4 Toate echipamentele de back-up al curentului vor fi amplasate in camera

tehnica.

ENERGO.5 Din motive de siguranta, camera in care se afla grupul de baterii va fi echipat

cu senzori specifici de gaz si sisteme de ventilatie automatice.

ENERGO.6 Aerul si circuitul de ventilatie al acestei camere va fi absolut diferit si

independent de celelalte sisteme ale cladirii.

4.2.6.2 Generatorul de curent

ENERGO.7 Generatorul de Curent va fi creat pe o platforma standard, cu un motor pe

combustibil si un generator tri-fazic. Din motive de eficienta si fiabilitate motorul va fi

unul Diesel.

ENERGO.8 Generatorul de Curent va fi capabil sa porneasca automat in momentul in care

sistemul UPS are un nivel scazut de curent (un algoritm de pornire va fi stabilit in

conformitate cu specificatiile tehnice ale UPS-ului), avand capacitatea de a alimenta cu

curent intreg centrul de comanda, facilitatile adiacente si bateriile UPS-ului. Generatorul

se va opri numai dupa ce sursa de curent principala reporneste sau in momentul cand

bateriile sunt reincarcate cu cel putin 90% din capacitatea nominala.

ENERGO.9 Generatorul va fi capabil sa functioneze continuu, la capacitate maxima,

pentru cel putin 3 zile. Alta facilitate a generatorului va fi aceea de a putea fi umplut cu

combustibil (diesel) chiar si in conditii de functionare (contructorul se va asigura de toate

conditiile necesare pentru aceasta umplere de combustibil sa se realizeze in siguranta).

ENERGO.10 Generatorul va fi echipat cu sisteme de reducere a zgomotului si absorbtie a

vibratiilor astfel incat sa nu devina un factor de tulburare a activitatii in Centru de

Comanda si Control. Deasemenea, sistemul de evacuare va avea tevi si filtru conform

normelor ecologice actuale.

ENERGO.11 Din motive de siguranta, camera in care se afla generatorul de curent va fi

echipat cu senzori specifici de gaz si sisteme de ventilatie automatice.

60 / 234

ENERGO.12 Aerul si circuitul de ventilatie al camerei generatorului va fi absolut diferit si

independent de celelalte sisteme ale cladirii.

5 Arhitectura sistemului

5.1 Sistemul de comunicatii

5.1.1 Reteaua locala de date (LAN)

LAN.1 Infrastructura pentru reteaua LAN va fi realizata prin cablare structurata FTP

cat.6 sau superior.

LAN.2 Reteaua trebuie sa permita o utilizare de 365 de zile pe an, 24 de ore pe zi si sa

poata fi extinsa conform standarelor in vigoare.

LAN.3 LAN-ul trebuie sa asigure comunicatiile intre toate echipamentele conectate in

CMISU, cum ar fi:

a. Servere si statii de lucru;

b. Sistem de comunicatii voce;

c. Sistem video;

d. Periferice;

e. Acces la internet utilizand o conexiune disponibila.

LAN.4 LAN-ul trebuie sa asigure comunicatii sigure intre utilizatori, periferice si

servere in toate sub-retelele din CMISU, cel putin pentru urmatoarele:

a. Reteaua core;

b. Reteaua de distributie;

c. Reteaua de utilizatori.

LAN.5 Criteriile de proiectare pentru LAN trebuie sa fie:

a. Disponibilitate mare;

b. Redundanta;

c. Viteza de procesare mare;

d. Arhitectura flexibila referitoare la modificari si reconfigurari;

e. Performanta inalta;

f. Timp de intarziere redus;

g. Clasificare dupa tipul de traffic si efectivul de utilizatori;

h. Flexibilitate de traffc inalta folosind resurse dedicate;

i. Capabilitati de definire de VLA-uri;

LAN.6 Ofertantul trebuie sa specifice echipamentele de retea active necesare sa

indeplineasca cerintele de mai sus, specificand switch-urile, bridge-urile, router-ele,

load balancer-ele sau alte echipamente estimate.

LAN.7 Ofertantul trebuie sa puna la dispozitie un expert comunicatii cu certificari

profesionale in domeniu respectiv Cisco Certified Network Professional (CCNP) sau

echivalent, Cisco Certified Network Associate (CCNA) sau echivalent, Juniper

Networks Certified Internet Associate (JNCIA) sau echivalent, Juniper Networks

Certified Internet Specialist (JNCIS) sau echivalent. Expertul trebuie sa aiba

61 / 234

experienta profesională în domeniul de minim 1 an si sa fi particpat in cel puţin 1

proiect privind sisteme informatice complexe

5.1.2 Reteaua locala de comunicatii voce

VOCE.1 Sistemul de comunicatii voce va opera pe platform fizica a retelei LAN,

folosind comunicatii digitale, standard VoIP.

VOCE.2 Centralizarea comunicatiilor de voce se va face folosind un echipament

dedicat, tip centrala telefonica, digital, instalatat in sectiunea de echipamente, numit

PBX.

VOCE.3 Sistemul PBX ofera servicii de telefonie interne si externe catre operatori si

utilizatori.

VOCE.4 Toti operatorii si utilizatorii din CMISU vor avea terminal IP interoperabil cu

PBX-ul.

VOCE.5 PBX-ul va trebui sa indeplineasca cerintele minim necesare conform fisei

tehnice.

VOCE.6 Teminalul de voce IP va trebui sa indeplineasca cerintele minim necesare

conform fisei tehnice.

5.1.3 Comunicatiile BEMIS (COM-BEMIS)

5.1.3.1 Performante si caracteristici

Sub-sistemul de comunicatii al BEMIS (COM-BEMIS) va acoperi cel putin urmatoarele

caracteristici:

BCOM.1 Flexibil, platform stabile pentru apelurile de urgenta si monitorizarea traficului

in circuitul radio;

BCOM.2 Pregatit pentru viitoarele dezvoltari;

BCOM.3 Interfata universala si bine definita pentru solutii de securitate;

BCOM.4 Panou de Comanda customizabil dupa cerintele clientului-utilizator (usor de

familiarizat pentru dispeceri);

BCOM.5 Sistem modern de telecomunicatii cu atribute de performanta;

BCOM.6 Interfata sistemului va fi deschisa, astfel incat sa poata fi integrata sau extinsa

si de alti producatori de solutii, sisteme si/sau aplicatii;

BCOM.7 Conexiunea audio nu va avea intarzieri;

BCOM.8 Control facil;

BCOM.9 Monitorizarea Controlului Acces;

BCOM.10 Sistem de monitorizare a comunicatiilor;

BCOM.11 Anunturi digitale de pentru apelanti (in asteptare, stare apel etc.);

BCOM.12 Conexiune radio digitala cu VoIP sau ISDN;

BCOM.13 Integrarea facilitatii de diversitate primire/trimitere in interfata;

BCOM.14 Monitorizarea statiei radio si schimbarea de la distanta in retelele radio

posible;

BCOM.15 O multitudine de retele fall-back, redundanta mare prin constructia speciala;

BCOM.16 Alocarea controlului inteligent pentru fiecare statie asigurand operarea

continua in caz de nefunctionare a unei statii;

BCOM.17 Conexiune simpla a distributiei locatiilor monitorizate cu ISDN (S0 sau S2M);

BCOM.18 Interfata cu modul de dispecerizare Tetra;

BCOM.19 Activarea locatiilor IP monitorízate;

62 / 234

BCOM.20 Baza de date de abonati (tip agenda telefónica) integrata, cu functii flexibile de

cautare;

BCOM.21 Interfata pentru sisteme de loguri;

5.1.3.2 Sub-Sistemul de control al comunicatiilor integrate (ICOM-BEMIS )

ICOM.1 Acest sistem va integra comunicatiile radio PMR, radio TETRA, analogice si

de telefonie (de toate tipurile utilizate de operatori si autoritati la nivelul Municipiului

Bucuresti).

ICOM.2 Pentru a fi posibil sa directioneze angajatii rapid si eficient, autoritatile publice

si organizatiile de securitate au nevoie de centre de comanda echipate adecvat. Toate

apelurile de urgenta trebuie sa fie coordonate si directionate printr-un sistem central de

comunicatii.

ICOM.3 Sistemul integrat digital de dispecerat este un sistem modular digital de

comunicatii cu numeroase posibilitati de extindere cat si garantia de functionare pentru

tehnologiile viitoare. Arhitectura sistemului inegrat de dispecerat trebuie sa fie o

platforma foarte flexibila si extreme de stabile pentru coordonarea apelurilor de

urgenta si grupurile de radio comunicatii.

ICOM.4 Sistemul integrat digital de dispecerat trebuie sa fie complet compatibil cu

sistemul Tetra; trebuie sa integreze infrastructura Tetra, sistemul radio conventional,

indiferent de echipamentul uitilizat, sistemul de telefonie si sistemul de avertizare.

ICOM.5 Interconectarea centrului de comanda cu centrul de comanda Tetra este

realizata cu conexiuni multiplex ISDN (E1) pentru transmiterea vocii si controlul

informatiilor si de asemenea cu o conexiune IP pentru accesarea serviciilor de la un

server Tetra.

ICOM.6 Prin implementarea acestei interfete, centrul de comanda va oferi posibilitatea

folosirii tuturor functiilor unei retele Tetra. Toate caracteristicile canalelor radio

analogice si ale sistemelor radio digitale TETRA vor fi prezente.

ICOM.7 Utilizatorii potentiali ai sistemului radio digital TETRA Trunking sunt in

principiu organizatiile de securitate si autoritatile publice (pompieri, politie, serviciile

de urgenta, justitia, armata, si apararea civila) precum si grupuri de civili inchise ca

serviciile de transport, aeroporturi sau companiile energetice. Multe din aceste grupe

de utilizatori in acest moment isi organizeaza sistemul radio TETRA trunking pentru

dispecerat si au integrat reteaua radio digitala in sistemele lor radio si in gestionarea

apelurilor de urgenta.

ICOM.8 Sistemul va avea cel putin un Switch dedicat sistemului de comunicatii care va

trebui sa indeplineasca cerintele minim necesare conform fisei tehnice.

ICOM.9 Sistemul trebuie sa permita comanda manuala a sistemului de comunicatie

din BEMIS (ofertantul trebuie sa descrie functionalitatile si interfata de utilizator).

ICOM.10 Sistemul trebuie sa permita comanda automata a sistemului de comunicatie

din BEMIS ( ofertantul trebuie sa descrie functionalitatile si interfata de utilizator).

Integrare cu infrastructura TETRA pentru trasmisii de date si voce.

ICOM.11 Sistemul trebuie sa integreze cel putin urmatoarele functii TETRA in BEMIS:

• apel individual;

• apel grup;

• apel urgenta;

• grup dinamic (DGNA);

• transmitere/ receptie mesaje SDS;

• localizare automata a vehiculelor ( AVL);

63 / 234

• ascultare ambientala;

• monitorizare audio;

• monitorizare eveniment;

• localizarea utilizatorului.

ICOM.12 Pentru sustinerea indeplinirii cerintelor ICOM ofertantul va prezenta descrieri

succinte si referinte din partea utilizatorilor pentru minim 3 sisteme cu functionalitati

similare deja instalate

5.1.3.3 Comunicatii prin satelit

SCOM.1 Se va livra un sistem de comunicatii prin satelit, care este compus dintr-o

statie fixa pe cladirea CMISU.

SCOM.2 Sistemul de comunicatii prin satelit va permite efectuarea de comunicatii in

orice loc unde a aparut o urgent si va garanta:

a. Comunicatii voce;

b. Comunicatii IP tehnice;

c. Videoconferinta;

d. Scalabilitate.

SCOM.3 Sistemul de comunicatii prin satelit va fi modular si usor de extins si va

permite cresterea capacitatilor de functionare ( largime de banda, numar de terminale,

etc. ).

SCOM.4 Ofertantul va detalia principalele sub-sisteme ale sistemului de comunicatii

prin satelit mobil: antena, ACU, banda de baza, radiofrecventa, suport, etc.

SCOM.5 Sistemul de comunicatii prin satelit fix este compus din toate elementele

necesare pentru a stabili comunicatii de voce, date si videoconferinta. Echipamentul

fix se va instala pe acoperisul cladirii CMISU (antena fixa cu diametru de minim1.2

m) si va permite orientarea automata a antenei.

5.1.3.4 Comunicatii la nivel dispecer

DCOM.1 Sistemul de bază pentru informaţiile intrate şi ieşite din dispecerat este

reprezentat de staţia operatorului pentru apelul de urgenţă / staţia radio a operatorului.

Aceasta este integrata in sistemul de control al comunicatiilor

DCOM.2 Această staţie este realizata în tehnică digitala, asigurand următoarele legături

de comunicaţii:

a. linii trunk digital S0, S2M şi analog

b. legături cu staţiile de comunicaţie / staţiile de telecomunicaţii ale pompierilor

şi ale oraşului

c. conexiuni radio analog

d. conexiuni radio digitale (TETRA)

e. legături fixe cu instituţii de ex. companii de utilităţi

DCOM.3 Staţia operatorului pentru apel de urgenţă / staţia radio a operatorului prezintă

toate caracteristicile cerute, printre care:

a. identificarea apelantului cu recunoaşterea abonaţilor, în măsura în care există

informaţii

b. suportul prin intermediul unei cărţi telefonice electronice

c. suportul de reapelare pentru abonaţi

DCOM.4 Sistemul de staţii este dotat cu redundanţe necesare comenzii sistemului,

senzorilor de comunicaţii şi alimentării cu curent electric.

64 / 234

DCOM.5 Cablurile de conexiune necesare sunt conduse prin intermediul a 2 traiecte la

sistem.

DCOM.6 Operarea acestor sisteme se realizează cu ajutorul calculatoarelor cu operare

manuală a funcţiilor individuale. În paralel funcţiile pot fi realizate şi susţinute de

calculatorul central al staţiei.

5.1.3.5 Staţia pentru apeluri de urgenţă

UCOM.1 Staţia pentru apelul de urgenţă reprezintă staţia centrală a CMISU. Aceasta

primeşte conexiuni directe din reţeaua publică ISDN prin intermediul a 2 linii,

conexiunea la reţele radio precum şi conexiunea la reţeaua radio digitală.

UCOM.2 Se realizează şi conectarea la staţia de telecomunicaţii a CMISU precum şi

conexiunea staţiilor de operare în CMISU.

5.1.4 Cerinţe speciale pentru sistemul de comunicaţii

5.1.4.1 Functii speciale

COM.1 Susţinerea conexiunilor pentru apeluri de urgenţă prin două switch-uri

separate ale operatorilor de reţea. Serverul de telecomunicaţii este integrat într-o reţea.

În interiorul reţelei există următoarele caracteristici de performanţă:

1. conexiuni digitale în reţea

2. integrarea într-un plan de numere de apel

3. afişaj general

4. afişare în text clar

5. suprafeţe comune de administrare

6. devierea apelurilor

7. transmiterea apelurilor

8. folosirea unui sistem voce digital

9. folosirea cărţilor telefonice electronice

10. salvarea cărţilor telefonice electronice într-o bază comună de date pentru a

putea fi accesate de centrul de comandă şi control şi serverul de comunicaţii

11. integrarea bazei de date carte de telefon pentru identificarea abonaţilor şi

afişarea pe ecran în serverul de comunicaţii şi în BEMIS

COM.2 Funcţii suplimentare:

1. integrarea unei documentaţii pe perioadă scurtă în panoul de control cu

conectarea fiecărei staţii de operare

2. introducerea apelului de urgenţă 112 cu identificarea locaţiei şi dispozitiv de

urmărire

3. introducerea numerelor speciale de telefon

4. linii de comutare şi linii de legături fixe la alte centre de comandă

5. conectarea la alte centrale de apeluri de urgenţă, spitale, secţii de poliţie

6. suportul prin intermediul conexiunilor digitale şi analoge pentru conectarea

instituţiilor, de ex.:

7. furnizori de energie

8. departamente pompieri

9. autorităţi de ordine publică

10. dispecerate taxi

11. dispecerate cale ferată

12. dispecerate transport public

65 / 234

13. conexiuni cu staţiile de comunicaţii / administrare / telecomunicaţii

14. supravegherea permanentă a liniilor cu afişaj de semnalizare defecţiune

15. instalarea unui dispozitiv cu transmisie radio între reţele

16. pregătirea pentru comutarea TETRA cu codificare şi decodificare end to end

17. identificarea automată a apelantului

18. sisteme de operare cu şi taste cu afişaj meniu

19. instrumente pentru apelare rapidă şi alocarea tastelor cu editarea şi

coordonarea tastelor, simbolurilor şi marcajelor

20. instalarea unei interfeţe pentru BEMIS ca interfaţă CTI cu funcţionalitate

bidirecţională

COM.3 Pentru funcţiile comutate, sistemul cu transmisie radio şi sistemul analog de

alarmă, sistemul trebuie să prezinte o unitate de identificare şi afişare.

COM.4 Pentru canalele special de transmisie se folosesc tonul de apel 1 şi 2. În cazul

introducerii tonului de apel se vor afişa optic şi acustic canalele de transmisie. Odată

cu acceptarea canalului de transmisie se deschide difuzorul de ascultare.

5.1.4.2 Canale radio prioritare

COM.5 Canalele radio prioritare pot fi comutate selectiv în funcţie de dispecerat. În

stadiul de procesare, poate fi procesat un canal radio arbitrar. După revenirea la

stadiul standard este din nou disponibil canalul radio prioritar selectat anterior.

COM.6 Prin apăsarea tastei PTT se comută automat canalul radio prioritar sau grupul

prioritar.

5.1.4.3 Suport pentru conectarea la faxul de urgenţă şi interogarea

COM.7 Persoanele cu deficienţe de auz au posibilitatea de a trimite fax către centrul

de comandă şi control.

COM.8 Apelurile primite prin fax sunt preluate manual si automat. Dacă apelul este

recunoscut ca apel prin fax, atunci acel apel este transmis în continuare printr-o

funcţie de intermediere la un fax pentru apeluri de urgenţă.

COM.9 Semnalizarea apelului prin fax se păstrează la staţia de lucru Touchscreen.

Informaţia de apel se şterge dacă la aparatul de fax se activează butonul de recepţie

prin sistemul de comunicare (PLC).

5.1.4.4 Managementul sistemului central de comunicatii

COM.10 Stabilirea nivelurilor de administrare locală şi la distanţă pentru suportul

service pentru o staţie de administrare individuală sau în reţea. Aceasta va asigura cel

putin urmatoarele functionalitati:

1. suport pentru interogări detaliate

2. suport pentru interogări concentrate cu afişaj optic pentru conexiunile /

apelurile încă deschise / în aşteptare

3. apel de grup

4. apel individual

5. funcţia de apelare între staţii

6. operarea combinată a interogărilor detaliate şi concentrate

7. parametrizarea funcţiilor individuale din sistem

66 / 234

8. interogarea automată a apelurilor după timp de apelare (First in, First out pro

grupă/linie)

9. posibilitate de interograre automată a apelurilor mai vechi

10. funcţia de ascultare între staţiile de lucru cu ton de întrerupere

11. posibilitatea de întrerupere a tonurilor de apel în stadiul de prelucrare

12. capacitatea de formare automată internă şi externă

13. conferinţă

14. funcţie de comutare pentru operare nocturnă

15. capacitate multi-protocol

16. apelurile neintermediate se semnalizează locului de provenienţă

17. asistenţa conexiunilor cu şi fără notificare

18. listă de activităţi pe fiecare staţie de lucru

19. suport prin caracteristici standard în telecomunicaţii, precum reapelare

automată

20. posibilitatea individuală de ajustare a apelurilor acustice, precum volum,

microfon, semnalizarea apelului, intensitatea difuzorului, reglarea tonului,

amplificare, hands-free

21. taste de urgenţă pentru comutarea manuală a apelurilor de urgenţă

5.1.4.5 Conexiuni fizice

COM.11 Se va avea in vedere cel putin realizarea urmatoarelor conexiuni fizice:

1. conexiuni de bază S0 conexiune publică (sisteme IT)

2. E1

3. TETRA

4. Ethernet

5.1.4.6 Interfeţe proprii ale sistemului de comunicatii

COM.12 Se va avea in vedere livrarea urmatoarelor interfete de comunicatii:

1. Interfaţa sistemului pentru suportul sistemului RSS

2. Interfaţa sistemului pentru suportul emiţătorului alarmei radio

3. Interfaţa sistemului pentru suportul operatorului unei staţii radio

4. Interfaţa sistemului pentru teleservice

5. Interfaţa sistemului pentru management central

COM.13 Interfata radio TETRA va trebui sa indeplineasca cerintele minim necesare


COM.14 Interfata linie TETRA va trebui sa indeplineasca cerintele minim necesare


COM.15 Interfata linie E1 va trebui sa indeplineasca cerintele minim necesare conform

fisei tehnice.

COM.16 Interfata linie S0 BRI va trebui sa indeplineasca cerintele minim necesare


COM.17 Interfata radio analog PMR va trebui sa indeplineasca cerintele minim

necesare conform fisei tehnice.

5.1.4.7 Interconectarea TETRA

COM.18 Se va asigura interconectarea cu reteaua TETRA prezenta in Bucuresti, prin 3

interfeţe de sistem E1

67 / 234

5.1.4.8 Comenzi consola integrate operator

COM.19 Suportul pentru serverul de comunicaţii se va realiza prin panoul de control.

COM.20 Panoul de control constă din calculator - staţie de operare cu sistem de

operare, conectat prin LAN BEMIS cu interfeţele sistemului pe serverul de

comunicaţii. Panoul de control va asigura următoarele funcţii:

1. operare prin cablu

2. operare radio

3. operare digitală TETRA

4. documentaţie integrată pentru termen scurt

5. emiţător alarmă

6. panou de afişare şi control sistem radio

7. controlul alarmei cu semnal integrat

8. panou de control video

9. suport prin intermediul unei cărţi telefonice electronice

10. suport pentru formarea printr-o singură apăsare

11. afişare deranjamente

12. panou de control pentru serverul de alarmă telefonică (taste grup)

13. afişarea orei

COM.21 Alte funcţii pentru panoul de control:

1. comenzi vocale, opţional prin receptor cu identificare color,

2. set căşti,

3. dispozitiv hands-free.

COM.22 Prin panoul de control se asigură că alarma de avertizare şi convorbirea radio

se pot realiza în paralel. Afişajul în sistem se realizează prin difuzorul integrat în

panoul de operare pentru funcţia de semnalizare a apelurilor şi ascultare.

COM.23 Panoul de control se dotează suplimentar pentru operare sistem TETRA.

Panourile de control conţin o lampă de avertizare. Lampa de avertizare se conectează

cu staţia de operare. În cazul apelării unei staţii de operare lampa de avertizare se

activează astfel încât să se poată identifica staţia care este în funcţiune.

5.1.4.9 Alte cerinte

COM.24 Consola operator va trebui sa indeplineasca cerintele minim necesare conform

fisei tehnice.

COM.25 Sistemul de inregistrare convorbiri va trebui sa indeplineasca cerintele minim

necesare conform fisei tehnice.

COM.26 Terminalul radio analog va trebui sa indeplineasca cerintele minim necesare


COM.27 Cuplorul pentru antena va trebui sa indeplineasca cerintele minim necesare


COM.28 Pilon antena: se va instala un pilon pe cladire.

68 / 234

COM.29 Interfata de alarme pentru unitatile de pompieri conecteaza unitatile de

pompieri la centrul de comanda si control pentru a transporta informatiile referitoare

la alarme. Se instaleaza la centrul de comanda si control. Interfata de alarme pentru

unitatile de pompieri va trebui sa indeplineasca cerintele minim necesare conform

fisei tehnice.

5.1.4.10 Functii si sisteme de suport comunicatii

COM.30 Serverul de comunicaţii va initia conexiunea digitala prin interfeţele de cablu,

precum şi interfeţele sistem cu echipamentele radio asociate. Interfaţa serverului de

comunicaţii va accepta sistemul TETRA in mod trunking. În BEMIS se realizează

integrarea şi operarea sistemelor de radio digitale prin:

1. repartizarea în grupurile de radio stabilite

2. sfuncţiade gestionare pentru grupurile radio alocate

3. managementul utilizatorilor

4. Integrarea grupurilor în grupuri, în funcţie de activităţi operaţionale :

COM.31 Sistemul va oferi suport de informaţii referitoare la stadiul de cuplare cu

sistemul de stare si o reţea de management prin sistem client pe locuri de muncă

alocate.

5.1.4.11 Modul de apelare urgenţă (server de comunicaţii)

COM.32 Prin sistemul de apelare de urgenţă se vor opera toate apelurile de urgenţă,

apelurile oficiale, apeluri directe, legături linie fixă sau cu posturi de lucru aflate în

legătură cu instalaţii de telecomunicaţii, conexiuni cu sistemele de adrese publice

precum şi cu canalele de comunicaţii conectate. Un calculator central racordat va

prelua printr-o interfaţa specializata următoarele funcţii şi procese:

1. preluare numere de telefon (protocol canal D)

2. comparare cu datele salvate din baza de date a calculatorului central

3. afişaj în sistem

4. afişaj date eroare

5. suport la apelare (din cartea de telefon electronică, introducere liberă)

6. apel în aşteptare

7. întrerupere apel

8. comunicare mai departe

9. documentaţie de utilizare

10. utilizare directă cu preluare de date

11. suport carte de telefon cu căutare text

12. legături cu catalogul de măsuri

13. setare istoric cu căutare după apeluri intrate, apeluri acceptate, apeluri

efectuate cu prezentare statistică după număr şi timp.

COM.33 Pentru a monitoriza funcţionalitatea interfeţei se va crea o telegramă ciclică

sau un watchdog. Astfel se va trimite de către BEMIS la intervale regulate o

telegramă de date către sistemul închis la care se va răspunde prin subsistem. Dacă la

telegrama generată de către BEMIS nu se răspunde, BEMIS va trimite un semnal

corespunzător de eroare care este înregistrat.

COM.34 Din partea BEMIS este posibilă împărţirea anunţurilor în anunţuri de operare,

de deranjament şi de alarmă care va fi întreţinută apoi de către administrator.

Conţinuturile detaliate se vor conveni în faza de realizare.

69 / 234

COM.35 În cazul unei alarmări necesare BEMIS transmite matricea de alarmare sub

formă de telegramă date către subsistemul respectiv. Subsistemul respectiv răspunde

la alarmă la intervale regulate şi comunică şi statusul acţiunii. BEMIS înregistrează

acest lucru cu o marcă de timp, şi transmite acest anunţ. Dacă telegrama generată de

BEMIS nu primeşte răspuns BEMIS va transmite un semnal acustic şi vizual de

eroare pe ecran, prevăzut cu un marcaj de timp.

COM.36 Managementul datelor şi configurarea se realizează în serverul de comunicaţii.

Acesta presupune cel putin înregistrarea datelor istorice, posibilitatea de reapelare din

documentul istoric, suport cu carte de telefon electronică şi cu înregistrarea liniilor

serverului de comunicaţii pentru apelurile ieşite.

COM.37 Pe langa conexiunea prin cablu, posturile oprerative vor avea si conexiune

radio cu serverul

5.2 Sistemul si infrastructura IT

5.2.1 Infrastructura de servere

INIT.1 Caracteristicile generale ale infrastructurii de servere minim obligatorii sunt

urmatoarele:

a. Reconfigurarea si repararea componentelor fara oprirea serverului;

b. Management si monitorizare remote;

c. Infrastructura hardware redundant la nivel de echipament

d. Cel putin 2 placi de retea pentru fiecare conexiune fizica;

e. Sistemul de operare va furniza un mediu stabil pe care vor rula aplicatiile care

sunt instalate pe server.

INIT.2 Solutia adoptata va fi cea cu structura de servere fizice multiple, configurate in

structura virtualizata.

INIT.3 Cantitatiile si specificatiile minim obligatorii ale serverelor sistemului sunt

specificate in Fisele Tehnice anexe la prezentul caiet de sarcini.

INIT.4 Vor fi configurare doua medii:

a. Mediul de productie

b. Mediul de testare/dezvoltare/instruire – care va contine toate componentele

principale ale mediului de productie avand caracteristici de performanta mai

scazute

5.2.2 Aria de stocare a datelor

INIT.5 Sistemul de stocare va avea cel putin urmatoarele caracteristici tehnice care

pot fi revizuite si modificate conform cerintelor proiectului preliminar:

a. Dispozitive externe: se vor instala toate sistemele necesare si se va asigura

capacitatea maxima de expansiune prin arii de stocare ( disks array)

b. Redundanta si disponibilitate extinsa: fiecare sistem trebuie sa fie capabil sa

acceseze sistemul de stocare pe cai redundante cu mecanisme de optimizare a

accesului;

c. Mecanisme de protectie a datelor: Se va implementa un mecanism de

protectie de date hardware tip RAID 0,1,5 sau 0+1 impreuna cu mecanisme

de tip Hot Spare.

d. SAN: Sistemul de stocare trebuie sa ofere capacitati SAN (Storage Area

Network) pentru datele critice iar serverele vor fi organizate intr-un cluster.

70 / 234

e. Capacitatea SAN : Capacitatea minima a sistemului SAN va fi cel putin 25

Terabytes.

f. Cache: Sistemul de stocare trebuie va avea mecanisme de cache .

g. Compatibilitate: Sistemul de stocare trebuie sa fie compatibil r diferite de

platforme si sisteme de operare, cel putin cu cele propuse de ofertant in oferta

si cu cele existente in mod current.

h. Copiere de date: sistemul de stocare trebuie sa ofere sau sa fie compatibil cu

mecanisme de copiere hardware si software in mod sincron, asincron si

combinat.

i. Viteza de acces: sistemul SAN trebuie sa functioneze la viteza de cel putin 4

Gbps in fiecare element ( HBA, switch FC si disc)

j. Instrumente de management: vor fi compatibile cu elemente variate, incluzand

directive de securitate si vor permite integrarea lor cu instrumente standard de

management, monitorizare si alarme.

5.2.3 Posturi de lucru

INIT.6 Se vor livra un numar de statii de lucru conform anexei 6. Furnitura va include

20 statii de lucru pentru prelucrarea informatiilor cu caracter ridicat de

confidentialitate, cu protectie TEMPEST impotriva emisiilor sau perturbatiilor

electromagnetice conform standardului SDIP-27 Level B.

INIT.7 Fiecare staţie de lucru din Sala Operativa va fi un terminal compatibil PC cu

iesiri video, monitoare, tastatură şi mouse.

INIT.8 Toate tastaturile şi dispozitivele de acţionare (mouse) vor fi cablate. In

interiorul pupitrului dispecerului.

INIT.9 Furnizorul va asigura amplasarea calculatoarele staţiilor de lucru în sala

serverelor, împreună cu serverele, pentru a reduce zgomotul, interferentele

electromagnetice şi căldura disipata din Sala Operativa.

INIT.10 Toate statiile vor opera cu sisteme de operare si platforme software (de

exemplu Microsoft Windows, Linux, OSX sau echivalent), ultimele versiuni.

INIT.11 Toate statiile de lucru vor beneficia de monitoare proprii.

INIT.12 Monitoarele TFT plate pentru CMISU vor trebui selectate funcţie de

capabilitatea de a afişa imagini video în timp real.

INIT.13 Monitoarele pentru pupitrele operatorilor vor avea diagonala minimă a

ecranului de 22”. Vor trebui să aibă posibilitatea de ajustare a poziţiei şi înclinării.

INIT.14 Cablajul către şi de la monitoarele de pe pupitrele operatorilor va fi ascuns şi

nu va restricţiona in nici un fel mişcarea monitoarelor; el va fi amplasat în interiorul

pupitrelor sau trasat prin podeaua suspendata.

INIT.15 Pentru a permite operatorilor să utilizeze cât mai mult spaţiu de pe pupitre,

monitoarele amplasate pe acestea vor si instalate pe console reglabile. Consolele vor fi

dispuse in asa fel încât monitoarele să poată fi utilizate, cu respectarea stricta a

cerintelor de ergonomicitate, fără a necesita mişcarea consolelor celorlalte monitoare

si fara a afecta vizibilitatea acestora.

INIT.16 Pe lângă staţiile de lucru din CMISU, se vor oferi si terminale mobile şi fixe

capabile sa acceseze sistemul de la distanţă Terminalele mobile cu acces de la

distanţă trebuie să aibă la bază computere portabile sau Tablet PC, cu posibilitati de

legatura cu sistemul CMISU prin Internet.

INIT.17 Fiecare terminal din CMISU situat în afara Camerei de comandă va fi prevăzut

cu o imprimantă locala, de mica capacitate.

71 / 234

INIT.18 Este acceptabil ca, in cazul spatiilor de tip birou in care sunt mai mult de 4

terminale, numarul imprimantelor personale sa fie mai mic.

INIT.19 Sala Operativa va trebui deservită de un numar de doua (2) imprimante

departamentale, de reţea, laser color, accesibile personalului operator. Utilizatorii vor

avea posibilitatea de a tipări formate maxime A3, selectabil de către utilizatori.

INIT.20 Pe langa Sala Operativa, fiecare spatiu operativ (birou, sala de sedinte etc) va

beneficia de cate 1 (una) imprimanta departamentala.

INIT.21 Imprimantele departamentale vor trebui să prezinte un nivel redus de zgomot

la funcţionare, adecvat utilizării în cadrul CMISU.

5.2.4 Back-up si recuperare

BKPR.1 Ofertantul trebuie sa ofere hardware-ul si software-ul necesar pentru a

indeplini urmatoarele cerinte minime:

a. Recuperare de date: Trebuie sa fie posibil sa se recupereze date partiale ale

unui sistem sau aplicatie fara interferente cu celelate servicii.

b. Politici de salvare de date: Trebuie sa permita sa se aplice politici de salvare

de date diferite.

c. Design-ul back-up-ului: Back-up-ul trebuie sa acopere o varietate de platform

mixte, datorita posibililor schimbarii de tehnologie pe termen mediu si lung.

d. Client Back-up: Trebuie sa acopere cerintele specific de back-up ale unor

anumite componente, de exemplu baze de date.

BKPR.2 Sistemul trebuie sa ofere urmatoarele facilitati:

a. sa se bazeze pe prelucrarea tranzactiilor;

b. sa aiba capacitatea de a efectua salvari de date la comanda utilizatorului pe

diverse destinatii / suporturi de stocare rezistente (optice, magnetice) care pot

fi stocate in afara sediului;

c. sa ofere posibilitatea restaurarii datelor salvate;

d. sa asigure posibilitatea ca, utilizand backup off-site, in caz de catastrofa,

intregul sistem precum si datele salvate sa poata fi recuperat/ restaurat pe un

calculator de rezerva;

e. salvarea informatiilor trebuie sa se realizeze automat si periodic pe baza unui

scheduler stabilit de Administrator.

BKPR.3 Atribute esentiale:

a. Administrare centralizată – web based

b. Suport pentru o mare varietate de hardware

c. Mutare si stocare de date inteligentă

d. Automatizare bazată pe politici a proceselor de backup, arhivare si restaurare

e. Capabilităti pentru recuperarea în caz de dezastru

72 / 234

BKPR.4 Salvare via SAN (Storage Area Network): datorita faptului că orice transfer de

date în LAN se realizează prin protocolul TCP/IP (care este un protocol de nivel

ridicat si foloseste intensiv resursele computerelor) facilitatea de salvare via SAN

va reduce în mod considerabil si impactul asupra resurselor. Solutia trebuie să

permită serverelor si clientilor care se conectează la SAN să folosească această

conexiune directă cu mediul de stocare, astfel încat procesele de salvare/restaurare

si arhivare/dezarhivare să se desfasoare prin intermediul SAN în loc de LAN, sau

direct pe benzi sau în storage pool-ul de discuri al serverului. Solutia trebuie să

asigure salvare/restaurare fară incărcare LAN si accesul clienŃilor la libraria de

benzi conectată la SAN

BKPR.5 Salvare / restaurare online baze de date: solutia trebuie să asigure salvarea

online (fară oprirea serviciilor) a bazelor de date precum Oracle, Microsoft SQL sau

IBM DB2

BKPR.6 Solutia trebuie să suporte o mare varietate de medii de stocare, independent de

producator

BKPR.7 Cerinte detaliate:

a. Solutia trebuie să asigure salvarea si restaurarea datelor si arhivarea si

extragerea acestora

b. Aplicatia trebuie să permita efectuarea backup-ului doar pentru fisierele care

au suferit schimbari de la ultimul backup si pentru fisierele nou create. Pentru

sistemul de fisiere FAT/NTFS, solutia trebuie să fie capabilă de a salva doar

portiunea modificată a unui fisier.

c. Administrarea solutiei de backup trebuie să se poată realiza prin intermediul

unei interfete web pentru mai multe servere de backup, indiferent de

platformele pe care ruleaza acestea.

d. Clientii de backup trebuie să fie accesibili prin intermediul unei interfete web,

astfel încât administratorii să aiba la dispozitie un mecanism facil de operare

de la distantă.

e. Solutia trebuie să dispună de un model de administrare flexibil si să permita

accesul mai multor utilizatori (administratori si operatori), fiecare cu nivel de

autorizare diferit.

f. Solutia de backup trebuie să asigure copii de sigurantă pentru mai multe

versiuni ale aceluiasi fisier, astfel încât să ofere posibilitatea restaurărilor

selective.

g. Solutia trebuie să fie capabilă de a sterge copiile de sigurantă ale versiunilor

expirate ale fisierelor (în conformitate cu politica de backup) astfel încât să se

elibereze spatiu pe mediile de stocare (benzi).

h. In cazul în care în timpul procesului de backup/restore conexiunea dintre client

si server se întrerupe, solutia trebuie să fie capabilă de a relua acest proces din

momentul întreruperii si nu de la început.

i. Securitate: solutia trebuie să fie capabilă de criptarea datelor schimbate între

client si server în timpul procesului de backup/restore.

j. Aplicatia trebuie să permită setarea perioadelor de păstrare a datelor salvate, în

functie de timpul la care a fost realizat backup-ul.

73 / 234

k. Solutia trebuie să contina mecanisme de tipul “Bare Machine Backup &

Restore” pentru sisteme Windows, UNIX si Linux.

l. Solutia trebuie să ofere mecanisme de salvare si restaurare pentru NAS fillere

folosind protocolul NDMP.

5.2.5 Specificatii functionale si operationale ale serviciilor

5.2.5.1 Servicii de baza

SERV.1 Aceasta sectiune specifica serviciile de infrastructura de baza care trebuie

folosite de sisteme si care trebuie oferite de ofertant:

a. Name Service: Servere DNS servers, atat interne cat si furnizate impreuna cu

aplicatia.

b. mecanismele redundante corespunzatoare.

c. NTP Times Service: Doua servere de timp si un ceas GPS clock trebuie oferit

pentru NTP times service.

d. Agenti: Ofertantul trebuie sa include in oferta toti agentii necesari pentru

functionarea corecta a sistemului.

e. Securitarea spatiului operatorilor: Spatiul operatorilor trebuie echipat cu toate

sistemele necesare pentru a asigura nivelele de securitate adecvante conform

specificului activitatii.

5.2.5.2 Baza de date operationala

INIT.22 Baza de date operationala se va ocupa cu managementul depozitelor de

stocare a datelor. Capacitatile principale solicitate bazei de date operationale:

a. Optimizarea inregistrarilor si interogarilor

b. Disponibilitate mare

c. Facilitati de backup si restaurare

d. Inregistrarea si schimbarile fiecarei operatiuni (inserare, stergere, updatare,

interogare)

e. Control acces depinzand de profile si permisiunile fiecarui tabel.

f. Suport pentru toate standardele relationale, si de asemenea XML, text, imagini

si spatiu alocabil

g. Suport pentru procedurile de stocare Java si PL/SQL

h. Performanta, securitate si fiabilitate

i. Suport pentru diferitele sisteme de operare

j. Unelte de administrare a statisticilor

INIT.23 Baza de date operationala va fi capabila sa utilizeze datele stocate, ca

„Unelte de creare a deciziilor”.

INIT.24 Ofertantul trebuie sa livreze licentele pentru intreaga infrastructura de baze

de date propusa.

INIT.25 Ofertantul trebuie sa explice mecanismele prin care baza de date

operationala va fi populata.

INIT.26 Nivelul Baza de Date - este compus din minim doua servere de baza de date

in cluster activ – activ care sa asigure balansarea incarcarii, precum si disponbilitate maxima.

INIT.27 Serverele de baza de date vor fi conectate la un storage comun: Storage

Area Network (SAN), unde se afla instanta de baza de date de lucru.

74 / 234

INIT.28 Cerinţe generale

a) SGBDR va fi capabil să stocheze, interogheze şi să returneze date

alfanumerice.

b) Baza de date relaţională trebuie să suporte comunicarea cu aplicaţiile client

folosind protocolul de transport pe reţea TCP/IP

c) Baza de date relaţională trebuie să ruleze pe pe distributiile majore de sisteme

de operare prezente pe piata cum ar fi Windows, Linux, Solaris, AIX, HP-UX,

in vederea asigurarii portabilitatatii.

d) SGBDR va oferi funcţii de raportare si se va integra uşor cu instrumentele de

raportare folosite.

e) SGBDR va suporta Unicode UTF-8 pentru a asigura un set acoperitor de

caractere.

INIT.29 Cerinţe de securitate

f) Baza de date relaţională va trebui să permita restricţionarea accesului la

nivelul obiectelor bazei de date in functie de drepturile de acces ale

utilizatorilor

g) Baza de date trebuie să permita aplicarea simultană a mai multor politici de

securitate pe un acelaşi obiect al bazei de date

h) Baza de date relaţională trebuie să ofere o listă cu operaţiile pe care un grup

sau o clasă de utilizatori le poate executa

i) In vedera auditarii activitatii, baza de date relaţională trebuie să ofere o

facilitate care înregistrează următoarele informaţii pentru modificări, inserări,

ştergeri şi selectări de către utilizatori individuali, ale obiectelor interne bazei

de date:

o id-ul utilizatorului bazei de date (ID aşa cum este el stocat în baza de

date)

o data şi ora (data şi ora acţiunii)

o tipul tranzacţiei (selectare, inserare, modificare, sau stergere)

o id-ul bazei de date

o obiectul/obiectele ţintă

o interogarea trimisă

j) Baza de date relaţională trebuie să ofere abilitatea de a se ajusta la gradul de

detalii, capturate de către facilitatea de audit.

k) Baza de date trebuie să ofere un mecanism de verificare şi validare a parolelor.

l) Baza de date relaţională trebuie să ofere un mecanism de criptare a datelor.

INIT.30 Cerinţe de salvare şi recuperare

a) Baza de date relaţională trebuie să ofere o facilitate pentru salvarea totala

şi/sau parţială a bazei de date

b) Baza de date relaţională trebuie să ofere o facilitate pentru restaurarea totala

şi/sau parţială a bazei de date.

c) Baza de date relaţională trebuie să ofere o facilitate pentru înregistrarea tuturor

modificărilor bazei de date, pentru a permite recuperarea bazei de date

(înregistrarea tranzacţiilor)

75 / 234

d) Baza de date relaţională trebuie să ofere o facilitate pentru recuperarea totala

şi/sau parţială a bazei de date de la un moment de timp specificat de utilizator.

e) Baza de date relaţională trebuie să ofere abilitatea de a face salvări pentru unul

sau mai multe spaţii alocate tabelelor aşa cum este specificat de către

administratorul bazei de date.

f) Baza de date relaţională trebuie să permită salvarea online a bazei de date

direct pe bandă.

g) Baza de date relaţională trebuie să permită o restaurare a bazei de date direct

de pe bandă.

h) Baza de date relaţională trebuie să scrie în mai multe fişiere pe disc simultan

în timpul unei operaţii de salvare, in vederea cresterii performantei.

i) Baza de date relaţională trebuie să citească din mai multe fişiere pe disc

simultan în timpul unei operaţii de restaurare, in vederea cresterii

performantei.

j) Baza de date relaţională trebuie să permită citirea şi scrierea paralelă în timpul

unei operaţii de salvare

k) Baza de date relaţională trebuie să permită citirea şi scrierea paralelă în timpul

unei operaţii de restaurare

l) Baza de date relaţională trebuie să permită o arhitectură de înaltă

disponibilitate

INIT.31 Cerinţe de integritate a datelor

a) Baza de date relaţională trebuie să identifice şi să rezolve situaţiile care ajung

în puncte moarte (deadlock)

b) Baza de date relaţională trebuie să permita constrângeri de tip cheie primară

c) Baza de date relaţională trebuie să permită ca o coloană să nu accepte valori

NULL.

d) Baza de date relaţională trebuie să ofere abilitatea de impunere a

constrângerilor pentru a se asigura că nici o valoare duplicată nu este introdusă

într-o coloană anume care nu participă la o cheie primară

e) Baza de date relaţională trebuie să ofere abilitatea de a impune constrângeri

asupra tipurilor şi valorilor datelor

INIT.32 Cerinte analize geografice

a) Sa ofere suport pentru analize geografice 3D, cum ar fi modele urbane, modele

de teren sau nori de puncte

b) Sa ofere suport pentru geocodare de adrese

c) Sa ofere un format deschis pentru stocarea, administrarea si interogarea

datelor de tip referinta de locatie

d) Sa furnizeze un model deschis pentru stocarea si administrarea grafurilor

e) Sa ofere functionalitati analitice pentru aplicatii de tip business intelligence

care sa includa capabilitati de clasificare, aranjare, asociere si corelare

geografica

76 / 234

f) Sa furnizeze un tip de date pentru obiecte de tip geografic pentru stocarea,

indexarea si efectuarea de operatiuni cu acest tip de date, impreuna cu setul

asociat de operatori

g) Sa ofere posibilitatea de expunere ca servicii web a informatiilor geografice

h) Sa ofere un model deschis pentru stocarea si administrarea de topologii

i) Sa ofere suport pentru versionarea datelor, punind la dispozitie atit versiunea

curenta, cit si cea istorica a datelor

j) Sa ofere posibilitatea de efectuare de calcule precise pe datele geografice,

luind in considerarea si curbura pamintului pentru functiile de tip lungime,

distanta sau arie

INIT.33 Cerinţe privind dicţionarul datelor

a) Baza de date relaţională trebuie să ofere o facilitate de catalog (sau dicţionar

de date) care este modificată automat de fiecare dată când instrucţiuni de tipul

Data Definition Language (DDL – Limbajul de definire a datelor) şi Database

Control Language (DCL - Limbajul de Control al Bazei de Date) se aplică pe

acea bază de date.

b) Baza de date relaţională trebuie să ofere o facilitate pe platforma instalată

pentru a accesa catalogul şi a obţine informaţii legate de obiectele bazei de

date, in vedera monitorizarii instructiunilor care se executa.

INIT.34 Cerinţe privind performanţa şi scalabilitatea bazei de date

a) Baza de date relaţională trebuie să poata rula pe sisteme de tip cluster in mod

activ-activ

b) Baza de date trebuie sa asigure partajarea automata a incarcarii intre nodurile

cluster-ului in vederea maririi productivitatii

c) Sistemul de gestiune de baze de date sa contina propriul soft de clusterware

integrat, astfel incat sa permita rularea pe diferite platforme si sisteme de

operare fara achizitionarea de soft de cluster aditional de la producatorul

sistemului de operare

d) Baza de date relaţională trebuie să ofere abilitatea să partiţioneze tabele in

vederea cresterii performantei si administrarii facile a datelor din tabele

e) Baza de date relaţională trebuie să permită unei tabele să fie partiţionate

bazându-se pe una sau mai multe valori specifice de date, aşa cum este hotărât

de către administratorul bazei de date

f) Baza de date relaţională trebuie să permită definirea cantităţii minime de date

transferate între disc şi memoria locală a bazei de date la o cerere

g) Baza de date relaţională trebuie să ofere facilitatea să reţină date din tabele

special indicate în memoria locală pentru o perioadă nedefinită de timp

h) Baza de date relaţională trebuie să permită setarea mărimii unei zone din

memoria locală, rezervată să reţină date din tabele special indicate, pentru o

perioadă nedefinită de timp

i) Baza de date relaţională trebuie să aibă un optimizator bazat pe cost pentru a

optimiza interogările

77 / 234

j) Instanţe multiple, izolate, şi complet funcţionale ale bazei de date trebuie să

poată coexista pe un singur nod fizic.

k) Baza de date relaţională trebuie să suporte indecşi in vederea regasirii rapide a

informatiilor.

l) Sa ofere posibilitatea de partitionare logica a tabelelor mari in scopul

reducerii timpului de acces la date dupa diverse criterii de partitionare (list,

range, hash) si toate combinatiile acestora (range-list, range-hash, etc.)

INIT.35 Cerinţe privind administrarea bazei de date

a) Baza de date relaţională trebuie să ofere o unealtă de administrare a bazei de

date

b) Unealta de administrare a bazei de date oferită cu Baza de date trebuie să

includă următoarele caracteristici:

o O fereastră SQL pentru a construi şi executa scripturi

o O fereastră pentru a salva şi afişa scripturi SQL

o O fereastră grafică pentru a adăuga şi şterge următoarele obiecte ale

bazei de date şi pentru a le modifica proprietăţile: tabel, index, vedere,

constrângere, declansator, procedură stocată

o O interfaţă pentru a efectua sarcini legate de următoarele funcţii ale

bazei de date: stocare, backup, recuperare

c) Să ofere capabilitatea de diagnosticare a problemelor aparute la nivelul bazei

de date prin urmărirea execuţiilor

d) Să permită prin componenta de administrare web afişarea de grafice de

performantă în timp real

e) Să ofere o funcţionalitate de recomandari de optimizare a interogărilor SQL

5.2.5.3 Securitatea informatica

Securitate logica, se refera la elementele hardware si software, si la configuratiile necesare

pentru a asigura securitatea, confidentialitatea si autenticitatea datelor din sistem. Este un

element esential pentru intreg proiectul. Masurile de securitate logica trebuiesc proiectate si

livrate in conformitate cu urmatoarele cerinte minime:

SERV.2 Firewall

a. Securitatea conexiunilor externe: Conexiunile cu exteriorul trebuiesc protejate

prin sisteme firewall cu filtre suficiente pentru a proteja diferitele sisteme si

retele.

b. Interfata cu firewall-urile: Sistemul firewall trebuie sa incorporeze interfete

grafice care sa permita crearea de obiecte, servicii si reguli vizuale si

interactionale.

c. Suport pentru tehnologii si protocoale standard: Firewall-urile trebuie sa

suporte atat protocoale standard IP cat si tehnologii standard cum ar fi NAT

(Network Address Translation)

d. Suport pentru VPN-uri: Sistemul firewall trebuie sa suporte crearea de VPN-

uri prin protocoalele standard ca IPsec.

e. Autentificarea utilizatorilor: Firewall-ul trebuie sa permita autentificarea

utilizatorilor atat prin sistemul intern (baze de date interne) cat prin sisteme

externe (LDAP, RADIUS, etc)

78 / 234

f. Disponibilitate mare: Firewall-ul trebuie sa functioneze in configuratii cu

disponibilitate mare si / sau echilibrarea proceselor.

g. Instalarea: Firewall-ul trebuie sa fie livrat, instalat si configurat la parametrii

ceruti de masurile de securitate propuse si determinate in etapele de analiza si

protectare ale arhitecturii sistemului.

SERV.3 Detectie intruziuni

a. Detectia intruziunilor: Livrarea, instalarea, configurarea si setarea parametrilor

a unui sistem de detectie a intruziunilor centralizat.

b. Alarme pentru detectia intruziunilor: Sistemul trebuie sa fie capabil sa

genereze o singura alarma pentru un atac, chiar daca atacul a declansat mai

multe incidente.

c. Detectii false: Sistemul de detectie a intruziunilor trebuie sa fie capabil sa

reduca numarul de detectii false.

SERV.4 Criptarea comunicatiilor

a. Comunicatia de date intre sisteme si sub-sisteme trebuie sa fie criptata de

fiecare data cand trece prin retele care nu sunt sub controlul CMISU.

b. Sistemele de criptare trebuiesc sa fie livrate, instalate, configurate si setate

conform necesarului propus si determinat in etapele de analiza si protectare

ale arhitecturii sistemului

SERV.5 Sistemul antivirus

a. Sistemul antivirus: Trebuie livrat, instalat, configurat si setat un sistem

centralizat de antivirus pentru eventualele conexiuni la internet si alte retele

externe. Sistemul antivirus trebuie sa aibe incorporat un serviciu de update

automat, precum si operatiuni ce pot fi facut in cazul unor virusi nedetectati.

b. Sistemul de update al antivirusului: Costul update-urilor pe durata

contractului, trebuie inclus in pretul de oferta.

SERV.6 Certificate digitale

a. Compatibilitatea cu certificatele digitale: Intregul set de hardware si software

trebuie sa fie livrat suficient de deschis si compatibil in integrarea cu alte

certificate standard.

5.2.5.4 Gestiunea documentelor

DOCM.1 Sistemul trebuie sa suporte o mare varietate de continut in format electronic,

de la imagini scanate ale documentelor pe hartie, la documente create cu editoare de

text, foi de calcul tabelar, desene CAD fisiere video AVI, MPG, fisiere audio MP3,

fisire grafice: BMP, JPG, GIF fisiere text: PDF, TXT, HTML, .odt (open office), .flv

(flash video), mpeg-4, posibilitați de streaming media, webcam si va oferi suport

pentru integrarea unor viewere in cadrul solutiei de catre beneficiar pentru alte tipuri

de fisiere ce ar putea prezenta interes pe viitor;

DOCM.2 Informatiile din sistem trebuie pastrate intr-o structura asemanatoare arhivarii

fizice: fiset, cutie, dosar, separator documente, document;

DOCM.3 Sistemul de management de documente trebuie sa permita realizarea structurii

arborescente si definirea de noi niveluri in cadrul arhivei electronice;

DOCM.4 Documentele trebuie pastrate independent de baza de date, pentru a evita

cresterea dimensiunii baze de date si ingreunarea timpului de raspuns. In baza de date

se vor pastra doar legaturi catre documente / fisiere, alaturi de metadatele specifice;

DOCM.5 Formatul de stocare al documentelor electronice va fi cel nativ. Se exclude

79 / 234

pastrarea documentelor in format propriu sistemului de arhivare electronica, pentru a

asigura recuperarea datelor in caz de defectiune;

DOCM.6 Se solicita existenta facilitatilor de setare a cailor de salvare a documentelor,

configurabile in functie de dimensiunea arhivei, astfel incat sa fie generate foldere

separate de dimensiune fixa, ce pot fi salvate ulterior pe medii de stocare;

DOCM.7 Accesul la documente se va realiza prin oricare dintre urmatoarele: Client

Desktop, Client Web;

DOCM.8 Sistemul trebuie sa ofere posibilitatea utilizatorilor de a se conecta folosind un

client smartphone non-web

DOCM.9 Sistemul de management al documentelor va fi independent de platforma,

putand rula atat pe Windows, cat si pe Linux, Unix;

DOCM.10 Interfata utilizator va fi multilingva, utilizatorul avand posibilitatea de a

realiza selectie in momentul autentificarii;

DOCM.11 Interfata va fi de tipul user-friendly, sa contina facilitati de help contextual. In

functie de tipul utilizatorului, va exista posibilitatea configurarii acesteia dupa nevoi,

oferind facilitati de adaugare de butoane sau de eliminare a unor butoane;

DOCM.12 Mesajele de eroare va fi insotite de texte explicative. Sistemul trebuie sa

permita pastrarea unui log de functionare a serverului pentru a se putea urmari

potentialele probleme ce urmeaza a fi tranmise echipei de suport tehnic;

DOCM.13 Sistemul solicitat va fi de tip modular, acesta trebuind sa functioneze ca un tot

unitar;

DOCM.14 Sistemul trebuie sa ofere o interfata de tip API, care sa ofere suport pentru

dezvoltarea/integrarea cu alte sisteme folosind cel putin limbajele de programare Java

si .NET

DOCM.15 Sistemul trebuie sa permita accesul la functiile acestuia pentru realizarea unor

customizari suplimentare, direct din interfata si prin legatura externa din cadrul unei

solutii de dezvoltare avansate sau prin servicii WEB;

DOCM.16 Pentru customizarile realizate, sistemul trebuie sa permita adaugarea de

butoane specifice carora sa li se asocieze functiile dezvoltate si de asemenea, trebuie

sa se permita adaugarea de noi facilitati in cardul meniului contextual (cand se

efectueaza click drept pe un element din arhiva);

DOCM.17 Sistemul va contine o zona de Favorites, in care utilizatorul sa poata pastra cel

mai recent folosite documente/fisiere;

DOCM.18 Subsistemul va permite scanarea direct din cadrul solutiei, fara necesitatea

apelarii unei aplicatii externe. Sistemul va fi compatibil cu driverele TWAIN si ISIS,

sa permita realizarea de profiluri de scanare, configurarea unor facilitati precum :

stabilirea nivelului de alb din pagina, rezolutie, calitatea imaginii, setarea formatului

imaginii si al compresiei acesteia, dimensiunea paginii scanate, sa permita setarea

scanarii duplex sau simplex;

DOCM.19 Sistemul trebuie sa permita utilizarea de separatori de documente pentru

oferirea posibilitatii de automatizare a unor procese de lucru;

DOCM.20 Facilitatile de administrare vor fi permise inclusiv din interfata Web;

DOCM.21 Sistemul trebuie sa permita oferirea de drepturi multiple de acces in cadrul

80 / 234

solutiei, adaugare de noi utilizatori, mostenirea de drepturi, gruparea utilizatorilor in

grupuri, asocierea de administratori de grupuri de utilizatori;

DOCM.22 Sistemul trebuie sa permite realizarea importului de utilizatori de pe statia

locala sau din sistemul LDAP;

DOCM.23 Sistemul trebuie sa permita criptarea documentelor pe 128 biti si utilizarea de

chei de criptare;

DOCM.24 Asocierea de drepturi va putea fi realizata pana la nivel de obiect;

DOCM.25 Sistemul trebuie sa permita copierea unei structuri de fisiere dintr-un cabinet

intr-un alt cabinet si definirea de structuri predefinite pe care utilizatorul sa le poata

accesa cu usurinta;

DOCM.26 Sistemul trebuie sa permita pornirea de activitati pentru un document sau grup

de documente;

DOCM.27 Sistemul trebuie sa permita realizarea de proiecte in cadrul arhivei electronice,

raportat la elementele existente in arhiva;

DOCM.28 Sistemul trebuie sa detina un mecanism avansat de Audit, care sa furnizeze

rapoarte la nivel general si individual;

DOCM.29 Sistemul trebuie sa permita schimbul de fisiere precum si comunicarea intre

utilizatori;

DOCM.30 Sistemul trebuie sa permita repartizarea de sarcini intre utilizatori si

clasificarea acestora pe nivele de prioritate, precum si filtrarea sarcinilor dupa o

perioada de timp dorita de utilizator;

DOCM.31 Sistemul trebuie sa permita rescanarea unui document;

DOCM.32 Sistemul trebuie sa permita pastrarea unui istoric al versiunilor fisierelor,

vizualizarea versiunilor anterioare, revenirea la o versiune anterioara, compararea

intre versiuni precum si pastrarea de versiuni pentru metadatele asociate fisierelor;

DOCM.33 Sistemul trebuie sa detina facilitati avansate de vizualizare: marirea imaginii

cu 25%, 50%, 100%, incadrare pe inaltime, incadrare pe latime, fullscreen, afisare

documente de tip thumbnail view;

DOCM.34 Sistemul trebuie sa permita transmiterea documentelor pe fax, email,

imprimanta direct din interfata acestuia;

DOCM.35 Sistemul trebuie sa permita adaugarea de documente electronice printr-un

mecanism de tip drag and drop si sa permita integrare cu Windows Explorer.

DOCM.36 Sistemul trebuie sa detina facilitati de integrare cu sisteme de editare text si

integrare cu e-mail, oferind facilitati de salvare in arhiva direct din editorul de texte;

DOCM.37 Sistemul trebuie sa asigure lipsa aparitiei de dubluri in cadrul arhivei, prin

oferirea facilitatii de realizare de scurtaturi catre un obiect din arhiva;

DOCM.38 Sistemul trebuie sa ofere facilitati de verificare a spatiului de stocare ocupat de

o ramura din arhiva si numarul de componente ale acelei structuri arborescente;

DOCM.39 Sistemul trebuie sa permita vizualizarea elementelor din structura in mod

ordonat: sortare manuala, alfabetic ascendent, alfabetic descendent, dupa data

arhivarii;

DOCM.40 Sistemul trebuie sa asigure autenticitatea documentelor arhivate prin

mecanisme de verificare de tipul check-sum;

81 / 234

DOCM.41 Sistemul trebuie sa permita adaugarea de notite pe document, comentarii,

adaugarea de atasamente la document;

DOCM.42 Sistemul va detine facilitatea de realizare de preview al unui document, pentru

a creste timpul de afisare al elementelor arhivate, prin transformarea documentului in

sine, in format TIFF sau PDF spre exemplu;

DOCM.43 Sistemul va detine optiuni de imbunatatire a calitatii imaginii precum si

optiuni multiple de vizualizare a acestor imagini: zoom pe zone, incadrari pe

orizontala sau verticala, fullscreen, rotire imagine, vizualizare serii de imagine in

forma Thumbnail cu preview;

DOCM.44 Sistemul trebuie sa permita pornirea de fluxuri simple si predefinite. Crearea

fluxurilor va fi realizata direct din interfata sistemului fara a necesita cunostinte de

programare;

DOCM.45 Sistemul trebuie sa permita urmarirea evolutiei fluxurilor si realizarea de

rapoarte de activitate, precum si transmiterea de instiintari catre persoanele implicate;

DOCM.46 Interactiunea in cadrul fluxurilor de lucru trebuie sa se poata realiza atat din

client cat si din interfata Web;

DOCM.47 Sistemul va detine facilitati avansate de cautare: dupa metadate, comentarii,

versiune, adnotari precum si facilitati extinse de cautare in continut;

DOCM.48 Sistemul trebuie sa permita pastrarea de profile de cautare si definirea de

cautari personalizate;

DOCM.49 Sistemul de cautare va detine facilitati de rafinare a rezultatelor afisate;

DOCM.50 Sistemul va oferi functionalitatea de rotire de documente in cadrul

previzualizarii

DOCM.51 Sistemul va oferi functionalitatea de zoom pe documente in cadrul

previzualizarii

DOCM.52 Sistemul trebuie sa ofere un mecanism de check-out si check-in pe documente

DOCM.53 Sistemul trebuie sa ofere un mecanism ce permite inghetarea documentelor

DOCM.54 Sistemul trebuie sa permita mutarea de documente in aria de lucru a altui

utilizator

DOCM.55 Sistemul trebuie sa permita trimiterea de mesaje intre utilizatori

DOCM.56 Sistemul trebuie sa permita exportul si importul arhivei electronice;

DOCM.57 Sistemul va detine facilitati de restaurare a elementelor sterse;

DOCM.58 Sistemul trebuie sa permita realizarea unui nomenclator de documente si a

unor forme de indexare;

DOCM.59 Sistemul trebuie sa permita definirea de template-uri de documente;

DOCM.60 Sistemul va prezenta suport pentru integrarea semnaturii electronice;

DOCM.61 Sistemul va prezenta facilitati de recunoastere OCR;

DOCM.62 Sistemul trebuie sa permita lucrul cu versiuni multiple de documente si

comparare intre versiuni de documente, pentru a determina modificarile realizate de la

o versiune la alta;

DOCM.63 Sistemul trebuie sa permita arhivarea documentelor direct din sistemul de

operare, prin apelarea la click dreapta a arhivei electronice;

DOCM.64 Sistemul trebuie sa permita folosirea sistemelor profesionala de stocare: benzi

82 / 234

magnetice, blueray-uri, storage-uri;

DOCM.65 Sistemul trebuie sa permita lucrul pe activitati bine definite;

DOCM.66 Sistemul va oferi facilitati avansate de cautare: in document, dupa cuvinte

cheie, dupa comentarii la versiuni, in textul post-it-urilor sau cautare fulltext;

DOCM.67 Sistemul trebuie sa permita intregrarea cu alte aplicatii;

DOCM.68 Sistemul trebuie sa permita extinderea functionalitatilor direct din cadrul

interfetei de lucru de catre untilizator, printr-o zona de scripting;

DOCM.69 Sistemul trebuie sa permita notificari automate ca e-mail sau task;

DOCM.70 Sistemul trebuie sa permita adaugarea de stamp-uri la un document;

DOCM.71 Sistemul trebuie sa permita adaugarea de adnotari asupra documentului;

DOCM.72 Sistemul trebuie sa permita asignarea de inconite grafice dedicate pentru

ramurile / categoriile din arhiva;

DOCM.73 Sistemul trebuie sa permita definirea de tipuri proprii de documente si iconite

asociate acestor tipuri de documente;

DOCM.74 Sistemul va prezenta o interfata de administrare complexa, atat din clientul

web cat si din clientul de Windows;

DOCM.75 Sistemul trebuie sa permita realizarea de profile de scanare;

DOCM.76 Sistemul trebuie sa permita definirea de profile de back-up;

DOCM.77 Sistemul va prezinta facilitati de replicare intre client si server si server-server;

DOCM.78 Sistemul va folosi resurse minimale pentru rularea acestuia in conditii optime;

DOCM.79 Sistemul va fi extensibil, numarul de utilizatori sa poate creste prin simpla

modificarea a codului de licenta;

DOCM.80 Sistemul trebuie sa permita restaurarea documentelor intr-un timp foarte scurt,

in cazul aparitiei unei defectiuni hardware;

DOCM.81 Sistemul trebuie sa permita adaugarea de “voice notes” ca atasament la

documentul respectiv (de exemplu o inregistrare vocala care sa stabileasca instructiuni

cu privire la acel document);

DOCM.82 Sistemul de management de documente trebuie sa fie compatibil ODMA. El

va permite lansarea automata din sistem a aplicatiilor cu care au fost creeate fisierele

iar din aplicatiile ODMA sa se poata salva automat in sistem, fara operatii

suplimentare de tip salvare atasare;

DOCM.83 Sistemul de management de documente trebuie sa permita integrarea

serviciului de e-mail, adica sa poata trimite automat mesaje la aparitia unor

evenimente (ex. Documente expirate, documente in lucru etc) catre adrese de e-mail

ale utilizatorilor;

DOCM.84 Sistemul de management de documente trebuie sa aiba o interfata standard de

cautare a documentelor pe baza unor criterii diverse (nume document, data crearii,

cuvinte-cheie etc.). Aceasta va asigura accesul utilizatorului la acele documente la

care are dreptul, pe baza drepturilor de acces definite in sistem;

DOCM.85 Sistemul va oferi posibilitatea de setare de drepturi de access pentru utilizatori

si grupuri de utilizatori, cu granularitate pana la nivel de document si camp de

indexare asociat documentului

DOCM.86 Sistemul de management de documente trebuie sa permita ca un document sa

83 / 234

poata fi inregistrat simultan in mai multe registre;

DOCM.87 Sistemul va oferi posibilitatea de tiparire a registrelor de documente;

DOCM.88 Sistemul de management de documente trebuie sa aiba incluse utilitare (.exe)

care permit atasarea simultana la un document a mai multor fisiere selectate manual

sau specificate ca rezultat al unei operatii de recunoastere coduri de bare;

DOCM.89 Sistemul de management de documente trebuie sa dispuna de un modul

integrat in clientul de mesagerie ofertat in solutia de mesagerie astfel incat sa permita

lucrul cu documente direct din clientul de e-mail;

DOCM.90 Sistemul va oferi mecanisme de cautare dupa diverse optiuni de cautare

(cautare dupa formularul de indexare cu cuvinte cheie, cautare folosind Wildcard,

cautare pentru secvente, cautare „incepe cu” sau „se termina cu”, cautare de la / pana

la, cautare complexa , cautare full text combinata)

DOCM.91 Sistemul de management de documente trebuie sa dispuna de un modul de tip

„enterprise search” care sa permita cautarea atat in arhiva proprie cat si pe siturile

interne ale institutiei sau in exterior si organizarea rezultatelor astfel incat sa permita

regasirea dupa cuvinte cheie si ordonarea raspunsurilor in functie de relevanta

rezultatelor;

DOCM.92 Structura arborescenta se va integra nativ cu ierarhiile LDAP, avand

elementele sincronizate la nivel de unitate organizationala si de obiect de tip grup;

DOCM.93 Sistemul trebuie sa permita stabilirea posturilor si a subordonarii acestora,

rutand automat cererile catre sefii directi, conform fluxului stabilit;

DOCM.94 Sistemul trebuie sa permita pornirea de fluxuri ad-hoc de tip

informare/distribuire sau de tip avizare/aprobare cu selectarea utilizatorilor sau

grupurilor de utilizatori care vor fi implicati. De asemenea, trebuie sa permita salvarea

acetor fluxuri ad-hoc pentru refolosirea ulterioara;

DOCM.95 Sistemul trebuie sa functioneze pe fluxuri definite vizual prin masina de stari.

Sistemul trebuie sa permita definirea vizuala a tranzitiilor intre stari precum si

conditiile ce determina aceste evenimente;

DOCM.96 Sistemul trebuie sa permita notificarea prin e-mail referitor la aparitia unei

cereri si va conduce operatorul automat in pagina unde acesta poate aproba sau refuza

aceasta cerere;

DOCM.97 Sistemul trebuie sa ofere posibilitatea generarii de rapoarte in format tiparit la

cereri, pentru a fi semnata, pe baza unui template predefinit.

DOCM.98 In cadrul sistemului de management al documentelor trebuie sa va realiza

arhiva centrala pentru subsistemul de monitorizare si inregistrare a istoricului datelor.

5.2.5.5 Server GIS

Server GIS trebuie să îndeplinească următoarele specificaţii minime obligatorii:

SGIS.1 Caracteristicile fundamentale ale bazei de date geospaţiale:

a) datele spaţiale trebuie să poată fi stocate în dublă precizie, eliminând astfel

neconcordanţele în ceea ce priveşte precizia datelor, unificând prelucrarea

geometriei şi simplificând geoprelucrarea volumelor mari de date geospaţiale;

84 / 234

b) fişierul unei baze de date geospaţiale trebuie să poată fi stocat sub forma unui

folder de fişiere care poate fi stocat atât pe platforme Windows cât şi Linux

sau Unix, fără limite pentru volumul de date geospaţiale ce se doreste a fi

salvat;

c) continutul fişierului unei baze de date geospaţiale trebuie să poată fi de

asemenea comprimat.

d) să permită accesul unui număr nelimitat a două categorii de utilizatori:

e) utilizatori cu drepturi de vizualizare a informaţiei (inclusiv în format vector

GIS) din baza de date pe baza unei aplicaţii Web-GIS;

f) utilizatori de tip manageri cu drepturi de vizualizare a rapoartelor operative şi

istorice.

SGIS.2 Editare web a obiectelor spaţiale. Serverul Web GIS să permită crearea de

aplicaţii Web GIS cu funcţionalităţe de editare web a obiectelor spaţiale, cu

posibilitatea de selectare a straturilor ce pot fi editate (inclusive la nivel de versiune)

şi pentru fiecare strat selectat pentru editare să permită selectarea editării numai a

geometriei sau a atributelor sau a ambelor;

SGIS.3 Pentru menţinerea integrităţii spaţiale a datelor, funcţiile de editare web să

permită utilizarea şi configurarea opţiunilor de snapping;

SGIS.4 Procedeul de replicare a bazelor de date geospaţiale trebuie să permită crearea

şi gestionarea de replici ale acesteia (în întregime sau parţial); o parte sau toate

seturile de date geospaţiale ale unei versiuni ale aceleiaşi baze de date geospaţiale

trebuie să poată fi replicat; să se asigure restricţionarea la datele ce trebuiesc replicate

prin intermediul interogărilor spaţiale şi a celor bazate pe atribute; două sau mai multe

baze de date geospaţiale să poată fi sincronizate cu generarea mutiplă ale editărilor

efectuate asupra fiecarei baze de date geospaţiale;

SGIS.5 Să permită actualizarea bazei de date geospaţiale master imediat ce s-au operat

schimbări asupra unei versiuni a acesteia (aşa numitul procedeu “check-in/check-

out”);

SGIS.6 Să permită gestionarea detectării modificărilor şi conflictelor pentru versiuni

anterioare ale bazelor de date geospaţiale fără a fi necesară reconcilierea sau existenţa

unei sesiuni de editare deschise;

SGIS.7 Trebuie să permită rezolvarea conflictelor de versiuni atât la nivelul versiunii

”parent” a bazei de date cât şi în cadrul sesiunii de editare;

SGIS.8 Să ofere un cadru de lucru scalabil pentru publicarea pe internet a hărţilor

interactive, datelor geospaţiale, serviciilor web gis şi accesul utilizatorilor la toate

acestea;

SGIS.9 Un cadru standard de server gis ce va permite dezvoltarea de aplicaţii

particularizate utilizând : java, .net, flex, javascript şi silverlight. Produsul software

destinat dezvoltării aplicaţiilor web gis particularizate trebuie să ofere o diversitate de

instrumente dezvoltator utile în utilizarea datelor geospaţiale, a obiectelor spaţiale dar

şi serviciilor web gis;

SGIS.10 Să permită dezvoltarea de aplicaţii server cu funcţionalităţi gis, distribuite în

mediile client/server şi de servicii web, folosind standardele cheie cum ar fi: java,

85 / 234

.net, com şi xml/simple object access protocol (soap) pentru transferul de date şi

mesagerie pe internet (http) şi arhitectura rest (representational state transfer);

SGIS.11 Suport pentru format kml (citire şi publicare de servicii tip kml care să poată fi

accesate de client web şi desktop ce suportă formatul kml) şi integrarea totodată cu

acesta şi a simbologiei, etichetelor text, grafice, draparea directă peste modelul digital

al terenului şi posibilitatea de auto-refresh pe server şi a optimizării proceselor de

analiză tridimensională;

SGIS.12 Integrare cu aplicaţiile software desktop gis, fără a fi nevoie de conversia

datelor gis. De asemenea, sistemul informatic geografic trebuie să permită publicarea

oricarei hărţi realizate cu aplicaţiile software desktop gis fără a se produce modificări

asupra acestora;

SGIS.13 Să dispună de un set de instrumente dedicate optimizării publicării rapide a

documentelor hartă ca servicii web hartă, mentinând totodată şi standardele

cartografice complexe ale layerelor create prin intermediul aplicaţiilor gis desktop

specificate anterior;

SGIS.14 Utilizarea datelor vector şi datelor raster cu diverse rezolutii. De asemenea,

utilizarea simultană, în aplicaţiile web, a celor două categorii de date;

SGIS.15 Să ofere obiecte programatice out-of-the-box pentru dezvoltarea aplicaţiilor

web, care să permită:

a) afişarea hărţilor publicate prin intermediul serviciilor GIS, a rozei vânturilor

etc.,

b) navigarea în hartă,

c) interogarea datelor geospaţiale,

d) afişarea şi administrarea map tip-urilor,

e) editarea versionată a datelor spaţiale.

SGIS.16 Să asigure gestionarea datelor geospaţiale, accesul multiutilizator de

citire/scriere în bazele de date geospaţiale, comprimarea bazelor de date cu versiuni

multiple chiar în momentul în care utilizatorii sunt conectaţi la bazele de date;

SGIS.17 Posibilitatea de unificare a geometriei obiectelor de versiuni separate în cazul

editarii aceluiaşi obiect geospaţial de către doi editori;

SGIS.18 Să permită posibilitatea editării web a datelor;

SGIS.19 Produsul web să permită transcalculul de coordonate “on-the-fly” din sistemul

în care sunt stocate datele în cel în care sunt afişate;

SGIS.20 Posibilitatea de a dezvolta aplicaţii şi servicii folosind aceeaşi tehnologie

orientată-obiect;

SGIS.21 Administrarea serviciilor web gis prin intermediul unei aplicaţii web (utilizare

intr-un browser) şi posibilitatea publicării de servicii web profesionale. Crearea rapidă

de servicii gis şi dezvoltarea rapidă a portalelor web gis cu ajutorul exemplelor de cod

şi a template-urilor puse la dispoziţie de producătorul software;

SGIS.22 Să asigure interoperabilitatea cu diverse aplicaţii gis avansate enterprise şi cu

aplicaţii web de catografiere profesionale;

86 / 234

SGIS.23 Posibilitatea creării de script-uri java (pentru diverse diverse funcţionalităti

precum sunt funcţionalităţile de navigare în hartă, interogare, geocodare,

geoprelucrare) capabile să exploateze serviciile web geospaţiale amintite anterior;

SGIS.24 Capabilităţi server cu funcţii pentru crearea, interogarea, analiza şi

geoprocesarea datelor raster;

SGIS.25 Instrumente pentru publicarea serviciilor web xml. Sistemul informatic

geografic trebuie să permită publicarea bazelor de date spaţiale ca servicii geospaţiale,

funcţionalităţe care permite accesul direct la bazele de date distribuite. De asemenea,

aceste servicii trebuie să permită replicarea şi sincronizarea bazelor de date

geospaţiale. Aceste servicii trebuie să ofere posibilitatea integrarii în hărţi a datelor

spaţiale (provenite din baze de date geospaţiale) publicate în lan, wan şi internet. În

plus, acest serviciu trebuie să asigure posibilitatea realizării de conectări multiple

(utilizatori cu roluri şi drepturi diferite) la nivelul diverselor versiuni de date ale

aceleiaşi baze de date geospaţiale. De asemenea, aplicaţiile client conectate la aceeaşi

bază de date geospaţiale trebuie să poată efectua operaţii de extragere de date, creare

de replici, importul, exportul şi reconcilierea versiunilor existente la nivelul replicilor;

SGIS.26 Să dispună de aplicaţii dedicate şi de instrumentele specifice gestionării

securizării serviciilor gis şi aplicaţiilor web. De asemenea, sistemul informatic în

ansamblul lui, trebuie să asigure definirea utilizatorilor, a rolurilor şi drepturilor de

utilizare a serviciilor şi aplicaţiilor web gis dezvoltate pe tehnologie active server

pages;

SGIS.27 Să ofere suport pentru diseminarea informaţiilor geospaţiale şi distribuirea

capabilităţilor de cartografiere diferitelor tipuri de aplicaţii client, aplicaţii web de tip

lightweight, aplicaţii de tip browser şi aplicaţii desktop gis;

SGIS.28 Să ofere posibilitatea de particularizare, integrare şi comunicare tinând seama

de standardele internaţionale specifice informaţiei geospaţiale şi asigurarea

interoperabilităţii web;

SGIS.29 Să ofere suport atât pentru protocolul ipv4 şi ipv6 cât şi unicode;

SGIS.30 Să asigure posibile implementări viitoare de soluţii particularizate privind

modelarea şi analiza datelor de tip reţea;

SGIS.31 Să ofere suport pentru realizarea analizelor pentru toate formatele raster şi

vector suportate de aplicaţiile software desktop gis;

SGIS.32 Să permită utilizarea de sisteme de proiecţii diferite “on-the-fly“ pe durata

analizelor;

SGIS.33 Produsul gis destinat dezvoltării de portale web gis trebuie să ofere

următoarele facilităţi:

SGIS.34 Trebuie să permită dezvoltarea de aplicaţii ria (rich internet applications), fără

a avea cunostinţe avansate de programare, utilizand api-uri pentru .net, javascript,

java, microsoft silverlight şi adobe flex în care să se poată utiliza animaţii, înregistrări

video, reprezentări 3d etc.; utilizarea resurselor online puse la dispoziţie de

producătorul softului pentru afişarea în aplicaţia web gis a imaginilor satelitare şi

aeriene cu rezolutie de 500m, 15m (acoperire continuă) şi 1m (acolo unde este

disponibil), hărţilor de transport şi modelul terenului.

87 / 234

SGIS.35 Să ofere un set de instrumente destinate analizei geostatistice avansate care:

SGIS.36 Să ofere o gamă largă de instrumente destinate explorării datelor spaţiale,

identificării abaterilor, predicţiei, şi creării suprafeţelor;

SGIS.37 Să permit prelucrarea datelor ( histograme, statistici sumare)

SGIS.38 Să permită realizarea de hărţi clasificand datele prin metoda cantitativa

SGIS.39 Să permită analiza domeniilor de variaţie ale datelor, identificarea excepţiilor,

să permită examinarea tendinţelor de ansamblu, determinarea autocorelaţiei spaţiale şi

corelaţiei dintre diferite seturi de date;

SGIS.40 Prelucrarea datelor geospatial pentru analiza tendinţelor;

SGIS.41 Să permită realizarea de hărţi dintr-o serie de poligoane din jurul unui punct;

SGIS.42 Să permită predicţia, determinarea erorilor standard ale predicţiei, analize ale

limitelor de prag şi să ofere o varietate de modele şi instrumente pentru crearea

hărţilor de localizare cantitative;

SGIS.43 Să permită realizarea de semivariograme şi covariaţii ale setului de măsuratori;

SGIS.44 Să ofere un set de instrumente destinate modelării spaţiale şi analizei avansate

care să permită:

a) Identificarea unei locaţii potrivite.

b) Calcularea distantelor si directiilor intre doua puncte

c) Realizare date folosind functii de prelucrare a imaginilor

d) Analiza date raster / vector

e) Interpolarea valorilor pentru o zonă de studiu.

f) Realizarea de analize statistice pe zone predeterminate.

g) Functii Map Algebra pentru analiza geografice

h) Metode de analiza hidrologică

i) Analiza suprafetelor complexe

j) Tehnici de analiza statistică in format harta care se actualizeaza automat

k) Analiza densităţii folosind obiectele spatiale

l) Analiza distanţei si directiei intre diferite puncte

m) Interogarea şi explorarea datelor

SGIS.45 să permită realizarea analizelor complexe prin expresii algebrice simple - map

algebra

SGIS.46 Ofertantul trebuie sa dispuna de un expert GIS cu competente in tehnologiile

GIS ofertate dovedite prin certificari si competente avansate in realizarea hartilor GIS,

recunoscute prin diplome sau premii. Expertul va avea experienta profesionala de cel

putin 5 ani, experienta dovedita in coordonarea de proiecte nationale sau

internationale in domeniul GIS si experienta profesionala in domeniu de cel putin 5

ani.

SGIS.47 Sistemul va asigura replicarea fisierelor de tip tile harta pe mai multe servere

de fisiere. Avand in vedere numarul mare de fisiere tiles continute de o harta,

dinamica actualizarii lor precum si dimensiunea acestora, trebuie sa existe un modul

care sa efectueze replicarea fisierelor diferentiat (doar pe cele modificate) si fara sa

afecteze banda de transfer sau capacitatea de procesare a serverului ce stocheaza

88 / 234

aceste fisiere. Este necesar sa se foloseasca tehnologie software care sa permita

rularea in background, in timpul in care sistemul nu este folosit pentru activitati critice

SGIS.48 Componenta de server a replicarii fisierelor de tip tile:

a) administreaza directorul cu toate tile-urile si listele de tile-uri pentru fiecare

sector

b) periodic scaneaza listele si tile-urile de pe disc (pe baza unui checksum)

inregistrand toate operatiile (adaugare/modificare/stergere) intr-un jurnal

c) furnizeaza printr-un serviciu web jurnalul de operatiuni

d) mentine un jurnal de activitate sub forma unui fisier text sau windows event

log (descarcarea fisierelor va fi jurnalizata de serverul web)

e) directorul cu tile-urile hartii este expus printr-un server web

SGIS.49 Componenta agent client a replicarii fisierelor de tip tile:

a) memoreaza pozitia in jurnal a ultimei actualizari si cere serverului jurnalul de

operatiuni ulterioare

b) parcurge jurnalul primit si incearca sa descarce (folosind job-uri de

background care nu afecteaza performanta procesorului) tile-urile de pe server

si sa le stearga pe cele care au fost sterse pe server

c) raporteaza serverului pozitia ultimei actualizari

d) mentine un jurnal de activitate sub forma unui fisier text sau event log sistem

de operare

e) daca serviciul client este oprit in cursul operatiei de download job-ul va

continua in background si va fi preluat in momentul repornirii clientului

5.2.5.6 Sistem GIS pentru stații de lucru

Sistemul GIS pentru stații de lucru trebuie să permită editarea în mod avansat a resurselor

GIS. Sistem GIS pentru stații de lucru trebuie să îndeplinească următoarele specificaţii

minime obligatorii:

WGIS.1 Posibilitatea utilizării de către 3 utilizatori concurenţi

WGIS.2 Să facă parte din categoria produselor GIS profesionale, utilizate la nivel

mondial

WGIS.3 Să vizualizeze, administreze, creeze şi analizeze date specifice GIS referitoare

la toate facilităţile existente;

WGIS.4 Să asigure instrumente ce permit analiza, optimizarea şi publicarea

documentelor de hartă realizate sub formă de servicii web, scalabile către un server de

aplicaţii GIS centralizat;

89 / 234

WGIS.5 Să dispună de instrumente profesionale de management a datelor geospaţiale

(creare clase de obiectele geospaţiale, adăugare de domenii spaţiale, ştergere/adăugare

câmpuri, subtipuri, administrare relaţii între date spaţiale şi non-spaţiale, topologii);

WGIS.6 Să asigure funcţii complexe de management a datelor în mediul de

geoprelucrare prin:

a) Conversia diferitelor tipuri de date: raster, CAD, dbase, formate vector;

b) Gestionarea tabelelor bazei de date geospaţiale prin analiza acestora, setarea

privilegiilor, etc.;

c) Crearea de seturi de date geospaţiale de tip multiutilizator şi asigurarea

performanţei bazei de date geospaţiale prin instrumente profesionale de

compactare şi comprimare a acesteia;

d) Gestionarea geometriei obiectelor geospaţiale funcţie de anumite caracteristici,

ce permit “explodarea“ multiplă, delimitarea liniilor prin vertecsi, extinderea

liniilor, conversia obiectelor geospaţiale de tip poligon în cele de tip linii,

instrumente de generalizare a obiectelor geospaţiale, cum sunt cele de

simplificare şi modelare;

e) Import/export date din format CAD;

WGIS.7 Să permită amplasarea automată a etichetelor de tip text şi editarea

cartografică profesională de tip „WYSIWG - What You See Is What You Get”;

WGIS.8 Să asigure stocarea etichetelor şi simbolizării cartografice direct în baza de

date geospaţială inclusiv actualizarea automată în cazul modificării poziţiei spaţiale şi

a atributelor obiectelor spaţiale modificate;

WGIS.9 Să permită etichetarea în funcţie de clase de etichete;

WGIS.10 Să permită diseminarea directă şi automată a produselor hartă cartografice

profesionale şi a planurilor de referinţă geospaţiale sub diferite drivere şi formate:

imprimare plotter, postcript, PDF (incluzand posibilitatea vizualizării atributelor),

formate imagine (JPG, PNG, TIFF, etc.), publicarea directă la nivelul aplicaţiei server

GIS avansată centralizată şi sub forma de servicii web GIS (WCS, WFS, etc.);

WGIS.11 Să asigure integritatea spaţială prin intermediul:

a) Topologiei bazei de date geospaţiale, în special construirea şi întreţinerea

relaţiilor spaţiale între obiectele geospaţiale folosind regulile topologice şi a

procesului de validare;

b) Reţelelor geometrice, asigurând modelarea conectivităţii specifice acestora.

WGIS.12 Să permită personalizarea interfeţei utilizator prin adăugarea sau eliminarea

barelor de instrumente, butoane, meniuri şi aplicaţii cu funcţionalităţi noi, folosind

limbaje standard de programare, precum: Visual Studio .NET, C++, Perl, vbscript,

Visual Basic, JavaScript, VBA, Python;

WGIS.13 Să permită editarea cu ajutorul mouse-ului asemănătoare celei oferite de

programele CAD (introducere coordonate XY, perpendicular, paralel, în funcţie de

direcţie, distanţă);

WGIS.14 Să permită crearea uşoară de hărţi de calitate;

90 / 234

WGIS.15 Să furnizeze capacităţi de cartografiere completă, inclusiv legende dinamice,

reprezentarea corectă a diferitelor sisteme de coordonate, scalare corectă, redarea

corectă a hărţii în concordanţă cu proiecţia selectată;

WGIS.16 Să permită redarea hărţilor la scara reală, de la diferite formate până la A0.

Desenele să poată fi redate prin imprimare/ plottare ca de altfel şi prin formate digitale

(ex.TIF). Mărimea simbolului (ex. Latimea liniei) să poată varia automat în funcţie de

scara utilizată;

WGIS.17 Să se poată conecta la seturi de date CAD asigurându-se importul şi exportul

către CAD (dxf);

WGIS.18 Trebuie să suporte minimum următoarele topologii: puncte, linii, poligoane;

WGIS.19 Să fie uşor de folosit de utilizatorii non-tehnici;

WGIS.20 Trebuie să poată fi rulate pe PC-uri standard, ce au minim instalat sistemul de

operare

WGIS.21 Să permită lucrul cu tabele şi cu baze de date spaţiale;

WGIS.22 Să permită interogarea grafică (după poziţie) sau după atribute;

WGIS.23 Să permită lucrul cu formate vectoriale în sisteme de coordonate specifice

României: Stereografic 1970, Gauss Kruger, UTM şi WGS 84;

WGIS.24 Să permită stocarea datelor în oricare din sistemele de coordonate locale

(definite custom) şi în cel naţional, precum şi în toate sistemele de coordonate

internaţionale recunoscute şi procesarea lor fără a fi necesar importul datelor dintr-un

sistem în altul;

WGIS.25 Să permită transcalculul de coordonate “on-the-fly” din sistemul în care sunt

stocate datele în cel în care sunt afişate;

WGIS.26 Să permită gestiunea mixtă atât a datelor raster cu cele vector cât şi acelor

alfanumerice. Datele vector şi alfanumerice trebuie gestionate integrat într-o bază de

date relaţională profesională;

WGIS.27 Să fie nelimitat cu privire la obiectele geografice (ex.ca numar de puncte, linii,

noduri şi poligoane), însuşirile bazei de date şi înregistrările ataşate acesteia;

WGIS.28 Să dispună de facilităţi pentru etichetarea automată a entităţilor grafice din

citirea bazei de date;

WGIS.29 Să permită calcularea distanţelor şi direcţiilor dintre două puncte date prin

intermediul coordonatelor geografice (în diferite sisteme);

WGIS.30 Să permită georeferenţierea hărţilor scanate: tif, jpeg, bmp;

WGIS.31 Să permită interogări/ selecţii după atribute sau poziţii spaţiale;

WGIS.32 Să permită ca tabelele de date externe să fie integrate în totalitate în baza de

date internă;

WGIS.33 Să permită ca obiectele vector, raster şi CAD să fie relaţionate din punct de

vedere geografic independent unul de altul dar să poată fi afişate împreună;

WGIS.34 Să asigure posibilitatea editării multiutilizator -mediul de gestionare a bazelor

de date geospaţiale trebuie să permită accesul şi editarea simultană a obiectelor

spaţiale de către utilizatori multipli şi să asigure reconcilierea oricărui conflict;

WGIS.35 Să permită ca utilizatorii să poată lucra cu mai multe tipuri de obiecte de date

intuitive. Bazele de date geospaţiale trebuie să permită construirea de obiecte de date

91 / 234

ce corespund unui model de date specific utilizatorului. În loc de obiectele spaţiale

generice – puncte, linii, poligoane, utilizatorii trebuie să aibă posibilitatea de a lucra

cu obiecte de interes, cum ar fi: conducte, vane, străzi, etc.;

WGIS.36 Să asigure un depozit central uniform al bazelor de date geospaţiale gestionat

printr-un RDBMS;

WGIS.37 Să dispună o bară de instrumente pentru a permite conectarea la echipamente

GPS (COM, rata transfer);

WGIS.38 Să permită vectorizarea în baza de date utilizand cu opţiuni de snapping la

vector şi raster;

WGIS.39 Să permită extragerea semi-automată a informaţiilor dîntr-o hartă raster

scanată şi georeferenţiată;

WGIS.40 Să permită publicarea de date GIS arhivate pe server-ele producătorului

software şi distribuirea acestora către utilizatori (user şi parola) în scopul distribuirii

volumelor mari de date spaţiale;

WGIS.41 Mod stocare date desktop în formate ce suportă mai mult de 10GB;

WGIS.42 să permită crearea de modele utilizand interfaţa grafică şi limbaje de

programare script precum: Python, VBscript şi Jscript;

WGIS.43 Să permită suprapunerea de date vector, analize spaţiale complexe: de tip

proximitate, vecinătate, cuprindere, şi analize spaţiale statistice;

WGIS.44 Analiza spaţială bi sau tridimensională a datelor vector şi raster;

WGIS.45 Crearea şi analiza suprafeţelor destinate modelării, vizualizării şi analizelor

complexe;

WGIS.46 Prelucrarea datelor geospaţiale, analiza (histograme, analiza tendinţelor, hărţi

tematice cantitative, etc.) și interpolarea geostatistică a datelor spaţiale cât şi

posprelucrarea acestora;

WGIS.47 Să permită diagnosticarea calităţii modelării prin validare simplă şi încrucişată

(compararea modelelor) şi exportul rezultatelor de predicţie în obiecte de tip poligon,

linii de contur, grid-uri, etc;

WGIS.48 Să ofere instrumente pentru modelarea după diferite scenarii complexe cum ar

fi reţele multimodale de transport a diferitelor forme de transport prin utilizarea unor

puncte de coincidenţe;

WGIS.49 Să ofere suport pentru realizarea analizelor pentru toate formatele raster şi

vector suportate de aplicaţiile software desktop GIS;

WGIS.50 Să permită utilizarea de sisteme de proiecţii diferite “on-the-fly“ pe durata

analizelor;

WGIS.51 Să dispună de un mediu de modelare grafică pentru a selecta cea mai bună

locaţie a unei amplasări;

WGIS.52 Să permită crearea bufferelor raster pe baza unei distanţe sau pe seama

vecinătăţilor obiectelor spaţiale;

WGIS.53 Să dispună de metode de interpolare a suprafeţelor în cazul fenomenelor

continue spaţiale cu diferite metode de analiză statistică spaţială (interpolare

inversată, metoda Kriging, interpolare de tip curbă, polinomială, sau utilizând tehnica

de vecinătate, etc.);

92 / 234

WGIS.54 Să permită generarea hărţilor de densitate folosind obiectele spaţiale de tip

punct;

WGIS.55 Să permită crearea de suprafeţe continue pornind de la puncte sau linii de

contur;

WGIS.56 Să permită realizarea simultană de interogări booleane şi calcule algebrice pe

intrări multiple;

WGIS.57 Să permită realizarea analizelor zonale sau de vecinătate;

WGIS.58 Să asigure realizarea diferitelor tipuri de analize statistice cu funcţii diferite

incluzând statistici de vecinătate, pe celulă, de suprapunere zonală şi statistici

multivariate;

WGIS.59 Să permită realizarea generalizării şi prelucrarea datelor pentru validare

WGIS.60 Să asigure instrumentele necesare analizelor de densitate: Kernel, Line şi Point

Density;

WGIS.61 Să permită realizarea clasificărilor, vizualizărilor şi generalizărilor datelor

grid;

5.2.5.7 Modul de monitorizare a sistemului

Ofertantul va pune la dispozitie o aplicatie software comercial care sa permita monitorizarea

echipamentelor, aplicatiilor si a fluxului informational din cadrul acestora pe mai multe

niveluri, pornind de la nivelul software pana la componentele hardware care sustin sistemul.

Modulul trebuie sa puna la dispozitie urmatoarele functionalitati:

MONIT.1 Sa poata administra evenimentele sistemelor de operare, printr-un jurnal de

evenimente la nivel de întreprindere care colecteaza şi raporteaza problemele şi

informatiile generate referitoare la sistemele şi aplicatiile din reteaua companiei.

MONIT.2 Sa permita monitorizarea switch-urilor, routerelor, imprimantelor si altor

dispozitive prin SNMP.

MONIT.3 Sa efectueze raportarea şi analiza tendintelor necesare pentru urmarirea

problemelor în timp şi generarea rapoartelor detaliate despre starea de functionare

generala a mediului administrat.

MONIT.4 Sa permita monitorizarea aplicatiilor distribuite pe mai multe servere;

MONIT.5 Sistemul trebuie sa detina un editor in mod grafic de componentele ale unui

serviciu;

MONIT.6 Sistemul trebuie sa permita monitorizarea si raportarea evenimentelor,

urmarirea nivelului de sanatate al sistemului

MONIT.7 Sistemul trebuie sa permita identificarea fiecarui echipament din retea printr-o

reprezentare grafica;

MONIT.8 Aceste rapoarte sa poata fi accesate local sau sa poata fi publicate în site-urile

Web pentru accesul facil la informatiile de administrare ale sistemelor.

93 / 234

MONIT.9 Modulul trebuie sa permita definirea de harti de monitorizare intr-un editor

grafic, cu posibilitati de a crea prin operatii de tip wizard si drag-n-drop:

a) Harta echipamentelor in rack

b) Harta aplicatiilor pe echipamente

c) Harta echipamentelor/aplicatiilor in camerele unde sunt instalate

d) Harta camerelor in cadrul cladirii(lor)

MONIT.10 Utilizatorul trebuie sa poata naviga intre harti astfel incat sa comute de

la un nivel de detaliere la altul, vizualizand oricand, in timp real, starea aplicatiilor si a

echipamentelor monitorizate

MONIT.11 In cadrul unui proces informational utilizatorul trebuie sa poata sa

ajunga repede, din elementele de proces monitorizate pana la pozitia in rack a

echipamentului care a produs defectiunea.

MONIT.12 Modulul trebuie sa permita crearea de harti de proces, geografice,

topologice sau de tip panou de bord pe care sa se pozitioneze elementele monitorizate

MONIT.13 Hartile elementelor monitorizate sa poata fi afisate in baza rolurilor

utilizatorilor printr-un browser web.

MONIT.14 Sa prezinte portleti specifici pentru cel putin un portal (ex: Sharepoint,

Websphere, WebLogic)

MONIT.15 Sa permita crearea de rapoarte de disponibilitate a aplicatiilor pe baza

interdependentelor intre harti

5.2.5.8 Suita de aplicatii de productivitate și colaborare

SPRD.1 Suita pentru productivitate si colaborare trebuie instalata pe toate statiile

client livrate in proiect si trebuie sa indeplineasca urmatoarele cerinte:

a) să fie un sistem integrat pentru îmbunătățirea productivității

b) să fie o suită de programe destinate să lucreze împreună pentru rezolvarea

diverselor probleme

c) să ofere acces la informații pentru realizarea de acțiuni eficiente și decizii

inteligente

d) să asigure lucrul rapid și eficient

e) să aibă suport pentru extinderea functionalității prin dezvoltarea de module

integrabile

f) să poată sa partajeze informații și conținut între aplicațiile din suită

g) să aibă o instalare facilă și automatizată a pachetului de programe

h) interfață localizată în limba română (meniuri, submeniuri, ajutor în limba

română)

i) suport tehnic local

94 / 234

j) corector ortografic şi gramatical în limba română

k) sa aiba suport pentru Portable Document Format file (PDF)

SPRD.2 Aplicație de editare, formatare și partajare documente cu următoarele

caracteristici:

a) suport pentru editarea documentelor folosind caractere românești corecte și

tastatura românească standardizată

b) crearea, urmărirea, modificarea, gestionarea comentariilor și modificarilor

pentru documente precum si previzualizarea modificărilor în timp real

c) suport pentru standard deschise de documente precum și de scheme

particularizate de documente

d) facilităţi avansate de formatare (dimensiune font, paragraf, borduri, marcatori

şi numerotare, coloane, tabelatori, inserare numerotare pagini în variante

complexe (subcapitole, număr pagină din număr total de pagini etc.) şi

vizualizare (antet şi subsol, format pagină tipărită, marcaje de urmărire etc.).

e) suport pentru inserarea de tabele şi posibilitatea de desenare de grafice într-un

format avansat (inserarea de forme automate – săgeţi, scheme logice, stele şi

forme ondulate, conectori şi linii drepte sau ondulate, inserarea de casete de

text sau icoane de tip WordArt-uri, posibilităţi de colorare sau de umplere cu

culoare a spaţiilor goale)

f) panou de cercetare şi referinţe

g) suport pentru controlul și versionarea documentelor

h) panou de citire, destinat persoanelor cu dizabilităţi vizuale

i) inspector de documente, pentru scoaterea informaţiilor ascunse sau

confidenţiale; controlul aplicatiilor de tip macro

j) gestiunea certificatelor de securitate

k) unelte pentru recuperarea documentelor

l) suport pentru compararea a doua documente asemanatoare, cu afisarea

diferentelor si asemanarilor dintre documente

SPRD.3 Aplicație pentru calcul tabelar:

a) suport pentru editarea tabelelor folosind caractere românești corecte și


b) suport pentru standard deschise de documente

c) librărie de conexiune de date, integrare cu sisteme de baze de date şi aplicaţii

construite pe standarde deschise

d) suport pentru tabele cu număr mare de rânduri (minim 500.000)

e) suport pentru formatare condițională

f) suport pentru conectare la sisteme de tip Business Inteligence

g) motor de generare grafice (de ex. pie-chart, bars, points, samd)

h) inspector de documente, pentru scoaterea informaţiilor ascunse sau

confidenţiale; controlul aplicatiilor de tip macro

i) suport pentru ecuații matematice

95 / 234

j) suport pentru semnături digitale si gestiunea certificatelor de securitate

k) unelte pentru recuperarea documentelor

SPRD.4 Aplicație pentru colaborare și mesagerie :

a) suport pentru editarea mesajelor folosind caractere românești corecte și


b) suport pentru gestiunea mesajelor de poştă electronică, a calendarelor, a

persoanelor de contact

c) eliminarea mesajelor e-mail nesolicitate de tip SPAM și blocarea

atasamentelor periculoase

d) posibilitatea de căutare în corpul mesajelor, în cadrul persoanelor de contact și

în calendar

e) panouri de asistență pentru utilizare si ajutor

f) integrare cu sisteme de tip instant messaging

g) inspector de documente, pentru scoaterea informaţiilor ascunse sau

confidenţiale; controlul aplicațiilor de tip macro pentru creșterea nivelului de

securitate

h) suport pentru semnături digitale și pentru criptarea documentelor și a

mesajelor

i) sa asigure administrarea mesajelor electronice primite şi trimise într-un mod

intuitiv

j) sa permita evidenţa persoanelor de contact (inclusiv nume, prenume, funcţie,

telefon fix, mobil, fax, adrese acasă, firmă, adrese email, adresă web, etc).

k) Programul trebuie, de asemenea, să includă calendar, listă de activităţi zilnice

sau programate la diferite date, posibilitatea de import / export de certificate.

SPRD.5 Aplicație pentru prezentări grafice:

a) suport pentru editarea prezentărilor folosind caractere românești corecte și


b) suport pentru multimedia, integrare ți rulare fisiere audio si video

c) panouri de asistență pentru utilizare și ajutor

d) panou de cercetare şi referinţe

e) suport pentru controlul si versionarea documentelor

f) inspector de documente, pentru scoaterea informaţiilor ascunse sau

confidenţiale

g) suport pentru documente semnate electronic și criptare

h) gestiunea certificatelor de securitate

i) suport pentru vizualizarea elementelor suplimentare doar pentru prezentator

precum timp scurs, notițe, pagini următoare în paralel cu rularea prezentării

pentru audiență

j) unelte pentru recuperarea documentelor

5.2.5.9 Solutie antivirus

96 / 234

5.2.5.9.1 Caracteristici generale minimale si eliminatorii:

AVIR.1 detectia si dezinfectia atat a virusilor internationali cat si a celor regionali

(Europa de Est)

AVIR.2 producatorul trebuie fie certificat ISO 9001 pentru productie de software

AVIR.3 se solicita autorizare de distributie/revanzare din partea producatorului pentru

revanzator;

AVIR.4 Ofertantul solutiei de securitate trebuie sa aibe un minim de 5 inginerii de

suport tehnic certificati de catre producatorul solutiei antivirus. Se solicita copie dupa

diplomele de certificare.

AVIR.5 Ofertantul trebuie sa fie certificat de catre dezvoltatorul solutiei de securitate.

Se solicita diploma si prezenta pe site-ul producatorului la rubrica parteneri.

AVIR.6 Certificari internationale obtinute cel tarziu in intervalul 2005 - 2010 (ICSA

Labs, Checkmark, Virus Bulletin, CheckVir etc); Se vor prezenta cel putin 4

certificate emise de organizatii europene pentru produsele anti-virus livrate de catre

ofertant.

AVIR.7 Posibilitatea de update centralizat a solutiei antivirus atat pentru statii cat si

pentru servere in mod automat/programat la un interval de maxim 1 ora;

AVIR.8 Existenta unui singur motor de scanare a antivirusului de statie, pentru a nu se

incarca suplimentar memoria sistemelor de calcul

AVIR.9 Din considerentele unei solutii complete cu management centralizat, intreaga

solutie va apartine aceluiasi producator

AVIR.10 Asigurarea si garantarea actualizarii semnaturilor de virus si upgrade la noi

versiuni pe intrega perioada care se va contracta, cu posibilitati de prelungire.

AVIR.11 Sa existe posibilitatea ca in cazul trecerii la alt sistem de operare si/sau server

de mail sa fie livrat un kit de instalare si certificat de licenta pentru produsul nou fara

costuri suplimentare.

5.2.5.9.2 Privind serviciile si echipa de suport tehnic:

AVIR.12 Avertizari prin e-mail asupra aparitiei noilor virusi

a) Mesaje de alerta in cazul aparitiei unor noi virusi distructivi sau cu potential

mare de rapandire rapida

b) Posibilitatea de a trimite aceste avertizari si la partenerii Beneficiarului pe

baza unor adrese de e-mail furnizate de acesta

AVIR.13 Posibilitatea furnizorului/producatorului de a raspunde unor solicitari cu

privire la incidente provocate de catre atacurile virusilor in termen de 24 ore prin

interventie in locatiile beneficiarului fizic/sau de la distanta folosind o aplicatie cu

urmatoarele particularitati (pe sistemele Windows):

a) Interventie real-time securizata, bazata pe un ticket cu durata limitata de

valabilitate;

b) Contact continuu intre inginerul suport tehnic si client prin intermediul unei

aplicatii de chat inclusa in sesiunea remote;

c) Vizibilitate totala asupra actiunilor intreprinse prin aplicatia remote;

d) Posibilitatea clientului de a prelua controlul in orice moment;

97 / 234

e) Conectare via plug-in web care nu necesita configurari suplimentare in

firewall-ul sau serverele clientilor

f) Nu necesita dezvaluirea parolelor de administrator de pe serverele clientilor.

AVIR.14 Antidot pentru orice virus nou semnalat de catre beneficiar

AVIR.15 Suport tehnic, telefonic, e-mail si chat non-stop, 24/24 in limba romana oferit

de producator. In oferta tehnica si comerciala furnizorul va prezenta numerele de

telefon si adresele de email la care beneficiarul poate accesa serviciile de suport

tehnic.

AVIR.16 Cel putin 3 dintre specialistii de suport tehnic ai producatorului solutiei

antivirus sa aiba certificari pe cel putin una din tehnologiile ofertate precum Microsoft

Certified Professional sau echivalent. Se vor prezenta copii ale certificarilor.

AVIR.17 Asistenta tehnica telefonica si remote la configurarea produselor

AVIR.18 Constatarea de deficienţe sau neconcordanţe între caracteristicile tehnice şi

funcţionale ale produsului livrat şi instalat şi cerinţele tehnice din caietul de sarcini

atrage după sine înlocuirea produsului software antivirus sau actualizarea acestuia, în

termen de 48 ore de la constatarea deficienţelor.

AVIR.19 Nu se admit neconcordanţe între performanţele, caracteristicile produselor

software antivirus livrate/instalate şi caracteristicile din specificaţia tehnică a

Caietului de sarcini.

5.2.5.9.3 Cerinte minime pentru produsele antivirus:

5.2.5.9.3.1 Antivirus pentru statii de lucru (mobile sau fixe) cu management

centralizat

AVIR.20 Metode de detectie a virusilor, a programelor spion, a rootkit-urilor, a

mesajelor de tip spam, a tentativelor de fraudare de tip phising si a altor programe cu

potential malitios

AVIR.21 Intefata grafica in limba romana

AVIR.22 Solutia de securitate pentru statii va fi livrata impreuna cu manualul de

utilizare in limba romana

5.2.5.9.3.2 Caracteristici si functionalitati principale ale modulului antivirus si

antispyware :

AVIR.23 Scanarea automata “on acces” (in timp real) a fisierelor care se copiaza de pe

suport extern si din LAN sau WAN

AVIR.24 Posibilitatea de a scana statiile client inainte de instalare. In acest fel se

detecteaza si elimina amenintarile de securitate existente

AVIR.25 Clientii antivirus pentru workstation sa permita scanarea transferurilor de

fisiere la comunicatii P2P (instant messaging)

AVIR.26 Scanarea euristica comportamentala prin simularea unui calculator virtual in

interiorul caruia sunt rulate aplicatii cu potential periculos protejand sistemul de

virusii necunoscuti prin detectarea codurilor periculoase a caror semnatura nu a fost

lansata inca

AVIR.27 Scanarea la cerere si la acces a oricarui suport de stocare a informatiei (FDD ,

HDD, CD-ROM)

98 / 234

AVIR.28 Scanarea in urmatoarele arhive si efectuarea dezinfectarii intr-o serie de

formate uzuale (arj, ace, cab, dbx, docfile, gzip, lha, mbx, mime, pdf, pst, rar, rpm, rtf,

sfx, tar, zip, thebat)

AVIR.29 Scanarea automata a e-mailurilor la nivelul statiei de lucru indiferent de

clientul de e-mail folosit la nivelul POP3

AVIR.30 Posibilitatea selectarii tipului principal si secundar de actiune la detectarea

unui mesaj infectat

AVIR.31 Posibilitatea trimiterii de mesaje de alerte automate catre adresa de e-mail a

destinatarului in caz de detectie a unui mesaj infectat.

AVIR.32 Mesaje pe ecran sub forma de fereastra pop-up in momentul detectarii unui e-

mail infectat

AVIR.33 Configurarea cailor ce urmeaza a fi scanate, inclusiv la nivel de fisiere;

AVIR.34 Clientii antivirus pentru workstation sa permita excluderea de la scanarea “on-

access” (in timp real) a fisierelor de anumite dimensiuni, cu posibilitatea definirii

dimensiunilor respective

AVIR.35 Clientii antivirus pentru workstation sa permita definirea unor liste de

excludere de la scanarea “on-access” si “on demand” (in timp real si la cerere) a

anumitor directoare, discuri, fisiere sau extensii.

AVIR.36 Clientii antivirus pentru workstation trebuie sa contina optiunea de pauza si

reluare a scanarilor

AVIR.37 Clientii antivirus pentru workstation sa permita monitorizarea activa a

registrilor afisand mesaje de atentionare a utilizatorului in momentul in care o

aplicatie incearca sa modifice cheile registrilor

AVIR.38 Cu ajutorul unei baze de date complete cu semnaturi de spyware si a euristicii

de detectie a acestui tip de programe, produsul va trebui sa ofere protectie anti-

spyware si sa permita prevenirea furtului de date confidentiale.

AVIR.39 Clientul antivirus pentru worstation trebuie sa functioneze atat in cadrul retelei

interactionand cu consola de management cat si in mod standalone cu posibilitatea de

actualizare atat din LAN cat si de pe serverul producatorului solutiei fara ca

utilizatorul sa intervina asupra setarilor

AVIR.40 Pentru a nu incarca resursele sistemului produsul antivirus trebuie sa contina

un singur motor de scanare si sa poata rula scanarile programate cu prioritate redusa

AVIR.41 Mod de vizualizare grafica a procesului de scanare la acces precum si a

activitatii in Internet, afisata permanent la nivelul statiei de lucru

5.2.5.9.3.3 Firewall:

AVIR.42 Firewall protectie a datelor si filtrarea traficului la intrare si la iesire,

controland fisierele de tip cookie, blocand scripturile malitioase si programele de tipul

„XXX-dialer”.

AVIR.43 Predefinirea setului de reguli ce urmeaza a fi aplicate in mod automat

AVIR.44 Controlul fisierelor de tip script si cookie

99 / 234

AVIR.45 Posibilitatea de a stabili tipul de lucru „invizibil” la nivelul retelei locale sau

Internet

5.2.5.9.3.4 Antispam:

AVIR.46 Tehnologiile antispam sa permita adaptarea la noile tehnici de lansare a spam-

ului, analizand si memorand preferintele utilizatorului, reducand astfel la minim

numarul mesajelor legitime etichetate ca spam.

AVIR.47 Filtrul antispam sa poata fi antrenat de catre utilizator, prin simpla clasificare a

catorva e-mail-uri ca spam sau legitime

AVIR.48 Filtrare a mesajelor Spam de tip imagine

AVIR.49 Posibilitatea blocarii mesajelor e-mail in functie de limba utilizata la scrierea

acestora

AVIR.50 Folosirea filtrului antispam “antrenat” pe baza unei serii de mesaje spam astfel

incat acesta sa poata recunoaste noile mesaje de acest tip prin identificarea

asemanarilor cu cele pe care le-a examinat deja.

5.2.5.9.3.5 Carantina:

AVIR.51 Produsul antivirus sa permita trimiterea manuala si automata a fisierului din

carantina catre laboratorul antivirus.

AVIR.52 Produsul antivirus sa permita stergerea automata a fisierelor duplicate sau a

celor carantinate mai vechi de o anumita perioada, pentru a nu incarca inutil spatiul de

stocare

AVIR.53 Posibilitatea de a muta un fisier din carantina in locatia lui originala

5.2.5.9.3.6 Administrare si instalare remote:

AVIR.54 Posibilitatea de a avea o consola centrala care la randul ei sa poataa avea

subordonate mai multe console care pot indeplini aceleasi functii

AVIR.55 Posibilitatea creari unui singur kit de instalare , utilizabil atat pentru sistemele

de operare 32-bit cat si pe 64-bit

AVIR.56 Posibilitatea de instalare a clientilor antivirus doar cu anumite module ( ex:

fara antiphising )

AVIR.57 Clientii antivirus instalati pe statiile de lucru vor permite adaugarea modulelor

de securitate care au fost omise la instalarea initiala.

AVIR.58 Atat la nivel de server de management cat si la nivel de statie sa fie permis

importul si exportul setarilor

AVIR.59 Posibilitatea de dezinstalare automata a solutiei de securitate antivirus

existente in prezent utilizand scripturi WMI

AVIR.60 Detectare automata a statiilor nou intrate in retea cu posibilitatea de instalare

automata a protectiei antivirus pe acestea

AVIR.61 Detectia statiilor de lucru fara protectie dupa numele acestora si dupa plaja de

adrese IP

AVIR.62 Automatizarea, pe baza de politici de securitate, a activitatilor administrative

de rutina

100 / 234

AVIR.63 Clientii antivirus pentru workstation sa permita scanarea programata, respectiv

verificarea, periodica sau numai la anumite momente, a sistemului fara interventia

utilizatorului

AVIR.64 Protejarea prin parola a accesului la consola de management a solutiei

antivirus

AVIR.65 Protejarea prin parola a clientilor antivirus astfel incat dezinstalarea acestora

sa fie posibila doar daca se introduce parola de administrator a sistemului.

AVIR.66 Asigura respectarea politicilor de securitate ale companiei de catre utilizatorii

statiilor de lucru mobile, chiar si atunci cand acestea nu sunt conectate la retea

AVIR.67 Produsul trebuie sa permita administratorului de retea sa instaleze/dezinstaleze

programe (instalate cu MSI installer) de pe statiile client prin utilizarea de script-uri

WMI la cerere si programat.

AVIR.68 Posibilitatea de a stabili restrictii, la nivel de utilizator, legate de accesul la

site-uri web nesigure sau cu continut inadecvat, precum si la anumite aplicatii precum

si limitarea accesului la Internet in anumite intervale de timp.

AVIR.69 Posibilitatea de a colecta de informatii legate de componentele si sistemele

informatice ale statiilor de lucru prin utilizarea de script-uri de administrare WMI.

AVIR.70 Permite stabilirea a doua tipuri de clienti - clientii autorizati, cu acces nelimitat

la interfata si clientii restrictionati, cu acces limitat la interfata

AVIR.71 Posibilitatea de notificare a administratorului in cazul in care clientii de

workstation au fost inactivi un numar de zile predefinit

AVIR.72 Posibilitatea de a instala/dezinstala programe nedorite de pe statiile de lucru in

mod programat

5.2.5.9.3.7 Rapoarte si grafice:

AVIR.73 Clientii antivirus pentru workstation sa permita generarea de rapoarte

complete privind rezultatele scanarii si infectiilor detectate dar si a tuturor obiectelor

scanate

AVIR.74 Posibilitatea de a crea rapoarte pe baza unor sabloane de rapoarte definite in

consola de management.

AVIR.75 Posibilitatea de a crea rapoarte pe useri si grupuri de useri.

AVIR.76 Posibilitatea de a exporta rapoarte

5.2.5.9.3.8 Backup

AVIR.77 Posibilitatea realizarii unor copii de rezerva a datelor importante la nivel local,

pe statiile de lucru sau direct pe medii de stocare externe: CD, DVD

5.2.5.9.3.9 Actualizare:

AVIR.78 Actualizarea antivirus sa poata fi facuta automat la un interval de maxim 1 ora,

on demand

AVIR.79 Posibilitatea efectuarii update-ului la nivel de client de workstation in mod

silentios (fara avertizare)

AVIR.80 Posibilitatea de a astepta restartarea calculatorului dupa efectuarea actualizarii

fara a notifica utilizatorul

101 / 234

AVIR.81 Posibilitatea stabilirii intervalului de descarcare a actualizarilor

AVIR.82 Posibilitatea de a configura servere de actualizare cascadate

5.2.5.9.3.10 Antivirus pentru servere de fisiere pe platforma Windows :

AVIR.83 Protectie antivirus, antispyware si antirootkit


on demand




lansata inca

AVIR.86 Marcarea „read only” a fisierelor scanate in cadrul aceleiasi sesiuni si

rescanarea acestora numai in cazul unei noi sesiuni, update sau infectie in cadrul

sistemului.

AVIR.87 Scanare in timp real a fisierelor ce trec prin server, atat la deschiderea acestora

cat si la inchidere; posibilitatea scanarii la cerere si a serverului pe care este instalat




AVIR.89 Administrare sa poata fi facuta centralizat din cadrul consolei de

management globale sau independent

AVIR.90 Posibilitatea scanarii la alegere doar a fisierelor avand extensiile specificate de

administrator precum si optiunea de scanare numai a fisierelor de o dimensiune mai

mica decat o limita stabilita de administrator

AVIR.91 Posibilitatea de definire a proceselor care sa fie excluse de la scanare.

AVIR.92 Posibilitati de actiuni multiple la detectia unui virus (disinfect, delete, mutare

in carantina)

AVIR.93 Posibilitatea de a seta locatia de carantina unde vor fi stocate mailurile virusate

– in functie de optiunea administratorului

AVIR.94 Produsul va trebui sa ofere rapoarte si statistici detaliate referitoare la scanarea

antivirus

AVIR.95 Update configurabil de pe internet cu setari specifice unui proxy (user si

password) sau din cadrul retelei de pe un server de update propriuSe vor trimite

notificari la detectarea unui mail virusat in functie de optiunile alese la administrator

AVIR.96 Posibilitatea de notificare prin mail a existentei unei versiuni noi a produsului

instalat.

AVIR.97 Posibilitatea de export a setarilor produsului pentru a putea fi importante la o

instalare ulterioara sau pe un alt server de fisiere.

AVIR.98 Sa se poata integra in consola de administrare Windows MMC.

AVIR.99 Produsul se va integra in cadrul consolei de management unitar al solutiei

antivirus

5.2.5.9.3.11 Antivirus pentru servere de fisiere Linux/Unix (Samba File Server)

AVIR.100 Compatibilitate cu sisteme de operare Linux/Unix

102 / 234




lansata inca

AVIR.102 Posibilitatea produsului de a monitoriza disponibilitatea propriilor module in

vederea verificarii functionalitatii acestuia

AVIR.103 Cel putin 2 certificari pentru doua distributii diferite de Linux/Unix

AVIR.104 Respectarea completa a standardului FHS (Filesystem Hierarchy Standard)

fara ingerinte in sistem

AVIR.105 Compatibil cu sistemele de monitorizare SNMP

5.2.5.9.3.12 Antivirus, antispyware pentru servere e-mail


on demand precum si fortat de catre producatorul antivirusului in momentul aparitiei

unei amenintari virale astfel incat sa nu existe brese de timp intre aparitia semnaturilor

de virusi aparute pe site-ul producatorului si momentul actualizarii serverului de mail.




lansata inca

AVIR.108 Produsul trebuie sa ofere protectie antivirus, antispam, content filtering,

attachment filtering si sa asigure scanarea bazelor de date

AVIR.109 Asigura scanarea atasamentelor si a continutului mesajelor in timp real, fara a

afecta vizibil performanta serverului de mail.

AVIR.110 Produsul va trebui sa ofere optiuni multiple la identificarea unui atasament

virusat (disinfect, delete, mutare in carantina)




AVIR.112 Produsul va trebui sa ofere protectie antispam, configurabila cu o baza de

semnaturi actualizabila prin internet; vor exista optiuni de de configurare: stergere,

redirect, reject precum si marcare a mailurilor de tip spam.

AVIR.113 Pentru scanarea antispam va trebui sa existe posibilitatea de a seta nivelul de

agresivitate al filtrului, black-list si white-list configurabile la nivelul

administratorului, filtru URL si scoring dupa tipurile de caractere folosite (chirilice,

asiatice)

AVIR.114 Produsul va trebui sa ofere filtru RBL care sa identifice spam-ul prin

sincronizarea cu anumite baze de date online care contin liste de servere de mail

cunoscute ca fiind la originea acestui tip de mesaje.

AVIR.115 Produsul va trebui sa ofere filtru Bayesian antrenabil, capabil sa identifice

mesajele spam prin intermediul examinarii unor exemple concrete de e-mailuri din

Inbox, exemple pe baza carora filtrul “invata” sa diferentieze spam-ul de e-mail-urile

legitime.

103 / 234

AVIR.116 Produsul va trebui sa ofere anti-phishing, care sa detecteze tentativele de

copiere a infatisarii si continutului mesajelor autentice in vederea pacalirii

destinatarului acestora pentru obtinerea ilegala de date confidentiale.

AVIR.117 Se vor trimite notificari la detectarea unui mail virusat in functie de optiunile

alese la administrator, sender sau receiver

AVIR.118 Posibilitatea de a seta locatia de carantina unde vor fi stocate mailurile virusate

– in functie de optiunea administratorului

AVIR.119 Produsul va trebui sa ofere rapoarte si statistici detaliate atat referitoare la

scanarea antivirus cat si la scanarea antispam

AVIR.120 Produsul va trebui sa poata defini politici de filtrare antivirus, antispam, a

continutului sau a atasamentului pentru diferiti utilizatori sau grupuri

AVIR.121 Update configurabil de pe internet cu setari specifice unui proxy (user si

password) sau din cadrul retelei de pe un server de update propriu

AVIR.122 Posibilitatea de notificare prin mail a existentei unei versiuni noi a produsului

instalat.Produsul se va integra in cadrul consolei de management unitar al solutiei

antivirus

5.2.5.10 Sisteme de operare

SISO.1 Pentru servere se cere sistemul de operare Unix, Linux sau Windows in

functie de componentele software

SISO.2 Sistemele de operare server vor avea urmatoarele caracteristici:

a) să aibă la baza tehnologii verificate de-a lungul timpului

b) sa ruleze pe echipamentele hardware livrate

c) să asigure un suport complet pentru sistemul aplicativ şi să furnizeze un înalt

nivel de fiabilitate

d) trebuie să permită rularea pe procesoare cu 64 biți

e) sa aiba instrumente de administrare performante

f) sa permita virtualizare si partionarea serverelor (procesoare, memorii, I/O,

etc.)

SISO.3 Clientii utilizaţi trebuie operaţi unitar cel puţin cu sistemul de operare

Windows 7 Professional sau echivalent/superior din punct de vedere functional

5.2.5.11 Soluţia CRM

5.2.5.11.1 Cerinte generale

SCRM.1 Soluţia propusă trebuie să se bazeze pe un pachet de aplicaţii software

disponibile comercial (COTS –Commercial off the Shelf) de tip CRM (Customer

relationship management), care să funcţioneze integrat şi să fie testate în alte

implementări similare.

104 / 234

SCRM.2 Soluţia propusă trebuie să se bazeze pe un pachet de aplicaţii software care

trebuie să provină de la acelaşi producător, iar aplicaţiile trebuie să fie nativ integrate.

SCRM.3 Pachetul de aplicaţii software propus trebuie să nu impună alegerea unei

anumite platforme tehnologice, fiind capabil să ruleze pe multiple sisteme de operare

şi baze de date.

SCRM.4 Furnizorul pachetului software va trebui să facă accesibile standardele şi

instrumentele de dezvoltare utilizate în realizarea produsului, precum şi interfeţele

standard, astfel încât să permită extinderea acestuia şi realizarea schimbului de date cu

sisteme exterioare.

SCRM.5 Se va oferi Beneficiarului posibilitatea de a customiza/modifica aplicaţiile

standard livrate de producător, conform cerinţelor prezente sau viitoare.

SCRM.6 Instrumentele de dezvoltare oferite trebuie să dea posibilitatea specialiştilor IT

aparţinând Beneficiarului de a interveni asupra aplicaţiilor, cum ar fi modificarea unui

ecran de introducere a datelor în aplicaţiile livrate etc.

SCRM.7 Efectele implementării unui astfel de sistem trebuie să ducă la:

a. Îmbunătăţirea calităţii serviciilor prestate de organizaţie pentru cetăţeni;

b. Reducerea numărului de angajaţi care intră în contact cu o persoană care

doreşte obţinerea de informaţii necesare;

c. Rezolvarea eventualelor probleme sau informarea despre unele aspecte pe care

trebuie să le aducă la cunoştinţa cetăţeanului;

d. Reducerea costurilor de comunicare cu fiecare cetăţean/solicitant;

e. Reducerea timpului de răspuns la problemele sesizate;

f. Realizarea unei imagini mai bune a organizaţiei în relaţia cu cetăţenii.

SCRM.8 Principalele funcţionalităţi care se doresc acoperite de soluţia CRM:

a. Gestiunea informaţiilor despre cetăţeni;

b. Gestiunea interacţiei cu cetăţenii pe următoarele canale de interacţie:

i. Call Center (telefonie);

ii. E-mail;

iii. Fax;

iv. Web (portal pentru cetăţeni);

v. Direct (centru de relaţii cu publicul, corespondenta);

c. Gestiunea solicitărilor/cererilor/reclamaţiilor:

d. Gestiunea relaţiei cu unităţile, instituţiile şi agenţiile deservite;

e. Gestiunea campaniilor de informare şi sondajelor.

SCRM.9 Ofertantul va prezenta detaliat modul în care soluţia oferită susţine necesităţile

enumerate mai jos.

5.2.5.11.2 Gestiunea informaţiilor despre solicitanţi/cetăţeni

SCRM.10 Soluţia oferită trebuie să aibă la bază un model de date predefinit, specific

relaţiei cu solicitanţii în cadrul sectorului public. Ofertanţii vor descrie elementele

specifice sectorului public din modelul de date şi vor specifica referinţele soluţiei în

cadrul organizaţiilor din Administraţia Publică şi Ordine Publică.

105 / 234

SCRM.11 Soluţia oferită trebuie să permită înregistrarea şi administrarea informaţiilor

specifice despre solicitanţi, atât persoane fizice cât şi persoane juridice.

SCRM.12 Modelul de date trebuie să fie flexibil, extensibil şi deschis pentru a putea

stoca toate atributele şi informaţiile necesare (structurate sau nestructurate). În plus,

modelul de date trebuie să permită încărcări periodice sau on-line de date din alte

sisteme interne sau externe.

SCRM.13 Soluţia oferită trebuie să ofere posibilitatea de înregistrare a datelor de contact

ale solicitanţilor, respectiv nume, CNP, adrese de domiciliu, loc de muncă, ocupaţie,

adrese de email şi numere de telefon multiple.

SCRM.14 Soluţia oferită trebuie să aibă capacitatea să reţină modalitatea de contact

(telefonic, e-mail, scrisoare, fax) pe care o preferă solicitantul pentru interacţiile

ulterioare (ex. în cazul în care sunt necesare informaţii suplimentare pentru rezolvarea

solicitării, notificarea rezoluţiei, etc.).

SCRM.15 Soluţia oferită trebuie să ofere posibilitatea înregistrării informaţiilor de natură

demografică ale solicitanţilor (sex, data naşterii, statut marital, etc.), care sunt

relevante pentru soluţionarea cererii sau care pot sta la baza rapoartelor şi analizelor.

SCRM.16 Soluţia oferită trebuie să permită înregistrarea şi păstrarea istoriei complete de

relaţionare a solicitanţilor cu M.A.I. prin Centru de Contact, de pe toate canalele de

interacţie şi zonele de servicii.

SCRM.17 Vor fi prevăzute următoarele aspecte:

a. Gestiunea solicitanţilor/cetăţenilor, identificându-se şi colectând informaţiile

şi caracteristicile unice specifice acestora;

b. colectarea datelor referitoare la un anumit solicitant/cetăţean din surse

multiple:

i. date operaţionale,

ii. înregistrări ale schimburilor de informaţii dintre organizaţie şi cetăţean,

folosind pentru aceasta machete standard pentru cereri, sugestii,

reclamaţii, recomandări formulate de către cetăţeni etc.;

iii. transformarea datelor colectate despre solicitanţi, din mai multe surse,

într-o informaţie coerentă, în scopul analizei şi prezentării unei imagini

complete despre solicitant;

c. regăsirea informaţiilor, utilizatorul având acces rapid la:

i. oricare solicitant/cetăţean din baza de date;

ii. informaţiile vehiculate între organizaţie şi solicitant sau grupa de

solicitanţi selectată.

SCRM.18 Fişa fiecărui solicitant va cuprinde următoarele informaţii:

a. Informaţii specifice despre solicitanţi;

b. informaţii privind identitatea solicitantului (persoană fizică sau reprezentant al

unei persoane juridice, inclusiv informaţiile privind persoana juridică pe care o

reprezintă). Informaţiile furnizate de solicitant vor putea fi verificate în baza

de date a Evidenţei persoanelor;

c. informaţii de contact (adrese, nr. telefon, e-mail, canalul preferat de contact);

SCRM.19 Informaţii privind relaţia solicitantului cu M.A.I:

106 / 234

a. cererile şi răspunsurile transmise/primite, recomandările şi opţiunile

formulate;

b. proprietăţi ale solicitantului, dacă acestea fac obiectul cererii;

c. răspunsurile care s-au formulat şi transmis;

d. reclamaţiile şi sesizările prezentate de către solicitant privind modul de

rezolvare a cererilor sale.

SCRM.20 Informaţii ce vor fi folosite în vederea stabilirii de măsuri proactive:

a. informaţii demografice şi de clasificare;

b. informaţii privind relaţiile între entităţi (reprezentaţi ai unei companii, membri

familie, sucursale, etc.).

SCRM.21 Configurarea aplicaţiei de CRM se va face de către ofertant în etapa de

implementare a Centrului de Contact în urma consultării cu Beneficiarul pe baza unei

analize privind:

a. grupele de solicitanţi;

b. tipurile de cereri gestionate şi modalităţile de culegere a informaţiilor specifice

fiecărui tip de cerere;

c. procesele de rezolvare.

5.2.5.11.3 Gestiunea interacţiei cu solicitanţii/cetăţenii

SCRM.22 Aceasta arie funcţională are drept scop gestiunea integrată a interacţiilor cu

cetăţenii şi integrarea cu gestiunea informaţiilor şi relaţiilor cu aceştia, în scopul

consolidării şi unificării canalelor de comunicare şi interacţie cu solicitanţii, precum şi

creşterii calităţii acestora şi a serviciilor oferite.

SCRM.23 În acest scop, se va realiza o unificare a interacţiei în sine cu conţinutul

solicitării şi cu activităţile declanşate în urma acesteia (rezolvarea solicitării).

Indiferent dacă interacţia este iniţiată de M.A.I. sau de cetăţean, dacă este vorba

despre un schimb de informaţii, o cerere de audienţă, o cerere de asistenţă, o

reclamaţie, o contestaţie etc., soluţia propusă va permite înregistrarea în sistem a

conţinutului solicitării şi gestiunea procesului de rezolvare. De asemenea, soluţia

propusă va permite implementarea unor proceduri standard de lucru pentru abordarea

şi rezolvarea cererilor şi informărilor de orice tip venite de la cetăţeni precum şi a

comunicărilor iniţiate de organizaţie către cetăţeni.

SCRM.24 Soluţia trebuie să permită solicitanţilor posibilitatea de a cere asistenţă

utilizând canalul de interacţie preferat şi să captureze conţinutul şi finalitatea acestei

interacţii. De asemenea, prin gestionarea controlată a canalelor moderne de interacţie,

Centrul de Contact va asigura informarea şi asistenţa contribuabililor, optimizând în

acelaşi timp costurile interne la nivel de organizaţie.

5.2.5.11.4 Canalul telefonie - CTI (Computer Telephony Integration)

SCRM.25 Soluţia CRM ofertată va trebui să permită folosirea telefonului de către agent

direct din aplicaţie, fără a fi necesar lucrul cu mai multe ecrane ale unor aplicaţii

diferite. În acest scop aplicaţia va oferi capabilităţi de tip “softphone” sau toolbar

pentru comunicaţii care să permită accesul utilizatorului la funcţiuni de telefonie

107 / 234

(răspuns/iniţiere/întrerupere apel, transfer, conferinţă, etc.). Pe lângă acestea, soluţia

trebuie să permită preluarea din centrală a informaţiilor privind apelurile precum şi a

informaţiilor înregistrate în IVR ceea ce va permite o mai bună alocare şi o mai bună

pregătire a operatorului pentru a susţine interacţia.

SCRM.26 Operatorii vor fi ghidaţi de scripturi pentru susţinerea interacţiei astfel încât să

se asigure un tratament adecvat al solicitanţilor şi preluarea tuturor informaţiilor

relevante de la primul apel.

SCRM.27 Soluţia ofertată trebuie să permită logarea unică a operatorului direct în

interfaţă fără a fi necesare logări adiţionale pe echipamentele telefonice.

SCRM.28 Soluţia oferită trebuie să permită operatorului de Centru de Contact să incheie

conversaţia telefonică deschisă apăsând cu un click de mouse pe butonul respectiv

afisat de software sau folosind taste rapide. Dupa ce încheie apelul în acest mod,

operatorul trebuie să fie liber să preia apelul următor.

SCRM.29 Soluţia oferită trebuie să permită transferul apelului şi datelor: când un apel

este transferat, datele trebuie să fie transmise împreună cu apelul. Celălalt operator

trebuie sa aibă posibilitatea să vadă instant informaţiile solicitantului precum şi

înregistrările efectuate de primul operator.

SCRM.30 Soluţia ofertată trebuie să ofere facilitatea de conferinţă astfel încât agenţii să

poată implica experţi sau supervizori în convorbirile telefonice purtate cu solicitanţii.

SCRM.31 Soluţia oferită trebuie să suporte următoarele funcţii de supervizare: ascultare

apel, intervenţie în apel, deconectare apel, înregistrare convorbire, logare/ delogare

operator.

SCRM.32 Prin integrarea cu telefonia, soluţia trebuie să permită recunoaşterea automată

a apelurilor care vin, pentru ca agentul să poată să acceseze ultima cerere a

apelantului, înainte de a răspunde apelului, în acest fel fiind mai bine pregătit pentru a

susţine interacţia.

SCRM.33 Soluţia oferită trebuie să permită eventualele configurări care ţin de integrarea

cu telefonia (CTI- Computer telephony integration) cum ar fi „screenpops”

SCRM.34 Soluţia ofertată trebuie să permită accesul operatorului la Baza de cunoştinţe şi

soluţii pentru regăsirea rapidă a modului în care trebuie încadrată şi tratată o anumită

solicitare.

5.2.5.11.5 Canalul E-mail şi mesagerie

SCRM.35 Soluţia CRM ofertată va oferi şi conexiune e-mail. Pe de o parte soluţia

trebuie să permită înregistrarea solicitărilor primite pe e-mail şi pe de altă parte

cetăţenii, agenţii, supraveghetorii etc., să aibă posibilitatea să fie informaţi despre

acceptare şi despre procesarea cererii. Aceste e-mail-uri de notificare trebuie să fie

generate automat cu un text predefinit şi, de asemenea, trimise automat

solicitantului/cetăţeanului.

SCRM.36 Conexiunea la sistemul de e-mail se va face prin protocoalele POP3 over SSL,

IMAP over SSL şi/sau SMTP over SSL, sau POP3S, IMAPS şi SMTPS.

5.2.5.11.6 Canalul Fax

108 / 234

SCRM.37 Soluţia CRM ofertată va permite preluarea şi prelucrarea solicitărilor intrate

prin Fax. Integrarea cu canalul Fax va oferi şi suport outbound prin răspunsuri definite

în aplicaţie şi transmise prin Fax.

SCRM.38 Se va oferi şi instala o aplicaţie de fax-mail, astfel încât faxurile primite în

Centrul de Contact vor intra într-un server sub formă de e-mail. Pentru aceasta

furnizorul va realiza dimensionarea hardware şi software a soluţiei, astfel încât să se

poată primi minim 30 de transmisii fax simultan.

SCRM.39 Faxurile primite vor fi transferate în aplicaţie, care va permite înregistrarea

acestei interacţii cât şi preluarea conţinutului sub formă de ataşament.

SCRM.40 Soluţia oferită va permite crearea conţinutului şi transmiterea de fax-uri direct

din aplicaţie, prin integrarea cu acest canal.

SCRM.41 Pentru crearea de conţinut pentru fax-uri va fi inclusă posibilitatea utilizării de

şabloane.

SCRM.42 Interacţia prin fax va fi tratată în mod unitar la fel ca şi celelalte tipuri de

interacţii, înregistrându-se inclusiv canalul pe care a avut loc aceasta interacţie.

5.2.5.11.7 Canalul Web

SCRM.43 Soluţia CRM ofertată trebuie să ofere o componentă dedicată pentru accesul

direct al solicitanţilor/cetăţenilor în regim self/service. Această componentă va

permite solicitanţilor cel puţin:

a. acces controlat la baza de cunoştinţe şi proceduri;

b. acces la o secţiune tip FAQ;

c. înregistrarea solicitărilor în formulare web; aceste solicitări vor intra în

aceleaşi fluxuri de lucru ca şi celelalte solicitări înregistrate în Centrul de

Contact;

5.2.5.11.8 Canalul Direct şi Corespondenţa

SCRM.44 Soluţia CRM ofertată va permite accesul utilizatorilor din centrele de relaţii cu

publicul care au interacţii directe sau primesc corespondenţa de la solicitanţi, la

înregistrarea şi regăsirea informaţiilor despre solicitanţi şi solicitări. Aceştia vor avea

posibilitatea de a introduce solicitări şi de a scana documentele primite de la cetăţeni

şi a le asocia înregistrărilor din sistem.

SCRM.45 Soluţia va permite pentru toate categoriile de utilizatori definirea de

corespondenţă (outbound)

5.2.5.11.9 Gestiunea solicitărilor, cererilor, reclamaţiilor

SCRM.46 Această arie funcţională va oferi o platformă şi un cadru de activitate controlat

şi procedurat pentru gestiunea informaţiilor, relaţiilor şi comunicărilor implicate în

activităţile de rezolvare a cererilor şi sesizărilor, plângerilor şi contestaţiilor primite de

la cetăţeni pe orice canal de interacţiune (numite generic solicitări).

SCRM.47

SCRM.48 În acest scop, se va asigura gestiunea integrată, corelarea între resursele

interne implicate în aceste activităţi, informaţiile despre cetăţeni, relaţiile şi

comunicările cu aceştia care apar în cursul rezolvării cererilor şi cazurilor.

109 / 234

SCRM.49 De asemenea se va asigura accesul personalului autorizat implicat în aceste

activităţi la informaţiile relevante despre cetăţeni.

SCRM.50 Principalele aspecte care trebuie luate în considerare sunt următoarele:

5.2.5.11.10 Înregistrarea solicitărilor

SCRM.51 Solicitările vor putea fi înregistrate/preluate în sistem de pe oricare din

canalele de interacţie şi asociate la înregistrarea despre solicitant. Cererile introduse

pe canalul web direct de către solicitant respectând cerinţele de securitate ale

Beneficiarului, vor fi distribuite către Centrul de Contact pentru o prima validare şi

apoi introduse în fluxul de lucru. În cadrul şedinţelor de workshop vor fi definite, şi

ulterior implementate, şabloane specifice pentru fiecare tip de solicitare, conţinând

câmpuri obligatorii care să asigure preluarea tuturor informaţiilor relevante pentru o

anumită solicitare

5.2.5.11.11 Gestiunea resurselor

SCRM.52 Trebuie să existe posibilitatea definirii atât a resurselor individuale cât şi a

grupelor de lucru şi de alocare a cererilor în cadrul acestei organizări. Pentru fiecare

resursă/echipă va exista posibilitatea definirii de competenţe şi nivel de competenţe.

Fiecare utilizator va avea drepturi şi responsabilităţi specifice categoriei din care face

parte.

5.2.5.11.12 Fluxuri de lucru

SCRM.53 Este necesară posibilitatea definirii de fluxuri specifice de lucru pentru fiecare

tip/categorie de cerere. Fluxurile de lucru vor putea fi uşor vizualizate/modificate în

sisteme, de către Beneficiar. În cadrul unui flux de lucru se vor defini activităţile care

trebuie efectuate pentru rezolvarea solicitării, succesiunea lor şi timpul maxim admis

pentru execuţie. Acestea vor fi lansate automat în succesiunea definită şi alocate către

resursa responsabilă.

5.2.5.11.13 Criterii de alocare

SCRM.54 Alocarea solicitărilor şi a activităţilor se va face funcţie de o matrice bazată

pe:

a) Solicitantul/categoria de solicitanţi;

b) Tipul de solicitare;

c) Caracterul de gravitate/urgenţă al solicitării;

d) Setul de competenţe şi nivelul de competenţe a resursei;

e) Gradul de încărcare a resursei.

SCRM.55 Soluţia va permite transferul activităţii şi escaladarea activităţilor şi a

solicitărilor care se abat de la criteriile de conformitate sau procedurile stabilite (ex.

timp de răspuns depăşit).

5.2.5.11.14 Baza de cunoştinţe şi proceduri

SCRM.56 Pe tot parcursul fluxului de lucru, resursele vor avea acces la o bază de

cunoştinţe, soluţii şi proceduri în scopul asigurării standardizării activităţii. Cererile la

care s-a răspuns şi soluţia acestora pot fi imediat salvate într-o aşa numită “bază de

110 / 234

cunoştinţe”. Pentru a introduce date în această “bază de cunoştinţe” e nevoie de o

autorizare specială oferită de administrator, în acest fel asigurându-se uniformitatea

datelor.

SCRM.57 Pot fi asignate cuvinte cheie fiecărei înregistrări pentru ca a fi folosite de către

agenţi la căutare, pentru a răspunde cererilor. Dacă un agent găseşte un răspuns

adecvat în “baza de cunoştinţe” îl poate introduce într-un câmp tip soluţie al ticket-

ului său.

5.2.5.11.15 Gestiunea relaţiei cu unităţile, instituţiile şi agenţiile deservite

SCRM.58 Pentru solicitările care depăşesc nivelul de competenţă sau responsabilitate al

personalului din front office al Centrului de Contact şi care nu sunt nici de competenţa

personalului din back-office din structurile M.A.I. din municipiul Bucureşti se va

oferi o soluţie pentru transferare şi gestiune în cadrul unităţilor, instituţiilor şi

agenţiilor subordonate. Principiile de bază vor fi:

a. accesul controlat al personalului din cadrul acestor organizaţii la informaţii şi

solicitări;

b. gestiunea centralizată şi facilă a organizaţiilor şi a angajaţilor acestora cu

responsabilităţi privind rezolvarea solicitărilor;

c. neduplicarea informaţiei privind solicitanţii/solicitările în baze locale din

cadrul acestor organizaţii;

d. posibilităţi de prelucrare/rezolvare similare cu cele ale personalului din front-

office.

5.2.5.11.16 Gestiunea campaniilor de informare şi a sondajelor

SCRM.59 Accesul se va face prin intermediul unui portal dedicat pentru aceste

organizaţii.

SCRM.60 Soluţia oferită va permite identificarea necesităţilor de informare ale

populaţiei şi abordarea proactivă a acestor necesităţi prin campanii de informare în

masă. Vor fi oferite capabilităţi de definire, automatizare şi monitorizare a acestor

campanii. Campaniile vor putea fi adresate către grupuri specifice din cadrul

populaţiei. Conţinutul informării va fi publicat atât către utilizatorii interni care intră

în contact cu populaţia cât şi către public. Pentru populaţie se vor utiliza canale de

informare web, telefonic, şi e-mail, corespondenta.

SCRM.61 Pentru măsurarea activităţii Centrului de Contact şi identificarea modului în

care aceasta poate fi îmbunătăţită, va fi posibilă organizarea de sondaje privind gradul

de satisfacţie al solicitanţilor/populaţiei faţă de serviciile oferite. Sondajele vor putea

fi efectuate în legătură cu rezolvarea solicitărilor, ca un ultim pas în flux, prin

preluarea de feed-back-uri de la solicitanţi pe toate canalele de interacţie utilizate de

aceştia. De asemenea, vor putea fi organizate sondaje periodice pe un anumit subiect

care să nu fie legate de procesele de rezolvare a solicitărilor.

5.2.5.11.17 Necesităţi şi capabilităţi de integrare

SCRM.62 Integrare cu telefonia (CTI) în scopul susţinerii eficiente a interacţiei pe

canalul voce utilizând o interfaţă unică cu utilizatorul.

111 / 234

SCRM.63 Integrare cu e-mail. Toţi utilizatorii soluţiei CRM vor avea posibilitatea de a

transmite e-mailuri direct din aplicaţie (oubound). Pentru grupul specializat de

operatori din Centrul de Contact va fi posibilă primirea şi gestiunea mailurilor direct

în aplicaţie, prin integrarea completă a canalului e-mail cu înregistrarea în sistem a

interacţiei pe acest canal.

SCRM.64 Integrare Fax: Grupul specializat de operatori din Centrul de Contact vor avea

posibilitatea de a primi şi transmite Fax-uri direct din aplicaţie.

SCRM.65 Integrare cu aplicaţiile de tip Office. Capabilităţi de integrare şi

interoperabilitate cu alte sisteme. Sistemul va oferi posibilitatea de a se defini şi

monitoriza:

a. sistemele conectate;

b. tipul de conectare/transfer (inbound/outbound; on-line/batch) inclusiv

periodicitatea transferului batch;

c. informaţiile/datele schimbate cu aceste sisteme;

d. maparea pe structura de date interne;

e. regulile de completare/consolidare a informaţiei gestionate de sistem cu

informaţii din alte sisteme (completarea informaţiei despre solicitanţi,

solicitări);

SCRM.66 Vor fi prevăzute schimburile de informaţii inbound şi outbound despre

solicitanţi şi solicitări cu alte sisteme atât în timp real cât şi in mod batch.

5.2.5.11.18 Asigurarea calităţii informaţiei

SCRM.67 Soluţia oferită va trebui să permită asigurarea calităţii informaţiei gestionate

de sistem. Se vor avea în vedere asigurarea unicităţii informaţiei introduse în sistem

prin instrumente de identificare şi eliminare a duplicatelor.

SCRM.68 Identificarea duplicatelor se va face prin reguli configurabile de matching

(potrivire) completă sau parţială şi prin asignarea unui scor de matching. Eliminarea

duplicatelor trebuie să fie posibilă prin păstrarea informaţiei cu cel mai înalt grad de

încredere sau prin consolidarea informaţiei existente în mai multe înregistrări.

Eliminarea duplicatelor se va putea face automat sau manual funcţie de gradul de

matching şi de necesitatea unei decizii din partea personalului. Soluţia va oferi o

consolă de administrare pentru rolul de Data Quality Manager, în care vor putea fi

definite toate regulile de formatare şi unicitate (matching, eliminare, consolidare) şi

vor putea fi monitorizate aceste procese.

SCRM.69 Curăţarea şi deduplicarea datelor va fi posibilă prin procese batch sau în timp

real. Persoanele care introduc informaţii despre solicitanţi vor fi avertizate la

introducere despre existenţa unei înregistrări similare în sistem şi vor avea

posibilitatea să ia decizia vizând introducerea unui nou profil solicitant sau

deschiderea solicitării pentru un solicitant deja existent (care a mai avut solicitări în

trecut). Acest aspect este foarte important în asigurarea unor informaţii corecte şi

coerente despre solicitanţi, care vor sta la baza analizelor şi a deciziilor ulterioare.

5.2.5.11.19 Capabilităţi de lucru cu documente scanate

112 / 234

SCRM.70 Soluţia de CRM va oferi posibilitatea, directă sau prin integrare cu o

componentă dedicată, de a captura şi gestiona documente scanate în scopul procesării

electronice a informaţiilor importante blocate în documente stocate pe hârtie. Acest

lucru va permite gestiunea electronică a tuturor informaţiilor asociate solicitărilor, pe

întreg ciclul de rezolvare, inclusiv paşii care în stadiul incipient al sistemului nu pot fi

acoperiţi/procesaţi pe suport informatic, de exemplu cereri primite prin poştă în

format liber, aprobări interne cu semnătură olografă.

5.2.5.12 Server Web

SWEB.1 Componenta server web – este compusa din doua servere web cu balansare a

incarcarii

SWEB.2 Solutia server web trebuie sa poata rula in mod reverse-proxy si sa permita

ascunderea adreselor din domeniul intern.

SWEB.3 Componenta server web trebuie sa permita implementarea unei comunicatii

criptate folosind tehnologii de tip Secure Socket Layer (SSL) si sa fie compatibila cu

solutia de control acces.

SWEB.4 Cerinţele serverului web sunt :

a) Sa ofere suport pentru SSL si autentificare de baza

b) Să permită extensia functionalităţilor pe baza de plugin-uri sau module

c) Serverul web trebuie sa dispuna de plugin-uri astfel incat sa permita utilizarea ca

server de interfata pentru serverul de aplicatii

d) Serverul web trebuie sa permita implementarea unui mecanism de tip SSO in

conjunctie cu solutia de control acces

e) Serverul trebuie sa permita implementarea unei arhitecturi de tip PKI

f) Comunicatiile cu exteriorul retelei trebuie sa se realizeze atat criptat cat si in clar,

in functie de tipul informatiei ; suport SSL v3

g) Sa permita integrarea cu solutii de accelerare hardware a criptarii/decriptarii

h) Sa permita operarea in mod reverse-proxy

i) Sa dispuna de functionalitati de rescriere a adreselor URL

j) Sa dispuna de mecanisme de balansare a incarcarii

k) Sa permita configurarea intr-un mod de disponibilitate ridicata

l) Sa ofere suport pentru IPv4 si IPv6

113 / 234

m) Sa permita rularea continutului dinamic oferind suport cel putin pentru

tehnologiile PHP, JSP, C/C++

n) Sa permita port tunneling

o) Portabilitate pe multiple platforme harware si sisteme de operare

5.2.5.13 Server Portal

SPRT.1 Componenta Portal este compusa din minim doua servere cu balansare a

incarcarii pe care ruleaza serviciile portalului sistemului informatic pentru situatii de

urgenta.

SPRT.2 Scopul componentei Portal este de a consolida multiple interfete de utilizator

provenite de la diferite sisteme si aplicatii, si de a le face disponibile printr-un punct

unic de acces web, unde utilizatorii se pot autentifica, pentru a avea acces la toate

produsele si serviciile disponibile, in conformitate cu drepturile si rolurile lor din

sistem.

SPRT.3 Componenta portal va servi ca un punct de pornire pentru utilizatorii ce doresc

sa acceseze solutia. Astfel, interfetele de lucru catre toate componentele solutiei pot fi

prezentate ca parti ale aceleiasi solutii web, folosind diferite criterii de personalizare.

SPRT.4 In plus, componenta portal va asigura:

a) un mediu declarativ, bogat pentru crearea unei interfete web, publicarea si

administrarea informatiei, accesarea datelor dinamice, si adaptarea experientei

utilizatorilor folosind un framework pentru orice tehnologie web, cum ar fi

accesul la aplicatii bazat pe arhitectura J2EE si servicii web;

b) conectarea angajatii, partenerii si clientii cu informatia de care au nevoie in

format personalizat pentru fiecare comunitate de utilizatori;

c) organizarea si administrarea continutului web prin functionalitati de grupare a

paginilor in grupuri de pagini si definirea de sabloane de pagini;

d) setarile la nivel de grupuri de pagini ce controleaza sabloanele, paginile si

tipurile de obiecte, proprietatile si clasificarile elementelor de continut, si

traducerile lingvistice ce pot fi utilizate de paginile continute in respectivul

grup de pagini;

e) functionalitati avansate de personalizare si customizare;

f) control al nivelelor de customizare al paginii si al portletilor ce sunt

disponibile pentru utilizatori: de la simple privilegii de ascundere, afisare si

rearanjare pana la privilegii ce permit construirea unei pagini;

g) utilizarea standardelor de interoperabilitate cu ar fi XML, Portlet, WSRP Web

Services for Remote Portlets (WSRP) si Java Specification Request (JSR) 170

pentru integrarea facila si rapida cu orice serviciu expus de un sistem extern;

h) un grad ridicat de securitate pentru orice resursa gazduita sau accesata prin

intermediul interfetei unice de utilizare.

SPRT.5 Cerinţele componentei de portal sunt:

a) Interfaţă web standardizată, simplă şi intuitivă

114 / 234

b) Interfaţă cu utilizatorii bogată în funcţionalităţi, care să ofere un nivel ridicat

de accesibilitate, conform cu cerinţele nivelului I (A) de accesibilitate WCAG

versiunea 1.0

c) Grad ridicat de securitate a sistemului, care să garanteze confidenţialitatea şi

securitatea datelor utilizatorilor pentru accesul neautorizat atât dinafară cât şi

din interiorul sistemului

d) Rapoarte analitice asupra tuturor actiunilor utilizatorilor, care să ofere

posibilitatea de a analiza traficul şi activitatea utilizatorilor pe portal

e) Componenta de management de conţinut, care să permită stocarea şi

gestionarea într-o manieră sigură şi eficientă a tuturor secţiunilor ce vor fi

publicate prin intermediul portalului

f) Un framework unic de dezvoltare a portalului, astfel încât indiferent de tipul

de conţinut publicat în portal sau de tipul de aplicaţii, modul de integrare al

acestora în portal să fie consistent şi sigur

g) Administrare simplificată, pe intreg ciclul de viaţă al portalului

h) Servicii şi extensii ale portalului modulare, care să permită dezvoltarea

ulterioară de noi funcţionalităţi

i) Suport pentru servicii web şi Web Services for Remote Portlets (WRSP)

j) Arhitectură orientată pe servicii, astfel încât toate serviciile implementate

pentru gestionarea conţinutului în portal (publicare, căutare, versionare, etc.),

să poată fi reutilizate şi incluse în alte aplicaţii

k) Administrarea si dezvoltarea portalului se va putea realiza facil, utilizand doar

un browser web

l) Personalizarea experientei utilizatorilor prin posibilitatea personalizarii

interfatei de portal (aranjare in pagina, alegere skin-uri etc)

m) Sa contina un motor de cautare performant, care se permita efectuarea de

interogari in toate sursele de informatie prezente in mediul portal

n) Sa imbunatateasca experienta utilizatorilor prin utilizarea unor tehnologii

bazate pe Web 2.0 si AJAX

o) Sa ofere acces catre toate resursele prezente in cadrul portalului printr-o

singura autentificare, la deschiderea sesiunii

p) Suport pentru standardele deschise JSF, JSR 168, JSR 170

q) Sa ofere posibilitatea de a repozitiona portlet-ii in cadrul portalului prin

operatiuni simple de drag and drop

r) Sa ofere functionalitati Web 2.0, pentru a asigura interactiunea dintre

utilizatorii portalului

s) Sa ofere posibilitatea de a utiliza un director LDAP pentru a stoca si

administra utilizatorii portalului

t) Sa fie integrata cu software-ul de control al accesului la resurse

u) Sa fie integrata cu serverul web

v) Sa fie integrata cu serverul de aplicaţii

SPRT.6 Sa fie portabila pe multiple platforme harware si sisteme de operare

115 / 234

5.2.5.14 Server Aplicatie

SAPP.1 Componenta de Aplicatie este compusa din minim doua servere cu balansare a

incarcarii pe care ruleaza serviciile de logica a sistemului informatic pentru situatii de

urgenta.

SAPP.2 Serverul de aplicatii reprezinta componenta care asigura logica aplicatiilor

solutiei.

SAPP.3 Componenta server de aplicatii va asigura infrastructura software necesara

executiei aplicatiilor moderne bazate pe standarde deschise.

SAPP.4 Serverul de aplicatii trebuie sa asigure un set de servicii standard pe care toate

aplicatiile dezvoltate si instalate sa il poata accesa si utiliza:

a) servicii de clusterizare pentru o disponibilitate ridicata;

b) servicii de balansare si dirijare a incarcarii;

c) servicii de securitate pentru protejarea resurselor gazduite;

d) servicii de definire si context de executie pentru resursele de aplicatie:

conexiuni catre baze de date relationale, cozi de mesaje;

e) servicii de manipulare a datelor in format XML;

f) servicii de management al tranzactiilor la nivelul aplicatiilor.

SAPP.5 Cerintele componentei server de aplicatii sunt:

a) Compatibil cu specificatiile platformei Java Enterprise Edition 5 sau

echivalent

b) Compatibilitate cu specificatiile platformelor anterioare Java, Java 2

Enterprise Edition 1.4 si Java 2 Enterprise Edition 1.3 sau echivalent

c) Platforma tehnologica completa pentru instalarea si executia site-urilor web

dinamice, serviciilor web si aplicatiilor J2EE sau echivalent

d) Suport complet pentru specificatiile Java Servlets 2.3, 2.4 si 2.5 sau echivalent

e) Suport complet pentru specificatiile JavaServer Pages 1.2, 2.0 si 2.1 sau

echivalent

f) Suport complet pentru specificatiile Enterprise JavaBeans 2.0, 2.1 si 3.0 sau

echivalent

g) Suport pentru servicii web conform specificatiilor WS-I Basic Profile 1.0 si

1.1

h) Suport complet pentru servicii web utilizand specificatiile JAX-WS 2.0 si

JAX-RPC 1.1 sau echivalent

i) Suport pentru Simple Object Access Protocol (SOAP) versiunile 1.1 si 2.0 si

SOAP with attachments API for Java (SAAJ)

j) Transformarea datelor in format XML utilizand standardul W3C Extensible

Stylesheet Language (XSL)

116 / 234

k) Citirea si scrierea datelor in format XML utilizand interfetele de programare

standard Document Object Model (DOM) si Simple API for XML (SAX) si

specificatia Streaming API for XML (StAX) sau echivalent

l) Securizarea serviciilor web utilizand standardele WS-Security si WS-

SecurityPolicy

m) Suport complet pentru standardul Java Database Connectivity (JDBC)

versiunile 2.1 si 3.0 sau echivalent

n) Suport pentru conectarea la multiple sisteme de gestiune a bazelor de date

relationale (SGBDR)

o) Partajarea conexiunilor de date (Connection Pooling) integrat cu mecanismele

de clustering si detectare a defectelor implementate la nivelul bazelor de date

p) Suport complet pentru standardul Java Messaging Service (JMS) versiunile

1.0 si 1.1 sau echivalent

q) Suport complet pentru managementul tranzactiilor utilizand specificatia Java

Transaction API (JTA) versiunile 1.0 si 1.1 sau echivalent

r) Implementare proprie pentru specificatia Java Persistence API (JPA) sau

echivalent cu suport pentru urmatoarele tipuri de obiecte : Plain Old Java

Object (POJO), JavaBeans si Enterprise Java Beans (EJB) sau echivalent

s) Suport complet pentru standardul Java Authentication and Authorization

Service (JAAS) sau echivalent

t) Mecanisme de grupare a serverelor in clustere de servere de aplicatii atat in

topologii de tip activ-activ cat si activ-pasiv

u) Stoparea temporara a unui nod din cluster pentru mentenanta si suport,

sistemul in acest timp fiind disponibil pentru activitati normale

v) Mecanisme de balansare dinamica a incarcarii sistemului intre resursele

administrate in cadrul aceluiasi cluster

w) Mecanisme de scalare a sistemului pe orizontala (Scale Out) si verticala (Scale

Up)

x) Sa ofere proceduri de aplicare automata de patch-uri pe un cluster de servere

de aplicatii cu mentinerea continuitatii de business a aplicatiilor

y) Server web integrat

z) Sa permita rularea serverului de aplicatii pe toate distributiile majore de

sisteme de operare prezente pe piata: Windows, Linux si UNIX

aa) Sa permita instalarea de noi versiuni ale unei aplicatii fara intreruperea

utilizatorilor conectati asigurand continuitate activtii de business (Zero-

Downtime); vechea aplicatie va fi dezactivata numai dupa inchiderea tuturor

conexiunilor active la momentul instalarii noi versiuni

bb) Consola de administrare a serverelor de aplicatii cu capabilitati de gestiune a

schimbarilor de configuratii:

blocarea unei configuratii in vederea modificarii

salvarea unei configuratii fara aplicare efectiva

revenirea la o configuratie anterioara

istoricul modificarilor

117 / 234

cc) Sa se permita inregistrarea, sub forma unui script de comenzi, a operatiilor de

administrare executate asupra unui domeniu de aplicatii cu posibilitatea de

utilizare ulterioara a acestuia pentru activitati de administrare si mentenanta a

serverului de aplicatii

dd) Suport pentru protectie impotriva supraincarcarii serverului de aplicatii

utilizand optiuni de configurare a resurselor software pentru cazurile in care

serverul nu mai poate accepta noi cereri de procesare, capacitatea maxima a

sistemului fiind atinsa

ee) Serverul de aplicatii trebuie sa includa facilitati de modificare dinamica (self-

tunning) a numarului de sesiuni concurente acceptate functie de gradul de

incarcare a sistemului exploatat

SAPP.6 Sa permita migrarea automata a unei instante de server de aplicatii dintr-un

cluster de pe un nod al clusterului pe altul conform politicilor de administrare definite

5.2.5.15 Server integrare

SINT.1 Componenta Integrare este compusa din minim doua servere cu balansare a

incarcarii pe care ruleaza serviciile de integrare si fluxuri de procese din cadrul

sistemului pentru situatii de urgenta.

SINT.2 La randul ei aceasta componenta este formata din urmatoarele

subcomponente:

5.2.5.15.1 Componenta Aplicatii SOA

SINT.3 Pentru dezvoltarea aplicatiilor in arhitecturi SOA (Service Oriented

Architecture) se impune existenta unei infrastructuri software care sa ofere suport

pentru:

a) utilizarea standardelor deschise XML si WS-*;

b) managementul intregului ciclul de viata a serviciilor web;

c) ansamblarea componentelor SOA sub forma de aplicatii compozite;

d) definirea sub-componentelor de aplicatii SOA folosind un limbaj de tip

workflow bazat pe standarde deschise.

SINT.4 Cerintele componentei aplicatii SOA sunt:

e) Sa ofere suport complet pentru dezvoltarea, testarea, executia, monitorizarea,

optimizarea si administrarea aplicatiilor compozite folosind standardul Service

Component Architecture (SCA)

f) Sa ofere suport pentru solutii moderne si deschise de integrare conform

principiilor si conceptelor arhitecturilor Service Oriented Architecture (SOA)

si Event Driven Architecture (EDA)

g) Sa fie bazata pe standardele deschide de interoperabilitate a aplicatiilor WS-I

Basic Profile, WSDL, WS-*, XML, SOAP, UDDI

h) Mediul de dezvoltare sa asigure dezvoltarea si instalarea aplicatiilor compozite

SOA pe serverele de executie si sa permita scrierea de suite de teste asociate

modulelor de aplicatii

118 / 234

i) Sa permita modelarea declarativa a proceselor de afaceri utilizand standardul

OASIS BPEL cu ajutorul mediului de dezvoltare integrat al sistemului

j) Sa permita ansamblarea proceselor de afaceri BPEL in aplicatii compozite

folosind standardul Service Component Architecture (SCA)

k) Sa ofere suport pentru comunicatii sincrone si asincrone inter-aplicatii

l) Sa ofere mecanisme transparente de persistenta a starii aplicatiilor si

informatiilor de audit intr-o baza de date relationala

m) Sa permita folosirea canalelor de notificare moderne (email, voce, SMS, fax)

pentru informarea utilizatorilor despre evenimentele semnificative aparute in

aplicatii

n) Pentru interactiunea umana cu aplicatiile compozite, sa ofere sabloane

predefinite de dirijare a activitatilor catre utilizatorii cu roluri specifice la

nivelul aplicatiilor precum si interfete grafice de lucru cu aplicatiile

automatizate

o) Sa se integreze cu solutii de tip Service Registry bazate pe standardul deschis

Universal Description Discovery and Integration (UDDI)

p) Sa permita auditarea si inregistrarea aplicatiilor compozite executate sau in

curs de executie precum si a datelor transportate

q) In scopul detectarii problemelor de performanta, infrastructura de executie sa

permita colectarea permanenta de statistici de executie – timpi de executie,

frecventa de aparitie evenimente, stari – pentru aplicatiile compozite instalate

r) Sa includa un modul dedicat de stocare si evaluare a regulilor de business

externe aplicatiilor modelate, pe care personalul non-tehnic sa le poata accesa

si modifica on-line prin intermediul unei console web

s) Implementarea unui mecanism de export al informatiilor – variabile proces,

activitati, exceptii – din aplicatii direct in baze de date relationale sau cozi de

mesaje

t) Facilitati de activare a auditarii numai in cazul terminarii cu eroare a unei

aplicatii

u) Sa ofera mecanisme de definire, inregistrare si consum de evenimente

utilizand filtre personalizabile in cadrul aplicatiilor compozite SOA.

SINT.5 Componenta de aplicatii SOA va pune la dispozitie o modalitate completa,

standardizata si usor de utilizat pentru modelarea, instalarea, executia si monitorizarea

solutiilor de tip procesari de business ce contin aplicatii eterogene si in care procesele

de business presupun atat interventie umana cat si automata.

SINT.6 Modelarea proceselor de lucru se va realiza utilizand standardul Business

Process Execution Language (BPEL) ca limbaj standard pentru agregarea unui set

discret de servicii sub forma unei diagrame de proces.

SINT.7 Prin modelarea proceselor se va asigura:

a) automatizarea proceselor standard de lucru din cadrul organizatiei sub forma

de fluxuri electronice;

119 / 234

b) modelarea grafica, de tip drag&drop, a proceselor de business utilizand

standardul BPEL;

c) conectori predefiniti pentru integrare cu solutii informatice eterogene astfel

incat sa se permita schimbul de informatii cu sisteme externe indiferent de

tehnologia utilizata de acestea;

d) un motor de transformare si rutare a mesajelor;

e) un modul pentru interactiune umana cu capabilitati de gestiune a listei de

activitati, aprobarilor, notificarilor, escaladarilor, rutarilor seriale, paralele si

ad-hoc;

f) mecanisme de tratare a exceptiilor si compensare a activitatilor proceselor;

g) un modul integrat de mesagerie electronica care sa permita transmiterea de

notificari si alerte catre sisteme folosind diverse canale (e-mail, SMS, fax,

voice);

h) monitorizarea proactivă a fluxurilor în execuţie prin accesul direct, sub forma

de tablouri de control, la indicatorii cheie de execuţie;

i) utilizarea standardelor de interoperabilitate cum ar fi XML, Web Service

Definition Language (WSDL), Simple Object Access Protocol (SOAP),

Universal Description Discovery and Integration (UDDI) pentru integrarea

facila si rapida cu orice serviciu expus de un sistem extern;

j) publicarea fluxurilor electronice ca servicii web standard ce pot fi reutilizate in

modelarea altor procese de business.

5.2.5.15.2 Componenta monitorizare aplicatii SOA

Monitorizarea proactiva si eficienta a sistemelor si componentelor de aplicatii SOA se va face

utilizand serviciile componentei monitorizare aplicatii SOA.

SINT.8 Cerintele componentei monitorizare aplicatii SOA sunt:

a) Sa permita monitorizarea in timp real a indicatorilor de tipul Key Performance

Indicators (KPI)

b) Sa permita monitorizarea in timp real a SLA-urilor de business sau

operationale

c) Sa colecteze date utilizand diferite canale de date precum: conexiuni la baze

de date relationale, cozi de mesaje, publicare directa in cache-ul de

monitorizare in timp real

d) Definirea si prezentarea tablourilor de bord se va putea face de catre personal

non-tehnic utilizand un simplu browser web

e) Solutia va permite definirea de alerte si planuri de actiuni asociate

nerespectarii KPI-urilor si SLA-urilor impuse sau altor evenimente ale

sistemului.

5.2.5.15.3 Componenta magistrala de mesaje

SINT.9 Integrarea aplicatiilor se va face utilizand serviciile unei componente de tip

magistrala de mesaje. Aceasta componenta va oferi suport pentru:

a) virtualizarea accesului la functionalitatile de aplicatii;

120 / 234

b) conectarea la diferite tehnologii si sisteme de aplicatii;

c) transformarea mesajelor schimbate intre aplicatii;

d) rutarea mesajelor intre diferitele sisteme integrate;

e) livrarea sigura a mesajelor intre sisteme.

SINT.10 Cerintele componentei magistrala de mesaje sunt:

a) Suporta transformari si manipulari de date complexe pentru implementarea de

fluxuri de mesaje

b) Tipurile de mesajele transportate suportate de solutia de tip Magistrala Mesaje

vor fi: XML, text, ne-tipat, binar, attachment

c) Sistemul va include capabilitati extinse de transformare a mesajelor XML

utilizand standarde deschise W3C Extensible Stylesheet Language (XSL) si

XQuery

d) Ofera solutii de conectare predefinite la principalele tipuri de tehnologii: baze

de date relationale, cozi de mesaje (Java JMS, Oracle Advanced Queuing

(AQ), IBM MQ, MS MQ), sisteme de fisiere, servere FTP

e) Suporta solutii de conectare la principalele sisteme de aplicatii

f) Ofera un cadru de dezvoltare pentru noi solutii de conectare la sisteme externe

bazat pe standarde deschise

g) Ofera servicii de transport cu suport pentru persistenta datelor

h) Ofera servicii de transport cu suport pentru garantarea livrarii datelor

i) Include capabilitati extinse de transformare si dirijare a datelor bazate pe

continutul transportat

j) Solutia va implementa urmatoarele modele de servicii: sincron cerere/raspuns,

asincron one-to-one, asincron one-to-many, asincron cerere/raspuns

(synchronous-to-asynchronous bridging)

k) Magistrala de Mesaje va oferi posibilitatea definirii, la momentul executiei, a

adreselor de destinatie a mesajelor (Dynamic Routing), eventual prin

interogarea unei solutii de tip Service Registry utilizand standardul UDDI

l) Solutia va implementa mecanisme de control si garantare a livrarii mesajelor

conform urmatoarelor tipuri de politici: Exactly-Once, At-Least-Once, Best-

Effort

m) Specificarea si modificarea fluxurilor de mesaje sa se poata face atat utilizand

mediul de dezvoltare integrat al sistemului cat si un simplu browser web

n) Managementul incarcarii livrarii mesajelor catre serviciile destinatie

inregistrate la nivelul magistralei de mesaje folosind cozi de mesaje tampon

care permit:

o definirea concurentei maxime admise de serviciul destinatie;

o definirea unei perioade de expirare pentru mesajele trimise;

o definirea de prioritati asociate mesajelor.

5.2.5.15.4 Componenta gateway si securitate aplicatii SOA

121 / 234

SINT.11 Accesul securizat la aplicatiile SOA, bazat pe seturi de politici de control al

accesului administrate centralizat, va fi asigurat de componenta gateway si securitate

aplicatii SOA.

SINT.12 Componenta va oferi:

a) suport pentru securitatea serviciile web bazat pe standarde deschise;

b) mecanisme de interceptarea a cererilor catre serviciile web si aplicarea de

politici de securitate asupra acestora;

c) depozitar central de politici de securitate;

d) consola web de administrare si monitorizare a securitati la nivelul serviciilor

web.

SINT.13 Cerintele componentei gateway si securitate aplicatii SOA sunt:

a) Sa ofere un modul centralizat de gestiune si aplicare a politicilor de securitate

peste portofoliul de aplicatii compozite instalat

b) Sa ofere servicii de securitate atat la nivel transport cat si la nivel de aplicatie

c) Pentru asigurarea securitatii la nivel transport, solutia va permite utilizarea

protocolul Secure Socket Layer (SSL) si a certificatelor compatibile X.509

d) Sa ofere servicii de securitate specifice lucrului cu serviciile web standard:

o autentificarea accesului la servicii

o autorizarea accesului la servicii

e) Solutia sa fie bazata pe standardele deschise de securitate a serviciilor web,

precum WS-Security, Security Assertation Markup Language (SAML)

f) Sa ofere suport pentru standardele deschise de securitate privind mesajele in

format XML:

o XML Encryption pentru criptarea / decriptarea mesajelor XML in

vederea asigurarii confidentialitatii mesajelor transportate;

o XML Signature pentru semnarea / verificarea digitala a mesajelor

XML in vederea asigurarii integritatii si non-repudierii mesajelor

transportate

g) Sa permita securizarea tuturor apelurilor catre serviciile existente printr-un

mod de functionare de tip poarta de acces (gateway) fara sa fie necesara

modificarea proceselor instalate

h) Sa ofere agenti ce vor putea fi instalati pe statiile client in vederea

impachetarii (adaugare informatii securitate) apelului catre serviciile web

dorite

i) Definirea politicilor de securitate se va face declarativ, utilizand un instrument

de configurare web-based, pe baza unor primitive de activitati de securitate

pre-definite – exemplu: verificarea credentialelor utilizator versus un director

LDAP, auditarea accesului la un serviciu, etc.

5.2.5.15.5 Componenta procesare evenimente

122 / 234

SINT.14 Componenta procesare evenimente va permite dezvoltarea si executia

aplicatiilor cu arhitectura bazata pe evenimente (Event-Driven Architecture).

Componenta va permite in principal lucrul cu fluxuri de evenimente prin selectarea,

agregarea si sincronizarea performanta a unui numar ridicat de evenimente provenite

din sisteme si aplicatii multiple.

SINT.15 Cerintele componentei procesare evenimente sunt:

a) Sa ofere capabilitati extinse pentru implementarea aplicatiilor cu arhitectura

Event-Driven Architecture (EDA)

b) Sa ofere un mediu declarativ pentru dezvoltarea aplicatiilor bazate pe

evenimente

c) Sa ofere un mecanism de cache pentru evenimente in care aplicatiile sa poata

publica evenimente respectiv din care aplicatiile sa poata consuma evenimente

marind disponibilitatea si performanta infrastructurii de evenimente

d) Sa ofere un depozitar de evenimente care sa stocheze secventele de

evenimente aparute si sa permita executarea ulterioara a acelorasi evenimente

pe baza scenariilor inregistrate in depozitarul de evenimente

e) Sa permita monitorizarea continua a surselor de evenimente putand realiza

filtrarea, agregarea, corelarea si sincronizarea evenimentelor

f) Sa implementeze un limbaj specializat, de tip SQL, care sa permita selectarea

si filtrarea continua a evenimentelor receptionate din multiple surse de

evenimente

g) Limbajul de procesare a evenimentelor sa permita definirea de ferestre de

evenimente incrementale sau batch bazate pe intervale de timp sau numar de

evenimente de interes

h) Limbajul de procesare a evenimentelor sa permita definirea de sabloane de

detectie a secventelor de evenimente si non-evenimentelor folosind operatori

logici si temporali

i) Limbajul de procesare a evenimentelor sa permita definirea de sabloane de

detectie a evenimentelor bazate pe expresii regulate

j) Limbajul de procesare a evenimentelor sa permita managementul incarcarii

aplicatiilor catre care evenimentele filtrare sau agregate sunt livrate

k) Sa permita integrarea limbajul de procesare a evenimentelor cu aplicatii scrise

in Java folosind modele de programare de tip Plain Old Java Object (POJO)

sau Spring pentru procesarea performanta a evenimentelor

l) Sa includa un generator de incarcare care sa permita simularea de evenimente

in vederea testarii aplicatiilor bazate pe evenimente

m) Sa se integreze bidirectional cu componentele magistrala de mesaje si aplicatii

SOA astfel incat aceste componente sa poata fi surse sau destinatii pentru

evenimentele gestionate de solutia de tip CEP.

5.2.5.16 Control acces si gestiune utilizatori

INIT.36 Aceasta va fi compusa din urmatoarele servere:

123 / 234

a) Server Control Acces – un server pe care ruleaza serviciile care asigura

managementul identitatii utilizatorilor (componenta de securitate), precum si

accesul centralizat la informatia despre utilizator printr-un unic punct.

b) Server LDAP – server dedicat stocarii informatiei despre profilul utilizatorilor

si structura organizatorica.

INIT.37 Data fiind importanta asigurarii unui grad ridicat de securitate a accesului la

informatiile vehiculate prin intermediul interfetelor web, este esentiala utilizarea unor solutii

avansate de control al accesului web, administrare unitara a conturilor de utilizator si stocare

sigura a profilelor.

INIT.38 Aceste componente vizeaza alinierea solutiilor software cu tendintele de

securitate din domeniul prelucrarii datelor cu caracter confidential si trebuie sa ia in

considerare urmatoarele specificatii:

a) Solutie de control al accesului:

o Control al accesului la aplicatii web

o Single sign on si federalizare a accesului la aplicatii web

o Administrare centralizata a politicilor de acces la aplicatii

b) Solutie de administrare unitara a conturilor de utilizator:

o Creare automatizata de conturi in functie de politici de acces la resurse

o Stergere automatizata a conturilor in functie de politicile de acces la

resurse

o Vedere unitara a tuturor resurselor alocate unui utilizator

o Raportare si auditare avansata

o Integrare cu sistemele vizate pe baza de tehnologie fara agenti

c) Solutie de stocare sigura a profilelor de utilizator:

o De tip LDAP v3

o Stocarea efectiva a informatiei sa se faca la nivel de baza de date

o Informatiile stocate sa beneficieze de toate avantajele de redundanta,

disponibilitate si securitate de la nivelul bazei de date utilizate

o Sa contina functionalitati de virtualizare a surselor de identitati

5.2.5.16.1 Controlul accesului

INIT.39 Solutia de control al accesului la aplicatii web trebuie sa indeplineasca

urmatoarele cerinte:

d) Stocarea configuratiilor si a politicilor sa se realizeze intr-un director LDAP

unificat, fara a exista nevoia unui depozitar proprietar de date

e) Sa permita accesarea simultana a mai multor surse de identitati pentru

realizarea autentificarii si autorizarii, fara a implica duplicarea informatiei sau

crearea unui metadirector

f) Toate componentele software ale solutiei trebuie sa permita rularea in mod

disponibilitate ridicata folosind functionalitati native si fara a necesita

echipamente suplimentare

g) Sa ofere o interfata web pentru administrare si self-service

124 / 234

h) Sa permita rularea de fluxuri pentru inregistrarea utilizatorilor, recuperarea si

resetarea parolei, inregistrarea in grupuri de cercetare

i) Toate politicile de control al accesului trebuie sa poata fi definite utilizand

interfata web a solutiei, fara a necesita cunostinte de programare sau rularea de

scripturi pe server

j) Sa permita simularea politicilor de acces (ce utilizatori afecteaza, ce politica

va fi aplicata in anumite conditii, etc)

k) Sa ofere control al accesului bazat pe roluri, in combinatie cu alti factori

precum momentul de realizare a cererii de contectare, adresa de retea de unde

provine cererea, grupul din care faca parte utilizatorul si orice alt atribut din

profilul acestuia (inclusiv atribute special definite, nestandard)

l) Functionalitati de tip single sign on (autentificare unica) pentru toate resursele

protejate; orice utilizator care se autentifica si este autorizat trebuie sa poata

avea acces la informatiile expuse de sistem fara a i se cere reautentificarea pe

parcursul sesiunii, atat timp cat nu exista politici care sa ceara acest fapt

m) Sa ofere autentificare multi nivel combinand orice metode de autentificare

disponibile (de exemplu nume utilizator si parola pentru nivel privat, certificat

digital pentru nivel confidential, etc)

n) Sa suporte cel putin urmatoarele metode de autentificare:

o Nume de utilizator si parola

o Certificate digitale x.509

o Smart card

o Token-uri fizice cu PIN

o Bazata pe formulare web

o API-uri de autentificare pentru dezvoltari

o) Schimbarea comportamentului standard (refuza acces sau permite acces pentru

resursele neprotejate)

p) Auditarea informatiei sa se realizeze atat in fisiere text formatate cat si in baze

de date (precum Oracle si SQL Server); auditarea se refera la evenimente de

autentificare si autorizare, nu evenimente de functionare a sistemului (pentru

acestea se accepta loguri text)

q) Nivelul de auditare trebuie sa fie configurabil (succes, nereusita, etc)

r) Sa se integreze cu solutii avansate de raportare si sa ofere out-of-the-box

rapoarte pentru datele auditate

s) Sa realizeze criptarea informatiei transferata intre componentele sistemului si

clienti (HTTPS, LDAPS, etc)

t) Solutia de control acces sa ofere integrare cu solutia de stocare a utilizatorilor

si cu cea de administrare unitara

u) Suport pentru acces federalizat la resursele expuse de parteneri si toate

standardele urmatoare:

o SAML 1.0, 1.1, 2.0

o Liberty Alliance ID-FF 1.1, 1.2

o WS-Federation

125 / 234

5.2.5.16.2 Gestiunea utilizatorilor

INIT.40 Solutia de administrare a utilizatorilor trebuie sa indeplineasca urmatoarele

cerinte:

a) Sa ofere posibilitatea de implementare in faze. Organizatia poate alege ce

functionalitati sa implementeze (de exemplu doar module care vizeaza

complianta si provizionarea) fara a exista dependente sau prioritati; decizia

trebuie sa poata fi realizata la nivel de resursa.

b) Alocare automata de resurse catre utilizatori pe baza de politici si drepturi.

Pentru orice set de utilizatori, administratorii pot specifica nivelul de acces

pentru fiecare resursa ce urmeaza a fi alocata, astfel incat fiecare utilizator sa

aiba doar drepturile de acces necesare indeplinirii sarcinilor de lucru specifice

c) Definirea de politici de negare a accesului la resurse

d) Capabilitati de tratare a erorilor din cadrul fluxurilor de alocare a resurselor

(sau aprobari)

e) Cand un utilizator pleaca din organizatie sau accesul nu mai este necesar in

urma schimbarii rolului, solutia trebuie sa permita revocarea automata sau

manuala a acestuia , conform cu politicile de acces din sistem

f) Interfata expusa catre utilizatori (self-service) trebuie sa permita vizualizarea

si modificarea informatiilor din profil

g) Utilizatorii si administratorii trebuie sa poata urmarii stadiul unei cereri in

timp real, la orice moment

h) Utilizatorii trebuie sa isi poata configura intrebari si raspunsuri cheie pentru

resetarea parolelor de acces la resurse dintr-un punct unic

i) Administrare delegata pentru situatiile in care utilizatorii sunt temporar

nedisponibili

j) Suporta politici avansate de parole: lungime parola, numar si tipuri de

caractere necesare, sa impiedice reutilizarea acelelasi parole in mod repetat

dupa expirare, dictionar de parole care nu trebuiesc utilizate

k) Sa poata genera parole in mod automat la inregistrarea utilizatorilor

l) Politici de parole multiple pentru aceeasi resursa

m) Sincronizarea bidirectionala a parolelor intre resursele administrate si solutia

de administrare a utilizatorilor

n) Motor de fluxuri care sa permita modelarea proceselor de aprobare din

organizatie cu suport pentru escaladare si delegare a aprobarii

o) Sa permita definirea de reguli de negare a accesului la o resursa X daca

utilizatorul are acces la o anumita resursa Y

p) Solutia trebuie sa ofere posibilitatea rularii periodice a unor rapoarte (atestare):

o Sa pastreze istoricul rapoartelor rulate; pentru fiecare rulare sa ofere

detalii pentru fiecare utilizator

o Atestarea nu trebuie sa se bazeze pe posibilitatea de conctare la sisteme

(chiar daca un sistem nu este accesibil, sa se poata raporta pe baza

datelor interne ale sistemului de administrare a utilizatorilor, fara a

exista pierderi de informatie)

126 / 234

q) Monitorizare continua a conturilor orfane si executare a unor actiuni corective

automate

r) Solutia trebuie sa fie usor de configurat si administrat:

o Sa nu necesite mai mult de un depozitar pentru stocarea tuturor

informatiilor specifice (baza de date), incluzand roluri, politici, fluxuri

de lucru sau date de profil ale utilizatorilor

o Sa permita inalta disponibilitate fara schimbarea arhitecturii produsului

sau instalarii

o Sa suporte personalizare folosind unelte vizuale, fara a fi nevoie ca

administratorii sa invete libaje de programare specifice produsului

s) Solutia trebuie sa foloseasca aceleasi tehnologii pentru toate componentele

(self-service, provizionare, conectori, etc).

5.2.5.16.3 Stocarea utilizatorilor

INIT.41 Solutia de stocare a utilizatorilor trebuie sa indeplineasca urmatoarele cerinte:

a) Sa permita accesarea datelor despre utilizatori atat din baze de date cat si din

directoare LDAP, cu posibilitatea de agregare selectiva a profilelor si

expunerea acestor informatii in format LDAP catre alte sisteme

b) Stocarea utilizatorilor sa se realizeze intr-un director de utilizatori LDAP v3

c) Sa permita integrarea cu celelalte componente ale sistemului general astfel

incat sa existe o singura sursa de utilizatori pentru toate nivelele (aplicatie,

baza de date, etc)

5.2.5.17 Server mesagerie electronica

Cerinte minim obligatorii pentru sistemul de mesagerie electronica:

SMSE.1 Usurinta in utilizare:

a) Solutia sa ofere asistenta vizuala pentru alegerea celor mai bune date si ore pentru

intalniri, in functie de programul invitatilor si resurse.

b) Posibilitatea de a vedea informatiile despre disponibilitatea persoanelor din

calendar.

c) Salile de conferinta si echipamentele sa fie marcate clar in agenda, astfel incat sa

poata fi parcurse separat.

d) Sa se poata programa mesaje “Out-of-Office” separate, pentru a fi trimise unor

destinatari interni sau externi dupa preferinta mesaje diferite.

e) In cazul accesului la casuta postala prin Web sa se permita convertirea

documentelor (Microsoft Office Word, Excel®, PowerPoint® şi PDF) astfel incat

sa poata fi vizualizate chiar daca aplicatiile respective nu sunt instalate pe

calculatorul client. Deasemenea, accesul prin Web sa aduca functionalitati extinse

gen schedule assistant, categorii de mesaje, cautari avansate

f) Lucru colaborativ facil din interfata Web, adica daca un utilizator primeste o

legatura la un document de pe un site SharePoint (portal) sau alt sistem de partajare

a fisierelor, sistemul de mesagerie sa preia linkul si sa faca cererea in numele

utilizatorului pentru a afisa documentul.

127 / 234

g) Accesul la casutele postale sa se poata face si de pe dispozitive mobile, Windows

Mobile etc. Mai mult, daca un dispozitiv este pierdut sau furat, utilizatorul sa poata

sterge continutul dispozitivului mobil sau sa poata reseta parola prin interfata Web.

h) Usurinta in realizare de reguli pentru a redirecta corespondenta in diverse arhive,

containere sau destinatii,

i) Posibilitatea de a marca corespondenta cu diferite culori in functie de importanta,

pentru o vizibilitate mai buna.

j) Posibilitatea de a grupa e-mailurile in functie de topic, destinatar, identificator etc.

k) Informatii oferite in legatura cu destinatiile din interiorul institutiei catre care dorim

sa trimitem corespondenta (exemplu: daca persoana respectia este in concediu; daca

in componenta grupului catre care dorim sa trimitem un mesaj exista si oameni din

afara institutiei etc)

SMSE.2 Eficienta in administrare si securitate

l) Sistemul de mesagerie trebuie sa asigure performante ridicate si fiabilitate, pe

masura ce cresc dimensiunile casutelor postale si numarul de conturi de utilizator

per server. Sa aiba capacitatea sa acomodeze cantitati foarte mari de mesaje la

performante ridicate.

m) Sistemul sa ofere un grad ridicat de securitate, care sa poate fi integrat nativ cu PKI

(infractrucura de chei publice) sau cu RMS (sistem de gestionare a drepturilor de

acces la informatie) usor de folosit si integrat nativ cu Active Directory.

n) Sistemul sa permita filtrarea antispam disponibila de la instalare, fiind gestionata de

rolul de server Edge Transport, in perimetrul retelei si sa ofere un mecanism de

protectie impotriva virusilor si al viermilor de retea.

o) Arhitectura sa asigure o inalta disponibilitate si replicarea bazelor de date cu

casutele postale. Baza de date sa poata sa fie replicata si pe alte servere de

mesagerie din institutie si in cazul in care baza de date primara este corupta,

automat utiliatorul sa fie redirectat catre alta copie a casutei postale.

p) E-mailurile din interiorul organizatiei sa fie criptate automat, de la plecarea din

clientul de e-mail al expeditorului, pana la primirea în clientul de e-mail al

destinatarului.

q) Configurarea aplicatiei client de e-mail, in vederea conectarii la server, sa se faca

usor, de genul daca utilizatorul este conectat la retea, serverul de mesagerie prin

componentele sale sa configureaze automat profilul de Outlook al utilizatorului.

r) Pentru a putea impune anumite reguli (interne, guvernamentale sau locale) sistemul

trebuie sa fie capabil, prin control detaliat asupra fluxurilor de e-mailuri, sa

implementeze un motor pentru politici.

s) Pentru a asigura certificarea mesajelor administratorii trebuie sa poata utiliza reguli

de transport pentru a aplica clasificari ale mesajelor pentru e-mailurile in tranzit, in

functie de subiect, continut sau adresa expeditorului/destinatarului. Sa existe

posibilitatea folosirii unui un proces automat care sa scaneze foldere predefinite de

administrator pentru a retine, expira sau jurnaliza mesajele, in functie de normele

care trebuie respectate.

128 / 234

t) Sistemul sa poata permite realizarea de cautari text rapide in cadrul tuturor casutelor

postale din organizatie, daca este necesara această actiune din punct de vedere legal.

u) Sistemul de mesagerie sa permita integrarea cu centrala telefonica existenta pentru a

adauga functionalitati de cutie vocala cat si IVR (recunoasterea inteligenta a vocii)

pentru utilizatorii din institutie.

v) Produsul sa ofere sistemului de operare contorii necesari pentru a putea fi urmarita

starea de functionare si performanta in fiecare clipa cat si integrarea cu diferite

unelte de monitorizare.

w) Consolele de aministrare sa fie intuitive si usor de utilizat.

x) Sistemul sa poata delega drepturi diferite pentru anumite departamente sau grupuri

de persoane pentru a asigura segregarea drepturilor in functie de responsabilitatile

fiecarui utilizator.

y) Sistemul sa dispuna de unelte care sa permita rularea de comenzi text cat si

realizarea facila de scripturi pentru a automatiza diverse actiuni cat si pentru a

automatiza instalarea aplicatiei pe o platforma noua.

z) Sistemul sa ofere interfata de autoadministrare pentru utilizatori.

aa) Sistemul sa ofere protocoale de acces la casuta postala: POP, IMAP, WEB si

protocolul MAPI.

bb) Sistemul sa ofere unelte de jurnalizare si arhivare la nivel global sau pentru un

numar restrans de utilizatori cat si posibilitatea clientului de a-si arhiva singur

mesajele.

5.2.5.18 Configuratia minimala de procesare(mediul de productie)

Server # servere # core / server

Server Web 2 1

Server Portal Web 2 2

Server Aplicatie 2 4

Server Integrare 2 2

Server Control Acces 2 2

Server LDAP 2 2

Server DB 2 4

Server gestiune documente 2 2

Server GIS 2 4

Server monitorizare 1 2

Server management echipamente 1 2

Server Backup 1 2

Server Antivirus 1 2

Server Mesagerie 2 4

Server CRM 2 2

5.2.5.19 Configuratia minimala de procesare(mediul de testare/dezvoltare/instruire)

129 / 234

Server # servere # core / server

Server Web 2 1

Server Portal Web 2 1

Server Aplicatie 2 1

Server Integrare 2 1

Server Control Acces 2 1

Server LDAP 2 1

Server DB 2 1

Server gestiune documente 2 1

Server GIS 2 1

Server monitorizare 1 1

Server management echipamente 1 1

Server Backup 1 1

Server Antivirus 1 1

Server Mesagerie 2 1

Server CRM 2 1

Alte sisteme: Securitate logica; Atentionare privind vehicule suspecte; Managementul

defectelor; Integrarea cu BTMS; Managementul unitar al drepturilor de acces. Cerinte

detaliate pentru aceste subsisteme se gasesc in fisele tehnice.

5.2.6 Sub-Sistemul operativ mobil

Sistemul mobil permite interconectarea in timp real a terminalelor mobile folosind

comunicatii securizate prin retelele mobile (UMTS/HSDPA/GPRS). Sub-sistemul va include

de asemenea o componenta de tip Unmanned Aerial Vehicle (UAV); acesta va putea fi

lansata de pe un vehicul si va fi utilizata pentru transmiterea in timp real de imagini video din

teren (zona situatii de urgente). Cerinte detaliate pentru aceste subsisteme se gasesc in fisele

tehnice.

MOB.1 Ofertantul trebuie sa furnizeze urmatoarele echipamente pentru Sistemul

Mobil, asa cum se detaliaza in anexa:

a. PDA (Personal Digital Assistant – pentru personal, lucru in mod portabil)

b. Laptop-uri

MOB.2 Principalele aplicatii care vor rula pe echipamentele mobile sunt, dar nu sunt

limitate la: acces la informatii de la locul unui incident; acces la rapoarte; acces la

notificari.

MOB.3 Ofertantul va dezvolta o aplicatie software care va transfera date de la doua

baze tehnice care vor fi definite in proiectul preliminar (de exemplu: masini furate,

etc. ).

MOB.4 Ofertantul va dezvolta o aplicatie software care sa permita transferul de

inregistrari ale incidentelor in BEMIS.

5.2.7 Sub-Sistem Monitorizare si Management

MNG.1 Ofertantul va detalia propunerea pentru un sistem de monitorizare si

management al retelei cu urmatoarele cerinte:

130 / 234

a. Sistemul, prin protocoale ca SNMP (Simple Network Management

Protocol) va utiliza informatia introdusa de agenti si depozitata in fiecare

statie sau server si o va procesa.

b. Sistemul va fi capabil sa genereze alarme in cazul incidentelor de tipul

nefunctionarii serviciilor sau serverelor precum si la incidente predefinite

de tipul :

o Memorie libera minima

o Spatiu disponibil pe disk

o Temperatura ridicata

o Supraincarcarea proceselor

c. Sistemul va permite recunoasterea automata a fiecarui element, a

elementelor introduse manual si a elementelor relocate.

d. Sistemul va prezenta permanent o harta a topologiei fizice si logice a

retelei.

e. Sistemul va genera cel putin urmatoarele rapoarte: :

o Tipul alarmei : critica sau non-critica.

o Folosirea link-urilor online si a istoricului.

o Listarea inventarului si a obiectelor din retea.

MNG.2 Sistemul de management va satisface urmatoarele cerinte:

a. Descriere functionala: ofertantul va descrie principalele functionalitati ale

sistemului de management;

b. Descrierea arhitecturii: ofertantul va descrie arhitectura sistemului de

management;

5.2.8 Sistemul de afisare de mari dimensiuni (perete-ecran)

5.2.8.1 Generalitati

VIDEO.1 Ecranele de mari dimensiuni ale CMISU functioneaza controlate de

interfata grafica comuna (GUI), iar funcţiile trebuie să fie disponibile la fiecare

dintre staţiile de lucru operator din Centru.

VIDEO.2 Sistemul de afisare trebuie sa corespunda cerintelor tehnice si

ergonomice specifice unui dispecerat civil.

5.2.8.2 Ecranul principal din Sala Operativa

VIDEO.3 Ecranul principal din Sala Operativa va fi modular, de tip matrice cu

retro-proiectie multipla, capabil de a afişa atât imagini CCTV cât şi imagini de

înaltă rezoluţie generate pe calculator de la subsistemele SMSUB.

VIDEO.4 Ecranul principal va ocupa partea principală a peretelui frontal din Sala

Operativa. Poziţionarea ecranului principal va ţine cont că pe el pot fi afişate

imagini CCTV ce nu trebuie prezentatepersoanelor neautorizate.

VIDEO.5 Ecranul principal va include funcţii de staţie de lucru operator, pentru a

compune anumite combinaţii de imagini CCTV şi de calculator, conform

cerinţelor operaţionale. Aceste combinaţii pot include intrări pentru imagini

preînregistrate sau în direct, grafică de calculator şi televiziune în direct.

131 / 234

VIDEO.6 Caracteristicile si configuratia imaginilor pe ecranul principal vor fi

organizate si stabilite prin aplicatia software dedicata, accesibila in retea, de la

orice terminal. Configuraţia caracteristicilor ecranului principal va trebui să poată

fi stocată de către operatori şi restaurată la cerere.

VIDEO.7 Dimensiunile, configuratia şi solutia tehnica a echipamentului aferent

ecranului principal vor fi incluse în documentul de Proiect final. Toate elementele

mecanice de fixare vor fi testate şi verificate înainte de montarea echipamentului.

VIDEO.8 Ecranul principal va trebui să fie fixat pe planşeul inferior, în mod

rigid. Va trebui să fie lăsat un spaţiu suficient pentru ventilaţie şi acces la reparaţii,

in spatele acestuia. Modalităţile de prindere vor fi prezentate în documentul

Proiect şi convenite cu Beneficiarul înainte de instalare.

VIDEO.9 Conexiunile prin cablu la/de la monitoare vor trebui incluse în

grosimea declarată pentru toate display-urile în cadrul documentului Proiect.

Acest document va trebui să declare spaţiile necesare din spatele monitoarelor, în

scopul ventilării şi întreţinerii.

VIDEO.10 Construcţia ecranului principal va trebui să fie de aşa natură încât

grosimea vizibilă a marginilor orizontale şi verticale să fie minimă.

VIDEO.11 Elementele de afişare bazate pe tehnologii de proiecţie vor trebui să

aibă anumite caracteristici de fiabilitate, de exemplu lămpi duale, pentru a asigura

o operare continuă cu un minim de intervale pentru reparaţii.

VIDEO.12 Configuratia ecranelor va fi aleasa in asa fel incat ecranul de afisare va

fi instalat in pozitie fixa, iar toate operatiunile de intretinere, interventii si

mentenanta se vor face prin spatele ecranului. Nu se accepta nici o interventie prin

fata ecranului.

VIDEO.13 Ecranul principal va fi controlat de un calculator server specializat

(display screen controller). Controlerul Ecranului principal va trebui să aibe

caracteristici de protecţie la defectări de ordin 2 pentru evitarea întreruperii

serviciului la apariţia unor defectări singulare.

VIDEO.14 Controlerul Ecranului principal va trebui să fie conectat la celelalte

subsisteme prin intermediul LAN din CMISU. Furnizorul va lua în considerare

posibilitatea de a amplasa acest server împreună cu celelalte în sala de

echipamente în loc de amplasarea sa în apropierea ecranelor din Sala Operativa .

VIDEO.15 Furnizorul va trebui să includă o descriere detaliată a controlerului

ecranului principal, a funcţiunilor acestuia, interfeţelor cu elementele de afişare şi

cu sub-sistemele CMISU, în documentul Proiect pentru aprobarea de către

Beneficiar.

VIDEO.16 Ecranul principal va fi realizat matriceal, folosind 30 cuburi cu

retroproiectie, amplasate in configuratie 3 linii (orizontale) x 10 coloane

(veriticale). In functie de forma amplasamentului final, este de asteptat ca ecranul

sa prezinte o curbura orizontala de 3-10º.

5.2.8.3 Alte ecrane

VIDEO.17 Alte ecrane vor fi prevazute, dupa necesitati, in saliile de sedinta. In

cadrul CMISU vor fi prevazute un numar de 10 ecrane suplimentare, amplasate in

functie de posibilitati, in principal in saliile de sedinte si in birourile operative.

5.2.8.4 Servere de control video

VIDEO.18 Sistemul de afisare va beneficia de sistemul electronic propriu de

procesare video si de management a ecranelor.

132 / 234

5.2.8.5 Reteaua video

VIDEO.19 Transmisia datelor aferente sistemului video se va face printr-o retea

IP, proprie sistemului (sau dedicata acestuia) astfel incat, in caz de cadere a retelei

principale, ecranele sa ramana functionale.

VIDEO.20 Reteaua si echipamentele active aferente sistemului de afisare

(principal si secundar) vor fi integral redundante.

VIDEO.21 Proiectul de retea si echipamente aferente sistemului de afisare vor fi

descrise in Proiect si vor fi agreate cu Beneficiarul.

VIDEO.22 Reteaua IP a sistemului de afisare va respecta specificatiile IEEE

1000BaseT si va fi cablata cu cablu de cupru tip FTP Cat.6 sau cu cablu de fibra

optica.

5.2.8.6 Aplicatia de management ecranelor si a imaginilor

VIDEO.23 Sistemul de afisare in ansamblu va beneficia de o aplicatie (sau o suita

de aplicatii) software de management a suprafetelor de afisare.

5.2.9 Sistemul de videoconferinta

VCONF.1 Sistemul videoconferinta permite comunicatiile intre utilizatori diferiti

si realizarea de conexiuni intre Sala Operativa si alte locatii.

VCONF.2 Serverul de videoconferinta multi-punct are caracteristicile minime

specificate in anexa 6, fisa tehnica aferenta.

5.2.10 Sistemul integrat de securitate fizica

Prin securiatate fizica se intelege ca sunt acoperite toate aspectele in legatura cu controlul

accesului la CMISU si diferite birouri in interior, precum si supravegherea perimetrala si

interioara.

Scopul acestor specificatii este de a obtine un sistem integrat de securitate la central CMISU,

stabilind politici globale care vor imbunatati securitatea persoanelor si a proprietatilor de

orice fel care trebuie protejate si sa optimizeze operatiunile si mentenanta facilitatilor.

SEC.1 Ofertantul va livra un sistem integrat de securitate fizica testat. Solutia

propusa trebuie sa fie testata si implementata la alti clienti.

SEC.2 Soluţia de securitate este asigurată de patru sisteme complementare:

a. Sistemul de alarmă – va asigura securitatea personalului şi echipamentelor,

generând alarme in cazul situaţiilor necontrolate sau intruziunilor

b. Alarma în caz de incendiu – ca orice dispecerat, Centrul de comandă şi

control trebuie echipat cu o alarmă în caz de incendiu alocată, capabilă să

detecteze orice incendiu, urmă de fum sau temperaturi periculoase.

c. Sistemul de control al accesului – va proteja interiorul Centrului de

comandă şi control împotriva accesului personalului neautorizat. Pentru

aceasta, există echipament protejat, personal de serviciu şi conţinutul

informaţional.

d. Sistemul video de supraveghere a securităţii – asigură supravegherea şi

serviciul de înregistrare a imaginilor pentru fiecare poziţie din sistem.

5.2.10.1 Sistemul de alarmă

133 / 234

SEC.3 Sistemul local de alarmă va fi realizat folosind o unitate specializată centrală,

alocată acestui scop şi echipată cu senzori şi accesorii pentru a detecta orice

intruziune neautorizată.

SEC.4 Interfaţa utilizatorului va fi realizată printr-o tastatură alocată cu ecran

alfanumeric care va putea fi folosit de către utilizatori obişnuiţi, de către

administrator sau personalul tehnic.

SEC.5 Protecţia uşii va fi asigurată de senzori magnetici (Reed-Contact, magnet pasiv

la uşă şi detector de contact pe partea fixă). Toate uşile vor fi echipate cu senzori.

Ca o opţiune, ferestrele pot fi echipate cu asemenea senzori magnetici.

SEC.6 Zonele din interior vor fi protejate folosind senzor PIR (receptor pasiv cu

infraroşu – tehnologie singulară). Senzorii vor fi selectaţi în vederea acoperirii a

cel puţin 80% din suprafaţă şi vor fi orientaţi în principal spre posibilele intrări

(uşi şi ferestre).

SEC.7 Unitatea de alarmă va avea o soluţie locală de energie de rezervă (baterii

reîncărcabile) calculate pentru a asigura funcţionalitatea soluţiei locale de

securitate (alarma de interior şi a perimetrului) pentru cel puţin 24 de ore în

aşteptare şi 30 minute alarma).

SEC.8 Alarma va avea o sirenă locală optic-acustică, amplasată extern.

SEC.9 Sistemul de alarmă trebuie să se poată proteja independent, prin partiţii diferite

şi interfeţele utilizatorului (tastaturi) cel puţin în Camera de Control şi Camera

Tehnică.

5.2.10.2 Soluţia de control a accesului

SEC.10 Controlul accesului va asigura identificarea personalului la fiecare

intrare în Centrul de Comandă şi Control. De asemenea, sistemul va putea

identifica fiecare persoană la ieşire.

SEC.11 Sistemul de control al accesului va fi făcut în jurul accesului inteligent

şi unităţii centrale de control, cititori (proximitatea codului) şi dispozitive de

blocare a uşii.

SEC.12 Sistemul va putea memoriza informaţie pentru cel puţin 200 de

utilizatori.

SEC.13 Pe fiecare cale de acces la Centrul de Comandă şi Control (uşile de

acces) vor fi plasate soluţii de blocare administrate prin accesul electronic şi

sistemul de control. Această soluţie de blocare va ţine uşile închise normal şi va

permite deschiderea numai dacă sistemul electronic identifică persoana autorizată.

SEC.14 In caz de urgenţă (incendiu, cutremur sau altele) uşile se vor putea

deschide automat. De asemenea, o soluţie mecanică de deschidere de rezervă va fi

furnizată. Pentru situaţii de urgenţă, unitatea de acces şi control va avea o interfaţă

care va colecta date din sistemul de incendiu & alarmă.

SEC.15 Personalul va fi identificat folosind soluţia de identificare personală –

fiecare persoană va avea propriul său card de proximitate, folosit pentru acces şi

identificare. Toate cardurile vor fi standard şi identice, dar pe fiecare card va fi

posibil de plasat un tabel imprimat conţinând identificarea utilizatorului şi

informaţia (nume şi prenume, imagine, funcţie, departament etc.).

SEC.16 Pe ambele părţi ale uşii vor fi plasate cititoare de proximitate, care vor

putea citi carduri de la cel puţin 10 cm distanţă. Cititoarele de proximitate vor fi

în permanenţă conectate la fluxurile de date la unitatea centrală, nefiind acceptate

comenzi directe la sistemul de blocare.

134 / 234

SEC.17 Sistemul de proximitate (carduri şi cititoare) va fi selectat standard şi

furnizat de mai mulţi producători, pentru ca integratorul să poate furniza carduri

pentru cel puţin 10 ani utilizabile sau clientul va putea găsi specialiştii de pe piaţă

în această perioadă.

SEC.18 Sistemul va memora şi înregistra toate evenimentele (intrare, ieşire,

deschiderea uşii, persoane etc.). înregistrarea va fi stocată local (memorie internă

statică) şi, la cerere, va fi transferabilă pe suport extern (computer local).

SEC.19 Aplicaţia software va putea asigura transferul de date în alte formate

(format tradiţional PC), realiza înregistrări, statistici, evidenţa personalului etc.

Aplicaţia software va putea funcţiona în timp real şi după analiza evenimentelor.

5.2.10.3 Supraveghere video

SEC.20 Zonele centrului de comandă şi Control vor fi în permanenţă

supravegheate de mai multe camere video, montate pentru a asigura

supravegherea cel puţin a zonelor specificate mai departe.

SEC.21 Zonele supravegheate video– zonele care trebuie supravegheate

permanent video sunt:

a. Intrările în Centrul de Comandă şi Control

b. Intrarile in Sala Operativa

c. Intrările în Camera Serverelor.

SEC.22 Supravegherea va fi asigurată în permanenţă, folosind camere video ce

vor stoca imaginile într-o zonă de stocare alocată.

SEC.23 vizualizarea imaginilor se va putea realiza din orice punct de acces în

reţeaua locală din clădirea Centrului de Comandă şi Control, însă va fi accesibilă

numai personalului autorizat. Din motive de securitate, vor fi plasate cel puţin

două (2) monitoare permanente de supraveghere video : în interiorul Camerei de

Control şi la Postul de Securitate.

SEC.24 Toţi parametrii funcţionali ai sistemului sau ai camerelor video vor

putea fi setati în întregime static folosind o interfaţă software alocată (preferabil

bazată pe web).

SEC.25 Aplicaţia de setare va fi unitară (acelaşi software / interfaţă) pentru

toate camerele de securitate din sistem însă va putea seta fiecare cameră în parte.

Setarea fiecărei camere va fi protejată de drepturile de acces, valabile numai prin

acces autorizat (prin utilizator sau parolă).

SEC.26 Pentru a asigura modul de supraveghere pe timp de noapte, sistemul va

avea dispozitive de iluminat cu Infraroşu, pentru camerele de supraveghere a

zonelor de intrare.

SEC.27 Camerele video vor fi fără întreţinere, nefiind solicitată nici o

intervenţie obişnuită. In caz de defectare, sistemul va permite schimbul fizic al

dispozitivului cameră însă nu este necesară nici o procedură specială.

SEC.28 Camerele de interior vor fi plasate în carcase tip “dome” (in scopuri

estetice.

SEC.29 Toate imaginile de la camerele de securitate video de la toate

amplasamentele şi Centrul de Comandă şi Control vor fi înregistrate într-o zonă

alocată de stocare, plasată in Centrul de Comandă şi Control . Zona de stocare va

fi redundantă şi va asigura un timp de înregistrare de cel puţin 30 zile pentru toate

camerele. Accesul la informaţia de la sistemul de securitate video stocată va fi

permis numai utilizatorilor autorizaţi.

135 / 234

5.2.11 Interfeţe de sistem

Furnizarea de interfeţe de sistem cu suport software şi integrare de sistem. Instrumentul de

programare este susţinut de hardware şi interfeţe de software.

5.2.11.1 Cerinţe generale ale interfeţelor

INT.1 Calculatorul central comunică cu sistemele conectate prin legatura fizica si

interfata digitale.

INT.2 BEMIS înregistrează prin intermediul interfeţei mesajele intrate şi ieşite,

informaţiile şi erorile, aplicându-le un marcaj temporal şi afişându-le. Dacă la

telegrama generată de BEMIS nu se răspunde, BEMIS trimite acustic şi vizual pe

ecran un semnal de eroare.

INT.3 Interfeţele de cuplare sunt conectate printr-o interfaţă TCP/ IP protocol pe

bază.

INT.4 Reţeaua de transfer este un Fast Ethernet sau un gigabit Ethernet cu switch, o

lăţime de bandă de 10/100/1000 megabiţi pe secundă.

INT.5 Porturile seriale sunt convertite cu serverele terminale în porturi IP.

INT.6 Pentru monitorizarea funcţionalităţii ambelor interfeţe şi pentru afişare se va

trimite o telegramă sau un watchdog. Astfel calculatorul central va trimite la intervale

regulate o telegramă de date către sistemul conectat, la care se va răspunde de către

subsistem.

INT.7 Pentru monitorizarea funcţionalităţii rutinei programul primeşte numere

curente de înregistrare, la care se va răspunde. În cazul în care BEMIS nu primeşte

răspuns la telegrama generată cu numărul de înregistrare corespunzător, BEMIS va

aduce un semnal de eroare corespunzătoare, vizual şi sonor pe ecran.

INT.8 Subsistemul conectat transmite cu ajutorul telegramei ciclice / watchdog

statusul propriu de operare sau eventuale erori. Acestea prevăd şi transferul altor

mesaje. În BEMIS mesajele de operare, eroare, alarmă se diferenţiază şi se sortează

per operator de sistem. În plus faţă de anunţurile şi informaţiile orientate către proces

prin interfeţe se pot susţine şi funcţii manuale individuale. Mesajele se raportează în

BEMIS. Administrarea datelor şi configurarea sistemului se realizează cu instrumente

de administrare în calculatorul central.

INT.9 Toate interfeţele se vor configura astfel încât în cazul unei erori sau a unei

căderi de sistem acestea să pornească automat / individual. În plus, există posibilitatea

de a putea reseta instrumentele interfeţei cu ajutorul software. Interfeţele redundante

trebuie închise automat în cazul unei defecţiuni iar în cazul revenirii, sistemul să

revină la stadiul de bază. În plus se va crea un schimb de interfeţe ciclic pentru

interfeţele redundante. Printr-un anunţ de operare se va prezenta care interfaţă este

activă.

INT.10 În caz de eroare toate interfeţele trebuie să fie astfel configurate încât să

lucreze fără efecte secundare asupra instalaţiei conectate şi să aibă efect asupra

calculatorului central.

5.2.11.2 Cerinţe de bază pentru interfeţele de sistem

136 / 234

INT.11 Calculatorul central susţine interfeţele pentru funcţiile de anunţare şi de

comandă. Pentru a asigura faptul că interfeţele sunt funcţionale în întreaga arie se vor

îndeplini cerinţele prezentate în continuare.

INT.12 Interfeţele manuale se vor opera pe sisteme şi se vor separa de interfeţele

BEMIS.

INT.13 Predarea documentaţiilor tehnice ale interfeţelor cu protocolul de date,

structura de date, derularea funcţiilor, cazurile test. Livrarea unui sistem test pentru

dezvoltarea interfeţei şi implementarea în BEMIS prin calculatorul central. Suport la

dezvoltarea interfeţei dacă există abateri faţă de interfeţele obişnuite cunoscute, prin

suport direct, prin suport telefonic.

INT.14 Suport la integrarea sistemului la faţa locului prin test de sistem, preluare,

participare la şedintele de proiect pentru coordonare tehnică şi din punct de vedere a

termenlor.

INT.15 În continuare se vor descrie cerinţele de bază şi funcţiile sistemului. Măsura în

care sunt operaţionale la faţa locului sisteme de acest tip depinde de structura de la

faţa locului şi de cerinţe. Interfeţele se vor stabili în fiecare caz în parte şi se vor

stabili cu beneficiarul.

5.2.11.3 Monitorizarea interfeţelor

INT.16 Pentru a monitoriza funcţionalitatea interfeţei se va crea o telegramă ciclică

sau un watchdog. Astfel BEMIS va trimite la intervale regulate o telegramă de date

către sistemul închis la care se va răspunde prin subsistem. Dacă la telegrama generată

de către BEMIS nu se răspunde, BEMIS va trimite un semnal corespunzător de eroare

care este documentat.

INT.17 Subsistemele conectate vor fi informate prin status despre starea de operare

existentă, despre anunţurile de eroare existente. Clasificarea mesajelor în funcţiune de

operare, eroare, alarmă şi revizie se vor întocmi de către administrator care le va şi

verifica.

INT.18 Funcţii individuale

a. realizare legătură / realizare comunicare

b. anunţ actualizare

c. declanşare mesaje de alarmă

d. deconectare declanşator

e. comutare declanşator pe mod revizie

f. comutare declanşator pe revizie off

g. aport simultan a mai multor detectoare (detector avalanşă)

h. afişare defecţiune interfaţă

i. repunere automată în funcţiune a unei interfeţe după finalizarea defecţiunii

j. funcţie comandă pornit

k. funcţie comandă oprit

5.2.11.4 Interfaţa pentru serverul de alarmă telefonică / server alarmare telefonică

INT.19 Suport pentru efectuarea de apeluri telefonice ca apel individual, apel de grup

sau a unui grup de apelare pentru conexiuni prin cablu, pentru conexiuni în domeniul

comunicaţiilor mobile, GSM/ UMTS.

137 / 234

INT.20 Trimiterea de informaţii mesaje scurte. Implicarea de servicii de pager

generale care sunt furnizate în calitate de participant cu o interfaţă de comunicare/

legătură la serverul de alarmă telefonică.

INT.21 Calculatorul central comunică cu serverul de alarma telefonică prin

intermediul unei interfeţe protocol TCP/ IP. Reţeaua de transport este un Ethernet

switch Fast-/Giganet.

INT.22 Pe lângă controlul standard prin matricea de alarmă trebuie să fie posibile

introducerea şi trimiterea de text liber individual (vorbit şi scris). Administrarea

datelor şi configurarea (de exemplu, gruparea posturilor telefonice respectiv

discuţiilor precum şi a aparatelor finale mobile) se realizează în fiecare subsistem.

INT.23 Administrarea datelor şi configurarea (de exemplu, gruparea posturilor

telefonice respectiv discuţiilor precum şi a aparatelor finale mobile) se face de către

administrator cu instrumentul de întreţinere al BEMIS.

INT.24 Alocarea la secţia de telefon cu apelurile efectuate. Preluarea şi prezentarea

listelor de apeluri şi de apeluri preluate din serverul de alarma telefonică din sistem.

Integrarea în funcţia CTI.

5.2.11.5 Interfaţa pentru sistemul de detectare a incendiilor

INT.25 Stabilirea unei interfeţe bidirecţionale pentru citirea şi scrierea sistemelor de

anunţare a erorilor alocate ca aşa-numita interfaţă mare de dialog. Sprijinirea

funcţionării sistemului pentru mesajele de intrare şi ieşire cu informaţii în scris/ citit.

INT.26 Implementarea interfeţei existente de conectare prin portul serial pentru

sisteme de alarmare, cum ar fi RS232, V.24, printr-un server port cu protocolul TCP/

IP prin LAN ca LAN Ethernet către calculatorul central.

5.2.11.6 Interfaţa cu sistemul de management trafic (cu integrare video)

INT.27 Interfaţă de acces pentru semnale video digitale.

INT.28 Calculatorul comunică cu sistemul de conectat prin intermediul unei interfeţe

TCP/ IP. Reţeaua de comunicare este Ethernet comutat. Lăţime de bandă de obicei 4

MB.

INT.29 Principalele subsisteme din cadrul BTMS catre trebuiesc integrate sunt

subsistemul de control al traficului urban (Urban Traffic Control) si subsistemul de

monitorizare video(CCTV). Solutia propusa este realizare unei interfete integrate

comune celor doua sisteme care sa permita operatorilor SMSUMB si BTMS schimbul

rapid de informatiilor si lucrul pe acelasi suport operational (common operational

picture).

INT.30 SMSUMB trebuie sa integreze urmarirea fluxurilor video si controlul

camerelor video.

INT.31 SMSUMB trebuie sa integreze vizualizarea inregistrarilor video

INT.32 SMSUMB trebuie sa integreze functionalitatea “Follow me”, urmarirea video

a vehiculelor de urgent.

INT.33 SMSUMB trebuie sa permita urmarirea acordarii de prioritate la trecerea prin

intersectii pentru vehiculele de urgenta.

138 / 234

5.2.11.7 Interfaţa cu pozitiile externe

INT.34 Centrul de comandă şi control este separat din punct de vedere al configurării

reţelei şi al structurii de operare în trei domenii esenţiale:

a. Segmente de reţea din zona calculatorului central pentru prelucrarea

proceselor de control ale centrului

b. Segmente de reţea în domeniul de administrare pentru postprelucrarea datelor,

analize, statistici, sisteme de contabilitate, integrarea de servicii

complementare, cum ar fi tehnologia video

c. Segmente de reţea externă pentru conectarea cu locuri de muncă externe

pentru a susţine utilizarea de postprocesare, de colectare a rapoartelor,

sistemul de contabilitate precum şi dispunerea de locuri de muncă externe / la

distanţă cu acces la calculatorul central.

INT.35 Segmente de reţea individuale sunt separate unele de celelalte prin sistemele

firewall eficiente sub supraveghere IT. Transmiterile de date în alte segmente de reţea

subordonate se realizează de către calculatorul central exclusiv unidirecţional.

INT.36 Operarea de la distanţă/ externă cu reţeaua de gestionare şi cu reţeaua

calculatorului central va fi sprijinită exclusiv prin suport server WEB / de exemplu

server CITIRX. Circuitul comunicării dintre locul de muncă extern / la distanţă se va

realiza prin clientul WEB / de exemplu CITIRX cu serverul subordonat WEB / de

exemplu CITIRX. Serverul WEB / de exemplu CITIRX primeşte porturile de

autentificare alocate în firewall pentru a putea derula relaţiile de comunicare atât cu

calculatorul central cât şi cu reţeaua de administrare.

5.2.11.8 Interfeţe digitale sistem radio / TETRA

INT.37 Sistemul de suport Digital radio. Conexiune printr-o interfaţă E1 cu interfeţele

de datele şi pregătirea pentru interfaţa IP .

INT.38 Integrarea sistemului radio digital TETRA în sistemul de control.

5.2.11.9 Interfaţa utilizatorului

INT.39 Interfaţa cu utilizatorul este parte a sistemului de control operaţional şi se va

integra pentru utilizarea şi funcţionarea acestuia. Prezentările ulterioare sunt pentru

suport în acest sens.

INT.40 Afişarea grupurilor TETRA prin vizualizarea de informaţii de stare în culori.

Lista de participanţi individuali. Culoarea indică ce grup este în funcţie / vorbeşte.

INT.41 Linia actuală a utilizatorului este afişată. Afişarea personalului şi resurselor.

Culoarea indică statusul. Crearea SDS sosit din SDS. Enumerarea apelurilor de

urgenţă şi a cerinţelor de revenire. Preluare/ acceptarea prin dublu-click. Filter

Manager pentru a seta conţinutul ecranului.

5.2.11.10 Interfaţă la servere externe

INT.42 Sistemul calculatorului central este separat din punct de vedere al configurării

de reţea şi structura de prelucrare în zonele:

a. segmente de reţea în domeniul calculator central pentru prelucrarea centrului

de control al proceselor

139 / 234

b. segmente de reţea în domeniul de administrare pentru utilizarea de

postprocesare, analize, statistici, sisteme de contabilitate, integrarea de servicii

complementare, cum ar fi tehnologia video

INT.43 Segmente de reţea individuale sunt separate unele de celelalte prin sistemele

firewall eficiente sub supraveghere IT. Transmiterile de date în alte segmente de reţea

subordonate se realizează de către calculatorul central exclusiv unidirecţional. Datele

din procesele BEMIS sunt transferate spre postprelucrare după utilizare, facturare şi

sprijin pentru serviciile de management pe serverul de management în administrare

LAN.

INT.44 Serverul de WEB / de ex. CITRIX primeşte porturi de drepturi alocate în

firewall pentru a putea derula relaţii de comunicare cu segmentele de reţea din reţeaua

calculatorului central dar şi din reţeaua de administrare.

5.2.11.11 Interfeţe radio GSM

INT.45 Interfetele GSM standard vor asigura cel putin urmatoarele functionalitati:

a. transferul datelor prin intermediul serverului de comunicare la interfaţa GSM

b. trimiterea de date cu selectare în sistemul central

c. pregătirea datelor de trimis prin mesajele de alarmare

d. marcarea datelor de transferat prin intermediul GSM

e. suport trimitere de texte goale din sistemul central prin intermediul interfeţei

GSM

f. susţinere a funcţiei de comunicare în reţeaua GSM

g. comunicaţiile intrate se vor primi exclusiv prin firewall sau prin serverul web

cu LAN-BEMIS rezultat.

5.2.11.12 Interfeţe date radio SMS

INT.46 Interfetele SMS standard vor asigura cel putin urmatoarele functionalitati:

a. trasmitere de mesaje SMS prin intermediul interfeţei GSM, cuplate prin

serverul de comunicare sau prin routerul de sistem legat la circuit la

conexiunea de date cu serverul sistem al providerului de reţea mobilă.

b. transmitere de date SMS-uri

c. selectare în sistemul principal

d. marcarea date/ textelor care urmează să fie transmise

e. transfer de mesaje de alarmare

f. transfer de texte goale cu alocarea de cote gratuite pentru textele, datele şi

informaţiile de transmis

5.2.11.13 Interfeţe FAX

INT.47 Interfetele FAX standard vor asigura cel putin urmatoarele functionalitati:

a. suport al unei interfeţe Fax cu circuit prin serverul de fax

b. transmiterea de mesaje, date şi texte din sistemul de control al misiunii.

c. transfer la ediţia de fax server pe interfaţa de fax

d. suport pentru interfeţe multi fax

e. salvare intermediară a textelor transmise

f. raport pentru faxurile trimise

140 / 234

g. salvare intermediară a textelor dacă acestea nu pot fi transmise imediat prin

porturile de conectare disponibile

5.2.11.14 Interfaţă e-mail

INT.48 Interfata implementata pe serverele de mail va asigura cel putin urmatoarele

functionalitati:

a. suportul unei interfeţe de e-mail pentru transmiterea de date, ştiri, texte din

circuit.

b. opţiuni pentru a selecta din textele şi mesajele pregătite

c. configurare sprijin pentru transferul de texte din telegramele de alarmă

d. marcarea textelor de transferat

e. preluarea în formatul de e-mail.

f. transfer de date prin firewall în gestionare LAN pentru predarea prin interfaţa

de email în gestionarea LAN sau direct prin internet cu pornirea firewall.

g. înregistrarea în jurnal a mesajelor trimise

h. preluarea într-un protocol de trimiteri

i. suport al unui index de adrese cu preluarea din datele de bază/ index de adere

j. afişarea mesajelor trimise

k. afişaj pentru mesajele care nu au fost trimise din cele de trimis

5.2.12 Sub-Sistemul baza de timp

TIME.1 Furnizorul va trebui sa prevadă în CMISU o bază unică de timp real, sigura si

stabila, precum şi un repetor de timp separat (tip „Time-Server”). Sursa exterioară de

tact va trebui sincronizată cu alte purtătoare de date, considerate universale si

compatibile cu sistemele general acceptate in Uniunea Europeana.

TIME.2 În conformitate cu cele de mai sus, baza de timp a sistemului va utiliza un

receptor GPS pentru livrarea impulsurilor de tact. Toate echipamentele furnizate şi

instalate în cadrul acestui Contract vor prelua automat informatia de ceas de la aceste

facilităţi.

TIME.3 Calculatorul central comunică cu un sistem central ceas cu timp GPS printr-un

protocol TCP / IP. Serviciul de timp este susţinut de un server ceas, cu o alocare ceas

la un server de sistem. Reţeaua de transmitere este un Ethernet rapid Fast/ Giganet.

Sprijin pentru timpul standard pentru aplicaţiile de sincronizare.

5.2.13 Sistemul de alarmare – avertizare pentru populatie

ALA.1 Proiectul va include interfatarea, integrarea si implementarea nodului de

comanda a sistemului de alarmare-avertizare pentru public. La nivelul Municipiului

Bucuresti, acesta include un numar de sirene, precum si reteaua de comunicatii

(analogica si digitala) aferenta.

ALA.2 Contractorul va include la nivelul CMISU infrastructura fizica si interfata

necesare conectarii la sistemul de alarmare-avertizare. Aceasta va include cel putin o

statie de lucru si un server dedicat (fizic sau logic).

ALA.3 Contractorul va livra solutia de management integrat a sistemului de alarmare-

avertizare a populatiei. Aceasta va rula in cadrul BEMIS, ca aplicatie Web-Based,

accesibila atat de la nivel central cat si in mod de acces de la distanta.

141 / 234

ALA.4 Aplicatia va permite accesul de la un numar nelimitat de terminale externe

sistemului, cu conditia ca acestea sa fie conectate securizat.

ALA.5 Toata comunicatia se va face criptat

ALA.6 Toate comenziile la nivelul aplicatiei se vor aplica numai dupa autentificarea

utilizatorului, prin metoda sigura (semnatura digitala sau similar).

ALA.7 Aplicatia va asigura monitorizarea si prezentarea, in forma grafica, a

circuitelor de comanda si a starii sirenelor si a dispozitivelor din sistem.

ALA.8 Toate actiunile, fluxurile si informatiile vehiculate in sistem vor fi memorate

intr-un fisier dedicat (log de evenimente).

ALA.9 Interfata de utilizator va asigura urmatoarele facilitati:

a. aplicatie software cu operare centralizata, pe server

b. capacítate de operare pe cel putin 2 monitoare simultane, din care unul

afiseaza harta sinoptica

c. functie de apropiere in harta (zoom)

d. capabilitate de operare cu ecran senzitiv (tip touchscrieen)

ALA.10 Sistemul va permite conectarea folosind cel putin urmatoarele tipuri de

interfete si/sau protocoale:

a. RS232

b. Ethernet

c. Analog (cablat)

d. Radio (VHF si/sau UHF – transmisie FFSK cu criptare 24 bit sau superior)

ALA.11 Contractorul va avea in vedere analizarea in detaliu a sistemului implementat

la nivelul Muncipiului Bucuresti, astfel incat solutia propusa sa fie perfect compatibila

cu acesta.

ALA.12 In cadrul CMISU va fi livrat un echipament de comanda a sistemului de

alarmare-avertizare independent, acesta avand functie de back-up in caz de cadere a

sistemului central. Caracteristicile echipamentului de comanda de siguranta vor fi:

a. controller multifunctional, dedicate sistemului de alarmare-avertizare

b. ecran tip LCD-TFT, senzitiv

c. Interfete de conectare: RS232, RS485, USB, Ethernet

Data fiind complexitatea sistemului, ofertantul va pune la dispozitie un expert arhitect

sisteme IT cu studii superioare în domeniul IT&C (se vor prezenta copii după diplomele de

sudii), competente in domeniul arhitecturilor complexe (se va prezenta certificare

profesionala TOGAF 8 sau echivalent), competente privind dezvoltarea aplicatiilor dovedite

prin certificarea Microsoft Certified Solution Developer sau echivalent si cu experienţă

profesională în domeniul IT&C de cel putin 5 ani.

6 Cerinte functionale

Sistemul va functiona pe baza unei suite de sub-sisteme si aplicatii informatice

complexe, deschise, generice sau dezvoltate special pentru acesta. Suita de aplicatii se va

numi BEMIS (initialele Bucuresti – EMIS).

În continuare sunt descrise cerinţele tehnice pentru asigurarea proceselor operaţionale

în centrul de comandă şi control.

• Înregistrarea semnalizării

• Dispecerizare

142 / 234

• Alarmare

• Suport intervenţie

• Închidere intervenţie

• Procesare intervenţie

• Dubla înregistrare

• Intervenţia în vecinătate

• „Strategii pentru mijloacele de intervenţie“

• Suport grafic

• Distribuirea şi cumularea intervenţiilor

• Organizarea anticipată a intervenţiei

• Semnalizări multiple

• Documentaţia

• Semnalizarea automată a incendiilor

• Caracteristici pentru serviciul de salvare

Intervenţia medicului de urgenţă

Transport bolnavi

• Comunicări şi informaţii

Urmatoarele procese vor fi acoperite prin functionalitati minim obligatorii:

6.1 Înregistrarea semnalizării

FN.1 Înregistrarea semnalizării se efectuează ca:

a. înregistrare manuală a semnalizării prin apeluri telefonice sau radio (semnal radio

analog, RSS, SDS ) cu transfer de informaţii ale apelantului, ID apelant.

b. preluare directă a numerelor utilizatorilor la recepţionarea apelului de urgenţă şi

afişare automată a adresei apelantului

c. înregistrare automată a semnalizării prin sistemele de detectare a intruziunilor /

incendiilor, cu afişarea ID-ului apelantului

d. preluarea datelor obiectivului la intrarea alarmei de avertizare

e. înregistrare la alegere a locului de intervenţie prin localitate, cartier, obiectiv,

stradă cu suportul datelor de referinţă şi cu suportul GIS

FN.2 Căutare tip Wildcard

a. Preselecţie localitate, cartier, zone

b. Reducere a listei de selecţie cu fiecare literă introdusă

c. Prezentare directă a străzilor transversale. În funcţie de selecţie inserarea automată

a tuturor obiectivelor adiacente unei străzi/ număr.

d. Indicaţii directe la informaţiile consemnate despre stradă şi obiectiv

e. Efectuarea verificării numărului

f. Recunoaşterea obiectivului prin număr

g. Marcarea locului intervenţiei în sistem grafic

h. Preluarea locului intervenţeiei din modulul grafic

i. Alocarea unui timp de avertizare în avans în cazul intervenţiilor planificate

143 / 234

j. Alocarea unui durate aproximative a intervenţiei

k. Planificarea automată a transporturilor cu luarea în considerare a duratei de

intervenţie sau fără durată de intervenţie

l. Marcarea intervenţiilor ciclice cu generarea automată a încheierii intervenţiei

m. Luarea în considerare a timpilor de întrerupere

FN.3 Sistemul asistă înregistrarea semnalizării cu ID-ul de avertizare prin

verificarea localităţii, verificarea serviciului de intervenţie precum si a cuvântului-cheie de

intervenţie. Aici vor fi utilizate datele de referinţă furnizate şi sau investigaţiile externe de

date, de ex. date adresă, date localitate, date obiectiv, servicii de intervenţie, cuvinte-cheie de

intervenţie, cuvinte-cheie (pompieri, serviciu ajutor, serviciu salvare) sau datele din fişierele

de informaţii.

FN.4 În cazul înregistrării manuale a semnalizării aceste date vor fi utilizate liber.

Sistemul trebuie să ajute prin datele de referinţă disponibile, precum şi cu datele de informare

liber introduse.

FN.5 În cazul înregistrării automate a semnalizării cu conectare la sistemele de

comunicaţie alocate vor fi utilizate datele înregistrate definitiv despre localitate şi obiectiv,

precum şi cuvintele-cheie de intervenţie. Acestea trebuie înregistrate automat sau modificate

manual. Înregistrarea se efectuează la alegere în câmpul apelant şi/sau în câmpul anunţ

intervenţie. Informaţiile individuale înregistrate la date localitate sau obiective vor fi marcate

în computerul central pentru intervenţii. Pentru separarea aceloraşi date localitate se

efectuează în primul rând marcarea printr-un cod localitate/ cartier. În cazul unor date

localitate comune se va aloca un cod date localitate.

FN.6 Datele de intervenţie necesare pentru operarea avertizării şi pentru operarea

generală a centrului de comandă şi control, inclusiv datele statice de referinţă trebuie

consemnate într-o baza centrală de date, care va fi ţinută redundant şi la care orice centru de

intervenţii îndreptăţit va avea acces cu procesele şi funcţiile sale. Informaţiile deja

înregistrate vor fi salvate ca istoric şi vor fi puse la dispoziţie pentru înregistrarea

semnalizărilor şi raportul de situaţie.

FN.7 La înregistrarea semnalizărilor vor fi puse la dispoziţie informaţii suplimentare

din baza de date relaţională, care la nevoie pot fi accesate.

FN.8 Acest lucru este valabil şi pentru datele suplimentare externe, ca de ex.

informaţii despre condiţiile meteorologice de pe serverele web, datele din fişierele cu

materiale periculoase însă cu afişarea pe un sistem independent din cadrul serverului central

pentru intervenţii.

FN.9 În template-ul de înregistrare vor fi înregistrate informaţiile de avertizare cu

ajutorul câmpurilor de prelucrare. Câmpurile de prelucrare obligatorii trebuie marcate în mod

clar.

FN.10 Câmpurile obligatorii (marcate color) sunt cel putin urmatoarele: informatii

referitoare la localizare(precum localitate, cartier, stradă) şi cuvintele-cheie de intervenţie.

FN.11 Câmpurile opţionale din template-ul de înregistrare servesc la completare şi

informare.

144 / 234

FN.12 Prin introducerea de text liber pot fi înregistrate informaţii şi texte de

avertizare suplimentare. Trebuie să existe posibilitatea de a prelua prin funcţiile de copiere

texte din alte blocuri de text sau date de informare. Numărul de caractere ce pot fi introduse

nu trebuie să fie limitat.

FN.13 Continuarea prelucrarii va fi posibilă numai în cazul în care sunt completate

câmpurile obligatorii cerute. Câmpurile obligatorii necompletate vor fi indicate prin marcarea

vizuală a câmpurilor respective. Cursorul de scriere va fi plasat automat în primul câmp

obligatoriu necompletat.

FN.14 O dată cu înregistrarea semnalizării sistemul va insera automat data, ora şi

dispecerii competenţi.

FN.15 La încheierea unei înregistrări de semnalizare ca mesaj de alarmă are loc

salvarea generală a înregistrării semnalizării. Semnalizarea înregistrată va fi salvată într-o

lista „Intervenţii înregistrate, neatribuite“ şi aici vor fi supravegheate pentru prelucrarea

ulterioara. În cazul în care se depăşeşte perioada estimată de timp, sistemul va da o avertizare

vizuală.

FN.16 Înregistrarea semnalizării va fi introdusă şi procesată în sistem in timp real. În

funcţie de configuraţia sistemului următoarele date minime trebuie introduse în sistem şi

preluate în jurnalul operativ / protocolul de intervenţie: Ora apelului, preluarea apelului,

declanşarea senzorului, recepţionarea senzorului, întocmirea unui mesaj de alarmă prin

salvare la transmiterea către un alt centru de intervenţii.

6.2 Înregistrarea locaţiei / Verificarea locaţiei

FN.17 La introducerea unor date despre locaţie va fi afişat automat un nomenclator al

numelor similare şi numelor alternative sau sinonime cu locaţia pentru:

a. zone

b. localităţi

c. cartiere

d. străzi

e. secţiune stradă

f. intersecţie străzi

g. număr

h. străzi transversale cu intersecţii, intersecţii mari, secţiune stradă, structurat după

înregistrarea numărului

i. obiective (clădiri, compartimente, şantiere / zone închise, senzori cu denumire şi

statut, etc.)

FN.18 În cazul în care denumirile locaţiei apar de mai multe ori, atunci sistemul va

face automat o referire la informaţii suplimentare, ca localitate aferentă, localitate la stradă,

cartier la localitate, zonă la localitate.

FN.19 Înregistrarea unei locaţii trebuie să se poată efectua după reguli ierarhice:

a. prin intermediul informaţiilor deja cunoscute, ca stradă sau număr

145 / 234

b. prin intermediul selecţiilor zonelor supraordonate, ca ţară, localitate, cartier, stradă,

stradă transversală, număr

FN.20 Dispecerul are posibilitatea de a scrie datele locaţiei direct în câmpul pentru

introducerea datelor sau să preia localitatea sau obiectivul căutat dintr-un nomenclator al

localităţilor.

FN.21 Informaţiile despre locaţie înregistrate vor fi marcare în paralel cu un simbol

pe ecranul pentru informaţii grafice. Acest suport grafic (suport GIS) pentru verificarea

locaţiei se efectuează prin conectare a datelor despre locaţie, cu referinţe geografice, la datele

grafice.

FN.22 Prin conectarea datelor despre locaţie şi datelor grafice există posibilitatea de a

prelua datele despre locaţie prin clicul mouse-ului din informaţiile grafice din prelucrarea

intervenţiei / template-ul de semnalizare.

FN.23 În plus înregistrarea trebuie să fie asistată prin grafică la:

a. Localizare in GIS

b. Pozitionare/Repozitionare în GIS

FN.24 O altă metodă de asistare pentru introducerea de date ale locaţiei este asistarea

unei înregistrări rapide prin codurile combinate cu semne speciale pentru mai multe câmpuri.

Prin intermediul semnelor speciale trebuie să existe posibilitatea de a furniza locaţii multiple

sau de a marca intersecţii şi secţiuni.

Exemplu:

Strada-12 = Liniuţă ca separator de ex. pentru stradă şi număr

Localitate + strada principală + strada = Semnul „+” ca separator de ex. pentru două

străzi ca marcare a unei intersecţii.

FN.25 La câmpurile de denumire a localităţii trebuie să fie posibilă introducerea a

oricât de multe sinonime şi denumiri alternative şi aceasta trebuie să conducă la o înregistrare

corectă. Sistemul trebuie sa permita particularizarea sinonimelor pentru specificul limbii

romane. Dictionarul de sinonime sau prescurtari trebuie sa poata fi schimbat de catre

beneficiar.

FN.26 Asistarea căutării şi structurării secţiunilor de stradă după număr şi străzi

transversale.

6.3 Căutare fonetică

FN.27 Pentru căutarea fonetică datele despre locaţie trebuie ordonate după sonoritate.

Numele similare care indică acelaşi model sonor din punct de vedere fonetic trebuie indicate

din baza de date prin verificarea locaţiei.

6.4 Serviciul de intervenţie

146 / 234

FN.28 Serviciile de intervenţie sunt beneficiari ai BEMIS: serviciul de pompieri,

serviciul de salvare cu salvare de urgenţă, servicii de transport, în principal serviciul de

transport bolnavi, servicii tehnice de salvare, servicii de comunicaţii şi servicii speciale.

FN.29 Serviciile de intervenţie reprezintă domenii de lucru independente şi pot fi

împărţite după forma de organizare în diverse centre de intervenţie.

FN.30 Serviciile de intervenţie se împart şi/sau se cumulează în funcţie de cerinţe

conform intervenţiei, astfel încât rezultă intervenţii principale şi secundare. Capacitatea de

cumulare a intervenţiilor principale şi secundare trebuie documentată şi prezentată continuu

în sistem.

FN.31 În plus există posibilitatea de a aloca serviciilor de intervenţie numere de

intervenţie independente, pentru efectuarea evaluărilor, statisticilor şi deconturilor după

derularea serviciului de intervenţie.

FN.32 Serviciul de intervenţie are asociate cuvinte-cheie de intervenţie. În cazul în

care nu se selectează un serviciu de intervenţie, atunci serviciul de intervenţie va fi alocat

automat în funcţie de cuvântul-cheie de intervenţie înregistrat.

FN.33 Prin template-ul de intervenţie există posibilitatea de a aloca anticipat serviciul

de intervenţie, de ex. pentru a pregăti resursele pentru anumite sarcini cum ar fi transportul

bolnavilor şi pentru a le optimiza pentru informaţia de avertizare şi prelucrarea propriu-zisă.

6.5 Cuvânt-cheie de intervenţie

FN.34 Cuvântul-cheie de intervenţie este parametrul informaţiei „ce eveniment este

semnalizat“. Pentru înregistrarea unui cuvânt-cheie de intervenţie există posibilitatea de a

introduce cuvântul-cheie direct la înregistrarea semnalizării sau de a atribui respectivului

cuvânt-cheie alte cuvinte-cheie înregistrate.

FN.35 Cuvintele-cheie trebuie asociate tipurilor de incidente şi /sau mijloacelor de

intervenţie.

FN.36 Sistemul trebuie în plus să propună cuvinte-cheie de intervenţie la

introducerea cuvintelor-cheie definite. Dispecerul poate introduce informaţia direct sau poate

prelua printr-o funcţie de copiere cuvântul-cheie de intervenţie.

FN.37 Înregistrarea cuvintelor-cheie cu litere şi reducerea listei pe baza caracterelor

introduse (cum ar fi localităţile) pentru selecţie şi înregistrare.

FN.38 O dată cu înregistrarea cuvântului-cheie de intervenţie se efectuează

verificarea vecinătăţii(vezi intervenţiile învecinate) şi alocarea serviciului de intervenţie(de

ex. serviciul de pompieri/salvare).

FN.39 Trebuie efectuată alocarea unui cuvânt-cheie de alarmă provenita de la un

obiectiv (de ex. cuvânt-cheie de la senzor).

6.5.1 Modificarea cuvintelor-cheie legate de obiectiv, zonă, stradă

147 / 234

FN.40 După verificarea locului de intervenţie cu privire la eventualele tipuri de străzi,

tipuri de obiective sau tipuri de zone indicate trebuie să fie posibilă o modificare a

cuvântului-cheie.

FN.41 Dispecerizarea trebuie efectuată cu cuvântul-cheie înlocuit automat în funcţie

de stradă, obiectiv sau zonă. Sistemul software verifică în funcţie de acestea cuvântul-cheie

definitiv. Cuvântul-cheie definitiv înlocuieşte cuvântul-cheie iniţial şi devine cuvânt-cheie

principal pentru dispecerizare.

Exemplu:

La semnalizarea unui eveniment se utilizează cuvântul-cheie INCENDIU. La

verificarea locaţiei adresa va fi recunoscută, fiind vorba la respectiva adresă despre un

obiectiv deosebit (de ex. cămin de bătrâni = tipul de obiectiv), aflat pe o stradă cu o

insuficientă alimentare cu apă de stins incendiile (= tipul de stradă). Locul intervenţiei se află

în zona pompierilor voluntari (=tipul de zonă), care va fi alarmat în această zonă în paralel cu

pompierii. Cuvântul-cheie INCENDIU trebuie modificat respectiv înlocuit în mod

corespunzător stabilirii diferitelor tipuri. Trebuie să fie clar dacă măsurile / modificarea

cuvântului-cheie / înlocuirea cuvântului-cheie din tipul de străzi, zone şi obiective se vor

adăuga măsurilor de la cuvântul-cheie INCENDIU, sau dacă este posibilă modificarea

diferenţiatoare a cuvântului-cheie (verificare a ceea ce se solicită în măsurile suplimentare din

tipurile respective şi ceea ce este deja furnizat în cuvântul-cheie principal).

6.5.2 Modificarea cuvântului-cheie de intervenţie

FN.42 La modificarea situaţiei de intervenţie poate fi modificat cuvântul-cheie de

intervenţie înregistrat. Modificarea se efectuează oricând prin reînregistrarea unui cuvânt-

cheie de intervenţie sau prin utilizarea unui buton funcţional +/- pentru adaugarea sau

eliminarea unui cuvânt-cheie. Există posibilitatea înregistrării unui cuvânt-cheie adiţional.

FN.43 După modificarea cuvântului-cheie de intervenţie, pe baza modificării va fi

posibila o nouă dispecerizare. Propunerile de dispecerizare sau propunerile de măsuri deja

existente vor fi efectuate în conformitate cu cuvântul-cheie completat. Dispecerizările

completate sau modificate vor fi marcate color faţă de celelalte dispecerizări existente pe

ecranul de prelucrare.

FN.44 În cazul modificării unui cuvânt-cheie mijloacele de intervenţie deja alocate

vor fi prezentate cu menţiune de modificare. Acest lucru înseamnă în cazul adaugarii unui

cuvânt-cheie că mijloacele de intervenţie vor fi adaugate automat. În cazul eliminarii unui

cuvânt-cheie se va marca ce mijloacele de intervenţie pot fi înlăturate manual.

6.6 Tabloul sinoptic al cuvintelor-cheie de intervenţie

148 / 234

FN.45 În tabloul sinoptic al cuvintelor-cheie de intervenţie, cuvintele-cheie de

intervenţie vor fi stabilite şi reprezentate separat în funcţie de departamente, servicii

(pompieri, serviciu ajutor, salvare de urgenţă, transport bolnavi, informaţii, evenimente cu

daune de mari proporţii etc.) şi în funcţie de necesităţi. Cuvintele-cheie de intervenţie pot fi

completate printr-un cod de prioritate atât ca prezentare, cât şi ca funcţie.

6.6.1 Intervenţii învecinate

FN.46 Înainte de ramificarea căutării mijloacelor de intervenţie se va verifica dacă la

aceleasi obiective sau in localităţile, cartierele, străzile, secţiunile de stradă, numere aflate în

vecinătate se derulează o "intervenţie învecinată" sau dacă pentru acestea există o

semnalizare.

FN.47 Afişajul include toate centrele de intervenţie în verificare. Sarcinile noii

intervenţii pot fi preluate respectiv verificate, dacă este vorba despre un proces care se află

deja în prelucrare / intervenţie. În cazul declanşării mai multor senzori automaţi, semnalizarea

va fi alocată automat obiectivului furnizat. Acest lucru este valabil şi atunci când sunt alocaţi

mai mulţi senzori unui singur obiectiv(cazul obiectivelor mari).

FN.48 După alocare se efectuează o verificare şi indicarea intervenţiilor învecinate

respectiv aceloraşi intervenţii, dacă este vorba despre declanşarea senzorilor din aceleaşi

obiective sau din obiective învecinate. Intervenţiile învecinate vor fi afişate ca listă de

selecţie, va rezulta o listă încrucişată şi afişarea în sistemul grafic.

FN.49 La declanşarea senzorilor trebuie prezentate în sistemul grafic planurile

aferente ale obiectivului: planul de evacuare a clădirii cu prezentarea senzorilor declanşaţi şi

cu prezentarea dinamică a informaţiilor. În cazul unei extinderi a declanşării senzorilor,

indiferent de înregistrarea în sistem a semnalizărilor primite, afişajele trebuie actualizate

permanent.

FN.50 Stabilirea distanţelor pentru marcarea zonelor învecinate va fi configurabila la

nivel de obiectiv. Dispecerul are în plus posibilitatea de a ajusta liber aceasta distanta. O altă

posibilitate este reglarea dinamică a distanţei în baza cuvintelor-cheie indicate şi a tipului

mijloacelor de intervenţie.

FN.51 Verificarea vecinătăţii în sistem trebuie trebuie sa fie o functionalitate ce poate

fi activata/dezactivata la nivel de utilizator.

6.7 Mesaj multiplu in cazul unui incident

FN.52 In cazul unor apeluri de urgenta, apeluri speciale si alarme trebuie sa se

realizeze de catre sistem o verificare a cuvintelor cheie de aplicatie cu privire la mesajele

primite din zone apropiate, mesajele repetate sau similare.

FN.53 Rezultatul verificarii este indicat pe fiecare staţie de lucru. Identificarea

trebuie sa fie realizata in fiecare caz, indiferent cine a deschis cazul.

149 / 234

FN.54 Cazurile similare, respectiv cele gasite adiacent, trebuie sa fie indicate

utilizatorului prin alocarea unui punct comun. Distanta dintre incidentele similare trebuie sa

fie configurabila.

6.8 Aparitia stringenta a mesajelor

FN.55 In cazul incidentelor cu nevoia stringenta a acceptarii apelurilor de

urgenta/accesului semnalizatoarelor (avalanse de mesaje) BEMIS-ul trebuie sa administreze

in scurt timp o amplitudine de mesaje/acceptari de mesaje.

FN.56 Acceptarea mesajului in cazul avalanselor de mesaje (manual sau automat)

sprijina inregistrarea rapida a multor cazuri care pot sa fie procesate de abia mai tarziu.

Mesajele trebuie sa fie colectate in lista cazurilor „care nu sunt alocate“.

FN.57 Mesajele trebuie sa fie sortate in special dupa urmatoarele criterii:

a. Cuvinte-cheie de aplicatie

b. Prioritate

c. Timpul de acces

d. Locatia

e. Informatii cu privire imaginea mesajului

FN.58 Alte criterii de sortare/filtrare trebuie sa fie permise.

FN.59 Cazurile care nu sunt alocate trebuie sa fie distribuite pe staţii de operare

pentru fiecare pas de procesare (inspectii, controale, ghidare, procesari). Cazurile care nu sunt

alocate trebuie sa poata fi transmise mai departe catre locatii optionale sau pregatite sa preia

cazuri in interiorul unui centru de comandă cat si catre locatii in afara centrului de comandă

pentru a fi procesate in continuare.

FN.60 Daca un caz nu este procesat intr-un timp definit, se realizeaza in mod automat

o conexiune catre alta locatie de aplicatie. Mai multe locatii de executare a cazurilor pot fi

conectate pentru o distributie a aplicatiei intr-o grupa de urmarire sau de colectare.

FN.61 In cazul unei locatii mari cu volum ridicat de mesaje se realizeaza distributia

datelor dupa cuvintul-cheie, locatie, domeniu, serviciu.

6.9 Imaginea de ansamblu a aplicatiei

FN.62 Cazurile curente precum si cele planificate in prealabil trebuie sa fie

prezentate in ansamblu. Imaginea de ansamblu a aplicatiei contine toate cazurile de la

colectarea acestora pana la finalizare. Filtrele trebuie sa fie presetate.

FN.63 In plus trebuie sa existe posibilitatea ca fiecare filtru sa poata fi setat

individual.

6.9.1 Predarea si expedierea mesajelor si aplicatiilor

150 / 234

FN.64 In serverul central de aplicatie configurarea „Predarea si expedierea mesajelor

si aplicatiilor“ trebuie sa fie configurabila. Prin aceasta caracteristica exista posibilitatea ca

incidentele in procesare si/sau accesate pentru procesarea in continuare sau pentru predarea

altor statii de operare sa fie expediate in continuare. Astfel trebuie sa fie furnizat un buton cu

functia de „expediere/predare“.

FN.65 Daca acest buton este activat dupa accesarea unui mesaj sau in cazul unei

aplicatii suportate, apare o lista a operatorilor catre care se poate face predarea de

aplicatii/mesaje. Pentru dispeceri este irelevant daca acesti operatori se gasesc in interiorul

propriului centru de comanda sau intr-un centru de comanda preconfigurat in retea (centru de

control in caz de urgenta).

FN.66 Predarea, respectiv expedierea mai departe a cazurilor este inregistrata si

supravegheata in sistem. Cel care a expediat primeste o confirmare in momentul deschiderii

cazului predat. Daca preluarea nu se poate face catre statia de operare care trebuie sa preia,

aplicatia ramane la posesor. Prin predare/expediere cazul trebuie sa se subordoneze noului

operartor ca „posesor“. Informatiile cu privire la apelul pentru acest caz trec apoi catre statia

de operare care trebuie sa le prelueze.

6.9.2 Campul de text

FN.67 In ecranul de introducere a datelor este pus la dispozitie un camp de text liber

pentru notite si observatii incluzand alocarea la un caz. Campul de text trebuie sa dispuna de

functii de editare (marcare, copiere, stergere, transferare).

FN.68 Textele pregatite trebuie sa poata fi preluate din campurile de text existente

sau din cazurile asemanatoare.

FN.69 Dispecerul trebuie sa aiba posibilitatea sa preia din cazurile existente, pe langa

campuri de tip text, si alte tipuri de informatii, prin copiere, respectand securitatea IT

(Exemplu: informatiile sub forma de imagini).

FN.70 Informatiile sub forma de text trebuie sa fie inregistrate si prezentate in

istoricul modificarilor cazului.

6.9.3 Memorare

FN.71 Dupa acceptarea manuala a unui mesaj imaginea mesajului trebuie sa fie

memorata si sa ii fie alocat un numar de caz unic in BEMIS.

6.9.4 Numarul de aplicatie

FN.72 Sistemul gestioneaza numerele de cazuri.

151 / 234

FN.73 Numarul de caz este desemnat si indicat prin postarea unui mesaj in sistem.

Alocarea ferma se realizeaza la confirmarea imaginii de mesaj prin memorarea sau derivarea

in dispozitie/alarmare.

FN.74 Cazurile planificate in prealabil primesc in cadrul planificarii anterioare un

numar de procedura. Prin activarea cazului numarul de caz este atribuit si alocat in mod ferm.

FN.75 Numerele de aplicatie sunt predeterminate intr-o structura ierarhica. Serviciul

de executie primeste un numar central - de exemplu serviciul de pompieri. Serviciile de

completare alocate, precum serviciul de salvare si alte servicii sunt identificate prin numerele

de subcazuri care permit permit o alocare clara la cazul principal.

FN.76 Numarul de cifre al numarului de caz trebuie sa fie prezentat public si trebuie

sa asigure o protectie de pana la 12 cifre.

FN.77 Numarul apelului de urgenta inregistrat trebuie sa fie alocat numarului

incidentului din baza de date.

6.9.5 Mesaje informative

FN.78 Mesajele care nu au ca rezultat crearea unui caz sau au doar caracter

informativ sau sunt apeluri conectate gresit pot fi tratate prin ca mesaje de tipul „serviciu

informational“. Daca in cazul unui mesaj acceptat butonul „Informatie\“ este activat, sistemul

comuta in modul de informare. In modul de informare informatia apelantului este transferata

automat in informatia aplicantului si in informatia apelantului. Cuvantul-cheie de aplicatie

este setat cu un cuvant-cheie de aplicatie „informatie“, rezervat in prealabil.

6.9.6 Atribuirea imaginii de mesaj conform serviciilor

FN.79 Functia de posesor/detinator de caz trebuie sa fie configurata dupa diferite

criterii: Unic posesor, posesor-grup, posesor-total ca functii ale centrului de control.

6.10 Dispozita de interventie (ordinul de executie a operatiunii)

FN.80 Dispozitia se compune din propunerea de dispozitie pe baza unei planificari de

aplicatie conform unei ordini de alarma si de pornire.

6.10.1 Prezentarea dispozitiei

FN.81 Dispozitia trebuie sa se imparta in informatii referitoare la

aplicatii/independente de aplicatii si in resurse.

152 / 234

FN.82 Resursele alocate si/sau masurile trebuie sa fie indicate prin descrierea si

prezentare sub forma unei liste de dispozitie cu fiecare conditie de procesare. Dispozitia este

facuta pe baza informatiilor actuale referitoare la statusul resursei in mod automat. Prin

dispozitie resursa responsabila este activata. Resursa este blocata pentru alte procesari si

dispozitii.

FN.83 Resursele dispuse sunt prezentate impreuna cu data/ora alocarii intr-o lista de

dispozitie. In plus activitatile complementare, precum semnalizarea, deschiderea cataloagelor

de masuri si informatiile suplimentare sunt indicate. Dispozitia pregatita automat pe baza

planurilor de alarma, a ordinei de alarma si de incepere precum si pe baza unei liste de masuri

este standardul obligatoriu. Devierile manuale si completarile trebuie sa fie protejate de

sistem pentru a putea reactiona in mod corespunzator in situatii speciale.

FN.84 In cazul modificarii cuvantului-cheie de aplicatie sau a locatiei de aplicatie

dispozitia trebuie sa fie ajustata automat. Astfel resursele necesare suplimentar trebuie sa fie

completate automat.

FN.85 La modificarea cuvantului-cheie trebuie sa se completeze resursele luand in

considerare resursele deja dispuse. In functie de configurare si de setarile sistemului in

aceasta dispozitie se pot prezenta resurse din contingente disponibile, liber sau din cazurile in

progres.

FN.86 Prezentarea dispozitiilor in fisierul „aplicatii dispuse“ conform criteriilor de

sortare care vor fi prevazute, in legatura cu tipul de caz, de cuvantul-cheie, de prioritate, de

resursa, de locatia de aplicatie, de alocarea in grupe de procesare si alti parametrii (reglarea

parametrilor de filtrare).

6.10.2 Parametrii dispozitiei

FN.87 La baza dispozitiei sta cautarea de resurse prin prezentarea alarmelor

planificate in prealabil, masurilor si informatiilor.

FN.88 Bazele dispozitiei sunt urmatorii parametri de dispozitie:

a. resurse

b. tipul resursei

c. resursa cu echipament special si competenta

d. aparate cu resursa

e. tipul da caz

f. starea resursei

g. conditiile de dispozitie a resursei : fara ocupare, incarcare speciala (Exemplu:

targa, incubatorul, respectiv alte echipamente speciale cu instructiuni cu privire la pregatirea

resurselor la locul aplicatiei, de ex. carucior pentru pacient), disonibil, pauza, prioritate

h. cuvant-cheie de aplicatie/cuvant-cheie

i. serviciul de aplicatie

j. localizarea cazului

k. distanta fata de localizarea cazului

l. durata drumului pana la caz

153 / 234

m. angajati

n. plan de serviciu

o. domeniu/zona

p. supraveghere/domeniu de protectie/domeniu de aplicatie

q. alegerea libera, manuala

r. locatia actuala a resursei

s. inlocuirea cu resurse de rezerva

t. prima statie raspunzatoare/ajutatoare inainte de locatie-functii

u. statutul numeric al resurselor RSS / SDS (una sau mai multe cifre):

Exemplu: RSS-Status / SDS Status

apel de urgenta 0 multi-digit

pregatit – accesibil prin radio 1

pregatit pentru supraveghere 2

pe drum catre locatia de aplicatie 3

se gaseste la locatia de aplicatie 4

cerere de discutie 5

nu este pregatit 6

pe drum catre spital 7*

receptie in mana/transmisie externa 9*

*este definit in mod specific in BEMIS.

v. informatii de completare la parametrii de dispozitie:

w. resursei nu ii este alocat niciun caz

x. resursa este propusa

y. resursa este semnalizata

z. resursa este semnalizata, dar totusi nu este transmisa intr-un time-out din status

RSS 3 sau asemanator in SDS

6.10.3 Transmisia vocala

FN.89 Pentru sprijinul dispozitiei toate resursele primesc un fisier WAVE. In fisierul

WAVE denumirea resurselor este pozitionata vocal si alocata.

6.11 Managementul resurselor

FN.90 Criteriile de cautare pentru resurse trebuie sa fie cel putin: distanta resurselor

fata de locul cazului, statutul resurselor, procesul resurselor si cifrele aplicatiei.

FN.91 Acesti parametrii trebuie sa fie ajustabili individual in functie de prioritatea

lor.

154 / 234

6.11.1 Completari la resurse

FN.92 Tipurile de resurse trebuie sa poata fi impartite in grupe si subgrupe.

6.11.2 Cautarea de resurse

FN.93 Rezultatele cautarii de resurse pentru interventie trebuie sa fie ajustabile in

functie de evenimente, de raporturile de situatie ale mesajelor, de tipurile de resurse, de

situatiile de dispozitie, de tacticile de cautare si de substituire.

FN.94 Daca o resursa este propusa pentru un caz in progres si preluata, automat se

realizeaza o dealocatre de la cazul existenta cu documentatia corespunzatoare, automata si cu

notificarea disponentilor.

FN.95 Domeniile de cautare trebuie sa fie prezentate la vedere. Pe langa alocarea

automata exista posibilitatea sa se realizeze o alocare manuala. Alocarea manuala se

realizeaza prin setarea informatiilor de statut la fiecare resursa.

FN.96 Alocarile manuale pot fi realizate si pentru resurse alocate la cazuri in progres

pentru a retrage resursele dintr-un caz existent si pentru a le prelua intr-unul nou.

6.11.3 Tactica de management a resurselor

FN.97 In strategia de alocare a resurselor trebuie sa existe posibilitatea sa se utilizeze

diferiti parametrii de calcul, de exemplu calculul dupa un timp optim, calculul dupa un timp

maxim, predeterminat. Selectia parametrilor de calcul trebuie sa fie liber ajustabila.

FN.98 Dispecerul trebuie sa aleaga prin informatii grafice resurse apropiate,

corespunzatoare, acestea putand fi asociate. In completare sistemul trebuie sa introduca

resursele in GIS si in transferurile de date GPS cuplate.

FN.99 Datele transferate GPS trebuie sa fie valorificate in cadrul strategiei de

urmarire a resurselor. Autovehiculele in discutie sunt indicate in lista de dispozitie si grafic

pe harta.

6.12 Activitatile dispecerului

FN.100 Activitatile dispecerilor se realizeaza prin aplicarea parametrilor de dispozitie

si a cerintelor de principiu din dispozitie si sunt listate dupa cum urmeaza:

a. preluarea de cazuri din prezentarea grafica (GIS)

b. preluarea din tabelul de autovehicule, respectiv resurse

c. preluarea resureslor de la un caz in progres

d. rezervarea in prealabil a unei resurse

e. rezervarea unei resurse-aplicatia de resurse, de exemplu camioane cu diferite

sarcini si conditii

f. modificarea cuvantului-cheie de aplicatie (ridicare, micsorare)

155 / 234

g. modificarea locatiei cazului

h. anexarea cuvintelor-cheie aditionali la caz

i. anexarea de resurse, tipuri de resurse sau aparate la cuvintele-cheie de aplicatie

pentru dispozitia automata care va fi completata

j. anexarea, respectiv modificarea cuvintelor-cheie de aplicatie/a informatiei

statutului

k. modificare preliminara a parametrilor de dispoziţie prealabila

l. generarea de texte de anunturi si rapoarte si resursele care se afla in aplicatie sunt

identificate conform statutului cu informatii ale statutului si prin culori.

6.13 Fişiere de informaţii

FN.101 Pentru dispoziţie, BEMIS trebuie să ofere informaţii suplimentare, la care, în

cazul în care este necesar, agentul autorizat să poată avea acces. Informaţiile vor fi atribuite

panoului de semnalizare, Indiferent de acest lucru, accesul la măsuri, informaţii, carte telefon

electronica etc. rămân valabile şi fără dispoziţia unei intervenţii.

FN.102 Această facilitate este utilizată pentru susţinerea generală a operării, prin

utilizarea posibilităţilor multiple ale server-ului de dirijare a intervenţiilor, şi fără ca acesta să

depindă de intervenţiile pentru activităţile generale şi informaţii ale centrului de comanda. Cu

ajutorul fişierelor de informaţii şi ale bazelor de date tip text, se va înfiinţa o baza de

cunostinte, ce va oferi informaţii şi sfaturi în prelucrarea intervenţiilor, precum şi în

prelucrarea măsurilor care trebuie luate.

6.14 Finalizarea planificării

FN.103 Finalizarea planificării se face prin preluarea mijloacelor de intervenţie şi a

măsurilor în alarmare planificată.

6.15 Sprijinirea si dirijarea intervenţiilor

FN.104 Cu ajutorul sistemului de susţinere a intervenţiilor sunt supravegheate şi

prelucrate interveniile aflate în derulare. Agentul care dă dispoziţia trebuie să aibă

posibilitatea indicării intervenţiilor pe ecran. Indicarea pe ecran se va efectua cu ajutorul unui

filtru de selectare, de ex. intervenţiile pompierilor, salvării, numere de intervenţie, data

intervenţiei, ora intervenţiei, mijloace de intervenţie utilizate.

156 / 234

FN.105 Cu ajutorul listei „intervenţii alarmate în curs de desfăşurare“ fiecare agent

autorizat sa emita dispoziţii poate avea acces la intervenţii şi astfel să efectueze aici

prelucrările necesare sau să ia măsurile care sunt cerute. Toate informaţiile din apelul

telefonic sunt alocate de regulă agentului care a emis dispoziţia sau lui CMISU care dirijează

intervenţia. Locaţia principală a intervenţiilor este acel loc care preia intervenţia respectivă, o

prelucrează, salvează preluarea ei sau locaţia cu funcţia de colectare.

FN.106 Solicitări ulterioare, alarmări de completare, în cazul pregătirii mijloacelor de

intervenţie sunt solicitate de regulă de către forţele de intervenţie cu ajutorul comunicării prin

unde radio de la centrul de comandă şi control.

FN.107 Modificările permanente ale statusului mijloacelor de intervenţie care se află

pe lista de dispoziţii a intervenţiei alocate. În plus disponentul trebuie să aibă posibilitatea

modificării manuale a informaţiilor de status ale intervenţiilor care sunt în curs de derulare.

FN.108 Pentru sprijinirea intervenţiilor, disponentul utilizează de regulă

caracteristicile standard „Anunţare“, „Emitere dispoziţie “, „Alarmare“.

FN.109 Cu ajutorul interfeţei de anunţare trebuie, ca prin modificarea cuvântului cheie

de intervenţie sau prin indicarea unei căi de mijloc pentru intervenţie, să existe posibilitatea

modificării numărului (de ex. 3x maşini salvare), sau indicării unui mijloc de intervenţie sau a

modificării locaţiei de intervenţie, emiterea unor dispoziţii suplimentare pentru mijloacele de

intervenţie.

FN.110 Mijloacele de intervenţie pentru care s-a emis ulterior o dispoziţie trebuie

alarmate cu ajutorul modulului de alarmare. În plus trebuie să existe posibilitatea ca în urma

discuţiilor cu centrul de intervenţie să poată fi retrase mijloace de intervenţie dintr-o locaţie şi

punerea lor la dispoziţie pentru alte sarcini.

FN.111 Din punct de vedere al tehnicii de comunicare, centrul de intervenţie are la

dispoziţie toate mijloacele şi căile de informare. O funcţie regulată în susţinerea interventiilor

sunt informaţiile salvate în server-ul de dirijare a intervenţiilor sau din datele din surse

externe.

FN.112 În cazul în care intervenţia se extinde la o zonă mai mare, există posibilitatea

în sprjinirea intervenţiei ca centrul de intervenţie să prelucreze mai repede şi mai eficient

intervenţia cu ajutorul caracteristicilor standard prin „prelucrare paralelă“.

FN.113 Prin sistemul grafic de informare (GIS) trebuie să existe mereu posibiltatea

sprijinirii forţelor de intervenţie cu informaţii şi indicaţii extinse referitoare la situaţia de la

faţa locului.

FN.114 Toate intervenţiile aflate în curs de desfăşurare sunt reprezentate pe sistemul

grafic de informare. Printr-un „click“ agentul care emite dispoziţia are posibilitatea să

verifice intervenţiile aflate în curs de derulare şi să reprezinte mijloacele de intervenţie

utilizate.

FN.115 O importanţă deosebită o are sprijinirea intervenţiilor cu ajutorul sistemului

grafic de informare în serviciul de salvare. Agentul care emite dispoziţia trebuie să aibă

posibilitatea să observe în mod regulat mijloacele de intervenţie şi să optimizeze comenzile

care urmează.

FN.116 Toate funcţiile, informaţiile, indicaţiile şi acţiunile din susţinerea intervenţiei

vor fi înregistrare prin alocarea lor la respectivele locuri de intervenţie.

157 / 234

6.15.1 Redarea intervenţiei

FN.117 Functionalitatea „Redarea intervenţiei“ trebuie să poată fi folosită permanent

în prelucrarea intervenţiilor. Agentul care face dispoziţia are astfel posibilitatea să transmită

mai departe intervenţiile către alte locuri de intervenţie. Transmiterea intervenţiilor se va nota

într-un proces-verbal prin schimbul între „Proprietar“ şi „Utilizator“. Aceste schimburi se vor

susţine prin prelucrarea permanentă şi fără întrerupere a sistemului.

FN.118 În cazul unui schimb de „Utilizator“ sunt blocate prelucrările permanente, însă

rămân active în supraveghere. Anunţarea unui nou „Utilizator“ se va face prin setarea unei

ştampile cu ora şi cu „Utilizator“. Toate intervenţiile aflate în curs de desfăşurare şi toate

celelalte intervenţii vor fi alocate noului „Utilizator“ la staţia de operare.

6.15.2 Vedere de ansamblu asupra intervenţiilor

FN.119 Toate intervenţiile vor fi reprezentate într-o lista pentru o vedere de ansamblu

cu diferiţi parametri. Cu ajutorul unor funcţii de tip filtru care poate fi liber setat trebuie să

existe posibilitatea filtrarii si sortării listei în funcţie de servicii şi funcţii.

FN.120 Filtrele pot fi setate de exemplu în funcţie de domeniile de supraveghere, de

pază, de zone supravegheate, de domenii protejate, de tipul autovehiculului, de marca

autovehiculului, de status, de număr de intervenţie, de număr de telefon pentru apel în caz de

intervenţie, de timpii de intervenţie şi de prelucrare.

6.15.3 Încheierea intervenţiei

FN.121 Prin „Încheierea intervenţiei“ se finalizează toate acţiunile unei intervenţii,

datele preluate în intervenţie sunt transmise din BEMIS in modulul de administrare. Aici sunt

arhivate pe termen lung. „Încheierea intervenţiei“ este un modul de program prin care

intervenţiile aflate în curs de derulare sunt încheiate, respectiv sunt finalizate. Intervenţiile

pot fi încheiate dacă mijloacele de intervenţie nu mai sunt utilizate.

FN.122 Prin modificarea de status trebuie să fie posibilă finalizarea parţială sau în

totalitate a intervenţiilor pentru a putea utiliza mijloacele de intervenţie de la pază sau de la

locaţiile de intervenţii şi în alte locuri. (În mod automat sau manual)

FN.123 După încheierea intervenţiei, fişierele de intervenţie nu mai pot fi modificate.

Atâta timp cât mai există o intervenţie în altă locaţie, această intervenţie nu poate fi încheiată

de către iniţiator.

6.15.4 Încheiere

158 / 234

FN.124 O încheiere de intervenţie cu ajutorul server-ului de dirijare a intervenţiilor

poate fi efectuată dacă niciun mijloc de intervenţie nu mai este activ în această intervenţie.

Mijloacele de intervenţie îşi încheie automat operaţiunea prin succesiunea predefinită RSS,

cu ajutorul BEMIS sau manual prin agentul care emite dispoziţia.

FN.125 Încheierea intervenţiei poate fi efectuată de server-ul de dirijare a intervenţiilor

în mod automat, dacă toate mijloacele de intervenţie au parcurs o succesiune logică a

statusului. În plus există posibilitatea efectuării unei încheieri manuale după indicarea

anticipată cu ajutorul server-ului de dirijare a intervenţiilor.

FN.126 Încheierea intervenţiei deschide mai ales următoarele posibilităţi:

a. posibilitatea separării mijloacelor de intervenţie, de ex. autovehicule ale salvării,

ale pompierilor

b. sunt elaborate copii după mjloacele multiple de transport

c. indicarea unei intervenţii pentru evaluări speciale

d. redare în arhivarea BEMIS

6.16 Procese complementare şi module de program aferente BEMIS

FN.127 Urmărirea statusului pentru mijloacele de intervenţie ca bază a dispoziţiei şi

suportului pentru intervenţie cu documentaţia aferentă, cu suportul următoarelor funcţiuni:

a. urmărirea statusului cu referinţă la mijloacele de intervenţie pe bază RSS

b. introducerea manuală a statutului după statutul RSS

c. Includerea componentelor automatice de statut în protocolul de intervenţie, precum

0, 1 şi 5

d. modificarea şi retragerea atenţionărilor de statut false, tranziţiei statutului

e. refuzul tranziţiilor de status nepermise în forma configurabilă

f. indicarea informaţiilor statusului- documentarea despre informaţiille de status

g. suportul de introducere a punctelor forte pentru mijloacele de intervenţie.

6.16.1 Prelucrare paralelă a intervenţiilor/măsurilor

FN.128 Prelucrarea paralelă a intervenţiilor şi măsurilor în diferite locuri de comandă

a intervenţiilor în cadrul centrului de comandă trebuie să faciliteze posibilitatea ca locurile de

comandă ale intervenţiilor să se susţină reciproc în cazul daunelor mai mari sau în cazul unei

conglomeraţii de intervenţii şi activităţi şi să procedeze divizat pe sarcini .

FN.129 La prelucrarea paralelă se poate ca fiecare staţie de operare să apeleze la datele

unei intervenţii sau a unei măsuri şi să realizeze prelucrări. (prelucrare divizată).

FN.130 În server-ul de comandă a intervenţiilor se vor trece prelucrările paralele

realizate în protocolul de intervenţii şi documentate cu locurile de muncă participante

respectiv a agentului autorizat. Intervenţiile/măsurile şi mijloacele de intervenţie/resursele

rămân în subordinea raportării.

159 / 234

FN.131 În mod normal locul de coordonare lucrează ca şi proprietar general.

6.16.2 Planificarea anterioară intervenţiei

FN.132 Modulul „planificarea anterioară intervenţiei “ este o completare a modulului

„preluarea raportării“. Cu ajutorul modulului de program „planificarea anterioară intervenţiei

“ trebuie să fie pregătite intervenţii, măsuri şi activităţi. Planificările anterioare ale

intervenţiei servesc planificării generale a intervenţiei şi a planificării transportului.

FN.133 Planificarea anterioară trebuie să fie posibilă atât pentru intervenţii unice cât şi

pentru cele repetitive. Pe baza modulului de planificare anterioară se vor planifica mijloace

de intervenţie libere sau mijloace de intervenţie cu caracteristici deosebite. Suplimentar

trebuie să existe posibilitatea, să se poată rezerva intervenţii la anumite ore fixate sau anumite

mijloace de intervenţie şi astfel să se blocheze pentru alte intervenţii. În BEMIS se va observa

prin ce planificare anterioară s-a blocat mijlocul de intervenţie.

FN.134 În momentul planificării anterioare se va pregăti măsura pentru intervenţie. În

cazul intervenţiilor repetitive se va pune automat o nouă programare.

FN.135 Intervenţiile pot fi programate pe viitor cu o administrare automată a

programărilor.

FN.136 Intervenţiile planificate anterior trebuie să fie vizualizabile în liste generale.

FN.137 Criteriile de sortare ale indiciilor sunt următoarele:

a. mijloacele de intervenţie

b. data

c. timpul

d. locul preluării

e. destinaţia

6.16.3 Caracteristici pentru serviciul de salvare

FN.138 Serviciul de salvare respectiv serviciile de urgenta, transportul bolnavilor şi

alte domenii mai speciale ca serviciul salvării aeriene se vor trata in modulul de prelucrare

genarale în server-ul de comandă a intervenţiilor.

FN.139 Serviciul de salvare solicită server-ului central informaţii suplimentare:

a. tipul intervenţiei

b. mijlocul intervenţiei

c. tipul mijlocului de intervenţie

d. începutul intervenţiei

e. sfârşitul intervenţiei

f. suportul unei planificări de rute prin planificarea anterioară pentru transportul

bolnavului.

g. cuplarea planificării rutei cu datele grafice

160 / 234

h. caracteristici ale călătoriei ca de ex. semnal special, călătorie urgentă, călătorie

standard,pacient/victima unui accident: nume, prenume, loc,localitate, strada, număr, telefon,

vârstă,data naşterii, suportul preluării din informaţia celui care o redă despre tehnica cuplată a

comunicării.

i. ţintă: domeniu, loc, localitate, strada, secţia, pat.

j. locul preluării: domeniu, loc, localitate, strada, numarul casei, denumirea

obiectului, ex. spital/locuinţă, clădire, parte a clădiii, plan, secţie, cameră, pat

k. tipul subordonarea textelor libere transportului: dus/întors, schimb automat cu

întoarcerea transportului

l. comunicatorul cu adresă, nume, prenume, loc, localitate, strada, numărul casei,

indicaţii, număr de telefon (suportul cu adresa comunicatorului cu adresă din datele apelului

cu cuplarea pentru tehnica comunicaţiei)

m. menţiuni adiţionale pentru medic, specialist, nume, adresă-distanţă-cine suportă

cheltuielile

n. transferul datelor către sistemele de colectare a pozitiilor autovehiculelor(date de

bază pentru intervenţie, de ex. coordonatele intervenţiei, numărul intervenţiei, loc, cuvinte

cheie, pacient) prin suport GPRS de la transporturi multiple

o. suport şi realizare a transporturilor colective

p. suport şi realizare a intervenţiilor ciclice

6.16.4 Planificarea anterioară a transporturilor pentru bolnavi cu privire de ansamblu

grafică

FN.140 Pentru planificarea transportului de bolnavi, punctul esenţial în transportul sau

planificarea anterioară a intervenţiei este o reprezentare grafică ca program de planificare şi

reprezentare. În reprezentarea grafică se vor pregăti următoarele informaţii:

a. mijloace de intervenţie

b. rasterul de timp

c. rasterul de timp împărţit în minute şi ore

d. rasterul de timp împărţit în zile

e. rasterul de timp împărţit în săptămâni

f. rasterul de timp împărţit în luni

g. rasterul de timp împărţit în ani

FN.141 Grafica trebuie să ofere o privire de ansamblu asupra mijloacelor de

intervenţie planificate, referitor la acoperirea în timp.

FN.142 Valorile înregistrate se vor reprezenta în privirea de ansamblu grafică cu

subordonare la mijloacele de intervenţie existente.

FN.143 Pentru intervenţii ciclice se va reprezenta o privire de ansamblu, în ce zi a

săptămânii este planificată o intervenţie ciclică în cadrul unui interval de 12 luni.

FN.144 Intervenţiile terminate se vor şterge din privirea de ansamblu, inclusiv din

privirea de ansamblu grafică. În privirea de ansamblu mijloacele de intervenţie sunt

prezentate în funcţie de statutul actual al informaţiilor şi al disponibilităţii.

161 / 234

6.16.5 Planificarea anticipată a mijloacelor de intervenţie

FN.145 Mijloace de intervenţie vor fi planificate anticipat conform listei următoare:

a. planificarea mijloacelor de intervenţie fixe

b. planificarea şi alocarea mijloacelor de intervenţie deschise

c. alocarea mijloacelor de intervenţie în funcţie de zonă

d. asistarea planificării anticipate a mijloacelor de intervenţie conform unui grafic de

timp automat întocmit cu precizie pe o perioadă de 12 luni

e. intervenţii ciclice

f. introducerea mijloacelor de intervenţie din tabloul sinoptic grafic

g. înregistrarea informaţiilor de completare pentru mijloacele de intervenţie

6.17 Transporturi multiple / Transporturi colective

FN.146 O intervenţie în caz de urgenţă sau un transport calificat al bolnavilor la care

sunt preluate sau transportate mai multe persoane cu un mijloc de intervenţie, va fi distribuit

automat şi/sau manual cu ajutorul comenzii „Distribuire“ în mai multe intervenţii individuale

cu alocarea câte unei persoane şi/sau maşini.

FN.147 Persoanele implicate în intervenţie vor fi înregistrate într-o „Lista pacienţi“,

pentru a putea prezenta la căutarea după nume persoanele alocate respectivei intervenţii. Prin

aceasta lista se va asigura faptul că prin funcţiile de căutare pot fi căutate şi prezentate

persoanele după transport şi locurile-ţintă. Listele de nume trebuie să poată fi tipărite sau

transmise în format electronic.

6.17.1 Continuarea transportului

FN.148 Asistenţă pentru funcţia de continuare a transportului, în special în cazul

serviciul de salvare, transportul bolnavilor:

a. preluarea pacientului de la locul intervenţiei

b. transport la punctul-ţintă 1

c. preluare de la punctul-ţintă 1 - Continuarea transportului la punctul-ţintă 2 cu

asistenţa ulterioară a transportului de retur

FN.149 În modul continuarea transportului trebuie să existe şi posibilitatea de a asista

continuarea transportului ca transport multiplu / colectiv, şi anume:

a. preluarea pacientului de la locul preluării

b. transport la punctul-ţintă 1

c. preluarea unui al doilea pacient de la punctul-ţintă 1

d. continuarea transportului la punctul-ţintă 2

FN.150 Alternativ:

a. preluarea a doi pacienţi de la locul preluării

162 / 234

b. transportul pacientului 1 la punctul-ţintă 1

c. pacientului 2 la punctul-ţintă 2

FN.151 Încheierea intervenţiei

FN.152 Copierea datelor din intervenţii

FN.153 Când s-a încheiat o intervenţie sistemul trebuie să asiste posibilitatea ca prin

copiere să preia pentru noi intervenţii mesajele de alarmă înregistrate. Dispecerul trebuie să

aibă posibilitatea de a completa respectiv de a modifica datele copiate cu noile date de

intervenţie şi să gestioneze această nouă intervenţie printr-o dispecerizare independentă.

FN.154 Căutarea spitalelor adecvate trebuie să fie posibilă simultan după mai multe

departamente specializate (de ex. medicină internă, secţie bărbaţi şi terapie intensivă)

6.18 Situaţii speciale

FN.155 În cazul situaţiilor speciale procesele operaţiunii trebuie asistate prin procese

suplimentare ale server-ului central pentru intervenţii. Aceste procese trebuie corelate cu

procesele şi modulele de program ale operaţiunii (înregistrarea semnalizării, dispecerare,

alarmare, asistenţă intervenţie şi încheierea intervenţiei), precum şi cu celelalte module de

program suplimentare.

FN.156 În cadrul centrului de comandă şi control trebuie constituite grupe de posturi

din centrele de intervenţii configurabile dinamic pentru asistarea în situaţii speciale. Rezultă

într-o anumită măsură cerinţa de a lucra în paralel la posturile din centrele de intervenţii.

FN.157 În cazul situaţiilor speciale trebuie constituite domenii de intervenţie în

legătură cu evenimentul respectiv cu mijloacele de intervenţie alocate. Crearea domeniilor de

intervenţie în legătură cu evenimentul respectiv trebuie asistata cu ajutorul sistemului GIS.

FN.158 Derularea ulterioară în cadrul domeniilor de intervenţie în legătură cu

evenimentul respectiv se efectuează independent cu ajutorul bazei de date a mijloacelor de

intervenţie alocate.

FN.159 O situaţie excepţională va fi activată prin marcarea unui check box.

FN.160 Intervenţia rapidă

FN.161 Intervenţii de mari proporţii

a. Extinderea intervenţiei cu ajutorul unui tablou de situaţie al vehiculelor pentru

alocarea mijloacelor de intervenţie / resurselor în secţiunile de intervenţie. Constituirea şi

modificarea unui astfel de tablou pe baza planurilor de intervenţie pregătite sau adaptarea la

condiţiile speciale ale unei intervenţii de mari proporţii cu reproducerea structurii

organizaţionale la faţa locului cu prezentare în următoarele grupe, şi anume:

toate mijloacele de intervenţie pentru o intervenţie după alarmare

mijloacele de intervenţie într-un spaţiu alocat

mijloacele de intervenţie într-un loc special

mijloacele de intervenţie la secţiunea de intervenţie 1, de ex. acces 1 metrou

mijloace de intervenţie la secţiunea de intervenţie 2, de ex. ieşire metrou

autovehicule externe în scop de sprijin

163 / 234

b. O dată cu lansarea intervenţiei mijloacele de intervenţie vor fi prezentate în functie

de clasificarea lor.

FN.162 Transferul înregistrărilor de date pentru decontarea intervenţiilor serviciului de

pompieri şi de salvare, procesarea intervenţiei şi procesarea statistică

a. O dată cu transferul datelor intervenţiei către software-ul administrativ trebuie

transmise datele de bază înregistrate, care pot fi utilizate între altele pentru înregistrarea

raportului de intervenţie, decontare, procesarea intervenţiei şi statistică.

b. Toate datele înregistrate trebuie copiate din server-ul central pentru intervenţii sub

formă de înregistrare de date în software-ul administrativ.

FN.163 Transferul înregistrărilor de date către poliţie sau alte centre de intervenţie

FN.164 În cadrul unei posibile colaborări între centrul de intervenţii, poliţie sau alte

centre de intervenţii conectate pot fi transferate cuvintele-cheie de intervenţie definite sau, în

anumite cazuri şi în baza unui acord, datele înregistrate despre locaţie şi informaţii despre

obiectiv. Transferul se efectuează de la server-ul central pentru intervenţii printr-o conexiune

de date către centrul de intervenţie.

FN.165 Datele de intervenţie din mesajul de alarmă:

a. Locaţia evenimentului (localitate, stradă, număr respectiv kilometrul)

b. Tipul evenimentului sub formă de cuvânt-cheie de intervenţie şi cuvânt-cheie

suplimentar resp. cuvânt-diagnostic

c. Data evenimentului

d. Informaţii despre apelant

e. Texte înregistrate liber

f. Date din sistemul de coordonate geografice GIS

FN.166 Informaţii despre obiectiv:

Transferul de informaţii despre obiectiv pentru obiectivele înregistrate, selectate cu

indicaţii despre obiectiv

Transferul de informaţii individuale înregistrate sub formă de texte, grafice, imagini.

FN.167 Datele de bază utilizate la import / export:

a. Datele despre locaţie:

b. Localitate

c. Cartier

d. Stradă

e. Număr obiectiv

f. Denumire

g. Localitate

h. Număr

i. Apelant

j. Numele

k. Prenumele

l. Text liber

m. Informaţii despre intervenţie

n. Tipul intervenţiei

164 / 234

6.19 Baza de date despre personal

FN.168 Modulul „Baza de date despre personal“ este un instrument suplimentar pentru

dispecerizare. Structurarea, configurarea şi administrarea unei baze de date despre personal

trebuie asistate prin server-ul central pentru intervenţii. Modulul „Baza de date despre

personal“ serveşte conectării între mijloacele de intervenţie alocate şi/sau libere, de regulă

sub forma autovehiculelor de intervenţie şi personalul de intervenţie pentru pompieri şi

serviciul de salvare. La alegere conectarea se poate efectua între autovehiculele de intervenţie

şi personalul de intervenţie sau între personalul de intervenţie şi autovehiculele de intervenţie.

FN.169 Baza de date despre personal va fi gestionată manual. Perioada va cuprinde

minimum şase săptămâni calendaristice plus completări. Sistemul trebuie structurat în mod

extensibil pentru conectarea cu planul de serviciu prin intermediul unei interfeţe

corespunzătoare. În cadrul administrării bazei de date trebuie înregistrată fiecare persoană în

parte cu funcţia ei.

FN.170 Operatiile modulului „Baza de date despre personal“:

a. Descrierea problemei

Deoarece în staţiile de pompieri există mai multe maşini decât pot fi manevrate

personal, este neapărat necesar ca în caz de alarmă să fie luat în considerare personalul aflat

de gardă.

b. Stabilirea efectivului de maşini se efectuează prin planificarea intervenţiei,

furnizarea informaţiilor în server-ul central pentru intervenţii prin administratorul de sistem.

FN.171 Situaţia reală a bazei de date trebuie afişată actualizat pe ecranul de comandă

al intervenţiei.

FN.172 În cazul modificării efectivelor staţiei de intervenţie în server-ul central pentru

intervenţii de către un dispecer trebuie efectuată în mod automat înregistrarea în jurnalul de

supraveghere (ora şi utilizatorul).

FN.173 Crearea bazei de date depinde în principal de autovehicule şi va fi efectuată în

două etape: efectivul standard şi efectivul minim.

FN.174 În principiu toate vehiculele vor fi înregistrate cu efectivele standard indicate.

În cazul în care vehiculul nu poate fi ocupat de efectivul standard, atunci acest lucru trebuie

să îi fie indicat dispecerului. Deoarece sunt posibile şi efective de personal între efectivul

standard şi efectivul minim, este necesară afişarea efectivului real de ocupare a vehiculului.

FN.175 În cazul în care dintr-o staţie de pompieri sunt mobilizate mai multe maşini şi

nu s-au putut respecta efectivele standard, atunci efectivele vehiculelor pot fi reduse cel mult

până la efectivul minim, pentru a putea fi mobilizate pe cât posibil toate vehiculele aflate în

stare de alarmă de la respectiva staţie de pompieri.

6.20 Înregistrarea ulterioară a intervenţiei

165 / 234

FN.176 Operatia „Înregistrarea ulterioară a intervenţiei“ este necesară în cazul în care

server-ul central pentru intervenţii are defecţiuni din cauza lucrărilor de service sau avariilor

şi astfel nu mai este disponibil pentru operaţiunile curente şi procesarea curentă. Prin operatia

„Înregistrarea ulterioară a intervenţiei“ pot fi derulate măsurile adecvate şi înregistrările după

repornirea server-ului central pentru intervenţii.

FN.177 Următoarele lucrări trebuie să asiste modului de programe:

a. Modificarea priorităţii în cadrul intervenţiei.

b. Preluarea funcţionalităţii generale. Datele intervenţiei înregistrate ulterior sunt

datele de referinţă ale sistemului general şi sunt utile pentru prelucrarea ulterioară şi pentru

căutarea fără restricţii.

6.21 Jurnal de activitate BEMIS

FN.178 In server-ul central de intervenţie se va ţine un jurnal de activitate. In acesta se

inregistrează toate modificarile din sistem cu marcarea timpului. Informaţiile se vor ordona

cu statiile de lucru şi cu utilizatorii înregistraţi.

FN.179 Jurnalul de activiate se va completa după un format structurat unitar.

FN.180 Acesta va fi disponibil in format printabil pentru o afişare pe ecran şi pentru o

printare pe o imprimantă.

6.22 Protocolul de intervenţie al computerului central de intervenţie

FN.181 In protocolul de intervenţie se înregistrează structurat toate acţiunile legate de

intervenţie. Toate acţiunile se vor înregistra sortate temporal, cu marcare temporală. In

această formă structurată se vor realiza de ex. următoarele înregistrări:

FN.182 - acţiuni şi măsuri pentru declanşarea intervenţiei, utilizatori înregistraţi,

eliminaţi, inregistrări telefonice ale utilizatorilor, prelucrări in paralel, predări de intervenţie,

înregistrări manuale legături deviate, legături nerealizate, înregistrări ale statusului, informaţii

despre locurile de intervenţie etc.

FN.183 - date de înregistrare cu documentarea completărilor ulterioare şi a

modificărilor protocolului RSS, măsuri realizate - protocoale care se doresc a fi verbalizate -

depăşiri temporare, indicare manuală cu corpuri de text. Protocolul de intervenţie trebuie să

reprezinte o prezentare curentă a intervenţiilor ordonate. Protocolul de intervenţie se va printa

sau se va afişa pe ecran.

6.23 Aplicaţii / aplicaţii de sistem suporturi/ gestionarea datelor

FN.184 Pentru asistenţă în operarea centrului de comandă se vor instala următoarele

aplicaţii:

a. Comanda de alarmare şi decuplare

b. Catalog de măsuri

166 / 234

c. GIS

d. Administrarea mijloacelor de intervenţie cu recunoaşterea statusului

e. Date de informare

f. Informaţii legate de baza de date

g. Rapoarte

h. Informaţii despre printare

i. Texte de prezentare

j. Planificarea rutei

k. Prezentarea generală a ştirilor

l. Training si simulare

m. Documentare

n. Sistem de informare asupra poziţiilor centrale

o. Tablou al mijloacelor de intervenţie

p. Sisteme de înregistrare / Management

q. Suprafeţe, ecrane

FN.185 Pentru administrarea datelor se vor întocmi module separate cu drepturi de

autorizare a accesului pentru fiecare în parte conform următoarelor domenii:

a. Administrarea datelor de bază

b. Date locative

c. Paza

d. Poziţii de lucru

e. Alarmare

f. Urmările alarmei

g. Responsabilităţi (adrese, etc.)

h. Calea de legătură

i. Plecări

j. Disponibilităţi

k. Informaţii legate de text

l. Date legate de Comanda de alarmare şi decuplare

m. Suport de studiu pentru chestiuni legate de baza de date

n. Administrarea drepturilor şi utilizatorilor

FN.186 Suport de configurare:

a. Configurarea şi parametrizarea sistemului pentru instalare proprie in domenii

indicate

b. Activarea şi dezactivarea funcţiilor şi desemnărilor pe taste a funcţiilor

c. Ordonarea şi activarea funcţiilor de meniu

d. Sisteme demo şi de test

e. Setari generale

f. Setari la nivel de utilizator

167 / 234

6.24 Comanda de alarmare şi decuplare

FN.187 Reprezintă premisa obligatorie pentru dispunerea automată în server-ul

central.

FN.188 Comanda de alarmare şi decuplare trebuie să se intemeieze pe baze unitare

pentru poziţia centrală şi să se execute cu specific local şi de intervenţie.

FN.189 Comanda de alarmare şi decuplare se execută in cadrul planificării alarmei.

Trebuie să existe posibilitatea de a suporta planificarea alarmei cu împărţirea pe grupe a

mijloacelor de intervenţie, posibilitatea pentru repartizarea în subintervenţii care aparţin unei

intervenţii comune.

Exemplu: Din acest cuvânt cheie („metrou”) se obţin posibil trei subintervenţii:

Subinterenţia 1: pentru atac direct

Subinterenţia 2: pentru atac într-o staţie de metrou vecină

Subinterenţia 3: pentru intervenţie într-un spaţiu de pregătire

6.25 Cataloage de măsuri

FN.190 In cataloagele de măsuri se stipulează alarmări, informaţii şi activităti necesare

pentru derularea intervenţiei ca modul separat. Cataloagele de măsuri se includ în modulele

de program „dispoziţie“ şi „alarmare“.

FN.191 In cataloagele de măsuri se definesc măsuri care trebuie aplicate în caz de

interveţie. Pentru măsuri care sunt executabile printr-o interfaţă de date sistemul trebuie să le

pună pe acestea la dispoziţie. La intocmirea cataloagelor de măsuri sistemul trebuie să se

bazeze pe matricele de măsuri si pe măsurile de intrevenţie definite în baza de date.

FN.192 Formarea unui calup de măsuri unice dintr-un catalog:

a. separarea măsurilor în obligatorii, automate, manuale, opţionale şi ciclice

b. supravegherea temporară a măsurilor unice cu supravegherea intervalului pentru

măsuri ciclice

c. descrierea măsurilor

d. prelucrarea in paralel a măsurilor către posturi centrale de intervenţie diferite

e. documentarea măsurilor executate

f. indicarea măsurilor luate

g. suport de comunicare direct din catalogul de măsuri (telefon, expedierea daterlor,

SMS, E-Mail, Fax, depeşă printată)

h. alarmare directă din catalogul de măsuri.

6.25.1 Catalog de măsuri centrat pe intervenţie

168 / 234

FN.193 Odată cu prezentarea propunerii de dispoziţie pentru dispeceri trebuie să se

poată prezenta un catalog de măsuri centrat pe intervenţie care să vină in completare în

câmpul de dispunere. Prin confirmarea rândurilor de dispunere se pregăteşte catalogul de

măsuri la care dispecerul are acces.

FN.194 Utilizarea unui catalog de măsuri centrat pe intervenţie presupune ca

intervenţia aferentă să fie apelată la server-ul central de intervenţie. După deschiderea

catalogului de măsuri pentru aplicare trebuie să existe o listă cu descrierea pe scurt a tuturor

măsurilor aferente. Prin „marcarea“ unei etape de utilizare a descrierii scurte trebuie

evidenţiată descrierea lungă a măsurii unice aferente.

FN.195 In catalogul de măsuri respectiv în lista de măsuri prezentată se vor pune

linkuri la texte de referinţă. Toate măsurile se vor supraveghea temporal. Dacă se depăşesc

timpii stabiliti se produce o semnalizare acustica/ optică către locul/ locurile de intervenţie

centrale cu repetarea în timpii setaţi. Măsurile executate se vor contabiliza. Măsurile

neexecutate (Exemplu.: dacă un participant nu poate fi găsit telefonic) se vor marca.

FN.196 Toate măsurile şi acţiunile se preiau cu o marcare temporală in protocolul

computerului central de intervenţie. Modoificări sau abateri de la măsurile propruse se

justifică intr-o cutie de verificare. Justificarea se va face cel târziu până la inchiderea

intervenţiei.

FN.197 Catalogul de măsuri trebuie legat de prelucrarea intervenţiei. Masurile centrate

pe intervenţie trebuie disociate intre măsuri obligatorii şi măsuri posibile. Nu este posibilă

incheierea intervenţiei dacă nu sunt prelucrate toate măsurile obligatorii şi nu sunt marcate

corespunzător.

FN.198 In momentul prelucrării unei măsuri se va deschide un câmp pentru

răspunsuri. Măsurile incheiate se vor lua din catalog şi se vor trece in plan secund şi/ sau ca

rezolvate. In forma unei liste de rezolvări de ex. pentru a fi „bifate“.

FN.199 Server-ul central de intervenţie trebuie să ofere posibilitatea de a activa măsuri

prin repetare manuală dacă restabilirea automată a legăturii nu s-a făcut cu succes. Măsuri

repetate se vor menţiona în catalog respectiv in lista de măsuri.

6.25.2 Indici de performanţă rezumativi ai catalogului de măsuri

FN.200 In catalogul de măsuri se delimitează intre măsuri obligatorii opţionale şi

tipice. Formarea de cataloage de măsuri dintr-un pachet de măsuri unice

a. posibilitatea justificării pentru măsurile respinse

b. indicaţia automată a măsurilor executate defectuos la incheierea unei intervenţii.

6.26 Date de informare

169 / 234

FN.201 In sistem se pun la dispoziţie date de informare suplimentare pentru informaţii.

Datele de informare sunt informaţii posibile şi nu trebuie gestionate de către

utilizator.

FN.202 Datele de informare se inregistrează in serverul central de aplicatie ca texte

independente precum şi ca informaţii legate de obiecte şi de date. Dacă obiectele se

subordonează informaţiilor atunci la selectarea unui obiect pe ecran se afişează o informaţie

care este in spatele obiectului. In cazul informaţiilor importante aceste se afişează obligatoriu.

Există posibilitatea de a marca informaţiile ca find importante (de ex. informaţii legate de

obiecte).

FN.203 Completarea informaţiilor cu acces la datele externe prin web – client integrat

la locul central de intervenţie, prezentarea datelor, preluarea în serverul central de aplicatie,

aplicarea având in vedere solicitările de siguranţă IT

FN.204 Integrarea datelor de informare in special a datelor cu privire la substanţelor

periculoase in sistemul de informare grafic.

FN.205 Prezentare rezumativă a datelor de informare:

a. In administrarea mijloacelor de intervenţie se face un tablou general la capitolul

„intervenţii nerezolvate“ cu privire la intervenţiile care aşteaptă mijloace de intervenţie liberă

după tip sau fel (Exemplu: mijloace de intervenţie rezervate).

b. Intervenţiile se sortează după priorităţi şi se afişează pentru prelucrare. In a doua

parte a tabloului cu privire la intervenţii se indică intervenţiile in curs in care este implicat un

mijloc de intervenţie potrivit sau adecvat care se află în apropierea locului în care trebuie

realizată intervenţia nefinalizata.

c. Administrarea mijloacelor de intervenţie pune la dispoziţie utilizatorului un

instrument pentru a putea gestiona in mod adecvat la avizarea unui mijloc în situaţiile in care

la dispoziţie se află mai puţine mijloace de intervenţie sau resurse.

6.27 Prezentarea generală a mijloacelor de intervenţie

FN.206 Prezentarea generală a mjloacelor de intervenţie facilitează o imagine de

ansamblu durabilă, actuală, rapidă cu privire la cele mai importante date şi situaţii a

mijloacelor de intervenţie existente cu următoarele informaţii:

a. status alfanumeric cu data şi ora inregistrării statusului

b. gradul de procesare

c. alarmarea

d. instrucţiuni/ comenzi

e. particularităţi

f. mijloace de intervenţie de schimb existente / mijloace de intervenţie pentru (indice

ca mijloace de intervenţie de schimb )

g. indice dacă pentru un mijloc de intervenţie există un mijloc de intervenţie de

schimb

FN.207 Ordonarea mijloacelor de intervenţie la fiecare din domeniile de schimb şi

supraveghere trebuie să se facă dinamic.

170 / 234

FN.208 Prezentarea datelor generale se face cu ordonarea facila a locurilor centrale de

intervenţie. Interfeţele şi tabelele se pregătesc grafic şi se prezintă după organizarea fiecărui

domeniu al postului central. Mijloacele de intervenţie trebuie să poată fi preluate intr-o

prezentare grafică. Tabelele se vor ordona după servicii de intervenţie, grupe, obiecte,

domenii de supraveghere şi protecţie.

FN.209 Pentru prezentarea mijloacelor de intervenţie după criterii diferite şi liber

instabile de ex. tipul mijlocului de intervenţie, modul mijlocului de intervenţie şi statusul

mijlocului de intervenţie se poate crea o posibilitate de flitru.

FN.210 O preluare, respectiv o dispunere a mijlocului de intervenţie, se va extrage din

prezentarea generală printr-o funcţie de alocare.

FN.211 Mijloacele de intervenţie de schimb se vor desemna ca atare de ex. adăugarea

de litere şi prezentarea asistenţei la tehnoredactare sau la apăsarea mouse-ului.

6.28 Disponibilitatea mijloacelor de intervenţie

FN.212 Disponibilitatea mijloacelor de intervenţie ofera posibilitatea de a desemna

mijloace de intervenţie ca fiind inlocuibile sau nu la anumite intervale şi de a le

prezenta statusul in tabloul general.

FN.213 Caracteristici de performanţă:

a. Diferite intervale de timp in care un mijloc se află disponibil sau nu este disponibil.

b. Zile libere

c. Preluarea unei informaţii de status (ex. pauză)

d. Dispunerea mijlocului de intervenţie intr-o altă prioritate

e. Integrarea in măsurile propuse cu prioritate corespunzătoare

f. Aplicarea în domeniul de protecţie şi supraveghere a mijloacelor de intervenţie

6.29 Administrarea lipsei mijloacelor de intervenţie

FN.214 Există o lipsă a mijloacelor de intervenţie dacă:

a. dacă este indisponibil ultimul sau penultimul mijloc de intervenţie

b. personalul de intervenţie nu mai este disponibil pentru alte intervenţii

c. mijlocul de intervenţie desemnat sau un mijloc de intervenţie furnizat nu mai este

disponibil

d. resursele nu mai sunt disponibile

FN.215 La apariţia indisponibilitatii mijlocului de intervenţie se va indica automat

serverului central de aplicatie.

FN.216 Administrarea mijlocului de intervenţie se va relationa cu administrarea

personalului.

171 / 234

FN.217 Se va asigura preluarea intr-o alocare prestabilita pentru activarea unei

intervenţii sau a unei alocari/ alarmări ulterioare a unui mijloc de schimb către un mijloc de

intervenţie aflat in funcţiune.

6.30 Returnarea mijlocului de intervenţie

FN.218 Dacă exista un incident pentru care nu există un mijloc de intervenţie sau o

resursă, atunci se va administra de către serverul central de aplicatie ca o intervenţie

nerezolvată. Procesul se va integra in supravegherea temporală. Dupa trecerea

timpilor setaţi, computerul central va emite mesaje in cazul depasirii unor parametri.

FN.219 Este vorba despre următorii parametrii:

a. Cel târziu după un timp stabilit de operator

b. Dacă se eliberează un mijloc de intervenţie definit sau o resursă pentru o

intervenţie

c. Dacă pentru un mijloc de intervenţie există personal la dispoziţie

6.31 Tabloul mijloacelor de intervenţie / Prezentare generală a statusului

FN.220 Tabloul mijloacelor de intervenţie este o reprezentare grafică a mijloacelor de

intervenţie pentru afişarea mjloacelor de intervenţie şi a repartizărilor care sunt

gestionate de serverul central de aplicatie. In tabloul mijloacelor de intervenţie

acestea sunt prezentate in functie de status, disponibilităţi şi repartizări locale.

FN.221 Rezervări, resurse umane, actualizare automată permanentă a mijloacelor de

intervenţie după status şi disponibilitate, echivalarea automată cu poziţia centrală de urgenţă,

afişarea anunţurilor externe, afişarea pauzelor, suportul de alarme al mijloacelor de

intervenţie alocate.

FN.222 Mijloacele de intervenţie sunt un sinonim al aparatelor si măsurilor predilecte,

supravegherii si personalului necesar pentru intervenţie care susţin intervenţia.

FN.223 Mijloacele de intervenţie sunt desemnate in tabloul mijloacelor de intervenţie.

Se vor face următoarele indicaţii:

a. mijloace de intervenţie prin radio

b. denumirea mijloacelor de intervenţie prin comutarea anunţului printr-un comutator

de radio

c. radioemisie cu informaţie Tool pentru fiecare formă de prezentare

d. status RSS-SDS

e. domenii de supraveghere/ protecţie/ obiecte/ clădiri

f. particularităţi

g. desemnarea mijloacelor de schimb a celor de intervenţie

h. număr nelimitat de tablouri configurabile

i. dispunerea liberă a mijloacelor de intervenţie in diverse rubrici, coloane, rânduri în

mărimi variabile

172 / 234

j. instalarea de filtre şi opţiuni de afişaj pentru afişarea la intervenţii actuale şi

supraveghere după mijloacele de intervenţie, tipurile de mijloace de intervenţie etc.

k. prezentare cromatică conform informaţiei despre status in configurare liberă

l. mărimi de scriere setabile

m. alegere liberă a informaţiilor prezentate in etalarea grafică

n. actualizarea la timp a fiecărei modificări după status

o. căutarea mijloacelor de intervenţie după status

p. afişarea mijloacelor de intervenţie alocate la solicitarea verbală

q. afişarea rezervărilor mijloacelor de intervenţie

r. afişarea şi salvarea ultimelor indicaţii RSS

s. desemnarea de mijloace de intervenţie la evacuari

t. apelarea intervenţiei prin desemnare şi controlare (ex. dublu click)

u. dispunerea mijloacelor de intervenţie prin transpunerea directă in intervenţii

v. alarmare independentă de intervenţie cu predarea textului/ text scurt RSS /

informatie de date

w. indicaţii RSS

x. transmitere de text scurt RSS

y. modificarea statusului actual

z. suport de informaţie scurtă cu privire la mijloacele de intervenţie

aa. timp de lucru al mijloacelor de intervenţie la dispunere

bb. dispunerea unui mijloc de intervenţie după planul de lucru

cc. suportul securitatii cu preluarea alarmării legate de mijloacele de intervenţie sau a

celei legate de securitate/ de locurile de operare

dd. suportul unei actualizări a mijloacelor de intervenţie

ee. urmările mijloacelor de intervenţie centrate pe supraveghere

ff. desemnarea mijloacelor de intervenţie

gg. suportul protocolului RSS

FN.224 Mijloacele de intervenţie sunt domenii, locuri, supravegheri sau obiecte ale

subdiviziunilor organizatorice. Informaţiile despre status se vor instala la cuplarea la sistemul

de radioemisie pentru transmiterea automată a informaţiei.

FN.225 Pe lângă informaţiile automate de status, sistemul trebuie să sprijine şi

informaţia scurtă tactică conform TR BOS. Suplimentar la aceste informaţii se vor desemna

mijloacele de intervenţie cu reprezentări cromatice diferite in funcţie de informaţia despre

status şi de disponibilitate in lista generală.

6.32 Formate de prezentare ale tabloului mijloacelor de intervenţie

FN.226 Tabloul mijloacelor de intervenţie se va prezenta in forme si formate diferite.

FN.227 In particular există următoarele cerinţe pentru prezentare:

a. Impărţirea tabloului în format tabelar sau grafic

b. Afisarea de straturi statice

c. Se vor afişa în special:

173 / 234

- mijloace de intervenţie / resurse – disponibile, indisponibile, in curs de intervenţie

inclusiv, alocarea lor pe compartimente de intervenţie

- mijloace de intervenţie cu personalul asociat

- tipuri de mijloace de intervenţie, tipuri de organizare.

6.33 Sistem grafic

FN.228 Sistemul informativ grafic (GIS) este un instrument de ajutor pentru

prelucrarea intervenţiei cu centrul de comandă şi control. Datele locative furnizate sunt

furnizate intr-o bază de date in computerul central cu o cuplare referentiată geografic la datele

grafice.

FN.229 Sunt acceptate ca suport planuri grafice orientate pe vectori si pixeli. In

sistemul grafic GIS se face o prezentare dinamică a locurilor, obiectelor, intervenţiilor

desemnate, etc.

Exemplu: cu GIS sunt suportate prezentări vizuale de intervenţie şi depozitare:

- analizarea străzilor şi obiectelor dintr-un polygon

- măsurarea distanţei

- desemnarea suprafeţelor de avertizare

- prezentarea mesajelor de blocaj cu cuplarea datelor locative suport de calcul automat

al rutei pentru următoarea strategie

FN.230 Prin selectarea locului sunt afişate toate obiectele furnizate intr-o rază liber

instalabilă. Identificarea unui segment de stradă este ajutată si de identificarea străzilor

invecinate şi a intersecţiilor precum şi prin indicarea numerelor caselor. Suplimentar există

posibilitatea identificarii unui segment de stradă cu selectarea sistemului informaţional grafic.

6.33.1 Planuri de fundal in GIS

FN.231 Planurile de bază pentru GIS vor fi harti digitale pentru gestionarea

măsurătorilor completate prin planuri vectoriale digitalizate, puse la dispozitie de

catre beneficiar. Acestea vor fi prezentate in cel putin urmatoarele formate:

a. Hartă digitală a oraşului ca plan vectorial 1: 500

b. Plan topografic vectorial 1: 25.000

c. Plan de ansamblu vectorial 1: 50.000

d. Hărţi digitale Bucureşti (UTM)

e. Imagini digitale Bucureşti

f. secvente video georeferentiate (ex: radar meteo, simulari propagari, etc.)

FN.232 In completare sunt alte planuri suplimentare, planuri grafice axate pe obiect.

Cu privire la un sistem de selecţie trebuie ca dispecerul să aiba posibilitatea de a alege

măsuri/trepte diferite şi de a accesa informaţii suplimentare. Informaţii suplimentare stocate

se vor afişa optic in sistem.

174 / 234

FN.233 Locuri, străzi, numere de case sunt referenţiate geografic in datele puse la

dispoziţie de administrarea măsurătorilor in fisiere ASCII. Aceste date se vor folosi pentru

construcţia bazei de date locale şi sunt o parte a sistemului grafic.

FN.234 Suplimentar datelor preluate, sistemul trebuie sa ofere posibilitatea de a

integra informaţii privind ortofotografii, fotografii in sistemul grafic. Sistemul trebuie să

ofere posibilitatea de a păstra fiecare identificare independent de treptele de zoom.

FN.235 Corpurile de date ce realizeaza administrarea măsurătorilor, precum şi datele

grafice autoproduse se vor prelua prin convertorul grafic adecvat in sistemul informaţional

grafic al computerului central.

FN.236 Prin zoom sau schimbarea imaginii trebuie să existe posibilitatea de a arăta

detalii.

FN.237 In sistemul grafic trebuie să poată fi desemnate prin indicatori de tip pătrat,

dreptunghi, cerc sau date locative incluse intr-un poligon. De asemenea, trebuie să existe

posibilitatea de a da click pe obiecte georeferenţiate in harta şi de a afişa informatii

referiotoare la acestea.

FN.238 Sistemul grafic reprezintă informaţii şi aplicaţii suplimentare pentru

intervenţie:

a. planuri de mesaj

b. planuri curente

c. planuri speciale

d. reprezentarea domeniilor de vecinătate

e. imagine de ansamblu asupra imprejurimilor locului de intervenţie, intervenţilor

invecinate, mijloacelor de intervenţie care se găsesc in aplicaţie şi infomaţiei despre obiecte

f. cuplarea datelor grafice cu datele de intervenţie prin trimitere la planurile furnizate.

g. preluarea mijloacelor de intervenţie şi a informaţiilor de intervenţie din aplicaţie

prin desemnearea simbolurilor de intervenţie grafică din tabloul general cu indicarea

numărului de intervenţie si trimiterea la datele de informare.

h. prezentarea informaţiilor stocate şi a datelor despre meniu. Aranjarea automată a

funcţiilor simbol pentru desemnarea locurilor de intervenţie.

i. reprezentarea mijloacelor de intervenţie. Icoanele mijloacelor de intervenţie trebuie

să fie conform măsurii. La o apropiere ulterioară se face o repartizare in mai multe icoane

care reprezinta un grup de vehicole.

j. deschiderea unor informatii suplimentare prin click pe un caz pe harta cu

reprezentarea informaţiilor suplimentare

k. click pe obiecte, locuri, străzi, si afisarea informatiilor despre acestea

l. integrarea unui sistem GPS de afişare şi urmărire pentru mijloacele de intervenţie

cuplate

m. editarea informaţiei grafice

n. furnizarea şi afişarea rutelor străzilor blocate si informaţiilor legate de obiecte

o. completarea nivelurilor pentru reprezentarea suplimentară de ex. zone de evacuare,

zone de pericol, zone de supraveghere, zone de supraveghere depozite, situaţia unor zone

rezidentiale, situaţia canalizărilor, conductelor.

p. afişarea imaginilor video externe pentru pozitionarea pe baza de coordonate

175 / 234

q. cuplarea datelor externe cu sistemul informaţional grafic

r. suportul operatiunilor legate de baza de date grafică cu setarea de aplicatii mijloace

de intervenţie, date locative, obiecte

FN.239 Administrarea grafică se realizeaza cu poziţii de lucru computerizate cu acces

la aplicaţiile grafice prin instrumente adecvate de intreţinere.

FN.240 Funcţii automate in sistemul grafic (obligatorii):

a. Pozitionarea hărţii

b. Preluarea unui caz curent

c. Poziţionarea simbolului de intervenţie pe harta

d. La deschiderea cazului şi modificarea cuvântului cheie trebuie să fie actualizat pe

harta simbolul cazului

e. Simboluri liber definite despre editorul de simboluri in sistemul grafic.

f. Poziţionarea simbolului mijloacelor de intervenţie

g. Mijloacele de intervenţie trebuie să fie poziţionate in poziţia transmisa. Poziţia

definitivă a unui mijloc de intervenţie trebuie permanent adaptată şi actualizată la datele GPS.

FN.241 Funcţii manuale in sistemul grafic:

a. nivele de zoom predefinite

b. afisare/ascundere de layere (construcţii, terenuri, racorduri (apă gaze, curent)

canalizare, conducte linii la inălţime)

c. editarea suprafeţelor şi zonelor prin selectarea locurilor indicate in baza de date .

d. deplasarea hărţii

e. suportul unei centrări automate pe mijlocul ecranului la poziţionarea incidentelor

f. Comutare independentă afişare straturi de hartă

i. Este necesar ca hartă să fie reprezentata printr-un set de straturi

suprapuse, straturi ce vor putea fi afişate sau ascunse independent. De

asemenea ţinând cont de regulile de securitate impuse sistemul va

trebui sănu permită anumitor utilizatori vederea anumitor straturi.

ii. Trebuie ca din interfaţa să se poată comuta cu uşurinţă, printr-un click,

afişarea sau ascunderea unui strat disponibil utilizatorului curent.

iii. Altă funcţionalitate necesară este posibilitatea grupării arbitrare a unor

straturi de hartă într-un grup ales de administratorul aplicaţiei.

iv. Gruparea straturilor într-un grup facilitează comutarea afişării lor astfel

încat (de)bifarea grupului va avea ca efect (de)bifarea fiecarui element

din grup, în mod recursiv pe întreg sub-arborele.

v. Reciproc, când toate elemente (de toate nivelurile) ale unui subarbore

sunt (de)bifate (adica afişate sau ascunse de pe hartă) atunci şi rădăcina

subarborelui va fi (de)bifată.

g. Navigare între cadre

i. În timpul utilizării sistemului operatorii umani au nevoie să revină la

cadre anterioare şi / sau să navigheze la cadrele urmatoare. De aceea

sistemul informatic va reţine un istoric al cadrelor vizualizate şi va

permite navigarea bidirectionala în cadrul acestui istoric.

176 / 234

ii. Un cadru este definit de către patrulaterul de hartă pe care îl conţine.

Doua cadre centrate în acelaşi punct dar la altitudini logice diferite nu

vor fi echivalente.

h. Focalizare / defocalizare

i. Modulul de hartă va permite focalizarea sau defocalizarea fie în mod

precis, fie în mod rapid. Focalizarea sau defocalizarea precisăva fi

disponibilă cu ajutorul unor unelte dedicate, iar cea rapidă folosind

rotiţa de derulare a mouse-ului.

ii. Focalizarea precisa, de exemplu, se va face selectând unealta de

focalizare şi apoi conturând (drag-and-drop) un dreptunghi ce conţine

cadrul dorit. În urma eliberţrii butonului mouse-ului acel cadru va fi

afişat pe întreg ecranul, efectuându-se gradul de focalizare

corespunzător.

i. Deplasare hartă

i. Pentru a putea vedea zonele învecinate cu cadrul curent, sistemul

informatic va permite o deplasare facilî a hărţii folosind o unealtă

dedicată.

ii. Când unealta de deplasare este activa, o mutare (drag-and-drop) cu

mouse-ul în hartă va realiza o deplasare echivalentă.

j. Afişarea întregului cadru

i. La nivelul sistemului informatic va trebui să fie disponibila o unealta

dedicata pentru vizualizarea întregii hărţi a regiunii de care este

responsabil un operator uman.

ii. Printr-un simplu clic de mouse pe unealta se va centra regiunea şi se va

realiza focalizarea necesară vizualizării întregii regiuni administrate.

k. Afişare pe tot ecranul

i. Aplicaţia va trebui să permită un mod de lucru în care ocupa întreg

ecranul monitorului , fără bara de unelte, bara de stare sau meniuri ale

browserului, astfel încât bara de stare a sistemului de operare sau alte

regiuni ce nu ţin direct de aplicaţie să nu consume spaţiu vizual.

ii. Este necesar să existe un buton ce va fi vizibil şi în modul normal de

utilizare şi în modul “full screen” (pe întreg ecranul) ce va realiza

comutarea între aceste moduri.

l. Afişarea listei de incidente

i. Aplicaţia va permite afişarea incidentelor active (incidentul activ este

un incident confirmat ce nu a fost soluţionat inca) şi navigarea rapidă

între ele prin centrarea hărții la coordonatele incidentului.

ii. De asemenea lista va trebui să se poată sorta după oricare din coloanele

ce specifică detaliile incidentelor. Selectând un incident va avea ca

urmare şi centrarea hărţii pe incident şi focalizarea la un nivel

predefinit, optim pentru operarea acelui incident.

m. Interogare obiective

177 / 234

i. Obiectivele (cele de risc sau cele simplu-publice) vor putea fi

interogate privind numele, identificatorii sau alte atribute proprii.

n. Simularea propagării incidentelor în timp real

i. Deoarece un incident poate genera alte incidente (de exemplu în

incendiu în imediata apropiere a unei benzinarii poate duce la o

explozie a benzinariei) trebuie să se poată vizualiza pas cu pas stadiile

unei posibile propagări.

ii. Sistemul trebuie să pornească de la un incident existent / raportat şi

stabilindu-se o raza de afectare se va analiza care sunt posibilele

obiective captatoare de risc. Fiecare obiectiv captator de risc se va

adauga într-o lista pentru simularea acestei propagări.

iii. Obiectivele captatoare de risc pot fi (desi nu este obligatoriu) şi

emiţătoare de risc, riscul generabil fiind emis într-un poligon cunoscut

/ estimat.

iv. Obiectivele de pe raza incidentului initial sunt obiective afectabile de

nivel 1. Obiectivele afectabile ca urmare a declanşării unui incident

generat de un obiect de nivel 1 sunt obiective afectabile de nivel 2 şi

aşa mai departe.

v. În urma analizei posibilelor interacţiuni între obiective se va alcatui o

listă arborescentă. Din lista se vor putea selecta una sau mai multe

obiective şi pe baza acestei selecţii trebuie să se poată genera un raport

privind evacuarea zonei afectate / afectabile (raport de incident, adresă

incident, plan de evacuare cladire, și alte detalii de interes).

o. Calculul şi afişarea regiunilor de timp de deplasare

i. Sistemul informatic trebuie să permită calcularea şi afişarea duratelor

de deplasare dintr-un punct dat. Folosind o unealta specifică se va

putea specifică un loc în cadrul ariei administrate şi se vor calcula şi

afişa poligoanele centrate în acel punct pentru care în orice punct

interior se va ajunge într-o durata maximă de 5 minute, 10 minute sau

15 minute.

p. Căutare de adresă

i. Aplicaţia va permite căutarea unei adrese poştale pe baza numelui

străzii sau a unui fragment al acestuia şi, opţional, un număr de stradă.

ii. În urma căutării se va alcătui o listă de rezultate posibile, iar selecţia

unui rezultat va centra şi evidenţia pe hartă locaţia candidat.

q. Editare atribute obiective

i. Obiectivele publice pot avea atribute sub forma cheie – valoare.

Aplicaţia trebuie să permită vizualizarea şi editarea acestora în bloc.

ii. Se va putea selecta o regiune dreptunghiulară pe hartă, iar toate

obiectivele cuprinse în aria desenată vor fi selectate pentru editarea

atributelor.

iii. În finalul editarii se va putea opta pentru salvarea modificării sau

anularea ei.

178 / 234

r. Calcul drum optim

i. Aplicaţia trebuie să pună la dispoziţia utilizatorului functionalitatea de

calcul a drumului optim, în cadrul infrastructurii rutiere.

ii. Astfel specificând un punct de pornire şi un punct de sosire să

calculeze şi săafiseze ruta optimă, ce va avea durata de deplasare

minima şi va ţine cont de sensuri unice, blocaje şi alte aspecte.

s. Asociere echipaj

i. Aplicaţia va trebui să permită asocierea (asignarea) unui echipaj de

intervenţie sau mai multe la un incident. Asocierea va fi vizibilă pe

hartă printr-o linie trasată permanent între echipaj şi incident.

ii. Acţiunea de asociere va fi facila şi va implica desemnarea echipajului

şi apoi a incidentului.

iii. Un echipaj va putea fi asociat cu maxim un incident la un moment dat.

Vor putea fi asignate doar echipajele ce sunt disponibile (neasociate cu

alt incident şi care sunt apte de intervenţie – nu au defecţiuni tehnice,

probleme fizice ale persoanelor membre ale echipajului s.a.m.d.)

t. Dezasignare echipaj

i. Omolog cu acţiunea de asociere va fi acţiunea de dezasociere

(dezasignare) de echipaj de la un incident. Acţiunea va fi şi mai simplu

de realizat decât cea de asociere, fiind necesar doar să se selecteze un

echipaj ce urmează a nu mai participa la soluţionarea incidentului şi

marcarea ştergerii asignării.

ii. Această acţiune este necesară în cazul în care asignarea iniţială a fost

facută eronat, sau când echipajul trebuie alocat unui alt incident.

u. Închidere incident

i. În momentul în care un incident a fost soluţionat, aplicaţia va trebui să

permită închiderea incidentului. La închiderea incidentului, acesta nu

va mai fi afişat în lista de incidente active, pictograma asociată nu va

mai fi figurată pe hartă iar incidentul va fi arhivat.

ii. Arhivarea prin intermediul aplicaţiei are ca scop posibilitatea utilizarii

datelor incidentului în modulul de analiza, descris ulterior în acest

document.

v. Repozitionare incident

i. Sistemul informatic va trebui să permită repoziţionarea unui incident în

cazul în care operatorul uman a obţinut informaţii ulterioare, mai

precise, privind locaţia exacta a incidentului. De asemenea, o

poziţionare iniţială eronată a operatorului poate fi o situaţie alternativă

ce va necesita o repoziţionare.

FN.242 Funcţii de editare GIS

a. incărcare grafică, prelucrare, stocare, transpunere pe harta

b. reprezentare grafică a elementelor

179 / 234

c. modificarea obiectelor

eliminarea obiectelor

6.34 Managementul substanţelor periculoase

FN.243 Sistemul GIS trebuie sa afiseze reprezentarea geografica a răspândirii

substanţelor periculoase.

FN.244 Datele locative aflate intr-un traseu poligonal sau in cota standard de

răspândire.

FN.245 Integrarea in GIS - reprezentarea in forma răspândirii substanţelor periculoase

printr-un poligon corespunzător

6.35 Afişarea punctelor de blocaj /PUNCT DE plecare/planificarea rutei

FN.246 In computerul central se va crea posibilitatea de a inregistra puncte de blocaj

pentru datele locative diferenţiate pentru zone şi drumuri.

FN.247 Inregistrarea se face printr-ul tool care realizeaza inregistrarea locului care se

blochează, respectiv strada, cat si blocajul.

FN.248 Grupele mijloacelor de intervenţie se poziţionează in grupe de dispunere.

6.36 Puncte de blocaJ, PUNCT DE plecare

FN.249 Afişarea punctelor de blocaj indică toate punctele la care se blocheaza drumul

de acces pentru pompieri şi salvare sau la care se limitează considerabil accesul.

FN.250 Punctele de blocaj sunt cuprinse in intervale de timp, actualizate zilnic (de

exemplu santiere zilnice de la ora la ora, care noaptea se eliberează).

FN.251 Punctele de blocaj pot fi stabilite, înregistrate, modificate şi şterse atât de

operator cât şi de administrator. Dacă un punct de blocaj este activ, atunci se marcheaza pe

harta ca punct de blocaj atâta vreme cât blocajul este activ.

FN.252 Suplimentar se face o listă cu puncte de blocaj afisate pe ecran si se va printa.

Ocolirile, drumurile secundare, respectiv devierile se vor indica în depeşa de alarmă dacă nu

sunt indicate in sistem. In mesaj se va cuprinde o serie de obiecte, domenii, zone, locuri,

străzi şi porţiuni de străzi.

FN.253 Suplimentar sunt comunicate zilnic punctele de blocaj active centrelor de

supraveghere prin document printat.

FN.254 Serverele centrale sunt informate prin sistemul informaţional intern despre

punctele de blocaj zilnice.

FN.255 Punctele de blocaj instalate se resetează automat sau manual după trecerea

termenului setat.

180 / 234

FN.256 Informaţii legate de punctele de blocaj sunt comunicate verbal, fax sau e-mail

de autorităţile competente prin serverul central de aplicatie.

FN.257 Sistemul trebuie sa fie pregătit pentru o cuplare a bazei de date pentru a putea

prelua informaţii ale instituţiilor responsabile in baza unui sistem informaţional grafic similar.

FN.258 Administrarea punctelor de blocaj, cat şi modificarea punctelor de blocaj,

drumuri de plecare, planificarea rutelor se face prin interfaţa de întreţinere a datelor cu

aplicatii de intreţinere pe baza administrativă şi pe cea a posturilor centrale.

6.37 Planificarea rutei

FN.259 Referitor la planificarea rutei, trebuie să existe posibilitatea de a seta, planifica

şi edita rute optime de intervenţie. Mai departe, planificarea rutelor serveşte la

realizarea strategiei pentru resursele de interventie cu privire la calcul pentru

optimizarea mijloacelor de intervenţie in legătură cu „apropierea de intervenţie“.

FN.260 Bazele planificării rutei o constituie sistemul informatic grafic legat de un

sistem de navigare automat.

FN.261 Coordonatele de inceput şi de final sunt tranferate prin computerul central in

sistemul de navigare. Acesta găseşte ruta indicată ca fiind cea mai rapidă si mai scurtă.

FN.262 Rezultatul planificării rutelor este trasmis către serverul central de aplicatie.

FN.263 Opţional se pot pune în sistem planuri grafice care să fie cuplate direct cu

sistemul de navigare dacă se asigură că aceste date sunt actualizate in sistemul informaţional

grafic GIS.

FN.264 Rutele comunicate se vor afişa pe locul de intervenţie in mod grafic.

FN.265 Cerinţele pentru sistemul de routing sunt impărţite in următoarele caracteristici

de performanţă:

a. comunicarea distanţei despre ruta propriu-zisă

b. comunicarea distanţei despre ruta linia aeriană

c. comunicarea timpului de deplasare cu parametrii de viteză setabili

6.38 Sistem de simulare, testare şi training

FN.266 Pentru simulare, training şi testarea de programe şi sistem a noilor programe şi

aplicaţii sau ale celor modificate, trebuie sa existe un sistem de sine stătător cu o

bază de date pe serverul de test şi training.

FN.267 Trainingul se face cu copii corespunzătoare ale sistemului existent. Activitatea

curentă a computerului in productie nu este influenţată de sistemul de test.

FN.268 Datele de bază in sistemul de testare sunt sincronizate regulat cu baza de date

principală de pe serverul central. In cazul sistemului de training trebuie să existe posibilitatea

executării unei replici manuale a sistemului.

181 / 234

6.38.1 Training

FN.269 Sistemul de training, ca aplicaţie de sine stătătoare in computerul central, are

conform programelor furnizate următoarele funcţii:

a. deschiderea aplicaţiei

b. inregistrarea avertismentului

c. service/suport sistem de detectarea a intruziunilor şi incendiilor

d. ordonare manuală şi automată a mijloacelor de intervenţie

e. posibilitatea de modificare a ordonării

f. modificarea statusului mijloacelor de intervenţie

FN.270 Trainingul este un sistem independent. Accesul la date se face într-o bază de

date independentă echivalentă cu baza de date a computerului central de interventie.

6.38.2 Testare/simulare

FN.271 Sistemul serveşte verificării preliminare a datelor indicate, fişierelor şi

configurărilor în întreţinerea datelor, precum şi verificării software-ului nou şi

modificat (update-uri, upgrade-uri, rute) .

FN.272 Pentru verificările sistemului sunt verificate aplicaţiile cu activitate de

simulare şi training similar aplicaţiilor reale din serverul central de aplicatie. O altă editare in

acest program este preluarea şi predarea de date.

FN.273 Datele preluate trebuie să fie verificate în prealabil prin sistemul de test şi

simulare. Abia după verificarea acestora se va face preluarea in aplicaţia reală a serverului

central.

6.39 Sistemul de informaţii al centrelor de intervenţie

FN.274 Sistemul de informaţii al centrelor de intervenţie este un sistem de distribuţie a

datelor pentru informaţii (de exemplu texte, tabele, imagini) între punctele de

intervenţie ale centrului de intervenţie.

FN.275 Corespondenţa electronică (e-mail) din cadrul centrului de intervenţie va fi

derulata printr-un WEB Client.

FN.276 Informaţiile de semnalizare trebuie afişate ca informaţii despre apel în

rândurile de comunicare ale computerului central pentru intervenţii, de ex. cu informaţia

„mesaj nou“.

FN.277 Următoarele informaţii şi funcţii trebuie puse la dispoziţie:

a. autorul mesajului

b. data

182 / 234

c. ora

d. destinatarul

e. locul intervenţiei

f. obiectivul

g. staţia/domeniul de protecţie

h. locul de muncă

i. denumirea destinatarului

j. scurt mesaj /titlu

k. informaţia mesajului ca introducere de text liber

l. lista de distribuţie cu înregistrarea destinatarului

m. informaţii despre expeditor la deschiderea unui mesaj de către destinatar -

prezentarea destinatarului, care a deschis mesajul (confirmarea)

n. tipărire

o. dispozitiv reminder pentru un mesaj după un timp presetat, o singură dată sau

recurent

p. căutare de mesaje

q. alocarea unei adrese univoce de e-mail pentru centrul de intervenţie

r. asistarea unui modul de planificare cu funcţie de calendar.

6.40 Managementul senzorilor

FN.278 Managementul senzorilor trebuie să asiste prelucrarea şi administrarea

sistemelor de semnalizare ce sunt racordate la centrul de intervenţie. Sarcina

managementului senzorilor este de a administra senzorii furnizaţi cu alocarea în

funcţie de zone, obiective, ID senzor şi statut senzor.

FN.279 Fiecărui senzor trebuie să îi poată fi înregistrate informaţii suplimentare, de

ex. informaţii detaliate despre obiectiv, descrieri ale obiectivelor, planuri suplimentare ale

obiectivelor, persoanele responsabile, firme de service mandatate, etc.

6.40.1 Revizia senzorilor

FN.280 În modulul Revizia senzorilor, senzorii vor fi marcaţi ca fiind în revizie.

Furnizarea timpilor de pornire-oprire pe parcursul unei zile. Indicarea datei unei alocări

anticipate cu supravegherea orei programate.

FN.281 Înregistrarea persoanelor care semnalizează cu verificarea dreptului

respectivei persoane prin datele personale înregistrate o dată cu dreptul de semnalizare.

FN.282 Este exclusă conectarea senzorilor în cadrul unui sistem de alarmă în caz de

incendiu.

FN.283 Conectarea la computerul central pentru intervenţii se efectuează printr-un

protocol unitar.

183 / 234

FN.284 Cerinţele de deservire a sistemului pentru declanşarea senzorilor şi prelucrarea

senzorilor.

Exemplu:

- dispozitivele unei distribuţii a informaţiei pentru senzorii declanşaţi în funcţie de

- numărul senzorului

- grupă

- zonă

- obiectiv

- statut

- afişarea unui număr de semnalizări şi lista senzorilor, în cazul declanşării mai multor

senzori

6.40.2 Informaţii grafice despre senzori

FN.285 Senzorii înregistraţi trebuie conectaţi şi afişaţi la sistemul de informaţii grafice

prin intermediul obiectivelor.

6.40.3 Protocolul de transfer

FN.286 În protocolul de transfer vor fi prezentate informaţii despre senzor.

6.40.4 Protocolul despre senzor din computerul central pentru intervenţii

FN.287 În protocolul despre senzor din computerul central pentru intervenţii se vor

înregistra în ordine cronologică toate declanşările senzorilor, activităţile derulate şi

cazurile aferente:

a. data

b. ora

c. recunoaştere ID

d. statut senzor

e. alarmă

f. revizie

g. anunţ avarie

h. notificare operaţiune

i. post în cadrul centrului de intervenţie

j. utilizator

k. denumire senzor

l. obiectiv

FN.288 Funcţiile de selectare după interogarea printr-un filtru sunt:

a. toate înregistrările

b. anunţuri alarmă

184 / 234

c. alarmă manuală

d. alte alarme

e. confirmări

f. numărul intervenţiei

6.41 Căutarea intervenţiilor

FN.289 Asistarea unei căutări de intervenţie prin căutare după intervenţii curente,

planificare sau arhivate. Posibilităţi de căutare prin filtrele de sistem configurate cu

următoarele criterii de căutare:

a. tipul intervenţiei

b. cuvânt-cheie de intervenţie

c. cuvânt-cheie

d. perioada

e. numărul intervenţiei

f. mijlocul de intervenţie

g. tipul mijlocului de intervenţie

h. post de lucru

i. nume / pacient

j. locul de intervenţie cu informaţii referitoare la localitate, stradă, obiectiv

k. afişarea din rezultatul căutării

6.42 Statistica BEMIS

FN.290 Statistica BEMIS se va adapta alături de evaluarea liberă, suplimentar la datele

oficiale de statistică şi estimările pompierilor şi ale serviciului salvării, prin filtre

predefinite, care pot fi modificate (de către administrator). Formatele de statistică

vor fi transferate în layout-uri agreate. Pentru layout-uri, se vor defini şi configura

formate corespunzătoare de layout şi imprimare.

FN.291 Interogarea statisticii este asistată într-un interval de timp predefinit sau direct

pe baza utilizărilor executate. Statistica va fi emisă în perioade de timp definite de utilizator

precum statistica zilei, statistica săptămânii, statistica lunii, statistica anului sau statistica pe

mai mulţi ani.

Aplicaţia va expune trei tipuri de analize ce au ca date de intrare arhiva de incidente.

Toate cele trei tipuri de analize diferă doar în forma de prezentare grafică. Criteriile de filtrare

sunt tipul de incident şi perioada orară a zilei. Principalul scop al analizelor retrospective este

identificarea zonelor cu probleme pentru tratarea lor într-un mod optim.

Analiza tip „heatmap”

Acest tip de analiză va expune incidentele ce corespund criteriilor de filtrare, ca zone

colorate mai intens în roşu în zone cu densitate de incidenta mai mare şi mai slab colorate

unde densitatea e mai mica.

185 / 234

Analiza tematică

Se vor prezenta pe hartă regiunile (sectoarele) zonei administrate, colorate în nuanţe

de portocaliu în funcţie de numărul de incidente în acele regiuni. Zonele cu un număr mai

mare de incidente vor avea nuanţe mai inchise.

Analiza tip „cluster”

În acest tip de analiza aplicaţia va trebui să prezinte discuri de dimensiuni diferite ce

au pozitionat central numarul de incidente pe subregiune. Dimensiunea discului va fi

proporţională cu numărul de incidente din subregiune.

6.43 Cerinţe de operare

FN.292 Parametri de interogare: aici vor fi afişaţi parametri individuali ce pot fi

interogaţi, de ex. dată, oră, cifre, valori alfanumerice, liste generale de valori.

FN.293 Câmpuri obligatorii/ Câmpuri facultative: câmpurile obligatorii şi câmpurile

facultative vor fi marcate în mod clar.

FN.294 Selectare fereastră: in selectarea ferestrei se vor cuprinde diferite evaluări într-

un câmp comun de rezultate cu parametri de selecţie definiţi.

6.44 Parametri statistică

FN.295 În continuare sunt reprezentaţi cei mai importanţi parametri din BEMIS.

a. număr intervenţie

b. domeniu intervenţie

- localităţi

- cod poştal

- coordonate geografice

- coduri oficiale regionale

c. loc intervenţie/ loc de destinaţie

- stradă

- sector de stradă

- intersecţie

- domeniu de supraveghere

- loc apel

d. obiect intervenţie/ obiect ţintă

- denumire

- tip (spital, direcţie de specializare, departament, secţie)

e. organizaţii (pompieri, serviciul de salvare, diverse)

f. termene de ajutor/ intervale intervenţie

- primire apel de urgenţă

- preluare apel

- terminare convorbire

186 / 234

- moment începere misiune

- moment alarmă

g. tipul notificării

h. final notificare

i. cuvânt-cheie intervenţie

- imagine notificare

- cuvânt-cheie încheiere

- semnal special

j. telefon

k. semnalizator

l. mobil

m. informaţii status RSS

n. diverse (definire liberă)

FN.296 Parametrii la pompieri şi acordarea de ajutor

a. tipul incendiului / măsuri / daune

- daune

- cauze

b. acordarea de ajutor

- persoane în situaţii periculoase

- animale în situaţii periculoase

- accidente de muncă

- prăbuşiri

- accidente de circulaţie

- blocaje de circulaţie

c. protecţia mediului

- substanţe care pun în pericol apa

- substanţe care pun în pericol aerul

- otrăviri

- daune furtună

- daune diverse, emisiii

d. persoane

- persoane afectate

e. notificare fără intervenţie

- alarmă de diversiune

- alarmă premeditată de diversiune

- alarmă de diversiune prin semnalizator

- alarmă de diversiune prin telefon

- serviciul de informaţii

f. intervenţii speciale

- salvări speciale

- salvări la înălţime

g. mijloace intervenţie

- autovehicule

187 / 234

- persoane

- aparate

- mijloace externe

- specialişti

- diverse (liber definibil)

h. semnalizator

- semnalizator

- domenii semnalizare

- semnalizator cu informaţii status

- notificare a stării de alarmă

- semnal de avarie

- semnal revizie

FN.297 Parametrii referitori la Serviciul de salvare

a. salvare în caz de urgenţă

- caz de urgenţă

- transport multiplu

- accident de circulaţie

- accident de muncă

- alt accident

- boală

- diverse

- intervale intervenţie

- mijloc de transport

- tip de transport

- sarcină permanentă

b. transport bolnavi

- transport regulat

- transport comun

- transport cu medic însoţitor

- amplasare

- moment preluare pacient

- moment pacient la destinaţie

c. alte servicii de transport

- transport intensiv

- transport de sânge

- transport de organe

- intervenţii după numărul de mijloace de intervenţie folosite în acelaşi timp

FN.298 Înregistrările şi evaluările datelor cuprinse în BEMIS despre intervenţii şi

activităţi vor fi pregătite pentru managementul calităţii.

FN.299 Pentru statistică, se poate utiliza un instrument integrat de software cu funcţii

de export-import.

188 / 234

6.45 Raportare statistica

FN.300 Aplicatia va cuprinde un modul dedicat de statistica pe urmatoarele categorii

de resurse:

a. echipaj de interventie (pe tipuri de echipaje)

b. personal

c. echipament

d. tip interventie

e. tip risc

f. altele

6.46 Managementul calităţii

6.46.1 Cerinţe generale

FN.301 Datele înregistrate şi prelucrate vor fi reprezentate în baza de date relaţională

pentru evaluarea calităţii după adaptarea liberă a conţinutului bazei de date. Pentru

reprezentare, se vor executa funcţii de filtru şi sortări ale datelor evaluate.

FN.302 Criteriile măsurabile ale unui management al calităţii:

a. frecvenţa lansării de către apelant de apeluri de tipul „Notificare înainte de apelare”

(preluare automată)

b. frecvenţa lansării de către apelant de apeluri în timpul „Notificării înainte de

apelare”

c. timp de aşteptare apel înainte de interogare prin 112 - timp de aşteptare apel înainte

de interogare

d. frecvenţa stării de ocupare

e. timpul de reacţie la intervenţii critice

f. interogare calificată la apeluri de urgenţă prin folosirea unui algoritm

g. flux de comunicaţii intrare

h. ieşire pentru toate direcţiile

i. durata convorbirii cu totalizarea direcţiilor

j. încărcarea completă a centrului de comandă.

FN.303 Datele necesare în acest sens vor fi extrase din datele BEMIS, precum şi din

modulul de administrare cu evaluări şi statistici şi vor fi transmise către sistemul de calitate.

Prin macro-ul programului ce va fi pus la punct, datele înregistrate ale evaluărilor şi

statisticilor vor fi transmise în modulul programului „Sistem de calitate”. Acolo, datele vor fi

comparate conform indicaţiilor analizei situaţie ţintă/ situaţie curentă. Astfel, pot fi

determinate valori de performanţă.

6.46.2 Cerinţe şi date pentru un sistem de management calitate

189 / 234

FN.304 Intervenţiile înregistrate, activităţile diferitelor servicii vor fi procesate şi

reprezentate în funcţie de diverse sub-diviziuni:

a. domenii

b. obiecte

c. pompieri

d. salvare de urgenţă

e. transport bolnavi

f. politie

g. servicii speciale

h. serviciul de informaţii.

FN.305 Divizarea în funcţie de activităţi, funcţii şi rezultate, de ex.:

a. preluare notificare

b. durată preluare

c. alarme

d. durată alarmă

e. intervenţii

f. durată intervenţie

g. termene servicii de acordare de ajutor

h. volum prelucrare şi intervale prelucrare pe fiecare loc de comandă intervenţie

i. încărcare completă a sistemului.

FN.306 Date ale serviciilor prestate de pompieri pentru evaluare sunt:

a. număr de intervenţii în funcţie de tip vehicul/ mijloc de intervenţie (servicii)

b. mijloace de intervenţie utilizate

c. măsuri luate

d. aparate utilizate

e. consumabile utilizate

f. personal utilizat

g. număr unităţi

h. semnalizatoare iniţiate

i. deranjamente

j. impărţire în funcţie de dată/ termene:

i. intervale sosire

ii. interval mediu intervenţie

k. ocupare medie

l. ocupare maximă

m. ocupare minimă

n. impărţire în funcţie de tipul de intervenţie

o. împărţire în funcţie de cuvântul-cheie al intervenţiei

p. împărţire în funcţie de tipul de notificare

FN.307 Evaluări în serviciul de acordare a ajutorului sunt, de ex.:

a. intervenţii totale

b. număr de intervenţii în funcţie de tipul de vehicul

c. salvare de urgenţă ( ambulanţă, vehicul intervenţii de urgenţă)

190 / 234

d. transport bolnavi

e. diverse mijloace de intervenţie utilizate.

FN.308 Salvare în caz de urgenţă

a. timp de sosire pentru toate mijloacele de salvare

b. timp de sosire a primului medic de urgenţă

c. timp de sosire al ajutorului la faţa locului

d. staţie de răspuns

e. durată medie intervenţie în minute

f. durată medie transport

g. reprezentarea caracteristicilor

h. rată intervenţii

i. intervenţie medici de urgenţă

FN.309 Transport bolnavi

a. durată medie transport

b. distanţe medii de transport

c. raport dintre transport bolnavi şi salvare de urgenţă

d. raport dintre transporturi individuale şi transporturi multiple

6.47 Imagine de ansamblu – informaţii, canale de comunicaţie

FN.310 Pe fiecare staţie de operare se va dispune o imagine de ansamblu asupra

informaţiilor, în care vor fi redate toate notificările pentru respectivul loc. Acestea

vor fi informaţii care vizează desfăşurarea regulamentară a unei intervenţii, dar şi

informaţii de pe alte staţii de operare şi informaţii ale sistemului.

FN.311 Informaţiile care sosesc vor fi însoţite de semnale optice şi acustice diferite în

funcţie de notificare, apel sau informaţie. Vor fi redate în funcţie de prioritatea acestora într-o

listă de vizualizare.

FN.312 Agentul are posibilitatea de a selecta un apel din listă sau de a prelucra lista

după succesiunea intrării apelurilor.

FN.313 În continuare, vor fi specificate informaţiile despre apel şi notificare solicitate

în canalele de comunicare:

a. instalaţii de transmitere alarmă

b. apel telefonic/ apel verbal

c. apel RSS

d. apel SDS

e. informaţii nod de comunicaţie

f. semnale de operare şi deranjamente

g. notificări BEMIS

6.48 Metoda de transmitere alarme pentru notificări de incendiu

191 / 234

FN.314 La o notificare automată de incendiu printr-o instalaţie de transmitere alarme

se vor afişa şi urmări următoarele puncte:

a. afişaje ale unei notificări sosite, diferenţiate după tipul notificării şi status în

coloanele de informaţii

b. semnalizare pe culori a butoanelor de apelare la intrarea notificării

c. marcare acustică în funcţie de tipul notificării şi status pe fiecare notificare

d. informaţii de completare cu recunoaştere ID şi status (alarmă, revizie, deranjament)

e. completarea afişajelor atunci când sosesc simultan mai multe notificări

f. afişarea numărului semnalizatorului la sosirea mai multor notificări

g. posibilitate de selecţie a unei semnalizări sosite dintr-un fişier de vizualizare

h. semnalizare apel pe locuri de intervenţie configurabile

i. transmitere mai departe a apelului, atunci când apelul nu e procesat de locul de

intervenţie coordonat, sub formă de notificare colectivă cu semnal acustic spre toate locaţiile.

6.48.1 Apel telefonic/ Apel verbal

FN.315 Informaţiile apelului apar pe o interfaţă cu indicarea telefonului. Există

posibilităţi de formare de interfeţe separate în funcţie de diferite grupuri de apeluri.

FN.316 Funcţiile din coloanele de informaţii sunt în special:

a. notificarea unui apel telefonic sau telefon, optic/ acustic, separat în funcţie de

judeţul numărului apelant/ grupa de telefoane/ grupa de convorbiri/ canalele de legătură cu

recunoaştere ID pe fiecare apel.

b. reprezentare atunci când sosesc simultan mai multe apeluri.

c. deschiderea unui fişier de vizualizare la atingerea unui buton de notificare cu

indicatorul mouse-ului sau în mod automat.

d. înregistrare la alegere a unui apel din fişierul de vizualizare în fereastra de

notificare.

e. completarea informaţiilor privind participanţii, în măsura în care acestea sunt

cuprinse în datele de bază ale bazei de date.

f. transmiterea mai departe a apelului la alte staţii de operare sau ca apel colectiv,

dacă apelul nu este preluat într-un interval de timp setat în prealabil.

g. transmitere încrucişată către GIS cu afişarea imaginii grafice la afişarea de numere

de telefon, care se subordonează unor obiecte cu posibilitate de prelucrare a coordonatelor.

h. plasarea automată a unei intervenţii în curs, atunci când informaţiile privind

apelantul sunt identice cu informaţiile apelantului unei intervenţii existente, de ex. acelaşi

număr de apel, acelaşi nume de apelant.

i. deschiderea unei ferestre de selecţie pentru caracteristici suplimentare ale

conexiunii telefonice (de ex. suport, transmisiune, intermediere, separare)

j.

6.48.2 Apel RSS / Apel SDS

192 / 234

FN.317 Apelul RSS/SDS, format din convorbire RSS/SDS sau apel de urgenţă

RSS/SDS va fi afişat pe calculatorul de dirijare intervenţie optic şi acustic în

coloanele de comunicare.

FN.318 Pentru procesarea apelului se vor pregăti următoarele funcţii:

a. notificare privind status-ul RSS 5 sau status SDS echivalent sub formă de intenţie

de convorbire către centrul de comandă şi control

b. transfer intenţie de convorbire către difuzor subordonat la alegere sau la alegere

toate difuzoarele cu câte un semnal optic şi acustic pe fiecare apel.

c. informare atunci când există mai multe apeluri RSS simultan

d. indicarea sumei notificărilor existente

e. emiterea unei liste de apelanţi

f. deschiderea listei de apelanţi prin atingerea butoanelor de notificare cu indicatorul

mouse-ului sau în mod automat

g. transmiterea mai departe a convorbirii la predarea intervenţiei către o altă staţie de

operare

h. plasare automată a intervenţiei la preluarea convorbirii.

i. marcare a apelului de urgenţă cu prioritate deosebită.

j. transmitere mai departe a informaţiilor apelului către toate staţiile de operare, dacă

un apel RSS nu este preluat de deţinătorul unei staţii de operare într-un interval de timp setat

în prealabil.

6.48.3 Sistem de asistenta la alarme multiple

FN.319 Asistarea informaţiilor prin SMS cu atribuirea mijloacelor de intervenţie

conform planului de intervenţie / comandă de alarmare şi decuplare.

FN.320 Configurarea unei confirmări a participanţilor la telefonul mobil cu

transmiterea informaţiilor înapoi în sistemul de ghidare a intervenţiilor. Prin sistemul de

ghidare a intervenţiilor se va reprezenta o confirmare cu atribuirea mijlocului de intervenţie şi

a intervenţiei (lista informaţiilor de retur).

6.49 Informaţii privind locaţia de prestare a serviciului

FN.321 Informaţiile privind locaţia de prestare a serviciului vor fi afişate în cazul

informaţiilor în canalele de comunicare. La preluarea notificării se va deschide spre

prelucrare o funcţie standard de trimitere fişier prin e-mail. Butonul de comandă

serveşte în acelaşi timp pentru primirea şi trimiterea de informaţii.

6.49.1 Informaţii privind notificări şi operaţiuni - notificări BEMIS

193 / 234

FN.322 Prin intermediul informaţiilor despre notificări şi operaţiuni vor fi afişate

imagini actuale asupra situaţiilor curente de operare, supravegheri sau deranjamente.

La plasarea unei notificări va apărea un afişaj acustic, respectiv optic în coloanele

de informaţii.

FN.323 La preluarea notificării va apărea un text cu informaţii privind situaţiile de

operare notificate cu indicarea în catalogul de măsuri la măsurile executate, respectiv cu

indicare pentru prelucrarea intervenţiei, atunci când anunţul se referă la notificări de

intervenţii.

6.50 Cerinţe suprafeţe de pe ecran

FN.324 Staţiile de operare dispun de regulă de suprafeţe de lucru cu patru ecrane. Pe

suprafeţele ecranelor sunt reprezentate procesele şi utilizările. În principiu, ecranele

sunt împărţite în: ecran de prelucrare pentru preluare notificări - misiune - alarmare

- ecran de informaţii - panou mijloace de intervenţie.

FN.325 Fişiere cu informaţii generale

a. ecran de vizualizare de ansamblu,

b. reprezentare intervenţie

c. imagini de ansamblu asupra intervenţiei

d. ecran grafic – GIS – imagini

e. informaţii grafice de completare

FN.326 Pentru asistarea rapidă a proceselor de bază, reprezentările ecranelor vor fi

astfel proiectate încât funcţiile individuale pentru prelucrare să poată fi puse la dispoziţie în

condiţii de siguranţă fără funcţii pe fişe (de exemplu: reprezentarea prelucrării notificării şi

misiunea pe un ecran).

FN.327 Dispunerea ferestrelor, operaţiunilor, afişajelor şi butoanelor de comandă pe

ecrane se vor proiecta astfel încât să poată fi afisate ergonomic. Trebuie să existe posibilitatea

plasării unui profil orientat pe utilizator.

FN.328 WEB-Client poate fi plasat la alegere pe cele 4 ecrane şi astfel se pot afişa

independent de sistemul de ghidare a intervenţiilor informaţii şi afişaje generale. Agentul are

astfel posibilitatea să plaseze WEB-Client astfel încât activitatea BEMIS să fie păstrată în

mod optim.

6.50.1 Ecran de prelucrare

FN.329 Ecranul de prelucrare se va agrea împreună cu beneficiarul în ceea ce priveşte

structura şi reprezentarea acestuia.

FN.330 Suprafaţa ecranului se va subordona serviciului prin selecţie sau introducerea

unui cuvânt-cheie. În funcţie de cerinţele serviciilor individuale, suprafaţa ecranului respectiv

layout-ul ecranului va fi adaptat cerinţelor din cadrul interfeţei de bază.

FN.331 Cerintele minime privind popularea cu informatii a ecranului de prelucrare:

194 / 234

a. Preluare notificare:

- canale de comunicare

i. telefon (pe grupe, conexiuni, nr.)

ii. semnalizare incendiu

iii. apel RSS/ apel SDS

iv. informaţii privind locaţia de prestare a serviciilor

v. informaţii privind notificarea şi operaţiunile

vi. număr intervenţie

vii. loc intervenţie

- domeniul de supraveghere/ protecţie

- locaţie (oraş, comună)

- stradă

- intersecţie

- număr casă

- obiect

- clădire

- semnalizator

- cuvânt-cheie intervenţie

- cuvânt caracteristic

- cuvânt diagnosticare

- cuvânt-cheie prioritate

- apelant

i. nume

ii. prenume

iii. telefon

iv. localitate

v. stradă

- informaţii text

b. Informaţii speciale preluare

- afişare fundal

- listă a locaţiei

- listă obiecte

- listă semnalizator

- listă cuvinte-cheie intervenţie

- diagnosticare

- listă cuvinte caracteristice

- informaţii privind apelantul cu indicarea adresei din înregistrările făcute în baza de

date

c. Informaţii privind transportul

- nume pacient

- tip transport

- dotări speciale

- loc intervenţie

195 / 234

- loc preluare

- obiect (spital, clădire, domeniu, departament)

- loc de destinaţie

- obiect (spital, clădire, domeniu, departament)

- data transportului: de la – până la

- data transportului înapoi: de la – până la

- durata transportului

d. Fişier semnalizator

- descriere semnalizator

- ID - recunoaştere

- status

FN.332 Suprafeţe active - funcţii

a. Misiune:

- mijloc intervenţie

- denumire mijloc intervenţie

- stare de disponibilitate

- denumire apel radio

- locaţie mijloc de intervenţie

- informaţii status

- măsuri

- informaţii

- reavizări

- fişiere intervenţie

- procese verbale intervenţie

b. Masuri

- Modificare mijloc de intervenţie

- Informaţii – completări text

- Mijloc de intervenţie +/-

c. Alarmare:

- mijloace de intervenţie ce pot fi alarmate

- catalog măsuri

- alarmare automată colectivă

- alarmare manuală individuală

d. Asistare intervenţie:

- utilizarea interfeţelor pentru preluare notificare, misiune şi alarmare

- reprezentarea listelor de intervenţii

- informaţii

- reavizări

- funcţie telefon

- asistare radio

- servicii RSS, servicii SDS

- emiţător alarme radio

196 / 234

- rapoarte

- sarcini de imprimare

- proces verbal BEMIS

- împărţire intervenţie

- informaţii

e. Încheiere intervenţie:

- utilizarea funcţiei de sprijinire a intervenţiei cu completarea interfeţei de încheiere

intervenţie

- înregistrări despre intervenţie

- copiere informaţii despre intervenţie

- împărţire intervenţii

- plasarea transporturilor multiple

-

6.50.2 Ecran de informaţii şi imagine de ansamblu

FN.333 Reprezentarea de bază este panoul cu mijloace de intervenţie. Completările

obişnuite aici sunt în special:

a. informaţii din baza de date

b. informaţii generale

c. prelucrări independente de intervenţie

6.50.3 Ecran grafic

FN.334 Reprezentarea de bază este GIS. Completările sunt în special:

a. afişarea nivelelor din GIS

b. reprezentarea planurilor speciale

c. reprezentarea fotografiilor de la faţa locului sau fotografiilor de ansamblu

d. informaţii generale imagini

e. pentru sprijinirea funcţiei de management a notificărilor se vor plasa pe suprafaţa

ecranului următoarele cerinţe:

i. organizarea unui canal de comunicare pentru reprezentarea

notificărilor sosite

ii. marcare optică în funcţie de semnalizator şi status

iii. informaţii acustice ajustabile

f. reprezentarea unei liste de selecţie la sosirea mai multor notificări, sortate în funcţie

de tipul notificării şi status

g. sortarea listei pe filtre, după:

- domeniu

- tip notificare

- denumire semnalizator

- status semnalizator

197 / 234

- sosire temporală

- preluarea din lista de selecţie în masca de notificare – înregistrarea într-un fişier de

notificări a notificărilor care sosesc şi trebuie prelucrate

- notificare alarmă

- notificare deranjament şi funcţionare

- notificare alarmă de la un semnalizator în stare de revizie

- reprezentarea situaţiei actuale

h. preluare printr-o suprafaţă activă de notificare

i. suprafeţe active de prelucrare:

- confirmare semnalizator

- respingere

- ştergere

- preluare

transfer în prelucrare intervenţie

6.51 Funcţie de ajutor

FN.335 Organizarea unei funcţii de ajutor care să funcţioneze permanent cu

coordonare spre teme individuale şi paşi de prelucrare. În cadrul funcţiei de ajutor,

operatorul trebuie să aibă posibilitatea de a primi ajutor.

FN.336 Prin intermediul unei funcţii de căutare, trebuie să existe posibilitatea de a

căuta informaţii suplimentare după noţiuni şi cuvinte-cheie. Sistemul trebuie să facă

transferul prin link-uri către informaţi şi explicaţii suplimentare.

6.52 Documentare/JURNALIZARE OPERATII SISTEM

FN.337 Cu sistemul de asistare a documentării trebuie documentate toate operaţiile în

BEMIS, cu activităţile efectuate, după dată, oră şi locurile de editare, cu utilizatorii

înregistraţi. Documentaţia este bază pentru evaluări şi statistici. În acelaşi timp se

extrag datele importante pentru managementul calităţii.

FN.338 Documentaţia se va înregistra într-un proces verbal BEMIS curent şi

cronologic.

FN.339 Documentarea se face în principal după următoarea listă:

a. protocolarea tuturor operaţiilor manuale şi automate.

b. înregistrare în procesul-verbal BEMIS pentru toate operaţiile.

c. înregistrare în jurnalul sistemului, raportat la intervenţii.

d. marcarea orei în funcţie de statut, manual sau prin înregistrare automată

e. marcare automată a orei la începerea serviciului

f. marcarea monitorizării timpului:

i. dispoziţie

ii. dispoziţie automată

g. modificări manuale ale dispoziţiei

198 / 234

h. alarmare

i. mobilizare

j. deplasare la locul respectiv

k. sosire la locul intervenţiei

l. preluare pacient

m. continuarea deplasării la locul de destinaţie

n. sosire la locul de destinaţie

o. serviciu finalizat

p. întoarcere la monitorizare/casa aparatelor/adăpost

q. dorinţa de apelare

r. apel de urgenţă

s. înregistrarea câmpului cu ora cu modificare automată a disponibilităţii în fişierul

mijloacelor de intervenţie.

t. lista cu intervenţii, separate în funcţie de intervenţii în curs, nefinalizate şi finalizate.

u. lista cu intervenţii, separate în funcţie de măsuri în curs, nefinalizate şi finalizate

v. marcarea apelurilor primite în serverul de comunicare şi în instalaţiile conectate la

acesta cu transmitere şi afişare în BEMIS pentru: apel primit - apel acceptat - apel

redirecţionat - apel terminat

w. marcarea altor apeluri primite

x. alte linii conectate (FAX, SMS, E-Mail)

FN.340 Intrarea unui semnalizator în alarmă

a. intrarea unui semnalizator în revizie

b. intrarea unui semnalizator defect

c. alarmare / automat, manual

d. înregistrări de text şi note

e. proces-verbal pentru înregistrarea în fişierul cu măsuri

f. înregistrări ulterioare ale intervenţiilor

g. înregistrarea unei staţii de operare

h. schimbare de utilizator la o staţie de operare

i. lămuriri catalog de măsuri cu fiecare măsură în parte

j. editare paralelă cu marcaj utilizator

k. predare serviciu

6.52.1 Documentaţia în colaborare cu instalaţiile de documentare audio

FN.341 În cadrul documentaţiei este necesar un schimb de date între computerul de

coordonarea intervenţiilor şi instalaţia de documentare audio.

FN.342 Conform normei de securitate IT sunt necesare următoarele documentări şi

protocolări:

a. Operatii de administrare

b. Stabilirea configuraţiilor

c. Creări, modificări şi ajustări în baza de date

199 / 234

d. Instalare şi configurare în baza de date

e. Documentarea accesibilităţii şi cerinţelor de confidenţialitate în baza de date

f. Documentarea drepturilor de acces şi vizualizările fiecărui utilizator în parte

g. Documentarea utilizatorilor autorizaţi cu profilul lor de drepturi

h. Documentările linkurilor la banca de date

i. Documentările restricţionărilor de resurse efectuate în banca de date

j. Documentările procesului de securizare IT

k. Documentarea pentru realizarea şi transpunerea conceptului de siguranţă IT

l. Documentarea funcţiilor de management

m. Documentarea şi crearea unui manual de siguranţă IT, operaţii restore, operaţii de

deservire de urgenţă

n. Documentarea programelor create, a sistemelor de operare, a programelor de

utilizatori, program antivurus, programe de sistem

o. Documentarea defecţiunilor şi virusurilor înregistrate

p. Documentarea verificărilor

q. Documentarea conceptelor krypto create

r. Documentarea sistemelor de hardware create şi utilizate, tool-uri software

s. Documentarea pentru reglarea service-ului şi a întreţinerii ca şi diviziunea sarcinilor

necesară pentru aceasta

t. Documentarea unei liste de inventar software

u. Documentarea unei liste hardware

v. Documentarea asigurărilor de date care au fost efectuate

w. Documentarea atribuirii funcţiilor pentru drepturile de acces

x. Documentarea pentru protocolarea fişierelor

y. Documentarea cu privire la schimbul de date, transmiterile de date în reţea

z. Documentarea cu privire la posibile procese IT şi desfăşurări de proces

aa. Documentarea cu privire la remediile şi analizele de erori necesare şi posibile

bb. Documentarea cu privire la accesul la baza de date

cc. Documentarea cu privire la activităţile de administrare desfăşurate

dd. Documentarea cu privire la controalele de siguranţă necesare şi recurente în sistem

FN.343 Documentarea trebuie salvată în fişierele pregătite în sistem, aşa încât să

poată fi consultata şi revizuită. Datele trebuie protejate de accesul general şi arhivate min. 12

luni.

6.53 Asigurarea intervenţiilor în curs - Tipărire în fişier

FN.344 Pentru asigurarea intervenţiilor în curs şi finalizate anumite înregistrări

selectate din jurnalul activitatii trebuie transferate în formă structurată.

FN.345 Transferul trebuie făcut într-o baza de date structurată. În structura respectivă

trebuie stocate toate datele esenţiale cu privire la intervenţiile în curs şi finalizate.

200 / 234

FN.346 Dacă se defectează serverul de coordonare a intervenţiilor trebuie să existe

posibilitatea de a reprezenta datele stocate în mod structurat prin intermediul unui tool

pregătit sub formă de raport şi print, aşa încât să existe o privire de ansamblu rapidă asupra

intervenţiilor în curs şi finalizate şi asupra informaţiilor de status.

6.54 Computerul / serverul de coordonare a intervenţiilor

FN.347 Serverul de coordonare a intervenţiilor este un sistem integrat de informare,

comunicare, management şi organizare. Cerinţele fundamentale ale sistemului sunt

crearea şi asistarea staţiei de operare în operarea şi desfăşurarea proceselor în

serviciile:

a. pompieri

b. salvare

c. poliţie

d. asistenţă în condiţii de catastrofă

e. servicii de asistenţă clienţi şi de informare

f. acordarea de ajutor

6.55 Cerinţe cu privire la PERFORMANTA

FN.348 BEMIS trebuie să sprijine eficient staţiile de operare cu toate

funcţionalităţile, aplicaţiile şi funcţiile sale.

FN.349 Toate componentele sistemului trebuie concepute, în privinţa dimensiunilor

şi a performantei, pentru aceste solicitări. Capacitatea totală de performanţă în BEMIS trebuie

să fie atât de mare încât să se poată garanta o activitate eficientă şi rapidă.

FN.350 BEMIS este cuplat cu sistemul de comunicare şi informare, aşa încât întregul

sistem să sprijine în funcţiile sale, pe lângă informaţiile şi dispoziţiile dependente de statut şi

operările şi aplicaţiile de comunicare, în mod automat.

FN.351 Punctele forte sunt în acest context cuplările şi aplicaţiile pentru preluările de

mesaje, dispoziţii, alarmări, asistenţă intervenţii şi finalizări intervenţii.

6.55.1 Comportament de pornire după repunerea în funcţiune

FN.352 BEMIS trebuie să aibă o rutină automată de start, respectiv un proces de

repornire, prin care după o anumită perioadă de inactivitate este actualizat întregul

sistem. După reboot în BEMIS trebuie realizate mai ales următoarele funcţii:

a. Preluare a mijloacelor de intervenţie

b. Reprezentarea detectoarelor

c. Structura afişajului cu privire la starea autovehiculelor

d. Actualizarea statusurilor intervenţiilor

e. Reglarea cu serverul RSS pentru actualizarea informaţiilor de statut

201 / 234

f. Structura legăturilor de comunicare

g. Activarea interfeţelor create

h. Actualizarea orelor pentru monitorizarea duratelor, raportat la noua oră de start a

computerului de coordonarea intervenţiilor.

6.55.2 Randamentul sistemului

FN.353 Asistarea sistemului cu performanţă înaltă pt. funcţionarea generală a

centrului de comandă şi în condiţii de solicitare la capacitate maximă şi editare

simultană la toate locurile de coordonarea intervenţiilor

6.56 Capacitatea centrului de comanda

FN.354 Capacitatea unui centru de comandă şi control este o dimensiune importantă

în privinţa randamentului şi se calculează în funcţie de intervenţiile care trebuie

realizate şi de activităţile complementare.

FN.355 Intervenţiile sunt intervenţiile fixe atribuite cu un număr de intervenţie şi cu

luarea în considerare a rezervelor pentru extindere, respectiv a evenimentelor extraordinare.

FN.356 Activităţile complementare sunt informaţii care nu se pot corela în mod

direct cu o intervenţie, de ex. combaterea insectelor, îndepărtarea cadavrelor, întrebări pentru

cabinete medicale. Solicitarea BEMIS se măsoară ca valoare de vârf în orele cu circulaţie de

vârf şi la solicitări excepţionale. Aceste solicitări se vor acoperi cu BEMIS.

FN.357 Ca şi capacitate trebuie plecat de la 300.000 intervenţii, respectiv activităţi

complementare ale centrului de comandă p.a., cu o solicitare pe oră de 800 intervenţii şi

activităţi complementare. Trebuie luate în considerare şi posibilele extinderi cu alte

intervenţii şi activităţile complementare.

6.57 Cerinţe specifice BEMIS:

FN.358 Administrarea datelor principale, constând din:

a. date despre locatie

b. date despre obiect

c. date despre persoana care a făcut anunţul

d. date despre mijloacele de intervenţie

e. cuvinte-cheie intervenţie

f. cuvinte de ordine

g. date cu privire la adrese

h. date de legătură

i. planuri de alarmă

j. informaţii grafice.

202 / 234

FN.359 Administrarea datelor dinamice pentru corelarea datelor principale prin

regulamentul de alarmă şi mobilizare şi cataloagele de măsuri

FN.360 Asistenţă pentru preluarea mesajelor, dispoziţii şi alarmări până la 999.999

(cu şase poziţii) intervenţii etc. Asistenţă pentru instalaţiile publice de semnalizare cu până la

999.999 semnalizatori etc. (cu şase poziţii), cu luarea în considerare a datelor

semnalizatorilor (numerele semnalizatorilor, statutul semnalizatorului, linia semnalizatorului,

locul semnalizatorului) şi a informaţiilor grafice aferente

FN.361 Pentru administrarea volumelor de date trebuie prevăzute spatii de stocare de

dimensiuni corespunzătoare într-o baza de date relaţională pentru datele principale. În acest

context trebuie luate în considerare alte rezerve de extindere.

6.58 Bazele de date

FN.362 Baza de date trebuie creată ca baza de date de tip SQL relaţională cu interfaţă

ODBC. În acest context trebuie livrată şi creată ca sistem unitar baza de date cu sistemul cel

mai nou de programe. Structura bazei de date trebuie armonizată cu centrul de comandă pe

baza datelor utilizate, respectiv implicate.

FN.363 Structura bazei de date trebuie sa ofere acces liber la tabele şi coloane.

6.58.1 Structura bazei de date

FN.364 Baza de date relaţională trebuie structurată pentru o asistare cu fişiere şi date

împărţite. De asemenea trebuie create domenii pentru preluarea de date principale

din alte baze de date. Sincronizările şi replicarile bazei de date între servere trebuie

realizate automat, independent de activitatea de coordonare a intervenţiilor. Erorile

în corelarea datelor trebuie afişate ca mesaje de eroare.

FN.365 Up-datările regulate trebuie sa garanteze actualizarea datelor cu distribuţie

automată la bazele de date corelate.

FN.366 Comutările pe baze de date redundante în caz de defectare a serverului de

date trebuie să aibă loc automat. Comutările trebuie afişate ca mesaj în sistem. Într-un câmp

de meniu trebuie afişată de fiecare date activitatea băncii de date operate la momentul

respectiv.

6.58.2 Informări - baza de date

FN.367 Prin filtre, interfeţe şi fişiere toate datele şi informaţiile stocate în baza de

date trebuie adusă în formă vizualizabilă pe monitoarele locurilor de coordonare ale

intervenţiilor, prin rapoarte, pentru editare şi pentru furnizarea de informaţii.

FN.368 Accesul şi informaţiile din baza de date trebuie sprijinite cu etapele simple

de dialog desfăşurate cu ajutorul meniului:

a. selectarea câmpurilor

203 / 234

b. căutare în datele principale după criterii selectabile

c. reprezentarea unui tablou de ansamblu ca fişier în care se poate răsfoi şi care se

poate prelua în cazul în care căutarea a avut mai multe rezultate

d. extinderea unui tablou de ansamblu dintr-o denumire scurtă într-o denumire cu text

întreg

e. pregătirea afişajului în formă grafică

FN.369 Datele şi informaţiile determinate trebuie preluate în meniul Editarea

intervenţiilor. În completare trebuie să existe posibilitatea de a transfera aceste date prin

intermediul funcţiei export la alte programe de aplicaţii sau la un fişier de tipărit.

6.58.3 Baze de date în CMISU

FN.370 Bazele de date relaţionale sunt o componentă importantă a centrului de

comandă.

FN.371 În bazele de date sunt stocate datele principale necesare ca şi datele logice de

legătură pentru aplicaţiile de proces ale computerului de coordonarea intervenţiilor. Prin

legături online cu sistemele de comunicare conectate în centrul de comandă se actualizează

datele actuale, ca informaţiile de statut, intrările de mesaje ca şi editările în curs şi

intervenţiile.

FN.372 În interiorul centrului de comandă serverul bazei de date şi de aplicaţie

(serverul principal), serverul pentru şcolarizări şi teste, serverul de comunicare ca şi serverul

de administrare dispun de bănci de date independente care sunt sincronizate la intervale

regulate cu banca de date primară în serverul principal pentru aplicaţiile şi procesele stocate

în serverele respective.

FN.373 Mentenanta datelor se realizeaza independent de sincronizările / replicarile în

banca de date, în principal în baza de date a serverului principal şi completat cu datele

aferente în serverele de aplicaţie. Pe lângă sincronizările automate şi replicate, trebuie să

existe posibilitatea de a realiza sincronizarea / replicarea de fiecare dată manual sau de a le

întrerupe, respectiv finaliza automat.

6.58.4 Colectarea datelor

FN.374 Pentru funcţionarea şi activitatea BEMIS este necesară o structură unitară şi

structurată a datelor. Pentru punerea în funcţiune a BEMIS trebuie realizată o primă preluare

a datelor existente. Prima preluare cuprinde inserarea datelor principale din sistemul existent

prin intermediul executantului.

FN.375 Datele trebuie introduse din sistemele de date existente cu convertire

corespunzătoare. Pe durata aprovizionării cu date trebuie garantată o actualizare permanentă a

datelor în sistemul existent şi în sistemul nou.

FN.376 În BEMIS trebuie introduse mai ales următoarele date principale:

a. datele despre loc

b. semnalizatori obiecte

204 / 234

c. mijloace de intervenţie

d. cuvinte-cheie referitoare la intervenţii

e. cuvinte de ordine

f. măsuri

g. liste de adrese

h. liste de telefoane

i. liste de nume

j. coordonări periferice (căi de legătură)

k. legături telefonice

l. legături fax

m. legături SMS

n. legături mail

o. texte informative

p. grafică

6.58.5 Preluare din sursele de date

FN.377 În BEMIS se preiau date din alte sisteme de program. Structurile bazei de

date trebuie analizate de către executant şi trebuie convertite, în baza de date a

computerului de coordonare a intervenţiilor.

FN.378 Indicaţiile cu privire la structurile bazei de date sunt comunicate de către

beneficiar. Această cerinţă este valabilă şi pentru datele create în cadrul inregistrării datelor,

pregătite de ex. în tabele sau prin bazele de date.

6.58.6 Instrumente pentru preluarea şi gestionarea datelor

FN.379 Pentru preluarea datelor existente din bazele de date deja create ale

sistemului existent cat şi a datelor nou create trebuie dezvoltate instrumente de

convertire corespunzătoare pentru prealuarea de date unice sau în curs de

desfăşurare.

FN.380 Pentru fiecare aplicaţie în parte trebuie creată o zona de operare apelabila din

meniu.

6.58.7 Preluarea datelor

FN.381 Datele principale şi de legătură necesare trebuie inserate în banca de date în

formate armonizate.

205 / 234

FN.382 La preluare trebuie efectuate verificări corespunzătoare de logică şi

consistenţă a datelor create şi preluate. Suplimentar trebuie create instrumente adecvate

pentru a verifica datele migrate înainte de funcţionarea cu programe de aplicaţii.

FN.383 Sunt puse la dispoziţie mai ales următoarele fişiere, respectiv date pentru

convertirea datelor şi pentru preluarea în baza de date:

a. Hartă digitală cu date locale georeferenţiate pe baza planurilor de vector.

b. planuri standard

c. hartă digitală ca plan vector 1:500

d. plan vector topografic 1: 25.000

e. plan de ansamblu topografic 1: 50.000

f. planuri de ansamblu în format CAD

g. planuri obiect şi intervenţie

h. date de semnalizare ale instalaţiilor de semnalizarea incendiilor

i. date de semnalizare ale instalaţiilor de transmiterea alarmei

j. fişiere cu adrese

k. mijloace de intervenţie

l. căi de legătură şi coordonare

m. date - informaţii

n. planuri alarmă

o. planuri speciale

FN.384 Zonele marchează domeniile organizatorice sau tactice pentru editarea

intervenţiilor. Zonele se pot defini liber. Crearea se face cu sprijinul GIS, cel putin:

a. Pompieri: zona de intervenţie, zona de pază, zona protejată localitate, cartier, stradă,

sector stradă

b. Salvare: zona salvare, zona de pază localitate, cartier, stradă, sector stradă

c. Servicii speciale (zone de intervenţii care se pot defini liber, de ex. cazuri de daune

mari)

d. Zone de competenţă, zone de pază localitate, stradă, sector stradă

6.58.8 Interconectarea cu alte sisteme externe

FN.385 Aplicatia software va asigura integrarea cu Baza de Date Urbana (BDU –

Bucuresti), avand capacitatea de introducere si preluare a datelor de la nivelul

acesteia. Comunicatia bidirectionala in timp real se va asigura pe baza limbajului

XML, iar informatiile referitoare la modalitatea de transfer vor fi puse la dispozitia

implementatorului de catre beneficiar si vor fi detaliate in faza de analiza a

proiectului.

FN.386 Aplicatia va putea fi conectata cu sistemele similar ale: MApN, MAI, SRI,

STS, Administratia Spitatelor si Serviciilor Medicale, Salvare, Administratia apelor,

ApaNova, Radet si/sau a altor entitati desemnate de catre Beneficiar. Comunicatia se va face

pe baza limbajului XML, intercoectare IP, iar protocoalele de transfer ale BEMIS vor fi puse

la dispozitia Beneficiarului pentru dezvoltari ulterioare.

206 / 234

6.59 Structura datelor principale esenţiale

În cele ce urmează se indică structura celor mai importante date principale.

FN.387 Date despre loc

a. Zone

- zone ale serviciului de salvare

- zone în judeţ

- zone în oraş / zona comunei

- zona de pază / protecţie

- zone de serviciu

- zone semnalizatoare

- alte zone care se pot defini liber

- marcare specială a zonei (succesiunea zonelor FF, resursă specială în zona ş.a.m.d.)

b. Cod poştal

c. Localitate

d. Cod oficial comună

e. Stradă

f. Număr

g. Căi de circulaţie

h. Curs de apă

i. Căi de circulaţie

j. Sectoare de stradă

k. Intersecţii stradă

l. Pietre kilometrice stradă, căi de circulaţie (raportate la direcţie)

m. Sectoare de stradă cu cel mai mare şi mai mic număr de casă par

n. Sectoare de stradă cu cel mai mare şi mai mic număr de casă impar

o. Marcaje speciale ale străzilor (tipul străzii, stradă cu sens unic, stradă înfundată etc.)

FN.388 Obiecte (date complementare la datele despre loc):

a. Denumirea obiectului

b. Tipul obiectului

- Spital

- Clădire

- Direcţia de mers

c. Departament

d. Staţie

e. Adresă

- Cod poştal

- Localitate

- Cartier

- Stradă

- Număr

207 / 234

- Drumuri de acces

f. Alte adrese de ex. clădirea unui obiectiv

g. Număr semnalizator

h. Grupă semnalizator

i. Zonă semnalizator

j. Bariere

k. Porţi

l. Camere

m. Obiecte speciale (de ex. obiecte delimitate în timp ca târguri periodice, circuri)

n. Coordonate

o. Clădire

p. Număr clădire

q. Parte clădire

r. Etaj

s. Număr etaj

t. Sector etaj

u. Cameră

v. Număr cameră

w. Sector cameră

FN.389 Alte informaţii şi înregistrări complementare faţă de datele despre loc:

a. şantiere

b. nume suplimentare

c. nume "alias"

d. număr casă fictiv (de ex. pentru terenuri neconstruite)

e. număr cameră fictiv

f. câmpuri libere de date pentru date specifice de utilizator după definirea utilizatorului

g. zone în interiorul obiectului (de ex. zone unde se fac anunţuri, zone de evacuare)

h. coordonate

i. hidranţi

j. locuri de coordonare învecinate

FN.390 Date cu privire la mijloacele de intervenţie (EM):

a. Pompieri

b. Organizaţii

c. Mijloace de intervenţie

d. Tipuri de mijloace de intervenţie

e. Autovehicule

f. Persoane

g. Funcţii

h. Aparate

i. Grupe

j. Sinonime

k. Măsuri

FN.391 Informaţii complementare la mijloacele de intervenţie:

208 / 234

a. nume mijloc de intervenţie

b. nume suplimentar

c. tip mijloc de intervenţie

d. număr autovehicul

e. marcaj organizare (pentru selectarea resurselor)

f. nume apel celular

g. denumire RSS /SDS

h. grupe radio Tehnică digitală radio TETRA

i. zone de pază / protecţie

j. amplasamente

k. încărcătură specială / aparat / specialist

l. înălţime autovehicul

m. lăţime autovehicul

n. greutate autovehicul

o. personal implicat în intervenţie

Persoanele implicate în intervenţie sunt stocate în fişierul cu adrese.

FN.392 Date cu privire la mijloace auxiliare

a. nume mijloc auxiliar (mijloace auxiliare liber definibile ca mijloace de intervenţie şi

asistenţă pentru măsuri în domeniu de activitate al pompierilor, salvării, intervenţiei la

catastrofe)

b. nume suplimentar

c. text mijloc auxiliar

FN.393 Servicii de intervenţie

a. Serviciu pompieri

b. Acordare de asistenţă tehnică

c. Salvare în caz de urgenţă

d. Transport bolnavi / servicii de transport

e. Servicii de informaţii

f. Servicii pentru intervenţii catastrofe

g. Servicii speciale

FN.394 Crearea de funcţii de export şi import pentru preluarea informaţiilor de text

prin Client WEB ca şi prin informaţii externe. La sectiunea de cautare / cuvinte cheie se vor

prevede cel putin urmatiarele categorii si/sau cuvinte:

a. Cuvânt-cheie intervenţie:

- Pompieri

- Poliţie

- Acordare de ajutor

- Salvare în caz de urgenţă

- Transport bolnavi

- Informaţii

- Cazuri de daune mari

b. Cuvinte de ordine:

- Cuvinte suplimentare (asistenţă pentru găsirea de cuvinte-cheie intervenţie)

209 / 234

- Cuvintele de ordine vor fi cuplate cu cuvintele-cheie.

c. Liste de adrese

- Structură cu până la 10 trepte ierarhice (corelare şi înlănţuire) pentru marcare şi

selectare mai bună.

- Nume treaptă ierarhică (1 până la 10)

- Prenume

- Titlu

- Sex

- Data naşterii

- Funcţie

- Tip (de ex. spital, farmacie etc.)

- Apartenenţă zonă de pază / de protecţie

- Case de aparate

- Adăposturi

- Instrucţie

- Calificare

- Telefon: Fix Serviciu Telefon Fix Privat

- Grupă telefon: Telefon Mobil, Serviciu, Telefon Mobil, Privat

- Fax: Serviciu, Privat

- E-mail

- Nume apel celular

- ID RSS

- ID SDS

- Grupă celular

- Număr apel celular

- Cod poştal Localitate

- Cartier Stradă

- Număr

- Clădire Etaj

- Cameră

d. Informări, căi de legătură

- Imprimantă

- Legături generale

- IP

- Alarmă de pază

- Căi generale de comandă

- Date radio

- SMS SDS E-mail

6.60 Tipuri de fişiere de informaţii

210 / 234

FN.395 Urmatoarele tipuri, formate si/sau standarde sunt necesare si vor fi luate in

considerare de catre Contractant.

a. Fişiere materiale periculoase – formate standard

b. Fişiere grafice

- Hărţi digitalizate - material cartografic vectorizat

- Planuri speciale

- Fotografii ale locului

- Planuri obiect

- Imagini

- Date despre loc inserate

6.61 Asistarea exportului de informatii

FN.396 Pentru exportarea datelor principale aprovizionate trebuie prevăzut un sistem

de asistare a exportului din baza de date în alte programe, de ex. Microsoft Word,

Microsoft Excel, Microsoft Access.

FN.397 Utilizatorul trebuie să aibă posibilitatea de a selecta din baza de date datele

pregătite prin intermediul filtrelor şi să le transfere prin Export. Selectarea datelor trebuie

asistată cu View baza de date.

6.62 Volumul bazei de date

FN.398 Baza de date trebuie concepută în principiu cel puţin pentru o aprovizionare

dublă cu datele principale necesare, pentru a prelua în cadrul reţelei servicii de asistenţă şi

reprezentare. Volumul trebuie să poată fi extins, pentru a răspunde şi altor cerinţe.

FN.399 În detaliu, în principal trebuie planificat următorul volum pentru domeniul

centrelor de coordonare:

Localităţi: 1.000

Străzi / sectoare de străzi / numere:100.000

Obiecte: 50.000

Semnalizatoare (UE): 30.000

Mijloace de intervenţie: 30.000

Liste de adrese: 1.000.000

Zone: 2.000

Telefoane: 2.000.000

Puncte de coordonare / căi de legătură: 2.000

Fişiere de informaţii / Texte / Tabele / Imagini: 500.000

Cuvinte-cheie intervenţie / cuvinte de ordine / cuvinte diagnostic: 50.000

211 / 234

Fişiere cu text liber: memorie 20 GB

Grafică: memorie 200 GB

6.63 Asistarea sistemului

FN.400 Asistarea sistemului se împarte în administrarea sistemului, mentenanta

datelor şi planificare BEMIS.

FN.401 Pentru administrarea sistemului şi mentenanta datelor trebuie puse la

dispoziţie unelte adecvate şi interfeţe de editare uşor de înţeles, apelabile din meniu.

FN.402 Asistarea sistemului este în principal sarcina utilizatorului pentru domeniul

administrării sistemului.

FN.403 Domeniul asigurarea datelor şi planificarea BEMIS este prealuată de

utilizator, în acest caz de Centrul de Comandă şi Control Bucureşti.

6.64 Administrarea datelor

FN.404 Pentru aceasta, în centrul de comandă şi control trebuie furnizate în principal

următoarele funcţii generale:

a. aprovizionarea cu date

b. serviciu de modificare

c. verificări ale consistenţei datelor

FN.405 Datele introduse trebuie verificate în privinţa logicii. Trebuie prevăzută

posibilitatea de a pune la dispoziţie o interfaţa pentru administrarea datelor şi pe staţia de

operare pentru o editare prin dispeceri autorizaţi.

FN.406 Pentru asistarea administrării datelor în scopul actualizării datelor principale

şi legăturilor logice conform planurilor de alarmă, regulamentului de alarmă şi de mobilizare

şi măsurilor, sunt implicate şi locurile de operare de la PC-uri. Cu instrumentele pregătite la

aceste locuri de operare PC trebuie pregătite şi actualizate date. Aceste date sunt transmise pe

serverul de date prin reţea.

6.65 Date grafice

FN.407 Datele grafice necesare pentru computerul de coordonarea intervenţiilor se

vor pune la dispoziţie alte planuri necesare sunt procurate de beneficiar de comun

acord cu furnizorul de software BEMIS al sistemului. Prima livrare ca şi updatările

regulate ale datelor grafice trebuie să se facă prin suporturi pregătite de date.

Updatările regulate nu au voie să îndepărteze datele specifice utilizatorilor.

FN.408 Prima aprovizionare (încărcare) ca şi updatările se stochează pe server.

212 / 234

6.66 Planificarea BEMIS

FN.409 Planificarea BEMIS se corelează strâns cu serviciile de intervenţie aferente şi

cu organizaţiile respective. Rezultatul planificării BEMIS îl reprezintă ajustările

corespunzătoare în zona regulamentului de alarmă şi mobilizare, a succesiunii

zonelor, a tacticii de intervenţie cat şi completări în cataloagele de măsuri.

FN.410 Pentru asistarea planificării, actualizarea datelor referitoare la loc, datelor de

mijloace de intervenţie, planificarea alarmării cu comanda de alarmare şi decuplare se

creează locuri de muncă externe cu corelare directă la computerul de coordonarea

intervenţiilor.

FN.411 Prin sistemul de asistare pot fi prestabilite indicaţii necesare şi administrarea

datelor. Preluarea şi introducerea în computerul de coordonarea intervenţiilor se face prin

BEMIS.

6.67 Management, MESAJE de eroare şi de operare

FN.412 În general, în aparate se utilizează dispozitive SNMP. Monitorizarea şi

afişarea sunt susţinute de managementul funcţionării în condiţii de siguranţă şi sunt

afişate pe BEMIS cu informaţii în text simplu. Pentru gestionare este folosit un

instrument de management adecvat.

FN.413 Computerul central cu echipamentele şi sistemele implicate în gestionarea, cu

o eroare de sistem şi afişează de operare. Computerul central se va conecta la toate

dispozitivele si sistemele din sistemul de management permanent pentru monitorizarea

defecţiunilor şi al activităţii. Toate componentele sistemului sunt supravegheate în mod

curent. Toate sistemele sunt dotate cu modulele corespunzătoare SNMP. Afişarea în sine este

realizată, supravegheată şi afişată printr-un sistem de supraveghere pe un manager de sistem,

şi afişate.

FN.414 Anunţurile de deficienţe se vor prezenta în funcţie de următoarele criterii:

a. deficienţă ce urmează să apară

b. deficienţă cunoscută

c. anunţ privind o deficienţă trecută

FN.415 Diferitele informaţii despre anunţuri se vor prezenta cu diferite culori.

FN.416 Anunţurile de deficienţe trebuie încorporate în protocoalele curente.

FN.417 Aceasta include:

a. Alarme în sistem cu display direct în text simplu şi cu măsurile ce trebuie luate

b. Display sisteme de operare

c. Monitorizarea serverelor si sistemelor conectate, de exemplu, în ceea ce priveşte

utilizarea memoriei, performanţele sale şi comportamentul relativ la cerinţele de securitate IT

d. Anunţurile de deficienţă se vor afişa vizual şi acustic.

213 / 234

FN.418 Prin sistemul de management pe baza cerinţelor de siguranţă IT pot fi

configurate sistemele, se pot stabili utilizatorii cu drepturile aferente şi parolele în funcţie de

nivelurile de drepturi si grupurile de acces.

FN.419 Pe lângă gestionarea datelor şi prelucrarea datelor în funcţie de permisiunile

specificate va exista de asemenea posibilitatea ca datele introduse de la posturile de lucru să

fie completate.

FN.420 Actualizarea datelor de bază nu trebuie să necesite repornirea sistemului,

pentru a folosi aceste date în cadrul operaţiunii curente.

FN.421 Toate funcţiile şi intrările în sistemul de management trebuie documentate

fără lipsuri.

FN.422 Documentaţia se va păstra în cadrul sistemului. Trebuie să existe posibilitatea

de a salva documentaţia pe suporturi externe pentru arhivare precum şi posibilitatea de

printare pe hârtie a documentaţiei, astfel încât aceasta să poată fi folosită la refacerea

sistemului în caz de deficienţă

6.68 Arhivarea datelor

FN.423 Arhivarea datelor cu stocare şi management

FN.424 Introducerea unei valori de expirare a timpului alocat unei aplicatii

informatice.

FN.425 Controlul automat al timpului.

FN.426 Afişare la atingerea timpului specificat pentru ştergerea de către

administratorul de sistem.

6.69 Back-up

FN.427 Toate datele din computerul central trebuie salvate în mod conform în cel

puţin alte două locuri inclusiv în afara BEMIS şi trebuie arhivate timp de 10 ani

fiecare. Datele arhivate sunt editabile şi se pot căuta.

FN.428 Seturile de date care urmează să fie şterse se vor comunica. Ştergerea

fişierelor aprobate necesită aprobarea utilizatorului de drept.

FN.429 Pentru întreg sistemul din computerul central se va configura o securitate

eficientă cu funcţii automate.

FN.430 Nivel minim al cerinţelor de funcţionalitate:

a. backup manual la nevoie

b. backup automat de rutină de rezervă

c. backup pe termen lung conform unei politici de backup definite

d. stabilitatea datelor salvate

214 / 234

e. utilizarea datelor arhivate pentru repornire manuală şi automată şi pentru căutări

f. securizarea întregului set de date, inclusiv sistemul de operare, date de configurare,

date de master, cererea de date

g. realizarea de backup în operarea standard, fără nici o influenţă semnificativă asupra

performanţei

h. respectarea legislaţiei privind protecţia datelor

i. păstrarea datelor dinamice conform cerinţelor de date pentru următoarea generaţie

j. realizarea unui backup înainte de schimbări majore

k. actualizări şi upgrade-uri ale programelor alocate

l. rezistenţă contra atacurilor de vandalism asupra datelor

m. protecţia împotriva atacurilor din afară, din interior sau a atacurilor în forţă asupra

datelor

FN.431 Trebuie să se asigure că, în caz de cădere a sistemului datele salvate pot

asigura funcţionarea.

FN.432 Pentru datele salvate se va pune la dispoziţie o bază de date corespunzătoare.

Cu sprijinul bazei de date se vor prezenta oricând replicate pe ecran cu sistemul de operare

windows actual datele salvate.

6.70 Sistemul de management al crizelor

FN.433 Sistemul de management al crizelor va suporta toate procedurile automate

legate de managementul planurilor de urgenta controlate de ISUMB si legate de

regiunile Bucuresti si Ilfov, suportant coordonarea si colaborarea si facand posibila

luarea deciziilor in comun, dand agentiilor interoperabilitatea tactica si strategica

necesara.

FN.434 Managementul urgentelor majore este un process cooperativ intre agentiile ce

au o prezenta fizica in CMISU (ISUMB, DGPMG, SAMB, etc), autoritati locale sau centrale

si companii private

FN.435 Managementul sistemului va fi facut din cadrul CMISU.

FN.436 Principalele functionalitati care trebuie sa suporte sistemul de management al

crizelor sunt :

a. Managementul planurilor de risc si urgenta, incluzand crearea, modificarea,

consultanta, activarea si dezactivarea acestuia.

b. Stagiul unul plan deja activ, operatiunile lansate, resursele implicate, raporturile, etc.

c. Managementul si coordonarea unei urgente cu diferitele puncte de decizie implicate

ca : agentii prezente in CMISU, organisme nationale, companii private, etc.

d. Integrarea informatiilor din organizatii externe

e. Mentenanta calalogului de resurse

f. Generarea de rapoarte

FN.437 Sistemul de management al crizelor va afisa o harta tactica cu situatia actuala

si un sumar cu toate sursele de informatii. Aceasta harta tactica va fi accesibila tuturor

administratorilor, cu permisiunile aferente.

215 / 234

6.70.1 Componente generale

FN.438 Ofertantul va descrie modul de vedere asupra sistemelor si integrarile dintre

acestea, oferind o vedere integrata si detaliata asupra managementului crizei.

FN.439 Sistemul de management al crizei este compus din urmatoarele sisteme:

a. Baza de date privind riscul si urgentele

b. Unelte de colaborare pentru planificarea actiunilor de management

c. Harta tactica a situatiei

d. Catalogul unificat al resurselor

e. Manager de documente si continut

f. Administrare

FN.440 Sistemul de management al crizelor va indeplini urmatoarele cerinte

generice:

a. Simplicitatea catre utilizatorul final

b. Flexibilitatea operationala

c. Customizabilitate

d. Platforma securizata

e. Includerea de facilitati pentru planurirea urgentelor

f. Includerea de componente cooperative WEB 2.0

g. Integrarea cu GIS

h. Integrarea cu sistemul BEMIS

6.70.2 Integrarea cu BEMIS si alte sisteme in CMISU

FN.441 Sistemul de management al crizelor va fi interoperabil cu sistemul BEMIS,

deoarece principalul scop al proiectului SMISU este acela de a livra un sistem

complet de date, procese si aplicatii interoperabile.

6.70.3 Baza de date pentru riscuri si urgente

FN.442 Sistemul de management al crizelor va avea capacitatea de a gazdui, revizui

si analiza planurile de risc si urgente definit de PAAR (Planului de Analiza si

Acoperire a Riscurilor).

FN.443 Definitia planurilor de actiune are scopul standardizarii, pentru fiecare plan,

activitate sau mod de lucru pentru fiecare agentie, relatiile dintre entitati, expedierea

resurselor si modelul de raspuns.

6.70.4 Planurile de actiune

FN.444 Managementul planurilor de actiuni va permite generarea, consultarea,

activarea si dezactivarea acestor planuri intr-un mod intuitiv si simplu.

216 / 234

FN.445 Sistemul de management al crizelor va furniza capacitatile urmatoare pentru

fiecare plan, automat cu uneltele modului de lucru:

a. Propunerea operatiunilor precedente

b. Arii afectate

c. Validare / Atribuire

d. Lista de Contacte

e. Date statistice

f. Alerte / incidente / urgente:

g. Rapoarte sumare

h. Resurse mobilizate

6.70.5 Catalogul resurselor unificate

FN.446 Catalogul este o baza de date comuna pentru toate agentiile si organismele

implicate in proiectul SMISU si legate de managementul de urgenta.

FN.447 Trebuie sa fie accesata intr-o pagina web sigura, cu urmatoarele cerinte:

o Accesibila de cateva entitati pentru upgrade; orice schimbare la orice entitate

va fi vizibila si la celelalte entitati.

o Asigura integrarea de noi resurse material si umane.

o Crearea datelor si legaturilor

o Forme automate pentru a incarca informatia.

o Sistem de audit si securitate pentru informatii noi.

o Instrumente de mentenanta

FN.448 Implementarea sistemului trebuie sa aiba in considerare parametrii si

standardizarea datelor pentru incarcarea in catalogul unic.

6.70.6 Echipa de colaborare

FN.449 Cerintele minime pentru managementul de urgenta pentru echipa de

colaborare sunt. :

a. Crearea unui site pentru proiectul SMISU.

b. Crearea unui site pentru CMISU.

c. Crearea de site-uri pentru agentiile CMISU.

d. Crearea de site-uri dinamice pentru Urgente.

6.70.7 Harta tactica

FN.450 Sistemul de management al crizelor trebuie sa aibe inclus un viewer GIS cu o

vedere impartita a urgentei, aratand informatiile despre incident si resursele asociate

cu operatiunile de urgenta.

217 / 234

FN.451 Harta tactica trebuie sa aibe functiile de baza de navigatie (pam, zoom,

scroll), folosind capacitatile sistemului GIS.

FN.452 Harta tactica CROP (Common Relevant Operational Picture) va fi impartita

oferind informatii complete si in timp real asupra situatiei, ajutand la luarea unei decizii in

cazul unor urgente.

FN.453 CROP-ul trebuie sa fie accesibil utilizatorilor la distanta prin mecanismele de

securitate aferente.

FN.454 Ofertantul trebuie sa detalieze integrarea intre CROP si Catalogul de resurse

unificate.

6.70.8 Managementul documentelor si continutului

FN.455 Sistemul de management al crizelor va putea permite accesul la urmatoarea

documentatie:

a. Modul de lucru, protocoale si proceduri

b. Planuri de urgenta

c. Directorul de contacte

d. Alte informatii in format electronic.

FN.456 Un sistem de management al documentelor trebuie livrat cu urmatoarele

cerinte:

a. Librarile de documente si galeriile de imagini sa fie cu urmatoarele functionalitati:

i. Mod de lucru (aprobare, publicare, revizuire)

ii. Managementul permisiunilor utilizatorilor

iii. Controlul versiunilor

b. Managementul metadatelor asociate documentelor.

c. Depozit accesibil cu capacitatea de integrare cu alte sisteme pentru stocare si

recuperare documente.

d. Interfata pentru incarcarea si descarcarea de documente.

e. Mecanisme de indexare a documentelor si continutul stocat, imbunatatirea modului

de cautare si acces la informatii mai rapid

FN.457 Platforma de management a documentului trebuie sa furnizeze o solutie

pentru procesarea informatiilor in format electronic si stabilirea de legaturi pentru transferul,

procesarea si depozitarea acestora.

FN.458 Un sistem de management al continutului trebuie furnizat cu urmatoarele

cerinte:

- Colaborare. Permiterea echipelor de a lucra impreuna intr-un mod eficient,

colaborand in editarea si publicarea paginilor, incluzand modul de lucru si

partajarea informatiilor.

- Managementul continutului. Crearea si gestionarea continutului Web, folosind

modul de lucru si oferind accesul la informatii.

- Continut web. Permite crearea de pagini web pentru impartirea informatiilor,

personalizarea paginii depinzand de profilul utilizatorului.

218 / 234

- Formulare. Permite crearea de formulare integrate in aplicatii si baze de date.

6.71 Confidentialitate si autenticitate

FN.459 Sistemul de management al crizelor trebuie sa furnizeze acces la informatii

de catre utilizatorii diferitelor organisme implicate in proiectul SMISU, si protejarea

impotriva accesului neautorizat din exterior.

FN.460 Sistemul va furniza securitatea prin intermediul definitiilor de utilizatori,

grupuri, roluri si permisiuni, verificand in orice timp permisiunea utilizatorului in fiecare

operatiune.

6.72 Integrarea camerelor de supraveghere a traficului

TRAFIC.1 Exista un numar de 100 de camera video IP pentru controlul traficului care

trebuie integrate in SMISU.

TRAFIC.2 Operatorii si staff-ul trebuie sa poata vizualiza semnale video live si

inregistrate de la toate camerele.

TRAFIC.3 Urmatoarele cerinte minime trebuie indeplinite:

a. Sistemul trebuie sa suporte integrarea a cel putin urmatoarelor formate:

MPEG-1, MPEG-2, MPEG-4 , H-264, cu rate de transfer de la 8 Kbps pana la

20 Mbps, cu traffic unicast sau multicast.

b. Integrand sistemul de management al camerelor, operatorii trebuie sa aiba

informatia referitoare la situatia fiecarei camera video integrate intr-un layer

GIS, astfel incat sa acceseze imagini video live sau inregistrate cand

gestioneaza un incident.

Folosind player-ul video din sistemul de management al camerelor, player-ul video va avea

control pentru derulare, inghetare si cautare in functie de timp a imaginilor video.

7 Asigurarea calitatii

7.1 Metodologia de asigurare a calitatii

Cerinţele privind documentaţia sistemului de management al calităţii, ţinerea sub control a

documentelor şi a înregistrărilor, responsabilitatea conducerii, managementul resurselor,

realizarea produsului, măsurarea, analiza şi îmbunătăţirea se îmbogăţesc prin abordarea

procesuală şi prezenţa determinantului principal.

QUAL.1 Metodele folosite pentru monitorizarea şi măsurarea proceselor sistemului de

management al calităţii sunt definite şi documentate de către responsabilii proceselor.

In acest sens se va defini un grup de asigurare a calitatii care va face parte din

resursele aferente proiectului.

219 / 234

QUAL.2 Pentru măsurarea eficacităţii proceselor sistemului de management trebuie

utilizaţi indicatori de performanţă. Atunci când rezultatele monitorizării şi măsurării

proceselor nu sunt în concordanţă cu cerinţele, trebuie întreprinse acţiuni corective

adecvate.

QUAL.3 Performanţele proceselor sistemului de management al calităţii sunt analizate

de către conducerea de vârf, la intervale stabilite.

7.2 Sistemul de management al calităţii

QUAL.4 Pentru implementarea unui sistem de management al calităţii care să respecte

cerinţele definite de standardul ISO 9001, organizaţia trebuie, mai întâi, să asigure:

a. identificarea proceselor corespunzătoare sistemului de management al calităţii;

b. determinarea succesiunii şi a interacţiunii acestor procese;

c. determinarea criteriilor şi metodelor necesare pentru ţinerea sub control a

proceselor;

d. disponibilitatea resurselor necesare pentru monitorizarea proceselor;

e. monitorizarea şi analiza proceselor;

f. implementarea de acţiuni necesare pentru obţinerea rezultatelor planificate şi

îmbunătăţirea continuă a proceselor.

QUAL.5 Documentaţia sistemului de management al calităţii trebuie să includă:

a. politica şi obiectivele organizaţiei în domeniul calităţii;

b. un manual al calitătii;

c. procedurile documentate cerute de standardul ISO 9001;

d. documentele necesare organizaţiei pentru a asigura planificarea, desfăşura-rea

şi ţinerea sub control a eficacităţii proceselor sale;

e. înregistrările cerute de standardul ISO 9001.

QUAL.6 Manualul calităţii trebuie să cuprindă:

a. domeniul de aplicare a sistemului de management al calităţii;

b. procedurile documentate care au fost stabilite pentru sistemul de management

al calităţii organizaţiei;

220 / 234

c. o descriere a interacţiunilor dintre procesele sistemului de management al

calităţii.

QUAL.7 Ţinerea sub control a documentelor - pentru ţinerea sub control a

documentaţiei sistemului de management al calităţii trebuie elaborată o procedură

documentată, care să prevadă modalitatea de desfăşurare a următoarelor activităţi:

a. aprobarea documentelor înainte de a fi utilizate;

b. analiza şi actualizarea documentelor;

c. asigurarea disponibilităţii documentelor acolo unde acestea sunt necesare;

d. identificarea documentelor şi asigurarea lizibilităţii acestora;

e. identificarea şi tinerea sub control a distribuirii documentelor de provenienţă

externă (documente provenind de la clienţi, reglementări aplicabile etc.);

f. identificarea corespunzătoare a documentelor perimate (nevalabile) sau

retragerea acestora, pentru a preveni utilizarea lor neintenţionată.

QUAL.8 Ţinerea sub control a înregistrărilor - pentru ţinerea sub control a

înregistrărilor referitoare la sistemul de management al calităţii trebuie elaborată o

procedură documentată, care să prevadă modalitatea de desfăşurare a următoarelor

activităţi:

a. identificarea înregistrărilor şi asigurarea lizibilităţii acestora;

b. arhivarea şi păstrarea înregistrărilor pe o durată determinată;

c. retragerea înregistrărilor nevalabile.

QUAL.9 Responsabilitatea managementului:

a. angajamentul conducerii organizaţiei privind implementarea şi îmbunătăţi-rea

continuă a sistemului de management al calităţii;

b. demonstrarea orientării către client a organizaţiei;

c. definirea politicii organizaţiei referitoare la calitate;

d. planificarea obiectivelor referitoare la calitatea produselor şi a sistemului de

management al calităţii;

e. stabilirea responsabilităţilor şi a unui sistem corespunzător de comunicare;

221 / 234

f. desemnarea "reprezentantului conducerii", care să asigure menţinerea

conformităţii sistemului de management al calităţii cu standardul de referinţă;

g. efectuarea de analize periodice, la nivelul conducerii organizaţiei, pentru

evaluarea conformităţii sistemului de management al calităţii cu standardul de

referinţă.

QUAL.10 Ofertantul trebuie sa implice in implementarea proiectului un specialist

in managementul calitatii care sa demonstreze bune practici în domeniul IT-

măsurarea indicatorilor proceselor şi a sistemelor informatice – prin certificate

cum ar fi Control OBjectives for Information and related Technology – COBIT

sau echivalent, calitatea de auditor sisteme de securitatea informaţiei – prin

certificare cum ar fi ISO27001/BS7799 sau echivalent, expertiza in managementul

securităţii - prin certificate cum ar fi Certified Information Security Manager –

CISM/Certified Information Systems Security Professional – CISSP sau

echivalent, expertiza in management de proiect – prin certificate cum ar fi Project

Management Professional - PMP, Projects IN Controlled Environments 2 -

PRINCE2 sau echivalent); Specialistul trebuie sa fie absolvent de studii superioare

în domeniul IT&C cu o experienţă relevantă în domeniu IT&C de minim 5 ani, sa

fi participat la 1 proiect privind sisteme informatice complexe si sa fi coordonat şi

finalizat implementarea şi certificarea în domeniul IT a cel puţin unui sistem de

management al calităţii conform ISO 9001:2000 sau echivalent şi a cel puţin un

sistem de management al securităţii informaţiilor conform ISO 27001:2005 sau

echivalent

8 Testare si acceptanta

8.1 Generalitati

TEST.1 In aceasta etapa, Contractorul va desfasura producerea de echipamente si

software, achizitionarea elementelor si integrarea acestora in conformitate cu Caietul

de Sarcini si Proiectul de detalii propus si avizat de catre Beneficiar.

TEST.2 In aceasta etapa, Contractorul va dezvolta, prezenta si propune Planul de

testare (PT), Protocoale pentru teste de acceptanta (PA) si Istoric al testelor de

acceptanta in conformitate cu Planul de testare si Descrierea Testelor hardware si

software. Vor exista trei tipuri de teste externe (ce se vor desfasura in prezenta

Beneficiarului), descriese in continuare.

TEST.3 Fiecare sectiune a sistemului poate suporta sesiuni de teste separate, stabilite de

Contractor, propuse prin Planul de Testare si acceptate de Beneficiar.

TEST.4 Contractorul isi va asuma costurile si responsabilitatea reiesite din organizarea

acestor teste.

222 / 234

TEST.5 Ofertantul trebuie sa demonstreze ca dispune de 3 specialisti, absolventi cu

studii superioare si care detin certificari referitoare la detinerea competentelor

avansate in domeniul testarii, cu experienta profesionala de minim 3 ani, si cu minim

1 an experienta in testarea sistemeleor integrate dovedita prin recomandari

8.2 Teste de acceptanta la fabricant (FAT)

Obiectivul acestor teste este acela de a verifica performantele si functionalitatile fiecarui

element esential al sistemului, in conditii de laborator, inainte de implementarea efectiva.

TEST.6 Se vor testa cel putin:

a. Interfata grafica (GUI)

b. Arhitectura retelei de date, functionala, in conditii de stres

c. Arhitectuara de servere

d. Aplicatiile software

TEST.7 Contractorul va prezenta functiile si interfata proiectate pentru sistem. Acest

test va permite verificarea faptului ca toate functiile sunt prezente in interfata

(verificarea rezultatelor aferente nu face parte din aceste teste).

8.3 Teste de acceptanta instalare in teren (SAT)

TEST.8 Aceste teste se vor efectua pentru testarea capacitatiilor partiale, dupa livrarea

si instalarea echipamentelor, precum si dezvoltarea si configurarea sub-sistemelor si a

aplicatiilor software, fara integrare.

TEST.9 Contractorul va elabora o procedura de testare SAT incluzand toate detaliile

testului.

8.4 Test de acceptanta finala

TEST.10 Acest test reprezinta testul final al sistemului dupa ce lucrarile de proiectare,

achizitionare, dezvoltare, integrare, desfasurare si configurare a acestuia au fost

finalizate, iar sistemul se considera a fi pe deplin functional.

TEST.11 Contractorul va elabora o procedura de testare finala incluzand toate detaliile,

cu sistemul integrat si functional.

8.5 Rezultate si documentare

223 / 234

TEST.12 Ca rezultat al acestor etape, sistemul trebuie sa fie gata sa inceapa sa opereze la

capacitatile sale depline. Pentru aceasta, Contractorul va realiza si livra urmatoarele

documente:

a. Descrierea in detaliu a interfetelor externe, in care se vor descrie caile clare

de implementare a echipamentelor a si sistemului.

b. Diseminarea rezultatelor testelor efectuate.

c. Planul de mentenanta, care va descrie solutiie de intretinere propuse pe

durata perioadei de garantie.

d. Planul de training, care va descrie continutul si obiectivele cursurilor de

operare si intretinere.

9 Pregatirea personalului

Pentru realizarea functionalitatii viabile si eficiente a sistemului de management al situatiilor

de urgenta un rol important trebuie acordat componentei de resurse umane implicate.

9.1 Planul de training

TRAIN.1 Planurile de training concepute vor trebui sa tina cont in mod fundamental

diferentele dintre categoriile de personal si sa ajute la dezvoltarea de competente

specifice celor doua tipuri de activitati cotidiene: manageriala si de executie.

TRAIN.2 Cursurile ce vor avea loc vor fi de tipul Train the Trainers, ceea ce va da

posibilitatea cursantilor de a deveni ulterior traineri pe specializarea respectiva.

TRAIN.3 Cursurile vor avea o durata de cel putin 40 de ore si odata absolvite ar trebui

sa ofere participantilor capacitatea de a opera sistemul.

9.2 Pregatirea personalului managerial

TRAIN.4 Pentru managerii organizatiilor implicate in managementul situatiilor de

urgenta este necesara o pregatire complexa, care sa acopere cunostinte si abilitati din

mai multe sectoare.

Contractorul va organiza cursuri de pregatire pentru managerii organizatiilor implicate in

urmatoarele specialitati:

TRAIN.5 Abilitati economice:

a. cunoasterea aprofundata a proceselor economice;

224 / 234

b. intelegerea aspectelor financiare si economice capacitatea de a cultiva relatiile

exogene organizatiei;

TRAIN.6 Abilitati in resurse umane:

a. inzestrarea cu echipamente si personal;

b. evaluarea performantelor;

c. comunicarea proiectarea organizatorica;

TRAIN.7 Management:

a. managementul de proiect;

b. evaluarea riscului;

c. punerea in valoare a intereselor organizatiei;

d. abilitati interpersonale si de rezolvare a problemelor;

e. managementul resurselor.

9.3 Pregatirea personalului tehnic (administratorii de sistem)

9.3.1 Generalităţi

Programele de training cuprind administrarea sistemului, preluarea datelor şi operarea

sistemului IT.

TRAIN.8 Programul de training se realizează sub formă de cursuri ţinute de specialişti.

TRAIN.9 Programul de training este structurat în cursuri de bază şi cursuri de

perfecţionare. În cazul în care sunt necesare forme speciale de training se pot pune la

dispoziţie programe de training corepunzătoare, cu indicarea costurilor aferente.

Scopul programului de training este de a asigura operarea sistemelor informatice, sistemelor

software, bazelor de date si aplicaţiilor. Acest program include de asemenea noţiuni de

remediere în cazul defectării sistemelor informatice precum şi asigurarea service-ului.

TRAIN.10 Toate cursurile sunt însoţite de activităţi practice, documentaţii şi manuale.

Manualele de curs referitoare la sistemele ce urmează a fi instalate se pun la dispoziţia

cursanţilor cu cel puţin 14 zile înainte de data de desfăşurare a cursurilor.

225 / 234

TRAIN.11 În vederea desfăşurării programelor de training, simulare şi teste se vor pune

la dispoziţie bazele de date originale care vor putea fi operate cu ajutorul unui

program de simulare.

TRAIN.12 După punerea în funcţiune a sistemului IT este necesar un program de training

post-implementare. Cu ajutorul programului de training post-implementare se asigură

optimizarea administrării sistemului şi procesării intervenţiilor.

9.3.2 Conţinutul programului de training tehnic

Cursuri de bază - În ceea ce priveşte aplicaţia BEMIS se organizează un curs de bază ce

cuprinde aplicaţii UNIX/LINUX/Windows, componente hardware şi reţele. În cadrul acestui

curs sunt predate noţiuni de bază cu privire la sistemele instalate, aplicaţii şi specificaţii.

Scopul cursului este prezentarea sistemelor în asociere cu componentele hardware, sistemele

de operare şi interconexiuni.

TRAIN.13 Curs de bază „Administrare” - cursul se realizează în coordonare cu furnizorii

de componente hardware şi de sisteme de operare şi baze de date. Tematica predată în

cadrul cursului cuprinde:

a. aplicaţii

b. exemple de aplicaţii în cadrul sistemului

c. realizarea configuraţiilor de sistem

d. administrarea sistemului

e. administrarea abonaţilor

f. remedierea defecţiunilor

g. suport service

h. măsuri pentru suport service la distanţă

i. setarea şi modificarea serviciilor de reţea

j. setarea, modificarea şi adaptarea sistemelor hardware

k. instalarea şi administrarea de noi aplicaţii software

l. reguli de protecţie a datelor

m. realizarea de conexiuni de sistem şi de reţea

226 / 234

n. implementarea soluţiilor de backup

o. implementarea măsurilor de siguranţă

TRAIN.14 Curs de bază „Baze de date“ - În cadrul acestui curs sunt prezentate bazele de

date cu diversele relaţii, replicări, administrări şi interogări. Cursul cuprinde de

asemenea exemple de administrare şi prelucrare a datelor. Cursul de bază „Baze de

date“ acoperă următoarele teme:

a. înregistrarea datelor

b. istoricul datelor

c. introducerea de noi înregistrări

d. ştergerea înregistrărilor

e. setarea de filtre pentru evaluări şi statistici

f. integrarea în sistemul de operare

g. integrarea in aplicaţiile SQL, ODBC, interfeţe de import şi export

h. conexiuni

i. replicarea bazei de date

j. administrarea bazei de date

TRAIN.15 Curs de bază „Software BEMIS“- In cadrul cursului de bază „Software

BEMIS“ se vor prezenta specificaţiile aplicaţiilor precum şi aplicaţiile adiţionale.

Cuprinsul cursului se referă la:

a. prezentarea specificaţiilor aplicaţiilor

b. înregistrarea datelor / administrarea datelor

c. setarea şi operarea sistemului

d. prezentarea modulelor program

e. implementarea în sistemul de operare şi în baza de date

f. aplicaţii ale diverselor sisteme pentru pompieri, salvare, măsuri împotriva

producerii de dezastre

g. interfeţe de administrare a datelor

227 / 234

h. setarea de conexiuni logice sub forma de comenzi de alarmare şi decuplare şi

cataloage de măsuri

i. preluarea planurilor existente cu privire la alarmare şi măsuri împotriva

producerii de dezastre

TRAIN.16 Curs de bază „Înregistrarea datelor“ - pentru înregistrarea datelor se realizează

un curs cu o tematică incluzând informaţii şi instrucţiuni pentru colectarea şi

înregistrarea datelor. Cuprinsul cursului se referă la:

a. crearea bazelor de date individuale, gestionarea şi modificarea datelor de

înregistrat

b. realizarea bazelor de date

c. digitalizarea planurilor

d. preluarea datelor în sistem

e. realizarea bazei de date pentru simboluri cu configuraţie liberă

f. exerciţii practice, instrucţiuni şi operare

g. pregătirea listelor de înregistrare a datelor şi a mediilor de stocare

9.3.3 Pregatirea personalului opertiv (dispeceri)

Programul de training pentru dispeceri se realizează pentru mai multe grupe, în funcţie de

programul de lucru. Scopul cursului este asigurarea unei operări eficiente a centrului de

comandă şi control şi a sistemelor de comunicaţii pe baza unui sistem integrat în CMISU.

TRAIN.17 Programul de training este structurat într-un modul training BEMIS, un modul

Training sisteme de comunicaţii şi un modul training operare integrată.

TRAIN.18 Cursul se realizează pe baza datelor înregistrate în sistemul BEMIS. Premisa

pentru realizarea cursului este funcţionalitatea sistemului integrat CMISU. Pentru

programul de training pentru dispeceri se adaugă un program activ de operare de

probă cu suportul de specialitate al realizatorului CMISU.

TRAIN.19 Desfăşurarea programelor de training se va stabili în detaliu în funcţie de

locaţie.

10 Documentatie

DOC.1 Contractorul va avea in vedere realizarea si livrarea urmatoarelor documentatii:

228 / 234

a. Manualul administratorului de sistem

b. Manualul supervizorului de sistem

c. Manualul operatorului de sistem.

d. Manual de operare pentru fiecare tip de utilizatori ai sistemului, care va fi

aprobat de catre reprezentantii Beneficiarului si va fi livrat inainte de testul

SAT. Aceste manuale vor cuprinde cel putin descrierea detaliata a

instructiunilor de operare pentru tot sistemul hardware si software.

e. Manual de intretinere sistem - contractorul va intocmi un Manual de

intretinere in vederea aprobarii de catre reprezentantii Beneficiarului, care va

fi livrat inainte de testul SAT. In Manualul de intretinere vor fi incluse

urmatoarele aspecte:

Descrierea sarcinilor aferente intretinerii ce vor fi indeplinite de catre

personalul desemnat pentru aceasta activitate.

Descrierea detaliata a procedurilor aplicabile sarcinilor de intretinere

anterioara.

f. Manual de reguli de securitate: vor cuprinde cerintele de mediu si cerintele de

protectie a echipamentelor si personalului pe durata manevrarii acestor

elemente implicate in sarcinile de intretinere

DOC.2 Toate documentatiile si manualele vor fi livrate in limba romana, in 2 (doua)

exemplare fizice (tiparite) si 2 (doua) CD-uri cu documentatia in format electronic.

11 Garantie, suport si mentenanta

11.1 Garantie

GAR.1 Contractantul va asigura o perioada de garantie pentru intregul sistem, in

ansamblu, pe o perioada de cel putin 12 luni calendaristice de la data acceptantei

finale.

GAR.2 Pe durata perioadei de garantie si intretinere, Contractorul va rezolva imediat si

gratuit toate viciile ascunse identificate in sistem si va repara erorile pe care le-ar

putea avea sistemul.

GAR.3 Aceasta etapa se va incheia cu Raportul de incheiere a perioadei de garantie, care

va trebui sa rezume:

229 / 234

a. Starea generala a sistemului.

b. Incidentele identificate pe durata perioadei de garantie si intretinere.

c. Actiunile intreprinse in aceasta perioada.

d. Activitati in curs de rezolvare (reparatii in curs).

e. Probleme si actiunii propuse pentru intretinerea viitoare.

f. Starea stocului de piese de schimb.

GAR.4 In primele 6 luni de la incheierea acestei etape, Contractorul va putea emite o

propunere de intretinere a sistemului dupa ce perioada de garantie a expirat, avand in

vedere diferite alternative si costurile implicate.

GAR.5 Pe perioada de garantie, Contractorul va fi responsabil cu executarea sarcinilor

listate in paragrafele urmatoare, ca parte a furnizarii incluse in contract.

GAR.6 In cazul aparitiei unei disfunctii sau intreruperi, aceasta va fi izolata intr-un mod

care sa permita operarea restului sistemului, pana la momentul in care intreruperea

este rezolvata. Se presupune ca, in contextul Caietului de sarcini, operabilitatea se

refera la conditiile care permit ca sistemul sa isi desfasoare misiunea pe care o are.

GAR.7 Contractorul va fi responsabil pentru repararea tuturor intreruperilor si

disfunctiilor, in cel mai scurt timp, indiferent de conditiile externe. In cazul unei

intreruperi, Administratorul in functie va decide daca Sistemul se afla in conditii de

inoperabilitate.

GAR.8 Nevoia proiectarii unui echipament non-comercial va tinde sa se reduca. Partea

esentiala hardware a echipamentului va fi comerciala, cu fezabilitatea si posibilitatea

de intretinere exprimata in conformitate cu urmatorii parametri:

a. MTBF (Timpul mediu dintre disfunctii).

b. MTBCMA (Timpul mediu dintre actiunile corective de mentenanta).

c. MTTR (Timpul mediu de reparare)

GAR.9 Valorile MTBF, MTBCMA si MTTR se vor determina in conformitate cu

standardele internationale IEC/TR 62380 sau MIL-HDBK-217F sau MIL-HDBK-472

sau alte standarde echivalente.

11.2 Servicii de intretinere

230 / 234

MNT.1 Contractorul va asigura, in perioada de garantie, toate operatiunile de mentenanta

necesare asigurarii bunei functionari a sistemului in ansamblu.

MNT.2 Dupa incheierea perioadei de garantie, Contractorul va emite o propunere de

colaborare, in conditii comerciale corecte si care vor fi negociate de parti, privitoare la

asigurarea mentenantei sistemului. Aceasta colaborare va fi realizata in baza unui

contract ce va fi intocmit ulterior, prin vointa partilor, si care nu face obiectul

prezentului caiet de sarcini.

MNT.3 La realizarea lucrariilor si a actiunilor de intretinere, Contractorul va fi

raspunzator pentru:

a. Toate costurile aferente dezvoltarii adecvate a activitatilor (cheltuieli de

calatorie, cazare, subzistenta etc.) implicate de catre personalul acestuia.

b. Personalul Contractorului si producatorului, mijloace, echipamente si

transportul pieselor de schimb catre diferite locatii ale sistemului.

c. Toate costurile asociate cu personalul (salarii, taxe, asigurare sociala) si

asigurarile aferente (asigurarea civila, asigurarea impotriva daunelor

echipamentului, accidente si deces).

d. Oferirea mijloacelor necesare, instruire si certificate pentru personalul propriu

si adaptarea facilitatilor existente pentru asigurarea securitatii persoanelor in

conformitate cu legislatia din Romania.

11.3 Servicii de support

11.3.1 Generalitati

SUP.1 Tehnicineii vor fi raspunzatori pentru executarea urmatoarelor activitati in diferite

locatii ale sistemului:

a. Protocoale de intretinere preventiva recomandate de catre producatori,

comercianti si furnizori, cu o periodicitte stabilita.

b. Intretinere software si aducere la zi.

c. Diagnoza disfunctii, inlocuire si reparatii la nivel de inlocuire a unitatiilor

identificate ca defecte.

d. Echipament auxiliar suport (unelte, echipament de testare etc.) pentru sarcinile

de intretinere.

SUP.2 Sarcini de management de intretinere generala:

231 / 234

a. Trimiterea materialului catre producatori in vederea repararii si primirea

materialului de la producatori dupa efectuarea reparatiilor.

b. Servicii auxiliare de inchiriere, atunci cand aceasta este necesara in vedere

desfasurarii de activitati de intretinere.

c. Controlul pieselor de schimb si stocului de consumabile.

SUP.3 Tehnicienii vor avea la dispozitie toate instrumentele necesare, echipamentele de

testare si mijloacele necesare desfasurarii activitatilor respective.

SUP.4 Ofertantul va pune la dispozitie un expert hardware, absolvent de studii

superioare în domeniul IT&C, cu certificare profesională în administrarea

sistemelor informatice emisă de către producători de platforme informatice

recunoscuţi la nivel mondial (MCSA sau echivalent), certificare profesională în

profesia de inginer de sistem emisă de către producători de platforme informatice

recunoscuţi la nivel mondial (MCSE sau echivalent), certificare profesionala in

asigurarea securitatii sistemelor informatice emisa de catre producatori de

platforme informatice recunoscuti la nivel mondial (MCSE: Security sau

echivalent). Expertul trebuie sa detina competenţe de nivel avansat privind auditul

sistemelor informatice (dovedite prin certificate cum ar fi Certified Information

System Auditor – CISA sau echivalent) si sa detina o certificare tehnologica

avansata precum MCM: Windows server r2 2008 directory sau echivalent.

11.3.2 Suport telefonic permanent (tip “Call-center “)

SUP.5 Un serviciu de call-center va fi oferit de catre Contractor pe durata a 24 de ore pe

zi, 365 de zile pe an, in vederea receptarii alertelor de disfunctii si nefunctionari si

activarii serviciilor de suport logistic in vederea rezolvarii acestora.

SUP.6 Call-center-ul va oferi, de asemenea, consultanta directa in cazul unor probleme,

prin suport telefonic si conexiune la distanta la sistemul de informatii al

Beneficiarului si al Contractorului.

11.3.3 Aplicatie software pentru gestiunea incidentelor

Pentru gestionarea tuturor incidentelor si a tichetelor generate de acest proiect de mentenanta,

ofertantul trebuie sa puna la dispozitia autoritatii contractante o aplicatie software de

gestionare a incidentelor, care sa poata fi folosita de cel putin 400 de utilizatori cu

urmatoarele caracteristici:

INCD.1 inregistrarea solicitarilor de suport si alocarea unui identificator unic fiecarei

solicitari;

INCD.2 posibilitatea de definire a unor categorii de apeluri de asistenta;

INCD.3 posibilitatea de definire si de incadrare a solicitarilor in categorii: defect,

eroare, solicitare de informatii, cerere de schimbare.

232 / 234

INCD.4 posibilitatea de inregistrare a datelor de identificare ale apelantului - include

atribuirea incidentului unei persoane care raporteaza in aplicatia software (inginerul

de suport al Call Center), persoana care solutioneaza incidentul (de la orice nivel),

persoana care a raportat un incident. Toate datele prezente aici includ atat date

personale, cat si date de contact, activitate curenta etc., aceasta aplicatie putand fi

personalizata sa primeasca detalii diferite pentru aceste puncte de reper in mod diferit

si definit in totalitate de catre un administrator de aplicatie.

INCD.5 posibilitatea de alocare a unui criteriu de urgenta. Aplicatia software sa

permita clasificarea incidentelor in functie de tipul stabilit in SLA, putand sa emita

notificari pe mail privind alocarea incidentelor catre persoanele implicate in incident.

INCD.6 posibilitatea de alocare automata a unor coduri de incident care sa indice cauza

probabila a incidentului. Aplicatia software sa aloce coduri unice fiecarui incident.

Aplicatia software sa permita de asemenea si gruparea pe module a incidentelor.

INCD.7 posibilitatea de gestionare a informatiilor despre personalul de suport caruia i

se pot aloca spre rezolvare incidentele. Aplicatia software contine implicit toate datele

de contact si deci persoanele, care pot fi considerate alocabile sau care pot aloca un

incident. Aceste date pot fi folosite in mod facil in cazul unui audit.

INCD.8 inregistrarea automata a datei si a orei primirii unei solicitari de asistenta.

INCD.9 posibilitatea de definire a criteriilor de calitate si performanta (SLA) pentru

rezolvarea diferitelor categorii de solicitari de asistenta.

INCD.10 posibilitatea de atentionare automata in momentul depasirii unor praguri

temporale de rezolvare a diferitelor categorii de solicitari de asistenta.

INCD.11 posibilitatea de definire a unor fluxuri de evolutie a solicitarilor de suport, in

cazul in care ele trec prin mai multe nivele de competenta pana in momentul

finalizarii.

INCD.12 posibilitatea de escaladare a cererilor de suport.

INCD.13 posibilitatea de inregistrare a datelor de contact pentru responsabilii pentru

activitatile de suport de nivel 1, 2 si 3 pentru diferitele componente ale sistemului

informatic.

INCD.14 posibilitatea de definire a unor rapoarte personalizate folosind criterii cum ar

fi: tipul de incident, nivelul de urgenta, timpul de rezolvare, persoana si locatia de

unde a fost semnalat un incident, modulul sau functia care a cauzat incidentul,

numarul de incidente pentru care nu s-au respectat criteriile din SLA etc.

INCD.15 sa permita in orice moment accesul la baza de date a personalului autorizat al

sistemului pentru verificarea modului de tratare a incidentelor si pentru rularea de

rapoarte de performanta a serviciului de Call Center. Accesul se va face numai pentru

citire si nu va fi conditionat in niciun fel de catre operatorii sau administratorii

serviciului.

11.3.4 Suport avansat

SUP.7 Contractorul va achizitiona mijloacele necesare, facilitatile si echipamentul pentru

efectuarea sarcinilor de intretinere in Romania;

233 / 234

SUP.8 In acest context, urmatoarele concepte de nivel “O”, “I” si “D” de intretinere se

presupun a fi:

a. Nivelul “O”: acele sarcini care pot fi indeplinite la fata locului, ca de exemplu

inlocuirea la nivel de unitate functionala si executarea de protocoale de

intretinere preventiva.

b. Nivelul “I”: acele sarcini care nu pot fi desfasurate la fata locului, dar care ar

putea fi efectutate in laboratoare adecvate (locale) si de catre tehnicieni

instruiti de producator.

c. Nivelul “D”: acele activitati care nu pot fi desfasurate decat la locatiile

producatorilor

11.3.5 Calitatea serviciului

SUP.9 Timp de reactie: nu mai mare de 12 ore in cel mai rau caz. In acest sens, este de la

sine inteles ca timpul de reactie este timpul scurs intre avertizarea prin alarma si

inceperea efectiva a operatiunilor de intretinere de la fata locului.

SUP.10 Timp de reparare - in acest sens, se presupune ca timpul de reparare este perioada

de timp scursa de la inceperea actiunilor de intretinere si recuperarea completa a

operarii normale si repararea pieselor disfunctionale ale sistemului.

a. Pentru reparatii la nivel de Contractor, daca nu sunt necesare piese de schimb

iar lucrarea poate fi efectuata la fata locului timpul va fi de sub 3 zile / daca

sunt necesare piese de schimb, care se afla in stoc sau daca lucrarilor nu pot fi

efectuate la fata locului: sub 1 saptamana (reparatii nivel “O” sau “I”) / daca

sunt necesare piese de schimb, dar nu se afla pe stoc: 2 luni in cel mai rau caz.

b. Pentru reparatii nivel de producator: daca nu sunt necesare piese de schimb

sau daca acestea se afla pe stoc: 1 luna / daca sunt necesare piese de schimb,

dar acestea nu se afla pe stoc: 3 luni in cel mai rau caz.

c. In cazul unei nefunctionari care nu implica stare de inoperabilitate, timpul

maxim de reparare va fi de 3 luni.

Specificatiile tehnice definite in cadrul prezentului caiet de sarcini corespund

necesitatilor si exigentelor autoritatii contractante. Avand in vedere

particularitatile acestui proiect, autoritatea a descris necesarul de livrabile si

servicii la un nivel de detaliu necesar operatorilor economici interesati, permitand

identificarea obiectului acestui contract de achizitie publica. In acest sens, toate

234 / 234

specificatiile, serviciile si cerintele mentionate si solicitate in cadrul acestui caiet

de sarcini sunt insotite de mentiunea „sau echivalent”.

În scopul evaluării conformităţii propunerilor tehnice cu cerinţele din prezentul

caiet de sarcini, pentru produsele IT solicitate, ofertantul va completa Formularul

Nr. 18 din sectiunea formulare – Tabel detalii producator.

82303890 Final Caiet de Sarcini v7

Documents

Transcript of 82303890 Final Caiet de Sarcini v7