10 Jun Validierung von MES-Rezepten

1. Muss man MES-„Rezepte“ validieren?

Um die bewusst provokativ gestellte Frage zu beantworten, muss ich ein leider wenig ausholen, um Ihnen meine Sichtweise auf Manufacturing Execution Systeme und deren Rezepte darzulegen, also sozusagen, um Sie „abzuholen“.
Ich halte diesen Teil aber so knapp wie möglich, um schnell zum entscheidenden Punkt zu kommen. Dadurch werden die Ausführungen zu MES und den Rezepten keinen Anspruch auf Vollständigkeit erheben können.

2. Was ist ein MES?

Die Abkürzung MES steht für „Manufacturing Execution System“. Im deutschen wird z.T. der Begriff Produktionsleitsystem verwendet. Die Norm ANSI/ISA-95 stellt die Integration von Unternehmens- und Betriebsleitebene dar und beschreibt Manufacturing Execution Systeme als Level 3, also als Bindeglied zwischen der Betriebsleitebene (ERP System) in Level 4 und der Überwachungsebene (SCADA – Supervisory Control And DATA Aquisition) in Level 2.

Ein MES stellt den systematischen Ablauf der einzelnen Produktionsschritte sicher, die notwendig sind, um ein entsprechendes Produkt gleichbleibender Konfektionierung und Qualität herzustellen. Dazu nutzt das MES sog. Rezepte. Wie nebenbei protokolliert das MES die einzelnen Schritte der Rezepte zum Nachweis und kann so einen Herstellreport erzeugen.

Zu den Kernfunktionen moderner Manufacturing Execution Systeme zählen:

• Stammdatenadministration: z.B. Benutzer- / Material- / Equipmentverwaltung / …
• Rezeptadministration: Anlegen, Ändern, Versionieren von Rezepten (z.B. je Produkt, Markt, Spezifikation, …)
• Auftragsadministration
• Abarbeitungsfunktionen
• Weitere Administrationsoberflächen
• Review- / Freigabefunktionen

Daneben existieren viele weitere Funktionen, die über die Jahre erweitert und verfeinert wurden, wie wiederverwendbare Bibliotheken, Reporting, KPIs, Benachrichtigungen, usw.

Manufacturing Execution Systeme ermöglichen es also anhand bestehender Rezepte und je nach Bedarf, Fertigungsaufträge zur Herstellung von Produkten anzulegen bzw. zu übernehmen und deren Abarbeitung zu triggern, zu leiten und deren Ablauf zu dokumentieren.

Was diese Abarbeitung angeht, stellt das Manufacturing Execution System im Grunde also eine „Laufzeitumgebung“ für Produktionsrezepte dar!

3. Was ist ein MES Rezept?

Ein MES-Rezept enthält die Menge aller Informationen, die benötigt werden,
um dauerhaft Produkte gleichbleibender Qualität nach einem bestimmten Verfahren unter Einsatz bestimmter Materialien und Nutzung bestimmten Equipments herzustellen.

I.d.R. definiert es also, ganz ähnlich eines Kochrezeptes, die Materialliste, die notwendigen Ausrüstungsgegenstände und die korrekte Abfolge der Schritte des Herstellungsprozesses.

Das MES-Rezept kann z.B. in Form einer Datei vorliegen, entweder in offenem Format, (wie z.B. XML) oder aber auch Hersteller-proprietär.

4. Betrachtung zur Validierung von Manufacturing Execution Systemen

Ohne zu sehr ins Detail zu gehen kann man sicher behaupten, dass ein MES ein sehr komplexes System mit vielfältigen Server- und Client-Komponenten darstellt. Es besteht i.d.R. aus Datenbank-Server, Applikation-Server, Web-Server, File-Server, Print-Server, etc., etc. sowie zusätzlichen Interfaces zu Level 2 und Level 4 Applikationen, die oft auf verschiedene (virtuelle) Hardware-Komponenten verteilt vorliegen.

Gerade im Hinblick auf das „kritische Denken“ ist es also naheliegend vielfältige Abhängigkeiten zu identifizieren, vielfältige riskante Einflussfaktoren zu analysieren und in den Validierungsansatz einzubeziehen.

Dennoch will ich im vorliegenden Fall aber eine Lanze dafür brechen einem anderen Ansatz zu folgen und stattdessen einen Schritt zurückzutreten und das komplexe Computersystem abstrakter zu betrachten und so möglicherweise zu einem vereinfachten Validierungsansatz beizutragen.

Ich plädiere dafür das MES zunächst aus verschiedenen Perspektiven differenziert zu betrachten.

Beispiele:

• Perspektive-1: Hardware-Komponenten vs. Software-Komponenten
• Perspektive-2: Software-Komponenten pro Hardware (VM)
• Perspektive-3: „Standard“-Software vs. Custom-Entwicklung
• Perspektive-4: Software-Code vs. Konfiguration vs. Stammdaten
• …
  
  

Diese Liste an Differenzierungsperspektiven ist bei weitem nicht vollständig, ich habe lediglich jene dargestellt, die diese Diskussion aus meiner Sicht voranbringen.

So unterstützt (1.) die Differenzierung von Qualifizierung und Validierung, (2.) ermöglicht die Strukturierung der Validierungsdokumente, (3.) und (4.) sind wertvoll für die risikobasierte Betrachtung und damit den zu betreibenden Validierungsaufwand.

4.1. IT Infrastruktur Plattformen

Die Hardware wird nach Anforderung bestellt oder in einer virtuellen Umgebung konfiguriert. Zur Dokumentation der anforderungskonformen Umsetzung kann z.B. das Konfigurationsskript / Konfigurationsprotokoll dienen. Gibt es ein solches Dokument nicht, z.B. weil die Konfiguration manuell erfolgt, kann eine Art Installationsanleitung, in der einzelne Schritte abgehakt oder unterschrieben wurden, an dessen Stelle treten.

4.2. MES (Software-Code)

Das MES, i.d.R. der MES Application Server, stellt eine definierte Menge an Standard- bzw. Custom-Funktionen bereit. Diese müssen unter Einbeziehung der GAMP Kategorie im Rahmen einer Risikoanalyse betrachtet, bewertet und abhängig von der Bewertung auch validiert, d.h. im Hinblick auf Übereinstimmung mit den Benutzeranforderungen getestet werden. Da es sich jedoch weitgehend um ein konfigurierbares Standard-System mit gelegentlichen kundenspezifischen Anpassungen handelt, kann der Validierungsaufwand hier zu großen Teilen angepasst, d.h. reduziert werden.

Kundenspezifische Entwicklungen stellen hier den Sonderfall dar.

4.2. MES-Rezepte

Wir können das Manufacturing Execution System als eine Art „Laufzeitumgebung“ mit Administrationsoberflächen betrachten; Laufzeitumgebung deshalb, weil im Rahmen von Herstellaufträgen die MES-Rezepte immer wieder ablaufen, gerade so, wie z.B. Java Bytecode in einer Java Virtuellen Maschine (JVM), oder eine Excel Formel in der Microsoft Excel Applikation immer wieder gleich (vorhersehbar) ablaufen.

Die entscheidenden Informationen zur elektronischen Abbildung des Herstellprozesses stecken folglich in den MES-Rezepten, so dass diesen bei der Validierung auch besondere Aufmerksamkeit zukommen muss.

Exkurs: Stammdaten(pflege) // Konfiguration

Grundsätzlich kann jeder Hersteller selbst definieren, was er als Stammdatenpflege (Stammdaten) bzw. als Konfiguration (Konfigurationsdaten) betrachtet und was als Unterscheidung dienen soll. Sich diesbezüglich der Lieferantenempfehlung anzupassen ist auf jeden Fall sinnvoll.

Beispiel: SAP definiert Stammdaten als Daten die über das Easy Access Menu oder Transaktions-Codes editiert werden, wohingegen Konfigurationsdaten über den Implementation Guide (IMG) oder durch direkte Anpassung der Konfigurationstabellen editiert werden.

Ähnliche Unterscheidungen liefern auch MES Anbieter.

MES-Rezepte sind Dateien, die alle Produktionsschritte eines Herstellungsprozesses, deren Abfolgen, Abhängigkeiten, jeweils betroffene Materialen (Eingang / Ausgang) sowie das betroffene Equipment enthalten und in einen für die Produktion sinnvollen und notwendigen Zusammenhang bringen.

MES-Rezepte und darin enthaltene Formeln bedienen sich nur aus bereits im System verfügbaren Objekten und ihre „Konfiguration“ erfolgt ausschließlich über entsprechende, eingeschränkte Entwicklungs-Oberflächen, in der existierende Standard-Objekte zur Verfügung gestellt werden.

Eine Person, die ein Rezept modelliert, bedient sich lediglich dieser vorgefertigten Objekte und kann maximal deren Reihenfolge, Ausprägung und Häufigkeit beeinflussen.

Frage: Ist das Erstellen eines MES-Rezeptes dann also nicht nur eine Art Konfiguration und das MES-Rezept selbst nur eine Konfigurationsdatei?

Exkurs Definition: (Computer) Programm

Das Cambridge Dictionary definiert ein Programm übersetzt als:

„Eine Serie von Anweisungen, die einem Computer übergeben werden können, damit dieser eine Aufgabe ausführt.“

Antwort: Im engeren Sinne nein, dennunabhängig davon, ob Anweisungen „geschrieben“ oder zusammengeklickt werden, stellt ein MES-Rezept doch ein Programm dar.

Auch die Tatsache, dass nur aus einer begrenzten Menge von Anweisungen gewählt werden kann, spielt hierbei keine entscheidende Rolle, da auch Laufzeitumgebungen anerkannter Programme, z.B. der JVM, nur einen begrenzten, wenn auch wesentlich größeren, Anweisungsumfang beherrschen!

Die Frage ist und bleibt aber spannend, so dass wir noch darauf zurückkommen werden.

MES-Rezepte kodieren den Herstellungsprozess und weisen das Computersystem
(hier: das MES) an, den Herstellprozess nach vorbestimmtem Ablauf abzuarbeiten. Sie sind somit eigene proprietäre Programme, stellen den bedeutendsten Teil kundenspezifischer Entwicklung/Anpassung dar und sind daher als GAMP Kategorie 5 zu betrachten!

Besonderheiten bei der Entwicklung von MES-Rezepten

Entwickler von MES-Rezepten, auch Modellierer genannt, weil sie den durch die Herstellvorschrift definierten Herstellungsprozess im Manufacturing Execution System nachbilden (modellieren), sind in der Art ihren Eingaben, anders als Software-Entwickler, nicht ganz frei. D.h. Sie haben oft keine Möglichkeiten Quelltext frei in einen Editor einzutragen.

Sie können oft auch keine eignen Interfaces, Klassen, Objekte, Variablen, Attribute, Methoden, Funktionen, oder andere Sprachelemente von Computersprachen erzeugen und benennen. Sie sind also weitgehend beschränkt darauf bestehende Funktionsbausteine zu verwenden und in Ihrer Abfolge anzuordnen, ähnlich, wie man Excel Funktionen, nicht aber Excel Macros, nutzt.

In diesem Sinne können Rezept-Entwickler ihre Entwicklungsoberfläche häufig nur nutzen, um bereits bestehende Objekte auszuwählen und sich so Ihre gewünschte Berechnung zusammenzuklicken. Für ein solches Vorgehen / einen solchen Ansatz haben sich inzwischen die Begriffe Low-Code / No-Code etabliert, um zu verdeutlichen, dass keine speziellen Software-Entwicklungskenntnisse erforderlich sind, um MES-Rezepte zu entwickeln.

Könnte man also nicht dennoch so weit gehen, die weiter oben gegebene Antwort, nach der MES-Rezepte Programme sind nochmal in Frage zu stellen und zu behaupten, dass die Erstellung von MES Rezepten trotz allem eher der Konfiguration von Herstellprozesses im MES, mit den für die MES Rezepte bereitgestellten Bordmitteln, entspricht?

Wir kommen darauf zurück.

Der Herstellungsprozess, den Modellierer im MES-Rezept nachbilden ist grundsätzlich zwar in der Herstellungsvorschrift beschrieben, jedoch oft rudimentär, ohne viele Details, so dass oft nur die allerkritischsten Parameter tatsächlich mit Werten hinterlegt sind.

Eine Herstellungsvorschrift kann also bestenfalls als Spezifikation für den ersten, sehr eingeschränkten Entwurf eines MES-Rezeptes herangezogen werden.

Weitere Details finden sich möglicherweise in einem papierbasierten Herstellprotokoll und / oder vor allem in den Köpfen von Fachexperten, seien es Produktionsmitarbeiter bei bereits bestehenden Herstellprozessen oder Forscher bei Neuentwicklungen.

Der Prozess dieses Wissen herauszukitzeln und für die Verfeinerung des MES-Rezeptes nutzbar zu machen, gelingt am besten im kontinuierlichen gemeinsamen Austausch zwischen Modellierern und Fachexperten, indem immer wieder neue Prototypen von Teil-Abläufen des Rezeptes entwickelt, vorgestellt, besprochen, angenommen oder verworfen werden. Ähnlich multipler Evolutionen werden immer wieder neue Ideen entwickelt und auf die Probe gestellt, bis sich die beste durchsetzt. Es handelt sich also um einen explorativen Ansatz des Prototypings.

6.   Besondere Herausforderungen bei der Validierung von MES-Rezepten

Wenn Sie bisher meiner Argumentation folgen, dass MES Rezepte Programme sind, wenn auch ggfs. Low-Code Programme, so sind wir uns vermutlich bereits einig, dass diese Programme auch validiert werden müssen.

Uneinigkeit könnte aber durchaus noch dahingehend bestehen, ob MES-Rezepte „programmiert“ oder nur „konfiguriert“ werden.

Als programmiertes Stück Software müssten MES-Rezepte nämlich in die GAMP Kategorie 5 eingestuft werden.

Lassen Sie uns diesen Gedanken kurz parken, um später darauf zurückzukommen, wenn ich Ihnen zeige, dass dies im Fall von MES-Rezepten keinen Unterscheid machen muss.

6.1 Dokumente für Systeme der GAMP Kategorie 4:

Egal ob konfiguriert (GAMP Kategorie 4) oder programmiert (GAMP Kategorie 5), folgende empfohlene Dokumente (sog. Deliverables) sollten im Rahmen der Validierung erstellen werden:

• Validation Plan
• URS
• Risk Assessment
• Functional Specification
• Detailed (Module) Design Specification
• Module Testing
• Functional Testing
• User Acceptance Testing
• Traceability Matrix
• Validation Report
  
  

Risikobasiert und durch Anwendung kritischen Denkens, sollte beurteilt werden, welche der genannten Deliverables explizit auch für MES-Rezepte notwendig sind.

Ich möchte Ihnen folgende Argumentation als Hilfestellung anbieten:

Validierungs-Plan:
Je nach Setup des Projektes kann es sinnvoll sein, dieses Dokument für jedes MES Rezept einzeln zu erstellen.

Prinzipiell würde ich jedoch davon abraten und eher dafür plädieren die Inhalte in das Deliverable des Manufacturing Execution Systems selbst zu integrieren.

Anforderungs-Spezifikation:
Für jedes einzelne MES-Rezept sollte eine Anforderungs-Spezifikation erstellt werden, die zumindest Basisdaten des MES Rezeptes beinhaltet, wie:

• Rezept-ID
• eingesetzten Materialien
• Zielmaterial
• verwendete Produktionseinheit und verwendetes Equipment
• Abfolge der Hauptproduktionsschritte
• verwendete Formeln und Berechnungen
• ggfs. Besonderheiten des Rezeptes
  
  

Da der Prozess der MES-Entwicklung (siehe Low-Code-Argumentation in Kapitel 5) einerseits aber sehr agil (rapid Prototyping) und weitgehend explorativ abläuft und andererseits eher einer Konfiguration entspricht, kann es aus meiner Sicht durchaus Sinn machen nicht zu versuchen die Spezifikation vorab detailliert auf Papier (oder elektronisch) niederzuschreiben und dann dahingehend zu entwickeln.

Stattdessen empfehle ich eine konstante und enge Zusammenarbeit zwischen Entwicklern (Modellierern) einerseits und den prozessverantwortlichen Business Repräsentanten anderseits, aus der dann entweder ein fertiges MES-Rezept und eine dynamische Dokumentation mit Hilfe neuerer und agiler Dokumentationstechnologien, hervorgeht oder (falls diese Dokumentationstechnologien nicht zur Verfügung stehen) ein fertiges MES-Rezept dessen „Spezifikation“ / Dokumentation entsprechend einer Konfiguration „as-is“ erfolgt, d.h. die Dokumentation des Status erfolgt erst nach der agilen Entwicklung.

Diese Art von „Spezifikation“ kann dann auch automatisch erstellt werden!

Risikobewertung:
Die grundsätzlichen Risiken die mit Fehlern in MES-Rezept verbunden sind unterscheiden sich eher von Industrie zu Industrie (Chemische Industrie – z.B. Lackherstellung vs. Pharmazeutische Industrie – z.B. Wirkstoffherstellung) als von Rezept zu Rezept innerhalb eines Unternehmens.

Daher empfehlen wir in den meisten Fällen mehrere, z.T. sogar alle, Rezepte in einer Risikobewertung zusammenzufassen. Dies erspart Ihnen sowohl Erstellungs-, als auch Pflegeaufwand und geht in den allermeisten Fällen nicht mit einem Rückgang an Qualität, hier dem Verpassen möglicher Fehlerszenarien oder der Fehlbewertung von Risiken, einher.

Funktionale Spezifikation:
Für alle MES-Rezepte, die Berechnungen, z.B. in Form von Formeln durchführen sollte eine Funktionale Spezifikation erzeugt werden, die darstellt, auf welche Anforderung man sich bezieht, d.h. welches Ziel man mit der Berechnung verfolgt und wie dieses ziel umgesetzt wird, d.h. die Funktionsweise der Berechnung.

Detail (Module) Design Spezifikation:
Aus meiner Sicht sind weder Detail Design Spezifikationen noch Modul Design Spezifikationen für MES-Rezepte erforderlich. Theoretisch könnte man argumentieren, dass wiederverwendbare Bausteine (Bibliotheken) als Module betrachtet werden könnten, so dass bei reger Verwendung dieser Bausteine eine Modul Design Spezifikation vielleicht Aufwand einsparen könnte. Dennoch empfehle ich in der Mehrzahl der Fälle die Spezifikation des verwendeten Bausteins einfach in die Anforderungs-Spezifikation bzw. die Funktionale Spezifikation zu integrieren.

Modul Tests:
Aus meiner Sicht sind Modultests meist kaum möglich und im Übrigen bei MES-Rezepten vernachlässigbar. Erfahrungsgemäß kann ich sagen, dass eine Überprüfung der Implementation von Formeln und Berechnungen (siehe 6.2) Funktionale Tests und Benutzer Akzeptanz Tests mehr als ausreichende Sicherheit im Hinblick auf die Anforderungs- und Behördenkonformität der MES-Rezepte liefern.

Funktionale Tests:
Sie dienen der Überprüfung der Funktionen, d.h. im Falle von MES-Rezepten in erster Linie von Berechnungen oder Formeln und sollten daher alle wesentlichen Berechnungen abdecken.

Benutzer Akzeptanz Tests:
Sie dienen dazu sicherzustellen, dass die Endanwender, vertreten durch den Prozess-Eigner oder dessen Delegierte, ein MES-Rezept erhalten, welches Sie in die Lage versetzt, den Herstellungsprozess entsprechend Ihrer in den Anforderungen festgelegten Erwartungen und der eingereichten Herstellvorschrift in guter Qualität und reproduzierbar durchzuführen.

Solche Benutzer Akzeptanz Tests sollten pro MES-Rezept durchgeführt werden.

Business-Repräsentanten bestätigen dabei die Eignung des MES-Rezeptes für den vorgesehenen Einsatzzweck / Herstellungsprozess.

Benutzer Akzeptanz Tests sind zwingend erforderlich, müssen aber nicht zwingend in einer bestimmten, nur für die Validierung vorgesehenen „Umgebung“ durchgeführt werden.

Rückverfolgbarkeits-Matrix: 
siehe Ausführungen zum Validierungs-Plan.

Validierungs-Report: 
siehe Ausführungen zum Validierungs-Plan.

6.2. Üblicherweise Dokumente für Systeme der GAMP Kategorie 5:

• Coding-Richtlinie
• SourceCodeReview-SOP (ggfs. mit Template)
• SourceCodeReview (die eigentliche Ausführung)
• SourceCodeReview-Report (Zusammenfassung der Ergebnisse)
• …
  
  

Kommen wir nun zurück zu der Frage, ob MES-Rezepte als Programme (GAMP Kategorie 5) oder doch nur als Konfigurationsdateien (GAMP Kategorie 4) zu betrachten sind.

Auch bei den beispielhaft o.g. zusätzlichen Deliverables der GAMP Kategorie 5 empfiehlt sich kritisches Denken anzuwenden, in dem z.B. der potentiellen Nutzen und Qualitätsgewinn einzelner Maßnahmen und deren Dokumentation kritisch hinterfragt wird.

Wenn z.B. SourceCode vom Entwickler nicht frei in einem Editor „geschrieben“ werden kann, d.h. wenn der Entwickler Interfaces, Klassen, Objekte, Variablen, Attribute, Methoden, Funktionen, usw. zwar nutzen, aber nicht selbst benennen kann, ist der eigentliche Sinn einer Coding-Richtlinie, nämlich „Wildwuchs“ bei der Entwicklung einzuschränken, nicht gegeben.

Überall da, wo der Entwickler also eine Entwicklungsoberfläche nur nutzt und nur nutzen kann, in dem er bereits bestehende Objekte auswählt (zusammenklickt) und in eine gewünschte Reihenfolge bringt, folgt er eher einem Low-Code, No-Code-Ansatz.

In diesen Fällen führt z.B. eine Coding-Richtlinie und deren Einhaltung (sichergestellt durch SOP / Überprüfung / Bericht) nicht zur Verhinderung von „Wildwuchs“ und somit auch nicht zu einem Zuwachs an Qualität.

In diesen Fällen kann auf die Deliverables der GAMP Kategorie 5 sogar vollständig verzichtet werden, weil sich diese eben nicht qualitätssteigernd auswirken.

Was, wenn nicht das, stellt ein stärkeres Argument dar, MES-Rezepte nur als GAMP Kategorie 4 und somit als Konfigurationsdateien zu betrachten?

Ein „SourceCodeReview“ ganz anderer Art ist im Fall von MES-Rezepten aber durchaus qualitätssteigernd und somit auch sinnvoll, nämlich dann, wenn der Review nicht die Konformität zu einer Coding-Richtline prüft, sondern stattdessen die Konformität zum beschriebenen Prozess, so wie er in der Anforderungsspezifikation festgelegt wurde, im Idealfall gemeinsam mit einem qualifizierten Endanwender und einem Entwickler vor der ersten Testdurchführung, d.h. noch vor den Funktionalen Tests!

Natürlich kann hier auch der grundsätzliche Ablauf des „Programms“, des MES-Rezepts überprüft werden, da dies jedoch im Rahmen der Funktionalen Tests / Benutzer Akzeptanz Tests ebenfalls erfolgt, sollte aus meiner Sicht der Schwerpunkt risikobasiert auf die Prüfung der korrekten Implementierung von Formeln und Berechnungen gelegt werden.

Sollten Sie allgemein mehr zum Thema Computer System Validierung erfahren wollen, selbst einen schlanken Ansatz der Computer System Validierung verfolgen und sich rückversichern wollen oder konkrete Fragen zur MES-Rezept Validierung haben, setzen Sie sich bitte direkt mit uns in Verbindung.

Autor: Helmut Rector