Arnhem, 15 December 2009 Auteur: Robin Massink
Een Ethernet verkeer generator
met microseconde precisie
Document:
Afstudeerverslag
Een Ethernet verkeer generator met microseconde precisie
Uitvoerende partij :
Naam : Robin Massink Studenten nr. : 1218026
Opdrachtgever : Richard Schimmel
Bedrijf : KEMA Nederland B.V
Utrechtseweg 310 6812 AR Arnhem Datum : Utrecht, 15-12-09 Instelling : Hogeschool van Utrecht
Opleiding :Electronic Engineering & Design
Versie : 1.0
Het bestuur van de Stichting Hogeschool van Utrecht aanvaardt geen aansprakelijkheid voor schade voortvloeiende uit het gebruik van enig gegeven, hulpmiddel of procédé in dit verslag geschreven.
Vermenigvuldiging zonder toestemming van zowel de opleiding EE&D van de Hogeschool van Utrecht als de opdrachtgever is niet toegestaan.
Voorwoord
Voor u ligt het afstudeerverslag van het project genaamd “Een Ethernet verkeer
generator met microseconde precisie” en is primair bedoeld voor de afstudeercommissie en de bedrijfsbegeleiders binnen KEMA Nederland B.V. Dit verslag omvat een
procesbeschrijving van het onderzoek, ontwerp, implementatie, en de uiteindelijke oplevering van het eindproduct en nevenproducten.
De afstudeeropdracht voor het onderzoeken, ontwerpen en realisatie van een technisch middel werd door KEMA Nederland B.V. beschikbaar gesteld als afstudeerproject.
Doordat ik; Robin Massink, heb gesoliciteerd bij KEMA na aanleiding van een gesprek op de Nationale Carrièrebeurs, is mij de mogelijkheid aangeboden om dit project voor KEMA Nederland B.V. uit te voeren.
Het afstudeerproject is uitgevoerd onder begeleiding van Richard Schimmel; mijn bedrijfsbegeleider binnen KEMA Nederland B.V.
Dankwoord
Mijn dank gaat uit naar de volgende personen:
Begeleiding KEMA Consulting Services Richard Schimmel (Technical Consultant) Verdere collegae KEMA Nederland B.V.
Marijn Flohil (consultant) Bas Mulder (consultant)
Begeleiding Hogeschool Utrecht Wim Holst (afstudeerdocent) Leverancier hardware
Erik Hemen(sales engineer EBV)
Hulplijn binnen de uitvoering van het gehele project Bert Thomas(Eigenaar Brothom group)
Samenvatting
Deze scriptie beschrijft de afstudeeropdracht die is uitgevoerd door Robin Massink bij KEMA Consulting. De opdracht omvat het realiseren van een technisch middel, namelijk een test apparaat dat pakketten verstuurd volgens het IEC61850-9-2 protocol, om andere apparaten te kunnen testen. Dit komt er op neer dat het test apparaat Ethernet pakketten uitstuurt. Deze Ethernet pakketten kunnen willekeurige data bevatten(in dit geval dus IEC61850-9-2 pakketten). De pakketten hebben elk een timestamp, zodat de timing van elk pakket afzonderlijk kan worden bepaald. De timestamps hebben een precisie van ongeveer 10 microseconden, en er kunnen er minimaal 4800 pakketten per seconde worden verstuurd.
In deze scriptie is beschreven waarom en hoe deze opdracht is uitgevoerd. Het project komt voort uit de wens voor een test apparaat dat niet binnen de gestelde eisen van KEMA beschikbaar is. Het test apparaat moet passen binnen de systemen en test
omgevingen die al binnen KEMA aanwezig zijn. Hierom is het apparaat ontworpen om los te kunnen worden aangestuurd vanaf een laptop via Ethernet, of via een overkoepelend systeem. Omdat een normale PC met Windows niet geschikt is voor het versturen van pakketten met de precisie die de opdracht voorschrijft, zal het geheel op een embedded systeem worden ontwikkeld. Dit systeem is gevonden in de vorm van het MPC8313eRDB ontwikkelbord van Freescale. Dit bord draait Linux, en is voor de opdracht gepatched met real time extensies in de vorm van ADEOS-IPIPE. Met dit systeem kan door de
ontwikkeling van een Linux kernel module aan de eisen van de opdracht worden voldaan.
In deze kernel module wordt via Interrupt Service Routines via hardware timers de Ethernet hardware aangestuurd, om de pakketten op tijd uit te sturen. Om te zorgen dat de timing van het test apparaat synchroon loopt met het apparaat dat wordt getest, is het test systeem gesynchroniseerd via een externe puls. Deze puls zorgt voor een synchronisatie met een precisie tot ongeveer 10 microseconden.
Er is ook een user interface ontwikkeld in de vorm van een .NET command line applicatie die draait op een laptop. Deze user interface communiceert met het test apparaat via TCP. De data voor de test pakketten wordt doormiddel van een binair bestand via FTP door de user interface overgezonden.
Het platform met de ontwikkelde software is ingebouwd in een behuizing om het geheel geschikt te maken voor tests die worden uitgevoerd door KEMA Consultants.
Naast de realisatie van het test apparaat is er ook een user manual, een development manual, een testrapport en een API beschrijving opgesteld om te zorgen dat werknemers binnen KEMA het product kunnen doorontwikkelen indien gewenst.
Inhoudsopgave
Voorwoord... 5
Samenvatting ... 6
1. Inleiding ... 9
1.1. Inhoud ... 9
2. Beeldvorming ... 11
2.1. KEMA ...11
2.1.1. KEMA Consulting Services ...11
2.2. Onderstation ...11
2.2.1. Basisdelen...12
2.3. IEC 61850 ...13
2.3.1. IEC61850-9-2: Sampled Values ...13
2.4. KEMA IEC Test System ...14
2.5. Comtrade ...14
3. Opdracht... 15
3.1. Eindproduct ...15
3.2. Betrokkenen ...16
3.3. Randvoorwaarden...16
3.4. Functionele eisen...16
3.5. kwaliteitseisen ...17
3.6. Beknopte risicoanalyse ...17
4. Aanpak ... 18
4.1. Beeldvorming...18
4.2. Specificeren van ontwerp...19
4.3. Ontwerp ...21
4.4. Planning en Uitvoering ontwerp ...21
4.5 Oplevering...21
5. Globale planning... 22
6. Specificatie ... 23
6.1. Beeldvorming...23
6.2. Initieel ontwerp ...23
6.3. Specificeren van ontwerp...27
6.3.1. Hardware ...27
6.3.2. Software ...31
6.3.3. Testen ...34
6.3.4. Software ontwerp...35
7. Ontwerp ... 38
7.1. API...38
8. Planning ... 39
8.1. Taakbeschrijving ...39
8.2. Overzicht...40
9. Uitvoering ontwerp... 41
9.1. Het verkrijgen van een ontwikkelbord ...41
9.2. Bevindingen tijdens implementeren software ...41
9.3. Testen of ontwerp voldoet aan de specificatie eisen ...42
9.3.1. Opgestelde testcases...43
9.3.2. Resultaten...43
9.4. Selectie behuizing...45
9.5. Inbouwen behuizing...45
9.6. Documentatie schrijven ...45
9.8. Opleveren/presenteren...45
10. Oplevering ... 46
10.1. Resultaten ...46
10.2. Evaluatie ...46
10.3. Conclusies ...46
12. Lijst van afkortingen en symbolen... 47
13. Verantwoording... 47
Bijlage I: Hardware eisen en selectie ... 48
1. Beeldvorming...48
2. Gevonden systemen ...48
3. Vergelijking ...50
4. Samenvatting ...52
5. Aanbeveling...53
Bijlage II: MPC8313e-RDB... 54
1. Platform ...54
2. Hardware ...55
3. Software packages ...55
3.1. Shipped software ...55
3.2. Drivers ...55
Bijlage III: Software eisen en selectie ... 56
1. Mogelijkheden...56
2. Bespreking ...57
Bijlage IV: ADEOS-IPIPE beschrijving ... 58
Bijlage V: Software ontwerp... 59
Software design...59
init_simulator()...59
xmit_isr_ipipe() ...59
xmit_isr_Linux() ...60
pps_sync_isr()...60
control_simulator() ...60
Bijlage VI: User guide... 61
Bijlage VII: Development guide... 63
Bijlage VIII: API... 66
1. Inleiding
Dit document beschrijft het afstudeeropdracht binnen de opleiding Elektrotechniek, specialisatie Embedded Systems aan de Hogeschool Utrecht.
Deze afstudeeropdracht betreft het ontwerpen, en de realisatie van een technisch middel.
Het betreffende technische middel is een systeem om Ethernet pakketten te versturen met microseconde precisie. Deze afstudeeropdracht is in de vorm van een project uitgevoerd.
Doel van de opdracht:
Het doel van de opdracht is tweeledig.
Voor de opdrachtgever:
De opdracht uitvoeren, en de in de opdracht gestelde producten op een gepaste
manier opleveren.
Voor de opleiding:
Zichtbaar maken dat de afstudeerder als bachelor of engineering in de Elektrotechniek competent is; Hij kan technische middelen ontwerpen en realiseren.
Ook moet de afstudeerder aantonen dat hij op bachelorniveau werk kan uitvoeren; Hij kan werk uitvoeren op een manier die aansluit op de vijf
bachelorkenmerken.
De uitvoering van de opdracht is zichtbaar gemaakt door het gehele project te documenteren, en elke stap binnen het project te verantwoorden in de
projectdocumentatie.
1.1. Inhoud
Doelgroep
De scriptie wordt geschreven voor de volgende doelgroep: Leerlingen en docenten van de Hogeschool Utrecht, faculteit FNT, evenals de opdrachtgever bij KEMA.
Doel van dit document
Dit document is opgesteld om zichtbaar te maken welke stappen zijn ondernomen bij de uitvoer van de afstudeeropdracht. Na het lezen van dit document moet het volgende duidelijk zijn aan de lezer:
De aanleiding voor de opdracht.
Wat de opdracht precies inhoudt.
Welke eindproducten er zullen worden opgeleverd
Welke personen en instanties zijn betrokken bij deze opdracht
Welke taken er moeten gedaan worden, om van opdracht tot eindproduct te komen.
In welk tijdspad de diverse taken worden uitgevoerd.
Hoe de taken zijn uitgevoerd, welke oordeelsvorming hier bij tot uiting is gekomen Hoe de specificatie van het eindproduct tot stand is gekomen
Hoe het complete ontwerp van het eindproduct is vorm gegeven Hoe het ontwerp is vertaald naar de planning
Hoe de planning is vertaald naar het eindproduct Wat zijn de conclusies na de uitvoering van dit project
Het document kan worden gebruikt om inzicht te krijgen in de achtergrond, en de totstandkoming en de uitvoering van de geformuleerde afstudeeropdracht. Ook kan het document worden gebruikt ter beoordeling van het gekozen traject waarin de opdracht is uitgevoerd, en of de opdracht vanuit de juiste achterliggende gedachte is uitgevoerd. Ten slotte kan het document gebruikt worden als naslagwerk voor overeenkomstige
opdrachten.
Indeling
Het document beschrijft kort samengevat de volgende onderdelen:
Inleiding bedrijf van uitvoering Inleiding omgeving opdracht Inleiding plaatsing opdracht Opdracht
Aanpak
Globale planning
Specificatie van onderdelen Ontwerp van eindproduct
Planning van de uitvoer, met betrekking op het maken van het eindproduct Hoe de planning is uitgevoerd
Conclusies Verantwoording
Er zijn ook diverse bijlagen. Er is getracht om het document zo op te stellen dat het kan worden begrepen zonder deze door te nemen. Alleen als er desgewenst dieper moet worden ingegaan op een onderwerp, kan hier naartoe worden gesprongen. De volgende onderwerpen zijn opgenomen in de bijlage;
Hardware eisen en selectie MPC8313e-RDB specificatie Software eisen en selectie ADEOS-IPIPE beschrijving Software ontwerp
User guide
Development Manual
2. Beeldvorming
Voor een goede beeldvorming van de opdracht zullen er eerst diverse betrokken partijen moeten worden geïntroduceerd. De eerste betrokken partij is KEMA, de overkoepelende organisatie waar de afstudeeropdracht wordt uitgevoerd.
2.1. KEMA
KEMA is opgericht in 1927 als een keuringsinstituut voor de Nederlandse
elektriciteitssector. Tegenwoordig staat de naam KEMA, oorspronkelijk slechts de afkorting van de volledige naam, voor veel meer dan alleen het testen van elektrische apparatuur.
2.1.1. KEMA Consulting Services
Dit afstudeerproject heeft plaatsgevonden binnen de werkmaatschappij KEMA Consulting Services. De klanten van KEMA Consulting Services zijn leveranciers in elektrische
energie en netbedrijven, die voor het transport en distributie van deze energie zorgen.
Kernactiviteiten van KEMA Consulting Services:
Klanten ondersteunen met uitleveren van projecten op gebied van
procesbeheersing, bewaking en optimalisatie van energie gerelateerde projecten.
Certificering van beveiligingsproducten die toegepast worden in energieonderstations.
2.2. Onderstation
Aangezien het eindproduct(dat in dit document wordt gedefinieerd) moet worden gebruikt om apparatuur te testen in een onderstation, zal er moeten worden begrepen wat een onderstation is. Dit is noodzakelijk om een duidelijk beeld te krijgen van de omgeving waarin de opdracht wordt uitgevoerd.
Elektriciteitscentrales wekken elektrische energie op, die vervolgens via het energie netwerk uiteindelijk aankomt bij de stopcontacten die in elk huis zijn te vinden. (zie figuur 5)Hoge spanningen zijn efficiënter te transporteren over het energie netwerk, maar niet veilig en praktisch om uit het stopcontact te laten komen. Hierom zal ergens in de buurt van het stopcontact de spanning moeten worden getransformeerd naar een lagere, veiligere spanning. Om dit efficiënt te doen, wordt de elektrische energie in meerdere stappen naar steeds lagere spanningen getransformeerd, tot ze uiteindelijk als 230volt wisselspanning uitkomt bij het stopcontact.
Figuur 5: Schematisch Energie netwerk Een onderstaton is een knooppunt in het energie netwerk. De belangrijkste taak van een onderstation is de elektrische energie naar een lagere spanning transformeren. De onderstations die relevant zijn voor dit project transformeren bijvoorbeeld 230KV naar 20KV. Dit zijn dan ook de grotere stations, en niet de transformatorhuisjes die we bijvoorbeeld in een woonwijk zien staan.
Hiernaast staat een schematische weergave met daarin een transmission en een power onderstation. In dit schema is tevens zichtbaar waar een knooppunt ofwel substation zicht bevindt in een energienetwerk.
Om meer controle te hebben over de energie distributie binnen het netwerk voert een onderstation ook nog diverse andere taken uit. Hier zijn de
belangrijkste taken samengevat:
Beveiliging Besturing Meting
Transformeren
2.2.1. Basisdelen
Om de beoogde taken van een onderstation uit te voeren, bevat een onderstation de volgende onderdelen
Circuit Breakers (vermogens schakelaars). Deze zorgen voor het op, en afschakelen van de hoogspanningslijnen die lopen van, en naar het systeem.
Transformatoren, Deze zorgen voor het transformeren van de spanningen.
Isolatoren Conductoren
Intelligent Electronic Device (IED). Een 'Intelligent Electronic Device' zal in dit document voortaan worden beschreven als IED. Een IED is een apparaat dat de cruciale taken in een onderstation controleert. Een IED kan bijvoorbeeld via een sensor of een signaal van de controlekamer een circuit breaker in- of uitschakelen.
Een activiteit van KEMA Consulting is het testen van IED's. IED's communiceren met elkaar via diverse protocollen. Een recente ontwikkeling, waar KEMA sterk bij betrokken is, is het standaardiseren van deze protocollen onder 1 standaard genaamd: IEC61850.
Het technische middel(dat wordt beschreven in dit document) moet voldoen aan deze standaard, en vooral de 9-2 suffix hiervan. Hierom zal er dus eerst globaal moeten worden begrepen wat deze standaard inhoud.
Figuur 4: Onderstation
2.3. IEC 61850
Er is de laatste tijd veel energie gestoken in het standaardiseren van de communicatie binnen de diverse apparaten in een onderstation. Er zijn namelijk diverse initiatieven om onderstations te automatiseren door de diverse IED's te laten communiceren via een netwerk. Bij een dergelijke automatisering is het wenselijk dat de systemen van diverse fabrikanten met elkaar kunnen communiceren, en de klant niet afhankelijk is van de ideeën van één fabrikant over de automatisering van een onderstation. Hiervoor is de IEC61850 standaard opgesteld.
KEMA Consulting speelt de rol van een onafhankelijke derde partij. Die test of een IED die wordt ontwikkeld door een fabrikant, wel voldoet aan de IEC61850 standaard. Zo weten de fabrikant en de gebruiker van het systeem zeker dat alle verschillende IED's zonder problemen met elkaar overweg kunnen.
De klanten van KEMA zijn dus in dit geval de fabrikanten van een IED, die een consultant van KEMA inhuren, om te laten testen of de ontwikkelde IED wel aan de IEC 61850 standaard voldoet.
Of een IED voldoet aan de IEC61850 standaard kan in veel gevallen worden getest door KEMA met bestaande testapparaten. Er zijn ook onderdelen die nog niet volledig worden ondersteund door de huidige testapparaten beschikbaar binnen KEMA. Een van deze onderdelen heeft betrekking op het testen van de IEC61850-9-2 standaard: Sampled Values.
2.3.1. IEC61850-9-2: Sampled Values
Het IEC61850-9-2 onderdeel wordt gebruikt om de signalering van de merging units naar de circuit breakers in goede banen te leiden over ethernet. Een merging unit is een IED dat de stroom en spanning meet op een punt in het netwerk, en deze informatie(de sampled values) digitaal via het ethernet kenbaar maakt aan de andere IED's op het netwerk. Een andere IED kan hier vervolgens op ingrijpen door te besluiten om een trip signaal af te geven in geval van een kortsluiting. Het trip signaal zorgt voor de
afschakeling van een hoogspanningslijn doormiddel van een circuit breaker. Omdat de informatie o.a. gebruikt wordt om in te grijpen bij een kortsluiting is deze zeer
tijdkritisch. De IEC 61850-9-2 standaard heeft hierom duidelijke (timing) eisen waaraan de apparatuur moet voldoen om betrouwbaar te kunnen functioneren.
Er zijn momenteel geen testapparaten binnen KEMA, die aan deze timings eisen kunnen voldoen bij het versturen van IEC61850-9-2 test pakketten. Voor het ontvangen van pakketten is er al een testapparaat aangeschaft. Er zijn wel diverse generieke
testapparaten beschikbaar op de markt, die technisch geschikt zijn om tests uit te voeren om te zien of er aan de IEC61850-9-2 standaard wordt voldaan (m.b.t. het versturen van test pakketten). Maar deze testapparaten hebben andere nadelen die ze ongeschikt maken om door KEMA te worden gebruikt als testapparaat. Vooral de prijs van het testapparaat, en het gebrek aan gebruiksgemak maken deze apparaten niet geschikt voor gebruik binnen KEMA Consulting.
Hierom heeft KEMA Consulting zelf de opdracht gegeven om een testapparaat te
ontwikkelen, die wel IEC61850-9-2 pakketten kan versturen. En zo dus IED's kan testen of ze aan de standaard voldoen. Het maken van dit testapparaat als technisch middel, is de afstudeeropdracht die wordt beschreven in dit document.
2.4. KEMA IEC Test System
KEMA Consulting is momenteel ook bezig om al haar testapparaten onder te brengen in een overkoepelend systeem, genaamd KEMA IEC Test System(KITS). Dit systeem moet ervoor zorgen dat het eenvoudiger wordt voor consultants om meerdere testapparaten te gebruiken met 1 universeel systeem. Aangezien elk testapparaat te integreren moet zijn in dit toekomstige systeem, is deze informatie relevant voor de beeldvorming binnen deze opdracht.
Het achterliggende idee is dat er een centrale module is, de Data Acess Module, waar diverse grafische interface modules aan kunnen worden gehangen, die via deze module toegang kunnen krijgen tot de functionaliteit van de verschillende testapparaten, die elk hun functionaliteit ter beschikking stellen via een 'driver module'.
Het KITS systeem zorgt er bijvoorbeeld voor dat een module een test signaal genereert, die wordt gestuurd naar den Device Under Test(DUT). Deze DUT reageerd met een bepaalde uitput, die via een andere module weer wordt teruggevoerd in het testsysteem.
Zo kan het KITS systeem precies zien hoe de DUT reageert in een opgestelde testcase.
Hieronder is een schematische weergave van het beschreven systeem.
Het is dus een systeem dat is opgebouwd uit diverse modules. Het systeem is nog in ontwikkeling, en niet alle modules en koppelingen zijn momenteel geïmplementeerd.
2.5. Comtrade
Comtrade is een bestandsformaat dat gebruikt wordt in veel IED gerelateerde systemen om een serie stromen en spanningen digitaal op te slaan. Door deze informatie weer uit te sturen kunnen kortsluitingen worden gesimuleerd. Het testapparaat in deze
afstudeeropdracht zal hier mee te maken krijgen, doordat dit bestandsformaat gebruikelijk is voor het uitvoeren van simulaties met betrekking op onderstations.
KITS
KITS test verzend module DUT KITS test uitlees module
3. Opdracht
Het technische middel dat binnen deze opdracht gerealiseerd moet worden, zal worden gebruikt om een IED te testen op het voldoen aan de IEC61850-9-2 standaard. Dit testen moet uitgevoerd worden door het genereren van testdata. Dit wil zeggen; Het
testapparaat simuleert een signaal, om te testen hoe de IED er op reageert.
Het testapparaat zal dus worden gebruikt door consultants binnen KEMA, om met dit apparaat de producten(De IED's) van hun klanten kunnen testen op het voldoen aan de IEC 61850-9-2 standaard.
De opdracht kan als volgt worden geformuleerd:
Ontwerp en realiseer een technisch middel voor Consultant binnen KEMA, om de
IEC61850-9-2 protocol compliance te testen van IED's, doormiddel van het uitsturen van testsignalen.
3.1. Eindproduct
Het eindproduct is een apparaat waarmee consultants van KEMA test kunnen uitvoeren, om te zien of een IED aan de IEC61850-9-2 standaard voldoet.
Het op te leveren eindproduct moet zijn in de vorm van een functioneel prototype. Dit betekent dat het een compleet functioneel apparaat betreft. Dit apparaat zal worden gebruikt door de consultants om te testen of het apparaat voldoet aan de eisen van het beoogde eindproduct.
Het beoogde testapparaat moet naast het bevatten van een losse gebruikersinterface, ook passen binnen KITS als een module. Hier zal dus in ieder geval rekening mee moeten worden gehouden bij de ontwikkeling van de gebruikersinterface.
Ook zijn er nog bepaalde nevenproducten die zullen moeten worden gerealiseerd;
Omdat het een testapparaat betreft, dat door consultants gebruikt zal gaan worden, moet er een gebruikshandleiding aanwezig zijn.
Ook bestaat er de kans dat mensen binnen KEMA het testapparaat later willen uitbreiden of debuggen. Hiervoor moet er een ontwikkelhandleiding aanwezig zijn.
Om aan te kunnen tonen dat het apparaat functioneert volgens de specificaties, wordt er een testrapport opgesteld.
Om te beschrijven hoe het apparaat moet worden aangestuurd vanuit een programma, is er een API beschrijving opgesteld.
3.2. Betrokkenen
De volgende partijen zijn betrokken bij deze opdracht:
KEMA als bedrijf, dat baat heeft bij de uitvoer van de afstudeeropdracht Consultants die het apparaat gaan testen en gebruiken
Klanten van KEMA consultancy waarvan de apparatuur wordt getest met dit apparaat
Richard Schimmel als opdrachtgever namens KEMA, voor het uitvoeren van de afstudeeropdracht
Richard Schimmel als bedrijfsbegeleider die zorgt voor voldoende faciliteiten voor het uitvoeren van de afstudeeropdracht.
Leveranciers van technische middelen die nodig zijn voor de ontwikkeling binnen de opdracht
Leveranciers van technische middelen die worden toegepast in het eindproduct Consultants binnen KEMA Consulting die het KITS systeem ontwikkelen
De afstudeerder: Robin Massink, die de opdracht uitvoert.
De begeleider van Hogeschool Utrecht: Wim Holst, die zorg draagt over de controle op afdoende begeleiding van het bedrijf binnen het project
3.3. Randvoorwaarden
De opdrachtgever heeft diverse randvoorwaarden gesteld aan het te maken testapparaat;
De opdracht moet worden uitgevoerd binnen KEMA
De opdracht moet binnen een half jaar worden uitgevoerd De materiaalkosten mag niet meer dan 1000 euro bedragen
3.4. Functionele eisen
De opdracht kan worden vertaald naar de volgende functionele eisen;
De oplossing moet compatible zijn met KITS
De oplossing moet ook losstaand kunnen werken. Dit wil zeggen, zonder KITS, bijvoorbeeld bestuurd via een laptop
De oplossing moet mee te nemen zijn in een vliegtuig als handbagage De oplossing moet updatebaar zijn via ethernet
De oplossing moet Comtrade simulatiebestanden accepteren als testdata.
De oplossing moet testcases uit kunnen voeren, die betrekking hebben op het voldoen aan de IEC61850-9-2 standaard van een IED. Hierbij gaat het alleen om het ontvangen van pakketten door een IED.
3.5. kwaliteitseisen
Moet door een consultant kunnen worden gebruikt na het lezen van de handleiding Er moeten mensen uit ICT mee verder kunnen ontwikkelen
3.6. Beknopte risicoanalyse
Het betreft hier een nieuw product, dat door een afstudeerder wordt ontwikkeld. Er zijn geen directe trajecten binnen KEMA die afhankelijk zijn van het slagen van dit product, en de kosten voor dit project blijven beperkt tot de kosten van de afstudeervergoeding, en eventuele ontwikkelkosten. De materiaalkosten is in de randvoorwaarden beperkt tot 1000 euro. Ook is het voor KEMA een bruikbaar resultaat als blijkt dat het project niet binnen de gestelde tijd af is te krijgen, namelijk dat het niet binnen het gereserveerde budget gerealiseerd kan worden.
4. Aanpak
Om van de opdracht te komen tot een eindproduct zullen er diverse stappen moeten worden ondernomen. Hieronder staan de stappen beschreven, en de relatie met elkaar.
De stappen hebben allemaal een 'deliverable'. De deliverable zorgt ervoor dat elke stap een gedefinieerd tussenresultaat heeft, dat kan worden gebruikt als input bij andere taken. Indien er naderhand een detail binnen de opdracht wordt aangepast, kan via deze aanpak worden geanalyseerd welke consequenties dit heeft voor het gehele project. Ook kan er via de stappen de voortgang worden bewaakt, en zo nodig de beschikbare
resources worden herverdeeld onder de verschillende taken. Zo kan het project binnen de planning worden gehouden.
4.1. Beeldvorming
Verdieping in IEC61850-9-2
Er zal moeten worden verdiept in de details van de IEC61850-9-2 standaard, om helder te krijgen aan welke eisen de het eindproduct moet voldoen.
Deliverable: archief met relevante informatie over IEC61850-9-2
Verdieping in KITS
Het eindproduct moet geïntegreerd kunnen worden in KITS. Hiervoor zal er verdiept moeten worden in de details van dit systeem, en hoe het eindproduct hier in kan gaan passen.
Deliverable: archief met relevante informatie over KITS
Verdiepen in comtrade bestandsformaat
Het eindproduct moet het comtrade bestandsformaat ondersteunen, hiervoor moet er een helder beeld zijn van hoe dit bestandsformaat is opgezet, en welke implicaties dit heeft voor het eindproduct.
Deliverable: archief met relevante informatie over comtrade bestandsformaat
Inzicht krijgen in het werk van de consultants binnen KEMA
Omdat het eindproduct zal worden gebruikt door de consultants, is het verstandig om te kijken hoe de huidige testapparaten door deze consultants worden gebruikt, en welke kennis de consultants bezitten over dergelijke systemen.
Deliverable: archief met relevante informatie over het werk van de consultants
Inzicht krijgen in de producten van de klant
Het eindproduct zal worden gebruikt om IED's van fabrikanten te testen. Hierom is het verstandig om te verdiepen in de functionaliteit en implementatie van deze producten. Zo kan er beter rekening worden gehouden met het uiteindelijke doel, bij het ontwikkelen van het eindproduct.
Deliverable: archief met relevante productinformatie
4.2. Specificeren van ontwerp
Initiële opzet maken voor ontwerp
Als bovenstaande verdiepingen zijn uitgevoerd, moet het mogelijk zijn om in ieder geval een initiële opzet te maken voor een ontwerp. Hierin is gedefinieerd wat de functionaliteit van het eindproduct wordt. Dit ontwerp wordt vervolgens besproken met de consultants en de opdrachtgever om te controleren of het ontwerp de functionaliteit implementeert op een manier die voor hen acceptabel is. Het initiële ontwerp verduidelijkt hoe het eindproduct wordt gebruikt door de consultant. Het initiële ontwerp verduidelijkt niet hoe het eindproduct intern werkt. In dit stadium kunnen er aanpassingen worden gemaakt om het product beter aan te laten sluiten op de werkwijze van de consultants. Indien de consultants akkoord gaan met het initieel functionele ontwerp, kan dit worden omgezet in een definitief functioneel ontwerp.
Deliverable: definitief functioneel ontwerp
Functionele eisen omzetten naar technische hardware eisen
Indien het functionele ontwerp is goedgekeurd, kunnen er technische eisen worden opgesteld, met in achtneming van de functionele eisen, en het definitieve functionele ontwerp.
Deliverable: document met technische hardware eisen
Oriënteren op beschikbare hardware oplossingen
Met in achtneming van de technische hardware eisen kan er nu een oplossing worden gevonden die aan deze opgestelde eisen voldoet.
Deliverable: gekozen hardware, alternatieven en afweging op basis van de opgestelde eisen.
Fabrikanten en leveranciers benaderen voor gevonden oplossing
Als er een Hardware oplossing is geselecteerd, zal deze moeten worden aangeschaft.
Indien er hier problemen aan het licht komen, zal er naar de volgende stap moeten worden teruggesprongen.
Deliverable: gekozen hardware in bezit
Software eisen opstellen
Wanneer de hardware selectie vast staat kan er worden nagedacht over de specifieke eisen van de software die er op moet gaan draaien. Deze eisen zijn gebaseerd op de hardware, de functionele eisen en het functionele ontwerp.
Deliverable: document met software eisen
Afweging van software maken
Op basis van de software eisen moet er bepaald worden, welke software moet worden geselecteerd, en welke moet worden geschreven.
Deliverable: onderbouwde keus voor geschreven of geselecteerde software per onderdeel
Software selectie maken
Voor de software die niet zelf wordt ontwikkeld moeten diverse opties en producten tegen elkaar worden afgewogen op basis van de opgestelde software-eisen.
Deliverable: gekozen softwarepakket, alternatieven en afweging op basis van de opgestelde eisen
Opstellen testcases
Er zullen testcases moeten worden opgesteld op basis van de geselecteerde software om te testen of de combinatie van hardware en software aan de gestelde software-eisen voldoet
Deliverable: document met testcases
Testen van geselecteerde software
De geselecteerde software zal moeten worden getest in combinatie met de hardware, om te kijken of deze daadwerkelijk voldoet aan de opgestelde software eisen. Hiervoor zullen er kleine testprogramma's worden geschreven om te zien of het geheel naar verwachting presteert.
Deliverable: testprogramma's die de testcases demonstreren
Maken van software ontwerp
Als er is geverifieerd dat de gekozen hardware en software voldoet aan de opgestelde eisen en testcases, kan er een definitief software ontwerp worden opgesteld.
Deliverable: definitief software ontwerp
Al deze onderdelen zullen worden opgenomen in de eindscriptie bij de specificatie van het product.
4.3. Ontwerp
Compleet ontwerp
Nadat deze stappen zijn uitgevoerd, is het eindproduct volledig te specificeren. De specificaties dienen te worden samengevoegd in een compleet ontwerp.
Deliverable: definitief compleet ontwerp,
Dit onderdeel zal worden opgenomen in het hoofdstuk 'Ontwerp' in de eindscriptie
4.4. Planning en Uitvoering ontwerp
Opstellen planning van uitvoer
Vervolgens kan de uitvoering van het ontwerp worden opgedeeld en gepland in de beschikbare tijd.
Deliverable: planning van realisatie eindproduct en nevenproducten
Uitvoer
Vervolgens wordt de opgestelde planning doorlopen, en worden alle deeltaken uitgevoerd.
Deliverable: eindproduct en nevenproducten
Terugkoppeling
Hierna zal er worden teruggekoppeld naar de specificatie om te controleren of het eindproduct(en nevenproducten) voldoet aan de opgestelde eisen in de specificatie en opdrachtomschrijving.
Deliverable: een rapport van het eindproduct met betrekking tot de opgestelde functionele en technische eisen.
Deze onderdelen zullen worden opgenomen in de eindscriptie in het hoofdstuk 'Uitvoering'
4.5 Oplevering
Indien het eindproduct aan de specificatie voldoet, kan het geheel worden gepresenteerd en opgeleverd aan de opdrachtgever. Hiermee is het project afgerond.
Deliverable: compleet product.
5. Globale planning
In deze planning zal worden beschreven hoe de taken uit de aanpak beschrijving worden gekoppeld aan de beschikbare tijd. Hiermee kan worden beoordeeld of het beoogde pad tot de realisatie van het eindproduct reëel is binnen de gestelde tijd.
Er zijn in totaal 17 weken ingepland voor het project(40 uur * 17 = 680). Hieronder is een grove planning te zien. De beeldvorming bevat taken die onafhankelijk van elkaar kunnen worden uitgevoerd. De andere taken (van initieel ontwerp tot oplevering)hebben allemaal een duidelijke stapsgewijze afhankelijkheid van elkaar(zie aanpak voor de relatie tot elkaar). Het is dan ook niet mogelijk om deze taken parallel uit te voeren.
Wanneer de planning van de uitvoer is gemaakt, kan er worden gekeken of het werk nog past binnen de geplande tijd. Ook kan er dan worden gekeken hoe het werk verdeeld kan worden onder de uitvoerders.
Het is erg lastig om een correcte schatting te maken van de tijd die nodig is voor elke taak. De ervaring en informatie ontbreken momenteel om meer dan een grove schatting te kunnen maken op dit gebied. Hierom is de gedefinieerde tijd in deze planning alleen maar een leidraad, en zal in de loop van het project deze moeten worden bijgesteld.
Toch is de planning hier wel gedefinieerd omdat het inzicht geeft in de verdeling van de tijd binnen het project, en het ook duidelijk laat zien welke implicaties vertragingen hebben voor de totale planning.
4.1. Beeldvorming - 40 uur Verdieping in IEC61850-9-2 - 8 uur Verdieping in KITS - 8 uur
Verdiepen in comtrade bestandsformaat - 8 uur
Inzicht krijgen in het werk van de consultants binnen KEMA - 8 uur Inzicht krijgen in de producten van de klant - 8 uur
4.2. Initieel ontwerp – totaal 16 uur Initiële opzet maken voor ontwerp
4.3. Specificeren van ontwerp – totaal 160 uur
Functionele eisen omzetten naar technische hardware eisen - 8 uur Oriënteren op beschikbare hardware oplossingen - 16 uur
Fabrikanten en leveranciers benaderen voor gevonden oplossing - 16 uur Software requirements opstellen - 8 uur
Afweging van software maken - 4 uur Software selectie maken - 16 uur Opstellen testcases - 4 uur
Testen van geselecteerde software - 80 uur Maken van software ontwerp - 8 uur
4.4. Planning en Uitvoering ontwerp – totaal 448 uur Opstellen planning van uitvoer - 8 uur
Uitvoer - 400 uur
Terugkoppeling - 40 uur 4.5 Oplevering – 1 uur
6. Specificatie
In de specificatie wordt beschreven hoe de diverse onderdelen van het uiteindelijke ontwerp tot stand zijn gekomen. Ook wordt er aandacht besteed aan de alternatieven en de besluitvorming binnen elk onderdeel.
Dit is een stapsgewijs verhaal, aangezien de diverse onderdelen grotendeels op elkaar zijn gebouwd. Zo bepaald bijvoorbeeld de gekozen hardware, welke software er gekozen moet worden, die op haar beurt weer bepaald hoe de applicatie moet worden ontworpen.
Door het geheel ook stapsgewijs te beschrijven kan er beter worden begrepen hoe de besluitvorming tot stand is gekomen.
6.1. Beeldvorming
De beeldvorming bestaat vooral uit het doornemen van documenten die door KEMA beschikbaar zijn gesteld. Deze zijn opgenomen in de literatuurlijst. De documenten zijn beschikbaar gesteld op het intranet van KEMA, en konden hierdoor verkregen worden door het intranet binnen KEMA te doorzoeken op de relevante onderwerpen. De verdieping in het werk van de consultants zelf en de producten van de klant bestaat vooral uit observaties en is al voldoende beschreven in hoofdstuk 2: 'Beeldvorming'.
6.2. Initieel ontwerp
Het initieel functioneel ontwerp beschrijft hoe het beoogde testapparaat moet
functioneren. Dit is opgesteld vanuit de eisen en randvoorwaarden uit de opdracht. Dit ontwerp kan in zichzelf technische details bevatten, maar deze dragen in deze contex vooral bij aan de definitie van de functionaliteit die relevant is voor de eindgebruiker(de consultants binnen KEMA).
Hier staan nogmaals de functionele eisen opgesomd:
De oplossing moet compatible zijn met KITS
De oplossing moet ook losstaand kunnen werken. Dit wil zeggen, zonder KITS, bijvoorbeeld bestuurd via een laptop
De oplossing moet mee te nemen zijn in een vliegtuig als handbagage De oplossing moet updatebaar zijn via ethernet
De oplossing moet Comtrade simulatiebestanden accepteren als testdata.
De oplossing moet testcases uit kunnen voeren, die betrekking hebben op het voldoen aan de IEC61850-9-2 standaard van een IED. Hierbij gaat het alleen om het ontvangen van pakketten door een IED.
Hieronder wordt beschreven hoe deze functionele eisen zijn vertaald naar het functioneel ontwerp.
Omdat het eindproduct testcase moet kunnen uitvoeren met betrekking op de IEC61850- 9-2 standaard, is er verdiept in deze standaard. Uit deze standaard volgen diverse eisen waar het eindproduct aan zal moeten voldoen;
Protocol Interface
IEC61850-9-2 heeft betrekking op communicatie via ethernet. Hierbij moet het
testapparaat alleen maar Ethernet pakketten versturen, aangezien het eindproduct alleen de ontvangers moet testen. IEC61850-9-2 definieert 1 weg communicatie tussen
apparaten over een 100mbit full duplex verbinding. Hierom zal het eindproduct dus in ieder geval een ethernetcontroller met 100 mbit full duplex aan functionaliteit moeten bezitten.
Data-rate
Ook definieert de IEC61850-9-2 standaard een data-rate voor de pakketten. Namelijk 4000 pakketten per seconde voor een land met een lichtnet van 50Hz, en 4800 pakketten per seconde voor 60Hz. Het eindproduct zal beide moeten ondersteunen, aangezien KEMA vooral internationaal opereert. Er mag elke seconde een verschil zijn van maximaal 1 pakket in het aantal verstuurde pakketten. Dus er mogen er alleen 4799, 4800 of 4801 verstuurd zijn. Indien er bijvoorbeeld 4799 pakketten zijn verstuurd in 1 seconde, moet er de volgende seconde 4801 pakketten verstuurd worden om dit te compenseren. IEC61850-9-2 pakketten zijn overigens altijd van gelijke grootte, namelijk 113 bytes.
Synchronisatie
De definitie van de tijdsbasis waarin de pakketten moeten worden gestuurd is ook gedefinieerd. Deze moet namelijk synchroon zijn met de ontvanger tot op 1 microseconde nauwkeurig.
Het systeem voor synchronisatie kan volgens de standaard op 2 manieren worden geïmplementeerd;
Door een 'pulse per second'(PPS), een standaard die definieert dat er elke seconde een puls moet worden gegenereerd op TTL niveau door een bron. De IEC61850-9-2
standaard schrijft dus een nauwkeurigheid van 1 Ns voor. Dus dit moet ook de maximale afwijking zijn van deze puls. Een bron zou hierbij, bijvoorbeeld een GPS-receiver kunnen zijn. De gebruikelijke connector voor dit signaal in IED's is BNC.
De andere manier is het IEEE1588 protocol. Dit is een standaard voor de synchronisatie van apparaten over ethernet met sub-microseconde precisie. Deze precisie is alleen mogelijk bij het gebruik van specifieke ethernet hardware, die dit IEEE 1588 protocol ondersteunt. De IEC61850 standaard definieert alleen niet of deze manier van
synchroniseren moet gaan plaatsvinden via dezelfde verbinding als waarmee de 4000 pakketten per seconde worden uitgestuurd. Ondanks dat het versturen van deze informatie over dezelfde verbinding technisch mogelijk is, is dit volgens de consultants binnen KEMA niet aan te raden. Desondanks zal een IEC61850-9-2 compliant product, door het gebrek aan definitie in de standaard dit wel moeten ondersteunen
Het eindproduct moet beide vormen van synchronisatie kunnen ondersteunen, aangezien beide vormen ook in het te testen apparaat aanwezig kan zijn. Er moet dus een
aansluitmogelijkheid zijn op het eindproduct voor IEEE1588 compliant signalen en PPS.
Duur van de tests.
Er is niet gespecificeerd in de opdracht hoe lang een test maximaal duurt mag duren. Dit is wel iets waar de dagelijkse gebruikers tegen aan zullen lopen. Hierom is er extra informatie ingewonnen bij de consultants. Hieruit blijkt dat een test nooit langer zal duren dan 4 seconden. Hierom zal het eindproduct dan ook worden ontworpen op tests van maximaal 4 seconden.
Vroege ontwerpkeuzen
Omdat het van grote impact is voor de vorm en functionaliteit van het eindproduct, is hier de keus onderbouwd voor het gebruik van een standaard Windows PC of een losstaand systeem. Er is dus bewust gekozen om bij het functionele ontwerp al onderzoek te doen naar het platform van de applicatie. De test apparaten die KEMA Consulting zelf ontwikkeld zijn namelijk softwarepakketten die draaien onder Windows.
Dit zou dus normaal gesproken een logische keus zijn, maar in dit geval niet mogelijk.
Hieronder wordt uiteen gezet waarom een normale Windows PC geen geschikt platform is binnen deze specifieke opdracht.
Operating systems
Een operating system als Windows heeft determinisme tot ongeveer 1 milliseconde
(bron: http://www.wideman-one.com/gw/tech/dataacq/wintiming.htm ). Dit is gebaseerd op de precisie van de timers die het OS aanbied. Er is in dit soft-realtime systeem geen garantie dat de deadline voor een timer ook daadwerkelijk gehaald wordt.
Uitgaande van 4800 pakketten per seconde, zoals IEC61850-9-2 voorschrijft, moeten er in 1 milliseconde ongeveer 4 pakketten verstuurd worden(1 elke 208 Ns). Dus een best case afwijking van 1 milliseconde zorgt al voor een afwijking die buiten de specificatie valt(4 pakketten in plaats van 1). Een Windows systeem is dus niet geschikt om software op te draaien met de benodigde precisie.
Hierom zal er dus een specifiek losstaand systeem moeten worden ontwikkeld, dit wil zeggen; een systeem dat bestaat uit hardware en software in plaats van een
softwarepakket voor Windows.
Fysieke grootte
Het systeem moet mee te nemen zijn in een vliegtuig als handbagage. Om deze reden zal er in ieder geval rekening moeten worden gehouden met de grootte van het
losstaande systeem. Als het eindproduct past in een laptoptas, is het systeem nog van een acceptabel formaat.
Behuizing
Aangezien het eindproduct zal worden gebruikt in het veld, moet het systeem in een behuizing worden geplaatst. Deze behuizing zal dus in ieder geval geschikt moeten zijn voor dagelijks gebruik.
KITS
Uit de verdieping blijkt dat KITS een systeem is dat uit diverse modules is opgebouwd.
Delen van het systeem draaien op een Windows platform, maar modules kunnen via het ethernet aan het systeem worden gekoppeld.
Het eindproduct van deze opdracht moet volledig kunnen worden aangestuurd door dit systeem. Hierom zal de complete besturing van het eindproduct mogelijk moeten zijn via software. Maar aangezien het eindproduct ook zonder dit systeem moet kunnen
functioneren, moet er een besturingsinterface komen die dit beide mogelijk maakt. Om deze eisen elegant te integreren in het ontwerp zal er moeten worden nagedacht over een manier om dit beide mogelijk te maken zonder dat er te veel dubbel werk wordt gedaan.
Voor de ondersteuning van KITS zal er dus in ieder geval een Ethernet verbinding aanwezig moeten zijn voor de aansturing van het eindproduct.
Control Interface
Voor de losse interface van het systeem zijn er 2 logische mogelijkheden;
Een los bedieningspaneel.
Een besturing via de Ethernet controller doormiddel van een laptop.
Met oog op het eenvoudig houden van de hardware- en software eisen van het losstaande systeem, is er gekozen om de volledige besturing te laten geschieden via ethernet. Er zal dus een simpele applicatie worden geschreven als losse interface(user interface ofwel UI), die draait onder een Windows PC, en het losstaande systeem aanstuurt via ethernet.
Simulatie methode
Het eindproduct moet de beoogde tests uit kunnen voeren, en in kunnen spelen op mogelijke aanpassingen in de toekomst. Hierom is ervoor gekozen om het systeem op te bouwen als een generieke pakketgenerator. Dit betekent dat het systeem een bestand inleest, met een binair pakket en een timestamp. De generator kijkt niet naar de inhoud van het pakket, maar stuurt het simpelweg op tijd uit. Het pakket definieert hierbij alle informatie die wordt verstuurd, dus ook MAC adres en dergelijke. Dit maakt het mogelijk om het eindproduct ook te gebruiken voor het testen van andere typen pakketten, in plaats van alleen IEC61850-9-2. De intelligentie om een IEC61850-9-2 pakket samen te stellen komt dus voor de rekening van de aansturende applicatie.
Voeding
Vanuit de oriëntatie op de plaatsen waar de tests worden uitgevoerd door consultants blijkt dat er bepaalde eisen wordt gesteld aan de voeding van het eindproduct. De consultant moet het eindproduct kunnen gebruiken in verschillende omgevingen, waar niet altijd 230 volt aanwezig is. De volgende voeding is beschikbaar voor de consultant afhankelijk van de plek waarop de test wordt uitgevoerd, moet het eindproduct kunnen worden gevoed met voeding uit het lichtnet; 100 tot 250 volt AC (50 tot 60 Hz). Of kunnen worden gevoed met 24 volt DC.
Schematisch ontwerp
Bovenstaande gegevens zijn verwerkt in onderstaand schematisch ontwerp. Hierin zijn niet alle details(zoals hierboven beschreven) expliciet in weergegeven, maar deze zijn wel van toepassing op het functionele ontwerp. Ze zijn simpelweg niet opgenomen om de overzichtelijkheid behouden.
Input
Commando's over TCP-IP Ethernet(Ethernet link 0) IEEE1588 signaal(Ethernet link 1)
PPS-signaal(BNC)
Voeding aansluiting voor 24 volt DC, en een bijbehorende adapter om te voeden vanuit het lichtnet.
Output
status over TCP-IP Ethernet(Ethernet link 0) IEC61850-9-2 signaal(Ethernet link 1)
Overige details: Het geheel kan worden meegenomen in een laptoptas.
Dit ontwerp is goedgekeurd door de consultants, en er kan dus op basis van dit ontwerp een technisch ontwerp worden gespecificeerd.
6.3. Specificeren van ontwerp
In de aanpak is gedefinieerd dat er op basis van het functionele ontwerp een technische specificatie zal moeten worden opgesteld. Hier volgt het eerste deel van deze technische specificatie, namelijk de hardware.
6.3.1. Hardware
Nu er een akkoord is over de functionaliteit van het eindproduct kan de hardware gaan worden gedefinieerd.
Voeding
PPS clock signaal Ethernet link 0
Ethernet link 1 SMV92 simulator
Voorafgaande keuze
Er is voorafgaand aan het opstellen een keuze gemaakt met betrekking tot de hardware die een grote impact heeft voor de ontwikkeling van het project. Namelijk de afweging tussen het gebruik van een FPGA of een Microprocessor.
Tegenwoordig zijn FPGA's een stuk populairder geworden ten opzichte van de traditionele microprocessor. Het gebruik van een FPGA in de plaats van een microprocessor is een serieuze overweging geweest
Een FPGA heeft in dit geval het grote voordeel, dat de timing voor het versturen van IEC61850-9-2 pakketten volledig kan worden vastgelegd in de hardware. Hierdoor is deze timing tot op de nanoseconde deterministisch te maken.
Uiteindelijk is er toch gekozen voor een Microcontroller vanwege de volgende aspecten Het goedkoopste gevonden bord dat 2 ethernet poorten ondersteunt kost ongeveer 1000 euro. Dit betekend dat er dan geen reserve meer is voor andere tools zoals een debugger, of een interfacekabel.
Er moet IEEE1588 ondersteuning aanwezig zijn. Het zelf implementeren van deze ondersteuning zou zeer veel extra werk opleveren.
Er is geen kennis van VHDL aanwezig bij KEMA Consulting. Er is vooral een expertise voor softwareontwikkeling aanwezig. Er is ook geen interesse binnen de afdeling om dit te leren. Dit kan voor grote problemen zorgen bij het onderhouden van het eindproduct.
Er is geen directe behoefte voor het aanschaffen van een nogal kostbare
ontwikkellicentie voor dit enkele project. Hierdoor wegen de kosten van een licentie niet op tegen de baten.
Er zijn op het eerste gezicht wel ontwikkelborden beschikbaar met een microprocessor, die 2 ethernet controllers met IEEE1588 ondersteunen. Het grote voordeel van een hoge precisie van de timing is hierbij niet aanwezig, maar deze precisie is ook niet geëist.
Hardware Eisen
De opdracht met eisen/randvoorwaarden en functioneel ontwerp zijn hieronder eerst vertaald naar eisen die betrekking hebben op de hardware. Hierbij is gebruik gemaakt van de verkregen kennis uit de voorgaande stappen, en de logische conclusies hieruit. Op basis van deze eisen kan een hardware platform worden geselecteerd. Als dit platform is geselecteerd, kan er verder worden gekeken hoe de implementatie van de opdracht vorm zal krijgen op basis van deze hardware.
De meeste eisen zijn logische gevolgen uit de beschrijvingen van de voorgaande
stappen. Zo is er bijvoorbeeld al vermeld welke voedingsspecificaties er moeten zijn, en dat er consultants verder moeten kunnen ontwikkelen met het eindproduct(dus hieruit volgt dat er een gangbare taal zoals C/C++ de voorkeur heeft).
Er is 1 onderdeel waar nog geen volledige aandacht aan is besteedt, namelijk de jitter in de timing van het versturen van de pakketten. Er is wel al uiteengezet dat de standaard voorschrijft dat er maar 1 pakket per seconde mag worden afgeweken, en dat de klok op de microseconde nauwkeurig synchroon moet lopen. Het synchroniseren en versturen van pakketten ligt alleen iets genuanceerder. De afwijking van 1 Ns heeft betrekking op het nemen van sample's op een bepaald tijdstip. Normaal gesproken zit er (zoals in de beeldvorming besproken) een sensor in een onderstation die de stroom en spanning meet, en dit digitaal via IEC61850-9-2 verstuurd. Het is hierbij vooral van belang dat de timestamp bij de genomen sample tot op de microseconde accuraat is. Deze worden vervolgens beide in hetzelfde pakket verstuurd over het netwerk. Door de timestamp is het mogelijk om het signaal bij de ontvanger te reconstrueren. Dit mechanisme zorgt ervoor dat de sample timing tot bepaalde hoogte niet meer afhankelijk is van de latency en jitter in het netwerk tussen de IED's. Omdat het eindproduct een testapparaat is, zijn samples met timestamp vooraf al gedefinieerd.
Het eindproduct moet er dus alleen voor zorgen dat de pakketten binnen redelijke grenzen, op tijd worden verstuurd ten opzichte van de timestamp. Hiervoor wordt er teruggesprongen op de eis van precies of 4800 pakketten per seconde, met 1 pakket afwijking. 4800 pakketten per seconde is 1 pakket in 207 Ns. Om hier ruim binnen te blijven, is ervoor gekozen om een maximale jitter van 100 Ns toe te staan.
Let hierbij er wel op, dat het hier jitter in verzending betreft. De gesynchroniseerde klok in het systeem moet ervoor zorg dragen, dat een verlaat pakket er niet voor zorgt dat het volgende pakket ook te laat aankomt en de afwijking dus accumuleert.
De latency in het versturen van pakketten is niet gespecificeerd. Maar aangezien het hier gesimuleerde pakketten betreft, kan dit worden gesimuleerd door een andere timestamp mee te geven aan een pakket dan het tijdstip van het daadwerkelijk versturen.
Globale specificaties
Er moet een behuizing beschikbaar zijn voor het systeem
Het gehele platform mag niet meer dan 1000 euro kosten(hardware en ontwikkel omgeving)
Het platform moet beschikbaar zijn in Nederland(Het platform moet binnen een paar weken geleverd kunnen worden)
Het gehele systeem moet in een laptop-tas passen.
Het systeem moet voldoen aan de CE richtlijnen
Het systeem moet kunnen functioneren onder normale kantoor omstandigheden Het systeem moet gevoed kunnen worden met 24 volt DC en 110-230 volt AC.
Het moet een functioneel compleet product zijn (geen hardware ontwikkeling)
Hardware details
Het systeem moet een gangbare architectuur hebben(zoals i386, PPC of ARM) 2 Ethernet poorten met RJ-45 connector moeten beschikbaar zijn op het bord Het systeem moet een input voor PPS bezitten
Het systeem moet 1588 in de hardware ondersteunen(v1 and v2) voor de IEC61850-9-2 verbinding
De Ethernet controller in combinatie met de microcontroller moeten snel genoeg zijn om 4800 packets per seconde te kunnen sturen
Er moeten voldoende resources in het systeem aanwezig zijn om de
simulatiebestanden te kunnen inladen en uitvoeren voor een test van maximaal 4 seconden, met 4800 pakketten per seconde
Er moet een 100mbit full duplex Ethernet verbinding aanwezig zijn voor IEC61850- 9-2
Het systeem moet nauwkeurig de tijd kunnen bijhouden(op de microseconde) De Ethernet controller in combinatie met de microcontroller moeten deterministisch genoeg zijn, om een maximale jitter van +/-100 Ns te verzekeren
Ontwikkelings details
Er moet een OS met IP stack aanwezig zijn voor het platform Er moeten drivers aanwezig zijn voor het platform
Er moeten debug mogelijkheden zijn voor het platform
Er moet real-time functionaliteit beschikbaar zijn voor het platform
Er moet voorbeeldcode en ondersteuning zijn vanaf de fabrikant voor het platform Er moet een tool-chain met C of C++ ondersteuning aanwezig zijn
Vanuit deze technische eisen zijn verschillende leveranciers en fabrikanten benaderd. De gebruikte methode hierbij was op Internet zelf te zoeken en leveranciers te bellen om te vragen welke oplossing ze aanbieden voor mijn probleem. Benaderde bedrijven waren onder andere;
Acal Alcom Avnet silica
Beckhoff Nederland Top-electronics Texim
EBV
Synopsys DesignWare
De geschikte oplossingen die zijn gevonden, zijn verwerkt in een tabel die de voor en nadelen tegen elkaar afwegen. Deze vergelijking met onderbouwde conclusie is opgenomen in bijlage I.
Korte conclusie
Uit de vergelijking is gekomen dat het MPC8313e-RDB development board van Freescale de beste keus is. Dit is een ontwikkelbord met een PowerPC (RISC) architectuur die draait op 333 MHz, met 2 Ethernet controllers, die beide IEEE1588 ondersteunen. Het bord draait vanuit de fabriek Linux versie 2.6.23 met bijna alle peripheral drivers geïmplementeerd doormiddel van patches in de kernel. De ontwikkelomgeving is zo ingericht, dat een ontwikkelaar binnen een uurtje of 2 zijn eigen software (of customised kernel) kan draaien op het bord.
Deze oplossing is aangedragen door Erik Heimen van EBV, en EBV kan ook het bord leveren aan KEMA voor de prijs van 289 euro. De specifieke detail zijn opgenomen in bijlage II.
Overige Hardware
Zoals gedefinieerd in het functioneel ontwerp, zal de hardware in een behuizing moeten worden geplaatst. Deze behuizing zal in ieder geval geschikt moeten zijn voor het dagelijkse gebruik in een kantooromgeving. Het MPC8313e-RDB ontwikkelbord is
ontworpen om in bepaalde mini-itx kasten te kunnen worden gebouwd. Deze kasten zijn in alle soorten en maten beschikbaar, en bezitten meestal ook al een voeding die aan de eisen van het project voldoet. Het is simpelweg een kwestie van een geschikte kast selecteren. Hierom zal er dan ook niet veel tijd worden besteed aan keuze alternatieven.
Wanneer het bord in de kast is ingebouwd en aangesloten op de voeding, moet er alleen nog een BNC connector in de kast worden gemonteerd, voor het PPS signaal.
6.3.2. Software
Nu de hardware is gedefinieerd, kan er worden gekeken naar welke software er moet worden verkregen en/of ontwikkeld. Hieronder is het proces beschreven dat is doorlopen om tot de software eisen te komen.
Inlezen
Voordat er dieper in kan worden gegaan op de software, zal er eerst moeten worden verdiept in de MPC8313e PowerPC processor, en hoe deze functioneert. Hiervoor is er ruim voldoende documentatie beschikbaar op de website van Freescale;
Link: http://www.Freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC8313E Uit de documentatie kan onder andere worden geconcludeerd dat de software die vanuit de fabriek op het bord draait niet geschikt is voor integratie in het beoogde eindproduct.
De website van Freescale levert een lijst aan met software leveranciers die dit product ondersteunen. Freescale noemt een dergelijk software pakket; Board Support Package, afgekort BSP. Een BSP bevat een OS met alle drivers voor het betreffende bord.
Analyse van real-time eisen
Als we kijken naar het eindproduct hebben de real-time eisen maar betrekking op 2 onderdelen. Namelijk de tijdsynchronisatie, en het op tijd verzenden van pakketten. Uit de analyse van de MPC8313e is gebleken dat beide taken waarschijnlijk kunnen worden opgelost met een paar interrupt service routines en enige configuratie. Deze routines moeten het volgende gaan doen:
Een timer ISR zal een registerbit aanpassen in de Ethernet controller. Dit bit is een teken voor de Ethernet hardware om een vooraf klaargezet pakket te versturen. Dit
mechanisme is als enige bepalend voor de timing van het verzenden van pakketten.
De timer die het verzenden van pakketten moet timen, zal extern gesynchroniseerd moeten worden. Dit kan gedaan worden via PPS en IEEE1588;
Via PPS zal er een mechanisme moeten zijn dat de timing van de PPS puls vastlegt, en hierop de interne timer synchroniseert. Dit kan worden opgelost met een ISR die wordt ge-triggered door een PPS flank. Het is vanwege het ontwerp van het ontwikkelbord niet mogelijk om een externe trigger via de hardware aan een timer te koppelen.
Er is ervoor gekozen door de opdrachtgever om IEEE1588 nog niet te ondersteunen vanuit de software. De reden hiervan is tweeledig. Ten eerste is de IEC61850-9-2 standaard op dit punt nog niet duidelijk genoeg. Deze standaard is namelijk ook nog deels in ontwikkeling. Ten tweede is het niet van essentieel belang voor de huidige tests, aangezien er nog geen apparaten op de markt zijn die dit protocol ondersteunen. Deze functionaliteit kan later worden toegevoegd, doordat hier bij de hardware eisen wel rekening mee is gehouden.
Software eisen
Hieronder staat beschreven hoe voorgaande eisen zich vertalen naar de eisen van de software voor het betreffende platform.
Functionele eisen
De software moet commando's accepteren via een TCP verbinding.
De software moet diagnostische en performance informatie geven via een TCP verbinding.
De software moet signaalbestanden kunnen verwerken om bepaalde testcases te kunnen simuleren.
De software moet het verzenden van pakketten kunnen synchroniseren met PPS.
De software moet voorgedefinieerde testcases kunnen uitvoeren.
De software moet pakketten uit kunnen sturen conform IEC61850-9-2.
De software moet geüpdate kunnen worden via het Ethernet.
De software moet geschreven zijn in C/C++
Technische eisen
De software moet precies 4000 pakketten kunnen uitsturen met een foutmarge van 1 procent elke seconde
De software moet precies 4800 pakketten kunnen uitsturen met een foutmarge van 1 procent elke seconde
De software moet een jitter hebben van minder dan 100 microseconden tussen de pakketten
Aangekochte software moet niet meer kosten dan 300 euro De software moet TCP verbindingen ondersteunen
De software moet hardware drivers bezitten die geschikt zijn voor het MPC8313 ontwikkelbord
De software moet real-time mogelijkheden hebben De software moet bestands overdacht ondersteunen
De software moet in het geheugen van het ontwikkelbord passen De software moet ondersteund worden door de fabrikant
Voor de software moet documentatie beschikbaar zijn De software moet debug mogelijkheden hebben
De software moet multitask mogelijkheden hebben.
In bijlage III is een vergelijking opgenomen van de verschillende gevonden producten, met een vergelijking van de opties, en een verantwoording van de gemaakte keus.
Korte conclusie
Uit de vergelijking is naar voren gekomen dat de originele BSP met de real-time ADEOS- IPIPE patch de beste keus is. De originele BSP ondersteunt bijna alle gebruikte hardware, en ondersteund de belangrijkste eisen zoals een IP stack met ondersteuning voor TCP.
Ook is overal de source van beschikbaar, hierdoor kan functionaliteit eenvoudig worden uitgebreid. De oplossing is volledig gratis en voldoende gedocumenteerd op de website van Xenomai;
Link: http://www.xenomai.org/index.php/Main_Page
Omdat er eigenlijk geen noodzaak is voor een volledig real-time operating system met real-time taken, real-time memory management en real time IP-stack, is ADEOS-IPIPE ook een logische keuze. Er zal namelijk waarschijnlijk alleen gebruik worden gemaakt van interrupts om de diverse real-time taken in goede banen te leiden. Een Beschrijving van ADEOS-IPIPE is opgenomen in bijlage IV.
6.3.3. Testen
Nu er een platform met een real time operating system is geselecteerd, zullen diverse delen moeten worden getest om te controleren of het geheel kan werken zoals is bedoeld.
Er zal moeten worden getest of de timing van de interrupt afhandeling binnen de gestelde eisen van het project valt. Door dit te testen kan er worden bepaald of de geselecteerde software ook daadwerkelijk geschikt is voor gebruik binnen het project.
De hardware die wordt aangestuurd via de ISR is deterministisch tot in de nanosecondes.
Hierom is de meest significante factor die de jitter bepaald, de tijd tussen het vuren van de hardware interrupt, en het moment dat de ISR routine wordt aangeroepen. Als de jitter hiervan kleiner is dan 100 Ns. Kan de test als geslaagd worden beschouwd.
De latency is niet van belang, aangezien dit valt te compenseren met de timestamps. De tijd dat de processor binnen de ISR besteed is wel van belang, dit zal ook moeten worden gemeten.
Testcases:
testen of de timing van de interrupt afhandeling binnen de gestelde eisen van het project valt. De interrupt moet in ieder geval een jitter hebben van minder dan 100
microseconden.
Testen of de code execution time kort genoeg is om binnen de gestelde eisen van het project te functioneren. De code (met overhead) moet in ieder geval klaar zijn binnen de 207 microseconden. (4800 pakketten per seconde is elke 207 microseconden een
pakket)
Om de tests uit te kunnen voeren is het volgende gedaan:
Ontwikkelomgeving opzetten
Er moet een omgeving worden opgezet waarmee applicaties kunnen worden ontwikkeld voor de MPC8313e-RDB
Linux compileren met ontwikkelomgeving voor het platform
Omdat Linux gepatchet moet worden, moet deze kunnen worden gecompileerd voor de MPC8313e-RDB
Linux patchen met adeos ipipe
De kernel moet worden gepatched voor real-time functionaliteit Aangepaste kernel laden in het bordje
De gepatchte kernel moet worden getest op de MPC8313e-RDB. Hiervoor moet de kernel worden ingeladen, en gekeken of het geheel wil booten.
ISR schrijven die de jitter kan meten in de ISR afhandeling
Als de aangepaste kernel draait, kan er een simpele applicatie worden ontwikkeld die de gepatchte kernel gebruikt om de test uit te voeren. In deze applicatie zal er worden gereageerd op een GPIO input interrupt, en als actie een GPIO output inschakelen, wat dummy code uitvoeren en dan de GPIO output uitschakelen. De dummy code is de vervanging voor de routines die de pakketten gaan klaarzetten voor de Ethernet hardware. Deze routines zijn gebaseerd op de code uit de bestaande ethernet driver.
ISR software laden in het bordje
Het geheel moet in het bordje worden geladen, en kunnen worden gestart.
Meting uitvoeren met de software
Door een functiegenerator te zetten op de input kan de timing worden gemeten van de jitter en latency doormiddel van een oscilloscoop.
Conclusie
Het blijkt dat de ISR een absoluut maximale jitter heeft van 10 Ns, en hierbij een standaard deviatie van 0,4 Ns. De tijd dat de interrupt in de routine doorbrengt is ongeveer 3 Ns. Er is vervolgens gebeld met diverse fabrikanten van commerciële operating systems, met de vraag of hun product een betere performance kon leveren met betrekking op de jitter. Dit was volgens hen mogelijk tot een jitter van ongeveer 5 Ns. De performance van de geselecteerde software valt dus ruim binnen de gestelde eisen, en heeft een enigszins vergelijkbare performance in vergelijking met commerciële producten.
6.3.4. Software ontwerp
Als het operating system is geselecteerd kan er een compleet ontwerp worden gemaakt van de software zoals deze zal moeten worden geïmplementeerd in de uitvoering. Het volledige software ontwerp voor het platform is opgenomen in bijlage V, en is gebaseerd op onderstaande eisen;
Functionele eisen
De software moet commando's accepteren via een TCP verbinding.
De software moet diagnostische en performance informatie geven via een TCP verbinding.
De software moet signaalbestanden kunnen verwerken om bepaalde testcases te kunnen simuleren.
De software moet het verzenden van pakketten kunnen synchroniseren met PPS.
De software moet voorgedefinieerde testcases kunnen uitvoeren.
De software moet pakketten uit kunnen sturen conform IEC61850-9-2.
De software moet geüpdate kunnen worden via het Ethernet.
De software moet comtrade bestanden ondersteunen
Technische eisen
De software moet precies 4000 pakketten kunnen uitsturen met een foutmarge van 1 procent elke seconde
De software moet precies 4800 pakketten kunnen uitsturen met een foutmarge van 1 procent elke seconde
De software moet een jitter hebben van minder dan 100 microseconden tussen de pakketten
De software moet TCP verbindingen ondersteunen De software moet bestands overdacht ondersteunen
De software moet in het geheugen van het ontwikkelbord passen
Korte samenvatting
Het softwareontwerp is als volgt opgezet;
Implementatie
Om de software te implementeren moest er een kernel module worden ontwikkeld. Het is namelijk niet mogelijk om dingen zoals een ISR te schrijven vanuit een user-space
programma in Linux. Hiervoor is het boek "Linux Device Drivers" van O'Reilly veelvuldig gebruikt. Dit boek is gratis te downloaden van het Internet.
Initialisatie
De GPIO ISR is gekoppeld aan de input waar het PPS signaal aan verbonden is. Als de ISR vuurt wordt er gemeten hoeveel ticks dit was ten opzichte van de vorige puls. Door hier een gemiddelde van meerdere waarden te nemen, kan er een redelijk accurate waarde worden vastgesteldvoor het aantal timer ticks per seconde. Dit kan gebruikt worden om te berekenen, op hoeveel timer ticks het volgende pakket moet worden verstuurd. Hierdoor is dus de timer gesynchroniseerd
Verzending
Er wordt een binair bestand in geladen. Dit bestand bevat de pakketdata, en een timestamp.
Dit bestand wordt geïnterpreteerd en als een linked list in het geheugen gezet.
Vervolgens wordt de pakkettimer gestart, en de timeout waarde ingesteld. Deze instelling is aan de hand van de timer synchronisatie. Als de interrupt vuurt, wordt het pakket verzonden, en de volgende hierna klaar gezet. Hierna wordt de time-out weer opnieuw ingesteld voor het volgende pakket.
Als alle pakketten zijn verstuurd gaat de software weer naar de beginstand.
Het geheel kan natuurlijk gestart en gestopt worden. Ook zitten er diverse foutdetectie mechanismen ingebouwd.
User interface
Het geheel wordt aangestuurd vanuit een applicatie die draait op een Windows PC. De koppeling met KITS zal naderhand buiten dit project worden ontwikkeld. De user interface is gemaakt in de vorm van een .NET command line applicatie. De naam is 'SMV92Simulator.exe'. Deze applicatie kan het volgende;
