Zum Inhalt springen
Schiffbau & Maritime technische-dokumentationbetriebsanleitungklasifikation

KI-gestützte technische Dokumentation für Schiffskomponenten

Technische Redakteure in Werften und Zulieferern erstellen Betriebsanleitungen und Wartungshandbücher für Schiffskomponenten oft manuell aus Konstruktionsdaten. KI halbiert den Erstellungsaufwand und erhöht Konsistenz.

Worum geht's?

Es ist Montag, 8:15 Uhr, und Thomas Brandt, Technischer Redakteur bei einer Werft in Rostock, öffnet die Aufgabenliste für die Woche. Zwölf Kapitel Betriebsanleitung für die neue Pumpeneinheit im Maschinenraum — Erstversion bis Freitag, weil der Surveytermin mit DNV für übernächsten Dienstag bestätigt ist.

Thomas hat die Konstruktionsdaten aus dem PLM-System, ein SAP-Datenblatt mit 340 Feldern und drei handgeschriebene Seiten Notizen vom Konstrukteur. Was er nicht hat, ist eine aktuelle Vorlage, die schon mal durch eine DNV-Prüfung gelaufen ist. Die letzte ähnliche Anlage — andere Baureihe, ähnliche Pumpenklasse — hat sein Vorgänger 2019 dokumentiert und ist inzwischen in Rente.

Thomas verbringt Dienstag und Mittwoch damit, Textbausteine aus der alten Dokumentation herauszukopieren, an die neue Komponente anzupassen und dabei dreimal die Konstruktionsabteilung anzurufen, weil er nicht sicher ist, ob die Druckangaben für die neue Variante identisch sind. Am Donnerstagabend ist Version 1 fertig. Am Freitag schickt der Konstrukteur eine Korrektur: Die maximale Betriebstemperatur war falsch übernommen.

Das Survey-Gespräch am Dienstag verläuft trotzdem. Aber Thomas fragt sich, warum das 2025 immer noch so läuft.

Das echte Ausmaß des Problems

Technische Dokumentation ist im Schiffbau keine Nebensache. Klassifikationsgesellschaften wie DNV, Bureau Veritas oder Lloyd’s Register prüfen bei jedem Newbuilding systematisch, ob alle Komponenten vollständig und korrekt dokumentiert sind. Fehlt ein Kapitel, sind Druckangaben widersprüchlich oder fehlt ein Nachweis, verzögert sich der Survey — und damit die Inbetriebnahme des Schiffs. Liegezeiten von Tagen bis Wochen kosten Werften im schlimmsten Fall Konventionalstrafen und Folgeauftragsrisiken.

Eine mittelgroße Werft mit zehn bis zwanzig Neubauten pro Jahr hat technische Redakteure, die im Schnitt 300 bis 600 Handbuchkapitel pro Jahr erstellen und aktualisieren — für Hauptmaschinen, Hilfsaggregate, Navigations-, Sicherheits- und Rettungssysteme. Viele dieser Kapitel haben eine Ähnlichkeit von 60 bis 80 Prozent mit Vorgängerversionen, werden aber trotzdem von Grund auf neu geschrieben oder aufwändig kopiert und angepasst, weil automatisierbare Extraktion aus PLM-Systemen selten eingerichtet ist.

Dazu kommt die Sprachenfrage: Dokumentation für internationale Kunden muss oft auf Englisch, Chinesisch, Griechisch oder Arabisch geliefert werden. Manuelle Übersetzung kostet Wochen und vervielfacht den Aufwand.

Laut einer Studie des VDI (Verband Deutscher Ingenieure) zu technischer Dokumentation im Maschinenbau verbringen technische Redakteure bis zu 40 Prozent ihrer Arbeitszeit mit Recherche, Copy-Paste-Adaption und Konsistenzprüfungen — Tätigkeiten, bei denen KI direkt eingreifen kann.

Mit vs. ohne KI — ein ehrlicher Vergleich

KennzahlOhne KIMit KI-Unterstützung
Erstellungszeit je Handbuchkapitel4–8 Stunden1,5–3 Stunden
Konsistenzprüfung über VariantenManuell, fehleranfälligAutomatisch über alle Varianten
Übersetzungsaufwand je Sprache2–5 Tage je Sprache30–60 Minuten (Post-Editing)
Nacharbeiten nach DNV-Feedback1–3 Zyklen üblichHäufig 0–1 Zyklus
Schulungszeit neue Redakteure3–6 Monate bis produktiv4–8 Wochen bis produktiv

Die Zeitangaben basieren auf Praxisberichten aus Maschinenbau- und Schiffbau-Dokumentationsprojekten; die Branchenwerte sind erfahrungsgemäß ähnlich. Reduzierte Nacharbeitszyklen hängen stark davon ab, wie gut die Vorlage auf die Klassifikationsanforderungen kalibriert ist.

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5) Technische Dokumentation ist im Schiffbau einer der größten Zeitfresser im Konstruktions- und Genehmigungsprozess. KI kann direkt in der Erstellungsphase eingreifen: Entwürfe aus PLM-Attributen generieren, Vorgängerdokumentation adaptieren, Übersetzungen in Minuten statt Tagen liefern. In dieser Kategorie ist der Zeiteffekt einer der höchsten, weil der Status-quo-Aufwand besonders hoch ist.

Kosteneinsparung — niedrig (2/5) Die eingesparte Zeit schlägt indirekt als Kapazitätsgewinn durch — ein technischer Redakteur kann mehr Projekte gleichzeitig bearbeiten oder früher liefern. Direkte Kosteneinsparung ist schwer zu isolieren, weil technische Redakteure in der Regel Festangestellte sind und die freigesetzte Zeit nicht automatisch in Einsparungen mündet. Wer externe Technische Redakteure oder Übersetzungsbüros beauftragt, kann dagegen direktere Kostensenkungen messen.

Schnelle Umsetzung — hoch (4/5) Ein erster Pilotbetrieb mit ChatGPT oder Claude braucht keine IT-Integration — nur strukturierte Vorlagen, ein sauberes Übergabeformat aus dem PLM-System und einen geschulten Redakteur, der lernt, Prompts effektiv zu formulieren. Das ist innerhalb von zwei bis vier Wochen möglich. Vollständige Integration in Teamcenter oder andere PLM-Umgebungen dauert länger, ist aber nicht Voraussetzung für echten Nutzen.

ROI-Sicherheit — mittel (3/5) Der Nutzen ist real und messbar — aber er hängt von der Dokumentationsfrequenz ab. Eine Werft, die zwanzig Schiffe pro Jahr baut, profitiert stark. Eine Werft mit zwei Großprojekten, die sich über Jahre erstrecken, sieht weniger Volumeneffekte. Die Messbarkeit ist hoch (Stunden je Kapitel vorher/nachher), aber die Vorhersage des konkreten ROI-Eintritts ist kontextabhängig.

Skalierbarkeit — hoch (4/5) Sobald die Prompt-Vorlagen und PLM-Übergabeformate für eine Komponentenklasse eingerichtet sind, funktionieren sie ohne Mehraufwand für alle ähnlichen Varianten. Neue Schiffstypen benötigen Anpassungen, nicht Neuentwicklungen. Wachsendes Dokumentationsvolumen schlägt nicht proportional auf den Personalaufwand durch.

Richtwerte — stark abhängig von vorhandenem PLM-System, Dokumentationsvolumen und Grad der Automatisierung.

Was das System konkret macht

Der Ansatz nutzt Generative KI als Drafting-Werkzeug: Das KI-System erhält strukturierte Eingaben aus dem PLM-System — Komponentenbezeichnung, technische Parameter, Grenzwerte, Materialnummern — und generiert daraus einen vollständigen Entwurf für ein Handbuchkapitel nach einer vorgegebenen Dokumentationsvorlage.

Das Kernprinzip ist nicht, dass die KI das Handbuch autonom schreibt. Sie erstellt einen strukturierten Rohtext, der alle technischen Kerndaten richtig platziert, die korrekte Kapitelstruktur einhält und Standardformulierungen für Sicherheitshinweise, Montageanleitungen und Wartungsintervalle einbettet. Der Technische Redakteur prüft, ergänzt kontextspezifisches Wissen und gibt frei.

Was das in der Praxis bedeutet:

Der Redakteur lädt die Komponentendaten als strukturierten Export aus Siemens Teamcenter oder einem vergleichbaren PLM in ein konfigurierbares Prompt-Template. Das Template enthält die Kapitelstruktur der Norm (z. B. DIN EN 82079 für Betriebsanleitungen) und den klassenspezifischen Anforderungskatalog des Kunden. Die KI generiert in 30 Sekunden einen vollständigen Erstentwurf über zehn bis fünfzehn Seiten. Der Redakteur verbringt dann noch eine bis anderthalb Stunden mit Prüfung, Anpassung und Freigabe — statt drei bis vier Stunden mit dem Erstellen von Grund auf.

Übersetzung als Nebeneffekt: Einmal auf Deutsch freigegeben, lassen sich Kapitel mit DeepL Pro oder integrierter LLM-Übersetzung in wenigen Minuten in andere Sprachen bringen. Post-Editing durch einen muttersprachlichen Fachübersetzer dauert dann 20 bis 45 Minuten je Kapitel statt eines vollen Arbeitstages.

Konsistenzprüfung über Varianten: plusmeta kann über eine ganze Dokumentenbasis hinweg prüfen, ob Temperaturangaben, Druckniveaus oder Sicherheitshinweise konsistent verwendet werden — und flaggt Abweichungen, bevor sie im Survey-Gespräch peinlich werden.

Konkrete Werkzeuge — was wann passt

ChatGPT oder Claude (direkter Einstieg) Für Werften und Zulieferer, die ohne IT-Projekt starten wollen: strukturierter Prompt mit Komponentendaten aus dem PLM als Texteingabe, Dokumentationsvorlage als Systemprompt. Kosten: 20–30 Euro/Monat je Nutzer. Keine Integration nötig, voller Nutzen binnen zwei Wochen. Einschränkung: Daten müssen manuell eingegeben oder eingekopiert werden — keine automatische PLM-Anbindung.

plusmeta (SCHEMA ST4 Integration) Für Technische Redaktionen, die bereits mit SCHEMA ST4 als Redaktionssystem arbeiten: plusmeta automatisiert Metadatenvergabe, Klassifikation und Konsistenzprüfung direkt im Redaktionssystem. Besonders wertvoll bei variantenreichen Komponentenportfolios — zum Beispiel bei Pumpen, Ventilen oder Steuerungssystemen in mehreren Baureihen. Einstieg ab ca. 800–2.000 Euro/Monat für kleine Redaktionsteams.

Siemens Teamcenter mit Copilot-Funktion Für Werften, die Teamcenter bereits im Einsatz haben: der Teamcenter Copilot ermöglicht natürlichsprachliche Abfragen der Produktstruktur und kann Dokumentationsentwürfe direkt aus dem BOM-Kontext generieren. Integration in bestehende Workflows ist hoch — allerdings setzt das das Teamcenter-Ökosystem voraus und der Nutzungsumfang des Copilot ist noch begrenzt.

Azure Document Intelligence (für Bestandsdokumentation) Wenn ältere Dokumentation als gescannte PDF oder Word-Datei vorliegt: Azure Document Intelligence extrahiert strukturierten Text aus unstrukturierten Dokumenten, der dann als Input für KI-Adaptionen dient. Besonders nützlich beim Überarbeiten von Schiffsunterlagen, die seit Jahren nicht mehr aktualisiert wurden. EU-Hosting verfügbar.

Wann welcher Ansatz:

  • Soforteinstieg ohne IT-Projekt → ChatGPT oder Claude mit Prompt-Vorlage
  • SCHEMA ST4 bereits im Einsatz → plusmeta
  • Teamcenter-Ökosystem vorhanden → Teamcenter Copilot
  • Bestandsdokumentation digitalisieren → Azure Document Intelligence zuerst

Datenschutz und Datenhaltung

Technische Dokumentation für Schiffskomponenten enthält häufig proprietäre Konstruktionsdaten, die unter Geheimhaltungsvereinbarungen mit Auftraggebern stehen. Bevor Komponentendaten in ein KI-System eingegeben werden, ist zu prüfen, welche Daten als vertraulich klassifiziert sind.

Konkrete Hinweise je Tool:

ChatGPT (OpenAI) verarbeitet Daten standardmäßig in den USA. Für Unternehmen mit vertraulichen Konstruktionsdaten empfiehlt sich entweder der ChatGPT Enterprise-Plan mit AVV-Option oder der Wechsel zu einem EU-gehosteten Anbieter. Claude (Anthropic) bietet über die API und Claude.ai Enterprise eine AVV-Vereinbarung gemäß DSGVO Art. 28.

plusmeta ist EU-gehostet und ISO/IEC 27001-zertifiziert — geeignet für sensible Konstruktionsdaten. Siemens Teamcenter läuft in der Cloud-Variante (Teamcenter X) auf EU-Infrastruktur; On-Premises-Deployment ist möglich.

Für Werften mit Verteidigungsaufträgen gilt: Klassifizierte oder ITAR-relevante technische Daten dürfen grundsätzlich nicht in kommerzielle Cloud-KI-Dienste eingegeben werden. Hier ist On-Premise-Deployment mit einem deutschen oder EU-Sprachmodell erforderlich.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

  • Prompt-Vorlagen entwickeln und kalibrieren: 3–8 Tage intern (Redakteur + ggf. KI-Berater)
  • Schulung der technischen Redakteure auf KI-gestütztes Drafting: 1–2 Tage
  • Kosten externer Einrichtungsbegleitung (optional): 2.000–6.000 Euro

Laufende Kosten (monatlich)

  • ChatGPT Plus/Team oder Claude Pro/Team: 20–30 Euro/Nutzer/Monat
  • plusmeta: ab ca. 800 Euro/Monat für kleine Teams
  • Teamcenter Copilot: in Teamcenter-Lizenz integriert, kein separater Aufpreis

Was dagegen steht Ein technischer Redakteur im Schiffbau kostet inklusive Nebenkosten rund 50–80 Euro/Stunde. Wenn KI täglich zwei Stunden Routinearbeit übernimmt, sind das 400–800 Euro täglich. Bei drei Redakteuren und 220 Arbeitstagen entstehen Einsparungen im sechsstelligen Bereich jährlich — wenn die freigesetzte Kapazität für höherwertige Tätigkeiten genutzt wird. In der Praxis ist der realisierte Effekt erfahrungsgemäß näher an 30–50 Prozent davon, weil Anlaufzeiten, Qualitätsprüfung und Ausnahmen die theoretische Zeitersparnis reduzieren.

Wie du den ROI tatsächlich misst Zähle vor Einführung über vier Wochen: Wie viele Handbuchkapitel wurden erstellt? Wie viele Stunden je Kapitel? Wiederhole nach drei Monaten. Die Vergleichszahl ist dein ROI-Nachweis.

Drei typische Einstiegsfehler

1. Die KI direkt ins Klassifikationssystem einreichen wollen. KI-generierte Erstentwürfe sind Erstentwürfe. Sie enthalten manchmal korrekte Werte in falschen Kontexten — z. B. Druckangaben, die für eine ähnliche Pumpenklasse aus dem Trainingsdatensatz stammen, aber nicht für die konkrete Baureihe gelten. Wer den generierten Text ohne Redakteursfreigabe einreicht, riskiert Survey-Verzögerungen durch technische Fehler. Lösung: KI als Drafting-Werkzeug einsetzen, das die Redakteure entlastet, aber nicht ersetzt. Die Verantwortung für die fachliche Korrektheit bleibt beim Menschen.

2. Ohne Vorlage starten. Ein LLM kann keine Handbuchstruktur erfinden, die den Klassifikationsanforderungen entspricht — es braucht eine kalibrierte Vorlage als Prompt. Wer einfach fragt “Schreib mir eine Betriebsanleitung für diese Pumpe”, bekommt etwas, das wie eine Betriebsanleitung aussieht, aber nicht die Kapitelnummern, Sicherheitshinweis-Pflichtfelder und Normanforderungen (DIN EN 82079, IEC-Normen) enthält. Lösung: Bestehende, bereits durch den Survey gegangene Dokumentation als Vorlage extrahieren und das KI-System damit kalibrieren.

3. Nur Texterstellung automatisieren, nicht die Pflege. Schiffskomponenten werden überarbeitet — neue Baureihen, geänderte Druckklassen, aktualisierte Sicherheitshinweise nach Vorkommnissen. Wer KI nur für die Ersterstellung nutzt, aber die Versionspflege manuell lässt, hat das Problem auf spätere Zeitpunkte verschoben. Das ist gefährlich, weil überarbeitete Komponenten manchmal andere Handbücher haben als nominell gleichartige Einheiten auf dem gleichen Schiff. Lösung: von Anfang an einen Review-Trigger einrichten — Änderungsanzeige im PLM löst automatisch einen Überarbeitungsprozess im Dokumentationssystem aus.

Was mit der Einführung wirklich passiert — und was nicht

Technische Redakteure reagieren auf KI-Einführung meistens nicht mit Widerstand, sondern mit einer Mischung aus Skepsis und Neugier. Was die Skepsis nährt: “Wenn das so gut funktioniert, werde ich nicht mehr gebraucht.”

Diese Sorge ist berechtigt, aber falsch adressiert. Was KI übernimmt, ist das Kopieren, Formatieren und Adaptieren von Standardpassagen — die Tätigkeiten, die die meisten Redakteure am wenigsten schätzen. Was bleibt, ist die fachliche Entscheidung: Welche Sicherheitshinweise sind für diese Komponente in diesem Betriebskontext zwingend? Welche Wartungsintervalle weichen von der Standardempfehlung ab, weil der Einsatz im tropischen Klima anders ist als im Nordmeer? Diese Fragen kann kein Modell beantworten.

Praktisch helfen zwei Maßnahmen:

Pilot mit einem echten Projekt. Nicht mit einem Testdokument — mit dem nächsten wirklichen Handbuchauftrag, den der Redakteur sowieso erledigen müsste. Wenn die KI für dieses Projekt zwei Stunden spart und die Qualität vergleichbar ist, ist das Argument viel stärker als jede Präsentation.

Redakteure in die Vorlageentwicklung einbinden. Wer die Prompt-Vorlagen selbst mitgebaut hat, versteht das System und verteidigt es. Wer das System von oben aufgedrückt bekommt, sucht zuerst nach den Fehlern.

Realistischer Zeitplan mit Risikohinweisen

PhaseDauerWas passiertTypisches Risiko
Inventur & VorlageWoche 1–2Beste vorhandene Dokumentation als Vorlage extrahieren, Prompt-Struktur entwerfenVorhandene Docs sind nicht survey-konform genug als Vorlage
PilottestWoche 2–4Einen echten Dokumentationsauftrag mit KI-Unterstützung durchführenPrompt zu generisch — Ergebnis braucht mehr Überarbeitung als erwartet
KalibrierungWoche 4–6Prompt und Vorlage auf Basis des Pilot-Feedbacks verbessernKonstrukteure liefern Daten in inkonsistenten Formaten — Extraktion aufwändiger als geplant
RolloutAb Woche 7Alle Redakteure einbinden, Prozess dokumentierenEinige Mitarbeitende nutzen das Tool nicht konsequent — Nutzungsrate messen und ansprechen

Häufige Einwände — und was dahintersteckt

“KI kann keine technisch korrekte Dokumentation schreiben.” Das stimmt, wenn man erwartet, dass die KI die Ingenieursentscheidungen trifft. Wenn die KI strukturierten PLM-Output in Fließtext nach einem vorgegebenen Schema übersetzt — das stimmt nicht. Was die KI gut kann: eine Tabelle mit Druckwerten, Temperaturgrenzen und Wartungsintervallen in Standardsätze nach einem DIN-konformen Schema verwandeln. Was der Mensch behalten muss: prüfen, ob die Werte für diese spezifische Konfiguration gelten.

“Unsere Klassifikationsgesellschaft akzeptiert das nicht.” DNV, Bureau Veritas und Lloyd’s Register prüfen das fertige Dokument, nicht die Entstehungsweise. Was zählt, ist, ob alle Pflichtkapitel enthalten sind, die technischen Angaben stimmen und die Normanforderungen erfüllt sind. Ob das in vier Stunden manuell oder in zwei Stunden mit KI-Unterstützung entstanden ist, ist für die Prüfungsgesellschaft irrelevant.

“Wir haben kein strukturiertes PLM-System.” Dann ist das der erste Schritt — nicht wegen der KI, sondern weil ohne strukturierte Produktdaten auch die manuelle Dokumentation fehleranfällig ist. Ein gut strukturiertes PLM-System ist Voraussetzung, nicht nur für KI, sondern für reproduzierbar korrekte Dokumentation überhaupt.

Woran du merkst, dass das zu dir passt

  • Du erstellst regelmäßig mehr als 50 Handbuchkapitel pro Jahr für unterschiedliche Komponentenvarianten mit hoher struktureller Ähnlichkeit
  • Deine Dokumentationserstellung ist immer im Zeitdruck wegen Survey-Terminen oder Übergabedaten
  • Technische Daten liegen strukturiert im PLM — auch wenn kein automatischer Export existiert, könnten sie als strukturierter Text übergeben werden
  • Du vergibst externe Übersetzungsaufträge und weißt, dass das Volumen und die Kosten mit KI deutlich sinken könnten
  • Neue Redakteure brauchen Monate, um den Stil und die Anforderungsstruktur zu lernen — eine gute KI-Vorlage verkürzt diese Kurve erheblich

Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:

  1. Unter 20 zu erstellenden oder zu überarbeitenden Handbuchkapiteln pro Jahr. Der Einrichtungsaufwand für Vorlagen und Prompt-Kalibrierung amortisiert sich bei niedrigem Volumen nicht.

  2. Komponentendaten liegen ausschließlich als gescannte Zeichnungen oder in Excel-Listen ohne konsistente Struktur vor. Dann ist Strukturierung der Daten der erste Schritt — KI kann aus unstrukturierten Eingaben keinen konsistenten Entwurf erzeugen.

  3. Alle Dokumentation unterliegt strengen Geheimhaltungsvereinbarungen oder ITAR-Regularien, ohne dass eine On-Premise-KI-Infrastruktur besteht. In diesem Fall ist Cloud-KI regulatorisch ausgeschlossen, bis eine sichere Alternative eingerichtet ist.

Das kannst du heute noch tun

Nimm das nächste Handbuchkapitel, das auf deiner To-do-Liste steht — idealerweise eine Variante einer Komponente, die du schon einmal dokumentiert hast. Exportiere die relevanten technischen Parameter aus eurem PLM oder Datenblatt als Text. Öffne ChatGPT oder Claude und teste folgenden Prompt:

Prompt für technischen Dokumentationsentwurf
Du bist ein erfahrener Technischer Redakteur im Schiffbau. Erstelle auf Basis der folgenden technischen Daten ein vollständiges Kapitel "[KAPITELNAME]" für die Betriebsanleitung der Komponente "[KOMPONENTENBEZEICHNUNG]". Halte dich an folgende Struktur: 1. Kurzbeschreibung der Komponente und ihres Verwendungszwecks 2. Technische Spezifikationen (als Tabelle) 3. Sicherheitshinweise (gemäß DIN EN 82079) 4. Inbetriebnahmeanweisung (nummerierte Schritte) 5. Wartungsintervalle und -maßnahmen Technische Daten: [HIER TECHNISCHE PARAMETER AUS PLM EINFÜGEN — z. B. Nenndruck, Temperaturbereich, Förderleistung, Werkstoff, Gewicht, Anschlussmaße] Verwende konservative, normkonforme Formulierungen für Sicherheitshinweise. Markiere jede Stelle, bei der du dir unsicher bist oder ein Wert fehlt, mit [PRÜFEN: Begründung].
Funktioniert mit ChatGPT, Claude
Beispiel-Ausgabe

Mitarbeiter:in

Erstelle Kapitel 'Betrieb' für Kreiselpumpe KP-450. Nenndruck: 16 bar, Förderleistung: 450 m³/h, Mediumtemperatur: -10 bis +90 °C, Werkstoff: Edelstahl 1.4408, Antriebsleistung: 75 kW, Schutzklasse: IP55

KI-Assistent

**3. Betrieb** **3.1 Kurzbeschreibung** Die Kreiselpumpe KP-450 ist eine einstufige Horizontalpumpe für den Einsatz in Schiffs-Maschinensystemen. Sie dient der Förderung flüssiger Medien in Kühl-, Heizungs- und Hilfssystemen mit erhöhten Anforderungen an Korrosionsbeständigkeit. **3.2 Technische Spezifikationen** | Parameter | Wert | |---|---| | Nenndruck | 16 bar | | Förderleistung | 450 m³/h | | Mediumtemperatur | –10 bis +90 °C | | Werkstoff (fluidberührt) | Edelstahl 1.4408 | | Antriebsleistung | 75 kW | | Schutzklasse Motor | IP55 | **3.3 Sicherheitshinweise** ⚠ WARNUNG: Bei Betrieb mit Medien über 60 °C besteht Verbrennungsgefahr an berührungsheißen Flächen. Berührungsschutz sicherstellen. ⚠ ACHTUNG: Trockenlauf ist unzulässig. Pumpe nur bei vollständig gefülltem Saugraum in Betrieb nehmen. **3.4 Inbetriebnahme** 1. Saugleitung und Pumpengehäuse vollständig füllen und entlüften 2. Absperrarmatur druckseitig schließen 3. Motor einschalten und auf Drehrichtung prüfen [PRÜFEN: Drehrichtungskennzeichnung an Pumpe vorhanden?] 4. Absperrarmatur langsam öffnen bis Betriebspunkt erreicht **3.5 Wartungsintervalle** [PRÜFEN: Herstellerempfehlung für Gleitringdichtung und Lagerlebensdauer aus technischen Unterlagen übernehmen]

Quellen & Methodik

  • Dokumentationsaufwand technische Redaktion: VDI-Richtlinie 4500 (Technische Dokumentation, Stand 2012) und Erfahrungswerte aus Maschinenbau- und Schiffbau-Dokumentationsprojekten
  • DIN EN 82079: Gültige Norm für Erstellung von Anleitungen, zuletzt überarbeitet 2021 — definiert Pflichtelemente für Betriebsanleitungen in der EU
  • Zeitvergleichswerte: Erfahrungsberichte aus technischen Redaktionsteams im Maschinenbau; übertragbare Größenordnung auf Schiffbaudokumentation
  • Survey-Anforderungen: DNV Rules for Classification of Ships (Juli 2024 Edition), Kapitel zur Dokumentationsanforderungen; Bureau Veritas Rules for Classification: Ships, Rule Note NR 600
  • ITAR-Hinweis: International Traffic in Arms Regulations (22 CFR Part 120–130); relevant für Werften mit Verteidigungsaufträgen

Diesen Inhalt teilen:

🤝

Interesse an diesem Use Case?

Schreib uns, wenn du mehr erfahren oder diesen Use Case für dein Unternehmen umsetzen möchtest. Wir melden uns zeitnah bei dir.

Deine Daten werden ausschließlich zur Bearbeitung deiner Anfrage verwendet (Art. 6 Abs. 1 lit. b DSGVO). Mehr in unserer Datenschutzerklärung.

Kostenloser Newsletter

Bleib auf dem neuesten
Stand der KI

Wähle deine Themen und erhalte relevante KI-News, Praxistipps und exklusive Inhalte direkt in dein Postfach – kein Spam, jederzeit abmeldbar.

Was interessiert dich? Wähle 1–3 Themen — du bekommst nur Inhalte dazu.

Mit der Anmeldung stimmst du unserer Datenschutzerklärung zu. Jederzeit abmeldbar.

Kostenlos
Kein Spam
Jederzeit abmeldbar