Planung für eine abgekündigte SPS-CPU mit belastbaren Daten

Sie hören, eine Referenz sei abgekündigt, und der erste Impuls ist, irgendetwas zu bestellen, bevor sie verschwindet. Halten Sie diesen Gedanken zehn Minuten zurück. Prüfen Sie den Abkündigungsstatus gegen die aktuelle veröffentlichte Herstellerinformation, nicht gegen Erinnerung oder die Erzählung einer Kollegin oder eines Kollegen. Hersteller führen Referenzen durch Lebenszyklusphasen, und ein bei der letzten Prüfung aktueller Status kann sich inzwischen verändert haben.

Vergrößertes Systemdiagramm

×

Der belastbare Weg führt über die veröffentlichte Quelle mit Datum in den Planungsdatensatz. Schwache Aussagen verweisen zur Bestätigung auf dieselbe Quelle.

Der Status kann auch nach Region und Vertriebsweg verschieden sein. Eine Referenz, die in einem Markt als Ersatzteilbestand gehandelt wird, kann in einem anderen erschöpft sein. Eine Händlerliste ist kein Nachweis wie eine Herstellerankündigung zum Lebenszyklus. Erfassen Sie, welche Quelle was und wann gesagt hat. Eine Statusnotiz ohne Datum ist nach einem Jahr nicht vertrauenswürdig, weil die Referenz weitergerückt sein kann. Eine Händlerliste kann aktuell sein und trotzdem nichts zur Abkündigung beweisen, denn Handelsbestand und Lebenszyklusstatus sind unterschiedliche Tatsachen.

Die Prüfung dauert Minuten und verankert den ganzen Plan in einer datierten, zitierbaren Quelle. Die heute erfasste Quelle ist diejenige, die Sie beim Überprüfen des Plans erneut lesen. Darum gehört die Fundstelle in den Planungsdatensatz und nicht in das Postfach einer Person. Erfassen Sie auch den Abrufweg, damit die nächste Person die Prüfung ohne Rückfrage wiederholen kann.

Hersteller führen Referenzen üblicherweise durch benannte Phasen: eine aktive Zeit, eine veröffentlichte Abkündigungsankündigung, einen letzten Liefertermin und anschließend eine unterschiedlich lange Supportphase. Die Phase Ihrer Referenz entscheidet, wie viel Zeit der Plan hat. Erfassen Sie deshalb Phasenname und Datum statt nur das Wort abgekündigt. Eine Ankündigung von vor zwei Jahren und eine vom letzten Monat beschreiben für dieselbe Referenz sehr unterschiedliche verbleibende Zeit.

Erfassen Sie genaue Referenz, Revision und Firmwarestand, solange die Einheit noch läuft. Eine funktionierende abgekündigte CPU ist selbst ein Nachweis, und sie verschwindet an dem Tag, an dem sie ausfällt. Jede Tatsache, die von der laufenden Einheit gelesen werden konnte, etwa eine vom Engineering-Tool gemeldete Firmwareversion, ist danach nicht mehr wiederzugewinnen. Das ist das stärkste Argument, früh zu dokumentieren statt erst beim Maschinenstillstand.

Vergrößertes Systemdiagramm

×

Alle drei Erfassungen haben dieselbe Frist: den Ausfalltag. Die Pfeile zeigen die Abhängigkeit von der noch laufenden Einheit.

Notieren Sie, ob ein Projekt-Backup existiert und wo es gespeichert ist. Prüfen Sie dann, ob das Backup lesbar ist, statt dies anzunehmen. Ohne nutzbares Backup wird jeder Wiederherstellungsweg schwieriger: Ein gleichwertiger Austausch wird zum Neuaufbau, eine Migration wird Programmieraufwand. Diese Tatsache gehört in den Planungsdatensatz, weil sie Kosten und Zeit jedes Wegs der Liste verändert.

Jetzt aufgenommene Typenschildfotos kosten nichts und beantworten Fragen, die keine Ersatzteilliste beantworten kann. Erfassen Sie auf gleiche Weise Trägerzusammenstellung und Netzwerkgeräteliste, weil die Abkündigungsplanung alles umfasst, was an die CPU gebunden ist, nicht nur die CPU. Dasselbe Foto verankert die Steckplatzpositionen, die Sie in jedem späteren Vergleich zitieren.

Teilen Schwesteranlagen oder Linien die Referenz, erfassen Sie auch sie, wenn auch nur kurz. Eine Zeile pro Maschine mit eigenem Schaltschrankort und Zustand verwandelt den Planungsdatensatz von einer Einheitsnotiz in eine Flottenansicht. Eine Flottenansicht verändert die Wirtschaftlichkeit: Ein gemeinsames Ersatzteil wird eher vertretbar, eine Migration betrifft mehr Einheiten, und die Dringlichkeit eines einzelnen Ausfalls wird an der Zahl der verbleibenden laufenden Einheiten gemessen.

Beschreiben Sie, was die Maschine tut und was ein CPU-Ausfall tatsächlich stoppt: eine Maschine, eine ganze Zelle oder eine Funktion mit Sicherheitsbezug. Diese Risikobeschreibung bestimmt, wie viel Dringlichkeit jeder Wiederherstellungsweg verdient und wer an der Entscheidung beteiligt werden muss. Eine CPU, die eine von fünf gleichen Linien stoppt, ist eine andere Planungsaufgabe als eine Einzelquelle, die einen ganzen Werksbereich anhält.

Vergrößertes Systemdiagramm

×

Zwei Eingaben bestimmen das Risiko: Reichweite des Ausfalls und Zahl der Bindungen, die eine Migration berührt.

Fragen Sie die Personen, die die Maschine bedienen, nicht nur die Personen, die sie instand halten. Die Betriebssicht zeigt häufig Umgehungen und Optionen an Schwesterlinien, die eine rein technische Sicht übersieht. Diese Optionen verändern, welcher Weg Investition verdient. Die Betriebssicht verändert die Frist oft ebenso sehr wie die Prioritätenliste.

Erfassen Sie auch das umgebende Umfeld: Trägerzusammenstellung, Netzwerkgeräteliste und HMI-Projekte, die auf die CPU verweisen. Der Migrationsaufwand wächst mit allem, was an die CPU gebunden ist. Ein Nachfolgervergleich für eine CPU mit drei verbundenen Projekten ist eine andere Arbeit als für eine CPU ohne solche Projekte.

Sicherheitsbezug gehört in einer eigenen Zeile in die Risikobeschreibung. Eine failsichere Anwendung verändert Beteiligte, besprechbare Wiederherstellungswege und den Umfang der erneuten Validierung einer Migration. Behandeln Sie diese Zeile als Weganweisung für den Plan, nicht als Adjektiv. Eine Risikobeschreibung, die Sicherheitsbezug nur als eine Tatsache unter mehreren aufführt, verdeckt die eine Tatsache, die alles Weitere verändert. Die Aufwandsschätzung macht auch die Migrationsroute mit den anderen vergleichbar.

Listen Sie mögliche Wege ohne sich auf einen festzulegen: Beschaffung einer passenden Einheit, einen Reparatur- oder Austauschansatz und Migration zu einer aktuellen Familie. Jeder Weg benötigt andere Nachweise. Beschaffung stützt sich auf genaue Referenz und Revision, Reparatur auf Fehlerhistorie und Fotos, Migration auf Projekt- und Netzwerkdatensätze. Die Wegliste zeigt, welche Lücken Sie vor allen anderen schließen müssen.

Vergrößertes Systemdiagramm

×

Jeder Weg nennt eigene Nachweisbedarfe. Die Lücken, nicht die Präferenz, bestimmen den nächsten Schritt.

Das Aufschreiben der Wege zeigt Optionen, die niemand bedacht hat, etwa Betriebszeit von einer Schwesterlinie zu leihen, während eine Einheit beschafft wird. Jede jetzt erfasste Bindung ist eine Unbekannte weniger bei einer späteren Migration. Die Liste verhindert auch, dass ein Druckmoment die Auswahl auf den Lieferanten verengt, der zuerst zurückruft.

Halten Sie Nachweisphase und Entscheidungsphase getrennt. Eine dokumentierte Referenz, Risikobeschreibung und Wegliste erlauben später eine geprüfte Entscheidung, ohne die Schaltschrankarbeit zu wiederholen. Sie verhindern auch, dass die Entscheidung durch einen Ausfall erzwungen wird. Eine nach jedem Ereignis geprüfte Wegliste bleibt kurz, eine erst nach Jahren betrachtete wird zur Archäologie.

Geben Sie der Wegliste einen Prüfturnus, der an reale Ereignisse statt nur an den Kalender gebunden ist. Prüfen Sie sie bei Statusänderung der Abkündigung, beim Ausfall einer Schwestereinheit oder bei der nächsten Maschinenwartung und erfassen Sie, was die Prüfung verändert hat. Eine nie erneut betrachtete Liste veraltet still, und die erste erzwungene Entscheidung trifft dann auf eine Liste, die jahrelang niemand geprüft hat.

Bestand, Lieferzeit und Migrationskosten bleiben offene Fragen, bis eine Quelle sie bestätigt. Halten Sie diese Felder ausdrücklich sichtbar und lassen Sie undatierte Behauptungen aus dem Plan. Der Datensatz soll zeigen, was bekannt ist, was angenommen wird und was noch ein Angebot oder eine Lieferantenbestätigung braucht. Eine geprüfte Entscheidung braucht diese Trennung. Jedes Feld kann sein eigenes Datum tragen, sodass die bekannte Spalte zeilenweise prüfbar bleibt.

Vergrößertes Systemdiagramm

×

Die Dreiteilung macht den Datensatz überprüfbar. Eine Entscheidung kann ihn bewerten, ohne die Historie neu herzuleiten.

Der Plan funktioniert genau wie beabsichtigt, wenn die Maschine ausfällt und die Reaktion mit einem vollständigen Datensatz statt mit hektischer Suche beginnt. Das ist die Prüfung der ganzen Übung: Der Ausfall wird zum Moment, in dem der Plan seinen Nutzen zeigt, nicht zum Moment, in dem eine Entscheidung erzwungen wird. Der Unterschied wird nur sichtbar, wenn der Plan sagt, was er erreichen sollte.

Ein Plan, der seine eigenen Lücken markiert, kann an andere Personen übergeben werden. Die nächste Person erkennt, welche Felder Tatsachen, welche Annahmen und welche Wege nie bewertet wurden. Diese Übergabequalität hält den Plan mehr als jede einzelne Tatsache über die Jahre lebendig, in denen eine abgekündigte CPU weiterlaufen kann.

• Prüfen Sie die Abkündigung anhand aktueller Herstellerveröffentlichungen und erfassen Sie Quelle und Datum.
• Erfassen Sie Referenz, Firmware, Backup-Status und Maschinenrisiko, solange die Einheit noch läuft.
• Listen Sie Beschaffung, Reparatur oder Austausch und Migration und schließen Sie die Nachweislücken jedes Wegs.
• Bestand und Lieferzeit bleiben offen, bis eine Quelle sie bestätigt.

• den SPS- und CPU-Bereich von Ardkor
• wie eine Nachfolgerreferenz verglichen wird
• Nachweise für Reparatur gegenüber Ersatz