vergleich der spezifikationen für technische...

Fakultät Technik und InformatikStudiendepartment Informatik

Faculty of Engineering and Computer ScienceDepartment of Computer Science

Hochschule für Angewandte Wissenschaften Hamburg

Hamburg University of Applied Sciences

Bachelorarbeit

Karolina Bernat

Vergleich der Spezifikationen für TechnischeDokumentation, ATA iSpec 2200 und S1000D, mit

XML-basierter Transformation am Beispiel vonLuftfahrt-Dokumenten

Karolina Bernat

Vergleich der Spezifikationen für Technische Dokumentation,ATA iSpec 2200 und S1000D, mit XML-basierter Transformation

am Beispiel von Luftfahrt-Dokumenten

Bachelorarbeit eingereicht im Rahmen der Bachelorprüfung

im Studiengang Angewandte Informatikam Studiendepartment Informatikder Fakultät Technik und Informatikder Hochschule für Angewandte Wissenschaften Hamburg

Betreuender Prüfer: Prof. Dr. Michael NeitzkeZweitgutachter: Prof. Dr. Olaf Zukunft

Abgegeben am 24. August 2010

Karolina Bernat

Thema der BachelorarbeitVergleich der Spezifikationen für Technische Dokumentation, ATA iSpec 2200 und S1000D,mit XML-basierter Transformation am Beispiel von Luftfahrt-DokumentenStichworteS1000D, ATA iSpec 2200, Technische Dokumentation, strukturierte Dokumente, Manual,XML, XSL Transformation, DatenmodulKurzzusammenfassungDie Erstellung von technischen Dokumentationen im Bereich der zivilen Luftfahrt wird durcheinen internationalen Standard, die Spezifikation ATA iSpec 2200, geregelt. Die SpezifikationS1000D stellt einen weiteren, internationalen Standard zur Erstellung von technischen Doku-menten dar. Diese deckt jedoch eine Vielzahl von Anwendungsbereichen, über den Luftfahrt-bereich hinaus, ab. Im Rahmen dieser Arbeit werden Ähnlichkeiten und Unterschiede dieserbeiden Spezifikationen in einer Gegenüberstellung anhand ausgewählter Inhalte aufgedeckt.Desweiteren wird am Beispiel eines ATA iSpec 2200 Wartungsdokuments untersucht, ob In-halte mit Hilfe von XSLT automatisiert von ATA iSpec 2200 zu S1000D transformiert werdenkönnen.

Karolina Bernat

Title of the paperComparison of technical documentation specifications of ATA iSpec 2200 and S1000D withan XML-based transformation on the example of aviation documentsKeywordsS1000D, ATA iSpec 2200, technical documentation, structured documents, manual, XML,XSLT, data moduleAbstractThe creation of technical documents for the civil aviation sector is based on the ATA iSpec2200 specification, which is an international standard. The S1000D specification is anotherinternational standard for creating technical documentation. Except for civil aviation, thisstandard also encompasses other fields of application. The thesis includes a comparison ofthose specifications that will reveal their similarities and differences on the basis of selectedcontent. In addition, an analysis of a maintenance document will be conducted in order toverify whether ATA iSpec 2200 content can be automatically transformed into S1000D withthe assistance of XSLT.

Inhaltsverzeichnis

Abbildungsverzeichnis 1

Tabellenverzeichnis 2

Listings 3

1 Einleitung 41.1 Motivation und Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Inhaltlicher Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Grundlagen 62.1 Technische Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Erstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Kategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.4 Dokument-Lebenszyklus . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.1 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Spezifikationen für technische Dokumente . . . . . . . . . . . . . . . . . . 11

2.4.1 ATA iSpec 2200 (Revision 2006.1) . . . . . . . . . . . . . . . . . . . 112.4.2 S1000D (Issue 4.0) . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Analyse - Gegenüberstellung der Spezifikationen 203.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Datenverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Common Source Database - CSDB . . . . . . . . . . . . . . . . . . 213.2.2 Data Module - DM . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.3 ATA iSpec 2200 Standard Number Breakdown . . . . . . . . . . . . 283.2.4 Dokumente und Publikationen . . . . . . . . . . . . . . . . . . . . . 323.2.5 Externe Medien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.6 Datenaustausch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3 Inhaltsmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Inhaltsverzeichnis v

3.3.1 Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.3.2 Listen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.3.3 Hotspots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.4 Business Rules - BR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.4.1 BR Kategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.4.2 Business Rules Exchange - BREX . . . . . . . . . . . . . . . . . . . 51

3.5 Applicability (Effectivity) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.5.1 Effectivity in ATA iSpec 2200 . . . . . . . . . . . . . . . . . . . . . . 553.5.2 Applicability in S1000D . . . . . . . . . . . . . . . . . . . . . . . . . 563.5.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.6 Referenzen (Links) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.7 Warning, Caution, Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.7.1 Abbildung von Warnings / Cautions / Notes von ATA iSpec 2200 zuS1000D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.8 Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.8.1 ATA iSpec 2200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.8.2 S1000D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.8.3 Revisions-Highlighting . . . . . . . . . . . . . . . . . . . . . . . . . 643.8.4 Löschen von Revisionen . . . . . . . . . . . . . . . . . . . . . . . . 643.8.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4 Ausgewählte Aspekte der Transformation eines ATA iSpec 2200 Engine Manualszu S1000D 664.1 Dokumentaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.2 Überführung der ATA iSpec 2200 Engine Manual-Inhalte in S1000D Datenmo-

dule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.2.1 Informationsaufteilung auf der Pageblock-Ebene . . . . . . . . . . . . 684.2.2 Informationsaufteilung auf der Task-Ebene ohne Berücksichtigung der

Pageblock-Informationen . . . . . . . . . . . . . . . . . . . . . . . . 694.2.3 Informationsaufteilung auf der Task-Ebene mit Berücksichtigung der

Pageblock-Informationen . . . . . . . . . . . . . . . . . . . . . . . . 704.2.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.3 Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.3.1 Data Module Identification and Status Section . . . . . . . . . . . . . 714.3.2 Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5 Bewertung 785.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.2 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Inhaltsverzeichnis vi

Literaturverzeichnis 82

Abbildungsverzeichnis

2.1 Dokument-Lebenszyklus (nach Kissinger (2010)) . . . . . . . . . . . . . . . 82.2 XSL-Transformation (nach Bongers (2008)) . . . . . . . . . . . . . . . . . . 102.3 S1000D International Organization (nach ASD u. a. (2010)) . . . . . . . . . . 17

3.1 Traditional Document Creation (Continental DataGraphics Ltd. (2010)) . . . . 223.2 S1000D Data Creation (Continental DataGraphics Ltd. (2010)) . . . . . . . . 233.3 DM Struktur (nach Augsburger und Malloy (2009)) . . . . . . . . . . . . . . 243.4 DM Inhaltstypen (nach Augsburger und Malloy (2009)) . . . . . . . . . . . . 253.5 DMC Aufbau (ASD u. a. (2008)) . . . . . . . . . . . . . . . . . . . . . . . . 263.6 DMC: 17 Zeichen (ASD u. a. (2008)) . . . . . . . . . . . . . . . . . . . . . . 273.7 DMC: 41 Zeichen (ASD u. a. (2008)) . . . . . . . . . . . . . . . . . . . . . . 283.8 ATA Three Element Procedure Numbering System (nach Air Transport Asso-

tiation (2006)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.9 ATA Numbering System TOSS Breakdown (nach Fischer (2007)) . . . . . . . 293.10 S1000D Informationsauslieferung (nach Augsburger und Malloy (2009)) . . . 363.11 CALS-Table Model (nach Lufthansa Systems (2007)) . . . . . . . . . . . . . 453.12 Table Row (nach Lufthansa Systems (2007)) . . . . . . . . . . . . . . . . . 463.13 Nested List vs. Procedural Step . . . . . . . . . . . . . . . . . . . . . . . . 483.14 Business Rule Categories (ASD u. a. (2008)) . . . . . . . . . . . . . . . . . 513.15 BREX Ausschnitt (PDF-Fromat) (ASD u. a. (2008)) . . . . . . . . . . . . . . 543.16 Applicability: DM Abhängigkeiten (ASD u. a. (2008)) . . . . . . . . . . . . . 573.17 Caution (ASD u. a. (2008)) . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.18 Werte des issueType-Attributs (ASD u. a. (2008)) . . . . . . . . . . . . . . . 63

4.1 Engine Manual Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.2 Chapter Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.3 Konvertierung von Pageblocks zu Datenmodulen (nach Mayer (2010)) . . . . 684.4 Konvertierung der Tasks und Pageblock-Inhalten zu Datenmodulen (nach Mayer

(2010)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.5 Konvertierung von Tasks mit Pageblock-Inhalten zu Datenmodulen (nach Mayer

(2010)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.6 Data Module - Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.7 Task vs. Data Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Tabellenverzeichnis

2.1 ATA iSpec 2200 Architektur (Air Transport Assotiation (2006)) . . . . . . . . . 122.2 ATA iSpec 2200 Handbücher (Air Transport Assotiation (2006)) . . . . . . . . 14

3.1 ATA TOSS vs. S1000D DMC (Mayer (2010)) . . . . . . . . . . . . . . . . . . 313.2 Manualtypen-Einsatzbereiche vs. Informaiton Sets . . . . . . . . . . . . . . 333.3 Manualtypen vs. Information Sets . . . . . . . . . . . . . . . . . . . . . . . 353.4 Manual Front Matter Inhalte . . . . . . . . . . . . . . . . . . . . . . . . . . 373.5 Externe Medien-Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.6 Grafikelemente im Vergleich (Mayer (2010)) . . . . . . . . . . . . . . . . . 423.7 Nummerierte Listen im Vergleich . . . . . . . . . . . . . . . . . . . . . . . 473.8 Nicht nummerierte Listen im Vergleich . . . . . . . . . . . . . . . . . . . . 473.9 Referenzen (Mayer (2010)) . . . . . . . . . . . . . . . . . . . . . . . . . . 593.10 Abbildung von Warning, Caution und Note . . . . . . . . . . . . . . . . . . 60

4.1 Task Prerequisites vs. Preliminary Requirements . . . . . . . . . . . . . . . 744.2 Task vs Data Module - Inhalte . . . . . . . . . . . . . . . . . . . . . . . . . 75

Listings

3.1 BREX Ausschnitt (XML-Format) (ASD u. a. (2008)) . . . . . . . . . . . . . . 533.2 Effectivity - Code Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.3 REVST/REVEND Beispiel (Air Transport Assotiation (2006)) . . . . . . . . . 613.4 changeInlie Beispiel (ASD u. a. (2008)) . . . . . . . . . . . . . . . . . . . . 633.5 Delete anchor - ATA iSpec 2200 Beispiel (Air Transport Assotiation (2006)) . . 643.6 Delete Element - S1000D Beispiel (ASD u. a. (2008)) . . . . . . . . . . . . . 65

4.1 DM Identification and Status Section . . . . . . . . . . . . . . . . . . . . . . 72

1 Einleitung

1.1 Motivation und Problemstellung

Die Grundlage für diese Arbeit ist die Zusammenarbeit mit der Firma Lufthansa Systems.Einer von Schwerpunkten der Tätigkeiten der Lufthansa Systems liegt in der Erstellung vonSoftware-Lösungen für den Luftfahrtbereich und die Software-technische Unterstützung vonWartung, Reparatur und Überholung (MRO - Maintenance, Repair and Overhaul). Das The-ma dieser Arbeit basiert auf der Problematik der Handhabung von technischer Dokumentati-on im Bereich der zivilen Luftfahrt, die durch internationale Vereinbarungen geregelt wird. Diefür ein Flugzeug notwendigen Wartungsarbeiten werden anhand von technischer Dokumen-tation durchgeführt. Die Erstellung der Dokumentation ist eine Aufgabe des Flugzeugher-stellers bzw. der Hersteller der Subsysteme (z. B. Triebwerke) eines Flugzeugs. Der Aufbaudieser Dokumente ist durch eine Internationale Spezifikation für technische Dokumentati-on ATA iSpec 2200 standardisiert. Aufgrund der Ankündigung einiger Original-Equipment-Manufacturer (OEM) in Zukunft vermehrt Dokumentation nach Standard S1000D auszulie-fern, möchte Lufthansa Systems ihre Software-Systeme für die Unterstützung des neuenStandards erweitern. In diesem Zusammenhang ergibt sich eine Reihe von Problemstellun-gen, die untersucht werden müssen:

• welchen Ansatz verfolgt die Spezifikation 1000D

• welche Ähnlichkeiten gibt es zu ATA iSpec 2200

• wie kann Dokumentation nach ATA iSpec 2200 in S1000D konvertiert werden

• welche Auswirkungen auf die MRO-Prozesse hat die Einführung von S1000D

• welche Software-Systeme werden von der Einführung betroffen

• welche Anpassungen der Software-Systeme sind notwendig

1.2 Zielsetzung

Im Rahmen dieser Arbeit werden die ersten drei der oben aufgeführten Problemstellungennäher behandelt. Es wird eine Untersuchung der Konzepte und Eigenschaften der Spezifika-tionen ATA iSpec 2200 und S1000D durchgeführt. Diese werden in einer Gegenüberstellung

1 Einleitung 5

vorgestellt, um die Ähnlichkeiten und Unterschiede in der Konzeption sowie der Handhabungvon ausgewählten Inhalten technischer Dokumente zu verdeutlichen. Im Speziellen wird hierBezug auf ein ATA iSpec 2200 Engine Manual genommen. Dieses Wartungsdokument wirdmittels einer XSL-Transformation in S1000D Konstrukte überführt. Anschließend werden dieErgebnisse präsentiert und bewertet.

Die Auswirkung einer Auslieferung von S1000D-konformen Watungsdokumenten auf dieMRO-Prozesse werden im Rahmen dieser Arbeit nicht untersucht. Dieses würde eine gründ-liche Analyse der Prozesse erfordern und müsste in einer engen Zusammenarbeit mit einemMRO-Betrieb durchgeführt werden. Als Grundlage für derartige Untersuchungen können dieErgebnisse dieser Arbeit dienen.

Die Folgen der Einführung von S1000D-Dokumentation für bestehende Software-Systemezur Unterstützung der MRO-Prozesse sind ebenso kein Bestandteil dieser Arbeit. Die Not-wendigkeit des Einsatzes solcher Software-Systeme zur Handhabung von technischen Do-kumenten wird in Abschnitt 2.1 erläutert. Die Unterstützung der MRO-Prozesse wird u. a.durch Publishing-, Anzeige- oder Erfassungs-Software erreicht. Aufgrund der Komplexitätder betroffenen Systeme würde eine Untersuchung der notwendigen Anpassungen den Um-fang dieser Arbeit überschreiten. Die in dieser Arbeit behandelten Problemstellungen könnenjedoch ebenso als Grundlage für derartige Untersuchung genutzt werden.

1.3 Inhaltlicher Aufbau

Die Grundlagen, die dem besseren Verständnis der hier beschriebenen Themen dienen sol-len, werden im Kapitel 2 vorgestellt. Dazu gehört ein kurzer Überblick über die technischeDokumentation (siehe 2.1), gefolgt von einem Einblick in XML (siehe 2.2) und XSLT (siehe2.3). Im letzten Teil des Grundlagen-Kapitels werden die beiden betrachteten Spezifikationenfür technische Dokumentation, ATA iSpec 2200 und S1000D, vorgestellt (siehe 2.4).

Der Schwerpunkt dieser Arbeit liegt in der Analyse der Konzepte der beiden Spezifikationen.Eine Gegenüberstellung ausgewählter Konstrukte wird im Kapitel 3 beschrieben. Es wirdauf die Handhabung der Inhalte der Dokumente und deren Verwaltung eingegangen (siehe3.2). Weiterhin werden die verwendete Inhaltsmodelle vorgestellt (siehe 3.3). Desweiterenwird das Konzept der Business Rules in S1000D vorgestellt (siehe 3.4), sowie das durchbeide Spezifikationen unterstützte Applicability-Modell (siehe 3.5). Die Unterstützung vonReferenzen wird im Abschnitt 3.6 beschrieben. Zuletzt wird auf die Darstellung von Warnings,Cautions und Notes und deren Rolle in technischen Dokumenten eingegangen (siehe 3.7),gefolgt von Vorstellung der Revisions-Modelle in beiden Spezifikationen (siehe 3.8).

Die Ergebnisse der XSL-Transformation des Beispieldokuments von ATA iSpec 2200 zuS1000D werden im Kapitel 4 disskutiert und anschliessend im Kapitel 5 bewertet.

2 Grundlagen

2.1 Technische Dokumentation

Für einen Benutzer von elektronischen oder mechanischen Geräten ist es wichtig, derenFunktionsweise möglichst ausführlich zu kennen. Mit der Komplexität der Geräte steigt auchdie Notwendigkeit einer ausführlichen Beschreibung in Form einer Anleitung oder einesHandbuchs. Diese haben die Rolle eines Bindegliedes zwischen dem Benutzer und einemtechnischen Produkt. Technische Dokumentationen richten sich an eine spezielle Benutzer-gruppe, die bestimmte Erwartungen an die Dokumentation hat. Sie wird erzeugt unter derBerücksichtigung der Erfahrung, der Aufgaben, des Berufs, der Ziele und der Problemstel-lungen einer Zielgruppe (siehe Byrne (2006)). Nach diesen Kriterien werden Inhalte, An-satz, Aufbau, Detailierungsgrad, Stil, Terminologie etc. gewählt. Die Hauptaufgabe der tech-nischen Dokumentation ist die Hilfestellung beim Lösen von Problemen. Dem Benutzer sollnahe gebracht werden, wie z. B. ein Software-System funktioniert oder wie ein Teil einerMaschine aufgebaut ist.

2.1.1 Definition

Eine Definition von DUDEN lautet: „Technische Dokumentation ist eine, die Technik betref-fende, nach einer bestimmter Reihenfolge geordnete Zusammenstellung von Dokumentenund Sprachmaterialien jeder Art, die dadurch einem Nutzen dient und dazu geeignet ist, dasssie wie ein Beweis bewertet werden kann oder dass sie ein gut und allgemein verständlicheroder bildhaft vorstellbarer Beweis sein kann“.

2.1.2 Erstellung

Die Erstellung der Dokumentation hat das Ziel, den größtmöglichen Nutzen für den Endan-wender zu erzielen und dessen Anforderungen zu erfüllen. Eine Reihe von Personen ist inden Erstellungsprozess involviert:

• technische Autoren

• Illustratoren

2 Grundlagen 7

• Fachexperten

• Übersetzer

Dies deutet auf die Komplexität der erzeugten Inhalte hin, die wiederum zu der großen Viel-falt von benötigten Tools für den Umgang mit der Dokumentation führen. Die Verwendungeines einfachen Texteditors wird rasch an die Grenzen der Benutzbarkeit stoßen. Der Ein-satz spezieller Softwarelösungen in der Praxis ist unumgänglich, um das Erfassen komplexerInhalte mit Grafiken oder Multimedia-Daten oder das Publizieren in unterschiedlichen Aus-gabeformaten (z. B. PDF oder HTML) zu ermöglichen (Byrne (2006, S. 61)).

2.1.3 Kategorien

Folgende Kategorien lassen sich nach für technische Publikationen definieren (nach Byrne(2006)):

• prozedurale Dokumente (z. B. Anweisungen einer Montage oder Arbeitsweise)

• deskriptive und erklärende Dokumente (z. B. Beschreibungen der Produkte, der Be-dienung, Erklärung der Funktionsweise)

• Dokumente die der Überzeugung oder Bewertung dienen (z. B. Projektberichte)

• Forschungsdokumentation (z. B. Berichte, die neue Wissenserkenntnisse enthalten)

In dieser Arbeit wird prozedurale Dokumentation am Beispiel von Luftfahrt-Wartungsdoku-menten näher erläutert. Der Typ von prozeduralen, technischen Dokumenten, der die In-stuktionen beschreibt, ist der wahrscheinlich am häufigsten erzeugte (Byrne (2006, S. 63)).Wartungsdokumentation ist in der Gruppe der prozeduralen Dokumente nur ein Typ, der die-ser Kategorie unterliegt. Diese wenden sich an eine noch weiter spezialisierte Gruppe vonLesern, nämlich nicht zwingend den Benutzer eines Produkts, sondern an einen Ingenieurbzw. Techniker, der Wartungsarbeiten an einem Gerät durchführen möchte. Somit werdendie Inhalte zielgerecht erfasst und umfassen nicht die Bedienungsanleitung eines Produkts.Sie enthalten eine detaillierte Anleitung der zu durchführenden Wartungsschritte.

2.1.4 Dokument-Lebenszyklus

Dokumentation ist ein integrales Element eines Produkts. Mit der Produktentwicklung, verän-dert sich auch dessen Dokumentation. Die Anforderungsanalyse und primäre Erstellung sinddie ersten Schritte im Lebenszyklus eines Dokumentes. Diese umfassen die Konzeption undAufbereitung der Texte und Grafiken sowie der Seitengestaltung eines Dokumentes (Saffady(1997)). Das vollständige Dokument kann freigegeben und publiziert werden und den Nut-zern zur Verfügung gestellt werden. Falls Änderungen am Produkt entstehen, muss dessen

2 Grundlagen 8

Dokumentation revidiert werden. Eine grafische Darstellung der einzelnen Schritte des Le-benszyklus ist Abbildung 2.1 zu entnehmen. Das Einfügen der Neuerungen, Änderungenoder Kundenanforderungen gehört zu den Aufgaben der technischen Autoren im Revisions-zyklus. Danach wird das Dokument zur weiteren Nutzung freigegeben, ggf. in unterschiedli-chen Ausgabeformate publiziert und ausgeliefert. Weitere Änderungen können vom Geräte-hersteller selbst oder von den Benutzern angefordert werden, wodurch ein Revisionszykluserneut durchlaufen wird.

Abbildung 2.1: Dokument-Lebenszyklus (nach Kissinger (2010))

Der Revisionszyklus richten sich an der Häufigkeit der Änderungen, die am Produkt selberdurchgeführt werden oder er wird durch andere Abmachungen (z. B. vertragliche) geregelt.Solange ein Produkt im Gebrauch bleibt, muss seine Dokumentation gepflegt werden. In derLuftfahrtindustrie bedeutet das, dass Dokumente über Jahrzehnte gepflegt und somit aktuellgehalten werden müssen.

2 Grundlagen 9

2.2 XML

Die Extensible Markup Language (XML) ist eine Markup-Sprache, die von dem World WideWeb Consortium (W3C)1 etabliert wurde (Harold und Means (2004)). Eine einfache Syn-tax definiert menschenlesbare Tags, die als Beschreibung und Hervorhebung der Textin-halte dienen. XML dient als ein platformunabhängiges Datenaustauschformat (Vonhoegen(2005)). Ebenso wird es vewendet, um z. B. Vektor-Grafiken zu beschreiben, in der Pro-grammierung Objekt zu Serialisieren oder entfernte Prozeduren aufzurufen. Das sind nurwenige der Einsatzgebiete von XML. Die Wurzeln von XML liegen in der Standard Genera-lized Markup Language (SGML), die bereits seit 1969 als Beschreibungssprache eingesetztwurde. Diese war jedoch für den alltäglichen Gebrauch zu komplex und unflexibel.

Die Grundlage des XML-Markups stellt ein XML-Element dar. Für ein XML-Dokument wirdspezifiziert, welche Markup-Elemente erlaubt sind und wie sie zu benutzen sind oder wel-che XML-Attribute verwendet werden können. Durch die XML-Spezifikation werden Regelndefiniert, die es ermöglichen, beliebige XML-Daten mit Hilfe eines XML-Parsers einzulesen.Die Regeln legen fest, welche Elemente und in welcher Reihenfolge verwendet werden kön-nen, wie diese aufgebaut werden, wo Attribute platziert werden u. Ä. Ein XML-Dokument,dass all diesen Regeln gerecht aufgebaut ist, heißt wohlgeformt. Ein nicht wohlgeformtesXML-Dokument wird von einem XML-Parser nicht akzeptiert (Harold und Means (2004)).

Mit Hilfe von XML kann eine Dokument-Struktur beschrieben werden. In dieser wird defi-niert, welche Elemente verwendet werden dürfen und in welcher Beziehung diese zueinan-der stehen. Die Aufgabe von XML ist jedoch nicht das Beschreiben des Aussehens einesDokuments. XML enthält also keine Layout-Informationen eines Dokuments.

2.2.1 Schema

Die Regeln zum Aufbau der Struktur eines Dokuments können in einem Schema definiertwerden. Falls ein XML-Dokument allen in dem Schema definierten Regeln gerecht ist, ist esgültig. Die Gültigkeit eines Dokuments wird immer anhand eines Schemas geprüft. Es gibtmehrere Schema-Sprachen, mit Hilfe deren ein Schema definiert werden kann, z. B. (Haroldund Means (2004)):

• Document Type Definition (DTD)

• W3C XML Schema Language

• RELAX NG

• Schematron

1http://www.w3.org/

http://www.w3.org/

2 Grundlagen 10

• Hook

• Examplotron

Die meist verbreiteten Schema-Sprachen sind DTD und W3C XML Schema Language.

2.3 XSLT

Die im XML-Format vorliegenden Dokumente können mittels Extensible Stylesheet Langua-ge Tranformation verarbeitet und manipuliert werden. XSL ist eine standardisierte Sprachezur Informationsverarbeitung und gehört zur XML-Familie Bongers (2008). Die Erstellung derXSL-Stylesheets erfolgt ebenfalls im XML-Format. Durch diese Abhängigkeit wird XSLT fürdie Verarbeitung von XML-Daten gegenüber anderen Technologien bevorzugt.

Die Notwendigkeit der Handhabung von Daten im XML-Format wird durch wachsende Ver-breitung von XML immer größer Bongers (2008). Die Platformunabhängigkeit von XSLT-Stylesheets vereinfacht die Portierbarkeit. Zur Ausführung von XSL-Transformationen wirdein XSLT-Prozessor benötigt (z. B. Saxon2). Als Eingabe wird eine XML-Datei und ein XSLT-Stylesheet benötigt, aus denen eine Ausgabedatei erzeugt wird (siehe Abbildung 2.2).

Abbildung 2.2: XSL-Transformation (nach Bongers (2008))

Zusätzlich zur XSL wird in einem Stylesheet die Sprache XPath verwendet. Diese ermöglicht

2http://saxon.sourceforge.net/

http://saxon.sourceforge.net/

2 Grundlagen 11

es in einem XML-Dokumentbaum zu navigieren und eine beliebige Menge an Knoten undvorliegenden Informationen zu benennen.

2.4 Spezifikationen für technische Dokumente

2.4.1 ATA iSpec 2200 (Revision 2006.1)

ATA iSpec 2200 ist eine internationale Spezifikation für technische Dokumentation aus demLuftfahrtbereich. In der Spezifikation werden die Inhalte, die Struktur und der Austausch vonFlugzeugbau-, Wartungs- und Luftbetriebdokumenten spezifiziert. Der vollständige Namelautet „ATA iSpec 2200: Information Standards for Aviation Maintenance“. Die Spezifikationwurde von der Air Transport Association (ATA) entwickelt. Die US-amerikanischer Organisa-tion vereinigt über 20 Fluggesellschaften und mehr als 40 Industrie-Vertreter mit der Förde-rung eines ordnungspolitischen Umfelds für einen sicheren Lufttransport (siehe Air TransportAssociation (2010)).

2.4.1.1 Geschichte / Entstehung

Die erste Revision der iSpec ist im Januar 2000 erschienen. Als Basis für die Entwicklungdienten zwei bereits vorhandenen Spezifikationen der ATA, nämlich die „ATA Spec 100: Ma-nufacturers’ Technical Data“ und die „ATA Spec 2100: Digital Data Standards for AircraftSupport“. Diese Spezifikationen werden seit 1999 nicht mehr aktualisiert und wurden durchdie ATA iSpec 2200 abgelöst (Scholz (2002); Air Transport Association (2010)).

Die Dokumente, die an die Spezifikation angelehnt sind, gelten als strukturierte Dokumenteund werden im SGML-Format ausgeliefert. Die Strukturen, die zusätzlich zu dem eigent-lichen Inhalt des Dokuments erfasst werden, können den DTDs entnommen werden, diemit der Spezifikation geliefert werden. Für die meisten strukturierten Dokumente gilt, dasssie nicht in der Form verwendet werden, in der sie ausgeliefert werden. Das heißt, dassdie SGML-Dateien z. B. in das PDF- oder HTML-Format überführt werden müssen, bevorsie gedruckt oder durch Benutzer betrachtet werden können (André u. a. (1989)). In diesemProzess können bestimmte Informationen verworfen werden und das Dokument kann in vie-le einzelne Dokumente überführt werden. Das Verwenden von strukturierten Dokumenten istin Zusammenhang mit ATA iSpec 2200 sehr sinnvoll, da die Handhabung dieser Dokumen-te gegenüber von unstrukturierten Dokumenten viel einfacher ist. Strukturierte Dokumentewerden bevorzugt, da sie sich leichter verändern und warten lassen.

2 Grundlagen 12

2.4.1.2 Ziele

Die Hauptziele bei Verwendung von ATA iSpec 2200 sind die Kosten- und Aufwanderspar-nis, die bei anfallenden Arbeiten an Luftfahrzeugen und im Flugbetrieb entstehen, sowieeine Vereinfachung der Übername der Dokumentation durch die Airlines. Der Zeitfaktor so-wie Qualität der gelieferten Dokumente spielen ebenso eine wichtige Rolle und sollen nichtvernachlässigt werden. Es soll erreicht werden, dass die Informationen, die vom Anbieter(Hersteller) an die Betreiber (Fluggesellschaften, Wartungsbetriebe) gelangen, den betrieb-lichen Anforderungen des Luftfahrtbereichs sowie der Betreiber entsprechen.

In der Spezifikation werden Regeln für Struktur, Inhalt und Layout der Manuals festgelegt undGrafik-Layout, Informations- und Revisions-Kennzeichnung sowie Daten-Kommunikation be-stimmt. Für die meisten Wartungs-Manuals sind DTDs definiert, die die Struktur der Manualsabbilden.

2.4.1.3 Struktur

Die Gliederung der Spezifikation gibt einen guten Überblick über deren Umfang und kannder Tabelle 2.1 entnommen werden:

Tabelle 2.1: ATA iSpec 2200 Architektur (Air Transport Assotiation (2006))Chapter Chapter Titles DescriptionPreface General information on the

use and update/revision ofthis specification

Defines responsibility and accountability forthe use of the specification, contact infor-mation for comments or changes and doc-uments the revision specifics.

Chapter 1 Introduction to iSpec 2200 Defines the purpose of the specification, thecreation process, and the organization of theinformation.Describes future vision statements, state-ment of direction that meets the agreedTICC objectives and industry scope and re-lated value chains with process metrics.

Chapter 2 Requirements Defines the Business, Functional and Tech-nical Requirements for the Specification.

2 Grundlagen 13

Chapter Chapter Titles DescriptionChapter 3 Information Standards Groups information standards (properties

and domains) by the Primary BusinessFunctional Area to which they have a naturalaffinity. Information that falls into general useis placed in the Generic Resources area.

Chapter 4 Models and Schemas Addresses the what, how, and why ofreengineering business processes. Identi-fies the data model value chain analysis, themethodology and information design.Specifications for the various DocumentType Definitions (DTDs) including their re-spective structure charts.

Chapter 5 Media, Protocols and DataPackaging

Lays out the physical specifications for me-dia, data content (what is to be included onthe media) and the presentation.Retrieval Standards to provide software in-dependent access to information stored infull-text and graphics databases. Describesrequirements and guidelines for direct ac-cess.

Chapter 6 Annex 1 Provides a bibliography of external refer-ences including links to additional informa-tion

Anhand der zahlreichen Schriften lässt sich zusätzlich ein Eindruck über den Umfang deriSpec gewinnen. Insgesamt sind es über 25 Dokumente, die folgende Bereiche abdecken:

• Wartung des Flugzeugs

• Überprüfung der Flugzeugkonfiguration und Definition des Flugzeugs

• Ausbildung von Wartungspersonal

• Flugbetrieb

In Tabelle 2.2 wurden die Handbücher zusammengefasst:

2 Grundlagen 14

Tabelle 2.2: ATA iSpec 2200 Handbücher (Air Transport Assotiation (2006))Handbuch Abkürzung

Maintenance ProceduresAircraft Maintenance Manual AMMAircraft Recovery Manual ARMComponent Maintenance Manual CMMConsumable Products Manual CPMEngine Cleaning Inspection and Repair Manual CIREngine (Shop) Manual EMFault Reporting and Fault Isolation Manual FRM/FIMNon Destructive Testing Manual NDTPower Plant Buildup Manual PPBMService Bulletin SBStructural Repair Manual SRMWeight & Balance Manual WBM

Configuration Control of Product DefinitionAircraft Illustrated Parts Catalog AIPCComponent Maintenance Manual Parts List CMMIPLEngine Illustrated Parts Catalog EIPCEngine Parts Configuration Management Section EPCMPower Plant Buildup Manual Illustrated Parts List PPBMIPLTool and Equipment Manual TEMWiring Manual WM

TrainingSystem Description Section SDS

Flight OperationsFlight Crew Operations Manual FCOMMaster Minimum Equipment List MMEL

Universal ApplicationsComponent Manual Index CMIPublications Index PIService Bulletin Index SBIService Letter SL

In dieser Arbeit wird auf zwei Maintenance-Dokumente genauer eingegangen - das EngineManual (EM) und das Aircraft Maintenance Manual (AMM). Diese werden im Kapitel 3.2.4erläutert.

2 Grundlagen 15

2.4.2 S1000D (Issue 4.0)

Die Spezifikation S1000D ist eine internationale Spezifikation für technische Dokumentatio-nen. Der vollständige Name lautet „The International Specification for Technical PublicationsUtilising a Common Source Data Base - Specification 1000D“. Die Entstehungsgeschich-te greift zurück bis Mitte der Achtziegerjahre (siehe ASD u. a. (2010)). Für die Entwicklungwar anfangs die Association Européenne des Constructeurs de Matériel Aérospatial (AEC-MA) verantwortlich. Gemeinsam mit der European Defence Industries Group (EDIG) undder Association of the European Space Industry (EUROSPACE) hat AECMA die AeroSpaceand Defence Industries Association of Europe (ASD) gegründet. Die Organisation vereinigtdie meisten europäischen Länder zwecks einer Verbesserung der Wettbewerbsfähigkeit aufdiesem Gebiet.

2.4.2.1 Geschichte

Die Datumsangaben der Entwicklung von S1000D sind in den Quellen nicht einheitlich. Dieoben aufgeführten Daten beziehen sich auf die Angaben der Firma HiCo, die seit 2001 einVollmitglied der ASD und seit 2008 Mitglied des S1000D Steering Committees ist (HiCo undAviation Service Network (2009)) sowie auf die geschichtliche Einführung aus dem erstenKapitel der Spezifikation (ASD u. a. (2008)).

Die Arbeiten an der ersten Version der S1000D wurden 1989 abgeschlossen. Zu diesemZeitpunkt hat der Standard vor allem in der militärischen Luftfahrtindustrie eine große Ver-breitung gefunden (ASD u. a. (2010)).

Zur Untersuchung der Methoden und Praktiken, die der Handhabung von Dukumentation vonProjekten in der Luftfahrtindustrie dienen, wurde von der ASD die Documentation WorkingGroup (DWG) gegründet. Die Gruppe vereinte Vertreter aus der Industrie des europäischenRaums. Im militärischen Bereich wurden in den Achtzigerjahren unterschiedliche nationaleStandards verwendet. Es fehlte ein Standard, der eine internationale Anerkennung gewinnenkönnte. Die Bedeutung der Arbeitsgruppe, die Vertreter vieler Länder zusammengeführt hat,war deshalb umso größer. Die meisten Projekte aus dem zivilen Luftfahrtbereich wurden mitHilfe der ATA Spec 100, einer Spezifikation der Air Transport Association, realisiert. Dieseerfasst im Wesentlichen die Vorgaben für technische Dokumente in der Luftfahrtindustrie.Die ATA Spec 100 wurde zwar international verwendet, jedoch formal nicht als ein interna-tionaler Standard anerkannt. Anfangs wurde S1000D nur auf dem europäischen Gebiet undfür Projekte aus dem militärischen Bereich verwendet.

2.4.2.2 Ziele

Die Spezifikation formuliert folgende Ziele (ASD u. a. (2008)):

2 Grundlagen 16

• Kostenersparnisse bei der Erstellung und Instandhaltung technischer Dokumente

• Vermeidung von Redundanzen

• Ökonomische Planung des Supports

• Günstigere Dokumentauslieferung

• Vereinheitlichung der Standards der beteiligten Parteien in einem Projekt

• Standardisierung des Datenaustausches

• Verbesserung der Kompatibilität

• Nutzung von ASD Simplified Technical English (ASD-STE 100) und somit Vereinfa-chung und Vergünstigung einer Übersetzung

Eines der Hauptziele, die S1000D definiert, ist die Reduzierung von Duplikaten in den Doku-menten und somit bessere Möglichkeiten der Wiederverwendung von Informationen sowiemaschinelle Auswertbarkeit der Dokumente. Dieses soll unter anderem mit Hilfe von Da-tenmodulen (Data Modules, DM) erreicht werden (siehe auch 3.2.2). Ein solches Modul istdie kleinste, selbständige Dateneinheit, die in verschiedenen Dokumenten bzw. mehrmals ineinem Dokument wiederverwendet werden kann. Es enthält Informationen über z. B. Kompo-nenten, Materialien oder Systeme die eigenständig Sinn und Bedeutung haben, ohne dassweitere Informationen, außer Grafiken oder Multimedia-Daten, gebraucht werden. Ein Daten-modul muss auch in Verbindung mit weiteren DM-s in einer technischen Publikation integriertwerden können. Es ist keine bestimmte Größe für ein Datenmodul vorgegeben. Lediglich dieStruktur und Verwendung wird in der Spezifikation beschrieben.

DM-s werden im XML-Format erstellt, wobei frühere Versionen der Spezifikation auch SGML-Format zugelassen haben. XML-Schemata werden dafür vorgegeben.

2.4.2.3 Entstehung

An der Entwicklung der Version 2.0 der Spezifikation, die 2003 veröffentlicht wurde, hat sichdie amerikanische Aerospace Industries Association (AIA) beteiligt. Der Standard hat inter-nationale Anerkennung gefunden. Steigende Verbreitung hat zur Erweiterung des Standardsauf weitere Bereiche geführt, wie z. B. See, Land und Industrie im Allgemeinen. 2007 ist ATAder Weiterentwicklung von S1000D beigetreten. In der Version 3.0 wurde der Fokus stark aufdie Integration der ATA iSpec 2200 gelegt. Somit ist die Bedeutung der Spezifikation auchfür die zivile Luftfahrt gestiegen.

In dieser Arbeit wird Bezug auf die aktuelle Version 4.0 der Spezifikation genommen, die am01.08.2008 veröffentlicht wurde. An der Entwicklung dieser Version haben die ASD, AIA undATA gemeinsam mit ihren Kunden gearbeitet.

Die organisatorische Aufteilung der Zuständigkeiten bei der Entwicklung der Spezifikationgliedert sich folgendermaßen auf:

2 Grundlagen 17

• S1000D Council, der aus dem Memorial of Understanding zwischen den Organisatio-nen ASD, AIA und ATA entstanden ist. Die Aufgabe des Councils ist die Leitung undKontrolle der Entwicklungsarbeiten.

• S1000D Steering Committee, das Mitglieder von Nationen und Organisationen verei-nigt um deren gemeinsamen Interessen in der Spezifikation zu vertreten. Das SteeringCommittee hat unter anderem die Aufgabe Änderungen für die neue Revision zu ak-zeptieren oder zu verwerfen. Es ist jedoch verpflichtet sich dabei an die Anweisungendes Councils zu halten.

• Working Groups und Task Teams, die die täglichen Aufgaben an der Entwicklung undRevidierung der Spezifikation und der XML-Schemata durchführen.

Abbildung 2.3 zeigt die organisatorischen Strukturen um die S1000D.

Abbildung 2.3: S1000D International Organization (nach ASD u. a. (2010))

2.4.2.4 Struktur

Um die Spezifikation gut leserlich zu gestalten, wurde sie in neun Kapitel unterteilt, welcheim Bezug auf technische Dokumente die Themen Erzeugung, Verwaltung, Publikation und

2 Grundlagen 18

Lebenszyklus abdecken. Im Folgenden werden diese genannt und anschließend die Begriffeund Konzepte näher erläutert (ASD u. a. (2008)):

1. Introduction to the Specification.

2. Documentation Process.

3. Information Generation.

4. Information Management.

5. Information Sets and Publications.

6. Information Presentation/Use.

7. Information Processing.

8. SNS, Information and Learn Codes.

9. Terms and Data Dictionary.

In 1. Kapitel werden die Historie der Entwicklung von S1000D und allgemeine Informationenüber die Spezifikation vorgestellt. Außerdem werden der Anwendungsbereich, die Art derVerwendung und die Anforderungen von Änderungen erläutert.

Das 2. Kapitel gibt einen Überblick über den Dokumentationsprozess. Hier wird die Verwen-dung von Informationstechnik und der Bezug zu anderen Prozessen und Spezifikationenbeschrieben.

Kapitel 3 beschäftigt sich mit den Regeln, die für das Erstellen technischer Dokumente Gel-tung haben. Insbesondere wird hier auf Dokumente eingegangen, die auf Basis von Daten-modulen aufgebaut werden und eine Common Source Database zur Speicherung von Datenverwenden. Die Struktur der Datenmodule ist hier festgelegt. Die Aufgaben rund um das Ak-tualisieren der Datenmodule und Verwendung von Informationssets sind erläutert. Vorgehen,die der Qualitätssicherung beim Erstellen und Aktualisieren von Datenmodulen dienen, wer-den behandelt. Diese Informationen richten sich insbesondere an Autoren und Illustratoren.An dieser Stelle wird in der Spezifikation darauf hingewiesen, dass die vorgestellten Regelnmit Vorrang vor den XML-Schemata behandelt werden. Die Schemata erlauben an einigenStellen mehr, als es wörtlich im Text der Spezifikation festgelegt wurde, um die Schematamöglichst einfach und wartbar zu halten.

Unter dem Begriff Informationsmanagement versteht man die Adressierung, Speicherungund Handhabung von Informationsobjekten, wie Datenmodule, Illustrationen oder Publika-tionen. Dadurch wird die Erstellung und Benutzung von technischen Dokumenten in einemProjekt ermöglicht. Themen wie Struktur von Data Module Codes (DMC), Regeln für denAustausch, Aktualisierung und Verwaltung von Datenmodulen, Illustrationen und Publikatio-nen werden in Kapitel 4 der Spezifikation behandelt. Es wird beschrieben wie eine Com-mon Source Database (CSDB) eingerichtet werden kann, um Datenaustausch zu ermögli-chen. Der Weg, eine Versionskontrolle zu gewährleisten, ist hier vorgestellt. Detaillierte In-formationen zur Kodierung von Datenmodulen und der damit verbundenen Illustrationen und

2 Grundlagen 19

Multimedia-Informationen sind gegeben. Es werden Listen von Datenmodulen beschrieben,die für das Planen, Verwalten und die Kontrolle der CSDB erstellt werden. Weitere Aspekte,die hier behandelt werden, sind die Handhabung von Kommentaren für die Datenmoduleund Publikationen, eine Erläuterung des BREX-Datenmoduls und die Nutzung von ProcessData Modules oder die Verwaltung einer Umgebung, in der mehrere Kunden bedient wer-den sollen. Konzepte der Wiederverwendung und Optimierung von Informationen sind hiererläutert. Es wird ein Überblick über die Funktionalitäten eines Anwendbarkeitsmodells prä-sentiert, das sowohl in einfachen als auch sehr komplexen Anwendungsfällen Verwendungfindet.

Die Wartbarkeit und Bedienbarkeit eines Produkts im Konzept von S1000D hängt stark mitInformations-Sets und Publikationen von Dokumenten zusammen. Im 5. Kapitel werden die-se Themen behandelt und die Voraussetzungen für die Strukturen vorgegeben. Diese richtensich hauptsächlich an die Autoren, Illustratoren und Verwalter von technischen Dokumenten.

Für die Benutzung von seitenorientierten Publikationen sowie elektronischen interaktivenPublikationen, die der S1000D unterliegen, gelten bestimmte Regeln. Kapitel 6 beschreibtdiese und gibt eine Matrix der Funktionalitäten, die für die Publikationen erfüllt werden sollen.

Im 7. Kapitel werden die technischen Aspekte der XML Schemata, Grafiken und Notationenebenso wie die Voraussetzungen für den Datenaustausch, die Auflösung von Ressourcenund Anforderungen an die Software vorgestellt.

Standard Numbering System (SNS), Information Codes und dessen Nutzung im Data Mo-dule Code (DMC) sind im Kapitel 8 beschrieben.

Anschließend wurden im letzen Kapitel Begriffe und Abkürzungen sowie Erläuterungen derXML Elemente, die in der Spezifikation verwendet werden, in einem Glossar zusammenge-fasst.

3 Analyse - Gegenüberstellung derSpezifikationen

In diesem Kapitel werden die Konzepte der beiden betrachteten Spezifikationen in einer Ge-genüberstellung vorgestellt. Zunächst werden allgemeine Konzepte erläutert. Weiterhin wer-den Meta-Strukturen, die dem Aufbau und der Bereitstellung einer Dokumentation dienen,vorgestellt, wie z. B. Data Module Requirement List, Information Set, Common Source Da-tabase. Im Weiteren werden die Strukturen, die dem Erfassen der Dokumentinhalte dienen,beschrieben. Diese sind z. B. Datenmodule, Listen, Tabellen. Es wird auch auf die Handha-bung der Dokumentrevisionen sowie Widerverwendbarkeit der Inhalte in den Spezifikationeneingegangen.

3.1 Allgemeines

Beide der Spezifikationen, die in dieser Arbeit vorgestellt werden, werden für das Erstellenvon technischen Dokumentationen angewendet und haben somit eine Reihe von Ähnlichkei-ten, wie z. B. die Handhabung von strukturierten Dokumenten und Vorgaben für deren Auf-bau in Form von DTD oder XML-Schemata (Rey (2010)). ATA iSpec wurde jedoch spieziellfür den zivilen Luftfahrtbereich entwickelt und findet keine Verwendung in anderen Industri-en. Der Einsatz von S1000D ist nicht auf eine bestimmte Industrie eingeschränkt und kannfür diverse technische Dokumente als Anleitung dienen. Mit dem Beginn der Integration vonATA iSpec 2200 in der Version 3.0 von S1000D kommen die Ähnlichkeiten noch stärker zumTragen. Einige Konstrukte der iSpec wurden komplett in die S1000D aufgenommen (z .B. dasATA Nummerierungssystem oder die Typen der zu erzeugende Dokumente als InformationSets Typen die weiter in der Arbeit vorgestellt werden). Die historische Entwicklung der iSpecbringt jedoch einige Nachteile gegenüber von S1000D, wie z. B. der Fokus auf papierbasierteDokumente. Zwar können die Dokumente nach ATA iSpec 2200 auch im IETP-Format (In-teractive Electronic Technical Publication) verwendet werden, jedoch der Ursprung und einimmernoch weit verbreiteter Weg der Verteilung von technischen Dokumentation nach iSpecliegt in einem seitenorientiertem Ausgabeformat (PDF). S1000D setzt sehr stark auf die Er-zeugung, Nutzung und Austasch von Dokumenten in elektronischer Form und als interaktivePublikationen. Der modulare Aufbau von S1000D-Publikationen ist ebenso ein gravierender

3 Analyse - Gegenüberstellung der Spezifikationen 21

Unterschied zum Aufbau eines Manuals nach iSpec, das als eine zusammenhängende Dateierstellt und ausgeliefert wird. Die Modularisierung in S1000D fördert die Wiederverwendbar-keit und stellt einen großen Vorteil gegenüber der ATA iSpec 2200 dar.

3.2 Datenverwaltung

Ein sehr wichtiger Aspekt im Kontext der technischen Dokumentation ist das Informations-management. Die S1000D erwähnt sogar schon im Titel die Verwendung einer CommonSource Database, was andeutet, dass die Art der Verwaltung von Informationseinheiten einegroße Rolle spielt. Der ATA iSpec 2200 kann man keine Vorgaben zur Datenspeicherung ent-nehmen. Somit wird sich der nächste Teil ausführlich mit dem Konzept der Datenverwaltungnach S1000D mit Hilfe einer CSDB beschäftigen.

3.2.1 Common Source Database - CSDB

Die Spezifikation 1000D sieht vor, dass Publikationen aus einer definierten Menge von Da-tenmodulen erstellt werden. Es sind ausführliche Informationen darüber gegeben, wie dieDatenmodule adressiert werden sollen und wie sie abzuspeichern sind. Darüber hinaus istdie Handhabung von Informationen, also Datenmodulen, Illustrationen und Publikationen ineinem Projekt spezifiziert. Die Common Source Database ist das zentrale Element bei derDatenspeicherung. Es ist ein Werkzeug zur Datenverwaltung, mit dessen Hilfe alle Daten, diein einem Projekt benötigt werden um technische Publikationen zu erzeugen, abgespeichertwerden.

Zum Design und der Implementierung von CSDB äußert sich die Spezifikation nicht. Le-diglich wird die Datenstruktur der gespeicherten Objekte definiert, sodass diese von einerSoftwareimplementierung unabhängig bleiben. Die Objekte, mit Ausnahme von Illustratio-nen oder Multimediadaten, liegen im XML-Format vor.

Der Unterschied zu den traditionellen Methoden der Dokumenterzeugung wurde in den fol-genden Grafiken (3.1, 3.2) verdeutlicht.


Basic S1000D Comparison with Traditional Documentation Methods

© Continental DataGraphics Ltd. 2007 www.cdgl.com Tel: +44(0)1707 367700

Traditional Document Creation Departments working on similar data in isolation, data and effort are duplicated

S1000D Document Creation Departments share information in a Common Source Database. Documents are written as modular units (Data Modules) that facilitate document re-use.

Engineering Data

Maintenance Doc Department

Flight Operations Department

Illust. Parts List Department




Maintenance ManualFlight Ops Manual Illust. Parts List Manual

CSDB Common Source Database

Maintenance ManualFlight Operations Manual

Illust. Parts List Manual

Document Creation Document Creation Document CreationAnalysis of equipment, breaking it down to create modular units

Engineering Data

File StorageFile StorageFile Storage DM1 DM2 DM3 DM4

DM5 DM6 DM7 DM8

Data Modules

DM1 DM3

DM4

DM2DM1 DM1

DM4

DM3

DM3 DM4DM6

DM7 DM5

DM8

Manuals may contain duplicated information which could introduce errors. Document maintenance increases when equipment evolves as changes need to be made to each manual.

Common elements (shown here as DMs 1, 3 and 4) are repeated across three different manuals, but they are only created once. Future changes in one Data Module become replicated across all future manual revisions.

Publish

CreateCreate

Publish

Abbildung 3.1: Traditional Document Creation (Continental DataGraphics Ltd. (2010))


Basic S1000D Comparison with Traditional Documentation Methods

© Continental DataGraphics Ltd. 2007 www.cdgl.com Tel: +44(0)1707 367700

Traditional Document Creation Departments working on similar data in isolation, data and effort are duplicated

S1000D Document Creation Departments share information in a Common Source Database. Documents are written as modular units (Data Modules) that facilitate document re-use.

Engineering Data







Maintenance ManualFlight Ops Manual Illust. Parts List Manual

CSDB Common Source Database

Maintenance ManualFlight Operations Manual

Illust. Parts List Manual

Document Creation Document Creation Document CreationAnalysis of equipment, breaking it down to create modular units

Engineering Data

File StorageFile StorageFile Storage DM1 DM2 DM3 DM4

DM5 DM6 DM7 DM8

Data Modules

DM1 DM3

DM4

DM2DM1 DM1

DM4

DM3

DM3 DM4DM6

DM7 DM5

DM8

Manuals may contain duplicated information which could introduce errors. Document maintenance increases when equipment evolves as changes need to be made to each manual.

Common elements (shown here as DMs 1, 3 and 4) are repeated across three different manuals, but they are only created once. Future changes in one Data Module become replicated across all future manual revisions.

Publish

CreateCreate

Publish

Abbildung 3.2: S1000D Data Creation (Continental DataGraphics Ltd. (2010))


3.2.2 Data Module - DM

3.2.2.1 DM Grobstruktur

Ein Datenmodul besteht aus zwei Teilen. Im ersten, dem ID-Status-Teil, werden Metadatenfür die Identifizierung eines Datenmoduls gespeichert (z. B. Data Module Code (DMC), Ti-tel, Versionsnummer, Versionsdatum, verwendete Sprache), sowie Statusinformationen (z. B.Sicherheitsstufe, Verantwortliche oder Urheber, Anwendbarkeit, Qualitätssicherungsstatus,Aktualisierungsgrund). Für jedes Datenmodul ist die ID-Status-Struktur identisch. Im zwei-ten Teil werden die textuellen und grafischen Inhalte erfasst, die für einen Benutzer sichtbarsind. Der Aufbau ist Abbildung 3.3 zu entnehmen.

Abbildung 3.3: DM Struktur (nach Augsburger und Malloy (2009))

3.2.2.2 DM Inhaltstypen

Die Strukturen der erfassten Inhalte sind unterschiedlich, abhängig vom Inhalttyp des Da-tenmoduls. So werden auch, je nach Inhalt, unterschiedliche XML-Schemata verwendet. Eskönnen drei Gruppen von Inhaltstypen der DM-s definiert werden (Augsburger und Malloy(2009)). Diese gliedern sich wie in Abbildung 3.4 ein.


Abbildung 3.4: DM Inhaltstypen (nach Augsburger und Malloy (2009))

Dieser Aufbau der Datenmodule ermöglicht eine effiziente Speicherung in einer CommonSource Database (CSDB). Zur Identifizierung innerhalb der Datenbank (Primärschlüssel)wird der Data Module Code (DMC) benötigt, der im ID-Status-Teil des Datenmoduls ent-halten ist. Der DMC ist ein strukturierter und standardisierter Identifier. Durch den Codewird eine Namenskonvention für die Datenmodule festgelegt (siehe AIA Product Supportu. a. (2008)). Jedes einzelne Modul stellt eine Informationseinheit über einen bestimmtenSystemaspekt dar. Somit können in einem DM auch bestimmte Aufgaben oder die durchzu-führende Arbeiten beschrieben werden. Beispiele hierfür sind: der Ölwechsel eines Motors,eine Liste von Materialien die mit einer Aufgabe verbunden sind oder das Vorgehen bei ei-nem Testversuch. Der Name eines Datenmoduls ist semantisch mit der Namenskonvention,die in der Spezifikation beschrieben ist, verbunden. Auch bei Verwendung eines DM-s inunterschiedlichen Systemen oder Projekten, bleibt der Name erhalten. Solche Integrität istdurch eine Abhängigkeit des Identifikationscodes eines Datenmoduls und des Systems, zudem das DM gehört, in einem Data Module Code gewährleistet. Durch die Eingrenzung desInhaltstyps durch das XML-Schema sowie der Zugehörigkeit im System, die im DMC festge-halten ist, kann der im Datenmodul erfasste Inhalt eingegrenzt werden. Somit wird auch dieGröße eines Datenmoduls nicht beliebig ausgedehnt werden können.


3.2.2.3 Data Module Code - DMC

In Abbildung 3.5 wurde der Aufbau des Data Module Codes dargestellt.

S1000D-I9005-01000-00

ICN-AE-A-040300-0-C0419-00001-A-003-01

Fig 1 Generic structure of the data module code

A single project can require the use of multiple model identifiers in data module codes, which can contain an SNS with the same characters but with a different definition. The additional optional character, called the materiel item category code, within the SNS, shown in Fig 1, is used to indicate the different SNS. To avoid a complete renumbering of the data modules where multiple SNS are used it is allowable for the materiel item category code to be used where applicable. This means that it is not required to populate the data module code elements to a consistent length in such projects.

3.1 Data module code partitions Breakdown details for the three partitions "hardware identification", "information type" and "learn type" are given in Table 2, Table 3 and Table 4.

Table 2 Hardware identification

Breakdown Length

Model identification code 2 thru 14 alphanumeric characters

System difference code 1 thru 4 alphanumeric characters

SNS 1 (optional materiel item category code) plus 6 or 8 alphanumeric characters

System 1 (optional materiel item category code) plus 2 alphanumeric characters

Subsystem + sub-subsystem 2 (1+1) alphanumeric characters

Applicable to: All S1000D-A-04-03-0000-00A-040A-A

Chap 4.3

DMC-S1000D-A-04-03-0000-00A-040A-A_006-00_EN-US.doc 2008-08-01 Page 3

Abbildung 3.5: DMC Aufbau (ASD u. a. (2008))

In einem DMC können bis zu 41 alphanumerische Zeichen verwendet werden, wie in Abbil-dung 3.7 gezeigt. Mindestens müssen aber 17 Zeichen verwendet werden, was in Abbildung3.6 verdeutlicht wird. Folgende Informationen werden in dem DMC gespeichert:

• Model Identification Code

• System Difference Code

• Standard Numbering System

• Disassembly Code

• Information Code

• Item Location Code

• Learn Code

Der Model Identification Code (MI) beschreibt das Produkt, um das es sich handelt. Er bein-haltet auch alle verwandten Varianten des Modells.

Mit Hilfe des System Difference werden alternative Versionen eines Systems oder Subsys-tems identifiziert. Es wird dabei jedoch nicht auf die Identifizierung eines Typs, Models oderVariante eingegangen.

Mit dem Standard Numbering System ist eine standardisierte Art der Kodierung von techni-schen Informationen für ein Produkt vorgegeben (siehe Ericsson (2008)). Im DMC identifi-ziert der SNS die Stelle innerhalb des Materials oder der Ausstattung. Für die Luftfahrzeuge,Triebwerke und Ausstattung ist die SNS-Aufgliederung an die ATA-Chapter-Aufgliederungangelehnt (dazu mehr in 3.2.3) (siehe Augsburger und Malloy (2009)). Drei Gruppen von


Zeichen werden verwendet, um ein SNS zu erstellen. Diese entsprechen der Kodierung fürein System, Subsystem/sub-Subsystem und Baueinheit (Assembly). Die Spezifikation defi-niert eine Reihe von Standard Numbering Systems, die in diversen Bereichen (z. B. GeneralSea Vehicles, Support and Training Equipment) Anwendung finden. Diese können auch aufdie speziellen Bedürfnisse und Projektanforderungen angepasst werden.

Der Disassembly Code beschreibt für eine Baueinheit (Assembly) die Ausfall/Schadens-Bedingungen, auf die sich Wartungsinformationen beziehen.

In Datenmodulen können unterschiedliche Typen von Informationen abgelegt werden (z. B.für Betrieb, Wartung, Fehlermeldung). Der Information Code wird in einem DMC verwendet,um die verschiedenen Informationstypen zu identifizieren.

Die Situation, in der eine Information anzuwenden ist, ist ebenso durch einen Code beschrie-ben - der Item Location Code findet hier seine Verwendung.

Der Learn Code bezieht sich auf Human Performance Technology (HPT) bzw. Training DataModules und dessen Benutzung ist optional.

S1000D-I9005-01000-00

ICN-AE-A-040300-0-C0419-00002-A-003-01

Fig 2 Data module code for Product


Chap 4.3


Abbildung 3.6: DMC: 17 Zeichen (ASD u. a. (2008))


S1000D-I9005-01000-00

ICN-AE-A-040300-0-C0419-00002-A-003-01

Fig 2 Data module code for Product


Chap 4.3


Abbildung 3.7: DMC: 41 Zeichen (ASD u. a. (2008))

3.2.3 ATA iSpec 2200 Standard Number Breakdown

Das von ATA vorgegebene Nummerierungssystem für die technischen Dokumente wird füralle Manualtypen verwendet. Ziel hier ist das Standardisieren der Nummerierung für alleWartungsdokumente. Die Nummerierung wird jedoch nicht für das Benennen des Doku-ments, sondern zur Nummerierung der Dokumentteile verwendet und bezieht sich direkt aufbestimmte Bauteile eines Flugzeugs. Die Nummer ist aus drei Teilen aufgebaut, die eine Ab-grenzung des Materials in Chapter (System) - Section (Subsystem) - Subject (Unit) darstellt(siehe Abbildung 3.8). Diese Art der Nummerierung von Inhalten spiegelt die Aufgliederungder Struktur eines Flugzeugs wider. Die Nummer ist hierarchisch aufgebaut und deckt alleTeile eines Flugzeugs ab (siehe Fischer (2007)).

Abbildung 3.8: ATA Three Element Procedure Numbering System (nach Air Transport Asso-tiation (2006))


Die Chapter-Nummern nach ATA besitzen eine feste Zuordnung zu den funktionalen Berei-chen der durchnummerierten Produkte. So steht z. B Chapter 21 für „Air Conditioning“ oderChapter 33 für „Lights”. Die Inhalte aus dem jeweiligen Bereich sind in einem Manual nachATA iSpec 2200 immer im jeweiligen Kapitel erfasst (die Kapitelnummer ist fest einem Be-reich zugeordnet). Der Chapter-Teil der Nummer sowie der Sub-Subsection-Teil sind durchATA vorgegeben und müssen durch die Hersteller in Wartungsdokumenten eingehalten wer-den. Die zweite Ziffer der Sub-Subsection und Subject-Teil des Identifiers werden vom Her-steller definiert und beziehen sich auf bestimmte Teile des Produkts. Die Nummer insgesamtbildet einen Equipment Identifier, der herstellerbezogen eindeutig sein muss.

3.2.3.1 Task Oriented Support System (TOSS)

In einem Task-orientiertem Manual, wie z. B. EM oder AMM, wird ein logisches Numme-rierungssystem verwendet, um die Tasks und Subtasks innerhalb des Manuals zu ordnen(siehe Abbildung 3.9). Es ist eine weitergehende Art, die Dokumentinhalte zu strukturieren.Dadurch kann eine automatisierte Sortierung, der Aufruf und die Verwaltung der digitalisier-ten Daten erleichtert werden. Das TOSS System verwendet die ATA Chapter-Section-SubjectNummerierung und nutzt zusätzlich einen Function Code und Unique Identifier zwecks er-weiterter Identifizierung auf Task-Ebene.

Abbildung 3.9: ATA Numbering System TOSS Breakdown (nach Fischer (2007))

In einem Engine Manual nach iSpec wird für die Nummerierung der Tasks das Jet EngineMaintenance Task Oriented Support System (JEMTOSS) und für das Aircraft MaintenanceManual entsprechend das Aircraft Maintenance Task Oriented Support System (AMTOSS)angewendet, die jedoch denselben Aufbau aufweisen. Dieser ist in Abbildung 3.9 dargestellt.Der Hardware-Identification-Teil der Nummer ist durch den ATA-Chapter-Breakdown vorge-geben, gefolgt von einer dreistelligen Nummer für den Function Code und einer dreistelli-gen Sequence Number. Gemeinsam erzeugen die letzten sechs Stellen der TOSS-Nummer


den Task-Identification-Teil. Optional kann eine dreistellige Nummer (sechster Teil der Task-Identifizierung) angefügt werden, die die Attribute Configuration Letter (confltr) mit einer Stel-le und Variant Number (varnbr) mit zwei Stellen belegt. Das Verwenden dieser erweitertenNummerierungssysteme ermöglicht den Einsatz von Electronic Data Processing (EDP), al-so das Speichern, Verändern und Verwenden der digitalen Inhalte der Manuals. Die zusätz-lichen Nummern dienen der Identifizierung von Tasks, Subtasks und der Analyse dessenVoraussetzungen und beziehen sich auf den funktionalen Einsatz der nummerierten Inhalte(Tasks), im Gegensatz zu dem ATA-Chapter-Breakdown, der einer Hardware-Identifizierungdient.

3.2.3.2 Mapping von DMC auf AMTOSS/JEMTOSS

Das Überführen der Identifizierung der Manual-Inhalte mittels TOSS-Nummerierung kannnicht ohne bestimmte Annahmen durchgeführt werden. Als Ziel müssen die Eindeutigkeitdes DMC und die Vollständigkeit der übertragenen Informationen im Fokus bleiben. Das ATA-Nummerierungssystem gibt eine klare Aufteilung der Hardware- und Funktions-Identifizier-ung in Form von ATA-Breakdown und Task-Nummerierung vor. Diese ermöglicht auch dieLesbarkeit der Nummer und eindeutige Zuordnung zur Flugzeug-Hardware oder Funktion.Eine Analyse der Möglichkeiten zur Erhaltung dieser Trennung sowie der Lesbarkeit in dervorliegenden Form muss durchgeführt werden.

Um die Eindeutigkeit des DMC zu erhalten, muss entschieden werden, auf welcher Hier-archieebene des EM-Manuals die Aufteilung der Inhalte erfolgen soll. Hier gibt es mehrereAnsätze, die diskutiert werden können, z. B. Aufteilung der Inhalte auf der

• Chapter-Ebene

• Section-Ebene

• Subject-Ebene

• etc.

Bei der Entscheidung sollen

• der Umfang des gewählten Abschnittes, sowie

• die Eindeutigkeit der Abschnitts-Identifizierung

berücksichtigt werden. Die kleinste adressierbare Einheit des Engine Manuals wird durcheinen Task repräsentiert und eignet sich sehr gut für die Überführung in ein S1000D Da-tenmodul (siehe auch 4.2). Die Adressierung eines Tasks nach TOSS wurde im Abschnitt3.2.3.1 vorgestellt und kann folgendermaßen in ein Data Module Code überführt werden(siehe Mayer (2010)):


Tabelle 3.1: ATA TOSS vs. S1000D DMC (Mayer (2010))

ATA TOSS S1000D DMCChapter Number SNS System CodeSection Number [0] SNS Subsystem CodeSection Number [1] SNS Sub-Subsystem CodeSubject Number SNS Assembly CodeKeine Entsprechung Dissassembly CodeConfiguration Number (Pageblock) /Configuration Letter (Task)

Dissassembly Code Variant

Function Code Information CodeVariant Number Information Code VariantSequential Number Keine entsprechende Nummerie-

rung. Ggf. muss die Sequencegemappt werden (z. B. mit demInformation Code), um Eindeutigkeitzu gewährleisten.

3.2.3.3 Zusammenfassung

Nicht alle Elemente der Nummerierung lassen sich aufeinander abbilden. Die Abbildungder Hardware-Identifizierung durch ATA-Breakdown kann vollständig auf das SNS (Stan-dard Numbering System) des DMC abgebildet werden, da dieses Konzept vollständig indie S1000D aufgenommen wurde. Andere Teile der ATA-Task-Identifizierung, wie z. B. dieSequential Number, finden keine Entsprechung in den DMC-Strukturen. Andererseits bleibtein Teil des DMC, z. B. der Dissassembly Code, ungenutzt. Er spiegelt eine bestimmteFunktion wieder (die Ausfallbedingung eines beschriebenen Bausteins), die in der TOSS-Nummerierung nicht abgebildet ist und somit in dem DMC ungenutzt bleibt. Das Abbildeneines anderen Teil der TOSS-Nummer auf den Dissassembly Code (z. B. der Sequence,die keine Entsprechung im DMC hat) würde nur unwesentlich eine Verbesserung bieten, dadie funktionale Bedeutung dieser DMC-Stelle somit verloren gehen würde. Die Attribute desATA-Pageblocks bzw. Tasks „Configuration Number“ und „Configuration Letter“ können aufdie Dissassembly Code Variant abgebildet werden, da beide die Abweichung einer Bauein-heit wiedergeben.

Um eine Informationsverlust-freie Übertragung zu gewährleisten, muss die Sequential Num-ber, die keine direkte Entsprechung im DMC findet, ebenso in dem Code enthalten sein.Dieses kann durch ein Mapping der Sequence mit einer anderen Nummer im DMC realisiertwerden. Die Lesbarkeit der Sequence geht dadurch verloren, jedoch bleibt die Eindeutig-keit erhalten und die verlustfreie Informationsübertragung ist sichergestellt. Für eine nach-


trägliche Wiederherstellung der Sequence müsste eine maschinelle Auswertung des DMCerfolgen.

3.2.4 Dokumente und Publikationen

Wie in der Einführung zu ATA iSpec erwähnt (siehe 2.4.1.3), ist eine Vielzahl an Handbü-chern durch die Spezifikation definiert, die im Luftfahrtbereich Anwendung finden. Die diver-sen Manuals sind in übergeordnete Gruppen zusammengefasst (siehe Tabelle 2.2), je nachRahmen, in denen die Dokumente eingesetzt werden können. Die Spezifikation S1000D un-terscheidet keine Manualtypen. Hier werden lediglich Bereiche definiert, in denen Dokumen-te eingestuft werden können - die Information Sets. Diese werden im Folgenden erläutert.Weiterhin wird auf zwei Typen von Wartungsdokumenten nach ATA genauer eingegangen,das Aircraft Maintenance Manual (AMM) und das Engine (Shop) Manual (E(S)M).

3.2.4.1 Information Set

Ein Information Set ist eine definierte Information, die für einen bestimmten Bereich und einebestimmteTiefe (Autorensicht) gilt. Die Informationen werden in (mehreren) Datenmodulenausgedrückt, die in einer Common Source Database verwaltet werden. Die für ein Projektrelevanten Datenmodule werden in einer Data Module Requirement List (DMRL) zusammen-gefasst. Die Information Sets können grob in drei Bereiche unterteilt werden. Im Folgendenwird die Aufteilung der in S1000D definierten Information Sets Aufgelistet:

• Common Information Sets

– Crew/Operation Information

– Description and Operation

– Maintenance Information

– Wiring Data

– Illustrated Parts Data

– Maintenance Planning Information

– Mass and Balance Information

– Recovery Information

– Equipment Information

– Weapon Loading Information

– Cargo Loading Information


– Stores Loading Information

– Role Change Information

– Battle Damage Assessment and Repair Information

– Illustrated Tool and Support Equipment Information

– Service Bulletins

– Material Data

• Air Specific Information Sets

– Structure Repair Information

– Cross Servicing Information

– Engine Maintenance Information

– Power Plant Build-Up Information

– Engine Standard Practices

– Aircrew Information

• Land/Sea Specific Information Sets

– Crew/Operator Descriptive Information

– Crew/Operator Operation Information

– Crew/Operator Sequential Operation Information

– Crew/Operator Fault Detection, Isolation and Resolution Information

– International, National and Regulatory Scheduled Check Information

Die Common Information Sets können für alle technischen Dokumente eingesetzt werden,da sie allgemeingültig sind (ASD u. a. (2008)). Die luftfahrtspezifische Anwendung wird in denAir Specific Information Sets erfasst. Die übergeordneten, funktionalen Bereiche der Manualsin ATA iSpec 2200 würden folgendermaßen auf die S1000D Information Sets abgebildetwerden können (siehe Tabelle 3.2).

Tabelle 3.2: Manualtypen-Einsatzbereiche vs. Informaiton SetsATA iSpec 2200 S1000D

MaintenanceRequirements

• Common Information Sets - Maintenance Plan-ning Information


ATA iSpec 2200 S1000D

Maintenance Procedures • Air Specific Information Sets - Engine Mainte-nance Information

• Air Specific Information Sets - Engine StandardPractices

• Air Specific Information Sets - Structure RepairInformation

• Common Information Sets - Maintenance Infor-mation

Configuration Control ofProduct Definition

• Common Information Sets - Illustrated Parts Data

• Common Information Sets - Material Data

• Common Information Sets - Equipment Informa-tion

• Common Information Sets - Wiring Data

Training • Training

Flight Operations • Air Specific Information Sets - Aircrew Informa-tion

Eine weitere Abbildung wäre denkbar, indem man die Information Sets den einzelnen Ma-nualtypen gegenüberstellt. Für diesen Fall würde die Aufstellung in der Tabelle 3.3 zutreffen.Zwar definiert die Spezifikation 1000D weit mehr unterschiedliche Information Sets, als esManualtypen in der iSpec gibt, jedoch ist die S1000D auch auf vielen anderen Bereichenanwendbar und nicht auf die Luftfahrt beschränkt.


Tabelle 3.3: Manualtypen vs. Information Sets

ATA iSpec 2200 S1000DAircraft Maintenance Manual Common Information Sets -

Maintenance InformationEngine (Shop) Manual Air Specific Information Sets -

Engine Maintenance InformationFlight Crew Operations Manual Air Specific Information Sets -

Aircrew InformationService Bulletin Common Information Sets - Service

BulletinsWiring Manual Common Information Sets - Wiring

Dataetc...

Die durch Information Sets definierten Bereichestellen die funktionale Aufteilung der Informa-tionen für ein Projekt dar. Die für einen Benutzer lesbare Form wird im Publication Module(PM) (siehe 3.2.4.2) definiert und durch eine Publikation widergespiegelt.

3.2.4.2 Publication Module - PM

Das Grundprinzip der Datenerfassung nach S1000D besteht darin, dass Informationen inkleinen Einheiten erfasst werden (ASD u. a. (2008)). Das Zusammensetzen der einzelnenInformationseinheiten, der Datenmodule, in eine Publikation erfolgt mit Hilfe von Publikati-onsmodulen. So können Publikationen nach Vorschriften eines PM-s und mit Hilfe geeigneterSoftware z. B. in das PDF-Format oder in eine elektronische, interaktive Publikation (IETP)überführt werden. Die Publikation ist dann eine Zusammensetzung z. B. für den Kunden.Es ist eine Art vordefinierte Sicht auf die Informationen, überführt in eine menschenlesbareForm.

Ein PM ist auch ein Datenmodul. Es fasst alle Datenmodule zusammen, die eine Publikationenthalten soll, definiert den Inhalt und gibt die Struktur einer Publikation vor. Es kann Refe-renzen auf Datenmodule sowie auf weitere Publikationsmodule enthalten. Das XML-Schemafür Publikationsmodule ist vorgegeben.

In der Grafik 3.10 werden die Abhängigkeiten zwischen den unterschiedlichen Konstruktenvon S1000D, Datenmodulen, Information Sets und Publikationen verdeutlicht.


Abbildung 3.10: S1000D Informationsauslieferung (nach Augsburger und Malloy (2009))

3.2.4.3 Aircraft Maintenance Manual - AMM

In einem Aircraft Maintenance Manual (nach ATA iSpec 2200) wird beschrieben, wie einMechaniker das Flugzeug warten soll. Das Dokument gibt vor, welche Arbeitsschritte undOperationen durchgeführt werden müssen. Damit sind sowohl die Arbeiten im Vorfeld sowiein der Wartungshalle oder der Werkstatt gemeint (siehe Air Transport Assotiation (2006)).Das AMM wird in zwei Teilen erstellt. Im ersten Teil ist die System Description Section (SDS)enthalten. Diese beschreibt das System in vier Detaillierungsstufen: System, Sub-System,Section, Unit. Die Hauptkomponenten des Systems werden beschrieben sowie der Zweckim Allgemeinen. Des Weiteren wird hier auf die Funktionsweise und die Besonderheiteneingegangen. Im Folgenden wird die Beschreibung der einzelnen Units erfasst (Einbauort,Einbauweise, Funktionsweise, Handhabung). Im zweiten Teil des AMMs sind die Wartungs-anweisungen und -prozeduren beschrieben. Die Bereitstellung und Revision eines AMMserfolgt in einem einheitlichen Dokument.

3.2.4.4 Engine (Shop) Manual - E(S)M

Das Engine Manual (nach ATA iSpec 2200) enthält die technischen Informationen und Vor-aussetzungen, die es ermöglichen, Wartungsarbeiten an einem Triebwerk sowie allen Teilen,die im Zusammenhang mit einem Triebwerk eingesetzt werden, durchzuführen (siehe AirTransport Assotiation (2006)). Es wird dabei davon ausgegangen, dass das Triebwerk vom


Flugzeug entfernt ist. Ähnlich wie beim AMM wird das Engine Manual in zwei Teilen erstellt.Zunächst wird die System Description Section aufgeführt, danach folgen die durchzuführen-den Prozeduren. Optional kann zu dem EM ein weiteres Manual hinzugefügt werden, näm-lich das Engine Cleaning Inspection and Repair Manual (CIR). Dieses wird als Teil des EMbetrachtet. Das EM wird aber zu jeder Zeit als ein einheitliches Dokument vom Triebwerk-hersteller geliefert, unabhängig davon, ob das zusätzliche, optionale CIR-Manual mitgeliefertwird oder nicht.

3.2.4.5 Legal Notice

In einem Wartungsdokument nach ATA iSpec 2200 kann ein optionaler Teil Legal Noticeaufgeführt werden. Die dort beschriebenen Informationen beziehen sich beispielsweise aufUrheberrechte oder Einschränkungen bezüglich des Exports.

In der Spezifikation 1000D wird nicht explizit darauf hingewiesen, dass ein Dokument einensolchen Inhalt aufführen sollte. Am Beispiel der Spezifikation selbst, die nach eigenen Vor-gaben erfasst wurde, ist es erkennbar, dass Informationen zu den Urheberrechten in demAbschnitt „Copyright and User Agreement“ erfasst und am Anfang des Dokuments platziertwurden. Außerdem sind in diesem Ausschnitt Hinweise zum Nutzungsrecht sowie eine Ver-einbarung der Nutzung von S1000D aufgeführt.

3.2.4.6 Manual Front Matter

Informationen, die am Anfang eines Manuals erfasst werden, können dem Manual FrontMatter entnommen werden (siehe Air Transport Assotiation (2006)). Dieses bezieht sich aufbeide der hier beschriebenen Spezifikationen. In einem Manual nach ATA iSpec 2200 wirdManual Front Matter direkt nach der optionalen Legal Notice aufgeführt. Die Inhalte einerManual Front Matter wurden beispielhaft in Tabelle 3.4 dargestellt.

Tabelle 3.4: Manual Front Matter InhalteInhaltstyp Beschreibung iSpec S1000DLetter of Transmittal(Transmittal Letter)

Identifiziert die Seiten einer Revi-sion, die hinzugefügt bzw. entferntwurden. Gibt allgemeine Informatio-nen zu einer Dokumentrevision an.Informationen zum Vorkommen vontemporären Revisionen können hierebenfalls enthalten sein.


Inhaltstyp Beschreibung iSpec S1000DHighlights Fasst die Änderungen eines Doku-

ments/Datenmoduls seit der letztenRevision zusammen. Beschreibt dieRevisionen und Gründe für jede Re-vision, die für das freigegebene Do-kument/Datenmodul erfasst wurden

Title Page Die erste Seite eines Manuals. Ent-hält den Namen des Inhabers desDokuments, Dokumentnummer, denNamen und die Adresse des Herstel-lers.

Record of Revision /Change Record

Dient der Verfolgung von Revisions-informationen / dem Zustand jederindividuellen Kopie einer Publikation.

Service Bulletin List Enthält die Informationen über denaktuellen Status von Einbeziehungdes Service Bulletins (des Doku-ments des Herstellers mit Vorga-ben zu den Änderungen, Austauschvon Teilen, zusätzlichen Inspektio-nen/Checks u. Ä.). Listetet jedes Ser-vice Bulletin, dessen Revisionsnum-mer (falls vorhanden) und Datum, so-wie die Revision des Manuals auf, indem der Service Bulletin Effect ein-gefügt wurde. Falls keine Änderun-gen im Manual vorgenommen wur-den für die vorhandene Ausgabe desService Bulletin, wird „No Effect“ ein-getragen.

Table of Contents Das Inhaltsverzeichniss.

List of Figures(Illustrations)

Listet alle Illustrationen des Doku-ments/der Publikation auf.


Inhaltstyp Beschreibung iSpec S1000DIntroduction Enthält einführende Informationen zu

einem Dokument bzw. wichtigen Do-kumentstrukturen, z. B. erklären derOrganisation, des Inhalts und derMethoden/Art der Nutzung des Ma-nuals.

Nichtin derSpec.definiert,kannjedocherfasstwerden(sieheText derS1000D)

Deactivation/ReactivationIndex

Index von Prozeduren, sollte vomHersteller des Dokuments erstelltwerden.

List of Effective Pages Identifiziert jede Seite in einem seite-norientierten Dokument.

List of Effective TRs Identifiziert die temporären Revisio-nen eines Dokuments und derenStatus.

List of Effective DataModules

Listet alle Datenmodule einer Pu-blikation auf. Muss auch die IssueNumber und Datum der aktuellenPublikation enthalten.

List of Abbreviations Eine Auflistung der spezifischen Ab-kürzungen mit Erklärung.

List of Terminology Listet die speziellen Begriffe, die imDokument/in der Publikation verwen-det werden und deren Erklärung.


Inhaltstyp Beschreibung iSpec S1000DEffectivity Cross-Reference(List of Effective Aircraft) /ApplicabilityCross-Reference Table

Enthält Informationen zu diversenMethoden der Identifizierung vongrundlegenden Effectivity-Gruppenin einer Dokumentinstanz. Zusätzlichwird hier erklärt, in welcher Bezie-hung diese zu einander stehen.Enthält Informationen zu dem Statusder Eingliederung von Kundenände-rungen.

Customer OriginatedChange List

Enthält Informationen zu dem Statusder Eingliederung von Kundenände-rungen.

Die Tabelle enthält keine vollständige Liste der möglichen Elemente, die in einer Front Matteraufgeführt werden können. Die vollständige Auflistung kann den Spezifikationen entnommenwerden.

3.2.5 Externe Medien

In beiden der hier betrachteten Spezifikationen ist es vorgesehen, externe Medien an dieverfasste Dokumente bzw. Publikationen anzubinden. Hiermit sind beispielsweise Illustratio-nen bzw. Multimediadateien gemeint. In Tabelle 3.5 wurden beispielhaft erlaubte Medienfor-mate zusammengefasst. Die iSpec erwähnt zwar, dass es denkbar ist andere Medien alsIllustrationen in den Dokumentationen zu verwenden, dessen Austausch wird jedoch nichtspezifiziert.

Tabelle 3.5: Externe Medien-Vergleich

ATA iSpec 2200 S1000DIllustrationen

TIFF TIFFCGM CGM (recommended format for interchange)JPEG JPEGPNG PNG

MultimediaMP3 Audio (z. B. PLS, CDA, WAV, MP3, WMA)MPEG Video (z. B. FLA, AVI, MPEG)WRL 3D (z. B. CGR, DWF, WRL, X3D)PDF Diverse (z. B. PDF, DOC, XLS, PPS)


3.2.5.1 Illustrationen/Grafiken

Illustrationen werden in technischen Dokumenten verwendet, um z. B. vorhandene Text zuverdeutlichen, lange Erklärungen zu vermeiden, Informationen, die mit Hilfe von Text nichtvermittelt werden können, zu verdeutlichen oder auch als Vereinfachung bei mehrsprachigenTexten (siehe Augsburger und Malloy (2009)). Im Zusammenhang mit Illustrationen werdenHotspots, auch interaktive oder intelligente Grafiken genannt, verwendet (siehe 3.3.3) (AirTransport Assotiation (2006)).

ATA iSpec 2200 enthält die Voraussetzungen für die Verwendung von Grafiken. Diese umfas-sen die allgemeinen Voraussetzungen (z. B. Beschriftung, Typ), Voraussetzungen bezüglichdes Inhalts sowie funktionale Voraussetzungen (z. B. Positionierung, Blickwinkel). Weiter-hin werden Standards zum Grafik-Stil beschrieben. Zusammenhängende Grafiken werdenin einem Sheet ausgeführt (GRAPHIC-Element). Um eine konkrete Grafik zu identifizierenwird das SHEET-Element, das als Kind-Element von GRAPHIC auftreten kann, verwendet.Das Referenzieren einer konkreten Grafik-Datei wird mittels des GNBR-Attributes via Entity-Objekt realisiert (Neitzke (2002)). Zum Datenaustausch wird eine Graphics Declaration Filebenötigt, die die Basisinformationen über die Grafiken enthält. Somit bekommt man einelesbare Information über den Inhalt der Mediadateien.

Die Spezifikation 1000D beschreibt ausführlich, wie Illustrationen behandelt werde sollen,wie sie aufbereitet werden und wie sie kontrolliert werden können (siehe Augsburger undMalloy (2009)). Bereiche wie Präsentationstechniken, Symbole, Typ, Größe, Format von Il-lustrationen u. Ä. werden beschrieben. Angaben für das Layout können ebenso der Spezifi-kation entnommen werden. Entsprechend dem Data Module Code, der für das Benennen derDatenmodule verwendet wird, wird die Information Control Number (ICN) für das Kodierender Namen von Illustrationen, Multimediadaten oder anderen Daten, die an ein Datenmodulangehängt werden können, verwendet (siehe ASD u. a. (2008)). Dabei ist es unerheblich,in welchem Datenformat die Informationen vorliegen. Für die Speicherung in der Datenbankwird der ICN ebenso als Primärschlüssel verwendet.

Nach ATA iSpec 2200 können Illustrationen, die in einer Illustrated Parts List verwendet wer-den, in einem Figure-Konstrukt zusammen gefasst werden. Figure enthält neben den Illus-trationen auch textuelle Inhalte und hat eine Cointainer-Funktion für die Parts Data. S1000Dsieht ein Illustrated Parts Data Datenmodul vor, das ebenso die Daten und Illustrationen zu-sammenfasst. Das iSpec Figure würde in diesem Fall durch S1000D IPD Figure repräsentiertwerden.

Das Mapping der entsprechenden Elemente den beiden Spezifikationen wurde in Tabelle 3.6zusammengefasst.


Tabelle 3.6: Grafikelemente im Vergleich (Mayer (2010))

ATA iSpec 2200 S1000DGraphic FigureGraphic/Title Figure/TitleSheet Figure/GraphicSheet/Title kein entsprechendes KonstruktSheet/Gdesc Verwendung von Figure/Legend möglich

3.2.6 Datenaustausch

In diesem Abschnitt wird erläutert, welche Vorgaben die hier betrachteten Spezifikationenzum Austausch der erfassten Informationen machen. Dies gewinnt eine große Bedeutung,wenn die erzeugte Dokumentation nicht nur für den Eigenverbrauch durch den Herstellerverwendet werden soll, sondern z. B. an Kunden oder Geschäftspartner ausgeliefert werdenmuss.

Zum Austausch von Informationen beschreibt die iSpec die Möglichkeiten der Wege, auf de-nen die Daten ausgetauscht werden können und listet mögliche Optionen auf. Dem Senderund Empfänger stehen also mehrere Wege des Austausches zur Verfügung und eine Eini-gung muss zwischen den betroffenen Parteien erfolgen. Einige Ansätze sind beschrieben,z. B. der direkte Austausch über das Internet nach dem Pull- bzw. Push-Prinzip. Die Form, inder die Daten übergeben werden steht ebenso zur freien Wahl (z. B. CD-ROM, Mikrofiche,Archiv-Datei).

Die S1000D hat ein Konzept des Austausches von digitalen Daten in Form eines dateiba-sierten Austausches bestimmt und gesonderte Strukturen dafür vorgeschrieben. Die Basis-austauscheinheit liegt in einem Datenmodul vor. Ein Austauschpaket (Transferpaket) mussmindestens aus einer Data Dispatch Note (DDN) (siehe 3.2.6.1) und mindestens einem wei-teren Datensatz aus den folgenden Kategorien bestehen (ASD u. a. (2008)):

• ein oder mehrere Datenmodule, zugehörige Illustrationen, Multimediadaten oder an-dere Dateien

• eine oder mehrere CSDB Status List

• eine oder mehrere Data Module Requirements List (DMRL)

• eine oder mehrere Comment Forms und zugehörige Anhänge

• eine oder mehrere Publikationen oder SCORM-Inhaltspakete (auf diese wird in derArbeit nicht weiter eingegangen)

Für jede dieser Kategorien wurde ein Schema definiert (außer von CSDB Status List undDMRL, die dasselbe Schema verwenden). Namenskonventionen werden zwecks Vereinfa-


chung des CSDB-Imports beim Datentransfer verwendet. Somit besteht keine Notwendigkeitder Prüfung von Dateninhalten. Die Konventionen sind durch die Spezifikation vorgegeben.Es wird empfohlen, dass die DDN-Datei als erste in der Sequenz der ausgelieferten Datenaufgestellt ist. Eine Ordnerstruktur wird nicht verwendet. Zugelassen sind jedoch passendeTechniken der Datenkompression, z. B. ZIP. Im Folgenden werden die einzelnen Konstrukteerläutert.

3.2.6.1 Data Dispatch Note - DDN

Die DDN ist eine Art Lieferschein in Form eines Datenmoduls. Mit Hilfe dieses Konstruktswerden alle Datenmodule und Multimediadaten, die in einem Transferpaket mitgeliefert wer-den sollen, in einer Liste erfasst. Für die Erstellung dieses Datenmoduls ist ein Schemabereitgestellt. DDN definiert den Sender und Empfänger sowie den Inhalt der Lieferung.

3.2.6.2 Data Module Requirement List - DMRL

Für ein Projekt nach S1000D wird eine definierte Menge von Datenmodulen benötigt. AlleDatenmodule, die in einem Projekt verwendet werden, werden in der Data Module Require-ment List zusammengefasst. Die Liste hat eine unterstützende Rolle dei der Planung, Erstel-lung und Konfoguration des Projekts. Das Erstellen der Liste kann in in einer einheitlichenForm oder in Teilen erfolgen, die z. B. durch Vertragspartner erstellt werden und später zu-sammenzufügen sind. Folgende zwei Elemente stellen eine DMRL dar: die Identification andStatus Section und Data Module Requirement List Content. Im ersten Teil werden Statusin-formationen erfasst, wie z. B. die Adresse mit Informationen zur eindeutigen Identifizierunginnerhalb der S1000D Domäne. Der Content-Teil enthält eine Liste von Datenmoduleinträ-gen.

In einer Organisation bzw. für ein Projekt muss festgelegt werden, ob die DMRL, als Mecha-nismus der Spezifizierung und des Austausches der Informationen, zum Planen einer CSDBverwendet wird. Das Revisionsdatum einer CSDB muss ebenso passend gewählt werden(beispielsweise das Eingangsdatum oder der Verfallstag der Informationen oder ein ande-res, passendes Datum). Über die Verwendung der optionalen Elemente, die in der DMRLspezifiziert wurden, muss ebenso entschieden werden.

3.2.6.3 CSDB Status List

Der Status der Common Source Database für ein Projekt wird in der CSDB Status List be-schrieben. Die CSDB ist die Quelle aller Datenmodule, für die die jeweilige Firma oder Or-ganisation verantwortlich ist. Um Abweichungen innerhalb von CSDB-s der kooperierenden


Parteien zu vermeiden, wird es empfohlen, dass die beteiligten Parteien periodisch einenAustausch von Referenzlisten aller Datenmodule betreiben. Die CSDB Status List enthältgenau dieselben ID-Code-, Status- und Datenmoduleinträge wie die Data Module Require-ment List.


Beide Spezifikationen äußern sich zum Datenaustausch, jedoch wird das Thema mit sehrunterschiedlicher Relevanz betrachtet. S1000D gibt viel strengere Vorgaben und lässt nichtso viele Freiheiten zum Datenaustausch, wie ATA iSpec 2200. Dies kann sich dadurch posi-tiv auswirken, dass einheitliche Methoden geschaffen werden können, um die Informationenin bestehende Informationssysteme zu integrieren und den Datenaustausch möglichst au-tomatisiert durchgeführt werden kann. Dadurch, dass keine strenge Standardisierung desFormates der ausgetauschten Daten vorliegt, sind diverse Vorbereitungsschritte nach demEmpfangen der überreichten Daten notwendig. Durch die Freiheiten, die die iSpec zulässt,ist eine viel höhere Beteiligung von Personen beim Datenaustausch verschiedener Parteienerforderlich, was mit einem größeren Aufwand verbunden ist.


3.3 Inhaltsmodelle

3.3.1 Tabellen

Die Tabellarische Darstellung von Informationen wird in den Spezifikationen mittels Conti-nuous Acquisition and Life-cycle Support (CALS) Table Model realisiert. Dieses standardi-sierte Modell für die Erstellung der Tabellen in XML-Dokumenten wurde von der OASIS-Society (Organization for the Advancement of Structured Information Standards) definiert.Der Aufbau einer CALS-Tabelle wurde in Abbildung 3.11 dargestellt.

Abbildung 3.11: CALS-Table Model (nach Lufthansa Systems (2007))

Elemente, die optional aufgeführt werden können, wurden mit einem ’?’-Symbol markiert,z. B. der Titel bzw. Fußnote einer Tabelle. Elemente, deren Vorkommen erforderlich ist unddie eine minimale Tabelle darstellen, sind:

• Table

• Table Group

• Table Body

• Row


Zu den Inhalten, die in einer Tabelle vorkommen können, gehören unter anderem:

• Grafiken

• Listen

• Warnings, Cautions, Notes

• weitere Tabellen

Diese werden in dem Entry-Element der Table Row eingeschlossen (siehe Abbildung 3.12)oder durch die Fussnote umklammert.

Abbildung 3.12: Table Row (nach Lufthansa Systems (2007))

Die Konvertierung von Tabellen eines Engine Manuals in S1000D Strukturen eines Daten-moduls ist durch das Verwenden eines gemeinsames CALS-Table Model Standards leichtumsetzbar. Bei der Konvertierung der Tabelleninhalte, wie Grafiken oder Listen, muss aufdie Kompatibilität geachtet werden, jedoch können die Strukturen der Tabellen aufeinanderabgebildet werden.

3.3.2 Listen

Die Darstellung von Manual-Inhalten in Form von Listen ist in beiden hier betrachteten Spe-zifikationen möglich. Unterschiedliche Möglichkeiten der Abbildung sind möglich und diesewerden im Folgenden erläutert.

3.3.2.1 Nummerierte Listen

Listen, die eine Nummerierung der Listenelemente zulassen, werden in der ATA iSpec 2200durch das Element <numlist> und in S1000D mit dem Element <sequentialList>gekennzeichnet, die Listenelemente jeweils mit <numlitem> und <listItem>. In derTabelle 3.7 wurde eine Gegenüberstellung der Listeninhalte von ATA iSpec 2200 und S1000Dzusammengefasst.


Tabelle 3.7: Nummerierte Listen im Vergleich

ATA iSpec 2200 S1000Dnumlist sequentialListkeine Entsprechung titlenumlitem listItempara note / para

Das Listenmodell von S1000D bietet gegenüber dem Modell der iSpec keine wesentlichenVorteile und die Abbildung kann an dieser Stelle einfach durchgeführt werden.

3.3.2.2 Nicht nummerierte Listen

Informationen, die in einer beliebigen Reihenfolge aufgelistet werden können, werden inForm von nicht nummerierten Listen dargestellt. Eine Gegenüberstellung der Modellelemen-te wurde in Tabelle 3.8 zusammengefasst.

Tabelle 3.8: Nicht nummerierte Listen im Vergleich

ATA iSpec 2200 S1000Dunlist randomListkeine Entsprechung titleunlitem listItempara note / para

Eine Abbildung der nicht nummerierten Listen lässt sich zwecks Konvertierung gut realisie-ren. Einige Attributwerte der EM-Listen (z. B. ’bulltype’) finden jedoch keine Entsprechungin den Attributen der Listen des S1000D Listenmodells und können somit nicht übertragenwerden.

3.3.2.3 Verschachtelte Listen

Verschachtelte oder hierarchische Listen beinhalten eine Reihe von geordneten Listen-Itemseiner bestimmten Ebene N. Diese wiederum können Listen der Ebene N+1 enthalten und so-mit eine Hierarchie darstellen. In ATA iSpec 2200 kann die Verschachtelung maximal bis zursiebten Ebene fortgesetzt werden. Die Spezifikation 1000D hat an dieser Stelle keine Be-grenzung, da die Verschachtelung mit stets demselben Element (<proceduralStep>)erfolgt. Dieses Element stellt weiterhin einen Arbeitsschritt einer Prozedur dar und hat somiteine doppelte Rolle. Abbildung 3.13 stellt das Inhaltsmodell einer verschachtelten Liste dar.


Abbildung 3.13: Nested List vs. Procedural Step

Die Inhalte eines List-Items können, neben der verschachtelten Liste, folgende sein:

• Warnings, Cautions

• Tabellen

• Weitere (nummerierte bzw. nicht nummerierte) Listen

• Referenzen

• Grafiken


Das Übertragen der Listen von ATA iSpec nach S1000D kann auf der Element-Ebene ohneweiteren Hindernisse durchgeführt werden. Einige Attribute können nicht aufeinander abge-bildet werden und werden bei der Konvertierung nicht berücksichtigt, was einen Datenverlustan dieser Stelle bedeutet.

3.3.3 Hotspots

Benutzer von interaktiven elektronischen Dokumentationen erwarten, dass beim Klicken aufeinen bestimmten Teil der Illustration, eine bestimmte Aktion ausgeführt wird. Dies erlaubt


z. B. das Erstellen von Verweisen zu einer Stelle in einer oder mehreren Grafiken, Verweisenvon Grafiken zur textuellen Inhalten oder zwischen der Grafiken (siehe Ericsson (2008)). Hin-weise zur Handhabung von interaktiven Grafiken können beiden Spezifikationen entnommenwerden.

ATA iSpec 2200 beschreibt die funktionalen Voraussetzungen für interaktive (intelligente)Grafiken. Diese werden im Zusammenhang mit Textinhalten vorbereitet und verwendet. Fol-gende Funktionalitäten werden in dem Zusammenhang gewährleistet: Navigieren (z. B. vonder Grafik zum Text), Abfrage (z. B. bei der Suche nach Attributen einer Grafik), Datenex-traktion (z. B. Zugriff auf die unsichtbaren, nicht-grafischen Inhalte einer Grafik) und Analyse(z. B. Benutzung physikalischer Eigenschaften, die mit einer Grafik verbunden sind, um Si-mulationen oder Analyse zu ermöglichen). Ebenso wird spezifiziert, welche Informationendie Grafiken enthalten sollen. Begleitend zu den interaktiven Grafiken wird von der iSpeceine Companion File definiert, die zusätzliche Metainformationen über die Struktur und In-halt von Grafiken beschreibt. In dieser Hinsicht wird die Interaktivität und Funktionalität inBetracht gezogen. Eine DTD für diese Datei ist vorgegeben und ein Linking-Mechanismuszwischen den Grafiken und den begleitenden Inhalten wird ebenso beschrieben (siehe AirTransport Assotiation (2006)).

Interaktive Grafiken (Hotspots) werden auch durch die S1000D beschrieben und unterstützt.Die Definition erfolgt über das XML-Element (Markup) <hotspot>, dass die Verbindungzwischen den Grafiken bzw. zwischen Grafik und Text darstellt und alle für das Navigierenbenötigten Informationen enthält. Das Element wird mit diversen Attributinformationen verse-hen. Die Verweise können sowohl von Grafiken zu Grafiken oder anderen Objekten führen,als auch umgekehrt. Weiterhin ist es möglich zwischen unterschiedlichen Datenmodulen zuverlinken, genauso wie innerhalb eines Datenmoduls. Für den Fall, dass aus einem Objektzu mehreren Zielobjekten verwiesen werden soll, muss ein Menü mit der Auswahl der mögli-chen Ziele aufgelistet werden. Dieses kann beispielsweise durch das Anklicken des Objektsrealisiert werden.

Das Linking von Datenmodultext zu Grafikobjekten erfolgt über das <internalRef>-Markup, das als Child-Element von <hotspot> definiert ist. Für den Fall, dass die Verbin-dung innerhalb eines Datenmoduls hergestellt werden soll, wird das Attribut “internalRefId”und der XML ID/IDREF-Mechanismus angewendet. Falls dies nicht gilt, muss das Attribut“refferedFragment” benutzt werden, das die Universal Ressource Name (URN) enthält, dieauf das Zielobjekt zeigt. Eine URN kann z. B. bei Verwendung von Audio/Video-Dateien ver-wendet werden, die eine bestimmte Position haben. Für das Verlinken von Grafikobjektenin anderen Datenmodulen wird das XML-Element <dmRef> verwendet. Mit dem optiona-len Attribut “refferedFragment” hat man die Möglichkeit des Referenzierens eines Objektesinnerhalb des anderen Datenmoduls.


3.4 Business Rules - BR

Für jedes S1000D Projekt oder für eine Firma bzw. Organisation können durch die Firmabzw. Organisation die sogenannten Business Rules definiert werden, die für das jeweiligeProjekt oder für die Firma gelten sollen. Die BR-s sind Entscheidungen und Regeln undbestimmen darüber, wie die Spezifikation 1000D in dem Projekt umgesetzt oder wie sie Fir-menweit eingesetzt werden soll (siehe ASD u. a. (2008)). Hiermit kann beispielsweise fest-gelegt werden, welche Version der Spezifikation für das Projekt verwendet wird oder welchesFormat für die Grafiken gelten soll (siehe 3.14). Es wird aber auch festgelegt, welche XML-Elemente und Attribute beim Erstellen der Inhalte verwendet werden sollen. Mehrdeutigkei-ten bei der Implementierung sollen dadurch ausgeschlossen werden. Die Regeln könnenalle Aspekte von S1000D betreffen und sind nicht z. B. auf die Erstellung der Inhalte oderVerwendung von Illustrationen begrenzt. Themen, die nicht in S1000D behandelt werden,können ebenso durch die Business Rules beschrieben bzw. definiert werden, z. B. die Zu-sammenarbeit von S1000D mit anderen, verwandten Standards oder Spezifikationen. Dadie Spezifikation sehr generisch und allgemein gehalten wird und auf sehr unterschiedlicheBereiche anwendbar ist, können Projektspezifische Abgrenzungen in Form von Regeln mitHilfe von BR angewendet werden.

3.4.1 BR Kategorien

In S1000D werden 10 unterschiedliche Kategorien von Business Rules definiert (siehe 3.14),unter anderem z. B. Product Definition Business Rules, Data Creation Business Rules oderLegacy Data Conversion Business Rules. Die Bereiche teilen die Regeln in funktionale Grup-pen und fassen zusammengehörige Entscheidungen zusammen. Die Aufteilung soll als Leit-faden dienen und kann in einem Projekt flexibel angewendet werden. Für ein S1000D Projektist es notwendig diese Entscheidungen zu treffen. Sie sollten sehr überlegt bestimmt und do-kumentiert werden.


S1000D-TPSMG-01000-00 S1000D-I9005-01000-00

rule required by a lower level of the business rules hierarchy can be in conflict with the related business rules of the other layers. Para 5 of this chapter points out various conflicting aspects in business rules creation and provides guidance as well as recommendations to avoid these conflicts.

2 Business rule categories A business rule category is a unique grouping that describes rules applicable to product definition, maintenance philosophy, concepts of operation, security, business processes, data creation, data exchange, data integrity, data output and/or legacy data conversion, management, handling and other issues.

Ten different business rule categories have been identified. These categories are defined to ensure that business rules developers consider all major business rules decisions within S1000D. Each sample business rule is assigned to one business rule category. Some business rules can belong to one or more categories. Apart from that, the business rule categories cannot be considered in isolation from each other. They relate to and complement each other (eg data exchange, data integrity and management business rule categories as shown in Para 2.8, as well as data creation and data output business rule categories as shown in Para 2.10). The business rule categories are identified in Fig 1.

ICN-83007-S1000D001-001-01

Fig 1 Business rule categories

The examples given after the definitions of each business rule category in Para 2.1 thru Para 2.10 are not exhaustive and are only intended to provide the reader with a guide how these categories of rules can be covered. The word "must" means in this example that a certain business rule must be followed only by this particular example project or organization.

2.1 Business rule category 1: General business rules 2.1.1 Definition

General business rules cover all decisions made by a project or an organization that are not covered by any of the specific business rule categories below. They serve as overall decisions for the implementation of S1000D.


Chap 2.5.1


Abbildung 3.14: Business Rule Categories (ASD u. a. (2008))

Business Rules werden zum einen in einem Dokument (Projektdokumentation) und zum an-deren im Business Rules Exchange (BREX) Data Module festgehalten. Durch das BREXkann automatisiert geprüft werden, ob in einem Projekt die definierten Business Rules ein-gehalten werden. Nicht alle Entscheidung sind jedoch in dem BREX DM enthalten, z. B. obeine IETP- oder PDF-Ausgabe der Publikationen für das Projekt vorgesehen ist. Dies wä-re nur schriftlich in der Projektdokumentation festzuhalten (siehe Crowell Solutions (2010)).Entscheidungen bezüglich des Inhaltes (welche Inhalte sind erlaubt) können automatisiertüberprüft werden und sind im BREX Data Module enthalten. Ein Schema für das Erstellenvon BREX-Datenmodulen ist vorgegeben. Zum Erstellen der Business Rules kann man inder Version 4.0, die in dieser Arbeit als Referenz verwendet wird, keine Informationen fin-den. Lediglich trifft man auf einen Hinweis, dass spätere Versionen der von S1000D dieThemen Erstellung und Nutzung von Business Rules enthalten werden. Aufgrund der feh-lenden Anweisungen bzgl. der Erstellung der BR-s wurden in dieser Arbeit im Ranhmen derKonvertierung der Dokumentation von ATA iSpec 2200 nach S1000D keine Business Rulesfür das S1000D-Projekt definiert.

3.4.2 Business Rules Exchange - BREX

Um Zweideutigkeiten in der Auffassung von vereinbarten Business Rules zu vermeiden, kanndas BREX-Datenmodul verwendet werden (siehe ASD u. a. (2008)). Dieses dient der Ver-minderung der Missinterpretation und Missverständnisses in Bezug auf die Business Rules.Die Regeln ermöglichen den beteiligten Parteien (Projektpartnern) das Prüfen der CSDB-


Objekte auf Gültigkeit hinsichtlich der vereinbarten Regeln. Diese Prüfung kann z. B. auto-matisiert durchgeführt werden.

Es ist notwendig, dass in jedem Datenmodul, das bestimmten, vordefinierten Regeln unter-liegt, eine Referenz auf das BREX-Datenmodul enthalten ist. Es ist dabei zu beachten, dassjeweils nur ein BREX einem Datenmodul zugeordnet werden kann, da ansonsten Inkonsis-tenzen und Verstöße gegen die getroffenen Vereinbarungen entstehen können.

Ein Default BREX-Datenmodul ist von S1000D vorgegeben. Darin enthaltene Regeln stellenz. B. Einschränkungen, die durch Schemata nicht wiedergegeben werden konnten oder auchvordefinierte Attributwerte, so wie sie in S1000D spezifiziert sind. Im Folgenden wird ein Aus-schnitt aus dem Default-BREX-Datenmodul gezeigt und seine beispielhafte PDF-Ausgabe.

<content> <brex> <contextRules> <structureObjectRuleGroup>  <structureObjectRule> <objectPath>//dmodule </objectPath> <objectUse>The root element of an interchanged data module must be element /dmodule/ (Chap 3.9.5). </objectUse> </structureObjectRule>  <structureObjectRule> <objectPath allowedObjectFlag="0" >//responsiblePartnerCompany[(not(attribute::enterpr iseCode) or attribute::enterpriseCode = "") and (not(chi ld::enterpriseName) or child::enterpriseName = "")] </objectPath> <objectUse>Company or organization must be indicated by at least one of either the name of the company a nd/or the company’s CAGE code, .... However, if a responsible partner compan y has an enterprise code, then that code must be used (Chap 3.9.5.1, Para 2.2 .5). </objectUse> </structureObjectRule>  <structureObjectRule> <objectPath allowedObjectFlag="0" >//identAndStatusSection/dmAddress/dmIdent/issueInfo [attribute::issueNumber = "001" and ancestor::dmodule[child::identAndStatusSection[chil d::dmStatus[child::reasonForUpdate]]]] </objectPath> <objectUse>RFU must not be used on Issue 001 of a data module (Chap 3.9.5.2.1.1, Para 2.1). </objectUse> </structureObjectRule> <structureObjectRule> <objectPath allowedObjectFlag="0" >//dmodule[descendant-or-self::dmStatus[attribute::issueType != "changed"] a nd descendant-or-self::dmAddress[descendant-or-self::issueInfo[attri bute::issueNumber != "000" and attribute::issueNumber != "001"]] and not(desce ndant-or-self::reasonForUpdate)] </objectPath> <objectUse>Data modules that are not of issue type changed must also have at least one reason for upda te element if the issue number is greater than 001 (Chap 3.9.5.2.1.1, Para 2.2). </objectUse> </structureObjectRule> (...)

Listing 3.1: BREX Ausschnitt (XML-Format) (ASD u. a. (2008))


Abbildung 3.15: BREX Ausschnitt (PDF-Fromat) (ASD u. a. (2008))

3.5 Applicability (Effectivity)

Unter Anwendbarkeit versteht man die Gültigkeit eines Abschnitts, Materials oder techni-scher Daten für einen Typ, eine Serie, ein Modell oder einen individuellen Abschnitt (sieheAir Transport Assotiation (2006)). Diese wird verwendet, wenn ein bestimmter Teil des In-halts nicht allgemeingültig anwendbar ist, sondern für eine Teilgruppe der beschriebenenKomponenten gilt. Diese Abgrenzung kann z. B. anhand der Modell- oder Seriennummer ge-kennzeichnet werden. Besonders wichtig ist das Konstrukt hinsichtlich der Effizienz bei derErstellung von technischen Dokumenten. Durch das Markieren von Anwendbarkeit kann ver-mieden werden, dass unterschiedliche Dokumentationen z. B. für verschiedene Modelltypeneines Produkts (z. B. Triebwerks) gepflegt werden müssen, im Falle, dass deren Inhalte nurunerheblich voneinander abweichen. Hierdurch ist eine Möglichkeit zur Definition von beding-ter Logik innerhalb von Publikationen gegeben. Ein einziges Dokument kann erstellt werdenund Teile, bei denen unterschiedliche Inhalte bzw. Vorgehensweisen erforderlich sind, kön-nen durch das Anwendbarkeitskonstrukt gekennzeichnet werden.


3.5.1 Effectivity in ATA iSpec 2200

In ATA iSpec 2200 spricht man hier von Effectivity. Gekennzeichnet wird die durch das<EFFECT>-Element, das als erstes Kind-Element in dem betroffenen Abschnitt verwendetwird. Mit dem Attribut EFFRG (Effectivity Range) kann man die Komponentengruppe kenn-zeichnen, auf die der markierte Abschnitt zutrifft. Für Flugzeuge ist der Effectivity-Wert durcheine Liste von Intervallen mit Zahlen der Länge 2 · N festlegt (N gibt die Code-Länge an), dieden Gültigkeitsbereich vorgeben. Die Bedeutung der Bereiche muss festgelegt sein (sieheNeitzke (2002)). Eine maschinelle Auswertung aller möglichen Teilmengen ist dadurch er-möglicht. Zusätzlich kann das EFFTEXT-Attribut eine Beschreibung der Anwendbarkeit alsFreitext enthalten. Die Verwendung wird durch folgendes Codebeispiel verdeutlicht:

<PRCITEM> <TITLE> Hydraulic Ground Power Cart </TITLE> <PARA> <EFFECT EFFRG="001006 010255 900999"></EFFECT>Only hydraulic ground power... </PARA> <PARA> <EFFECT EFFRG="001999"></EFFECT>Fluid sampling for... </PARA> </PRCITEM>

Listing 3.2: Effectivity - Code Beispiel

Die zwei <EFFECT>-Elemente beziehen sich jeweils auf die PARA-s und sind als erstesKind-Element der jeweiligen <PARA>-Elemente aufgeführt. Effectivity-Informationen könnenebenfalls in Bezug auf Grafiken verwendet werden.

Zusätzlich zu den Effectivity-Anmerkungen gehört die sogenannte Effectivity Cross-Refer-ence (auch List of Effective Aircraft genannt) zu dem iSpec Anwendbarkeitskonzept. Die-se listet Daten auf, die der Identifizierung diverser Effectivities-Gruppen einer Dokumentin-stanz dienen. Die Effectivity Cross-Reference enthält auch Informationen über die Zusam-menhänge zwischen den Anwendbarkeits-Informationen und der Erklärung der Effectivities-Ausdrücke. Die Art der zusätzlichen Hierarchiesierung von Effectivity-Informationen wird ineinem AMM angewendet. Bei diesem Manual-Typ ist es möglich, eine übersichtliche Auf-teilung der unterschiedlichen Effectivity-Gruppen zu erreichen. Die Vorfilterung mittels derDaten der Effectivity Cross-Reference kann auf der Modelltyp- oder Seriennummer-Ebenedurchgeführt werden. In diesem Fall ist die Vielfalt der unterschiedlichen Möglichkeiten imUnterschied zu einem Engine Manual recht klein. Im Fall eines EM kann keine Vorfilterungstattfinden, da hier eine Effectivity Cross-Reference nicht enthalten ist. Dies ist auf die sehrgroße Vielfalt der möglichen Gruppierungen in dem Triebwerksbereich und somit die Schwie-rigkeit bei der Definition der Effectivity-Gruppen zurück zu führen.


3.5.2 Applicability in S1000D

In S1000D spricht man von Applicability. Auch hier werden einem Teil oder dem gesam-ten Data Module Informationen mitgegeben, die aussagen, in welcher Situation dieses zuverwenden ist. Im ersten Fall spricht man von Inline oder Content Applicability, im zweitenvon Global oder Data Module Applicability. Dieses Konstrukt kann in S1000D sehr einfach,aber auch sehr komplex benutzt werden. Mit Hilfe von Anwendbarkeit-Informationen kannbei Bedarf eine Filterung der Inhalte durchgeführt werden. Man kann sich vorstellen, dassnicht alle Informationen, die in einem DM enthalten sind und auf mehrere Produktmodellezutreffen, für einen Endanwender interessant sind. So würde man beim Publizieren der Da-ten die Inhalte, die für ein Modell vorgesehen sind, die für den Endanwender irrelevant sind,herausfiltern. Diese Vorgehensweise wäre in einer interaktiven, elektronischen Publikationumzusetzen. Im Falle, dass die Publikation seitenorientiert und statisch erzeugt wird (z. B.als PDF-Dokument), müssen alle Informationen ausgegeben werden und der Nutzer mussanhand der Anwendbarkeit-Informationen entscheiden, welche Inhalte für ihn relevant sind.

Komplexe Applicability-Konstrukte und vor allem diejenigen, die das Filtern der Inhalte in ei-nem Viewer ermöglichen, erfordern die Pflege weiterer Strukturen: Applicability Cross-Refer-ence Table (ACT), Conditions Cross-Reference Table (CCT) und Products Cross-ReferenceTable (PCT) (siehe ASD u. a. (2008)). Jede dieser Strukturen stellt ein Datenmodul dar. DieAttribute eines Produkts sind im ACT-Datenmodul enthalten. Diese können z. B. Modell- oderSeriennummer sein. Dieses Datenmodul ist der zentrale Referenzpunkt für alle Datenmodu-le bzw. Publikationen, die Applicabilty-Annotations verwenden. Weiterhin verweisen CCT-DMund PCT-DM auf das ACT-DM. Diese Abhängigkeiten sind durch Abbildung 3.16 verdeutlicht.

Bedingungen sind im CCT-Datenmodul abgelegt. Dies können alle Bedingungen sein, dieden Inhalt beeinflussen können, z. B. Ort der Wartungsarbeiten, verfügbare Werkzeuge,Windgeschwindigkeit oder ähnliches. Sie werden während der Projektplanung erstellt, kön-nen aber im Laufe der Zeit und mit Weiterentwicklung eines Produkts wachsen. Neue Attri-bute und Bedingungen müssen erstellt und in die Dokumentation eingetragen werden. ImPCT-Datenmodul sind Informationen zur Konfiguration der Produktinstanzen sowie die Pro-duktdefinitionen enthalten.


S1000D-TPSMG-01000-00 S1000D-I9005-01000-00

ICN-S1000D-A-041400-A-76301-00002-A-002-01

Fig 2 Referencing scheme

Refer to Chap 4.14.1 for details on the ACT data module.

2.2.3 CCT data module The CCT data module is used to declare any type of condition that can affect applicability of data. Conditions can be technical, operational, environmental or any other type of condition that can affect technical data. Technical conditions are typically tied to the configuration of the Product, such as service bulletins or modifications. The state of technical conditions can change throughout the service life of a product instance. Examples of operational and environmental conditions are location of maintenance, availability of tools, regulatory rules, temperature, wind speed and sandy conditions.

Similar to the ACT data module, a project or an organization can have multiple CCT data module instances. A project or an organization can decide to use more than one CCT data module instance to segregate conditions between major subsystems or to segregate between project partners.

The CCT data module is divided into three major elements:

an element to define common types of conditions

an element to define specific conditions

an optional incorporation status list for technical conditions

Refer to Chap 4.14.2 for details on the CCT data module.


Chap 4.14


Abbildung 3.16: Applicability: DM Abhängigkeiten (ASD u. a. (2008))

Die oben aufgeführten Datenmodule sind nicht dafür gedacht, von Nutzern technischer Do-kumentationen eingesehen zu werden und werden nur zwecks Computerverarbeitung ge-nutzt. Das Konzept der Anwendbarkeit wird in S1000D ausführlicher betrachtet, als bei deriSpec. Die Informationen aus der iSpec Effectivity Cross-Reference können in die ACT- bzw.PCT-Datenmodule übertragen werden (siehe Mayer (2010)). Die CCT würde Informationenbeinhalten, die in einem Service Bulletin nach iSpec enthalten sein würden. Die Verwaltungder verschiedener Datenmodule muss jedoch nicht zwingend komplexer sein, als dies in Ma-nuals nach ATA iSpec 2200 der Fall ist. Applicability kann im S1000D-Umfeld sehr einfachrealisiert werden, aber eignet sich auch für Abbildung komplexer Verhältnisse. Das iSpecKonzept ist in vieler Hinsicht eingeschränkter und S1000D bietet mehr Flexibilität an dieserStelle.

3.5.3 Zusammenfassung

Das Kennzeichnen der Anwendbarkeit ist mit Hilfe der beiden hier betrachteten Spezifikatio-nen möglich und wird sehr ähnlich gehandhabt. Applicability (Effectivity) kann sowohl aufdie Textinhalte als auch auf die Grafiken angewendet werden. S1000D bietet jedoch ei-ne stärkere Differenzierung der definierten Gültigkeitsbereiche anhand der Funktionalität,die in den drei vordefinierten Cross-Reference Tabellen untergebracht werden können. Auf-grund der Modularisierung mit Hilfe von Datenmodulen ist auch eine zusätzliche Form der


Appclicability-Definition auf der DM-Ebene möglich. Diese erlaubt einen Austausch von gan-zen Datenmodulen, was zur Vereinfachung führt und für mehr Übersichtlichkeit sorgt.

3.6 Referenzen (Links)

Ein wichtiges Mittel, das das Arbeiten mit technischen Dokumenten erleichtert, ist das Refe-renz-Konstrukt. Mit Hilfe von Links (Referenzen, Verweise) ist es möglich, an beliebiger Stelleim Dokument ein weiteres Dokument bzw. eine Stelle im Dokument zu markieren, sodassder Benutzer direkt dorthin navigieren kann. Beide hier betrachteten Spezifikationen unter-stützen das Verwenden von Referenzen in Dokumenten.

Da eine S1000D Publikation aus mehreren XML-Dateien erstellt wird, muss sichergestelltwerden, dass Verweise innerhalb eines Dokuments (Datei) sowie zwischen unterschiedli-chen Dateien realisiert werden können. Für das Referenzieren innerhalb einer Datei (Cross-Reference) ist mit dem ID/IDREF-Mechanismus realisiert (sieheASD u. a. (2008)). Es ist einStandard-Konstrukt, das das Referenzieren innerhalb einer XML-Datei ermöglicht. Zwei At-tribute werden benötigt: ID, das ein generisches Attribut ist und beim Element vorhanden seinmuss, auf das aus einer anderen Dokumentstelle referenziert werden soll (Ziel). Das zwei-te Attribut vom generischen Typ IDREF bzw. IDREFS, das beim Element vorhanden seinmuss, aus dem zu einer anderen Dokumentstelle referenziert werden soll (Start). Hier mussals Attributwert der Wert des ID-Attributs des Zielelements vorhanden sein. Das <IDREFS>-Element wird verwendet, Fallf mehrere Zielelemente zur Auswahl stehen sollen. Für dieexternen Referenzen (zwischen verschiedenen Dateien) wird in S1000D das <dmRef>-Element verwendet, das mit Hilfe von Data Module Code das gesuchte Ziel-Datenmodulerreicht. Es ist dabei unerheblich, welcher Datenmodultyp betroffen ist. Mit dem Attribut „re-ferredFragment“ wird das gesuchte Element (dessen ID) innerhalb des Ziel-Datenmodulsbestimmt. An dieser Stelle wird wiederum der ID/IDREF-Mechanismus angewendet.

Es wird empfohlen, diese Art des einfachen Referenzieren zu verwenden. Eine weitere Mög-lichkeit des erweiterten Referenzierens mit Hilfe der XML-Linking-Sprache XLink ist ebensomöglich. Elemente, deren Attribut xlink:type den Wert ’simple’ oder ’extended’ aufweist,sind dann die Linking-Elemente.

Dokumentationen nach iSpec werden normalerweise als ein umfangreiches Dokument aus-geliefert. Das Referenz-Konzept ist somit mit Hilfe von internen Referenzen realisiert. Zudiesem Zweck wird ebenso das oben beschriebene ID/IDREF-Konstrukt verwendet und einLink mit dem Element <REFINT> markiert. Das Linking kann jedoch auch zwischen unter-schiedlichen Manuals erfolgen. Hierfür wird das Element <REFEXT> verwendet. Das Ele-ment enthält eine textuelle Beschreibung mit einer Erklärung des Verweises. Die Attributespeichern die benötigten Informationen, die für das Auflösen der Referenz notwendig sind.Die AMTOSS-Nummerierung wird für das Kodieren der Zielelemente verwendet.


In Tabelle 3.9 wurden die für die Transformation benötigten Informationen zusammengefasst.

Tabelle 3.9: Referenzen (Mayer (2010))

ATA iSpec 2200 S1000DStart und Ziel in einem DM

REFINT internalRefREFINT/@refId internalRef/@internalRefIdREFINT/@reftype internalRef/@internalRefTargetType

Ziel ist ein DMREFINT bzw. REFEXT dmRef

dmRef/dmRefIdent/dmCode enthaltenDaten des transformierten Ziel-Elements(anchor)

Ziel liegt innerhalb eines DM-sREFINT bzw. REFEXT dmRefZiel-Anchor dmRef/dmRefIdent/dmCodeREFINT/@REFIDbzw. anchor-ID des REFEXT/@REFLOC

dmRef/@refferedFragment

3.7 Warning, Caution, Note

In Wartungsdokumenten werden bestimmte Inhalte mit einer Warnung versehen, da beson-dere Vorsicht beim Umgang mit dem betrachteten Teil bzw. bei der Ausübung der Aufgabengeboten ist. Die Warning-, Caution- und Note-Elemente dienen der Kennzeichnung dieserAbschnitte.

Warnings informieren den Manual-Benutzer über die möglichen Gefahren, denen dieser imZusammenhang mit der betreffender Prozedur bzw. dem Material ausgesetzt werden kann.Folgen der Unachtsamkeit können gesundheitliche Schäden sowie Beschädigung der Ma-schinen sein, falls die im Wartungsdokument enthaltenen Anweisungen nicht präzise einge-halten werden.

Falls während eines Vorgangs die behandeltet Produkte bzw. Materialien beschädigt werdenkönnen, werden die betroffenen Dokumentinhalte mit einer Caution markiert. Somit wird aufbesondere Vorsicht im Umgang mit dem jeweiligen Produkt bzw. Material hingewiesen. DieRisiken und mögliche Auswirkungen sind hier aufgeführt. Eine beispielhafte Umsetzung einerCaution wurde in Abbildung 3.17 dargestellt.

Zusätzliche Informationen, die eine Aufgabe erleichtern können, jedoch nicht direkt zu dembeschriebenen Inhalt gehören, werden in Notes erfasst. Notes können jedoch keinesfalls


anstatt von der beschriebenen Prozedur ausgeführt werden und haben lediglich eine ergän-zende Funktion.

S1000D-I9005-01000-00


Chap 6.2.2


The warning text being centered in a symbolic warning

An extra leading of 8 pt after the frame

The difference is in the "symbolic" frame.

The symbol can be omitted or substituted with other, to the warning, relevant symbols eg as given in Para 2.10.1.1.2.

Fig 5 in Chap 6.3.1 shows a warning with an acknowledge button, , which is used in interactive publications only. Refer to Chap 6.3.1.

2.10.1.3 Cautions Follows the same rules as warnings given in Para 2.10.1.1 and Para 2.10.1.2 with the following differences:

Cautions are preceded by any warnings

2.10.1.4 Notes Notes given in the beginning of a procedural step must be preceded by any warning and cautions.

The caption Note, or Note X if more than one, must be presented in 10/11 pt bold, lowercase. The normal leading from a preceding headline, paragraph, list item, table footer (closing line), figure title line, last line in a warning, caution or note, etc, to the illustration top limit is used, eg 8 pt after a text paragraph or figure title line. No extra leading must be added after the caption.

The word Note must align the left type limit when it refers to a paragraph and be indented to align the text of the list item to which it pertains. The note itself must be indented 7 mm from the left limit of the word Note and is presented in 10/11 pt, lowercase, on the following line. An extra leading of 8 pt must be added after the note.

The word Note or Note X and the note itself must not be split due to a page break.

Abbildung 3.17: Caution (ASD u. a. (2008))

3.7.1 Abbildung von Warnings / Cautions / Notes von ATA iSpec 2200zu S1000D

Warnings, Cautions und Notes können in beiden der hier beschriebenen Spezifikationenverwendet werden. Die Kennzeichnung dieser Abschnitte wird in ATA iSpec 2200 mittelsder Elemente <warning>, <caution> und <note> realisiert. Entsprechende Elemen-te können in S1000D identifiziert werden. Tabelle 3.10 enthält eine Abbildung der iSpecStrukturen auf die S1000D Konstrukte.

Tabelle 3.10: Abbildung von Warning, Caution und Note

ATA iSpec 2200 S1000DWarning

warning warningpara warningAndCautionPara

Cautioncaution cautionpara warningAndCautionPara

Notenote notepara notePara

3.8 Revision

Ein technisches Dokument, das einmal erstellt wurde, durchläuft in seinem Lebenszyklusnormalerweise mehrere Revisionen. Gründe hierfür sind Änderungen, die an beschriebenen


Materialien vorgenommen wurden bzw. Nutzung neuer Materialien, Verbesserungen in denProzessen, Aktualisierung von Grafiken oder ähnliches. Diese führen zu Änderungen in denDokumentinhalten.

3.8.1 ATA iSpec 2200

ATA iSpec 2200 bietet drei Formen der Auslieferung neuer Inhalte: Komplett-, Incremental-und Temporary-Auslieferung. Die veränderten Inhalte werden markiert, basierend auf demAnchor-Konzept, das das Grundelement der Revisionskontrolle darstellt und zwischen demZulieferer und dem Empfänger (Kunde, Projektpartner) ausgetauscht wird. Anchor stellt einElement dar, für das es möglich ist Revisionsinformationen zu speichern, z. B. Chapter, Sec-tion, Task, etc. Ein aktualisierter Abschnitt wird mit Hilfe von <REVST>- und <REVEND>-Elementen gekennzeichnet und kann somit im Fließtext hervorgehoben werden (siehe 3.3).Im Falle von Erzeugung oder Entfernung eines gesamten Anchors muss der Inhalt ebensomit <REVST> bzw. <REVEND> markiert werden.

EXAMPLE EXAMPLE ... <PARA><REVST>revised data<REVEND></PARA> ...

EXAMPLE EXAMPLE

Listing 3.3: REVST/REVEND Beispiel (Air Transport Assotiation (2006))

Revisionsinformationen werden in folgenden Anchor-Attributen gespeichert:

• key: wird jedem Anchor zugeordnet und enthält die ID-Informationen

• chg: enthält Informationen zu dem Änderungsstatus der Inhalte. Kann folgende Werteannehmen: „N“ (New), „D“ (Deleted), „R“ (Revised), „U“ (Unchanged)

• revdate: enthält Informationen zum letzten Revisionsdatum des Anchors

Ein iSpec Manual wird meist in festen Revisionszyklen, z. B. vierteljährlich, revidiert und ei-ne vollständige, neue Version (Revision) eines Dokuments wird dem Kunden bzw. Projekt-partner überreicht. Dies ist der Fall einer Komplett-Auslieferung. Es ist jedoch möglich, dieÄnderungen, die in der Zwischenzeit im Dokument vorgenommen wurden, häufiger zu veröf-fentlichen. Eine Incrementelle Auslieferung bedeutet, dass nur die veränderten Inhalte einesManuals übergeben werden. Diese müssen dann in das vorhandene Manual integriert wer-den. Ein Hilfsmittel für diesen Vorgang stellt die List of Effective Anchors (LEA), die im Falleeines Incrementals Updates ausgeliefert werden muss. Diese Liste wird zwecks Überprü-fung der Konsistenz der Daten des Senders und Empfängers eingesetzt. Einträge mit denbetroffenen Daten (Anchor) und den Revisionsinformationen für Change-Status und Revisi-onsdatum sind darin enthalten. Die iSpec gibt ausführliche Informationen zur Erstellung von


LEA. Eine Temporary Revision (TR) ist eine besondere Art der incrementellen Auslieferung.TR-s werden nicht revidiert, sondern im Falle, dass Veränderungen in den revidierten In-halten vorgenommen werden müssen, eine neue TR wird erstellt, die die vorherige ersetzt.Eine Auslieferung der veränderten Daten, die jedoch nicht als reguläre Revision eines Manu-als wahrgenommen wird und außerhalb des regulären Revisionszyklus veröffentlicht werdensoll, kann mittels TR durchgeführt werden. Normalerweise werden hier sicherheitsbezogene(sicherheitskritische) Inhalte ausgeliefert. Diese werden in der nächsten regulären Revisionenthalten sein.

3.8.2 S1000D

Da technische Dokumentation nach S1000D aus mehreren XML-Dateien (Datenmodulen)erstellt wird, werden die Revisionsinformationen für jedes einzelne DM gepflegt. Auch beidem Publikations-Datenmodul werden Versionsinformationen gespeichert, die für die ge-samte Publikation gelten. Die Revisionsinformationen werden in der Identification and StatusSection gespeichert. Folgende Elemente sind hierfür vorgesehen:

• <issueInfo> enthält die Versionsnummer des Datenmoduls (issueNumber At-tribut), sowie eine Information darüber, ob es sich um einen Entwurf eines DM-s han-delt (Attribut inWork).

• <issueDate> enthält das Revisionsdatum (Attribute year, month, day)

• <reasonForUpdate> (RFU) enthält eine kurze Erklärung der Gründe eines Upda-tes (z. B. „Deleted. Data module no longer required.“). Falls ein DM vollständig revidiertwurde und sein Status auf „revised“ gesetzt wurde, muss das RFU den Vermerk „to-tally revised“ enthalten. Das Element kann verwendet werden, um das Highlights-DMautomatisiert zu erzeugen.

• <dmStatus> enthält Statusinformationen eines DM, u. a. das Attribut issueType,das folgende Werte annehmen kann: „new“, „deleted“, „changed“, „revised“, „status“,„reinstate-status“, „reinstated-changed“, „reinstated-revised“

Die erlaubten Werte des IssueType-Attributs wurden tabellarisch aufbereitet und können Ta-belle 3.18 entnommen werden.


S1000D-I9005-01000-00


Chap 3.9.5.1


"status". Data modules that have had their identification and status information

updated must have the attribute issueType set to the value "status".

"rinstate-status". Data modules that have been reinstated from a previously

deleted data module and have only the status information changed must have the

attribute issueType set to the value "rinstate-status". In the simplest

case, this status change must require setting the attribute issueType to the value

"rinstate-status".

"rinstate-changed". Data modules that have been reinstated from a previously

deleted data module and have the changes indicated by change elements and

attributes, must have the attribute issueType set to the value "rinstate-

changed".

"rinstate-revised". Data modules that have been reinstated from a previously

deleted data module and have the changes not indicated by change elements and

attributes, must have the attribute issueType set to the value "rinstate-

revised".

Table 2 shows the permitted values of the attribute issueType, where "X" shows that the

value is permitted.

Table 2 Values of the issue type attribute

Current issue Next issue of data module

new revised changed deleted status rinstate-x

new X X X X

revised X X X X

changed X X X X

deleted X

status X X X X

rinstate-x X X X X

When work first starts on a data module, the attribute issueType is set to the value "new",

while the issue number is set to the value "000" and inwork number to "01", using the attribute

issueNumber and attribute inWork of element <issueInfo>. Then, when the data

module is released, the attribute inWork is reset to the value "00", and the issue number

incremented to indicate approved release of that instance of the data module. From issue

"002" onwards the attribute issueType must not be set to the value "new" but is to reflect

the release status of the instance of the data module.

Child elements:

! <sourceDmIdent> (O). Refer to Para 2.2.1.

! <security> (M). Refer to Para 2.2.2.

! <dataRestrictions> (O). Refer to Para 2.2.3.

! <logo> (O). Refer to Para 2.2.4.

! <responsiblePartnerCompany> (M). Refer to Para 2.2.5.

! <originator> (M). Refer to Para 2.2.6.

! <applicCrossRefTableRef> (M). Refer to Para 2.2.7.

Abbildung 3.18: Werte des issueType-Attributs (ASD u. a. (2008))

Das <changeInline>-Element wird benutzt, um die Änderungen im bereits vorhande-nen Text zu markieren. In dem Beispielcode 3.4 wurde ein Textinhalt innerhalb eines Para-Elements hinzugefügt. Es wird hier auf ein Änderungsgrund verwiesen und das AttributupdateHighlight=“1“ gesetzt, sodass die Änderung im Highlight-DM aufgeführt wird.Für neu hinzugefügte oder gelöschte Elemente erfolgt die Änderungsmarkierung auf derElement-Ebene mittels bestimmter Attribute und nicht per <changeInline>-Element.Diese Attribute sind z. B. „changeMark“ (0 bzw. 1), „changeType“ (add, modify, dele-te), „reasonForUpdateRefIds“. Ein Verwendungsbeispiel wurde für das Löschen vonElementen unter 3.6 aufgeführt.

Die Häufigkeit der Updates wird nicht spezifiziert und muss z. B. mit Hilfe der Business Rulesfür ein Projekt festgelegt werden.

<proceduralStep> <para>Use the <internalRef internalRefId="seq-0001" internalRefTargetType="supequip">wrench</internalRef> to tighten the bolts <changeInline changeType="add" reasonForUpdateRefIds="rfu-0007" changeMark="1">to 16 lb/sq in <superScript>2</superScript> </changeInline>. </para> </proceduralStep> <reasonForUpdate id="rfu-0007" updateReasonType="urt02" updateHighlight="1"> <simplePara>The torque value is added</simplePara> </reasonForUpdate>

Listing 3.4: changeInlie Beispiel (ASD u. a. (2008))


3.8.3 Revisions-Highlighting

In ATA iSpec 2200 wird ein <CHGDESC>-Element verwendet, um die geänderten Anchor-Elemente zu identifizieren. Dieses Element wird als Kind-Element des Anchor-Elementsgesetzt und wird direkt hinter dem Effectivity-Element platziert. Anhand der <CHGDESC>-Elemente werden die Revisions-Highlights erzeugt, die alle Änderungen und betroffenen An-chors eines Manuals tabellarisch zusammenfassen und als Highlights (Change Description)am Anfang eines Manuals angefügt werden.

Die Highlights können für Dokumentation nach S1000D automatisiert erzeugt werden, wenndie veränderten DM-s das Element <reasonForUpdate> (RFU) verwenden. Hierfürmuss das Attribut ’updateHighlight’ der Wert ’1’ annehmen. Zusätzlich kann aus der ver-änderten Stelle heraus zu der Beschreibung des Änderungsgrundes referenziert werden.Highlights werden, ähnlich wie bei ATA iSpec 2200, am Anfang des Manuals als Teil derManual Front Matter angefügt.

3.8.4 Löschen von Revisionen

Beim Löschen eines gesamten Anchor-Elementes im Dokument nach ATA iSpec 2200 wirddas <DELETED>-Element verwendet, um den betroffenen Anchor kenntlich zu machen. DieVerwendung wird durch ein Code-Beispiel verdeutlicht (siehe 3.5).

<DOC SPL = "ATA/AIA" TSN = "3"> <CHAPTER CHG = "U" KEY = "A341" REVDATE = "19920101"> <SECTION CHG = "U" KEY = "A342" REVDATE = "19920101"> <PARA>gggggggggggggggggggggg</PARA> </SECTION> <SECTION CHG = "D" KEY = "A343" REVDATE = "19921001"> <CHGDESC>mod4</CHGDESC> <REVST><DELETED><REVEND> </SECTION> </CHAPTER> </DOC>

Listing 3.5: Delete anchor - ATA iSpec 2200 Beispiel (Air Transport Assotiation (2006))

Das Löschen von S1000D Datenmodulen, z. B. falls die Daten in der beschriebenen Formnicht mehr gebraucht bzw. verwendet werden, erfolgt durch das Markieren des DM-s mitdem Status „deleted“. Das Datenmodul wird jedoch aus der CSDB nicht entfernt. Die Ent-scheidung, wie lange ein gelöschtes Datenmodul in der CSDB beibehalten werden soll,muss für ein Projekt festgelegt werden. Weiterhin ist es möglich, ein DM, das als „deleted“


markiert wurde, wiederherzustellen und für weitere Benutzung freizugeben. Für S1000D-Datenmodule, die den Status „deleted“ haben, muss mit Hilfe von Business Rules für ein Pro-jekts bestimmt werden, wie der weitere Umgang mit den betroffenen DM-s gehandhabt wirdund wie Benutzer von technischen Dokumenten auf ein gelöschtes Datenmodul aufmerksamgemacht werden. Ein Codebeispiel verdeutlicht die Verwendung der aufgeführten Konstruk-te (siehe 3.6). Hier wird das gesamte „proceduralStep“ gelöscht (auch die Child-Elemente<PARA> und <TABLE>). Der Grund für die Entfernung wird im „reasonForUpdateRefIds“-Attribut referenziert.

<proceduralStep reasonForUpdateRefIds="rfu-0008" changeMark="0" changeType="delete"> <para>This is a deleted sub-step.</para> <table>...</table> </proceduralStep > <reasonForUpdate id="rfu-0008" updateReasonType="urt02" updateHighlight="1"> <simplePara>Step XX and table YY are deleted</simplePara> </reasonForUpdate>

Listing 3.6: Delete Element - S1000D Beispiel (ASD u. a. (2008))


Die Möglichkeiten der Markierung von Revisionsinformationen sind in beiden Spezifikatio-nen ähnlich. Geänderte Textinhalte werden mittels spezieller Elemente-Markups gekenn-zeichnet (z. B. <REVST>, <REVEND> oder <changeInline>). Weiterhin werden Attri-bute für das Markieren der Änderungen auf der Element-Ebene verwendet. S1000D bie-tet eine größere Bandbreite an Attributwerten, die für die Markierung ausgewählt werdenkönnen und hat somit mehr Möglichkeiten die Zustände der Inhalte abzubilden. Mit dem<reasonForUpdate>-Element können in einem S1000D-Datenmodul zusätzlich Kom-mentare erfasst werden, die das Nachvollziehen von Änderungen in den Texten erleichtern.Vor allem im Falle, dass mehrere Autoren für das Editieren der Inhalte zuständig sind, kanndas Element zur Vereinfachung der Arbeit dienen.

4 Ausgewählte Aspekte derTransformation eines ATA iSpec 2200Engine Manuals zu S1000D

4.1 Dokumentaufbau

Im Folgenden wird dargestellt, wie ein ATA iSpec 2200 Engine Manual aufgebaut ist. In die-ser Arbeit wird exemplarisch auf ein Wartungsdokument der Engine-Herstellerfirma Pratt &Whitney1 Bezug genommen. Die Abbildung 4.1 verdeutlicht die Struktur des Beispieldoku-ments.

Abbildung 4.1: Engine Manual Struktur

1http://www.pw.utc.com/Home

http://www.pw.utc.com/Home

4 Ausgewählte Aspekte der Transformation eines ATA iSpec 2200 Engine Manuals zuS1000D

67

Neben der Manual Front Matter (die im Abschnitt 3.2.4.6 ausführlich beschrieben wurde),sind in dem Beispiel-Manual sog. Chapter (Kapitel) vorhanden, die entsprechend dem ATA-Chapter-Breakdown durchnummeriert und strukturiert sind. Die Abbildung 4.2 verdeutlichtden hierarchischen Aufbau eines ATA-Kapitels.

Abbildung 4.2: Chapter Struktur

4.2 Überführung der ATA iSpec 2200 EngineManual-Inhalte in S1000D Datenmodule

Die Überführung der Inhalte eines Engine Manuals in die S1000D Datenmodule kann auf ver-schiedenen Ebenen des Manuals durchgeführt werden. Im Folgenden werden drei Ansätzenach Mayer (2010) diskutiert und anschließend wird ein Lösungsvorschlag für die Konvertie-rung gewählt.

Der hierarchische Aufbau des EM ermöglicht die Identifizierung unterschiedlicher Ebenen,die als Ansatzpunkte für die Aufteilung der Inhalte des Manuals dienen können. Diese kön-nen z. B. Chapter, Section, Subject, Pageblock oder Task sein. Jeder dieser Abschnitte würdedann in ein S1000D Datenmodul überführt werden.

Für die Erstellung der Datenmodule stellt die Spezifikation diverse Inhaltstypen zur Verfü-gung (unterschiedliche XML-Schemata). Für die Überführung der Inhalte eines Engine Ma-


68

nuals werden prozedurale Datenmodule erstellt, die auf dem entsprechenden XML-Schemabasieren. Dieses gilt auch für die Transformation eines Aircraft Maintenance Manual.

Im Rahmen dieser Arbeit werden nur die prozeduralen Inhalte eines Engine Manuals trans-formiert. Diese umfassen die notwendigen Arbeitsschritte zur Durchführung von Wartungsar-beiten. Die Abschnitte des Beispieldokumentes, die keine prozeduralen Arbeitsschritte dar-stellen (wie z. B. Manual Front Matter), werden hier nicht behandelt. Diese nicht behandeltenTeile des Dokuments enthalten zusammenfassende bzw. Meta-Informationen bzgl. des Ma-nuals, wie z. B. den Table of Contents.

4.2.1 Informationsaufteilung auf der Pageblock-Ebene

Eine der möglichen Vorgehensweisen basiert darauf, die Aufteilung des Engine Manuals aufder Pageblock-Ebene durchzuführen. Dadurch würde ein Pageblock zu einem Datenmodulkonvertiert werden (siehe Abbildung 4.3). In diesem Lösungsansatz würden die Datenmodu-le oftmals sehr groß werden, da sie mehrere Tasks enthalten können.

Abbildung 4.3: Konvertierung von Pageblocks zu Datenmodulen (nach Mayer (2010))

Ein so erzeugtes DM wird mittels DMC adressiert, was die eindeutige Identifizierung derEM-Pageblocks sicherstellt, jedoch nicht der Tasks. Eine weitere Möglichkeit der eindeuti-gen Identifizierung der Tasks innerhalb der neu erzeugten Datenmodule müsste geschaf-fen werden, da ansonsten die wichtige Eigenschaft und Information, die im Engine Manualvorhanden ist, verloren geht. In einem Datenmodul, das selber als die kleinste Informati-onseinheit definiert ist, ist ein Konstrukt zur weitergehenden, eindeutigen Identifizierung vonDM-Inhalten nicht gegeben.


69

4.2.2 Informationsaufteilung auf der Task-Ebene ohneBerücksichtigung der Pageblock-Informationen

Mit einem EM-Task bekommt man die kleinste Einheit eines Engine Manuals, die eindeutigadressierbar ist. Die Adressierung wurde im Abschnitt 3.2.3.1 in dieser Arbeit beschrieben.Mit diesem Ansatz wird ein EM-Task in ein prozedurales Datenmodul überführt (siehe Ab-bildung 4.4). Ein Pageblock, der als Container für die Tasks betrachtet werden kann, kannInformationen beinhalten (z. B. Grafiken), die übertragen werden müssen.

Abbildung 4.4: Konvertierung der Tasks und Pageblock-Inhalten zu Datenmodulen (nachMayer (2010))

In diesem Lösungsvorschlag wird ein deskriptives Datenmodul erzeugt, das die Pageblock-Inhalte kapselt. Dabei wird eine hierarchische Abhängigkeit zwischen den deskriptiven (Pa-geblock) und den prozeduralen (Task) Datenmodulen geschaffen, die durch die Aufteilungder zusammengehörigen Informationen zustande kommt. Diese Art von hierarchischen Ab-hängigkeiten ist beim Erzeugen von Datenmodulen durch S1000D untersagt. Datenmodulewerden laut Spezifikation als eigenständige und unabhängige Informationseinheiten erzeugtund der Aufbau einer Hierarchie der Datenmodule zum Zeitpunkt deren Erzeugung würdegegen die S1000D-Konzepte verstoßen. Eine logische Zusammenstellung der Datenmodulekann mit Hilfe von Publikationsmodulen abgebildet werden. Dieser Schritt kann jedoch erstzum Publikationszeitpunkt erfolgen.


70

4.2.3 Informationsaufteilung auf der Task-Ebene mit Berücksichtigungder Pageblock-Informationen

Um eine einfache Identifizierung der EM-Task zu ermöglichen, wird die Überführung ei-nes Engine Manuals in die Datenmodule auf der Task-Ebene durchgeführt. Die zusätzli-chen Informationen, die in einem Pageblock enthalten sein können, werden in diesem Vor-gang einem (oder mehreren) zugehörigen Datenmodul angeschlossen. Dadurch werden diePageblock-Informationen redundant in all den Datenmodulen vorkommen, die alle Tasks ei-nes jeweiligen Pageblocks abbilden (siehe Abbildung 4.5).

Abbildung 4.5: Konvertierung von Tasks mit Pageblock-Inhalten zu Datenmodulen (nachMayer (2010))

In dem Beispieldokument, das für die Konvertierung in dieser Arbeit verwendet wird, wird die-ses Vorgehen keine Auswirkung haben, da die Pageblocks dieses Dokuments keine weiterenInformationen enthalten. Dies vereinfacht die Konvertierung der Daten zum einen dadurch,dass kein Mapping der Pageblock-Informationen mit den Task-Inhalten in einem Datenmo-dul notwendig ist, zum anderen, da keine Redundanz der Daten durch die Konvertierungentsteht. Dieser Lösungsweg wurde im Rahmen dieser Arbeit realisiert.


Die hier beschriebenen Vorgehensweisen für die Übertragung der Inhalte eines ATA iSpec2200 Engine Manuals zu S1000D Datenmodulen haben Vor- und Nachteile. Der Ansatz derTransformation der Inhalte auf der Task-Ebene mit Berücksichtigung der Pageblock-Inhaltewird bevorzugt, weil eine Informations-verlustfreie Übertragung ermöglicht und keine Hier-archiesierung der Datenmodule verursacht wird. Hierfür muss jedoch abgewogen werden,


71

welche Folgen die redundante Speicherung der Pageblock-Informationen in den Datenmo-dulen hätte. Im Beispieldokument sind keine Pageblock-Informationen vorhanden, sodass eszu keiner Redundanz kam.

Für den Fall, dass der Lösungsweg des hierarchischen Aufbaus der Datenmodule gewähltwird, muss abgewogen werden, welche Folgen dies für ein Projekt hat. Die logischen Abhän-gigkeiten können ggf. durch Referenzen realisiert werden, jedoch wird dieses ggf. negativeAuswirkungen auf die Wiederverwendbarkeit der Datenmodule haben.

Die erste Methode wird nicht empfohlen, da die Adressierbarkeit der Tasks dadurch verlorengeht. Ein weiterer Nachteil entsteht durch den großen Umfang des Pageblock.

4.3 Transformation

Für die Überführung der EM-Tasks wurde eine XSL-Transformation erstellt. Im Folgendenwird vorgestellt, welche Annahmen für die Konvertierung der Inhalte getroffen wurden undwelche Einschränkungen aufgedeckt wurden. Die im Rahmen der Konvertierung erzeug-ten S1000D Datenmodule unterliegen dem durch die Spezifikation 1000D definierten XML-Schema „proced.xsd“. Dieses dient der Erstellung von prozeduralen Datenmodulen.

4.3.1 Data Module Identification and Status Section

Der erste Teil eines jeden Datenmoduls besteht aus einer Identification and Status Sec-tion (siehe3.2.2). Hier werden diverse Metainformationen eines Datenmoduls gespeichert,wie z. B. die Bestandteile des Data Module Codes oder Revisionsinformationen. Die Vorge-hensweise bei der Konvertierung dieser Informationen wurde auch in anderen Abschnittendieser Arbeit vorgestellt (siehe z. B. 3.2.2). Einige der Werte, die in einer Identification andStatus Section erforderlich sind, aber nicht den Quelldaten eines Tasks entnommen werdenkönnen, werden in dem XSLT-Stylesheet statisch als XML-Entities definiert (z. B. Creator,Language, Model Identification). Werte, die optional im DM-Schema definiert sind und keineEntsprechung in dem Engine Manual finden, werden in der Transformation nicht berücksich-tigt. Ein Ausschnitt der Identification and Status Section ist dem folgenden Code-Abschnittzu entnehmen:


72

<identAndStatusSection> <dmAddress> <dmIdent> <dmCode modelIdentCode="PW4000_100" systemDiffCode="00" systemCode="05" subSystemCode="1" subSubSystemCode="0" assyCode="00" disassyCode="001" disassyCodeVariant="" infoCode="990" infoCodeVariant="0" itemLocationCode="0"/> <language countryIsoCode="US" languageIsoCode="en"/> <issueInfo issueNumber="52" inWork="0"/> </dmIdent> <dmAddressItems> <issueDate year="1995" month="02" day="15"/> <dmTitle> <techName>Task 05-10-00-990-001</techName> <infoName>Instructions For Continued Airworthiness - General</infoName> </dmTitle> </dmAddressItems> </dmAddress> <dmStatus> <security securityClassification="01"/> <responsiblePartnerCompany enterpriseCode="PW"> <enterpriseName>Pratt Whitney</enterpriseName> </responsiblePartnerCompany> <originator enterpriseCode="PW"> <enterpriseName>Pratt Whitney</enterpriseName> </originator> (...) <qualityAssurance> <unvefified/> </qualityAssurance> </dmStatus> </identAndStatusSection>

Aus einer Entity

Aus Task-Attributen

Listing 4.1: DM Identification and Status Section

4.3.2 Content

Der Aufbau des Content-Teils eines Datenmoduls, der die Prozedurinhalte enthält, ist in Ab-bildung 4.6 dargestellt. Elemente, die optional einsetzbar sind und keine Entsprechung ineinem EM-Task haben bzw. in dem Beispieldokument nicht eingesetzt werden, werden beider Konvertierung nicht berücksichtigt. Dieses trifft beispielsweise bei dem DM-Element ’Re-ferences’, das erlaubt, weitere Datenmodule zu referenzieren.


73

Abbildung 4.6: Data Module - Content

Ein prozedurales Datenmodul bietet die Möglichkeit, Bedingungen bzw. Aufgaben zu defi-nieren, die nach der Ausführung der Hauptprozedur gewährleistet oder durchgeführt werdenmüssen (die „Close Requirements“). In einem EM-Task sind solche abschließende Aufgabennicht vorgesehen. Für alle konvertierten EM-Tasks wird an dieser Stelle ein leeres Element<noConds/> eingetragen.

In Abbildung 4.7 wurde beispielhaft die Abbildung der Konstrukte eines EM-Tasks und Da-tenmoduls dargestellt.

Abbildung 4.7: Task vs. Data Module


74

Die ausführliche Beschreibung der Konvertierung von einzelnen Elementen wird in den fol-genden Abschnitten vorgestellt.

4.3.2.1 Transformation von ATA iSpec 2200 Task Prerequisites in S1000D PreliminaryRequirements

Im Falle, dass vor der Ausführung einer Aufgabe, die in einem EM-Task beschrieben wird,eine bzw. mehrere Vorbereitungsschritte notwendig sind, werden Vorbedingungen definiert -die sogenannten Task Prerequisites (bzw. Pretopics in einem AMM). Diese beschreiben z. B.die notwendige Ausstattung eines Mechanikers oder Arbeitsschritte, die vor dem Beginnder eigentlichen Prozedur bereits ausgeführt werden sollten, damit die Durchführung derhervorstehenden Aufgabe möglich ist. Eine solche Möglichkeit bietet ebenso die S1000D mitdem Konstrukt der Preliminary Requirements. Diese werden jedoch in Kategorien unterteilt,die die Voraussetzungen aufteilen. Beispielhaft sind Kategorien für das notwendige Personal,Tools oder bereits durchgeführte Arbeitsschritte definiert (siehe 4.1).

Tabelle 4.1: Task Prerequisites vs. Preliminary Requirements

ATA iSpec 2200 S1000DTask Front Matter <tfmatr> Preliminary Requirements

<preliminaryRqmts>Task Prerequisites <tprereq> Production Maintenance Data

<productionMaintData>Required Conditions <reqCondGroup>Required Persons <reqPersons>Required Technical Information<reqTechInfoGroup>Required Support Equipment<reqSupportEquips>Required Supplies <reqSupplies>Required Spares <reqSpares>Required Safety <reqSafety>

Eine generische Gruppe der Vorbedingungen ist nicht vorhanden. Eine solche Aufteilung istin einem EM-Task nicht gegeben und somit ist eine direkte Überführung der Task Prerequi-sites in Preliminary Requirements nicht ohne weiteres möglich. In der praktischen Realisie-rung wurde in dieser Arbeit auf das Konvertieren der Task Prerequisites verzichtet. Für dieVollständigkeit der Transformation sowie um eine Informations-verlustfreie Konvertierung zugewährleisten, müssten diese Inhalte zu S1000D übertragen werden. Für die Durchführungeiner Prozedur sind sowohl die in der Prozedur selbst beschriebenen Aufgaben, als auch die


75

definierten Vorbedingungen notwendig, da ansonsten unvollständige und ggf. irreführendeInformationen vorliegen.

Mögliche Lösungsansätze

Eine Konvertierung der in einem Engine Manual vorhandenen Task Prerequisites in dieS1000D Preliminary Requirements ist durch manuelle Zuordnung der Inhalte der definiertenVorbedingungen in die einzelne Gruppen, die die S1000D vorsieht, möglich. Da diese Lö-sung einen großen Aufwand und Spezialwissen erfordert, wird sie im Rahmen dieser Arbeitnicht realisiert. Falls dieser Lösungsweg gewählt wird, muss der Aufwand einer manuellenZuordnung hingenommen werden, da ein Verlust dieser Inhalte eine unvollständige Doku-mentation als Ergebnis der Konvertierung erzeugen würde.

Ein weiterer Lösungsansatz besteht darin, die Inhalte der Task Prerequisites in die Hauptpro-zedur (Task) zu übernehmen. Somit kann ein Datenverlust vermieden werden, jedoch lässtdiese Lösung inhaltliche Vermischung der Informationen zu und wird deswegen in dieserArbeit nicht umgesetzt.

4.3.2.2 Transformation von Task Procedure in Main Procedure

Anders als in einer Prozedur im S1000D-Datenmodul, kann in einem EM-Task der Prozedur-teil <taskProc>, der die eigentliche Prozedur beschreibt, entfallen. Falls ein Task nur ausTask Prerequisites besteht, wird in der Realisierung die Main Procedure mit einem Procedu-ral Step eingefügt, der den Titel „NO PROCEDURAL STEP“ enthält. In einem XML-Schemafür prozedurale Datenmodule ist nicht zugelassen, dass eine Prozedur ohne den Hauptteil(Inhalt des prozeduralen Schrittes) erstellt werden kann. In einem Task des Engine Manualsist es möglich, ein Task zu definieren, ohne dass dieser eine Prozedur enthält. Die Tabelle4.2 stellt die einzelnen Elemente eines Tasks und eines Datenmoduls gegenüber.

Tabelle 4.2: Task vs Data Module - Inhalte

ATA iSpec 2200 Task S1000D ProcedureTask Front Matter <tfmatr>(implied)

Preliminary Requirements<preliminaryRqmts>(required)

Task Procedure <taskproc>(implied)

Main Procedure <mainProcedure>(required)

nicht vorhanden Close Requirements <closeRqmts>(required)


76

In einer Task-Prozedur sowie der Hauptprozedur (Main Procedure) eines Datenmoduls, wer-den alle Arbeitsschritte beschrieben, die zur Durchführung der Wartungsarbeiten notwendigsind. Ein EM-Task kann eine Reihe von Prozeduren enthalten (Element <taskproc>),die den prozeduralen Schritten eines Datenmoduls entsprechen (<proceduralStep>-Element). Attribute, die einem Task oder einer Prozedur zugeordnet sind, aber keine Ent-sprechung in den Datenmodul-Attributen haben, werden nicht übertragen. Dies sind z. B.:

• Task

– alunqi

– breaknbr

– confnbr

• Procedure

– alt

Die optionalen Attribute eines Datenmoduls, die keine Entsprechung in einem EM-Task ha-ben, werden in dem Vorgehen nicht gefüllt. Dies trifft beispielsweise folgende Attribute:

• Procedural Step

– itemCharacteristic

– changeType

– skillLevelCode

• Procedure Title

– securityClassification

– commercialClassification

Die eigentlichen Schritte einer Prozedur können beliebig oft in einem Task sowie in einemDatenmodul wiederholt werden. Diese können Inhalte wie z. B. Tabellen, Listen (nummeriertbzw. nicht nummeriert), Warnings, Grafiken oder Multimedia-Daten enthalten. Die Übertra-gung der einzelnen Inhaltsmodelle wurde im Abschnitt 3.3 beschrieben.

Subtasks

In einem ATA iSpec 2200 Manual können einzelne Schritte einer Prozedur durch ein Subtask-Konstrukt gekapselt werden. Dies ist ein spezifisches Element einer Dokumentation nachiSpec und kann auf kein vergleichbares Konstrukt der S1000D abgebildet werden. Die Kap-selung einer Prozedur durch einen Subtask hat die Aufgabe einer logischen Trennung der


77

Inhalte innerhalb eines Tasks. Für einen Manual-Benutzer wird lediglich durch ein Subtask-Titel ersichtlich, dass eine Prozedur in einem Subtask angeordnet ist. Für die Konvertierungwird der Titel des Subtasks auf ein <para>-Element eines Datenmoduls abgebildet, wo-durch ein optisch ähnliches Ergebnis für den Endanwender erreicht werden kann. Die Kap-selung wird somit aufgehoben, da sie keine funktionale Bedeutung für die Handhabung einerProzedur hat.

5 Bewertung

5.1 Zusammenfassung

Im Rahmen dieser Arbeit wurde eine Untersuchung der Spezifikationen für technische Doku-mentation ATA iSpec 2200 und S1000D durchgeführt. Eine Gegenüberstellung ausgewähl-ter Konzepte hat die Gemeinsamkeiten und Unterschiede verdeutlicht. Beide Spezifikationenwurden entwickelt, um die Handhabung von strukturierten Dokumenten zu beschreiben undzu standardisieren. ATA iSpec 2200 ist in ihrem Einsatzgebiet auf die zivile Luftfahrtindus-trie beschränkt, während S1000D den Ursprung im militärischen Bereich hat, aber für jegli-che Form der technischen Dokumentation geeignet ist. Dies hat zufolge, dass Eigenschaftenvon Dokumentation nach iSpec, die spezifisch für Luftfahrtdokumente entwickelt wurde, nichtvollständig auf allgemeine Konstrukte in S1000D abgebildet werden können.

Beide Spezifikationen haben zunächst das SGML-Format verwendet. Im Laufe der Entwick-lung wurde das Format der S1000D-Dokumente auf XML geändert. Die SGML-Dokumentenach ATA iSpec 2200 wurden mit einer bestehenden Anwendung der Lufthansa Systems indas XML-Format überführt. Die Einheitlichkeit der Formate hat es ermöglicht, eine Transfor-mation der Dokumente mit Hilfe von XSLT durchzuführen.

In der Arbeit wurde ein iSpec Wartungsdokument vom Typ Engine Manual beispielhaft nachS1000D überführt. Hierbei wurde gezeigt, dass Inhaltsmodelle wie z. B. Tabellen, Listen oderGrafiken, die durch beide Standards unterstützt werden, direkt aufeinander abgebildet wer-den können. Da beide Standards für diese Inhaltsmodelle dieselbe Ausdrucksstärke besit-zen, ist eine automatisierte Transformation mittels XSLT durchführbar (siehe Abschnitt 3.3).Auch Referenzen und Revisionsinformationen (siehe Abschnitte 3.6 und 3.8) sowie War-nings, Cautions und Notes (siehe Abschnitt 3.7) konnten so transformiert werden.

Das Nummerierungssystem der ATA iSpec 2200 wurde auf den Data Module Code derS1000D abgebildet. Beide Systeme stellen strukturierte Bezeichner dar, die durch die je-weilige Spezifikation definiert sind. Teile des Nummerierungssystems der ATA iSpec 2200hatten eine direkte Entsprechung im DMC der S1000D und konnten direkt übertragen wer-den. Andere, luftfahrtspezifische Teile der Nummerierung waren in der Form nicht in S1000Dvorgesehen. Hierfür wurden Lösungen vorgestellt (siehe Abschnitt 3.2.3).

Die Hierarchisierungs-Konstrukte Pageblock, Task und Subtask der ATA iSpec 2200 habenkeine direkte Entsprechung in der S1000D. An dieser Stelle verfolgen die Spezifikationen

5 Bewertung 79

verschiedene Ansätze des Dokumentenaufbaus. S1000D fordert voneinander unabhängi-ge Module, die zum Erstellungszeitpunkt einer solchen Hierarchisierung widersprechen. Eswurden Lösungswege aufgezeigt und diskutiert, um auch diese Elemente automatisiert inDatenmodule übertragen zu können (sieh Abschnitt 4.2).

5.2 Bewertung

Die Untersuchung der Spezifikationen für technische Dokumentation, ATA iSpec 2200 undS1000D, wurde am Beispiel von ausgewählten Konstrukten durchgeführt. Die Analyse hatgezeigt, dass ähnliche Inhaltsmodelle, wie z. B. Tabellen, Listen, oder Grafiken, durch bei-de Spezifikationen beschrieben werden und dieselbe Ausdrucksstärke bieten. Diese Inhaltekonnten ohne Informationsverluste übertragen werden. An dieser Stelle hat sich XSLT alsein geeignetes Werkzeug zur automatischen Transformation bewährt.

Die Konstrukte, die den hierarchischen Aufbau des Dokumentes widerspiegeln, konntennur teilweise übertragen werden, da S1000D unabhängige Datenmodule verlangt. So istbeispielsweise die Hierarchie der Elemente Pageblock, Task und Subtask durch die Trans-formation verloren gegangen. Diese Abhängigkeiten der Informationen untereinander kannzum Erstellungszeitpunkt im Ansatz der S1000D nicht abgebildet werden. Zum Publikations-zeitpunkt kann der hierarchische Aufbau des Dokumentes jedoch wiederhergestellt werden,sodass für einen Endanwender kein Nachteil in der Nutzung der Dokumentation durch dieTransformation besteht. Infolgedessen wurden auch die Konstrukte Chapter, Section undSubject der ATA iSpec 2200 nicht berücksichtigt. Diese Hierarchien stellen jedoch relevan-te Informationen dar und müssten im Publikationsschritt berücksichtigt werden. Im Rahmendieser Arbeit wurde jedoch lediglich die Erstellung von S1000D-Datenmodulen behandelt.

Dadurch, dass ATA iSpec 2200 ausschließlich für den Luftfahrtbereich entwickelt wurde, be-sitzt diese Spezifikation spezielle Konstrukte. Hierzu zählt z. B. das Nummerierungssystem,das den hierarchischen Aufbau der Dokumente widerspiegelt. Dies wird nur teilweise in die-ser Form durch S1000D unterstützt. Da diese Spezifikation einen allgemeinen Standard fürtechnische Dokumente darstellt, ist die Unterstützung der luftfahrtspezifischen Aspekte deriSpec nicht vollständig vorhanden. Die Sequenznummer der TOSS-Nummerierung besitztkeine direkte Entsprechung im DMC. Hierfür wurde eine Lösung vorgestellt, die eine vollstän-dige Übertragung der TOSS-Nummerierung ermöglicht, wobei die Aussagekraft und Lesbar-keit einiger Teile des DMC darunter leidet. Die Nützlichkeit dieses Work-Arounds muss sichim praktischen Einsatz beweisen.

Weiterhin wurde gezeigt, dass unterschiedliche Ansätze des Dokumentenaufbaus verfolgtwerden. Dieser Aspekt hat zu einer Untersuchung möglicher Übertragungswege der Doku-mentinhalte geführt. Ein Lösungsweg, der die Aufteilung eines iSpec Engine Manuals auf derTask-Ebene vorsieht, wurde empfohlen und für die Transformation verwendet. Somit wurde

5 Bewertung 80

gezeigt, wie ein ATA iSpec Beispieldokument erfolgreich modularisiert werden kann und da-durch der Ansatz eines modularen Aufbaus von Dokumenten in S1000D verfolgt wird.

Die Analyse der Dokumentinhalte hat gezeigt, dass eine XSL-Transformation eine geeigneteMethode zur Überführung der Inhalte eines iSpec Engine Manuals zu S1000D Datenmo-dulen darstellt. Hierbei muss jedoch beachtet werden, dass nicht alle Inhalte auf diesemWege übertragen werden können, da manuelle Zuordnung z. B. der Vorbedingungen einesEM-Tasks für eine Informations-verlustfreie Konvertierung notwendig ist.

Das Transformieren der Task-Vorbedingungen konnte nicht realisiert werden, da die Kate-gorisierung der möglichen Vorbedingungen in S1000D viel detaillierter ist. Die Durchführungder Übertragung ist ein wichtiger Teil der Transformation, würde aber den Rahmen dieser Ar-beit überschreiten. Eine geeignete Überführung bedarf eines manuellen Eingriffs sowie desFachwissens auf diesem Gebiet.

Das Applicability-Modell (Effectivity), das durch beide Spezifikationen ähnlich gehandhabtwird, konnte am Beispiel des Engine Manuals nicht transformiert werden. Die Vielfalt undmangelnde Strukturierung der Effectivity-Informationen im EM sowie das Fehlen einer Cross-Reference Table, so wie sie im AMM vorhanden ist, würde eine manuelle Übertragung derApplicability-Informationen in die S1000D Strukturen erfordern.

Die Business Rules für die transformierten Datenmodule wurden nicht definiert, da die Hin-weise bzgl. der Erstellung von BR-s in der Spezifikation 1000D nicht vorhanden sind und inspäteren Versionen ergänzt werden sollen.

5.3 Ausblick

Neben den Aspekten, die im Laufe dieser Arbeit behandelt und erfolgreich transformiert wur-den, bestehen weiterhin offenen Themen, die in dieser Arbeit nicht bearbeitet wurden. Hier-zu zählt z. B. die Erstellung der Business Rules, die erst in einer zukünftigen Fassung derS1000D spezifiziert werden. Außerdem wurde lediglich das Engine Manual und auszugs-weise das Aircraft Maintenance Manual betrachtet. Sowohl für die BR-s, als auch für dierestlichen iSpec-Manuals müssten weitere Untersuchungen angestrengt werden.

Die oben genannten Aspekte, wie z. B. Applicability, die einen manuellen Aufwand erfordern,müssten in Zukunft bearbeitet werden, um einen Informationsverlust bei der Transformationzu vermeiden.

Aufgrund des Umfangs der beiden Spezifikationen, die jeweils mehrere tausend Seiten um-fassen, konnte nur ein kleiner Ausschnitt berücksichtigt werden. Erwähnenswert sind dieArbeiten der Civil Aviation Working Group (CAWG)1. Diese beschäftigt sich ausführlich mit

1http://www.ataebiz.org/

http://www.ataebiz.org/

5 Bewertung 81

der Integration der ATA iSpec 2200 in S1000D und präsentiert regelmäßig ihre Arbeitsergeb-nisse.

Literaturverzeichnis

[AIA Product Support u. a. 2008] AIA PRODUCT SUPPORT ; TECHNICAL PUBLICATIONS

SUB-COMMITTEE ; AEROSPACE INDUSTRIES ASSOCIATION, INC.: A Recommendation tothe Department of Defense to Adopt the S1000D - the International Specification for Tech-nical Documentation. 10 2008. – URL www.aia-aerospace.org/assets/wp_s1000d-rec.pdf. – Abgerufen am 24.02.2010

[Air Transport Association 2010] AIR TRANSPORT ASSOCIATION: ATA Homepage. Websi-te. 03 2010. – URL http://www.airlines.org. – Abgerufen am 23.03.2010

[Air Transport Assotiation 2006] AIR TRANSPORT ASSOTIATION: ATA Specification 2200(iSpec 2200): Information Standards for Aviation Maintenance. 2006

[Air Transport Assotiation 2008] AIR TRANSPORT ASSOTIATION: Overview and Perspec-tive. Presentation. 10 2008. – URL http://www.ataebiz.org/forum/2008_ata_e-biz_forum_agenda/ATA_Ballance.pdf. – Abgerufen am 23.0.2010

[André u. a. 1989] ANDRÉ, Jacques (Hrsg.) ; QUINT, Vincent (Hrsg.) ; FURUTA, Richard(Hrsg.): Structured documents. New York, NY, USA : Cambridge University Press, 1989.– ISBN 0-521-36554-6

[ASD u. a. 2010] ASD ; AIA ; ATA: S1000D Homepage. Website. 02 2010. – URLhttp://s1000d.org. – Abgerufen am 14.02.2010

[ASD u. a. 2008] ASD ; ATA ; AIA: International specification for technical publicationsutilizing a common source database S1000D. 08 2008. – URL http://s1000d.org/Downloads/Pages/S1000DDownloads.aspx

[Augsburger und Malloy 2009] AUGSBURGER, Ryan ; MALLOY, Thomas: S1000D In-termediate. Presentation. 10 2009. – URL http://s1000d.org/Downloads/Documents/2009%20User%20Forum%20Presentations/US_09_S1000D_intermediate_final.pdf. – Abgerufen am 14.02.2010

[Bongers 2008] BONGERS, Frank: XSLT 2.0 und XPath 2.0. 2. Bonn : Galileo Press, 2008.– ISBN 978-3-89842-694-7

[Byrne 2006] BYRNE, Jody: Technical Translation: Usability Strategies for Translating Tech-nical Documentation. 1. Springer Netherlands, 2006

www.aia-aerospace.org/assets/wp_s1000d-rec.pdf

www.aia-aerospace.org/assets/wp_s1000d-rec.pdf

http://www.airlines.org

http://www.ataebiz.org/forum/2008_ata_e-biz_forum_agenda/ATA_Ballance.pdf

http://www.ataebiz.org/forum/2008_ata_e-biz_forum_agenda/ATA_Ballance.pdf

http://s1000d.org

http://s1000d.org/Downloads/Pages/S1000DDownloads.aspx

http://s1000d.org/Downloads/Pages/S1000DDownloads.aspx

http://s1000d.org/Downloads/Documents/2009%20User%20Forum%20Presentations/US_09_S1000D_intermediate_final.pdf




[Continental DataGraphics Ltd. 2007] CONTINENTAL DATAGRAPHICS LTD.: Basic S1000DComparison with Traditional Documentation Methods. 2007. – URL http://www.s1000d.net/s1000d-comparison.pdf. – Abgerufen am 14.02.2010

[Continental DataGraphics Ltd. 2010] CONTINENTAL DATAGRAPHICS LTD.: S1000D.net.Website. 03 2010. – Abgerufen am 15.06.2010

[Crowell Solutions 2010] CROWELL SOLUTIONS: S1000D Business Rules.Website. 05 2010. – URL http://www.crowsol.com/services/S1000DBusinessRules. – Abgerufen am 15.05.2010

[Day 2010] DAY, Mike: Business rules. Overview - making S1000D work for you. Presenta-tion. 10 2010. – URL http://www.ataebiz.org/forum/2008_ata_e-biz_forum_agenda/BusinessRules_Day.pdf. – Abgerufen am 22.04.2010

[Ericsson 2008] ERICSSON, Svante: S1000D - A tutorial. Presentation. 10 2008

[Fischer 2007] FISCHER, Detlev: A theory of presentation and its implications for the designof online technical documentation. Website. 2007. – URL http://www.oturn.net/top/App-II.html. – Abgerufen am 31.05.2010

[Harold und Means 2004] HAROLD, Elliotte R. ; MEANS, W. S.: XML in a nutshell. O’ReillyMedia, 2004

[HiCo und Aviation Service Network 2009] HICO ; AVIATION SERVICE NETWORK: HiCoStandardschulung. Presentation. 10 2009

[Kissinger 2010] KISSINGER, Robert: Implementation of Real-Time Electronic Delivery ofTechnical Publications. Presentation. 05 2010

[Lufthansa Systems 2007] LUFTHANSA SYSTEMS: DocCreate Client User Manual. Manu-al. 09 2007

[Mayer 2010] MAYER, Gary: Transforming ATA iSpec 2200 to S1000D. Presentation. 052010. – URL http://www.ataebiz.org/forum/2010_ata_e-biz_forum/Mayer_Transforming2200toS1000D.pdf. – Abgerufen am 01.07.2010

[Neitzke 2002] NEITZKE, Michael: ATA iSpec 2200 - Nutzen für Endandender. Presentati-on. 04 2002

[Rey 2010] REY, Michael: Manufacturer abilities in ATA and S1000D standards use formultiple aircraft programs. Presentation. 05 2010. – URL http://www.ataebiz.org/forum/2010_ata_e-biz_forum/Rey_Mfr_Abilities.pdf. – Abge-rufen am 15.06.2010

[van Rotterdam 2008] ROTTERDAM, Jeroen van: S1000D Applicability Model. Pre-sentation. 10 2008. – URL http://www.ataebiz.org/forum/2008_ata_e-biz_forum_agenda/Applicability_vanRotterdam.pdf. – Abgerufenam 18.05.2010

http://www.s1000d.net/s1000d-comparison.pdf

http://www.s1000d.net/s1000d-comparison.pdf

http://www.crowsol.com/services/S1000DBusinessRules

http://www.crowsol.com/services/S1000DBusinessRules

http://www.ataebiz.org/forum/2008_ata_e-biz_forum_agenda/BusinessRules_Day.pdf

http://www.ataebiz.org/forum/2008_ata_e-biz_forum_agenda/BusinessRules_Day.pdf

http://www.oturn.net/top/App-II.html

http://www.oturn.net/top/App-II.html

http://www.ataebiz.org/forum/2010_ata_e-biz_forum/Mayer_Transforming2200toS1000D.pdf

http://www.ataebiz.org/forum/2010_ata_e-biz_forum/Mayer_Transforming2200toS1000D.pdf

http://www.ataebiz.org/forum/2010_ata_e-biz_forum/Rey_Mfr_Abilities.pdf

http://www.ataebiz.org/forum/2010_ata_e-biz_forum/Rey_Mfr_Abilities.pdf

http://www.ataebiz.org/forum/2008_ata_e-biz_forum_agenda/Applicability_vanRotterdam.pdf

http://www.ataebiz.org/forum/2008_ata_e-biz_forum_agenda/Applicability_vanRotterdam.pdf


[Saffady 1997] SAFFADY, William: The Document Life Cycle: A White Paper. Whitepaper.03 1997

[Scholz 2002] SCHOLZ, Dieter: Standards als Mittel zur unternehmensübergreifendenZusammenarbeit in der Luftfahrt-Industrie. Whitepaper. 04 2002

[Vonhoegen 2005] VONHOEGEN, Helmut: Einstieg in XML. Galileo Press, 2005

[Weidenbrück 1998] WEIDENBRÜCK, Sigrid: Preparing intelligent graphics for interactivecatalogs. 05 1998

Versicherung über Selbständigkeit

Hiermit versichere ich, dass ich die vorliegende Arbeit im Sinne der Prüfungsordnung nach§22(4) bzw.§24(4) ohne fremde Hilfe selbständig verfasst und nur die angegebenen Hilfsmit-tel benutzt habe.

Hamburg, 24. August 2010 Karolina Bernat