\section{Grundlagen}
\label{sec:grundlagen}

Dieses Kapitel beschreibt die Technologien, auf welche die weiteren
Ausf\"uhrungen aufbauen. Folgende Themengebiete werden als bekannt
vorausgesetzt:

\begin{itemize}
  \item die Programmiersprache C++. Ein gutes Nachschlagewerk ist \cite{stroustrup}
  \item die Programmiersprache C\#, sowie das .NET Framework. Einstieg in den Einsatz unter Linux bietet \cite{mono}
  \item Funktionsweise und Aufgaben von Betriebssystemen. Eine Einf\"uhrung bietet \cite{tanenbaum}
  \item Grundkenntnisse bei der Arbeit mit Linux (bash)
  \item Netzwerkprotokolle (TCP, IP) ausf\"uhrlich beschrieben in \cite{stevens}
  \item das OSI-Model (siehe \cite{black}) sollte bekannt sein
\end{itemize}

In diesem Kapitel wird der Stand der Technik im Bereich Kommunikation in der Automatisierungstechnik aufgezeigt, sowie neue Ans\"atze zur Kommunikation in der Automatisierungstechnik erl\"autert, das openSource Entwicklungsmodell vorgestellt und die Eigenschaften von Echtzeit-, embedded und verteilten Systemen beschrieben. Das Kapitel schlie\ss t mit einer Einf\"uhrung in (Real-time) CORBA \cite{corbaspec}, \cite{rtcorbaspec}.

\subsection{Kommunikation in der Automatisierungstechnik}

Computerbasierte Steuerungen werden auf verschiedenen Plattformen, in verschiedenen Programmiersprachen realisiert. W\"unschenswert w\"are eine plattform- und programmiersprachenunabh\"angige Kommunikation zwischen allen computerbasierten Steuerungen in Echtzeit. Es werden die Schwachstellen der momentan bekannten Kommunikationsstandards in der Automatisierungstechnik aufgef\"uhrt und Alternativen aufgezeigt. Es wird erl\"autert, weshalb sich die weiteren Untersuchungen auf die Middleware CORBA konzentrieren.

Momentan werden haupts\"achlich diese Techniken verwendet:

\begin{description}
\item[Bussysteme] wie Powerlink \cite{powerlink}, Profinet, DeviceNet \cite{odva}, CAN \cite{can}, SERCOS-III \cite{sercos}, InterBus \cite{interbus}, \dots erfordern spezielle Hardware in der Steuerung. Die ben\"otigten Treiber sind oft nur f\"ur wenige Plattformen verf\"ugbar.
\item[Softwarekopplung] Es gibt die Standards DCOM \cite{dcom}, OPC UA/XL \cite{opc} \dots, welche nicht echtzeitf\"ahig sind und eher auf die Bed\"urfnisse zur \"Uberwachung von Steuerungen ausgelegt wurden, als zur Steuerung.
\end{description}

Es gibt weitere Standards, die in computerbasierte Steuerungen integriert werden k\"onnten:

\begin{description}
\item[neues Protokoll] bedeutet enormen Aufwand, da es in s\"amtliche Systeme implementiert werden mu\ss .
\item[Webservices] wie SOAP \cite{soap} bl\"ahen die zu \"ubertragenden Daten enorm auf. Eine schnelle Daten\"ubertragung ist nicht realisierbar.
\item[Middleware] wird zur Kommunikation zwischen Plattformen und Programmiersprachen eingesetzt:
\begin{itemize}
\item RMI \cite{rmi} und JINI \cite{jini} sind nur f\"ur die JAVA Plattform verf\"ugbar und bieten keine M\"oglichkeit zur Echtzeitkommunikation
\item Ice \cite{ice} plattform- und programmiersprachenunabh\"angig, allerdings nicht echtzeitf\"ahig, daf\"ur sehr schnell (siehe auch Kapitel \ref{sec:ice})
\item CORBA ist ein Standard f\"ur den auch eine Real-time Erweiterung definiert wurde. Da es f\"ur fast jedes System eine CORBA Implementierung gibt, ist mit dieser Technologie eine plattform- und programmiersprachenunabh\"angige Echtzeitkommunikation denkbar
\end{itemize}
\end{description}

Vorteile von CORBA beim Einsatz in der Automatisierungstechnik:

\begin{itemize}
\item Ethernet als Kommunikationsschicht m\"oglich: 
\begin{itemize}
\item Steuerungen k\"onnen mit Lichtwellenleiterkabeln verbunden werden: elektrische Entkoppelung der vernetzten Anlagen; \"Ubertragung von elektrischen Feldern nicht beeinflu\ss bar
\item mit entsprechendem CORBA Protokoll routbar, ist allerdings mit einem Verlust der Echtzeit verbunden
\end{itemize}
\item Durch Priorisierung k\"onnen echtzeitkritische Instruktionen und Komfortfunktionen in einem System verarbeitet werden
\item Technologie seit Jahren im Einsatz und erfolgreich erprobt
\end{itemize}

Nun mu\ss\ gepr\"uft werden, ob eine entsprechende CORBA Implementation auf einem embedded Real-time Linux System lauff\"ahig ist, oder ob der Speicherbedarf zu gro\ss\ f\"ur die beschr\"ankten Ressourcen ist. Auch das Real-time Verhalten mu\ss\ gemessen und gegebenenfalls optimiert werden.

\subsection{openSource Entwicklungsmodell}
\label{sec:opensource}

Da es sich bei der eingesetzten Software um openSource Produkte handelt, wird im Folgenden auf die Besonderheiten einer derartig entwickelten Software eingegangen.

openSource bedeutet nicht nur das Offenlegen der Quelltexte zu jeder Softwarerelease, sondern gew\"ahrleistet Zugriff auf die Quelldateien, auch w\"ahrend des Entwicklungsprozesses. Durch die permanente Verf\"ugbarkeit der Quellen wurde openSource zu einer Technik des Softwareengineerings. 

Ein openSource Projekt wird von einem Maintainer geleitet. Seine Aufgabe ist, zu entscheiden, ob  und in welchem Umfang Quellcode von der Community in die Quellen des Projekts \"ubernommen wird. Die Community besteht in der Regel aus Programmierern und an dem Fortschritt der Software interessierten Benutzern. Meist wird in Mailinglisten diskutiert, ob und wie welche Features implementiert werden. openSource Projekte arbeiten benutzerorientiert. Um fr\"uh Feedback von den Benutzern der Software zu erhalten, wird diese in einem fr\"uhen Entwicklungsstadium ver\"offentlicht.

In dem Buch \emph{The Cathedral And The Bazaar} \cite{raymond:cathedral} wird die Entwicklung einer openSource Software mit einem orientalischen Basar verglichen. Den openSource Methoden gegen\"ubergestellt wird die Entstehung einer Software, deren Quellen nur bei einem Release offen gelegt werden: Kathedrale. Eine deutsche Zusammenfassung des Buches ist \cite{online:kath}.

Der Gro\ss teil der momentan kommerziell vertriebenen Software wird als \emph{closedSource} angeboten. Der Kunde kauft die f\"ur ein bestimmtes System erstellten Bin\"ardateien der Software. Anpassungen an die Bed\"urfnisse des Kunden k\"onnen nur vom Hersteller der Software durchgef\"uhrt werden. Somit ist der Kunde bei \"Anderungsw\"unschen und Support vom Hersteller abh\"angig.

Bei openSource Software besteht in der Regel die M\"oglichkeit, nicht die Software, sondern Support f\"ur die Software zu kaufen. 
Eigene Features k\"onnen entweder selber in die Software, oder durch die openSource Community gegen Bezahlung, implementiert werden.

\subsection{Echtzeitsystem}
\label{sec:Real-time}

Zun\"achst werden zum weiteren Verst\"andnis notwendige Begriffe definiert, anschlie\ss end wird auf den Unterschied zwischen harter und weicher Echtzeit eingegangen. Die Anforderungen an ein Echtzeitsystem werden geschildert. Am Beispiel von Funktionalit\"aten eines Autos wird die Dringlichkeit von Priorisierung vermittelt. In einem Unterkapitel werden die Unterschiede zwischen einem konventionellen und einem Echtzeit Betriebssystem erl\"autert.

\begin{description}
\item[Latenzzeit] ist die Dauer zwischen Aktion (zum Beispiel Tastendruck) und Reaktion (Darstellung des entsprechenden Zeichens auf dem Bildschirm).
\item[maximale Ausf\"uhrungszeit] eines Programms, ist die Zeit, die das Programm ben\"otigt um $n$ Datens\"atze zu verarbeiten (wird in der Regel als Formel abh\"angig von $n$ angegeben).
\item[Priorit\"at] beschreibt die Dringlichkeit eine Aufgabe abzuarbeiten. Je h\"oher die Priorit\"at desto wichtiger ist die Bearbeitung.
\item[Deadline] definiert den Zeitpunkt zu dem das Programm garantiert ein Ergebnis berechnet haben mu\ss : $Time_{deadline} = Time_{start} + Duration_{max}$. Ein Ergebnis nach diesem Zeitpunkt ist unter harten Echtzeitbedingungen unbrauchbar.
\end{description}

Ein Echtzeitsystem mit \emph{harten Echtzeitanforderungen} garantiert, dass das Ergebnis einer Berechnung innerhalb eines vorgegebenen Zeitintervalls $(0, Duration_{max}]$ geliefert wird. Die maximal erlaubte Bearbeitungsdauer $Duration_{max}$  f\"ur die Berechnung und die Einheit des Zeitintervalls wird von den Anforderungen an die Anwendung definiert.

Um \emph{harte Echtzeitbedingungen} in einem System gew\"ahrleisten zu k\"onnen, m\"ussen:
\begin{itemize}
\item alle Systemkomponenten ihre Aufgabe in einer definierten Zeit garantiert ausgef\"uhrt haben. Dies kann bei verschiedenen Komponenten schwierig (Festplatten mit Cache) bis unm\"oglich (TCP/IP geroutetes Netz) sein.
\item die vom Programm ben\"otigten Ressourcen (Speicher, CPU Leistung) bekannt und vorhanden sein.
\item die Dauer von Betriebssystemaufrufen bekannt sein.
\item die maximale Ausf\"uhrungszeit des eigenen Programms bekannt sein.
\end{itemize}

Ist von \emph{weichen Echtzeitanforderungen} die Rede, so darf ein definierter, geringer Prozentsatz aller Anfragen die Deadline \"uberschreiten. In industriellen Steuerungen ist diese Echtzeit unbrauchbar.

In der Regel sind nicht alle Aufgaben einer Applikation zeitkritisch. Beispielsweise ist es in einem Auto unverzichtbar, dass Sicherheitsfunktionen wie Airbag, ABS, ESP rechtzeitig funktionieren. Unwichtiger ist, dass der elektrische Fensterheber in kritischen Situationen latenzfrei reagiert. Dies geschieht, indem die Sicherheitsfunktionen h\"oher priorisiert werden, als die Komfortfunktionen. Eine Komfortfunktion darf niemals das Abarbeiten einer Sicherheitsfunktion behindern. W\"urde dies geschehen, w\"are von einer Priority Inversion die Rede.

\subsubsection[RTOS]{RTOS - Real-time Operating System - Echtzeitbetriebssystem}
\label{sec:rtos}
Konventionelle Betriebssysteme und Echtzeitbetriebssysteme unterscheiden sich am gravierendsten in der Implementierung des Schedulings. Insbesondere in der Implementierung der Warteliste. Sobald in der Warteliste eine h\"oher priorisierte Aufgabe, als die die gerade bearbeitet wird eintrifft, mu\ss\ ein RTOS die neu eingetroffene Aufgabe bearbeiten. Um dies ohne Zeitverluste gew\"ahrleisten zu k\"onnen, mu\ss\ bei einem RTOS das Auffinden der Aufgabe mit der h\"ochsten Priorit\"at in der Warteliste sehr effektiv implementiert sein.

Beim Umgang mit Semaphoren und Mutexen mu\ss\ bei der Implementation eines RTOS zus\"atzlich darauf geachtet werden, dass es bei verschieden priorisierten Aufgaben zu einer unerw\"unschten Priority Inversion kommen kann. Eine niedrig priorisierte Aufgabe h\"alt einen Mutex. Dieser wird kurz darauf von einer h\"oher priorisierten Aufgabe angefordert. In diesem Fall mu\ss\ vermieden werden, dass die h\"oher priorisierte Aufgabe solange blockiert, bis die niedriger Priorisierte den Mutex freigibt.

Ein RTOS mu\ss\ die Abarbeitung von Interrupts cachen, damit diese nicht die Ausf\"uhrung von Echtzeitaufgaben beeinflussen.

Die Reservierung von Speicher mu\ss\ in konstanter Zeit, unabh\"angig von der Menge des angeforderten Speichers erfolgen. Bietet das RTOS dieses Feature nicht, mu\ss\ der Programmierer vor der Echtzeitbearbeitung den von der Echtzeitroutine ben\"otigten Speicher reservieren.

Der vanilla Linux Kernel \cite{kernel} bietet momentan noch keine  ausreichende Grundlage f\"ur harte Echtzeit unter Linux. Der RT\_ PREEMPT PATCH (\cite{rt} und \cite{rtwiki}) von Ingo Molnar et al., fa\ss t die n\"otigen \"Anderungen f\"ur harte Echtzeit gegen\"uber dem vanilla Kernel zusammen.  Linus Torvalds ist mit der sukzessiven Integration des RT\_ PREEMPT Patches in die vanilla Sources einverstanden. Jede Menge Code aus dem RT\_ PREEMPT Patch wanderte mit 2.6.18 und 2.6.19 in die vanilla Sourcen. Weiteres wird mit den n\"achsten Kernel Releases folgen.

Neben Linux mit RT\_ PREEMPT Patch gibt es weitere (zum Teil kommerzielle) \emph{RTOS}es. Ein kleiner Auszug bekannter Systeme: RTLinux \cite{rtlinux}, INTEGRITY \cite{integrity}, Symbian OS \cite{symbian}, VxWorks \cite{vxworks}, Windows CE \cite{ce}, Microware OS 9 \cite{os9}\dots .

Bei TRUMPF Laser wird der Standard Kernel mit RT\_ PREEMPT Patch verwendet, da ein Laser \"uber 10 Jahre im Einsatz ist und kein kommerzielles Produkt mit entsprechend langem Supportzyklus angeboten wird. Ein weiterer Grund f\"ur Linux war die einfache Portierbarkeit des Codes, von dem zuvor eingesetzten Microware OS 9.

\subsection{embedded Systems}
\label{sec:embedded}
Ein embedded System wird f\"ur einen bestimmten Einsatzzweck in einem Ger\"at (Handy, CNC-Steuerung, Mikrowelle, Bordcomputer) entwickelt. Es wird in der Regel auf die standardisierte PC Peripherieschnittstellen (PS/2, Audio Out, USB, \dots) verzichtet. Daf\"ur besitzt ein solches System je nach Einsatzgebiet spezialisierte Schnittstellen, von parallelen I/O Ports, bis zu Feldbusinterfaces.

In den meisten F\"allen werden CPU, RAM, ROM, HDD (in Form eines Flashspeichers) und Schnittstellenwandlerbausteine (z.B. MAX 232 zur Generierung eines V24 COM-Port Signals) auf einer Platine verl\"otet (siehe Abb. \ref{img:embedded}).

\begin{figure}
\begin{center}
\includegraphics[width=0.5\textwidth]{./img/acmesystems.jpg}
\caption{embedded System (Quelle: http://www.acmesystems.it)}
\label{img:embedded}
\end{center}
\hrule
\end{figure}

Je nach Einsatzzweck wird das System in Assembler programmiert, oder die Applikation oberhalb eines Betriebssystems ausgef\"uhrt.

Da embedded Systeme \"uber einen l\"angeren Zeitraum als Desktop PCs eingesetzt werden und die Betriebsumgebungen deutlich h\"arter sind, m\"ussen diese robuster und wartungsarmer gebaut werden. Dies hat zur Folge, dass embedded Systeme nicht so leistungsf\"ahig sind wie ein ebenso aktueller PC. Trotzdem m\"ussen embedded Systeme oft  zeitkritische Berechnungen durchf\"uhren. Der Entwickler mu\ss\ deshalb sparsam mit den Ressourcen umgehen.

\subsection{verteilte Systeme}
\label{sec:distsys}

Nach der Definition des Begriffs wird an Beispielen der Einsatz von verteilten Systemen beschrieben.

F\"ur den Begriff verteiltes System, englisch Distributed System gibt es viele Definitionen.
\\
\begin{shadowenv}

A distributed computing system consists of multiple autonomous
processors that do not share primary memory, but cooperate by
sending messages over a communication network.

Henri Bal (Professor of Computer Science, Autor von \cite{bal:dist})
\\
\end{shadowenv}

\dots entspricht meiner Ansicht eines verteilten Systems.

\begin{figure}
\begin{center}
\includegraphics[width=0.6\textwidth]{./img/distsys.jpg}
 \caption{verteiltes System}
 \label{img:distsys}
\end{center}
\hrule
\end{figure}

Da sich die zu einem verteilten System zusammengefassten Rechner in der Regel keinen Speicherbereich teilen k\"onnen und Informationen \"uber Benutzereingaben, Anfragen, Ergebnisse und Zust\"ande austauschen m\"ussen ist eine Kommunikation \"uber ein Netzwerk unumg\"anglich (siehe Abb. \ref{img:distsys}). 

Ein Fallbeispiel: Der Benutzer tippt seine Aufgabe an Comp1 ein (1).  Dieser sendet \"uber das Netzwerk die Aufgabenstellung an den \emph{Spezialisten} f\"ur diesen Aufgabentyp, Comp3 (2). Comp3 berechnet die L\"osung und sendet diese an Comp1 (3) zur\"uck. F\"ur den Benutzer ist nicht ersichtlich ob Comp1, Comp2 oder Comp3 die L\"osung berechnet hat.

\piccaption{distcc: Overhead bei Senden, Empfangen, Abh\"angigkeiten\label{img:distcc}}
\parpic[f]{\includegraphics[width=8.5cm]{./img/distccmon.jpg}}
Die verteilte Aufgabenbearbeitung erm\"oglicht das Nutzen ungenutzter
Rechenkapazit\"aten, wie beispielsweise bei SETI@home\footnote{a
scientific experiment that uses Internet-connected computers in the Search for
Extraterrestrial Intelligence (SETI). You can participate by running a free 
program that downloads and analyzes radio telescope data. Informationen: 
\cite{seti}} oder distcc\footnote{freier, verteilter C/C++ Compiler \cite{distcc}} (siehe Abb. \ref{img:distcc}). 

In verteilten Systemen, in denen mehrere Computer den selben Dienst anbieten, 
kann die Rechenleistung des verteilten Systems gesteigert werden, indem ein 
weiterer Computer in das System eingebunden wird. Diese Leistungssteigerung 
verh\"alt sich allerdings keineswegs linear zur Rechnerzahl, da auch die Verwaltung 
der Aufgabenverteilung, das Sichern des Systems vor einem Komplettstillstand, 
falls ein Rechner ausf\"allt und eventuell vorhandene Abh\"angigkeiten von 
Berechnungen, einen nicht zu vernachl\"assigenden Verwaltungsaufwand bedeuten.

%\subsection{Middleware}
%\label{sec:middleware}

%Beginnend mit einer Beschreibung von Middleware werden in diesem Kapitel verschiedene Middleware Konzepte und Produkte vorgestellt.

%Ein \emph{verteiltes System} (siehe \ref{sec:distsys}) kann aus Rechnern mit
%verschiedenen Hardwarearchitekturen und Betriebssystemen bestehen. Um diese
%Heterogenit\"at auf einen gemeinsamen Nenner zu bringen wird \emph{Middleware} 
%eingesetzt.

%Des weiteren kann \emph{Middleware} den Softwarentwicklungsprozess beschleunigen, da L\"osungen f\"ur viele Aufgaben in einem Framework in abstrahierter Form zur Verf\"ugung gestellt werden.

%Die Problematik bei der Entwicklung von Middleware wird in \cite{vinhen} (Chapter 2.1, page 10) beschrieben:

%\begin{shadowenv}
%At a very general level, you can tackle the problem of developing applications
%for heterogeneous distributed systems by following two key rules.
%\begin{enumerate}
%  \item Find platform-independent models and abstractions that you can apply to
%  help solve a wide variety of problems.
%  \item Hide as much low-level complexity as possible without sacrificing too
%  much performance.
%\end{enumerate}
%\end{shadowenv}

%\subsubsection[Konzepte]{Middleware Konzepte}
%\label{sec:midkonz}

%Es gibt verschiedene Ans\"atze zur Implementierung von Middleware. Die wichtigsten werden nun kurz vorgestellt.

%\begin{description}
%\item[Object Request Broker (ORB):] Ein oder mehrere Server verwalten Objekte anhand von Regeln. Clients fordern ein Objekt an und benutzen dessen Methoden, lesen und/oder ver\"andern dessen Daten.
%\item[Publish - Subscriber:] Selbes Prinzip wie Mailinglisten. Ein Server
%kategorisiert Daten. Clients registrieren sich f\"ur bestimmte
%Informationskan\"ale und bekommen entsprechende Informationen entweder in bestimmten Intervallen (z.B. t\"aglich, sek\"undlich\dots) oder sofort bei Eintreffen zugestellt.
%\item[Message Oriented Middleware (MOM):] Vom Server an den Client
%\"ubermittelte Nachrichten werden gepuffert, bis diese vom Client abgearbeitet sind (\"Ahnlich einem POP-Mailserver).
%\item[Remote Procedure Call (RPC):] Client ruft Methoden auf dem Server auf.
%Server liefert Ergebnis. Wartet der Client auf das Ergebnis spricht man von
%einem synchronen Aufruf. F\"uhrt der Client sein Programm vorerst ohne das
%Ergebnis vom Server fort, so ist der Methodenaufruf asynchron.
%\end{description}

%\subsubsection[Produkte]{Middleware Produkte}

%Einige Middlewarel\"osungen mit verschiedenen Konzepten.

%\begin{description}
%\item[RMI]\footnote{http://java.sun.com/products/jdk/rmi/index.jsp (06.09.2006)} von Sun in und f\"ur Java implementierte Middlewarel\"osung nach dem RPC Konzept (siehe \ref{sec:midkonz}).
%\item[Jini] erweitert \emph{RMI}. So k\"onnen zum Beispiel im Netzwerk neu verf\"ugbare Dienste automatisch erkannt und angesprochen werden.\footnote{weitere Informationen: http://www.jini.org (06.09.2006)}
%\item[WebSphere MQ] ist eine \emph{MOM} (siehe \ref{sec:midkonz}) von IBM f\"ur eine high-level Integration von Businessprozessen.\footnote{http://www-306.ibm.com/software/integration/wmq/ (06.09.2006)}
%\item[CORBA (Common Object Request Broker)](siehe \ref{sec:corba}) spezifiziert einen \emph{ORB}(siehe \ref{sec:midkonz}) und eine \emph{MOM}(siehe \ref{sec:midkonz})
%\end{description}

\subsection{CORBA}
\label{sec:corba}

Es werden CORBA Implementationen vorgestellt, sowie die Komponenten und das Funktionsprinzip von CORBA erkl\"art.

CORBA ist eine sehr detailierte Spezifikation der Object Management Group (OMG) \cite{omg}. Diese Spezifikation wurde in verschiedenen Programmiersprachen von Softwareunternehmen und openSource Communities komplett oder nur teilweise implementiert. Eine CORBA Implementierung wird auch CORBA Distribution genannt. Die verschiedenen Distributionen sind, solange man sich auf die in der Spezifikation beschriebenen CORBA Features beschr\"ankt, untereinander kompatibel.

Einige CORBA Implementierungen:

\begin{description}
\item[JacORB] \cite{jacorb} ist eine freie openSource Implementation auf Java Basis mit einigen Monitoring Tools
\item[Orbacus]\cite{orbacus} von IONA auf Java basierende kommerzielle Implementation
\item[Visibroker]\cite{visibroker} von Borland, unterst\"utzt: Java, C++ und die .NET Sprachen
\item[The ACE Orb (TAO)]\cite{taohp} sehr komplette, freie, plattformunabh\"angige, openSource Implementation in C++ (Details siehe Kapitel \ref{sec:tao})
\end{description}

\piccaption{ein einfaches CORBA System\label{img:minCORBA}}
\parpic{\includegraphics[width=0.5\textwidth]{./img/minCORBA.jpg}}

Ein CORBA System besteht aus mindestens einem CORBA Server und einem CORBA Client (siehe Abb.  \ref{img:minCORBA}).

Der CORBA Server stellt ein oder mehrere Objekte zur Verf\"ugung. Der CORBA Client kann diese Objekte aus seiner Applikation heraus ansprechen. Die Programmlogik ist dabei die Selbe, als w\"urden sich die vom Server zur Verf\"ugung gestellten Objekte tats\"achlich auf dem Client befinden.

\piccaption{CORBA Object Request\label{img:objreq}}
\parpic{\includegraphics[width=0.45\textwidth]{./img/objRequest.jpg}}

Abbildung \ref{img:objreq} zeigt den Ablauf einer Objektanfrage. Der Stub serialisiert die zu \"ubertragenden Parameter. Der Object Request Broker (siehe Kapitel \ref{sec:orb}) routet die Anfrage zum Skeleton des entsprechenden Objekts, welcher die \"ubermittelten Parameter deserialisiert und den eigentlichen Aufruf absetzt.

Die Schnittstelle, zu dem vom Server angebotenen Objekt, wird in Interface Definition Language (IDL, siehe Kapitel \ref{sec:idl}) definiert.

\vspace{1.5cm}

\subsubsection[ORB]{ORB - Object Request Broker}
\label{sec:orb}

Der ORB routet Objektaufrufe zu dem zugeh\"origen Objekt und sorgt daf\"ur, dass zu einem  Aufruf geh\"orende out-, inout-Parametern und Exceptions an das aufrufende Objekt zur\"uckgeroutet werden. 

\begin{figure}[!htb]
\includegraphics[width=\textwidth]{./img/orb.jpg}
\label{img:orb}
\caption{ORB mit Schnittstellen zu Applikation und System}
\end{figure}

\paragraph{ORB Interface}
Das ORB Interface bietet Zugriff auf initiale CORBA Funktionen, wie zum Beispiel:
\begin{itemize}
\item narrow: Cast:\footnote{wandeln eines Datentyps in einen Anderen} Objektreferenz $\Leftrightarrow$ Stringrepr\"asentation
\item Zugriff auf verschiedene Services, zum Beispiel dem NamingService (siehe Kapitel \ref{sec:namingservice})
\item Holen des rootPOAs (siehe Kapitel \ref{sec:poa})
\end{itemize}

\paragraph{IFR - Interface Repository}
ORBs pflegen ein Interface Repository (IFR) in dem alle deaktivierten und aktivierten Objekte aufgelistet sind. Anhand eines Schl\"ussels (IOR - siehe Kapitel \ref{sec:ior}), welcher eine Anfrage abbildet, wird im IFR das zugeh\"orige Objekt gefunden.

\paragraph{DII - Dynamic Invocation Interface}
Das Dynamic Invocation Interface (DII) bietet die M\"oglichkeit ein Objekt zu beschaffen, welches zum Zeitpunkt der Compilierung noch nicht definiert war.

\paragraph[POA]{POA - Portable Object Adapter}
\label{sec:poa}
Ein Portable Object Adapter (POA) ist serverseitig f\"ur die Erstellung von CORBA Objekten und deren Zuweisung zu vom Programmierer erstellten Objekten zust\"andig.
Objekte m\"ussen hierzu mit Ihrem IOR (siehe Kapitel \ref{sec:ior}) bei einem POA registriert werden.

Es besteht die M\"oglichkeit, zur Strukturierung der Objekte, unterhalb eines rootPOAs weitere POAs anzulegen.

Zur Ressourcenschonung besteht die M\"oglichkeit anhand von Policies (siehe Kapitel \ref{sec:policies}) momentan von keinem Client benutzte Objekte zu deaktivieren und bei Bedarf wieder zu aktivieren. Dieser Vorgang l\"adt beziehungsweise entl\"adt ein Objekt in oder aus einem Servant. Ein Servant kann auch mehrere Objekte beherbergen und repr\"asentiert die Prozessor- und Speicheranbindung.

\subsubsection{Policies}
\label{sec:policies}
Policies werden einem POA zugewiesen, um den Umgang mit den Systemressourcen zu definieren.

Es kann zum Beispiel definiert werden,\dots

\begin{itemize}
\item \dots dass die G\"ultigkeit eines Objekts mit Beendigung des entsprechenden Serverprozesses erlischt, oder das Objekt weiter lebt.
\item \dots ob ein Servant bei Nichtbenutzung sofort deaktiviert wird, oder ob er noch f\"ur weitere Anfragen aktiviert bleiben soll.
\item \dots ob die ObjektID vom Benutzer oder vom ORB vergeben werden soll.
\end{itemize}

\subsubsection[IDL]{IDL - Interface Definition Language}
\label{sec:idl}
In der CORBA Spezifikation ist unter andrem die Interface Definition Language (IDL) spezifiziert. Diese dient der Definition von Schnittstellen, \"uber welche mit den Objekten kommuniziert werden kann. Will man eine ganze Instanz eines Objektes \"ubertragen, so muss eine Funktion definiert werden, welche das gew\"unschte Objekt zur\"uckliefert.

IDL unterst\"utzt Vererbung, Namespaces, Typdefinitionen, Definitionen von Strukturen, Enumerationen, Unions und Exceptions, sowie die Spezifikation von Zugriffsrechten. 
\"Ubergabeparameter von Funktionen sind immer gerichtet (in, out oder inout).

Ein IDL Compiler, welcher Bestandteil jeder CORBA Distribution ist, erzeugt aus dem IDL Code Programmcode, in einer vom ORB der Distribution unterst\"utzten Programmiersprache. So entsteht mindestens ein ClientStub und ein ObjectSkeleton pro Schnittstelle.

\subsubsection{DataType Mapping}
\label{sec:mapping}
Der IDL Compiler (siehe Kapitel \ref{sec:idl}) ist f\"ur das Umsetzen der IDL Datentypen in Datentypen der Zielsprache zust\"andig. 
In vielen F\"allen (zum Beispiel bei int, float, \dots) kann direkt in einen elementaren Datentyp der Zielprogrammiersprache gewandelt werden. Bei Datentypen, die in der Zielsprache nicht definiert sind erstellt der IDL Compiler Klassen, die den entsprechenden Datentyp repr\"asentieren. Beispielsweise f\"ur unsigned int in JAVA, oder selbst definierte Datentypen.

\subsubsection[IOR]{IOR - Interoperable Object Reference}
\label{sec:ior}
\"Ahnlich einem ObjectPointer in C++ stellt die Interoperable Object Reference (IOR) den Aufenthaltsort eines Objektes dar. Eine IOR ist nicht auf den Speicherbereich des eigenen Programms beschr\"ankt, sondern funktioniert weltweit, \"uber das Internet.

Es gibt verschiedene M\"oglichkeiten des IOR Aufbaus. In Tabelle \ref{tab:ior} ist eine M\"oglichkeit dargestellt.

\newpage

\begin{longtable}{|l||l|l|l|}
\hline
            & \textbf{Repository ID}                & \textbf{EndpointInfo}& \textbf{ObjectKey}\\
\hline
\hline
\textsl{Beispiel}    & IDL:nameSpace:1.0            & IIOP://myHost.de:567 & 98073sad;fg \\
            & IDL:nameSpace:/interFace:1.0          &                      & \\
            & IDL:nameSpace:/interFace/function:1.0 &                      & \\
\hline
\hline
\textsl{Erkl\"arung} & Position der Elemente in der IDL      & Position des Servers\footnote{Darstellung im Beispiel vereinfacht}
                                                                           & ORB spezifische\\
            &										&                      & ID\\
\hline
\caption{Aufbau einer IOR}
\label{tab:ior}
\end{longtable}

\subsection{Real-time CORBA}
\label{sec:rtcorba}

Es wird auf die Voraussetzungen f\"ur Real-time CORBA \cite{rtcorbaspec} (RTCORBA) eingegangen, sowie die Erweiterungen zum CORBA Standard \cite{corbaspec} erl\"autert.

Die OMG \cite{omg} beschreibt in der Real-time CORBA Specification, einer optionalen Erweiterung zur CORBA Spezifikation, die Implementationsrichtlinien eines Real-time ORBs mit zeitlicher Ende zu Ende Vorhersagbarkeit.

Um eine Ende zu Ende Vorhersagbarkeit zu erreichen, mu\ss\ eine Ende zu Ende Vorhersagbarkeit in allen Komponenten des Systems m\"oglich sein:
\begin{enumerate}
\item Scheduler des Betriebssystems
\item Betriebssystemaufrufe
\item ORB
\item Netzwerk, oder andere eingesetzte Kommunikationswege
\item Applikation
\end{enumerate}

Ist dies nicht der Fall, so kann keine Ende zu Ende Vorhersagbarkeit garantiert werden. Es ist bei einer Evaluation der Echtzeitf\"ahigkeiten eines verteilten Systems zu beachten, dass alle Komponenten echtzeitf\"ahig sind. Es gen\"ugt nicht, die Middleware alleine zu betrachten.

\begin{figure}
\begin{center}
\includegraphics[width=0.6\textwidth]{./img/rtcorbaext.jpg}
\label{img:corbaext}
\caption{Real-time CORBA Erweiterungen (Quelle: \cite{rtcorbaspec})}
\end{center}
\hrule
\end{figure}

In Abbildung \ref{img:corbaext} sind die spezifizierten Erweiterungen und deren Position im CORBA Model dargestellt, welche im Folgenden genauer beschrieben werden.

\subsubsection{RTCORBA Priority}
Damit RTCORBA plattformunab\"angig  Priorit\"aten richtig interpretiert, ist einem RTCORBA Objekt eine \emph{RTCORBA::Priority} zugeordnet.  Es kann nicht mit Betriebssystempriorit\"aten gearbeitet werden, da verschiedene Plattformen mit verschiedenen Priorit\"atenverteilungen arbeiten. Priority Mapping \"ubersetzt die RTCORBA Priorit\"at in die entsprechende Priorit\"at auf dem Zielbetriebssystem. \"Uber das RTCurrent Interface eines RTCORBA Objekts kann dessen Priorit\"at zur Laufzeit ver\"andert werden.

\subsubsection{Scheduling Service}
Der Scheduling Service ist f\"ur das priorit\"atengesteuerte Umschalten zwischen Threads zust\"andig. Zum Beispiel, wenn eine h\"oher priorisierte Anfrage w\"ahrend der Abarbeitung einer niedriger priorisierten Anfrage eintrifft. Hierzu kann je nach Implementierung zwischen verschiedenen Scheduling Algorithmen gew\"ahlt werden, oder eigene Algorithmen dynamisch eingebunden werden.

\subsubsection{RTORB - Real-time Object Request Broker}
Ein Real-time Object Request Broker (RTORB) ist eine Erweiterung des Standard CORBA ORBs und f\"ur die Instanzen der Real-time CORBA Objekte verantwortlich. 

\subsubsection{Threadpool}
Threadpools \cite{threadpools} stellen sicher, dass f\"ur eine bestimmte Objektzahl gen\"ugend voralokalisierte Ressourcen zur Verf\"ugung stehen. Ein Threadpool ist mit einem Real-time Portable Object Adapter (RTPOA) verbunden. So kann sichergestellt werden, dass ein RTPOA nur begrenzte Ressourcen zur Verf\"ugung hat. 

\subsubsection{Priorisierung der Netzwerkverbindung}
Zur Daten\"ubertragung stehen verschiedene Protokolle zur Verf\"ugung (z.B. IIOP, ESIOP, \dots). Es kann auch selbst ein Netzwerkprotokoll definiert und eingebunden werden.

Die Kommunikation kann \"uber mehrere Verbindungen stattfinden, welche verschieden priorisiert sind (Priority Banded Connections) oder es kann die Objektpriorit\"at auf das TOS Feld im IP Header gemapped werden. Bekommt ein RTORB eine nicht priorisierte Anfrage, z.B. von einem nicht Real-time f\"ahigen ORB,  so kann er diese entsprechend behandeln.

\subsection{CORBA Services}
\label{sec:services}

Es gibt eine Vielzahl von der OMG spezifizierter CORBA Services \cite{corbaservices}. 
CORBA Services sind CORBA Applikationen, die die CORBA Programmierung erleichtern, da sie oft ben\"otigte Funktionalit\"aten zur Verf\"ugung stellen.

Es werden hier nur die Services beschrieben, welche in der Diplomarbeit benutzt werden.

\subsubsection{NamingService}
\label{sec:namingservice}
Der CORBA NamingService \cite{namingspec} erleichtert das Auffinden von Objekten im Netzwerk. Der Server registriert ein Objekt mit Name und IOR (siehe Kapitel \ref{sec:ior}) beim NamingService. Ein Client kann anhand des Namens die IOR beim NamingService abrufen und dann mit Hilfe der IOR auf das Objekt zugreifen.

Der NamingService wird per Multicast im Netz gesucht. Alternativ kann beim Start der CORBA Applikation, Host und Port des laufenden NamingServices als Parameter mitgegeben werden.

\subsubsection{RT EventService}
\label{sec:rteventservice}
Die CORBA Implementation TAO (siehe Kapitel \ref{sec:tao}) implementiert zus\"atzlich zu dem von der OMG spezifizierten EventService \cite{eventspec}, einen Real-time EventService. Der von der OMG spezifizierte EventService empf\"angt Meldungen von sogenannten Suppliern. Eine Meldung besteht aus einem Header (SOURCE\_ ID und TYPE) sowie einem Datenteil.

Ein Consumer meldet sich bei einem EventService an. Hierbei gibt er an, wie der EventService ihm gegen\"uber auf neu eingetroffene Meldungen reagieren soll:

\begin{description}
\item[Pull Modell:] der Consumer schaut zyklisch beim Supplier nach, ob neue Meldungen vorhanden sind
\item[Push Modell:] der Supplier benachrichtet den Consumer \"uber neue Meldungen\dots
\begin{itemize}
\item \dots sobald eine neue Meldung eintrifft.
\item \dots sobald eine Meldung von bestimmten TYPE und, oder mit bestimmter SOURCE\_ID eintrifft.
\item \dots in einem definierten Intervall (zum Beispiel alle 5 Sekunden) werden alle aufgelaufenen Meldungen (von bestimmtem TYPE und, oder mit bestimmter SOURCE\_ID) weitergeleitet.
\end{itemize}
\end{description}

Der TAO Real-time EventService besitzt einen Scheduler um priorisierte Meldungen korrekt weiter zu verteilen. Da es in einer Echtzeitumgebung keinen Sinn macht Meldungen anzufordern, wurde das Pull Modell nicht implementiert. \cite{rtevent} Seite 65 ff erl\"autert die Architektur des RT Event Services und die Unterschiede zur OMG EventService Spezifikation \cite{eventspec}.

\subsection[Ice]{Ice - Internet Communication Engine}
\label{sec:ice}

Die Internet Communication Engine (Ice) \cite{ice} wird als hochperfomante Alternative zu CORBA angepriesen \cite{fw}. 

Zwar ist Ice \cite{iceintro} nicht Real-time f\"ahig, daf\"ur ebenso wie ACE/TAO plattform- und programmiersprachenunabh\"angig. Es wird eine Ice-Applikation zur \"Ubertragung eines Prozessabbildes erstellt, um einen Vergleichswert f\"ur die Performance von ACE/TAO RTCORBA zu haben.

Die Architektur von Ice ist sehr an die CORBA Architektur angelegt, allerdings deutlich einfacher gehalten.