Evaluation von ACE/TAO als Standard zur Realtime

CORBA Kommunikation in der Automatisierungstechnik

Seite: 2

Diplomarbeit zur Erlangung des akademischen Grades ”Diplom-Informatiker (Fachhochschule)“

Bearbeiter:  Manuel Traut

Matrikelnummer: ai15278

Betreuer:  Prof. Dr. rer. nat. Martin Zeller (Hochschule)

Dipl. Ing. Matthias Bühler (Trumpf Laser)

Bearbeitungszeit: 01.11.2006 - 28.02.2007

Zusammenfassung

t.b.d.

Abstract

t.b.d.

Inhaltsverzeichnis

1 Einführung 4

1.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1 Bedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.3 Optionenen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Grundlagen 6 2.1 freie Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 open Souce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Echtzeitsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 RTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 embedded Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5 verteilte Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5.1 Einsatzgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.6 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6.1 Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.6.2 Produkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.7 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.7.1 ORB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.7.1.1 ORB Interface . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.7.1.2 IFR - Interface Repository . . . . . . . . . . . . . . . . . . . 18 2.7.1.3 DII - Dynamic Invocation Interface . . . . . . . . . . . . . . 18 2.7.1.4 POA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.7.2 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.7.3 IDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.7.4 DataType Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.7.5 IOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.7.6 CORBA Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.7.6.1 NamingService . . . . . . . . . . . . . . . . . . . . . . . . 20 2.7.6.2 EventService . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.8 Realtime CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.8.1 Scheduling Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.8.2 RTORB - Realtime Object Request Broker . . . . . . . . . . . . . . . 21 2.8.3 RTCORBA Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.8.4 Threadpool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.8.5 Priorisierung der Netzwerkverbindung . . . . . . . . . . . . . . . . . . 22

Inhaltsverzeichnis  Seite: 2

2.8.6 zusätzliche Pollicies . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.9 DAIS - Data Acquisition for Industrial Systems . . . . . . . . . . . . . . . . . 22 2.10 DDS - Data Distribution Service . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Systemkonfiguration 23

3.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.1.1 realtime preemption . . . . . . . . . . . . . . . . . . . . . . 23 3.1.1.2 ACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1.3 gperf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1.4 TAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.2 embedded Windows XP . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.2.1 ACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.2.2 gperf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.2.3 TAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.3 dotgnu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.3.1 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.3.2 embedded Windows XP . . . . . . . . . . . . . . . . . . . . 26

3.1.4 RealTime Kernel Konfiguration . . . . . . . . . . . . . . . . . . . . . 26 3.1.5 DAIS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.5.1 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.5.2 embedded Windows XP . . . . . . . . . . . . . . . . . . . . 26

3.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.1 CPX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Aufwandsbewertung 27

Abbildungsverzeichnis I

Tabellenverzeichnis II

Abkürzungsverzeichnis III

Anhänge V

A Tools V A.1 latencyTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V

B Quelltexte XVI B.1 V1 Prozessabbild via TAO RTCORBA übertragen . . . . . . . . . . . . . XIX C Messergebnise XXV

C.1 V1 Prozessabbild via TAO RTCORBA übertragen . . . . . . . . . . . . . XXV C.1.1 ohne Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . XXV

Ehrenwörtliche Erklärung XXVI

1 Einführung

openSource, Automatisierungstechnik, osadl^{1}, Linux, plattformunabhängig, realtime, TRUMPF Gruppe^{2}

1.1 Aufgabenstellung

• Integration des ACE/TAO Frameworks^{3} für Realtime CORBA unter OSADL Realtime Linux und Windows XP (embedded)

• Integration des DAIS Server der Firma HOMAG unter OSADL Realtime Linux und Windows XP (embedded)

• Integration der C Sharp Library zur Ankopplung an ACE/TAO

• Programmierung von Clients unter C++ (und C Sharp) zum schnellen Datenaustausch über Ethernet

• Performance-Messungen und Optimierungen zum Echtzeitverhalten über Ethernet

1.1.1 Bedingungen

Alle im Rahmen der Diplomarbeit durchgeführten Erweiterungen von Open Source Projekte werden in diese Projekte zurückgeführt Ergebnisse der Untersuchungen werden voraussichtlich unter OSADL.ORG veröffentlicht.

1.1.2 Zielsetzung

• Übergabe einer Applikation unter C++ zum Austausch eines 1 kByte großen Prozessabbildes zwischen zwei Lasersteuerungen

• Bewertung des Frameworks bezüglich Footprint und Realtime Performance

• Zusammenstellung von Bibliotheken (Leitfaden) zur schnellen Adaption in Projekten

• Bewertung des personellen Aufwands beim Einsatz in embedded Systemen der TRUMPF-Gruppe

1http://www.osadl.org/ (05.09.2006)

2http://www.trumpf.com/ (05.09.2006)

3http://www.cs.wustl.edu/ schmidt/TAO.html (05.09.2006)

Einführung  Seite: 5

1.1.3 Optionenen

DDS: Integration und Untersuchung der Erweiterung DDS^{4} für optimierte Echzeitkommunikation

OPC: Implementation eines OPC-Servers auf Basis des Frameworks der Firma Softing^{5} und Anbindung an den DAIS Server

Die Optionen können zur Diplomarbeit dazugenommen werden, wenn die ersten Aufgaben zu schnell abgeschlossen werden können.

4http://www.dre.vanderbilt.edu/DDS/ (05.09.2006)

5http://www.softing.com/home/de/industrial-automation/products/opc/index.php (05.09.2006)

2 Grundlagen

Dieses Kapitel beschreibt die Technologien, auf welche die weiteren Ausführungen aufbauen. Da eine allumfassende Erklärung aller Grundlagen den Rahmen dieser Arbeit sprengen würden, werden folgende Themengebiet als bekannt vorausgesetzt:

• die Programmiersprache C++. Ein gutes Nachlagewerk ist [?]

• Funktionsweise und Aufgaben von Betriebssystemen. Eine Einführung bietet [?]

• Grundkentnisse bei der Arbeit mit Windows und Linux (bash)

• Netzwerkprotkolle (TCP, IP) sehr Ausführlich beschrieben in [?], auch das OSI-Model siehe [?] sollte bekannt sein.

• Die Mengenlehre, Wahrscheinlichkeitsrechnung

2.1 freie Software

Richard M. Stallman^{6} Urvater der freien Software Bewegung beschreibt die Ziele seiner Community der Free Software Foundation^{7}:

Free software is a matter of liberty, not price. To understand the concept, you should think of free as in free speech, not as in free beer.

Free software is a matter of the users’ freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom, for the users of the software:

freedom 0 The freedom to run the program, for any purpose.

freedom 1 The freedom to study how the program works, and adapt it to your needs. Access to the source code is a precondition for this.

freedom 2 The freedom to redistribute copies so you can help your neighbor.

freedom 3 The freedom to improve the program, and release your improvements to the public, so that the whole community benefits. Access to the source code is a precondition for this.

6http://www.stallman.org (11.09.2006)

7http://fsf.org (11.09.2006)

Grundlagen  Seite: 7

Sehr populär wurde freie Software mit dem Erfolg von GNU^{8}/Linux. Die Erfolgsgeschichte von Linux und freier Software wird sehr interessant in den Filmen Codename: Linux [?] und Revolution OS [?] vermittelt. Just For Fun - Wie ein Freak die Computerwelt revolutionierte [?] ist ein sehr lesenswertes Buch über den Linuxerfinder Linus Torvalds^{9}.

2.2 open Souce

Open Source bedeutet nicht nur das Offenlegen der Quelltexte zu jeder Softwarerelease, sondern das dauerhafte Offenlegen der Quellen. Durch die permanente Verfügbarkeit der Quellen wurde openSource zu einer Form der Softwareentwicklung.

Ein openSource Projekt wird von einem Maintainer geleitet. Seine Aufgabe ist es zu entscheiden, welcher Quellcode mit in das Projekt aufgenommen wird und welcher außen vor bleibt. Der Quellcode wird von Programmierern erstellt, die meißt in Mailinglisten diskutieren ob und wie welche Features implementiert werden sollen. Open Source Projekten arbeiten sehr benutzerorientiert. Um möglichst früh Feedback von den Benutzern der Software zu erhalten wird diese in einem sehr frühen Entwicklungsstadium veröffentlicht.

In dem Buch The Cathedral And The Bazaar [?] wird die Entwicklung einer openSource Software mit einem (orientalischen) Basar verglichen. Den openSource Methoden gegenübergestellt wird die Entstehung einer freien Software derren Quellen nur bei einem Release offen gelegt werden (Kathedrale). Eine deutsche Zusammenfassung des Buches ist [?]

2.3 Echtzeitsystem

Vorweg einige wichtige Begriffe:

Latenzzeit ist die Dauer zwischen Aktion (zum Beispiel Tastendruck) und Reaktion (Darstellung des entsprechenden Zeichens auf dem Bildschirm).

Jitter Varianz der Latenzzeit (Schwankung der Reaktionszeiten)

maximale Ausführungszeit eines Programms, ist die Zeit, die das Programm benötigt um n Datensätze zu verarbeiten (wird in der Regel als Formel abhängig von n angegeben)

Priorität beschreibt die Dringlichkeit eine Aufgabe abzuarbeiten. Je höher die Priorität desto wichtiger ist die Bearbeitung

Deadline definiert den Zeitpunkt zu dem das Ergebnis benötigt wird:= T_{start} + D_{max}. Eine Bearbeitung nach diesem Zeitpunkt ist unter harten Echtzeitbedingungen sinnlos.

8GNU is Not Unix 9http://www.cs.helsinki.fi/u/torvalds/ (11.09.2006)

Ein Echtzeitsystem mit harten Echtzeitanforderungen garantiert, dass das Ergebnis einer Berechnung innerhalb eines vorgegebenen Zeitintervalls (0, D_{max}] geliefert wird. Die maximal erlaubte Bearbeitungsdauer D_{max} für die Berechnung und die Einheit des Zeitintervalls wird von den Anforderungen der Anwendung definiert.

In der Praxis ist oft auch von weichen Echtzeitanforderungen die Rede:

\frac{(∑_{k=1}^{n} D_{n})}{n} < D_{max}  (1)

Der Durchschnitt aller Bearbeitungsdauern D_{1...n} der n Aufgaben liegt unter einer definierten Schranke D_{max}.

Um Echtzeitbedingungen in einem System gewährleisten zu können müßen:

• alle Systemkomponenten ihre Aufgabe in einer definierten Zeit garantiert ausgeführt haben. Dies kann bei verschiedenen Komponenten schwierig (Festplatten mit Cache) bis unmöglich (TCP/IP geroutetes Netz) sein.

• die vom Programm benötigten Resourcen (Speicher, CPU Leistung) bekannt und vorhanden sein

• die Dauer von Betriebssystemaufrufen bekannt sein

• die maximale Ausführungszeit des eigenen Programms bekannt sein

In der Regel sind nicht alle Aufgaben einer Applikation zeitkritisch. Beispielsweise ist es in einem Auto wichtiger, dass Sicherheitsfunktionen wie Airbag, ABS, ESP rechtzeitig funktionieren, als der elektrische Fensterheber. Dies geschieht, indem die Sicherheitsfunktionen höher priorisiert werden, als die Komfortfunktionen.

2.3.1 RTOS - RealTime OperatingSystem - Echtzeitbetriebssystem

Der wichtigste Unterschied zwischen einem konventionellen OS und einem RTOS liegt in der Implementierung des Schedulings, genauer in der Implementierung der Warteliste. Sobald in der Warteliste eine höher priorisierte Aufgabe, als die die gerade bearbeitet wird eintrifft, sollte die neu eingetroffene Aufgabe bearbeitet werden. Das Auffinden der Aufgabe mit der höchsten Priorität in der Warteliste sollte sehr effektiv implementiert sein.

Beim Umgang mit Semaphoren mußbei der Implementation eines RTOS zusätzlich darauf geachtet werden, dass es bei verschieden priorisierten Aufgaben zu einer unerwünschten priority inversion kommen kann. Eine niedrig priorisierte Aufgabe reserviert einen Semaphore welcher anschließend von einer höher priorisierten Aufgabe angefordert wird. In sollchen Fällen sollte vermieden werden, dass die höher priorisierte Aufgabe solange blockiert, bis die niedriger Priorisierte den Semaphore wieder freigibt.

In einem RTOS sollten Funktionen zur Verfügung stehen, die es ermöglichen Interrupts zu cachen, damit diese nicht die Ausführung von sehr hoch priorisierten Aufgaben blockieren.

Die Lokalisierung von Speicher mußin konstanter Zeit, unabhängig von der Menge des angeforderten Speichers erfolgen.

Der vanilla Linux Kernel^{10} bietet momentan keine Grundlage für ein RTOS. Abhilfe schafft der realtime preemption patch^{11} von Ingo Molnar, welcher auch in dieser Diplomarbeit verwendet wird. UPDATE: TRUMPF Laser und Thomas Gleixner waren maßgeblich bei der Integration der RT-Patches in den vanilla Kernel 2.6.18 beteiligt. Somit ist jetzt jedes Standard Linux realtimefähig!

Es gibt unzählige weitere RTOSes. Ein kleiner Auszug bekannter Systeme: … RTLinux, Be-OS, INTEGRITY, LynxOS, Symbian OS, VxWorks, Windows CE, ….

2.4 embedded Systems

Ein embedded System wird für einen bestimmten Einsatzzweck in einem Gerät (Handy, CNC-Steuerung, Mikrowelle, Bordcomputer) entwickelt. Es wird in der Regel auf die standardisierte PC Peripherieschnittstellen (PS/2, Audio Out, USB, …) verzichtet. Dafür besitzt ein solches System Schnittstellen, je nach Einsatzgebiet vom simplen Parallelport, bis hin zu Feldbusinterfaces.

In den meißten Fällen wird 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ötet (siehe Abb. 1).

10http://kernel.org (11.09.2006)

11http://www.redhat.com/ mingo/realtime-preempt/ (11.09.2006)

Abbildung 1: embedded System (Quelle: http://www.acmesystems.it)

Je nach Einsatzzweck wird das System vom Hersteller direkt in Assembler programmiert, oder es wird ein Betriebssystem (Windows CE, Windows XP embedded, VxWorks, …) aufgespielt.

Da embedded Systeme länger als Desktop PCs eingesetzt werden und die Betriebsumgebungen deutlich härter sind (vom Weltraum bis zum U-Boot) müßen sie robuster und wartungsarmer gebaut werden. Dies hat zur Folge, dass sie lange nicht so leistungsfähig sind als ein ebenso aktueller PC. Dafür müßen sie oft zeitkritische Berechnungen durchführen, was ein enorm sparsamer Umgang mit den spärlich vorhandenen Resourcen bedeutet.

2.5 verteilte Systeme

Für den Begriff verteiltes System, englisch Distributed System gibt es viele Definitionen. Wobei man mehrere eigenständige Rechner bearbeiten gemeinsam eine Aufgabe als den kleinsten gemeinsamen Nenner der meißten Definitionen ansehen kann.

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 [?])

A distributed system is one in which the failure of a computer you didn‘t even know existed can render your own computer unusable.

Leslie Lamport (*1941 Informatiker, Forschungsgebiet z.B. Prozesssynchronisation)

A distributed system is a collection of independent computers that appears to its users as a single coherent system.

Andrew S. Tanenbaum (*1944 Professor für Informatik, Autor von Minix)

Abbildung 2: einfaches verteiltes System

Da sich die zum verteilten System zusammengefassten Rechner in der Regel keinen Speicherbereich teilen können und Informationen über Benutzereingaben, Anfragen, Ergebnisse und Zustände austauschen müßen ist eine Kommunikation über ein Netzwerk unumgänglich (siehe Abb.2).

Abbildung 3: distcc Monitor als Beispiel für Verwaltungsoverhead senden, empfangen, Abhängigkeiten

Die verteilte Aufgabenbearbeitung ermöglicht z.B. das Nutzen ungenutzter Rechenkapazitäten, wie beispielsweise bei SETI@home^{12} oder distcc^{13} (siehe Abb. 3).

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ält sich allerdings keineswegs linear zur Rechnerzahl, da auch die Verwaltung der Aufgabenverteilung, das Sichern des Systems vor einem Komplettstillstand, falls ein Rechner ausfällt und eventuell vorhandene Abhängigkeiten von Berechnungen einen nicht zu vernachlässigenden Verwaltungsaufwand bedeuten.

2.5.1 Einsatzgebiete für verteilte Systeme Abbildung 4: Schema: Onlinenavigation

12a 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.

Beschreibung von [?] 13freier, verteilter C/C++ Compiler: http://distcc.samba.org/ (06.09.2006)

(Quelle: http://www.navme.de)

Fernwartungssysteme: Eine computergesteuerte Fertigungsanlage, welche via Internetüberwacht, neu konfiguriert und programmiert werden kann.

Onlinenavigationslösungen: Von einem Handy aus wird via Internet eine Routenanfrage gestellt. Der entfernte Rechner berechnet die Route und sendet diese an das entsprechende Handy.^{14}

vernetztes Haus: Türklingel, Kühlschrank, Alarmanlage, Fernseher, Telefon, Rollläden, … und Computer sind miteinander verbunden um den Wohnkomfort und die Sicherheit zu maximieren. Es können die verschiedensten Szenarios program-

miert werden: Einbruch, Alarm, Videoanruf bei Polizei, mit Bild der Uberwachungskameras; Bestellen von Artikeln aus dem Internet via Fernbedienung und TV …^{15}

Multiplayer Games: Die Spieler sind via LAN oder Internet miteinander verbunden. Anstatt gegen virtuelle Gegner zu spielen, werden die Gegner von den Mitspielern gesteuert.

2.6 Middleware

Ein verteiltes System (siehe 2.5) kann aus Rechnern mit verschiedenen Hardwarearchitekturen und Betriebssystemen bestehen. Um diese Heterogenität auf einen gemeinsamen Nenner zu bringen wird Middleware eingesetzt.

Des weiteren soll Middleware den Softwarentwicklungsprozess beschleunigen, da Sie ständig wiederkehrende Funktionen auf einem hohen Level abstrahiert.

Die Grundlegende Problematik wird in [?] beschrieben:

14zum Beispiel: http://www.heise.de/newsticker/meldung/70361 (06.09.2006)

15weitere Informationen: http://www.heise.de/newsticker/meldung/56929 (06.09.2006)

At a very general level, you can tackle the problem of developing applications for heterogeneous distributed systems by following two key rules.

1. Find platform-independent models and abstractions that you can apply to help solve a wide variety of problems.

2. Hide as much low-level complexity as possible without sacrificing too much performance.

2.6.1 Middleware Konzepte

Es gibt verschiedene Ansätze zur Implementierung von Middleware. Die wichtigsten werden nun kurz vorgestellt.

Object Request Broker (ORB): Ein oder mehrere Server verwalten Objekte nach definierten Regeln. Clients fordern ein Objekt an und benutzen dessen Methoden, lesen und/oder verändern dessen Daten.

Publish - Subscriber: Selbes Prinzip wie Mailinglisten. Ein Server kategorisiert Daten. Clients registrieren sich für bestimmte Informationskanäle und bekommen entsprechende Informationen entweder in bestimmten Intervallen (z.B. täglich, sekündlich…) oder sofort bei Eintreffen zugestellt.

Message Oriented Middleware (MOM): Vom Server an den Client übermittelte Nachrichten werden gepuffert, bis diese vom Client abgearbeitet sind (Ähnlich einem POP-Mailserver).

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ührt der Client sein Programm vorerst ohne das Ergebnis vom Server fort, so ist der Methodenaufruf asynchron.

2.6.2 Middleware Produkte

Einige Middlewarelösungen mit verschiedenen Konzepten.

RMI ^{16} von Sun in und für Java implementierte Middlewarelösung nach dem RPC Konzept (siehe 2.6.1).

Jini erweitert RMI. So können zum Beispiel im Netzwerk neu verfügbare Dienste automatisch erkannt und angesprochen werden.^{17} WebSphere MQ ist eine MOM (siehe 2.6.1) von IBM für eine high-level Integration von

16http://java.sun.com/products/jdk/rmi/index.jsp (06.09.2006)

17weitere Informationen: http://www.jini.org (06.09.2006)

Businessprozessen.^{18}

CORBA (Common Object Request Broker) (siehe 2.7) spezifiziert einen ORB(siehe 2.6.1) und eine MOM(siehe 2.6.1)

2.7 CORBA

CORBA ist eine sehr detailierte Spezifikation (siehe [?]) der OMG (Object Management Group). Diese Spezifikation wurde in verschiedenen Programmiersprachen von Softwareunternehmen und openSource Communities mehr oder weniger komplett implementiert. Eine CORBA Implementierung wird auch CORBA Distribution genannt.

Im Folgende eine (bei weitem nicht vollständige) Auflistung einiger CORBA Implementierungen:

JacORB ^{19} ist eine freie openSource Implementation auf Java Basis mit einigen Monitoring Tools.

Orbacus ^{20} von IONA auf Java basierende kommerzielle Implementation.

Visibroker ^{21} von Borland unterstützt Java, C++ und die .NET Sprachen.

The ACE Orb (TAO) (siehe ??)

Abbildung 5: ein einfaches CORBA System

Ein CORBA System besteht aus mindestens einem CORBA Server und einem CORBA Client (siehe Abb. 5).

Der CORBA Server stellt ein oder mehrere Objekte zur Verfügung. Der CORBA Client kann diese Objekte aus seiner Applikation heraus ansprechen. Die Programmlogik ist dabei die Selbe, als würden sich die vom Server zur Verfügung gestellten Objekte tatsächlich auf dem Client befinden.

18http://www-306.ibm.com/software/integration/wmq/ (06.09.2006)

19http://www.jacorb.org (06.09.2006)

20http://www.iona.com/products/orbacus.htm (06.09.2006)

21http://www.borland.com/us/products/visibroker/index.html (06.09.2006)

Abbildung 6: CORBA Object Request

Abb. 6 zeigt stark vereinfacht den Ablauf einer Objektanfrage. Der Stub serialisiert die zu übertragenden Parameter. Der Object Request Broker (siehe 2.7.1) routet die Anfrage zum Skeleton des entsprechenden Objekts, welcher die übermittelten Parameter deserialisiert und den eigentlichen Aufruf absetzt.

Die Schnittstelle zu dem vom Server angebotenen Objekt wird in einer speziellen Sprache (IDL^{22} (siehe 2.7.3) definiert.

2.7.1 ORB - Object Request Broker

Der ORB routet Objektaufrufe zu dem zugehörigen Objekt und sorgt dafür, dass zu einem Aufruf gehörende out-, inout-Parametern und Exceptions an das aufrufende Objekt zurückgeroutet werden.

22Interface Definition Language

Abbildung 7: ORB mit Schnittstellen zu Applikation und System

2.7.1.1 ORB Interface Das ORB Interface bietet Zugriff auf intiale CORBA Funktionen.

• narrow: Cast:^{23} Objektreferenz ⇔ Stringrepräsentation

• Zugriff auf verschiedene Services, zum Beispiel dem NamingService (siehe 2.7.6.1)

• Holen des rootPOAs (siehe 2.7.1.4)

23wandeln eines Datentyps in einen Anderen

2.7.1.2 IFR - Interface Repository

ORBs pflegen ein Interface Repository in dem alle deaktivierten und aktivierten Objekte aufgelistet sind. Anhand eines Schlüssel (IOR - siehe 2.7.5), welcher eine Anfrage abbildet, wird im IFR das zugehörige Objekt gefunden.

2.7.1.3 DII - Dynamic Invocation Interface

Das Dynamic Invocation Interface (DII) bietet die Möglichkeit ein Objekt zu beschaffen, welches zum Zeitpunkt der Compilierung noch nicht definiert war. Diese Schnittstelle wird auch vom CORBA Messaging Service verwendet.

2.7.1.4 POA - Portable Object Adapter

Ein POA ist serverseitig für die Erstellung von CORBAObjekten und derren Zuweisung zu vom Programmierer erstellten Objekten zuständig. Objekte müßen hierzu mit Ihrem IOR (siehe 2.7.5) bei einem POA registriert werden.

Es besteht die Möglichkeit unterhalb eines rootPOAs weitere POAs anzulegen; ähnlich einer Ordnerstruktur eines Dateisystems.

Zur Resourcenschonung besteht die Möglichkeit anhand von Policies (siehe 2.7.2) momentan von keinem Client benutzte Objekte zu deaktivieren und bei Bedarf wieder zu aktivieren. Dieser Vorgang lädt bzw. entlädt ein Objekt in bzw. aus einem Servant. Ein Servant kann auch mehrere Objekte beherbergen und repräsentiert die Prozessor- und Speicheranbindung.

2.7.2 Policies

POA Policies werden einem POA zugewiesen, um den Umgang mit den Systemresource zu definieren.

Es kann zum Beispiel definiert werden…

• … dass die Gültigkeit eines Objekts mit Beendigung des entsprechenden Serverprozesses erlischt, oder das Objekt weiter lebt.

• … ob ein Servant bei Nichtbenutzung sofort deaktiviert wird, oder ob er noch für weitere Anfragen aktiviert bleiben soll.

• … ob die ObjektID vom Benutzer oder vom ORB vergeben werden soll 2.7.3 IDL - Interface Definition Language

Die Interface Definition Language ist in der CORBA Spezifikation [?] spezifiziert und dient der Definition von Interfaces^{24}, über welche mit den Objekten kommuniziert werden kann. Will man eine ganze Instanz eines Objektes übertragen, so muss eine Funktion definiert werden, welche das gewünschte Objekt liefert.

IDL unterstützt außerdem Vererbung, Namespaces, Typdefinitionen, Definitionen von Strukturen, Enumerationen, Unions und Exceptions, sowie die Spezifikation von Zugriffsrechten. Übergabeparameter von Funktionen sind immer gerichtet (in, out oder inout).

Ein IDL Compiler, welcher in jeder CORBA Implementation vorhanden sein muß, erzeugt aus dem IDL Code Programmcode in einer, der vom ORB der Distribution unterstützten Programmiersprache. So entstehen mindestens ein ClientStub und ein ObjectSkeleton pro Interface.

2.7.4 DataType Mapping

Der IDL Compiler (siehe 2.7.3) ist für das Umsetzen der IDL Datentypen in Datentypen der Zielsprache zuständig. In vielen Fällen (in der Regel, zum Beispiel bei int, float, …) kann direkt in einen elementaren Datentyp der Zielprogrammiersprache gewgewandelt werden. Bei Datentypen, die in der Zielsprache nicht definiert sind erstellt der IDL Compiler Klassen, die den entsprechenden Datentyp repräsentieren.

2.7.5 IOR - Interoperable Object Reference

Ähnlich einem ObjectPointer unter C++ stellt die Interoperable Object Reference den Aufenthaltsort eines Objektes dar. Allerdings ist die IOR nicht auf den Speicherbereich des eigenen Programms beschränkt, sondern funktioniert theoretisch sogar weltweit, über das Internet.

Es gibt verschiedene (sehr ähnlichhe) Möglichkeiten des IOR Aufbaus. In Tabelle 1 ist eine Möglichkeit dargestellt.

Repository ID  EndpointInfo  ObjectKey
Beispiel IDL:nameSpace:1.0  IIOP://myHost.de:567 98073sad;fg

IDL:nameSpace:/interFace:1.0

IDL:nameSpace:/interFace/function:1.0

Erklärung Position der Elemente in der IDL  Position des Servers^{25} ORB spezifische

ID

Tabelle 1: Aufbau einer IOR 2.7.6 CORBA Services

24Schnittstellen 25Darstellung im Beispiel vereinfacht

Es gibt eine Vielzahl von der OMG spezifizierter CORBA Services. Es werden hier nur die Services kurz beschrieben, welche in der Diplomarbeit benutzt wurden.

2.7.6.1 NamingService

Der CORBA NamingService erleichtert das Auffinden von Objekten im Netz. Der Server registriert ein Objekt mit Name und IOR (siehe 2.7.5) 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.

2.7.6.2 EventService

Der CORBA EventService empfängt 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über auf neu eingetroffene Meldungen reagieren soll:

• gar nicht, der Consumer schaut selber nach ob neue Meldungen da sind (Pull Modell)

• der Supplier benachrichtet den Consumer über neue Meldungen (Push Modell)

– sobald irgendeine neue Meldung eintrifft

– sobald eine Meldung mit bestimmter TYPE ID eintrifft

– in einem definierten Intervall (z.B. alle 5 sec.) werden alle aufgelaufenen Meldungen (mit bestimmter TYPE ID) weitergeleitet

2.8 Realtime CORBA

Die OMG beschreibt in der Real-time CORBA Specification [?], einer optionalen Erweiterung zu [?], die Implementationsrichtlinien eines CORBA ORBs mit Ende zu Ende Vorhersagbarkeit.

Um eine Ende zu Ende Vorhersagbarkeit zu erreichen mußeine Ende zu Ende Vorhersagbarkeit in den einzelnen Komponenten möglich sein:

1. Scheduler des Betriebssystems

2. ORB

3. Netzwerk, oder andere eingesetzte Kommunikationswege 4. Applikation

Abbildung 8: Realtime CORBA Erweiterungen (Quelle: [?])

In Abb. 2.8 sind die spezifizierten Erweiterungen und derren Position im CORBA Model dargestellt, welche im Folgenden genauer beschrieben werden.

2.8.1 Scheduling Service

Der Scheduling Service ist für das prioritätengesteuerte Umschalten zwischen Threads zuständig. Zum Beispiel, wenn eine höher priorisierte Anfrage während der Abarbeitung einer niedriger Priorisierten Anfrage eintrifft. Hierzu kann je nach Implementierung zwischen verschiedenen Scheduling Algorithmen gewählt werden. Dies wird über die Schnittstelle RTCORBA::Current, welche jedes CORBA Objekt besitzt, gesteuert.

2.8.2 RTORB - Realtime Object Request Broker

Ein RTORB ist eine Erweiterung zum Standard ORB und für die Instanzen der Realtime COR-BA Objekte (generiert aus RTCORBA IDL interfaces) verantwortlich.

2.8.3 RTCORBA Priority

Einem RTCORBA Objekt ist eine RTCORBA::Priority zugeordnet, welche die vom Scheduling Service benötigten Informationen über deren Priorität liefert. Diese Abstraktion ist notwendig, da Prioritäten nicht auf jedem System gleich definiert sind und CORBA auch zur Kommunikation zwischen verschiedenen Betriebssystemen eingesetzt werden kann. Priority Mapping übersetzt die CORBA Priorität in die entsprechende Priorität auf dem Zielbetriebssystem.

2.8.4 Threadpool

Threadpools stellen sicher, dass dem Programmierer für eine bestimmte Objektzahl genügend voralokalisierte Resourcen zur Verfügung stehen. Ein Threadpool ist mit einem RTPOA verbunden. So kann sichergestellt werden, dass ein RTPOA nur begrenzte Resourcen zur Verfügung hat.

2.8.5 Priorisierung der Netzwerkverbindung

Zur Datenübertragung stehen verschiedene Protokolle zur Verfügung (z.B. IIOP, ESIOP, …). Es kann auch selbst ein Netzwerkprotokol definiert werden.

Die Kommunikation kann über mehrere Verbindungen stattfinden, welche verschieden priorisiert sind (Priority Banded Connections). Bekommt ein RTORB auf der Standardverbindung eine somit nicht priorisierte Anfragen von einem nicht RT fähigen ORB, so kann er diese entsprechend behandeln.

2.8.6 zusätzliche Pollicies

Es wurden weitere Policies zur Client- bzw. Serverkonfiguration definiert. Zum Beispiel können

• Invocation Timeouts definiert werden, um die Vorhersagbarkeit des Systems zu verbessern.

• mit Hilfe der Priority Banded Connection Policy können beispielsweise diffServ Informationen zur Priorisierung der RTCORBA Daten in die TCP Pakete geschrieben werden.

2.9 DAIS - Data Acquisition for Industrial Systems

bla

2.10 DDS - Data Distribution Service

bla

3 Systemkonfiguration

3.1 Software

Folgende Kapitel stellen eine Zusammenfassung von [?] und eigenen Erfahrungen dar.

Es wird beschrieben, wie die aktuelle stable Distribution of The ACE ORB(TAO) Version 1.5^{26} (siehe ??, ??) unter Windows XP embedded und unter Linux mit Ingo Molnars realtime preemption patch installiert und konfiguriert wird.

3.1.1 Linux

Damit der CORBA NamingService unter Linux funktioniert, muß:

• /etc/hosts^{27} die Gegebenheiten des lokalen Netzwerks wiederspiegeln.

• im Linux Kernel die Optionen IP:Multicasting, IP Tunneling und Multicast Routing aktiviert sein.

3.1.1.1 Ingo Molnars realtime preemption patch

Wie in Kapitel 2.3.1 angemerkt, müßen Linuxkernel neuer 2.6.17 nicht mehr gepatched werden. Es sollte dennoch überprüft werden ob die unten beschriebenen Kernelkonfigurationen eingestellt sind. Ist dies nicht der Fall, sollte die Konfiguration angepasst werden und der Kernel neu kompiliert werden.

Der realtime preemption patch sollte nur auf die vanilla Kernel Quellen angewendet werden. Die aktuelle vanilla Quellen können von http://www.kernel.org heruntergeladen werden. Anschließend werden die Kernel Quellen werden ins Verzeichnis /usr/src/ entpackt. Der eventuel vorhandene Link auf die aktuellen Kernel sourcen wird entfernt und ein neuer Link auf die aktuellen Kernel sourcen erstellt.

1 wget  http ://www.kernel .org/pub/linux /kernel /v2.6/linux -2.6.16. tar.gz
2 tar  xzvf  linux -2.6.16. tar.gz -C /usr/src/
3 cd /usr/src
4 unlink  linux
5 ln -sf linux -2.6.16  linux
6 cd linux

Nun muß an die Variable EXTRAVERSION in /usr/src/linux/Makefile noch die Zeichenfolge rtpreempt angehängt werden. Dies kann zum Beispiel mit dem Editor vi erledigt werden.

1 vi Makefile
2 ..

26http://www.cs.wustl.edu/ schmidt/TAO.html (01.09.2006)

27Konfigurationsdatei: Zuordnung IP-Adressen zu Rechnernamen

Systemkonfiguration  Seite: 24

Es ist darauf zu achten, dass der realtime preemption patch mit der selben Versionsnummer heruntergeladen wird, wie die zuvor heruntergeladenen vanilla Quellen. Vor dem eigentlichen Patchvorgang sollte zuerst ein dryrun durchgeführt werden, wenn dieser fehlerfrei verläuft kann der kernel gepatched werden.

1 wget  http ://people .redhat .com/mingo /realtime -preempt /patch -2.6.16- rt29
2 patch  --dry-run  -p1 < patch -2.6.16- rt29
3 patch  -p1 < patch -2.6.16- rt29

Um nicht die ganze Kernelkonfigurationsarbeit zu wiederholen, kann die momentan aktuelle Kernelkonfiguration übernommen werden. Es müssen dann nur noch die mit dieser Version neu dazugekommen Features konfiguriert werden. Um die Realtime Funktionalität zu erhalten, sind die angegebenen Fragen entsprechend zu beantworten.

1 cp /boot /config -<aktuelle  kernel  version > .config
2 make  oldconfig

3

4 High  Resolution   Timer  Support  (HIGH_RES_TIMERS  ) [N/y/?]  (NEW) y

5

6 Preemption   Mode
7 1. No Forced  Preemption   (Server ) (PREEMPT_NONE  )
8 2. Voluntary  Kernel  Preemption   (Desktop ) (PREEMPT_VOLUNTARY  )
9 3. Preemptible   Kernel  (Low-Latency  Desktop ) (PREEMPT_DESKTOP  ) (NEW)
10 > 4. Complete  Preemption   (Real -Time ) (PREEMPT_RT ) (NEW)
11 choice [1-4]:  4

12

13 /proc  stats f o r preemptible   RCU  read -side  critical  sections  (RCU_STATS ) [Y/
      n/?]  (NEW) y
14 RT Mutex  debugging , deadlock  detection  (DEBUG_RT_MUTEXES  ) [Y/n/?]  (NEW) y
15 Built -in scriptable   tester f o r rt-mutexes  (RT_MUTEX_TESTER  ) [N/y/?]  (NEW) y
16 Non-preemptible   critical  section  latency  timing  (CRITICAL_PREEMPT_TIMING   ) [
      N/y/?]  (NEW) y

Letzter Schritt ist das Kompilieren des Kernels und der Module, sowie das Anpassen des Bootmanagers. Es wird von der Benutzung von grub als Bootmanager ausgegangen, wie es bei den meißten Distributionen der Fall ist. Weitere Hilfen zur grub Konfiguration unter:

http://www.gentoo.de/doc/de/handbook/handbook-x86.xml?part=1&chap=10#doc chap2

1 make  && make  modules_install
2 cp arch /i386 /boot /bzImage  /boot /kernel -rt
3 cp .config  /boot /config -rt
4 cp System .map  /boot /System .map-rt
5 vi /boot /grub /menu .lst
6 > title             RT patched  vanilla  2.6.16
7 > root              (hd0,0)
8 > kernel            /kernel -rt root =/dev/sda2

Systemkonfiguration  Seite: 25

Nun kann das System neu gebootet werden. Es ist darauf zu achten, dass beim Systemstart der Realtime Kernel ausgewählt wird.

3.1.1.2 ACE 1. Archiv entpacken

1 cd /opt
2 tar  xzvf  ACE+TAO-1.4 a_with_latest_patches   .tar.gz
3 cd ACE_wrappers
4 mkdir  1.4a
5 mv * 1.4a

2. Umgebungsvariablen setzen

1 echo  'export  ACE_ROOT =/opt/ACE_wrappers  /1.4 a' >> /etc/profile
2 echo  'export  LD_LIBRARY_PATH  =$ACE_ROOT /lib:$LD_LIBRARY_PATH  ' >> /etc/

      profile

3 echo  'export  PATH =$ACE_ROOT /bin:$PATH ' >> /etc/profile
4 source  /etc/profile

3. Konfigurationsdateien erstellen

1 echo  '#include  "ace/config -linux .h"' > $ACE_ROOT /ace/config .h
2 echo  'include  $(ACE_ROOT )/include /makeinclude  /platform_linux  .GNU' >
      $ACE_ROOT /include /makeinclude  /platform_macros  .GNU

4. in das Verzeichnis ACE wechseln und ACE übersetzen

1 cd $ACE_ROOT
2 make

3.1.1.3 gperf gperf^{28} wird von TAO benötigt.

1. in das Verzeichnis gperf wechseln und gperf übersetzen

1 cd $ACE_ROOT /apps /gperf
2 make

28Programmbeschreibung: http://www.cs.wustl.edu/ schmidt/PDF/gperf.pdf (01.09.2006)

Systemkonfiguration  Seite: 26

3.1.1.4 TAO 1. Umgebungsvariable setzen

    1 echo  'export  TAO_ROOT =$ACE_ROOT /TAO' >> /etc/profile
    2 source  /etc/profile

2. in das Verzeichnis TAO wechseln und TAO übersetzen

    1 cd $TAO_ROOT
    2 make

3.1.2 embedded Windows XP 3.1.2.1 ACE 3.1.2.2 gperf 3.1.2.3 TAO 3.1.3 dotgnu 3.1.3.1 Linux 3.1.3.2 embedded Windows XP 3.1.4 RealTime Kernel Konfiguration 3.1.5 DAIS Server 3.1.5.1 Linux 3.1.5.2 embedded Windows XP

3.2 Hardware

Sämtliche Versuche werden auf dem von Kontron^{29} speziell für TRUMPF-Laser entwickelten embedded System durchgeführt. Das als CPX^{30} bezeichnete System wird im nächsten Kapitel genau beschrieben.

3.2.1 CPX t.b.d. Grafik Systemkomponenten

29http://www.kontron.com (2.11.2006)

30t.b.d.

4 Clients zur Datenkommunikation

Es werden Beispielapplikationen zur Realtimekommunikation in der Automatisierungstechnik in verschiedenen Technologien implementiert und derren Realtimefähigkeiten gemessen.

4.1 Ende zu Ende Latenz messen

Es wurde eine Testumgebung (siehe Abb. ??) geschaffen, welche es ermöglicht die tatsächliche Latenz eines Signals zu messen. Hierzu wurde eine Rechteckspannung an einem digitalen Eingang einer CPX angelegt. Jede Änderungen am Port (+ je nach Bedarf zusätzliche Daten um größere Nachrichten zu simulieren) wird via Middleware auf den digitalen Ausgang einer anderen CPX übertragen.

Ein Speicherosziloskop^{31} zeichnet die generierte Rechteckspannung und das via Middleware übertragene Signal in einer CSV^{32} Datei auf.

1 ...
2 2.44 e-03,-16.8,-12.2
3 2.46 e-03,-16.8,-12.2
4 2.48 e-03,8,-12
5 2.50 e-03,10.8,-12.6
6 2.52 e-03,10.8,-12.2
7 2.54 e-03,11,-12
8 2.56 e-03,11,-12.4
9 2.58 e-03,11.2,-12.2
10 2.60 e-03,11.2,-12.2
11 2.62 e-03,11,-12.2
12 2.64 e-03,10.8,-12.2
13 2.66 e-03,10.8,-12.2
14 2.68 e-03,11.2,-12.4
15 2.70 e-03,11,-12
16 2.72 e-03,11.4,-12.2
17 2.74 e-03,11,-12.6
18 2.76 e-03,11,-12
19 2.78 e-03,10.8,11.4
20 2.80 e-03,11,11
21 2.82 e-03,10.8,11.6
22 ...

Abbildung 9: Ausschnitt einer mit einem TDS 3034B aufgezeichneter CSV-Datei In Abbildung ?? ist die Verzögerung desübertragenen Signals (3. Wert jeder Zeile) gegenüber

Clients zur Datenkommunikation  Seite: 28

dem Signal des Frequenzgenerators (2. Wert) am Polaritätswechsel zu erkennen. Der 1. Wert ist ein Zeitstempel. Zum Zeitpunkt 2.48 ∗ 10^{−03} in Zeile 4 wechselt der 1. Wert die Polarität. In Zeile 19 zum Zeitpunkt 2.78∗10^{−03} wechselt der 3. Wert die Polarität. Daraus kann eine Latenz berechnet werden:

31z.B. Tektronix TDS 3034B 32Comma Separated Values

2, 78 ∗ 10^{−03} − 2, 48 ∗ 10^{−03} = 300 ∗ 10^{−6}[sec]  (2)

Da eine einzige Latenzzeit nichts über die Qualität des Echtzeitsystems aussagt, wurde ein Programm erstellt, welches die komplette CSV-Datei auswertet. Es werden alle Latenzen (ansteigende und abfallende Flanke) berechnet. Eine Häufigkeitsanalyse der Latenzzeiten wird grafisch mit Hilfe von gnuplot^{33} ausgegeben. Der Mittelwert sowie Modalwert mit Spannweite in best und worst case Richtung werden bestimmt. Das Programm ist in der Lage auch noch ein weiteres Signal zu analysieren. Grafisch werden dessen Latenzschwankungen mit einer anderen Farbe im selben Diagramm dargestellt. Die Quellen des Programms sind im Anhang A.1 sowie auf der CD unter tools/latencyTest zu finden.

Eine Programmierumgebung istüber niedrig priorisierte Ethernetports mit den beiden CPXen verbunden. Sie dient zum Compilieren und Übertragen der Quellen, sowie zum Erzeugen von Netzlast (siehe ??).

33http://www.gnuplot.info (8.11.2006

Abbildung 10: Versuchsaufbau für Latenzmessungen

4.2 Lastsimulationen

Um die Realtime Eigenschaften des Systems zu überprüfen werden die Linuxsysteme künstlich belastet:

Harddisk: xdd -op read -targets 1 /dev/hda -reqsize 8000 -numregs 128 -verbose simuliert auf dem Rechner, auf dem das Kommando ausgeführt wird lesende Zugriffe auf /dev/hda

Netzwerk: Das Kommando ping -f -i 0 -l 100000 -s 1 -q IP wird von einem Rechner, welcher dirket mit dem Ziel (IP) verbunden ist als Benutzer root ausgeführt. -f -i 0: keine Pause zwischen den Anfragen. -l: Anzahl Pakete die gesendet werden ohne eine Antwort zu erhalten. -s: Paketgröße in Bytes. -q: quiet keine Ausgaben. So wird eine sehr hohe Netzauslastung erzeugt. (flood ping)

Prozessor: cpuburn5^{34} lastet die CPU des Rechners, auf dem das Kommando ausgeführt wird, voll aus

4.3 RTCORBA Clients implementiert mit ACE/TAO

In den ersten zwei Kapiteln wird das ACE/TAO Framework vorgestellt. An wichtigen Stellen wird die Implementation genauer beschrieben.

Die weiteren Kapitel beschreiben die Implementation und Ergebnisse der Versuche zur Realtime CORBA Datenkommunikation mit ACE/TAO.

4.3.1 ACE - The ADAPTIVE Communication Environment

ACE^{35} ist ein plattformunabhängiges, frei verfügbares openSource Framework zur objektorientierten Netzwerkprogrammierung.

34URL ???

35http://www.cs.wustl.edu/ schmidt/ACE.html (08.09.2006)

Abbildung 11: Struktur des ACE Frameworks (Quelle: http://www.cs.wustl.edu/ schmidt/) Auf Abb. ?? ist zu erkennen, dass die Architektur des ACE Framework aus aufeinander ge-

setzten Schichten besteht. Ein OS Adaption Layer abstrahiert die systemspezifischen Schnittstellen (zum Beispiel IPC oder den Zugriff auf das Dateisystem) der von ACE unterstützten Betriebssystemen. Darauf aufgesetzt befindet sich beispielsweise das Reactor/Preactor Framework, welches für das Filtern von Events (Reactor) und das Eventmanagment bei asynchronen Aufrufen (Proactor) verantwortlich ist. Das Acceptor und Connector Framework für einbzw. ausgehende Verbindungsaufbauten entkoppelt den Verbindungsaufbau von der eigentlichen Kommunikation. Ein CORBA Handler bietet eine Anbindung für CORBA Implementationen, wie zum Beispiel TAO (siehe ??).

4.3.2 TAO - The ACE ORB

TAO^{36} ist ein auf das Adaptive Communication Environment aufsetztende (siehe ??, Abb. ??), frei verfügbare, plattformunabhängige openSource C++ CORBA Distribution.

Douglas Schmidt (Entwicklungsleiter von ACE+TAO) erklärt auf seiner Homepage [?], die wichtigsten Gründe die Ihn zur Entwicklung von TAO bewegten:

• Erforschung der Grundlagen zur Implementierung eines Realtime CORBA ORBs (siehe 2.8 für den Einsatz in verteilten (siehe 2.5), embedded (siehe 2.4), Echtzeitsystemen (DRE - Distributed Real-time Systems).

• Kombination von Echtzeit Ein- und Ausgabesystemarchitekturen mit einem optimierten ORB zur Implementierung einer Ende zu Ende CORBA Kommunikation mit Datendurchsatz, Latenzzeit und Jitter Quality of Service (QoS) Anforderungen.

• Anbieten einer qualitativ hochwertigen, frei verfügbaren, openSource CORBA Middleware Plattform. TAO kann frei heruntergeladen, benutzt und weiterverbreitet werden.

• Mitwirken bei der OMG Realtime CORBA Spezifikation (siehe 2.8)

• …

Im nachfolgenden wird am Beispiel Servicerequest beim Server (rechter Teil Abb. ??) der Informationsfluß innerhalb von TAO beschrieben.

36http://www.cs.wustl.edu/ schmidt/TAO.html (06.09.2006)

Abbildung 12: Architektur der TAO RT Komponenten (Quelle: [?])

1. I/O Subsystem erhältüber das RT Netzwerk einen Request

2. Scheduler ermittelt Priorität des Requests

3. Je nach Priorität wird der Request auf eine der priorisierten Wartelisten gesetzt

4. Der ORB Core nimmt den Request aus der Warteliste und reicht ihn mit entsprechender Priorität an den

5. Object Adapter weiter, welcher in konstanter Zeit das zugehörige Objekt findet

6. dieses Objekt bearbeitet mit entsprechender Priorität die Anfrage

4.3.2.1 Scheduling

Die Qualität und Art der Implementation des Schedulings von Tasks definiert die Realtime Eigenschaften eines Multitaskingsystems.

In TAO wird für das Scheduling von Requests eine gepufferte Version des RMS (Rate Monotonic Scheduling siehe [?] Chap. 7.4.3 page 472) eingesetzt. Hierzu werden Aufgaben in rates groups organisiert.

Auf der I/O Ebene besteht für jede rates group eine eigene Verbindung. Somit kann auf der I/O Ebene, ohne Betrachtung des Inhalts der einkommenden Daten, bestimmt werden, mit welcher Priorität Sie verarbeitet werden. Dies ist wichtig, um auf dieser Ebene eine priority inversion zu verhindern.

Die so getakteten Anfragen einer rates group (zum Beispiel 20 Hz) werden im ORB via fixed Priority Scheduling (siehe [?] Chap. 2.5.3 page 143, 144) einem mit entsprechend hoher Priorität arbeitendem Threadpool zugewiesen. Threadpools haben den Vorteil, dass sie eine fixe Anzahl von Threads inklusive Resourcen zur Bearbeitung der zugewiesenen Aufgaben besitzen. Würden mehr Threads benötigt als der Threadpool zur Verfügung stellt, werden die Aufgaben später abgearbeitet. Dies verhindert ein ständiges Freigeben und neu Lokalisieren von Resourcen. Anhand der Größe des Threadpools kann die Performance optimiert werden.

RT Info Struktur

Um das Scheduling zu optimieren müßen TAO Applikationen alle zur Benutzung vorgesehenen Resourcen bekannt geben. Diese Angaben beeinflußen die Kompilierung des Programms.

In der RT Info Struktur (Tabelle ??) werden die echtzeitrelevanten Informationen einer Task gespeichert.

Aus diesen Informationen berechnet der Realtime Scheduler, welche Operationen in einem Thread zusammengefaßt werden und mit welcher Betriebssystempriorität dieser Thread arbeiten mußdamit die Echtzeitanforderungen erfüllt werden können.

Der Programmierer kann über das RTCORBA::Current Interface einem Objekt eine Priorität zuweisen. Diese Zuweisung beeinflusst nicht nur die RT Info Struktur des entsprechenden Objekts, sondern unter Umständen auch die RT Info Strukturen der Objekte von denen dieses Objekt abhängig ist. ( dependencies Feld)

Feldname  Einheit  Beschreibung
worstcase execution time  Time C  obere Schranke für

harte Echtzeitanforderungen

typical execution time Time C Schranke für

weiche Echtzeitanforderungen

cached execution time Time C falls ! = 0 wird zur Optimierung

nur einmal innerhalb der angegebenen Zeit die worstcase execution time verwendet.

period Time C Zeit zwischen periodischen

Aufrufen (z.B. bei Iterationen)

criticality Enum: VERY LOW … wird vom Scheduler ausgewertet

VERY HIGH CRITICALITY

importance Enum: VERY LOW … wird vom Scheduler nur
VERY HIGH IMPORTANCE ausgewertet, falls zwei

Aufgaben gleich wichtig sind

quantum Time C nicht benutzt / für gerechtes

Scheduling von niedrigst priorisierten Aufgaben

threads Anzahl n intern von der Operation

benutzter Threads

dependencies Handles auf andere von denen diese Operation direkt
RT Info Strukturen  abhängt. Aus dieser Information

werden intern Abhängigkeitsgraphen erstellt. Jeder Graph wird in einem Thread ausgeführt

priority Betriebssystempriorität wird von TAO aus den anderen

Informationen berechnet und gesetzt

subpriority Unterpriorität zur Sortierung von RT Infos mit

gleicher Priorität (wird ebenfalls von TAO berechnet und gesetzt)

Tabelle 2: RT Info Struktur 4.3.2.2 RTPOA

Der TAO RTPOA kann wahlweiße nach der perfect Hashing oder der active Demultiplexing Methode arbeiten. Beide finden das zum IOR zugehörige Objekt in konstanter Zeit.

perfect Hashing eine perfect Hash Table bestimmt anhand des Hashwertes des IOR den zugehörigen Skeleton. Eine zweite Hash Table dient zur Bestimmung der zugehörigen Funktion. Hierzu wird das GNU Tool gperf verwendet. Perfect Hashing kann nur verwendet werden, wenn zum Zeitpunkt der Kompilierung bekannt ist, mit welchen Objektschlüsseln und Funktionsnamen gearbeitet wird. Ist dies nicht der Fall, so ist…

active Demultiplexing Sendet der Client die IOR im request Header an den Server, so kann damit in einem Schritt der entsprechende Servant und die verknüpfte Operation bestimmt werden.

4.3.3 V1 Prozessabbild via TAO RTCORBA zwischen zwei embedded Systemen übertragen

4.3.3.1 Softwaredesign

CPX 2 agiert als RTCORBA Server. Als Servant wird ein Objekt zur Verfügung gestellt, welches via Memory Mapping einen übergebenen Wert direkt auf den digitalen Ausgang der CPX schreibt.

CPX 1, welche als RTCORBA Client aggiert erhält via NamingService eine Referenz auf das zur Verfügung gestellte Objekt. Änderungen an einem digitalen Eingang der CPX 1 werden mit einem RTCORBA Funktionsaufruf auf den digitalen Ausgang von CPX 2 geschrieben.

4.3.3.2 Implementation

Das Sequenzdiagramm (Abb. ??) zeigt die Kommunikation zwischen Receiver und Supplier. Das Holen der Objektreferenz vom NamingService, sowie CORBA interne Objekte wurden Übersichtlickshalber nicht dargestellt. Das Diagramm beinhaltet den Programmstart von Receiver und Supplier, sowie die Übertragung einer Zustandsänderung.

Abbildung 13: Sequenzdiagramm: V1 Prozessabbild via TAO übertragen Die Quellen zum Versuch sind im Anhang B.1 und auf der CD ROM zu finden.

4.3.3.3 Datenfluß

In Abb. ?? ist aufgezeigt, welche Komponenten die Daten passieren, um eine Portänderung via ACE/TAO von einer CPX auf die andere zu übertragen. RT Receiver und RT Supplier sind Komponenten die nicht vom System zur Verfügung gestellt oder automatisch generiert wurden.

Abbildung 14: Datenfluß: V1 Prozessabbild via TAO übertragen

4.3.3.4 Konfiguration

Linux ermöglicht eine Neupriorisierung aller Prozesse. Die rt-preempt Erweiterung cached IR-Qs und führt diese innerhalb je IRQ eines Prozesses aus. Somit kann einem Interrupthandler genau wie einem Prozess eine Priorität zugeteilt werden. Dies ermöglicht ein bevorzugtes Abarbeiten von entsprechend hoch priorisierten Interruptprozessen.

Es besteht die Möglichkeit die Algorithmik des RTCORBA Schedulers zu beeinflussen, in dem den RTPOAs entsprechende Policies zugewiesen werden. rt-preempt Priorisierung

Mit dem Tool rtnice^{37} wurden die (negativen) Realtime Prioritäten wie folgt zugewiesen:

Prozess  Priorität Kommentar
Supplier  RT (-99) RTCORBA Client
softirq-net-rx -2
softirq-net-tx -40
IRQ 6  -90  Digitale Ein/Ausgänge
IRQ 14  -2  ide0
IRQ 17  -90  eth0 (für RT Kommunikation)
IRQ 18  -2  ethX (restliche Ethernetports)

Tabelle 3: Priorisierung CPX1 - Supplier - RTCORBA Client

Prozess  Priorität Kommentar
Receiver  RT (-99) RTCORBA Server
softirq-net-rx -40
softirq-net-tx -2  Senden ist rel. unwichtig
IRQ 6  -90  Digitale Ein/Ausgänge
IRQ 14  -2  ide0
IRQ 17  -90  eth0 (für RT Kommunikation)
IRQ 18  -2  ethX (restliche Ethernetports)

Tabelle 4: Priorisierung CPX2 - Receiver - RTCORBA Server

softirqs: führen Interruptcode aus, welcher nicht zeitkritisch ist. Dies hat den Vorteil, dass die CPU nicht länger als nötig von einer Interruptserviceroutine benutzt wird. Eine detailierte Beschreibung ist in [?] ab Seite 142 zu finden.

Beeinflussen des RTCORBA Schedulers

Supplier: • RTCORBA::private connection policy()

• RTCORBA::priority model policy(RTCORBA::CLIENT PROPAGATED, RTCOR-BA::maxPriority)

37Download: http://www.tglx.de/projects/misc/rtnice/rtnice.tar.bz2

4.3.3.5 Ergebnisse

Abbildung 15: Latenzzeiten bei varriierender Systembelastung

Auf den folgenden Seiten sind Messungen abgedruckt, auf denen die in Abb. ?? farblich hervorgehobenen Erkenntnise dieses Versuchs ersichtlich sind.

Anhand der Dateinamensmatrix in Anhang C.1.1 können alle Messdiagramme dieses Versuchs eingesehen werden.

Abbildung 16: Receiver und Supplier ohne zusätzliche Systemlast

Ohne künstlich produzierte Lasten beträgt die Latenzzeit kontinuierlich 300 μs. Da alle beteiligten Prozesse sehr hoch priorisiert sind, dürfte in einem Echtzeitsystem eine Auslastung der Resourcen mit niedrigeren Prioritäten die Latenzzeit nicht bedeutend verändern. Ist dies doch

Clients zur Datenkommunikation  Seite: 41

der Fall, so deutet dies auf eine Priority Inversion^{38} hin.

Abbildung 17: Receiver ohne zusätzliche Systemlast; Supplier mit CPU Last Eine Auslastung der Supplier CPU beeinflusst die Latenzwerte nicht.

38ein niedriger priviliegerter Prozess blockiert einen höher Priviligierten, z.B. durch das Halten eines Mutexes

Abbildung 18: Receiver ohne zusätzliche Systemlast; Supplier mit CPU, Netz und HD Last Volle CPU Last, ein flood Ping und dauerhaftes Lesen von der Festplatte auf dem Supplier

beeinträchtigt dessen RT Verhalten nicht.

Abbildung 19: Receiver mit Netzlast; Supplier ohne zusätzliche Last

Ein flood ping auf den Receiver beeinträchtigt dessen Antwortverhalten. Vermutung: Priority Inversion bei der Abarbeitung von Netzwerkpaketen.

Abbildung 20: Receiver und Supplier mit CPU, Netz und HD Last

Wird auf beiden Systemen Netz- CPU- und HD-Last erzeugt wird das Signal nicht mehr korrekt übertragen, da:

T_{Latenz} > \frac{T_{P eriode}}{2}  (3)

Abbildung 21: Receiver mit CPU und HD Last; Supplier mit CPU, Netz und HD Last Ohne flood ping auf den Receiver kann das Signal korrekt übertragen werden.

Latenzschwankungen bei flood ping auf CPX2 (Receiver)

Bei einem Netzwerkinterrupt (IRQ 17/18) liest der Netzwerkkartentreiber (/usr/src/linux/drivers/net/eepro100.c) die Daten aus der Netzwerkkarte in den Arbeitsspeicher ein. Die Auswertung dieser Ethernetdaten wird in einem softirq (/usr/src/linux/net/core/dev.c: net-rx-action()) abgearbeitet. Ein Prozess bearbeitet die Ethernetdaten aller Ethernetdevices. Deshalb ist es nicht möglich durch Prozesspriorisierung eine bevorzugte Abarbeitung der Daten der RT-Ethernetschnittstelle zu gewähren.

Lösungsansätze

1. Prioritätenvergabe der IRQ Prozesse überarbeiten

2. IRQ 18 während echtzeitkritischen Programmabläufen deaktivieren 3. eigene softirqs für jedes Ethernetdevice

4. Abarbeitung des softirq-Codes innerhalb der Interruptserviceroutine

Lösung

Durch die Neuzuordnung der IRQ-Prioritäten wurden die Latenzschwankungen nahezu eliminiert:

Prozess  Priorität Kommentar
Supplier  RT (-99) RTCORBA Client
softirq-net-rx -35
softirq-net-tx -40
IRQ 6  -50  Digitale Ein/Ausgänge
IRQ 14  -2  ide0
IRQ 17  -80  eth0 (für RT Kommunikation)
IRQ 18  -2  ethX (restliche Ethernetports)

Tabelle 5: Repriorisierung CPX1 - Supplier - RTCORBA Client

Prozess  Priorität Kommentar
Receiver  RT (-99) RTCORBA Server
softirq-net-rx -45
softirq-net-tx -20  Senden ist rel. unwichtig
IRQ 6  -50  Digitale Ein/Ausgänge
IRQ 14  -2  ide0
IRQ 17  -80  eth0 (für RT Kommunikation)
IRQ 18  -2  ethX (restliche Ethernetports)

Tabelle 6: Repriorisierung CPX2 - Receiver - RTCORBA Server

Beim Supplier wird die Priorität des softirq-rx Prozesses erhöht, somit wird sichergestellt, dass die TCP-acknowledge Pakete vom Receiver rechtzeitig empfangen werden können. Dies hat zur Folge, dass die Datenübertragung nicht wegen eines fehlenden acknowledge Pakets eingefroren wird.

Der Receiver bekommt durch die Erhöhung der Priorität von softirq-net-tx die Chance zeitgerecht die TCP-acknowledge Pakete zu versenden.

Durch diese kleine Optimierung verbesserte sich das Ergebnis gravierend:

Abbildung 22: Supplier und Receiver ohne Last

Abbildung 23: Supplier und Receiver mit xdd, flood ping und cpuburnP5 belastet Abbildung ?? und ?? zeigen, dass die Latenzzeiten nicht mehr gravierend mit der Systemaus-

lastung korreliert sind.

Alle weiteren Versuche werden mit dieser Priorisierung durchgeführt.

Die Häufung der Latenzen auf wenige verschiedene Werte läßt sich mit der Implementation des TAO Schedulers begründen. Da die Anfragen in priority lanes sortiert werden, werden sie getaktet bearbeitet. So entsteht ein von der Rechenleistung des PCs abhängiger Wert für die Zeit zwischen den einzelnen Latenzzeiten.

Die letzten beiden Lösungsansätze würden eine Veränderung des Kernel Codes bedeuten, was sofern die Änderung nicht in den Mainstream Kernel übernommen werden, die Wartbarkeit des Systems verschlechtert.

to be checked! Festplattenlast

t.b.d. Festplattenlast?

4.3.4 V2 Prozessabbild via TAO RT EventService zwischen embedded Systemen übertragen

4.3.4.1 Softwaredesign

Auf CPX 2 wird ein NamingService (siehe ??) und ein Realtime EventService (siehe ??) gestartet. Die RTCORBA Applikation CPXEventSupplier sendet bei einer Änderung an einem digitalen Eingang eine Nachricht mit dem aktuellen Prozessabbild an den RT EventService.

Der CPXEventConsumer wird auf CPX 1 gestartet und registriert sich beim RT EventService für die Nachrichten, welche von der CPX 2 an den RT EventService gesendet werden.

Sobald der RT EventService von CPX 2 eine Prozessabbild Nachricht erhält leitet er diese an den CPXEventConsumer auf CPX 1 weiter. Der CPXEventConsumer stellt das Prozessabbild auf den digitalen Ausgängen dar.

4.3.4.2 Implementation

Abbildung 24: Sequenzdiagramm V2

Prozess C (Producer) generiert beim Eingang eines DIO Signals eine Nachricht mit dem aktuellen Prozessabbild , welche er per RT CORBA an Prozess B den RT EventService sendet.

Prozess A (Consumer) registriert sich beim EventService für die Nachrichten von Prozess C. Da der RT Event Service nur das Push Modell (siehe ??) unterstützt, werden beim EventService eintreffende Nachrichten sofort an Prozess A weitergeleitet. Dieser schreibt das übermittelte Prozessabbild auf die digitalen Ausgänge.

Clients zur Datenkommunikation  Seite: 51

4.3.4.3 Konfiguration Der RT EventService, CPXEventConsumer und CPXEventSupplier ist als RT Prozess priorisiert. Die Priorisierungen der restlichen Prozesse sind den Tabellen in ?? zu entnehmen.

4.3.4.4 Ergebnisse

Abbildung 25: CPX1 und 2 ohne Last

Abbildung 26: CPX1 und 2 mit xdd, flood ping und cpuburnP5 belastet Die Latenz von etwa 600 microsec entspricht den Erwartungen (siehe Abb. ??). Da die Daten

durch den RTEventService (eine weitere RTCORBA Applikation) geschleust werden.

Abbildung 27: vermutete Latenzverteilung 4.3.5 V3 Prozessabbild via TAO RT CORBA zwischen zwei embedded Systemen

über verschieden priorisierte Kanäle übertragen

4.3.5.1 Softwaredesign

Es wurden die Programme aus ?? erweitert. Weiterhin wird ein Prozessabbild in Realtime übertragen. In diesem Versuch wird zusätzlich das selbe Prozessabbild noch einmal mit minimaler Priorität übertragen. Anstelle des gleichen Abbilds könnten hier auch andere Daten übertragen werden, wie z.B. Logdateien… t.b.d. ?)

4.3.5.2 Konfiguration

Die Prozessepriorisierung entspricht der aus ??.

Es wird mit der ServerPropagatedPriorityPolicy gearbeitet. Der Supplier (RTCORBA Server) registriert das nieder priorisierte Objekt mit RTCORBA::minPriority und das hoch Priorisierte mit RTCORBA::maxPriority.

4.3.5.3 Ergebnisse

Abbildung 28: CPX1 und 2 ohne Last

Es ist zu erkennen, dass der Zugriff auf das nieder priorisierte Objekt deutlich langsamer erfolgt, als auf das hoch Priorisierte. Eine priority Inversion tritt nicht auf.

Abbildung 29: CPX1 und 2 mit xdd, flood ping und cpuburnP5 belastet

4.4 irgendein DAIS

4.5 und noch en DDS

5 Footprint

Da auf embedded Systemen in aller Regel Speicherresourcen deutlich knapper bemessen sind als auf anderen Computersystemen, ist ein kleiner Footprint ein wichtiges Optimierungsmaßfür Software, welche auf einem embedded System eingesetzt werden soll.

Der Footprint von ACE/TAO Anwendungen im Arbeitsspeicher ist erfahrungsgemäßsehr klein und bedarf keiner weiteren Optimierung.

Die Mächtigkeit von ACE/TAO spiegelt sich im benötigten Festplattenplatz der Libraries wieder. Die ACE/TAO Libraries werden dynamisch von den ACE/TAO Applikationen zur Laufzeit geladen.

Vor allem bei ACE/TAO Applikationen die nur wenig Dienste und Funktionen verwenden, kann eine deutliche Optimierung des benötigten Festplattenplatzes erfolgen, in dem nur die von den auf einem System lauffenden Applikationen benötigten Libraries auf das entsprechende System übertragen werden. Die Libraries, welche für V1 (siehe ??) benötigt werden belegen circa 90 MB Massenspeicher.

5.1 ACE/TAO statisch compilieren

Die Befehlsfolge

1 cd $ACE_ROOT
2 ./MPC/clone_build_tree  .pl s t a t i c
3 export ACE_ROOT =$ACE_ROOT /build / s t a t i c
4 export TAO_ROOT =$ACE_ROOT /TAO
5 cd $ACE_ROOT
6 make  static_libs  =1 shared_libs_only  =0 static_libs_only  =1
7 cd $TAO_ROOT
8 make  static_libs  =1 shared_libs_only  =0 static_libs_only  =1

baut ACE/TAO im Verzeichnis build/static. Die Applikationen, welche gegen diesen Tree gelinkt werden benötigen keine shared Libraries mehr. Für ein so gebautes ACE/TAO ca. 20 GB Festplattenplatz benötigt.

Eigene Applikationen, ohne weitere Optimierungen statisch kompiliert, werden mindestens 20 MB groß, je nach Abhängigkeiten auch deutlich größer.

t.b.d. footprint im Speicher!!!

5.2 soreduce: Erstellen von Library subsets

ACE ROOT/apps/soreduce/soreduce untersucht die Abhängigkeiten von eigenen ACE/TAO Applikationen und von denen benötigten Libraries und kreiert daraus MakeProjectFiles. Mit Hilfe

Footprint  Seite: 56

dieser MakeProjectFiles kann ACE/TAO mit nur von den eigenen Applikationen benötigten Abhängigkeiten gebaut werden.

Da soreduce nicht sehr häufig benutzt wird^{39}, ist es nicht optimal gewartet.

soreduce wird in der Standardkonfiguration nicht automatisch mit ACE/TAO kompiliert. Um soreduce zu übersetzen sind unter Linux folgende Schritte durchzuführen:

1 cd $ACE_ROOT /apps /soreduce
2 mpc.pl -type  gnuace
3 make  -j 2

Um nicht die bereits voll gebaute ACE/TAO Version zu verändern empfiehlt es sich, den ACE/TAO Baum zu klonen:

1 cd $ACE_ROOT
2 ./MPC/clone_build_tree  .pl mySubset

Der so geklonte ACE/TAO Baum befindet sich unter ACE ROOT/build/mySubset und wird zum neuen ACE ROOT:

1 export ACE_ROOT =$ACE_ROOT /build /mySubset
2 export TAO_ROOT =$ACE_ROOT /TAO

Nun können die MakeProjectFiles mit derren Hilfe die verkleinerten ACE/TAO Libraries gebaut werden können mit soreduce erstellt werden:

1 cd /home /meinName /meinProgVerzeichnis
2 $ACE_ROOT /apps /soreduce /soreduce  meinProg1  meinProg2  ...  meinProgN

Folgende Befehle bauen die masgeschneiderten Libraries:

1 cd $ACE_ROOT
2 mwc.pl -recurse
3 make

Wird das eigene Projekt neu übersetzt, wird automatisch gegen die subset Libraries gelinkt. Es lässt sich leider momentan keine Aussage über die damit realisierbare footprint Redurzie-

rung machen, da soreduce trotz Kontakt mit den Entwicklern und damit verbundenen Bugfixes, soreduce angewandt auf meine Applikationen keine funktionierenden MPC-Files erstellt.

39ace, tao Mailinglist: Using mwc.pl after soreduce Link: http://groups.google.de/group/comp.soft-

sys.ace/browse thread/thread/f66687e7c429f7c5/?hl=de#

6 Aufwandsbewertung für den Einsatz in der Automatisierungstechnik Abbildungsverzeichnis

1 embedded System (Quelle: http://www.acmesystems.it) . . . . . . . . . . . . . . . 10 2 einfaches verteiltes System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7 ORB mit Schnittstellen zu Applikation und System . . . . . . . . . . . . . . . . . 17 8 Realtime CORBA Erweiterungen (Quelle: [?]) . . . . . . . . . . . . . . . . . . . . 21 9 Latenzmessungen bei varriierender Systembelastung . . . . . . . . . . . . . XXV

Tabellenverzeichnis

1 Aufbau einer IOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Abkürzungsverzeichnis

Abb.  Abbildung
ACE  Adaptive Communication Environment
ASX  Adaptive Service Executive
bzw.  beziehungsweiße
CIAO  Component Integrated ACE ORB
CORBA  Common Object Request Broker Architecture
CPU  Central Processing Unit
CPX  t.b.d.
DAnCE  Deployment And Configuration Engine
DII  Dynamic Invocation Interface
DOC  Distributed Object Computing
DSI  Dynamic Skeleton Interface
enum  enumeration
FSF  Free Software Foundation
GIOP  General InterORB Protocol
GNU  GNU Is Not Unix
HDD  HardDisk Drive
IDL  Interface Definition Language
IFR  Interface Repository
IIOP  Internet InterORB Protocol
IP  Internet Protocol
IPC  Inter Process Communication
IOR  Interoperable Object Reference
MOM  Message Oriented Middleware
OMG  Object Management Group
ORB  Object Request Broker
OS  Operation System
OSI  Open System Interconnection
POA  Portable Object Adapter
QoS  Quality of Service
RAM  Random Access Memory
RMI  Remote Methode Invocation
RMS  Rate Monotonic Scheduling
ROM  Read Only Memory
RPC  Remote Procedure Call

Abkürzungsverzeichnis  Seite: IV

RT  RealTime
RTOS  RealTime OperatingSystem
SETI  Search for extraterrestrial intelligence
TAO  The ACE ORB
TCP  Transmission Control Protocol
USB  Universal Serial Bus
z.B.  zum Beispiel

Anhang A Tools

Die in der Arbeit verwendeten und frei verfügbaren Tools sind auf CD-ROM im Ordner tools/¡Name des Tools¿ zu finden.

Anhang A.1 latencyTest

latencyTest ist ein von mir erstelltes Tool zur Analyse der vom Osziloskop generierten CVS-Dateien.

C++ Code:

 1 /**
 2 * latenc .c
 3 * --------------------------------
 4 * (c) Manuel  Traut  <mail@manut .de>
 5 * 06/11/08  - version  0.98
 6 * --------------------------------
 7 * This  program  is free  software ;
 8 * you  can  redistribute   it and/or
 9 * modify  it under  the  terms  of
10 * the  GNU  General  Public  License
11 * Version  2 as published  by the
12 * Free  Software  Foundation .
13 **/

14

15 #i n c l u d e <fstream >

16 #i n c l u d e <stdlib .h>

17 #i n c l u d e <string >

18 #i n c l u d e <iostream >

19 #i n c l u d e <sstream >
20 #i n c l u d e <math .h>
21 #i n c l u d e <list >

22

23 /**
24 * structure  for  latency -list
25 * --------------------------------
26 * 1st latency
27 * 2nd counter
28 */
29 s t r u c t latency_counter  {
30 f l o a t latency ;

31 unsigned i n t counter ;

32 latency_counter  ( f l o a t _latency ){
33  counter  = 1;

Anhang A Tools  Seite: VI

34  latency  = _latency ;

35 }

36 } typedef lat_count ;

37

38 /**
39 * seperates  values  of one  line
40 * convert  time
41 * --------------------------------
42 * 1st time
43 * 2nd reference  signal
44 * 3rd delayed  signal
45 * 4th another  delayed  signal
46 **/

47

48 void sep_values (std::string  cpp_string , f l o a t * time , i n t * val1 , i n t * val2 ,
       i n t * val3 ){

49

50 i n t posStart  = 0;
51 i n t posEnd  = cpp_string .find (",", posStart );

52

53 std::string  time_str  = cpp_string .substr (posStart , posEnd );
54 i n t posOfExp  = time_str .find ("e", 0);
55 std::string  expo  = time_str ;
56 std::string  base  = time_str .substr (0,  posOfExp );
57 expo  = expo .substr (posOfExp +1,  expo .length ());
58 f l o a t fbase  = atof (base .c_str ());
59 f l o a t fexpo  = atof (expo .c_str ());
60 *time  = fbase *pow(10.0, fexpo );

61

62 posStart  = posEnd +1;
63 posEnd  = cpp_string .find (",", posStart )-1;

64

65 *val1  = atoi (cpp_string .substr (posStart , posEnd ).c_str ());

66

67 posStart  = posEnd +2;
68 posEnd  = cpp_string .find (",", posStart )-1;

69

70 i f(posEnd  > cpp_string .length ()){

71

72  posEnd  = cpp_string .length ()-1;

73

74  *val2  = atoi (cpp_string .substr (posStart , posEnd ).c_str ());
75  *val3  = 0;

76

77 } e l s e {

Anhang A Tools  Seite: VII

78

 79  *val2  = atoi (cpp_string .substr (posStart , posEnd ).c_str ());

80

 81  posStart  = posEnd +2;
 82  posEnd  = cpp_string .find (",", posStart )-1;

83

 84  i f(posEnd  < cpp_string .length ()) posEnd  = cpp_string .length ()-1;
 85  *val3  = atoi (cpp_string .substr (posStart , posEnd ).c_str ());

86 }
87 }

88

 89 /**
 90 * adds  a latencie  to a latency -
 91 * counter -list
 92 * --------------------------------
 93 * 1st latency
 94 * 2nd latencycounterlist
 95 * ret  counter  state
 96 **/

97

 98 i n t add_latency  ( f l o a t latency , std::list <lat_count >* lat_list ){

99

100 // latency  already  in list ?
101 f o r (std::list <lat_count >::iterator  it = lat_list ->begin (); it != lat_list
          ->end(); it++){
102  i f(it->latency  == latency ){
103  it->counter ++;
104  return it->counter ;

105  }
106 }

107 // add  latency
108 lat_count  new_lat_count  (latency );
109 lat_list ->push_back (new_lat_count  );
110 return new_lat_count  .counter ;

111 }

112

113 /**
114 * calculates   jitter  of a latency -
115 * counter -list
116 * --------------------------------
117 * 1st latencycounterlist
118 * ret  jitter
119 **/

120

121 f l o a t calc_jitter  (std::list <lat_count >* lat_list ){

Anhang A Tools  Seite: VIII

122

123 double avg  = 0;

124 i n t sum  = 0;

125

126 f o r (std::list <lat_count >::iterator  it = lat_list ->begin (); it != lat_list
          ->end(); it++){
127 avg  += it->counter  * it->latency ;
128 sum  += it->counter ;

129 }

130 avg  = (double )(avg/sum);
131 std::cout <<"Mittelwert :\t"<<avg<<" sec";

132

133 double jitter  = 0;

134

135 f o r (std::list <lat_count >::iterator  it = lat_list ->begin (); it != lat_list
          ->end(); it++){
136 jitter  += ((it->latency -avg)*it->counter );

137 }

138 jitter  = (double )(jitter /sum);

139

140 return ( f l o a t )jitter ;
141 }

142

143 /**
144 * calculates   modalvalues   and  ranges
145 * of a latency -counter -list
146 * --------------------------------
147 * 1st latencycounterlist
148 * 2nd debug
149 **/

150

151 void calc_modal (std::list <lat_count >* lat_list , bool debug = f a l s e ){

152

153 lat_count  modal (0);
154 lat_count  min(0);
155 min  = *lat_list ->begin ();
156 lat_count  max(0);
157 max  = *lat_list ->begin ();

158

159 f o r (std::list <lat_count >::iterator  it = lat_list ->begin (); it != lat_list
          ->end(); it++){
160  i f(it->latency  < min.latency ){  // for  difference   min  -> modal  (best
            case )
161  min  = *it;

162  }

Anhang A Tools  Seite: IX

163  i f(it->latency  > max.latency ){  // for  difference   max  -> modal  (worst
            case )
164  max  = *it;

165  }

166  i f(it->counter >modal .counter ){  // most  occurences
167  modal  = *it;
168  } e l s e i f (it->counter  == modal .counter ) { // if same  occurence , lower

            value

169  i f (it->latency  < modal .latency ){
170  modal  = *it;

171  }
172  }
173 }

174 std::cout <<"\nModalwert :\t"<<modal .latency <<" sec  - Haeufigkeit  : "<<
          modal .counter ;
175 std::cout <<"\nSpannweite  :\t"<<min.latency -modal .latency <<" sec  (best  case
          )\n\t\t "<<max.latency -modal .latency <<" sec  (worst  case )\n";

176 }

177

178 /**
179 * prints  out  latency -counter -list
180 * --------------------------------
181 * 1st latencycounterlist
182 * 2nd debug
183 **/

184

185 void print_lat_count  (std::list <lat_count >* lat_list , i n t * ch_counter , bool
        display = f a l s e ){

186 i n t i = 0;

187 std::stringstream   ss;
188 ss<<*ch_counter ;
189 std::string  file  = "result "+ss.str()+".txt";
190 std::ofstream  w(file .c_str ());
191 i f(!w.is_open ()){
192  std::cerr <<"cannot  write  output  file \n";

193 } e l s e {

194  f o r (std::list <lat_count >::iterator  it = lat_list ->begin (); it !=
            lat_list ->end(); it++){
195  i f(display ) std::cout <<it->latency <<" "<<it->counter <<std::endl ;
196  w<<it->latency <<" "<<it->counter <<std::endl ;
197  i++;

198  }

199  i f(i>0)  *ch_counter   = *ch_counter +1;

200 }

Anhang A Tools  Seite: X

202

203 /**
204 * main  routine
205 * --------------------------------
206 * 1st filename  of the  csv-file
207 **/

208

209 i n t main ( i n t argc , char ** argv ){

210

211 i f(argc  < 2){
212  std::cout <<"\nlatenc  by Manuel  Traut  <mail@manut .de>\n\ndraws  a
            graphical  visualization   and  some  statistical   informations   about
            latencies  out  of a Tektronix  TDS  3034 B generated  csv  file \n\
            nPhysical  Configuration  :\nCH1 : reference  signal \nCH2 : delayed
            signal  \nCH3 : (optional ) delayed  signal \n\nOsciloscope
            Configuration  :\n1) measure \n2) delay  \n3) save  \n4) all  channels  \
            n5) to FDD\n\nSYNOPSIS :\nlatenc  <TEKxxxx .CSV> [debug ]\n\n";
213  return EXIT_FAILURE  ;

214 }

215

216 bool debug  = f a l s e ;

217

218 // open  file
219 std::ifstream  f(argv [1]) ;
220 i f(!f.is_open ()){
221  std::cerr <<"file  open  failed \n";
222  return EXIT_FAILURE  ;

223 }

224

225 std::string  d = "debug ";
226 i f(argc  > 2) i f(d==(argv [2]) ){
227  debug  = true ;

228 }

229

230 // var  decl
231 i n t * val1 ; // actual  value  reference  signal
232 i n t * val2 ; // actual  value  1st delayed  signal
233 i n t * val3 ; // actual  value  2nd delayed  signal
234 i n t voltage1 , voltage2 , voltage3 ; // state  of the  signal  (+/-)
235 f l o a t * time ; // actual  time  (1st csv)
236 f l o a t refTimeDown  , refTimeUp ; // timestamp  ref  signal  raised /falled

237

238 bool firstFound   = true ;     // to find  a proper  start
239 bool latStartUp   = f a l s e ;
240 bool latStartDown   = f a l s e ;

Anhang A Tools  Seite: XI

241

242 std::string  linenr ; // one  csv  line

243

244 i n t ch_counter   = 0;

245

246 std::list <lat_count >* latencies1st  ;
247 std::list <lat_count >* latencies2nd  ;

248

249 val1  = new i n t ;
250 val2  = new i n t ;
251 val3  = new i n t ;
252 time  = new f l o a t ;

253

254 latencies1st   = new std::list <lat_count >;
255 latencies2nd   = new std::list <lat_count >;

256

257 while(!f.eof()){

258

259  getline (f, linenr );

260

261  i f(!f.eof()){

262

263  sep_values (linenr , time , val1 , val2 , val3 );

264

265  i f(firstFound ){ // to find  a proper  start

266

267 firstFound   = f a l s e ;
268 voltage1  = *val1 ;

269

270  } e l s e {

271

272 i f ( (voltage1  > 0) && (*val1  <= 0) ){ // if ref  state  changed

273

274  refTimeDown   = *time ;
275  i f(debug ) std::cout <<*time <<": ref  Down : "<<voltage1 <<"->"<<*val1 <<std
            ::endl ;
276  voltage1  = *val1 ;
277  latStartDown   = true ;

278

279 } e l s e i f ( (voltage1  <= 0) && (*val1  > 0) ){ // if ref  state  changed

280

281  refTimeUp  = *time ;
282  i f(debug ) std::cout <<*time <<": ref  Up: "<<voltage1 <<"->"<<*val1 <<std::
            endl ;
283  voltage1  = *val1 ;

Anhang A Tools  Seite: XII

284  latStartUp   = true ;

285

286 }

287

288 i f ( (voltage2  > 0) && (*val2  <= 0) && latStartDown   ){ // if delayed
          state  changed

289

290  f l o a t latency2  = *time  - refTimeDown  ;  // calc  latency
291  voltage2  = *val2 ;  // remember  state
292  i f(debug ) std::cout <<*time <<": CH1  latency  Down : "<<latency2 <<std::endl

            ;

293  i f(latency2  != 0){ // may  happen  at begining  of cvs
294  add_latency  (latency2 , latencies1st  );

295  }

296

297 } e l s e i f ( (voltage2  <= 0) && (*val2  > 0) && latStartUp   ){ // see  above !

298

299  f l o a t latency2  = *time  - refTimeUp ;
300  voltage2  = *val2 ;
301  i f(debug ) std::cout <<*time <<": CH1  latency  Up: "<<latency2 <<std::endl ;
302  i f(latency2  != 0) add_latency  (latency2 , latencies1st  );

303

304 }

305 i f ( (voltage3  > 0) && (*val3  <= 0) && latStartDown   ){ // see  above !

306

307  f l o a t latency3  = *time  - refTimeDown  ;
308  voltage3  = *val3 ;
309  i f(debug ) std::cout <<*time <<": CH2  latency  Down : "<<latency3 <<std::endl

            ;

310  i f(latency3  != 0) add_latency  (latency3 , latencies2nd  );

311

312 } e l s e i f ( (voltage3  <= 0) && (*val3  > 0) && latStartUp   ){ // see  above !

313

314  f l o a t latency3  = *time  - refTimeUp ;
315  voltage3  = *val3 ;
316  i f(debug ) std::cout <<*time <<": CH2  latency  Up: "<<latency3 <<std::endl ;
317  i f(latency3  != 0) add_latency  (latency3 , latencies2nd  );

318

319 }
320  }
321  }
322 }

323

324 d e l e t e val1 ;
325 d e l e t e val2 ;

Anhang A Tools  Seite: XIII

326 d e l e t e val3 ;
327 d e l e t e time ;

328

329 f.close ();

330

331 std::cout <<"\n\ndelayed  1st\n---------------\  n\n";
332 print_lat_count  (latencies1st  , &ch_counter , debug );
333 std::cout <<"\nJitter :\t\t"<<calc_jitter  (latencies1st  )<<" sec";
334 calc_modal (latencies1st  , debug );

335

336 std::cout <<"\n\ndelayed  2nd\n---------------\  n\n";
337 print_lat_count  (latencies2nd  , &ch_counter , debug );

338

339 i f(ch_counter   == 1){
340  system ("sh lat.sh");

341 } e l s e {

342 std::cout <<"\nJitter :\t\t"<<calc_jitter  (latencies2nd  )<<" sec";
343  calc_modal (latencies2nd  , debug );
344  system ("sh lats .sh");

345 }

346

347 return EXIT_SUCCESS  ;

348 }

sh Code:

 1 #!/bin/bash

2 #

 3 # file : lat.sh

4 #

 5 # Simple  bash  script f o r parsing and evaluating   a CSV  file
 6 # (C) 2006  Jan  Altenberg  <tb10alj@tglx  .de>

7 #

 8 # modified  2006  by Manuel  Traut  <mail@manut .de>
 9 # - parsing and calculating   is now  done  by c++ application
 10 # - modified  gnuplot  parameters

11 #

 12 # This  program  is free  software ; you  can  redistribute   it and /or
 13 # modify  it under  the  terms  of the  GNU  General  Public  License  Version
 14 # 2 as published  by the  Free  Software  Foundation .

15

 16 GNUPLOT =`which  gnuplot `

17

 18 PLOT_FILE =plot .pnm

19

 20 RESULT_TMPFILEn  =result0 .txt

Anhang A Tools  Seite: XIV

21 cat  $RESULT_TMPFILEn   | sort  -n > tmp.txt
22 RESULT_TMPFILE  =tmp.txt

23

24 echo  "Generating   1ch plot ..."

25

26 echo  -e "set  title  \"Streuung  der  Latenz \"\n\
27 set  terminal  pbm  color \n\
28 set  xrange  [0:*]\ n\
29 set  yrange  [0:*]\ n\
30 set  xlabel \"Latenz  in [sec]\"\ n\
31 set  ylabel \"Haeufigkeit   n\"\n\
32 set  output  \"$PLOT_FILE \"\n\
33 set  boxwidth  0.000006\ n\
34 set  style  fill  solid  1 border \n\
35 plot  \"$RESULT_TMPFILE  \" using  1:2  \"%lf%lf\" notitle  with  boxes " | gnuplot
        -persist

36

37 display  $PLOT_FILE
 1 #!/bin/bash

2 #

 3 # file : lats .sh

4 #

 5 # Simple  bash  script f o r parsing and evaluating   a CSV  file
 6 # (C) 2006  Jan  Altenberg  <tb10alj@tglx  .de>

7 #

 8 # modified  2006  by Manuel  Traut  <mail@manut .de>
 9 # - works  with  2channels ,
10 # - parsing and calculating   is now  done  by c++ application
11 # - modified  gnuplot  parameters

12 #

13 # This  program  is free  software ; you  can  redistribute   it and /or
14 # modify  it under  the  terms  of the  GNU  General  Public  License  Version
15 # 2 as published  by the  Free  Software  Foundation .

16

17 GNUPLOT =`which  gnuplot `

18

19 PLOT_FILE =plot .pnm

20

21 RESULT_TMPFILEn  =result0 .txt
22 cat  $RESULT_TMPFILEn   | sort  -n > tmp.txt
23 RESULT_TMPFILE  =tmp.txt

24

25 RESULT_TMPFILEm  =result1 .txt
26 cat  $RESULT_TMPFILEm   | sort  -n > tmp1 .txt

Anhang A Tools  Seite: XV

27 RESULT_TMPFILE1  =tmp1 .txt

28

29 echo  "Generating   2ch plot ..."

30

31 echo  -e "set  title  \"Streuung  der  Latenz \"\n\
32 set  terminal  pbm  color \n\
33 set  xrange  [0:*]\ n\
34 set  yrange  [0:*]\ n\
35 set  xlabel \"Latenz  in [sec]\"\ n\
36 set  ylabel \"Haeufigkeit   n\"\n\
37 set  output  \"$PLOT_FILE \"\n\
38 set  boxwidth  0.000006\ n\
39 set  style  fill  solid  1 border \n\
40 plot  \"$RESULT_TMPFILE  \" using  1:2  \"%lf%lf\" with  boxes  title  \"RTCORBA ::
       maxPriority  \",  \"$RESULT_TMPFILE1  \" using  1:2   \"%lf%lf\" with  boxes
       title  \"RTCORBA ::minPriority  \"" | gnuplot  -persist

41

42 display  $PLOT_FILE

Anhang B Quelltexte

Auf der beiliegenden CD-ROM befinden sich im Ordner quellcode die Quelltexte zu den durchgeführten Versuchen. Die nicht automatisch generierten Quelltexte, sind im folgenden abgedruckt.

Den Zugriff auf die digitalen Ein- und Ausgänge der CPX wie folgt zugegriffen:

Headerfile:

 1 /**
 2 *
 3 * \file     cpx.h
 4 * \brief    read  and  write  DIO
 5 *
 6 * \author   Manuel  Traut
 7 * \version  2006-10-06
 8 *
 9 */

10

11 # i f n d e f CPX_H
12 #d e f i n e CPX_H

13

14 #i n c l u d e <iostream >

15

16 #i n c l u d e <sys/mman .h>
17 #i n c l u d e <sys/ioctl .h>

18 #i n c l u d e <fcntl .h>

19 #i n c l u d e <unistd .h>

20

21 #d e f i n e CPX_Input       "/dev/iio2 "
22 #d e f i n e CPX_Input_1     "/dev/iio2_in "
23 #d e f i n e CPX_Output_1    "/dev/iio2_out "

24

25 #d e f i n e PORT1_OUT       0x2c00
26 #d e f i n e PORT2_OUT       0x3c00
27 #d e f i n e PORT3_OUT       0x4c00

28

29 #d e f i n e PORT1_IN      0x5c00
30 #d e f i n e PORT2_IN      0x6c00
31 #d e f i n e PORT3_IN      0x7c00

32

33 # i f n d e f PROT_READ
34 # d e f i n e PROT_READ      0x01

35 # e n d i f

36 # i f n d e f PROT_WRITE

Anhang B Quelltexte  Seite: XVII

37 # d e f i n e PROT_WRITE     0x02

38 # e n d i f

39 # i f n d e f MAP_SHARED
40 # d e f i n e MAP_SHARED     0x01

41 # e n d i f

42 # i f n d e f MAP_PRIVATE
43 # d e f i n e MAP_PRIVATE    0x02

44 # e n d i f

45

46 // ioctl  (file  descriptor , CPX_DIO_IOCTL_SET_SIGNAL   , irq_send_signal_param

       *)

47 // enable  sending  signal  on interrupt
48 // cpx_dio_set_signal_param   .signal  = signal  to be sent  to process
49 #d e f i n e CPX_DIO_IOCTL_BASE    0xCD

50

51 typedef s t r u c t {

52  i n t signal ; /* IN parameter : LINUX  signal  to be sent  */
53  i n t pid;     /* IN parameter : process  id where  signal  should  be sent  to

            */

54 }cpx_dio_set_signal_param   ;

55

56 #d e f i n e CPX_DIO_IOCTL_ADD_SIG      _IOW (CPX_DIO_IOCTL_BASE   , 3,
       cpx_dio_set_signal_param   )
57 #d e f i n e CPX_DIO_IOCTL_DEL_SIG      _IOW (CPX_DIO_IOCTL_BASE   , 4,
       cpx_dio_set_signal_param   )

58

59 c l a s s CPX{
60 p u b l i c :

61  CPX();
62  void set( short port , short value );

63  short get( short port );
64 p r i v a t e :

65 i n t init ();

66 unsigned char *mapped_in ;
67  unsigned char *mapped_out ;

68  v o l a t i l e u_char  *DOUT ;
69  v o l a t i l e u_char  *DIN;
70  cpx_dio_set_signal_param     param ;
71 };

72

73 #e n d i f

Implementierung:

 1 /**

Anhang B Quelltexte  Seite: XVIII

 3 * \file     cpx.cpp
 4 * \brief    read  and  write  DIO
 5 *
 6 * \author   Manuel  Traut
 7 * \version  2006-10-06
 8 *
 9 */

10

11 #i n c l u d e "cpx.h"

12

13 CPX::CPX(){
14 init ();
15 std::cout <<"\n\n init  ok\n\n";

16 }

17

18 i n t CPX::init (){

19

20 i n t fd_out  = open (CPX_Input , O_RDWR  | O_SYNC );
21 i f (fd_out  == -1){
22  std::cout <<"PBCIO : open  failed "<<std::endl ;

23  return (-1) ;
24 }

25 std::cout <<"CPX_Output_1   opened \n";

26

27 /* setup  signal  on interrupt  */
28 param .signal  = 1001;
29 param .pid  = getpid ();

30

31 i f (ioctl (fd_out , CPX_DIO_IOCTL_ADD_SIG   , (void *) &param ) == -1)  {
32 std::cout <<"signal  map  failed \n";
33  close (fd_out );

34  return (-1) ;

35 } e l s e std::cout <<"signal  map  ok\n";

36

37  mapped_out   = (u_char *) mmap  (NULL , 0x10000 , PROT_READ  | PROT_WRITE ,
          MAP_SHARED , fd_out , 0);
38  i f (mapped_out   == MAP_FAILED ) {
39  std::cout <<"PBCIO : mmap  failed \n";
40  close  (fd_out );

41  return (-2) ;
42  }

43  std::cout <<"mmap  ok\n";

44

45  DOUT  = (u_char  *) mapped_out ;
46  DIN  = (u_char  *) mapped_out ;

Anhang B Quelltexte  Seite: XIX

47

48  return 0;
49 }

50

51 short CPX::get( short port ){

52 unsigned char value  = 0;

53

54 switch (port ){
55  case 1:

56  value  = DIN[PORT1_IN ];

57  break ;
58 case 2:

59  value  = DIN[PORT1_IN ];

60  break ;
61 case 3:

62  value  = DIN[PORT1_IN ];

63  break ;
64 d e f a u l t :

65  std::cout <<"portNo : "<<port <<" incorrect \n";

66 }

67

68 return ( short ) value ;
69 }

70

71 void CPX::set( short port , short value ){

72 switch (port ){
73  case 1:

74  DOUT [PORT1_OUT ] = value ;

75  break ;
76 case 2:

77  DOUT [PORT2_OUT ] = value ;

78  break ;
79 case 3:

80  DOUT [PORT3_OUT ] = value ;

81  break ;
82 d e f a u l t :

83  std::cout <<"portNo : "<<port <<" incorrect \n";

84 }
85 }

Anhang B.1 V1 Prozessabbild via TAO RTCORBA übertragen

Schnittstellendefinition in Interface Description Language:

 1 /**

Anhang B Quelltexte  Seite: XX

 2 *
 3 * \file     bench .idl
 4 * \brief    Interfacedefinition    for  writing  values  to digital  Output
 5 *
 6 * \author   Manuel  Traut
 7 * \version  2006-10-15
 8 *
 9 */

10

11 module  benchmark {
12 exception  invalidRequest  {};
13 interface  Put{
14  void connect () raises (invalidRequest  );
15  void onePort (in short portNo , in short value ) raises (invalidRequest  );
16  void allPorts ( in short valPort1 ,
17  in short valPort2 ,
18  in short valPort3 ) raises (invalidRequest  );
19 };
20 };

RTCORBA Server hosted Objekt zum Setzen der digitalen Ausgänge

 1 /**
 2 *
 3 * \file     Receiver .cpp
 4 * \brief    RTCORBA  Server , holding  one  Object  for  setting  digital  Output
 5 *
 6 * \author   Manuel  Traut
 7 * \version  2006-10-15
 8 *
 9 */

10

11 #i n c l u d e <iostream >

12

13 #i n c l u d e "benchI .h"

14

15 #i n c l u d e "orbsvcs /CosNamingC .h"
16 #i n c l u d e <tao/RTCORBA /RTCORBA .h>

17

18 i n t main ( i n t argc , char * argv []){

19  t r y {

20  // initialize   ORB
21  CORBA ::ORB_var  orb  = CORBA ::ORB_init (argc , argv , "ServerORB ");
22  std::cout <<"ORB  initialized  "<<std::endl ;

23

24  // access  RT Extensions

Anhang B Quelltexte  Seite: XXI

25  CORBA ::Object_var   rtorb  = orb->resolve_initial_references    ("RTORB ");
26  RTCORBA ::RTORB_var  rtORB  = RTCORBA ::RTORB ::_narrow (rtorb );
27  std::cout <<"RT Extensions   OK"<<std::endl ;

28

29  // obtain  rootPOA
30  CORBA ::Object_var   poa  = orb->resolve_initial_references    ("RootPOA ");
31  PortableServer  ::POA_var  rootPOA  = PortableServer  ::POA::_narrow (poa.in()
            );

32

33  // activate  POA  Manager
34  PortableServer  ::POAManager_var   poaManager   = rootPOA ->the_POAManager  ();
35  poaManager ->activate ();
36  std::cout <<"rootPOA  OK"<<std::endl ;

37

38  // create  Policy
39  CORBA ::PolicyList   benchPolicy  (1);
40  benchPolicy  .length (1);
41  benchPolicy  [0]  = rtORB ->create_priority_model_policy    (RTCORBA ::
            CLIENT_PROPAGATED  , 20);

42

43  // create  ObjectAdapter  , assign  Policy
44  PortableServer  ::POA_var  benchPOA  = rootPOA ->create_POA ("benchPOA ",
            poaManager .in(), benchPolicy  );
45  std::cout <<"Policy  assigned "<<std::endl ;

46

47  // create  the  servant
48  benchmark_Put_i   bench_i ;

49

50  // activate  servant
51  PortableServer  ::ObjectId_var   objectID  = benchPOA ->activate_object  (&
            bench_i );
52  CORBA ::Object_var   benchObj  = benchPOA ->id_to_reference  (objectID .in());
53  CORBA ::String_var   ior  = orb->object_to_string  (benchObj .in());
54  std::cout <<"Servant  activated "<<std::endl ;

55

56  // NameService
57  CORBA ::Object_var    namingObject   = orb->resolve_initial_references    ("
            NameService  ");
58  CosNaming ::NamingContext_var    namingContext   = CosNaming ::NamingContext  ::
            _narrow (namingObject  .in());
59  CosNaming ::Name  name (1);
60  name .length (1);
61  name [0]. id = CORBA ::string_dup ("Receiver ");
62  namingContext  ->bind (name , benchObj .in());
63  std::cout <<"Bound  Receiver  to NameService  "<<std::endl ;

Anhang B Quelltexte  Seite: XXII

64

65  // start  ORB
66  orb->run();
67  std::cout <<"ORB  ready "<<std::endl ;

68

69  //destroy
70  rootPOA ->destroy (1,1) ;
71  orb->destroy ();
72  }catch (CORBA ::Exception  &any){
73  std::cout <<"Exception : "<<any<<std::endl ;

74  }
75  return 0;
76 }

RTCORBA Client übermittelt Änderungen an digitalem Eingang an den Receiver

 1 /**
 2 *
 3 * \file     Supplier .cpp
 4 * \brief    RTCORBA  Client , catches  Signal  on DIO  changes  and  reports  this
        changes  via  RTCORBA  to the  Receiver
 5 *
 6 * \author   Manuel  Traut
 7 * \version  2006-10-15
 8 *
 9 */

10

11 #i n c l u d e <iostream >
12 #i n c l u d e "benchC .h"
13 #i n c l u d e "orbsvcs /CosNamingC .h"
14 #i n c l u d e <tao/RTCORBA /RTCORBA .h>
15 #i n c l u d e <unistd .h>

16

17 #i n c l u d e "cpx.h"

18

19 benchmark ::Put_var  put;
20 CPX  cpx;

21

22 // Signal -Handler
23 void sigproc ( i n t signo )
24 {      signal (SIGRTMIN +29,  sigproc );
25  put->allPorts (cpx.get(1), cpx.get(2), cpx.get(3));

26 }

27 28

29 i n t main ( i n t argc , char * argv []){

Anhang B Quelltexte  Seite: XXIII

30

31 t r y {

32  // initialize   ORB
33  CORBA ::ORB_var  orb  = CORBA ::ORB_init (argc , argv , "ClientORB ");
34  std::cout <<"ORB  ok"<<std::endl ;

35

36  // get  RTORB
37  CORBA ::Object_var   rtorb  = orb->resolve_initial_references    ("RTORB ");
38  RTCORBA ::RTORB_var  rtORB  = RTCORBA ::RTORB ::_narrow (rtorb .in());
39  std::cout <<"RTORB  ok"<<std::endl ;

40

41  // NamingService
42  CORBA ::Object_var   namingObject   = orb->resolve_initial_references    ("
                NameService  ");
43  CosNaming ::NamingContext_var    namingContext   = CosNaming ::
                NamingContext  ::_narrow (namingObject  .in());
44  std::cout <<"NamingService   ok"<<std::endl ;

45

46  CosNaming ::Name  name (1);
47  name .length (1);
48  name [0]. id = CORBA ::string_dup ("Receiver ");

49

50  // receive  Object
51  CORBA ::Object_var   benchObj  = namingContext  ->resolve (name );
52  put  = benchmark ::Put::_narrow (benchObj .in());
53  std::cout <<"TransferOjekt   ok"<<std::endl ;

54

55  // Private  Connection   Policy
56  CORBA ::PolicyList   pcPolicy (1);
57  pcPolicy .length (1);
58  pcPolicy [0]  = rtORB ->create_private_connection_policy     ();
59  CORBA ::Object_var   newTran  = put->_set_policy_overrides   (pcPolicy ,
                CORBA ::SET_OVERRIDE  );
60  put  = benchmark ::Put::_narrow (newTran .in());
61  std::cout <<"PrivateConnection    ok"<<std::endl ;

62

63  // rtCurrent  set  priority
64  CORBA ::Object_var   rtCurrentObj   = orb->resolve_initial_references    ("
                RTCurrent ");
65  RTCORBA ::Current_var   rtCurrent  = RTCORBA ::Current ::_narrow (
                rtCurrentObj  .in());
66  rtCurrent ->the_priority  (RTCORBA ::maxPriority  );
67  std::cout <<"PriorityChange   ok"<<std::endl ;

68

69  // Input  auf  Interface  schreiben

Anhang B Quelltexte  Seite: XXIV

70  put->connect ();
71  put->allPorts (0,  0, 0);

72

73  // signal  handling
74  signal (SIGRTMIN +29,  sigproc );

75

76  while(true ){

77  pause ();

78  }

79

80  // destroy  ORB
81  orb->destroy ();

82

83  }catch (CORBA ::Exception  &any){
84  std::cout <<"Exception  occured : "<<any<<std::endl ;

85  }
86  return 0;

Anhang C Messergebnise

Auf der beiliegenden CD-ROM befinden sich im Ordner messungen die Dateien zu sämtlichen Messungen. Die Einstellungen des Osziloskops in einer txt-Datei, den Bildschirminhalt des Osziloskops als tif-Datei.

Anhang C.1 V1 Prozessabbild via TAO RTCORBA übertragen

Anhang C.1.1 ohne Optimierung

Abbildung 30: Latenzmessungen bei varriierender Systembelastung

Ehrenwörtliche Erklärung

Hiermit versichere ich, die vorliegende Arbeit selbständig, ohne fremde Hilfe und ohne Benutzung anderer als der von mir angegebenen Quellen angefertigt zu haben. Alle aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche gekennzeichnet. Die Arbeit wurde noch keiner Prfungsbehörde in gleicher oder änlicher Form vorgelegt.

Weingarten, den 21. November 2006