Software auf Schienenfahrzeugen der Deutschen Bahn AG unterliegt einem
Konfigurationsmanagement, wobei immer eine Software-Zielversion pro
Fahrzeugvariante gebildet wird.
Die Größe der Flotte und die Teilumrüstung der Software in verschiedenen Werken
bedingt, dass die Zielversion häufig nicht in einem Schritt erreicht wird, sondern über
verschiedene Zwischenzustände, die durch Übergangsversionen abgebildet werden.
Hierbei muss jedoch sichergestellt sein, dass jede Konfiguration stets gültig und
funktionsfähig ist.
In diesem Zusammenhang sind Abhängigkeiten der einzelnen Softwaresysteme
untereinander und von anderen Entitäten, wie z.B. der Region, der Jahreszeit und
gesetzlichen Bestimmungen zu beachten. Diese Abhängigkeiten unterscheiden sich
hinsichtlich mehrerer Kriterien, wie zum Beispiel ihrer Ausprägung und Relevanz. Die
Abhängigkeiten werden in der Diplomarbeit anhand derartiger Merkmale und ihrer
Abhängigkeitspartner analysiert und klassifiziert.
Aufbauend auf dieser Analyse wird ein Konzept vorgestellt, das drei Hauptgruppen von
Abhängigkeiten unterscheidet:
• Abhängigkeiten gegenüber Software-Komponenten
• Abhängigkeiten gegenüber systemexternen Entitäten
• Abhängigkeiten gegenüber anderen Abhängigkeiten
Das Konzept ist in einem Entity-Relationship-Modell abgebildet und gibt insbesondere
Wertebereiche für die Klassifizierung der Abhängigkeitspartner vor. Ein Beispiel hierfür
ist die Abhängigkeit eines Softwaresystems vom Kurvenradius der Strecke. Hierfür
können geforderte bzw. zulässige Intervalle eingegeben werden.
Das Modell ist mithilfe einer Datenbanklösung umgesetzt. Die Entwicklung dient
gleichermaßen als Wissensdatenbank für die Mitarbeiter der Deutschen Bahn AG als
Basis für die Prüfung erstellter Konfigurationsaufstellungen und als Datengrundlage für
eine visuelle Darstellung.
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation
1.2 Aufgabenstellung
1.3 Ziele
1.4 Ausgangslage
2 Einordnung in das Software-Konfigurationsmanagement
2.1 Hinführung
2.2 Notwendigkeit
2.3 Ziele
2.4 Die vier Säulen des Softwarekonfigurationsmanagements
2.5 Variantenmanagement
2.6 Konfigurationsmanagement bei Fahrzeugsoftware der DB AG
3 Abhängigkeiten von Softwarekomponenten
3.1 Begriffsdefinition
3.2 Arten
3.3 Klassifikation
3.4 Ursachen
4 Verwaltung von Abhängigkeiten
4.1 Analyse
4.1.1 Anforderungen
4.1.2 Architekturmodell
4.2 Realisierungsidee Paketmanager
4.2.1 Konzept
4.2.2 Bewertung
4.3 Datenbankbasiertes Softwaresystem
4.3.1 Entwurf Datenmodell
4.3.2 Realisierung
4.3.3 Anlegen von internen Abhängigkeiten
4.3.4 Anlegen von externen Abhängigkeiten
4.3.5 Abfrage von Abhängigkeiten
4.3.6 Vorschläge für weitere Prototypversionen
4.3.7 Vorschlag zur Einführung und Benutzung des Systems
5 Darstellungsmöglichkeiten
5.1 Motivation
5.2 Anwendungsbereiche und Beispiele
5.3 Syntaktische Darstellungen
5.3.1 Natürliche Sprache
5.3.2 Relationen
5.3.3 Dependency Schreibweise
5.3.4 MAKE-Beschreibung
5.4 Graphische Darstellungsmöglichkeiten
5.4.1 Abhängigkeitsgraph
5.4.2 Gantt
5.4.3 UML
5.4.4 Dependency Structure Matrix
5.4.5 PERT-Diagramme
5.4.6 CPM-Methode
5.4.7 Petri-Netze
5.4.8 P-Netze
5.4.9 CIE-Diagramme
5.5 Verworfene Ansätze
5.6 Zusammenfassung
6 Zusammenfassung und Ausblick
A Anhang
A.1 Weiterführende Definitionen zu Relationen
A.2 Agile Softwareentwicklung
A.3 Screenshots aus der Softwarelösung
Abbildungsverzeichnis
1.1 Beispiel einer Softwareladeliste
2.1 Die vier Säulen des KM
3.1 Abhängigkeitsarten Mindmap
3.2 Abhängigkeitsarten im Bereich der Deutschen Bahn AG bei Fahrzeugsoftware
3.3 Klassifikationsmöglichkeiten
3.4 Implizite / Explizite Abhängigkeiten
3.5 Multidimensionaler Bereich der Abhängigkeiten
4.1 Abhängigkeit zwischen Softwarekomponenten
4.2 Externe Abhängigkeit
4.3 Abhängigkeit gegenüber einer internen Abhängigkeit .
4.4 Abhängigkeit gegenüber einer externen Abhängigkeit .
4.5 Gewerkeübersicht
4.6 Gewerkestruktur gruppiert
4.7 Beispielhafter Aufbau der Datenstruktur
4.8 Übersicht im Aptitude Paketmanager
4.9 Abhängigkeitsbedingungen in Synaptic
4.10 Externe Abhängigkeit
5.1 Abhängigkeitsdiagramm der sql_class.cc von mysql . .
5.2 „Spaghettigraph“
5.3 Gantt Abhängigkeitsdiagramm entnommen aus [KS02]
5.4 Abhängigkeitsbeziehung mit mehr als zwei Elementen
5.5 UML Verwendungsbeziehung
5.6 UML Realisierungsbeziehung
5.7 UML Substitutionsbeziehung
5.8 UML Verteilungsbeziehung
5.9 UML-Abhängigkeitsdiagramm entnommen aus [Mar05]
5.10 Mögliche Abhängigkeitsbeziehungen
5.11 Beispiel einer DSM zur Darstellung von Abhängigkeiten
5.12 Beispiel für ein Pert Diagramm im Softwareentwicklungsprozess
5.13 Abhängigkeiten von Aktivitäten am Beispiel des Caruso Projekts
5.14 CPM Diagramm - Beispiel für Zubereitung von Kaffee
5.15 Beispiel eines P-Netz. Vom Sourcecode zur fertigen Software
5.16 Einfaches Beispiel eines CIED Diagramms
6.1 Roadmap für die weitere Bearbeitung
A.1 Login-Screen
A.2 Hauptbildschirm
A.3 Administrationsmöglichkeit (Analog für Komponente und Version) .
A.4 Interne Komponentenabhängigkeit hinzufügen
A.5 Interne Abhängigkeit gegenüber einer anderen Abhängigkeit hinzufügen
A.6 Anlegen externer Abhängigkeiten
A.7 Abfrage von Abhängigkeiten
A.8 Logfile
Kurzfassung
Software auf Schienenfahrzeugen der Deutschen Bahn AG unterliegt einem Konfigu- rationsmanagement, wobei immer eine Software-Zielversion pro Fahrzeugvariante ge- bildet wird.
Die Größe der Flotte und die Teilumrüstung der Software in verschiedenen Werken be- dingt, dass die Zielversion häufig nicht in einem Schritt erreicht wird, sondern über verschiedene Zwischenzustände, die durch Übergangsversionen abgebildet werden. Hierbei muss jedoch sichergestellt sein, dass jede Konfiguration stets gültig und funk- tionsfähig ist.
In diesem Zusammenhang sind Abhängigkeiten der einzelnen Softwaresysteme untereinander und von anderen Entitäten, wie z.B. der Region, der Jahreszeit und gesetzlichen Bestimmungen zu beachten. Diese Abhängigkeiten unterscheiden sich hinsichtlich mehrerer Kriterien, wie zum Beispiel ihrer Ausprägung und Relevanz. Die Abhängigkeiten werden in der Diplomarbeit anhand derartiger Merkmale und ihrer Abhängigkeitspartner analysiert und klassifiziert.
Aufbauend auf dieser Analyse wird ein Konzept vorgestellt, dass drei Hauptgruppen von Abhängigkeiten unterscheidet:
- Abhängigkeiten gegenüber Software-Komponenten
- Abhängigkeiten gegenüber systemexternen Entitäten
- Abhängigkeiten gegenüber anderen Abhängigkeiten
Das Konzept ist in einem Entity-Relationship-Modell abgebildet und gibt insbesondere Wertebereiche für die Klassifizierung der Abhängigkeitspartner vor. Ein Beispiel hierfür ist die Abhängigkeit eines Softwaresystems vom Kurvenradius der Strecke. Hierfür können geforderte bzw. zulässige Intervalle eingegeben werden.
Das Modell ist mithilfe einer Datenbanklösung umgesetzt. Die Entwicklung dient glei- chermaßen als Wissensdatenbank für die Mitarbeiter der Deutschen Bahn AG, als Basis für die Prüfung erstellter Konfigurationsaufstellungen und als Datengrundlage für eine visuelle Darstellung.
Abstract
Vehicular Software of Deutsche Bahn AG is subject to a configuration management: For each vehicle model one single target version for all involved software components is built.
Due to the size of the fleet and the fact that the changeover of software takes place in various factories and therefore is iterative, quite frequently the target version cannot be reached in one single step. In this case intermediate states of all software versions are necessary. Nevertheless it is crucial that all configurations are valid and reliable at any time.
When talking of configuration, you have to keep in mind that there are dependencies between all software components itself and towards external entities, like regional restrictions, seasonal limitations or legal requirements. Moreover these dependencies differ by any means in miscellaneous criteria: e.g. their occurrence and their relevance. In this diploma thesis, several differentiating factors of dependencies and their relating partners are analysed and developed.
Based upon this analysis, a concept is presented which distinguishes three basic types of dependencies:
- Dependencies between software components
- Dependencies between software and external entities
- Dependencies between software and other dependencies
This concept is represented by an entity-relationship-model and provides a statement of requirements for valid classifications of dependency-partners. As an example, a soft- ware component of a train vehicle could be dependent of the track’s curve radius. In this case, it would be helpful to provide claimed and respectively valid ranges.
In terms of support in practice, the model is implemented in a database solution. This software has the task to support the employees of Deutsche Bahn AG, while verifying configurations for vehicular software. This is achieved by providing and managing all necessary information about dependency relationships.
1 Einleitung
1.1 Motivation
Für die Beförderung von Gütern und Personen ist der Transport auf Schienenfahrzeu- gen heutzutage den wichtigsten Verkehrsmitteln zuzuordnen. Im Rahmen des techni- schen Fortschritts haben sich auch im Bereich von Schienenfahrzeugen komplexe Soft- waresysteme verbreitet, die für einen zuverlässigen und sicheren Betrieb bei minima- len Kosten sorgen. In modernen Zügen gilt es bis zu 140 Mikroprozessorsteuerungen, wie in [BKLS06] beschrieben, mitsamt der darauf aufbauenden Software miteinander zu verbinden, zu koordinieren und zu konfigurieren. Wie [ABPG05] ausführt, verviel- fachte sich aber auch beispielsweise die Größe automotiver Software von 100 Kilobyte bis zu geschätzten 1 Gigabyte innerhalb der letzten 15 Jahre jeweils pro Fahrzeug. Ein ähnlicher Trend wird im Bereich der Schienenfahrzeuge oder eingebetteter Systeme, ebenfalls, jedoch mit Zeitverzug, beobachtet.
Durch die steigende Zahl von Softwarekomponenten in Schienenfahrzeugen ergibt sich somit auch eine wachsende Komplexität im Zusammenspiel dieser verschiedenen Komponenten untereinander und zwar nicht nur auf Codeebene, sondern auch darüber hinaus zwischen abgeschlossenen Softwarekomponenten. Auch hier zeigt sich die Kehrseite des technischen Fortschritts: Während bei mechanischen Elementen (z.B. Zahnräder) die Abhängigkeit der einzelnen Bauteile noch verhältnismäßig klar und offensichtlich war, ist dies bei Software aufgrund ihrer Immaterialität nicht mehr gegeben. Software kann außerdem nicht als isoliertes Problemfeld angesehen werden, da sie zum Betrieb per se Hardware benötigt. Probleme im Bereich von Software sind daher immer eng in Kombination mit Hardware zu betrachten.
Zusammenhänge innerhalb von und zwischen Software sind nicht offensichtlich, son- dern müssen anhand von Spezifikationen, Normen und Definitionen abgebildet und geprüft werden. Dieser Mehraufwand impliziert eine exakte und genaue Definition der Funktion der Software und eine detaillierte Abbildung der Abhängigkeiten, um dieses Defizit der einfachen Wahrnehmung zu kompensieren. Bei materiellen Bautei- len von Fahrzeugen lässt sich die „Richtigkeit“ der Zusammenstellung verschiedener Komponenten empirisch einfacher belegen, als bei „undurchsichtiger“ Software. Wird ein falsches mechanisches Bauteil verwendet, so passt dieses z.B. aufgrund der tech- nischen Maße nicht in das Gesamtprodukt. Zum Beispiel arbeitet ein falsches Zahn- rad nicht mit anderen und blockiert im laufenden Betrieb oder passt gar nicht erst in das Gesamtsystem - dies ist klar erkennbar. Bei Software hingegen ist dieser materiel- le Prüfmechanismus nicht gegeben, da die Hardware jede systemkompatible Software aufnimmt, ohne die Richtigkeit im Gesamtkontext empirisch prüfen zu können.
Vor allem im Hinblick auf das Thema Sicherheit (Safety) ist eine ordnungsgemäße Zusammenstellung der Softwarekomponenten von immenser Wichtigkeit. Denn wie bei jeder anderen Komponente auch, kann eine fehlerhafte Zusammenstellung und eine Missachtung von Abhängigkeiten zu Fehlern im Betrieb der Software führen. Dies zieht Sicherheitsprobleme und weitere Risiken nach sich.
Die vorliegende Diplomarbeit beschäftigt sich mit dieser Thematik und beleuchtet die grundlegende Problemstellung und die damit verbundenen Anforderungen. Erarbeitet werden sollen mögliche Problemlösungswege für die Verwaltung und Darstellung von Abhängigkeiten von Fahrzeugsoftware im Gesamtzusammenhang des Softwarekonfi- gurationsmanagements. Anzumerken ist hierbei, dass die Begriffe Fahrzeugsoftware und Schienenfahrzeugsoftware synonym verwendet werden.
1.2 Aufgabenstellung
In dieser Diplomarbeit sollen zunächst die für die Konfigurationsaufstellung erforderlichen Daten möglichst so klassifiziert werden, dass auch Daten einzuordnen sind, die in Zukunft zusätzlich erhoben werden. Dabei sind Notwendigkeiten, Ziele und Rahmenbedingungen für das vorliegende Problem zu erfassen und zu prüfen. Überdies soll eine Abgrenzung zwischen allgemeingültigen Aspekten bei Abhängigkeiten und denen im Bereich der Fahrzeugsoftware bei der DB AG stattfinden, sodass die gültigen Besonderheiten herausgestellt werden.
Im Detail werden dann die Abhängigkeiten der Softwarekomponenten von Fahrzeu- gen definiert und klassifiziert, sodass darauf aufbauend geeignete Darstellungsarten ubernommen oder entwickelt werden können. Aufbauend auf den Ergebnissen der Analyse soll ein Konzept für ein Softwaresystem zur Verwaltung und Darstellung von Abhängigkeiten erarbeitet werden und in Teilbereichen in Form von Prototypversionen realisiert werden. Sofern möglich, kann hier auch passende Software oder ein Konzept eines Drittherstellers herangezogen werden. Hierbei gilt es insbesondere auch mögli- che Alternativen hinsichtlich der verschiedenen Lösungsansätze zu finden und zu be- werten.
Die grundlegenden Probleme der bisherigen Darstellung und deren Hintergründe sollen analysiert werden. Hierbei sind zudem die Anforderungen an Konfigurationsaufstellungen zu formalisieren und in den Kontext des Software-Konfigurationsmana- gements einzuordnen.
Ein Ausblick auf weitere Analyseaspekte, die über die Bearbeitung der Diplomarbeit hinausgehen, dient als Wegweiser für weitere Bearbeitungen des Themas.
1.3 Ziele
Im Gegensatz zu gängigen Diplomarbeitsthemen, ist bei dieser Arbeit kein konkreter Lösungsansatz zu evaluieren oder zu realisieren, sondern vielmehr sollen eine erste Analyse und mögliche Lösungsansätze erarbeitet werden.
Die entsprechenden Detailziele sind wie folgt definiert:
- Mit Hilfe einer Ist-Analyse soll definiert werden, wie die Verwaltung der Abhängigkeiten derzeit stattfindet. In diesem Zusammenhang sollen die notwendigen Begrifflichkeiten herausgearbeitet und definiert werden.
- Aufbauend auf dieser Analyse soll der derzeitige Stand bewertet und daraus eine Problemstellung definiert werden.
- Die Abhängigkeiten im Bezug auf Fahrzeugsoftware sollen herausgearbeitet und hinsichtlich ihrer Abhängigkeitspartner und Klassifikationsmöglichkeiten charakterisiert werden.
- Zur Problemlösung soll ein softwarebasiertes Konzept entwickelt werden.
- Dieses Konzept soll in Form von Prototypen realisiert werden, um bereits erste Arbeitserleichtungen im Alltag zu ermöglichen und eine Ausgangsbasis für eine Weiterentwicklung zu schaffen.
- Möglichkeiten zur visuellen Darstellung von Abhängigkeiten sollen erörtert wer- den.
1.4 Ausgangslage
Derzeit werden die Software-Konfigurationsaufstellungen der einzelnen Baureihen und Bauarten[[1]] in einer Tabellenkalkulationssoftware manuell gepflegt. Diese Aufstellung, die sogenannte „Softwareladeliste“ dient als Grundlage dafür, welche Softwarekomponenten auf die jeweiligen Schienenfahrzeuge aufgespielt werden und ist jeweils bei einer Softwareänderung neu zu erstellen bzw. zu ergänzen. Ein Beispiel einer solchen Softwareladeliste findet sich in Abbildung 1.1.
Im Bezug auf alle Abhängigkeiten von Software gegenüber anderer Software sind im Aufgabengebiet der Bauartbetreuung nur diejenigen Abhängigkeiten von Relevanz, die zwischen den Softwarekomponenten vorliegen und nicht innerhalb dieser selbst. Darüber hinaus müssen diejenigen Abhängigkeiten betrachtet werden, die im Bezug auf die Integration einer Komponente in ein (bestehendes) Gesamtsystem - ein Fahrzeug oder ein ganzer Zug - auftreten und die so bestimmen, was ein System bereitstellen muss, um den Anforderungen der Softwarekomponente zu genügen. Diese Abhängigkeiten bezeichnet [Szy98] als „ context dependencies “.
Die mangelnde Möglichkeit zur Darstellung der Abhängigkeiten bzw. der Relationen zwischen einzelnen Softwarekomponenten führt dazu, dass diese wichtige Information nur als Metainformation sekundär verfügbar ist.
Das Grundwissen über die vorhandenen Abhängigkeiten findet sich nur verstreut und in keiner einheitlich strukturierten Form wieder. Einige der Abhängigkeiten sind in von Herstellern mitgelieferten Dokumenten enthalten, weiteres Wissen über Abhän- gigkeiten ist in verschiedenen Abteilungen teilweise undokumentiert vorhanden. Eine schnelle und präzise Aussage über neue Kombinationsmöglichkeiten von Software ist somit nicht möglich - es fehlt eine offene Wissensdatenbank. Eine Bearbeitung dieser Aufstellung durch einen anderen Mitarbeiter ist ohne grundlegende Einarbeitung nicht möglich, obwohl das entsprechende Fachwissen vorhanden wäre.
Sowohl die Erfassung der Aufstellungen als auch die Zusammenstellung ist derzeit nur schwer handhabbar, da die verwendete Tabellenlösung sich als wenig komfortables Werkzeug für diesen Einsatzzweck erwiesen hat. Änderungen am Layout bedürfen fast immer einer Änderung oder eines Umkopierens des Inhalts.
Darüber hinaus findet die Generierung der Softwareladeliste manuell statt. Dies bedarf eines hohen zeitlichen Aufwands und ist darüber hinaus fehleranfällig.
1 Im Bereich von Schienenfahrzeugen unterscheidet man Baureihen, Bauarten und Bauserien. Nach [Wik07b] ist eine Baureihe im Bezug auf Eisenbahnen jeweils eine Gruppe von Schienenfahrzeugen, die in vielfacher Ausführung in gleichartiger Weise gefertigt wurden. Dies ist zum Beispiel der ICE-T mit den Baureihen 411/415 und der ICE-1 mit der Baureihe 401. Auf der Ebene der einzelnen Fahr- zeuge (z.B. Wagen) existieren Bauarten, die verschiedene Entwicklungsstufen abbilden und so bspw. eine Trennung zwischen erster und zweiter Klasse ermöglichen. Bei Bauserien wird eine jeweilige Bau- reihe oder Bauart nachgebaut, jedoch unter Einbeziehung von konstruktiven Verbesserungen, die sich ergeben, da z.B. effizientere Teile lieferbar sind oder gewisse Komponenten nicht mehr verfügbar sind.
1.4 Ausgangslage
Abbildung 1.1: Beispiel einer Softwareladeliste
Abbildung in dieser Leseprobe nicht enthalten
2 Einordnung in das Software-Konfigurationsmanagement
2.1 Hinführung
Im Hinblick auf das vorliegende Thema soll eine Einordnung im Rahmen des Softwareentwicklungsprozesses und des Produktlebenszyklus stattfinden. Die Problematik der Behandlung und Auflösung von Abhängigkeiten von Softwarekomponenten ist im Bereich des Konfigurationsmanagements anzusiedeln.
Nach [Kol87] stammt das Konfigurationsmanagement (KM) aus dem Bereich der Hardwareentwicklung in den USA zwischen 1955 und 1960. Der erste Standard für KM (AFSCM 375-1) wurde 1962 bei der US Air Force entwickelt, da bei der Entwicklung eines Jets Mängel im Bereich der Kontrolle und der Kommunikation im Projekt auftraten, die es zu beseitigen galt (Vgl. hierzu [Ber92]). Diese Norm gilt als Grundlage für alle Folgeentwicklungen im Bereich des Konfigurationsmanagements.
Das Software-Konfigurationsmanagement (SKM) und das KM unterscheiden sich in den wesentlichen Bestandteilen nicht voneinander. Beide implizieren identische Funk- tionen wie beispielsweise Identifikation, Kontrolle und Auditing von Konfigurationen, wie in [BHS80] beschrieben. Der Hauptgrund einer eigenen Ableitung des KM für Soft- ware liegt darin begründet, dass die Handhabung des Konfigurationsmanagement für Hard- und Software nicht einheitlich stattfand und Software im klassischen KM nur oberflächlich behandelt wurde. Nach [BHS80] lässt sich zusammenfassend sagen, dass das SKM eine Übertragung des KM auf Systeme ist, die von Software dominiert wer- den.
Das Software-Konfigurationsmanagement ist nach [Ber79], [Tic99], eine Disziplin, um alle Änderungen, die während des Softwareentwicklungsprozesses stattfinden syste- matisch zu kontrollieren, zu verfolgen und zu steuern. Nach [Sie03] dient es der Kon- trolle und der Koordination aller Aktivitäten in der Entwicklung von Softwaresystemen und im Bezug auf den Lebenszyklus von Software. Darüber hinaus ist diese Disziplin von der zugrundeliegenden Systemarchitektur und dessen Produktvielfalt abhängig (Vgl. hierzu [Dum01b]). Softwarekonfigurationsmanagement steht in engem Zusam- menhang mit vielen Standard-Entwicklungsprozessen, wie z.B. dem Capability Ma- turity Model for Software (CMM), dem V-Modell oder dem Wasserfallmodell. Da im Bereich dieser Arbeit die Betrachtungsweise hinsichtlich Fahrzeugsoftware ausgelegt ist, wird „Konfigurationsmanagement“ im Folgenden immer synonym mit „Software- konfigurationsmanagement“ verwendet.
Da in den Begrifflichkeiten des SKM und des KM der Begriff der „Konfiguration“ An- wendung findet, muss dieser definiert werden. Eine Definition hierzu bietet die EN ISO 10007 [Deu95]:
„Funktionelle und physische Merkmale eines Produkts, wie sie in zuge- hörigen technischen Dokumenten beschrieben und im Produkt verwirklicht sind.“
2.2 Notwendigkeit
Wie bereits einleitend erläutert, steigt die Anzahl von Einzelelementen in Softwaresys- temen und die damit verbundene Komplexität immer weiter an. Diese Elemente wer- den Konfigurationselemente (KE) oder Configuration Items (CI) genannt. Sie stellen die wichtigsten Bausteine des SKM dar, da Konfigurationselemente die Objekte sind, die mit Hilfe des SKM verwaltet werden sollen. Unter einem solchen Element kön- nen nicht nur der reine Programmcode, sondern darüber hinaus auch alle Dokumente, die eine Einflussgröße im Hinblick auf die Software darstellen, wie z.B. Pflichtenhefte, Entwurfsdokumente, Gutachten, Entwicklungsumgebungen, Compiler, Testdaten, Bi- naries, User Manuals, etc. verstanden werden. Es handelt sich hierbei um elementare Einheiten, die nicht weiter aufgetrennt werden können und somit in keinerlei Variation auftreten dürfen, sondern die kleinsten atomaren Elemente im Bezug auf die Konfigu- ration darstellen, wie in [Buc96], [BHS80] beschrieben wird.
Verbunden mit der Tatsache, dass immer wieder neue Softwarereleases generiert wer- den, vervielfacht sich hier eine große Anzahl von Elementen eines Softwaresystems pro Zeiteinheit. Berücksichtigt man darüber hinaus noch den Aspekt der Globalisierung, nämlich die Möglichkeit, dass Softwareentwicklung in länderübergreifenden Teams stattfinden kann, so kann man zusammenfassend sagen, dass es eine große Anzahl von Elementen eines Softwaresystems an unterschiedlichsten Orten zu verwalten gilt. Zusätzlich existieren noch weitere Aspekte, die die Komplexität erhöhen, wie z.B. ver- schiedene Plattformen, Dateisysteme und Client-/Server-Strukturen, wie in [BS00] be- schrieben.
Hier setzt das SKM ein und stellt systematische Hilfen zur Bewältigung dieser Proble- me bereit. Der Einsatz von SKM ist immer dann sinnvoll, wenn gravierende Probleme im Softwarelebenszyklus auftauchen, die sich beispielsweise auf die Qualität von Soft- ware auswirken.
In den Ausführungen von [HS85] werden konkrete Probleme erläutert, die auf die Not- wendigkeit von SKM hinweisen. Hierunter zählt das bereits angesprochene Mengen- problem: Es gilt eine Vielzahl von Softwareelementen konsistent zu verwalten. Die große Menge von Softwarebestandteilen ist aber nicht als Konstante anzusehen, son- dern befindet sich durch geplante Änderungen, Erweiterungen und Fehlerbereinigun- gen in einem stetigen Wandel. Dies verursacht demnach das Änderungsproblem, da es die Vielzahl von Änderungen zu kontrollieren, koordinieren und zu protokollieren gilt. Dies ist dadurch begründet, dass so eine Rückverfolgbarkeit aller Änderungspro- zesse einer Software gegeben ist und so jeder Entwicklungszustand wiederhergestellt werden kann. Eng damit verbunden beschreibt [HS85] das Lebensdauerproblem, weil auch Änderungen im Bezug auf die Wartung und die damit verbundene Lebensdau- er einer Software existieren. Man versucht durch Wartungen die Lebenszyklen einer Software zu erweitern, für diese Aufgabe bedarf es jedoch genauer Kenntnisse über die beteiligten Softwareelemente eines Produkts. Bedingt durch die Etablierung objek- torientierter Programmierung mit dem damit verbundenen Grundsatz der Wiederver- wendung von Code, besteht eine Software nicht mehr aus nur einem einzelnen Projekt, sondern wird in der Regel aus mehreren Komponenten zu einem Gesamtprodukt zu- sammengestellt. Diese Einzelkomponenten haben jedoch eine Eigendynamik im Bezug auf den Lebenszyklus. Einige Module sind bereits fertig zur Auslieferung und wurden bereits getestet, während andere Module noch in der Spezifikationsphase verweilen. Überdies existieren einzelne Module in unterschiedlichen Ausprägungen ihrer selbst, da z.B. verschiedene Release-Stände bei den jeweiligen Kunden im Produktiveinsatz sind. Diese Problematik bezeichnet wird in [HS85] als das Konsistenzproblem, da es als Aufgabe gilt all diese unterschiedlichen Entwicklungsstände konsistent und deren Dokumentation aktuell zu halten.
Softwarekonfigurationsmanagement erhebt den Anspruch, bei diesen Problemen als Hilfestellung dienen zu können. Daraus lassen sich die Grundfunktionen des Konfigurationsmanagement ableiten [Dum01b], die sich wie folgt widerspiegeln:
- Bestimmung und Festlegung der Einzel- und Gesamtkonfigurationsstruktur.
- Steuerung und Bearbeitung aller anfallenden Änderungen.
- Änderungsüberwachung mitsamt Sicherstellung der Konsistenz und Vollständigkeit nach Realisierung von Änderungen.
- Protokollierung (Erfassung und Verwaltung) aller Konfigurationsmerkmale der Systemelemente.
Eine genauere Betrachtung der vier Säulen, findet sich in Kapitel 2.4.
2.3 Ziele
Die Ziele des (Software-)Konfigurationsmanagement lassen sich im Wesentlichen auf zwei Hauptaspekte komprimieren:
- Die Produktkonfiguration eines Systems soll dokumentiert werden, sowohl unter dem Aspekt der Vergangenheit, als auch der gegenwärtige Stand. Darüber hinaus ist es das Ziel, über den ganzen Lebenszyklus hinweg jederzeit eine Aussage über die Erfüllung der Anforderungen eines Systems treffen zu können. (Vgl. hierzu [BR05])
- Es soll sichergestellt werden, dass ein Produkt eindeutig hinsichtlich seiner funktionellen und äußeren Merkmale identifizierbar ist. Dies hat den Grund, dass so Änderungen kontrolliert werden können und die Integrität des Produkts zu jedem Zeitpunkt sichergestellt werden kann. (Vgl. hierzu [Bun04])
2.4 Die vier Säulen des
Softwarekonfigurationsmanagements
Das Softwarekonfigurationsmanagement lässt sich zusammenfassend auf vier Wesent- liche Aufgabengebiete beschränken, die sogenannten „Vier Säulen des Softwarekonfi- gurationesmangement“, wie von [Sie03] und [Whi91] definiert. Angelehnt an [Rie02] lassen sich diese Themengebiete mitsamt den wichtigsten damit verbundenen Frage- stellungen, wie in Abbildung 2.1 darstellen. Die einzelnen Säulen sollen nachfolgend in ihrer Funktion zusammengefasst und die wichtigsten Fragestellungen ausgeführt wer- den, wie von [Tic88] und [Whi91] ausgelegt. Im Hinblick auf das Thema wird vor allem Wert auf die Aspekte gelegt, die der Softwareprogrammierung übergeordnet sind.
- Version-Management
Das Versionsmanagement dient der Verwaltung und Lenkung aller Softwareele- mente und Dokumente von der Entstehung bis zur Auslieferung, also über den gesamten Lebenszyklus. Die Abbildung erfolgt über Zustände. Es stellt den Ent- wicklern zudem Arbeitsbereiche zur Verfügung, in denen Sie über Ihre notwen- digen Ressourcen verfügen und somit ungestört arbeiten können. Das Versions- Management lenkt die gleichzeitige Überarbeitung von Programmen und Doku- menten in einem Entwicklerteam. Die wichtigsten Fragestellungen, die im Be- reich des Versionsmanagement geklärt werden müssen lauten:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1: Die vier Säulen des KM
- Wie kann man viele verschiedene Versionen effizient verwalten?
- Wie sollte man eine alte Programmversion aufbewahren und vorhalten, so- dass man z.B. zu einem späteren Zeitpunkt noch Fehler untersuchen kann?
- Build-Management
Das Build-Management dient der Verwaltung von Abhängigkeiten zwischen den Softwareelementen und der Erzeugung ausführbarer Software. Es werden die Schritte vom Programmcode bis zur lauffähigen Software automatisiert. Zudem werden die Abhängigkeiten von Programmen und Dokumenten im Rahmen des Build Managements verwaltet.
- Welcher Aufwand wird verursacht, wenn sich ein Element des Gesamtprodukts ändert?
- In welcher Reihenfolge wird ein System aufgebaut?
- Welche Abhängigkeiten existieren und wie kann man diese beherrschen?
- Release-Management
Hier steht die Verwaltung und Dokumentation der Endergebnisse der Softwa- reentwicklung im Vordergrund. Release werden fertige Softwarepakete genannt. Das Release besteht im Wesentlichen aus dem getesteten Endprodukt zusammen mit der Dokumentation und den Release-Notes. Releases haben eine besondere Stellung im Software Lebenszyklus. Da diese Versionen an den Kunden ausge- liefert werden, muss sichergestellt werden, dass diese vollständig, getestet und nicht fehlerhaft sind. Zudem dürfen nur autorisierte Personen Releases als solche definieren und ausliefern. Zu Supportzwecken und eventuellen Nacharbeiten zur Fehlerbehebung ist es wichtig, dass die Releases aufbewahrt werden und die Zu- sammenstellung der Releasekomponenten mitsamt deren Versionierung bekannt ist.
Fragestellungen:
- Welcher Kunde hat welche Version im Einsatz?
- Welches Version ist auf welchem Fahrzeug aufgespielt?
- Welche Lizenzstrukturen hat der Kunde?
- Wie wird ein Update-Rollout vollzogen?
- Welche Probleme sind bekannt, welche Lösungen gibt es hierfür?
- Change-Management
Dieser Punkt regelt Änderungswünsche im Hinblick auf Software, die von der Umwelt ausgehen. Vorschläge für Änderungen müssen gesammelt und analy- siert werden. Die Vorschläge für gewünschte Änderungen können von verschie- denen Gruppen kommen, wie z.B. Kunden, anderen Abteilungen (bspw. Marke- ting, Vertrieb) oder von den Entwicklern selbst. Sobald ein Änderungswunsch eingegangen ist, wird entschieden, ob dieser Änderungswunsch gültig ist, da z.B. auch Änderungswünsche eingehen können, die insoweit keine sind, sondern viel- mehr auf systemabhängige Fehler oder auf eine Fehlbedienung der Software zu- rückzuführen sind. Die Entscheidung darüber, ob ein Änderungswunsch auch umgesetzt wird, fällt das Projektmanagement. Dieses lässt sich bei bei seinen Ent- scheidungen von mit dem Projekt vertrauten Systemingenieuren beraten.
Fragestellungen:
- Wie sollte der korrekte Ablauf für das Vorschlagen, Bewerten und die Implementierung einer Änderung sein?
- Welche Auswirkungen hat ein Änderungswunsch?
- Welche Fehler wurden in einer neuen Version beseitigt und welche sind noch zur Korrektur offen.
- Wurde jeder Interessent darüber benachrichtigt, dass eine Änderung stattgefunden hat?
- Wurde eine Änderungen sorgfältig getestet?
- Gibt es geplante Änderungen für ein Element?
2.5 Variantenmanagement
Das Variantenmanagement ordnet sich parallel zu diesen vier Säulen an und ist daher als zusätzliche Dimension [Piz04] zu sehen. Es befasst sich mit der Verwaltung nebeneinander existierender Versionen von Konfigurationselementen, die jeweils eine zeitliche Entwicklungsgeschichte besitzen. [Sch03] Variantenmanagement ist ein noch relativ junger Aspekt des SKM, der aber aufgrund der zunehmenden Individualisierung von Produkten immer wichtiger wird.
Generell gilt es bei der Betrachtung von Abhängigkeiten zwischen Softwarekomponen- ten Varianten und Versionen mitsamt den Abhängigkeiten zu unterscheiden. Auf Basis des V-Modell 97 [Bun97] sind Varianten als zeitlich nebeneinander liegende Produk- tausprägungen zu verstehen, während Versionen zeitlich nacheinander zu betrachten sind. Jede Änderung an einer Software resultiert in einer neuen Version. Somit können von einem Produkt mehrere Versionen und Varianten existieren und von einer Varian- te ebenfalls mehrere Versionen. Varianten besitzen zudem die Eigenschaft, dass diese unter Umständen problemlos durch andere Varianten getauscht werden können, da die gelieferten Ergebnisse identisch sind, da nur der Funktionsumfang erweitert wur- de. Gängige Variantenformen, wie man es von Standardsoftware her kennt, wären eine Home-, Premium- und Enterprise-Variante je nach Einsatzzweck. Da jedoch Varianten oftmals mit neuen Nummern versehen werden, wird dieser Begriff in manchen Fällen fälschlicherweise synonym zu Version verwendet.
2.6 Konfigurationsmanagement bei Fahrzeugsoftware der DB AG
Der Themenkreis der vorliegenden Arbeit siedelt sich im Bereich des Release- und des Build-Managements an. Dies ist darin begründet, dass hier die Abhängigkeitsproblematik auftritt und zudem klar sein muss, welche Konfiguration auf welchem Schienenfahrzeug im Einsatz ist.
Die bereitgestellte Software für Schienenfahrzeuge liegt in der Regel schon fertig vor und ist bereits abgenommen. Aus diesem Grund kann kein oder bzw. nur in sehr geringem Umfang Einfluss auf die jeweilige Software und deren Entwicklungsweise außerhalb der Funktionalitätsanforderung genommen werden.
Die Software wird von Herstellern geliefert und befindet sich noch nicht auf den Zügen, sondern muss zusammen mit anderen Softwarekomponenten in Form eines Gesamtpa- kets konfiguriert werden. Diese fertige Konfiguration der einzelnen Softwareelemente wird dann dem Betreiber zur Übernahme auf die einzelnen Schienenfahrzeuge über- geben. Generell muss Fahrzeusoftware auf unterschiedlichen Abstraktionsebenen be- trachtet werden, die im Rahmen des SKM verwaltet und konfiguriert werden müssen:
- Elementare Softwareeinheiten für einzelne Bausteine/EPROMs.
Hierbei handelt es sich um die einzelnen Softwareelemente zur Bereitstellung von Funktionalität. Dies können beispielsweise in Form von EPROM-Bausteinen mit Software (z.B. ICE-1) oder als direkte Kompilate (z.B. ICE-3) vorliegen. Die Verwaltung dieser Elemente übernimmt in der Regel der Hersteller.
- Komponente
Die Funktionalität einer Komponente wird aus verschiedenen einzelnen Soft- wareeinheiten gebildet, die dann im Gesamtpaket erst die vollständige Funkti- on abbilden. Zum Beispiel kann eine Gesamtkomponente aus einem speziellen Funktionalitätsmodul und universell benutzten Kommunikationsmodulen und Log-Modulen bestehen. Die Erstellung von Stücklisten für EPROMs und die Be- reitstellung der entsprechenden Softwarepakete der Komponenten erfolgt ebenso durch den Hersteller.
- Ein Gesamtpaket aus mehreren Komponenten, für ein einzelnes Fahrzeug
Jede Baureihe verfügt über eine individuelle Komponentenzusammenstellung zur Bereitstellung der Gesamtfunktionalität zum Betrieb des Fahrzeugs. So ist zum Beispiel das FIS (Fahrgastinformationssystem) auf den Triebköpfen des ICE1/2 nicht vorhanden, während diese Komponente auf anderen Fahrzeugen für die Fahrgäste notwendig ist. Bei dieser Zusammenstellung gilt es Abhängig- keiten zu beachten, die im Verantwortungsbereich der DB AG liegen.
- Eine Zusammenstellung von mehreren Fahrzeugen zu einem Zug.
Die Fahrzeugsoftware muss nicht nur in den einzelnen Fahrzeugen, sondern auch im Zug betrachtet werden: Der ICE-1 besteht aus 10 bis 14 Mittelwagen und zwei Triebköpfen, die jeweils über ein Bussystem kommunizieren. Dies muss bei der Konfiguration der Fahrzeugsoftware beachtet werden, damit eine reibungslose Kommunikation fahrzeugübergreifend stattfindet. Dies ist ebenfalls ein Aufga- benbereich der DB AG.
Als Konfigurationselement wird hierbei die Software-Komponente definiert, die je- weils durch eine Version gekennzeichnet ist. Diese stellen die kleinsten Einheiten dar, zwischen denen Abhängigkeiten bei der Bauartbetreuung betrachtet werden. Auf den Stufen davor hat der jeweilige Hersteller für die Konfiguration und die Lösung mögli- cher Abhängigkeitsprobleme Sorge zu tragen. Nach [Pop06] ist dies jedoch keine ein- malige Entscheidung, sondern die Definition der Konfigurationselemente ist ständige Aufgabe des Konfigurationsmanagements, die es immer wieder zu bewältigen und neu zu definieren gilt.
Alle Problemstellungen in Verbindung mit Abhängigkeiten zwischen den Konfigurationselementen müssen demnach im Arbeitsgebiet des Buildmanagements betrachtet werden und sind somit ein elementarer Bestandteil des SKM. Gängige Verfahren für Konfigurations- und Variantenmanagement können hierzu Lösungen hinsichtlich dieser Aufgaben liefern oder diese zumindest unterstützen.
3 Abhängigkeiten von Softwarekomponenten
3.1 Begriffsdefinition
Der Begriff der Abhängigkeit ist schwer nur in eine Bedeutung zu fassen, obwohl die- ser häufig Verwendung findet. Deshalb ist es wichtig, dass die formalen Definitionen rund um das Thema Abhängigkeiten dargestellt und bewertet werden. Um eine auf das Themengebiet angepasste Begriffsumschreibung zu finden, müssen diese Defini- tionen mit Verständnis des Begriffs „Abhängigkeit“ im Bereich der Fahrzeugsoftware abgeglichen werden. Die nachfolgenden Definitionen sind im Bereich der Mathematik, formalen Logik und Informatik einzuordnen. Darüber ist der Begriff der Abhängigkeit auch z.B. in den Bereichen der Medizin, Psychologie und Wirtschaft definiert. Da diese Informationen aber bei der Problemlösung nur marginal beitragen könnten, werden sie hier ausgeklammert.
Definition 1. [Bro01] Sind mehrere Begriffe oder Dinge (z.B. Gr öß en, Eigenschaften, Aus drücke, Aussageformen) durch bestimmte Zusammenhänge, Gesetzm äß igkeiten, Relationen, u.a. miteinander verknüpft, so werden sie als (voneinander) abhängig bezeichnet, d.h. es besteht eine Abhängigkeit zwischen ihnen. Eine explizite Abhängigkeit liegt vor, wenn eine Aussage der Form „ A hängt von A 1 , A 2 , ... , A n ab “ , gemacht werden kann. Ein Beispiel dafür die die Ab hängigkeit der Variablen y des Wertebereichs einer Funktion f von der unabhängigen Variablen x ihres Definitionsbereichs. Eine Aussage der Form A 1 , A 2 , ... , A n sind voneinander abhängig drückt eine implizite Abhängigkeit aus. Ein Beispiel ist die aus
Abbildung in dieser Leseprobe nicht enthalten
hervorgehende Gleichung der Form
Abbildung in dieser Leseprobe nicht enthalten
Da Abhängigkeiten auch als Relation gesehen werden können, lässt sich eine Einordnung analog zu den Relationen vornehmen und sich daraus ein entsprechender Formalismus ableiten. Deshalb kann nach [Wik07d] eine Funktion im mathematischen Sinne als Abhängigkeit aufgefasst werden.
Die genaue Definition der einzelnen mathematischen Klassifikationsmöglichkeiten findet sich im Anhang A.1.
Definition 2. [Mic00] Abhängigkeit : Der Zustand, in der eine Entität hinsichtlich der eige nen Definition oder Funktionalität von spezieller Hardware, spezieller Software oder speziellen Ereignissen abhängt.
Definition 3. [SBd05] Eine Abhängigkeit definiert eine Beziehung zwischen zwei Software Entitäten e1 und e2, wobei die Existenz von e1 von der Existenz von e2 abhängt oder alle Ä nderungen von e2 auch in e1 reflektiert werden müssen.
Obwohl diese Definitionen in Detailmerkmalen stark differieren, setzen sie jedoch alle auf einen gemeinsamen Kern auf:
- Es gibt mindestens zwei beteiligte Objekte (Begriffe, Dinge, Zustände, Gr öß en, Entitäten, Werte, Ergebnisse).
3 Abhängigkeiten von Softwarekomponenten
- Diese stehen in einem Verhältnis zueinander (Zusammenhang, Relation, Gesetzmäß igkeit, miteinander verknüpft, gebunden sein)
Weitere Begriffsdefinitionen, die aber auf Spezifalfälle von Abhängigkeiten abzielen, sind im Anhang A.1 zu finden.
Die vorgestellten Definitionen sind in ihren Ausprägungen nicht ausreichend, um Ab- hängigkeiten im Bezug auf die Fahrzeugsoftware deckend zu umschreiben. Daher ist es notwendig, eine eigenständige Definition für den Begriff „Abhängigkeit“ zu fassen, die auch insbesondere in den Kontext der Konfiguration von Fahrzeugsoftware passt.
Definition 4. Eine Abhängigkeit definiert die M ö glichkeiten der Verknüpfung zwischen min- destens zwei Entitäten e1 und e2 von Software-Komponenten. Sie impliziert eine Limitierung der Zusammenstellungsm ö glichkeiten gegenüber einer beliebigen Verknüpfung der Entitäten. Jede dieser Entitäten besitzt eine eindeutige Identifikation durch eine Versionsnummer, wodurch ein Abhängigkeitsverhältnis definierbar ist. Die Zusammenstellung der Komponenten erfolgt unter der Berücksichtigung der Abhängigkeiten zwischen den Softwarekomponenten in sich und externen Einflüssen, wie Hardware und Umweltabhängigkeiten zu einer Gesamtversion. Abhängigkeiten sind daher immer in einem Kontext zu betrachten. Eine Abhängigkeit ist keine Eigenschaft einer Entität, sondern immer als Attribut zwischen mindestens zwei Entitäten zu sehen.
3.2 Arten
Im konkreten Anwendungsfall im Bereich der Fahrzeugsoftware wurde im ersten Schritt eine Mindmap (siehe Abbildung 3.1) erstellt, die mögliche Abhängigkeitsarten in einer Stoffsammlung beleuchtet und grob zwischen technischen und nichttechnischen Abhängigkeiten im Bezug auf Softwarekomponenten unterscheidet.
Zum besseren Verständnis kann der Begriff „Abhängigkeitsart“ mit „Abhängigkeitspartner“ gleichgesetzt werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.1: Abhängigkeitsarten Mindmap
Ein anschauliches Beispiel aus dem nicht-technischen Bereich ist eine Abhängigkeit von einer Kosten-/Nutzenstruktur im Zweig Administrativ -> Monetär -> Effizienz. Jede Softwarekomponente wird in einem wirtschaftlichen Unternehmen so ausgelegt sein, dass diese größtmögliche Effizienz bringt. Findet sich hierbei eine bessere Lösung wird die Bestehende durch eine neue substituiert.
Aus dem Bereich der technischen Abhängigkeiten ließe sich anführen, dass Softwareelemente von physikalischen Grenzen abhängen (z.B. muss eine Software die Existenz der Schwerkraft berücksichtigen, um in der realen Welt einsetzbar zu sein) und somit die eingeschränkte Machbarkeit in der realen Welt berücksichtigen. Dies ist im Pfad Physisch -> Physikalisch -> „Machbarkeit eingeschränkt“ dargestellt.
Anhand dieser Beispiele zeigt sich, dass es weitreichende Variationen geben kann, die jedoch für das Aufgabenfeld der Diplomarbeit zu weit gefasst sind. Daher wurden in einem zweiten Schritt diese Abhängigkeiten insoweit reduziert, dass diese nur noch für die vorkommenden Arten im Bereich von Fahrzeugsoftware der Deutschen Bahn AG gelten. (Vgl. hierzu Abbildung 3.2). Die grundlegende Betrachtungsweise hierzu lautete „Der Einsatz der Software ist abhängig von X im Bereich der Deutschen Bahn AG“, wobei X die jeweilige Abhängigkeitsart darstellt. Im Bezug auf die vorher ge- tätigte Grobeinteilung lassen sich diese Abhängigkeitsarten ausnahmslos den externen Abhängigkeiten zuordnen. Zum besseren Verständnis sollen diese Abhängigkeiten nun jeweils anhand eines Beispiels im Bereich von Fahrzeugsoftware erläutert werden.
- Eine der offensichtlichsten Abhängigkeiten von Software ist diejenige gegenüber der Hardware, weil Software naturgemäß Hardware zur Funktionsausführung benötigt. Im Hinblick auf Schienenfahrzeuge kann eine unterschiedliche Hard- warebasis z.B. zwischen verschiedenen Baureihen vorliegen. Jedes Fahrzeug be- sitzt funktions- oder bauartbedingt unterschiedliche Softwarekomponenten mit einem entsprechenden Softwarestand. Werden nun verschiedene Wagen zu ei- nem Gesamtzug gekoppelt, gilt es sicherzustellen, dass die Software zwischen den Wagen - also innerhalb eines Zugs selbst - richtig konfiguriert ist. Darüber hinaus müssen auch Abhängigkeiten in einem Zugverband (Ein Zugverband be- steht aus n Zügen) beachtet werden. Jeder Zug besteht aus mehreren Wagen un- terschiedlicher Bauart, die dann zusammen mit einer Gesamtversion beschrieben werden. Werden nun zwei Züge gekuppelt, so sind auch hier die Abhängigkei- ten zwischen diesen Zügen zu beachten oder entsprechend die Kuppelbarkeit zu beschränken, sodass die möglichen Kombinationen eingeschränkt sind.
Im Hinblick auf sicherheitskritische Systeme spielt die Redundanz eine wichti- ge Rolle. Dadurch, dass wichtige Ressourcen mehrfach vorhanden sind, obwohl diese im störungsfreien Betrieb im Normalfall nicht benötigt werden, multipli- ziert sich an dieser Stelle auch die Anzahl der Softwarekomponenten und deren Abhängigkeiten.
Bedingt durch die Modernisierung bzw. Redesign (vgl. hierzu [DB07b]) der ICE 1 Züge (Baureihe 401), werden zahlreiche Änderungen an den bestehenden Zügen vorgenommen, wie z.B. ein modernisiertes Fahrgastinformationssystem, Entfer- nung der Radio- und Videosysteme und weitere Umbauten im Bereich des Innen- raums. Da hierbei auch Hardware getauscht wird, hat das Redesign Einfluss auf die Abhängigkeiten der Software, da hierbei neue Software aufgespielt werden muss.
- Die Abhängigkeit zwischen Softwarekomponenten stellt eine der wichtigsten Arten dar, da zur Bereitstellung der gewünschten Funktionalität verschiedene Komponenten miteinander kommunizieren müssen. Wichtig hierbei ist, dass sachfremde Komponenten sich aus Sicherheitsgründen nicht ungewollt negativ
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.2: Abhängigkeitsarten im Bereich der Deutschen Bahn AG bei Fahrzeugsoftware gegenseitig beeinflussen dürfen. Von jeder Software können verschiedene Aus- führungen existieren, die im Laufe der Zeit durch Weiterentwicklungen entstan- den sind.
- Neben dem Regulärbetrieb im täglichen Verkehr gibt es darüber auch speziel- le Veranstaltungen, die einen außerplanmäßigen Einsatz bedingen und somit aber zeitgleich eine andere Software erfordern. Denkbare Beispiele hierfür wä- ren Fahrten zur Zeit der WM 2006 in Deutschland, dort würden Züge mit einem besonderen Fahrgastinformationssystem (FIS) ausgestattet, das jeweils die Fahr- gastinformationen in der Landessprache der jeweilig an diesem Tage spielenden ausländischen Mannschaft anzeigt. Darüber hinaus gibt es Überführungsfahrten, bei denen Fahrzeuge ohne Fahrgäste an einen anderen Ort Transportiert werden. Da die Züge hierbei nicht selbstständig fahren, sondern geschleppt werden, ist hierzu unter Umständen andere Software als im Regelbetrieb erforderlich. Bei neuer oder geänderter Software finden Testfahrten statt, wobei diese sowohl mit Fahrgästen als auch ohne diese stattfinden. Hierfür kann beispielsweise Überwa- chungssoftware installiert werden, die dann später wieder entfernt wird.
- Da Schienenfahrzeuge von Menschen bedient werden und insbesondere Perso- nen befördern, ist der Einsatz der Fahrzeugsoftware in besonderem Maße vom Menschen abhängig. Sowohl das Zugpersonal als auch die Fahrgäste interagie- ren mit den Informationssystemen des Zuges und somit auch mit der Software. Ein Aspekt hierbei ist die Sprache, da Züge in unterschiedlichen Ländern einge- setzt werden. Als Beispiel hierfür kann man die Überfahrt deutscher ICE-Züge nach Paris [DB07a] oder nach Dänemark [DB07c] anführen. Für behinderte Per- sonen besteht hierbei nicht nur eine Erleichterung im Alltag, sondern eine Not- wendigkeit. Im Bezug auf die DB AG existieren ausgewählte Fahrzeuge mit einer behindertengerechten Zufahrtsrampe. Dieser Unterschied bedingt so eine Verän- derung in der Hard- und Softwarekonfiguration von Zügen. In zunehmendem Maße muss zudem das Prinzip der Individualisierung (siehe [Sch07]) betrachtet werden, wie z.B. individuelle Sitzpositionen und Einstellungen für Fahrgäste und Triebfahrzeugführer. Weitere Individualgruppen sind z.B. Kinder und Tiere.
Im Bereich der Außendarstellung lässt sich feststellen, dass naturgemäß ein großer Wert auf Fortschritt und Modernisierung gelegt wird, um den Kunden ein zeitgemäßes und angenehmes Reisen zu ermöglichen. Dies betrifft nicht nur die reine Austattung der Züge, sondern auch die Softwarekomponenten, z.B. im Bezug auf die elektronische Platzreservierung im Zug.
- Im Hinblick auf die Administration, existieren Abhängigkeiten, die nicht nur den Bereich der Fahrzeugsoftware, sondern den gesamten Eisenbahnbetrieb der Deutschen Bahn betreffen. Es existieren Normen und Richtlinien, die sowohl von extern als auch konzernintern als notwendig vorgeschrieben sind und die Soft- ware aus diesem Grund regelkonform konfiguriert werden muss. Darüber hin- aus bestehen gesetzliche Rahmenbedingungen. Andere Kriterien, die in den ad- ministrativen Bereich fallen, sind Themen, wie Prestige oder Supportleistungen. So könnte beispielsweise das Ende von Supportleistungen einen Softwarewechsel bedingen. Zur Gewährleistung zukunftssicherer Systeme ist es erforderlich, dass für Weiterentwicklungen und Fehlerbereinigungen weiterhin Supportleistungen vom jeweiligen Hersteller geleistet werden. Wird vom Konzern eine Partnerschaft mit einem Lieferanten beschlossen, beendet oder ist dieser insolvent, hat dies wie- derum Einfluss auf die Software durch den Tausch von Komponenten und dem damit verbundenen Problem, dass neue Abhängigkeiten auftreten können.
- Als ein weiterer Faktor gilt die Abhängigkeit der Software von lokale Gegeben- heiten. Die Fahrzeugsoftware ist insoweit angepasst, dass sie den jeweils vor- herrschenden regionalen Besonderheiten Genüge leistet. Hierbei lassen sich Ab- hängigkeiten gegenüber den natürlichen geographische Bedingungen und ge- genüber dem Einsatzgebiet unterscheiden. Mögliche Abhängigkeiten von natürli- chen Ressourcen wären ein Beispiel für geographischen Bedingungen. Dies könn- te sich bei Fahrzeugsoftware insoweit wiederspiegeln, dass es z.B. unterschiedli- che Software für das WC wegen regional unterschiedlicher Wasserhärten gäbe. Auch unter Berücksichtigung des Wetters oder des Klimas im Allgemeinen gibt es Abhängigkeiten, da jeweils für Sommer und Winter teilweise andere Software- komponenten zum Einsatz kommen können, um den entsprechenden Tempera- turen z.B. in puncto Kühlung zu genügen. Ein weiteres Beispiel wären die vorlie- gende Steigung oder der Kurvenradius im Zielgebiet - ein wichtiger Faktor z.B. für die Neigetechnik.
Im Rahmen der europäischen Union wird die Interoperabilität der europäischen Hochgeschwindigkeitsstreckennetze gefördert, sodass nun auch, wie bereits am Beispiel Frankreich und Dänemark erläutert, Züge grenzüberschreitend einge- setzt werden können. Es existiert demnach eine Abhängigkeit der Software be- züglich des Einsatzgebiets. Bislang besaß jedes nationale Streckennetz Besonder- heiten z.B. im Hinblick auf die Zugsicherungstechnik und soll nun aufgrund ei- ner EU-Richtlinie [EG96] durch das neue European Train Control System (kurz ETCS) vereinheitlicht werden. Da dieser Prozess jedoch noch nicht abgeschlossen ist und noch einige Jahre in Anspruch nimmt, müssen derzeit noch die alten na- tionalen Systeme parallel installiert sein. Dies führt kurzfristig sowohl zu höheren Kosten, als auch zu einer verstärkten Komplexität der Konfiguration dieser somit doppelt ausgelegten Softwarekomponenten. Auf lange Sicht führt die Interopera- bilität jedoch zu einer Minimierung der Abhängigkeiten. Es existieren aufgrund der unterschiedlichen Einsatzländer noch weitere Abhängigkeiten, wie z.B. im Bezug auf regional unterschiedliche Sonderzeichen (vgl. Dänemark) oder unter- schiedlicher automatischer Ansagen im Zug bezogen auf den Ort oder die Zug- fahrstrecke (Vgl. S-Bahn). Ein weiteres Beispiel sind unterschiedliche elektrische Spannungsversorgungen durch die Oberleitung, z.B. Gleichstrom in Südfrank- reich und Wechselstrom im Norden und auf allen Schnellfahrstrecken [Wik07c].
Diese grundlegenden Arten dienen als Ausgangsplattform für die weitergehende Analyse. Problematisch hierbei ist, dass eine genaue Auflistung aller relevanten Arten von Abhängigkeiten in einem einzigen Iterationsschritt nicht durchführbar ist. Darüber hinaus stellt selbst eine vermeintlich vollständig abgebildete Menge immer nur einen zur Zeit gültigen Ausschnitt und keine vollumfängliche allgemeingültige Menge dar. Dies ist darin begründet, dass sich Rahmenbedingungen und Sichtweisen verschieben können: Bislang vernachlässigte Aspekte können akut werden oder bislang wichtige Abhängigkeitsarten können gänzlich verschwinden.
3.3 Klassifikation
In Abbildung 3.3 findet sich eine Übersicht der verschiedenen Möglichkeiten, die nachfolgend nun erläutert und anhand eines konkreten Praxisbeispiels der Deutschen Bahn AG belegt werden sollen.
Schichtung
Bei der Einteilung der Abhängigkeiten in verschiedene Klassen lassen sich diese auch anhand ihrer Schichtung unterscheiden. Hierbei gilt es zu unterscheiden, welche Beziehungsarten auf horizontaler Ebene (z.B. Kardinalitäten) oder auf vertikaler Ebene (z.B. Hierarchieebenen) existieren.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.3: Klassifikationsmöglichkeiten
Abhängigkeiten lassen sich nach ihrer Gewichtung ordnen. Jede Beziehung zwischen zwei Entitäten wird hierbei unterschiedlich schwer bewertet („gewichtet“). Eine Be- wertung ist an den Kanten und an den Knoten möglich. Da eine Abhängigkeit per definitionem immer zwischen Entitäten stattfindet, ist für diesen Zweck nur eine Kan- tengewichtung sinnvoll. Diese Bewertung kann z.B. auf Grundlage des Mehraufwan- des im Bezug auf die Umsetzung, Mehrkosten, Sicherheitsrisiko, usw. stattfinden, muss jedoch für alle Objekte anhand derselben Kriterien erfolgen, um eine Vergleichbarkeit überhaupt erst ermöglichen zu können. Ob nun eine geringere Maßzahl einen besseren Stellenwert hat, als eine höhere, ist dann Definitionssache. Durch diese Klassifikation ist es möglich, eventuelle Wahlmöglichkeiten besser gegeneinander aufwiegen zu kön- nen. Diese Klassifikation ist der Theorie der gewichteten Graphen entlehnt [Dum01a], die z.B. auch beim Travelling Salesman Problem [ABCC98] Anwendung findet.
Relevanz
In einem Abhängigkeitsverhältnis sind beeinflussende Faktoren zwischen den jewei- ligen Komponenten denkbar („E2 hängt von E1 ab und beeinflusst E1 in folgender Weise...“). Aus diesem Grund können Abhängigkeiten auch nach Ihrer Relevanz ka- tegorisiert werden. Diese Einteilung hängt eng mit der Schadensfunktion[[1]] zusammen. Es ist denkbar, die Verletzung von Abhängigkeiten somit kalkulierbar zu machen.
- Harte Abhängigkeiten:
Analog zu Echtzeitsystemen („ Verletzung von Echtzeitkriterien “), kann eine Verlet- zung von Abhängigkeiten zu Fehlfunktionen und/oder Leistungsminimierungen führen. Daher wurden die Kriterien der „harten“ und „weichen“ Echtzeitsysteme, wie in [Sch05] beschrieben, auf Abhängigkeiten abgeleitet. Eine harte Abhängig- keit beschreibt ein Szenario, in dem die Abhängigkeit in keinem Fall verletzt wer- den darf. Eine Verletzung, wenn auch nur in geringem Umfang zieht erhebliche Folgen nach sich.
Hierbei müssen bei der Bewertung zwei Gesichtspunkte beachtet werden:
- Welche Kosten treten bei Verletzung der Abhängigkeit auf?
- Welche Kosten treten durch das Vorhandensein der Abhängigkeit auf?
- Weiche Abhängigkeiten:
Eine weiche Abhängigkeit bedingt ebenfalls eine Nichtverletzung der Abhängigkeit, jedoch unter dem Aspekt, dass unter einer zeitlichen Bedingung eine gelegentliche Verletzung tolerierbar ist. Als Folge sind meist diverse Abweichungen vom Idealzustand zu erwarten, wie z.B. Betrieb mit langsamerer Geschwindigkeit, eingeschränkte Funktionalität, Zeitverzögerungen etc.
In der Praxis wäre ein solcher Fall z.B. dann gegeben, wenn z.B. eine Software für das Fahrgastinformationssystem aufgespielt werden würde, die im Ausland nicht funktioniert und somit eine Abhängigkeit verletzt würde. Generell ist diese Ver- letzung zwar möglich, da die Schadensfunktion relativ niedrig ausfallen würde (Verärgerte Kunden, da keine Information über Fahrzeit, Reservierung nächster Halt, etc. möglich), jedoch ist dieser Zustand nicht gewünscht und zu vermeiden.
- Empfehlungen:
Neben diesen beiden Kriterien gibt es noch Relevanzkriterien, die nur Empfeh- 1 Der Begriff Schadensfunktion findet häufig im Hinblick auf Echtzeitsysteme Anwendung. Mit Hilfe einer Schadensfunktion wird versucht verschiedene Effekte, die einen Schaden gegenüber Dritten ver- ursachen (z.B. Sachschaden, Umweltverschmutzung, mangelnde Qualität, etc.) monetär zu bewerten und somit vergleichbar zu machen. lungen darstellen. Die Einhaltung einer derartigen Abhängigkeit wäre zwar wün- schenswert („wenn möglich“) ist jedoch nicht zwingend erforderlich. Dies ist im- mer dann sinnvoll, wenn eine Einhaltung im Nachgang weitere Konfigurations- schritte wesentlich vereinfachen würde. Als Beispiel ließe sich hierfür aufführen, dass z.B. eine Entität E1 priorisiert mit E2 zu kombinieren wäre, da somit die Er- füllung der Abhängigkeit zur Entität E3 automatisch gegeben wäre. Jedoch ist auch eine Kombination von E1 mit der Auswahlkomponente E20 anstatt E2 ohne Probleme möglich.
Eine Empfehlung wäre im konkreten Anwendungsfall dann gegeben, wenn z.B. ein Hersteller eine Versionsempfehlung gibt: „Version 2.4 von FIS empfiehlt eine Version von ZEUS (Zentrale Einrichtung zur Überwachung und Steuerung)“, die mindestens der Version BT019 entspricht. Hierbei spielt die Schadensfunktion keine Rolle, da auch jede andere zulässige Versionskombination möglich wäre und durch die Verletzung einer Empfehlung kein Schaden entstehen würde. Die Empfehlung existiert aber, weil z.B. die empfohlene Kombination in besonderem Maße schnell oder zuverlässig funktioniert.
Die oben dargestellte Unterteilung wurde in ähnlicher Form auch von [Bur05] vorge- schlagen. Hierbei wurden aber Empfehlungen und weiche Abhängigkeiten als äquiva- lent betrachtet.
Herkunft
Hierbei sind drei Einflussgruppen zu nennen: Die Deutsche Bahn AG selbst, die jewei- ligen Hersteller der Software oder Hardware und die Behörden, mitsamt rechtlicher Rahmenbedingungen und Gesetze. Diese Gruppen sind insoweit gut als Klassifizie- rungsmerkmal geeignet, als dass somit klar wird, wer als Urheber dieser Abhängig- keitsthematik dient und im Bezug auf die Auflösung von Abhängigkeiten auf einer höheren Ebene als Ansprechpartner in Frage kommen kann. Da hierbei auch unter- schiedliche Interessengebiete aufeinander treffen, entstehen hier auch Abhängigkeiten zwischen den jeweiligen Interessengruppen, sodass eine Einordnung nicht ganz klar erfolgen kann.
Beherrschbarkeit
Auf einer abstrakten Ebene lassen sich Abhängigkeiten grundsätzlich nach Ihrer Be- herrschbarkeit und Sichtbarkeit klassifizieren. Diese Klassifizierungsstufe kann dann in weitere Einordnungsebenen in Form eines Breitenaspekts zusätzlich eingezogen wer- den. Bei diesem Attribut handelt es sich grundsätzlich um die Fragestellung, inwieweit eine Abhängigkeit überhaupt als sichtbar und damit beschreib- und klassifizierbar gilt. In der Theorie der objektorientierten Softwareentwicklung gibt es eine ähnliche Pro- blemstellung. Nach [LR06] sind implizite Abhängigkeiten schwerer handhabbar und erkennbar. Dies erschwert die Wartbarkeit der Software. Diese versteckten Abhängig- keiten sind im Bereich der Objektorientierung dadurch begründet, dass in Software- systemen - direkt im Code - Wiederholungen und Redundanz im Bezug auf die Funk- tionalität existieren. Übertragen auf das Themenfeld der Konfiguration von Software und den damit verbundenen Abhängigkeiten, bedeutet dies, dass durch implizite Ab- hängigkeiten auch die Wartung der Softwarekonfiguration erschwert wird. Folgt man [AW02], so werden hier implizite Abhängigkeiten als diejenigen bezeichnet, die kei- ne direkte Kommunikation (Methodenaufruf, Datenaustausch, etc.) zwischen Kompo- nenten bedingen, sondern aus einer tieferen Schicht stammen und z.B. das Schedu- ling oder die Speichernutzung betreffen. Diese Definition von impliziten Abhängigkei- ten begründet somit auch die schwerere Sichtbarkeit dieser, da keine offensichtliche Kommunikation stattfindet. Explizite hingegen sind offensichtlich erkennbar oder aus- drücklich beschrieben, sodass diese klar in die jeweilige Analyse der Konfiguration einbezogen können.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.4: Implizite / Explizite Abhängigkeiten
Im Hinblick auf implizite Abhängigkeiten ist zu beachten, dass Zyklen entstehen können. Eventuell werden hierbei sogar Problemstellungen analog eines Deadlocks (vgl. [Bra03]) aufgeworfen, die es zu berücksichtigen gilt.
Ein Beispiel für derartige Abhängigkeiten, wird in Abbildung 3.4 dargestellt. Neben der nach außen sichtbaren Abhängigkeit von Methode A und B, gibt es noch eine implizite (versteckte) Abhängigkeit in Form einer globalen Variablen, die beide Klassen nutzen.
Alternative Auswahl
Eng mit der Thematik der Relevanz hängt die Bewertung nach der möglichen Auswahl zusammen. Als Grundlage hierfür muss gegeben sein, dass es eine Alternativauswahl zwischen mindestens zwei Entitäten in einem Abhängigkeitsverhältnis gibt. Hierbei lassen sich zwei grundlegende Unterteilungsmöglichkeiten nennen:
- Gleichwertig:
Im Bezug auf die Gleichwertigkeit bedeutet dies, dass Abhängigkeiten existieren, bei denen zwei oder mehr Entitäten eine gleiche Stellung besitzen. So ist zwar eine Abhängigkeit gegeben, jedoch mit einer freien Wahlmöglichkeit zwischen den möglichen Alternativen. Bei einer Darstellung als gerichteter Graph hätten dann die jeweiligen Kanten jeweils identische Gewichtungen. Die Gleichwertig- keit kann aber auch nur auf eine Entitätsebene beschränkt sein, sodass die je- weiligen Entitäten zwar auf der aktuell gültigen Ebene zwar gleichwertig wären, jedoch im Nachgang sich aber dann je nach Auswahl weitere Vor- und Nachteile ergeben könnten.
- Konkurrierend:
Im Gegensatz zur gleichwertigen Auswahl ist bei konkurrierenden Abhängigkei- ten jeweils ein Pfad besser geeignet, als ein anderer und von daher in der Aus- wahl beschränkt. Die Kanten hätten dann jeweils unterschiedliche Gewichte. Wo- bei aber auch hier dieser Sachverhalt auf eine Ebene beschränkt sein kann.
[...]
- Quote paper
- Stephan Hüwe (Author), 2007, Entwurf eines Systems zur Verwaltung und Darstellung der Abhängigkeiten von Schienenfahrzeug-Software, Munich, GRIN Verlag, https://www.grin.com/document/83186
-
-
-
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X.