Diss.-ETH 12317 Diss.-ETH 12317 Diss.-ETH 12317 Diss.-E Eine ...

Diss. ETH Nr. 12317 

Eine Domänen-Architektur zur 

Konfiguration von wiederverwendbaren 

Software-Komponenten für die Lösung 

nichtlinearer Netzgleichungen 

ABHANDLUNG 

zur Erlangung des Titels 

DOKTOR DER TECHNISCHEN WISSENSCHAFTEN 

der 

EIDGENÖSSISCHEN TECHNISCHEN HOCHSCHULE 

ZÜRICH 

vorgelegt von 

PETER BOSSHART 

Dipl. El.-Ing. ETH 

geboren am 15. Juli 1955 

Bürger von Zürich (ZH) 

und Wittenwil (TG) 

Angenommen auf Antrag von 

Prof. Dr. R. Bacher, Referent 

Prof. Dr. R. Weiss, Korreferent 

Zürich 1997 

Diss.-ETH 12317 Diss.-ETH 12317 Diss.-ETH 12317 Diss.-E


Meiner Frau Klara 


Diese Arbeit entstand zwischen 1994 und 1997 während meiner Assistenztätigkeit 

am ETH-Institut für Energieübertragung und Hochspannungstechnik 

in der Fachgruppe Netzleittechnik. 

Herrn Prof. Dr. Rainer Bacher möchte ich für die Betreuung und Korrektur 

der Arbeit danken. Er hat in offenen und kreativen Diskussionen 

viel zu dieser Arbeit beigetragen. Herrn Prof. Dr. Reinhold Weiss sei 

für die Übernahme des Korreferats herzlich gedankt. Prof. Dr. Hans 

Glavitsch hat den Einstieg in diese Arbeit mit viel Erfahrung begleitet. 

Wertvolle Einsichten ergaben sich auch aus der Zusammenarbeit mit Reto 

Hirt, der Teile des Prototyps implementiert und getestet hat. Ferner hat 

Markus Leuzingers kompetente und freundliche Hilfe bei EDV-Problemen 

die Arbeit oft erleichtert. Stamatina Orfanogianni verdanke ich die Vergleichsmöglichkeit 

mit ihrem konkurrierenden Ansatz. 

Herzlicher Dank gilt meinem Vater Walter und seiner Frau Anne 

Bosshart-Girod für das offene Haus in der Nähe des ETH-Instituts während 

der Abschlussphase dieser Arbeit. 

Besonderer Dank gilt schliesslich meiner Frau Klara, die mich während 

dem Entstehen dieser Arbeit hilfreich, klug und geduldig begleitet hat. 

Zürich, im Juli 1997 Peter Bosshart 


Kurzfassung 

Viele Applikationen im Bereich der elektrischen Energieübertragung 

führen auf ein System von simultanen, nichtlinearen Gleichungen 

g(x,p)=0(x: Unbekannte, p: Parameter), die nach den Unbekannten x 

aufzulösen sind. Diese Gleichungen beschreiben das nichtlineare Verhalten 

miteinander verbundener Entitäten. 

Dies ist kein neues Problem. Der Beitrag der vorliegenden Arbeit 

besteht jedoch darin, für diese Klasse von Problemen mit Mitteln des 

Software-Engineerings und aktuellen Erkenntnissen aus der Netzmodellierung 

eine wiederverwendbare, generische Lösung zu beschreiben, die 

leicht an neue Anforderungen angepasst werden kann. 

Diese Lösung besteht konkret aus den Diensten Netzaufbau, Netzberechnung 

und der Darstellung von Resultaten. Diese Dienste werden in 

einheitlicher Art als Leistungen aufgefasst, die sich aus einem variablen 

und einem innerhalb der Problemklasse konstanten Anteil zusammensetzt. 

Diese Struktur ist in einem in der vorliegenden Arbeit betrachteten Prototypen 

konkretisiert worden. 

Der Kern des Prototypen besteht aus einem objekt-orientierten Framework. 

Es eignet sich für diese Aufgabenstellung, weil sich damit ein generisches 

Modell der betrachteten Problemklasse implementieren lässt. Dieses 

Domänenmodell stellt ein wesentliches Ergebnis der vorliegenden Arbeit 

dar. 

Es hat sich herausgestellt, dass das Verhalten eines Netzes durch Instanzen 

zweier generischer Bausteintypen, Ntor und Summengeber, modellierbar 

ist. Instanzen dieser Typen werden stets über Anschlüsse miteinander 

verbunden. Dabei wird der Anschluss als abstrakter Begriff aufgefasst. 

Die dafür gängige Vorstellung einer elektrischen Klemme ist nur ein wichtiger 

Spezialfall. 

Das Ntor ist eine Entität, die üblicherweise mit einem physikalischen 

Betriebsmittel, wie z.B. einem Generator, einer Last oder Leitung assoziiert 

wird. Das Ntor ist jedoch von allgemeinerer Natur. Es ist mit ihm 

möglich, auch eine Fehlerbedingung, wie z.B. einen Kurzschlussfall zu 

modellieren. Das Ntor stellt einen endlichen Automaten mit einem Verhalten 

BN σ(Vσ,Pσ,E σ,Tσ) für jeden Zustand σ dar. Die Menge E σ enthält 

alle Gleichungen, die mit Hilfe der Variablen Vσ und den Parametern Pσ 

gebildet werden. Die Menge Tσ spezifiziert den endlichen Automaten 

durch die Angabe von Zuständen und Übergangsbedingungen. 


Die Summengeber greifen auf Variable in den Ntoren zu, und formulieren 

damit weitere Gleichungen, um z.B. die Topologie eines Netzes auszudrücken. 

Den Bausteintypen des Domänenmodells entsprechen spezielle Klassen 

des Frameworks, die dazu angelegt sind, für einen bestimmten Anwendungsfall 

noch konkretisiert zu werden. Dazu wird ein Mechanismus vorgestellt, 

der den variablen Anteil eines Dienstes in kontrollierter Weise im 

Framework adaptiert. An dieser Stelle kommt ein symbolisches Rechenprogramm 

(Maple V) zum Einsatz, das aus einer anwendungsfreundlichen 

Hochsprachen-Spezifikation zuverlässig den korrekten Quelltext für die zu 

konkretisierenden Teile des Frameworks erzeugt. 

Alle diese Elemente, wie Framework, Spezifikation und Adaption der 

generischen Teile des Frameworks werden innerhalb einer übergeordneten 

Domänen-Architektur koordiniert. 

Der Nutzen der in dieser Arbeit vorgeschlagenen Vorgehensweise ist 

eine erhebliche Einsparung des Entwicklungsaufwandes innerhalb dieser 

Klasse von Simulationsproblemen. 


Abstract 

Many applications lead to systems of simultaneous nonlinear equations 

g(x,p)=0(x: unknowns, p: parameters) which have to be solved for 

the unknowns x. It is assumed that these equations describe non-linear 

behavior related to interconnected entities. This is not a new problem. 

However the contribution of this thesis is a description of a generic solution 

for a class of problems by means of software-engineering and an actual 

approach of network modeling. The result is a reusable asset which can be 

easily adapted to changes of specifications. 

The proposed asset offers three fundamental services: Instantiation of 

network building objects, simulation (calculation) and representation of 

results. These services are modeled in a unified manner. Each service consists 

of a variable and a constant part within the boundary of the problem. 

This concept has been implemented in a prototype, which is described in 

the thesis. 

The core of the prototype is an object-oriented framework. It is suited 

for the task, because it is capable to represent a generic design for the class 

of problems mentioned above. A domain model containing the commonalities 

of these problems has been found, which is an important result of this 

thesis. 

A typical application was analyzed to figure out an object-oriented model 

of this domain. It turned out that a behavior of a network can be modeled 

by instances of two generic types nport and sumsetter. These instances 

are always connected by ports. Thereby the port is seen as an abstract 

term. Its common association to an electrical terminal is only an import 

special case. 

The nport is the entity typically associated with an electrical element 

such as generator, load, line etc. The nport, however, is more general allowing 

to model for example fault conditions, such as a short circuit. The 

nport is a finite state machine with a behavior BN σ(Vσ,Pσ,E σ,Tσ) for 

each state σ. The set E σ contains all equations formulated in terms of local 

variables Vσ and parameters Pσ. Tσ defines the transitions and their 

conditions leading to next states. 

A sumsetter accesses variables located in nports to create further equations, 

typically expressing incidence relations within networks. A sumsetter 

contains instances of sum types and a set A of n connected ports. 

The domain model was implemented as a system of coupled classes 


which establish the object-oriented framework. Thereby the entities of the 

domain model, nport and sumsetter, are special classes, which have to be 

adapted to concrete applications. A mechanism is proposed to adapt the 

framework in controlled way. At this place a symbolic calculation system 

(Maple V) is applied to generate correct source code of the adapted parts 

of the framework from a user-friendly, high-level language specification. 

All these elements, such as framework, specification and adaptation of 

the generic parts of the framework are coordinated within a domain architecture. 

The payoff of this approach is a high reduction in the effort to develop, 

maintain and expand software in the domain of non-linear network 

equations. 


Inhaltsverzeichnis 

1 Einleitung 1 

1.1 Motivation.......................... 1 

1.2 StandderTechnik...................... 2 

1.3 ZielderArbeit........................ 4 

1.4 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . 5 

2 Konzepte des Software-Engineering 7 

2.1 Einleitung.......................... 7 

2.2 Software-Wiederverwendung . . . . . . . . . . . . . . . . 8 

2.2.1 Erwartungen an die Wiederverwendung . . . . . . 9 

2.2.2 Grundlegende Ansätze............... 9 

2.2.3 Hindernisse . . . . . . . . . . . . . . . . . . . . . 10 

2.2.4 Techniken . . . . . . . . . . . . . . . . . . . . . . 12 

2.3 Begriffe der objekt-orientierten Programmierung . . . . . 15 

2.3.1 Objekt . . . . . . . . . . . . . . . . . . . . . . . . 15 

2.3.2 Klassen . . . . . . . . . . . . . . . . . . . . . . . 17 

2.3.3 Methoden . . . . . . . . . . . . . . . . . . . . . . 17 

2.3.4 Attribute . . . . . . . . . . . . . . . . . . . . . . 18 

2.4 Objekt-orientierte Konzepte . . . . . . . . . . . . . . . . 18 

2.4.1 Kapselung . . . . . . . . . . . . . . . . . . . . . 18 

2.4.2 Vererbung . . . . . . . . . . . . . . . . . . . . . . 20 

2.4.3 Polymorphismus . . . . . . . . . . . . . . . . . . 21 

2.5 Objekt-orientiertes Framework . . . . . . . . . . . . . . . 21 

2.5.1 Begriff und Funktion . . . . . . . . . . . . . . . . 22 

2.5.2 Entwicklungsvorgang . . . . . . . . . . . . . . . . 23 

2.5.3 Anwendung . . . . . . . . . . . . . . . . . . . . . 24 

3 Netzmodellierung und Netzberechnung 27 

3.1 Domänenanalyse ...................... 27 

3.1.1 Lastfluss-Applikation . . . . . . . . . . . . . . . . 28 

I 


II INHALTSVERZEICHNIS 

3.1.2 Modellierung von Netzelementen . . . . . . . . . 29 

3.1.3 Zusammenschaltbarkeit der Netzelemente . . . . . 31 

3.1.4 Lösungsverfahren . . . . . . . . . . . . . . . . . . 33 

3.1.5 Netzgleichungen . . . . . . . . . . . . . . . . . . 36 

3.2 Domänenmodell....................... 51 

3.2.1 Netz und Entitäten ................. 51 

3.2.2 Anschluss . . . . . . . . . . . . . . . . . . . . . . 52 

3.2.3 Variable . . . . . . . . . . . . . . . . . . . . . . . 53 

3.2.4 Parameter . . . . . . . . . . . . . . . . . . . . . . 54 

3.2.5 Ntor . . . . . . . . . . . . . . . . . . . . . . . . . 54 

3.2.6 Summengeber . . . . . . . . . . . . . . . . . . . 56 

3.3 Funktionalität des Domänenmodells ............ 57 

3.3.1 Netzaufbau . . . . . . . . . . . . . . . . . . . . . 57 

3.3.2 Netzberechnung . . . . . . . . . . . . . . . . . . 57 

3.3.3 Resultat-Anzeige . . . . . . . . . . . . . . . . . . 58 

3.4 Beispiel ........................... 58 

4 Framework 63 

4.1 Einleitung.......................... 63 

4.2 Anwendungsbereich . . . . . . . . . . . . . . . . . . . . 64 

4.3 Implementation des Domänen-Modells........... 64 

4.4 Netzmodellierung . . . . . . . . . . . . . . . . . . . . . . 66 

4.5 Newton-Raphson-Netzberechnung . . . . . . . . . . . . . 67 

4.5.1 Beitrag des lokal definierten Verhaltens . . . . . . 67 

4.5.2 Konzeption der Operationen . . . . . . . . . . . . 69 

4.5.3 Aufgabenverteilung auf Klassen . . . . . . . . . . 70 

4.5.4 Lösen des linearen Gleichungssystems . . . . . . . 75 

4.6 Programmier-Schnittstellen (API) . . . . . . . . . . . . . 77 

4.7 Implementation....................... 78 

4.7.1 C++ . . . . . . . . . . . . . . . . . . . . . . . . . 79 

4.7.2 Bibliotheken . . . . . . . . . . . . . . . . . . . . 79 

5 Domänen-Architektur 81 

5.1 Einleitung.......................... 81 

5.2 Sichten ........................... 83 

5.2.1 Architekturebenen . . . . . . . . . . . . . . . . . 83 

5.2.2 Dienste . . . . . . . . . . . . . . . . . . . . . . . 83 

5.2.3 Variabilität innerhalb der Dienste . . . . . . . . . 86 

5.3 Architektur-Elemente.................... 86 


INHALTSVERZEICHNIS III 

5.3.1 Domänenmodell .................. 88 

5.3.2 Spezifikationselement . . . . . . . . . . . . . . . 89 

5.3.3 Spezifikationsdaten . . . . . . . . . . . . . . . . . 89 

5.3.4 Adaption . . . . . . . . . . . . . . . . . . . . . . 89 

5.3.5 Framework . . . . . . . . . . . . . . . . . . . . . 89 

5.3.6 Zusammensetzung des Frameworks . . . . . . . . 90 

5.4 Implementation....................... 90 

5.4.1 Spezifikationselement . . . . . . . . . . . . . . . 92 


5.4.3 Adaption . . . . . . . . . . . . . . . . . . . . . . 94 

5.4.4 Zusammensetzung des Frameworks . . . . . . . . 95 

5.5 Adaption des Dienstes Netzberechnung . . . . . . . . . . 98 

5.5.1 Spezifikation . . . . . . . . . . . . . . . . . . . . 98 


5.5.3 Adaption . . . . . . . . . . . . . . . . . . . . . . 102 

5.5.4 Aufbau eines Lastfluss-Programms . . . . . . . . 107 

5.6 Adaption des Dienstes Netzaufbau . . . . . . . . . . . . . 108 

5.6.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . 108 

5.6.2 Problembeschreibung . . . . . . . . . . . . . . . . 110 

5.6.3 Analyse eines konkreten Tauschformates . . . . . 111 

5.6.4 Spezifikation . . . . . . . . . . . . . . . . . . . . 116 


5.6.6 Adaption . . . . . . . . . . . . . . . . . . . . . . 120 

5.6.7 Diskussion der Lösung............... 123 

5.7 Richtlinien fürdieBenutzung................ 124 

5.7.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . 124 

5.7.2 Anpassung durch den Klienten . . . . . . . . . . . 125 

5.7.3 Vorgehen bei Änderung eines Dienstes . . . . . . 127 

5.7.4 Erweiterung des Frameworks . . . . . . . . . . . . 127 

6 Fallstudien 129 

6.1 Lastfluss in kartesischen Koordinaten . . . . . . . . . . . 132 

6.1.1 Spezifikation der Ntor-Typen . . . . . . . . . . . . 132 

6.1.2 Spezifikation der Summengeber-Typen . . . . . . 135 

6.2 Lastfluss in polaren Spannungskoordinaten . . . . . . . . 135 



6.3 Wechselstrom-Lastfluss mit Austauschgebiet . . . . . . . 137 


IV INHALTSVERZEICHNIS 

6.3.1 Modellierung eines Austauschgebietes . . . . . . . 139 



6.4 Lineare Netzberechnung . . . . . . . . . . . . . . . . . . 141 

6.5 DC-Lastfluss ........................ 144 



6.6 Resultate .......................... 146 

6.6.1 Herstellung des Simulationsprogramms . . . . . . 146 

6.6.2 CPU-Zeiten und Speicherbedarf . . . . . . . . . . 147 

6.6.3 Charakteristik der Software-Entwicklung . . . . . 149 

7 Schlussbetrachtung 151 

7.1 Zusammenfassung ..................... 151 

7.2 Ergebnisse.......................... 153 

A Umformung der Ntor-Gleichungen 155 

A.1 Modellierung der Ntore . . . . . . . . . . . . . . . . . . . 155 

A.2 Kirchhoff-Knoten . . . . . . . . . . . . . . . . . . . . . . 156 

A.3 Darstellung aller Gleichungen eines Netzes . . . . . . . . 157 

B IEEE Common Data Format 159 

C Stichwortverzeichnis 163 


Kapitel 1 

Einleitung 

1.1 Motivation 

Simulation ist heute eine unerlässliche Technik für die Analyse von 

Energieversorgungssystemen, um seine aktuelle und zukünftige Leistungsfähigkeit, 

Zuverlässigkeit und Anpassungsmöglichkeiten an neue 

betriebliche Anforderungen zu überprüfen. Dabei werden aufgrund eines 

passenden Modells Vorgänge nachgebildet und auf dem Computer berechnet. 

Die Resultate verhelfen zu einem rascheren Verständnis eines Problems 

und ermöglichen eine Beurteilung von Hypothesen. Zur Zeit löst 

beispielsweise die Liberalisierung des Strommarktes eine Reihe von neuen 

Fragestellungen aus. 

Simulations-Systeme werden tendenziell grösser und komplizierter, da 

immer mehr Zusammenhänge zu anderen Wissensgebieten, wie z.B. der 

Ökonomie, zu berücksichtigen sind. Neben der Komplexität, die hauptsächlich 

von der Typenvielfalt und der Parametrierbarkeit herrührt, erschwert 

die fehlerträchtige Kodierung der Algorithmen Entwicklung und 

Wartung solcher Systeme. 

Als Folge davon wird es immer schwieriger, Software rechtzeitig auf 

den Markt zu bringen und innerhalb budgetierter Kosten zu entwickeln. 

Gemäss [1] liegen heute 90 % vom Entwicklungsaufwand von Produkten, 

die auf einem Rechner basieren, bei der Software. Deren Entwicklungszeitdauer 

bestimmt letztlich den Preis und den Zeitpunkt der Marktreife. 

Es ist schwierig geworden, diese neuen Anwendungen mit traditionellen 

Software- Entwicklungshilfsmitteln aufzubauen und zu unterhalten. In 

konventionellen Sprachen wie Fortran, Pascal oder C entwickelte Systeme 

weisen eine starke Koppelung zwischen den Datenstrukturen und den 

Algorithmen auf. Typischerweise erstreckt sich ein Algorithmus über ein 

1 


2 KAPITEL 1. EINLEITUNG 

Programm. Ein Algorithmus greift an vielen Stellen auf Variablen zu, deren 

Typen durch geeignete Datenstrukturen vorgegeben werden. Kleine 

Änderungen können sich daher auf ein ganzes Programm auswirken. Der 

Programmieraufwand ist nicht wie gewünscht proportional zur Änderung, 

sondern wegen der verteilten Abhängigkeiten eher proportional zur Grösse 

des Programms. Dieser unerfreulichen Situation kann man zwar mit Modularisierung 

und genormten Schnittstellen-Standards begegnen. Neben 

dem Zeit- und Koordinationsaufwand der Schnittstellen-Normierung erhebt 

sich aber stets die Frage, was denn ein Modul beinhalten soll. Damit 

Module allgemein verwendbar sind, tendieren sie dazu, eher klein zu 

sein. Unabhängig davon, ob die Module in konventionellem oder in objektorientiertem 

Stil entwickelt werden, entstehen daher oft zu feinkörnige 

Strukturen. Der sich darin bewegende Software-Entwickler ist gezwungen, 

an vielen Orten Entscheidungen zu treffen, wie er diese relativ vielen 

und kleinen Teile zusammensetzt und miteinander kommunizieren lässt. 

In diesen Entscheidungen liegen Fehlerquellen, welche die Qualität eines 

Produktes trotz einwandfreier Module beeinträchtigen. 

Neuere Ansätze aus dem Software-Engineering gehen diese Probleme 

an, indem sie Techniken bereitstellen, um grobkörnigere und dennoch flexible 

Module für eine Klasse von Problemen herzustellen. 

1.2 Stand der Technik 

Im Folgenden werden einige Lösungs-Ansätze aus der Literatur aufgeführt, 

welche einzelne oder mehrere der im Unterkapitel 1.1 dargestellten 

Probleme angehen und den Hintergrund der vorliegenden Arbeit bilden. 

Die objekt-orientierte Technik hielt bei den Energieübertragungssystemen 

etwa Ende der Achtzigerjahre Einzug. In [2] wurde bestätigt, dass 

die objekt-orientierte Technik die Flexibilität grosser Software-Systeme 

erhöht. Als besonderer Vorteil wurde erkannt, dass Änderungen innerhalb 

eines Objektes das restliche System nicht beeinflussen. Dies ist eine wesentliche 

Voraussetzung um das Problem der Komplexität der Software in 

den Griff zu bekommen. Als weiterer Vorteil wurde gesehen, dass Objekte 

gleichermassen physikalische Dinge und abstrakte Ideen in einheitlicher 

Art darstellen und dahinter liegende Details verstecken können, was die 

Arbeit des Software-Entwicklers wesentlich erleichtert. 

In [3] wurde die objekt-basierte Technik in einem graphischen Benutzer-Interface 

erprobt, was anfangs das klassische und besonders anschau- 


1.2. STAND DER TECHNIK 3 

liche Anwendungsfeld der objekt-orientierten Technik darstellte. Das Objekt 

wird unmittelbar durch ein graphisches Symbol am Bildschirm sichtbar, 

das man anklicken und dadurch dem dahinterliegenden Objekt Botschaften 

schicken kann. Dank der Objektmodellierung und der Vererbungseigenschaft 

ist es einfach, ein einheitliches Verhalten eines Benutzer- 

Interfaces zu erreichen, was auch für den Endbenutzer ein unmittelbarer 

Vorteil ist. 

In [4] wird die objekt-orientierte Technik auch in einer numerischen Berechnung 

angewendet, die speziell auf das Lastflussproblem zugeschnitten 

ist. Damit konnte das den ersten objekt-orientierter Simulationsprogrammen 

anhaftende Manko an Rechengeschwindigkeit beseitigt werden. Der 

wesentlicher Beitrag von [4] besteht aber darin, ein objekt-orientiertes Simulationsprogramm 

so konzipiert zu haben, dass es für einen bestimmten 

Bereich von Problemen wiederverwendbar wird. 

Bei der Modellierung des elektrischen Netzes besteht ein beträchtlicher 

Freiheitsgrad. Modellierung bedeutet grob gesagt, eine geeignete Menge 

von Objekten zu definieren. In [5] wird eine Modellierung einer Lastflussrechnung 

dargestellt, die sich strikte an physikalischen Objekten, wie 

z.B. Schalter, Leitungen, Transformatoren orientiert. Damit strebt man einerseits 

Unabhängigkeit von den Algorithmen an und stellt andererseits 

das Datenmodell durch eine natürliche und intuitiv einleuchtende Objektwahl 

verständlich dar. Diese anwendungsfreundliche und stabile Objektwahl 

geht allerdings auf Kosten erhöhter Rechenzeit. 

Die Abstraktionsfähigkeit der objekt-orientierten Technik wurde erkannt 

und in [6] ausgenutzt, um eine allgemeine Software-Plattform für 

Simulationsapplikationen in Netzen zu formulieren. Ein sogenannter generischer 

Behälter zur Speicherung und Berechnung von elektrischen Übertragungsnetzen 

wird in [6] vorgestellt. Die Wiederverwendung geschieht 

in diesem Ansatz dadurch, dass ein Software-Entwickler 1 vorgegebene 

Klassen dieses Behälters an seine Bedürfnisse anpasst. Er benötigt dabei 

objekt-orientierte Techniken, die in Kapitel 2 beschrieben sind, und ferner 

spezielle Spracheigenschaften der Zielsprache (C++) des Behälters. 

Das fehlerträchtige Kodieren von Elementen, die bei der Simulationsrechnung 

benötigt werden 2 , muss aber immer noch vom Klienten geleistet 

werden. 

In [7, 8, 9] ist erkannt worden, dass symbolische Rechnungssysteme 

1 In der vorliegenden Arbeit als Klient bezeichnet 

2 Bei der Lastflussrechnung: Jacobi- und Mismatchterme 



diese fehlerträchtige Arbeit automatisch ausführen können. Dabei wird 

das zu simulierende System in mathematischer Darstellung, typischerweise 

durch einen Satz von Gleichungen, vorgegeben. 

Aufgrund dieser Spezifikationen kann das in [7] vorgestellte, allgemein 

verwendbare Werkzeug Simulationen ausführen. Darin erlaubt das symbolische 

Verarbeiten der Spezifikationen des Klienten einen sehr hohen 

Grad an Anpassungsfähigkeit. Dies kostet aber andererseits viel Verarbeitungszeit, 

was insbesondere bei Programmen mit Echtzeitanforderungen 

zu Leistungsbegrenzungen führen kann. 

Ein etwas anderer Weg wird in [8, 9] vorgeschlagen. Das Simulationsproblem 

wird auch hier durch einen flexiblen Satz von Gleichungen 

baukasten-förmig vorgegeben. Die symbolische Berechnung verarbeitet 

diese Eingabe und erzeugt daraus einen Quelltext, der in einer numerischen 

Rechenumgebung zur effizienten Lösung von Gleichungssystemen 

abgearbeitet wird. 

Es bleibt noch das Problem bestehen, dem Klienten eine grobkörnigere 

und dennoch flexible Struktur zur Wiederverwendung anbieten zu können. 

Die Ansätze [4] und [6] gehen bereits in diese Richtung, indem sie ein Design 

von zusammenwirkenden und anpassbaren Objekten als generische 

Lösung für eine Reihe von Problemen vorsehen. Dies ist eine Möglichkeit, 

um ein Design einer Lösung zu beschreiben und wiederzuverwenden. Diese 

Technik wird in [10] in einem sogenannten Applikations-Framework 3 

ausserhalb der elektrischen Energieübertragung dargestellt. In [11] wird 

mit Hilfe der Framework-Technik ein Werkzeug für Unterhalt, Training 

und Dokumentationserstellung und Fehleranalyse für EMS instantiiert. 

Das Framework befreit den Klienten jedoch noch nicht vom fehlerträchtigen 

Kodieren von Elementen. Es braucht nochmals einen grösseren 

Rahmen, der die einzelnen Elemente (Software-Komponente und mathematische 

Spezifikation) in einer kohärenten Art zusammenbringt und ihre 

Konsistenz sicherstellt. In [12] und [13] wird dieser grössere Rahmen als 

Architektur bezeichnet und eingehend dargestellt. 

1.3 Ziel der Arbeit 

Das Ziel dieser Arbeit ist, den Klienten beim Herstellen neuer Simulations-Applikationen 

4 von elektrischen Energieübertragungssystemen zu un- 

3 Siehe Kapitel 2 

4 In der Arbeit als Applikation abgekürzt 


1.4. AUFBAU DER ARBEIT 5 

terstützen. Sie soll ihm helfen, neue Applikationen auf qualitativ hohem 

Niveau zu entwickeln. Dies bedeutet: 

• Erstellung von korrektem Code, insbesondere bei abgeleiteten Termen, 

• gute Rechenzeiteffizienz verglichen mit der Codierung von Hand und 

• Beibehalten der Eigenschaft der Schwachbesetztheit. 

Ferner sollen Konzepte gefunden werden, die dem Klienten helfen, neue 

Applikationen mit hoher Produktivität zu entwickeln. Dies bedeutet: 

• wiederverwendbare Lösung für eine wichtige Klasse von Simulationsproblemen 

in Netzen, 

• Leichte und schnelle Anpassung an neue Modelle, 

• Förderung der Transparenz, um den Entwicklungsprozess und die 

Bausteine verständlicher und leichter kommunizierbar zu machen, 

• Vereinfachte Umstellung auf eine neue Zielsprache. 

Dazu sollen Konzepte der objekt-orientierten Technik zusammen mit 

Erkenntnissen des Software-Engineerings und der Netzmodellierung benutzt 

werden, um den Software-Entwicklungsprozess zu beschleunigen. 

Das Produkt dieser Arbeit ist eine wiederverwendbare Software-Komponente 

und ein dazu passender Rahmen5 , wie dies in [14] zusammenfassend 

dargestellt ist. Innerhalb dieses Rahmens adaptiert der Klient diese 

Software-Komponente, um sie schliesslich in seiner Applikation einbauen 

zu können. Die Software-Komponente soll den Klienten von Design- und 

Programmierarbeit befreien, die er in vielen Simulationsprogrammen im 

Bereich der elektrischen Energieübertragung ansonsten erneut zu leisten 

hätte. Gemeint ist dabei die Klasse von Problemen, bei denen es vernetzbare 

Entitäten mit einem Verhalten gibt, das auf nicht-lineare Gleichungssysteme 

führt. 

1.4 Aufbau der Arbeit 

Diese Arbeit ist wie folgt gegliedert: Zuerst wird die Problematik beim 

Entwickeln neuer Simulations-Software dargelegt. Ferner werden einige 

bekannte Vorgehensweisen angeführt. 

5 Dies ist die in Kapitel 5 beschriebene Domänen-Architektur 



Kapitel 6 Kapitel 5 Kapitel 4 

Fallstudien Domänen-Architektur 

Framework 

Kapitel 2 

Konzepte des 

Software-Engineerings 

Kapitel 3 

Netzmodellierung 

Netzberechnung 

Abbildung 1.1: Kapitel und Beziehungen 

: A benutzt / benötigt B 

Das Kapitel 2 erläutert Begriffe und Konzepte des Software-Engineerings 

und insbesondere der objekt-orientierten Technologie. Im Kapitel 3 

wird die Netzberechnung und -modellierung nach dem Ntor-Ansatz und 

ein darauf basiertes objekt-orientiertes Netzmodell vorgestellt. Darauf 

bauen die beiden Hauptkapitel 4 und 5 auf. 

Das Kapitel 5 beschreibt den Rahmen zur Adaption und Wiederverwendung 

des Frameworks. Das Kapitel 4 beschreibt die Software- 

Komponente, die in dieser Arbeit als Framework bezeichnet wird. 

Es bildet den hart-codierten Kern der in dieser Arbeit formulierten 

Netzberechnungs-Software. 

Im Kapitel 6 wird gezeigt, wie die Software-Komponente an konkrete 

Simulationsprobleme aus dem Bereich der elektrischen Energieübertragungssysteme 

adaptiert werden kann. 

Abbildung 1.1 zeigt die Abhängigkeiten zwischen den Kapiteln. Damit 

ist ersichtlich, in welcher Reihenfolge Begriffe und Konzepte festgelegt 

und verwendet werden. Eine weitere Lesehilfe bietet ein Stichwortverzeichnis 

im Anhang dieser Arbeit. 

Diss.-ETH 12317 Diss.-ETH 12317 Diss.-ETH 12317 Diss.-E 

A 

B

Kapitel 2 

Konzepte des Software-Engineering 

2.1 Einleitung 

Die vielversprechenden Ansätze, um die Ziele der vorliegenden Arbeit zu 

erreichen, stammen aus dem Gebiet des Software-Engineerings. In Abbildung 

2.1 sind relevante Begriffe aus diesem Teilgebiet aufgezeigt. 

Seit Ende der Sechzigerjahre hat man in der Wiederverwendung bereits 

geschriebener Softwareteile grosses Potential gesehen, um Kosten 

und Aufwand bei der Entwicklung von Software einzusparen. Man erwartete 

signifikante Produktivitäts- und Qualitätsverbesserungen. 

Innerhalb des Software-Engineerings ist daher das Teilgebiet Wiederverwendung 

entstanden. Es beschäftigt sich neben anderen Aspekten mit 

der Frage, wie man wiederverwendbare Software herstellt. Es gibt viele 

verschiedene Techniken, wovon einige nie über das Stadium von Forschungsprototypen 

hinauskamen, weil ihre Anwendung in der Praxis zu 

kompliziert erschien. In [13] wurde 1994 festgehalten, dass die hohen Erwartungen 

an die Wiederverwendung von Software nicht auf der ganzen 

Linie erfüllt wurden. 

Es zeigte sich aber, dass die Wiederverwendung unter gewissen Einschränkungen 

den Erwartungen gerecht werden kann. 

Man hat erkannt, dass die Wiederverwendung innerhalb von Familien 

von ähnlichen Programmen gewinnbringend sein kann. Das Wissensgebiet 

des Domänen-Engineerings baut genau auf dieser Erkenntnis auf und konzentriert 

sich auf den Bau wiederverwendbarer Software innerhalb eines 

klar begrenzten Anwendungsgebietes, eben einer Domäne 1 . 

Der für diese Arbeit wichtige Beitrag des Domänen-Engineerings ist 

1 Eine Domäne ist laut [15] “a distinct functional area that can be supported by a class of software 

systems with similar requirements and capabilities.” 

7 


8 KAPITEL 2. KONZEPTE DES SOFTWARE-ENGINEERING 

Domänen- 

Modell 

benutzt 

Objekt-orientierte 

Technologie 

SW-Engineering 

benutzt 

ist Teilgebiet von 

Wiederverwendung 

Domänen- 

Engineering 


benutzt 

benutzt 

Domänen- 

Architektur 

hat 

Generisches 

Design 

ist ein 

Framework 

Legende: 

Alternativen 


A 

B 

andere Teilgebiete 


heisst: 

B ist Teilgebiet von A 

Abbildung 2.1: Begriffe aus der Software-Technologie 

die Erkenntnis, dass eine Familie von Software-Produkten mit Hilfe eines 

Domänenmodells 2 und einer Domänen-Architektur 3 formalisierbar ist. 

Beide Beiträge werden in diesem Kapitel dargestellt. 

Die objekt-orientierte Programmtechnik hat sich als hilfreich erwiesen, 

einerseits das Domänenmodell und andererseits das von der Domänen- 

Architektur geforderte generische Design zu beschreiben. 

2.2 Software-Wiederverwendung 

Unter Wiederverwendung versteht man ein Entwicklungsvorgehen, bei dem 

neue Applikationen auf bereits existierender Software aufgebaut werden, 

und das generell darauf abzielt, Codevervielfachung zu vermeiden, indem 

Gemeinsamkeiten in grundsätzlich ähnlichen Aufgaben systematisch genutzt 

werden. Dabei werden nicht nur Programm-Code, sondern mit steigendem 

Nutzen Programm-Design und Anforderungen wiederverwendet. 

Wiederverwendbarkeit ist keine inhärente Eigenschaft von Software. 

Gemeint ist daher nicht das ad-hoc Verfahren nach dem Muster von Copy- 

Paste-Modify. 

2Ein Domänenmodell ist laut [15] “a product of an analysis of a domain which provides a representation 

of the requirements of the domain.” 

3Eine Domänen-Architektur ist laut [15] “a generic, organizational structure or design for software 

systems in a domain.”

2.2. SOFTWARE-WIEDERVERWENDUNG 9 

Systematische Wiederverwendung muss geplant sein [16, 17]. Sie entsteht 

auch nicht einfach dadurch, dass z.B. eine bestimmte Programmiertechnik, 

wie die objekt-orientierte Technik angewendet wird. Unter systematischer 

Wiederverwendung versteht man eine Softwareentwicklung, die 

durch den geplanten Einsatz von Erzeugnissen des Domänen-Engineerings, 

wie dem Domänenmodell, der Domänen-Architektur und weiterer Software-Komponenten 

in aufeinanderfolgenden Phasen des Software-Engineering-Prozesses 

gekennzeichnet ist [15]. 

2.2.1 Erwartungen an die Wiederverwendung 

Von der Wiederverwendung verspricht man sich folgenden Nutzen: 

• Weniger Entwicklungs- bzw. Wartungsaufwand: Weniger Zeitbedarf 

und tiefere Kosten bei der Spezifikation, dem Design, der Codierung 

und Fehlersuche, da bereits eine entwickelte Software-Komponente 

verwendet wird. Je häufiger diese verwendet wird, und je grösser 

eine Software-Komponente ist, desto grösser ist der Nutzen. 

• Reduktion des Wartungungsaufwand: In [13] wird von einem Wartungsaufwand 

4 heutiger Software-System von 67 % ausgegangen. Es 

kann gezeigt werden, dass die gleichen Entwicklungsziele, die zur 

Verbesserung der Wiederverwendbarkeit führen, auch die Wartbarkeit 

und Portierbarkeit eines Software-Systems fördern [13]. 

• Erhöhung der Softwarequalität: Mehrfache Anwendung erhöht die 

Wahrscheinlichkeit, dass Fehler gefunden werden und zu einer laufenden 

Verbesserung einer Software-Komponente führen. 

2.2.2 Grundlegende Ansätze 

Auf der Stufe einer Software-Komponente unterscheidet man zwischen 

dem Black-Box-Ansatz und dem White-Box-Ansatz der Wiederverwendung. 

Beim Black-box-Ansatz werden grobkörnige und möglicherweise parametrierbare 

Komponenten ohne Änderungen in ein neues System eingebaut. 

Beim White-box-Ansatz werden feinkörnige und möglicherweise parametrierbare 

Komponenten mit Änderungen in ein neues System eingebaut. 

Der White-box-Ansatz ist flexibler. Er hat aber den Nachteil, dass wegen 

4 gemeint ist der Aufwand für die Fehlerbehebung und für Erweiterungen der Funktionalität 



der Feinkörnigkeit eine grössere Menge von Komponenten entsteht. Ferner 

müssen einem Klienten, der solche Komponenten einsetzt, nebst Angaben 

über die Schnittstelle weitere Informationen angegeben werden. Diese betreffen 

z.B. den Sichtbarkeitsbereich und die Bedeutung von Variablen und 

Funktionen innerhalb einer solchen Komponente. 

Ferner unterscheidet man zwischen horizontaler und vertikaler Wiederverwendung. 

Vertikale Wiederverwendung kennzeichnet die Wiederverwendung 

von Software-Komponenten innerhalb einer bestimmten Domäne. 

Neben dem Programmcode lassen sich auch die Spezifikation und das Design 

von Programmen auf einen neuen Anwendungsfall übertragen. In der 

vorliegenenden Arbeit liegt der Schwerpunkt daher auf der vertikalen Wiederverwendung. 

Horizontale Wiederverwendung ist unabhängig von der Domäne. Ein 

Beispiel dafür sind Klassenbibliotheken von allgemeinem Charakter, wie 

etwa die Dienste eines Betriebssystems, mathematische Funktionen oder 

graphische Benutzerschnittstellen. Horizontale Wiederverwendung wird 

heute verbreitet praktiziert. 

In der vorliegenden Arbeit kommen alle Ansätze der Wiederverwendung 

nebeneinander vor. Software-Komponenten mit domänen-unabhängigem, 

mathematischem Charakter folgen dem Black-Box-Ansatz. Hier liegt 

horizontale Wiederverwendung vor. Die Bausteine des Domänenmodells 

von Kapitel 3 hingegen müssen sehr flexibel konzipiert sein. Daher wird 

bei ihnen der White-Box-Ansatz angewendet. Die Simulations-Funktionalität 

wird als generisches Design beschrieben und in vertikaler Wiederverwendung 

genutzt. 

2.2.3 Hindernisse 

Die wesentlichen Hindernisse, die bei der Wiederverwendung auftreten 

sind: 

• Auf der Seite des Klienten: 

– Finden einer geeigneten Komponente 

– Verstehen einer Komponente 

– “Not invented here” Syndrom5 • Auf der Seite des Anbieters oder eines Entwicklungsleiters: 

5 Gemeint ist das Misstrauen, ein fremdes und ungenügend dokumentiertes Produkt zu verwenden, bei 

dem man nicht genau weiss, was es tut und welche Seiteneffekte es dabei produziert. 



– Schwierigkeit beim Herausfinden, welche Komponenten wiederverwendbar 

sind. Dies bedeutet, Gemeinsamkeiten in verschiedenen 

Anwendungen zu erkennen, zu klassifizieren und zu beschreiben. 

– Mangelnde Standardisierung der Komponenten 

– Fehlende Entwicklungswerkzeuge zur Herstellung wiederverwendbarer 

Komponenten 

– Kosten Nutzen-Frage: Rechtfertigung von Initialkosten und Mehraufwand 

für die Herstellung einer Komponente 

– Rechtliche Fragen, Schutz von geistigem Eigentum 

Eine Schwierigkeit einer wiederverwendbaren Komponente ist deren Abgeschlossenheit 

(Black-Box). Damit lässt sie sich nachträglich nicht problemlos 

an neue Anforderungen anpassen. Meyer [18] formuliert daher 

das Open-Closed-Prinzip, das folgende wünschenswerte Eigenschaften 

einer wiederverwendbaren Software-Komponente festhält: 

• Eine Software-Komponente ist offen, wenn sie nachträglich erweitert 

werden kann, ohne dass ihr Quelltext geändert werden muss oder existierende 

Klienten davon betroffen werden. Mögliche Erweiterungen 

sind das Hinzufügen von neuen Elementen zu Datenstrukturen oder 

das Hinzufügen von zusätzlichen Funktionen. 

• Eine Software-Komponente ist abgeschlossen, wenn sie mit einer 

klar definierten Schnittstelle in einer Bibliothek für die Wiederverwendung 

zur Verfügung gestellt wird. 

Diebeidenansichgegensätzlichen Wünsche werden deutlicher, wenn man 

zwischen Schnittstelle und Implementierung einer Software-Komponente 

unterscheidet. Der Klient möchte eine stabile d.h. abgeschlossene Schnittstelle 

zu Software-Komponenten. Als Anbieter wiederverwendbarer Software-Komponenten 

möchte man zulassen, dass die Schnittstellen, wie in 

Abbildung 2.2 dargestellt, von verschiedenen Klienten in verschiedenen 

Varianten implementiert werden können. Dabei soll es die Klienten nicht 

betreffen, wenn verschiedene Varianten aus einer benutzten Software-- 

Komponente gebildet werden. 



Klient 1 

ändert um 

Δ 

1 

Δ 1 

Wiederverwendbare Komponente 

keine Beeinflussung 

Klient 2 

ändert um 


Δ 2 

Klient 1 Klient 2 

Δ 2 

Abbildung 2.2: Anwendung des Open-Closed-Prinzips 

Kompositions 

basiert 

Programm-generierende 

Systeme 

Erzeugungs 

basiert 

Sprach Transformations 

basiert basiert 

Applikations- 

Generator 

Abbildung 2.3: Prinzipielle Vorgehensweisen zur Herstellung von Programmen nach [17] 

2.2.4 Techniken 

In [17] werden, wie in Abbildung 2.3 dargestellt, verschiedene Vorgehensweisen 

zur Herstellung von neuen Programmen durch Wiederverwendung 

unterschieden. Darin werden nicht nur Quelltext, sondern noch gewinnbringendere 

Teile wie Domänen-Wissen und Programmdesign wiederverwendet. 

In existierenden Systemen ist aber keine der genannten Vorgehensweisen 

in reiner Form umgesetzt. Die Systeme stellen eher Mischformen 

dar. 

Kompositions-basierte Systeme basieren auf der Wiederverwendung von 

atomaren Software-Komponenten (Black-Box-Ansatz). Solche Systeme 

benötigen Wissen, wie man eine passende Komponente für Teilaufgaben 

findet. Eine weitere Aufgabe besteht darin, diese Komponenten zu einem 

lauffähigen Programm zu verknüpfen. 

In erzeugungs-basierten Systemen ist es viel schwieriger, wiederverwendete 

Komponenten zu identifizieren. Das wiederverwendete Wissen


steckt in der Struktur des Programms, das neue Programme erzeugt. Ein 

primitiver Vertreter dieser Vorgehensweise ist das Programmgerüst, das 

von einem Klienten bei Bedarf angepasst wird. 

Sprach-basierte, generierende Systeme bauen auf einer wohldefinierten 

Sprachkonstruktion auf, welche eine Domäne beschreibt. Eine solche 

Sprache ist weit mehr als nur eine Befehlszeile zur Steuerung eines Programmgenerators. 

Ein wesentlicher Vorteil für den Klienten besteht darin, 

dass die Sprache von Einzelheiten der Implementation abstrahiert. Als besondere 

Herausforderung beim Bau solcher Systeme gilt es jedoch, eine 

effiziente Implementation der Sprache zu finden. 

Transformations-basierte Systeme bestehen grob gesehen aus einer Folge 

von Transformationen, welche eine Grundvariante einer Programmfamilie 

beschreibt. Ein Klient passt diese Grundvariante neuen Bedürfnissen 

an, indem er einige Transformationen ersetzt und die geänderte Folge von 

Transformationen erneut “abspielt”, um das neue Programm zu erzeugen. 

Applikations-Generatoren enthalten Muster, die beim Erzeugen spezifischer 

Instanzen eines Zielsystems wiederverwendet werden. Ein Muster 

stellt dabei das Gemeinsame der erzeugten Instanzen dar. Ein Muster 

ist wesentlich flexibler als eine atomare Software-Komponente beim 

kompositions-basierten Vorgehen. Der variable Teil einer Applikationsfamilie 

wird aus geeigneten Eingabe-Daten erzeugt und im Applikations- 

Programm eingebaut. Als Vertreter eines Applikations-Generators wird 

DRACO [19] eingestuft, wobei auch dieses System sprach- und transformations-basierte 

Eigenschaften enthält. 

Den vorgestellten Systemen ist gemeinsam, dass sie neben Quell-Code 

auch Domänenwissen und Programmdesign wiederverwenden, um daraus 

neue Programme zu erzeugen. Dazu muss unabhängig von der Technik 

stets ein System zueinander passender und teilweise voneinander abhängiger 

Elemente organisiert werden. 

Dies geschieht innerhalb einer zu erarbeitenden, spezifischen Architektur 

6 . 

6 Eine Architektur ist laut [15]: 

“1. a organizational structure of a system or asset 

2. the structure of components, their interrelationships, and the principles and guidelines governing their 

design and evolution over time” 



Domänen-Engineering 

Das Domänen-Engineering betreibt vertikale Wiederverwendung. Es beschränkt 

sich darauf, Software-Komponenten 7 zu bauen. Auch hier ist die 

Architektur als Beschreibungsmittel eines Systems von zentraler Bedeutung. 

In [12]: “We strongly believe that architecture is the enabling technology 

that brings together the elements (...) in a coherent approach”. Der 

Architektur-Begriff wird jedoch auf eine Domäne eingeschränkt. Es gelten 

die spezialisierten Begriffe Domänen-Architektur und Domänenmodell. 

Zentraler Ausgangspunkt für den Bau einer wiederverwendbaren Software-Komponente 

ist das Herausfinden eines Domänenmodells. Dies ist 

das Ergebnis einer Domänen-Analyse, bei der Gemeinsamkeiten und Unterschiede 

zwischen Systemen einer Domäne erfasst werden. Ein Domänen- 

Modell enthält folgende Angaben: 

• Gültigkeitsbereich und Funktionalität der Domäne 

• Information über die Entitäten 

• Faktoren, die zu Variationen führen 

Die Domänen-Architektur ist eine generische Struktur (Design), zur Organisation 

von Elementen eines Systems innerhalb einer Domäne. Eine 

Domänen-Architektur enthält: 

• die Struktur 

• die gemeinsamen Elemente 

• den Kommunikations-Mechanismus zwischen Elementen 

• die Richtlinien für die Benutzung und Weiterentwicklung der Domänen-Architektur 

Die Domänen-Architektur liefert daher einen Bezugsrahmen für die 

Herstellung von Software-Komponenten einer Domäne. 

Objekt-orientierte Technologie 

Wie einleitend bemerkt, reicht die objekt-orientierte Technologie nicht aus, 

um alleine eine systematische Wiederverwendung zu ermöglichen. Hingegen 

kann sie wesentliche Beiträge leisten: 

7 gemeint sind Programme oder Teile, die in Programmen eingebaut werden 


2.3. BEGRIFFE DER OBJEKT-ORIENTIERTEN PROGRAMMIERUNG 15 

konventionell objekt-orientiert Methoden 

Zugriffe 

Funktionen 

Daten 

ein Objekt: 


Zugriffe 

Attribute 

Abbildung 2.4: Funktionales und objekt-orientiertes Vorgehen 

• bei der Beschreibung eines Domänenmodells 

• bei der Beschreibung eines Programm-Designs mit Hilfe eines objekt-orientierten 

Frameworks (siehe Seite 21) 

Die wichtigste Errungenschaft der objekt-orientierten Programmierung ist 

die direkte Unterstützung des Open-closed-Prinzips durch entsprechende 

Sprachkonstrukte [10]. Die Begriffe und wesentliche Beiträge der objektorientierten 

Technologie werden im Kapitel 2.3 dargestellt. 

2.3 Begriffe der objekt-orientierten Programmierung 

In diesem Unterkapitel werden die Grundbegriffe der objekt-orientierten 

Programmierung wie Objekt, Klasse, Methode und Attribut festgelegt, um 

einen einheitlichen Sprachgebrauch sicherzustellen. Es stellt keine umfassende 

Einführung in das Gebiet der objekt-orientierten Entwicklung dar. 

Eine umfassende Einführung bietet [20]. 

2.3.1 Objekt 

In der Abbildung 2.4 wird der grundsätzliche Unterschied zwischen der 

funktionalen und der objekt-orientierten Vorgehensweise dargestellt. Neben 

den unterschiedlichen Namen an sich gleichartiger Elemente fällt ihre 

unterschiedliche Anordnung auf. So klein dieser Unterschied auch erscheinen 

mag, so gross sind die Auswirkungen, wie weiter unten noch gezeigt 

wird. Eine wichtige Änderung ist, dass eine Menge von Funktionen, 

Daten und Zugriffen in der objekt-orientierten Welt immer innerhalb eines 

Objekt zusammengefasst wird. Software-Systeme bestehen beim objekt-orientierten 

Vorgehen daher stets aus einer Menge interagierender Objekte. 

Dabei gilt die in Tabelle 2.1 dargestellte Begriffs-Korrespondenz:


funktional objekt-orientiert 

Funktionen Methoden 

Daten Attribute 

Tabelle 2.1: Begriffs-Korrespondenz 

Die Zugriffe zwischen Funktionen und Daten werden dabei gewissermassen 

in das Innere eines Objektes gestülpt und sind ausserhalb eines Objektes 

nicht mehr sichtbar. 

Beim funktionalem (konventionellem) Vorgehen liegt der Schwerpunkt 

auf der Spezifikation und Dekomposition der Systemfunktionalität. Dieser 

Ansatz mag als der effektivere Weg erscheinen, ein gewünschtes Ziel 

zu implementieren. Das resultierende System ist aber in der Regel anfälliger 

für umfangreiche Restrukturierungen, falls es an neue Anforderungen 

anzupassen ist. 

Bei der objekt-orientierten Vorgehensweise zielt man hingegen zuerst 

darauf ab, Objekte einer Anwendungs-Domäne zu identifizieren, und diese 

erst später mit den passenden Methoden und Attributen auszustatten. 

Obwohl dies ein Umweg zu sein scheint, hält die objekt-orientierte Software 

einem Wechsel von Anforderungen besser stand. Dies hat damit zu 

tun, dass die Objekt-Findung im grösseren Rahmen einer Anwendungs- 

Domäne erfolgt, und nicht auf der Ebene einzelner, schnellebiger Funktionen 

[20]. 

Objekte stellen eigenständige Einheiten mit einer inneren Struktur dar. 

Einheiten können sein: elektrische Betriebsmittel, Fensterflächen, Dinge 

von reeller oder abstrakter Natur, jedoch mit einer klar definierbaren Rolle 

innerhalb einer Anwendungs-Domäne. Die innere Struktur wird durch die 

Implementation der Methoden, der Attribute und ihrer Zugriffe bestimmt. 

Jedes Objekt hat eine Identität und ist dadurch unterscheidbar. So sind 

z.B. zwei Schafe mit haargenau dem gleichen Aussehen dennoch zwei individuelle 

Schafe. Der Begriff Identität bezeichnet die fundamentale Eigenschaft 

der Existenz eines Objektes und hat nichts mit seinen Eigenschaften 

zu tun. 

Ferner hat ein Objekt ein Verhalten. Es reagiert auf bestimmte Botschaften 

(siehe Kapitel 2.3.3) in einer bestimmten Weise, indem es z.B. 

seinen eigenen Zustand ändert und möglicherweise Aktionen anderer Objekte 

auslöst. 


2.3. BEGRIFFE DER OBJEKT-ORIENTIERTEN PROGRAMMIERUNG 17 

2.3.2 Klassen 

Unter einer Klasse wird in der vorliegenden Arbeit immer ein Stück Quelltext 

der verwendeten Programmiersprache (C++) verstanden. Die Klasse 

ist eine Beschreibung von typgleichen Objekten. Eine Klassenbeschreibung 

enthält daher sowohl die innere, verborgene Struktur eines Objektes 

als auch die Reaktionsfähigkeit durch die Angabe der Schnittstelle seiner 

Methoden. Zur Programmlaufzeit ist die Klasse daher eine Art Objektfabrik, 

aus der beliebig viele Objekte eines gleichen Typs instantiiert werden 

können. 

Man beachte, dass sich bei gewissen Programmsprachen, wie z.B Eiffel 

oder Smalltalk, die Frage erhebt, inwiefern eine Klasse selber wieder eine 

Instanz, also ein Objekt ist. Dies ist grundsätzlich dann der Fall, wenn 

der Quelltext einer Objektbeschreibung selbst ein generiertes Produkt ist. 

Dieser Fall tritt auch bei der vorliegenden Arbeit auf. 

Eine spezielle Klasse ist die abstrakte Klasse. Aus ihr werden nie direkt 

Objekte erzeugt. Sie ist dazu angelegt, ihre Substanz an weitere abgeleitete 

Klassen zu vererben und damit zu konkretisieren. Die Substanz einer 

abstrakten Klasse besteht aus abstrakten Methoden, die leer und zum Überschreiben 

gedacht sind. Durch eine solche Gruppe von Methoden lässt sich 

eine Menge von Botschaften festlegen, die von Objekten verstanden wird. 

Damit lassen sich standardisierte Protokolle festlegen, die einen wesentlichen 

Bestandteil eines Design bilden, weil dadurch die Kommunikation 

zwischen Objekten formalisierbar ist. Abstrakte Klassen sind daher an der 

Spitze von Klassenhierarchien zu finden. 

2.3.3 Methoden 

Um die Fähigkeiten eines Objektes zu nutzen, schickt man ihm Botschaften. 

Damit wirkt man von aussen auf ein Objekt ein und stösst eine Aktion 

im Objekt an. Dies wird programmtechnisch dadurch realisiert, dass 

eine Methode eines existierenden Objektes aufgerufen wird. Ein Methodenaufruf 

umfasst neben einem gewohnten Prozeduraufruf mit optionalen 

Übergabeparametern auch einen Identifikator des Objektes. Dies ist eine 

Variable, deren Wert vom System zur Laufzeit berechnet wird. 

Dabei kann das Objekt nur ihm bekannte Methoden ausführen. Das 

Objekt kennt diejenigen Methoden, die in seiner eigenen Klasse oder einer 

Klasse definiert sind, von der die Methode geerbt wird. Die Ausführung 

der Methode kann zu weiteren Methoden-Aufrufen und zur Änderung des 



inneren Zustandes eines Objektes führen. 

2.3.4 Attribute 

Dies sind die im Innern eines Objektes verborgenen Daten. Diese können 

Platzhalter für Eigenschaften des Objektes sein, die es näher beschreiben. 

Neben Standard-Typen sind auch Objekte von einer anderen oder der eigenen 

Klasse denkbar. 

Typischer- und sinnvollerweise kann ein Benutzer eines Objektes die 

Attribute nicht direkt manipulieren, sondern nur über die dafür vorgesehenen 

Methoden. 

Die Speicherwirkung der Attribute ermöglicht einem Objekt, einen Zustand 

und ein Gedächtnis zu haben. Die Speicherwirkung hält nicht länger 

an als das Objekt existiert. 

2.4 Objekt-orientierte Konzepte 

Die Fähigkeit abgeleitete Klassen zu bilden, Eigenschaften auf diesem intuitiv 

natürlich empfundenen Weg zu vererben sowie die dynamische Bindung 

sind weitere Schlüsselelemente für den Bau von wiederverwendbarer 

Software. 

Die Datenabstraktion und die Kapselung durch Klassen sind die wichtigsten 

Beiträge für eine einfache und eine durch das objekt-orientierte Vorgehen 

elementar unterstützte Modellierung. Eine wichtige Konsequenz ist, 

dass grundsätzlich keine Lücke zwischen Modellierung und Implementierung 

entsteht, die zu schwer verständlichen Inkonsistenzen zwischen Design 

und Implementation führen kann. Solche Lücken lassen sich bei der 

funktionalen Programmierung nur durch guten Kommentar überbrücken. 

In diesem Unterkapitel werden die wichtigsten Paradigmen der objektorientierten 

Programmierung zusammengestellt. In diesem Unterkapitel 

werden Konsequenzen für den Bau von wiederverwendbarer Software aufgezeigt, 

die sich aus dem Objekt-Modell ergeben. 

2.4.1 Kapselung 

Wie bereits in Abbildung 2.4 angedeutet, verbergen Objekte ihre innere 

Struktur. Unter innerer Struktur werden die Attribute und die Implementation 

der Methoden verstanden. Soll auf ein Objekt zugegriffen werden, 


2.4. OBJEKT-ORIENTIERTE KONZEPTE 19 

Zugriff nur auf 

Methoden des 

Objektes 

Zugriff auf Attribute 

nicht möglich 

MeinBildschirm 

(Klasse Bildschirm) 

Methoden: 

Öffnen 

Schliessen 

Originalgrösse 

Zoom 

ZeichneRahmen 

ZeichneInhalt 

AllesZeichnen 

Attribute: 

links 40 

rechts 140 

oben 10 

unten 100 

Wirkung der Klasse: 

Abbildung 2.5: Abstraktion durch Kapselung 

geschieht dies stets durch das Schicken einer Botschaft, in der dem Objekt 

nur mitgeteilt wird, was es zu tun hat. Objekte erledigen dann Aufgaben 

prinzipiell in eigener Verantwortung. Sie lassen sich vom Aufgabensteller 

nicht aufzwingen, wie sie eine Aufgabe zu erledigen haben. Man kann den 

Objekten nur sagen, was sie zu tun haben. Diese Fähigkeit zur Abstraktion 

hilft dem Klienten, komplexe Systeme in kleinere Teile zu zerlegen. 

Er kann sich darauf beschränken, von den Objekten nur das kennenzulernen, 

was sie ausführen, und nicht noch, wie sie es tun. Das Mittel, das 

die Abstraktion durchsetzt ist die Kapselung. Abbildung 2.5 zeigt, wie die 

Kapselung funktioniert. Wie in der biologischen Welt die Zellmembrane 

den Zellkern von allen chemischen Signalen der Aussenwelt abschirmt, 

ausser denjenigen Signalen, welche die Zellmembran versteht, verhindert 

die Kapsel eines Objektes, dass äussere Programmaktivitäten in irgendwelche 

Speicherzellen eines Objektes hineinschreiben können und dadurch 

das Objekt gefährden. Anderseits lässt die Kapsel Zugriffe auf die Methoden 

des Objektes zu. In Abbildung 2.5 ist eine stark vereinfachte Instanz 

einer Bildschirm-Klasse aufgezeigt. Das Objekt versteht einen Methodenaufruf 

“Öffnen”. Es veranlasst darauf, die im Bild rechts gezeichnete Darstellung 

auf einem Bildschirm auszugeben. Die einzige Möglichkeit um 

die Attribute für die Koordinaten des geöffneten Fensters zu ändern, besteht 

darin, die Methoden “Zoom” oder “Originalgrösse” aufzurufen, und 

entsprechende Parameter zu übergeben. Das Objekt lässt einen direkten 

Zugriff auf seine Attribute nicht zu. Dadurch werden zufällige oder unkorrekte 

Änderungen verhindert, was hier zur Folge hätte, dass solchermassen 

geänderte Attribute mit dem zugrundeliegenden Fenstersystem unver- 



M 

A 

Basis 

Abgeleitet 

ΔM 

Δ A 

Methoden 

Attribute 

Symbol 

für Vererbung 

Abbildung 2.6: Vererbungsbeziehung 

träglich würden, oder der Inhalt ausserhalb seines Fensters irgendwo auf 

dem Bildschirm zu liegen käme. 

2.4.2 Vererbung 

Ein wichtiges Konzept der objekt-orientierten Programmierung ist die Vererbung. 

Mit Hilfe dieses Konzeptes lassen sich neue Klassen definieren, 

die auf einer existierenden Klasse aufbauen. Es muss dann nur noch die 

Differenz zu einer gewünschten inneren Struktur einer Klasse (Methode 

und Attribute) definiert werden. Die bereits existierende Klasse wird als 

Basis- oder Vorgängerklasse bezeichnet. Die neue Klasse ist die abgeleitete 

Klasse. In Abbildung 2.6 ist eine solche Vererbungsbeziehung dargestellt. 

Darin ist die Basisklasse mit den Methoden M und den Attributen 

A ausgestattet. Die abgeleitete Klasse erbt alle Methoden und Attribute 

seiner Vorgängerklassen. Die abgeleitete Klasse kann damit die Funktionalität 

der Vorgängerklassen erweitern und an neue Bedürfnisse anpassen, 

indem 

• neue Attribute hinzugefügt werden AAbgeleitet = A ∪ ΔA 

• neue Methoden hinzugefügt werden MAbgeleitet = M ∪ ΔM 

• eine geerbte Methode M durch eine andere Implementation ersetzt 

wird: MAbgeleitet = ΔM. Dies wird auch als Überschreiben einer Methode 

bezeichnet. 

• eine geerbte Methode erweitert wird. Dies geschieht z.B. dadurch, 

dass im Code von ΔM die Methode M aufgerufen wird. 


2.5. OBJEKT-ORIENTIERTES FRAMEWORK 21 

Von Mehrfachvererbung spricht man, wenn eine abgeleitete Klasse mehrere 

Vorgängerklassen hat. 

Vererbung fördert die Wiederverwendung von Methoden und Attributen 

und damit von Code. Gemeinsamer Code kann in einer gemeinsamen 

Basisklasse eingebracht und allen Erben zur Verfügung gestellt werden. 

2.4.3 Polymorphismus 

Polymorphie ist die wichtige Fähigkeit, verschiedene Implementationen 

hinter einem gleichen Namen verbergen zu können. Dies wird mit einem 

Mechanismus (dynamische Bindung) realisiert, der erst zur Programmlaufzeit 

entscheidet, ob und welche Methode eines Objektes aufzurufen 

ist, um diesem eine bestimmte Botschaft mit einem bestimmten Namen 

zu schicken. Daher kommt die Polymorphie erst beim Verschicken von 

Botschaften zum Tragen. 

Eine Methode, die beispielsweise die Matrix-Elemente addiert, wird 

korrekt arbeiten, solange alle Elemente der Matrix die Botschaft “Addiere” 

verstehen, egal aus welcher Klasse die zu summierenden Elemente stammen. 

In Systemen ohne Polymorphie wären Fallunterscheidungen notwendig, 

um je nach Typ des Matrix-Elementes und möglicherweise des aktuellen 

Typs der bisherigen Summe eine passende Prozedur für die Addition 

aufzurufen. Die Gefahr für den Software-Entwickler besteht dabei darin, 

dass er einen Fall vergisst. Ferner ist es schwierig, eine solche Software 

wiederzuverwenden, da kleine Änderungen dem System sehr wahrscheinlich 

weitere Fälle aufbürden. Da die Fallunterscheidungen über das ganze 

System verstreut sind, wird es ebenso verstreute Modifikationen bedingen, 

ehe das System wiederverwendet werden kann. 

Polymorphie vereinfacht daher die Kommunikation unter Objekten ganz 

erheblich. Ferner erlaubt es dem Software-Entwickler, eine eigene Version 

einer Klasse zu erzeugen, diese wieder in das System einzubauen und an 

der Stelle des Originals in Betrieb zu nehmen. 

2.5 Objekt-orientiertes Framework 

Die in Bibliotheken gesammelten Klassen sind in vielen Fällen nützlich 

und sehr flexibel, haben aber folgende Nachteile: 



• Vielzahl von Klassen: In grossen Bibliotheken müssen zuerst passende 

Klassen für einen bestimmten Anwendungsfall gefunden werden. 

Es kann für einen Klienten schwierig sein, ohne konzeptionelle 

Dokumentation der Klassenbibliothek herauszufinden, wofür die einzelnen 

Klassen gedacht sind. Noch schwieriger und gefährlicher ist 

es, in diesem Fall eigene Änderungen und Ergänzungen anzubringen. 

• Beziehungen zwischen den Klassen: Die Kommunikation und die 

Beziehungen zwischen den Klassen sind nach wie vor vom Klienten 

zu programmieren. Er legt dabei fest, wann welche Botschaft an welches 

Objektes zu schicken ist. Dies zwingt einen Klienten bei komplexeren 

Anwendung immer wieder, eigene Lösungen für die gleichen, 

grundlegenden Probleme zu finden. Selbst wenn Klienten dafür 

die gleichen Klassen wählen, machen die vielen, leicht abweichenden 

Entscheidungen den Code der Applikationen genügend unterschiedlich, 

um das gemeinsame Design nicht mehr so einfach zu erkennen 

und wiederverwenden zu können. 

Daher versucht man das Prinzip Kapselung auf einer höheren Stufe anzuwenden, 

um Code und Design von Lösungen innerhalb einer grösseren 

Einheit zu integrieren und wiederzuverwenden. Diese nächst höhere Abstraktionsebene 

erreicht man mit Hilfe eines Frameworks. 

2.5.1 Begriff und Funktion 

Johnson [21] definiert ein Framework wie folgt: “ A framework is a set 

of classes that embodies an abstract design for solutions to a family of related 

problems”. Die Grundaufgabe des Frameworks besteht also darin, 

ein wiederverwendbares Design einer bestimmten Problemstellung zu beschreiben. 

Dabei wird dieses wiederverwendbare Design durch den Code 

des Frameworks beschrieben. Dieser Code legt folgende Elemente fest: 

1. Die Menge der Klassen 

2. Die standardisierten Protokolle: In abstrakten Basisklassen werden 

Mengen von Methoden festgelegt, welche die Protokolle für die 

Kommunikation unter den Framework-Klassen definieren. 

3. Die Erweiterungsstellen: Das Framework verknüpft eine Menge 

von Klassen. Ein Teil dieser Klassen und/oder Methoden bedarf weiterer 

Konkretisierung, um das innerhalb der Familie von verwandten 

Problemstellungen unterschiedliche Verhalten zu definieren. 



Rückmeldung 

1 

Domänen-Wissen 

Domänen-Engineering 

Unterstützung des 

Applikations-Engineering 

Applikations-Engineering 

Geschäfts- oder 

Forschungsziele 

Anforderungen 

Produkt für 

Endbenutzer 

Abbildung 2.7: Durch Wiederverwendung gesteuerter Software-Engineering Prozess 

2.5.2 Entwicklungsvorgang 

Die Entwicklung eines Frameworks wird als eine schwierige Aufgabe erachtet 

[12]. Sie benötigt das Wissen eines Experten einer bestimmten 

Domäne. Das Aufwendige dabei ist die Erstellung eines Domänenmodells. 

Dieses ist wiederum die Grundlage für den Entwurf des Frameworks. Das 

Domänenmodell ist das Ergebnis einer Domänen-Analyse, in deren Verlauf 

eine oder mehrere wissenschaftliche Theorien einer Domäne zu formalisieren 

sind. 

Frameworks entstehen meist Bottom-up durch Konsolidierung von Erfahrung, 

die bei der Entwicklung einer Lösung für ein spezielles Problem 

gefunden wurde [10]. Dies geschieht innerhalb eines iterativen Entwicklungsprozesses, 

wobei das Framework in konkreten Anwendungen erprobt 

wird. Die dabei gewonnenen Erfahrungen fliessen in das Framework zurück. 

Der Entwicklungsprozess von Frameworks wird noch nicht von objekt-orientierten 

Analyse- und Entwurfswerkzeugen unterstützt. 

Die Entwicklung eines Frameworks kann durch den in Abbildung 2.7 

aufgezeigten Software-Engineering Prozess in einem grösseren Zusammenhang 

dargestellt werden. Dieser Prozess wurde von dem Software 

Productivity Consortium [12] vorgeschlagen. Er entspricht prinzipiell 

dem Ausreifprozess des Frameworks. Dem Domain-Engineer entspricht 

der Entwickler des Frameworks. Das Framework soll den Applikations- 

Entwickler darin unterstützten, Applikationen rascher und mit grösserer 

Qualität zu entwickeln. Der Applikations-Engineer, der in dieser Arbeit 

als Klient bezeichnet wird, ist derjenige, der das Framework in seiner An- 


2


Framework 

GetAElem(..) 

in MeinNtor 

überschreibt 

GetAElem(..) in 

VNtor 

VNtor 

GetAElem(..) 

MeinNtor 

GetAElem(..) 

vom Klienten durch Ableitung definierte Erweiterungen 

Abbildung 2.8: Funktionsweise eines Frameworks 

Programmfluss 

wendung einbaut und damit in eher traditioneller Weise Software-Produkte 

für einen Endbenutzer erstellt. In einem Forschungsumfeld ist der Klient 

oft selber Endbenutzer. 

Der durch Wiederverwendung gesteuerte Software-Engineering Prozess 

ist dadurch gekennzeichnet, dass es vom Klienten eine Rückkopplung zum 

Framework-Entwickler gibt. Die Kommunikation zwischen diesen Akteuren 

ist entscheidend. Das Verbessern und Erweitern des Frameworks ist in 

diesem iterativen Prozess möglich, solange der Klient dies benötigt. 

In [12] werden Erfahrungen mit diesem Prozess dargestellt, die bei der 

Produktion von Software für Flugsimulatoren gemacht wurden. 

2.5.3 Anwendung 

Kann ein Klient bei seiner Problemstellung auf einem Framework aufbauen, 

so ist bereits ein Teil der Entwurfsarbeit vom Framework-Entwickler 

erbracht worden. Der Klient benutzt ein Framework, indem er an den dafür 

vorgesehenen Stellen eigene Klassen ableitet. Der Klient überschreibt 

Methoden und ändert damit das vom Framework vorgegebene Standard- 

Verhalten. In Abbildung 2.8 wird die Anpassung eines Frameworks an 

einem einfachen Beispiel aufgezeigt. Die Klasse VNtor sei eine Klasse 

des Frameworks, die dazu angelegt ist, vom Klienten in einer abgeleiteten 

Klasse, hier MeinNtor, konkretisiert zu werden. Der Klient liefert eine 

eigene Version zu der Methode GetAElem(..), um dieser Methode ein 

spezielles Verhalten zu geben. Man beachte aber, dass GetAElem(..) unabhängig 

von den Änderungen des Klienten vom Framework zur geeigneten 

Zeit aufgerufen wird. Diese Art der Wiederverwendung ist in Kapitel 



2.2.2 als “White-Box-Ansatz” klassifiziert worden. Dem Vorteil der Flexibilität 

steht ein erhöhter Lernaufwand gegenüber. Obwohl die abgeleiteten 

und zu konkretisierenden Klassen häufig klein und einfach sind, muss der 

Klient doch wissen, wie die überschriebenen Methoden aufzubauen sind. 

Ferner kann die Menge der zu konkretisierenden Klassen gross werden, 

und eine zusätzliche Erschwernis im Lernprozess des Klienten darstellen. 

In [22] werden folgende Vorteile des Frameworks aufgeführt: 

1. Weniger Code zu schreiben: Das Framework enthält bereits Design- 

Entscheidungen und Quell-Code des Programms. 

2. Zuverlässiger und robuster Code: Der vom Framework geerbte Code 

ist bereits getestet und im Framework richtig eingebaut. 

3. Einheitlicher und modularer Code: Wiederverwendeter Code fördert 

die Einheitlichkeit und das Herausarbeiten der Gemeinsamkeiten 

zwischen Programmen, unabhängig vom Programm-Entwickler. Der 

Einsatz von Frameworks vereinfacht die Aufteilung eines Programms 

in kleine Stücke. 

4. Generische Lösung, für verwandte Probleme wiederverwendbar: 

Der Umgang mit Frameworks bewirkt beim Klienten, dass er für seine 

Probleme weniger eine spezielle sondern eher eine generische Lösung 

sucht. Daraus könnte sogar selbst wieder ein Framework entstehen. 

5. Vereinfachte Integration von verwandten Programmen: Da Programme, 

die auf dem gleichen Framework aufbauen, nicht nur den 

gleichen Code, sondern auch die gleichartige Struktur aufweisen, verstehen 

Klienten die an ähnlichen Aufgaben arbeiten, gegenseitig ihre 

Programme besser. Ferner ist es wahrscheinlicher, dass die Zusammenarbeit 

ihrer Programme gelingt. 

Der Einsatz von Frameworks erlaubt dem Softwareentwickler, Nutzen 

aus bereits eingebauten, und teilweise komplexen Beziehungen zwischen 

Objekten zu ziehen. Ein wesentlicher Vorteil dabei ist, dass der Softwareentwickler 

nicht alle Einzelheiten dieser Beziehungen verstehen muss. 

Frameworks wurden schon verschiedentlich in Systemen für Energieversorgung 

(EMS) eingesetzt. Anfangs geschah dies insbesondere bei den 

graphischen Benutzersystemen. In [11] wird der Einsatz eines objekt-orientierten 

Frameworks für Unterhalt und Dokumentation von EMS beschrieben. 




Kapitel 3 

Netzmodellierung und Netzberechnung 

In diesem Kapitel werden die Anforderungen an das Domänenmodell betrachtet. 

Dazu wird Wissen gesammelt und im Domänen-Modell formalisiert. 

Das Resultat ist ein Modell für einen bestimmten Ausschnitt aus der 

realen Welt. Das Modell zielt auf einen Anwendungsbereich ab, für den 

ähnliche Softwaresysteme (Applikationen) gebaut werden. Dieser Bereich 

ist die Welt von vernetzbaren Entitäten mit Verhalten, dass durch nichtlineare, 

simultane Gleichungen beschreibbar ist. 

Die Beschreibung des Modells enthält die folgenden Angaben: 

• Gültigkeitsbereich und Leistungen des Domänenmodells 

• Information über die Entitäten 

• Faktoren, die zu Variationen führen 

Abschliessend wird ein Beispiel betrachtet, bei dem eine einfache Anordnung 

im Domänenmodell identifiziert wird. 

3.1 Domänenanalyse 

In diesem Unterkapitel wird der Gültigkeitsbereich und die Grenzen der 

Domäne festgelegt, indem die wichtigen Funktionen und Merkmale der 

Domäne beschrieben werden. Dabei wird beschrieben, was getan wird, 

nicht wie. Die wichtigen Funktionen und Fähigkeiten einer Domäne werden 

als Anforderungen einer Domäne bezeichnet. Die Beschreibung der 

Anforderungen ist nicht nur für den Entwickler des Domänenmodells wichtig. 

Sie enthält ausserdem die Information, die ein Klient benötigt, um 

dieses Modell aufzufinden und auf seine Eignung zu prüfen. 

27 


28 KAPITEL 3. NETZMODELLIERUNG UND NETZBERECHNUNG 

Alle Anforderungen einer Domäne 

R 1 

M 1 

R 2 

R 3 

M 2 

Abbildung 3.1: Grundsätzliche Problematik beim schrittweisen Modellieren 

Die Festlegung der Anforderungen sollte vor der Domänen-Modellierung 

erfolgen. In Abbildung 3.1 sind die Konsequenzen einer iterativen 

Modellierung veranschaulicht. Darin werde zunächst eine Teilmenge R1 

der Anforderungen modelliert. Dann ist das gefundene Modell M1 teilweise 

hinfällig, wenn neue Anforderungen zu modellieren sind. 

Andererseits ist es eine anerkannte Tatsache, dass sich Modelle nur 

schrittweise entwickeln lassen. Diese grundsätzliche Problematik bei der 

iterativen Modellierung wurde im Verlaufe dieser Arbeit ebenfalls bestätigt. 

Der objekt-orientierte Programmieransatz ist in dieser Phase sehr hilfreich, 

da Modellierung und Programmdesign zusammenfallen. Damit kann das 

Modell bereits nach kurzer Zeit eingesetzt und getestet werden. 

3.1.1 Lastfluss-Applikation 

Die Lastfluss-Rechnung ist ein typischer, stabiler und gut verstandener 

Vertreter der Probleme, die in die Domäne der nichtlinearen Systeme gehören. 

Die genaue Bestimmung des Betriebszustandes eines elektrischen 

Energieübertragungssystems ist eine zentrale, jedoch nicht neue Aufgabe, 

die im Betrieb und bei der Planung solcher Systeme sowie als Teilaufgabe 

bei Marktsimulations-Szenarien immer wieder zu lösen ist. Die typischen 

Fragen lauten: 

• Wie sieht das Spannungsprofil an den Netzknoten bei einer bestimmten 

Belastung aus? 

• Welche Belastungen (Leistungen, Ströme) treten in den Betriebsmitteln 

auf? 


M 3 

?

3.1. DOMÄNENANALYSE 29 

Entität Bedingungen Typ aus [23] 

PQ-Last P und Q sind Parameter 0 

PQ-Gen V = Vmin ...Vmax 1 

P und Q sind Parameter 

PV-Gen Q = Qmin ...Qmax 2 

P und V ist Parameter 

Slack-Knoten V und Φ sind Parameter 3 

P und Q sind unbegr. Vars 

Tabelle 3.1: Knoten-Typen 

Eine kompakte und präzise Darstellung von Lastfluss-Anforderungen 

findet man implizit in der Beschreibung von Datenformaten, in denen beteiligte 

Personen eine gemeinsame Sprache festlegen. Diese Datenformate 

müssen präzise und vollständig sein, da sie auch für den Computer lesbar 

sind. 

Dafür ist ein verbreitetes Datenformat [23] ausgewählt worden. Das 

Domänenmodell soll in diesem Format beschriebene Netze für den Lastfluss 

abbilden können. 

3.1.2 Modellierung von Netzelementen 

Die Datenvorgabe für eine Lastfluss-Rechnung geschieht mit Hilfe von 

speziellen Datentypen, die meistens von einem Knoten-Zweig basierten 

Netzmodell ausgehen. Ein repräsentativer Satz solcher Typen ist in [23] 

dargestellt. Die in Klammer stehenden, englischen Begriffe stammen aus 

[23]. Verschiedene Teile der vorliegenden Arbeit beziehen sich auf diese 

Typen. Die Typvielfalt und ihre Eigenschaften legen den Variationsbereich 

fest, der vom Domänenmodell zu bewältigen ist. 

Knoten-Typen 

Die Knoten-Typen (Buses) zeichnen sich durch einen elektrischen Anschluss 

aus. Sie entsprechen einem Knoten im zugrundeliegenden Knoten- 

Zweig-Modell. Die Typen unterscheiden sich in zusätzlichen Randbedingungen 

in den Knoten. Diese lassen sich durch Gleichungen ausdrücken, 

wie dies weiter unten unter Kapitel 3.1.5 dargestellt wird. In der Tabelle 

3.1 sind die Knoten-Typen von [23] zusammengestellt. 

PQ-Knoten sind Stellen, an denen das Netz belastet oder Leistung von 

Kraftwerken ins Netz eingespiesen wird. Dabei sind die Lasten durch die 

Verbraucher bestimmt, z.B. durch Industrieprozesse, Heizbedürfnisse usw. 



Wesentlich dabei ist, dass eine konstante Wirkleistung P und Blindleistung 

Q vorgegeben wird, die nicht von den übrigen Grössen des Netzes abhängt. 

Der Spannungsbetrag V am Knoten stellt sich frei ein. Der Knoten toleriert 

dabei einen Bereich von V = Vmin ...Vmax. 

PV-Knoten sind Kraftwerkseinspeisungen bei denen eine Wirkleistung 

P und ein Spannungsbetrag V vorgegeben wird. Beides sind Sollwerte, für 

die der Turbinen- bzw. der Spannungsregler des Generators verantwortlich 

ist. Die Blindleistung Q am Knoten stellt sich dabei frei ein. Der Knoten 

toleriert dabei einen Bereich von Q = Qmin ...Qmax. 

Sowohl der PQ- als auch der PV-Knoten stellt wegen der Leistungsbeziehung 

S = P + j · Q = U · I ∗ und der Konstanthaltung des Spannungsbetrags 

nichtlineare Zusammenhänge zwischen den Knotengrössen her. 

Der Slack-Knoten ist eine Kraftwerkseinspeisung, bei der alle Komponenten 

der komplexen Knotenspannung vorgegeben werden. Der Slack- 

Knoten ist daher ein spezieller Knoten, da er als Referenz für sämtliche 

Spannungen eines Netzes dient. Üblicherweise wird die Spannung des 

Slack-Knotens in die reelle Achse der komplexen Ebene gelegt. Am Slack- 

Knoten stellen sich die Wirkleistung P und die Blindleistung Q entsprechend 

der Leistungsbilanz im Netz ein. Dieser Knoten hat deshalb die 

Bezeichnung Slack-Knoten (slack = lose, locker). 

Ein weiterer Knoten, in Tabelle 3.1 mit PQ-Last bezeichnet, ist eine 

ungeregelte Stelle des Netzes, an welcher mit den Parametern P und Q 

eine Last vorgegeben werden kann. 

Zweig-Typen 

Zweig-Typen (Branches) zeichnen sich durch zwei elektrische Anschlüsse 

aus. 

Typische Vertreter sind der Transformator und die Übertragungsleitung. 

Wie in der Tabelle 3.2 ersichtlich, lassen sich mehrere Typen von 

Transformatoren unterscheiden, je nach den möglichen Datenvorgaben. 

Die Grösse t bezeichnet das Übersetzungsverhältnis t und eine Phasendrehung 

Φt. Beide Vorgaben sind Steuergrössen des Transformators, die 

in bestimmten Grenzen variierbar sind, um z.B. einen Spannungsbetrag 

und/oder eine Wirk- oder Blindleistung an einem beliebigen Netzknoten 

zu regeln. Die beiden Anschlüsse werden durch Zusatzinformation unterschieden, 

die einem dahinterliegenden Modell des Zweiges entspricht. 

Das Transformatormodell hat eine Seite, die dem idealen Übertrager (Tap- 

Bus) und eine Seite, die mit einer nichtverschwindenden Impedanz ver- 



Entität Bedingungen Typ aus [23] 

Übertragungs- 0 

leitung 

Trafo1 t = const. 1 

Trafo2 t = tmin ...tmax, Φt = const, 2 

VBus = Vmin ...Vmax 

Trafo3 t = tmin ...tmax, Φt = const, 3 

QBranch = Qmin ...Qmax 

Trafo4 Φt = Φmin ...Φmax, t = const, 4 

PBranch = Pmin ...Pmax 

Tabelle 3.2: Zweig-Typen 

bunden ist (Impedance-Bus). Eine Übertragungsleitung (Tie-Line) hat eine 

“Meter-Bus”- und eine “NonMeter-Bus”-Seite. Parallele Zweige werden 

in [23] durch Circuits-Nummern unterschieden. Damit lassen sich z.B. 

parallele Leitungsstränge etwas vereinfacht darstellen, da gemeinsame Daten, 

wie z.B. die gleichen Knoten-Nummern nur einmal anzugeben sind. 

Interchange-Area 

Das Interchange-Area ist ein Gebiet innerhalb eines Netzes, in welchem 

eine bestimmte Wirkleistungssumme vorgegeben werden kann. Diese Vorgabe 

entspricht beispielsweise einer Sollvorgabe für einen bestimmten Wirkleistungs-Export 

des Gebietes. Die Leistung, die aus einem Area exportiert 

ist positiv, bei Import ist sie negativ. 

3.1.3 Zusammenschaltbarkeit der Netzelemente 

Eine wesentliche Eigenschaft der Netzelemente ist, dass sie eine oder mehrere 

Anschlussstellen (Klemmen) besitzen, an denen sie miteinander in 

verschiedenster Weise verbunden werden können. Dies ist ein bedeutender 

Faktor von Variabilität innerhalb der betrachteten Domäne. Bei der Topologie 

(Lehre vom Ort, Topos: Ort) des Netzes geht es um die Beschreibung 

der Verbindungen zwischen Knoten. Bevor auf dem Computer eine Netzberechnung 

ausführbar ist, muss die Topologie des Netzes computermässig 

erfasst werden. In der vorliegenden Arbeit wird diese Erfassungsfunktion 

als Netzaufbau bezeichnet. Ein elektrisches Energieübertragungsnetz lässt 

sich grob durch seine Knotenzahl und die Zahl der Übertragungsleitungen 

charakterisieren, da die Zahl der (Hochspannungs-) Leitungen gegenüber 

anderen Zweig-Typen des Übertragungsnetzes weitaus dominiert. Für eine 

modellmässige Beschreibung muss darüber hinaus bekannt sein, wie 



1 

4 

2 

5 

Abbildung 3.2: Graph für ein 5-knotiges Netz 

die einzelnen Knoten verbunden sind und welche Typen von Knoten und 

Zweigen vorhanden sind. 

Auf dem Papier lässt sich ein Netz eindeutig durch einen Graphen beschreiben. 

Als Beispiel ist in Abbildung 3.2 ein Graph für ein 5-knotiges 

Netz gezeigt. 

Ein Graph besteht nur aus Knoten und Verbindungen (Zweigen) zwischen 

diesen Knoten. Die Zweige besagen lediglich, dass zwischen den 

betreffenden Knoten eine Verbindung besteht. Der Bezugsknoten wird im 

Graphen nicht eingezeichnet 1 . 

Den Verbindungen kann noch eine vorgegebene Richtung zugeordnet 

werden, die durch einen Pfeil festgelegt wird. Man spricht dann von einem 

gerichteten Graphen, im Unterschied zum ungerichteten Graphen der 

Abbildung 3.2. 

Im allgemeinen Fall wird mit dem gerichteten Graphen gearbeitet, da 

es in einem Netz meistens unsymmetrische Zweige gibt, wie z.B. einen 

Transformator mit einem Übersetzungsverhältnis = 1 oder eine Übertragungsleitung 

mit nur einer Leistungs-Messstelle an einem der Leitungsenden. 

In beiden Fällen ist die Angabe der Einbau-Richtung (=Zweigrichtung!) 

absolut zwingend, damit eine übereinstimmende Modellierung auf 

dem Computer möglich ist. 

Mit dem (gerichteten) Graphen ist bei der Modellierung von elektrischen 

Netzen die Netzstruktur festgelegt. 

Der Graph ist wohl ein anschauliches geometrisches Gebilde, aber damit 

ist die Netztopologie noch nicht für den Computer unmittelbar lesbar. 

Dafür muss der Graph alphanumerisch umgesetzt werden. Eine mögliche 

computerlesbare Eingabeform ist die Zweigliste. Sie besagt, welche 

Knoten am Start- und Endknoten der gerichteten Zweige anliegen, oder 

umgekehrt, welche Knoten durch den Zweig verbunden sind. 

1Er entspricht im Dreiphasen-System dem Sternpunkt. Sämtliche Knotenspannungen im Netz beziehen 

sich auf diesen Punkt. 


3


In der folgenden Zweigliste ist der Graph der Abbildung 3.2 numerisch 

beschrieben. 

Start-Knoten End-Knoten 

1 2 

1 4 

2 5 

4 5 

2 3 

3 5 

Falls diese Zweigliste noch mit technischen Parametern der modellierten 

Betriebsmittel ergänzt wird, gelangt man zu einem Format (Tauschformat), 

dass von einem Computer gelesen werden kann. 

3.1.4 Lösungsverfahren Netzgleichungen 

Wie in 3.1.2 dargestellt, führen Randbedingungen der Knoten-Typen bei 

der Lastflussrechnung auf nicht-lineare Gleichungssysteme. Es hat sich 

gezeigt, dass ein Domänenmodell, das solche nicht-lineare Gleichungen 

enthält, vom zugrundeliegenden Lösungsverfahren abhängt. So ist es beim 

gewählten Newton-Raphson-Verfahren zwingend, dass die Variablen kontinuierlich 

und alle Funktionen einmal ableitbar sind. 

Das gesamte Gleichungssystemg(x,p)=0 enthält N gleichzeitige, nichtlineare 

Gleichungen, gebildet aus den Unbekannten 

x = {x1,x2,···xN} und den Bekannten p. 

Dieses Unterkapitel zeigt und bewertet zwei möglichen Verfahren zur Auflösung 

von N nicht-linearen Gleichungen, die das System 

g(x,p)=0 bilden. 

Das Gauss-Seidel Verfahren 

Für das Gauss-Seidel Verfahren werden die N Gleichungen wie folgt aufgestellt: 

x1= g1(x2 ···xN) 

. = 

xi= gi(x1···xN) (1


g(x ) 

k 

g(x) 

xk+1 

Abbildung 3.3: Eindimensionale Darstellung des Newton-Raphson-Verfahrens 

Das Gauss-Seidel Verfahren liefert den Wert xk i , der die Approximation 

von xi bei der Iteration k darstellt: 

x k i = gi(x k 1 ,xk2 ,···,xki−1 ,xk−1 

i+1 ,···,xk−1 N ) (3.1) 

Falls die Bedingung 

Δx k i = |xki − xk−1 i | < ε ∀i 

erfüllt ist, hat das Verfahren konvergiert und eine Lösung gefunden. 

Das Gauss-Seidel Verfahren ist ein Relaxations-Verfahren. Es konvergiert 

schlecht oder gar nicht, falls ein Netz mehr als 100 Knoten aufweist. 

Die Methode wird kaum noch in der Praxis angewandt. Das Verfahren 

würde sich jedoch sehr einfach in einem objekt-orientierten Design implementieren 

lassen. In [5] und in veränderter, konzeptionell aber ähnlicher 

Form in [24] wird dieses Verfahren benutzt, um damit einen knotenorientierten 

Netzberechnungs-Algorithmus zu formulieren. Es zeigt sich, 

dass der Datenaustausch genau der Topologie des Netzes folgt, was in der 

objekt-orientierten Welt bedeutet, dass nur benachbarte Objekt miteinander 

kommunizieren müssen. 

Das Newton-Raphson-Verfahren 


(4) 

(3) 

Um die eindimensionale, nichtlineare Gleichung 

g(x)=0 

x k 

(2) 

(1) 

x


zu lösen, wird die Funktion in einer Taylor-Reihe um den Punkt xk entwickelt, 

so gilt: 

g(x)=g(xk)+ ∂g(x) 

 

 

(x−xk)+Terme höherer Ordnung 

∂x x=xk 

Bricht man die Reihe nach dem Term 1. Ordnung ab, erhält man für die 

Lösung eine bessere Approximation: 

xk+1 = xk + Δx 

wobei 

 

∂g(x) 

−1 

Δx = − · g(xk) (3.2) 

∂x x=xk 

Dieser iterative Prozess wird solange fortgesetzt bis das Konvergenzkriterium 

|g(xk)| < ε 

erfüllt ist. Je mehr sich die Funktion einer Geraden annähert desto schneller 

und zuverlässiger konvergiert das Verfahren unter der Voraussetzung, 

dass der Startpunkt nahe genug bei der Lösung gewählt wurde. 

Stellt man die Funktion y = g(x) graphisch dar (siehe Abbildung 3.3), 

so kann die Lösung visuell einfach festgestellt werden: Dort, wo die Kurve 

die x-Null-Achse schneidet, d.h. dort wo y = 0, ist die gesuchte Lösung 

für x. 

Das Newton-Raphson-Verfahren nähert sich, ausgehend von einem numerisch 

gegebenen Startwert xk (Punkt 1 in Abbildung 3.3) dieser Lösung 

iterativ wie folgt: 

Am Ort yk = g(xk) (Punkt 2) wird eine Tangente, in Abbildung 3.3 

durch 3 gekennzeichnet, an die Kurve y = g(x) gelegt. Diese Tangente 

(eine Gerade) schneidet die x-Achse am Ort xk+1 (Punkt 4). Für diesen 

Wert wird der zugehörige Wert yk+1 = g(xk+1) bestimmt. Dann wird wieder 

eine Tangente an die Kurve gelegt, der Schnittpunkt mit der x-Achse 

festgestellt, usw. 

Die Methode lässt sich auf beliebig grosse Gleichungssysteme 

g(x,p)=0 (3.3) 

anwenden. Die Tangente in Abbildung 3.3 ist in diesem Fall durch eine 

tangentiale Fläche in einem N-dimensionalen Raum zu ersetzen. Die 

Menge der Unbekannten wird dabei wie folgt verbessert: 

xk+1 =xk + Δx 



wobei 

Δx = −J −1 ·g(xk) Jij = ∂gi(x) 

 

 

(3.4) 

∂xj x=xk 

Die Jacobi-Matrix J ersetzt dabei die erste Ableitung in Gleichung (3.2). 

Der maximale Mismatch ist dabei die betragsmässig grösste Funktionswert- 

Abweichung. 

Dieses Verfahren ist heute die Basismethode für die Lösung des Lastflusses. 

Darüber hinaus wird dieses Verfahren verbreitet in kommerziellen 

Simulationsprogrammen verwendet. 

Die Erfahrung zeigt, dass sich der Mismatch bei diesem Verfahren pro 

Iteration um den Faktor 10 verkleinert. Unabhängig von der Netzgrösse 

kann daher erwartet werden, dass nach 4 bis 6 Iterationen eine befriedigende 

Lösung gefunden wird. 

Zusammenfassend sprechen folgende Gründe für die Wahl des Newton- 

Raphson-Verfahrens: 

• Rasche und sichere Konvergenz 

• Unabhängigkeit von der Netzgrösse 

• Vorhandensein von effizienten Softwarepaketen zur Lösung von Gleichungssystemen 

2 

• Vorhandensein von Sprachen, welche eine symbolische Ableitung von 

Funktionen ermöglichen 

3.1.5 Erzeugung der Netzgleichungen 

Die Netzmodellierung gibt an, wie man systematisch zu einem Satz von 

Gleichungen gelangt, die das Verhalten des Netzes beschreiben. Es existieren 

heute mehrere solcher Verfahren. Es stellt sich daher die Frage, 

welche dieser Netzmodellierung zu wählen ist. 

Eine Netzmodellierung ist für die Ziele der vorliegenden Arbeit dann 

günstig, wenn sie durch eine objekt-orientierte Modellierung, realisierbar 

ist, bei der die Vorzüge dieser Technologie möglichst gut zum Tragen 

kommen. Dabei wird insbesondere dem Gesichtspunkt der Kapselung, 

d.h. einer klaren Zuordnung von Daten und Aktionen auf Entitäten 

2 Wie in Kapitel 3.1.5 gezeigt wird, handelt es sich dabei um schwach-besetzte Gleichungssysteme 



beachtet. Ferner wird angestrebt, dass es möglichst wenige solcher Aktionen 

benötigt. Ferner ist es auschlaggebend, dass das gewählte Newton- 

Raphson-Verfahren in einfacher Weise mit der Modellierung kombiniert 

werden kann. 

Ein gut bekannter Kandidat basierend auf Knoten und Zweigen soll 

zunächst vorgestellt und hinsichtlich der objekt-orientierten Modellierung 

nach diesen Kriterien untersucht werden. Dies geschieht anhand eines Beispiels, 

das auch in einem weiteren, alternativen Modellierungs-Ansatz benutzt 

wird, der in dieser Arbeit als Ntor-Ansatz bezeichnet wird. An diesem 

durchgezogenen Beispiel wird aufgezeigt, dass sich der Ntor-Ansatz 

für eine objekt-orientierte Modellierung eines Netzes besser eignet, als der 

verbreitete Knoten-Zweig-Ansatz. 

Modellierung mit Knoten und Zweigen 

Ein verbreiteter Ansatz modelliert das Netz als einen gerichteten Graphen, 

der aus Knoten und Zweigen besteht. Sämtliche elektrischen Betriebsmittel 

werden dabei als spezielle Knoten- oder Zweiginstanzen betrachtet. 

Das zentrale Element ist dabei stets die Knotenpunktsadmittanzmatrix. 

Dieser Ansatz ist verbreitet. Man findet ihn in den meisten Lehrbüchern 

über Netzwerkanalyse. Er wird eingehend in den Arbeiten [24] und [25] 

benutzt und in weiteren Veröffentlichungen wie [2, 4, 6, 8] und [23] verwendet. 

Der Knoten-Zweig-basierte Ansatz soll hier auf seine Eignung für eine 

objekt-orientierte Modellierung untersucht werden. Dazu werden die Terme 

betrachtet, welche im Zuge des Newton-Raphson-Verfahrens für das 

linearisierte Gleichungssystem benötigt werden. Dabei interessieren vorallem 

die Zugehörigkeiten dieser Terme zu Knoten und Zweigen. Einfache 

Zugehörigkeiten lassen einen einfacheren Design erwarten. 

Für diese Untersuchung wird eine Lastfluss-Berechnung betrachtet. Nachfolgend 

sind dazu die Gleichungen, Variablen und Parameter der einzelnen 

Knotentypen dargestellt. Da bei dieser Lastfluss-Berechnung nur sinusförmige 

Grössen vorkommen, können die Variablen durch komplexe 

Zahlen realisiert werden. 

Die Knotentypen sind im Unterkapitel 3.1.2 beschrieben. Jeder dieser 

Typen hat Variable und formuliert damit typspezifische Gleichungen. Je 

zwei Gleichungen stammen aus der Strombilanz am Knoten, wie in Abbildung 

3.4 dargestellt. Weitere Gleichungen können wie in Tabelle 3.3 

dargestellt, dazukommen. 



U 

I 

I 

Knoten-Entität 

i 

KE 

i 

i 

U i 

Referenzpotential 

I i 

Knotenspannung am Knoten I gegen Referenzpotential 

i Strom in die Knoten-Entität i 

I 

KE 

i 

Summe aller aus dem Knoten i fliessender Zweigströme 

Abbildung 3.4: Strombilanz im Knoten 

Netzwerk 

Die komplexen Grössen sind wie folgt zusammengesetzt: 

I i = Iei + j·Ifi 

IKEi = IKEei + j·IKE fi Ui = ei + j · fi 


j 

(3.5) 

(3.6) 

(3.7) 

Eine zentrale Gleichung ist die Strombilanz im Knoten i. Die Strombilanz 

benutzt die Gleichungen (3.10), (3.11), (3.13) und (3.14). 

IKEi +I i = 0 (3.8) 

Der Strom I i fliesst vom Knoten i in das restliche, rechts-liegende Netz 

hinein. Dabei ist zu beachten, dass die Zweige bei dieser Modellierung immer 

durch Vierpole ausgedrückt werden. Der Zweig-Teil des Netzes lässt 

sich daher mit Hilfe der bekannten Knotenadmittanz-Matrix Y ausdrücken. 

Y besitzt die komplexen Elemente y ij : 

y ij =gij + j·bij 

(3.9) 

Damit lässt sich der Strom I i nach Real- und Imaginärteil getrennt durch 

folgende Gleichungen ausdrücken: 

Iei = 

Ifi= 

N 

∑ 

j=1 

N 

(ej gij − fjbij), i=1...N (3.10) 

∑(ejbij 

+ fjgij), i=1...N (3.11) 

j=1


Slack-Knoten 

i 

Admittanz Y = G + jB 

Y-Zweig 

PQ-Knoten 

Abbildung 3.5: Netzbeispiel modelliert mit Knoten-Zweig-Ansatz 

N ist die Anzahl aller Netzknoten ohne den Referenzknoten. 

Ferner lässt sich der Strom aus den Knoten-Entitäten IKEi aus den Angaben 

von Wirk- und Blindleistung bei gegebener Knotenspannung U i mit Hilfe 

der Beziehung 

∗ 

Pi + j · Qi = Ui · IKEi 

(3.12) 

berechnen und nach Real- und Imaginärteil getrennt ausdrücken: 

IKEei = eiPi + fiQi 

ei 2 + fi 2 


j 

(3.13) 

IKE f = i −eiQi + fiPi 

ei 2 + fi 2 

(3.14) 

Man beachte, dass das Verbraucherzählpfeilsystem gewählt ist. Die Knoten- 

Entität verbraucht daher Leistung, falls P grösser als 0 ist. 

Abbildung 3.5 zeigt eine einfache Netzkonfiguration. Die darin vorkommenden 

Knoten- und Zweigentitäten werden mit Hilfe der Strombilanz 

3.8 und weiteren typenspezifischen Beziehungen charakterisiert. Die 

Tabelle 3.3 zeigt, was g(x,p)=0 in diesem Fall konkret bedeutet. In 

der Spalte “Gleichungen”, “Param(eter)” und “Variable” stehen die Komponenten 

der Vektoren g, p und x. Allgemein gibt es zu jeder im Netz 

vorkommenden Knoten-Entität zwei unbekannte Knotenspannungen e und 

f . Diesen entsprechen zwei Komponenten von x. Ferner ist erkennbar, 

dass die Knoten-Entitäten wegen der Leistungsbeziehung (siehe Gleichung 

(3.12)) je zwei Komponenten von g mit nichtlinearem Verhalten aufweisen. 

Für jeden Typ der Knoten-Entitäten können je nach Bedarf weitere 

Komponenten in g, p und x dazukommen. wie z.B. die dritte und vierte 

Zeile in der Spalte “Gleichungen” des Typs Slack-Generators. Die Zweig- 

Entität steuert nur Komponenten von p bei, mit deren Hilfe die Komponenten 

von g formuliert werden. Die Zuordnung der Komponenten der 

Vektoren g, x und p ist frei wählbar. Sie muss jedoch für die weitere Berechnung 

beibehalten werden.


Entität Variable Param. Gleichungen 

x p g(x,p)=0 

Slack- Pi,Qi eSl, fSl 

Knoten ei, fi 

PQ- e j, f j Pj,Qj 

Knoten 

Y- G,B 

Zweig 

ei Pi+ fi Qi 

e 2 i + fi 2 + ei G − fi B − e j G + f j B = 0 

−ei Qi+ fi Pi 

ei 2 + fi 2 

e j Pj+ f j Q j 

e2 j + f j 2 

−e j Q j+ f j Pj 

e j 2 + f j 2 

+ ei B + fi G − e j B − f j G = 0 

ei − eSl = 0 

fi − fSl = 0 

+ e j G − f j B − ei G + fi B = 0 

+ e j B + f j G − ei B − fi G = 0 

Tabelle 3.3: Entitäten beim Knoten-Zweig-Ansatz 

Aus der Angabe von Tabelle 3.3 lassen sich alle die Terme berechnen, 

die für das Newton-Raphson-Verfahren benötigt werden. 

Eine wichtige Konsequenz des Knoten-Zweig-Ansatzes ist, dass die Jabobi- 

Matrix Nebendiagonal-Blöcke Aij aufweist, die von Null verschieden sind. 

Dies ist dann der Fall, wenn zwischen den Knoten i und j ein Zweig mit 

einer Admittanz Yij =0 vorhanden und nicht ein Slack-Knoten verbunden 

ist. 

Aij = ∂[gi] 

(3.15) 

∂[xj] 

Dabei bezeichnen [gi] und [xi] Teilmengen von Funktionen und Variablen 

der Knotentypen. In der Tabelle 3.3 sind diese Teilmengen für jeden Knotentypen, 

der im Netzbeispiel vorkommt, dargestellt. 

Es zeigt sich, dass vorallem die Nebendiagonal-Blöcke näher zu betrachten 

sind. Bei den Diagonalblöcken steuern die Zweige die Parameter 

B und G bei. Damit wird das Lokalitätsprinzip verletzt. Beim Mismatch- 

Wert treten keine wesentlichen Unterschiede zwischen der Knoten-Zweigund 

der, ab Seite 43 diskutierten, Ntor-basierten Modellierung auf. 

Hingegen gibt es bei der Erzeugung der Nebendiagonal-Blöcke durch 

den Knoten-Zweig basierten Ansatz Schwierigkeiten, wenn dies in einer 

objekt-orientierten Modellierung geschehen soll. 

Dazu sind in der Tabelle 3.4 die Nebendiagonal-Blöcke der Jacobi- 

Matrix für alle Kombinationen von Knoten-Typen dargestellt, die über den 

gleichen Zweig verbunden sind. 



Knoten 

i 

Admittanz Y 

Zweig 

Knoten 

Abbildung 3.6: Abhängigkeit der Nachbarknoten 

Knotentyp i Knotentyp j Aij 

 

0 0 

Slack Slack 

0 0 

Slack PQ 

Slack PV 

PQ PQ 

PQ PV 

PV PV 

PV PQ 

PQ Slack 

PV Slack 

−gij bij 

−bij −gij 

−gij bij 0 


j 

 

−bij −gij 0 

 

−gij bij 

−bij −gij 

−gij bij 0 

⎡ 

 


−gij bij 0 


 

 

⎤ 

⎢ 

⎣ 

⎥ 

⎦ 

0 

⎡ 

0 0 

⎤ 

⎢ 

⎣ 

−gij bij 

−bij −gij 

 

0 0 

 

0 0 

0 

⎡ 

0 

0 

⎤ 

0 

⎢ 

⎣ 0 

⎥ 

0 ⎦ 

0 0 

Tabelle 3.4: Abhängigkeit der Jacobi-Terme 

⎥ 

⎦


Es ist offensichtlich, dass für die Erstellung dieser Matrizen Information 

von den drei beteiligten Entitäten benötigt wird. Man erkennt die Abhängigkeit 

zwischen der Dimension der Matrizen und der Grösse der Variablen- 

Mengen der anstossenden Knotentypen. Die Reihenfolge der Knoten- 

Typen für die Dimension der Matrizen entscheidend. Je nachdem, ob die 

Reihenfolge i- j PQ-PV oder PV-PQ lautet, wird die Matrix eine 2×3- oder 

eine 3 × 2-Matrix. 

Ferner hängen die Elemente selbst von den Knotentypen ab. Wenn der 

Slack-Knoten die Rolle des Knotens j hat, sind alle Matrizenwerte 0. In 

den anderen Fällen werden die Elemente durch Zweigparameter vorgegeben. 

Es stellt sich daher die Frage, welche Entität die Matrix Aij letztlich 

erstellt, und wie dabei das Wissen aus den anderen Entitäten beigesteuert 

wird. Zwei mögliche Lösungsansätze werden nachfolgend skizziert. Die 

dabei entstehenden Schwierigkeiten im Zusammenhang mit dem objektorientierten 

Design werden erläutert. 

Die erste Lösung geht davon aus, dass ausser den Spannungen keine 

weiteren Variablen gegenseitig in den Gleichungen von Knoten i und 

j vorkommen. Unter dieser Annahme lässt sich mit dem in Abbildung 

3.7 gezeigten Datenaustausch die Information durch die beteiligten Entitäten 

fortlaufend vervollständigen. Dies geschieht innerhalb verschiedener 

Aktionen, die zu verschiedenen Entitäten gehören. In der objektorientierten 

Terminologie entsprechen die Aktionen den Methoden verschiedener 

Klassen. Im Folgenden werden die Aktionen durch das Symbol 

M Index1[Index2] abgekürzt. Index1 bezeichnet die zugehörige Entität 

(Z=Zweig, K=Knoten bzw. Kirchhoff-Knoten, N=Ntor). Mit Index2 

werden unterschiedliche Aktionen einer Entität identifiziert. 

Die Aktion MK1E verfügt über die Information, die der Knoten j für 

den Aufbau der Matrix Aij bzw. A ji benötigt. 

Man beachte, dass die Vierpole der Zweige nicht symmetrisch zu sein 

brauchen. Daher wurde in beiden Lösungen angenommen, dass es zwischen 

zwei benachbarten Knoten immer zwei entgegengesetzt gerichtete 

Zweige gibt. 

Dieser Lösungsansatz benötigt vier unterschiedliche Aktionen: 

MZ1H, MZ1T , MK1A und MK1E sowie fünf Parameter-Werte. Als nachteilig 

wird dabei beurteilt, dass die von der Zweig-Entität stammenden Übergabeparameter 

gij bzw. bij für die Schnittstellendefinition der Knoten- 

Entität (Aktionen MK1A und MK1E) benutzt werden. Sollten sich diese 



über alle 

Zweige 

in Richtung 

M Z1H 

g ij , b ij 

M K1A 

Dimension i 

g ij , b ij 

i j 

M K1E 

über alle 

Zweige 

in Richtung 

i j 

Zweig Knoten Knoten 

ij i j 

M Z1T 

g ij , b ij 

M K1A 

ij b Dimension i 

g , ij 


M K1E 

Abbildung 3.7: 1. Lösungsansatz zum Aufbau der Nebendiagonalblöcke 

Übergabeparameter jemals ändern, so sind die Schnittstellen des Knotentypen 

anzupassen. 

In der zweiten Lösung wird eine Fallunterscheidung im Programmcode 

der Aktion MZ2H bzw. MZ2T der Zweige benutzt. Diese Fallunterscheidung 

hängt, wie in Tabelle 3.4 ersichtlich und nachfolgend diskutiert wird, 

von der Vielfalt der Knotentypen ab. Obwohl der zweite Lösungsansatz 

nur drei Aktionen MZ2H, MZ2T und MK2 und einen Übergabeparameter für 

den Knotentypen benötigt, gibt es ebenfalls Wartungsprobleme, wenn z.B. 

die Vielfalt der Knotentypen ändert. In diesem Fall wäre der Programmcode 

in der Aktion MZ2H bzw. MZ2T der Zweig-Entität anzupassen. 

Modellierung mit Ntor-Ansatz 

In Tabelle 3.4 ist ersichtlich, dass bei der Knoten-Zweig-basierten Modellierung 

für den Aufbau eines Nebendiagonalblocks Aij Informationen von 

drei Entitäten benötigt werden. Ferner zeigt sich, dass der Nebendiagonalblock 

Aij gleichzeitig die Information enthält, ob zwischen den Knoten 

i und j eine Verbindung besteht und welche Parameter des Zweiges zwischen 

diesen Knoten massgebend sind. 

Wie in Kapitel 3.1.5 gezeigt wurde, ist diese Vermischung von gleichzeitig 

auszuwertender Information für einen objekt-orientierten Design ungünstig. 

Es treten Wartungsprobleme der Software auf, wie z.B. die in 

Programmen verstreute Auswirkungen bei Änderung von Datentypen oder 

A ij 

A ji 

Zeit


über alle 

Zweige 

in Richtung 

i 

über alle 

Zweige 

in Richtung 

i 

j 

j 

Zweig Knoten Knoten 

ij i j 

M Z2H 

case 

case 

... 

M Z2T 

case 

case 

... 

Knotentyp 

Knotentyp 

A 

Knotentyp 

Knotentyp 

ij 

A ji 

M K2 

M K2 


M 

K2 

M K2 

Abbildung 3.8: 2. Lösungsansatz zum Aufbau der Nebendiagonalblöcke 

Entitäten. 

Daher wird ein weiterer Modellierungsansatz untersucht, der in der vorliegenden 

Arbeit als Ntor-Ansatz bezeichnet wird. 

Dieser Ansatz zielt einerseits darauf ab, diese Vermischung zu entflechten. 

Ausserdem hat es sich gezeigt, dass die Flexibilität der Modellierung 

beim Knoten-Zweig-basierten Ansatz an Grenzen stösst, wenn Betriebsmittel 

mit mehr als zwei Anschlüssen zu modellieren sind. Dies ist z.B. 

beim Dreiwickler-Transformators mit verstellbarem Übersetzungsverhältnis 

der Fall, um genügende Übereinstimmung mit der Wirklichkeit zu erlangen. 

In [26] werden genauere aber auch komplexere Modelle dargestellt. 

Diese Komplexität ist ein wesentlicher Grund für eine Modellierung, 

die allgemein für Betriebsmittel mit N Anschlüssen geeignet ist. 

Der Ntor-Ansatz baut auf den Entitäten Ntor und Kirchhoff-Knoten und 

formuliert dabei die Gleichungen etwas anders. Wie im Anhang A gezeigt, 

lassen sich die Gleichungen des Ntor-Ansatzes in diejenigen des Knoten- 

Zweig-Ansatzes überführen. 

Die grundlegende Idee des Ntor-Ansatzes ist, Betriebsmittel mit internen 

“starken” physikalischen und damit modellmässigen Zusammenhängen 

als Ntore zu modellieren. Es gibt hier keinen Unterschied mehr zwischen 

Knoten- und Zweigentitäten. Alle Betriebsmittel sind bei dieser Modellie- 

Zeit


Referenzknoten 

anr 

Flussvariable 


Ntor 

i 

i,anr 

Potentialvariable i,anr 

Abbildung 3.9: Zählrichtungen von Fluss- und Potentialvariablen 

rung Ntor-Entitäten. Jedes Ntor formuliert dazu Gleichungen in eigenen 

Variablen. 

Typische Vertreter sind in der Energieübertragungstechnik die Leitung 

(2-Tor), das Kabel (2-Tor), der Shunt (1-Tor), das Serieelement (2-Tor), 

der 2-Wicklungstransformator (2-Tor) und der 3-Wicklungstransformator 

(3-Tor). 

Die Anzahl Tore pro Ntor, d.h. die Zahl N gibt zunächst die Anzahl 

unterschiedlicher Klemmen eines Betriebsmittel an, über die es mit den 

übrigen anderen Elementen des Netzes verbunden werden kann. Dies sind 

stets Verbindungen von diesen Ntoren zu Kirchhoff-Knoten. In Unterkapitel 

3.2 wird schliesslich eine abstraktere Betrachtung angegeben, bei dem 

das Tor, als Anschluss bezeichnet, den Zugriff auf eine beliebige Anzahl 

von indizierten Variablen ermöglicht. 

Ein weitere Entität ist daher der Kirchhoff-Knoten. Beim Übertragungsnetz 

in der Energietechnik wird jeder idealen, impedanzlosen Sammelschiene 

ein (Kirchhoff-) Knoten zugeordnet. Ihm ist die Aufgabe zugeteilt, 

die Netztopologie zwischen Ntor-Entitäten zu beschreiben. Dies wird 

durch folgende beiden Kirchhoffschen Gesetze erreicht: 

• Die Potentialvariablen aller miteinander verbundenen Ntor-Anschlüsse 

haben den gleichen Wert. 

• Die Summe der Flussvariablen aller miteinander verbundenen Ntor- 

Anschlüsse ist Null. 

Die Potentialvariablen entsprechen in elektrischen Anwendungen gerichteten 

Spannungen gegen einen Referenz-Knoten. Den Flussvariablen entsprechen 

die in die Ntor-Anschlüsse fliessenden Ströme oder Leistungen. 

Beim Ntor-Ansatz gelten folgende Regeln der Modellierung:


Ntor i Ntor k 

Slack 

I i,1 

U i,2 

1 2 

Verbindung 

1 

I k,2 

U k,2 

Y 

1 1 

Verbindung 

2 


I k,1 

U k,1 

I j,1 

Ntor j 

U j,1 PQ 

Abbildung 3.10: Netzbeispiel modelliert mit Ntor-Ansatz 

1: Bezugsrichtungen von Fluss- und Potentialvariablen beim Ntor- 

Anschluss sind gemäss Abbildung 3.9 festgelegt. 

2: Die Basisnamen der Fluss- und Potentialvariablen sind netzweit 

einheitlich. 

3: Die Datentypen der Fluss- und Potentialvariablen sind netzweit 

einheitlich. 

4: Fluss- und Potentialvariablen werden gemäss folgendem Schema 

bezeichnet: 

• netzweit: Basisnamei,anr 

• innerhalb Ntor i : Basisnameanr 

Die Zahl anr ist die bezüglich des Ntors i lokale Nummer eines 

Anschlusses. 

5: Der Referenzknoten gilt netzweit. 

6: Ntor-Anschlüsse können nicht direkt miteinander verbunden 

werden. 

7: Die Verbindung zwischen den Ntor-Anschlüssen ist impedanzlos. 

Impedanzbehaftete Pfade zum Referenzknoten gibt es nur 

innerhalb von Ntoren. 

Diese Standardisierung ermöglicht es, beide Kirchhoff-Gesetze unabhängig 

von den Ntor-Typen aufzustellen. 

An dieser Stelle wird das Modellierungs-Beispiel mit dem Ntor-Ansatz 

gemäss Abbildung 3.10 für eine Lastflussrechnung formuliert. Das Verhalten 

der Entitäten ist identisch mit demjenigen, das bei der Knoten- 

Zweig-Modellierung in 3.1.5 verwendet werden. In beiden Modellierungen 

wird das Verbraucherzählpfeilsystem angewandt. Die Gleichungen 

beider Ansätze lassen sich daher direkt vergleichen. 

Beim betrachteten Fall sind die Flussvariablen Ströme mit dem einheitlichen 

Namen I. Die Potentialvariablen sind Spannungen mit einheitlichen


Namen U. Für die Lastfluss-Rechnung ist ein komplexer Datentyp für diese 

Variablen geeignet. I und U bestehen bei der Wahl von kartesischen 

Koordinaten aus den Komponenten: 

Ii = iei + j · i fi 

Ui = ei + j · fi 

(3.16) 

(3.17) 

Die Tabelle 3.5 zeigt, was g(x,p)=0 beim Ntor-Ansatz konkret bedeutet. 

In der Spalte “Gleichungen”, “Param(eter)” und “Variable” stehen 

die Komponenten der Vektoren g, p und x. Im betrachteten Beispiel gibt 

es zu jedem im Netz vorkommenden Ntor pro Anschluss zwei unbekannte 

Komponenten der Knotenspannungen e und f, sowie zwei Komponenten 

ie und i f . Diesen Komponenten entsprechen vier Komponenten von x. 

Ferner ist erkennbar, dass die Ntore mit einer Leistungsbeziehung gemäss 

Gleichung (3.12) (PQ- und Slack-Ntor) je zwei Komponenten von g mit 

nichtlinearem Verhalten aufweisen. Ntor-Typen unterscheiden sich durch 

die Anzahl und Namen der Komponenten von p und x sowie durch die 

Anzahl und Struktur vong. Summengeber-Entitäten können grundsätzlich 

Komponenten aller drei Vektoren g, p und x beisteuern. Im betrachteten 

Beispiel sind die Entitäten “Verbindung1” und “Verbindung2” Summengeber, 

welche nur weitere Komponenten von g beisteuern. Auch hier ist 

die Zuordnung der Komponenten der Vektoren g,x und p frei wählbar. Sie 

muss jedoch für die weitere Berechnung beibehalten werden. 

Nun soll der wesentliche Unterschied dieser Neuformulierung der Gleichungen 

beim Ntor-Ansatz betrachtet werden. Die in Tabelle 3.4 dargestellten 

Jacobi-Terme existieren beim Ntor-Ansatz nicht, da die Menge der 

Funktionen [gi] eines Ntors i stets nur in den eigenen Variablen [xi] ausgedrückt 

wird, und die Schnittmenge der Variablen zwischen beliebigen 

Ntor-Instanzen stets leer ist. Daher verschwinden alle Terme ∂[gi] 

mit i = j. 

∂[x j] 

Die der topologischen Verknüpfung entsprechende Information hat eine 

andere Form. Für jeden Kirchhoff-Knoten n entsteht eine Matrix AVerbn .Es 

ist eine reine Inzidenz-Matrix, bestehend aus vielen Nullen und typischerweise 

wenigen “1”- und “-1”-Elementen. 

Sie lautet für die Verbindung 1: 



AVerb1 

Entität Variable Param. Gleichungen 

x p g(x,p)=0 

Slack- ei,1, fi,1 eSl, fSl iei,1 − ei,1 Pi+ fi,1 Qi 

ei,1 2 + fi,1 2 = 0 

Ntor iei,1 ,ifi,1 i fi,1 − −ei,1 Qi+Pi fi,1 

ei,1 2 + fi,1 2 

Pi,Qi 

ei,1 − eSl = 0 

fi,1 − fSl = 0 

PQ- e j,1, f j,1 Pj,Qj ie j,1 − e j,1 Pj+ f j,1 Q j 

e j,1 2 + f j,1 2 


= 0 

= 0 

Ntor ie j,1 ,ifj,1 i f j,1 − −e j,1 Q j+Pj fi,1 

e j,1 2 + f j,1 2 = 0 

Zweig- ek,1, fk,1 G,B iek,1 − 

ek,1 − ek,2 G + fk,1 − fk,2 B = 0 

Ntor iek,1 ,ifk,1 i fk,1 − 

fk,1 − fk,2 G − ek,1 − ek,2 B = 0 

ek,2, fk,2 

iek,2 

+ iek,1 = 0 

iek,2 ,ifk,2 

i fk,2 + i fk,1 = 0 

Verbin- iei,1 + iek,2 = 0 

dung 1 i fi,1 + i fk,2 = 0 

ei,1 − ek,2 = 0 

fi,1 − fk,2 = 0 

Verbin- ie j,1 + iek,1 = 0 

dung 2 i f j,1 + i fk,1 = 0 

e j,1 − ek,1 = 0 

f j,1 − fk,1 = 0 

Tabelle 3.5: Entitäten beim Ntor-Ansatz 

= 

= 

∂−−→ f unsVerb1 ⎡ ∂x 

0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 

⎢ 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 

⎢ 

⎣ 1 0 0 0 0 0 0 0 0 0 0 0 0 0 −1 

0 

0 

0 

(3.18) 

⎤ 

1 0 

⎥ 

0 1 ⎥ 

0 0 

⎥ 

⎦ 

0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 −1 0 0 

−−→ 

f unsVerb1 entspricht den Gleichungen der Verbindung 1, in der Reihenfolge, 

die in Tabelle 3.5 angegeben ist. x entspricht allen Variablen des


über alle 

Kirchhoff- 

Verbindungen 

des Netzes 

Kirchhoff-Verbindung Ntor 

M K 

n 

Name der Variablen 

Position der Variablen 

A Verb n 


M N 

Abbildung 3.11: Datenaustausch beim Ntor-Ansatz für AVerbn 

Systems in der Reihenfolge ihres Auftretens in der Spalte “Variable” der 

Tabelle 3.5. 

In Abbildung 3.11 ist eine objekt-orientierte Lösung skizziert, bei der die 

beteiligten Entitäten die Matrix AVerbn erstellen. Dabei sammelt die Kirchhoff- 

Verbindung die Matrix-Positionen aller Variablen der mit ihr verbundenen 

Ntore. Dies ist die Menge aller Variablen, die über die Kirchhoffschen 

Gesetze miteinander in Verbindung stehen. Dies sind im Beispiel für die 

Verbindung1 (siehe Tabelle 3.5): 

{iei,1 ,iek,2 ,ifi,1 ,ifk,2 ,ei,1,ek,2, fi,1, fk,2}. 

Die Kirchhoff-Verbindung erzeugt pro Gleichung, welche an den 

Kirchhoffschen Gesetzen beteiligt ist, je eine Zeile der Matrix AVerbn . 

Es sind die beiden Aktionen MK und MN mit zwei Parametern für die 

Übergabe des Variablennamens und der Matrix-Position notwendig. Beide 

Parameter sind allgemeine Datentypen (Zeichenkette und INTEGER). Es 

ist ersichtlich, dass die Lösung vom Ntor-Typ völlig unabhängig ist. 

Sicht des Netzes 

In Abbildung 3.12 wird die Struktur der Jacobi-Matrizen (A) im Knoten- 

Zweig- und Ntor-Ansatz für ein gleiches Netz gegenübergestellt. Wie in 

Abbildung 3.12 ersichtlich, unterscheiden sich die Jacobi-Matrizen beider 

Ansätze erheblich. Beim Knoten-Zweig-Ansatz besitzt sie eine Diagonale, 

die durch quadratische, praktisch vollbesetzte Blockmatrizen gebildet 

wird. Jede dieser Blockmatrizen gehört zu einer Knoten-Entität. 

Die Matrizen-Elemente hängen auch von Zweigparametern ab. Pro Zweig 

gibt es zwei Matrizen in der Nebendiagonalen, deren Struktur und Werte, 

Zeit


0 

0 

Knoten-Zweig-Ansatz Ntor-Ansatz 

0 

0 

0 

0 

A u b 

(Jacobi-Matrix) 

(Mismatch- 

Vektor) 

von Knoten-Entitäten abhängig 

von Zweig-Entitäten abhängig 

1 1 1 1 

1 -1 

1 -1 

1 1 1 


0 

A 

von Ntoren abhängig 

von Summengebern abhängig 

Abbildung 3.12: Struktur der linearisierten Gleichungssysteme beider Ansätze 

wie die Schraffur in Abbildung 3.12 andeutet, von den Knoten-Entitäten 

und dem sie verbindenden Zweig abhängen. Diese Matrizen sind, wie in 

Tabelle 3.4 ersichtlich, typischerweise zu 74% besetzt. Alle übrigen Matrixelemente 

sind Null. 

Beim Ntor-Ansatz ist die Jacobi-Matrix wesentlich grösser. Sie besteht 

aus zwei rechteckigen Matrizen. Die obere Matrix, in Abbildung 3.12 hell 

dargestellt, ist eine reine Block-Diagonalmatrix. Diese ist aus den relativ 

schwach besetzten und den Ntoren zugeordnete Matrizen gebildet. Da im 

Ntor-Ansatz die zahlenmässig häufig vorkommenden Leitungen (Zweige) 

ebenfalls durch Ntore modelliert werden, hat deren Anzahl einen wesentlichen 

Einfluss auf die Grösse der Jacobi-Matrix. Die untere Matrix, in 

Abbildung 3.12 schwarz dargestellt, ist eine rechteckige, typischerweise 3 

sehr schwachbesetzte Matrix (vergl. Gleichung (3.18)). 

Bewertung der Ansätze 

Zusammenfassend ergibt sich folgende Bewertung: 

Vorteile des Ntor-Ansatzes: 

• Entflechtung von Gleichungen, welche die Topologie beschreiben und 

solchen, die die physikalische Modellierung der Ntore betreffen 

3 in Netzen der Energieübertragung 

0 

u 

b

3.2. DOMÄNENMODELL 51 

• Gleichbehandlung bei der Modellierung elektrischer Betriebsmittel, 

da keine Unterscheidung mehr in Knoten und Zweige 

• Elektrische Betriebsmittel mit mehr als zwei Anschlüssen lassen sich 

in gleicher Weise modellieren und für den Computer implementieren. 

• Der geschlossene Schalter kann problemlos mit Z = 0 modelliert werden. 

Nachteile des Ntor-Ansatzes: Der Preis für die Entflechtung von Information 

ist die Vergrösserung der Dimension des Gleichungssystems auf 

18 Variable und 18 Gleichungen, da im betrachteten Beispiel hinter jedem 

elektrischen Anschluss eines Ntors je ein Satz von Variablen (Strom und 

Spannung) steht. Im Vergleich dazu tritt beim Knoten-Zweig-Ansatz pro 

elektrischer Verbindung (Knoten) nur eine Spannungsvariable auf. Das 

Gleichungssystem enthält für das gleiche Beispiel nur 6 Variable und 6 

Gleichungen. Ferner haben die in Netzen typischerweise zahlreichen Zweige 

(Leitungen) gar keine Variablen. 

Im Beispiel der Abbildung 3.5 ist das Verhältnis zwischen den Nichtnull-Elementen 

und der totalen Anzahl der Elemente der A-Matrix 12 : 

16. Dieses Verhältnis beträgt beim Ntor-Ansatz für das gleiche Netz 54 : 

324. Die Vergrösserung der Dimension wiegt daher nicht so schwer, da 

das Gleichungssystem wesentlich schwächer besetzt ist als beim Knoten- 

Zweig-Ansatz. 

3.2 Domänenmodell 

Dieser Teil beschreibt die Ergebnisse der Domänenanalyse. 

Es wird dargestellt, welchen Beitrag die einzelnen Entitäten an der Bildung 

des gesamten nichtlinearen Gleichungssystems g(x,p)=0 leisten. 

Dabei ist dim [x] =dim[g]. Der Vektor x ist der Vektor der unbekannten 

Variablen, p ist der Vektor der bekannten Parameter. 

3.2.1 Netz und Entitäten 

Ein Netz wird als Menge untereinander verbundener Entitäten angesehen, 

die in dieser Arbeit als “Ntor” und “Summengeber” bezeichnet werden. 

Diese Entitäten werden stets über die weitere Entität “Anschluss” miteinander 

verknüpft. Zu jeder Verknüpfung gehört genau ein Anschluss. Jeder 



Σ 

Σ 

Σ 

Ntor Anschluss Summengeber 

Abbildung 3.13: Netzwerk gebildet aus den Entitäten Ntor und Summengeber 

Anschluss muss mit genau einem Summengeber verbunden sein. Verbindungen 

entstehen mathematisch gesehen dadurch, dass Gleichungen von 

miteinander verbundenen Ntoren und Summengebern gemeinsame Variable 

haben. 

Ein Ntor hat genau n Anschlüsse. Dabei bezeichnet n eine ganze Zahl 

grösser Null. Man beachte, dass z.B. ein Betriebsmittel, dass 3 elektrische 

Anschlüsse hat nicht notwendigerweise ein 3Tor (n=3) ist. Die Zahl 

“n” steht nämlich für die Anzahl nach aussen zu verknüpfender, reeller 

Variablen des Ntors. Diese Variablen werden ausserhalb des Ntors von 

Summengebern benutzt, um daraus weitere Gleichungen aufzubauen. Der 

Anschluss eines Ntors muss also im Falle der elektrischen Ntore nicht 

zwingend eine Hochspannungs-Klemme darstellen. Möglich sind weitere 

Signalklemmen, wie z.B. ein Ist-Werteingang eines Reglers. Ein elektrischer 

Anschluss verknüpft immer Variable, die in Kirchhoff-Gleichungen 

verwendet werden, um die Topologie eines Netzes zu formulieren. Je nach 

Anwendungsfall sind dies unterschiedlich viele Anschlüsse. 

3.2.2 Anschluss 

Der Anschluss bildet die Verbindung zwischen Ntor und Summengeber. 

Jeder Anschluss steht dabei für eine gemeinsame Variable, die sowohl im 

Ntor als auch im verbundenen Summengeber in den Gleichungen auftritt. 

Pro gemeinsame Variable (immer reell) ist ein Anschluss zu instantiieren. 

Ein elektrischer Anschluss verknüpft immer Variable, die in Kirchhoff- 

Gleichungen verwendet werden, um die Topologie eines Netzes zu formu- 


Σ


Σ 

a1 

summiert alle 

verbundenen a‘s b2 

c 

Σ 

summiert alle 

verbundenen b‘s 

Ntor 

V 

Variable 

Anschluss 


hat 

P 

Parameter 

Σ 

E 

Gleichungen 

Summengeber 

Abbildung 3.14: Verknüpfung als Verbindungspfad zwischen Variablen 

lieren. Je nach Anwendungsfall (DC, AC symmetrisch, allgemein dreiphasig 

usw.) sind dies unterschiedlich viele Anschlüsse. 

Anschlüsse sind ausserhalb des Ntors immer über Summengeber miteinander 

verbunden. Summengeber können über die Anschlüsse auf indizierte 

Variable der Ntore zugreifen. 

Jeder Anschluss besitzt zwei Informationen. Die eine Information k 

identifiziert das zugehörige Ntor innerhalb eines Netzes. Die andere Information 

j ist ein Index, der Teil einer Identifikation (Schlüssel) ist. 

3.2.3 Variable 

Eine weitere, zentrale Entität ist die Variable. Diese Entität hat ein Wertattribut, 

das auf dem Rechner als Double-PRECISION-Wert abgespeichert 

ist. Der Wert ist initialisierbar. Der Wert gehört zu der Komponente xvnr 

des Vektors der Unbekanntenx innerhalb des Gleichungssystemsg(x,p)= 

0. 

Ein Grundgedanke dieses Modells liegt darin, dass es zwei verschiedene 

Sichten auf ein und denselben numerischen Wert xvnr gibt. Eine Sicht 

bedeutet einen Zugriffsweg auf den numerischen Wert einer Variablen. 

Die erste Sicht bezieht den numerischen Wert auf die Komponente eines 

Vektors von zugehörigen Zuwächsen, die im Zuge des Lösungsvorganges 

des nicht-linearen Gleichungssystems beteiligt sind. Die Lage der Komponente 

im Vektor ist nicht zum Voraus bekannt. Sie ist von vielen Grössen


abhängig. Diese sind: 

• die Anzahl der im Netz vorhandenen Ntore und Summengeber 

• die Instantiierungsreihenfolge 

• die Anzahl der Variablen im Netz vorkommender Ntore und Summengeber 

• der aktuellen Zustand, in dem sich ein Ntor oder Summengeber befindet 

Der Zugriff für die erste Sicht wird durch eine bei der Variablen abgespeicherte, 

ganzzahligen Zahl vnr (Integer) ermöglicht. Der Wertebereich 

dieser Zahl umfasst die Anzahl der in den Netzen vorkommenden Variablen. 

Die zweite Sicht bezieht sich auf die Beschreibung der Gleichungen mit 

Hilfe von Variablen und Parameter. Diese Gleichungen werden einerseits 

lokal in Ntoren und netzweit mit Summengebern formuliert. Die Funktion 

Vk(basename,anr) ermöglicht diesen Zugriff. Sie gibt den numerischen 

Wert einer Variablen heraus, die durch eine Zeichenkette basename und 

einen optionalen, ganzzahligen Wert anr innerhalb des Namenraumes eines 

Ntors k identifizierbar ist. Im gleichen Namensraum sind auch die 

Parameter eines Ntors k angesiedelt. Variable innerhalb von Summengebern 

sind von aussen nicht zugreifbar. Dazu fehlt den Summengebern die 

Anschlüsse zu ihren (optionalen) Variablen. 

3.2.4 Parameter 

Ein Parameter ist eine Entität, welche die bekannten Werte p von Ntoren 

oder Summengebern darstellen. Er hat ein Wertattribut, das auf dem Rechner 

durch einen Double-PRECISION-Wert dargestellt ist. Der Parameter 

kann von einem Klienten auf einen bestimmten Wert gesetzt werden. Dieser 

Wert ist während des Auflösens des nicht-linearen Gleichungssystems 

g(x,p)=0 konstant. 

3.2.5 Ntor 

Das Ntor modelliert typischerweise ein vernetzbares Betriebsmittel, wie 

einen Generatoren, eine Last, eine Leitung usw. Das Ntor wird als end- 



licher Automat betrachtet, der das Verhalten BN σ(Vσ,Pσ,E σ,Tσ) in jedem 

Zustand σ aufweist. Im Gegensatz zum im Kapitel 3.2.6 beschriebenen 

Summengeber ist das Verhalten zur Spezifikationszeit eines Ntors 

bekannt. Die ngσ Gleichungen liegen im gesamten Gleichungssystem an 

den Stellen q bis q + ngσ − 1. Eine wichtige Eigenschaft ist, dass diese 

Gleichungen unabhängig von der Topologie des Netzes formulierbar sind, 

in welchem das Ntor eingesetzt ist. Die Gleichungen werden durch eine 

bekannte Menge V von nvσ Variablen mit der Lage s bis s + nvσ − 1im 

Gleichungssystem und Parametern P beschrieben. 

Das Verhalten BN σ im Zustand σ enthält die folgenden Mengen: 

Vσ = { xs,xs+1,...xs+nvσ−1 } 

Pσ = { p1, p2,...pnpσ } 

E σ = { gq(V [q] 

σ ,P [q] 

σ )=0, 

gq+1(V [q+1] 

σ ,P [q+1] 

σ 

···, 

)=0, 

gq+ngσ−1(V [q+ngσ−1] 

σ , P [q+ngσ−1] 

σ )=0 } 

Tσ ={ v−pa≥0⇒Folgezustand = σ1, 

pb − v ≥ 0 ⇒ Folgezustand = σ2 } 

Dabei ist Parameter pa, pb ∈ Pσ, mit pa > pb und die Variable v ∈ Vσ. In 

jedem Zustand σ gibt es maximal zwei Folgezustände σ1 und σ2. 

Es sind verschiedene Strategien für den Zustandwechsel möglich. Da 

der endliche Automat im Ntor spezifiziert ist, kann und soll das Ntor zur 

Laufzeit entscheiden, ob ein Zustandsübergang angezeigt ist. Das Ntor soll 

aber nicht selbständig wechseln. 

Es wird daher die Strategie unterstützt, dass das Ntor dem Klienten anzeigt, 

dass die Bedingung für einen Zustandswechsel erfüllt ist. Die Kontrolle 

liegt dann beim Klienten den Zustandswechsel im Ntor zu veranlassen. 

Das Ntor wechselt dann in den spezifizierten Nachfolgezustand σi. Ab 

dann gilt im Ntor das neue Verhalten BN σi (Vσi ,Pσi ,E σi ,Tσi ). Tσ = {} 

bezeichnet einen Zustand ohne Nachfolgezustand. 

Diese Zustandsbeschreibung erlaubt, für gewisse Bedingungen von Variablen 

des Ntors, die Gleichungsmenge und damit das Verhalten zu ändern. 

Dies ist in der Praxis dann wichtig, wenn z.B. in einem Lastfluss ein PV- 

Generator wegen begrenzter Blindleistung Q das Verhalten eines PQ-Generator 

erhalten soll. 



3.2.6 Summengeber 

Summengeber formulieren und instantiieren Summenbeziehungen zwischen 

Basisnamen von Variablen. Ein Summengeber s greift auf Variable der 

Ntore zu, um weitere Teilmengen von Gleichungen 

g [s] (x [s] ,p [s] )=0 (3.19) 

zu formulieren. Diese Gleichungen drücken typischerweise topologische 

Beziehungen aus, die als Inzidenzbeziehungen innerhalb von Netzwerken 

bezeichnet werden. Ein Summengeber hat ng Instanzen von elementaren 

Summentypen und eine Menge A verknüpfter Anschlüsse. Alle elementaren 

Summentypen ergeben Gleichungen mit n Variablen, die einen gemeinsamen 

Basisnamen basename haben. Wahlweise kann eine Variable 

lv und ein Parameter par in die Summe einbezogen werden. Ein Summengeber 

kann mit beliebig vielen Ntoren in Beziehung stehen. Es gibt die 

folgenden, parametrierbaren Summentypen (Elementarsummen): 

1. EinzeiligeSumme(basename,[lv,][par,]A ): 

n 

∑ Vki 

i=1 

(basename, ji)[+lv][+par]=0 (3.20) 

2. MehrzeiligeSumme(basename, A ): 

Vk1 (basename, j1) − Vk2 (basename, j2) = 0 

Vk2 (basename, j2) − Vk3 (basename, j3) = 0 

··· = 0 (3.21) 

Vkn−1 (basename, jn−1) − Vkn (basename, jn) = 0 

Das Verhalten BS(A ,E ) eines Summengebers wird durch die nachfolgend 

beschriebenen Mengen charakterisiert. Dabei steht Sum stellvertretend 

für beide elementaren Summentypen. 

A = { Anschluss1,Anschluss2,... ,Anschlussn } 

E = { gq = Sum( basenameq,[lvq,][parq,]A ), 

gq+1 = Sum( basenameq+1,[lvq+1,][parq+1,]A ), 

···, 

gq+ng−1 = Sum( basenameq+ng−1,[lvq+ng−1,] 

[parq+ng−1,]A ) } 


3.3. FUNKTIONALITÄT DES DOMÄNENMODELLS 57 

Im Gegensatz zum Ntor ist das Verhalten BS zur Spezifikationszeit noch 

nicht vollständig bekannt. Die aktuelle Menge der zu verknüpfenden Anschlüsse 

A kennt man erst, nachdem Netzdaten eingelesen worden sind. 

3.3 Funktionalität des Domänenmodells 

Dieses Unterkapitel fasst die Funktionen sowie die Merkmale des postulierten 

Domänenmodells zusammen. Dabei wird der Anwendungsbereich 

des Domänenmodells zusammenfassend dargestellt. Das Domänenmodell 

liefert eine Basis, auf der sich die drei Funktionen Netzaufbau, Netzberechnung 

und Resultatanzeige aufbauen lassen. 

3.3.1 Netzaufbau 

Das Domänenmodell enthält die Elemente Ntor, Summengeber und Anschluss, 

aus denen beliebige Netze modelliert werden können. In einem 

Netz lassen sich beliebig viele Ntor- und Summengeber-Typen definieren. 

Dabei kann eine beliebige Menge von Instanzen miteinander in beliebiger 

Topologie verknüpft werden, solange die Verknüpfungsregeln des 

Domänenmodells nicht verletzt werden. 

3.3.2 Netzberechnung 

Das Domänenmodell enthält sämtliche Elemente, aus denen die Netzberechnung 

nach dem Ntor-Modellierungs-Ansatz aufgebaut wird. Das dabei 

entstehende gesamte Gleichungssystem g(x,p)=0 enthält ng gleichzeitige, 

nichtlineare Gleichungen, gebildet aus den Unbekannten 

x = {x1,x2,···xnv} und den Bekannten p. Die gesamte Variabilität des Verhaltens 

wird ausschliesslich durch die Bausteine Ntor und Summengeber 

erbracht. Pro Baustein-Typ werden dabei beliebige Teilmengen von g, x 

und p spezifiziert und verwaltet. 

Dabei sind die folgenden Punkte zu berücksichtigen: 

1. Es gibt keine netzbezogenen Gleichungen ausserhalb von Summengebern 

und Ntoren. 

2. Alle Komponenten vonx sind kontinuierliche Variablen. 



3. Die Gesamtzahl der Variablen nv ist gleich der Gesamtzahl der Funktionen 

ng. Dies ist eine notwendige aber nicht hinreichende Bedingung 

für die Lösbarkeit des nichtlinearen Gleichungssystems. 

4. Die linearisierten Teile von g sind linear unabhängige Funktionen. 

5. ∃ ∂gi(x,p) 

∂x ∀{i, j}: Es existieren alle ersten partiellen Ableitungen der 

j 

Gleichungen nach allen Unbekannten. 

6. Netzweit gültige Daten, wie z.B. die Bezugsscheinleistung oder die 

Bezugsspannungen sind bei jedem Bausteintypen als Parameter p zu 

modellieren. 

7. Für sämtliche Variablen sind Anfangswerte für den Newton-Raphson- 

Algorithmus vorzugeben. 

Innerhalb eines Ntors lassen sich beliebige Funktionen bilden, solange 

sich diese nach allen Variablen dieses Ntors ableiten lassen. Hingegen 

haben Funktionen von Variablen von verschiedenen Summengeber-Instanzen 

stets die Form von Elementarsummen. 

3.3.3 Resultat-Anzeige 

Das Domänenmodell kennt die unbekannten Grössen und ihre Zugehörigkeit 

zu den Bausteinen. Daraus ist grundsätzlich eine objekt-orientierte 

Resultatanzeige-Funktion ableitbar. 

3.4 Beispiel 

An dieser Stelle wird ein genügend einfaches Beispiel für eine Modellierung 

mit Entitäten des Domänenmodells betrachtet. Abbildung 3.15 gibt 

einen vollständigen Überblick über dieses Modellierungs-Beispiel. 

Darin ist eine Glühlampe über eine Leitung an einer Batterie angeschlossen. 

In dieser einfachen Anordnung soll das stationäre Verhalten 

modelliert werden. 

In einem ersten Schritt werden für die drei Betriebsmittel einzelne Ersatzschaltbilder 

erstellt, die durch Rechtecke begrenzt sind. Die Ersatzschaltbilder 

werden an nummerierten Klemmen zusammengeschaltet. Die 

Batterie und die Last haben eine Klemme, die Leitung hat zwei Klemmen. 

Da nur das stationäre Verhalten interessiert, reicht je eine Zustandsgrösse 


3.4. BEISPIEL 59 

+ 

- 

+ - 

4.5V 

Batterie Leitung Last 

R 

Uq 

I1 

1 1 2 1 

I1 R I2 I1 U1 U1 

U2 U1 I1 U1 

U1 I1 U 

U1 I 

I1 2 I R + Uq - = 0 - + R + 2 = 0 

- 1 R = 0 

+ = 0 

U 1 Batterie 

I 1 Batterie 

- 

U 1 

Leitung 

+ I1 = 0 

Leitung 

= 0 

U 2 

I 2 

- 


U 1 

Leitung Last 

= 0 

+ I1 = 0 

Leitung Last 

Verbindungsstelle Verbindungsstelle 

1 2 

Abbildung 3.15: Modellierungs-Beispiel 

R 

Betriebsmittel 

Ersatzschaltbilder 

für die Modellierung 

der Ntor-Typen 

Ntor- 

Gleichungen 

Summengeber- 

Gleichungen 

für den Strom I und die Spannung U. Im Ersatzschaltbild werden darauf 

sämtliche Variablen und Parameter eingetragen. Die neben der Klemme i 

stehenden Variablen werden mit i indiziert. Man beachte, dass die Symbolnamen, 

z.B. I1 oder auch R, nur innerhalb des Ersatzschaltbildes eines 

Ntors eindeutig sein müssen. 

Nach diesen Vorbereitungen kann die Anordnung mit dem Domänen-- 

Modell formuliert werden. Die drei verschiedenen Betriebsmittel werden 

durch drei Ntor-Typen wie in Tabelle 3.6 modelliert. 

Eine elektrische Verbindungsstelle wird durch einen Summengeber mo- 

Betriebsmittel V P E 

Batterie {U1,I1} {R,Uq} {I1R+Uq−U1 =0} 

Leitung {U1,U2,I1,I2} {R} {−U1+I1R+U2 =0,I1+I2 =0} 

Last {U1,I1} {R} {U1 − I1 R = 0} 

Tabelle 3.6: Ntor-Typen für das Beispiel 

Σ


delliert. Dieser ist so parametriert, dass er die Kirchhoffschen Gesetze 

formuliert: 

E = { EinzeiligeSumme(Basisname = I), 

MehrzeiligeSumme(Basisname = U);} 

Die Menge der Anschlüsse ist dem Summengeber erst nach dem Einlesen 

der Netzdaten bekannt. Dann kennt z.B. die Verbindungsstelle1 in der Abbildung 

3.15 die Menge der Anschlüsse A . Diese umfasst den Anschluss 

1 der Batterie und den Anschluss 1 der Leitung. 

Betriebsmittel Anschluss speichernde Instanz 

Batterie Batterie-1 Verbindungsstelle1 

Leitung Leitung-1 Verbindungsstelle1 

Leitung-2 Verbindungsstelle2 

Last Last-1 Verbindungsstelle2 

Tabelle 3.7: Anschlüsse beim Beispiel 

Die gestrichelten Pfade der Abbildung 3.15 verbinden gleichwertige 

Variable in zwei verschiedenen Systemen. Das eine System wird durch 

Gleichungen der Ntore, das andere durch solche der Summengeber gebildet. 

Man beachte, dass aber in beiden Fällen der gleiche numerische Wert 

gemeint ist. Die Anzahl der linear unabhängigen Gleichungen ist gleich 

der Anzahl der Variablen (8). Dies ist eine notwendige Bedingung, damit 

das (lineare) Gleichungssystem dieses Beispiels auflösbar ist. Diese Variablen 

entsprechen den Unbekannten x des Gleichungssystems g(x,p). Die 

Zuordung ist in Tabelle 3.8 dargestellt. 

Unbekanntex Variable der Ntore 

x1 

x2 

x3 

x4 

x5 

x6 

x7 

x8 

U1Batterie 

U1Leitungen 

U2Leitungen 


U1Last 

I1Batterie 

I1Leitungen 

I2Leitungen 

I1Last 

Tabelle 3.8: Zuordnung der Variablen auf Unbekanntex 

Tabelle 3.9 zeigt alle Gleichungen auf, welche einerseits durch die Ntor- 

Instanzen “Batterie”, “Leitung” und “Last” andererseits durch die Sum-

3.4. BEISPIEL 61 

mengeber-Instanzen “Verbindungsstelle1” und “Verbindungsstelle2” formuliert 

werden. 

Gleichungen g(x,p) formulierende Instanz 

x5 · RBatterie +UqBatterie − x1 = 0 Batterie 

−x2 + x6 · RLeitung + x3 = 0 Leitung 

x6 + x7 = 0 

x4 − x8 · RLast = 0 Last 

x1 − x2 = 0 Verbindungstelle1 

x5 + x6 = 0 

x3 − x4 = 0 Verbindungsstelle2 

x7 + x8 = 0 

Tabelle 3.9: Gleichungssystem g(x,p) für das Beispiel 




Kapitel 4 

Framework 

Johnson [21] definiert ein Framework wie folgt: “A framework is a set of 

classes that embodies an abstract design for solutions to a family of related 

problems”. 


Der Begriff des Frameworks ist in Kapitel 2.5 allgemein erläutert worden. 

In diesem Kapitel wird ein Framework beschrieben, das das gemeinsame 

Programm-Design von Simulationsabläufen enthält wie sie bei vernetzbaren 

Entitäten auftreten. Das Framework bildet ein wichtiges Element der 

in Kapitel 5 beschriebenen Domänen-Architektur. 

Dieses Element besteht aus hart-codierten, eng-gekoppelten Klassen, 

die innerhalb ähnlicher Applikationen den stabilen Codeteil mit der vergleichsweise 

längsten Lebensdauer bilden. 

Das Framework definiert einerseits die gemeinsame Struktur von Newton-Raphson-Verfahren 

mit vernetzbaren Entitäten (siehe Kapitel 3) und 

legt andererseits Schnittstellen fest, an denen der Klient spezifischen Anpassungen 

vornimmt. Die Anpassung geschieht wie bereits in Kapitel 2 

beschrieben durch Ableitung weiterer Klassen, bzw. durch Überschreiben 

von bestimmten Methoden. 

Dieses Framework lässt sich innerhalb eines Bereichs von ähnlichen Simulationsproblemen 

anwenden. Dieser Anwendungsbereich wird in Kapitel 

3 aufgezeigt. 

Es wird die Implementation der Dienste beschrieben, die das Framework 

anbietet. Dies ist der Netzaufbau, die Netzberechnung und die Resultatausgabe. 

Dazu werden die benutzten Mechanismen und deren Implementation 

dargestellt. Für jeden einzelnen Dienst werden die für den 

63 


64 KAPITEL 4. FRAMEWORK 

Klienten wichtigen Programmschnittstellen (API, engl. Application Programming 

Interface) aufgezeigt. 

Das vorliegende Framework ist das Resultat einer iterativen Entwicklung. 

Das Framework wurde in konkreten Aufgabenstellungen (siehe Kapitel 

6) getestet und entwickelt. 

Abschliessend werden Entscheidungen bei der Implementation aufgezeigt, 

welche die Programmiersprache, die Bibliotheken und die Portierbarkeit 

des Frameworks betreffen. 

4.2 Anwendungsbereich 

Das Framework deckt einen bestimmten Bereich von Anwendungen ab. 

Dieser Bereich wird im Domänenmodell auf Seite 57 festgelegt. Für das 

in dieser Arbeit realisierte Framework gelten folgende zusätzliche Festlegungen: 

• Es sucht eine Lösung innerhalb einer maximalen Anzahl Iterationen 

und innerhalb einer Toleranz. 

• Pro Ntor lässt sich eine Variable überwachen. Ab einem parametrierbaren 

Konvergenzgrad wird geprüft, ob die überwachte Variable innerhalb 

eines Bereichs liegt. Liegt sie ausserhalb, wird das Verhalten 

des Ntors geändert und mit dem begrenzten Wert der Variablen als 

Anfangswert erneut eine Lösung gesucht. 

• Atomare Ntore: Keine Typenschachtelung 

4.3 Implementation des Domänen-Modells 

Dieser Abschnitt gibt einen Überblick über das aktuelle Framework. Es 

zeigt die Klassen, welche das in Kapitel 3 beschriebene Domänen-Modell 

darstellen. Die Klassen VNtor, VSummengeber, NetzObjekt, LinSolver 

und NewtonRaphson sind im Laufe der Entwicklung des Frameworks hinzugekommen. 

Alle Klassen sind eng-gekoppelt und erbringen zusammen 

die Dienste des Frameworks. Die Klassen leisten dabei ihren Beitrag je 

nach zugeordneter Verantwortung. Diese Beiträge werden bei den weiter 

unten beschriebenen Diensten im Einzelnen aufgeführt, sofern dies nicht 

bereits beim Domänen-Modell geschehen ist. 

Abbildungen 4.1 und 4.2 zeigen die statische Klassenstruktur auf. 


4.3. IMPLEMENTATION DES DOMÄNEN-MODELLS 65 

A 

Parameter Variable Anschluss 

B 

B spezialisiert A 

hat 

Parameter 

Adaptierbare Teile 

NetzObjekt 


Netz 

NewtonRaphson 

VNtor VSummengeber 

Ntor Summengeber 

Abbildung 4.1: “Ist-ein”-Beziehungen (is-a) zwischen Klassen 

0 oder >0, falls 

nichts angegeben 

genau ein 

0 oder 1 

Netz 

Ntor gehört zu Anschluss 

name name 

hat 

1+ 

Variable 

name name 

hat 

2+ 

hat 

hat 

verbunden mit 

Einzeilige Mehrzeilige 

Summe Summe 

1+ 1+ 

hat 

Einzeilige 

Summe 

hat 

LinSolver 

Abbildung 4.2: “Hat”-Beziehungen (has) zwischen Klassen 

Summengeber 

hat hat 

Mehrzeilige 

Summe


In der Abbildung 4.1 stehen die Basis-Klassen zuoberst. Weiter unten 

angesiedelte Klassen erben von den Basis-Klassen Daten (Attribute) und 

Verhalten (Methoden). 

4.4 Netzmodellierung 

Die hier dargestellten Klassen sind dafür verantwortlich, ein Netz aus Instanzen 

der beiden Klassen Ntor und Summengeber zu modellieren. 

• NetzObjekt: Identifiziert Objekte durch einen Namen. Die Identifikation 

bereits instantiierter Objekte wird beim Verknüpfen von 

Summengeber- und Ntoren benötigt. 

• Ntor: spezielle Ntor-Klasse, deren Verhalten vom Klienten spezifiziert 

wird. Der Konstruktor der Ntore hat die Form: 

typname(char* name [, Parametertyp Parameter ]) 

Die Parameter-Menge wird vom Klienten festgelegt. Es ist eine beliebige 

Anzahl Parameter möglich. Die Zeichenkette char* name identifiziert 

Ntor-Instanzen. Der Bezeichner typname identifiziert Ntor- 

Klassen. 

• Summengeber: spezieller Summengeber-Typ mit Namen 

typname, dessen Verhalten vom Klienten spezifiziert wird. Der Konstruktor 

der Summengeber hat die Form: 

typname(char* name [, Parametertyp Parameter ]) 

Die Parameter-Menge wird vom Klienten festgelegt. Es ist eine beliebige 

Anzahl Parameter möglich. Die Zeichenkette char* name identifiziert 

Ntor-Instanzen. Der Bezeichner typname identifiziert Ntor- 

Klassen. 

• VSummengeber: Diese Klasse implementiert die Summengeber-Basisklasse 

und stellt einen Platzhalter für die vom Klienten zu definierenden 

Summengeber-Typen dar. 

– InsertAnschluss(char* name, int i, VNtor* nt) 

Der Konstruktor erzeugt am Ntor nt einen Anschluss mit dem 

Index i und dem Namen name. 

• Netz: Dies ist ein Behälter, der den Objektbestand aus Ntor- und 

Summengeber-Typen speichert. Für beide Kategorien gibt es je eine 

einfach-gebundene Liste. Da erst zur Laufzeit bekannt ist, welcher 


4.5. NEWTON-RAPHSON-NETZBERECHNUNG 67 

aktuelle Typ in der Liste abzulegen ist, und C++ eine typenstrenge 

Sprache ist, ist ein allgemeiner Platzhalter anzugeben. Dies ist VNtor 

für die Ntor-Klassen und VSummengeber für die Summengeber- 

Klassen. Ntor- und Summengeber-Instanzen sind als Argumente mit 

den verlangten Typen zu kennzeichnen 1 

Methoden: 

– InsertNTor(VNTor* nt) 

Fügt die Ntor-Instanz nt ein. 

– InsertSumSetter(VSummengeber* sg) 

Fügt die Summengeber-Instanz sg ein. 

– InsertAnschluss(char* sname,char* n,int i) 

Verknüpft eine bereits geschaffene Summengeber-Instanz mit 

Namen sname mit einer Ntor-Instanz mit dem Namen n am Anschluss 

mit dem Index i. In der Summengeber-Instanz wird eine 

Anschluss-Instanz mit dem Index i eingefügt. Damit wird die 

Verbindung zwischen dem Summengeber und dem Ntor hergestellt. 

4.5 Newton-Raphson-Netzberechnung 

Der zentrale, algorithmische Dienst des Frameworks ist das Lösen eines 

nicht-linearen Gleichungssystems nach dem Newton-Raphson-Verfahren. 

Dieses Verfahren wird in drei Schritten implementiert: 

1. Zusammensetzen der Jacobimatrix und des Mismatch-Vektors aus dem 

lokal definierten Verhalten der Summengeber- und Ntor-Instanzen 

2. Lösen eines schwach-besetzten, linearen Gleichungssystems mit einem 

geeigneten Paket, das an den objekt-orientierten Programm-- 

Kontext angepasst ist 

3. Aktualisieren der Unbekannten in den Ntoren und Summengebern 

4.5.1 Beitrag des lokal definierten Verhaltens 

Das gesamte, nichtlineare Gleichungssystem g(x,p)=0 wird aus Instanzen 

von Ntoren und Summengebern zusammengebaut. 

1 engl. casting 



Anzahl Funktionen 

q 

1 

k 

ng 

1 

ng 

k 

s 

0 

k 

Anzahl Variable 

nv 

k 

Ntor 

k 

0 

1 1 1 1 

1 -1 

1 -1 

1 1 1 

A 

von Ntoren erzeugt 


nv 

von Summengebern erzeugt 

Abbildung 4.3: Struktur des schwachbesetzten, linearen Gleichungssystems 

Da die Lösung dieses Systems mit dem bekannten Newton-Raphson- 

Verfahren ermittelt wird, stellt die Matrix A (Siehe Abbildung 4.3) die 

Jacobi-Matrix dar. Der Vektor b entspricht den Mismatch-Werten und u 

den negativen Korrekturwerten, mit denen die Unbekannten pro Iterationsschritt 

verändert werden. Die symbolischen Ausdrücke der linearisierten 

Terme Aij und bi eines Newton-Raphson Iterationsschrittes werden nachfolgend 

dargestellt. 

Abbildung 4.3 zeigt die folgenden Zuordnungen: 

zum Ntork ⎧ gehörige Gleichungsterme: 

⎪⎨ :qk≤i


Aij = 

bi = 

⎧ 

⎪⎨ 

⎪⎩ 

1:qk ≤i


M 

C 

M 

B 

M 


A 

Abbildung 4.4: Rekursion und Polymorphie 

Kommunikation zwischen Summengeber und Ntor-Variable 

Ein wesentlicher Datenaustausch findet zwischen dem Summengeber und 

den Variablen in Ntoren statt. Die Summengeber bilden in jeder Iteration 

Summen von Variablen, die sich in den angeschlossenen Ntoren befinden. 

Die Summengeber greifen auf diese Werte zu, um die eigenen Mismatch- 

Werte zu berechnen. Diese Aufgabe delegiert der Summengeber an seine 

Elementarsummen. 

Abbildung 4.5 zeigt die drei Teilschritte: 

1. Zeiger auf Variable beschaffen 

2. Wert der Variablen holen 

3. Position der Variablen im Gleichungssystem berechnen (siehe Methode 

GetLfNr(), S. 74) 

4.5.3 Aufgabenverteilung auf Klassen 

Am Aufbau des Gleichungssystems sind folgende Klassen beteiligt: 

• NewtonRaphson: Diese Basisklasse legt das Protokoll aller am Newton-Raphson 

Algorithmus beteiligten Klassen fest. Alle davon abgeleiteten 

Klassen (siehe Kapitel 2.4.2) unterstützen dieses Protokoll, 

indem sie die hier angegebenen Methoden sinngemäss auf ihrer Stufe 

implementieren. In Anlehnung an Abbildungen 4.3 und 4.4, stellen 

k, sk, qk Indizes dar, die für alle Teilmatrizen und Vektoren verschiedener 

Objekt-Instanzen k gelten. Die Schnittstellen der Methoden 

dieser Basisklasse sind die Vereinigungsmengen der Parameter aller 

abgeleiteten Klassen. Andererseits implementieren nicht alle von dieser 

Basisklasse abgeleiteten Klassen alle Methoden. 

Die zugehörigen Methoden sind:


Summengeber Anschluss Ntor Variable 

1 

2 

3 

GetVar(Grundname) 

VarName = 

Grundname.index 

vp existiert 

vp -> GetValue 

Wert der Variablen 

GetOwnNtor 

nt existiert 

nt ->GetLfNr(vp) 

LfNr 

GetVar(VarName) 

vp existiert 

nt = Zeiger auf Ntor 

GetName 

name = VarName 

vp = Zeiger auf Variable 


name 

GetName 

name 

nt ->GetLfNr(vp) 

LfNr 

LfNr = LfNr + StartLfNr 

Abbildung 4.5: Datenaustausch Summengeber-Variable 

– void CountNonZeroes(int& nZ) 

Der Solver braucht, wie auf Seite 75 beschrieben, zur Initialisierung 

die Anzahl der Nichtnull-Elemente der gesamten “A”- 

Matrix. Die erbende Klasse addiert zu der Zahl nZ die Anzahl 

der Nichtnull-Elemente in ihrer “A”-Teilmatrix. 

– void SetFunStartLfNr(int& fnr) 

Die Instanz k setzt die Anfangszeile qk ihrer A-Teilmatrix auf den 

Wert fnrund addiert die Anzahl der Gleichungen ngk. 

– void SetVarStartLfNr(int& vnr) 

Die Instanz k setzt die Anfangsspalte sk ihrer A-Teilmatrix auf 

den Wert vnr und addiert die Anzahl ihrer Variablen nvk. 

– void InsertRVar(RVar* rv) 

Fügt eine Variable in die Menge Vk eines Ntors k ein. 

– void InsertRPar(RPar* rp) 

Fügt einen Parameter in die Menge Pk eines Ntors k ein. 

Zeit


– RVar* GetVar(char* name) 

Holt eine Variable mit Namen name aus der Menge Vk eines 

Ntors k. 

– RPar* GetPar(char* name) 

Holt einen Parameter mit Namen name aus der Menge Pk 

– double GetAElem(int i, int j, int state) 

Die Instanz k liefert das Element Aqk+i,sk+ j ihrer Teilmatrix A für 

einen Zustand state. Bei zustandslosen Instanzen ist der Parameter 

state wirkungslos. 

– double GetbElem(int i, int state) 

Die Instanz k liefert das Element bqk+i ihres Teilvektors b für 

einen Zustand state. Bei zustandslosen Instanzen ist der Parameter 

state wirkungslos. 

– void PutSolver(LinSolver& solver) 

Die Instanz k füttert den Solver solver mit der “A”-Teilmatrix und 

dem “b”-Teilvektor. 

– void GetFromSolver(LinSolver& solver) 

Holt die Korrekturwerte für die Variablen xi ,i = sk ...sk +nvk 

der Instanz k aus der Lösung des gesamten Gleichungssystems 

und addiert sie zu diesen Variablen. 

– void GetMaxMismatch(double& MaxMism) 

Der maximale Mismatch ist eine Kenngrösse, an welcher der 

Konvergenzverlauf des Newton-Raphson-Verfahrens erkennbar 

ist. Wie in Kapitel 3.1.4 beschreiben, ist der maximale Mismatch 

der betragsmässig grösste Wert der einzelnen Abweichungen 

der Funktionswerte. Die Instanz k berechnet ihre bi im Bereich 

i = qk ...qk+ngk und überschreibt MaxMism, falls ein betragsmässig 

grösserer Wert auftritt. 

– int Limiter() 

Testet und meldet, ob eine Variablen-Grenze aktiv wurde. Falls 

dies eintrat, wird entsprechend der Ntor-Spezifikation das Verhalten 

BN σi (Vσi ,Pσi ,E σi ,Tσi ) des Nachfolgezustandes σi eingerichtet. 

– double CheckLimits(double v, min, max) 

Begrenzt einen Wert v auf das Band zwischen min und max und 

meldet, ob v begrenzt wurde. 



– void PrintVarsAndPars() 

Diese Methode implementiert den Dienst Resultatausgabe. Die 

Resultatausgabe erfolgt auf die Standard-Ausgabe des Betriebssystems. 

Liefert die aktuellen Werte der Mengen Vk und Pk einer 

Instanz k. 

• Netz: Die Klasse Netz ist mit folgenden Methoden an der Netzberechnung 

und Resultatanzeige beteiligt: 

– Netz(char* name, char* F, char* file) 

Der Konstruktor liest Netzdaten und interpretiert diese gemäss 

dem gewählten Tauschformat F. Dabei wird ein Objektbestand 

im Netz-Objekt abgespeichert und für die Berechnung vorbereitet. 

Falls die Anzahl der Variablen und Funktionen nicht übereinstimmt, 

ist ein späterer Aufruf der Methode Calculate wirkungslos. 

– Calculate(int maxIter, double dfein, double dgrob) 

Versucht innerhalb maxIter Iterationen und einer Mismatch-Toleranz 

von dfein eine Lösung zu finden. Testet dabei ab einer 

zweiten, gröberen Mismatch-Toleranz dgrob, ob das Verhalten 

von Ntoren aufgrund aktiv gewordener Variablengrenzen zu ändern 

ist. Falls dies zutrifft, wird das Verhalten gemäss Spezifikation 

des Ntors geändert und ein neuer Newton-Raphson-Prozess 

mit den auf die Grenzen gesetzten Variablen als Anfangswerte 

gestartet. Abbildung 4.6 zeigt den Programmablauf. Die Methode 

hat folgende mögliche Resultate: 

1. Keine Rechnung, wegen Netzfehler. Ein Netzfehler tritt auf, 

wenn die Anzahl der Variablen und Funktionen nicht übereinstimmt, 

oder versucht wurde, nichtexistente Bausteine miteinander 

zu verbinden. 

2. Fehler wegen linear abhängiger Gleichungen oder numerischer 

Probleme, z.B. Division durch Null 

3. konvergierter Prozess ohne Zustandsänderung in Ntoren 

4. konvergierter Prozess mit Zustandsänderung in Ntoren 

5. divergierender Prozess 

• ElektroObjekt: Diese Klasse liefert die Identifikation eines Objektes 

durch einen eindeutigen Namen. Im Zuge der Netzberechnung bedarf 



es des Zugriffs auf identifizierbare Variable im Namensraum einer 

Ntor-Instanz. 

– char* GetName() 

Liefert den Namen (Zeichenkette) eines Objektes im Netzbestand. 

• Variable: Diese Klasse stellt eine Variable xi im Gleichungssystem 

dar und ist stets in Ntor- oder in Elementarsummen beheimatet. 

– Variable(char* name, int lfNr, double* var) 

Der Konstruktor erzeugt eine Variable mit dem Namen name. 

Die Variable ist lokal an der Stelle sk+lfNr einer Ntor- oder Elementarsummen-Instanz 

k angeordnet. Diese Anordnung muss 

konsistent sein mit der erzeugten Jacobi-Matrix und dem Unbekannten-Vektor. 

Über den Zeiger var wird die Verbindung zwischen 

Laufzeit-Namen der Variablen und dem zur Übersetzzeit 

bekannten Speicher-Symbol hergestellt. Das Speichersymbol wird 

für die Berechnung der Teilmatrizen und Teilvektoren benutzt. 

– double GetValue() 

Gibt den Wert einer Variablen. 

– double SetValue(double Value) 

Setzt den Wert einer Variablen. 

– int GetLfNr() 

Gibt die zur Festlegung der Reihenfolge der Variablen notwendigen 

Laufnummer lfnrinnerhalb einer Ntor-Instanz k an. Zusammen 

mit dem Wert sk ist der Index der Variable xi im gesamten 

Gleichungssystem berechenbar: 

i = sk + lfnr 

• Parameter: Diese Klasse stellt einen Parameter pi im Gleichungssystem 

dar und ist stets entweder in Ntor- oder in Elementarsummen- 

Instanzen beheimatet. 

– Parameter(char* name) 

Der Konstruktor erzeugt einen Parameter mit dem Namen name. 

• Anschluss: Diese Klasse implementiert die Verbindung zwischen 

Summengeber und Ntor. 



– Anschluss(char* name, int i, VNtor* nt) 

Der Konstruktor erzeugt am Ntor nt einen Anschluss mit dem 

Index i und dem Namen name. 

– Variable* GetVar(char* name) 

Implementiert die Zugriffsfunktion Vk(basename,i) auf eine Variable 

im zugehörigen Ntor k. In der Zeichenkette name ist 

basename und Index i zusammengehängt. 

• VSummengeber: Diese Klasse implementiert die Summengeber-Basisklasse 

und stellt einen Platzhalter für die vom Klienten zu definierenden 

Summengeber-Typen dar. 

– InsertAnschluss(char* name,int i,VNtor* meinNTor) 

Der Konstruktor erzeugt am Ntor meinNTor einen Anschluss mit 

dem Index i und dem Namen name. 

• VNtor: Diese Klasse implementiert die Ntor-Basisklasse und stellt 

einen Platzhalter für die vom Klienten zu definierenden Ntor-Typen 

dar. 

4.5.4 Lösen des linearen Gleichungssystems 

Das Lösen des linearen Gleichungssystems A · x = b geschieht mit einem 

bewährten und leistungsfähigen Softwarepaket aus der mathematischen 

Domäne. Dieses Paket besteht aus einzelnen Unterprogrammen. Es löst 

schwachbesetzte Gleichungssysteme mit der Genauigkeit des C oder C++- 

Typs “Double”. Es ist innerhalb der Klasse LinSolver gekapselt. Dadurch 

kann das Paket im objekt-orientierten Programm-Kontext des Frameworks 

benutzt werden. Die Klasse LinSolver hat folgende Schnittstelle: 

• LinSolver(int n, int nzmax) 

Der Klassen-Konstruktor benötigt die Dimension des Gleichungssystems 

n, sowie die Anzahl der Nicht-Nullelemente nzmax in der Matrix 

A. Je nach Wert dieser Parameter wird Speicher alloziert, der im 

Destruktor wieder freigegeben wird. 

• fillVector(double bi, int i) 

Schreibt bi i = 0,1,...,n−1 

• double readVector(int i) 

Gibt bi i = 0,1,...n−1 



ja 

ja 

Netzfehler 

? 

nein 

AnzIterationen = 0 

AnzIterationen 

> maxIter ? 

MaxMismatch = 0 

Anzahl Nichtnull-Elemente = 0 

Nichtnull-Elemente zählen 

LinSolver-Objekt 

instantiieren 

A und b aufbauen 

Gleichungssystem 

lösen 

ja 

Start 

Lösung 

verarbeiten 

dgrob>= nein 

MaxMismatch 

? 

ja 

Variablengrenzen testen und Variablen begrenzen 

Verhaltensänderung in Ntoren mit begrenzter Variable 

gibt es 

nein 

verletzte Grenzen 

? 

ja 

Anfangsspalten und -zeilen 

der Matrizen und Vektoren 

aller Ntore und Summengeber 

berechnen 

LinSolver-Objekt vernichten 

Ende 

nein 

Fehler 

? 

nein 

MaxMismatch berechnen 

Parameter: maxIter, dgrob, dfein 

AnzIterationen um 1 erhöhen 

MaxMismatch = 

dfein>= 

MaxMismatch 

? 


b i max 

ja 

nein 

konvergiert 

über alle instantiierten Funktionen 

Abbildung 4.6: Programmablauf in Calculate 

nein 

MaxMismatch 

>> 0 ? 

ja 

divergiert

4.6. PROGRAMMIER-SCHNITTSTELLEN (API) 77 

• fillMatrix(double Aij, int i, int j) 

Schreibt Aij i,j=1,2,...,n 

• int Solve() 

Löst das Gleichungssystem und signalisiert Erfolg oder Misserfolg. 

• double ReturnSolution(int i) 

Liest xi , i = 0,1,...,n−1 

4.6 Programmier-Schnittstellen (API) 

Der Klient muss vom Framework mehr wissen, sobald er Dienste ändert. 

Falls es dafür noch keine passenden Adaptionselemente gibt, muss er in 

der Lage sein, diese zu bauen. Ein weiterer Grund kann darin liegen, dass 

der Klient das vorgeschlagene Default-Programm ersetzen muss, weil z.B. 

mehrere Newton-Raphson-Prozesse pro Simulation zu starten sind. Der 

Klient benutzt das Framework über die beiden grundsätzlich verschiedenen 

Programmierschnittstellen: 

1. Aktives API: Der Klient instantiiert selber Objekte des Frameworks 

und ruft ihre Methoden auf. Alle als “public” definierten Klassen 

und Methoden sind vom Klienten benutzbar. Der Klient benutzt das 

Framework hier im Sinne einer Klassenbibliothek (vergl. Black-Box- 

Ansatz in Kapitel 2). Pro Klasse muss der Klient wissen, wofür ein 

Objekt verantwortlich ist, was die einzelnen Methoden tun und wie 

die Schnittstellen aussehen. 

Der Klient ist für die Instantiierung, den Programmablauf und die Interaktion 

zwischen solchen Objekten verantwortlich. Das Framework 

legt kein Default-Verhalten fest. 

2. Passives API: Dies sind die adaptierbaren Stellen F im Framework, 

die der Klient an seine Applikation anpasst. Der Klient überschreibt 

dabei Methoden an dafür vorgesehenen Stellen des Frameworks (vergl. 

White-Box-Ansatz in Kapitel 2). Der Klient braucht sich dabei weder 

um die Objektinstantiierung noch um den Programmablauf der adaptierten 

Methode und seines Objektes zu kümmern. Das Framework 

ruft diese Methoden in der richtigen Reihenfolge auf und liefert ein 

Default-Verhalten, falls der Klient keine Adaption vornimmt. 



Kontext Passives API Aktives API 

aufrufendes Netz-Konstruktor 

Programm Netz::Calculate 

Netz::PrintVarsAndPars 

Konstruktor Konstruktor der Basisklasse: VNtor(name) 

InsertVariable, InsertParameter 

Ntor- Konstruktoren Variable und Parameter 

Adaption GetAElem 

GetbElem 

PrintVarsAndPars 

Limiter 

SwitchState Listen:append/pop und CheckLimits 

Konstruktor Konstruktor der Basisklasse: 

VSummengeber(name) 

Summengeber- Konstruktoren der Elementarsummen 

Adaption Elementarsumme hinzufügen 

PrintVarsAndPars Iterator über Elementarsummen 

Netz- Konstruktor Konstruktor Ntor und Summengeber 

Aufbau InsertNtor, InsertSummengeber, 

InsertAnschluss 

Tabelle 4.1: API’s des Frameworks 

Andererseits muss der Klient wissen, was die Methoden, die er hier 

überschreibt, im Framework leisten sollen. Er muss das Protokoll 

des adaptierten Dienstes kennen. Ferner muss er das aktive API im 

Kontext dieser Methoden kennen, um die vorgesehene Leistung programmieren 

zu können. 

Die Methoden “append” und “pop” gehören zu der generischen Klasse 

(LEDA) zur Verwaltung von Listen. Die Methode “append” fügt ein Objekt 

in eine Liste, “pop” holt ein Objekt aus einer Liste. Das Framework 

enthält insgesamt 14 Klassen mit insgesamt 64 unabhängigen Methoden. 

Davon müssen für den Klienten 20 Methoden des aktiven und 8 Methoden 

des passiven API’s dokumentiert werden. 

4.7 Implementation 

Im Kapitel 2 sind die objekt-orientierten Konzepte beschrieben, die bei der 

Implementation des Frameworks benutzt werden. Ferner wird aufgezeigt, 

welche externen Bibliotheken eingesetzt werden. 


4.7. IMPLEMENTATION 79 

4.7.1 C++ 

Als Programmsprache des Frameworks wurde C++ verwendet [27, 28]. 

Die Sprache C++ unterstützt die objekt-orientierte Programmierung. Ferner 

ist die Implementation der Adaptionsphase in der Domänen-Architektur 

zu berücksichtigen. Maple V kann C-Code erzeugen. Dieser ist problemlos 

in C++ einbaubar. Ferner gibt es sehr viele und öffentlich zugängliche 

Programm-Bibliotheken, die in C++ geschrieben sind. Die Kompilation 

erfolgt mit g++ von Free Software Foundation. 

Die hart-codierten Klassen des Frameworks können grundsätzlich in jeder 

Sprache formuliert werden, die folgende objekt-orientierten Konzepte 

unterstützt: 

1. einfache und mehrfache Vererbung 

2. Polymorphismus 

3. Kapselung 

Das Framework ist in einem defensiven Stil entwickelt, d.h. es sind keine 

Spezialitäten von C++ ausgenutzt. Die Polymorphie wird durch die 

Verwendung von abstrakten Basisklassen realisiert. Das Hineinmischen 

von Eigenschaften in eine Klasse geschieht durch Mehrfachvererbung. Die 

“Friend-Funktion” wird nicht benutzt. Damit kann grundsätzlich jede andere 

Sprache verwendet werden, die das OO-Paradigma unterstützt. Das 

Domänenmodell wird mittels der Objekt-Modellierungstechnik [20] in zwölf 

hart-codierte und zwei generische Klassen “VNtor” und “VSummengeber” 

übertragen. 

4.7.2 Bibliotheken 

DerSolverfür die Lösung von schwachbesetzten Gleichungssystemen stammt 

aus dem FORTRAN “UMF-package” [29]. Dieses Paket berechnet nach 

der Methode “unsymmetric-pattern multifrontal” ein Gleichungssystem der 

Form Ax = b. Das Paket baut auf dem Fortran BLAS Toolkit auf. Es wird 

mit der Genauigkeit des Datentyps DOUBLE PRECISION gerechnet. Die 

FORTRAN77-Prozeduren wurden in C übersetzt und in dieser Form innerhalb 

der C++-Klasse “LinSolver” gekapselt. 

Für gebundene Listen wurden Template-Klassen aus der C++-LEDA 

Bibliothek [30] verwendet. 




Kapitel 5 

Domänen-Architektur 

Das NIST [15] definiert eine Domäne als “a distinct functional area that 

can be supported by a class of Software Systems with similar Requirements 

and capabilities. Domain may exist before there are Software Systems to 

support it”. Der Begriff Domänen-Architektur definiert die gleiche Stelle 

als “a generic, organizational structure or design for software systems in a 

domain”. 


Als Ergebnis der Domänenanalyse ist ein Domänenmodell gefunden worden. 

Dieses Modell deckt die Anforderungen der Domäne ab. In einem 

weiteren Schritt ist daraus ein wiederverwendbares Stück Software in 

Form eines Frameworks abgeleitet worden. Ein Klient kann dieses Framework 

benutzen, sofern seine Aufgabenstellung diese Anforderung enthält. 

Nicht alle Anforderungen des Domänenmodells sind aber innerhalb des 

Frameworks erfüllbar. Es gibt darin keine symbolische Berechnung, um 

z.B. Jacobi- und Mismatchterme für eine Lastflussrechnung zu bilden. Der 

Klient hingegen will das veränderliche Verhalten seiner Bausteine auf hohem 

Abstraktionsniveau beschreiben und verändern. Daher gibt es eine 

Lücke zwischen der abstrakten Notation der Gleichungen und der Programmiersprache 

des Frameworks (C++). Diese Lücke soll geschlossen 

werden, um den Klienten von der fehlerträchtigen und mühsamen Arbeit 

zu befreien, Gleichungen in der Programmiersprache des Frameworks zu 

codieren. Der Klient ist daher auf eine konsistente Umsetzung auf die Implementationsebene 

angewiesen. 

Bei dieser Umsetzung sind etliche Teile involviert. Neben dem Framework 

sind einige andere Elemente beteiligt, welche die Anforderungen der 

81 


82 KAPITEL 5. DOMÄNEN-ARCHITEKTUR 

Domäne erbringen. Es ist daher sinnvoll, diese Komplexität herunterzubrechen 

und eine hilfreiche Struktur zu finden. Es soll Konformität der 

Elemente und ihrer Verbindungen angestrebt werden, um die Wahrscheinlichkeit 

für ihre Wiederverwendbarkeit in ähnlichen Aufgabenstellungen 

zu fördern. Daneben soll die Verständigung zwischen involvierten Entwicklern 

erleichtert werden. Dies kann einerseits unter Klienten als auch 

zwischen dem Klienten und dem Framework-Entwickler der Fall sein. 

Das hier notwendige Strukturierungsmittel ist eine Domänen-Architektur 

(DA) (vergl. Kapitel 2, S. 14). 

Unter den vielen verschiedenen Definitionen des Begriffs Architektur 

im Zusammenhang mit Software, scheint in der Literatur in folgenden 

Punkten Übereinstimmung zu herrschen, dass eine DA 

• die Struktur 

• die Elemente 

• den Kommunikations-Mechanismus zwischen Elementen 

• die Richtlinien für die Benutzung und Weiterentwicklung der Architektur 

innerhalb einer bestimmten Domäne festlegen sollte. 

Auf der Grundlage von Erfahrungen, die im Laufe der Framework- 

Entwicklung und der in Kapitel 6 beschriebenen Fallstudien gemacht wurden, 

ist eine Struktur von Elementen gefunden worden. Diese Struktur und 

die darin angesiedelte Elemente werden in diesem Kapitel beschrieben. 

Die wesentlichen Dienstleistungen, d.h. die Anforderungen der im Kapitel 

3 beschriebenen Domäne, werden in der DA durch verschiedene Dienste 

formuliert. In der vorliegenden Arbeit sind dies die Dienste Netzaufbau, 

Netzberechnung und Resultatausgabe. Die Dienste werden von der 

DA in Zusammenarbeit mit dem Framework erbracht. Die Aufgabenteilung 

zwischen diesen Teilen wird in diesem Kapitel im Einzelnen aufgezeigt. 

Dabei werden die Elemente der DA zunächst auf der konzeptionellen 

Ebene dargestellt. In einem weiteren Schritt wird aufgezeigt, wie die 

Elemente implementiert sind. Anhand konkreter Bausteine wird gezeigt, 

wie der Dienst Netzberechnung für die Lastflussrechnung spezifiziert und 

adaptiert wird. Ferner wird der Dienst Netzaufbau basierend auf dem Netzdatenformat 

[23] dargestellt. Das Kapitel schliesst mit einer Betrachtung 

der DA aus der Sicht des Klienten. 


5.2. SICHTEN 83 

5.2 Sichten 

Die DA lässt sich anhand der in der Arbeit ausgeführten Untersuchungen 

wie in Abbildung 5.1 darstellen. Die räumliche Anordnung der Elemente 

widerspiegelt die Struktur der DA. Jede räumliche Dimension verkörpert 

dabei eine Sicht. 

5.2.1 Architekturebenen 

Die DA ist in drei Ebenen aufgeteilt. 

In der ersten Ebene werden alle veränderlichen Teile der in der DA erbrachten 

Dienste (Netzaufbau, Netzberechnung, Resultatanzeige) erfasst. 

Dies bedeutet, dass die Variabilität und eine dafür geeignete Parametrierung 

festgelegt wird. Ferner gehört eine Verwaltung dazu, die konkrete 

Parameterwerte entgegennimmt und speichert, damit nachfolgende Operationen 

sie auffinden und weiterverarbeiten können. 

Die zweite Ebene enthält die gemeinsamen und daher konstanten Anteile 

der vom Framework erbrachten Dienste. Dies entspricht dem nichtgenerischen 

und konstanten Anteil des Domänenmodells. Das Framework 

bietet, wie in Abbildung 5.1 ersichtlich, für jeden Dienst passende Stellen, 

an denen die adaptierbaren Teile aufgesteckt werden, die das variable 

Verhalten eines Dienstes verkörpern. 

Innerhalb der dritten Ebene wird ein vom Klienten angepasstes Framework 

erzeugt und zusammengesetzt, das er in seiner Applikation oder im 

Default-Programm einsetzen kann. 

Das Default-Programm erzeugt eine Instanz des Frameworks, das so 

adaptiert ist, dass damit ein Lastfluss basierend auf Netzdaten im Format 

von [23] berechnet werden kann. 

5.2.2 Dienste 

Dies sind die Leistungen, die das aktuelle Framework erbringt. Es sind 

Teilaufgaben, die ein Klient in seiner Applikation wiederverwenden kann. 

Dies ist der Netzaufbau, die Netzberechnung und die Anzeige von Resultaten. 

Zu jedem Dienst gehört eine Methode der Framework-Klasse “Netz”, 

über die der Klient einen bestimmten Dienst aufruft. 

Ein Dienst wird innerhalb des Frameworks von der zugehörigen Methode 

in der Klasse “Netz” und unter Mitwirkung der Bausteine erbracht. 



Anteil 

Bausteine 

Spezifikation 

Adaption 

Framework 

Anteil Netz 

S1 

Σ 

V V V 

1 2 3 

A 1 

F 1 

Berechnung 

S 2 

A 2 

F 2 

Dienste des Frameworks 

Σ 

Netzaufbau 

Variabilität 

pro Dienst 

Integration ins 

Quelltext des Laufzeitsystem 

adaptierten Frameworks 

Abbildung 5.1: Sichten der DA 


S 3 

A 3 

F 3 

Resultate 

Σ 

Architekturebene 

Variabilität 

Gemeinsamkeit

5.2. SICHTEN 85 

~ 

~ 

Aufruf Dienst i 

= 

Objekt "Netz" 

Σ 

= 

Bausteine 

~ 

= 


= 

~ 

Abbildung 5.2: Objekt-Beteiligung an Diensten 

Objekt-Methoden 

für den Dienst i 

Konstanter Anteil 

Variabler Anteil 

Ein Dienst kann grundsätzlich einen variablen und einen konstanten 

Anteil haben. 

Ein Beispiel dafür ist der Netzaufbau aus verschiedenen Tauschformaten. 

Die Unterschiede der Behandlung, die von den verschiedenen Formaten 

herrühren, entsprechen dem variablen Anteil. Wie aus Abbildung 5.2 

ersichtlich, wird ein Dienst durch Mitwirkung von Methoden der Objekte 

Netz und Bausteine erbracht. Die Methoden können ihrerseits einen konstanten 

und variablen Anteil aufweisen, sofern dies bei der Entwicklung 

des Frameworks vorgesehen wird. 

Es ist eine grundsätzliche Schwierigkeit bei der Entwicklung des Frameworks, 

für die variablen Anteile eines Dienstes geeignete, erweiterbare 

Stellen im Framework zu identifizieren. Dies trifft insbesondere für die 

Methoden in der Klasse “Netz” zu. Hier muss man zur Entwicklungszeit 

des Frameworks wissen, ob und an welcher Stelle eine adaptierbare Methode 

aufzurufen ist. 

Der Klient soll den variablen Anteil eines Dienstes spezifizieren und 

im Framework adaptieren können. Die DA ordnet daher jedem Dienst die 

Elemente Spezifikation, Adaption und passives API 1 des Frameworks zu. 

In konventionellen Systemen, die auf relationalen Datenbanken aufbauen, 

werden Dienste normalerweise in Subsystemen organisiert, z.B. eines 

für die Berechnung und eines für ein graphisches Benutzer-Interface. Im 

vorliegenden Ansatz werden solche Subsysteme am Objekt selber gebildet 

1 Application programming interface


und integriert. Es steht daher zur Programmlaufzeit nicht mehr eine Datenbank 

im Zentrum, sondern ein Baustein-Objekt, das verschiedene Dienste 

integriert, indem es Methoden und Attribute für die gewünschten Dienste 

bei sich vereinigt. In der DA sind Ntore und Summengeber in dieser Weise 

aufgebaut und erweiterbar. 

5.2.3 Variabilität innerhalb der Dienste 

Wie in Kapitel 5.2.2 bereits ausgeführt, werden Dienste unter Mitwirkung 

verschiedener Objekte des Frameworks realisiert. Dies sind einerseits die 

Bausteine. Jeder Baustein-Typ kann in unterschiedlicher Weise an Diensten 

mitwirken. So hat beispielsweise jeder Baustein-Typ beim Dienst Netzberechnung 

eine eigene Berechnung seiner Jacobi-Blockmatrix und des 

Mismatch-Vektors. 

Diese Typvielfalt der Bausteine ist die Dimension senkrecht zur Blattebene 

von Abbildung 5.1. Je mehr Typen der Klient definiert, desto umfangreicher 

wird der Stapel der Spezifikationsdaten und die daraus erzeugten 

Framework-Adaptionen. Der Umfang der Adaption wächst nicht zwingend 

mit der Typenvielfalt der Bausteine. Für die Netzberechnung bei der 

Lastfluss-Applikation ist es möglich, die Adaption durch zwei parametrierbare 

Codegeneratoren für Ntore und Summengeber zu realisieren. 

Anderseits liegt eine Quelle von Variabilität in Varianten eines Dienstes 

selber. Als Beispiel sei hier der Dienst Netzaufbau erwähnt. Hier sind 

einige Möglichkeiten vorhanden. Der Netzaufbau kann 

• aus sequentiellen Netzdaten eines bestimmten Tauschformats 

• aus einer Datenbank in einem bestimmten Format 

• aus Aktivierung/Passivierung des Netzbestandes innerhalb einer Anwendung 

erfolgen. 

5.3 Architektur-Elemente 

Hier folgt die Beschreibung der einzelnen Elemente der Architektur und 

ihrer Funktion. Die Elemente werden in diesem Kapitel unter verschiedenen 

Gesichtspunkten dargestellt. Daher werden zunächst alle Symbole 

definiert, die in diesem Kapitel verwendet werden. Die Symbole werden 


5.3. ARCHITEKTUR-ELEMENTE 87 

benötigt, um den Zusammenhang zwischen verschiedenen Sichten und der 

Element-Beschreibung herzustellen. Die Art der Indizierung unterscheidet 

die Gesichtspunkte. 

Folgende Mengen definieren jeweils einen Anwendungsfall: 

NT Menge der Ntor-Typen, die der Klient definiert oder verwendet 

ST Menge der Summengeber-Typen, die der Klient definiert und 

verwendet 

D Menge der verwendeten und bestehenden Dienste des Frameworks 

mit variablem Anteil in einer Methode der Klasse 

“Netz”. 

VK Menge der Basisnamen von Variablen pro elektrischem Anschluss, 

die der Klient definiert oder verwendet. 

Spezifikation: 

Si Spezifikation, die mindestens die Variabilität des Dienstes i 

beschreibt. “Mindestens” deshalb, weil Si auch Variabilität 

beschreiben kann, die auch für einen anderen Dienst j, i = j 

SNi 

SN 

SΣi 

SΣ 

SNetzij 

benutzt werden kann. 

Spezifikation des variablen Anteils eines Ntor-Typs mindestens 

für eine Beteiligung am Dienst i, wobei i = 0 den Klassenkonstruktor 

bezeichnet. 

Spezifikation des variablen Anteils eines Ntor-Typs. 

Spezifikation des variablen Anteils eines Summengeber-Typs 

für mindestens eine Beteiligung am Dienst i, wobei i = 0den 

Klassenkonstruktor bezeichnet. 

Spezifikation des variablen Anteils eines Summengeber-Typs. 

Spezifikation j des variablen Anteils einer oder mehrerer Methoden 

der Klasse “Netz” für den Dienst i. 



Spezifikationsdaten: 

Vi Spezifikationsdaten, die mindestens die Variabilität des 

Dienstes i parametrieren. 

Spezifikationdaten des variablen Anteils eines Ntor-Typs für 

VNi 

VN 

VΣi 

VΣ 

eine Beteiligung am Dienst i. 

Spezifikationdaten des variablen Anteils eines Ntor-Typs. Vereinheitlichter 

Datensatz (Menge von Variablen mit Namen und 

Datentyp), das alle in NT angegebenen Summengeber-Typen 

und alle in D angegebenen Dienste einschliesst. 

Spezifikationdaten des variablen Anteils eines Summengeber- 

Typs für eine Beteiligung am Dienst i. 

Spezifikationdaten des variablen Anteils eines Summengeber- 

-Typs. Vereinheitlichtes Datenformat, das alle in ST angegebenen 

Ntor-Typen und alle in D angegebenen Dienste einsch- 

liesst. 

VNetzij Spezifikationdaten j des variablen Anteils einer oder mehrerer 

Methoden der Klasse “Netz” für Dienst i. 

Adaption: 

Ai Adaption aller am Dienst i beteiligten, variablen Teile des Frameworks 

AN Adaption des variablen Anteils eines Ntor-Typs 

AΣ Adaption des variablen Anteils eines Summengeber-Typs 

Adaption des variablen Anteils k der Klasse “Netz” für 

ANetzik 

den Dienst i 

ANetzi Adaption aller variablen Anteile der Klasse “Netz” für 

den Dienst i 

Adaptierte Teile des Frameworks: 

Fi Adaptierte Teile des Frameworks für Dienst i 

FN Adaptierter Anteil eines Ntor-Typs 

FS Adaptierter Anteil eines Summengeber-Typs 

Adaptierte Methode k der Klasse “Netz” für Dienst i 

FNetzik 

5.3.1 Domänenmodell 

Das Domänenmodell ist ein integraler Bestandteil der DA, denn es verkörpert 

die gemeinsamen Anforderungen der Domäne. 

Ein Hauptmerkmal des Domänenmodells sind die beiden generischen 

Bausteine Ntor und Summengeber. Dies sind die Typen, die innerhalb der 

Domäne für einzelne Dienste parametrierbar sind. Die dadurch entstehen- 


5.3. ARCHITEKTUR-ELEMENTE 89 

de Variabilität muss von der DA bewältigt werden. 

Daher hat das Domänenmodell zentralen Einfluss auf die Struktur und 

die Elemente der DA. Änderungen des Modells haben Konsequenzen für 

die Architektur. 

5.3.2 Spezifikationselement 

In diesem Element formalisiert der Klient veränderliche Teile der Dienste. 

Das Spezifikationselement ist in der Lage, aktuelle Parameter entgegenzunehmen, 

abzuspeichern und der nachfolgenden Adaption zur Verfügung 

zu stellen. Veränderliche Teile lassen sich sowohl den Bausteintypen als 

auch den Diensten zuordnen. Der Ansatz unterstützt eine objekt-orientierte 

Struktur der Spezifikation. Ferner berücksichtigt er die Tatsache, dass es 

Spezifikationen gibt, die zu Diensten und nicht zu Bausteinen gehören. 

5.3.3 Spezifikationsdaten 

Die Spezifikation liefert aktuelle Parameter als Daten. Die Daten sollen die 

Adaption der variablen Teile des Frameworks steuern. Es muss prinzipiell 

möglich sein, dass eine Adaption Ai auf Spezifikationen S j,i = j anderer 

Dienste zugreifen kann. Es hat sich herausgestellt, dass beispielsweise 

der Netzaufbau ein Dienst ist, der zur Netzdaten-Interpretation neben den 

variablen Anteilen des Dienstes Netzaufbau einige variable Anteile des 

Dienstes Netzberechnung kennen muss (siehe S. 120). 

5.3.4 Adaption 

Ein weiteres Element Ai erzeugt aus Spezifikationsdaten S j den Code für 

die adaptierbaren Stellen Fi des Frameworks. Die Adaption erzeugt damit 

neuen Code innerhalb der Domäne. Der neue Code bildet eine konsistente 

Schnittstelle zwischen der gewählten Spezifikationssprache und der Sprache 

des Frameworks. Die Sprache des Frameworks ist durch sein API 

festgelegt. In der DA gibt es für jeden Dienst eine solche Schnittstelle. 

5.3.5 Framework 

Dieses Element ist das objekt-orientierte Kernstück der DA. Es ist im Kapitel 

4 beschrieben. Das Framework kapselt das gemeinsame Verhalten 

der Domäne und schirmt den Klienten von den Einzelheiten der inneren 



Beziehungen ab. Andererseits stellt es Adaptionsstellen (passives API) 

zur Verfügung, die das unterschiedliche Verhalten enthalten. Die Adaptionsstellen 

Fi in Abbildung 5.1 stellen diese Ankopplungsstellen für die 

variablen Teile der Dienste dar. Das Framework bietet für jeden Dienst i 

eine Adaptionsstelle Fi an. 

5.3.6 Zusammensetzung des Frameworks 

Dieses Element baut aus den adaptierten und konstanten Einzelteilen des 

Frameworks einen ausführbaren Quelltext zusammen. Dieser Prozess wird 

durch folgende Angaben des Klienten gesteuert: 

1. Menge der verwendeten Ntor-Typen NT 

2. Menge der verwendeten Summengeber-Typen ST 

3. Menge der benutzten Dienste D 

4. Menge von Basisnamen, die für jeden elektrischen Anschluss (automatisch) 

zu spezifizieren sind 

Der Aufbauprozess benötigt für jeden benutzten Dienst die verlangten 

Spezifikationen und Adaptionen. Der Klient liefert die für seinen Anwendungsfall 

geeignete Spezifikation und Adaption. 

Der Klient benutzt dann den zusammengebauten Quelltext, indem er 

ihn übersetzt, in seinen Kontext bindet und als Netz-Objekt instantiiert. 

Dieser Kontext kann das Default-Hauptprogramm oder sonst ein Quellprogramm 

des Klienten sein. 

5.4 Implementation 

In diesem Unterkapitel wird aufgezeigt, wie die Adaption des Frameworks 

und die einzelnen Elemente der DA implementiert sind. Als grundlegende 

Randbedingungen sind dabei folgende beiden Punkte von zentraler Bedeutung: 

1. Die symbolische Berechnung wird benötigt, damit der Klient Gleichungen 

auf hohem Abstraktionsniveau definieren und in der Adaptionsphase 

weiterverarbeiten kann. Maple V [31, 32] ist ein symbolisches 

Rechensystem, das folgende Eigenschaften besitzt: 



• interpretierte Sprache 

• vereinfacht symbolische Ausdrücke 

• differenziert symbolische Ausdrücke 

• generiert C-Quelltext 

Neben der symbolischen Umformung von Funktionen und deren Ableitungen 

bietet es komfortable Möglichkeiten, Zeichenketten zu bilden 

und mathematische Ausdrücke in die Programmiersprache des 

Frameworks (C++) zu übersetzen. Dies sind Eigenschaften, die bei 

der Code-Generierung in den Adaptionselementen sehr nützlich sind. 

Maple erlaubt ferner, Prozeduren zu definieren, diese in Bibliotheken 

abzuspeichern, und in einfacher Weise wiederaufzufinden. Dank 

der Kombination all dieser Eigenschaften eignet sich Maple für das 

gesamte Preprocessing des Frameworks. 

2. Die laufzeitintensive Berechnung der Matrizen- und Vektorelemente 

erfolgt wenn immer möglich über private Variable der Baustein-Objekte. 

Dies ist bei den Ntoren immer der Fall, bei den Summengebern 

aber prinzipiell nicht. Summengeber greifen über die in Abbildung 

4.5 dargestellte, mehrstufige Adressierung auf die Variable in den 

Ntoren zu. Andererseits ist bei den Summengebern die Berechnung 

der Terme einfacher, da nur einfache Summen vorkommen. 

Die Berechnung ist beim Zugriff direkt über Symboladdressen effektiver. 

Die Symboladressen werden bereits zur Übersetzungszeit 

vom Kompiler berechnet. Eine wichtige Konsequenz des Ansatzes 

ist, dass konkrete Baustein-Typen, z.B. ein Transformator-Ntor oder 

ein Kirchhoff-Summengeber immer durch konkrete, zur Übersetzungszeit 

bekannte Klassen realisiert werden. Ein Klassenkonstruktor 

wird zur Programmlaufzeit generell nur ein einziges Mal aufgerufen, 

um ein Baustein-Objekt zu erzeugen. In diesem einzigen Aufruf 

müssen dann die über alle Dienste benötigten lokalen Variablen und 

Übergabeparameter vom Klienten im Baustein-Konstruktor akkumuliert 

werden, damit bei der Instantiierung alle benötigten lokalen Variablen 

vorhanden sind und initialisiert werden können. 

Die Elemente der DA und der Adaptionsprozess beeinflussen sich bei 

der Implementation der DA gegenseitig. 

Die Einzelteile lassen sich daher im Kontext des Adaptionsprozesses 

von Abbildung 5.3 besser verstehen. Die Symbolbeschreibung in Unter- 



kapitel 5.3 hilft ausserdem, den Zusammenhang mit der konzeptionellen 

Beschreibung der DA herzustellen. 

5.4.1 Spezifikationselement 

Die Spezifikationselemente werden generell mit Maple-Prozeduren realisiert. 

Der Klient überschreibt im Prozedurrumpf verschiedene globale Variable 

um den variablen Teil des Frameworks zu parametrieren. Diese globalen 

Variablen stellen die weiter unten beschriebenen Spezifikationsdaten 

dar. Die Prozeduren haben keine Rückgabe-Argumente. Dafür können 

Eingabe-Argumente vorkommen, um Daten für die Spezifikation zu liefern, 

die global pro Anwendungsfall gelten. Ein Beispiel ist die Menge 

VK der Basisnamen von Variablen, die an jedem elektrischen Anschluss 

zu spezifizieren ist. 

Bausteine 

Jeder Baustein des Typs T name wird innerhalb einer eigenen Prozedur spezifiziert. 

Dabei werden die variablen Anteile VN,S i sämtlicher i Dienste für 

einen Baustein-Typen parametriert. Dies geschieht durch Überschreiben 

von globalen Variablen, welche die Spezifikationsdaten VN (Ntore) bzw. 

VS (Summengeber) darstellen. Jede Prozedur realisiert in diesem Ansatz 

genau ein Spezifikationselement SN bzw. SV . 

Dieser Ansatz wurde gewählt, damit nur eine Prozedur zur Spezifikation 

eines Bausteins benötigt wird. Mit einem Prozedur-Aufruf sind alle 

Spezifikationen eines Bausteins aktualisiert. Damit lässt sich der Aufbauprozess, 

wie in Abbildung 5.3 dargestellt, in einfacher Weise formulieren. 

Ein weiterer Grund ist die Adaption des Konstruktors eines konkreten 

Bausteins. Der Konstruktor hat eine Sonderstellung, da er im Gegensatz 

zu anderen Methoden immer sämtliche Parameter zur Initialisierung aller 

Objekt-Variablen benötigt. 

Eine Folge dieses Ansatzes ist, dass alle Spezifikationsdaten im Prozedurrumpf 

zu überschreiben sind. Ein Nachteil ist, dass jede Änderung 

eines Dienstes Anpassungen der Spezifikationen und in gewissen Fällen 

auch der Adaptionen bedingt. Der damit verbundene Aufwand ist klein, 

falls nur weitere Spezifikationsdaten, d.h. Variable, dazukommen. Er ist 

grösser, falls bestehende Variable zu ändern sind. Dann sind bestehende 

Adaptionen, in denen die geänderte Variable vorkommt, anzupassen. Eine 



konsequente Namensgebung der Variablen für die Spezifikationsdaten ist 

hilfreich. 

Die Prozeduren werden in Bibliotheken gesammelt. Die Namen der 

Bibliotheken sind innerhalb der DA festgelegt. Der Klient gibt jedem 

Baustein-Typen einen eindeutige Namen T name. Daraus werden die Namen 

der Prozeduren gemäss der Vorschrift 

De f + Tname → De f T name (5.1) 

gebildet. Damit lässt sich der Zugriff auf die Spezifikationsdaten des Bausteins 

über seinen Typnamen aufbauen: 

with(Ntor); #Zugriff auf Bibliothek 

Prozedur := ‘Def‘.‘Tname‘; 

Prozedur(...); 

Ferner wird durch die Namens-Vorschrift der Namenskonflikt zwischen 

Prozeduren vermindert. 

Methode der Klasse “Netz” 

Jeder Dienst i kann grundsätzlich eine Variabilität aufweisen, die nicht 

von den Bausteinen abhängt. Diese Variabilität wird Methoden der Klasse 

“Netz” zugeordnet, und kann in j Spezifikationen SNetzij definiert werden. 

Es hat sich als praktisch erwiesen, grössere Spezifikationsmengen in 

j kleinere, logisch zusammengehörige Spezifikationen zu packen, um die 

Lesbarkeit und Handhabung zu verbessern. Jedes Spezifikationselement 

SNetzij wird durch eine Prozedur realisiert. Im Rumpf dieser Prozeduren 

aktualisiert der Klient die zugehörigen Spezifikationsdaten VNetzij 


Die Spezifikationsdaten V werden mit Hilfe einer Menge von globalen Variablen 

von den Spezifikations- zu den Adaptionselementen übertragen. V 

ist eine heterogene Menge verschiedener Variablen-Typen, wie beispielsweise 

Vektoren oder Tabellen. Die Implementation über Variable ermöglicht 

die Datenübertragung zwischen beliebigen Spezifikationen und Adaptionen. 

Die Menge dieser Variablen ist innerhalb eines Anwendungsfalls grundsätzlich 

unter der Kontrolle des Klienten. Der Klient entscheidet, ob er 

von Spezifikationen und Adaptionen eines ähnlichen Falles ausgehen will 



und damit eine bereits festgelegte Menge von Variablen wiederverwenden 

kann, oder ob er neue Variablen braucht, um die Variabilität seines Anwendungsfalles 

formulieren zu können. 

Für die Spezifikationsdaten der Bausteine benötigt die DA aus den auf 

Seite 92 genannten Gründen zwei vereinheitlichte Formate VN bzw. VS, 

die jeweils als Satz von Variablen realisiert werden. Ein solcher Satz ist 

die Vereinigungsmenge aller Spezifikationen VN,S über alle Dienste i, an 

i 

denen Bausteine beteiligt sind. 

Für die Spezifikationsdaten VNetzij , welche die variablen Anteile der 

Methoden der Klasse “Netz” parametrieren, gibt es innerhalb der DA keine 

Festlegungen. Der Klient organisiert für die Dienste i beliebig struktu- 

rierte Variable, die sich für den Datenaustausch zwischen dem Spezifikationselement 

SNetzij und einem Adaptionselement SNetzik eignen. 


Die Adaptionselemente Ai werden generell mit Maple-Prozeduren realisiert. 

Die Prozeduren heissen innerhalb der DA alle MakeX(args). X steht 

für eine Identifikation der Prozedur, siehe Tabelle 5.1 

Die optionalen Prozedur-Argumente args sind dafür vorgesehen, Daten 

X Adaption-Inhalt siehe Abbildung 

Ntor alle Dienste aller Ntor-Typen 5.4 

SumSetter alle Dienste aller Summengeber-Typen 5.4 

DienstName einen Dienst i an Klasse ”Netz” 5.5 

Tabelle 5.1: Namens-Konvention 

zu empfangen, die global pro Anwendungsfall gelten, beispielsweise die 

Menge der benutzten Ntor-Typen. 

Der Klient schreibt im Prozedurrumpf einen Code-Generator, den er mit 

Hilfe von Spezifikationsdaten V und Prozedur-Argumenten konfiguriert. 

Die Adaptionsprozeduren sind hierarchisch organisiert. Auf der obersten, 

für den Aufbau massgebenden Ebene, benötigt die DA eine Prozedur MakeNtor(), 

welche den variablen Anteil aller Dienste einer konkreten Ntor- 

Klasse generiert. Entsprechendes gilt für die Summengeber. Pro Dienst 

mit variablem Anteil in Methoden der Klasse “Netz” ist, wie in Tabelle 5.1 

angegeben, eine Prozedur mit dem Namen “DienstName” vorgesehen. 

Es ist dem Klienten überlassen, unter diesen Haupt-Prozeduren weitere 



Prozeduren zu verwenden, um die Adaption, falls nötig, weiter zu strukturieren. 

Der von der Adaption zu erzeugende Code richtet sich nach der Sprache, 

in der das Framework implementiert ist. Dies ist in der vorliegenden 

Arbeit C++. Mit Maple V lassen sich Ausdrücke sehr einfach in die 

Sprache C übersetzen. Es ist ohne weiteres möglich, aus einem in C++ 

geschriebenen Programmteil heraus in C codierte Funktionen oder Ausdrücke 

aufzurufen. 

Beispiel: 

Es soll die Funktion fun(e,f)= 1 

e 2 +f 2 nach der Variablen e abgeleitet werden. 

Die Maple V-Anweisungen 

readlib(C); 

fun := 1/(eˆ2 + fˆ2); 

C(diff(fun,e)); 

erzeugen folgenden Quelltext in C: 

t0 = -2.0/pow(e*e+f*f,2.0)*e; 

∂ fun(e,f) 

In t0 speichert Maple V den Wert von ∂x . 

Codeteile, die in C geschrieben sind, können problemlos in C++ integriert 

werden. Der Output der Adaption sind Dateien, die den Quelltext 

der erzeugten Framework-Erweiterungen enthalten. Die Dateien haben die 

Namen out.C für den Deklarations- und out.h für den Definitionsteil des 

erzeugten Quelltextes. Der Name out ist aus den Spezifikationsdaten oder 

den Argumenten der Prozeduren abzuleiten. Diese Namen müssen innerhalb 

der DA konsistent sein, damit sich der Zusammenbau in generischer 

Weise formulieren lässt. 

Die Prozeduren der Adaption werden in einer Bibliothek gesammelt. 

Der Name der Bibliothek ist innerhalb der DA festgelegt. 

5.4.4 Zusammensetzung des Frameworks 

Der Zusammenbau des adaptierten Frameworks geschieht innerhalb von 

zwei verschachtelten Prozessen. Der äussere Prozess ist der Hauptprozess. 

Er ist mit dem Make-Werkzeug des UNIX-Betriebssystems realisiert. Dieser 

Prozess kennt einerseits die Abhängigkeiten zwischen Teilen, die für 

den Zusammenbau benötigt werden, und Regeln dafür, wie diese Teile aufzubauen 

sind. 



Start 

alle 

Baustein-Typen NT,ST 

abgearbeitet ? 

nein 

Aktualisiere 

Spezifikationsdaten 

V N bzw. VΣ 

des Baustein-Typen 

Adaptiere Konstruktor 


Alle Dienste 

ja 

D abgearbeitet 

? 

nein 

Adaptiere Klassenmethode(n) 

des aktuellen Dienstes 


ja 

Alle Dienste 

D abgearbeitet 

? 

nein 

Aktualisiere 

Spezifikationsdaten 

der Methode(n) 

der Klasse "Netz" 

für den aktuellen Dienst 


Σj 

VNetz ij 

Adaptiere 

Methode(n) 

der Klasse "Netz" 

für den aktuellen Dienst 

Σ k 

F Netz ik 

Abbildung 5.3: Adaptionsprozess des Frameworks 

Eine der Regeln bildet den inneren Prozess, der hier genauer betrachtet 

wird. Wie im Flussdiagramm von Abbildung 5.3 dargestellt, erzeugt 

der innerhalb von Maple laufende Prozess den Quelltext der adaptierbaren 

Teile des Frameworks. Dies sind je eine konkrete C++-Klasse für jeden 

ja 

Ende 

verlangten Baustein-Typ FN bzw. FS und eine oder mehrere Methoden 

FNetzij der Klasse “Netz”. Die Abbildungen 5.4 und 5.5 zeigen typische 

Datenfluss-Graphen zwischen den Prozeduren der Spezifikation und Adaption. 

Man beachte, dass die aktuelle Form der Graphen von Vorgaben 

des Klienten abhängt. 

Der innere Prozess kann erst gestartet werden, nachdem der Klient alle 

Prozeduren zur Spezifikation und Adaption definiert hat. Danach kann der 

Prozess diese Definitionen mit Hilfe der Prozedur-Namen in Bibliotheken 

auffinden. 

Jede Spezifikationsprozedur überschreibt einen Satz von globalen Variablen 

V mit aktuellen Werten. Alle angegebenen globalen Variablen 

werden in der Prozedur typenspezifisch aktualisiert. Über diese Variable 

erfolgt der Austausch der Spezifikationsdaten. Der Aufbauprozess reicht


SB 

SB 

1 

SB2 SB 3 

} 

V B 

Pro Baustein-Typ 

A B 

M 1 

Netzberechnung 

Netzaufbau 

Resultatanzeige 

B = N(Ntor) oder S(Summengeber) M = adaptierte C++ - Methoden 

S 

S 

S 

Abbildung 5.4: Adaptions-Beispiel eines Bausteins 

Netz i1 

Netz i2 

Netz i3 

S 

N 

VNetz 

i2 

Pro Dienst i 

VNetz 

i1 

VNetz 

i3 

VN 

A 

A 

A 

Netz i1 

Netz i2 

Netzi 


M 2 

M 3 

F Netz i1 

F Netz i2 

Abbildung 5.5: Adaptions-Beispiel einer Methode der Klasse “Netz” 

diese Daten an die Adaption weiter. 

Der konstante Teil des Frameworks benötigt an geeigneten Stellen festgelegte 

Namen um den Quelltext der adaptierten Teile ins gesamte Framework 

einzuschliessen. Dies geschieht über den in Abbildung 5.6 dargestellten 

Mechanismus. Mit Hilfe der Datei “InclControlFile” wird dem 

C++-Kompiler mitgeteilt, welche externen Dateien einzufügen und zu übersetzen 

sind. Die Datei “InclControlFile” ist ebenfalls ein autogenerierter 

Teil, der im inneren Prozess aus der Typmenge einer Applikation erzeugt 

wird. 

Jeder Baustein X hat eine Spezifikations-Prozedur mit Namen DefX. 

Diese Namenskonvention wird benutzt, um über die Menge aller verlangten 

Spezifikationen zu iterieren. Die Namen der aufzurufenden Prozeduren 

sind erst zur Laufzeit des inneren Prozesses bekannt. Dank der interpretierenden 

Ausführung von Maple ist es möglich, eine erst dann bekannte 

Menge von Prozeduren abzuarbeiten. 

Nachdem der innere Prozess abgeschlossen ist, übersetzt der Hauptpro- 

FB


Framework Erweiterungen 

z.B. für NTore 

B2.C 

B1.h 

B1.C 

Quelltext Framework 

#include InclControlFile 

Spezifikation Baustein-Menge 

NT = [ ... , B1, B2, ... ] 

generiert 

Datei InclControlFile 

#include B1.C 

#include B1.h 

#include B2.C 

Abbildung 5.6: Zusammenbau mittels Steuerdatei 

zess den Quelltext und bindet alle für das Framework benutzten Bibliotheken. 

5.5 Adaption des Dienstes Netzberechnung 

Der Dienst Netzberechnung wird auf allen Architekturebenen anhand der 

typischen beiden Bausteine “PU-Generator” und “Kirchhoff-Knoten” für 

eine Lastflussrechnung aufgezeigt. 

5.5.1 Spezifikation 

Hier wird die Spezifikation zweier typischer Bausteine für eine Lastflussberechnung 

anhand der Spezifikations-Prozeduren dargestellt. 

Ntor-Typ PU-Generator 

Der Prozedurkopf deklariert den Namen der Spezifikations-Prozedur des 

Ntor-Typs “PU-Generator”. Der Typ-Name lautet PUGen. Als Parameter 

der Prozedur wird die Menge VarsProA übergeben. Damit wird netzweit 

angegeben, welche Basisnamen von Variablen pro elektrischem Anschluss 

gewünscht sind. Ferner wird die Anzahl der elektrischen Anschlüsse und 

der möglichen Zustände dieses Ntor-Typs definiert. 

NTor[DefPUGen] := proc(VarsProA) 


5.5. ADAPTION DES DIENSTES NETZBERECHNUNG 99 

global Vars, Pars, Funs, 

AnzVars, AnzPars, AnzFuns, 

N, NTorType, 

Regelung, ParType, States, 

StateDefs, StateChanges; 

# NTor-Eigenschaften 

NTorType := ‘PUGen‘; 

N := 1; 

States := 2; 

Hier folgt die Spezifikation der Menge der Variablen V und Parameter 

P für den Initialzustand des Ntor-Typs. Die Funktion AlleAVars() füllt 

den Variablenvektor Vars mit N+1 indizierten Instanzen der in der Menge 

VarsProA definierten Basisnamen. Neben den N Anschlüssen, kommt 

noch ein weiterer Anschluss dazu, den dieses Ntor zur Spannungsregelung 

benötigt. Die Funktion ExpandVektor() verlängert Vektoren an ihrem 

Ende, d.h. es wird die Variable Q1 dem Vektor Vars hinzugefügt. 

# Variable 

Vars := ExpandVektor( AlleAVars( N+1, VarsProA),[Q1] ); 

AnzVars := vectdim(Vars); 

# Parameter 

AnzPars := 9; 

Pars := vector(AnzPars,[P1,U,Umax,Umin,G,B,Qmax,Qmin,P2]); 

Nachfolgend sind die Fehlerfunktionen aufgeführt aus denen sich durch 

Nullsetzen die Menge der Gleichungen E des Grundzustandes ergibt. Die 

ersten beiden Funktionen beschreiben den Zusammenhang zwischen Strom 

und Spannung, je für den Real- und Imaginärteil. Die dritte Funktion 

drückt den Spannungsbetrag (Sollwert) durch einzelne Spannungskomponenten 

aus. Die beiden letzten Gleichungen formulieren die stromlose 

Messung der zu regelnden Spannung. 

# Regelung: {} keine, {RVC} : Remote Voltage Control 

Regelung := {RVC}; 

# Functions of the NTor 

AnzFuns := 5; 

Funs := vector(AnzFuns); 

Funs[1] := ie1 - (e*P1 + f*Q1)/(eˆ2 + fˆ2) 

-evalc(Re((e1+I*f1)*(G+I*B))); 

Funs[2] := if1 - (-e*Q1 + f*P1)/(eˆ2 + fˆ2) 

-evalc(Im((e1+I*f1)*(G+I*B))); 



Funs[3] := Uˆ2 - e2ˆ2 - f2ˆ2; 

Funs[4] := ie2; 

Funs[5] := if2; 

Die folgenden Definitionen legen die Anzahl der möglichen Zustände dieses 

Ntor-Typs fest. Für beide Zustände s= PUMode(1) und 

PUQMode(2) muss je ein Verhalten BN s(Vs,Ps,E s,Ts) definiert werden. 

# Finite State Machine 

StateDefs := vector(States); 

StateDefs[1] := table([ State=‘PUMode‘, 

Vars=Vars, 

Pars=Pars, 

Funs=Funs 

]); 

StateDefs[2] := table([ State=‘PUQMode‘, 

Vars=AlleAVars(N+1, VarsProA), 

Pars=ExpandVektor(Pars, [Q1]), 

Funs=vector(4,[Funs[1],Funs[2], 

Funs[4],Funs[5]]) 

]); 

Die folgenden Angaben legen die Zustands-Übergänge Ts fest. 

StateChanges[1] := table([ From=‘PUMode‘, 

To=‘PUQMode‘, 

LimVars={Q1}, 

UpperLim={Qmax}, 

LowerLim={Qmin}, 

AddVars={}, DelVars={Q1}, 

AddPars={Q1}, DelPars={} 

]); 

StateChanges[2] := table([ From=‘PUQMode‘, 

To=‘PUMode‘, 

LimVars={‘sqrt(pow(ue2,2.0) 

+pow(uf2,2.0))‘}, 

UpperLim={Umax}, 

LowerLim={Umin}, 

AddVars={Q1}, DelVars={}, 

AddPars={}, DelPars={Q1} 

]); 

end: 

Pro Zustandsübergang werden die Grenzen UpperLim und LowerLim einer 

Variablen LimVars definiert, bei deren Überschreitung in den Zustand 

To=... gewechselt wird. Die im neuen Zustand geltende Variablen- und 

Parametermenge Vs und Ps wird mit Hilfe der Operationen für das Hinzufügen 

(AddVars und AddPars) und das Entfernen von Variablen und 

Parameter (DelVars und DelPars) aktualisiert. 



Summengeber-Typ Kirchhoff-Knoten 

Der Prozedurkopf deklariert den Namen der Spezifikations-Prozedur des 

Summengeber-Typen “Kirchhoff-Knoten”. Der Typ-Name lautet Knoten. 

Es gibt vier Fehlerfunktionen, aus denen sich durch Nullsetzen die Menge 

der Gleichungen E ergibt. Die ersten beiden Gleichungen formulieren 

Nullsummen für Real- und Imaginärteil des Stromes ie + j · i f . Die 

restlichen Gleichungen formulieren den Wertausgleich aller Spannungen 

e + j · f . Das Verhalten eines Summengeber-Typs wird durch eine beliebige 

Menge von Elementarsummen festgelegt. Im folgenden Code- 

Ausschnitt werden vier Elementarsummen parametriert. Die Parameter 

jeder Elementarsumme werden mit dem Datentyp table als Einheit zusammengefasst 

und komponentenweise im Vektor Funs gesammelt. Die 

einzelnen Felder des Datentyps table bezeichnen den Typ der Elementarsumme, 

einen gemeinsamen Basisnamen, der Name einer optionalen 

Variablen und der Name eines optionalen Parameters. 

SumSetter[DefKnoten] := proc() 

global Funs, AnzFuns, SumSetterType; 

SumSetterType := ‘Knoten‘; 

AnzFuns := 4; 

Funs := vector(AnzFuns); 

Funs[1]:= table([ElementarFunTyp=EinzeiligeSumme, 

ExternalVarName=‘ie‘, 

LocVarName=0, 

Parameter=0] ); 

Funs[2]:= table([ElementarFunTyp=EinzeiligeSumme, 

ExternalVarName=‘if‘, 

LocVarName=0, 


Funs[3]:= table([ElementarFunTyp=MehrzeiligeSumme, 

ExternalVarName=‘e‘, 

LocVarName=0, 


Funs[4]:= table([ElementarFunTyp=MehrzeiligeSumme, 

ExternalVarName=‘f‘, 

LocVarName=0, 


end: 




Variable Bedeutung (vergl. S. 51 ff.) 

Vars V0 

Pars P0 

Funs E alle 

AnzVars dim(V0) 

AnzPars dim(P0) 

AnzFuns dim(E alle) 

N Anzahl elektrischer Anschlüsse 

NTorType Typname Ntor 

States σmax 

StateDefs Name des i-ten Zustandes 

StateChanges 

Vi , Pi , E i ,i = 1...σmax 

Ti ,i ≤ σmax 

Funs E 

AnzFuns dim(E) 

SumSetterType Typname Summengeber 

Tabelle 5.2: Datenaustausch Spezifikation-Adaption 

Der Datenaustausch zwischen Spezifikation und Adaption erfolgt über die 

in Tabelle 5.2 dargestellten globalen Variablen. 


Die Adaptions-Prozeduren erzeugen die Framework-Adaptionen für die 

Lastflussberechnung. 

Die nachfolgenden Code-Beispiele zeigen die erzeugten C++-Methoden 

dem Prinzip nach auf. Gleichförmige Teile werden durch Punkte abgekürzt. 

Aus den Spezifikationen erzeugte Symbole sind eingerahmt. 

Der Konstruktor des PU-Generators instantiiert alle Variablen- und 

Parameterobjekte. Die Reihenfolge der Variablen ist eine wesentliche Information 

für die Handhabung des Gleichungssystems. Die Adaption des 

Konstruktors setzt die Reihenfolge der Variablen im Vektor Vars in Laufnummern 

um, die im Konstruktor der Variablen übergeben werden. Ferner 

sind für sämtliche Argumente des Konstruktors private Variable zu deklarieren 

und Anfangswerte zu überweisen. 

PUGen :: PUGen (char* name 

, double _ ie1 

... 

, double _ f2 

, double _ Q1 



... 

, double _ P2 

: VNtor(name ) 

) 

{ 

anz_vars = 9 ; 

anz_pars = 9 ; 

anz_funs = 5 ; 

state = PUMode ; 

InsertVariable(new Variable(" ie1 ", 

... 

0 , & ie1 )); 

InsertVariable(new Variable(" Q1 ", 8 , & Q1 )); 

InsertParameter(new Parameter(" P1 ", & P1 )); 

... 

InsertParameter(new Parameter(" P2 ", & P2 ;/ 

ie1 

... 

= _ie1 ; 

f2 = _f2 ; 

Q1 

... 

= _ Q1 ; 

P2 = _ P2 ; 

} 

Der folgende Code zeigt die erzeugte Methode Limiter() des PU-Generators. 

Diese Methode testet beim Ntor, ob es im Zustand σ bleibt, 

oder ob es in den Nachfolgezustand σi wechselt. Die Spezifikationsdaten 

Q1, Qmax und Qmin werden als Parameter an die Methode CheckLimits() 

weitergereicht. Für jeden Zustand σ des Ntors werden aus Spezifikationsdaten 

der Variablen StateChanges Fallunterscheidungen mit Hilfe 

von Case-Anweisungen generiert. 

int 

{ 

PUGen :: Limiter() 

double new_value; 

switch (state) { 

case PUMode : 

//Generierte, zu untersuchende Limiten 

limiteIstVerletzt = falsch; 

new_value = CheckLimits( Q1 , Qmax , Qmin ); 

if (limiteIstVerletzt) SwitchState(new_value); 



break; 

case PUQMode : 

... 

default: 

break; 

} 

return limiteIstVerletzt; 

} 

Der folgende Code ist die erzeugte Methode SwitchState() des PU- 

Generators. SwitchState() wird von der Methode Limiter() aufgerufen. 

SwitchState() bringt das Ntor von einem Zustand σ in seinen Nachfolge- 

zustand σi und installiert das neue Verhalten 

BN σi (Vσi ,Pσi ,E σi 

,Tσi ). Pro spezifiziertem Zustand σ des Ntors wird aus 

Spezifikationsdaten der Variablen StateChanges eine Fallunterscheidung 

generiert. 

void PUGen :: SwitchState(double new_value) 

{ 

int i; 

Variable* rv; 

Variable* pop_rv; 

Parameter* rp; 

Parameter* pop_rp; 

switch (state) { 

case PUMode : 

// Entfernen von unbenutzten Variablen 

rv = GetVar(" Q1 "); 

for (i=0; i


anz_vars = 8 ; 

anz_pars = 10 ; 

anz_funs = 4 ; 

state 

break; 

= PUQMode ; 

case 

... 

PUQMode : 

default: 

break; 

} 

} 

Die folgenden Zeilen zeigen die erzeugte Methode GetAElem() des 

PU-Generators. Diese zentrale Methode erzeugt für alle spezifizierten 

Zustände je einen Zugriff auf die schwach besetzte Jacobi-Matrix. Er 

wird durch geschachtelte Abfrage mittels case-Anweisungen implementiert. 

Der Default-Fall liefert den Wert 0 zurück. Für die Nichtnullen der 

Matrix setzt die Adaption das aus den Spezifikationen von Vars, Funs und 

StateDefs symbolisch berechnete Jacobi-Element ein. 

double PUGen :: GetAElem(int i, int j, int state) 

{ 

double t0; 

switch(state) { 

case PUMode : 

switch(i) { 

case 1 : 

switch (j) { 

case 1 : 

t0 = 1.0 ; 

return t0; 

break; 

case 3 : 

t0= -P1/(e1*e1+f1*f1) 

+ 2.0*(e1*P1+f1*Q1)/ 

pow(e1*e1+f1*f1,2.0)*e1-G ; 

return t0; 

break; 



... 

default: 

return 0.0; 

break; 

} /* switch j */ 

break; 

case 2 : 

... 

case 5 : 

default: 

return 0.0; 

break; 

} /* switch i */ 

case PUQMode : 

... 

default: 

return 0.0; 

break; 

} /* switch state */ 

} 

Die erzeugte Methode GetbElem() des PU-Generators ist nach dem 

gleichen Muster wie GetAElem() aufgebaut. Hier ist die Schachtelung der 

Case-Anweisung ein Ebene weniger tief, da nur ein Index und der aktuelle 

Zustand den Schlüssel auf einen Mismatch-Wert bilden. 

Die folgenden Code-Zeilen zeigen den Konstruktor des Kirchhoff-Knotens: 

Knoten 

{ 

:: Knoten (char* name ) : VSummengeber(name ) 

elementarFuns.append((NewtonRaphson*) new 

EinzeiligeSumme (&anschluesse, " ie " , 0.0 )); 


EinzeiligeSumme (&anschluesse, " if " , 0.0 )); 


MehrzeiligeSumme (&anschluesse, " e " , 0.0 )); 



} 


MehrzeiligeSumme (&anschluesse, " f " , 0.0 )); 

5.5.4 Aufbau eines Lastfluss-Programms 

Die Spezifikation der Applikation enthält die Namen der Bausteine und die 

Angabe der Variablen, die netzweit für elektrische Anschlüssen zu instantiieren 

sind. Der folgende Maple-Code zeigt, wie die zu adaptierenden Teile 

des Frameworks aus der Spezifikation der gesamten Applikation aufgebaut 

wird. Es wird über alle Bausteine und über alle Dienste iteriert. 

#Maple-Bibliotheken fur Spezifikations und 

#Adaptions-Prozeduren: 

with(Ntor): 

with(CodeGen): 

with(SumSetter): 

# Die Variablen, die netzweit zu 

# jedem elektrischen Anschluss gehoeren (VK): 

VarsProA := vector(4,[ ‘ie‘ ,‘if‘ , ‘e‘, ‘f‘ ]): 

# Alle applikationsspezifischen Ntor-Typen (NT) : 

NtorTypMenge := ... , PUGen, ...; 

# Alle applikationsspezifischen Summengeber-Typen (ST): 

SumSetterTypMenge := Knoten, ... ; 

# Erzeugen der Steuerfiles fuer Include 

# aller adaptierter Teile 

# Name dieses Files = InclControlFile 

MakeIncludeNtor( {NtorTypMenge}, {SumSetterTypMenge}, 

‘InclControlFile‘ ); 

# Erzeugen der verlangten Ntor-Klassen 

for i in NtorTypMenge do 

Prozedur := ‘Def‘.i; 

Prozedur(VarsProA); 

MakeNtorClass(); 

od: 

# Erzeugen der verlangten Summengeber-Klassen 

for i in SumSetterTypMenge do 

Prozedur := ‘Def‘.i; 

Prozedur(); 

MakeSumSetterClass(); 



od: 

... 

quit: 

NP1 Bus1 

SlackGen 

1 

Z 

NP2 

1 2 

Bus2 

2 1 

1 PVGen 

NP5 

Bus3 NP4 

1 

PQLoad 


Z 

NP3 

Abbildung 5.7: Netzbeispiel 

5.6 Adaption des Dienstes Netzaufbau 

Dieses Unterkapitel zeigt, wie der Dienst Netzaufbau innerhalb der DA 

zu adaptieren ist, damit aus dem IEEE Common Format [23] (relevanter 

Ausschnitt siehe Anhang B) ein Netzbestand für eine Lastflussrechnung 

aufgebaut werden kann. 

Bevor in der objekt-orientierten Welt simuliert werden kann, müssen 

Objekte im Speicher des Computers parametriert und aktiviert werden. 

Danach sind die Objekte miteinander zu verknüpfen, damit das Netzmodell 

für eine bestimmte Applikation entsteht. 

5.6.1 Einleitung 

Folgendes Beispiel zeigt, worum es geht. In Abbildung 5.7 ist ein kleines 

Netz gegeben. In diesem Netz soll eine Lastfluss-Rechnung ausgeführt 

werden. Ein Klient modelliert diese Applikation durch die Ntor-Typen 

“SlackGen”, “PQLoad”, “PVGen” und “Z”. Die Klasse “Netz” enthält 

in ihrem API alle Methoden, um ein Netzmodell aufzubauen. Die untenstehenden 

C++-Methoden-Aufrufe erzeugen die verlangten Objekte und 

verknüpfen sie so, wie es das Beispiel von Abbildung 5.7 vorgibt. 

// Ntor-Objekte erzeugen 

InsertNTor( new SlackGen("NP1", weitere Parameter ));

5.6. ADAPTION DES DIENSTES NETZAUFBAU 109 

InsertNTor( new Z("NP2", weitere Parameter )); 

InsertNTor( new Z("NP3", weitere Parameter )); 

InsertNTor( new PQLoad("NP4", weitere Parameter )); 

InsertNTor( new PVGen("NP5", weitere Parameter )); 

// Kirchhoff-Knoten-Objekte erzeugen 

InsertSumSetter( new Knoten("Bus1") ); 



// Objekte verknuepfen 

InsertAnschluss("Bus1", "NP1", 1 ); 







Die Objekterzeugung und -verknüpfung erfolgt im Konstruktor der Klasse 

“Netz”. Dazu werden die Konstruktoren der verlangten Typen aufgerufen 

und sämtliche notwendigen Parameter gesetzt. Diese Art der Objekterzeugung 

ist zu Testzwecken des Frameworks bei kleinen Netzen durchaus 

geeignet, da sie sehr einfach ist. Sie hat aber gravierende Nachteile: 

• Jede Netzänderung (Parameter und/oder Topologie) bedingt eine Neuübersetzung 

der Netz-Klasse und erneutes Binden des gesamten Programms. 

• Die Code-Länge des Programms wächst mit der Anzahl der Netz- 

Objekte und ihrer Verknüpfungen. 

Daher ist es wünschenswert, die Objekte zur Programmlaufzeit aufzubauen. 

Dies erreicht man durch Interpretation von Netzdaten, wie in den 

folgenden Zeilen skizziert: 

... 

if ( aktuelleNetzdaten.typ == BUS3 ) 

InsertNTor( new SlackGen( aktuelleNetzdaten.name, ... )); 

... 

if ( aktuelleNetzdaten.typ == BRANCH0 ) 

InsertNTor( new Z( aktuelleNetzdaten.name, ... )); 

... 

Die Fallunterscheidungen werden aufgrund von Netzdaten getroffen, 

die von einem interpretierenden Programm eingelesen werden. 



netz 44 2.345 66 

Bl aaa 

33 

445. 77.2 1.05 

Bl aaa 

44.4 77.01 445 

1.02 

0.87 22.5 

33.44 77.8 

1.07 1.06 

Netzdaten 

wählt Tauschformat 

Klient 

parametriert 

(baut) 

Netzaufbau 

Abbildung 5.8: Übersicht Netzaufbau 


Σ 

Σ 

Σ 

Objektbestand 

Netzdaten beschreiben elektrische Netze für bestimmte Applikationen. 

Netzdaten liefern einerseits die benötigten Daten der Betriebsmittel-Modelle 

und die topologische Beschreibung eines Netzes. Es gibt heute zahlreiche 

verschiedene Daten-Formate [23, 33]. Der applikations-orientierte 

Verwendungszweck bestimmt Form und Umfang der Netzdaten. In der 

Regel ist die topologische Beschreibung unter den Formaten recht ähnlich. 

Die Unterschiede liegen vorallem bei den Modellen der Betriebsmittel und 

ihren Parametern, sowie einigen Zusatzfunktionen, wie Regelung und Zugehörigkeiten 

zu Gebieten mit bestimmten Eigenschaften. 

Da die elektrische Energieübertragung naturgemäss ein vernetztes Gebilde 

darstellt, besteht zwischen den Beteiligten aus Planung, Betrieb und 

Forschung ein stetes Bedürfnis, netzbezogene Daten untereinander auszutauschen 

und bereits erfasste Datenbestände zu nutzen. 

Datenmodelle wurden ausgehandelt [23, 33] und passende Austauschformate 

definiert. Diese Formate beschreiben die Organisation der Daten 

typischerweise in Tabellenform. 

Definierte Formate sind die Voraussetzung für den Bau von Schnittstellen 

zwischen Computersystemen. Damit lassen sich einzelne Systeme und 

Datenmodelle entkoppeln, was zu kleineren, flexibleren und besser wartbaren 

Applikationen führt. 

5.6.2 Problembeschreibung 

In dieser Arbeit soll eine Schnittstelle zwischen einem typischen Vertreter 

tabellenförmiger Austauschformate und dem Framework implementiert 

werden. Abbildung 5.8 zeigt die Rolle des Klienten. Der Klient para-


metriert für seine applikationsspezifische Netzberechnung eine geeignete 

Menge von Ntor- und Summengeber-Typen. Die eigentliche Aufgabe besteht 

nun darin, bestehende Netzdaten mit Hilfe der neuen, vom Klienten 

gewählten Ntor- und Summengeber-Typen zu interpretieren. 

Der Klient kennt das Tauschformat der Netzdaten und seine applikationsspezifischen 

Typen. Mit diesem Wissen parametriert er den Dienst 

Netzaufbau, welcher die Netzdaten in einen Objektbestand übersetzt, der 

auf Ntor- und Summengeber-Typen basiert. Auf diesem Objektbestand 

kann der Klient dann die Netzberechnung durchführen. 

Der Dienst Netzaufbau ist dadurch gekennzeichnet, dass es in ihm einen 

variablen und konstanten Teil gibt. Der variable Teil umfasst alles, was der 

Klient parametrieren muss: 

• Syntax des gewählten Tauschformats, um in den Netzdaten Muster zu 

erkennen, die für die Übersetzung benötigt werden 

• Übersetzungs-Semantik für die benutzten Muster 

Der konstante Teil betrifft die Framework-Seite der Übersetzung. Diese 

Seite ist konstant, weil 

• der Klient seine Applikation immer durch Spezialisierung der beiden 

Typen Ntor und Summengeber formuliert, 

• und der Verknüpfungsmechanismus im Framework unabhängig vom 

aktuellen Ntor- oder Summengebertyp ist. 

5.6.3 Analyse eines konkreten Tauschformates 

Die Analyse des Tauschformates ist ein notwendiger Schritt, um die Anforderungen 

des Netzaufbaus eindeutig zu erfassen, und so zu formalisieren, 

dass dieser Dienst implementiert werden kann. Es hat sich herausgestellt, 

dass die Implementation ziemlich komplex ist, und nur ein Vorgehen, 

das an konkreten Übersetzungs-Beispielen vollzogen wird, zum Ziel 

führt. Aus diesem Grund wurde zunächst ein konkretes Tauschformat [23] 

ausgewählt, um Netze daraus aufzubauen. 

Das Tauschformat [23] wurde ausgewählt, weil es gut dokumentiert ist 

und zahlreiche Netzdaten grösserer Testnetze vorliegen. Ferner steckt hinter 

dem Format ein Modell, das für die Lastfluss-Rechnung zugeschnitten 

ist. Die Datenvorgabe erfolgt anhand von Typen, die unter Kapitel 3.1.2 

beschrieben sind. Das Tauschformat [23] wurde in den Siebzigerjahren 



entwickelt. Es ist ein typischer Vertreter tabellenförmig strukturierter Formate. 

Syntax 

Die Syntax definiert Regeln für die Anordnung von Zeichen, um korrekte 

Netzbeschreibungen zu liefern. Der Dienst Netzaufbau benötigt diese 

Information, um in den Netzdaten Zeichen zu finden, denen in der weiter 

unten beschriebenen semantischen Übersetzung gleichbedeutende Objekte 

des Domänenmodells zugeordnet werden. 

Die Daten eines Netzes sind in einer ASCII-Datei abgelegt, und wie 

in Abbildung 5.9 tabellenförmig strukturiert. Die Tabellenform entsteht 

10/30/96 Project NRA 1.0 1996 W IEEE 5 Bus Test Case 

BUS DATA FOLLOWS 4 ITEMS 

1 Bus 1 HV 2 1 3 1.000 0.0 0.0 0.0 232.4 -16.9 0.0 1.0 0.0 0.0 0.0 0.0 0 

1 Bus 1 HV 2 1 0 1.000 0.0 0.0 0.0 2.0 0.0 0.0 1.0 1.1 0.9 0.0 0.0 0 

3 Bus 3 HV 2 1 2 1.010 -12.72 0.0 0.0 5.0 0.0 0.0 1.0 40.0 -40.0 0.0 0.0 3 

4 Bus 4 HV 2 1 0 1.000 0.0 0.4 0.0 0.0 0.0 0.0 1.0 1.1 0.9 0.0 0.0 0 

5 Bus 5 HV 2 1 0 1.000 0.0 0.6 0.0 0.0 0.0 0.0 1.0 1.1 0.9 0.0 0.0 0 

-999 

BRANCH DATA FOLLOWS 4 ITEMS 

2 1 1 1 1 0 0.0 0.1 0.0 0 0 0 3 0 0.94 0.0 0.0 0.0 0.0 0.9 1.1 

2 3 1 1 1 0 0.0 0.1 0.0 0 0 0 2 0 0.95 0.0 0.9 1.0 0.0 0.5 1.5 

4 2 1 1 1 0 0.0 0.1 0.0 0 0 0 0 0 0.94 0.0 0.0 0.0 0.0 0.0 0.0 

3 5 1 1 1 0 0.0 0.1 0.0 0 0 0 0 0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 

-999 

INTERCHANGE DATA FOLLOWS 1 ITEMS 

1 2 Bus 2 HV 1.5 1.00 1996 W IEEE 5 Bus Test Case 

-9 

TIE LINES FOLLOWS 0 ITEMS 

2 1 1 2 1 

4 2 2 1 1 

3 1 5 2 1 

-999 

Abbildung 5.9: Beispiel für Netzdaten 

dadurch, dass Daten jeweils nach maximal 128 Zeichen einer neuen Zeile 

zugeordnet werden. Es gibt kein anderes Zeichen, das ein Zeilenende 

markiert. Innerhalb der Zeilen sind Datenfelder angeordnet. Diese werden 

durch festgelegte Spaltenpositionen von einander abgegrenzt. Damit lassen 

sich zwar Datenzeichen einsparen. Es ist jedoch aufwendiger, einen 

Datenstrom ohne Trennzeichen in einzelne Symbole zu zerlegen 2 . Eine 

Zeile entspricht jeweils einem Datensatz. Gleichartige Datensätze sind in 

Datenblöcken zusammengefasst. Datensätze sind gleichartig, wenn sie die 

gleiche Anzahl von Datenfeldern an den gleichen Spaltenpositionen aufweisen. 

Anfang und Ende der Datenblöcke lassen sich durch Datensätze 

mit einer blockspezifischen Start- bzw. Stopidentifikationen erkennen. 

Ein Datenfeld ist eine Zeichenkette in einem Datensatz. Ein Datenfeld 

lässt sich durch Angabe je einer Zahl für die Anfangs- und Endspalte im 

Datensatz lokalisieren. 

2 engl. to parse 



Übersetzer-Semantik 

Der Klient beschreibt, wie für seine Anwendung relevante Konstrukte des 

Tauschformates in gleichbedeutende Objekte seiner Applikation zu übersetzen 

sind. Eine solche Beschreibung wird hier anhand eines für die Lastfluss-Rechnung 

geeigneten Satzes von Ntor- und Summengeber-Typen als 

Beispiel angeführt. Dazu dienen die nachfolgenden Tabellen der Abbildungen 

5.10, 5.11 und 5.12. Sie zeigen, wie relevante Konstrukte (siehe 

Anhang B) in Objekte und Parameter des Frameworks zu übersetzen sind. 

Verschiedene Zweig- und Bustypen unterscheiden sich durch das Typfeld. 

Je nach Typ können gleich positionierte Datenfelder verschiedene 

Bedeutungen haben. Gemeinsam ist jedoch, dass sich ihre Typkennung 

aus dem Datenblock-Typ und dem Datensatztyp zusammensetzt und dass 

sie die Information für die Netztopologie enthalten. Die Netztopologie 

wird dadurch beschrieben, dass die Knoten 3 netzweit eindeutig nummeriert 

sind. Die Zweige haben für jede Anschlusseite je ein Datenfeld, das 

die Nummer des angeschlossenen Knotens enthält. 

Abbildung 5.10 zeigt die Übersetzung der Bus-Datensätze. Die einfachsten 

Typen erzeugen je einen Summengeber mit dem Verhalten eines 

Kirchhoff-Knotens (mit KH bezeichnet) und ein damit verbundenes Ntor. 

Das Ntor formuliert das Verhalten des Knotens. Der Datensatz Bus, Typ 

2 erlaubt es, einen anderen Bus auf eine Spannung Usoll zu regeln. Je 

nach Wert des Feldes RVC ist dies ein entfernt liegender oder der eigene 

Bus. Der korrespondierende Ntor-Typ weist zwei Tore auf. Das zweite Tor 

führt zu Variablen, mit denen die Gleichung für die Spannungsregelung 

formuliert wird. Die Einzelheiten zur Spannungsregelung sind in Kapitel 

6 beschrieben. 

Abbildung 5.11 zeigt die Übersetzung der Zweig-Datensätze. Die Reihenfolge 

der Bus1 und Bus2-Felder ist für Zweige wichtig, da damit die 

Einbaurichtung eines Betriebsmittels, wie z.B. eines Transformatoren festgelegt 

wird. Der Datensatz Zweig, Typ 2 ermöglicht die Festlegung einer 

Spannungsregelung eines weiteren “Bus”. Dies bietet beispielsweise ein 

Transformator mit variablem Übersetzungsverhältnis. Ferner wird ein typischer 

Fall einer Parameter-Auswahl aufgezeigt. Da das gewählte Tauschformat 

F auch Daten für die optimierenden Lastflussrechnungen liefert, 

sieht es für verschiedene Parameter Bereiche, wie Umax und Umin vor. Soll 

die Applikation wie hier ohne Optimierung arbeiten, muss der Bereich auf 

3 engl. bus 



Konstrukte Tauschformat F Framework - Objekte 

Bus, Typ 0,1,3 

Bus 

#1 

Bus, Typ2 

Bus 

#1 

Bus 

#1 

Usoll 

RVC 

Bus 

#2 

KH 

Σ 

Bus 

# 

RVC = 0 : 

KH 

Σ 

Bus 

#1 

RVC = 0 : 

KH 

Σ 

Bus 

#1 

U -> Usoll 


1 

0 -> PQ-Load 

1 -> PQ-Gen 

3 -> Slack-Generator 

PU-Generator 

1 

2 

PU-Generator 

1 2 

Abbildung 5.10: Übersetzung der Bus-Datensätze 

Konstrukte Tauschformat F 

Zweig, Typ 0,1 

Bus 

#2 

Zweig, Typ2 

Bus Bus 

#1 #2 

Umin 

Umax 

RVC 

Bus 

#3 

KH 

Σ 

Bus 

#1 

Bus#3 = Bus#1 

KH 

Σ 

Bus 

#1 

U -> Usoll 

Bus#3 = Bus#2 

KH 

Σ 

Bus 

#1 

Framework - Objekte 

Leitung, Transformator 

1 2 

TransformatorII 

1 2 

3 

TransformatorII 

1 2 

3 

Abbildung 5.11: Übersetzung der Zweig-Datensätze 

KH 

Σ 

Bus 

#2 

U -> Usoll 

KH 

Σ 

Bus 

#2 

KH 

Σ 

Bus 

#2 

KH 

Σ 

Bus 

#2 

U -> Usoll


Konstrukte Tauschformat F 

Austausch-Gebiet 

Slack 

Area 

# 

Psoll 

Bus 

# 

Verbindungsleitung 

Bus Bus 

#1 Area #2 Area 

#1 #2 

Bus Bus 

#1 #2 

Toleranz 

Zweig, Typ0 

Zweigparameter 

P-Summe 

Σ 

Area 

# 

-> Psoll 

P-Summe 

Σ 

Area 

#1 

KH 

Σ 

Bus 

#1 

Framework - Objekte 

P1 = ... P2 = ... 

1 2 


1 

AreaSlack-Generator 

P1 = ... 

Leitung 

1 2 

bereits übersetzter Teil 

Abbildung 5.12: Übersetzung spezieller Datensätze 

1 

KH 

Σ 

Bus 

# 

P-Summe 

einen einzelnen Parameter abgebildet werden, z.B. Usoll = Umax+Umin 

2 

Abbildung 5.12 zeigt die Übersetzung der Datensätze für Austauschgebiete 

und Verbindungsleitungen. Diese speziellen Datensätze dienen dazu, 

Leistungsbilanzen zwischen Netzgebieten zu formulieren. Die Einzelheiten 

der Modellierung sind in Kapitel 6 angegeben. Spezielle Datensätze 

lassen sich nicht nach dem gleichen Schema wie Bus/Zweig-Datensätze 

übersetzen. Spezielle Datensätze enthalten entweder keine Netztopologie 

oder sie liefern Zusatzinformation zu anderen, bereits übersetzten Datensätzen. 

Im oberen Teil der Abbildung 5.12 ist die Übersetzung von Datensätzen 

für Austauschgebiete dargestellt. Innerhalb eines Gebiets Area# 

soll gesamthaft eine bestimmte Leistung Psoll ausgetauscht werden. Die 

Toleranz-Angabe wird nicht verwendet, da die Applikation nicht optimiert. 

Pro Austausch-Gebiet wird ein Ntor vom Typ “AreaSlack” instantiiert und 

durch Anschluss an einen Summengeber vom Typ P-Summe in die Leistungsbilanz-Summe 

einbezogen. Der “AreaSlack” muss noch mit einem 

Summengeber KH, zur Modellierung des elektrischen Anschlusses verbunden 

werden. 

Im unteren Teil von Abbildung 5.12 ist aufgezeigt, wie ein bereits instantiiertes 

Ntor im Zuge der weiteren Übersetzung zu behandeln ist. Bei 

Σ 

Area 

#2 

KH 

Σ 

Bus 

#2


der Übersetzung eines Datensatzes für Verbindungsleitungen wird zusätzliche 

Information für einen Zweigdatensatz eingebracht. Sie betrifft die 

Zugehörigkeit beider Zweiganschlüsse zu den Austausch-Gebieten. Die 

Übersetzung erfolgt dadurch, dass das bereits vorhandene Ntor zusätzlich 

an die verlangten Summengeber vom Typ P-Summe angeschlossen werden. 

5.6.4 Spezifikation 

Nachfolgend ist beschrieben, wie die parametrierbaren Teile des Dienstes 

Netzaufbau spezifiziert werden. Grob gesehen gibt es für alle relevanten 

Konstrukte des Tauschformates F (siehe Anhang B) eine Maple-Prozedur. 

Zum Parameter gehörende Information 

Zur Instantiierung von Ntor- und Summengeber-Typen sind für alle Parameter 

in der Schnittstelle des Konstruktors aktuelle Werte P1, P2, ...Pnzu 

übergeben: 

... new NTor("name", P1, P2, ..., Pn ) 

Der Klient spezifiziert, wie die aktuellen Werte aus den Netzdaten zu bilden 

sind. Abbildung 5.13 zeigt, welche Angaben vom Klienten benötigt 

werden, um einen für die Ntor-Instantiierung benutzten Parameter Pi aus 

den Netzdaten zu filtrieren. Der Klient legt fest, welche Parameter er 

aus den Netzdaten für seine Applikation filtrieren will. Diese Parameter 

werden als O-Parameter bezeichnet. Jedem O-Parameter ist ein Deskriptor 

zugeordnet. Der Deskriptor beschreibt einen O-Parameter durch ein Symbol, 

einer Start- und Endposition im Datensatz sowie einem Datentyp, mit 

welchem die Zeichenkette der Netzdaten zu interpretieren ist. Grundsätzlich 

stehen die in Tabelle 5.3 angegebenen Datentypen zur Auswahl. 

Datentyp C-Datentyp Typ-Code 

reell float f 

ganzzahlig short d 

Zeichenkette char* s 

Tabelle 5.3: Datentypen für Deskriptor der O-Parameter 

Der Klient verwendet die in Spalte “Typ-Code” der Tabelle 5.3 aufgeführten 

Buchstaben, um im Deskriptor einen Datentypen zu deklarieren. 



Datensatz 

O-Parameter 

Symbol 

Anfangsspalte 

Endspalte 

Datentyp 

n 

hat 

Konvertier- 

Funktion 

1 

hat 

Parameter 

im Konstruktor 

Zeichenkette 

Tauschformat F 

Abbildung 5.13: Spezifikation eines Parameterwertes 

Zu jedem Parameter definiert der Klient eine Konvertierungs-Funktion. 

Diese wird als Zeichenkette formuliert, welche standardmässige Mathematik-Funktionen 

und Symbole von O-Parametern in der Programmiersprache 

des Frameworks (C++) enthält. 

Beispiel: Der Klient formuliere die Gleichungen seiner Ntor-Typen in kartesischer 

Darstellung. Das Tauschformat F liefert die O-Parameter U und 

θ (in Grad) jedoch in polarer Form. esl sei ein kartesischer Parameter, der 

bei der Instantiierung eines Ntor-Objektes benötigt wird. Die Konvertierungsfunktion 

für esl lautet daher Ucos( πθ 

180 ) . 

Das folgende Maple-Codestück zeigt, wie der grundlegende Mechanismus 

eines Deskriptor mit Maple V formuliert ist. Stellvertretend zeigt es 

für den Ntor-Typ den Deskriptor: 

# Variable zum Speichern der Spezifikationsdaten: 

global ... Pars, ParKonvFuns, OParameter, OParType, 

OParStart, OParEnd, AnzOutPars, AnzPars; 

# D e s k r i p t o r 

# O-Parameter aus den Netzdaten im Tauschformat F: 

AnzOutPars := 4; 

OParameter := vector(AnzOutPars,[Theta,U,G,B]); #Auswahl der 

#O-Parameter 

OParType := vector(AnzOutPars,[f,f,f,f]); #Datentypen in C 

#f = FLOAT 



OParStart := vector(AnzOutPars,[34,85,107,115]);#Start-Position 

#der O-Parameter 

OParEnd := vector(AnzOutPars,[40,90,114,122]);#End-Position 

#der O-Parameter 

# Parameter fuer die Objekt-Instanzierung: 

AnzPars := 4; 

Pars := vector(AnzPars,[esl,fsl,G,B]); #Parameter im Objekt 

... 

# Konvertierungsfunktion pro Parameter:# Objekt = f(Netzdaten) 

ParKonvFuns := vector(AnzPars); # 

ParKonvFuns[1] := U*cos(Pi*Theta/180); # esl = U*cos(Pi*Theta/180) 

ParKonvFuns[2] := U*sin(Pi*Theta/180); # fsl = U*sin(Pi*Theta/180) 

ParKonvFuns[3] := G; 

ParKonvFuns[4] := B; 

Die Konvertierungsfunktion spezifiziert stets einen C-Ausdruck, der anstelle 

des Parameters im Konstruktor eines Ntor-Objektes eingesetzt wird. 

Zur Programmlaufzeit wird der Ausdruck ausgewertet und als konkreter 

Parameterwert zur Instantiierung des Objektes benutzt. 

Netzweit geltende Parameter 

Die durch Angabe eines Deskriptors ausgewählten O-Parameter gelten global 

für das Netz. Ein typischer O-Parameter ist die Bezugsscheinleistung, 

die zur Skalierung für die Per-Unit-Rechnung benutzt wird. 

Bus/Zweig - Datensätze 

Die Übersetzung dieser Datensätze wird an drei prinzipiell verschiedenen 

Stellen spezifiziert. Dafür ist je eine Prozedur vorgesehen. Diese Partitionierung 

hat vorallem implementations-technische Gründe: 

1. Die Übersetzung richtet sich nach dem Typ des Bus- oder Zweigdatensatzes. 

Eine Korrespondenztabelle ordnet jedem Bus- oder 

Zweigdatensatz TFj einen Ntor-Typen TNj zu. 

Es wird der Typ des Datenblocks und des Datensatzes benötigt, um 

den Tabelleneintrag TFj zu bilden. 



2. Die den Datenblöcken gemeinsamen Übersetzungsangaben werden 

in einer Prozedur zusammengefasst. Dies verringert die Spezifikationsmenge 

bei den einzelnen Ntor-Spezifikationen und ermöglicht 

ein blockbezogenes Vorgehen bei der Übersetzung der Bus- und Zweigdatensätze. 

Pro Block gibt es einen Deskriptor, der die folgende Angaben 

enthält: 

• Start- und Stopzeichen der Datenblöcke 

• Anzahl der elektrischen Anschlüsse N 

• Positionen und Längen der Zeichenketten, die sich auf elektrische 

Verbindungen beziehen 

• Position und Länge der Zeichenkette, die den Typidentifikator 

enthält 

• Position und Länge der Zeichenkette, die das Austausch-Gebiet 

enthält 

3. Alle Angaben der Übersetzung, die spezifisch für einen Ntor-Typ X 

gelten, werden in der zugehörigen Spezifikations-Prozedur mit dem 

Namen DefX hinzugefügt. Die Ntor-Spezifikation wird um folgende 

Daten ergänzt: 

• Deskriptor pro O-Parameter 

• Konvertierungsfunktion pro Parameter 

Spezielle Datensätze 

Für die beiden Datensätze Austauschgebiete und Verbindungsleitungen gibt 

es je eine Prozedur mit folgenden Angaben: 

• Deskriptor pro Parameter 

• Konvertierungsfunktion pro Parameter 

• Start- und Stopzeichen des Datenblocks 


Wie im Codebeispiel S. 117 ersichtlich, besteht ein Deskriptor aus einem 

Tupel der Variablen, die in Tabelle 5.4 beschrieben ist. 



Variablename Bedeutung 

OParameter Name eines O-Parameters 

OParStart Start-Spaltennummer des Datenfeldes eines O- 

Parameters 

OParEnd End-Spaltennummer des Datenfeldes eines O- 

Parameters 

AnzOutPars Anzahl der O-Parameters eines Datensatz-Typs 

AnzPars Anzahl der Parameter, die der Dienst Netzberechnung 

verwendet 

Pars Namen der Parameter, die der Dienst Netzberechnung 

verwendet 

Tabelle 5.4: Spezifikationsdaten für einen Deskriptor 

Die optionalen Konvertierungsfunktionen werden mit Hilfe der Variablen 

ParKonvFuns vom Typ “Vektor” gespeichert. Die Dimension dieses 

Vektors wird durch die Variable AnzPars vorgegeben. 

Zur Spezifikation der verschiedenen Datensatztypen sind weitere Variable 

notwendig, um z.B. die Start- und Stopidentifikation eines Datenblocks 

zu speichern. 


In der Adaption wird aus den Spezifikationsdaten die adaptierbare Methode 

der Klasse “Netz”, F-Übersetzer genannt, erzeugt. Dies geschieht mit 

einem Codegenerator, der im Folgenden als F-Übersetzer-Generator bezeichnet 

wird. 

Seine Entwicklung ist ziemlich komplex, insbesondere dann, wenn eine 

möglichst allgemeine Verwendbarkeit angestrebt wird. Daneben gibt es für 

die Entwicklung folgende Randbedingungen: 

1. Tauschformat F (Syntax und Semantik): Die Implementation des F-- 

Übersetzer-Generators hängt vom zu übersetzenden Format F ab. Die 

bei der Analyse gefundenen relevanten Konstrukte bestimmen zusammen 

mit der Syntax des Formates die Implementation des F-Übersetzer-Generators 

und der Spezifikation. 

2. Schnittstelle zum Framework (API): Das API des Frameworks muss 

vor der Entwicklung des F-Übersetzers bekannt sein. Der F-Übersetzer 

benötigt sowohl die Konstruktoren der applikationsspezifischen 

Ntor- und Summengeber-Typen als auch die Methoden zu ihrer Einfügung 

und Verknüpfung innerhalb des Frameworks. 



Für alle 

Ntor-Typen 

der 

Applikation 

Start 

Blockweit gültige 

Übersetzung 

einrichten 

Typidentifikator 

TF 

bilden 

TF = TF ? 

1 

nein 

TF = TF ? 

2 

nein 

TF = TF ? 

n 

nein 

Ende 

Bus/Zweig Datensätze 

Fehler: fehlende Typ-Korrespondenz 

ja 

ja 

ja 

Ntor vom Typ TN instantiieren 

1 


2 


n 

Erzeugen 

Knoten 

alle 

Datensätze 

? 

ja 

alle 

Datenblöcke 

? 

Abbildung 5.14: Übersetzung von Bus/Zweig-Typ-Datenblöcken 


ja 

nein 

nein


Eine wesentliche Erschwernis beim Bau des F-Übersetzer-Generators 

kommt daher, dass sowohl mehrere zeitliche Phasen, wie Spezifikations-, 

Übersetz- und Laufzeit als auch mehrere Gültigkeitsbereiche von Variablenzuberücksichtigen 

sind. Der F-Übersetzer-Generator lässt sich 

am einfachsten durch den Zielcode beschreiben, den er erzeugt. Dabei 

schreibt eine Programmzeile des Generators genau eine C++-Programmzeile 

des Zielcodes in eine Quelltext-Datei : 

writeto(Quelltext-Datei ); 

... 

lprint(‘ eine Zielcode-Zeile ‘); 

Die Zielcode-Zeile stellt innerhalb des Generators eine Variable vom Typ 

Zeichenkette dar. Im einfachsten Fall wird diese Variable auf einen konstanten 

Wert gesetzt, um einen konstanten Codeteil, wie z.B. ein Sprachsymbol 

von C++ zu erzeugen. In komplexeren Fällen wird die Zeichenkette 

aus Teilen zusammengesetzt, die z.B. von den Spezifikationsdaten, den 

Aufrufparametern des F-Übersetzer-Generators oder von Variablen (z.B. 

Zählern) des Generators abhängen. 

Eine typische Programm-Struktur für die Interpretation des Tauschformates 

(vergl. Codebeispiel S. 109) ist im Flussdiagramm von Abbildung 

5.14 dargestellt. Dieses Flussdiagramm zeigt den Programmablauf bei der 

Übersetzung der Bus- und Zweigdatensätze. Die anderen Datensätze (siehe 

Anhang B) werden prinzipiell gleichbehandelt, wenn auch stark vereinfacht, 

da es z.B. keine unterschiedlichen Typen innerhalb eines Datenblocks 

gibt. 

Im Folgenden wird das Flussdiagramm von Abbildung 5.14 betrachtet. 

Da die Bus- und Zweigdatensätze nach der gleichen Syntax aufgebaut 

sind, lassen sie sich nach dem gleichen, blockweit gültigen Schema interpretieren. 

Es muss z.B. bei jedem Datenblock zunächst ein Blockanfang 

gefunden werden. Der Codegenerator erzeugt in diesem Fall ein Zielcodestück, 

das Netzdaten einliest, bis es auf ein bestimmtes Zeichen stösst. 

Dieses Zeichen ist abhängig von dem Spezifikationsdatum “Startzeichen 

des Datenblocks”. Der Codegenerator setzt dieses Zeichen in einen Zeichenkettenvergleich, 

wie z.B.: 

...strcmp(."‘.Startzeichen.‘" ...) == 0 ... 

Eine weitere, wichtige Gemeinsamkeit betrifft alle Bus- und Zweig-Da- 



Netzdaten 

Format F 

liest ruft auf 

Framework 

Objekt- 

Netzbestand 

Prozess zur Programm-Laufzeit 

Hinweis: liest 

A B 

F-Übersetzer 

Σ 

Framework 

API 

instantiiert Objekte 


Σ 

Σ 

bedeutet: B liest A. 

Abbildung 5.15: F-Übersetzer zur Laufzeit 

tensätze. Es ist die Übersetzung des Datensatzes in einen Ntor-Typ, wie 

dies in der inneren Schleife von Abbildung 5.14 dargestellt ist. Für die 

Typabfrage und die Ntor-Instantiierung kann der Codegenerator für alle 

Ntor-Typen, die der Klient in der Applikation verwenden will, den gleichen 

Zielcode erzeugen, mit der Ausnahme weniger Stellen. An diesen 

Stellen setzt der Codegenerator Zeichen in den Zielcode ein, die aus den 

Spezifikationen (siehe Korrespondenztabelle S. 118) und aus der Menge 

der verwendeten Ntore (Parameter NT) ableitbar sind. 

Zur Laufzeit ruft der Konstruktor der Klasse “Netz” die F-Übersetzer- 

Methode auf. Wie in Abbildung 5.15 ersichtlich, liest dabei der F-Übersetzer 

die Netzdaten und erzeugt mit Hilfe des API’s den Objektbestand für 

die gewünschte Netzberechnung. 

5.6.7 Diskussion der Lösung 

Die Übersetzung eines bestimmtes Tauschformats F [23] ist innerhalb der 

Domänen-Architektur möglich. Dabei ist in der vorliegenden Arbeit genau 

ein Format pro Dienst “Netzaufbau” übersetzt worden. Dieses Ergebnis hat 

für den Klienten folgende Konsequenzen: 

1. Der F-Übersetzer für das Tauschformat F ist wiederverwendbar. Die 

Übersetzung auf neue applikationsspezifische Ntor- und Summengebertypen 

lässt sich innerhalb der Spezifikation einfach anpassen.


2. Weitere Bus- und Zweigdatensätze innerhalb des Tauschformates F 

lassen sich durch Anpassung der Spezifikation übersetzen. 

3. Andere tabellenförmige Tauschformate, bei denen die Datenfelder 

ebenfalls durch Spaltenpositionen definiert sind, bedingen eine neue 

Implementation der Übersetzung, die strukturell der aktuellen Lösung 

ähnlich ist. 

4. Falls der Klient ein neues Austauschformat mit genügend abweichender 

Syntax verwenden will, muss er den Dienst “Netzaufbau” neu 

implementieren. In diesem Fall lässt sich evtl. noch die Spezifikation 

der Parameter-Konversion und Teile ihrer Implementation wiederverwenden. 

Zusammenfassend lässt sich der vorgestellte Dienst Netzaufbau wie folgt 

charakterisieren: 

Vorteile: Die Übersetzung der wichtigen Bus-Zweig Datensätze wird lokal 

innerhalb einer Ntor-Spezifikationen SN parametriert. Dieser Ansatz 

folgt daher der objekt-orientierten Betrachtungsweise. Zum Objekt gehörige 

Information ist auch dort angesiedelt. Dies erleichtert das Verständnis. 

Nachteile: Es braucht pro Tauschformat einen Satz von Ntor-Spezifikationen. 

Ferner ist der vorliegende Dienst auf das Tauschformat F und solche 

beschränkt, die ebenfalls eine tabellenförmige Struktur mit zeilenweiser 

Zuordnung von Datensätzen und eine Definition einzelner Datenfelder 

durch Spaltennummern aufweisen. 

5.7 Richtlinien für die Benutzung 

5.7.1 Einleitung 

Generell entscheidend für eine einfache Benutzung ist eine verständliche 

Dokumentation. Diese beinhaltet eine klare Darstellung des Domänenmodells, 

der erbrachten Dienste und der Voraussetzungen für die Anwendung 

des Frameworks. Ferner gehören Einsatz-Beispiele dazu, möglicherweise 

in Form von Tutorien oder Fallstudien. In einem vernetzten Informationssystem 

sind heute die Angaben von häufig gestellten Fragen (FAQ’s), 


5.7. RICHTLINIEN FÜR DIE BENUTZUNG 125 

Anwenderforen in Form von Diskussionsgruppen (usergroups) und Fehlerlisten 

mit Fehlerumgehungen üblich. 

Auf die DA übertragen, bedeutet dies, dass für eine Wiederverwendbarkeit 

ein Katalog der vorhandenen Dienste angelegt werden muss. Dazu 

sind die zugehörigen Spezifikationen, Spezifikationsdaten und Adaptionen 

zu dokumentieren. 

Die DA hilft dem Klienten, indem sie ein Vorgehen der Wiederverwendung 

und Anpassung innerhalb einer definierten Struktur vorgibt. Die Einzelteile 

dieser Struktur helfen mit, die Komplexität der Aufgabe zu reduzieren. 

Es werden einzelne Aufgabenschritte definiert. 

Der aufwendigste Schritt dabei ist die Entwicklung des Codegenerators 

im Adaptions-Element. Sie kann dann gelingen, wenn eine klare Vorstellung 

vom zu erzeugenden Code besteht und eine geeignete Parametrierung 

vorgenommen wird. Gerade wegen dieser Schwierigkeiten ist es sinnvoll, 

einen Rahmen für die Entwicklung festzulegen, der Konformität erzeugt, 

und dadurch Wiederverwendung und Erfahrungsaustausch zwischen Klienten 

und Framework-Entwickler fördert. 

5.7.2 Anpassung durch den Klienten 

In Abbildung 5.16 sind verschiedene Eingriffsstellen des Klienten auf Elemente 

der Architektur dargestellt. Je nach Umfang der Anpassung, nachfolgend 

Variation genannt, greift der Klienten an den Stellen (1,2,3) ein. 

Bei der Stelle (4) legt der Klient fest, wie sein Framework-Quelltext aufzubauen 

ist. Dazu dienen die Angaben NT, ST, D und VK. Der Klient bindet 

den zusammengebauten Quelltext entweder in das Default-Programm oder 

in sein eigenes Quellprogramm. 

Es gibt grundsätzlich die folgenden Fälle für die Wiederverwendung 

des Frameworks mit der DA, wobei die in Klammern angegebenen Zahlen 

die Eingriffstellen von Abbildung 5.16 bezeichnen: 

• Die Variation liegt im Spezifikationsbereich bestehender Dienste. Der 

Klient gibt in den Spezifikationsprozeduren neue Daten ein und/oder 

fügt neue Ntor- bzw. Summengeber-Typen hinzu (1). 

• Die Variation liegt in der Adaption eines bestehenden Dienstes. Der 

Klient muss dabei keine neuen Methoden und Attribute innerhalb des 

passiven API’s hinzufügen. Der Klient ändert dazu evtl. die Spezifikation 

S, die Daten V sowie die Adaption A. Beispiele: Neue, z.B. 



Programm-Familie auf der Basis des Domänenmodells 

Variabilität 

Gemeinsamkeit 

(Haupt-) 

Programm 

Laufzeitsystem 

Spezifikation 

Adaption 

parametriert 

Framework 

ausführbares 

Programm 

erzeugt Teile von 

ist eingebunden in 

Abbildung 5.16: Benutzung der DA 

Klient 

effizientere Berechnung für die Jacobi-Matrix, bzw. den Mismatch- 

Vektor (1),(2). 

• Die Variation liegt in der Adaption eines bestehenden Dienstes. Der 

Klient muss dabei neue Methoden und Attribute innerhalb des passiven 

API’s hinzufügen. Der Klient erweitert dabei das aktive API 

im Kontext der adaptierbaren Klassen, indem er in der Adaption neue 

Klassen-Methoden erzeugt und evtl. neue Attribute hinzufügt. Hierbei 

muss der Klient beachten, dass er innerhalb einer Klasse, die er 

auf diese Weise erweitert, die Eindeutigkeit von Namen beachtet, damit 

keine Seiteneffekte auf vorhandene, private Variablen entstehen. 

Beispiel: Berechnung spezieller Zwischenresultate. 

• Die bestehenden Dienste sind nicht wiederverwendbar. Sie lassen 

sich nur durch Änderung der Klassenstruktur innerhalb des Frameworks 

realisieren(3). In diesem Fall liegt das Problem ausserhalb 

der Domänen-Anforderungen. Beispiele: Optimierung, numerische 

Lösung von Differentialgleichungen. 


1 

2 

3 

4

5.7. RICHTLINIEN FÜR DIE BENUTZUNG 127 

5.7.3 Vorgehen bei Änderung eines Dienstes 

Änderungen innerhalb des variablen Anteils eines Dienstes sind möglich, 

sofern geeignete Adaptionsstellen bei der Entwicklung des Frameworks 

eingeplant worden sind. Angenommen, dass diese Voraussetzungen erfüllt 

sind, sind folgende Schritte vom Klienten auszuführen: 

1. Anforderungen an adaptierten Framework-Code erfassen. 

2. Test, ob es bereits eine Adaption mit ähnlichen Anforderungen gibt. 

Falls es solche gibt, können diese evtl. nach geeigneten Modifikationen 

wiederverwendet werden. 

3. Zielcode mit Hilfe des aktiven API’s des aktuellen Kontextes erarbeiten. 

4. Zielcode testen. 

5. Variable Teile des Zielcodes identifizieren. 

6. Test, ob es bereits Spezifikationsdaten gibt, aus denen die variablen 

Teile des Zielcodes erzeugbar sind. 

7. Falls keine Spezifikationsdaten existieren, sind solche zu schaffen. 

Dabei ist zu unterscheiden, welcher Kategorie (Netz oder Bausteine) 

die Spezifikation zuzuordnen ist. 

5.7.4 Erweiterung des Frameworks 

Weitere Dienste lassen sich am Framework nur dann einfügen, wenn der 

Klient in dem bestehenden Framework neue Adaptionsstellen hinzufügt. 

Dazu muss er für den neuen Dienst: 

• eine zusätzliche Methode und evtl. Attribute in der Klasse “Netz” 

ergänzen. Falls diese Methode einen variablen Anteil hat, muss auch 

eine Adaptionsstelle ergänzt werden. 

• Virtuelle Methoden in einer gemeinsamen Oberklasse der Bausteine 

vereinbaren. 

• Adaptionsstellen für die Baustein-Beteiligung ergänzen. 



Im Architektur-Ansatz der vorliegenden Arbeit ist es der Framework- 

Entwickler, der neue Dienste hinzufügt und damit das Framework gemäss 

dem in Abbildung 2.7 dargestellten, durch Wiederverwendung gesteuerten 

Software-Entwicklungsprozess (RSP-Prozess) erweitert. 


Kapitel 6 

Fallstudien 

Dieses Kapitel zeigt verschiedene Fälle aus dem Bereich der Netzberechnung. 

Das Augenmerk richtet sich vorallem auf eine vollständige Modellierung 

innerhalb der Domänen-Architektur. Dazu sind geeignete Ntorund 

Summengebertypen und ihr Verhalten gemäss Kapitel 3.2 festzulegen. 

Im Gegensatz zu den Beispielen der Kapitel 3, 4 und 5 wird der 

Aspekt des Netzaufbaus und der Parametrierung auf der Basis des Tauschformates 

[23] einbezogen. Neben dem Verhalten der Bausteine werden 

auch die Konvertierungsfunktionen spezifiziert, um anzugeben, wie man 

von den ausgewählten Datenfeldern des Tauschformates zu den Parametern 

der Ntor-Typen gelangt. Ferner werden die Code-Mengen angegeben, 

die auf den verschiedenen Ebenen der Domänen-Architektur (siehe Abbildung 

5.1) geschrieben bzw. erzeugt werden. 

Die ersten drei Fälle sind Lastfluss-Berechnungen. Es wird das fünfknotige 

Netz verwendet, das in Abbildung 6.1 dargestellt ist. Nichtumrandete 

Werte sind vorgegebene Parameterwerte, umrandete Grössen sind Resultate 

der ausgeführten Lastfluss-Simulation. Angaben ohne Masseinheit 

sind immer bezogene Grössen (p.u.-Werte). Die zugehörigen, computerlesbaren 

Netzdaten sind gemäss Tabelle 6.1 im Tauschformat [23] (siehe 

Anhang B) vorgegeben. Man beachte, dass bei jedem Fall eine individuelle 

Auswahl aus diesen Daten getroffen wird. 

Die Reihenfolge der Datensätze in der Tabelle 6.1 liefert die Instanzennamen 

OP... bzw. TP... von Ntoren in Abbildung 6.1. Die unter “BUS 

DATA” aufgeführten Datensätze werden mit dem Namen OP, diejenigen 

unter “BRANCH DATA” mit TP gekennzeichnet. Die unterste Zeile der 

Netzdaten von Tabelle 6.1 dient als Skala zur Lokalisierung der Zeichenketten. 

In den Tabellen 6.3, 6.4, 6.5, 6.8, 6.9 und 6.11 wird durch Angabe der 

129 


130 KAPITEL 6. FALLSTUDIEN 

OP1 

SlackGen 

P=2 MW 

Q=-2.21MVar 

1 

PQ-Last 

P=2MW 

Q=0MVar 

OP2 

Bus1 

1 

1.00 0.00 0 

1 

Z 

TP6 

Bus2 

2 

0.88 27.2 0 

Z 

TP7 

1 2 

Z 

TP8 

1 2 

1.00 57.3 

Bus3 

0 

2 1 

OP3 

PVGen 


1 

Z 

TP9 

P= 5MW 

Q=-2.46MVar 

Abbildung 6.1: Netzwerk zu Fallstudien 

1.00 53.9 

Bus5 

0 

0.87 

OP5 

1 

PQ-Last 

P=0.6 MW 

Q=0MVar 

Bus4 OP4 

1 

PQ-Last 

P=0.4 MW 

Q=0MVar 

03/26/96 -- -------- 1.0 1997 W ---- 5 Bus Test Case 

BUS DATA FOLLOWS 5 ITEMS 

1 Bus 1 HV 2 1 3 1.000 0.0 0.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 0 

1 Bus 2 HV 2 1 0 1.000 0.0 2.0 0.0 0.0 0.0 0.0 1.0 1.1 0.9 0.0 0.0 0 

3 Bus 3 HV 2 1 2 1.000 0.0 0.0 0.0 5.0 0.0 0.0 1.0 10.0 -10.0 0.0 0.0 3 

4 Bus 4 HV 2 1 0 1.000 0.0 0.4 0.0 0.0 0.0 0.0 1.0 1.2 0.8 0.0 0.0 0 

5 Bus 5 HV 2 1 0 1.000 0.0 0.6 0.0 0.0 0.0 0.0 1.0 1.2 0.8 0.0 0.0 0 

-999 

BRANCH DATA FOLLOWS 

1 2 1 1 1 0 0.0 0.1 0.0 0 0 0 0 0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 

2 3 1 1 1 0 0.0 0.1 0.0 0 0 0 0 0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 

2 4 1 1 1 0 0.0 0.1 0.0 0 0 0 0 0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 

5 3 1 1 1 0 0.0 0.1 0.0 0 0 0 0 0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 

-999 4 ITEMS 

INTERCHANGE DATA FOLLOWS 1 ITEMS 

1 2 Bus 2 HV 2.0 1.00 ------ ---- 5 Bus Test Case 

-9 

TIE LINES FOLLOWS 3 ITEMS 

2 1 1 2 1 

4 2 2 1 1 

3 1 5 2 1 

-999 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 

1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 

Tabelle 6.1: Netzdaten 

Start- und End-Position festgelegt, welche Zeichen als Daten für die einzelnen 

Fälle zu interpretieren sind. 

In der Tabelle 6.2 wird angegeben, in welche Ntor-Typen die Typen 

“BUS” und “BRANCH” des Tauschformates zu übersetzen sind. 

Die Tabelle 6.3 spezifiziert die Gemeinsamkeiten unter den Bus- und 

Zweigdatensätzen. Dies bezieht sich auf die Zeilen 3 bis 7, bzw. 10 bis 

13 von Tabelle 6.1. Man beachte, dass die Spezifikation der Positionen 

einzelner Datenfelder durch die Domänen-Architektur nicht festgelegt ist. 

Dieser Freiheitsgrad lässt sich ausnutzen, um eine einfachere Spezifikation 

und/oder Implementation der Adaption zu erzielen. Im Gegensatz zu den 

übrigen Spezifikationen, die mit Start- und Endpositionen arbeiten, werden 

Datenfelder in Tabelle 6.3 mit Hilfe von Feldlängen und Abständen 

zwischen Datenfeldern lokalisiert. 

24.2 

0

Datensatzname Typidentifikation Typname des 

Ntors 

BUS 0 PQLast 

BUS 1 PQGen 

BUS 2 PVGen 

BUS 3 SlackGen 

BRANCH 0 Z 

Tabelle 6.2: Korrespondenz-Tabelle 

Bus-Datensatz Zweig-Datensatz 

Start-Zeichen BUS BRANCH 

Stop-Zeichen -999 -999 

Anz. el. Anschlüsse 1 2 

Feldlänge 3 3 

Knotenbezeichnung 

Abstand zwischen 2 2 

Knotenbezeichnungen 

End-Position der 4 9 

Knotenbezeichnung 

Feldlänge der 1 0 

Typidentifikation 

Start-Position 25 19 

Typidentifikation 

Feldlänge 1 1 

Austauschgebiet 

Start-Position 19 11 


Tabelle 6.3: Gemeinsame Übersetzungsangaben 

Die netzweit geltenden Parameter von Tabelle 6.1 werden mit Hilfe der 

Angaben von Tabelle 6.4 spezifiziert. 

In den ersten drei Fällen wird mit bezogenen Grössen gearbeitet. Die 

gemeinsame Bezugsgrösse ist die Scheinleistung in Megawatt. Sie lässt 

sich mit den Angaben der Tabelle 6.4 aus den Netzdaten lesen. Im Netz 

kommt nur eine Bezugsspannung vor. Sie wird als 1 kV angenommen. 

Parameter Datentyp Start-Position End-Position 

Bezugs-Scheinleistung f 32 37 

(SB) 

Tabelle 6.4: Netzweit geltende Parameter 


131


6.1 Lastfluss in kartesischen Koordinaten 

Als Basisfall wird ein stationärer Wechselstrom-Lastfluss betrachtet. Es 

wird angenommen, dass es sich um ein symmetrisches Übertragungsnetz 

handelt. Die Unbekannten lassen sich daher als komplexe Grössen darstellen. 

Dies geschieht mit Variablen e und f für die kartesischen Koordinaten 

der Spannung e + j · f und ie und if für den Strom ie + j · if.DieseVariablen 

gelten bei allen elektrischen Anschlüssen der elektrischen Entitäten 

”SlackGen”, “PVGen”, “PQLast”, und “Z”. Diese Entitäten werden als 

Ntor-Typen realisiert und unter 6.1.1 beschrieben. 

Die Spannungsregelung des “PVGen” wird über einen zweiten elektrischen 

Anschluss realisiert. Zur Laufzeit wird dieser Anschluss mit demjenigen 

Kirchhoff-Knoten verbunden, der von den Netzdaten vorgegeben 

wird. Das Ntor formuliert dazu eine Gleichung mit den Spannungskomponenten 

dieses Anschlusses. Da ein elektrischer Anschluss in diesem 

Fall jedoch zwei Stromkomponenten enthält, müssen auch diese mit je einer 

Gleichung im Ntor-Typ “PVGen” einbezogen werden. Der elektrische 

Anschluss wird in diesem Fall als Sollwert-Eingang einer stromlosen Messung 

aufgefasst. Beide Komponenten des Stromes sind daher Null. 

6.1.1 Spezifikation der Ntor-Typen 

SlackGen (Slack-Generator für das ganze Netz): 

V = { e1, f1,ie1,if1,P,Q },T ={},P ={esl, fsl } 

E ={ e1−esl = 0, f1 − fsl=0, 

P−esl · ie1 − fsl·if1 =0, 

Q+esl · if1− fsl·Ie1 = 0 } 

Die Gleichungen stellen die Lastflussgleichungen dar, die in Kapitel 3 

mit Hilfe der Gleichungen (3.8) und (3.12) hergeleitet und in Tabelle 3.5 

zusammengefasst sind. 

Die Netzdaten im betrachteten Tauschformat liefern die Spannungen 

in polarer Darstellung (siehe Tabelle 6.5). Der Spannungswinkel wird in 

Grad vorgegeben. Die Gleichungen sollen aber in kartesischer Darstellung 

formuliert werden. Daher ist eine Umrechnung, wie in Tabelle 6.6 ersichtlich, 

zu spezifizieren. 

PQLast: 

V = { e1, f1,ie1,if1 },T ={},P ={P,Q } 


6.1. LASTFLUSS IN KARTESISCHEN KOORDINATEN 133 

Ntor-Typ O-Parameter Datentyp Start-Position End-Position 

Slack Θo f 34 40 

Uo f 85 90 

PQLast PLo f 41 49 

QLo f 50 59 

PVGen PGo f 60 67 

Uo f 85 90 

Qmaxo f 91 98 

Qmino f 99 106 

RVCo s 124 127 

Z Ro f 20 29 

Xo f 30 40 

Tabelle 6.5: Parameter für die Ntor-Typen 

Ntor-Typ Parameter Konvertierungs-Funktion 

f(O-Parameter) 

Slack esl esl = Uo · cos( Θo·π 

180 ) 

fsl fsl =Uo·sin( Θo·π 

180 ) 

PQLast P P = PLo/SB 

Q Q = QLo/SB 

PVGen P P = −PGo/SB 

U 

Qmax 

U = Uo 

Qmax = Qmaxo /SB 

Qmin Qmin = Qmino /SB 

Z R R = Ro 

X X = Xo 

Tabelle 6.6: Konvertierungsfunktionen für die Ntor-Typen 

E = { ie1 − e1·P+f1·Q 

e1 2 +f1 2 = 0,if1− −e1·Q+P·f1 

e1 2 +f1 2 =0 } 

Für die Spezifikation des Verhaltens des Ntors “PQLast” werden die Parameter 

“P” (Wirkleistung) und Q (Blindleistung) als bezogenene Grössen 

(p.u.-Werte) benötigt. In der Tabelle 6.5 werden die O-Parameter PLo bzw. 

QLo aus den Netzdaten festgelegt und mit Hilfe der in Tabelle 6.6 angegebenen 

Beziehungen in bezogene Darstellung umgerechnet. 

PVGen (PV-Generator): 

Der “PVGen” ändert sein Verhalten von einem PV- zu einem PQ-Typ, 

da der “PVGen” nur eine begrenzte Blindleistung Q 

(z.B. ±10MVar) erzeugen kann, um die Spannung “V” konstant zu halten. 

Es sind drei verschiedene Zustände notwendig, um die verschiedenen 

Verhalten zu realisieren. Im Zustand 1 verhält sich das Ntor wie ein “PV- 

Knoten”, der auf S. 30 beschrieben ist. Wird der Bereich der erzeugbaren 

Blindleistung über- bzw. unterschritten, ändert sich das Verhalten des 



Ntors in dasjenige eines “PQ-Knotens”. Beim Überschreiten der Grenze, 

d.h. bei Q ≥ Qmax, geht das Ntor in den Zustand 2 über. Beim Unterschreiten 

der Grenze, d.h. bei Qmin ≥ Q, geht das Ntor in den Zustand 3 

über. Die Indizes der folgenden Mengen zeigen an, in welchem Zustand 

das spezifizierte Verhalten gilt. Die leeren Mengen T2 und T3 bedeuten, 

dass das Ntor unabhängig von der Blindleistung in den Zuständen 2 und 3 

bleibt. 

V1 = { e1, f1,ie1,if1,Q } 

P1 ={ P,U,Qmin,Qmax } 

E 1 = { ie1 − e1·P+f1·Q 

e1 2 +f1 2 = 0,if1− −e1·Q+P·f1 

e1 2 +f1 2 

U 2 −e 2 1 − f2 1 

=0 } 

T1 ={ Q−Qmax ≥ 0, ⇒ 2 

Qmin − Q ≥ 0, ⇒ 3} 

V2 = { e1, f1,ie1,if1, },T2 ={} 

P2 ={ P,Qmax } 

E 2 = { ie1 − e1·P+f1·Qmax 

e1 2 +f1 2 

V3 = { e1, f1,ie1,if1, },T3 ={} 

P3 ={ P,Qmin } 

E 3 = { ie1 − e1 P+f1·Qmin 

e1 2 +f1 2 


=0 

= 0,if1− −e1·Qmax+P·f1 

e1 2 +f1 2 

= 0,if1− −e1·Qmin+P·f1 

e1 2 +f1 2 

= 0} 

= 0} 

Für die Spezifikation des Verhaltens des Ntors “PVGen” werden die Parameter 

P (Wirkleistung), Qmin (minimale Blindleistung) und Qmax als bezogenene 

Grössen (p.u.-Werte) benötigt. In der Tabelle 6.5 werden die 

O-Parameter aus den Netzdaten ausgewählt und mit Hilfe der in Tabelle 

6.6 angegebenen Beziehungen in bezogene Darstellung umgerechnet. 

Z (Impedanz): Die folgenden Angaben spezifizieren eine Längsimpedanz 

mit Z = R + j · X. V = { e1, f1,ie1,if1,e2,f2,ie2,if2 } 

P ={ R,X },T ={} 

Mit Hilfe der Kirchhoffschen Gleichungen und der Bildung von Real- (ℜ) 

und Imaginärteil (ℑ) lassen sich die Fehlerfunktionen angeben: 

e1+ jf1 

E = { ie1 − ℜ R+jX −e2+jf2 

 

R+jX =0, ie2 + ie1 = 0, 

 

e1+jf1 

if1−ℑ R+jX ,−e2+jf2 

 

R+jX =0, if2+if1 =0 } 

Für die Spezifikation des Verhaltens des Ntors “Z” werden die ParameterR(Längswiderstand) 

und X (Längsreaktanz) benötigt. In der Tabelle 

6.5 werden die O-Parameter aus den Netzdaten festgelegt und gemäss Tabelle 

6.6 den Parametern R und X zugewiesen. Man beachte, dass die

6.2. LASTFLUSS IN POLAREN SPANNUNGSKOORDINATEN 135 

Zuweisung von O-Parametern auf die Parameter immer über eine Konvertierungsfunktion, 

im einfachsten Fall durch den Faktor 1 erfolgt. 

6.1.2 Spezifikation der Summengeber-Typen 

Bus1...Bus5 sind die elektrischen Verbindungsstellen des Netzes. Sie werden 

mit Hilfe von Summengebern modelliert. 

Elektrische Verbindungsstelle: 

S = { EinzeiligeSumme(Basisname = ie), 

EinzeiligeSumme(Basisname = if), 

MehrzeiligeSumme(Basisname = e), 

MehrzeiligeSumme(Basisname = f ) } 

6.2 Lastfluss in polaren Spannungskoordinaten 

In diesem Fall wird der gleiche Wechselstrom-Lastfluss wie unter Kapitel 

6.1, jedoch mit polaren Koordinaten gerechnet. Für jeden elektrischen 

Anschluss gibt es für die komplexe Spannung U = U · e j·Θ die Variablen 

U und Θ. Beim Strom, der wiederum in der kartesischen Form ie + j · if 

dargestellt wird, sind es die Variablen ie und if. 

Man beachte, dass die Summengeber die Stromsummen nicht in polarer 

Form behandeln können, da nur lineare Terme mit dem Faktor 1 summierbar 

sind. 



V = { U1,Θ1,ie1,if1,P,Q },T ={},P ={Usl,Θsl } 

E = { U1 −Usl = 0,Θ1 − Θsl = 0, 

P −Usl · cos(Θsl) · ie1 −Usl · sin(Θsl) · if1 =0, 

Q+Usl · cos(Θsl) · if1−Usl · sin(Θsl) · ie1 = 0 } 

Es werden grundsätzlich die gleichen O-Parameter wie beim kartesischen 

Lastfluss verwendet (siehe Tabelle 6.5). Hingegen gibt es, wie in Tabelle 

6.7 aufgezeigt, einfachere Konvertierungsfunktionen für die Parameter 

Usl und Θsl da die O-Parameter bereits eine polare Form des Ntor-Typs 

“Slack” aufweisen. 



PQLast: 



Slack Usl Usl = Uo 

Θsl 

Θsl = Θo·π 

180 


V = { U1,Θ1,ie1,if1 },T ={};,P ={P,Q } 

E ={ ie1 ·U1 − cos(Θ1) · P −U1 · sin(Θ1) · Q = 0, 

if1·U1+cos(Θ1) · Q − P · sin(Θ1)=0 } 

PVGen (PV-Generator): 

V1 = { U1,Θ1,ie1,if1,Q } 

P1 ={ P,U,Qmin,Qmax } 

E 1 = { ie1 ·U1 − cos(Θ1) · P − sin(Θ1) · Q = 0, 

if1·U1+cos(Θ1) · Q − P· sin(Θ1)=0 

U−U1=0 } 

T1 ={ Q−Qmax ≥ 0, ⇒ 2 

Qmin − Q ≥ 0, ⇒ 3} 

V2 = { U1,Θ1,ie1,if1 },T2 ={} 

P2 ={ P,Qmax } 

E 2 = { ie1 ·U1 − cos(Θ1) · P − sin(Θ1) · Qmax = 0, 

if1·U1+cos(Θ1) · Qmax − P · sin(Θ1)=0} 

V3 ={ U1,Θ1,ie1,if1, },T3 ={} 

P3 ={ P,Qmin } 

E 3 = { ie1 ·U1 − cos(Θ1) · P − sin(Θ1) · Qmin = 0, 

if1·U1+cos(Θ1) · Qmin − P · sin(Θ1)=0} 


6.3. WECHSELSTROM-LASTFLUSS MIT AUSTAUSCHGEBIET 137 

Z (Impedanz): 

V = { U1,Θ1,ie1,if1,U2,Θ2,ie2,if2 } 

P ={ R,X },T ={} 

E ={ ie1 − ℜ 

ie2 + ie1 = 0, 

if1−ℑ 

U1·cos(Θ1)+ j·U1·sin(Θ1) 

R+ j·X 

U1·cos(Θ1)+ j·U1·sin(Θ1) 

R+ j·X 

if2+if1 =0 } 


− U2·cos(Θ2)+ 

 

j·U2·sin(Θ1) 

R+ j·X = 0, 

− U2·cos(Θ2)+ 

 

j·U2·sin(Θ1) 

R+ j·X = 0, 

Die elektrischen Verbindungsstellen Bus1...Bus5 werden mit Hilfe von 

Summengebern modelliert: Elektrische Verbindungsstelle (Kirchhoff) 

: 

S = { EinzeiligeSumme(Basisname = ie), 

EinzeiligeSumme(Basisname = if), 

MehrzeiligeSumme(Basisname = U), 

MehrzeiligeSumme(Basisname = Θ) } 

6.3 Wechselstrom-Lastfluss mit Austauschgebiet 

Das unter Kapitel 6.1 beschriebene Lastfluss-Problem wird in diesem Fall 

erweitert. Als zusätzliche Bedingung kommt eine Bilanz von Wirkleistungen 

innerhalb eines bestimmten Netzbereiches hinzu. Ein solcher Netzbereich 

wird als Austauschgebiet bezeichnet. In Abbildung 6.2 ist ein 

Austauschgebiet eingezeichnet. Besondere Bedeutung haben darin Verbindungen, 

welche die Grenze des Austauschgebietes schneiden. Es sind 

die Verbindungen, über die Wirkleistung mit dem restlichen Netz ausgetauscht 

wird. Im Beispiel soll in das Austauschgebiet eine Wirkleistung 

von 2MW importiert werden. Dies lässt sich durch die Gleichung (6.1) 

ausdrücken: 

PTP61 

+PTP82 +PTP91 −2=0 (6.1) 



OP1 

SlackGen 

P=-5.0 MW 

Q=-0.46MVAr 

1 

PQLoad 

P=2MW 

Q=0MVar 

OP2 

Bus1 

1 

1.00 0.00 0 

Σ 

PTP6 

1 

3.0 MW 

Pk 

> 0: 

i 

Import in das 


1 

1.00 8.64 

Bus3 

0 


Bus2 

Z 

TP6 

1.00 

2 

-17 

PImport 

0 

Z 

TP7 

1 2 

Z 

TP8 

= 2 MW 

1 2 

OP10 

AreaSlackGen 

1 

P=7.0 MW 

Q=-1.5 MVAr 

2 1 

OP3 

PVGen 

1 

P= 5MW 

Q=-1.06MVAr 

0 

1.00 -19.8 


Z 

TP9 

Abbildung 6.2: Netzwerk mit Austauschgebiet 

U 

Austauschgebiet c 

P 

Σ 

1.00 5.2 0 

P Bus5 

TP9 1 

OP5 

-0.6 MW 

1 

PQLoad 

P=0.6MW 

Q=0MVar 

Ntor an Gebiets- 

KH 

grenze k 

i 

KH 

Ik 

i 

P k i 

k 

i 

i 

Bus4 OP4 

P 

TP8 2 

-0.4 MW 

1 

PQLoad 

P=0.4MW 

Q=0MVar 

Abbildung 6.3: Vorzeichenfestlegung bei ausgetauschter Wirkleistungen 

Σ

6.3. WECHSELSTROM-LASTFLUSS MIT AUSTAUSCHGEBIET 139 

6.3.1 Modellierung eines Austauschgebietes 

Jedes Ntor k mit mindestens zwei elektrischen Anschlüssen benötigt für 

den an einer Grenze liegenden Ntor-Anschluss mit der Nummer i einen 

Anschluss auf die Wirkleistung Pki . 

Bei kartesischen Koordinaten ist die Wirkleistung: 

Pki = ℜ((eki + jfki )(ieki + j · ifki )∗ ) (6.2) 

Aus dem Netzbestand lässt sich die Nummer i des an der geographischen 

Grenze liegenden Anschlusses eines Ntors k herausfinden. Dies geschieht 

mit der Funktion A(k, c). Diese Funktion gibt die Nummer i des Anschlusses 

eines Ntors k zurück, das am inneren Rande eines Austauschgebietes c 

liegt. 

Für ein Austauschgebiet c mit n an der geographischen Grenze liegender 

Ntore ist die importierte Leistung: 

PImportec = 

n 

∑ PkA(k,c) 

k=1 


(6.3) 

Diese zusätzliche Gleichung muss natürlich durch eine zusätzliche Variable 

ausgeglichen werden, damit die Anzahl von Gleichungen und Variablen 

im gesamten Gleichungssystem übereinstimmt. Die zusätzliche Variable 

wird einem Betriebsmittel, dem Ntor-Typ “SlackArea”, zugeordnet. 

Die Variable P des “SlackArea” stellt sich im Zuge der Rechnung so ein, 

dass die geforderte importierte Wirkleistung erbracht wird. 


SlackArea (Slack-Generator für Austausch-Gebiet): 

V = { e1, f1,ie1,if1,P,Q },T ={} 

P ={ U } 

E ={ ie1 − e1 P+f1 Q 

e1 2 +f1 2 = 0,if1− −e1Q+Pf1 

e1 2 +f1 2 

U 2 −e 2 1 − f2 1 

=0 } 

=0, 

Der SlackArea-Generator benötigt keine Übersetzungs-Daten. Es wird 

angenommen, dass er stets einem Knoten innerhalb eines Austauschgebietes 

zugeordnet werden kann, z.B. dem grössten Wirkleistungsproduzenten. 

An den Grenzen des Austauschgebietes sind in Abbildung 6.2 Instanzen 

des Ntor-Typs “Z” eingesetzt. Damit dieser Ntor-Typ in der Wirkleistungsbilanz 

von Gleichung (6.1) beteiligt werden kann, muss er die Wirkleistungen 

P1 und P2 als Variable zur Verfügung stellen:


Z (Impedanz): 

V = { e1, f1,ie1,if1,e2,f2,ie2,if2,P1,P2 } 

P ={ R,X },T ={} 

 

E ={ ie1 − ℜ 

if1−ℑ 

ie2 + ie1 = 0, 

if2+if1 =0, 

 

e1+ jf1 

R+jX −e2+jf2 

R+jX 

 

e1+jf1 

R+jX −e2+jf2 

R+jX 

=0, 

 

=0, 

P1−ℜ((e1 + jf1)(ie1 + jif1) ∗ )=0, 

P2−ℜ((e2 + jf2)(ie2 + jif2) ∗ )=0 } 

Die Zugehörigkeit zu Austauschgebieten fehlt in den “BRANCH”-Datensätzen 

des Austauschformates [23]. Die Angaben werden in den Datensätzen 

ergänzt, die in der Tabelle 6.1 mit “Tie-Lines” bezeichnet sind. 

Die Tabelle 6.8 spezifiziert aus den “Tie-Line”-Datensätze Parameter, aus 

denen der Dienst Netzaufbau alle n an der geographischen Grenze des Austauschgebietes 

liegenden Ntore und ihre Anschluss-Nummern i herausfindet. 

Der Eintrag 1 : 1 in den Tabellen 6.8 und 6.9 unter der Spalte “Konvertierungsfunktion” 

bedeutet, dass es pro O-Parameter genau ein zugehöriger 

Parameter mit dem gleichen Namen gibt. Der Wert wird unverändert vom 

O-Parameter auf den Parameter übertragen. 

O-Parameter Datentyp Start- End- Konvertierungs- 

Position Position Funktion 

Bus-Nummer am s 1 4 1:1 

“Meter”-Anschluss 

Nummer des d 7 8 1:1 

Austauschgebietes beim 

“Meter”-Anschluss 

Bus-Nummer am s 11 14 1:1 

“Non-Meter”-Anschluss 


Austauschgebietes beim 

“Non-Meter”-Anschluss 

Tabelle 6.8: Parameter für Grenzleitungen 


6.4. LINEARE NETZBERECHNUNG 141 


Der Kirchhoff-Knoten ist wie in Kapitel 6.1 modelliert. Die Summengleichung 

(6.3) für das Austauschgebiet wird mit Hilfe eines Summengebers 

realisiert. Dieser wird als einzeilige Summe parametriert, wie dies in Gleichung 

(3.20) beschrieben ist. Da die Formen der Gleichungen (3.20) und 

(6.3) unterschiedlich sind, ist der Parameter par der einzeiligen Summe 

mit der negativen importierten Wirkleistung als PImport zu identifizieren. 

Die dazu notwendige Multiplikation mit -1 wird in der Konvertierungsfunktion 

von Tabelle 6.10 bewerkstelligt. Ferner geschieht hier der Übergang 

auf die bezogene Grösse, indem der Wert noch durch die Bezugsscheinleistung 

SB dividiert wird. 

Austauschgebiet für Wirkleistung: 

S = { EinzeiligeSumme( Basisname = P , 

par = PImport) } 

Mit den Angaben von Tabelle 6.9 werden Netzdaten ausgefiltert, die 

zur Instantiierung des Summengebers benötigt werden. Dies ist PImport, 

die Nummer des Austauschgebietes c und die Nummer des Knotens, an 

welchem ein Ntor vom Typ “SlackArea” anzuschliessen ist. 

O-Parameter Datentyp Start- End- Konvertierungs- 

Position Position Funktion 


Austauschgebietes 

Bus-Nummer des d 4 7 1:1 

SlackArea 

PExport f 21 28 siehe Tabelle 6.10 

Tabelle 6.9: Parameter für das Austauschgebiet 

Parameter Konvertierungs-Funktion 

des Summengebers f(O-Parameter) 

PImport 

PImport = PExport 

SB 

Tabelle 6.10: Konvertierungsfunktionen für das Austauschgebiet 

6.4 Lineare Netzberechnung 

In diesem Fall wird eine Kurzschluss-Rechnung in einem dreiphasigen 

Übertragungsnetz mit den Phasen R,S und T skizziert. Da bei dieser 



OP1 

Quelle 

Last 

OP2 

Bus1 

1 

1 

1 

Z 

TP6 

Bus2 

2 

Z 

TP7 

1 2 

Z 

TP8 

1 2 

Bus3 

TP9 1 2 

Kurzschluss 

2 1 


1 

Z 

OP3 

Quelle 

Abbildung 6.4: Netzwerk mit Kurzschluss 

Bus5 

Bus4 OP4 

1 

Last 

OP5 

1 

Last 

Kurzschluss-Rechnung keinerlei Leistungsvorgaben in den Ntoren auftreten, 

wird das gesamte Gleichungssystemg(x,p)=0 rein linear. Dies ist ein 

Spezialfall, den die Domänen-Architektur ebenfalls abdeckt. Es wird wieder 

vom Netz der Abbildung 6.1 ausgegangen. Dieses Netz muss jetzt so 

verallgemeinert verstanden werden, dass jede gezeichnete Verbindung drei 

gekoppelten Phasen R, S und T entspricht. Zwischen dem Ntor “TP9” und 

“Bus5” tritt jedoch, wie in Abbildung 6.4 eingezeichnet, ein Kurzschluss 

zwischen den Phasen S und T auf. 

Da sich dieser Fall nicht direkt aus Daten im Tauschformat [23] aufbauen 

lässt, werden in Abbildung 6.4 keine Zahlenwerte vorgegeben. Die 

folgende Modellierung beschränkt sich daher auf das Verhalten von charakteristischen 

Ntor-Typen. 

Bei dieser Simulation ist man an den stationären Strömen sowie dem 

Kurzschlussstrom ieKS + j ·ifKS (siehe Abbildung 6.6) im Netz interessiert. 

Die Unbekannten lassen sich daher als komplexe Grössen darstellen. 

Bei kartesischen Koordinaten ist die Menge der Variablen für jeden elek- 

trischen Anschluss i: 

Vi = {eRi ,eSi ,eTi , fRi , fSi , fTi ,ieRi ,ieSi ,ieTi ,ifRi ,ifSi ,ifTi } 

Diese Variablen gelten bei allen elektrischen Anschlüssen der elektrischen 

Entitäten Quelle, Last, Z und Kurzschluss. 

Z (3-phasige Leitung mit gekoppelten Phasen): 

In Abbildung 6.5 ist das Ersatzschaltbild mit allen Grössen der Phase R sowie 

die induktiven Kopplungen M der anderen Phasenströme eingetragen. 

Daraus lässt sich folgendes Ntor-Verhalten ableiten, wobei ω die Kreisfrequenz 

bezeichnet: 

V = { V1, V2 } , T = {} 

P ={ RR,RS,RT,XR,XS,XT,ω,MRS,MRT,MST }

6.4. LINEARE NETZBERECHNUNG 143 

R 

S 

T 

R 

S 

T 

e ie R R + j X 

R1 + j f R1 R1 + j ifR1 R ie R2 + j ifR2 

e R2 + j fR2 

1 

M 

2 

M 

RT 

RS 


M ST 

Abbildung 6.5: Ersatzschaltung für Ntor-Typ “Z” 

e R1 + j f R1 ieR1 + j ifR1 ie R2 + j ifR2 

e R2 + j f R2 

1 

ieKS + j if KS 

Abbildung 6.6: Ersatzschaltung für Ntor-Typ “Kurzschluss zwischen Phasen R und T” 

E = { −eR1 +ieR1 · RR − ifR1 ·XR− 

ω·MRS · ifS1−ω·MRT · ifT1 +eR2 =0, 

−fR1 +ieR1 · XR + ifR1 ·RR+ 

ω·MRS · ieS1 + ω · MRT · ifT1 + fR2 =0, 

ieR1 + ieR2 = 0, ifR1 +ifR2 =0, 

für die Phasen S und T entsprechend} 

Die Ntor-Typen “Quelle” und “Last” lassen sich in gleicher Art modellieren. 

Die Fehlerstelle wird ebenfalls als Ntor mit zwei Anschlüssen modelliert: 

Kurzschluss (Fehler zwischen Phasen S und T): 

In Abbildung 6.6 ist das Ersatzschaltbild der Fehlerstelle mit den Grössen 

der Phase R eingetragen. Die Phasen S und T sind analog bezeichnet. Man 

beachte, dass es sich um ein Ntor mit einem Kurzschluss-Element handelt, 

bei dem alle Impedanzen echt Null sind. Daher lässt sich folgendes Ntor- 

Verhalten ableiten: 

V = { V1, V2 ,ieKS ,ifKS } ,T = {} 

P ={ } 

2


E = { ieR1 + ieR2 = 0,ifR1 +ifR2 =0, 

ieS1 + ieS2 + ieT1 + ieT2 = 0,ifS1 +ifS2 +ifT1 +ifT2 =0, 

ieS1 + ieS2 − ieKS = 0,ifS1 +ifS2−ifKS = 0, 

eR1−eR2 = 0,eS1 −eS2 = 0,eS1 −eT1 = 0, 

eT1 −eT2 = 0, 

fR1 − fR2 = 0, fS1 − fS2 = 0, fS1 − fT1 = 0, 

fT1 − fT2 = 0} 

Damit dieser Fall aus den Netzdaten des Tauschformates [23] aufgebaut 

werden könnte, müssten die Parametern des Mit- und Nullsystems der Elemente 

“Quelle”, “Last” und “Z” spezifiziert werden. 

6.5 DC-Lastfluss 

In zahlreichen Fällen ist man für erste Abschätzungen an Näherungslösungen 

des Lastflussproblems interessiert. Der DC-Lastfluss ist eine vereinfachte 

Modellierung bei der an allen Knoten i die Wirkleistungen Pi vorgegeben 

sind. Daraus werden die Spannungswinkel Θi näherungsweise berechnet. 

Dabei nützt man die physikalische Tatsache aus, dass Wirk- und 

Blindleistungsbeziehungen relativ schwach gekoppelt sind. Ferner werden 

folgende Annahmen getroffen: 

1. Die Spannungsbeträge Ui in den Knoten i werden netzweit vorgegeben. 

Ein typischer Wert ist der Spannungsbetrag des Slack-Knotens, 

d.h. 1 (p.u.). 

2. Die Leitungsimpedanzen sind rein imaginär, d.h. Z = j ·X. Ferner ist 

der Blindleistungsfluss am Leitungsanfang und -ende gleich gross. 

3. Netzelemente, bei denen der Blindleistungsfluss am Leitungsanfang 

und -ende nicht gleich gross ist, wie z.B. Kompensationsdrosseln etc., 

werden weggelassen. 

Bei der Modellierung mit Ntoren kann daher jedem elektrischen Anschluss 

eine Variable mit der Bedeutung der Wirkleistung P, des Spannungswinkels 

Θ und des Spannungsbetrags U zugeordnet werden. Das 

IEEE Common Format sieht für den Längszweig keine Knotenspannungswerte 

vor. Das Modell des Längszweiges benötigt aber zwei Spannungswerte. 

In der hier aufgezeigten Lösung werden die Spannungswerte über 

die elektrischen Anschlüsse mit der Variablen U in die Längszweige übermittelt. 


6.5. DC-LASTFLUSS 145 

Die Verbindung zwischen den Ntoren wird in diesem Fall durch die 

Potentialvariablen Θ und U sowie durch die Flussvariable P ausgedrückt. 



V = { U1,P1,Θ1 } , T = {},P ={Θsl,Usl } 

Ntor-Typ O-Parameter Datentyp Start-Position End-Position 

Slack Θo f 34 40 

Uo f 85 90 

PLast PLo f 41 49 

PGen PGo f 41 49 

Z Xo f 30 40 

Tabelle 6.11: Parameter für die Ntor-Typen 



Slack Usl Usl = Uo 

Θsl 

Θsl = Θo·π 

180 

PLast P P = PLo/SB 

PGen P P = PGo/SB 

Z X X = Xo 


Der Slack-Generator ist das Nport, an dem der netzweit gültige Spannungswert 

über den Parameter Usl vorgegeben wird. Dieser Parameter 

wird aus dem O-Parameter Uo vom Tauschformat übertragen (siehe Tabelle. 

6.11 und 6.12). 

E = { Θ1 − Θsl = 0,U1 −Usl = 0 } 

PLast: 

V = { U1,P1,Θ1 } , T = {};,P ={P } 

E ={ P1−P=0 } 

PGen: Beim DC-Lastfluss ist der Spannungsbetrag netzweit an allen Knoten 

gleich gross. Daher sind alle Generatoren, ausser dem einen Slack- 

Generator, der den netzweit einheitlichen Spannungsbetrag vorgibt, P-Generatoren. 

Das Verhalten ist gleich wie bei der PLast, hingegen wird der O-Parameter 

PGo des Tauschformats verwendet. 



Z (Impedanz): 

V = { U1,Θ1,U2,Θ2,P1,P2 }, 

P = { X }, T = {} 

E ={ P1−U1·U2·sin(Θ1 − Θ2)/X = 0, 

P1 + P2 = 0, U1 −U2 = 0 } 

Die Modellierung lässt sich weiter vereinfachen, wenn man voraussetzt, 

dass Θ1 − Θ2 klein ist. Dann kann in einem approximativen DC-Lastfluss 

die Längsimpedanz durch die Gleichungsmenge 

E = { P1 −U1 ·U2 · (Θ1 − Θ2)/X = 0, 

P1 + P2 = 0, U1 −U2 = 0 } 


modelliert werden. 

Die elektrischen Verbindungspunkte Bus1...Bus5 werden mit Hilfe von 

Summengebern modelliert. Man beachte, dass anstelle der kirchhoffschen 

Strombilanz pro Verbindungspunkt i eine Leistungsbilanz 

∑ 

m∈A 

Pim = 0 ( A : alle verbundenen Ntore) (6.4) 

formuliert wird. 

Elektrische Verbindungsstelle: 

S = { EinzeiligeSumme(Basisname = P), 

MehrzeiligeSumme(Basisname = U), 

MehrzeiligeSumme(Basisname = Θ) } 

6.6 Resultate 

Abschliessend werden einige Resultate aufgezeigt, die dokumentieren, dass 

der in dieser Arbeit vorgeschlagene Ansatz zu hoher Qualität und Produktivität 

sowie Erweiterbarkeit und Modularisierbarkeit beiträgt. 

6.6.1 Herstellung des Simulationsprogramms 

In Tabelle 6.13 wird dargestellt, wie sich der gesamte Code für die Simulation 

der einzelnen Fälle zusammensetzt. Davon ausgenommen ist 

jedoch der Code, der in den benutzten Bibliotheken (UMFPACK [29], 

HARWELL , LEDA [30] und Standard-Bibliotheken) verwendet wird. Die 


6.6. RESULTATE 147 

Fall Maple V C++ Kompilations- 

Spezifikation Adaption Ntore Summengeber Netz zeit in Sek. 

6.1 245 1033 1100 39 345 17.4 

6.2 238 1033 1017 39 337 17.0 

6.3 322 1130 1371 74 437 18.2 

• 637 1130 4748 74 705 41.7 

6.5 216 1033 534 37 315 15.6 

Tabelle 6.13: Anzahl Codezeilen und Kompilationszeit 

Code-Mengen werden in Anzahl Zeilen angegeben, wobei Leer- und reine 

Kommentarzeilen nicht gezählt werden. 

Fallweise neu zu schreiben ist der Code unter der Spalte “Spezifikation”. 

Dies ist aber nur ein Bruchteil der erzeugten, und ohne diesen Ansatz 

von Hand zu erstellenden Code-Menge. Dank diesem Ansatz lässt sich 

Entwicklungszeit einsparen und damit die Produktivität fördern. Der Umfang 

des Codes unter der Spalte “Adaption” hängt davon ab, wieviele Datensätze 

des Tauschformates für die einzelnen Fälle zu interpretieren sind. 

Der Quelltext für das “Framework” umfasst bei allen Fällen 1370 Zeilen. 

Der innerhalb der Domänen-Architektur erzeugte Code steht in den 

Spalten “Ntore”, “Summengeber” und “Netz”. Unter “Netz” ist die erzeugte 

Methode der Klasse “Netz” gemeint, welche das Netz aus dem 

Tauschformat [23] aufbaut. 

Der in Tabelle 6.13 mit • bezeichnete Fall umfasst neben der Modellierung 

des Austauschgebietes weitere Ntor-Typen, wie Π-Leitungsmodell 

und mehrere Transformator-Typen, die zur Modellierung der grösseren 

Netze von Tabelle 6.15 benutzt werden. 

Die Kompilationszeit 1 ist die Zeitspanne, die das System 2 zur Erzeugung 

eines ablauffähigen Programmes benötigt. Eine kleine Kompilationszeit 

begünstigt die Produktivität beim Entwickeln neuer Applikationen. 

6.6.2 CPU-Zeiten und Speicherbedarf 

Die Ausführungszeiten und der Speicherbedarf 3 sind für den Endbenutzer 

der Simulationsprogramme ausschlaggebend und in den Tabellen 6.14 und 

6.15 dargestellt. Auffällig ist die etwa konstante Zunahme der Rechenzeit 

mit der Netzgrösse, die durch die Anzahl der Kirchhoff-Knoten angegeben 

1UNIX-Werkzeug “timex”, Angabe der user-Zeit 

2SUN Ultra1 SPARC, 64 MByte RAM, Solaris 2.5 

3UNIX-Werkzeug “top”, Size-Angabe: 1K entspricht dem 1024-fachen Speicherbedarf des C++- 

Datentyps “char” 



wird. Diese Zunahme liegt im Bereich von 2 bis 5 msec pro Variable. Rund 

ein Drittel der Rechenzeit wird dabei für die Speicherallokation während 

des Netzaufbaus verbraucht. 

Die Fälle unter 6.1 bis 6.3 konvergieren in 4 Iterationen innerhalb einer 

Schranke von einem Tausendstel. Der DC-Lastfluss konvergiert bei exakter 

Modellierung der Zweigflüsse (Wirkleistungen) in 2 Iterationen, bei 

approximierter Modellierung in einer Iteration. 

Fall max. End- Anzahl CPU-Zeit Speicherbedarf 

Mismatch Variable in Sek. 

6.1 6.52355 · 10 −6 59 0.15 1808K 

6.2 1.74644 · 10 −5 59 0.14 1808K 

6.3 8.99662 · 10 −4 73 0.16 1824K 

6.5 5.2 · 10 −4 39 0.11 1786K 

Tabelle 6.14: Merkmale des Lösungsprozesses bei gleichem Netz 

Netz- max. End- Anzahl Anzahl CPU-Zeit Speichergrösse 

Mismatch Variable Nichtnullen in Sek. bedarf 

5 8.99662 · 10 −4 73 209 0.16 1824K 

14 1.40633 · 10 −6 290 1002 0.4 2088K 

57 7.9301 · 10 −8 1060 3690 1.22 2640K 

118 3.96988 · 10 −7 2599 9287 3.04 3704K 

2550 6.85541 · 10 −6 45605 162814 235.28 33M 

Tabelle 6.15: Merkmale des Lösungsprozesses bei gleicher Modellierung 

In Tabelle 6.15 werden CPU-Zeiten und Speicherbedarf bei verschiedenen 

Netzen aber gleicher Modellierung (kartesisch) dargestellt, wobei 

die Kompilation (g++) ohne Optimierung ausgeführt ist. Mit Optimierung 

vermindert sich die Ausführungszeit beim 2550-Knoten Netz um 16 

%. Andererseits erhöht sich dadurch die Kompilationszeit um 18 %. Die 

Ausführungszeit ist jedoch, verglichen mit einem “konventionellem” Lastflussprogramm, 

bei welchem der Code mit dem Werkzeug ADIFOR 4 erstellt 

wird, wesentlich langsamer. Dieses benötigt für das gleiche 2550- 

Knoten Netz nur 23 Sekunden, bei einem Speicherbedarf von 27 M. Da 

dieses Programm eine Knoten-Zweig-basierte Modellierung benutzt, braucht 

es, wie in Kapitel 3.1.5 dargestellt, wesentlich weniger Variable (5626) für 

4Werkzeug zur automatischen Differenzierung von Fortran 77 Programmcode, Version 2.0, Christian 

Bischof 


6.6. RESULTATE 149 

das gleiche Netz. Das Verhältnis zwischen der Rechenzeit und der Anzahl 

Variablen beträgt rund 4 msec pro Variable, und entspricht, wie in Tabelle 

6.15 ersichtlich, den beim Ntor-Prototypen gemessenen Zeiten. 

Ein Indiz für die Qualität des erzeugten Codes ist, dass die berechneten 

Werte trotz unterschiedlicher Modellierung (siehe Fälle 6.1 und 6.2) 

innerhalb der benutzten Kommastellen identisch sind. Diese Werte sind in 

Abbildung 6.1 eingerahmt eingetragen. Auch die im Fall 6.5 berechneten 

Näherungswerte der Spannungswinkel sind, wie in Tabelle 6.16 gezeigt, 

vergleichbar. 

Bus-Nr ΘDC−Last f luss ΘDC−Last f luss ΘAC−Last f luss 

exakt approx. kart./ polar 

1 0 0 0 

2 23.6 22.9 27.2 

3 49.7 48.1 57.3 

4 21.3 20.6 24.2 

5 46.2 44.7 53.9 

Tabelle 6.16: Vergleich Spannungswinkel 

6.6.3 Charakteristik der Software-Entwicklung 

Die Domänen-Architektur unterstützt die Modularisierbarkeit der Software-Entwicklung 

auf verschiedenen Stufen. Im Beispiel des DC- 

Lastflusses (siehe Kap. 6.5) geschieht dies auf der Stufe einzelner Ntor- 

Typen. Durch den Austausch einer Gleichung im Ntor-Typ “Z” werden 

die beiden Lastflussvarianten “DC-Exakt” und “DC-Approximativ” 

erzeugt. Eine weitere Stufe der Modularität bildet jeweils ein Satz von 

Summengeber- und Ntor-Typen. Die Bausteine eines Satzes zeichnen sich 

dadurch aus, dass sie die gleiche Schnittstelle haben. Diese wird durch eine 

netzweit spezifizierbare Menge von Variablen vorgegeben. In den Kapiteln 

6.1, 6.2 und 6.5 sind solche Sätze dargestellt, um die verschiedenen 

Lastflussvarianten “kartesisch”, “polar” und “DC” zu formulieren. 

Ein weiterer Qualitätsfaktor einer wiederverwendbaren Software ist 

gemäss Bertrand Meyer [18] deren einfache Erweiterbarkeit. In Kapitel 6.3 

wird der Lastfluss erweitert, um eine Wirkleistungsbilanz in Austauschgebieten 

hinzuzufügen. Die dazu notwendigen Änderungen beschränken 

sich auf die Spezifikations- und Adaptionsebene innerhalb der Domänen- 

Architektur. 



In der Adaptionsebene ist dies, wie in Tabelle 6.13 ersichtlich, durch 

97 zusätzliche Codezeilen realisiert. Diese erweitern den Dienst Netzaufbau, 

damit die Datensätze für Austauschgebiete und Verbindungsleitungen 

(siehe Anhang B) interpretiert werden können. Die zugehörige Spezifikationserweiterung 

ist in den Tabellen 6.9 und 6.10 angegeben. In den Ntor- 

Spezifikationen werden lediglich die zu bilanzierenden Wirkleistungsvariablen 

hinzugefügt. 

Dank den Festlegungen der Domänen-Architektur werden die Erweiterungen 

in den Elementen “Spezifikation” und “Adaption” konzentriert und 

damit verhindert, dass eine Kettenreaktion von Änderungen im ganzen Simulationsprogramm 

zu bewältigen ist. 


Kapitel 7 

Schlussbetrachtung 

7.1 Zusammenfassung 

Viele Applikationen im Bereich der elektrischen Energieübertragung führen 

auf ein System von simultanen, nichtlinearen Gleichungen 

g(x,p)=0(x: Unbekannte, p: Parameter), die nach den Unbekannten x 

aufzulösen sind. Diese Gleichungen beschreiben das nichtlineare Verhalten 

miteinander verbundener Entitäten. 

Dies ist kein neues Problem. Der Beitrag der vorliegenden Arbeit besteht 

jedoch darin, für diese Klasse von Problemen mit Mitteln des Software- 

Engineerings und neuen Erkenntnissen aus der Netzmodellierung eine wiederverwendbare 

Lösung zu beschreiben. Dazu sind verschiedene Ansätze 

in einem Prototypen neu kombiniert worden. Der Prototyp besteht aus 

einer Software-Komponente (ein objekt-orientiertes Framework) und einer 

dazu passenden Domänen-Architektur. Innerhalb dieser Domänen- 

Architektur erfolgt die Anpassung des Frameworks, das die grundlegenden 

Dienste erbringt, die in Netz-Simulationen vorkommen, wie Netzaufbau, 

Netzberechnung (d.h. das Lösen von nicht-linearen Gleichungen) und 

Darstellung von Resultaten. Das Framework basiert auf einem Domänenmodell, 

dass das Verhalten eines Netzes ausschliesslich durch Instanzen 

zweier generischer Baustein-Typen, Ntor und Summengeber, modelliert. 

Das Ntor ist die Entität, mit der physikalische Betriebsmittel und auch 

Fehlerbedingungen modelliert wird. Das Ntor stellt einen endlichen Automaten 

mit einem Verhalten BN σ(Vσ,Pσ,E σ,Tσ) für jeden Zustand σ dar. 

Die Menge E σ enthält alle Gleichungen, die mit Hilfe der Variablen Vσ 

und den Parametern Pσ gebildet werden. Die Menge Tσ spezifiziert den 

endlichen Automaten. 

Die Summengeber greifen auf Variable in den Ntoren zu, und for- 

151 


152 KAPITEL 7. SCHLUSSBETRACHTUNG 

mulieren damit weitere Gleichungen auszudrücken. Summengeber sind 

Behälter für eine beliebige Anzahl von elementaren Summentypen. Dies 

können einzeilige und mehrzeilige Summen sein. Das Domänen-Modell 

ist als ein System von gekoppelten Klassen implementiert worden. Diese 

Klassen bilden zusammen das objekt-orientierte Framework. Das Framework 

enthält Klassen und Methoden, die im Design zwar angelegt, jedoch 

für einen bestimmen Anwendungsfall noch zu konkretisieren sind. 

Diese Adaption lässt sich nicht innerhalb des Frameworks ausführen. 

An dieser Stelle kommt ein symbolisches Rechenprogramm (Maple V) 

zum Einsatz, um aus einer anwendungsfreundlichen Hochsprachenspezifikation 

zuverlässig den korrekten Quelltext der zu konkretisierenden Klassen 

zu erzeugen. 

Alle diese Elemente, wie Framework, Spezifikation und Adaption der 

generischen Teile des Frameworks werden innerhalb der Domänen-Architektur 

koordiniert. 

Der Prototyp, der alle Teile der Domänen-Architektur umfasst und implementiert, 

wurde in verschiedenen Lastflussrechnungen eingesetzt. Ferner 

ist mit ihm auch der lineare Spezialfall der Kurzschlussrechnung modelliert 

worden. Der Prototyp wurde auch anhand grösserer Netze mit bis 

zu 2550 elektrischen Verbindungsstellen überprüft. 

Ein Klient kann mit diesem Prototypen Quelltext erzeugen, den er in 

seiner Simulations-Applikation einbinden kann. Dies geschieht in folgenden, 

durch die Domänen-Architektur festgelegten Schritten: 

1. Der Klient spezifiziert die variablen Teile der Dienste Netzaufbau, 

Netzberechnung und Resultatanzeige. 

2. Der Klient verwendet oder spezifiziert eine geeignete Adaption der 

generischen Teile des Frameworks, um die variablen Teile der Dienste 

in der Software-Komponente einzubauen. 

3. Der Klient erzeugt (automatisch) eine Instanz der Software-Komponente. 

Ohne diesen Prototypen hätte der Klient beim Aufbau seiner Applikation 

einige Entscheidungen selber zu treffen. Diese betreffen erstens die 

Modellierung des Netzes. Der verbreitete und bezüglich der Computer- 

Ressourcen effektive Knoten-Zweig Ansatz ist für viele typische Lastflussfälle 

geeignet. Er ist aber nicht allgemein genug, um das breite Gebiet 

von praktisch vorkommenden Betriebsmitteln zu modellieren. Der 


7.2. ERGEBNISSE 153 

im Domänenmodell eingesetzte Ntor-Ansatz hingegen hat sich als sehr 

flexibel erwiesen. Zweitens müsste ein Klient z.B. bei Verwendung einer 

Bibliothek von allgemeinen Software-Funktionen (Prozeduren oder 

feinkörnige Klassen) erneut entscheiden, welche Bibliotheks-Komponenten 

er nehmen soll und wie er die Kommunikation zwischen ihnen zu organisieren 

hätte. Dank dem Einsatz des Frameworks kann der Klient jedoch 

bereits eingebaute und komplexe Beziehungen zwischen einer Menge von 

kooperierenden Objekten wiederverwenden, ohne die inneren Einzelheiten 

dieser Beziehungen kennen zu müssen. Drittens müsste der Klient 

selber einen Rahmen finden, um den Übergang von einer geeigneten und 

anwenderfreundlichen Spezifikation seines Problems zu einem effizienten 

Simulationsprogramm zu organisieren. Die Domänen-Architektur bietet 

einen solchen koordinierenden Rahmen an. Dieser Rahmen ist eine Voraussetzung 

für die Wiederverwendbarkeit der darin benutzten Elemente. 

In Übereinstimmung mit [34] lassen sich die Begrenzungen des in dieser 

Arbeit betrachteten Ansatzes wie folgt zusammenfassen: “Perhaps the 

key limiting factor in this approach is that the specification of the various 

grammars implies a certain closed-endedness of the space of possibilities. 

Even when the grammars are made extensible along some of the obvious 

dimensions (data types, control types, and so on), there remain integral 

features of the grammar that constrain what the system can do. In a sense, 

the approach’s ability to capture high-level semantics is a double-edged 

sword: It provides leverage but takes away choice.” 

7.2 Ergebnisse 

Der in der vorliegenden Arbeit dargestellte Ansatz interessiert direkt oder 

indirekt verschiedene Personengruppen. Aus deren Sicht lassen sich abschliessend 

folgende Punkte zusammenfassen: 

1. Klient: 

• Qualität: der Einsatz eines symbolischen Rechensystems innerhalb 

eines festgelegten Ablaufs sichert die Erzeugung korrekter 

Terme für den Simulationsalgorithmus. 

• Produktivität: Bei der Herstellung von Simulationsprogrammen 

ist nur ein Bruchteil der Codemenge neu zu schreiben. Damit 

lässt sich Entwicklungszeit einsparen und die Produktivität för- 


154 KAPITEL 7. SCHLUSSBETRACHTUNG 

dern. Die verhältnismässig kleine Kompilationszeit ermöglicht 

kurze Entwicklungszyklen. 

• Modularisierbarkeit: Die Domänen-Architektur unterstützt die 

Modularisierbarkeit der Software-Entwicklung auf verschiedenen 

Stufen. 

• Erweiterbarkeit: Dank den Festlegungen der Domänen-Architektur 

werden die Erweiterungen in den Elementen “Spezifikation” 

und “Adaption” konzentriert und damit verhindert, dass der Klient 

eine Kettenreaktion von Änderungen im ganzen Simulationsprogramm 

zu bewältigen hat. 

• Zuverlässigkeit: Anstelle fehlerträchtiger Handcodierung erzeugt 

ein symbolisches Rechenprogramm (Maple V) aus einer anwendungsfreundlichen 

Hochsprachen-Spezifikation den korrekten 

Quelltext für die zu konkretisierenden Teile des Frameworks. 

2. Für den Endbenutzer, der nicht gleichzeitig Klient sein muss, ergeben 

sich die folgenden Punkte: 

• Die Rechenzeit bei der Simulation grosser Netze ist verhältnismässig 

hoch verglichen mit traditionellem, funktionalem Handkodieren. 

• Die Wartezeit, bis Modelle erweitert oder neue Ntor-Typen verfügbar 

sind, ist tendenziell kleiner, da die Entwicklung dank dem 

vorgestellten Ansatz rascher vorangeht. 

• Die klaren Spezifikationsmöglichkeiten vereinfachen die Kommunikation 

zwischen den beteiligten Personengruppen. 

3. Framework-Entwickler: das Domänenmodell, die Domänen-Architektur 

sowie das Framework stellen eine Basis für das Domänen-Engineering 

dar. Es ist ein Ausgangspunkt für weitere Entwicklungen, 

wie z.B. die Optimierung oder die Simulation des transienten Verhaltens. 


Anhang A 

Umformung der Ntor-Gleichungen 

Dieses Kapitel zeigt, wie sich die Ntor-Gleichungen (siehe Kapitel 3) in 

die Form des bekannten Knotenpotentialverfahrens abbilden lassen. 

A.1 Modellierung der Ntore 

Für die Betrachtungen dieses Kapitels wird die Charakteristik der Ntore 

gegenüber der Darstellung in Kapitel 3 wie folgt eingeschränkt: 

• g(x,p) ist linear, 

• alle N Anschlüsse sind elektrische Anschlüsse und 

• die Ntore haben keine weiteren, innere Variablen. 

Es wird eine stationäre Netzberechnung bei Wechselstrom betrachtet. Pro 

Anschluss gibt es daher je eine komplexe Spannungs- und Stromvariable. 

Das Gleichungssystemg [i] (x [i] ,p [i] )=0 eines Ntors i wird in diesem Kapitel 

in der Form 

MUiUNtori +MIiINtori = bi 

(A.1) 

dargestellt. 

Darin werden die Zusammenhänge zwischen den an allen Anschlüssen 

anliegenden Spannungen UNtori des Ntors i und den in diese Anschlüsse 

hineinfliessenden Ströme INtori in einer neuen Form dargestellt. Dazu werden 

die Variablen x [i] in die beiden Vektoren UNtori und INtori aufgeteilt, 

welche je die Dimension N haben. Die einzelnen Elemente der Vektoren 

und INtori stellen die Spannungen und die (in das N-Tor hineinge- 

UNtori 

richteten) Ströme der N Anschlüsse des Ntors i dar. 

Die Parameter p [i] jedes Ntor-Typs i werden in der neuen Form in den 

Matrizen MUi und MIi und den Elementen des Vektors bi angeordnet. 

155 


156 ANHANG A. UMFORMUNG DER NTOR-GLEICHUNGEN 

Ntor Anschluss 

m 

U m 

Kirchhoff- 

Knoten k 


I km 

Abbildung A.1: Kirchhoff-Knoten und Ntor 

MUi und MIi stellen daher numerisch gegebene, komplexe Matrizen der 

Dimension NxN dar. 

A.2 Kirchhoff-Knoten 

Für stationäre Vorgänge und Wechselstrom lassen sich am Kirchhoff-Knoten 

(siehe Abbildung A.1) bekanntlich folgende beiden Gesetze formulieren: 

1. Da die Kirchhoff-Knoten gemäss Modellierungsregel 7 auf S. 45 keine 

Verbindung gegen Erde aufweisen, muss die Summe aller (gerichteter) 

Ströme an jedem Kirchhoff-Knoten gleich Null sein. Formell 

bedeutet dies, bei Annahme, dass die Ströme immer aus den Kirchhoff-Knoten 

herauskommen: 

∑ Ikm = 0 (k: alle Kirchhoff-Knoten) (A.2) 

m∈k 

wobei sich in (A.2) und (A.3) der Index m auf alle zum Kirchhoff-- 

Knoten k verbundenen Ntor-Anschlüsse m bezieht. Der Index m ist 

netzweit eindeutig. Er setzt sich daher gemäss Modellierungsregel 

4 auf S. 45 aus der Ntore-Identifikation i und der lokalen Anschlussnummer 

anr zusammen. 

2. Da die Kirchhoff-Knoten gemäss Modellierungsregel 7 auf S. 45 impedanzlos 

mit Ntor-Anschlüssen verbunden sind, entspricht die (komplexe) 

Knotenspannung jedes Kirchhoff-Knotens genau der komplexen 

Spannung aller Ntor-Anschlüsse, die mit diesem Kirchhoff-Knoten 

verbunden sind: 

U k = U m ∀m ∈ k(k: alle Kirchhoff-Knoten) (A.3) 

U k

A.3. DARSTELLUNG ALLER GLEICHUNGEN EINES NETZES 157 

Das Kirchhoff’sche Gesetz (A.3) kann matriziell wie folgt formuliert 

werden: 

C ·UKirchho f f −UNtor = 0 (A.4) 

wobei UNtor der Vektor der komplexen Spannungen der Anschlüsse aller 

Ntore darstellt. Der Vektor UKirchof f repräsentiert die komplexen Knotenspannungen 

aller Kirchhoff-Knoten. 

Die Matrix C ist eine Inzidenzmatrix, deren Elemente Ckm wie folgt ge- 

bildet werden: 

Ckm = 

⎧ 

⎨ 

⎩ 

1:der m-te Ntor-Anschluss ist mit dem 

Kirchhoff-Knoten k verbunden 

0:sonst 

Die Matrix C hat die Dimension Anzahl Anschlüsse aller Ntore · Anzahl 

Kirchhoff-Knoten. Vertikal sind die Anschlussnummern m aller Ntore in 

der Reihenfolge R aufgezählt und horizontal die Nummern aller Kirchhoff- 

Knoten k. 

Konvention 1 Die Reihenfolge der Variablen in INtor und UNtor wird durch 

die Reihenfolge R der Anschlüsse in der C-Matrix festgelegt. 

Das Kirchhoff’sche Gesetz (A.2) kann mit derselben Matrix C formuliert 

werden: 

C T · INtor −IKirchho f f = 0 (A.5) 

Da aber IKirchho f f = 0 gilt, folgt noch einfacher: 

C T · INtor = 0 (A.6) 

A.3 Darstellung aller Gleichungen eines Netzes 

Folgend den Konvention (1) für INtor und UNtor können alle Ntor-Gleichungen 

zusammen in Matrixform geschrieben werden: 

diag(MUi )UNtor +diag(MIi )INtor = b (A.7) 

wobei diag(MUi ) die blockdiagonale Form aller einzelner NxN - Matrizen 

MUi , diag(MIi ) die blockdiagonale Form aller einzelner NxN - Matrizen 

MIi und der Vektor b die Blockvektorform aller einzelner Vektoren bi aller 

N-Tore darstellt. 


158 ANHANG A. UMFORMUNG DER NTOR-GLEICHUNGEN 

Man beachte, dass die Reihenfolge der Plazierung der Teilmatrizen MUi , 

MIi und der Elemente bi nicht mehr frei ist, sobald die Elemente der Vektoren 

UNtor und INtor aufgesetzt sind. Dieser letzte Schritt wird durch das 

Aufstellen der Matrix C definiert. 

Es gilt (A.4), womit die Variablen UNtor immer eliminiert werden können. 

Es entsteht das Gleichungssystem: 

 

diag(MIi ) diag(MUi )·C 

CT 0 

 

· 


INtor 

UKirchho f f 

 

= 

b 

0 

 

(A.8) 

Im allgemeinen können nun keine weiteren Eliminationsschritte von immer 

gleichartigen Blöcken von Variablen durchgeführt werden, da sowohl 

die Matrix diag(MUi ) wie auch diag(MIi ) singulär sein können. 

Unter der Annahme, dass diag(MIi ) nicht singulär ist, können die Variablen 

INtor aus (A.8) eliminiert werden: Es folgt aus (A.8): 

INtor = diag(MIi )−1 · b−diag(MUi )C·UKirchho 

 

f f (A.9) 

Dieser Ausdruck in die zweite Zeile von (A.8) eingesetzt ergibt: 

C T diag(MIi )−1 diag(MUi )C·UKirchho f f = C T diag(MIi )−1 b (A.10) 

Durch Setzen von 

und 

Y = C T diag(MIi )−1diag(MUi )C (A.11) 

I o = C T diag(MIi )−1 b (A.12) 

und 

U = UKirchho f f 

(A.13) 

ist die normalerweise in der Theorie verwendete Darstellung mit Hilfe der 

Knotenadmittanzmatrix 

Y ·U = I 0 

(A.14) 

hergeleitet worden. Y stellt die Knotenpunktsadmittanzmatrix dar, U den 

Vektor aller Knotenspannungen (genauer: Kirchhoff-Knotenspannungen) 

und I 0 den Vektor aller gegebener (Kirchhoff-) Knotenströme.

Anhang B 

IEEE Common Data Format 

Dieses Kapitel stellt einen Ausschnitt aus der Beschreibung des 

“IEEE Common Data Format for the Exchange of Solved Load Flow Data”[23] 

dar. 

Die Datenfelder sind wie folgt gekennzeichnet: 

Abkürzung Bedeutung 

A Alphanumerisch (ohne Sonderzeichen) 

I Integer (Ganzzahlig) 

• Obligatorisch 

F Gleitkomma 

Tabelle B.1: Abkürzungen 

Datensatz Spalte Beschreibung 

2- 9 Datum, im Format DD/MM/YY mit führenden 

Nullen. Falls kein Datum angegeben wird, muss 

0b/0b/0b eingetragen werden, wobei b ein Leerzeichen 

ist. 

netzweite 11-30 Name des Urhebers (A) 

Daten 32-37 Bezugsscheinleistung MVA (F•) 

39-42 Jahreszahl (I) 

44 Jahreszeit (S - Sommer, W - Winter) 

46-73 Identifikation des Falles(A) 

Tabelle B.2: Datenblock mit netzweitem Datensatz• 

159 


160 ANHANG B. IEEE COMMON DATA FORMAT 


Start 1-16 BUS DATA FOLLOWS • 

Bus 1- 4 Knotennummer (I) • 

6-17 Name, links bündig (A) 

19-20 Nummer des Austauschgebietes = 0 (I) • 

21-23 Nummer des Gebietes für Verlustbilanzierung (I) 

25-26 Knotentyp (I) • 

0 - Ungeregelt (Last, PQ) 

1 - PQ-Generator mit Spannungsgrenzen 

2 - PV-Generator mit Blindleistungsgrenzen 

3 - Slack-Generator, pro Netz einmal vorhanden 

28-33 resultierender Spannungsbetrag (p.u.) (F) • 

34-40 resultierender Spannungswinkel Grad (F) • 

41-49 Last (MW) (F) • 

50-59 Last (MVAR) (F) • 

60-67 Erzeugung (MW) (F) • 

68-75 Erzeugung (MVAR) (F) • 

77-83 Bezugsspannung KV (F) 

85-90 Spannungssollwert (p.u.) des geregelten Knotens 

(F) 

91-98 Maximale Blindleistung (MVAR) oder Spannungsgrenze 

(p.u.) (F) 

99-106 Minimale Blindleistung (MVAR) oder Spannungsgrenze 

(p.u.) (F) 

107-114 Shunt Leitwert G (p.u.) (F) • 

115-122 Shunt Suszeptanz B (p.u.) (F) • 

124-127 Nummer des geregelten Knotens 

Ende 1- 4 -999 

Tabelle B.3: Datenblock mit Bus-Datensätzen• 


Start 1-16 BRANCHDATAFOLLOWS• 

Zweig 1- 4 Knotennummer auf der “Tap”-Seite. Gilt für 

Transformatoren und Phasenschieber (I) • 

6- 9 Knotennummer auf der “Z”-Seite. Gilt für Transformatoren 

und Phasenschieber (I) • 

11-12 Nummer des Austauschgebietes (I) 

Fortsetzung auf folgender Seite 


Fortsetzung 


13-14 Gebietsnummer für Verlustbilanzierung (I) 

17 Nummer des Stromkreises (I) • 

19 Zweigtyp (I) • 

0-Übertragungsleitung 

1 - Transformator mit konstantem Übersetzungsverhältnis t 

2 - Transformator mit variablem Übersetzungsverhältnis t für 

Spannungsregelung 

3 - Transformator mit variablem Übersetzungsverhältnis t für 

Blindleistungsregelung 

4 - Phasenschieber mit variablem Phasenwinkel Φt für Wirklei- 

stungsregelung 

20-29 Zweigwiderstand R, p.u. (F) • 

30-40 Zweigreaktanz X, p.u. R + j · X = 0 (F) • 

41-50 Gesamter Querleitweit B p.u. (F) • 

69-72 Nummer des gesteuerten Knotens 

74 Anschlusseite des gesteuerten Knotens (I) 

0 - indifferent 

1 - gesteuerter Knoten auf der “Tap”-Seite 

2 - gesteuerter Knoten auf der “Z”-Seite 

77-82 maximales Übersetzungsverhältnis tmax eines 

Transformators (F) 

84-90 maximaler Phasenwinkel Φtmax 


161 

eines Phasen- 

schiebers (F) 

91-97 Minimales Übersetungsverhältnis tmin oder minimaler 

Phasenwinkel Φtmin (F) 

98-104 Maximales Übersetungsverhältnis tmin oder maximaler 

Phasenwinkel Φtmin (F) 

113-119 Minimale Spannung (p.u.), Blind- (MVAR) oder 

Wirkleistung (MW)(F) 

120-126 Maximale Spannung (p.u.), Blind- (MVAR) oder 

Wirkleistung (MW)(F) 

Ende 1- 4 -999 

Tabelle B.4: Datenblock mit Zweig-Datensätzen•

162 ANHANG B. IEEE COMMON DATA FORMAT 


Start 1-16 INTERCHANGE DATA FOLLOWS 

Austausch- 1- 2 Nummer des Austauschgebietes = 0 (I) • 

gebiet 4- 7 Nummer des Slack-Knotens des Austauschgebietes 

(I) • 

21-28 Exportierte Wirkleistung aus dem Austauschgebiet 

(MW) (F) • 

30-35 Toleranz der exportierten Blindleistung (MW) (F) 

• 

46-75 Name des Austauschgebietes (A) 

Ende 1- 2 -9 

Tabelle B.5: Datenblock mit Datensätzen für Austauschgebiete• 


Start 1-16 TIE LINES FOLLOW 

Verbindungs- 1- 4 Knotennummer bei der “Meter”-Anschlussseite (I) 

leitung 7-8 Nummer des Austauschgebietes bei der “Meter”- 

Anschlussseite (I) 

11-14 Knotennummer bei der “Nonmeter”-Anschlussseite (I) 

17-18 Nummer des Austauschgebietes bei der “Nonmeter”- 

Anschlussseite (I) 

21 Nummer des Stromkreises 

Ende 1- 3 -999 

Tabelle B.6: Datenblock mit Datensätzen für Verbindungsleitungen 


Anhang C 

Stichwortverzeichnis 

Anschluss bildet die Verbindung zwischen Ntor und Summengeber. Jeder 

Anschluss steht dabei für eine gemeinsame Variable, die sowohl 

im Ntor als auch im verbundenen Summengeber in den Gleichungen 

auftritt. Pro gemeinsame Variable (immer reell) ist ein Anschluss zu 

instantiieren. Ein elektrischer Anschluss verknüpft immer Variable, 

die in Kirchhoff-Gleichungen verwendet werden, um die Topologie 

eines Netzes zu formulieren. Je nach Anwendungsfall sind dies unterschiedlich 

viele Anschlüsse. 

API Application Programming Interface. Hier ist die Programmierschnittstelle 

des Frameworks gemeint. Das Framework hat zwei API’s. 

Das passive API ist für die Adaption des Frameworks vorgesehen. 

Hier füllt ein Klient applikationsspezifischen (erzeugten) Code hinein. 

Dieser wird vom Framework aufgerufen. Das aktive API sind 

die Methoden des Frameworks, die der Klient (aktiv) aufrufen kann. 

Applikation Eine Applikation ist das Programm eines Klienten, das ein 

adaptiertes Framework verwendet. Der Code-Anteil des adaptierten 

Frameworks am Gesamtcode der Applikation kann sich dabei in weiten 

Grenzen bewegen. Wie in Abbildung C.1 ersichtlich, ist der Adaptionsbereich 

des Frameworks im allgemeinen nicht identisch mit 

dem übrigen Code-Anteil ausserhalb des Frameworks. Das in dieser 

Arbeit beschriebene Framework deckt eine Domäne ab und ist 

nicht als Applikations-Framework konzipiert. Diese Definition unterstreicht 

den evolutionären Charakter der Framework-Ausreifung. 

Tendenziell wird der Framework-Codeanteil ansteigen, nie aber alles 

ausmachen, da in jeder Applikation etwas Neues steckt, das vom 

Framework nicht vorwegnehmbar ist. 

163 


164 ANHANG C. STICHWORTVERZEICHNIS 

Gesamter Applikation-Code 

Adaptiertes 

Framework 

Framework 

Abbildung C.1: Applikation und Framework 

Aktives API: Klient ruft auf 

Passives API: Framework ruft 

Code des Klienten auf 

Codemenge ausserhalb 

Framework 

Codemenge des Frameworks 

Σ Summengeber Ntor 

Abbildung C.2: Grundlegende Symbole dieser Arbeit 

Bausteine Sammelbegriff für alle vom Klienten definierbaren Ntore und 

Summengeber. Auf der Ebene des Frameworks ist jedem Baustein- 

Typ eine Klasse zugeordnet. Abbildung C.2 zeigt die beiden generischen 

Baustein-Symbole, die in dieser Arbeit festgelegt sind, um 

den Baustein-Bezug in verschiedenen Zusammenhängen zu verdeutlichen. 

Dienst Dies sind die verschiedenen Leistungen, welche das Framework 

in Zusammenarbeit mit der Domänen-Architektur erbringt. Dies 

sind Netzaufbau, Netzberechnung und Resultatanzeige. Der Dienst 

ist eine Sicht auf die Domänen-Architektur. Pro Dienst ordnet die 

Architektur je ein Element Spezifikation, Adaption und passives 

Framework-API zu. 

Domäne Das NIST [15] definiert es als “a distinct functional area that 

can be supported by a class of Software Systems with similar Requirements 

and capabilities. A Domain may exist before there are 

Software Systems to support it”. 

Domänenmodell Das Modell, das aus Anforderungen von typischen, 

nicht-optimierenden Lastfluss-Rechnungen gewonnen wurde. 

Elementarsumme Sammelbegriff für die beiden Summentypen Einzeilige- 

und Mehrzeilige-Summe. 


Entität Sind hier die unterscheidbaren Einheiten des Domänen-Modells. 

Die Klassen sind ihre Implementation in der Welt des Frameworks. 

Framework Eine Menge von kooperierender Klassen, welche die abstrakte 

Gestalt von Lösungen innerhalb einer Familie von verwandten Problemen 

verkörpern. Gamma [10] sieht es als konzeptionelle Erweiterung 

der abstrakten Basisklasse. Es bedarf noch der Anpassung an 

die konkrete Aufgabenstellung. Dies geschieht durch Ableitung neuer 

Klassen. Dadurch gibt es keine Codeänderung am Grundverhalten 

des Frameworks. Applikationsspezifische Ergänzungen erfolgen 

durch Überschreiben von Methoden. Der globale Kontrollfluss ist bei 

einem Applikations-Framework bereits in den Framework-Klassen 

vorgegeben. 

Funktion Spezifizierbare Fehlerfunktiong(x,p)zwischen Variablenx und 

Parametern p, aus der durch Nullsetzen das nichtlineare Gleichungssystem 

g(x,p)=0 gebildet wird. Funktionen werden im betrachteten 

Domänenmodell ausschliesslich durch Bausteine ins Gesamtsystem 

eingebracht. Eine Funktion muss für eine Newton-Raphson- 

Berechnung einmal nach allen Variablen ableitbar sein. 

Kirchhoff-Knoten Ein spezieller Summengeber. Impedanzlose Zusammenschaltstelle 

zwischen Ntoren. Dieser Summengeber formuliert 

Summen im Sinne von Kirchhoffs Gesetzen. Der Kirchhoff-Knoten 

liefert die topologische Information ins Gleichungssystem (Inzidenzmatrix). 

Klient Der Klient ist ein Software-Entwickler, der für seine Applikation 

ein adaptiertes Framework verwendet. Das Framework kann er innerhalb 

der Domänen-Architektur adaptieren. In diesem Rahmen kann 

er Spezifikationen und Adaptionen ähnlicher Anforderungen wiederverwenden. 

Netz Als grundlegender Modellierungsansatz ist das Netz eine beliebige 

Menge von frei definierbaren Ntoren und Summengebern, die über 

gemeinsame Variable miteinander verbunden sind. 

Ntor Applikationsspezifischer Baustein mit Anschlüssen. Typischerweise 

identifiziert ein Klient aus der Welt der Elektrotechnik damit Betriebsmittel 

wie Generator, Leitung, Transformatoren usw. Vom Kli- 


165

166 ANHANG C. STICHWORTVERZEICHNIS 

enten ist pro Ntor ein eindeutiger Typ-Name und ein Verhalten zu 

definieren. 

Parameter Dies sind die bekannten, innerhalb eines Newton-Raphson 

Prozesses konstanten Werte p. Parameter lassen sich den Bausteinen 

zuordnen. Namen und Anzahl sind frei wählbar. Die Namen müssen 

zusammen mit den Variablennamen innerhalb eines Bausteins eindeutig 

spezifiziert sein. Alle Parameter sind vom C++-Typ “Double”. 

Summengeber Summengeber formulieren und instantiieren Summenbeziehungen 

zwischen Basisnamen von Variablen. Der Klient spezifiziert 

Summengeber für seine Applikation. Dies geschieht auf der 

Basis der parametrierbaren Elementarsummen. 

Variable Dies sind die Unbekannten x, die innerhalb eines Newton- 

Raphson Prozesses berechnet werden. Alle Variablen sind vom gleichen 

Typ Double. Menge und Namen werden vom Klienten spezifiziert. 

Der Klient ist dafür verantwortlich, dass er die Variablen 

eindeutig indiziert, und die Funktionen entsprechend formuliert. Die 

Variablen lassen sich bei der Instantiierung des Ntors beliebig initialisieren. 

Verhalten Damit sind spezielle Spezifikationsdaten eines Bausteins gemeint. 

Aus diesen Daten lässt sich der adaptierbare Teil der Bausteine 

bilden, der zum Aufbau des gesamten Gleichungssystems beiträgt. 

Dies ist beim Baustein Ntor BN σ(Vσ,Pσ,E σ,Tσ) in jedem Zustand 

σ und BS(A ,E ) für den Baustein Summengeber. 


Literaturverzeichnis 

[1] R. Rada. Software Reuse. Intellect Ltd., Oxford, England, 1995. 

[2] A. F. Neyer et. al. Object-oriented Programming For Flexible Software: 

Example Of A Load Flow. IEEE Transactions on Power Systems, 

5(3):689–695, August 1990. 

[3] M. Foley et al. An Object Based Graphical User Interface for Power 

Systems. IEEE Transactions on Power Systems, 8(1):97–104, February 

1993. 

[4] B. Hakavik und A. T. Holen. Power System Modelling And Sparse 

Matrix Operations Using Object-Oriented Programming. IEEE Transactions 

on Power Systems, 9(2):1045–1051, May 1994. 

[5] M. Foley und A. Bose. Object-Oriented On-Line Network Analysis. 

IEEE Transactions on Power Systems, 10(1):125–130, February 

1995. 

[6] E. Z. Zhou. Object-oriented Programming, C++ and Power System 

Simulation. IEEE Transactions on Power Systems, 11(1):206–215, 

February 1996. 

[7] F. L. Alvarado und Y. Liu. General Purpose Symbolic Simulation 

Tools for Electric Networks. IEEE Transactions on Power Systems, 

3(2):689–697, May 1988. 

[8] R. Bacher. Computer Aided Power Flow Software Engineering And 

Code Generation. IEEE Transactions on Power Systems, 11(1):490– 

496, Feb. 1996. 

[9] R. Bacher. Automatic Generation of Optimisation Code Based on 

Symbolic Non-Linear Domain Formulation. International Symposium 

on Symbolic and Algebraic Computation (ACM conference), Zurich, 

Switzerland, pages 283–291, July, 1996. 

167 


168 LITERATURVERZEICHNIS 

[10] E. Gamma. Objektorientierte Software-Entwicklung am Beispiel von 

ET++. Springer-Verlag, Berlin Heidelberg, 1992. 

[11] C. W. Sanders. Object-Oriented Development of EMS Maintenance 

and Documentation Tools. IEEE Power Industry Computer Application 

Conference, pages 488–493, 1995. 

[12] R. R. Macala et al. Managing Domain-Specific, Product-Line Development. 

IEEE Software, pages 57–66, May 1996. 

[13] K. Kueffmann. Software-Wiederverwendung. Vieweg, Braunschweig/Wiesbaden, 

1994. 

[14] P. Bosshart und R. Bacher. A Domain Architecture For Solving 

Simultaneous Nonlinear Network Equations. IEEE Power Industry 

Computer Application Conference, pages 142–148, 1997. 

[15] S. Katz et al. Glossary of Software Reuse Terms. National Institute of 

Standards and Technology, Gaithersburg, 1994. 

[16] D. Tsichritzis et al. Beyond Objects: Objects. International Journal 

of Intelligent and Cooperative Information Systems (IJICIS), 1(1):43– 

60, March 1992. 

[17] Biggerstaff T. und Perlis A. Software Reusability, Volume 1. ACM 

Press, 1989. 

[18] B. Meyer. Object-Oriented Software Construction. Prentice Hall, 

Englewood-Cliffs,New Jersey, 1988. 

[19] J. M. Neighbors. Draco: A Method For Engineering Reusable Software 

Systems. In: Biggerstaff, T., Perlis, A. (Ed.): Software Reusability 

Volume I - Concepts and Models. ACM-Press, New York, 1989. 

[20] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorenson. 

Object-Oriented Modeling and Design. Prentice-Hall, Inc., New Jersey, 

1991. 

[21] R. E. Johnson und B. Foote. Designing Reusable Classes. The Journal 

of Object-Oriented Programming, 1(2):22–35, 1988. 

[22] S. Cotter und M. Potel. Inside Taligent Technology. Addison-Wesley, 

New York, 1995. 


LITERATURVERZEICHNIS 169 

[23] H. E. Pierce et. al. Common Format For Exchange Of Solved Load 

Flow Data. IEEE Transactions on Power Apparatus and Systems, 

pages 1916–1925, 1973. 

[24] K. Werlen. A Node-oriented Solution Strategy In Power System Analysis. 

PhD thesis, ETH 10181, 1993. 

[25] K. Imhof. Power System Modelling and Analysis Bases On Graph 

Theory. PhD thesis, ETH 7923, 1985. 

[26] K. Imhof et al. Modelling of Tap-Changer Transformators in an Energy 

Management System. IEEE Power Industry Computer Application 

Conference, pages 378–384, 1995. 

[27] B. Stroustrup. The C++ Programming Language, 2nd Edition. 

Addison-Wesley, New York, 1991. 

[28] Satir G. und Brown D. C++: The Core Language. O’Reilly Associates, 

Inc., 1995. 

[29] Timothy A. Davis und Iain S. Duff. Umfpack version 2.0: 

Unsymmetric-pattern multifrontal package. Sept 1995. Program 

package at: http://www.cis.ufl.edu/˜davis. 

[30] S. Naeher. The LEDA User Manual, Version 3.1. Max-Plank-Institute 

für Informatik, 66123 Saarbrücken, Germany, 1995. 

[31] B. Char et al. Maple V: Library Reference Manual. Springer-Verlag, 

1992. 

[32] M. B. Monagan et al. Maple V Programming Guide. Springer, New 

York, 1996. 

[33] W.H. Wellssow. Datenmodell für Planungsrechnungen. Forschungsgemeinschaft 

für Hochspannungs- und Hochstromtechnik 

FGH, 1995. 

[34] E. Wegscheider. Toward Code-Free Business Application Development. 

IEEE SW, pages 35–43, mar 1997. 


170 LITERATURVERZEICHNIS 


Lebenslauf 

Peter Bosshart 

von Zürich und Wittenwil TG 

geboren am 15. Juli, 1955 

1962-1968 Primarschule in Zürich 

1968-1969 Lyceum Alpinum, Zuoz 

1969-1972 Sekundarschule in Zürich 

1972-1976 Mittelschule in Zürich 

Matura Typus B 

1977-1982 Studium an der ETH Zürich 

Abschluss als Dipl. El.-Ing. ETH 

1983- 1992 Entwicklungsingenieur bei ABB Process Automation 

1992- 1997 Wissenschaftlicher Assistent am Institut für 

Hochspannungstechnik und 

Energieübertragung der ETH Zürich 

Dissertation unter der Anleitung von 

Prof. Dr. R. Bacher 

1995- Studium höheres Lehramt für Elektrotechnik

Diss.-ETH 12317 Diss.-ETH 12317 Diss.-ETH 12317 Diss.-E Eine ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?