Dokument 1.pdf - Staatliche Studienakademie Glauchau

TRANSIM TECHNOLOGY CORPORATION
Bachelor Thesis
Erweiterung des Engine Framework und der Web-Schematic
Lösung der Transim Technology Corporation um eine
Echtzeitkommunikation zwischen Simulator und Schematic
Vorgelegt am: 30.08.2013
Von:
Martin Meyer
Flemmingstraße 19
09116 Chemnitz
Studiengang:
Technische Informatik
Studienrichtung: Prozessinformatik
Seminargruppe:
4TI10-1
Matrikelnummer: 4000652
Praxispartner:
Transim Technology Corporation
Annaberger Straße 240
09125 Chemnitz
Gutachter:
Herr Dipl.-Inf. (FH) Frank Vogel (Transim Technology Corp.)
Herr Dr. Mathias Sporer (Staatliche Studienakademie Glauchau)

Inhaltsverzeichnis
Inhaltsverzeichnis
Inhaltsverzeichnis ................................................................................................... IV
Abbildungsverzeichnis ........................................................................................... VI
Tabellenverzeichnis ............................................................................................... VII
Formelverzeichnis ................................................................................................. VIII
Listingverzeichnis ................................................................................................... IX
Abkürzungsverzeichnis ........................................................................................... X
1 Einführung ................................................................................................... 1
1.1 Hinführung zum Thema ................................................................................. 1
1.2 Motivation ...................................................................................................... 1
1.3 Einblick in das EngineFramework ................................................................. 2
1.4 Hinweise zur Arbeit ....................................................................................... 3
1.4.1 Verwendete Beispiele und Simulationen ....................................................... 3
1.4.2 Gliederung ..................................................................................................... 5
2 Analyse des bestehenden Systems .......................................................... 6
2.1 Die Simulationsanwendung “Qucs” ............................................................... 6
2.2 Der EngineServer .......................................................................................... 7
2.2.1 Allgemein ...................................................................................................... 7
2.2.2 Der EngineServer als Webdienst .................................................................. 8
2.3 Die QucsEngine ............................................................................................ 8
2.4 Die Darstellung der Simulationsdaten in der Webanwendung ...................... 9
3 Änderungen an Qucs ................................................................................ 11
3.1 Vorüberlegungen ......................................................................................... 11
3.1.1 Kommunikation zwischen den Anwendungen ............................................. 11
3.1.2 Verwendung des Netzwerkprotokolls .......................................................... 12
3.1.3 Zuweisung der gesendeten Daten zu einer Simulation ............................... 13
3.1.4 Formatierung der Simulationsergebnisse .................................................... 14
3.1.4.1 Analyse der bisherigen Ausgabedateien von Qucs ..................................... 14
3.1.4.2 Betrachtungen zu der Paketgröße und dem Datenformat ........................... 15
3.1.5 Nachbilden zeitintensiver Simulationen ....................................................... 17
3.1.6 Die Netzwerkkommunikation ....................................................................... 17
3.2 Implementierung ......................................................................................... 18
3.2.1 Der Programmeinstieg ................................................................................ 18
3.2.2 Die Netzwerkklasse ..................................................................................... 18
3.2.3 Einbinden der Netzwerkklasse .................................................................... 19
3.2.3.1 Die Klassenhierarchie der Simulationssoftware .......................................... 19
3.2.3.2 Erkennen der Simulationsergebnisse .......................................................... 20
3.2.3.3 Erkennen der Abhängigkeiten ..................................................................... 20
Seite IV

Inhaltsverzeichnis
4 Die QucsLiveEngine ................................................................................. 22
4.1 Vorbetrachtungen ........................................................................................ 22
4.1.1 Starten der Simulation ................................................................................. 22
4.1.2 Empfangen der Simulationsdaten ............................................................... 22
4.1.3 Auswerten des XML-Dokumentes ............................................................... 23
4.1.4 Konvertieren der Daten ............................................................................... 24
4.1.5 Erzeugen der Waveform Dateien ................................................................ 25
4.1.6 Die Manifest Datei ....................................................................................... 26
4.1.7 Speichern von Kurvenscharen .................................................................... 26
4.2 Implementierung ......................................................................................... 27
4.2.1 Starten des TCP-Servers und der Simulationsanwendung ......................... 27
4.2.2 Empfangen der Daten ................................................................................. 28
4.2.3 Auslesen des TCP-Stroms .......................................................................... 29
4.2.4 Speichern der Simulationsergebnisse ......................................................... 30
5 Der EngineServer ...................................................................................... 32
5.1 Vorbetrachtungen ........................................................................................ 32
5.1.1 Das Postprocessing .................................................................................... 32
5.1.2 Bereitstellen der Simulationsdaten .............................................................. 34
5.2 Implementierung ......................................................................................... 35
5.2.1 Anpassen der QucsLiveEngine ................................................................... 35
5.2.2 Speichern der Daten im Zwischenspeicher des EngineServers .................. 36
5.2.3 Starten des Postprocessing ........................................................................ 37
6 Anzeige der Simulationsergebnisse in WebScope ................................ 38
6.1 Vorbetrachtung ............................................................................................ 38
6.1.1 Anfrage der Simulationsdaten ..................................................................... 38
6.1.2 Ausgabe der Simulationsdaten zu Laufzeit ................................................. 38
6.1.2.1 Allgemein .................................................................................................... 38
6.1.2.2 Erneutes Abfragen aller Ergebnisse (Polling).............................................. 39
6.1.2.3 Abfragen nach neuen Ergebnissen (Long Polling) ...................................... 39
6.1.2.4 Websocket-Protokoll ................................................................................... 40
6.1.2.5 Senden der Ergebnisse vom Webserver ..................................................... 40
6.2 Implementierung ......................................................................................... 40
6.2.1 Auslesen des Zwischenspeichers im EngineServer .................................... 40
6.2.2 Ausgabe der Simulationsdaten ................................................................... 41
7 Bewertung und Ausblick .......................................................................... 43
Quellenverzeichnis ................................................................................................. 44
Anhangverzeichnis ................................................................................................. 46
Seite V

Abbildungsverzeichnis
Abbildungsverzeichnis
Abbildung 1 Tiefpass erster Ordnung 3
Abbildung 2 Transientsimulation des Tiefpasses 4
Abbildung 3 Wechselstrom-Simulation des Tiefpasses 4
Abbildung 4 Das Web-Schematic 9
Abbildung 5 WebScope nach Abschluss einer Simulation 10
Abbildung 6 Die Klassenhierarchie der Simulatoren von Qucs 19
Abbildung 7 Speichern der Ergebnisse in der Waveform-Datei 25
Seite VI

Tabellenverzeichnis
Tabellenverzeichnis
Tabelle 1 Vergleich des Overheads bei XML und JSON .................................... 16
Tabelle 2 Format der Achsbezeichung in der Manifest-Datei ............................. 26
Seite VII

Formelverzeichnis
Formelverzeichnis
Formel 1 Berechnung der Grenzfrequenz ............................................................ 5
Formel 2 Differenz des Overheads von XML und JSON .................................... 17
Seite VIII

Listingverzeichnis
Listingverzeichnis
Listing 1 Beispiel für eine Netzliste ...................................................................... 6
Listing 2 Ausschnitt einer Qucs-Ausgabedatei .................................................. 14
Listing 3 Startparameter für die Netzwerkkommunikation ................................. 18
Listing 4 Auswahl des Ports für den TCP-Server .............................................. 28
Listing 5 Lesen der XML-Dokumente aus dem TCP-Puffer ............................... 30
Listing 6 Beispiel für die PostProcessingCommands ........................................ 32
Listing 7 Von FlashGen erzeugte Datei zur Berschreibung der Diagramme ..... 33
Listing 8 Änderungen an der generischen Klasse ............................................. 35
Listing 9 Aufruf der Rückruffunktion in der QucsLiveEngine .............................. 36
Listing 10 Änderungen an der EngineServer-Klasse ........................................... 36
Listing 11 Polling in WebScope ........................................................................... 42
Seite IX

Abkürzungsverzeichnis
Abkürzungsverzeichnis
AC
Alternating current
AJAX
API
CLI
DLL
DOM
GPL
HTML
IIS
IP
JSON
Qucs
RFID
SAX
SimID
TCP
UserID
UDP
URL
XML
Asynchronous JavaScript and XML
Application Programming Interface
Common Language Infrastructure
Dynamic Link Library
Document Object Model
GNU General Public License
Hypertext Markup Language
Internet Information Services
Internet Protocol
JavaScript Object Notation
Quite Universal Circuit Simulator
Radio-frequency identification
Simple API for XML
Simulation Identifikationsnummer
Transmission Control Protocol
Benutzeridentifikationsnummer
User Datagram Protocol
Uniform Resource Locator
Extensible Markup Language
Seite X

Einführung
1 Einführung
1.1 Hinführung zum Thema
Die Transim Technology Corporation hat sich auf die Entwicklung von
Webanwendungen spezialisiert, in denen unterschiedliche Simulationsmöglichkeiten,
speziell für Firmen aus der Halbleiterindustrie, realisiert werden können. Für die
Simulationen werden Anwendungen von Drittherstellern verwendet. Die
Webanwendungen stellen dabei eine Schnittstelle zwischen den
Simulationsanwendungen und der grafischen Oberfläche im Webbrowser des
Endnutzers dar. Simulationen dienen der Analyse von realen Systemen durch die
Verwendung von Modellen. Dadurch kann das Verhalten eines Systems untersucht
werden, ohne dieses real nachbilden zu müssen. Ein weiterer Vorteil besteht darin,
dass die Modelle parametrisiert werden können. In einer realen Nachbildung des
Systems müssen Komponenten entsprechend ausgetauscht werden, im
Simulationsmodell muss lediglich ein Parameter geändert werden. Es entsteht somit
eine erhebliche Zeit- und Kostenersparnis. Für Firmen aus der Halbleiterindustrie
bedeutet dies, dass sie ihren Kunden neue Bauelemente über eine
Simulationsanwendung bereitstellen können. Die Kunden können über diese
Anwendung testen, ob und in welcher Art und Weise die Bauelemente für ihre
Zwecke verwendet werden können.
Für die Simulation können hierbei unterschiedliche Arten angeboten werden. Die
wichtigste Rolle spielen dabei die Simulationen von elektronischen Schaltungen. So
stehen beispielsweise Transientsimulationen zur Verfügung, über die das
Einschaltverhalten von Systemen analysiert werden kann, oder eine Wechselstrom-
Simulation, die eine Analyse des Amplituden- und Phasengangs ermöglicht. Auf
diese Simulationen wird in dieser Arbeit näher eingegangen. Es sind jedoch auch
Simulationen möglich, über die zum Beispiel unterschiedliche Entwürfe von RFID-
Antennen (engl.: radio-frequency identification) untersucht werden können.
1.2 Motivation
Neu entwickelte Bauelemente müssen für ihre Einsatzgebiete entsprechend
angepasst werden. Ohne Simulationen müssten die Bauelemente in den realen
Systemen umständlich getestet werden, bis sie ihre Funktion korrekt erfüllen. Die
immer schneller voranschreitende Entwicklung der Technik setzt die Entwickler von
elektronischen Geräten zunehmend unter Druck. Ohne die Verwendung von
Simulationen müssten neue Bauelemente sehr zeit- und kostenaufwendig in ihren
Einsatzgebieten getestet werden und würde zu einer langsameren Entwicklung
führen.
Die Komplexität der Bauelemente nimmt immer weiter zu, wodurch die Bedeutung
der Simulation immer größer wird. Komplexere Bauelemente bedeuten jedoch auch
Seite 1

Einführung
komplexere Simulationen. Da die Rechenleistung eines Computers beschränkt ist,
kommt es somit zu einer längeren Ausführungszeit der Simulation. In dem bisherigen
System der Transim Technology Corporation werden die Simulationsergebnisse erst
nach Abschluss der Simulation ausgegeben. Bei komplexen Simulationen führt dies
zu einer langen Wartezeit des Endnutzers. Im Rahmen dieser Arbeit soll eine
Möglichkeit gefunden werden, die Simulationsergebnisse während der Berechnung
dem Endnutzer zur Verfügung zu stellen. Sieht dieser, dass beispielsweise
Schwellwerte überschritten werden, kann er die Simulation abbrechen und mit
geänderten Parametern erneut starten und muss nicht auf das Ende der gesamten
Simulation warten.
1.3 Einblick in das EngineFramework
Wurde für eine Firma aus der Halbleiterindustrie eine Webanwendung entwickelt,
kann der Endnutzer über diese zunächst die Bauelemente der Firma auswählen.
Nach der Auswahl können für diese unterschiedliche Parameter festgelegt werden.
Handelt es sich um eine elektronische Simulation wird dem Nutzer die Schaltung des
Systems im Webbrowser angezeigt. Diese Anzeige wird WebSchematic genannt.
Hier besteht die Möglichkeit, Elemente der Schaltung zu parametrisieren und eine
Simulation zu Starten. Wurde die Simulation gestartet, werden die Parameter an den
Webserver der Webanwendung übertragen. Um die Simulation zu starten, muss der
Webserver zunächst eine Anfrage an den sogenannten JobManager stellen. Dieser
verteilt die Simulationsanfragen auf unterschiedliche Simulationsserver auf. Diese
Simulationsserver werden EngineServer genannt. Die Transim Technology
Corporation nutzt dieses System, um die Simulationen auf mehrere Computer
aufzuteilen. Steigt die Anzahl der Simulationen kann leicht ein neuer
Simulationsserver in das System eingebunden werden. Nachdem der
Simulationsanfrage ein EngineServer zugewiesen wurde, werden die
Simulationsparameter an diesen weitergeleitet. In diesen ist unter anderem
enthalten, welche Simulationsanwendung verwendet werden soll. Die Schnittstelle
zwischen den Anwendungen und dem EngineServer erfolgt über die sogenannten
Engines. Für jede Simulationsanwendung existiert eine eigene Engine. Nachdem die
Parameter beim EngineServer eingegangen sind, startet dieser die entsprechende
Engine. In dieser wird die Simulationsanwendung gestartet. Nach Abschluss der
Simulation müssen die Simulationsergebnisse von der Engine in ein eigenes Format
konvertiert und gespeichert werden. Ist die Simulation abgeschlossen, teilt der
EngineServer dies dem Webserver der Webanwendung mit. Dieser kann nun die
Simulationsergebnise vom EngineServer abfragen, und dem Endnutzer in der
Webanwendung zur Verfügung stellen. Die graphische Darstellung der
Simulationsergebnisse im Webbrowser erfolgt in dem sogenannten WebScope.
Seite 2

Einführung
1.4 Hinweise zur Arbeit
1.4.1 Verwendete Beispiele und Simulationen
Zum besseren Verständnis dieser Bachelor Thesis werden unterschiedliche
Beispiele verwendet. Diese bauen auf den Tiefpass erster Ordnung aus der
Elektronik auf. Unter einem Tiefpass ist ein Filter zu verstehen, der aus einem
eingehenden Signal die Frequenzanteile abschwächt, die über der Grenzfrequenz
des Tiefpasses liegen. Abbildung 1 zeigt die Schaltung eines Tiefpasses erster
Ordnung.
Abbildung 1 Tiefpass erster Ordnung
Elektronische Schaltungen, wie der Tiefpass, lassen sich auf unterschiedliche Art
und Weise simulieren. In dieser Arbeit wird lediglich auf die Transientsimulation und
die Wechselstrom-Simulation, auch AC-Simulation (alternating current) genannt,
eingegangen.
Bei der Transientsimulation wird das zeitliche Verhalten eines Systems dargestellt.
Sie wird verwendet um die Antwort eines Systems auf ein bestimmtes
Eingangssignal zu analysieren. Als typische elektrische Kenngrößen lassen sich
unter anderem die Flankensteilheit (engl.: slew rate) oder die Einschwingzeit (engl.:
rise time) ablesen. Für diese Simulationsart muss die Endzeit angegeben werden.
Bei einigen Simulatoren kann eine Startzeit angegeben werden. Diese beschränkt
dabei lediglich die Ausgabedaten des Simulators. Da es sich um eine zeitliche
Darstellung handelt, muss der Simulator stets bei t=0s beginnen, um das gesamte
Verhalten des Systemes abzubilden. In Abbildung 2 ist das Ergebnis einer
Transientsimulation zu dem in Abbildung 1 gezeigten Tiefpass aufgeführt (Startzeit:
0s, Endzeit: 0.25ms).
Seite 3

Einführung
Abbildung 2 Transientsimulation des Tiefpasses
Zu sehen ist, dass die Eingangsspannung Ue, sowie die Ausgangsspannung Ua über
der Zeit abgebildet sind. In dem hier gewählten Beispiel ist zu erkennen, dass die
Ausgangsspannung bereits deutlich geschwächt gegenüber der Eingangsspannung
ist. Neben der Schwächung des Signales ist das Einschaltverhalten des Systems
ersichtlich.
Die Wechselstrom-Simulation ermöglicht es, den Verlauf des Amplituden- und
Phasenganges eines Systems zu analysieren. Dazu wird eine Sinusspannungsquelle
mit variabler Frequenz verwendet. Dem Simulator muss dabei die Anfangs- und
Endfrequenz, sowie die Schrittweite mitgeteilt werden. Bei der Simulation werden für
jede Frequenz die Ströme und Spannungen für jeden Knotenpunkt berechnet. In
Abbildung 3 ist das Ergebnis einer Wechselstrom-Simulation für den Tiefpass aus
Abbildung 1 dargestellt.
Abbildung 3 Wechselstrom-Simulation des Tiefpasses
Zu sehen ist der Amplituden- und Phasengang der Eingangs- und
Ausgangsspannung über der Frequenz. Während die Eingangsspannung konstant
bleibt, ist zu erkennen, dass die Ausgangsspannung bei der Grenzfrequenz einbricht
Seite 4

Einführung
und eine Phasenverschiebung erfolgt. Die Berechnung der Grenzfrequenz ist in
Formel 1 aufgeführt. 1
Formel 1 Berechnung der Grenzfrequenz
Für jede Simulationsart besteht die Möglichkeit, Eigenschaften von Elementen zu
parametrisieren. Für diesen Parameterdurchlauf muss ein Start- und Endwert, sowie
die Anzahl der Zwischenschritte angegeben werden. Die Simulation wird für jeden
Wert des Parameters durchgeführt. Als Ergebnis erhält man eine Kurvenschar. Die
Parameterdurchläufe können dabei beliebig verschachtelt werden.
Die Anwendung Qucs bietet die Möglichkeit, Gleichungen zu den Schaltungen
anzugeben. Darüber lassen sich zusätzliche Werte berechnen, wie beispielsweise
die Phasenverschiebung der Ausgangsspannung bei einer Wechselstrom-
Simulation. Das Format der Transim Technology Corporation zur Darstellung von
Schaltungen bietet derzeit noch keine Möglichkeit Gleichungen einzubinden. Aus
diesem Grund wird im Rahmen dieser Arbeit nicht näher auf diese eingegangen.
1.4.2 Gliederung
Im Rahmen dieser Arbeit wird auf mehrere Programme bzw. Unterprogramme
eingegangen die für die Realisierung der Aufgabe modifiziert werden müssen. In
Kapitel 2 wird ein Überblick über die Programme gegeben und auf deren
Besonderheiten eingegangen. Die anschließenden Kapitel gehen tiefgründiger auf
die vorzunehmenden Modifizierungen an den Programmen ein. Hierbei werden
zuerst Vorbetrachtungen getroffen und anschließend auf die Implementierung näher
eingegangen. Die Reihenfolge der Kapitel ist an den Ablauf der Daten im System
angepasst. So wird zunächst auf den Simulator Qucs eingegangen. Anschließend
werden die Konvertierung und die Speicherung der Simulationsergebnisse im
EngineFramework behandelt, bevor schließlich die Ausgabe der Daten im
Webbrowser realisiert wird.
1 vgl. online: Tiefpass auf Wikipedia.org (07.08.2013)
Seite 5

2 Analyse des bestehenden Systems
2.1 Die Simulationsanwendung “Qucs”
Analyse des bestehenden Systems
Die Anwendung Qucs (Quite Universal Circuit Simulator) dient der Simulation von
Schaltungen. Der Quellcode ist unter der GPL (GNU General Public License) Lizenz
frei verfügbar. 2 Im Rahmen der Studienarbeit wurde bereits näher auf die
Anwendung eingegangen und Änderungen vorgenommen. 3 In dieser Bachelor
Thesis wird die in der Studienarbeit angepasste Version von Qucs verwendet. Der
Quellcode von Qucs ist in mehrere Teile gegliedert. In dieser Arbeit wird
ausschließlich der Simulator „qucsator.exe“ betrachtet. Dieser kann unabhängig von
den anderen Teilen erstellt und anschließend ausgeführt werden. Die
Simulationsanwendung wurde in der Sprache C++ programmiert.
Um eine Simulation zu starten, müssen dem Programm der Zielpfad zu einer
Ausgabedatei, sowie der Quellpfad einer Netzlistendatei angegeben werden. In einer
Netzliste werden alle Komponenten einer Schaltung in textueller Form gespeichert.
Dazu zählen zum einen die verwendeten Bauteile. Dazu zählen sowohl analoge
Elemente (wie Strom- oder Spannungsquellen, Kondensatoren, usw.), als auch
digitale Elemente (wie Taktgeneratoren, Logikgatter, FlipFlops, usw.). Neben den
Bauteilen befinden sich die Daten zu den entsprechenden Simulationen in der
Netzliste wieder. Ein Beispiel für eine solche Netzliste ist in Listing 1 aufgeführt.
# Qucs 0.0.17 C:/Qucs/Tiefpass/AC_Sweep.sch
# Bauelemente:
Vac:V1 gnd Ue U="1 V" f="1 GHz" Phase="0" Theta="0"
R:R Ue Ua R="R1" Temp="26.85" Tc1="0.0" Tc2="0.0" Tnom="26.85"
C:C gnd Ua C="1 nF" V=""
# Simulationen:
.AC:AC1 Type="log" Start="1 Hz" Stop="10 GHz" Points="50" Noise="no"
.SW:SW1 Sim="AC1" Type="log" Param="R1" Start="5 Ohm" Stop="5 MOhm"
Points="3"
Listing 1 Beispiel für eine Netzliste
Hier wurden, zur besseren Darstellung, die Komponenten nach Art sortiert und
Kommentare eingefügt. Für die Simulationsanwendung sind die Art und die
Reihenfolge der Komponenten nicht entscheidend.
Wurde der Anwendung beim Start eine Netzliste übergeben, werden alle
Simulationen ausgeführt. Die Ergebnisse werden anschließend in eine Ausgabedatei
geschrieben. Für zeitaufwändige Simulationen bedeutet dies, dass lange auf die
Ergebnisse gewartet werden muss. Eine Ausgabe der Zwischenergebnisse während
der Simulation ist nicht möglich. Diese Funktion soll im Rahmen dieser Bachelor
2 online: Qucs auf Sourceforge (12.07.2013)
3 vgl. Studienarbeit MEYER, 2013
Seite 6

Analyse des bestehenden Systems
Thesis in die Anwendung implementiert werden. Die Zwischenergebnisse sollen
dabei anderen Programmen zur Verfügung gestellt werden.
2.2 Der EngineServer
2.2.1 Allgemein
Die Transim Technology Corporation nutzt Simulationsanwendungen von
Drittherstellen. Somit können den Kunden unterschiedliche Simulationsmöglichkeiten
zur Verfügug gestellt werden. Der EngineServer stellt dabei die Verbindung zwischen
der Webanwendung und dem Simulator her. Zu den verwendeten
Simulationsanwendungen zählen beispielsweise SIMetrix, Portunus, LTSpice, Qucs,
etc. Diese benötigen zum Starten eine Abbildung der Schaltung in Form einer
Netzliste, oder einer Schematic-Datei. Das Format dieser Dateien ist für jede
Anwendung unterschiedlich. Ebenso werden die Simulationsergebnisse in einem,
von der Software abhängigem Format gespeichert. Zur Darstellung der Schaltungen
und der Simulationsergebnisse, hat die Transim Technology ein eigenes
Datenformat entwickelt. Dies bedeutet, dass vor einer Simulation die Schaltung in
das für die Anwendung spezifische Format konvertiert wird. Nach der Simulation
müssen schließlich die Ergebnisse wieder in das Transim-spezifische Format
konvertiert werden. Die Konvertierung der Schaltung in eine Qucs-Netzliste ist
bereits in dem EngineFramework implementiert. Auf diese wird im Rahmen dieser
Arbeit nicht näher eingegangen.
Aufgrund der unterschiedlichen Formate der einzelnen Simulationsanwendungen,
muss die Schnittstelle zu dem EngineServer für jede Software angepasst werden.
Aus diesem Grund hat die Transim Technology Corporation eine Generische Klasse
entwickelt, welche die grundlegenden Funktionen, wie das Starten der Simulation,
oder das Konvertieren der Ergebnisse, bereits deklariert. Für jeden Simulator
existiert eine eigene Klasse, welche von dieser generischen Klasse erbt. Diese
Klassen, die die Schnittstelle zwischen dem Simulator und dem EngineServer
darstellen werden folgend Engine genannt. Auf die Engine, die Qucs steuert, wird im
folgenden Kapitel näher eingegangen.
Neben dem Steuern der Simulationsanwendungen hat der EngineServer ebenfalls
die Aufgabe, die Simulationsergebnisse in unterschiedlichen Arten weiter zu
verarbeiten (genannt PostProcessing). So können beispielsweise die Ergebnisse, in
einem kartesischen Koordinatensystem dargestellt, als Bilddatei gespeichert werden.
Ebenfalls werden die Simulationsergebnisse für die Darstellung in einer
Webanwendung vorbereitet. Darauf wird im späteren Verlauf der Arbeit näher
eingegangen.
Seite 7

Analyse des bestehenden Systems
2.2.2 Der EngineServer als Webdienst
Der EngineServer wurde als Webdienst implementiert. Webdienste dienen zur
Interaktion zwischen unterschiedlichen Anwendungen über ein Netzwerk. Der
Webdienst verfügt über eine Schnittstellenbeschreibung, in der definiert ist, wie mit
dem Webdienst interagiert werden kann. Andere Programme können Anfragen an
den Webdienst stellen, auf die dieser mit der entsprechenden Information antwortet.
Der Webdienst wurde in der von Microsoft entwickelten C++/CLI programmiert.
Dabei handelt es sich um eine Abwandlung der Programmiersprache C++, die um
Sprachelemente erweitert wurde um einen Zugriff auf die Laufzeitumgebung der
.NET-Plattform zu ermöglichen. Somit können Besonderheiten der Common
Language Infrastructre (CLI), wie Ereignisse, automatische Speicherbereinigung,
generische Klassen, etc. verwendet werden.
Zum Ausführen des Webdienstes werden die Internet Information Services (IIS) von
Microsoft benötigt. Diese werden von Microsoft für die eigenen Betriebssysteme zur
Verfügung gestellt.
Wird eine neue Simulation gestartet wird dieser eine eindeutige
Identifikationsnummer für die Simulation (das JobHandle) zugewiesen. Diese wird
benötigt, um eine Zuordnung zwischen der ursprünglichen Simulationsanfrage und
den Simulationsergebnissen herstellen zu können.
2.3 Die QucsEngine
Im Rahmen der Studienarbeit wurde die QucsEngine zur Steuerung der Anwendung
Qucs entwickelt. 4 Diese startet zunächst über eine Netzliste die Simulation. Ist diese
abgeschlossen, werden die Simulationsergebnisse aus der Ausgabedatei
ausgelesen und in das framework-spezifische Format konvertiert und gespeichert.
Dazu wird die Ausgabedatei zeilenweise eingelesen und ausgewertet. Dieser
Algorithmus ist für die Verarbeitung der Simulationsergebnisse zur Laufzeit nicht
weiter verwendbar.
Der bisherige Ablauf der QucsEngine soll weiterhin möglich sein. Dies bedeutet,
dass der Engine mitgeteilt werden muss, welche Art von Simulation sie starten soll.
Die QucsEngine ist von einer generischen Klasse abgeleitet. In dieser ist bisher noch
keine Möglichkeit integriert zwischen unterschiedlichen Arten einer Simulation zu
unterscheiden. Dazu muss sich zunächst firmenintern abgesprochen werden, wie
diese Unterteilung erfolgen soll. Aus diesem Grund wurde sich vorerst dazu
entschieden, eine neue Engine, die QucsLiveEngine, zu entwickeln.
Die QucsEngine ist ebenfalls wie der EngineServer in C++/CLI programmiert. Somit
können die Funktionen des .NET-Frameworks verwendet werden. Um die Engine auf
4 vgl. Studienarbeit MEYER, 2013
Seite 8

Analyse des bestehenden Systems
dem EngineServer nutzen zu können, muss diese kompiliert und erstellt werden. Der
Erstellprozess erzeugt eine dynamische Programmbibliothek (engl.: Dynamic Link
Library – DLL). Diese kann nun im EngineServer verwendet werden. Dazu muss in
einer Konfigurationsdatei ein Verweis auf die Bibliothek gesetzt und der
EngineServer neu gestartet werden. Da die Engine von einer generischen Klasse
abgeleitet ist, die dem EngineServer bekannt ist, muss dieser nicht neu erstellt
werden, um die neue Engine verwenden zu können.
2.4 Die Darstellung der Simulationsdaten in der Webanwendung
Um die Darstellung einer Schaltung in einem Webbrowser zu ermöglichen, hat die
Transim Technology Corporation das sogenannte Web-Schematic entwickelt. Dieses
bietet neben der Darstellung der Schaltung ebenfalls die Möglichkeit, Parameter für
einzelne Bauteile anzupassen. Über das Web-Schematic können die Simulationen
der Schaltungen gestartet werden. In Abbildung 4 ist ein Beispiel für das Web-
Schematic zu sehen.
Abbildung 4 Das Web-Schematic
Wurde eine Simulation gestartet muss der Nutzer der Webanwendung warten bis die
Simulation beendet wurde. In dieser Zeit wird ein Dialogfenster angezeigt, das über
die ungefähre restliche Bearbeitungszeit der Simulation Auskunft gibt. Ist die
Simulation abgeschlossen werden die Simulationsdaten in einem zusätzlichen Modul
angezeigt. Dieses Modul wird WebScope genannt. Hier können die
Simulationsergebnisse als Kurvenverläufe in unterschiedlichen Diagrammen
Seite 9

Analyse des bestehenden Systems
abgebildet werden. Abbildung 5 zeigt ein Beispiel für die Ausgabe der
Simulationsdaten in WebScope
Abbildung 5 WebScope nach Abschluss einer Simulation
Im Rahmen dieser Arbeit soll eine Möglichkeit entwickelt werden, dem Nutzer die
Simulationsdaten zur Laufzeit der Simulation anzuzeigen.
Seite 10

Änderungen an Qucs
3 Änderungen an Qucs
3.1 Vorüberlegungen
3.1.1 Kommunikation zwischen den Anwendungen
Zum Datenaustausch zwischen zwei oder mehreren Programmen, auch
Interprozesskommunikation genannt, gibt es unterschiedliche Methoden die im
Folgenden kurz näher erläutert werden: 5
Shared Memory
Bei dieser Methode wird ein Bereich im Arbeitsspeicher festgelegt, auf den mehrere
Prozesse zugreifen können. Um ein gleichzeitiges Lesen/Schreiben von mehreren
Prozessen zu verhindern wird ein Mechanismus zum Wechselseitigem Ausschluss
(auch Mutex genannt) verwendet. Dem Empfänger muss dabei mitgeteilt werden,
wann neue Daten vorliegen. Diese Methode eignet sich besonders bei großen
Datenmengen, jedoch müssen Sender- und Empfängerprozess auf den
gemeinsamen Speicher zugreifen können. Somit ist diese Methode nicht geeignet,
wenn die Programme auf unterschiedlichen Computern ausgeführt werden.
Ereignisse
Bei dieser Methode kann der sendende Prozess ein sogenanntes Ereignis auslösen.
Der empfangende Prozess kann sich für dieses Ereignis registrieren. Dazu muss ein
Unterprogramm (auch Behandlungsroutine genannt) angegeben werden, welches
bei Eintreten des Ereignisses ausgeführt werden soll. Ein Beispiel dieses Konzeptes
stellen die Software Interrupts dar. Diese Methode wird nur von einigen
Betriebssystemen unterstützt, wobei jedes Betriebssystem die Methode
unterschiedlich implementiert hat.
Funktionsaufrufe
Eine weitere Methode besteht darin, einem anderen Prozess Zugriff auf einzelne
Funktionen zu gewähren. Bei dieser Methode ist es möglich, dass sich Sender- und
Empfängerprogramm auf unterschiedlichen Computern befinden. Diese Methode ist
in vielen Programmiersprachen über zusätzliche Bibliotheken und Dienstprogramme
eingebunden und somit weitestgehend vom Betriebssystem unabhängig.
Datenströme
Als letzte Methode stehen die Datenströme zur Verfügung. Diese bieten die
Möglichkeit Daten sequentiell von dem Sender zum Empfänger weiter zu reichen.
Dabei schreibt der Sender in den Datenstrom, während der Empfänger die Daten
aus diesem Strom liest. Diese Methode kann über Pipes, Named Pipes oder
5 vgl. online: Interprozesskommunikation auf Wikipedia.org (15.07.2013)
Seite 11

Änderungen an Qucs
verbindungsorientierte Netzwerkprotokolle realisiert werden. Hier spricht man auch
von Sockets. Dabei kann über Pipes lediglich innerhalb eines Prozesses
kommuniziert werden. Mithilfe von Named Pipes ist dies auch zwischen
unterschiedlichen Prozessen möglich, jedoch müssen diese auf demselben
Computer ausgeführt werden. Durch die Nutzung von Sockets können auch
Prozesse, die auf unterschiedlichen Computern ausgeführt werden untereinander
kommunizieren.
Für die Wahl der Methode sind zunächst die Anforderungen zu betrachten. Es ist
denkbar, dass Qucs die Simulationsergebnisse an eine Anwendung senden soll, die
nicht auf demselben Computer ausgeführt wird. Somit fällt die Nutzung eines
gemeinsamen Speichers aus der Auswahl. Des Weiteren soll eine hohe
Kompatibilität der Kommunikation erreicht werden. Da die ereignisgesteuerte
Kommunikation stark von dem Betriebssystem abhängt entfällt somit auch diese. Für
die Verwendung von Funktionsaufrufen werden in C++ zusätzliche
Programmbibliotheken benötigt. Die Wahl viel somit auf die Verwendung von
Sockets, weil diese in den meisten Betriebssystemen in C++ zur Verfügung stehen.
Um die Simulationsergebnisse über einen Socket einer anderen Anwendung zur
Verfügung zu stellen, benötigt Qucs die Adressinformationen des Empfängers. Zu
diesen Adressinformationen zählen die Adressfamilie, die IP-Adresse des Computers
auf dem der Empfängerprozess ausgeführt wird, sowie der Port, auf den der
Empfängerprozess gebunden ist. Die Adressfamilie wird dabei auf „Internetadresse“
festgelegt. Die IP-Adresse, sowie der Port des Empfänger-Computers sollen variabel
gehalten werden. Befinden sich Qucs und Empfängerprozess auf dem gleichen
Computer muss als IP-Adresse 127.0.0.1 angegeben werden.
3.1.2 Verwendung des Netzwerkprotokolls
Wie aus Kapitel 3.1.1 hervorgeht, soll für die Übertragung der Dateien eine Socket-
Kommunikation implementiert werden. Hierbei gibt es Stream- und Datagram-
Sockets, die jeweils durch ein Protokoll vereinbart sind
Transmission Control Protocol (TCP) – Stream Socket
Das TCP stellt zwischen zwei Endpunkten eine Verbindung her, es ist somit ein
verbindungsorientiertes Protokoll. Dabei können Daten in beide Richtungen
übertragen werden. Treten bei der Verbindung Datenverluste auf, werden diese
automatisch erkannt und behoben. Ebenfalls wird sichergestellt, dass die
gesendeten Pakete in der gleichen Reihenfolge bei dem Empfänger eingehen in der
sie beim Sender verschickt wurden.
User Datagram Protocol (UDP) – Datagram Socket
UDP ist, im Gegensatz zu TCP, ein verbindungsloses Netzwerkprotokoll. Alle Daten
werden versendet, ohne zu prüfen, ob diese entgegengenommen werden.
Seite 12

Änderungen an Qucs
Datenverluste werden nicht erkannt, und somit auch nicht behoben. Die Reihenfolge
der empfangenen Pakete muss nicht der Reihenfolge der gesendeten Pakete
entsprechen.
Der Vorteil von TCP besteht in dem Sicherheitsaspekt. Jedoch kann es zu
Verzögerungen kommen, da ein weiteres Paket erst übertragen wird, wenn
sichergestellt ist, dass das vorherige am Empfänger eingetroffen ist. Somit hat UDP
einen erheblichen Vorteil, wenn es darum geht schnell Daten zu übertragen.
Da zu diesem Zeitpunkt der Entwicklung nicht abzusehen ist, ob es darauf ankommt,
die Ergebnisse sicher zu übertragen und dafür eine längere Übertragungszeit
akzeptiert wird, oder ob es auf eine schnelle Übertragung ankommt, bei der auch
Pakete verloren gehen können, ist die Entscheidung gefallen zunächst beide
Protokolle in Qucs zu implementieren.
3.1.3 Zuweisung der gesendeten Daten zu einer Simulation
Aus den bisher getroffenen Überlegungen ergibt sich der folgende Ablauf auf dem
EngineServer. Wird eine neue Simulation angefordert, wird eine neue QucsEngine
erstellt. Diese startet Qucs und empfängt während der Simulation über eine
Netzwerkschnittstelle die Ergebnisse. Es ist jedoch denkbar, dass während eine
Simulation läuft, eine weitere gestartet wird. Somit werden weitere
Simulationsergebnisse über das Netzwerk übertragen. Dies bedeutet, dass die
übertragenen Daten, einer QucsEngine zugeordnet werden müssen. Bei der Lösung
dieses Problems kamen die folgenden zwei Lösungen in Betracht.
Zuweisung über eine Identifikationsnummer
Eine Überlegung besteht darin, auf dem EngineServer eine Serverinstanz
auszuführen, die alle Simulationsergebnisse entgegen nimmt. Anschließend weißt
dieser die Ergebnisse an die entsprechende QucsEngine zu. Dafür muss jedoch eine
Unterscheidung der eingehenden Daten erfolgen. Um dies zu erreichen kann Qucs
eine eindeutige Identifikationsnummer beim Starten übergeben werden. Diese
Nummer wird anschließend bei der Übertragung jedes einzelnen
Simulationsergebnisses mit an den Server übertragen. Dieser kann anhand der
Identifikationsnummer die Ergebnisse den Simulationen zuweisen. Bei dieser
Variante wird lediglich ein Server zur Entgegennahme der Ergebnisse benötigt. Der
Nachteil dieser Variante besteht jedoch darin, dass eine erhöhte Netzwerkauslastung
stattfindet, und Qucs um einen zusätzlichen Startparameter erweitert werden muss.
Zuweisung über einen Port
Als zweite Möglichkeit kam in Betracht, dass jede QucsEngine eine eigene
Serverinstanz startet. Diese bindet sich an einen beliebigen freien Port. Dieser Port
wird beim Starten von Qucs übergeben. Somit werden die Simulationsergebnisse nur
an den entsprechenden Port übertragen und es entstehen keine zusätzlichen
Seite 13

Änderungen an Qucs
Netzwerkdaten. Der Nachteil besteht jedoch darin, dass für jede Simulation eine
eigene Serverinstanz erstellt werden muss.
Die Wahl fiel schließlich auf die portbasierte Zuweisung. Da Qucs zum Starten des
Netzwerkdienstes bereits die IP-Adresse und der Port der Serverinstanz übergeben
werden müssen, entfällt hier der zusätzliche Startparameter. Die Serverinstanz kann
geschlossen werden sobald die Simulation beendet ist. Bei der Verwendung der
anderen Überlegung müsste die Instanz entweder permanent ausgeführt werden,
oder eine Steuerung implementiert werden, die diese erst beendet, wenn keine
Simulation ausgeführt wird.
3.1.4 Formatierung der Simulationsergebnisse
3.1.4.1 Analyse der bisherigen Ausgabedateien von Qucs
Betrachtet man die Ausgabedateien von Qucs, erkennt man, dass die Ergebnisse in
einer XML-ähnlichen Struktur gespeichert werden. In Listing 2 ist eine Ausgabedatei
in gekürzter Form aufgeführt. Die vollständige Datei befindet sich in Anhang 1. Die
Ergebnisse einer Simulation werden in den -Tags gespeichert. Als Attribute
wird in ihnen angegeben, von welchen Eingangsparametern diese abhängen. Die
Werte für die Eingangsparameter sind dabei in den -Tags hinterlegt.
+1.00000000000e+000
...
...
...
-4.93480220054e-017-j3.14159265359e-009
-4.93479002439e-007-j3.14158490204e-004
...
+1.00000000000e+000-j1.57079632679e-008
...
...
Listing 2 Ausschnitt einer Qucs-Ausgabedatei
Bei der Netzwerkausgabe der Simulationsergebnisse müssen diese Abhängigkeiten
ebenfalls übergeben werden, da sonst keine Zuordnung der einzelnen Ergebnisse zu
den Eingangsparametern möglich ist. Es ergibt sich daraus die Überlegung, dass
nach einem erfolgten Simulationsschritt eine Liste für die Abhängigkeiten, sowie eine
Liste für die Ergebnisse erstellt wird und anschließend Beide an die Serverinstanz
übertragen werden.
Seite 14

3.1.4.2 Betrachtungen zu der Paketgröße und dem Datenformat
Änderungen an Qucs
Wie bereits erläutert, sollen die Simulationsergebnisse über ein Netzwerk
ausgegeben werden. Die Übertragung der Daten kann dabei im gleichen Thread wie
die Berechnung erfolgen, oder in einen neuen Thread verlagert werden. Wird nur ein
Thread dafür verwendet kommt es zu einer Verlangsamung der gesamten
Simulation, da während der Übertragungszeit keine neuen Ergebnisse berechnet
werden. Lagert man das Senden der Daten in einen extra Thread aus, benötigt man
einen zusätzlichen Puffer, in dem die Simulationsergebnisse zwischengespeichert
werden. Für die Übertragung würde dann ein Ergebnis aus dem Puffer entnommen
und an den Server übertragen werden. Läuft die Berechnung der Ergebnisse jedoch
deutlich schneller, als das Senden, kann es passieren, dass keine Elemente mehr in
den Puffer geschrieben werden können. Ebenfalls muss hier dafür gesorgt werden,
dass nicht gleichzeitig vom Puffer gelesen und darauf geschrieben wird (dies wird
auch Threadsicherheit genannt) und ist aufwändiger zu implementieren. Aus diesem
Grund wurde sich für die Verwendung eines Threads entschieden. Um die Dauer des
Blockierens zu verringern muss eine Optimierung an der Paketgröße der
übertragenen Daten erfolgen.
Der Netzzugang im späteren Einsatzgebiet wird das Ethernet sein. Ethernet regelt
den Datenaustausch zwischen zwei Endpunkten über Pakete. Um eine möglichst
schnelle Ausgabe der Simulationsergebnisse zu erreichen, muss die Anzahl der
übertragenen Datenpakete gering gehalten werden. Laut den Spezifikationen des
Ethernet-Rahmens, stehen pro Paket für die zu sendenden Daten maximal 1.500
Byte zu. 6
Eine Übertragung der Ergebnisse soll nach einem Simulationsschritt erfolgen. Neben
den einzelnen Ergebnissen werden auch die entsprechenden Abhängigkeiten
gesendet. Dazu wird ein Datenformat entworfen, das ermöglicht, mehrere
Ergebnisse, sowie die zugehörigen Abhängigkeiten abzubilden. Hier haben sich zwei
Formen etabliert, auf die im Folgenden kurz eingegangen wird.
XML (Extensible Markup Language)
Die XML ist eine Auszeichnungssprache und kann hierarchisch strukturierte Daten in
Textform darstellen. Sie wurde von dem World Wide Web Consortium (W3C)
spezifiziert.
JSON (JavaScript Object Notation)
Die JavaScript Object Notation ist ein Datenformat. Im Gegensatz zu XML ist JSON
typisiert, wobei jedoch nur grundlegende Typen unterstützt werden. Ein JSON-
Dokument lässt sich mit JavaScript direkt in ein Objekt umwandeln.
6 vgl. IEEE 802.3-2012-Section One, 2013, S. 53-57
Seite 15

Änderungen an Qucs
Über beide Formate lassen sich Daten in Textform abbilden. Sowohl XML als auch
JSON werden von vielen Programmiersprachen unterstützt. Durch die
unterschiedlichen Formatierungen entsteht jedoch bei beiden Formen ein
unterschiedlicher Overhead. Als Overhead werden alle Daten bezeichnet, die nicht
zu den Nutzdaten gehören. In Tabelle 1 sind ein XML-, sowie ein JSON-Format
aufgeführt. Ebenfalls wurden die Zeichen, sowie die daraus resultierende Größe des
Overheads bestimmt.
Übersicht
XML
...
...
...
...
JSON
{"qucs":
{"v":"0.0.17",
"i":[
{"n":"...","v":"..."},
...
],
"d":[
{"n":"...","v":"..."},
...
]
}
}
Overhead
allgemein
...
{"qucs":
{"v":"0.0.17",
...
}
}
Overhead pro
Abhängigkeit
...
"i":[...],
{"n":"...","v":"..."} ( )
, ( )
Overhead pro
Ergebnis
...
( ) ( ( ) ( ))
"d":[...]
{"n":"...","v":"..."} ( )
, ( )
( ) ( ( ) ( ))
Summe ( ) ( )
Anmerkung
Tabelle 1 Vergleich des Overheads bei XML und JSON
Betrachtet man die Differenz beider Werte (siehe Formel 2), wird deutlich, dass der
Overhead des JSON-Formates nur günstiger ist, wenn ein Ergebnis und eine
Seite 16

Änderungen an Qucs
Abhängigkeit vorhanden sind. Steigt die Anzahl der Ergebnisse, bzw. Abhängigkeiten
ist das XML-Format besser geeignet.
( ) ( ) ( ( ) (
( )))
( ( ))
Formel 2 Differenz des Overheads von XML und JSON
In Anhang 2 sind die resultierenden Paketgrößen in Abhängigkeit von der Anzahl der
Simulationsergebnisse, sowie deren Abhängigkeiten tabellarisch aufgelistet. Nach
der Konvertierung der Werte in eine Zeichenkette haben diese eine maximale Länge
von 39 Zeichen. Aus diesem Grund wurden hier zusätzlich 39 Byte in die
Berechnung eingebunden. Aus den Tabellen ist zu erkennen, dass durch die
Nutzung des XML-Formates mehr Daten in einem Ethernet-Paket übertragen werden
können, als bei der Verwendung des JSON-Formates.
3.1.5 Nachbilden zeitintensiver Simulationen
Die Betrachtungen in Kapitel 3.1.4.2 bezogen sich speziell auf Simulationen deren
Zwischenergebnisse schnell berechnet werden. Es gibt jedoch auch Simulationen die
eine längere Zeit benötigen um ein Zwischenergebnis zu erzeugen. Für den späteren
Entwicklungsverlauf empfiehlt es sich, dieses Verhalten in dem Simulator
nachzuahmen. So kann die Visualisierung der Zwischenergebnisse auch mit
einfachen Beispielen getestet werden.
3.1.6 Die Netzwerkkommunikation
Als Grundlage für die Modifizierungen an Qucs wird die Quelltextversion verwendet,
die im Rahmen der Studienarbeit aus dem fünften Semester entstanden ist. In der
Studienarbeit wurde erörtert, dass die Implementierung einer
Netzwerkkommunikation entweder mit dem Einbinden einer entsprechenden
Klassenbibliothek oder durch die Nutzung von betriebssystem-abhängigen
Funktionen vorgenommen werden kann. Im Rahmen der Studienarbeit kam es bei
der Verwendung von zusätzlichen Klassenbibliotheken zu komplexen Problemen. 7
Aus diesem Grunde wurde die Plattformunabhängigkeit für die Fortsetzung der Arbeit
aufgegeben, und sich dafür entschieden die betriebssystem-spezifischen Funktionen
zu nutzen.
Um die Ausgabe der Simulationsdaten über das Netzwerk testen zu können, wurde
ebenfalls in der Studienarbeit ein TCP- sowie ein UDP-Server erstellt, der
eingehende Daten in der Windows-Konsole ausgibt. Die Server wurden in JavaScript
7 vgl. Studienarbeit MEYER, 2013
Seite 17

Änderungen an Qucs
geschrieben. Zum Ausführen wird Node.js benötigt. An den Servern wurden einige
Veränderungen vorgenommen. So wird nun die Systemzeit zu der eine Nachricht
erhalten wurde ebenfalls mit ausgegeben. Diese Server dienen ausschließlich zum
Testen der Netzwerkausgabe von Qucs. Der Quelltext der Server ist in Anhang 3
aufgeführt.
3.2 Implementierung
3.2.1 Der Programmeinstieg
Wie aus Kapitel 3.1.2 hervorgeht, soll sowohl eine Übertragung über TCP, als auch
über UDP möglich sein. Ebenso wurde in Kapitel 3.1.1 erörtert, dass für das
Herstellen einer Verbindung, sowohl die IP-Adresse des Servers, sowie der Port auf
den die Serveranwendung gebunden ist, bekannt sein müssen. Um diese
Informationen an die Anwendung zu übertragen wurden die zwei neuen
Starparameter -udp und -tcp hinzugefügt. Zusätzlich wurde ein Paramter
hinzugefügt, über den die in Kapitel 3.1.5 angesprochene Verzögerungszeit in
Millisekunden übergeben werden kann. Die Anwendung wartet nach einem
Simulationsschritt die Zeit ab, bevor der nächste Simulationsschritt folgt. Listing 3
zeigt die hinzugefügten Startparameter.
Usage: qucsator.exe [OPTION]...
-udp IP:PORT use UDP to send the simulation results to an UDP-Server
-tcp IP:PORT use TCP to send the simulation results to a TCP-Server
-d DELAY set delay in [ms] between simulation steps
Listing 3 Startparameter für die Netzwerkkommunikation
Der Programmeinstieg befindet sich in der Datei ucs.cpp. Hier befindet sich die
Bearbeitung der bereits definierten Startparameter. Die Daten, zu der Zieladresse,
sowie der Verzögerungszeit, werden hier in globalen Variablen der Netzwerkklasse
hinterlegt. Dadurch ist im späteren Verlauf der Programmabarbeitung ein Zugriff auf
diese möglich. Die am Quelltext getätigten Änderungen finden sich in Anhang 4.
3.2.2 Die Netzwerkklasse
Um die in Kapitel 3.1.6 angesprochenen Probleme zu verringern wurde eine eigene
Klasse entwickelt, in der die Kommunikation zu dem Server umgesetzt wird. Wird
später eine plattformunabhängige Klassenbibliothek eingebunden, muss somit nur
die Netzwerkklasse angepasst werden. Alle Änderungen im Simulator die auf die
Klasse zugreifen müssen nicht geändert werden.
Im Anhang 5 befindet sich die Header-, sowie die Quelltext-Datei für die entwickelte
Netzwerkklasse. Wie zu erkennen ist, wird im Rahmen dieser Arbeit die Windowsspezifische
winsock2.h eingebunden, die Methoden zur Herstellung und Verwendung
einer Netzwerkkommunikation bereitstellt. Zur Zuweisung des Protokolls wurde ein
Enumerationstyp definiert. Dem Konstruktor muss die Ziel-Adresse, sowie das zu
nutzende Protokoll übergeben werden. Zu der Ziel-Adresse gehören die IP-Adresse,
Seite 18

Änderungen an Qucs
sowie der Port des Ziels. Diese werden, wie unter Listing 3 beschrieben, als
Startargument dem Programm als Zeichenkette übergeben und kann über die
statische Funktion getAddr(...) in IP-Adresse und Port aufgeteilt werden. Die
weiteren öffentlichen Methoden stellen die Verbindung zu einem Server her und
ermöglichen das Senden von Daten. Eine Methode zum Empfangen wurde nicht
implementiert, da keine Daten empfangen werden müssen. 8
Zusätzlich wurden in der Header-Datei Deklarationen für externe, globale Variablen
getroffen. Auf diese kann in jeder Quellcode-Datei zugegriffen werden, in welcher die
network.h eingebunden wird. So können bereits zum Programmstart die Daten für
die Zieladresse gespeichert werden.
3.2.3 Einbinden der Netzwerkklasse
3.2.3.1 Die Klassenhierarchie der Simulationssoftware
Für die Übertragung der Simulationsergebnisse muss der aktuelle Simulationsschritt
abgeschlossen sein. Bei der Analyse des Quellcodes von Qucs hat sich gezeigt,
dass für jede Simulationsart eine eigene Klasse existiert. Damit nicht in jeder dieser
Klassen das Senden der Daten implementiert werden muss, wurde zunächst die
Klassenhierarchie von Qucs näher untersucht. Das Resultat ist in Abbildung 6 als
vereinfachtes Klassendiagramm dargestellt.
object
analysis
...
nasolver parasweep ...
dcsolver acsolver trsolver
Abbildung 6 Die Klassenhierarchie der Simulatoren von Qucs
Zu sehen ist, dass die Klassen für die Simulationen von der Klasse nasolver
abgeleitet sind. Diese ist, ebenso wie die Klasse parasweep, von der Klasse analysis
abgeleitet. Die Klasse parasweep wird für den Parameterdurchlauf benötigt. Die
Berechnung der Simulationsergebnisse erfolgt jedoch ausschließlich in den von
nasolver abgeleiteten Klassen. Es bietet sich daher an, die Netzwerkkommunikation
in die nasolver–Klasse zu implementieren.
8 Bei der Entwicklung der Netzwerkklasse wurde sich an die Anleitungen von c-worker.ch zum Thema
„Winsock“ gehalten – vgl c-worker.ch
Seite 19

Änderungen an Qucs
Dazu muss in dieser die Netzwerkklasse eingebunden werden. Zusätzlich wird eine
private Membervariable vom Typ network angelegt. Über diese soll die
Kommunikation zum Server realisiert werden. In Anhang 6 sind die Änderungen
aufgeführt, die an der Klasse vorgenommen wurden. In den Konstruktoren wird die
Verbindung zu dem Server hergestellt. Bei den Variablen networkUse, networkAddr
und networkProtocol handelt es sich um die externen globalen Variablen der
Netzwerkklasse. Diese wurden bereits beim Programmstart in der Datei ucs.cpp
gesetzt. Das Senden der Daten erfolgt in der Funktion saveResults(). An dieser
Stelle sind alle Ergebnisse der Simulation berechnet worden. Vor dem Senden wird
das XML-Dokument erzeugt. In der Variable netPrint sind an diesem Punkt des
Programmablaufes alle XML-Konten für die Abhängigkeiten und Ergebnisse
enthalten. Auf diese Variable wird in den folgenden beiden Kapiteln näher
eingegangen.
3.2.3.2 Erkennen der Simulationsergebnisse
Bei der Analyse des Quelltextes von Qucs hat sich gezeigt, dass in der Datei
analysis.cpp unter der Funktion saveVariable(...) die Simulationsergebnisse für
die spätere Verwendung gespeichert werden. Um die Simulationsergebnisse für die
Übertragung vorzubereiten wurde die Funktionen getDNode(...) implementiert.
Diese erzeugt einen XML-Knoten und hängt diesen an die Zeichenkette netPrint an.
Übergeben wird der Funktion der Name des Ergebnisses, sowie dessen Wert. Zu
Beginn wird der Wert in eine Zeichenkette umgewandelt. Anschließend erfolgt die
Erzeugung und Speicherung des Knotens. In C++ werden Zeichenketten als Felder
vom Typ char behandelt. Für ein Feld wird nur ein begrenzter Bereich des
Arbeitsspeichers reserviert. Werden der Zeichenkette neue Elemente angefügt, kann
es zu einem Zugriff auf nicht reservierten Speicher kommen. Aus diesem Grund wird
hier die existierende Zeichenkette in der Hilfvariable help gespeichert. Anschließend
wird der Speicherbereich der ursprünglichen Zeichenkette netPrint freigegeben. Für
diese wird dann ein neuer Speicherbereich allokiert, welcher der Länge der alten
Zeichenkette plus der des neuen Knotens entspricht. Wurde der Speicher allokiert
kann die neue Zeichenkette erstellt werden. Zum Schluss wird der Speicherbereich,
den die Hilfsvariable belegt, wieder freigegeben und der XML-Knoten als
Zeichenkette übergeben. Die netPrint-Variable wird nach jedem Simulationsschritt
wieder zurückgesetzt.
3.2.3.3 Erkennen der Abhängigkeiten
Für die spätere Verarbeitung der Simulationsergebnisse, müssen deren
Abhängigkeiten mit übertragen werden. Als Abhängigkeit ist beispielsweise für eine
Transientsimulation die Zeit, oder für eine Wechselstromsimulation die Frequenz
anzusehen. Werden in einer Simulation ein oder mehrere Parameterdurchläufe
verwendet, entstehen zusätzliche Abhängigkeiten. Die Abhängigkeiten können dabei
Seite 20

Änderungen an Qucs
nicht in netPrint gespeichert werden. Obwohl für jeden Simulationsschritt ein neuer
Wert für beispielsweise die Frequenz vorliegt, muss beachtet werden, dass ein
übergeordneter Parameterdurchlauf existieren kann. Wird der aktuelle Wert des
Parameters in die Variable netPrint geschrieben, wäre dieser nur im ersten
Simulationsschritt bekannt. Es müssen daher die Werte der übergeordneten
Simulationen gespeichert werden.
Dazu wurde die solve()-Funktion der analysis-Klasse überladen. Dieser kann nun
eine Zeichenkette übergeben werden, die in die zusätzliche Membervariable Indeps
kopiert wird. Zusätzlich wurde eine Funktion getINode() implementiert. Dieser
werden der Name, sowie der aktuelle Wert des aktuellen Simulationsschrittes
übergeben. In der Funktion wird der XML-Knoten für die Abhängigkeit erzeugt. Die
Funktion gibt anschließend die Zusammenführung der bereits existieren Indeps-
Variable und des neuen XML-Knotens zurück. Der zuletzt hinzugefügt Knoten steht
dabei an erster Stelle. Dies ist für die spätere Auswertung des XML-Dokumentes von
Bedeutung. Für jeden Simulationsschritt sind somit die übergeordneten Parameter,
sowie der aktuelle Wert bekannt und kann vor der Berechnung der Ergebnisse in die
netPrint-Variable geschrieben werden. Die Änderungen an der analysis-Klasse
sowie ein Beispiel für die Verwendung der getINode()- und getDNode()-Funktion
befinden sich in Anhang 7.
Seite 21

Die QucsLiveEngine
4 Die QucsLiveEngine
4.1 Vorbetrachtungen
4.1.1 Starten der Simulation
Eine Aufgabe der QucsLiveEngine besteht darin, die Simulationsanwendung zu
starten. Dazu muss dieser der Speicherort der qucsator.exe-Datei bekannt sein. Der
Pfadverweis soll, wie bereits in der QucsEngine, über einen Eintrag in der Windows-
Registrierdatenbank zur Verfügung gestellt werden. Wäre der Speicherort im
Quellcode hinterlegt, müsste die Anwendung, bei einer Änderung des Speicherortes,
neu erstellt werden. Ebenfalls können durch diese Methode Startparameter einfach
bearbeitet werden. Der Befehl zum Starten der Simulation ist dabei wie folgt
aufgebaut:
[QucsDir]\bin\qucsator.exe –i -o –tcp 127.0.0.1:
{-d x}
Dabei steht QucsDir für das Installationsverzeichnis von Qucs. Die Zeichenketten
und werden durch die Pfadangaben zu der Netzliste und der
Ausgabedatei ersetzt. Über wird der Anwendung mitgeteilt, auf welchem Port
der Server die Ergebnisse entgegennimmt. Zusätzlich kann über „–d x“ eine
Verzögerung zwischen den einzelnen Simulationsschritten in x Millisekunden erzeugt
werden.
4.1.2 Empfangen der Simulationsdaten
Um die Simulationsdaten von der Simulationsanwendung entgegennehmen zu
können, muss zunächst ein Server implementiert werden. Qucs bietet die Möglichkeit
die Daten sowohl über TCP als auch UDP zu übertragen. Für die Wahl des
entsprechenden Protokolls muss nun betrachtet werden, wie die Simulationsdaten in
der QucsLiveEngine weiter verarbeitet werden. Zunächst müssen die Daten in das
framework-spezifische Format konvertiert und anschließend gespeichert werden. Es
ist nun die Situation denkbar, dass die Konvertierung und Speicherung der Daten
mehr Zeit in Anspruch nimmt, als die Berechnung des nächsten Simulationsschrittes.
Bei der Verwendung von UDP würde dies bedeuten, dass die Daten schneller in den
UDP-Puffer geschrieben werden, als sie daraus gelesen werden. Da durch UDP
nicht sichergestellt wird, dass alle Daten korrekt beim Empfänger eingehen, kann es
zu einem Überlauf des Puffers führen. TCP hingegen stellt sicher, dass alle
gesendeten Daten beim Empfänger eingehen. Das Senden der Daten über TCP
wurde in Qucs über einen blockierenden Algorithmus implementiert. Dies bedeutet,
dass der nächste Simulationsschritt erst erfolgt, wenn für die zuletzt übertragenen
Daten eine Empfangsbestätigung (Acknowledgement) eingegangen ist. Da Qucs auf
die Bestätigung des Empfängers warten muss, kann es zu einer längeren
Bearbeitungszeit der Simulation kommen.
Seite 22

Die QucsLiveEngine
Ein weiterer Aspekt, der für die Verwendung des TCP spricht, ist die Verarbeitung
der Daten. Diese werden fortlaufend in einer Datei hinterlegt. Somit ist die korrekte
Reihenfolge der empfangen Daten von hoher Bedeutung. TCP stellt im Gegensatz
zu UDP sicher, dass die Daten in der Reihenfolge beim Empfänger eingehen, wie sie
beim Sender versandt wurden. Somit fiel die Wahl auf TCP, weil dieses sicherstellt,
dass alle Daten korrekt empfangen werden. Der daraus resultierend längeren
Bearbeitungszeit ist eine wesentlich niedrigere Priorität zuzuordnen, und kann daher
in Kauf genommen werden.
Vom Programmablauf her ist zu beachten, dass der TCP-Server gestartet wurde und
sich im Listen-Modus befindet, bevor die ersten Daten übertragen werden. Da es
sich bei Programmen um eine sequentielle Abarbeitung der Befehle handelt muss
dementsprechend zuerst der TCP-Server gestartet werden, bevor die
QucsLiveEngine die Simulation startet. Betrachtet man die Funktionsweise des TCP-
Servers kommt es hier jedoch zu einem Problem. Befindet sich der Server im Listen-
Modus wird die Anwendung blockiert bis eine Nachricht eingegangen ist. Da Qucs
jedoch erst gestartet werden kann, nachdem der TCP-Server sich in dem Listen-
Modus befindet, entsteht hier ein Blockieren der gesamten QucsLiveEngine. Eine
Lösung dieses Problems bietet die Verwendung von Threads. So wird zunächst der
Server gestartet. Bevor dieser in den Listen-Modus gesetzt wird, wird ein neuer
Thread erstellt. In diesem wird der Server in den Listen-Modus gesetzt und kann die
von Qucs gesendeten Nachrichten empfangen und weiter verarbeiten Somit kann im
ursprünglichen Thread die Funktion aufgerufen werden, die schließlich Qucs startet.
Anschließend muss darauf gewartet werden, dass zum einen die Anwendung
geschlossen wurde, und zum anderen der zusätzliche Thread beendet wurde. Es
bietet sich hier an, diesen zu beenden, sobald die TCP-Verbindung vom Client
unterbrochen wurde. Anschließend kann die QucsLiveEngine wie gewohnt
ausgeführt werden.
4.1.3 Auswerten des XML-Dokumentes
Aus Kapitel 3.1.4.2 geht hervor, dass die Daten in einem XML-Dokument übertragen
werden. Um die Simulationsergebnisse aus dem XML-Dokument zu erhalten wird ein
XML-Parser benötigt. Für die Programmiersprache C++ existieren bereits viele XML-
Parser, die sich in ihrem Umfang und der Funktionalität unterscheiden. Der Zugriff
auf das Dokument erfolgt dabei üblicherweise über die DOM-API (Document Object
Model – Application Programming Interface) oder die SAX-API (Simple API for XML).
Bei der DOM-API wird das XML-Dokument als Baumstruktur abgebildet. Dadurch ist
ein sowohl lesender, als auch schreibender Zugriff auf alle Elemente des
Dokumentes möglich. Dies hat jedoch den Nachteil, dass große XML-Dokumente viel
Seite 23

Die QucsLiveEngine
Arbeitsspeicher beanspruchen. 9 Bei der SAX-API hingegen wird das XML-Dokument
als Datenstrom abgebildet. Treten beim Lesen des Streams vordefinierte Ereignisse
auf, werden den Ereignissen zugewiesene Funktionen aufgerufen. Der Vorteil liegt
im niedrigen Speicherverbrauch, jedoch ist der Programmieraufwand deutlich größer
gegenüber der DOM-API. 10 Da es sich bei den übertragenen Simulationsergebnissen
um kleine XML-Dokumente handelt, wurde sich dazu entschieden, einen XML-Parser
zu verwenden, der die DOM-API nutzt.
Die XML-Parser unterscheiden sich zusätzlich im Umfang ihrer Funktionalität. So
werden beispielsweise Namensräume oder Dokumenttypdefinitionen nur von einigen
XML-Parsern unterstützt. Da diese Besonderheiten in dem entworfenen Datenformat
jedoch nicht vorkommen, wurde sich für die Verwendung des XML-Parsers TinyXML-
2 entschieden. Ebenfalls steht die Bibliothek unter der Zlib-Lizenz, was die
Verwendung im kommerziellen Bereich ermöglicht. 11 Ein weiterer Vorteil besteht
darin, dass die Bibliothek keine betriebssystemspezifischen Funktionen verwendet
und somit plattformübergreifend verwendet werden kann.
4.1.4 Konvertieren der Daten
Da die Transim Technology Corportaion ein eigenes Format zur Speicherung der
Simulationsdaten verwendet, müssen die Ergebnisse der Simulation in dieses
Format konvertiert werden. Bisher erfolgte dies nachdem die Simulation beendet
wurde und die Ausgabedatei erzeugt wurde. Um die Zwischenergebnisse dem
EngineFramework zur Verfügung zu stellen, müssen jedoch diese bereits beim
Eintreffen konvertiert werden und gespeichert werden. Ebenfalls müssen die Daten
dem Schematic zur Verfügung gestellt werden. In den folgenden Kapiteln wird näher
auf das Speichern der Daten eingegangen. Das Bereitstellen für das Schematic wird
in einem späteren Kapitel näher erläutert.
Aus Kapitel 3.1.4.2 geht hervor, dass für jeden Simulationsschritt ein XML-Dokument
übertragen wird. In diesem befinden sich neben den Ergebnissen (-Tags) auch
die zugehörigen Abhängigkeiten (-Tags). Eine Besonderheit tritt ein, wenn zu den
Ergebnissen mehrere Abhängigkeiten vorliegen. Darauf wird jedoch in einem
späteren Kapitel näher eingegangen. Für das Konvertieren der Daten ist hier zu
beachten, dass die erste übergebene Abhängigkeit den X-Wert des aktuellen
Simulationsschrittes enthält. In den Ergebnis-Tags befinden sich die entsprechenden
Y-Werte. Die Werte liegen zunächst als Zeichenkette vor und müssen in eine
Fließkommazahl (float) umgewandelt werden. Als Attribut befindet sich in den
Ergebnis-Tags der Name des entsprechenden Kurvenverlaufs (engl.: Waveform). Für
9 vgl. online “Document Object Model” auf Wikipedia.org (09.08.2013)
10 vgl. online “Simple API for XML” auf Wikipeida.org (09.08.2013)
11 vgl online “The zlib/libpng License (Zlib)” auf Opensource.org
Seite 24

Die QucsLiveEngine
jeden Kurvenverlauf wird eine Datei angelegt in die die Ergebnisse geschrieben
werden.
4.1.5 Erzeugen der Waveform Dateien
Das Speichern der Simulationsergebnisse in Dateien ist notwendig, um später auf
diese zugreifen zu können. Diese Dateien werden in einem Unterordner gespeichert
und müssen nach dem folgenden Schema gespeichert werden:
/[UserID]/Waveform/[SimID]_[JobHandle]_group0_c[i]
Die UserID stellt die Identifikationsnummer des Benutzers dar. Diese wird aus der
Webanwendung übergeben. Bei der SimID handelt es sich um eine Kennzeichnung
der Simulation. Diese wird beim Starten der Simulation der QucsLiveEngine
übergeben. Auf diese soll hier nicht weiter eingegangen werden. Das JobHandle ist
die bereits in Kapitel 2.2.2 angesprochene Identifikationsnummer der Simulation. Das
i stellt eine durchlaufende Ganzzahl dar. Diese dient der Identifikation der
unterschiedlichen Kurvenverläufe. Wie die Zuweisung dieser Nummer zu den
Kurvenverläufen erfolgt wird im nächsten Kapitel näher erläutert. Zu beachten ist,
dass die Dateien über keine Dateinamenserweiterung verfügt.
In den Waveform-Dateien werden die Werte byteweise hintereinander gespeichert.
Dazu müssen diese Werte zunächst von einer Fließkommazahl in ein vier Byte
großes Array des Types Byte umgewandelt werden. Bei dem Speichern ist darauf zu
achten, ob es sich bei dem Y-Wert um eine reelle oder komplexe Zahl handelt. Bei
einer komplexen Zahl erfolgt eine Trennung zwischen Real- und Imaginärteil. Beide
Anteile werden anschließend in der Datei gespeichert. Abbildung 7 zeigt dabei die
Reihenfolge in der die Zahlen zu speichern sind.
Start
Schreibe(XValue->Real())
YValue->Complex()
ja
Schreibe(XValue->Real())
nein
Schreibe(YValue->Real())
YValue->Complex()
ja
Schreibe(YValue->Real())
nein
Ende
Abbildung 7 Speichern der Ergebnisse in der Waveform-Datei
Seite 25

Die QucsLiveEngine
Ist der Y-Wert komplex, muss ebenfalls für den X-Wert ein komplexer Wert
gespeichert werden. Handelt es sich um eine reale Zahl ist der Imaginärteil als „0.0“
zu speichern.
4.1.6 Die Manifest Datei
Um eine Zuordnung der Waveform-Dateien zu den ursprünglichen Knotenpunkten zu
erhalten muss eine sogenannte Manifest-Datei angelegt werden. Dabei ist der
Dateiname wie folgt anzulegen:
/[UserID]/Waveform/[SimID]_[JobHandle]_group0.manifest
In diese Datei werden die Zuordnungen zeilen weise eingetragen. Eine Zuordnung
muss nach dem folgenden Format angelegt werden:
[Name],[Dateiname],[X-Typ],[Y-Typ],1,[Komplex]
Der Name steht dabei für den Namen des Kurvenverlaufes. Dieser kann
beispielsweise eine Ausgangsspannung, ein Eingangsstrom, oder ein beliebiger in
der Schaltung angegebener Abtastpunkt (engl.: Probe) sein. Der Dateiname steht für
die erzeugte Waveform-Datei und muss dem in Kapitel 4.1.5 erläuterten Format
entsprechen. Anschließend folgen die Bezeichnungen für den physikalischen Typ der
X- und Y-Achse. Eine Auswahl der möglichen Bezeichnungen findet sich in Tabelle
2. Die vollständige Liste der Bezeichnungen befindet sich in Anhang 8.
# Bezeichnungen
3 amp current
4 second time
… …
Tabelle 2 Format der Achsbezeichung in der Manifest-Datei
Dabei kann in der Manifest-Datei entweder die Bezeichnung oder die zugehörige
Zahl aufgeführt werden. Um einen Typ zuordnen zu können, muss eine Angabe zu
diesem bereits von dem Simulator übertragen werden. Zuletzt muss angegeben
werden, ob es sich bei den gespeicherten Werten um reelle, oder komplexe Zahlen
handelt. Sind die Zahlen reell, wird der Wert 1 eingetragen, sind sie komplex, der
Wert 2.
4.1.7 Speichern von Kurvenscharen
Eine gesonderte Rolle spielen Simulationen, bei denen die Ergebnisse mehrere
Abhängigkeiten besitzen. Dieser Fall tritt ein, wenn für gewisse Bauteile ein
Parameterdurchlauf ausgeführt wird. Das bedeutet, dass einem Bauteil ein
Parameter zugewiesen wird. Dieser ist mit einem Start- und Endwert, sowie der
Anzahl an Schritten definiert. Die Simulation muss für jeden dieser Parameter
ausgeführt werden. Für die Ergebnisse bedeutet dies, das nicht ein Kurvenverlauf
entsteht, sondern eine Kurvenschar. In diesem Fall muss jede Kurve in einer
separaten Waveform-Datei gespeichert werden. Die Benennung dieser Datei erfolgt
Seite 26

Die QucsLiveEngine
zunächst wie in 4.1.5 angegeben, jedoch wird dem Dateinamen zusätzlich folgende
Zeichenkette angehängt:
/[UserID]/Waveform/[SimID]_[JobHandle]_group0_c[i]_div[j]
Der Parameter j ist dabei ein fortlaufender Zähler der für die Kurve in der
Kurvenschar steht. Die Manifest-Datei muss ebenfalls angepasst werden, um eine
Zuordnung der einzelnen Kurven zu den Parametern zu ermöglichen. Das Format
der Daten bleibt wie in 4.1.6 bestehen, jedoch muss in der ersten Zeile ein Hinweis
angegeben werden, dass für einen Knotenpunkt mehrere Kurven vorliegen. Dieser
Hinweis muss nach dem folgenden Format aufgebaut sein:
# Division Labels (comma separated) : [Name Div1],[Name Div2], ...
Die Namen für die unterteilten Kurven kann dabei beliebig erfolgen, es bietet sich
jedoch an, einen Verweis auf die zugehörige Abhängigkeit anzugeben. Die Anzahl
der Namen muss mit der Anzahl der einzelnen Kurven (s.o. j) übereinstimmen. Da
die Namen durch Kommata getrennt werden, dürfen die Namen selbst keine
Kommata enthalten. Neben der Manifest-Datei muss ebenfalls eine Division-Datei
angelegt werden. Dieser ähnelt der Manifest-Datei. In der ersten Zeile befindet sich
die Angabe zu den Kurvenscharen. Diese kann aus der Manifest-Datei übernommen
werden. Die Angabe zu den Waveform-Dateien erfolgt anschließend wie folgt:
[Name],[Dateiname],0
Zur besseren Verdeutlichung befindet sich in Anhang 9 ein umfangreiches Beispiel.
Hier handelt es sich um eine Transientsimulation des Tiefpass-Filters. Neben dieser
Simulation wurde zusätzlich ein Parameterdurchlauf mit vier Schritten für den
Wiederstand hinzugefügt. In der Ausgabe sind neben der Eingangsspannung die vier
Ausgangsspannungen zu erkennen. In dem übertragenen Zwischenergebnis finden
sich neben den Ergebnissen Ue.It, Ue.Vt und Ua.Vt auch deren Abhängigkeiten
wieder. Dabei steht time.s für den aktuellen Zeitwert der Transientsimulation und R1
für den aktuellen Widerstandswert des Parameterdurchlaufs. In den erzeugten
Waveform-Dateien sind die drei Ergebnisse mit jeweils vier unterschiedlichen Kurven
zu erkennen. Schließlich findet sich die Zuordnung der Waveform-Dateien in der
Manifest-Datei wieder.
4.2 Implementierung
4.2.1 Starten des TCP-Servers und der Simulationsanwendung
Für die Implementierung der Netzwerkkommunikation wird in der QucsLiveEngine
die winsock2-Bibiliothek verwendet. Zum Starten eines TCP-Servers wird ein SOCKET-
Objekt benötigt. Diesem wird ebenfalls als Adressfamilie „Internetadresse“
zugewiesen. Als IP-Adresse wird für einen Server die Konstante INADDR_ANY
zugewiesen. Anschließend muss der Server an einen Port gebunden werden. Ist
Seite 27

Die QucsLiveEngine
dieser Port bereits an eine andere Anwendung gebunden, wird versucht sich an den
nächsten Port zu binden. Listing 4 zeigt die Implementierung zur Auswahl des Ports.
// Get the minimum and maximum value for the Port
int minPort, maxPort;
if(!GetPort(&minPort, &maxPort))
return false;
// Find Free Port to bind on:
int port = minPort-1;
do {
port++;
local.sin_port=htons((u_short)port);
} while(port maxPort)
return false;
Listing 4 Auswahl des Ports für den TCP-Server
Die Funktion GetPort() liest aus der Registrierungsdatenbank einen Bereich in dem
der Port liegen darf. Anschließend wird versucht den Server an den Port zu binden.
Schlägt diese Funktion fehl, wird der Port um eins inkrementiert und es wird erneut
versucht. Überschreitet die port-Variable den maximal zulässigen Wert, wird die
Simulation abgebrochen. War die Bindung an einen Port erfolgreich, kann der Server
gestartet werden. Wie bereits in Kapitel 4.1.2 erläutert, muss dieser in einem
zusätzlichen Thread erzeugt werden. Für eine bessere Übersicht wurde dies in einer
zusätzlichen Klasse implementiert. Zum Starten des neuen Threads wird die
Funktion AfxBeginThread() verwendet. Diese wird durch das .NET-Framework
bereitgestellt. Als Ergebnis liefert diese einen Zeiger auf ein Objekt vom Typ
CWinThread. Ist der Thread gestartet, wird der Server in den Listen-Modus gesetzt
und wartet auf eine eingehende Verbindung.
Nach dem Start des neuen Threads wird in dem ursprünglichen Thread die
Anwendung Qucs gestartet. Dies erfolgt wie bisher, jedoch wird ihr als zusätzlichen
Startparameter die Adresse, sowie der Port des TCP-Servers übergeben. Da die
Anwendung und der TCP-Server auf der gleichen Maschine ausgeführt werden, ist
die IP-Adresse die 127.0.0.1. Als Port wird der ermittelte Port übergeben.
4.2.2 Empfangen der Daten
Wurde die Verbindung zwischen Client und Server hergestellt, können die Daten
übertragen werden. Um Daten entgegen zu nehmen, muss im Server die Funktion
recv(...) aufgerufen werden. Diese Funktion blockiert den Programmablauf, bis
Daten eingehen. Als Parameter müssen ihr, die Client-ID, ein Zeiger auf einen
Puffer, die Größe des Puffers übergeben werden. Die Größe des Puffers wurde hier
anhand der Eigenschaften von TCP bestimmt. Diese sind die dem Request for
Comments (RFC) 793 aufgeführt. 12 Einen Teil des TCP-Headers stellt das Window-
12 vgl. RFC 793
Seite 28

Die QucsLiveEngine
Feld dar. Dieses Feld gibt an, wie viele Daten vom Server empfangen werden
können, bevor dieser eine Bestätigung (Acknowledgement) an den Client senden
muss. Bei einem kleinen Wert muss demzufolge der Client oft auf die Bestätigung
des Servers warten. Somit würde das gesamte System verlangsamt. Wird ein hoher
Wert gewählt, müssen weniger Bestätigungen geschickt werden, und eine schnellere
Übertragung ist gewährleistet. Der Nachteil eines großen Wertes tritt ein, wenn es zu
einer fehlerhaften Übertragung kommt. In diesem Fall müssen alle Daten, die nicht
bestätigt wurden, erneut gesendet werden. Bei störanfälligen Netzwerken würde sich
ein großer Wert negativ auf die Geschwindigkeit auswirken. Da sich der Client und
der Server hier jedoch auf der gleichen Maschine befinden können fehlerhafte
Übertragungen nahezu ausgeschlossen werden. Somit kann ein hoher Wert gewählt
werden. Im TCP-Header sind 16 Bit für den Window-Wert vorgesehen. Dies
entspricht einer maximalen Größe von 65.535 Byte, was ebenfalls als Größe für den
Puffer gewählt wird.
Die recv()-Funktion liefert als Rückgabewert die Anzahl der empfangen Daten. Wird
die Verbindung zum Client beendet liefert sie den Wert 0. Werden mehr Daten
gesendet als in den übergeben Puffer geschrieben werden, muss die recv()-
Funktion erneut aufgerufen werden um die nächsten Daten zu empfangen. Daraus
resultierend wurde eine Schleife entwickelt, die abgebrochen wird, wenn die
Verbindung beendet wurde.
4.2.3 Auslesen des TCP-Stroms
Zum Übertragen der Simulationsergebnisse werden diese in einem XML-Dokument
gespeichert. Wurden die Daten auf dem Server empfangen befinden sie sich in dem
bereits erwähnten Puffer. Bei schnellen Simulationen ist es aufgrund des großgewählten
Puffers möglich, dass mehrere Datensätze in den Puffer geschrieben
werden. Mithilfe der TinyXML-2-Bibliothek kann eine Zeichenkette zu einem XML-
Objekt geparst werden. Dazu darf in der Zeichenkette jedoch nur ein XML-Dokument
aufgeführt sein. Aus diesem Grund müssen die Datensätze aus dem Puffer zunächst
getrennt werden. Jedes XML-Dokument beginnt mit der XML-Deklaration und
beginnt demzufolge mit der Zeichenkette „

Die QucsLiveEngine
// position-variable required to split the received string.
int pos1=0, pos2 = 0, size;
char* pch;
pch = strchr(data, '?');
while (pch != NULL) {
if(*(pch-1)=='

Die QucsLiveEngine
Dabei muss eine Zuordnung der Ergebnisse zu den Dateien erfolgen. In 4.1.5 wurde
erläutert, dass sich die Dateien in dem c-Wert unterscheiden. Es wurde eine Klasse
zur Verwaltung der Ergebnisnamen und den c-Werten entwickelt. Sie bietet eine
Funktion, der der Name des Ergebnisses und eine Referenz auf eine Zeichenkette
übergeben werden. In der Zeichenkette wird der zum Namen zugehörige c-Wert
zurückgegeben. Die Funktion überprüft, ob bereits eine Zuordnung vorhanden ist.
Falls nicht wird eine neue hinzugefügt. Dabei werden diese fortlaufend
durchnummeriert. Wurde ein neuer Eintrag hinzugefügt, wird von der Funktion ein
true zurückgegeben. War die Zuordnung bereits vorhanden ein false. Dieser
Rückgabewert wird gespeichert und gibt später an, ob eine neue Manifest-Datei
erzeugt werden muss. Ist der c-Wert bekannt, kann das Ergebnis in der Waveform-
Datei gespeichert werden. Dies erfolgt wie in der bisherigen QucsEngine.
Wie in 4.1.7 erläutert, muss eine Unterscheidung bei Kurvenscharen erfolgen. Diese
treten auf, wenn in dem vector mehr als ein Eintrag vorhanden ist. In diesem Fall
erfolgt eine Zuordnung der zusätzlichen Abhängigkeiten zu dem entsprechenden
div-Wert. Diese Zuordnung erfolgt ähnlich wie die Zuordnung der Ergebnisse zu den
c-Werten der Waveform-Dateien. Wird eine neue Zuordnung angelegt, muss
ebenfalls eine neue Manifest-Datei, sowie eine Division-Datei erzeugt werden.
Wurden alle Ergebnisse in die Waveform-Dateien geschrieben muss geprüft werden,
ob eine neue Manifest- und Divison-Datei erstellt werden müssen. Sind div-
Zuordnungen vorhanden muss die erste Zeile der Manifest- und Division-Datei
erzeugt werden. Anschließend werden die c-Zuordnungen durchlaufen und die
entsprechenden Einträge in der Manifest- und Division-Datei gesetzt. Das neue
Erstellen der Dateien ist notwendig, damit WebScope Zugriff auf die neu erstellen
Waveform-Dateien erhält.
Seite 31

Der EngineServer
5 Der EngineServer
5.1 Vorbetrachtungen
5.1.1 Das Postprocessing
Um die gespeicherten Simulationsdaten weiter verwenden zu können muss eine
Nachbearbeitung (engl.: Postprocessing) stattfinden. Das Postprocessing wird dabei
stets auf dem EngineServer ausgeführt. Es sorgt dabei für die Umwandlung der
Simulationsergebnisse in eine verständliche Darstellung. Dazu zählt unter anderem
die Darstellung der Kurvenverläufe in unterschiedlichen Diagrammen. Neben den
Möglichkeiten Bild-Dateien zu erzeugen ist das Postprocessing ebenfalls dafür
zuständig die Daten für die spätere Ausgabe in dem Webbrowser vorzubereiten.
Dem Postprocessing können dazu unterschiedliche Befehle, sogenannte
PostProcessingCommands, übergeben werden.
Für die Darstellung von Kurvenverläufen bedeutet dies zunächst, dass ein
entsprechendes Diagramm erzeugt wird. Es können unterschiedliche Arten von
Diagrammen erzeugt werden, jedoch soll in dieser Arbeit lediglich auf das Erstellen
von kartesischen Diagrammen eingegangen werden. Diese bestehen aus einer X-
Achse und einer oder mehreren Y-Achsen. Der X-Achse wird der sich ändernde Wert
zugewiesen. Für eine Transientsimulation wäre die beispielsweise die Zeit, bei einer
Wechselstrom-Simulation die Frequenz. Auf der/den Y-Achse/n werden die
Ergebnisse zugeordnet. Um solch eine Beschreibung, die später von WebScope
interpretiert werden kann, zu erzeugen wird das bereits existierende Unterprogramm
„FlashGen“ verwendet. Dieses Unterprogramm entstand, als die
Simulationsergebnisse in dem Browser noch über den Adobe Flash Player
ausgegeben wurde. Dafür musste der entsprechende Flash Player auf dem PC des
Nutzers installiert sein. Um eine Unabhängigkeit von zusätzlicher Software zu
erreichen hat die Transim Technology die Ausgabe der Daten über HTML und
JavaScript realisiert. Dies wird von jedem Browser unterstützt und benötigt keine
Installation von zusätzlicher Software. Der Name FlashGen stellt daher lediglich ein
historisches Zeichen dar. Die Aufgabe von FlashGen besteht darin, die Beschreibung
von allen benötigten Diagrammen zu erzeugen. Dazu müssen diesem mehrere
Befehle, die sogenannten PostProcessingCommands, übergeben werden. In Listing
6 ist ein Beispiel für diese Kommandos aufgeführt.
oFlashGen = CreateInstance("FlashGen")
oFlashGen.AddGroup(Name="Voltage", XMax="5E-4")
oFlashGen.AddWaveform(Name="Ue.Vt", Group="Voltage", DisplayName="Ua.Vt",
Color="#FF0000", Enabled="true", YType="Voltage",
YMin="-1.1", YMax="1.1")
oFlashGen.AddWaveform(Name="Ua.Vt", Group="Voltage", ...)
oFlashGen.CreateFlashManifest()
Listing 6 Beispiel für die PostProcessingCommands
Seite 32

Der EngineServer
Es muss zuerst eine Instanz von FlashGen erzeugt werden. Danach folgen die
Definitionen für die Ergebnisgruppen. Hier wird eine Gruppe für die Ausgabe der
Spannungen erstellt. Bisher wurden die Grenzen für die X-Achse aus den
vorhandenen Waveform-Dateien ermittelt. Diese werden jetzt zur Laufzeit mit neuen
Werten gefüllt. Wird ein neuer Wert in die Dateien eingetragen müsste FlashGen neu
gestartet werden, um die neuen Grenzen zu ermitteln. Um dies zu verhindern wurde
der Funktion AddGroup() ein neuer Parameter hinzugefügt um den Maximalwert für
die X-Achse setzen zu können. 14 Nach Erstellen der Gruppen können diesen mit der
Funktion AddWaveForm() Kurvenverläufe hinzugefügt werden. Der Name muss dabei
dem Namen in der Manifest-Datei entsprechen. Neben dem Namen kann der Kurve
ein Anzeigename, eine Farbe, sowie weitere Eigenschaften zugewiesen werden.
Über den Befehl CreateFlashManifest() wird schließlich von FlashGen eine XML-
Datei erzeugt, in der sich die Beschreibung aller benötigten Dateien befindet. Diese
Datei wird unter dem folgenden Namen gespeichert:
[SimID]_[JobHandle]_JS_VIEWER.xml
In Listing 7 ist ein Beispiel für eine solche Datei aufgeführt. Zur besseren Übersicht
wurden hier einige Attribute aus den Knoten entfernt.
Listing 7 Von FlashGen erzeugte Datei zur Berschreibung der Diagramme
In dem XML-Dokument befindet sich der Wurzelknoten . Dieser kann
mehrere -Knoten beinhalten. Diese Knoten stehen jeweils für ein
Diagramm. Innerhalb dieser Knoten befindet sich in den -Knoten die
Beschreibung der jeweiligen Achsen. Zu erkennen sind die Attribute die die
Maximum- und Minimumwerte der Achsen angeben. Es können ebenfalls mehrere
Definitionen für Y-Achsen vorhanden sein. Dies wird benötigt, wenn mehrere Kurven
unterschiedlichen Typs, oder mit unterschiedlicher Achseinteilung in einem
14 Anm.: Die Änderungen an FlashGen wurden von einem Mitarbeiter der Transim Technology
durchgeführt.
Seite 33

Der EngineServer
Diagramm dargestellt werden sollen. In den -Knoten befindet sich die
Beschreibung der Kurvenverläufe. Als Attribut dieses Knotens werden der Name, die
zu verwendende Farbe, sowie die Information ob die Kurve angezeigt werden soll
angegeben. In dem Attribut locator befindet sich ein Uniform Resource Locator (URL)
der auf die zugehörige Waveform-Datei verweist. In den -Knoten befinden
sich schließlich die -Knoten, in denen die kurvenspezifischen Achsen definiert
sind. Über die Attribute sind hier ebenfalls der Name sowie die Maximum- und
Minimumwerte angegeben. Die Zuordnung zu der Achsengruppe erfolgt über das
Attribut type.
Im bisherigen Verlauf des Simulationsvorganges wurde das Postprocessing
gestartet, nachdem die Simulationsanwendung beendet wurde und alle Waveform-
Dateien, sowie die Manifest-Datei erzeugt wurden. Für den Start von WebScope wird
jedoch die von FlashGen erzeugte XML-Datei benötigt. Diese muss demzufolge
ebenfalls zur Laufzeit der Simulation erstellt werden. Die Minimum- und Maximum-
Werte können FlashGen über die PostprocessingCommands übermittelt werden. Es
muss daher nicht auf alle Simulationsergebnisse gewartet werden. Das Erzeugen der
XML-Datei setzt die Manifest-Datei voraus. Kommt es zu einer Änderung an der
Manifest-Datei, beispielsweise bei einer Simulation mit einem Parameterdurchlauf,
muss eine neue XML-Datei erzeugt werden. Zusammenfassend bedeutet dies, dass
FlashGen nach dem Erzeugen, sowie nach jeder Änderung der Manifest-Datei
ausgeführt werden muss.
5.1.2 Bereitstellen der Simulationsdaten
Ist die Simulation abgeschlossen, kann WebScope auf die Ergebnisse zugreifen.
Wird in WebScope in die erzeugten Diagramme herein- oder aus ihnen
herausgezoomt, werden die Simulationsdaten erneut vom EngineServer abgefragt.
Somit wäre ein erneuter Zugriff auf die Waveform-Dateien nötig. Es müssten die
Werte ebenso aus der Byte-Darstellung in ein Ganzzahlen-Objekt konvertiert
werden. Aus diesem Grund werden die Simulationsergebnisse nur bei der ersten
Anfrage ausgelesen und konvertiert. Anschließend werden die Ergebnisse im
Arbeitsspeicher in einem Zwischenspeicher, folgend Map genannt, hinterlegt. Es wird
dadurch ein Geschwindigkeitsvorteil erreicht, da zum Einen die Ergebnisse nicht
erneut konvertiert werden müssen, und zum Anderen die Zugriffzeiten auf den
Arbeitsspeicher, im Vergleich zu Festplatten, deutlich niedriger sind.
Für die Darstellung der Simulationsergebnisse zur Laufzeit ergibt sich hier das
Problem, dass neue Ergebnisse nicht angezeigt werden, da diese zwar in die
Waveform-Dateien geschrieben werden, der EngineServer für die Darstellung jedoch
die Werte aus dem Arbeitsspeicher verwendet. Die Ergebnisse müssen demzufolge
sowohl in den Waveform-Dateien auf der Festplatte, als auch in der Map im
Arbeitsspeicher gespeichert werden.
Seite 34

Der EngineServer
5.2 Implementierung
5.2.1 Anpassen der QucsLiveEngine
In Kapitel 4 wurde bereits auf die Entwicklung der QucsLiveEngine eingegangen. In
dieser werden die Simulationsdaten von der Anwendung Qucs entgegen genommen
und in die Waveform-Dateien geschrieben. Nach einem Zugriff auf die
Simulationsdaten über den EngineServer müssen die Simulationsergebnisse
ebenfalls in den, in Kapitel 5.1.2 beschriebenen, Zwischenspeicher geschrieben
werden. Dazu ist eine Kommunikation zwischen EngineServer und der
QucsLiveEngine erforderlich. In der bereits bestehenden generischen Klasse, von
der alle Engines erben, sind bereits Rückruffunktionen definiert, die der Engine eine
Kommunikation zum EngineServer ermöglicht. Um die Simulationsdaten zur
Verfügung zu stellen, wird hier eine zusätzliche Rückruffunktion definiert. In Listing 8
sind die Änderungen an der generischen Klasse aufgeführt.
/* ALRESULT - AddLiveResult */
PROC_ALRESULT_CALLBACK g_pfnALResultCallBack = NULL;
/* ... */
extern "C" __declspec( dllexport )
void SetALResultCallBack(PROC_ALRESULT_CALLBACK pfnCallBack ) {
g_pfnALResultCallBack = pfnCallBack;
}
/* ... */
bool CGenericEngine::CallALResultCallback(const char* WFFilename,
float XData, float YData, float XDataImag,
float YDataImag, bool IsComplex) {
if ( g_pfnALResultCallBack == NULL)
return false;
g_pfnALResultCallBack(WFFilename, XData, YData, XDataImag, YDataImag,
IsComplex);
return true;
}
Listing 8 Änderungen an der generischen Klasse
Die Funktion SetALResultCallBack() wird als extern definiert, damit der
EngineServer diese nutzen kann. Über diese Funktion registriert sich der
EngineServer für den Rückruf. Damit der EngineServer die Daten verarbeiten kann,
muss hier ein Zeiger auf eine Funktion übergeben werden. Die Funktion
CallALResultCallback() wird von der QucsLiveEngine benötigt. Wurde ein neues
Zwischenergebnis berechnet, muss diese Funktion aufgerufen werden. In dieser wird
geprüft, ob eine Rückruffunktion definiert wurde. Ist dies der Fall wird diese
ausgeführt. Da die Definition der Funktion in einem anderen Programm erfolgt, ist
diese dem Compiler hier nicht bekannt. Es muss daher auf die korrekte
Parameterliste geachtet werden. Die Parameter bestehen hier aus dem Dateinamen
der zugehörigen Waveform-Datei, die aktuellen X- und Y-Werte, inklusive reeller und
imaginärer Anteil, sowie die Angabe, ob es sich um komplexe Werte handelt.
Seite 35

Der EngineServer
Um den Rückruf in der QucsLiveEngine auszuführen, muss in dieser noch der
entsprechende Aufruf eingebunden werden. In Listing 9 ist der entsprechende
Funktionsaufruf aufgeführt.
CallALResultCallback(waveFormFilename,
curIndep.getValue()->getReal(), numb->getReal(),
curIndep.getValue()->getImag(), numb->getImag(),
numb->isComplex()
);
Listing 9 Aufruf der Rückruffunktion in der QucsLiveEngine
Der Aufruf der Funktion erfolgt dabei an der Stelle im Programmablauf, an der die
Ergebnisse in die Waveform-Datei geschrieben werden.
5.2.2 Speichern der Daten im Zwischenspeicher des EngineServers
Nachdem die Daten von der QucsLiveEngine bereitgestellt werden muss der
EngineServer modifiziert werden, um die Simulationsdaten gegebenenfalls in den
Zwischenspeicher zu schreiben. In Listing 10 sind die Änderungen an der
EngineServer-Klasse aufgeführt.
// EngineServerWSClass.h:
public delegate void ALResultCallBackDel(const char* WFFilename,
float XData, float YData, float XDataImag,
float YDataImag, bool IsComplex);
namespace EngineServerWS {
/* ... */
private:
static ALResultCallBackDel ^c_ALResultDelegate;
void ALResultCallBack(const char* WFFilename, float XData,
float YData, float XDataImag, float YDataImag, bool IsComplex);
/* ... */
}
// EngineServerWSClass.cpp:
[DllImportAttribute("GenericEngine.dll", CharSet=CharSet::Ansi)]
extern "C" void SetALResultCallBack(ALResultCallBackDel ^d);
Int32 EngineServerWSClass::Start() {
/* ... */
c_ALResultDelegate = gcnew ALResultCallBackDel(this,
&EngineServerWSClass::ALResultCallBack);
SetALResultCallBack( c_ALResultDelegate );
/* ... */
}
Int32 EngineServerWSClass::StopServer() {
/* ... */
c_ALResultDelegate = nullptr;
/* ... */
}
void EngineServerWSClass::ALResultCallBack(const char* WFFilename,
float XData, float YData, float XDataImag,
float YDataImag, bool IsComplex) {
/* ... */
}
Listing 10 Änderungen an der EngineServer-Klasse
Seite 36

Der EngineServer
In der Header-Datei der Klasse befinden sich neue Deklarationen. Es wird ein
Methodenzeiger (engl.: delegate) deklariert. Anschließend wird eine globale Variable
von dem neuen Typ, sowie ein Funktionskopf deklariert.
In der Quelltext-Datei muss zunächst der Verweis auf die Rückruffunktion der
generischen Klasse angegeben werden. Wird der EngineServer gestartet wird ein
neuer Methodenzeiger angelegt, der auf die Funktion ALResultCallBack() verweist.
Anschließend wird diese der Rückruffunktion der generischen Klasse zugewiesen.
Wird eine von der generischen Klasse abgeleitete Engine gestartet, kann in dieser
nun die Rückruffunktion aufgerufen werden. Anschließend wird die
ALResultCallBack()-Funktion im EngineServer aufgerufen. Somit ist die
Kommunikation zwischen dem EngineServer und der Engine hergestellt. Wird der
Server gestoppt, wird der Methodenzeiger zurückgesetzt.
Der Zwischenspeicher wird bei der ersten Anfrage der Simulationsergebnisse
angelegt. Die Daten werden in der Struktur WFData hinterlegt, die aus vier Feldern
vom Typ float besteht. In der Funktion ALResultCallBack() müssen die
Simulationsdaten in den Zwischenspeicher geschrieben werden. In Anhang 10
befindet sich die Struktur- sowie die Funktionsdefinition. Bei dem Erstellen des
Zwischenspeichers werden die Felder, in denen die Werte gespeichert werden,
angelegt. Dies bedeutet, dass die Größe der Felder auf die Anzahl, der zu diesem
Zeitpunkt, vorhandenen Ergebnisse gesetzt wird. Durch die Echtzeitkommunikation
werden jedoch neue Werte empfangen, die in den Zwischenspeicher geschrieben
werden müssen. Da ein Feld nicht beliebig erweitert werden kann, wurde eine neue
Struktur WFLiveData entworfen. Diese ähnelt der WFData, jedoch werden hier die
Daten in Listen gespeichert. Diese können beliebig erweitert werden. Das Erstellen
des Zwischenspeichers musste an die neue Struktur angepasst werden. Die
Änderungen zum Lesen der Daten wird in Kapitel 6 näher erläutert. Das Speichern
der Simulationsergebnisse in den Zwischenspeicher ist in Anhang 10 aufgeführt.
Zunächst muss in allen vorhandenen Simulationen die aktuell benötigte gesucht
werden. Diese hat den Typ ESJobObject. In dieser ist eine Hashtable aller
vorhandenen Waveform-Daten enthalten. In den entsprechenden Eintrag der
Hashtable werden schließlich die neuen Simulationsergebnisse hinzugefügt.
5.2.3 Starten des Postprocessing
Wie in Kapitel 5.1.1 erläutert, muss nach einer Änderung an der Manifest-Datei das
Postprocessing gestartet werden. Im bisherigen Ablauf wird das Postprocessing
einmalig nach Abschluss der Simulations ausgeführt. Dazu ist in der generischen
Klasse eine Rückruffunktion definiert. Ist die Simulation beendet wird diese von der
Engine aufgerufen. Anschließend wird auf dem EngineServer das Postprocessing
ausgeführt. In der QucsLiveEngine muss nun der Funktionsaufruf lediglich nach dem
Erstellen der Manifest-Datei erfolgen.
Seite 37

Anzeige der Simulationsergebnisse in WebScope
6 Anzeige der Simulationsergebnisse in WebScope
6.1 Vorbetrachtung
6.1.1 Anfrage der Simulationsdaten
Die Ausgabe der Simulationsergebnisse in WebScope muss in zwei Bereiche
unterteilt werden. Zum einen müssen die Ergebnisse zur Laufzeit dargestellt werden.
Darauf wird im folgenden Kapitel näher eingegangen. Zum anderen können beim
Laden von WebScope bereits Simulationsergebnisse vorliegen. Diese vorhandenen
Ergebnisse müssen separat geladen werden. Eine direkte Darstellung der
Simulationsdaten im Webbrowser ist nicht möglich. Stattdessen muss die Größe des
Ausgabebereiches an den Webserver übergeben werden. Dieser leitet, über einen
Proxy, die Werte an den EngineServer weiter. Hier werden anhand der
Simulationsergebnisse die darzustellenden Punkte berechnet. Der Grund für diese
Darstellung liegt in der Anzahl der Simulationsergebnisse. Würde die Berechnung
der Darstellung im Webbrowser erfolgen müssen alle Simulationsergebnisse an
diesen übertragen werden. Bei Simulationen mit einer großen Anzahl an
Ergebnissen würde dies zu einem erheblichen Datentransfer führen. Durch die
Berechnung, der auszugebenden Punkte, im EngineServer bleibt die Größe der zum
Browser zu übertragenden Daten konstant. Dies bedeutet jedoch, dass beim hereinund
herauszoomen in Webscope die Daten erneut vom Server geladen werden
müssen. Ebenfalls führt ein verschieben des angezeigten Bereiches zu einem
Neuladen der Daten. Für die Anfrage muss daher neben der Größe des
Ausgabebereiches auch die Skalierung der X- und Y-Achsen übergeben werden.
In Kapitel 5 wurde bereits erläutert, dass die Simulationsergebnisse auf dem
EngineServer nach der ersten Anfrage zwischengespeichert werden. Um die
Simulationsergebnisse zur Laufzeit in den Zwischenspeicher schreiben zu können,
musste dieser vom Aufbau her modifiziert werden. Werden über den Webserver
neue Daten angefordert, wird auf den Zwischenspeicher lesend zugegriffen.
Dementsprechend muss die Funktion zum Auslesen der Daten an den neuen Aufbau
angepasst werden.
6.1.2 Ausgabe der Simulationsdaten zu Laufzeit
6.1.2.1 Allgemein
Die Anzeige der Simulationsergebnisse erfolgt bei dem Endnutzer im Webbrowser
über ein HTML-Dokument (Hypertext Markup Language). Bei HTML handelt es sich
um eine textbasierte Auszeichnungssprache. Sie dient der Strukturierung von
Bildern, Text und anderen Elementen in einem Dokument. HTML trägt aktuell die
Versionsnummer 4.01, wobei an HTML5 entwickelt wird, und dies bereits von vielen
Seite 38

Anzeige der Simulationsergebnisse in WebScope
Layout-Engines unterstütz wird. 15 HTML bietet keine Möglichkeit zur Darstellung von
dynamischen Elementen. Um dies zu erreichen müssen zusätzliche Techniken
verwendet werden. Hier hat sich die Skriptsprache JavaScript etabliert. Sie wird von
allen gängigen Webbrowser unterstützt. Es existieren viele JavaScript-Bibliotheken
die das Erstellen von dynamischen Inhalten auf Webseiten vereinfachen. Als
Konzept für die asynchrone Datenübertragung hat sich Ajax (Asynchronous
JavaScript and XML) in der Webentwicklung durchgesetzt 16 und soll auch hier für die
Übertragung der Simulationsergebnisse genutzt werden. Zur Darstellung von
Echtzeitdaten auf einer Webseite haben sich unterschiedliche Methoden entwickelt.
Im Folgenden wird auf einige dieser Methoden näher eingegangen.
6.1.2.2 Erneutes Abfragen aller Ergebnisse (Polling)
Eine Möglichkeit, Daten von einem Webserver abzufragen, besteht darin, in einem
bestimmten Zeitabstand sämtliche Daten erneut vom Server abzufragen. In der
Antwort befinden sich die alten, sowie die neuen Daten. Dieses Verfahren wird
Polling genannt. Der Vorteil besteht in einer einfachen Implementierung. Jedoch
kommt es so zu einem hohen Datenverkehr, da die alten Daten jedes Mal neu
übertragen werden. Um zu verhindern, dass der EngineServer stets die neuen
Ausgabedaten berechnet, kann hier ein Puffer eingerichtet werden, in dem die
Ausgabedaten hinterlegt werden. Bei Eintreffen neuer Simulationsergebnisse
müssten diese sowohl in den Zwischenspeicher als auch in den Puffer übernommen
werden.
6.1.2.3 Abfragen nach neuen Ergebnissen (Long Polling)
Eine Abwandlung des in Kapitel 6.1.2.2 beschriebenen Verfahrens stellt das
sogenannte Long Polling dar. Hier werden nicht alle Daten vom Webserver
angefragt. Stattdessen wird eine Anfrage gesendet, ob neue Daten vorliegen. Liegen
diese nicht vor, wird die Anfrage zunächst nicht beantwrotet. Gehen neue Ergebnisse
ein, kann die Anfrage bestätigt werden. Da lediglich neue Daten übertragen werden,
wird hier der Datenverkehr im Vergleich zum herkömmlichen Polling stark reduziert.
Hier ist jedoch ein höherer Implementierungsaufwand nötig. So muss eine
Differenzierung erfolgen, welche Daten auf dem Server als neu, und welche als alt
eingestuft werden. Des Weiteren geschieht das Abfragen der Ergebnisse über eine
HTTP-Anfrage. Erhält diese nach einer gewissen Zeitüberschreitung (engl. timeout)
keine Antwort wird eine Ausnahme geworfen, die entsprechend behandelt werden
muss.
15 vgl. online: Hypertext Markup Language auf Wikipedia.org (22.08.2013)
16 vgl. online: Ajax (Programmierung) auf Wikipedia.org (22.08.2013)
Seite 39

Anzeige der Simulationsergebnisse in WebScope
6.1.2.4 Websocket-Protokoll
Bei dem Websocket-Protokoll handelt es sich um ein Netzwerkprotokoll, das auf TCP
basiert. Mit diesem kann eine bidirektionale Verbindung zwischen einem Webserver
und einer Webanwendung hergestellt werden. Durch das Herstellen einer
Verbindung kann der Server aktiv Daten an den Client schicken, und muss nicht, wie
bei einer HTTP-Verbindung, auf eine Anfrage des Clients warten. Ebenfalls entfallen
bei WebSockets zusätzliche Daten, die durch den HTTP-Header verursacht
werden. 17 Der Nachteil dieser Methode besteht jedoch darin, dass sowohl Browser
als auch Webserver das WebSocket-Protokoll unterstützen müssen. Die Transim
Technology Corporation verwendet als WebServer die Internet Information Services
(IIS) von Microsoft in den Versionen bis 7.5. Das WebSocket-Protokoll wird jedoch
erst ab der IIS-Version 8.0 unterstützt. Ältere Versionen des IIS können durch die
Integration von beispielsweise Node.js erweitert werden, wodurch das WebSocket-
Protokoll genutzt werden kann. Das WebSocket-Protokoll wird ebenfalls nur von
neuen Webbrowsern unterstützt. Da die Webanwendungen der Transim Technology
Corporation jedoch auch auf älteren Webbrowser ausgeführt werden soll, müssen
hier zusätzliche JavaScript-Bibliotheken eingebunden werden, damit das Protokoll
verwendet werden kann.
6.1.2.5 Senden der Ergebnisse vom Webserver
Neben den bisher genannten, besteht die Möglichkeit, Daten vom Webserver direkt
an den Webbrowser zu senden. Diese Technik ist unter dem Begriff „Server-Sent
Events“ bekannt. Im Gegensatz zu WebSockets wird keine bidirektionale Verbindung
hergestellt. Nachdem eine Verbindung vom Client hergestellt wurde, können
anschließend vom Server Daten an den Client übertragen werden. Diese Methode
wird ebenfalls nicht vom IIS unterstütz, jedoch existierten Bibliotheken, die die
Verwendung von „Server-Sent Events“ im IIS ermöglichen. Größere Probleme gibt es
hier bei den Webbrowsern. Der Internet Explorer von Microsoft unterstützt bis zu der
aktuellen Version 10 keine „Server-Sent Events“. Auch liegen derzeit keine
JavaScript-Bibliotheken vor, über die die Funktion in den Browser eingebunden
werden kann. 18
6.2 Implementierung
6.2.1 Auslesen des Zwischenspeichers im EngineServer
In Kapitel 5.2.2 wurde beschrieben, wie die Simulationsergebnisse zur Laufzeit in
den Zwischenspeicher geschrieben werden. Sendet WebScope eine Anfrage an den
EngineServer, müssen die Ergebnisse aus dem Zwischenspeicher gelesen werden.
In Anhang 11 befindet sich der Quelltext zum Auslesen der Simulationsergebnisse.
17 vgl. online: WebSocket auf Wikipedia.org (25.08.2013)
18 vgl. online: Server-Sent Events auf Wikipedia.org (25.08.2013)
Seite 40

Anzeige der Simulationsergebnisse in WebScope
Hier wird davon ausgegangen, dass bereits das entsprechende Objekt für die
Simulation (ESJobObject) bereits geladen wurde. Zu Beginn werden die Waveform-
Daten geladen. Für die erste Anfrage sind diese Daten leer. In diesem Fall werden
die Listen für die Werte angelegt. Anschließend werden die Daten aus dem bisher
verwendeten Zwischenspeicher (vgl. wfdat) in den neuen kopiert. Da es sich um die
erste Anfrage handelt, befinden sich in diesem alle bisherigen Ergebnisse.
Anschließend werden die Daten aus den Listen in die Ausgabevariablen
geschrieben. Die Ausgabedaten müssen dabei als Feld vorliegen. Hier bietet jedoch
das .NET-Framework die ToArray()-Methode, mit der eine Liste in ein Feld
konvertiert werden kann.
6.2.2 Ausgabe der Simulationsdaten
In Kapitel 6.1.2 wurden mehrere Möglichkeiten aufgezeigt, wie die
Simulationsegergebnisse im Webbrowser zur Laufzeit dargestellt werden können. Da
die Transim Technology Corporation eine Kompatibilität für ältere Webbrowser
anbietet entfällt als Methode die Verwendung der „Server-Sent Events“. Die
Verwendung von Polling würde zu einem erhöhten Datenverkehr kommen und sollte
daher ebenfalls nicht verwendet werden. Somit bleiben als Alternative das Long-
Polling, sowie die Verwendung des WebSocket-Protokolls übrig. Beide Varianten
haben ihre Vor- und Nachteile.
Für die Verwendung von WebSockets müssen Änderungen an den Webservern der
Transim Technology Corporation vorgenommen werden. Ebenfalls muss eine
zusätzliche JavaScript-Bibliothek in WebScope eingebunden werden, um ältere
Webbrowser zu unterstützen. Der Vorteil liegt jedoch in der bidirektionalen
Verbindung zwischen Webbrowser und Webserver. Es ist gegenüber Long-Polling
schneller, und erzeugt einen niedrigeren Datenverkehr. Ebenfalls ist es möglich,
dass mehrere Client-Verbindungen zu dem Webserver hergestellt werden. So kann
die Ausgabe der Simulationsergebnisse auch von anderen Modulen, wie
beispielsweise dem WebSchematic zur Laufzeit genutzt werden. Long Polling
dagegen kann ohne Änderungen am Webserver implementiert werden. Da die
Anfragen an den Webserver über HTTP versandt werden, entsteht durch den HTTP-
Header ein höherer Datenverkehr. An dieser Stelle der Entwicklung müssen weitere
firmeninterne Besprechungen getroffen werden, welche Methode verwendet werden
soll. Da es zum Zeitpunkt der Fertigstellung dieser Bachelor-Thesis noch keine
Entscheidung vorlag ist die finale Implementierung hier nicht aufgeführt.
Um dennoch die Ausgabe der Simulationsdaten testen zu können, wurde zunächst
die Polling-Methode implementiert. Hierzu wurde eine neue Schaltfläche in
WebScope implementiert, über die die Aktualisierung angehalten, oder gestartet
werden kann. In Listing 11 ist der JavaScript-Quelltext aufgeführt, über den das
Polling realisiert wird.
Seite 41

Anzeige der Simulationsergebnisse in WebScope
function liveRef(idx) {
checkBounds(idx);
SimProxy.Graph(createJSON(idx), responseLiveGraph, null, 0);
}
function responseLiveGraph(data) {
// save the results
/* ... */
if (liveRefresh) {
setTimeout(function () { liveRef(0); }, 500);
}
}
Listing 11 Polling in WebScope
Die Funktion liveRef() startet über den Aufruf SimProxy.Graph() die Ajax-Anfrage
an den Webserver. Über den Proxy wird die Anfrage an den EngineServer
weitergeleitet. Dieser berechnet alle darzustellenden Punkte. Wurde in WebScope
keine Skalierung angegeben, werden als Minima- und Maxima-Werte die aus der
erzeugten *_JS_VIEWER.xml-Datei genommen. Wurden die Daten generiert werden
diese an den Webbrowser zurück geschickt. Hier wird die Funktion
responseLiveGraph() aufgerufen. In dieser Werden die übertragenen Daten in dem
Ausgabebereich der Webseite ausgegeben. Ist der Knopf für die Echtzeitausgabe
aktiviert, wird 500 Millisekunden gewartet, bevor eine neue Anfrage an den Server
geschickt wird. Diese Methode ist in der Praxis nicht zu verwenden, da ein sehr
hoher Datenverkehr entsteht. Er wurde hier lediglich implementiert, um die Ausgabe
der Simulationsergebnisse zu testen.
Seite 42

Bewertung und Ausblick
7 Bewertung und Ausblick
Im Rahmen dieser Arbeit wurden mehrere Programme und Unterprogramme
modifiziert, um eine Ausgabe von Simulationsergebnissen zur Laufzeit der
Simulation zu ermöglichen. Als Übertragung der Daten von dem Simulator zu der
Engine wurde sich für die Verwendung von Datenströmen entschieden. Im Verlauf
der Arbeit hat sich gezeigt, dass TCP gegenüber UDP als Protokoll besser geeignet
ist. Werden mehrere Simulationen auf einem Simulationsserver gleichzeitig
ausgeführt, muss eine Zuweisung der Simulationsdaten zu der ursprünglichen
Simulation erfolgen. Diese Zuordnung wird nun erreicht, indem für jede Simulation
ein eigener TCP-Server erstellt wird, an den die Simulationsanwendung die
Ergebnisse sendet. Für die Kommunikation zwischen Anwendung und Engine
musste ein Format entworfen werden, indem die Ergebnisse abgebildet werden. Hier
wurde XML-Format entworfen, das einen minimalen Overhead erzeugt und somit die
Netzwerkauslastung verringert. Die Implementierung eines TCP-Servers in der
Engine hat ergeben, dass es zu einem Blockieren der Engine kommt, wenn keine
Daten empfangen werden. Dies wurde umgangen, indem das Empfangen der Daten
in einen zusätzlichen Thread ausgelagert wurde. Um die empfangenen Daten in dem
Webbrowser zugänglich zu machen, musste die bestehende Lösung zur Ausgabe
der Daten modifiziert werden. Um einen Geschwindigkeitsvorteil zu erreichen,
werden die Ausgabedaten in einen Zwischenspeicher geschrieben. Der
EngineServer wurde so modifiziert, dass neue Simulationsergebnisse in diesen
Zwischenspeicher eingetragen werden. Um die Ergebnisse aus der Engine an den
EngineServer weiterzuleiten wurden Rückruffunktionen verwendet. Die eigentliche
Ausgabe der Simulationsergebnisse in WebScope greift auf die Daten in dem
Zwischenspeicher des EngineServers zu. Um die Simulationsergebnisse WebScope
zur Laufzeit zur Verfügung zu stellen, wurden mehrere Methoden vorgestellt. Dabei
hat sich die Verwendung von Long-Polling oder die Nutzung des WebSocket-
Protokolls als günstig erwiesen. Die Entscheidung für eine der Methoden muss in
weiteren firmeninternen Besprechungen erfolgen. Aus diesem Grund ist die
Implementierung aufgrund des zeitlich begrenzten Rahmens in dieser Arbeit nicht
möglich gewesen.
Seite 43

Quellenverzeichnis
Quellenverzeichnis
Ajax (Programmierung) auf Wikipedia.org
http://de.wikipedia.org/wiki/Ajax_(Programmierung) (22.08.2013)
c-worker.ch Winsock Tutorial
http://www.c-worker.ch/tuts.php (08.07.2013)
Document Object Model auf Wikipedia.org
http://de.wikipedia.org/wiki/Document_Object_Model (09.08.2013)
Hypertext Markup Language auf Wikipedia.org
http://de.wikipedia.org/wiki/Hypertext_Markup_Language (22.08.2013)
IEEE 802.3-2012 – Section One, 2012
Interprozesskommunikation auf Wikipedia.org
http://de.wikipedia.org/wiki/Interprozesskommunikation (15.07.2013)
MEYER, Martin: Studienarbeit – Integration des „Quite Universal Circuit Simulator“ in
das Engine Framework der Transim Technology Corporation. Glauchau, 2013
Qucs auf Sourceforge.net:
http://sourceforge.net/p/qucs/git/ci/master/tree/ (12.07.2013)
RFC 793 – Transmission Control Protocol
http://tools.ietf.org/html/rfc793 (13.08.2013)
Server-sent events auf Wikipedia.org
http://en.wikipedia.org/wiki/Server-sent_events (25.08.2013)
Simple API for XML auf Wikipedia.org
http://de.wikipedia.org/wiki/Simple_API_for_XML (09.08.2013)
Seite 44

Quellenverzeichnis
The zlib/libpng License (Zlib) auf opensource.org
http://opensource.org/licenses/Zlib (09.08.2013)
Tiefpass auf Wikipedia.org
http://de.wikipedia.org/wiki/Tiefpass (07.08.2013)
WebSocket auf Wikipedia.org
http://de.wikipedia.org/wiki/WebSocket (25.08.2013)
Seite 45

Anhangverzeichnis
Anhangverzeichnis
Anhang 1
Anhang 2
Anhang 3
Anhang 4
Anhang 5
Anhang 6
Anhang 7
Anhang 8
Anhang 9
Anhang 10
Anhang 11
Qucs-Ausgabedatei
Größe der Ergebnisdaten bei XML und JSON
Node.js Quelltext für den TCP- und UDP-Testserver
Änderungen am Programmeinstieg „ucs.cpp“
Die Header- und Quelltext-Dateien der Qucs-Netzwerkklasse
Erweiterung der nasolver-Klasse
Speichern der Ergebnisse und Abhängigkeiten in Qucs
Typen
Beispiel für eine Kurvenschar
Änderungen an der EngineServer-Klasse
Auslesen der Simulationsergebnisse aus dem Zwischenspeicher
Seite 46

Qucs-Ausgabedatei Anhang 1
Anhang 1 Qucs-Ausgabedatei
+1.00000000000e+000
+1.00000000000e+005
+1.00000000000e+010
+5.00000000000e+000
+5.00000000000e+006
+5.00000000000e-010
+1.50000000000e-009
-4.93480220054e-017-j3.14159265359e-009
-4.93479002439e-007-j3.14158490204e-004
-1.99991894634e-001-j1.27318794437e-003
-4.93358488727e-011-j3.14081768789e-009
-1.99999918943e-007-j1.27323902871e-010
-2.00000000000e-007-j1.27323954474e-015
-4.44089209850e-016-j9.42477796077e-009
-4.44122335597e-006-j9.42456867305e-004
-1.99999099371e-001-j4.24411270385e-004
-4.43148116314e-010-j9.40389509777e-009
-1.99999990994e-007-j4.24413162466e-011
-2.00000000000e-007-j4.24413181578e-016
+1.00000000000e+000-j1.57079632679e-008
+9.99997532605e-001-j1.57079245102e-003
+4.05268309663e-005-j6.36593972186e-003
+9.99753320756e-001-j1.57040884394e-002
+4.05284570314e-007-j6.36619514355e-004
+4.05284734569e-017-j6.36619772368e-009
+1.00000000000e+000-j4.71238898038e-008
+9.99977793883e-001-j4.71228433652e-003
+4.50314343905e-006-j2.12205635192e-003
+9.97784259418e-001-j4.70194754888e-002
+4.50316351465e-008-j2.12206581233e-004
+4.50316371744e-018-j2.12206590789e-009
+1.00000000000e+000
+1.00000000000e+000
+1.00000000000e+000
+1.00000000000e+000
+1.00000000000e+000
+1.00000000000e+000
+1.00000000000e+000
+1.00000000000e+000
+1.00000000000e+000
+1.00000000000e+000
+1.00000000000e+000
+1.00000000000e+000

Größe der Ergebnisdaten bei XML und JSON Anhang 2
Anhang 2 Größe der Ergebnisdaten bei XML und JSON
( ) ( ( ) ( )) ( ( ) ( ))
d
XML
in Byte
i
1 2 3 4 … 23 24 25 26 27 28
1 147 198 249 300 … 1269 1320 1371 1422 1473 1524
2 198 249 300 351 … 1320 1371 1422 1473 1524 1575
3 249 300 351 402 … 1371 1422 1473 1524 1575 1626
4 300 351 402 453 … 1422 1473 1524 1575 1626 1677
… … … … … … … … … … … …
23 1269 1320 1371 1422 … 2391 2442 2493 2544 2595 2646
24 1320 1371 1422 1473 … 2442 2493 2544 2595 2646 2697
25 1371 1422 1473 1524 … 2493 2544 2595 2646 2697 2748
26 1422 1473 1524 1575 … 2544 2595 2646 2697 2748 2799
27 1473 1524 1575 1626 … 2595 2646 2697 2748 2799 2850
28 1524 1575 1626 1677 … 2646 2697 2748 2799 2850 2901
( ) ( ( ) ( )) ( ( ) ( ))
d
JSON
in Byte
i
1 2 3 4 … 23 24 25 26 27 28
1 145 200 255 310 … 1355 1410 1465 1520 1575 1630
2 200 255 310 365 … 1410 1465 1520 1575 1630 1685
3 255 310 365 420 … 1465 1520 1575 1630 1685 1740
4 310 365 420 475 … 1520 1575 1630 1685 1740 1795
… … … … … … … … … … … …
23 1355 1410 1465 1520 … 2565 2620 2675 2730 2785 2840
24 1410 1465 1520 1575 … 2620 2675 2730 2785 2840 2895
25 1465 1520 1575 1630 … 2675 2730 2785 2840 2895 2950
26 1520 1575 1630 1685 … 2730 2785 2840 2895 2950 3005
27 1575 1630 1685 1740 … 2785 2840 2895 2950 3005 3060
28 1630 1685 1740 1795 … 2840 2895 2950 3005 3060 3115

Node.js Quelltext für den TCP- und UDP-Testserver Anhang 3
Anhang 3 Node.js Quelltext für den TCP- und UDP-Testserver
Der TCP-Server:
var net = require('net');
var host = '127.0.0.1';
var port = 12346;
net.createServer(function(sock) {
sock.name = sock.remoteAddress + ":" + sock.remotePort
console.log(Date.now() + ' | CONNECTED: ' + sock.name);
sock.on('data', function(data) {
console.log(Date.now() + ' | DATA ' + sock.name + ' - ' + data);
});
sock.on('error', function(data) {
console.log(Date.now() + ' | ERROR ' + sock.name + ' - ' + data + '\n');
});
sock.on('end', function() {
console.log(Date.now() + ' | END: ' + sock.name + '\n');
});
}).listen(port, host);
console.log('Server listening on ' + host + ':' + port + '\n');
Der UDP-Server:
var port = 12345;
var host = '127.0.0.1';
var dgram = require('dgram');
var server = dgram.createSocket('udp4');
server.on('listening', function () {
var address = server.address();
console.log('UDP Server listening on ' + address.address + ':' + address.port
+ '\n');
});
server.on('message', function(message, remote) {
console.log(Date.now() + ' | DATA ' + remote.address + ':' + remote.port
+ ' - ' + message);
});
server.bind(port, host);

Änderungen am Programmeinstieg „ucs.cpp“ Anhang 4
Anhang 4
Änderungen am Programmeinstieg „ucs.cpp“
/* ... */
#include "network.h"
/* ... */
int main (int argc, char ** argv) {
}
/* ... */
// check program arguments
for (int i = 1; i < argc; i++) {
/* ... */
if (!strcmp (argv[i], "-d")) {
i++;
msDelay = atoi(argv[i]);
}
else if (!strcmp (argv[i], "-udp")) {
// Look for valid Arguments
if(i+1 >= argc)
{
fprintf (stdout,
"Usage: %s [OPTION]...\n\n"
" -udp IP:PORT using UDP to send the simulation results "
"to a server\n", argv[0]);
return 1;
}
i++;
networkAddr = (char *)malloc(strlen(argv[i])+1);
strcpy(networkAddr, argv[i]);
networkUse = true;
networkProtocol = network::UDP;
}
else if (!strcmp (argv[i], "-tcp")) {
// Look for valid Arguments
if(i+1 >= argc)
{
fprintf (stdout,
"Usage: %s [OPTION]...\n\n"
" -tcp IP:PORT using TCP to send the simulation results"
" to a server\n", argv[0]);
return 1;
}
i++;
networkAddr = (char *)malloc(strlen(argv[i])+1);
strcpy(networkAddr, argv[i]);
networkUse = true;
networkProtocol = network::TCP;
}
/* ... */
}
/* ... */

Die Header- und Quelltext-Dateien der Qucs-Netzwerkklasse Anhang 5
Anhang 5
Die Header-Datei:
#ifndef __NETWORK_H__
#define __NETWORK_H__
Die Header- und Quelltext-Dateien der Qucs-Netzwerkklasse
#include
#pragma comment(lib,"ws2_32.lib")
class network
{
public:
// Enumeration Declarations
enum Protocol {UDP, TCP};
// Consturctor & Destructor Declarations
network(char const* str, network::Protocol protocol);
network(char const* ip, int port, network::Protocol protocol);
~network(void);
// static member function Declarations
static int getAddr(char const* str, char* ip, int* port);
// member function Declarations
int netStartSocket(void);
int netConnect(void);
int netSend(char* str);
int netClose(void);
private:
// private member function Declarations
int startWinsock(void);
// private member variables Declaration
Protocol m_protocol;
char m_strIP[15];
int m_iPort;
long m_lRC;
SOCKET m_s;
};
// externalize global variable
extern bool networkUse;
extern char * networkAddr;
extern network::Protocol networkProtocol;
extern int msDelay;
#endif /* __NETWORK_H__ */

Die Header- und Quelltext-Dateien der Qucs-Netzwerkklasse Anhang 5
Die Quelltext-Datei:
#include "network.h"
// Global variables.
bool networkUse = false;
char * networkAddr = NULL;
network::Protocol networkProtocol = network::UDP;
int msDelay = 0;
network::network(void)
{
strcpy(m_strIP, "127.0.0.1");
m_iPort = 12345;
m_protocol = UDP;
}
network::network(char const* str, network::Protocol protocol)
{
char ip[15];
int port;
if(getAddr(str, ip, &port) == 0)
{
strcpy(m_strIP, ip);
m_iPort = port;
m_protocol = protocol;
}
}
network::network(char const* ip, int port, network::Protocol protocol)
{
strcpy(m_strIP, ip);
m_iPort = port;
m_protocol = protocol;
}
network::~network(void)
{
}
int network::startWinsock()
{
WSADATA wsa;
return WSAStartup(MAKEWORD(2,0),&wsa);
}
/* Page 1 of 3 */

Die Header- und Quelltext-Dateien der Qucs-Netzwerkklasse Anhang 5
int network::getAddr(char const* str, char* ip, int* port)
{
// copy str to temporary variable
char* tmp = (char*)malloc(strlen(str)+1);
strcpy(tmp, str);
// split the string at ':'
int cnt = 0;
char* pch = strtok(tmp, ":");
while (pch != NULL)
{
if(cnt == 0)
strcpy(ip, pch);
if(cnt == 1)
*port = atoi(pch);
cnt++;
pch = strtok(NULL, ":");
} free(tmp);
if(cnt != 2)
return 1;
}
return 0;
int network::netStartSocket(void)
{
// start WinSock
m_lRC = startWinsock();
if(m_lRC != 0)
return m_lRC;
// create socket
if(m_protocol == UDP)
m_s = socket(AF_INET, SOCK_DGRAM, 0);
else if(m_protocol == TCP)
m_s = socket(AF_INET, SOCK_STREAM, 0);
else
return -1;
if(m_s == INVALID_SOCKET)
return WSAGetLastError();
}
return 0;
/* Page 2 of 3 */

Die Header- und Quelltext-Dateien der Qucs-Netzwerkklasse Anhang 5
int network::netConnect(void)
{
// connect to server
SOCKADDR_IN addr;
memset(&addr, 0, sizeof(SOCKADDR_IN));
addr.sin_family = AF_INET;
addr.sin_port = htons(m_iPort);
addr.sin_addr.s_addr = inet_addr(m_strIP);
m_lRC = connect(m_s, (SOCKADDR*)&addr, sizeof(SOCKADDR_IN));
if(m_lRC == SOCKET_ERROR)
return WSAGetLastError();
}
return 0;
int network::netSend(char* str)
{
char * buf = (char *)malloc(strlen(str)+1);
strcpy(buf, str);
m_lRC = send(m_s, buf, strlen(buf), 0);
if(m_lRC == SOCKET_ERROR)
return WSAGetLastError();
free(buf);
return 0;
}
int network::netClose()
{
closesocket(m_s);
WSACleanup();
return 0;
}
/* Page 3 of 3 */

Erweiterung der nasolver-Klasse Anhang 6
Anhang 6
Erweiterung der nasolver-Klasse
// Constructor creates an unnamed instance of the nasolver class.
template
nasolver::nasolver () : analysis () {
/* ... */
if(networkUse)
{
myNet = network(networkAddr, networkProtocol);
myNet.netStartSocket();
myNet.netConnect();
}
}
// Constructor creates a named instance of the nasolver class.
template
nasolver::nasolver (char * n) : analysis (n) {
/* ... */
if(networkUse)
{
myNet = network(networkAddr, networkProtocol);
myNet.netStartSocket();
myNet.netConnect();
}
}
// Destructor deletes the nasolver class object.
template
nasolver::~nasolver () {
/* ... */
if(networkUse)
myNet.netClose();
}
/* ... */
/* This function saves the results of a single solve() functionality
into the output dataset. */
template
void nasolver::saveResults (const char * volts, const char * amps,
int saveOPs, vector * f) {
/* ... */
//Send Result to Server:
if(networkUse)
{
// Create XML-Node:
const char vers[] = {PACKAGE_VERSION};
int len;
len = strlen(netPrint)+strlen(vers)+39;
char * xnode = (char *)malloc(len + 1);
sprintf(xnode, "%s", vers,
netPrint);
xnode[len] = '\0';
}
myNet.netSend(xnode);
}
// Add delay to simulation:
usleep(msDelay*1000);

Speichern der Ergebnisse und Abhängigkeiten in Qucs Anhang 7
Anhang 7 Speichern der Ergebnisse und Abhängigkeiten in Qucs
Änderungen an der analysis.cpp:
int analysis::solve (char const * str)
{
netPrint = (char*)malloc(strlen(str)+1);
strcpy(netPrint, str);
return solve();
}
Aufruf der getDNode()-Funktion:
void analysis::getDNode (char const * n, nr_complex_t val)
{
char * out;
char * tmp;
double creal = real(val);
double cimag = imag(val);
int len = 0;
if(cimag != 0) {
tmp = (char *)malloc(40);
char sign = '+';
if(cimag < 0) {
sign = '-';
cimag = -cimag;
}
sprintf(tmp, "%+.11e%cj%.11e", creal, sign, cimag);
}
else {
tmp = (char *)malloc(20);
sprintf(tmp, "%+.11e", creal);
}
if(netPrint2==NULL) {
len = strlen(n)+strlen(tmp)+12;
netPrint2 = (char *)malloc(len+1);
sprintf(netPrint2, "%s", n, tmp);
}
else {
len = strlen(netPrint2);
char * help = (char*)malloc(len+1);
strcpy(help, netPrint2);
free(netPrint2);
len = strlen(help)+strlen(n)+strlen(tmp)+12;
netPrint2 = (char *)malloc(len+1);
sprintf(netPrint2, "%s%s", help, n, tmp);
free(help);
}
free(tmp);
}
return;

Speichern der Ergebnisse und Abhängigkeiten in Qucs Anhang 7
Beispiel für die Verwendung der getINode()-Funktion:
char * analysis::getINode (char const * IName, char const * unit, nr_double_t v)
{
char * out;
char* tmpName;
int len;
char val[20];
sprintf(val, "%+.11e", v);
if(strlen(unit)>0) {
len = strlen(IName)+strlen(unit)+1;
tmpName = (char *)malloc(len+1);
sprintf(tmpName, "%s.%s", IName, unit);
}
else {
len = strlen(IName);
tmpName = (char *)malloc(len+1);
sprintf(tmpName, "%s", IName);
}
tmpName[len] = '\0';
if(netPrint == NULL) {
len = strlen(tmpName)+strlen(val)+12;
out = (char *)malloc(len+1);
sprintf(out, "%s", tmpName, val);
}
else {
len = strlen(tmpName)+strlen(val)+strlen(netPrint)+12;
out = (char*)malloc(len+1);
sprintf(out, "%s%s", netPrint, tmpName, val);
}
out[len] = '\0';
return out;
}

Typen Anhang 8
Anhang 8
Typen
# Bezeichnungen
0 UNKNOWN
1 NONE
2 volt voltage
3 amp current
4 second time
5 hertz frequency
6 ohm resistance
7 siemens conductance
8 farad capacity
9 henry inductance
10 joule energy
11 watt power
12 coulomb charge
13 weber magnetic flux
14 volt_squared
15 volt_squared_over_hertz
16 volt_over_square_root_of_hertz
17 amp_squared
18 amp_squared_over_hertz
19 amp_over_square_root_of_hertz
20 volt_over_second
21 constant
22 centigrad
23 digital
24 tesla
25 amp_turns_over_meter
26 temperature
27 length
28 angle

Beispiel für eine Kurvenschar Anhang 9
Anhang 9 Beispiel für eine Kurvenschar
Die Schaltung:
Ausgabe der Simulation:
Auszug der übertragenen Zwischenergebnisse:
+6.07902735562e-006
+1.00000000000e+001
-2.57362469582e-002
+4.59512013373e-001
+2.02149543791e-001

Beispiel für eine Kurvenschar Anhang 9
Liste der Waveform-Dateien:
Die Manifest-Datei:
# Division Labels (comma separated) : P1 +1.00e+000, P1 +3.16e+001, P1 +1.00e+003
Ua.Vt,Sim1_6373452_group0_c0_div_0,4,2,1,1
Ua.Vt,Sim1_6373452_group0_c0_div_1,4,2,1,1
Ua.Vt,Sim1_6373452_group0_c0_div_2,4,2,1,1
Ue.Vt,Sim1_6373452_group0_c1_div_0,4,2,1,1
Ue.Vt,Sim1_6373452_group0_c1_div_1,4,2,1,1
Ue.Vt,Sim1_6373452_group0_c1_div_2,4,2,1,1
Ue1.It,Sim1_6373452_group0_c2_div_0,4,3,1,1
Ue1.It,Sim1_6373452_group0_c2_div_1,4,3,1,1
Ue1.It,Sim1_6373452_group0_c2_div_2,4,3,1,1

Änderungen an der EngineServer-Klasse Anhang 10
Anhang 10 Änderungen an der EngineServer-Klasse
ESTypes.h:
public ref struct WFData : public Object
{
public:
array ^m_XDataReal;
array ^m_YDataReal;
array ^m_XDataImag;
array ^m_YDataImag;
};
public ref struct WFLiveData : public Object
{
public:
List ^m_XDataReal;
List ^m_YDataReal;
List ^m_XDataImag;
List ^m_YDataImag;
};
EngineServerWSClass.cpp:
void EngineServerWSClass::ALResultCallBack(const char* WFFilename, float XData,
float YData, float XDataImag, float YDataImag,
bool IsComplex)
{
IDictionaryEnumerator ^DicEnum = c_JobHandleToJobObject->GetEnumerator();
while ( DicEnum->MoveNext() )
{
ESJobObject ^jo = safe_cast(DicEnum->Value);
if ( jo != nullptr ) {
String ^WaveFormFilename = gcnew String(WFFilename);
if(!String::IsNullOrEmpty(jo->m_strFileTag)) {
if(jo->m_mapWFLiveData == nullptr) {
jo->m_mapWFLiveData = gcnew Hashtable();
}
WFLiveData ^wfldat = (WFLiveData ^)jo->m_mapWFLiveData[WaveFormFilename];
if(wfldat != nullptr) {
wfldat->m_XDataReal->Add(XData);
wfldat->m_YDataReal->Add(YData);
if(IsComplex) {
wfldat->m_XDataImag->Add(XDataImag);
wfldat->m_YDataImag->Add(YDataImag);
}
jo->m_mapWFLiveData[WaveFormFilename] = wfldat;
}
}
}
}
}

Auslesen der Simulationsergebnisse aus dem Zwischenspeicher Anhang 11
Anhang 11 Auslesen der Simulationsergebnisse aus dem Zwischenspeicher
WFLiveData ^wfldat = nullptr;
if(jo->m_mapWFLiveData != nullptr)
wfldat = (WFLiveData ^)jo->m_mapWFLiveData[WFFileName];
if(wfldat == nullptr)
{
wfldat = gcnew WFLiveData();
wfldat->m_XDataReal = gcnew List();
wfldat->m_YDataReal = gcnew List();
if(bComplex)
{
wfldat->m_XDataImag = gcnew List();
wfldat->m_YDataImag = gcnew List();
}
else
{
wfldat->m_XDataImag = nullptr;
wfldat->m_YDataImag = nullptr;
}
for(int i=0; i< wfdat->m_XDataReal->Length; i++)
{
wfldat->m_XDataReal->Add(wfdat->m_XDataReal[i]);
wfldat->m_YDataReal->Add(wfdat->m_YDataReal[i]);
}
}
if(bComplex)
{
wfldat->m_XDataImag->Add(wfdat->m_XDataImag[i]);
wfldat->m_YDataImag->Add(wfdat->m_YDataImag[i]);
}
XData = wfldat->m_XDataReal->ToArray();
YData = wfldat->m_YDataReal->ToArray();
if(bComplex)
{
XDataImag = wfldat->m_XDataImag->ToArray();
YDataImag = wfldat->m_YDataImag->ToArray();
}
return ES_ERROR_NOERROR;

Ehrenwörtliche Erklärung
Ehrenwörtliche Erklärung
„Ich erkläre hiermit ehrenwörtlich“,
1. dass ich meine Bachelor Thesis mit dem Thema
Erweiterung des Engine Framework und der Web-Schematic Lösung der
Transim Technology Corporation um eine Echtzeitkommunikation zwischen
Simulator und Schematic
ohne fremde Hilfe angefertigt habe.
2. dass ich die Übernahme wörtlicher Zitate aus der Literatur sowie die
Verwendung der Gedanken anderer Autoren an den entsprechenden Stellen
innerhalb der Arbeit gekennzeichnet habe und
3. dass ich meine Bachelor Thesis bei keiner anderen Prüfung vorgelegt habe.
Ich bin mir bewusst, dass eine falsche Erklärung rechtliche Folgen haben wird.
____________________
Ort, Datum
____________________
Unterschrift

Thesen
Thesen
1. Die Kommunikation zwischen der Simulationsanwendung Qucs und der
entsprechenden Engine des EngineServers erfolgt mithilfe von Datenströmen.
2. Als Protokoll für die Kommunikation zwischen Simulationsanwendung und
Engine ist das sicherere TCP bevorzugt gegenüber dem schnelleren UDP.
3. Bei mehreren gestarteten Simulationen muss eine Zuweisung der
übertragenen Daten zu den Simulationen erfolgen. Diese Zuweisung erfolgt,
indem für jede Simulation ein eigener TCP-Server erstellt wird, der an einen
eigenen Port gebunden ist.
4. Als Format für die Übertragung der Daten von Qucs an das EngineFramework
ist XML, aufgrund eines kleineren Overhead, gegenüber JSON zu verwenden.
5. Zum Empfangen der Simulationsergebnisse in der Engine wird ein TCP-
Server benötigt. Um ein blockieren der Engine zu verhindern, muss dieser in
einem zusätzlichen Thread ausgeführt werden.
6. Um die Simulationsergebnisse von der Engine an den EngineServer zur
Laufzeit weiterzuleiten eignet sich die Verwendung von Rückruffunktionen.