diff --git a/datenmodell.png b/datenmodell.png deleted file mode 100644 index 5b3d162..0000000 Binary files a/datenmodell.png and /dev/null differ diff --git a/main.tex b/main.tex index 62414e5..694c9c9 100644 --- a/main.tex +++ b/main.tex @@ -55,291 +55,161 @@ } \mode -\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 : . +@prefix rdf: . +@prefix xsd: . +@prefix rdfs: . +@prefix foaf: . +@prefix 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 : . +@prefix rdf: . +@prefix xsd: . +@prefix rdfs: . +@prefix foaf: . +@prefix 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} \ No newline at end of file