Caiet de Sarcini

1
DOCUMENTAIE 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 Lucrri specifice pe partea electric i de automatizri ............................. 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 Consideraii 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 Cerine privind colarizarea Personalului de Exploatare........................... 98
7.6.2 Cerine 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

6

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 oraele: Drgneti-Olt, Scorniceti, Piatra-Olt
i Potcoava. Judeul 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
reea de ap de 133,372 km i canal 106,12 km (inclusiv extindere);
Drgneti-Olt 12.195 locuitori, aductiune 5 km, o reea de ap de 29,652km
i canal de 14,5 km (inclusiv extindere);
Scorniceti 12.679 locuitori aductiune 3,8 km, o reea de ap de 27,8 km i
canal de 14,5 km (inclusiv extindere);
Piatra-Olt 6.347 locuitori aductiune 1,7 km, o reea de ap de 41,9 km i canal
de 7,7 km (inclusiv extindere);
Potcoava 6.111 locuitori aductiune 2,87 km, o reea de ap de 17,2 km i
canal de 6,6 km (inclusiv extindere);
Activitile principale ale S.C. CAO S.A. sunt: captarea, tratarea i distribuia apei
precum i colectarea i epurarea apelor uzate n Municipiul Slatina i cele 4 orae
(aglomerari urbane): Scorniceti, Drgneti-Olt, Piatra-Olt i Potcoava.
Apa este preluat din surse subterane, puuri 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 furnizrii continue a apei la o calitate conform cu standardele
naionale i europene.

8
2. Asigurarea calitii apelor uzate epurate evacuate din staiile de epurare conform
NTPA 11/2005.
3. Asigurarea furnizrii continue a serviciilor de canalizare a apelor uzate;
4. Meninerea i mbuntirea continu a Sistemului de Management Integrat
Calitate, Protecia Mediului, Sntate i Securitate Ocupaional, conform
standardelor ISO 9001, ISO 14001 i OH SAS 18001;
5. Meninerea orientrii activitii companiei ctre clieni;
6. Contorizarea integral a consumatorilor deservii de Compania de Ap Olt S.A.;
7. Creterea volumului surselor atrase pentru investiii n infrastructura de ap i
ap uzat.
8. Reducerea consumului i a cheltuielilor cu energia electric.
9. Lrgirea ariei de operare prin cooptarea altor localiti n cadrul operatorului
regional.
10. Valorificarea nmolurilor din staiile de epurare, rezultate n urma epurrii 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, cuprinznd 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 cnd 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 inct 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, cnd, 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.

13

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 oraele: Drgneti-Olt,
Scorniceti, Piatra-Olt i Potcoava.
In prezent se afla in faza de implementare un proiect cu cofinantare UE, in vederea
reabilitrii generale a infrastructurii de alimentare cu ap i canalizare din Regiunea
oraselor: Slatina, Drgneti-Olt, Scorniceti, Piatra-Olt i Potcoava din Judeul Olt.
Principalele activiti 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 desfura n aria regiunii formate
din oraele:
o Slatina,
o Draganesti-Olt,
o Scornicesti,
o Piatra-Olt,
o Potcoava.
n ceea ce privete activitatea de ntreinere i reparaii, OR a realizat o strategie pe
termen scurt i mediu. Majoritatea activitilor de ntreinere i reparaii sunt si vor fi
coordonate de la sediul central, acolo fiind localizate echipele mobile de intretinere si
intervantie impreuna cu principalele echipamente de interventie.

15

16

17
4 DEFINIREA PROIECTULUI
4.1 Obiectivul Proiectului
In conformitate cu cerinele 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 Cerinele Angajatorului, pentru municipiul Slatina au fost prevzute
Lucrri la sursele de ap potabil, tratare apa si retele de alimentare cu apa pentru
urmtoarele locaii:
Front captare dreapta, front captare stanga
staia Salcia, staia N. Blcescu (tr.1), staia Oituz, staia Crian (tr.2).
statii hidrofoare (nr buc = 12)
Pentru toate cele 4 staii anterior menionate n subsidiarul Slatina sunt prevazute pe
contractele de lucrari, realizarea de staii de tratare noi dotate cu dispecerate locale de
control (DL). Cu alte cuvinte, la finalizarea contractelor de lucrri 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:
Cmp Zona Nou, Cmp Vid, Cmp Zona D, Cmp Curtioara (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 Cerinele Angajatorului, pentru aglomerarea Potcoava au fost
prevzute Lucrri 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 staii 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 lucrri 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 Cerinele Angajatorului, pentru aglomerarea Draganesti-Olt au fost
prevzute Lucrri la sursele de ap potabil i ap uzat pentru care sunt prevazute
pe contractele de lucrari, realizarea unei staii 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 lucrri 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 Cerinele Angajatorului, pentru aglomerarea Piatra-Olt au fost
prevzute Lucrri la sursele de ap uzat pentru care sunt prevazute pe contractele
de lucrari, realizarea unei staii noi de epurare prevazuta cu dispecerat local. Cu alte
cuvinte, la finalizarea contractelor de lucrri 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 Cerinele Angajatorului, pentru aglomerarea Scornicesti au fost
prevzute Lucrri 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 asigurrii unui sistem eficient de monitorizare al debitelor gestionate de
Operatorul Regional, adiional fa de lucrarile deja contractate n cadrul proiectului
Extinderea i reabilitarea sistemelor de apa i ap uzat n judeul Olt
(implementarea unui sistem SCADA Regional, prevederea de debitmetre la nivelul
surselor de ap, a staiilor de tratare ap i pe reelele de distribuie pentru
monitorizarea reelei n mprirea acesteia n zone de msurri 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, ctre
dispeceratul Regional SCADA, de date privind n principal mrimea i evoluia 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 att local (pe display-ul debitmetrului)
ct i la distan prin intermediul dataloggerului. 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 inserie, cu
dimensiuni, funcie de diametrul nominal (DN) al tronsoanelor monitorizate, diametrul
interior (Di) al conductelor respective, debitul i implicit viteza apei n conduct.

32
5.2.1 LUCRRI SPECIFICE PE PARTEA ELECTRIC I DE AUTOMATIZRI
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, prevzut cu echipamente industriale de fiabilitate ridicat, funcionnd n
topologie redundant pentru asigurarea continuitii fr ntreruperi. Rolul DTR este
acela de coordonare a tuturor subreelelor de achiziie de date din aglomerrile aflate n
aria de interes a Companiei.
Dispeceratele Locale reprezint de fapt reele locale de date (LAN) situate n
aglomerarile aflate n aria/zona de interes a Operatorului Regional, care achiziioneaz
i proceseaz (n funcie de specificul activitii) informaiile primare ale procesului
(nivelul apei, monitorizare debite, telemetrie, semnale de diagnosticare, etc.) i le pune
la dispoziia att a operatorului local al entitii conduse ct 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
msura i transmisie de la aceste puncte de msura, transmisia datelor la SCADA-
DTR, preluarea, afiarea i stocarea datelor din cmp. Tipul de transmisie de la
punctele de msura debit va fi 3G/GPRS/GSM, cu posibilitatea de transmitere de SMS /
e-mail de avertizare (la depire praguri debit i presiune, lips alimentare, lipsa ap n
conduct).
Pentru partea de telemasur se va urmari achiziia i transmiterea catre SCADA-DTR
a cel puin urmtorilor parametri:

Afiare debit instantaneu;
Afiare debit totalizator pozitiv, negativ i total, avertizare lips ap n conduct;
Avertizare depire debit maxim admis;
Avertizare depaire presiune maxim admis;
Indicare presiune;
Alarmare n caz de putere minim baterie;
Indicare stare comunicaie GPRS.
Sistemul SCADA-DTR va include afiarea de grafice de tendin (Trend View) pe
diferite perioade a tuturor mrimilor transmise i stocarea acestora pe o perioad de
minim 1 an. Intervalul de comunicaie / actualizare a datelor va fi 1 data / 60min, cu
posibilitatea configurrii ulterioare funcie de necesiti.

33
Datele stocate de ctre datalogger vor avea posibilitatea de a fi descrcate i pe un
dispozitiv tip laptop sau PDA, direct din acesta la faa locului prin conexiune directa pe
cablu sau wireless (ex. Bluetooth).
Lucrri 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 comunicaie, antena GSM se va monta pe un
suport n exteriorul cminului);
setare parametri debitmetru, datalogger conform instruciunilor de montaj ale
productorilor;
executare legturi electrice i semnalizare la debitmetru, datalogger i anten
GSM;
execuie branament electric (doar pentru debitmetrele instalate n incinta staiilor
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 funcionare i poziionare
a debitmetrelor n zonele:
Potcoava i Drgneti-Olt (Anexa 6.1);
Scorniceti, Piatra-Olt i Bistria 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
informaii de plecare pentru proiectarea sistemului centralizat de telecontrol i
supervizare, sunt urmtoarele:
Toate staiile locale dispun de acoperie minim GPRS;

35
Sistemele SCADA aferente dispeceratelor locale dispun de cate un PLC, care
centralizeaz informaiile, fie de producie ap (puuri, rezervoare, staie de
tratare, etc.), fie de epurare ap (etape epurare, rezervoare, pompare, etc).
Sistemele SCADA locale vor dispune de funcionaliti 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 staiile sunt autonome, iar funcionarea lor nu depinde de starea
comunicaiilor 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 reele de date
locale LAN (Local Area Network) care achiziioneaz i proceseaz fluxul informaional
primar (nivelul apei, monitorizare debite, telemetrie, semnale de diagnosticare, etc.) si
apoi il transmit prin intermediul reelei de comunicaie ctre nivelul ierarhic superior
(Dispeceratul de Telecontrol Regional - DTR).
Instalaiile de comand, automatizare, msur 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 legtur 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 urmrirea parametrilor de funcionare care se va
face prin intermediul terminalelor om-main (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 configuraie modular i deschis
(scalabilitate), astfel nct 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, obinerea i mentenana informaiei 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 producie;
o compresia eficient a datelor;
o autoconfigurarea stocrii de istorice, ce elimin efortul de a crea
variabilele de doua ori;
o un server de gestiune a informaiei via web care simplific organizarea i
prezentarea informaiilor referitoare la operaiunile din procese, care
permite printre alte faciliti, 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);
Fiecrui Obiect i se pot defini urmtoarele proprietti/ atribute:
o Intrri / Ieiri (I/O);
o Semnale preventive i de avarie (Alarme i Evenimente);
o Aplicaii / scripturi si configurare de istorice;

39
o Atribute de securitate;
o Caracteristici obiect (cod de culori, dinamic, etc.);
Aceste obiecte se vor include n librrii de obiecte, ce vor avea urmtoarele
caracteristici:
Posibilitatea de a crea abloane (templaturi);
Orice modificari n librrie vor fi actualizate n tot sistemul;
Posibilitatea de a crea / definii noi librrii pornind de la cele existente;
Posibilitatea crerii unor librrii de obiecte standard;
Posibilitatea crerii 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 funcionare;

40
emiterea comenzilor de functionare de la distanta;
nregistrarea evenimentelor;
managementul alarmelor;
stocarea datelor;
realizarea rapoartelor;
urmrirea operaiilor de ntreinere;

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;
numr ore de funcionare echipamente.

6.2.3 MODUL DE PREZENTARE AL INFORMATIILOR

Debit
valoarea instantanee;
valoarea pe zi;
afiare grafic pe orice perioad selectat cu funcie de mrire zoom;
stocarea datelor pe perioada dorita

Nivel
afiare grafic pe orice perioad selectat cu funcie de mrire zoom;
stocarea datelor pe perioada dorita.

Presiune
afiare grafic pe orice perioad selectat;
stocarea datelor pe perioada dorita

Control clorinare n pct. de msur (statia de pompare si rezervoare)

41
afiare grafic pe orice perioad selectat;
stocarea datelor pe perioada dorita.

Numr ore de funcionare pompe
afiare tabelar;
alarmarea personalului de ntreinere 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 ieire instantaneu / total (unde este cazul);
alarmare (senzor) anti-efracie 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 aspiraie grup pompare;
presiune refulare grup pompare;
debit distribuit gravitaional instantaneu / total;
debit pompat instantaneu / total;

42
stare (on/off/avarie) grup pompare;
starea (on/off/avarie) si frecvena de lucru a convertizoarelor (unde este cazul);
automatizare locala a grupului de pompare pentru functionare n regim automat
n funcie de nivelul din rezervor (automat ntre niv. min/max, rotire automat a
pompelor);
alarmare (senzor) anti-efracie 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 funcie de presiunea din
container);
valoarea clorului rezidual n apa distribuit;
stare (caracteristici) grup injecie clor (pompe on/off);
comanda la distanta de la dispecerat a opririi/pornirii grupului de injectie clor
alarmare (senzor) anti-efracie 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 staiile de epurare mici, n funcie i de schema tehnologic adoptat, se vor
avea n vedere achizitionarea urmtoarelor informatii:
monitorizarea i controlul debitului incident de ap uzat n staia de epurare n
vederea nivelrii ncrcrii hidraulice i cu poluani pe parcursul celor 24 ore ale
zilei;
monitorizarea nivelului de funcionare al pompelor de ape brute;
supravegherea automat a strii de funcionare a pompelor (pornit/oprit, valoare
curent absorbit, existena tuturor fazelor la alimentarea cu energie electric,
corelarea strii de funcionare cu debitul pompat);
controlul evacurii de nmol primar, dac staia este prevzut cu decantor
primar, prin controlul debitului evacuat;
controlul concentraiei de oxigen din bazinul de aerare, dac staia este cu nmol
activat;
controlul evacurii de nmol 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 nmol activ de recirculare n cazul n care staia este cu
nmol activat;
controlul strii suflantei pentru aer comprimat, a pompei de recirculare, a vanelor
de evacuare a nmolului n exces;
monitorizare, mcar TS (suspensii) la ieirea din staie;
dac staia de epurare este prevzut cu treapt biologic cu pelicul biologic,
se va monitoriza sistemul pe care se fixeaz pelicula biologic (biodiscuri,
biotambur, elemente ale filtrului biologic), stare de funcionare, turaie, debit;
dac staia este prevzut cu sistem de colectare i dezhidratare mecanic a
nmolului, se va monitoriza starea de funcionare i a acestei instalaii;

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 integrrii n viitor i a staiei 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 prevzut cu posibilitatea hardware i
software de a integra complet in viitor nc un 8 subsisteme informatice cu toate
funciunile 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;
Telemsura debitmetriei de retea;

(2). Cerinte de Sistem Informatic de Proces
Arhitectur deschis (Open Architecture) trebuie asigurata posibilitatea
interconectrii si a integrrii ulterioare (upgrade/extension) a echipamentelor
si/sau a sistemelor provenite de la productori diferiti;
Interoperabilitate/Interconectivitate trebuie asigurata posibilitatea integrrii
complete si a functionrii 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
productor ns respectnd acelasi standard. Echipamentele unui sistem IT&C
trebuie s poat fi nlocuite, la nevoie (fr pierderea partial sau total a
functiunilor) atat cu alte echipamente de acelasi tip de la acelasi productor cat si
cu echipamente de la productori diferiti, fara a fi necesare investitii
suplimentare.
Creterea fiabilitii 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 descongestionrii sistemului central.
Partajarea resurselor. Trebuie sa devina accesibilila oricrui utilizator care
poate avea acces att la bazele de date ct i la programele care gestioneaz
procesul n derulare.
Gradul de securizare trebuie sa fie unul crescut. Se vor utiliza in acest sens
comunicaii 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 distani de a accede n mod autorizat
la informaia pus la dispoziie de sistemul complex care gestioneaz procesul
prin intermediul conectivitii tip broadband, mrindu-le astfel flexibilitatea i
eficiena.
Asigurarea cresterii rentabilitii (economie de cost), trebuie asigurat un raport
pre / performan mai bun, prin utilizarea unor capaciti de prelucrare i
comunicaie performante, integrate n sistemele proiectate, care s elimine
necesitatea unor reele 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, prevzut cu echipamente industriale de
fiabilitate ridicat, funcionnd n topologie redundant pentru asigurarea continuitii
fr ntreruperi.
Dispeceratele Locale (DL) reprezint de fapt reele locale de date (LAN) situate n
oraele aflate n aria/zona de interes a Companiei de Apa Olt (care vor fi realizate in
cadrul contractelor separate aflate in derulare), care achiziioneaz i proceseaz (n
funcie de specificul activitii) informaiile primare ale procesului i le pun la dispoziia
att a operatorului local al entitii conduse prin intermediul sistemului SCADA local, ct
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 inndu-se cont de contractele de modernizare aflate n derulare (n diverse
stadii) precum i de solicitrile 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
Soluia optimizat pentru routarea i procesarea informaiei prelevate de la nivel de
proces respect urmtorul mecanism:
(i) Integrarea (n vederea telecontrolului) fluxului informational provenit de la
unitile 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
unitile de cost din aglomerrile urbane: Slatina, Potcoava, Draganesti-Olt,
Piatra-Olt i Scornicesti.
La nivel de dispecer va exista o interfa grafic unitar care va colecta ntreg
fluxul informaional achiziionat din proces, oferind operatorului posibilitatea
monitorizrii i controlului activitii de exploatare.
Interfaa 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 (premergtoare fazei de
SAT Site Acceptance Test). Grafica va fi construit n conformitate cu
solicitrile i strategia de exploatare a Beneficiarului.
(ii) Debitmetria de reea 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 locaii 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 comunicaie 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 aplicaie care va rula constitui platforma SCADA a
sistemului de dispecerizare regional de dispecer va cuprinde obligatoriu
urmtoarele module:
Achiziie i control proces;
Rapoarte;
Centralizare i procesare si validare a datelor achiziionate;
Portal web;
Modul de gestionare al clientilor si al procesului de mentenanta.
Not
Detalierea modulelor software aferente platformeu SCADA este prezentat explicit n
seciunea 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 soluie
deschis i flexibil.

6.6 Cerinte Hardware ale sistemului SCADA-DTR
n cele ce urmeaz sunt descrise principalele echipamente hardware (i funciunile
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 Conine rack PC-urile (staii de lucru operator,
servere SCADA, server date) i echipamentele de
reelistic i alimentare utilizate pentru telecontrolul
staiilor.
1.2 Server SCADA
rack-abil 19
[Rack PC 19]
2 Servere industriale rack-abile 19 cu funcia de
servere de proces n conexiune redundant (master-
reset), pe care ruleaz exclusiv aplicaiile specifice
sistemului SCADA.
1.3 Server WEB
rack-abil 19
[Rack PC 19]
1 Server utilizat pentru difuzarea informaiilor n format
web accesibil tuturor utilizatorilor (autorizai 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
nentreruptibil
(UPS 3kVA)
2 Alimenteaz cu tensiune nentreruptibil server-ele
i echipamentele de retelistica considerate
consumatori vitali nentreruptibili. UPS-urile sunt
configurante n structur redundant pentru a se
asigura alimentarea continu n cazul apariiei
eventualelor indisponibiliti.
1.8 Consol
management +
Switch KVM.
1 Managementuladministrare/configurare/mentenan)
integrat al serverelor i staiilor de lucru rack-ate n
dulapurile de servere. Consola de management va
conine urmtoarele 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 Staie de lucru
operator tip
rack-PC 19
(HMI).
2 Staie de lucru operator (HMI) pe care ruleaz
interfaa grafic om-main (GUI) care asigur
interfaarea 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
instalaie de aer
condiionat
1 ansablu Numrul de echipamente din camera/locaia IT
fiind suficient de mare este necesar asigurarea
unui microclimat adecvat pentru o funcionare n
condiii optime. Acest lucru presupune echiparea
camerei sau locaiei 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 cmp 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 staiilor de lucru operator
(descrise la pct.1.4) pe care ruleaz interfaa
grafic om-main (GUI);
2.2 Set periferice:
Tastatura +
Mouse
2 2 seturi sunt alocate staiilor de lucru operator
(descrise la pct.1.4) pe care ruleaz interfaa
grafic om-main (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 staiilor de lucru
HMI din dulapurile unde sunt rack-ate unitile pn
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 fiecrui
eveniment (schimbare de stare) aprut n sistem.
2.5 Monitor LCD 1 Se foloseste un display LCD min.47 pentru
vizualizare tuturor schemelor sinoptice aferente
staiilor integrate n SCADA/DTR, cu posibilitatea de
expandare pe ntreg ecranul a oricrei scheme
sinoptice. Folosirea LCD se justific prin faptul c
schemele sinoptice sunt statice i dup o
funcionare 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 situaiilor neconforme care pot
apare n exploatarea sistemelor SCADA. Informaia
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 reea 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, comunicaii, networking
administration).
4.2 Trus portabil
de scule
electronist
1 Folosit de echipa tehnic (inginerii de sistem)
pentru lucrri minimale de mentenan / intervenii
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 creterea gradului de securitate, siguran n funcionare, ergonomie i
optimizare a spaiului s-a propus ca activele hardware de reelistic i servere s fie
rack-ate n camera IT iar camera de comand a turei operative s conin 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 poziionate pe pupitrul de teleconducere la cele 2 extremiti 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 (ieirile HDMI) pe un
sistem de afiaj bazat pe tehnologia cu cristale lichide (LCD). Dimensiunea
dispozitivului de afiaj va fi de 47 iar acesta va fi prevzut cu toat conectica
necesar i cu functionalitate specifica care s permit comutarea fr
intervenie extern (hands-off) de pe un HMI pe celalalt n caz de defect (HMI
failure point). Din motive de ergonomie i eficien operativ, poziionarea
echipamentului se va face pe tavan, frontal i centrat fa de pupitrul de operator
(6) Ansamblu mobilier pentru posturile de lucru operator, compus din
urmtoarele elemente:
birou sectorizat operator tip desk;
scaune operatori;
suport office dedicat imprimantei de evenimente.
Observaie
Dimensionarea pupitrului de operator i a ansamblului mobilier pentru arhiva de
documente va fi stabilit n faza de DdE (Dtalii de Execuie) 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 asigurrii 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 urmtoarele echipamente:
Priza pentru server-rack multipost care contine un numr suficient de posturi
de alimentare (prize) nct s fie capabil s alimenteze (din unitatea UPS 5kVA

54
Nr.1) toi consumatorii vitali neintreruptibili ai panoului (echipamentele de
reelistic 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 rezoluie 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 funcioneaz n conexiune Master-Reset (Hot-StandBy), avnd
aceeai 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.
Staie de lucru operator HMI 1 i HMI 2 pe care ruleaz simultan interfetele
grafice om-main i care permit interacionarea interactiv a operatorului cu
procesul telecontrolat;
Surse de alimentare nentreruptibil 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 informaiile de la router ul GSM/GPRS i se
va putea interfaa prin diverse protocoale de comunicaie industriale cu

55
echipamentele din dispecerul central n vederea diagnosticrii ulterioare i
transmiterii datelor ctre 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 lng 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 ctre 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, uor de utilizat. Software-ul de analiz trebuie s
poat fi utilizat pentru inginerie, ntreinere 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
locaia 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 stttoare (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 relaional, 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 reea distribuite, alarmele trebuie s fie vizualizate i identificate
de la orice statie de lucru i informaiile trebuie s fie distribuite tuturor
clienilor. Numele operatorului si nodul de identificare a alarmei trebuie sa
poata fi vazute in rezumatul alarmelor.
Sistemul trebuie s fie configurat astfel nct operatorul sa fie anuntat de
alarma, indiferent de fereastra in care se afla. Avertizarea trebuie s includ
opiunea 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.
Afiarea 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 limea. Ecranul de alarm trebuie s suporte pn la 8
combinatii de culori diferite, n funcie 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 cnd se produce o alarm nou. Ecranul de alarme trebuie s se
deplaseze la noua alarma n mod automat atunci cnd utilizatorul s-a mutat n
jos n list.
Ecranul alarmelor trebuie s poat recupera informaii 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 ctre un operator nu trebuie s afecteze ecranele
altor operatori.
Trebuie s fie posibil re-afiarea 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 seciunii 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, recunoaterea alarmelor i
schimbarea de valori limita.
Operatorul va putea efectua toate funciile 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 cutare pentru a gsi cu uurin 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 tendinele 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 nct s poat fi ncorporate n SCADA HMI sau orice alt depozit
ActiveX. Clientul de Query este folosit pentru a face interogri 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 fr 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 achiziionarea de date la vitez mare i
compresia eficient a acestora.
Fiecare valoare discreta stocat, scrisa in istoric trebuie s ocupe un spaiu de
aproximativ 7 octei.
Fiecare valoare analogic stocata n modul Delta sau Ciclic , scrisa in istoric
trebuie s ocupe un spaiu de aproximativ 10 bytes.
Istoricul trebuie s poat stoca iruri de text sau date, fiecare ir de text de
pn 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. Definiiile 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 uor de citit.

70
Datele ce vor fi introduse in istoric, vor fi configurate din acelai 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 rezoluiile de pn la 5 milisecunde pentru
tagnames configurare pentru stocare delta.
Istoricul trebuie s poat obine date n mod automat i manual. Achiziia de
date automata trebuie s fie realizata prin mijloace de transport de date
standard. Trebuie s suporte achiziionarea 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 rezoluie 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, staii pompare ape,
staii pompare ape uzate, camere deversoare, hidrofoare, nivele rezervoare.
Funcionarea punctelor care au doar funcia de transmitere date se realizeaz automat,
autonom, fr supraveghere permanent. Toate funciile punctelor acestora se vor
realiza local, la acest nivel, i vor fi dependente de starea activ de funcionare a
sistemului dispecer a sistemului de comunicaie. Periodic (sptmnal) se vor realiza
inspecii n cadrul programului de exploatare i ntreinere.
Centrul dispecer va achiziiona datele n timp real, n scopul observrii i monitorizrii
funcionrii sistemului. Sistemul de automatizare va fi monitorizat, iar n cazul
evenimentelor neplanificate, se va activa o alarm cu prioritate n funcie de tipul
evenimentului.

71
Centrul dispecer poate, la cerere, activa/porni respectiv dezactiva/opri activitile 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 funciona permanent, principalele funcii fiind:
monitorizarea performanelor sistemelor de automatizare, a locaiilor
monitorizate;
optimizarea proceselor specifice punctelor monitorizate;
diagnoza i urmrirea entitilor sistemelor de automatizare ale punctelor
monitorizate;
managementul alarmelor i rapoartelor, n vederea iniierii unor aciuni corective
sau adoptrii 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 instalaia
monitorizat i de tipul datelor: schemele sinoptice, curbele grafice de evoluie, tabele
de date, hri specifice. Operatorul va avea drepturi pentru efectuarea unor comenzi de,
dup o schem de acces configurabil. Operatorul va urmri alarmele care apar n
sistem, pe toata perioada pe timp .
Va fi posibil definirea datelor care se achiziioneaz n mod constant, n timp real.
Definirea datelor se va realiza mpreun cu Beneficiarul. Aceste faciliti sunt aplicate
punctelor de monitorizare unde se vor efectua comenzi de la distan asupra

72
pornirii/opririi pompelor din staiile de pompare n funcie de presiunea reelei 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 comunicaie trebuie sa permita monitorizarea i controlul de la
distan pentru un numr minim de puncte din aplicaia beneficiarului, cel puin
500 plus o rezerv de 25%. Dac transferul de date se face, pe unele (sau pe
toate) segmente, prin reele publice (spre exemplu prin reeaua Internet) atunci
respectivele segmente trebuie securizate corespunztor. 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 acionri 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 soluia oferit.
Sa puna la dispozitie o baz de cunotine online pentru operarea sistemului
instalat, coninnd urmtoarele domenii: monitorizarea datelor, acionare 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 urmtoarele caracteristici: o fereastr SQL pentru a
construi i executa scripturi, o fereastr pentru a salva i afia scripturi SQL, o

73
fereastr grafic pentru a aduga i terge urmtoarele obiecte ale bazei de date
i pentru a le modifica proprietile: tabel, index, vedere, constrngere,
declansator, procedur stocat, o interfa pentru a efectua sarcini legate de
urmtoarele funcii ale bazei de date: stocare, backup, recuperare. Baza de date
trebuie s permita restricionarea 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 parial a bazei de date;Trebuie s ofere o
facilitate pentru restaurarea totala i/sau parial 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 fiiere pe disc simultan n timpul unei
operaii de salvare, in vederea cresterii performantei; Trebuie s permita
constrngeri de tip cheie primar si cheie straina; Trebuie s ofere abilitatea de
impunere a constrngerilor pe coloane asupra tipurilor i valorilor datelor;
Trebuie s ofere o facilitate de catalog (sau dicionar de date) care este
modificat automat de fiecare dat cnd instruciuni 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 adugate/eliminate din cluster n mod
dinamic, fr a fi necesar ntreruperea bazei de date; trebuie sa permita
executarea comenzilor SELECT, INSERT, UPDATE si DELETE de tip multi-
tabel, astfel nct s poat fi inserate linii dintr-o singur instruciune n mai
multe tabele; Trebuie s suporte indeci 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 evidenia acele
valori care sunt n afara limitelor, pentru a putea fi marcate ca nevalide
evitnd astfel procesarea lor de ctre sistemele expert. Aplicarea validrii datelor
permite utilizatorilor s identifice valori obinute in teren care sunt n afara
limitelor sau foarte diferite de tendinele prevzute, putand astfel sa evite
utilizarea acestora n sistemele expert tocmai pentru a preveni distorsionarea
procesului de analiz a datelor. Aplicaia 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. Soluia 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 ctre un
operator remote pentru oferirea de servicii de mentenan, back-up i
eventual control la cerere pentru evitarea deplasrii echipei tehnice la
dispecerele locale sau la dispecerul central .
o Serviciile oferite vor constitui un pachet modularizat care s permit
adaptarea stricta la opiunile 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 facilitile 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 puin a urmtoarelor condiii:
Suport pentru standardul OPC i protocolul de comunicaie standard folosit;
Suport pentru principalii fabricani de PLC-uri; (de ex. Omron, Allen Bradley,
Motorola, Siemens, etc) ;
Realizarea gestiunii comunicaiilor cu echipamentele externe (RTU, PLC,
Data Logger, etc.);
Posibilitatea de a lucra ca OPC Server pentru comunicaiile 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 informaii full-duplex.

82
6.10 Conceptul sincronizarii de timp (stabilirea timpului de referinta)
Ansablu sincronizare de timp va fi folosit pentru a
asigura reacia potrivit a sistemului i pentru a face
posibil analiza pertinent a evenimentelor, n mod
special n cazul defectelor, unde sunt necesare reacii
rapide i toate elementele trebuie sa funcioneze pe
acelai timp pentru a exista o corelare. Sistemul de
sincronizare de timp furnizeaz referina 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. Referina 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 recepia 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 muli furnizori de
echipamente;
s poat conlucra cu alte aplicaii realizate pe sisteme deschise;
s prezinte un stil consistent de interaciune cu utilizatorul;
Cea mai mare deschidere pe care conceptul open-system o aduce n proiectarea
sistemelor SCADA este posibilitatea de a distribui funciuni n diferite noduri de
prelucrare. Fiecare nod funcional 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; totui prin hardware va trebui sa fie
asigurat o independen ct mai mare deoarece, pe aceast cale, se poate obine
posibilitatea de extindere ulterioar sau de nlocuire. De asemenea, independena
nodurilor de prelucrare servete la minimizarea mesajelor i ncrcrii reelei de
transmisie de date. Redundana n cadrul nodului mrete gradul de disponibilitate al
acestuia i micoreaz riscul pierderii lui i a distribuirii funciunilor 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 folosete ca suport de
comunicaie reelele locale de date (LAN Local Area Network) i cele la distan
(WAN Wide Area Network) realizate pe baza unor proceduri i interfee 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.

87

88
7 SECURITATEA INFORMATIEI
7.1 Cerinte de Securitate a Informatiei
Sigurana SCADA se va baza pe folosirea Codurilor de Securitate i a Conturilor de
Utilizator.
7.1.1 CODURI DE SECURITATE
Alocarea autorizaiilor de acces este controlat de ctre funcia de Administrator, unde
autorizaiile sunt acordate n conformitate cu nevoile utilizatoriilor de sistem la
accesarea diferitelor nivele de operare. Cnd un utilizator se va autentifica n sistem,
accesul i va fi permis doar pentru acele funcii autorizate i configurate de ctre
administratorul de sistem toate celelalte fiindui interzise.
7.1.2 GRUPURI DE UTILIZATORI
Grupurile de utilizatori opereaz n conjuncie cu autorizarea seciunii precedente.
Fiecare utilizator va avea identitate proprie caracterizat prin nume de utilizator
(user_name) i o parol (password). Fiecare utilizator va fi identificat ca aparinnd unui
grup artat mai jos i va avea definit explicit autorizaia asignat.
Va fi posibil totodata si repartizarea mai multor grupe cu diferite coduri de acces, de
ex.: grup de supervizare. Urmtoarele conturi vor fi orientative pentru accesul permis
fiecrui grup de acces.
7.1.3 OPERATOR
Grupul utilizatorilor de tip Operator va fi capabil s vizualizeze toate ecranele aplicaiei
i s navigheze n sistem. n plus, va fi posibil (n funcie de decizia Beneficiarului i
politica de IT a Companiei) s aduc modificri minore punctelor de setare i prilor de
control din staie.
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
configuraii complexe, setri i parametri n sistem, de ex.: ecrane, logici n PLC i n
software-ul de aplicaie, management al bazei de date, articole, alarme, direcii etc.

89
7.1.5 ADMINISTRATOR
Administratorul de sistem va avea acces necondiionat la toate zonele sistemului.
Aceasta include abilitatea de a manageria aplicaiile software i de setri i configurri
n sistemul de operare. Orice nou cont de utilizator sau modificri ale codurilor de acces
deja existente, vor fi configurate doar de ctre Administrator.
7.1.6 CONSIDERAII GENERALE DE SECURITATE
Toate instalaiile trebuie s intre n modul de operare (run mode) atunci cnd sistemul
este pornit. Bara de sarcini va fi auto-ascuns n fiierele de setare ale sistemului de
operare.
Abilitatea de a comuta aplicaii, 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 fiierul
proprietile 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 pregtirea 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 CERINE PRIVIND COLARIZAREA PERSONALULUI DE EXPLOATARE
Prin personal de exploatare se nelege personalul TESA care manageriaz activitatea
de exploatare a staiilor aferente Companiei. Personalul de exploatare cuprinde efii
CED i adjuncii CED sau personal care programeaz activitatea de exploatare.
Activitile de colarizare ale personalului de exploatare au ca scop mbuntairea
capabilitii personalului Beneficiarului de a permite o urmarire mai corect a activitii
de exploatare bazat pe informaia (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
funciuni. Totodat se vor prezenta Beneficiarului din domeniul de exploatare toate
posibilitile oferite de sistem n ceea ce privete modul de culegere a informaiilor
necesare procesului de exploatare (rapoarte, analiz evenimente, etc.).
7.6.2 CERINE PRIVIND COLARIZAREA PERSONALULUI TESA DEDICAT INFORMATICII DE
PROCES (IP)
Prin personal de informatic de proces se nelege 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. Activitile de colarizare ale
personalului de informatic de proces au ca scop mbuntairea capabilitii
personalului Beneficiarului n vederea administrrii (operaiuni de: parametrizare,
setare, configurare) si ntretinerii sistemelor informatice de proces i reelistic 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 dispoziia autoritii contractante o
aplicaie software de gestionare a incidentelor, inregistrat la ORDA, cu urmtoarele
caracteristici:
inregistrarea solicitrilor de suport i alocarea unui identificator unic fiecrei
solicitri;
posibilitatea de definire a unor categorii de apeluri de asisten;
posibilitatea de definire i de ncadrare a solicitrilor n categorii: defect, eroare,
solicitare de informaii, cerere de schimbare.
posibilitatea de inregistrare a datelor de identificare ale apelantului - include
atribuirea incidentului unei persoane care raporteaz n aplicaia software
(inginerul de suport al Call Center), persoana care soluioneaz incidentul (de la
orice nivel), persoana care a raportat un incident. Toate datele prezente aici
includ att date personale, ct i date de contact, activitate curent etc., aceast
aplicaie putnd fi personalizat s primeasc detalii diferite pentru aceste
puncte de reper n mod diferit i definit n totalitate de ctre un administrator de
aplicaie.
posibilitatea de nregistrare a descrierii problemei i de ataare a unor
documente suplimentare. Aplicaia software s permit ataarea oricror tipuri
de fiiere (doc, xls, jpg, xml etc.) precum i postarea a unor capturi de ecran din
aplicaii.
posibilitatea de alocare a unui criteriu de urgen. Aplicaia software s permit
clasificarea incidentelor n funcie de tipul stabilit n SLA, putnd s emit
notificri pe mail privind alocarea incidentelor ctre persoanele implicate n
incident.
posibilitatea de alocare automat a unor coduri de incident care s indice cauza
probabil a incidentului. Aplicaia software s aloce coduri unice fiecrui
incident. Aplicaia software s permit de asemenea i gruparea pe module a
incidentelor.
posibilitatea de gestionare a informaiilor despre personalul de suport cruia i se
pot aloca spre rezolvare incidentele. Aplicaia software conine 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 solicitri de asisten.
posibilitatea de definire a criteriilor de calitate i performan (SLA) pentru
rezolvarea diferitelor categorii de solicitri de asisten.
posibilitatea de atenionare automat n momentul depirii unor praguri
temporale de rezolvare a diferitelor categorii de solicitri de asisten.
posibilitatea de definire a unor fluxuri de evoluie a solicitrilor de suport, n
cazul n care ele trec prin mai multe nivele de competen pn n momentul
finalizrii.
posibilitatea de escaladare a cererilor de suport.
posibilitatea de nregistrare a datelor de contact pentru responsabilii pentru
activitile 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 funcia care a cauzat incidentul,
numrul 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 condiionat n niciun fel de ctre 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 soluie 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 specificaiile 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 cerinele 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 ctre
furnizor in baza propriei metodologii de organizare propusa in cadrul ofertei tehnice.
Furnizorul va trebui s ntocmeasc i sa depun documentatiile att n format
electronic ct i pe hrtie n limba romn. Se vor depune trei exemplare pe hartie + 1
CD din fiecare raport.
Rapoartele menionate n continuare vor acoperi toate activitile Proiectului i vor
puncta toate rezultatele obinute de ctre 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 lucrrilor cuprinse n cele 7 contracte de lucrri
aflate in derulare (vezi tabelul urmator) este Consultantul pentru Supervizare desemnat
in cadrul Contractului de Servicii Asisten Tehnic pentru Supervizarea Lucrrilor
Extinderea i reabilitarea sistemelor de ap si ap uzat n Judeul 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 observaiile 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 primete nici
aprobarea i nici observaii 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 urmtoarelor 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 ntrziere sau discontinuitate n procesul decizional, evitnd diminuarea
responsabilitii Prestatorului.
Prin natura lor, serviciile care fac obiectul prezentului contract implic o
cooperare direct ntre Furnizor i personalul desemnat de ctre 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
activitile 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 activitile de zi cu zi mpreun cu experii din
echipa Furnizorului.

115
10 LISTA STANDARDELOR
SR CEI Seria 60050 Vocabular Electrotehnic International;
SR CEI Seria 60300 Managementul siguranei n functionare;
SR HD Seria 60364 Instalaii 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 calitaii. Cerine.
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 conformitaii 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

117

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 Intervenie

GPRS General Packet Radio System
[Serviciul de transfer radio bazat pe pachete de date]

GPS Global Positioning System
[Sistem de radio-navigaie global]

GUI Graphycal User Interface
[Interfa Grafic cu utilizatorul]

HMI Human Machine Interface
[Interfa grafic om-main]

IT & C Information Technology and Communication
[Tehnologia informaiei i telecomunicaii]

ISDN Integrated System for Digital Network
[Reele digitale/numerice cu integrarea serviciilor RNIS]

119

ISO International Standard Organization

LAN Local Area Network
[Reea 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 achiziie i proces]

SCADA Supervisory Control And Data Aquisition
[Sisteme de supervizare, control i achiziie 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 [Reea de date cu acoperire mare/extins]

Digitally signed by MIHAI-DAN
NEDELEA
Date: 2012.05.11 13:24:52 +03:00
Reason:

Caiet de Sarcini

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Caiet de Sarcini

Încărcat de

Drepturi de autor:

Formate disponibile

1

S-ar putea să vă placă și