IES

1. Osnovne komponente elektroenergetskog sistema i njihovo modeliranje u CIM-u

EES - sistem u okviru kog se izvode sve el.eng transformacije: el.eng se proizvodi, prenosi, distribuira i trosi.
Nacela : Pouzdanost, sigurnost, ekonomicnost.
Podsistemi: Proizvodnja, Prenos, Distribucija, Neposredna potrosnja.

El.eng se ne moze skladistiti u velikim kolicinama - proizvodnja priblizno jednaka potrosnji(manji deo se moze
skladistiti u baterijama). Glavni znak disbalanasa - promena frekvencije

Prenosne i distributivne mreze se sastoje od cvorova i grana. Osnovna uloga cvorova je:
- Spajanje vodova istog naponskog nivoa
- Povezivanje mreza razlicitih naponskih nivoa
- Prikljucak izvora(elektrane) I potrosaca na mrezu

Visi napon = manji gubici!!!

Kvalitet podrazumeva napon, frekvenciju i kontinualno napajanje!

U Prenosnim mrezama na duzim deonicama dolazi do pada napona, zato se na svakih x kilometara deonice postavlja
regulacioni transformator ciji je zadatak da odrzi naponski nivo.

Klasicni izvori energije su: drvo, ugalj, nafta, prirodni gas, vodena energija, atomska ili nuklearna energija.
Alternativni izvori energije su: energija vetra, geotermalna, energija biomase, energija plime i oseke.
Neobnovljivi izvori energije su: Ugalj, Nafta, Gas, Nuklearna energija.
Obnovljivi izvori energije su: Energija vetra, Energija sunca, Energija biomase, Energija vode.

U cvorovima se grade razvodna postrojenja:

- na otvorenom - za velike napone - veca indukcija
- u zatvorenom - za nize napone

Vrste Mreza:
- Upetljane mreze - svaki cvor se napaja sa vise izvora
- Radijalne mreze(stablo) - svaki cvor se napaja samo sa jednog izvora

Prenosne mreze u upetljane jer kvar u prenosnoj mrezi ostavlja bez napona veci broj potrosaca nego kvar u
distributivnoj mrezi koja je radijalna!

Potrosaci mogu biti:

- Rezistivni - napon i struja u fazi
- Kapacitivni - struja kasni za naponom
- Induktivni - struja prednjaci za naponom
Snaga:
- Aktivna P[W]
-Reaktivna Q[VAr] - nastaje zbog fazne razlike izmedju napona i struje i osciluje kroz mrezu.
-Prividna S[VA] - kombinacija P i Q

DER - Distribued Energy Resource

SmartGrid - EES koji koristi savremene tehnologije kako bi dosao do podataka o potrosnji i prozvodnji i kako bi
reagovao na adekvatan nacin!
Elementi EES:

1. Generatori - elektricne masine koje pretvaraju mehanicku energiju u elektricnu

- Napon: 15-10kV
-Podaci: Snaga(Normalna,Max,Min), Nom.Napon, Rezistanasa, Rekatansa
- Wires::Plant, Wiers::EnergySource, Wires:: SyncronysMachine

2. El. Mreze(prenos i distribucija) - Wires::

- Transformator - el.masina za transformaciju napona uz postovanje principa prenesene snage
- Wires::PowerTransformer, Wires:: TransformerWinding
- Snaga na primaru = Snaga na sekindaru + gubici ,uz obrnuto porporcijani napon i struju
- Podaci: Snaga, Prenosni odnos, Nom.Napon primara i sekundara, satni broj..
- Vrste: Blok(SN/VN), Prenosni(VN/VN), Distributivni i Industijski(VN/SN), Potrosacki(SN/NN)
- Strujni/Naponski merni TF - smanjuju radne napone/struje na vrednosti koje se mogu
meriti i u blizni kojih mogu boraviti ljudi.
- Regulacioni TF - Regulacija se vrsi variranjem prenosnog odnosa TF.
-Wires::TapChanger - lowstep, highstep, initialDelay, neutralStep
-Dis. Mreze - Odrzavanje napona , napajanje iz jedne tacke(regulacija se vrsi na VN strani)
-Pre.Mreze - Smanjenje gubitaka, Odrzavanje napona, Stabilnost Pogona
-Vrste:
- Poprecna - na nekom delu deonice se odrzava napon
- Vertikalna - utice na vise fidera
-Vodovi - elementi namenjeni za prenos I dristribuciju el.eng
-Wires::Line, Wires::Conductor, Wires::ACLineSegment, Wires:: DCLineSegment
- Vrste: Nadzemni(provodnici) , Podzemni(kablovi)
- Podaci: Napon, Struja, Pogonski parametri(reaktansa, rezistansa, susceptansa,
konduktansa), Duzina.
-Sabirnice - Omogucavaju medjusobno povezivanje razlicitih elemenata EES
- Wires:: BusBarSegment
- Spojni provodnici povezuju gen. i tf. ili medjusobno.
- Sabirnice i spojni provodnici mogu biti kruti ili u vidu uzadi.
-Spojnice - povezivanje dva el.voda.
- Wires::Clamp
-Rasklopna oprema - Wires::Switch
- Vidno I sigurno odvaja deo postrojenja koji je pod naponom od dela koji nije pod naponom. To su
elementi cijiom se manipulacijom ostvaruje zelejna topologija mreze. Svaka manipulacija ima
odredjenu cenu!
- Rastavljacka opreama
* Rastavljaci(disconnectors) - manipulacija u beznaponskom stanju !
- Wires::Disconnector, Wires::GroundedDisconnector
* Rastavljaci snage - prekidaju struje do svoje nominalne struje
- Wires:: LoadBreakSwitch
- Prekidacka oprema
* Automacki prekidaci - manipulacija u svim situacijama. Vrlo brzo prekidaju struju kratkog spoja.
Poseduju komoru za gasenje luka(SF6, Uljni, prenumatski, vakumski) - Wires::Breaker
-Osiguraci - Stitle elemente iza sebe od kratkog spoja I preopterecenja, pregorevanjem prekidaju
strujno kolo - Wires::Fuse

3. Otoke
- Kondenzatori - kompenzacija rekativnih snaga
- Prigusnice - za ogranicenje struje kratkog spoja, uzemlj. nulte tacke TF, regulaciju reak. snaga
- Potrosaci - individualni i idustrijski
NN Mreza - stambene ili poslovne zgrade i drugi objekti prikljuceni na NN mrezu.
Elementi:
- Prikljucak - skup vodova I opreme koji povezuje el.instalacije sa NN mrezom.
- Kucni, Spolji, Unutrasnji, Nadzemni, Podzemni
- Merno-rzavodni orman - rasklopni aparati I uredjaji za merenje i zastitu
- Razvodna tabla

CIM praktično predstavlja skup standarda koji su namenjeni integraciji sistema kao i razmeni informacija
između različitih sistema. Razmena informacija je bazirana na tom zajedničkom modelu. CIM sadrži definicije I opise
entiteta iz realnog sveta(za EE sistem entiteti su transformatori, generatori itd.). Ti entiteti sa svojim atributima, i
međusobnim relacijama su definisani u CIM-u.
Razmena podataka preko CIM-a nam je bitna i zbog semantike podataka. Preko XSD-a definisemo poruke, preko
RDFS-a model.
CIM nije vezan za neku pojedinu aplikaciju ili neku specificnu implementaciju. On omogucava pristup podacima na
jedan standardan nacin. Održava se u Enterprise Architect-u.
Jedan od osnovnih ciljeva CIM-a je da nam obezbedi razmenu podataka nezavisnu od platforme. Da bi se to
postiglo CIM može da bude namapiran na različite tehnologije poput RDF-a, XML, OWL…

Paketi:
-Wires Paket - osnovne komponente EES-a
- Lines - infr. Za prenos i distribuciju el.eng
- Switch - modeluje prekidacku I rasklopnu opremu
- Transformers - modeluje transformatore
- Core Paket - def. Osnovne CIM klase
-IdentifyObject - Koristi se za jedinstvenu identifikaciju objekata u EES (mRID, name)
- PowerSystemResource - za grupisanje elemenata
- Equipment - Fizicki uredjaji (el I meh)
- EquipmentContainer - konekcija fizickih uredjaja
-Connectivity Node - fizicka veza elemenata
-Teminal
- Topology paket - modeluje topoligiju logicki opis veza izmedju uredjaja . Prdstavlja skup konektivnih
cvorova koji su spojeni u tekucem stanju mreze.
- Normalno uklopno stanje - stanje mreze u kom se sva oprema nalazi u predef. stanju
- Trenutno stanje mreze - definise topologiju ,moze se razlikovati od NUS
- Izgradjenost(konektivnost) + SCADA merenja = Topologija

-LoadModel - za modelovanje potrosaca

-Outage - za rad sa otkazima
-Meas - merenja
-SCADA
-Equivalents
-Domain
-Protection
2. Podsistemi elektroenergetskog sistema i standardi za modeliranje podataka.

EES - sistem u okviru kog se izvode sve el.eng transformacije: el.eng se proizvodi, prenosi, distribuira i trosi.
Nacela : Pouzdanost, sigurnost, ekonomicnost.
Podsistemi: Proizvodnja, Prenos, Distribucija, Neposredna potrosnja.

El.eng se ne moze skladistiti u velikim kolicinama - proizvodnja priblizno jednaka potrosnji(manji deo se moze
skladistiti u baterijama). Glavni znak disbalanasa - promena frekvencije.

Proizvodnja - transformacija razlicitih oblika energije u elektricnu. Naponi generatora su relativno niski (15-20kV
- visok napon - manji gubici). Na prenosnu mrezu se prikljucuje preko blok transformatora koji podizu napon.

Prenos - prenosnom mrezom se el.eng prenosi od proizvodnje do vecih potrosackih podrucija(prozivodimo tamo gde
je jefino, prenosimo tamo gde je potrebno). U Srbiji naponski nivo prenosne mreze je 220kV i 400kV, u svetu ide i do
750kV - Prenosne mreze u upetljane jer kvar u prenosnoj mrezi ostavlja bez napona veci broj potrosaca nego kvar u
distributivnoj mrezi koja je radijalna! U Prenosnim mrezama na duzim deonicama dolazi do pada napona, zato se na
svakih x kilometara deonice postavlja regulacioni transformator ciji je zadatak da odrzi naponski nivo.

Distribucija - povezuje prenos(proizvodnu) i neposrednu potrosnju. Napon distributivnne mreze je 10kV, 20kV,
35kV. Distributivna mreza je radijlna i zasniva se na konceptu fidera. Na prenosnu mrezu se povezuje preko
Distributivnih transformatora (VN/SN).

Neposredna Potrosnja - skup individualnih i indstrijskih potrosaca koji se grupisu u sektore i kategorije
-Sektori: Domacinstva, Komercijalna potrosnja, Industrija
-Industrijski potrošači mogu da se direktno kače na srednje naponski nivo.
-Napon između faze i 0: 230V
-Napon između dve faze: 400V
Potrosaci mogu biti:
- Rezistivni - napon i struja u fazi
- Kapacitivni - struja kasni za naponom
- Induktivni - struja prednjaci za naponom
Snaga:
- Aktivna P[W]
-Reaktivna Q[VAr] - nastaje zbog fazne razlike izmedju napona i struje i osciluje kroz mrezu.
-Prividna S[VA] - kombinacija P i Q

DER - Distribued Energy Resource

Električna energija se ne može skladištiti u velikom obimu – danas postoje razni oblici baterija koji mogu skladištiti
različite količine energije u zavisnosti od kapaciteta. Električni automobili se takođe služe konceptom skladištenja
el.energije.
Zbir aktuelne potrošnje, odgovarajućeg izvoza i električnih gubitaka bi trebao da bude približno isti da bi sistem bio
stabilan. Stabilnost sistema se vidi preko frenkfencije(svi generatori treba da rade u istom taktu i da budu u istoj fazi).
Ako bi 2 generatora radila u kontra fazi 1 bi bio proizvođač, drugi potrošač. Frenkfencija u Americi (60Hz), kod
nas(50Hz).

Standardi su CIM I Multispeak.

CIM praktično predstavlja skup standarda koji su namenjeni integraciji sistema kao i razmeni informacija
između različitih sistema. Razmena informacija je bazirana na tom zajedničkom modelu. CIM sadrži definicije I opise
entiteta iz realnog sveta(za EE sistem entiteti su transformatori, generatori itd.). Ti entiteti sa svojim atributima, i
međusobnim relacijama su definisani u CIM-u.
Razmena podataka preko CIM-a nam je bitna i zbog semantike podataka. Preko XSD-a definisemo poruke, preko
RDFS-a model.
CIM nije vezan za neku pojedinu aplikaciju ili neku specificnu implementaciju. CIM je baziran na UML-u. Održava se u
Enterprise Architect-u.
Jedan od osnovnih ciljeva CIM-a je da nam obezbedi razmenu podataka nezavisnu od platforme. Da bi se to
postiglo CIM može da bude namapiran na različite tehnologije poput RDF-a, XML, OWL…
Multispeak- za americka preduzeca - koriste web service

IEC 61970 – za prenosne mreze(EMS). IEC61970-301 standardom je definisan CIM.

-Core - osnovne klase, oslanja se na Domain paket(osnovni podaci - Voltage…)
-Wires - izgradjenost mreze(oprema)
-Meas - merenja (oslanja se na SCADA i ContronArea pakete)
-Topology - zavisi od Wires(izgradjenost) i SCADA(SV-trenutno stanje)
-Equivalent - ekvivalenti iz drugih sistema
IEC 61968 – prosiren IEC61970 sa distribucijom.\
- Locations, Operations, Assets, Planning, Work, Customers, Meteering, ERP,GML, Common(zajednicki)
IEC 62325 – trziste el.eng (EU i NA) - razmena podatak izmedju operatera i trzista(Operations+Managment)
-EU:
-Day Ahead Markets - sledeci dan
-Intra-Day - za tekuci dan
-Ballancing - prodaja I kupovina ee
-Saradnja sa ENTSO-E
-NA:
-Day Ahead -sledeci dan sa ekonom. ogranicenjima
-Hour Ahead - sledeci sat
- RT Market - sa sigurnosnim ogranicenjima
- Saradnja sa ISO/RTD

3. Razlike pri modeliranju evropskih i američkih distributivnih mreža.

Americka mreza
- Nebalansirana mreze - do potrosackog podrucija se stize sa 3 faze i nulom, nako cega se svaka faza odvaja za
jedan deo potrosackog podrucija - monofazno napajanje NN potrosaca.
- Osnovni podaci:
- Frekvencija: 60 Hz,
- SN : 12-13 kV,
- NN: 120/240 V
- Distributivni transformatori su monofazni i napajaju 5-6 potrosaca(50kVA). Ako se zahteva trofazno napajanje
to se onda radi sa 2 transformatora. Postoje i slucajevi gde do potrosaca stizu dve faze ugaono pomerene za 180
stepeni nastale preko dva namotaja na sekundaru transformatora.
- Kvar u distributivnoj mrezi ostavlja bez el.eng manji broj potrosaca
- Teza je kradja el.eng jer se sa jednom fazom napaja 5-6 potrosaca

Evropska mreza
- Balansirana mreze - do potrosackog podrucija se stize sa 3 faze, i do svakog potrosaca dolaze 3 faze i nula-
trofazno napajanje
- Osnovni podaci:
- Frekvencija: 50 Hz,
- SN : 10,20 kV,
- NN: 230/400 V
- Distributivni transformatori su trofazni i napajaju oko 100 potrosaca(300kVA,skuplji, pouzdaniji).
- Do NN TF-e se dolazi sa 3 faze, u TF-i se vrsi uzemljivanje srednje tacke transformatora - za nulti provodnik.
- Kvar u distributivnoj mrezi ostavlja bez el.eng veci broj potrosaca , ali su Dis.TF pouzdanije
- Laksa je kradja el.eng jer se sa jednom TF napaja 100+ potrosaca.

Evorpski TF ime srednje naponske panele, prekidačku I zaštitnu opremu I uvodnicu u transformator. Sam
transformator ima odgovarajuće uljno hlađenje(koje je potrebno promeniti na određeni period). Transformator
konvertuje srednje naponski nivo na nisko naponski nivo. Sve se nalazi u nekom limenom kućištu. Evropski
transformator je skuplji od američkog(EU - 300kVA , USA - 50kVA).
4. Tehnicka i upravljacka kompleksnost softvera.

Kompleksnost softvera:
- Tehnicka
- Upravljacka - sa stanovista upravljanja projektom.

U sredini se nalazi neki prosečan projekat koji radi 5-10 ljudi, traje 10-15 meseci, ima 3-5 eksternih interfejsa i
korisnik kada je naručivao softver nije bio siguran šta hoće.

Visoka Tehnicka kompleksnost je ono sto je u real time, distribuiranim sistemima I sistemima otpornim
na otkaze, to su sistemi koji se prvi put prave, reinzenjering se koristi(na osnovu iskustava) i oni imaju visoke
performanse.

Niska Tehnicka kopleksnost - aplikacije napisale 4GL jezicima , zasnovane na komponentama uz upotrebu
reinzenjeringa aplikacije.

Visoka Upravljacka kompleksnost - veci sistemi, vecih dimenzija, prave se pod ugovorom, imaju mnogo,
stakeholder-a,

Niskka Upravljacka kompleksnost - sistemi manjih dimenzija, neformalni, imaju jednog stakeholder-a, obicni
proizvodi, jedna aplikacija koja nesto radi.

Visoka Upravljacka, Visoka Tehnicka kompleksnost - Sistemi za kontrolu letenja, Sistemi raketne odbrane
Visoka Upravljacka, Niska Tehnicka kompleksnost - Sistem za proracun plata u velikom preduzecu
Niska Upravljacka, Niska Tehnicka kompleksnost - Informacioni sistem nabavke, Excel
Niska Upravljacka, Visoka Tehnicka kompleksnost- Voznja Automobila(Automobil) od strane coveka, CASE Tool
Tehnicki faktori koji uticu na slozenost: distribuiranost, vreme odziva, efikasnost, kompleksnost, upotrebljivost koda,
lakoca instalacije, lakoca upotrebe, prenosivost na druge platforme, odrzavanje, paralelizam/konkurentnost,
sigurnost i bezbednost, pristupacnost, obuka.

Kompleksnost je nas neptijatelj i cilj je unistiti je.

Reinzenjering predstavlja radikalan redizajn zbog dramaticnog poboljsanja. Radikalni redizajn pocinje dizaj iz pocekta
tj. ne menja vec postojeci nacin rada.
5. Prikaz arhitekture sistema UML-om i njihova primena u IES.

Objektni jezik za modelovanje (Unified Modeling Language - UML) - skup grafičkih notacija zasnovanih na
jedinstvenom metamodelu.
UML se koristi za: vizuelizaciju, specifikovanje, konstruisanje i dokumentovanje, razumevanje, komunikaciju.

Benefiti: open standard, podržava celokupan razvoj softvera , podržava različite vrste aplikacija ,
baziran na iskustvu i potrebama korisničke zajednice, podržano od starne raznih alata

Blokovi za izgradnju UML-a:

Stvari (things)
- Strukturne - klasa, interfejs, kolaboracija, use-case funkcije, aktivna klasa, komponenta, cvor
- Statusna - poruka, stanje
- Grupisuce - paket
-Anotacijske - komentar
Relacije
-Zavisnost
-Asocijacija
-Generalizacija
-Realizacija
Dijagrami

Arhitektualni pogled je apstrakcija sistema, koja pokriva odredjene elemente,i izostavlja one koji nisu relevantni za
odgovarajuću perspektivu.
Arhitektura sistema je dobra kad je:
1) Rezilientna – prilagodljiva samoj šemi, lako promenljiva
2) Jednostavna – sagledala je sve aspekte, a prihvatljiva je
3) Pristupačna i razumljiva
4) Jasno razloži na šta se odnosi koji deo odnosi ( npr veza između prenosa i distribucije, gde je spojna
tačka HV/MV stanica)
5) Balansiran nivo odgovornosti
6) U skladu sa ekonomskim i tehnoloskim ograničenjima

Razliciti pogledai na argitekturu sistema:

- Logicki pogled (krajnji korisnici, funkcionalnosti)
- Implementacioni pogled(programski)
- Porcesni pogled(performanse, skalabilnost)
- Deployment pogled (topologija, kominikacije)

Ne zahtevaju svi sistemi sve poglede!

6. Tipovi dijagrama definisanih UML-om i njihova primena u IES.

Model predstavlja dovoljno dobar opis sistema iz odgovarajuće perspektive.

Podela UML dijagrama:

- Strukturni dijagrami (dijagram klasa, dijagram objekata, dijagram komponenti, dijagram deployment-a,
dijagram paketa, dijagram slozene strukture)
- Dijagrami ponasanja (dijagram aktivnosti, dijagram slučajeva upotrebe, dijagram stanja, dijagram sekvence,
dijagram komunikacije, dijagram pregleda interakcija, vremenski dijagram)

Dijagram Klasa - opisuje tipove objekata u sistemu i veze između njih - opisuje strukturu sistema i predstavlja graf
povezan relacijama. Specificira logičke i statičke aspekte modela.

Dijagram Objekata - Presek objekata sistema u nekom trenutku (uglavnom instance, ne klase) Koristi se za
prikazivanje primera povezanih objekata

Dijagram komponenti - opisuje komponente sistema I njihove relacije potrebne za realizaciju neke funkcionalnosti.
Komponente mogu biti biblioteke, paketi, fajlovi.

Dijagram deployment-a - Otkrivaju fizičku organizaju sistema i delove aplikacije koji se izvršavaju na određenim
delovima računarskog sistema. Komunikacione putanje između čvorova pokazuju da se između delova sistema
odvija komunikacija. Pogodni su za uvid u izgled sistema.
Dijagram paketa - prikazuje grupisanje elemenata u celine višeg nivoa. Hijerarhijska struktura - klasa pripada paketu,
paket drugom paketu... Svaki paket pripada jednom namespace-u . Na dijagramima je moguće prikazati i sadržaj
paketa. U isti paket treba stavljati klase koje treba menjati iz sličnih razloga, ili one koje ce se zajedno koristiti.
Zavisnosti između paketa - zavisnosti između njihovog sadrzaja.

Dijagram slozene strukture - omogućuju hijerarhijsko razlaganje slozene struktur.

Dijagram aktivnosti - prikazuje dinamicko ponasanje sistema, opisuje tok poslovne logike i moze da prikaze
paraleleno ponasanje. Dodatni elementi dijagrama su Particije - pokazuju koja klase/celina izvrsava date akcije, i
Signali koji pokazuju da klase prima spoljasnji dogadjaj.

Dijagram slucajeva upotrebe - Opisuju uobičajene

interakcije korisnika i sistema. Obično se prvo opisuje
scenario - niz koraka koji opisuju interakciju između
korisnika i sistema . Slučaj upotrebe (use case) je skup
scenarija povezanih jednim ciljem korisnika. Najveća
vrednost slučajeva upotrebe je u sadrzaju, a ne u
dijagramu.
Dijagram stanja - prikazuju kako dogadjaji menjaju(uticu na) stanje objekata.

Dijagram sekvence - Prikazuje jedan scenario koji obuhvata vise objekata i poruka koje oni razmenjuju za dati slučaj
koriscenja • Opisuje interakciju izmedju ucesnika (objekata) - naglašava redosled i vreme angažovanja učesnika u
toku jednog slucaja upotrebe

Dijagram komunikacije - prikazuje nacin(redosled) na koji entiteti u sistemu komuniciraju - razmenjuju

poruke(sinhrono ili asinhrono)

Dijagram pregleda interakcija - može se smatrati kao dijagram aktivnosti koje su predstavljene dijagramima
sekvenci.

Vremenski dijagram - prikazuje vremensku zavisnost izmedju odgovarajucih dogadjaj

7. Slučajevi korišćenja (Use Cases) i njihova primena u IES.

Koriste se da bi pokazali kako odgovarajući korisnici vide sistem i koriste se u ranoj fazi razvoja softvera. Često
se koriste da odradimo klasifikaciju zahteva koje je klijent imao.

Opisuju uobicajene interakcije korisnika i sistema. Obično se prvo opisuje scenario - niz koraka koji opisuju
interakciju između korisnika i sistema. Slučaj upotrebe (use case) je skup scenarija povezanih jednim ciljem korisnika
Najveća vrednost slučajeva upotrebe je u sadržaju, a ne u dijagramu.

Svaki korak u slucaju upotrebe - deo interakcije učesnika i sistema.

- Korak - namera učesnika
- Prosirenja - uslov primene
- Za svaki korak analizirati sve mogućnosti i nepovoljne događaje

Dijagram slučajeva korišćenja (Use case dijagram) prikazuje

- učesnika (actors)
- slučajeva upotrebe i
- veze izmedju njih
- Koji učesnici izvrsavaju koje slučajeve
upotrebe
- Koji slučajevi upotrebe uključuju druge
slučajeve upotrebe

Veze izmedju slucajeva upotrebe:

- Generalizacija: Generalizovani slučaj
korišćenja opisuje ponašanje zajednicko za grupu
specijalizovanih slučajeva koriscenja.
- Ukljucivanje (inclusion): Slučaj korišćenja je
deo drugog slučaja korišćenja
- Prosirivanje (extension): Slučaj korišćenja
moze prosiriti drugi slučaj korišćenja

8. Klasni dijagrami (Class diagrams) i njihova primena u IES.

Dijagram Klasa - opisuje tipove objekata u sistemu i veze između njih - opisuje strukturu sistema i predstavlja graf
povezan relacijama. Specificira logičke i statičke aspekte modela.

Klasa - skup objekata koji dele iste atribute, operacije, relacije i semantiku.
Atribut - imenovana osobina klase bitna za aspekt modelovanja.
Operacija - aktivnosti koje klasa ume da obavi.
Interfejs - skup spolja vidljivih operacija(klasa koja nije realizovana, ima sve apstraktne karakteristike).
Apstraktna klasa - sadrži jednu ili više apstraktnih operacija (nije realizovana, već deklarisana)
Statičke operacije i atributi - Odnose se na celu klasu, a ne na njenu instancu.
Relacije:
- Zavisnost – relacija korišćenja
- Generalizacija – povezuje opštiju klasu sa specifičnijom – natklasa/potklasa
- Asocijacija – strukturna relacija između konkretnih primeraka
- Realizacija – relacija između interfejsa i klase koja ga implementira
- Agregacija predstavlja odnos celina-deo
- Kompozicija – svaka instanca mora pripadati samo jednom vlasniku
9. Relacije između klasa definisanih UML-om.

- Zavisnost – relacija korišćenja - Ako promene definicije jednog objekta (supplier) mogu izazvati promene
drugog objekta (klijent)

- Generalizacija – povezuje opštiju klasu sa specifičnijom – natklasa/potklasa

- Asocijacija – strukturna relacija između konkretnih primeraka

- Realizacija – relacija između interfejsa i klase koja ga implementira

- Agregacija predstavlja odnos celina-deo

 - Kompozicija – svaka instanca mora pripadati samo jednom vlasniku

10. Sekvencijalni dijagrami (Sequential diagrams) i njihova primena u IES.

Prikazuje jedan scenario koji obuhvata više objekata i poruka koje oni razmenjuju za dati slučaj korišćenja . Opisuje
interakciju između učesnika (objekat) prikazanog pomoću vertikalne linije života i poruka koje se čitaju odozgo
nadole. Jednostavni su i lako razumljivi. Prijem poruke izaziva odredjenu akciju.

Elementi : Učesnici – objekti, Poruke, Linija života, Traka aktivnosti

Ako su dijagrami slucajeva upotrebe prethodno definisani - onda je dijagram sekvence jedna njegova realizaciija koja
prikazuje redosled dogadjaja i objekata. Ovi dijagrami nisu najzgodniji za logiku upravljanja.

-Popunjeni vrh strelice – sinhrona poruka – pošiljalac čeka na odgovor

- Prazan vrh – asinhrona poruka - pošiljalac ne čeka odgovor (može da nastavi da radi)
- Isprekidana strelica - odgovor
11. Dijagrami komponenti (Component diagrams) i njihova primena u IES.

Definiše odgovarajuću fizičku strukturu vezanu za implementaciju I predstvlja deo arhitekturalne specifikacije.
Razvijen je od strane arhitekata I programera.
Prikazuje veze izmedju komponenti softverskog sistema. Ovi dijagrami su veoma korisni kod izrazito
kompleksnih sistema sa velikim brojem komponenata.

Ne opisuju funkcionalnosti sistema ali opisuju komponente koje se koriste kako bi se te funkcionalnosti
obezbedile.Komponente mogu biti biblioteke, paketi, fajlovi…

U UML-u dijagram komponenti opisuje komponente i veze izmedju njih - odnosno nacina na koji se komponente
grupisu u vece komponente softverskog sistema. Komponenta je nesto sto je potrebno kako bio se izvrsio deo
odredjene funkcionalnosti. Komponente su povezane izmedju sebe preko assembly konektora i na taj nacin je
obezbejdeno da jedna komponenta pruza interfejs(sa operacijama) koji zahteva druga komponenta tj. jedna
komponenta koristi servise druge komponente kako bi se obavio neki posao.

Sa slike ispod vidimo odgovarajuće DLL-ove I nezavisne komponente koje zajedno čine neku aplikaciju.

12. XMI (XML Metadata Interchange).

XMI predstavlja standard za razmenu meta podataka. Razvijen od strane Object Management Group (OMG).
Kao što važi za svaki XML standard, XMI dokument se može pregledati u tekstualnom editoru, dok sa druge
strane može biti pročitan nekim alatom za modeliranje.

Meta podaci - podaci o podacima,opisuju karakteristike i kontekst podataka u informacionom modelu

XMI file se sastoji iz 2 osnovne celine: zaglavlja i tela(sadržaja)

Nakon kreiranja UML modela, moguće je generisati XMI fajl. XMI fajl se koristi u daljem procesu modeliranja,
tj. prilikom definisanja CIM profila. Na vežbama smo imali UML model iz koga smo napravili XMI, koji je kasnije
uvučen u CIM Tool.

XMI definiše odgovarajuće objekte I njihove atribute, a postoji i mogućnost povezivanja objekata (u istom ili
različitim fajlovima).
Svaki od objekata se definiše pomoću UUID-a (Universal Unique ID). Validacija XMI dokumenta se radi pomoću XML
šeme(XSD).
Koristi se da modelujemo odgovarajuće modele predstavljene u UML-u i mapirane pomoću MOF (Meta Object
Facility). MOF je praktično iskorišćen da se namapira na XMI i tada različiti alati koji definišu model UML-a
mogu da kroz XMI razmenjuju različite modele - definise XML tagove preko kojih se opisuje serializovani model
EBNF (proširena Bakus Naurova forma) – definiše jezička pravila
Mi definišemo odgovarajuću gramatiku jezika pomoću pravila i na taj način definišemo sve moguće validne
sekvence jezika.

13. URI, URL, URN, IRI

URI (Uniform Resource Identifier) je skup karaktera koji identifikuje odgovarajuće ime ili resurs u mreži. Može
identifikovati resurs preko lokacije ili imena(ili oba). On je nadskup URL-a i URN-a.

URL (Uniform Resource Locator) je podskup URI-ja koji specificira gde se resurs nalazi, ali pored toga što
ukazuje na lokaciju obezbeđuje I mehanizme za pristup resursu. Npr (http://), (ftp://) itd.

URN (Uniform Resource Name) predstavlja niz karaktera koji identifikuje resurs na osnovu imena. Za razliku od URL-a
URN je postojaniji(znacajniji) i vlasnik moze ocekivati da bilo ko drugi moci da ga pronadje resurs .

IRI (International Resource Identifier) je isto što I URI samo dozvoljava internacionalizaciju, pa možemo pisati i
ćirilicu, kineski itd.

14. RDF (Resource Description Framework).

RDF predstavlja nacin definisanja modela podataka(opis resursa) sa formalnom semantikom i opisan je u W3C
specifikaciji. RDF se zasniva na ideji davanja iskaza o resursima u obliku subjekat-predikat-objekat = RDF triplet(RDF
Graf). Subjekat je resurs, Predikat izrazava vezu izmedju Subjekta i Objekta, a Objekat oznacava atribut (Klasa
poseduje atribut - Klasa=S, poseduje=P, atribut=O). Svaki subjekat(resurs) je imenovan svojim jedinstvenim
identifikatorom - URI-jem.

Svrha RDF-a je da obezbedi mehanizam za interpretaciju resursa tako da su oni opisani na nacin da ih
odredjeni softver razume. Taj softver treba da ima mogucnost pristupa informacijama i njihovog razumevanja.

RDF zapravo predstavlja podskup XML-a. Za RDF je bitno da:

- ima jednostavan model
- ima formalnu semantku i da možemo da rezonujemo odgovarajuće informacije iz tako def. semantike
- koristi odgovarajuće proširive rečnike podataka bazirane na URI-ju
- koristi XML baziranu sintaksu
- podržava XML šeme (XSD)
- Svako može da kaže sve o svakome (i da ne kaže ništa) – može biti tačno ili netačno (?)
- Moze se serializovati u razlicite oblike
15. RDF/XML.

W3C je preporučio da se RDF serijalizuje(RDF graf se predstavi u obliku XML dokumenta) u obliku XML-a, I tada se ta
serijalizacija naziva RDF/XML serijalizacija.
Koristeci XML, RDF informacije se mogu lako da se razmenjuju izmedju razlicitih sistema.
Da bi kodirali graf u XML-u cvorovi I predikati miraju biti predstavljeni preko XML elemenata - imena elemenata,
sadrzaj elementa, imena atributa I vrednost atributa.
XML sintaksa za RDF podatke, omogućava definisanje veze između XML čvorova.
Elementi u ovom formatu sadrže nekoliko atributa:
- ID: definiše novi resurs
- about: opisuje postojeći resurs koji će na neki način biti obogaćen nekom dodatnom informacijom
- Description: koristi se za parove Property/Value čime definišemo neke nove informacije o resursima

16. RDFS (RDF Schema).

RDFS fajlovi opisuju klase, atribute i relacije informacionog modela(mogu se kreirati hierarhije klasa). Koristi .rdfs
format. Pogodan je za opisivanje pojedinacnih delova sistema(CIM profil se moze zapisati u rdfs formatu). RDFS
definise prosirivi recnik pojmova. Model predstavlja instancu RDFS-a(-RDF-).
Prosirivi recnik pojmova - RDFS predstavlja proširivi jezik koji obezbeđuje elemente za zadavanje RDF resursa.
najvažniji pojmovi koji se koriste:
- Class- za definisanje nove klase
- Resource- root klasa za sve resurse
- Property- klasa za atribute
- Datatype- identifikacija tipova podataka
- subClassOf- za specificiranje hijerarhija
- range- limitiranje vrednosti za neki atribut
- type- tip klase
- domain - domen resursa
- about- opisuje postojeći resurs
- Description - opis
- comment, label

17. CIM RDFS.

Kada je pravljen CIM, RDF šema je proširena odgovarajućim semantičkim značenjima i napravljen je CIM RDFS.
CIM RDFS koristi podskup RDFS-a, ali ima I svoja proširenja.

Od RDF klasa je koristi: Resource, Class, Literal I Property.

Iz RDFS-a se koristi:
- Class- za definisanje nove klase
- Property- klasa za atribute
- subClassOf- za specificiranje hijerarhija
- type- tip klase
- about- opisuje postojeći resurs
- comment
- Resource- root klasa za sve resurse
- Datatype- identifikacija tipova podataka
- range- limitiranje vrednosti za neki atribut
- domain - domen resursa
- Description - opis
- label

Prosirenja RDFS-a:
- profile - multiplicity
- classCategory - inverse rolename
- belongsToCategory - isAggregate
- datatype - stereotype

18. CIMXML.

Sluzi za razmenu podataka izmedju sistema-aplikacija. CIM/XML datoteka je formirana u skladu sa rdf-om. U ovoj
datoteci RDF sintaksa definise konkretne instance klasa. Jedinstveni identifikator je obelezen sa rdf:ID atributom I
naveden je prvi. Nakon identifikatora slede ostali atributi. Ukoliko neki atribut referencira neki drugi objekat
obelezen je atriutom rdf:resurce koji kao vrednost sadrzi identifikator referenciranog objekta.
CIM/RDFS je sema za CIM/XML.
Iz CIMXML-a nemamo eksplicitno definisanu referencu na CIM profil koji ga definise, ne postoje direktne reference
ka objektima drugih cimxml-a fajlova

19. Veza CIM UML – RDF – RDBMS.

UML predstavlja definisanje modela, RDF njegovu konkretizaciju (sa konkretnim vrednostima i kreiranjem
objekata) dok relacioni model predstavlja smeštanje tih podataka u neku bazu podataka -u bazi ne postoji
mogućnost kreiranja reference već se moraju kreirati nove tabele.

UML sadrži odgovarajuće klase sa svojim atributima ili asocijacijama. Naš model sadrži odgovarajuće instance
klasa – objekte.

RDF sadrži klase koje sadrže svoje attribute. Instance su nam resursi, I oni imaju svoj opis(ResourceDescription)
I vrednost. Vrednost može biti URI ili prava vrednost.

Relacioni model za svaku konkretnu klasu ima odgovarajuću tabelu. Za attribute imamo odgovarajuće kolone u
tabeli. I praktično svaka vrednost ima field value.

Podatke je potrebno validirati odma pri unosu u sistem, jer moramo imati mogucnost da validiramo model na
neki način. Relacioni model je trenutno standard za modelovanje baza podataka, I on svakako sadrži manje
informacija od objektnog modela. Mreže se modeluju pomoću grafova, ali su problem dovoljno kvalitetne graf
baze podataka I njihova sigurnost, da mogu da rade bez greške u distribuiranom režimu itd.

20. Ontologije.

Ontologija je domensko znanje, koje predstavlja odgovarajuće termine koje smo ustanovili u okviru nekog
domena koji želimo da modelujemo. Recimo definisali smo neke reči ili atribute I njihovo značenje u okviru tog
domena.

U okviru te ontologije smo definisali klase, attribute, njihove veze I to smo u okviru CIM-a odradili sa UML-om.

Mi možemo definisati i odgovarajuće:

- restrikcije – formalni opis nečega što mora biti zadovoljeno kako bi akcija/unos bio prihvaćen
- pravila - neki zaključci koji se izvode na osnovu tvrdnji
- aksiomi – tvrdnje koje važe u okviru domena na koji se odnosi ontologija
- događaji – kad, šta, sa čim je povezano itd.
Sama ontologija može da se definiše na različite načine. Da bi formalno definisali ontologiju možemo iskoristiti:
- RDF šemu
- OWL – Web Ontology Language
- OWL2 – najnoviji jezik za definisanje ontologija

Većina ontoloških jezika je bazirana na RDF modelu, a razlike između ontologija mogu biti u izražajnosti
odgovarajućih jezika I mogućnost zaključivanja kompleksnosti.

21. OWL.

OWL predstavlja WEB Ontology Language. On je moćniji od RDF-a, I on u sebi može podržati I relacije,
asocijacije,dodatne tipove podataka, enumeracije. Koristi se za specificiranje ontologija koje će dati semantiku
podacima, standard koji uključuje RDF i proširuje ga(zasnovan na RDF-u, prosiruje ga). Koristi se u situacijama kada je
potrebno obraditi informacije u aplikaciji(a ne od strane ljudi).

Prednosti OWL-a:
- podržani kardinaliteti,
- veca mogucnost izrazavanje znacenja i semantike nego XML, RDF, RDFS
- sinonimi za objekte, klase, svojstva
- mogućnost dodeljivanja karakteristika svojstvima – tranzitivnost, simetričnost...
- definisanje ograničenje za vrednosti koje neko svojstvo uzima
- mogućnost definisanja novih klasa primenom skupovnih operacija nad postojećim klasama

OWL koriste neki CIM alati za definisanje CIM-profila(CIM model podataka je def. u UML-u I razmenjuje se preko
XMI-a)

U ontologiji propertija definisani su domen i rang. Domen-ko moze imati property, range-koja moze biti vrednost
propertija.

22. Višeslojna arhitektura po CIM standardu i njena primena u IES.

Imamo informacioni model koji možemo proširiti određenim ekstenzijama vezanim za naš domen. Možemo da
ga povežemo sa drugim aplikacijama. Iz tog informacionog modela mi definišemo kontekstni koji predstavlja
podskup CIM/UML-a i njegovih definisanih proširenja.

CPSM predstavlja Common Power System Model koji je napravljen u SAD-u za razmenu podataka isključivo
prenosnih mreža.

Zatim sledi definicija poruka gde definišemo strukturu profila i strukturu poruke. Ta strukura poruke predstavlja
osnovni izgled poruke, kako ona izgleda. Definiciju poruke imamo sa XSD-om, a definiciju profila imamo sa CIM
RDFS-om. Drugi profili mogu da budu definisani sa OWL ili sa DataBase relacionom šemom.
Iz toga mi definišemo CIM/XML fajl, XML NDR(Network Data Record) ili ostala pravila koji definišu naše modele.
Krecemo od nekog informacionog modela, pa definišemo neki kontekst u okviru toga. Navedeni kontekst
nam definiše poruke, a te poruke nam definišu sam model. Drugačije rečeno krećemo od apstraktnog modela I
dolazimo do sintatičkog modela. Krecemo od CIM-a definisanog UML-om, definisali smo naše profile I iz tih profila
možemo da definišemo odgovarajuće poruke, a sintaksa je u ovom slučaju XML sintaksa definisana XSD-om koji
definiše našu poruke.

Informacioni nivo – ovde se nalazi CIM (sa ekstenzijama ukoliko su potrebne); tu postoji generalizovan
model svih mogućih elemenata i njihovih veza; postoje modeli za različite domene; taj model je
nezavistan od aplikacije, ali pruža sve koncepte potrebne bilo kojoj aplikaciji
Kontekst – definiše se profil (deo CIM modela koji je potreban uz određene ekstenzije) u RDFS formatu
- UML-podskup inf. modela sa ograničenjima i bez dodataka
- klase i atributi koji odgovaraju potrebnom biznis domenu
Sklop poruke – IEC-om 61968 definišemo poruke koje se mapiraju na XSD šemu. Tu se definiše
struktura potrebnih poruka koje će se razmenjivati između aplikacija.
Sintaksa razmene – XSD šema definiše format poruka koji DMS mora da ispoštuje da bi komunicirao sa
drugim sistemima. S druge strane RDFS definiše CIM/XML koji drugi sistemi moraju da ispoštuju da bi
komunicirali sa DMS-om
Implementacija – konkretne tehnologije. Korišćenje recimo XML-a za serijalizaciju fajlova i poruka
Ograničenja XSD-a u odnosu na RDFS su to što ne možemo da definišemo odgovarajuća nasleđivanja.
Nasleđivanje u XSD-u se definišem “ugradnjom” elementa u okviru onoga koga on nasleđuje I nemamo
mogućnost da na drugi način referenciramo kao u RDFS-u (subClassOf). Reference u XSD-u se rešavaju
uglavnom preko stringova, I ne može da se validira da li je to što se referencira zaista validno.

23. Arhitekturalni model Smart Grid-a – domeni, zone i interoperabilnost.

Interoperabilnost – sposobnost pravljenja sistema tako da mogu da međusobno razmenjuju informacije i

interpretiraju ih prema svojim potrebama

Interoperabilnost(dimenzije)
1. Biznis sloj – biznis pogled na razmenu informacija tog smart grid sistema(regulativa).
2. Funkcijski sloj- definiše slučajeve korišćenja i funkcije
3. Informacioni sloj – opisuje informacije koje se koriste za razmenu između funkcija, servisa i
komponenti. Tu se, u suštini pojašnjavaju koncepti koje sadrže poruke koje se razmenjuju između
sistema. Ovde se definišu modeli podataka – CIM.
4. Komunikacioni sloj – značaj u opisivanju protokola i mehanizama za interoperabilnu razmenu
podataka. Sadrži dve kategorije: prva obezbeđuje razumevanje struktura podataka koje poruka sadrži,
a druga služi za obezbeđivanje prenosa poruka kroz različite vrste mreža. (Protokoli Modbus, ICCP, CIM
XML)
5. Sloj komponenti – fizički nivo za prenos poruka (tcp/ip)
Domeni
1. Proizvodnja (generisanje) – predstavlja generisanje električne energije (npr. u nuklearnim ili
hidroelektranama). Obično je povezan sa sistemom prenosa.
2. Prenos – predstavlja infrastrukturu i organizaciju koja transportuje ee preko velikih udaljenosti
3. Distribucija – infrastruktura i organizacija koja distribuira električnu energiju do krajnjih korisnika
4. DER (distribuirani električni resursi) – nezavisni manji generatori koji se povezuju na električnu mrežu i utiču
na nju. To su kao neki pomoćni generatori (vetrogeneratori, solarni paneli...)
5. Prostorije potrošača – odnosi se i na krajnje potrošače ali i na proizvođače EE. Obuhvaćeni su
industrijski, komercijalni i kućni objekti koji su povezani na električnu distr. mrežu
Zone
1. Procesi – uključuje fizičke, hemijske i prostorne transformacije energije kao i fizičku opremu koja je
direktno uključena u te procese (generatori, transformatori, kablovi...) - sta se stvaro desava
2. Teren – oprema za zaštitu, kontrolisanje i praćenje procesa u ees (zaštitni releji, bay kontroleri)
3. Stanice – agregacioni nivo; tu se skupljaju i agregiraju podaci dobijeni iz raznih merenja
4. Operacije – kontrolne operacije za odgovarajući domen: DMS, EMS... rad sa prethodno prikupljenim
Podacima - operatori koji upravljaju mrezom
5. Preduzeće – uključuje komercijalne i organizacione procese, servise i infrastrukture za preduzeće
(upravljanje radnom snagom, obuka osoblja, upravljanje odnosima sa kupcima, nabavka...)
6. Tržište – rad sa tržištem (trgovanje energijom, masivno tržište...)

24. Integracije u okviru Smart Grid-a bazirana na standardima.

U današnje vreme su svi procesi automatizovani i to toliko da čak distribucije ne razvijaju same svoj softver nego
postoje proizvođači koji im nude gotova rešenje.
Neki od sistema dostupni na ovom tržištu su: DMS (Distribution Management System), EMS (Energy), OMS
(Outage), GIS (Geographic information system), AMI (Advanced Metering Infrastructure), MDM (Meter Data
Management), HAN (Home Area Network)
Da bi svi sistemi radili zajedno na ostvarenju ciljeva, moraju da komuniciraju(moraju biti uskladjeni) - integracija.
Varijante integracije: na nivou 2 učesnika (svaki sistem sa svakim) ili na nivou sistema (pričaju preko CIMXMLa)
Integracione razlike (distance):
1. Ne postoji standard
2. Interfejsi mogu biti namapirani
3. Interfejsi koriste zajednicki model
4. Optimalno da imamo PlugAndPLay standard (postoje Interoperability testovi (testovi uskladjenosti))

Standardizacija modela olakšava integraciju sistema. Neki od najzastupljenijih standard su:

1. CIM
2. Multispeak - definisan za mala americka preduzeca, nemaju potrebe za ESB (nema potrebe za
komplikovanjem), rade poruke uz oslonac na web servise
“Standards are great. Everyone should have one”
Nivoi integracije:
- Nema standarda sve sa radi custom - kompleksno.
- App imaju odredjene interfejse koji mogu biti namapirani.
- Ako koriste interfejsi zajednicki model, to je jos bolje ali npr CIM moze da ima odredjena prosiranja.
- Plyg and Play - dobro definisani prorokoli(IO testovi)(SCADA-ICCP)

25. Tipični CIM pristup modeliranju elektroenergetskog sistema.

Nezavisno se definise svaki profil. Svaki profil definise svoje klase i atribute npr. Svaki profil definise svoju klasu
IdentifiedObject - neodrzivo.

-EqBoundary- Granica izmedju dva preduzeca - oprema

-SSH Profile - propracu uklopnog stanja
-Toplogy- Topologija - aktuelno stanje mreze
-Dynamics- parametri generatora
-GeoLoc- Gografska lokacija
-Equipment- Oprema - osnovni!!!
-SV- aktuelne vrednosti u mrezi(npr. Treutna potrosnja)
-TopoBound- Granica izmedju dva preduzeca - topoloska ostrva
-DiagLayout-

Pristup modelovanju elektricne mreze definisan je u okviru CIM-a. Pristup se oslanja na podskup RDF-a, instance su
definisane u CIMXML format, koristeci CIM/RDFS, kako bi se kreirao cim profil.

Iz jednog CIMXML fajla mogu se referencirati drugi objekti ali ne zanmo u kom fajlu, samo zanmo ID(URI) objekta.
Delovi koji referenciraju odredjeni objekat pretpostavljaju da on I postoji.

Imamo da jedan model zavisi od drugog (tada imamo odgovarajući property DependentOn). Na primer
Measurment može zavisiti od Equipment-a da bi se nakačio na njega. Međutim ako jedan referencira podatke
iz drugog modela mi nemamo način da direktno proverimo reference osim da sad ručno gledamo oba modela.
Za DependendOn nemamo dovoljnu semantiku da računar može lako da pročita.
26. Linked Data CIM pristup modeliranju elektroenergetskog sistema.

Nedostaci CIM-a sa stanovista Linked Data: CIM profil nije referenciran od strane CIMXML modela. Iz jednog CIMXML
fajla mogu se referencirati drugi objekti ali ne zanmo u kom fajlu, samo zanmo ID(URI) objekta pa zato nije moguca
automacka validacija. CIM nije otvoreni recnik pojmova i namece skup ogranicenja koji utice na primenljivost.

Ne redefinisemo klase. Umrezavamo kompletno resenje. Objekat iz modela moze direktno da

referencira ili klasu i model iz drugog modela. Omogucava da podaci koji su do sada bili
nezavisno definisani koji se mogu dati na analizu nekom dizajneru da izvuce neke zakljucke koji do sad nisu mogli da
se izvuku.

Mi možemo sa odgovarajućim IRI/URI-jem da definišemo odgovarajuću ontologiju koristeći JSON-LD(Linked

Documents) sintaksu. Pomoću ključne reči isEquivalent (iz JSON-LD) se definise referenciranje profila ka
ontologiji.
Definisana ontologija nam predstavlja neko domensko znanje za neku integraciju ili za neku oblast koju
hoćemo da modelujemo. Ukoliko u jednom profilu koristimo klase koje se definisane u drugom domenu mi ih
možemo izjednačiti(equivalent-irati) I na taj način imati mogućnost da na automatski način dopremo do definicije
klase. Instance iz dva modela se povezuju uz pomoć IRI-ja. To znači da direktno u jednom modelu možemo
referencirati instancu koja se nalazi u drugom. Ono što je novo uneto ovde je mogućnost zaključivanja nekih veza
koje nisu eksplicitno definisane samo u okviru jednog profila.
27. CIM profil kao ontologija.

Definise skup imena I tipova podataka. CIM profil je definisan kao uredjena cetvorka O(C,P,PC,SR)
C - set koncepata - klase(ime + prop)
P - set propertija (n, PC) - n=ime, PC- ogranicenja
PC - set ogranicenja (multiplicity, type…)
SR - set semantickih relacija
Podrzane relacije:
- Same-as - iz razlicitih klase gadjamo istu stvar koja se drugacije zove - na nivou klase
- Is-Equivalent - na nivou objkata - jedna obj je isto sto I drugi obj
-Kind-of - specializacija
-Asocijacije- asocijacije izmedju koncepata

Rezulat primene ovakvog pristupa na CIM svet može biti:

1) CIM klasa postaje skup koncepata(deklaracija CIM klasa su CIM koncepti)
2) Atributi klasa su odgovarajući property-i
3) Relacije između CIM klasa postaju apstrakovane kao skupovi semantičkih relacija. Asocijacije između
CIM klasa su definisane kao property ontologije koje imaju “type equal” između referenciranih CIM
klasa.

28. Jezici semantičkog Web-a.

Krenulo se od odgovarajućeg URI-a i IRI-a - identifikatorima.

Definicije XML-ova, namespace-ova I XML šema nam omoguciju komunikaciju nezavisno od platforme.
Zatim smo definisali RDF I RDF šemu, u našem slučaju CIM XML I RDFS(ili CIM RDFS). Vidimo da su ovi dokumenti self
described. RDF šema je u principu prikazana u RDF-u I ona je samoopisana na osnovu toga što znamo
semantiku opisanu u odgovarajućem modelu. Primećujemo da što se više penjemo imamo više semantičkog znanja.
Zatim smo definisali ontološke rečnike. Ontologije definišemo pomoću OWL-a. Skup RDF iskaza definise ontologiju.

Jezici koji definišu logike su su descriptive logic jezici. Oni služe da se definišu odgovarajući dokazi na osnovu
pojedinih tvrdnji definisanih sa logičkim jezicima. Na taj način, kada dokažemo sve logičke tvrdnje u nekom
ontološkom jeziku mi tome možemo da verujemo.

Semanticki web je zanovan na RDF formatu(subjekat-predikat-ovjekat , iskazuje se kroz XML sintaksu). Web trenutno
ne sadrzi nikakvo znacenje, on dobija zancenje tek kada ga ljudi interpretiraju.
Ideja semantickog weba je jednostavna, iskoristiti znanja, principe i tehnologije, koje su u osnovi obicnog weba za
novi web koji bi bio univerzalni medijum za razmenu podataka i znanja. Klasican web je oblikovan da njegov korisnik
bude covek a ne masina - podaci na webu moraju biti masinski citljivi ali I dovoljno fleksibilni.
29. Podela CIM paketa IEC 61970.
IEC 61970 – služi za za modelovanje prenosa ,uključujuci i razmenu podataka i EMS, definiše toplogiju, odgovarajuće
provodnike i SCADA-u.

CIM je definisan u IEC 61970-301 i predstavlja glavni deo ove serije standarada, ukljucuje najveci deo objekata
potrebnih za modelovanje el.eng mreze. Glavni zadatak CIM-a je da obezbedi model podataka nezavisan od
platforme. CIM nude opšte informacije o modelu kao i šeme za poruke da bi modeli mogli da
se razmenjuju između sistema. CIM standard je zasnovan na UML-u .Obezbeđuje zajedničku semantiku za sve
razmene informacija. Nije vezan za određeni tip aplikacije, a može da se prilagodi svakom tipu. Klase u CIM-u su
grupisane po paketima u zavisnosti kakvu ulogu imaju u EES.

IEC 61970 takodje sadrzi:

-Component Interface Specification(CIS) - definise kako se podaci nezavisni od platforme i genericki interfejsi
mogu u kombinaciji koristiti za komunikaciju
-Generic Interface Definition(GID) - fokusiran na razmenu podataka(i CIM semantiku).

Domain paket definiše tipove podataka I neke osnovne stvari. Tipovi podataka mogu ovde mogu biti napon,
jačina struje, aktivna I reaktivna snaga itd. Svaki od ovih tipova podataka je obično definisan kao uređena
trojka gde imamo (Multiplicity, jedinica, vrednost) gde Multiplicity može biti (kilo, nano…), a jedinica(V,W).
Core paket definiše neke osnovne klase na koje se ostale oslanjaju. Klase ovog paketa se odnose na fizičke
delove opreme. Obično se koriste za povezivanje komponenti definisanih u Wires paketu (npr. terminal)
OperationalLimits – operaciona ili upravljačka ograničenja
Wires - Definiše kompletnu provodnu opremu. Predstavlja kompletnu konektivnost mreže. Na slici ovaj paket zavisi
od toplogije, međutim ne možemo napraviti aktuelno stanje mreže bez konektivnosti. Definiše sve delove opreme
koji su povezani na mrežu (modeluje osnovne komponente koje se koriste za generisanje, prenos i distribuciju
električne energije).
Topology – aktuelno stanje mreže. Daje informaciju kako se mreža povezuje u obliku čvorova. Zajedno sa
Terminal klasom iz Core paketa modeluje konektivnost (fizički način na koji su elementi povezani u sistemu).
Dodatno modeluje i topologiju sistema (logičku povezanost sistema u mreži). Topologija definiše i topološka
ostrva.
Outage – možemo definisati uređaje u outage-u, tj. otkazu. Definiše raspored za planiranu konfiguraciju
mreže. Sadrži klase koje definišu stanje switch-eva u određenom trenutku.
LoadModel – imamo definisane potrošače I dodeljujemo im krivu potrošnje. Služi za
modeliranje potrošača EE i opterećenja sistema. Posebne okolnosti koje mogu da utiču na opterećenje kao što
su godišnja doba i tipovi dana su uključeni u paket.(EnergyConsumer klasa i njene podklase zajedno sa Wires
paketom definišu fizičku vezu između mreže I potrošača.
Protection – odnosi se na zaštitnu opremu u stanici, kada i kako će reagovati. Opisuje i
podešavanja za zaštitnu opremu kao što su releji.
Generation – opisuje proizvodnju
ControlArea – upravljačka oblast kojom neki od operatera može upravljati.
SCADA - služi za modelovanje informacija koje koriste SCADA aplikacije.
Measurments – na kojim mestima mi se u opremi nalazi merenje. Rezultat Measurments-a generiše
topologiju. Sadrži klase koje opisuju dinamičko merenje podataka koji će se razmenjivati između aplikacija
Equivalents – služi za modelovanje ekvivalentnih mreža (dve mreže su ekvivalentne ukoliko poseduju iste
elektrotehničke karakteristike)

30. Podela CIM paketa IEC 61968.

IEC 61968 – Fokus na impvinu, naplatu, market, prosirenja mreze. Predstavlja prosirenje IEC 61970-301 prosiren
podsistemom distribucije (DMS). Glavni deo ove serije standarada je Interface Reference Model (IRM) koji specifikuje
slucajeve upotrebe, interfejse
i poruke.

Imamo zajedničke pakete(Common) sa definisanim lokacijama(Location) I odgovarajućim domenom(Domain2).

Common – opisuje informacije o često korišćenim objektima. Sadrži opšte klase koje su podržane u
distribuiranom sistemu koje predstavljaju osnovu za modelovanje razmene podataka u okviru ees.
- Po definiciji CIM-a: ovaj paket sadrži informacione klase koje podržavaju distribuirano upravljanje u
opštem smislu
Operations(3,4) – sadrži objekte kojima upravlja Outage management. Uključuje dokumentovanje operacija
kao što su otkazi i promene stanja switch-eva . Klasa OutageRecord ima niz atributa koji sadrže podatke o otkazu
(početak, kraj, trajanja, tip, napravljena šteta, akcija za popravljanje...)
Assets(4) – sadrži klase za opisivanje fizičkih karakteristika opipljivih električnih resursa(imovine).Sluzi za opisivanje
asset-a (Asset i AssetContainer) ali i klase koje podržavaju akcije nad tim asset-ima kao i subjekat koji
te akcije može izvršiti.
- Po definiciji CIM-a: ovaj paket sadrži klase koje podršavaju asset management aplikacije. Takođe bave
se fizičkim i aspektom životnog ciklusa za različite mrežne resurse. Asset paket sadrži veliki broj atributa koji uključuju
proizvođača, serijski broj, datum, proizvodnje, datum kupovine...
Work(6) – sadrži osnovne klase koje su potrebne za work management. Služi za opis aktivnosti koje treba
da se izvrše: vrsta (održavanje, merenje, uključivanje, isključivanje...), prioritet, datum zahteva za
izvršavanje, na koje potrošače se odnosi aktivnost...
Customers(8) – sadrži klase koje su potrebne aplikacijama koje rade sa naplaćivanjem usluga potrošačima.
Metering(9) – sadrži klase koje su potrebne aplikacijama koje se bave merenjima kao i udaljenim
funkcijama za očitavanje. Ove klase su obično povezane sa tačkom gde se usluga dostavlja potrošaču
LoadControl(9) – Sadrže klase koje su potrebne aplikacijama koje rade sa kontrolisanjem opterećenja na određenoj
opremi u mreži.
PaymentMetering(9) – proširenje Metering paketa. Sadrži informacije o plaćanju i različitim opcijama plaćanja.
Planning (5,7) - planiranje , radovi u mreži(planirani, neplanirani)
ERPS podrška(Enterprise Resource Planing Support), GMLS podrška (Geography Markup Language
Support) – pokušaj da se sa predefinisanom semantikom xml-ova definišu lokacije objekata

31. Podela CIM paketa IEC 62325.

IEC 62325 (tržište električnom energijom) –predstavlja standard koji pokriva komunikaciju na tržištu (evropsko i
američko) energije. Glavni deo pokriva komunikaciju između operatora i učesnika na tržištu
Ovo je grupa standarda koja je namenjena tržištu električne energije. Severno-američko i evropsko tržište je
različito I imamo različite načine implementacije samog EE sistema.

-EU:
-Day Ahead Markets - prognoza za sledeci dan
-Intra-Day - prognoza za tekuci dan
-Ballancing - prodaja i kupovina ee
-Saradnja sa ENTSO-E
-NA:
-Day Ahead -prognoza sledeci dan sa ekonom. ogranicenjima
-Hour Ahead - prognoza za sledeci sat
- RT Market - sa sigurnosnim ogranicenjima
- Saradnja sa ISO/RTD
U Evropi imamo interoperability testove(američko tržište nema) I integracija radi na dnevnom nivou.

MarketCommon – opisuje učesnike i njihove uloge na tržištu. Jedan učesnik može da ima više uloga

MarketManagement – za evropsko tržište. Generiše skup profila poruka. Ovi profili će se koristiti kada
je tržište zasnovano na Third-Party-Access tada je svakom dobavljaču omogućeno: Prenosna mreža za snadbevanje
potrošača, Velike i male transakcije razmene energije (u okviru tržišta ili između više njih)
- ključna uloga je u konceptu MarketDocument pomoću kojeg se razmenjuju informacije
- svaki biznis proces treba da ima svoj konkretan skup dokumenata koji će biti specificiran uz pomoć
profila u UML-u
MarketOperations – za američko tržište. Opisuje skup klasa koje će se zajedno sa onima iz MarketCommon paketa i
drugih delova CIM-a, a čiji je cilj generisanje modela profila koji uključuju I Day ahead i Real-time modele koji su
karakteristika američkih mreža.
32. CIM Interoperability Framework.

Pomoću CIM Interoperability framework-a možemo da predstavimo upravljanje EE sistemom sa stanovišta

softvera iz 3 aspekta:
Tehnički
- Osnovno povezivanje – mehanizam za uspostavljanje fizičke i logičke veze između različitih sistema
- Interoperabilnost mreže – mehanizam za razmenu poruka kroz različite mreže. Tehnički aspekt je baziran na
sintaksnom nivou (definišemo neki XSD i naspram njega razmenu poruka)
Informacioni (semantički)
Uloga CIM-a je da definiše sintaksu, semantiku i kontext razmene podataka.
-Sintaksnu interoperabilnost - razumevanje struktura podataka u porukama
-Semantičko razumevanje – razumevanje koncepata koje sadrže poruke koje se razmenjuju između sistema
-Poslovni kontekst – u kom kontekstu se razmena poruka vrši
Organizacioni
- Poslovnih procedura - razumevanje domena i zadatka
- Poslovni ciljevi - strateški i taktički ciljevi koje sistemi dele
- Ekonomski/Regulatorni zahtevi

Uspostavljanje inteoperabilnosti na jednom nivou, daje veću fleksibilnost na drugim nivoima

33. Grupe CIM profila definisane u okviru IEC 61970-4xx i primena u IES.
CIM profil je deo CIM-a koji sadrži podskup klasa i atributa, koji sa svojim vezama daju smisaonu celinu
- profili su kreirani u skladu sa specifičnim situacijama u skladu sa kojima su birani i objekti tih profila
- profili definisu nama odgovarajuce interfejse i oni postaju javno dostupni na neki standardan nacin (npr. GDA)
- profil za odgovarajucu integraciju definise odgovarajuću ontologiju (domensko znanje)

IEC 61970-4xx predstavlja seriju Component Inteface standarda. Ovde se definišu zahtevi prema interfejsima
koje određena komponenta(ili aplikacija) implementira:
- radi razmene informacija sa drugim komponentama(ili aplikacijama)
- da bi pristupila podacima na jedan standardan način

Interfejsi opisuju sadržaj poruka i servise koji mogu biti korišćeni od strane aplikacija u te svrhe.

61970-456 – stanje mreže

-State Variables – profil za promenljive stanja koje su izračunate ili izmerene za određeno stanje u vremenski
promenljivom sistemu
-Topology – specificira podatke o topologiji mreže za određeno stanje (kako su switch-evi postavljeni, da li su
generatori povezani...)
-Measurement Set – kako će informacije o merenju biti struktuirane. Postoje diskretna i analogna merenja
61970-452 – statika
-Measurement Specification – specifikacija mera
-Equipement Model – ključni deo za definisanje električne mreže. Sadrži statičke podatke o
modelima fizičkih elemenata EES
-Schedules – specifikacija o vremenskim promenljivim objektima - krive proizvodnje I potrosnje
-Boundary objects - granicni objekti
-Common objects - zajednicki objekti
61970-453 – grafika
-Schematic Layouts – grafički šematski prikaz
61970-45x
-Dynamic model- dodavanje dinamike u model mreze za simulacije.
EquipmentModel predstavlja glavni CIM profil. On u sebi definiše konektivnost, tj. izgrađenost mreže.
Na ovako definisanu izgrađenost mreže mi postavljamo odgovarajuća merenja. Ta merenja sadrže skup aktuelnih
merenja(I analogna I digitalna) koja utiču na topologiju(aktuelno stanje mreže). Za topologiju sam nam bitna
trenutna digitalna merenja (analogna nas ne interesuju, jer mi treba da napravimo topološka ostrva, a za to treba da
znamo u kom stanju nam je rasklopna oprema).
Topology = Equipment + StateVariables

34. Zvanični CIM profili – CPSM, CDPSM i ENTSO-E.

CPSM: The Common Power System Model – napravljen je u SAD-u za razmenu podataka isključivo
prenosnih mreža
- definiše podskup klasa, atributa i veza koje su potrebne za izvršavanje EMS aplikacije (za praćenje protoka
energije i procene stanja)
- originalna definicija potekla od severno-američke korporacije NERC pa je posle proširena od strane IEC
- koristi se u USA za razmenu modela sistema prenosa
- definisan je IEC 61970-452 standardom.
Svrha tog standarda je:
1. Da poboljša preciznost modela ees
2. Da ostvari konzistentnost u modelima
3. Da smanji ukupne troškove održavanja
Integracije bazirane na CPSM-u se izvode tako sto svi susedni sistemi
moraju da imaju kompletan pristup modelu svih susednih elektro-prenosnih preduzeća da bi mogli da
izvrše estimaciju stanja i proračunaju tokove snaga.
Sam model razmene podataka je baziran na CIM XML-u koji praktično predstavlja podskup RDF-a. Sam
CIM profil je definisan u obliku RDF šeme koja sadrži sve potrebne informacije da bi se model
jednoznačno definisao. Model omogućuje i proširenja definisana po CIM standardu.
CDPSM: The Common Distribution Power System Model – koristi se u Evropi za razmenu distributivnih
modela mreže.
Evropska mreža je komplikovanija kod niskonaponske mreže, jer ima mnogo više korisnika(u SAD-u ima
po 4-5). Američka mreža je komplikovanija kod monofazno/trofaznog konvertovanja električne
energije.
CDPSM ima svoja ograničenja, i veoma je teško završiti realan projekat oslanjajući se samo na ovaj
profil jer ne sadrži dovoljno informacija o zaštitnoj opremi, o detaljima vezanim za integraciju SCADE sa
samim modelom itd. Takođe ne postoji ni interoperability test vezan za CDPSM.
ENTSO-E: Korišćen je u Evropi za razmenu podataka kod prenosnih(transmission) mreža. Sadrži profile:
Equipment, Topology, StateVariables, EquipmentBoundary, TopologyBoundary, Geographical,
DiagramLayout, Dynamics...

35. Model konektivnosti u CIM-u.

Kada treba da se definiše veza između elemenata u mreži izbegava se direktno povezivanje elemenata
asocijacijom, umesto toga se koriste ConnectivityNode-ovi. Provodna oprema se ne povezuje direktno sa
ConnctivityNode-ovima (konekcionim čvorovima) već se to radi posredno, preko Terminal-a koje sadrži svaka
instanca provodne opreme. ConnctivityNode predstavlja tačku sa nultom impedansom.

Model konektivnosti ili povezanosti u CIM-u je napravljen na sledeći način: Imamo IdentifiedObject,
PowerSystemResource, Equipment I ConductingEquipment. Provodna oprema jedino ima smisla da uđe u
izgrađenost mreže Provodna oprema ima svoje terminale (nula ili više). Terminal predstavlja tačku spajanja između
provodne opreme I ostatka mreže, a to spajanje se vrši kroz ConnectivityNode pa jedan terminal može biti vezan na
0 ili 1 ConnectivityNode.
Na terminale se takođe postavljaju I odgovarajuća merenja(Measurment).
Topološki čvor (TopologicalNode) predstavlja grupu ConnectivityNode-ova koji su u jednom trenutku povezani
električno uzevši u obzir akutelno stanje mreže. Može se reći I da topološki čvor predstavlja grupu
ConnectivityNode-ova koji su između sebe povezani nultom impedansom, a da bi bili njom povezani moraju
imati zatvorene prekidače. Prema aktuelnom stanju prekidačke opreme topološki čvorovi se menjaju.
Grupa topoloških čvorova koji su povezani čine topološko ostrvo(TopologicalIsland). Velika distributivna mreža
se izdeli na manja topološka ostrva koja se mogu nezavisno proračunavati.
Bus predstavlja sabirnicu. Na nekom višem nivou apstrakcija topološki čvor možemo smatrati sabirnicom.
Bus/Branch model je izračunat spram aktuelnog stanja merenja.
36. Razmena podataka između aplikacija za analizu mreže uz oslonac na standardne profile.

Data Modeller - (opisuje statičke podatke o mreži) kao izlaz daje Equipment Model Profile (podaci o opremi) i
Schematic Layout Profile (geografski podaci) koji su dalje ulaz u SCADU, modul za proračun topologije i aplikaciju za
računanje protoka energije i u estimator stanja.
SCADA - SCADI je potreban Equipment Profil da bi mogla da odredi kojoj opremi pripada koje merenje, izlaz su
Analog i Discrete Measurement Profili koje koristi State Estimator. Discrete Measurement Profili koristi i Topology
Processor.
Topology Processor - koristi Equipment Profile, Discrete Measurement Profil i Scheduel(krive potr. I proiz.) za
proracu topologije.
State Estimator - koristi Analog i Discrete Measurement Profile, Equipment Profil, i Scheduel(krive potr. I proiz.) a
daje nam StateVariable Profil - profil za promenljive stanja koje su izračunate ili izmerene.
Power Flow Application - Koristi topologiju, StateVariable Profile, Shematic , Scheduel(krive potr. I proiz.) a daje nam
proracunate vrednosti (SV - izracunate vrednosti npr. Tokove snaga.)
Schedule Updater - koristi StateVariables Profil a daje nam podatke o krivama potrsnje i/ili prozvodnje.

37. Potpuni i modeli razlika pri estimaciji stanja.

Equipment, Measurment i Schedules Modeli se retko menjaju(staticki) - kada ih formiramo imamo potpun model.
Kada zelimo da ih menjamo(azuriramo) potreban nam se samo model razlika novog i prethodnog modela kako bi ih
azurirali.
Descrete i Topology model se menjaju cesce ali kada dobijemo model razlika moramo formirati azurirani-potpuni
model.
Analog i SV modeli se menjaju stalno I uvek nam je potreban njihov potpuni model kako bi mogli da estimiramo
stanje i vrsimo propracune tokova snaga.
38. Referentni model interfejsa baziran na razmeni IEC 61968 poruka.

Po definiciji CIM se koristi da bude jedan, ’’zajednički’’ model. Jedan od ključnih ciljeva CIM-a je da pruži prevenciju
dupliranja definicije podataka, a da i dalje definiše sve podatke koji se razmenjuju između sistema koji su definisani
IRM-om (Interface Reference Model).Suština IRM-a je u definisanju različitih standardnih interfejsa za svaku klasu
aplikacija. Pruza inteoperabilnost izmedju razlicitih sistema. Definise use case, interfejse i poruke u elektro
domenu. Objekti u IEC 61968 su bazirani na funkcijama u IRM-u. Bazira se na 14 poslovnih funkcija. Imamo
middlware servis koji se slaze sa standardima 61968 i 61970. Rad ovog modela mozemo podeliti na poslovne funkcije
koje upravljaju distribucijom i one koje ne upravljaju distribucijom. Sve komponente su povezane interfejsima.
Upravljanje distribucijom se svodi na: elektricnu dis-ju, planiranje, izgradnju, odrzavanje i operacije mreze, dok
funkcije koje nemaju veze sa distribucijom, njih cine: upravljanje proizvodnjom I prenosom, planiranje privrednih
resursa, korporativni servisi(finansije, kadrovsko).

39. CIM model razlika (Difference file).

IEC 61970-452- definise profil za razmenu statickih podataka. IEC 61970-452 definise CIM XML format za razmenu
podataka zasnovan Resource Description Framework (RDF) Schema.

CIM model razlika se sastoji od:

- Header - pomaze u pracenju i auditing-u verzija modela
- Preconditions - Uslov primene promena na modelu - zabog konkurentnog izvrsavanja - transakcione promene
- Forward diff - iskazi definisani u azuriranom modelu i nedefinisani u starom modelu.
- Reverse diff - definisani u starom modelu, a nedefinisani u azuriranom modelu.

CIM trenutnone definiše relacije sadržavanja na neki poseban način (containment relations).Implementacija može da
odluči koje relacije su relacije sadržavanja. Time je narušena interoperabilnost. Iz tog razloga je potrebno uključiti sve
objekte u kaskadno brisanje da bi se jednoznačno definisao način na koji izvorni sistem definiše kaskadno brisanje .
Brisanje elemenata mora sadržati sve atribute, radi mogućnosti vraćanja obrisanih elemenata. Promene mogu
zavisiti jedna od druge! Poslednje stanje se opisuje preko reverse.

Primer:
Operacije Insert Update Delete
Forward “insert data” “new value” /
Reverse / “old value” “insert data”
40. Proces integracija baziran na CIM-u.
-nije jedinstven proces, gotovo svaka integracija je specifična na svoj način
- osnovni koraci:
1. Kreiranje slučajeva korišćenja
2. Kreiranje sekvencijalnih dijagrama – ovde se predstavlja interakcija učesnika, sa naglaskom na redosled
i vreme izvršavanja akcija. Poruke koje se šalju mogu biti sinhrone, asinhrone ili odgovori na prethodno
poslate poruke
3. Pravljenje domenskog modela (definisanje CIM profila) – u ovom koraku za svaku poruku
identifikovanu u sekvencijalnim dijagramima je potrebno definisati sadržaj. To se zasniva na pravljenju
profila – definišu se klase, atributi i veze koje su potrebne za izvorni sistem, a zatim se to isto uradi i za
odredišni sistem.
4. Dizajn poruka (bazirano na definisanom CIM profilu) – ovde se prethodno definisanim porukama
dodeljuje konkretan payload (konkretni podaci koji će se razmenjivati između sistema)
5. Dizajn interfejsa – kada su završena prethodna 4 koraka u odnosu na njih je potrebno definisati dizajn
interfejsa za svaki sistem koji je uključen u integraciju. Mnoge današnje tehnologije za integraciju su
konfigurabilne tako da se ovaj korak svodi na izbor dizajna šablona i zapisivanje konfiguracionih
parametara
6. Kreiranje interfejsa – ovde se kreira interfejs u skladu sa dizajnom koji je prethodno definisan. Ukoliko
je dizajn detaljno opisan ne bi trebalo biti problema prilikom kreiranja. Koraci:
a. Konfigurisati alat za integraciju u skladu sa izabranim šablonom i definisanim parametrima u 2. i 5. koraku
b. Razviti procese koji će izvršavati definisanu logiku
c. Konstruisati komponente koje će izvršiti validaciju, transformaciju i translaciju
d. U izvorni repozitorijum staviti kod interfejsa, definicije poruka i bilo koje fajlove povezane sa interfejsom
e. Izvršiti unit testiranje i debagovanje
7. Upravljanje objektima – ako se ispoštuje prethodno navedena procedura postojaće dosta objetaka koji
će u celosti biti korišćeni kao interfejsi. S obzirom da se sistem stalno menja i nadograđuje potrebno je
pamtiti stalne promene. Najbolje je da postoji neki repozitorijum koji će sadržati sve te objekte koji će
trebati u budućnosti da se koriste. U idealnom slučaju ovaj repozitorijum bi trebao čuvati i različite
verzije ovih objekata

41. Metodologija za klarifikaciju zahteva i izbor tehnologije rešenja u okviru “Smart Grid” projekta.

Pravimo WorkShop iz kojih definisemo Use-Case-ove. Koraci(steps) name definisu sekvencu razmene poruka a to
nam u kombinaciji sa interfejsima definise matricu poruka koja se razmenjuje izmedju entiteta u sistemu. Ucesnici
nam definisu globalnu listu ucesnika, I u kombinaciji sa porukama dobijamo interfejse pa odatle imamo definisani
standardne kataloge i mapiranja. Na osnovu globalne liste ucesnika i zahteva dobijamo arhitekturu komponenti
sistema. Zahtevi nam definisu bazu zahteva koje u iterativnom postupku mozemo usavrsavati. Scenarija nam definisu
dijagrame aktivnosti (poslovne logike) i zahteve vezane za sigurnost(Security). Izlazi nam definisu : Model podataka,
analizu preformansi kao i izbore tehnologije, strukture sistema i uredjaja.

- kompletan use case se sastoji iz:

Dijagrama (nije neophodan ako postoji dosta detaljan opis u okviru dokumenta)
Dokumenta ili tabele sa detaljnim opisom
- slučajevi korišćenja treba da budu mapirani na prave softverske zahteve. Tri standardna dela:
Učesnici – tipovi ili klase korisnika koji su uključeni u sistem
Definicija softverskog sistema – sistem za koji se vrši integracija
Ciljevi – šta učesnici postižu koristeći sistem
- dva ključna pitanja:
Ko će koristiti sistem
Koje ciljeve će ostvariti koristeći sistem
- Pre-conditions – treba da budu zadovoljeni kako bi slučajevi korišćenja započeli
- Trigger – događaj koji inicira korake u slučajevima korišćenja
- Steps – koraci neophodni da se dostigne Success End Condition (kokak-po-korak proces koji se mora izvršiti
da bi se ostvario krajnji cilj)
- Post-conditions – stanje sistema nakon izvršavanja slučajeva korišćenja
Success End Condition – očekivano stanje koje treba da se pojavi posle uspešno izvršenog slučaja
korišćenja
Failed End Condition – očekivano stanje koje se pojavljuje ukoliko se slučaj korišćenja ne izvrši uspešno
- Extension steps – koraci koje se pojavljuju ukoliko nešto ne uspe u uspešnom scenariju (npr. neko klikne
Cancel)
- korisnik hoce da odradi integraciju OMS-a i DMS-a (pravimo odgovarajuce use case-ove)
- u okviru us-a provericemo bezbednosne scenarije, poslovnu vrednost koju tebi donosi, definisacemo
ucesnike, interfejse
- rezultat: use-case dijagrami, mapiranje izmedju interfejsa, definisana arhitektura => precisceni zahtevi
- moze se definisati model podataka, performanse, izabrati tehnologiju, strukturu, uredjaje
- sve se ovo radi iterativno (moze iskociti neki novi use case)

42. Tokovi podataka pri upravljanju promenama modela.

- promocija modela se odnosi na kompleksniji skup programa koji se koriste za izvršavanje QA-a (quality
assurance) prilikom importovanja podataka i planiranja koja se odnose na mrežu i sve to u cilju obezbeđivanja
održivosti modela, te visoke pouzdanosti i bezbednosti
- cilj procesa promocije modela je promocija promena izvršenih nad modelom u produkcioni sistem
- ključni deo ovoga procesa predstavlja sinhronizacija procedure prilikom koje se verzije modela u okviru DMS
Staging instance, DMS QA instance i DMS Production instance poravnavaju (Production zona je najsigurnija)
- ne moze zona nize sigurnosti da gura podatke u zonu vise sigurnosti! Moze se jedino iz zone vise sigurnosti inicirati
prenos podataka iz zone nize sigurnosti (samo podaci, nema izvrsnih fajlova)
- poredjenjem delti insert operacija dobijamo insert, update, delete operacije nad modelom. Jedan elektricni model,
vise grafickih modela.
-Planirane promene se nalaze u Production Zoni, promene koje se direktno verifikuju I potvrdjuju idu kroz QA I
Stagging

- tokovi podataka mogu biti:

1. Statički (električni i grafički)
[Corporate System ->] Staging DMS -> QA DMS -> PULL <- Production DMS
Production inicira replikaciju podataka iz Test I QA zone
2. Dinamički (status prekidačke opreme, izmerene analogne vrednosti, privremeni elementi i tagovi)
Production DMS -> QA DMS
Prenos podataka o trenutnom stanju kako bi se sto kvalitetnije izvrsio QA
-corporateSystem (CIS, GIS, EMS postave svoje izmene na neki dropbox. Obaveste adaptera koji javlja network
import servisu koji napravi delte i smesti ih u historical) -> date promene mozemo primeniti na QA.
-Mogući problem (brisemo jednu sekciju, a na njoj mi se nalazi neki element koji ce ostati nepovezan ako
obrisemo sekciju => zbog toga u transakciju ulazi Temporary Element Service koji proverava da li transakcija
sme da se izvrsi (ako ne sme, odbija tu transakciju), zato imamo sve ove dinamike na QA-u (ukoliko delta cini
stetu kompletnom modelu, ona ce biti odbijena))
- Simulation DMS (u PROD) – da bi operater bio siguran da ce promena proci, ovde vrsi jos jednu proveru
promene (ta provera se radi zato sto je sada promena u drugim uslovima, druga zona); QA rade ljudi koji nisu
operateri (model-koordinatori), dok u SimulationDMS-u rade iskljucivo operateri
U QA zoni se testiraju promene pre nego sto se prebace u produkciju.

43. Koncept jedinstvenog izvora podataka i konsekvence narušavanja ovog koncepta.

The single source of the truth concept(TSSOTTC) samo jedan sistem moze da bude (master
jednog entiteta modela) vlasnik podataka, samo njemu verujemo. Za izgradjenost mreze to je
GIS. U integrisanom sistemu, GIS sistem ima tipicno ulogu master-a u procesima unosa I
uredjivanja podataka distributivne mreze.
1. azurirana vrednost entiteta u modelu, bez spoljnih promena vrednost ostaje ista kao sto je
bila pre inkrementalnog azuriranja.
2. Bez promene na modelu, azurirana vrednost atributa entiteta spolja vrednost atributa
postaje spoljna promenjena vrednost
3. azurirana vrednost entiteta u modelu, azurirana vrednost entiteta atributa spolja, vrednost iz
modela se prepisuje.
4. entitet obrisan u modelu, azurirana vrednost atributa entiteta spolja izuzetak se javlja tokom
import operacije.
5. entitet obrisan u modelu, drugi entitet se konektuje na taj, javlja se izuzetak.
6. bez promena vrednosti atributa u modelu, entitet obrisan spolja entitet ce biti obrisan sa
svim drugim entitetima. Ako je nemoguce obrisati entitete, javice se izuzetak tokom operacije.
7. entitet obrisan u modelu, entitet obrisan spolja operacija ce biti preskocena tokom import
operacije.
Posledice ukoliko se narusi princip.

44. Dijagram stanja izvoda – Feeder-state diagram.

Promene se kreiraju u Source sistemu, zatim sledi Extract u CIM/XML-u, kreiranje changeset-a i primena u finalnom
modelu. U Source sistemu se kreira promena. Zatim sledi tranzicija u Extract(CIM/XML) tj prijem u sistem koji
obradjuje tu promenu(Recieved). Promena sa validira, ako je nevalidna prelazi u stanje Invalid salje se obavestenje
Source sitemu i prelazi se u stanje Obsolute(kako bi imali uvid u sve promene I javili Sourceu da ispravi gresku), a ako
je validna prelazi se u stanje Pending.Pending stanje ceka da stigne informacija o stanju oba zavisna fidera. Iz
Pending stanja se prelazi u stanje Used For ChangeSet i kreira se promena koja je u stanju Ready za primenu na
finalnom modelu. Zatim se promena ponovo validira(jer u slucaju planiranih promena moze proci i duze vreme od
prve validacije u Extract-u). Ako je nevalidna promena prelazi u stanje Rejected pa u Obsolute. Ako je validna ,
promena prelazi u stanje Approved pa u QA in Test (testiranje na replici sistema, samo tada je deo QA modela) zatim
sledi primena u Produkciji gde se vris takodje provera jer nema inverznih promena u slucaju postojanje bug-a ( i u
Extractu takodje) i u oba sistema promena prelazi u Archived stanje.
Primer: Imao fider i on se grana na dve strane, imaom switch-eve na njemu. Zadamo da se switch na jednoj strain
zatvori i prebacimo sav napon sa tog fidera na drugu polovinu. Ako su oba prekidaca zatvorena, napon se deli na obe
polovine.
DMZ(Staging,QA) - zona najmanje sigurnosti.Insert delta - svi objekti koji pripadaju datom feederu. Odnosom nove I
stare insert delte dobija se Difference delta.DMS je vodeci sistem u ovom slucaju, GIS ne zna da li je nesto
energizovano, on dobija samo potvrdu da je nesto uradjeno. Promee feedera su staticke.

45. Dijagram stanja planirane promene – Network-patch lifecycle.

Glavni znacaj NetoworkPatch-a je izmena nad modelom. Primena je uvek u produkcionom sistemu ali prmena moze
biti nedeljama ranije kako bi se sve pripremilo. U OMSu se uvek vrse promene stanje prekidacke opreme, ovde
govorimo o planiranim promenama statickog modela. Planirana promena se prvo vidi u GIS-u zatim se primenjuje na
QA sistemu(uzima se jeftiniji model, ali se vodi racuna i o bezbednosti). Promene u odnosu na pocetni plan se
modeluju preko TE.
Stagging & QA : NetworkBuilder izabere patch i zalkjuca ga za izmene. Dodaju se TE I validiraju je se Patch I TE-I. Na
kraju se sve sacuva na repou(promene su i elektricne I graficke).

Production: Izaberemo patch, energizujemo ga, i sklonimo iz liste operatera.

Patch dobijamo u obliku difference fajla. Energizacija patch-a se radi u produkcionoj zoni jer imamo odgovarajuce
SW planove za energizaciju(posalji posadu na tere, otvori SW, stavi na SW DoNotOperate, kada se posao odradi skini
tag i zatvori SW) - mora zbog SW plana biti u produkciji. Model mreze je poravnat sa produkcijom sto nam je I cilj.
As
F1 Proposed
Delta - Temporary Elemenri - As Build Promen
F1’
+
D1

Prazan skup ako nema As Build

promena
Source(GIS) sistem kreira planirane promene(vise feedera) i salje u Extract u vidu difference fajla. Prelazi se u stanje
Recieved. Vrsi se validacija (ako je nevalidan ide u Invalid pa Obsolute), ako je validan ide u Pending stanje(ako ima
vise patcheva koji su medjusobno zavisni). Pravi se changeSet. ChangeSet prelazi u Ready stanje, moze da se validira
u QA In Test rezultat moze biti Approved ili Rejected ali moze iz Approved ici na kreiranje SW plana - Approved for
SP. Promene se mogu approve-ovati I primeniti kasnije, kada se to desi, operator je u kontaktu sa posadom na
terenu I neposredno pre toga im moze odraditi simulaciju - SIM in Test ponovo moze da se Approve-uje I postaje deo
modela. Promena prelazi u In Prod stanje automacki i difference fajl prelazi u primenu u produkcionom
sistemu.Trenutno je on samo u Core-u, nakon sinronizacije prelazi u QA & Stagging - SYNCED. Nakon sinhronizacije se
prelazi se u COMFIRMED stanje i u ARCHIVED(automacki I diff fajl prelazi u Archived). Comfirm dovodi do toga da u
source sistemu stize potvrda da je patch usao u produkciju(tada je DMS-vodeci sistem za primenu promena) zato sto
patch kada je napravljen u GIS nije postao deo modela, kada se izvrsi GIS dobija notifikaciju da je primenjen I
primenjuje ga kod sebe.

46. Procedura sinhronizacije modela.

- krajnji korak u promociji modela
- pokrece se najcesce iz produkcije
- podrazumeva:
Promociju potvrđenih (approved) changeset-ova
Poravnanje verzija modela na DMS Staging, DMS QA i DMS Production instancama
- može da se pokreće automatski ili na zahtev model koordinatora
- proces sinhronizacije može da podrazumeva Network Patch-eve kao deo rešenja ali i ne mora
- nakon sto approve-ovani ti changesetovi, prva primena se radi na QA (i ako sve prodje kako treba, repliciraju
se na produkciju); ovo je bila prica u slucaju da imamo sve feeder update-e (bez patch-eva)
- ako imamo network patcheve (zone: STG, QA, PROD):
1. Stigli pecevi i direktno su primenjeni na produkciju => nisu sva 3 modela poravnata, produkcioni model je
vodeci
2. imam changeset-e u CSRepou u QA-STG (approve-ovani feederi); da bi oni mogli biti primenjeni na QA-STG,
moram prvo u QA-STG povuci peceve iz PROD i tek onda mogu primeniti changesetove (feedere) na QA-STG
model
-*** uvek je vodeci model PROD (prikazuje kako realni sistem stvarno izgleda)
- GIS je uvek vodeci model osim u slucaju da su primenjeni pecevi na PROD; onda DMS postaje vodeci i javlja
GIS-u da treba i on da primeni te peceve; GIS onda salje potvrdjujuce feeder-e DMS-u kroz changeset-e i
njihovom primenom se zavrsava posao primene peceva na DMS (GIS ponovo postaje vodeci)
47. Metodologija za definisanje zahteva i izbor tehnologije u Smart Grid projektima – “Use Cases” pristup.

Pravimo WorkShop iz kojih definisemo Use-Case-ove. Koraci(steps) name definisu sekvencu razmene poruka a to
nam u kombinaciji sa interfejsima definise matricu poruka koja se razmenjuje izmedju entiteta u sistemu. Ucesnici
nam definisu globalnu listu ucesnika, I u kombinaciji sa porukama dobijamo interfejse pa odatle imamo definisani
standardne kataloge i mapiranja. Na osnovu globalne liste ucesnika i zahteva dobijamo arhitekturu komponenti
sistema. Zahtevi nam definisu bazu zahteva koje u iterativnom postupku mozemo usavrsavati. Scenarija nam definisu
dijagrame aktivnosti (poslovne logike) i zahteve vezane za sigurnost(Security). Izlazi nam definisu : Model podataka,
analizu preformansi kao i izbore tehnologije, strukture sistema i uredjaja.

- kompletan use case se sastoji iz:

Dijagrama (nije neophodan ako postoji dosta detaljan opis u okviru dokumenta)
Dokumenta ili tabele sa detaljnim opisom
- slučajevi korišćenja treba da budu mapirani na prave softverske zahteve. Tri standardna dela:
Učesnici – tipovi ili klase korisnika koji su uključeni u sistem
Definicija softverskog sistema – sistem za koji se vrši integracija
Ciljevi – šta učesnici postižu koristeći sistem
- dva ključna pitanja:
Ko će koristiti sistem
Koje ciljeve će ostvariti koristeći sistem
- Pre-conditions – treba da budu zadovoljeni kako bi slučajevi korišćenja započeli
- Trigger – događaj koji inicira korake u slučajevima korišćenja
- Steps – koraci neophodni da se dostigne Success End Condition (kokak-po-korak proces koji se mora izvršiti
da bi se ostvario krajnji cilj)
- Post-conditions – stanje sistema nakon izvršavanja slučajeva korišćenja
Success End Condition – očekivano stanje koje treba da se pojavi posle uspešno izvršenog slučaja
korišćenja
Failed End Condition – očekivano stanje koje se pojavljuje ukoliko se slučaj korišćenja ne izvrši uspešno
- Extension steps – koraci koje se pojavljuju ukoliko nešto ne uspe u uspešnom scenariju (npr. neko klikne
Cancel)
- korisnik hoce da odradi integraciju OMS-a i DMS-a (pravimo odgovarajuce use case-ove)
- u okviru us-a provericemo bezbednosne scenarije, poslovnu vrednost koju tebi donosi, definisacemo
ucesnike, interfejse
- rezultat: use-case dijagrami, mapiranje izmedju interfejsa, definisana arhitektura => precisceni zahtevi
- moze se definisati model podataka, performanse, izabrati tehnologiju, strukturu, uredjaje
- sve se ovo radi iterativno (moze iskociti neki novi use case)
48. Sinhrona i asinhrona komunikacija.
Sinhrona komunikacija:
-Mora da bude brza, jednostavna
-Nije teska za odrzavanje
-Pouzdanost nije kriticna
-Aplikacije komuniciraju u real-time, Duplex: Salje se zahtev i ceka se odgovor
Asinhrona komunikacija:
-Spora
-Komplikovanija za odrzavanje
-Pouzdranost nije kriticna
-Komun. kanali mogu biti prekinuti, ali je isporuka garantovana
-Duplex: salje se zahtev, ne ceka se odgovor - bice obradjen kada stigne

Proces poslovne logike odredjuje nacin komunikacije. Poruke su po default-u asinhrone ako
ukljucuju queues i topike gde je jednosmerna komunikacija, tj. nema odgovora na njih. Web
servisi su po default-u sinhroni posto mogu da ukljuce odgovor u istom pozivu.

49. IEC 61968 glagoli za definisanje poruka (Verbs).

Request glagoli
GET – za dobijanje objekta čije tipove specificira poruka imenice
CREATE – za kreiranje objekata čije tipove specificira imenica
DELETE – za brisanje objekata. Ukoliko ima potrebe za čuvanje istorije objekat se nekada ne briše
potpuno iz sistema
CLOSE i CANCEL – podrazumevaju akcije koje se odnose na poslovne procese (zatvaranje objekata kada
se završi njegov životni ciklus u okviru uspešno izvršenog nekog poslovnog procesa)
UPDATE (isto kao CHANGE) – koristi se za modifikaciju objekata. Bitno je uočiti da može da dođe do
višeznačnosti usled biznis pravila, posebno kada pričamo o kompleksnim podacima koji npr. imaju veze
N:1 – tada je bitno obezbediti neki mehanizam tipa kaskadnog modifikovanja ili slično
Reply glagoli
- odgovor na svaki zahtev koristi REPLY glagol
- koristi se za objavu rezultata nekog eksternog zahteva (create, change, delete, cancel ili close)
- REPLY poruka može da sadrži neke dodatne informacije, u smislu da li je zahtev izvršen uspešno ili ne, te da
eventualno ponudi neke alternative za izvršavanje ukoliko je zahtev završen neuspešno
Event glagoli
- indikatori da se nešto desilo
- glagoli koji se koriste za događaje koriste prošlo vreme
- glagoli događaja su često posledica zahteva gde CREATE može rezultovati generisanjem CREATED događaja
CREATED – za objavu kreiranja objekta što može biti rezultat nekog eksternog zahteva ili neke interne akcije
CHANGED – za objavu izmene objekta
CLOSED – objava da je došlo do normalnog zatvaranja objekta
CANCELED – objava da je izvršeno CANCEL nad objektom
SHOW – objava trenutnog sadržaja nekog objekta. Najčešće mu prethodi zahtev GET
SUBSCRIBE – za slanje zahteva za objavljivanje izmena koje su nastale u objektu
UNSUBSCRIBE – za slanje zahteva da se prestane sa objavljivanjem izmena objekta
50. IEC 61968 imenice za definisanje poruka (Nouns).

Svaka imenica odgovara XML Schema, definisana koristenjem namespace-a jedinstvenog za svaku imenicu. Definise
se na osnovu use case-a. Imenice se koriste za identifikovanje tipa informacije koja se razmenjuje. Po potrebi,
imenice mogu biti definisane za razlikovanje drugacijih sadrzaja poruke. Imenice ne treba da budu definisane kao
klasa u UML-u, ali sadrzaj i struktura imenicese definisu pomocu klase, atributa i relacija u UML modelu.
Primeri imenica: NetworkDataSet, NetworkChangeSet, LoadDataSet, OperationalRestriction, SafetyDocument,
SwitchingSchedule, OutageReport, TroubleTicket, PlannedOutage, OutageNotice, Work, Schedule

51. Struktura IEC 61968 poruka.

Strutkura:
- Header - obavezan za
sve poruke, osim za fault message.
- Request - opcioni, kada trazimo nest
- Reply - odgovor, da naznaci detalje uspesnosti i/ili greske
- Payload - sadrzaj koji se prenosi.

Payload je potreban kada zelimo da kreiramo neki objekat, update ili kada trazimo objekat koji
postoji. Ne treba kada radimo uspesno create, update, delete pa u reply ne dobijamo payload.

Payload-postoje cetiri stereotipa: RequestMessage, ResponseMessage, EventMessage,

FaultMessage.
Potreban kod:
- CREATE request,
- UPDATE request,
- REPLY message za uspesan GET request
Nije potreban kod:
- REPLY message za neuspesni GET request,
- REPLY to a CREATE, UPDATE, DELETE, CLOSE, ili CANCEL,
- DELETE, CLOSE, ili CANCEL request zato sto se Id objekta definise u request-u
- GET request parametri su definisani u request delu

52. Predstavljanje vremena u skladu sa ISO 8601.

- ISO 8601 standard definiše reprezentaciju vremenskih vrednosti. Pokriva razmenu podataka koji su zasnovani
na datumu i vremenu
- cilj ovog standarda je da obezbedi nedvosmislen i dobro definisan metod za predstavljanje datuma i vremena.
Sve to opet u cilju sprečavanja pogrešnog tumačenja ovakvih podataka, naročito ako se podaci prenose između
zemalja sa različitim konvencijama za format datuma i vremena
- ovo prevazilazi problem u vezi sa vremenskim zonama
-opšta pravila:
Vrednosti datuma i vremena se ređaju od najvažnijeg do najmanje važnog – godina, mesec (ili nedelja),
dan, sat, minut, sekund i deo sekunde
Svaka vrednost vremena i datuma ima fiksan broj cifara tako da ukoliko je potrebno treba dodavati
nule na početak
 Postoje dve reprezentacije:
1. Osnovni format – sa minimalnim brojem separatora (20090106)
2. Prošireni format – sadrži separatore koji poboljšavaju čitljivost (2009-01-06)

Da bi se smanjila preciznost bilo koji broj vrednosti može da se ukloni iz formata ali sve dok ostaju
zapisani svi na važnijoj poziciji od njega
Što se tiče vremena koristi 24h format i takođe ima osnovni i prošireni format, gde je za prošireni
separator ’’:’’
Za označavanje zona se može koristiti Z kao 0 ili odgovarajuća zona sa predznakom +/- opet u
osnovnom ili proširenom formatu
Kada treba spojiti vreme i datum samo se doda T između njih. Tada može da se koristi osnovni ili
prošireni format ali je bitno da i jedno i drugo koriste isti
- timestamp iz poruka koje šalju klijenti može da koristi bilo koji ISO 8601 kompatibilan timestamp
-Timestamp format: 2009-03-05T14:00:00-06:00
-kada pisemo neke podatke, upisujemo serversko vreme, a ne klijentsko (klijent je previse labav da bih se
oslonio na njega => stavlja se serversko vreme i zona[time-06:00] => jednoznacno oznacavanje vremena)

53. SLA.
Predstavlja formalno definisani ugovor izmedju 2 ili vise servisa gde se zna koliko je garantovano vreme izmedju 2
ispada I koliko je vreme da servis uspostavi funkcionalnost. Koliko je garantovano vreme da ce servis biti dostupan od
90% do 100%. Postoje razliciti nivoi nedostupnosti. SLA tipicno ima definicije MTBF(Mean time between failures) i
MTTR(Mean time to recovery). Raspolozivost je povezana sa pouzdanoscu sistema I onda se definise kao
MTBF/(MTBF+MTTR), gde je MTBF srednje vreme izmedju dva ispada, a MTTR srednje vreme potrebno za oporavak.
Pouzdanost sistema je verovatnoca da njegovog ispravnog funkcionisanja u datom vremenskom periodu pri
definisani uslovima rada. Ako je sistem pouzdaniji MTBF ce biti veci pa ce raspolozivost sistema biti veca.

SLA(Service Level Agreement) tj. ugovoreni nivo usluga, predstavlja dogovoreni i obavezujuci nivo usluga izmedju
onoga ko isporucuje servis(Service Provider) i korisnika-dokumentovani ugovor koji opisuje nivoe usluga i njihovu
cenu. Incident-neplanirani prekid u radut IT servisa ili neplanirano smanjenje kvaliteta rada servisa.
Stavke koje se nalaze u SLA: opis servisa, vreme rada servisa, vreme odgovora na incidente, vreme resavanja
problema, odgovornosti klijenta, period za koji se potpisuje ugovor.

54. Različiti pristupi pri implementaciji Web Servisa.

WSDL - jezik za opis Web Servisa baziran na XML-u. Glavni elementi u okviru WSDL-a:
- tipovi podataka - definicija tipova podataka koji se razmenjuju. Preporucuje se upotreba XSD-a za definisanje tipova
podataka
- poruke - koje koriste Web Servisi. Svaka poruka se sastoji od naziva i opisa. Moze imati 0 ili vise delova.
- operacije - koje Web Servis moze da izvrsi. Ovo predstavlja interfejs web servisa. Definisu se operacije I poruke koje
se pri tome razmenjuju. Tipovi operacija mogu biti
- one-way - salje se zahtev i ne ceka se odgovor.
- request-response - salje se zahtev I ceka se odgovor
- solitic-response - ceka se odgovor pa se tek onda salje zahtev
- notification - obavestenje(ceka se odgovor)
- protokoli - za komunikaciju sa web servisom - definise se konkretan protokol HTTP, SMTP ili neki novi i format
podataka za portType. Binding element ima dva atributa: ime - definise ime, type - ukazuje na port.

Web 1.0 - web stranice sadrze informacije ili pruzaju informacije. Jedini nacin na koji su korisnici mogili da koriste
takvu vrstu web sajtova jeste pregledanje njihovog sadrzaja. Vremenom stvorila se potreba da korisnici na razlicite
nacine ucestvuju u postavljanju I menjanju sadrzaja. U 2.0 nema poruke, jer sam interfejs podrzava poruke.

WSDL definise web servis kao skup portova I krajnjih tacaka. KOristi se kombinacija SOAP i XSD za pruzanje usluga
web servisa. Klijent koji se kaci na web servis moze da cita wsdl fajl kako bi video koje opcie servis pruza. Tipovi
podataka definisani su u XSD-u. Transfer se vrsi preko HTTP-a. Klijent moze da koristi SOAP za pozivanje neke
operacije servisa.
SOAP- komunikacioni protokol za opis poruka izmedju aplikacija- definise format poruka za komunikaciju. Najcesce
koristi HTTP.

SOAP poruka - XML koji ima sledece delove:

- Envelope element - obavezni deo - identifikuje XML kao SOAP poruku.
- Zaglavlje
- Telo - informacije i parametri - obavezno
- Fault element - opcioni, pruza informacije o tome sta treba uraditi ako dodje do greske.
SOAP koristi XML i HTTP kako bi se obezbedila komunikacija ne zavisna od platforme.
Strongly typed web services (STWS)- imamo predefinisane reci koje trebaju da se zamene. Ime operacije = glagol +
imenica. Brza obrada poruka. Definisana operacija. Imamo predvidjene wsdl templejte
Koristi se SOAP. Servis sadrzi kompletnu definiciju ulaznih i izlaznih poruka u XML schema. Jedina informacija koju
potrosac I provajder servisa moraju da razmene je wsdl.

Generic web services (GWS)- imamo 1 xsd koji sluzi za sve poruke tj. 1 xsd se koristi u svim wsdl. Ge Noun(deo
parametra). Nisu strongly typed. Omogucuju da se poruke rutiraju koristeci notaciju postavljenu unutar poruke. XML
uvek u istom obliku. Operacije: request kada je potrebno dobiti informaciju, response kod asinhronog odgovora,
public event koji se salje mogu da imaju podrazumevan odgovor. Bilo kakva kombinacija imenica I glagola je
dozvoljena. Jedan XSD za sve poruke - ne zahteva se modifikacija .xsd fajla.

55. ESB Request-Reply integracioni šablon.

- ESB (Enterprise service bus) je model arhitekture softvera koji se koristi za dizajniranje i implementaciju
komunikacije između aplikacija (u server-orijentisanoj arhitekturi) koje su u interakciji.
- poenta korišćenja ESB-a je u integraciji različitih aplikacija. Između aplikacija se stavi ESB i onda se omogući
svakoj aplikaciji sa komunicira sa njim
na ovaj način je omogućeno nezavisno komuniciranje sistema bez potrebe za dodatnim znanjima o drugim
aplikacijama povezanim sa ESB-om
- korišćenjem ESB-a povećava se skalabilnost, jer je lako dodati nove aplikacije i samo ih povezati sa ESB-om,
bez potrebe da se povezuju sa svakom pojedinačnom aplikacijom u sistemu
- podaci koji putuju kroz ESB su u kanoničkom formatu (najčešće XML) i to je dogovor između aplikacija. To
znači da kroz ESB putuje samo jedan tip poruke i da svaka aplikacija zna da interpretira taj format
- ne postoje globalni standard koji implementira ESB, nego samo postoje provajderi koji taj koncept koriste
-ESB određuje da li je poruka validna i radi detaljnu analizu poruka
-ESB posreduje u komunikaciji client-server (esb procesira sadrzaj poruke, prosledi serveru, server procesira pa
vrati poruku esb-u sa corellationID, esb to procesira, rutira i vraca klijentu)
- prednost ESB-a: svi adapteri su u ispravnom stanju, security (pravo pristupa), rutiranje (laka zamena servera)
- tipicne mogucnosti ESB-a: logovanje svega, generisanje ID-a i potpisa, autentifikacija/autorizacija,
identifikacija instance online servisa, nezavistan od OS, podrzava integracione paterne, slabo spregnuti sistemi,
orkestracija vise servisa, security, mogucnost koriscenja CIM-a za razmenu informacija.
-Svaka komunikacija koja koristi ESB je asinhrona. CorrelationID povezuje odgovor I zahtev. Adapteri prilagodjavaju
poruke - transformisu podatke
-ESB sadrzi: Queue(garantuje redosled isporuke poruka), Topic(ne garantuje redosled poruka, Pub-Sub),
DeadLatterQueue - za izgubljene poruke
Bez ESB-a možemo imati sledeći slučaj:

56. Request-Reply integracioni šablon uz oslonac na adaptere.

- adapteri se uvode da ako se izmeni nešto na ESB-u to ne utiče na ostatak sistema
- posledica ovog su slabo spregnuti sistemi
- adapter se postavlja između ESB-a i aplikacija i njegovo zaduženje je da prikuplja podatke između dve strane
- adapter je odgovoran za komunikaciju sa krajnjim aplikacijama – transformiše podatke iz formata aplikacije u
format ESB-a
- adapteri takođe mogu da se pozabave aktivnostima koje se odnose na rutiranje poruka, bezbednost, praćenje
i upravljanje greškama
npr: Adapter konvertuje klijentske poruke u CIM poruke da bi do ESB-a stigle CIM poruke koje kasnije mogu da
saljem na server;
- Adapter izmedju ESB -a i server (konvertuje CIM poruke na ESB -u u serverski format poruke)
57. Integracioni paterni.

Basic Request-Reply using WS

- trudi se da ostvari sinhronu komunikaciju
- odma se javlja da je poruka obradjena

Basic Request-Reply using JMS

- komunikacija između klijenta i servisa se odvija preko ESB-a po principu slanja zahteva klijenta serveru koji
potom šalje odgovor klijentu
- JMS (Java Message Servis) – standard razmene poruka koji omogućava kreiranje, slanje, primanje i citanje
poruka u okviru aplikacija koje su zasnovane na Java platformi. Omogućava pouzdanu asinhronu komunikaciju
- mogući načini implementacije JMS-a su:
1. I Request i Response se organizuju u redove – ’’Point-to-Point’’
2. I Request i Response se organizuju u topice – ’’Publish-Subsribe’’
- poenta je da ako se koristi red onda znači da je ta poruka isključivo namenjena jednom primaocu tako da će je
samo on i dobiti. Kod topic-a je drugačija situacija – svi koji su se pretplatili dobijaju poruku
- ovde se radi uz pomoć reda jer se smatra da kada se pošalje zahtev ta poruka je zapravo nekom konkretnom
upućena. To je i najčešći način implementacije JMS-a. Red je dobro koristiti kada je bitno da poruka bude
obrađena i dostavljena nekome – red to garantuje
- jms client salje request na jms topic (servis mora da ima jms interface), reply direktno na jms client

Basic Request-Reply using JMS Topic

- klasičan PubSub odnosno više klijenata je pretplaćeno na neki servis. ESB kontroliše saobraćaj, a može da vrši
i rutiranje poruka (određivanje puta/rute poruke kroz mrežu)
- kada se koristi topic poenta je sledeća – objavi nešto, svi koje zanima će to videti. U ovom slučaju na neku
objavu može biti nula ili više pretplaćenih što predstavlja problem ukoliko je potreban odgovor. U opštem
slučaju kada se koristi topic odgovor se ne očekuje. Topic takođe ne garantuje redosled slanja poruka
Content-based routing using jms – rutiranje na odgovarajuci topic, server sa tog topica dobija zahtev (moze da
odgovori direktno na tog klijenta ili da se subscribe-uje na drugog klijenta)

Basic Request-Reply using WS & JMS

- ovde se uvodi pojam Web Server-a koji takođe može da komunicira sa servisom tako što se putem proksija’’kači’’
na neki topic ili ruter

- u ovom slučaju postoje tri mogućnosti pristupa serveru:

1. Adapter i non-compilant interfejs
2. Adapter i WS interfejs
3. JMS interfejs

Smart proxy – radi se proxy koji salje na odgovarajuci topic; server moze da uradi reply na tog klijenta preko
istog proxy-a. Smart proxy- konvertuje zahtev i prosledjuje topiku/queue-u. Topic != queue. Svaki klijent ima svoj
queue. Smart proxy presrece poruku poslatu na request reply service. Za svaku nadolazecu poruku, smart proxy cuva
povratnu adresu definisanu od strane originalnog posiljaoca. Potom zamenjuje povratnu adresu u poruci sa kanalom
gde smart proxy slusa. Kada odgovor na poruku stigne do smart proxy-ja, smart proxy pronalazi skladistenu adresu i
koristi message ruter da prosledi nemodifikovani reply na datu adresu. Za komunikaciju ka WS klijentima
(kombinacija WS i JMS), Na ESB-u nam treba WS interface tu je proxy koji prosledjuje poruku na topic pa se vrsi
rutiranje na drugi topic. Replay moze ici ili preko proxy-a ili direktno.
proxy, router, adapter – za razliku od prethodnog ovaj servis ima WS INTERFACE (odgovarajuci adapter mora
biti definisan na esb-u, prilagodjava pristigle poruke)
- moguce varijacije na temu (topic, rutiranje, web servisi ekspozovani na razlicitim mestima, jms interface)!!!
- content-based router - rutiranje poruke bazirano na sadrzaju (XPath)
- smart proxy – preusmeri poruke na neku destinaciju i da prosledi odgov odgovor klijentima
- claim check – cesto koriscen kod integracije sa GIS-om. Ne salje se direktno veliki file vec samo javim klijentu da
sam ostavio fajl na nekoj lokaciji(FTP,SFTP)
- transformation – XSL transformise xml u pdf, html i slicno
- bridge – poruka objavljena na neki topic ili queue moze se proslediti na neku drugu strukturu tako da poveze
ta 2 sistema - za sisteme koji nisu direktno povezani na esb.

58. Karakteristike i benefiti korišćenja ESB-a.

Karakteristike: loguje poruke, generise identifikatore, generise potpise poruka, vrsi identifikaciju online service
instancu tj. koji je aktivan.

ESB dozvoljava da vise aplikacija komuniciraju sa razlicitih platform. Podrzava integracione paterne, upotreba CIM-a
za razmenu infomacija.
Radi bezbednosne provere kada aplikacija komunicira preko adaptera kao i odgovarajuce rutiranje. ESB radi
monitoring kompletnog saobracaja, prikazivace stanje aktivnosti adaptera.
Ako neko posalje poruku na pogresnu adresu, ESB ce to interno smestiti sto ce operater posle moci da pogleda.
Omogucava interakciju tj. objedinjavanje citavog sistema kao I da radi autentifikaciju. Pomocu ESB lako se radi load
balancing(rukuje opterecenjem serverskih stanica tako da se resursi koriste optimalno, optimizacija koriscenja
resursa, veca propusna moc, minimiziranje propusnog odziva, izbegavanje preopterecenja nekog resursa).

59. ICT standardi korišćeni u Smart Grid-u.

external-sluze za komunikaciju izmedju 2 udaljena sistema, nisu unutar istog objekta istog sistema i tako to, sluzi za
komunikaciju sa ostatkom sveta. internet protokoli (ip, tcp, udp, www)
enterprise-unutar preduzeca sta se koristi, iec 61970 968, web servisi i multispeak.
ima cis, gis..
wan-sonet(sinhrono opticko umrezavanje), wdm(multipleksiranje),satellite, microwave, dnp3. wan je 1 celina, okrug.
field lan-lokalna mreza na terenu, na recimo jednom vodu.
bpl/plc, adsl, cellular(mobilna mreza), cable(kablovska mreza).
han-zigbee, wifi, BACnet(automatizacija izgradnje i kontrola mreze)

Enterprise sistem: CIM standard i GDA (generic data access), SOAP i Web servisi, kroz CIM komuniciramo
sa kontrolnim centrom(postoje i ebXML, CIM/GID)
- kontrolni centar: kroz DNP3, 61850, ICCP komunicira sa uredjajima u polju (mernom opremom)
- merna oprema (SCADA) komunicira preko WiMAX, CDMA, GPRS, Microwave, SONET, optickim putem
- substation komunicirapomocu DNP3, 61850
- asset management nema neki standard
- vetrogenerator pomocu 61400-25
- sami potrosaci (Home Area Network) pomocu WiFi, Zig bee (adhoc protocol koji se uspostavlja sa prvim
susednim uredjajem)
- Distributed Resources (distribuirani uredjaji) pomocu 61850-7-420
- komercijalne usluge pomocu OpenADR

60. Multispeak specifikacija.

MS je specifikacija(nije standard kao CIM) automatizacije poslovnih procesa I razmene podataka izmedju soft.
Aplikacija koje se primenjuju u manjim jutilitijima(manja preduzeca) u NA. Specifikacije detaljnije opisuje kako MS
standard treba primeniti. Definise interfejse I strukturu poruke. Naglasava izbore protokola koji treba da se koriste u
implementaciji interfejsa I uspostavlja smernice kako izabrana tehnologija treba da se implementira da bi proces
integracije bio efikasniji. MS se oslanja na veb servise za integraciju, zato sto manja preduzeca nemaju
implementiran middlware poruka(ESB). Napravljen je od strane NERCA, za def modela distributivne mreze I razmenu
podataka izmedju aplikacija koje upravljaju tom mrezom-integracija aplikacija, CIM modeluje siri spektar. Oba su
fokusirana na slabo spregnute integracije, imaju model u kome se radi transformacija u CIM ili Multispeak, XML
poruke imaju predefinisani sadrzaj. U CIM-u imami header, imenice, glagole. MS se oslanja na WS(dve aplikacije,
svaka ima svoj interface, direktno povezane). Predefinisa WSDL I on im definise endpointe I poruke, MS moze da
prodzi i ekstenzije kod IO testova se one odbacuju(RDFS

mspObject osnovna klasa (IO je u CIM-u)

mspSwitchingDevice -
mspLineObject -
- mspConectivityLine
-mspElectricLine
Primary = SN, Secondary = NN
-ohPrimary/SecondaryLine
-ugPrimary/SecondaryLine
mspResultBase - proracuni tokova snaga I struje krathih spojeva.
mspPointObject
-mspConectivityPoint - spojna tacka
- mspMotorGenerator - motori ili generatori
-mspElectricPoint
-mspBankObject - skup objekata (tf,prekidaca,gang)
-stanica,feeder,fakeNodeSection,serviceLocation
mspDevice
-meter

61. Poređenje CIM i Multispeak.

- CIM pokriva mnogo siru oblast

- CIM i Multispeak opisuju integraciju
- oba modela se oslanjaju na slabo spregnute integracije i oba modela se oslanjaju na xml poruke
- Multi ima predefinisane web servise (s obzirom da mali utility nemaju esb-ove)
- objekti u multi hijerarhiji: dosta manje od CIM-a; nije modelovan visoki napon zato sto je Multispeak
modelovan samo za distribuciju; ne modeluju unutrasnjost stanice, imaju feedere i meter-e
- svi interfejsi su realizovani kroz web servise i na osnovu toga mogu da se definisu odgovarajuci serverski i
klijentski adapter (reuse adaptera)
- Multispeak procesni model: ucesnici (finansije, naplata, load prodiles, outage detection, outage analysis, gis
[source podataka za sve sisteme])
-3 vrste razmene poruka koje Multispeak definise: batch files, request-reply, pubsub
- imaju dobre IOP testove
- Multispeak ne modeluje terminale(CIM ih modeluje jer napon na krajevima sw na dva terminala nije isti, struja
jeste) on postvai neko merenje na prekida, dogovorom se zna na kojoj strani je postavljen prekidac.
Mutispeak model konektivnosti dis. mreze koja omogucava razmenu informacija I interoperabilne testove, dok CIM
obuhvata mnogo vece podrucje. Multispeak dobije gotove wsdl, to implementiraju i rade interoperabilne testove.
CIM obuhvata proizvodnju, distribuciju i potrosnju, dok je Multispeak orijentisan samo na distribuciju.

CIM protokol poruka definise standardizovan header poruka, imenica/glagol definicije operacija I payload xml poruke.
MS se oslanja na veb servise za integraciju jer manja preduzeca nemaju implementiran middlware poruka. MS je
fokusiran na standardizovane implementacije koje mali jutilitiji mogu da iskoriste prakticno nepromenjene. MS
profile podrzavaju ekstenzije koje nisu uzete u obzir za interoperabilne testove.

Domen CIM MS
ModelManagment EA XMLSpy nekada, sada EA
Nameing Nameing klasa (jedan obj vise imena) mspObject -> objectId
Hierarhija klasa Paketi Nema paketa
Veze Agregatori Banks(gang/non gang operated)
Konektivnost Section-Oriented Section & Node - Oriented
Asset Equipment ima vezu ka asset pod. Banks
Grafika Atributi vezani za lokaciju GML - GeoXML
Prednosti Dobor definisani interfejsi Parcijalni prenos podataka pomocu
difference fajlova

62. Model distributivne električne mreže u ArcGIS-u.

ArcGIS je geografski informacioni sistem(GIS) za rad sa

mapama I geografskim informacijama. Koristi se za:
stvaranje i upotreba mapa, prikupljanje geografskih
podataka, analiziranje mapiranih informacija, deljenje i
otkrivanje geografskih informacija, upravljanje geografskim
informacijama u bazi podataka.
Geometric network je skup povezanih grana i cvorova,
zajedno sa pravilima povezivanja koji se koriste da
predstave I modeluju ponasanje osnovne infrastructure
mreze u realnom svetu. Nad Geometrijskom mrezom se
automacki generise Logicka mreza zbog traceinga -
pripadnost nekom feederu u NUS. GIS : topologija je nasa
konektivnost

Edges-grana ima svoju duzinu kojom nesto tece(gas, voda, struja). Grana je kreirana iz klase Line u nekom skupu
podataka I odgovara granama u logickoj mrezi.
Junctions-cvorovi omogucuju da se 2 ili vise grana spoje cime se olaksava prenos izmedju grana. Cvorovi su kreirani
od klase Point u nekom skupu podataka I odgovaraju cvorovima u logickoj mrezi.
Jednostavne grane-uvek povezane sa 2 cvora, po 1 na svakoj strain. Ne mogu se podeliti na 2 nove sekcije ubacivanje
Junctiona(mora se brisati sekcija i ubaciti nove).
Kompleksne grane-su povezane sa najmanje 2 cvora. Mogu se podeliti na 2 nove sekcije ubacivanje Junctiona.

Source - izvor, u distributivnim mrezama je to VN/SN TS, DER-ovi

Sink - u distributivnim mrezama je to SN/NN transformatori, industrijski potrosaci
Source & Sinks - mozemo da definisemo orijentaciju mreze.
Svaka grana ima svoju tezinu - moze biti npr. Protok kroz cev, cena prenosa, faznost, najveca upotreba u saobracaju
(tezina = broj traka).