Versionen und Zuordnung
SPS-, HMI-, IPC- und weitere Softwarestände werden Maschinentypen, Varianten und – soweit möglich – dem laufenden Feldbestand zugeordnet.
Maschinenbau · Softwarepflege
Technische Bestandsanalyse, bevor aus Unsicherheit ein Großprojekt wird.
Quellstände, Builds, Bibliotheken, SPS, HMI, IPC, Kommunikation, Updatewege, Testbarkeit und Dokumentation erfassen – als technische Grundlage für Pflege, Modernisierung und belastbare Prioritäten.
Entscheidungsgrundlage
Erst den Bestand verstehen, dann das Modernisierungsprojekt zuschneiden.
Ohne Übersicht werden einzelne Auffälligkeiten schnell zu einem vermeintlichen Großprojekt. Eine technische Bestandsanalyse trennt belegte Lücken, offene Fragen und spätere Verbesserungsmöglichkeiten.
Sie ist sinnvoll, wenn der führende Quellstand unklar ist, Builds nur auf einem historischen Rechner funktionieren, Bibliotheken nicht nachvollziehbar sind oder Update, Fernwartung und Test bisher von Einzelwissen abhängen.
Maschinenverordnung und Cyber Resilience Act können Anlass sein, diese Grundlagen zu klären. Bewertet wird der technische Bestand – nicht die rechtliche Konformität.
Technische Prüffelder
Sechs Blickwinkel auf Pflegefähigkeit und Nachvollziehbarkeit.
Der vereinbarte Umfang entscheidet, welche Prüffelder vollständig, als Stichprobe oder zunächst nur über offene Fragen behandelt werden.
Werkzeuge und Reproduzierbarkeit
Engineering-Versionen, Buildschritte, Gerätebeschreibungen, Lizenzen und notwendige Umgebungen werden auf Abhängigkeiten und Wissensinseln geprüft.
Bibliotheken und Schnittstellen
Interne und externe Bibliotheken, Protokolle, Datenflüsse sowie Übergänge zwischen SPS, HMI, IPC, Netzwerk und angebundenen Diensten werden erfasst.
Update und Fernwartung
Paketierung, Verteilung, Rückfallweg, Zugriffswege, Zuständigkeiten und beobachtbare Betriebszustände werden technisch nachvollzogen.
Tests und reale Validierung
Bestehende Prüfungen werden nach Aussagekraft getrennt: Quellcode, Build, Logik- oder DryRun-Prüfung und reale Maschine beantworten unterschiedliche Fragen.
Dokumentation und Prozess
Änderungsweg, Freigaben, bekannte Schwachstellen, Pflegeverantwortung, Wissensübergabe und offene technische Entscheidungen werden betrachtet.
Abgegrenzter Analyseauftrag
Von der Entscheidungsfrage zum priorisierten Umsetzungsweg.
Fragestellung und Stichprobe festlegen
Maschinentypen, Varianten, Softwareanteile, verfügbare Unterlagen und die anstehende Entscheidung bestimmen Tiefe und Grenzen der Analyse.
Nachweise sammeln
Projektstände, Repositories, Builds, Bibliotheken, Dokumente, Updatewege und technische Ansprechpartner werden erfasst. Herkunft und Lücken bleiben sichtbar.
Technischen Bestand bewerten
Pflegefähigkeit, Reproduzierbarkeit, Testbarkeit, Updatefähigkeit, Abhängigkeiten und Cyberresilienz werden anhand des vorhandenen technischen Materials eingeordnet.
Lücken und Risiken priorisieren
Nicht jede historische Besonderheit benötigt sofort ein Projekt. Priorisiert wird nach technischer Wirkung, Abhängigkeit und notwendiger Vorarbeit.
Umsetzungsweg beschreiben
Das schriftliche Ergebnis enthält sinnvolle Arbeitspakete, Reihenfolge, offene Entscheidungen und – soweit belastbar ableitbar – Aufwandsspannen für nächste Schritte.
Mögliche Ergebnisse
Ein Befund, mit dem technische Entscheidungen möglich werden.
Form und Detailtiefe werden vor Beginn festgelegt. Ergebnisse unterscheiden belegte Tatsachen, technische Bewertung und offene Fragen.
SystemübersichtKomponenten, Versionen und Beziehungen
Lückenbildfehlende Stände, Builds, Tests und Dokumente
PrioritätenRisiken, Abhängigkeiten und Reihenfolge
UmsetzungswegArbeitspakete, offene Fragen und Aufwandsspannen
Technische Bestandsanalyse und Umsetzung für Softwarepflege, Nachvollziehbarkeit, Testbarkeit, Updatefähigkeit und Cyberresilienz.
Klar abgegrenzter Analyseumfang mit schriftlichem Ergebnis.
Keine Rechtsberatung, Zertifizierung oder abschließende Konformitätsbewertung. Die Analyse ersetzt weder Risikobeurteilung noch externe Abnahme und garantiert keine CRA-, CE- oder sonstige Rechtskonformität.
Fragen und Grenzen
Fragen zur technischen Bestandsanalyse
Ist die technische Bestandsanalyse eine CRA- oder CE-Zertifizierung?
Nein. Sie untersucht technische Grundlagen wie Quellstände, Builds, Abhängigkeiten, Updatewege, Tests und Dokumentation. Sie ist keine Rechtsberatung, Zertifizierung, Konformitätsbewertung oder Garantie für Rechtskonformität.
Muss dafür der gesamte Maschinenbestand vollständig analysiert werden?
Nicht zwingend. Umfang und Stichprobe richten sich nach Maschinentypen, Varianten, gemeinsamen Softwarebasen und der konkreten Entscheidungsfrage. Repräsentativität und bekannte Lücken werden im Ergebnis ausdrücklich benannt.
Was wird für den Einstieg benötigt?
Hilfreich sind eine Übersicht der Maschinentypen und Varianten, verfügbare Quell- und Projektstände, Engineering-Umgebungen, Bibliotheksinformationen, Build- und Updatewege sowie vorhandene technische Dokumentation. Fehlende Unterlagen sind selbst ein relevanter Befund.
Kann aus der Analyse direkt ein Umsetzungsprojekt entstehen?
Ja, wenn die technischen Prioritäten und Verantwortlichkeiten ausreichend geklärt sind. Analyse und Umsetzung bleiben getrennte Phasen; der schriftliche Befund kann auch als Grundlage für interne Teams oder andere technische Dienstleister dienen.
Weiter im System
Bestand fachlich weiter einordnen
KONTEXTMaschinenverordnung und CRAWelche technischen Grundlagen Maschinenbauer klären sollten und wo die rechtliche Abgrenzung liegt.CODESYSCODESYS und Legacy-SteuerungenWenn die Bestandsfrage konkret CODESYS 2.3, CODESYS 3.5, Build oder Migration betrifft.UMSETZUNGSPS-ProgrammierungWenn aus einem geklärten Befund eine begrenzte Änderung an der Maschinenlogik entstehen soll.
Analyseumfang festlegen
Niemand kann belastbar sagen, welcher Softwarestand im Feld wirklich zählt?
Beschreiben Sie Maschinentypen, Varianten, verfügbare Projektstände und die anstehende Entscheidung. Daraus lässt sich ein klar abgegrenzter Analyseumfang mit schriftlichem Ergebnis bilden.