Av Maren Istad og Henning Taxt, SINTEF Energi AS

Transkript

1 Av Maren Istad og Henning Taxt, SINTEF Energi AS Sammendrag DeVID-prosjektet (Demonstrasjon og Verifikasjon av Intelligente Distribusjonsnett) sitt hovedmål er å bidra til verdiskaping ved hjelp av kostnadseffektive løsninger og økt produktivitet for nettkunder, nettselskap og leverandørindustri. Dette skal skje gjennom utvikling, demonstrasjon og verifikasjon. Demonstrasjon skal skje i demonstrasjonsområdene Smart Energi Hvaler og Demo Steinkjer. Et av verktøyene som er valgt for å oppfylle prosjektets mål er use case. I denne rapporten vil use case metodikk gjennomgås og eksempler på use case i DeVID-prosjektet bli presentert. En viktig del av DeVID-prosjektet er testing og demonstrasjon. En metodikk som er valgt for å få gjennomført testing og demonstrasjon er use case metodikk. Denne rapporten forklarer kort hva use case er og viser eksempler på use case hvor bruk av data fra AMS og nettstasjonsovervåkning er beskrevet. Testing av use case pågår i Demo Steinkjer og Smart Energi Hvaler og noen eksempler på tester er også inkludert i rapporten. Use case er et hjelpemiddel som først ble tatt i bruk av IT-bransjen i utvikling av ny programvare [1]. Use case egner seg spesielt til kommunikasjonen mellom brukerne av programvaren, som kjenner behovene som skal dekkes av programvaren, og programutviklerne som ikke har kjennskap til bransjen, men som skal svare på behovene gjennom utviklingen av programvare. Use case er tatt i bruk i utviklingen av Smart Grids, blant annet som et hjelpemiddel for å kartlegge behov og potensiale knyttet til ny teknologi. Ved å konkretisere hvert use case, blir kravene til informasjonsflyt, interoperabilitet og sikkerhet tydeliggjort. Videre vil slike use case danne et grunnlag for hvilken hardware- og software-arkitektur som best støtter de behovene og mulighetene bransjen har. I USA er det gjort et arbeid for å beskrive smartgrid use case, og disse er samlet 33

2 av EPRI [2]. I IEC har det vært arbeidet fram en standard for bruk av use case [3]. Denne er oversatt til norsk, og benyttes i DeVIDprosjektet. Use case-malen inneholder følgende deler: Beskrivelse av use case inkludert tittel, forfatter og versjonsnummer og mål med use caset. Skisse av use case i form at et diagram som viser hvilke aktører og handlinger som er med i use caset. Diagrammet er en grafisk fremstilling av de ulike stegene som realiserer use caset. Tekniske detaljer i form av liste over aktører som involvert i use caset. Dette kan være personell, roller, systemer, komponenter eller applikasjoner, og alle aktørene er beskrevet i denne listen. Videre er forutsetninger, antakelser, hendelser og referanser som er relevant for use caset beskrevet. I delen use caset steg for steg beskrives de ulike scenarioer i use caset, med involverte aktører, utløsende hendelse og tilstander ved start og slutt. Videre blir hvert enkelt scenario beskrevet stegvis. Informasjonen som utveksles mellom aktørene er en del av beskrivelsen. Informasjon som utveksles mellom aktørene i use caset beskrives i detalj. Dette gir, sammen med krav-spesifikasjonen, en oversikt over hva use caset krever av systemet og komponenter for å fungere som tiltenkt. I DeVID-prosjektet er det utviklet en samling av use case, se eksempel i Figur 1. Disse er basert på innspill fra partnerne i prosjektet og er valgt ut fra en vurdering å nytte og gjennomførbarhet. De prioriterte use casene danner grunnlaget for tester som nå gjennomføres ved demostedene Smart Energi Hvaler og Demo Steinkjer. I kapitlene under er tre eksempler på use case beskrevet. 34

3 Målet med use caset Verifisere nettdokumentasjon ved hjelp av spenningsmålinger med AMS er å kunne benytte målinger av forbruk og spenning til å verifisere om dokumentasjonen av nettet stemmer. Forutsetning for testing av use case er at feil i nettdokumentasjon gir avvik mellom målt og spenning beregnet i eksempelvis Netbas. Testing av Use Case skal avdekke hvor store avvik ulike feil i nettdokumentasjon gir, hvilke feil denne metoden kan avdekke og hvilke feilkilder som er aktuelle. Metoden baserer seg på å sammenligne to sett av spenningsverdier, sett A og sett B, på enkeltkundenivå. Sett A er fra en lastflyt som er beregnet med følgende input-data: Impedansmatrise fra nettinformasjonssystemet (NIS), for eksempel Netbas Gjennomsnittlig aktiv effekt for alle sluttbrukere hentet fra AMS Gjennomsnittlig reaktiv effekt for alle sluttbrukere hentet fra AMS 35

4 Gjennomsnittlig spenning målt i eller nær transformator mot overliggende nett Sett A av spenningsverdier, som er resultat av denne lastflyten, sammenlignes med sett B som er målinger av gjennomsnittlig spenning hos hver sluttbruker i samme tidsintervall. Det skal være gjennomsnitt av tre linjespenninger. Avvik mellom spenningene A og B kan skyldes en eller flere av følgende grunner: Impedansene som er dokumentert i NIS stemmer ikke med det som faktisk er i nettet (tverrsnitt, lengde..) Målingen av aktiv eller reaktiv effekt hos sluttbruker er feil Det er umålt forbruk i kretsen Kunden er ikke tilknyttet på samme sted som angitt i dokumentasjonen I tillegg er det noen feilkilder i metoden som kan gi opphav til feil: Enfase-kunder er vanskelig å ta hensyn til i metoden og vil gi unøyaktigheter. En stikkledning til en en-fasekunde vil, dersom lastflyt beregnes med trefaselaster, gi et spenningsfall over stikkledningen som avviker med en faktor 3 Hvis det kun måles to linjespenninger hos kunden kan dette være en feilkilde ved usymmetrisk last Reel temperatur for ledere er ikke mulig å angi nøyaktig i lastflytberegning. Avviket i beregnet spenning vil være cirka 0,3 % per C feil angivelse av temperatur Sammenligning av spenningene A og B må gjøres for flere perioder med ulike lastforhold for å avdekke systematiske avvik. Eksempler på beregning som viser hvilket utslag ulike avvik mellom dokumentasjon og virkelighet kan gi er gitt under. Sammenligning med målte spenninger vil gjennomføres ved Demo Hvaler. 36

5 Eksempel 1- Feil kabeltverrsnitt i nettdokumentasjon: En kabel på 100 meter er dokumentert i nettinformasjonssystemet som 150 Al kabel. Faktisk kabel er 95 Al. I dette tilfellet vil avviket i spenning mellom sett A og sett B bli 0,0286V per kw forbruk som forsynes gjennom stykket. Dersom forbruket i en time er 35 kw, vil det gi 1 volt avvik mellom sett A og sett B. Eksempel 2 - Feilmåling av forbruk: En stor kunde har en konsekvent feilmåling. Forbruket måles 33 % lavere enn faktisk forbruk. Kunden forsynes via 100 meter 150 Al kabel. I dette tilfellet vil avviket i spenningen i sett A og B bli 0,0215 V per kw faktisk forbruk. Dersom kunden en gitt time trekker en effekt på 100 kw vil avviket mellom spenningene bli cirka 2,15 V. Eksempel 3 - Forbruk som ikke er dokumentert: Det hender at sluttbrukere er tilknyttet et annet sted enn det som er oppgitt i dokumentasjonen. En sluttbruker, kunde 1, er tilknyttet nettstasjon NS1 i følge dokumentasjonen. I virkeligheten er kunde 1 tilknyttet NS2. Ved analyse av lavspenningskretsen forsynt av NS1, vil kunde 1 vises med et tilsynelatende vilkårlig avvik i spenning, fordi spenningen som måles hos kunde 1, i realiteten bestemmes av lastforholdene i NS2. For andre sluttbrukere i samme forsyning vil spenning fra lastflytberegningen bli litt lav enn om kunde 1 ikke var tilknyttet. 37

6 Ved analyse av lavspenningskretsen NS2, vil forbruket til kunde 1 mangle i lastflytberegningen og gi et spenningsavvik. Dersom denne sluttbrukeren deler forsyning over en 100 meter 150 Al kabel med andre sluttbrukere vil de andre sluttbrukerne vises med et avvik på 0,0939 V per kw effekt som kunde 1 trekker. Dersom kunde 1 i en gitt time har et forbruk på 10 kw, vil det gi et avvik på 0,939 V. Raskere håndtering av feil i nettet er et av områdene av nettdriften hvor det kan identifiseres store gevinster. Per i dag er det kun feil i høyspenningsnettet som gir KILE-kostnader for nettselskapet, og dette er derfor et naturlig fokus. Et overordnet use case, som beskriver hvordan håndtere feil og avbrudd i HS-nett består av følgende steg: oppdage feil, lokalisere feil, opprette alternativ forsyning og utbedre feil. Hvert av disse stegene kan løses ved hjelp av ulike og til dels komplementær sub-use case. Et av disse sub-use casene er lokalisering av feil i HS distribusjonsnett vha strømmålinger. Dette use caset benytter målinger av kortslutningsstrømmen i transformatorstasjonen og informasjon om impedansene i nettet til å lokalisere sannsynlig feilsted. Dersom det er flere avgreininger på avgangen med feil, vil kortslutningsindikatorer i forgreiningene kunne bidra til å lokalisere feilen. Use caset har blitt testet av Fredrikstad Energi Nett i 18 kv luftnett på Hvaler. Foreløpige resultater viser at metoden i de fleste tilfeller gir en god feillokalisering innenfor en feilmargin som er uproblematisk til de fleste praktiske formål. Noen observasjoner som er gjort så langt: På grunn av impedans i feilstedet vil faktisk feil ofte være nærmere enn det som er beregnet feilsted. Det er ikke kortslutningsindikatorer med fjernavlesning på de avgangene det er gjort tester. Derfor har det vært flere mulige feilsted som resultat av beregningen. Dette er et problem bare dersom det er lange avgreininger fra "hovedradialen". I området use caset er testet er det nesten bare luftlinje. Det er ikke testet hvor godt metoden fungerer i kabel- og blandet-nett. Et use case med tittel Vurdere belastnings- og spenningsforhold beskriver hvordan data fra nettstasjon og AMS kan brukes som et første 38

7 steg i å vurdere belastnings- og spenningsforhold for eksempel i forbindelse med tilknytting av nye lavpenningskunder. Use caset testes ut på både Demo Steinkjer og Smart Energi Hvaler. I Figur 3 er aktører og informasjon som er en del av use caset vist. Få oversikt over belastning og spenningsforhold for nettplanlegging Database for historiske belastningsdata Hente historisk belastningsdata Velge aktuelt nettområde/ komponent Nettplanlegger KIS Hente avbrudd-, spenningsklagehistorikk Hente historiske spenningsverdier Innhente målinger for kvalitetssikring mm. Planleggingsverk tøy Database for spenningsmålinger Vise max/minspenninger Vise belastning i tidsserie og varighetskurve <<expand>> Vise antall sp.hendelser Presentere data i nettbildet/ kart Vise spenningsmargin Nettstasjon Andre visninger Vise trafotemperatur Et scenario som er beskrevet i use caset er Vise max/min spenninger (beskrevet i use case Gi oversikt over spenningsforhold ved tung og lett last). I dette scenarioet velges et nettområde, spenningsdata hentes fra en database for spenningsmålinger til et planleggingsverktøy, eksempelvis NIS og viser min/maks spenninger hos sluttbrukere ved eksempelvis tung, lett og normal last. Use case-metodikk er velegnet som et hjelpemiddel i DeVID for kommunikasjon mellom forskere, nettselskap, leverandører og demomiljøene. I use case må tanker og gode ideer knyttet til bruk av data fra AMS og nettstasjoner konkretiseres i form av målformulering, beskrivelser og datautveksling. Dette er en effektiv test om ideene er konkrete og avgrensende nok til uttesting. Ved manglende konkretisering og avgrensing blir testing av use case en utfordring. 39

8 Erfaringer fra DeVID viser at det er viktig å formulere avgrensede, små use case og der målformuleringen er tydelig og konkret. Da kan use caset brukes når teknologien, i neste omgang, testes i realistiske omgivelser. Målene er da formulert på en slik måte at det er enkelt å avgjøre om målene er oppfylt eller ikke. Målformuleringen kan være på ulike nivå, fra mål om at data går fra A til B, til mål om effektive prosesser i nettselskapet. Sistnevnte mål krever at det brytes opp i mindre deler og spesifiseres hvilke konkrete situasjoner og behov som skal dekkes av use caset. Det er også viktig å erkjenne når use case ikke er egnet metode. Ved et visst detaljeringsnivå, vil use case slutte å være nyttig. Algoritmer og beskrivelser av implementering er bedre å beskrive i et annet format. Likedan kan de mest overordnede prosessene i organisasjonen like gjerne beskrives ved hjelp av tradisjonelle arbeidsprosessverktøy. Utvikling og testing av use case gir viktige innspill til nettselskaper om hvilke funksjoner (eksempelvis verifisering av nettdokumentasjon) og krav (eksempelvis parameter som skal logges) som bør stilles til systemer ved anskaffelser. Det er utfordrende å beskrive funksjoner som involvere mange ulike systemer og leverandører. Da kan gode use case-beskrivelser være nyttig. Utvalget av use case fra DeVID kan være et godt utgangspunkt ved valg av funksjoner. [1] Cockburn, A. (2001). Writing Effective Use Cases 24. utgave [2] EPRI Use Case Repository: dato: [3] IEC Ed.1: Use case methodology Part 2: Definition of use case template, actor list and requirement list 40