Caiet de Sarcini

1

DOCUMENTAłIE DE ATRIBUIRE

Pentru procedura de achizitie publica – licitatie deschisa – a contractului de furnizare:

„Supervizare si control colectare date (SCADA)”

Volumul 3. Specificatii tehnice

Sectiunea 3.1 Cerintele Angajatorului (Caiet de sarcini)

2

1 Prezentare S.C. Compania de Apa Olt S.A.............................................................. 7

1.1 1.1 Incadrare in profilul de servicii furnizate populatiei....................................... 7

1.2 1.2 Obiectivele strategice ale S.C. Compania de Apa Olt S.A. .......................... 7

2 Scopul Caietului de Sarcini ...................................................................................... 9

2.1 Metodologia de derulare a activitatilor de analiza si proiectare........................ 10

2.2 Instrumente de lucru folosite ............................................................................ 10

2.3 Terminologie adoptata...................................................................................... 10

2.4 Considerente care trebuie vizate de ofertant in cadrul proiectarii sistemului

ofertat ........................................................................................................................ 11

3 Introducere............................................................................................................. 14

3.1 Generalitati....................................................................................................... 14

4 Definirea Proiectului ............................................................................................... 17

4.1 Obiectivul Proiectului........................................................................................ 17

4.2 Datele de plecare pentru realizarea proiectului ................................................ 17

5 Situatia contractelor de lucrari aflate in derulare .................................................... 18

5.1 Contracte de lucrari pe activitatile de productie, distributie si tratare ............... 18

5.1.1 Zona Metropolitana SLATINA.................................................................... 18

5.1.2 Aglomerarea POTCOAVA ......................................................................... 25

5.1.3 Aglomerarea DRAGANESTI-OLT.............................................................. 27

5.1.4 Aglomerarea PIATRA-OLT........................................................................ 29

5.1.5 Aglomerarea SCORNICESTI..................................................................... 30

5.2 Contracte de lucrari pe activitatea de debitmetrie / telemetrie de retea ........... 31

5.2.1 Lucrări specifice pe partea electrică şi de automatizări ............................. 32

5.3 Sinteza conditiilor de plecare in vederea realizarii proiectului .......................... 34

6 Descrierea a sistemului regional de dispecerizare SCADA-DTR ........................... 38

6.1 Generalitati....................................................................................................... 38

6.2 Functiile sistemului SCADA-DTR ..................................................................... 39

6.2.1 Functii cu caracter general ........................................................................ 39

6.2.2 Informatii minimale furnizate de sistem...................................................... 40

6.2.3 Modul de prezentare al informatiilor .......................................................... 40

6.3 Principalii parametrii monitorizati...................................................................... 41

Cuprins

3

6.3.1 Activitatea de distributie apa potabila, statii de pompare, tratare apa........ 41

6.3.2 Activitatea de canalizare............................................................................ 42

6.3.3 Activitatea de Epurare ............................................................................... 43

6.4 Obiectivele proiectului – rezumat ..................................................................... 43

6.5 Cerinte – solutii ................................................................................................ 45

6.5.1 Cerinte generale ce trebuie indeplinite de catre solutiile ofertate .............. 45

6.5.2 Cerinte specifice ........................................................................................ 46

6.5.3 Arhitectura Dispeceratului de Telecontrol Regional................................... 47

6.5.4 Modul de routare al informatiei prelevate de la nivelul procesului ............. 47

6.6 Cerinte Hardware ale sistemului SCADA-DTR................................................. 49

6.7 Cerinte ale camerei Dispeceratului de Telecontrol Regional............................ 52

6.7.1 Modul de amplasare al mobilierului şi al echipamentelor de operator

aferente sistemului SCADA de Dispecer................................................................ 52

6.7.2 Amplasarea echipamntelor de calcul si retelistica in dulapul de

echipamente........................................................................................................... 53

6.8 Cerinte Software ale sistemului SCADA-DTR.................................................. 55

6.8.1 Cerinte de baza ......................................................................................... 55

6.8.2 Mediul de dezvoltare.................................................................................. 57

6.8.3 Editorul Grafic............................................................................................ 60

6.8.4 Software-ul de aplicatie (SCADA).............................................................. 61

6.8.5 Mecanismul de gestionare a alarmelor ...................................................... 64

6.8.6 Platforma SCADA. Interactiunea GUI cu operatorul. ................................. 64

6.8.7 Nivele de selectie al controlului autoritatii. ................................................. 70

6.8.8 Capabilitati si Functiuni – Platforma SCADA. Module software specifice. . 72

6.8.9 Comunicatii / Drivere ................................................................................. 78

6.8.10 Licente ....................................................................................................... 78

6.8.11 Modul de interactiune al software-ului platformei SCADA cu aplicatiile de

GIS si Modelare Hidraulica .................................................................................... 78

6.8.11.1 Consideratii generale asupra software-ului de Modelare Hidraulica –

Mike Urban............................................................................................................ 78

6.9 Cerinte pentru comunicatiile de date................................................................ 80

6.9.1 Conceptul de Comunicatii.......................................................................... 80

6.10 Conceptul sincronizarii de timp (stabilirea timpului de referinta) ................... 82

6.10.1 Sincronizarea in cadrul sistemului central SCADA-DTR............................ 82

6.10.2 Sincronizarea in cadrul punctelor de achizitie a datelor............................. 83

4

6.10.3 Echipament Hardware ............................................................................... 83

6.10.4 Functii ale sistemului de sincronizare ........................................................ 83

6.10.5 Functii de sincronizare a timpului global. Comutarea zonelor orare. ......... 84

6.11 Conceptul de Redundanta ............................................................................ 85

6.12 Conceptul de Deschidere si Interoperabilitate al sistemului.......................... 86

7 Securitatea Informatiei ........................................................................................... 88

7.1 Cerinte de Securitate a Informatiei ................................................................... 88

7.1.1 Coduri de Securitate.................................................................................. 88

7.1.2 Grupuri de utilizatori................................................................................... 88

7.1.3 Operator .................................................................................................... 88

7.1.4 Inginer de sistem ....................................................................................... 88

7.1.5 Administrator ............................................................................................. 89

7.1.6 ConsideraŃii generale de securitate ........................................................... 89

7.2 Cerinte de Proiectare ....................................................................................... 89

7.2.1 Documentatia de proiect............................................................................ 90

7.3 Cerinte de Livrare............................................................................................. 90

7.3.1 Obligatii pentru Livrare:.............................................................................. 91

7.3.2 Documentatia de livrare............................................................................. 91

7.3.3 Data de livrare a documentatiei ................................................................. 91

7.3.4 Livrarea, indeplinirea, preluarea, transferul riscurilor si transferul proprietatii

92

7.4 Cerinte de Asamblare, Instalare si Punere in Functiune .................................. 93

7.4.1 Servicii oferite de Beneficiar ...................................................................... 93

7.4.2 Conceptul punerii in functiune ................................................................... 93

7.5 Cerinte de Testare ........................................................................................... 95

7.5.1 Modul de testare........................................................................................ 95

7.5.2 Perioada operatiilor de testare................................................................... 95

7.5.3 Durata testelor ........................................................................................... 96

7.5.4 Intreruperea testelor .................................................................................. 96

7.5.5 Incetarea testelor....................................................................................... 96

7.5.6 Mediul de testare ....................................................................................... 97

7.6 Cerinte de Instruire........................................................................................... 97

7.6.1 CerinŃe privind Şcolarizarea Personalului de Exploatare........................... 98

7.6.2 CerinŃe privind Şcolarizarea Personalului TESA dedicat Informaticii de

Proces (IP) ............................................................................................................. 98

5

8 Continutul Ofertei ................................................................................................. 101

8.1 Modul de prezentare si continutul ofertei........................................................ 101

8.2 Oferta Tehnica ............................................................................................... 102

8.3 Fisele Tehnice ale Echipamentelor ................................................................ 102

8.4 Metodologie.................................................................................................... 103

8.5 Declaratii ale ofertantului................................................................................ 103

8.6 Echipa de Proiect ........................................................................................... 106

8.7 Lista de Activitati Inclusa in Graficul de Implementare ................................... 106

9 Rapoarte ale Proiectului....................................................................................... 110

9.1 Cerinte privind raportarea............................................................................... 110

9.2 Depunerea si Aprobarea Rapoartelor ............................................................ 110

9.3 Monitorizarea Proiectului................................................................................ 111

9.4 Documentatia de Proiect ................................................................................ 111

9.5 Livrarea .......................................................................................................... 112

9.6 Asamblarea si Instalarea................................................................................ 113

9.7 Servicii Oferite de Beneficiar .......................................................................... 113

9.8 Securitatea Muncii.......................................................................................... 113

9.9 Mecanismul Cooperarii................................................................................... 114

10 Lista Standardelor................................................................................................ 115

11 Abrevieri............................................................................................................... 118

7

1 PREZENTARE S.C. COMPANIA DE APA OLT S.A.

1.1 1.1 Incadrare in profilul de servicii furnizate populatiei

S.C. Compania de Apa Olt S.A. este principalul operator al

judetului Olt in domeniul apa, canal, epurare.

S.C. Compania de Apã Olt S.A. opereazã în Municipiul

Slatina și orașele: Drãgãnești-Olt, Scornicești, Piatra-Olt

și Potcoava. JudeŃul are o populatie de: 465.019 locuitori

(2010) și o suprafaŃã de 5.507 km², Operatorul Regional,

la nivelul anului 2010, deservind o populatie totala de

116.147 locuitori, dupa cum urmeaza:

• Slatina – 78.815 locuitori, aductiune 33,2 km, o

reŃea de apã de 133,372 km și canal 106,12 km (inclusiv extindere);

• Drãgãnești-Olt – 12.195 locuitori, aductiune 5 km, o reŃea de apã de 29,652km

și canal de 14,5 km (inclusiv extindere);

• Scornicești – 12.679 locuitori aductiune 3,8 km, o reŃea de apã de 27,8 km și

canal de 14,5 km (inclusiv extindere);

• Piatra-Olt – 6.347 locuitori aductiune 1,7 km, o reŃea de apã de 41,9 km și canal

de 7,7 km (inclusiv extindere);

• Potcoava – 6.111 locuitori aductiune 2,87 km, o reŃea de apã de 17,2 km și

canal de 6,6 km (inclusiv extindere);

ActivitãŃile principale ale S.C. CAO S.A. sunt: captarea, tratarea și distribuŃia apei

precum și colectarea și epurarea apelor uzate în Municipiul Slatina și cele 4 orașe

(aglomerari urbane): Scornicești, Drãgãnești-Olt, Piatra-Olt și Potcoava.

Apa este preluatã din surse subterane, puŃuri de mare și medie adancime 50-120m

(exceptie facand Piatra-Olt, care are asigurata sursa de alimentare cu apa din SP

Salcia – administrare sediu secundar Slatina);

1.2 1.2 Obiectivele strategice ale S.C. Compania de Apa Olt S.A.

Principalele obiective strategice ale SC Compania de Apa Olt S.A. sunt:

1. Asigurarea furnizării continue a apei la o calitate conformă cu standardele

naŃionale şi europene.

8

2. Asigurarea calităŃii apelor uzate epurate evacuate din staŃiile de epurare conform

NTPA 11/2005.

3. Asigurarea furnizării continue a serviciilor de canalizare a apelor uzate;

4. MenŃinerea şi îmbunătăŃirea continuă a Sistemului de Management Integrat

Calitate, ProtecŃia Mediului, Sănătate şi Securitate OcupaŃională, conform

standardelor ISO 9001, ISO 14001 şi OH SAS 18001;

5. MenŃinerea orientării activităŃii companiei către clienŃi;

6. Contorizarea integrală a consumatorilor deserviŃi de Compania de Apă Olt S.A.;

7. Creşterea volumului surselor atrase pentru investiŃii în infrastructura de apă şi

apă uzată.

8. Reducerea consumului şi a cheltuielilor cu energia electrică.

9. Lărgirea ariei de operare prin cooptarea altor localităŃi în cadrul operatorului

regional.

10. Valorificarea nămolurilor din staŃiile de epurare, rezultate în urma epurării apelor

uzate.

9

2 SCOPUL CAIETULUI DE SARCINI

Caietul de Sarcini cuprinde cerintele minime necesare pentru amenajarea şi dotarea

unui Dispecerat de Telecontrol Regional (DTR), in cadrul S.C. Compania de Apa Olt

S.A., pentru monitorizarea unor parametri de baza aferenti sistemelor de alimentare cu

apa si canalizare, din cele cinci aglomerari urbane din judetul Olt administrate de catre

Operatorul Regional. Suplimentar sistemul SCADA Regional trebuie sa ofere facilitatile

necesare realizarii unei gestiuni performante a activitatilor si activelor Companiei de

Apa precum si instruirea necesara Beneficiarului in vederea utilizarii sistemului

implementat.

Acest obiectiv se va realiza in mod concret prin achizitia, instalarea, verificarea si

punerea in functiune a unui sistem informatic de proces – SCADA Regional, in cadrul

S.C. Compania de Apa Olt S.A., cu ajutorul caruia sa poata fi realizat telecontrolul si

supervizarea sistemelor de alimentare cu apa (inclusiv a telemetriei de retea) si

canalizare din aria proiectului.

Ofertantul trebuie sa prezinte in oferta tehnica o descriere in detaliu (amanuntita) a

metodologiei dupa care se vor derula activitatile de analiza si proiectare. De asemenea,

ofertantul trebuie sa prezinte procedurile si instructiunile de lucru de analiza si

proiectare implementate in cadrul propriei organizatii.

Instrumentele utilizate in descrierea ofertantului vor trebui sa poata asigura:

• colectarea si evidentierea cerintelor;

• acoperirea integrala a tematicii proiectului;

• trasabilitatea cerintelor pornind de la obiectivele proiectului pana la specificatiile

tehnice;

• modelarea proceselor si activitatilor in conformitate cu standarde de modelare si

reprezentare recunoscute.

Ofertantul va prezenta detaliat livrabilele care vor rezulta in urma prestarii serviciilor

corespunzatoare etapelor de analiza si proiectare. Descrierea va trebui sa contina

urmatoarele informatii:

• formularul/formularele care va fi utilizate pentru fiecare livrabil;

• descrierea continutului fiecarui livrabil;

• modul in care va fi interpretat continutul livrabilelor

10

2.1 Metodologia de derulare a activitatilor de analiza si proiectare

Metodologia de lucru presupune parcurgerea ciclului de viata al sistemului

informational, cuprinzând urmatoarele obiective:

• activitatile specifice fiecarei etape;

• procedurile si regulile care se aplica in fiecare etapa;

• standardele asociate fiecarei activitati;

• metodele, tehnicile si instrumentele utilizate in realizarea diferitelor activitati si

etape.

Metodologia de realizare si dezvoltare a sistemului informational reprezinta in sine o

colectie de metode, una sau mai multe, pentru fiecare activitate desfasurata in cadrul

unei etape a proiectului de realizare si dezvoltare. Unele metodologii sunt asociate cu

tehnologii specifice, pe când altele reflecta diferite abordari conceptuale in dezvoltarea

sistemelor.

2.2 Instrumente de lucru folosite

Instrumentele folosite de catre Ofertant pentru desfasurarea activitatilor de analiza si

proiectare sunt instrumente ce trebuie sa asigure:

• colectarea si evidentierea cerintelor;

• acoperirea integrala a tematicii proiectului;

• evidentierea modificarilor cerintelor

• trasabilitatea cerintelor pornind de la obiectivele proiectului pana la specificatiile

tehnice;

• modelarea proceselor si activitatilor in conformitate cu standarde de modelare si

reprezentare recunoscute.

2.3 Terminologie adoptata

Pentru a respecta „conceptul SCADA”, definit in Studiul de Fezabilitate aferent acestui

contract de furnizare, se va adopta in cuprinsul caietului de sarcini urmatoarea

terminologie:

o Entitate „Server” de dispecer (descris in studiul de fezabilitate) – Sistem Informatic

de Proces (SIP) implementat la nivelul Dispeceratului de Telecontrol Regional, care

reprezinta totalitatea echipamentelor informatice si a dispozitivelor de retelistica si

comunicatie care constituie sistemul SCADA-DTR.

11

o Echipamentele „PLC” (descrise in studiul de fezabilitate) – reprezinta punctele locale

de achizitie a datelor sau sistemele SCADA locale care deservesc activitatile

specifice de productie si telemetrie de retea.

2.4 Considerente care trebuie vizate de ofertant in cadrul proiectarii

sistemului ofertat

Proiectarea sistemului informatic de proces (sistemul SCADA-DTR) ce urmeaza a fi

implementat in cadrul Dispeceratului Regional al S.C. Compania de Apa Olt S.A. este

etapa de baza care va consta in stabilirea arhitecturii si a structurii sistemului, atat la

nivel fizic cat si logic, in conformitate cu specificatiile si cerintele rezultate din faza de

analiza a CS, astfel incât sa fie indeplinite toate obiectivele urmarite.

Proiectantul de sistem (ofertantul) va avea obligatia de a detalia cerintele si specificatiile

rezultate din faza de analiza, pentru toate nivelurile si componentele sistemului care va

fi proiectat si ulterior realizat si implementat.

Principalele tipuri de specificatii care sunt definite in faza de proiectare se refera la:

• iesirile sistemului (mediul pe care apar, continutul lor si timpul la care apar);

• intrarile in sistem (originea/sursa intrarilor, fluxul parcurs de intrari si modul de

introducere si preluare al acestor intrari);

12

• interfetele cu utilizatorii (simplitate, eficienta, logica relatiei om – masina, reactia

inversa (feedback) si tratarea erorilor in operare);

• proiectarea fisierelor si a bazei / bazelor de date (structurarea datelor ca logica si

relatii, volumul si timpul de raspuns, specificatiile pentru inregistrari);

• prelucrarea datelor (proceduri de prelucrare, modulele de programe, cerintele de

raportari si timpul de raspuns etc.)

• definirea procedurilor manuale in prelucrarea si urmarirea fluxurilor de date si

informatii (ce activitati, cine le realizeaza, când, cum si unde);

• definirea operatiunilor de control pentru diferite tipuri de operatii:

o de intrare (caractere, limite etc.);

o de prelucrare (consistenta, gestiunea inregistrarilor);

o de iesire (totaluri, esantioane, etc.);

o procedurale (forme speciale, cuvinte de acces etc.);

o de evaluare a performantelor in raport cu anumite standarde de referinta.

• definirea operatiunilor de securitate, privind controlul accesului, planurile pentru

situatii de exceptie, auditul de urmarire.

• documentarea pentru operarea sistemului si pentru utilizatori.

• conversia la noul sistem, care se refera la transferul de fisiere, initierea si

definirea unor proceduri noi, selectarea metodelor de testare pentru noul sistem,

modul de trecere efectiva la utilizarea noului sistem.

• instruirea, care presupune pregatirea personalului care va utiliza noul sistem,

alegerea metodei de instruire, realizarea modulelor de instruire si definirea

facilitatilor care vor fi utilizate in instruire.

• schimbarile organizatorice presupuse de implementarea noului sistem, prin

proiectarea fiselor posturilor de lucru (job design), a activitatilor, proceselor si

structurii organizatorice (compartimente si conexiunile dintre ele), precum si toate

corelatiile presupuse de aceasta structura.

W1

Pentru cuantificarea obiectiva a acestei sectiuni, ofertantul va trebui sa detalieze

viziunea proprie privitoare la modalitatea de proiectare a sistemului informatic de

proces, axata pe cele 2 planuri si anume: proiectarea logica si proiectarea fizica.

14

3 INTRODUCERE

3.1 Generalitati

Acest caiet de sarcini sumarizeaza cerintele hardware si software, pentru noul sistem

SCADA – DTR ce urmeaza a fi achizitionat si implementat de catre S.C. Compania de

Apa Olt S.A.

Scopul acestui document este de a specifica conceptul sistemului informatic de proces

precum si cerintele tehnice pentru dispozitivele si modulele ce alcatuiesc sistemul

SCADA, faptul ca sunt conforme cu standardele tehnice actuale si ca aceste dispozitive

prezinta o baza buna pentru dezvoltarea sistemului in urmatorii 10 ani, asa cum poate fi

prevazut la acest moment.

S.C. Compania de Apa Olt S.A. este principalul operator al judetului Olt in domeniul

apa, canal, epurare si opereazã în Municipiul Slatina și orașele: Drãgãnești-Olt,

Scornicești, Piatra-Olt și Potcoava.

In prezent se afla in faza de implementare un proiect cu cofinantare UE, in vederea

reabilitării generale a infrastructurii de alimentare cu apă şi canalizare din Regiunea

oraselor: Slatina, Drãgãnești-Olt, Scornicești, Piatra-Olt și Potcoava din JudeŃul Olt.

Principalele activităŃi ale S.C. Compania de Apa Olt S.A. (OR) si prin urmare, procesele

ce urmeaza a fi integrate, controlate si supervizate din Dispeceratul de Telecontrol

Regional sunt: productia si distributia de apa potabila si colectarea şi epurarea apelor

uzate.

Activitatea companiei cuprinsă în acest proiect, se va desfăşura în aria regiunii formate

din oraşele:

o Slatina,

o Draganesti-Olt,

o Scornicesti,

o Piatra-Olt,

o Potcoava.

În ceea ce priveşte activitatea de întreŃinere şi reparaŃii, OR a realizat o strategie pe

termen scurt şi mediu. Majoritatea activităŃilor de întreŃinere şi reparaŃii sunt si vor fi

coordonate de la sediul central, acolo fiind localizate echipele mobile de intretinere si

intervantie impreuna cu principalele echipamente de interventie.

17

4 DEFINIREA PROIECTULUI

4.1 Obiectivul Proiectului

In conformitate cu cerinŃele specifice ale Caietului de Sarcini, obiectivul general de

îndeplinit il reprezinta implementarea unei solutii integrate tip SCADA Regional, care sa

permita managementul centralizat al informatiilor colectate din sistemele de alimentare

cu apa si canalizare din 5 orase ale regiunii, si sa ofere facilitatile necesare realizarii

unei gestiuni performante ale activitatilor si activelor companiei de apa.

Acest obiectiv se va realiza prin amenajarea, dotarea, instalarea, verificarea si punerea

in functiune a unui Dispecerat de Telecontrol Regional (DTR), in cadrul S.C. Compania

de Apa Olt S.A., cu ajutorul caruia sa poata fi realizat controlul si supervizarea

sistemelor de alimentare cu apa (inclusiv a telemetriei de retea/debitmetrie) si

canalizare din aria proiectului, o gestiune performanta a activitatilor si activelor

companiei, precum si instruirea necesara Beneficiarului in vederea utilizarii si exploatarii

eficiente a sistemului astfel implementat.

4.2 Datele de plecare pentru realizarea proiectului

Dispeceratul de Telecontrol Regional, din cadrul S.C. Compania de Apa Olt S.A., va

realiza controlul si supervizarea sistemelor de alimentare cu apa (productie apa si

telemetrie de retea) si canalizare din 5 localitati ale regiunii enumerate anterior.

In prezent, se afla in derulare, in fiecare dintre aceste localitati, o serie de contracte de

lucrari, la finalul carora vor fi realizate sistemele de supervizare si control SCADA ale

productiei de apa si ale epurarii si vor fi instalate puncte de monitorizare debit si

presiune prevazute cu debitmetre cu transmisie GPRS corespunzatoare telemetriei de

retea din fiecare locatie unde acestea sunt pozitionate. Toate acestea vor fi integrate in

Dispeceratul de Telecontrol Regional, subiect al prezentului caiet de sarcini.

In capitolul urmator vor fi descrise succint lucrarile aflate in derulare, in fiecare din cele

5 localitati ce determina aria proiectului.

18

5 SITUATIA CONTRACTELOR DE LUCRARI AFLATE IN DERULARE

5.1 Contracte de lucrari pe activitatile de productie, distributie si tratare

5.1.1 ZONA METROPOLITANA SLATINA

În conformitate cu Cerin�ele Angajatorului, pentru municipiul Slatina au fost prevăzute

Lucrări la sursele de apă potabilă, tratare apa si retele de alimentare cu apa pentru

următoarele locașii:

• Front captare dreapta, front captare stanga

• stașia Salcia, stașia N. Bălcescu (tr.1), stașia Oituz, staŃia Crişan (tr.2).

• statii hidrofoare (nr buc = 12)

Pentru toate cele 4 staŃii anterior menŃionate în subsidiarul Slatina sunt prevazute pe

contractele de lucrari, realizarea de staŃii de tratare noi dotate cu dispecerate locale de

control (DL). Cu alte cuvinte, la finalizarea contractelor de lucrări vor exista 4

dispecerate locale care vor fi integral preluate în sistemul SCADA-DTR (conf. Anexei 1).

Tot pentru municipiul Slatina sunt prevazute Lucrari la retelele de canalizare si tratare

apa uzata pentru urmatoarele locatii:

• statii pompare ape uzate Gradiste si Pitesti

• statie epurare ape uzate Slatina

Pentru Statia de epurare ape uzate Slatina se va realiza un dispecerat local care va

integra parametrii aferenti procesului de tratare a apei uzate, date care vor fi preluate

integral in sistemul SCADA-DTR (conf. Anexei 1).

DETALIEREA OBIECTIVELOR INTEGRABILE

5.1.1.1 Dispeceratul Local de Tratare SALCIA (DLT SALCIA) va integra

informatia preluata de la urmatoarele obiective (vezi Anexa 1 / Ob.1,

respectiv detalierea in Anexa 1.1):

(a) Statia de tratare si clorinare Salcia impreuna cu debitmetria aferenta

monitorizarii procesului de tratare (vezi Anexa 1.1 / Ob.1);

(b) Fronturile de puturi (captare apa) de pe malul drept al Oltului (vezi Anexa

1.1 / Ob.1);

(c) Debitmetria aferenta retelei de distributie a apei (pentru realizare balanta

apa) (vezi Anexa 1.1 / Ob.2);

(d) Statia de pompare Salcia (vezi Anexa 1.1 / Ob.3);

19

(e) Debitmetria pentru masurarea debitului catre aglomerarea Piatra Olt (vezi

Anexa 1.1 / Ob.4).

Mentiuni

• Obiectivele (a) si (b) se vor integra complet in aplicatia SCADA gestionata de

dispeceratul local de la Salcia, acest lucru fiind realizat prin contractele de

lucrari specifice aflate in derulare.

• Obiectivul (c) se va finaliza in cadrul CL aferent, prin aducerea in cadrul

camerei de comanda a unui tablou de monitorizare al debitelor intrare/iesire

din SP Salcia. Obiectivul (c) este format fizic din 2 debitmetre (cu cablu de

transmitere a datelor – non wireless) si este un obiectiv de tip stand-alone,

nefiind integrat in aplicatia SCADA al DL Salcia, motiv pentru care in vederea

transmiterii in SCADA-DTR a datelor furnizate de acesta ofertantul va

prevedea un echipament de achizitie a datelor de tip PLC la care se adauga

suportul de comunicatie adecvat in vederea transmiterii pe protocol OPC a

datelor obiectivului (c) catre sistemul de dispecer regional SCADA-DTR si

serviciile de inginerie specifice (montare echipamente, configurare, testare

comunicatie cu SCADA-DTR).

• Obiectivul (d) se va finaliza in cadrul CL aferent, prin aducerea in cadrul

camerei de comanda Salcia a unui tablou sinoptic de automatizare (local).

Obiectivul (d) este tot un obiectiv de tip stand-alone, nefiind integrat in

aplicatia SCADA al DL Salcia, motiv pentru care in vederea transmiterii in

SCADA-DTR a datelor furnizate de acesta precum si a controlului procesului

de pompare din SP Salcia din GUI/SCADA-DTR, ofertantul va prevedea un

echipament de achizitie a datelor de tip PLC la care se adauga suportul de

comunicatie adecvat in vederea transmiterii pe protocol OPC a datelor

aferente obiectivului (d) catre sistemul de dispecer regional SCADA-DTR si

serviciile de inginerie specifice (montare echipamente, configurare, mapare

semnale spre/dinspre SCADA-DTR, testare comunicatie cu SCADA-DTR,

etc.).

• Obiectivul (e) se va finaliza in cadrul CL aferent, prin instalarea a 1 buc.

debitmetru folosit pentru masurarea debitului catre aglomerarea Piatra-Olt.

Obiectivul este prevazut cu echipament de tip data logger pentru transmiterea

wireless (via GPRS) a datelor prelevate precum si cu dispozitiv de

comunicatie (modem GPRS). Integrarea obiectivului (e) in SCADA-DTR se va

20

realiza de Integratorul de sistem (ofertant), fiind necesare a fi luate in

considerare (bugetate) lucrarile de inginerie aferente acestei integrari.

5.1.1.2 Dispeceratul Local de Tratare NICOLAE BALCESCU (DLT N.

BALCESCU) va integra informatia preluata de la urmatoarele obiective (vezi

Anexa 1 / Ob.2, respectiv detalierea din Anexa 1.2):

(a) Statia de tratare si clorinare N. Balcescu impreuna cu debitmetria aferenta


(b) Fronturile de puturi (captare apa) de pe malul stang al Oltului, respectiv:

Câmp Zona Nouă, Câmp Vid, Câmp Zona D, Câmp Curtişoara (vezi

Anexa 1.2 / Ob.1);



(d) Statia de pompare N. Balcescu (vezi Anexa 1.2 / Ob.3);

Mentiuni


dispeceratul local de la N. Balcescu, acest lucru fiind realizat prin contractele

de lucrari specifice aflate in derulare.



din SP N. Balcescu. Obiectivul (c) este format fizic din 1 debitmetru (cu cablu

de transmitere a datelor – non wireless) si este un obiectiv de tip stand-alone,

nefiind integrat in aplicatia SCADA al DL N. Balcescu, motiv pentru care in

vederea transmiterii in SCADA-DTR a datelor furnizate de acesta ofertantul

va prevedea un echipament de achizitie a datelor de tip PLC la care se

adauga suportul de comunicatie adecvat in vederea transmiterii pe protocol

OPC a datelor obiectivului (c) catre sistemul de dispecer regional SCADA-

DTR precum si serviciile de inginerie specifice (montare echipamente,

configurare, testare comunicatie cu SCADA-DTR).

• Obiectivul (d) se va finaliza in cadrul CL aferent, prin aducerea in cadrul

camerei de comanda N. Balcescu a unui tablou sinoptic de automatizare

(local). Obiectivul (d) este tot un obiectiv de tip stand-alone, nefiind integrat in

aplicatia SCADA al DL N. Balcescu, motiv pentru care in vederea transmiterii

in SCADA-DTR a datelor furnizate de acesta precum si a controlului

21

procesului de pompare din SP N. Balcescu din GUI/SCADA-DTR, ofertantul

va prevedea un echipament de achizitie a datelor de tip PLC la care se

adauga suportul de comunicatie adecvat in vederea transmiterii pe protocol

OPC a datelor aferente obiectivului (d) catre sistemul de dispecer regional

SCADA-DTR si serviciile de inginerie specifice (montare echipamente,

configurare, mapare semnale spre/dinspre SCADA-DTR, testare comunicatie

cu SCADA-DTR, etc.).

5.1.1.3 Dispeceratul Local de Tratare OITUZ (DLT OITUZ) va integra informatia

preluata de la urmatoarele obiective (vezi Anexa 1 / Ob.3, respectiv

detalierea din Anexa 1.3):

(a) Statia de tratare si clorinare Oituz impreuna cu debitmetria aferenta


(b) Debitmetria aferenta retelei de distributie a apei (pentru realizare balanta


(c) Statia de pompare Oituz (vezi Anexa 1.3 / Ob.3);

Mentiuni

• Obiectivul (a) se va integra complet in aplicatia SCADA gestionata de

dispeceratul local de la Oituz, acest lucru fiind realizat prin contractele de


• Obiectivul (b) se va finaliza in cadrul CL aferent, prin aducerea in cadrul


din SP Oituz. Obiectivul (b) este format fizic din 1 debitmetru (cu cablu de

transmitere a datelor – non wireless) si este un obiectiv de tip stand-alone,

nefiind integrat in aplicatia SCADA al DL Oituz, motiv pentru care in vederea




datelor obiectivului (b) catre sistemul de dispecer regional SCADA-DTR

precum si serviciile de inginerie specifice (montare echipamente, configurare,

testare comunicatie cu SCADA-DTR).


camerei de comanda Oituz a unui tablou sinoptic de automatizare (local).

Obiectivul (c) este tot un obiectiv de tip stand-alone, nefiind integrat in

22

aplicatia SCADA al DL Oituz, motiv pentru care in vederea transmiterii in


de pompare SP Oituz din GUI/SCADA-DTR, ofertantul va prevedea un



aferente obiectivului (c) catre sistemul de dispecer regional SCADA-DTR


mapare semnale spre/dinspre SCADA-DTR, testare comunicatie cu SCADA-

DTR, etc.).

5.1.1.4 Dispeceratul Local de Tratare CRISAN tr.2 (DLT CRISAN) va integra

informatia preluata de la urmatoarele obiective (vezi Anexa 1 / Ob.4,

respectiv detalierea in Anexa 1.4):

(a) Statia de tratare si clorinare Crisan impreuna cu debitmetria aferenta


(b) Debitmetria aferenta retelei de distributie a apei (pentru realizare balanta


(c) Statia de pompare Crisan (vezi Anexa 1.4 / Ob.3);

Mentiuni

• Obiectivul (a) se va integra complet in aplicatia SCADA gestionata de

dispeceratul local de la Crisan, acest lucru fiind realizat prin contractele de


• Obiectivul (b) se va finaliza in cadrul CL aferent, prin aducerea in cadrul


din SP Crisan. Obiectivul (b) este format fizic din 2 debitmetre (cu cablu de

transmitere a datelor – non wireless) fiind un obiectiv de tip stand-alone,

nefiind integrat in aplicatia SCADA al DL Crisan, motiv pentru care in vederea




datelor obiectivului (b) catre sistemul de dispecer regional SCADA-DTR


testare comunicatie cu SCADA-DTR).

23


camerei de comanda Crisan a unui tablou sinoptic de automatizare (local).

Obiectivul (c) este tot un obiectiv de tip stand-alone, nefiind integrat in

aplicatia SCADA al DL Crisan, motiv pentru care in vederea transmiterii in


de pompare SP Crisan din GUI/SCADA-DTR, ofertantul va prevedea un



aferente obiectivului (c) catre sistemul de dispecer regional SCADA-DTR


mapare semnale spre/dinspre SCADA-DTR, testare comunicatie cu SCADA-

DTR, etc.).

5.1.1.5 Dispecerat Local al statei de Epurare SLATINA (DLE Epurare

SLATINA) (vezi Anexa 1 / Ob.5) realizeaza conducerea completa a

procesului local aferent statiei de epurare Slatina. Constructorul de pe CL

aferent statiei de epurare isi propune reabilitarea si extinderea statiei de

epurare a orasului Slatina prin lucrari efectuate asupra: procesului

tehnologic, instalatiilor electrice, instrumentatiei de masura si control,

echipamentelor de automatizare si achizitie a datelor si lucrari civile si

constructii. Din punctul de vedere al automatizarii, antreprenorul proiecteaza

si implementeaza un sistem SCADA (local) complet automatizat care va fi

interconectat la sistemul central SCADA-DTR, pentru a permite controlul si

monitorizarea in intregime a procesului de epurare, cu personal minim.

Lucrarile aferente modernizarii statiei de epurare Slatina vor include in linii mari:

procurarea tuturor echipamentelor de automatizare si a instrumentatiei necesare

achizitionarii de semnale din proces, realizare conexiuni intre echipamentele de

proces si sistemul SCADA local, pregatirea si adaptarea camerei de comanda-

control a statei in conf. cu cerintele si standardele de automatizare, instalarea si

punerea in functiune a tuturor echipamentelor de automatizare si teste intre

acestea si sistemul SCADA local al statiei, asigurarea serviciilor de inginerie

specifice integrarii statei de epurare in sistemul central SCADA-DTR.

Ofertantul de sistem integrator SCADA-DTR va trebui sa realizeze integrarea

sistemului SCADA local al statiei de epurare tinand cont de tipurile de semnale

specifice unei statii de epurare, care vor fi detaliate la capitolele urmatoare.

24

5.1.1.6 Bazin GRADISTE (vezi Anexa 1 / Ob.6) – obiectiv echipat cu debitmetre

folosite pentru masurarea cantitatii de apa in retea. Obiectivul se va finaliza

in cadrul CL aferent, prin aducerea in cadrul camerei de comanda Gradiste a

unui tablou de monitorizare al debitelor masurate de cele 2 debitmetre.

Obiectivul este format fizic din 2 debitmetre (cu cablu de transmitere a

datelor – non wireless) fiind un obiectiv de tip stand-alone, nefiind integrat in

nici un fel de aplicatie SCADA locala, motiv pentru care in vederea

transmiterii in SCADA-DTR a datelor furnizate de aceste debitmetre

ofertantul va prevedea un echipament de achizitie a datelor de tip PLC la

care se adauga suportul de comunicatie adecvat in vederea transmiterii pe

protocol OPC a datelor obiectivului catre sistemul de dispecer regional

SCADA-DTR precum si serviciile de inginerie specifice (montare

echipamente, configurare, testare comunicatie cu SCADA-DTR).

5.1.1.7 Statii de Pompare Ape Uzate (SPAU) SLATINA – Obiectivul SPAU are

in componenta urmatoarea constelatie de statii de pompare (Anexa 1):

(a) Statia de pompare ape uzate Gradiste (Anexa 1 / Ob.7);

(b) Statia de pompare ape uzate Pitesti (Anexa 1 / Ob.8);

(c) Statia de pompare ape uzate Eugen Ionescu (Anexa 1 / Ob.9);

(d) Statia de pompare ape uzate Manastirii (Anexa 1 / Ob.10);

(e) Statia de pompare ape uzate Alice Botez (Anexa 1 / Ob.11);

(f) Statia de pompare ape uzate Arcului (Anexa 1 / Ob.12);

(g) Statia de pompare ape uzate Vailor (Anexa 1 / Ob.13).

Pe contractele de lucrari sunt prevazute doar modernizari partiale ale echipamentului de

proces pentru obiectele (a) si (b), fara a fi echipate cu instrumentatia necesara realizarii

unor sisteme SCADA locale sau puncte de achizitie a datelor de tip stand-alone, motiv

pentru care, in vederea unei integrari ulterioare in Sistemul de Telecontrol Regional

(SCADA-DTR), ofertantul va prevedea un numar suficient de tagg-uri (min. 200 tag-

uri/statie) in vederea unei integrari complete. Ofertantul va lua in considerare la

dimensionarea sistemului integrator, faptul ca pentru constelatia de SPAU-ri se va

realiza atat monitorizarea cat si controlul procesului de la nivelul SCADA-DTR.

25

Monitorizarea procesului fara control pe aparatajul din proces se va face doar pentru

statiile de epurare si in mod evident pentru activitatea de debitmetrie.

5.1.2 AGLOMERAREA POTCOAVA

În conformitate cu Cerin�ele Angajatorului, pentru aglomerarea Potcoava au fost

prevăzute Lucrări la sursele de apă potabilă, retele de alimentare cu apa si

canalizare şi tratare apă uzată pentru care sunt prevazute pe contractele de lucrari,

realizarea unei staŃii de tratare noi dotata cu dispecerat local de control (DL), respectiv o

statie de epurare prevazuta de asemenea cu dispecer local. Cu alte cuvinte, la

finalizarea contractelor de lucrări vor exista 2 dispecerate locale care vor fi integral

preluate în sistemul SCADA-DTR (conf. Anexei 2).


5.1.2.1 Dispeceratul Local Tratare POTCOAVA (DLT POTCOAVA) va integra

informatia preluata de la urmatoarele obiective (Anexa 2 / Ob.1):

(a) Statia de tratare si clorinare Potcoava impreuna cu debitmetria aferenta

monitorizarii procesului de tratare din statia Potcoava (Anexa 2 / Ob.1.1);

(b) Fronturile de puturi (captare apa) (Anexa 2 / Ob.1.1);

(c) Debitmetria aferenta retelei de distributie a apei (pentru realizare balanta apa)

(Anexa 2 / Ob.1.2);

Mentiuni


dispeceratul local de tratare de la Potcoava, acest lucru fiind realizat prin

contractele de lucrari specifice aflate in derulare.


camerei de comanda a DLT Potcoava a unui tablou de monitorizare al

debitelor care intra in reteaua de distributie. Obiectivul (c) este format fizic din

1 buc. debitmetru (cu cablu de transmitere a datelor – non wireless) si este un

obiectiv de tip stand-alone, nefiind integrat in aplicatia SCADA al DLT

Potcoava, motiv pentru care in vederea transmiterii in SCADA-DTR a datelor

furnizate de acesta ofertantul va prevedea un echipament de achizitie a

datelor de tip PLC la care se adauga suportul de comunicatie adecvat in

vederea transmiterii pe protocol OPC a datelor obiectivului (c) catre sistemul

26

de dispecer regional SCADA-DTR si serviciile de inginerie specifice (montare


5.1.2.2 Statii de Pompare Ape Uzate (SPAU) Potcoava – Obiectivul SPAU are

in componenta urmatoarea constelatie de statii de pompare (Anexa 2):

(a) Statia de pompare ape uzate 1 (Anexa 2 / Ob.3);

(b) Statia de pompare ape uzate 2 (Anexa 2 / Ob.4);


proces, fara a fi echipate cu instrumentatia necesara realizarii unor sisteme SCADA

locale sau puncte de achizitie a datelor de tip stand-alone, motiv pentru care, in vederea

unei integrari ulterioare in Sistemul de Telecontrol Regional (SCADA-DTR), ofertantul

va prevedea un numar suficient de tagg-uri (min. 200 tag-uri/statie) in vederea unei

integrari complete. Ofertantul va lua in considerare la dimensionarea sistemului

integrator, faptul ca pentru cele doua SPAU-ri se va realiza atat monitorizarea cat si

controlul procesului de la nivelul SCADA-DTR. Monitorizarea procesului fara control pe

aparatajul din proces se va face doar pentru statiile de epurare si in mod evident pentru

activitatea de debitmetrie.

5.1.2.3 Dispecerat Local al statei de Epurare POTCOAVA (DLE POTCOAVA)

realizeaza conducerea completa a procesului local aferent statiei de epurare

Potcoava. Constructorul de pe CL aferent statiei de epurare isi propune

reabilitarea si extinderea statiei de epurare a orasului Potcoava prin lucrari

efectuate asupra: procesului tehnologic, instalatiilor electrice, instrumentatiei de

masura si control, echipamentelor de automatizare si achizitie a datelor si lucrari

civile si constructii. Din punctul de vedere al automatizarii, antreprenorul

proiecteaza si implementeaza un sistem SCADA (local) complet automatizat care

va fi interconectat la sistemul central SCADA-DTR, pentru a permite controlul si

monitorizarea in intregime a procesului de epurare, cu personal minim. Lucrarile

necesare modernizarii statiei de epurare Potcoava vor include in linii mari:






27






5.1.3 AGLOMERAREA DRAGANESTI-OLT

În conformitate cu Cerin�ele Angajatorului, pentru aglomerarea Draganesti-Olt au fost

prevăzute Lucrări la sursele de apă potabilă şi apă uzată pentru care sunt prevazute

pe contractele de lucrari, realizarea unei staŃii de tratare noi dotata cu dispecerat local

de control (DL) respectiv o statie de epurare prevazuta de asemenea cu dispecer local.

Cu alte cuvinte, la finalizarea contractelor de lucrări vor exista 2 dispecerate locale care

vor fi integral preluate în sistemul SCADA-DTR (conf. Anexei 3).


5.1.3.1 Dispeceratul Local Tratare DRAGANESTI-OLT (DLT DRAGANESTI-

OLT) va integra informatia preluata de la urmatoarele obiective (Anexa 3 / Ob.1):

(a) Statia de tratare si clorinare Draganesti-Olt impreuna cu debitmetria aferenta

monitorizarii procesului de tratare din statia Draganesti-Olt;

(b) Fronturile de puturi (captare apa);


apa);

Mentiuni


dispeceratul local de tratare de la Draganesti-Olt, acest lucru fiind realizat prin

contractele de lucrari specifice aflate in derulare.


camerei de comanda a DLT Draganesti-Olt a unui tablou de monitorizare al

debitelor care intra in reteaua de distributie. Obiectivul (c) este format fizic din

1 buc. debitmetru (cu cablu de transmitere a datelor – non wireless) si este un

obiectiv de tip stand-alone, nefiind integrat in aplicatia SCADA al DLT

Draganesti-Olt, motiv pentru care in vederea transmiterii in SCADA-DTR a

datelor furnizate de acesta ofertantul va prevedea un echipament de achizitie

a datelor de tip PLC la care se adauga suportul de comunicatie adecvat in

28

vederea transmiterii pe protocol OPC a datelor obiectivului (c) catre sistemul

de dispecer regional SCADA-DTR si serviciile de inginerie specifice (montare


5.1.3.2 Statii de Pompare Ape Uzate (SPAU) Draganesti – Olt – Obiectivul

SPAU are in componenta urmatoarea constelatie de statii de pompare (Anexa 3):

(a) Statia de pompare ape uzate 1 (Anexa 3 / Ob.3);

(b) Statia de pompare ape uzate 2 (Anexa 3 / Ob.4);


proces, fara a fi echipate cu instrumentatia necesara realizarii unor sisteme SCADA

locale sau puncte de achizitie a datelor de tip stand-alone, motiv pentru care, in vederea

unei integrari ulterioare in Sistemul de Telecontrol Regional (SCADA-DTR), ofertantul

va prevedea un numar suficient de tagg-uri (min. 200 tag-uri/statie) in vederea unei

integrari complete. Ofertantul va lua in considerare la dimensionarea sistemului

integrator, faptul ca pentru cele doua SPAU-ri se va realiza atat monitorizarea cat si

controlul procesului de la nivelul SCADA-DTR. Monitorizarea procesului fara control pe

aparatajul din proces se va face doar pentru statiile de epurare si in mod evident pentru

activitatea de debitmetrie.

5.1.3.3 Dispecerat Local al statei de Epurare DRAGANESTI-OLT (DLE

DRAGANESTI-OLT) (Anexa 3 / Ob.2) realizeaza conducerea completa a

procesului local aferent statiei de epurare Draganesti-Olt. Constructorul de pe CL

aferent statiei de epurare isi propune reabilitarea si extinderea statiei de epurare

a orasului Draganesti-Olt prin lucrari efectuate asupra: procesului tehnologic,

instalatiilor electrice, instrumentatiei de masura si control, echipamentelor de

automatizare si achizitie a datelor si lucrari civile si constructii. Din punctul de

vedere al automatizarii, antreprenorul proiecteaza si implementeaza un sistem

SCADA (local) complet automatizat care va fi interconectat la sistemul central

SCADA-DTR, pentru a permite controlul si monitorizarea in intregime a

procesului de epurare, cu personal minim. Lucrarile de modernizare ale statiei de

epurare Draganesti-Olt vor include in linii mari: procurarea tuturor echipamentelor

de automatizare si a instrumentatiei necesare achizitionarii de semnale din

proces, realizare conexiuni intre echipamentele de proces si sistemul SCADA

local, pregatirea si adaptarea camerei de comanda-control a statei in conf. cu

29

cerintele si standardele de automatizare, instalarea si punerea in functiune a

tuturor echipamentelor de automatizare si teste intre acestea si sistemul SCADA

local al statiei, asigurarea serviciilor de inginerie specifice integrarii statei de

epurare in sistemul central SCADA-DTR.




5.1.4 AGLOMERAREA PIATRA-OLT

În conformitate cu Cerin�ele Angajatorului, pentru aglomerarea Piatra-Olt au fost

prevăzute Lucrări la sursele de apă uzată pentru care sunt prevazute pe contractele

de lucrari, realizarea unei staŃii noi de epurare prevazuta cu dispecerat local. Cu alte

cuvinte, la finalizarea contractelor de lucrări va exista 1 dispecerat local care va fi

integral preluat în sistemul SCADA-DTR (conf. Anexei 4).


5.1.4.1 Dispecerat Local al statei de Epurare PIATRA-OLT (DLE PIATRA-

OLT) realizeaza conducerea completa a procesului local aferent statiei de

epurare Piatra-Olt. Constructorul de pe CL aferent statiei de epurare isi propune

reabilitarea si extinderea statiei de epurare a orasului Piatra-Olt prin lucrari

efectuate asupra: procesului tehnologic, instalatiilor electrice, instrumentatiei de

masura si control, echipamentelor de automatizare si achizitie a datelor si lucrari

civile si constructii. Din punctul de vedere al automatizarii, antreprenorul

proiecteaza si implementeaza un sistem SCADA (local) complet automatizat care

va fi interconectat la sistemul central SCADA-DTR, pentru a permite controlul si

monitorizarea in intregime a procesului de epurare, cu personal minim. Lucrarile

de modernizare ale statiei de epurare Piatra-Olt vor include in linii mari:








30




5.1.5 AGLOMERAREA SCORNICESTI

În conformitate cu Cerin�ele Angajatorului, pentru aglomerarea Scornicesti au fost

prevăzute Lucrări partiale la sursele de apă, precum si la retelele de alimentare cu

apa si canalizare pentru care sunt prevazute pe contractele de lucrari, realizarea unei

retehnologizari a fronturilor de captare, executia a doua statii de pompare apa potabila:

SP Suica, respectiv SP Constantinesti, precum si o statie hidrofor Teius, obiecte

destinate deservirii populatiei din localitatile invecinate Scornicesti-ului. Lucrarile la

sursele de apa vor presupune instalarea si punerea in functiune a echipamentelor

hidraulice si mecanice specifice functionarii puturilor care alcatuiesc fronturile de

captare. In aceste conditii, Ofertantul va lua in considerare realizarea unui PLC local a

carui locatie va fi ulterior stabilita de catre Ofertant impreuna cu Autoritatea

Contractanta, PLC in care vor fi preluate datele de la nivelul fiecarui debitmetru cu care

sunt echipate puturile care alcatuiesc frontul de captare. Statia de tratare a apei

existente nu detine instrumentatia necesara achizitionarii datelor de proces. Mai mult,

pe reteaua de canalizare sunt prevazute executia a doua noi statii de pompare ape

uzate SP1 si SP2 la care se vor rraliza doar modernizari partiale ale echipamentului de

proces, fara a fi dotate cu instrumentatia necesara realizarii unor sisteme SCADA locale

sau puncte de achizitie a datelor de tip stand-alone. Astfel, in vederea unei integrari

ulterioare in Sistemul de Telecontrol Regional (SCADA-DTR), Ofertantul va prevedea

un numar suficient de tagg-uri (min. 200 tag-uri/statie) in vederea unei integrari

complete. Ofertantul va lua in considerare la dimensionarea sistemului integrator, faptul

ca pentru cele doua SPAU-ri se va realiza atat monitorizarea cat si controlul procesului

de la nivelul SCADA-DTR. Cu alte cuvinte, va trebui sa exite posibilitatea integrarii

ulterioare in sistemul SCADA-DTR atat a liniei aferenta procesului de tratare a apei cat

si a liniei apei uzate.

Orasul Scornicesti mai detine si o statie de epurare partial retehnologizata (conf. Anexa

5 / Ob.2), in sensul ca nu are prevazuta instrumentatia necesara achizitionarii datelor

din proces, motiv pentru care nu va putea fi integrata in aceasta etapa in sistemul

central SCADA-DTR. Ofertantul va dimensiona insa sistemul central SCADA-DTR astfel

incat pe viitor sa poata fi integrata si statia de epurare Scornicesti in sistemul de

31

telecontrol regional. Dimensionarea se va face cu un nr. de tagg-uri identic ca si pentru

celelalte statii de epurare enumerate la subpunctele anterioare.

5.2 Contracte de lucrari pe activitatea de debitmetrie / telemetrie de retea

În vederea asigurării unui sistem eficient de monitorizare al debitelor gestionate de

Operatorul Regional, adișional fașă de lucrarile deja contractate în cadrul proiectului

“Extinderea și reabilitarea sistemelor de apa și apă uzată în judeșul Olt”

(implementarea unui sistem SCADA Regional, prevederea de debitmetre la nivelul

surselor de apă, a stașiilor de tratare apă și pe reșelele de distribușie pentru

monitorizarea reșelei în împărșirea acesteia în zone de măsurări de debite – DMA), se

vor concretiza în teren “puncte de monitorizare a debitelor”.

Conceptul de “Punct de monitorizare debit” include ansamblul de lucrari civile,

mecanice, electrice și/sau de automatizare ce au ca scop final furnizarea, către

dispeceratul Regional SCADA, de date privind în principal mărimea şi evoluŃia în timp a

debitelor vehiculate în sistemul de alimentare cu apă.

Prin contractul de debitmetrie aflat în derulare, se propune realizarea a 43 de puncte de

monitorizare a debitelor prin montarea de debitmetre electromagnetice cu imersie

dotate cu dispozitive de transmitere la distanŃă (loggere și GSM).

Instalatia de monitorizare, pentru fiecare amplasament in parte, se compune dintr-un

ansamblu debitmetru electromagnetic – data logger, care are functia de culegere,

stocare si transmitere a datelor la distanta printr-un sistem GPRS/GSM catre

dispeceratul central.

Citirea debitelor şi a altor parametri se poate face atât local (pe display-ul debitmetrului)

cât şi la distanŃă prin intermediul datalogger–ului. Acesta va avea sarcina de a

monitoriza şi transmite valoarea debitului vehiculat pe conductă prin intermediul

senzorului încorporat.

Alimentarea cu energie electrica a fiecarui echipament se va realiza independent, prin

prevederea unei surse de alimentare locale (baterie internă sau pachet de baterii

externe).

Se vor avea în vedere debitmetre electromagnetice cu senzor de tip inserŃie, cu

dimensiuni, funcŃie de diametrul nominal (DN) al tronsoanelor monitorizate, diametrul

interior (Di) al conductelor respective, debitul şi implicit viteza apei în conductă.

32

5.2.1 LUCRĂRI SPECIFICE PE PARTEA ELECTRICĂ ŞI DE AUTOMATIZĂRI

Sistemul SCADA Regional ce urmează a fi implementat, va fi o structură centralizată

care presupune realizarea unui Dispecerat de Telecontrol Regional (DTR) în municipiul

Slatina, prevăzut cu echipamente industriale de fiabilitate ridicată, funcŃionând în

topologie redundantă pentru asigurarea continuităŃii fără întreruperi. Rolul DTR este

acela de coordonare a tuturor subreŃelelor de achiziŃie de date din aglomerările aflate în

aria de interes a Companiei.

Dispeceratele Locale reprezintă de fapt reŃele locale de date (LAN) situate în

aglomerarile aflate în aria/zona de interes a Operatorului Regional, care achiziŃionează

şi procesează (în funcŃie de specificul activităŃii) informaŃiile primare ale procesului

(nivelul apei, monitorizare debite, telemetrie, semnale de diagnosticare, etc.) şi le pune

la dispoziŃia atât a operatorului local al entităŃii conduse cât şi dispecerului teritorial aflat

la nivel central.

Datele vor fi transmise utilizind acelasi protocol de comunicatie pentru toate punctele de

lucru, pentru a putea asigura integrarea la nivelul dispecerului zonal. Integrarea

sistemelor de puncte de monitorizare debite presupune montarea echipamentului de

măsura şi transmisie de la aceste puncte de măsura, transmisia datelor la SCADA-

DTR, preluarea, afişarea şi stocarea datelor din câmp. Tipul de transmisie de la

punctele de măsura debit va fi 3G/GPRS/GSM, cu posibilitatea de transmitere de SMS /

e-mail de avertizare (la depăşire praguri debit şi presiune, lipsă alimentare, lipsa apă în

conductă).

Pentru partea de telemasură se va urmari achizișia și transmiterea catre SCADA-DTR

a cel pușin următorilor parametri:

• Afișare debit instantaneu;

• Afișare debit totalizator pozitiv, negativ și total, avertizare lipsă apă în conductă;

• Avertizare depășire debit maxim admis;

• Avertizare depașire presiune maximă admisă;

• Indicare presiune;

• Alarmare în caz de putere minimă baterie;

• Indicare stare comunicașie GPRS.

Sistemul SCADA-DTR va include afișarea de grafice de tendinŃă (Trend View) pe

diferite perioade a tuturor mărimilor transmise şi stocarea acestora pe o perioadă de

minim 1 an. Intervalul de comunicaŃie / actualizare a datelor va fi 1 data / 60min, cu

posibilitatea configurării ulterioare funcŃie de necesităŃi.

33

Datele stocate de către datalogger vor avea posibilitatea de a fi descărcate şi pe un

dispozitiv tip laptop sau PDA, direct din acesta la faŃa locului prin conexiune directa pe

cablu sau wireless (ex. Bluetooth).

Lucrări electrice şi de automatizare

Lucrarile electrice aferente punctelor de monitorizare a debitelor sunt realizate pe un

contract de lucrari separat (contractul CL8/2), care nu face obiectul actualului caiet de

sarcini, insa pentru ca ofertantul sa aiba o idee exacta asupra situatiei existente s-au

detaliat in cele ce urmeaza actiunile derulate pe contractul de lucrari care includ:

• montare echipamente debitmetru, datalogger, antena GSM (acolo unde puterea

semnalului este insuficienta pentru comunicaŃie, antena GSM se va monta pe un

suport în exteriorul căminului);

• setare parametri debitmetru, datalogger – conform instrucŃiunilor de montaj ale

producătorilor;

• executare legături electrice şi semnalizare la debitmetru, datalogger şi antenă

GSM;

• execuŃie branşament electric (doar pentru debitmetrele instalate în incinta staŃiilor

de tratare);

• integrarea şi corelarea cu sistemul SCADA-DTR ce care se implementează la

sediul OR;

În anexele 6.1, 6.2 şi 6.3 sunt prezentate detaliat schemele de funcŃionare şi poziŃionare

a debitmetrelor în zonele:

• Potcoava şi Drăgăneşti-Olt (Anexa 6.1);

• Scorniceşti, Piatra-Olt şi BistriŃa Nouă (Anexa 6.2);

• Slatina (Anexa 6.3).

W2

Pentru a demonstra intelegerea exacta atat a conditiilor existente (expuse in capitolul 5)

care reprezinta conditii de plecare („start-up”), cat si a amplorii proiectului, ofertantul va

trebui sa:

• expuna o schema completa (arhitectura de retea functionala) cu obiectivele

Companiei de Apa Olt, integrabile in sistemul SCADA-DTR ofertat;

34

• expuna o schema bloc (in viziune proprie) cu obiectivele integrabile in SCADA-

DTR in care sa fie accentuat suportul de comunicatie si modalitatea de routare a

informatiei / datelor intre punctele de achizitie si sistemul central SCADA-DTR;

• expuna o „arhitectura software” a sistemului care sa cuprinda solutia completa (in

viziunea ofertantului) de integrare a obiectivelor in sistemul central SCADA-DTR.

Elemente ale arhitecturii tebuie sa puncteze software-ul de proces utilizat la

integrare; protocolul de comunicatie care realizeaza schimbul informational intre

punctele de achizitie si sistemul central SCADA-DTR; submodulele software ale

platformei SCADA implementata la Dispeceratul Regional Slatina; alte elemente

care sunt considerate semnificative pentru a explicita arhitectura software

solicitata;

• expliciteze modalitatea concreta (in propria viziune) in care se realizeaza

integrarea obiectivelor descrise in CS (o descrierea sintetizata a situatiei

existente si a obiectivului „de realizat” in cadrul propunerii ofertate). Solutia de

integrare ofertata va fi detaliata pentru a se putea face o evaluare corecta a

functionalitatii optime a acesteia.

5.3 Sinteza conditiilor de plecare in vederea realizarii proiectului

Asa cum s-a explicitat in subcapitolul anterior, in urma contractelor de lucrari aflate in

derulare vor fi realizate urmatoarele:

• sisteme SCADA locale pentru productia de apa;

• sisteme SCADA locale pentru epurarea apei uzate;

• se vor instala debitmetrele cu transmisie GPRS pentru telemetria/debitmetria de

retea.

Productia include: puturile, rezervoarele, canalizare, statiile de pompare, statie de

tratare. Pentru toate aceste elemente exista un singur sistem SCADA numit aici

generic, "Productie".

Caracteristicile generale ale celor tipuri 3 obiective, ce vor fi folosite de catre ofertanti ca

informaŃii de plecare pentru proiectarea sistemului centralizat de telecontrol şi

supervizare, sunt următoarele:

• Toate staŃiile locale dispun de acoperie minim GPRS;

35

• Sistemele SCADA aferente dispeceratelor locale dispun de cate un PLC, care

centralizează informaŃiile, fie de producŃie apă (puŃuri, rezervoare, staŃie de

tratare, etc.), fie de epurare apă (etape epurare, rezervoare, pompare, etc).

• Sistemele SCADA locale vor dispune de funcŃionalităŃi compatibile cu standardul

OPC (OLE (Object Linking and Embedding) for Process Control) si vor putea

mapa informatia (in vederea integrarii in SCADA-DTR).

• Pentru sistemele SCADA locale (executate pe contractele de lucrari) se va avea

in considerare in vederea dimensioarii si integrarii, un numar de minim 500 de

tag-uri si 20% rezerve pentru dezvoltari ulterioare;

• Parametri monitorizati in cadrul DTR vor fi cei oferiti de catre sistemele SCADA

locale;

• Toate staŃiile sunt autonome, iar funcŃionarea lor nu depinde de starea

comunicaŃiilor cu Dispeceratul DTR;

• Pentru telemetria de retea, in cele 5 localitati vor fi instalate un numar de 43 de

debitmetre cu transmisie de date GPRS (distributia per localitati a debitmetrelor

fiind reprezentata in anexele 6.1, 6.2 si 6.3). Transmiterea informatiei de la

echipamentele de tip data logger – aferente echipamentelor de telemetrie

(debitmetre) catre sistemul central SCADA-DTR se va realiza pe protocoale de

comunicatie pe proces (ex. DNP 3.0 sau Modbus) pentru a se pastra

sincronizarea de timp cu referinta generata de sistemul central.

Procesele derulate la nivel de dispecerate locale au fost modelate ca reŃele de date

locale LAN (Local Area Network) care achiziŃionează şi procesează fluxul informaŃional

primar (nivelul apei, monitorizare debite, telemetrie, semnale de diagnosticare, etc.) si

apoi il transmit prin intermediul reŃelei de comunicaŃie către nivelul ierarhic superior

(Dispeceratul de Telecontrol Regional - DTR).

InstalaŃiile de comandă, automatizare, măsură şi semnalizare aferente punctelor de

lucru locale (sistemele SCADA locale) se bazeaza pe utilizarea automatelor

programabile “slave”, montate în dulapurile electrice locale, de la fiecare locatie (captari

de apa bruta, statii de tratare a apei brute, statii de pompare apa potabila, rezervoare

de apa potabila, sisteme de canalizare ape uzate, statii de epurare ape uzate) şi pe

serverele ”master”, montate la dispeceratul central aflat la sediul Companiei de Apa

Olt.

36

Serverele „master” vor fi în legătură permanentă (on-line) cu serverele aferente

sistemelor SCADA locale.

Pe contractele de lucrari care nu fac obiectul acestei documentatii se vor realiza

operatiunile de setare/parametrizare şi urmărirea parametrilor de funcŃionare care se va

face prin intermediul terminalelor om-maşină (HMI – Human Machine Interface),

instalate deasemenea la fiecare locatie, pe panourile frontale ale dulapurilor electrice

care vor asigura alimentarea, comanda si monitorizarea instalatiilor, sistemelor si

elementelor de camp dorite.

Automatele programabile locale (din statii) vor permite colectarea semnalelor furnizate

de traductoare, senzori si echipamente de masurare (debitmetre, traductoare de

presiune, de nivel, control clorinare şi aparate dedicate pentru masura consumului

energetic) si vor fi montate in locatiile specificate pe contractele de lucrari.

• Tipul debitmetrelor utilizate va fi definitivat in functie de caracteristicile tehnice

(diametre conducte, gama de masurare, etc.) specifice fiecarei locatii

monitorizate.

• Senzorii de nivel vor fi de două tipuri: traductoare cu ultrasunete pentru informatii

privind nivelul real si senzori cu plutitoare pentru semnalizare nivel minim si

maxim.

• Alimentarea cu energie electrica a traductoarelor, senzorilor se va face cu

ajutorul unor acumulatoare speciale (cu durata lunga de viata, cca. 5ani), iar a

celorlalte echipamente prin racordarea lor la instalatiile electrice existente sau la

bransamentele noi care vor fi realizate.

Transmiterea informatiilor colectate de la punctele locale spre/dinspre sistemul central

SCADA se va face folosind sistemul de comunicatie GSM / GPRS. Serviciile de

voce/date necesare pentru realizarea comunicatiilor din cadrul sistemului, subiect al

acestui proiect, vor fi achizitionate de catre Beneficiar. Datorita faptului ca, pe piata din

Romania exista mai multi furnizori pentru acest tip de servicii, Prestatorul (adica,

ofertantul declarat castigator in urma evaluarii ofertelor depuse pentru aceasta licitatie)

va acorda asistenta tehnica Beneficiarului in vederea stabilirii celui/celor mai bun/buni

operator/operatori, capabili sa ofere serviciile de voce si date optime pentru

complexitatea si aria de desfasurare a proiectului.

37

Sistemul SCADA-DTR propus va avea o configuraŃie modulară şi deschisă

(scalabilitate), astfel încât sa permita dezvoltari ulterioare (racordarea la sistem şi a altor

echipamente sau module software de aplicatie).

38

6 DESCRIEREA A SISTEMULUI REGIONAL DE DISPECERIZARE SCADA-DTR

6.1 Generalitati

Sistemul SCADA ofertat va trebui sa fie o platformă scalabilă cu urmatoarele

caracteristici:

• sa utilizeze o tehnologie bazată pe obiecte care sa permita configurarea,

înregistrarea datelor, obŃinerea şi mentenanŃa informaŃiei istorice şi a celei în

timp real.

• sa dispuna de un modul specializat de istorice de procese, de înalta performanŃă,

care sa permita:

o stocarea istoricului de producŃie;

o compresia eficientă a datelor;

o autoconfigurarea stocării de istorice, ce elimină efortul de a crea

variabilele de doua ori;

o un server de gestiune a informaŃiei via web care simplifică organizarea şi

prezentarea informaŃiilor referitoare la operaŃiunile din procese, care

permite printre alte facilităŃi, vizualizarea unor ferestre şi grafice (forme de

unda – trends) din SCADA via Web.

In cadrul Dispeceratului Regional vor fi controlate, supervizate si vizualizate numai

informatiile/datele oferite de sistemele SCADA locale / dispeceratele locale (realizate

sau in curs de realizare in contractele de lucrari, sau in cazul telemetriei de retea, ce vor

fi realizate in cadrul acestui contract).

(a). Integrarea de variabile – presupune ca:

• se pot importa variabilele definite în PLC-uri;

• Pentru majoritatea PLC-urilor de pe piaŃă, tagg-urile care se definesc în PLC se

transfera automat în platforma SCADA-DTR;

(b). Programare / Configurare – presupune ca:

• Proiectarea sistemului utilizeaza T-POO (Tehnologia de Proiectare Orientată pe

Obiecte);

• Fiecărui Obiect i se pot defini următoarele proprietăti/ atribute:

o Intrări / Ieşiri (I/O);

o Semnale preventive şi de avarie (Alarme şi Evenimente);

o AplicaŃii / scripturi si configurare de istorice;

39

o Atribute de securitate;

o Caracteristici obiect (cod de culori, dinamică, etc.);

Aceste obiecte se vor include în librării de obiecte, ce vor avea următoarele

caracteristici:

• Posibilitatea de a crea şabloane (templaturi);

• Orice modificari în librărie vor fi actualizate în tot sistemul;

• Posibilitatea de a crea / definii noi librării pornind de la cele existente;

• Posibilitatea creării unor librării de obiecte standard;

• Posibilitatea creării de obiecte prin programe personalizate (ex. Vizual Basic,

Active X, .Net, etc.)

• Posibilitatea de dezvoltare a proiectului într-un mediu multi-utilizator.

(c). Istorice

Baza de date se va construi pe o baza de date relationala si va suporta intre 250 si

1.000.000

de variabile ce vor fi inregistrate in istoric.

Tipuri minime de variabile ce vor fi inregistrate in istoric:

• Analogice: din cadrul SCADA se vor vizualiza graficele acestora;

• Digitale: Toate alarmele / evenimentele vor putea fi inregistrate in baza de date;

• Recuperarea de istorice: posibilitatea de a recupera istoricele direct in baza de

date pornind de la importul de fisiere in format text, din RTU-uri.

• Accesul la distanta si publicarea datelor via Web

(d). SCADA va include un portal web cu urmatoarele caracteristici:

• Gestiune a continutului Web pentru a oferi informatia in timp real;

• Configurare de rapoarte, grafice si generarea automata a acestora cum ar fi:

o Balanta consumului de apa incluzand bilantul pe surse/consum tehnologic

o Situatia consumului de energie electrica aferenta sistemului de alimentare

cu apa;

o Situatia consumului de energie electrica aferenta sistemului de canalizare;

6.2 Functiile sistemului SCADA-DTR

6.2.1 FUNCTII CU CARACTER GENERAL

• vizualizarea grafica a sistemelor si instalatiilor monitorizate;

• monitorizarea parametrilor de funcŃionare;

40

• emiterea comenzilor de functionare de la distanta;

• înregistrarea evenimentelor;

• managementul alarmelor;

• stocarea datelor;

• realizarea rapoartelor;

• urmărirea operaŃiilor de întreŃinere;

6.2.2 INFORMATII MINIMALE FURNIZATE DE SISTEM

• debitele de apa (potabile si uzate) vehiculate;

• nivelul apei (potabile sau uzate) in locatiile monitorizate;

• presiunea apei în locatiile monitorizate;

• consumul de energie electrică;

• număr ore de funcŃionare echipamente.

6.2.3 MODUL DE PREZENTARE AL INFORMATIILOR

Debit

• valoarea instantanee;

• valoarea pe zi;

• afişare grafică pe orice perioadă selectată cu funcŃie de mărire “zoom”;

• stocarea datelor pe perioada dorita

Nivel


• afişare grafică pe orice perioadă selectată cu funcŃie de mărire “zoom”;

• stocarea datelor pe perioada dorita.

Presiune


• afişare grafică pe orice perioadă selectată;

• stocarea datelor pe perioada dorita

Control clorinare în pct. de măsură (statia de pompare si rezervoare)


41

• afişare grafică pe orice perioadă selectată;

• stocarea datelor pe perioada dorita.

Număr ore de funcŃionare pompe


• afişare tabelară;

• alarmarea personalului de întreŃinere la data reviziei;

6.3 Principalii parametrii monitorizati

In functie de tipul obiectivelor monitorizate (retea distributie, statii pompare, rezervoare,

sisteme clorinare, statii epurare/tratare, etc.), sistemele SCADA sau RTU-urile

implementate pe contractele de lucrari vor transmite catre sistemul de dispecerizare

regional (si nu se vor rezuma doar la acestea) semnalele/parametrii prezentati in cele

ce urmeaza.

6.3.1 ACTIVITATEA DE DISTRIBUTIE APA POTABILA, STATII DE POMPARE, TRATARE APA

• presiunea actuală din sistem;

• prezenŃă tensiune alimentare sistem SCADA

6.3.1.1 Rezervoare simple

• volum apă în rezervor;

• comanda distanta (telecomanda) de la dispecerat pentru operatiunile de

comutatie de tipul inchidere/deschidere vana, intrare/iesire rezervor;

• debit intrare sau ieşire instantaneu / total (unde este cazul);

• alarmare (senzor) anti-efracșie incintă/perimetru obiectiv;

• prezenŃă tensiune alimentare punct SCADA;

6.3.1.2 Rezervoare prevazute cu grup de pompare

• volum apă în rezervor;

• comanda distanta (telecomanda) de la dispecerat pentru operatiunile de

comutatie de tipul inchidere/deschidere vana, intrare/iesire rezervor;

• presiune aspiraŃie grup pompare;

• presiune refulare grup pompare;

• debit distribuit gravitaŃional instantaneu / total;

• debit pompat instantaneu / total;

42

• stare (on/off/avarie) grup pompare;

• starea (on/off/avarie) si frecvenșa de lucru a convertizoarelor (unde este cazul);

• automatizare locala a grupului de pompare pentru functionare în regim automat

în funcșie de nivelul din rezervor (automat între niv. min/max, rotire automată a

pompelor);

• alarmare (senzor) anti-efracșie incintă / perimetru obiectiv;

• prezenșă tensiune alimentare sistem SCADA;

6.3.1.3 Instalatii de clorinare apa potabila

• doză clor introdusă;

• cantitate clor disponibilă în container (se poate afla în funcșie de presiunea din

container);

• valoarea clorului rezidual în apa distribuită;

• stare (caracteristici) grup injecșie clor (pompe on/off);

• comanda la distanta de la dispecerat a opririi/pornirii grupului de injectie clor

• alarmare (senzor) anti-efracșie incintă / perimetru obiectiv;

• prezenta tensiune alimentare punct SCADA;

• doză clor introdusă;

6.3.2 ACTIVITATEA DE CANALIZARE

6.3.2.1 Statii de pompare si interventie rapida

• Nivel apa in cheson;

• Presiune refulare grup pompare;

• Stare (caracteristici) grup pompare (pompe on/off);

• Debit pompat instantaneu / total;

• Alarmare (senzor) anti-efractie incinta/perimetru obiectiv;

• Prezenta tensiune alimentare punct SCADA.

6.3.2.2 Statii de pompare

• Presiune refulare grup pompare;

• Stare (caracteristici) grup pompare (pompe on/off);

• Debit pompat instantaneu / total;

• Comanda la distanta de la dispecerat a opririi/pornirii grupului de pompare;

• Alarmare (senzor) anti-efractie incinta/perimetru obiectiv;

43

• Prezenta tensiune alimentare punct SCADA.

6.3.3 ACTIVITATEA DE EPURARE

Pentru staŃiile de epurare mici, în funcŃie şi de schema tehnologică adoptată, se vor

avea în vedere achizitionarea următoarelor informatii:

• monitorizarea şi controlul debitului incident de apă uzată în staŃia de epurare în

vederea nivelării încărcării hidraulice şi cu poluanŃi pe parcursul celor 24 ore ale

zilei;

• monitorizarea nivelului de funcŃionare al pompelor de ape brute;

• supravegherea automată a stării de funcŃionare a pompelor (pornit/oprit, valoare

curent absorbit, existenŃa tuturor fazelor la alimentarea cu energie electrică,

corelarea stării de funcŃionare cu debitul pompat);

• controlul evacuării de nămol primar, dacă staŃia este prevăzută cu decantor

primar, prin controlul debitului evacuat;

• controlul concentraŃiei de oxigen din bazinul de aerare, dacă staŃia este cu nămol

activat;

• controlul evacuării de nămol secundar, indiferent de schemă tehnologică, prin

controlul debitului evacuat, sau a timpului de evacuare, în cazul în care se

optează pentru acest sistem;

• controlul debitului de nămol activ de recirculare în cazul în care staŃia este cu

nămol activat;

• controlul stării suflantei pentru aer comprimat, a pompei de recirculare, a vanelor

de evacuare a nămolului în exces;

• monitorizare, măcar TS (suspensii) la ieşirea din staŃie;

• dacă staŃia de epurare este prevăzută cu treaptă biologică cu peliculă biologică,

se va monitoriza sistemul pe care se fixează pelicula biologică (biodiscuri,

biotambur, elemente ale filtrului biologic), stare de funcŃionare, turaŃie, debit;

• dacă staŃia este prevăzută cu sistem de colectare şi dezhidratare mecanică a

nămolului, se va monitoriza starea de funcŃionare şi a acestei instalaŃii;

6.4 Obiectivele proiectului – rezumat

Obiectivele urmarite prin realizarea acestui proiect, sunt urmatoarele:

1. Amenajarea, dotarea, instalarea, verificarea si punerea in functiune a unui

Dispecerat de Telecontrol Regional (DTR), in cadrul Companiei de Apa Olt, cu

44

ajutorul caruia sa poata fi realizat controlul si supervizarea sistemelor de

alimentare cu apa (inclusiv a telemetriei de retea) si canalizare din aria

proiectului, o gestiune performanta a activitatilor si activelor companiei, precum si

instruirea necesara beneficiarului in vederea utilizarii sistemului implementat.

2. Sistemul SCADA regional centralizat, la nivelul Dispeceratului de Telecontrol

Regional (DTR), va integra urmatoarele sisteme SCADA (va realiza corelarea cu

sistemele SCADA existente):

• Productie apa, epurare apa (existente sau implementate in viitor, in cadrul

contractelor aflate in derulare) din municipiul Slatina.


contractelor aflate in derulare) din orasul Potcoava.


contractelor aflate in derulare) din orasul Draganesti-Olt.

• Epurare apa (existente sau implementate in viitor, in cadrul contractelor aflate

in derulare) din orasul Piatra-Olt.

• Productie apa (existente sau implementate in viitor, in cadrul contractelor

aflate in derulare) respectiv in viitor statia de epurare neretehnologizata din

orasul Scornicesti.

Se va prevedea posibilitatea integrării în viitor şi a staŃiei de epurare din Scornicesti

precum si a celor 7 statii de pompare ape uzate (SPAU) din municipiul Slatina. Aceasta

înseamnă că sistemul SCADA de dispecer trebuie prevăzut cu posibilitatea hardware şi

software de a integra complet in viitor încă un 8 subsisteme informatice cu toate

funcŃiunile sale plus procentul de 20% rezerve pentru dezvoltarile ulterioare.

3. Se va integra complet in SCADA-DTR informatia preluata de la debitmetrele cu

transmisie GPRS din municipiul Slatina si localitatile mentionate la activitatea de

debitmetrie.

4. Se solicita o solutie integrata, la cheie, care sa cuprinda urmatoarele:

• furnizare echipamente necesare (hardware, software inclusiv licente);

• instalare;

• verificare;

45

• punere in functiune;

• dezvoltare aplicatii;

• training utilizatori;

• manuale de intretinere, operare si exploatare.

6.5 Cerinte – solutii

6.5.1 CERINTE GENERALE CE TREBUIE INDEPLINITE DE CATRE SOLUTIILE OFERTATE

(1). Cerinte principiale

• Comanda & controlul instalatiilor de productie a apei;

• Monitorizarea instalatiilor de epurare a apei reziduale;

• Telemăsura debitmetriei de retea;

(2). Cerinte de Sistem Informatic de Proces

• Arhitectură deschisă (Open Architecture) – trebuie asigurata posibilitatea

interconectării si a integrării ulterioare (upgrade/extension) a echipamentelor

si/sau a sistemelor provenite de la producători diferiti;

• Interoperabilitate/Interconectivitate – trebuie asigurata posibilitatea integrării

complete si a functionării optime în structura existentă de retea si a altor

echipamente diferite de cele ale sistemului initial prin utilizarea unor protocoale

de comunicatie standardizate;

• Portabilitate si Interschimbabilitate – formatul fisierelor de configurare

concepute pentru un anumit echipament trebuie să poată fi utilizate (eventual

printr-un proces de reconversie) si pe un echipament realizat de un alt

producător însă respectând acelasi standard. Echipamentele unui sistem IT&C

trebuie să poată fi înlocuite, la nevoie (fără pierderea partială sau totală a

functiunilor) atat cu alte echipamente de acelasi tip de la acelasi producător cat si

cu echipamente de la producători diferiti, fara a fi necesare investitii

suplimentare.

• Creşterea fiabilităŃii – prin introducerea unui proces de validare a datelor si prin

existenta unei baze de date comune.

46

• Arhitectură distribuită – trebuie sa asigure o segregare virtuală a functiunilor de

proces pe noduri de retea în vederea descongestionării sistemului central.

• Partajarea resurselor. Trebuie sa devina accesibilila oricărui utilizator care

poate avea acces atât la bazele de date cât şi la programele care gestionează

procesul în derulare.

• Gradul de securizare trebuie sa fie unul crescut. Se vor utiliza in acest sens

comunicaŃii de date criptate si a aplicatiilor de tip firewall si a programelor

antivirus.

• Asigurarea compatibilitatii cu tehnologia broadband. Conceptul sistemul

trebuie sa asigure permisiunea utilizatorilor distanŃi de a accede în mod autorizat

la informaŃia pusă la dispoziŃie de sistemul complex care gestionează procesul

prin intermediul conectivităŃii tip broadband, mărindu-le astfel flexibilitatea şi

eficienŃa.

• Asigurarea cresterii rentabilităŃii (economie de cost), trebuie asigurat un raport

preŃ / performanŃă mai bun, prin utilizarea unor capacităŃi de prelucrare şi

comunicaŃie performante, integrate în sistemele proiectate, care să elimine

necesitatea unor reŃele dedicate şi scumpe.

6.5.2 CERINTE SPECIFICE

Sistemul integrat tip SCADA dispecer din cadrul Companiei de Apa Olt, trebuie sa fie o

structură centralizată în municipiul Slatina, prevăzut cu echipamente industriale de

fiabilitate ridicată, funcŃionând în topologie redundantă pentru asigurarea continuităŃii

fără întreruperi.

Dispeceratele Locale (DL) reprezintă de fapt reŃele locale de date (LAN) situate în

oraşele aflate în aria/zona de interes a Companiei de Apa Olt (care vor fi realizate in

cadrul contractelor separate aflate in derulare), care achiziŃionează şi procesează (în

funcŃie de specificul activităŃii) informaŃiile primare ale procesului şi le pun la dispoziŃia

atât a operatorului local al entităŃii conduse prin intermediul sistemului SCADA local, cât

şi dispecerului regional DTR, aflat la nivel central.

47

6.5.3 ARHITECTURA DISPECERATULUI DE TELECONTROL REGIONAL

Arhitectura Dispeceratului de Control Regional este reprezentată în Anexa 7 si a fost

concepută Ńinându-se cont de contractele de modernizare aflate în derulare (în diverse

stadii) precum şi de solicitările Beneficiarului de a se realiza un sistem informatic

integrat capabil să managerieze în timp real activele şi resursele care conduc/emulează

procesul specific companiei de apă.

6.5.4 MODUL DE ROUTARE AL INFORMATIEI PRELEVATE DE LA NIVELUL PROCESULUI

SoluŃia optimizată pentru routarea şi procesarea informaŃiei prelevate de la nivel de

proces respectă următorul mecanism:

(i) Integrarea (în vederea telecontrolului) fluxului informational provenit de la

unităŃile de cost: surse si statii de tratare, statii de pompare si ridicare a presiunii

se va face exclusiv la nivelul DTR – CAO Slatina. Sub această incidenŃă se află

unităŃile de cost din aglomerările urbane: Slatina, Potcoava, Draganesti-Olt,

Piatra-Olt şi Scornicesti.

La nivel de dispecer va exista o interfaŃă grafică unitară care va „colecta” întreg

fluxul informaŃional achiziŃionat din proces, oferind operatorului posibilitatea

monitorizării şi controlului activităŃii de exploatare.

InterfaŃa grafică de operator (GUI – Graphical User Interface) va avea o structură

dinamică (colorarea dinamică) bazată pe medii vizuale; structura ecranelor şi

detalierea elementelor constitutive va fi punctată în capitolul de grafică şi va fi

detaliată şi elaborată în format final în faza de inginerie (premergătoare fazei de

SAT – Site Acceptance Test). Grafica va fi construită în conformitate cu

solicitările şi strategia de exploatare a Beneficiarului.

(ii) Debitmetria de reŃea din cele 5 aglomerari urbane va fi monitorizată în timp real

direct de la nivelul de conducere al dispeceratului regional. Cu alte cuvinte pentru

aceste locaŃii DTR va realiza o monitorizare in timp real şi o generare de rapoarte

în vederea controlului permanent al acestui tip de activitate.

(iii) Protocolul de comunicaŃie între dispeceratele locale şi sistemul SCADA de

dispecer va fi OPC (OLE for Process Control). Protocolul de comunicatie folosit

pentru achizitionarea informatiei de la echipamentele de telemetrie (debitmetre)

respectiv echipamentele care se vor interfata cu dulapurile de automatizare ale

48

statiilor de pompare sau monitorizare debitmetrie pentru realizare balanta, va fi

unul din protocoalele de proces: DNP3.0 sau Modbus, in functie de solutia

aleasa de fiecare ofertant.

(iv) Pachetul software-ului de aplicaŃie care va rula constitui platforma SCADA a

sistemului de dispecerizare regional de dispecer va cuprinde obligatoriu

următoarele module:

• AchiziŃie şi control proces;

• Rapoarte;

• Centralizare şi procesare si validare a datelor achiziŃionate;

• Portal web;

• Modul de gestionare al clientilor si al procesului de mentenanta.

Notă

Detalierea modulelor software aferente platformeu SCADA este prezentată explicit în

secŃiunea dedicata software-ului de aplicatie.

W3

Pentru a demonstra intelegerea exacta a solicitarilor, ofertantul va trebui sa:

• Detalieze in viziune proprie (particularizat pe solutia ofertata) dar bazata pe

arhitectura de retea detaliata la capitolele anterioare, modalitatea de rutare a

informatiei prelevate de la nivelul procesului si interschimbata cu nivelul central

SCADA-DTR.

• Sa prezinte schematic (schema bloc/schema logica) si in descriere functionala,

fluxul datelor in sistemul informatic propriu proiectat si ofertat, tinand totodata

cont de fluxul informational furnizat de sistemele SCADA locale, modulele de

validare de date si analiza, baza de date in timp real (RTDB), etc.

• Schema de la punctul anterior va trebui sa includa si modalitatea prin care

ofertantul prevede integrarea in viitor in SCADA-DTR si a modulelor de GIS si

Modelare Hidraulica, module care au fost dezvoltate independent de Compania

de Apa Olt pe alte proiecte.

49

• Descrierea solicitata trebuie sa evidentieze in viziunea proprie a ofertantului

modalitatea prin care arhitectura propusa realizeaza urmatoarele deziderate:

o Utilizabilitatea, ergonomia si accesibilitatea modulelor functionale;

o Scalabilitatea, flexibilitatea si modularitatea;

o Utilizarea standardelor de interoperabilitate;

o Actiuni sau unelte (tools-uri) orientate clar spre medii descentralizate;

o Generarea de rapoarte care sa se realizeze in conformitate cu o soluŃie

deschisă şi flexibilă.

6.6 Cerinte Hardware ale sistemului SCADA-DTR

În cele ce urmează sunt descrise principalele echipamente hardware (şi funcŃiunile

acestora) care stau la baza constituirii Dispeceratului de Telecontrol Regional.

Pozitie Denumire

echipament Cantitate Functiuni generale de echipament

1.0 Echipamente amplasate in camera IT & C a Dispeceratului de Telecontrol Regional

Slatina

1.1 Dulap industrial servere rack-abil 19” [Network cabinet] + conectica aferenta acestuia.

1 ConŃine rack PC-urile (staŃii de lucru operator, servere SCADA, server date) şi echipamentele de reŃelistică şi alimentare utilizate pentru telecontrolul staŃiilor.

1.2 Server SCADA – rack-abil 19” [Rack PC – 19”]

2 Servere industriale rack-abile 19” cu funcŃia de servere de proces în conexiune redundantă (master-reset), pe care rulează exclusiv aplicaŃiile specifice sistemului SCADA.

1.3 Server WEB – rack-abil 19” [Rack PC – 19”]

1 Server utilizat pentru difuzarea informaŃiilor în format web accesibil tuturor utilizatorilor (autorizaŃi printr-un proces prealabil de autentificare).

50

1.4 Server de aplicatii de tip rack-PC 19”.

1 Server utilizat pentru rularea aplicatiilor conexe specifice platformei SCADA (ex. modulul de gestiune a informatiei, modulul de generare rapoarte, modulul de mentenanta si management clienti).

1.5 Server de tip rack-PC 19” pentru gestionarea bazei de date.

1 Server utilizat pentru rularea bazei de date aferente platformei SCADA.

1.6 Sistem de Back-up

1 Cabină de discuri + software-ul aferent dimensionat pentru a asigura o politică de Back-up pentru sistemele existente în sistemul informatic al DTR.

1.7 Sursă de tensiune neîntreruptibilă (UPS 3kVA)

2 Alimentează cu tensiune neîntreruptibilă server-ele şi echipamentele de retelistica considerate consumatori vitali neîntreruptibili. UPS-urile sunt configurante în structură redundantă pentru a se asigura alimentarea continuă în cazul apariŃiei eventualelor indisponibilităŃi.

1.8 Consolă management + Switch KVM.

1 Managementuladministrare/configurare/mentenanŃă) integrat al serverelor şi staŃiilor de lucru rack-ate în dulapurile de servere. Consola de management va conŃine următoarele componente: monitor LCD 17” rabatabil şi tastatură + track ball încorporat, montate pe sertar glisant.

1.9 Router de retea 2 Router cu VPN şi mecanisme de securizare a accesului în Internet

1.10 StaŃie de lucru operator tip rack-PC 19” (HMI).

2 StaŃie de lucru operator (HMI) pe care rulează interfaŃa grafică om-maşină (GUI) care asigură interfaŃarea operatorului cu procesul condus.

1.11 Concentrator de date

In functie

de solutia

propusa

Are rolul de colectare a tuturor datelor transmise de la punctele de achizitie de date și convertor de format pentru mediul industrial.

1.12 Ansamblu GPS (antenă, conectică, convertor) folosit pentru sincronizarea de timp – data/oră

1 Este folosit pentru a furniza serverelor SCADA ştampila de timp cu care vor fi amprentate evenimentele prelevate din proces. Acest timp este considerat referinșă (etalon) pentru toate evenimentele din sistem.

1.13 Echipament de climatizare – instalaŃie de aer condiŃionat

1 ansablu Numărul de echipamente din camera/locașia IT fiind suficient de mare este necesară asigurarea unui microclimat adecvat pentru o funcșionare în condișii optime. Acest lucru presupune echiparea camerei sau locașiei în care sunt plasate dulapurile cu servere cu un dispozitiv de climatizare care să asigure o temperatură şi umiditate în limitele prescrise de furnizorul de echipamente IT.

51

1.14 Server GSM/GPRS

In functie

de solutia

propusa

Server cu rol de management si securitate pentru datele preluate din câmp prin GSM/GPRS si transmiterea acestora catre SCADA.

1.15 Integrator de mesaje

1 Are rolul de a asigura pe o platforma comuna schimbul de date intre aplicatiile informatice ale sistemului.

2.0 Echipamente amplasate in camera de comanda a Dispeceratului de Telecontrol Regional

Slatina

2.1 Monitor LCD 2 2 monitoare sunt alocate stașiilor de lucru operator (descrise la pct.1.4) pe care rulează interfașa grafică om-mașină (GUI);

2.2 Set periferice: Tastatura + Mouse

2 2 seturi sunt alocate stașiilor de lucru operator (descrise la pct.1.4) pe care rulează interfașa grafică om-mașină (GUI); respectiv statiilor de lucru operator din punctele de lucru implementate pe activitatea de telemetrie.

2.3 Extender KVM 2 kit-uri Folosit pentru prelungirea perifericelor de tip Keyboard+Video+Mouse aferente staŃiilor de lucru HMI din dulapurile unde sunt rack-ate unităŃile până la pupitrul operatorului unde sunt plasate aceste periferice.

2.4 Imprimantă de evenimente [Event Printer]

1 Imprimantă matricială numită şi „on-line printer”, folosită pentru listarea în timp real a fiecărui eveniment (schimbare de stare) apărut în sistem.

2.5 Monitor LCD 1 Se foloseste un display LCD min.47” pentru vizualizare tuturor schemelor sinoptice aferente staŃiilor integrate în SCADA/DTR, cu posibilitatea de expandare pe întreg ecranul a oricărei scheme sinoptice. Folosirea LCD se justifică prin faptul că schemele sinoptice sunt statice şi după o funcŃionare îndelungată pot impregna (impresiona) stratul de luminofor al unor eventuale display-uri în tehnologie CRT sau Plasmă.

2.6 Imprimantă rapoarte [Report Printer]

1 Este o imprimantă de tip laser-jet color A4 care va fi folosită pentru listarea rapoartelor / evenimentelor / ecranelor / sau a situaŃiilor neconforme care pot apare în exploatarea sistemelor SCADA. InformaŃia hard-copy livrată de aceasta va fi utilizată pentru întocmirea rapoartelor de evenimente sau constituirea unor arhive fizice utile în procesele de mentenanŃă/service a sistemelor SCADA. Această imprimantă este o imprimantă de reŃea fiind partajată tuturor PC-urilor LAN-ului.

2.7 Ansamblu mobilier pentru posturile de lucru

1 furnitura Mobilierul este compus din pupitru operator specific dispeceratelor de telecontrol, 2 scaune ergonomice de dispecer şi 2 suporturi de mobilă speciale pentru imprimantele alarme si evenimente.

52

3.0 Echipamente amplasate in site-uri

3.1 Dulap de automatizare tip 1

In functie

de solutia

propusa

Ofertantii vor trebui sa detalieze solutia oferita si sa explice in detaliu cum se va realiza conectarea site-urilor la SCADA DTR, justificand numarul si tipul echipamentelor alese astfel incat sa fie indeplinite cerintele caietului de sarcini

3.2 Dulap de automatizare tip 2

In functie

de solutia

propusa

Ofertantii vor trebui sa detalieze solutia oferita si sa explice in detaliu cum se va realiza conectarea site-urilor la SCADA DTR, justificand numarul si tipul echipamentelor alese astfel incat sa fie indeplinite cerintele caietului de sarcini

4.0 Echipamente specifice formatiei de inginerie de sistem SCADA

4.1 PC notebook 1 Folosit de echipa tehnică (coordonatorul echipei IT şi inginerii de sistem) exclusiv pentru informatica de proces (management IT, comunicaŃii, networking administration).

4.2 Trusă portabilă de scule electronist

1 Folosită de echipa tehnică (inginerii de sistem) pentru lucrări minimale de mentenanŃă / intervenŃii accidentale exclusiv pentru partea de informatică de proces.

6.7 Cerinte ale camerei Dispeceratului de Telecontrol Regional

6.7.1 MODUL DE AMPLASARE AL MOBILIERULUI ŞI AL ECHIPAMENTELOR DE OPERATOR

AFERENTE SISTEMULUI SCADA DE DISPECER.

Pentru creşterea gradului de securitate, siguranŃă în funcŃionare, ergonomie şi

optimizare a spaŃiului s-a propus ca activele hardware de reŃelistică şi servere să fie

rack-ate în camera IT iar camera de comandă a turei operative să conŃină doar display-

urile LCD şi perifericele (tastaturi şi track-ball / mouse).

(1) Monitoarele LCD 24” [2 buc.] aferente statiilor de lucru operator HMI1 si HMI2

vor fi poziŃionate pe pupitrul de teleconducere la cele 2 extremităŃi ale acestuia

împreună cu periferice (KV) aferente (vezi Anexa nr.8).

(2) Imprimanta de Raport [1 buc.] tehnologie laser jet, color, dispusă în partea din

mijlocul pupitrului de operator. Este o imprimantă de retea care este partajată

tuturor PC-urilor aferente sistemului SCADA de dispecer.

53

(3) Imprimanta de Evenimente [1 buc.] tehnologie matricială, format A4 , dispusă

în partea din fata pupitrului de operator. Este o imprimantă on-line care este

conectată la serverele de SCADA aferente sistemului de dispecer.

(4) Dispozitiv integrat pentru vizualizarea schemelor sinoptice plus conectica

aferentă de tip LCD Wall. Pentru o conducere operativă optimă de dispecer se

va folosi proiectarea imaginilor generate de PC-urile HMI (ieşirile HDMI) pe un

sistem de afişaj bazat pe tehnologia cu cristale lichide (LCD). Dimensiunea

dispozitivului de afişaj va fi de 47” iar acesta va fi prevăzut cu toată conectica

necesară şi cu functionalitate specifica care să permită comutarea fără

intervenŃie externă (hands-off) de pe un HMI pe celalalt în caz de defect (HMI

failure point). Din motive de ergonomie şi eficienŃă operativă, poziŃionarea

echipamentului se va face pe tavan, frontal şi centrat faŃă de pupitrul de operator

(6) Ansamblu mobilier pentru posturile de lucru operator, compus din

următoarele elemente:

• birou sectorizat operator tip desk;

• scaune operatori;

• suport office dedicat imprimantei de evenimente.

ObservaŃie

Dimensionarea pupitrului de operator şi a ansamblului mobilier pentru arhiva de

documente va fi stabilit în faza de DdE (Dtalii de ExecuŃie) in functie de amplasamentul

acestuia in camera de comanda si a cerintelor specifice ale Beneficiarului.

6.7.2 AMPLASAREA ECHIPAMNTELOR DE CALCUL SI RETELISTICA IN DULAPUL DE

ECHIPAMENTE

În vederea asigurării unui microclimat optim de functionare al echipamentelor IT&C

precum si al unui grad de securitate si fiabilitate cat mai ridicat, toate echipamentele de

calcul si retelistică vor fi rack-ate in cele 2 dulapuri de servere in conformitate cu Anexa

11.

Dulapul va contine rack-ate următoarele echipamente:

• Priza pentru server-rack multipost – care contine un număr suficient de posturi

de alimentare (prize) încât să fie capabil să alimenteze (din unitatea UPS 5kVA

54

Nr.1) toŃi consumatorii vitali neintreruptibili ai panoului (echipamentele de

reŃelistică şi echipamentele de calcul);

• Convertor GPS – conectat cu antena GPS care are rolul de a diviza impulsul de

tact de 1 secundă receptionat de antena la o rezoluŃie de milisecundă necesara

sistemului SCADA. Convertorul GPS este conectat la serverele SCADA pentru a

furniza ştampila de timp (timpul de referinŃă) cu care vor fi marcate toate

mesajele preluate din proces.

• Consolă de management (glisantă, retractabilă) – folosită pentru

managementul echipamentelor de calcul din dulap.

• Switch KVM management – folosit pentru conectarea tuturor PC-urilor

sistemului SCADA la consola de management

• Serverele SCADA – Server SCADA_1 (Principal) şi Server SCADA_2

(Redundant) care funcŃionează în conexiune Master-Reset (Hot-StandBy), având

aceeaşi prioritate în controlul procesului.

• Server Baza de Date – utilizat pentru stocarea bazelor de date ale platformei

SCADA.

• Server Aplicatii de Gestiune – utilizat pentru rularea aplicatiilor de gestiune

specifice platformei SCADA.

• Server Portal WEB – utilizat pentru aplicatiile de tip WEB client.

• Sistem de Back-up – format dintr-o cabina de discuri plus pachetul software

necesar; trebuie sa fie dimensionat pentru o politică de Backup suficientă pentru

sistemele existente în dispeceratul regional.

• StaŃie de lucru operator – HMI 1 şi HMI 2 pe care rulează simultan interfetele

grafice om-maşină şi care permit interacŃionarea interactivă a operatorului cu

procesul telecontrolat;

• Surse de alimentare neîntreruptibilă 3kVA, – folosite pentru alimentarea

tuturor echipamentelor IT&C din dulap.

• Router GPRS – utilizat pentru interconectarea tuturor punctelor de achizitie la

platforma SCADA a sistemului de dispecer.

• Concentrator de date - va prelua informaŃiile de la router –ul GSM/GPRS şi se

va putea interfaŃa prin diverse protocoale de comunicaŃie industriale cu

55

echipamentele din dispecerul central în vederea diagnosticării ulterioare şi

transmiterii datelor către serverul GSM/GPRS.

• Server GSM/GPRS – are rolul de management al datelor primite prin

concentratorul de date; managementul se va realiza prin intermediul unui

protocol industrial de mare viteză ales de ofertant. Pe lângă management, acesta

va oferi posibilitatea de securizare al datelor primite, prin intermediul unui firewall

dedicat, stocarea datelor într-o bază de date pentru realizarea ulterioară de

istorice, trend-uri şi care va permite trimiterea acestora la cerere către software-ul

SCADA.

W4

Pentru a demonstra intelegerea exacta a solicitarilor, ofertantul va trebui sa:

• Completeze matricea de complianta cu echipamentele hardware aferente

sistemului central SCADA-DTR, utilizate in solutia proprie ofertata. Totodata se

va descrie si detaliat si modalitatea de amplasare a acestor echipamente atat in

locatia sistemului central cat si in locatiile (obiectivele) care se vor integra in

sistemul central SCADA-DTR.

• Descrie tipul de pardosea tehnologica propus / ofertat, pentru a fi utilizat la

echiparea celor 2 locatii (camera de comanda si enclava IT&C) ale dispeceratului

regional precum si modalitatea prin care se va realiza climatizarea folosind

infrastructura de pardosea tehnologica. Descrierea va fi obligatoriu insotita si de

o schita/schema generala de amplasament si functionare a ansamblului

pardosea-climatizare.

6.8 Cerinte Software ale sistemului SCADA-DTR

6.8.1 CERINTE DE BAZA

• Software-ul SCADA va trebui sa respecte standardele internationale in vigoare

privind functii bloc reutilizabile pentru controlul proceselor.

• Sistemul SCADA trebuie sa fie un sistem integrat, deschis, interoperabil,

scalabil, modular. Aplicarea acestor concepte va trebui sa fie explicata si

detaliata de fiecare ofertant in cadrul ofertei sale.

56

• Scopul proiectului il reprezinta realizarea unui sistem SCADA care sa integreze

toate sistemele SCADA locale si punctele de achizitie a datelor intr-un

dispecerat regional. Aceste sisteme SCADA locale fac obiectul altor contracte

de lucrari.

• Ofertantul va demonstra capacitatea sa tehnica de a integra sisteme de

SCADA locale diferite, provenite de la producatori / furnizori diferiti, prin

certificari de partener integrator de la cel putin 2 producatori diferiti de software

SCADA.

• Sistemul SCADA va include un software SCADA si aplicatii complementare

care sa dezvolte si sa imbogateasca sistemul, aplicatii realizate in tehnologii

deschise, modulare la randul lor si cu o perfecta adaptare la specificul

sistemului.

• Software-ul SCADA trebuie sa dispuna de redundanta, scalabilitate,

independenta de producatorul de hardware, astfel incat beneficiarul sa aiba

libertatea de a achizitiona ulterior componente, module sau produse de la mai

multi producatori cu conditia asigurarii compatibilitatii intre sisteme.

• Software-ul de SCADA va fi format dintr-o interfata om-masina (HMI) cu suport

pentru supervizare si control al proceselor, achizitie de date in timp real, alarme

si gestiune a evenimentelor, recolectare a datelor istorice, generare de

rapoarte, comunicatii de telecontrol cu PLC/RTU-uri locale sau aflate la

distanta si acces la intranet/internet. Software-ul trebuie sa fie usor de utilizat

cu grafica dezvoltata in tehnologia orientata spre obiecte, arhitectura deschisa

si folosind ultimele tehnologii software ale Microsoft.

• Platforma software trebuie sa fie flexibil, pentru a permite o usoara configurare

in conformitate cu specificatiile utilizatorului.

• Platforma software trebuie sa poata fi scalabila de la o aplicatie simpla (unica,

stand alone) pana la o mare retea de control distribuit cu server sau servere

redundante de baze de date. Software-ul va trebui sa poata comunica sau sa

poata fi integrat cu usurinta in baze de date externe, software de modelare si

simulare, Enterprise Asset Management (EAM), Condition Based Monitoring

(CBM), Maintenance Management Systems (CMMS), ERP, LIM si sisteme

GIS.

• Software-ul trebuie sa poata suporta oricare din ultimele versiuni ale

urmatoarelor sisteme operative: Microsoft CE (doar pentru runtime in

57

dispozitive HMI specifice), Microsoft Windows XP, Microsoft Vista (Enterprise,

Business, Ultimate editions), Microsoft Windows 2003 si 2008 Server, Microsoft

Windows 7, Microsoft Windows 2008 Server R2. Cu exceptia Windows CE,

trebue sa fie suportate atat versiuni pentru 32 de biti cat si pentru 64 de biti. De

asemenea trebuie sa fie suportate versiunile Tablet pentru aplicatiile client.

• Software-ul SCADA trebuie sa suporte medii de virtualizare, incluzand

Microsoft Hyper-V si Vmware (ESX Server). De asemenea, software-ul trebuie

sa suporte hardware cu procesoare multi core si multiprocesor.

• Trebuie sa fie posibil ca, utilizand software-ul de dezvoltare SCADA, sa poata fi

realizata o aplicatie care sa permita schimbari dinamice de limba in modul

runtime. Sistemul trebuie sa suporte oricare din limbile suportate de catre

sistemul operativ.

• Trebuie sa se poata configura limbaje multiple (mai mult de doua).

6.8.2 MEDIUL DE DEZVOLTARE

• Mediul de dezvoltare trebuie sa ofere un mediu de programare multi-utilizator,

in care, programatorii sa aiba permise de securitate bazate pe roluri individuale

sau de grup.

• Mediul de dezvoltare al software-ului de SCADA trebuie sa fie orientat spre

obiecte si sa foloseasca un model de obiect care sa ii permita sa reprezinte cat

mai fidel caracteristicile fizice ale unui sistem SCADA, incluzand topologia

geografica, echipamentele si locatiile calculatoarelor. Sistemul trebuie sa

foloseasca conceptul de „Application Objects”. Aceste obiecte trebuie sa

reprezinte atat echipamente/instrumentatie reale (bucle PID, motoare, vane,

pompe, etc.) cat si obiectele de informatii (legaturile cu bazele de date, etc).

„Application objects” trebuie sa prezinte o imagine cat mai reala a sistemului si

sa sa nu fie legata de o topologie „tag-only”, oferind posibilitatea de a crea

structuri de date complexe, multi-variabile.

• Mediul de dezvoltare trebuie sa permita reutilizarea sabloanelor care pot fi

utilizate pentru crearea de noi sabloane, fara a pierde relatiile „tata-fiu” ale

definitiilor din obiecte.

• Mediul de dezvoltare trebuie sa foloseasca un depozit central pentru sabloane

si obiecte ale aplicatiei, ierarhia obiectelor, configurarea startului aplicatiei si

58

genealogia. De asemenea trebuie sa dispuna de optiunea de a folosi acelasi

depozit pentru stocarea si gestionarea aplicatiei de vizualizare.

• Mediul de dezvoltare trebuie sa permita ca programatorii cu drepturi de

configurare sa vada obiectele, cu scopul de a asigura faptul ca doar o singura

persoana poate schimba un sablon sau un obiect in acelasi timp.

• Depozitul trebuie sa poata fi utilizat doar pentru configurare si de aceea,

trebuie sa poata fi deconectat din sistem in timpul operarii in faza „run-time” a

sistemului.

• Mediul de dezvoltare trebuie sa includa o unealta pentru dezvoltarea

sabloanelor de obiecte. Aceste sabloane se vor utiliza pentru a crea obiecte

individuale care sa realizeze activitatile SCADA. Sabloanele de obiecte vor

putea contine alte sabloane de obiecte conform unei relatii ierarhice. Obiectele

create pornind de la sabloane vor contine configuratia generala a obiectului,

definitiile intrarilor si iesirilor sale, definirea atributelor sale interne,

documentatia de sprijin pentru configurarea obiectului, definitiile atributelor

create de utilizator, definitiile alarmelor si evenimentelor, a istoricelor ce trebuie

stocate si rutinele executabile.

• Mediul de dezvoltare va contine o baza de sabloane de obiecte care vor fi

incluse in produsul furnizat de catre fabricantul platformei de dezvoltare.

Produsul va include de asemenea, o unealta pentru crearea de obiecte care va

permite utilizatorului sa creeze noi sabloane de obiecte prin folosirea Visual

C++ si Visual C#.

• Sabloanele trebuie sa permita configurarea unei conexiuni la un sistem de

alarmare care sa suporte alerme si evenimente orientate spre conditii, cu

unelte predefinite care sa orienteze utilizatorul in procesul de definire a

configuratiilor de alarmare.

• Obiectele trebuie sa poata sa execute rutine logice pentru a creste nivelele de

alarmare, pentru a realiza sume si pentru a verifica valorile parametrilor

proceselor si pentru a executa actiunile de raspuns corespunzatoare. Pe de

alta parte, sistemul va suporta configurarea obiectelor care vor realiza

operatiuni de control de procese, pentru schimbarea starii semnalelor, pentru

prezentarea ferestrelor, etc.

• Mediul de dezvoltare trebuie sa includa un manager de comunicatii pentru

instalarea la distanta a obiectelor servere de comunicatii de intrari si iesiri, sa

59

activeze configuratii la distanta si sa realizeze operatiuni si diagnostice de

functionari incorecte. Se vor putea crea noi sabloane de obiecte prin operatiuni

de „mostenire” a sabloanelor, incluse de catre fabricantul platformei furnizate,

sau definite de catre utilizator. Sabloanele derivate din sabloanele existente vor

mentine orice nivel al ierarhiei sabloanelor de origine.

• Mediul de dezvoltare va contine urmatoarele: configurare de sabloane de

obiecte cu ajutorul ferestrelor de dialog, vizualizare si configurare a aplicatiei

utilizand o vedere de sus a instalatiilor, vizualizare si configurare de obiecte

prezentand in mod simultan genealogia obiectului de la sablonul de origine

pana la obiect.

• Mediul de dezvoltare trebuie sa furnizeze o supervizare-audit a intrarilor,

iesirilor si a istoricul versiunilor pentru fiecare sablon sau obiect al aplicatiei,

care sa includa ID-ul utilizatorului, data, ora si un rezumat detaliat al

schimbarilor efectuate.

• Mediul de dezvoltare trebuie sa permita importul si exportul modelului aplicatiei

catre un format ca de exemplu CSV (comma separated value) pentru editarea

sa intr-o aplicatie de tip Microsoft Excel.

• Trebuie sa se poata realiza un test functional al ecranului grafic prin comutare

in modul "run".

• Mediul de executie trebuie sa ofere o unealta pentru vizualizarea starii in timp

real a oricarui atribut al oricarui obiect al aplicatii in executie.

• Mediul de dezvoltare trebuie sa poata fi executat dintr-o sesiune Terminal

Services.

• Mediul de dezvoltare al sistemului SCADA trebuie sa fie capabil sa

administreze aplicatiile de vizualizare si sa poata distribui aplicatiile HMI

folosind „drag and drop". Schimbarile realizate in cadrul aplicatiei trebuie sa

poata fi propagate spre orice locatie din sistemul SCADA. Software-ul SCADA

va include un manager de aplicatii cu un „explorer" tip Windows pentru a

simplifica administraea aplicatiilor client. Managerul de Aplicatii trebuie sa

poata schimba rezolutia aplicatiei in mod dinamic astfel incat sa poata fi

utilizate statii de lucru cu diferite rezolutii grafice fara a fi nevoie sa fie refacuta

aplicatia.

60

6.8.3 EDITORUL GRAFIC

• Editorul grafic va include o serie de unelte de desenare pentru crearea

obiectelor simple si complexe. Selectand un icon din bara de unelte pentru

desen, se vor putea crea obiecte simple precum linii, dreptunghiuri, poligoane,

elipse, cercuri sau text. Oricaruia dintre aceste obiecte li se va putea atasa o

serie de atribute precum culoarea liniei, culoarea fondului, marimea, orientarea

si se va putea alege daca obiectul va fi static sau dinamic. Obiectele text vor

avea optiuni de scalare, ingrosare, subliniere sau inclinare.

• Toate obiectele vor fi scalabile si vor putea fi deplasate cu cate un pixel sau va

putea fi realizat „drag and drop” cu mouse-ul. Editorul de grafice va suporta

functii standard pentru manipularea obiectelor, de ex. „copy”, „cut”, „paste” si

„erase”. Va include unelte pentru alinierea obiectelor, pentru distribuirea in

spatiu , vertical sau orizontal, pentru deplasare, rotatie, grupare sau eliminare a

grupului.

• Editorul grafic va include o bogata librarie de obiecte complexe si simboluri de

proces, cum ar fi: aparate de masura, butoane de comanda, pompe, motoare,

rezervoare, vane, alarme, etc. Editorul grafic va trebui sa permita configurarea

obiectelor in asa fel in cat acestea sa se poata activa in functie de conditii din

proces. Sistemul va suporta librarii de obiecte configurabile care isi vor

schimba proprietatile in functie de optiunile selectionate in ferestrele de dialog.

Sistemul va permite importul de fisiere DXF, ca obiecte native ale platformei.

Editorul grafic va permite de asemenea importul desenelor in format BMP,

JPEG, PCX si TGA. Utilizatorul va trebui sa poata defini ecrane grafice in timp

ce sistemul este in modul de functionare „run”.

• Editorul grafic va dispune de o paleta predefinita de cel putin 48 de culori si va

fi posibil sa fie create palete personalizate de minim 16,7 milioane de culori.

Aceste palete vor putea fi exportate si stocate. Sistemul va putea suporta

folosirea de transparente, texturi pentru toate obiectele si fondurile.

• Alarmele trebuie sa fie vizualizate prin intermediul unui obiect proiectat special.

Obiectul trebuie sa poata fi redimensionat si trebuie sa dispuna de o fereastra

de dialog pentru configurarea sa. Configurarea implicita trebuie sa dispuna de

optiunea de putea fi modificata in timpul vizualizarii in modul „run”. Acest obiect

trebuie sa contina checks pentru a selecta si pentru a abilita sau a inabilita cum

apar alarmele in runtime. Alarmele trebuie sa poata fi codificate cu culori,

61

conform starii si prioritatii, incluzand cel putin: alarma identificata, neidentificata

sau alarma care a disparut fara a fi identificata. Utilizatorul va putea sa aleaga

intre cel putin 256 de culori pentru fiecare din starile respective. Ecranul de

alarme trebuie sa suporte o fereastra de evenimente , de asemenea cu un

minim de 256 de culori.

6.8.4 SOFTWARE-UL DE APLICATIE (SCADA)

• Software-ul SCADA trebuie sa poata suporta cel putin OLE , tehnologia OCX.

SCADA trebuie sa fie un depozit ActiveX cu suport pentru metode, proprietati si

evenimente pentru obiectele ActiveX. Faptul ca va suporta tehnologia ActiveX

va permite utilizatorului acesul imediat la o multitudine de OCX dezvoltate de

catre terti. Inregistrarea acestor controale in sistem trebuie sa poata fi facuta in

mod automat.

• Pe langa suportul ActiveX, software-ul SCADA trebuie sa ofere un suport

integrat pentru controale .NET. Sistemul trebuie sa poata distribui in mod

automat assemblies de .NET nodurilor-client, in timpul procesului de publicare

si desfasurare.

• Sabloanele de obiecte trebuie sa permita asocierea si configurarea unuia sau a

mai multor scripturi logice. Scripturile cuprinse intr-un sablon de obiect trebuie

sa poata utiliza cel putin tehnologia Microsoft.NET si sa poata fi compilate cu

.NET Common Language Runtime.

• Software-ul SCADA trebuie includa un limbaj de scripting care sa dea

posibilitatea executiei de comenzi si operatiuni logice si matematice bazate pe

conditii specifice sau actiuni ale utilizatorului. Utilizatorul trebuie sa poata edita

logica in timp ce sistemul HMI este in executie.

• Software-ul SCADA va da posibilitatea instalarii la distanta, cu toate

functionalitatile, a unei aplicatii, a derivatelor aplicatiei sau a oricarui software

de care este nevoie pentru executia aplicatiei. Acest lucru inseamna ca din

centrul de control se va putea actualiza un program client aflat la distanta fara

a mai fi nevoie de o deplasare in locatia clientului. Astfel se va putea realiza un

control centralizat al actualizarii aplicatiilor din tot sistemul.

• Software-ul SCADA trebuie sa includa un generator de grafice orientat spre

obiecte (Trend Viewer), cu capacitate puternica de animatie, care sa ofere

62

operatorilor o vedere reala a proceselor din sistemul SCADA. Toate

operatiunile de editare a graficelor trebuie sa poata fi realizate cu mouse-ul,

prin point-and-click si cu ajutorul meniurilor tip lista.

• Sistemul trebuie sa poata executa script-uri logice definite de catre utilizatori,

fara compilatoare externe. Logica sistemului trebuie sa permita executia

automata a functiilor, cum ar fi valori limita incrementale si valori limita totale, si

sa verifice valorile limita ale procesului pentru a putea executa actiuni. Logica

sistemului trebuie sa poata monitoriza starea fiecarei tagname a sistemului si

sa execute actiuni conform logicii definite.

• Sistemul trebuie sa fie capabil sa execute aplicatii de control prin scripting,

actiuni de la tastatura sau schimbari ale unui tag-name.

• Sistemul trebuie sa fie capabil sa creeze blocuri logice si sa salveze logica, ca

functie. Aceste functii vor putea fi executate in procese independente fata de

thread-ul procesului HMI, cu scopul de a nu incarca CPU-ul pentru proces.

Functiile logice vor putea fi apelate din alte functii.

• Sistemul trebuie sa fie capabil sa poata informa si alerta in legatura cu

resursele utilizate de catre sistem (folosire CPU, memorie, etc).

• Software-ul SCADA trebuie sa ofere redundanta pentru toate functiile incluse in

mod normal intr-o aplicatie SCADA: aplicatia, obiectele, alarmele, comunicatiile

si istoricele de date de proces. Redundanta aplicatiei trebuie sa fie nativa in

cadrul softului fara sa fie nevoie de o programare speciala, ci doar activarea

unui check-box si nu trebuie sa depinda de producatorul de hardware.

• Software-ul SCADA trebuie sa detecteze cel putin urmatoarele evenimente din

retea: eroare de comunicatie cu un PLC/RTU, eroare de comunicatie cu un

grup de PLC/RTU, eroare de comunicatie cu serverul de comunicatii, eroare

de aplicatie, eroare la imprimanta de alarme (off-line, lipsa hartie), eroare

managerul de alarme, eroare comunicatii cu partea de istorizare, abatere date

istorizare, spatiu insuficient pe hard disk.

• Software-ul SCADA trebuie sa detecteze orice posibila eroare si sa permita ca

statia client sa se conecteze fara interventia utilizatorului.

• Software-ul SCADA va dispune de o unealta pentru conversia protocolului DDE

la OPC si viceversa pentru a realiza comunicatii cu servere de comunicatii

oferite de terti.

63

• Software-ul SCADA trebuie sa dispuna de servere de „device integration”

pentru a putea stabili o interfata de comunicare cu echipamente de camp adica

PLC-uri, RTU-uri sau sisteme DCS. Aceste servere „device integration” trebuie

sa fie disponibile pentru toti marii fabricanti de PLC-uri de pe piata, cum ar fi

Allen Bradley, GE, Modicon, Siemens si pentru diverse RTU-uri si sisteme

DCS. Serverele de comunicatii cu PLC-urile trebuie sa suporte interfete via

direct serial, local control network precum Data Highway Plus, Modbus Plus

sau via TCP/IP Ethernet.

• Software-ul SCADA trebuie să includă un set de instrumente pentru analiza

datelor istorice şi în timp real, uşor de utilizat. Software-ul de analiză trebuie să

poată fi utilizat pentru inginerie, întreŃinere şi de catre operatorii de supervizare

care au nevoie de informatii din sistemul SCADA, dar nu au nevoie de acces la

ecranele grafice. Instrumente de raportare trebuie să poată accesa mai multe

servere de istorice. Utilizatorul accesează sistemul de rapoarte dupa ce se va

înregistra ca utilizator / parola în sistem. Utilizatorul nu trebuie să cunoască

locaŃia serverului de istorice, pur şi simplu este de ajuns cu numele de disc al

serverului. Software-ul de analiză de date trebuie sa includa instrumente pentru

analiza avansată a tendintelor, plotting X-Y de tagNames, şi de vizualizare a

rapoartelor in foi de calcul care urmează să fie formatate în mod liber. Toate

instrumentele trebuie să utilizeze butonul dreapta al mouse-ului, pentru

selectarea meniului. Instrumente de raportare trebuie să fie disponibile ca

software de sine stătătoare (stand-alone) sau ca si controale ActiveX care

urmează să fie încorporate în ecranele HMI ale SCADA.

• Software-ul SCADA va include o bază de date relaŃională, in timp real, pentru

a stoca datele procesului pentru o lungă perioadă de timp. Baza de date

trebuie sa suporte intre 250 si 1.000.000 de variabile ce vor fi inregistrate in

istoric. Baza de date trebuie sa fie ne proprietara, bazata pe Microsoft SQL

Server, ORACLE, MySQL sau PostgreSQL cu arhitectura client server, pentru

a permite accesul dinspre aplicatii externe, spre datele stocate, intr-o forma

transparenta, de exemplu ODBC, fara a fi nevoie sa se utilizeze programe

proprietare.

• Software-ul de SCADA trebuie sa poata importa variabilele definite in PLC-uri,

iar tagurile definite in PLC-uri sa se transfere automat in SCADA.

64

• Software-ul SCADA trebuie sa includa un portal web care sa asigure:

administrarea continutului WEB pentru a oferi informatia in timp real,

configurarea de rapoarte, grafice si generarea automata a acestora si va trebui

sa includa posibilitatea de a vizualiza ecranele SCADA, utilizand tehnologia de

acces la distanta Terminal Services.

6.8.5 MECANISMUL DE GESTIONARE A ALARMELOR

• Alarmele trebuie sa fie detectate si raportate de catre un Servici de

Administrare a alarmelor. Acest servici treebuie sa fie capabil sa suporte cel

putin 2000 de ferestre client simultan. In cazul unei cascade de alarme (sute si

mii de alarme detectate intr-o secunda) managerul de alarme trebuie sa

raporteze si operatorul trebuie sa poata vizualiza cel putin 900 de alarme intr-

un interval de 10 secunde de la detectarea alarmelor.

• Alarmele trebuie sa fie stocate intr-o baza de date Microsoft SQL Server sau

MSDE (Microsoft Database Engine). Evenimentele de alarma ce se vor stoca

trebuie sa contina alarma, return-to-normal si identificarea alarmei. Elementele

ce se vor stoca pe langa evenimentul de alarma, trebuie sa includa data si ora

alarmei, grupul alarmei, tagname, tipul de tag (real/enter/boolean), tipul alarmei

(LoLo, Lo, Hi, HiHi, ROC, Deviere, disc, etc), numele operatorului, nodul

operatorului care a identificat alarma si prioritatea alarmei. Trebuie sa fie

disponibil un servici de curatire a alarmelor si trebuie sa se poata stoca alarme

anterioare unei anumite date definite de catre utilizator.

• Alarmele trebuie sa poata fi trimise catre o imprimanta locala sau de retea.

Alarmele imprimate dintr-un anume nod, vor fi cel putin: toate alarmele, doar

cele identificate, alarmele unui grup sau a mai multor grupuri, alarmele cu un

anumit grad de prioritate sau alarmele de la diversi furnizori de alarme.

6.8.6 PLATFORMA SCADA. INTERACTIUNEA GUI CU OPERATORUL.

• Aplicatia SCADA va fi bazata pe o arhitectura distribuita. Trebuie sa fie posibila

scalarea arhitecturii de la un nod fara comunicatie cu alta aplicatie , pana la o

arhitectura de cel putin 100 de noduri. Arhitectura trebuie sa cuprinda un model

cu multiple calculatoare, care trebuie vazut ca o singura aplicatie in mediul de

executie, si care sa nu necesite replicarea datelor de la un nod la celalalt.

65

• Obiectele aplicatiei si atributele trebuie sa fie accesibile dupa numele

ierarhizate ale obiectelor sau prin tagname.

• Arhitectura trebuie sa poata sa suporte instalarea la distanta a programelor de

comunicatii fara a fi nevoie sa se reinstaleze software-ul manual, sa permita

administrarea centralizata si controlul in starea „run” a sistemului, se se

opereze in timp real manevrand date tranzactionale si evenimente in intervale

de milisecunde, sa se monitorizeze si sa se raspunda la mari volume de date

asioncrone si mesaje de mii de evenimente pe secunda. Trebuie sa suporte

pana la 1.000.000 de puncte de comunicatii si pana la 100 de noduri in reteaua

distribuita.

• Obiectele aplicatiei trebuie sa se poata conecta la orice driver de comunicatii

folosind protocoale tip DDE/NetDDE, Suitelink sau OPC.

• SCADA trebuie sa permita marca de timp in origine, adica va putea sa ia ca

marca de timp a evenimentului cea propusa de PLC sau RTU. Datele cu marca

de timp vor putea fi vizualizate pe ecran sau stocate in istorice de proces sau

de alarme.

• Atat mediul de dezvoltare cat si cel de runtime trebuie sa poata utiliza serviciile

de securitate ale sistemului de operare propus, pentru a permite utilizatorilor sa

vada, sa configureze sau sa modifice sabloane sau Obiecte de aplicatie.

• Sistemul de securitate trebuie sa suporte un model ierarhizat si bazat pe

obiecte care sa permita atribuire de permise pentru configurarea bazei de date

si a permiselor operative legate de runtime si accesul la vizualizarea anumitor

ferestre. Permisele operative pentru rutime ar trebui sa permita cel putin:

accesul sau blocarea identificarii alarmelor, modificarea atributelor de

configurare, modificarea atributelor operative care permit operatorilor acceptati

sa realizeze activitatile de zi cu zi, (cum ar fi schimbarile de valori limita, iesirile,

modul de lucru pentru un obiect PID sau comanda unui dispozitiv), deschiderea

si vizualizarea unei ferestre de proces sau a aplicatiei, modificarea atributelor

care permit utilizatorului sa regleze un atribut in mediul runtime (sensibilitate

PIDE sau valorile limita pentru alarme). Din motive de securitate toate

schimbarile in runtime ale valorilor obiectelor trebuie sa fie supuse autorizarii.

Utilizatorii vor trebui sa se identifice in sistem prin procedura de sutentificare

inainte de a putea realiza orice schimbare.

66

• Orice schimbare in runtime a unei variabile trebuie sa provoace o supervizare-

audit al ID-ului utilizatorului, numelui complet al acestuia, al valorii anterioare si

al noii valoari.

• Operatorul Software-ul SCADA trebuie sa poata realiza de la statia sa de lucru

toate functiile de supervizare si control. Comenzile cele mai comune includ

modificarea de valori limita, recunoasterea alarmelor si limitelor acestora,

activarea automata si manuala a dispozitivelor din teren. Operatorul va trebui

sa poata avea acces la toate functiile SCADA , din orice statie de lucru din

retea, fara a avea nevoie sa cunoasca in ce server al sistemului SCADA este

baza de date de istorice si configurarea ecranelor postului sau de lucru.

Platforma de dezvoltare va include o unealta pentru generarea de ecrane

grafice color cu animatie completa, in asa fel in cat sa se poata prezenta

operatorului o imagine cat mai reala a procesului.

• Operatorul va interactiona cu aplicatia SCADA prin intermediul iconurilor usor

de recunoscut si a meniurilor lista sau de ecran complet. Operatorul va putea

avea acces simultan la mai multe ecrane si la un numar nelimitat de ecrane de

ajutor sensibile la context prin apasarea unei taste sau a unui buton de mouse.

Navigarea prin diferite ecrane nu va necesita in general utilizarea tastaturii

alfanumerice.

• Statia de lucru operator va utiliza modelul de securitate definit in baza de date

de configurare. Sistemul de securitate trebuie sa permita inutilizarea/inhibarea

controlurilor ferestrelor (inchidere, diminuare fereastra, etc) si a comenzilor via

tastatura (Ctrl-Esc, Alt-Tab, Ctrl-Alt-Del).

• Sistemul va putea fi pornit in mod automat, fara compromiterea securitatii

sistemului operativ, fiind executat ca servici Windows.

• Toate actiunile operatorului se vor inregistra intr-un registru de evenimente

care va permite trasabilitatea operatorilor, a modificarilor parametrilor de

control sau a controlului dispozitivelor. Fiecare registru va stoca data, ora,

operatorul care a realizat modificarea si tipul de actiune realizata.

• Operatorul trebuie sa poata vizualiza informatiile despre alarmele actuale si

istorice intr-o fereastra cu un rezumat al alarmelor sau intr-o zona dedicata , in

partea inferioara a oricarui ecran. Informatiile despre alarme trebuie sa fie

afisate in ordine cronologica, cu alarma cea mai recenta in partea superioara.

67

Informatiile alarmelor care pot fi vizualizate trebuie sa includa data si ora,

descrierea, tagname, starea alarmei, tipul de alarma (lo, lo-lo, hi, hi-hi, rate-of-

change, etc), valoare, identificare, operator, nivelul de prioritate a nodului de

identificare, alarma sau numele si sablonul grupului din aria de proces.

• Trebuie să fie posibil ca operatorul sa poata filtra fereastra de alarme,

bazandu-se pe nivelul de prioritate, grupuri de alarme sau zona de proces. În

sistemele de reŃea distribuite, alarmele trebuie să fie vizualizate şi identificate

de la orice statie de lucru şi informaŃiile trebuie să fie distribuite tuturor

clienŃilor. Numele operatorului si nodul de identificare a alarmei trebuie sa

poata fi vazute in rezumatul alarmelor.

• Sistemul trebuie să fie configurat astfel încât operatorul sa fie anuntat de

alarma, indiferent de fereastra in care se afla. Avertizarea trebuie să includă

opŃiunea unei alarme pop-up, un simbol intermitent (de exemplu, un rezervor),

un mesaj de text de alarmă disponibil în toate ferestrele sau un ecran de

alarmă dedicat oriunde pe ecran.

• Ecranul rezumat de alarmă trebuie să furnizeze scroll orizontal şi vertical.

Afişarea acestor bare trebuie să fie configurabila . Ecranul rezumat de alarmă

ar trebui să poată să fie redimensionabil în runtime, prin selectarea liniei de

coloane şi definind lăŃimea. Ecranul de alarmă trebuie să suporte până la 8

combinatii de culori diferite, în funcŃie de prioritatea de alarmă şi daca a fost

identificata sau nu. Culorile trebuie să fie selectabile de catre utilizator, dintr-o

paleta de 256 de culori. Sistemul trebuie să fie capabil de a notifica utilizatorul

atunci când se produce o alarmă nouă. Ecranul de alarme trebuie să se

deplaseze la noua alarma în mod automat atunci când utilizatorul s-a mutat în

jos în listă.

• Ecranul alarmelor trebuie să poată recupera informaŃii de la alarme realizand o

interogare serverului pentru alarme. Interogarea de alarme trebuie să permita

specificarea unui nivel de "prioritate", stari de identificare, grup de alarma sau

alarma istorica sau insumata. De asemenea, trebuie sa fie posibila combinarea

acestor parametri pentru interogare şi filtrarea rezultatelor.

• Operatorul trebuie să aibă posibilitatea de a crea noi interogari de alarme in

runtime şi de a le salva pentru reutilizarea posterioara.

68

• Operatorul trebuie să fie poata să identifice alarme individual, de grup sau de

zonă.

• Operatorul trebuie să poata să identifice doar acele alarme vizibile pe ecran,

numai cele selectate, doar cele mai recente sau toate ale sistemului. Ecranului

de alarme trebuie să permită selectarea alarmelor doar realizand un click

deasupra lor, in runtime.

• Operatorul trebuie să aibă posibilitatea de a suprima alarme pe ecranul local.

Suprimarea de alarme de către un operator nu trebuie să afecteze ecranele

altor operatori.

• Trebuie să fie posibilă re-afişarea unei alarme suprimate, printr-un simplu click

de mouse.

• Operatorul trebuie poată să selecteze o alarmă din ecranul de alarme şi

sistemul trebuie să comute la fereastra corespunzatoare secŃiunii particulare a

sistemului din care provine alarma.

• Platforma SCADA trebuie să fie capabil de a efectua notificarea de alarme la

distanŃă, prin email şi / sau telefon, pentru personalul selectat pe baza unei

programari. Notificarea telefonica va dispune de un sistem de securitate si va

putea sa interactioneze cu SCADA prin tastatura, pentru a introduce codurile

de securitate necesare, introducerea parolei, recunoaşterea alarmelor şi

schimbarea de valori limita.

• Operatorul va putea efectua toate funcŃiile de control ale monitorizarii şi

supervizarii, dintr-o statie de lucru thin client. Nu va fi nevoie să se instaleze

nici un software specific de client SCADA în aceasta statie de lucru. Va fi

suficient doar ca statia de lucru sa dispuna de firmware-ul sau software-ul

necesar pentru a realiza o sesiune de terminal intr-un mediu cum ar fi sistemul

de operare Windows 2000 sau 2003. Software-ul SCADA HMI trebuie sa

suporte Microsoft Terminal Services Advanced Client pentru a putea fi

executat din Microsoft Internet Explorer .

• Sistemul trebuie să includă un instrument care sa permita utilizatorilor să

vizualizeze tagNames într-un format grafic sau sub formă de tabel. Acest

instrument trebuie să aibă un browser de tagNames (de tip Windows Explorer

sau similar) cu un filtru de căutare pentru a găsi cu uşurinŃă tagName in istoric.

69

• Utilizatorul trebuie să fie capabil sa creeze foldere pentru gruparea şi

vizualizarea de tagNames. Utilizatorul trebuie să aiba, de asemenea,

posibilitatea de a salva tendinŃele pentru a le viziona ulterior. Trebuie sa

dispuna de posibilitatea de a comuta între tendinta in timp real si cea istorica,

cu o casetă de selectare simplă.

• Software-ul de analiză trebuie să aibă controale ActiveX pentru clientii Trend si

Query astfel încât să poată fi încorporate în SCADA HMI sau orice alt depozit

ActiveX. Clientul de Query este folosit pentru a face interogări în baza de date

SQL Server şi pentru a inapoia rezultatele sub formă de tabel. Acest instrument

trebuie să suporte interogari pe mai multe servere pentru vizualizarea datelor

din surse diferite, simultan.

• Rapoartele trebuie sa poata fi prezentate in format HTML, Excel sau Word si

nu se va realiza/utiliza niciun tip de macro pentru realizarea acestora.

• Istoricul va permite stocarea datelor pentru fiecare variabila analogica , discreta

sau in format text si , de asemenea, evenimente, alarme şi datele de

configurare. Baza de date de istorice va obtine si stoca datele fără a realiza

niciun proces de comprimare şi va include o serie de instrumente de analiză a

datelor şi raportare.

• Baza de date trebuie să suporte achiziŃionarea de date la viteză mare şi

compresia eficientă a acestora.

• Fiecare valoare discreta stocată, scrisa in istoric trebuie să ocupe un spaŃiu de

aproximativ 7 octeŃi.

• Fiecare valoare analogică stocata în modul Delta sau Ciclic , scrisa in istoric

trebuie să ocupe un spaŃiu de aproximativ 10 bytes.

• Istoricul trebuie să poată stoca şiruri de text sau date, fiecare şir de text de

până la 512 de caractere si stocat impreuna cu campul de calitate a datelor

corespunzator.

• Procesul de stabilire a tabelelor bazei de date trebuie să fie automat şi sa nu

necesite nici o inginerie. DefiniŃiile datelor, inclusiv crearea de obiecte în baza

de date, cum ar fi tabele, indexuri, reguli, proceduri stocate, triggere, şi views

trebuie să respecte un standard, cu o schemă a bazei de date uşor de citit.

70

• Datele ce vor fi introduse in istoric, vor fi configurate din acelaşi editor al

obiectelor. Trebuie să fie posibilă configurarea ratei de stocare pentru fiecare

data a obiectului dupa o frecventa definta de utilizator (stocare ciclica) sau

dupa schimbarile de valoare (stocare delta). Stocarea ciclica trebuie să fie

posibilă de la 1 secunda pana la ore.

• Istoricul trebuie să accepte rezoluŃiile de până la 5 milisecunde pentru

tagnames configurare pentru stocare delta.

• Istoricul trebuie să poată obŃine date în mod automat şi manual. AchiziŃia de

date automata trebuie să fie realizata prin mijloace de transport de date

standard. Trebuie să suporte achiziŃionarea de date prin intermediul Dynamic

Data Exchange (DDE) şi OLE pentru Controlul Procesului (OPC), în plus faŃă

de utilizarea unor sisteme proprietare. Metoda de recuperare a datelor trebuie

să fie Structured Query Language (SQL). Trebuie să fie posibilă stocarea

datelor cu o rezolutie si recuperarea lor cu o alta rezolutie. Trebuie să existe

metode de interogare şi recuperare a datelor ciclic, cu rezoluŃie de milisecunde,

indiferent de metoda de stocare.

6.8.7 NIVELE DE SELECTIE AL CONTROLULUI AUTORITATII.

In vederea selectarii controlului autoritatii in sistemul SCADA-DTR se vor prevedea

urmatoarele ierarhii:

Nivel 0 (Nivel local)

Nivelul 0 este nivelul de prioritate cel mai ridical, definit ca fiind cel al punctelor

monitorizare presiuni, debite, clor remanent, dispecerate locale, staŃii pompare ape,

staŃii pompare ape uzate, camere deversoare, hidrofoare, nivele rezervoare.

FuncŃionarea punctelor care au doar funcŃia de transmitere date se realizează automat,

autonom, fără supraveghere permanentă. Toate funcŃiile punctelor acestora se vor

realiza local, la acest nivel, şi vor fi dependente de starea activă de funcŃionare a

sistemului dispecer a sistemului de comunicaŃie. Periodic (săptămânal) se vor realiza

inspecŃii în cadrul programului de exploatare şi întreŃinere.

Centrul dispecer va achiziŃiona datele în timp real, în scopul observării şi monitorizării

funcŃionării sistemului. Sistemul de automatizare va fi monitorizat, iar în cazul

evenimentelor neplanificate, se va activa o alarmă cu prioritate în funcŃie de tipul

evenimentului.

71

Centrul dispecer poate, la cerere, activa/porni respectiv dezactiva/opri activităŃile şi

regimurile de lucru la nivelul punctelor monitorizate.

Nivelul 1 (la distanŃă) – Nivel camera de comanda

Este un nivel intermediat transpus intre nivelul 0 (nivel local) si nivelul 2 (nivel de

dispecer – la distanta). Acest nivel este specific doar obiectivelor in care exista deja

implementat un sistem SCADA local (ex. statiile de epurare, dispeceratele locale ale

statiilor de tratare/clorinare). Din punctul de vedere al sistemului SCADA-DTR acest

nivel intermediar este vazut tot ca si un nivel local, existent la nivel de proces. Se va

tine cont de acest nivel la implementarea logicii de control al procesului de la nivel de

dispecerat (doar acolo unde este cazul).

Nivelul 2 (la distanta) – Nivel Dispecer Regional

Nivelul 2 (la distanta) de Dispecer este nivelul ierarhic superior al sistemului integrator

SCADA-DTR, considerat centrul de decizie in controlul procesului avand prioritatea cea

mai scazuta din punct de vedere al controlului procesului (comenzi directe catre

proces).

Centrul dispecer va funcŃiona permanent, principalele funcŃii fiind:

• monitorizarea performanŃelor sistemelor de automatizare, a locaŃiilor

monitorizate;

• optimizarea proceselor specifice punctelor monitorizate;

• diagnoza şi urmărirea entităŃilor sistemelor de automatizare ale punctelor

monitorizate;

• managementul alarmelor şi rapoartelor, în vederea iniŃierii unor acŃiuni corective

sau adoptării unor decizii executive sau de management;

Operatorul trebuie aiba capabilitatea de urmarire in in timp real folosind GUI/HMI a

datelor mapate din punctele de achizitie, într-un format care depinde de instalaŃia

monitorizată şi de tipul datelor: schemele sinoptice, curbele grafice de evoluŃie, tabele

de date, hărŃi specifice. Operatorul va avea drepturi pentru efectuarea unor comenzi de,

după o schemă de acces configurabilă. Operatorul va urmări alarmele care apar în

sistem, pe toata perioada pe timp .

Va fi posibilă definirea datelor care se achiziŃionează în mod constant, în timp real.

Definirea datelor se va realiza împreună cu Beneficiarul. Aceste facilităŃi sunt aplicate

punctelor de monitorizare unde se vor efectua comenzi de la distanŃă asupra

72

pornirii/opririi pompelor din staŃiile de pompare în funcŃie de presiunea reŃelei şi nivelului

din rezervoare.

6.8.8 CAPABILITATI SI FUNCTIUNI – PLATFORMA SCADA. MODULE SOFTWARE SPECIFICE.

Sistemul integrat SCADA va trebui sa fie capabil sa realizeze urmatoarele functii:

• Achizitie date, control si operare a intregului sistem.

• Sa ofere servicii pentru asistenta online si dublarea comenzilor de la distanta.

Infrastructura de comunicaŃie trebuie sa permita monitorizarea şi controlul de la

distanŃă pentru un număr minim de puncte din aplicaŃia beneficiarului, cel puŃin

500 plus o rezervă de 25%. Dacă transferul de date se face, pe unele (sau pe

toate) segmente, prin reŃele publice (spre exemplu prin reŃeaua Internet) atunci

respectivele segmente trebuie securizate corespunzător. Interfata grafica cu

utilizatorul va fi similară cu cea disponibilă în cadrul dispeceratului beneficiarului,

cu date actualizate permanent folosind tehnologie OPC. În caz de necesitate, se

vor putea face şi acŃionări de la distanŃă.

• Sa ofere simulatoare de proces industrial, realizate folosind automate

programabile dedicate şi automate pentru închidere de urgenŃă de tip ESD.

• Sa ofere capabilitati de integrare cu platformele pentru modelare hidraulica si sa

permita simulari numerice complexe pe o infrastructură de tip GRID computing

integrată cu soluŃia oferită.

• Sa puna la dispozitie o bază de cunoştinŃe online pentru operarea sistemului

instalat, conŃinând următoarele domenii: monitorizarea datelor, acŃionare de la

distanŃă, generare de rapoarte, tratarea alarmelor, consultarea arhivelor.

• Sa ofere o baza de date in care datele vor fi stocate si accesibile in tabele,

conform formatului datelor relationale. O baza de date relationale are un nume si

coloane , care o definesc. Datele sunt stocate pe randuri. Tabelele pot fi

relationate intre ele; Baza de date este organizata fizic in fisiere, iar

corespondenta intre fisiere si tabele este posibila datorita structurii interne a

bazei de date, care permita ca diferite tipuri de date sa fie stocate in locatii

diferite. Aceasta impartire logica se realizeaza cu ajutorul spatiilor pentru tabele;

Baza de date trebuie sa dispuna de o unealta grafica de administrare, intuitiva si

foarte usor de utilizat; Unealta de administrare a bazei de date oferită cu Baza de

date trebuie să includă următoarele caracteristici: o fereastră SQL pentru a

construi şi executa scripturi, o fereastră pentru a salva şi afişa scripturi SQL, o

73

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 interfaŃă pentru a efectua sarcini legate de

următoarele funcŃii ale bazei de date: stocare, backup, recuperare. Baza de date

trebuie să permita restricŃionarea accesului la nivelul obiectelor bazei de date in

functie de drepturile de acces ale utilizatorilor; Tipuri de date suportate: XML,

text, documente, imagini, audio, video; Accesul la date se realizeaza prin

interfete standardizate, precum SQL, JDBC, ODBC, SQLJ, OLE DB, SQL/XML si

Xquery; Baza de date trebuie sa poata lucra in sistemele de operare de tip

enteprise precum cele ale platformelor Windows, Linux, Unix, trebuie să ofere o

facilitate pentru salvarea totala şi/sau parŃială a bazei de date;Trebuie să ofere o

facilitate pentru restaurarea totala şi/sau parŃială a bazei de date; Trebuie să

permită salvarea online a bazei de date direct pe bandă; Trebuie să aiba

posibilitatea scrierii si citirii în mai multe fişiere pe disc simultan în timpul unei

operaŃii de salvare, in vederea cresterii performantei; Trebuie să permita

constrângeri de tip cheie primară si cheie straina; Trebuie să ofere abilitatea de

impunere a constrângerilor pe coloane asupra tipurilor şi valorilor datelor;

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;

Trebuie să permită o arhitectură de înaltă disponibilitate; Trebuie să poata rula

pe sisteme de tip cluster in mod activ-activ; Trebuie sa asigure partajarea

automata a incarcarii intre nodurile cluster-ului in vederea maririi productivitatii;

nodurile din cluster trebuie să poată fi adăugate/eliminate din cluster în mod

dinamic, fără a fi necesară întreruperea bazei de date; trebuie sa permita

executarea comenzilor SELECT, INSERT, UPDATE si DELETE de tip multi-

tabelă, astfel încât să poată fi inserate linii dintr-o singură instrucŃiune în mai

multe tabele; Trebuie să suporte indecşi in vederea regasirii rapide a

informatiilor; sa permita posibilitatea de a defini indecsi de tip clustered si non

clusterd pentru a accesa mai rapid anumite tabele; sa permita posibilitatea de

interogare a informatiilor in anumite momente din trecut; suport pentru replicarea

informatiilor intre doua baze de date separate; suport tranzactii si suport pentru

proprietatile ACID; suport pentru tipuri de date numerice si caractere definite

conform standardului ANSI SQL; trebuie sa permita stocarea in mod nativ si

74

administrarea structurilor de date XML; sa permita scrierea procedurilor stocate

in limbaje native precum si limbaje orientate spre obiecte de tip enterprise

precum Java sau c# .NET; trebuie sa aiba posibilitatea de a cripta informatii

stocate in tabele; Aplicatia trebuie sa dispuna de urmatoarele module: un modul

de reporting care sa ofere acces la date si prezentarea informatiei catre

organizatie, acces la date din diferite surse RDBMS, XML, export in diferite

formate - HTML, Excel, PDF, Text si difuzare de rapoarte via web sau e-mail; un

modul de analiza care sa usureze explorarea si analiza de date in mod interactiv,

cu raspuns rapid, un modul de integrare de date care sa permita accesarea si

integrarea datelor, indiferent de locul de provenienta, baze de date, legacy

systems.

• Sa ofere o unealta care sa asigure fiabilitatea datelor generate in sistem, prin

verificarea acestora intr-un proces automat si manual, care sa asigure

vizualizarea în formă grafică a datelor ce trebuie analizate si care sa permita

definirea de valori limita pentru validarea datelor prin raportare la valorile

instantanee şi la cele medii, sa ofere posibilitatea de a eticheta valori ca fiind

nevalide si sa permita , de asemenea, vizualizarea valorilor unei variabile sau

tag, în timp, în formă grafică sau tabelară cu posibilitatea de evidenŃia acele

valori care sunt în afara limitelor, pentru a putea fi „marcate” ca „nevalide”

evitând astfel procesarea lor de către sistemele expert. Aplicarea validării datelor

permite utilizatorilor să identifice valori obŃinute in teren care sunt în afara

limitelor sau foarte diferite de tendinŃele prevăzute, putand astfel sa evite

utilizarea acestora în sistemele expert tocmai pentru a preveni distorsionarea

procesului de analiză a datelor. AplicaŃia poate fi bazată pe o dezvoltare proprie

sau pe un produs comercial consacrat în domeniu.

• Sa ofere o unealta pentru gestionarea mentenantei tuturor activelor companiei

(incluzand aici, instrumentatia, echipamentele din teren, retelele de apa si

canalizare, statiile atat la nivel de edificiu cat si la nivel de echipamente, cladirile,

etc). Sistemul de management al mentenantei va dispune de client web, server

de aplicatii tip si arhitectura orientata spre servicii si trebuie sa fie prevazut cu

posibilitatea de a lucra in doua moduri: offline – in care trebuie sa permita

tehnicienilor care merg pe teren, sa caute, sa accesese si sa completeze

ordinele de lucru, fara a avea o conexiune de retea, atat in cazul laptopurilor cat

si in cazul dispozitivelor si modul mobil - care permite tehnicienilor care merg pe

teren, sa caute, sa acceseze si sa completeze ordinele de lucru cu ajutorul

75

telefoanelor mobile sau PDA-urilor. Aplicatia de management a mentenantrei

trebuie sa includa urmatoarele module dedicate: ordine de lucru (atribuire

resurse umane, materiale in stock, costuri, documentare si urmarire a

informatiilor relevante privitoare la cauza evenimentului, durata de nefunctionare

si recomandari pentru actiuni viitoare, etc), mentenanta preventiva (are functii de

urmarire a activitatilor de mentenanta, crearea instructiunilor pas cu pass au

checklists, liste de materiale necesare si alte detalii. Trebuie sa permita procese

de mentenanta, in mod automat, bazandu-se pe lectura diferitilor parametri ai

sistemului SCADA), gestiunea activelor (cuprinde registri referitori la

echipamente si proprietati ale institutiei, incluzand detalii, informatii despre

garantii, contracte de servicii, procese verbale pentru piese de schimb, si orice

alt parametru ce poate fi de ajutor pentru gestiune. In plus, trebuie sa poata

genera parametri, cum ar fi indicele de stare al infrastructurii), controlul

Inventarelor (cuprinde gestionarea pieselor de schimb, uneltelor si altor

materiale, incluzand aici stocurile de materiale destinate unor anumite lucrari,

evidenta materialelor din stoc, previziuni de achizitie de noi materiale, etc.),

securitate (cuprinde gestiunea permiselor si documentatiei necesare pentru a

indeplini normativele de securitate. Aceste specificatii vor include: accesul

restrans, pericole de natura electrica, izolare de produse si materiale sau

informatii despre riscuri, printre altele.).

• Sa ofere o unealta pentru gestiunea clientilor care trebuie sa fie modulara,

fiecare modul reprezentand cate un aspect functional al acesteia, ca de exemplu

modulul de Conturi, modulul de Activitati, modulul de Oportunitati, modulul de

Activitati, modulul de Clienti Potentiali, etc. Aplicatia trebuie sa fie bazata pe o

tehnologie web, trebuie sa fie compatibila cu sistemele de operare tip enterprise

precum Windows, Linux, sa poata fi integrata cu Microsoft Outlook, sa ofere o

personalizare rapida a interfetei de utilizator, sa includa managementul listelor de

contact, marketing pentru e-mail, managementul proiectelor, si unelte de

calendar. In cadrul aplicatiei se vor putea programa intalniri, convorbiri, activitati,

proiecte, mailuri, mass-mailuri, pentru utilizatorul curent sau pentru un alt

utilizator. Programul va fi foarte flexibil, oferind o organizare foarte eficienta a

activitatilor uneia sau mai multor firme va fi real time, avertizand utilizatorii logati

asupra taskurilor programate la un interval de timp prestabilit.

• Sa ofere servicii pentru transmiterea datelor prin exceptie. SoluŃia va avea

capabilitatea de a rezolva protocoale multiple de comunicatie, solutii de tip client-

76

server, capacitatea de memorare pe o perioada de timp a datelor, transmisie

date prin exceptie, filtrare, validari de date.

• Sa ofere servicii de telediagnoza si teleinterventie

o Va permite dublarea comenzilor dispecerelor locale de la distanŃă către un

operator remote pentru oferirea de servicii de mentenanŃă, back-up şi

eventual control la cerere pentru evitarea deplasării echipei tehnice la

dispecerele locale sau la dispecerul central .

o Serviciile oferite vor constitui un pachet modularizat care să permită

adaptarea stricta la opŃiunile clientului. In acest fel clientul nu va fi obligat

să suporte costul unor servicii nesolicitate. Principalele grupuri de servicii

oferite vor fi:

� Monitorizare in timp real a starii functionale a procesului tinta si

semnalarea posibilelor aparitii a situatiilor de risc.

� Interventia de la distanta, in situatii de urgenta, in scopul evitarii

pericolelor si pierderilor materiale si umane posibile.

� Analiza performantelor functionale si stabilirea actiunilor necesare

pentru optimizarea acestora din punct de vedere tehnico-economic.

� Asistenta de la distanta a personalului operator in perfectionarea

profesionala si/sau explicatii punctuale printr-un subsistem de

asistenŃă on-line.

• Sa ofere un portal Web care sa permita utilizatorilor valorificarea si exploatarea

informatiilor sistemului SCADA integrat, in functie de cerintele, atributiunile si

permisele de acces ale fiecaruia. Modulul va pune la dispozitie informatiile intr-o

forma integrata, indiferent de provenienta acestora sau de locul lor de stocare in

cadrul sistemului, va oferi un punct de acces unic destinat consultarilor pentru

obtinerea de informatii fiabile si pentru imbunatatirea si sprijinirea procesului de

luare de decizii, pentru toate nivelurile. Va fi bazat pe dezvoltarea de unelte

integrate (portal web) care sa exploateze in mod intensiv informatiile provenite

din diferite medii si tehnologii implementate in cadrul prezentei solutii. De

asemenea arhitectura trebuie sa fie bazată pe tehnologii deschise şi facilităŃile de

integrare, ce permit o extensibilitate facilă a sistemului, indiferent de modalitatea

aleasă pentru acest lucru. Forma de prezentare a informatiilor va fi personalizata

si orientata spre cerintele diferitelor tipuri de utilizatori care vor lucra cu aceaste

informatii. Astfel, mediul web va oferi unelte orientate spre utilizator, care nu va fi

nevoit sa cunoasca functionarea sistemului (locul de provenienta, felul in care

77

sunt procesate, etc) pentru a dispune si utiliza datele din sistem. Portalul pentru

consultari integrate va oferi urmatoarele facilitati: alarme (remainders, depasiri

ale valorilor limita stabilite, etc.), indicatori cheie de performanta (KPI) (tablouri

de bord operationale, tablouri de bord tactice), reporting (bazat pe tehnologia

Business Intelligence), analiza si consultari (pentru crearea de consultari si

rapoarte, navigare prin informatii, etc), portal mobil (orientat spre mobilitate),

portalul meu (orientat spre utilizator si spre posibilitatea de a configura propriile

continuturi). Cu ajutorul acestui mediu, operatorii vor putea sa insereze si sa

consulte informatii generale, cadrele de conducere intermediare si analistii vor

putea sa analizeze comportamentul istoric al sistemului (folosind tendinte,

sabloane, etc) si vor avea acces la rapoarte privind starea sistemului si executia

operatiunilor. De asemenea, cadrele de conducere superioare vor putea analiza

sistemul, intr-un mod simplu si rapid, starea, evolutia si nivelul serviciilor

existente in cadrul diferitelor procese ale organizatiei. Acest modul va trebui sa

contina cel putin urmatoarele sub-module, in functie de tipul informatiilor ce

trebuie publicate: sub-modulul SCADA (care va furniza utilizatorului informatia

cea mai recenta despre instalatiile din zona, atat alarme cat si masuratori din

retea, va furniza o lista cu alarmele semnalate in sistem, cu posibilitatea de putea

fi filtrate pe instalatii, zone sau perioade de timp, va oferi posibilitatea consultarii

valorilor oricarei masuratori ale echipamentelor din sistem), sub-modulul BI (care

va furniza informatii aditionale masuratorilor sau datelor din sistem si astfel,

utilizatorul va putea vizualiza in forma grafica sau tabelara toate datele istorice

ale masuratorilor din sistem si cele referitoare la calculele si statisticile furnizate

de catre baza de date a sistemului de BI, va furniza rapoarte predefinite si

posibilitatea ca fiecare utilizator sa-si poata personaliza propriile rapoarte), sub-

modulul de gestiune a mentenantei (care va furniza datele referitoare la

exploatare si la operatiunile de mentenanta realizate asupra tuturor

echipamentelor din sistem asupra carora sunt realizate activitati de mentenanta

atat preventiva cat si corectiva, va furniza utilizatorului o planificare a activitatilor

de mentenanta ce vor fi realizate intr-o perioada determinata si o unealta pentru

rapoarte pentru inregistrarea activitatilor realizate. Sistemul va fi capabil sa

genereze rapoarte de mentenanta in forma grafica sau tabelara, cu date despre

echipament, instalatie, zona, operator si perioade de timp), modulul de gestiune

a clientilor (care va oferi date pertinente despre clientii companiei).

78

6.8.9 COMUNICATII / DRIVERE

În principiu se impune ca necesară îndeplinirea cel puŃin a următoarelor condiŃii:

• Suport pentru standardul OPC şi protocolul de comunicaŃie standard folosit;

• Suport pentru principalii fabricanŃi de PLC-uri; (de ex. Omron, Allen Bradley,

Motorola, Siemens, etc) ;

• Realizarea gestiunii comunicaŃiilor cu echipamentele externe (RTU, PLC,

Data Logger, etc.);

• Posibilitatea de a lucra ca OPC Server pentru comunicaŃiile cu alte sisteme.

6.8.10 LICENTE

Ofertantul va avea obligativitatea furnizarii licentelor pentru toate aplicatiile (de proces

sau de operare) instalate pe PC-urile si echipamentele aferente sistemului SCADA-DTR

integrator. Se vor include licente pentru sistemele de operare, baza de date, software

de aplicatie si toate celelalte licente necesare pentru rularea sistemului.

6.8.11 MODUL DE INTERACTIUNE AL SOFTWARE-ULUI PLATFORMEI SCADA CU APLICATIILE DE

GIS SI MODELARE HIDRAULICA

In prezent exista achizitionat de catre OR, si aflat in implementare cu sprijinul asistentei

tehnice pentru managementul proiectului licente pentru urmatoarele programe specifice

gestionarii sistemelor de alimentare cu apa si canalizare:

� ARC GIS profesional, ESRI ARC EDITOR 9.3.1., pentru implementarea

sistemului GIS la nivelul OR.

� Softwere DHI Mike Urban, pentru programele de modelare hidraulica a

sistemelor de alimentare cu apa si canalizare

Aplicatiile propuse in cadrul subcap. 6.8 trebuie sa integreze softwere-ul deja existent.

6.8.11.1 Consideratii generale asupra software-ului de Modelare Hidraulica –

Mike Urban

Integrarea in cadrul aplicatiei software SCADA-DTR a modelarii hidraulice are ca scop

obtinerea automata, periodica si in timp real a modelului hidraulic, generand simulari

hidraulice care sa tina cont de conditiile curente dar si sa identifice viitoarele investitii.

Integrarea aplicatiei de modelare hidraulica in cadrul aplicatiei SCADA-DTR se va

realiza utilizand standardul OPC prin utilizarea datelor furnizate serverul OPC la nivelul

79

sistemului SCADA catre modulul DIMMS al programului modelare hidraulica Mike

Urban.

Aplicatia de modelare hidraulica va trebuie sa preia in mod automat din aplicatia

SCADA date referitoare la: nivel apa in rezervor, regim functionare vane si pompe,

debite si presiuni transmise prin debitmetre.

Toate aceste date furnizate de platforma SCADA vor fi folosite de aplicatia de modelare

hidraulica care va procesa datele si va simula pe baza algoritmilor de modelare

hidraulica specifici diferite regimuri sau comportamente procesuale. Toate aceste date

simulare vor fi transmise ca si feedback catre sistemul SCADA pentru a putea fi folosite

in procesul de analiza comparativa intre situatia masurata si modelul/modelele

simulat(e).

Modulul software de modelare hidraulica on-line Mike Urban este capabil de a primi in

timp real date de la sistemul SCADA prin putand elabora analize on-line ale starii de

functionare ale sistemului de apa putand raspunde totodata in situatiile in care apar

diferite modificari de sistem. In baza informatiilor furnizare in timp real de catre sistemul

SCADA despre starea sistemului de alimentare cu apa, utilizarea simularilor hidraulice

in timp real si in parametrii constanti poate realiza un calcul al debitelor si al presiunilor,

chiar la nivelul punctelor unde nu se pot fizic masura acesti parametrii.

Conceptul de integrarea al aplicatiei de modelare hidraulica in platforma SCADA-DTR

trebuie privit in contextul in care pachetul utilitar de modelare este parte integranta a

unui sistem complet de monitorizare-control care sa asigure un mod de lucru de tip

„senzor virtual” utilizat pentru o intelegere mai apropiata de realitate a sectiunii de

hidraulica a sistemului si mai ales pentru calibrarea modelelor si compararea automata

a debitelor si presiunilor masurabile de echipamentele de instrumentatie cu valorile

calculate prin algoritmii specifici. De asemenea, pentru ofertarea solutiei de integrarea a

aplicatiei de modelare in platforma SCADA trebuie avut in vedere si faptul ca rezultatele

generate de modelul hidraulic, analiza calitatii apei sau estimarea costurilor cu energia

trebuie sa fie disponibile in timp real in baza de date a sistemului SCADA cu

posibilitatea de a fi accesate rapid si inteligibil, fara operatiuni suplimentare de

conversie de format sau inginerie informatica. Tot sub acest aspect de integrare trebuie

formulata o solutie completa care sa permita avertizarea prestabilita a utilizatorului

atunci cand exista diferente semnificative intre valorile efectiv masurate de sistemul

SCADA si valorile calculate de modulul hidraulic.

80

W5

Pentru a demonstra intelegerea exacta a solicitarilor detaliate la subcapitolul 6.8

precum si asumarea acestora, ofertantul va trebui ca in baza principiilor descriese sa

detalieze urmatoarele:

• Modalitatea prin care aplicatia/aplicatiile ofertate indeplinesc cerintele de baza

ale platformei SCADA; descrierea editorului grafic punandu-se accent pe

cerintele specifice ale CS; detalierea mecanismului de gestionare al alarmelor si

al interfetei grafice cu utilizatorul; explicitarea modalitatii de implementare si

gestionare in cadrul SCADA-DTR al nivelelor ierarhice de selectie al controlului

autoritatii.

• Sa descrie cat mai detaliat (bazat pe produsul oferta) modulele software

constituente ale platformei SCADA utilizata in cadrul DTR, in conf. cu cerintele

CS. Sa specifice aplicatiile software licentiate si modalitatea prin care se face

licentierea.

• Sa descrie cat mai detaliat, utilizand si o schema bloc, modalitatea prin care

solutia ofertata realizeaza integrarea modulului de modelare hidraulica si a

pachetului GIS in cadrul platformei SCADA-DTR. Pentru ca evaluarea solutiei

ofertate sa se poata face cat mai corect si obiectiv, ofertantul va urmari exact

structura cu cerintele detaliate la subcapitolul 6.8.11.1, particularizand-o pe

produsul ofertat.

6.9 Cerinte pentru comunicatiile de date

6.9.1 CONCEPTUL DE COMUNICATII

Potrivit situatiei, solutiile de comunicatii trebuie sa fie construite pe baza serviciilor unui

furnizor de servicii de comunicatii. In consecinta, odata cu cresterea latimii de banda

necesara vom avea si o crestere a costurilor de comunicatie.

Comunicatiile de date, care in acest context inseamna schimbul informatiilor pe baza

cailor suportului radio de comunicatie, se fac prin intermediul canalelor inchiriate de la

unul sau mai multi furnizori de servicii de comunicatii GSM.

In ceea ce priveste sistemul de comunicatii, subiect al acestui Caiet de Sarcini, in cadrul

acestui contract / proiect trebuie realizate urmatoarele activitati:

81

• Transmiterea informatiilor de masura si control SCADA intre dispeceratele locale

sau sistemele SCADA locale aferente statiilor de epurare si Dispeceratul de

Telecontrol Regional.

• Transmiterea in sistemul SCADA-DTR a informatiilor de masura si control

provenite de la debitmetrele de masurare a debitelor din retelele celor 5 localitati:

Slatina, Draganesti-Olt, Piatra-Olt, Scornicesti si Potcoava. Sistemul de

comunicatii al debitmetrelor descrise la subcap.5.2 nu face parte din acest

contract / proiect, urmand a fi realizat in cadrul unui contract separat.

Arhitectura de comunicatii presupune implementarea unei retele de comunicatii private

pentru transmiterea informatiilor de masura si control SCADA de la punctele de achizitie

a datelor catre sistemul central SCADA-DTR. Canalul de comunicatii utilizat va fi de tip

GPRS/3G deoarece echipamentele de masura si control sunt dispersate pe o suprafata

mare care nu poate fi acoperita de un furnizor ISP traditional.

Pentru realizarea redundantei procesului de comunicatie, echipamentele (modem-urile)

ofertate in cadrul acestui contract vor fi de tip dual-SIM, pentru a putea fi echipate de

catre Beneficiar cu cartele de comunicatii date provenite de la furnizori diferiti de

telefonie mobila.

In acest scop Beneficiarul va contracta de la operatorii de telefonie mobila un

abonament de conectivitate caruia ii va fi asignat un APN individual pentru acest proiect

astfel incat canalul de comunicatie sa se comporte precum o retea privata in care numai

pachetele de date ale Beneficiarului vor fi routate cu prioritate maxima.

La Dispeceratul de Telecontrol Regional operatorul de telefonie mobila va oferi o

conectivitate traditionala astfel incat echipamentele de tip router locale vor putea

comunica cu routerele GPRS instalate in punctele de masura si control.

Arhitectura de comunicatii va fi de tip stea, fiecare punct de achizitie a datelor avand

comunicatie directa cu Dispeceratul de Telecontrol Regional.

Echipamentul de tip router din cadrul Dispeceratului de Telecontrol Regional permite

interconectarea sistemului SCADA-DTR cu sistemele dispeceratele SCADA din teritoriu

sau cu alte puncte de achizitie si se vor realiza cu ajutorul unui tunel VPN (Virtual

Private Network) peste Internet.

Echipamentele de comunicatie din punctele de achizitie a datelor transmit si

receptioneaza spre/dinspre sistemul central SCADA-DTR informaŃii full-duplex.

82

6.10 Conceptul sincronizarii de timp (stabilirea timpului de referinta)

Ansablu „sincronizare de timp”ș va fi folosit pentru a

asigura reacŃia potrivită a sistemului şi pentru a face

posibilă analiza pertinentă a evenimentelor, în mod

special în cazul defectelor, unde sunt necesare reacŃii

rapide şi toate elementele trebuie sa funcŃioneze pe

acelaşi timp pentru a exista o corelare. Sistemul de

sincronizare de timp furnizează referinŃa de timp pentru

toate elementele sistemului SCADA-DTR precum şi

pentru semnalele provenite de la sistemele SCADA distribuite.

Sincronizarea de timp presupune doua implementari tehnice si anume:

• Implementarea unei referinte de timp. ReferinŃa de timp trebuie să fie un semnal

furnizat de GPS. Sincronizarea de timp va fi executată utilizand protocolul

standard RFC 1305, cunoscut ca si NTP (Network Time Protocol). Echipamentul

trebuie sa fie format dintr-un receptor GPS / server NTP, o antenă GPS şi

conectica si conexiunile necesare pentru recepŃia timpului de referinŃă.

• Toate echipamentele, statiile de lucru si serverele vor fi sincronizate temporal cu

ajutorul unui echipament de tip server de timp cu receptor GPS integrat.

6.10.1 SINCRONIZAREA IN CADRUL SISTEMULUI CENTRAL SCADA-DTR

In cadrul sistemului central SCADA-DTR va fi instalat un server de timp bazat pe un

semnal GPS

ca referinta de timp si NTP ca protocol de sincronizare. Toate celelalte elemente ale

sistemului

central vor fi clienti NTP, care vor avea serverul de timp ca referinta.

Implementarea protocolului NTP trateaza deasemenea toate aspectele legate de

redundanta. Starea operationala a serverului de timp va fi supravegheata de catre

sistemul SCADA-DTR.

83

6.10.2 SINCRONIZAREA IN CADRUL PUNCTELOR DE ACHIZITIE A DATELOR

Punctele de achizitie a datelor (sistemele SCADA locale, unitatile de achizitie,

debitmetrele) nu au fost prevazute cu sisteme locale de sincronizare temporara, motiv

pentru care sincronizarea acestora se va realiza folosind serverul de sincronizare al

sistemului central SCADA-DTR. Sincronizarea ceasului intern al acestor puncte de

achizitie cu sistemul central se va face utilizand protocoalele de comunicatie afente

procesului de integrare. Sistemul central va supraveghea starea operationala a

procesului de sincronizare al punctelor de achizitie si va genera alarme la iesirea din

sincronism al acestora.

6.10.3 ECHIPAMENT HARDWARE

• Receptor GPS inclusiv antena montata (instalare externa) pe acoperis sau pe

perete conform cerintelor specifice ale Beneficiarului;

• Inclusiv dispozitivele conexe, antena, cablul pana la antena, mufe, prize si orice

alt echipament necesar;

• Inclusiv ingineria, montarea, instalarea, punerea in functie, testarea;

• Dispozitiv de 19“ (rack-abil) integrat in integrat in dulapul de servere;

• Nu sunt acceptate carduri PC-Slot;

• Adaptor de retea RJ 45, Ethernet 802.3, 100BASETX, TCP/IP;

• Management si monitorizare via interfata SNMP si web.

6.10.4 FUNCTII ALE SISTEMULUI DE SINCRONIZARE

• Informatia de timp va fi distribuita catre toate componentele sistemului central

(inclusiv dispozitive de retea) via NTP;

• Informatii SNMP catre serverele de sistem;

• rezolutie <= 1 ms;

• acuratete <= 10 ms;

• urmatoarele evenimente si opusul lor trebuie sa fie inregistrate in lista

cronologica de evenimente si sa declanseze alarme potrivit cerintelor specifice

ale beneficiarului:

o Dispozitive lipsa sau care nu sunt in operare;

o Semnal de la antena lipsa;

84

o Antena lipsa sau nu este in functie

6.10.5 FUNCTII DE SINCRONIZARE A TIMPULUI GLOBAL. COMUTAREA ZONELOR ORARE.

• HMI-urile si toate reprezentarile de date trebuie sa afiseze ora oficiala a

Romania;

• Toate functiile de afisare si raportare trebuie sa indeplineasca cerintele legale

aplicabile;

• Toate mecanismele de filtrare si interogari de date trebuie sa integreze

functionalitatea de timp si sunt bazate pe ora oficiala a Romaniei;

• Data comutarii zonei orare trebuie sa fie parte a modelului de date si poate fi

schimbata sau extinsa prin intermediul modelarii de date;

Schimbarea de la ora de iarna la ora de vara:

• Golurile din arhive (e.x. intre 3:00 si 4:00) trebuie sa fie inregistrate ca “nu au fost

culese”;

• Este atribuit “INV”;

• Ziua respectiva este definita ca avand 23 ore;

• Schimbarea zonei orare trebuie sa fie inregistrata in lista cronologica de

evenimente.

Schimbarea de la ora de vara la ora de iarna:

• Afisarea orelor “a” si “b” in lista cronologica de evenimente;

• Inregistrarea orelor “a” si “b” in arhive;

• Ziua respectiva va fi definita ca avand 25 ore;

• Schimbarea zonei orare trebuie sa fie inregistrata in lista cronologica de

evenimente

W6

85

Pentru a demonstra intelegerea exacta a solicitarilor, referitoare la conceptul de

sincronizare de timp, ofertantul va trebui ca in baza principiilor anterior prezentate sa

detalieze insotit de scheme/schite, solutia proprie propusa/ofertata pentru sincronizarea

temporara a sistemului SCADA-DTR si a punctelor de achizitie integrate in acesta.

6.11 Conceptul de Redundanta

Conceptul de redundanta implica satisfacerea urmatoarelor considerente:

• Nivelul server de sistem redundant consta in 2 sisteme construite identic;

• Fiecare sarcina de procesare de date functioneaza identic pe ambele servere;

• Fiecare server este alimentat cu aceleasi informatii din proces;

• Verificari de consistenta si sincronizari sunt executate peste intreaga retea;

• Unul dintre servere este serverul master, iar celalalt este server rezerva calda

(HSB);

Pornire automata a serverului dupa repornire calda/rece in modul Master simplex, doar

daca nu este gasit alt server master. Sincronizare automata cu serverul Frontend

master, la starea actuala a procesului. Daca in timpul procesului de pornire initiala

serverul detecteaza un alt server master, atunci serverul respectiv va porni in modul

rezerva calda, se va sincroniza cu starea acuala a serverului master in ceea ce priveste

starea actuala a procesului si a arhivelor.

Daca un server care porneste detecteaza un alt server care este de asemenea in curs

de pornire, acest server va primi rolul de server master care va asigura pierderea

minima de date in arhiva, respectand timpul actual de pornire.

W7

Pentru a demonstra intelegerea exacta a solicitarilor, referitoare la conceptul de

redundanta, ofertantul va trebui ca in baza principiilor anterior prezentate sa detalieze

insotit de schema logica, solutia proprie propusa/ofertata pentru mecanismul de

redundanta al sistemului SCADA-DTR punctand in clar functiile serverului master si

functiile serverului „rezerva calda” in contextul conceptului de redundanta. Pentru o

descriere completa, solicitarile acestui subpunct (W6) vor fi coroborate cu solicitarile

legate de conceptul de redundanta specificate in tabelul cu Declaratii ale Ofertantului.

86

6.12 Conceptul de Deschidere si Interoperabilitate al sistemului

Conceptul de deschidere in sensul OSI – ISO, presupune ca sistemul sa dispuna de

posibilitati care permit implementarea aplicatiilor astfel incat:

• să poată fi implementate pe sisteme provenind de la mai mulŃi furnizori de

echipamente;

• să poată conlucra cu alte aplicaŃii realizate pe sisteme deschise;

• să prezinte un stil consistent de interacŃiune cu utilizatorul;

Cea mai mare deschidere pe care conceptul open-system o aduce în proiectarea

sistemelor SCADA este posibilitatea de a distribui funcŃiuni în diferite noduri de

prelucrare. Fiecare nod funcŃional trebuie sa fie independent ca resursă hardware.

Serverele de proces trebuie sa constituie astfel de noduri care sa degreveze statiile de

lucru operator de alte sarcini de proces.

Gradul de dependenŃă între noduri este variabil; totuşi prin hardware va trebui sa fie

asigurată o independenŃă cât mai mare deoarece, pe această cale, se poate obŃine

posibilitatea de extindere ulterioară sau de înlocuire. De asemenea, independenŃa

nodurilor de prelucrare serveşte la minimizarea mesajelor şi încărcării reŃelei de

transmisie de date. RedundanŃa în cadrul nodului măreşte gradul de disponibilitate al

acestuia şi micşorează riscul pierderii lui şi a distribuirii funcŃiunilor pierdute în alte

noduri.

O caracteristică a sistemelor deschise o constituie faptul că nodurile pot fi situate la

orice distanŃă; arhitectura distribuită devine o necesitate şi foloseşte ca suport de

comunicaŃie reŃelele locale de date (LAN – Local Area Network) şi cele la distanŃă

(WAN – Wide Area Network) realizate pe baza unor proceduri şi interfeŃe standard.

Sistemul SCADA-DTR ofertat trebuie sa satisfaca totdata si conceptul de

interoperabilitate, adica capabilitatea de a se interconecta si opera in aceleasi conditii

cu alte sisteme conexe sau adiacente care utilizeaza aceeasi platforma sau standarde

de comunicatie.

W8

Pentru a demonstra intelegerea exacta a solicitarilor, referitoare la conceptele de sistem

deschis, respectiv sistem interoperabil, ofertantul va trebui ca in baza principiilor

enuntate anterior sa detalieze pe baza solutiei ofertate modalitatea prin care sistemul

propus / ofertat intruneste dezideratele de sistem OSI – interoperabil.

88

7 SECURITATEA INFORMATIEI

7.1 Cerinte de Securitate a Informatiei

SiguranŃa SCADA se va baza pe folosirea Codurilor de Securitate şi a Conturilor de

Utilizator.

7.1.1 CODURI DE SECURITATE

Alocarea autorizaŃiilor de acces este controlată de către funcŃia de Administrator, unde

autorizaŃiile sunt acordate în conformitate cu nevoile utilizatoriilor de sistem la

accesarea diferitelor nivele de operare. Când un utilizator se va autentifica în sistem,

accesul îi va fi permis doar pentru acele funcŃii autorizate și configurate de către

administratorul de sistem – toate celelalte fiindui interzise.

7.1.2 GRUPURI DE UTILIZATORI

Grupurile de utilizatori operează în conjuncŃie cu autorizarea secŃiunii precedente.

Fiecare utilizator va avea identitate proprie caracterizată prin nume de utilizator

(user_name) şi o parolă (password). Fiecare utilizator va fi identificat ca aparŃinând unui

grup arătat mai jos şi va avea definită explicit autorizaŃia asignată.

Va fi posibilă totodata si repartizarea mai multor grupe cu diferite coduri de acces, de

ex.: grup de supervizare. Următoarele conturi vor fi orientative pentru accesul permis

fiecărui grup de acces.

7.1.3 OPERATOR

Grupul utilizatorilor de tip Operator va fi capabil să vizualizeze toate ecranele aplicaŃiei

şi să navigheze în sistem. În plus, va fi posibil (în funcŃie de decizia Beneficiarului şi

politica de IT a Companiei) să aducă modificări minore punctelor de setare şi părŃilor de

control din staŃie.

Operatorul va fi abilitat să controleze procesul prin transmiterea de comenzi (acolo unde

este cazul) si sa confirme şi sa anuleze alarme.

7.1.4 INGINER DE SISTEM

Grupul utilizatorilor de tip Inginer de sistem vor avea acces securizat similar grupului

Operator. În plus, grupul utilizatorilor de tip Inginer de sistem va fi abilitat să realizeze

configuraŃii complexe, setări şi parametri în sistem, de ex.: ecrane, logici în PLC și în

software-ul de aplicașie, management al bazei de date, articole, alarme, direcŃii etc.

89

7.1.5 ADMINISTRATOR

Administratorul de sistem va avea acces necondiŃionat la toate zonele sistemului.

Aceasta include abilitatea de a manageria aplicaŃiile software şi de setări şi configurări

în sistemul de operare. Orice nou cont de utilizator sau modificări ale codurilor de acces

deja existente, vor fi configurate doar de către Administrator.

7.1.6 CONSIDERAłII GENERALE DE SECURITATE

Toate instalaŃiile trebuie să intre în modul de operare (run mode) atunci când sistemul

este pornit. Bara de sarcini va fi auto-ascunsă în fişierele de setare ale sistemului de

operare.

Abilitatea de a comuta aplicaŃii, folosind Alt+Tab sau Ctrl+Alt+Del de expunere a menu-

ului de start, etc., vor fi anulate în modul de pornire. Acestea vor fi anulate din fişierul

proprietăŃile computerului (Computer Properties), în modul editare.

Un buton va fi configurat să permită doar Administratorului închiderea sesiunii de

software SCADA.

7.2 Cerinte de Proiectare

In nici un moment sarcinile de proiectare sau de inginerie nu vor fi in responsabilitatea

Beneficiarului. In acest sens cerintele specifice ale beneficiarului trebuie privite ca o

documentare a modului de realizare a proiectului, acceptata de echipa de implementare

a proiectului, care nu aduce termeni contractuali noi.

Se vor organiza intalniri cu privire la proiect (detaliile de executie), intre ofertant si

Beneficiar pentru a demonstra starea derularii proiectului la acea data si pentru

derularea in continuare a lui. Aceste intalniri vor avea loc in locatii apartinand

Beneficiarului. Frecventa acestor intalniri va fi stabilita ulterior.

Separat de cerintele specifice ale Beneficiarului, intalnirile de proiect trebuie

documentate cu rapoarte sau minute scrise. In aceste rapoarte ale intalnirilor vor fi

trecute toate informatiile, specificatiile si deciziile, starea prezenta a derularii proiectului,

intarzieri fata de programul proiectului, dificulatati, procedurile urmatoare etc.

Rapoartele, minutele de proiect vor fi scrise in maximum 3 zile lucratoare (preferabil in

timpul intalnirii de proiect in sine) si trebuie prezentate echipei de implementare proiect

a beneficiarului pentru a fi acceptate.

90

Schimbarile in ceea ce priveste extindere livrarilor sunt deasemenea documentate in

cerintele specifice ale Beneficiarului. Acest lucru nu va genera costuri suplimentare.

7.2.1 DOCUMENTATIA DE PROIECT

Documentatia sistemului in cadrul cerintelor specifice ale Beneficiarului, inclusiv

descrierea partii hardware, software si a sistemului ca un intreg, va fi executata intr-un

software standard cum ar fi Word, Excel, Access, PowerPoint; desenele trebuie

prezentate cu Microsoft Visio si/sau AutoCAD.

La data livrarii, software-ul folosit la executarea documentatiei trebuie sa fie la ultima

versiune, sau in mod alternativ sa fie up-datat la ultima versiune. Trebuie sa fie

inmanata echipei de implementare proiect a Beneficiarului impreuna cu rapoartele de

proiect si avertizari de schimbare.

Documentatia de proiect trebuie prezentata pe suport de hartie (hardcopy) precum si in

format electronic (softcopy) pe suport optic (CD/DVD).

Pentru conturarea cerintelor specifice ale beneficiarului se vor respecta cele mai noi

standarde tehnice, toate normele IEC, ISO si romanesti, standardele EN, precum si

normele relevante, indrumare si obligatii legale. Indrumarele tehnice si normativele

interne stipulate de Beneficiar trebuie de asemenea respectate cu strictete.

7.3 Cerinte de Livrare

Conditia pentru livrare este acceptarea de a livra emisa de catre Beneficiar.

Livrarea componentelor sistemului, inclusiv ambalajele, la locatia de santier va fi facuta

fara costuri aditionale. Livrarea se va face in entitati diferite, confom planului de

desfasurare a proiectului. Echipa de receptie trebuie anuntata cu cel putin 2 saptamania

inaintea livrarii, astfel incat masurile necesare sa poata fi luate din timp. In general este

de asteptat ca livrarile sa aiba loc la momentele stabilite.

Toate componentele sistemului, parti de echipamente, dispozitive si facilitati care

ofertantului ii sunt comandate, sunt parte integranta a livrarii, asa cum sunt si sursa de

alimentare cu energie electrica, distributia energiei electrice, cabluri de retea, precum si

toate materialele necesare pentru instalare, ansamblare si fixare.

Oferta trebuie sa includa transportul, impachetarea, livrarea, asigurare de transport si

indepartarea materialelor folosite la ambalare. Datele livrarilor trebuie sa fie specificate

conform cu programul proiectului.

91

Documentatia livrata trebuie sa arate clar si fara echivoc, fara sa necesite ajutor din

partea ofertantului, relatiile intre punctele de intersectie si punctele de intrare-iesire ale

dispozitivelor si echipamentelor instalatiei, la fel ca si functiile lor. In mod aditional,

planurile si schemele trebuie sa fie etichetate folosind modul de etichetare utilizat de

echipa de receptie din partea Beneficiarului.

Livrarea este permisa daca verificarile functionale nu au evidentiat greseli grave sau

erorile din timpul verificarilor functionale au fost corectate.

Daca instalatiile testate prezinta erori grave livrarea nu poate fi facuta si nu va fi

permisa.

7.3.1 OBLIGATII PENTRU LIVRARE:

Dupa inchierea perioadei de garantie, furnizorul este obligat sa livreze (contra cost)

piese de schimb hardware compatibile pentru o perioada de 1 an si module hardware si

software precum si module software de extindere pentru o perioada de cel putin 10 ani.

Beneficiarul va fi informat de catre ofertant, cu cel putin 6 luni inaintea expirarii obligatiei

de livrare, cu privire la indisponibilitatea, terminarea sau sistarea din programul

ofertantului, a anumitor componente ale sistemului.

7.3.2 DOCUMENTATIA DE LIVRARE

Documentatia de livrare trebuie sa corespunda cu lista de cantitati si trebuie sa contina

urmatoarele documente:

• Note de livrare si returnare;

• Liste cu piese si dispozitive.

7.3.3 DATA DE LIVRARE A DOCUMENTATIEI

Intreaga documentatie trebuie sa fie livrata cat mai repede posibil, dar cel mai tarziu la:

• Livrarea completa a partii hardware la locul instalarii Ofertantul trebuie sa

instiinteze Beneficiarul asupra terminarii lucrarilor in forma scrisa.

• (documentatia pentru Hardware);

• Punerea in functie completa a partii software la fata locului (documentatia pentru

Software);

92

Documentatia de insotire a proiectului trebuie realizata in timpul proiectului. Odata cu

aprobarea finala a sistemului trebuie predata documentatia completa, revizuita si finala.

7.3.4 LIVRAREA, INDEPLINIREA, PRELUAREA, TRANSFERUL RISCURILOR SI TRANSFERUL

PROPRIETATII

7.3.4.1 Livrarea

• In mod normal, sunt valide intelegerile stipulate in contract;

• In cazul in care nu s-au incheiat alte intelegeri, toate livrarile, la locul unde

contractul trebuie indeplinit, sunt facute fara costuri suplimentare,

deasemenea sunt asigurate, descarcate si amplasate la locul instalarii fara

alte costuri.

7.3.4.2 Locul unde contractul va fi dus la indeplinire

• Adresa furnizata de catre beneficiar este locul unde contractul va fi dus la

indeplinire.

Data indeplinirii

• Termenul (le) limita stipulat (e) in contract este (sunt) considerat (e) ca data a

indeplinirii.

• Ofertantul trebuie sa instiinteze Beneficiarul asupra terminarii lucrarilor in

forma scrisa.

7.3.4.3 Preluarea

• Beneficiarul este obligat, sa preia in mod oficial acele activitati a caror

preluare necesita o anumita forma.

• Dupa ducerea la indeplinire, asa cum este stipulat in contract, preluarea

livrarilor si activitatilor are loc in locatiile unde contractul este dus la

indeplinire.

• Lucrarile sunt considerate ca duse la indeplinire doar in momentul in care

preluarea a fost efectuata de catre beneficiar sau de catre o companie pe

care beneficiarul a mandatat-o.

7.3.4.4 Transferul riscurilor

93

• Imediat ce sistemul a fost acceptat de catre beneficiar are loc transferul

riscurilor de la ofertant catre Beneficiar.

7.3.4.5 Transferul proprietatii

Odata cu plata ultimei facturi, bunurile livrate si serviciile devin proprietatea

Beneficiarului.

7.4 Cerinte de Asamblare, Instalare si Punere in Functiune

Toate masurile necesare pentru ansamblare, instalare, constructie, fixare si conectare

trebuie luate si indeplinite de catre ofertant.

Separat fata de ansamblare, instalare, construire, fixare si conectare, intocmirea si

inmanarea documentatiei preliminare privitor la ansamblare trebuie deasemenea sa fie

inclusa in oferta.





echipa de receptie din partea beneficiarului.

In plus, aprovizionarea cu aparate de masura si testare, precum si alte scule, unelte si

echipamente necesare pentru o ansamblare si instalare rapida si corespunzatoare

trebuie incluse in oferta.

In timpul ansamblarii, instalarii si punerii in functie, ofertantul va tine un jurnal al

instalarii in modul sugerat de beneficiar.

7.4.1 SERVICII OFERITE DE BENEFICIAR

Beneficiarul confirma ca locatiile folosite vor fi curate si gata pentru procesul de

ansamblare si instalare, astfel incat lucrarile sa demareze cat mai curand. Este sarcina

ofertantului sa curete periodic si la final incaperile folosite de el.

7.4.2 CONCEPTUL PUNERII IN FUNCTIUNE

Procesul punerii in functie trebuie sa se desfasoare dupa cum urmeaza:

7.4.2.1 Etape preliminare

94

• Crearea unui program detaliat inclusiv servicii aflate in responsabilitatea

Beneficiarului;

• Intalniri de inceput la fiecare locatie, analize de risc, instruirea personalului

furnizorului cu privire la normele de securitate a muncii, facilitati si proceduri

de urgenta;

• Pregatirea locatiei (locatiilor), alimentarea cu energie electrica, traseele

paturilor de cable, etc;

7.4.2.2 Instalarea efectiva

• Livrarea si instalarea sistemului central de dispecer (SCADA-DTR) complet;

• Integrarea in sistemul SCADA-DTR a sistemelor SCADA locale;

7.4.2.3 Punerea in functiune

Dupa ansamblare si instalare, sistemul trebuie pus in functie. Aceasta faza include:

• Instalarea tuturor modulelor software necesare;

• Instalarea tuturor parametrilor si fisierelor bazelor de date;

• Up-datarea si testarea intregului model de date;

• Probe functionale in conditiile procesului;

• Stabilirea conexiunii cu procesul, testarea la nivel de bit si teste de

functionare;

• Punerea in functie conform cu buletinul de verificare

Dupa emiterea Ordinului de Incepere de catre Autoritatea Contractanta, Antreprenorul

va elabora si inainta spre analiza Reprezentantului Autoritatii Contractante Graficul de

executie al tuturor lucrarilor care fac obiectul prezentului Caiet de Sarcini. Ofertantul va

primi, la cerere, asistenta, prin intermediul personalului local, in timpul procesului de

punere in functie.

Operatiuni privind punerea in functiune:

� Punerea in functiune / testarea tuturor componentelor SCADA-DTR;

� Punerea in functiune / testarea tuturor componentelor periferice aferente

acestuia;

95

� Punerea in functie / testarea tuturor dispozitivelor si a canalelor de

comunicatii;

� Punerea in functie / testarea tuturor componentelor software;

� Testarea tuturor punctelor de achizitie a datelor;

Integrarea complet functionala a tuturor sistemelor SCADA locale in sistemul

SCADA/DTR

7.5 Cerinte de Testare

7.5.1 MODUL DE TESTARE

7.5.1.1 Teste de acceptanta la fata locului (SAT – Site Acceptance Test)

Executia testelor SAT de catre ofertant are loc dupa instalarea la fata locului a intregului

sistem (hardware si software).

Aceste testari „on site” nu trebuie intelese ca si o inspectie sau receptie ci doar ca teste

preliminare punerii efective in functiune, pentru a se asigura faptul ca sistemul este

complet functional. Inaintea receptiei sistemului ca un intreg, instalatiile trebuie sa

indeplineasca toate caracteristicile functionale descrise in contract. La receptia finala,

ofertantul va preda toata documentatia de care dispune.

Beneficiarul trebuie sa elibereze o acceptare scrisa a operatiilor de testare imediat ce

ofertantul si-a indeplinit obligatiile. Imediat ce aceptarea a fost emisa, operatiile de

testare pot demara.

7.5.2 PERIOADA OPERATIILOR DE TESTARE

Perioada de testare se stabileste in conditii normale de activitate si serveste pe de o

parte ca dovada a indeplinirii calitative a caracteristicilor sistemului, iar pe de alta parte

ca un test al functionalitatii sistemului pe termen lung.

Perioada operatiilor de testare va dovedi:

• Timpul de reactie al sistemului;

• Disponibilitatea si interoperabilitatea;

• Indeplinirea completa a sarcinilor.

Perioada operatiilor de testare va fi luata in considerare ca si proba de functionalitate a

sistemului instalat. Intrega perioada a operatiilor de testare se presupune ca va fi

efectuata cu o singura versiune de software.

96

Daca din cauza defectelor sunt necesare efectuarea de module hard sau software,

beneficiarul are dreptul sa repete testele de acceptare la fata locului pentru aceste noi

componente sau pentru intreg sistemul.

7.5.3 DURATA TESTELOR

Perioada operatiilor de testare va dura maxim 3 luni si trebuie incheiata cu succes in

termen de maxim 6 luni de la inceperea ei. Daca din motive care nu tin de beneficiar,

perioada operatiilor de testare nu poate fi incheiata cu succes in termen de 6 luni, se va

acorda o perioada aditionala de 1 luna. Dupa aceasta perioada aditionala operatiile

trebuie terminate. Daca nici dupa aceasta perioada aditionala operatiile de testare nu

pot fi incheiate cu succes, beneficiarul are dreptul sa se retraga din contract.

7.5.4 INTRERUPEREA TESTELOR

De comun acord, perioada operatiilor de testare poate fi intrerupta pentru o anume

perioada de timp pentru remedierea defectiunilor minore. Este datoria liderului echipei

de implementare a proiectului sa informeze seful de echipa al ofertantului despre

erorile/defectiunile majore sau minore imediat ce acestea au fost constatate.

Dupa aceasta liderii celor doua echipe de proiect trebuie sa cada de comun acord

asupra masurilor care trebuie luate pentru corectarea erorilor/defectelor. Deasemenea

trebuie sa solicite o intrerupere a perioadei operatiilor de testare. Dupa remedierea

erorilor/defectiunilor, perioada operatiilor de testare va continua. Costurile aferente

remedierii erorilor/defectiunilor, vor fi exclusiv responsabilitatea ofertantului.

7.5.5 INCETAREA TESTELOR

Daca apar greseli grave in ceea ce priveste livrarea si performanta, lucruri care

afecteaza folosirea specifica a sistemului sau o fac imposibila, operatiile de testare vor

inceta. In acest caz este de datoria sefului de echipa implementare proiect al

beneficiarului sa informeze seful echipei de proiect din partea ofertantului imediat

despre greselile grave, defectiuni si erori.

Dupa aceasta, seful echipei de proiect din partea ofertantului, trebuie sa ia toate

masurile necesare pentru remedierea imediata a erorilor/defectiunilor. Imediat ce

erorile/defectiunile au fost remediate, perioada operatiilor de testare se va relua in cazul

in care beneficiarul nu solicita reluarea in intregime a testelor de acceptanta la fata

locului. Costurile pentru remedierea erorilor/defectiunilor, precum si pentru repetarea

testelor in cazul in care sunt solicitate, sunt responsabilitatea ofertantului.

97

Daca perioada operatiilor de testare este intrerupta sau incheiata din cauza instalatiilor

defecte, toate costurile ce deriva din extinderea perioadei de testare si/sau din oprirea si

reluare perioadei de testare sunt responsabilitatea ofertantului.

7.5.6 MEDIUL DE TESTARE

Mediul de testare trebuie sa realizeze urmatoarele:

(1) Software-ul sa poata fi controlat prin meniuri si mouse pentru simularea starilor,

valorilor si a atributelor definite;

(2) Sa fie integrat in interfata SCADA folosind acelasi aspect si abordare („look and

feel”);

(3) Accesibil in concordanta cu drepturile de utilizator atribuite separat;

(4) Sa suporte punerea in functie/parametrizarea/service-

ul/intretinerea/diagnosticarea sistemului SCADA/ echipamentului de comunicatie/

RTU-uri;

(5) Sa suporte crearea, testarea si mentinerea valorilor calculate si aplicatii specifice

de utilzator prin simularea intrarilor/valorilor de iesire/atributelor/starilor;

(6) Sa permita selectarea punctelor de date conform cu cele specificate in acest

document;

(7) Sistemul sa permita simularea intrarilor din proces sau de utilizator si sa aiba

posibilitatea sa blocheaze actualizarea din proces a valorilor digitale/analogice

(pentru facilitatea de mentenanta).

(8) Sistemul sa permita simularea emiterii de comenzi fara transmiterea telegramelor

necesare catre PLC-urile sistemelor SCADA locale si sa simuleaza semnalele

de feedback corecte.

(9) Sistemul sa permita simularea valorilor de proces care vor fi furnizate ca alegere

libera a utilizatorului bazata pe valori brute (valoare conform cu specificatiile

protocolului) sau valorilor tehnologice.

7.6 Cerinte de Instruire

Furnizorul va asigura pregătirea personalului Beneficiarului în domeniile legate de

operare, exploatare si întretinere.

98

Ofertantul trebuie sa ofere un concept de pregatire complet aferent partii de aplicatie

dedicate sistemului SCADA integrat. Planul pentru pregatirea angajatilor conform

programului va fi sincronizat cu cel intocmit de Consultantul pentru managementul

proiectului, astfel incat activitatile sa nu se suprapuna. Acesta va tine seama si de

progresul inregistrat in cadrul contractelor de lucrari.

• Pregatirea se va organiza la sediul Beneficiarului.

• Ofertantul trebuie sa furnizeze pregatire pentru 5 dispeceri, fiecare beneficiind

de cate 2 zile de pregatire in cate 2 seminarii distincte pentru utilizarea

sistemului SCADA.

• Pentru utilizarea celoralte aplicatii din cadrul sistemului se vor pregati 5 persoane

fiecare timp de 5 zile.

Ofertantul va face propuneri detaliate în acest sens în oferta sa.

7.6.1 CERINłE PRIVIND ŞCOLARIZAREA PERSONALULUI DE EXPLOATARE

Prin personal de exploatare se înŃelege personalul TESA care manageriază activitatea

de exploatare a staŃiilor aferente Companiei. Personalul de exploatare cuprinde şefii

CED şi adjuncŃii CED sau personal care programează activitatea de exploatare.

ActivităŃile de şcolarizare ale personalului de exploatare au ca scop îmbunătaŃirea

capabilităŃii personalului Beneficiarului de a permite o urmarire mai corectă a activităŃii

de exploatare bazată pe informaŃia („materia primă”) furnizată de sistemul SCADA de

Dispecer. Şcolarizarea personalului de exploatare se va rezuma la o prezentare

principială a sistemului, a modulelor software ale acestuia precum şi a principalelor

funcŃiuni. Totodată se vor prezenta Beneficiarului din domeniul de exploatare toate

posibilităŃile oferite de sistem în ceea ce priveşte modul de culegere a informaŃiilor

necesare procesului de exploatare (rapoarte, analiză evenimente, etc.).

7.6.2 CERINłE PRIVIND ŞCOLARIZAREA PERSONALULUI TESA DEDICAT INFORMATICII DE

PROCES (IP)

Prin personal de informatică de proces se înŃelege personalul TESA care

manageriază resursele hardware şi software ale sistemul SCADA-DTR. Se vor instrui

minim 2 ingineri de sistem pe o perioada de minim 2 zile. ActivităŃile de şcolarizare ale

personalului de informatică de proces au ca scop îmbunătaŃirea capabilităŃii

personalului Beneficiarului în vederea administrării (operaŃiuni de: parametrizare,

setare, configurare) si întretinerii sistemelor informatice de proces şi reŃelistică din

cadrul companiei.

99

7.7 Cerinte privind mentenanșă

Pentru gestionarea tuturor incidentelor și a tichetelor generate de acest proiect de

mentenanșă, ofertantul trebuie să pună la dispozișia autoritășii contractante o

aplicașie software de gestionare a incidentelor, inregistrată la ORDA, cu următoarele

caracteristici:

• inregistrarea solicitărilor de suport și alocarea unui identificator unic fiecărei

solicitări;

• posibilitatea de definire a unor categorii de apeluri de asistenșă;

• posibilitatea de definire și de încadrare a solicitărilor în categorii: defect, eroare,

solicitare de informașii, cerere de schimbare.

• posibilitatea de inregistrare a datelor de identificare ale apelantului - include

atribuirea incidentului unei persoane care raportează în aplicașia software

(inginerul de suport al Call Center), persoana care solușionează incidentul (de la

orice nivel), persoana care a raportat un incident. Toate datele prezente aici

includ atât date personale, cât și date de contact, activitate curentă etc., această

aplicașie putând fi personalizată să primească detalii diferite pentru aceste

puncte de reper în mod diferit și definit în totalitate de către un administrator de

aplicașie.

• posibilitatea de înregistrare a descrierii problemei și de atașare a unor

documente suplimentare. Aplicașia software să permită atașarea oricăror tipuri

de fișiere (doc, xls, jpg, xml etc.) precum și postarea a unor capturi de ecran din

aplicașii.

• posibilitatea de alocare a unui criteriu de urgenșă. Aplicașia software să permită

clasificarea incidentelor în funcșie de tipul stabilit în SLA, putând să emită

notificări pe mail privind alocarea incidentelor către persoanele implicate în

incident.

• posibilitatea de alocare automată a unor coduri de incident care să indice cauza

probabilă a incidentului. Aplicașia software să aloce coduri unice fiecărui

incident. Aplicașia software să permită de asemenea și gruparea pe module a

incidentelor.

• posibilitatea de gestionare a informașiilor despre personalul de suport căruia i se

pot aloca spre rezolvare incidentele. Aplicașia software conșine implicit toate

100

datele de contact și deci persoanele, care pot fi considerate alocabile sau care

pot aloca un incident. Aceste date pot fi folosite în mod facil în cazul unui audit.

• înregistrarea automată a datei și a orei primirii unei solicitări de asistenșă.

• posibilitatea de definire a criteriilor de calitate și performanșă (SLA) pentru

rezolvarea diferitelor categorii de solicitări de asistenșă.

• posibilitatea de atenșionare automată în momentul depășirii unor praguri

temporale de rezolvare a diferitelor categorii de solicitări de asistenșă.

• posibilitatea de definire a unor fluxuri de evolușie a solicitărilor de suport, în

cazul în care ele trec prin mai multe nivele de competenșă până în momentul

finalizării.

• posibilitatea de escaladare a cererilor de suport.

• posibilitatea de înregistrare a datelor de contact pentru responsabilii pentru

activitășile de suport de nivel 1, 2 si 3 pentru diferitele componente ale

sistemului informatic.

• posibilitatea de definire a unor rapoarte personalizate folosind criterii cum ar fi:

tipul de incident, nivelul de urgenșă, timpul de rezolvare, persoana și locatia de

unde a fost semnalat un incident, modulul sau funcșia care a cauzat incidentul,

numărul de incidente pentru care nu s-au respectat criteriile din SLA etc.

• să permită în orice moment accesul la baza de date a personalului autorizat al

sistemului pentru verificarea modului de tratare a incidentelor și pentru rularea

de rapoarte de performanșă a serviciului de Call Center. Accesul se va face

numai pentru citire si nu va fi condișionat în niciun fel de către operatorii sau

administratorii serviciului.

101

8 CONTINUTUL OFERTEI

8.1 Modul de prezentare si continutul ofertei

Modul de prezentare si continutul ofertei va contine in mod obligatoriu urmatoarea

structura:

• descrierea detaliata a cerintelor;

• descrierea formei in care trebuie prezentate ofertele: capitole sunt incluse in

oferta, ce explicatii si pana le ce nivel de detaliu trebuie mers cu explicatiile.

Explicatiile trebuie sa fie clare, sugestive, detaliate insotite de schite, scheme,

diagrame, desene, etc., necesare pentru o intelegere deplina a solutiei propuse.

Ofertele care prezinta solutii confuze, fara descrieri sau cu descrieri insuficiente,

incomplete sau necorelate cu descrierea din menoriul tehnic, nu vor fi considerate

oferte valabile, putand fi respinse ca fiind neconforme.

Fisele tehnice de echipament se vor completa integral cu caracteristicile

corespunzatoare, pentru a demonstra indeplinirea cerintelor. Se va pastra structura

tabelara si ordonarea caracteristicilor propusa in DA.

Evaluarea va tine cont de viziunea de integrator de sisteme SCADA a ofertantului, de

experienta acestuia in domeniu, toate acestea fiind necesar a fi transpuse intr-o solutie

tehnica detaliata, completa, performanta care sa poata sa reprezinte o “unealta flexibila”

si eficienta pentru OR.

Pentru o evaluare corecta, dar totodata si pentru a asigura o uniformitate a ofertelor din

punct de vedere al structurii, continutului si a formei de prezentare, ofertantii vor trebui

sa-si structureze ofertele respectand urmatoarele cerinte tehnice:

1. Descrierea solutiei;

2. Arhitectura hardware a sistemului propus;

3. Arhitectura software a sistemului propus;

4. Fluxul datelor;

5. Interactiunea modulelor software ca si parti constituente ale platformei

SCADA;

6. Interactiunea cu platformele GIS si Modelare Hidraulica;

7. Comunicatiile de Date;

8. Conceptul de Redundanta al sistemului SCADA-DTR;

102

9. Interoperabilitatea sistemului;

10. Deschiderea sistemului (bazat pe conceptul OSI-ISO);

11. Descrierea conceptului de Modularitate al sistemului;

12. Descrierea conceptului de Scalabilitate al sistemului;

13. Descrierea conceptului de Adaptabilitate al sistemului;

14. Descrierea modalitatii de realizare a Securitatii informatice a sistemului;

15. Metodologie de realizare/implementare;

16. Prezentarea unui Grafic de Implementare realist;

17. Descrierea modalitatii de realizare a Implementarii, Testarilor si Punerii in

Functiune a sistemului.

18. Modalitatea de realizare a Instruirii Beneficiarului;

19. Asistenta Tehnica;

20. Fise Tehnice de echipamente;

Nerespectarea mentiunilor referitoare la formatul si continutul de prezentare al ofertei

tehnice mentionat la subcapitolul 2.4 poate conduce la respingerea ofertei considerata

ca fiind neconforma cu cerintele CS.

8.2 Oferta Tehnica

Solutia trebuie sa indeplineasca si sa prezinte in mod explicit urmatoarele cerinte

tehnice:

• Utilizabilitate, ergonomie si accesibilitate a modulelor functionale;

• Scalabilitate, flexibilitate si modularitate;

• Utilizarea standardelor de interoperabilitate sau implementarea de module,

metodologii sau unelte in definirea si dezvoltarea solutiei;

• Actiuni sau unelte clar orientate spre medii descentralizate;

• Generarea de rapoarte in conformitate cu o soluŃie deschisă şi flexibilă;

• Utilizarea unei metodologii de testare pentru gestionarea probelor si in

gestionarea configurarii si implementarii produselor rezultate

8.3 Fisele Tehnice ale Echipamentelor

Fiecare oferta trebuie sa contina fisele tehnice ale echipamentelor, completate

corespunzator.

103

8.4 Metodologie

Oferta trebuie sa fie bazata pe o metodologie standardizata, conform normelor

nationale sau internationale. Se va prezenta in oferta metodologia propusa.

Oferta trebuie sa acopere complet toate cerintele privind livrarile si performantele,

inclusiv activitatile specifice legate de implemnetarea sistemului SCADA. In consecinta

livrarile si performantele care nu sunt mentionate in caietul de sarcini in mod expres

insa sunt fara doar si poate necesare pentru buna functionare a sistemului, trebuie

incluse in proiect deasemenea.

Subcapitolele Organizare si Metodologie vor cuprinde o descriere detaliată, punct cu

punct, a caracteristicilor tehnice si functionale esentiale ale produselor si activitatilor pe

durata de implementare în conformitate cu specificaŃiile tehnice din Volumele 3 si 4

care fac parte integranta din prezenta documentatie de atribuire.

De asemenea va fi inclusa procedura de testare la punerea in functiune a

echipamentelor, avizata de catre producator. Procedura de testare trebuie sa

evidentieze faptul ca echipamentele indeplinesc cerintele caietului de sarcini, deoarece

va fi utilizata in timpul receptiei sistemului, iar rezultatul aplicarii acesteia vor fi

consemnate in procesul verbal de punere in functiune.

Propunerea tehnica va respecta în totalitate cerinŃele impuse în documentatia

de atribuire.

8.5 Declaratii ale ofertantului

Asa cum este mentionat in partile anterioare ale acestui document, ofertantul trebuie sa

prezinte anumite declaratii si explicatii referitoare la modul de indelinire al contractului.

Acestea vor fi incluse in subcapitolul Organizare si Metodologie sunt prezentate mai jos

in siteza:

1. Furnizorul trebuie sa confirme dimensionarea sistemului pentru punctele

de achizitii de date (punctele de lucru locale) pentru care a dimensionat sistemul,

conform caietului de sarcini.

Acestea vor fi definite ca pozitie ulterior, dupa semnarea contractului, in functie

de modul de implementare al subsistemelor SCADA prevazute in contractele de

104

lucrari.

2. Furnizorul trebuie sa confirme ca nu exista nici o alta limitare in ceea ce

priveste

configurarea si operarea cu punctele de date deja configurate pe contractele de

lucrari individuale. Acest lucru presupune ca furnizorul/integratorul sa confirme

faptul ca sistemele SCADA locale realizeaza “deschiderea” necesara pe

protocolul industrial de comunicatie OPC, si faptul ca informatia mapata din

aceste sisteme SCADA locale poate fi preluata integral in sistemul SCADA-DTR

in vederea prezentarii intr-un format unitar.

3. Furnizorul trebuie sa confirme ca a proiectat sistemul in concordanta cu

parametrii si valorile date

4. Ofertantul trebuie sa confirme faptul ca a inclus integrarea in sistemul

SCADA-DTR a sistemelor SCADA locale pentru activitatile specificate in tabela

prezentata la subcapitolul 3.2.2, in conformitate cu specificatiile prezentate,

cantitati / dimensiuni si viitoare extinderi ale acestora. De asemenea, ofertantul

va explica si detalia metoda si activitatile necesare pentru indeplinirea acestei

sarcini.

5. Ofertantul trebuie sa explice in intregime daca trebuie sa fie realizate

dezvoltari

specifice pentru acest proiect, pentru a indeplini in totalitate cerintele de

integrare. Daca este cazul atunci Ofertantul trebuie sa descrie explicit

urmatoarele:

• Intreaga enumerare a cerintelor despre care este vorba

• Descrierea explicita a interfetelor de comunicatie

In cazul incheierii contractului, intreaga documentatie a interfetelor de

comunicatie va fi pusa la dispozitie, chiar daca interfetele sunt interne

sistemului/sistemelor.

6 Ofertantul trebuie sa explice detaliat conceptul sau de redundanta, iar in mod

special trebuie sa explice:

• Cum lucreaza componentele impreuna in modul normal de operare si cum

sunt manevrate componentele care sunt in stand-by

• Cum reactioneaza sistemul la defectiuni ale componentelor care sunt in

105

functiune

• Cum reactioneaza sistemul la defectiuni ale componentelor care sunt in

stand-by

Ofertantul trebuie sa ilustreze explicatiile sale cu o digrama schematica (schema

logica) a sistemului.

7 Ofertantul trebuie sa confirme ca va respecta acesti parametri de performanta.

8 Ofertantul trebuie sa specifice cerintele minime care trebuie respectate

pentru statiile de lucru operator . Aceasta presupune ca ofertantul sa sintetizeze

conditiile de lucru specifice unei functionari optime a aplicatiilor grafice care

ruleaza pe statiile de lucru operator, (de ex. conditii de microclimat (temperaturi /

umiditare), perioada de intretinere (mentenanta), operatiuni executate pe

derularea procesului de mentananta, modul de realizare a mentenantei hardware

si software, etc.

9 Ofertantul trebuie sa-si explice conceptul de servere de proces si distributia

functiilor software pe aceste servere.

10 Ofertantul trebuie sa explice si sa argumenteze detaliat sistemul de

codificare al obiectelor din aplicatia grafica precum si conventiile sau standardele

internationale care au stat la baza adoptarii acestor notatii.

11 Intr-o Declaratie pe proprie raspundere, care va fi inclusa in oferta, ofertantul

declara ca toate pisele de schimb necesare pot fi furnizate pentru o perioada de

inca cinci ani dupa ce perioada de garantie s-a incheiat. Ofertantul va declara in

scris la depunerea ofertei faptul ca trebuie sa asigure pe termen mediu/lung

facilitati de service si intretinere (contra-cost doar dupa iesirea din garantie). Mai

mult, se va prevedea constituirea unei garantii pentru disponibilitatea de piese de

schimb pe toata durata de viata a sistemului. Ofertantul se obliga prin contract sa

acorde un preaviz cu cel putin un an inainte de a inceta fabricarea de

componente utilizate de sistem.

Ofertantul trebuie sa furnizeze o lista cu piesele de schimb care le considera

predictibile ca fiind necesare sistemului in primii 5 ani de functionare si

suplimentar peste durata de viata pentru care s-a proiectat sistemul.

12 Ofertantul trebuie sa predea impreuna cu oferta, certificate pentru fiecare

componenta care foloseste protocolul OPC care sa ateste ca implementarea

106

protocolului OPC este conforma in totalitate cu standardele din specificatie.

Certificarea trebuie efectuata de un laborator de teste certificat din UE.

8.6 Echipa de Proiect

Dupa primirea ordinului de incepere a lucrarii, ofertantul va mobiliza imediat echipa

responsabila pentru acest proiect. Aceasta echipa va ramane responsabila pe tot

parcursul derularii Contractului. Va fi condusa de un director de proiect care serveste ca

partener de comunicare central cu beneficiarul si consultantul si va fi responsabil pentru

continutul livrarilor si realizarii tuturor activitatilor prevazute in cadrul acestui contract

precum si pentru respectarea programului proiectului.

Toata echipa de proiect va fi desemnata nominal.

8.7 Lista de Activitati Inclusa in Graficul de Implementare

In cadrul duratei totale a contractului de 18 luni + 12 luni perioada de garantie pentru

remedierea defectelor, ofertantul este liber sa propuna termene intermediare proprii, cu

conditia respectarii succesiunii activitatilor prezentate mai jos:

Activitatea Termenul de

executie

A Livrarea echipamentelor conform graficului de livrare propus de

ofertat

Predarea documentatiei referitoare la caracteristicile individuale

ale echipamentelor care vor fi montate in dispecerat

(documentatie de producator, certificate de garantie, atestate de

calitate, certificate de conformitate, pachetele software (kit-urile

de instalare) si licentele atat pentru sistemele de operare cat si

pentru aplicatiile software specifice procesului, etc), exceptie

facand manualul de exploatare al sistemului care se va cere doar

dupa integrarea completa a tuturor sistemelor SCADA locale.

B. Instalarea sistemului informatic la nivel de Dispecer care necesita:

1 Instalarea tuturor componentelor hardware (echipamente de

107

retelistica, echipamente de comunicatie, servere, imprimante,

UPS-uri, monitor de vizualizare, instal. de climatizare, pardosea

tehnologica si infrastructura de protectie la nivelul enclavei IT&C,

cablarea structurata specifica camerei de comanda, etc.) si a

mobilierului aferent locatiei de dispecer, mobilier care deserveste

operatorul (dispecerul);

2 Instalarea software-ului de operare aferent serverelor sistemului

SCADA (sistemele de operare), instalarea pachetului software de

aplicatie cu toate modulele ofertate, instalarea pachetului

software antivirus si a altor aplicatii software utilitare (arhivatoare,

office, vizualizatoare, etc.).

3 Testarea preliminara a aplicatiilor SCADA, testarea stabilitatii si

integritatii comunicatiei intre sistemul SCADA-DTR si entitatile

(punctele de achizitie a datelor) ce urmeaza a fi integrate,

testarea redundantei surselor neintreruptibile de alimentare si a

autonomiei de functionare a acestora, testarea redundantei

serverelor de proces – preluarea automata a controlului de catre

server-ul aflat in standby, testarea sistemului automat de Back-

up, testarea locala a mecanismului de sincronizare prin GPS,

testarea avertizarii acustice, verificarea structurilor de ecrane

specifice aplicatiei SCADA precum si a elementelor / obiectelor

continute in aceste ecrane, stabilirea unei ierarhizari / prioritizari

in ceea ce priveste alarmele si evenimentele ce urmeaza a fi

achizitionate, realizarea inscriptionarii si a etichetarilor in vederea

identificarii a tuturor panourilor, echipamentelor de calcul si

retelistica, cablurilor, sigurantelor automate, sirurilor de cleme,

etc. folosindu-se codul de identificare din DdE (Detaliile de

Executie).

4 Predarea documentatiei referitoare la sistemul informatic in

ansamblu (toate licentele pentru Softwere si aplicatiile dedicate,

etc), exceptie facand manualul de exploatare al sistemului care se

va cere doar dupa integrarea completa a tuturor sistemelor

SCADA locale.

C. Integrarea sistemului local de control si monitorizare (SCADA

108

local) in sistemul SCADA-DTR care necesita:

1 Configurarea bazei de date la nivel de sistem SCADA-DTR astfel

incat sa fiecapabila sa achizitioneze toata informatia mapata de la

nivel de sistem SCADA local;

2 Realizarea testarii functionalitatii structurilor de ecrane generale

(globale) si individuale pentru sistemul SCADA local ce urmeaza

a fi integrat;

3. Stabilirea exacta a listei de semnale analogice & digitale (Signal

I/O List) ce urmeaza a fi mapata in aplicatia grafica de dispecer.

Asignarea gradului de prioritate pentru fiecare semnal din lista de

semnale mentionata anterior.

4 Realizarea lucrarilor de inginerie in punctele de achizitie a datelor

privind integrarea efectiva (maparea semnalelor din sistemul

SCADA local si preluarea integrala a acestora in serverele de

proces aferente sistemului SCADA-DTR). Aplicarea tuturor

semnalelor astfel achizitionate a criteriilor de selectie descrise la

punctul 3.

5. Elaborarea de catre Integrator a procedurilor de testare specifice

aplicatiei (Site Test Procedure), buletine de verificare (Site Test

Sheets) si a unei metodologii de testare (Methode Statement)

care sa cuprinda detaliat operatiunile si actiunile intreprinse pe

durata testarii.

Nota: Toate aceste proceduri de testare si metodologii trebuie in

prealabil sa fie avizate de catre Beneficiar care-si rezerva dreptul

de a le completa cu eventuale teste suplimentare pentru a se

certifica corecta functionare a sistemului. Realizarea procedurilor

anterior mentionate trebuie sa fie bazata pe standardele

internationale de specialitate aflate in vigoare cu particularizare

pe aplicatia Beneficiarului. Totodata trebuie sa se tina cont la

elaborarea acestei documentatii si de eventualele standarde sau

politici interne ale Companiei.

6. Teste de acceptanta (SAT – Site Acceptance Test) efectuate

dupa realizarea procesului de integrare de la punctul 3. Acest

lucru presupune testarea completa in serverele de proces ale

109

sistemului SCADA-DTR a tuturor semnalelor preluate din proces

de PLC-uri si mapate ulterior pe protocol OPC.

7. Probe functionale (FT – Functional Test) sau probe cap la cap

(end to end test) initiate dupa finalizarea testelor de acceptanta.

Aceste teste cuprind simularea semnalelor din proces (de la

sursa) si urmarirea feedback-ului acestora direct in sistemul

SCADA-DTR, inclusiv modalitatea de functionare a ecranelor

generale si a subecranelor orientate pe aplicatie integrata.

D. Integrarea presupune parcurgerea urmatoarelor etape:

1. Verificarea functionalitatii tuturor ecranelor, subecranelor,

mecanismelor de avertizare optica si acustica si a tuturor

modulelor software care constituie aplicatia integrata de

supervizare. De asemenea, subpunctul se considera finalizat doar

daca este asigurata stabilitatea comunicatiei dintre dispecer si

site-urile monitorizate.

Nota: Toate aceste verificari vor urmari operatiunile descrise in

procedurile de testare la care s-a facut referire la punctul 5 al

sectiunii C.

2. Predarea documentatiei aferente: STS – Site Test Sheets

(buletine de verificare rezultate in urma testelor si a documentatiei

de executie reactualizata cu situatia din teren (DdE – Detalii de

Executie + As Built).

Nota: Toate aceste proceduri de testare si metodologii trebuie in prealabil sa fie avizate

de catre Beneficiar care-si rezerva dreptul de a le completa cu eventuale teste

suplimentare pentru a se certifica corecta functionare a sistemului. Realizarea

procedurilor anterior mentionate trebuie sa fie bazata pe standardele internationale de

specialitate aflate in vigoare cu particularizare pe aplicatia Beneficiarului. Totodata

trebuie sa se tina cont la elaborarea acestei documentatii si de eventualele standarde

sau politici interne ale Companiei.

Avand in vedere faptul ca acest grafic de activitati este legat cu graficul de executie al

platilor, activitatea se considera finalizata in momentul in care Conform precizarilor din

Vol. 2 au fost indeplinite toate conditiile pentru aprobarea fiecarei subactivitati.

110

9 RAPOARTE ALE PROIECTULUI

9.1 Cerinte privind raportarea

Principalele activitati derulate in cadrul contractului sunt detaliate in cap. 5

Descrierea modului de indeplinire a activitatilor va face obiectul unor rapoarte lunare de

activitate, insotite de documente suport, care trebuie redactate şi prezentate de către

furnizor in baza propriei metodologii de organizare propusa in cadrul ofertei tehnice.

Furnizorul va trebui să întocmească şi sa depună documentatiile atât în format

electronic cât şi pe hârtie în limba română. Se vor depune trei exemplare pe hartie + 1

CD din fiecare raport.

Rapoartele menŃionate în continuare vor acoperi toate activităŃile Proiectului şi vor

puncta toate rezultatele obŃinute de către Prestator.

9.2 Depunerea si Aprobarea Rapoartelor

In termen de o luna de la finalizarea subactivitatilor, asa cum au fost acestea detaliate

in cap. 5, ofertantul va transmite Beneficiarului un raport complet de activitate insotit de

toate documentele suport definite in prezentul caiet de sarcini.

Formatul Rapoartelor se va stabili de comun acord cu Reprezentantul Autoritatii

Contractante desemnat cu urmarirea executiei lucrarilor care fac obiectul prezentului

Caiet de Sarcini.

Reprezentantul Autoritatii Contractante cu rol in supravegherea punerii în operă

(montajul) a echipamenteleor SCADA in conformitate cu continutul cap.5 din prezentul

Caiet de Sarcini precum si cu corelarea lucrărilor cuprinse în cele 7 contracte de lucrări

aflate in derulare (vezi tabelul urmator) este Consultantul pentru Supervizare desemnat

in cadrul Contractului de Servicii AsistenŃă Tehnică pentru Supervizarea Lucrărilor

„Extinderea şi reabilitarea sistemelor de apă si apă uzată în JudeŃul Olt”

Toate rapoartele vor fi inaintate spre analiza si aprobare Reprezentantului Autoritatii

Contractante, in conformitate cu graficul de executie stipulat in capitolul 5, la datele

mentionate in oferta tehnica a furnizorului.

Reprezentantul OR va aproba rapoartele sau va prezenta observaŃiile sale în termen

de 28 zile de la data depunerii.

111

In cazul în care în termen de 30 zile de la depunere Furnizorul nu primeşte nici

aprobarea şi nici observaŃii asupra unui anume raport, atunci acesta se consideră ca

fiind aprobat în mod implicit.

9.3 Monitorizarea Proiectului

Se vor organiza intalniri lunare cu privire la progresul lucrarilor, intre ofertant,

Reprezentantul Autoritatii Contractante (Inginerul) si beneficiar/Autoritatea Contractanta

pentru a analiza stadiul realizarii proiectului la acea data si pentru planificarea

activitatilor viitoare destinate implementarii in termenele stabilite in graficul de executie

propus de Ofertant. Aceste intalniri vor avea loc la sediul Reprezentantului Autoritatii

Contractante. Frecventa si calendarul acestor intalniri vor fi stabilite ulterior emiterii

Ordinului de Incepere a lucrarilor.

Separat de cerintele specifice ale beneficiarului, intalnirile de proiectare sau intalniri ad-

hoc trebuie documentate cu rapoarte (acolo unde este cazul) sau minute scrise. In

aceste rapoarte ale intalnirilor vor fi trecute toate informatiile, specificatiile si deciziile,

starea prezenta a derularii proiectului, intarzieri fata de programul proiectului, dificultati,

procedurile urmatoare etc. Minutele de proiect vor fi scrise in maximum 3 zile lucratoare

de la data sedintei (preferabil in timpul intalnirii de proiect in sine) si trebuie prezentate

tuturor participantilor la sedinta pentru a fi acceptate.

De asemenea, dupa emiterea Ordinului de incepere a lucrarilor, Ofertantul desemnat

castigator va transmite Reprezentantului Autoritatii Contractante un grafic de plati

corelat cu graficul de executie al contractului spre analiza. Procedurile specifice

intocmirii situatiilor de lucrari in vederea decontarii, corespondenta, etc vor fi stabilite in

cadrul unei sedinte de inceput organizata la o data comunicata ulterior de catre

Reprezentantul Autoritatii Contractante.

9.4 Documentatia de Proiect

Documentarea sistemului in cadrul cerintelor specifice ale beneficiarului, inclusiv

descrierea partii hardware, software si a sistemului ca un intreg, va fi executata intr-un

software standard cum ar fi Word, Excel, Access, PowerPoint; desenele trebuie

prezentate cu Microsoft Visio si/sau ACAD sau cu un soft compatibil cu cele pe care

Beneficiarul le are in dotare.

112

La data livrarii, software-ul folosit la executarea documentatiei trebuie sa fie la ultima

versiune, sau in mod alternativ sa fie up-datat la ultima versiune. Intreaga documentatie

aferenta software-ului folosit precum si software-ul trebuie inaintate spre verificare

Inginerului impreuna cu rapoartele de proiect si eventuale notificari privind modificari

fata de solutia initiala. Documentatia de proiect trebuie prezentata pe suport de hartie

precum si in format electronic (CD). Desenele sau schemele se vor executa in

AUTOCAD sau similar. Lucrarile vor fi executate doar in concordanta cu documentele

verificate de Inginer si aprobate de Beneficiar. Acceptarea de catre Inginer nu absolva

ofertantul de responsabilitatile in ceea ce priveste livrarile, performanta si

responsabilitatea pentru intreg proiectul. In nici un moment sarcini de proiectare sau de

inginerie nu vor fi responsabilitatea Beneficiarului. In acest sens cerintele specifice ale

Beneficiarului trebuie privite ca o documentare a modului de realizare a proiectului,

acceptata de Inginer, care nu aduce termeni contractuali noi.

9.5 Livrarea

Livrarea este conditionata de acceptarea prealabila emisa de catre Beneficiar, pe baza

recomandarilor facute de catre Inginer.

Livrarea componentelor sistemului, inclusiv ambalajele, la locatia de santier va fi facuta

fara costuri aditionale. Livrarea se va face confom planului de livrare propus de

Ofertantul desemnat castigator si aprobat de Inginer. Inginerul trebuie anuntat cu cel

putin 2 saptamani inaintea livrarii, astfel incat masurile organizatorice sa poata fi luate

din timp. In general este de asteptat ca livrarile sa aiba loc la momentele stabilite.

Toate componentele sistemului, parti de echipamente, dispozitive si facilitati care ii sunt

comandate Furnizorului sunt parte integranta a livrarii, asa cum sunt si cabluri de retea

si de distributie, precum si toate materialele necesare pentru instalare, ansamblare si

fixare.

Oferta trebuie sa includa transportul, impachetarea, livrarea, asigurare de transport si

indepartarea materialelor folosite la ambalare. Datele livrarilor trebuie sa fie specificate

conform cu programul de livrare acceptat de Inginer.

113

9.6 Asamblarea si Instalarea

Toate masurile necesare pentru ansamblare, instalare, constructie, fixare si conectare

trebuie luate si indeplinite de catre ofertant.

Ansamblarea, instalarea, construirea, fixarea si conectarea, intocmirea si inmanarea

documentatiei preliminare privitor la ansamblare trebuie deasemenea sa fie incluse in

oferta.





echipa de Proiect din partea beneficiarului.

In plus, aprovizionarea cu aparate de masura si testare, precum si alte scule, unelte si

echipamente necesare pentru o ansamblare si instalare rapida si corespunzatoare

trebuie incluse in oferta.

In timpul ansamblarii, instalarii si punerii in functie, ofertantul va tine un jurnal al

instalarii in modul sugerat de beneficiar.

9.7 Servicii Oferite de Beneficiar

Beneficiarul confirma ca locatiile folosite vor fi curate si gata pentru procesul de

ansamblare si instalare, astfel incat lucrarile sa demareze cat mai curand. Este sarcina

ofertantului sa curete periodic si la final incaperile folosite de el.

9.8 Securitatea Muncii

• Se vor respecta prevederile IPSSM 001/2007

• Se va completa fisa analiza de risc pentru locatiile in care se lucreaza

• Se va face o prezentare introductiva a locurilor in care se va lucra

• Se vor prezenta proceduri de lucru in instalatiile beneficiarului

• Toate lucrarile asociate realizarii proiectului trebuie realizate cu urmarirea atenta

a tuturor:

• Prevederilor legale,

• Normelor tehnice,

114

• Regulamente interne de lucru ale Electrica Distributie Transilvania Sud.

Contractorul va efectua o analiza detaliata de risc, in conformitate cu prevederile legii

nr. 319 / 2006, privind siguranta si securitatea muncii. Aceasta va fi parte a planului de

management al calitatii, mediului si sigurantei muncii.

9.9 Mecanismul Cooperarii

• Furnizorul va colabora direct cu Inginerul-Consultantul pentru supervizarea

lucrarilor, care reprezinta Autoritatea Contractanta. Astfel, intreaga

corespondenta, documentatie tehnica, organizare intalniri, etc se vor derula prin

intermediul Inginerului. Acesta, va instiinta Beneficiarul/Autoritatea Contractanta

prin Unitatea de Implementare a Proiectului, din cadrul OR. Ori de cate ori este

necesar, Ofertantul desemnat castigator va solicita, prin Inginer, prezenta

expertului SCADA desemnat in cadrul contractului de Asistenta tehnica pentru

managementul proiectului in baza următoarelor principii:

• Consultare şi consens

• Transfer de experienŃă

• Eficienta

• Mecanismul de cooperare cu AC va fi dezvoltat în cel mai eficient mod, pentru a

evita orice întârziere sau discontinuitate în procesul decizional, evitând diminuarea

responsabilităŃii Prestatorului.

• Prin natura lor, serviciile care fac obiectul prezentului contract implică o

cooperare directă între Furnizor şi personalul desemnat de către CAO să

gestioneze proiectul; simultan, se va asigura transferul de experienŃă necesar.

• Personalul CAO va fi direct implicat în procesul de implementare şi în toate

activităŃile aferente cu obiectivul de a acumula suficientă competenŃă şi experienŃă

pentru a gestiona sistemul SCADA implementat in cadrul acestui contract.

• Personalul CAO va fi implicat în activităŃile de zi cu zi împreună cu experŃii din

echipa Furnizorului.

115

10 LISTA STANDARDELOR

SR CEI Seria 60050 – Vocabular Electrotehnic International;

SR CEI Seria 60300 – Managementul siguranþei în functionare;

SR HD Seria 60364 – Instalaþii electrice de joasa tensiune;

SR EN Seria 60446 – Principii fundamentale si de securitate pentru interfata om-

masina;

SR EN 60529 – Grade de protectie asigurate prin carcase (cod IP);

SR CEI Seria 60706 – Ghid de mentenabilitate a echipamentului;

SR EN Seria 61000.4-12 – Compatibilitate electromagnetica (CEM – Standard de

baza în CEM – Încercari de imunitate);

SR EN Seria 61140- Protectia împotriva socurilor electrice;

SR EN 61508 – Securitatea functionala a sistemelor electrice / electronice;

SR EN 50263: Compatibilitatea electromagnetica (CEM). Standard de produs pentru

relee de masura si dispozitive de protectie;

ISO 9001-2008 : Sisteme de managementul calitaþii. Cerinþe.

IEC 60255-21-1 Vibration requirements

IEC 60255-21-2 Shock requirements

IEC 60446 Conductors identification using colours and numbers

IEC 61000 Electromagnetic compatibility

IEC 61346 Industrial systems, installations and equipment and industrial products

PE 505/73 – Regulament de Exploatare Tehnica a camerelor de control si de

supraveghere a instalatiilor

LEGE 608/2006 privind evaluarea conformitaþii produselor

IEC60834-1 Command and Control Systems

IEC 60068 – Environmental Testing

IEC 60073 Basic Safety principles for human-machine interface (HMI), marking and

identification

116

IEC 600297 – 19 inch rack

IEC 60870 – Telecontrol equipment and systems

IEC61000 – Electromagnetic compatibility (EMC)

IEC61131 – PLC Programming

IEC 61158 – Industrial communication network – Fielbus specification

IEC 61588 – Precision clock synchronization protocol for networked measurement

and control systems

IEC 62040 – Uninterruptible power systems

IEC 62264 – Enterprise-control system integration

IEC 62351 – Power System Control and Associated Communications - Data and

Communication Security

IEC 62443 – Industrial communication networks - Network and system security

(DRAFT)

IEC 62455 – Internet protocol (IP) and transport stream (TS) based service access

118

11 ABREVIERI

CAO Compania de Apă Olt CL Contracte de Lucrari

DL Dispecerat Local DTR Dispecerat de Telecontrol Regional

EMMI Echipe Mobile de MentenanŃă şi IntervenŃie

GPRS General Packet Radio System [Serviciul de transfer radio bazat pe pachete de date]

GPS Global Positioning System

[Sistem de radio-navigaŃie globală] GUI Graphycal User Interface

[InterfaŃă Grafică cu utilizatorul]

HMI Human Machine Interface [InterfaŃă grafică om-maşină]

IT & C Information Technology and Communication [Tehnologia informaŃiei şi telecomunicaŃii]

ISDN Integrated System for Digital Network

[ReŃele digitale/numerice cu integrarea serviciilor – RNIS]

119

ISO International Standard Organization

LAN Local Area Network [ReŃea de date cu arie limitată de acoperire]

MIS Management Information System [Sistem informatic integrat pentru managementul companiei]

OR Operator Regional OSI Open System Interconnection

PL Punct de Lucru POO Proiectare Orientată pe Obiecte

RTDB Real Time Data Base [Bază de date în timp real]

RAPP Remote Aquisition and Process Point

[Punct distant de achizișie și proces]

SCADA Supervisory Control And Data Aquisition [Sisteme de supervizare, control şi achiziŃie a datelor]

SDL Sistem de Dispecerizare Local SDZ Sistem de Dispecerizare Zonal

SAT Site Acceptance Test (Teste de acceptanŃă în site)

120

SIP Sisteme Informatice de Proces SP Statie de Pompare

WAN Wide Area Network [ReŃea de date cu acoperire mare/extinsă]

Caiet de Sarcini

Documents

Transcript of Caiet de Sarcini