Update on Overleaf.
This commit is contained in:
Anonymous
overleaf
parent
507958e1ca
commit
04d15498fe
BIN
datenmodell.png
BIN
datenmodell.png
Binary file not shown.
|
Before Width: | Height: | Size: 30 KiB |
390
main.tex
390
main.tex
|
|
@ -55,291 +55,161 @@
|
|||
}
|
||||
|
||||
\mode<presentation>
|
||||
\title{IEC 61850}
|
||||
\subtitle{Kommunikation und Datenmodell für Umspannwerke}
|
||||
\title{Intelligente Systeme}
|
||||
\subtitle{Ontologieprojekt: RDFS Ontologie }
|
||||
\author{Marcel Felix, Jan Philipp Timme}
|
||||
\date{\today}
|
||||
|
||||
\begin{document}
|
||||
\tableofcontents[hideallsubsections]
|
||||
|
||||
\begin{comment}
|
||||
http://www02.abb.com/global/sgabb/sgabb005.nsf/bf177942f19f4a98c1257148003b7a0a/e81bb489e5ae0b68482574d70020bf42/$FILE/B5_G2_Enhanced+protection+functionality+with+IEC+61850+and+GOOSE.pdf
|
||||
|
||||
* Process Bus ist meist schon in die IED gewandert, ansonsten kann er auch auf dem selben Netz laufen wie der Station Bus (Keine Sorgen machen, passt schon irgendwie)
|
||||
* GOOSE ist für IED<->IED, regelmäßige Updates, unregelmäßig bei Abweichungen etc.
|
||||
* SMV werden (vermutlich über GOOSE) zwischen den IED geteilt, die IED werden über SCL konfiguriert (stimmt das?)
|
||||
* Datenmodell ist zumindest im Grundkonzept interessant, da es mit GOOSE direkt zusammenpasst und somit stressfreier als Binärkram zu lesen ist (Interoperabilität) [Ja, aber halt nicht alle einzelnen möglichen Bestandteile durchgehen. Ich denke einfach eine Folie mit einer Übersicht zeigen und mal drüber fliegen wäre i.O]
|
||||
* Process Bus ist sehr nah an Switchgear angesiedelt; eine Bay in einer Substation ist soetwas wie ein Rack im Serverraum - Dinge für eine gemeinsame Aufgabe stecken dort zusammen - so die Ideee
|
||||
*
|
||||
\end{comment}
|
||||
|
||||
\section{Überblick}
|
||||
|
||||
\subsection{Überblick}
|
||||
\begin{frame}{Überblick}
|
||||
\begin{frame}{Szenario}
|
||||
\begin{itemize}
|
||||
\item Ausgangspunkt prorietäre Protokolle
|
||||
\begin{itemize}
|
||||
\item Binärkodierte Daten waren nur für Geräte des passenden Herstellers verwertbar
|
||||
\end{itemize}
|
||||
\item Arbeit an UCA\footnote{Utility Communications Architecture} begann
|
||||
\item Woraus der IEC 61850 enstand
|
||||
\end{itemize}
|
||||
Mit IEC 61850 soll die technische Weiterentwicklung zur Vereinfachung der Datenübertragung und -repräsentationen genutzt werden.
|
||||
\end{frame}
|
||||
\begin{comment}
|
||||
Früher hatte man wenig Bandbreite => Kommunikation erfolgte via wenigen bytes
|
||||
=> Das hat zum Nachteil, dass vorher viel abgesprochen werden muss
|
||||
=> welches byte bedeutet was, Konfiguration war aufwendig etc.
|
||||
Heute hat man viel Bandbreite zur verfügung
|
||||
=> Selbst erklärende Daten möglich
|
||||
Daraus enstand die UCA (Utility Communication Architecture)
|
||||
=> Grundstein für den IEC 61850 (GSSE stammt aus dem UCA (erwähnenswert?) <- Lieber nicht, GSSE und GOOSE sind zwei Paar Schuhe.
|
||||
\end{comment}
|
||||
|
||||
|
||||
\begin{comment}
|
||||
Aufbau des IEC 61850
|
||||
- Funktionale Anforderungen für Kommunikation in einer substation werden ermittelt
|
||||
- Diese Anforderungen dienen daraufhin dazu
|
||||
- Beispielsweise die Data Items und Service
|
||||
- Das Applikation Protokoll
|
||||
- das unterliegende transport, netzwerk, "data link" und physische "layer"
|
||||
zu finden, die diese Anforderungen erfüllen
|
||||
- Defintion der Data Items und Services die UNABHÄNGIG der darunter liegenden Protokolle sind.
|
||||
- Daraus entstehen ASCI (Abstract Communication Service Interface) für die Service
|
||||
- Und für die Data Models gibt es diese "Logical Nodes" (+ Sub-Typen) (Kommen ja später in dem Bild)
|
||||
- Hinzu kommen die: Common Data Classes (für die "common pieces" aus denen die data objects bestehen
|
||||
- Das Mappen der abstrakten Data Items / Services zu echten Protokollen.
|
||||
- MMS
|
||||
- GOOSE
|
||||
- Sample Measures Values (Aufnehmen/Sammeln/Umwandeln der "echten" anlogen werte?)
|
||||
- Process Bus.
|
||||
- Zwischendrin wird das SCL (Substation Configuration Language) erklärt. (XML Dialekt)
|
||||
- Formale beschreibung der Beziehung einer Substation und dem substation automation system (SAS)
|
||||
- ("Substation Automation System (SAS) software provides an intelligent solution to monitor, analyze, control, and protect today's modern substations")
|
||||
|
||||
- Eigentlicher Fokus war "inside" the substations. Wird jedoch auch für "Substation to Master" oder substation-to-substation communcation genutzt.
|
||||
-
|
||||
|
||||
<!------------------------------------------------------------------------------------------------------!>
|
||||
\end{comment}
|
||||
|
||||
\subsection{Struktur des IEC 61850}
|
||||
\begin{frame}{Struktur des IEC 61850}
|
||||
|
||||
\begin{minipage}{0.45\textwidth}
|
||||
\begin{itemize}
|
||||
\item Funktionale Anforderungen ermitteln (3-5)
|
||||
\item Definition der Substation Configuration Language (SCL) (6)
|
||||
\item Definition abstrakter \enquote{data items} und \enquote{services} (7)
|
||||
\item Mappen der abstrakten Typen auf Protokolle (8)
|
||||
\item Sample Measured Values (SMV) (9)
|
||||
\end{itemize}
|
||||
\end{minipage}
|
||||
\hfill
|
||||
\begin{minipage}{0.5\textwidth}
|
||||
\begin{figure}[f]
|
||||
\includegraphics[scale=0.20]{toc_IEC.png}
|
||||
\caption{Ralph Mackiewicz, Technical Overview and Benefits of \dots - Tabelle 1}
|
||||
\end{figure}
|
||||
\end{minipage}
|
||||
|
||||
\end{frame}
|
||||
|
||||
|
||||
\begin{comment}
|
||||
Device model begins with a physical device
|
||||
- defined by network address
|
||||
- contains one or more logical devices
|
||||
- Each Logical device contains one or more logical nodes
|
||||
- A logical node:
|
||||
- One or more "Named grouping of data und services" die in Verbindung zu einer power system function stehen.
|
||||
- Typ am ersten Buchstaben des namens erkennbar. "M" is metering/measurement.
|
||||
- (Kurze Folie mit übersicht einblenden, aber nicht näher drauf eingehen?!?!)
|
||||
- Weiter unterteilt in "sub datentyp"? Beispielsweise "Phase 2"
|
||||
- Erfüllt specification of CSC (common data class)
|
||||
- Bild von so einem CSC einblenden? (overview paper, seite 3 Fig. 2.)
|
||||
|
||||
|
||||
\end{comment}
|
||||
|
||||
\section{Datenmodell}
|
||||
|
||||
\begin{comment}
|
||||
Falls du das gebrauchen kannst :-)
|
||||
\end{comment}
|
||||
\subsection{Hierarchie definierter Typen/Objekte}
|
||||
\begin{frame}{Hierarchie definierter Typen/Objekte}
|
||||
\begin{figure}
|
||||
\includegraphics[scale=0.27]{IEC61850-7-2-F1.png}
|
||||
\captionsetup{labelformat=empty}
|
||||
\caption{IEC 61850-7-2, Abbildung 1}
|
||||
\end{figure}
|
||||
\end{frame}
|
||||
|
||||
\subsection{Datenmodell}
|
||||
\begin{frame}{Datenmodell}
|
||||
Definition verschiedener, hierarchischer Abstraktionsebenen
|
||||
\begin{itemize}
|
||||
\item Server $\rightarrow$ Logical Device $\rightarrow$ Logical Node $\rightarrow$ Data Object $\rightarrow$ Data Attribute
|
||||
\item Server enthalten mehrere Logical Devices
|
||||
\item Logical Devices arbeiten gemeinsam an einer Funktion
|
||||
\begin{itemize}
|
||||
\item \dots und enthaltene mehrere Logical Nodes
|
||||
\end{itemize}
|
||||
\item Logical Nodes enthalten Datenobjekte mit Attributen
|
||||
\end{itemize}
|
||||
$\Rightarrow$ Adressierung einzelner Datenattribute über voll qualifizierten \enquote{Pfad} möglich
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Datenmodell}
|
||||
\begin{figure}
|
||||
\includegraphics[scale=0.40]{UCAIUG-Slide15.png}
|
||||
\captionsetup{labelformat=empty}
|
||||
\caption{UCAIug Summit; IEC 61850 Tutorial, Folie 15}
|
||||
\end{figure}
|
||||
\end{frame}
|
||||
|
||||
|
||||
\begin{comment}
|
||||
=> Daten sind nun abstrakt. (Logical devices/nodes, common data class etc.)
|
||||
- Werden auf echtes Protokoll gemapped
|
||||
=> MMS (Manufacturing Message Specification)
|
||||
- Wurde gewählt, weil es leicht mit den Complexen Namen umgehen kann. Prinzipell jedoch jedes andere Protokoll denkbar,
|
||||
- (Kurze Folie die das IEC61850 to Object Mapping zeigen? Overview Paper, Seite 4, Table II)
|
||||
- (Kurze übersicht über das Mappen. Ein "control model" service wird zu read/write services, Logical device wird ein MMS Domain etc.)
|
||||
|
||||
\end{comment}
|
||||
|
||||
\section{Protokolle}
|
||||
\subsection{GOOSE}
|
||||
\begin{frame}{Protokolle: GOOSE}
|
||||
\begin{itemize}
|
||||
\item Generic Object Oriented Substation Events
|
||||
\item Baut direkt auf Ethernet (Layer 2) auf
|
||||
\begin{itemize}
|
||||
\item VLANs werden als Nachrichtenkanäle genutzt
|
||||
\item Peer-to-peer-Kommunikation über Multicast\footnote{Broadcasts innerhalb eines VLAN}
|
||||
\item Nachrichtenpriorität wird direkt über Ethernet-Header angegeben
|
||||
\end{itemize}
|
||||
\item IED$\Leftrightarrow$IED-Kommunikation
|
||||
\item Zustandsmeldungen (regelmäßig oder auch abhängig von Events/Wertabweichungen)
|
||||
\item Kommunikation via GOOSE hauptsächlich \textit{innerhalb} des Umspannwerks
|
||||
\item Welt der Spielekonsolen mit Bewertungen
|
||||
\item Spielekonsolen mit einigen Attributen beschrieben
|
||||
\item Spielekonsolen werden von Organisationen hergestellt
|
||||
\item Spielekonsolen haben einen Nachfolger/Vorgänger
|
||||
\item Organisationen haben einen CEO
|
||||
\item \dots
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\subsection{MMS}
|
||||
\begin{frame}{Protokolle: MMS}
|
||||
\begin{itemize}
|
||||
\item Manufacturing Message Specification
|
||||
\begin{itemize}
|
||||
\item Gemäß ISO 9506\footnote{Nachrichtenformate für Fertigungszwecke} standardisiert
|
||||
\item IEC 61850 definiert ein Mapping des Datenmodells für MMS
|
||||
\end{itemize}
|
||||
\item Client/Server-Protokoll
|
||||
\item Findet über TCP/IP (Layer 3) statt
|
||||
\item In unserem Kontext: Kommunikation zwischen HMI\footnote{Human Machine Interface} und IEDs
|
||||
\begin{itemize}
|
||||
\item \dots und somit auch ggf. zwischen Umspannwerken und Kontrollzentren
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\begin{frame}[fragile]{Selbstdefinierte Prädikate}
|
||||
\begin{lstlisting}
|
||||
:foundingYear rdf:type rdf:Property ;
|
||||
rdfs:domain foaf:Organization ;
|
||||
rdfs:range xsd:int .
|
||||
|
||||
:internetEnabled rdf:type rdf:Property ;
|
||||
rdfs:domain :GameConsole ;
|
||||
rdfs:range xsd:boolean .
|
||||
|
||||
:consoleName rdf:type rdf:Property ;
|
||||
rdfs:domain :GameConsole ;
|
||||
rdfs:range xsd:string .
|
||||
\end{lstlisting}
|
||||
\end{frame}
|
||||
|
||||
\begin{comment}
|
||||
\begin{frame}{Objektmapping von IEC 61850 auf MMS}
|
||||
\begin{figure}
|
||||
\includegraphics[scale=0.40]{mms_data_mapping.png}
|
||||
\caption{Ralph Mackiewicz, Technical Overview and Benefits of \dots - Tabelle 2}
|
||||
\end{figure}
|
||||
\end{frame}
|
||||
\end{comment}
|
||||
\begin{frame}[fragile]{Ein eigener Datentyp und mehr \dots}
|
||||
\begin{lstlisting}
|
||||
# rdfs:Datatype
|
||||
:PriceEur rdf:type rdfs:Datatype .
|
||||
:PriceEur rdfs:label "Preis in Euro"^^xsd:string .
|
||||
|
||||
# rdfs:subPropertyOf
|
||||
:predecessorOfConsole rdfs:subPropertyOf :relatedToConsole .
|
||||
:successorOfConsole rdfs:subPropertyOf :relatedToConsole .
|
||||
|
||||
\begin{comment}
|
||||
Es fehlt hier auf jeden fall noch irgendwas Praxis bezogenes. Aka wie wird das ganze umgesetzt/eingesetzt. (Ich denke, dass das spannende für das Projekt ist?!?!?)
|
||||
Laut der readme.
|
||||
- "betroffene Geräte"
|
||||
=> Geräte die irgendwas mit dem IEC zu tun haben
|
||||
-> Was haben sie zu zun? Kann man sicher eine tolle Grafiken aus der Präsi die du gestern geschickt hast übernehmen
|
||||
- "Beispiel für die Umsetzung eines einfachen Gerätes über den Standard."
|
||||
- Das geht irgendwie ein wenig Hand in Hand mit vorherigen Punkt bzw. kann man das verbinden?
|
||||
=> in einem (Praxisbezogenen) Bild die betroffenen Geräte aufzeigen
|
||||
=> Inklusive der Beziehung zu einander
|
||||
=> Kommunikation untereinader. Wer spricht was mit wem (und worüber)
|
||||
=> Daran kann man super den Station/Prozess Bus erklären, sowie am Beispiel aufzeigen, wer wie warum welches Datenpakete (über welchen layer) verschickt.
|
||||
|
||||
\end{comment}
|
||||
# rdfs:subClassOf
|
||||
:GameConsole rdf:type rdfs:Class .
|
||||
:PortableGameConsole rdf:type rdfs:Class .
|
||||
|
||||
\section{Datenfluss}
|
||||
|
||||
\begin{frame}{Datenfluss auf abstrakter Ebene}
|
||||
\begin{figure}
|
||||
\includegraphics[scale=0.7]{IEC61850-5-F3.png}
|
||||
\caption{IEC 61850-5, Abbildung 3}
|
||||
\end{figure}
|
||||
:PortableGameConsole rdfs:subClassOf :GameConsole .
|
||||
\end{lstlisting}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Schnittstellen eines IED}
|
||||
\begin{figure}
|
||||
\includegraphics[scale=0.7]{IEC61850-6-F18.png}
|
||||
\captionsetup{labelformat=empty}
|
||||
\caption{IEC 61850-6, Abbildung 18}
|
||||
\end{figure}
|
||||
|
||||
|
||||
\begin{frame}[fragile]{Überblick Daten A-Box (1/2)}
|
||||
\begin{lstlisting}
|
||||
@prefix : <http://example.com/ins_uebung/#> .
|
||||
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
|
||||
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
|
||||
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
|
||||
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
|
||||
@prefix rev: <http://purl.org/stuff/rev#> .
|
||||
|
||||
:Nintendo rdf:type foaf:Organization ;
|
||||
:ceo :Kimishima ;
|
||||
:foundingYear 1889 ;
|
||||
foaf:name "Nintendo Co., Ltd."^^xsd:string .
|
||||
|
||||
:Kimishima rdf:type foaf:Person ;
|
||||
foaf:familyName "Kimishima"^^xsd:string ;
|
||||
foaf:givenName "Tatsumi"^^xsd:string .
|
||||
|
||||
\end{lstlisting}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Kommunikationswege innerhalb eines Umspannwerks}
|
||||
\begin{figure}
|
||||
\includegraphics[scale=0.30]{IEC_OB_Substation_Architecture.png}
|
||||
\caption{Ralph Mackiewicz, Technical Overview and Benefits of \dots - Abbildung 6}
|
||||
\end{figure}
|
||||
\begin{frame}[fragile]{Überblick Daten A-Box (2/2)}
|
||||
\begin{lstlisting}
|
||||
:Switch rdf:type :PortableGameConsole .
|
||||
:Switch rev:hasReview :SwitchReviewByJPT .
|
||||
|
||||
:Wii rdf:type :GameConsole .
|
||||
|
||||
:Wii_u rdf:type :GameConsole ;
|
||||
:internetEnabled true ;
|
||||
:consoleName "Wii U"^^xsd:string ;
|
||||
:numOfSupportedControllers 8 ;
|
||||
:predecessorOfConsole :Wii ;
|
||||
:releaseYear 2012 ;
|
||||
:successorOfConsole :Switch .
|
||||
\end{lstlisting}
|
||||
...
|
||||
\end{frame}
|
||||
|
||||
\begin{comment}
|
||||
In dem Overview paper steht afaik eine gute Zusammenfassung.
|
||||
\end{comment}
|
||||
\section{Fazit}
|
||||
\begin{frame}{Fazit}
|
||||
Der IEC 61850 bringt sehr, sehr viel mit\footnote{Vor allem eine Menge an Text \dots}. \\
|
||||
Uns gefällt davon vor allem \dots
|
||||
\begin{itemize}
|
||||
\item \dots Interoperabilität durch Abstraktion der Daten/Services
|
||||
\item \dots das selbstbeschreibendes Datenmodell
|
||||
\item \dots vollständig \enquote{adressierbare} Datenattribute
|
||||
\item \dots günstige und einfache Installation/Integration von IEDs
|
||||
\begin{itemize}
|
||||
\item Freiheit bei der Wahl der Hersteller
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\vfill
|
||||
\dots und das war erst ein Teil des Standards!
|
||||
\begin{frame}[fragile]{T-Box (1/2)}
|
||||
\begin{lstlisting}
|
||||
@prefix : <http://example.com/ins_uebung/#> .
|
||||
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
|
||||
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
|
||||
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
|
||||
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
|
||||
@prefix rev: <http://purl.org/stuff/rev#> .
|
||||
|
||||
# Our own properties
|
||||
:ceo rdf:type rdf:Property ;
|
||||
rdfs:domain foaf:Organization ;
|
||||
rdfs:range foaf:Person .
|
||||
|
||||
:foundingYear rdf:type rdf:Property ;
|
||||
rdfs:domain foaf:Organization ;
|
||||
rdfs:range xsd:int .
|
||||
|
||||
:internetEnabled rdf:type rdf:Property ;
|
||||
rdfs:domain :GameConsole ;
|
||||
rdfs:range xsd:boolean .
|
||||
\end{lstlisting}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Quellen}
|
||||
\begin{itemize}
|
||||
\item IEC 61850
|
||||
\item Ralph Mackiewicz: Technical Overview and Benefits of the IEC 61850 Standard for Substation Automation
|
||||
\item Ralph Mackiewicz on UCAIug Summit 11/2011: IEC 61850 Tutorial
|
||||
\end{itemize}
|
||||
\begin{frame}[fragile]{T-Box (2/2)}
|
||||
\begin{lstlisting}
|
||||
:consoleName rdf:type rdf:Property ;
|
||||
rdfs:domain :GameConsole ;
|
||||
rdfs:range xsd:string .
|
||||
|
||||
:numOfSupportedControllers rdf:type rdf:Property ;
|
||||
rdfs:domain :GameConsole ;
|
||||
rdfs:range xsd:string .
|
||||
|
||||
:successorOfConsole rdf:type rdf:Property ;
|
||||
rdfs:domain :GameConsole ;
|
||||
rdfs:range :GameConsole .
|
||||
\end{lstlisting}
|
||||
\end{frame}
|
||||
|
||||
\begin{comment}
|
||||
\begin{frame}{Überblick}
|
||||
\begin{itemize}
|
||||
\item Zu erfüllende Anforderungen (????)h
|
||||
\item We can \enquote{know} a piece of information
|
||||
\item We can \enquote{share} it with other devices
|
||||
\item Protokolle (GOOSE, MMS, \dots)
|
||||
\item Bild: physikal/logical Device, Node, Data (Übergang zwischen Datenmodell und den Geräten)
|
||||
\item Architektur einer Substation
|
||||
\item Highlevel Services
|
||||
\item Datenmodell, Data classes, self describing, auf Elektronikkrams abgestimmt
|
||||
\item Substation Configuration Language (SCL) (nur am Rande?)
|
||||
\item Vorteile durch IEC 61850 und so?
|
||||
\end{itemize}
|
||||
\begin{frame}[fragile]{Anwendung von RDFS-Regeln}
|
||||
Gegeben sei folgende A-Box
|
||||
\begin{lstlisting}
|
||||
:Wii_U rdf:type :GameConsole .
|
||||
:Switch :successorOfConsole :Wii_U .
|
||||
\end{lstlisting}
|
||||
mit dieser T-Box
|
||||
\begin{lstlisting}
|
||||
:successorOfConsole rdf:type rdf:Property ;
|
||||
rdfs:domain :GameConsole ;
|
||||
rdfs:range :GameConsole .
|
||||
\end{lstlisting}
|
||||
Anwendung der Regel \texttt{rdfs2}
|
||||
\begin{lstlisting}
|
||||
s p o .
|
||||
p rdfs:domain c . ==> s rdf:type c .
|
||||
\end{lstlisting}
|
||||
Ergebnis:
|
||||
\begin{lstlisting}
|
||||
:Switch rdf:type :GameConsole .
|
||||
\end{lstlisting}
|
||||
\end{frame}
|
||||
\end{comment}
|
||||
|
||||
% The end.
|
||||
\end{document}
|
||||
Loading…
Reference in New Issue